BKeeney Briefs

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?

The Association of REALbasic Professionals did a survey late last year about the REAL Software beta program.  You can see their writeup here.

There was nothing earth-shattering in the results.   With a self-selecting group (via the survey name) they found that roughly half of all the respondents participated in the beta program in some form or fashion.    Of those that didn’t participate, most ARBP members didn’t even know it existed.  I’m shocked that people didn’t know about it.  I guess that just shows how long I’ve been part of the RB collective. 

Unsurprisingly, the Non-ARBP folks that were not part of the group, when asked why they weren’t part of the beta program, responded most often with some form of “I’m a newbie.”  It would be nice to get more of these folks into the beta program but given their timidity with RB to begin with I’m not sure they’re confident enough to know what a bug is and what it isn’t.

Just for the record, the way to sign up for the beta program is simple.  Log into your account on the REALbasic website and select “Beta Program” from the menu options.  You have to have a current, valid license for any version of REALbasic.  That’s it!  You then start receiving the beta list emails and get access to any current alpha, beta, or final candidate downloads.

A lot of the survey respondents said they participated in the beta program to test their product before it was released as well as making REALbasic better.  This makes sense as most of the participants are using REALbasic professionally and don’t want to be surprised with a new version and know (mostly) what the current bugs are.

The survey asked a question about having some form of compensation for beta testers.  Among the ARBP members it was 50% yes and 49% no.  Non-ARBP members said no 66% of the time.

I’m the one that suggested this question because I’ve probably logged around 50 RB bugs in the past couple of months.  Some of this because of my high level of interest in the new reporting system and some of it from producing many hours of REALbasic training videos.  I sometimes feel like I’m being asked to do my own job and then RS’ and the only reward I get is a better product (not that that’s a bad thing).  From the mixed results, the professionals have similar issues.

Finally we asked the question, “Do you feel the beta program is improving REALbasic?”  Both groups were overwhelmingly Yes with 70% of ARBP members with 90% of the non-ARBP members.  I think the interesting part lies in the 30% that didn’t say yes in the ARBP group.  What are they unhappy about?

From my own experience in the beta program, too many things are being changed when the product goes to Final Candidate status.  Final Candidate should mean that they think there are no more changes to be made and therefore this build is going to be THE release unless a show-stopper bug is found.  Unfortunately, we saw the results of last minute changes with RB 2009 R5 when a change late in the cycle caused reporting and the database to be broken.  The result was RB 2009 5.1.

So what are your thoughts about the beta program?  Do you like it?  Is it flawed, or is it just the nature of a product that’s always changing?

Making a screencast video presentation is more difficult that you image.  First you figure out the script, then you do the recording (perhaps more than once), then do any editing (cut the coughs and um’s, speed up long typing sequences, etc), add any callouts or special effects, then convert to the appropriate video format, upload the video and finally create an accompanying article to go along with it.

Whew!  That’s a lot of work.  I’ve done this for over nine hours worth of material so far!

We, BKeeney Software, are now offering streaming videos for REALbasic training with over an hours worth of free video (you do have to sign up for an account though).  To say that this has been a labor of love is understating the scope of the project.  With nine hours of video we’ve barely scratched the surface of all that REALbasic has to offer.  We have many, many things still left on the plate. I look at this as a never ending stream of videos as REALbasic is always evolving (on a 90 day basis!) so the work will never be done.

With nine hours available now, what’s it mean for a month or year from now?  I don’t honestly know, but as I’m writing this I’m encoding and updating another twenty-six minutes of video.

Since this is REALbasic I spend a lot of time working in one environment, Mac OS X, and doing debug runs in Windows 7 and Linux (Ubunutu) and show you the big, little and sometimes subtle differences between the platforms.  You’re seeing how I approach a project from the ‘what I’m going to do’ to implementing it and doing final testing.  And yes, you get to see me make some mistakes (hey, don’t we all?) and through the magic of post editing I’ll point those out when I do them so you’re not confused and then we show the correction process.

This is not a typical video training program.  We have five hours of video just on the basic controls available for REALbasic.  Not only do we describe what it does and some of the things to be aware of, we use the control in a project and examine what it does in Mac OS X, Windows, and Linux when there are differences.

My goal is to make you a better REALbasic programmer.  I name EVERYTHING from RB objects to my variables in source code so that they mean something.  At a glance you should be able to tell what your source code is doing because you’re not just writing code for right now, but you’re writing code for six months and six years from now.

Sign up for an account and automatically get a free Guest Pass.  Poke around and take a look at the free videos.  We’d love it if you’d sign up for a subscription.  With our introductory pricing, a three month subscription costs $45.  A year subscription is $150 which is a 20% savings.

What’s great about the video training?  You can help direct what videos are done next.  REALbasic has thousands of classes – some with poor documentation and examples.  We can create the video training that helps you out sooner rather than later.

That’s it for now.  Happy coding!

Happy New Year everyone!  This time of year is an awesome time to review the previous year and make plans for the upcoming one.

Many of us charge clients by the hour regardless if we tell them that or not.  In a fixed bid project we estimate how long it will take to do the various parts of the project and then give the client a value based on those hourly estimates.

Reliable and accurate estimates are just the first step in making your business profitable.  The final step is going back and seeing if you estimated properly.  The only way to do this is to track your time on a project by project basis.

There are variety of tools available for doing this, but Task Timer, one of our products, is a very simple and inexpensive ($24.95) way of doing this.  Task Timer is designed to be simple and easy to use.  It’s as simple as pressing a button!

Setting up Task Timer isn’t much harder.  Add your project, add the major tasks you want to track, and add your initial estimates and start using it.  The new built-in estimate graphing gives you a minute by minute graphical view into how you’re estimate is tracking in comparison to your actual time spent.

For many of our consulting clients we give them a discount rate when they pre-purchase a block of hours (usually 40 hours).  Task Timer’s new estimates feature makes tracking the hours used really easy.  When the client purchases a new block of hours simply create a new task for the project and put the block of hours into the estimate field.  Task Timer is now tracking your bulk hours used for the client!

Many people who have purchased Task Timer have told us that it pays for itself in the first week!  We can’t verify their claims but we can say that when we created Task Timer and started implementing it for all of our projects we found that our billable hours rose over 15%.  It seems we were not very accurate reporting how much we worked on any particular project at the end of the day.  If we reported (really guestimated) our hours at the end of the week the numbers were even worse!

For additional information about Task Timer, please see this link:  http://www.bkeeney.com/products/tasktimer4

Download links:

Mac OS X:  http://www.bkeeney.com/downloads/macintoshdownloads/download/36-tasktimer

Windows:  http://www.bkeeney.com/downloads/download/38-tasktimer

Tracking your time is a good reality check.  Were those products you were spending so much time on really worth it?  How much time are your blogging?  What about video production for those training videos?  For that big size month project what did you get right (and more importantly wrong) in your estimates?

Plan on getting a handle on your estimating skills in 2010.  Task Timer is just one of the tools you can use.