BKeeney Briefs

In the first part of this series I talked about how I got involved with Real Studio.  In part two I talked about some of things I’m currently doing in Real Studio.  In this post I’ll talk a little about the future and what I think where Real Studio will be in the future and my needs and wants as a professional user.

For many people, using Real Studio is a Love-Hate relationship.  Mine is no different.  I’ve been using it for over ten years and while I find it easy to use and very powerful, there are times I feel like putting my fist through the monitor due to frustration.

Real Software releases a new version of Real Studio roughly every ninety days as part of their Rapid Release Model.  From one aspect it’s nice since I know when a new version is going to get released and plan for it.  I know that there will be some new features and a whole bunch of bug fixes.

Unfortunately getting a new version is often an exercise in futility because new releases can sometimes break existing functionality.  Since I work on so many projects I’m often waiting on a particular bug fix in the next version so I’m forced to upgrade.  The frustration of finding yet another bug upon trying the new release is sometimes too much.  If you find me grousing about Real Studio (see last summers Windows rants) it’s generally after one of these types of upgrades.

I’ve been very critical of RS in past because of new features that just plain don’t work.  Rightly so, in my opinion.  New features don’t get tested in the beta process because there’s usually no documentation and usually no example projects showing how it’s used.  Either case is bad and it has to get better.  The perception that Real Studio is buggy, wether right or wrong, has to improve.

Look, I know that every release has significant bug fixes and only a few new features.  I know because I’m part of the beta program and have been for a long time.  But as a beta member I don’t feel like the program lets me help Real Software very much.  I can’t tell you how many times I report a bug, it’s gets marked as fixed and then I have to scour the release notes looking for bug reports that look like mine.

The feedback system and releases aren’t designed to help me verify the fix.  I feel that a bug isn’t fixed until the bug reporter has verified the fix.  From my aspect it’s very inefficient and I wish it was better.  But since it’s not my system I can’t do much about other than offer suggestions.

The future on Mac OS X is Cocoa.  I expect that in the next release or two, the Mac OS X IDE will be built for Cocoa.  When that happens, you’ll know that Cocoa is really ready.  Building for Cocoa will give RB users the ability to harness some of the Cocoa goodies that Mac users come to expect from their applications.

Unfortunately, Cocoa isn’t going to help Windows or Linux as it just makes the platforms that much more different.  However, I do know that much of the work that has gone into Cocoa has involved rewriting major portions of Windows and Linux to fit the newer event models rather than the old Carbon/Classic model.  I don’t know the specifics but it wouldn’t surprise me if almost all of the frameworks was rewritten accomplish this.

I’m not sure where Windows is heading in the future.  Real Software is a Mac heavy company and it’s hard to know how serious they are about Windows.  Last summer there were some very easy and very serious Windows bugs that bit me very hard (because of the upgrade cycle) that very nearly cost me a big project.  I just don’t see much going on for advanced Windows support but perhaps that is just a byproduct of the march to Cocoa.  After ten years they still don’t have full COM support and without it there’s just a bunch of stuff that Real Studio won’t be able to do.  It’s also unknown when 64bit support is coming and when Microsoft will switch over to a full 64 bit OS.  I think this is as every bit as important as the switch to Cocoa on the Mac side.

I have reservations about Linux support.  I wonder if the time and effort is worth it in sales for Real Software.  As a consultant I get no one asking for Linux apps but perhaps that’s anecdotal evidence since I’m heavy into Mac and Windows development.  Also anecdotally my blog and website just have a few percentage points of Linux users that visit on a regular basis.

We know that a User Interface change is coming.  Geoff demoed it at the Atlanta Summit but no pictures have surfaced yet.  From what I can remember, it should reduce mouse clicks as the Project Tab will be easily accessible all the time.  Unused events will not show in the Events list until you add them (I believe the most common event(s) will automatically be added).  A new tool palette was revealed that reminded me very much of xCode/Interface Builder.

I would also expect a lot of the Web Edition editor features will make it into the new IDE.  The in-line editors are generally okay but I’m not a huge fan of them.  I really hate the new Tab Order Editor as it’s confusing once you get more than a dozen controls on the window.  I’m also not a big fan of the object handles (that allow you to resize controls) since they’re a major pain to use – they disappear when you’re resizing.  This means that controls have to have special visual modes to show their sizes unlike the current Window Editor where controls have a visible outline.

