BKeeney Briefs

Real Studio Developer Issue 10.3 March/April 2012 is out.  In this issue I have my regular column where I talk about how to attract clients to you rather than you hunting them down.

There’s an interview with Paul Lefebvre.

There’s an article from Anthony Mousel titled “Adventures In the Dark – Hard Lessons in Consulting”.  I highly recommend reading it if you want to do any consulting.  Good lessons to learn.  Even I still make some of these mistakes!

If you’ve been around Real Studio/REALbasic for a while you’ve probably grown accustomed to the 90 day release cycle from Real Software.  Whether you love it or hate it is really besides the point because for the past 6 six years it’s all we’ve known.

If you haven’t noticed, 2012 Release 1 hasn’t been released yet.  Real Studio 2011 Release 4 was put out on December 6, 2011.  201o Release 4.1 was released the first week of February and 4.2 was released last week and it looks like a 4.3 release is imminent.

We already know that Real Studio 2012 Release 1 will have a couple of major changes.  The first is that it will be the first release where Cocoa support is ‘official’ and no longer beta.  Many Real Studio developers have been banging away on Cocoa and while it’s not perfect many are using it.

Another big change is a redesigned user interface for the IDE.  I’ve been able to see some previews of it.  The first was at the ARBP conference in Atlanta last March and in early November at the Real Studio Database Days training sponsored by MonkeyBread Software.  It will be an interesting change for sure since we use the IDE all day long and we’re intimately familiar with it.

If you were around during the last UI change (circa 2006) you may have some trepidation about this change because that one didn’t go well, in my opinion.  Thankfully some things have changed since then.  First, Real Studio is now written using Real Studio so the company is painfully away of the problems with the transition to Cocoa and the new UI.  Back then, nothing in Real Studio (that I’m aware of) was written using Real Studio so the developers weren’t always aware of the more painful bugs the new UI caused.

I’m still hesitant about the new UI because Real Software doesn’t use the IDE like we do.  They are starting with an existing code base with portions of the code base that don’t get examined very often.  We (and I’m speaking as a consultant here) create new projects from scratch every week with about a dozen really big projects (start to finish) every year.  If you’ve ever looked at a few of the editors (*cough* reporting *cough* database *cough*) you know what I’m talking about because it’s obvious they don’t *use* them in IDE.  They have such huge holes and bugs in them they’re practically unusable for most of us.  It’s that level of detail I’m afraid of.

Frankly, there’s no guarantee that the UI changes will make our lives easier.  Software development is a crapshoot, at times, and while I *know* they’re copying good ideas from other products and tweaking them to fit the RB environment that doesn’t mean they’ll pull it off.  If they release something that makes our lives harder – then well I can’t wait to hear the moaning, complaining, and screaming.  :)

Anyway, back to my point.  If you were expecting a new release in March it ain’t gonna happen.  With a dot release imminent I would suspect at least 90 days from that dot release.  Maybe a little sooner or later but that puts my estimated arrival time around June.  We won’t know for sure until it goes to the beta list for testing and that hasn’t happened yet.

So for those of us that were wishing for fewer releases I guess we got our wish.  Hopefully this means it’s done when it’s done and not based on an arbitrary schedule.  Of course, the drawback is that some bugs that are killing us won’t get fixed for a while and waiting until June is fugly.  Then who knows what sort of issues we’ll find in the new UI that keeps us from using it.

When you’re at Real World at the end of May I guess we can meet at the bar and either celebrate or commiserate!  See you there!

I’ve had the privilege to be a First Lego League (FLL) coach for the past two years.  It’s a very rewarding experience as I am amazed at the hard work and awesome ideas that these kids put into the research and their presentations.

The FLL competition each year revolves around a main theme.  This year it was called Food Factor and was all about keeping food safe.  The competition has three areas of emphasis, the Research (identifying and providing solutions to problems), Core Values (team participation, enthusiasm, gratious professionalism), and the robot (design and programming).  This is a very brief overview but you get the point.

FLL is for kids 9 to 14 years old and this year my team consisted of 10 kids (double the team size from last year) with two sixth graders, two fifth graders, a fourth grader, and five 3rd graders with seven of the ten being brand new to the program.  The ‘hook’ for most of the kids is the Lego Mindstorms robot and at the table competition challenges are made from Lego’s.  It’s brilliant because what kid doesn’t like playing with Lego’s?

