Students often ask me for Ruby on Rails books that I could recommend.
There are two Rails books that I recommend:
Agile Web Development wit Rails (if you start with Rails)
Ruby for Rails (once you know Rails)
However, there are some books that are not about Rails, but I think that every Rails programmer should read:
Refactoring - Martin Fowler
This book teaches you what is elegant code and how easily you can change your existing code into something beautiful :) It also teaches many OOP concepts.
The Pragmatic Programmer: From Journeyman to Master - Andrew Hunt and David Thomas
Lots of useful techniques every programmer should know. Testing, debugging, version control etc.
Peopleware - Tom de Marco
It's not technology that matters. It's people. Read it before you start any bigger project.
Death march - Edward Yourdon
Why projects fail. What to ask for before you join a new team.
What other books would you include in this list?
Monday, December 6, 2010
Friday, May 14, 2010
Rails MVC: How to deal with fat models
My presentation on the last DRUG (Wroclaw Ruby User Group, D stands for Dolnoslaskie) about Rails fat models.
I covered some of the techniques we use in our projects:
I covered some of the techniques we use in our projects:
- current_user is never nil
- a class for each user type - User, Guest, Admin, SuperAdmin, Partner
- remove "if" statements from views
- minimize the number of "if" statements in controllers and models
- modules to extract common behavior from models
- one controller action calls only one model method
- in controllers everything goes through current_user
- using custom exceptions for Model - Controller communication
Thursday, April 15, 2010
Greasemonkey as a temporary solution for a rewrite project
We are starting a new project for a client. This client has a suite of websites around their main internet product. Our job is to rewrite one of the existing websites.
The thing is that until we are fully ready with the rewrite we can't release our software for production use. It means that one of the main use cases (scenario which starts on the main product and leads the user with some data to our tool) is not easily possible to be manually testable.
The way the main product brings users to our tool is simple - by using a link with some parameters. We need to parse the parameters and let the user use the imported data.
As a temporary solution we decided to create a simple Greasemonkey script.
In our case we need to replace all the links pointing to the old tool. The links should now point to the new url. Here is the full code we needed:
// ==UserScript==
// // @name url modifier
// // @include http://*.example.com/*
// // ==/UserScript==
//
function replace_import_link(e) {
var href = this.getAttribute("href");
new_href = href.replace("http://example.com/old_tool", "http://example.com/new_tool");
this.setAttribute("href", new_href);
}
var allLinks = document.getElementsByClassName('old_tool_link');
for (var i = 0; i < allLinks.length; i++) {
link = allLinks[i];
link.addEventListener('click', replace_import_link, true)
}
As you see, we create a click event handler in which we replace the existing href attribute.
Possibly, there were other solutions, but this one was quite simple and seems to work fine for us. Having this script, we can test the full importing scenario even though we are not ready for production release yet.
Do you have any other idea how to solve this kind of problems with a rewrite project?
BTW, it's not our first rewrite to Rails :) Our biggest rewrite so far was http://restaurant-kritik.de. Restaurant Kritik was rewritten from PHP to Rails. This time we work on a website which was created using Flash. In both cases we support migrating data from existing databases.
The thing is that until we are fully ready with the rewrite we can't release our software for production use. It means that one of the main use cases (scenario which starts on the main product and leads the user with some data to our tool) is not easily possible to be manually testable.
The way the main product brings users to our tool is simple - by using a link with some parameters. We need to parse the parameters and let the user use the imported data.
As a temporary solution we decided to create a simple Greasemonkey script.
For those of you who don't know what is Greasemonkey - it's a tool which lets your browser change the html code on-the-fly. You write a JavaScript snippet of code which is run as if it was part of the webpage JavaScript.
In our case we need to replace all the links pointing to the old tool. The links should now point to the new url. Here is the full code we needed:
// ==UserScript==
// // @name url modifier
// // @include http://*.example.com/*
// // ==/UserScript==
//
function replace_import_link(e) {
var href = this.getAttribute("href");
new_href = href.replace("http://example.com/old_tool", "http://example.com/new_tool");
this.setAttribute("href", new_href);
}
var allLinks = document.getElementsByClassName('old_tool_link');
for (var i = 0; i < allLinks.length; i++) {
link = allLinks[i];
link.addEventListener('click', replace_import_link, true)
}
As you see, we create a click event handler in which we replace the existing href attribute.
Possibly, there were other solutions, but this one was quite simple and seems to work fine for us. Having this script, we can test the full importing scenario even though we are not ready for production release yet.
Do you have any other idea how to solve this kind of problems with a rewrite project?
Thursday, March 4, 2010
Google Spreadsheet as an admin panel for your web app
Today, I would like to share a story with you. A story which led us to discover a nice and simple technique for building admin panels.
The customer's request
Recently, in one of our projects (e-commerce), we've had the following requirement:
At first it seemed strange to me. Why would we want to edit prices using Excel if it can easily be done using the web admin panel which we created. I asked the customer what's the reason and he came up with a fair argument, that it's much easier to mass-edit prices using formulae or using copy/paste in Excel.
I was convinced at this point, but then Yashke (my teammate) suggested that maybe it's better if we do the same, but with Google Spreadsheets (GS), hopefully saving the time for exporting/importing from Excel. The idea sounded pretty cool, so I asked the customer if it was acceptable and I was given a positive response.
The setup we are trying
As always with this kind of risky situations (new technology) we prepared the simplest solution that could possibly work and exposed it in the admin panel. After some discussions we decided for the following workflow.
As you can see, we're not relying fully on Google Spreadsheets - it's just a tool for editing the data. We still have the traditional web-based admin panel. So the admin logs in to the admin panel and then he can generate a spreadsheet with some data.
This project is not finished yet, but the first feedback is very positive.
The advantages
Our journey with GS started with a single requirement, but over time we discovered many exciting opportunities, like:
The customer's request
Recently, in one of our projects (e-commerce), we've had the following requirement:
In order to edit prices
As an admin
I want to export products to Excel, edit them and upload back
At first it seemed strange to me. Why would we want to edit prices using Excel if it can easily be done using the web admin panel which we created. I asked the customer what's the reason and he came up with a fair argument, that it's much easier to mass-edit prices using formulae or using copy/paste in Excel.
I was convinced at this point, but then Yashke (my teammate) suggested that maybe it's better if we do the same, but with Google Spreadsheets (GS), hopefully saving the time for exporting/importing from Excel. The idea sounded pretty cool, so I asked the customer if it was acceptable and I was given a positive response.
The setup we are trying
As always with this kind of risky situations (new technology) we prepared the simplest solution that could possibly work and exposed it in the admin panel. After some discussions we decided for the following workflow.
- Admin presses "Generate the spreadsheet" in the web admin panel
- Then he goes to the google spreadsheet page
- He edits the prices
- He goes back to the admin panel
- He clicks "import prices"
As you can see, we're not relying fully on Google Spreadsheets - it's just a tool for editing the data. We still have the traditional web-based admin panel. So the admin logs in to the admin panel and then he can generate a spreadsheet with some data.
This project is not finished yet, but the first feedback is very positive.
The advantages
Our journey with GS started with a single requirement, but over time we discovered many exciting opportunities, like:
- mass-editing records
- sorting
- search
- search & replace
- using formulae
- using colors
- charts!
In the project I mentioned above, we use it for the following features:
All of these things would be more difficult if we did it in a traditional web admin panel.
Another thing where Google Spreadsheet could be useful is for rapid prototyping. We already have some code that let us easily take a collection of objects and display them in a worksheet, so reusing it will be very easy.
The drawbacks
There are some drawbacks of course:
1. Speed
- mass-editing prices for product variants (we have about 2000 products, each of them can have more than 300 variants, that's a story for another blog post - how assigning prices can be challenging)
- selecting which products to show on the main page, in what order etc.
- managing other kind of collections, like bestseller products
- displaying orders, so that it can be easily sorted, grouped. It's also useful for any kind of reports.
All of these things would be more difficult if we did it in a traditional web admin panel.
Another thing where Google Spreadsheet could be useful is for rapid prototyping. We already have some code that let us easily take a collection of objects and display them in a worksheet, so reusing it will be very easy.
The drawbacks
There are some drawbacks of course:
1. Speed
Exporting 2000 records to GS takes about 1 minute. The good thing is that they start appearing as soon as you press "Export", so you can see the first rows quickly.
The same problem is with importing. It's slow.
2. Relying on Google
We don't know if Google Spreadsheets will live forever, so relying so hard on it may be risky. We try to keep the GS layer simple, so that at any point we can change the implementation to handle Excel or Resolver One files.
Conclusion
The same problem is with importing. It's slow.
2. Relying on Google
We don't know if Google Spreadsheets will live forever, so relying so hard on it may be risky. We try to keep the GS layer simple, so that at any point we can change the implementation to handle Excel or Resolver One files.
Conclusion
So far, our experience with GS is very positive. As we build many web applications for which the admin panel plays an important role, we already consider using GS in other projects, like social network apps (statistics data) or a web surveys app (collecting and analyzing the survey results).
We use exclusively Rails for our web apps, but the idea of using GS can be applied with any other technology.
Let me know if you have any specific questions regarding the topic of using GS as the admin panel. I will be happy to help you.
Subscribe to:
Posts (Atom)