BKeeney Software Acquires Real Studio True North Software Products

Lenexa, Kansas, USA (July 30, 2012) — BKeeney Software Inc. has announced that it has acquired the RealStudio portfolio of products from True North Software including…

- Formatted Text Control (FTC)

- RTF Parser

- RB Code Reports

- Spell Check Utilities (SCU)

- RBVersioner

- Obfuscate

- RB Linux Maker

- VInstaller

We are very excited to bring these products to BKeeney Software. These products represent years of quality work which we routinely use in our consulting work. These products are valued assets for the Real Studio community and we will continue to enhance these products. Brendan Murphy, from True North Software said, “I am glad BKeeney Software has chosen to acquire these products. They have the technical expertise and integrity to make these products flourish for years to come.”

The new home for these products can be found at the following URL’s:

http://www.bkeeney.com/products/formatted-text-control

http://www.bkeeney.com/products/rb-code-reports

http://www.bkeeney.com/products/spellcheckutilities

http://www.bkeeney.com/products/rbversioner

http://www.bkeeney.com/real-studio/rb-linux-maker

http://www.bkeeney.com/real-studio/vinstaller

http://www.bkeeney.com/real-studio/obfuscate

For more information visit http://www.bkeeney.com or send email to info@bkeeney.com

.

Increased Demand for Cross-Platform Applications

It’s been a busy couple of weeks so I haven’t been posting much.  I have a number of things going on:  New and updated products, Real Studio training, and consulting projects are eating up a lot of time.  Free time?  What’s that?

It’s always nice to be quoted in someone else’s press release.  Real Software issued a press release last Friday about an increase in leads for cross-platform projects.  I was quoted a number of times about our experience as Real Studio consultants.  This one, perhaps, is the conversation I have the most often with our VB6 conversion clients:

According to Keeney, many of his clients have made the decision that sticking with Microsoft for another 10 years is not in their best interests. It means learning a new development environment (.NET) and still not being able to support the Mac. “The only other alternative is to have separate projects — one in .NET and one in xCode, and take their chances,” Keeney added. “Most desire to have the same code base for both platforms and deal with the same developers for each one.”

Mac support is a huge reason why people are looking at Real Studio and coming to us to do the work.  It’s a good time to be a Real Studio developer in my opinion.

Despite my initial misgivings on Web Edition, I think it’s a good addition to our toolkit.  We’ve done a number of projects in Web Edition that we would have turned down a year ago for lack of experience in web technologies.  It’s nice to be able to leverage our decade of experience in Real Studio into a new area.  That’s lead to some very fun and interesting projects.

Anyway, that’s my quick thought for the day.  What’s been your experience?

Sharing Code Between Projects

Someone at Real World asked me about maintaining shared code between projects in Real Studio. He was using external project items (in XML format) and that makes it difficult to work with source control since the XML format isn’t really designed for that. We have a lot of code that we share between projects, both code that we’ve written like ActiveRecord and open source code or libraries that we’ve purchased.

We don’t try to share the code automatically. Instead we keep shared code in a separate project (ideally with testing code, although we’re not at 100%). That code is separately versioned and we update individual projects by copying the new version into the project’s that use it.

In our experience this works much better than trying to share code automatically. We work on a lot of projects and sometimes a project won’t have changes for months or even years. If the shared code has changed in the meantime, we don’t want to go back to the project that uses it and find that it may have bugs that were introduced by changes to the shared code.

This applies to other language also by the way. I can’t see myself ever having code shared between separate projects (with the exception of header files in C or C++).

If you search for vendor branches you can find some more information that’s specific to Subversion. We don’t use the vendor branch pattern ourselves but it’s worth knowing about.

Twas the Night After Real World

I love Real World for many reasons.  It’s like a high school reunion except that you actually like (mostly) and get along with all your old classmates.  Everyone is there at Real World to talk about Real Studio and praise it (and bitch about it).  There were plenty of things to talk about this year.

The good news/bad news is that the 2012 Release 1 will come out later than what anyone expected and will still have the old IDE user interface.  But it turns out that this is good news in that R1 will contain a ton of bug fixes and minor to medium changes that will help everyone.  Release 2 will then have the new IDE.  Personally, I feel that my post from several months ago was pretty much spot on though in no way do I feel that my post had any influence on their decision.  I guess I can say, with very minor satisfaction, “Told you so.”