In reality, though, there’s after building the field components there’s not a lot of Lego building.  There’s *some* with the robot but once you build it you really don’t want to mess with it much.  The robot is really about learning how to program and that’s where my big beef comes in.

After having used the Lego Mindstorms graphical programming environment for a couple of years for my First Lego League team I decided that it teaches them little to nothing about programming.  The graphical programming environment seems easy but in reality the kids find it frustrating and once you get past simple programs it quickly gets confusing.  There are ways around these limitations but I feel it in no way teaches the kids about good programming principles.

The IDE uses ‘blocks’ to describe what’s going on.  But, because the display doesn’t show the properties you are constantly having to click on blocks to see what is going on with that block.  So the graphical environment is NOT self documenting.

The left to right programming environment isn’t like most other languages.  I don’t know if this is a spurious argument or not but I find the left-to-right paradigm unsettling.  I spent years doing PLC programming in my electrical engineering days and I found it easy to describe how logic ‘fell through’ to the next level.  This language was used by a lot of plant electricians and a lot were not the ‘programmer type’ if you get my meaning.  All programming languages I’ve used professionally are text based vertical (top to bottom).  I feel the kids are not learning much that’s helpful when they get to a ‘real’ language.

You can add comments to the code which is kind of nice.  But, they are location specific meaning that if I added a comment near the 3rd block from the left and then added two new blocks before the 3rd one the comment is now out of place.  What I’ve found is that the kids won’t use comments.  No one likes documenting their code but because the IDE works against them they learn not to use it.

Variables are almost an afterthought in this development environment.  They are hard enough to use that it’s considered an ‘advanced’ technique?  Really!?  What programming language doesn’t make variables easy?  Another major failing in my opinion.

Now I don’t know what, exactly, I’d do differently, but I’m looking into it.  I’m looking at creating a set of Mindstorms NXT classes using Real Studio.  This might involve creating a base set of classes to allow Real Studio developers to control the robot just like the Mindstorms software.

Besides using standard REALbasic classes (and dot notation) I’d love to create a simplified interface that would be easy for beginners to accomplish some complex things.  I’ve batted the idea around of something like Mac OS X Automator.  It’s pretty linear, self documenting and graphical.  I don’t know how I’d handle loops but it has to be better than what the Mindstorms software is doing.

So I’ve done a little research and it looks like Real Studio can at least *see* the NXT using the MonkeyBread Software USB classes. Does anyone have any experience/insight in this area? I can start from scratch but I’d love to talk to someone that’s a Subject Matter Expert (SME) if I could.

For what it’s worth, there is a very old project that connected to the older RCX but not the newer NXT. Unfortunately, it was written using encrypted modules so it’s not possible to review and update the code for the NXT.

So if you have any experience in this area, please contact me and we’ll collaborate if possible.

Yesterday Apple announced Mountain Lion and released a Developer Preview. It was announced to world through the press which is very un-Applelike. Welcome to the new Apple. As a developer I like that – less uncertainty.

One of the major new features in Mountain Lion is called GateKeeper and I won’t attempt to butcher the explanation. I’ll let the fine folks from Panic tell you via their blog post at http://www.panic.com/blog/2012/02/about-gatekeeper/. Come back when you’ve read it.

I think this is a very good thing from a developer standpoint. GateKeeper seems to be a much wanted middle ground that we’ve been waiting for. It seems to give the best of both worlds for both casual and power users (and most that are in the middle).  Security shouldn’t be so painful that mere mortals (and the average developer) should be punished.

Mountain Lion also integrates iCloud into the OS in a big way. A troubling thing, though, is that to use iCloud services you must be in the App Store (either iOS or Mac). That limits my options as a developer. If I want to make iCloud part of my application then I am forced to sell it through an Apple store.

I know plenty of Mac developers that have no desire or intention of putting their apps into the Mac App Store because they don’t want to pay Apple 30% off the top. Some also dislike Apple’s ‘walled garden’ approach. It feels as if Apple is punishing us by cutting off access to iCloud.

Most of the readers of this blog use Real Studio and many are concerned with non-Mac platforms in addition to Mac OS X. I don’t know the answer to these questions: Can we currently include iCloud services in our Windows builds? And will this change for the Mountain Lion release?

Does the move to GateKeeper change the March 1st deadline for SandBoxed Applications sold through the Mac App Store? It seems that this hasn’t been answered yet and I’m not the only one that feels this way. See http://www.pcadvisor.co.uk/news/software/3338240/developers-unsurprised-but-cautious-about-gatekeeper/ for more details.

