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

Java & Grails developer

#456 Киев — это cool!

Originally posted on Америчка:

IMG_3437

Впечатления о Киеве
День вышиванки
Yoko Ono
Хороший фильм
Жены Амазона
Неправильные выводы
Почему ресторан работает хуже

Качаем или слушаем

View original

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

[Linkset] Несколько статей про карьеру в IT

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

The Myth of the Genius Programmer

Чичиков и программиат

What I Wish I Knew When I Started My Career as a Software Developer

The Parable of the Two Programmers

Страсть к программированию. Глава 13. Найди ментора

Дисциплина, или этот проклятый рабочий день

10 отличий между хорошим и нормальным программистом

Как правильно задать вопрос своему коллеге?

Плохие привычки программистов

Признаки плохого программиста

Ремесло программиста. Золотые правила

Как стать руководителем

Что нужно делать смолоду или как стать богатым айтишником

Как стать богатым айтишником — продолжение от другого автора

5 Questions Great Job Candidates Ask

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

Что спрашивают на собеседованиях Senior Java Developers?

За прошлые две недели я прошёл больше двадцати собеседований. Может больше, может меньше, сложно сказать, большинство из них проходил по скайпу «вот прям сейчас». Ещё пару таких неделек и я бы побил рекорд комбатса :)
Немного вестей с полей, очень субъективно:
* Мне сложно судить, но ощущение что вакансий по Java в Киеве заметно поубавилось. Судить сложно, потому что в прошлый раз когда искал работу я был мидл уровня и был не очень востребованным на рынке. Ну и проект в прошлый раз я нашёл за день, там искали именно специалиста по Grails как раз как я.
Но в любом случае, новые компании не могут аутсорсить в Украину. Многие делают массовый релокейт своих сотрудников. Массово и планомерно сгребают всех в Таллин и Краков.
* В этот раз по Grails не смог найти ничего. Очень хотел попасть в TransferWise, у меня релевантный опыт к ним и там толковый тимлид, но они в Черкассах. Я предложил на испытательный срок поработать у них в Черкассах а потом на удалёнку только подъезжая на бэклог грумниг, но сказали так им не пойдёт.
* Джинни реально рулит — очень много отзывов пришло на моё резюме. В LinkedIn кроме спрамерш тоже нашлось несколько настоящих рекрутёрш. Из сайтов вакансий тоже только по ДОУ Работа прошёлся, несколько отличных вакансий было.
* Крупные аутсорсы — походу отстой. Из крупных только Люксофт ещё шевелится и работает.
Например ЕПАМ свои вакансии на ДОУ вообще не публикует, но я зашёл на их сайт нашёл таки открытые позиции и зааплаился на несколько на которые подхожу, ии… всё. Никакого ответа. Вообще у меня такое впечатление что в Епаме уволили весь HR отдел, а чтобы нанять новых нет эйчаров.
У Глобалоджика вакансий по джаве не было на сайте вообще, также у Инфопульс. У Сиклума было вакансий клёвых, но видать не заинтересовало моё резюме. Отписались только вчера, когда я уже офер принял. А ведь это всё лидеры в топах.
Люксофт не подкачал, две крутые позиции предложили, жаль моего уровня не хватило — там нужно было хорошо уметь многопоточность.
* Да, кстати к заголовку поста, синьёров спрашивают по сути тоже что и мидлов и джуниоров: Java Core, коллекции, мапинги в хибернейт, скоупы бинов в спринге, пару задачек на агрегацию SQL, но в добавок особенно уже начинают расспрашивать низкоуровневую жесть: про то как работает Garbage Collector, как исправлять проблемы на сервере через jconsole, и особенно жёстко Concurrency — что такое ThreadLocal, volatile. Проблема в том что конкаренси это такая жёсткая тема которую ну просто невозможно изучить не поработав на проекте с нею. Вопросы по алгоритмам почти всегда — на знания деревьев и их обход.
Ну и как всегда к реальной практике вопросы обычно отношения почти не имеют.
* Почти все взяли моду спрашивать логические задачки на собеседовании и давать тестовые задания. Причём если логические задачи ещё хоть как-то можно обосновать, то тестовые задания я вообще не понимаю зачем давать. Вот прошёл я отлично техническое интервью, ребятам явно понравился, да и я бы уже готов к ним идти, но нет — вот вам тестовое задание: напишите простую веб апликуху с импортом в БД из CSV файла.
А у меня через час после них следующее собеседование назначено, а на следующий день ещё три. Такую апликуху сделать — как два пальца, но блин это всё равно время часа на четыре минимум, за которые никто не заплатит. А когда ты почасово поработаешь на удалёнке то начинаешь особо ценить время. И особенно его начинаешь ценить когда вторую неделю не зарабатываешь а ходишь по собеседованиям.
И делать ну вот реально не хочется: задача не интересная, тебя по скайпу перебивают эйчары, и вообще лучше время потратить чтобы освежить знания про конкаренси чтобы завтра на собеседовании не краснеть. И даже примитивную программу писать всё таки долго: ты, например, можешь отлично шарить хибернейт, но тебе всё равно нужно будет потратить время чтобы его правильно подключить к проекту, потому что ты этого не делал никогда а работал на работе где уже готовое приложение было. Потом прописать мапниги, наколбасить тесты, побороть пару непонятных исключений из-за опечаток — вроде и фигня, а на каждом новом проекте съедает кучу времени.