One feature that I do like is the pasteboard that is automatically populated at the bottom of the WE page editor when placing non-visual objects (like timers).  This probably means that Dialogs will be rewritten to act just like the new WebDialogs.  One can hope that they will retain the existing methods.  I also expect the Radio Button control to be replaced by the RadioGroup – again, similar to what Web Edition did.

Some of these changes make a lot of sense from a beginner perspective.  They are common questions from new users and are a solution to aid them.  From a power user perspective I’m trying to be as open as I can to the changes.  Some will grow on me I’m sure with usage.  Others, I’m just as sure, will make me pine for the ‘old days’.

We can only hope that Real Software has a feature complete IDE when it makes it into the beta program and lets hope that they’re not adding major functionality to it during the beta.  Otherwise I expect a chorus of very vocal naysayers and boo birds.  A User Interface change is a big deal and should not be taken lightly.  I hope they do their own (very strenuous) internal testing on it before foisting it on us.

Eventually, Real Software will switch the back-end compiler to LLVM.  RBScript is already using LLVM and while that was a significant step, it’s probably going to be a lot of work to switch over all of Real Studio to it.  If my sources are correct, they’re going to writing their own linker for Windows which I have no doubt is more work than they expect (Cocoa was only going to take 18 months remember?).

Will LLVM lead to Real Studio being able to compile for iPhone and other mobile devices?  My answer is a big maybe.  I have a hard time figuring out the marketing for including mobile devices in the current product other than to saying you can reuse much of the same code, but just like with Web Edition you really have a separate product with separate editors and separate compilers.  I have no problem with a mobile optimized IDE that leaves the cruft of desktop and web apps behind.  I think it could be brought to market faster that way too.  Like much of the rest of this post, it’s pure speculation on my part.

One thing I wish was improved was the Real Studio debugger.  Anyone that’s come from the Visual Basic and .NET world understands what I’m saying.  The Real Studio IDE debugger just isn’t easy to use.  No watchpoints and always having to refer to the listbox to view variable values is huge pain (wouldn’t it be nice to hover your mouse over a variable and get the value in a tooltip?).  Many Real Studio users don’t even realize that you can view the call stack since it’s a popup menu (poor UI choice, in my opinion).  Many also don’t get the whole breakpoint and exception handling either.

There is still a bunch of essential controls missing from the standard control list.  After ten years there’s still no date, time, or calendar control.  While the standard listbox is fairly powerful, it’s a beast and you just get to a certain point where it’s too slow and cumbersome to use.  For those needing them, they’re forced to use a 3rd party set of controls.

I think much of these limitations is all based on how Real Software uses the tool themselves.  The IDE has absolutely no need for grid, date, time, or calendar controls.  You could certainly argue that the reason why the TextArea RTF support is so weak is because the IDE has no need for it.  The same with the lackluster support for TextField masks.  Likewise, to the best of my knowledge, the IDE does not use the built-in reporting tool and, it too, suffers from having no strenuous use from the company that designed it.  Modern toolbars?  Need I say more?

I’ve argued for years that RS could really use a consulting group that bids and works on projects just like the rest of us consultants.  A lot of the projects I work on run into the same constraints time and time again and I’m forced into less that optimal solutions.  I can submit Feedback reports until my fingers bleed, but until RS has to fulfill a need for themselves it probably won’t happen.  Personally, I’d welcome them into the consulting business.  Sure, it means more competition for me personally, but I’m okay with that as it will make the product better.

Sorry for the rambling post as there are lot of things that I’d love to see RS do a better job at and improve in the product.  I really do appreciate the work they’ve done as it pays for my, and my employees, salaries.  As a professional user my needs are vastly different than a majority of Studio users but as someone who spends a considerable amount of money on yearly license updates and the referral program, and spend a lot of effort selling the product to clients I feel that my needs should be aired publicly.  My time with ARBP has shown that many of you agree to varying degrees.

