В прошлый раз мы кратко познакомились с основными структурами интерпретатора ruby. Сегодня я попробую углубиться в интересующую нас тему. Помимо этого, я буду приводить некоторые разъясняющие примеры, как на языке си, так и на руби.

Как лучше всего практиковать изучения ядра Ruby

Теория это хорошо, но честно говоря лучше практиковать и ошибаться :) По крайней мере в этом деле.

Я расскажу вам о своем workflow:

MacOSX-10.5.8 + Xcode + текстовый редактор + исходники ruby 1.8.7 + установленный по-умолчанию ruby.

1) Подготавливаем файлы

rbdev$ cd path/to/ruby/source
rbdev$ mkdir x
rbdev$ cd x
rbdev$ touch my_ext.c
rbdev$ touch extconf.rb

2) Редактируем extconf.rb
Самый простой вариант того, как должен выглядеть этот файл:

require 'mkmf'
create_makefile("my_ext")

3) Открываем файл нашего расширения (my_ext.c) и заполняем:

#include <stdlib.h>
#include <ruby.h>
#include <stdio.h>
 
void Init_My_Ext(void) {
	// инициализация нашего расширения происходит здесь
	// создадим константу
	VALUE global_const_value = rb_str_new2((char*)"This is my global CONST");
	rb_define_global_const((char*)"MyGlobalConst", global_const_value);
}

4) Компилируем (с правами рута, например)

bash-3.2# ruby extconf.rb
creating Makefile

bash-3.2# make
gcc -I. -I/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/universal-darwin9.0 -I/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/universal-darwin9.0 -I.  -fno-common -arch ppc -arch i386 -Os -pipe -fno-common  -c my_ext.c
cc -arch ppc -arch i386 -pipe -bundle -undefined dynamic_lookup -o my_ext.bundle my_ext.o -L. -L/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib -L. -arch ppc -arch i386    -lruby  -lpthread -ldl -lm 

bash-3.2# make install
/usr/bin/install -c -m 0755 my_ext.bundle /Library/Ruby/Site/1.8/universal-darwin9.0

5) Проверяем наше скомпилированное расширения

bash-3.2# irb
>> require "My_Ext"
=> true
>> MyGlobalConst
=> "This is my global CONST"

Как видите мы успешно создали наше расширение, давайте посмотрим еще один вариант “вскрытия внутренностей” (my_ext.c)

void Init_My_Ext(void) {
	char* my_code = (char*)"puts 100, "Welcome to debugger"";
	rb_eval_string(my_code);
	printf("%sn", (char*) "We can output to irb directly from c-code :D");
}

Irb вывыдет три строки, как и ожидалось:

>> require "My_Ext"
100
Welcome to debugger
We can output to irb directly from c-code :D

Так же легко это делается на системах linux. (Сколько бы я не пытался заставить компилироваться расширения руби на Windows – у меня ничего не получилось)

Освежим память

Весь наш с тобою разговор, читатель, будет проходить вокруг уже знакомых тебе структур, составляющих основу интерпретатора руби.

Давай освежим память и взглянем на них:

struct RBasic {
	unsigned long flags;
	VALUE klass;
};
 
struct RObject {
	struct RBasic basic;
	struct st_table *iv_tbl;
};
 
struct RClass {
	struct RBasic basic;
	struct st_table *iv_tbl;
	struct st_table *m_tbl;
	VALUE super;
};

Как ты уже понял, структуруа RBasic находится внутри структур RClass и RObject.
Я не хочу запутать вас, и попробую привести пример “вложенности” используя руби:

RBasic = Struct.new(:klass)
RObject = Struct.new(:r_basic) 
 
r_basic = RBasic.new(Class)
r_object = RObject.new(r_basic)
 
puts r_object.r_basic.klass # => Class

Из вышеописанного кода понятно, что мы создаем две структуры – RBasic и RObject. RBasic содержит в себе “указатель” на класс. Структура RObject содержит в себе структуру RBasic, которая в свою очередь содержит в себе указатель на класс.

Давайте я легко заменю класс, содержащийся внутри RBasic:

r_basic = RBasic.new(MyCustomClass)
# ...
puts r_object.r_basic.klass # => MyCustomClass

unsigned long VALUE

И так, обрати внимание на строку «VALUE klass» структуры интерпретатора руби(!) struct RBasic.
Если ты читал первую часть моего рассказа, то понял, что это ничто иное как указатель на класс. Но тип переменной VALUE (typedef unsigned long VALUE) используется не только для этого.

VALUE может указывать и на структуры других типов, например RString или RFile.

Как это происходит? Дело в том, что VALUE определен как unsigned long, поэтому мы легко можем хранить внутри этой переменной адрес другой структуры. Для этого нам придётся воспользоваться type-cast’ингом.
Вот тебе небольшой пример того, как можно «кастить»:

#include <stdlib.h>
#include <stdio.h>  
 
struct class { char* name; };  
typedef unsigned long VALUE; 
typedef struct class Class;  
 
