Tools of the Trade

We are currently getting our kitchen remodeled.  We’ve used the contractor before because we know he does quality work and gets it done when he says it will be done.  Plus, when he gives us a bid, we know that he’s already calculated into the bid stuff that we don’t even know about yet.  There’s not really much difference with doing software consulting.

Most times when clients come to us they have only a vague idea of what they want and need.  Usually we can count the number of paragraphs of specifications on one hand.  So when we start our estimating process we just add stuff in ‘just because’ we know that a typical desktop or web app will require certain types of things.

For example, we know that nearly all applications are database driven.  Thus, we include ActiveRecord unless there is a good reason not to use it.  ActiveRecord gives us some other advantages like speed of development time, fewer bugs, and in an update to ARGen (coming soon) the ability to create initial List and Edit forms (for both web and desktop) with controls already laid out.  It’s far from perfect but using ActiveRecord and ARGen saves us a lot of time.

Many business applications require reporting.  BKeeney Shorts has been around a number of years and has allowed us to create code driven reports.  Now, with the integrated report designer we can give users the ability to create their own reports.  It’s still a young product, and there are things it can’t do yet, but for a vast majority of business reports it works great.  Now, instead of taking a couple of hours to code a report it now takes minutes to design the report and see it right in the designer.

We’ve used the same preference class for many years because it works natively on Mac OS X, Windows and is good enough in Linux.  We’ve developed our Window Menu class that works well too.  For web apps we have our own paging control as well as a customized sorting listbox.  These are all things that we assume we’re going to use in most projects.

Do we factor these things into our estimates?  Of course, we do. We spent time and effort to develop them in the first place.  These tools are part of our standard toolkit and using them saves us, and the client, money.  To put it in terms that our kitchen remodeler might use, he knew going in that he would use a tile saw.  He could go rent one just for our project but he’s purchased one years ago because he knows that he typically has to use one.  Renting makes no sense for him when he uses it for practically every project.

I’m not saying that you need Shorts and ARGen to get your projects out the door (not that I wouldn’t mind the sales), but if you struggle with the tedium of database programming, or you dread doing reports because the built-in tool isn’t what you need, then these tools might be good solutions for you.

Regardless, if you use our tools, or something elses, you need to establish your toolset.  Having a variety of tools to get your projects done is crucial for a consultant.  Whether you use plugins or third party code these have the possibility of saving you hundreds of hours of coding time.  At the end of the day, time equals money.

Happy coding!

Imposter Syndrome

Today I’m going to talk about the Imposter Syndrome.  That feeling that says everyone knows you’re faking it and they’re going to find out, at any minute, that you’re a fraud.  You’ll be cast down into the depths of despair in humiliation because EVERYONE WILL KNOW YOU SUCK!

I’ve experienced this feeling and I’ve had conversations with developers I greatly admire that struggle with this too.  This is both heartening because it means we’re not alone in this despair, but it’s also sad since that means there’s really not a point where you’ve ‘made it.’
Feeling like an imposter doesn’t go away as you gain experience but it’s not as big a deal.  With more experience you know the things you know and have hopefully gained enough knowledge and wisdom to know where to start looking for the things you don’t know.  Still, sometimes, you have to fake it.

Wait, fake it?  Yes.  Sometimes you have to be an imposter.  Let me use a poor analogy to explain it a bit more.

When you start a new video game you just start playing, right?  You know a few rules and as you progress you make mistakes.  You learn from them and at some point you level up.  This comes with a fancy cut scene showing your character victorious over the foe, gaining an object of some value, and gaining experience.  Your character is more wise and capable of doing more things.  You were up for the challenge and overcame the barriers to the next level.LevelUp

Being a consultant and software developer is no different than a video game.  You have to play the game to learn the rules.  The consequences of not learning the rules can be disastrous but hopefully you’ve done your research so those rules don’t kill you (metaphorically speaking, of course).

At some point you level up from time and experience doing consulting and programming projects.  Sadly, there is no amazing cut scene with dramatic music since we rarely, if ever, see the level up process.  It’s shame really because I’d really like to have dramatic music just play from nowhere and obtain some cool device from my endeavors.  But I digress.

For a Xojo consultant, like myself, it’s knowing parts of the framework really well and realizing that I don’t know some parts as well.  I do a ton of small example projects to learn those bits better.  It means creating my own tools to make my daily life easier.  Those tools involve ActiveRecord, and Shorts to name a few.  These were not developed overnight but over the period of a decade.

