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

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

В жизни каждого разработчика наступает такой момент, когда ему нужно сделать форму. Вроде бы чего тут сложного — бери, бросай. А нет, форма то, она как живая. У неё есть своё настроение, свои привычки. Выбрал пол — “Ж”, она преобразилась, стала чуть другой, любопытной, спрашивает замужем ли, любимые духи, обувь с каблуком, или без? Но ты же мужик! И тут выбираешь пол “М”, и, как бы, вопросы должны быть другие — холост, любимый сорт пива, любимый спорт. Конечно, можно понаделать кучу формочек для каждого чиха, если “М”, то одна, если “Ж”, то другая. Но такой метод обернется катастрофой на этапе поддержки, да и вообще не в духе красивого кода. Поэтому форма должна быть умной. Очень умной. Она должна знать кто её трогает, чего он хочет, его потаённые желания. Например: есть форма ввода адреса в пять полей

• страна
• область
• город
• улица
• метро

Выбираю я город, и почему бы форме не додумать область и страну? Или выбрал Владимирскую область, зачем мне в списке городов “Москва”? Поле “метро” для Владимирской области тоже не актуально, а когда выбран город Струнино, так вообще издевательство. Занимаясь разработкой клиентской части в корпоративных WEB приложениях вот уже 5 лет я таки познал, как сделать форму умной. Надеюсь, мой опыт будет полезен и вам.

UPD: Продолжение статьи с примером техзадания

Не так давно на хабре были две статьи (Согласно техническому заданию и А зачем мне ТЗ? Я и так знаю!) посвященные техническим заданиям. У меня обе статьи вызвали, мягко говоря, недоумение, в особенности статья «Согласно техническому заданию». На мой взгляд, это вообще вредная статья, которая приводит к неверному понимаю сути ТЗ. В связи с этим хочу выразить свой взгляд на этот вопрос. Не буду говорить обо всех тех. заданиях, слишком широка тема, но думаю смогу рассказать о ТЗ на сайт.

То описание технического задания, о котором речь пойдет ниже, не является пересказом ГОСТа, но скорее является его творческой переработкой, хорошо сдобренной горьким опытом. Описанный ниже подход к ТЗ не охватывает все аспекты сайтостроения, но задает общее направление.

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

1. Обоснование необходимости ТЗ

А зачем вообще нужно ТЗ на сайт? Заказчик говорит: «Нужен следующий сайт: каталог товаров, корзина, форма заказа, доставка, мы на карте, о нас, обратная связь». Что не ясно? Ничего необычного, всё обыденно и рутинно.

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

Попробовал весьма интересный стартап сервис по приему платежей пластиковыми картами stripe, основанный в Сан-Франциско.



Судя по их блогу, открылись они совсем недавно, если верить информации в интернете, в декабре 2011 года. Примечательно, что среди инвесторов данного сервиса три наиболее влиятельных венчурных фонда силиконовой долины (Sequoia Capital, Y Combinator и Andreessen Horowitz), а также Peter Thiel и Elon Musk, которые являются основателями PayPal. Такая компания инвесторов сразу привлекает внимание к проекту.

Для начала, позвольте уточнить, что я являюсь большим любителем и сторонником Scala вот уже 5 лет. Мною были написаны книги и статьи о Scala. Также я работал со множеством компаний, начавших использование Scala и Lift и проводил code review огромного количества Scala — проектов. Раньше я думал, что Scala — это просто. Она была и продолжает быть лекарством от многих проблем Java. С точки зрения “сложные или вообще невыполнимые вещи в Java довольно просты в Scala”, Scala — довольно простой язык. Работа с коллекциями очень проста. Изоляция бизнес-логики делает программы гораздо более поддерживаемыми и невероятно простыми, чем если бы они писались на Java.
Так почему же Scala сложна? Вот лучшее, что я смог придумать:

Итак, приступим пожалуй. Я люблю Scala не только за то, что она позволяет писать в два раза меньше кода, чем на Java. Понятного и выразительного кода. Помимо этого на Scala можно делать вещи вообще недоступные разработчикам на Java: generic’и высшего порядка, узнавать типы generic’ов в runtime при помощи манифестов.

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

Священный спор

Принято считать, что есть «вечные» вопросы, на которые нет правильного ответа. Например, что лучше: Windows или Linux, Java или C#; Чужой против Хищника или Чак Норрис против Ван Дамма.

Одним из таких холиваров считается выбор лучшей IDE для Java:


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

Так вот, я утверждаю, что это не просто дело вкуса. Есть объективные причины, почему

Intellij IDEA однозначно лучше, чем Eclipse.

Подчёркиваю, мы сейчас рассматриваем обе среды именно как Java IDE.

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

Как вы разрабатываете веб-приложение на Java?
После каждого изменения, как вы его запускаете и проверяете? Сколько времени занимает редеплой приложения и рестарт контейнера?

Мне довелось видеть разные варианты: от полной пересборки WAR-файла до использования плагинов для IDE типа MyEclipse, WTP и «коннекторов» для сервлет-контерйнеров. У некоторых из них есть явные недостатки, другие вполне работают — но есть способ проще!

Запускалка

Этот способ разработки позволяет максимально просто и гибко настроить приложение с минимальным временем редеплоя. Вам надо всего лишь написать один простенький Java-класс с main-методом, который запустит сервер Jetty сразу с нужными приложениями (т.н. Embedded Mode).

Хочу поделиться недавним опытом разработки апплетов на Swing и рассказать про подводные камни, приемы найденные и использованные в процессе работы.

