I am worried about REALbasic, or now, REAL Studio. I have been a fan since it was a Mac-only product, running on OS 9, maybe even OS 8. I have been a writer for REALbasic Developer Magazine, spoken at multiple REAL World conferences, was an adviser to the Association of REALbasic Professionals, and am now a board member of that organization. I have loved this product and have been sad and mad at both REAL Software and the community.  The stages of grief:

  • Denial: This can’t really be the state of the community.
  • Anger: Why are they going in that direction?
  • Bargaining: I have had debates with Geoff.
  • Depression: Saddened that I may have to move on from my favorite programming language.
  • Acceptance: This will be bad for REAL Software, as more people get to this stage. I am just about there.

In the past, I have written posts about the state of REALbasic and its community. The longer I observe the community, the more sad & angry I get. I have been using REALbasic since v2. In that time, I have seen REALbasic flourish and now stagnate. It has stagnated for years and is now settling for mediocrity instead of excellence. So, if anyone from REAL Software is reading this article, it is for your own edification. It is not to solely bash the product REALbasic.

I’ll get straight to the point of the problem:  REAL Software favors the hobbyist and allows the professional high-demand customers to flop around on the ground like fish gasping for breath out of water.  The problem with this thought pattern is when these “fish” die, it will be nearly impossible to bring them back.  The side affect of these dying fish is two-fold for those of us professionals still gasping.  The REALbasic ecosystem is unhealthy, and instead of a giving community, it is a black hole of novice questions that could easily be answered by opening the language reference in the REALbasic product itself. 3rd party vendors are ridiculed for trying to make a living by actually charging money for their work. It is no use trying to rationalize with the people in the community — the people there now want everything for free, and don’t want to put in an effort.  This is the class of people that REALbasic is attracting.  Perhaps you are reading this and are having trouble getting a grasp of what I’m saying.  For you, here is a real world example.  Go to your nearest Target store. Look around, study the people… how do they dress & how do they act?  Got it?  Good. Now, go to the nearest Walmart and see the difference.  REAL Software is attracting far too many Walmart class people to REALbasic.

Yes, previously I blamed the community.  But after further thought, it is the company behind the community.  If REAL Software wanted to change the community they could. They have the power to change it, and heal the flailing REALbasic ecosystem.  Here is how they could do it:

  1. A 3-tier product is too complex.  It wreaks of Microsoft’s 7 OS SKUs. Offer the language and sell cross-platform development as an add-on.  Up-sell the the database server if you really must keep it.
  2. Consider dropping the database server. The licensing options are not attractive and there are too many open source alternatives.
  3. Allow developers to pre-compile code (libraries) that can be sold as REALbasic add-ons. This is a much better alternative to the half-baked “encryption” we now have, which has been broken in the past (2006!), and the broken option is the default!  A few years ago I mentioned the latter and watched as a developer made the “new” encryption option selected by default, and check in the change, but mysteriously it was removed by the next release of REALbasic.
  4. Allow an API for the IDE so that 3rd party software can extend it.   Allow tools to analyze the code, insert code snippets, drive the IDE, and extend it.  One of the best tools that I used in VB was from a third party.
  5. Work on reducing the size of the executable created.  When I release a shareware product, I am embarrassed by the size the binary.
  6. Speed up the launch of the IDE.  I have reduced my plugins to the bare minimum that I can. In the time it takes for REALbasic to start up, I can launch Xcode a number of times.
  7. Pre-compile plugins in the background as the developer is coding. When I want to make a build, I don’t want to wait for that.
  8. Plugins should be able to be added dynamically without needing to re-launch REALbasic.  (See 6 & 7 above.)
  9. Give the fanatics the ability to make REALbasic the best IDE & language possible.

And now the do not’s:

  1. We should not have had to wait for Apple’s removal of Carbon APIs before Cocoa APIs were taken seriously. Get it done!
  2. Stop canceling the REAL World developer conferences!  No, we don’t want mini-regional PR conferences. We want one big conference where we can gather with like minds.
  3. Customers do not want to hear about “small company” & “limited resources”; we want solutions. If REAL Software can not provide them, it would be nice to be able to point them to a 3rd party that had the ability because the IDE was able to be extended.
  4. You are not Apple! Stop trying to be everything to everybody.  Concentrate on the core of REALbasic & do it well. Let others build, say, a report writer.

If you are still reading this, you probably see a theme. The IDE needs to be opened up so that REAL Software can work on the language & IDE. Power users need more tools. Until then, I fear for the future of REALbasic as more of the fish die when the Acceptance stage is reached.  For years I thought that Xcode and Interface Builder were too complicated. That may have been the case at one time.  But it isn’t anymore and REAL Software should be concerned about their Mac-only customers.  After spending the past few months in Xcode, it is not nearly as bad nor as complicated as I had thought. It looks better and better every day.

This has been a loving warning letter to REAL Software…  from a long time customer, supporter, and evangelist who has been pushed out of his comfort zone due to your corporate decisions.  For your sake, I hope you take to heart what has been written.  If changes aren’t made soon, it will stop hurting me when I launch REALbasic, because I won’t be launching it anymore.

I just spent days looking for how to make an iPhone effect similar to OS X’s “genie” effect when a window is minimized to the Dock. It would have been nice to know it was a private API before I wasted so much time looking….

http://stackoverflow.com/questions/428110/how-can-i-replicate-the-trashing-animation-of-mail-app

Do you know which OS your customers are using?  Both Panic and The Omni Group do.  I think this information is important, if not a curiosity regarding the state of the Mac OS.  It is astounding to me that people are still using Mac OS X 10.3.  As a struggling college student I didn’t upgrade my hardware often, in fact, I’ve never owned a G3 Mac nor a G5 Mac.  However, I always kept my OS up to date.  I’ve made it a policy here at Pariahware to support the current OS and the previous OS for desktop operating systems.  As of this writing, for the Macintosh that means OS X 10.6 (Snow Leopard) and 10.5 (Leopard).  For Windows that means Windows 7 and Vista.

When one is developing software, it is important to decide what platforms will be supported.  Sometimes the requirements placed on software are only placed there for support reasons.  Other times the requirements are there because of dependencies.  For example, one of Pariahware’s products, Doc Merge, requires Word 2008 on Macintosh and Word 2007 on Windows.  Why? Because the scripting functionality for Mac won’t work on the previous version, and the other scripting for Windows will throw errors if 2007 isn’t installed.  Even though some people didn’t meet the system requirements, they were trying anyway, not that I blame them.  But, the error reporting mechanism we use would give us strange errors telling us that requirements weren’t being met.  Now, if the user is doing this willingly, no problem.  However, if the user was unwittingly installing the software it looked bad for Pariahware.

To alleviate this problem, in the latest version, I added some checks to Doc Merge at start up.  So, on OS X it checks to make sure that the OS is 10.5 or 10.6.  It also checks to make sure that Word 2008 is installed on the system.  If either of these doesn’t qualify, the user is told with an apology which requirement has not been met and the application quits.  For Windows, the application checks to see if the user is running Vista or 7, then it checks the registry for Word 2007.  Again, if one doesn’t meet the requirements a similar dialog is displayed.  While this may seem draconian to some, the error reports for the latest version have quit coming in. To me, that shows an improved user experience, and in turn, shows an improved quality in the product.  Another one of Pariahware’s products is File Stitcher.  On Windows, a check was added to see if QuickTime had been installed because File Stitcher required it.  Since iTunes is ubiquitous it is rare to find a Windows system without QuickTime, but it can happen.  Macs come with QuickTime so it is not an issue.

To sum things up, if one is developing a product with certain requirements for reasons other than support, add checks to your applications to improve your user’s experience with your product.

Let’s face it, having to learn the ins & outs of a unique database interface for each type of database we come across is annoying.  If you’re using a PostgreSQL, MySQL, or SQLite database, you’re either using the archaic command line interface each with their own syntax, a web-based interface, or a specialized GUI application.  If you need to administer the MySQL database, you’ll need to either command line your way through or find an application.  But if the next day you need to administer a PostgreSQL database instead, you need a new set of commands to command line your way through, or use a separate application.  Now the  phpMyAdmin and phpPgAdmin guys have tried to solved this, but to be blunt, web interfaces stink.  In fact even if you use these two web interfaces, the GUIs are nothing alike.  It is as ridiculous as it is irritating.

