A Short Video is Worth a Hundred Emails

One of the ‘joys’ of consulting is the language difference between developers and the customer.  Developers have a ‘language’ and clients have a completely different ‘language’.  A perfect example is when a customer says ‘the application crashed’ and trying to interpret that.  I usually end of asking, did this crash mean a dialog appeared saying something happened (an exception was caught), or that the app just went ‘poof’ and disappeared (something way more serious).  For Xojo developers those two definitions of ‘crash’ mean totally different things.  Those nuances mean nothing to the customer.

Email is a notoriously bad way to communicate.  It’s easy miss details, or worse yet, misconstrue intention.  It’s easy to read anger, annoyance, or <insert feeling here>, that the sender did not imply.

We’ve had instances where we go round and round with a client via email on some detail when a simple phone call would have solved the issue within five minutes.  I know it’s not ‘modern’ but sometimes a simple phone call solves a lot of issues.

More recently I’ve had a client say that a sequence was wrong and described it with some detail.  I took a stab at the fix and then gave them another build for testing.  Still had issues.  The problem was that they’re not describing what’s really happening – they’re using customer language when I needed developer language.  The solution was a simple video.

Most people have a smart phone that can take video.  In my case, once I knew what the customer was really doing it was a simple fix because I could see what they were really doing.

Voice calls are important, videos are important, and doing screen sharing is becoming another important factor.  Think about using any of these tools before sending yet another email.

Xojo:  The Best Secret in the Programming Industry Part 2

In Part 1 of Xojo:  The Best Secret in the Programming Industry we talked about some of the capabilities of Xojo and why it’s such a great software development tool.  We finished it with the question on why isn’t Xojo more well known?  If it’s such a good development tool why doesn’t everyone know about it?  There are no easy answers to this but I’ll identify some of areas of concern.

Entrenched IT Departments

The first issue is the BASIC language.  Xojo uses a form of the basic language.  However, it’s nothing like the gwbasic many programmers learned in high school.  It is a highly evolved, object-oriented language that happens to use a form of basic as the syntax.  Unlike other forms of basic, Xojo compiles down into a self contained executable needing no outside libraries.  It is not an interpreted language.  It’s not a ‘toy’ language.

Yet, the stigma of Basic still persists.  I think in many cases it’s because Basic is very approachable for new developers.  Many of these developers are not programmers by education and are coming at the language to get something done.  If you’re trying to introduce Xojo to your corporate IT department filled with programmers, that have spent thousands of dollars on their eduction, Xojo doesn’t fit any of the checkboxes of any of the current, hot, and yet soon-to-be-obsolete development tools they’ve learned.

From my own personal experience we had a Xojo app working as a prototype, proof-of-concept application, for a big Fortune 100 company.  Their IT department laughed at it and then turned around and told the project owner that it would take them TWO YEARS to start working it (they were busy after all) and they estimated another two years of development time.  Um…with Xojo our small five person team spent under a year on it starting from scratch and got it mostly working!  But that didn’t matter.  Never underestimate the power of entrenched IT departments.

And, much like in the Visual Basic 6 era, just because you can create a very useful application with the tool doesn’t mean that it is a great application that adheres to all of the modern principles.  Simply put, just because it’s easy doesn’t mean anybody can magically create a great application.  Software development takes some skill and some discipline to make a good application and sometimes beginning programmers don’t know any better (regardless of platform).

 

Who Is Their Market?

Honestly, I have no idea who Xojo markets to.  I’ve used the term hobbyist in the past but Xojo prefers the term ‘Citizen Developer’.  Whatever.  I think we’re talking about the same crowd.  They’re people that aren’t necessarily getting paid to develop software or it’s not their primary function in their job.  While, I don’t have a problem with getting more of these types of people into the community but what I really want are the enterprise users.

The trick in either the citizen or enterprise developer is how do you reach them?  In years past you could do some advertising in magazines but that market has gone to the web so it’s much harder to identify and advertise.  What is Xamarin and the other cross platform tools doing to advertise?

