Показаны сообщения с ярлыком Начинающим программистам. Показать все сообщения
Показаны сообщения с ярлыком Начинающим программистам. Показать все сообщения

среда, 21 ноября 2012 г.

#kranonit S04 Встреча клуба анонимных айтишников посвящённая защите ПО



Друзья, после долгого перерыва мы приглашаем вас долгожданную конференцию по новым компьютерным технологиям… и защите компьютерных программ!

Итак, в субботу 1го декабря в 12:00 в конференц зале 139 Нархоза: ул. Семашко, 16, ст. м. Кольцевая.
На встрече будет два доклада:

Тема: Защита от Master Boot Record Locker
Докладчик: Антон, занимается системным кодингом, безопасностью ОС, играет на электрогитаре.
О чём рассказ:
Многие наверное видели картинку при загрузке Windows, мол "отправьте SMS чтобы разблокировать".
Обычно борются с этой бедой перестановкой Windows.
Так вот, в последнее время злостные хакеры научились блокировать систему ещё в MBR загрузчике, и простая переустановка тут уже не спасёт.
Как работают такие локеры и как с ними бороться расскажет Антон.
Необходимы базовые знания ассемблера и Си, понятиями как регистры процессора, адресация, режимы работы процессора.

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

Ведущим встречи будет Эдуард Лобас если потеряетесь звоните ему 0675257582

После докладов мы продолжим общение в более неформально обстановке на АП.

Также заранее анонсируем что в декабре у нас пройдут ещё две встречи:
Уже через неделю, 8го декабря Сергей Бурма, опытный программист на Python,
сделает нам два разказа:
1. Про облачные сервисы Google App Engine, OpenShift
2. Проведёт мастер класс по работе с системой контроля версий Git (из новичков мало кто этим пользуется, а зря)

22 декабря мы закроем осенний сезон #kranonit большим докладом про высоконагруженные системы (high load) о которых нам расскажет Игорь Цинько (combats) и Серёжа Пономарёв (stokito).

Подробнее анонсы о них будут после 1го декабря.

Будем рады снова видеть вас!

UPD
Материалы встречи

вторник, 25 сентября 2012 г.

Вторая встреча Клуба Анонимных Айтишников

О клубе

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

Мы уже провели первую встречу и вы можете посмотреть полный отчёт со всеми презентациями и видео.

Вторая встреча Клуба Анонимных Айтишников в Кривом Роге которая состоится в эту субботу 29го сентября в 10:00 в конференц зале 139 Нархоза: ул. Семашко, 16, ст. м. Кольцевая (см. карту).

О чём пойдёт речь на встрече

Какой программист не писал свою игру? :) Кто-то, как я, писал арканоид, а кто тетрис, или крестики-нолики. А хотели бы вы создать полноценную анимированную 3D игру? А ведь её можно ещё выложить в интернет и даже заработать на ней при должном везении и упорстве.
Сейчас индустрия онлайн и мобильных игр переживает бум. Все знают Весёлую Ферму, Angry Birds и множество других игр которые стали классикой и повеселили миллионы людей.

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

Нам любезно согласились рассказать про них двое кудесников игр: Стас Чирва и Дмитрий Свириденко. Оба они родом из Кривого Рога а сейчас работают в киевской компании True Token. Мы услышим от них два доклада, после чего Сергей Пономарёв расскажет про хорошие книжки-наставники для программистов, да и не только.

Программа

9:45 Регистрация. Просьба не опаздывать.

10:00 Открытие клуба

10:10 Доклад «HTML5: Поздравляю, ты в новой реальности»

Докладчик: Дмитрий Свириденко JavaScript разработчик в True Token.
Длительность: 40 минут.
Дмитрий расскажет о том что это за зверь такой HTML5, какие его перспективы, технические особенности и проведёт демо игр разработанных с его помощью.

11:00 Доклад «Unity3D: Разработка казуальных и социальных игр»

Докладчик: Стас Чирва - JavaScript и Unity3D разработчик в True Token.
Длительность: 1 час 20 мин
Стас расскажет основы Unity3D и покажет его возможности на живом мастер классе.