So, how would you like a single desktop application that would let you, your employees, and coworkers mange, maintain, and query PostgreSQL, MySQL, SQLite, Oracle, and perhaps any other database that can be connected via ODBC?  What if it would work on your Mac machines, your Windows machines, and your Linux boxes? Well, I have already started on this and have the ability to read PostgreSQL and SQLite databases since those are the two that I use the most.  Currently databases are readable but not editable; one step at a time.

Before I go further into development, I’m looking for your thoughts: If you were to buy such an application…

- What are the most important databases that the application supports?

- Would you want to pay more to have access to all supported databases or purchase access to databases a la cart?

- Is starting with simple query & editing enough, or would scripting, filtering, and triggers be required in a first release?

- What are the most important features for a SQL editor in your mind?

Over the long weekend we soft launched Doc Merge version 2.1 for both Macintosh & Windows. For Windows users this version is mostly a face-lift. And by a face-lift, I mean that the application is now driven via toolbar buttons. But for Macintosh users, this is a major overhaul. They have been stuck at version 1.1 since 2005!  As a predominantly Mac shop, it really hurt us that the Windows version of our product was better than the Mac version. This post will get a little geeky, so if you choose to continue reading, make sure that your propeller hat is securely fastened.

It has been a long road to get here, but we are happy to finally be able to support Microsoft Office 2008 with Doc Merge.

Most of our products are developed in REALbasic, a tool that allows us to more or less write code once and deploy on Mac, Windows, and Linux. Of course there are minor tweaks to make the application work properly for each platform, but most of the code is exactly the same.  At the heart of Doc Merge has been something called Office Automation.  Office Automation is a “VB Lite” language that allows a third-party application, such as Doc Merge, to control Microsoft Office products. Unfortunately with Office 2008, Microsoft decided to remove this ability from their suite of products for the Mac.  We could no longer “drive” Word in the way we had in the past on the Mac, and how we still do today with Word 2007 on Windows.  But this problem was actually the third hurdle.

The first hurdle was actually painful for the users of Doc Merge for Macintosh to install it.  In order for users to use Doc Merge, they had to place Doc Merge in the “Office” folder of “Microsoft Office 2004″ folder, which was located in the Applications folder of OS X.  Due to the agreement between REAL Software and Microsoft, this was how it had to be done.  Although annoying for the end user, this solution did work for quite some time until REALbasic dropped the old Macintosh executable format called PEF for the new Bundle-based model, that was the second hurdle.  With PEF, the executable was a single file with a data fork and a resource fork.  Once PEF was dropped, an application built with REALbasic could no longer drive an office application because in a Bundle-based application, the executable is actually located in a MacOS folder, within the Contents folder of the application’s .app folder.  We waited for a REALbasic-based solution.  It never came.

When Office 2008 was released we figured REAL Software would update their Office Automation components since Microsoft had removed the “VB scripting” capability.  I met up with one of the engineers at REAL World conference and asked about this.  The unofficial response I received basically said that REAL had no intention of updating that portion of REALbasic and that I should look into automating with the Apple Event model or the Applescript model.  After talking to some other developers and even obtaining some sample code, I decided that the Apple Event method was not going to work.

I never had any intention of learning Applescript.  Its ultra high-level coding style was very confusing to me.  I had even purchased and read a reference guide for converting the VB model to Applescript and it didn’t help.  Additionally, there didn’t seem to be a way at the time to create and run dynamic Applescripts from REALbasic. The latter is no longer the case, but I still find Applescript difficult to write.  With the use of the MBS plugins, Doc Merge can now generate a custom Applescript and run it.

With this Applescript solution, Doc Merge no longer has to be in that pesky “Office” folder.  Doc Merge 2.1 for Macintosh is also now able to be a Universal Binary application!  Previously on Mac and currently on Windows, the Doc Merge engine would give Word step by step instructions, so if Word returned some sort of error message, Doc Merge could try something different in order to continue.  With Applescript, we no longer have direct control over Word.  Instead, a custom script is dynamically  created, compiled, and then sent off with a “good luck”.  If the script fails, we know about it but are mostly helpless.  However, the only time we’ve seen this fail is if a Word Document is password protected and the user does not unlock the document; not a big deal.

