Распечатка доклада в Харькове

декабря 5, 2014  |  Published in Best Practices, Tips&Tricks, Новости, Уголок философа

Подготовил доклад для встречи организуемой DataArt в Харькове: «Философия систем сквозь призму разработки ПО», но, увы, не смог его рассказать так, как положено. С этой целью и выкладываю шпоргалку (без редактирования, как есть) для того, чтобы хотя бы из нее вы почерпнули ту информацию, которой я хотел бы поделиться. Номера пунктов — это номера слайдов в презентации. Презентация лежит здесь: system-philosophy.

2.

Тема моего доклада: Философия систем сквозь призму разработки ПО.

Что есть Философиия систем? Философия систем — это научно-философский труд над которым я начал работать совсем недавно и закончу совсем не скоро. Тем не менее мне уже сейчас есть чем с вами поделиться.

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

Многие философы работают над изучением сути вещей. Что есть человек или что есть этот ноутбук? На самом деле это вопросы весьма сложные.

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

Что же касается философской составляющей, то она в большей мере проявляется в самом стиле труда, а не в содержании. Сухие математические выкладки меня прельщают в меньшей мере, нежели красивый литературный слог.
Таким образом Философия систем ограничивается коротким и прагматичным объяснением: Все есть система.
4.

Целое больше, чем сумма его частей. — заметил Аристотель.

Это целое состоящее из множества частей и является системой. Система — это не просто множество компонентов вхожих в нее, но скорее отношения между этими компонентами.
5.

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

Можно сказать что рассматриваемый нами объект — это система, а среда — это суперсистема, то есть система, компонентом которой является рассматриваемая система. Внутри суперсистемы А, система А1 пребывает в некоторых взаимоотношениях с другими вложенными системами: А2, А3, …, Аn, и эти взаимодействия потенциально опасны.

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

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

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

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

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

Вы слышите об исключениях и слышите слова «в некоторых» и как неудобно мне дается категоризация систем. Позже вы узнаете почему так.
7.

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

Чаще всего эти понятия применяют в отношени биологических систем, например, клетки, органа или целого организма, но сфера их употребления не ограничивается лишь биологией.

8.

В чем разница между саморегуляцией и самоорганизацией?

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

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

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

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

В противовес самоорганизации и саморегуляции существуют организация и регуляция, то есть управление. Самоорганизующаяся и саморегулирующаяся система (объект управления) начинает противостоять субъекту управления. Так, например, программный продукт противостоит разработчику, даже не смотря на то, что часть логики его поведения была заложена самим разработчиком.

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

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

 

10.

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

Все это характерно для любых систем в том числе и абиотических.
11.

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

Так, применяя адаптивную разработку, мы не допускаем разрушительных волн — цунами.
12.

Опускаясь на уровень ниже, к системе — самому коду приложения, важно знать о таком правиле организации систем, как правило максимальной изоляции.

Клетку от вредного воздействия из вне защищает мембрана, человека защищает кожа, Землю защищает магнитное поле и атмосфера.

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

Клетка, человек и планета Земля имеют свои протоколы взаимодействия. Так клетка участвует в некотором химическом взаимодействии со своими соседями, кожа защищает организм от бактерий и, например, от соленой воды, магнитосфера Земли защищает всех ее обитателей от радиации, а озоновый слой от ультрафиолетовых лучей. Аналогичный, строгий интерфейс взаимодействия должен быть разработан и для системы — программного продукта и рекурсивно повторен для всех ее компонентов и компонентов компонентов.
13.

Боги программирования низпослали нам принципы именуемые SOLID.

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

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

Принцип подстановки Барбары Лисков говорит о том, что компонент B, наследуемый от компонента A, должен быть способен заменить компонент А. Другими словами, он обязан реализовывать тот же интерфейс. Этот принцип перекликается с предыдущим.

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

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

Другой важный принцип низпосланный нам богами имеет название TDA. Эта аббревииатура расшифровывается как: Tell, do not ask, то есть: говори, а не спрашивай.

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

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

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