И что этим тестовым заданием хотели посмотреть? Как я пишу код? Так для этого можно на гитхаб зайти посмотреть, я же его указал в резюме. Ну или прямо на собеседовнии можно простой код написать.
Узнать как я шарю техническую жесть и знания технологий? Ну так тут задача на один контролер с десятью строчками кода. Ну и опять таки — резюме, гитхаб, вопросы.
В другой компании дали обычную TDD кату пройти. Опять таки: ну и что по этой кате можно узнать? Шарю ли я ТДД? Ну шарю, это можно и вопросом выяснить. Может какую архитектуру я наваял в итоге? Так по ТДД архитектура всегда выходит не самая лучшая, зато рабочая. Это всегда так при разработке снизу вверх.
И да, тоже пять часов её втыкать не интересно.

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

А вот что мне реально понравилось и считаю хорошей практикой — это когда мне дали листинг кода и спросили какие ты тут проблемы видишь и как бы отрефакторил.
И тут да, сразу поехало: тут ненужный автобоксинг, тут дженерик бы дописать, вот это в метод заэкстрактить, тут в JDBC лучше сделать prepared statement и ещё забыли ресурс закрыть. 15 минут за которые интервьювер узнал про меня в разы больше чем за пятичасовое тестовое задание.
Когда в следующий раз буду сам собеседовать обязательно возьму эту практику.

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

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

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

Что спрашивать на собеседовании

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

Ох, как же тяжело быть программистом

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

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

evil_programer
А всё потому что написанная однажды твоя программа будет ещё переписываться много раз. И скорее всего не тобою…
И я начал чётко следовать этому правилу и стараться писать код хорошо.
Время шло и я узнал следующую правду жизни:

Как бы ты не старался, тебе потом будет стыдно за этот код и даже будет хотеться переписать.

Чёрт побери, и ведь правда! Всем программистам стыдно.

Как же с этим жить? Но вот на одной конференции я узнал спасение:

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

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

И вот я переколбасил код думая что я сделал «рефакторинг», ну ничего что без тестов, но работать должно. И вместо написания своего CSV парсера нашёл в интернете и подключил к проэкту какой-то чужой, который ещё и Excel файлы шарит парсить, и в БД сразу записывать и кофе варить и ракеты запускать.
Я удалил не 200 а 400 строк! Йуху! Какой же я крутой :-)

И в припрыжку понёс показывать это всё архитектору на ревью.
А он глянул и сразу дал мне по шапке: «А это что за библиотека? А ты уверен что в ней нет багов? А класс этот ты зачем поменял? А ты тесты написал? А ты уверен что после твоего рефакторинга оно будет работать как прежде?».
И рассказал мне программисткий анекдот:
Работает - не трогай

И ты так и продолжаешь работать на проекте постоянно дописывая костыли и накапливая технический долг.
И вот наступает такой момент когда прибегает к тебе проджект менеджер и говорит «там заказчику нужно срочно поменять стратегию начисления скидок к рождественским продажам. За сколько можешь сделать?».

А ты хрен его знает даже что отвечать — там такой код уже непонятный, всё в костылях, писался десятью индусами и те уже поувольнялись.
— Ну за два-четыре дня. Наверное.
— Отлично! Два дня, так и скажу заказчику.
И убежал.

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

Любой код без автотестов сразу становится legacy: никому непонятный, хрупкий и почти неизменяемый, и все уже через неделю забудут что он делает и как.

Посидел, поглядел в монитор часик.
Нет, всё равно непонятно. Как оно, блин, вообще работает? Я убил бы того кто это писал, вот бы узнать где он живёт… и бензопилой… или лучше в кислоте его…
Пойду кофе заварю.
Вернулся, посидел ещё часик.
Скучно. О! Новый имейл.
Потом ещё часик.
А что там в твитере пишут?
Потом ещё часик.
Зайду-ка я на хабру, может чё интересного почитать.
Потом ещё часик.
Так, ладно. Нифига не понятно, пора домой.

Следующий день проходит примерно также. И вот заходит к тебе проджект менеджер, а у тебя на весь монитор башорг:
— Нушотам, сделал?
— Та я это… там непонятно..
— Блин, ты же обещал за два дня сделать! А ты башорг читаешь!
— Ну… за два-четыре…
— Да продажи уже начнутся через два дня! Короче у тебя дедлайн до завтра. Иначе уволю нафиг, бездельника.

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

http://www.slideshare.net/Cartmendum/pmlabs09-part1

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

И всё? Вот это вот я три дня ковырялся чтобы одну строчку исправить? Блин, я программист а кода как-то и не пишу. И новая истина которая открылась тебе гласит:

Большую часть времени программист читает код, а не пишет.

Блин, это совсем не романтично :-(

Ну вообщем заказчик уже нервничает и ты сдаёшь программу. А твой QA на проекте тоже был занят и не успел протестировать твой код и так он и отправился в продакшен.

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

Вообщем раздача пилюлей докатилась сверху вниз до тебя усилившись на каждом уровне и вместо рождества и пьянки с девками сидишь ты в офисе и разбираешься в чём ошибка.

А ошибка оказывается происходит когда пользователи цену указывают с центами. И вдруг ты понимаешь —
а в США десятичный разделитель не запятая, а точка! И ты вбивал $5,50 и у тебя работало, а американцы вбивают $5.50 и получают ошибку. Но ты об этом ну вообще даже не мог подумать, и отдал не до конца протестированный код и который ну просто обязательно и завалился. Это было неизбежно, потому что есть Закон Мерфи который гласит:

Если что-то сделано так что может поломаться, оно обязательно поломается

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

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

Но время идёт, потихоньку ты учишься делать рефакторинг правильно и быстро, средствами IDE, покрывая тестами, в заранее выпрошенное у заказчика время.
Но работа тебя постепенно перестаёт переть. Это уже совсем не тот драйв который ты испытывал когда писал Змейку на втором курсе.
Какое-то унылое ковыряние в XML конфигах, баг фиксинг, чтение документации, разговоры с коллегами.
А при этом прогресс не стоит на месте, и вот выходит новая версия библиотеки, где добавился новый функционал а старый будет удалён. И тебе нужно посидеть попробовать её, прочесть книжку, попробовать пописать код. Но это не в рабочее время, естественно.

Нужно бежать за прогрессом чтобы оставаться на месте

Как быть? После работы дома ещё начинаешь себе pet project, так, чисто для души.
Жена недовольна — муж приходит с работы и снова за компьютер и в наушники. Сначала бесится, а потом рожает тебе ребёнка чтобы ей скучно не было. Теперь дома детские визги вообще не посидеть кодить — и начинаешь засиживаться на работе до 11ти.
А что делать? Как-то же обучатся нужно.
И постепенно твоя производительность снижается и устанавливается на определённом уровне, и тебе открылась следующая истина:

все работники креативной специальности: маркетологи, художники, музыканты, программисты — никогда не могут работать больше, чем четыре часа в день.
© bobuk

Но вот случается чудо, и заказчику нужно написать новое приложение. У вас есть возможность написать проект самим с ноля! Не какого-то старого монстра фиксить костылями, а начать с чистого листа.
Тут вы сразу же восторженно рисуете UML диаграммы, схему БД и выбираете стект технологий: что там сейчас самое модное? MongoDB, AngularJs, Scala? Ну и конечно же сразу нужно всё писать для cloud!
Начали писать, всё круто, но тут заказчик начинает сразу вносить поправки в техническое задание, причём нужно опять успеть до дедлайна, архитектуру переделывать некогда и снова ваш код заростает костылями.
Как это не прискорбно, но следующее открытие:

Начали в стиле «Хай-тек». Продолжили в стиле «Пусть так». Закончили в стиле «Хрен с ним».
© Dmitriy Efimenko

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

Именно поэтому, вообщем-то, хороших программистов не так много. И именно поэтому им платят относительно неплохо (а на самом деле ещё и сильно недоплачивают).

Но однажды ты почувствуешь спокойствие и Силу Джедая. Как к этому прийти обязательно посмотри этот коротенький и чудный рассказа Андрея Солнцева:

UPD Похожая статья В поисках идеального программиста

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

Говорящие и красночные логи FreeTTS Log4J Appender

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

Собственно уже на следующий день меня это уже достало окончательно и я принялся искать пути как проверить свои изменения без полного передеплоя. Разобравшись и поняв что с этим монструозной легаси системой такое не прокатит я выработал традицию запускать систему и сразу же идти за кофе, или открывать хабру. Мда… И уже всё стартануло, но надо же дочитать срачи в каментах!
А потом ещё обнаружить что тупанул и забыл где-то в toString() поставить пробел и опять перезапускать перестиестивать :)

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

Сейчас, благодаря TDD, и модульной архитектуры у меня проект стартует уже не 15 минут, но всё равно несколько довольно мучительных минут в течении которых непонятно чем себя занять.
Хабру уже не почитаешь, разве что пару твитов. Я решил просто «откидываться на спинку кресла» и закрывать глаза чтобы отдохнули.
откиньтесь на спинку кресла
Но тут появилась проблема: сервер уже стартанул, но как это увидеть с закрытыми глазами? А если ещё на этапе компиляции произошла ошибка а я с закрытыми глазами ещё пару минут тупить буду?

И тогда я решил что нужно просто озвучивать процесс запуска. Для начала я дописал обычный beep(), но это костыль. Хочется слышать как приложение проходит разные стадии а не только финальный звоночек.
Поскольку звуки на все случаи жизни искать тоже не вариант, то я решил использовать синтезатор речи и подключить его в как обычный апендер логов. Благо это пару строчек кода.
Синтезатор речи для джавы, пускай и слегка заброшенный, но есть.
В результате представляю вам FreeTTS Log4J Appender. Прошу любить и форкать.
Как подключать описано в ридми, но если в двух словах то нужно подключить мой мавеновский репозиторий и прописать его депенденси.

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

Нужно ли указывать непрофильное образование в резюме?

Вопрос по поводу резюме. Я сейчас заканчиваю второе высшее, бакалавр, Computer Science… до этого я закончил английскую филологию :(
И у меня по этому поводу комплекс — я в резюме об этом нигде не указываю. Правильно ли я делаю?
Тебя бы отпугнуло такое резюме Java Junior, где в графе образование значится Иняз и Computer Science?

Ответил так:

  • Первое высшее обязательно указывай. Во первых, это твоё высшее, и это уже довольно круто и почётно. Далеко не каждый может его получить. Та даже не высшее — это твои знания, и их стыдится вообще нельзя.
  • Во вторых специальность крутая — англ филология, значит Инглишь шаришь или как минимум любишь.
  • В третьих — чтобы не было вопросов «а чем ты занимался всё это время?».
  • В четвёртых — есть компании которым именно такой человек может и нужен. Например Gramarly — они делают проверку орфографии для английского и им может нужен человек который поможет сделать структурный анализ текста на соответствие художественному или научно популярному стилю.

Хуже точно не будет, а плюс будет в любом случае.

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

kranonit S20 Django — легко, быстро, эффективно

stokito:

Ух ты, кранонит выходит из спячки!

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

9646be688285186b8605df7ec308e29f

Легко, быстро, эффективно — эти слова в полной мере описывают самый популярный фреймворк для веб-приложений на языке Python. Отличная документация, быстрая скорость работы, удобная настройка и разработка приложений, гибкость инструментов и возможность наработки собственных стандартных фрагментов кода, которые затем могут применяться повторно… На этом преимущества Django не заканчиваются. 7 марта Сережа Бурма, наш давний друг, расскажет гораздо больше о самом фреймворке, его особенностях и преимуществах, покажет, как за пару часов можно создать сайт, его админку да и в целом как довести проект до ума. Не пропустите! Такой мастер-класс бывает не каждый день ;)
Место проведения неизменно — 322 ауд. пединститута (главный корпус, Гагарина, 54). Ждем вас в 10:00. Взнос на чай и печеньки — 15 грн.

View original

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

Как быстро можно стать Java Junior?

Максим Педич поделился опытом: для того чтобы изучить Джаву с нуля нужно пол года активного вкалывания.

Макс Криворучко дополнил

Чтобы стать программистом (читай освоить Java core) нужно пол года. Чтобы стать интересным для компаний программистом нужно знать кроме Java Core как минимум еще и тулы (maven/gradle, svn/git), jdbc, Servlet API, Spring (IoC). Было бы хорошо знать еще и html, sql, xml на базовом уровне.

В случае знания Java Core светить может интернатура,

во втотом случае — могут взять джуном.

Самое главное: по каждой теме иметь практику. И чем ее больше — тем лучше. Даже читая книгу, в которой примеры кода — нужно как обезьяна его перепечатать в IDE и запустить.

чтобы стать джуном нужно год-полтора

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

Частые вопросы Java Juniors

Ко мне в последнее время было много вопросов от Джава Джуниоров, запишу по памяти что отвечал:

скажите пожалуйста, нет ли у вас тестовых заданий от компаний на java или возможно пример проектика, который вы советуете делать начинающим java девам

У меня нет, а если бы и были то не дал. Это не честно, это всё равно что на экзамен прийти зная что за билеты.
Каждая компания старается задавать свои вопросы чтобы лучше узнать уровень соискателя. Они их придумывают, они не хотят чтобы эти вопросы другие знали, это их авторские права в конце концов.
Эта информация практически с грифом для служебного пользователя и не распространяется. Точно также как не распространяется информация о том какие грейды разработчиков (уровни Мидл, Синьёр) потому что в каждой компании разный уровень и по этой информации можно определить насколько в целом уровень профессионализма в ней.

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

Есть часть вопросов которые практически стандартные, и их легко найти в интернете.
Например: «Чем отличается абстрактный класс от интерфейса?»
И даже если вы ответите на этот вопрос, то его можно немного перефразировать или усложнить.
Например на вопрос «Чем List отличается от Set?» можно задать следующий вопрос «А почему Set не наследуется от List если он по сути похож, разве что не позволяет сохранять дубликаты?».
Ответ уже на этот вопрос потребует от вас именно полного понимания темы.

Так что заучивать стандартные вопросы можно и нужно, но опытного интервьюера этим вы не обойдёте.

Большинство вопросов идут из сертификации OCJP их легко найти и есть книги для подготовки по теме.

Так что вопросы с реальных собеседований не выпрашивайте, это преступление и они всё равно вам особо не помогут.

А пример проектика?

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

Как правило, если это вакансия для веб разработчика, вас попросят написать простое CRUD приложение, например TODO лист с использованием БД.