int main(void) { 	
// Пример номер один: 	
// ptr объявлен как обычный int, и он будет содержать в себе адрес переменной a,
    
// мы вручную “кастим” адрес переменной a к типу int: 	
    int a = 10; 	
    int ptr = (int)&a;  	
// сначала кастим наш int в указатель на int (int*), а потом достаем значение по адресу 	
    printf("%in", *((int*)ptr) ); // выведет 10  	
 
// Пример номер два: 	
    VALUE object; 	
    Class my; 	
    object = (VALUE)&my; 	
    ((Class*)object) -> name = (char*)"MySuperClass";  	
    printf("%sn", ((Class*)object) -> name ); // выведет "MySuperClass"  }

Но нам не придется мучиться и писать откровенно страшный и непонятный код, создатели руби заранее придумали макросы, для облегчения повседневных задач.

Давайте рассмотрим пример с объектом-строкой:

// макрос
#define RSTRING(obj) (R_CAST(RString)(obj))

Взглянем на структуру RString:

struct RString {
    struct RBasic basic;
    long len;
    char *ptr;
    union {
		long capa;
		VALUE shared;
    } aux;
};

Существуют специальные функции, которые создают объекты разных классов. Например, функция rb_str_new2 создает объект класса String и возвращает указатель на созданный объект:

void Init_My_Ext(void) {
	// создаем простую строку
	char* simple_string = (char*)"My String";
 
	// создаем строку в руби и присваиваем адрес нового объекта переменной my_string
	VALUE my_string = rb_str_new2(simple_string);
 
	// нам не приходится вручную писать type-кастинги, мы просто воспользуемся макросом RSTRING
	printf("%in", RSTRING(my_string) -> len); // выведет длинну строки => 9
 
	/*
	так как структура RString содержит в себе указатель на строку (в нашем случае на simple_string)
	мы легко можем воспользоваться этим %)
	*/
	printf("%sn",RSTRING(my_string) -> ptr); // выведет "My String"
}

Как видите макросы облегчают жизнь, для большего осознания этого приведу пример не-макросного кода:

void Init_My_Ext(void) {
	char* my_c_str = (char*)"MyString";
	VALUE my_rb_str1 = rb_str_new2(my_c_str);
	VALUE my_rb_str2 = rb_str_new2( ((struct RString*)my_rb_str1) -> ptr );
	printf("%sn", (char*)((struct RString*)my_rb_str1) -> ptr);
}

Когда я впервые увидел ruby.h я был полностью шокирован. Теперь я понимаю, что макросы облегчают жизнь, и конечно же ими нужно не пренебрегать, а аккуратно изучать и использовать.

Подведем итог:

VALUE создан для того, чтобы ссылаться на различные R***** структуры. Но это далеко не все,что можно рассказать о VALUE. Я вернусь к этому чуточку позже.

flags

Помимо класса, структура RBasic содержит строку «unsigned long flags». Вы наверно спросите — «Почему не заменять unsigned long flags на VALUE flags?». Дело в том, что создатели руби заранее определились, что будут использовать VALUE только как указатель на структуры R******. К тому же во многих макросах используется определение VALUE, что может вызвать ошибку, если мы подсунем указатель НЕ НА СТРУКТУРУ (а мы все с вами знаем, что сделать это как два пальца ******ть). Думаю в этом нет ничего сложного, немного поработав с исходниками руби и написав несколько расширений вы лучше поймёте о чем идёт речь.

Во-первых, flags содержит в себе тип структуры. (смотрим в наш любимый ruby.h и находим там определения типов структур, например: T_NIL, T_OBJECT, T_STRING, T_CLASS и т.д.)
Во-вторых, flags содержит в себе специальные флаги для интерпрнтатора ruby, о которых я возможно когда-нибудь расскажу (если конечно меня вообще заинтересуют лезть так глубоко)

Попробуем немного поработать с флагами:

void Init_My_Ext(void) {
	// создадим новую строку
	VALUE my_str = rb_str_new2((char*)"Rails rocks!");
 
	if(TYPE(my_str) == T_STRING)
		printf("Yeah, this is stringn");
 
	if(TYPE(my_str) == T_OBJECT)
		printf("OBJECT?n");
}

Выведет только “Yeah, this is string”. Так же мы можем воспользоваться макросом CLASS_OF:

void Init_My_Ext(void) {
	VALUE my_str = rb_str_new2((char*)"Rails rocks!");
 
	if(CLASS_OF(my_str) == rb_cString)
		printf("yeah, this is string-classn");
	if(CLASS_OF(my_str) == rb_cObject)
		printf("yeah, this is object-classn");
}

Выведет только “yeah, this is string-class”.

Посмотрим на определение макроса CLASS_OF:

#define CLASS_OF(v) rb_class_of((VALUE)(v))

затем смотрим в определение функции rb_class_of:

static inline VALUE
#if defined(HAVE_PROTOTYPES)
rb_class_of(VALUE obj)
#else
rb_class_of(obj)
    VALUE obj;
#endif
{
    if (FIXNUM_P(obj)) return rb_cFixnum;
    if (obj == Qnil) return rb_cNilClass;
    if (obj == Qfalse) return rb_cFalseClass;
    if (obj == Qtrue) return rb_cTrueClass;
    if (SYMBOL_P(obj)) return rb_cSymbol;
 
    return RBASIC(obj)->klass;
}

Во-первых нас интересует последняя строка -> “return RBASIC(obj) -> klass”.
Мы уже знаем, что сама по себе структуру RString не содержит никакой информации о своем классе, но она содежит в себе структуру RBasic, которая в свою очередь содержит указатель на класс объекта. Таким образом строка “return RBASIC(obj) -> klass” обращается к структуре basic, находящейся внутри obj и возвращает класс объекта, например rb_cString.

Но почему перед этой строкой стоят какие-то странные условия? А дело все в том, что не каждая структура руби содержит в себе структуру RBasic.
Несмотря на то, что в руби все – объект, классы Symbol, Fixnum, NilClass, FalseClass, TrueClass не содержат внутри себя структуры RBasic. Это сделано для того, чтобы ускорить интерпритатор. Только подумайте, чтобы случилось, если бы на каждое новое число создавалась целая структура.

Небольшой пример на руби:

puts 1.object_id # => 3
puts 1.object_id # => 3
 
puts :text.object_id # => 109858
puts :text.object_id # => 109858
 
puts "Hello, habr".object_id # => 33970
puts "Hello, habr".object_id # => 33950  (!!!)

Сколько бы мы не пытались узнать id объекта Fixnum или Symbol -> мы получаем одно и тоже значение. А вот со строкой все иначе, она создалась два раза. Именно поэтому выгоднее использовать символы, вместо строк, особенно это касается разработчиков ruby on rails ( ну или любого другого софта на руби ):

map.root :controller => :main, :action => :index # отлично
map.root :controller => "main", :action => "index" # не очень хорошо

Что дальше?

В следующей статье я познакомлю вас с ID, более подробно расскажу о работе с числами и объектами класса Symbol. Конечно же весь мой рассказ будет сопровождаться поясняющими примерами на руби и си.

VIM – это сила.

Мало того, что для этого замечательного текстового редактора написали уже более 3-ёх тысяч расширений, так еще и пишутся они достаточно легко. К слову говоря, если полазить по дебрям каталога плагинов, можно найти множество интересных и полезных утилит.

Но сила VIM не только в его расширяемости. VIM сам по себе – очень мощная штука, которую можно настроить как угодно. Именно за это он мне и нравится – я как бы создаю свою рабочую среду. Многие любители “сделай сам” поймут о чем я говорю.

VIM – это новое.

Текстовому редактору VIM и его предку VI гораздо больше лет, чем мне. И не смотря на это, я нашел работу в виме необычной, и могу смело сказать – что это разрыв привычной текстовой обыденности.

Мы привыкли к IDE, привыкли клацать мышкой и выделять фрагменты текста, привыкли, что наша правая рука прыгает от букв к стрелочкам, а потом легким движением оказывается на мышке, и потом снова на стрелочках, а потом опять на буквах клавиатуры. Всё это обыденность.

С VIM вы будете делать всё совершенно иначе. Моя рука всегда в одном положении, я полностью забыл о клавишах-стрелочках и мышке. Они просто не нужны. Я так же смог забыть о клавише CTRL. Мне больше не нужно зажимать мизинцем CTRL SHIFT ALT.

Вим имеет несколько режимов. Основные режимы это Вставка и Normal-mode. В режиме вставки vim ведет себя так же, как и обычные текстовые редакторы. Normal-mode создан для того, чтобы манипулировать текстом.

Вим очень минималистичный, в нём нету красивых кнопок и рамок. Многим не нравиться это, но в действительности это позволяет вам сосредоточиться на тексте, дать тексту больше места, освободив экран от ненужных элементов, к котором вы обращаетесь раз в неделю.

VIM – это вы.

Вы вольны настроить всё так как вам нужно. Не нравиться то, что переход в normal режим происходит по клавише ESC? Это можно легко исправить! Хотите, чтобы цвет фона в режиме вставки был другого цвета? Легко! Хотите, чтобы цветовая схема отличалась в разное время суток? Пожалуйста! Хотите написать своё дополнение? Тогда пишите его на родном Vimscript, или воспользуйтесь Ruby, Python, Tcl, Perl или Lua!

VIM – это расширяемость вашей мечты!

vim на самом деле легко расширять и дополнять. Помимо простейшего встроенного языка программирования Vimscript вы можете воспользоваться своими любимыми языками, вот краткий пример на ruby:

# выведем имя текущего буфера:
VIM::message VIM::Buffer.current.name
# проверим, есть ли в текущем буфере TODO задачи:
buffer_object = VIM::Buffer.current
1.upto(buffer_object.length) do |count|
	if buffer_object[count].match(/TODO/)
		VIM::message "TODO detected! in string number #{count}"
	end
end

Разве это не мечта настоящего хакера? Инструмент, который так легко расширять и дополнять!

VIM – это не так сразу.

Проблема в том, что вам придётся потратить некоторое количество времени на освоение базовых возможностей. Многих отпугивает это, но в действительности, через некоторое время вы получите мощнейший инструмент в своих собственных руках.

А что дальше?

В следующей статье я хочу более подробно рассказать о расширениях, приведя пример простенького расширения на языке руби.

Надеюсь вам понравилось.

Каждому из нас когда-нибудь объясняли ценность английского языка. Не смотря на все это, я не очень-то следовал этому. И конечно пожалел об этом.
Я рад, что смог во время осознать ценность английского языка и начать исправлять плачевную ситуацию.

Сегодня я расскажу вам о том, почему же я начал изучать английский и забросил русский.

Книги

Примерно полтора года назад я спонтанно решил начать “серьезное программирование”. До этого я уже имел небольшой опыт в этой сфере, но на более “простом” языке. Решено – сделано! Я немедленно отправился в книжный магазин и закупился парой учебников на русском языке:

Всегда поражаюсь убогостью оформления русских книг, яркий пример тому – вторая книга. Я бы не показал такую книгу своим друзьям. Так же ужасно я чувствовал себя, когда читал комиксы “Микки-маус”, сидя в метро. Правда тогда мне было около 8, и я очень стыдился, что кто-то заметит этот комикс в моих руках. Но интерес к картинкам победил комплексы юного обывателя.

В тот же вечер я приступил к чтению. Было очень трудно. Оно и не удивительно. Я понимал, что так резко столкнутся с реальным ООП будет тяжело. Но я не сдавался и вдавливал в себя каждую строку. Проблема в том, что я люблю понять всё, прежде чем сказать себе “я могу с этим работать”. Поэтому процесс затянулся.

Через какое-то время я наткнулся на великую и ужасную “Thinking in Java”, а точнее говоря на ее русский вариант:

Это очень хорошая книга, но мне, совсем-совсем зеленому было трудновато. Я и не жаловался. Если я что-то не понимал в одной главе – я находил аналогичную главу в другой книги. Таким образом мне удавалось получить альтернативный вариант изложения материала.

Беда заключалась в том, что я часто замечал, что во время чтения мой мозг отключается. Мне слишком тяжело давались эти термины. Нет, я попробую перефразировать – мне слишком тяжело давалось сочетание “литературно-научного” русского языка. К тому же я являюсь фанатом аналогий.

Аналогии – это здорово. Любую вещь, даже самую сложною, можно объяснить представив более простой аналог. Не понимаю, почему авторы таких сложных книг отказываются от этого приёма.
Иногда мне было трудно понять, для чего же придумали эту вещь. Я не видел причины в ее существовании.

Не смотря на всё это, я справлялся. Читая то одну, то другую, то третью книгу я продолжал изучение Java.
Но я устал.
И совершенно случайно я открыл оригинальный вариант книги “Thinking in Java”.

Я испытал настоящий шок.

Мой английский ужасен, но даже с таким уровнем я понимал каждую строку в 5 раз лучше, чем из русского варианта. Я понял, что английский менее богат на красивые словечки, нежели русский, и эту особенность стоит использовать!

Обучение пошло в РАЗЫ быстрее. Я был действительно счастлив. Я читал книгу на инородном языке и понимал его лучше, чем свой родной.

История с Ruby on Rails

Около года назад я решил изучать фреймворк Ruby on Rails. Я уже знал ruby на очень начальном уровне, достаточном, чтобы манипулировать классами и объектами. Зайдя в книжный магазин я нашел маленькую книжку-руководство:

Я пытался перечитать ее 3 раза! И ни разу я не смог понять, что такое MVC. Черт подери, это самое простое, что только может быть.

Это прозвучит как бред, но начав читать книгу “Agile web development with Rails” на английской языке я сразу же врубился во все аспекты MVC и начал разработку на rails.

Думайте, что хотите, но теперь я очень редко обращаюсь к “родной” литературе. И я понятия не имею с чем это связано. Возможно, я действительно глуп для русских писателей.

Блоги

Вы когда-нибудь пользовались Google-reader’ом? А вы когда-нибудь смотрели на список своих подписок? И много там русских?
Это грустно, но я не нашел ни одного интересного мне tech-блога на русском языке. Хабр не в счет. Кроме него ничего и нет.

Складывается ощущение, что русские ребята даже не стараются создать что-то своё. Стоит признать, что большинству просто до фонаря блогинг, как платформа получения информации.

Я ежедневно читаю десятки тематических английских блогов на разные темы, начиная от дизайна, заканчивая программированием. И я не вижу не одной достойной русской альтернативы.

Учите английский. Начните с малого. Подпишитесь на один блог и переведите все статьи. Со временем ваш английский будет улучшаться. И вы сможете открыть для себя море интересной информации. Такой информации, которую никогда не найти на просторах русского интернета.

Многие из вас слышали о замечательном методе inherited.

Если кто-то не понимает о чем сейчас идёт речь, то поясню, что этот метод вызывается, когда какой-нибудь класс унаследовал другой (базовый) класс. Сегодня вы узнаете, как этот метод может быть полез в хозяйстве ;)

