Книги: Penetration Testing Basics

Penetration Testing Basics
Ric Messier.
Penetration Testing Basics: A Quick-Start Guide to Breaking into Systems.
Apress, 2016.
Очень оптимистичный подзаголовок у книги. А вот заголовок достаточно честный.
Предположим, что вы совсем ничего не знаете о взломе систем. Болтается сервер в проруби, а вы задумчиво на него смотрите, не представляя даже первого шага. В таком случае эта почти брошюра (всего 120+ страниц) послужит очень, очень общим введением в занятие. В каком-нибудь ультимативном учебнике заняло бы первую главу, наверное, а то и пролог.
Целевая аудитория точно не включает в себя разработчиков. Читал потому, что под руку попалось, ну и раз начал, надо долистать хотя бы. Возможно, продвинутым пользователям будет интересно.

Miscellanea I

Бизнес, построенный на чужом API, очень хрупкий. Мало того, что даже топовые корпорации не всегда озабочены сохранением совместимости, так иногда просто гасят то, что считают негодным. Примером тому Facebook Public Post search API, после отмены коего не один сайт схлопнулся. Также интересное получается тогда, когда “модераторы” на стороне API решают, что приложение не норм: Instagram передаёт привет общественности. В общем, суровый и злобный бизнес, в котором никто никому ничего не должен.

Чтение всякого — хорошая прививка от “так не делают” и “так не бывает”. Считаю, у разработчика такие фразы равны “не могу знать”, старательно выбиваемому Суворовым. В разработке всё можно, если под этим всем есть хорошее обоснование. Помни, что до тебя по этому лесу уже ходили миллионы. Шишки набиты, собраны, сварены. Не использовать чужой опыт глупо. Не видеть и не учитывать чужой опыт потому, что построил в голове карцер и спрятался в нём — глупо вдвойне.

Одна из поучительных историй, за которой стоит приглядывать — отношение к goto statement. Эдакий маркер бездумного следования за, если разработчик остервенело кидается. Если подумать, то…
Во-первых, Dijkstra (все же читали эссе, с которого началось, правда?) допускал использование goto в машинных кодах [читай “на низком уровне”]: “the go to statement should be abolished from all “higher level” programming languages (i.e. everything except — perhaps — plain machine code)”.
Во-вторых, народ проголосовал практикой против теоретиков. В C-коде по сию пору goto используется вполне активно, достаточно грепнуть Linux kernel.
В-третьих, массовый контраргумент goto в том, чтобы не делать код лапшой. Это… кхм. Как дела с break и return, например? Ах, они называются иначе. Ну так поинтересуйтесь, в какие инструкции зачастую компилируются такие вот выходы.
Не первый раз упоминаю goto, но что поделать, если исторически ему не повезло. Короче, как обычно — полезно сначала думать, а потом идти.

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

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

Книги: Кто сказал, что слоны не умеют танцевать?

Кто сказал, что слоны не умеют танцевать?
Луис Герстнер.
Кто сказал, что слоны не умеют танцевать? Возрождение корпорации IBM: взгляд изнутри.
Альпина Паблишер, 2003.
Блог про разработку, книга не про разработку. Такое будет бывать. Но это же IBM, а про них всегда интересно читать — корпорация, прошедшая путь от помощи нацистам до Watson. А тут ещё и книга от главного директора, который спасал IBM от развала в 90-х.
Но я ошибся. Текст скучный.
Во-первых, Герстнер написал его для очень, очень массовой аудитории. Потому нет ничего, чего не понял бы даже ребёнок из детского сада. Ни какой-нибудь экономической специфики, ни технической, ни организационной. Вообще нет хоть сколь сложных деталей. Пара мазков в каждой главе, но и только.
Во-вторых, Герстнер не инженер. Он был топовым руководителем IBM, осматривающим область с той высоты полёта, на которую инженерные сведения не забираются. Что там с Deep Blue? Какие проблемы были у мейнфреймов? Как при отказе от OS/2 сохранилась IBM PC DOS? И ещё тысяча других занятных тем не упомянута в книге.
В-третьих, вроде и теоретически интересные штуки рассказывает, но можно на пять минут выключиться, потом включиться и ничего не потерять, ибо рассказывает так отдалённо от личностей и конфликтов, с таким фильтром на конкретику… короче, заменить IBM в книге на любую другую корпорацию и ничего не изменится. Перевернул культуру. Предотвратил децентрализацию. Переставил людей. Продал часть бизнеса. Купил часть бизнеса. Были проблемы, но мы с ними справились. Сотрудников воодушевил. Молодцы у меня сотрудники, кроме тех, кто не молодец. IBM рулит.
Потому рекомендация “не читать”.

