Рубрики
0. Мироощущение и бытие

Оборачиваясь назад.

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

Дело в том, что общаясь в среде различных программистов с завидной периодичность наблюдаю следующую сцену. Один разработчик рассказывает и показывает итоги своей работы другим программистам в надежде получить отзыв вроде: "Ну ты крууууут!", в ответ же он получает не возгласы восхищения и аплодисменты, а вопрос: "На что именно было потрачено столько времени? На ЭТО? Что тут такого делать, почему так долго?". После этой фразы начинаются жаркие споры, обиды, непонимание и обвинения в некомпетентности друг друга.

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

Более того, сами программисты спустя годы, оборачиваясь назад начинают думать: "Я потратил на это три/пять/семь лет своей жизни? Почему?! Как ЭТО заняло столько времени?"

Одной из причин, на мой взгляд, является не совсем точное представление о том, как оценивается сложность проекта. Для многих это прямая из точки А в точку B.
Пред глазами предстает следующая картинка.
ab

На самом деле, это идеальная картина. В жизни разработка сложного проекта сопровождается решением многих неучтенных проблем. Возникают "развилки" на которых нужно принимать решение куда двигаться дальше. Это могут быть решения высокого уровня, такие как выбор языка (java, c#, python или всё вместе) или способ хранения данных (mysql, oracle, berkley db, mongodb, hazelcast или все вместе), так и более низкого уровня - какой веб-фреймворк выбрать (ext или gwt, или может быть JSF 2 и т.д.), прикрутить velocity или обойтись стандартными средствами для работы со строками, начать использовать более популярный graddle или остаться на maven-е (или даже ant-e), использовать AnglularJS или не стоит.

Таких "точек бифуркации"  в большом проекте может быть несколько десятков или даже сотен. При этом важно понимать, что все могут ошибаться и иногда приходится возвращаться на исходную позицию, менять стратегию, платформу (или как говорят программисты "переписать половину кода"). Кроме этого цель из точки B может передвинуться в точку B' и в результате некоторые принятые решения уже могут оказаться неподходящими.
Другими словами лучше описывает ситуацию следующая картина.
ab_2

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

Конечно более сложный случай, когда нет хороших проторенных "дорог". Например, если это принципиально новая разработка. В таком случаях утверждение "Что он тут такого делает уже N-цатый год?", звучит аналогично претензии к Колумбу: "Что тут такого? Здесь и ежу понятно, что нужно просто плыть на запад и попадешь в Америку". Сегодня это кажется очевидным, а тогда найти средства на подобную авантюру было не так уж и просто.  Опять-таки в итоге Колумб все-таки ошибся где-то в три с половиной раза (почти на Пи), ведь изначально он хотел попасть в Индию, а она намного дальше...

Возвращаясь в наши дни, к теме этой заметки, хотел подвести небольшое резюме.

  • Чтобы оценить сложность проекта нужно проделать большую работу (см. картинку с деревом решений). Не стоит прогибаться, когда заказчик требует выдать ему оценку сложности какого-то нового проекта в человеко-часах, суть которого вам изложили только что на словах в трех предложениях за чашечкой кофе. Реальная цена такой оценки наверное будет меньше стоимости выпитой вами чашки кофе.
  • Не стоит удивляться и сильно корить себя за количество потраченного времени. Во-первых в жизни часто сложности забываются, поэтому возникает кажущееся ощущение легкости пройденного пути, а во-вторых задним умом мы все гении.
  • Желательно искать хорошего "проводника", у которого был опыт работы если не в аналогичных, то хотя бы в похожих проектах. Естественно, что каждый проект в чем-то уникален, но возможно его интуиция и опыт позволит частично избежать попадания в тупиковые ситуации.

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

P.P.S. Дерево прорисовывается с помощью языка программирования processing. Собственно экспериментами с ним, а также arduino и raspberry pi сейчас посвящены воркшопы, которые мы проводим вместо проводимых ранее Scala-тусовок.


Рубрики
Java

Про новые публикации на блоге и планы на ближайшее будущее

Ближе к концу марта запускаю крупный проект на Java SE/EE. Сейчас по нему ведутся предварительные работы (проработка архитектуры, подготовка проектной документации, переговоры с клиентом и т.д.).
В связи с этим буду не сильно задействован непосредственно в разработке и думаю появится чуть больше свободного времени. Поэтому хотел в блоге сделать пару объявлений.

1. Планирую разобрать скопившиеся на блоге черновики. Их скопилось довольно много и все они в разной степени готовности и хочется как-то выставить приоритеты.
Вопрос, который меня терзает: "по какой тематике интересней было бы прочитать статьи?".
Варианты:

  • Про Android
  • Обычная Java (Scala)
  • О программирование в целом (UML, архитектуры, шаблоны и т.д.)

Если есть какие-то пожелания и предпочтения – буду рад узнать о них в комментариях.

2. В связи с менее загруженным графиком работы у меня (и в большей степени у моей коллеги) появилась возможность сделать небольшую заказную мобильную разработку под Android (и не только).
Если будут конкретные предложения - буду рад пообщаться.

Исходные данные.

Рубрики
4. Полезняшки

Умножаем на пи (π = 3,14159265...)

Около месяца назад мне попался на глаза шедевральный пост, в котором приводится гениальное по простоте, остроумное и изящное математическое доказательство теории: "при оценки сроков и объема работы над проектом желательно умножать исходную оценку на Пи". Оригинальный труд находится по следующей ссылке: http://www.altdevblogaday.com/2013/11/15/always-multiply-estimates-by-pi/. В этой статье хотел изложить краткий пересказ доказательства.

Допустим у вас есть какой-то исходный план действий.
Обозначим его вектором направленным из точки A в предполагаемую точку B0.
blog-1

Времена меняются. Цель из точки B0 отодвигается под фактором различных обстоятельств в точку B.
blog-2

Естественно не бывает так, что всё идет гладко, возникают трудности, которые приводят к отклонению от прямой. В итоге путь, по которому вы прибываете к цели является кривой.
blog-3

Рубрики
0. Мироощущение и бытие

Сколько стоит?

Так получилось, что я знаком со многими программистами, которые работают в крупных (и не очень) софтверных компаниях в качестве наемных сотрудников, т.е. на окладе. На сегодняшний день Москве можно наблюдать два явления:
1. Дефицит квалифицированных кадров.
2. Кризис самореализации. Много ИТ специалистов в прошлом учились в лучших высших учебных заведениях России, но текущая их работы не в полной мере позволяет им реализовать свой потенциал. Одни мирятся с таким положением дел, у других возникает желание "изменить судьбу", открыть свое дело, начать стартап, освободиться от "офисного рабства".

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

Пример из сборника задач Сканави М.И. для поступающих ВТУЗы. В прошлом, те кто хотел поступить в ВУЗ могли решить такой пример не особо себя утруждаю, как мы шутили «спинным мозгом». Наверное сейчас с появлением ЕГЭ эпоха задач из Сканави уходит в прошлое.

С другой стороны, когда нужно сделать не намного более сложные арифметические и алгебраические операции, но вместо конкретных чисел будут стоять налоги, накладные расходы, человеко-часы, риски, объемы, сроки, скидки и другие составляющие, то это вызывает панику. Человек с высшим техническим образованием может потратить несколько дней или даже недель, чтобы найти грубые ошибок в своих вычислениях.
Другими словами, если речь идёт о готовом математическом выражении — всё просто, но если это якобы "бизнес" ситуация и нужно ответить на вопрос "за 100 000 сделаешь программу?" или "сколько будет стоит сделать мобильное приложение?", то начинается тупёж. Например постоянно сталкиваюсь с людьми, которые путаются с процентами и не могут посчитать какую цену они должны указать заказчику, чтобы у них осталось 100 000 рублей после оплаты налога в 6% с дохода?
Казалось бы ответ очевиден - приблизительно 106 383 рубля, но даже в таком простом примере многие делают ошибки (считают 106 000) или вообще не учитывают налог в конечной стоимости («да ладно, пусть, чего мелочится, всего 6%»). Когда же нужно проделать более «сложные» вычисления, т.е. учесть в цене все затраты (часы на согласование проекта, тестирование, внедрение, отчисления в фонды, обслуживание счета в банке, расходы на аренду, обрудывание и другие расходы), то в итоге некоторые делают множество существенных арифметических, алгебраических и алгоритмических ошибок. Хотя на самом деле, здесь нет ничего сложного.

Ошибка 1.

Допустим существует некий абстрактный московский 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 рублей в фитнес-клуб никто не пустит, хотя стоимость часа рассчитана по схожему принципу. Думаю для любого торговца на улице очевидна причина в разнице цены за килограмм картошки между покупкой ее вагонами и трех килограммов в розницу, но почему-то у программистов-предпринимателей работает "линейное" мышление в расчете цены.

Ошибка 2.


Есть такой бородатый анекдот:
Новый русский открыл фотосалон и дал объявление: "Приглашаю фотомодель для съемки. Оплата наличкой на месте. За час работы 20 тысяч баксов".
Набежала куча моделей, отобрали одну, снимали с вечера и до ночи.
Приходит новый русский:
- Ну что, фотограф, сколько наснимал?
- Четыреста кадров.
- А выдержку ставил какую?
- 1/200 секунды.
- Ну ты, девка, в натуре, на две секунды всего лишь наработала, держи 12 баксов.

К чему я вспомнил этот старый анекдот из прошедшей эпохи?

Рубрики
0. Мироощущение и бытие

Let's rock, everybody!

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

Статья про рок-банды, новое время и программирование.

rock-and-roll-xs

 

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

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

Если мы посмотрим на разработку программных продуктов по классической водопадной схеме, то состав участников также будет довольно обширным: архитектор, тим лид, ведущие программисты, несколько программистов разной специализации (java, c/с++, javascript и тд) и группа дизайнеров с верстальщиками. Естественно далеко не все компании могут себе позволить идеально укомплектованный состав. Наиболее успешные организации могут заинтересовать в профессиональном и материальном плане более сильных специалистов, остальные конторы довольствуются тем, кто соответствует их уровню.

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

Под новым форматом я имею в виду небольшой творческий коллективов состоящий из 3-5 человек. Это еще не "оркестр", но уже и не соло-программист. Естественно масштаб создаваемых произведений не сопоставим с творением Классики. Другими словами, если проводить аналогии, речь идет о коллективах создающие программы "по духу" более близкие к Yesterday Битлз, чем к Хорошо темперированному клавиру И.С. Баха.
Все идет к тому, что в программировании наступит время аналогичное музыкальной эпохи 60-70гг прошлого века.

У кого-то может возникнуть такая ассоциация:
blog_beatles
у других такая:

Рубрики
Java

JavaJobs.ru - перезагрузка.

Года три-четыре назад в качестве "лабораторного" эксперимента мною был сделан сайт JavaJobs.ru.
В основе лежало желание создать небольшой ресурс (в большей части для собственных нужд), упрощающий поиск свежих и интересных вакансий для java-программистов.

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

Работа над этим проектом велась в свободном режиме, в перерывах между работами по коммерческими проектами.

В первой редакции это был просто сайт для публикации вакансий.
Потом мне надоело с ним возиться, я написал робота-поисковика, который сам выискивал на разных job-ных сайтах интересные вакансии.

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

В декабре удалось выкроить немного времени, разобраться Twitter Bootstrap (HTML и CSS фреймворк). В итоге была запущена третья редакция с обновленным интерфейсом.

Несмотря на то, что javajobs-робот иногда простаивал, я все же решил построить график изменения количества найденных ссылок на вакансии:

Рубрики
1. Языки программирования 4. Полезняшки

Тренды программистских вакансий на indeed.com

Пару дней назад прочитал интересную статью на dzone.com с занятными графиками, которые показывали количество вакансий для программистов.

В статье были опубликованы данные с сайтов: indeed.com и simplyhired.com

Оба сайта имеют русскоязычный интерфейс, поэтому надеюсь, что приведенные графики отображали не только данные по США (как часто бывает), а мировые тренды.
Хотя может быть это и не так. К сожалению, не нашел способа получить картинки локализованные под Россию (или Москву).

Меня в первую очередь конечно интересовала java, а также близкие или "конкурирующие" языки программирования.
Поэтому в отличие от оригинальной статье на dzone я оставил в графике от indeed.com только такие языки как: java, C++, C#, objective c (убрал Perl и Visual Basic).

Получилась такая картинка:

Рубрики
0. Мироощущение и бытие

Жизнь в Coworking-e

фотография с сайта http://placeplaceplace.ru
Прошел где-то месяц, с того момента как я переехал работать в коворкинг. В связи с этим хотел поделиться некоторыми итогами и своими впечатлениями.

В первую очередь, хотел ответить на вопрос, который задают в первую очередь: "Сколько стоит?".
Стоимость аренды около 10 тысяч рублей в месяц. Комментировать цену не хочу.
Подробнее можно прочитать на сайте: http://www.flacon.su/space/coworking/

Расположение.
Коворкинг на территории дизайн-завода "Флакон" (ул. Б. Новодмитровская, д. 36). Ближайшее метро - Дмитровская.

Рубрики
3. Инструментарий

Firefox и localhost

Недавно помогал ребятам из одной конторы (нужно было сделать на HTML5 Canvas графический редактор для их легаси-системы). Среди прочих задачек, была интересная проблемка с Firefox-ом - медленно обрабатывались запросы (1 запрос > 1 секунды).
Так как веб-сервер - самописный (полностью!), то были подозрения на все-что угодно (ошибки в реализации протокола, проблемы в клиентском коде на javascript и т.д.).

В итоге все-таки я проблему решил, оказалось очень забавно. Пишу здесь, может кому пригодится.
Сервер тестировался на localhost-е, а в Firefox-е есть проблема http://goo.gl/jJc7g
В общем проблема заключалась в медленном DNS-ресолве для localhost в Firefox-e (например 127.0.0.1 - не глючил)

Самое просто решение (но не самое правильно):
about:config -> network.dns.disableIPv6=true

Подробнее о причинах и правильных решениях: http://kb.mozillazine.org/Network.dns.disableIPv6

Рубрики
3. Инструментарий

Desktop wallpaper в качестве инструмента проверки браузера под различным разрешением

Используем обои для рабочего стола

У моего монитора разрешение 1680x1050, а в работе иногда нужно время от времени смотреть как будет выглядеть содержимое браузер например под разрешением 1024x768 или 1280x800.

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

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

При желании можно поместить в свободное пространство какую-нибудь приятную вам картинку. Я поместил Дюка (жавный маскот с красным носом). Он сейчас стал опенсорснутым, то есть вы его можете свободно (т.е. на халяву и безболезненно) использовать в различных целях. Например выкладывать в блогах и на своих веб страничках. Подробнее можно прочитать в "Open Source Duke".

Сами картинки с Дюком можно взять здесь.