Those are some of my wants, needs, future predictions, fears, worries and gripes.  What say you?

 

In part one of this series I talked about the early chapters of my Real Studio story.  Today I’ll talk about some of the things we (because we have multiple employees) with Real Studio.

Let’s go back to the 2008.  That was the last year that Real Software held the REAL World conference in Austin, Texas.  I begged Real Software to let me have a meeting at 8:00 AM to hold an organizational meeting for a REALbasic users group of some sort.  I was surprised at the turnout and the Association of REALbasic Professionals (ARBP) was born.  http://www.arbp.org

Starting ARBP has been a job of persistence and overcoming inertia.  Since we started with nothing: no organization, no leaders, no website, no expectations, we really had no idea what we were going to be when we grew up.  Thankfully I was supported by an awesome group of dedicated individuals that really helped push the organization, and me, along.

In three years, ARBP has hosted two conferences.  The first was in Boulder, Colorado in 2009 and the second was in Atlanta, Georgia this past March.  Both of those conferences were recorded and are available for ARBP paid members.

Besides helping organize both events I’ve spoken at both of them.  So has my #1 employee, über programmer, Seth Verrinder.  Seth has been with us for three and a half years and has been an awesome addition to the team.  Without him, we wouldn’t be as successful as we are.  Between the two of us we’ve also written a fair number of the tutorials, newer projects in the source code repository, and articles.

Sharing code with the community is great way to contribute.  Many of us ‘old timers’ have a library of code just sitting around that would contribute to the community and help people just starting out with Real Studio.  Think about adding your source code to the ARBP Source Code Repository.

Speaking of training, in late 2009 I was contacted to do some video training for Real Studio.  They only wanted about eight hours of video and I felt that I couldn’t do the language or the IDE justice in that short amount of time.  But it did start my creative juices flowing and now I have over 30 hours of Real Studio video training material available at http://www.bkeeney.com.  That 30 hours comprises over 110 separate videos including most of the common Real Studio controls for both desktop and Web Edition.  Most videos come with a project file that you’re free to use in your own projects.  I have two complete series where I start at the beginning of a project and follow it through to the end.  Needless to say, I’ve been very happy with the results and the comments I get from users are very encouraging.

What sort of work do we do with Real Studio?  Well, it varies all the time since we’re a consulting firm.  In the past year we’ve done major updates to professional athletic training system (we did version 1 as well), updates to teleprompting software (we did the version 2 rewrite), major work a Web Edition project for an underwriting company, fixed some right-to-left language support in an existing Real Studio app, updates to a veterinary management app, and updates to credit repair software.

From-scratch projects include a PDF viewer/annotation/organizer app, a military strategy simulator, a family genealogy organizer, a front end user interface to a serial lightning detection device, a neurological test for patients with brain damage, a proof-of-concept app for a Mac OS X computer to talk to a electronic keyboard that uses a proprietary ethernet protocol, and a Web Edition app to share URL’s among registered users.  Most desktop projects are cross-platform.

On top of all that, we’ve created a number of smaller, proof-of-concept/training projects for folks that want to do something specific in RB but don’t have the time or inclination to learn it on their own.  These projects are actually kind of fun since they’re very specific and allow us to explore a control or API that we’ve not spent much time on without having to worry about the nit picky details of a full-blown application.

I’m very picky on how I organize documents (I am an engineer after all) so every now and then I go through the older directories as a refresher.  We’ve done a LOT of projects over the years and not one of them is similar to another one.

So how do I find the clients?  At this point we’ve been doing Real Studio consulting for a long time and a lot of long-term clients keep coming back for rewrites and major new additions.  I’m very happy about that as the relationship is already in place and they trust us.  It’s an awesome feeling.

Believe it or not, the video training has been a nice addition to our consulting business.  The progression is that people sign up for the videos and then after a couple of weeks (or months) they send us an email asking if we are available for work.  Because of the videos we already have a ‘relationship’ even if I’ve never talked to them before because they see how I work with Real Studio.

I’m also a member of the Real Studio Consulting Referral Program https://secure.realsoftware.com/store/consulting.php.  It currently costs $495 for twelve months and $295 for six months.  It’s worth it.  By the time a potential client sends in their information to the Find a Developer Page at https://secure.realsoftware.com/support/consultants.php they’ve already decided that Real Studio is what they’re looking for.

