We’ve Acquired the Fireye PDF Classes

Lenexa, Kansas, USA (December 27, 2013) — BKeeney Software Inc. has acquired the Fireye PDF classes for Xojo and Real Studio.

We are very excited to bring the FireEye PDF classes to BKeeney Software.  The PDF classes represent years of quality work and fill a need in the Xojo developer community in regards to the creation of PDF documents.  We will spend some time modernizing the classes to conform with the new requirements for Cocoa and rerelease for sale once we have completed the work.  We also plan on using these PDF classes to enhance our Xojo related developer products, particularly Formatted Text Control and BKeeney Shorts.

Asher Dunn, the original developer of the Fireye PDF classes said, “I am happy that my work was highly valued by the community.  I think Bob and his staff at BKeeney Software will do a great job maintaining and enhancing the PDF classes for years to come.”

All existing customers will receive version 2 for free.  An email will be sent to all registered users with instructions on how to upgrade to the BKeeney version.  Once a new version is released existing customers will be able to upgrade at a discounted price.  At this point, pricing has not been determined.

The new home for the FireEye PDF Classes is at: http://www.bkeeney.com/allproducts/pdf-classes/

For more information visit http://www.bkeeney.com or send email to support@bkeeney.com

Visual Basic 6 on Windows 8.1

Not a month goes by where we don’t get a prospective client asking about the possibility of converting their old (but working) VB6 application to Xojo.  They always tell me that their project is working great in Windows 7 and Windows 8.  Then comes the but.  But, they feel that they’re living on borrowed time and it’s only a question on WHEN Microsoft pulls the plug on compatibility not a matter of IF.

Let’s face it.  VB6 Service Pack 6 was released in 1998 and official support ended in 2008.  I think it’s a testament to its power and popularity that developers are still using it five years after support was ended.  It may also be an indictment of how many felt abandoned by Microsoft in the move to .NET.

So the questions I end up answering for many are these:

Can we convert their VB6 application to Xojo?

The answer is generally yes.  I’ve come across few projects that can’t (or shouldn’t) be done in Xojo.  There are some caveats, though, because Xojo is a cross-platform programming tool.

If you’re looking for fancy grids that you rely upon in Windows you’ll be disappointed.  As a cross-platform tool some controls are the least common denominator simply because Mac OS X doesn’t support or encourage the same types of grid components.  Apple encourages simplicity which forces different design considerations.  Linux has differences too that force compromises.

Reporting isn’t nearly as robust in Xojo as in VB6 either.  While it’s true that Xojo has built-in reporting components most developers I know find it too weak for anything beyond simple reports.  There are a number of third party reporting tools (including BKeeney Shorts, our particular solution) but none of them are as easy, mature, and integrated as Crystal Reports.

Can we easily convert their project to Xojo?

This answer is a definite no.  I don’t care what anyone says, running your VB6 project through any of the available converters will not result in good Xojo code.  From experience, you’ll end up spending more time fixing the things that it didn’t convert properly than if you had just started from scratch.  In our opinion it’s much easier to rewrite the application in Xojo rather than convert it.

That’s not saying you can’t reuse major portions of the VB6 code in Xojo but, as a developer, I want to analyze it and choose what I want to port rather than having it bring over everything.  There are a couple of reasons for this.

  • This first is that Xojo is really good at subclassing controls.  VB6 was horrible at it and many developers have extensive classes and modules to work around this fact.  Little to none of the code that’s in those classes and modules is necessary in Xojo.
  • The second is that Xojo is pretty good at threading.  Much of the app.doevents code you’ve had to add in your VB6 project because of tight loops to avoid the UI from freezing you’ll do away with and put into a thread in Xojo.  There are some caveats with threads in Xojo but generally it’s a better way to deal with time consuming operations that might otherwise freeze the user interface.
  • The third is that the VB6 best way to do something may not be the best way to do it in Xojo.  A number of years ago we converted a simulation application from VB6 to Xojo (then called Real Studio).  The project used an insane number of control arrays  with various levels of overlapping controls.  The logic was very convoluted.  Rather than try to duplicate the exact same functionality in the same way in Xojo, we were able to greatly simplify the logic and put everything in simple classes.  The ‘unit’ in the simulation handled all of its own actions and generated events for the UI to respond to.  The UI simply passed the user action into the appropriate class instance.  Everything was encapsulated in the classes and in the long run they could have used the same UI front end for any number of different simulations.  It wasn’t the VB6 way and it took some convincing that it was a better Xojo way.  In the end they were happy with the results with a solution that ran on Windows and Macintosh (and Linux if they had requested it).