Сперва добейся

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

Что такое технически годный сложный продукт? Всего три варианта.
Во-первых, тот, что годами живёт в офигиллиардах production’ов, выполняя свою работу в режиме пяти девяток, образно говоря. Пример: ядра операционных систем.
Во-вторых, тот, что годами живёт в production’е без вмешательства человека. И да, выполняет свою работу в режиме пяти девяток, всё так же образно говоря. Пример: софт того, что земляне в космос извергают.
В-третьих, тот, что выживает в стрессовых условиях окружающей среды при огромной цене ошибки. И… вы поняли. Пример: военный, авиационный софт.
Почему именно эти “отрасли”? Если вы хоть час потратите на глубокое размышление о том, что за задачи там возникают и какие требования к решениям, поймёте простое: всё плохо. Ограничение по ресурсам. Максимум устойчивости (в страшном сне ребут Боинга на высоте 10К метров, ага). Особые требования (вспышка слева, кладбище справа). При этом бывает адок огромных кодовых баз (Boeing 787 Dreamliner = ~7M LoC, например) с адком интеграции сотен и тысяч модулей систем. Жёсткое следование стандартам. Всё такое.
В общем, вне зависимости от того, что об этом думаете вы, описанное выше является Skills Challenge промышленного программирования. И код, который всё это успешно делает, является кодом для изучения и подражания, если хотите писать продукты такого уровня.
При чём тут “сперва добейся”? Все интеллектуальные разговоры о том, что такое правильный и удобный язык, в каком стиле писать код, каким гайдам следовать и т.п. — они до первого хардкорного проекта. И стоят копейку, не больше. Граница там же, где граница между строителями пальмовых хижин в няшном климате райских островов и строителями командных центров РВСН в условиях Ямала. Достаточно даже не делать самому, но вдумчиво изучить проблемы и решения, чтобы многое понять.
И что? Да то, что вон те ребята, которые ввели в эксплуатацию КЦ РВСН — они добились, они сделяль. Им как-то уж точно виднее, что и как правильно в согласовании с реальностью. Если они используют какую-нибудь конструкцию языка, от которой вас воротит, значит, проблема не в конструкции языка. Если они используют язык, который вы считаете неправильным, значит, проблема не в языке. Если вы видите в их архитектуре, методах, стиле что-то, что вы считаете неправильным… ну, докажите обратное. С их стороны конструкция, которая выдержит падение Луны на маковку. С вашей стороны морщины несогласия на лбу и опыт тысячи хижин на берегу у голубой водички.
Фиг с ним, с делом, накопайте и покажите что-то, что делает то же с тем же результатом, но удовлетворяет вашему вкусу. Linux kernel на JavaScript (а не этом страшном C). Спутник связи на Python (а не на этом головоломном C++). Ford GT на Ruby, наконец (к слову, у Ford GT количество LoC в mission critical code на ~3M больше, чем у Боинга). Это замечательные выразительные языки. На них вы можете легко и быстро писать годный софт. В них нет нелюбимых вами конструкций. Всё для того, чтобы попа у разработчика была мягкой и шелковистой.
Нет? Не получается? Внезапно оказывается, что няшные конструкции — это ни фига не то, что следует считать приоритетом? Или “ну это же языки НЕ ДЛЯ ЭТОГО”? Тогда не надо вилять попой под обстрелом. Надо в дискуссиях честно и сразу ставить шашки на место: “я, Семецкий Юрий Михайлович, считаю, что мой любимый язык является удобным языком для строительства пальмовых хижин, а конструкция XYZ великолепна для вкапывания брёвнышек в песок”. Попутно добавляя шёпотом, что эти же любимые языки Семецкого не являются универсальными или, как минимум, гораздо менее универсальные, чем C/C++. И что все эти рассуждения о том, что УДОБНО и что ПРАВИЛЬНО — они валидны лишь в ясно обозначаемом контексте. И вся болтовня без “сперва добился” так и остаётся пустой болтовнёй, ибо, повторюсь, первый же проект сурового уровня меняет мышление разработчика, после чего и на goto смотрят крайне спокойно и прагматично. А если мышление не меняется, разработчик с Ямала едет к пальмам.

