Показаны сообщения с ярлыком работа. Показать все сообщения
Показаны сообщения с ярлыком работа. Показать все сообщения

2015-06-11

Про огромный маленький мир

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

Как-то получилось что у меня в ленте несколько лет назад оказалось толпа белорусов из программерской тусовки, среди них был +Pavel Drobushevich

На работе мы решили перейти с YouTrack на TargetProcess. ТР оказался весьма нетривиален и наворочен. Чтобы разобраться в некоторых деталях разработчиков собрали на вебинар, и Steven показывал как они сами работают с TP.

Каково же было мое удивление, когда я увидел знакомую аватарку, а потом вспомнил: Павел писал как он перешел в команду TP. В этот момент меня просто накрыло: специалист из Америки показывает разработчку из России как работать с их системой на примере разработчика из Белоруси. Какова вероятность того что два разработчика знают друг друга, пусть и заочно. В этот момент весь мир показался мне Pale Blue Dot.

2015-04-27

Про Mac и философию системы

Год назад, в связи со сменой работы, срочно понадобилось мобильное рабочее место. Я долго присматривался к Dell Sputnik - но сами делловцы почему-то похоронили проект. Других вариантов ноутбуков с нормальным железом в доступности не было - пришлось раскошеливаться на прошку. Зря сэкономил на памяти конечно - нужно было брать 16 GB.

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

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

Сейчас совершенно другая крайность: вообще ничего не трогать, если это не мешает работать и работать до тех пор, пока система полностью не деградирует. Еще при переезде на убунту пришло понимание, что можно просто не ковырять стопицот настроек меняющие порядок кнопок в менюшке окна, а работать - IDEA везде одинаковая (с оговорками) ZSH с Midnight Commander тоже, браузеры одни и те же, остальное - мелочи, на которые можно не обращать внимание. Достаточно просто принять философию системы и не пытаться сделать из одной системы другую, более привычную или идеально удобную.

Когда сел и занялся первичной настройкой, было сильное дежавю - как будто сел за странную сборку убунту (понятно стало откуда они черпают идеи) в которой всё так же нужно ковыряться через консоль, но при этом возможности настройки довольно ограничены.

Продали мне ноут без рутового пароля, пришлось идти к другу с широким интернетом, чтобы загрузчик выкачал образ и переставил систему. Был жесткий диск, сделал из него тайм-машину, куда раз в неделю по расписанию делаю бекап - за год потратил примерно 700 GB. Один раз восстанавливался после того как что-то очень сильно сломалось. Восстановил почти полностью - остались таки какие-то странные вещи, потом перестал замечать или они пропали. Для сравнения - на винде я образ восстановить так и не смог, на убунте руками восстановил систему до загружаемого состояния потратив день. MacOS восстановилась из бекапа минут за 40.

Очень интересно что еще с переездом на линукс и джаву, полностью сменилась экосистема - куда ни глянь, есть инструкции под линукс, почти такая же для маков и лютые танцы с бубном чтобы запустить это под виндой. По обычному софту не хватает каких-то мелких вещей типа печати выделенного фрагмента, при этом можно докупить того что не хватает за какие-нибудь $19.99. Родной офисный пакет мне сильно напомнил Lotus Symphony - освоить я его так и не смог, пришлось поставить Libre Office по крайней мере он не сильно портит офисные документы. Steam работает как влитой, игори есть, хотя не все. Такого чтобы чего-то не хватало вроде нет.

Итог: великолепное железо, для линуксоидов переезд будет практически незаметным: вместо apt-get будет brew, ну и конфиги будут немного в других местах лежать. В остальном это просто работает и можно говолову вообще не напрягать.

Domain Specific Language

Я уже писал про свои эксперименты с DSL, захотелось подтянуть матчасть и прочитать классический труд. Книга на самом деле состоит из двух книг: первая - введение в DSL и обзор различных техник, вторая - типичный список паттернов, в которую Мартин собрал всё что только можно. Первая часть на пять, позволяет структурировать знания, вторую - тупо пролистал по диагонали.

Зачем нужен DSL? - ... two main ones: improving productivity for developers and improving communication with domain experts. A well- chosen DSL can make it easier to understand a complicated block of code, thus improving the productivity of those working with it. It can also make it easier to communicate with domain experts, by providing a common text that acts as both executable software and a description that domain experts can read to understand how their ideas are represented in a system. This communication with domain experts is a benefit more difficult to achieve, but the resulting gain is much broader because it helps unclog one of the worst bottlenecks in software development—the communication between programmers and their customers.

