I originally installed PhpGedView back in 2007. It’s an open source and free web program for managing family trees and based on the universal Gedcom file format commonly used in many genealogical websites and applications. I’ve been using it on and off for several years very successfully – all credit to the open source programmers – with very few problems. However its been on my TODO list to upgrade since maybe 2008. I finally got around to updating it.
At the start of the week I decided to try to collect some information together regarding the Forestry Commissions’ owned woodland and map that data so we can see the scale and find out which ones are locally owned. (Jump to the app here if you’re impatient!).
Having planned to do the work to combine my two previous blogs together, I thought I’d take the opportunity to upgrade to the very latest WordPress 3.0 version, which includes the all new default theme TwentyTen.
This is already a very nice theme – a much improvement over the last default. It’s also very easy to customise to your own preference, for instance you can change the background colour and add a picture to the background and change the header image all with a few clicks of the mouse. It also makes a very nice base theme.
It uses the search function in your new account to list the possible matches (usually just the correct one!). It works this way because the blog names on blogger are rarely the same as in wordpress, but it encourages people to update their links by showing them it’s different. It also displays a helpful message.
You may have seen the program Zoomify, or similar programs like, OpenZoom and DeepZoom, which quickly display large resolution images on websites without large amounts of data being downloaded – only the part which is needed is downloaded. Most of these applications use some kind of plugin to work (e.g. Flash or Silverlight), so I wanted to see if we could create one without any plugin, using only the HTML5 standards.
Just back from a very interesting seminar at the University of Oxford entitled: “Copying the Means of Production to the Proletariat” – yes, that meant little to me too – basically it’s about RepRap – the Replicating Rapid-prototyper (more commonly known as a 3D printer!)
The talk was by Dr Adrian Bowyer from Bath University, who’s been instrumental in building this type of 3D printer. His specific work has been in creating a 3D printer that can effectively print another copy of itself – so one printer can build the next printer. It’s not designed to be 100% printable however as that would mean much of it would have to be glued together rather than bolted as in the photo, which would effectively rule out experiments, improvements and tweaks of the printer. The current design, the “RepRap II: Mendel”, has about 50% printed parts. (I’m not sure I agree with this though, I think many people would be very happy to have a fully, 100% printable (well 99%), 3D printer, they’d be so handy to have. You could print spare parts once it’s running, and if a better one comes along, print the new one and recycle the old one back through)
So that I could test some of the new HTML5 features I put together a new clock design, called the world clock.
HTML 5 is an upcoming standard for the internet, and it has some rather nice features such as the canvas tag. The new standard is currently only in draft but has already been implemented on many browsers such as Opera and Firefox.
I’m not a fan of CSS hacks, they are totally unstable and unpredictable pieces of code, usually built on top of another bug… but… unfortunately the way of the web has made it almost impossible to avoid them – I find myself facing a problem I can’t get around without one.
The problem here is CSS media queries and our old fiend Internet Explorer. Internet Explorer only understands the very basic media types such as: media=”screen” but fails to understand media queries like media=”screen and (min-device-width: 450px)”. When it doesn’t recognise this it simply ignores it – that means whole sections of styles are just ignored, and your pages will look completely different to how they are supposed to.
This post is about folder structures and project management in Subversion.. If you don’t already know what Subversion is check out the previous post: http://blog.akademy.co.uk-tips/2009/09/source-control-beginning-with-subversion/
The folder structure you implement in your repository can have significant impacts on how well your project gets managed, now and in the future. With the right forethought you can implement things like:
- release version tagging,
- multiple simultaneous version releases
- and have code, installers and build systems all in the same place.
Tags – release version tagging
Tagging is the term used to “mark” a certain version of your files as important in some way. Most often this will be to mark public releases of your code, this enables you to go back to that specific version even after other changes and version releases have taken place. In Subversion there is no specific tagging mechanism, instead you simply take a copy of the code as it is at the moment. Now this sounds like it would use a whole lot of memory space but you need to remember that Subversion only ever records the changes between files – a tag will not not have any changes in so is virtually copied for free.
To keep track of all your tags you’ll need somewhere to put them and in subversion this means a folder. So in the top level repository folder have a folder called “Tags”. Lets assume you have another folder called “Main” for now which contains your source, to create a tag you’d just copy it, so type something like:
svn copy file://your-path/TestProj/Main file://your-path/TestProj/tags/release-1.0 --message "1.0"
Branches – multiple simultaneous version releases
To work on multiple versions you’ll need to once again copy the main source code. You might need to work on two different releases if you have two major changes to the code which you want to test separately, or you need to make bug fixes in an old release but don’t want to mix up the new code, or you just want to try an idea but don’t want to mess with the main source.
You’ll need to keep this code separate also so create another folder at the top level of your repository. We’ll call this one “Branches” as you are copying the main code to subsequently change it – it branches away from the main part. Now You’ll just need to copy the main code, so type:
svn copy file://your-path/TestProj/Main file://your-path/TestProj/branches/newtest --message "fixing"
This command is near identical to the tag one. This is because all you are “really” doing is making a folder and copying some files to it.
Main (or Trunk) – code, installers and building
When you read up on subversion you’ll come across the folder “Trunk”. Once again, this is subversion so it’s just a folder, and it’s where you main source is edited from. (It’s called “Trunk”, because it’s where the “Branches” come from!). The above paragraphs have called in “Main”.
I tend to split my main folder into several others to make the full building of a program easier. Typically this will be something like “Source”, “Installers” and “Builder” – “Source” holds things like c++ files, “Installer” will hold the files needed to create an installer, and “Builder” is the files needed to automatically build all the bits into some kind of release, such as a CD; (you might like to add “Content” or “Manuals” or something else to your own). This is very useful when you need to tag something as everything needed to rebuild a specific release will be copied into that tag.
Trunk, Branches, Tags or anything.
Obviously the folders you’ll need will depend on your own project. Don’t be afraid to experiment with your own names and structures – the folders are yours to play with!
A few caveats on changing from “Trunk”, “Branches” and “Tags”
- Some client programs can automatically create tags and branches if you stick to these folder names.
- Much of the documentation will make reference to these folder names.
Up until now I have assumed a single Project in your repository but that’s not the only way to do it. There’s two main ways to store multiple projects in Subversion, each with positives and negatives.
- Create multiple repositories, one for each project.
- Create a single repository with a top level folder for each project.
Multiple repositories, single projects
This is the simplest to manage. Every new project his it’s own repository and is entirely separate from any others.
- You can reduce the impact from a single hardware failure as repositories can be kept on separate hard drives.
- You can backup each project separately, depending on it’s value.
- You can easily give user access to a single project
- User subversion errors limited to a single project.
- Users will need to be created separately for each repository.
- The merging of projects is very difficult.
Single repository, multiple projects
A single repository, with top level folders for each project. Each sub folder has the usual “Trunk”, “Tags” and “Branches” in.
- A single list of users is all that is needed.
- A single, simple, backup procedure.
- Merging of several projects into one is very easy.
- Can mistakenly give access to a user for any project.
- Single hardware failure can wipe out all projects at once. Single backups also at risk.
- A subversion user error in one project can impact all other projects.
There is no right and wrong way to store your folders. It really depends on your use, for instance I use subversion to back up my fiction writing, and it contains no folders just a list of files.
There are some best practices you should consider though, decide how you’ll make taqgs or branches if you’ll need them, and if you are going to use multiple or single project repositories.
However, if you are looking for a quick set up, I’d recommend having a single repository for a project, then a sub folder structure of “Trunk”, “Branches” and “Tags”. In side that Trunk create a folder for each of the different parts you’ll need, although different parts can be added later.
That concludes this blog. A future blog will include subversion clients amongst other things.
PhotoSketch is some nifty software which allows you to creatively edit your photos by adding new parts to them.
As you all you do is make a quick sketch of your scene, label each bit with some text and, seemingly by magic, you sketch is transformed into a unique photo.
It looks like it takes your basic shape and matches them to parts in other photos. I’d imagine the parts have already been labelled inside the photo (maybe by way of GWAP). And then with some real clever pixel matching techniques the parts are embedded in a single photo background. In the above photo you can see the original photos and the sketch on the right with the new automatically created photo on the left.
More information from: