Differentiating Your Services

There are hundreds of consultants out there doing the exact same thing you do.  They’re hustling to sell their services to the very same people you’re trying to sell to.  They don’t live in New York city or San Francisco and can live on $15/hour.  How can you, a good developer, compete with overseas programmers or newbies?

Let’s be honest.  If the client is evaluating potential developers solely on price then you probably don’t want them as a client anyway.  That’s not to say that price should be ignored because a client that’s not frugal with their money is a problem too.  But, it is possible to win a bid even with a higher end price.

So how do you differentiate yourself from the cheap programmers?  The first thing to have is a page on your website that shows previous projects.  This shows potential clients the type of work you’ve done before.  You have to be careful about violating any Non-Disclosure Agreements you have, but for the most part you don’t have to get into specific details about a project to portray the type of work it was.

If you’re just starting out, your previous projects page is going to be sparse.  Another drawback is when your previous projects page doesn’t show the skills the client is looking for.  Unfortunately, the only way to get around this problem is to be upfront with the client and let them know you’ve done the research and have a plan.

Do you have off-site storage of source code?  If you’re working out of your house (who needs an office anyway?) you should probably have automatic backup of source code to an off-site facility.  In the event of a disaster like a flood, fire, earthquake or someone breaks into your house, this is a simple and inexpensive way to protect your work.

We use a Subversion host that gives us gigabytes of storage that amounts to hundreds of Xojo projects files along with documentation and other supplementary info.  The host itself has offsite backup storage and hourly backups.  Does this sound paranoid?  You bet it does!  Your code is your money maker and the client isn’t going to be willing to fund several more months worth of work because your hard drive crashed or your laptop was stolen and you have to recreate your work.  They don’t care, they just want the project done.

Bug tracking systems like Bugzilla, Mantis and many others are good open source software applications that make bug tracking cheap and easy.  Using a bug tracking system is light years ahead of working strictly through email, if for nothing more than the documentation features and audit trail features.  The client can log into the system and see a bug’s status and add additional information.  You, as the developer, can request additional information, close a bug, or merge it with another one.  A good bug tracking system is a must on large projects or projects with multiple developers.

Oddly enough, the other thing that can differentiate yourself from other developers is your contract (you do have a contract, right?).  A good contract is not only protection for you and your client legally, it is also a way to document what you will and won’t do.  It’s the first step into managing the expectations of the client.

Contracts can be a pain to create.  Start with a standard contract.  I’ve been pretty impressed with the documents at www.docracy.com.  Once you have one you like you can add to it.  We use a standard boilerplate contract that is fill-in-the-blank for the basics (name, address, etc) and has general responsibilities for us and the client.  We constantly refer to Appendix A that lists all of our deliverables (source code, installers, documentation, etc), client deliverables (graphics, timely testing, etc), a brief description of what the code will do, and the payment terms.

Price is important and you’ll lose some clients because of it.  It happens.  But using some of the tools and techniques we’ve talked about you can differentiate yourself from the cheap and inexperienced developers.

What things help differentiate you from other developers?

 

XDC 2014 Random Thoughts

Anyone who has been following this blog for any length of time knows that I love the Xojo Developer Conferences.  It’s my one time of the year that I can talk shop all day and night.  Here are some random thoughts on XDC 2014.

Las Vegas: I know a lot of people love, Love, LOVE Las Vegas.  I don’t.  I don’t gamble.  I can only take so many shows, and heaven (and my wife) knows that I’m not there to chase the girls.  Las Vegas is an adult Disney World with a license to lose your inhibitions.  But besides all that I feel that we lost a major part of what I really love about the conference.  Talking with other developers.

The Monte Carlo Hotel has somewhere in the neighborhood of 10 bars and nightclubs.  As the night progresses the ones further from the gambling room close and force you towards the game room.  The music gets louder too making it tough to, you know, have a conversation.

In years past the hotels had a single bar and while it might have closed at 1 or 2 AM it was the one spot you could ALWAYS catch another developer.  This big mega hotels in Las Vegas, not so much.

Another thing that really sucked about the Monte Carlo was the WiFi.  It worked (sometimes) on the first two floors.  In our rooms we had an ethernet cable.  Hello!  2001 faxed us and wants their ethernet back.  I’ve not been in a hotel in the past 10 years that didn’t have a WiFi system (even if it was paid access).  Thankfully, people brought (or bought) Airport Express cards for in-room connectivity.

