Отчёт о #kranonit S08

Друзья, спасибо большое всем кто был на встрече.
Видео и скринкаст у нас не получилось записать :'(
Вы большие молодцы что выдержали АЖ ЖЕСТЬ ЧАСОВ сложного доклада на совсем не интересную тему.

Я рассказывал по чужим презентациям, вводная от Николая Алименкова

Видео

• Я упоминал про статический анализатор кода Sonar через который мы можем определить качество нашего кода.
  В интернете много информации по нему, я даже не знаю что посоветовать. Но если кому интересно я рассказывал о нём в рамках курса интенсива по яве.
• Рассказал про бесплатную онлайн конференцию ITBrunch, всем советую.
• Порекомендовал линейку продуктов от JetBrains.
• Все самые важные принципы хорошего проектирования описаны в этой статье

Затем я пересказывал лекцию Сергея Сергеева из Яндекс.ШРИ о системах контроля версий. По сути я просто чуть проще пересказал. Видео моего пересказа нету, так что смотрите видео оригинальной лекции.

Итак, мы узнали про GitHub и зачем он нужен.
Вы можете научится базовой работе с гитхабом на этом онлайн тренажёре.
Если вы уже знакомы с гитом то гляньте на онлайн тренажёр по ветвления в гите.
На самом деле нужно знать не так много базовых команд. Достаточно init, clone, pull, commit, push.
Это команды которые помогут вам выжить первое время, а дальше - работайте с гитом через IDE, а консоль оставьте угрюмым линуксоидам.

Дальше я показал всем пример простенького юнит теста на Яве который я подробно описал в статье.


Затем мы прошлись по первой главе книги Мартина Фаулера о Рефакторинге
В результате у нас получился такой проект на гитхабе

ВСЕМ ДОМАШНЕЕ ЗАДАНИЕ - форкнуть проект, и дописать все рефакторинги которые дальше идут в первой главе и позже сделать пул реквест.

Кто справится, тот получит значок с улыбайтом ;)



Если вы чуть более опытный специалист, то я очень советую посмотреть видеозапись лекции о рефакторинге от Саши Баглая.

Список книг для самостоятельного прочтения.
А когда станете совсем крутыми, прочтите ещё Джошуа Кериевски: Рефакторинг с использованием шаблонов.

Dev database

HQSQL крут тем что сама БД в файл сохраняется как SQL скрипт который её создаёт и начиняет данными.

Это очень удобно, не нужно дополнительного клиента чтобы посмотреть содержимое БД.
Можно ложить его в VCS и отслеживтаь изменения.

А вот H2 так не умеет, у него БД имеет бинарный формат. Это кстати странно, потому что H2 разрабатывал автор HQSSQL, и вообще H2 значит Hipersonic 2.
Ну, ну конечно, можно дампится в SQL и его уже ложить под контроль VCS, но зачем лишние телодвижения?

Grails GORM: Избегайте HQL и уже тем более SQL запросов

GORM построен поверх Hibernate а в нём есть два API для работы с БД: Hibernate Query Langauge (HQL) и Criteria API.
HQL по сути тот же SQL, только не специфичный для конкретной БД:

def results = Book.findAll("from Book as b where b.title like 'Lord of the%'")

Criteria API это объектно ориентированный подход к построению запросов. От этого он может получатся менее выразительным и громоздким. Но в замен вы получаете более удобный механизм генерации сложных запросов в ООП стиле, вместо генерирования HQL как текста (а значит и меньше ошибок связанных с некорректным HQL):