So the next time you feel the Imposter Syndrome hitting, recognize that it’s a natural part of the process.  You leveled up without noticing and that’s okay.  You can handle it.  It means you’re winning.

VB6 and Windows 10

It looks like the Visual Basic 6 holdouts can breathe yet another sigh of relief.  Visual Basic 6 seems to work with Windows 10 as do VB6 apps, though not without some caveats.

I’ve been reading a few threads in various forums where most people have had few to no problems developing VB6 apps or running them in Windows 10.  I’ve seen at least one VB6 developer that claims they’re OCX laden application has issues when loading.  They say that some of the controls simply fail to load at runtime.  Funny enough, it happens only on 32 bit Windows and 64 bit Windows 10 works fine.  They gave no information if these were new installs or legacy upgrades.

Another developer claims to have problems installing VB6 Service Pack 6 on Windows 10.  They tracked it down to two Registry keys not being written.  This website gives a process to install VB6 in Windows 10.  The fact there is now a procedure to install an old app on a new operating system should be pause for concern.

The only way to get hold of VB6 is to have a MSDN subscription.  The subscription is $500 so that doesn’t seem like a huge burden.  But then again, remember that Microsoft is not supporting VB6 though the VB6 runtime is shipped with Windows 10.

There are a boatload of VB6 applications still out there so I think support for VB6 will be around for a long time.  In April, 2014 an InfoQ article  stated there were hundreds of VB6 developer positions listed on Dice and Monster.  VB6 officially went out of support in 2008 so good luck finding entry level and even junior developers to fill those spots – no one is learning VB6 any more.  One of my old clients has had a revolving door of VB6 developers for several years now and it’s getting harder and harder to find competent VB6 developers, and developers that wish to work with it.

As a Xojo consultant we’ve converted quite a few VB6 apps.  Well, convert is a strong word, really it’s a rewrite.  Despite both using a BASIC-like language, the two languages are diverging rapidly (not that they were ever really all that close to begin with).  Many issues that we spent a lot of time working around in VB6 just don’t happen in Xojo.  In our experience entire modules and classes just disappear because we don’t need them in Xojo.

Xojo is updated several times a year while VB6 isn’t.  Xojo is about ready to release a new version that creates 64 bit versions of Mac OS X, Windows, Linux for desktop, console, and web apps.  iOS will also be 32 bit and 64 bit.  VB6 is stuck building only 32 bit Windows apps.

Is Xojo a perfect alternative for VB6?  No.  It is not perfect for every application.  Because its strength is really cross platform applications there are compromises all over the place.  If you look at Mac and Linux applications they just don’t have the complex controls that Windows does.  For some this is a deal breaker because their application demands it.  However, if you want a Mac OS X or Linux version of your application you’ll want to redesign the UI anyway.

Ten years ago our clients came to us for Windows apps first and if we could do a Mac version for the graphics geek that was great.  Now, they come to us for Mac apps first and if we can do a Windows version for the accountant in the corner that’s great.  Xojo does web apps now and that’s become an increasingly larger portion of our business and VB6 just doesn’t compete in that area.

The Xojo universe is full of VB6 developers and the Xojo forums are full of them.  The developers that have found and started using Xojo usually go through a short learning curve and a few WTF moments.  And then, after they stop trying to make Xojo work just like VB6, they embrace the tool and enjoy life again.

Windows 10 is yet another bullet dodged for VB6 hold outs.  At what point do you start to panic and find an alternative?  I guess if you’ve waited this long you’re hoping that Microsoft keeps supporting the VB6 runtime forever.

I am biased, naturally, but Xojo really is a good product and a good solution for many applications.  If you would like to find out some rough costs of moving your application to Xojo we have a utility that will give us some metrics on your VB6 project.  It can be found at http://www.bkeeney.com/vb2rbconversion/

Happy coding!

Licensing Systems for Xojo Applications

For years we’ve been using eSellerate for purchasing and licensing and registration of our apps.  We’ve recommended it to clients too and, for the most part, it’s worked quietly, steadily, and hassle-free for many years.  Their plugin is still using the old Real Studio format and they’ve said in several emails that they will not support Xojo going forward.  With Xojo moving to 64 bit in the R3 release it’s time for us to look at alternatives.

We liked eSellerate for a number of reasons.  For one, it was pretty simple.  Once you learned the intricacies of their web portal it was easy to add products.  Their sample app sucked but we figured out a better sample and offered it as an example for others on our website.  After years of using them I could set a new product up in as little as five minutes.  Then, they handled all of the various sales taxes and VAT for the states and countries that need it.

