Archive for September, 2009

5 Reasons Why Silverlight Is My Preferred Web Development Platform

18 commentsWritten on September 5th, 2009 by
Categories: Opinions, Silverlight

NOTE: if you landed on this post while doing research as to whether or not Silverlight is a technology worth learning or using, please read the following posts as well, which i wrote about a year after writing the one below: Keep Your Eyes On The Road and Learn To Work With The Web Instead Of Against It. Simply put, Silverlight is no longer my preferred web development platform for a variety of reasons i mention in those two posts.

The company where i work has been using Silverlight ever since the first version came out, and by now we have quite a bit of experience and dare i say expertise in it. We generally suggest using Silverlight for every new project that we do, and the only time we don't use it is when customers don't want us to use it. This happens very rarely though.

While i generally don't get involved in most of the UI stuff, i'm pretty happy with this because i seriously like Silverlight as a platform. Below is my list of top 5 reasons why Silverlight is my preferred platform for Web Development nowadays:

  1. The ability to create an excellent UIX which definitely matters to customers.

    We have some projects at work where the Silverlight UI definitely receives a "wow" response from customers. Not only because the UI is extremely responsive and snappy, but also because we can use new ways of visualizing data and enabling user actions in the UI in ways that are either completely new for web applications, or just new in general. We can easily create much more intuitive user interfaces with a responsiveness that can easily compete with that of desktop applications.

  2. Low bandwidth overhead

    Downloading the XAP file can sometimes be painfully slow, depending on your bandwidth obviously, but once it's downloaded it's also cached by the user's browser. Everything that happens after that consumes very little bandwidth. There is no CSS, no HTML markup, no javascript, ... the only thing that goes over the wire is the data that you actually need. And with Silverlight's Binary XML feature you're also using less bandwidth than before. This might not seem like a big deal to you, but bandwidth has a huge impact on the client-side responsiveness as well as your server-side ability to process requests.

  3. The client is stateful again

    This one is huge to me. We don't have to deal with things like ViewState or SessionState or anything like that. If a client has retrieved a set of data, it can just keep it in memory if it makes sense to do so. This is especially useful for things like user-profiles, or static data that never changes but it has an impact on pretty much everything you develop. You can simply keep whatever data you need in memory, and it has no impact on the server at all. Well, it actually reduces the amount of data that you need to send to the server (or receive), and the number of requests you need the server to handle to implement the functionality you need client-side. This is pretty much a win-win for both the client and the server whereas with typical ASP.NET development, either the client or the server has to take some kind of a hit when it comes to maintaining state (even if it's only a little).

  4. The ability to write the client almost entirely in C#

    I don't know about you, but my HTML, CSS and Javascript skills are extremely limited. This seriously reduces my effectiveness when i need to make changes in the presentation layer in typical ASP.NET applications. And while my XAML skills aren't what they should be, my C# skills are sufficient for me to be effective in client-side changes. I can easily look at a piece of client-side code and make whatever change i need to make without having to consult a reference guide. That's not the biggest advantage to being able to write the client in C# though. Existing C# skills are very easily transferable to the Silverlight side of things, which means that a larger pool of developers is available to work on your front-end. True, there is a bit of a learning curve when it comes to Silverlight, but i'd argue that there is a much steeper learning curve to doing traditional client-side web development effectively.

  5. It's only going to get better

    As much as i like Silverlight, it is by no means perfect and there is plenty of room for improvement. That's normal though for such a young platform. In the future we'll see plenty of new libraries and tools that will become available to Silverlight developers which should enable us to create even better web applications. Microsoft is investing a lot of money and effort into it, and i'm pretty sure that others will follow.

Now, you won't hear me say that Silverlight is the perfect solution for every web application. SEO is still a problem, as well as acceptance of the Silverlight plugin in corporate environments (though this will only improve over time). But, in the situations where you can use Silverlight, it certainly pays off to do so.

Let Me Know What You Think

11 commentsWritten on September 4th, 2009 by
Categories: About The Blog

It's always (well, most of the times) nice to hear from your readers, but the large majority of people who read blogs don't leave comments. So i'm gonna try something new here... i just installed the 'GD Star Rating' plugin for WordPress which enables you, the reader, to rate my posts. You can give a star rating, or just a plain thumbs-up or thumbs-down.

So don't be afraid to let me know what you think when you read a post, either through a comment or through a rating :)

More ORM Ignorance

23 commentsWritten on September 4th, 2009 by
Categories: Opinions

Tony Davis from simple-talk wrote a post about the so-called ORM Brouhaha that followed from the recent benchmarking fiasco. I have some problems with some of the statements in his post, and since he loves to hear what we think i decided to share my thoughts on this.

He starts off the post with the following:

A while back, Laila Lotfi wrote an editorial on the need for a standard benchmark for Object-Relational mappers, such as Entity Framework and nHibernate. By how much do they really slow down database applications?

ORM's slow down database applications? That's a generalization that i believe many of us can make about stored procedures or classic data access layers as well, after all, they are quite frequently used as incorrectly as ORM's are often misused. First of all, the purpose of an ORM is not just to ease your development tasks or to keep your code free from repetitive cruft. It is as much about optimizing your usage of the database as it is about ease of development.

