Предвзятое мнение о книге "Seven languages in seven weeks"

Закончил ускоренное чтение по диагонали книги "Seven languages in seven weeks", автор Bruce Tate.



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

Описываются языки:

• Ruby
• Io
• Prolog
• Scala
• Erlang
• Clojure
• Haskell

Обзор каждой главы - это мой субъективный взгляд на две вещи сразу: язык программирования и материал главы про него. Объясню почему - для знакомых языков вряд ли имеет смысл описывать сам язык. Может имеет смысл отметить интересные отличительные моменты. А вроде для неизученных, типа Пролога или Clojure, можно и остановиться немного на самом языке.

Ruby

Про Ruby ничего особенно из книги не вынес, так как вдумчиво читал "Programming Ruby 1.9", после чего подсел на этот язык. Ruby - фантастический скриптовой язык. Каждый раз, когда пишу на нем, испытываю удовольствие примерно такое, когда я после Perl'а попробовал в первый раз PHP.

Автор языка сказал в интервью, что, создавая бы язык заново сегодня, он бы хотел для многопоточности вместо традиционных потоков сделать модель "actor".

В двух словах, Actor - это когда параллельные потоки разделяют ресурсы не через память и механизмы синхронизации типа мьютексов и семафоров, а через обмен сообщениями, прием и посылка которых обеспечиваются средой, и они встроены в синтаксис языка. Например, как в Scala, Go, Erlang, Io.

Io

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

Интересный механизм многопоточности в дополнение к actor и coroutine (коллективная многозадачность, как в Lua), называемый futures. "Futures" - это вроде бы как обычный actor, поток запущенный работать параллельно. Но с одним отличием: как только создающий поток попытается воспользоваться результатом future, он будет заблокирован до тех пор, пока future не вычислит это значение.

Примерчик из книги:

// Запускаем future
futureResult := URL with("http://google.com/") @fetch
writeln("Сразу начинаем делать что еще, пока future работает в фоне.")
// Эта строка будет выполнена сразу.
writeln("fetched ", futureResult size, " bytes")
// А вот эта строка будет заблокирована, пока future не выполнится.

Идем дальше, Prolog.

Этого зверя я грызу давно. К счастью, благодаря освоению Erlang'а, я стал реально въезжать в функциональную тему в целом, и монстры типа Пролога или Хаскелла уже не за пределами понимания.

Так совпало, что глубина материала по Прологу легла точно для моего уровня. Задача восьми ферзей и поиска решений Судоку были для меня отличными примерами.

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

Фактические программа поиска решения Судоку - это набор переменных, составляющих клетки поля Судоку, и набор правил - разнообразные суммирования по группам, по строками и столбцам (по правилам Судоку). И затем Пролог перебором ищет подходящие значения и комбинации переменных.

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

Идем дальше, Scala.

Отмечу только отдельные факты, интересные мне.

Многопоточность на основе actors, то есть когда потоки обмениваются сообщениями. После Go и Erlang понимаешь как это удобно и правильно.

Про остальное - по-моему в Scalа есть все возможные свистелки и перделки, когда-либо придуманные в области языков программирования. В общем, если вы фанат Java VM, то надо брать полноценную книгу по Scala и грызть ее.

Идем далее, Erlang.

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

Clojure

Снова язык на основе Java VM. Clojure - это разновидность Лиспа со всеми вытекающими.
Интересная возможность языка, в общем-то не связанная с его лисповой сущностью - это STM, software transactional memory. Это когда некий кусок кода в программе объявляется транзакцией, и он выполняется атомарно, либо все изменения откатываются.

Ну и под занавес, Haskell.

Хаскелл суров, и данная книга - это крайне минимальное введение, просто для запоминания слова Хаскелл. Я кое как осилил отличную книгу Душкина и "Programming in Haskell", а сейчас читаю "Real World Haskell", поэтому главу этой книги просто пролистал.

Вывод: книга 100% одноразовая, но, как говориться, раз не... полезно для кругозора и для программистских терок на кухне.

Steve Jobs: The Exclusive Biography / Биография Стива Джобса от Уолтера Айзексона

Note: This post is in two languages. The English one is the second.

---

Биография Стива Джобса от Уолтера Айзексона от Уолтера Айзексона

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

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

Можно говорить, что это конъюнктура и попытка сыграть на ситуации, что Стив только что умер, но, несмотря на все эти предрассудки, я подсел практически сразу.

