BKeeney Briefs

The July/August 2010 edition of REALbasic Developer Magazine is out.  This months column title is “Having a Thick Skin: Take the Emotion out of Your Tech Support”.

I talk about the pitfalls of providing tech support when people asking for (or is it demanding!) for tech support aren’t nice.  Email and forums posts are awful mediums for communicating to each other so you have to take the emotion out of the equation.

Do you have any horror stories, tips, or jokes about tech support you’d like to share?

Be aware that RB 2010 R2.1 has a nasty Windows-only bug that might affect you.  It seems that the keyboard accessibility for pushbuttons (and possibly other controls) no longer works properly.

To duplicate, put two pushbuttons on a window.  Put a message box in the Action event saying which one has been pushed.

Test it with the mouse.  Works fine.  Now tab to each pushbutton and press the spacebar.  Works fine.

Now, tab to each one and press the Return or Enter key.  Nothing.  If you happen to have a default pushbutton the Enter/Return key will activate that button regardless of where the focus is.

Nasty bug that leads the average Windows user to curse your name in vain if they rely on the keyboard to navigate.  I spent hours trying to figure this one out because it manifests itself in the MessageDialog class too.

Yeah, I’m a little pissed.   I have to revert to RB 2010 R1 where it does not manifest itself.  The hard deadline for the project I’m working on is today.  Gives me a black eye for a problem outside of my control.

For those that care, Feedback ID 12626

I’m a big fan of the Einhugur control suite for REALbasic.  In particular, the Einhugur TreeView, Calendar, Date, and Time controls often find their way into my projects, both internally and for consulting projects.  The StyleGrid also gets some consideration for many projects as well.

A recent post on the Monkeybread Software blog mentions a number of bugs about the ComboBox control.  I agree with Christian’s assessment of the state of the ComboBox control.  I made a comment (currently awaiting moderation) that I thought that a 3rd party could sell a full-featured combobox control.

I’ve mentioned in the past that I would help finance someone to come up with a cross-platform WebKit plugin and, as of yet, no one has made one or approached me taking me up on the offer.  REAL Software has indicated that they’re looking at it.  Given their workload I’m not sure I expect it anytime soon.

I’m also a big fan of the True North Software Formatted Text Control.  I’ve used it in quite a few projects and find it to be a very nice replacement for the the TextArea control.  For now, it’s the best way to get true RTF support in your REALbasic application.  It’s also very extensible so if you need it to do something special you can modify the source to do it (though it might be a lot of work).

Other things I’d like to see:

• A multi-column popupmenu/combobox
• A grid control that supported container controls hosted in individual cells
• A list view that could switch between column (Mac OS X), TreeView, List, and Icon View.

What is on your wish list of controls for REALbasic that are currently not available?  Why isn’t there a bigger market for 3rd party controls?

As you start to code all day, every day, you start to develop your own set of guidelines.  I’d call them rules, but since I break them often enough I have to call them guidelines.  Since I deal with my own code and Other Peoples Code (OPC) on a regular basis here are my guidelines (in no particular order):