Here are a few ideas:  What about sponsoring a podcast or webcast that business owners or developers listen to?  It seems like there’s a podcast for everything these days but the trick is to identify a podcast that might have a lot of listeners that fit the ‘citizen developer’ model.

The Raspberry Pi has some interesting possibilities and, I think, fits with Xojo very well.  When Remote Debugging is completed this makes Xojo an excellent choice for the platform.  I would think there is a number of marketing opportunities that open up from magazines to podcasts to websites that do nothing but talk about the mini computer.  I imagine a ‘show us your Xojo Raspberry Pi application’ contest.

One of my new developers discovered Xojo as part of a software bundle from a number of years ago.  It’s a long gestation period but giving out a free single platform license every couple of years does seem to grow the user base.  This is anecdotal evidence, of course, but it makes sense to me.  When the programming industry got started what you used at work became what you used at home.  The flip side could also be true:  if you start with a really good tool as a youngster you might end up using it later to get stuff done.

Many of our clients ask about Xojo and ask if I think they’ll be around in five years.  For a company that’s been around for twenty years already that seems like a silly question but perhaps Xojo needs to use that as a marketing point.  They’ve been around longer than most of the current, hot, software development languages and tools.  I doubt they’re going away any time soon.

Third Party Tools

This one is near and dear to my heart because this issue has been around since I started with Xojo fifteen years ago.  The Xojo community is small and there is not a big community of developers writing add-ons for it.  There are tools for almost anything you want that range from free to commercially supported.  The difference is that not all third party tools are supported equally and some developers aren’t exactly quick to support their products.  Some developers look at Xojo and are scared away by the lack of third party components.

On the flip side, developers don’t write add-ons for Xojo because the market is small.  We, BKeeney Software, have developed several components and can tell you that we couldn’t survive on component sales – a vast majority of our income is from consulting.  We cheat and spend a lot of time on those components that we use ourselves.  Either way we win.  It’s either a competitive edge when bidding on projects or we make a little extra cash with sales to other developers.

I don’t feel that Xojo does a very good job of promoting third party products.  They do sell some of those products through their web store but there are no previews, no demo’s, screenshots, or anything, to tell you how good those products are.  There’s no way to link to the developers website, how long the product has been around, or when it was last updated.

I would love to get my products in front of more eyeballs.  The store in its current form isn’t doing it.  I would also gladly pay to promote some of my products (like our reporting tool) that I think many Xojo developers might find useful.  Even better, I’d love to create a lite, free version, that could be bundled with Xojo.  Sure, it’s a bit more work right now, but in six months or year, some of the people using the lite version might buy the full version.

Currently Xojo has the ability to use plugins written in C++ and there are some incredibly useful plugins out there.  We own most of them because they save time and money on many projects.  Xojo has announced that sometime in 2017 users will have the ability to create plugins within the IDE using Xojo itself.  This has the potential of really growing the market but until it’s in our hands we won’t know for sure.  This is a critical component in 2017 for Xojo to help foster the third party market.  Hopefully Xojo helps promote them too in such a way that’s a win-win for both Xojo and the developer.

No Books/Lack of Training Material

One issue that some people have with adopting Xojo is that you can’t go to Amazon and find a Xojo book.  There are some older REALbasic and Real Studio books but mostly they’re out of date (though still valid for much of the language).  We, BKeeney Software, offer video training and we have about 65 hours of video that has some Real Studio material in it as well.  The name change to Xojo from Real Studio and REALbasic hasn’t help them in that regard and it will get better over time.

Another issue is that Xojo is on a ninety day release cycle.  It means that if I write a book that is completely valid today in three months there is a good chance part of it becomes obsolete.  Every ninety days Xojo adds something, changes something, and fixes bugs.  There is no way a printed book ever stays up to date.

If you’re looking for written material I’d look at www.xojolibrary.com as the topics tend to be narrowly focused on a specific topic.