Уф. Хау. Я сказаль. Иногда здорово достают нападки на C/C++, от чего у меня поводок обрывается.

Антиода фронтендерам

К фронтендерам у меня крайне двойственное отношение, отдающее шизофренией.
С одной стороны вне работы они норм. Ну т.е. люди как люди. Бывают очень годные, бывают очень упоротые. В целом совпадает с распределением по популяции разработчиков.
С другой стороны в разработке… Мне кажется, многие больны. Когда от меня хотят чего-то странного и плохого, почти всегда это оказывается либо менеджер (чем дальше от разработки, тем больше бабушка в режиме “а чё, вот кнопочку нажать не поможет?”), либо фронтендер (в режиме “да чё, вот тут костыль, сюда костыль, а сверху штукатурка, мы всегда так делаем”).
Когда начались проблемы? Когда верстальщики стали фронтендерами, да будет проклят Node.js, прорубивший им это окно. О, сказали верстальщики, теперь мы можем писать на JavaScript все утилиты и даже бекенд! Мы всё можем на нём написать! И ведь пишут. Казалось бы, что в этом такого?

Во-первых, по теоретической подготовке фронтендер не является программистом. Если даже когда и являлся, ему не зашло, потому он ушёл в мир выпадающих списков и теней под менюшками. В этом мире не нужны знания алгоритмов, процессоров, операционных систем и т.д. Есть макет (обычно нет), есть зоопарк браузеров, да и всё. Если человек с таким background’ом берётся писать бекенд, в 99% случаев на результат нельзя смотреть без ящика пива. И вы лоб сломаете в попытках объяснить, почему одной бутылки мало. Вас не поймут. НУ РАБОТАЕТ ЖЕ! ЧЁ НЕ ТАК?!
Во-вторых, JavaScript не воспитывает хороших разработчиков. Опять же, потому, что этот язык никогда не предназначался для разработки вне браузера и никогда не предназначался для разработки больших сервисов. Сейчас он почти идеален для “полезные скрипты на два-три экрана” и для “хочу попробовать программировать”, во всём остальном выкапывает мозг тем глубже, чем больше строк вам надо отладить, собрать и выкатить. Да, с этим справляются. Но чуваки на классических языках бекенда с меньшими усилиями справляются на гораздо, гораздо бОльших кодовых базах.
В-третьих, культура фронтенда — это культура “раз в полугодие мы всё переписываем” и “ой, у нас новый фреймворк, уииии!”. В итоге нет привычки доводить продукт до состояния продукта. Зачем, если завтра вы выкидываете то, что написали сегодня? Это же является одной из причин, по которым костылизация становится нормой. Зачем неделю писать правильный железобетонный код, если завтра всё поменяется, а костыль можно написать за час?
В-четвёртых, мир браузеров — джунгли. Я вообще не понимаю, как можно остаться в здравом рассудке и продолжать что-либо делать в условиях “это работает в X, не работает в Y, странно тупит в Z, а в A и B работает, но не так, но надо, чтобы везде хоть как-то работало, при этом вчера”. Нет ничего удивительного, что этот мир порождает орды Маугли и Тарзанов, успешно действующих в доисторических условиях, но фигово творящих в условиях цивилизации. Как если бы в Нью-Йорке рубить пальмы и делать из них телеги. Да, телега поедет (задача решена), но блин, чувак, это Нью-Йорк и 2016 год.
В-пятых, фронтендеры являют собою апофеоз подхода “я ничего не буду системно учить, погуглю и со Stackoverflow стырю решение”. Может, мне так везёт. Не знаю. Но, образно говоря, если из десяти бекендеров одного точно можно уговорить прочитать спецификацию или учебник (и он прочтёт), то из сотни фронтендеров спецификацию попробует осилить один, да и тому будет скучно, если чаем с мёдом не поить и не уговаривать “заинька, ну ещё страничку, ну за папу, за маму”.

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

Ад сложного софта

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

