Понедельник. Постановка задачи

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

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

Покинуть Google было непростым решением. За время моей работы там я стал довольно страстным поклонником компании. Я выступал на четырех Google Developer Day, на двух Google Test Automation Conferences и был плодовитым участником блога Google Test. Рекрутеры часто просили меня помочь уговорить очень перспективных кандидатов на работу в компании. Меня никто не должен был просить дважды для поддержки Google, и никто более меня не удивился тому, что я не смог это продолжать. На самом деле последние три месяца работы в Google были вихрем отчаяния в тщетной попытке вернуть прошлую страсть.

В течение последних двух лет я использовал Maven как инструмент для сборки проектов. В результате я остался весьма недоволен Мавеном, недоволен настолько, что всерьез обдумываю перевод нынешнего проекта на Ant.

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

Часто когда начинаешь работать на SWING сталкиваешься с проблемой понимания Layout.
Сама идея очень хорошая, но для людей которые работали только в визуальных средах это становится большой проблемой. Не может человек понять почему быстрее написать код чем накидать его в GUI дизайнере. Сам я со свингом плотно работаю около 2 лет и вот решил рассказать про замечательную библиотеку JGoodies Form Layout. Статей наверное пока будет только три, если все хорошо буду писать дальше.

И так часть первая вводная.

В данном примере мы рассмотрим базовые возможности Form Layout. FormLayout — это фактически таблица, только с очень гибкими настройками, благодаря им можно получить любой интерфейс с минимальными затратами.

Служба безопасности Украины возбудила уголовное дело по четырем статьям уголовного кодекса:

• ст. 201 — Контрабанда
• ст. 15 — Покушение на преступление
• ст. 263 — Незаконное обращение с оружием, боевыми припасами или взрывчатыми веществами
• ст. 359 — Негласное получение информации

… за две заказанных на dealextreme видеокамеры в виде брелока и перочинный ножик.

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

Самое интересное, что по логике следствия, примерно у 99% украинских читателей хабры есть спецсредство в виде мобильного телефона. Будьте осторожны!

Детали дела на distributed.org.ua/forum/index.php?showtopic=5245

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

Если вы работаете в бумажной газете или журнале, то вот вам самая страшная картинка года.


А вот ссылка на исследование, результатом которого стала эта картинка.

Тема глупых вопросов на собеседовании поднимается на Хабре довольно часто. Ниже мой перевод отличного комикса Oatmeal на эту тему:

Доброго времени суток.

Хочу поделиться некоторыми идеями которые помогают мне в Святой Войне с Хаосом в процессе разработки ПО. Для определенности картины добавлю несколько деталей: я — менеджер проектов, фирма средних размеров (~40 мозгов) занимается оффшорным программированием, команда смешанная (15% сеньоры, 35% девелоперы, 35 джуниоры, 15% стажеры, причем есть еще деление по специализации — разработка, качество, инфраструктура).

Процесс

Источников создания хаоса более чем достаточно — длинная цепь связи с заказчиком, неоднородная и в общем, молодая команда, «славянский менталитет» ( эксцентричное творчество и частые медитации ;) ), проблемы коммуникаций, политические игры сейлс-людей (Sales — те кто нас «продают») и т.д.

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

Только вчера закончил свой первый, полнофункциональный портлет для Liferay (SVN/Mercurial/CVS браузер) — и хочу поделится некоторым опытом (пусть и минимальным). К тому же по Liferay вроде на Хабре еще ничего не пробегало. Статья очень поверхностная — но тем не менее, надеюсь, даст некоторое начальное представление

После заметки о выходе книги «Разгони свой сайт» ко мне обратились с просьбой осветить процесс публикации собственного издания. Не скажу, что описанные ниже действия были простыми и очевидными: в ходе возникло масса вопросов, на которые я с трудом мог ответить самостоятельно, поэтому приходилось искать совета буквально везде.

Предыстория

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

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

За все время, проведенное в написании кода на Java, у меня сформировался определенный набор полезных cторонних библиотек, которые прочно засели в classpath, и без которых не обходится ни один день разработки, будь то написание чего-либо «на коленке» или работа над серьезным проектом. Речь идет не о «монстрах» вроде Spring, Struts, Hibernate (это другая история), а скорее об утилитах, которые заполняют пробелы в Java SE API и позволяют сэкономить десяток-другой лишних строк кода/минут тут и там. Этой информацией я бы и хотел поделиться с хабрасообществом — надеюсь, она пригодится особенно тем, кто только начинает штурмовать Java, и позволит немного, но увеличить производительность труда.

