Facebook has a HTTP REST API exposed to the outside world. It is used by thousands of developers in different languages. Google API for most (if not all) of its services is also based on HTTP REST. This seems to be working for almost any “web 2.0″ application out there. Now bring Microsoft into the complex: Facebook SDK by Microsoft. I’m trying to get the news feed from a multi-threaded application using this SDK and here is what I get: System.Threading.ThreadStateException: ActiveX control ’8856f961-340a-11d0-a96b-00c04fd705a2′ cannot be instantiated because the current thread is not in a single-threaded apartment.
And for now I’m getting this in my unit tests (which are running under ReSharper), I am going to have so much “fun” doing it in the real app.
I just want to ask WHY? Why is there an ActiveX anywhere in this SDK? Forget about the old and redundant technology. Couldn’t MS guys put a simple SDK together like ANY other REST based SDK out there that just works based on a bundle of wrappers around HTTP REST calls?
Why does Microsoft want to do everything their way and ignore every single standard under the sun?
I love Windows 7. So much that when my MacBook batter died for the third time in two years because of a manufacturing fault, I didn’t bother to go to an Apple shop again! I now use my Samsung NC10 netbook with Jolicould pre-beta and Windows 7 on my main desktop.
I also love Chrome as a browser. I’m using the main release and not Dev or Beta channels since it’s my main browser and I have other things to worry about at the moment. However, one thing bugs me a lot about Windows 7 and Chrome. Here is a snapshot of my taskbar. I have a Chrome App for my Last.fm and ever time I start it, all other instances of Chrome are displayed under that as multiple tabs.
Chrome Team: Please fix this! Thank you!
My recent project was hosted on a virtual server in GoGrid. The server was a Windows 2008 running IIS7 and SQL 2008 Express. The application was in .NET 3.5 SP1 and was running as a ASP MVC front end and a Windows Service as a back end. NHibernate as ORM, Spring.net for IoC and DI, Log4Net for logging and a few other open source tools and frameworks.
With my BizSpark partnership approved, I tried to move the system to Windows Azure and now after spending 2 weeks on that I am moving it back to a dedicated server and trying to recover from the time wasted on this.
In my opinion, Azure is a brilliant framework but it is not ready for prime time yet. It can become a great cloud development environment within a year or so, but not now.
The problem is Microsoft is inventing lots of new concepts and tools to make Azure happen. The logging framework, communication between the worker instances (done only through WCF and queues) and many other new concepts are being tried at the moment as Azure is in CTP. However, this means no serious commercial product can really be ported to it until the tools and framework is set and gets to a certain level of maturity. Until then, developers will lose a lot of time, tracking this moving target and that is something many startups cannot afford.
Compare this with other MS technology based cloud computing services offered by Amazon, GoGrid, RackSpace and others. These are based on tried and tested technologies and that makes it easier for developers to develop for.
Cloud computing hosting and development is still a new technology and is still suffering from teething problems. I think Microsoft is doing a good job in inventing new tools for this new paradigm. However, it should try to open up its standards and to the open source standards if it wants to see Azure take off and more importantly, it should stay in the game for a long time and the developers will gradually move to the new platform slowly.
For now, the pain of moving my application to Azure was too great: Front-end/Back-end comms had to be replaced with MSMQ backed WCF, Lucene directories had to be re-written for Azure storage, logging had to be replaced with traces and some other issues.
Very long deployment process, VS SDK issues, SQL server accessibility problems and lack of good personal development/business support structure within Microsoft added on top of my other problems meant that I will be visiting Azure sometime later this year but not for this project.