оригинал на xkcd

Топ-3 повседневных вопросов программиста:

• как сделать Х,
• почему работает так, а не эдак,
• как назвать переменную.

С третьим вопросом всё понятно — он неразрешим в принципе. С первыми двумя интереснее.

Чтобы получить ответы, программисты девяностых читали исходники и руководства. Программисты двухтысячных начали активно гуглить. А затем в 2008 появился Stack Overflow, и стал «внешней памятью» для разработчиков. Теперь на 95% вопросов есть готовый ответ: первая ссылка из гугла на Стек.

Современные научные представления говорят о существовании у процессов функционирования человеческого мозга определенных особенностей, которые:

• на личном уровне подталкивают к прокастинации;
• в стартапе по мере его успеха и роста приводят к потере прежней творческой «внутренней атмосферы» и нарастанию бюрократии;
• в больших компаниях приводят к «иерархическому регрессу».

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

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

У Git есть строгие обязательства по обратной совместимости: многие продвинутые возможности скрыты за разнообразными опциями, а не применяются как поведение по умолчанию. К счастью, Git также поддерживает и алиасы, так что вы можете создавать свои собственные команды, которые делают всю характерную для Git магию. Под катом — подборка полезных (или как минимум забавных) алиасов, определённых в моём .gitconfig.

Вступление

В стандарте SQL описывается четыре уровня изоляции транзакций — Read uncommited (Чтение незафиксированных данных), Read committed (Чтение зафиксированных данных), Repeatable read (Повторяемое чтение) и Serializable (Сериализуемость). В данной статье будет рассмотрен жизненный цикл четырёх параллельно выполняющихся транзакций с уровнями изоляции Read committed и Serializable.

Для уровня изоляции Read committed допустимы следующие особые условия чтения данных:

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

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

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

— пусть лучше небольшая, но фейербаховская...
Виктор Пелевин «Поколение Пи»

Недавний релиз ядра Linux 4.9 отличный повод рассказать о предстоящем разгоне WiFi. Сразу оговорюсь — пост не о том, как увеличить зону покрытия или менять регуляторные домены. Ничего такого делать не надо, достаточно обновить ядро после того, как патчи буфероборца Dave Täht будут в стабильной ветке.

Значительное повышение скорости достигнуто за счет уменьшения задержки ^[1] и избыточной буферизации ^[2] в сети. Разработчикам пришлось ради этого перелопатить mac80211, убрать кое-что сверху, добавить снизу и после этого задержки в сети сократились на порядок. Цена вопроса? Патч в 200 строк. Подробности под катом.

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

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

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

Будет интересно выяснить, что их объединяет, в чем они противоречат другу другу. Возможно, их ответы помогут выявить какие-то общие закономерности, полезные советы, которые помогут многим из нас.

Сегодня наш гость — Константин Осипов, разработчик, основатель и руководитель проекта Tarantool. Константин рассказал, как ему удается совмещать пост разработчика ПО с должностью менеджера. Он также поделился своим списком литературы.

Примечание. «Зомбирование» в данном контексте — многократное повторение ложной и/или неточной информации.

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

1. Люди замечают вещи, которые уже укрепились в памяти или часто повторяются.
2. Люди склонны замечать и запоминать скорее особенные, причудливые и смешные образы, чем непричудливые или несмешные.
3. Люди склонны замечать изменения.
4. Людей притягивает информация, которая подтверждает их убеждения.
5. Люди склонны лучше замечать ошибки у других, чем у себя.

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

Это телевидение.

Кэш глазами «чайника»:


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

Давайте прокрутим полный оборот ситуаций.

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

Результаты опроса из прошлой статьи меня шокировали. Ведь когда разработчики берутся за проект без ТЗ, умирает один неоперившийся аналитик и 10 маленьких котят. Зачем вы так? Как же так получается?



Почему так происходит? Что можно сделать? Вот несколько версий:

Версия 1: боюсь потерять клиента

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

Даниил Подольский (Git in Sky)

Рассказ о том, что каждый инженер должен сделать в своей жизни после того, как он родил ребенка, посадил дерево и построил дом – это сделать свое файловое хранилище.

Доклад мой называется «Опыт построения и эксплуатации большого файлового хранилища». Большое файловое хранилище мы строим и эксплуатируем последние три года. В тот момент, когда я подавал тезисы, доклад назывался «Ночью через лес. Опыт построения эксплуатации бла-бла-бла». Но программный комитет попросил меня быть серьезнее, тем не менее, на самом деле это доклад «Ночью через лес».

На протяжении долгого времени я не до конца понимал htop. Я думал, что средняя загрузка [load average] в 1.0 означает, что процессор загружен на 50%, но это не совсем так. Да и потом, почему именно 1.0?

Затем я решил во всём разобраться и написать об этом. Говорят, что лучший способ научиться новому — попытаться это объяснить.

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

• Вы начинаете искать новую работу
• Новая работа начинает искать вас

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

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

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

Давайте разберём уровни зрелости ИТ-процессов на примере управления инцидентами. Это всё то, что сыплется на ИТ-отдел в виде тикетов от пользователей, шефа, текущих задач и всего, что надо сделать. Забегая чуть вперёд, скажу, что в среднем по стране у крупного бизнеса с инцидентами довольно хорошо, в большинстве случаев это 4-й уровень. Ну просто потому, что работа со сбоями — это первое, по чему судят об ИТ-отделе.

Первый уровень — это когда:

• ИТ-отдел работает без распределения обязанностей и специализаций. Все отвечают за всё (точнее, ни за что), принцип выбора исполнителя — «Вася, ты свободен, ну, сделай им там».
• Ответственности нет: если Вася забыл, непонятно, кому писать, непонятно, как и что на что влияет, пользователи вообще не разбираются, кто и что делает. И иногда бьются в истерике.
• Документации нет.
• Автоматизации нет (либо есть на уровне списка задач в блокноте).
• Пользователи почти всё решают по личным знакомствам, обращаясь к тем, кто им уже один раз помог.

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

Про grep знают если не все, то многие читатели Хабра, однако его многочисленных родственников знают немногие.

Давайте узнаем, как можно грепать все, что таит в себе хоть крупицу текста.

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

Александр Календарев ( akalend )

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

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

Залп скосил 50 офицеров и 760 рядовых. Французы дрогнули, запаниковали и — обратились в бегство. «Тут дела наши пошли не вполне хорошо», — описывает этот момент битвы официальная французская депеша.

Келли Дж. Порох. От алхимии до артиллерии.

Формирование Scrum команды всегда сопряжено со многими трудностями. Почти все справляются с тем, чтобы изменить порядок рабочего процесса и начать проводить некоторые из необходимых по Scrum событий. Но получить от этих формальных изменений видимую пользу и начать действительно менять рабочий процесс удается меньшинству. В результате у команды формируется следующее мнение о Scrum: “Мы без толку тратим время на митинги. Scrum не работает. Нужно что-то менять”.

Пытаясь как-то спасти положение, активисты Scrum вспоминают, что Scrum — это же еще и framework. Объявляется новая стратегия: “Мы не только Scrum, мы еще и Agile! Мы используем best practices, берем из Scrum только самое лучшее, то, что подходит конкретно для нашей ситуации, а все остальное лишнее и необязательно”. А раз так — “Мы — молодцы и все делаем правильно”.