Category: Notes

[Linkset] «Stringly typed» Antipatern: Avoid string where other types are more appropriate

Conditional Verbosity With Temporary Log Queues

I found a great advise in article Optimal Logging and it worth to mention separately:

When errors occur, the log should contain a lot of detail. Unfortunately, detail that led to an error is often unavailable once the error is encountered. Also, if you’ve followed advice about not logging too much, your log records prior to the error record may not provide adequate detail. A good way to solve this problem is to create temporary, in-memory log queues. Throughout processing of a transaction, append verbose details about each step to the queue. If the transaction completes successfully, discard the queue and log a summary. If an error is encountered, log the content of the entire queue and the error. This technique is especially useful for test logging of system interactions.

It’s cool idea, I’ll try in practice.
And Michael Würtinger created a SLF4J extension for doing it.

Код стайл не только для читаемости но и для редактируемости

Тема код стайла очень хорошо раскрыта в замечательной книге Clean Code.
От себя я бы хотел обратить внимание на пару не очень очевидных вещей к которым пришёл со временем.

  1. Во первых это вертикальная плотность кода (Vertical Density). Где-то я слышал что программист не может в голове держать больше 400 строчек кода. Собственно это и есть лимит на количество строк в вашем файле. Если больше — разбивайте на другие классы.
    Скролить файл вниз — утомляет. Более того, иногда похожие или связанные методы идут рядом и хотелось бы их сразу видеть рядом.
    Ещё один момент — обычно вертикально идут сами команды а горизонтально их параметры.
    Обычно когда ты смотришь в код тебе более важно понять логику и последовательность команд а не их уточнения.
    По сути это визуальное отображение принципа High Cohesion (Сильное Сцепление).
    Поэтому я начал очень сильно следить за вертикальной плотностью и несколько следующих принципов вытекают из этого требования.

  2. Принцип неразрывности — когда вы избегаете писать пустые строки внутри методов потому что обычно являются запахом что тут следовало бы экстрактнуть метод.
    В IntelliJ Ctrl+S > Code Style > Java > Blank lines всё выставьте по нолям или максимум 1

  3. Не переносите строки: сегодня у нас очень широкие мониторы и уже следует избегать переносов команд на две строки. На моём мониторе спокойно влезает по 256 символов. Это более чем достаточно, но обычно IDE переносят строки по границе в 120 символов. Более того, обычно если у час всё равно длинная строчка и не влезает полность на экран то это не страшно — обычно там идут неинтересные параметры вызова метода. В любом случае горизонтально скролить приходится в тысячу раз реже чем вертикально.
    Поэтому сразу полезайте и отключайте эти переносы или ставьте им границу в 400 символов.
    В IntelliJ Ctrl+S > Code Style > General > Right Margin

  4. Джавадоки тоже пытайтесь делать однострочными.
    Т.е. вместо

    /**
    * Some method description
    */
    void someMethod() {
    ...
    }
    

    пытайтесь писать так

    /** Some method description */
    void someMethod() {
    ...
    }
    

    В IntelliJ Ctrl+S > Code Style > Java > Java Doc > Do not wrap one line comments

  5. Отключите выравнивание (arange) кода. Очень многие IDE по умолчанию наводят «красоту» и выравнивают (тут я отметил нижним подчёркиванием _)

    void someMethod() {
    def params = [
    firstName:_'John',
    lastName:__'Doe',
    age:_______42
    ]
    }
    

    С одной стороны принято считать что это добавляет красоты и читаемости. С другой стороны, если вы удалите например первую строчку то вам придётся перевывравнивать соседние сточки и эти изменения подзагадят вам diff в системе контроля версий.
    В IntelliJ Ctrl+Alt+S > Code Style > Java > Wrapping > Align when multiline

Вместо заключения

На стиль кода влияют несколько вещей:
1. Удобство чтения кода — большую часть мы код читаем
2. Возможности IDE — очень многие вещи они могут отображать более удобно (сворачивать гетеры и сетеры, копирайт заголовки, импорт лист).
3. Система контроля версий — очень важно чтобы изменения были как можно более атомарными и в diff’е не было слишком много строк чтобы было проще понять суть.
4. Дебагинг — иногда лучше вместо method chaining выделить переменную потому что дебагер идёт построчно.

