|
|
|
|
|
 Monday, 5 April 2004
|
|
I've always been quite interested in extending Delphi using the Open Tools API. My first add-in was back in Delphi 2 days, called CodeQuick. Amazingly, it's still listed on Torry's for all you D2 users out there :-).
Anyway, lately I've been writing a few add-ins for Delphi 8 on flights and in spare moments, the first of which is ready for some more public scrutiny.
FileExplorer is a free add-in for Delphi 8, which provides Explorer-like functionality in a dockable window inside the IDE. There's more info and some screenshots on the project page, along with some ToDo's, but please feel free to grab this version and try it out. Feedback is of course welcome.
|
|
|
In an earlier post, I mentioned the new C++BuilderX 1.5 which, amongst other things, includes a Visual Designer for Symbian apps. Well, we've finally posted the Flash Demo. Well worth a watch before you download the trial version.
Update: More detailed screenshot here
|
|
|
I've been having a lot of fun playing around with the new C++BuilderX 1.5 Mobile Edition.
It was only released in the last couple of days, but one of the big changes in this one over v1.0 is the addition of a Visual Designer for Series 60 applications (the phone-looking thing in the screenshot above is not an emulator, it's actually the Form Designer).
There are normal GUI-type components, but there are also non-visual components for everything from interfacing with BlueTooth, accessing the camera on your phone, the Address Book, etc. Obviously, a Visual Designer is no substitute for synaptic activity, but it does seem to make the whole process more approachable. I had my Hello World Symbian app up and running in an emulator in about 5 minutes, and debugging it on the device via Bluetooth in about 5 more. Now, all I need is a good idea for an app :-)
There's a trial version available here (the Mobile Studio link partway down the page. Mobile Studio includes Java and C++ in the same IDE) and we should have a Flash-based demo available shortly.
|
|
|
Whenever my issue of The Delphi Magazine used to arrive, the first thing I would read was Julian Bucknall's Algorithms column. He's got such a knack for making complicated and oftentimes fairly dry subject matter not only clear, but interesting as well. I learn new things everytime I read his columns, even when I reread them.
Anyway, he stopped writing them awhile back, but today I stumbled across him twice. He's blogging, actually, he's got two blogs. One is on his homepage at www.boyet.com (RSS) and one is over at Falafel (RSS).
|
|
|
We took a bit of a holiday in Seoul at the end of my trip, so I'm just getting back into it.
Before the holiday, however, we had a half day Delphi 8 for .NET event, with just shy of 700 Delphi developers showing up! I'm going to write something up for BDN with some photos.
Anyway, the Borland Korea staff worked like crazy on the event, and I swanned in to do the opening keynote bit and a C#Builder plug (as well as inflict my grasp of Korean on the audience. Needless to say, they were very polite).
As is usually the way, the one who did the least work got the glory, and I ended up in Korea's largest IT newspaper the next day, which earned me many brownie points with my Korean Mother-in-law :-) However, it has raised the bar, as she expects me on TV next time I'm in Korea, another newspaper clipping just won't cut it.
Hmmm, do you think I might be losing my hair?
|
|
|
At the end of April I'll be speaking at the ADUG Symposium on issues around porting Delphi/Win32 apps to Delphi/.NET. I've spoken at Borcon and other conferences with most of these guys before, but never in such a condensed setting. AND I'm at the end of the day. Bloody hell, talk about pressure.
|
|
|
This piece raised some interesting questions for me.
I'm going to try and avoid the obvious response which, as I work for a development tools vendor, you can probably guess.
But I'm wondering at what point do you decide that your tool is doing quite enough thank you very much? I know this will be different for everybody, but why is today's level of abstraction enough, whereas the level we had 5 years ago was not? Why was it OK for dbExpress to abstract out details of dealing with databases, but it's not OK for ECO to take that further?
Is the rise of code-focused features (like refactoring, smarter code templates, code intentions, etc) in IDE's a recognition that giving people more wizards, components and frameworks is not necessarily what they are after? Just give me stuff that lets me bang out code faster?
I was just chatting with someone about this who said that your comfort level is determined by the technologies at which you first become truly proficient. Actually, he qualified this by saying this was the point where you no longer had to spend too many cycles on the details of the framework, language syntax, etc and could focus the majority of your attention on the problem. For example, I used to be a C++ developer, but I really sucked. I jumped ship to Delphi 1, but I don't think I approached this "proficient" point until around the Delphi 5-ish timeframe. So, this theory says that Delphi 5 should be my comfort level and everything after that just becomes "this bloody tool getting in the way".
Hmm, don't think I buy that. I'm not sure what I would buy instead, but this doesn't do it for me. Or is it that you reach a point where it's just hard work to keep up with the latest doo-hickey and you either put on a suit and tie or grumble about Microsoft taking the fun out of programming.
Well, I'm wearing a suit and tie as I write this, so I'm sure that's not it :-)
However, it is an interesting thing for tools vendors to be thinking about. I know I've faced this type of response from people while we've been out evangelising .NET via C#Builder and Delphi 8. Our industry is pretty much built on raising productivity by lifting the level of abstraction, and I'm not suggesting that should stop. Is it just a case that, as Geoffrey Moore would suggest, eventually market pressure will force the the laggards to adopt the new abstraction or get left behind?
Theories anyone?
|
|
|
Danny Thorpe, Delphi compiler god has started blogging here. He only has Atom feeds at this stage, but http://www.2rss.com seems to work ok. This should give you a RSS version of his feed.
Danny wrote what I consider the best Delphi book, Delphi Component Design, so I am very much looking forward to reading his blog.
|
|
|
SQLSite is available for download here. SQLSite is an extension to CodeSite 2 from Raize Software which allows CodeSite messages to be sent from SQL Server Stored Procedures and Triggers. It comes as a collection of Extended Stored Procedures, which once installed into SQL Server, can be called like any other procedure from T-SQL.
|
|
|
IBSite is available for download here. IBSite is an extension to CodeSite 2 from Raize Software which allows CodeSite messages to be sent from Interbase Stored Procedures and Triggers. It comes as a collection of UDF's (User Defined Functions), which once installed into Interbase, can be called like any other statement from Interbase SQL.
|
|
|
Over the last few years, my company has been called in to help various development projects in trouble. Sometime these troubles are management-related, sometimes process, sometimes the troubles can be traced back to individual team members. But at the beginning of 2000, we were called in to help a Delphi project with an out of control bug-count.
This development team (who were kind enough to let me write about them, provided I didn't tell anyone who they were<g>) seemed to be doing all the right things. They had a manager who did his best to "run interference" on the developers behalf, letting them focus on writing software. They had source code control and a bug-tracking database. They had a good range of experience across the team, and they had regular code-reviews. Yet they still had a pile of bug reports that would kill a brown dog* and seemed to have been 2 weeks away from delivering their software for the last 4 months.
* A translation is probably required for any non-Aussie readers. The Australian mongrel brown dog is notoriously hard to kill. All sorts of stories abound regarding brown dogs that have survived snake bites, crocodile attacks and Taco Bell burritos (personally I'm sceptical about that last one). At the very least, understand that having a bug list that would kill a brown dog is a very bad situation to be in.
What follows are the techniques we used to reduce their current bug count, and more importantly, reduce the number of bugs they were introducing into the new code they were writing. With one exception, none of the techniques we'll discuss were that difficult to implement, nor did they require a big investment of time.
more...
|
|
|
This paper was originally written for the UK-BUG magazine.
In a dark, paranoid corner of my mind, I imagine the conversation went something like this:
"How many?"
"Two. We've got two Australians presenting at DCon 2002"
"How did this happen?"
"Well, they submitted papers, and the Advisory Board accepted them"
"Yes, but what are they like? Are they like that horrid Crocodile Hunter fellow, always saying 'Struth' and 'Crikey' and 'Dry as a dead dingo's donger'?"
"I don't think so. One of them even lives here, and the other one seems civilised enough on email"
"Well, I don't know. Do you think anyone will want to listen to them?"
"Maybe we should get them to write an article each for the User Group magazine. Then everyone can get a chance to check them out"
"OK.but if either one of them even mentions the Cricket, he's packing his bags"
OK, maybe this is just a symptom of some colonial inferiority complex, but this is what flashed through my mind when Joanna wrote asking me to submit a short article. Of course, this was quickly replaced by fear born of having no idea what to write about. So, in a move that I'm getting particularly good at, I promptly forgot about it, hoping that either inspiration would strike, or desperation would drive me to think up some topic of worth.
more...
|
|
| |
|