def c = Account.createCriteria()
def results = c {
    between("balance", 500, 1000)
    eq("branch", "London")
    or {
        like("holderFirstName", "Fred%")
        like("holderFirstName", "Barney%")
    }
    maxResults(10)
    order("holderLastName", "desc"

Кроме того, вам не нужно отдельно учить синтаксис SQL и HQL, что позволит новичкам быстрей разобраться с этим кодом. И уж тем более новичкам будет сложней сделать ошибку, поскольку запрос становится статически типизированным и ваша IDE может подсказать автодополнение а компилятор ругнутся на ошибку.
Если в Java иногда предпочитают HQL за его краткость, то Grails предоставляет удобный DSL для Criteri API, так что даже этот аргумент теряет свою важность.

И самое главное, запросы в Criteria API стиле могут быть программно проанализированы и это позволяет покрыть интеграционными тестами код который работают БД. Grails предоставляет просто шикарный тестовый фреймворк который позволяет тестировать работу с доменными объектами имитируя работу с GORM через лёгое in-memory хранилище.

Самое вкусное что большую часть простых запросов вы можете выполнить через механизм динамических методов с префиксом findBy (finders, файндеры):

def book = Book.findByTitle("The Stand")
book = Book.findByTitleLike("Harry Pot%")
book = Book.findByReleaseDateBetween(firstDate, secondDate)
book = Book.findByReleaseDateGreaterThan(someDate)
book = Book.findByTitleLikeOrReleaseDateLessThan("%Something%", someDate)

Внутри себя Grails конвертирует их в Criteria API запросы.
По возможности старайтесь использовать такие динамические файндеры они более краткие и очень выразительные.

И напоследок, обязательно изучите руководство по GORM'у чтобы не плодить проблем. Именно запросы в БД чаще всего являются узким местом в вашем приложении из-за которого проседает производтельность.
К сожалению в GORM очень много ловушек многих из которых избежать вам помогут три статьи евангелиста Grails Питера Ледбрука (Peter Ledbrook):

1. GORM GOTCHAS (PART 1) Перевод на русский
2. GORM GOTCHAS (PART 2) Перевод на русский
3. GORM GOTCHAS (PART 3) (перевода на русский нет)

Интерфейсы программ

• консольный
• консольная с выводом в XML
• текстовая графика
• CGI
• оконный интерфейс
• просто графический интерфейс (как в играх)

Свойства ПО

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

Однако откуда такой недостаток программистов? И при том что институты, онлайн учебники, книжки PHP для чайников миллионами штампуют каких то невнятных кодеров.

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

Вообщем когда вы принимаете инженерные решения нужно учитывать много факторов. От этих факторов зависит и выбор языка программирования, стека технологий да и процесса разработки (ну там SCRUM, Kanban, RUP). И про эти факторы и желаемое свойства ПО я хочу поделится своими наблюдениями, всего лишь информация к размышлению. Ну начнём с простого, очевидного и самого популярного у начинающих программистов…

Скорость работы программы.

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

Примеры: разворачивание циклов, арифметика указателей, битовые операции, инлайнинг функций, безусловные переходы goto, быстрый обратный квадратный корень.

Актуально для игр, баз данных, какого нибудь специфичного софта для обработки потоков информации (видео, сеть).

Языки лучшие для достижения этого свойства: Си/Си++, местами возможен ассемблер.

Тут прийдётся очень туго — увеличение скорости как правило достигается усложнением системы, переход на чуть ли не процессорный уровень абстракции. Это очень портит жизнь: сопроводительность программы осложняется, размер программы увеличивается, масштабируемость, скорость разрабтки падает, короче ухудшается ВСЁ.

Скорость работы на деле же оказывается самым ненужным параметром, скелет которого только изредка вываливается из шкафа. Поэтому как это не парадоксально, скорость программы это то на что нужно твёрдо забить и лишь оптимизировать самые тормознутые участки и только когда возникла практическая нужда. Если у вас сильно большие проблемы со скоростью, то скорее всего вам нужно поработать над алгоритмами, масштабируемостю и архитектурой приложения (возможно поменяв стек технологий).

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

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

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

Скорость алгоритмическая

Правильно подобраные алгоритмы могут существенно увеличить скорость.

Например: фильтр Блума, двоичный поиск, контрольные суммы.

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

Масштабируемость и высоконагружаемость

Ну или как это назвать. Это возможность увеличить производительность системой просто добавив ещё один сервер (node — узел) в кластер. Здесь стоит отметить что масштабируемость бывает вертикальная (интенсивная), когда мы увеличиваем мощность одного серера, и горизонтальная (экстенсивная) когда мы просто рядом ставим ещё один слабенький сервачок.

Чтобы так разрабатывать софт нужны совершенно другие подходу к софту.

Стек технологий: NoSQL, алгоритм Map/Reduce.

Точность

Это нужно для научного софта (математического, физического).

Ну прийдётся все константы увеличивать намного, плясать с бубном над вычислениями с большими числами. Для всего этого есть специальные математические библиотеки, в том числе и Matlab.

Стандартность

Соответствие всяким RFC, J2EE спецификациям, прохождение ACID тестов броузерами, ANSI SQL.

Это хроническая проблема майкрософта которую они превратили в своё конкурентное преемущество.

Обфускационность.

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

Защищённость и безопасность

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

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

Обратная совместимость.

Особенно актуально во всяких open source библиотеках, платформах, операционных системах.

Майкрософт этому очень большое внимание уделяет и спустя 20 лет вы до сих пор можете запустить большинство MSDOS программ даже на семёрке.

Качество (отсутсвие дефектов)

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

Понятность

Вот самый важный параметр. Был. Сейчас уступил тестируемости и отошёл на второе место.

Вашу программу потом будут читать так что постарайтесь уж её сделать грамотно.

Так же стоит отметить что понятность это не обязательно «Идеальный код» или «Чистый код». Адский говнокод может быть вполне понятен.

Тестируемость

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

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

Юзабилити

Вас утомляет ждать перезагрузки всей страницы когда вы отправляете комментарий? Ага, ну тогда нужно делать пляски с аяксом. Значит увеличиваем сложность системы.

Юзабилити это отдельная наука со своими противоречивыми принципами. Например карандаш имеет очень простой интерфейс, но научится им пользоваться довольно тяжело (вспомните ваши калякул маракули в детстве или коптение над чертежами в институте). И другой пример: приборная панель самолёта, она тоже на самом деле обладает удобным интерфейсом.

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

Продолжение следует…

Все в клауд!

Сегодня прошла 14тая встреча (чёрт, уже 14тая!) клуба анонимных разработчиков от XP Injection.
Обсуждали Amazon Cloud и Microsoft Azure.
Про Amazon рассказывал Николай Алименков а про Azure рассказывали крутые спецы из Microsoft: Виктор Цикунов и Антон Бойко.
Реально круто. У меня ни с первым ни с другим опыта не было, но для себя подчеркнул несколько основных мыслей, которыми спешу поделится с вами:

• Облачные вычисления это не какой то модный тренд а вполне практически оправданный этап эволюции систем.
• Вы можете в любой момент заказать себе сервера если вдруг нагрузка на ваш сайт увеличилась. Не нужно возится и покупать железо - два клика и через две минуты у вас уже свой сервер.
• Нужно перелопатить кучу данных или запустить тестовую нагрузку на вашу систему? Купили сервер на пару часов, сделали и потушили.
• Это выгодно. Реально выгодно. Держать своё железо, обеспечивать его питанием и вентиляцией, обновлять и держать админа-башечитателя больше не нужно.
• Расширятся нужно горизонтально (экстенсивно) а не вертикально (интенсивно). Проще дозаказать пару слабеньких серверов чем один супер квадрупал.
• Если не тушить машины после их использования (особенно перед выходными) это вам влетит в копеечку. Проинструктируйте джунов про технику безопасности.
• Амазон имеет очень адекватный сапорт и секьюрити команду. Поспамить и вдоволь покраулить не выйдет.
• Амазон предоставляет Infrastructure as a Service (IaaS) - всё делаете ручками, Azure Platform as a Service (PaaS) - всё делаете кликами мышки.
• По ценам примерно одинаковые, но Azure имеет много приятных моментов сэкономить.
• Майкрософт реально молодцы: с ними можно договариваться. Предоставляют бесплатно (!да да!) своих технических консультантов. Дают бесплатно тестовый доступ. Проводят бесплатные тренинги. Прислал своих бойцов в нерабочее время рассказывать 15ти гикам до 12ти ночи. Вообщем активно занимаются привлечением клиентов и их поддержкой. Амазон на это положил, его итак все используют.
• Linux в Azure таки не поднять. Ну собственно никто и не сомневался :) Но это вызвано чисто техническим аспектом, он даже поддерживает только новые серверные винды (т.е. семку нет). В новых виндах есть специальный сервис для взаимодействия с Azure. Это расплата за PaaS. В Амазоне все изобретают свои велосипеды.
• Софт на виртуалках тоже подлежит лицензированию по полной программе. MS дают софт в аренду. Скорее всего вам прийдётся переходить на свободные решения.
• Из Visual Studio Ultimate можно задеплоить в облако нажатием одной кнопочки Publish. Но эта студия стоит как автомобиль Lanos поэтому не актуально. К тому же деплоится 20 минут, но можно схитрить побыстрей.
• Майкрософт делает серьёзную ставку на Azure, уже вбухал 4 миллиарда долларов. И они правы. Продукт вышел реально клёвым и нетопорным. Это даже чувствуется в каждом пикселе интерфейса сочных админок на SilverLight. Особенно порадовал эмулятор облака на котором можно локально потестится.
• Вы можете выбирать регион в котором хостить сервер, причём у них разная ценна. До дальних регионов дольше пинг.
• Специально для Azure построено несколько датацентров, два в США, два в Европе и пару в южной Азии. Строить их стараются там где холодно. Один датацентр вообще на островном отшибе Европы - в Дублине. Потому что там круглый год +16 и сильный ветер который сам задувается в вентиляционные шахты. И наоборот, заказать сервер в жарком южноазиатском регионе вам обойдётся дороже.
• В мае будет халявный двухдневный тренинг от MS, места ещё есть. Давали ссылку но вспомнить не могу.

Спасибо организаторам, докладчикам и всем кто сегодня был и не стеснялся делится опытом за прекрасно и с пользой проведённое время!

З.Ы.

Вот тут камрад грамотно опускает мифы про клауды, призадумался.

[Перевод] Может ли программирование стать следующей массовой профессией?

Может ли программирование стать следующей массовой профессией так же как сельское хозяйство в 17-ом столетии, фабричная работа во время промышленной революции, строительство во время Великой Депрессии, и мануфактура после Второй мировой войны.
Даже лучше! Потому что программирование является творческим процессом, который может быть с или без традиционного (устаревшего?) офиса, и может создавать огромную личную и экономическую ценность.

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

Есть новая возможность, появившаяся для молодых людей чтобы получить продуктивную, предприимчивую, удовлетворяющую работу: они могут научиться программировать. Программирование это не то, чему трудно научится — любая аутсорсинговая компания берет людей без знаний и делает их Ява программистами за 3 месяца (Конечно, огромное значение имеет тут имеет талант и мастерство).
Программировать не дорого — с интернетом, облачными хостингами и открытым ПО.
До определенного момента программисты самообучаемы, и могут продолжить совершенствовать свои умения.

Есть даже великолепные сервисы: на подобии Treehouse и Codecademy, бесчисленые бесплатные онлайн курсы, Google Code University, приветливый Stack Overflow, персональные курсы вроде Dev Bootcamp, летние кружки для детей, и великолепные организации вроде CodeNow. Я уверен что перечислил далеко не все.

Ещё не так много ВУЗов обучающих программированию. Большинство их учит этому лишь как часть учебного курса.
Хотя конечно они так и должны делать — программирование это грамота, а не (только) специализированный навык. И даже дети могут начать программировать рано. Много студентов которые могут быть потрясающими в программировании, креативными, но при этом не развиваться в институтской (школьной) среде.

Существует огромный спрос на программистов, даже несмотря на общий уровень безработицы, так-что обучение программированию быстро вознаграждается.
Онлайн фриланс бирижи наподобии oDesk и Elance нанимают начинающих программистов по рейтам $15-20 за час и более.
Обучению программированию это один из лучших путей к предпринимательству. Программирование также доставляет студентам удовольствие творчества и мастерства.
Программирование однажды станет базовым профессиональным навыком — наподобие отправки электронной почты или «профессиональное владение Word-ом».
Молодые люди также готовы это изучать: программирование сейчас бренд. Парень который пишет под iPhone или Android, сегодня заполучает девчонку (ну или мальчика).

Есть даже возможность делать больше чем просто научится программировать — а стать элитным программистом, и для этого не обязательно идти в ВУЗ.
Мы сейчас на ранней стадии обучения программированию как профессии. Большинство академических курсов направлены на обучение студентов теории а не практике.
(В США только программа обучения колледжей из Лиги Плюща требует одного курса где студенты непосредственно пишут код.)
Представьте если студенты которые даже не смогли поступить в ВУЗ могут стать элитными программистами.

Для нас в США главной идеей развития является создание нового поколения учёных.
И это так и отражено в том как мы называем предмет программирования — компьютерная «наука» (computer science).
Мы можем сделать что-то другое (или в дополнение), обучая студентов быть ремесленниками, а не учёными: создать следующее поколение тех кто может хакать, творить, зарабатывать сразу, и возможно стать предпринимателями.
Обучение этому может сделать высшее образование более ценным, потому что это будет давать непосредственный результат.

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

© Roy Bahat

Инспекции Idea

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

Я немного потрудился на выходных и написал простой плагин к Идее который сгенерировал список инспекций. Вот он:


Теперь просто скопируйте его себе и покажите команде. Уверен дискуссия будет жаркой и познавательной :)

