I'm still coding Ruby and I still love it. It's expressive, succinct and easy to read. It does have some inconsistencies (e.g. @@) and I don't like the block-local variable declaration syntax in 1.9, but it still remains a joy to work with.

I find myself writing a lot of custom gems. I like being able to package away code in a reusable, versioned chunk of goodness. I find that my business domain/"model" code fits nicely in this realm, because if I want to have consistent behavior across command line scripts or web apps, building a gem is a nice way to do it.

I haven't written many Rails applications, so understand I'm speaking out of a degree of ignorance (not stupidity), but I'll say it anyway.

I'm not a huge Rails fan. Why? Because I think it adds too much unnecessary magic on top of Ruby itself. I also think its greatest strength of being opinionated is also its greatest weakness. The Rails approach is to streamline building web application front ends to a database. It's great if you've got a greenfield CRUD type application that you want to put on the web. That's a Rails Home Run.

The problem is that it's almost too easy. Just like Scaffolding is something that is generally not used in production apps, I don't see why it's so hard to write a "model" layer by hand. ActiveRecord gives a ton of functionality and leverages a lot of nice meta-programming techniques. But if I'm writing a model layer that I'm going to be using every day for the next two years, I don't mind crafting it precisely.

IOW, I don't mind doing the work upfront because it's the core of my application that I'm going to build upon. The rails approach is great for consultants that need to get stuff done quickly and tend to things every once in a while afterwards. But if you're in it for the long term, Rails approach is actually counter productive.

I also don't cringe when writing SQL to access data in an RDBMS. There's nothing wrong with writing in the "native" language of the thing you're interfacing with, in many cases it's required to get the desired performance and behavior. Impedance mismatch is something developers have dealt with for a long time, and we continue to deal with it in HTML/XML markup it just seems the Ruby community accepts that more readily. Perhaps it's because we have awesome JavaScript frameworks like jQuery to deal with the DOM and everything else?

What it boils down to is that I like minimalistic frameworks and Sinatra is just that for Web development. Sinatra adds a thin layer on top of Rack (another awesome framework). These frameworks are enough for web development. You don't need anything else. Everything else can be added as required in standard Ruby ways. Want ActiveRecord or DataMapper? Just use it; it's just Ruby afterall. And this is the beauty of Sinatra; it's Ruby-centric web development. It doesn't try to be anything but something to facilitate web development within Ruby.

FTR, I will say that I'm a much bigger fan of Tony Bennett's music and voice, but I can live with the framework name choice.

Titanium was very smart to add mobile development to their offerings. When I saw PhoneGap at JSConf this year, I knew immediately that that was the way to build/deliver iPhone/Mobile applications. Titanium has essentially added that on top of it's desktop stuff.

It's looking really good and will probably be the basis for a lot of my future development: both desktop and mobile. I had written about Mozilla Prism and how important that project was going to be for me, but Titanium makes that irrelevant.

I really like TextMate on OSX. One of things that saves me loads of time is TextMate's ability to edit vertically. It's just so freaking brilliant and elegant. Why don't all editors support this?

Anyway, if someone has a similar recommendation for Linux, I'm all ears. Scribe, gedit, kate or geany aren't the same. e-texteditor looks interesting and I'll probably go ahead and (try to) install it on my linux box. I just wish it was a bit more polished on the linux side.

As a side note: Every developer needs a good hex editor. On OSX, I don't use TextMate for hex editing...does it even support Hex Editing? I use 0xED. On Windows I use Notepad++ which has hex editing capabilities built in. On linux, I don't think I've found anything...suggestions?

My current comment making system on this blog sucks. I'm going to look into integrating DISQUS...RSN once I have enough time to do it. If it's that important, send me email.

I find that I update my twitter feed much more frequently than I blog here. Since I only seem to blog every 6-8 months, that's not saying very much. But the reality is that twitter is definitely offering something useful to a lot of people.

Interestingly enough my brother who runs a messenger service in NYC said that one of the founders of Twitter (Jack Dorsey) used to do some tech work for them and was inspired by bike messenger/courier service dispatching to create Twitter. Some details here.

So I decided to check out what was going on in the Delphi world, since I haven't been paying attention to it at all. The first thing that struck me is that it's too hard to type "embarcadero.com" into my address bar. I have to sound it out in order to spell it.

Next I noticed that they've got a bunch of incremental features coming out with Studio 2010. Nothing that's going to be a game changer, but reasonable evolutionary things. IOW, underwhelming to me. The only thing that is a possible exception is their support for touch-based kiosk type applications...interesting but seems very niche to me.

It was wise of them to make a deal with RemObjects and get Chrome reworked as Delphi Prism. That is a sensible .NET strategy. Finally, but probably too little too late...at least for me to start any project in .NET.

Next they have this feature called "IDE Insight". It's interesting, but IMO, it is a solution that represents a larger problem: too many features within their IDE. The Delphi IDE has become this behemoth of configurations/options and functionality...it's just way too feature rich.

Anyway, nothing that makes me want to go back or choose Delphi over Titanium any time soon.

Since last Spring, I have personally and professionally transitioned to using Ruby as my primary language. I have not regretted that choice one bit. Ruby is a great language: concise, expressive and easy to read. The community has a positive energy, they are productive and focused on solving interesting problems. There are tons of gems available to help solve nearly every type of problem I encounter.

I am a big Merb fan. The high degree of modularity and the whole idea of being less opinionated is a good thing. The features and philosophical direction have been superb (read: the way I would have done it). Merb has engaged with deployment and "enterprisey" type issues that Rails has dismissed as unimportant.

Rails is a very nice web framework and certainly a revolutionary one. It was exactly the kind of framework our industry needed to smack the Java and .NET communities upside the head. In my opinion, it is just too opinionated.

I hope that Rails will become more Merb-like for 3.0. But if this marriage doesn't pan out, I hope that the Merb guys have the courage to fork it and push Merb forward again. FTR, I don't think it's productive to advocate a Merb fork, let's see how this dream team works out and if they can make it work.

