XDC 2019 Session List

The session list for the 2019 Xojo Developers Conference (XDC) was released today at https://www.xojo.com/xdc/sessions/.  Take a look at this interesting list.

I’ve been attending Xojo developer conferences for twelve plus years (don’t remember what my first XDC was – maybe 2004?).  Each one is unique and the topics are usually interesting but do tend to be repetitive from year to year at times.  The session topics for XDC 2019 seem to be more unique than past years.

Obviously Geoff will do his keynote address and talk about what they’ve done in the past year, what they’re currently working, and what’s coming up (sometime) in the future.  There is a session each for Android, Web 2.0, API 2.0, beyond Linux, everything MS Windows, and more by the Xojo staff.

What’s left is an intriguing list of sessions that will be tough to figure out what I want to attend and which ones I can wait to see recorded (assuming they’re recorded again).  I can’t remember an XDC I’ve looked forward to more.

Carol is doing a session on Database Topics for Programmers and I’m doing one called “Xojo Mistakes We All Regret Later”.  My alternative title is “Thankfully time travel doesn’t exist otherwise my future self will no doubt come back to murder me for these stupid programming mistakes I’ve done.”

If you’ve never been to an XDC I highly recommend it.  You will get to meet some of the best Xojo developers on the planet, talk Xojo non-stop for 3 (or more) days on end, talk to Xojo staff, and have fun.  Of course that last point is mostly because of the first three.  You won’t find a bigger concentration of Xojo developers on the planet!

I hope to see you all in Miami in the first week of May.  What sessions are you excited about?

What Topics Do You Want Covered?

One of the joys of doing a blog for close to eleven years is that I feel like I’ve talked about a lot of topics and people ‘know me’ fairly well.  I always get a thrill when people tell me they’ve read this blog.  That is so cool and I thank you for your valuable time!

As many of you know I do a quick review of every Xojo release.  I often do a blurbs about updates to our own products.  Occasionally I even rant about things (you should see the posts where I never hit the Publish button!).

When I had a column in Xojo Developer magazine this blog was a convenient place to discuss the ideas from the column.  But writing a reoccurring column is tough.  Keeping a blog going for eleven years seems to be even harder.  I’ve been writing fewer and fewer posts and I’d like to change that trend.

At one point I thought about taking a topic in the Xojo Forums and talking about it in-depth  here.  We’ve been busy doing consulting work so I spend far less time on the forums than I used to but it might be an interesting way to generate new posts.

So, my fellow Xojo developers, what topics would you like to see me tackle?  Topics can include my opinions on the future of Xojo, how’s the 3rd party market doing, why did we choose <x> or <y> over <z>, or anything in between.  I’ll let you be in the drivers seat for while.

Some ground rules:

  • If you’re rude to me, my staff, or Xojo staff I’ll just delete the comment, ban you, and move on.
  • Keep it simple – this is a blog and not a magazine.  Though that doesn’t mean I can’t do a multi-part blog post.
  • I reserve judgement to make more rules as I think of them.  😉

So what topics do you have?

Chrono-Optimism

At the XDC Keynote a few weeks ago Geoff Perlman said they’d no longer give target dates for new features.  Instead they’re going to say what’s a ‘priority’ and what’s ‘important’.  Software projects are often big and complex and it’s very hard to estimate the amount of work involved with a new feature.  “Happiness is all about having expectations met,” said Geoff and I think it’s fair to say that Xojo has typically been overly optimistic on when a feature is going to ship (much less when it’s going to be usable).  So instead they’re going to stop predicting when a feature will be released.

If you hear them say it’s ‘Important’, it’s something they’re seriously looking into.  It will be in the product in the not too distant future.  A ‘priority’ means it’s either in active development or will be shortly.  The Rapid Release Model is still in play which means we will still get releases three or four times a year.

In one sense I’m disappointed that they’re not going to give us any timeframe for new features.  I really want to know when Web 2.0 is going to ready for testing as we have a number of projects in development or about ready to start development that it would be really nice to know if it’s a 90 day, 120 day, or longer window.  Android is a nice to have feature, but since I’m not doing much mobile development it’s not that important to us, but I can see how for some it is a huge need.

In another sense I understand why they’re not going to give us target dates any more.  They’ve missed every projected release date that I can think of and I’m going back a lot of years.  It was about a year ago this week, in Berlin, that Geoff said that Android would be out by the end of 2017 when the reality is that we’ll be lucky if we see it by the end of 2018 (that’s just a guess on my part and having having been around a long time).  I would love to be wrong on that guess but it’s a new target that involves a ton of compiler, framework, and IDE work not to mention the need for Interops (a dependency) to work well.