В мире железа как-то ушли уже от ручного переключения джамперами на плате в эпоху “вставь и играй”. Допёрли, что человеку ну вот ни фига не в кайф возиться с тараканами стопицотой железки в его жизни. В мире софта как был ад, так и продолжается ад, так и будет ад.
Сначала ты тратишь заметное A дней жизни на то, чтобы хоть как толково поставить и настроить какое-нибудь поделие. Потом тратишь B дней жизни на то, чтобы понаступать на грабли эксплуатации поделия. Потом тратишь C дней жизни, чтобы втянуть в полушария все пути обхода этих и других граблей, становишься хотя бы middle по эксплуатации поделия. Вроде жизнь нормализуется…
Но нет! Потом эти боевые римляне выпускают новую версию своего поделия, обязательно major, обязательно с кучей изменений! И ты тратишь D дней своей жизни, чтобы мигрировать на новые грабли. Потом тратишь E дней своей жизни, чтобы ещё что-нибудь. И вроде как успокаиваешься…
Но нет! Мода не стоит на месте. Тех же баз данных до фига. Вот тут у нас MongoDB, тут MySQL, тут PostgreSQL, тут ещё какая-нибудь xxxDB и yyySQL. Потому надо для каждой подолбени проходить один и тот же цикл.
Также надо учитывать, что любая хоть сколько серьёзная система состоит из нескольких взаимноинтегрированных систем, ну и в любом процессе разработки продукта участвует ещё стопка систем (начиная от компилятора и системы сборки, заканчивая системой выкатки в production). У каждой свои грабли. На стыке каждой пары всегда возникают свои грабли. И вы снова тратите F, G, H и даже I дней жизни, чтобы обойти, настроить, поднять, удержать, не уронить, заставить работать хоть каплю быстрее.
Офигенно мотивирует то, что уже через год-два эти знания и умения устареют. Мало того, что в работе разработчика и так каждый год постоянная дань забвению отдаётся (ну вот не запомнишь навечно всё, что через себя пропускаешь), так ещё и то, что помнишь, никому нафиг не надо будет. А каждые пять лет стек обновляется ваще совсем так, что жизнь с нового листа. У толковых нанимающих, кстати, нередко негласное правило смотреть только на последние 3 года работы. Всё, что до этих 3 лет, смысла уже не имеет.

Так вот. К чему весь этот стон, что я песней считаю? Подзадалбывает. Хочу, чтобы софт ставился одной кнопкой, поднимался одной кнопкой и опускался одной кнопкой. Чтобы софт делал ровно свою работу, а не гадил мне в мозг “а ещё я кофе могу сварить”. В жопу иди со своим кофе, просто реализуй своё предназначение так, чтобы я мог забыть о твоём существовании. Чтобы не требовались специальные люди, у которых специальные знания и специальные бумажки вида “я год жизни убил на то, чтобы крутить колесо швейной машинки в нужном ритме”.
Но вектор такой, что в будущем мы ещё увидим дипломированных специалистов по “профессиональному созданию таблицы в базе данных путём применения всего лишь 146 команд и флажков”. Вот именно так и будет. Я уверен.

Книги: Программирование на C для начинающих

Программирование на C для начинающих
Майк МакГрат.
Программирование на C для начинающих.
Эксмо, 2016.
Она же “C Programming in easy steps” 2012 года. От автора, подарившего миру 20+ книг категории “Что-нибудь in easy steps” — XML, PHP, Linux, CSS, Perl, Unix, jQuery и т.д.
Фиговенькая книжечка, особенно начинающим. Не знаю, какую пользу из неё может извлечь начинающий, разве что научиться со страницы копипастить исходник и компилировать его.
Нет объяснений происходящего. Также нет сравнения с аналогами в других языках. Нет связи с железом, с алгоритмами, с культурой программирования, с проектированием, с чем-либо вообще. Текст подаётся в вакууме.
Слишком поверхностный охват материала. Да, я понимаю, что easy steps, но блин, настолько.
Отдельно доставляют скриншоты виндового терминала с результатом компиляции и запуска. Перед каждым заботливый пункт вида “Сохраните файл, а затем запустите программу, чтобы увидеть результат выполнения ..” — и так в каждой главе.
Русский перевод заслуживает отдельного. Как пример красоты канцелярита, вот про &&:

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

Заснул и захрапел. Можно бы сказать, что придираюсь, но так вся книга. Абсолютно вся.
В сумме с переводом и крайне разреженной вёрсткой текста… русскому изданию однозначно отказать, американскому изданию просто отказать