I’ve thought about writing a book on database programming using Xojo.  I even have an outline and some chapters fleshed out complete with code examples.  But, since I know the new Xojo framework changes many aspects of Xojo it’s not worth it to complete the book.  Why write it now and have to rewrite most of it when the new framework comes out?  The community is small and the number of people that would be willing to write a book is even smaller.  I think to get a book into Amazon and other books sellers Xojo is going to have to commission a book to give an author an incentive to complete it.

Competitive Advantage/Keep it Secret!

There are some people that are using Xojo and making a great living selling their Xojo-made applications.  They’re just not vocal about it.  I’ve heard clients tell me they don’t want their competitors to know they use Xojo because they feel it’s a ‘competitive advantage’.  It takes them about a quarter of the time to put out a new version that their competitor (who is using more ‘traditional’ programming tools) can do.  That means more sales to them.

I get it.  Remember my story about the working prototype that the IT department laughed at?  It’s five years later and to the best of my knowledge the project was never started.  Imagine how they’d be feeling now if that Xojo prototype project had gone into product?  The project owner would be a flipping hero for solving the problem quickly for far less money than they could do it internally.

They’re not Apple or Microsoft

Xcode is the standard bearer for macOS and iOS development.  Apple is tight lipped on many of their new technologies so a third party developer like Xojo finds out at the same time the public does on new API’s and technologies.  Likewise, Visual Studio is Microsoft’s preferred development tool and while they’re not as forward thinking and don’t obsolete older technologies nearly as much as Apple they do introduce new technologies at a fast pace.  There is simply no way for Xojo to keep up with either of them.

This might be one of the biggest drawbacks to Xojo.  Because they have to be reactive to the whims of Apple and Microsoft they are always late to the party.  It took Xojo a few months to quickly deprecate QuickTime from Xojo because Apple deprecated it and shortly afterwards started rejecting applications from the Mac App Store that used QuickTime.  I think they did admirably in that situation but what’s the next bombshell?  That the Mac lineup is moving to the ARM processor?

At their developers conference last month they told us about a new feature called Interops that, at least for macOS and iOS, and Linux, make future platform changes easier to transition to.  However, there’s no guarantee that something else won’t change in the future that causes Xojo to play major catch up.

Conclusions

It’s truly a shame that Xojo isn’t more well known.  It’s a great tool that accomplishes a lot of things that other development tools don’t even try to do.  I think the community is getting larger and one would hope that there is some tipping point where Xojo becomes synonymous with cross-platform programming.  It has some extremely important deadlines to meet in 2017 to keep the platform moving forward.

Did I miss any reasons why Xojo isn’t more well known?

Xojo: the Best Secret in the Programming Industry Part 1

Xojo turns twenty years old in 2016.  That’s an extraordinary feat not only for a business but even more as a development tool.  The simple fact is that 90% of all businesses in the United States fail within two years.  There’s a significant number of the remaining businesses that fail two years after that.  Xojo has beaten the odds from a business standpoint.

When it comes to software development tools and languages it seems that every time you turn around there is another programming language of the moment that is the hot, hot, HOT thing that everyone has to learn and then two years later it is relegated to old, has been, technology.  Each one promises to make software development easier and faster and in most cases they solve A problem but not necessarily all problems.  In reality, every development tool still requires a competent programmer to do some work – you get nothing for free.

Xojo has been renamed multiple times first as REALbasic and then as Real Studio but in each name iteration it’s been the same product:  a rapid application development platform and language that creates compiled desktop, console, and web applications native for Mac OS X, Windows, and Linux.  Not only in 32-bit but also for 64-bit.  For a vast majority of users it really is as simple as checking a box captioned “Windows” to create a fully functioning Windows application that works the same as the one you’ve create on the Mac or in Linux.

Xojo started out twenty years ago as CrossBasic before Real Software Inc purchased the rights.  It was modeled after the very successful Microsoft Visual Basic and those roots are still visible today.  Xojo initially ran only on Macintosh but within a few years it ran on Windows.  It now runs on Linux too.