Уж не знаю, в чем тут дело, может просто автор мастер своего дела, но я так и не оторвался, пока не прочитал до конца.

Вывод: настоятельно рекомендую, даже для принципиальных нелюбителей Эппла.

---

Steve Jobs: The Exclusive Biography by Walter Isaacson

I thought that biographies are for "old people". This book has changed that mindset in me. Being driven by massive ads and recently emerged love with Apple products and philosophy I had started reading.

Initially it was like an expanded version of "Pirates of Silicon Valley" which I, frankly, liked, but as reading progressed I had just fallen in love with this book and weren't able to stop.

The book can be treated as conjuncture or just an attempt to leverage the situation that Steve has just passed away. I was fully biased but after the first chapter I was hooked.

It is fascinating reading. Maybe just because the author is talented, I don't know.

Conclusion: strongly recommend.

The world is flat 3.0 / Плоский мир 3.0

Note: This post is in two languages. The English one is the second.

---

Я снова вернулся к аудиокнигам. 40-50 минут в день по дороге на работу и потом обратно позволяют поглощать книги с приличной скоростью.

Из недавнего.

"The world is flat 3.0: A Brief History of the Twenty-first Century", Thomas L. Friedman

Убийственная книга для осознания, что:

• сейчас индивидуумы могут спокойно конкурировать с корпорациями
• важность инженерного, а особенно компьютерного, образования растет семимильными шагами, и это не дань моде, а объективная реальность
• количество мест на планете, где можно жить и зарабатывать достойные деньги и развиваться уже не сужается к Штатами (разве не забавно слышать такое от коренного американца-консерватора) и некоторыми странам Европы
• Индия, Китай, Россия и многие другие страны начали сильнейшую конкурецию на рынке труда с тем же США уже без массового отъезда специалистов
• постоянное самообразование - это едиственный способ не быть вытолкнутым с рынка труда

И многое многое другое.

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

Это очень интересное и познавательное чтиво.

---

I've come back to audiobooks. 40-50 minutes per day when heading an office and then back allow to consume books with decent speed.

A recent.

"The world is flat 3.0: A Brief History of the Twenty-first Century", Thomas L. Friedman

This is a killer book to understand or even discover that nowadays:

• individuals can compete with corporations
• importance of engineering and especially computer education is increasing enormously
• number of places on the Earth when you can have decent life doing what you love to do is not narrowed to the US and a few EU countries anymore
• India, China, Russia and many other countries have a very strong position competing with even US now without immigration
• permanent self education and nurturing your curiosity (CQ + PQ always greater that IQ) is the only way to remain valuable

And many other topics.

Frankly, there were moments in my life when I doubted and thought I would be better off doing, for instance, real estate, natural resources, ads or media rather than software. If you have even a tiny similar concern this book will wipe it out forever, and maybe even show the way.

To conclude: very useful, interesting and fascinating reading.

Закомментированные куски кода

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

Ребята купили в офис "Test Driven Development for Embedded C" от James W. Grenning.

Хоть там и много про hardware, но примеры как можно и нужно изолировать зависимости для упрощения тестирования на языке С очень полезные. Кроме того описаны пара xUnit библиотек для этого языка (хотя cmockery нет).

Итак, цитата (как есть, без сокращении и перевода).

Commented-out Code

Sources files littered with commented-out code are an ugly mess. New or returning programmers are faced with questions about what the code is supposed to do. "Should the code be uncommented?" "It is no longer needed?" "When will it be needed and under what circumstances is it needed?" "What's that for?"

The solution to this code smell is simple; delete the commented-out code. It can always be recovered from your source repository.

Посты по теме:

• Unit-тестирование в языке С

Книги по обработке строке и производящим функциям

Покупка книг на Амазоне в Европе и Штатах дело крайне простое, удобное и быстрое (особенно для электронных книг). Тут также можно и продавать свои книги. Очень удобно и для владельца, когда надо избавиться от одноразовой книги, и для покупателя, так как можно купить реально дешевле (а потом тоже продать).

Надеюсь, почта России одумается и сделает нормальный сервис доставки.

В Лондоне мой любимый книжный - это Foyles на Charing Cross. Ни в Waterstones, ни в Borders не видел столь огромного отдела технической литературы, которая еще и великолепно отсортирована и разобрана по разделам. Например, отдельный шкаф с книгами чисто по компиляторам, или чисто по языку Хаскель, или по QA тестированию, а вдоль стендов про Java или C++ вообще можно ехать на самокате.

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