Проблемы OpenJDK или в очередной раз про идиотизм Orcale

Ну для начала лекция для тех кому интересно въехать в курс дела:

У меня к OpenJDK есть такие претензии:
1. Название, я поначалу подумал «ну вот ето JDK а мне на сервер достаточно только JRE» и искал OpenJRE 🙂
2. Сайт: посмотрите на сайт Mono http://www.mono-project.com/ — красивый, всё ясно куда нажимать. А теперь посмотрите на это уродство http://openjdk.java.net/ . Я не дизайнер, и неприхотливый но даже меня тошнит. А ведь это же маркетинг!
4. Почему IDEA упорно не дружит с ним? Это меня настораживает — вы говорите что OpenJDK на 99% соответсвует обычной OracleJDK, но идея пишет что будут проблемы с графикой. Это правда? В чём причина? Напишите JetBrains чтобы они убрали это сообщение.
5. Где версия под Windows?
6. Отправлять патчик по мылу это прошлый век — перенесите проект на GitHub!

До сих пор у всех осталось отношение к OpenJDK как к кастрированому форку православной сановской Явы.
Боюсь чтоы избавится от этого его прийдётся переименовать и впихнуть в него что-то модное чтобы пресса рассказала о нём как о прорыве.

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

Ruby, Ruby, Ruby, Ruby! And do ya, do ya, do ya, do ya!

Просто несколько вещей которые бесят постоянно. Можно расписывать их много, но тут я акцентирую внимание на том что уровень вхождения в Яву выходит большим из-за банального разгильдяйства Oracle. Неожиданно, но они совсем не учитывают что платформу нужно ПРОДАВАТЬ, и очень важен маркетинг. А ведь ещё «корпорацией бабла» называются 🙂

JDK, JRE — WTF?

JDK содержит в себе полную JRE + SDK (компилятор, декомпилятор, дебагер и.т.д). Тем не менее, вместо того чтобы ставить отдельно SDK, всегда приходится полностью выкачивать JDK содержащий JRE.
Самое интересное, что теперь у нас есть OpenJDK, и несмотря на JDK в названии он же и JRE. Я окончательно запутался.

Is Java open soure?

Принято считать, что Java открытая платформа. Что можно считать открытой платформой? Сам язык Java, насколько я в курсе это вполне проприетарная технология. Открытые исходные коды — это ещё не значит что это открытая платформа. Например разработка Android ведётся в строжайшем секрете и ты не знаешь чем тебя удивит Google в следующей версии. Но так-то исходники открывают, да.
Изначально SUN не хотела выкладывать исходники Java из-за того что те содержали какой-то патентированый код. Я не очень понимаю почему это было большой проблемой. Можно было выложить то, что можно, а запатентированный код либо переписать, либо выделить в отдельный модуль. В принципе так вроде и сделали в результате чего получилась OpenJDK. Но тут есть ключевой момент: OpenJDK — это отдельный проект. Его нужно отдельно расскручивать, у него отдельный сайт, своё сообщество и, что потенциально опасно, свой код который может начать отличатся от того что внутри оракловой JDK. И тут сразу возникает следующий вопрос…

OpenJDK == Oracle?

На конференциях парни из Oracle утверждают что OpenJDK это на 99.9% тоже что и Oracle JRE, и что они вообще билдятся из одних исходников. Тем не менее, IntelliJ упорно отказывается работать с OpenJDK и запугивают проблемами с производительностью. Наверное тут дело в криворукости JetBrains, но всё равно настораживает.
Тем не менее, все продолжают использовать именно OracleJDK