Windows 8.1

So why bring all this up?  For some reason a lot of people have hit a previous blog while searching about Windows 8 and VB6 during the past month.  I did some checking and while Microsoft has said Windows 8 would still have VB6 compatibility built-in, some developers have had issues in Windows 8.1  The workarounds seem to be fairly simple, but I think most people still using VB6 are wondering if this will be the last version of Windows that will still have that.  VB6 does work in Windows 8.1 but will this be the last version?  Only Microsoft can answer that but given their stated intentions of doing annual updates like Apple it seems likely at some point they’ll jettison some backwards compatibility.

Also a consideration for many of them is Mac compatibility and to a lesser extent Linux.  Ten years ago the Mac version was an afterthought for many of our clients.  Now, not so much, in that they need a Mac version to satisfy their customers or personnel.  The past couple of desktop projects have actually been Mac first and then Windows.  How times change.

Finding Xojo Developers

I’ll put a plug in for ourselves https://www.bkeeney.com/bkeeneyconsulting/.  We’ve converted dozens of VB6 projects to Xojo.  Contact us if you’d like a quote.  You can even put your application through our VB6 Analyzer (https://www.bkeeney.com/vb2rbconversion/) so we can get some metrics about what all is in your VB6 project.  The beauty of the analyzer is that we never have to see your project to give you a rough estimate of the cost to convert.

You can also request the Xojo Developers Network to get in touch with you.  Simply fill out the request at http://xojo.com/support/consultants.php and Xojo developers will contact you if they’re interested in your project.

Support for VB6 ended a long time ago but based on the number of contacts I get it is certainly not dead yet.

When a License Isn’t a Valid License

I will preface this post with the usual disclaimers:  Not everyone will have this issue nor will it even apply to a vast majority of Xojo developers.  Take it with a grain of salt and if you disagree, that is your prerogative.

This week we had a little lull in the development of one of our bigger consulting projects.  It’s a Web Edition project that has 300+ web pages, 250+ WebContainers, 97,000 lines of code and compiles down to about 43 MB of code.  It’s a monster and we’ve been maintaining it in Real Studio 2012 R21.  This week we decided to upgrade it to Xojo 2013 Release 3.

We have 3 full-time developers and a DBA/QA person who is familiar enough with Xojo programming to fix some of the simple stuff.  We already had 2 Xojo pro licenses and bought a 3rd for our other full time programmer that had been working on this project.  The 4th team member won’t ever compile but will need to be able to save in the version control format that we use on all projects into Subversion.

Being a responsible and conscientious user I read the Xojo End User License Agreement (EULA).  Here is what it says:

• A Xojo License Key is required to save a project in Text or XML formats.

With that fairly plain English we bought a desktop license because it would be the most likely be relevant in the future for our 4th team member (since most of our work is desktop apps).  When our team member applied the license and worked on the Web Edition project every time she tried to save the IDE kept doing a Save As in binary format.  Obviously something was wrong with the licensing.

After checking with Xojo Inc. we discovered that the licensing text was incorrect, or at best misleading.  You need the target specific license key to save a project in Text or XML formats.   In other words, to save in Text or XML for a Web Edition project you need a Web Edition license, to do the same thing for a Desktop project you need a a Desktop license and so on.

For us it was not a huge deal.  We needed it so we bought another Pro license and Xojo Support quickly lupgraded our license.  I understand the reasoning behind it but the fact that I looked it up in the EULA just to make sure says the EULA language needs some additional clarification.  I was pretty mad at the time because it wasted my time and a team members time for a half day while we got it all straightened out.

So be aware of those restrictions when you buy Xojo for your team.

What Pro Developers Need Out of Xojo

I’ve been a REALbasic/Real Studio/Xojo developer since REALbasic version 3.5.  I’ve been through a lot of versions, UI changes, and have made a fairly successful business using the product.  I am a huge supporter of the product and count a lot of the current and former Xojo Inc employees as friends.  I am also a critic in that I always want a better product than what I have right now.  This post is a laundry list of things that we find lacking Xojo.

