Введение

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

Наиболее часто для фиттинга данных используется линейная функция:

$$

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

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

Содержание

• 1. Антипаттерны: плохое обоснование
  
  • 1.1. Очевидно же
  • 1.2. Мамой клянусь!
  • 1.3. Зайчики обиделись
• 2. Хорошие паттерны обоснования
  
  • 2.1. Пруфлинк
    
    • Ссылка на требования
    • Сами требования
    • Ссылка в интернет
    • Письмо заказчика
    • ROI
    • Статистика
  • 2.2. Единообразие
  • 2.3. Проблема, или #жизньболь
• 3. Когда обоснование не нужно
• 4. Итоги

Когда вы заводите задачу, ее нужно обосновать. Вы должны убедить разработчика, что:

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

А то иногда читаешь баги (особенно баги новичков) и задаешься вопросом:

— Почему это баг??

Например, там написано: «Загружаем отчет, получаем 57,6. А должно быть — 57.9».



Если записать обоснование, это решит проблемы:

• Коллеги отвлекают с вопросами «А почему это баг?», вырывая из контекста.
• Спустя месяц ты сам забыл, а, собственно, почему это был баг…

См также:
Зачем нужно обоснование в баге — более подробно о том, зачем вообще обоснование.

Через меня прошли сотни начинающих тестировщиков (студентов). Вот как раз на их задачах я и начала задаваться вопросом «А почему это баг?»… Спрашиваешь ребят, а в ответ получаешь «Да это же очевидно!». Ну как-то не очень =))

Через кучу задач и вопросов «А почему?» стали вырисовываться паттерны ответов. Я выделила хорошие и плохие паттерны. О них и хочу рассказать.

Эта статья для:

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

1. Антипаттерны: плохое обоснование

Вы готовы к новым нагрузкам? Приглашаем всех любителей и профессионалов на чемпионат по проектированию и администрированию высоконагруженных сервисов HighLoad Cup #2!

Начало соревнованию было положено еще в прошлом году. Тогда мы знали, что HighLoad Cup — это именно тот чемпионат, которого не хватало в ряде проектов Mail.Ru Group. В первом пилотном соревновании участвовало 449 человек. Было много кода и много пота как у самих организаторов, так и участников (8789 различных решений). Были нюансы в технической реализации, но главное, что всем понравилось! Организаторы провели множество ночей в датацентре, несколько выходных — в офисе. Готовы к этому снова! В конце статьи вы найдете полезные материалы от нас и от участников, которые помогут вам разобраться в механике и найти какие-то best practice-решения.

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



Итак, добро пожаловать на борт!

Привет, сообщество! Мы в Хекслете составили список из пяти бесплатных автоматизированных онлайн-платформ для новичков.

На русском:

HTML Academy
«Академия» учит верстать сайты. Основной контент в формате подписки (390 рублей в месяц) и интенсивов (от 12500 рублей), но есть несколько бесплатных автоматизированных курсов по основам HTML, CSS и JavaScript.

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

Code Basics
Это новый бесплатный сервис от Хекслета. Его основная идея — через решение простых заданий прямо в браузере погружать новичков в основы программирования. Сейчас есть уроки по PHP, JavaScript и Python, ближайшее время появятся — новые. Платформа подойдет лучше всего для изучения основ синтаксиса, и меньше — для прокачки алгоритмов.

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

Среди проектов отдела образования Mail.Ru Group — учебные программы в 7 ведущих технических вузах, включающие 200 IT-дисциплин, более 17 онлайн-курсов, 9 IT-чемпионатов и около 1000 обучающих видео на YouTube-канале Технострим.

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

GitHub – крупнейшая библиотека, созданная разработчиками для разработчиков. Главная прелесть хостинга в его идеологии: отдавать также легко, как и получать. Здесь можно найти самые разные IT-проекты как легальные, так и не совсем. Пользуясь открытостью, кто-то роется в исходниках в корыстных целях – чтобы потом использовать их уязвимости для банального шантажа, а кто-то с помощью репозиториев прокачивает свои профессиональные скилы. Давайте разберемся, как не закопаться в миллионах источников и какие перки можно заполучить.

То, что знания не принадлежат лишь узкому кругу избранных, уже признают и транснациональные корпорации. На основе одного исходного кода вырастает несколько новых – так и развиваются технологии, которыми в итоге начинает пользоваться весь мир. Такие гиганты, как Apple, Google, Facebook, Microsoft – разместили и продолжают постоянно обновлять свои репозитории на GitHub. Да что уж, если даже Министерство обороны США заводит хранилище на хостинге https://github.com/Code-dot-mil/code.mil с лозунгом «Помогите нам стать лучше». И каждое новое предложенное полезное решение – это очередной выученный урок в карьере разработчика.

Формат open-source проектов хорош тем, что позволяет участникам общаться также, как мы делаем это в социальных сетях. Помните про принцип соревновательности! К примеру, некто постит вариант реализации идеи. Другие участники, на интересе, либо желая покуражиться предлагают хаки. В итоге – сообщество плюсует авторам лучших решений.

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

Привет. Меня зовут Иван Мельничук, я Head of Development Department в украинской IT-компании. В публикации хочу поделиться личными профессиональными подходами относительно решения вопроса legacy code в условиях стремительного развития проекта и рассказать о приемах, к которым прибегает наша команда в случаях “когда фичи нужно сдавать “на вчера”.

Разбираемся с проектом

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


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

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

Российское отделение PMI опубликовало исследование зарплат РП за 2017 год ещё в июле этого года, а на Хабре этот вопрос никак не обсудили. Поделюсь своими впечатлениями. В отличие от глобального исследования (Pulse of the Profession 2018) в российском исследовании есть особенности:

За основу взята не зарплата, а общий доход. За основу взяты числа получаемые на руки, а не до уплаты налогов. Добавлен ряд данных интересных для России — разрез по городам и “белизна” дохода.

Нет, я не собираюсь рассказывать, как написать своего шифровальщика-вымогателя, майнера или эксплуатировать супер-новую уязвимость, как вы могли подумать. И тем более я не горю желанием поднимать холивар «Linux безопаснее Windows?(да)». Моей целью было написание простого вируса для linux, некого, так сказать, «Just for Fun», единственной функцией которого является распространение своей копии. О том, что у меня получилось, я расскажу в этой статье. В конце я приведу ссылку на GitHub с исходниками.

Предисловие для читателей Хабра — статья о поиске работы на рынке разработки в Украине (который в основном об аутсорсе на иностранных заказчиков), поэтому некоторые вещи могут показаться странными (LinkedIn, собеседования с заказчиками, обязательное требование разговорного английского, обсуждение ЗП в долларах) или нерелевантными для РФ. Тем не менее, статья имела большой успех на локальных ресурсах, и читатели попросили меня перевести её на русский.

Этой статьей я хочу начать цикл рассказов о том, как я на протяжении нескольких месяцев проходил собеседования в примерно 20-и разных компаниях на разные должности. Тут будут мои мысли о рынке труда, процессе найма, советы а так же несколько самых интересных историй. Цикл будет состоять из нескольких частей — HR собеседования, технические собеседования, финальные собеседования. Итак, первая часть.

Немного о себе. Программирую со школьного возраста, за деньги работаю 10 с хвостиком лет. Работал админом, программистом, тимлидом, РМ-ом, линейным менеджером. Выполнял обязанности SRE/DevOps, архитекта, HR, офис-менеджера, эникейщика.

Работал в кровавом энтерпрайзе, в стартапе, в аутсорсе. В основном занимался формошлёпством и крудами, имел дело с Java и бэкендом. За последние несколько лет пересел на фуллстек микс из Java, Ruby/RoR, Python, Node.js.

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

Всего я прошел примерно 20 собеседований с рекрутерами: половина из которых были из агенств и половина — штатные рекрутеры/HR компаний. Так что, могу сказать что некоторая статистика у меня есть.

Небольшое отступление

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

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

Предыстория

Один из самых крутых и универсальных стероидов, известных мне – раш (по-английски Rush – натиск, напор). Термин пришел из компьютерных игр, особенно из стратегий реального времени. Лично я с ним познакомился, когда играл в Starcraft Broodwar, а точнее – когда наблюдал за нашими общажными мастерами. Они и показали мне, что такое zerg rush.

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

Раш – тактика рискованная, как в игре, так и в жизни. Если противник предвидел раш, и подготовился в защите, то вы, скорее всего, проиграете. В жизни, если ваш раш не сработает, вас уволят.

Я много лет работал Data Engineer'ом и Data Scientist'ом, решал сложные бизнес-кейсы, строил большие системы, выводил это все в продакшен. В начале 2017го я бросил пить, курить и работать в офисе и ушел фрилансить, экспериментировать с альтернативными формами занятости. Довольно много времени я провел на Upwork. Судя по многочисленным комментариям, уважаемая аудитория не до конца представляет себе, что это такое. Вещаю.

Upwork это крупнейшая в мире биржа фриланса. Дата сатанисты и дата инженеры мало кому в этом мире нужны (по сравнению с переводчиками, веб-мастерами и переписывателями текстов), так что задач для нас относительно мало, так что они тяготеют к крупнейшей бирже в мире. Других фриланс-бирж с постоянным потоком задач для дата саентистов в мире нет — ни Guru, ни Toptal, ни отечественный fl.ru спросом похвастаться не могут. Что важно — для специалистов более массовых специальностей опыт фриланса может сильно отличаться.

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

Каждый программист старается писать хороший код. Читабельность — один из главных признаков такого кода. О ней написано достаточно много книг, но всё же в теме есть пробелы. Например, те самые книги сфокусированы больше на советах КАК написать читабельный код, а не на причинах того, почему один код является хорошо читабельным, а другой — нет. Книга говорит нам «используйте подходящие названия переменных» — но что делает одно название более подходящим, чем другое? Работает ли это для всех примеров подобного кода? Работает ли это для всех программистов, которым попадётся на глаза этот код? Как раз о последнем я и хотел бы поговорить чуть детальнее. Давайте погрузимся немного в человеческую психику. Наш мозг — главный наш инструмент, хорошо бы изучить специфику его работы.