Over all, we’re pretty happy with this new release of Doc Merge for Macintosh. The only thing that we wish could be changed is that Word apparently can not be driven via Applescript and remain hidden.  Other than that, it’s an easier install (read: nothing to do), it’s a Universal Binary, and it has a pretty, new, toolbar driven interface!

I’ve been using REALbasic for many years and I’ve spoken at multiple REAL World conferences.  I’ve partnered with REAL Software to sell my REALbasic add-ons via their store.  Before becoming an Association of REALbasic Professionals board member, I was an adviser to the board.  If you’re wondering, the board membership receives no monetary compensation.  I really like REALbasic and if one needs to develop cross-platform software, there is nothing better.  And that is what makes me concerned for the state of the community.  Let me explain:  Recently there was a thread on the REALbasic forums where people were complaining about the quality of the examples provided at the ARBP web site.  It was said that the examples were “unprofessional” or “beginner level”.

Granted, the person who complained about the examples being unprofessional was probably a kid who wanted ready-to-go, drop-in-place, “professional” code, with no effort of their own.  If that is what one wants, then go buy a license for the Einhugur plugins.  We’ll call this person the “pie-in-the-sky-everything-should-be-free-and-open-source-give-it-to-me-because-I-deserve-it-and-don’t-want-to-work-for-my-education”, or “type 1″.

The other complaint was that the examples were too “beginner level”.  Beginner-level is completely relative.  While one may know how to use databases, perhaps they have never used the graphics object.  In one skill set this person is extremely proficient, and in the other, they are a “beginner”.  We’ll call this person “I-pick-nits-because-I-am-bored”, or “type 2″.

What do person Type 1 and person Type 2 have in common?  They are both willing to complain, but neither one is willing to help to make the existing ARBP examples better or provide new ones.  If the REALbasic community is to survive & prosper, then the community needs to start fending for itself.  We can not continue to wait for REAL Software to spoon feed us.  If there are examples from the REALbasic distribution or the ARBP repository, that are sub-par, “unprofessional”, or too “beginner level”, then feel free to make your own (or improve the originals) and upload them to the ARBP repository.  There is virtually 100% chance that your example will be available at the ARBP repository within days.

If you are a REALbasic fan, then just like a relationship the community needs to be nurtured.  If you do not give back, the relationship will die.  It is time to fend for yourself.  Get dressed on your own.  Learn to fly… whatever your metaphor.  The truth is this:

- REAL Software canceled REAL World.

- REAL Software announced and then canceled the “mini” REAL World events.

- REAL Software is busy getting REALbasic Cocoa ready.

- ARBP helped put on the REALbasic conference in Colorado.

- ARBP is part of your community.

- You need the community just as the community needs you.

Stop abusing the community:

- Try to solve your problem before you ask your question.

- Search the NUG Archives or the Forums before you ask your question.

- If you figured something out, create a quick example project and upload it to the ARBP repository.

- Support REALbasic 3rd party developers. They are a critical part of the community and represent the level of health for the REALbasic ecosystem.

One final note.  Do you want REALbasic to fail?  If you’re not part of the solution, you’re part of the problem.  Let’s all be a part of the solution and support the language that we love.

I really only have one major gripe about the iPhone. It is that the VPN option doesn’t always try to reconnect, therefore potentially sending / checking for e-mail in the clear. When I turn on the VPN option on my iPhone, I want it to always stay connected. I don’t care if I’ve switched from 3G to Edge to Wi-Fi or if even if the phone has gone into “sleep” mode. VPN VPN VPN! Currently, if the network changes or if the phone “sleeps”, the VPN connection is dropped and it never attempts to reestablish the connection. Granted, this is usually not a problem on the cell network or encrypted networks. The BIG problem is the open Wi-Fi network. Last week I was on vacation and fired up Wire Shark at the hotel. To my dismay, I saw my phone logging in to check my mail. BAD APPLE!