Thursday, March 09, 2006
Project "Vanilla DAL" On Sourceforge.Net
Hey, the Vanilla DAL project has been approved by sourceforge.net. The project can be found at http://sourceforge.net/projects/vanilla-dal/, there is also a first draft document explaining "Motivation and Strategy".
Wednesday, March 08, 2006
Announcing Project "Vanilla DAL"
I just filed in my first open source project for hosting at sourceforge.net. Project review is still pending, so there is no official site yet, but I guess I can already post my proposal in here:
Vanilla DAL is a data access framework on top of ADO.NET. It aims to simplify the developer's job when accessing relational database systems by providing the following functionality:
So far all I have is this idea, and about one to two hours of spare time during weekdays for pursuing the project. My baby-son goes to bed around 8pm, so afterwards I can get going - I have done a lot of tech research during the night lately, but it's starting to be a little bit tiring, and want to get my hands on coding some stuff that grabbed my interest for quite a while already.
More on Vanilla DAL during the next weeks...
Vanilla DAL is a data access framework on top of ADO.NET. It aims to simplify the developer's job when accessing relational database systems by providing the following functionality:
- Structured organization of SQL statements within XML-files (as opposed to the way Visual Studio's query builder generates SQL code).
- Convenience implementations for recurring tasks.
- Wrapping database-specific components, hence laying the groundwork for database independence.
- Object-relational mapping of typed datasets and database tables.
- Automated optimistic locking facility.
- A simple mechanism for propagating transaction context through data access methods.
So far all I have is this idea, and about one to two hours of spare time during weekdays for pursuing the project. My baby-son goes to bed around 8pm, so afterwards I can get going - I have done a lot of tech research during the night lately, but it's starting to be a little bit tiring, and want to get my hands on coding some stuff that grabbed my interest for quite a while already.
More on Vanilla DAL during the next weeks...
Monday, March 06, 2006
What Makes A Great Programmer
Steve McConnell (via Jeff Attwood's blog):
The intense inwardness of programming makes personal character especially important.
[...]
Your employer can't force you to be a good programmer; a lot of times your employer isn't even in a position to judge whether you're good. If you want to be great, you're responsible for making yourself great. It's a matter of your personal character.
Let's face it, programming is difficult - that is, unless you are a coding god of the likes of James Gosling or Linus Torvalds. The rest of us surely have delivered some really bad code once in a while. The step we have to take is to acknowledge our limitations and strive to get better. This takes some guts, especially as many programmers have strong egos. Edsger Dijkstra described that phenomenon more than thirty years ago in his classic paper "The Humble Programmer".
What also stroke me often during my professional career is the huge discrepancy in work productiveness and quality between the best and the worst programmers. I mean their job descriptions might look quite similar, but their qualification differs like a brain surgeon's does from a caregiver's. No offense intended here, I admire what caregivers are doing, but still you wouldn't let them operate your brain, right? But each day and at many places, I can assure you, software layman are doing software surgery, and of course they screw up. And they are doing so because they think they are surgeons, when they are not - which at the same time prevents them from improving.
It partly has to do with our industry's education system. Some developers have been hacking away since their early teenage days, some others have attended a six-week-now-I-become-a-web-designer-course. And many employers don't care a lot. The novice might cost them half, and the fact that he is just going to produce one tenth of the value is unconceivable for most managers. In other areas, the apprentice would never be allowed to touch stuff that only a master craftsman can handle. In the software business there are no such restrictions.
At the same time formal education is no guarantee either. I have seen graduates from my university produce great stuff, and others who were horrible coders. Some of the best developers I know don't even have a degree. On the other hand there are graduates who think they have seen it all, which is exactly their problem.
It's hard to separate the wheat from the chaff up-front. Jeff Atwood has a point when he says:
When interviewing candidates for programming positions, I always look for someone who is brave enough to say "I don't know" when they need to. Candidates who can't or won't do this get red flagged; those types of programmers are dangerous. "Can-do" attitudes have a superficial allure, but they're actually poison in our field.
I might add that letting interviewees do some life coding should be a must - unfortunately this is hardly ever practiced.
The intense inwardness of programming makes personal character especially important.
[...]
Your employer can't force you to be a good programmer; a lot of times your employer isn't even in a position to judge whether you're good. If you want to be great, you're responsible for making yourself great. It's a matter of your personal character.
Let's face it, programming is difficult - that is, unless you are a coding god of the likes of James Gosling or Linus Torvalds. The rest of us surely have delivered some really bad code once in a while. The step we have to take is to acknowledge our limitations and strive to get better. This takes some guts, especially as many programmers have strong egos. Edsger Dijkstra described that phenomenon more than thirty years ago in his classic paper "The Humble Programmer".
What also stroke me often during my professional career is the huge discrepancy in work productiveness and quality between the best and the worst programmers. I mean their job descriptions might look quite similar, but their qualification differs like a brain surgeon's does from a caregiver's. No offense intended here, I admire what caregivers are doing, but still you wouldn't let them operate your brain, right? But each day and at many places, I can assure you, software layman are doing software surgery, and of course they screw up. And they are doing so because they think they are surgeons, when they are not - which at the same time prevents them from improving.
It partly has to do with our industry's education system. Some developers have been hacking away since their early teenage days, some others have attended a six-week-now-I-become-a-web-designer-course. And many employers don't care a lot. The novice might cost them half, and the fact that he is just going to produce one tenth of the value is unconceivable for most managers. In other areas, the apprentice would never be allowed to touch stuff that only a master craftsman can handle. In the software business there are no such restrictions.
At the same time formal education is no guarantee either. I have seen graduates from my university produce great stuff, and others who were horrible coders. Some of the best developers I know don't even have a degree. On the other hand there are graduates who think they have seen it all, which is exactly their problem.
It's hard to separate the wheat from the chaff up-front. Jeff Atwood has a point when he says:
When interviewing candidates for programming positions, I always look for someone who is brave enough to say "I don't know" when they need to. Candidates who can't or won't do this get red flagged; those types of programmers are dangerous. "Can-do" attitudes have a superficial allure, but they're actually poison in our field.
I might add that letting interviewees do some life coding should be a must - unfortunately this is hardly ever practiced.
Sunday, February 26, 2006
Christian Nagel On .NET Enterprise Services
The Upperaustrian .NET Usergroup has another interesting event coming up: Christian Nagel will be talking about .NET Enterprise Services this Wednesday. Don't miss it!
Friday, February 24, 2006
.NET Rocks TV
Cool, one of my favorite podcasts, ".NET Rocks", is now complemented by its own videocast ".NET Rocks TV". Some topics such as "Databinding in .NET 2.0" or "ASP.NET Webcontrols" simply require screen captures for through understanding. Video downloads are available via BitTorrent.
Wednesday, February 15, 2006
Borland Dumps Delphi And JBuilder
In other news, and somehow connected to my previous posting: Borland bows out of the IDE business altogether. So it's farewell to Delphi and JBuilder. Reminds me that I heard that a local software vendor was about to revamp its flagship product using Delphi.NET. I considered that a weird choice back then, and it looks even worse today.
Well, it also makes me wonder what will be left of Borland. IDEs are a commodity today (see Eclipse or NetBeans), and even Microsoft is giving away Visual Studio 2005 Express Edition for free. Borland's press release states that they are going to concentrate on Application Lifecycle Management Solutions instead. Good idea after all, as many decision makers in large corporations enjoy buying this kind of stuff for hundreds of thousands of dollars (just to find out later they are trapped in a typical vendor-lockin, so no way to get rid of it even when there are better suited solutions available at a fraction of the original costs).
I still remember the good old days of Turbo Pascal under CP/M and DOS. Turbo Pascal was unbeatable at the time, both in compiler speed and IDE featureset and usability. That was the time when Borland was about the same size as Microsoft, and Philippe Kahn's success in developer tools really bothered Bill Gates (see the "Delete Philippe"- and "Stick it to Philippe"-incidents). The story goes that Bill Gates even dated Kahn's ex-wife... oh well.
Well, it also makes me wonder what will be left of Borland. IDEs are a commodity today (see Eclipse or NetBeans), and even Microsoft is giving away Visual Studio 2005 Express Edition for free. Borland's press release states that they are going to concentrate on Application Lifecycle Management Solutions instead. Good idea after all, as many decision makers in large corporations enjoy buying this kind of stuff for hundreds of thousands of dollars (just to find out later they are trapped in a typical vendor-lockin, so no way to get rid of it even when there are better suited solutions available at a fraction of the original costs).
I still remember the good old days of Turbo Pascal under CP/M and DOS. Turbo Pascal was unbeatable at the time, both in compiler speed and IDE featureset and usability. That was the time when Borland was about the same size as Microsoft, and Philippe Kahn's success in developer tools really bothered Bill Gates (see the "Delete Philippe"- and "Stick it to Philippe"-incidents). The story goes that Bill Gates even dated Kahn's ex-wife... oh well.
Tuesday, February 14, 2006
Java Studio Creator
Over the last ten years, I have worked with a couple of Java IDEs, namely (in consecutive order):
For one reason or another and although it had been one my radar for quite a while, it wasn't until some weeks ago that I took a closer look at Sun's NetBeans platform resp. Sun Java Studio Creator, which is built on top of NetBeans. And what I have seen so far is quite astonishing.
Great toolset, lots of RAD features, refactoring, J2EE at a breeze (Java Server Faces come to full strength with this IDE). Creator's main focus lies in the web development area, but NetBeans and Creator also include the best Java rich client UI designer I have ever seen, namely Matisse. As a sidenote, with Creator I really have hopes for the return of Swing for desktop applications. I was always very fond of the Swing API, and the native Look&Feels have gotten much better over the years. Swing always was brandmarked as being slow, which might have been true when it was introduced - but believe me, if it feels clunky today, that's the fault of the application programmer.
For a quick intro you might want to check out Java Studio Creator 2 in Action. And by the way, Sun gives away Creator for free!
- Symantec Cafe
- Symantec Visual Cafe
- IBM Visual Age For Java
- Sun Forte
- Borland JBuilder
- Eclipse
- IBM Websphere Studio Application Developer
For one reason or another and although it had been one my radar for quite a while, it wasn't until some weeks ago that I took a closer look at Sun's NetBeans platform resp. Sun Java Studio Creator, which is built on top of NetBeans. And what I have seen so far is quite astonishing.
Great toolset, lots of RAD features, refactoring, J2EE at a breeze (Java Server Faces come to full strength with this IDE). Creator's main focus lies in the web development area, but NetBeans and Creator also include the best Java rich client UI designer I have ever seen, namely Matisse. As a sidenote, with Creator I really have hopes for the return of Swing for desktop applications. I was always very fond of the Swing API, and the native Look&Feels have gotten much better over the years. Swing always was brandmarked as being slow, which might have been true when it was introduced - but believe me, if it feels clunky today, that's the fault of the application programmer.
For a quick intro you might want to check out Java Studio Creator 2 in Action. And by the way, Sun gives away Creator for free!
Friday, January 27, 2006
ITunes
Stanford on iTunes - subscribed!
BTW, it seems as if the latest iTunes 6.0.2 client for Windows solves that annoying flickering-when-dragging-the-scrollbar-bubble-issue - just in case someone encountered the same problem.
Update: I had rejoiced too soon - flickering still happens... :-(
BTW, it seems as if the latest iTunes 6.0.2 client for Windows solves that annoying flickering-when-dragging-the-scrollbar-bubble-issue - just in case someone encountered the same problem.
Update: I had rejoiced too soon - flickering still happens... :-(
Monday, January 23, 2006
JetBrains ReSharper
If you - just like me - are in the unfortunate situation that you cannot migrate all your Visual Studio 2003 projects to Visual Studio 2005 yet, and grow increasingly jealous about those cool new VS 2005 productivity enhancements like improved IntelliSense, refactoring or code snippets, there is a remedy: JetBrains ReSharper. It comes equipped with a rich set of features, such as intelligent coding assistance, on-the-fly error highlighting and quick error correction, support for code refactoring, and a whole lot more. We have been using it under VS 2003 for a while, and it has saved us tons of time.
Disclaimer: I am by no means affiliated with JetBrains.
Disclaimer: I am by no means affiliated with JetBrains.
Wednesday, January 18, 2006
Spamusement
Poorly-drawn cartoons inspired by actual spam subject lines.
Thursday, January 12, 2006
The Perils Of JavaSchools
Just a little follow-up to my posting about Joel Spolsky's "The Perils Of JavaSchools". Please don't get me wrong, I enjoy very much coding in Java (even more than in C#), my only point was (and also Joel's, I think) that students who have been taught programming solely in Java are missing some important concepts about how things work under the hoods. And the knowledge about how lower-level stuff is being done is very important in order to be able to build high-quality software systems on other platforms, such as C or C++. Just learning a new language syntax will not be sufficient in those cases.
.NET User Group Upperaustria
I figured out a little bit too late that the "Upperaustrian .NET User Group" has been formed already back in November. Next week Tuesday their third meeting will take place at the University of Linz, including a presentation about "ASP.NET 2.0 and Web Parts". Definitely a good reason to go there and check it out.
Sunday, January 08, 2006
Friday, January 06, 2006
Startup Or Corporate Group?
Which place is more likely to bring out the best in talented and motivated developers, small startups or large corporate groups? Well, it's a double-edged sword.
Usually at startups, the environment is more challenging. Stakes are high, but so can be the gains. No politics, no messing around, just one mutual goal. There is no place for dorks to hide. They are either not hired at all, or identified within days. A great working experience if the right kind of people get together. But then still nine out of ten startups fail (the number varies depending on the definition of "failure"), so it's quite likely that all those efforts are lost.
With big companies, this is less likely to happen. Heck, they even back doomed projects for years. This doesn't necessary imply that they are going support a winner project accordingly either, but at least it increases the chances they will. Unfortunately working in large companies can be cumbersome, especially for the more gifted employees. Committees that are unable to make decisions, projects stuck in the conceptual stage for years, proteges and "know-it-alls" meddling with your venture, and if there is no management buy-in, you are going to fail no matter how hard you try.
So what's the best place to work at? It might be a combination of both. A startup-like department or subsidiary inside a large organization. That alone is not enough, you have to be able to attract highly-qualified people, your management has to trust you and give you the time you need, and of course you still have get the job done. Then this is a likely scenario for joy of work and project success.
Usually at startups, the environment is more challenging. Stakes are high, but so can be the gains. No politics, no messing around, just one mutual goal. There is no place for dorks to hide. They are either not hired at all, or identified within days. A great working experience if the right kind of people get together. But then still nine out of ten startups fail (the number varies depending on the definition of "failure"), so it's quite likely that all those efforts are lost.
With big companies, this is less likely to happen. Heck, they even back doomed projects for years. This doesn't necessary imply that they are going support a winner project accordingly either, but at least it increases the chances they will. Unfortunately working in large companies can be cumbersome, especially for the more gifted employees. Committees that are unable to make decisions, projects stuck in the conceptual stage for years, proteges and "know-it-alls" meddling with your venture, and if there is no management buy-in, you are going to fail no matter how hard you try.
So what's the best place to work at? It might be a combination of both. A startup-like department or subsidiary inside a large organization. That alone is not enough, you have to be able to attract highly-qualified people, your management has to trust you and give you the time you need, and of course you still have get the job done. Then this is a likely scenario for joy of work and project success.
Sunday, January 01, 2006
Ineffective Development Practices
Via Günter Obiltschnig's Weblog: Steve McConnell lists 36 ineffective development practices in his classic book "Rapid Development" (I certainly got a copy of "Rapid Development" on my bookshelf, just like "Code Complete" and "Software Project Survival Guide")
People-Related Mistakes
#1: Undermined motivation
#2: Weak personnel
#3: Uncontrolled problem employees
#4: Heroics
#5: Adding people to a late project
#6: Noisy, crowded offices
#7: Friction between developers and customers
#8: Unrealistic expectations
#9: Lack of effective project sponsorship
#10: Lack of stakeholder buy-in
#11: Lack of user input
#12: Politics placed over substance
#13: Wishful thinking
Process-Related Mistakes
#14: Overly optimistic schedules
#15: Insufficient risk management
#16: Contractor failure
#17: Insufficient planning
#18: Abandonment of planning under pressure
#19: Wasted time during the fuzzy front end
#20: Shortchanged upstream activities
#21: Inadequate design
#22: Shortchanged quality assurance
#23: Insufficient management controls
#24: Premature or too frequent convergence
#25: Omitting necessary tasks from estimates
#26: Planning to catch up later
#27: Code-like-hell programming
Product-Related Mistakes
#28: Requirements gold-plating
#29: Feature creep
#30: Developer gold-plating
#31: Push me, pull me negotiation
#32: Research-oriented development
Technology-Related Mistakes
#33: Silver-bullet syndrome
#34: Overestimated savings from new tools or methods
#35: Switching tools in the middle of a project
#36: Lack of automated source-code control
People-Related Mistakes
#1: Undermined motivation
#2: Weak personnel
#3: Uncontrolled problem employees
#4: Heroics
#5: Adding people to a late project
#6: Noisy, crowded offices
#7: Friction between developers and customers
#8: Unrealistic expectations
#9: Lack of effective project sponsorship
#10: Lack of stakeholder buy-in
#11: Lack of user input
#12: Politics placed over substance
#13: Wishful thinking
Process-Related Mistakes
#14: Overly optimistic schedules
#15: Insufficient risk management
#16: Contractor failure
#17: Insufficient planning
#18: Abandonment of planning under pressure
#19: Wasted time during the fuzzy front end
#20: Shortchanged upstream activities
#21: Inadequate design
#22: Shortchanged quality assurance
#23: Insufficient management controls
#24: Premature or too frequent convergence
#25: Omitting necessary tasks from estimates
#26: Planning to catch up later
#27: Code-like-hell programming
Product-Related Mistakes
#28: Requirements gold-plating
#29: Feature creep
#30: Developer gold-plating
#31: Push me, pull me negotiation
#32: Research-oriented development
Technology-Related Mistakes
#33: Silver-bullet syndrome
#34: Overestimated savings from new tools or methods
#35: Switching tools in the middle of a project
#36: Lack of automated source-code control
Subscribe to:
Comments (Atom)