Конечно же читать!

Знания не торба, за плечами не носить. (Народ)

Я уже устал удивляться тому, как часто на форумах возникают темы "Стоит ли мне читать про технологию ХYZ и смогу ли я найти потом работу". Вот с какой луны падают такие люди? Конечно же стоит изучать! В конце-то концов, чтобы стать программистом (а не быдлокодером), нужно постоянно учиться. Новые идеи не приходят от плевания в потолок и упорного использования одной-двух технологий.

Мечтают ли программисты об авралах

В ИТ разработка продукта и выпуск релиза зачастую связаны с авралами, переработками, безнадёжными проектами и другими "прелестями". Всё это вроде как достало, но тем не менее программисты не воспринимают эти самые авралы как абсолютное зло, которое нужно избегать. Казалось бы, не нравятся авралы - посылай начальство и всё нормально. Ведь есть множество других областей и профессий, где аврал не считается нормой. Однако мало кто так делает и очередной релиз снова идёт в авральном режиме. Почему?

Программисты

Посмотрим на профессию программиста. Кто-то считает эту профессию творческой, кто-то думает, что программист - это ремесленник. Как правильно - в данный момент неважно. Итак программист - это:

• творческая личность
• умный, образованный ремесленник
  

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

Менеджмент

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

Авралы

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

Как нам живётся во время аврала

Аврал - время снятия всех ограничений. Когда приходит понимание, что в заданном режиме работы к сроку не успеваем, но начием думать, а как бы ускорить работу. Вот тут-то программист и получает практически полную свободу действй! Множество решений принимается самостоятельно, "на лету", без необходимости отчитываться о каждом из таких решений и без необходимости ждать, пока "таможня (руководство) даст добро". Вот тут-то и приходит долгожданный программистский кайф.

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

Операторы условия во Flex'e и чудеса, связынные с ними

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

1 top_buttons.selectedIndex = 1;
2 if (top_buttons.selectedIndex == 1) {
3     Alert.show('Ура!');
4 } else {
5     Alert.show('Фигу тебе!');
6 }

Казалось бы ход выполнения ясен как 2+2=4, НО! я вижу вовсе не радостное Ура, а самую настоящую фигу. Что это такое - я не знаю. Что самое смешное во всём этом, что вот такой код:

 1 private function test(): void {
 2     top_buttons.selectedIndex = 1;
 3     if (top_buttons.selectedIndex == 1) {
 4         Alert.show('Ура!');
 5     } else {
 6         Alert.show('Фигу тебе!');
 7     }
 8 }
 9 
10 test(); // Фигу
11 test(); // Ура

даёт сперва фигу, а потом радостно сообщает "Ура". В чём прикол - до сих пор не понял. Решил пока что на это забить, ибо нет времени. Просто изменил логику программы на прямолинейную без всяких там условий.

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

linux, mail, консоль

Сегодня понадобилось отправить несколько поправленных файлов с продакшн-сервера на свой почтовый ящик. Доступ к серверу - putty. Помогла очень полезная утилита - mail.

Как отправить почту из консоли:

cat filename | mail -s "тема" mymail@yandex.ru

Мифический человеко - месяц (Mythical man-month)

Наконец-то я закончил чтение этой книги. Читал её долго, с перерывами, как-то не до неё было.

Книга интересная, ненапрягающая и проверенная временем ;) - всё ж таки почти 35 лет уже прошло со времени первого издания.

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

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

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

И снова drupal, ecommerce и почта

Ранее я писал про баг в модуле для друпла, который нам удалось победить. Ну в общем-то было рано радоваться. Баг я победил, мейнтейнерам письмо написал, а потом...

Мейнтейры сказали, что больше этот модуль не развивают и предложили перейти на 6-й друпал. Хорошо ещё, что они не знали, что у нас не drupal, а vbdrupal - засмеяли бы.

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

Обидно, что сил было потрачено много, а результата это не дало. Такой себе НИОКР за свой счёт и за пару недель до дедлайна. В следующий раз будем умнее и будем брать то, что точно работает, и мы знаем, как это настроить.

Paint как средство усмирения заказчика

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

1. Нужно побольше фото нашей продукции на первой странице, чтобы клиент сразу видел, что у нас всё есть!

   Как скажете! Но учтите, чем больше фото, тем дольше грузится сайт, и клиент может уйти, так ничего и не увидев.

   Не надо!

2. Давайте сделаем фон какой-нибудь яркой радугой, а может вообще на оранжевом фоне фиолетовые буквы.

   (уж и не знаю, что он представлял в своём воображении, но меня спас Paint)

   Подождите секунду, - открывают паинт, заливаю всё оранжевым и пишу слово фиолетовым текстом - Вы хотите такой дизайн, или оставим прежний?

   Прежний.

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

Программист-прагматик

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

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

Особенно мне понравился совет писать программы, которые пишут программы + принцип DRY. Первое же применение этого совета мне очень помогло. Несколько месяцев назад я делал небольшой веб-проект, в котором было много однотипных страниц, но при этом нельзя было использовать CMS, на каждую ссылку нужно было делать отдельный php-файл. Вручную копипастить код из одного файла в другой было бы долго (хотя в таком случае результат можно было бы показывать уже через 1-2 часа работы), поэтому я решил написать генератор страниц. Все отличия я вынес в отдельные файлы: имена файлов, заголовки страниц, текст страниц. Затем написал простой генератор, который брал данные из этих файлов и генерировал на выходе необходимые мне файлы с перекрёстными ссылками друг на друга. В течении дня я занимался этим генератором и входными файлами, а вечером у меня уже был результат. Очень большой выигрыш по времени я получил и на этапе сопровождения этого кода, когда подгоняли страницы под конкретные требования, мне не нужно было менять один и тот же блок в большом количестве файлов, я менял только правило генерации страниц.

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

Путь камикадзе (Смертельный марш)

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

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

Чем может помочь эта книга одному из членов проектной команды:

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

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

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

Времени, потраченного на книгу не жалею, чтение оказалось полезным и интересным. Её можно прочесть даже как художественную, только под названием "Игры менеджеров или почему программисты умирают". Позитивного всем чтения! :)

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

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

Мне приходилось сталкиваться с таким стартом:
1. Был посетителем одного тренинга по языку программирования Perl. Я пошёл туда, уже имея опыт программирования на этом языке, из простого любопытства. За три дня слушатели получили базовое представление об этом языке и написали простого веб-бота, который парсил сайты знакомств. На самостоятельное получение таких опыта и знаний у многих бы ушло не меньше недели.
2. Мне недавно пришлось переходить на новую CMS - drupal. Вспоминая свой опыт работы с joomla, я сразу отвёл себе неделю на изучение базового функционала друпала неделю. В итоге, под руководством человека, знающего друпал, я за день сделал скелет сайта, к которому в последствии добавляли самописный функционал.

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