Archive for September, 2006
September 29, 2006 at 8:29 pm · Filed under General
Many years ago, I used CVS for my personal projects. After that, I used Perforce. The free perforce license for small guys was a good thing, but I didn’t find perforce to be the perfect solution. It had its issues with branching, web support, and other little nits. When subversion was mature, I started using that. After moving to subversion, I thought I had a great solution that had the good features from Perforce (like the atomic commit) with an environment similar to CVS. Oh yeah, I also hated the perfoce ‘edit’ procedure. I should never have to worry about my workspace becoming inconsistent with my scm. CVS and Subversion are very good about that.
So back to the story. I’m using subversion at work and I had to do some branching and I was about to do a merge. I had never done one so I read up about it.
Wow. What a let down. They really didn’t have a solution for that. Essentially, you, the programmer, have to keep track of the last items you previously merged! You would think in the era of gigahertz cpus and gigabytes of storage that saving this information wouldn’t be a hard problem.
This prompted me to research the SCM space again. It’s actually an interesting space. Recently (the last 5-6 years), there have been a lot of alternative and interesting SCM systems developed and released. One of the ones that a bunch of friends use is darcs. darcs is written in Haskell and it allows the developer to treat every workspace as a repository. Steve thinks it works well for him, but acknowledges issues… especially performance. I was considering reading more about it and possibly switching over when I stumbled upon a different solution.
SVK
svk is a tool written on top of the subversion storage system. It is written in Perl and it delivers distributed/disconnected development (like darcs and a few others), and a smarter merge (like GNU arch). It even does this without having to get rid of your existing subversion repository, which is very nice! There are already a lot of tools that work with subversion so keeping that investment makes the decision easy.
Did I mention that the merge is smart! 
It’s called smerge and it is much easier to use than the subversion merge.
So after doing a lot of research, I started noticing that various tech bloggers had good things to say about svk. There are also some decent tutorials on the net as well.
So…. I decided to try it out. They have Windows binaries that install easy on the main site. I followed the example usage documents and tried it out. Here is what I learned:
The software is quality work. All commands and operations had help and functioned correctly.
ALWAYS use a local branch for smerge, push, pull operations - and always use ‘-C’ to see what it would do. I made a mistake and pushed a merge the wrong way (from dev to release). I was also using a non-local branch (ie. a mirror) for the operation and I was online. The net-net was that I pushed the wrong code and it got propagated live to the main subversion repo. I had to spend a lot of time fixing this. NOTE, this was really a user-error, not a flaw in svk design. They tell you to use a local branch because everything is geared towards using local branches. Also, doing things with the trunk tend to not work the way you would expect. svk assumes you are on a branch since the branch has a known spot where it forked from the tree, whereas the ‘trunk’ does not.
After I used it for a day, I find that I like the way it works better than subversion. The merges worked and I was more productive with the mirrors setup. I’m also pulling in more mirrors since I have more than one repo that I’m using.
OVERALL, I think this is going to be a great new tool for the toolbox and I highly recommend it.
September 29, 2006 at 8:02 pm · Filed under Computers, General
In the 80’s we had megahertz speed processors, megabyte sized disks, and kilobit speed wans with megabit lans.
In the 90’s we still had megahertz processors, but gigabyte sized disks, megabit wans and 100 megabit lans. wireless was megabit.
Here we are in the 2000’s and we have gigahertz processors and soon, terabyte sized disks. On the wan side we are in the multiples of megabits still but lans are gigabit. wireless may reach the gigabit with UWB.
We may never have terahertz processor cores.
What will he do with terabyte disks and terabit lans?
September 29, 2006 at 7:49 pm · Filed under General
Jack puts up a link on his blog to a movie that raises questions about the cause of the WTC building collapse. It was too easy, I just clicked and then I was watching, and I couldn’t easily just tune it out.
All I can say is this…
It is worth watching, and there are some interesting questions raised.
September 29, 2006 at 6:19 pm · Filed under Computers, General
To be honest, I prefer a good GUI IDE for development projects. MSVC 6 with Visual Assist X rocks for C++. For the Rails development I do on my windows laptop, however, I just use a combination of Scite, standard Windows explorer, and a cmd window. It isn’t Textmate, but it isn’t bad either. I’ve tried Eclipse, but it usually lets me down. It is confusing to install. It can be confusing to import an existing project. It may not even do what I need. It is too complex to configure. It is also quite large (ie. slow). If it had a new killer feature, I might reconsider it in the future.
Occasionally, though, I need to work on the Unix box that has our code. This means that I need a decent editor under Unix. This means Vim.
Vim is really good at dealing with all the different file types out there and providing support for syntax highlighting as well as proper indentation and completion. Recently, I had to create a .vimrc file in order to edit some code and get the spacing properly set.
Here are some good links for that:
A great page on using VIM for Ruby and Ruby on Rails. Interesting sections on using VIM as and IDE (relevant for other languages as well)
http://wiki.rubyonrails.org/rails/pages/HowtoUseVimWithRails
A nice small blog post on a vimrc
http://www.quotedprintable.com/articles/2005/11/24/vimrc
A nice complicated example
http://www.hermann-uwe.de/files/vimrc
When I setup my vimrc, I always turn off tabs for everything except makefiles. The vimrc is expressive enough to handle conditionals based on the file type involved. For example, here is one of my .vimrc files (I have several similar files on various accounts). Notice how it is setup for Python, but was easy to pull off the necessary differentiation just for ruby.
set nocompatible " We're running Vim, not Vi!
syntax on " Enable syntax highlighting
filetype on " Enable filetype detection
filetype indent on " Enable filetype-specific indenting
filetype plugin on " Enable filetype-specific plugins
set tabstop=4 ” tabs are 4 spaces!
set shiftwidth=4 ” tabs are 4 spaces!
set expandtab
set pastetoggle=
au BufNewFile,BufRead Makefile set noexpandtab
au BufNewFile,BufRead makefile set noexpandtab
colorscheme elflord
augroup ruby
autocmd BufReadPre,FileReadPre *.rb set tabstop=2
autocmd BufReadPre,FileReadPre *.rb set shiftwidth=2
augroup end
September 29, 2006 at 5:51 pm · Filed under General, Ruby and Rails
Fred Hwang pointed to this post by Steve Jones about the problem of the LAMP acronym with Ruby for the language instead of PHP. The problem being that it would be called LAMR.
For those so inclined to drop buzzwords, I think they should call the platform LASR. Just consider the database to be SQL (a compromise between MySQL, Postgresql, and SQLite), and it fits nicely.
September 29, 2006 at 5:40 pm · Filed under General, Ruby and Rails
Quick tip…
When working on a rails project you need to have REAL DATA to work with in your development environment. The easiest way is to grab data from a production database. Ah, but won\’t that require SQL and effort?
The answer is no. Luckily, 99% of the work involving this is done for you. You will not have to code a single bit of SQL to accomplish this.
Here is what we do here:
- Find the extract_fixtures rake task somehwere out on the internet. Check it into your project. Essentially, this gives you a rake task that dumps the environments database into .yml files in your test/fixtures directory. I modified the file so that it creates files with a \’.bak\’ extension in order to avoid destroying an existing fixture.
So, on my production machine, I do the following.
rake extract_fixtures RAILS_ENV=production
Then I copy the resulting files to my development environment. I then change the data to protect the innocent and avoid leaking any sensitive information. Once that is done, I rename the files over their blank/empty/unused fixtures of the same name (for example mv fruit.yml.bak fruit.yml) and check them in.
Once all the fixtures are sufficiently populated, I then do the following on my development workspace:
rake db:fixtures:load
I have just given myself (and every developer on the team) great test data that is also useful for developing new features. It is just too hard to code new features without real data. For example, that bar chart you are working on will not impress anyone when all the bars are at 0.
So, again, a few simple,easy steps and significant improvement on the development cycle for all parties.
September 29, 2006 at 5:29 pm · Filed under General
Quick tip…
When working on a rails project and I need to get a new model up and running, I do the following.
./script/generate model Fruit
That will generate the model files, and most-importantly an empty migration… all in one step. The migration also has the nice side effect of having the appropriate skeleton of the model already inside (less typing, better consistency == good)
I then edit the migration and run it to generate the necessary modifications to the database. For example, not only will I create the columns for the Fruit object, I may add some columns to another table (Cakes ?) to refer to instances of this new model.
rake migrate
Now, once this is done, I have the model, and the tables ready in the database. The next part is to add the scaffolding.
./script/generate scaffold Fruit \'admin/fruit\'
This will create the controller and view skeleton code that will facilitate the basic CRUD operations.
DONE
For all of this to work, you didn\’t have to do anything but pick a name for the model and choose the fields.
So here is the summary… simple, no?
./script/generate model Fruit
rake migrate
./script/generate scaffold Fruit \'admin/fruit\'
September 29, 2006 at 5:14 pm · Filed under General
Now that I’m fully embedded in the advertising industry, I’m noticing how much improvement can be done.
For example, Expedia sends me lots of emails. The most recent one tells me about travel deals to San Francisco. Uh, they have my address AND my email. Surely they can see that this promotion isn’t relevant.
Next entries »