12:30 Доклад «Хоррррошие книжки!»

Докладчик: Сергей Пономарёв - Java и Grails разработчик в Gramant
Длительность: 25 минут
Сергей расскажет о хороших книжках которые у которых КПД больше 100% и они помогут вам быстрей стать профессионалом.

Приходите, будет интересно!

По всем вопросам обращайтесь:

Сергей stokito@gmail.com +38(096) 978-29-75.
Эдуард Лобас yakikhaddaffi@gmail.com +38(067) 525-75-82

И не прячетесь, вступайте в группы:
Группа Вконтакте и встреча
Группа в LinkedIn и встреча
Группа в Facebook
Twitter хештег #kranonit

До встречи на клубе!
Серёжа Пономарёв, Игорь Цинько и Эдурд Лобас.

воскресенье, 23 сентября 2012 г.

Почему я советую знакомым студентам учить Java?

Недавно снова наткнулся на вопрос «почему Java а не что то другое?». Я уже отвечал на форуме, теперь достал и оформил в виде статьи с акцентом почему я советую знакомым студентом учить Java.
Я не очень опытный специалист и здесь будет много субъективного мнения, и конечно же тема очень обширная и холиварная, но я хочу собрать все свои мысли в одном месте.
Вкратце суть статьи:
Учить нужно то, за что платят (т.е во что вкладывают) деньги, а больше платят за Java. Там и инновации, и широкий спектр решений и технологий.
Java нацелена на разработку больших проектов, поэтому её любят большие корпорации.
А платят за Java больше чем например за C#, в который тоже вбухивают деньги, потому что стоимость разработки и сопровождения ниже: много бесплатных инструментов, библиотек обкатанных временем, средства разработки и она кроссплатформенная и можно использовать бесплатный Linux, обратно совместимая, предсказуемая и надёжная.

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

Начнём с анализа текущих дел


Сейчас массовый софт работает в трёх основных областях:
  • Desktop приложения (офисы, АРМы, студии, системы документоборота, антивирусы), т.е. требующие установки на компьютер.
  • Web приложения сюда мы отнесём все сайты и онлайн сервисы (wikipedia, gmail). Многих она притягивает потому что не требуется установка ПО и данные остаются доступными в сети.
  • Мобильные приложения
  • Игры, особенно мобильные и броузерные для социальных сетей.
  • Embeded - встроенные системы (драйверы, контроллеры)

Примерно прикинем популярность по трендам индексатора американских сайтов работы indeed.com:


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


Embeded я убрал из-за странного дёрганого тренда.

А теперь график по языкам:

Тут несколько нюансов:
  • Для большего драматизма я добавил любимый но мертвый Delphi.
  • Также по Си из-за однобуквенного названия график выходит неоправданно завышенным, я использовал C Developer, тренд хоть кажется адекватным.
  • Objective-c подозрительно маленький тренд, чаще пишут iOS developer.
  • JavaScript (не путать с Java!) раньше имел ограниченное применение для небольших клиентских сценариев в броузере, но сейчас стал активно использоваться для создания игр и даже для серверного программирования.

Основные области применения Java это большие web приложения, банковские desktop приложения и мобильная разработка для Android. Т.е. она сразу попадает в три популярные категории.

Ну и собственно зарплаты по данным опроса DOU.ua
75 перцентиль midle разработчиков в Киеве. Справа шкала количества анкет.


