Tag Archives: Business

Formatted Text Control Has a New Home and is Open Sourced

Posted on by

One of the biggest shortcomings of Xojo is the lack of a full word processor control. The built-in TextArea doesn’t support images, hyperlinks, full RTF support, page layout view, and so much more. For many Xojo developers it’s a major missing piece. Early on in our consulting projects we found this shortcoming to be a major hindrance so we needed to find a solution.

Like most Xojo developers we turned to the third-party market and found Formatted Text Control that had been developed by Brendan Murphy of True North Software. When Brendan decided to leave the community we purchased the rights to Formatted Text Control and continued its development.

FTC was originally based on the Canvas control and when Xojo was updated to support Cocoa the canvas no longer did proper keyboard handling in macOS. After butting heads with Xojo they released the Text Input Canvas (as open sourced and to this day not properly documented) we had to scramble to update FTC to use it rather than the Canvas. Then we added Retina support, fixed any number of bugs and added features that I’d have to look in git to remember.

And then, like so many things in life, we didn’t use FTC in practically any projects. For years. And when that happens you tend to forget about it and it’s no longer an important thing.

In 2019 we made some serious effort to update FTC but it never went beyond some proof of concept projects and research. By the end of 2019 we recognized that consulting was slowing down to the point it was time to get a full-time job. Obviously all work on FTC stopped. In March of 2020 I found a full-time job (still doing Xojo development) and since then I’ve been slowly selling off products when I found a good home for them.

Today, I’m pleased to announce that Formatted Text Control has found a new home and will become open sourced! Dr. Brian Gaines has been an FTC user since before we purchased it in 2007 and it’s the basis for his suite of conceptual modeling tools. Since those tools will be open source in the near future, FTC will be open source as well. More information can be found at https://pages.cpsc.ucalgary.ca/~gaines/repplus/Code/

I believe that under the stewardship of Dr. Gaines and the open source community FTC will grow and change in ways that I never envisioned. It’s such an important tool for Xojo developers that I envision a lot of interest in it.

I thank Dr. Gaines for purchasing the rights to FTC and for open sourcing it. I want to thank everyone in the community that used FTC over the years, submitted bug reports, and asked those challenging questions on what FTC can and can’t do.

Happy coding!

AutoComplete Wish

Posted on by

I understand that the future of Xojo is API 2.0.  I have used API 2.0 and while I disagree with some of the naming conventions I can live with it.  I do have a problem with many of my older projects, however.  My older projects, especially the big ones, will most likely never use API 2.0 because it’s simply too big of a task to convert.

To upgrade to API 2.0 for a desktop project I have to change my error handling to go from checking for error codes to handling exceptions.  Any string manipulation cannot simply be upgraded because the older API is 1-based and the newer one is 0-based.  And the sheer number of property name changes is disastrous in some projects.  Converting from Date to DateTime is not a simple replacement either.

That’s not to say that these things are not doable but they are not desirable right now.  And I’d really like to not accidentally invoke an API 2.0 method or property because AutoComplete shows me both.  AutoComplete conveniently shows me the old, classic property/method in red which is great but I have no way of knowing what is new for API 2.0.  Therefor I’d love to have the option to choose what is shown in AutoComplete.

Feedback 57885 Feedback #57885 is just that.  This case is currently ranked fairly high so I’m not the only one that thinks this is a great idea.  The basic gist of it is this:  there is a preference setting that allows me to select what I see in AutoComplete, API 2.0, API 2.0 and Classic, or just Classic API.

In the ideal world (as stated in the Feedback case) this would change the deprecation warnings for API 2.0 if you’ve selected Classic API and it would also switch the local documentation to the proper usage to avoid confusion.

Obviously, Xojo does NOT want to implement this because API 2.0 is the future of the platform.  My argument is that without this mechanism many of us with older, big projects, won’t update our licenses because we can’t/won’t use Xojo with API 2.0.  

This is not a good situation to be in because I feel we’re one macOS upgrade away from disaster.  If you’ll recall before Catalina was released FolderItems were broken in  for a while.  This turned out to be an Apple bug that was fixed.  Another example is the ColorPicker and if you’re using an older version of Xojo you have issues with it that you have to workaround.  What happens with Son of Catalina comes out and something else is deprecated and we *have to* upgrade to newer Xojo.

