Недавно мы решили выделить логические компоненты внутри нашего большого рейлс-приложения, чтобы в будущем возможно разделить приложение физически. Для стандартизации общения между частями системы я использовал JSON-совместимые объекты с валидацией при помощи JSON-схем и немного доработанный OpenStruct. Про этот эксперимент я и хочу рассказать в сегодняшней статье.

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

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

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

У меня всегда есть файл config/initializers/_monkey_patching.rb, в который я добавляю необходимую низкоуровневую функциональность в рейлс и руби. Когда я плохо знал возможности языка и фреймворка, этот файл был большой. Теперь я его регулярно пересматриваю и по возможности переписываю код на стандартные механизмы.

Сегодня хочу поделиться с вами, что хранится у меня в этом файле сейчас.

У нас открылась вакансия Javascript-разработчика.

Требования:

• Javascript (jQuery, Coffee)
• CSS3 (SCSS), IE8+, Mobile
• Git, знакомство с рейлс
• Опыт работы от 2-х лет

Офис находится в 5 минутах от метро Арбатская. Проект интересный.

Контакты:
Коломоец Иван, kolomoetz@gmail.com, +7 (915) 012-03-04
Вахов Алексей, vakhov@gmail.com, +7 (926) 589-45-37

С++ я уважал за мощь и строгость, Руби обожаю за работу с строками, массивами и хэшами, но к Javascript всегда относился и продолжаю относится холодно. Мне не нравится как осуществляется работа с this, смущает обилие операторов и зарезервированных слов undefined, null, Infinite, Nan, ==, ===, а также я плохо ориентируются в колбеках. Кроме того, я не прочитал ни одной книги по Javascript, что конечно же не способствует установлению приятельских отношений с этим языком.

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

Оговорюсь, что у нас простой интерфейс, однако есть сложные алгоритмические куски кода на javascript. Поэтому наши задачи идеально подходят под классическое юнит-тестирование, про которое я буду рассказывать сегодня. Как тестировать сложный UI я пока не знаю, так как с такой задачей еще не сталкивался.

Последнее время я очень полюбил mustache-темплейты и использую их всегда, когда нужно отрисовать кусок HTML на сервере и потенциально на клиенте. Причем я не хочу переходить на более продвинутый handlebars, так как мне кажется, что logicless-сущность mustache помогает создать более изящную архитектуру, лучше спроектировать json’ы общения клиента и сервера и избежать соблазна сделать erb-кашу из шаблонов.

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

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

Основная идея истории заключается в том, что у любого программного обеспечения есть 3 стадии: любительская, когда что-то работает у программиста на компьютере, профессиональная, когда программное обеспечение можно установить и люди его будут использовать в повседневной работе, и коробочная, которую можно устанавливать на многих компьютерах, многих людей. Трудозатраты этих 3-х версий находятся в примерном отношении 1:10:100, где коэффициент 10 очень сильно зависит от типа проекта. Очень вероятно встретить проект в котором данное соотношение будет 1:100:10000, но не существует проектов где бы это соотношение было 1:3:9 или еще лучше.

3 недели в блог не писал и уже тяжело снова начинать. Так однажды я 2 года спортом не позанимался и тоже лень было возвращаться. Есть правда хорошое решение - нужно себя заставлять. И вот сегодня я хочу рассказать про разные мелочи, с которыми столкнулся в свое время.