Monday 29 December 2008

The Hypothetical just became Categorical

My last post was about Microsoft’s Bizspark program. When I started that post, it’s entire premise was built on the hypothesis that I would want to start a Micro ISV. As I wrote more and more of it, I kept saying to myself, why not? Give it a go? You’ve got no excuse now.

Now don’t get me wrong, it wasn’t just the cost of Delphi that kept the idea just that, an idea. There are other things, but the fear of failure is a really strong deterrent. I guess that fear is still there, but if I do fail, I won’t have spent a few thousand Dollars/Euros/Pounds setting up my development environment.

I’ve got a few ideas for products. Some of them pretty good. I figure whatever I do, I’ll be learning, and that’s always a good thing. So I signed up for Bizspark. I thought I’d have to go through hoops. I thought it would be hard. In fact it was really easy. I just found a partner willing to back me, and I’m in, I’m now a Bizspark member.

I’m slipping slowly away from my Pascal roots. It does hurt, but I have to follow my head and not my heart. At work we are moving away from Delphi, I’ve got to keep up, and start thinking more like a .NET developer, and less like a Delphi one.

A few of the comments to my previous post, said forget licenses, use a pirate copy of Delphi 2009. Well, that just doesn’t feel right to me. Ironically though, Codegear get no money from those pirates, but they get no money from those of us who just can’t afford the price of their product either. Nobody wins.

I’m sure I’ll be using Delphi for a few more years to come (First smile since the start of this post). It’s what I’m paid to do. But the decision has been made at work. Sooner or later I’ll be doing C# full time.

Friday 26 December 2008

Bizspark – Where’s Embarcadero’s equivalent?

Let’s imagine a hypothetical situation. It’s hypothetical because I’m just speculating, but it’s one that could happen, and I’m sure happens all the time.

Right, I’m a Delphi developer. I’ve been working 9-5 for the boss for a long time. I have had a great idea for a product, and would like to try and develop that product independently, and market it. Being a Delphi developer, I naturally would like to develop that product in Delphi. Makes sense. Ok, so what do I need? I have a pc (or 3), so I now need the IDE. Ok so what are my options? I’d like the latest, and greatest. No point in making my mouth water with features such as Generics and Anonymous methods and expect me to settle for less. So  I go to the Codegear (UK) website, and check out the prices. WOW. £979 excluding VAT (currently 15%). I may be able to get a better deal somewhere, but it’s not going to be much cheaper. My product idea is great and all that, but you never know. I need to keep my costs down, and £979 (don’t forget the VAT) is a lot of money for something which may or may not succeed. There’s no such thing as a free lunch you say!

Well maybe there is. Let’s look at the competition. In particular Microsoft. Microsoft have what they call Bizspark. Basically, they’ll give you a whole load of their products, for free if you are a startup. If your revenues are less than a million dollars a year, and you’ve been in business for less than three years that is. Well, if my product starts making a million a year, then I wouldn’t mind paying £979, but right now that’s a little too much. So if I choose to use C# instead of Delphi, I can save myself £979. Actually it’s a lot more than that, because not only do I get Visual Studio, but I also get a whole lot more than that. In fact it will cost me a simple $100 after 3 years. I’ll have tried my product idea with little or no risk, and Microsoft have gained a developer for a cost of $100 to them. By giving me thousands of dollars worth of software for a measly $100, they haven’t lost any sales, because I would never have bought them in the first place.

I mean forget Bizspark. If I really want I can go and download Visual C# Express, and use SQL Server Express as my backend. That’s more than enough for my product. What has Codegear to offer? Turbo Delphi? That’s Delphi 2005 I think. Whatever it is, it’s not Delphi 2009. What about Prism? Do they have a Delphi Prism Express? Nope, not that I can see. Not much of a decision really, is it? I’m a Delphi developer, but C# holds absolutely no fears for me. Codegear have just lost another developer. More importantly, maybe my product idea is a success. Maybe in a year’s time I need to employ a few developers. Codegear have just lost a few more developers. Ok, my product is now really successful. I can afford the £979 for each of my 10 developers. Am I going to switch? Somehow I doubt it?

So Delphi, which used to be the obvious choice for your one man startups, is no longer a viable option. It has always been expensive, but when compared to the opposition, it was still value for money. It no longer is. How much of Codegear’s sales are Delphi 2005/2006/2007 shops upgrading to the latest, and how much are new developers? Or old developers branching out? My guess is that it’s very close to 100% Delphi shops looking to go to the latest offering.