Главная идея: разделение на Internal и External DSL, необходимость для DSL Semantic Model, которая строится поверх Domain Model. Картинка которая объясняяет необходимость в DSL: даже скомпилированный код нуждается в движущихся частях, которые и обеспечиваются DSL. Здесь же корень стремлений вынести бизнес-логику в СУБД (результат немного предсказуем).

Идеальный вариант языки вида Ruby/Groovy, которые содержат богатые возможности для написания DSL. В любом случае, DSL очень просто можно реализовать практически где угодно, если архитектура приложения будет достаточно продумана: разделение на статическое API и движущиеся части в виде конфигов.

2015-03-17

Богатый папа, бедный папа

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

Товарищ порекомендовал книгу, поскольку про Киосаки слышал давно, взял и прочитал за один вечер. Сначала был в восторге, но потом остыл - появилось много вопросов к терминологии и фактических несоответствий. Не смотря на то, что книга совершенно художественная, написана мотивационным тренером для MLMщиков и про "смотрите как я пришел к успеху, познакомившись в детстве с крутым бизнесменом и начав делать кручу-верчу с недвижкой" - она дает пищу для размышлений, а это главное.

Школа жизни - это что-то вроде толчков, которые ты ощущаешь. Ну и про долги: если вы обнаружили, что закопались, перестаньте копать.



Очень многие не хотят работать "на дядю" и открывают свой бизнес. Если утрировать, низкая ответственность, малый объем информации которую надо держать в голове меняется на большую ответственность и больший объем информации ценой (возможно) большей прибыли. Суть работы от этого не меняется. Каждый день нужно вставать утром чтобы работать работу вне зависимости от наличия условного дяди. Киосаки называет это крысиными гонками. Я ощущаю это состояние давным давно. Характер моей работы не позволяет мне регулировать занятость. Рядом со мной есть много примеров таких предпринимателей, от wannabe успешных людей, которые не вызывают ничего кроме снисходительной улыбки, до действительно что-то создавших.

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


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

P.S. Я давно понял к чему страмиться: хочу стать Ричардом Бренсоном, уединиться на острове, кататься на кайте и думать о том, как сделать мир лучше.

2015-02-26

Мысли об энетерпрайзе

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

Я с самого начала карьеры работал в стартапах, где явно виден вклад каждого и нет лишних людей. Каждый раз когда сталкиваюсь с большими компаниями, меня разрывает противоречие: с одной стороны whatever man has done, man can do - это конечно круто, но стартап не запустит ракету в космос (ок, если конечно CEO не Элон Маск) или не построит супертанкер в силу объемов работу с другой стороны с такой чудовищной неэффективностью работы удивительно, как компания вообще двигается куда-то (достигнув тысячи человек, учреждение становится административно самодостаточным и может само генерировать себе работу). Все помнят историю, как банк снимал табличку.

Общие мысли

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

2 pizza team может двигаться быстро и не тратить время на бесконечных совещаниях, очень мало людей, способных доставить письмо Гарсиа. Команда из таких людей способна свернуть горы.

2015-02-09

Про языки и DSL

Я уже как-то писал про инсайты, приходящие именно в тот момент, когда ты готов услышать их. Хотя большой вопрос: каков вклад счастливой случайности? Может это знание, как тайные знаки всегда было рядом, а ты их смог увидеть и понять, только когда стал готов, а случай подвернется рано или поздно.

2015-01-29

Редактирование истории в git

Этот пост что-то вроде Advanced mercurial но для git. Рано или поздно все сталкиваются с двумя проблемами: у меня куда-то пропали коммиты и я запушил не туда. Во втором случае есть простой случай, когда никто не успел спулить и когда неправильный кормит у всей команды. Все опасаются применять команды с ключами --hard и --force, но это совсем не страшно, если понимаешь, что все обратимо и ты понимаешь чего хочешь достичь этими командами.