After the purchase, eSellerate would send an email to the user with purchase details.  This included license code, download instructions, and any other messages that we wanted to give them.  And all of this without any intervention on our part.  It just worked.

eSellerate also has an in-application purchase which we found to be pretty useful.  Users could purchase the application without ever having to leave the application.  For some people this was a nice feature but I’m not sure how necessary this is any more.  Lot’s of people purchase things over the internet with no qualms.

When it came to the registration part of things they had a number of nice features.  I could control how many machines could be activated with a single license.  This led to some instances where users didn’t deactivate a license on an old machine and couldn’t activate it on a new one.  However, a 30 second trip to the eSellerate web portal usually solved this.

On very rare occasions we’d get a user that couldn’t activate an app because of security restrictions on their network.  To solve this eSellerate had a manual activation process that would bypass all of that.  It was kind of tedious but then that’s why it’s called a ‘manual’ activation.

Bundling products together was pretty simple and even setting up payments to a third party was easy.  It was flexible and I know it was used in a number of bundle offerings over the years because of its simplicity.

So now we are on the hunt for the next purchasing/licensing/registration system.  We could write our own but I really don’t want to do that for a lot of reasons I won’t go into here.  Ideally, we’d find an existing system that integrates into our website that takes a variety of payment types and also handles sales taxes.  The last thing I want is to get hounded by a government entity – I just want that to happen automatically.

I’d also like to keep the per machine registration with restrictions on how many activations a single license can do.  It must work on Mac OS X, Windows, and the most popular Linux distributions.  Not that we have a lot of Linux applications but we have some and I don’t want two different systems if I can help it.

The in-application purchase and registration was nice but that’s not necessary any more.  I think most people are comfortable now buying over the internet.  However, offline activation is still something that is a requirement.  There’s no telling where customers are and what security restrictions are in place.

I guess the other part of the equation is that I, nor or customers, need something them an arm and a leg.  I’ve see a few licensing schemes that want $300 per product per month.  While they seem really nice, that’s above and beyond what we want and need.

A few names that have come up recently are LimeLM, Paddle, FastSpring, and I suppose even the venerable Kagi is in play.  FastSpring is more of an eCommerce front end so what are you using for application licensing?

What I’d like, Dear Readers, is for you to share your experiences, both positive and negative for any of the services listed.  Have any missed any that should be on the list?

Having the Same Object Handle Multiple Tasks

It’s often tempting to write some code to do a task and make it generic enough to handle similar but different tasks.  A great example that we dealt this this week was a picker dialog that was used generically for people, organizations, and skill sets in a Xojo web app.

It made sense.  The dialog is called from multiple places and it does the exact same thing in each place (displays a list and the user can filter on the list).  What’s different is what data we pass into it for initialization and what data it loads for display.  We wanted the exact same UI in all three cases.

We all want to write as little code as possible.  That’s what’s great about being a lazy programmer.  Do more with less.  That works until it doesn’t and, to be honest, we’ve learned, the hard way, that sometimes the best approach is to make your objects do one thing and one thing only.  Why?  Because inevitably the client will say, this is great, but we want to filter for ‘x’ on people, and ‘y’ on organizations, and neither of those things are interchangeable UI-wise and neither x nor y make zero sense for skill sets.

The first approach is to put lots of if-then-else blocks into what was once a very generic picker dialog.  Now it’s a complex UI that has three distinct code paths.  This complicates testing since every time you make a change it now has to be tested in all three areas.  What worse is the code becomes complex and if you’re in a hurry (and who isn’t?) it’s easy to change the WRONG bit of code.

Our solution was to write the first dialog, get the UI working properly, and then duplicate the entire object and customize it for its new task.  <Gasp>  I know, bad OO programming, right?  We disagree and that’s coming from the school of hard knocks.

The end result is that we have specific pickers for people, organizations, and skill sets.  It’s now simple for a developer to make a change for the picker in question.  No longer do they have to think, “gee, which datatype am I fixing this time,” and possibly get it wrong.  Keeping it simple reduces accidental coding bugs and it reduces unintended bugs due to code changes.

Testing also becomes easier because if we’ve done something to the employee picker, we don’t have to test organizations or skill sets.  Likewise for the other two areas.  Simple is good.