Oracle принципиально не делает дистрибутива для Debian, а только для своей Solaris.
А в Ubuntu выпилили этот пакет, в результате каждый раз установка джавы превращаются в пляску с бубном: нужно прописать сторонний PPA, в котором инсталятор Java, который за тебя выкачивает её из сайта Oracle и устанавливает. Естественно такой пакет из стороннего PPA нельзя использовать как зависимость в своём пакете.

  1. На сайте Оракла чёрт ногу сломит, всё страшное и некрасивое. Ещё и вымагают регистрацию. Никакой заботы о пользователях, никакого маркетинга.
  2. Почему-то инсталятор сам не прописывает переменную JAVA_HOME и JDK_HOME. Что ему, жалко что-ли? Вообще переменные окружения это большое зло, может уже пора искоренить их вовсе?
  3. Успех платформы во многом зависит от наличия пакетного менеджера в поставке с ней. В Ruby есть gem, в NodeJS — npm. В яве ничего.
  4. Туториалы на оф. сайте стары как мир, без подсветки синтаксиса и никакого интерактива.

Как так получилось что откровенно поганая платформа Ruby стала такой модной и популярной? Умелый маркетинг.
Посмотрите на сайт например Mono, он выглядит приятней и опрятней, пускай это аутсайдерский проект, но даже там пытаются хоть ка кто для людей сделать.
Я уже молчу про прямого конкурента Java — платформу .NET.
На сайте много всячины и сразу же баннер на Visual Studio.
А теперь гляньте на Web 1.0 сайт явы. Фу!
Кстати, тоже самое касается самого языка программирования.
Если MS в целях маркетинга впихнул всё нужное и ненужное в C#, то в Яве даже самые нужные фичи добавляют с огромным скрипом. Вот например, лямбд все ждут уже десятилетие, и вот уже наконец в восьмой Яве будут.
Конечно, Ява по философии консервативна и стремится быть минималистичной, но не до такой же степени чтобы ждать пятой версии для for each циклов.

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

Маркетинг господа. Если вы ещё не поняли, то в постиндустриальной эпохе это самое главное.

Блин, да как же всё таки обучить программистов?

А как научится танцевать балет? А как выучить английский? А как научится писать романы?
Берёшь, и делаешь, делаешь, делаешь. Только практика. Но просто практика помогает только по началу.
Дальше нужно чтобы тебя кто-то скорректировал. Поначалу ты привыкнешь делать неправильно, и твой наставник должен тебя отучить от этого.
Дальше нужно постигнуть несколько базовых принципов чтобы понять как делать работу лучше.
Например в программировании базовый принцип прост:
Ты пишешь для других: давай правильные названия, не усложняй, пиши комментарии.
Осознание этого просто принципа рано или поздно тебя приведёт к правильным книгам или менторам которые просто расскажут пару трюков как этого достичь.
Ты всё равно будешь краснеть за свой код написанный месяц назад, но при этом ты всегда будешь знать к чему стремиться.

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

Человеческий мозг — это компьютер, сложный и тем не менее прямолинейный.
Мы запоминаем только то, что повторяем. И если не повторяем — забываем. Очень просто, правда?
А теперь мы берём студента, пичкаем его знаниями: структуры данных, дискретная математика, исследование операций, ТАУ, схемотехника, ООП, сети.
По идее должен выйти отличный инженер, правда? Истина в том что знания почти никак не влияют на профессионализм. Ты либо программист. либо нет, всё тут. И ты был таким всегда, с рождения!
Это нейрологическое свойство твоего мозга которая просто нашло максимальное своё проявление в случайно оказавшейся полезной специальности.
Знание микросхемотехники мне никак вообще не пригодилось. Когда мне было интересно как устроен компьютер я прочёл и изучил схему полусумматора и понял. Мне этого хватило. То что есть JK и T триггеры для меня бессмысленный багаж знаний. Вообще всё что рассказывали оказалось бессмысленным — я просто этим больше не занимался. И почти всё забыл, то что написано в моём дипломе магистра теперь полная ложь.
И это правильно, это механизм выработанный миллионами лет эволюции!