Концептуальное отличие от mercurial: в git коммит обязательно должен принадлежать бранчу (без бранча коммит становится detached head), а бранч может быть только один. В mercurial ветки могут быть анонимными, более того может быть несколько веток с одним именем. Чтобы коммит стал виден, должен существовать путь до него из какого-либо бранча. То самое отличие кроны и корневой системы (почему-то именно такая аналогия приходит в голову). В mercurial чтобы коммит был доступен должен существовать путь до него от 0-го коммита, а имена и прочее это мелочи. Соответственно и можно четко проследить начало и конец любой ветви, в отличии от git, где коммиты эфемерные дельты болтающиеся по узлам DAG. Хорошо это или плохо - зависит от, но в централизованной разработке мне больше импонирует mercurial с долгоживущими и вполне материальными ветвями, хотя это не значит что там нельзя редактировать историю - дельта алгебра везде одна. Git же заточен именно под распределенность и множество центральных узлов - помимо ветки foo-branch, обязательно есть origin/foo-branch или another/foo-branch с четким разделением откуда приехал коммит - в mercurial же именование веток сквозное по всем репозиториям, если стянули изменения то они уже ваши и отделить где чьё не получится.

Дальше пойдет описание трех сценариев в демке с github. Демка пошагово демонстрирует работу Алисы и Боба с общим репозиторием. Запускаем, читаем комментарии, жмем батон. Демка должна работать на unix-like системах где есть bash. Кстати, ознакомьтесь со статьей tonsky - прольет свет на внутренности git.

2014-12-13

Пол года с Groovy и Grails

Пол года уже как пишу на Groovy/Grails и пора бы уже сформулировать отношение к этим вещам в письменном виде. Сравнивать буду, естественно, с Python/Django. Совсем немного пощупал cherrypy/jinja когда готовил олимпиаду для студентов, но они не сильно отличаются.
TL;DR версия: groovy восхитителен, джависты, для мелких тасков крутейшая штука, берите и используйте, grails не нравится потому, что рвет связность кода, особенно заметно на больших масштабах и совершенно немодульный.

Дальше будет описание отдельных аспектов и иногда сравнение.

2014-10-25

Про Git и Mercurial

Моя борьба с git длится уже пятый год. Большую часть времени я его просто игнорировал. Последние пол года начал активно работать. Вообще, прекрасная иллюстрация импринтинга: первой системой была svn, а затем произошел переезд на идейного наследника mercurial - после чего git кажется технологией пришельцев. Первые попытки были вынужденными: нужно было попатчить драйвер couchdb для диплома, заслать пару пуллреквестов - каждый раз приходилось открывать шпаргалку и копипастить команды в консоль. Не помогла даже книга Pro Git, пол года назад пролистал еще раз - пока читаешь - все понятно, но повторить не смог бы.

Есть базовая идея, которая лежит в основе, без понимания которой все остальное не имеет смысла. В идеологии git есть один мастер бранч, все остальные - временные недоразумения, которые либо вливаются в главный, либо удаляются целиком, безымянные бранчи не могут существовать (хотя конечно есть reflog). В mercurial, как наследнике svn, бранчи - полноценные долгоживущие сущности, которие живут и после слияния. Поэтому граф git выглядит как корень дерева, а mercurial - как крона. Поэтому в git сложно взглянув на граф определить в каком бранче был сделан коммит, как он попал в текущую ветку и если ли эти изменения в ней вообще.

Другая идея важная для понимания - в git, пока не был сделан merge или rebase, визуально четко разделяются чужие ветки и твои (branch-name vs origin/branch-name) поэтому fetch совершенно безопасен, поэтому push --force деструктивнее, но крайне удобен если понимаешь, что ты делаешь, в mercurial как только коммит попал к тебе, он становится твоим сразу же, поэтому hg strip приходится делать каждому разработчику. Интересно, что mercurial органично впитывает лучшие идеи git: strip, rebase, rebase -i, stash, backup copy при деструктивных операциях - обратного дрейфа не заметно.

После того как освоил инструмент, обязательно начинаешь затачивать под свой workflow. Недавно, задействовав все свое bash-fu, родил монструозный алиас, чтобы понять в каком же бранче находится закрытый тикет (на самом деле главное - смерджен/не смерджен). Делать
git log --grep
git branch --contain
быстро надоело, поэтому легко заменить на
git gb #ISSUE-1234
при помощи
gb = !git --no-pager log --format=\"%H\" --decorate --all --grep=$1 | xargs -I {} sh -c \"git branch --contains {}| paste -sd ',' - && git --no-pager log --oneline --decorate {}^..{}\"