Например:

class A
  def self.inherited(child)
    puts “Now I am parent of class #{child}!”
  end
end
 
class B < A
end
 
#=> “Now I am parent of class B”

Такие методы называются методами обратного вызова (callback).

Но для чего оно может пригодиться нам?

Например, вы разрабатываете свой фреймворк и вам необходимо узнать о классах, которые унаследовали базовый класс:

class MyController < MyFrameWork::Base

На этой недели я разрабатывал свою систему виджетов, и воспользовался этой техникой:

class MyCustomWidget < Widgets::Base

Скрипт читал каждый .rb файл в директории “widgets” и загружал его в память. Как только интерпретатор замечал, что какой-нибудь класс унаследовал Widgets::Base, он сразу заносил имя этого класса в хранилище.

Проблема в том, что при срабатывании метода inherited вам недоступны методы, объявленные в теле класса – потомка. Потому что интерпретатор еще не успел занести методы класса в память. Это может стать проблемой. Я обошел эту проблему простым путём: узнал о всех классах, унаследовавших базовый класс, позволил интерпретатору загрузить методы классов, а уже после этого создал объекты классов:

def initialize
  self.pool = EasyWidgets::Pool.new
  self.load_widgets
  self.pool.init_objects_pool
end

Более подробно об объектном пуле

