Код. Тайный язык информатики
Автор: Чарльз Петцольд
Твердый переплет, 512 стр.
Эта книга на ozon.ru / books.ru

Есть довольно много книг для программистов из категории «must read» и о некоторых из них уже много раз упоминали на хабре (например, «Совершенный Код» Макконнелла). Об этой же книге я видел не так много упоминаний, хотя она заслуживает этого. «Код», на мой взгляд, является лучшей книгой о компьютерах, их устройстве и — главное — сути программирования. Книга, не только объясняющая как и почему работают компьютеры, но и приучающая к инженерному мышлению.

На прошлой неделе мне показали довольно любопытный проект, который, к сожалению, находится на самой ранней стадии. Его цель — интеграция javascript-движка V8 в веб-сервер nginx. Звучит необычно, правда?.. :)

На самом деле я вижу в этой идее довольно много плюсов, главные из них:

— V8, предположительно, намного быстрее, чем уже существующий интегрированный Perl;
— Javascript знает куча народу, и писать на нём будут;
— Javascript совершенно естественен в части асинхронного IO — интерфейс XMLHTTPRequest представляют себе все, и в nginx можно было бы сделать что-то подобное для работы с вводом-выводом;
— Javascript — современный, стандартизованный и развивающийся язык, с поддержкой от Google (да и других корпораций) он имеет шансы жить долго и счастливо, в отличие от Perl;

Основных два минуса этой затеи — общая неприспособленность Nginx для того, чтобы быть сервером приложений (по-крайней мере, для более-менее больших приложений), а также некоторая необычность самой идеи яваскрипта на server-side.

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

ЗЫ Адрес проекта на Google Code.

Итак, наболело.

Суть текста.

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

И это нужно исправлять. Срочно. Тыкать носом, не обижаться, сквозь слезы, но исправлять.


Еще немного сути.

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

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

А как делать этот самый рефакторинг, если даже неизвестно, с чего начать? Как осушить болото кода и не утонуть нем?

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

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

Богатство доступных программистам опций сегодня просто чудовищно. Мы задохнулись под тем, что извергает рог изобилия. Последние несколько лет я зарабатывал на том, что писал на Java, Objective-C, C, C++, Python, Ruby, JavaScript, PHP (прошу прощения) с разными вариантами SQL/баз данных (MySQL, PostgreSQL, MongoDB, BigTable, Redis, Memcached и другими). Нравится ли это мне? Черт побери, нет. По большей части я просто чувствую вину за то, что не делал ничего на Erlang, Clojure, Rust, Go, C#, Scala, Haskell, Julia, Scheme, Swift или OCaml.


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

Сейчас многие покупают точки доступа 802.11n, но хороших скоростей достичь удается не всем. В этом посте поговорим о не очень очевидных мелких нюансах, которые могут ощутимо улучшить (или ухудшить) работу Wi-Fi. Всё описанное ниже применимо как к домашним Wi-Fi-роутерам со стандартными и продвинутыми (DD-WRT & Co.) прошивками, так и к корпоративным железкам и сетям. Поэтому, в качестве примера возьмем «домашнюю» тему, как более родную и близкую к телу. Ибо даже самые администые из админов и инженеристые из инженеров живут в многоквартирных домах (или поселках с достаточной плотностью соседей), и всем хочется быстрого и надежного Wi-Fi.
[!!]: после замечаний касательно публикации первой части привожу текст целиком. Если вы читали первую часть — продолжайте отсюда.

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

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

Уровни управления проектом

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

• Секреты управления программистами
• Как стать менеджером в IT
• Черная книга менеджера
• Белая книжная полка менеджера
• Управленческие инструменты

Получить все книги бесплатно (нужна регистрация) можно вот здесь:

5 управленческих книг Стратоплана >>

Чуть ниже — об истории создания всех этих книг

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



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

Сейчас же я ожидаю гораздо более сильный по эмоциям шквал комментариев и сравнений меня с различными персонажами, вплоть до Геббельса. Надеюсь, все таки до этого не дойдет. Итак, «Фирменные стандарты» ИТ компании.

Как-то один из персонажей популярного сериала заявил «Все врут!». И это отчасти правда. И что уж 100% правда, что все лажают. Каждый может вспомнить, когда наши сотрудники не выполнили взятые на себя обязательства, сорвали сроки, что-то сделали — но совсем не то, а иногда лучше бы вообще не проявляли инициативу. К сожалению, лажают не только сотрудники, но и руководители. Самое печальное в этом то, что работают далеко не дураки, но бывают такие глупые epic fail, что и говорить не хочется.



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