Needless to say, I will have strong reservations about going to an XDC in Las Vegas again.  Perhaps it’s time to go back to Austin for a year.  Make it a homecoming!

The Battleship Code Contest:  I understand how these things go, they just didn’t have enough time to come up with a NEW contest.  It would have been great to come up with a gambling theme since we were in Vegas.  I was not the only one that was disappointed.  Last year there were close to 30 contestants – this year 11.  It was fun to see the tournament in action.  Geeks cheering on each other is good.

Perhaps the community can come up with an alternative game for next year.  How about something that involves Xojoscript like a battle bot game?

Community Sourcing for Session Topics:  This came up in the Feedback session.  It would be nice to have a period where the community could offer and vote on ideas for sessions.  Then, those of us that would like to speak would have to pick from one of the top X voted ideas.  I think this is brilliant as it might help attendance and breath some fresh ideas into the sessions.  It might also make us get out of our comfort zones a bit and do some real research.  I realize I’m probably in the minority of speakers on this one but I love this idea!

Engineer Vetting of Session Topics:  My entire team collectively attended every session.  The feedback I received from them was that some sessions were awful from the first slide (if there were any slides).  Every session needs to have the question asked:  What is a developer going to get out of it?  And then the slides need to be reviewed with the question:  Will someone looking at these PDF’s in six months even know what they were talking about?

Recordings of Sessions:  This one comes up every year and Xojo always shoots it down.  I get their reasoning:  they want quality, blah, blah, blah.  This is the twenty-teens.  Video is everywhere and it’s SO damn easy to do it this one baffles me.  Sure, I get that they want people to attend the conference but they could also SELL these videos to the community.  Make it 4 or 5 months AFTER the event.  Income streams is a good thing.

Make Slide Decks Available:  Again, like the video, make them available to the community 4 or 5 months after the event.  In a lot of them it doesn’t matter if they were released today.  There’s not enough detail in them that really explains anything.  The details are spoken out loud and the slides are section headers.  For me, they are a reminder of what I heard at XDC.

Do you have any thoughts on XDC 2014?  Where do you want XDC to be held next year?

XDC 2014: Future Hints

In my last post I talked about what version 1 of the new compiler is going to accomplish in the first quarter of 2015.  It’s a great first step and with any switch to a newer, better technology it means some things will become easier to accomplish.

In Joe Raneri’s Compiler session he talked about several new things that the new compiler might be able to do.  I will stress the might bit.  If it doesn’t happen don’t say they promised it.  :)

Autocomplete:  The current autocomplete mechanism in Xojo is completely separate from the compiler.  It’s possible with the new compiler these are unified.  This would be great because the autocomplete code pretty much duplicates what the compiler does since it needs to process the same level of information.  I’ve been told there are dozens of autocomplete classes in Xojo.  If the compiler can process some of this information perhaps autocomplete will be even faster and more reliable.

Debugger Tooltips:  I’ve wanted this one ever since I moved to Xojo from Visual Basic.  While in the debugger it would be very cool to get the value of the variable you’re hovering over to get displayed in a tooltip.  The current object viewer in the debugger is less than ideal and I really despise using it.  I always seem to be fighting it so being able to hover over the variable to get its value would be a very welcome addition.

Xojo Plugins:  This is the long term, and only, approach to getting plugins on iOS.  Currently iOS does not allow dynamic libraries so until Xojo can create plugins, developers will have to use declares into the iOS frameworks.  This is less than ideal so the new compiler will allow iOS developers to create plugins entirely in Xojo code.

I believe that, at least for iOS, Xojo plugins is a definite.  How this affects desktop remains to be seen but what it would mean is that developers would not have to create plugins using C.  What we don’t know is what happens to the current plugin SDK.  Does it get deprecated or does the new way get more/better support over time until no one’s using the old SDK?  Only time will tell.

Other:  A few of the other possibilities that Joe shared that the new compiler might be able to do for us:  better refactoring tools, source indexing (e.g. finding the callers of a method), and more platforms or architectures.

The new compiler is a big deal and it’s been many years in the making.  Some of things that might come out of it are exciting.  It’s my opinion that if Joe is saying these things at lease some preliminary work has been done, or at least some preliminary proof-of-concept code has been completed.

What are you most excited about?

XDC 2014: Compiler News

The Xojo Developer Conference keynote address is usually where a bunch of future items are put on display.  This year it was iOS and Xojo Cloud (the latter just being released).  But sometimes the sessions that the engineers lead are just as informative.  Sometimes it’s hints about future things and sometimes it’s an outright roadmap.

In Geoff’s keynote presentation we learned that the ARM compiler and LLVM backend compiler are real and if not perfect, mostly working.  Joe Strout stated that many things still had to be finalized but it’s a good sign that a significant amount of work has already been put into them and they are functional.

In Joe Ranieri’s ‘About the Xojo Compiler’ session we learned a lot about what a compiler does.  The frontend of the compiler includes the lexer, parser, semantic analyzer, and the intermediate representation (IR) generator.  The results then get passed into the backend of the compiler which has an optimizer and code generator.  That output then gets sent to the linker.  Very technical stuff but interesting.

He then went on to explain how the compiler described isn’t actually what’s in use today. The current compiler is designed to emit machine code quickly and merges a number of the compilation steps together.  Unfortunately this results in it not being reusable for other tasks like autocomplete and there being at least two to three other parsers in the product.  The current compiler also has poor error recovery and diagnostics, and, expects 32-bit integers.  Obviously the compiler needs to be updated.

The new compiler will be designed and implemented very much like what was described earlier, providing a base for future plans. With the first release, the new compiler will create 64-bit applications.  Some of this is waiting on framework work to make sure they are capable of using 64-bits.

The new compiler will be built using LLVM, which has has some great optimization passes but they’re pretty generic to work across a lot of languages.  It will also have additional optimization passes that are specific for Xojo (the language).  This means that some things will get huge speed gains such as direct calls into the framework, redundant reference counting, and direct access to arrays.

The new compiler will have better diagnostics.  Hopefully this will turn into better compiler error messages.  So hopefully this means we can get better information than a generic ‘syntax error.’

Finally, the new compiler will have native linkers.  Currently the compiler does not have native linkers for Linux and Windows which requires the loader stub to do some work that will sometimes trigger Anti-Virus warnings.

The new compiler is scheduled for the first quarter of 2015.  It will not be an immediate replacement and the end Xojo user will be able to switch between the two compilers as fringe cases are found.  All of this is not new to anyone that was around during REALbasic version 5.

All-in-all this is good news.  It’s a little disappointing that it’s going to be another 9 months to see the new compiler but as with all things I’d much rather it work well in version 1 than have it take 3 releases to be usable.

In my next post I’ll talk a little bit about what some of these changes *might* mean in the future.

Xojo Developers Conference 2014

Geoff Perlman of Xojo gave the keynote address at the Xojo Developers Conference (XDC) today.  In his hour long talk Geoff talked a lot about Xojo Cloud and a little bit about the upcoming iOS version of Xojo.

This years XDC sold out and attendance was up over 16% over last year.  Attendees represented 14 different countries and over half were first time attendees.  Early on in the presentation Geoff acknowledged over 20 attendees that have been using Xojo since version 1.0.  He also presented Marc Zeedar (of Xojo Developer Magazine) with having attended every single conference.

Geoff then went on to acknowledge that the name change from Real Studio to Xojo has gone well.  There is one issue in that a sports drink made it to market about the same time with the same name.  The two separate companies are on friendly terms and on Friday all of the attendees will get a bottle of the sports drink.  This may or may not be a good thing on a Friday in Las Vegas.

Xojo Cloud

Xojo Cloud has now been released.  It has a number of benefits including zero configuration, one-click deployment, no maintenance, and better security.  The latter issue is incredibly huge since Xojo discovered that it takes about 15 minutes for a brand new server on the internet to get its first unauthorized access (attack).  With Xojo Cloud the servers are automatically configured with security in mind.

In the long run anyone creating web apps does not want to be a security expert.  However, those developers should be, so the security focus of Xojo Cloud is worth the additional cost.  Xojo admits that it is not the cheapest host, but it doesn’t take too much of your time doing configuration and maintenance on your (non-Xojo) server to make up the cost difference.

Xojo is paranoid about security and this is a good thing.  It was during XDC 2013 that their servers got hacked.  They feverishly moved all their backups into the Xojo Cloud servers.  Since then there have been no infiltrations (that they know of) in over 15 million scans.  When they reviewed their security with RackSpace (their server provider) who told them, “Only our most paranoid customers have this much security.”

