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



Больше всего меня достали:
1. Отсутствие индексов в базе данных на ключи ассоциаций
2. Нахождение дублирующих ключей в файлах локализации
3. Поиск отсутствующих переводов
4. Строки — одинарные и двойные кавычки

С репликацией серверов MySQL я познакомился относительно недавно, и по мере проведения разных опытов с настройкой, записывал, что у меня получалось. Когда материала набралось достаточно много, появилась идея написать эту статью. Я постарался собрать советы и решения по некоторым самым основным вопросам, с которыми я столкнулся. По ходу дела я буду давать ссылки на документацию и другие источники. Не могу претендовать на полноту описания, но надеюсь, что статья будет полезной.

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

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

Предположим, что единственный способ представления кода — лямбда-выражение, а единственная доступная структура данных — массив:

square = ->(x) { x * x }
square.(4) # => 16

person = ["Dave",:male]
print_person = ->((name,gender)) {
  puts "#{name} is a #{gender}"
}
print_person.(person)

Это самые основы функционального программирования: функции — единственное, что у нас есть. Давайте попробуем написать что-то более похожее на реальный код в таком же стиле. Посмотрим, как далеко мы сможем зайти без особых мучений.

Предисловие

Пришла мне в голову смелая мысль, взяться за написание туториала по разработке на node.js (что-то наподобие ruby.railstutorial.org). Так как я первый раз берусь за подобный труд то для для меня очень важен любой фидбэк. Нужно это — не нужно. Что стоит убрать а на чем остановиться подробнее, в общем любая конструктивная критика. Надеюсь что дело пойдет и вам понравится, в этом случае по мере написания буду выкладывать главы на хабр.

Вступление

Приветствую, перед вами небольшой учебник по практической разработке на node.js, с использованием фреймворка express. Я с большим энтузиазмом отношусь к node и сопутствующим технологиям. Node.js в первую очередь привлекает свежестью в подходах к разработке, смелостью и драйвом.

О том, что такое node.js вы можете прочитать на http://nodejs.org/, если коротко — то это серверная платформа, для выполнения javascript. Так же мы будем использовать express, web-фреймворк построеный на концепции middleware (о том, что это такое, поговорим поподробнее чуть позже)

В процессе изучения мы познакомимся с различными аспектами web-разработки, такими как использование системы контроля версий, автоматическое тестирование и так далее. В результате по ходу изучения мы разработаем вполне рабочее web-приложение (простенький аналог твиттера)

Хочется отметить, что очень большое влияние на меня оказал railstutorial, это лучшее пособие по web-разработке, которое я встречал, и мне очень хотелось бы создать нечто подобное для node.js.

В ECMAScript пока отсутствует понятие «класс», в классическом понимании этого термина, однако, в CoffeeScript такое понятие есть, поэтому сегодня мы рассмотрим этот вопрос очень подробно.

Содержание:

1. Основные понятия
2. Члены класса
   2.1. Метод constructor
   2.2. Открытые члены класса
   2.3. Закрытые члены класса
   2.4. Защищенные члены класса
   2.5. Статические члены класса
   2.6. Оператор => (fat arrow)
3. Наследование
4. Дополнительная литература

Примечание переводчика: данный пост является логическим развитием, а точнее «предысторией» поста Вникаем в include и extend и был подсказан в комментариях к нему пользователем murr, за что ему большое спасибо.

Классы и объекты в Ruby связаны между собой достаточно затейливо и не сразу можно понять что к чему. Из-за особого назначения классов очень легко потерять из вида тот факт, что классы — это тоже объекты Ruby. От «обычных» объектов их отличает два вещи: они служат образцом для создания новых объектов и они являются частью иерархии классов. Все верно, классы могут иметь экземпляры себя (объекты), суперклассы (родителей) и подклассы (детей).

Если классы — это объекты, то у них должен быть свой собственный класс. Классом всех классов (как объектов) в Ruby является класс Class:

# один из способов создать новый класс
Dog = Class.new
    
# общепринятый способ создания класса
class Dog
    # какая-то реализация собачьего поведения
end

Dog.class
=> Class

Примечание переводчика: перед прочтением этого поста рекомендую сначала ознакомиться с постом Вникаем в метаклассы Ruby.

Все рубисты знакомы с формальными определениями для include и extend. Вы делаете include модуля, чтобы добавить методы экземпляра класса, и extend — чтобы добавить методы класса. К сожалению, данные определения не совсем точны. Они не могут объяснить почему мы используем instance.extend(Module), чтобы добавить методы объекту. Разве не должны мы в этом случае использовать instance.include(Module)? Чтобы разобраться в этом вопросе, начнем с выяснения где же хранятся методы.

Кто здесь?

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

11:24:21 PM Michael: ну хз, надо пробовать
11:24:24 PM Michael: наверное так лучше
11:24:27 PM Michael: даже я думаю наверняка
11:24:36 PM Michael: но пока меня че-то останавливает
11:24:38 PM Michael: лень наверное :)

Знакомо? «Не хочется разбираться? Нет времени?» Тогда читаем дальше. В статье расскажу, как настроить свое любимое рельсовое окружении на разработку с подходом BDD и начать новую жизнь (опционально).

Многие любят руби за его красоту и гибкость. Но некоторые не догадываются о темной стороне языка Ruby. Сегодня расмотрим одну из темных лошадок руби, многие им пользуются, но не многие знают его секрет. Итак, тема дня блоки!

В последнее время столкнулся с тем, что Prototype не такая уж клевая библиотека. Даже в компрессии напару с scriptaculous занимают много места да и синтаксис странный. Для меня загадка, почему в Rails включили именно его. jQuery по синтаксису намного больше похож на Ruby и более легковесная библиотека. Собственно немного порыскал и нашел неплохие шпаргалки на jQuery, чтоб освоение протекало несколько легче.

1. jQuery Color Cheatsheet (PNG)