Wednesday, February 10, 2010

Google Applications

I logged into GMail today and got an invitation to activate Buzz, so I did. I even posted a quick little message about my immediate impressions. And a fine bit of useless drivel it turned out to be if I do say so myself.

There was one thought that stuck me as interesting though. The realization cemented in my mind that there is bit of a pattern Google has to creating their solutions. They build or sometimes buy software that solves specific and difficult problems in easy to use ways that they provide for free. And with advertising much less obtrusive than other applications. They have many such pieces of software at this point. Now, they are finding the best possible ways to integrate them as elegantly as thy can. Networking applications to solve social networking, if you will.

I know, I'm late in realizing this. But I never accused myself of being overly watchful of other companies' strategies. Many people will argue that the one point of entry provided by Facebook makes social networking more convenient. My problem is that the utilities provided there just don't provide the functionality I want in photo management, calendars, email and event planning.

Thursday, February 4, 2010

MVVC, Silverlight and Staying Grounded

I was reading some Visual Studio Magazine today and there was an article on MVVC gushing over how great it is. I know it's not exactly new. I also know that the pattern, when combined with the trend toward data binding is a powerful combination. But it's surprising that many 'architects' apparently swear by this solution and insist on writing whole applications of every type without deviation.

There are many in-the-trenches sorts that believe that while it is useful in certain situations, it actually causes more work and creates less maintainable code much of the time as well. I ran across many differing opinions all in the same day. Probably the most sane of which were saying that it's a good architecture for mid size, data processing applications; too much for small tools and not flexible enough for large, interaction rich utilities.

As with all layers of an application, there appears to be different problems to solve in the UI. The different paradigms are good at specific problems of certain sizes, but no one is best suited for all tasks of every caliber. From messaging between disparate parts of a large application, to showing data in a small application, to interacting with complex UI's and business logic, it seems like you need to choose the solution(s) that will best fit the problem(s) at hand. This might not help you out much in choosing the best model to use on your current project, but it may be ammunition against those of the one-solution-fits-all mind set.

Maybe it all comes back to the fact that a text box and button with some in line SQL in the code behind is a perfectly acceptable way to modify some simple data under certain circumstances...

I also read up a bunch on Silverlight 4 today. I guess there's a slew of new technology being released along with .NET 4 and VS 2010. The general summary is that it makes Silverlight a viable line-of-business application platform. But, there seems to be a lot of bells and whistles that are more web 2.0'ish rather than business requirements. Maybe there's some overlap there, or maybe there will be when businesses are ready for it. That being said, it's probably worth looking into the specifics on the WCF changes as those were the hardest challenges that I remember having to overcome with the platform in a business application. The whole printing thing is probably pretty nice too.