Framework Changes

Parts of the Xojo framework have been been around for 15 years.  In that time Xojo has supported Mac OS 68k and PPC, Windows x86, Linux, Mac OS X, Cocoa, and Web (to name a few).  Obviously there are a few areas of cruft that have crept in and there are inconsistencies in the API.  Add in iOS, ARM, 64 bit, and LLVM and Xojo has some serious issues in the framework.  Thus a new framework is in the works.

The existing framework (classic) consists of the desktop and web.  Each of these sits on top of the console framework.  The console framework consists of non-ui items like FolderItem, TextInput/OutputStream and BinaryStream.

With the new frameworks there will be framework namespace for each platform (desktop, web, iOS) and will contain things that are specific for each.  For common elements (like buttons) these will live in the UI framework that lives underneath the platform frameworks.  The ultimate goal of this change will be copying common UI from a desktop app and pasting them into a web app the controls will just work with no problems.  This can’t be done now as the desktop and web controls have separate frameworks.

The new framework will arrive first in console, then web, iOS (initially it will have its own version of the new framework), and then finally desktop.  My advice is to not stress out about this until more information is known.

iOS

The big news of the day is that iOS is very close to being sent to alpha users.  The current schedule (always take schedule news with a grain of salt) has the alpha shipping in May with a beta in June and hopefully shipping to end users in the third quarter of 2014.

Pricing will be $400 for those users that want iOS only.  Pro licenses will go up $200.

Geoff did an initial demo with the iOS application running in the iOS Simulator.  This is similar to things we’ve seen before.  What was new, however, was that Geoff did a final build, used Apple’s Configuration Utility and ran the demo app on an iPhone and an iPad.

From this evidence it seems that work on the LLVM and ARM compiler is well advanced.  Built iOS apps are currently only 32 bit.

Another interesting tidbit from the demo was that Auto Layout is in full force in iOS.  Auto Layout is a super advanced way to handling automatic layout for windows, views, containers, etc. and is much more advanced than the simple locking properties.  This should really help in localization.  Other than the quick aside in the demo there was not much said about it.

All-in-all the keynote was fairly quiet.  Not a whole lot of new information was given out.  Ta ta for now and if I find out more information I’ll share it with you.

 

Xojo Consulting

When we (Christian Miller of Pariahware and myself) spoke at REAL World 2007 about Xojo (then Real Studio) consulting we had no idea what people wanted.  So we took the generic approach of  lets-throw-everything-we-can-think-of-and-fit-it-into-45-minute presentation.  We were surprised that nearly every seat in the room was filled.  We were off to a decent start.

To make a very long story short, we were pretty happy at the response to the presentation.  What surprised us even more was the Question and Answer session afterward.  There were a lot of really good questions.  One of those questions has come up again and again:  How do you find Xojo Consulting work?  It’s a good question.

In my opinion, the best way to find work is to get the Professional license for Xojo.  Yes, at $995 it is expensive but in addition to the Desktop, Web, Database Access and Console you get access to the Pro-only forum which includes access to Xojo consulting leads.  As a consultant I find myself using all the Pro features eventually so the price doesn’t concern me.  I do realize that not everyone has the same resources that I do.

There is a page on the Xojo website called Find a Consultant where potential clients enter basic details of who they are, how to contact them and a brief synopsis of their project.  That information is then posted in the Pro-Only forum.  In turn, the developers may contact the person who posted the project.

In my opinion, this is like shooting fish in a barrel.  The potential customer already knows (or at least thinks they know) that they want a Xojo developer.  So you don’t have to sell them on Xojo or the advantages of one code base for three platforms for desktop, web, and console apps.  Isn’t that half the battle?

I’ve been part of the program for a a long time (in all its various incarnations and price points).  The quality and quantity of the leads varies considerably but all it takes is one decent sized project to make up your investment. You can find more information about it at https://xojo.com/support/consultants.php.

Most of the clients I’ve obtained from these leads have come back for more work.  This doesn’t happen with every client, naturally, but it happens enough to make a note about it.  In several cases the original job was a small project so the client could see if we were worthy of the project they REALLY wanted to do.  These small projects are good to see if you and the client are compatible (people are people and some just don’t get along).