Итак, список наиболее часто используемых мной классов и методов с комментариями:

Текущий проект на работе разросся до огромных размеров и продолжает расти.
Так получилось, что большая часть была создана людьми, которые уже не в проекте. И качество кода многих компонент зачастую ужасно. Но все это работает, пользователи всем этим пользуются и потому русское
«Это все никуда не годиться. Легче все написать заново» — не применимо.

Проект построен на связке tomcat,struts c java-сервером работающим с postgres. С веб-частью(tomcat) вроде все нормально. В самом сервере каша — где сам функционал по работе с БД.

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

Потому хочется почитать что-то по теме и дать почитать коллегам.
Не то чтобы я с луны свалился. Опыт какой никакой есть. И книг перечитано не мало.
Но возможно хабра-люди посоветуете что-то наиболее практичное с вашей точки зрения, без сухой теории.
(на русском языке, в бумажном виде, по теме: архитектура, паттерны проектирования, рефакторинг, разработка корпоративных приложений) — что-то наиболее приближенное к практике разработки большой быстро расширяемой системы.

уже есть(читал) по теме или близко:
— Рефакторинг. Фаулер
— Совершенный код. Стив Макконнелл
— Архитектура корпоративных программных приложений. Фаулер (хорошая книга)
— Еще какие-то одинаковые книги типа «Разработка корпор.приложений с помощью UML, J2EE» от
Гради Буча и пр.

Интересно не что-то общее из цикла типа RUP процессов разработки, а конкретно по архитектуре
и шаблонам развертывания, на примере конкретных коммерческих проектов.

Заранее спасибо за комментарии

Вдохновившись этим постом и взяв на заметку эту идею, менее, чем за час, собрал стол для работы стоя на запчастях из Икеи. Зачем — смотрите тут. Стоимость базовых элементов — 578 рублей.

1 октября состоялась первая конференция Scala-разработчиков в Санкт-Петербурге.

Гости из разных уголков России (и не только), посетившие в тот вечер уютный бизнес-инкубатор «Ингрия», имели возможность послушать интересные доклады и пообщаться с коллегами по цеху.



Под катом вас ждут видео докладов с конференции:

• «Использование Scala для backend задач» Эдуард Клементьев
• «Scala in Goozy» Алексей Злобин
• «Scala plugin for IntelliJ IDEA» Павел Фатин и Александр Подхалюзин
• «Squeryl — ORM с человеческим лицом» Юрий Буянов

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

Когда я* говорил, что нужно вкладывать в сообщество и User Groups, вы вкладывали в теннисные столы. Теперь у нас много средненьких теннисистов и нет коммюнити.

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

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

Парадигмы программирования

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

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

• инструкция (императивное программирование, FORTRAN/C/PHP),
• функция (функциональное программирование, Haskell/Lisp/F#/Scala),
• прототип (прототипное программирование, JavaScript),
• объект (объектно-ориентированное программирование, С++/Java),
• факт (логическое программирование, PROLOG).

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

В этой статье я хочу рассказать о сравнительно молодой, но крайне, на мой взгляд, полезной парадигме программирования – аспектно-ориентированном программировании.

Размеры объектов в Java уже обсуждались на Хабре, например, здесь или здесь. Мне бы хотелось подробнее остановиться на размерах многомерных массивов — простая вещь, которая для меня стала неожиданной.

Оптимизируя вычислительный алгоритм по памяти, я наткнулся на то, что при определённых (вполне разумных) входных параметрах создаётся массив float[500][14761][2]. Сколько он может занимать в памяти (на HotSpot 1.6.0_26 32bit, если кому интересно)? Я примерно прикинул, что 500*14 761*2*sizeof(float) = 500*14 761*2*4 = 59 044 000 байт плюс какой-то оверхед. Решив проверить, как на самом деле, я воспользовался Eclipse Memory Analyzer (невероятно волшебная вещь, рекомендую!) и обнаружил, что «Retained Heap» для этого массива составляет 206 662 016 байт! Неплохой оверхед — 350%. Посмотрим, почему так получилось.