Лекция для студентов как стать программистом

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

И вот в очередной раз наткнувшись на программистском форуме тему про ВУЗы я вспомнил что как раз сейчас мой брат свободен, а значит может дать лекцию в моей alma mater.

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



Я для себя тоже много нового подчеркнул.

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

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

Обновление

Ещё обязательно посмотрите отличный доклад "Яков Файн - Becoming a Professional Java Developer"


Слайды презентации
Becoming a Professional Java Developer (PDF)

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

Обновление 2

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

Модификаторы в Java для начинающих (public, private, static)

Начинающие изучать Яву часто путаются в модификаторах.
Например когда объявлять классы публичными, а когда приватными?
Вот пару простых советов которые я частенько даю начинающим пилить Джаву. Они помогут вам выжить первое время:

• Классы всегда создавайте публичными.
• Не делайте вложенные классы (inner classes).
• Все поля классов всегда создавайте приватными а для доступа к ним генерируйте гетеры и сетеры. Внутри класса обращайтесь к ним напрямик, а снаружи только через гетеры.
• Как бы это не было тяжело, не создавайте статических полей или методов. Исключение константы — всегда объявляйте их публичными, статическими и финальными public static final.
• Приватное private или защищённое protected поле это не для безопасности! Это просто уcловная черта для скрытия деталей от других классов чтобы вы случайно не поменяли извне сугубо внутреннее поле.