• Name any control you reference in code.  It needs to make sense to you.  If you have a bunch of Pushbutton1, Pushbutton2, etc. pushbuttons you are causing yourself grief in the long run.  You’re coding not only for right now, but for 5 years from now when you’re not intimately familiar with your UI and you want to make a change or fix a bug (or hand it off to a consultant).
• If you find yourself copy/pasting code over and over again you should think about a global method or perhaps a subclass.  I’m talking about the MessageDialog alerts, the ComboBox helper code, etc.  The reason this is a problem is that if you have the same code all over the place and you have to change it, you then have to change it everywhere.  The chances of missing one hase big bug implications and your clients/customers may not appreciate the bug.  This is called, by the way, refactoring and it’s not a bad thing to do.
• Big, huge, monolithic methods/functions are not good.  My general rule is that if my method is over a screen length I start looking at ways to break it up into smaller chunks.  This makes it easier to debug too since the runtime exception doesn’t have line numbers on where a bug occurred.  All it can give you is what the error is and where it occurred (and even sometimes that’s not reliable).
• Name your variables something that make sense to you.  You need to come up with your own guidelines, but the reason is the same as naming your controls.  You should, at a glance have some level of understanding of what the variable is for.  I don’t name loop variables (i, j, k, x, y, etc) unless I have nested loops.  Some would argue that prefixing your variables is a dumb idea because RB is very strongly typecast and if you change the type you then have to change the prefix.  Um…sure…that’s what global search and replace is for.  But I can tell at a glance what type the variable is.
• Name your methods/functions something that make sense.  Same reasons as above.  If you can’t figure it out at a glance what it does, then you might need to rename it.
• One that keeps haunting me (in other words I haven’t always learned the lesson on this) is to use a thread whenever there’s a tight code loop.  It always seems that during testing I have far less data than I will in real life so that tight loop that only takes a blink during development takes seconds in production and causes the app to ‘freeze’.  Threads are a natural way to solve that problem.  I urge you to not use refresh statements in your loops – instead use a thread.  Of course threads aren’t perfect in that you then have to worry about how you update UI but if you have the Thread in the window you’re generally pretty safe.
• Test your cross-platform apps on each platform.  Don’t assume that your Mac OS X application created in RB will look good on Windows and vice versa.  Trust me on this one.  Depending upon what you’re doing, Windows can be hugely different performance-wise than the Mac and Linux.  Double-buffering is standard on Mac OS X and Linux but NOT on Windows so that really great looking custom control on Mac/Linux looks just awful on Windows because of flickering.
• Project organization is important.  As your project gets bigger and more complicated having the big monolithic list of objects becomes harder to find things.  I generally start with Application, BKS, Others, and Assets folders in my projects and put everything in those folders.  The assets folder is icons and any other graphics for the projects.  The application folder has all app object, all the windows and application specific objects.  The BKS folder contains my own toolset of classes, subclasses, extensions, etc that I’ve written and use in most projects (I generally try to retain rights to any code in this folder).  In the others folder is my toolset of objects that are from others and I don’t claim that I wrote.  Some of these are encrypted and others are not.  Keeping your project tidy is a good thing.
• Code first for functionality and once it’s working you can test for efficiency.  I’ve found that some things I thought would be slow weren’t and some things I thought would be ok weren’t.  Get it working first and THEN worry about it.

Those are mine off the top of my head.  What guidelines would you share with someone new to coding and/or REALbasic?

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.

Earlier in the week I mentioned that I thought the REAL Software beta process is broken.  I’m a passionate user and I use RB all day, every day, so I have some strong opinions.  I happen to know a thing or two about testing on a commercial software product.

Earlier in my software development career I was the lead tester for a printer utility (for a very large printer company).  I was in charge of the test scripts (imagine the same test on 30 printer models for each beta release – yeah it was mind-numbingly dull) that each tester used to report bugs.  We’d find a bug in Test 3.13b (how to reproduce), explain what the error is and sent it to the developer in charge (via the bug tracking system).

The developer would fix it and then the build developer would put together the list of changes for that build and the system would then send the bug back to the original tester for verification.  If it passed our test (with the next build) we told the system that the fix was verified.  If not, it got sent back to the developer.

Then, when the developer made a public release, the fixed and verified bugs were put into the change list.  Depending upon how late in the process we were, verified bugs were listed as known bugs so the public testers didn’t report the same bug a billion times.

It’s a tedious process but it’s the only way to really do a beta program.  If you assume that you really want a quality (good enough?) product you need to slow it down and be tedious about it.

So why do I think that the RS beta program is broken?  First, in this release, several bugs were listed as fixed and were clearly not.  This, to me, says that there is no verification process on fixed bugs, or if there is, it’s not a very stringent one.  I understand how this happens because on small teams everyone is maxed out.

It could also be that the bug, as described, was fixed but it didn’t fix the overall problem.  I could easily see this happening.  The developer has a long list of things to do, looks at the bug report, fixes it, verifies it to his or her satisfaction and marks it as fixed.  This, all without a deeper look at why the bug is occurring.  I understand because it’s happened to me.

I would also posit that that the beta program, as it exists, doesn’t work the way that benefits REALbasic (and us end users) the most.  Bugs are getting introduced into the product.  Bugs aren’t getting fixed.  New features don’t get tested properly and take several releases to get working properly.

The beta program asks members to test each build against their projects.  Here’s the ugly truth:  When you ask me to test ‘everything’, it’s like asking me to test ‘nothing’.  There are a couple of dozen of controls that can be used in millions of different ways.  There are hundreds of REALbasic classes that can be used in an infinite number of ways.  Telling me to test my project against the new version only catches in-your-face, or easily noticeable, bugs.

