is Xojo Enterprise Ready?

In the last couple of months, two of my friends and colleagues in the Xojo world have posted about Xojo being ready for the Business world.  Bob’s article Xojo Should Scream ‘Business’ was first back in late May was the first.  Then recently Kevin article Let’s make Xojo more business centric – Part 1 (of how many parts?).  Now I agree with them.  I have a different point of view.  Not just is Xojo ready for Business? but is it ready for Enterprise?

Enterprise customers due to their size are much more demanding and less demanding at the same time.  I know that sounds really odd but bare with me.  Before and with nocturnal coding monkeys, I have worked with large enterprise companies that were not only Fortune 500, Fortune 100 and Global 100 (yes, top 100 global companies!).  Hard to be more enterprise than them.

64-Bit app

Yes it is on the road map and Xojo is working very hard at making this possible. iOS is already 64-bit.  Mac and Windows desktops should be later this year (maybe even R3).  Console apps (Mac, Windows, and Linux??) this year too.  Linux desktop apps will take a little more time as there is a GTK2 vs GTK3 issues.

Now does every app need to be 64-bit? nope. Most apps won’t hit the 32-bit boundaries.  So being 64-bit is more a check mark on a form.  It also in their mind makes it harder to be locked into something when 32-bit is no longer able to run on newer operating systems.

synapsis: this will fix itself later this year(ish).

Data Location

Data location is a big issue in the enterprise.  As new “Heads of…” or “Vice President of…” come and go, the tool the data is stored in changes.  Microsoft SQL Server to Oracle to Sybase to MySQL to PostgreSQL to to to… Same data just a different database engine.  The issue is how do we update the application to read (and write) the data from the new source?  Having a very simple way to change the source type would be great.  With several of those database engines, you could write a way to make it generic enough to be able to switch back and forth.  But it is a lot of more work on the developer upfront. And we as developers are lazy so we aren’t going to do it unless we have to.

One option is to use an ORM.  Here at nocturnal coding monkeys, we use ORMs whenever it is feasible, which is almost always.  There are a few for Xojo and we have used all of the publicly available ones.  The one we use the most is ActiveRecord.  Bob has written it and has given it to the community.  We have used it with SQLite, MySQL, PostgreSQL and cubeSQL.  There are few nice things about AR (ActiveRecord).  First you can connect to multiple databases at the same time, just any given “table” or object type can only be from one database (can’t join two “users” tables for instance).  Also if you develop your app using SQLite on your laptop (or desktop?) then switch it to a centralized database like PostgreSQL is just a line or two to change and you are done.  So getting back to the issue when a new “Head of” comes in and switches the database engine, all we have to do is change a couple lines of code and recompile.  done.

synapis: using a 3rd party ORM helps with this.

CI (continuous integration)

CI is one of the big keys to DevOps and the “new world order” in software development.  There will be another post about DevOps later.  But CI is very important to large organizations and lots of smaller ones.  I have worked with many organizations that you can not just deploy software to Production.  You check in your code to git/svn, then the CI server builds the software, tests the software (automated QA testing), package it up, and if everything is successful, deploy.  Back at XDC, the guys from Lighspeed told us how they cobbled tougher CI with Bamboo and Xojo.  They had to go through some serious hoops to get it to work.  I commend them on all their work.  But is should be easier. The next item would make this much much easier.  Command line compiling.

synapsis: command line compiling would make this a breeze.

Command Line Compiling

CLC is key for CI.  It is also important for people that are in the Alpha and Beta programs of Xojo.  There are several builds of each and it is hard to sit down and for each application one by one, load source code, test compile, if any errors, report them, then close the source code.  Now this is not just important to CI and the Alpha/Beta testers.  It is important for anyone that tries to stay current with the RapidReleaseModel that Xojo uses.  Between the internal code, OpenSource and customer code that we have, we could easily have north of fifty(50) Xojo repositories.  I don’t have the time to go through the code testing for every repo for every release.

As an Alpha and a Beta tester for Xojo, I would test every version they release (Alpha/Beta/GA) for all my repos if we had CLC.  I would script it and let er rip.  I also know people like Christian that has lots of code example that would love to do mass testing.  Also this will make it easier for Xojo to test all of their example code with every build too.  Helping to catch errors earlier.

synapsis: command line compiling would make all of our lives better.


Is Xojo ready for the Business and for the Enterprise? sure it is.  Just as much as other languages.  Just needs some improvements to make it more of a yes.


Leave a Reply

Your email address will not be published. Required fields are marked *