ЗЫ

Великолепный курс от codeschool
Интересная статья от tonsky
Мой .gitconfig

2014-08-29

Three month of rocking whole industry

Motivation

More then four moths passed since I decided to ride the wind of changes which gave me enough momentum to jump out of gravity well and three months with my new team. Next anniversary near but I didn't wrote anything about this. Really changing the workplace is all about will, first and success contact I get in some hours. I got 6 hours of interview in next two week indeed. But first one was great: remote work (so I can stay near taiga and mountains and snow) on foreign (why shoult you limit yourself with one city or even country) startup (big corporation and bodyshops is leaching you passion and energy) and last but not least was IDEA behind company: changing the whole industry of insurance - it was thrilling.

2014-08-07

Про истинный смысл ORM

В программировании есть несколько тем, которые любят объяснять люди не готовые к этому. Мои любимые темы:
* рекурсия на примере факториала - что за бред
* тестирование на примере арифметических операций, которое примитивно до невозможности, чтобы объяснить тестирование нужно сначала вкурить SOLID и рассмастривать сложные примеры близкие к реальности
* ООП на примере калькулятора - не надо натягивать сову на глобус, или графических фигур - чуть лучше, но неопытный объяснятель может не знать про LSP и рано или поздно скатывается в проблему квадрата-ромба. Еще одним открытием может стать множество видов полиморфизма. Чтобы объяснить параметрический полиморфизм, нужно сначала понять обобщенное программирование. Проблема курицы и яйца. Сюда же rich vs anemic, AOP и другие вопросы.
* Что-то мне подсказывает что большая часть статей про монады объясняют совсем не то что нужно.

Недавно меня накрыло на тему ORM. Главной причиной всех танцев с абстракцией от БД подается возможность легко заменить базу данных. Что?! За?! Бред?! За все годы работы я видел две смены БД в проекте: с Oracle 9 переехали на Oracle 10 XE, а с MySQL переехали на MariaDB. Под этим флагом идет безнадежная борьба за чистоту запросов: только JPQL/HQL, скажем нет нативным запросам. Вдруг мы захотим сменить БД. К сожалению, рано или поздно наступает момент, когда выразить запрос средствами ORM становится невозможно, либо он достигает совсем неприличных размеров и, скрепя сердце и зажмурившись, программист пишет нативный SQL.

Внезапно все меняется, если посмотреть на ORM как на оптимизатор рутиного CRUD-а и не более. Если для сложной выборки быстрее написать SQL, то не нужно мучить ORM, рядом можно нарисовать DTO-шку, чтобы ORM закинул в него данные. Пуристы забывают про то что это нужно для экономии времени и сокращения количества ошибок в программе со 100500 формочками. Время машины стало дешевле времени человека и мы можем себе позволить неэффективность в маленькой области, выигрывая в целом.

2014-06-17

Volere: Mastering the Requirements Process

Пол года назад vit-r посоветовал литературу по сбору требований. Тема сбора требований и написания технического задания меня очень интересовала в то время - спустя пару лет блужданий в потемках у нас начали получаться технические задания. А что такое получаться? - это когда фактическое время не сильно превышает планируемое и сам результат не сильно отличается от того, что планировали - никаких подводных камней, выкинуть все и переписать.

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

2014-06-01

Про свободу и преданность работе

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



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

Свобода внутренняя и внешняя

Постоянная конкуренция в лицее воспитала из нас индивидуалистов и научила сотрудничеству тогда, когда конкуренция не нужна. Имя собственное начало что-то стоить. Некоторые гордятся тем что закончили известное учебное заведение при этом никак себя не проявив (я постоял рядом с запуском ракеты), мы же гордились тем что в славном имени есть часть наших успехов. Так закрепилось разграничение между личными успехами и коллективными.

Когда мы выпускались, то набравшие больше 85% на итоговом тестировании, могли подать заявление на программу Болашак. Обучение в любом зарубежном вузе, но обязательство отработать 5 лет в Казахстане. Для меня выбор был очевиден: свобода не стоит этого. Я не хочу брать на себя обязательства. Выбирая университет, я выбрал менее крутой, но зато у меня было бы больше свободного времени, которое я могу посвятить развитию.

