Busy Updating Products

I apologize.  Blog posts have been slow lately.  Acquiring products from another company is an interesting process and figuring out the StyledHTMLField and Simple Help Editor was no exception.  First, you have to get in the mind of the original developer and figure out what they were trying to do and then determine if you wish to change the code and then test, test, test.  I can say I am very thankful for source code control because I’ve broken a few (too many) things and had to revert to older code!

One of the things we’re doing with Simple Help Editor is changing the licensing scheme to fit most of BKeeney Software’s other commercial products.  That led me down the proverbial rabbit hole because we discovered that the eSellerate plugin works fine in Carbon and Cocoa (after contacting tech support to get the Cocoa update) but fails in Windows (go figure).  Of course this only happens in Real Studio 2012 R1 and higher so I’m sure it’s simply a plugin compatibility issue and hopefully we can get an update soon (because we’re waiting to release!)

The other thing we decided to do was move to our standard preferences system.  The reasoning was twofold:  First, it now works just like every other of our products so my and my team won’t have to think about what the preferences system does because we know it (and use it everywhere).  The second reason, which was kind of by accident but fortuitous anyway, was that we got to touch code everywhere.  Just by replacing the preferences we go to see a LOT of code we wouldn’t have normally touched.

Just by doing these two seemingly minor items I now have a whole laundry list of items I want to change in Simple Help Editor.  Some of it is personal preference and some of it is features I want for my own products.  It’s also a strong possibility that we’ll integrate the Formatted Text Control into Simple Help Editor to not have to rely upon the RTF to HTML conversion routines and the built-in TextArea control which doesn’t allow any graphics to be shown.  This should make the Simple Help Editor text editors to be a bit more intuitive.  If you are are user of Simple Help Editor and have a feature request then please let me know.  I

Speaking of the Formatted Text Control we’re also working on it too and getting it ready for new features in version 3.  Among the planned features are Retina display support, HTML Export, Hyperlink support, and adding a number of simpler examples that developers can (hopefully) use out of the box without any plugins.

Sometimes I am amazed at how long some things seem to take.  I guess I shouldn’t at this point as I come up with estimates for clients all the time.  When it’s my own stuff it seems to take FOREVER to get done.

Anyway, that’s the current update.  Thanks for you patronage and continued support!

BKeeney Software Acquires Developer Products From The PandaWare Company

Lenexa, Kansas, USA (October 16, 2012) — BKeeney Software Inc. has announced that it has acquired two Real Studio developer products from The PandaWare Company including…

- Simple Help Editor: a cross-platform help authoring used by developers of all stripes
- PW Style HTML Field: a set of Real Studio classes for creating HTML email messages, used in several applications built with Real Studio

We are very excited to bring these products to BKeeney Software. These products represent years of work in areas that are fairly unique in the Real Studio world. These products are valued assets for the Real Studio community and we will continue to enhance these products. Dennis Birch, from The PandaWare Company said, “I am happy BKeeney Software has chosen to acquire these products.  They are well known in the Real Studio community and I’m sure they can continue to enhance these products and make them even better in the future.”

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

http://www.bkeeney.com/products/simple-help-editor
http://www.bkeeney.com/products/styled-html-field

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

Protect Your Most Valuable Asset

If you own a house, most likely you have insurance in the event of a disaster.  You might even have a safe box somewhere in your house to protect your valuable objects and you might even have a safety deposit box at the local bank to protect your most valuable items.  Why do many developers not use a Source Code and Version Control System for their source code? After all, your source code is the most important business asset you have and until you hand it over to the client it’s yours to protect. Even if it’s your personal code, why not protect it?

Real Studio doesn’t make this easy, in my opinion, with their binary (rbp) file format. The binary format is very fast and very portable single file in comparison to the version control (vcp) file format that creates a text file for each object in your project. The binary format, in my opinion, gives users a false sense of security. Bugs happen and hard drives fail.

Version control systems can not read the binary format and track code changes. They check in a binary file as a whole unit regardless of how many Real Studio objects are in it. So it doesn’t matter if the code in Window1 has been changed or not because all that code gets sucked into the server.

In my ideal world I’d love to have a format that works with the source code systems but is also as easy to package up and move around as the binary format. Apple’s bundle format would be ideal but as far as I know there is nothing built-in to Microsoft or Linux distro’s that does this automagically.

Subversion servers (and their like) tracks source code changes down to the line of code. Change the capitalization on an RB keyword in Window1.open event? It’s a change that’s noted in the object file (window1) and even to the line of code. When you check in the changes to the server it knows who did it and assigns a version to it.