Причины такой позиции Java

  • Строгая, статическая типизация что значительно уменьшает число ошибок и улучшает сопровождаемость кода, особенно если ещё использовать статический анализатор. При этом в яве есть ограниченные возможности динамического программирования через магию рефлексии и аннотаций. Но тем не менее есть её диалект Groovy который динамический и почти полностью совместим с ней на уровне синтаксиса. На нём кстати есть отличный Rails подобный фреймворк.
  • Java на рынке с 1995 года, обкатана и существуют сотни решений и технологий.
  • Что немаловажно является по сути упрощённым C++ который учили все в институтах и поэтому переход на неё проходит менее болезненно.
  • Язык прост, предсказуем, и минималистичен. Новые фичи вводятся очень осторожно, иногда даже черезчур долго (например замыкания).
  • Синтаксис Java является чем то вроде linva franca поэтому авторы книг часто выбирают её для примеров кода.
  • Мощные IDE, в частности Idea вообще вершина эволюции средств разработки и стоит в разы дешевле чем Visual Studio Ultimate для C# (700$ против 13300$).
  • Даже если кто и быдлокодит, это будет относительно легко разгрести через средства рефакторинга в IDE.
  • Кроссплатформенность, работает буквально на всём: от суперкомпьютеров до смарткарт и что особенно приятно на бесплатном Linux и FreeBSD.
  • Существуют около 350 гигабайт библиотек доступных в репозитории Maven. Для всего всего всего. И они в большинстве своём открытые, да.
  • В следствии очень дешёвая разработка.
  • Очень много программистов. Java самый популярный язык. Есть официальная сертификация программистов OSCJP.
  • Открытая стандартизация JSR, спецификации Java EE.
  • Компилируется в байт код, а не требует полной интерпретации как например Ruby и Python, что ускоряет работу. А благодаря оптимизирующему JIT компилятору может приближаться по скорости к нативному коду.
  • И последняя но далеко не последняя по важности: Полная обратная совместимость по API и ABI ещё с самых первых версий. Седьмая Java это всего лишь минорная версия, т.е. 1.7. Ни один другой язык не может похвастаться такой обратной совместимостью, даже C#.

Вывод

Остальные платформы и языки тоже хороши и востребованы и некоторые из них сейчас переживают бум. На их фоне Java выделяется самой сильной позицией и неплохими, пускай не самыми большими зарплатами. Но поскольку Java используется в корпоративном секторе и все проекты на ней большие то практически полностью отсутствует возможность фриланса на ней. Например количество вакансий на самой популярной фриланс бирже oDesk по запросу Spring (самый популярный веб фреймворк для Java) совсем не впечатляет.
Поэтому многим из тех кто хочет начать карьеру программиста но живут в городах где не устроится программистом прийдётся подаваться на фриланс и педалить на гнусном PHP.

«Есть всего два типа языков программирования: те, на которые люди всё время ругаются, и те, которые никто не использует.»
(c) Бьёрн Страуструп, автор C++

И Ява тоже далека от идеала. Кстати комментарий из этой статьи:
>> Ведь основная цель java была в облегчении жизни нам — простым разработчикам.
Это вас кто-то обманул. Главное преимущество джавы — надежность и предсказуемость. Ценой многократных, по сравнению с другими языками, усилий разработчиков.

Но это не самое важное, а главное «Вы должны писать на языке, который делает вас счастливее» (Пэт Аллан).


P.S. Наткнулся на очень толковое обсуждение где очень толковые специалисты высказали своё ведение проблемы.

воскресенье, 16 сентября 2012 г.

Отчёт о первой встрече Клуба анонимных айтишников

Спасибо всем за тепло проведённое время!

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

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

Было два доклада и небольшая но интересная презентация компании iLogos. Кстати меня удивил уровень зарплат которые они предлагают - он вполне приличный даже по киевским меркам. По крайней мере в киевском Samsung RD за аналогичную работу моему знакомому платили меньше. Но он правда из-за этого от них у ушёл...

Презентации:




Жалко что с видео получилась накладка, осталось только пару обрезков по 20 минут, но тем кто не был думаю можно будет представить атмосферу.







Игорь рассказывает как найти работу


Презентация iLogos



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


Также 22 сентября состоится отличный вебинар (онлайн семинар) «Поиск и найм IT профессионалов» который крайне рекомендуем к посещению.

Следующий клуб проведём через две недели 29 сентября.
Пожалуйста зарегистрируйтесь и вы получите заранее оповещение на почту. Если вы уже регистрировались на первую встречу, то регистрироваться не нужно.
Ждите рассылки!

Ещё раз всем спасибо,
До новых встреч!

вторник, 19 июня 2012 г.

[Перевод] Способы сравнения объектов дат в Java

Аннотация от переводчика

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

Итак, давайте обрисуем проблему — сравнение объектов Date в Java известный источник ошибок.
Это появляется в стандартном коде, но также бывает и в тестирующем коде, где нам регулярно нужно создавать объекты Date которые отмечают определенный момент времени на который потом будем ссылаться в сравнении.

Старый добрый устаревший и не рекомендуемый путь

В тестирующем коде я не переживал что использую устаревшие (deprecated) методы. Поэтому я использовал старый конструктор Date чтобы инициализировать даты, после чего я сравнивал их с другим объектами дат через метод сравнения equals():

Date date = new Date(112, 5, 3);
Date userCreatedDate = user.getCreatedDate();
if (userCreatedDate.equals(date)) { // Если даты равны…
  // делаем что нибудь…
}
Преимущества: это лаконично. Недостатки: это весьма не очевидно и вам нужны хорошие знания Java API чтобы знать что первый параметр это год минус 1900 и второй это индекс месяца который начинается с ноля для Января. И это сюрприз когда вы узнаёте что последний параметр это просто… просто день месяца.

Канонический способ

Начиная с Java 1.1 в Java API был добавлен класс Calendar чтобы разделить момент во времени (т.е. дату) от её представления в специфическом справочнике (календарь). Следующий фрагмент кода (snippet) это способ получения такого же результата как выше.

Calendar calendar = Calendar.getInstance();
calendar.set(YEAR, 2012);
calendar.set(MONTH, JUNE);
calendar.set(DAY_OF_MONTH, 3);

Это не только более многословно, тут также есть ошибка: часы, минут и остальное не равно нолю (берётся от момента непосредственного создания календаря), поэтому сравнение через equals() будет возвращать false. Вот правильный код:
Calendar calendar = Calendar.getInstance();
calendar.set(YEAR, 2012);
calendar.set(MONTH, JUNE);
calendar.set(DAY_OF_MONTH, 3);
calendar.set(HOUR_OF_DAY, 0);
calendar.set(MINUTE, 0);
calendar.set(SECOND, 0);
calendar.set(MILLISECOND, 0);

По меньшей мере это ухудшает краткость ;-)

Apache Commons Lang

Apache Commons изначально предоставляет различные утилитные библиотеки которые облегчают разработку в Java. Одна из таких библиотек Apache Commons Lang которая предоставляет функционал который заслуживает быть частью Java API. В нашем случае класс DateUtils позволит нам сократить код сохранив при этом его читаемость:

Calendar calendar = Calendar.getInstance();
calendar.set(YEAR, 2012);
calendar.set(MONTH, JUNE);
calendar.set(DAY_OF_MONTH, 3);
calendar = DateUtils.truncate(calendar, DAY_OF_MONTH); 

Даже лучше, DateUtils позволяет нам работать непосредственно с объектами Date в таком альтернативном виде:
Date date = new Date();
date = DateUtils.setYears(date, 2012);
date = DateUtils.setMonths(date, JUNE);
date = DateUtils.setDays(date, 3);
date = DateUtils.truncate(date, DAY_OF_MONTH);

Обратите внимание что он оставляет параметры нетронутыми, достигая неизменяемости (immutability) по принципа функционального программирования.
Преимущества: мы используем стандартное Java API.
Недостатки: да никаких. И ещё, не будет ли полностью своеобразный DSL казаться чем-то более подходящим?


Joda Time

Последний вариант это использование библиотеки Joda Time, которая нацелена стать заменой для Date и Calendar. Она также породила JSR-310 — новый и улучшенный API для манипуляции с датой и временем, который должен стать частью Java 8 (он был изначально запланирован для Java 7). Joda Time стоит посвятить отдельную статью (или даже мини-руководство). Для наших текущих нужд следующий фрагмент кода может выгодно заменить наш изначальный:
DateMidnight dm = new DateMidnight(2012, 6, 3);

Если сравнивать с первым примером, такой код кажется чище и лаконичней. И ещё, параметры самоописывающие, нет реальной нужды регулярно проверять JavaDocs чтобы узнать как инициализируется год. Кроме того, семантика имён классов ясна. И наконец, метод toDate() даёт нам мост к стандартному Java API.

Заключение

