Category: Заметка

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

http://habrahabr.ru/qa/13792/
http://cyrille.martraire.com/2010/01/the-string-obsession-anti-pattern/
http://monospacedmonologues.com/post/11534596516/stringly-typed
http://world.episerver.com/Blogs/Valdis-Iljuconoks/Dates/2012/1/Stringly-typed-Composer-functions/
http://blog.rough-sea.com/2010/10/from-a-stringly-typed-to-a-strongly-typed-messaging-system-part-i/
http://habrahabr.ru/blogs/programming/111432/
http://habrahabr.ru/blogs/development/96978/
http://blog.lexspoon.org/2010/05/stringly-typed-code.html
http://www.globalnerdy.com/2010/05/09/new-programming-jargon/

http://en.wikipedia.org/wiki/Strong_and_weak_typing

Effective Java»: Item 50: Avoid string where other types are more appropriate

И ещё моя статья по теме: toString() contract

Реклама

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 выделить переменную потому что дебагер идёт построчно.

Анонсик

Хочу поделиться мыслями и планами на ближайшее время.
До конца недели я хочу накидать статью «Как переехать в Киев айтишнику«. Ужасные потрясения которые выпали на нашу долю делают этот вопрос даже ещё актуальнее чем раньше. Очень много людей вынужденны были бежать из своих городов захваченных оккупантами.
Я давно и публично всех айтишников зазывал перемещаться в Киев из других городов. Это относительно комфортный для проживания город, с преимущественно нормальным климатом, с развитой IT индустрией и профессиональной тусовкой, хорошей природой, адекватными жителями, «вечный город». По статистике опросов DOU здесь сосредоточено больше половины всех айтишников Украины.
Я хочу объяснить зачем нужно сюда переезжать, мотивировать, подсказать как искать работу и квартиру и тому подобные приколы.
Если  у вас есть свой опыт, поделитесь пожалуйста им — напишите в своём блоге или пост в соцсетях а я обязательно сделаю на вас ссылку.

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

Также хочу сделать небольшой поисковик плагинов для Grails по Github — чтобы сразу можно было оценить качество проекта: количество старов, форков, комитов, тестов и других метрик по которым можно будет определить стоит ли вообще с ним связываться.
В идеале таким поисковиком я предложу заменить текущий Grails Plugin Portal также как это сделано в jQuery.
Вообще, я попробую изучить возможность и целесообразность создания механизма чтобы прописывать зависимости в Grails \ Gradle сразу на ревизию из репозитория системы контроля версий (Git или SVN). Это очень сильно упростит жизнь если использовать форки библиотек и устранит проблему с их версионированием облегчая модель Базара.

Следующее чем я хочу заняться это завести небольшой spare time project. Тут у меня две основные идеи которые я хочу реализовать:

1. Строгий переводчик и лексический конструктор.

Мне нужно выучить грамматику английского языка, что делать конечно же лень и не интересно. Я и русскую грамматику то не учил никогда, как вы наверное уже заметили, поэтому когда начинаю учить грамматику английского то вхожу в ступор от терминологии «подлежащее и сказуемое», «страдательный залог» и прочие герундии. Я себя чувствую как будто ты семиклассник который попал на курс по высшей математике и который диференциал dx/dy  решил сокращением дроби.
И я решил поступить так же как поступил на первом курсе с вышкой: взять и написать программу которая это всё будет решать. «лучший способ что-то изучить это научить этому компьютер» (с) кажись Дейкстра.
Теперь я хочу написать штуку которой реально всем не хватает: лексический конструктор предложений.
Допустим я вбиваю предложение «I read a book». Конструктор подсветит где тут глагол, где существительное. Затем я могу с помощью конструктора перевести это предложение в другое время или превратить в вопрос.
То есть это эдакий переводчик но с множеством кнопочек и подсказок. Обычные переводчики что я видел обычно просто имеют инпут и аутпут и переводят «примерно» и если были какие то проблемы с пониманием текста они это молча схавают и переведут «лучшая среда разработки» как «the best wednesday of development».
Тут есть большой прикол в том что этот проект прекрасно можно разработать в TDD стиле. Поэтому я свою попробую скринкастить и сделаю из него небольшое реалити шоу на своём ютуб канале где с нуля на глазах буду его создавать.

2. Консольная тула для рефакторинга.
Это более глобальный проект по реализации моего видения языка программирования следующего поколения, но тут конкретно я сделаю небольшой, но уже рабочий и полезный кусок чтобы использовать прям сегодня.
На сегодняшний день одна из самых больших проблем IT индустрии это обратная совместимость. Очень яркий тому пример это Java. На этом языке программирования написано тонны кода в больших проектах.
И теперь добавить новую фичу в язык очень сложно, потому что старый код может потом просто не скомпилироваться. Также в библиотеках джавы полно старых классов и методов помеченных как deprecated но которые не удаляют для поддержки обратной совместимости.
Например есть такой класс для индексированных массивов как Vector. Он старый, и тянется ещё с первой Джавы. Он имеет два недостатка: все его методы синхронизированны что гасит производительность и он не типизируемых дженериками.
Эти два недостатка исправлены в новом классе ArrayList, но никто же не будет вручную переписывать весь старый код на новый класс. Некоторые IDE имеют такой рефакторинг как Миграция (замена) класса.
Но это нужно чтобы каждый на своём проекте ткнул куда надо и нажал нужную комбинацию.
А теперь представьте что вы делаете библиотеку и в новой версии у вас у метода вы удалили лишний параметр. Всем пользователям вашей библиотеки теперь нужно просто удалить во всех местах где вызывается ваш метод этот redundant параметр. Элементарно, но изначально с новой версией вашей библиотеки у них код не будет компилироваться. Что вы тогда делаете? Обычно делаете новые метод без параметра рядом а старый помечаете как deprecated. И он так и болтается в коде до следующей майорной версии.
Теперь что я предлагаю: сделать небольшую консольную тулу которая автоматически пройдёт по коду и исправит всё так как надо. Так же как например миграции баз данных DBMaintain и LiquiBase. Код, это ведь то же данные по сути.
Тут особо придумывать ничего не нужно будет — можно попробовать вырезать рефакторинг из IntelliJ и просто к нему прилепить консольный интерфейс.

Если кому интересно — я буду рад любому сотрудничеству и идеям.
Надеюсь справлюсь 😉

 

Проблемы 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 как к кастрированому форку православной сановской Явы.
Боюсь чтоы избавится от этого его прийдётся переименовать и впихнуть в него что-то модное чтобы пресса рассказала о нём как о прорыве.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Grails: Хитрые грабли на примере сохранения и валидации пароля

Часто натыкаюсь на такую запись:

class User {
  String email
  ...
  String password

  static constraints {
        password(nullable: false, blank: false, minSize: 6)
  }
}

И потом делают валидацию по этому полю а перед сохранением перезаписывают его хешом, например:

user.password = params.password.encodeAsSHA256()

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

Хеш будет иметь всегда фиксированный размер (в 64 символа в случае с SHA256). Даже у пустой строки, ага.
Если не указан максимальный размер текстового поля то его размер на уровне БД будет 255 символов. А использовать будем всегда только 64, т.е. имеем оверхед.
Или например если вы не указали максимальный размер поля, то он не будет валидироватся на уровне формы и вы получите исключение при сохранении в БД — ещё один наглядный пример что валидация форм не всегда коррелирует с презентацией на уровне БД.

Значит нам нужно указать размер поля, например так:

password(nullable: false, blank: false, maxSize: 64)

Хочу обратить внимание что ещё один аргумент против указания характеристик пароля в описании поля в которое будет сохранён его хеш, потому что в таком случае пароль будет ограничен в 64 символа.
Ограничивать размер пароля совершенно глупо, чем длиннее пароль тем выше его надёжность. Я например могу использовать целую фразу и вставлять её автоматически например из брелока.
Какая вам разница какой длины мой пароль? Хоть весь текст Войны и Мира, всё равно ведь в вашей БД он займёт 64 символа. Главное чтобы уложилось в разумное ограничение на длину POST запроса.
Кстати также глупо ограничивать или навязывать мне набор символов, например чтобы обязательно были в нём цифры. Пароль из шестнадцати обычных латинских букв надёжней пароля из шести крякозяблов «qwert$123».

Заключение

Я бы вам посоветовал вот такое описание поля пароля

password(nullable: false, size: 64..64, bindable: false)

Где размер строго 64 символа на хеш (зависит от алгоритма хеширования), и ещё отключен биндинг на всякий пожарный.

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

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