Estimating a project is not a science.  You’re asking software developers to take a wild guess at how long a big feature is going to take.  When you make that initial guess you don’t know that replacing this small piece of code will affect this much larger piece of code over here.  Or cause this other piece to not work right thus forcing you to redo that other piece too.

In some respects creating a new project is considerably easier than replacing code.  In new projects you’re touching everything anyway but subconsciously you’re holding most, if not all, of the work in your mind and you shape it as you go.  Big, existing projects, or OPC (Other Peoples Code) projects, are considerably harder since not only do you have to read the code but also figure out the intent of the code and second guess what the original developer was attempting – not always an easy task.  I’ve never seen the code for the IDE but I’d imagine dozens of people have worked on it over the years with varying degrees of competency and coding styles.  So whatever work you do you have to read, interpret, change, and test to make sure it doesn’t break something somewhere else.  Tack on multiple environments and targets and it’s a herculean task.

I’ve spent the last four years working with my son’s FRC robotics team (team 1982) as the programming mentor.  They have six weeks to design and build a robot to a very demanding set of specifications before they crate it for competition.  These 120 pound robots are relatively complex and I’ve seen it time and time again where the kids have ‘Chrono-Optimism’ in what they believe they can get done in after-school meetings (some with mentors present and some without) and on Saturdays.  Granted, they spend a LOT of time working on the robot, but they’re just kids and most of them have never done anything like this before.  They don’t know what they don’t know and most years they’re scrambling just to get a working robot.

This year, the group of seniors really thought about what they wanted to do.  They knew it would be challenging, but they decided to change their build process and use a more modular hardware design which meant new gear boxes, wheels, framing, etc.  They also decided to build two robots which, for a team that’s never done that before, was …ambitious.  Then they decided that they wanted to go two regional tournaments.  Again, ambitious for a team that’s never done that.  From previous years they also learned something else:  they were attempting to design too much on the robot.  If there were three major tasks that a robot had to accomplish they couldn’t do all three with the resources and experience they had.  They couldn’t change the amount of time to build the robot so they changed the one thing they could – the scope of work – and made the robot simple and sturdy.

The Universe works in mysterious ways and has ways of throwing a monkey wrench into the best of plans.  The last day of build season this year happened to be a day off so the plan was to have a twelve hour work day to finish the robot and test.  Instead, Kansas City had a snow storm which cancelled all school activities.  The robot was not mechanically complete and not functional programming-wise.  The kids were devastated.  But there is a silver lining to their story.

The robot was crated away and couldn’t be worked on for weeks, but the second robot allowed them to work on the programming and driver training.  The modular design allowed them to plan the work they needed to do at the tournament before it started.  The simplicity of the robot meant that the work could actually get done in a short amount of time before taking to the field.

To conclude this story (because I’m bragging now), the team won their first tournament which qualified them for World Championships.  They were the eight seed alliance captain in their second tournament.  At the world championships, they finished 42nd of 67 teams, but were picked as part of the 6th seed alliance.  They won in the quarter finals and ended up getting to the semi-finals where they were defeated by the alliance that went on to be third in the overall tournament (out of 400 teams).  All because they examined their past behavior and decided to change it.  They knew they were bad at estimating and changed their expectations.

I will give credit to Xojo for realizing that, like most of us, they are Chrono-Optimistic in their estimates, and decided to change how they communicate to their customers.  As Geoff said, part of their job is setting expectations and they’ve been really bad at it.  It’s clear that they said ‘estimate’ and we heard it as a ‘promise’ which is partially on us.  So now we have what’s a ‘Priority’ and what’s ‘Important’.  I don’t know if this will help them, or us, in the long run but it will be different and I’m willing to play along for now.

What do you think about this change?  Negative, positive, or neutral about it?

Updates

One of my goals for 2018 is to write more.  So here’s an update on stuff.

We hired a new developer who comes on board in a few weeks.  I’m really excited about his Xojo experience and what he brings to the company.

The planets and stars aligned and I will be going to XDC in Denver next month.  This makes me very happy as XDC is one of my favorite events!  I get to immerse myself in Xojo for a week and see all my friends and meet new ones.  I’m not presenting so that makes life a little easier too.

The week of XDC is going to be hectic as the weekend before as the FRC robotics team my son is on will be attending the World Championships in Houston.  Last weekend they won the Heartland Regional Tournament in Kansas City.  After a pretty disastrous first day where a lot of mechanical issues arose they had a solid last day, got picked by the 3rd seeded alliance, and eventually won the tournament (an alliance is composed of three teams) and advanced, automatically, to the championship tournament in Houston.