The first thing that we want is stability in the product.  Xojo 2013 Release 3 is better than the 2 previous releases but we can still get it to create exceptions fairly reliably (yes, we’ve submitted Feedback reports).   Granted, Xojo has not been out for very long but we also had a year long wait from when it was promised to when it was released and we expected more.  For example, Xojo still hasn’t fixed bugs reported years ago in Real Studio.  Autocomplete still doesn’t work properly with shared methods and properties and namespace objects and there are a few other instances where autocomplete just doesn’t work.

The second thing we want from the product are power features (i.e. things that make my life easier).  The debugger, while powerful, is still essentially the same debugger it was when I started using REALbasic many years ago.  Many people want debugger watchpoints, and a better way to view application data while debugging (tooltip variable values are a common request).  Plugin management is a royal pain for developers like us that have projects spanning a decade.  We’d love to have a complete source code view of an object without having to click on each property, method, event, constant, etc.  In my VB6 days I was a huge fan of MZTools which was an add-in for the VB IDE that provided additional functionality that we’d love to have in Xojo.  In other words, we’d love to have the ability to have IDE add-ons.  We’d also like to have the ability to compile applications via the command line and the ability to create libraries and plugins via Xojo itself.

The third thing we need is better RAD tools.  For a tool that claims to be a RAD tool it has a surprising lack of RAD options.  Despite many years of users asking for it there are still no good options for a data grid control.  Sure, many things can be done with the listbox but it’s not quite what users are asking for (think embedded native controls).  The fact that Xojo does not ship with a basic date, time, or calendar control for many is the kiss of death for using the product.  Make them so basic (like Microsoft did) that any power feature has to be satisfied by a 3rd party developer (like Einhugur).

The last thing we need is better database support.  We see no reason why the recordset can’t have an AddNew function.  Why can’t the DatabaseRecord code be merged into the Recordset?  Currently, the classes are close enough in functionality to be easy to figure out but just different enough to be highly annoying (for example, field vs column terminology).  We’d also love to have a Batch Update function with the recordset and the ability to have Disconnected Recordsets.  Both of these features lead to some interesting and powerful database applications.  Another thing that we find lacking is that there are no built-in options to help the user with database operations as there’s zero error checking on table and field names (other than checking the database error property).

These are things that are on our short list and things that we’ve been talking with other developers since about 2008 when we helped found  the Association of REALbasic Professionals (ARBP).  This list does not include 64 bit support, LLVM, or SSL for Web Edition applications because those are already scheduled to be implemented.

Let me be clear, Xojo works for us – we just want it to be better.  We spend an awful lot of money on licenses and going to the developer conferences because this is what we do for a living.  Doing Xojo development pays the salary for all of our employees.  We depend on the tool on a daily basis and even though we think it’s already pretty good, we simply want it to be better.

So what is on your list of things you really want/need in Xojo?

Xojo Licensing Changes

Xojo, Inc. confirmed last week that the licensing for Xojo is changing.  The IDE now costs nothing.  Free.  Zip.  Zilch.  Nada.  Now we all know that it’s awful hard to stay in business by not charging any money, so the catch is that to make a build you need a license.  If you’re building for desktops (Mac, Windows, Linux) you need a desktop license.  Building for Web you’ll need the web license.  Building a console app you’ll need a console license.  The only oddity in the mix is if you’re using database servers which requires an additional license SQLite is included in all licenses).

Now that the IDE is free all users can take advantage of all Xojo features.  Item encryption, server sockets, SSL support, database encryption, remote debugging, container controls, code profiling, IDE scripting and build automation are the big items that were not available to all users depending on what license they had for Real Studio.  This has some advantages for training and getting people to actually use those features.  Everyone has the same set of features and all are available on all supported platforms.

Announced Pricing is this:

Console Licenses $100 ($50 renewal)

Desktop $300 ($150 renewal)

DB Servers $300 ($150 renewal)

Web $400 ($200 renewal)

So what does this mean for those with existing Real Studio licenses?  Real Studio personal licenses automatically get a Xojo Desktop license.  Real Studio Professional get Desktop, Database, and Console licenses for Xojo.  Real Studio Web licenses get converted to Xojo Web and Database.

Real Studio Enterprise licenses now get what’s called Xojo Pro.  Xojo Pro gives you all licenses.  You get desktop, console, web, and database licenses.  It comes with Priority Support which means that Xojo Inc. will handle all Priority Support issues first and then everything else.  Pro licenses also work on three machines (in contrast to the two for other licenses).

Another feature for Xojo Pro is that it gives you guaranteed access to the beta’s.  The Real Studio beta list really had no restrictions.  You signed up and you got access.  They didn’t say this but I suspect this is in response to the many people on the beta list that never reported anything but generated a ton of useless chatter.  This will definitely cut down on that problem.

Some people have taken offense to this.  They are not going to be Xojo Pro users so they feel that they’ll be cut out of the beta list.  The wording in the keynote was very specific.  Xojo Pro gives you ‘guaranteed’ access to the beta list.  That does not mean that you can’t join the beta it just means that it’s up to their discretion.  Those that have contributed in the past will most likely be welcome.  Those that have not are probably out of luck.

Another advantage of getting a Xojo Pro license is access to a Xojo Pro Only forum.  They figure it will most likely be the full-time developers (such as BKeeney Software) that use it.  Honestly, I have a problem with this even though I will most likely have several Pro licenses.  I have been a top 10 poster in the Real Studio forums for many years and I just don’t see how this helps me, or the community.  It seems like it will introduce some stratification into the community where there is none now.  I can’t imagine having an issue that I wouldn’t ask the entire community about.  I could go on about this but it seems to me that it’s a marketing bullet-point to make Pro look better.  I think it’s a bad idea and probably won’t use it.

The final ‘advantage’ of the Pro license is that Feedback cases now get a 3x multiplier. Real Studio licenses are a little different.  I believe Personal licenses get no multiplier, Pro/Web gets 3x and I thought that Enterprise licenses now get a 5x multiplier.  So in this scenario everyone else gets no multiplier but Pro users are the only ones to get it.

The Feedback multiplier isn’t a huge change but it definitely favors the Pro license.  I like this but I have my doubts that it will change anything significant.  As a pro user I have needs that are not being met by Real Studio (and now Xojo) despite many years of blogging and generating feedback reports.  Instead they have consistently gone for marketing bullet-point solutions and solutions that make it easier to sell to beginner and hobbyist developers.

Don’t get me wrong.  The free licensing has the potential to introduce Xojo to a lot of people that would consider themselves hobbyist or part-time developers.  That’s a good thing.  But it’s the folks like me (the Pro’s) that spend serious cash.  I want and need features that a) make my development life easier or b) help make me money (usually in completing things faster).  Not a whole lot of those types of features have been introduced in the past five years.

What do you think about the new licensing and the Xojo Pro features?

eSellerate Issues with Real Studio

Even though I’m a consultant, I still believe in the axiom that “Time equals money”. So while I don’t have a problem creating my own solution, if there are existing solutions out there I’ll use them. This is why I have the full suite of Einhugur and MonkeyBread Software plugins (including Chart Directory and DynaPDF) to name a few. I acquired the Formatted Text Control and Simple Help Editor when they became available because they scratch an itch that we have as Real Studio developers and they save me time in one form or another.

One item that seems to come up with regularity in our products and for our clients is licensing and registration. Add in web store functionality and it becomes a can of worms. Not that you can’t do it yourself, but most developers (and clients) are in the business of selling their products, not coming up with solutions for web stores, licensing and registration.

For several years we used a web only solution called phpAudit. It worked okay, but the the software wasn’t designed with desktop applications in mind. We made it work but it wasn’t ideal. For one, it required a web connection to check registration and the only way to purchase was through the web and the only payment option was PayPal. Again, we weren’t unhappy with that solution. Heck, several of our clients still use it and are happy with it.

We made the switch to eSellerate for our own products a few years back. It’s a decent solution with a web store solution AND an integrated store so users never have to leave your app to purchase the software. It can accept payment from credit cards in addition to PayPal and several other forms of payment.

It has an offline mode where you can still activate the software even if the end user machine doesn’t have an active internet connection. This came in handy when someone purchased our software while on a ship traveling the South Pacific.

I have had many conversations over the years with people who despise third party solutions like eSellerate because if their service gets broken/hacked then their apps get broken too. This has happened at least once in eSellerate’s history but not recently. While I can’t disagree with their reasoning I find it amusing that they’ve spent an inordinate amount of time trying to come up with their own unique licensing/registration solution. Remember my opening statement about time equals money?