We’ve used a variety of systems over the years. Many years ago we used Visual Source Safe, CVS, and we currently use Subversion. There are a lot of developers that are using GitHub with a lot of success. Regardless of what you use I believe you should be using some form of source code and version control system. It’s the smart thing to do as it’s the only safe way to store your source code.

Have you every lost code because you failed to keep a copy of it, deleted it accidentally, your hard drive failed, or your computer was stolen? There’s nothing worse than knowing you had some source code that you can no longer find and use. That’s an asset that you’ve now lost – forever.

I know I’m not the only developer that’s worked on a piece of code for a few hours only to realize that it’s crap and I have to revert to the pristine version (because it’s impossible to undo all the changes you’ve just made). You can do this with the binary format if you are really, really good (or paranoid) about making copies of your project but that’s a lot of work. The source code and version control systems are designed for this!

These systems let me save incremental changes, create snapshot copies of the entire project and even compare files across versions so that I can see exactly what’s changed. With multiple developers on a project this is nice to see who changed what and when. When the developer commits a change we all add a note on what we were working on. This is important for us on large projects.

These systems just aren’t for teams, though. Tracking your individual changes is important because sometimes you’ll just be wrong when you change some code and you’ll have to check out an earlier version. These features are very important on projects and teams of any type of size.

Subversion and GitHub can be done on a local computer (not necessarily a server) and from what I know they are not exceptionally hard to install and setup. We chose a commercial host for a variety of reasons. First, I don’t want to purchase and maintain a server with all of the security nightmares that can come with it – the commercial host keeps up with security issues and we all connect via SSL so we know our code is as safe as our passwords allow.

While we do backups of our important files the commercial host is an offsite backup for us.  They do offsite backups of their servers. I know that if my office were to burn down, get hit by a tornado or flood, I would be down as long as it would for me to get a new computer from the nearest Apple retailer and hook up to our Subversion server. That’s a huge peace of mind for me.

We use a Subversion client that is cross-platform simply to make it easier for training purposes. We use SmartSVN which has versions on Mac OS X, Windows, and Linux. While we spend 99% of our time developing our Real Studio applications on the Mac we occasionally need to compile or debug natively in Windows or Linux. The standard UI across platforms with SmartSVN makes this easy and we do not have to copy files across development environments.

We also use a bug tracking system. Unfortunately our version control and bug tracking aren’t tied together but there are plenty of commercial hosts that have both. We tend to commit based on bug reports or, at a minimum, clusters of bug reports. Have a single bug in a class? That’s one commit with the bug ID noted in the commit report. Have a couple in a set of related classes? That’s one commit with all the bug ID’s noted in the commit. At a glance I can tell what bugs were fixed with each commit.

So regardless of the reasons that appeal to you the most, you should be using some form of source and version control system. Protecting your source code assets should be a part of your practice. If you aren’t protecting your most valuable assets your playing with fire. A disaster on your development computer could put you out of business. Protect your source code and yourself.

What about you?  What do you do to protect your source code?

Has Microsoft Already Lost?

I say this with no malice when I say that Real Studio is a fairly small player (development tools-wise) when compared to Microsoft and Apple.  Those two behemoths have much bigger pockets and drive the development environments on their respective platforms.  It’s also fair to say that each has little interest in supporting the other platform.

Real Studio is a good cross-platform development environment that lets a skilled developer create nice Macintosh OS X and Windows applications using one code base.  Most things ‘just work’ and the language makes it easy to take into account the occasional (and sometimes not occasional) platform specific API calls and differences.  Sometimes the differences are a royal pain but rarely have we been stymied in a project as there always seems to be another option available.  And sometimes the trick is know which things to avoid when working on cross-platform apps.

When I started doing Real Studio consulting a decade ago most of the clients who found us were hard-core Apple users.  They had to satisfy their corporate bosses by developing mainly for Windows and if they could get a Mac OS X version as a side benefit that was great.  For the past couple of years it seemed that the clients who contacted us were the corporate IT folks that had legacy Visual Basic projects and didn’t want to convert to .NET (and yes, the boss wanted a Mac version too).

In the past year, however, we’ve been contacted – a lot – by clients invested in .NET and needing a Mac version.  This isn’t just for their internal business apps either – they’re talking about commercial applications.  What’s even more interesting is the number of calls we’ve fielded by existing .NET development shops needing help.

So it begs the question:  Has Microsoft lost the battle of mindshare?  Has Apple now wedged their way into consumer and corporate America to the point where not having a Mac version of your software is a detriment to marketing and sales?

Don’t get me wrong.  Microsoft isn’t going away any time soon, but I can remember a time when if you mentioned Apple (or any non-Microsoft technology for that matter) you were derided for your obvious stupidity.  I can’t tell you how many times I was laughed at for being an Apple developer.  Now, it’s hard(er) to find diehard 100% Microsoft-only IT person.

