Resources For Rails Development in Vim

While most programming languages seem to take steps toward big, full-featured graphical IDEs, Rails development seems to have gone the reverse: back to the command line, command line editors, and minimalist interfaces. Today, I’d like to share with you several resources that I’ve used to streamline my development process.

TextMate (€39) — Considered the definitive text editor for OS X, TextMate is a worthwhile purchase for any developer using any language. It’s extensible, powerful, and, Rails-specifically, allows for easy navigation between your MVC layers with easy hotkeys. If you code on OS X, you owe it to yourself to buy this.

The Playbook (free/$15/$50) — If you’re looking for tips on how to start a web design firm, set up your development environment, do proper project management, and more, consider picking up a copy of The Playbook, an eBook written by the geniuses at ThoughtBot. ThoughtBot is known for several of their Ruby gems that have been released into the public domain, including high_voltage, clearance, suspenders, and more. They are also known for some of their hugely popular applications, including Airbrake and Trajectory. They offer a few free snippets, a single user license, and a group license.

Rails.vim (free) — While Vim is an amazing editor on its own, it thankfully allows for plugins to be written to extend the functionality. Written by Tim Pope (Twitter/GitHub), Rails.vim is an amazing plugin that adds a whole host of commands to the editor, allowing for more fluid Rails development. Best of all, it’s free, open source, and readily available on our favourite source control repository, GitHub.

Vim for Rails Developers ($15/$50) — Vim is considered one of the most powerful text editors out there, and it’s available on virtually every platform. That being said, it’s a dauntingly steep learning curve (although I wrote a guide on getting started with it), and every bit of help you can get is worth it. This 34 minute video gives you the rundown of using rails.vim along with your Vim install. As with The Playbook, a single user and group license is available.

RailsCasts (free/$9 per mo) — Probably the go-to for most Rails podcasts, Ryan Bates (Twitter/GitHub) has been churning out 2 podcasts about Ruby on Rails for years now. He explains topics clearly, pushes the limits of what gems can do, and always offers comparisons between similar gems. Most of his content is free, but Pro users ($9/month) get access to Pro episodes which cover more content and new gems.

I’m Back

Well, it’s been a while since I’ve posted; about three weeks, actually. To the one or two readers I have, my apologies that you don’t have something to waste your time on twice per week. I’m getting back into the writing mood, so I should be building up a buffer of things to write in the near future.

A lot has happened since I last talked about the IPAM presentation that I took part in. To start with the related topic, I was approached to do the presentation again, this time internally to other departments. Thus, the other co-op student and I set about cleaning up the presentation a bit, fixing some errors, and making it flow smoother. It went much better the second time, thankfully, both from a public speaking perspective and a demonstration perspective. As fun as it was to work on that, I’m glad it’s over and done with right now.

Speaking of work, the number of days that I have left at IPC are dwindling quickly as the new year approaches. I work until December 31st, at which point I’m back in class. It’s been a fun past couple of months, and the paychecks have been very nice, but I’m also looking forward to getting back on campus to get some more studying done. I’ve decided that I won’t get a job during the winter semester so I can concentrate on my studying; I’ll have more than enough money to get through four months, and then I’ll be working in the summer again.

After that presentation was done with at work, I found that I had a fair amount of spare time, as there weren’t too many tasks to work on. I spent that time learning Ruby on Rails, and putting that knowledge towards the new UMSwing site. Although on the outside it will look almost the same as before, this new site will have an extensive backend that will make UMSwing virtually paperless. Although you may not think we use that much paper, think again; I have a full 3″ 3-ring binder in our office that says otherwise. All of our memberships, attendance, and transactions will be tracked on the web application, thus eliminating the need for those pieces of paper to be printed in the first place. Anyways, I’ve been working very hard on the site, and it’s almost ready to be tested by some other people. So, if you’re interested in testing some software for an eco-friendly cause, let me know in the comments section and I’ll keep you informed.

That’s a quick update on what’s happened in the past few weeks at work. I have a few more updates to spew out in the coming days, one of them involving my server upgrade (*cough* RAID *cough*), and some involving some extra-curricular activities (including some new photos to go up soon).

GNU Screen and Byobu Made Easy

For the *nix elitist, no graphical tool comes close to the power that the command line provides. While this may strike some people as odd, particularly those who only have experience with Windows, it’s a pretty well known fact that the Linux command line provides a method of controlling every aspect of your computer activity; this is so much the case that most GUI applications on Linux are just command line “wrappers”, hiding you from what’s actually happening behind the scenes.

GNU ScreenWhile this is all fine and dandy, things like development and multi-tasking can prove to be a little frustrating when connecting to a remote location and requiring more than one window open. Although a typical command line pretty much prevents this from happening, using GNU Screen or Byobu can make things a lot smoother. One window, multiple command lines.

As most developers will tell you, having multiple windows available to you is a godsend. It’s particularly useful when you have scripts to run in the background that generate output, but you don’t want to fork them as a daemon. Now, with GNU Screen and Byobu, you can do this easily, and even make your screen look snazzy as well. The only drawback to these utilities is that they are a little hard to get used to. In this post, I will quickly outline some of the key combinations which I use regularly.

GNU Screen and Byobu Simplified

The number one thing to remember about every command you use is Ctrl+A, which will be written as C-a. This is picked up by screen and will tell the utility that the next characters typed will be commands for screen to interpret. Keeping in mind that all keys are case-sensitive (as most things are in Linux), take a look at some of the commands below:

C-a c - Create a new screen window

C-a A - Rename the screen