Ларри Пейдж и Сергей Брин всерь­ез считали, что их компании управленцы незачем. В 2002 году они попытались выстроить горизонтальную оргструктуру — без менеджеров, руководящих программистами. Так, считали они, ничто не будет мешать быстрому обмену и появлению идей. Кроме того, им хотелось воссоздать ту атмосферу студенческой жизни, которая так нравилась им в университете. Эксперимент длился недолго: спустя несколько месяцев его пришлось прекратить. Брин и Пейдж изменили свое мнение о внутреннем устройстве компании, когда сотрудники валом повалили к Пейджу с вопросами, далекими от творчества: с финансовыми отчетами, жалобами друг на друга и т.п. А уж когда компания стала расти, ее основатели убедились, что управленцы полезны и в других отношениях: объясняют стратегию, значимость проектов и их очередность, налаживают сотрудничество в коллективе, следят за карьерным ростом людей и за тем, чтобы все рабочие процессы и системы соответствовали задачам бизнеса.

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

Ура! Мы закончили работу над переводом замечательной книги об архитектуре JavaScript-приложения. Работать над переводом было очень приятно — мы получили около 40 пулл-реквестов от совершенно незнакомых нам людей, которые помогли исправить множество опечаток, неточностей и различных багов на сайте! Ссылка на наш перевод упоминалась в курсе «Фронтенд-разработка», читаемом во втором семестре Технопарка Mail.ru, а также в некоторых независимых подкастах.

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

Читать книгу можно на сайте перевода. Также можно скачать книгу в удобном формате: epub, mobi, fb2. Исходный код проекта доступен в репозитории на GitHub

Дурак учится на своих ошибках

В этом смысле я полноценный дурак в большинстве технических дисциплин. Я никогда не был профессиональным программером и не пытался особенно следовать каким-либо правилам и стандартам, когда приходилось что-то написать на баше, а затем на питоне. Я просто решал свои мелкие админские задачи на том ЯП который был под рукой, наступая на каждую граблю которая мне попадалась. И так же просто и по админски доходил до того что профессиональные программеры наверное знают как поп 9 заповедей.
Убив сутки на дебаг bash скрипта, написанного за час, я понял что bash подходит практически только для однострочников. Попытавшись хранить инстансы собственных классов в текстовых файлах, понял зачем мне нужен orm, а поработав с собственным кодом годичной выдержки понял что хочу писать комментарии.
Никто меня этому не учил, никто не требовал от меня выполнения каки-либо правил написания кода, но их смысл доходил до меня с предельнгой ясностью, а желания ими пренебречь с тех пор не возникало.
Тут я полноценный дурак и этим горжусь.

Раздолбаи

Но в некоторых вопросах я до дурака не дотягиваю и хожу по одним и тем же граблям снова и снова. Даже пожалуй встаю на граблю и начинаю прыгать. Так я познаю искусство работы с людьми.
Началось все с попытки найти применение множеству знакомых раздолбаев. Раздолбай — это вроде бы хороший человек, с которым приятно попить пиво и пообщаться, но по тем или иным причинам не нашедший способа приносить обществу пользу. Такие личности обычно очень страдают от отсутствия денег на пиво и знают массу причин по которым попытка найти клевую работу и заработать себе на пиво в их случае обречена на провал и лишена смысла.
Среди таких причин обычно значатся отсутствие высшего образования, отсутствие опыта в чем-либо кроме пития пива, неспособность заниматься неинтересной и механической работой, отсутствие здоровья, преклонный возраст (24 года) итд.
И в этот момент появляюсь я с аналогичной любовью к пиву, ленью, нежеланием делать скучную работу, брошенным универом и огромной любовью к людям. Появляюсь и думаю — они такие же как я, но не прошарили что IT — есть сущий рай для раздолбая, где ты руководствуясь лишь любопытством с одной стороны и ленью с другой становишься первоклассным специалистом которому даже не надо ходить на работу и просыпаться раньше полудня, а надо только дотащить свой зад от кровати до компа и получать деньги, делая то что больше всего любишь.
И вот я сообщаю своим друзьям раздолбаям что знаю чит-код от реальности, и что им надо срочно стать сисадминами, и что я помогу им в этом совершенно безвозмездно и всецело.
Для этого мне приходится подарить раздолбаю свой устаревший десктопник с монитором, клавой и мышью, оплатить им на месяц интернет, распечатать пару книжек про Linux, записать на болванку livecd и показать как загрузиться с него и получить рутовую консоль. Затем я рассказываю и показываю как офигенно клево и логично устроен Linux в течении N часов и изрядно уставший иду наконец работать. Подобный сценарий у меня повторялся с десятком раздолбаев.
Через месяц одни раздолбаи пропили устаревший десктопник, другие подсели на доту, а третьи и вовсе на меня ополчились, заявив что я пытаюсь их использовать. Ни один раздолбай не стал линуксоидом.
Я же после этого впадал в депрессию на почве разочарования в людях. Я ломал голову месяцами пытаясь понять почему эти люди находят в себе силы жить без любимого пива, а пойти по легкому пути айтишника не могут. Ведь куда легче бороться за свое право на пиво чем смириться с его отсутствием. Разве нет?
И раз за разом я отказывался понимать правду написанную крупным шрифтом на ручке этих граблей: "люди не меняются"

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