If by some chance, Codegear do have some Bizspark equivalent, well done, but if that’s the case, then it’s very well hidden. I appreciate that Microsoft can afford to give away their products. Can Codegear afford not too?

Monday 22 December 2008

Program Structure – Code Folding

You know how in Delphi 2005 (could have been Delphi 8, but who actually used that?) Object Pascal was introduced to the world of code folding. Code folding, is where the IDE lets you hide certain parts of your code. Either it automatically chooses certain areas, or you can add further areas of your own.

Great, we all said. We have the same feature they have in C# and Visual Studio. Honestly though, have you ever used it in Delphi? I did initially, just because it was there, but I soon realised I just didn’t need it. Object Pascal with it’s interface and implementation sections allows you to look at a class’s declaration, and understand what it does at a glance. C# on the other hand, mingles the declaration with the implementation, which makes classes unreadable if they get above a certain size.

You can look at this from two angles.

  1. Object Pascal, while verbose is much more readable. With things like class completion and jumping between method declarations and implementation, the verbosity is not that big a deal, and anyway, I’d rather type a little more code if it makes it more readable.
  2. C# encourages you to make classes small. That’s a good thing. With Object Pascal, you can create very large classes, and still maintain readability, whereas with C#, you are forced early on to keep classes small.

So I guess the conclusion I came up with is that code folding is bad. If you need to fold code to make it readable, then your classes are probably too big. If you ignore code folding, C# actually may have an advantage here, because you are forced to some extent to keep classes small, whilst Object Pascal encourages (or at least doesn’t penalise) you to use large classes.

I think I’m going to call it a draw!

Sunday 21 December 2008

Do I really need to be a touch Typist?

I’ve just read Lars blog post regarding programmers and touch typing. I’ve been meaning to write about this for a while as I’ve read quite a few blog posts and heard quite a few podcasts where programmers insist that touch typing is a must have skill for programmers. Now, before I comment, I have to stress that I’m not a touch typist in the true sense, in that I do not use all my fingers. I probably use around 2 or 3 fingers per hand. My speed is around 70-80 wpm and I only occasionally need to look at the keyboard.

Now for the controversial bit. I think that touch typing is not a must for a programmer. So what if you can touch type at 120 words per minute? Can you think that fast? Can you code in your head that fast? Speed of coding has absolutely nothing to do with speed of typing, but rather the speed at which you can solve problems. As I said above, my typing speed, at full tilt, approaches the 80 wpm, but if you were to count the number of words I type in a whole day of coding, and divide it by the number of hours I worked, you’re unlikely to get anything near 80 wpm. That’s because typing is just the end-result of what we do. It’s the bit that communicates what’s in our heads to our machines. It’s not typing which makes us good at what we do, it’s the brain behind it.

When someone says  a programmer must be a touch typist, I assume they are talking about speed. They assume that if you are a touch typist you are fast. And I agree, you are fast. You are fast at typing words. It doesn’t mean you are a fast coder, and it certainly doesn’t mean you are a good coder. It’s a bit like saying an artist must be quick with his brush. Does it make the final painting better?

Lars states that Touch typists are usually able to involve themselves in a discussion about something else, while touch typing. That may be true, but coders need to concentrate. They’re not just typing words, they’re writing code. If you can solve problems whilst whilst holding a discussion with someone about something completely unrelated, then your brain works differently than mine. (Not even women can multi-task where coding is involved!)

(No offence to Lars, I’ve been meaning to write this for a while!)

Thursday 18 December 2008

Delphi Prism – Class Contracts

One of the new features of Delphi Prism, which you may not have heard about is native support for Class Contracts. Class Contracts are Delphi Prism’s implementation of design by contract.

The whole premise of Design by Contract is that components of a software system interact with each other on the basis of mutual obligations (a contract). Therefore a method of any class may :

  • Insist that any client calling the method must adhere to a certain pre-condition.
  • Guarantee a certain post-condition on exit.
  • or will commit to maintain a certain property (Invariants).

Pre-Conditions

A pre-condition frees the method from having to maintain any checking code as it can be certain that the pre-condition will be met. Delphi Prism implements pre-conditions using the require keyword.

method MyClass.ToString(const aIndex : Integer) : string;
require
aIndex >= 0;
begin
result := fStrings[aIndex];
end;


Pre-Conditions are evaluated before the method is executed.


Post-Conditions

