Archive for August, 2010

Silverlight Getting Worse When It Comes To Memory Leaks

15 commentsWritten on August 19th, 2010 by
Categories: Memory Management, Silverlight

A coworker of mine spent some hours yesterday hunting down memory leaks in an app that he'd already gotten 'leak-free' back when it was in Silverlight 3. Turns out that the leaks are caused by changes in Silverlight 4 and not in our code. As you surely know, Microsoft releases major Silverlight versions pretty frequently (there's at least one major new version each year). That's great and all when it comes to introducing new features and capabilities, but it truly sucks if you keep introducing new problems as well. The total amount of time (and thus, money) that we've lost hunting down leaks that are located in either the core Silverlight code or the Control Toolkit (also Microsoft code) is just starting to become embarrassingly high.

To give you an idea of what kind of leaks that keep popping up, be sure to check out these links: http://forums.silverlight.net/forums/t/179177.aspx http://forums.silverlight.net/forums/t/179358.aspx http://forums.silverlight.net/forums/t/180702.aspx http://forums.silverlight.net/forums/t/181257.aspx http://forums.silverlight.net/forums/t/171739.aspx

If anyone from Microsoft reads this: please, pretty please, pretty please with sugar on top: can we get a little bit more QA from you guys? If you can put out products like WebMatrix and LightSwitch, than surely you must have enough resources available to make sure that your real development platforms do not become a cost-sink for your customers due to your own lack of quality control, no?

Update: it's also quite telling that the search phrase "silverlight memory leak" is the number one search phrase through which people get to this site. #justsaying

Once Again: Comments In Code Aren’t Necessarily Bad

33 commentsWritten on August 18th, 2010 by
Categories: Code Quality, Opinions

I happened to come across some blog posts and tweets that once again mentioned how evil it is to use comments in code. Some people still like to advocate the "if you need comments, your code sucks!" sentiment. As is often the case with this kind of statement, the only correct (or dare i say realistic) point of view is: it depends!

I generally agree that you should strive to avoid comments in code. That is, you should write your code in a way that doesn't require comments for the reader to easily understand and grasp what the code is doing. However... there are situations where comments are helpful (or even required), since you simply can't write everything in such a manner that it doesn't require any comments.

To back up my point, i'd like to point you to this challenge i posted over a year ago. That code is clean. But pretty much everyone could use some comments to understand why that certain approach was necessary since it's just not that obvious when focusing solely on the code. That code applies a certain pattern which isn't well known, but there is a very specific reason why the pattern is needed. And i still believe that most developers need comments to understand it properly. That's not to say that the guy who wrote it (which happened to be me) is better than those who're going to have to maintain it. Hell, i wrote the code, and i would certainly be glad to see some comments in that code if i had to make a change 6 months after the fact.

The key thing to remember is this: don't blindly follow what the books and/or the 'legends' say. If you need to write some code in a very non-obvious way, then you could really make things easier for those who need to maintain it (which could very well be you, btw) by including some comments to explain why a certain solution/pattern was chosen. There are some details you simply can't show through good naming practices or clean code in general... some things simply need to be explained and it's quite possible that a WHY comment or two benefits not only you but whoever is going to read the code more than some kind of excessive and futile exercise in making it as easy to understand as possible without comments ever will be.

In short, strive to avoid the need to write comments by writing clean code. But don't be afraid to use comments wisely either when clean code simply doesn't cut it. There's nothing wrong with that. After all, we don't all have the luxury to restrict our efforts to contrived examples.

Can An Object Grow?

21 commentsWritten on August 17th, 2010 by
Categories: Code Quality

As you probably know, i'm currently learning Ruby. And as you may or may not know, Ruby is a very dynamic language. And one of the things that i found immensely interesting about it is the ability to add methods to existing classes or to existing objects, which isn't the same as adding a method to a class in Ruby btw. And it sorta got me thinking about how the whole static vs dynamic thing can be applied to how we are often taught about objects and classes.

Chances are that when you learned about OO, you were introduced to the concept of objects using real world items. For instance, a door could be an object. It has certain attributes, and it has certain operations that can be invoked on it. But once a door has been produced, it will never gain new capabilities. It won't learn anything new. If anything, the attributes and operations that it was created with will only deteriorate over time.

Then again, some of us will undoubtedly have heard that a person is an example of an object too. A Person is an instance of the Human class. There is a huge difference between a Person instance and a Door instance. While the Door will never change (except for possible deterioration), a Person will change during its lifetime. It will gain new capabilities depending on what the Person instance goes through during its lifetime. It will also lose capabilities. It will gain new attributes, and some of them will no longer apply to that Person instance after a while. Its relationships can vary wildly from each Person to the next. A Person instance is highly dynamic throughout its lifetime, while a Door will always be the same.