Xojo has transitioned from 68k Macintosh desktop apps, to PowerPC apps, to Carbon apps, and finally to Cocoa apps.  Recently they transitioned from 32-bit applications to 64-bit applications for Mac OS X, Windows, and Linux and introduced Linux ARM as a new target.  This transition is still in progress (the IDE is still 32-bit and remote debugging isn’t available for 64-bit yet) and they’ve announce more transitions on the Windows side to start moving away from the venerable Win32 framework for some things.

Besides desktop apps Xojo also creates console and web apps.  Web apps are a different beast as they expect to keep a constant connection between the browser and application on the server.  This makes web apps work a lot like desktops apps and eliminates a host of typical web app issues.  These web apps can be deployed as either cgi applications or as standalone apps.  The cgi applications work with Apache or IIS servers.  Standalone builds require no server and act as their own server which makes them very easy to deploy to any Mac OS X, Windows, and Linux machine.  Much of the code used in a desktop app is reusable for web apps.

A few years ago Xojo introduced the ability to create iOS applications which introduced yet another target.  iOS transitioned quickly from 32-bit to 64-bit after one of Apples famous ‘deprecations’.  iOS built under Xojo works with the iOS Simulator that comes with Xcode to accomplish remote debugging.  Just a few weeks ago Xojo announced that in late 2017 Android will become another target.

Xojo is an integrated development editor, or IDE, that allows a developer from within one application, to write all the code, layout all the user interface, and include any resources necessary for it to work.  It has a series of built-in editors that mostly mean you’ll never have to leave the Xojo IDE.  Working on desktop, web, console, or iOS projects expose the available libraries and controls for those targets.

Xojo lets you compile final executables or do remote debugging to any of the supported platforms.  So while working on Mac OS X I can remote debug an application in Windows running on another machine on the same network or in a VM environment.  While remote debugging, any exceptions that occur in code are revealed in the IDE and users can view variable values and see the call stack.

These things are nothing spectacular by themselves because many development tools can do them.  What makes Xojo remarkable is that is does this regardless of what platform you develop on.  A Windows developer, Mac OS X developer, and a Linux developer get the same capabilities and can deploy to any of the other platforms.  The only exception is that to do iOS you must be using a Macintosh and have Xcode.

Like any tool it has its detractors but it’s managed to transition, quite quickly at times, due to sudden announcements from Apple (who thought they’d move away from PPC?  Or iOS apps would be 64 bit that quickly?) and from the inevitable changes from Microsoft, and the sometimes daily changes in Linux distributions.  Some users complain about the number of bugs introduced in new releases or that bugs sometimes go years without being fixed.  It’s my opinion, though, that every developer complains about those things in their development tool of choice.  Xojo averages a release every 90 days (with the occasional dot release) and always add some new features and fixes many bugs.

The Xojo community is incredibly welcoming to new people.  There is not a lot of condescension given to new users that ask simple questions on the Xojo forums.  Unlike some other venues there is not a lot of vitriol going on.  The Xojo engineers frequent the forums and answer questions.

Since Xojo has lasted twenty years they’ve already beaten the odds.  There is every indication that they’ll be around many more years.  They are no Apple, Google, or Microsoft, but yet they keep churning out new versions that attempt to keep up with the ever changing development landscape with what many would consider a very lean development staff.  Most of the development staff are former users so there is a high level of familiarity with the needs of the user base.

So why don’t more developers know about Xojo?  With the features and history described above it seems like everyone show know what Xojo can do for them.  That doesn’t seem to be the case so why not?  In part 2 we’ll examine some of those reasons.

Xojo Musings

iOS 64 bit builds was introduced in Xojo 2015 R1.  Raspberry Pi support and 64 bit builds for Xojo desktop, web, and console apps was released in Xojo R3 in October 2015.  iOS, Raspberry Pi, and the 64 bit builds are all using the LLVM compiler.  The lack of a 64 bit debugger really holds back adoption of these new platforms in Xojo, in my opinion.

I’ve spent the last month working on a couple of different Raspberry Pi projects.  One was for a client and one was for fun.  In both cases the projects weren’t exceptionally tricky or complex but they took way longer than necessary since you can’t ’see’ anything while it’s running so I was is forced to use ‘old-school’ debugging methods with log files, message boxes, console messages, and whatnot.  Regardless, it’s not fun using the Raspberry Pi with Xojo.