C-a C-a - Go back to the previous window

C-a <0-9> - Switch to screen #0-9 (quick toggle)

C-a " - View a list of the current screens, which will allow you to select one from the list

C-a ' - Enter a screen number to switch to (slower version of C-a <0-9>)

C-a d - Detach the whole screen session and fork to the background. Very useful for remote sessions you want to leave open. The command "screen -r" will resume your screen session.

C-a <Escape> - Scroll up through your command line "history" and see what output you previously got. Hitting <Escape> again cancels it.

With the introduction of Byobu in Ubuntu 9.10, you can also get some statistics added to the bottom of your command line window to help keep you informed about the state of the system you are running on. Hitting F9 in session will bring up the menu for customization, which can make your screen session look pretty awesome. Instead of using screen to start your screen session, simply use byobu instead. Easy as pie.

If you have any questions about GNU Screen or Byobu, let me know and I’ll see what I can do to answer them. Stay tuned on Friday for another issue of “Five Things” (hopefully).

Going Open Source

The first time I wrote a full website, I made a lot of mistakes. A LOT.

Although not completely obvious from looking at it on the outside, H2H Security Group is built on a pretty shoddy content management system (CMS). There are bugs, there are incomplete sections of the site, and there is little administration that doesn’t require direct database access. I’ve stopped development on the current CMS and decided to go for a complete overhaul. That’s right: I’m completely re-building the system, H2H CMS, from the ground up.

Normally, this would be a preposterous idea, and perhaps it’s not the most efficient route for me to take, but I won’t be walking away from the CMS empty handed. It was an amazing experience working on it. Despite it being terribly designed, I’ve grown a lot as a programmer since I first started. I’ve learned about things like classes, hierarchies, debugging tools, exceptions, mysqli, more advanced MySQL statements, and caching. I’ve learned about the differences between versions of software such as PHP, which had monumental changes from PHP4 to PHP5. Most importantly, I learned proper software development in a university course. Looking back, every mistake I made during the design of the old CMS I have learned from, and I’m willing to make a mistake if it means that I learn from it.

Another big change I’m making is that I am going Open Source: letting anyone take a look at the source code. I’m sticking with a Creative Commons license, which allows anyone to take the code, modify it, and redistribute it for free, providing they give me credit for the original work. I think it’s the right choice to make, sticking with the hacker mentality and whatnot. With a goal of distributing knowledge and information to the masses, I think the open source route is a logical step to achieving that.

I started off the development of the new CMS quite differently than before; rather than jumping straight into the coding, I started off old-school: with a pen and paper. Design before development helped ensure everything stayed organized this time. Developing class-by-class, piece by piece allowed for logical places to start and stop work.

The part about this CMS that I am most proud of, however, is that security is added and implemented standard – not as an afterthought. Being interested in security, this seemed like a no-brainer, but it seemed to be either non-existant, poorly implemented, or at the expense of efficiency in other systems available. By considering both security and efficiency at the same time, I hope to develop a system that maintains both equally.

I always like to see people become involved in my projects. If someone is interested in helping with the development, let me know, and maybe something can be arranged.

Ohloh Page:

Project Trac Page:

Meat In A Tin

Over the past week or so, I’ve found that one of my other websites, H2H Security Group, has been getting a lot of spam. Unfortunately, it’s not just the random ads from bots. Bots I can deal with, and it’s unlikely that they’ll ever get past registration because there’s a reCAPTCHA in the registration. No, I have to deal with credit card spam.

Most people I know get spam in their email; it happens to almost all of us if we have a presence on the web with that email address. If any of you have read the spam before, usually it’s just a random string of words with a few links in them. Heck, some of them are just downright amusing. But credit card spam is more of a problem; not only is a nuisance, but it’s highly illegal. Not something that you want on a legitimate website.

The first problem was determining if the spam was automated (ie. from a bot), or a person who was posting the spam. The easiest way to do this was to install the reCAPTCHA system as I mentioned above. If you’ve signed up for any major service recently, chances are you’ve encountered a CAPTCHA of some sort. CAPTCHAs are the images with random numbers and letters which is supposed to be hard to read by an automated system, but fairly easy for a human. They are specifically designed to prevent bots from accessing the system. Although the reCAPTCHA system I installed stopped some of the spam, it didn’t stop all of it.

Stopping spam requires ruling your web site with an iron fist. Some automated scripts will help minimize it, but on a long enough timeline, spam will get through. It’s bound to happen. Currently the only way I’ve found to stop the spam is to start blocking IP addresses. In the case of this incident, I was forced to block an entire subnet of IP addresses. I found that ISP in Vietnam was producing a lot of the spam that I received. Despite numerous emails to their abuse department I found out that they deleted the emails without reading them, and made the decision to block the entire ISP from my web site.

Doing so is a bit of a double-edged knife. On one hand, the spam has stopped since I’ve done this (although I only did this two days ago – let’s see what happens!). On the other hand, I have pretty much cut off an entire country from visiting my site. Granted, the primary language there is not my primary target for my site, but still has the problem of cutting off legitimate users.

Of course, this is not a foolproof solution. There’s no reason that a person on that ISP couldn’t use a proxy to access my site and post more spam, but I’m taking a proactive approach to preventing this spam, and that’s about all one can do. Perhaps an interesting project would be to keep a central repository of known spamming IP addresses so that those IPs could be blocked by many websites around the world, and not just by a single server. Allowing a group of servers who pick up spam regularly to add IPs to the list for a number of days, and then many servers could download a list. It’s maybe something to consider to stop the spread of spam across the world.