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 — крупнейшее ruby-событие года, уже несколько лет подряд собирающее вместе лучших ROR-разработчиков со всей России, именитых спикеров со всего мира и актуальные темы для обсуждения.

       В программе

 Аарон Паттерсон, член 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

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

Посетить 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