Rails Plugins
This was brought up at #rubyonrails -- someone's idea of the top 11 Rails plugins.
There are a few missing from there:
Technoweenie (Rick Olsen)'s acts_as_authenticated and restful_authentication. These plugins do not tell you how to authenticate anything. Rather, you install the plugin then generate authentication code. From there, you modify it as you see fit.
Technoweenie also wrote attachment_fu
Rather than acts_as_taggable, I use acts_as_taggable_on_steroids, which is based on acts_as_taggable. Neither supports multiple tags per model, and the acts_as_taggable_on_steroids author invited me to write a patch, should I write one.
The largest repository of Rails plugins I've found is located at http://agilewebdevelopment.com/plugins.
How to do http + ssh with Subversion on Windows
First you should install TortoiseSVN and verify it is working.
Then right click on the desktop (or an explorer window) highlight “TortoiseSVN” then click Settings.
Click the “Network” tab
Check the “Enable Proxy Server” box, and in the “Server Address:” field place “localhost” and in the “Port” field place an unused port greater than 1024 (remember this number!). Click “Apply” then “OK”
I recommend Putty Tray and their suite, including their improved version of Pagaent, for reasons that will soon become obvious for the next section.
Open Pageant, then open your keyfile in it.
Continuing on, open up Putty, fill in your server address (make sure SSH is filled in). Then go to Connection -> SSH -> Tunnels. Under “Source Port” place the same number you filled in earlier, and in destination, place the address of your server and port 80, ie: my.server.net:80, Click Add. Go back too the session tab, save and name your connection (don’t want too do this every time).
Click Open.
You should then be able too use TortoiseSVN normally, though remember you will always need the SSH connection running too use it, it will not work otherwise (unless you clear the proxy in the settings).
This is why Putty Tray is so great, you can minimize it too the system tray, and have one less window cluttering your developing environment, until you absolutely need too do something on that command line.
As a ‘best practice’ rule, I have learned too set the background colour on my tunnel window to something other (and obviously not) black, and not use it for much of anything besides tunnels.
Good Luck!
References:
Ruby beautifier
I use jEdit for Ruby on Rails development. I only need three things from it:
- Project Viewer / File tree panel (like on TextMate)
- Search in directory. The "find" command is OK, but the jEdit HyperSearch will take me directly to the line number in the file.
- Autoformatting and autoindenting.
I am not particular to syntax highlighting. I don't need to have integrated SQL, log windows, or Subversion/SVK integration -- I use Tilda, a drop-down Gnome terminal bound to function keys.
jEdit 4.2final does (1) and (2) well. It does not do (3) well. I may get fed up enough to find a new editor soon to work with Ruby on Rails. Now, I can work with the broken autocompletions, but I have difficulty working with the broken autoindents. It looks fine when I see it in jEdit, but the resulting text does not output correctly. Probably because I did not set the indent options properly. Update: Yep, need to set "soft indent" and emulate indents with spaces.
Fortunately, there is a command-line script that will beautify Ruby scripts. It may not work in all the weird cases, but I can bind it to a rake task and apply it to the entire app/ directory.
LightBox
Someone at #rubyonrails mentioned LightBox, a Javascript library for doing in-page popups. It looks nice and gaudy -- I may replace the less flashy in-page popup we have on our Calendar app.
I'd definitely change the style a bit. I can't stand the Web Tweeny-bopper look.
Branching and Merging with SVK
Originally posted on a private mailing list.
Talking with a guy on #ledgersmb, I asked him about how well SVK and SVN worked together. I had previously used SVK for disconnected commits, but had not had the nerve to set up an SVK server.
It turns out, you don't need to set up a SVK server, per se, to take advantage of SVK's branching and merging.
To play with it, I set up a directory with a single file:
test/test.txt
And branched it with
svk cp test test-branch
If I modified test-branch/test.txt I can use svk push inside test-branch, and it will automerge back to test/test.txt
If I modified test/test.txt I can use svk pull inside test-branch and it will automerge modifications from test/
I had an svn client working with, and it was able to update the changes cleanly. I can use svn to do commits against each branches, and SVK handles that no problem. As far as the svn client is working, someone did branching/merging, no problem. This is made possible because SVK stores the merging information inside SVN's revision properties. That's why I don't need a special SVK server, just using SVK as a beefed up SVN client.
Now the next tricky thing was using svn cp test-branch test-svn-branch and playing with that. SVK still enters in merge tickets, but getting changes was no longer a simple svk update. I had to use svk pull at the parent directory to get it to update. For what I want to use this for, I will just have to remember to create branches using svk cp rather than svn cp.
Why bother with all of this stuff? The short time I worked for BankOne, I learned a neat method for releasing software. Changes flows from:
development -> testing -> qa -> production
When I first setup Subversion, I had attempted to do something like that. Commit changes to trunk, and have changes pushed upstream for testing (I skipped Q/A as that was done during testing), then to production. The problem is that Subversion's merging sucked. It sucked because it does not track merging changes.
Having played with this, I can now do something like:
(developer-1, developer-2, developer-3) -> trunk -> testing -> production
Pushing to testing and production would be a simple svk pull
Each developer has their own branches to isolate any potentially destructive changes. The developers do not necessarily need SVK (unless they are doing disconnected commits, such as if they are roaming around with a laptop like I do). This is a good thing, since TortoiseSVN is a known factor, and Windows may or may not play with SVK (written in Perl) very well.
The supervisor or PM would have commit priveledges to trunk, probably by using a different set of passwords, so he would do an svk push inside a developer branch once he makes sure it won't destroy anything. Lastly, all the changes, mistakes, whatever can get versioned, a habit I have similar to hitting "save" all the time. Nightly or continous builds would come off of trunk/testing.
Summary: SVK transparently makes merging as trivial as SVN branching without having to change anything server-side.