The one area that it does become a bit messier is if we have to do general user interface overhaul.  Now you potentially have three places to do it.  However, since we have WebStyles with web apps this becomes trivial unless you’re rearranging UI elements.  Xojo Desktop apps are a little harder since there are no styles but in those cases it’s actually fairly easy to copy/paste UI from one form to another (assuming that’s possible).

Call me cynical, but I would gladly work on UI for an hour to ensure they’re identical to futzing around with code in three separate code branches that are nearly identical.  I am a lazy developer after all.

Our experience says that generic, reusable objects, often lead us into trouble, so we tend simply not to do them.  But how do you teach that to a new developer and one that’s trying to do their best to use good OO conventions?  And when do you reach that breaking point where the generic way makes it harder than its worth?  Good questions that I don’t have good answers for.

Happy coding!

You Don’t Need to Be A Rock Star

I have been a Xojo consultant for nearly fourteen years.  It’s crazy to think it’s been that long and it’s sometimes hard to remember back to the early days of how I knew nothing and didn’t even realize that I knew nothing.

It also tickles me to no end that people consider me an ‘important’ person in the community.  Some might even consider me a ‘rock star’.  I claim no fame in the Xojo world other than I’ve stuck it out when many other developers have left the Xojo ecosystem.  Let’s just say that at times I feel like I’m the Last Man (consultant) Standing.

Can you become a Xojo consultant?  Absolutely!  There is nothing special about what I’ve done and you can do it too.  I have an electrical engineering degree so it’s not like I’m an idiot and it wasn’t until I met my wife who happened to be a software developer that I was given permission to change careers.

In retrospect that was the best thing that ever happened to me (besides meeting the love of my life).  I was an uninspiring engineer and I dreaded many of the tasks that I performed on a daily basis.  Software development, on the other hand, inspires me.  I wake up every day and (usually) can’ wait to start coding.  The fact that I get paid to do it is just icing on the cake.  To get paid to do what I love?  Sign me up!

If you know a little bit about Xojo you can become a consultant.  First, ask yourself WHY you want to be a consultant.  If it’s for the money don’t expect it to happen right away.  I think it was two or three years before we really made any money at it.  It took six years before I hired a second developer and ten years before a third and twelve before bringing my wife on as a software developer (she had always been doing those pesky taxes and payroll things that I hate doing).

So if you do become a consultant don’t expect to make money right away.  Or if you do, don’t expect the money to be consistent for a number of years.  Even now we fight with cash flow so it takes some discipline to ride out the really good times when cash flow is great and the not-so-good times when cash flow is poor.

The road to becoming a ‘name’ is not a quick one.  I spent many years in obscurity.  The first developer conference I went to I was a wall flower and barely talked to anyone.  By the third conference I co-hosted a session with another consultant because I didn’t feel like I was qualified enough to do it on my own.  Now I’m a regular presenter at the developer conferences.

One way to become a recognized name in the community is to teach others.  I’ve written a fair number of tutorials and example projects and I decided to doing video training and so far I’ve got about sixty-two hours of video available for streaming (and offline use now) with hundreds of individual videos and project files for new developers to learn from.

I think this is the part that makes people think that I’m a ‘rock star’.  I get people coming up to me all the time at conferences and engaging me in conversation and thanking me for some forum post, tutorial, or training video that made a difference for them.  It’s gratifying and sometimes a little scary (as an introvert) to have people do that.

Here’s my dirty little secret on those tutorials, example projects, and training videos.  Those are my way to learn something about Xojo and leveraging that experience for others.  Put another way:  The best way to learn something is to teach it to others.  If you are not doing something like this (maybe not for sale but for yourself) you should be.  That’s the only way you’re going to learn parts of Xojo you don’t know as well.  You really don’t want to learn new stuff on client projects (though it does happen occasionally).

As a consultant I don’t know everything.  There are still things that I’ve never touched in Xojo and things that I touch so rarely that I have to go relearn it.  Those small projects become invaluable review later on.

I don’t want to discourage anyone from becoming a Xojo consultant.  It’s not an easy road at times and it is sometimes frustrating and you put in long hours and you deal with bad clients and all the really bad things that come with consulting.  But the money can be good, it can be fun, it can be rewarding, and some clients you’ll be friends with for many years.  If you love, truly love, coding and enjoy the mysteries of it and putting the pieces of the puzzle together then maybe you, too, can become a rock star consultant.

Happy coding!

Capturing Unicorn Tears

