Не могу пройти мимо призыва Джейка Вартона – “Скажи mNo венгерской нотации!“.
Во-первых (и это мое личное мнение), использовать такую нотацию в исходниках на Java действительно нелепо.
Во-вторых, когда-то давно я grep-ом проходил исходники андроида (кажется 16-ый API Level) и там нотация не соблюдалась. Более того она была некорректной (статические поля с m-префиксом).
Вартон молодец, что наконец-то поднял эту тему.
Коворкинг интересен тем, что в нем можно встретить интересных людей.
Следующая история произошла после краткой беседы с Димой Гарником, арт-директором небольшой дизайн-студии.
У Димы была идея создать простой сайт для автовизиток. Идея несложная, но интересная. Вы заходите на сайт, указываете номер телефона и сообщение (например: “Мешает машина? Звони!“). Затем вы получаете развертку, из которой можно собрать симпатичную машинку. Развертка – это PDF-файл, который можно распечатать на листе бумаги формата А4 и собрать. Самое главное: сборка идет как “оригами”, т.е. без ножниц и клея, нужны только “прямые” руки и время.
В итоге получается такая штука:
Собственно, нужно было как-то реализовать генерацию этих разверток.
Так совпало, что Дима подошел и рассказал про свою идею именно в тот момент, когда мы с соседом пили кофе и вели досужие разговоры на тему: “что бы такого сделать интересного и не сложного”. Димина идея показалась интересной и не очень трудоемкой.
Генерацией PDF-файлов мне уже приходилось заниматься в прошлом (хотя это и была, в основном, генерация документов и отчетов с использованием различных выборок из БД – принципиальной разницы я не видел).
В общем, я сделал эту штуку.
Приблизительный план, что и как нужно делать, в целом, был понятен сразу:
1. Берем рисунок в векторе.
2. Сохраняем его в SVG-формате.
3. Поскольку SVG – это обычный XML, то менять в нем содержимое (номер, сообщение, цвет и т.д.) несложно.
4. Прикручиваем преобразователь SVG → PDF.
5. Проверяем, что все это работает, и делаем к этому “обвес”, который обрабатывает HTTP запросы и отдает пользователю PDF-файл.
6. Прикручиваем дизайн или интегрируем с текущим сайтом.
В целом, все прошло согласно плану. За исключением следующих моментов:
1. Проблемы со шрифтами.
Конечно, все зависит от SVG-файла, но, возможно, возникнут сложности с кириллическими шрифтами после развертывания на сервере (т.е. на Linux-е).
Решение: поставить недостающие (зависит от того, какие нужны) шрифты.
Например, как-то так:
apt-get install ttf-mscorefonts-installer
2. Еще раз проблемы со шрифтами.
У того, кто раньше работал с Apache FOP, могут возникнуть сложности в более тонкой настройке конфигурации.
Дело в том, что формат файла для настройки PDFTranscoder-а отличается от привычного fop.xconf!
Если кратко:
//Создает перекодировщик. Кроме PDF, если верить документации есть перевод в PostScript, EPS.
Transcoder transcoder = new PDFTranscoder();
// Если нужно "вшивать" свои шрифты, требуется дополнительная настройка
try {
DefaultConfigurationBuilder cfgBuilder = new DefaultConfigurationBuilder();
Configuration cfg = cfgBuilder.buildFromFile(new File("pdf-renderer-cfg.xml"));
ContainerUtil.configure(transcoder, cfg);
} catch (Exception e) {
throw new TranscoderException(e);
}
Где “pdf-renderer-cfg.xml”:
Весь пример можно скачать с сайта Apache FOP.
Сейчас это кажется очевидным. Но тогда, чтобы понять, как избавиться от крякозябр в картинках, пришлось потратить почти столько же времени, сколько на всю оставшуюся разработку.
На этом технические детали хотелось бы оставить в стороне и написать пару слов про дизайн и его значение.
Есть такая замечательная статья Learning to see (Учимся видеть)
В ней приводится следующая диаграмма:
Как правило, чем более “программистская” контора, тем сильнее доминирует принцип – делаем “not pretty but functional“, а затем дизайн (если остались деньги).
Все бы хорошо, но бывают заказчики, которым потом жалко тратить деньги на нормальный дизайн: им главное, чтобы работало. Как правило, это касается разработки внутренних систем. В целом, это нормальная бизнес-ситуация: лишних денег на “красивости” часто нет. Правда в том, что в итоге сотрудникам некоторых компаний приходится годами пользоваться унылым корпоративным ПО.
Если приводить аналогию, то в таком случае, сайт для создания автовизитки без дизайна выглядел бы примерно так:
Для сравнения, вот так он выглядит сейчас:
С другой стороны, если поставить дизайн во главу угла, может получиться ситуация, когда дизайн есть, а функциональности нет.
Красиво выглядит? Да, бесспорно! Работает? К сожалению, нет. При этом могут пройти месяцы, пока из красивого получится работающее. Ситуация может усугубиться, если дизайнер “понапридумывает” разного, а это потом не будет работать или окажется невозможным реализовать.
Многие скажут: “К чему эти банальности? Это и так понятно!”. Понятно, но хотел бы повторить: нормальный дизайн – это не опция, это неотъемлемая часть хорошего программного продукта. Такая же составляющая, как и его функциональность.
PS: Может кто-то знает нормальные курсы дизайна по UI/UX? Не про “сферического коня в вакууме”, а про конкретные практики – как пользоваться инструментами. И не про общие принципы: что нужно выравнивать, что какие-то цвета плохо сочетаются и т.д., – про это многое уже известно.
Проблема в том, что иногда по мелочи нужно что-то сделать (например, у меня бывают вопросы, как в фотошопе кнопку перекрасить из серого в красный) и это вызывает определенные сложности. Спасибо соседям по коворкингу, что выручают (Николай, Надежда – это я про вас ;).
В общем, если кто-то из программистов, читающих мой блог, бывал на таких курсах – был бы рад услышать про них отзыв: стоит или нет.
PPS: Если, вдруг, какой-то дизайнер забредет на мой программистский блог – буду рад возможности сотрудничества. Пишите в комментариях ;).
Проекты бывают разные. Некоторые можно сделать за два дня, некоторые за месяц, некоторые длятся годами. Именно про последние хотел написать эту заметку.
Дело в том, что общаясь в среде различных программистов с завидной периодичность наблюдаю следующую сцену. Один разработчик рассказывает и показывает итоги своей работы другим программистам в надежде получить отзыв вроде: “Ну ты крууууут!“, в ответ же он получает не возгласы восхищения и аплодисменты, а вопрос: “На что именно было потрачено столько времени? На ЭТО? Что тут такого делать, почему так долго?“. После этой фразы начинаются жаркие споры, обиды, непонимание и обвинения в некомпетентности друг друга.
Хорошо когда такие беседы проходят в дружеской программисткой атмосфере. Гораздо сложнее, когда выяснение отношений происходит на другом уровне. Например, когда одна команда пытается подрезать заказ у другой, убеждая клиента в том, что если бы обратились к ним, то они дескать сделали бы все гораздо быстрее и без затягивания сроков. Что принятые решения изначально были нерациональными и т.д.
Более того, сами программисты спустя годы, оборачиваясь назад начинают думать: “Я потратил на это три/пять/семь лет своей жизни? Почему?! Как ЭТО заняло столько времени?”
Одной из причин, на мой взгляд, является не совсем точное представление о том, как оценивается сложность проекта. Для многих это прямая из точки А в точку B.
Пред глазами предстает следующая картинка.
На самом деле, это идеальная картина. В жизни разработка сложного проекта сопровождается решением многих неучтенных проблем. Возникают “развилки” на которых нужно принимать решение куда двигаться дальше. Это могут быть решения высокого уровня, такие как выбор языка (java, c#, python или всё вместе) или способ хранения данных (mysql, oracle, berkley db, mongodb, hazelcast или все вместе), так и более низкого уровня – какой веб-фреймворк выбрать (ext или gwt, или может быть JSF 2 и т.д.), прикрутить velocity или обойтись стандартными средствами для работы со строками, начать использовать более популярный graddle или остаться на maven-е (или даже ant-e), использовать AnglularJS или не стоит.
Таких “точек бифуркации” в большом проекте может быть несколько десятков или даже сотен. При этом важно понимать, что все могут ошибаться и иногда приходится возвращаться на исходную позицию, менять стратегию, платформу (или как говорят программисты “переписать половину кода”). Кроме этого цель из точки B может передвинуться в точку B’ и в результате некоторые принятые решения уже могут оказаться неподходящими.
Другими словами лучше описывает ситуацию следующая картина.
В итоге, полученное “дерево решений” получается довольно ветвистым, а его “построение” делается методом “разведки боем” и занимает уйму времени. При этом, когда человек уже находится в конечной точке B и если он не страдает потерей памяти, то скорее всего повторить этот путь ему будет намного проще. Он уже знает как добраться к цели, по каким именно дорогам идти и на каком перекрестке свернуть.
Конечно более сложный случай, когда нет хороших проторенных “дорог”. Например, если это принципиально новая разработка. В таком случаях утверждение “Что он тут такого делает уже N-цатый год?“, звучит аналогично претензии к Колумбу: “Что тут такого? Здесь и ежу понятно, что нужно просто плыть на запад и попадешь в Америку“. Сегодня это кажется очевидным, а тогда найти средства на подобную авантюру было не так уж и просто. Опять-таки в итоге Колумб все-таки ошибся где-то в три с половиной раза (почти на Пи), ведь изначально он хотел попасть в Индию, а она намного дальше…
Возвращаясь в наши дни, к теме этой заметки, хотел подвести небольшое резюме.
P.S. В качестве иллюстрации нарисовал дерево, на развилках которого выбирается один вариант и подсвечивается красным цветом. При нажатии мышкой на дерево, оно случайным образом перестраивается.
Приятного просмотра!
P.P.S. Дерево прорисовывается с помощью языка программирования processing. Собственно экспериментами с ним, а также arduino и raspberry pi сейчас посвящены воркшопы, которые мы проводим вместо проводимых ранее Scala-тусовок.
Отправка простых HTTP запросов из Java уже хорошо описана в различных источниках, например в официальном туториале, поэтому пересказывать в очередной раз как работать с URL и выкладывать примеры кода не вижу смысла. В случае если приходится работать с защищенным HTTPS соединением, также особых осложнений у большинства программистов возникнуть не должно (возможно кроме случаев с самозаверенными сертификатами, но на эту тему также очень много учебного материала в интернете). Несколько больший интерес представляют собой случай, когда HTTPS подключение требует дополнительной авторизации по клиентскому сертификату. Вот об этом и пойдет речь в этой статье.
Для многих пользователей такой способ авторизации выглядит немного экзотичным, т.к. встречается он не часто, хотя работает “из коробки” в большинстве браузеров и поддерживается многими веб-серверами.
Более распространен такой способ авторизации не в клиент-серверных решениях, а скорее в межсерверном взаимодействии. Например при решения задач в сфере B2B, когда необходимо отправлять запросы к различным серверам контрагентов и внешним системам. Отчасти это связанно с тем, что одним из популярных способов создания таких коммуникаций является использование веб-служб, что в свою очередь означает программную отправку HTTP запросов. Поскольку внутренняя реализации JAX-WS, базируется на использовании стандартных классов (URL, HttpURLConnection и т.д.), решив задачу в общем виде (отправка https запросов с авторизацией по сертификату) автоматически решается задача для клиента веб-службы (речь идет о JAX-WS, в Axis2 задачу решать можно немного другим способом).
Самое простое что можно сделать для решения этой задачи — указать ключи и пароли в системных свойствах:
-Djavax.net.ssl.keyStore=privateKey.jks -Djavax.net.ssl.keyStorePassword=myPrivateKeyPassword -Djavax.net.ssl.trustStore=truststore.jks -Djavax.net.ssl.trustStorePassword=myTrustStorePassword
В данном случае в файл privateKey.jks вы можете положить свой приватный (закрытый) ключ, с помощью которого будет проходить аутентификация на сервере и (при необходимости) в файл truststore.jks положить сертификат сервера, к которому идет обращение.
Хранилище ключей может иметь тип не только JKS (Java Key Store), но например быть в более распространенном формате PKCS12. В таком случае в настройках следует указать тип хранилища:
-Djavax.net.ssl.keyStoreType=pkcs12 -Djavax.net.ssl.keyStore=privateKey.p12 -Djavax.net.ssl.keyStorePassword=myPrivateKeyPassword
Очень хорошо описаны отличия в использовании JKS и PKCS12 в статье Java 2-way TLS/SSL (Client Certificates) and PKCS12 vs JKS KeyStores.
В итоге, если все правильно и аккуратно настроить, то взаимодействие с сервером будет происходить автоматически и программисту не нужно будет вносить серьезных изменений в исходный код.
Теперь рассмотрим более сложный случай в котором необходимо программно регулировать работу с ключами. Например, когда у вас в файле (или на смарт-карте) находится несколько ключей и нужно явно как-то их дополнительно анализировать, указывать какой ключ использовать.
Общая последовательность шагов будет выглядеть следующим образом.
1. Получить хранилище ключей.
2. Создать объект класса менеджера ключей.
3. Создать объект управляющий доверенными сертификатами.
4. Произвести инициализацию ssl-контекста.
Теперь нужно разобраться, кто это такой “менеджер ключей” и “управляющий доверенными сертификатами”, а также с кем еще возможно придется столкнуться. Для этого приведу сильно упрощенную диаграмму классов:
Из диаграммы легко видеть как можно управлять поведением работы программы. Например, чтобы поменять логику выбора алиаса, можно сделать наследника класса менеджера ключей (KeyManager).
Для этого вначале нужно получить хранилище ключей (KeyStore), а дальше сделав своего наследника, который будет работать с ключами, передать его в метод для инициализации SSL контекста. Самый простой способ сделать такого наследника — получить менеджера ключей по-умолчанию, а затем обернуть его методы таким образом, чтобы основные методы “проксировались” и в то же время можно было перекрыть нужный метод со специфической логикой (выбор алиас, отслеживание какой ключ/принципал используется и тд).
Если не стоит такой задачи как подмена стандартной логики работы менеджера ключей, а просто необходимо программно управлять работой с хранилищем, то соответственно можно и не делать никаких наследников и не портить логику работы по-умолчанию.
Далее привожу очень простой пример, естественно это “вырожденный” случай иллюстрирующий общую схему работы.
Код приводится в ознакомительных целях и использовать его “как есть” крайне не рекомендуется.
/**
*
* @author Vit vit@programmisty.com
*/
public class Demo {
public static void main(String[] args) throws Exception {
SSLContext sc = SSLContext.getInstance("SSL");
// Каким-то образом получили хранилище ключей. Это за рамками статьи.
KeyStore keystore = ... ;
String algorithm = KeyManagerFactory.getDefaultAlgorithm();
KeyManagerFactory keyManagerFactory = KeyManagerFactory.getInstance(algorithm);
// не забываем инициализировать менеджера ключей
keyManagerFactory.init(keystore, password);
// получаем список менеджером (при необходимости делаем наследника и/или оборачиваем keyManager)
KeyManager[] keyManagers = keyManagerFactory.getKeyManagers();
// если у нас свой список доверенных серверов
TrustManager[] trustManagers = getTrustManagers("/trusted.jks", "trustedPassword".toCharArray());
sc.init(keyManagers, trustManagers, null);
// проставляем контекст
SSLContext.setDefault(sc);
// для проверки отправляем запрос
String url = "https://my-secure-server.com";
try (InputStream in = new URL(url).openStream()){
System.out.println(IOUtils.toString(in));
}
}
/**
* если у нас какой-то свой файлик с доверенными сертификатами
*/
private static TrustManager[] getTrustManagers(String path, char[] passwd) throws Exception {
String algorithm = TrustManagerFactory.getDefaultAlgorithm();
TrustManagerFactory trustManagerFactory = TrustManagerFactory.getInstance(algorithm);
// Загружаем доверенных
KeyStore keystore = KeyStore.getInstance(KeyStore.getDefaultType());
// Из ресурсов, так проще.
InputStream keystoreStream = Demo.class.getResourceAsStream(path);
keystore.load(keystoreStream, passwd);
trustManagerFactory.init(keystore);
//
TrustManager[] trustManagers = trustManagerFactory.getTrustManagers();
return trustManagers;
}
}
Одно время у меня были некоторые сомнения имеет ли смысл публиковать эту статью, т.к. в целом мне нечего сказать такого, что нельзя было найти в официальной документации об invokeAll. Затем, при общении с другими программистами, стал время от времени замечать не совсем правильное (на мой взгляд) понимание его работы. Поэтому пока есть свободное время решил все-таки закончить эту заметку.
Сразу хочу заметить, что мне не очень хочется углубляться в описание всей мощи java concurrent API, а просто расставить некоторые акценты при работе над небольшой простой задачей. Она может возникнуть в жизни каждого программиста, он замечает некоторые независимые операции и у него появляется нестерпимое желание их распределить по нескольким потокам. Грубо говоря, у вас есть какой-то метод, который можно было бы безболезненно запихнуть в Runnable-ы, стартануть и подождать когда все закончат свою работу.
Понятно, что для этого может подойти invokeAll т.к. в описании про него явно сказано: “Executes the given tasks, returning a list of Futures holding their status and results when all complete.”
Так вот, некоторые программисты не дочитывают последние слова и думают, что нужно самому контролировать процесс, ждать и “жать на тормоз”, проверять все ли потоки завершились, периодически дергать в цикле future.get(), join-ить или делать другие различные телодвижения. Конечно так поступают не все, но тем не менее такое бывает. Для того, чтобы разобраться в том, что происходит на самом деле, достаточно взглянуть в базовую реализацию этого метода (AbstractExecutorService.java). Надо же пользоваться тем, что src.zip в JDK все еще продолжают подкладывать: (далее…)
Исходной предпосылкой было как-то упростить процесс разработки/отладки. В некоторых ситуациях, например когда запуск-перезапуск приложения или теста занимает продолжительное время, очень удобно пользоваться возможностью подправить логику работы уже запущенной программы.
В поисках решения наткнулся на довольно занятное решение – Dynamic Code Evolution VM. Данная виртуальная машина является результатом работ проведенных в рамках исследовательского проекта Институтом системного программного обеспечения им. Иоганна Кеплера в г. Линце (Австрия).
Если грубо описать полученный результат – это специальная “пропатченная” Java VM, которая позволяет на лету править классы в работающей машине. Главная плюшка – если обычно при дебаге вы можете “на горячую” менять содержимое метода, то в DCE VM можно еще и добавлять/удалять методы и поля в классе.
К сожалению с установкой DCE VM у меня не заладилось с самого начала. Инсталлятор не сработал, в итоге пришлось просидеть полночи в попытках заполучить эту чудную VM. К решению этой задачи пробовал подступиться с разных сторон. Пытался собрать исходники. Собирать пришлось из под cygwin-а (в очередной раз пожалел, что сейчас у меня рабочая операционка не Linux). Потом возникли сложности с установкой “Microsoft SDKs Windows v7.1”, который почему-то не хотел устанавливаться. В итоге, правдам и неправдами, перед самым рассветом, перерыв кучу ссылок в интернете различными кривыми путями мне удалось стать счастливым обладателям этой машинки. Конечно сейчас, оглядываясь назад, у меня создается впечатление, что на самом деле я сделал кучу лишних шагов и про установку DCE VM информации более чем достаточно, главное внимательно читать инструкцию.
После того как всё настроил Hot Swap заработал сразу на:
Схема работы простая. Запускаем под дебагом → Делаем изменения → Жмем Apply Changes.
Если речь идёт о более экзотических случаях, например разработка Rich приложений на Netbeans Platform – то горячая замена у меня не заработала. Чуть позже у меня появилась гипотеза, что возможно это связано с тем, что у Netbeans Platform свой ClassLoader. Возможно гипотеза неверна и дело в настройках, думаю в свободное время посмотреть более внимательно исходники проекта и утилит, которые идут вместе с ним. (далее…)
Около месяца назад мне попался на глаза шедевральный пост, в котором приводится гениальное по простоте, остроумное и изящное математическое доказательство теории: “при оценки сроков и объема работы над проектом желательно умножать исходную оценку на Пи”. Оригинальный труд находится по следующей ссылке: http://www.altdevblogaday.com/2013/11/15/always-multiply-estimates-by-pi/. В этой статье хотел изложить краткий пересказ доказательства.
Допустим у вас есть какой-то исходный план действий.
Обозначим его вектором направленным из точки A в предполагаемую точку B0.
Времена меняются. Цель из точки B0 отодвигается под фактором различных обстоятельств в точку B.
Естественно не бывает так, что всё идет гладко, возникают трудности, которые приводят к отклонению от прямой. В итоге путь, по которому вы прибываете к цели является кривой.
(далее…)
За последнее время прошло несколько важных событий, о которых давно хотел написать.
Про одну новость я уже просто не имею права писать с ещё большей задержкой и опозданием…
Итак, во-первых, самое главное событие о котором я узнал в сентябре — команда российских программистов получила Duke Award 2013 в Сан-Франциско!
Ребята занимаются разработкой симулятора для Java Card Runtime Environment (jCardSim), пишут обфускатор и ПО для защиты Андроид приложений от реверса, а также ведут различные, по-настоящему сложные, Java-разработки. Другими словами занимаются не какими-то поделками вроде корпоративного веб-софта, клепание порталов и другими типовыми B2B/E-Commerce/Banking/Enterprise проектами, а работают над фундаментальными разработками и действительно непростыми вещами, в отличие от многих-многих Java программистов Москвы.
Друзья, еще раз мои поздравления!
Во-вторых, мы пытаемся возобновить наши встречи программистов или как сейчас модно говорить MeetUp-ы. Конечно сейчас уже будет не Scala, основы языка мы разобрали давным давно, у некоторых из нас использование Scala стало вполне будничным и хочется чего-то нового. Следующие встречи предполагаем посвятить процессингу, Arduino, малинке (raspberry pi). Всей нашей небольшой группе захотелось двинуться в сторону железок и интерактив арт. Думаю как всегда половина времени уйдет на общение с железками/компьютерами, а половина на распитие кофе и общение на общие темы.
Место встречи — на территории дизайн-завода Флакон или в кофейнях (как старые добрые времена).
В связи с этим еще одна небольшая новость. Сейчас обитаю в коворкинге StartHub-а, я о нем еще не рассказывал, он находится также во Флаконе, но немного в глубине территории, напротив летнего бассейна. Он расположен не так далеко от предыдущего коворкинга, в котором я арендовал себе рабочее место в прошлом году.
Для любопытствующих выкладываю фото комнаты где я сижу и ссылку на сам коворкинг. 
Наконец последняя новость. Мы недавно с друзьями решили вместе сделать Halloween Widget для Android. Как всегда всё в последний момент, но мне кажется получилось намного круче чем я ожидал.
По сути это тот же робот, только сильно доработанный. Из функциональных вещей добавился фонарик (Бека – спасибо, за пример кода!). Включается нажатием на центральную кнопку. Поскольку фонарик по-сути использует вспышку от встроенной фотокамеры, то для работы потребуется разрешение для работы с камерой: android.permission.CAMERA.
Огромный респект нашему дизайнеру Грише за проделанную работу и Тане, за львиную доли работы по переделке-улучшению UI/UX!
Выкладываю пару картинок, сам виджет можно скачать с маркета и при желании по тестировать.
Так получилось, что я знаком со многими программистами, которые работают в крупных (и не очень) софтверных компаниях в качестве наемных сотрудников, т.е. на окладе. На сегодняшний день Москве можно наблюдать два явления:
1. Дефицит квалифицированных кадров.
2. Кризис самореализации. Много ИТ специалистов в прошлом учились в лучших высших учебных заведениях России, но текущая их работы не в полной мере позволяет им реализовать свой потенциал. Одни мирятся с таким положением дел, у других возникает желание “изменить судьбу”, открыть свое дело, начать стартап, освободиться от “офисного рабства”.
Как следствие они начинают карьеру молодого предпринимателя, пытаясь начать самостоятельные проекты, искать заказы на разработку ПО. При этом у многих сохраняются наивные представления о том, как продавать свои услуги, на каких условиях работать с клиентом и самый главный вопрос возникающий у начинающего московского программиста-предприниматели – сколько стоят его услуги по созданию программного обеспечения. Для многих технически подкованных специалистов моего возраста в школьные годы не составляла особого труда решить примера вида:
Пример из сборника задач Сканави М.И. для поступающих ВТУЗы. В прошлом, те кто хотел поступить в ВУЗ могли решить такой пример не особо себя утруждаю, как мы шутили «спинным мозгом». Наверное сейчас с появлением ЕГЭ эпоха задач из Сканави уходит в прошлое.
С другой стороны, когда нужно сделать не намного более сложные арифметические и алгебраические операции, но вместо конкретных чисел будут стоять налоги, накладные расходы, человеко-часы, риски, объемы, сроки, скидки и другие составляющие, то это вызывает панику. Человек с высшим техническим образованием может потратить несколько дней или даже недель, чтобы найти грубые ошибок в своих вычислениях.
Другими словами, если речь идёт о готовом математическом выражении — всё просто, но если это якобы “бизнес” ситуация и нужно ответить на вопрос “за 100 000 сделаешь программу?” или “сколько будет стоит сделать мобильное приложение?”, то начинается тупёж. Например постоянно сталкиваюсь с людьми, которые путаются с процентами и не могут посчитать какую цену они должны указать заказчику, чтобы у них осталось 100 000 рублей после оплаты налога в 6% с дохода?
Казалось бы ответ очевиден – приблизительно 106 383 рубля, но даже в таком простом примере многие делают ошибки (считают 106 000) или вообще не учитывают налог в конечной стоимости («да ладно, пусть, чего мелочится, всего 6%»). Когда же нужно проделать более «сложные» вычисления, т.е. учесть в цене все затраты (часы на согласование проекта, тестирование, внедрение, отчисления в фонды, обслуживание счета в банке, расходы на аренду, обрудывание и другие расходы), то в итоге некоторые делают множество существенных арифметических, алгебраических и алгоритмических ошибок. Хотя на самом деле, здесь нет ничего сложного.
Допустим существует некий абстрактный московский java-программист. Его зарплата 120 000 в месяц. Он решил, что начинает работать на себя. Какую стоимость человеко-часа выставлять заказчику? Берем зарплату и делим на среднее количество рабочих часов в месяц (допустим 164,17 часов). Получаем стоимость часа около 731 рубля.
Давайте приведем аналогию из сферы услуг. Я знаю фитнес-центр в котором годовой абонемент стоит 16 000 рублей. Это недорого для Москвы (даже скажем средний, бюджетный вариант). Фитнес открыт ежедневно, работает по 12 часов в день. Разделим 16 000 на количество часов в году (365 дней * 12 часов = 4 380 часов) и получим стоимость часа равную 3 рубля 65 копеек. Посчитав это, я решаю пойти и позаниматься 2 часа, т.к. по моим расчетам должен заплатить 7 руб 30 копеек. Вопрос, почему администрации фитнес-центра требует с меня за разовое посещение 500 руб?! Что за наглость?
2 * (16 000 / (365 * 12)) = 7.30 != 500
Устраиваясь на работу, программист предоставляет свои услуги работодателю не на один месяц, а как правило по бессрочному договору, т.е. работать будет годами (хотя на обычно специалист меняет работодателя через 2-5 лет). Вы как бы “продаете” годовой абонемент своему работодателю — будут для вас задачи или нет, это уже не ваши проблемы. Фитнес-центр же не виноват, что кому-то лень тащить свое тело в зал и кто-то не приходит заниматься уже вторую неделю. Так и здесь, работодатель сам должен обеспечить вам фронт работы, а вы качественно программировать и получать каждый месяц зарплату. Если задач нет, то можно плевать в потолок или гонять танки, вашей вины в простое нет.
Другими словами, если вам предлагают проект на условиях: 2 миллиона рублей на 12 человеко-месяцев, деньги поступают каждый месяц, заказчик покупает вам необходимую для работы компьютерную технику, оплачивает интернет и аренду рабочего места, то можно говорить о том, что стоимость часа равна 731 рублей. Если это подработка на 60-100 часов, то о каких 731 рублей за час может идти речь? Вас же за 7 рублей в фитнес-клуб никто не пустит, хотя стоимость часа рассчитана по схожему принципу. Думаю для любого торговца на улице очевидна причина в разнице цены за килограмм картошки между покупкой ее вагонами и трех килограммов в розницу, но почему-то у программистов-предпринимателей работает “линейное” мышление в расчете цены.
Есть такой бородатый анекдот:
Новый русский открыл фотосалон и дал объявление: “Приглашаю фотомодель для съемки. Оплата наличкой на месте. За час работы 20 тысяч баксов”.
Набежала куча моделей, отобрали одну, снимали с вечера и до ночи.
Приходит новый русский:
– Ну что, фотограф, сколько наснимал?
– Четыреста кадров.
– А выдержку ставил какую?
– 1/200 секунды.
– Ну ты, девка, в натуре, на две секунды всего лишь наработала, держи 12 баксов.
К чему я вспомнил этот старый анекдот из прошедшей эпохи? (далее…)
Этим летом ко мне обратился старый знакомый, который хотел начать разработку нового веб-проекта. Он хотел пообщаться/посоветоваться на тему современных инструментов (фреймворков) для разработки веб-приложений. Дело в том, что у него скорее планировалась не разработка нового, а переделка старого проекта, сделанного на JSP и сервлетах, базовая архитектура которого ваялась еще в начале 2000-ных. В прошлом я немного участвовал в жизни этого программного продукта (доработки по Hibernate, прикручивал apache fop и т.д.), поэтому был немного в курсе внутренних особенностей системы.
В целом это было добротное веб-приложение на Spring-e и оракловой СУБД. Думаю многие из нас в былые времена делали подобные вещи. С тех пор многое поменялось, одни инструменты сильно развились, появились абсолютно новые, а некоторые безнадежно устарели и канули в Лету. В итоге мы решили встретиться, пообщаться, попить кофе и обсудить, кто с чем столкнулся на профессиональном поприще за последние несколько лет, а также поделиться впечатлениями об использовании тех или иных инструментов.
На мой взгляд к 2013 году человечество создало такое огромное количество библиотек, утилит, платформ и других полезных и бесполезных вещей для создания веб-приложения, что разобраться в них становится все сложнее и сложнее. Суть проблемы заключается в том, что обилие различных модных слов создают кашу в голове программистов.
Чтобы хоть в чем-то упростить себе (и другим программистам) жизнь, я решил после нашей беседы написать этот небольшой обзор различных веб инструментов (в контексте Java и JavaScript). Возможно многие вещи покажутся слишком простыми и очевидными, рассчитанные на совсем юных программистов, тем не менее думаю ошибочно считать, что “каша” возникает только у новичка. Наоборот, умудренные опытом программисты, опираясь на сформировавшиеся у себя в мозгу концепции, проецируют свои старые понятия на новые фреймворки, в итоге сложнее впитывают суть, смысл и назначение новых.
Ведь на самом деле, многие инструменты качественно отличаются друг от друга и сравнивать их порой не представляется возможным. 
В английском языке существует выражение “сравнивать яблоки и апельсины“, в русском языке ближайшим аналогом этого высказывания “путать теплое с мягким“. Сравнивать разные по сути вещи. Например, все равно что сравнивать JSF и jQuery.
Поэтому, чтобы внести ясность, я решил раскидать “яблоки к яблокам, а апельсины к апельсинам”. В итоге получился следующий текст.
(далее…)