At one Real World I said being part of the Referral Program is “like shooting fish in a barrel”.  I still believe that.  The cost is insignificant.  One very small project and it pays for itself.  If you want to start working with Real Studio on a full-time basis, this is the place to start.

One last note on ARBP.  I’m happy, and a little sad, to say that today is my last official day as leader of the organization.  Tonight is our board meeting where a new board will take over and a new president will lead ARBP into the future.  I’m still on the board as Treasurer (assuming no one else wants it) but the day to day stuff will no longer be in my hands.  I urge you to volunteer as it’s a great organization that is always looking for help.  You don’t have to be a Real Studio expert (or professional) help out.

So those are the current chapters in the BKeeney Software Real Studio story.  What sort of projects are you working on?  How are you finding work?

 

I was asked this year to be a coach for my sons robotics team through First Lego League (FLL).  It was my honor and privilege to coach these fourth and fifth grade boys.  It is when I see activities like this I feel good about the future of our country as I fully expect each one of these kids to be the future scientists and engineers of our country.

For our school it was our first year in FLL.  We had 4 teams, each with 6 kids.  The season lasts from start of school to until the end of February and for our team we met once a week and for the last month we met twice a week.  All meetings were 90 minutes long.  That is an incredible commitment for coaches, kids and parents.  It spans football, volleyball, soccer, wrestling and basketball seasons (and I’m sure several others).

This years theme was Body Forward and the competition consists of two major components.  The first is the research project where you identify a problem and come up with a solution.  Our team had fun and chose the brain as their topic and our presentation was ‘Zombie Brain Inspectors’ because, as we all know, zombies like BRAINS!

The second part of the competition is where the real fun is.  There is a 4 by 8 foot playing field with a number of field pieces (made out of LEGO’s of course) with tasks (each with their own set of rules for completion) that you have to do in two and half minutes.  You build your robot using the Lego Mindstorms kit and software.  Our robot did well, partly I think, because we went through three major robot designs, and finally settled on a tank design that offered stability, flexibility, and repeatability (things you really want in your robot!).

The LEGO Mindstorms NXT programming software stinks, which is unfortunate, because it has marred an otherwise awesome experience.  It’s written in LabVIEW and while I’ve heard people rave about how good LabVIEW is – our experience was anything but that.

First, getting it to run on Mac OS X 10.5 and 10.6 was difficult (PPC or Intel didn’t seem to matter).  In fact, after trying for a month I gave up on it and went back to an old Dell laptop running Windows XP.  The installers on the CD’s don’t work in those Mac operating systems.  Period.  There’s a hack where you have to copy all of the files to your hard drive, modify one of the installation files and then install from hard disk.  Really!?  Leopard was introduced by Apple in October of 2007.  Simply unacceptable.

Once we did get it installed on my two year old Mac laptop the darn thing never worked right.  The mouse was always jittery and made it next to impossible to select the blocks.  It didn’t seem to matter if they used the built-in trackpad or an external mouse.  My team got so frustrated they all voted to switch to the Dell laptop.

Even once we got onto the Dell, our problems didn’t really go away.  We had permission issues with the help files that required fixing.  We had file corruption issues:  once during one of the practice rumbles!  Because of this we (okay, this one was mine but the boys loved it), “Save As will save your…bacon” and it did after we learned the ‘save as’ lesson the hard way.  Unfortunately, we discovered that saving to a thumb drive didn’t always work.  A file length of zero is a bad thing!  We also discovered that doing a Save As will sometimes rearrange your blocks for you and another coach reported having severe issues copying programming files from one computer to another.  Ya.  Not good.

Once you get into the development environment a couple of things strike you as being odd.  First, everything is a shade of white and grey making it hard on the eyes.  A lot of the really important text, while black, is tiny when it should probably be the most important thing on the screen at the time.  The  User Interface in the environment isn’t Windows, it’s not Mac OS X, heck it’s not even Java it’s some weird thing that I’ve never seen before.  One has to presume that this is the environment that LabVIEW creates.

The whole left to right programming paradigm is odd.  I think you could argue that a top to bottom approach would make more sense and would certainly make it easier to print out.  I don’t have a strong opinion about this as there might be some very good reasons to do it the way they did.  Frankly, making it look like LEGO’s is eye candy and could be left out in my opinion as it adds absolutely no value.

The NXT brick only has 4 input ports and 3 output ports.  Why do I have to specify which port on every block?  Why can’t I just say, somewhere, that Port B is the LEFT motor, Port C is the RIGHT motor, and Port A is the ARM?  Or that Port 1 is the LIGHT sensor, Port 2 TOUCH sensor, etc?  I can’t tell you how many times the kids kept changing the wrong motor or used the wrong sensor because they chose the wrong port.  Why can’t I customize the names of the ports?  That simple change alone would have made life simpler.

The Mindstorms software has the ability to add comments to your code.  It’s less than optimal because you can’t tie it to a block or group of blocks.  So if you make a comment and then insert or remove a block it doesn’t move and I’ll be darned if I can figure out how to move a comment once you’ve created it.  End result is we’ve taught the kids not to bother with comments and I find that to be troubling.

I live and breathe cross-platform software development on a daily basis so I am being very critical.  I can’t tell you how many times I’ve thought about how cool it would be to use Real Studio to develop a better, more modern Mindstorms application.  It would be  a MUCH better experience for kids learning how to program using the LEGO Mindstorms kit.  It would be a native Mac OS X and Windows application with the appropriate installation methods.

Alas, it is but a pipe dream.  FLL requires that the kids use the LEGO Mindstorms software.  I can’t tell you how much money I’ve spent on Lego’s for kids over the years.  You’d think LEGO could come up with some better software for all the money I’ve given them.  The software came out in 2008 and hopefully a new version is in the works.

Now that the season is over I will remember the good things about the season.  I will also try to forget the crappy experience we had with their software.

 

I said back in December that I’d write a review of REAL Studio 2010 Release 5 when 5.1 was released.  Well, that didn’t quite happen as I expected.  For one thing, the 5.1 release didn’t happen until January and now we’ve discovered more information about the main component of R5 – Web Edition and its deployment problems..

2010 Release 5 and the subsequent 5.1 release (released in 2011 – how does that work?) were mainly about Web Edition.  I did a significant portion of a big web app project using Web Edition and to put it bluntly, there are many bugs, holes and significant issues with all aspects of Web Edition and I can’t really recommend it for production apps right now.  There are still significant issues with browser compatibility that need to be ironed out as well.

Deployment of standalone web apps seems to be okay, but installation of FastCGI applications was hit and miss (mostly miss) on commercial web hosts.  Since it was pretty much a black box installation it either worked or it didn’t and neither RS nor the web hosts were able to help much in diagnosing the problem.  And now we’ve been told that FastCGI isn’t all that RS hoped it would be and a new middleware application needs to be on the server so it can run as a CGI application.  This is disheartening to everyone that put in significant time trying to figure out deployment issues (including me).

Obviously, despite all of the problems in the first release of Web Edition, my client does have a working web app on his website (sorry, can’t share the URL).  To me this truly does indicate how powerful the RS web framework is and with a little more thorough testing and polish it should be a nice addition to my toolset.  I see much promise in Web Edition.  It makes the creation of web applications very easy.

Most of the skills you’ve spent years developing for desktop applications can be transferred to Web Edition with very little learning curve.  It’s those little things you’ve come to expect in desktop edition that will make you feel exasperated.  WebPage constructors don’t work as you would expect and sometimes subclassing WebDialogs will cause them to just not work and the Application.UnhandledException doesn’t catch exceptions and doesn’t let you keep your web app running.  All of these, by the way, have been marked as fixed in 2011 R1 already so RS is being very responsive to the major issues.

The other significant part of Release 5 was Cocoa.  Many things were fixed and much of it is now working.  Of course the first project I tried in Cocoa failed miserably due to a graphics issue but that appears to already be fixed (after I submitted a feedback report with a reproducible example project).  So despite all the fixes it’s still a work in progress.