Важным философским и не только философским вопросом является вопрос о том, чем некий объект является на самом деле, без его оценки нами, без существования расстояниями между нами и объектом, то есть постижение вещи в себе, ноумена. Людвиг Витгенштейн говорил о том, что философия существует лишь благодаря несовершенству нашего языка и что нет проблем философии, но есть проблемы языка, которым мы называем вещи и явления. Я же двигаюсь более прагматично. Работая над разработкой той или иной программной системы я постоянно задаюсь вопросами о том, какие сущности, другими словами компоненты мне необходимы и в каких отношениях они находятся. Я отбрасывают вопрос о том, что они есть так как в самом деле он не он глуп. Правильный вопрос должен звучать так: Из чего это состоит? Мы ведь рассматриваем все как систему.

В ответе на вопрос: «Из чего они состоят?» кроется маленькая хитрость.

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

Одной из ошибок ученых является создание понятия таксона и таксономии, как науки. Они берут отдельные кадры фильма истории и называют их определенными именами. Так один кадр они называют Homo erectus, а другой — Homo sapiens. Но если взять типичного Homo sapiens, его родителя и его потомка, то разница между ними будет так незначительна, то они будут оставаться тем же видом Homo sapiens. И если взять их родственников — ситуация повторится. Так где же проходит черта, переступив через которую организм преобразуется в новый вид? Это похоже на вопрос о курице и яйце, тем не менее ученые продолжают заниматься этим неблагородным занятием — классификацией.

Ответ заключается в генах. Мы должны работать с генами, а не с платоновскими идеальными объектами из метафизического мира. Согласно Платону, если есть человек, то дожно существовать идеальное воплощение человека, а сам человек — лишь жалкая его тень. рТак мы создаем класс Human и наполняем его необходимыми нам свойсвами и методами. И этот класс описывает нечто одно. Будто человек — это просто шарик слепленный из глины. Он и представляет абстрактного человека, а человечностью мы назовем принадлежность к этому классу.

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

Гены — это информация об организме, закодированая в длинные цепочки ДНК.

В царстве бактерий существует такое явление, как конъюгация, то есть обмен генами. Если человек наследует геном от родителей + происходит небольшая их мутация за счет информационного шума, то бактерии, будучи гораздо более примитивными существами способны собирать свой геном как конструктор взаимодействуя с другими бактериями. Могут ли в таком случае таксономисты четко определить вид и построить иерархию, например, родословную? Нет.
15.

Другой важной концепцией является концепция мема предложенная Ричардом Докинзом. Мем — это аналог гена в информационном пространстве. Мем — это некий смысл. И если мы будем рассматривать те или иные идеологии достаточно внимательно, то обнаружим, что они не являются чем-то цельным, но состоят из множества мемов.
К чему это я?

Я о том, что для большего удобства разработки нам следует использовать концепции аналогичные генам и мемам. Некая сущность в разрабатываемой системе должна быть лишь собранием тех или иных «генов». На ум сразу приходят примеси реализуемые в Ruby через подмешивание модулей, или trait’ы в Scala. Это отличная практика переодически выность код из классов в модули. Я обычно таким модулям даю окончание -able, например:
Authenticable, Logable, и т.д.

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

Другой возможный вариант, который может использователься параллельно — это минимизация использования наследования в пользу композиции. Целое мы разбиваем на компоненты. В ксенотранспланталогии популярным опытом является пересадка сердца ГМ свиньи человеку. За исключением того, что так и не удалось добиться того, чтобы чужеродное сердце прижилось, идея отличная ибо функциональность сердца свиньи и человека идентичны.

В случае с программным обеспечением, которое является гораздо более простой системой, чем даже организм глупого моллюска с всего-то 3000-5000 нейронов, «сердце» является достаточно абстрактным компонентом для того, чтобы иметь возможность использовать его как в свинье и в обезьяне или в человеке.

 

 

RailsClub Moscow 2014 состоится 27 сентября, в уютном зале DigitalOctober.

сентября 7, 2014  |  Published in Новости

RailsClub Moscow 2014 состоится 27 сентября, в уютном зале DigitalOctober.

 logo_rails__b_on_w

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

 

       В программе

foto-frame Аарон Паттерсон, член Ruby и Rails core team, топ 1 контрибьютор на сегодня, RubyHero 2010. Человек, который определяет развитие языка, и очень харизматичный спикер.

Не зря мы расписывали Аарону, как хорошо ему будет в Москве (посмотрите и вы). Тема выступления сейчас уточняется.

Божидар Батсов, CTO Tradeo, автор Rubycop и редактор Ruby и Rails style guides.

The Elements of Style in Ruby

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

 

