As of tomorrow I'll be deleting the feed: http://feeds.feedburner.com/Atozed.

The feed for my blog is http://feeds.feedburner.com/hadihariri

If you're subscribed via http://feeds.feedburner.com/hadihariri/rSpO , it will still continue to work, but I recommend you change it to the main one.

Please make sure you update.

And Happy Festive Seasons!

marc recently made a blog post regarding the world not revolving around Delphi, and in particular DelphiFeeds. My blog goes through a sophisticated Yahoo piping system to filter only Delphi related things, so that only posts that actually have words like Delphi, Borland, CodeGear, Embarcadero, etc.. come through the pipe (the reason for using Yahoo pipes was that I previously didn't have support for tags on my blog engine).

Reading marc's post, I recalled some comments the guys that run Delphifeeds made. They said they receive hate-mails if too many blogs posts are made that are off-topic.

Now here's the thing. First off, even if it wasn't exactly hate-mail, sending messages to someone that runs a feed site or posting comments on people's blog complaining that posts are off-topic shows plain arrogance. It's not your site, it's not your feeds and it's not your blog. Don't like it, well unsubscribe. Nobody owes you anything.

What's worse though is that many people don't seem to understand that Delphi is just a tool, it's an IDE and a language. Programming is a whole lot more than that. There are topics such as design, architecture, good practices, team work, and other frameworks (some could add value to your tool of choice, be it Delphi, Visual Studio, Ruby), etc. Just because there is no specific mention of Delphi in a post shouldn't automatically be considered off-topic or of no interest.

You subscribe to blogs that interest you because the content is interesting. You're not subscribing to an automated content-generation system. You're subscribing to a guy that's writing this content. Maybe that guy has something interesting to say that is not directly related to xxxxx (again, insert tool of choice here).

P.S.: This post should make it on Delphifeeds since I've mentioned the word Delphi a couple of times. If you are interested in other things, subscribe to my site directly. That way my posts aren't "censored". 

I'll be doing a talk in Belgium next month at the Visual Studio User Group, where I'll be covering topics such as Separation of Concerns, Single Responsibility, Interface Segregation, Dependency Injection and Inversion of Control, along with examples of IoC containers. There's limited space (90) and already 55 signed up, so if you're in or around the neighbourhood, got nothing better to do than here my brag, come along. I think they are organizing a geek dinner afterwards so it should be fun. Although the talk will be in C#, the important things to grasp are the concepts, not the language, be it Visual Basic, Delphi or whatever else (obviously it needs to be a OO language).

Sometime ago I posted an entry about some comments Michael Swindell had made about how Delphi was a better choice for enterprises because of it's speed. Marco followed-up to that post with another one yesterday about how really .NET vs Win32 speed is not relevant, but what is relevant is being able to upgrade your application to the latest compiler, that same application written in Delphi 2.

I was going to comment on his blog, but since it turned out long, I've made it a blog post. Now here's the thing. My original blog post wasn't about Delphi vs Visual Studio/C#/VB or CodeGear vs Microsoft. My point was that it's not all about performance. It might matter for intensive calculations and processing, but in general, it is not the case for the vast majority of Enterprise (or non-Enterprise for that matter) applications, specially when the real bottleneck is the database back-end and/or network.

Now Marco's post has somehow hooked into stability and reliability. These are broad terms which can be applied to many different aspects of an application and it's lifecycle. More than the actual scalability and up-time of the system, I think Marco's post is mostly referring to backwards compatibility.

One of the other points he brings up is how certain technologies have been dropped or are not backwards compatible. As for things being dropped, I think it's fair to say all companies do it. Even CodeGear has done it. Should I forget all the investment my company made in Internet Express? What about those poor people that invested in WebSnap? Not to mention Kylix or the recent VCL.NET.  In the case of Linq To Sql, it was pretty clear that this was a mid-term solution until they had something shippable with Entity Framework, and just like everything, if you took the necessary protection, it wouldn't hit you so hard. 

In regard to backwards compatibility, I couldn't agree more. You need to try and sustain compatibility as much as possible. However, there are times when it's near to impossible and you have to cut some ropes for the "greater good". Sometimes it's not viable to allow for new functionality and/or features without making sacrifices. We had this many times on Indy.

He also mentions how continuously new technology comes out from Microsoft. Well here's the deal. Microsoft is a company. Just like most of us they are here to make money . They push out new technology because among other things, it generates revenue and obviously there seems to be a demand for it. It's the same as us, as developers. When working on a product we tend to continuously innovate and create new features for our end customer. Why? To try and improve their experience, to try and make it easier for them, but ultimately to also generate revenue.

At the end of the day, if you're on the bleeding edge, don't be surprised if sometimes you cut yourself. That's where you need to apply judgement and valuate the risks involved, both for yourself and your business. Nobody forces anything down your throat. You're free to continue using what you were using 5 years ago. ADO.NET still works today. All new technology is still built on top of it. You just won't get the added-value if you don't "upgrade".

Barry Kelly (who btw, looks nothing like his photo in real life) has made a nice post about how to have "managed" pointers in Delphi Win32. This makes dependency injection so much more easier, not having to worry about freeing objects. The only thing lacking is an IoC Container now!

Well Marco's probably been the first one to blog about it. My only comments are:

a) Change the name. PRISM is already a pretty well-known project in the Microsoft camp, also known as Composite Application Library for WPF/Silverlight

