Sunday, March 30, 2014

How to move to Amsterdam

If you are a Perl developer and want to move to Amsterdam to work for Booking.com, it is a good idea to do these first.

I don't work for Booking.com, and I didn't get through the interview. But if I did these things, I would have had a much better chance.

The interview questions, and the suggestions here are based on what is actually being used by Booking.com in production. They use MySQL, and a lot of their code is old and is written in object oriented Perl. So, understanding them and being able to work with them is important.

Practice writing Perl code:
Write object oriented Perl code (not Moose)
Write code to read from large files
Write code to work with MySQL databases
Write code which uses hashes of hashes and other complicated data structures
Write Perl versions of the examples in Programming Pearls

Read these:
Read the Perl FAQ
Read the MySQL documentation
Read Programming Pearls

Learn about the Booking.com business model
Think about the problems they could possibly have, and how you would solve them.

Learn about database design, normalization, denormalization, sharding and anything else related to MySQL performance.

They are always looking for Perl developers. It would help to prepare well and then apply.

All the best!

Monday, March 24, 2014

MySQL commands

To login to mysql without selecting a database
mysql -h hostname -u username -p
(hostname can be an IP addrress)

To create a new database, and user and grant permissions on that database to the new user.
create database moodle;
create user 'moodle'@'localhost' identified by 'password';
grant all privileges on moodle.* to 'moodle'@'localhost';

To run the sql script in the file text_file.sql in the database databasename:
mysql -h hostname -u username databasename -p < text_file.sql

To create a table:
CREATE TABLE categories (
    id        INTEGER PRIMARY KEY AUTO_INCREMENT,
    name    VARCHAR(64) NOT NULL,
    created_on    DATE,
    created_by    INTEGER REFERENCES user(id),
    modified_by    INTEGER REFERENCES user(id),
    modified_on    DATE   
);

How to test creating a new row in the database

A webpage has a form and a 'Create my account' button on it which is used to create a new user.

initial = User.count
click_button "Create my account"
final = User.count
expect(initial).to eq final

Here, User is the resultset, which includes all users.
We didn't fill in any data, and we are clicking the button to submit an empty form. We expect that a new user will not be created.
So the initial count of users should remain unchanged after clicking the "Create my account" button.

To test the case where the User is successfullly created, you fill in all the values, and check that the final count is 1 more than the intial count.

visit signup_path
fill_in "Name",         with: "Example User"
fill_in "Email",        with: "user@example.com"
fill_in "Password",     with: "foobar"
fill_in "Confirmation", with: "foobar"
expect do
  click_button "Create my account"
end.to change(User, :count).by(1)


RSpec allows you to write the first test this way-

expect { click_button "Create my account" }.not_to change(User, :count)

Working with Ruby on Rails

If you make a change to the Gemfile, run bundle install, and remember to restart the server.

bundle install
rails server

rails console
rails console test
rails server --environment=production
rake db:migrate RAILS_ENV=production


When you change a model and add a new column, if you want to use it in your form, you can't just update the view. You have to add the new column name to the whitelist in the controller.

    # Never trust parameters from the scary internet, only allow the white list through.
    def user_params
      params.require(:user).permit(:name, :email, :password, :password_confirmation)
    end

Sunday, March 23, 2014

SQLite Commands

sqlite3 development.sqlite3
sqlite> .tables
sqlite> .schema users
sqlite> select * from users;
sqlite> .quit

Ruby on Rails models

We generate a rails model only once, when we want to create a new table in the database. After that we use migrations to make changes to our tables.


rails generate model User name:string email:string
bundle exec rake db:migrate

bundle exec rake db:rollback

rails console                     # Saves to DB
rails console --sandbox    # Will not save to DB

>> User.new
>> user = User.new(name: "Test One", email: "asdf@asdf.com")     #Create in memory
>> user.save          # Write to DB, returns true on success
>> user.name
>> user.updated_at
>> user2 = User.create(name: "Test two", email: "asdf1@asdf.com")  # Create and write to DB
>> user2.destroy

>> User.find(1)
>> User.find_by(email: "asdf@asdf.com")

>> User.first
>> User.all

>> user.email = "test@one.com"
>> user.save
>> user.reload   # If you don't want to save your changes, and read details from DB

>> user.update_attributes(name: "Testing One", email: "qwer@qwer.com") # write to DB
>> user.update_attribute(:name, "Tester One")

rake test:prepare

rails generate migration add_password_digest_to_users password_digest:string