BKeeney Briefs

In my previous blog, one of the commenters asked me about my thoughts on the new LLVM backend compiler that RS is implementing for REAL Studio.  I’ll first start by saying that I am not a backend compiler expert, nor want to be.  Much of what I’ll write about I’m getting from sources that are in the know, as they say.

What exactly is LLVM other than a fancy acronym?  It stands for Low Level Virtual Machine and is a compiler infrastructure.  It was started in 2000 at the University of Illinois and in 2005 Apple hired some of those original authors for their development system.

RB currently uses a custom written backend compiler.  As you can imagine, maintaining a compiler is a lot of work and writing optimizations is not easy.  LLVM was designed for multiple layers of optimization including compile-time, link-time, run-time and even idle-time.

What does LLVM mean for REALbasic applications?  It means that applications should be smaller and faster.  Code that isn’t used will be removed (dead-stripping code).  Currently RB can do this but it’s not exceptionally efficient (but really not all that bad either) as it which leaves some unused code compiled into your application.  For most of us this isn’t a big deal, but for many that start a project with a standard toolset, they might be introducing some inefficiencies into the final product.

Switching to LLVM is great news, though.  Smaller, faster, better are all things to strive for.  Without giving away too much information, the RBScript compiler is being reworked to use LLVM.  It’s a good first step.

But that’s all it is.  If you’ve not used RBScript, let me tell you, it’s not REALbasic.  One of the most powerful features of REALbasic is the cross-platform debugger.  Run in one environment while debugging in the other.  Even when you are debugging locally (on the same machine in the same environment) you’re ‘remote debugging’.  If my source is correct, switching to LLVM will require rewriting the entire debugger because the LLVM metadata system is different than RB’s debugger map system.

Since LLVM uses different metadata properties the current introspection system will break and have to rewritten.  Plugins will also break.  The IDE, the plugin system and even the reporting engine are a heavy consumers of introspection.  So going to LLVM means a huge portion of the product needs to get updated.

Rewriting the debugger is not a trivial task.  To do this the RIGHT way is a huge job that could take a couple of strong backend compiler developers 6 to 12 months to fully implement.  Even hacking it together is probably a 4 to 8 month project and it would still take some time getting the remote debugger to work properly.

If all this sounds daunting and kind of scary, well, it is.  Switching backend compilers is not something to do on a whim.  It has to be well thought out and resources have to be allocated properly.  The roadmap for features that will not be added during the transition time need to be thought out properly as well since limited resources are a fact of life in all organizations.  A small organization needs smart long-term planning.

Make no mistake, though, the backend compiler switch promises to be take a while.  It basically rewrites major portions of the product which will lead to some subtle and not-so-subtle changes.  The risk is high and it will affect EVERYONE.

There’s been some talk about all the ‘freebies’ we will get when using LLVM (such as 64 bit support).  Not true.  Using LLVM gets you ‘closer’ but it still won’t be free.  Switching to LLVM removes one of the many tasks involved with such support.

With all that said, I think moving to LLVM is a must.  If RS wants to support different platforms it’s a smart move going forward.  The optimization capabilities look very promising and will be welcome to many users.  It IS the right thing to do.  Just be prepared for some bumps along the way.

One final word.  I’m a passionate RB user.  I’ve also been a project manager where I think about the bumps in the road before they happen.  I’m not an expert at this stuff, though, so any misconceptions or mistakes are entirely my own.

The March/April 2010 edition of REALbasic Developer Magazine hit my inbox this morning.  Besides the normal BKeeney Briefs column Marc Zeedar and I have a spirited debate on whether or not REAL Software should devote existing resources to making REAL Studio work with iPhone apps.

Note the italics on ‘existing’.  While I think it would be a nifty idea, overall, I question the wisdom of diverting resources from an already small development team to a product that might be doable.  Is this a Mac OS X only product or is it cross-platform?  I seriously doubt that it will be cross-platform but perhaps I’m wrong.  The point is that there are a ton of issues to figure out and then the question then becomes, “What are we going to give up in the desktop versions while this is being developed?”