Лично меня жизнь убедила, что люди это капитал. Особенно в нашей отрасли все зависит от людей. Если кто-то сомневается в этом, то очень рекомендую книгу шведов Кьелла А. Нордстрема, Йонаса Риддерстрале, «Бизнес в стиле фанк. Капитал пляшет под дудку таланта». Книга не новая, но, имхо, очень доходчиво разъясняет, почему Маркс, Ленин и Мао Дзэдун были правы в современном мире это именно так.

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

Stop fucking procrastinating and do some fucking work!

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

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

Казалось бы, работа у IT-шников несложная — вагоны не разгружаем, землю не роем и уставать физически не должны. Однако о дичайшей усталости людей занятых интеллектуальным трудом приходится слышать чаще, чем хотелось бы. После того как я приехал в Москву 3 года назад — я почему-то начал дичайше уставать на совершенно ровном месте, и ни я, ни врачи не могли найти причину. После 2-х лет поисков тривиальная и легко исправимая причина нашлась, и на мой взгляд — в группе риска находятся практически все люди, занимающиеся интеллектуальным трудом. Ситуация усугубляется двумя народными обычаями.

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

1) Летом все ок, а зимой — апатия, ничего не хочется делать. Это любят называть сезонной «депрессией».
2) Утром все ок, а к вечеру на работе — мозги «не варят», ничего не хочется делать — только хабр и reddit листать. Приходите домой — и с дичайшей усталостью падаете в кресло. Сил хватает только лазить в интернете до ночи. Этот пункт — касается и работодателей, есть шанс, что люди вечером перестают работать не из-за своей лени.
3) Даже если вы просыпаетесь без будильника — вы не высыпаетесь.
4) Кофе и прочие стимуляторы — не дают бодрости, лишь делают вас злее.
5) Даже если вы спите «сколько влезет» — сны короткие и не запоминающиеся, или их нет вообще.
6) Вы замечаете, что даже 1 вещь вам иногда трудно удержать в голове. Мы можете забыть что вы сейчас хотели сделать.
7) Вы просыпаетесь уже с дичайшей усталостью
8) Вам кажется, что в комнате темно и все несколько не резкое.

Знакомьтесь, это обычный «литровый» пакет молока:

• Проверка на внимательность: там 900 грамм. Рядом несколько по 950. Но пакет может быть воспринят как литровый.
• Проверка на знание физики. Рядом лежит похожий кефир. Объём измеряется в миллилитрах, масса — в граммах. Плотность кефира трагически выше плотности воды. То есть 900 грамм кефира 3,2% жирности — это примерно 874,5 миллилитров.

Второй пациент:



25 лет гарантии. Круто, правда? Есть одна проблема. Надо сохранять чек. Проверка, опять же, на знание физики. Чек у них печатается на обычной кассовой термоленте (я проверил на месте). У меня в офисе лежит много чеков. Мы их ксерокопируем, потому что через год-два они полностью выцветают. Самый старый чек, который видел коллега, держался 3 года в папке в архиве. UPD: смотрите самый низ топика, Икея ответила.

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

Осторожно, трафик: под катом много находок с фотографиями.

От переводчика
Выгорание в жизни программиста может случиться по самым разнообразным причинам; если задаться целью перечислить все пути, которыми оно подкрадывается к нам, то одно лишь это перечисление займет немало времени. Это еще один повод, по которому не стоит недооценивать процесс выгорания — иначе однажды вам придется искать дорогу обратно, и стоить это может очень дорого. Последняя строка вовсе не голословна — мне самому однажды смогла помочь лишь любовь к коду — когда уже, казалось бы, все осточертело и ничего не хотелось, чтение подвернувшегося Макконнелла навеяло воспоминания о том, как же когда-то мне нравилось программировать. И сегодня мне нравится делать это снова.
А теперь — слово автору.

Я отошел от своего выгорания только недавно — несмотря на то, что случилось оно несколько лет назад. Да, мне было непросто… очень непросто. Когда я думаю о произошедшем, на ум приходит немало причин тому, что случилось со мной — но самое интересное заключается в том, что каждой из них я никогда раньше не придавал значения. Хотите повторить мой путь и выгореть? Пожалуйста, у меня готов целый список, как следует поступать в таком случае:

1. Думать о проекте и только о нем

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