If you are geeky and interested in what these kids build, here is the final match where they won the tournament.  https://www.thebluealliance.com/match/2018mokc2_f1m2

The Sound of Silence

Hey folks!  I just wanted to let everyone know that I’m still alive and kicking.  2018 has started off busy and chaotic.

I’ve been on-site with a client for nearly three weeks since the first of the year with a project, that while fun, has been challenging.  It involves big touch screens, credit card terminals, talking to three serial devices over USB, and calling into a Windows DLL.  This is the second major project with this client.  The first one required using Xojo for iOS with an integrated barcode scanner.

My son is a senior in high school (and all that entails) and co-captain of the FIRST robotics team.  I spent a good chunk of my limited free time writing their scouting application not only for desktop (Mac and Win) but for iOS as well (using Xojo of course).  Nothing like doing a big(ish) project for free.  Oh yeah, I’m nominally the programming mentor though I’ve had to step back some (since being out of town so much).

If you want to learn more about FIRST robotics and the challenge for 2018 go look at https://www.firstinspires.org/robotics/frc/game-and-season  I can’t say enough good things about FIRST and what it’s teaching these kids.  I believe the future is bright when I see what these kids accomplish (mostly) by themselves.  For what it’s worth my son received a really nice scholarship to a good university because of his FIRST robotics involvement.

To add into this mix BKeeney Software has been shorthanded for a variety of reasons.  My workload tripled a few weeks ago and we’re actively looking for a new Xojo developer.  As if I needed more things to do.  🙂

Mostly because of senior year commitments only one staff member is going to XDC in Denver.  This saddens me, a lot, since I haven’t missed an XDC since 2004 (I think).  It also means it’s unlikely that we’ll make it to the MBS conference in Munich this Fall.

I’m looking forward to some much needed time off.  I hoping that once things settle down and a new developer (or two) is on board I can get back to writing more.  2018 is going to be a big year for Xojo with so many things coming on board (the new web framework, interops, 64-bit debugging FINALLY working in Windows, and Android to name a few).

Coding Habits To Keep You Alive When Time Travel Is Invented

When you’re writing code we all know it’s a great idea to use method, property, class, and variable names that make sense.  It also makes sense to add in comments on code that isn’t clear.  But do you code in such a way that your future self won’t invent a time machine and come back and slap you in the face?  This is how you should be coding.  You really want your future self to appreciate the work your current self is doing.

One of the current projects I’m working on interfaces with multiple devices via serial communications.  Each one of them uses a different protocol (naturally) and some of the code was written by me and some of it by others.  Before I get into the Other Peoples Code (OPC) portion I’ll talk about my experiences with coming in cold to something called ccTalk.  ccTalk is a low speed communications protocol for use with Coin and Bill Accepters.

Had I ever heard of ccTalk?  Nope.  So the first thing I did was Google it.  I found a few helpful blog posts on it (saved the links) and found a few projects in Java and in C# and downloaded what I could.  I studied their code.  I found specification documents for ccTalk and device documentation and all were immediately added to the source code repository.  Why?  Because as soon as I move on to the next project I’ll forget the details.  If the information isn’t relevant in two weeks I’ll most likely forget about it.

In writing this post, I came to the conclusion that I also need to add any required drivers to the repository as well.  From experience I’ll inevitably need them in the field and if I don’t have them on hand I’ll waste time searching for them again.  Were they sent in an email, on the packing CD, or available from the website?  If it’s in the repository I won’t have to worry about it!

In my source code I document the message numbers I’m sending to the device and putting relevant details on the response and what I’m expecting back.  For ccTalk this might be a simple acknowledgement/busy response and depending on the command some additional data.  How much data am I expecting?  Did I get less?   Did I get more?  Does the checksum match my own calculation?  Do I have a way to create a log of the communication stream and is that log in human readable form or in hex?

This might seem like overkill but I’ve had to go back to my own code years later and relearn what I did.  This has involved finding the manuals again and trust me that’s no fun.  I think it best to assume you will not be the programmer on this project in the future.  Perhaps you get hit by a bus tomorrow and your client has to find a new developer.