Other thoughts:  Apple makes a boatload of money from developers buying Mac hardware and this product has the potential to take that revenue away.  One could certainly argue that it has the potential to sell more iPhones/iPads/iPod touches because more applications will be available.  But Apple has 140,000-ish apps right now.  Would 10,000 more, or 100,000 more really mean anything to Apple?

It also has the potential of being a potential support issue for Apple.  Assume for a second they allow RS to make iPhone apps.  The RB framework has a bug (because that’s never happened), or Apple changes the SDK one day and doesn’t give RS advance notice (Apple is secretive, no?), and now tens of thousands of RB iPhone apps no longer work.  Will the developer, RS or Apple get the blame?  Apple.  Just like how Microsoft gets the blame for crappy drivers and crappy 3rd party apps made by bad developers, Apple would get the blame.  Apple guards the keys to their kingdom very closely because they want it to be associated with a classy, premium product that “just works”.

Anyway, you can read the debate between Marc and myself in the magazine.  My guess is you can figure out my viewpoint.    Marc argues, the opposite.

My regular column talks about making your projects more Agile-ish without going full-bore in using the Agile process.  It’s not as hard as you think and your clients might really like it.

Your thoughts?

The number of bug reporting systems REAL Software has implemented in my time using REALbasic has been astounding.  Of course, some of the changes revolved around the emergence of the internet, but still, I’m amused at the iterations.

There was REALbugs (?) that was a standalone app that I never really used because I was a newbie. It memory serves, it was very much a Mac OS 9-type application.  As to how well it worked – I couldn’t tell you.

Then there was the feedback web site that allowed you to sign on to a bug to ‘vote’ for it.  It was nice, but people would literally sign on to EVERYTHING which defeated the purpose of the voting system to begin with.

Then RS switched to FogBugz and abandoned all of the old feedback items.  Supposedly, it would make life easier on them and they’d be able to fix bugs easier and faster.  Unfortunately, it made bug reporters life much harder since we couldn’t search the database.  RS was inundated with duplicate items and it was hard to tell the good reports from the bad.

So, now, in the current iteration we’ve come full circle and we’re back to an application called Feedback and is part of the download package.  It’s better in most respects to the previous system other than that it’s an application which just seems….odd in today’s internet world.  But I understand why they did it and for the most part it works.

It’s user interface forces you to search for an existing bug before you can add a new one (that’s good!).  You can see the newest cases (handy if you’re evaluating a new version of REAL Studio), My Cases, Participating In, and My Favorites.

You can add cases to your favorites list by clicking the star at the bottom of the cases listbox.  But a not so well documented feature is the Priority List.

The Priority List allows us to prioritize our bug fixes and feature requests.  This supposedly gives RS some feedback into what we want fixed or implemented sooner rather than later.  It’s also weighted in favor of the Professional and Enterprise users (we can argue whether that’s a good or bad thing in another post).  There is an algorithm to it but when I had my conversation with an RS employee I didn’t take notes so I might be off on the actual numbers.

A Personal license gets a weight of 1.  A professional user vote gets a weight of 10 and Enterprise has a weight of 20.  So Enterprise users are 20 times more powerful than Personal licenses.  That doesn’t strike me as too off base since a Personal license is $99 and the Enterprise is $995 (again we can argue the logic of the weighting another time).

Perhaps the smartest thing they did with the priority system is that you only get five votes and if my memory serves (forgive me, this is the day I got the flu), I believe a #1 rank gets 5 points and the last vote only gets 1.  So you have to be smart with your priority list and to edit it, go to My Cases and click the Edit Priorities button at the bottom of the list.  A separate list of all the cases you have some interest in are presented and you drag reorder the cases as you see fit but only the top five are counted and in the list are bold.

You can find the current list by clicking on Top Cases which brings up the current list.  If you double click on the list item you can see the internal rank in the upper left hand corner of the report.  And this, in my opinion, is where this system breaks down.