Джонас Никлас, автор фреймворка для тестирования Capybara и популярных библиотек Pundit, Turnip и CarrierWave. Ruby Hero 2011

Concurrent systems in Ruby

Джонас расскажет, как Ruby меняется к лучшему в аспектах работы с concurrenсу — больным местом многих нагруженных проектов. Он продемонстрирует несколько разных вариантов, включая классический mutex/condition variable combo, Node-style evented IO, Clojure-style compare-and-set и Erlang-style actors. Покажет, как их можно использовать в Ruby и как Ruby дает более широкий выбор по сравнению с другими платформами.

 

Эрик Майклс-Обер, участник open-sourсe проектов RailsAdmin, Thor и Twitter gem. Ruby Hero 2014 и разработчик в SoundCloud, Берлин.

Writing Fast Ruby

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

 

Сэнди Метц, автор «Practical Object-Oriented Design in Ruby», обладатель Ruby Hero Award 2013

All the Little Things

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

 

Равиль Байрамгалин, Evil Martians, ведущий разработчик Oh My Stats, контрибьютор больше 40 опенсорсных проектов.

Big Data и Ruby

Big Data — не только модные слова для стартап буллшит-бинго, но и реальная головная боль для многих инженеров в интернет-бизнесе. Для масштабирования вычислений на несколько машин есть множество Big Data фреймворков. Чтобы лучше понять их особенности и сделать правильный выбор, Равиль расскажет:  зачем необходима локальность данных,  почему эти фреймворки построены на dataflow,  в чем заключается лямбда архитектура, как ее упростить. И о том, как в Oh My Stats эспериментировали с реактивной абстракцией для вычислений. Среди конкретных фреймворков будут упомянуты ставшие уже классическими Hadoop и Storm (и как их использовать из Ruby), а также в чем преимущества модных Summingbird, Spark и парочки других альтернатив.

Александр Балашов, тимлид в Evrone

Интеграция всех аспектов разработки в единый процесс

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

Кстати, мы решили разнообразить формат и помимо традиционных получасовых докладов предлагаем выступить в серии lightning talks — с пятиминутным техническим докладом, в котором можно поделиться методологической находкой, полезной тулзой или презентовать свой open-source проект. У нас уже есть 4 отличных LT, темы которых мы анонсируем позже

Мы еще принимаем заявки в программу конференции. Есть о чем рассказать — welcome

Англоязычные доклады будут идти с качественным синхронным переводом на русский язык (как и обратно)

Что кроме докладов:

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

Присоединяйтесь, не пожалеете!

Цена билета до 10 августа — 7500

Успевайте купить билет

Партнеры проекта:

Генеральный спонсор — TopTal

Золотой спонсор — Bookmate

HR -партнер — DigitalHR

Организаторы — Evrone и Undev

Площадка мероприятия — Digital Octoder

Svitla Systems приглашает на RubyC-2014

апреля 11, 2014  |  Published in Новости

Svitla Systems приглашает на RubyC-2014

31 мая – 1 июня 2014 года в Киеве пройдет вторая конференция RubyC,
посвященная Ruby и Ruby on Rails

Svitla Ruby Conference 2014

Посетить RubyC 2014 будет полезно тем, кто хочет:

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

В этом году RubyC вновь собирает звездный состав докладчиков из Америки, Европы и стран СНГ. Среди приглашенных гуру: Стив Клабник (США), Бен Ловелл (Великобритания), Хавьер Рамирес (Великобритания), Александр де Оливера (Бразилия), Дэвид Хеннер (США), Джереми Эванс (США), Константин Теннахард (Германия), а также Богдан Гусев (Украина), Тимофей Цветков (Россия), Евгений Пирогов (Украина).

Подробнее о спикерах и их темах можно узнать на сайте http://rubyc.eu/.

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

Полезности:

  • Продажа билетов уже открыта на сайте конференции!
  • Место проведения конференции: БЦ «ИНКОМ», ул. Смоленская, 31-33, Киев.
  • Рабочие языки конференции – английский, русский, украинский.
  • Присоединяйтесь к группам RubyC на Twitter и Facebook.