Some of the iPhone apps are simply fads produced by gold-rush hysteria. For any hot, new platform this will be the case. However, I do believe that iPhone apps and the app store are here to stay (besides, if you're lucky enough to be the beneficiary of the fad that's ok too). The iPhone is one of the most impressive consumer electronics devices ever created and I cannot wait to start developing some iPhone apps in the new year.

The strange thing about switching from the PC to the Mac is that I don't really miss anything. When I need to go into my VM or use my PC, I feel like I've warped back to the 90's.

The Mac is better in almost every way I can think of...except perhaps cost. But it's a relatively small premium to pay in my mind for something that is in fact better. I will admit that my perspective is skewed from the normal user. I'm a developer: I don't use MS Office on a regular basis (I actively try to avoid it), I'm comfortable with the command line and a text editor, I have simple but non-trivial email needs (I despise outlook), etc. But hey, my mom has been using a Mac for longer than I have and she loves it too.

For those of you that are cost conscious, I think ubuntu makes a fine desktop Linux. Yes, Linux is ready for the desktop. No it's not as user friendly or nearly as sexy as OSX or even Windows. But it's perfectly suitable for developers and "surf & email" home users. Netbooks have paved the way, although I do acknowledge that the pendulum is swinging back towards Windows XP, Linux on the desktop is a reality...finally. In 2008, I replaced XP with Ubuntu on an old 12" laptop I had and it has completely revived the machine; it's actually usable once again.

One of the things about developing for OSX/iPhone is that objective-c is a necessity. It's also one of the syntactically weirdest ALGOL-based languages I've seen. I'm just starting to learn it, but I must say its syntax is awkward. I suspect at some point, I will begin to see its beauty...but maybe not.

One of the projects I will need to undertake in the new year is writing an objective-c plug-in for TextMate. We have some custom needs for file filtering/processing within a text editor/ide of some kind which need to be addressed. TextMate is a superb editor that I believe offers the best/shortest path forward for us.

I have dabbled in wrapping up Gecko using Delphi via the LLMozLib project. It worked ok and I made some reasonable progress there. But things change: cross platform capabilities are essential, I'm enjoying Ruby way too much to give it up and I am resolved to make progress with my little side project in 2009. So the progression of Prism is important to me. One of the things I would like to see is Prism running off a USB drive for both Windows and OSX. I've played around with this a bit and got it working off a USB drive for Windows, OSX seems to have a few more issues to resolve.

One thing I do have to say here, is that I have received a few emails from people asking me about the work I did with LLMozLib. I regret not replying....honestly I intended on doing so, but intentions don't mean very much compared to what we actually do or not do. I apologize. I will make some effort to actually do two things: 1) release whatever Delphi code I have related to LLMozLib and 2) email the handful of folks that emailed me to let them know that I'm abandoning this approach.

I believe that Erlang is the language to use to leverage multi-core and distributed processing capabilities. These things are super important now and will only become increasingly important going forward. CouchDB and RabbitMQ are two good examples of nice server software built with Erlang; I plan to leverage both in 2009.

I'm also keeping an eye on two projects built by Engine Yard leveraging Erlang: nanite and vertebra.

I've been a big fan of gliffy for about a year now. Honestly, I don't use it that often, and I "could" probably use it more often, but when I do need to draw something, it's great. It's always available, works with any browser that supports flash and it works well. I haven't looked at visio recently, and while gliffy might not really stack up feature for feature against visio, I don't care; the collaboration/publishing features are something a traditional desktop application will have a hard time competing against.

The latest online applications that I really like are zenbe and mint. I have been running Thunderbird off a USB drive for some time now, and that's been a good everywhere email solution for me, but zenbe is a better one. I just wish they allowed you to control the pop settings to actually pop the messages off the server. Until then, I'll continue to use Thunderbird off of a USB drive.

Mint is cool because it provides an integrated view of my financial information and I don't have to enter in a bunch of data. I'm not terribly skilled at keeping my finances up to date or establishing a budget or anything like that, so any help I can get is welcomed. The only thing that is a bit scary is that Mint now knows all my passwords and has access to all my financial information...oh well, I don't have that much money to be worried about anyway.

I have spent quite a few years coding Delphi and enjoyed it. I've been active in their newsgroups and if you google me, that is predominantly what you'll find out about me. I still check in on delphi.non-technical from time to time. In fact, I will comment on the biggest recent development for Delphi:

They finally have a sensible .NET strategy: drop Delphi for .NET, license RemObjects' Chrome/Oxygene/Prism and move forward with incompatible, but similarly flavored toolchains. Congratulations to the RemObjects folks, they definitely deserve whatever success this brings them.

Regardless, I've pretty much given up on .NET when I decided to focus my energy on Ruby. It's just not possible to keep up with everything anymore and .NET is too massive for one person anyway. Because of my decision, I have also become much less interested in Delphi and all of the goings on in that community. It is interesting, humorous and comforting to find the same people with the same complaints and issues. Good old Delphi...some things never change and sometimes that's the problem.

One thing that has changed is that they've put some kind of login/authentication for the newsgroups. I tried to post a few ancillary comments there recently and it rejected them. It's a sign that it's just not important/productive for me to post there any longer. I'm grateful and will pay attention to signs like these in 2009.

It was bound to happen. As far as I can tell, there are at least three distinct things that marketing folks group under the "cloud computing" marketing term:

1. Software as a Service (SaaS) - Salesforce, Google Apps, etc.
2. Platform as a Service (PaaS) - Force.com, Google App Engine, Amazon SimpleDB/SQS/S3, 3Terra, etc.
3. Infrastructure as a Service (IaaS) - Amazon EC2, Mosso, GoGrid, etc.

As geeks, we owe it to ourselves to understand the differences and coin terminology that is more precise. I personally think that Ezra's definition of cloud computing is a pretty accurate one:

• Virtualized Compute,Memory and Storage
• API accessible
• Resources scale up/down on demand

I'll add: "runs your code", which I believe Ezra would agree with.

This still doesn't distinguish from "Infrastructure as a Service" and "Platform as a Service". The main aspect to consider with Platform vs. Infrastructure is switching costs vs. do-it-yourself costs. In general, the more platform hooks you use, the higher the switching costs, the less you use, the more you have to do yourself to get functional equivalents but the easier it is to switch between vendors.

Ultimately cloud computing is very important and a lot of big companies are betting heavily on it. It cannot be ignored, but we should ignore the marketing obfuscation and demand clarity for our own sanity.

1. Small Size - it's a very small/thin phone measuring at: 99.0 x 47.0 x 14.0 mm / 3.9 x 1.9 x 0.6 inches. I can easily fit it into my pocket, there's no awkward bulge of any kind. Here is the size comparison to my old phone (XV6700) and the iPhone. Which doesn't include the big antenna of the XV6700 either. BTW, sizeasy.com is one of my favorite sites.
2. Automated GooSync calendar synchronization - I purposely picked a phone that was supported by goosync because I cannot live without my phone and my google calendar synchronizing. I would have been happy if the synchronization worked as well as it did on my old phone. On my old phone, I downloaded an application and ran it occasionally when I wanted it to sync my calendar and my phone. On the w580i, I've set it up to automatically synchronize every 12 hours. Now I don't ever have to think about synchronizing manually; it works without me having to think about it.
3. Bluetooth music player - I didn't think this was that big of a deal, and I actually stumbled upon this by accident. I have a car stereo with bluetooth capability which allows me to turn up the volume while I drive and still answer my wife's phone calls because my phone will cut into the music. It's a far better way for me to do the whole "handsfree" thing because I don't really need a headset any other time than when I'm in the car and again, the bluetooth hookup happens automatically when I drive my car and my phone is with me. IOW, I don't have to think about it or do anything to make it work.
   Well, after pairing my new phone with my stereo, I noticed my stereo offered me another music choice: bt-play. I turned to it and realized that my phone will play music wirelessly to my stereo. How cool is that! I bought a 4GB Micro Memory stick and am quite happy using it as a music player.
4. Inexpensive - This phone is significantly less expensive than the XV6700 I had on Verizon - $100 after rebate vs. $400-500??. The plan has worked out to be less expensive as well, about $50/month cheaper (family plan, unlimited text/data). Granted, my data plan isn't a 3G data plan, but I can live with that. FWIW, I didn't have any qualms about Verizon's network, nor do I have any complaints about AT&T's. If anything, AT&T's signal strength has been stronger than Verizon's in the areas that I've been.
5. Nice display - The screen on this phone is really nice. Sony's are known for bright/brilliant displays and this phone is no exception.
6. Good battery life - Another Sony hallmark; this phone's battery life puts the XV6700 to shame, which means I can have a 45 minute conversation without having to plug the phone into the charger.
7. Good Build Quality - Sturdy, but not heavy. This phone is a pretty tight and it just feels like a well made phone. The slider mechanism clicks into place crisply and the buttons feel solid.
8. Phone quality - I can actually hear the person talking on the phone. On the XV6700, I had to keep the volume turned up all the way to even have a chance at hearing the other person. I hated that. The XV6700 was a crappy phone. The Sony w580i is first and foremost a phone and I'm glad it is. I need a phone first, pda second and this device reflects that. It is a phone after all...
9. Tethered internet access - I'm posting this blog while vacationing at the beach using my Sony w580i in tethered mode. It's not 3G, and it is a bit slow...but I'm not streaming video or anything. It's good in a pinch (i.e. no wifi access): I can check my email, I can read the news, I can do a lot of things that I need to do with just my MacBook and phone. Eat your heart out iPhone (I know there are hacks to tether the iPhone...).
10. Friends think it's cool - Many of my friends that see this phone, which I thought was nothing special, make a comment about it: "That's a cool phone" or "Neat phone", etc. Which now makes me think, it is indeed a pretty sexy phone.
11. Built in pedometer - My wife has a pedometer and she wears it to be aware of how many steps she has taken during the day. So when I saw the "fitness" menu option in my phone, I decided to activate the pedometer. Well, it's pretty darn cool. I don't know how accurate it really is, but it's accurate enough to give a reasonable indication of how active I was during the day. It displays the current step count on the front screen and keeps a log of steps per day/distance walked for the last month. As expected, it resets the count at midnight automatically. The phone gets geek points.
12. Not Windows Mobile - I loathe Windows Mobile. I'm so happy to be free from the crashes, delays and bloated UI on my phone. The Sony's UI isn't perfect, but it's a heck of a lot more usable than my XV6700 ever was. Not only that, Opera Mini is a pretty decent browser and there are a bunch of java apps that work on this phone.
13. Suits my needs - Would I like more phone? Perhaps, but I'm extremely satisfied with the Sony w580i's combination of size, cost, usability and capability. It's primarily a phone, but enough of a pda, internet device and everything else that I need.

Maybe I love this phone because the XV6700 and Windows Mobile sucks so badly? It doesn't really matter, I'm very happy with this phone. The bottom line here is that the next generation iPhone better be really, really good (and justify its size) or I'll just stick with my "temporary" phone.

Non-software management will never understand code; nor should they. But isn't it way past time to stop pretending that software development fits the model they can understand? Management needs to accept that trying to manage software like other traditional processes doesn't work. Just stop it.

The ultimate point of this post is to showcase a fundamental flaw in the waterfall model. Users don't know what they want until they have something they don't. Generally speaking, this is often true in life. People don't typically know what they want, but they definitely know what they don't want: I don't want to be sick, I don't want to have debt, I don't want to fight with my spouse, etc. I've belabored this boring topic enough.

1. merb - Is a really cool framework. It's still rough around the edges and lacks all the comfy usability aspects of Rails that have been built up over the years, but I really like merb; merb is where its at.
2. Shoes - Why the lucky stiff is a bit crazy, however his Nobody Knows Shoes short book is actually informative; and because it is so zany, it gives the brain something to associate with the material.
3. Morfik - gets its pricing right. Finally. Too bad I can't actually link to the internal page because morfik is so ajaxy...
4. RubyScript2Exe - looks to be an interesting project. It also uses Free Pascal for its packing/unpacking tool. Cool.
5. Windows Mobile sucks. I don't care what anyone else says, I think it sucks.
6. Software Activation sucks too.
7. Single Platform software is a dinosaur. Delphi needs to have a serious cross platform strategy. Certainly before 2008.
8. Apple MacBook will be my next computer.
9. My Dentist is awesome.