You might feel like I’m complaining for the sake of complaining.  I assure you I am just looking out for my clients assets and my own hard work.  I can’t justify the cost and expense to upgrade to API 2.0 and I really don’t want to mix and match API’s.  I could use a newer version of Xojo but I just can’t take the chance of using something (API 2.0) that’s not fully proven (to me) yet.  All it takes is one mistake and I have a mad client.

Currently 57885 is ranked 9th.  If you’d like to see it get implement throw your points at it.  What do you think?  Am I agonizing over AutoComplete too much or do you think I’m justified in my concern and request?

A Short Video is Worth a Hundred Emails

Posted on by

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

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

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

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

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

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

Tools of the Trade

Posted on by

We are currently getting our kitchen remodeled.  We’ve used the contractor before because we know he does quality work and gets it done when he says it will be done.  Plus, when he gives us a bid, we know that he’s already calculated into the bid stuff that we don’t even know about yet.  There’s not really much difference with doing software consulting.

Most times when clients come to us they have only a vague idea of what they want and need.  Usually we can count the number of paragraphs of specifications on one hand.  So when we start our estimating process we just add stuff in ‘just because’ we know that a typical desktop or web app will require certain types of things.

For example, we know that nearly all applications are database driven.  Thus, we include ActiveRecord unless there is a good reason not to use it.  ActiveRecord gives us some other advantages like speed of development time, fewer bugs, and in an update to ARGen (coming soon) the ability to create initial List and Edit forms (for both web and desktop) with controls already laid out.  It’s far from perfect but using ActiveRecord and ARGen saves us a lot of time.

Many business applications require reporting.  BKeeney Shorts has been around a number of years and has allowed us to create code driven reports.  Now, with the integrated report designer we can give users the ability to create their own reports.  It’s still a young product, and there are things it can’t do yet, but for a vast majority of business reports it works great.  Now, instead of taking a couple of hours to code a report it now takes minutes to design the report and see it right in the designer.

We’ve used the same preference class for many years because it works natively on Mac OS X, Windows and is good enough in Linux.  We’ve developed our Window Menu class that works well too.  For web apps we have our own paging control as well as a customized sorting listbox.  These are all things that we assume we’re going to use in most projects.

Do we factor these things into our estimates?  Of course, we do. We spent time and effort to develop them in the first place.  These tools are part of our standard toolkit and using them saves us, and the client, money.  To put it in terms that our kitchen remodeler might use, he knew going in that he would use a tile saw.  He could go rent one just for our project but he’s purchased one years ago because he knows that he typically has to use one.  Renting makes no sense for him when he uses it for practically every project.

I’m not saying that you need Shorts and ARGen to get your projects out the door (not that I wouldn’t mind the sales), but if you struggle with the tedium of database programming, or you dread doing reports because the built-in tool isn’t what you need, then these tools might be good solutions for you.

Regardless, if you use our tools, or something elses, you need to establish your toolset.  Having a variety of tools to get your projects done is crucial for a consultant.  Whether you use plugins or third party code these have the possibility of saving you hundreds of hours of coding time.  At the end of the day, time equals money.

Happy coding!

Xojo Freemium Model Continues

Posted on by

Late last week Xojo announced that the Freemium model is NOT going to be cancelled and will continue indefinitely. According to a very brief forum post they discovered new information that showed there was no significant revenue difference between the Freemium and 30 Day Models and therefor the Freemium model will continue.

I don’t care which model they end up using. We’ll be buying a license anyway. Freemium has a LOT of advantages to the community. I’m also glad that the revenue difference isn’t significant – which is, by far, the most important part that some are forgetting.

What concerns me the most is the apparent lack of due diligence on Xojo’s part. In the original announcement (since removed – I’ll get to that in a minute) they said they didn’t make this change lightly. It took roughly a week of the community questioning the move for it to be reversed because of ‘new information’.

What the hell? If there is nothing that I’ve learned in my tenure as a Xojo developer is that the community HATES change. Every time there is an IDE change, name change, framework change, licensing change, or pricing change, it will upset more than a few people. Who needs or wants that level of aggravation if it can be helped?