Хорошо это или плохо?

С одной стороны вам не нужно создавать и следовать naming-convention. Как, например в Rails:

[main_controller.rb]: MainController < базовый_класс

Вы сможете делать что-то вроде этого:

[любое_имя_файла.rb]: MySuperClass < базовый_класс

Меня огорчил тот факт, что метод inherited срабатывает ДО того, как руби занёс методы класса в память.

Но по сути это не является серьезной проблемой.

Я думаю это первое “ограничение”, которое мне удалось встретить при работе с ruby :)

Это не просто голые советы, за всем этим стоит личный опыт и море потерянного времени.
Эту статью стоило назвать “Мои ошибки, совершенные при работе с Rails приложениями”, но получилось бы как-то слишком длинно.

Толстые модели и голые контроллеры

Моё первое rails-приложение было просто ужасно. Большая часть логики лежала в контроллерах. Я обрабатывал списки тегов и создавал ассоциации в контроллере, я почему-то отказывался от замечательного метода accepts_nested_attributes_for.

Всё было хорошо, но чёрт подери, я не люблю тестировать контроллеры! Гораздо проще и приятнее тестировать модели.

Обработка списка тегов очень простая задача, и почему же лучше выделить код этого обработчика в модель, а не контроллер?

• Удобство. Вы просто открываете модель Post и находите там все методы, которые работают с вашей моделью. У вас нет нужды открывать контроллер и править методы там.
• Дальнейшая расширяемость. Если код обработчика будет висеть в методе контроллера, то практически, этот код будет навсегда привязан к контроллеру. А что если вы захотите обработать список тегов в консоли?
• Предназначение. Контроллеры не предназначены для разбивки списка тегов.