Учтите что это вам советы только на первое время, потом обязательно разберитесь с этими модификаторами.

Java Evenings в Cogniance

Побывал сегодня на Java Evenings в Cogniance. Понравилось. В голове всё перемешалось, но всё равно отпишусь.

Первым выступил Дмитирий Думанский с полезным и интересным докладом «Размер объектов в Java».
Для себя вынес следующее:

• «Аппаратно» (т.е. не математично-алгоритмично) оптимизировать мы можем: память, процессор, ввод/вывод, блокировки.
• Java прожорлива по памяти, приложения на джаве как правило отъедают не менее 10% всей памяти. И именно её и нужно оптимизировать в первую очередь.
• Память сжирают: утечки, много данных и большие данные (? я разницу понял только интуитивно и забыл переспросить).
• Даже более менее адекватно написанное приложение может вполне поймать неадекватный OutOfMemoryException
• Оверхед на память способен довести бородатого сишника до инфаркта.

А теперь в цифрах.
У каждого объекта есть заголовок который всегда занимает 8 байт, из которых 4 байта это обязательный хешкод а остальные четыре отданы под другие ништяки, вроде Type Pointer.
Все поля выравниваются до double word, в итоге даже просто byte поле отъест 8 (ВОСЕМЬ!) байт. Однобитный примитивный булен тоже, но уже не факт, ибо его размер вообще не специфицирован плюс JVM их агрессивно оптимизирует.
Отсюда следует, что размеры все объектов всегда кратны 8ми. Можно этим затроллить синьора на собеседовании ;)

Объектные обвёртки примитивных типов - крайне плохая идея с точки зрения памяти. Зато их проще всего оптимизировать.
Если у вас есть not null поле

@NotNull
Long id;

то можно абсолютно безболезненно его сделать примитивным

@NotNull"
long id;

Дальше все ахнули узнав что строка из трёх букв съест 72 байта. Поэтому ещё одной из популярных оптимизаций является отказ от строк в качестве ключей во всяких там Map.
Пустой хешсет занимает около 200 байт. Хешсет из Guava уже два кибибайта.

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

Дальше больше, 64хбитная JVM расходует памяти на заголовки почти в два раза 32битной.
В итоге при переходе на 64битный JVM у вас вдруг откуда не возьмись... OutOfMemoryException.

Закончил Дмитрий предостережением от преждевременной оптимизации.

Вывод: Однозначно нужно изучить модель памяти в Java, даже если вам кажется это лишним.

UPD
Дмитрий Думанский отметил множество технических неточностей в моём отчёте и любезно предоставил презентацию и статью на хабре. Настоятельно рекомендую.


Затем Андрей Гусев взбодрил всех докладом «Funny Java» на половину состоявшим из классических задачек SCJP и Java Puzzlers (ссылка для копимистов).
В очередной раз поймал себя на мысли сколько неочевидного можно встретить и как легко попасть на очевидном.