It’s obvious that the move to 64 bit is much harder than they anticipated.  If it was easy the Xojo IDE would already be 64 bit by now – a year after 64 bit was released.

As a company we’ve officially held off on supporting 64 bit builds of our products.  Both Shorts and Formatted Text Control use XojoScript which isn’t 64 bit compatible yet.  XojoScript can be stripped from both products but it’s not an ideal situation and one that seems pointless since 64 bit is coming – eventually.

Xojo 2016 R3 was released a few weeks ago so the chances of R4 coming out in October is pretty slim.  The Xojo Developers Conference (XDC) is coming up in two weeks so I’m sure everyone at Xojo is gearing up for it.  And since they are all at the conference there is not much chance of real work getting done that week.  Good for those attending but bad for those anxiously awaiting new features and bug fixes.

In the past two and half years Xojo has added two new platforms (iOS and Raspberry Pi not to mention 64 bit builds) and not added any permanent staff (that I’m aware of).  Xojo does amazing stuff with the limited staff it has.  While they swear it doesn’t take away from their work I have to call them on it.  Two new platforms with initial development cost, debugging time, and the subsequent bug reports from users HAS to slow them down on other things.  It simply does.

I’m not doing their level of work but we manage five employees each with their own set of projects.  To put one person on ‘project x’ when they’re already working on ‘project y’ means that ‘project y’ gets delayed.  Since 2016 R2 was a big iOS release one has to wonder what was delayed to get those features added (and some would argue they were a year late anyway but that’s a different post).

I’m hoping to see a 64 bit debugger at XDC but I’d bet on a 64 bit IDE first.  This makes sense because they need time to work with it internally before we see it.  This will mean that XojoScript and whatever else was holding 64 bit back has been figure out.

Other things I predict for XDC:

Android.  Don’t get me wrong, I want Android because I feel it’s the only way for Xojo to grow into the mobile space, but if it means that the same staff are now adding yet one more platform it’s not worth it.  I’d rather have the big ticket items they’ve already said are coming than yet another platform that takes precious time away from what they already have. Likelihood:  sadly, pretty good given a recent Xojo blog post

Windows framework changes.  It’s been a while since Windows has received significant love.  We know they’ve been talking about using part of the .NET framework in Windows and now that Windows XP support was dropped this might become a reality.  The only question is what does it give us and when do we get it?  Likelihood:  Good

New framework additions.  The Xojo framework has been slow to gain momentum in the community.  Part of it is bugs those brave enough to use it have discovered and part of it is that it’s incomplete.  I’m not sure how much of the new framework is used in new parts of the IDE but it seems like this would become a bigger part of their mission as time goes on.    Likelihood:  Good

New database frameworks.  In iOS we’re already seeing the potential changes coming where a database error throws an exception.  This is a good change but will require a lot of patience on our part to get used to.  Many XDC’s ago Xojo showed off ORM classes (a lot like ActiveRecord but built into the IDE) for SQLite that looked interesting so it will be nice to see if that’s gone anywhere.  Prepared Statements are now built into the SQLExecute and SQLSelect commands but they’ve also screwed up (read removed) dynamic queries with the lack of BindType and BindValues so I’m looking for a new solution in this front.  Likelihood:  Maybe

Libraries with Xojo.  This was brought up last year at XDC so I don’t expect to see a lot of news about it but I do expect an update.  It would be really nice to create libraries using Xojo instead of using plugins or encrypting source code.  Likelihood:  Mention only

Plugin Management.  The simple fact of the matter is that many Xojo developers (myself included) use plugins.  For many it’s the simplest way of doing things and between Monkeybread Software and Einhugur they offer a ton of functionality that is not built into Xojo.  It would be nice to have the IDE manage them so you can have multiple versions of a plugin installed and only some of them activated on a per project basis.    Likelihood:  Wishful thinking

I’m sure there will be a surprise or two but honestly I expect methodical, evolutionary changes.  What news do you expect to see from the Xojo Developer Conference?  What would surprise you?