I ran across a post on the forums where the developer was asking how to call the Action event of a Pushbutton.  The simple answer is use the Push method.  It simulates the user actually pushing the button with the mouse thus causing its Action event to fire (and on Mac OS X the button actually animates the push – I don’t know about Windows or Linux).  The longer, more nuanced answer, is don’t do that!  It’s a bad idea.  Let me explain.

Let’s start off with a typical development experience.  You’ve created your wizbang new utility.  It starts of simple and you have a simple Pushbutton.  You add the Pushbutton to your window, you then add the Action event and you put your super duper code that captures unicorn tears.  You test and it works great to much acclaim.

Version one goes out the door and users ask for more features.  So you add a PagePanel to your Window and move the existing UI to one of the pages.  But, because capturing unicorn tears is THE feature of your app you add a Toolbar to the window and then add a Button to it.  In the Toolbar action event you need to make the same thing happen that the Pushbutton did before.

At this point you can either copy and paste the code from the Pushbutton Action event into the Toolbar Action event and be done with it.  This is bad because if you change something in your process it has to be fixed in two places.  But you’ve read the documentation and know that there is a Push method on the Pushbutton that allows you to simulate the push and fire the Action event.  This is slightly better because you only have one copy of the code.  But it’s still not great.

The better choice is to create a method that does whatever was in the Pushbutton Action event.  Maybe a method called “Handle_Capture_Unicorn_Tears” is a better idea.  Because then it can be called from either the Pushbutton or Toolbar action events.

I know, this seems like a lot of work, but now version two ships and someone asks, “Hey, wouldn’t it be great to have a keyboard shortcut for getting those Unicorn tears?”  And you say, “Yup,” and proceed to add it to the Menubar with its own MenuHandler.  If you had copied the code from action event to action event now you’d have a third place to maintain it.

Have I mentioned yet that this is a bad idea?  So don’t do it.  I’ve had to fix projects like this where code was copied and pasted each time it was used.  All of them slightly different.  Are there reasons for them to be different in this location versus the other location?  Only the unicorns know and they ain’t telling;  it’s very hard to debug apps like this.

But no, you’ve been trying to be a good developer and know that copy/pasting the exact same code in multiple places is a bad idea.  But you did use the Push method and you now try to call that from the MenuHandler.  Except the window that the Pushbutton resides on isn’t even open yet when you try to Free the Unicorns.  Except that in testing you always had that window open when calling the MenuHandler and now users are reporting a Nil Object Exception and are pretty angry.

I’m sure must be a valid reason to use the Push method.  I just haven’t found it yet in fifteen years of coding Xojo applications.  The Push seems to be the lazy way out when putting the code from the Action event into its own method would be just as easy (and preferable).

Push works for Pushbuttons, but there is no equivalent for it in other controls.  Nothing.  Learn how to call the same method from two places.  It’s not that hard.

I’ll mention a forward looking thing based on Xojo for iOS experience.  In the existing framework setting a controls value via code will always fire it’s action event.  For example, if you set the Value of a CheckBox it’s Action event fires.  In iOS, setting the equivalent Switch value via code does NOT fire its ValueChanged event.  This is on purpose and all iOS controls are like this.  I was told by a Xojo engineer that this will come to the desktop and web frameworks too.  Be warned.

Capturing unicorn tears is cool and I encourage to make such a utility.  Be smart about it and be lazy and not just lazy now but lazy for a year from now.  If you ever have a need to call a control event from another location, make a method and call the method from the spots it needs.

What say you my fellow Xojo maniacs?

Xojo Freemium Model Continues

Late last week Xojo announced that the Freemium model is NOT going to be cancelled and will continue indefinitely. According to a very brief forum post they discovered new information that showed there was no significant revenue difference between the Freemium and 30 Day Models and therefor the Freemium model will continue.

I don’t care which model they end up using. We’ll be buying a license anyway. Freemium has a LOT of advantages to the community. I’m also glad that the revenue difference isn’t significant – which is, by far, the most important part that some are forgetting.

What concerns me the most is the apparent lack of due diligence on Xojo’s part. In the original announcement (since removed – I’ll get to that in a minute) they said they didn’t make this change lightly. It took roughly a week of the community questioning the move for it to be reversed because of ‘new information’.

What the hell? If there is nothing that I’ve learned in my tenure as a Xojo developer is that the community HATES change. Every time there is an IDE change, name change, framework change, licensing change, or pricing change, it will upset more than a few people. Who needs or wants that level of aggravation if it can be helped?