Other developers have had some luck with finding work on the hire a developer sites like Rent A Coder.  Some of these sites require a fee to bid on the listings.  I would use caution using these sites to find work as your competing against people from all over the world.  Some people can live on $15 an hour (or less).  If you can pay your bills and save for your retirement at that rate then go for it.  I know I can’t!

Bidding on a fixed bid projects is an art form.  I use some basic formulas that call for a certain number of hours for each window/class/control and for really complex windows or classes I break them out separately.  Then if you want to get an idea of how much time you’ll spend on a project multiply your estimate by three.  That will take care of interruptions and waiting for responses for questions, doing research, and all of the things you have to do on a project that you can’t directly bill for.  I know a few developers that use a factor of 5 in doing their estimates.

This might seem a bit excessive but nearly every project I’ve ever worked on (even as an engineer in a previous lifetime) this seems to work reasonably well.  This doesn’t mean that the bid is inflated by three, it just means that I’ve accounted for interruptions and other issues that come up that might cause a delay.  At any given time I’m usually working on three or four separate projects and each one needs attention on a regular basis.

Track the time you spend on each project.  If you can, track the time you spend on each part of the project.  After each project, review how long it took to do the entire project and if you can, track how much each portion of the project took.  After you’ve done it a few times, you’ll find out what takes more time than you anticipated and what takes less.  This is valuable feedback for when you’re first starting out and learning how to do things.

Another thing to keep in mind is that you need to live on what you’ve bid.  If your rate is $15 an hour and you live in New York City I doubt you’ll be living comfortably unless you have six roommates in a two bedroom apartment!  In the long run, what you earn has to take into account your lifestyle, your location, and your ability to set aside enough for your retirement years.

As a consultant if you can bill 30 hours per week that’s awesome!  Most consultants say 20 billable hours per week is good.  Use that as your basis for determining what you should charge.  You’ll need to allow time for dealing with administrative issues, taxes, writing proposals and looking for more work.  Then take into account vacation and sick time (it happens) and what your expenses are and you’ll need some padding because some months will be slower than others.

50 weeks * 20 hours = 1000 hours per year.  You determine that you can making a living if you bring in $80,000 per year.  That means that you need to charge $80 per hour.  $80,000/1000 hours = $80/hour.  Don’t forget that you’ll have to pay your own taxes and insurance so take those things into account!

To be honest we charge significantly more than the $80/hour rate.  This was just an example of how to do some simple math to come up with a consulting rate.  Hopefully your rate leaves you with enough to live on and start saving for retirement.

Where are you finding Xojo work?  Have any fun stories of a client saying no to your rate and then coming back a year later after spending far more than your original estimate?

Look for some posts next week about my experiences at XDC!

Xojo 2014 Release 1

Xojo 2014 Release 1 hit the internet this week.  This substantial update fixes a number of issues, has some very nice enhancements, and has the long awaited release of Xojo Cloud.  So let’s dig in!

Xojo Cloud is, as the name implies, a hosting service for web applications written in Xojo.  It is a one-click deployment solution that greatly simplifies the process of deploying your Xojo web apps.  It really is pretty simple and there are really only a few caveats with using it.

Xojo Cloud is using RackSpace servers and there are three configurations that are currently available.  The small and cheapest server has 512 MB of RAM, 20GB of storage, and 1 Virtual CPU for $49/month.  The medium server has 1 GB of Ram, 40 GB of storage and 1 Virtual CPU for $99/month.  The biggest server has 2 GB of RAM, 80 GB of storage, and 2 Virtual CPU’s for $199/month.

This seems like a lot of money considering that a VPS offered by many hosting companies runs you about $400 a year (or less).  However, those VPS solutions are unmanaged and it’s up to you to keep them secure.  The Xojo Cloud solution has some pretty strict security that has intrusion detection and some other goodies that will make it difficult for an intruder to get to your application and data.  Add on that Xojo web apps are compiled and it makes for a pretty secure system.  Only time will tell how secure it is but unless you’re an expert on security it’s unlikely that your unmanaged VPS will be more secure.

Xojo web apps are guaranteed to work with Xojo Cloud (duh).  That’s not always the case with my experience with VPS solutions.  You have to worry about 32 bit compatibility libraries, permissions, and a whole host of other things that could go wrong.  Really, Xojo Cloud is a pretty decent value if you don’t like, or want, to manage your own server.