Web Edition is maturing nicely with news of an upcoming WebCanvas control that works pretty much like the desktop canvas control.  The 1-click installation on Real Software web hosting is interesting and I think I will try to move my web apps to their service so I can go back to regular shared hosting for my website.  Take what’s simple and put it on a simple server and take what’s complex and put it on the complex server.  It will make my life easier in the long run I think.

Cocoa is turning out to be a tough nut to crack.  Apple is doing things MUCH differently in Cocoa than in Carbon in a few areas and it seems that it’s hard to figure that out until you actually do the work.  Any framework is big and the deal with Real Software is that they’re trying hard to make it transparent to us.   But, the move to Cocoa, while very difficult, is an absolute must because Apple is slowly killing Carbon, it’s the only way to get 64 bit support and, it’s the only way to get iOS apps built in the long run.

iOS applications could be huge for Real Software.  Assuming they get it to work like we all need it to and it’s ‘just like’ an xCode app only written using Real Studio then they will have an unbelievably huge hit on their hands.  I can’t tell you how many clients ask me about leveraging their Real Studio code in an iOS app.  Currently that’s not possible.  A year from now?  I don’t know but I’ll be eager to test it even in the alpha stage.

Bottom line is that even though the company has taken a very long time to get the next version out the door I believe that this delay has been put to good use.  They’ve found stuff in the frameworks that they’ve been able to fix before it ever gets to us.  This is a good thing.  The delay is painful (and possibly executed poorly especially considering the talk on Agile software development) but we, and they, will be better off for it.

One can certainly argue the effectiveness of trying to code both the Cocoa framework changes AND a new IDE interface all at the same time but the fact is that they have made the Cocoa framework better by trying to do both at the same time.  By using the framework closer to how WE’LL be using it they’ve identified and squashed many more areas of concern.  The new IDE is a lot of change and some will hate it and some will love it and most of us will be in the middle.  I won’t know until I can spend 8 to 10 hours a day on it for a couple of weeks.  Based on what I saw at the conference that’s not possible now so the delay in getting the new IDE out is another good reason to push it of a release.

This is the first year where I’ve had multiple prospective clients talk to me about work.  If I manage to get all of the work I’d probably have to double my developer staff.  That’s a good problem to have!  I even had one client show up to the conference specifically to talk to me and my developers.

I though the location was okay and it was certainly better than Austin (nothing against Austin, just been there 5 or 6 times now).  I didn’t bring my family because we’ve been to both Disney World and Disneyland so Orlando had no attraction for me.  If they were to hold Real World again next year I’d recommend Las Vegas, San Diego or Seattle.  While some people might have enjoyed having it at the forefront of the big Memorial Day holiday weekend I didn’t as I felt like I lost the first part of it traveling home.  To each their own and I’d love to see more feedback on it.

I want to thank everyone for introducing themselves.  I had a lot of compliments about this blog and the magazine column and that really gives me a warm and fuzzy feeling.  I certainly don’t do it for the money and there are plenty of times where I feel like I’m talking to myself.  So at least I know I’m not totally crazy.  :)

What was your takeaway from the conference?  Do you want me to dig deeper into any topics I’ve been posting about?

 

Hiring Good Developers

It’s been a while since I’ve posted.  We’ve been very busy (this is good) but it cuts down on my writing time.  Here’s a random thought that popped up into my head this morning.

BKeeney Software has three full-time Real Studio developers, including myself.  The decision to add that first additional staff member was the biggest decision we’ve ever made as a company.  It made us anxious and filled us with concern.  Did we have enough work?  What if they didn’t work out?  How much would we need to supervise this person?

As usual, we did our research before we started interviewing developers.  We read the Joel Spolsky book “Smart and Gets Things Done”.  I’d highly recommend it if you are thinking about adding additional technical staff to your team.  We also came up with our own list of criteria to ask about.

When we started interviewing candidates we asked the following questions:

Are they smart?  Well, everyone we talked to either had degrees in Computer Science or certifications so that was really a nonsense question.  Of course they were smart.  But how capable were they of figuring out non-standard problems or things they’ve never seen before?  Were they able to take a problem and figure it out?

Do they get things done?  We wanted an experience developer so that we looked at developers that had some work experience.  Again, most technical people have fairly impressive resumes so it’s hard to tell.  The only way to do this is ask them and someone else (coworkers or past employers) about their project experience.

Can they work independently?  I didn’t want to spend a good portion of my day ‘babysitting’ my developers and with each of us working out of our home that makes supervision very difficult.