Major policy changes need to be thoroughly vetted well in advance by everyone on staff. Once everyone is on board then, and only then, should it be made public. The change, and subsequent reversal, doesn’t pass the smell test. I believe the decision was made by a select few and not fully investigated internally before it went public.

So lets talk briefly about removing the blog and forum post. First, Xojo has every right to pull it, shred it, burn it, and otherwise recycle the bits. Should they have done that? Well, that’s open for debate. I believe they should have edited the original post with an update at the beginning and end of the article with a quick note and link to subsequent information. That way there’s no hiding the information but also immediately corrects it. But Xojo’s not my company and not my responsibility.

Removing the blog post and forum thread does remove the original blemish. After all, they reversed the decision and really there’s nothing that changes for any user – new or existing. It does leave a minor scar though. Xojo is a small company and the engineers and staff members are incredibly accessible which leads many of us to think “transparent”. Removing historical data leaves a bad taste for some.

Rightly, or wrongly, we expect Xojo to be accessible and transparent and removing those items exposes that as patently false even though it’s never been true. They have zero obligation to be transparent nor do they have any obligation for the engineers to be accessible. They mostly do all those things because they feel like it and it happens to be good for business.

It’s my belief that this will quickly be forgotten. After all, who has it harmed? Not a single person. Xojo may have a little egg on their face but at least it shows that they are flexible. A stubborn regime would have stuck to their original announcement and weather the storm it generated.

Instead they reversed their decision. Removing the blog post and forum thread is questionable but, again, I feel it harms no one except those that feel inclined to be angry at change.

Time to move on and do some coding!

Xojo Ends Freemium Model

This week the Xojo blog announced that they were ending the Freemium model and going to back to the standard 30 day trial period model. As you would expect this has led to an outcry of folks on the forums and there are lots of opinions as to why Xojo is wrong to end the Freemium model. They’re wrong and here’s why.

Xojo said that the Freemium model increased downloads but didn’t change buying habits. The original thinking was that more downloads would get more eyeballs and thus more revenue in the long run. The IDE was free to try and use until you wanted to do a final executable.  It didn’t.  Period.  Their two year experiment with the Freemium model failed.

I don’t mean to belittle the hobbyist developers out there, but there is ample evidence that many of them simply just ran their apps in the IDE rather than compile them as standalone executables, thus not even purchasing an inexpensive desktop license. Obviously this was not the intent of the Freemium model and certainly violates the spirit of the model if not legally as well.

We can argue all day long as to why the freemium model didn’t attract more paying customers. I’m sure there is not just ONE reason but combinations of many smaller issues and here are some wild guesses. Perhaps desktop programming is experiencing a decline and perhaps web apps aren’t growing as much as once thought. Perhaps iOS isn’t an attractive target without Android. Perhaps the lack of business-only features hurts them. Perhaps the IDE design pushes some people away. Heck, I’ve asserted for a long time that the insistence of dumbing down the IDE in favor of newbie programmers is a detriment to the health of the platform. <Insert your favorite theory here>

One argument I might buy is that they didn’t give it a long enough try.  Some times it takes a while for things to take hold.  Add in that two years ago they changed the name of the company/product and lost whatever internet search rankings they may have had and it’s quite possible that it’s only now that people are finding Xojo.  It doesn’t matter now.

Regardless, the bottom line is that the Freemium model didn’t increase revenue for Xojo. At best, it means that revenue stayed the same and, at worst, they lost revenue. No company can stay in business by having static or negative revenue.  Expenses only go down through layoffs and no one wants that.  It’s the right business decision or otherwise we might not have our favorite development tool around in another year or two.

So while it’s sad it didn’t help them I can’t complain. They know the financial numbers better than we ever will. They told us the reasons so it’s time to move on.

What do you think?

LiveCode vs Xojo

I have been a Xojo developer for many years and I make a decent living at it.  That doesn’t mean, however, that I don’t look around at other development environments every now and then.  I do this because it makes good business sense to keep my options open.  This week I looked at LiveCode after a reader asked me to.

LiveCode (formerly called “Revolution”) is a unique development environment that has been around since 2001.  It was inspired by HyperCard and due to its lineage it uses a Card and Stack metaphor to represent windows, objects, and applications.  To put it more in Xojo terms you can think of a window as being a Card and the entire application as a Stack (of cards).  Dialogs and other objects can then be sub-stacks.  LiveCode can make Mac OS X, Windows, and Linux desktop applications, cgi-like web apps, and mobile apps for iOS and Android.

