Серёжа Пономарёв aka stokito

I'm Java & Grails developer, coach and founder of IT community #kranonit in my native city.

[Grails] Пару последних граблей с GORM

В последнее время несколько раз получал ошибки из-за неопытности в некоторых аспектах GORM и Hibernate. В этом плане GORM постоянный источник неприятных сюрпризов.
И сегодня увидев отличную статью Advanced GORM Features: Inheritance, Embedded Data, Maps and Lists Storing решил записать пока не забыл.

1. Если вы используете наследование в доменых объектах, то не забывайте миграцию при изменении имён классов

GORM позволяет использовать наследование. Классы наследники могут сохранятся либо в разные таблицы table-per-subclass либо все в одну table-per-hierarchy (по умолчанию).
Обратите внимание, что если у вас в одной таблице (table-per-hierarchy) то у вас будет ещё одно поле discriminator с именем class по которому собственно GORM и будет понимать какого конкретно класса эта запись.
Например для такой иерархии классов

class Content {
    String title
    User author
}

class Blog extends Content {
    Date dateCreated
}

class Book extends Content {
    String isbn
}

Будет такая таблица

+---------------------------------------------------------------------------------------+
| content                                                                               |
+---------------------------------------------------------------------------------------+
|id | class            | title            | author_id | date_created | isbn             |
|1  | com.example.Blog | My post          | 1         | '2014-1-1'   | null             |
|2  | com.example.Book | Grails in action | 2         | null         | '978-1933988931' |
+---------------------------------------------------------------------------------------+

Как вы видите, в поле class сохраняется полное имя класса. В момент выборки GORM по этому полю пытается создать этот класс и гидрировать данные из записи.
И тут кроется опасность: если вы допустим поменяли у себя имя класса или его пакет, то все старые записи не смогут извлечься. И самое противное что об этом вы можете узнать только когда уже задеплоите новую версию на продакшен.
Поэтому, если вы поменяли имя доменного класса, не забудьте добавить в скрипт миграции с помощью migration plugin (надеюсь, вы профессионалы, и используете его).
Например, если вы поменяли пакет класса Content и его наследников с com.example на com.example.content то вам следует написать примерно такой скрипт миграции:

databaseChangeLog = {
    changeSet(author: 'John Doe', id: '033_change_content_class-1') {
        update(tableName: "content") {
            column(name: "class", type: "varchar(255)", value: 'com.example.content.Blog')
            where("class = 'com.example.Blog'")
        }
    }
    changeSet(author: 'John Doe', id: '033_change_content_class-2') {
        update(tableName: "content") {
            column(name: "class", type: "varchar(255)", value: 'com.example.content.Book')
            where("class = 'com.example.Book'")
        }
    }
}

2. Не помечайте абстрактные доменные классы модификатором abstract, глючит

Наткнулся на какой-то хитрый баг. Если допустим вы пометите Content как абстрактный, что так и есть, то биндинг подклассов перестаёт почему то работать. Уже забыл детали, забыл зафайлить багу. Grails 2.2.3, возможно поздние версии работают.

Оставить комментарий »

Интервью с Андреем Замовским, CEO HolyTransaction.com

Интересная дружеская беседа с одним из пионоеров криптовалют и CEO компании https://HolyTransaction.com/ о биткоинах, стартапах, Кремниевой долине и личностном развитии.

Также есть другое, более серьёзное и профессиональное интервью с Андреем

5 Комментарии »

Несколько замечаний про код стайл

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Оставить комментарий »

Як я потрапив в IT.

stokito:

Небольшая статейка о том что если есть голова на плечах то устроится в IT не будет проблемой

Originally posted on animator404:

Відносно не так давно на DOU була стаття, як молодим людям отримати першу роботу. В ній був перелік компаній, зацікавлених в молодих перспективних людях, студентах, які бажають отримати перший досвід в IT сфері. Також там були і електронні адреси цих компаній, куди можна було слати свої резюме, що я власне і почав робити.

Bionic University на базі Національного університету «Києво-Могилянська академія»

Крім самих компаній там була загадка про курси програмування Bionic University, де можна зареєструватися на будь-яких з доступних напрямків в сфері IT — від підприємництва до власне мов програмування та фронт-енду. З офіційного сайту: “BIONIC University – освітня ініціатива інноваційного парку BIONIC Hill. Основною метою BIONIC University є створення інноваційної системи, яка забезпечує підготовку кваліфікованих фахівців для компаній-флагманів IT-індустрії та інших високотехнологічних галузей України.” Реєстрація проста та швидка, тому я подав заявку на Java SE та EE, оскільки на той час я вже майже…

View original ещё 875 слов

Оставить комментарий »

Анонсик

Хочу поделиться мыслями и планами на ближайшее время.
До конца недели я хочу накидать статью «Как переехать в Киев айтишнику«. Ужасные потрясения которые выпали на нашу долю делают этот вопрос даже ещё актуальнее чем раньше. Очень много людей вынужденны были бежать из своих городов захваченных оккупантами.
Я давно и публично всех айтишников зазывал перемещаться в Киев из других городов. Это относительно комфортный для проживания город, с преимущественно нормальным климатом, с развитой 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 и просто к нему прилепить консольный интерфейс.

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

 