A post-condition ensures that the client knows what to expect from the method after it has executed. Delphi Prism implements post-conditions using the keyword ensure.


method MyClass.ToString(const aIndex : Integer) : string;
require
aIndex >= 0;
begin
result := fStrings[aIndex];
ensure
result.Length > 0;
end;


The old scope prefix can be used in the ensure section for local variables and parameters,  and refers to the values as they were before the method executed.


method MyClass.Add(aValue : string);
require
aValue <> ‘’;
begin
fStrings.Add(aValue);
ensure
Count = old Count+1;
end;

The old construct is only supported for integers and value types of both parameters and local variables. The compiler saves the value before execution of the method.


Class Invariants

Class invariants ensure that certain properties or fields of an object comply with a fixed state. Class invariants may be either private or public. We need to be careful here, as the way these work may initially seem counter intuitive. Public invariants, are checked after every public method only. (Actually, after the ensure clause, if it exists), while private invariants, are checked after both public and private methods. Another point to make is that both public and private invariants have access to all fields of the class. The public and private scope modifiers only indicate on which methods the invariants will apply.



  TestClass = public class
private
fValue : Integer;
private invariants
fValue > 0;
public invariants
fValue > 35;
public
//public methods
end;

Since public fields can be accessed from outside the class, they cannot be used in invariants as there is no way to restrict what goes on outside of the class. Having said that, public fields are never advisable anyway, so it’s not that much of a restriction

If any of the contracts above are not upheld, an assertion is raised. Assertions are by default enabled for the debug configuration, and disabled for the release configuration.


The Future

So what could be added in future to make class contracts even more useful than they already are?


  • Pre and Post conditions for interfaces

ITest = interface
method Test(const aValue : Integer) : string; requires aValue >= 0 ensures result <> '';
end;

With this syntax, we not only specify what the implementation must look like, but we also specify how it must behave.


  • Exceptional Post-Conditions

The ability to specify what exceptions a method can/should raise.


method Test; raises System.OverflowException;

  • Frame Conditions

Frame conditions restricts what a method can modify. Sample syntax could look like

  method Test; modifies fValue; 

Conclusion

Class constructs are not one of those features that you cannot live without. You could happily go on writing code and never use them once. However, by adding class contracts to your code, you make it clearer what the class does, and how it does it. Class contracts remove some of the ambiguity and a lot of the guessing. Up until now, we have used method signatures to indicate how class users can go about using our classes. We have also had to document a lot of other information so the user knows what is expected of him/her, and what he/she can expect from the class. With class contracts, a lot of that documentation is now part of the class, and can be checked at run-time to ensure the application is doing what we intended it to do in the first place.

Saturday 13 December 2008

Do all great programmers start young?

I was recently hearing one of the Stackoverflow podcasts, where Jeff and Joel were interviewing Steve Yegge from Google. Jeff mentioned how he started programming at the age of around 13, and how the developers he has the most affinity with are also those who started at around 13, and were largely self-taught. Steve agreed with him (being one of those who started young), and insisted that the best developers are those who start young and are self-taught. And I have to agree! Well I would, since I started at 13 too.

I remember my parents bought us a Texas Instruments TI 99/4A, when we couldn’t find any Sinclair Spectrums (I think they were called Timex in the US) in stock anywhere. It was Christmas 1981, and I was 12 going on 13. The first thing I did when we got the computer home, was to type out one of those game listings you’d find in video game magazines. I’d actually bought the magazine before the computer. After spending a few hours typing it in (my typing skills were non existent then!), I typed in run, and waited. It kind of worked, but the score at the top right hand corner of the screen was not working. Disaster! I must have typed something in wrong. So I roped in my little brother to read me line by line, while I checked for any typos. After another few hours, we finally concluded, that we had typed it in correctly. I don’t know what drove me, but I had to fix it. It was a graphical score, with each digit independent of the others. So with every increase in score, you’d increment the units column, until it were at 9, in which case, you’d set it back to 0, and increment the tens column, and so on and so forth. Seems trivial now, but it took me a few days to figure out TI-BASIC, and fix it. But boy what elation when I ran it, and it finally worked. The subsequent month’s magazine printed the bug-fix, but I had fixed it on my own. I was officially a programmer. Luckily due to a hardware quirk, while my friends played fast machine code games on their Commodore 64s and Spectrums, the TI99/4A had some drab Basic and Extended Basic games available or wildly expensive (well to a 12 year old they were)cartridges. So if you had a TI99/4A, you either learnt to program, or you made friends with the neighbours and their Commodore! I started writing games, and even advertised and sold a few tapes. (storage was on plain old audio tapes) …and so began the love affair with computers.