Рисуйте и продумывайте

Да, это действительно помогает! Попробуйте обрисовать все связи вашего сайта. Попробуйте представить сложности, которые могут возникнуть. Конечно, при отсутствии опыта это может показаться очень трудным. Вы можете просто не знать, какие сложности будут ждать вас. Предварительное проектирование будет развивать вас. При обретении достаточного количества опыта, вы сможете заранее устранить многие сложности на этапе проектирования.

Я бы сэкономил уйму времени, если бы заранее нарисовал систему взаимодействия элементов меню со страницами и категориями на моем сайте.

Но я перемудрил и создал одну лишнюю модель. В итоге пришлось переписать всё.

А что дают рисунки?

В дальнейшем, спустя много времени вы сможете освежить свою память, просто взглянув на ваш рисунок. Иногда связи бывают очень сложными и “врубаться” заново в проект очень тяжело.

Графическая информация более проста к понимаю, поэтому она быстро освежит вам память и позволит сэкономить время.

Продумывайте ваш css заранее

Я потерял около двух дней на этом. Это был мой первый проект. Я решил отложить создание css-скелета на будущее. Я совершил роковую ошибку. Пришлось вручную править каждый view-файл.

Это было ужасно, но еще хуже то, что в первый раз я сделал это не правильно и пришлось повторно пройтись по всем файлам.

Избегайте этого, создавайте ваш css-скелет заранее и следуйте ему.

Описывайте сложные модели в комментариях

Это здорово помогло мне. Когда я создавал сложную систему меню с множеством простых и полиморфных связей.

Я решил заранее описать суть этой модели в комментариях.

Когда я создавал модель, всё было понятно, но уже через пару недель я не мог вспомнить всех тонкостей. Комментарии помогли мне.

Думайте о расширяемости