Выводы: 1) Нужно сертифицироваться, во время подготовки машинально запомнишь такие приколы. 2) Не экономьте на IDE, и включите все инспекции, а там как поймёте для чего они, то если что отключите. Лучше перестараться, чем недоглядеть.


Последним выступил Дмитирий Пекарь с рассказом про Hazelcast.
Это был не сколько доклад, а сколько формат беседы и обменом опыта.
Для себя вынес: Легко подключаемый и конфигурируемый джарник, который предоставляет деценетрализированое In-Memory хранилище (O_o синхронное?), с внятным API и возможностью писать запросы на чём-то похожем на SQL. Я правда не очень понял чем он от Касандры отличается.


Потом было пица и пивко, что было кстати очень кстати.

Спасибо огромное докладчикам, организаторам, всем присутствующим и компании Cogniance растящей таких специалистов!

Формат данных в QR коде

Спецификация QR кода не описывает формат данных.
Наиболее популярные программы просмотра QR кодов поддерживают такие форматы данных:

Тип данных	Формат
URL	http://www.example.com/
Закладка в браузер	MEBKM:TITLE:Example site title:;http://www.example.com/;;
Email (с темой письма)	user@example.com:subject:Hello!
Номер телефона	tel:19172073420,12122034357,1917456321
SMS на номер	sms:911
SMS на номер c темой	SMSTO:1917456321:Hello
MeCard	MECARD:N:Pupkin, Vasily;TEL:1917456321
vCard	BEGIN:VCARD VERSION:2.1 N:Gump;Forrest TEL;WORK;VOICE:(111) 555-1212 END:VCARD
Географические координаты (vCard)	BEGIN:VCARD N:;Krivoy Rog GEO:33.495255;48.005314 END:VCARD
Географические координаты	geo:33.495255;48.005314

Также некоторые программы могут распознавать GIF, JPG, PGN или MID файлы меньше 4KB и зашифрованный текст, но эти форматы не получили популярности.

Вообще, это очень тупо. Я знаю одно простое решение проблемы форматов. Вы тоже его знаете достаточно научить ридеры распознавать заголовок Content-type.
Всего лишь одна строчка, а насколько шире станет выбор форматов. Можно например вполне будет засунуть гипертекстовый документ вовнутрь QR кода.

Также есть отличный тест для проверки вашего ридера (спасибо за ссылку iov).

З.Ы. Пытался эту инфу дописать в википедию, но она доблестно не давала мне этого сделать, типа "ой а у вас тут ссылки на внешний сайт, вы небось спамер". Мне так настроение давно никто не портил. Какой сайт? exemple.com? Вы читать RFC не научились?

З.Ы.З.Ы Во Львове QR кодами пометили все достопримечательности города. Отличная идея, можно тоже сделать в Киеве.

Эмотиконы, ну всмылсе смайлы :)

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

Идея проекта проста: мне надоело что в разных программах/аськах/форумах разные смайлы. И при том один и тот же смайл может обозначать разное.
Цель проекта:
Унифицировать все смыйлы, унифицировать репозитории смайлов, создать единый реестр смайлов, создать единую библитеку смайлов для всех программ, адоптировать смайлы для разных систем.
Языки реализации и платформы: все.
Основная реализация для гнома (pidgin and empathy), джавы (spark, android) и ПХП (drupal, joomla).
Сделать поддержку спецификации EmoticonML.
Создать сообщество художников, разработчиков и пользователей.

Тернарный условный оператор в Delphi/Pascal через функцию IfThen

Очень часто в коде мы пишем вот обычные конструкции if-then-else внутри которых присваиваем переменной значение.

Для примера напишем простую функцию определяющей минимальное число:

function Min(A, B: Integer): Integer;
var
  Min: Integer;
begin
  if A < B then
    Min := A
  else
    Min := B;
  Result := Min;
end;

А ведь очень часто таких вот конструкций в коде становится много, и они отнимают очень много места (аж четыре строчки!) и внимания у нас при том что они очень просты. Некоторые программисты записывают таки условия в одну строчку:

function Min(A, B: Integer): Integer;
var
  Min: Integer;
begin
  if A < B then Min := A else Min := B;
  Result := Min;
end;

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

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

Имеет он такую запись:

переменная = булево_выражение ? значение_переменной_если_выражение истинно : значение_если_ложь;

Вот так можно переписать нашу функцию на Си с его использованием:

int min(int a, int b) {
  int min;
  min = (a < b) ? a : b;
  return min;
}

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

