This goes for table names, and also for the names of join tables. If you call your tables “user” and “group” then you probably want your linking tables to be “user_group”. If you go for plurals (my personal favourite) then be consistent over whether the linking tables are called “user_groups” or “users_groups”.
I’ve seen two main variations on the column names for primary keys, one is to call them all simply “id”, and the other is to name them after their table name such as “user_id” or “group_id”. It doesn’t really matter but my recommendation is for the latter – that way, the user_id column in any other table clearly joins on to the user_id column in the users table, making it easy to read and understand.
Due to my EXtreme DOuble CApitalitis, I prefer everything to be lower case, but the key is consistency, so that it is easy for developers to get used to the patterns in the database setup and to develop against your schema without having to refer back to it all the time.
In general, I like database schemas which are predictable and well-laid-out. Although I have my own preferred conventions, I don’t mind what is used so long as it is predominantly in step with itself – this makes my life as a developer so much easier! What’s your top tip for sane database naming conventions? Leave a comment and let me know!
In fact, all I had to do was update my upstream remote on my local repo – I set this up following the excellent github forking instructions when I first forked the repo. All I did then was to check my remotes:
git remote
This showed my remotes with the “upstream” pointing to the old repo. So I copied the URL of the organization repo, removed the old version and added a new upstream:
git remote rm upstream
git remote add upstream git://github.com/joindin/joind.in.git
Everything now behaves as before while handling the new central repo for the project – hopefully this helps others with projects moving from user accounts to organizations (or organisations, as I keep typing, British spellings as always!)
I am a wordpress user and even wrote a plugin once, but I’m an outsider in terms of community so I was looking forward to finding out more about the people involved with wordpress. I expected to meet some friendly folk and I was not disappointed at all – there was a wonderful range of people there, right from people wanting to start a blog to people making a living from wordpress development, and everyone in between. I attended talks on testing the internals of wordpress through to some case studies of sites built using it (thanks @simonwheatley) as well as sessions on plugins, business, and web technologies.
My biggest thankyou of the weekend goes to the Genius @pgibbs who took the time to reply to my tweet-appeal for someone to review my wordpress plugin and spent a good chunk of his afternoon wading through my newbie code – I got loads of great pointers, thanks Paul!
The event ended on a slightly contraversial note with some input from the Automattic people who had come over to attend the event – they’re putting a lot of work into improving the support for the communities running the WordCamps, which should have been good news, but one of the things that will change is that there’s a move away from having WordCamp
edit: I forgot to say I made a particular new friend, @apeei – you can see us here
This is the easy bit:
$ git branch
* api
master
$
The entry with the star next to it is the current branch, so here you can see that I have branches “master” and “api” and I’m currently working on the “api” branch. If you only have one branch it will usually be called “master”.
My experience is with Subversion until now, and branching is really different in git (because it actually has branches rather than just copies, this is definitely a feature, but it is a different approach from how I had used them before). So you can switch your working copy around to look at different branches, which threw me a bit to begin with. To change branches, just checkout the one you want:
$ git checkout master
Switched to branch 'master'
$
If you actually wanted a new branch simply name it and ask checkout to create it if it doesn’t exist, by using the -b switch:
$ git checkout -b demo
Switched to a new branch 'demo'
$
So now my branch command shows me this:
$ git branch
api
* demo
master
$
This is very much an optional step. Many of my branches are private branches – meaning that I branch on the development server, finish the feature at hand, and then merge the changes into my master branch without pushing the branch to anywhere else. To share changes with others though, I sometimes like to push my changes up to github – which is my “origin” remote on my repo. So to push the demo branch we just made, I would simply do:
$git push origin demo
Total 0 (delta 0), reused 0 (delta 0)
To [email protected]:lornajane/joind.in.git
* [new branch] demo -> demo
$
If you use “git push” on its own, it will push all branches which exist on both the local repo and the origin – but will not push any private branches unless you specify that it should.
The http://help.github.com site, Github’s own documentation, is actually brilliant and has really helped me to get up to speed with working with my own code and contributions from others.
* The only problem I’ve had with code on github recently is that I merged totally the wrong changeset into the main project root. Which really isn’t the fault of the source control system :)
/alertsoff
The / lets skype know its a command – much like IRC! There’s a full list I found on Skype’s support site, very handy :)
To set the scene – I’m hosting the Dutch PHP Conference this week and there’s a LOT of information to keep track of. Between tweets using the hashtag, people tweeting either my username or any of the conference twitter accounts, the schedule itself which will change as we’re having a no-prior-scheduling uncon, and the event and talk-related comments coming in via joind.in itself, its quite a bit of stuff to track. Add into the mix the fact that my iphone’s data package will be too expensive to use in NL and although I will have a phone with a data package it wont’ be mine and there’s no guarantee exactly what it will be. Oh and conference wireless, which last year wasn’t bad at DPC but you have to assume there’s a bottleneck.
So I figured that since I have a fast production server with lots of spare resource, it can do the hard work on processing the feeds, and just serve me a basic page with everything on and some internal hyperlinks to get around. So I wrote this monster, which runs a bunch of twitter searches and pulls in schedule and comments from joind.in, and that was good.
Except, it does take quite a long time to run (well, a few seconds, but that’s too long in my book) so I thought about caching each result set in memcache, and writing a cron job to repopulate those regularly, so every time I hit the script, the cache would be warm. Then I realised I was overcomplicating the matter, and simply wrote a cron job to run my php script and pipe the output to a static HTML file every minute! Whenever I hit the page, I’ll get the latest version. It doesn’t scale but it doesn’t need to, its only for me to use for a few days! Here’s the cron job:
* * * * * php -f /path/to/generate.php > /path/to/index.html
Job done! (the actual page I made is/ here if anyone is inquisitive)
I’ve now had the machine more than 18 months and I’ve been using it for events and keeping it by the bed pretty much ever since. However this year I’m speaking at TEK-X in Chicago and found myself wondering if I should get a new little machine to take with me. A few months back I upgraded the RAM in the machine (it had 512 MB originally!), and I came to the conclusion that actually, I didn’t need to splash out for a new netbook since with a bit more memory, its pretty usable.
Instead of replacing the machine, I bought the extended battery for the aspireone, taking me from about 2 hours to about 6 (I think, haven’t tried this battery life in anger yet). Its chunky, but not offensive:
It is quite a bit heavier than the old one – my original post about getting the aspireone weighed it with its original battery at 971g and with the extended battery, its 1274g, which is still only half the weight of my current work laptop.
Reading back to that original post about the netbook it was pretty obvious that I was hating that operating system. A couple of years ago, the support for aspireone in Ubuntu Netbook Remix became usable, and I installed that. Its been fabulous and I had no intention to do anything more than upgrade … until someone at OggCamp showed me they had the Kubuntu Netbook edition on their netbook.
It is shiny and blue, and since I use KDE on my laptop I couldn’t resist and I upgraded it with a week to go before I take it as my only machine as a speaker at a conference!
I haven’t spent a lot of money on the upgrades, the battery was about 50 GBP and the RAM came out of something else. I did have a large capacity SD card in the expansion slot since I only have 8GB hard drive. Then there was a problem with the machine suspending with the expansion slot in use and at around the same time I got a camera that takes SD … so I put my big card into there instead :) I don’t keep data on the netbook so its not an issue for me. I’ll be flying to Chicago for Tek in a few days, and presenting off my netbook as usual. For a budget machine with a little bit of love and attention added in, “Merry” (short for Merope) the netbook has been quite a fabulous investment!
I spoke again this year, it seemed to me like since there was voting on the talks, if my talk wouldn’t be a good fit then I wouldn’t get a slot! So I did put in a talk about source control; a topic that I’ll be speaking on in a couple of weeks at TEK-X in Chicago and one that I still feel a little bit wobbly about. Taking the main stage to give a hastily-reduced version of the talk to such a well qualified audience and coming off the stage to feel like it went OK was an excellent preparation for my next speaking event and I got chatting to all sorts of people while I was there. I’m not really a linux nut but I do have ubuntu or kubuntu installed on everything, and it was great to hear a bit more about so many aspects of technology that I use but don’t know much about.
The event ended in the traditional live podcast with all the presenters of Linux Outlaws and the Ubuntu UK Podcast all on stage at once. This is always good fun and there were some laughs from the crowd as always.
All in all, a great event, and I’m very much looking forward to next year’s!
Some time ago I blogged about starting to use bzr-svn but its taken me a while to get past those first steps. Having the repo locally is so fast to use, and the speedy diff and log functionality had me completely sold straight away. I’ve been mildly annoyed by bzr squashing my commits though, meaning that I’m still doing a single monster commit to subversion when I come back online after being gone for a few days.
Today, with some help from the very lovely people in the #bzr channel on freenode, I found out how to preserve my commit history when sending the changes back to subversion from bzr-svn. The bzr-svn user guide recommends a particular set of commands, but this includes merging your changes into the mirror of SVN. Even in a standard bzr branch, this would show in the logs as a single, combined commit.
The key to retaining the commit history is to push changes from the branch, rather than merging into the trunk mirror. To make this clearer, I’ve shown an example. The SVN is checked out into lorna-trunk and I’m making changes in the lorna-branch directory, including adding the db directory and the hello.php file.
$ bzr commit -m "initialising database files and hello.php"
Committing to: /home/lorna/data/personal/publish/tek10/svn_vs_distributed/bzr-svn-example/lorna-repo/lorna-branch/
added db
added hello.php
added db/setup.sql
Committed revision 2.
$ bzr push ../lorna-trunk/
All changes applied successfully.
Pushed up to revision 2.
No matter how many times you commit, when you push, all your changes will be sent to subversion as individual commits in the same way. This will really help me next time I’m offline for a little while!
Charmingly, while answering my questions to get me this far, the #bzr channel inhabitants then immediately explained to me that to handle changes in subversion, I’d have to rebase my branch before I could push my changes. This is because you can only push to a branch that is in sync with where yours was when you started making changes. If you try to push to subversion when there are changes in it, you will see this error:
bzr: ERROR: These branches have diverged. See "bzr help diverged-branches" for more information.
All I needed to do was to run bzr update in the mirror, and then rebase my branch onto that. At first my system didn’t recognise the rebase command, but this was because I needed to install the bzr-rebase package (called bzr-rewrite in newer versions but bzr-rebase in mine, Ubuntu 9.10 Karmic Koala). Rebasing was easy to do and brings the changes from the repo into your working branch. Here are the commands and how the output looked for me (with shortened paths to make this more readable):
lorna@taygete:~/.../lorna-branch$ cd ../lorna-trunk/
lorna@taygete:~/.../lorna-trunk$ bzr update
+N readme
All changes applied successfully.
Updated to revision 3.
lorna@taygete:~/.../lorna-trunk$ cd ../lorna-branch/
lorna@taygete:~/.../lorna-branch$ bzr rebase ../lorna-trunk/
All changes applied successfully.
Committing to: /home/lorna/.../lorna-branch/
modified hello.php
Committed revision 4.
lorna@taygete:~/.../lorna-branch$ bzr push ../lorna-trunk/
All changes applied successfully.
Pushed up to revision 4.
I haven’t had a lot of experience with using this in difficult situations with complex branching or conflicts yet, if you have any tips to add though, a comment would be excellent :)