Yes, there is a change list for each beta version but they never tell the beta list what the changes are per new beta build.  Several developers take the time to parse through this list and then publish what’s changed, but why are the testers doing this and not RS?  They should know what has changed in each release and publish the list based on beta build not just an overall list.

ARBP did a survey late last year asking about the beta program.  Most developers said they did it for early access to the next release.  This is akin to saying, “We are part of the program to make sure it doesn’t muck with my project.”  Sure, they test, but is it what RS really needs?

My recommendations.  Not in any particular order and some are mutually exclusive:

1)  Since the beta program isn’t producing the feedback RS needs/wants early enough, scale back on bug fixes and new features and do more internal testing for each release.

2)  Provide guidance on each beta build as to what to focus testing on.  If the listbox received a lot of work, then say that.  As a beta tester I should focus on the listbox.  With Cocoa receiving a ton of changes for each build, it would be helpful to know what the developer wants tested.

3)  Scrap the program entirely and rebuild it by invitation only.  This ensures quality testers and a good mix of hardware, operating systems, projects types, time commitment, etc.  Perhaps even do groupings of people to focus on different aspects of the product in each build.  Group A does controls in this release while Group B focuses on a framework or whatever and in the next release you reverse it.  It ensures that there are always different people looking at different things.  The key here is having as many eyes looking at as many things as possible.  This gets rid of the tire kickers too that provide no valuable feedback.

4)  Have a single person in charge of the beta and build process.  Give that person the authority to delay a public release if beta feedback is too negative or bugs are found at the last minute.  Don’t push the product out the door “just because”.  If there is a legal commitment (for whatever reason) to release on a certain date, then there must be proper time for the testers to vet out problems.

5)  Enforce a proper feedback loop.  Proper discussion needs to take place, both internally and externally, before major things get worked on.  We, users, have a certain set of expectations about features and when no one gets our expectations on record then we end up being overly disappointed in a feature we can’t/won’t use.  We, the users, are the biggest marketing arm of REAL Software.  Keeping us happy makes for happy reviews and comments in public forums.

6)  Don’t ignore beta feedback by saying we’re not the typical RB user.  Um…yeah, we are.  We care enough about the product to give you our time – for free.  Yes, we’re in it for our own interests but don’t dismiss our thoughts as not being representative.

Thoughts?  What would you change to the beta program, if anything?

We all have our pet bugs and the proper mechanism to express our desire for any particular item is to edit the priorities in the Feedback application and put it in your top five.  A few people can make a significant impact by adding a Feedback item in their top five.  I’m here to today to lobby for a particular bug.

<feedback://showreport?report_id=3218> Save as Version Control format kills external encrypted items with subclassing:  Because this one struck me this morning in a very, very bad way, I put this as my #1 priority.  If you use version control and if you have encrypted items (I use RSReport from Roth Soft) you sometimes get an encrypted file that becomes blank upon saving.  So when the IDE tries to open the project a second time it throws an error because the file was blank.  The trick is to keep a copy of the original file somewhere and replace it, or retrieve the good version from SVN.  Normally it’s a 30 second procedure but today it was an hour diversion.

Needless to say, it’s one of my hot buttons.  Since this one affects me every single friggin’ project I hope you would make it one of your priorities too.

Since we’re talking about Feedback items.  What’s your hot button item that causes you no end of grief?  I’m willing to use one or two of my priority items to put your Feedback item towards the top of the list.  So what is it?

A good friend of mine asked a relevant question last night over a birthday brewski last night.  “Why can’t I run my iPhone applications on my Mac?”  After a moments pause, I replied, only because Apple says so.

So before you write tell me I’m an idiot (which I might be anyway), I know there are some really valid reasons for not running portable apps on the desktop.  There is no motion sensor on the Mac so any application that needs the motion sensor is out.  Likewise anything that uses GPS or the compass is out.

One even could argue that many of the apps that pinch to zoom in and out would be out as well.  But let’s think about it for a minute.  How many of your iPhone apps really use all that?  On my iPhone the one app that uses this the most is Safari.  No need to use that on the desktop.  Same with Mail and a number of others.

Obviously Apple has figured it out because their emulator runs onto desktop.  I think Apple *could* run the iPhone apps on the desktop but they choose not to.