Its scripting is a natural English-like programming language that presumably makes it easy for casual programmers to get started.  Another interesting feature is that there is very little difference between ‘development mode’ and ‘debugging mode’ and switching between the two is literally just a button.  This means that you can run LiveCode commands practically at any time without the need to compile the application first.

The IDE has a variety of windows.  The Application Browser shows you all of the objects in the stack and lets you open each card into an editor.  The editors let you put controls on the Card (layout) and each card and UI object has a number of Messages that are similar to Xojo events.  LiveCode does not have an all-in-one window like most other IDE’s.  At first, I found the individual windows to be refreshing but after I while I found that I was fighting with background application windows.  I’m sure this is something that becomes more natural with usage but I had issues with it.  I’ve always wondered if Xojo’s all-in-one window IDE approach was really the ‘best’ approach to a development environment and now I see that I prefer it as it eliminates the distractions of other windows.  Also, Eclipse, Visual Studio, Xcode and Xojo all have all-in-one IDE’s so I this it safe to assume that most developers are comfortable with this style.  You may find LiveCode strange if coming from an all-in-one IDE.

The LiveCode scripting language definitely takes some time to get used to.  The natural English syntax seems inviting but after 30+ years of coding in various languages I found it frustrating.  It’s wordy and not exceptionally compact in its meaning.  If you don’t already have any programming experience this might be good for you.  If you’re coming from a different language you might be as frustrated as I was.

Xojo events are relatively easy to find and implement.  You simply right-click on an object either in the Navigator or in the Layout Editor and add Events to the object and it’s added into the code waiting for you to add your own code to it.  The object messages in LiveCode are not so easy to figure out, in my opinion.  To figure out the events I had to go into the documentation (which was decent, in my opinion), and had to look them up and then type them into the Script Editor.  I’m sure with a little time and practice I would pick up the messages that I use most often, but it is a hindrance to picking up the language.

LiveCode Dictionary

LiveCode API Dictionary

 

The Xojo Code Editor has a pretty good auto complete.  Auto complete means that when you start typing, say “SQLite”, and if there are either language keyword matches or variable matches the eclipses (…) is shown and if you hit the tab key a list of available properties and methods are shown to you in their proper context.  This makes discoverability much easier.  LiveCode has no auto complete in their Script Editor which means you have to look up the commands before you start typing and you won’t know if they’re correct until you run the project.

LiveCode has objects but they don’t have the same Object Oriented nature as Xojo.  In Xojo you create an instance of the object and then get/set a property or call a method using the dot notation.  Thus opening a database in Xojo means creating a new instance of the Database, setting a FolderItem property on that object.  Then calling the CreateDatabaseFile method on that same object and it returns a true or false to indicate success or failure.  All of that revolving around the same object (database).  The same thing in LiveCode requires less coding steps but there is no dot notation and it’s definitely more procedure driven.  Each method is its own call – not part of an object – and means that you’ll spend more time looking at documentation to discover them.  I feel that Xojo’s discoverability is superior to LiveCode.

LiveCode is not a strictly typecast language meaning you can use a variable anywhere at any time.  This means that writing scripts can be very quick but it also means that introducing errors is easy and with larger projects it might be hard to find errors.  Xojo, on the other hand, is strictly typecast and the compiler will tell you if a variable is not defined or if you try to put the wrong type of data into a variable.  There are plenty of other languages out there that don’t require variable type declarations but I never have spent much time with them.  If you’re used to them it’s probably no big deal but I tend to like the compiler to warn me early and often of any potential issues.  Another little thing about the language is that to assign a value to a variable using the Put command rather than an equal (=) sign.  In LiveCode you would say:

put “ABC” into myStringVariable

In Xojo this same thing would be

dim myStringVariable as String = “ABC”

LiveCode Create DB

Creating an SQLite Database File using LiveCode

Xojo Create Db

Creating an SQLite Database File using Xojo

 

One of the major drawbacks that I discovered early on was that LiveCode does not make native looking applications.  The good news is that PushButtons look the same on each platform (no mean feat) but it also means that those Pushbuttons don’t look native on any platform.  There are commercial plugins available to make LiveCode applications look native on each platform.  I don’t believe that the plugins are using native controls either so this means that an OS update might ‘break’ the look of an application until those plugins are updated.

LiveCode Mac app

LiveCode App running in Mac OS X

LiveCode Ubuntu App

LiveCode App running in Ubuntu

LiveCode Win8

LiveCode App running Windows 8

 