3 Комментарии »

What Makes America the Greatest Country in the World?

Originally posted on Yakov Fain's Blog:

My son Dave bought the DVDs with the first season of the HBO’s series «The Newsroom», and we watched the first episode today. In the beginning, they showed a press conference, where a journalist asked a TV anchor, «What makes America the Greatest Country?». He could not give a decent answer, which got me thinking, «How would I answered this question?»

I live in the USA for twenty one years. Before that I lived in the USSR. I’m an American citizen. I don’t have any other citizenships. I can compare. I can observe. I can speak up freely.

To put it short, the USA is the most wanted country in the world. That’s why it’s the greatest country in the world. Of course, not 100% want to relocate to America. But most of the people do even if they say otherwise.
People vote for America by putting the money (or…

View original ещё 629 слов

Оставить комментарий »

Что главное чтобы устроиться на работу программистом студенту? Законченный проект!

Я заметил что у студентов и джуниоров которые ищут себе первую работу программистом обычно возникают такие вопросы и проблемы:

0. А смогу ли я?
Этот вопрос они задают себе, но могут невзначай стесняясь спросить знакомого айтишника. Очень многие не уверены в себе.
Вокруг программирования есть такой ореол как будто это что-то страшное, сложное и связанное с математикой и обычно информатику углублённо преподают в физ-мат лицеях.
Это конечно же просто миф.  Может раньше оно так и было, когда компьютеры были большими и часто приходилось их даже самому паять. И использовались тогда компьютеры в основном в научной сфере.
И все программисты тогда были бородатыми инженерами-электронщиками.

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

Большая часть программ — вполне прикладные. Если это сайт, то получить запрос, выгребстки из базы данных, вставить в HTML страничку и покрасить кнопочку в синий.

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

Точно так же частый вопрос: «мне уже %ВАШ_ВОЗРАСТ% не поздно ли заняться программированием? Или уже идти на кладбище?».
Эта тема регулярно всплывает на форумах, и раскрыта там вполне. Будет тяжелей, но всё возможно.

Самое главное чтобы вам было просто интересно программировать. Остальное вторично.

1. Что учить? Какие языки программирования?

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

Обычно с первого языка ты всё равно скорее всего будешь переходить на другой язык.
Но лучше всё таки начать обучение с более классических языков типа C, C++, C# и Java, и которые более менее спроектированы а не такой язык в который всё навалено в кучу как в PHP или Basic. Но не парьтесь особо.

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

3. Учится, учится, и ещё раз учится, а потом учится, учиться, учиться….
И вот ребята уже учит и даже могут пописать код, и вот уже как бы пора бы работу искать.

Я заметил у студентов и джуноров которые ищут себе первую работу программистом одну проблему.
Почти все из них штудируют книги и учебники, даже уже читают шаблоны проектирования, но не знают когда остановится и как же всё таки найти себе работу.
И часто меня спрашивают что-то такое от чего я в шоке, например «А стоит ли учить шаблоны GRASP?».
O_o о боже, да я вообще про них в первые слышу :) Нафига оно тебе?

Ребята, не перезатягивайте.

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

Как можно научится танцевать по книгам? Как можно понять шаблоны проектирования не написав тонны быдлокода и не пересмотрев гибибиты исходников библиотек?

Никак

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

Да блин, я когда дорвался до компьютер мне так и хотелось творить нон стоп. И пофигу что. Мне не понравился калькулятор — я написал свой калькулятор с преферансом  и куртизанками. Свой арканоид, свой сайт итд.
Я обычно даю такой совет: напишите программу для себя. Лично мне понравилось в университете все задачи по математике решать своей программой. Мат алгоритмы прекрасно программируются.
Например решение системы линейных уравнений методом Гаусса — там вам и циклы, и работа с динамическими массивами.
Такие задачки отлично тренируют умение структурного программирования.

5. Что нужно уметь программисту?

По сути, вся эта алхимия программирования на самом деле состоит из таких компонентов:

  1.  Собственно структурное программирование: как объявлять переменную, функцию, как писать условный оператор if, приоритет операторов, как организовать цикл, как получить ввод от пользователя и как ему вывести. Это легкотня на самом деле: 15ть операторов, учатся быстро. Почти все языки программирования наследуются от Си (C++, Java, C#, PHP) так что переучивать их не придётся. Это как базовая грамота.
  2. Алгоритмизация: линейный поиск перебором, бинарный поиск, пузырьковая сортировка, быстрая сортировка итд.
  3. Организация и проектирование программы: объектно ориентированное программирование, шаблоны проектирования.
  4. Знание платформы, библиотек и технологий: Java Core, XML, работа с файлами, работа с сетью, работа с массивами, строками и коллекциями.
  5. Умение писать чистый код: как правильно называть переменные и классы, как форматировать код, как правильно писать комментарии, ну то есть как их. не писать :) Понимание приходит после прочтения книги Clean Code
  6. Умение работать с кодом: рефакторинг (книга Фаулера), хоткеи IDE для рефакторинга.
  7. Инженерные практики: юнит тесты, экстремальное программирование (XP), непрерывная интеграция, системы управления версиями (Git, SVN)
  8. Управление проектом и организация процесса: Agile, RUP, SCRUM, Kanban
  9. Умение общаться с закачиком и ладить в команде.
  10. Знание английского языка, умение чётко и лаконично писать документацию.