eSellerate requires a plugin for Real Studio and it works on Macintosh and Windows. Until recently there have been zero issues using this plugin. The switch to Cocoa took eSellerate a while to come up with a solution (that you have to ask Support to get, by the way) but that’s okay since Real Software’s Cocoa solution has been in beta for a while.

In Real Studio 2012 Release 1 the plugin API was changed slightly to make applications a bit safer. Until then it was possible for a plugin developer to do some unsafe things and this might have caused instability and hard crash issues. Many plugins worked just fine in this transition but the eSellerate plugin was one of the casualties. Ironically, the Macintosh (Carbon and Cocoa) version works fine but the Windows side of things crashes the application when certain plugin calls are made.

I know there are others who have reported the issue as well, but I first reported it in October of 2012. Since then I have received several updates from them with this being the latest:

I’m afraid I have some bad news.  As you know, we’ve lately had an engineer working on a daily basis to try and resolve the issue with Windows apps crashing if compiled with REALStudio 2012.  The folks at Real Software had been awaiting the results of our engineer’s investigation to try and troubleshoot further.

Unfortunately, as of last week, our engineer who had been working diligently on this case is no longer available.  I’ve taken this matter up with my manager, the director of eSellerate, and she has escalated it above her as well, trying to get some dedicated engineering resources to get this taken care of.  However, it doesn’t appear that we’re going to be able to continue the investigation in the immediate future.  We’re not sure when we may be able to resolve this.

We do understand how important this is for your continued integration with eSellerate, and we sincerely apologize for the trouble.  I’m very sorry I don’t have better news for you.  If it might be possible for you to integrate with a 2011 version of REALStudio, that might be your best bet for the time being.

This is not good news and their proposed solution is less than ideal. As the 2013 release nears completion this issue will continue to grow. Eventually Cocoa will be the defacto build for Macintosh and there will be features in Real Studio that can NOT be reverted to 2012 R2.1.

Because we’ve developed plugins for Real Studio I offered our services to eSellerate. I also contacted Geoff Perlman, CEO of Real Software, to see if they could help. RS has also offered to fix the plugin for eSellerate. So far neither RS or I have received any additional feedback.

So now I’m stuck between a rock and hard place. I can assume that eSellerate will fix their plugin but I’m currently advising one client NOT to do so. What’s the point of converting their entire user base over to eSellerate if they’re going to abandon the Real Studio market. Now, I’m not suggesting that they are, but it’s been four months and they don’t appear to be any closer to fixing this bug then they were in October of 2012.

If I go with my motto that time equals money what are the other solutions out there that handle payment, licensing, and registration in one package with Real Studio applications? I know of Kagi and FastSpring that are being used by some Real Studio developers. What are you using?  I’ll look at just about anything.

Busy Updating Products

I apologize.  Blog posts have been slow lately.  Acquiring products from another company is an interesting process and figuring out the StyledHTMLField and Simple Help Editor was no exception.  First, you have to get in the mind of the original developer and figure out what they were trying to do and then determine if you wish to change the code and then test, test, test.  I can say I am very thankful for source code control because I’ve broken a few (too many) things and had to revert to older code!

One of the things we’re doing with Simple Help Editor is changing the licensing scheme to fit most of BKeeney Software’s other commercial products.  That led me down the proverbial rabbit hole because we discovered that the eSellerate plugin works fine in Carbon and Cocoa (after contacting tech support to get the Cocoa update) but fails in Windows (go figure).  Of course this only happens in Real Studio 2012 R1 and higher so I’m sure it’s simply a plugin compatibility issue and hopefully we can get an update soon (because we’re waiting to release!)

The other thing we decided to do was move to our standard preferences system.  The reasoning was twofold:  First, it now works just like every other of our products so my and my team won’t have to think about what the preferences system does because we know it (and use it everywhere).  The second reason, which was kind of by accident but fortuitous anyway, was that we got to touch code everywhere.  Just by replacing the preferences we go to see a LOT of code we wouldn’t have normally touched.

Just by doing these two seemingly minor items I now have a whole laundry list of items I want to change in Simple Help Editor.  Some of it is personal preference and some of it is features I want for my own products.  It’s also a strong possibility that we’ll integrate the Formatted Text Control into Simple Help Editor to not have to rely upon the RTF to HTML conversion routines and the built-in TextArea control which doesn’t allow any graphics to be shown.  This should make the Simple Help Editor text editors to be a bit more intuitive.  If you are are user of Simple Help Editor and have a feature request then please let me know.  I