Besides, every few years I think developers need to reevaluate their skillset and push themselves out of their comfort zone to grow. I did this with C++ and I've done this with web development. Each time I've done it, I've had to work to acquire the skills that I wanted. But each time I've done it, I've become a much better programmer. And each time I've done it, I've been rewarded with interesting and fun opportunities. In short, it's always worth the effort. Enough philosophy. :)

One of the biggest, if not the biggest technical issue facing Delphi is its lack of cross platform capabilities. This is something that I believe will be essential to the long term goals of the product that I'm building. I don't think I'm the only one with this issue. Many ISV's, including Microsoft, have significant cross platform offerings. As the usage patterns of personal computers shift, the software development community can no longer rely on a single vendor/platform for their deployment needs. Why would I want to take that risk? Why wouldn't I want to be able to deliver my product to as many people as I can?

Despite the best efforts of CodeGear, Delphi suffers from several other problems:

1. Closed Source/Proprietary: Delphi's progress is at the mercy of CodeGear's competency and resources.
2. Activation/Licensing: The ability to use Delphi is at the mercy of CodeGear's activation servers.
3. Poor Documentation: Their documentation sucks and very few people care to document it for them. The user base is mature, those that know, already know.
4. Dwindling User Base: How many developers you know are choosing to learn Delphi? How many companies that you know are starting new projects with Delphi? How many companies are hiring new Delphi developers?

I like Ruby. I really like Ruby. It addresses virtually every weakness of Delphi and keeps most of its strengths. Ruby has a fantastic framework with many third party options. The language itself is extremely pliable and expressive. The notable weakness Ruby has, is Delphi's greatest strength. Ruby doesn't have a great GUI layer. Delphi is the best Windows GUI tool there is, so this is a big weakness, especially for a desktop application.

But, the interesting thing is that I've moved towards webifying my Delphi UI's anyway. So, why can't I do this with Ruby? A Ruby wrapper for WebKit would be perfect (I haven't found one yet, thinking about writing one). This would make the development of a cross platform shareware application viable with Ruby.

This is pretty close to what Rich Kilmer and the InfoEther guys are doing today. They use Flash for their UI, but they've got all the machinery and according to Rich's RubyConf session, they'll be releasing the core infrastructure as an open source project RSN. What Rich & Co have done is package the entire Ruby interpretor and framework in a way that it can be distributed with your application.

In moving away from Delphi, I'll certainly miss great components like NexusDB. But Ruby offers so much more than Delphi in the intangibles. These things are hard to ignore and it's at the tipping point for me.

The next steps for me is to do a few projects with Ruby and see where the limits are for my application. Once I explore a bit, I'll be able to determine quickly if Ruby has what I need to implement my vision.

Ruby is a on the upswing. It's got a smart, vibrant community that is cranking out useful stuff very quickly. It's open sourced so there is no bullsh*t about activation/licensing/escrow, dealing with a single vendor, etc. There is no fear that if I create something great in Ruby that it will be shackled (technically or legally) by some corporation other than my own. :)

Looking forward, Ruby's intangibles add up to a lot. It might mean more work for me to achieve my goals initially, but in the end, I believe the payoffs will be worth it. They always are.

There were about 500+ people in attendance. Almost all of them used Macs. I've never seen such a concentration of iPhone's either. :) My eyeball estimate is that 90% of the developers there were using MacBooks of some kind. Out of the remaining 10%, more than half were running some flavor of linux (ubuntu seemed to be the most popular) on their laptops.

Contrary to another programming community's cynical and disconnected viewpoint regarding Apple products, the Mac is a superior platform for developing Ruby applications. IOW, there's a reason why Macs are more popular in the Ruby community...imagine that.

OSX has been shipping Ruby since Tiger (April 2005). They are now shipping Rails with Leopard, and have picked up the Ruby Cocoa project. They've also created a Scripting Bridge and they demonstrated the use of injecting Ruby into a running application to control it. Very cool. Here's a nice write up of the OSX session.

Anyway, I will say that some of the talks were really useful, inspiring and wonderfully entertaining. There were some real "gems" in the RejectConf sessions too (presenters that weren't accepted in the formal sessions had the opportunity to present in an informal one; great idea).

On the other hand, some of the presentations weren't so great for me. IMO, there were two recurring problems:

1. The presentation's target audience was very advanced Ruby developers. With a conference attendance that doubles each year, half of the audience will be relative newbies. I'm one of those people. It would be helpful, even when discussing very advanced topics, to provide better "real world" context around the actual topic.
2. Basic assumption that developing open source frameworks is the primary use for Ruby. I'm exaggerating a bit here, however an example of this focus is that when talking about "generating Ruby code", the context of the whole talk was about writing generators like Rails generators for new frameworks. What about addressing fundamental code generation first and foremost? As the community gets bigger, most developers will be developing applications, not frameworks.

In general, those issues are issues simply because Ruby Conf is experiencing growing pains. That's to be expected. It might be useful in subsequent years to have an indicator of assumed skill level associated with each abstract. Another thing that would have been nice is to have a way to provide feedback about the specific sessions. A simple Rails app would have been enough for the attendees to provide such feedback. Maybe next year. :)

Overall it was a really great experience and I'm glad I went. Looking forward to next year's conference!

I'm pretty excited about the release of ASP.NET's MVC framework. I'm quite pleased MS has decided to hire Rob Conery and roll SubSonic into the official offering. This will certainly enhance the adoption rate of SubSonic by making it more palatable for "corporations" to use it.

I attended a RUG meeting a few weeks ago and one of the comments by the attendees is that he's seeing more competition between Rails and ASP.NET than Rails and Java. This was the first time I had considered the possibility of Rails eating into ASP.NET's marketshare rather than Java's, but the recent moves by MS indicate that they are adapting to fight that kind of battle.

All of this means good things for the web developer. If you like the Rails style of web development, and I do, then the forthcoming ASP.NET MVC framework is going to be worth checking out. Beyond the rather significant differences between what .NET and Ruby provide, the main technical reason I can see for locking yourself into WIN.NET rather than using the real-deal is for performance/scalability.

Now, I do believe that Rails can be made to perform and scale. It has been made to perform and scale. There is a lot of effort within the Ruby and Rails community to improve runtime performance across the board. In this regard, an interesting project to keep an eye on is Merb. I know I'll be looking into Merb in the next few months.

Anyway, congrats Rob and MS. Looking forward to good things from you guys. I promise that my next blog title won't be a silly pseudo math equation.

When I found out about it, I didn't have time to actually figure out how my website was exploited. So we danced for a few days: I deleted the files, the hacker replaced them. Wash. Rinse. Repeat.

It turns out the hacker got a bit frustrated, so he/she then decided to "rm -r *". Well, that was brilliant. It not only deleted my entire website, but it also deleted his/her backdoor. :) No more website, no more hacker.