The OPC portion of this project is using a different serial port to a different device and has exactly 24 comments in it.  Most of the comments don’t help me.  Commenting ‘If Serial1.open then’ doesn’t help me.  There are a few ‘Return //Exit this Routine’ comments that again would be more helpful if I knew why I have to exit the routine because it’s not immediately obvious from the rest of the code.  There are no comments regarding expected data.  No defensive coding techniques to ensure that if something is missing or garbled it can handle it gracefully instead of just crashing.  Of course there was no documentation for the hardware either so I’m not even entire sure I have the darn thing hooked up properly – all I can do is assume that I did until I get that documentation.  All-in-all I want to jump through the screen and scream at the other developer to a) put in useful comments; b) include the documentation with the source code; and c) include drivers and utilities that a newbie would need!

I try to make sure, in my code, that the developer that looks at my code in six months doesn’t curse me.  I say enough bad things about myself as it is.

What sorts of things do you do to ensure future you doesn’t curse your current self?

Is Xojo the Right Development Tool

Quite often prospective clients, and developers thinking of learning Xojo, ask my opinion of Xojo.  They are about to embark on a journey spending tens of thousands of dollars on a cross-platform tool and they want to know if Xojo is a right for them.  It’s a good question and I’ll share some of what I share with them in no particular order.

Xojo is pronounced “Zo Jo”.  I can’t tell you how many times I’ve heard it pronounced “Ex Oh Jay Oh” or something else.  They just don’t know and I think it spooks a lot of people as it doesn’t exactly roll off the tongue.  Xojo has been around under various names (REALbasic and Real Studio) for twenty years – all with the same company.  At that point it’s easy to name a dozen languages/development environments that were popular twenty years ago that either don’t exist today or been sold so many times that they’re now obscure tools.

This isn’t your fathers BASIC.  Xojo uses the BASIC syntax but this isn’t like the venerable Visual Basic or even older GWBasic or QBasic.  Xojo apps are NOT interpreted at runtime – they compile down into native code for each of the platforms.  The language itself is a modern object-oriented language that happens to use the BASIC syntax.  Xojo is updated three to four times a year and has undergone a lot of upgrades in the past two decades.  It first supported 68000 code, then PowerPC and Fat applications, Carbon, and now finally Cocoa on the Mac side.  They’ve added Windows, Linux, Raspberry Pi (Linux ARM), desktop and console application targets.  In the mobile space they’ve added iOS, and by the end of the year Android.  They’re also in the middle of the transition from 32-bit only applications to 64-bit applications.  For the most part things ‘just work’ and developers don’t experience too many issues (bugs happen but think about how many targets they’re supporting!).

Xojo applications are self-contained.  Take a compiled Xojo application and (with very few exceptions) literally copy the files to another computer and the application will just work.  Even Windows applications don’t need an official installer, however, it is recommended since most Windows users are comfortable and familiar with using them.  Most Mac applications are installed via drag-and-drop from a disk image but an installer can be used on the Mac as well.  This ease-of-installation is huge and it’s rare to have “DLL Hell” issue since all required libraries and resources are bundled together.  This does make the resulting output larger than some other development tools that depend on system libraries but I’ve rarely seen this an issue.

Xojo provides nearly everything you need in one tool (with some caveats).  The Xojo IDE has Code, Form, Menubar, Database, and Report editors (to name some of the big ones) in one tool so you never have to use another tool.  We’ve found the database editor to not be powerful enough so we prefer external database editors.  The built-in reporting tool also isn’t very powerful so we created our own reporting tool (Shorts) which has served us well in our consulting projects.  The nice thing is that all of the built-in tools work seamlessly with each other so the tools that are powerful enough for you ‘just work’ with few hassles.  The editors try really hard to protect your from hurting yourself while other tools are just a big text file that must be in an exact format.

The Xojo community is incredibly helpful.  The Xojo Forums are filled with some of the most helpful people I’ve ever met.  Some of the Xojo engineers respond to questions, but usually the community answers before they get to it.  Many other support forums are rude and condescending to newcomers to their language/tool.  The Xojo forum has even been known to answer questions about other tools.

Xojo is a cross-platform tool and because of this it has some compromises.  Controls are often the lowest- common denominator.  Grids especially aren’t as powerful as some are used to in the Windows world.  This is mainly because complex grids are not common in Linux and Mac environments.  Other controls have similar issues.  Things like automatic spell checking in TextArea’s are platform specific as on the Mac.  At times it is disappointing that there aren’t more control options for Xojo right out of the box (think date and calendar controls) but thankfully there is a third-party market for controls and libraries for Xojo that can often help.  Even though much is provided for you, it’s possible for a developer to use OS API’s using Declares that can significantly modify the appearance and functionality for some applications.