Speaking of the Formatted Text Control we’re also working on it too and getting it ready for new features in version 3.  Among the planned features are Retina display support, HTML Export, Hyperlink support, and adding a number of simpler examples that developers can (hopefully) use out of the box without any plugins.

Sometimes I am amazed at how long some things seem to take.  I guess I shouldn’t at this point as I come up with estimates for clients all the time.  When it’s my own stuff it seems to take FOREVER to get done.

Anyway, that’s the current update.  Thanks for you patronage and continued support!

BKeeney Software Acquires Developer Products From The PandaWare Company

Lenexa, Kansas, USA (October 16, 2012) — BKeeney Software Inc. has announced that it has acquired two Real Studio developer products from The PandaWare Company including…

- Simple Help Editor: a cross-platform help authoring used by developers of all stripes
- PW Style HTML Field: a set of Real Studio classes for creating HTML email messages, used in several applications built with Real Studio

We are very excited to bring these products to BKeeney Software. These products represent years of work in areas that are fairly unique in the Real Studio world. These products are valued assets for the Real Studio community and we will continue to enhance these products. Dennis Birch, from The PandaWare Company said, “I am happy BKeeney Software has chosen to acquire these products.  They are well known in the Real Studio community and I’m sure they can continue to enhance these products and make them even better in the future.”

The new home for these products can be found at the following URL’s:

http://www.bkeeney.com/products/simple-help-editor
http://www.bkeeney.com/products/styled-html-field

For more information visit http://www.bkeeney.com or send email to info@bkeeney.com
.

Protect Your Most Valuable Asset

If you own a house, most likely you have insurance in the event of a disaster.  You might even have a safe box somewhere in your house to protect your valuable objects and you might even have a safety deposit box at the local bank to protect your most valuable items.  Why do many developers not use a Source Code and Version Control System for their source code? After all, your source code is the most important business asset you have and until you hand it over to the client it’s yours to protect. Even if it’s your personal code, why not protect it?

Real Studio doesn’t make this easy, in my opinion, with their binary (rbp) file format. The binary format is very fast and very portable single file in comparison to the version control (vcp) file format that creates a text file for each object in your project. The binary format, in my opinion, gives users a false sense of security. Bugs happen and hard drives fail.

Version control systems can not read the binary format and track code changes. They check in a binary file as a whole unit regardless of how many Real Studio objects are in it. So it doesn’t matter if the code in Window1 has been changed or not because all that code gets sucked into the server.

In my ideal world I’d love to have a format that works with the source code systems but is also as easy to package up and move around as the binary format. Apple’s bundle format would be ideal but as far as I know there is nothing built-in to Microsoft or Linux distro’s that does this automagically.

Subversion servers (and their like) tracks source code changes down to the line of code. Change the capitalization on an RB keyword in Window1.open event? It’s a change that’s noted in the object file (window1) and even to the line of code. When you check in the changes to the server it knows who did it and assigns a version to it.

We’ve used a variety of systems over the years. Many years ago we used Visual Source Safe, CVS, and we currently use Subversion. There are a lot of developers that are using GitHub with a lot of success. Regardless of what you use I believe you should be using some form of source code and version control system. It’s the smart thing to do as it’s the only safe way to store your source code.

Have you every lost code because you failed to keep a copy of it, deleted it accidentally, your hard drive failed, or your computer was stolen? There’s nothing worse than knowing you had some source code that you can no longer find and use. That’s an asset that you’ve now lost – forever.

I know I’m not the only developer that’s worked on a piece of code for a few hours only to realize that it’s crap and I have to revert to the pristine version (because it’s impossible to undo all the changes you’ve just made). You can do this with the binary format if you are really, really good (or paranoid) about making copies of your project but that’s a lot of work. The source code and version control systems are designed for this!

These systems let me save incremental changes, create snapshot copies of the entire project and even compare files across versions so that I can see exactly what’s changed. With multiple developers on a project this is nice to see who changed what and when. When the developer commits a change we all add a note on what we were working on. This is important for us on large projects.

These systems just aren’t for teams, though. Tracking your individual changes is important because sometimes you’ll just be wrong when you change some code and you’ll have to check out an earlier version. These features are very important on projects and teams of any type of size.