RS really needs as many people using Cocoa as possible to find those hidden or quirky problems.  Always remember that RS doesn’t always use their own product like we do:  so creating feedback reports with example projects is the best way to help them.

A very promising note, though, is that the Feedback application that is available to beta testers is now Cocoa.  In my usage it’s pretty solid – but not quite perfect.  But it is built using an alpha build of Studio 2011 R1.  So it’s close.

So if you missed out on R5/5.1 you probably didn’t miss out on much unless you were specifically looking for Web Edition and Cocoa.  The march to Cocoa continues and it’s getting better (really!).  Web Edition shows a lot of promise and WILL get better (it has to) and hopefully the deployment issues go away in 2011 R1 which will hopefully go into beta testing soon.

The Mac App Store, so far, has been pretty good for sales of Task Timer.  We have been running double of normal sales of the previous version.  Technically, version 5 was out before it was approved in the Mac App Store so that’s even more proof that the Mac App Store is doing well for us.  So from that aspect we are very happy with what we’ve seen from a sales standpoint from the Mac App Store.

What’s not very good is the amount of time it takes to get an application – even an application update – approved (or rejected) in the store.  We’ve been lucky that the few bugs that have been reported aren’t affecting everyone and aren’t critical.  We submitted our update on January 12th and didn’t receive a rejection until January 28th.  That’s 12 business days!

The rejection was from not linking properly to the HXRuntime library.  The problem and fix is documented on REAL Software’s blog.  What’s worse is that REAL Studio applications don’t even use this library so this is a false-positive result from some automated test that Apple implemented between our first second submissions.

I realize that we’re not generating a ton of sales from Task Timer so we’re not even a blip in Apples sales figures, but 12 days is an eternity when a customer has a problem.  They won’t complain to Apple, they’ll complain to me.  At the best I can offer customers to update outside of the Mac App Store but that’s a half-assed solution, in my opinion.  At worst, I’ll lose customers for life because I’m ‘unresponsive’ or write ‘crappy’ software.  I predict most people will be relatively forgiving but I think it depends on the cost of the software and what it does.

We are not the first and only developers to face this problem.  Panic, makers of the popular Transmit, had a similar issue that was thankfully taken care of quickly.  One has to wonder if a public blog post from a very popular developer didn’t speed things up a bit, but the point is that the process has a flaw.

I can’t believe that Apple is oblivious to this problem.  The wait times for app approval is just too long.

I’m not sure what the solution is.  All I know is that the current situation is not good for smaller, independent developers like me.  Wasn’t the Mac App Store supposed to be a boon for us?

Anyway, I’m not really all that angry.  I expect that approval times will get better as time goes on.  I would also expect that the automation tools they’re using internally will be available to developers for testing purposes (before submission) or, at the very least, some sort of automated testing submission process that, if not instantaneous, is light years faster than it is now.

What say you?

We’ve been very busy recently.  Besides all of our cross-platform desktop app consulting work we’re now iOS developers as well (feel free to contact me if you’re looking for iOS developers).  Our first iOS app, Task Timer for iOS, is now on the App Store.  This is the Lite, iAd supported version, of Task Timer, and simply lets you track your life and hopefully bill for it. This version works on the iPhone, iPad, and iPod touch.

Want to track how much time you spend commuting to and from your job?  Create a Personal project and add a Commuting task and the next time you get in your vehicle hit the start button and when you leave the car hit the stop button.  It doesn’t get much easier than that.

The same goes with your on-site with clients.  After the initial setup it’s as simple are pressing the start and stop buttons.  At the end of the day, week, or month, you can view a summary of all the time you’ve spent.

Task Timer supports multiple simultaneous timers for those multi-taskers out there that can bill multiple clients at the same time (yeah, I’m looking at you, lawyers).  The Lite version supports unlimited projects and tasks but does not sync to the desktop version.

What’s it worth to you to increase your billing by 30%?  Did I mention that the Lite version is FREE?

An upcoming (paid) version will be able to synchronize with the desktop version of Task Timer (for Mac OS X or Windows) all without being plugged in to your computer!  This will be a free upgrade for current owners of Task Timer for Mac OS X or Windows.