Я даже забыл как в столбик делить, а недавно объяснял тестировщице основы программирования, хотел написать решение квадратного уравнения и… вот вам сейчас слабо вспомнить формулу x1? Мне пришлось глянуть в Википедию, вспомнить.
Глянуть в интернете у меня заняло 30 секунд. Зачем было меня напрягать 11 лет в школе?
Вся стоимость полученных мною знаний в школе это те 50 центов стоимости микрочипа памяти.
И всё всегда реально выучить и сделать как только попадается задача. Да да, как в том анекдоте «Завтра экзамен по китайскому, а мы не учили. Учебник есть? Да. Тогда сдадим!».
При этом, я уже самостоятельно выучил столько технологий, идей и концепций, что хватило бы на десять высших образований.

Теперь вопрос: зачем вообще обучать чему нибудь если оно забудется? Да ещё и пять лет!?
Пять, пять сука лет! Пять лет молодости, самого эффективного возраста.
Вместо того чтобы зарабатывать деньги, любить, завести семью мы тратим нашу жизнь на «заучил, сдал, забыл».

Люмпен пролы хоть год в бурсе, ещё один в армии и на завод, и уже живут. И уже рожают строителей идиотократии.
Вам, уже даже фильм сняли в Голливуде, с Тимберлейком и грудастой актрисой, как ещё вам, идиотам, объяснить чтобы вы поняли насколько время ценно?

Всё очень просто: обучать нужно маленькому кусочку знаний и сразу отправлять работать. Причём нужно сделать это очень быстро и чтобы максимально эффективно и чтобы студент на выходе гарантировано мог устроится на работу пока не забыл.
Хоть кем-то хоть куда-то. Главное прыгнуть в поезд, а там ты уже перейдёшь по вагонам и выберешь себе место.
Может оказаться что ему вообще уже программирование не прёт, зато ему интересно организовывать работу программистов и из него может выйти хороший менеджер проекта или сисадмин. Первая работа — как правило этот совсем не то что ты хочешь на самом деле. Ты ещё не знаешь сам что есть и что тебе лично интересно: игры делать, банковский софт или трояны. Зачем пять лет тратить на то, что тебе может и не понравится?

Доучится и перейти — не большая проблема. Я выучил Яву и перешёл на неё с Делфи за две недели. Ходил на собеседования и получил за это время два офера! Да у меня был опыт двух-трёх хелоуворлдов на Яве до этого, как впрочем и на Плюсах и на Си Шарпе. Всё равно, за две недели вникнуть в тонкости которые как раз и спрашивают на собеседовании это было сложно, но возможно.
Скажите я гений? Тогда как объяснить похожий успех у Игоря Цинько?

Да, я сейчас учусь: хожу на тренинги, конференции, читаю книги, блоги. Но только когда мне что-то либо интересно либо нужно по работе. Потому что иначе просто бессмысленно.
Когда на Coursea начали выкладывать курсы, я был в восторге и записался на курс криптографии. После двух занятий бросил.
Зачем оно мне? Основы мне отлично объяснил один из крутейших криптографистов Евгений Василенко, который вообще-то по образованию (сюрпайз!) геолог.
Я уже знаю что такое (а)симметричное шифрование, что за алгоритм Диффи Хелмана, что такое хеш, сеть доверия, что такое цифровая подпись. А больше я на практике и не использую. Зачем мне знать про эллиптические кривые?

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

Зачем вообще ходить на лекции в университет, если их можно записать? Зачем проводить экзамены?
У экзаменов есть два смысла: метрика чтобы студенту помочь следить за своими успехами и сертификация — когда государство поручается за твои знания.
Сертификацию можно делать вообще добровольно и только один раз. Зачем каждый семестр поддавать студентов стрессу?
Прочти все проверки заданий можно делать на компьютере в виде тестов.
Для программного кода в виде юнит тестов которые заранее выдать.
Проверки преподавателем можно свести до минимума.
Зачем вообще ходит в институт каждый день?
Зачем вообще держать огромные здания университетов? А ведь они занимают обычно огромные территории да ещё и в лакомых землях центра города.
Давайте их снесём лучше и на из месте построим дом элитный, или супермаркет или общественный туалет.
Да, общественные туалеты для нас важней университетов. Я серьёзно.