b) Two years ago I said at a session at TechEd that going down the VCL.NET route is a mistake because of the lack of roadmap and support from third-parties. I received a lot of feedback (i.e. read hate mail). Ironic...

I was just reading on a blog a reference to an article Michael Swindell published about native application development. It's fair to say that you don't always have to agree with everything someone writes, but I think in this particular case, there is misleading information.

The story of the .NET framework lagging behind native performance just doesn't cut it anymore. Wake up and smell the coffee. We are three versions into the .NET framework and Microsoft is already talking about 4.0. While we are seeing new things that will make applications and architectures more flexible and easier to maintain (such as dynamic binding), Delphi developers are still complaining about the garbage collector.

This might come as a shock to you, but in a business application, your end customer is not going to know how long it took him to destroy that order object, or to create it for that matter. He cares about his application. He cares about interoperability. He cares about his ROI. With all that the .NET Framework (or Java for that matter) has to offer in terms of productivity to the programmer, with all the frameworks that exists to make application development easier to maintain, the native vs interpreted performance argument doesn't stand anymore.

I'm not saying that native is bad, far from it. Right now, and for the foreseeable future, there is a place for native code, just as the article points out, something needs to be under that virtual machine or the RIA. Until all computer systems (excluding my mother, she's already on .NET 3.5) have the .NET framework installed, there will be room for small utilities to run natively. But enterprise level or businesses do not have an issue with making use of applications that use the .NET framework. They don't have an issue with deployment. You can still automate and accomplish easy deployment with .NET (and I'm not even talking about ClickOnce).

Every day we have faster processors coming out, we have cheaper memory and yet 6 years after the release of .NET we are still clinging on how native out-performs managed. They say you shouldn't dismiss something without having really tried it. Unfortunately that's something I see a lot in the Delphi community.

I was just reading through some of the comments on Anders'  blog in response to his post on positive feedback on Delphi 2009, and I came across this comment:

...Honestly Nick, I think in the day to day win32 programming world, I can’t think of any reasons for using anonymous methods or generics. ...

It's hard to understand the power of anonymous methods if you haven't used them for a bit and truly see the beauty of them and how they can make your apps so much more flexible and easier to write and maintain. But Generics? You find no use for generics? That's unreal.  Again, I think a lot of this is coming from the drag-n-drop culture and not truly using object orientated programming (I don't mean that as an insult to anyone, let alone the person that posted that comment)

In all honesty, I think with all the new features Delphi 2009 has in comparison to 2007, it is well worth it.

I was reading a comment in reply to this post on DelphiExtreme, by Ken Knopfli, and I quote:

Delphi programmers tend to be old experienced hands, have seen it all before, and can see hype for what it is.

Most of us have years of experience and have developed our own way of working. A young chap here is a big fan of D/NUnit and now we have two people that do nothing but create and maintain unit tests. Uh huh.

My customers want results and don’t care if I am “behind the times".

I think it's sad and wrong to think like that. We've all used RAD tools for many years, be it Delphi, Visual Basic or Visual Studio. Used like demoware they have one fundamental flaw, they create unmaintainable solutions in more ways than one. Agile practices, among other things, are about trying to prevent that.

Unit testing is not only about testing your code in isolation. It's about regression testing. Creating unit tests allows you to test your code anytime you introduce a change, be it a bug fix, be it a new feature. Unit Testing is about documentation. It's about letting a new member of your team understand the specs of the application one step at a time. Unit test can be and many times is (TDD) about design.

Separation of concerns, single responsibility, loose coupling are not buzzwords. They are fundamental design principles that can save you in the long and short term.

In reference to Lex's comment, I'll be doing talks both at SDC and at EKon (European CodeGear) about these topics, so if you're in Europe and interested, might be worthwhile coming. In any case, these are principles that can be taught irrelevant of the language, be it Delphi, C#, Lisp or Smalltalk. It's about good object orientated programming, it's not about a platform or an environment. Let's stop being the children of the drag'n'drop era.

I've moved my blog to a new engine. If you're subscribed to my blog using Feedburner, which you should be :), then nothing has changed. If you're subscribed directly, then please update your feed to use Feedburner

I'll gradually port all the old entries to this new engine, but for now you can find them at:

Tech Blog

Delphi Blog (deprecated sometime ago and merged with the previous, now this one)

If you were subscribed via www.delphifeeds.com and you're still interested in my non-Delphi related stuff I suggest you subscribe to Feedburner because Delphifeeds filters posts and only allows things with certain keywords through (i.e. Delphi, CodeGear, etc.)