So never lose money again!  When we developed the desktop version years ago we saw an immediate 30% rise in billing!  Why?  Because we know, down to the minute, how much time we spend on a billable (and non-billable) projects.  It helps our bottom line with billing AND it helps us track how well we’ve done with our estimates.  If you’re not tracking your time you’re not doing a very good job at managing it!

We hope you enjoy this free version.

REAL Software announced yesterday that REAL Studio 2010 Release 4 will no longer be actively supporting the PowerPC (PPC) framework.  This really means that only major bug fixes will be done to the PowerPC framework and nothing new will be added to it.

At the 2005 World Wide Developers conference Apple announced the move to Intel and many people were shocked that they would give up the PowerPC line of chips they spent a decade promoting as being better than their Intel counterparts.  Intel was the future and blah, blah, blah.  Many people said the Reality Distortion Field was on full blast.

In retrospect it seems so clear.  One could certainly argue that Apple’s resurgence is, in part, because of their move to Intel.  With a growth rates in the 30% range in year to year quarterly sales growths it’s not very hard to come to that conclusion either.

It’s been five years.  Most consumers have an Intel based Mac and most businesses will probably be phasing them out in the next couple of years if they haven’t already.  On BKeeney.com, only 10% of visitors are running a PPC Mac.  BKeeney Briefs and the ARBP site are both less than 2%.  When 90+% of total visitors to your websites are on Intel it’s safe to say the Intel transition is nearly complete.

The reaction to REAL Software’s announcement has been calm, I think, mainly because no one is shocked by the move.  Most developers are most likely on Intel Macs and I think a vast majority of software buying consumers are on Intel now as well.

Since Cocoa is Intel only and the IDE will eventually be built using Cocoa this presumably means that the IDE will no longer run on PPC machines.  This is probably not a big deal for most REAL Studio developers.

It might be a big deal for developers serving the education market, however.  But since they’ve said they will not remove the PPC build option for several years that market should be relatively safe for the foreseeable future.

Transitions can sometimes be painful.  The fact that Apple pulled off a major transition with very few problems is a testament to their engineering staff.  For companies that feed off of Apple this transition wasn’t always easy and REALbasic had its growing pains.  The transition to Cocoa has been painful but in the long run it will allow REAL Studio to grow with whatever is coming up next for Apple.

What do you think?  Do you still work on a PPC machine to do development?  Do you still serve PPC users?

Interesting little blurb at http://blogs.barrons.com/techtraderdaily/2010/05/26/apple-will-steve-ballmer-show-up-at-the-wwdc-keynote/ about Microsoft presenting at Apple’s World Wide Developer Conference (otherwise known as WWDC) to show off Visual Studio for iPad/iPhone and general Mac OS X development.

Geeze.  How many levels of wrong is this rumor?  You think Apple is going to trust Microsoft with the keys to their iPhone/iPad kingdom?  I don’t think so.  Apple has worked too hard building xCode and Cocoa Touch to let a 3rd party develop for iPhone/iPad.  If this does happen, then Apple might as well give Adobe a call and let them know they can restart their iPhone/iPad programs too.  And we all know where that feud isn’t over yet.

Where this might make sense is desktop applications.  Microsoft, while doing all that work to write Microsoft Office for the Mac in Cocoa, wrote their own Cocoa libraries and other Mac GUI editors and put it into Visual Studio.  Seems like an awful lot of work with minimal gain for Microsoft unless they’ve decided to make a push in REAL Software’s corner.  They certainly have the knowledge and resources to do such a product.

While I don’t think this rumor has legs it does make you think.  No doubt Microsoft is feeling the pinch of developers learning Cocoa which does nothing for Microsoft.  If they developed a cross-platform Visual Studio it stems the bleeding because now developers don’t have an either/or decision to make.  Learning a new development tool and frameworks suck and letting all those Windows developers develop for Mac and Windows using their tool keeps Microsoft in the game.  It doesn’t help them with iPhone/iPad development (now) but in five years who knows.  If it does happen it will generate some serious buzz which is something Microsoft wants (needs?).

What does this do, if true, to our favorite development tools company located in Austin?  I don’t think it would be good news.