Xojo 2016 Release 3

Xojo 2016 R3 was released today.  This release is a much smaller release than either R1 and R2 and despite not having any major new features has some nifty new small features and changes that will probably make your life easier.

You can now create a new event definition by right-clicking on an existing event and choosing “Create New Definition From Event”.  If you have ever subclassed a control you know what a pain this can be.  You need the Open event for your subclass, but you need to create a mirror Open event so the user could do something.  Before this release you had to create the definition manually and then hope the parameters (if there were any) matched.

Making ImageSets from existing pictures is easier.  Right-click on the picture and choose “Convert to Image” where it will create an ImageSet and put this image at the base image.  The only caveat to this feature is that you must have the Supports Hi-DPI setting in Shared Build Settings checked.  This seems like a needless restriction in my opinion.

You can now right-click an item in the Library and be able to create a new subclass from that menu item.  You no longer have to add a class and then change its super to the class you want.

Extract Super is a new right-click option on a class that lets you extract code items.  If you have a subclass , like the Listbox, you can now extract the super and tell the IDE which methods, properties, constants, delegates, enumerations, etc it should have.  To do this before would have been an extremely tedious and time consuming task.

Right-clicking on the Contents headers in the Navigator lets you insert things into your project.  In a similar fashion, right-clicking on a header of an object lets you add another of the same type.  If you right-click on Methods the only thing active in the contextual menu is the Add method.

The contextual menu in the Code Editor has two new additions.  You can now “Wrap in #if false #endif” and “Wrap In For Next”.  Both of these will options will wrap currently selected code in that code.  Another interesting adoption, “Convert to Constant” will take the currently selected code and bring up a Constant dialog allowing you to change the Name, Scope, Type, and Value of the constant before saving it and replacing the code with the new constant.

The icon for the Xojo Project file now has a solid color that helps distinguish it from the other Xojo text files.

The Library now has two “All” entries.  One is “All Controls” which shows every control including custom subclasses in the project.  The second is the “All Built-In Controls” which is just the native controls for the project type.  There is a new attribute you can add to a control, “HideFromLibrary” that you can add to a control subclass that keeps it from listing in the library.

If you like to have non-standard code editor colors you can now import and export color themes in preferences.  Also in preferences you can set how many “Recent Items” there are in the menu of the same name in the File menu.

As with every Xojo release, R3 has a not insignificant number of pure bug fixes.  I encourage you to look at the entire list and decide for yourself if anything important to you has been fixed.

An important bug concerning MySQL was fixed.  In the R2.x series using a MySQL connection in a thread would just ‘hang’ and never come back.

In my own testing R3 has been solid.  I did run into an issue with a web project that I opened in R3, saved it, and then tried to reopened it in R2.  I got the infamous “You might lose data” message that’s always scary.  In R2 I did an analyze project and saved it with on further issue.  So remember kids, backwards compatibility is a blessing – not a guarantee.

I enjoyed this beta cycle.  It was much smaller and easier to test.  Without major new features it seemed a less rushed cycle.  Hopefully R4 will be as good.  Will we finally see 64 bit debugging?  Man, I hope so as a current Raspberry Pi project really could use it.

Anything in R3 that you’re particularly happy to see?

Edit:  As Tiago points out in the comments section I forgot to mention the compiler optimization settings!  This dropdown in Shared Build Settings area will choose an optimization level (Default, Moderate, and Aggressive) for Raspberry Pi and any other project built for 64-bit.  Early reports suggest that it does a good job on math intensive projects as well as projects that are using a lot of loops.

It missed my initial list because we’re not building for 64-bit yet – waiting on that debugger.  I apologize for the omission.

Happy 50th Birthday Star Trek!

Today is the 5enterprise-movie-facebook-timeline-cover-photo0th anniversary of Star Trek.  For many people it inspired us to be better people and get involved in technology.  I think I can say with some relative certainty that I would not be who I am today if I had not watched Star Trek.