Any decent ORM will aim to minimize overhead when it comes to communicating with the database. Generally speaking, an ORM should try to send as few statements to the database as possible, either through usage of batching techniques, being able to generate good queries, and not executing unnecessary statements. How many times have we seen data access code that doesn't have proper dirty checking and sends update statements for entities that haven't really been modified? I've seen plenty of implementations where doing something like myEntity.SomeProperty = myEntity.SomeProperty still resulted in an unnecessary update statement because a dirty flag was set in a naive manner. A good ORM will not do this, and will try to keep the overhead of communicating with the database as low as possible.

There many complaints to the effect that the benchmark tests are useless, because the tool "should never be used in that way". If it can be, it almost certainly will be; and it is up to the tool creator to make sure that it stands up as well as its competitors.

Is it the responsibility of a tool creator to make sure it performs as well as it possibly can in usage scenarios that are actively discouraged? Should we hold everyone to this rule? How about we apply that logic to databases or DBA's? Using the same twisted logic, we could actually blame bad database performance on database implementations or DBA's because hey, we are able to use them badly, so it is their responsibility to make sure that it performs as well as it possibly can. Seems like a bit of a ridiculous statement, no? This kind of 'logic' actually conflicts with the problems that many people incorrectly associate with ORM's so i think we can safely ignore this.

I imagine the sight of such a brawl sent a chill down the spine of managers who may have been planning to use ORM technology.

Pardon me for being blunt, but having to follow the technical decisions from a manager who holds value to the results of silly, unrealistic benchmarks is a situation that would send chills down my spine as well.

The IT industry is increasingly coming to suspect that the performance and scalability issues that come from use of ORMs outweigh the benefits of ease and the speed of development.

I haven't really noticed this so called trend. In fact, i'm under the impression that usage of ORM's is finally becoming more and more accepted, especially in the .NET world. In the Java world, where i think we can objectively state that many large-scale and highly performant applications have been developed over the years, ORM usage is pretty prevalent.

And seriously, how many of us have had to deal with applications or systems that didn't use an ORM but used either a classic data access layer or stored procedures and still suffered from bad database performance? I think the large majority of the development community has experience with exactly this kind of situation, so i really don't think ORM's are the problem here...

We are crying out for objective benchmarks and if the ORM industry itself cannot hope to agree on how to do it, then perhaps benchmarks will have to be imposed on them.

Impose all you want, but don't be surprised if those benchmarks will be ignored or questioned by those who hold more value to properly educating developers instead of basing their decisions on irrelevant benchmarks.

QuickNet On Google Code

1 Comment »Written on September 3rd, 2009 by
Categories: testing

I mentioned QuickNet before and i'm happy to say that the project is now available on Google Code. I'm also going to be contributing to QuickNet as of next week, so you can probably expect some future blog posts about this as well ;)

Be sure to read Mark's announcement about this if you're interested in playing with QuickNet.

Avoiding (Or Recovering From) Burnout

11 commentsWritten on September 1st, 2009 by
Categories: life, Off Topic, work/career

A lot of software developers that are passionate about their craft spend a lot of time on it. They spend a lot of time reading interesting blogs, reading books about development, coding on some hobby projects, or maybe even contributing to open source projects or writing interesting blog posts of their own. Hell, just trying to stay up to date with all the new stuff that continually comes out can be one hell of a challenge in its own right. And a lot of this effort is typically spent outside of our normal working hours.

There's nothing inherently wrong with that, but it is extremely important to remember to take some time off, not just occasionally, but frequently. Software development can be very interesting and a lot of fun, but you really need to make sure that you find some kind of a healthy balance in your life. If you spend too much time on this, odds are pretty high that eventually you'll start to lose your passion for it, and even worse, that you really don't feel like spending any time on it at all anymore.

I reached that point somewhere at the end of May this year. I completely lost my motivation for both my job as well as the whole blogging thing. I didn't really care about writing code anymore, i couldn't be bothered to catch up with the RSS feeds that i subscribe too, and i could hardly fake interest whenever technical discussions came up. The fact that i was going through some personal stuff certainly didn't help either. But the biggest reason was probably the fact that i was just trying to do too much in the months before that.

And then i simply stopped caring about it. I still tried to do my job to somewhat satisfactory levels but my heart certainly wasn't in it anymore. After work, i didn't write any code, nor did i read about it anymore. I just started doing other things. Whatever i felt like doing basically, as long as it wasn't related to software development. I did write a couple of posts during this period, but none of them were actually any good.

Somewhere in the middle of July, my interest in software development was slowly coming back, but it was still more of a sporadic thing instead of the passion that it used to be. The most important thing that i learned at that time was that i simply shouldn't force myself to spend time on something if i don't feel like spending time on it at that time. I occasionally spent some time writing code or doing a bit of reading, but i was alternating between the geek stuff and the normal stuff more than i used to.

That turned out to be the key to my 'recovery'. And for the past couple of weeks, i've felt kinda reinvigorated. I care about software development again. I love spending time on it again and my motivation is as high as it used to be.

So now you're probably wondering why on earth i'm posting this? For one, it feels good to get this off of my chest. And secondly, because i'm willing to bet that there are a ton of developers who feel the same way. Take it from someone who's been through it: as much as you love software development, make sure that you don't spend too much time on it. When you feel like spending time on it, then by all means, do so. But never, ever spend time on it outside of your working hours if you're not really in the mood for it, or when you feel like you have to, or when you'd rather be doing something else. You're already spending 8 hours a day on this stuff, so you should only spend extra time on it when you really want to. If you ignore this advice, you might end up not wanting to spend any more time on it at all, and that is a situation you really want to avoid.