Куда я первым делом отправился во время визита в Москву на прошлой неделе? В "Библио-Глобус" на Лубянке. Кто знает в Москве офлайновый магазин с большим выбором и лучшей организацией стендов - поделитесь.

Приятно отменить, что очень много переводных книг, причем весьма свежих.

Но еще более приятно, что наша литература ничем не хуже.

В разделе компьютерном купил:

С. М. Окулов, Алгоритмы обработки строк



Как написано в предисловии - это книга посвящена одному вопросу - как искать подстроку в строке за линейное время. На первых страницах рассматривается Кнут-Моррис-Пратт, а дальше начинается всякая жесть. Забавно, что книга из серии "Развитие интеллекта школьников", то есть для просто школьников.

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

Вывод: иметь.

Далее, в соседнем разделе математики купил:

С. К. Ландо, Лекции о производящих функциях



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

Эта книга есть в свободном варианте.

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

http://www.mccme.ru/free-books/
http://e-maxx.ru/bookz/

P.S. Кто знает еще хорошие ссылки по электронным книгам - делитесь в комментах.

Jason Fried, David Heinemeier Hansson, "Rework"

Книга от создателей компании 37 signals и Ruby on Rails о том, как можно вести малый бизнес в IT, не разрывая зад по 10-12 часов в день, а только с 9 до 5, и при этом достойно и даже очень зарабатывать.

Jason Fried, David Heinemeier Hansson, "Rework"



Довольно пафосная книга, состоящая из мини глав, похожих на посты в блоге (эта книга и родилась из блога), но многие ее посылы стоит усвоить. С ними легче и приятнее жить, и во многом ранее скучном и нудном может появиться вдруг смысл. Также книга может подтолкнуть в мир самостоятельной работы на самого себя, например, написание shareware.

Но одна глава мне очень понравилась. Про резюме и сопроводительные письма.

Приведу ее целиком как есть и собственный вольный перевод, если кому надо.

Resumes are ridiculous

We all know resumes are a joke. They're exaggerations. They're filled with "action verbs" that don't mean anything. They list job titles and responsibilities that are vaguely accurate at best. And there's no way to verify most of what's on there. The whole thing is a face.

Worst of all, they're too easy. Anyone can create a decent-enough resume. That's why half-assed applicants love them so much. They can shotgun out hundreds at a time to potential employers. It's another form of spam. They don't care about landing your job; they just care about landing any job.

If someone sends out a resume to three hundred companies, that's a huge red flag right there. There's no way that applicant has researched you. There's no way he knows what's different about your company.

If you hire based on this garbage, you're missing the point of what hiring is about. You want a specific candidate who cares specifically about your company, your products, your customers, and your job.

So how do you find these candidates? First step: Check the cover letter. In a cover letter, you get actual communication instead of a list of skills, verbs, and years of irrelevance. There's no way an applicant can churn out hundreds of personalized letters. That's why the cover letter is a much better test than a resume. You hear someone's actual voice and are able to recognize if it's in tune with you and your company.

Trust you gut reaction. If the first paragraph sucks, the second has to work that much harder. If there's no hook in the first three, it's unlikely there's a match there. On the other hand, if your gut is telling you there's a chance at a real match, then move on to the interview stage.

Перевод:

Резюме – это недоразумение.

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

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

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

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

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

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

От себя могу добавить. Всегда стоит писать cover letter, причем вдумчивые и персонализированные. В процессе их написания часто приходит понимание - "а хочу ли сам я там работать?"

Книгу после прочтения я продал назад через Амазон.

Bernard Girard, "The Google Way"

Было интересно почитать про историю Google, посему купил вот эту книгу.

Bernard Girard, The Google Way



Не могу сказать, что мне особо понравилось, хоть фактов в книге предостачно: и про самое начало, и про выход на IPO (работая сейчас в сфере finance, знаю, как обычно инвестиционные банкиры наживаются на процедуре IPO, но Гугл их сильно в этом плане разочаровал, не дав им кусок своего пирога), и про правило 20%, и про систему peer review, и про наличие технической иерархии и про многое другое.

Разок прочитать можно, но не более того. Книгу продал назад через Amazon Market Place.

Тренинг Steve Dewhurst'а "C++ Common Knowledge"

Побывал на тренинге Steve Dewhurst'а "C++ Common Knowledge". У меня уже давно есть его книга:



и в целом конкретно этот тренинг посвящен темам из нее.

Очень прикольный дядька. Нескучно, разбавлено подколами аудитории и шутками типа что ребята из Boost'a не иначе как курят шаблоны и т.д. Мне очень понравилось.

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

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

Рекомендация такая: сначала задаешь себе вопрос: а нужно ли мне тут множественное наследование? а нужно ли мне виртуальное множественное наследование?? а нужно ли мне виртуальное множественное наследование с данными в базовом виртуальном классе??? И даже после долгого раздумья лучше сказать "нет". Лично я не имею ничего против множественного наследования. Но мне не очень нравится как это сделано в С++. И мне не очень нравится как это сделано в Java. Мне очень нравится, как сделано в Go. А именно: в Go полностью разнесены понятия структур данных и интерфейсов. Структуры данных не могут быть унаследованы. Они могут только реализовывать интерфейсы. А наследовать можно только интерфейсы. Поэтому в принципе нельзя при наследовании подцепить чужие данные, а только методы. А нет данных, не и проблемы их инициализации.

Итак, могу просто собрать общие рекомендации от Стива:

• стараться использовать виртуальные функции и полиморфизм в целом вместо "if" и "case"
• стараться использовать алгоритмы STL/Boost и функторы вместо циклов
• использовать только "умные" указатели при работе с динамической памятью
• не использовать классические массивы, а контейнеры STL (так как, например, std::vector гарантирует линейное размещение элементов, то можно смешивать "старый" код, работающий с указателями, с использованием контейнеров)
• тщательно продумывать операции копирования сложных классов (лучше всего реализовать конструктор копирования и метод swap, а оператор присваивания реализовать через них)
• всегда объявлять в коде класса конструктор копирования и оператор присваивания, и даже если они не используются, то просто закомментировать их объявление с пояснением, почему они не нужны
• никогда не использовать приведения типов в стиле С, только С++ (static_cast, const_cast и т.д.), так как они длинные, их нудно набивать и они уродуют вид программы - в общем, все, что нужно для минимизации их наличия
• помнить, что наследование - это re-use интерфейсов, а не кода как такового
• не слишком верить компилятору ;-) (Стив их писал и знает, что они могут и подставить)

Peter Seibel, "Coders at Work"

Неспешно дочитал "Coders at Work".

Peter Seibel, Coders at Work



Книга состоит из интервью с десятком известных программистов. Тут есть создатели UNIX, Netscape, JavaScript, Smalltalk, Haskell, Erland, Ghostscript, ЖЖ и также есть просто Дональд Кнут. В общем, не самые последние люди.

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

Многие ссылаются на разные книги - я значительно пополнил свой список на "прочитать".

Забавно, что почти никто не отозвался однозначно положительно о С++. Либо было однозначное нет типа "очень перегружено, сложно и т.д.", либо "ну раз уж более ничего пока лучше нет для создания native кода промышленной сложности, то пусть будет".

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

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

Как всегда убедился, что я даже и не слышал о некоторых крайне известных вещах. Например, Literate programming от Дональда Кнута или фильтр Блума.

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

Фундаментальные алгоритмы

После того, как я жестко облажался с самопальной сортировкой, причем облажался дважды: первый раз, когда думал, что порву по скорости STL'ный std::sort(), а второй - когда не понял, что все эти "ухищрения", как я думал, по ускорению QuickSort'а, реализованные в STL'е Visual Studio, есть ни что иное, как просто давно придуманный IntroSort.

В общем, я взял в руки:

Роберт Седжвик

Фундаментальные алгоритмы на C++. Части 1-4. Анализ. Структуры данных. Сортировка.



и начал освежать (а местами просто узнавать с нуля) когда-то читанное в студенчестве.

Втянулся.

Заказал вторую книгу:

Роберт Седжвик

Фундаментальные алгоритмы на C++. Часть 5. Алгоритмы на графах



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

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

Дж. Ханк Рейнвотер, "Наставление для программистов, руководящих другими программистами"

Дж. Ханк Рейнвотер

Наставление для программистов, руководящих другими программистами



Продолжая тему про книги для программистов, начавших заниматься управлением, расскажу про эту книгу.

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

Техническое лидерство взращивается на почве знания и питается готовностью учиться на собственных ошибках — в конечном итоге какая практика обязательно увенчается успехом.

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

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


Посты по теме:

• Фредерик Брукс, "Мифический человеко-месяц или как создаются программные системы"
• Том Демарко, Тимати Листер, "Человеский фактор: успешные проекты и команды"