So when did you start programming?

Friday 12 December 2008

WPF like effects in your Win32 forms

Are you still developing native applications? Would you like to do some cool tricks with your forms? How about making your windows fade in and out?

The Win32 API to the rescue! The function AnimateWindow can be used to blend in and out the form. To the FormShow event handler, add the following code :

AnimateWindow(Self.Handle, 1000, AW_ACTIVATE or AW_BLEND);

To reverse the effect, add the following code to the FormClose event :

AnimateWindow(Self.Handle, 1000, AW_HIDE or AW_BLEND);


You can also get the form to slide in, rather than blend, by changing the flags to AW_SLIDE or AW_HOR_POSITIVE to get the slide to come in from the left for example.



The same approach can be used in Delphi Prism, when using WinForms. While Delphi Win32 imports the AnimateWindow method for you, in windows.pas, in Delphi Prism you have to do it yourself using P/Invoke. (As you would with C# or VB.NET may I add). So in your WinForm, add the following code to the private declaration :



private
const AW_HIDE = $10000;
const AW_ACTIVATE = $20000;
const AW_HOR_POSITIVE = $1;
const AW_HOR_NEGATIVE = $2;
const AW_SLIDE = $40000;
const AW_BLEND = $80000;
[DllImport("user32.dll", CharSet := CharSet.Auto)]
class method AnimateWindow(hwand : IntPtr; dwTime : Integer; dwFlags : Integer) : Integer;external;


Remember to add System.Runtime.InteropServices to the uses clause of your form. Now, you can add the same code as before (it's all object pascal, so the same syntax), to the Load and FormClosing events of your form.



  method MainForm.MainForm_Load(sender: System.Object; e: System.EventArgs);
begin
AnimateWindow(Self.Handle, 1000, AW_ACTIVATE or AW_BLEND);
end;

method MainForm.MainForm_FormClosing(sender: System.Object; e: System.Windows.Forms.FormClosingEventArgs);
begin
AnimateWindow(Self.Handle, 1000, AW_HIDE or AW_BLEND);
end;

So there you have it, forms that fade in and out.

Tuesday 9 December 2008

Virtual Conferences

A few weeks back, I attended quite a few sessions of Emarcadero/Codegear’s Coderage III virtual conference. I’ve been to a few live conferences before, and have always found them very useful. This was my first virtual conference, and I must say I found it was almost as good as the real thing. There were a few audio issues, but nothing too distracting. As with all conferences, be they live or virtual, some of the sessions were great, others not so great, but I suppose that depends on what interests you. On the whole the sessions I attended were well presented, and hit the mark. I’m going to make a few observations though, so that perhaps Coderage IV might be even better.

  • Time Zones. There were a lot of sessions I’d have liked to attend, but at 4 in the morning, I also like to sleep. Now I know however you play this, there’s always going to be someone who’ll complain that 4 in the morning is time they should be in bed, but since the sessions were recorded, why not repeat them twice, even three times so that anyone in any time zone can find a decent timeslot? I know that you can get the replays after the event, but not the same thing..
  • I felt the sessions were slightly too short. Or perhaps the subjects that were covered were just too vast for the time allotted. I’m sure there’ll be someone who says the sessions were too long though.
  • Attendance was a little disappointing. Does that reflect a decline in the popularity of Delphi, or just the fact that a lot of people don;t like virtual conferences? Has anyone ever attended other virtual conferences? If so, how was the attendance there?

Another thing I noticed during this conference. From a technical point of view, being a trainer is much easier than being a day to day developer. I’m not saying the presenters at Coderage did not know their stuff. I’m sure that they do. It’s just that when giving a session of 45 minutes, you are forced to basically present glorified Hello World applications. You just scratch the surface.

I’m just trying to say that the technical side of things, while important (you can’t do a 45 minute session about something you know nothing about), is only a small part of what you need, to be a successful presenter. In my opinion, one of the best presenters I’ve ever had the pleasure of listening to, was Lino Tadros. His sessions, while having the requisite technical knowledge, had that X factor, that made them interesting, whatever the subject covered. The sign of a good teacher.

Does he still do Delphi, or has he completely gone over to the dark side? If so, he’s sorely missed!