Когда сотрудник (см выше определение бенефициара) сильно предан компании, излучает любовь, я с уверенностью могу сказать что он променял внутреннюю свободу на деньги, власть, ответственность, доверие, крутую задачу, возможность реализовать какую-то мечту, карт-бланш, вотэва - масштаб и потребности у всех разный, главное чтобы человек почувствовал себя обязанным. Фразы-маркеры: "компания дала тебе возможность", "компания тебя вырастила", "компания доверила тебе", "компания - это семья", "таы должен пожертвовать немного личного времени". Для меня чувствовать себя обязанным кому-то абсолютно некомфотно, когда же это чувство иррационально, то это некомфортно в квадрате. Человек может освободиться только нарушив внутренние принципы (ага, неприступная крепость в голове у человека). Вопрос может ли заниматься творческой деятельностью несвободный человек остаётся открытым.

Гораздо приятнее равное партнерство: я готов с вами работать потому, что наши интересы совпали на этом отрезке пространства и времени, как только сотрудничество перестанет быть взаимовыгодным, наши пути разойдутся. Останется чувство удовлетворения от выполненной работы и ни капли обязательств. Как было круто на заре карьеры подрабатывать: ни бумажного договора, ни обязательсв - два джентельмена договорились о сотрудничестве, которое было взаимовыгодно на протяжении трех лет. В большую компанию я так и не смог интегрироваться и начать говорить МЫ. Хотя, говорить что работаешь в большой компании гораздо приятней, чем в маленькой и никому неизвестной.

Выпас котов

Профессионалы (те, кого я вижу вокруг) внутренне мотивированы, обаладают широким кругозором и собственным мнением. Есть лишь одна проблема: большие риски. Такого человека сложно найти, сложно заменить (хотя за шесть лет наблюдений я ни разу не видел, чтобы уход даже самых казалось бы важных специалистов приводил к катастрофе). Невозможно масштабировать компанию индивидуалистов - её просто разорвет центробежными силами. Поэтому только взаимозаменяемые середнячки и специалисты по гайке на 12. Хотя некоторое количество таких людей полезны, особенно если они привязаны.

Про взаимовыручку

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

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

Есть руководители, защищающие своих бойцов, но это плохо, потому что рискованно, потому что связь этих людей друг с другом теснее, чем с компанией, а что если они разом встанут и уйдут - это плохо для бизнеса. Тут я вспомнил что это писали ДеМарко и Листер в Человеческом факторе - надо будет еще раз перечитать.

Заключение

Это не хорошо и не плохо, just a business. Некоторые принимают правила игры, некоторые нет. Протой тест на свободу: вы можете написать заявление и уйти в команию работающую в этом же городе на соседней улице (чтобы исключить из уравнения лишние факторы)? Что именно вас сдерживает? Не можете? - поздравляю, сделайте с этим что-нибудь. Начните с резюме, пообщайтесь с хантерами - это позволит взглянуть out-of-the-box, узнать себе реальную стоимость, посмотреть на возможности, которые совсем рядом. Не обязательно при этом что-то менять, но вы почувствуете себя гораздо свободнее в диалоге.

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

2014-04-28

Прощание на оранжевой волне

15 сентября 2011 года я, будучи молодым и самоуверенным (как же я ошибался: Always wanted to travel back in time to try fighting a younger version of yourself? Software development is the career for you!), пришел в команду новорожденного проекта Orange[UC]e. Мы собирались унифицировать (буква U) коммуникации (буква C), One ring to rule them all. На пути к этой амбициозной цели многие идеи не выдержали испытания реальностью, только спустя два года блужданий в тумане мы нащупали путь и, наконец, создали реальную вещь, которую можно отдать клиентам, за которую можно поручиться, поставить в продакшн и не бояться, что клиенты взорвут службу поддержки, начать пользоваться самим. Вещь, которой можно гордиться в конце концов, потому что люди ей пользуются, люди довольны и хотят большего. 

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

Примерно раз в пол года, как раз после отпусков, на меня нападала меланхолия и неясно тянуло куда-то вдаль, но каждый раз я открывал очередную ступень развития и с радостью кидался на освоение. Наблюдение за жизнью проекта на протяжении значительных промежутков времени необычайно ясно показывает, какие идеи выдержали испытание временем, а какие нет. Наблюдать продукт от initial enthusiasm, до scale: 25 стабильных релизов - от идеи, до выкатки клиентам. Это всё, поистине, бесценный опыт.