I am too young to remember when Star Trek originally ran but it was a staple of syndication by the time I was a youngster growing up in rural America.  This was a time before satellite television and we had only four channels (the horror!).  Star Trek was on every Sunday afternoon and it quickly became a must-watch show in our family.
One of my fondest memories was going to my grandmothers house and watching Star Trek with my cousin.  She was the only family member that had a color television and she was content to let us watch “that show” as long as we relinquished control before the Lawrence Welk Show came on.  Good times, let me tell you.

I recently attended the World Con convention in Kansas City.  This is one of the big science fiction and fantasy conventions of the year where the Hugo Award is given out.  Think of it as the Oscars for SF and Fantasy writers/readers.  I attended quite a few writers panels where panelists brought up Star Trek as being a major influence.  It was surprising to find that authors that I admired had the same influence as me.

Star Trek is part of the pop culture now.  Who doesn’t know what a Vulcan or Klingon is?  It’s what every show about space travel is compared to in some way.  The impact it has made on our culture is huge.
Star Trek is surprisingly liberal when you think about it.  It was where liberal ideas got presented to a conservative audience in a way that was palatable.  It made a huge difference in the lives of many people.  Black men and women saw Uhura on the command bridge doing real and important things and no one (on the show at least) cared that she was a woman or black.  As a kid I didn’t know it was a big deal that Kirk and Uhura kissed.

Star Trek and its subsequent followup shows talked about the politics, religious, and social issues of their era.  Of course you didn’t know it at the time – it was just entertaining – but like any good science fiction story it explored the grey areas of the day.  In my opinion, science fiction is the last remaining political and social commentary avenue available for modern era writers because it’s not about ‘us’ it’s about the future or some alien civilization.  It’s easier to see the injustice when it’s not about present day us.

There are other numerous examples of how Star Trek predicted the future, or perhaps helped change the future.  Automatic doors, cell phones, tablets, talking computers, and any number of other ‘futuristic’ technologies in Star Trek are now commonplace.  Imagine what the next fifty years will hold for us technology wise!

The other thing that I love about Star Trek is that it gives us hope for the future.  A future where we’ve learned to work together for the greater good for all species.  To not ignore our differences but to embrace the diversity of ideas that we all bring to the table.  To use technology for good things but also be wary of its abuses.

Happy Birthday, Star Trek.  Let’s hope the next 50 years are as fun, memorable, and thought-provoking!

To Be or NOT To Be

I’m probably getting into quasi-religious questions here, but I’ve been reading someone elses code in an OPC (Other Peoples Code) project and they use a lot of statements like this:

If Not aBooleanValue then
   
   //do something here

I find this harder to read and much prefer:

If aBooleanValue = false then
   
   //do something here

I understand why people want to use the former but to me it reads backwards.  I have to flip the value in my mind before the variable and then keep that in mind for the eventual comparison later.

And don’t get me going on people that do things like this:

If Not (SomeFunction > 0) then

//do something here

To me, that’s just being too lazy to correct your code.  What should be explicitly clear is now not so clear (granted, this is a super easy example but you get my point).  I like to code for explicitness which means it’s easier to read (by me or someone else) weeks, months, or years from now.

I’m lazy.  I freely admit this.  I prefer to see the test values explicitly called out.  So something like this:

If aBooleanOne = True and aBooleanTwo = False and aBooleanThree = True then
   
   //do something here

is better than:

If aBooleanOne and Not aBooleanTwo and aBooleanThree then
   
   //do something here

For every ‘rule’ of course there’s an exception.  For simple boolean comparisons where I am checking for true I tend to write:

if aBooleanValue then
   
   //do something here

The True check is explicit and there’s only one variable to compare.  As soon as I use a second variable I will change it to be more explicit.

It’s such a little thing but when reading code one seems much easier than the other.  Or perhaps it’s just my OCD shining through.

What do you think?  Am I being overly critical or do you have similar beliefs?

The Power of Meeting Face to Face