Как видите этот список можно продолжать, но вы должны понять главное: именно само программирование это совсем чуть-чуть. Все остальные пункты приходят с опытом и постоянным чтением правильных книг.

Не зависайте. Вкалывайте, делайте проекты и ищите работу.
Успехов!

5 Комментарии »

Привет, безоработные!

Геннадий Балашов отрезвляет студентов

Оставить комментарий »

[Grails] Mock MySQL database in test environment

Grails supports different data sources configured per environment.
If you use MySQL database in production and want to write integration tests you may prefer H2 database because it simpler.
For example it can automatically create in-memory database from the domain classes of GORM model.
And after running tests it will drop this database when application will shutting down.
H2 allows you to use full set of SQL commands, but they may differ from MySQL.
To imitate MySQL behavior you need to add options Mode=MySQL;DATABASE_TO_UPPER=FALSE;IGNORECASE=TRUE to connection string.

From documentation:

MySQL Compatibility Mode

To use the MySQL mode, use the database URL jdbc:h2:~/test;MODE=MySQL or the SQL statement SET MODE MySQL.

  • When inserting data, if a column is defined to be NOT NULL and NULL is inserted, then a 0 (or empty string, or the current timestamp for timestamp columns) value is used. Usually, this operation is not allowed and an exception is thrown.
  • Creating indexes in the CREATE TABLE statement is allowed using INDEX(..) or KEY(..). Example: create table test(id int primary key, name varchar(255), key idx_name(name));
  • Meta data calls return identifiers in lower case.
  • When converting a floating point number to an integer, the fractional digits are not truncated, but the value is rounded.
  • Concatenating NULL with another value results in the other value.

Text comparison in MySQL is case insensitive by default, while in H2 it is case sensitive (as in most other databases). H2 does support case insensitive text comparison, but it needs to be set separately, using SET IGNORECASE TRUE. This affects comparison using =, LIKE, REGEXP.

But raw SQL may not work, because MySQL field names are case sensitive, GORM expect them lowercased, but by default H2 creates them uppercased.
To fix that you need to set property DATABASE_TO_UPPER to FALSE

Database setting DATABASE_TO_UPPER (default: true).
Database short names are converted to uppercase for the DATABASE() function, and in the CATALOG column of all database meta data methods. Setting this to «false» is experimental. When set to false, all identifier names (table names, column names) are case sensitive (except aggregate, built-in functions, data types, and keywords).

So final Config.groovy will looks like:

environments {
    test {
        dataSource {
            dbCreate = 'create'
            url = 'jdbc:h2:mem:testDb;MVCC=TRUE;LOCK_TIMEOUT=10000;MODE=MySQL;DATABASE_TO_UPPER=FALSE;IGNORECASE=TRUE'
            pooled = true
            driverClassName = org.h2.Driver.class.canonicalName
            dialect = H2Dialect
            username = 'sa'
            password = ''
            logSql = true
            formatSql = true
            pooled = true
        }
    }
}
Оставить комментарий »

kranonit S18 Gamedev — это не игрушки! Отчет о встрече

stokito:

Классная встреча получилась

Originally posted on #kranonit Клуб анонимных айтишников в Кривом Роге:

poster_1

22 февраля прошла первая в этом году встреча Криворожского клуба анонимных айтишников. В этот раз ее поддержала международная геймдев компания iLogos —  докладчиками выступили первые лица: СОО компании Елена Лобова, СЕО компании Василий Черноморов и арт-директор Евгений Павлов.  Они поделились с нами секретами управления большой компанией, открыли тайны создания игр и поведали об особенностях игрового дизайна.

Первой перед нами выступала прекрасная девушка — Елена Лобова, занимающая должность исполнительного директора в компании iLogos.

Она рассказала нам о проблемах и рисках, какие могут возникать при создании и управлении компанией. Не менее интересно было услышать о мотивации, о фидбеке и построении отношений с коллективом в целом. Каждый человек, наверное, не раз слышал о таблице Маслоу. Елена продемонстрировала, как компания может удовлетворить все потребности своих сотрудников. И наконец был открыт  главный секрет — что самое важное для программистов, чем их мотивировать? Ответ на этот вопрос вы можете найти в видео со встречи.

Василий Черноморов…

View original ещё 280 слов

Оставить комментарий »

Отслеживать

Get every new post delivered to your Inbox.

Join 589 other followers