The current #1 item is case 9433 (iPhone support).  While it sounds good at first blush, iPhone development is a big break from how REAL Studio works currently, and it requires a lot of intermediate changes and there’s no evaluation from REAL Software on how long it would take to implement iPhone support or what we would have to give up during that time frame.

For example, the current #2 item is case 738 (Controls and Window Backgrounds Flicker in Windows) and is a huge problem for Windows application and my guess is that it hurts RS when Windows users evaluate REAL Studio more than they know.  Would you rather fix this gaping bug or have iPhone support?  Me, I want and need, this bug fixed.

Unfortunately, there’s no way to vote an item ‘down’.  The current system is rigged to only tell how many people think it’s a good idea.  There’s no way for RS to get a feel for how many think the top item is a BAD idea, or don’t think it should be a high priority item.

I personally think iPhone support is a rabbit hole of time and money that RS could use to adding some nice features and cleaning up long standing bugs.  To support the iPhone REAL Studio has to add a number of very important things before it can begin to *start* development:  Cocoa (currently in beta), LLVM compiler support (currently in beta for RBScript) only, new editors, and untold engineering problems on three platforms (is that even possible?).

Cocoa has taken close to two years to implement and ‘new features’ have slowed down (partially from Cocoa and partially from our requests for more bug fixes).  RS has talked about LLVM compiler support – first with RBScript and then for the entire app and who knows how long that will take to get working 100%.  The other items?  Only the Universe knows.

I urge all of you to play around with the Feedback application and find your high priority bugs and mark them as such.  This is the only way (currently) to tell REAL Software on what your priorities are.  If you want iPhone support, that’s great, but I caution you to be careful with what you wish for.

Happy coding!

Fellow REALbasic developer, Christian Miller penned an interesting blog post at http://www.pariahware.com/blog/?p=248&utm_source=rss&utm_medium=rss&utm_campaign=real-software-the-opposite-of-love-is-not-hate-it-is-indifference.  I suggest you read it.

The stage that Christian didn’t add was what happens after acceptance.  This is the point where you ask yourself, “So what am I going to do about it?”  As I see it, there are only three options that are worth talking about.

Deal with it.  Accept the fact that RB is a flawed product and learn to work around its many deficiencies.  We all know that RS is a small company and can’t devote as much resources to it as say an Apple or Microsoft can to their respective development environments.

Leave.  Move on and use the tool(s) that work for you.  I’ve said this to many people:  If you expect RB to make a great Mac OS X only, Windows only, or Linux only application you might be very disappointed.  If you’re looking for a good cross-platform application using one code base it’s one of the few tools available.  The other dev tools available wouldn’t be considered Rapid Application Development tools in my opinion.

Try to change the situation.  This is the approach that I took.  One of my goals with the Association of REALbasic Professionals was to bring the conversation out and be more vocal with what we, the professional developers, need and want.  I found the training materials wanting so I started my own video series available on my website.  I blog regularly about RB here and on the ARBP website.  I’ve written tutorials, answered questions in the RB forums, talked at RB conferences and, written articles.

Without patting myself too hard on the back and injuring myself, I have been a pretty vocal supporter of REAL Software.  Hopefully you all have read the posts where I’ve been just as critical of REAL Software.  I’ve hitched my wagon, so to say, to the REAL Software bandwagon because I like the product, like the people that work there and, it has satisfied the requirements of my company and my clients for a decade.  I’ve been called a shill for the company and I’ve received hate mail for my anti-REAL Software stances.  My point is that I’m not a mindless cheerleader for the product because that does no one any good.  My family and my employees families fates are intertwined with the fate of REALbasic so I need it to be a viable product.

From my perspective the constant focus on new hobbyist users does absolutely no good for my business.  Too often new features are implemented that are ‘good enough’ for the hobbyist but suck for me (think toolbars, the report generator, htmlviewer and Windows flickering to name a few).  The hobbyists can’t pay for advanced features.  Businesses can, and will, if it makes sense for them.