The weird thing is... a lot of us use OO to model or mimic real world behavior. But real world behavior is pretty dynamic. Not for everything, but it definitely is for some things. And all this time, a large majority of us has been trying to model or mimic that behavior with static languages. In a static language, a Person instance would never be able to grow. You could define multiple types of Persons, but hey, a lot of people generally don't like to be put in groups based on attributes or capabilities and you'll always run into problems when doing so.

I'm not trying to convince anyone about anything specific in this post. But i am trying to get you think about what i'm saying. I do believe that objects can 'grow' in some or maybe even a lot of cases. And i think a lot of us can agree that static languages aren't exactly a great solution to dealing with this problem (though i prefer the term 'reality' instead). Dynamic languages on the other hand can offer better ways to deal with this, but then again you do have to keep in mind that they come with some downsides as well. In software development, there are very, very few win-win situations. Everything is a trade-off. For everything that you know and love, there will be an alternative that is more suitable in some cases, and less suitable in others.

So now i'd like to ask you the following 2 questions: 1) do you think that objects can 'grow'? 2) can developers grow? and how does that answer correspond to your answer to the first question?

Highly Recommended Book: The Ruby Programming Language

16 commentsWritten on August 15th, 2010 by
Categories: Books

I first learned about Ruby about 8 years ago, when another programmer that i only knew from some Linux-related forum (yup, i was a die-hard linux user at the time) kept claiming that it was one of the nicest and purest OO languages available. I kept thinking "yeah right, nobody is using Ruby for real stuff so it can't be good". In my defense, i was only 21 at the time and at that age a lot of people can still be quite ignorant at times (or even quite frequently). But that doesn't change the fact that i was just plain stupid.

Fast forward 8 years, and here i am: a developer who was once convinced of the virtues of static languages, but is increasingly frustrated by both the static nature of C# (regardless of the introduction of the dynamic keyword) because of the limits it places on my creativity, as well as the entire .NET world for a variety of reasons. So i figured it was time for me to learn exactly what was so good about these dynamic languages. At first, i doubted between going for Ruby and Python. I picked Ruby, mostly because it has more momentum than Python. And since i hate learning something new from some simple online tutorials, i wanted to get some good books on the subject to make sure i really learned what it was all about. The first book i ordered was The Ruby Programming Language which seems to be the definitive guide to the Ruby language. It ought to be, with that title :)

Books about programming languages are generally pretty boring. It's not the fault of the writers, or the language, it's just because so many boring details need to be covered when learning a new language. I was very happy to see that this book certainly minimizes those boring parts. The book starts off with a quick introduction to Ruby. It very quickly goes over some code with very brief explanations as to what the code is doing. Not sure if everyone will agree on this, but for me it was like the perfect appetizer. It really made me want to learn the language thoroughly.

The next 4 chapters aren't nearly as interesting as the introduction was. The 2nd chapter deals with the structure of Ruby code. Important, but not exactly thrilling to read. The 3rd chapter discusses some of the standard data types and you'll also learn more about how objects work in Ruby. The stuff about objects was very interesting, but the descriptions of the data types are, as they always are, pretty boring. The 4th chapter (Expressions and Operators) and the 5th one (Statements and Control Structures) are also quite boring. But then again, i can't possibly imagine how anyone could write about these kinds of topics in a way that is truly interesting, regardless of the programming language that is used. In fact, i'd say that these topics were dealt with in a manner that is at least less boring than how they're usually covered in programming books. And even though those parts are not the most interesting to read, it is great reference material if you quickly need to figure out something or need to refresh your memory while working with the language.

The next 3 chapters however were (IMO) immensely interesting. Chapter 6 tells you everything you need to know about Methods, Procs, Lambdas and Closures. You might be thinking "how could that possibly be immensely interesting?", but trust me, it is. I also think that this chapter will either strongly increase your appreciation of the Ruby language, or might be a little off putting, depending on how you generally feel about the importance of static typing vs dynamic. Most developers will see the possible dangers here and you'll either feel fear for what people can do in a method, or you'll love the power and flexibility while still recognizing the dangers (with an increased appreciation for automated tests, hopefully).

Chapter 7 deals with everything there is to know about classes and modules, and it's an absolute joy to read. At this point, i really started to feel stupid for not having learned about this years ago. Lots of interesting stuff here, and the ideas it planted in my head are surely gonna hurt me frequently while coding in C# at work. Chapter 8 was even worse in this regard... it discusses Ruby's reflection capabilities and the whole metaprogramming thing. It made my head spin, in the good way. I know i can really take serious advantage of those capabilities and i can't wait to actually experiment with it.

