wiffu

Title: Practical Rails Social Networking Sites
Author: Alan Bradburne
ISBN: 1590598415
ISBN-13: 9781590598412
421 pages
Published: Jun 2007

So far my web development background has mainly consisted of Java (J2EE) and PHP. I just started playing with Ruby and now Ruby on Rails. I’ve worked through a few of the tutorials linked from www.rubyonrails.org. So essentially I had two or three ‘proof of concept’ sites with models consisting of two to three tables each. So of course at that point I wanted to ramp it up and build a ‘real’ site but that leap from demo site to a production ready, real world site can be a tough one to make. “Practical Rails Social Networking Sites” can certainly help you in that undertaking.

During the span of the book, Alan leads you through building an actual web application with many of the Web 2.0 features you would expect. When you are through with this book, you will have a simple “content management system”, user authentication with groups, RSS feeds, blogging with an API and user created themes, forums, photo gallery with tagging, email and mailing list, XFN support, Google maps and Flickr API integration, and views for mobile devices. So, as you can see, you learn how to build just about everything a social site needs. The author does a good job of using leading edge features of Rails and web development in general to build the components for the site. One that I was very happy to see was REST or “Representational State Transfer”. Rails Restful Routes are used throughout the book and you soon learn to appreciate them as they further simplify the routing of requests from the view, through the controller, and to the model.

For the most part the end of each chapter has a substantial section devoted to testing what was implemented previously in the chapter. I was good to see this emphasis on unit and functional testing as I know what value it brings to the scalability and maintainability of an application. Plus it is so easy to write tests in Rails, there is little excuse not to do so.

After you’ve worked through the examples in the book and have a substantial, working social web app, the final chapter will lead you through the process of deploying your work to a production environment. This chapter is compact but certainly gets you enough info and pointers to get you deployed and into a strategy for scaling and optimizing.

• You may not travel faster than the speed of light
• You may not power on a virtual machine in a virtual machine

As a freelance Web Developer, I often find myself this circumstance.
Client X states…

“We can allow you access to our network but only through your single dedicated IP“

I won’t go into how ‘un’-realword this is in this day and age (what freelance coder always works behind a single IP?). I tend to work from coffee shops and at home I prefer (cheaper) dynamic ip broadband.

Overview: We will use a ‘trusted’ server we have ssh access to as a ‘proxy’ to connect to the ClientX server. From ClientX’s point of view, it will simply look as though you are connecting directly from the proxy server but you will be able to connect to clientX from any server (through the proxy server).

Step 1:

Give clientX the IP to any “trusted” static IP server you have ssh access to (this will be the proxy server).

Step 2:

The setup

On local, issue this command…

$ ssh -L2001:clientX:22 proxy

You are instructing SSH to encrypt traffic from port 2001 (chosen arbitrarily, you can choose any unprivleged port that is available) on your local computer and send it to port 22 on clientX, using the SSH server on proxy.

Leave this terminal open (where you issue the above command. It will be logged into proxy through ssh).

Now in a new terminal window you can ssh, scp, sftp to clientX by using local port 2001. You can even use your favorite graphical ssh, scp,or sftp client, just point it to localhost and port 2001.

ex:

$ ssh -p2001 user@localhostuser@localhost's password:Last login: Fri Jan 19 17:29:23 2007 from 99.99.180.136[user@clientX user]$ hostnameclientX.com[user@clientX user]$

As you can see, you ssh to localhost port 2001 and end up on clientX

Shown below, you can take your GUI sftp client and point it to localhost and port 2011, after logging in (with your clientX credentials), you will see your files on clientX

To close the connection, disconnect any ssh, scp, or sftp clients then simply type exit in the original terminal where you typed $ ssh -L2001:clientX:22 proxy

Have you ever seen a more pathetic password policy (I’m sure you have but this one is pretty bad). Black-hat hackers must love this if they are able to use brute force type attacks. What poor excuse for a backend can only support passwords in this format?? I never understand why sites don’t allow you to use any (or a VERY limited set) of special characters in you password. Passwords should ALWAYS be hashed (md5, sha, etc…) before persisted so you should be able to use any ’special’ printable character you want. Be wary of the site that can retrieve your actual password!!!

• Passwords must either be 7 or 8 characters in
  length.
• You must use at least one number in your password.
• You must use either the # or $ character in your password.
• You may not use any of your previous (8) eight
  passwords.* If you experience a network or
  printer problem after
  resetting your password using Passport, please shutdown
  and restart your computer.