RS is right to be proud that they ‘eat their own dogfood’ and that the RB IDE is made in RB.  That’s great, but making an IDE/compiler isn’t what I make.  Its obvious, at times, that there is a disconnect between what RS perceives we need and what we really need.  I’ve been using RB since the 3.5 days and yet there’s only one Date control, one Calendar control and one alternative to the listbox (i.e. grid).  In the corporate environments I used to work in that’s unacceptable.

I’ve long advocated that REAL Software create an internal consulting group.  Start with one person.  That group bids on potential projects like all the other developers in the network (to make it fair to existing developers, their rate must be HIGH).  When they’re not bidding or working on projects they do two things:  1)  they create real world examples and check each one for each release to make sure they still work; 2) They create training videos and tutorials, and answer tech support issues.

Having an internal consulting group does a couple of things:  1)  they quickly learn the pain of making real world applications in REALbasic; 2) provide valuable feedback to the powers-that-be in RS on what needs to be fixed and in what priority; 3)  it’s a (potential) revenue stream; 4) Makes sure that the documentation and examples really work; 5) Makes corporate users feel better knowing that if their own development team gets into trouble RS can back them up.

The truest definition of insanity is doing the same things over and over again and expecting a different result.  As we’ve seen with some very vocal criticisms (like Christian’s) and others, the perspective is that RS is doing the same thing over and over again and failing.  Unfortunately, so are we, the users.

I’ve written a few times about The Sixty One. I thought it was a great example of a web app that works well.  I was able to discover some great new bands and for a few of them I track their progress to see if they come to town and play.

Unfortunately, The Sixty One is a prime example of how redesigning the user interface can make your existing user base very angry and make them leave.  Common complaints about the new design are “antisocial and unnavigable” and I happen to agree with them.  The new changes made a great music discovery site not nearly as much fun and discover new bands.  It sure looks pretty though.

Microsoft has gone through similar criticism with the Office ribbon.  Some people love it and others hate it.  The few times I’ve used Office with the ribbon I was frustrated beyond belief because of the way *I* learn how to use applications.

A friend recently commented to me that they learned to like the ribbon.  I’m not sure that Microsoft would get that benefit (of time) if Office wasn’t ubiquitous.  I can say that as a Mac user I’m not excited about getting the ribbon in the next version of Office but them I’m already using Pages and Numbers more and more because they do everything I need them to do for far less money and less bloat.

From my own experience, we went through interface changes on Task Timer, our Mac/Windows desktop application that tracks your time.  It’s a very simple interface.  Version 1 and 2 let you track one project/task combination at a time.  People complained so we opened it up to five.  People (mainly lawyers – go figure) said that five simultaneous timers weren’t enough so we made it unlimited.

We rewrote the interface to allow an unlimited number of simultaneous timers and project and task combinations.  The beta users were very happy and we were happy too (since we use it every day as well).  We released and the very first bug report was from a long-timer user who complained that we destroyed the simplicity of the interface.  I guess there’s no winning.  Thankfully, with a few minor tweaks we were able to make that customer satisfied but most users will just walk away in disgust.  It’s not easy to get a second chance.

Every time FaceBook changes their layout there’s always a round of complaints.  I generally fall into the group that is willing to work with it but I do have to admit that I generally don’t mind the changes after I’ve gotten used to it.  But then, I also find that the new interface isn’t that much better than the old one – usually.

I sometimes think that companies redesign their website and products because they’ve got designers on staff and they think the designers need to earn their keep.  Don’t fall into that trap and change the interface ‘just because’.

Interface changes should be well thought out to satisfy existing users and to get new ones.  Doing so without some serious thought and effort, both before and after the change, can result in people abandoning your product or service.  Tough to stay in business that way.

Any other examples of a bad user interface change?

Paul has an excellent blog post on the new name change of REALbasic to REAL Studio at http://www.rbdevzone.com/2010/02/real-studio-about-the-name-change/.

I don’t have a whole lot to add because I agree with most of his suggestions.  I do have one bone to pick with the use of ‘Enterprise’ as the top of the line REAL Studio product.  REAL Studio isn’t big in the ‘Enterprise’ market and naming it such doesn’t give you an automatic ticket into it.  If anything, it limits the current Pro owners who say, “I’m not an enterprise developer so why should I pony up the money?”  Perhaps, ‘Premier’ or ‘Ultimate’ might have been a better term.

Thinking back over the years at all the of the ‘hot’ programming languages, they’ve all had interesting names.  Java, Python, Perl, Ruby on Rails all have one thing in common:  They don’t say a damn thing about what they are or do.  But, boy, do the names stick with you and sound cool when you talk to a group of people.  ‘REALbasic’ not so much.  Like BASIC would be anything but real?

Enough griping.  Changing the name of the product or company is a huge gamble it’s not one to be done lightly.  One would hope that a name change with the product could invoke images of coolness, power, imagination, something hidden slightly out of view, and something mysterious enough for folks to check it out just because it sounds like those things.

Maybe something that gives you a hint of the cross-platform capabilities of what it can do.  How does “Crossbow” sound?  I can see the marketing campaigns now.  “Hit your cross-platform targets with Crossbow!”, “Crossbow is powerful enough for three platforms, but easy-enough for the mere mortal to use.”  The IDE icon changes to a Crossbow or Arrow sticking out of a target.  “Introducing Crossbow by REAL Software” sounds better (to me) then saying, “Introducing REAL Studio by REAL Software”.  Too many ‘reals’ in there for my taste.

Anyway, random thoughts on a Friday.  What say you?

Since REALbasic (now REAL Studio) 2009 R5.1 updated the SQLite database engine the RB Forums have had more than a few RB users complaining that the database no longer works.  Thankfully the community has been able to get the message out that the AutoCommit property of the REAL SQL Database is now, by default, false.  I think it should be true by default and the RS did the users a disservice by forcing this change on us.

As an advanced user I understand completely why autocommit should be false.  However, as someone who has fielded some of the forum questions and have even have this bite me in an old project I can’t imagine why this change was considered a good idea.

I’m not sure if the change fixed a bug or the RS engineers realized that it wasn’t working the way they expected it to but setting the AutoCommit to false, however, breaks a lot of existing programs.  That all by itself, in my opinion, was a big mistake – even if it ‘fixed’ a bug.  Someone evaluating RB for their DB application now sees a spate of “The database doesn’t work for me anymore” messages in the forums.  Are they going to really look much further even if the solution is as simple as db.autocommit = true?

Second, because the change is silent and subtle, a lot of developers were pretty mystified (and pissed off).  Heck, I didn’t spot it until I was doing the REALbasic training videos and realized that data wasn’t being saved.  I’ve been using RB for for over eight years and I spent more than a few minutes scratching my head.  How does that make a beginner feel about REAL Studio?

I know that I should be checking the error condition of the database after every transaction.  I know that I should be handling the commit and rollback on my own.  I know all this and do those very things (most of the time) and yet still I got bit.  I can’t imagine how the rest of the RB universe felt when they finally found out why their db apps weren’t working properly any more.

What’s worse is the Language Reference for AutoCommit is lacking anything close to an appropriate example.  The AutoCommit entry has this to say:

The default is False: Changes open implicit transactions that you must close explicitly. If you set AutoCommit to True, then the database will no longer open implicit transactions for you, and instead, will automatically commit each database change immediately. It is recommended that you leave AutoCommit set to False unless you understand the implications of setting it to True.

How about a little discussion on the implications?  And of course there’s no example of how to properly do this unless you’re smart enough to check out the examples in the parent REALSQLDatabase  entry and smart enough to realize that you also need to read the examples in the Recordset entry.

Let’s be brutally honest for a minute.  Most RB users want their changes to be committed automatically because they’re not SQL guru’s.  They just want their application to work and don’t care about what the ‘best practices’ are for databases.  It’s been a while since I’ve used VB6 and ADO but I don’t ever remember having to tell my data to commit.  I do remember having to add code to start a transaction and commit and rollback my transactions.  So why was this RB change a good one?