Do they work well in a team?  Obviously at that point it was just me but I knew we had a big Fortune 100 project coming up that was going to have multiple team members (from various companies).  I also knew that eventually we’d hire more people.  How did this person work in a team environment?  Was this person a leader or follower, a wall flower or a take charge sort of person?

The team question came from experience working with a local university professor who measured how well teams worked.  He measured things on a Energy and Motivation scale.  The fallacy was that managers always thought they needed High Energy/Highly Motivated people when in reality you needed only 1 or 2 of those (if at all).  Most of your team should have average motivation and average energy but the ones to avoid are the Low Energy/Low Motivation people because they can, and will, drag your team down.

Can they say no?  I didn’t want an employee that would simply say yes to whatever I, or perhaps more importantly what the client wanted, without thinking about the answer first.  They have to be competent communicators.

To start wrapping this post up (I feel like I’m starting to ramble a bit) is that we hired Seth 4 years ago and Robert last summer.  Each is very smart and gets things done.  They work well without much supervision and we’ve found that we work well as a team.  And trust me, they have no problem saying no to me or a client when they need to!  We all have different strengths and weaknesses, and that’s okay, because we’re whittling away at our weaknesses when we can.

I think I would sum up my thoughts like this: Hire someone smarter than yourself.  Some think that’s crazy but I don’t.  I want smart people who get things done without much supervision and who can function in a multi-functional team.  For that you want people as smart, or smarter than you.  (I can hear the chuckles now because finding someone smarter than me shouldn’t be too tough, eh?)

What are your thoughts on this on hiring developers?

Happy Coding!

Open Letter To RS

Dear Real Software,

Thank you for a wonderful product.  It has served me and my clients well for over a decade now.  I can think of no other product that is as easy to use yet as powerful and flexible as Real Studio.  It really is a great product and I have no problems recommending it to others.

I have been critical of Rapid Release Model in the past and will probably continue to do so in the future.  I feel that in too many cases incomplete features and documentation have been released simply to fit the schedule.  I have advocated for fewer releases or releases that stagger bug fixes and new features because I have been bitten, too often, by needing a bug fix in a new release just to be bitten by a new bug somewhere else in the product.  It’s very frustrating for me and my clients.

Unfortunately, at this point in time, we are experiencing the opposite effect.  You see, you have been telling us for over a year that we need to be testing Cocoa because it’s the future.  We’ve taken this to heart because we don’t care to get caught with our pants down.  In addition you’ve also told us that bugs in Carbon, unless critical, won’t be fixed.  This leaves us between a rock and a hard place for our Macintosh builds because we have projects (for paying clients) that can’t be built using Carbon because of bugs, and we can’t build for Cocoa because of Cocoa specific bugs.

We have similar issues with Web Edition apps.  We have a number of very critical bugs that are affecting our delivery of web apps to our clients.  Sadly, what makes this situation hard to deal with is that those bugs are marked as fixed and are only awaiting a new release.

We all know that the goal is to have the 2012 Release 1 be a 100% Cocoa Mac build.  We also know that it is a completely redesigned IDE.  Both are laudable goals and I can only imagine the complexity of managing both of those projects simultaneously.

Real Studio Release 4 was released the week of December 5, 2011.  The three dot releases fixed some hugely critical bugs but contained just a few changes.  I understand that all hands are on deck to get the new IDE up and running and Cocoa polished.  No one is denying that it’s not a huge job to undertake all that at the same time.  I question, however, if you really have the resources available and the proper planning in place to accomplish these goals in a timely manner without understanding the ramifications to your customers.

It’s now been 120 days since the last major release.  Frankly, I don’t care about the 90 day release cycle but it leaves a foul taste in my mouth when you tell us to use Cocoa because you need more feedback and then stick us with a release that has bugs in both Carbon and Cocoa.  Unfortunately, there is no end in sight as there is no release date set for 2012 Release 1 and, as far as I know, R1 is not in beta testing yet.

This delay is starting to be intolerable.  Your failure to plan and execute this transition properly is starting to cost me.  So far, my clients have been patient.  The really large projects are still on schedule but that’s about to end as Web Edition and Cocoa bugs WILL cause them to stop dead in their tracks.  Do you plan on paying my salary and my employees while we wait on you to release a working and stable version?  I’m certain that my clients won’t be willing to pay for projects that don’t work because of framework bugs.