Xojo Cloud is a version 1 release.  There are a number of things that are not available yet.  For one, the server does not come with a database server though this is very high on their list.  During the alpha period I was able to, with the help of Xojo engineers, use a Rackspace Database Server (MySQL) working with a Xojo Web app.  Also, if you have a lot of storage needs (we have 40 GB of video for the Xojo Training Application) you probably will have to get a RackSpace Cloud Files account.  All-in-all it’s not very hard once you get it setup but RackSpace can be kind of daunting  as you wade through all of their options.

Xojo 2014 Release 1 comes with some Cloud specific framework additions.  The first is a TargetXojoCloud constant that lets you call code specific to Xojo Cloud.  One of those is the XojoCloud.FirewallPort method this allows you to open a port in the server firewall.  Once the reference goes out of scope the port is automatically closed.  If you do any communication with the outside world such as sending an email, you’ll need to open the port to the mail server.

There is currently no control panel to upload or view files.  Release 1 comes with an example on how to do this via a web app.  There are four areas that you can access on your server:  the application area, the Temporary directory, Shared Documents, and Documents.  The latter 3 can be access via the SpecialFolder object.  Accessing the Documents folder of your application creates a Documents directory next to the application and accessing the Shared Documents creates a Documents directory in the overall applications directory.

A few other miscellaneous things that are kind of a drag:  There’s no way to create testing builds without changing the name.  Ideally, I would want the Stage Code to let me make testing builds without affecting the production app.  My second issue is that as a consultant I will potentially have multiple clients with their own servers.  Currently there is no way to share servers. The good news is that both of these items are in development and could be added at almost any time.  I’ve been told that some Xojo Cloud enhancements don’t depend on the IDE release schedule.

The IDE has some Xojo Cloud specific additions as well.  In the Build Settings you’ll now find Xojo Cloud as one of the targets.  Once selected you’ll get Cloud Specific properties in the Inspector.  Currently there are only two:  The name of the application and a popupmenu listing your servers.

All-in-all, Xojo Cloud is a very good first release.  In the years that Web Edition has been around, deployment issues are the biggest headache for many.  It can be quite frustrating to deal with the various issues and while Xojo Cloud seems a bit pricey we plan on migrating our apps over to it (technically some already are but they’re not public yet).  File Storage and Database support is an extra addition, however, and some might find that unpalatable for now.

As if that wasn’t enough, there’s more!  Release 1 has a ton of fixes and enhancements.  The Layout Editors are MUCH speedier.  I have several layouts that in previous versions were almost unusable with web containers.  I had several web pages with fairly complex containers on them and when I selected one of them it would take a second for the Inspector to load and forget about doing a drag of the container as it would lag to the point of being worthless.  This enhancement alone is worth the upgrade, in my opinion.

The IDE received a bunch of love fixing some of the more painful bugs in the Navigator.  There are simply too many to list here but it’s a lot of changes in improving the user experience.  Some of the properties in the Inspector have now been migrated to the advanced tab of the Inspector.  The advanced tab used to contain only the Attributes panel but now some things like Font, Control Set, Focus and Database Bindings.  No great loss of those since they’re not changed very often (or even used).

The SQL Server database class was enhanced so that it works with SQL Server 2012.  This is good news for folks running Microsoft SQL Server.

Another big change in this release is the removal of QuickTime dependencies in the IDE and in Cocoa builds.  Apple has deprecated QuickTime and is rejecting apps from Mac App Store that use it.  In release 1 all framework references to QuickTime and QTKit are removed.  If you are using EditableMovie or any of the QuickTime decencies in the MoviePlayer you are out of luck.  There are currently no plans to replace EditableMovie.  Along with this, the MoviePlayer was rewritten to work without QuickTime.

A new language feature is the IF operator.  This is similar to the VB IIf or VB.Nets’s If operator.  An example is:  If(myInteger > 40, “Big number”, “Small number”).  My only beef with the IF operator is that the debugger can’t show you the results unless you have a local variable defined to show it.

I highly recommend that you peruse the release notes as there is a plethora of changes and enhancements listed.

What are your thoughts on Xojo Cloud and this release?

Edit: Fixed a few typo’s.

Calendar Classes for Xojo 1.1.0

BKeeney Software has released version 1.1 of our Calendar Classes for Xojo and Real Studio. The Calendar Control is a Canvas subclass that lets you easily add Day, Week, Multi-Week, and Month views into your desktop applications.  The Calendar Control works in Mac OS X (carbon and Cocoa), Windows, and Linux applications.

