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

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

Введение

Есть несколько статей об антипаттернах разработки ПО. Но большинство из них говорят о деталях на уровне кода и фокусируются на конкретной технологии или языке программирования.

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

Терминология

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


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

• «Забытый слой пирамиды автоматических тестов» (Майк Кон, 2009)
• «Пирамида тестов» (Мартин Фаулер, 2012)
• «Блог отдела тестирования Google» (Google, 2015)
• «Пирамида тестов на практике» (Хэм Фокке, 2018)

Одним из параметров оценки кода служит его чистота. Создатель языка моделирования UML Гради Буч (Grady Booch) писал:

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

Сегодня мы собрали для вас список книг и статей по этой теме, которые рекомендуют к прочтению резиденты Hacker News, Stack Exchange и других профильных платформ.

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

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

Перед вами – небольшой список полезных приёмов работы с командной строкой Linux. С некоторыми из них вы, возможно, уже знакомы, но успели их позабыть. А кое-что вполне может оказаться приятной находкой даже для знатоков. Хочется надеяться, что некоторые из них будут вам полезны и превратятся из «списка» в живые команды, которыми вы будете пользоваться каждый день.

Введение

Вот не люблю я изобретать велосипед и статью я бы эту не написал, но пришлось. Про REST сказано уже довольно много. Многие поставщики веб служб готовы клясться, что их службы являются RESTful. Во время собеседования вы точно услышите хотя бы несколько вопросов про REST, независимо от того это собеседования для бэкенд, мобайл или фронтенд разработчика. Я вот помню как-то во время одного собеседования меня задали такой вопрос: «Вот вы написали в своем резюме, что знайте REST․ Ответьте пожалуйста, какой HTTP код вы получите, если при запросе к RESTful сервису ресурс не найден?». Ответ 404 был принят единогласно. Если честно, я так и не понял, как этот вопрос помог понять знаю ли я REST или нет, но одно могу уверенно сказать: REST понимают далеко не все. Вот некоторые вопросы, которые мучали меня долгое время:

1. Зачем REST стал таким трендовым? Это архитектура была же предложена еще в 2000 году?
2. Что я получу если моя служба будет RESTful?
3. Как определить является ли служба RESTful или нет?
4. Как правильно должны создаваться URL REST служб?
5. Какие http методы и коды должны быть использованы в RESTful службе?

Если вы не можете дать исчерпывающего ответа хотя бы на один из этих вопросов, то продолжайте чтение. Если вы можете однозначно ответить на все эти вопросы, можете привести формат правильного URL, считайте, что GET, POST, PUT, DELETE обязательно должны соответствовать CRUD операциям с ресурсами, то вам обязательно надо продолжать чтение.

Всем привет!
Я думаю, что многие слышали о Google DeepMind. О том как они обучают программы играть в игры Atari лучше человека. Сегодня я хочу представить вам статью о том, как сделать нечто подобное. Данная статья — это обзор идеи и кода примера применения Q-learning, являющегося частным случаем обучения с подкреплением. Пример основан на статье сотрудников Google DeepMind.

На просторах интернета часто доводилось видеть мнения, что де "нейросеть — панацея от всего и вся", т.е. например "натравите нейросеть — и все, профит" или еще брутальней "скоро создадут ИИ на базе нейронной сети, которая сможет заменить даже программистов / администраторов / аналитиков и т.д.".

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

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

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

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

Хотя вдруг это я таки нещадно отстал от жизни...

Один из принципов дизайна в Atlassian — лаконичность. В ходе эволюции UX некоторые непопулярные действия, расчитанные на опытных пользователей, были спрятаны в выпадающих списках или за горячими клавишами. Там они ждут предприимчивого пользователя, который случайно наткнётся на них благодаря случайному нажатию клавиш или клику мышки (ну, или заглянет в руководство). Вот шесть моих любимых трюков Bitbucket Cloud, о которых вы, возможно, никогда не слышали:

Омнибар

Омнибар в Bitbucket — это строка быстрого доступа к действиям, похожая на ⇧⇧ в средах разработки JetBrains или ⌘+P в Sublime Text. Запустить омнибар можно на любой странице, нажав клавишу точки.

По умолчанию, он покажет набор действий, соответствующих текущему контексту:

По просьбе tulskiy делаю вольный перевод частей официальной документации GitHub'а Fork A Repo и Send pull requests.

Итак, что же такое «запрос на включение (сделанных вами изменений)» (именно так я перевёл pull request)? В официальной документации гитхаба говорится следующее:

Pull request'ы позволяют вам рассказать другим о тех изменениях, которые вы разместили в своём GitHub-репозитории. Как только pull request отправлен, заинтересованные стороны рассматривают ваши изменения, обсуждают возможные правки или даже добавляют дополняющие коммиты, если нужно.

Говоря своим языком: Посылая pull request, вы говорите автору изначального репозитория (и всем заинтересованным лицам): «Смотрите, что я сделал, не хотите ли принять мои изменения и влить их в проект?»

Когда я* говорил, что нужно вкладывать в сообщество и User Groups, вы вкладывали в теннисные столы. Теперь у нас много средненьких теннисистов и нет коммюнити.

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

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

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

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

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

Предлагаю читателям «Хабрахабра» перевод заметки «Maslow's Hierarchy of Needs of Software Development», которую я нашел в блоге Скота Ханселмана.

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

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



Недавно я общался с заказчиком, где один хороший человек большей частью был озабочен стилем кода: расположением фигурных скобок, применением проверенных решений («best practices») в дизайне интерфейсов и еще кучей важных, но едва ли критичных вещей. В то же время в их организации не было поставлено модульное тестирование («unit-testing»), развертывание («deployment») проводилось вручную, а сборки были слабо верифицируемыми («verifiable build»).

Говоря иначе, он был сосредоточен на проблеме «достаточно ли я потребляю витамина А?», упустив из виду проблему «есть ли у меня вообще что приготовить к ужину?».

Я подумал: что если спроецировать пирамиду потребностей Маслоу на нашу предметную область — разработку ПО? Под катом пример того, что у меня получилось (благодарю Фила Хаака, Джона Галлоуэя, Джонатана Ванагела и Пола Стовела за участие в «мозговом штурме»).