While it’s still too early to have an opinion about Mountain Lion, GateKeeper and iCloud integration are both exciting and mysterious at the same time. I’m hoping the new Apple does a better job of telling developers what our options are.

 

After the current ARBP president, Paul Lefebvre, accepted a position at Real Software the Association of REALbasic Professionals (ARBP) found itself looking for  a new president.  Read about the news and changes at http://arbpmembers.org/arbp-blogs-and-opinions/article/3-ARBP%20Blogs/267-new-year-new-changes

I welcome Scott Boss as the new ARBP president.  If you are interested in helping out ARBP I think we could use your help.

Yesterday I was complaining about my OPC project and I’ve added a few more bullet points in the comments section.  This morning I added a comment about how the idiot developer used Recordset.idxField(index) rather than Recordset.Field(“FieldName”).  I hate it when developers use idxField because it makes it tough to read and I constantly have to go back and look at the query and count fields.  In the short term I modify the query string in the IDE and put index comments in the in string.  Something like this:

s = “Select field1, ” _ //1

+ “field2, ” _ //2

and so on but it’s still a pain.

Anyway, Christian S. posted a comment that got me thinking.  He said:

idxField is good. It can speedup applications a lot.

Is that really true?  I have never tested it so I created a little test application using an actual query from the project I’m working on.  I run the same query twice.  The first time I loop through the recordset using nothing but idxField and the second time I use nothing but field which uses the field name.  The results are interesting and confirmed my suspicions.

If I run my two functions just once and bring back only 1 record and do one read in the function the idx field is indeed faster by about 50%.  However my testing differences range from 6 to 300 microseconds faster and while I didn’t average out all the results, I’d say most times it was around 60 microseconds faster.  I ran this test a lot to see if I would see a wider variation but did not.  My 300 microseconds difference happened just once out of about 25 runs.

I changed my query so that instead of bringing back 1 record it brings back over 700 and I loop through the recordset and then do the same same test.  IdxField comes back about 15% faster.  When I loop through the same row 10,000 times there is no statistical difference which means that while Field is slower it’s a one time hit since my tests show that even doing the same pull 10,000 times the total difference between the two functions is still only about a 10-15% difference in overall speed.

My conclusion is that yes, idxField IS faster than using Field but to say it speeds up an application “a lot” is an exaggeration.  In 10 years of Real Studio consulting work I have rarely done an application that requires that much speed from the queries.  If you have any sort of graphical user interface I think it safe to say that updates to the controls on screen are significantly slower than pulling data out of the recordset.  That’s NOT to say that the query itself is fast because often times that is the most limiting factor.

I won’t discourage you from using idxField.  If you do, though, I really encourage you to use constants named after your fields.  So perhaps you create a constant named kField1 and the value is 1 for the first field in your recordset.  The only drawback to this approach is that you (or the developer after you) will change the SQL query and all the code using idxfield no longer works because your field order is different.

I much prefer the explicitness of using Field because I never have to worry if I change my field order.  It’s very readable.  It’s not perfect and there are plenty of reasons why it’s not the best (there’s a reason why we use ActiveRecord in a lot of projects).  Use what’s best for you and what’s best for the five years from now.

What say you, RB developers?

Dear Idiotic Developer:

OPC is our internal slang for Other Peoples Code.  I’ve talked about this before but just in case you’ve never been here before, OPC projects are always the most dangerous kind of projects to work on.  They can quickly become a rats nest and cause no end of grief mainly because you have to figure out what the original programmer (or programmers) was thinking.  Because it’s a Friday afternoon and I’ve been up to my elbows in digging through your OPC project all week here is my list of complaints:

• Poor variable names:  Variables such at ‘tmpd’ and ”bDbDl” don’t tell me anything.  Long variable names aren’t going to kill you and using Real Studio’s autocomplete will (usually) make this a non-issue.
• Three Letter Acronym (TLA) Variable names:  Stop being lazy and use some real words.  Obviously you didn’t expect someone else to read your code in five years.  If I ever find you I promise I will mock you.  I hope you are doing a better job of naming variables in your new job than your last one!
• Poor method names:  Methods named “SelAcc” and “DoWork” don’t give me any type of clue on what it does – especially when you have no comments in your code.
• Nested If-Then Blocks from Death:  There are times you need to do this but it’s been my experience if you’ve got more than 2 or 3 at any given time your method is too long and should be broken up into smaller methods.  Keep it simple.  Complexity kills.
• Multiple nested loops from death:  See nested if-then blocks from death above.
• Long methods:  This kinds of goes with the previous two.  If your methods scroll and scroll and scroll you have a problem.  If you had a problem in that method (i.e. it throws an exception) good luck finding the problem.  Break it up into smaller chunks of code.  Perhaps you can take the 100 lines of code you have the first part of your IF statement and break that out?  Just sayin’.
• Controls using the default names:  Really, you expect me to figure out the difference between TextField1 and TextField11 by making me look at the UI?  Next time, please use a name that will mean something to you in code.
• Controls using generic names:  On the flip side you used a name different than the default one.  Good for you.  Perhaps next time you can use something other than ‘s’ for its name because it took me a while to figure out it was damn text field rather than just a plain string.
• Constant names versus property names:  Quite ingenious the way you used the same constant name as a property name so that the IDE doesn’t help me in autocomplete.  Thanks.  That’s ones special.
• Stop trying to be fancy:  I get it.  You went to whiz bang college and learned some cool programming tricks and techniques and you’re pretty smart.  Remember, you’re writing for your boss/client/person who signs your paycheck so don’t forget that you’ll eventually move on/get fired/hit by a bus.  Be nice to the poor bastard that has to learn your code after you.  Assume they do not have your skill set.
• No comments/documentation.  Of course given all the previous bullet points this one isn’t surprising.  Would it have killed you to put a sentence – ONE SINGLE &*^!@% SENTENCE – describing what a method does?  If you hadn’t done all of the above items too that’s all it would have taken but instead you have ZERO comments in 10,000+ lines of code.

But, I must say thanks for reminding me why I don’t like working on OPC projects.  You’ve taught me that just saying “no” in future projects will make my life easier and less complicated.  My wife, kids, and dog will like me better if I don’t take another OPC project.

I think if I had any advice for programmers just starting out.  Spend six months fixing Other Peoples Code (OPC) and see what drives you absolutely bonkers.  Then, and only then, can you start writing your own code.  You’ll hate it but it will give you some very valuable experience early in your career, on the things not to do.  Being kind to the developers that come after you is just as important and by doing this you’ll know.

Ultimately I’m a lazy programmer.  Not that I don’t do the work I just don’t want to work that hard at figuring out old code.  If you name your variables and methods properly and consistently, keep your methods short, and if you write minimal comments it’s not that hard to figure it all out later.  Having to guess at someone else intent makes my head hurt.

Sincerely,

Bob

So dear readers what OPC foibles drive you crazy?

I haven’t been posting much this month for a reason.  This is, in all seriousness, the busiest January we’ve ever had for Real Studio consulting (and we’ve been doing this for over ten years!).  All three of our full-time Real Studio developers are maxed out on projects and not just on single large projects either.  We all have multiple projects awaiting our attention as soon as we have the time.

Being that busy is always a good thing-bad thing proposition.  My backlog of Real Studio training videos just gets bigger by the day.  Oh well, they’ll wait until I’m slow or want to do something completely different for a few days.

I’ll admit that I have been very critical of Web Edition – especially when it first came out.  I felt that it was released too soon with obvious bugs and holes in the frameworks, wasn’t adequate testing, and was without features that were necessary.  A lot of that has changed recently (though WebMoviePlayer still burns a hole in my stomach) and we’ve found that most projects these days have some sort of web component in them.  Web Edition fills that need for us and while it may not be the best, fastest, scalable, or comprehensive web platform to deal with it has increasingly become a part of our standard package.

I mention this because all three of our developers are working on projects where Web Edition is used to some extent in conjunction with the desktop apps.  I think it safe to say that about 1/4 of all our Real Studio work is using Web Edition.  Not bad considering it wasn’t really usable until mid-Summer 2011.

Web Edition is much like Real Studio desktop apps.  You have limited options and there are a bunch of compromises that you might not be able to live with.  If you can live with the compromises, development is very fast.  While deployment can be kind of a pain it seems that most of them revolve around three or four issues (FTP transfer, file permissions, 32 bit compatibility libraries, and the .htaccess file).  The fact that you can reuse much of your code between desktop and Web Edition is icing on the cake.

Anyway, that’s what’s up with us.  How is 2012 starting for you?

The Jan/Feb 2012 issue of Real Studio Developer came out a few weeks ago.  I was incredibly busy and I forgot to post about it.

In this issue I did a report on the Real Studio Database Days event held in Frankfurt, Germany in early November.  It was my first visit to Germany and I enjoyed myself immensely.