The 9th chapter discusses the Ruby Platform, which is basically a succinct run down of what you can do with a lot of the standard Ruby classes. I largely skipped this chapter since the next book on my reading-list (The Ruby Way) covers all of that and more, in depth. The final chapter covers the Ruby interpreter and the general Ruby environment. It's somewhat interesting, but nothing spectacular.

I generally approach programming language books as necessary reading (at least when you're learning a language) but a chore at the same time. While some of the chapters in this book suffer from a lot of the same problems that you'll find with other programming language books, it at least is less boring to read. Chapter 6 through 8 however are more than worth the cost of the book and could really change the way you think and feel about OO and if i could legally get away with it, i'd force every programmer to read those. It's certainly not going to convince everyone, but it could open a lot of people's eyes. This book is not only ideal to learn the Ruby language, it'll also be an invaluable reference resource to keep on your desk as you keep taking more steps in your Ruby journey.

I already know it's gonna take a long while before this book moves from my desk to my bookshelf.

First Month On Twitter: Likes And Dislikes

3 commentsWritten on August 12th, 2010 by
Categories: Opinions

It's been about a month since i caved and finally joined Twitter after having earlier said that i wouldn't. When i joined Twitter, i said this:

If i like it, i’ll keep using it and i’ll gladly state that i was wrong about the whole thing.

So here it is: i was wrong about the whole thing! Overall, i actually like it a lot and i'd probably find it pretty weird if i had to go back to going without it. But it's not all perfect though. So, this is a list of likes and dislikes that i've noticed after about a month of twitter.

Likes:

  • You can get in touch with everyone. You can reply to a tweet by someone 'famous' or that you admire or respect a lot or whatever, and actually get a response back. Well, you're never certain to get a response but it's highly likely that they at least read your reply. Getting a response is like icing on the cake. Likewise, people you've never heard of before will send you tweets to ask you a question, give their opinion on a post you wrote, or just reply to something you said. I often check the person's profile to see if they might be interesting to follow, and indeed, some people i enjoy following have been added to my list that way.
  • You can get into really interesting discussions merely by replying to other people's tweets or by asking a question or making a statement. It's a pretty easy way to get some other perspectives on certain topics.
  • You can sort of take the pulse of the community. When something happens (like say, a big company cutting the funding for a popular project or a big company releasing yet another train-wreck) you'll immediately know how a lot of people feel about that.
  • It's fun! If you follow the right people, tweets can range from insightful, to thought-provoking, to funny, to downright hilarious.
  • It's asynchronous communication so you spend time on it when you want to, instead of being interrupted by it (though that might depend based on the notification settings of your particular client). I'm involved in a conversation with 2 people right now, but that's not preventing me from doing something productive (though you could argue that writing posts like this is hardly productive, but hey, it could've been a productive post as well! :p).

Dislikes:

  • People can, and will, talk about anything. Sometimes that's good, sometimes it's bad. I've unfollowed a couple of people merely because they talk about politics or religion (or worse: both) too much. Which is too bad because they do have interesting things to say about technical stuff. Obviously, what you want to read on Twitter varies from person to person, and i'm sure people have unfollowed me for not liking the things i talk about as well. I try to restrict my tweets to technical/development topics, but occasionally there will be something else in there. I generally follow (and keep following) people who stick to those same topics.
  • The 140 character limit can be pretty frustrating. For regular tweets, it's usually enough but once you get into a conversation it can quickly be a bother. Especially if multiple people are involved because repeating their account names takes up a lot of your 140 characters.
  • I wish Twitter would store which Tweets you've already read, or which ones have already been retrieved by your Twitter client(s). I guess i'm in the minority here, but i actually like to go over all of them to make sure i didn't miss anything good. I guess very few people use Twitter this way, but it would definitely make things easier for people who use it like i use it. For instance, i have a twitter client on my iPhone, one on my Mac at home and another on my Windows PC at work. Each of those clients will show tweets that i've read in at least one of the other clients already and i have to manually look for the ones i haven't read yet. It's not a big issue obviously, just a minor inconvenience i guess.
  • As interesting as some discussions are, some of them aren't. Even worse, some of them are simply annoying and as far as i know, there's no way to tune out of a conversation if you're following both (or more) of the people involved. This luckily doesn't happen frequently, but when it does it would be nice to have some kind of "hide this conversation" button

It's obviously quite possible that some of the dislikes i mentioned are due to my noobness so if anyone has any tips regarding those issues, i'd love to hear them :)

« Older EntriesNewer Entries »

Meta

Recent Posts

Categories

Archives