Том Демарко, Тимати Листер, "Человеский фактор: успешные проекты и команды"

Том Демарко, Тимати Листер

Человеский фактор: успешные проекты и команды



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

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

Вывод: Прочитал и поставил на близкую рабочую полку по соседству с Макконнеллом и Бруксом.


Посты по теме:

• Фредерик Брукс, "Мифический человеко-месяц или как создаются программные системы"

Travis Swicegood, "Pragmatic Version Control using Git"

Travis Swicegood

Pragmatic Version Control using Git



Хорошее введение в распределенную систему контроля версий Git от сообщества разработчиков ядра Линукса и от Линуса Торвальдса в частности.

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

На официальном сайте есть превосходная электронная живая книга по Git. Многие главы имеют дельные коротенькие видео уроки.

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

P.S. Для интересующихся распределенными системами контроля версий рекомендую отличный блог про альтернативую систему Bazaar "Базарный день". Прочтете несколько постов и будете готовы использовать Bazaar.

Фредерик Брукс, "Мифический человеко-месяц или как создаются программные системы"

Фредерик Брукс

Мифический человеко-месяц или как создаются программные системы.



Как многие программисты, я весьма нетерпелив, и люблю как можно быстрее переходить к делу, а лучше — к реальным и осязаемым результатам. Поэтому с большим трудом читаю книги по профессии, где уж слишком много словоблудия, и особенно осторожен, когда кто-то пытается чего-то там теоретизировать. Я глубоко уверен, что кумиров "по умолчанию" в профессии иметь опасно, а лучше вообще не иметь, и любую веру в "крутизну" кого-либо надо проверять лично, поэтому я распечатал себе эту книгу (у меня получилось около 70 листов А4 с двух сторон), и решил полистать вечерком у телевизора.

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

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

Вывод

Два часа прочтения будут отзываться в вас еще долго, а необычные сегодня картины вычислительной техники "тех" дней только помогут кристаллизовать абсолютно актуальные до сих пор выводы Фредерика Брукса.


Посты по теме:

• Том Демарко, Тимати Листер, "Человеский фактор: успешные проекты и команды"

Чарльз Уэзерелл, "Этюды для программистов"

Лет пятнадцать назад мне в руки попала книга Чарльза Уэзерелла "Этюды для программистов".

Книга содержит 27 “этюдов”. Каждый этюд – это законченная задача для обучающихся программированию. Удивительно, книге более 30 лет, но любой из этюдов может быть до сих пор использован по назначению. Я сам с удовольствием давал этюды из этой книги студентам.

Тематика задач совершенно разная: ретроспективная задача по программе, которая печатает свой текст, игра Джона Конвея “Жизнь”, игровое и имитационное моделирование, интерпретаторы форматов и форматирование текста, статистический анализ карточных игр, символьные алгебраические вычисления, плавающая арифметика и работа с числами большой разрядности, математические методы взлома шифров, искусственный интеллект, машина Тьюринга, рекурсивные алгоритмы поиска, компрессия данных, эмуляция виртуальной компьютерной архитектуры, связывающий загрузчик, компилятор, интерпретатор символьного а-ля функционального языка и т.д. И все эти задачи времен, когда программировали на фортране с помощью перфокарт!

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

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

С различным успехом, но с огромным азартом, я возился в разные времена со всеми этюдами.

Был интересный эпизод с одним из этюдов. В главе 24, под названием “Секрет фирмы, или Математический подход к раскрытию шифров” описывается задача по взлому шифра Виженера (точнее, одной из его модификаций). В книге давался зашифрованный текст, описывался метод взлома и предлагалось расшифровать секретное послание.

И так меня эта задача торкнула, что я даже списался с одним из технических переводчиков этой книги. Тогда еще мне пришлось делать это по обычной бумажной почте России. У меня была масса вопросов, так как расшифровать предлагаемый в книге пример не получалось (математический анализ я тогда еще не изучал). Мне ответили, и среди всего прочего рассказали, как они сами (те, кто переводил книгу) расшифровывали. Ведь им, чтобы опубликовать это на русском языке, надо было иметь исходное сообщение, но в книге не приводился ответ, так что пришлось засучить рукава и заняться английской шифровкой:

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

Кстати, в интернете ходит много решений “этюдов” Уэзерелла. Например, программа, играющая в Калах, или интерпретатор символьного интерактивного языка TRAC.