Xojo is a Rapid Application Development (RAD) environment.  Between the all-in-one IDE and the language creating applications in Xojo is fast.  This means that an initial investment can get your app developed faster and cheaper than many other languages.  Obviously some of this depends on the developers doing the work but it can make a huge difference.  We’ve always told clients that if they’re not happy with Xojo performance after the initial release they can use our code as the proof of concept to the developer in whatever language they choose.  There have only been a handful of clients that have ever switched languages after release and that’s usually been switching from desktop apps to web app.

The cost of Xojo isn’t very high compared to some tools.  For $699 per year per developer you can create web, console, and desktop apps for Mac, Windows, Linux, and Linux ARM plus iOS apps.  That’s all in the same environment and same language and with the exception of iOS applications (which requires a Mac) you can use Mac, Windows, or Linux to create everything.  Many developers use third party controls and libraries and even those are relatively inexpensive.  Plus, there are no royalty fees for your Xojo made applications.  All-in-All it can be a relatively inexpensive tool.

What considerations have I missed?

MBS Xojo Developer Conference 2017

Xojo isn’t having their annual conference as they’ve decided to switch back to spring events. Since they last did one in October of 2016 they are not doing one in 2017. It makes me sad that I won’t see my friends until 2018. Thankfully, Monkeybread Software is holding a Xojo conference in Berlin on May 4th and May 5th, 2017 to tide me over..

This two day conference, held in the heart of Berlin, Germany, will boast the biggest Xojo get together of the year. Several people from Xojo Inc will be attending and Geoff Perlman will deliver the keynote address where I’m sure we’ll hear about many of the upcoming features of Xojo.

We will be there too. Carol will be giving a Database Design Mistakes session that she was hoping to give at XDC 2016 but had to cancel due to a grandson showing up. I will be giving a Reporting in Xojo talk showing off Shorts and some of the new features we’ll have added to the product by then.

I can’t emphasize enough how much I love these conferences. It’s where we can learn some new things about Xojo, and, more importantly, make friendships that can last a lifetime. I can tell you, from experience, that meeting the people you’ve ‘talked’ to on the forums is a magical experience.

Carol and I have never been to Berlin so we will do some sightseeing. We haven’t set our flights yet but we’ll be happy to try and coordinate with our Xojo friends. Let us know what sorts of things you’re doing and dates.

See you in Berlin, May 4th and 5th. To register for the conference, please go to http://www.monkeybreadsoftware.de/xojo/events/register.shtml

May your 2017 be better than 2016.

The Xojo Community is Awesome

Have I told you how much I love the Xojo community?  I’ve been part of it for fifteen years and I’ve met hundreds of Xojo developers at developers conferences and probably exchanged emails with thousands more.  I am amazed at how much this community helps each other and I wish there was a way to promote that as a key feature of the product.  It’s a big deal.  Really!

If you’re just starting out using Xojo know that there are a bunch of people, myself included, that are willing to help out, if we can, on your journey.  Programming is hard.  Well, I don’t think it’s hard because I’ve been doing it for so long, but it is complex at times and that makes it hard.  Just ask your question in the Xojo forums and you’ll almost always get an answer within hours.

Even Xojo pros, such as myself, have need of help.  Xojo covers Mac, Windows, Linux desktop, console, and web apps.  It does iOS apps for iPhone and iPad.  It now does Raspberry Pi for heavens sake!  It works with dozens of different databases.  There is simply no way any one person is going to know everything there is to know about Xojo.  It just can’t happen.  So yes, I go to the forums, all the time, and ask for help.

Just the other day I asked for some help with WooCommerce.  Not Xojo related, really, but certainly related to a project we’re working on for a client.  Within a few hours I had half a dozen developers private message me saying they might be able to help.  Subsequent contact narrowed that list down a bit but the point is that I have probably shaved off several days worth of work simply by asking for advice.

I am biased towards Xojo, naturally, as it’s been my primary development language for fifteen years.  I think I’d be hard pressed to find such a friendly community.  I call many on the forums my friends even though I’ve never physically met them.  The few that I’ve met in person have lived up to their forum reputations and are really friends for life.

So maybe this is my belated Thanksgiving post.  I am thankful that so many years ago I jumped both feet first into the tool.  I asked questions – many of the silly and redundant.  I became more proficient and then made another jump to start blogging about it, making products for other developers, and training the next generation of developers.

So if you are in need of a cross-platform development tool I highly recommend Xojo.  It ain’t perfect but no development tool is.  If you jump in I think you’ll love the community.  I know I do.

What say you fellow Xojo developers?

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!