BKeeney Briefs

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?