Steve Eichert is mad about TDD and I just got the link to the tool for TDD from him. It's the new name for the tool known as NUnitAddIn.
Go get it here.
I've been reading this article on Language Oriented Programming: the next programming paradigm.
The article first describes current problems. One of the biggest problems I think is, as said in the article, that developers can clearly explain to eachother in a matter of minutes, what needs to be build. But building the actual program requires much, much more time. This is the translation from our thoughts into the 'words' or commands of the computer. Once the program has been build, and you (or another developer) tries to understand what is going on after a couple of months, you have to make the translation again, and reverse engineer the program from those computer 'words' into your own head. For this we have comments, documentation, uml models and much more, but you'd have to study a fair amount of time to understand what is going on.
What the article doesn't describe (because it's out of scope) but what frustrates me most of the time, is that there still is no way that from client to developer there is a good way of communication. You've probably all seen the pictures of the swing, where client, developer, management, sales, everyone describes the problem differently. The two final pictures are of what the client finally gets and what the client actually wanted. Every picture is totally different.
I think the biggest problem is communication. Probably everyone agrees, but why don't people do something about it? We've got RUP, which creates many, many documents and a lot of overhead, and it might work some better, but most of the time I still see this fail miserably. Clients can't specifiy their problem or need, the analist can't get that information from the client either, and most of the time they can't describe it either. For example, write a Windows forms based functional document, when we're building a web application.
Anyway, back to the article. Sergey Dmitriev describes his Domain Specific Languages (DSL) which, in best, should be a graphical representation of a language, completely build for a specific domain. This can be database or gui related, but can also be a language build for finance related stuff, or a more specific part of finanance. It's very interesting to read what they've done with PMS already.
Years ago, people talked about the future, where we'd have some sort of building blocks. We could tie them all together and have a complete application, completely (or at least almost) without any customization by the 'developer'. I think this is never really possible. But with DSL, it's a bit different, but probably doable.
But there might be other problems as well. For example, integration is a hot topic currently and lots of (old) systems must be integrated and connected with eachother. A visitor asks the question on how all these languages will integrate, as multiple languages will be needed to build one program. And as not all languages will be build by the same vendor or company, this might be a big issue which must be tackled before we can start building DSLs.
Anyway, the future will bring us a lot of new goodies. I just hope there's enough work for developers. The final result might be that only a few real developers build languages, where those developers must have a deep knowledge of the domain they built the language for. In result, a small department can built programs on those languages and don't need to have a deep understanding of development, like you currently need to build applications.
A topic however I'm going to be reading some more about.
Some keywords in the topic for everyone searching through Google! ;)
There's a bug in FeedReader which results in not being able to change your proxy password. When you're on a domain which makes you change your password every few weeks, that's a bit of a problem. Luckely you can take a look at the source of FeedReader, as it's open source on SourceForge.
If gProperties.ProxyEnabled Then
if gProperties.ProxyPassword = '' then
if gProperties.ProxyUsername <> '' Then
As a result, I tried to remove the password from the .ini file, but that will lock up the application completely. So after removing the complete .ini file (from c:\documents and settings\[username]\Application Data\FeedReader\) I could enter everything again and the popup came up which asked for my password.
Before doing this, I emailed the developers of FeedReader, with the question on how to change my password. If they respond, I'll give them the solution to their problem. ;)
Lately I've read some comments from people all over the internet, on chatty lines. You should try to avoid chatting a lot with your services. Ofcourse you should probably avoid the same with components, but with services you should consider even more that they might be on the other side of the world.
But as I still have a lot of questions about how to define services, I also have questions about how to avoid chatting. It probably comes down to the design and implementation of your project, and no general recommendations can be given. Or at least not very detailed.
But maybe you guys have some ideas yourself, or resources where I can find more info on this.
Give me a call, leave your thoughts or urls in the comments, but give me feedback so I can learn from the great minds you all are. Not?
I have been working on my own website for years! As a true developer, I have never been satified, nor have I ever finished a website. And I don't believe I ever publically announced it was online or anything, so only a few friends of mine new of its existence. Maybe that's one of the reasons I always quitted development on it, because not really anyone comes and visits it, or whatever.
Anyway, on the root of this domain (sphear.demon.nl) I had a page that said a website was coming, with a link to these weblogs. I removed that page and now the website is visible to everyone. It hasn't got much functionality yet, but you can post comments using a pretty cool reaction system and place oneliners. Personally I will be able to add news through a few maintenance screens. Oh, and I hope the reaction system will work. You can post unregistered, but when you register your name isn't usable by anyone else. Go check it out.
Minor detail, it's completely in Dutch! ;)
Visit it here...
Now I only need a new domain, but after years I still don't have a cool name!