Here’s my fear:  You’ll release a new IDE with all of the Cocoa and Web Edition fixes but because you’re hurrying it through the testing process (because we’re all bitching for bug fixes) it will not be usable.  If that happens I am doubly screwed since I have zero options.  I can’t go forward and I can’t go back.  I see this as a lose-lose situation for me.

I urge you to reconsider the Cocoa and IDE redesign in the same release.  Let us, your loyal, paying, customers get our bug fixes so that you can continue working on the new IDE.  I realize this change will greatly impact the schedule of the IDE.  I also realize that retrofitting the newer framework into the older IDE is also a LOT of work if not extremely difficult.  However, if going back to an R4 update is faster and more stable than the new R1 IDE then I say do it and I will applaud the decision and defend the decision to the end.

I know this letter probably won’t go over well but I’m looking ahead and getting nervous.  I know you’re working as hard as possible but perhaps it’s time to rethink the strategy and go a different route.  Engineering is about planning and adapting to changes.  There is no shame in doing something different.

I hope I’m wrong and things fall into place.  I’d love to pen a post saying thanks for a great release saying that all of my developers and clients are happy.  I see many things that will make that hard to do.  I am nervous and nervous customers are a bad thing.

Anxious and concerned,

Bob Keeney

BKeeney Software Inc.

Clients Coming From Another Developer

If a potential client came to you complaining of another developer in the community, what would you do?  I’ve had a few referrals happen like this and if I personally know the developer I usually send the developer a quick note asking for any details they’d be willing to share about the client.  I’ve only done this for developers that I consider friends but I’m wondering if I’m breaking some sort of protocol.

I look at this way, if a potential client comes to me and is mad at another developer (and names them) I think I should do my due diligence and find out as much as I can about the client.  Should this be a warning flag?  Not all clients are made equal and some are downright bad and not worth the time and effort to court and some you should run away from as quickly as possible.  Ours is a small enough community where a bad client can go through many developers in a short amount of time causing nothing but heartache and financial ruin along way.  I know I’d appreciate a heads up if I was next on the list.

I’ve turned down potential clients because of various issues (mainly just gut instinct but some over contractual issues) only to have other developers contact me later asking if an why I had turned down the project to begin with.  I can hear the dismay in their voice (you know that old style communication thing called voice?) when I give them the answer.  I almost wish they had contacted me up front because sometimes these projects cost people hundreds of dollars (at a minimum) and tens of thousands for a really big project.  We all deserve better than that.

So what do you do if you’ve been contacted by a client unhappy by another developers work?  Have you contacted that developer asking for information?

Happy Coding!

 

Apps For Income Program For the Unemployed

Times are tough for those that don’t have a job. There just aren’t many opportunities out there for a lot of folks.  According to Tech Net, application software development has created 466,000 jobs in the United States since 2007.

Real Software announced an interesting program called the Apps for Income Program that will give away 20,000 licenses of Real Studio to anyone that is unemployed. The only requirement is proof of unemployment from the state you live in.

If you get accepted into the program you get a Personal Edition license for Real Studio and that’s enough to get you started. Real Studio is a software development environment that lets you create desktop applications for Mac, Windows, and Linux using one code base (Note: Personal Edition will only let you compile for the operating system the IDE is running in).

Software development isn’t simple and it isn’t something you learn overnight if you don’t have any experience. It takes some hard work and dedication to learn how to create high quality applications. The documentation and example programs that come with Real Studio are good for a vast majority of new users and there are a number of resources out there to help you learn Real Studio. Some people learn differently, however, and there are resources available to those too.

BKeeney Software Inc. has been Real Studio consultants and trainers for the over a decade creating internal and commercial applications for clients all over the world and of all sizes. Real Studio creates native applications suitable for Fortune 100 clients, the business next door, and for resale everywhere including the Mac App Store.  We offer onsite training on how to get going with Real Studio.

We also offer over 36 hours of Real Studio training videos to subscribers via video streaming from our website. These videos allow the user to see how someone with over a decade of Real Studio experience creates and debugs applications from the ground up. In addition to the video, most sessions have a project file complete with source code that they can use in their own applications.

The training area is written entirely in Real Studio’s Web Edition that makes web applications that can be served from Mac, Windows, and Linux computers. The Web Edition training web app has served up thousands of minutes of video since it went live in the Fall of 2011.

You can find more information about the BKeeney Software Real Studio training program at http://www.bkeeney.com/realbasic-training-section

You can find more information about the Apps for Income program at http://realsoftware.com/company/news/2012/appsforincome.php

Dear Idiotic Developer

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?

Busy Month

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?