No biggie, I was working on releasing an update to my website off and on for a few weeks (ok...a few months). So, it was time to change it and move forward. Restoring the content and moving all my blog entries over has taken a bit of time and effort. I had to write a few ruby scripts to help parse/convert the raw data from the old database, and I still have more work to do. But it's far enough along for me to write a new blog entry. :)

What you see here is the new website. It's built on top of MODx. I wanted a more streamlined, "web 2.0"ish website that really focused on Brain Endeavor's core competencies. I'm pleased with it, if you'd like, let me know what you think.

So why would you want to use it? Imagine the fully capable Firefox browser in your application without the use of ActiveX/COM. There is a pretty hefty set of runtime files/folders (~15mb) that must be installed within the application directory, but we're talking about a full fledged browser, with javascript support, etc.

I'm developing an application that needs to be able to run off a USB drive and it needs to run in a controlled manner (i.e. cache and history stored on the usb drive and cleared when desired). This might be a bit of an unusual requirement, but its the one I'm imposing.

Anyway, it's starting to take shape. I'm using the excellent Graphics32 library to render the Browser display within a Delphi form. It's not perfect, but I've been able to support some nice things like the mouse wheel (sort of..lol). In typing this blog entry though, I've noticed I still have work to do with capturing some of the ctrl key combinations (at least ctrl-c and ctrl-v works!).

The main downside that I can see is that at this time LLMozLib is pretty CPU intensive since it relies on full view rendering. IOW, there is no optimization of sections for the display. There is talk on the uBrowser Google Group about reworking this.

Also, in order to display fancy Web 2.0 Javascript or Flash animations, there are no "Invalidate" type events, thus on pages that require that, I use a timer to constantly repaint the page. It's not bad visually, Graphics32 doesn't flicker one bit, but it does chew up CPU cycles. I'm hovering at about 7-15% for one of my CPU cores as I write this using 200ms refreshes. Hey what else are you going to use your additional cores and fancy graphics cards for?

If you're interested in a somewhat polished component and some simple documentation on how to use it in your Delphi apps, comment here or send me an email. If there's interest, I'll see if I can free up enough time to make it consumable for the greater Delphi community beyond what the MPL requires.

Space tourism sounds pretty cool, I hope that we all get a chance to do it. Even having a meal prepared by Martha Stewart is something I would like.

I look forward to the experience of seeing the planet from outer space: to see our earth as one thing, to see that we're all traveling together on the same rock. What a powerful experience to remain mindful that we all share this planet.

]]> Wed, 11 Apr 2007 16:02:00 -0400 http://www.brainendeavor.com/modx/stsimonyi-goes-to-outer-space.html ..::brain endeavor llc::.. http://www.brainendeavor.com/modx/groovy-barely-kicking.html read how Monson-Haefel has lost the enthusiasm he once had for Groovy. According to his own website his "proudest achievement was instigating JSR-241, The Groovy Language Specification", so it is a strange change of heart indeed. This is especially unfortunate considering what I perceive as an uptick in activity and interest: Groovy 1.0 was just released, Groovy In Action was published, websites about Groovy and using Groovy have come online.

I contacted the journalist who wrote the article, Alex Handy, to ask him about Mr. Monson-Haefel's remarks. He explained it as:

It's unfortunate that Groovy is regarded as a fad. I believe Groovy is more than that, and I also believe that Mr. Monson-Haefel should know better. Perhaps Mr. Handy incorrectly characterized his remarks, I don't know.

Certainly I do appreciate recognizing it does take time for a programming language to "jell". But I also appreciate James Strachan's early vision for Groovy:

From my point of view, this is what makes Groovy more appealing than JRuby or Jython. For the record, I do love Ruby. I might really like JRuby on the JVM, but it's because of the impedance mismatch that makes Groovy more appealing to me on the JVM. Mr. Monson-Haefel seems to have had a different goal for Groovy:

I think that is a good goal, however it demonstrates how different Mr. Monson-Haefel's personal goal for Groovy is from the original goal of Groovy.

Mr. Monson-Haefel compares Groovy to an "idealistic politician", however it seems to me that his remarks about other dynamic languages is the real political maneuver. Sun needs to stop developers from abanadoning Java in favor of dynamic languages, it could also use this to compete against .NET CLR. So it makes sense for Sun, and those vested in the Java world, to push dynamic languages on top of the JVM. For example, as Ruby on Rails becomes a more popular alternative to Java, Sun sponsors the development of JRuby.

Now I believe that all of this is a good thing. It's great to have multiple languages support the JVM. I just don't understand why it's necessary for Mr. Monson-Haefel to state that Groovy "didn't succeed at all (as a language)" without letting the development community decide for themselves. Java was far from perfect in its initial release, Groovy deserves the same chance.

At least Tim Bray is keeping an open mind, perhaps Mr. Monson-Haefel was just too personally invested to do so. I'm certain that Guillaume Laforge and the Groovy community will continue to forge ahead, and hope that they, and more importantly those new to Groovy, are not discouraged by Mr. Monson-Haefel's callous and untimely remarks.

The "Everything you love about Delphi" slogan is silly too. Does the product support the Delphi language? No. Does the product create high performance natively compiled/nice looking GUI applications for Win32? No. So what is this "everything" that I supposedly love about Delphi? A drag-drop designer? Oh right, how silly of me, PHP is what I love about Delphi! At best it's factually incorrect, at worst it's insulting.