Major policy changes need to be thoroughly vetted well in advance by everyone on staff. Once everyone is on board then, and only then, should it be made public. The change, and subsequent reversal, doesn’t pass the smell test. I believe the decision was made by a select few and not fully investigated internally before it went public.

So lets talk briefly about removing the blog and forum post. First, Xojo has every right to pull it, shred it, burn it, and otherwise recycle the bits. Should they have done that? Well, that’s open for debate. I believe they should have edited the original post with an update at the beginning and end of the article with a quick note and link to subsequent information. That way there’s no hiding the information but also immediately corrects it. But Xojo’s not my company and not my responsibility.

Removing the blog post and forum thread does remove the original blemish. After all, they reversed the decision and really there’s nothing that changes for any user – new or existing. It does leave a minor scar though. Xojo is a small company and the engineers and staff members are incredibly accessible which leads many of us to think “transparent”. Removing historical data leaves a bad taste for some.

Rightly, or wrongly, we expect Xojo to be accessible and transparent and removing those items exposes that as patently false even though it’s never been true. They have zero obligation to be transparent nor do they have any obligation for the engineers to be accessible. They mostly do all those things because they feel like it and it happens to be good for business.

It’s my belief that this will quickly be forgotten. After all, who has it harmed? Not a single person. Xojo may have a little egg on their face but at least it shows that they are flexible. A stubborn regime would have stuck to their original announcement and weather the storm it generated.

Instead they reversed their decision. Removing the blog post and forum thread is questionable but, again, I feel it harms no one except those that feel inclined to be angry at change.

Time to move on and do some coding!

Client Red Flags

Posted on by

I’ve talked before about those little things that prospective clients (and sometimes actual clients) do that should give you cause for concern.  These are those things that should be red flags and make you reconsider taking them as a client, or not keeping them as a client.  We recently took on a new client that had already burned through another Xojo developer before coming to us.

I’ll start off by saying that we have an entire stable of clients that came to us after they had tried out another developer.  Roughly 75% of our long term clients have come to us this way.  For some, the developer left the industry and recommend us to their client but for some the Xojo consultants had failed to deliver a working application even after quite a bit of time and money.  The clients came to us and they’re happy that we have multiple developers and have a breadth of experience that is hard to find elsewhere.  We’re also not going away anytime soon.

This client should have raised enough red flags for us to avoid from the start.  But, honestly, that’s easy to say in retrospect.  Sometimes you just won’t know until you work with them for weeks and sometimes months.  Plus, it was a smallish project that was only a couple of weeks long.  What could go wrong, right?

The clients first developer underbid us by a grand total of 10 hours but had significantly lower billing rate.  A couple of months later the client parted ways due to lack of progress from the first developer and called us back.  Red flag number one, in my opinion.  Clients have every right to be price conscious but one warning sign is if they’re trying to get the project done ‘cheap’ and ‘quick’.  While possible they also need to be flexible and this client was anything but.

The second issue with the client is that they kept using phrases “we want it exactly like this,” with ‘this’ being a VB6 application that looked like they coded it in 1995 and an HTML website that harkened back to the 90’s as well.  Even if Xojo could create such an application (it can’t without significant work) I’m not sure I would simply because creating a 20 year old GUI isn’t something I strive for.  We were going to create modern GUI (nothing crazy – just want Xojo gives us) with a database backend so the application could scale.  But they demanded flat files and a UI that looked ‘exactly’ like their prototype (which was non-functional).  Their reasoning?  Because they understood it and ‘their generation’ understands that look.  Hm…okay.

I guess my biggest issue with this client is they chose Xojo – not us.  There was nothing in the project spec (a VB6 app, a simple HTML web site, and some phone meetings) that said it couldn’t be done in Xojo and when we heard ‘just like this’ we translated this to mean ‘as close to this in Xojo as possible’ and when we didn’t make it look like the 90’s website they were mad and cancelled the contract despite us redesigning the app twice in attempt to mollify them.