Subversion and GitHub can be done on a local computer (not necessarily a server) and from what I know they are not exceptionally hard to install and setup. We chose a commercial host for a variety of reasons. First, I don’t want to purchase and maintain a server with all of the security nightmares that can come with it – the commercial host keeps up with security issues and we all connect via SSL so we know our code is as safe as our passwords allow.

While we do backups of our important files the commercial host is an offsite backup for us.  They do offsite backups of their servers. I know that if my office were to burn down, get hit by a tornado or flood, I would be down as long as it would for me to get a new computer from the nearest Apple retailer and hook up to our Subversion server. That’s a huge peace of mind for me.

We use a Subversion client that is cross-platform simply to make it easier for training purposes. We use SmartSVN which has versions on Mac OS X, Windows, and Linux. While we spend 99% of our time developing our Real Studio applications on the Mac we occasionally need to compile or debug natively in Windows or Linux. The standard UI across platforms with SmartSVN makes this easy and we do not have to copy files across development environments.

We also use a bug tracking system. Unfortunately our version control and bug tracking aren’t tied together but there are plenty of commercial hosts that have both. We tend to commit based on bug reports or, at a minimum, clusters of bug reports. Have a single bug in a class? That’s one commit with the bug ID noted in the commit report. Have a couple in a set of related classes? That’s one commit with all the bug ID’s noted in the commit. At a glance I can tell what bugs were fixed with each commit.

So regardless of the reasons that appeal to you the most, you should be using some form of source and version control system. Protecting your source code assets should be a part of your practice. If you aren’t protecting your most valuable assets your playing with fire. A disaster on your development computer could put you out of business. Protect your source code and yourself.

What about you?  What do you do to protect your source code?

Has Microsoft Already Lost?

I say this with no malice when I say that Real Studio is a fairly small player (development tools-wise) when compared to Microsoft and Apple.  Those two behemoths have much bigger pockets and drive the development environments on their respective platforms.  It’s also fair to say that each has little interest in supporting the other platform.

Real Studio is a good cross-platform development environment that lets a skilled developer create nice Macintosh OS X and Windows applications using one code base.  Most things ‘just work’ and the language makes it easy to take into account the occasional (and sometimes not occasional) platform specific API calls and differences.  Sometimes the differences are a royal pain but rarely have we been stymied in a project as there always seems to be another option available.  And sometimes the trick is know which things to avoid when working on cross-platform apps.

When I started doing Real Studio consulting a decade ago most of the clients who found us were hard-core Apple users.  They had to satisfy their corporate bosses by developing mainly for Windows and if they could get a Mac OS X version as a side benefit that was great.  For the past couple of years it seemed that the clients who contacted us were the corporate IT folks that had legacy Visual Basic projects and didn’t want to convert to .NET (and yes, the boss wanted a Mac version too).

In the past year, however, we’ve been contacted – a lot – by clients invested in .NET and needing a Mac version.  This isn’t just for their internal business apps either – they’re talking about commercial applications.  What’s even more interesting is the number of calls we’ve fielded by existing .NET development shops needing help.

So it begs the question:  Has Microsoft lost the battle of mindshare?  Has Apple now wedged their way into consumer and corporate America to the point where not having a Mac version of your software is a detriment to marketing and sales?

Don’t get me wrong.  Microsoft isn’t going away any time soon, but I can remember a time when if you mentioned Apple (or any non-Microsoft technology for that matter) you were derided for your obvious stupidity.  I can’t tell you how many times I was laughed at for being an Apple developer.  Now, it’s hard(er) to find diehard 100% Microsoft-only IT person.

I decided to write this post after yet another phone call with a .NET developer.  They want Mac versions and they’ve already decided on Real Studio.  But, and this is always the catch, they’re good at .NET and know next to nothing about Real Studio and nothing about Mac development.

That’s where consultants like us come in as we can help bridge the gap in knowledge.  If you’re interested, we have 36 hours of training video’s (over 100 individual videos) available to subscribers at http://www.bkeeney.com/RealStudioTraining/realstudiotraining.cgi including several projects that start from scratch.  I’ve had experience Real Studio developers tell me they’ve learned a few things even by watching the 6 hours of non-subscription video.  Perhaps your .NET developers would get something out of the training?  Perhaps some one-on-one training would helpful?  Contact me – we can help.

I digress (sorry for the shameless plugs).  Have you Real Studio developers been seeing similar trends?  Does .NET seem to be losing its luster?