Ian McShane Rotating Header Image

February, 2007:

Ultimate Everything

My last post mentioned that I had managed to use Noobz‘ latest downgrader and my copy of GTA:LCS to get from the OR 2.8 version of the PSP firmware back down to the Homebrew friendly 1.50.

Whilst trying to find something useful and interesting to do with my new old-skool style PSP I stumbled across the OE (Open Edition) custom versions of the OR firmware, released by a chap with the moniker Dark Alex.
I’m now running his 3.10OE-a release which enables a number of cool things i’ve found and a number of cool things I *think* it can do :D.

The actual upgrade process was simple, the hardest part was getting the right information and the right versions of the s/w. A lot of forum jumping and post trawling was involved, unfortunately most of the good information was buried amongst, people I assume are under the age of 15, writing “cud u pls hlp me make my PSP play copied games cuz i dont no how” – damn that kind of writing really is one of my biggest hates.. (Not to say that I am a Shakespearean literary genius.)

Disclaimer – If you brick your PSP it’s not my fault, just enjoying having the best paper-weight in your office.

Firstly, I couldn’t run the upgrade until my battery was fully charged – Even though it was connected to the PSU. Annoying.

*Stops*

Ok, I found the info that I was about to type up online already. This would have been helpful yesterday!!

After downgrading to 1.50, follow the guide below.
NB. I didn’t know about the motherboard limitation whereby later versions of PSP are hardcoded not to accept firmware lower than 2.0.. There is a link to a downgrader for this issue too but I did not need it.. (I have one of the earliest Jap import models :D)

http://www.gamerspress.com/index.php?title=3.10_OE-A_Install_Guide

I wonder if it’s possible to run *nix on a PSP yet….

Halfway up the down

Following this item on BBC news, I decided to go ahead and attempt this homebrew stuff.

Every since I got my PSP, i’ve always kept the firmware up to date – for no other reason than I like having the latest and greatest. I don’t know why.

So, after following the instructions HERE I’m back down from 3.x firmware to a 1.5.

Now just need to work out what to do with it!!

Versioning a web development project

This week, i’ve been trying to get my head around workflow using SVN.
As i’ve mentioned before, i have a Ruby/Rails project on the go at the moment and at the start I decided to use SVN for version control – Mostly because DreamHost provide SVN as a one-click-setup job.
Here is a list of what I wanted to achieve, in order:

1. Backup in case I lose my local working copy.
2. Automatic publishing to webserver.
3. A nice way to track changes throughout the project.
4. Be able to publish the changes dynamically to a webpage.

I use TortoiseSVN on my XP installation to manage my working copy.
The first requirement was easy to achieve, so long as I check in regularly I have a nice shiny copy on the SVN server (obviously).
The second was fairly simple. I just checked out the latest version to the root directory for the webserver and run “SVN update” when I want to refresh it.

When I started, I didn’t really have much comprehension of source control from a developer perspective so I just had the root of the SVN repository as my working copy.
I have since read up a bit, taking in the concept of trunk, branches and tags.
Today I spent a couple of hours working out how my folder structure should be and moving everything around using TortoiseSVN to the following structure:

http://U.R.L/ProjectName/trunk
http://U.R.L/ProjectName/branches
http://U.R.L/ProjectName/tags

I also changed the web version to use the latest release version using SVN switch %URL_TO_RELEASE_VERSION_IN_TAGS_FOLDER%.

My idea of the workflow is that I make changes to the working copy (a subfolder of branches, i.e /branches/0.1.x) and check in as required.
Once I am happy with the changes, I transfer the changes to the /trunk/ version which can then be accessed via the web for any remote testing I may rope people into.
Once the trunk version has been tested against I can go ahead and make a copy of that into the tags version as the next release, do a SVN switch in the web directory and all is done (along with any config changes to the app’s db of course).

I’m not sure if that is a ‘best practice’ way of running an SVN linked project but it makes sense to me and would seem to work out in an environment where there was more than one developer working on it.

Like I said, it makes sense to me but maybe I have missed the point and made some fundemental error somewhere?
For example, I still don’t get the ‘Patch’ part of SVN, would it be possible to just update the web directory using a patch from the latest release rather than running SVN update?

I’ve also been looking been looking into a product called Trac which appears to be a good project management/defect tracking application, anyone had any dealings with it? From research it looks like a pain in the ass to install (to Dreamhost at least)

Crash!

Although i’m some kind of specialist in the MS area i’m no fan boy – check out how many times i’ve mentioned replacing my lappy with a Mac. However, I found the following statistics pretty interesting considering the slating Windows gets about it’s stability (i’m not talking security here, just stability). Just for the record, i’m of the opinion that the stability and reliability of a server (be it Windows, *nix or whatever) is a reflection of the admin responsible for it :p

Causes of BSODs:

Microsoft Code 5%
Hardware (memory, disk etc) 10%
Unknown (crash too corrupt for analysis) 15%
3rd party device drivers 70%

Data taken from MS’s analysis of the crash dumps for XP submitted to Microsoft OCA in April 2004.

Nice boys don’t play rock’n’roll

I got to Alcatraz this time around, it’s probably the best ‘audio-tour’ thing i’ve been on.  Of course the views on the ferry to and from were great also.

Most of the week was, understandably, tied up with work.  Some good presentations during the day, and a days course on Product Management MRD (Requirements That Work) which really was excellent.  The instructor had some awesome anecdotes (true or not) that really got you thinking about the requirements process.  For example,  take the zero gravity space pen.  Legend has it that after they discovered that the bog standard ball point pen wouldn’t work in zero G environments, NASA spent millions of dollars developing the aforementioned space pen.  Of course, when you look back at the potential product goals and use case (enable astronaut to write in space),  it is penned that the Russian Cosmonauts simply used a pencil.  An example of over thinking?  Maybe…

On the day I had free and after hitting Alcatraz, a colleague and I hired a couple of mopeds and spent 5 or so hours cruising around the city,  There is a handily signposted ‘scenic drive’ around that takes you past the obvious places (Fishermans Wharf, Golden Gate Bridge) and out to the not so obvious (names escape me now).
I also managed to go to the late-opening Apple store about 4 times in the week, further tempting myself with the Macbook…  I held strong, I’ve still got a feeling about an announcement this month..

Finally, the Wednesday evening 5 of us hired out a practice room and some equipment (drums, keys, bass, axes, mics, amps..) and had ourselves a wicked little jam session.  None of us having played together before, it was none too shabby.  Belting out such classics as Hold The Line (Toto), Run To You (Bryan Adams), Paradise City (GnR) and also a sweet rendition of Bohemian Rhapsody, intertwined with some ‘freestyle’ 12 bar blues and failed attempts at other tracks (Sweet Emotion, Don’t Fear The Reaper).