Normally I run REALbasic on Mac OS X and remote debug in Windows.  This works 99.9% of the time but late last week I ran into a situation where I wanted the IDE on the Windows side as well.  So I installed RB and downloaded the plugins that I needed.  Then I started to use RB.

Using RB for Windows was…different.  I’m not sure that I can quantify it other than that it seemed less polished.  It just doesn’t feel like a normal Windows app and it certainly was not as smooth as the Mac OS X version.

The reason I was in Windows to begin with was of tracking down a printing bug that was affecting my product.  Turned out it was the Application.UseGDIPlus property that had been set to true.  The end result was that my reports were ‘blown up’ about 10 times bigger than they should have been.  This has been documented and is <feedback://showreport?report_id=10399>.  Turning off the property fixed the problem.  Some fix, eh?

I don’t think that Windows gets as much attention as the Mac OS X.  Why do I believe this?  The ARBP surveys consistently show Mac users being about 80% of the membership.  Likewise, traffic to this website is roughly 80% Macintosh.  What this means is that beta testers are predominantly Mac based.  I believe that most of the developers at RS are Mac users as well.

Currently, RS is in the transition to get Cocoa out.  It won’t be happening for 2010 R1…so it’s obviously a much tougher nut to crack than they originally thought.  Honestly, I’m not surprised.  Going from Carbon to Cocoa is like creating an entire new platform.  Eighteen months to two years isn’t out of the question for such a big undertaking.

I’m hoping that when Cocoa is out and working great (you think it won’t have some bugs in the first release?) that RS pays a lot of attention to Windows.  They’ve said in the past (sorry no reference for this) that a vast majority of new licenses are Windows users.  But yet, based on observation, the professionals and beta testers are mainly Mac users.  Does that not say something?  Would better Windows support translate into more Professional and Studio licenses?  I don’t know, but I suspect so.

Perhaps it’s time to kill support for Windows 2000.  I’d even suggest killing off XP but I know a lot of places in the world are still actively using it so that’s probably a non-starter.  I believe Cocoa support will effectively kill support for anything less than Mac OS X 10.4 so why not for Windows too?

I suggest that everyone that has a Studio license do a bulk of their work in Windows for a couple of weeks.  More Windows-specific bug reports will (hopefully) get some of the more obvious (and painful) bugs fixed.

What are your feelings about this?  Am I right, wrong, or somewhere in-between?

I’m not entirely sure what Apple changed in Snow Leopard but  we quickly discovered that disk images created in Snow Leopard don’t work the same in Leopard and earlier systems.  When we create our disk images we have something that looks like this:

Looks fine in Snow Leopard.  Acts fine in Snow Leopard.  But when you take it into Leopard you get a disk image that looks something like this (no background image):

Long time Mac users understand what to do but new Mac users were a little mystified at what to do.  Unfortunately we didn’t find this out until after a couple of releases, but we did find a solution.

We use a postbuild script to automatically create our disk image.  The bit of code is:

hdiutil convert -quiet  -format UDBZ -o “${IMAGE_NAME}.dmg” -imagekey zlib-level=9 “./${IMAGE_NAME}.sparseimage” \
|| error_exit “$LINENO: Could not compress the DMG”

This leaves a sparseimage file laying around and normally we get rid of it.  While running this in Leopard we didn’t and copied it.  This sparseimage has the proper graphics and works in Snow Leopard so we now use it as our template when doing builds in Snow Leopard.

We changed the script to delete the OLD file on the sparseimage using:

rm -rf “/Volumes/${MOUNTED_DISK_NAME}/Task Timer 4.app/Contents” \
|| error_exit “$LINENO: Could not delete old build”

Then we copy our newly created RB app into the sparse image.

rsync -a “${MAC_OUTPUT}/Task Timer 4.app/” “/Volumes/${MOUNTED_DISK_NAME}/Task Timer 4.app/” \
|| error_exit “$LINENO: Could not copy into volume”

So, it’s kind of pain to do, and it’s not very efficient but it works.  We are still using RB 2009 R3 because build automation that was released in R4 doesn’t work for us.

Update:  If you want to see the entire script, there is an article in the Articles section on the ARBP members only site, which is available to any paid membership.