Впервые RubyC состоялась в 2011 году, став одним из наиболее значимых событий для руби-сообщества того года, поскольку собрало вместе не только высококлассных докладчиков из разных уголков земного шара, но и около 200 посетителей из Украины, России, Беларуси, Латвии и США . Спикерами RubyC среди прочих стали: Райан Бигг (Австралия), Стив Клабник (США), Джонас Никлас (Швеция), Дарси Лейкок (Австралия), Алексей Найден (Россия) и многие другие. Подробнее о том, как прошла первая конференция RubyC можно узнать тут.

Организатор RubyC — Svitla Systems Inc., американская аутсорсинговая компания, которая занимается разработкой приложений на Ruby, .NET, PHP, Java, Magento, Flash, а также мобильных приложений. Офисы компании находятся в Киеве, Львове, Харькове, Севастополе, Черкассах, Черновцах и Тернополе. Головной офис располагается в Сан-Франциско.

Контакты:

PR менеджер
Надежда Береговая
n.beregova@svitla.com
+38 097 852 86 71

Tags:

Le Roi est mort, vive le Roi!

ноября 22, 2013  |  Published in Новости  |  10 Comments

Будем честны, RubyDev — весьма скучный блог, я имею ввиду, что в нем нового? Введение в Ruby, введение в Rails, ничего принципиально нового и заставляющего включить мозг. Просто справочная информация для новичков, за что они довольны, но меня не слишком прельщают похвалы новичков.

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

Ам-м-м… Думаю, достаточно аналогий. RubyDev больше не будет блогом для новичков. Я собираюсь опубликовать новый, исправленный и действительно «православный» учебник по Ruby и это будет единственным моим подарком тем, кто называет себя новичками в программировании или junior’ами.

Мне не интересно писать введения, но по Ruby действительно отсутствует качественная литература. Не только по Ruby. Я имел удовольствие прочесть несколько книг по различным языкам программирования: Scala, Java, Erlang, Clojure, Ruby, Rails, JavaScript, но я не сумел найти среди них таких книг, которые мне бы понравились, разве что только книги Николаса Закаса. Это не камень в огород их авторов, точнее не камень в огород авторов, как разработчиков, но камень в огород авторов, как, эм…, авторов. Изложение либо скучно, либо непонятно, либо это просто рассказ о синтаксисе языка. В общем унылая тягомотина на 600-800 страниц, которая годится лишь для тренировки силы воли. Таким образом я постараюсь написать новый учебник по Ruby таким, чтобы он был интересным и учил не только синтаксису, но и вообще программированию.

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

Статьи о Rails? Признаться, я не люблю Rails. Я был восхищен его возможностями после перехода с PHP, но сейчас я вижу в Rails много неудачных решений. Чтобы быть совсем честным, что аналогичными недостатками изобилует абсолютное большинство фреймворков того же назначения. Я работаю с Rails и они позволяют мне заработать на хлеб, но Rails — это лишь инструмент. Как плотник не обязан обожать молоток, а сантехник испытывать нежные чувства к вантузу, так и я остаюсь хладнокровен к Rails. Мне не интересно писать учебник по Rails. У Rails есть хорошая документация по API и Rails Guide. Тем не менее у меня есть идея написать несколько статей критикующих Rails. Я напишу об антипаттернах в коде и API самого фреймворка и об антипаттернах тех, кто его использует.

После того, как я напишу первые 7 статей из учебника Ruby, я начну их публиковать по одной в день, а все старые статьи будут удалены (сейчас их 209).

Что такое SOLID?

мая 4, 2013  |  Published in Новости  |  3 Comments

SOLID — это аббревиатура, в которой содержатся 5 принципов ОО-дизайна.
  • S (SRP) — Single Responsibility Principle
  • O (OCP) — Open/Closed Principle
  • L (LSP) — Liskov Substitution Principle
  • I (ISP) — Interface Segregation Principle
  • D (DIP) — Dependency Inversion Principle

WTF do you mean?

Read the rest of this entry »

Tags: , ,

Let’s use PostgreSQL #1 Installing PostgreSQL on Ubuntu 12.10 & Getting started

января 8, 2013  |  Published in In English, PostgreSQL, Базы данных  |  2 Comments

postgresql_logoA few months ago I throught about migrating from MySQL to PostgreSQL. PostgeSQL has more features and is fast, stable and secure relative DB. And it is also free, open-source and has many different extensions. The main drawback of PostgreSQL is that it is more complicated than MySQL, so you should spend more time to learn how to work with it or hire an admin.