So who are they marketing this product to? One theory: existing Delphi developers. Considering the name of the product and slogan, that's the most reasonable answer. Is that a big (enough) market? If CodeGear has plans on rolling their PHP support into BDS, will the upsell margins be that significant? The whole marketing strategy seems foolish to me. The larger PHP market is much bigger than the existing Delphi one, go after that market.

The only thing I can think of to explain this strategy is that CodeGear wants to push two brands going forward: "Delphi" and "VCL". But again, I point to the law of line extension. What happened to using "Turbo" as a brand? Based on what the product actually is, I believe "Turbo PHP" would have worked quite well. The price point is right, the whole "single language IDE" thing is right. I just don't get it.

Ok, so what is the actual product? "Delphi for PHP" is Qadram's qstudio. CodeGear apparently cut a deal with Qadram to repackage their forthcoming PHP product. I'm glad CodeGear is acquiring and/or licensing outside technology. But the ultimate test is if "Delphi for PHP" can compete against the other php offerings: Komodo, Zend Studio, PhpED or VS.PHP. At the end of the day, it appears the distinguishing feature CodeGear has is a visual designer and I'm not sure if it's enough.

It's a complicated mess and I really don't like MS' solution to a problem C++ developers have been living with for the past 10 years, but whatever. Essentially dynamically linking (/MD) to the msvcr80.dll using VS.NET 2005 C++ is not a good idea. So the new build is statically linked (/MT).

Many thanks to Diego Navarro for pointing this problem out and having patience with me to work out the solution. Thanks Diego!

In the spirit of Guy Kawasaki and since CodeGear/Delphi needs more help than Microsoft, I figure I would throw out 10 ways to "save" Delphi. When I say "save" I mean save it from irrelevance, not death.

The OS is becoming less relevant, development frameworks are becoming more relevant. Cross platform development will help distinguish Delphi from VS.NET and make Delphi more competitive with C++ and Java. Delphi has proven itself to be capable of competing against C++ and Java. If Microsoft is going to face difficulties ahead, diversify Delphi.

Most Delphi users are Win32 developers. Find a way to give them something substantial to talk about. Be courageous and break backward compatibility to offer something new and experimental. Be bold and produce something completely bizarre but cool. Appeal to the inner geek in all of us. Give the R&D guys some latitude to produce some "less than useful things". Be remarkable.

On the strategic front of evangelism: the free Turbo Explorer editions are probably the best thing to happen to Delphi. But it's important to leverage this with a sustained marketing campaign. I see this as being akin to the "Spread Firefox" campaign. Do whatever it takes to "Spread Delphi", except bribe bloggers with pre-loaded laptops.

Google is typically quite mum about the products in their pipeline. Their marketing strategy is not one based on anticipated products, but on tangible ones. They under promise and over deliver. They serve the community rather than pushing product on them. They attract rather than promote.

There's a distinction between engaging the customer in an honest dialogue and justifying poor performance. There's a difference between an explanation and an excuse. I'm genuinely grateful that CodeGear is more open about their intentions than Borland has been in the past. I think they've improved quite a bit on the communication front, but...

I'm sick and tired of hearing excuses. I'm sick and tired of seeing product delays and poor quality releases. I'm sick and tired of hearing how CodeGear is different than Borland. I don't want to know about your problems anymore; I have my own. Whatever problems you have, fix them. SOX got you down? Don't bother telling me about it, you could have gone private. Again it's not my problem. I'm your customer not your lawyer, accountant, shrink or priest/minister/spiritual guru.

While we're at it, let's debunk the argument that what Borland did in the past is irrelevant. It's really simple to debunk: no one would care about CodeGear if it weren't for Borland. CodeGear inherits a positive legacy and a negative one. They cannot separate the two and trying to do so is simply living in denial. Denial is a useful tool, it's tempting to live in it "happily", but it's just not healthy or realistic.

The core problem CodeGear has is one of distrust. I don't trust what CodeGear has to say. When there is distrust, even a legitimate explanation sounds like an excuse. Everything CodeGear says seems like an excuse. There's only so much patience people have:

It's been a long time since we've listened to Borland talking about how how developer tools were integral to their ALM strategy, then turn around and align their ALM products with Eclipse and Visual Studio. Not to mention categorizing Delphi as a cash cow. Remember what all the Borland faithful said at the time? I do. Some people suggested a separate company "Delphi Inc.". Remember what all the Borland faithful said about that? I do. Then when the divestiture was actually announced, we waited. Remember what the Borland faithful said then? I do. Now we find that CodeGear is to become a wholly owned subsidiary. Ok, I agree it's better, but hardly "under promise and over deliver".

I'm not saying that we should hold a grudge or not give CodeGear a chance at redemption. I'm saying that there are serious trust issues and that CodeGear should be held accountable for what they say and do. Consider this a time of "tough love".

Bottom line: until they start taking action, there will continue to be distrust. Trust takes a long time to restore, so this action has to be visible and sustained over a long period of time.

If there has been a major mistake in the stewardship of Delphi in the past 5 years it's been in regards to .NET. Hindsight is 20/20 so I won't harp on past mistakes here. The important thing now is to have a .NET strategy that leverages Delphi's strength and keeps it relevant in the .NET world. Delphi's strength is it's native code abilities: .NET Interop is what's going to drive value. IMO, the ultimate .NET interop capability is a mixed mode compiler. Short of that, there are a few practical things that Delphi can do going forward: host Winforms, interop with WPF or WPF/e, ADO.NET and TDataSet adapters, easy .NET consumption of native Delphi packages.

Also since they already have a Delphi for .NET compiler, one of the more significant things they could do to distinguish themselves from VS.NET is to officially support Mono. They could also roll Mono's C# compiler into BDS. This would also aid in addressing my #1 point above.

Modern IDE's are more like platforms than products. Modern IDE's have integration hooks everywhere and they're documented and/or visible because those IDE's are open sourced. The reality is that CodeGear can't do everything for BDS; like it or not, they need the help of the community.