In retrospect, the client doesn’t really want a Xojo developer.  They want an HTML and php developer that will do exactly what they want.  No more.  No less.  The signs were there from the beginning – we just failed to see it.

In the long run it’s just another red flag example that I hope to learn from and I hope that you don’t have to go through either.

You Have a Contract, Right?

Posted on by

Writing software for others can be a tricky profession.  The client often has totally unrealistic expectations on how software development works.  They give vague requirements (or none!) and expect you, the developer, to read their mind and produce an awesome application.  And therein lies the problem, because there’s a wide difference between their requirements (or lack thereof) and the finished project.  A handshake and a verbal agreement just isn’t good enough – You need to protect yourself (and the client) with a contract and spell everything out.

If you don’t have a contract already, my preferred place to begin is by going to Docracy (www.docracy.com) and looking up contracts.  These forms aren’t perfect, but they’ve been looked at by lawyers, and in-lieu of hiring your own lawyer, a heck of a lot cheaper.

The basic contract has little over a dozen sections.  I’ll just highlight a few of the sections that seem to grab peoples attention.

A payments section is obvious.  It gets into the details of how you’re getting paid.  More detail is good.  What’s the rate?  How long is it good for?  Is it a fixed bid?  What is the payment structure?  Do you have a separate rate for bug fixes and for how long?  When can you revisit rates?  Do you take check or credit card?  Do you have a fee for taking credit cards?

The expenses section should detail everything that you are paying for out of your own pocket (like computers, development software, etc.) and what you expect the client to reimburse you for.  This could include travel expenses, special services, software, or plugins required for the project, postage and courier services or any number of legitimate things.  The point is that you need to document it!

One section that has caused me some issues over the years was the intellectual property ownership section.  Every client wants to own the code you’ve written and this section gives any patents or trade secrets developed for the project to the client.  I have, as many consultants do, a stable of controls and classes that I reuse on nearly every project which really can’t be the clients’ property when the project is done.  This is where the consultant’s materials section comes into play.

Consultant’s materials are the tools, or pieces of code, that were in existence before the work began that you use to get the job done.  You can give the client nonexclusive rights to the software with some exceptions (spelled out of course), or you can attempt to retain the rights to your own software.  Regardless, this section should be read carefully so that you and the client thoroughly understand the implications.  It has been my experience that this section almost always needs an edit or two to satisfy everyone.

A lot of clients also require a confidentiality agreement section that says that you won’t talk about your work for the client to others without permission from the client.  Sometimes they also want a non-compete section stating that you won’t work on similar software for a certain number of years.  Make sure that you understand the implications of these sections because it might mean you lock yourself out of an industry!

All of the above is fairly generic and is applicable to nearly all contracts.  In my format, the exhibit document is where a bulk of the details occur.  Here is where I list my deliverables, the client deliverables (I don’t like doing graphics so I usually require that the client do them), a listing of any requirements that I’ve received so far (referencing emails and other documents if need be), assumptions that went into the bid, payment schedule and amounts and milestone dates.  As you can image, the exhibit may be much larger than the rest of the contract.

In the client deliverables section, I always state that the client is responsible for final application testing and that they are responsible for end-user support.  The reason that clause is in there is that a client assumed I was doing all the testing and was going to perform end-user support.  This is why writing everything down is so important!

One of the assumptions I generally add into my Xojo projects is that Xojo can actually do what I, and the client, assume it can do.  I only had one issue ever come up and because of that assumption we were able to negotiate a slightly higher contract price to purchase a pricey third-party control.

In the exhibit I add a section that describes how long after the final sign-off I’ll fix bugs for free.  I also state the rate for the following year on program changes (new functionality, not bugs) and when I can renegotiate pricing.  This section can be contentious.  I’ll fix true bugs for a long time, but a lot of times the client doesn’t understand what a bug really is and how it’s different from their poor (or nonexistent) requirements.  If you find a problem client, this will probably be one of the areas that causes you grief.

There’s a lot of information that will be in your contract.  It’s designed to protect you and your client against poor assumptions.  It provides a way for you to handle the client and set their expectations upfront.  In the long run, a good contract will be the roadmap of your projects.