My BKeeney Briefs column was about evaluating last years consulting business and mapping out strategies to make 2012 better than 2011.

Tam Hanna had an interesting article on Outsourcing.  Jens Bendig had an article on global variables and Marc Zeedar had an article about building your application based on assumptions.

So how did your 2011 go?

 

There have always been Real Studio users that have been critical of the company and their products.  I have been known to throw a fit every now and then when I get bit by a bug.  There are currently several users in the Real Software forums that seem to be overly critical of the company these days.  These users go out of their way to hijack threads and tell everyone what a crap product Real Studio is and how Real Software is screwing everyone over.

I get their anger.  I really do.  I’ve been using Real Studio for ten years now working on a commercial products for clients all over the world.  Some of those are private apps, some are vertical market commercial apps and some are mass market  commercial applications.  I have probably been bitten by a bug in nearly every release and on every project.  It sucks but thankfully I’ve been able to find workarounds to most and come up with alternatives to others.

Don’t get me wrong, I’m not happy about bugs.  As a developer dealing with bugs is part of the job.  When I was an electrical engineer I dealt with hardware and software bugs ALL the time.  Try explaining to the client why a 1500 degree furnace stopped working because of bad firmware or why you stopped an automobile assembly line because a PLC glitch  When I was doing Visual Basic 6 development my code was a masterpiece of workarounds.  There is no excuse for bugs but they happen.  It’s part of my job to identify them and work around them.

One Real Studio user sent ME an email explaining how crappy Real Studio is.  It was reasonably intelligent email from someone who felt very passionately about the subject.  It was obvious he had a history of using Real Studio as a consultant.  I disagree with him on most every part of his email but I can sympathize.  Am I becoming to ingrained to ‘just dealing with it’?  I dunno.

Part of the problem, I feel,  is that Real Studio is geared for beginners and hobbyists.  That’s great and it’s how many long time users started.  Beginners don’t stay newbies very long if they stick with the product.  Soon enough they get past the initial learning curve and figure out how to ask the questions they couldn’t even formulate before and this is where the experience sometimes falls apart for many Real Studio users.

It feels sometimes that RS is solely interested in getting new users (and hobbyists at that).  New users are not a bad thing (in fact they are critical to any company).  However, isn’t retaining existing customers even more important?  You’ve already done the hard work in getting them to buy into the platform.  All you have to do is find the way to get them to stick with the product and ideally find ways to get them to upgrade to a higher priced product.

The Personal license is so cheap it’s practically giving it away at $99.  The Professional version is $299 so for every Professional license you have to get three Personals.  The Enterprise Edition is $995 so for every one Enterprise license you need ten Personal licenses.  Now, I don’t know what the renewal rate is among the licenses but I would suspect that Pro and Enterprise users renew more often Personal license users.  I know from a business standpoint my toolset is part of the cost of doing business so why NOT keep upgrading until I no longer use the tool?

My point is that Pro users are valuable and Enterprise users should be the most valued customers.  Instead, many of us feel abandoned for a variety of reasons.  As an Enterprise user I really like being able to use Web Edition, and use the product on all three platforms.    IDE Scripting, Build Automation are nice, but I could live without them.  I use the Profiler maybe once a year so it’s a feature that is wasted on me.  What makes the Enterprise edition worthy being an Enterprise product?  What are the compelling features for people to upgrade to Enterprise?  Not much at this point.

I’ve been doing this for ten years and I’ve been asking for the same things over and over again:  a grid component, a calendar control, date and time controls, less flickering in Windows, and finally reporting.  I lobbied hard for reporting and I feel like a fool for doing so since the reporting tool in Real Studio isn’t what I need (nor can use).  Instead I feel like I got a checkmark on a marketing page.

Granted, there are alternatives to many of the things I mentioned.  That’s not the point.  Instead of giving me the things I could use, today, in selling the product to my clients, I’m getting a new User Interface that will probably have some major bug when introduced that will make it less than ideal to use.  Did I ask for a new UI?  No.  I could think of a dozen things I’d like to see BEFORE a new UI comes down the pike.

So my hope for 2012 is some focus on features that Pro and Enterprise users need.  You can debate all day long on what those features are but the fact no one from RS has ever seriously asked me (or any other pro developer that I know of) what I need.  That says what they are focusing on instead.  Perhaps with some true Enterprise features more people would purchase Enterprise.

Well, but then again, I’m a long time Enterprise user and probably a bigger pain to support than those ten Personal licenses.  Happy coding!