New in Version 1.1:

  • Made Retina Ready (Mac OS X only)
  • Events on day view no longer overlap
  • Added ClearEvents method
  • Added Constant, kVersion to BKS_CalendarBase
  • You can now drag events to different times
  • Added a time interval to mConfig to constrain time drags and start/stop drag changes
  • Changed EventMoved event parameter to make usage more clear
  • Added ScrollToTime method to make the calendar scroll to that time
  • Added a new EventChanged event to tell the user that the event may have changed due to a time drag (move or change start/stop time)

We offer two versions of the Calendar, the Standard license is an encrypted set of classes and for those needing to get to the full source code we offer the Professional license.

More information can be found at http://www.bkeeney.com/calendar-classes-for-real-studio/

Bat Shit Crazy Fix

Every now and then the Xojo IDE/compiler does something that just makes zero logical sense.  By all accounts some bit of code should work.  But it doesn’t and no amount of debugging and code changes solves it.  It’s easy to spend hours and hours chasing these bugs

Most times when something like this happens a simple Xojo restart fixes it.  But not always.

After that, I delete the Xojo cache files and restart Xojo.  Most of the time that will fix it.  But not always.

So I came up with the “If you think you are bat shit crazy fix”.  Do all of the above and simply restart your machine.  This has always fixed those situations.

Fine, call me bat shit crazy but I have at least 3 other developers that can attest that this works.  After hours and hours of trying to debug an issue I was out of options and that was the my last bit of advice.  Guess what?  Their problem mysteriously disappeared.

I have no idea what the problem is or even how to report it to Xojo.  All I know is that if I’ve exhausted everything else in my arsenal, the clear cache and restart seems to work.  Who’s crazy now?

How Not to Get Screwed By Clients

Excellent article over at Fast Company that’s a really good read.  http://www.fastcodesign.com/3024819/how-not-to-get-screwed-by-clients?partner=newsletter  I’ll wait for you to come back.

Get it in Writing

Never do any work unless you have it in writing.  If you do happen to be talking via phone or video send an email afterward what you think you heard.  It’s up to the client to tell you differently then.

Don’t do any work without a contract.  You can find some simple contracts over a http://www.docracy.com.

No Spec Work

We get this line a lot, “There’s additional work in the future.  What kind of a price break can we get on this small starter project?”  Really?  You want the discount, now, before we’ve established that we can work together?  Um…no.  Discounts are for when you trust each other and it’s a really big project (as in you don’t have to find additional work).

Upfront payments & never send final work before final money

If you ever have a client tell you that they’ll pay you afterwards just walk away.  Seriously.

I turned down a project a few years back for a lot of reasons but one of them was that my gut was telling me the client seemed ‘slimy’.  For one, he insisted that in his 30 years of working with developers no one had EVER asked him for money upfront.  We said no and he went on his way.  He shopped his project around to a number of other consultants who also turned him down (for similar reasons).

Finally he found a Xojo developer that was just doing consulting for fun (really!) and who didn’t ask for any money up front.  What could go wrong, right?  He agreed to the project (no contract, by the way, but that’s another story) and delivered the project.  Guess what, the client stiffed him.

This developer did the work with no down payment and gave the client the final product before payment.  If he had at least gotten a down payment he would have been compensated a little.  Instead he got nothing.  Make sure you have your bases covered.  And of course with no contract in place the developer has no recourse.

Look for red flags.  Run for the hills

Don’t be afraid to run away from a prospective client.  Trust your instincts.  The linked to article has some good ones (including the This will lead to paid work line).  Some of our red flags:

• No specifications.  It’s common for a client to not have the fine details but when they have zero idea what they want then it’s time to move on (or charge them to write the specifications).

• Worse yet, worthless specifications.  I once had a client give me an 80 page specification document that made zero sense.  We had four people review it and all of us came out scratching our heads.  Funny enough, after meeting with him it was written exactly the way he talked.  Sadly, I should have walked away from that project even though the alarm bells were ringing.

• They fight you over every penny.  I’m not saying that the client shouldn’t be prudent with their money, but if they are professionals looking for professional help they should realize that your time, effort, and experience is not cheap.

• You’re the third or fourth developer they’ve either approached or worked with.  There’s a reason why they keep not finding or losing developers.

There are more red flags but those are a start.  What are some of your red flags with clients?