So how am I meant to deal with the light blue blobs. I can’t ‘edit’ that text in any sensible fashion when what I really want to do is remove the space just after the * character. I end up just typing the whole thing which removes the point of autocomplete.
The consensus wasn't to go live with the new site straight away after all but to create a better impression on the public by waiting on the final design and within no time at all Jordan had worked his graphical magic and delivered the goods.
I was supplied with a .psd mockup and got busy with Photoshop. I hadn't used this app in a while and it took some time to relearn how to use it but I managed to cut things up and proceeded to get stuck into the CSS.
Again I had to revisit some skills I hadn’t used since I started my current day job and when I looked at my first iteration in Internet Explorer I nearly cried.
Areas of difficulty I had were mainly concerned with how different browsers implement the box model and I also had to jump through some hoops to get opacity working but the end result is a consistent look across Firefox 2.0.x on Windows & Mac, Safari 3.0.x on Mac and IE 6.0.x on Windows. I haven't had a chance to test it with IE 7 but I imagine it is as broken as it's younger sibling 
I've already been working on the release process so there's just a few minor tweaks to go and the new site will be available in production.
I’m preparing to push my code for the new Infurious site into production so we can start selling our first application, Rickshaw.
The site’s not too pretty but It Works and our freshly recruited designer Jordan has some interesting ideas for the next iteration. All the important stuff is present: people can download Rickshaw, purchase a license and the license details will be generated and mailed out to them. I’ve just had a dry run of this scenario and it all looks good.
Thankfully Aidan has been at hand and steered me away from over-engineering the project and ending up with just a mess of unfinished code 
Doing this and holding down a 9 to 5 I’ve found difficult and the progress has been painfully slow but it will all be worth it.
Watch this space!
Here’s the scenario: you’re writing a green field web application. This application will be used to power more than one e-commerce site, which means that it must be easily tailored. You can use any toolset you like, and the requirements are fairly standard (e.g. exporting data to CSV, modern UI, payment gateway, etc.). What do you choose?
So, it seems you’ve got three options (anyone think of a 4th?). Of course within each of these options there are any number of competing solutions, especially in “build your own”, where you could potentially use any language, web server, etc.
I think with any software developer, the preference is to build one’s own. That way you get ultimate flexibility and intimate understanding of the code, which makes it easier to expand and customise. The downside is that you have more work up-front in order to get running.
Off-the-shelf (i.e. commercial) software tends to have a lot of features that your accountant and fulfillment department would like, and often gives you the ability to customise using one of a few popular languages or their own pseudo-language. The real advantage is that you can have a store quickly, or so you might think. Often, shoe-horning your data into their proprietary and closed-source format makes this option longer and more expensive than building it yourself.
All of which leaves open-source engines. You can be up and running quickly (like with commercial apps) but you have access to the source code if you decide you need to change things the way you want them. Potential downsides are lack of support and lack of particular features you might need (e.g. a particular payment gateway).
So, which would you choose?
Just a quick update on what I’ve been working on for Infurious recently.
Since finishing up on configuring Jabber I’ve been developing our website with the specific aim of allowing customers to download our products and purchase licenses for them.
For this I’ve returned to CakePHP and been tinkering with the PHP portion of the AquaticPrime framework which Aidan has implemented in our upcoming application, Rickshaw.
Other highlights have been working with the PayPal Sandbox and writing a component which generates “Buy Now” buttons for our apps and then handles the Instant Payment Notification and Payment Data Transfer callbacks once the transaction has been completed.
My current task is generating the license details, emailing the details to the customer and finally bunging a copy into our database for future reference and backup purposes…
It beats making minor configuration changes for the world's largest financial institution any day!
[[NSFileManager defaultManager] createDirectoryAtPath:_attachmentStorageDirectory withIntermediateDirectories:YES attributes:nil error:nil];
NSLog(@"Directory created!");
Anyone who knows me, knows I’m not a programmer. I speak Hello World in about 8 languages. Not very impressive. I’ve been able to hack a little php and javascript in the past and played with perl and Java for nothing useful. I did fix a couple of C programs back in the day so, like music, I’m able to read it but not really write or play.
The code block above represents my first real line of production code and though it’s fair to say that my hand was guided at every step, I do see it as a way forward.
I’ve never really needed to be a coder which is apparently one of the main reasons I can’t code. It’s never been instrumental to my daily bread and so it wasn’t a skill I retained despite learning Modula 2, C, Java, Javascript, Perl…etc. The only “code” skill I developed in any meaningful way was shell scripting which was used infrequently enough to require relearning when I needed to modify my own code.
My background was in Networks and there’s little programming needed in desktop support and network support. My own shell scripts were developed to enhance my burgeoning laziness (it is my contention that the best IT person is a conscientiously lazy IT person - someone who will work a 36 hour shift in order to put something in place that will shave 5 minutes off his daily routine.) I was happy to script snmp commands so I didn’t have to type them in, I’d just cron them. I was happier still to script AV definition file distribution so I didn’t need to visit every desktop and laptop with a floppy disk.
But there’s a change afoot and I want to get more into the code. It’s not something I really relish because after being known for years as the local Mac Daddy I find myself now a complete noob and no-one likes to feel stupid. But it’s something I want to do and, to be honest, feel compelled by myself to manage.
Learning Objective-C with Cocoa is daunting, not only because the syntax is odd (though really I have little to compare it with) but because the libraries are so comprehensive. As I’m also trying to get to grips with Object Oriented Programming, I have a double-whammy of confusion.
The 7th Ironcoder contest was announced today (for some definition of today - damn those pesky time zones). I think this year I actually feel confident enough to take part, even if I accomplish not very much 
For those who have no idea what it is, each contest selects a theme and Mac OS X API, then gives you 48 hours (real time) to write an app that has both theme and API centrally featured. Check out the Ironcoder site for more info, or take a look at the entries for Ironcoder 5.
If you happen to be using Xcode and get this somewhat baffling error message when building:
syntax error before ‘AT_NAME’ token
The problem is that you are missing an @end in some file that you’ve #imported, probably a header file. This error also shows up as “parse error ...” in some versions of Xcode (took me a while to track down with Google as a result).
This morning the subject in the Infurious chat swayed to the iPhone and the new possibilities with the SDK being available in February.
The SDK will enable applications to be written for both iPhone and iPod touch. This has different implications for applications wanting to take advantage of the New World Order.
Thinking of applications which are useful in terms of:
The conversations have started but from the above I’m guessing we’ll see free apps being “limited” to Web-apps and commercial apps getting the limelight. Unless of course, you fancy hacking it?
[Fraser Speirs agrees with some of this]
I’ve started working on some projects with a bunch of guys who are not used to using version control systems. This post is as much for them as it is for anyone else. I won’t go into how to install subversion, because that is covered by many other people elsewhere. I also don’t touch on how to administer subversion for the same reason. This simple guide is purely for how to be a subversion user. It assumes that you know how to access and use a Unix command line. There are GUIs out there for handling these activities, but I’m working from the perspective that (a) “In the beginning was the command line…” and (b) the principle is the same regardless of the interface.
If you are about to use subversion, your administrator has probably given you a URL for your repository. This could have a number of forms, but for our purposes they can all be treated identically - I’m going to use the fictitious URL http://example.com/svn/repo/trunk/project. The repository (as you probably know) is just a central store for all the files for a given project, along with version information. The first thing you’ll do is create a working copy of the repository on your computer.
svn co http://example.com/svn/repo/trunk/next_big_thing
Subversion will spit out some information about what it’s doing - ignore that for now. What’s happening here? It’s very simple.svn is the subversion command line application. The co command is short for checkout, which tells subversion to go the URL supplied and bring back a copy of the latest version of what’s there. This will create a directory (or folder if you prefer that term) with the same name as the bit after the last / of the URL - in this example: next_big_thing. That next_big_thing directory is your working copy of the repository.
Everyone who works on the Next Big Thing project will need to perform this same sort of checkout to their local computer. What lives in a working copy? Any sorts of files that you like: documents, source code, images, etc.
Go ahead and fiddle with stuff in your working copy - you can do anything you like because none of it will affect anyone else until you commit your changes back to the repository. Put some files into the directory, edit what’s already there, delete some as well - you can get it all back the way it was very easily. But first, let’s take a look at what’s changed (yes, that means you actually do have to go and change some things in your working copy: go on, I’ll go get a cup of coffee while you’re doing that … ready? OK, good). Run this command (from within your working copy - anywhere will do, but the top-level folder is best):
svn status
You should see a list of the changes you’ve made, with one of three characters beside them. Don’t worry about anything else that is spat out at this point (if anything).
? foo.txt- a file you’ve added that subversion doesn’t know about (yet)
M bar.txt- a file you’ve changed (M stands for merge, which is what happens to this file if you commit your changes)
! baz.txt- a file you’ve deleted
You’ve put some files into your working copy, but there’s another step that needs to happen before they can be committed to the central repository.
svn add mynewfile.txt
Naturally, you substitute “mynewfile.txt” for the name of your actual file. This tells subversion that you want to add the file to the repository the next time that you perform a commit (which we’ll get to in a moment). Why is this step necessary? There are any number of reasons why you wouldn’t want to automatically commit any file in your repository. The most common is probably that many programs create backup or temporary copies of files in a directory while you’re working on them - it wouldn’t be good to clutter up the repository with cruft. Subversion itself creates temporary files when there’s a conflict (yes, even in version control there is conflict - I may do another guide on how to deal with that).
Likewise, to delete a file you need to use:
svn delete myoldfile.txt
otherwise subversion gets confused. When you use add and delete, you’ll get a different status beside your file when you run that command - it’ll be A and D respectively (instead of the ? and ! that we saw above).
As I mentioned above, it’s easy to get things back the way they were. If you want to back out any changes you’ve made to the whole project, do this in the top-level directory:
svn revert
You can also use svn revert myfile.txt to revert individual files (or directories).
So, now you’ve made all the changes you want to make, it’s time to commit them back to the central repository. This is where all the actual version control magic actually happens. Run this command from the top-level directory of your working copy:
svn commit
The first thing that will happen here is that a text editor will start up (usually vi). Enter a comment describing your change and then save and exit (in vi that means typing ZZ in command mode).
This will take all the changes you’ve made and upload them into the repository, commented with what you wrote. Now the next time someone runs svn co ... all your changes will be visible to them. If someone else has also committed some changes, you can get the latest version with (from the top-level directory):
svn update
You will probably need to run the update command before you do a commit so that you have the latest version of the repository before trying to change it. Any time you (or anyone else) runs svn commit, the version number of the repository goes up by one. In this way, it’s easy to tell the state of every file in the repository at any particular point in the repository’s history, and it’s how you avoid having one person overwrite all (or worse: some) of the work done by someone else.
You can see the changes that people have made by using
svn log
Be careful with running this in the top-level directory of your working copy - you’ll get every commit message for the project since the first revision. Usually this is run on an individual file to see the history of that file.
That’s it - you now know the absolute basics of subversion. For more detail, I suggest reading the online Subversion Book. Any questions, comments or inaccuracies can be sent my way.
