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!

Estimating is an Art, Not a Science

A question that comes up quite a bit is how to do proper estimating.  It’s not an easy thing to quantify as much of involves gut feeling at times.  It’s why I feel that estimating is an art, not a science.  The hard thing about estimating is that it takes experience to know if you’re doing it right or not.

My first bit of advice is start using a tool to track your time.  If you can’t do it by specific task, as least do it by overall project.  Once the project is done you can then see if your estimate matches reality.  It won’t at first but that’s why you track your time so you can make adjustments on the next project.  After looking at several projects I came up with the idea of the times three for estimates.

When you look at part of a project, say a form, your estimate tends to be something like this:  if I know everything up front and there are no major surprises this is what is how many hours it will take to complete the programming and testing of this form.  However, we rarely know what those major surprises are up front so at best this is my guess and multiply it times three to come up with a more realistic estimate.

After a while I started to realize that some forms just aren’t going to take that long.  An About Window just won’t take more than fifteen, twenty minutes – ever – so why do the multiplier on that?  It makes no sense.

What makes one form harder to develop and test than an other?  Complexity.  A simple List form and an Add/Edit form might take an hour each (if that) to complete but busier versions of both might take three to four hours each.

What brings in the complexity?  Well, that depends on a number of factors.  Number of controls on the forms is a good start.  The business logic is another.  If how things work depend on what the user is doing in the controls you can rest assured that programming and testing of it is going to take longer than you expect.

Another part of complexity is the number of unknowns.  If you have to do a complex calculation that involves a bunch of math (especially if you’ve never done said math before) it should up the complexity.  Doing some programming concept in Xojo that you’ve never done before should up the complexity as well.  In both cases you should expect some research time, maybe even time to do a small example project, and a restart or two since you’re learning as you go.

In my initial guess I still do the ‘if I know everything up front and there are no surprises’ estimate.  And then my multiplier is my feeling of the complexity of that part of the project.  The complexity factor is now my multiplier.  So an About Window has a complexity of one.  A simple list form has a complexity of one and half, but a form with several page panels or containers that do different things based on user input might be a complexity factor of three or four (or more).

I tend to break projects down to several parts.  The first is overall project design.  There are certain number of hours just to set up the project and create the classes I need.  There’s usually some database design and implementation.  Do I need to make any special classes or subclasses for functionality that I already know about?

When it comes to the UI I often take the database design as the guide.  Each database table is (probably) going to need a List form and a way to edit it.  Figure that a list table is only going to need a few of the fields for listing but the Add/Edit form is going to use all of them.  Are they all text fields or is it a mix of lookup fields with foreign keys?  Each of these adds to the complexity of the forms in question.

Coming up with an estimate is sometimes an art.  It takes experience (and failing a few times) to get the hang of it which is why you need to track your time.  Using the complexity as a multiplier might be a good way for you to start getting more accurate estimates.

Let me know if you do something different for estimating.  How do you track your time?

Happy coding!

Introducing ARGen 2.0

ARGen More Powerful Than Ever!

BKeeney Software is pleased to announce the release of version 2 of ARGen, our ActiveRecord generator utility.  The new release includes many enhancements.  Some of the highlights are:

  • Can now create User Interface elements.
  • Create entire projects for Desktop and Web projects with the proper database connections for each type.
  • Choose between standard database error reporting and a more robust version that BKeeney Software provides.
  • Can now create foreign key elements automatically.
  • Ability to create relationships without having to put them into foreign keys in the database.
  • Works with more databases.
  • Added ability to use database views.
  • Completely redesigned application!

Purchase Mac Version
Purchase Windows Version

Note:  Without the paid upgrade, you can still access the free version with nag screen.  You can use the free version with no time limitation.  The free version is limited to two tables at a time and will not create any User Interface elements.

If you are an existing user and did not receive an email containing an upgrade coupon code please contact us at support@bkeeney.com.

If you want to see ARGen 2.0 in action, please visit our new video at http://www.bkeeney.com/allproducts/argen/argen-2-0/

Product Home Page:  http://www.bkeeney.com/allproducts/argen/

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?

XojoTalk 027 – Database Goddess

We at BKeeney Software are blessed in so many ways.  All of our employees bring a unique and interesting mix of talents and experiences.  It’s not just about one person and we often bounce ideas off each other to get the best possible result.

In the latest XojoTalk, Paul interviews our CEO, Carol Keeney, and how she uses Xojo and gets her thoughts on databases.    Carol has a ton of project management experience that makes running BKeeney Software easy since we often have a half dozen projects going at a time.

She has a lot of database experience too.  That has given her the “Database Goddess” nickname.  Again, that experience is so helpful for the programmers because, really, you don’t want your programmers designing the database.  We tend to do things the easy way which might not be the right way.

I thought it was an excellent interview.  You can find the XojoTalk at http://blog.xojo.com/2016/07/26/xojotalk-027-database-goddess/