In Kansas City this past weekend I attended MidAmerican 2, or WorldCon.  WorldCon is a Science Fiction and Fantasy fans dream come true.  Thousands of people from around the world attended hundreds of sessions covering television shows, movies, author readings and signings, many sessions on how to write, and much more.   It is a long convention at five days that culminates with the Hugo Awards ceremony (think the Academy Awards for science fiction and fantasy).

I am an aspiring science fiction writer (nothing published yet but I’m working on it!).  This convention was an excellent way to immerse myself with professional and amateur writers and learn.  There is something powerful about hearing people that have already “made it”.  Many of them still fight “Imposter Syndrome” and many have issues with the business of writing.  Writing is a solitary business and many are introverts and selling themselves is often nerve wracking.

Do these issues sound familiar?  They should.  In many ways, Xojo developers are much like writers in that they work in a vacuum with little feedback from others.  I know I personally struggle with Imposter Syndrome despite having done this gig for fifteen years and being ‘successful’ (whatever that means).  And much like writing, the only way to get better at Xojo programming is to do Xojo programming.

It seems a bit anachronistic to fly somewhere to meet with people.  After all, the internet makes this easier, right?  There is something powerful about being face-to-face with another person and being able to provide instant feedback.  We also tend to be much more polite in person than online and that’s a huge plus in my opinion.  I’ve met some wonderful people, in person, that online seem rude at best and sometimes simply belligerent.  The internet might make people more accessible but it seems to removal societal filters too, sadly.

In a month and a half Xojo is holding its annual Xojo Developers Conference (XDC) in Houston, Texas.  At XDC, Xojo developers from around the world will join together for three days of sessions covering practically every development topic you can think of.  And if you have a question that’s not covered you’ll be able to find someone to help you.  Besides the many amateurs and professionals attending you’ll have ample opportunities to talk to the Xojo engineers.

It’s not uncommon for businesses looking for a developer to attend XDC.  It gives them the unique opportunity to talk to many Xojo developers in a short amount of time.  We (BKeeney Software) typically speak to one or two prospective clients at XDC each year.  If you’re a consultant this conference should be on your ‘must attend’ list as it can pay for itself many times over if you land just one project.

Today is the last day to save $100 off the conference registration.  Sign up to learn and be inspired and to make some new friends.  See you in Houston!  http://www.xojo.com/store/#conference

 

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!

Xojo 2016 Release 2.1

Release 2.1 of Xojo 2016 was released yesterday.  This version fixes a few bugs discovered in Release 2 and fixes couple of serious regressions regarding threads.  Sadly, it also introduces a couple of new bugs that might affect your project.

A number of bugs were squashed in iOSTable and for web apps.  If you use either I recommend checking the release notes.

I am unsure of exactly what changed in Release 2 but Threads had issues.  Release 2.1 fixes quite a few (most?) of them.  Resuming a suspended thread now works properly on sleeping or suspended threads.  Blocked threads waiting for locks will stay waiting.  Some applications were hanging when the last non-main thread exited and the main thread had recently been unblocked.

If you are MySQL user the thread issue may have affected you as well.  Certain queries that create detached threads would cause assertions.

The DMG’s distributed by Xojo are now code signed so they will open in Sierra.

A product as big as Xojo will inevitably have bugs not found during the beta process.  I usually joke it takes about thirty seconds after release for the first bug to be found and Release 2.1 is no exception.  These Windows bugs, however, are no joking matter.

If you use RTFData in a Windows application you may experience problems.  As you reload the rtf data back into the control the text sizes get smaller.  Feedback 44852.  This may be related to Feedback 44878 where using SelTextSize and TextSize results in the wrong size being reported.  So if you have 10 point text it will report back as 9.5.

I think it’s always a good idea to peruse the Newest and Recent Activity lists to see what other developers are seeing.  There are a few other minors regressions being reported as well as a couple of Windows only regressions.

Should you upgrade to R2.1?  If you are already using R2 you most definitely should as R2.1 fixes some serious issues..  If you are on an earlier version it’s a bit more murky.  The answer is a definite maybe but only after some doing real testing – especially if you are using threads or MySQL.

What say you Xojo friends?  What do you think of R2 and R2.1?