I decided to write this post after yet another phone call with a .NET developer.  They want Mac versions and they’ve already decided on Real Studio.  But, and this is always the catch, they’re good at .NET and know next to nothing about Real Studio and nothing about Mac development.

That’s where consultants like us come in as we can help bridge the gap in knowledge.  If you’re interested, we have 36 hours of training video’s (over 100 individual videos) available to subscribers at http://www.bkeeney.com/RealStudioTraining/realstudiotraining.cgi including several projects that start from scratch.  I’ve had experience Real Studio developers tell me they’ve learned a few things even by watching the 6 hours of non-subscription video.  Perhaps your .NET developers would get something out of the training?  Perhaps some one-on-one training would helpful?  Contact me – we can help.

I digress (sorry for the shameless plugs).  Have you Real Studio developers been seeing similar trends?  Does .NET seem to be losing its luster?

Thoughts on the Formatted Text Control Acquisition

It’s been a busy couple of weeks around BKeeney Software world headquarters.  Besides our normal (read: hectic) Real Studio consulting work we recently acquired the Formatted Text Control (and various and associated  Real Studio projects and products) from True North Software.

There has been some speculation on the reasons why True North Software sold their Real Studio assets and on why we purchased them.  I will attempt to briefly summarize what I know and offer some commentary.

Brendan Murphy, owner of True North Software, told me that the company is moving in a new direction with consumer software.  This doesn’t necessarily preclude using Real Studio, but since he’s focusing exclusively on the Mac App Store he has no need for cross-platform support and therefore Real Studio is not fitting his needs.  xCode might be harder to learn but it has more Cocoa goodies for now and the foreseeable future.  Developer products just don’t fit into his future business model.

I am speculating that the apps that True North Software has released on the Mac App Store are more profitable then developing and maintaining Real Studio controls.  At the end of the day a business needs to have adequate cash flow and income to survive.

People ask me why there aren’t more third party products for Real Studio and there is no one answer but I’ll give several explanations.  The first is that the Real Studio market isn’t as big as .NET or Java or even xCode.  This alone, I feel, prevents many developers from attempting to get into the market as there are only so many people that could buy your product.

The second half of that equation is that even if you do get it to market there is a strong resistance to buying any third party products.  Seriously, go to the forums and you’ll see people bemoaning the fact that Real Studio is missing some (what they consider) key elements and yet they don’t want to purchase plugins or other third party code.  Those are two very big negatives for getting into the market.

The next issue is that Real Software, in my opinion, is not very friendly to third party developers.  You can’t add anything to enhance the IDE except IDE scripts.  Fine, but then they’re not exceptionally friendly to plugin developers for a variety of reasons.  The biggest one is poor documentation on how to create plugins and certainly no guidelines on how to create native cross-platform controls.  The IDE doesn’t manage plugins very well (either in a folder or not when Real Studio is started) and there is absolutely no version control on the plugins.  Projects don’t track which plugins they require so if you’re missing a plugin hopefully you can figure it out.  There is also no way to register and validate third party classes and controls so it’s up to each developer to implement a serial number system.  I don’t know for sure but I suspect that piracy is fairly common in the Real Studio world.

Real Software does throw third party developers a small bone by offering to sell their products in the Real Software web store.  The exposure is nice and it does make it easier for larger corporations to buy products (only 1 purchase order/invoice to get past supervisors) but the percentage take by Real Software for each sale is large.  I’m not allowed to tell you how much – it’s in the contract.  Let’s just say look at my product prices on the Real Software web store and look at them on my own webstore.  But, I digress.

So the incentive was there for True North to exit the Real Studio developer market.  And that’s how we came into the picture.  We’ve used the Formatted Text Control since before the first official release.  I can’t tell you how many commercial consulting projects we’ve used it in and we’ve been into the bowels of the source code offering code back to True North as we came across bugs and when we changed things to make our projects work better for our clients.

We are primarily a Real Studio consulting company and we obviously do more than just consulting.  We recently released our Calendar Control classes for Real Studio that gives developers a nice full-featured calendar like iCal (now Calendar in Mountain Lion) and Outlook.  Formatted Text Control and the Spell Check Utilities plugin fit in nicely in our new Real Studio Developer products category.

If nothing else, we will continue to enhance Formatted Text Control to meet our needs in ongoing and future projects.  Our ideas alone could propel us to several new versions.  We look forward to adding more documentation, example projects, tutorials, videos and the like in the upcoming weeks and months.  If you have features you’d like to see, please feel free to send them to us!

Anyway, I hope that clears up a few things.  It probably creates a few more questions so ask away!

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!