It makes me wonder if widgets wasn’t an early attempt at making an iPhone app.  Many of the things we’ve seen incorporated into Mac OS X have really been for the iPod/iPhone/iPad.  Coverflow looks nice on the Mac but I don’t see a lot of people using it – but on the iPod it sort of makes sense.  Widgets, while useful, have never made a lot of sense to me, but making a lightweight application for the iPod makes a LOT of sense.  Another example is the beautiful pop over control on the iPad.  It reminds me a lot (but not exactly) like the HUD windows on Mac OS X.

Those are just a few examples.  I’m sure we could come up with some other examples of Mac OS X-first technology that, while cool, was a gimmick on Mac OS X but makes a lot of sense for their portable hardware.  I wonder how many developers at Apple have worked on something and said, “This is stupid” only to see their work in a new device years later where it makes perfect sense?  I would love to know.

So Apple chooses not to allow iPhone apps on the desktop.  I’m cool with that.  But think about how nice it would be to have some of the iPhone games (all 50,000 of them) available on the Mac.  Even in a Windowed environment they would still be decent games.  Maybe a simple wrapper to allow the arrow keys to handle motion control would suffice for most of the games.  Maybe not, but it is an interesting thought.

Those 50,000 games would put Mac gaming in the mainstream very quickly.  Of course it might have the effect of killing desktop only game development but perhaps not.  I think there’s plenty of market out there for people like me that will gladly play $1.99 to $9.99 for a quality casual game.

Plants vs. Zombies is my current favorite iPhone/iPad game.  It has a desktop version but I don’t want to pay for it again.  On the iPad the iPhone version looks great at double size and I imagine it would in a double size window on my desktop too (which, if memory serves is roughly half the size of the window for the desktop version).

I think this could be a huge deal for the Mac OS X market.  I doubt Apple will allow that any time soon but I’ve often been wrong before.

My friend needs to give himself more credit.  It was a good question.  What are your thoughts?

(By the way, Happy Birthday, Robert!)

The iPhone 4.0 SDK was announced today by Apple.  It has a ton of new features and most are welcome.  It’s not all good news, however.  Stuck in section 3.1.1 of the new iPhone Developer Program License Agreement is the following:

Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

Wow.  I find this to be simply, and utterly, the most arrogant thing that Apple has done in my many years of being an Apple fan.  I find this to be distasteful in the extreme.  Words can’t describe how angry/disappointed I am in the “Think Different” company.

Now lets talk about the debate we had a while back of REALbasic making apps for the iPhone.  In my debate with Marc Zeedar for March/April 2010 issue of REALbasic Developer Magazine I said this:

An iPhone version depends on the willingness of Apple to let REAL Software play in their court. I have my doubts that Apple would do that simply because all of those 140,000+ iPhone applications they’re touting were developed on a Mac. Letting go of those hardware sales is not in Apple’s best interest economically. Not only that, but letting RS create iPhone apps now makes Apple dependent upon a third-party to issue bug fixes in the framework and be up-to-date whenever a new SDK is released.

I think today’s new license agreement proves my point.  Apple is going to control everything and if you don’t want to learn Objective-C and use XCode and CocoaTouch too bad for you.  Apple controls the entire ecosystem and they are not going to let anyone play in their court.

Much will be said in the upcoming weeks and months about the new license agreement.  The anti-Apple folks will use this to bludgeon the advancement of the iPhone and iPad into the corporate environments.  What will pro-Apple folks do?  Shut-up and start learning xCode and Objective-C because there’s not much to defend.

Will it always be this way?  I don’t know.  But I do know that nothing will change unless Apple starts losing money and by all accounts that’s not going to happen any time soon.

If you have your own business, are a consultant, or even simply sell your own stuff (whatever that stuff is) I recommend the article at http://www.thelaunchcoach.com/insecurity-doesnt-pay-the-bills.

I can’t even begin to tell you how much this post struck a chord with me.  I feel like this all the time with my blog posts, my REALbasic training videos, my software products and even my consulting.

I have to push myself past the insecurities every day.  I am my own worst enemy because whatever you think about me, my internal monkey chatter tells me the same and much worse – trust me on that one.

Thankfully, my fear of regret is bigger than my fear of failure.  And yes, I’m just as messed up as you – probably more.  ;)