Уголок философа

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

декабря 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 нейронов, «сердце» является достаточно абстрактным компонентом для того, чтобы иметь возможность использовать его как в свинье и в обезьяне или в человеке.

 

 

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

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

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

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

Tags: , , , ,

Self в Ruby

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

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

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

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

Read the rest of this entry »

Tags: , , ,

Святой Грааль разработки ПО

ноября 27, 2011  |  Published in Уголок философа

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

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

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

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

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

Выходя из утверждения работа = деньги можно прийти к выводу, что чем больше денег ты зарабатываешь тем лучше, однако это не всегда так. Кому-то важнее деньги, а кому-то комфорт. Каждый выбирает свое. Лично я заинтересован в работе над интересными проектами в дружной атмосфере, но это не значит, что я готов работать за копейки. Каждому труду есть цена и каждый человек за свой труд должен получать адекватный проделанной работе кусок пирога. Много денег не бывает и много никто не заплатит, разве что дурак какой-то. Работодатель должен платить в соответствии с производительностью рабочего. Чем лучше ты программист — тем больше у тебя производительность и тем больше ты получаешь. Арифметика простая, хороший программист — это такой, который больше зарабатывает, а не тот, который следует всем практикам Мартина Фаулера, покрывает код на 200% спеками и тестами и находит время поддерживать несколько open-source проектов.

Желание стать совершенным программистом в край глупо. Правильное желание — иметь отличную в плане коллектива и проектов работу с достойной твоего вклада оплатой.

Если тебя не тошнит от работы и ты чувствуешь, что получаешь ровно столько, сколько заслуживаешь, поздравляю! Ты нашел золотой Грааль!

— Мое субъективное мнение.

Революционная формула борьбы с ленью. 100% гарантия!

ноября 19, 2011  |  Published in Уголок философа

Нет более закаленных в разговорах о лени людей чем сами лентяи. Одни любят оскорблять себя — Боже мой, какой я ленивый, неудачливый мудак. Другие, предпочитают рассказывать об этом как о некой форме наркомании — Ничего не могу с собой поделать, прыгаю туда-сюда из Вконтакта в Ютьюб, из Гугл+ в Одноклассники из видео с чихающей пандой к фирменному посту в ЖЖ от Сергея Доли или Темы Лебедева. Третьи абсолютно смирились с ленью, их абсолютно устраивает то, что они обречены на ничтожное существование или у них имеется папа с толстым кожаным кошельком, который всегда готов финансово помочь своему любимому чаду.
Read the rest of this entry »

Tags: ,

Об идеальной веб-студии

августа 14, 2011  |  Published in Уголок философа

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

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

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

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

Термоядерное вооружение на службе добру

августа 10, 2011  |  Published in Уголок философа

Вы можете поймать муху палочками для еды?
Вы можете простоять в позе журавля трое суток?
А отжаться стоя на мизинцах?

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

Вполне закономерный вопрос: Зачем мне ловить муху палочками?

В ответе гуру на ваш вопрос будет говориться о совершенствовании души и тела, о бесконечном светлом стремлении к совершенству, о величестве духа человека ловящего мух палочками для еды, об очищении кармы и т.д., но толком ответа не даст, а ответ таков: ловить палочками для еды мух необходимо только для того, чтобы стать гуру, зачем — это уже другой вопрос.
Read the rest of this entry »

Tags: ,

Этапы развития программного проекта

августа 3, 2011  |  Published in Development Processes, Уголок философа

Сейчас я разрабатываю собственную CMS на Ruby on Rails и поскольку у меня не много опыта решения задач касательно архитектуры приложения, да и разработки в целом, я сталкиваюсь с множеством вопросов касательно организации архитектуры приложения. В игру вновь вступает вредный перфекционизм, который вновь и вновь растягивает время разработки. Наконец-то собравшись с мыслями я сформулировал для себя жесткие правила процесса разработки.

1. Делай чтобы хоть как-то работало!
Если проект работает хоть как-то — это уже лучше, чем когда его совсем нету. Множество ошибок, неправильная архитектура, множество различных хаков, множество повторяющихся фрагментов кода, множества непроизводительного кода и т.д. — все это лучше, чем когда вообще ничего нет!
Read the rest of this entry »

Чужой vs Свой код

июля 23, 2011  |  Published in Уголок философа

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

Рассмотрим все плюсы и минусы использования чужих и своих решений.

Плюсы решений сторонних разработчиков:

- Значительная экономия времени на разработку.

- Вы получаете уже протестированное и проверенное решение.

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

Плюсы собственных решений:
- Вы отлично знакомы с кодом своего решения и вам не нужно изучать чужое решение.

- Собственное решение является более органичным относительно приложения.

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

Минусы сторонних решений:

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

- Сторонее решение невсегда хорошо вписывается в архитектуру приложения.

- Очень часто требуется очень сильно дописывать строронее решение.

- Требуется время на изучение стороннего решения.

Минусы собственных решений:

- Необходимо относительно значительное время на разработку, тестирование, исправления и рефакторинг собственного решения.
Честно говоря, мне больше нравится вариант, когда собственные решения комбинируются со сторонними. Например, мне не придет идея писать свой фреймворк, однако мне пришла идея писать свою CMS на Rails и скорее всего в ней будет использоваться собственное решение для авторизации и аутентификации, однако много чего будет взято со стороны: JQuery, возможно Apotomo  и т.д.

Очень интересно мнение читателей по поводу использования своего решения или стороннего.

Tags:

Уголок философа: Принципы и Адаптация

мая 12, 2011  |  Published in Уголок философа

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

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

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

Когда реакцию на любую ситуацию человек не обдумывает, а поступает по шаблону, то часто может оказаться, что он противопоставляет себя. Быть принципиальным — означает находиться в напряжении, принимать не всегда лучшие решения и подвергаться риску. Read the rest of this entry »

Tags: