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

Так какого же чёрта моё прекрасное IT превращается в детский сад «Весёлый Програм-Мишка»?

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

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

Представляем Яндекс.Телефон — это первый смартфон, который объединяет привычные приложения Яндекса в единую экосистему, в центре которой находится Алиса.

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

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

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

Но с такими возможностями часто приходит полное отсутствие уважения к участникам проекта других профессий. Это отсутствие уважения может оказаться настолько глубоким, что порождает в уме разработчика твёрдую уверенность, что он не только самый ценный участник программного проекта, но и необходим компании в целом. К сожалению, хотя лишь малое число разработчиков способны накапливать что-либо напоминающее богатство, многие ведут себя так, словно они следующие Марк Цукерберг, Билл Гейтс или Стив Джобс; хотя это очень далеко от истины. Это приводит к личностным проблемам, которые так же увлекательно наблюдать со стороны, как страшно созерцать в себе.

Читатели Хабра, в основном, люди интеллектуального труда и нередко наша жизнь ограничивается схемой «работа, дом, редкие посиделки с друзьями в кафе или баре». А если ещё есть заботливый работодатель, предоставляющий обеды, печеньки, снеки и напитки без ограничений, то всё, — привет, лишний вес. Конечно, среди нас есть фанаты бега, кроссов, марафонов, спортзалов и Iron Man, но их по-прежнему мало.

На Хабре нередко пишут про физические нагрузки, стоячие столы и прочие приспособления, но мы сегодня поговорим… о еде. Давайте отвлечёмся от работы, подумаем о своём здоровье и о пищевых привычках, а заодно выясним, не сгущаем ли мы краски. Тем, кто ест за компьютером — приятного аппетита!

Беговая дорожка, не поспоришь

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

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

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

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

Предисловие

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

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

Содержание

1. Манифест жёсткого программиста
2. Основополагающие принципы манифеста жёсткого программиста
3. Комментарии

Манифест жёсткого программиста

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

Концепция важнее новых требований
Качество важнее скорости
Делать как надо важнее, чем делать как просят

То есть, не отрицая важности того, что справа, мы всё-таки более ценим то, что слева.

На этой неделе пользователи Hacker News решили обсудить вопрос «Каков максимальный объем плохого — но при этом работающего — кода вам доводилось видеть?» (позже к ним присоединились и пользователи Reddit). В комментариях было рассказано немало «веселых» историй про то, с чем мы все время от времени сталкиваемся; но больше всего внимания привлек рассказ про код «передовой СУБД, которую используют большинство компаний, входящих в список Fortune 100».

Победителем в номинации «лавкрафтовские ужасы» заслуженно стал рассказ бывшего разработчика Oracle, который работал над Oracle Database в период разработки версии 12.2. Объем кодовой базы СУБД на тот момент составлял 25 миллионов строк на языке C — и стоило вам изменить лишь одну из этих строк, как ломались тысячи написанных ранее тестов.

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

Ну привет. Я только что с собеса, и у меня бомбит. Сколько не пишут на Хабре, как правильно собеседовать — лучше не становится.

Мне кинули предложение — Senior full-stack .NET Developer, удаленно, крутой проект, куча денег. В списке требований хренова гора не связанных между собой вещей из мира .net и js/ts. Выглядит так, будто просто свалили в кучу все, что нагуглили за 10 минут — причем мало понимая, что именно.

Тревожно, но ничего. Собеседовать, думаю, будет разработчик — человек, с которым я говорю на одном языке. Расскажу про то, что делал, обсудим подходы к решению задач, проблемы в .NET, перспективы C#. Поговорим про структуры данных. Расскажу, почему структурная типизация мне нравится больше, чем мнемоническая. Если пойдет хорошо, поделюсь даже своей идеей фикс — всегда использовать структуры вместо классов в качестве моделей. Посравниваю FLUX с MVVM, расскажу, как нереально красив симбиоз ФП и ООП в TypeScript.

В общем, предвкушаю хороший разговор.

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

Как известно, в 2018 году компания Google провела крупнейший редизайн интерфейса своего почтового сервиса Gmail. Как обычно, довольны им оказались далеко не все — и на этот раз есть вполне объективные причины для недовольства сервисом. Почему загрузка Gmail стала занимать очень много времени, а действия вроде удаления или архивирования цепочки писем могут выполняться 4-6 секунд?

Пару дней назад подобным вопросом задался пользователь Hacker News — и он получил ответ от анонимного сотрудника Google, хлестко проехавшегося по культуре разработки внутри компании и своим коллегам.

С его слов, все это происходит в силу того, что в Google не предусмотрено никаких наказаний за подобные «промахи».

В стенах компании активно поощряют запуски (launch) — публичные релизы чего-либо. И то, что продукты могут содержать лишь половину необходимых фич, не работать, работать только из-под Chrome и прочее — это никого не волнует, ведь их создателям за это ничего не грозит. Это — норма.

Следующий доклад с Pixonic DevGAMM Talks, который мы расшифровали, немного философский — это выступление Константина Гладышева. Он Lead Game Programmer в 1C Game Studios и рассказывал о принципе управления сложностью разработки в контексте всего продукта, а не отдельных фичей. И на примерах показал, почему главное в разработке — это определить, чего делать не надо. Про другие доклады можно почитать по ссылкам в конце статьи.

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

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

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



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

Итак, обо всем по порядку.

Спам в социальных сетях и мессенджерах — это боль. Боль и для честных пользователей, и для разработчиков. Как с ней борются в Badoo, рассказал Михаил Овчинников на Highload++, далее текстовая версия этого доклада.


О спикере: Михаил Овчинников работает в Badoo и последние пять лет занимается антиспамом.

В Badoo зарегистрировано 390 миллионов пользователей (данные на октябрь 2017). Если сравнивать размер аудитории сервиса с населением России, то можно сказать, что в нашей стране по статистике каждых 100 млн человек охраняет 500 тысяч полицейских, а в Badoo каждые 100 млн пользователей защищает от спама всего один сотрудник Антиспама. Но даже такое небольшое количество программистов способно защитить пользователей от разных неприятностей в интернете.

Примечание переводчика: визит под кат этого поста означает большие объёмы потреблённого трафика. И это иронично, если учесть поднятую тему. Но всё сразу встаёт на свои места, если помнить, что в оригинале это было выступление в прошлом ноябре в Сиднее длиной почти в час. Чтение поста занимает куда меньше времени. В форме видеозаписи (1280×720) речь занимает два гигабайта. Пост же занимает всего лишь 12 МиБ. Рекомендуется просмотр на широких мониторах.



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

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

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

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

KDE — организация и международное сообщество вокруг нее, разрабатывающее свободное программное обеспечение: среду рабочего стола Plasma и набор приложений KDE Applications. Основным источником средств для проекта служит сбор пожертвований и целевые кампании по фандрайзингу.



15 октября 2018 некоммерческая организация KDE e.V., курирующая развитие проекта KDE, сообщила о получении пожертвования в $300 000 на 22-летие проекта от другого сообщества энтузиастов — Handshake.org. Причем 100 тысяч долларов, из полученных 300 тысяч, пойдут на развитие свободного офисного пакета Calligra.

22 сентября мы провели Backend United #2: Фарш — встречу, посвященную тестированию бэкенда. Говорили о приемах тестирования бэкенда, его отличиях в разных языках. Обсуждали CDC-подход к тестированию микросервисов — почему в Авито используют нативные тесты, написанные на языках сервисов-потребителей. Рассказали о механике и сложностях внедрения Pact — наборе библиотек, которые реализуют Consumer-Driven Contract подход в тестировании API. И узнали, как в микросервисной архитектуре создать честные и эффективные изоляционные тесты.

Под катом делимся впечатлениями, фото, видео, презентациями со встречи и отзывами слушателей.

В последние недели участилась волна статей на хабре о том, как проводятся собеседования.

Google ищет инженеров постоянно. Как SRE, могу точно сказать, что вы нужны в наших рядах. Печеньки на мини кухнях и кофе в кофемашинах ждут вас. Всего-то нужно пройти собеседование. Это сложно, но реально — когда-то я уже описывал свою историю как соискателя, а сейчас уже в числе прочего занимаюсь и проведением собеседований. Так что сейчас я расскажу, как мы проводим собеседования с инженерами.

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

Прим. перев.: Автор оригинальной статьи — Théo Chamley, архитектор облачных решений Google. В этой публикации для блога Google Cloud он представил краткую выжимку из более детального руководства его компании, названного «Best Practices for Operating Containers». В нём специалисты Google собрали лучшие практики по эксплуатации контейнеров в контексте использования Google Kubernetes Engine и не только, затронув широкий спектр тем: от безопасности до мониторинга и журналирования. Итак, какие практики в работе с контейнерами наиболее важны по мнению Google?