A day without work is a day without food

Zen saying. Heavy.

Came across this in this great post - The 10 rules of a Zen programmer

Zach Holman gave a great talk recently in which he pretty much summed up my feelings about Ruby in one of his slides;

“Ruby is so fast, I love it so much. Not computationally speaking of course, cos in that sense its slow as f…”

That said, if you’re working with it all day it pays to get it working as fast as you can so here’s some stuff I’ve cobbled together in the hope that it speeds up your dev workflow.

1) Use bundler –pre

If you’re waiting forever for gems to install with bundler, make sure you’re using the new 1.1 rc. Not convinced?

If you want to read up on why it’s so much faster there’s a great write up by Pat Shaughnessy over here

2) Ride the Unicorn

1
2

gem install unicorn
unicorn_rails

I’ve found Unicorn to be a better server for local development compared with mongrel or thin. Works with any Rack based applications too.

3) Make Vhosts config a thing of the past with Pow!!

Pow is a zero-config Rack server for Mac OS X. Have it serving your apps locally in under a minute.

If you’re managing multiple sites (as most devs are) Pow is a useful server to have for Rack and Rails apps. Getting a site set up is as simple as symlinking into a folder and it’s ready to view at foobar.dev

That said, I found it to be a bit of a pain running alongside a local Apache install (for PHP sites) as it screwed with the /etc/hosts. That was until I discovered Powder which gives you some shell commands for getting Pow!! to play nicely with the other servers.

1
2
3
4
5
6
7

gem install powder
powder link # Symlinks the current folder
powder applog # Tails the current application logfile

# My personal favourites
powder up   # Enable pow
powder down # Disable pow

4) Speed up your Rails boot time with Ruby 1.9.3 or 1.9.2-head

My namesake Xavier Shay identified a big win in speeding up how Rails requires files.. The patch subsequently made it into Ruby 1.9.3 and a 1.9.2 patch, but it doesn’t affect the earlier 1.8.7 or Ree. If you haven’t done it already, update using the following commands (assuming you’re using RVM).

1
2
3
4

rvm get head
rvm install 1.9.3
## or
rvm install 1.9.2-head

Enjoy the faster boot times.

5) Speed up all your Gem installations by using your .rvmrc file

RVM can have global settings specified in a .rvmrc file. My preference is to do without the ri and rdoc when I’m installing a gem, as I’m pretty happy being able to either look it up or install when needed. You can do the same with the following commands. First off, create the file in your home folder using your preffered text editor…

1

vi ~/.rvmrc

and here’s what I use to get you started.

1
2
3
4

rvm_gem_options="--no-rdoc --no-ri"
rvm_archflags="-arch x86_64" #useful for avoiding errors with natively
compiled gems
rvm_make_flags="-j 3" # Where 2 is the number of cores + 1

See here about optimising your make builds. It’s not guaranteed to help but it doesn’t hurt either.

6) Save time in development mode with the Active Reload gem

Given that this has made its way into the Rails core now, its fair to say the developer was onto something. Instead of requiring the zillion core files of Rails on every page view in development mode, this Gem cleverly only pulls in the ones that have changed based on their timestamp. You can check out the gem here or just add the following to your Gemfile;

1
2
3

  group :development do
    gem 'active_reload'
  end

and then run bundle. Works really well on big Rails apps like Spree and Radiant.

7) Get a f***ing SSD

Not that it’s strictly a Rails dev thing, but this video from Fastly CEO Artur Bergman presents a “compelling” argument for why you need an SSD in your life.

That’s it for now. Any other suggestions please stick them in a comment or get me on twitter.

There’s always debate about which ecommerce platform is harder/better/faster/stronger, and from experience of Prestashop and Magento I can say they’re both really good for different types of shops. For Forsyths, I developed a Prestashop solution for their Sheet Music department whilst I was working there and it’s been great so far but…

When picking a solution it really pays to do some forward planning and in this case, Prestashop can’t scale up to the kind of multi-store functionality that this music department store needed. That said, it was a lot easier getting a Prestashop store off the ground (I tried both at the start) and it’s served us well. My only gripe is that Prestashop’s module and templating system isn’t flexible enough to make real changes without editing the core – and that screws up future updates. Not what you need for ecommerce purposes.

UPDATE Since writing this, it’s all change with Prestashop v1.5 They’ve had a basic overrides system in place for a while now. Also the new version supports multistore but I haven’t used it, yet…

** Making the switch

Swapping out the products from PS to Mage is pretty straightforward – it’s just a case of a mysql query which maps them into the right fields. As with any Magento import the process is more or less similar;

• Add some dummy data into Magento, using all the fields you’re likely to use
• Export the data as a csv using System > Import/Export > Profiles
• Look at the file in your var/export folder and take a look at the headers

Tip for *nix users working with csv files – in terminal use the following command to save the first two lines to a file;

1

head -n 2 your_csv_file.csv > your_csv_file_head.csv

That’s if your csv file is really big.

** The problem with users

Now the above works fine for most things, but the problem with users lies in the different authentication that both shops use. Magento uses MD5 with a salt on the end, Prestashop uses a ‘Cookie Key’ prefix to the customer password, which is then MD5 encrypted. Anyone who’s looked into MD5 knows that this is a pig – you can’t reverse an MD5 into plain text, therefore you can’t get the original password strings in order to re-encode them (which is actually a good thing…).

** How to fix it

Clearly its impossible to convert from one MD5 hash to another so we have to try something different. Make the following file;

1

(magentoroot)/app/code/local/Mage/Customer/Model/Customer.php

and in it put the following;

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

class Mage_Customer_Model_Customer extends Mage_Core_Model_Abstract
{
/**
* Authenticate customer
*
* @param string $login
* @param string $password
* @return true
* @throws Exception
*/
public function authenticate($login, $password)
{

$this->loadByEmail($login);
if ($this->getConfirmation() && $this->isConfirmationRequired()) {
throw Mage::exception('Mage_Core', Mage::helper('customer')->__('This account is not confirmed.'),
self::EXCEPTION_EMAIL_NOT_CONFIRMED
);
}
if (!$this->validatePassword($password) && !$this->validatePassword('hKvthisisyourgibberishcookiestringfromprestashopCM'.$password)) {
throw Mage::exception('Mage_Core', Mage::helper('customer')->__('Invalid login or password.'),
self::EXCEPTION_INVALID_EMAIL_OR_PASSWORD
);
}
Mage::dispatchEvent('customer_customer_authenticated', array(
'model' => $this,
'password' => $password,
));
return true;
}

//end class
}
}

Notice the random string prepended to the password variable? That’s your cookie string which you’ll find in your Prestashop install here;

1

(prestshop root)/config/settings.inc.php

It’s the line beginning

1

define('_COOKIE_KEY_', 'ThisIsTheBitYouWant...' 

Believe it or not that’s all you need to do. Import your MD5 hashes from Prestashop straight into Magento and it’ll authenticate them as Prestashop would do. I’ll go through the mysql import in another post.