Но теперь к самому главному.

Пару дней назад королевская почта доставила мне то, что я так давно мечтал полистать лично — это английский оригинал этой книги.

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

Если в мире программирования могут существовать иконы, то “Этюды для программистов” Чальза Уэзеррела одна из них.

Олег Цилюрик, Егор Горошко, "QNX/UNIX. Анатомия параллелизма"

Олег Цилюрик, Егор Горошко

QNX/UNIX. Анатомия параллелизма

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

Несмотря на присутствие слова QNX в названии книги, она является прекрасным руководством по программированию потоков в UNIX в целом. Начиная прямо от печки, то есть от определения потока и его порой неверного отделения от термина "процесс", далее, следуя по базовым способам синхронизации потоков (блокировки, семафоры, условные переменные), детально разжеваны все тонкости поточного программирования с точки зрения идей и концепций, и в конкретном применении их в потоках POSIX (pthreads), включая нестандартные расширения различных версий.

Отдельной строкой укажу на отличную главу про взаимодействие механизма сигналов UNIX'а и, собственно, потоков. Это весьма сложная тема, но тут она понятно расписана. Даны рекомендации “как надо” и “как не надо”. 

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

Даются сравнительные оценки работы потоков в различных UNIX'ах, например, QNX против Linux. Все плюсы и минусы обстоятельно, без эмоций разобраны. В конце книги рассматриваются некоторые чисто QNX'овые возможности: пулы потоков, и как QNX избавляет программиста от огромного количества головной боли при их использовании, методика программирования сервисов на основе сообщений (для QNX это вообще родная тема благодаря микроядру).

Авторы совершенно точно смогли сконцентрироваться именно на теме многопоточности, не тратя место в книге (всего ~280 страниц) на смежные вопросы, предоставив для “открытых” вопросов отличную библиографию.  

Есть книги, которые, как говориться, прочитал, передай другому, а некоторые уже не хочется никому отдавать. Это одна из таких немногих книг.

Павел Агуров, "Интерфейс USB. Практика использования и программирования"

Павел Агуров

Интерфейс USB. Практика использования и программирования

Очень целостная книга про USB от электрических основ и применяемых микросхем до написания драйверов под Windows. Я прочитал книгу на одном дыхании, и не пожалел ни капли о потраченном времени. Правда, если быть честным, то последние главы про написание драйверов под Windows я уже просматривал по диагонали, ехидно хихикая про себя на тему “как же можно было усложнить написание драйверов под винды…” и почему в libusb так просто и понятно даже с нуля, а в Windows DDK проще использовать всякие конструкторы драйверов для радикального сокращения времени “начального вхождения” в тему. Но это мои личные тараканы.

Прочитав книгу вы как минимум точно будете знать почему конкретно нельзя два компьютера просто взять и соединить обычным USB кабелем. Я, например, со своим программистским сознанием недоумевал раньше, мол почему если принтер можно подсоединить к компьютеру по USB, то почему же нельзя вместо принтера поставить другой компьютер, написав для него программу по аналогии с принтерной прошивкой, и организовать тем самым мини сеть? Это же просто вопрос драйверов (я так думал)… А тут меня заставляют покупать какой-то хитрый кабель с логикой внутри…

В общем, за себя могу сказать — я на капельку поумнел, что приятно.

А если серьезно, то прочитав эту книгу, можно спокойно самостоятельно “набросать” USB-устройство и написать для него драйвера по Windows.

Жалко, что в книге рассмотрено написание USB драйверов только под Windows. Было бы интересно написать один и то же драйвер под Windows и Linux, например, и оценить трудозатраты.

Дармаван Салихан, "BIOS. Дизассемблирование, модификация, программирование"

Не буду оригинален в посвящении некоторых постов книгам.

Дармаван Салихан

BIOS. Дизассемблирование, модификация, программирование (BIOS Disassembly Ninjutsu Uncovered)



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

Изложение материала сопровождается изобилием примеров программ и результатов дизассемблирования под винды и линукс.

Единственный вопрос, который, как мне показалось, остался за бортом — это альтернативы классическому подходу в простроении биосов на основе ядра линукса, а именно системы Coreboot, ранее известной как LinuxBIOS.

Резюме: крайне занимательное чтиво для занимающихся встраиваемыми системами, и вообще находящихся на стыке железа и софта.

И еще. Нельзя забывать о том, что книги надо не только иметь, но и читать.