Forays into International Postage

With the intention of getting some Stack Overflow Stickers (http://blog.stackoverflow.com/2009/09/how-to-get-stack-overflow-stickers/), I went down to the post office to get an international reply coupon.

Img_0129

Odd things, they can't be used that often. The postmaster told me that it'd been the first time in 4 years that someone had asked for one. What they basically allow you to do is give someone the value of shipping for a letter. In this case, I'll throw it in an envelope to get my stickers.
 
Oh, and it was £1.10 - it's probably cheaper to stick a few $1 coins to an envelope.

Crumpler Cheesy Disco - New Laptop Bag

This arrived today. Brilliant new messenger/laptop bag to hold my
MacBook Pro, some folders, couple of pens, etc.

 There is plenty of space and the material seems strong enough to last
through the roughest of treatment.

 I shall see how it goes.

(download)

A Few Notes on the Apple Education Store

I just ordered my new MacBook Pro from the Apple Education Store. I thought I'd write up a few things that I needed to get the rather sizable education discount (15%).

 Firstly, you need to ring them: 0800 072 1154 is the number to use.

 After getting through to the call centre you'll be able to make your order. If you've ordered from them in the past (or, possibly have an iTunes account) they'll already have your details on file, so you can hand over the email address you'd usually use for that.

 After that you can order what you like.

 Once you've entered your payment details, the person at Apple will ask you to provide some evidence - to show that you are on the course you say you are. This can either be a scan of your student ID card (which, if you are like me, you won't have one yet) or your University Confirmation Letter.

 This can be scanned, or photographed and then sent into Apple (via the receipt they email you).

 Any questions? Pop me an email.

API Decisions and Targeted Development

I'm having a bit of a change in theory over how Web Services/Applications/etc should be developed. Typically you would build out your web application by designing a database, handling the UI, getting it up and running and then launch. Some time after that you'd open a public API and allow your users to build upon your application.

 If you cut back slightly to the development process, I think (at least mine) will need to change. Typically I would work along the following flow:

 1. Outline the Idea
2. Design the Database
3. Design the UI
4. Start Implementing Features
5. etc..

 The trouble is, designing the UI is quite a big hurdle. Design isn't my forte, I'm just able to build things that work. I would rather skip it entirely and cut down to implementing features.

 In the work I've done at Zefridge (http://zefridge.com) and other places, this is the method I've employed in building out the primary product. A large amount of time is usually spent on a mix of implementation and a progressive development of the user interface. So, for example, to implement a calendar event addition feature, you need to both build the back end to do it, and design how it will work. Neither of these are instant, and in some cases complicated to get working. Above all of it, it's slow, and mostly, boring.

 Instead I've thought about a different workflow. Something which is put above methodologies such as MVC and that is based around building API's.

 So instead of designing interfaces, you cut straight into building out the functionality at a core or, backend level before passing on these features to your users. At face value, it appears to be doubling up on the level of work required. You need to re-implement these features twice, rather just the once.

 However, more than likely you will build a public facing API and when you are dealing with a wide featured application, you may not implement new features directly onto the public, instead building and testing them upon your API.

 Of note; Google Reader was built in this way. First an API was built as an example, then the Reader app itself was built on top to see if this API worked as it was intended.

 As a consumer fronting product, the work I've been doing on Zefridge fits the wide ranging aspect rather appropriately. Whilst I can't fill you in on spec details, I can explain one part which I will eventually start working on.

Readernaut_feedback

The screenshot above shows the support/suggestions/bugs input box on Readernaut. It's use is of course self-explanatory. I intend to build such a thing on Zefridge - a way to easily ask questions, explain app problems and otherwise from within the application. By making it easier for the end user to do, they are more likely to take the effort to do it.
 
Instead of buliding this functionality directly into the main web app, I instead intend to build an API to handle support and a simple backend for tracking messages (simple to the point where it is merely a listing, or simpler, as in, sent directly to the users inbox) and then start to roll it out to users.
 
This is a far more flexible solution, and allows a working team (which works on different sections of the same project) to be able to roll the latest build out to users without showing functionality which won't yet work. This is obviously important for testing - support isn't the core functionality of the application, even though it is important.
 
At the risk of making this quite long, I'm going to end on the topic of another post: What's the best way to design an API? To refine that, what's the best way to design an API with PHP?

On Personal Wiki's

I'm not sure if it's down to my penchant for being somewhat OCD in the way I like to organise information, but having a Personal Wiki is probably the best 10 minutes I've spent setting something up.

 I'm currently using a local install of Instiki 0.17.0 which is working extremely well for me. It's local only to keep it out of other's prying eyes (not that it current contains anything sensitive, yet).

 What I do know though is that it is going to be my all in one solution for cataloguing new information as it hits me, reminding me of other things and ideas and to the point where it will certainly help me keep projects running.

 I'm currently building it out like the screenshot below shows, using large links to different sections. In this it shows the "Projects" sub-page, which within it has a list of a few new project ideas and links to current ones I'm dealing with, then the Infrastructure page, which in this case gives the information about the couple of servers I administer. What this directly saves is looking at an external source to see what an IP is, even when you only have three, it makes life a lot easier.

Picture_1

I chose Instiki over other solutions not because of it's framework (it's Ruby on Rails based), but because of it's design and integration with Markdown. I would have liked to have written my own, but not having the time was a big issue. Instiki allowed me to roll it out and instantly start adding content, which is a real plus.
 
I currently have this setup on a Windows box at home (which is why it's mostly local), but is far from ideal, so if any one can suggest a cheap Rails host, I'd be grateful.
 
In regards to limitations, I can only think of the lack of an API, or general plugin architecture. The latter is somewhat of a plus (it's less bulky), but an API would be great to have an iPhone app, or such like.

"Check in" Type Location Networks

For a little while I've wanted to play around with a project based around location based networks. At it's core, it'd be a way for a user to post their location, at the very basics, do the equivalent of an airport style "check in". Although, rather than confirming they're on a flight, tell a service their current location.

 With that in mind, it could be used for anything from plotting where you spent the day, to receiving localised adverts (think of a deal specific to a local coffee shop), or meeting up with others (I hear you scream to suggest interacting manually, but I'm more interested in the technology).

Picture_1

So I cracked open a copy of Balsamiq Mockups and threw this together in just around 10 minutes (I know that because the nag screen showed up once and then just after I had finished).
 
This is based around using an iPhone to do it. With an iPhone, not having background apps is of course an issue, but by changing from a constant tracking methodology to something based around checking in, this problem is almost solved. With this idea, you can also chose when to share, rather than automatically sharing.
 
I am currently stuck with naming ideas and others, the domain "check.in" is taken, so this just shows a basic idea. I would be interested to see if it had a possible userbase, it's certainly possible to make it a weekend project, so if you would be interested, please drop me a line.