Если вы создаете модель комментариев и привязываете эту модель к постам, подумайте, а что если в будущем вам понадобится добавить комментарии к голосованию, или к статичной странице? Продумайте расширяемость заранее, в будущем это сэкономит вам время.

Вы можете быстро сдать заказ, но что если через месяц что-то сломается или вам придётся добавить новую “фичу”? Гораздо приятнее работать с четкой структурой, нежели морем костылей.

Недавно я перевёл статью “How To Land a Rails Job with No Experience“.

Сегодня наткнулся на опровержение этой теории.

Скажу честно, опровержение понравилось мне больше, чем оригинал. Если кого-то интересует, то я могу перевести это опровержение.

Перевод статьи “How To Land a Rails Job with No Experience“

18 месяцев назад я получил отличную работу Rails-разработчика, не имея опыта в ruby.
Ниже представлены три трюка, которые помогут сделать вам тоже самое.

1. Создайте приложение для своего портфолио.

Очень важно создать Rails-приложение и дать возможность работодателю изучить его. Самое лучше доказательство вашей компетентности — это ваш рабочий код. Даже самое простое Rails приложение показывает, что вы освоили целый набор технологий: базы данных, ruby, rails, erb, html, css, развертывание rails приложения и некоторые другие. Если вы абсолютный новичок в мире Ruby on Rails, то я советую вам следовать следующим рекомендациям:

• Прочтите эту книгу — http://www.railstutorial.org/. Я думаю это отличная книга. Однако, как и в случае многих книг по программированию, вам не стоит просто читать текст. Следуйте примерам книги, создайте тестовое приложение. Придумайте простые задачи, сделайте так, чтобы ваше приложение решало их! Так вы быстрее научитесь многим вещам.
• После прочтения книги придумайте небольшое приложение для портфолио. Выберите что-нибудь маленькое и работайте над этим.
• Когда ваше приложение начнёт работать, используйте его как площадку для экспериментов. Попробуйте установить различные плагины и gem’ы. Переключитесь с Test::Unit на RSpec. Попробуйте перейти со стандартных фикстур на что-нибудь вроде factory girl. Переписывайте ваш код.
• Теперь выберите интересующие вас вакансии Rails-разработчика. Каждая из вакансий должна содержать в себе список технологий, которые используются в данной конторе. Внимательно просмотрите этот список и найдите то, что не очень знакомо вам. Возможно, вы еще не освоили Jquery, TDD и git. Уделите время и внедрите эти технологии в ваше приложение. Поймите, не обязательно в совершенстве владеть этими вещами, но уметь работать с этим на базом уровне всегда пригодится. Например, представьте себе такой диалог (которые обязательно случится) — Работодатель: Мы постоянно используем Jquery в наших разработках, вы владеете этим? Вы: я не владею этим в совершенстве, но я реализовал drag and drop и несколько визуальных эффектов в моей приложении. Вы должны доказать работодателю, что способны обучаться новым вещам. Если вы способны к самообучению, тогда работодатель наверняка обратит на вас внимание.

2. Используйте Github

Если бы существовало какое-то официальное место для опубликования ruby-кода, то http://github.com наверняка был бы этим местом. Вы просто обязаны иметь аккаунт на github и постоянно выкладывать ваш код туда. Работодателям будет гораздо легче оценить код проектов из вашего портфолио, если он будет находится на github.  Наблюдайте за программистами, которые интересуют вас. Читайте код их коммитов, тогда вы еще быстрее освоите стили программирования руби.

3. Посещайте ruby-встречи.

Это самый лучший способ получить свой шанс. Обычно такие встречи проходят локально, поэтому вы заранее будете знать многих участников. Вы сможете узнать о новых рабочих местах, и более того — отдать своё резюме в руки представителя какой-нибудь компании, что на практике гораздо лучше, нежели посылка резюме через электронную почту.

Помимо новых вакансий,  такие встречи хороши для поиска своего ruby-наставника. Многие люди готовы помочь новичкам, ответить на их вопросы, а так же оценить ваш код и указать на слабые места. Просто обратитесь к кому-нибудь, попросите его указать на самую ужасную часть кода и разузнайте то, как бы он исправил это.

Ответы на некоторые вопросы:

Действительно ли рынок Rails-разработчиков ищет новых талантов?

Конечно! На моей последней встречи на http://bostonrb.org/ я слышал о 4+ открытых вакансиях. Позиция, которую сейчас занимаю я, была открыта на протяжении нескольких месяц. Потом они решили взять новичка и обучать его.

Стоит ли пытаться ворваться в мир Rails?

Определенно!
Ruby — замечательный инструмент. Я люблю этот язык программирования. Помимо этого вы будете приятно удивлены rails-сообществом.

Будут ли эти советы действенными для меня?

Возможно. Они помогли мне! Я попал на желаемую работу после пары месяцев тяжелого труда.

Привет всем.
Решил изучать исходники моего любимого Руби. Буду периодически делиться с вами своими наблюдениями.

Небольшое предупреждение:
Желательно знать Си. Хотя бы немного. Ладно-ладно, не знаете? Ну, тогда спрашивайте в комментариях, я вам на “яблоках” объясню (и почему я постоянно думаю, что кто-то вообще еще продолжает читать этот рассказ?).