Unfortunately, now that AutoCommit has been like this for a few releases we can’t put the genie back in the bottle.  I would ask that in the future that REAL Software deprecate ‘broken’ methods and replace them with a new one so that it’s obvious that something has changed.

Did the AutoCommit change affect you at all?  Did it make sense right away or did you have to hunt the reason down?  Was the change necessary and a good change?

Over on the Association of REALbasic Professionals website, I wrote up a short review of REAL Studio 2010 R1.  Look in the Blogs and Opinions section or follow this link.

Summary:  Smallish interim release with not a whole lot of new features.  Bunch of bug fixes.  A couple of new bugs introduced that may or may not affect you.

REAL Studio 2010 Release 1 is now available.  Note that that IDE is now called REAL Studio instead of REALbasic.  The language is still REALbasic.  So in other words, RS announced RS 2010 R1 (now won’t that be fun until we get it straight?)

Perhaps the biggest change is that now the documentation is now online at http://docs.realsoftware.com.  Yippee!  It’s about time.  At the last REAL World conference in 2008 (!?  has it really been that long since RW!?) there was much talk about doing this.  Nice to know that it only took 2 years and it being #10 in the new Feedback list for it happen.  Sorry for being pessimistic but, in my opinion, this should have been done a very long time ago.

This doesn’t replace the built-in Language Reference or PDF documentation so you don’t need to be online to access it.  Hopefully this means that the Language Reference gets better as we users can start adding usage notes to make it more clear on how the various pieces should work.  How will the online changes affect the built-in Language Reference?  No idea, but hopefully the content changes based on user entries in the online version.

Unfortunately, there is no word (yet) on who can edit the content.  I have no doubt that RS (the company and not the IDE) will limit who can edit the content simply because that was their number one concern in various discussions at REAL World.

The 2010 R1 release still does not support Cocoa builds.  More in-depth review of Studio 2010 R1 later in the week depending upon work load….

Thoughts about the online documentation?  Good, bad, indifferent?

Someone asked me the other day what ‘feature complete’ meant.  I replied that I felt it meant that everything you intended to put into the application is there and not missing.  Other people gave other responses but it got me to thinking.

Here is the definition of ‘feature complete’ from Wikipedia:

A feature complete version of a software is not yet final, but contains all intended functionality of the final version.
Usually a feature complete software still has to undergo testing and bug fixing as well performance or stability enhancing before it can go to release candidate and finally gold status.

I think the semi-permanent beta status of open source and web software skews our expectations.  We’re so used to the term ‘beta’ being applied to software we’ve really lowered our expectations of software.  It used to be that software at the ‘alpha’ stage was feature complete but functionality could significantly change with usability testing.  ‘Beta’ stage was when all functionality was complete and usability testing started, usually by allowing a bigger group to test it.  Any bugs get fixed and a new beta version is released to make sure the bugs were fixed and no new bugs introduced.

Finally, the ‘Final Candidate’, or ‘Release Candidate’ was a fully functional version of the software that if everything worked properly it would be released to the public.

The Wikipedia definition for ‘Release Candidate’:

The term release candidate (RC) refers to a version with potential to be a final product, ready to release unless fatal bugs emerge. In this stage of product stabilization (read QA cycle), all product features have been designed, coded and tested through one or more Beta cycles with no known showstopper-class bug. When a version get to the Release Candidate cycle, only one iteration should be necessary.

Obviously, these definitions are fluid – at best.  Problems discovered late in the beta stage could seriously affect functionality and certainly a major flaw discovered in a Final Candidate could (and should) push a public release back.  If you have a ’set in stone’ release date, however, how does that affect your releases?  I imagine that it severely limits your flexibility if major problems are found – especially if you have some sort of contractual obligations to release.

Is this your understanding of the software process?  Or is software now so complex and so fluid that we need lowered expectations of what software should be capable of doing for us?  Is it okay to release with known bugs as long as it’s ‘good enough’?