а сколько по времени должно примерно уходить на его выполнение?

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

Тут ещё такой момент: бывает что на тестовом задании ты где-то застрял. Например у тебя исключение какое-то и ты не можешь двигаться дальше. Т.е. ты в приницпе понимаешь как это сделать но вот конкретно в этом случае застрял. В таком случае абсолютно нормально спросить помощи у знакомого программиста\ментора.
Ещё это вполне нормально когда ты уже готовое тестовое задание покажешь ментору чтобы он проверил перед отправкой заказчику. Ты его уже написал, так что если кто-то тебе найдёт ошибку или подскажет как лучше и объяснит то от этого ты только умнее станешь а твой необходимый уровень знаний ты итак покажешь.
Это примерно как с курсовым проектом в университете — тебе может и помогли, но рассказывать всё равно придётся тебе самому. Но с курсачём тебе его главное сдать, а тут от твоих знаний будет зависеть реально чья то жизнь и бизнес.

Что учить?

Только то что востребовано на рынке и за что больше платят. Например, может Ruby on Rails или какой нибудь Python и кажутся вам самыми модными, но вакансий намного меньше чем на Java или PHP. А из Java и PHP больше платят за Java. Следовательно её и нужно учить (по крайней мере сегодня).

Походите по сайтам работы, посмотрите вакансии, почитайте в Википедии что за технологии там описаны. Зайдите на сайт indeed.com и посмотрите какие там тренды.

Что сегодня на рынке востребовано я точно не скажу. Что будет востребовано в будущем вообще никто точно сказать не может. Может новую версию PHP доведут до ума, а может все вообще перейдут на MPS.
Всё меняется, елси раньше Хибернет был «маст хэв» то сегодня уже, насколько я могу судить, работодатели уже интересуются знанием NoSQL баз данных, в частности MongoDB. А Hibernate им уже может быть не принципиально.

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

1) Какими веб технологиями должен обладать хороший программист на Java? Sping, JDBC, Hibernate? Что еще? Есть ли смысл читать книги по этим технологиям или хватает спецификации / туториалов?

Точно нужно вникнуть в базовые технологии. Если с БД то в Java вы не опуститесь ниже JDBC, если делайте веб то ниже уровня JSP и Servlets вы не уйдёте. Поэтому с ними нужно точно разобраться. Поэтому может быть лучше вместо знаний Hibernate и Spring вникнуть в базовые JDBC и Servlets.
Скорее всего вас будут их спрашивать. Но тем не менее Хайбернейт и Спринг нужно тоже как минимум потрогать чтобы знать что это и куда его пихать.
Есть ли смысл читать книги — да. В книгах обычно пишут почему спроектированно именно так, т.е. передают некую инженерную мудрость которая намного ценнее чем даже знание самой технологии. Вы можете прочесть книгу по Спрингу и применить знания если вы нашли работу в ASP.NET где те же самые контроллеры.
Поэтому одна из самых важных книг по Джаве так и называется — Философия Java.

Туториалы нужны для того чтобы быстро и пошагово развернуть у себя проект с их использованием и чтобы вы могли сами прощупать как это делается. Это тоже важно — это мышечная память, без этого знания не зафиксируются в голове.
Вот недавно был выпуск подкаста Разбор полётов где как раз гуру давали рекомендации. И смысл такой: знаний Спринга у тебя может и не быть, это нормально для джуна, даже было бы удивительно если бы они были.
Но фундаментальные знания которые написаны в книгах у тебя должны быть, потому что интервьюверы хотят прежде всего понять насколько ты вообще обучаемый.
Если ты не смог прочесть и понять книжку, то как же ты будешь разбираться с кодом на работе?
Некий мифический параметр «Обучаемость» это то что они хотят вычислить прежде всего. Но это практически только интуитивно можно определить.
Есть и другие параметры, например знание конкретной технологии. Например работа на которую тебя рассматривают требуют чтобы ты занимался больше фронтендом и нужно там разобраться с CSS3 и HTML5. Может даже быть что в той команде никто их не знает толком и ты как джун там будешь их же обучать.
Я знаю такой реальный случай, там даже было неловко тимлиду который собеседовал джуна потому что он не знал что спрашивать по CSS3 (как там анимации делать, например), потому что он сам не знал, но на проект такой человек был нужен.
Ты может даже не очень обучаем и тебе сложнее въезжать в тему, но зато ты очень прилежный и исполнительный. И тебя могут взять вместо другого более «обучаемого» и опытного джуна. Или ты может просто прикольный весельчак и тебя возьмут разбавить команду нердов. Знаю случай когда девочку взяли в команду из девяти пацанов чтобы они хоть бриться начали :)

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

2) Посоветуйте литературу по архитектуре / паттернам. По паттернам читал книгу headfirst, но она, видимо, не очень глубоко описывает все. Есть ли альтернатива банде четырех не с кодом на С++?

Тут сразу нужно разделить два понятия: ты либо имеешь опыт программирования на других языках, например ПХП, а теперь учишь Джаву либо ты вообще студент и толкового опыта программирования у тебя нет.
В первом случае, тебе лучше взять книгу по языку программирования который ты лучше знаешь, просто ищешь по запросу, например «Шаблоны проектирования в PHP». И вникаешь на одном языке.
Паттерны практически не зависимы от языка программирования, поэтому главное понять их суть, а там уже на Джаве напишешь и сам. Но опять таки, половина шаблонов проектирования нафиг не не нужны в функциональных языках программирования где всё делается простой кложурой
Functional programming patterns

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

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

Изначально само понятие «паттерны проектирования» и их классификацию ввели GoF в своей книге. Соответственно те шаблоны которые они в ней описали называют «паттерны по Гофу».
Просто потом всем так понравилось понятие паттернов что каждый поупражнялся в интеллекте и напридумали ещё потом тысячу других паттернов и даже антипаттернов.
Но больше ничем примечательным их книга не отличается — ни доступностью материала, ни даже полнотой. Именно поэтому есть более поздние книги где лучше разжёвано с большим числом примеров и с конкретными особенностями платформы.
Иногда может хватить статьи на Хабре, благо их валом.
Лично мне ещё было проще: мне мой ментор сказал «ну вот помнишь как Xml парсер ты создаёшь? Ну вот, это абстрактная фабрика» или «ну вот тебе нужно получить неизменяемый List, для этого есть метод Collections.unmodifableList(myList) который вернёт тебе декоратор myList с скопироваными элементами который на самом деле будет подклассом UnmodifableArrayList с заглушками на методы add() и remove(). Но это от тебя скрыто за методом unmodifableList() и тебя вообщем и не интересует какой там класс реально будет.».
И всё стало сразу мне понятно: «Тю, так я эти шаблоны постоянно использовал! Просто не знал что у них есть названия».
Вот в том и смысл: шаблоны, точно также как и рефакторинги — это классификация для программистов чтобы им было проще общаться между собой: «Слушай, а давай здесь выделим интерфейс и сделаем фабрику?».
Поэтому вся ценность паттернов — это то знают ли их. А все остальные шаблоны можно смело выкидывать потому что пользы от них нет. Это обычные структурные конструкции которых может быть безграничное количество и смысла им давать свои имена нет.
Поэтому когда говорим паттерн — подразумеваем паттерны ГоФ, и то только ту часть что используем.

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

Поэтому отнеситесь к книге Head First как к комиксу «как сделать коронарное шунтирование сердца».

А вот что намного важнее понять, это когда именно нужно применять и какой именно шаблон. К этому можно только прийти постепенно изменяя код с помощью рефакторинга.
И соответственно самые лучшие книжки про шаблоны проектирования — это книжки не про паттерны, а про рефакторинг.
Я уже повторял неоднократно и не постесняюсь ещё раз повторить, что лучшая книга для того чтобы разобраться как лучше проектировать архитектуру, писать код, писать тесты, и сопровождать его, это бестселлер Матрина Фаулера «Рефакторинг — улучшение существующего кода».
Рефаткоринг

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

Для чуть опытных программистов есть более продвинутая книга Джошуа Кириевски которая так и называется Refactoring to Patterns. Я её сам правда как-то так и не прочёл, но все знакомые кто читал были в восторге.

А вообще я не понимаю почему джуны так сильно зацикливаются на паттернах. И зачем их спрашивают на интервью. Когда я искал себе работу и меня спрашивали по шаблонам то вопрос звучал примерно так «расскажи хоть какой нибудь шаблон». И я просто заучил их и по очереди называл их названия всех 23х шаблонов. И каждый раз интервьюеры офигевали «ого, это их столько? А можешь хоть один объяснить». И я рассказывал про один из трёх которые я реально понял. Интервьюер как правило знал столько же.

Я так понимаю что это связано с тем что вокруг шаблонов некий ореол «проектирования» которое якобы их делает чем то таким научным и теоретическим. Как будто их знание делает тебя умнее тех быдлокодеров унтерменшей.

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

Так что вы поймите хоть парочку шаблонов, желательно из разных групп, например структурный — Декоратор, creational — Singleton и behavioral — Observer. Это реально, остальные просто знайте что есть. Для джуна это нормально.

3) Как вы относитесь к различным онлайн курсам типа: курсера. юдасити. У меня начинает складываться впечатление, что там знания дают довольно поверхностные и много воды. Что Вы используете в большей степени при самообучении? Возможно посоветуете ресурсы?

У меня тоже впечатление, но это впечатление. Тут довольно сложная и большая тема возникает о самом формате обучения, у меня по этому поводу очень много мыслей но не все ещё сформулировал для себя. Если в двух словах то примерно такие мысли:
* Курсера — это всё таки курсы солидных унверситетов, это уже вызывает доверие. Это годами отработанные обучающие материалы, и они там не зря. Зарплаты преподавателей огромны, и это люди как правило имеющие отношение к реальной индустрии.
* Качество курсов от чуть ниже нормального до хорошего. Отлично сделать практически невозможно, всегда будет какая-то вода, всегда будут недостаточно хорошие примеры. Всегда может быть по теме более интересная книга или туториал на ютубе, всегда можно найти чувака который лучше расскажет, но на курсе всегда будет некая усреднённая доведённая до занудства «академичная» информация.
* Что ещё важно там есть вопросы для самопроверки и определённая сертификация. Это очень важно, а просто книга такого не даст.