Вывод делайте сами. Лично я обычно использую Apache Commons Lang, но в последнее время склоняюсь к Joda Time. Архив с примерами кода доступен для скачивания тут в виде Maven проекта под Eclipse.

Автор: Nicolas Fränkel
Оригинал Ways of comparing Date Objects in Java.

пятница, 13 апреля 2012 г.

Свойства ПО

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Точность

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Понятность

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

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

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

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

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

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

Юзабилити

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

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

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

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

воскресенье, 18 марта 2012 г.

[Перевод] Как писать сопроводительное письмо

Перевод статьи How to Write a Cover Letter.

Примечание переводчика: Сопроводительное письмо (англ. Cover Letter) — это письмо которым вы сопровождаете ваше резюме работодателю когда хотите устроится на конкретную позицию. В нём вы пишите, мол «я тут нашёл вашу вакансию на таком то сайте, я кое что умею из описанного в ней, я долго ждал такой возможности, возьмите меня пожалуйста на работу, в приложении к письму моё резюме и связаться со мной можно по этому телефону». Например вот таким было моё сопроводительное письмо год назад когда я пытался поменять специализацию. А вот ещё один пример сопроводительного письма фрилансера.

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

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

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

Так как же его писать?

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

Начните с приятного и профессионально приветствия.

Этот человек будет принимать решение нанимая вас - поэтому ваше начало знакомства должно убедить его думать о вас как о том с кем бы он хотел работать. «Уважаемый Евгений Николаевич», «Здравствуйте, Евгений,» будет уместным. А вот «Привет Женя,» «Как житуха, Жека?» или любая несерьёзность должна быть заменена на что нибудь более формальное. Не знаете имени человека который занимается наймом? «Уважаемый менеджер по персоналу», (“Dear Hiring Manager,”) это отличный способ задать профессиональный тон с самого начала.

Переходите к делу.

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

Меня заинтересовала ваша позиция ведущего блогера который вы недавно опубликовали. Я была профессиональным писателем на протяжении девяти лет, и я хорошо знакома с WordPress’ом и Typepad’ом. На протяжении трёх лет, как главный редактор BeingInterested, я управляла командой писателей которые публиковали по пять записей в блог за неделю. Вы можете познакомится с некоторыми моими работами в поём портфолио по адресу www.odesk.com/users/…

Подчеркните главное.

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

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

Следуйте указаниям.

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

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

Закрывайте продажу.

Убедитесь что вы дали им понять вашу способность занять позицию и пригласили их связаться с вами для обсуждения в будущем. Это вежливый способ «попросить работу» и закрепить ваш энтузиазм для работы с этим нанимателем:

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

Перечитайте, отредактируйте и продумайте.

Прежде чем нажать «Отправить», взгляните ещё раз на описание вакансии. Вы не упустили всех критериев в вашем сопроводительном письме? Если бы вы были человеком нанимающим на эту позицию, прошло бы это сопроводительное письмо? Поддержит ли ваш профиль и портфолио ваше принятие на эту работу? (Если нет, то не стоит! Приберегите вашу энергию для позиции которая лучше соответствует вашим навыкам и возможностям.) Если вы не уверены, попросите вашего друга просмотреть объявление вакансии и ваше сопроводительное письмо, и выслушайте внимательно его мнение, он может обнаружить подводные камни которые сыграют роль в вашем устройстве на работу.

Сопроводительные письма являются первым впечатлением для работодателя или клиента, поэтому убедитесь что вы приложили необходимые усилия. Найти больше советов по мастерству удачного сопроводительного письма вы можете найти в предыдущей статье Написание «убийственного» сопроводительного письма (ориг. Writing a Killer Cover Letter), содержащее короткий список способов добиться чтобы ваше письмо стало по настоящему «убийственным».

О авторе:

Эрика Бентон (Erica Benton) возглавляет команду блога в oDesk, и видела достаточно сопроводительных писем чтобы определить «убийственное» (“killer”) когда она его встретит. Эрика получила опыт как владелец небольшого бизнеса и фрилансера вплоть до того как она стала менджером по маркетинговым связям в oDesk.

воскресенье, 5 февраля 2012 г.

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

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

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

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

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

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

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

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

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

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

© Roy Bahat