In this series of articles I want to describe how to drop MySQL, start to use PostgreSQL and how to be happy with this powerfull solution without hiring a DBA (only if you doesnt work with big and high-loaded projects).

Let’s start by installing PostgreSQL on your development machine.

I work on Ubuntu Linux 12.10 so I will describe process of installing PostgreSQL on Ubuntu 12.10. To install PostgreSQL 9.2 on your Ubuntu you should use this command in your terminal:

$ sudo apt-get install postgresql-9.2

After installing PostgreSQL you can check PostgreSQL version on your machine:

$ psql —version
psql (PostgreSQL) 9.2.2

So now you have PostgreSQL installed on your Ubuntu 12.10 machine. Read the rest of this entry »

Tags: , ,

<irony>Майкл Хартл — самый ужасный программист в мире!</irony>

ноября 18, 2012  |  Published in Best Practices, Уголок философа  |  11 Comments

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

Собственно из-за того бросания в меня ссылками на Хартла и родилось это название <irony>Майкл Хартл — самый ужасный программист в мире!</irony>. Я надеюсь, что использование тега <irony></irony> спасет меня от «Ты сам мудак! Хартл — няша!» ибо, как показывает практика, людей обидчивых и не понимающих иронию очень много. К Майклу Хартлу я отношусь очень хорошо, он написал хорошую книгу, которую я рекомендовал бы к прочтению всем и хотя у меня есть несколько мелких разногласий с автором, я все же считаю его отличным программистом, а его книгу обязательной для прочтения. Read the rest of this entry »

Tags: , , , ,

О культе карго и хранении денег

ноября 15, 2012  |  Published in Best Practices  |  7 Comments

Вы должно быть знаете о культе карго (cargo cult)? Если нет — в Википедии есть замечательная статья. Культом карго также стало модно называть любое подражание без понимания сути. Члены культа карго подражают человеку или группе людей, которые добились успеха в чем-либо, рассчитывая на то, чтобы добиться аналогичных результатов от своего повторения.

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

Если спросить — Чем тушить пожар? — Большинство не задумываясь ответят — Водой. На самом же деле не всякий пожар можно тушить водой. Например, нельзя тушить водой электротехнику, нельзя потушить водой горючие жидкости, например, бензин или керосин и т.д. Водой также нельзя тушить воспламенившиеся щелочные металлы и много-много чего прочего.

Read the rest of this entry »

Tags: , , , , , ,

Self в Ruby

сентября 8, 2012  |  Published in Ruby, Расширения, Уголок философа  |  5 Comments

Честно сказать, достали меня уже вопросом о том, что такое self. Особено странно, что некоторые люди начинают работать с Ruby on Rails не разобравшись с самим языком Ruby. Ну как так можно? А?! Если лень читать книгу на 600 страниц — есть статьи на RubyDev, они не полностью корректные так как я писал их достаточно давно, но в общем достаточно годные, как мне кажется. Если нет желания прочитать краткие статьи, которые я пытался написать более чем понятным новичку языком, то, я думаю, что программирование — это не ваше. Ну да ладно. Напишу отдельную статью о self, хотя то, что такое self много где упоминалось в статьях на RubyDev.

self — это ссылка на текущий объект.

У каждого метода должен быть приемник — на то он и метод, а не функция, а если приемник не указан, то подразумевается, что приемником является self.

Read the rest of this entry »

Tags: , , ,

Tips&Tricks: Установка gem’ов без генерации документации

сентября 5, 2012  |  Published in Ruby Gems, Tips&Tricks  |  5 Comments

Зачем?

Все мы знаем, что при установке gem’ов часто генерация документации занимает куда больше времени, чем сама установка gem’а, при этом никто не пользуется оффлайновой документацией. Зачем открывать новую вкладку и запускать gem server, если вся документация доступна онлайн? Если вы не пользуетесь оффлайн документацией, то зачем засорять ею жесткий диск и тратить время на ожидание ее генерации при установке gem’ов?

Для отключения генерации документации с командой gem install используют флаги —no-rdoc и —no-ri, например, так:

$ gem install rails —no-rdoc —no-ri

Однако есть вариант получше — использовать файл .gemrc в вашей home/ директории.

Просто добавьте в него следующую строку:

gem: —no-rdoc  —no-ri

И вы забудете о генерации документации навсегда!

Tags: , , ,