Sometimes your first thought is your best one. Well this was definitely the case last week as I continued to struggle with getting the Syntax Highlighter working in an elegant fashion with the main GUI thread. In the end – threading was the solution. I perform some quick and dirty highlighting in the main thread which immediately updates the screen and then I also kick off a background job to highlight the rest of the file which is off screen. This works well and works seamlessly allowing on screen edits to pop up immediately and also meaning that paging up and down through the file gives a consistent look to the highlighting with no additonal calculation required. This backgrounding mechanism for syntax highlighting will also lend well to API lookups when we get to that.
I’m overdue for some new videos and of course as soon as I start thinking about putting together a demo I find all sorts of interesting issues and problems. So we’ll see what happens this week. We’re edging through summer and I’m no nearer to either getting the Rosegarden for Windows build finalised or adding the Kinect support back in to Friendlier – I’ve not even had time to play with the last Kinect for Windows SDK released in June. Time flies and I want both of those things sorted before September and before I have to start thinking about Windows 8 and tablet support.
I’ve just added a new page describing how you can set up MinGW to build C++ with Friendlier. So you should now have all you need to get up and running building C++ (and even Qt based apps) with Friendlier.
Give it a go!
I’ve been building and selling code for a few years now and this is usually as a part time thing alongside something else I’m already doing (i.e. a proper job or having a family). A few years ago I launched a company called Fervent Software which sold Studio to Go! I then launched a company called QuantockSoft which sold a product called TemperDB and I’ve just started a new company called Xyglo which has just started selling some software called Friendlier.
When you’re bringing a product to market (*) and you can only devote part of your time to it due to other commitments, there are many factors you have to weigh up. Some of these relate to the limited time you have, some of them are applicable to all ISVs. First and foremost you need to determine if there is a market for your product – that’s pretty important! Secondly you must decide if what you’re trying to build is achievable with the amount of spare time you have – also important. Thirdly you need to know how to spend your time – when to code and when to spend time on designing and when you have market or promote your piece of software. And finally and most importantly you need to know when to get it out of the door and actually start selling the thing.
Of course all of these steps are potentially perilous. If you’ve come up with something that is innovative then how do you know there is a market for it? As a small independent you don’t have the resources to have a focus group – and anyway have you even defined a core market? So maybe you’re taking a risk on the product or perhaps you’re launching a product to compete with an established player. In that case how do you ensure that you differentiate with that player and still get your voice heard? Secondly are you being realistic about how long it will take to build your software? If you have plenty of spare time and energy then this might be less of a concern, but if you have a family or other commitments be sure to work these in to your planning. Thirdly – and this is actually the best part – remember that you are the boss now. So when it comes to scheduling when you do stuff you can chop and change. If something is becoming a drag in your coding then give it up for a while and do some website stuff, or draw a logo, or write a press release or do some market research. Remember that all the effort you’re putting in is pushing the product in the right direction so don’t dismiss non-coding hours as non-productive ones. Even talking about your ideas with people counts as working – just don’t let them necessarily talk you out of it!
So let’s say you’ve got to that point when you want to release your software on the world but you’re still wracked with indecision. Is it ready? Is it good enough? Is it the right price? Will anybody want it? The only way you’ll find out is by pressing the button and getting it out of the door. If you get that far then there is no better feeling. So good luck.
(* I started writing this with the intention of saying how much easier it had got to build and release software regarding the tools, the payment providers, the website hosters etc. I’ve not got that far this time but I’ll get on to that at a later date. Also we need to talk about App Store vs truly Independent.)
Currently I’m wrestling with the best way of handling syntax updating whilst typing. At the moment the slow, obvious and safe way to do this is just to recalculate everything highlighting-wise when you’re typing. However for large files this starts to take a noticeable amount of time – this can mean that typing can become really slow and disjointed.
There are a couple of approaches we can take here to work around this issue. Firstly we can attempt to only update the highlights for the text that relate to this change. Therefore if a character is deleted on a line then all the highlights after that point on the same line need to move down one character too. If a line is deleted then all the highlights need to move up one line to stay in alignment. This can be quick but there are tricky edge cases – what happens to the highlight when you delete the middle of a keyword? What happens when you remove a comment end marker? There are many multi-line issues that could make this approach fiddly and difficult to get right.
Second approach could be to farm out the highlighting to a separate thread – get it done in the background and only overlay correct highlighting when it’s been completely recalculated. In the interim you could ‘guess’ what should happen with reasonable accuracy without having to be as exact as above.
Thirdly you could buffer the input somewhat so that all input is captured but the commands fire and the updates happen asynchronously after that. This could also be a model that might work well with an Intellisense a-like API generating model. That will take the most amount of work but it should hopefully leave us in a state where the design is flexible enough for us to add API browsing as part of our development experience.
Last week’s S3 cloud outage gave the cloud world a timely reminder that it doesn’t matter how big your infrastructure, you’re going to have some downtime at some point. With the continued migration to cloud solutions for not just B2C and B2B but increasingly intranet apps the question for a lot of organisations is, will the cost saving justify the risk and is that risk acceptable?
Where do we head next? Metacloud? Distribution across clouds? Or do we look to home hosted solutions? Or all of these?
One thing to bear in mind with cloud scale solutions is that they only work because they already use ubiquitous technology. The mechanism that makes them work is something any business of any size can leverage themselves if they know what they’re doing. The same is true for distributed computing as it is file systems but of course with storage you need to think about replication if you can afford it.
So when we talk about the cloud we need have no migration or lock-in fear. We should use it as we use our own servers, our desktops or even our Raspberry Pi. By using a combination of solutions we provide resiliency and availability. Nothing is going to be bulletproof but by anticipating failure modes during planning we can reduce downtime. Additionally we shouldn’t discount local solutions both for backups and for providing redundancy and uptime. The cloud or any geographically distinct storage solution no matter how big is only a part of the solution -and like any part if you rely on it completely then at some point you will have no other option.