среда, 1 февраля 2012 г.

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

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

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

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



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

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

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

Обновление

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


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

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

Обновление 2

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

вторник, 31 января 2012 г.

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

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

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

воскресенье, 11 сентября 2011 г.

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

Не самый лучший дизайн

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

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


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
Посмотрите ещё на отличные мотиваторы с этими приницпами для программистов.

пятница, 12 августа 2011 г.

Singleton не так прост

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

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

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

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

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

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

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

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

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

Пример 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 Продолжения не следует, тему раскрыли на хабре здесь и здесь

пятница, 29 июля 2011 г.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

среда, 6 апреля 2011 г.

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

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

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

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

вторник, 5 апреля 2011 г.

Возможности 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 г.

Константы, перечисления (enum), и static import'ы в Java

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

Константа — это, грубо говоря, переменная значение которой не меняется во время работы программы. Классический пример константы — число Пи (3,14...). Константы используются для борьбы с Магическими числами, т.е. непонятно что означающими числами или строками.

В Java нет специальной директивы для объявления констант как например const в Pascal/Delphi или в C/C++. Т.е. не выйдет написать такое:

const double PI = 3.14;

Но в замен есть более гибкий модификатор final:

final double PI = 3.14;
В этом примере была объявлена финальная переменная с названием PI и ей было сразу же задано значение 3.14. Финальным переменным значения можно задать только один раз и больше его нельзя менять. Любую попытку поменять значение финальной переменной (или поля) компилятор будет воспринимать как ошибку, т.е. всё так же как и с константами.

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

final String someFinalVariable; // Объявляем финальную переменную, но мы её не проинициализировали значением!
System.out.println(someFinalVariable); // Ошибка компиляции: значение не задано. javac: variable not have been initialized
someFinalVariable = "Some value"; // Наконец задаём значение
System.out.println(someFinalVariable); // Выводим содержимое переменной
someFinalVariable = "New value"; // Ошибка компиляции: значение переменной уже задано. javac: variable someFinalVariable already have been assigned
Такая отложенная инициализация например часто используется для создания неизменяемых объектов (англ. Immutable objects).

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

public static final double PI = 3.14;
Статическое поле (модификатор static) принадлежит классу и для доступа к нему не нужно создавать конкретный экземпляр объекта:
public class Math {
    public static final double PI = 3.14;
}

public class Test {
    public static void main(String[] args) {
        double d = 3 * Math.PI; // Мы не создавали объект класса Math а обратились к полю самого класса!
        System.out.println(d);
    }
}

Обратите внимание что в Яве, как и во всех Си подобных языках, принято имена констант писать БОЛЬШИМИ_БУКВАМИ_РАЗДЕЛЯЯ_ИХ_ПОДЧЁРКИВАНИЕМ.

Здесь стоит ещё отметить что такая константа может быть не просто числом, а полноценным выражением, в котором тоже можно обращаться к другим статическим полям или вызывать статические методы:

static final double SECONDS_IN_DAY = 60 * 60 * 24; // Сколько секунд в дне
При этом всё вычисляется на этапе компиляции и не нужно заменять 60 * 60 * 24 на менее читаемое и очевидное уже вычисленное вами 86400 (к тому же возможно неправильно рассчитанное).

Группирование констант через перечисления

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

public class Modifier {
    public static final int PUBLIC = 1;
    public static final int PROTECTED = 2;
    public static final int PRIVATE = 3;
    public static final int ABSTRACT = 4;
    public static final int STATIC = 5;
    public static final int FINAL = 6;
    public static final int TRANSIENT = 7;
    public static final int VOLATILE = 8;
    public static final int SYNCHRONIZED = 9;
    public static final int NATIVE = 10;
    public static final int STRICTFP = 11;
}

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

  • Небезопасность типа (type unsafe): в методе, где требуется передать значение перечисления, можно передать любое число, а не только значения от 1 до 11;
  • Неинформативность: например, при отладке значение 3 не скажет нам ни о чем. А хотелось бы увидеть PRIVATE;
  • Подверженность ошибкам: например, при добавлении нового элемента или при изменении последовательности существующих. Например можно не уследить, и у PUBLIC и PROTECTED поставить одинаковое значение 1. Т.е. отсутствует контроль со стороны компилятора как за уникальностью значений констант, так и за возможностью случайного присваивания переменным значений, не соответствующих ни одной из этих констант.