Как я уже говорил, для меня необычайно важна команда. Компания перешла на новый этап, пришли новые люди, но ощущения единства растворилось. Послеотпускная тоска была просто невыносимой и, увидев ряд знаков, я понял: настало моё время уходить. Я ухожу без страха за продукт - апельсин настолько повзрослел и набрал импульс, что ему не страшны никакие невзгоды в обозримой перспективе (успеха вам, апельсины). Но ухожу с грустью в сердце, потому что я не буду работать бок-о-бок с такими замечательными людьми как Максим (удачи тебе на новом месте), великолепный собеседник, источник опыта и пример для подражания решительно во всём; Пишник и Миха - неизменные собеседники на обедах всё это время; Дед - старый товарищ, не смотря на то, что наши пути расходятся всё дальше и дальше; Машенька - просто замечательный человек; Викуся - источник жизнерадостности; Наташа - неизменная соучастница и активистка еженедельных тусовок; Танюша - компаньон во многих спортивных дисциплинах. И многие другие, с которыми я общался не так активно, но всегда с удовольствием. Недеюсь, мы продолжим общаться и дальше. Отдельное спасибо Лео и Ольге за... пусть за то, что сделали меня мудрее.

So Long, and Thanks for all the Fish

2014-03-09

Про лямбды и API

Dive into lambdas

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

2014-02-12

Прикладная топология в исходном коде

Не развидеть

Бывают такие вещи, которые, однажды увидев, начинаешь замечать абсолютно везде. Для меня недавно таким открытием были теги {@see} и {@link} в джавадоках. Я неистово стал превращать исходники в такую вики. Параллельно сделал другое открытие, код не изотропен, связность пространства нарушается: попав из точки А в точку Б, я не всегда могу вернуться назад с той же скоростью - приходится обходить иерархию или вспоминать назание класса (черт возьми, у меня в активной памяти буфер на 7 элементов, названия класса из него выталкивается, даже если я пререшел из него десять секунд назад), чтобы по Ctrl+N перейти на него. Тут не спасают даже линки в джавадоках. Дальше я собрал подборочку таких моментов с реальными примерами.

2014-02-09

Заставившие задуматься эпизоды из жизни эникейщика

В очередном капитанском посте у jdevelop увидел старую эпичную ссылку про инженерную археологию и реверс-инженеринг завода. Сразу вспомнилось несколько кулстори из жизни эникейщика, произошедших на заре карьеры: такие себе инсайты, заставившие крепко задуматься о происходящем и мысленно провести After Action Review.

2014-01-04

Круто побывать на производстве

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

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

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

2013-12-11

Про Ubuntu и клиническую смерь панголина

Про убунту

Убунта (хотя, пожалуй, это свойственно почти всем дистрибутивам) похожа на лоскутное одеяло, состоит из кучи софта, разрабатываемого разными людьми. Стандарты? ЛолШТО? Есть, конечно, FHS, но всем плевать. Без интернетов под рукой восстановить систему после нетривиального падения не реально. Куча файлов со своим уникальным именованием, куча ключиков и параметров.

Самый эпичный момент был при обновлении до 12.04: из-за проблем с оборудованием, Космонавты выпилили режим гибернации из-за проблем с некоторыми версиями материнок. Включается он эпичнейше: не переключателем (как сделали бы разумные люди), не раскомментированием строк в каком-нибудь конфиге (как сделали бы разумные, но ленивые люди), а воссозданием конфига. Когда я это прочитал, единственная мысль была: НО? КАК? БЛЯДЬ? Я должен был бы его воспроизвести без интернета???

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

2013-12-08

Groovy shell в веб-приложении Java

Доступ к доменной модели

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

POC веб-консоли

Но хочется большего. В серверных приложения за время работы может накопиться невоспроизводимое состояние, либо в целом приложение начинает вести себя неадекватно. Основной способ борьбы - выводить подробные логи, а потом вдумчиво курить стектрейсы, строя гипотезы, как исключение могло возникнуть. А потом перезапустить приложение. Но что если доступаться к живому приложению? Возможности по съему телеметрии стали бы неограниченными: нам доступно для чтения и изменения все состояние живого приложения (правда неосторожными действиями можно его легко убить).