Всё. Больше никаких особо преимуществ нет и быть не может. На курсере невозможно получить практическую пользу и интерес большую чем от реального проекта или видео на ютубе.
Это всё равно что сравнивать статью в Википедии и статью на Хабре.
Но если взять статью на хабре и дописать к ней то что в ней опустили, и убрать то что может меняться со временем, попытаться вывести из материала какие-то общие законы и убрать субъективный и упрощённый научно-популярный стиль, то получится та же статья с Википедии.
Например, вот одна из самых первых статьей про Юнит тестирование за 2008й год к тому моменту это уже докатилось до нас и было отхоливорено со всех сторон и эта статья была подведением черты.
А вот какая статья в Википедии на сегодня.
А вот все курсы на Курсере где тебя обучат рефакторингу.

Например я бы мог в сто раз лучше базы данных чем на курсере, но я бы два года составлял курс прорабатывая материал, отбирая что важно что не важно, прийдя к выводу что всё важно, тестируя эффективность на студентах и он бы у меня разросся в пять раз больше и я бы стал его сокращать а на выходе получилось бы почти тоже самое что сейчас на курсе Introduction to Databases.

Нужно чётко осознать важный закон: кто не знает, но умеет — делает, кто знает, но не умеет — учит, кто не знает и не умеет — руководит.

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

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

Но где же найти тех кто реально шарит, и рассказать может хорошо и правильно, и самый свежий опыт?
Собственно мы программисты постоянно и много обучаемся, поэтому уже всё сформировали для себя:
* Блоги, правки в документации, меил листы, форумы, StackOverflow, скринкасты, туториалы, и напрямую чтение спецификаций. Написать более менее толковую развёрнутую статью занимает ну просто дофигища времени, сколько точно не знаю, зависит, но четыре часа минимум. А теперь представь что ты синьйор с загруженным графиком, у тебя семья, как ты выдыхаешься и при этом найти время и силы написать статью. А потом ещё переругаться с тролями в каментах.
* Конференции с докладами по часу-два с презентацией или мастер классом с живым кодированием. На подготовку одного часового доклада может уйти почти столько же времени как на статью, но, статью нужно писать и это напрягает, а презентацию к докладу накидывать как-то намного приятнее и там рассказывать можно голосом по ходу подстраиваясь под публику.
* Книги, программисты читают много их.

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

Так что пока вы джуны и вы учитесь, вам просто придётся всё время искать самим хорошую информацию по кускам и смирится что та полная что есть «академическая» скучная и с множеством воды. И постоянно искать себе менторов и спрашивать у них что нужно именно на практике. На примере шаблонов я это показал. Ваша задача — как можно быстрее устроится на работу, а там уже будет точно видно что нужно а что нет.

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

Я сам почти не проходил никаких курсов на Курсере (где же взять 8 недель на это?), но из того что видел считаю самым полезным и вменяемым курс основам вычтехники The Hardware/Software Interface. Тут вам расскажут как работает булева алгебра, как устроен компьютер, как считаются и складываются числа внутри, что такое указатели, освоите основы Си и перейдёте к высокоуровневым языкам. При этом это полноценный курс с множеством классных заданий.
Это очень и очень правильный курс который закрывает огромный пробел знаний и почти полностью имеет практическую пользу. Всё остальное что на курсере по компьютерам, имхо можно выкинуть нафиг. Разве что по алгоритмам может адекватный курс, но не смотрел.

4) Хочу начать делать какой-то пет проект, но не очень представляю с чего приступить.

блядь, просто начни

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

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

Могу дополнить только что у вас должна быть личная мотивация и интерес сделать проект. А такое может быть только если вы делаете программу для себя.
Например мой знакомый когда учил английский сделал себе программу под 1С с тестом слов. Потом когда он учил Джаву он себе написал фотовьювер как ему нравился.
Напиши любую программу например свой броузер. Джаст фор фан, пофигу что такое уже есть. А вдруг в твоей программе будет (или не будет) такой функционал который кому-то нужен. Твоя программа может найти своего пользователя и вырасти в полноценный продукт, как это было например с операционной системой Linux которую написал школьник а теперь используется многомиллиардными корпорациями.

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

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

Но.
Есть очень много софта который поддерживает плагины. И вот тут получается ситуация что ты делаешь свой проект в рамках другого, т.е. разбираешься с их кодом и у тебя есть примеры других плагинов, но при этом то что ты напишешь это твой отдельный проект.
Это такой симбиоз и очень классно работает на практике. Более того, у меня в университете один более менее вменяемый препод прямо так и давал задание написать плагин в Тотал Командеру.
Я например так когда-то написал плагин для Pidgin где мне пришлось изучить Си, программирование под Линукс и много ещё чего.