Такие сгруппированные константы называются перечислениями и в Java для них есть специальная конструкция enum. Перепишем этот класс как перечисление:

enum Modifier {
    PUBLIC,
    PROTECTED,
    PRIVATE,
    ABSTRACT,
    STATIC,
    FINAL,
    TRANSIENT,
    VOLATILE,
    SYNCHRONIZED,
    NATIVE,
    STRICTFP;
}
И использовать его можно как обычную константу:
Modifier variableModifier = Modifier.PUBLIC;

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

    // Так не делайте!
    if (modifier.eqals(Modifier.PUBLIC)) {
        // ....
    }
    // Просто сравнивайте по ссылке ;)
    if (modifier == Modifier.PUBLIC) {
        // ....
    }


Вообще тут нужно отметить что раньше, до пятой версии Java перечислений не было, вместо них приходилось использовать классы со статическими константами. Это я говорю к тому, что многие классы с которыми вы столкнётесь остались написанными «дедовским» способом. Причём в стандартных классах их не меняли, например java.awt.Color.

Технически перечисления представляют собой полноценный класс который наследуется от java.lang.Enum, т.е. запись public enum Modifier равноценна abstract class Modifier extends java.lang.Enum.

А если это класс, значит в него можно добавлять произвольное количество полей и методов:

enum Modifier {
    PUBLIC,
    PROTECTED,
    PRIVATE,
    ABSTRACT,
    STATIC,
    FINAL,
    TRANSIENT,
    VOLATILE,
    SYNCHRONIZED,
    NATIVE,
    STRICTFP;

    /**
     * Возвращает это имя модификатора в нижнем регистре.
     */
    @Override
    public String toString() {
        String lowercase = name().toLowerCase(java.util.Locale.US); 
        return lowercase;
    }
}

public class Test {
    public static void main(String[] args) throws Exception {
        Modifier variableModifier = Modifier.PUBLIC;
        System.out.println(variableModifier);
    }
}

При запуске этого примера в вывод будет напечатано public а не 1! У каждого enum'а хранится поле name с его именем (в нашем случае "PUBLIC"). Мы переопределили (@Override) метод toString() внутри которого приводим имя к нижнему регистру.

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

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

Использование статических импортов

Перечисления естественно подходят не для всех случаев. Например константа натурального логарифма e и константу π нельзя объединять в перечисление. Давайте посмотрим на класс содержащий эту константы:

public class Math {
    public static final double E = 2.71;
    public static final double PI = 3.14;
}

Все его поля public static final. Чтобы каждый раз не писать эти модификаторы многие программисты объявляют константы в интерфейсе, потому что все его поля итак уже public static final:

interface Math {
    double E = 2.71;
    double PI = 3.14;
}

И вот кому то стрельнула идея: «А зачем каждый раз писать полное имя интерфейса с константами, если можно его заимплементить и получить к ним доступ напрямую?». И такие конструкции

public class Test {
    public static void main(String[] args) {
        double d = 3 * Math.PI; 
        System.out.println(d);
    }
}
превратились в такой кошмар
public class Test implements Math {
    public static void main(String[] args) {
        double d = 3 * PI; // Math. можно уже не писать 
        System.out.println(d);
    }
}

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

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

import static Math.PI;
или все целиком:
import static Math.*;

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

double d = 3 * PI; // Math. можно не писать 

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

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

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

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

Как правильно объявить константный класс?

Если всё таки очень надо, то объявляйте константный класс как обычный класс, а не интерфейс. Только делайте его ещё и финальным (final), чтобы от него нельзя было унаследоваться. А ещё было бы неплохо сделать его абстрактным (abstract), чтобы нельзя было создать его экземпляр, ведь все коснтанты у нас статические и мы обращаемся к полям класса а не объекта.

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

public final class Math {
    public static final double E = 2.71;
    public static final double PI = 3.14;
    private Math() {
    }
}

Заключение

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