Why have a contract?  Because not having one may cost you  a lot of money.  I turned down a project a few years ago because the prospective client balked at having to pay money up front.  In indignation he claimed in 30 years he’d never paid anyone up front.

He then proceeded to go through the rounds of contractors and they all turned him down for much the same reason.  Finally, he found a developer that was looking for some extra money but already had a full time job.  He did the work (without a contract and without any up front payment).  And, as you can imagine, the client shafted him in the end.  Said that it didn’t work as promised so therefore wasn’t going to pay.  The client was full of it because he walked away with the source and never looked back.

The developer lost thousands of dollars and had no way to enforce it since he didn’t have a contract in place.  Even having a contract won’t stop a client from not paying but at least with a contract the developer could have gone to small claims court to recover some of the money.  No contract meant no such recourse was available.

I think we all have contract horror stories.  Have any that you’d like to share?

Custom Programming

Posted on by

Does your customer really need the type of custom programming you’re selling?  I often get a request for a quote that involves fairly standard business applications such as accounting and contact management.  It’s hard to justify,  to myself at least, why they’d want to spend tens of thousands of dollars when they could spend merely hundreds of dollars on off-the-shelf software.

Off-the-shelf software has some advantages over custom programming.  It’s generally cheaper.  It’s also available immediately, rather than the months (or years) it takes to develop and debug a custom application.  The off-the-shelf software usually has pretty good technical support and a community behind it that can answer those tough questions.  The customer also knows it’s likely the company behind the commercial software will be still be in existence for many years.

Custom programming, on the other hand, is expensive and time consuming.  If the customer wants you to write a QuickBooks killer they’d better be prepared to wait a while and spend some serious money.  Creating software that competes with established, feature-rich applications is a daunting task.

I am sometimes amazed at the reactions from customers when I give them estimates.  Really!?  You thought writing a QuickBooks clone would take 3 months and only cost $10k?

Most contract developers don’t provide much technical support for the product they’ve developed, leaving it up to the customer to fend for themselves.  Some clients are technically savvy, but most aren’t.  Is the customer going to fix the code themselves?  It’s been our experience that even the few clients that know Xojo aren’t capable of changing any code other than the most trivial – otherwise they’d have written it themselves.

Clients that are selling the application commercially are sometimes unprepared to handle tech support and that’s a problem as well.  If they can’t answer basic tech support questions are they going to rely on you to answer those questions?  Are they paying you to do this?  We had one client that assumed we would be providing free tech support, forever.

Is your custom programming business going to stick around for the long-haul?  Will the customer be able to come to you in five years and have you update their application for Windows 7 or Mac OS XIII or the current flavor(s) of Linux?  The customer wants and needs long-term stability.  I good portion of our clients have come from Real Studio and Xojo developers that are no longer consulting.

With all the problems associated with custom programming, why should anyone spend the money on it at all?  The customer gets exactly what they asked for.  If they’ve done a good job explaining their requirements and you’ve done a good job implementing them, they have something that makes their business very effective, very efficient, and is tailored to their business model.

Custom software might be an asset to the client in the event they sell their business.  Some of this depends upon the contract details you signed (you do have a contract, right?) before you started the project.  A lot of clients are going to want some sort of clause that allows them the rights to sell the software (with source code) to another party.

Custom software allows for additions and changes to occur over time.  Off-the-shelf software may be cheap, but try getting Intuit to change the way QuickBooks does their payroll or the way they handle payments.  Custom software allows the customer to grow their software as their company grows.  If the customer wants to integrate CRM functions into their accounting application this year and add event scheduling next year they can.  It’s really only a matter of your time and their money.

When talking to a potential customer for custom programming, be honest.  Tell them the advantages of custom programming.  You also need to be honest about the negatives as well.  A big part of dealing with clients is managing their expectations on what you can and can’t do for them.

Thankfully, by the time a client gets to us they’ve already explored off-the-shelf solutions and have ruled them out.  Usually they have a very specific need that can’t be addressed with the one-size-fits-all commercial application.

Have you ever convinced a client to use off-the-shelf software rather than your custom written solution?  Other thoughts?

Xojo Consulting

Posted on by

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!

Calendar Classes for Xojo 1.1.0

Posted on by

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/