Пожалуйста, не пугайтесь слова “указатель”. Это переменная которая указывает на что-то другое (если выражаться очень понятным языком).
Если попытаться привести простую аналогию указателей в руби, то на ум приходит следующая конструкция:

Есть объект стандартного удостоверения личности. А есть человек, имеющий этот документ.

class Document
  attr_accessor :person
 
  # при создании документа указываем его номер а так же объект, которому будет принадлежать сей документ
  def initialize(object, number)
    @document_number = number
    @person = object
  end
end
 
Person = Struct.new(:name)
 
# наш человек имеет имя Олег!
someone = Person.new("Oleg")
 
# теперь создадим документ
# передадим в качестве аргументов функции нашего человека и номер документа
doc = Document.new(someone,23234)
 
# а теперь магия!
puts doc.person.name
# => "Oleg"
doc.person.name = "Natalia"
puts doc.person.name
# => "Natalia"

На самом деле при создании нашего документа мы передали УКАЗАТЕЛЬ на объект Person. Таким образом получили возможность манипулировать этим объектом через класс Document.

В си нет классов, зато есть Структуры. И в руби они тоже есть (если вы не знали, то смотрим внимательно на класс Struct).
Я начну свой рассказ с файла “ruby.h”, и не от того, что я уже как пять пальцев знаю всю архитектуру руби, а, наверное, из-за того, что именно этот файл мы инклудим при создании своего расширения на си для руби.

Обратим внимание на самые важные вещи для нас -> класс и объект. Сейчас вы поймёте почему метапрограммирование в руби именно такое, почему можно сделать так и оно будет работать:

class MyClass
  def self.hello
    puts "hello"
  end
end 
 
MyClass.hello
# >> "hello"
 
MyClass.instance_eval {
  def hello
    puts "goodbye"
  end
}
 
MyClass.hello
# >> goodbye

Для себя я выделил 3 структуры, которые будут интересны нам:
RBasic, RObject и RClass.

Вот код этих структур:

struct RBasic {
unsigned long flags;
VALUE klass;
};
 
struct RObject {
struct RBasic basic;
struct st_table *iv_tbl;
};
 
struct RClass {
struct RBasic basic;
struct st_table *iv_tbl;
struct st_table *m_tbl;
VALUE super;
};

Давайте внимательно взглянем на структуры RObject и RClass (Объект и Класс).
Наверное, вы обратили внимание, что обе структуры имеют внутри себя еще одну структуру — RBasic.
Структура RBasic содержит в себе интересную строку — “VALUE klass”.  Если узнать, что же такое VALUE, то оказывается, что это переменная типа unsigned long. Эта переменная хранит в себе адрес класса в памяти. Зная адрес класса в памяти мы можем обращаться к нему в любое время!

Объект и класс в руби, обязательно имеют VALUE klass. Понимаете к чему я веду? Класс тоже является объектом!

Да, это странно, и не похоже на некоторые другие языки.
Именно это когда-то вскрыло мне мозги — ”О боже, как так? Декларация класса тоже объект? no way!”

Давайте приглядимся к структуре RObject, помимо структуры RBasic она имеет ссылку на iv_tbl.
iv_tbl расшифровывается как instance_variable_table, то есть таблица переменных объекта.

Класс тоже имеет ссылку на таблицу переменных объекта.
Да, да, у класса тоже могут быть свои переменные =) Эти переменные будут преследовать класс на протяжении всего цикла работы программы.

class MyClass; end
MyClass.instance_variable_set("@var", 100)
puts MyClass.instance_variable_get("@var")
# >> 100
obj = MyClass.new()
puts obj.instance_variable_get("@var")
# >> nil

Выведет nil, так как @my_var является переменной объекта MyClass, а не переменной экземпляра класса MyClass. (Надеюсь, я не запутал вас)

Окей, мы попытались разобраться с iv_tbl ( таблица переменных объекта ), теперь попробуем перейти к m_tbl.
Это указатель на таблицу методов (methods_table). Вы, наверное, уже заметили, что объект не имеет в себе указатель на таблицу методов.

Почему? Всё очень просто. Объект имеет внутри себя структуру RBasic, которая содержит в себе адрес своего класса.

Как происходит поиск методов?

Предположим мы написали такой код:

object.my_method()

Интерпретатор обращается к объекту, узнает адрес класса объекта, обращается к классу по этому адресу. Найдя класс, интерпретатор обращается к таблице методов класса и ищет там метод.

Вы уже заметили строку “VALUE super” в структуре RClass?
Здесь содержится адрес родительского класса.

если мы сделаем что-то вроде:

class A; end
class B < A; end

То теперь в поле “VALUE super” класса B будет адрес класса A, так как класс A является родителем класса B.