Document the OpenTools API, create example IDE integrations, demonstrate this via screencasts, etc. Do what it takes to make this happen, or CodeGear might as well integrate Delphi into Visual Studio or Eclipse or NetBeans.

In order to leverage the community effectively there are certain technologies that need to be in place. Delphi in many ways was a pioneer here: its RTTI enhancements enabled things like design-time component-based development. Enabling technologies are vitally important to spawn innovation and extend the reach of Delphi. CodeGear would benefit greatly by beefing up RTTI in native Delphi.

In addition to RTTI enhancements, getting generics is vitally important. Focus on some core VCL enhancements. Leverage RTTI enhancements and create a better data binding architecture. Let's get Unicode in there. Let's get an IDataSet implemented. Let's get a standard set of generic containers. The community will fill in the gaps with fancy looking controls.

Another thing that I would like to see is the removal from having to "install" packages. Why can't Delphi pick them up based on a standard (with an override) directory path? Make it easy to install, reinstall and manage Delphi installations across computers and team members. Why can't I check in our Delphi installation into version control? Why can't I have project specific configurations? Push the limits on dynamic code loading.

Internet development is vital. Because of that, it's important to get the server-side right. In recent releases, I've pretty much ignored the included server-side technologies that Borland has built. Why? Because there were better third party offerings (e.g. RemObjects). But there are two existing things in the box they should unite: Intraweb and ECO. Do this and allow deployment to Linux.

The fact that ECO doesn't include all its runtime source is unforgiveable. I'm sorry, but that's simply old fashioned thinking and hurts ECO's overall adoption. Also, most of your customer base can't use ECO because they are coding in Delphi Win32. Bring ECO to Win32/native. If you can't, build something "ECO like". Just don't use dbExpress; we don't need another framework without source code. Design it to use an abstraction layer where all the great third party data access components can be used.

This is a no brainer and can be done independent of Delphi releases, it can be done now. 'nuff said.

If CodeGear were to do this, it would demonstrate that they are a nimble, agile company that is committed to developers. Full releases every 4-6 months. They should also do more CTP's, Public Beta's, etc. and will need to for the long term projects that take longer than 4-6 months. CodeGear needs to demonstrate through their actions that they are not like the slow and monolithic development shop Borland ended up becoming.

Adjust the roadmap in the same way: small changes more frequently. Don't wait a year to update the roadmap, let it be a fluid outline of CodeGear's strategic direction. Make it a "living document".

In the spirit of Guy Kawasaki's bonus #11, here's mine. Dump Together; many people strip it out anyway. ModelMaker technology is simply better. ModelMaker will provide all the Together functionality and more: refactoring, uml design/code synchronization, ECO designer surface, etc. If CodeGear is truly independent from Borland, this is one thing they can do to really show it.

So there's my list. FWIW, I'm not so arrogant to believe that I could do a better job at managing Delphi or CodeGear, this is merely a blog entry after all. All I do know is that I don't envy their task one bit. Good luck CodeGear!

Notwithstanding NetBeans is free and open source, NetBeans competes against commercial IDE's like IDEA extremely well. Take a look at some of the core features; and then look at the profiler and the visual web pack. Very impressive and all for free.

One of the things that I tossed around in my head was the idea of plugging Free Pascal into Eclipse. Well, I think NetBeans might be a better choice. IMO, these tutorials for integration capabilities are quite instructive:

• Syntax Highlighting
• Code Completion
• Palette Integration
• Visual Designer

Geertjan's Weblog is another great resource for IDE integration modules. And if you get stuck, there's a lot of source code around (in NetBeans CVS repository) for existing integrations.

So just imagine what would be possible if someone really motiviated wanted to hook FPC into NetBeans...I imagine it could be done relatively quickly: follow the steps above. I searched for an Antlr grammer for FPC/Delphi and found only a few random messages/pages about it. That would be a good start for code completion support. XUL is the front end I'd like to see support for with FPC; I suspect someone will build XUL integration for NetBeans at some point. (In case you're wondering, I'm not smart enough or motivated enough to attempt to do this. I'm also too overcommitted to start "yet another project".)

Anyway, NetBeans is a very good IDE. I'm looking forward to further Groovy integration, but right now it's definitely my cross platform IDE of choice (except for Ruby/Rails work ).

Also, with the updated Delphi roadmap in the works I figure I should blog about my own vision of a Delphi Roadmap. Everyone has their needs and ideas about Delphi's strategic direction so I encourage everyone to express themselves. If nothing else it will demonstrate to the development community, and perhaps more importantly, to the investment community that Delphi still has a cadre of passionate developers that care deeply about the product.

I agree with Chad and Simon when they say that Borland has simply lost their way and that CodeGear needs to focus on their existing customer base in the immediate future.

Definition of terms:

• "Delphi" = the language in general; "Delphi Win32" and "Delphi for .NET" makes the distinction between the languages
• "BDS" = the IDE
• "VCL" = the VCL in general; "VCL Win32" and "VCL.NET" are specific flavors of the VCL
• "the natives" = the bulk of Delphi developers; these developers are primarily interested in using Delphi for native code development. They are getting restless and have been fasting for quite some time. :)