Ещё советуют брать заказы на фрилансе, но это тоже бред. Никто вам ничего нормального не доверит.

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

Что реально ещё работает: у Гугла есть программа Summer of Code и в её рамках можно поконрибьютить в опенсорс проекте под присмотром менторов. Опенсорс проекты готовят задачи для студентов и вместе их фигачат.
Вот например есть интересная программа для чата и онлайн звонков Jitsi и её страница с идеями для GSoC.
Задачи довольно интересные и в меру сложные.

5) Посоветуйте проекты с открытым кодом на Java, чтобы посмотреть как строиться архитектура и тд.

Опять таки, берите проект с плагинами и пишите свой плагин. А так, я не знаю что посоветовать, но есть например книга The Architecture of Open Source Applications и в ней же есть и описание тай же Jisti.
Вот посмотри исходники проектов из этой книги.

6) Как вы совмещаете изучение теории и практики? Предпочитаете читать только то, что в данный момент необходимо или же изучаете наперед?

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

P.S. Статью написал под эту песню

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

Human readable past date formating in Grails

Sometimes it better to write ‘2 days ago’ instad of ’28 Jan 2015′.
You can find a lot of solution in How to calculate “time ago” in Java?.

Here is a simplest snippet for making it in Grails from my project with i18n support.
Just create new tag `timeAgo` in your project taglib:

    static encodeAsForTags = [ timeAgo: [taglib:'html'] ]

    final static long ONE_SECOND = 1000;
    final static long ONE_MINUTE = ONE_SECOND * 60;
    final static long ONE_HOUR = ONE_MINUTE * 60;
    final static long ONE_DAY = ONE_HOUR * 24;

    /**
     Converts time (in milliseconds) to human-readable format
     "<w> days, <x> hours, <y> minutes ago" or "just now"
     <code>
     System.out.println(millisToLongDHMS(123));
     System.out.println(millisToLongDHMS((5 * ONE_SECOND) + 123));
     System.out.println(millisToLongDHMS(ONE_DAY + ONE_HOUR));
     System.out.println(millisToLongDHMS(ONE_DAY + 2 * ONE_SECOND));
     System.out.println(millisToLongDHMS(ONE_DAY + ONE_HOUR + (2 * ONE_MINUTE)));
     System.out.println(millisToLongDHMS((4 * ONE_DAY) + (3 * ONE_HOUR) + (2 * ONE_MINUTE) + ONE_SECOND));
     System.out.println(millisToLongDHMS(42 * ONE_DAY));
     </code>
     output :
     0 second
     5 seconds
     1 day, 1 hour
     1 day and 2 seconds
     1 day, 1 hour, 2 minutes
     4 days, 3 hours, 2 minutes
     42 days
     */
    private String millisToLongDHMS(long duration) {
        StringBuffer res = new StringBuffer();
        long temp;
        if (duration >= ONE_MINUTE) {
            temp = duration / ONE_DAY;
            if (temp > 0) {
                duration -= temp * ONE_DAY;
                res.append(temp).append(' ').append(temp > 1 ? g.message(code: 'timeAgo.days') : g.message(code: 'timeAgo.day')).append(duration >= ONE_MINUTE ? ', ' : '')
            }
            temp = duration / ONE_HOUR;
            if (temp > 0) {
                duration -= temp * ONE_HOUR;
                res.append(temp).append(' ').append(temp > 1 ? g.message(code: 'timeAgo.hours') : g.message(code: 'timeAgo.hour')).append(duration >= ONE_MINUTE ? ', ' : '')
            }
            temp = duration / ONE_MINUTE
            if (temp > 0) {
                res.append(temp).append(' ').append(temp > 1 ? g.message(code: 'timeAgo.minutes') : g.message(code: 'timeAgo.minute'))
            }
            res.append(' ').append(g.message(code: 'timeAgo.ago'))
            return res.toString()
        } else {
            return g.message(code: 'timeAgo.justNow')
        }
    }

    /**
     * @emptyTag
     *
     * @attr date the date in past
     */
    def timeAgo = { attrs ->
        Date date = attrs.date
        out << millisToLongDHMS((new Date().getTime()) - date.getTime());
    }

And then you need to add message codes in `messages.properties`:

timeAgo.justNow=just now
timeAgo.minute=minute
timeAgo.minutes=minutes
timeAgo.hour=hour
timeAgo.hours=hours
timeAgo.day=day
timeAgo.days=days
timeAgo.ago=ago
# for Russian
timeAgo.justNow=только что
timeAgo.minute=минуту
timeAgo.minutes=минут
timeAgo.hour=час
timeAgo.hours=часов
timeAgo.day=день
timeAgo.days=дней
timeAgo.ago=назад
# for Ukrainian
timeAgo.justNow=тіки що
timeAgo.minute=хвилину
timeAgo.minutes=хвилин
timeAgo.hour=годину
timeAgo.hours=годин
timeAgo.day=день
timeAgo.days=днів
timeAgo.ago=тому
1 комментарий »

Отслеживать

Get every new post delivered to your Inbox.

Join 814 other followers