Xojo is not perfect in this regard as not all of its controls are native on each platform either.  It does, however, use them whenever possible.  Another drawback to Xojo is that control features are often times the lowest common denominator between Mac, Windows, and Linux for desktop platforms.  This is more for feature parity than any malfeasance on their part.  Xojo web apps and iOS apps use native controls.

LiveCode, like Xojo, lets you create external libraries using C++.  LiveCode calls these Externals while Xojo calls them plugins.  It appears that there is an active community of developers and an active 3rd party development community for LiveCode.

Unlike Xojo, LiveCode comes in two different varieties:  Community Edition and Commercial.  The Community Edition is open sourced and free but limits you to open source and GPL applications.  If you are interested in LiveCode this is where I’d recommend that you start.

There are four different types of commercial LiveCode licenses.  The Indy Commercial license costs $299/year per seat and lets you do closed source and royalty free commercial apps with a $500k revenue limit (how this is enforced I have no idea).  The Business license costs $999/year/seat and eliminates the revenue limit.  The Pro license $1,999/year/seat and gives you more personalized service and a Premium license is $10,000/year for 3 seats and gives you priority support, use of their test suite, extensions, priority features (whatever that means) and a LiveCode conference ticket.

LiveCode also has a membership program that costs $99/year ($25/year for students) and gives you exclusive membership benefits and helps supports the continued development of the platform.  You also get access to over 100 training videos and access to the LiveCode Conference simulcast.

What I Liked About LiveCode

I found the LiveCode Start Center to be clean and uncluttered and useful.  It has four main areas, Projects that shows your recent projects, Getting Started that has handy links to the some beginners videos and guides, Resources that takes you to tutorials, sample stacks, the community forum and their API dictionary, and finally they have a Sample Projects list that has a sample projects in it.

The LiveCode website also does an excellent job of pointing out 3rd party commercial and non-commercial extensions and what they can do for the developer.  They also allow user reviews of the extensions so it makes it easier to make a purchase decision.  I have no idea what it takes to get listed on their website or if LiveCode takes a cut of the revenue but it’s something I wish Xojo would do a better job of helping their 3rd party developers market.

I also found it refreshing that their API documentation allowed user comments.  I really wish Xojo would do something similar because I feel that we, the user community, could add some really useful comments to the documentation.  While I like the Xojo documentation I feel it might be better served by opening it up a bit (with moderation).

LiveCode does deploy for Android which might be a huge bonus for some.  Assuming I could get a UI that looks native it might be the one thing that would make me look at LiveCode with any seriousness if a client asks for Android deployment.

Finally, the fact that part of LiveCode is open sourced is interesting.  They successfully ran a KickStarter campaign to open source the product in 2013 and successfully did a campaign on their own website to fund HTML5 web deployment in 2014.  I don’t know about anyone else but I would help fund certain items for Xojo development even if wasn’t open sourced (perhaps a better grid control?).

What I Disliked About LiveCode

If you’re coming from C++, Java, or any object oriented language I think you’ll find the lack of ‘objects’ to be disheartening.  Add to it that there is no auto complete for the Script Editor and I think it’s a deal killer for me.  Those two features make discovering events, properties, and methods so much easier without having to constantly check the documentation and I think it’s a huge adverting for Xojo.

The lack of strong datatypes, while not a deal killer, scares me a little.  I want to be warned early, often, and loudly when things go wrong and strong datatypes are something that I really find attractive in a programming language.  If there’s a data conversion going on it’s because I want it to happen (don’t get me going on Xojo variants – they’re evil – get over it).  The natural English scripting language also puts me off simply because it’s unnecessarily wordy.  Again, if you’ve never programmed before this might be an advantage.

The lack of native looking controls is also huge drawback for me.  Xojo apps will try their best to look native (though Linux apps require more of a nudge than Mac/Win apps) and while not perfect, out of the box, Xojo apps are generally native.

Conclusions

Is LiveCode worth a look?  Sure.  Like any development environment, if it speaks to you and you can get your projects done in it then it’s the right one for you.  For me, Xojo is a better language, with a better IDE, and has more features that I want.  Xojo is only lacking Android support and I’d probably look more at Xamarin than LiveCode for a variety of reasons.

If LiveCode works for you that’s great.  This review isn’t meant to be overly critical of the tool but as an existing Xojo developer I don’t see enough reasons to switch from Xojo development to LiveCode.  Feel free to leave comments below on anything you feel I missed or got wrong.