I'm only going to focus on the big technical issues. I'm not going to talk about the other sorely needed improvements (e.g. help system) or things that need to continue to get better (e.g. stability/responsiveness/quality of BDS) or business issues that I believe should change (e.g. shorter release cycles, sell the product via subscription only) or less obvious/unsung features that would be really nice (I'll discuss this in another blog entry).

Highlander/Delphi 2007

• enhance Delphi for .NET to support .NET 2.0 framework
• Generics for Delphi Win32 and Delphi for .NET
• Unicode foundation for Delphi and VCL Win32

Inc(Highlander, 1):

• ECO-lite for Delphi Win32 or at least build a modern DAL for Delphi Win32
• full Unicode support for Delphi and VCL Win32
• enhance Delphi Win32 .NET interop; incorporate ideas from managed-vcl and Hydra in the box
• Delphi Win32 should be able to host and leverage WinForms/WPF
• Delphi Win32 should have classes to help ADO.NET and TDataSet integration
• .NET languages should be able to leverage Delphi Win32 packages
• rudimentary Win64 support: compiler, RTL, non-visual support
• In the box Kylix cross-compiler support; server-side deployment kit (not a separate product)
• make Apache DSO support a priority
• Mono support
• integrate Mono's C# compiler and runtime assemblies with BDS
• officially support Delphi for .NET assemblies on Mono
• add help/code insight/compiler warnings to indicate where Mono and .NET differ either in scope or usage

Inc(Highlander, 2):

• full Win64 support
• full Delphi mixed-mode compiler
• compact framework support

I suspect the work for the Highlander release is well underway and that includes supporting .NET 2.0. It's also work that I believe they will align/leverage to support Generics in Win32. IOW, I think for Highlander, CodeGear is focused on reasonable things: .NET 2.0, Generics and Unicode.

Make no mistake though, there are only two things that will drive revenue for Highlander: Generics and Unicode for Win32. I don't believe that .NET 2.0 support will increase Delphi for .NET adoption in any significant way. The main reasons why I think it should be included is because: 1) it's long overdue and already in progress; 2) .NET 2.0 is much better than 1.1; 3) Mono is moving towards 2.0 support; and 4) it will be yet another data point to reveal Delphi's .NET strategy is fundamentally flawed.

For the release after Highlander, I've cut out all the "Vista" support for Delphi for .NET and added it in the form of interop for Delphi Win32. I've also not included VCL.NET for any work whatsoever as I agree with Chad: there is no benefit. I admit there are a lot of things on my list, but CodeGear's got a lot of work to do to make Delphi attractive in the modern day development landscape.

The main thing I believe Delphi should focus in on post Highlander is platform diversification. This is essentially executing on the "Delphi Everywhere" strategy that was floated in non-tech a while ago. This also includes diversification on .NET itself. It's critical to offer something different than MS is offering with VS.NET, and supporting Mono with BDS is one way to do it. Also by supporting Mono, CodeGear can better justify their .NET framework version lag time as Mono moves at about the same cadence as BDS has done over the past few years.

I think by rolling in a Kylix-based server-side cross-compiler kit, CodeGear can make BDS more appealing to those developers who are primarily on Windows, but may wish to deploy to Linux for things like Apache web modules (e.g. IntraWeb apps). It's important not to release this as a separate product; it's about selling to the existing market of Corporate IT developers that may want the option of using Linux as a deployment platform, even if they never do so. CodeGear should think of Kylix and the whole platform diversification strategy as selling an insurance policy to Windows developers. I believe many will buy it and some will use it. More importantly, more will use it than Delphi for .NET is currently used.

I've added an ECO-lite or a generic "modern DAL" for Win32 to the release as well. It's getting to be quite ridiculous that Delphi's Win32 database access has languished for as long as it has. It's showing its age and I believe this makes Delphi less appealing for database development. I believe that work/improvements in this area, in conjuction with full unicode support and progress on the Win64 front will help keep "the natives" happy and drive upgrade revenue.

Finally, the progression of Delphi in my perfect world ends up with a full blown mixed-mode compiler, Win64 support and if there's still a market for it, support for .NET Compact Framework. So there you have it, I hope to blog about Delphi and CodeGear's fundamentally flawed .NET strategy soon; but I might wait until the revised roadmap comes out.

The Mozilla platform is a framework just like Java and .NET. It provides a bunch of stuff to build all sorts of applications. It's language neutral, although IMO, it would work best with C++. CodeGear has a good opportunity to revive the CBuilderX product and use XUL instead of wxWidgets.

Interestingly enough, there is a good deal of work done by a company named Kama Software to bring XUL to Delphi. It's been almost a year since Kama Software has done anything with their DINO framework and a lot has changed on the Mozilla side. I've been watching it for a while now and finally looked at all the bits in their demo download while going through this learning process about the Mozilla Framework.

I was surprised at how much code they included in the demo download and by reading some of the code, I have a better idea of how their DINO adaptation works. I do have some implementation concerns and some ideas about how to do things a bit differently to make things more Delphi-like, but I admit to be just learning about the technology so it's best to be quiet. :) The bottom line here is that Kama Software's DINO framework proves that integration of XUL and Pascal is possible.

Considering how Delphi's cross platform priorities have changed (read: nullified), my belief is that it would be better suited for FreePascal. ISTM, the Lazarus IDE project, while it is making progress, is holding FPC back from bigger and better things.

Building an IDE is a tough job. I think the FPC guys should consider taking a page out of JBuilder's playbook and adopt Eclipse as their IDE core. Don't spend time reinventing the wheel, use something that works.

I also believe that the whole "choose your favorite GUI toolkit" strategy is too onerous. What I want is one consistent cross platform GUI; no futzing between VCL and CLX, or deciding if QT or GTK is better, etc. Just give me one that looks good and works well. I don't think I'm alone.

IMO, HTML/JS, XForms, Swing and XUL/XBL fit the bill; Flash and WPF/e might as well. Pick one and build the best support you can for it. My choice is XUL/XBL. And if XUL is chosen, another benefit in building off of Eclipse is the possibility of leveraging existing work like a XUL designer. FWIW, that particular XUL designer isn't a full blown visual WYSIWYG designer, but it's certainly a start towards IDE integration and could serve as a base for future development.

If I were a bit smarter, more in love with pascal and weren't too lazy/overcommitted, I might get involved in a project to bring Free Pascal to Eclipse and leverage XUL in the process. But right now, I think my choice for cross platform GUI development is Groovy and Swing development using NetBeans 5.5 for an IDE.

So I thought, perhaps I should look at JRuby and SWT/Swing. I have seen some modern SWT and Swing interfaces that look quite good and perform well. Although I don't follow the Java world and don't particularly like Java the language, SWT/Swing are both mature frameworks that are well supported.

But while I was reading about using JRuby and SWT, I ran across something called Groovy. The more I read, the more I liked about Groovy: dynamic language elements, seamless integration with Java, acceptance from the Java community and its overall design aesthetic.

I'm definitely going to play around with Groovy and Grails. Groovy has given me some hope that the Java platform can actually be fun to use. :)