Этой зимой я помог Виктору Кучину провести тренинг Java интенсива. За три неделе мы вместе с джунами вместе разрабатывали сайт. Только нужные технологии для выполнения работы в 80% компаний. Только нужные навыки. Практика, парное программирование.
У всех на выходе из курсов было составлено резюме, и в нём был указан реальный опыт на реальном проекте.
Все уже почти готовы к устройству на работу, только ещё самостоятельно заучить ответы на стандартные вопросы.
Сами того не зная, мы с Виктором действительно нашли правильный и наверное единственно верный формат обучения.
Я действительно глубоко переосмыслил что мы сделали и окончательно в этом убедился.
Вам даже сложно представить сколько всего перемолол мой мозг чтобы удивится поняв что мы интуитивно всё сделали правильно!
Может этот текст вас не убедит — это всего лишь заметка перед сном, вершинка айсберга, но я знаю что говорю, мне можно верить и я буду ещё много об этом говорить и писать.

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

Читайте продолжение: Здания университетов нужно превратить в туалеты! Без шуток

UPD
Эта заметка не смотря на неполноту и желтушность вызвала обсуждение. На меня посыпались кучи аргументов которые к сожалению в основном являются просто закостенелыми мифами и стереотипами. Градус неадеквата в таких дискуссиях быстро нарастал и мои оппоненты то и дело подтверждали закон Годвина да ещё не обошлось без Сталина.
Сегодня многоуважаемый мной тренер по программированию Николай Алименков написал отличную статью где выступил в защиту ВУЗов.
Николай мой кумир и один из основателей тренингового центра XP Injection, организатор многих конференций и киевского клуба программистов, и каждое его слово — золото, и к нему стоит прислушаться. Но к сожалению ничего нового в его статье нет, зато старые утверждения описаны очень хорошо.
Забавно что как раз все эти аргументы легко переводятся в обратную сторону против ВУЗов. Кстати сам тренинговый центр XP Injection я как раз и ставлю пример замены ВУЗов 🙂
А вот и мой ответ: Всё таки есть хоть какая нибудь польза от вузов?.

И ещё один: Единственная польза оффлайн вузов – это теоретически эффективный нетворкинг

Memento mori

Год назад мой брат Андрей рассказал про доклад Design for Repleceability  на конференции JavaZone. Вчера в разговоре он опять вспомнил про неё и я наконец посмотрел его и настоятельно советую его теперь посмотреть всем.
The most important question to be asked when developing a new software system is «How will we replace it?» It is however a question seldom asked. Instead organization focus on reusability, which unfortunately helps create rigid and inflexible architectures. The talk shows how to design systems made up of small parts, why you should standardize on protocol and not platform and how you will end with a system that is easier to scale and maintain.
В двух словах идея следующая: Если вы будете думать о смерти своего продукта то он станет лучше. А проект умрёт, причём довольно быстро.
Если вы напишите программу которая будет проживёт десять лет то вы станете очень богатым человеком
Так вот, чтобы не переписывать всю систему, то нужно использовать SOA архитектуру и разбивать на отдельные приложения-модули, например модуль авторизации, модуль админки и публичная часть сайта.
В любой момент вы можете заменить модуль, переписать его на новых технологиях а то и вовсе на другом языке программирования.
При этом если они все модули работают с одной базой то это всё равно одно приложение, потому что вы не можете безопасно отключить его и делать с ним всё что захотите.
Модули будут общаться по протоколу. Желательно очень простой протокол типа REST+JSON а не замудрённый SOAP.
Но у REST нет такого механизма для описания своих параметров и методов как WSDL файлы в SOAP.
На самом деле есть — WADL, но о нём никто вообще не знает и похоже стандарт мёртв.
Для решения этой проблемы вы просто на каждый сервис генерируете обычную XHTML страничку со всеми параметрами запроса. Любой человек сможет её понять.
Поскольку ваши приложения живут независимо то вы получаете горизонтальное масштабирование и устойчивость к падениям.
Кроме горизонтального масштабирования приложения вы ещё получаете горизонтальное масштабирование команд: каждое приложение может делать отдельная маленькая гипер-продуктивная команда из трёх-семи человек, причём если у вас например нет возможности нанять зажравшихся явистов можете набрать команду из школьников PHP’ешников и выделить их в отдельную команду.