Представляю вашему вниманию перевод статьи под названием "Redesigning The Country Selector" от Christian Holst. Перевели в компании UXDepot специально для пользователей Хабрахабра с одобрением издания Smashing Magazine.

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



Однажды, проводя масштабные юзабилити-тестирования (о которых мы писали на Smashing Magazine в апреле 2011. Примечание переводчиков: мы перевели и эту статью тоже. Обязательно ознакомьтесь :), мы последовательно столкнулись с несколькими проблемами, связанными с выбором страны. Якоб Нильсен сообщал о похожих моментах в 2000 и 2007 годах, когда он тестировал выпадающие списки с большим количеством внутренних элементов, к примеру, таких, как перечни штатов или стран.

Прослушав вебинар «How Google Tests Software» я был так вдохновлен, что решил записать некоторые тезисы. Эта статья и есть мой конспект. Прежде всего, я должен внести ясность относительно ее содержания. Это не дословный перевод. Здесь описаны только те вещи, которые показались мне важными. Проще говоря, здесь описано не все, что прозвучало в вебинаре. Так же существует вероятность, что я понял что-то не до конца или даже понял неправильно. Поэтому горячо рекомендую прослушать вебинар самостоятельно.
Его ведет Джэймс Витакер, который в данный момент занимает пост технического директора по тестированию ПО в Google. Джэймс совместно с коллегами готовится выпустить одноименную книгу. В ней можно будет получить исчерпывающую информацию о том, как проводят тестирование GoogleMaps, Google+, ChromeOS, Android и т.д…

Среди преподавателей сложилось мнение, что Ruby — наиболее подходящий язык для изучения программирования. Первый в жизни ЯП должен быть максимально простым в использовании и, разумеется, объектно-ориентированным. В нём не должно быть каких-то двусмысленных концепций или странных особенностей синтаксиса. В общем, Ruby подходит идеально, решили ребята из компании The Hybrid Group и выпустили приложение KidsRuby (код на github) — уроки Ruby для детей.

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

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

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

Большинство провальных проектов обладают одной закономерностью. Они абсолютно лишены структуры. Я называю архитектуру таких систем «пластилиновой».

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

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

Теперь давайте посмотрим, как поступит в этом случае типичный джуниор. Есть задача – её надо решить. Их так учили в университетах. Многие из них ещё находятся под влиянием маргинального лозунга «пиши код, б##дь!». Итак, он наливает себе растворимого кофе, надевает наушники с чем-нибудь пожёстче и погромче и уходит в поток на пару-тройку часов.

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

Согласно поговорке, программисты — это устройства, преобразующие кофеин в код.

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

Цель всего этого — избавиться от отвлекающих факторов. Но можно было бы просто закрыть дверь… Что же такого особенного в ночи?

Я думаю, что всё сводится к трём вещам: расписанию творца, сонному мозгу, и яркому экрану компьютера.

Некоторое время назад я гуглил интернет по поводу “REST vs SOAP”, прочитал пару статей и вроде бы все понял, но не почувствовал от этого никакого удовлетворения. Что-то было не так, то ли я не почувствовал основную идею, то ли просто читал, одновременно слушая новый музон и думая о новой фиче в проекте. Как появилось время, решил восполнить этот пробел, заодно написав полезную статью по этому поводу.

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

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

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

Многие знают о ”культе карго” — удивительном явлении, имевшим место во время Второй мировой войны. В ходе боевых действий удаленные острова в Тихом океане вдруг стали стратегическим объектом, американцы построили на них военную базу, и местные туземцы были осчастливлены продуктами цивилизации, которые доставляли грузовые самолеты. Туземцы решили, что хитрый белый человек, который сам не производит никаких материальных ценностей, получает их напрямую от богов, выполняя загадочные ритуалы: марширует с палками по плацу, сидит возле ящика с антенной и молится на непонятном языке, призывая небесных птиц. Когда война окончилась, американцы оставили острова и их наивных обитателей. Когда же позднее на остров вернулись исследователи, они с удивлением обнаружили туземцев с нарисованными нашивками, марширующих по плацу и шаманов, призывающих ”карго” в деревянных наушниках перед муляжом радиостанции.

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

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

В этом небольшом посте я постараюсь рассказать с чего начать разрабатывать приложения для Android на языке Scala с помощью SBT и IntelliJ Idea, а так же плюсы и минусы этого подхода. Все будет довольно просто, стоит только запастись терпением. Весь процесс описывается для unix like систем, на Windows не проверялось, но если очень хочется, то можно попробовать провернуть то же самое через cygwin. Итак…

Существующие решения

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

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

Инструменты

• ItelliJ Idea community edition с поддержкой Android — самая дружественная к Scala IDE на сегодняшний день (есть еще ensime, но это из другой оперы).
• JDK 6 для linux/mac os. Путь до JDK необходимо прописать в глобальной переменной JAVA_HOME (можно в ~/.bashrc).
• Android SDK для linux/mac os. Путь до SDK должен быть также задан через глобальную переменную ANDROID_SDK_HOME, но, внимание, для видимости всей системой, поэтому прописывать переменную нужно строго в /etc/environment. Может потребоваться перезагрузка.
• Simple Build Tool (SBT) 0.10.1 — инструмент для генерации и сборки Scala проектов. Недавно проект сменил имя на XSBT и переехал на github, что весьма удобно.
• Android плагин для SBT — для ознакомления, потому как данный плагин ставится автоматически.
• giter8 (g8) — утилита для генерации проектов из шаблонов, опубликованных на github.
• Мой шаблон g8 для генерации Idea проектов.
• Настроенный Android Emulator или напрямую подключенный андроид смартфон с включенной USB отладкой.