Впервые он появился ещё в Алголе — праязыке всех современных языков, который успешно ввёл понятие структурного программирования. Паскаль это вообщем то и есть упрощённый Алгол, но вот тернарный оператор он почему то не унаследовал :(

Зато практически все другие современные языки программирования, которые унаследовались от Си, сохранили синтаксис этого оператора нетронутым, а это: C++, JavaScript (ECMAScript), Objective-C, C#, D, Java, PHP, Perl.

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

В Delphi это функция IfThen, о которой как я заметил многие дельфисты не знают.

// Объявленные в стандартном юните Math
function IfThen(ACondition: Boolean; ATrue: Integer; AFalse: Integer = 0): Integer;
function IfThen(ACondition: Boolean; ATrue: Double; AFalse: Double = 0.0): Double;
// Объявленные в стандартном юните StrUtils
function IfThen(ACondition: Boolean; ATrue: string; AFalse: string = ''): string;

Её описание из хелпа: Conditionally returns one of two specified values. IfThen checks the expression passed as ACondition and returns ATrue if it evaluates to true, or AFalse if it evaluates to false. If the AFalse parameter is omitted, IfThen returns 0 or an empty string when ACondition evaluates to False.

Теперь можно переписать наш пример нахождения минимального числа так:

function Min(A, B: Integer): Integer;
var
  Min: Integer;
begin
  Min := IfThen(A < B, A, B);
  Result := Min;
end;

Но есть пару нюансов:

1. типами аргументов у нас могут быть только примитивные Integer, Int64, Double и string. С объектами или перечисляемыми типы облом :(
2. Значения аргументов функции вычисляются перед её вызовом, поэтому в отличии от стандартного условного оператора if-then-else у произойдёт вычисление всех его веток и это может вызвать ошибку.
   

   Приведу пример, пользователь задал в поле Edit1 высоту формы Form1. Мы берём строковое значение поля Edit1, преобразовываем его в Integer и задаём в качестве высоты формы. Если поле Edit1 пустое задаём форме стандартную высоту в 400 пикселей.

   Вот реализация через IfThen:
   

   var
     FormHeight: Integer;
   begin
     FormHeight := IfThen(Edit1.Text <> '', StrToInt(Edit1.Text), 400);
     Form1.Height := FormHeight;
   end;
   

   Во время выполнения если мы оставим Edit1 пустым мы неожиданно получим исключение "Ошибка: пустая строка не есть число". Всё это горе нам потому, что программа сперва пытается вычислить значения передаваемых аргументов, т.е. преобразовать пустую строку в число StrToIn(''), а только потом вызывает IfThen. Это никак не объехать, так что прийдётся написать по старинке через блок if-then-else.

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

1. Если вычисления в аргументах IfThen довольно сложные или запись IfThеn не вмещается на одну строчку, перепишите этот код через стандартный блок if-then-else.
2. Никогда, никогда не делайте вложенные вызовы IfThen!
   
   Так писать нельзя!
   

   N := IfThen(A < 0, -1, IfThen(A = 0, 0, 1));
   

   Потом не разгребётесь.

Используйте IfThen почаще, но с умом и тогда ваш код станет лучше!

[Перевод] Принципы хорошего программирования

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

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

DRY (Don’t repeat yourself) Не делайте одну и ту же работу дважды

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

Принцип абстракции (Abstraction Principle)

Относящийся к DRY принцип абстракции: «Каждый значительный кусок функциональности в программе должны быть реализован в одном месте исходного кода».

KISS (Keep it simple, stupid!) Не усложняй, тупица

Упрощение (и избежание сложности) всегда должно быть ключевой целью. Простой код занимает меньше времени чтобы его написать, имеет меньше ошибок, и его легче изменить.

YAGNI (You aren’t going to need it) Вам это не понадобится

Вам стоит пытаться не добавлять функциональности пока она вам не нужна. Только потратите время на разработку, отладку, поддержку и будет постоянно мешаться.

Делай сразу простейшую вещь, которая скорее всего заработает (Do the simplest thing that could possibly work)

Когда программируете сразу задайте себе вопрос: «Что является простейшей вещью, которая могла бы вот сразу заработать?». Это помогает удерживать нас на пути к простоте дизайна.

Не заставляйте меня напрягаться и думать (Don’t make me think)

Это на самом деле это название книги Стива Круга о веб-юзабилити и также имеет отношение к программированию. Дело в том, что код должен легко читаться и восприниматься с минимумом усилий. Если код вызывает затруднения чтобы его понять, то вероятно его стоит упростить.

Принцип Открытости/закрытости (Open/Closed Principle)

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

Пишите код для сопровождающего (Write Code for the Maintainer)

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

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

Правило наименьшего удивления (Principle of least astonishment)

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

Принцип единственной ответственности (Single Responsibility Principle)

Компонент кода (т.е. класс или функция) должен выполнять единственную хорошо определённую задачу.

Слабая связанность (Minimize Coupling)

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

Максимальное сцепление (Maximize Cohesion)

Код который имеет похожую функциональность должен находится в том же компоненте.

Скрытие деталей реализации (Hide Implementation Details)

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

Закон Деметры (Law of Demeter)

Компоненты кода должны взаимодействовать только с их непосредственными отношениями (например, классы от которых они унаследованы, объекты которые они содержат, объекты переданные с помощью аргументов и т.д.)

Избегайте преждевременной оптимизации (Avoid Premature Optimization)

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

Мы должны забыть про небольшие улучшения эффективности, скажем на протяжении 97% времени: преждевременная оптимизация — это корень всех бед. © Дональд Кнут

От переводчика:

Преждевременная оптимизация хуже преждевременной эякуляции. © namezys

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

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

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

Также профайлеры позволяют выполнить анализ покрытия кода (Code Coverage) — процесс выявления неиспользуемых участков кода при помощи, например, многократного запуска программы.

Повторное использование это хорошо (Code Reuse is Good)

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

Разделение ответственности (Separation of Concerns, SoC)

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

Обними изменения (Embrace Change)

Это заголовок книги Кента Бека, в которой рассматривается принципы экстремального программирования (XP) и методологии гибкой разработки (Agile) в целом. Многие другие принципы основаны на концепции, что вы должны ожидать и приветствовать изменения. На самом деле очень старые принципы разработки, вроде минимизации связанности, непосредственно предназначаются для более лёгкого изменения кода. Даже если вы не приверженец экстремального программирования этот подход к написанию кода не теряет смысла.

От переводчика: и ещё один очень важный принцип не упомянутый автором

В объектно-ориентированом дизайне обязателен SOLID: аббревиатура из первых букв названий приниципов, часть которых уже описана в этой статье:

Single responsibility principle	Принцип единой разделения ответственности
Open/closed principle	Принцип открытости/закрытости
Liskov Substitution Principle	Принцип подстановки Лисков
Interface segregation principle	Принцип изоляции интерфейса
Dependency Inversion Principle	Принцип инверсии зависимостей

© Christopher Diggins

UPD
Посмотрите ещё на отличные мотиваторы с этими приницпами для программистов.

Компьютерный удар по коррупции

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

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

На самом деле такая система уже давным давно работала в программе ДАС для хоз. судов, и все остальные захотели себе такое же с небольшими дополнениями. Изначально проект этой системы разработали сами программисты. Выглядел он на пару страниц. После его передали его судьям, он прошёл очень много согласований и дополнений и вернулся обратно программистам в виде 40 страниц сноса мозга. И сразу же его вообще пропихнули как закон который вступил в силу с новогодним салютом 2011 года.

Алгоритм очень сложный, и если по старой памяти я постараюсь объяснить его кратце. Не претендую на точность и и полноту.

• Берутся все судьи которые работают в этом суде и не уволены.
• Отбрасываются те кто не имеет полномочий судить. Есть пятилетний и пожизненный периоды полномочий, т.е. судья может работать но не иметь полномочий судить пока не пришёл указ президента.
• Отбрасываются те судьи которые не слушают такую категорию дел. Например один судья специализируется на интеллектуальном праве а другой разводы и хулиганства по пьяни.
• Если есть связанные дела (например несколько краж за которые подозреваются один и тот же подсудимый) то сразу добавляются судьи из них.
• Отбрасываются те судьи которые взяли самоотвод или слушали это дело ранее в суде нижней инстанции.
• Отбрасываются те кто на больничном, командировке, отпуске, причём даже за пару недель до отпуска или увольнения чтобы они могли спокойно закончить дела.
• Судьи делятся по коллегиям (если они сконфигурированы) или по отделениям судов (бывает что один и тот же суд находится в разных помещениях далеко удалёнными друг от друга, и тогда судьям приходится между ними бегать).
• Коллегии в которых недостаточно судей отсекаются. Например нужно назначить коллегию из троих судей а в ней доступно только два, а остальные болеют.
• Генерируется случайное число и по нему выбирается коллегия.
• Для каждого судьи рассчитываются коэффициент нагрузки, например один судья слушает по 20 дел в день (типа штрафов за парковку) а другой по одному толстому делу в месяц. Учитывается коэффициент сложности категории дел, шарашатся и подсчитываются все дела судьи за предыдущий год, причём учитываются форма участия судьи в деле: например судья докладчик имеет большую нагрузку чем судья сидящий в коллегии и всё заседания проковырялся в носу а после просто подписавшим решение. Учитываются админ. должности судей: например глава суда может заниматься делами только процентов 40 своего времени а остальное время он занят организационными делами.
• В коллегии может быть например 10 судей а нужно выбрать троих, поэтому судья выбирается по случайному числу делённому на коэффициент загруженности чтобы получить справедливую вероятность нагрузки.

Есть ещё много моментов связанных с перераспределением/заменой судьи но и без того вам этого достаточно чтобы оценить какой это головняк всё это реализовать. При этом это выполняется не дольше 30 секунд, иначе крупные суды регистрирующие по 400 дел в день просто не смогут успевать проводить эти назначения.

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

Каждый этап и ветвление этого процесса очень подробно записывается в дополнении к протоколу. Все коэффициенты, все причины исключения судей! Это около трёх-десяти страниц подробного текстового лога на каждое назначение, половина которого понятна только программистам (чисто внутренние вещи программы). Все изменения настроек/коэффициентов журналируются. Все дела подписываются электронной подписью и отправляются в единый реестр доступ к которому у любого через сайт.

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

Короче, человеческого фактора действительно нет! И всё работает чётко, я за это несу уголовную ответственность.

Украинская судебная система самая коррумпированная в мире, с большими проблемами которые очень хорошо раскрыты в передаче «Свобода слова» (рекомендую к просмотру). И пока не будут решены проблемы с коррупцией в судах, то в других областях бороться с ними бесполезно. Тем не менее, я не уверен, но по-моему ни в одной стране мира (ага и в США) нет такой мощной системы учитывающей столько факторов. Это большая победа плоды которой проявятся со временем.

«Это не ошибка - это умысел!» — это не выводы а истерика, иначе, уж поверьте, этот закон вообще бы не принимался. Боритесь за свои права и соблюдайте свои обязанности!

Singleton не так прост

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

Так вот, этот шаблон наверное наиболее часто используется на практике и при чаще всего критикуется. Главным образом из-за того что он затрудняет юнит-тестирование и по сути является теми же глобальными переменными.

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

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

Так что они имеют точно такое же право на жизнь как например интерфейсы, которые частично можно заменить полностью абстрактными классами. Но это уже на правах холивара.

Если вы решили бороться с сиглтонами, то к вашим услугам в Idea есть специальная инспекция которая определяет синглтоны как проблемы. Также в Google написали инструмент Singleton Detector который находит синглетоны и помогает от них избавлятся.

Критику можно почитать на вики проекта и в энциклопедии хороших практик Cunningham & Cunningham.

Беглый осмотр матчасти

Я сделал небольшой Copy & Paste конспект из нагугленого матана, главным образом из этих статей:

• Сколько нужно потоков для обработки пользовательских запросов или крайности при использовании Singleton
• Double-checked locking and the Singleton pattern
• Знакомьтесь, антипаттерн double-checked locking

Пример 1. Простейший, идиоматический синглтон

public class Singleton  {
 private static final Singleton instance = new Singleton();
 
 // Private constructor prevents instantiation from other classes
 private Singleton() {
 }
 
 public static Singleton getInstance() {
  return instance ;
 }
}

Именно такой и генерируется в Idea.

Пример 2. С отложенной инициализацией

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

public class Singleton  {
 private static Singleton instance = null;
 
 // Private constructor prevents instantiation from other classes
 private Singleton() {
 }
 
 /**
  * Метод возвращает экземпляр SomeObject, при этом он
  * создаёт его, если тот ещё не существует
  */
 public static Singleton getInstance() {
  if (instance == null)
   instance = new Singleton();
  return instance;
 }
}

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

Пример 3. Потокобезопасный

Несколько потоков могут одновременно дёргнуть getInstance() и он создаст несколько экземпляров класса. Чтобы этого избежать создание экземпляра делают в блоке synchronized

public class Singleton  {
 private static Singleton instance = null;
 
 // Private constructor prevents instantiation from other classes
 private Singleton() {
 }
 
 /**
  * Метод возвращает экземпляр SomeObject, при этом он
  * создаёт его, если тот ещё не существует
  */
 public static synchronized Singleton getInstance() {
  if (instance == null)
   instance = new Singleton();
  return instance;
 }
}

Продолжение следует...

UPD Продолжения не следует, тему раскрыли на хабре здесь и здесь

[Перевод] Советы молодым программистам

Мой вольный перевод статьи Advice to young programmers.

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

Решайте свои проблемы сами

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

Сначала попрактикуйтесь на небольших программах

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

Создайте клон любимой программы

Взгляните на сайт вашей любимой игры и сделайте свою копию! Делайте это перед тем как начать работу над собственными идеями. Это будет толкать вас узнавать передовые технологии и вам будет проще трудоустроится. Сделайте примерно 3-5 таких проектов-копий, а потом уже не стесняйтесь реализовать что-нибудь на свою фантазию.

Узнавайте что-то новое на каждом проекте

На каждом проекте пытайтесь использовать что-то в новое, что вы никогда не делали раньше, но слышали. Никогда не использовали jQuery? Попробуйте в следующем проекте. Никогда не пробовали Test Driven Development? Поэкспериментируйте над вашим следующим проектом как на лабораторной мыши. Ну, вы поняли меня, да?

Говорите «Да»

Если кто-то попросит вас, можете ли вы сделать что-то для них, всегда соглашайтесь, даже если вы этого с этим дела не имели. Я знаю, вы конечно думаете, что заработаете миллионы на своих идеях, вот только опыт показывает, что лучше потратить большую часть вашего времени на проекты, за которые вам наверняка заплатят. И всё же оставляйте время на свои звёздные проекты. Сделайте это, и появится много рефералов которые будут знакомым рекомендовать вас ;)

Подружитесь с профессиональными разработчиками

Это еще один способ получить рефералов. Со временем ваш друг окажется загруженным, и он будет нуждаться в ком-то, кому можно передать часть работы. И тут появляетесь вы. Также вы тоже можете оказаться загруженными, и теперь сами будете искать, кому бы отгрузить работы.

Станьте экспертом в определённой области

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

От переводчика

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

Хочу заметить, что здесь тема до конца не раскрыта, пункты без дополнений спорны и многого не хватает. Поэтому также обязательно полистайте интернет. У меня есть желание переработать остальной материал в сети и составить своё напутствие, предварительно обсудив его с гуру программирования. Удачи.

Интересные задачки из экзамена Oracle Certified Professional Java Programmer

На Хабре пару месяцев назад было две статьи (первая и вторая часть) с интересными задачками из экзамена по сертификации Oracle Certified Professional Java Programmer (бывший Sun Certified).

Если кому интересно, то я набил эти примеры и выложил их в репозиторий на GitHub.

Удачной сертификации.

Возможности Java: статический импорт

Эта статья была размещена на сайте sun.ru, но позже она стала недоступной. Я её вытащил из кеша поисковика и сохранил на всякий случай здесь.

Аккуратное и правильное использование import static улучшит читаемость вашего кода.

Статический импорт

Для того чтобы получить доступ к статическим членам классов, требуются указать ссылку на класс. К примеру, необходимо указать имя класса Math:

   double r = Math.cos(Math.PI * theta);

Чтобы обойти это, иногда добавляют статические методы в интерфейс и наследуются от этого интерфейса. Это плохая идея. Фактически это настолько плохая идея, что для нее есть свое название: Constant Interface Antipattern (см. Effective Java, 17 статья). Дело в том, что использование статических членов класса другим классом всего лишь деталь реализации. Когда же класс реализует интерфейс, его члены становится частью публичного АРI этого класса. Детали реализации не должны становиться публичным программным интерфейсом.

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

  import static java.lang.Math.PI;

или все целиком:

  import static java.lang.Math.*;

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

   double r = cos(PI * theta);

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

Так когда же следует использовать статический импорт? Только в некоторых случаях! Используйте его только, если иначе вы вынуждены объявлять локальные копии констант или при неправильном использовании наследования (Constant Interface Antipattern).

Другими словами, использование его оправданно, когда требуется постоянное использование статических членов одного класса из одного или двух других классов.

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

Перевод Комарова Е., Дмитриев А., 24.12.2007 г.