Таким образом, когда мы вызываем метод объекта, интерпретатор узнает класс объекта, обращается к этому классу, узнает адрес таблицы методов и пытается найти метод в этой таблице. Если метод не был найден, интерпретатор узнает адрес класса-родителя и если такой имеется, то он продолжает поиск метода в таблице методов класса-родителя.
Если метод не найден и в классе-родителе, то поиск продолжается в super классе нашего родителя:

class A
def my_method()
end
end
class B < A; end
class C < B; end
 
c = C.new()
 
c.my_method()

Мы видим, что метод my_method() определен в классе A, таким образом интерпретатор сначала будет искать этот метод в классе C, затем перейдет к классу B, а затем к классу A.
Это интересно, потому как раньше мне казалось, что создавая вот такое наследование:

class User < ActiveRecord::Base
end

мы тянем за собой всю тонну классов ActiveRecord’а. Мне было страшно, что мой скромный класс User “заполняется” методами своего родителя, я переживал за память.
Теперь мне легче. Умнеть иногда полезно =)

Думаю, теперь вы понимаете, что при наследовании руби создает цепочку классов, и каждый класс из этой цепи ссылается на свою таблицу методов.
Руби будет искать метод до тех пор, пока не дойдет до самого высшего класса цепочки.

В следующем выпуске я хотел бы ближе рассмотреть модули, то как они включаются в цепь наследования, а так же получше рассмотреть таблицы методов и переменных объекта.

Спасибо за терпение, жду ваших отзывов.

95-ая статья из книги 97 Things Every Programmer Should Know
by Gerard Meszaros

Вы пишите автоматические тесты для одного или всех своих приложений? Мои поздравления!
Вы пишите тесты до написания кода? Это еще лучше! Просто делая это, вы приближаете себя к гордому званию настоящего разработчика.

Но постойте, вы пишите хорошие тесты? Задайте себе вопрос — “Для кого я пишу тесты?”.

Писать тесты для себя или для компилятора не самая лучшая идея. Так для чего же на самом деле стоит писать тесты?

Тесты стоит писать для людей, которые в дальнейшем будут изучать ваш код. Хорошие тесты являются документацией к тестируемым программам. Они отлично описывают как и для чего работает код.

Можно выделить три основных сценария тестирования:

• Описание контекста тестируемой части программы, точку входа и данные, которые должны быть определены, перед выполнением теста
• Демонстрация того, как программа должна быть вызвана
• Описание ожидаемых результатов или условий, которые будут проверены

Человек, который пытается понять ваш код должен просто взглянуть на тесты и получить понимание того, как работает программа и к каким последствиям могут привести различные действия.

Каждый из тестов должен кристально ясно демонстрировать один из трёх сценариев тестирования.

Это означает, что тесты должны демонстрировать не только то, что явно, но и то, что скрыто.

Слишком большие тесты могут быть тяжелы для понимания, так как читатель может отвлечься на незначительные вещи. Старайтесь убрать на второй план не особо значимые вещи. Рефакторинг — ваш лучший друг в данном вопросе, извлекайте методы из большого кода, сосредотачивайте внимание ваших читателей на самом важном. И конечно же не забывайте давать вашим тестам понятные названия, которые не будут запутывать, но и смогут раскрыть суть этого теста.

Тестируйте свои тесты. Звучит странно? Но это тоже хорошая идея.

Вы можете проверить смогли ли ваши тесты найти предполагаемые ошибки. Умышленно создайте ошибки в вашем проекте и посмотрите, смогли ли тесты вычислить их. Желательно делать это на локальной копии проекта, не стоит подвергать данные опасности. Убедитесь, что ошибки вызванные тестами понятно и четко описывают проблему, это так же поможет людям работать с вашим приложением.

Попросите своего партнера просмотреть ваши тесты. Непредвзятый взгляд сможет выявить сложные и непонятные места, над которыми вам стоит поработать. Если этот человек чего-то не понял, то скорее всего это не из-за того, что он глуп, а из-за того, что вы не смогли доходчиво передать суть теста. (А теперь вперед меняться ролями — почитайте тесты ваших коллег!)

Честно говоря я не очень хорошо знаю английский.

Нет, ну конечно я его знаю. Почти вся литература, прочитанная мною, была на английском языке. Это скорее заслуга русских авторов. Я, знаете ли, не очень понимаю, что они иногда имеют ввиду. Ударьте меня, если я не прав, но нет ничего хуже, чем русская техническая литература.

Ах, я отвлёкся от главной мысли. Я буду переводить до тех пор, пока не смогу понимать английский как свой родной. Все переводы, сделанные мною, называются “вольными”. Я могу дописать что-то своё или пропустить. Это не очень хорошо, но наверное это ваша плата за то, что вы не знаете английский. Конечно при условии, что кто-то вообще будет это читать.

Привет всем, надеюсь через много лет кому нибудь пригодятся записи в этом “очередном блоге”.

Говорят, что нужно представляться. Собственно делать этого мы не будем. Кто-то даже говорит о своих планах. Но и здесь я промолчу, наверное от того, что боюсь “спугнуть”.

Так что лучше читайте мои посты, которые конечно же когда нибудь заполнят этот блог до отвала.