Метка: разработчики

  • День рождения #хэштегов

    День рождения #хэштегов

    23 августа 2007 года американский блогер и евангелист Open Source Крис Мессина опубликовал твит, в котором предложил использовать знак # для обозначения темы твита. Знак уже почти десять лет применялся в IRC для обозначения каналов, например, #news.

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

    Изначально знак # — это сокращённое написание libra pondo — римское обозначение меры веса. Сперва типографы для сокращения набора ввели лигатуру , а позднее упростили её до знакомого нам символа #. Кстати, музыкальный символ диез — это совершенно другой знак: у него линии косые.

    Также символ # используют во многих странах, чтобы обозначать слово “номер”. Нам кажется это необычным, ведь мы используем лигатуру Nomero для той же цели. В Россию она попала как заимствование из французской типографики в 19 веке. Занятно, что французская традиция потеряла этот символ в ходе преобразований.

  • Я чайник!

    Я чайник!

    В 1990 году первым устройством, управляемым через интернет, стал тостер. А 1 апреля 1998 года был предложен шуточный стандарт RFC 2324 для управления кофе-машинами через HTTP-протокол.
    Браузер шлёт запрос на веб-сервер, а веб-сервер сообщает браузеру о своём состоянии кодом из трёх цифр. Для тех случаев, когда запрос на варку кофе получает чайник, был выделен специальный код статуса веб-сервера 418 — Я чайник. Он должен сообщить, что сервер не сможет сварить кофе, но вместо этого сервер сообщает, что он простой чайник. Ответ фактически правильный, но пользователю не помогает — ну, чайник, а мне что делать-то?

    Мы должны видеть страницу сайта или страницу с ошибкой и понятными инструкциями. Коды со статусом веб-сервера предназначены для программистов, сисадминов и SEOшников. Кодов более 60, с некоторыми из них вы наверняка сталкивались.
    404 — Страница не найдена. Самый известный код ответа. День вебмастера отмечается каждый год 4.04. Эти страницы часто оформляют веб-дизайнеры.
    301 — Документ переехал. Чаще всего этот статус появляется в результате работы SEOшника. Пользователя моментально перенаправляет на другой адрес.
    500 — Внутренняя ошибка сервера. Программист залил код с ошибками.
    502 — Шлюз недоступен. Позовите сисадмина.
    503 — Сервис недоступен. Позовите сисадмина и программиста.

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

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

  • Фуллстек парадокс

    Фуллстек парадокс

    В начале 2000-х в веб-разработке не было фронтэндов или бэкэндов.
    Была профессия вебмастер. Этот человек мог сделать сайт целиком. Он умел общаться с полиграфическим дизайнером про внешний вид сайта, верстать HTML таблицами, оптимизировать графику, писать java script. Стек был небольшой и было мало слоёв абстракции.
    Если было нужно что-то покруче, звали программиста и он писал CGI-скрипты на Perl, PHP или C.

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

    В момент, когда фронт научился писать запросы к базе данных и создавать API-методы, он достиг своей полноты. В его мировоззрении всё жизненное пространство в этот момент освоено. Всё так, но для бэкэнд разработчика уровень фронтов на его территории — Intern или Junior.

    Современный бэкенд разработчик часто знает HTML, CSS и Java Script. Может так случиться, что был у него опыт разработки на React, но он не будет считать это значительным достижением. Хорошо, если в резюме укажет. Его территория упирается с одной стороны в серверное администрирование и облака, с другой находится уровень железа: производительность процессора, работа с памятью, операции чтения и записи на жесткий диск. Пляж фронтэндов находится на периферии его владений и занимает небольшой участок с выходом в море.

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

    Количество абстракций в процессе разработки выросло. У пирога было три слоя, а в современном рецепте их пятнадцать. Изобретают новые фреймворки, меняются библиотеки и подходы. Рынок делает веб-программирование всё более абстрактным и сложным.

    Практические выводы:
    – Если вам нужен в команду разработчик с полным спектром знаний — ищите сеньора бэкендера, у которого был опыт работы на фронте. Вакансии Веб-разработчик, Программист или Backend-developer. Но делать фронт его руками очень дорого.
    – В команду нужно брать и фронтов и бэков. Бэки будут ворчать и не хотеть делать задачи фронтов, фронты не владеют всей картиной происходящего на бэке.
    – LLM уже сейчас помогает бэкендерам делать сносный фронтэнд. Скоро всё перемешается снова.

  • Как придумать надёжный пароль?

    Как придумать надёжный пароль?

    Все пароли должны быть:
    🎲 Случайно сгенерированы
    🔢 Больше 12 символов

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

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

    Поэтому пароли должны быть уникальными для каждого аккаунта — пароль утекает в одном сервисе и его пробуют применить для входа во все остальные.

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

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

    🤷‍♂️ И что теперь?
    – Всегда генерируй случайный пароль!
    – Контрольные вопросы — зло, их следует прекратить использовать совсем.
    – Используй альтернативы паролям: passkey, одноразовые sms-коды, ключи или биометрию.
    – Нет 100% защиты от взлома, поэтому включай 2-х факторную аутентификацию — взломать два средства гораздо сложнее.

    В следующем посте я расскажу как и где хранить пароли дома и на работе.

    📩 Перешли это сообщение своим близким, пока их пароль не подобрал хакер!

  • Тестовые задания для разработчиков

    Тестовые задания для разработчиков

    Тестовые задания для разработчиков.

    Не люблю я тестовые задания. И разработчики не любят.

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

    Мидл не оскорбится, но проверить его навыки у вас тоже получится плохо. С выдуманным маленьким тестовым он справится без труда. Большое тестовое бесплатно делать не захочет. Задание нужно компетентно проверить и затем обсудить. Кто будет тратить на это ресурсы?

    Джун может посыпаться даже на простом задании. Вы же собираетесь его доучивать? Проверите разве что базовые навыки: нажимать на кнопки, смотреть в документацию и кормить вашими тестовыми нейросеть.

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

    Задайтесь вопросом, что мы на самом деле пытаемся у кандидата тестовыми заданиями узнать? Можно ли эти ответы получить иначе?

    Моя практика с тестированием навыков такая:
    1) Для сеньоров и мидлов — начать с обсуждения тестового ТЗ, очень похожего на реальный проект. Тут вы действительно сможете понять логику, оценить предлагаемые решения и обсудить реализацию. На пальцах и за 20 минут. Такое ТЗ без проблем составит ваш ПМ.
    2) Дать настоящие задачи и оплатить их выполнение. Я стараюсь вывести всех перспективных кандидатов на тестовую неделю. Мы увидим всё — навыки коммуникации, командной работы, скорость работы, владение реальными инструментами и возможность решать задачи реального мира. В любой момент тестовой недели обе стороны могут остановить тест и безопасно разойтись.
    3) Для джуна — он же не только у вас собеседование проходит. Спросите, какие ещё тестовые он проходил — и попросите показать результат. Сомневаюсь, что он подписал на тестовые NDA. Заодно поймёте, как подбирают разработчиков ваши коллеги и конкуренты.
    4) У всех кандидатов просить реальный код любого проекта. Можно не с прошлой работы, можно пет-проект. Этот код можно скормить на аудит нейросетке.

    А у вас как с тестовыми? Были случаи, когда они реально необходимы?

  • Почему нужно нанимать джунов

    Почему нужно нанимать джунов

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

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

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

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

    Вы просто очень хотите обучать. Может быть тогда ваш бизнес — образование?

    Мой вывод: большинству компаний и команд джуны не нужны.

    А вы нанимаете джунов? Расскажите, зачем и что из этого выходит.

  • Пройти Тест Джоэля

    Пройти Тест Джоэля

    В 2000 году Джоэль Сполски — сооснователь StackOverflow и Trello, написал список из 12 вопросов, известные как Тест Джоэля. Часто ссылаюсь на этот тест, поэтому прокомментирую эти вопросы.

    1. Используете систему контроля версий?
    Кажется, что git — уже обязательная вещь. Но до сих пор встречаются проекты без системы контроля версий.
    Для тех, кто уже использует, вопрос всё ещё актуален, но теперь звучит так: Вы действительно используете систему контроля версий? У вас есть стратегия ветвления, процедура слияния веток, понятные правила для работы с репозиторием?

    2. Сборка проекта происходит в один шаг?
    Проект должен собираться в 1 команду и она должна быть написана в readme. Если для запуска проекта требуется поставить несколько сервисов, иметь нужную версию компилятора и запущенную базу данных — стоит прописать все эти зависимости в docker-compose и запускать одной командой. После прихода виртуализации оправданий для многошаговой сборки и зависимости от среды больше нет.

    3. У вас настроен CI/CD?
    В оригинале Джоэль говорит про daily build — оперативная сборка софта каждый день. Сейчас в большинстве команд нет нужды синхронизировать код раз в день, можно делать это автоматически каждый раз, когда код попадает в репозиторий.
    Настройте автоматическую сборку и выкатку приложения на тестовый сервер.

    4. У вас же есть база багов? Правда?
    Громоздкая Джира не единственный вариант. Эксель тоже подойдёт! Если у вас есть общий зафиксированный список проблем, вы можете с ними работать и планировать их устранение.

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

    6. У вас есть план работ со сроками?
    План, который знают все и который связан с реальностью. Roadmap, этапы или просто дата, в которую надо запуститься.
    Работа ведёт себя как газ — занимает всё выделенное время. Ставьте сроки.

    7. У вас есть спецификация?
    Банально, но без ТЗ результат ХЗ. Сейчас не нужно писать исчерпывающее финальное тех задание — требования поменяются по ходу разработки. Достаточно написать концепцию, сделать прототипы, записать user story и опубликовать. Задачи тоже нужно записать и поставить в трекер.

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

    9. У разработчиков лучшая техника и инструменты?
    Быстрый комп, 2ой монитор, современный софт, быстрые серверы — стоят копейки относительно времени программиста. Планка памяти стоит как час работы разработчика. Ускоряйте их всеми доступными способами, это очень дёшево.

    10. У вас есть тестировщики?
    Если баги ищут только разработчики — значит, баги находят пользователи.
    Менеджеры и программисты проверяют, что код работает. Тестировщики проверяют, ищут где он не работает. У вас должен быть хотя бы 1 тестировщик в команде на нескольких разработчиков.

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

    12. Вы делаете usability тесты на добровольцах?
    Соберите группу для тестирования. Первые 5 случайных пользователей укажут вам на 95% проблем. Находите этих пользователей и проводите тестирование до большого релиза. Это дёшево и просто. В оригинале предлагается поймать добровольца в коридоре компании, но сейчас эра удалёнки — найдите их онлайн.

    Если вы фаундер или руководитель и у вас есть ответы “Нет” — их точно стоит обсудить с командой.

  • Клуб для директоров диджитал-агентств

    Клуб для директоров диджитал-агентств

    Отраслевой клуб Галера — лучшее, что со мной случилось за последние пару лет в профессиональном плане.

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

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

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

    Запишитесь на экскурсию в клуб и присоединяйтесь к сообществу!

  • Как измерять работу программистов

    Как измерять работу программистов

    Как измерять работу программистов.

    CEO и CFO приходят к CTO с вопросом: можно ли оптимизировать затраты на разработку? Как понять, кого уволить, а кто хорошо работает? Кому сколько платить?

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

    Очевидные метрики, которые придумает HR:
    – Присутствие на рабочем месте.
    – Количество выполненных задач.
    – Количество часов, затраченных на выполнение этих задач.
    – Уложился ли в план.

    Неочевидные метрики, которые добавит CTO:
    – “Бизнес ценность” — баллы, которыми стейкхолдеры оценивают задачи по их значимости или приоритету для бизнеса.
    – “Стори пойнты” — баллы трудоёмкости. Разработчики собираются на “Покер Планирования” и оценивают задачи между собой. Используют футболки (XS, S, M, L, XL) или степени числа 2 (1, 2, 4, 8, 16, 32).
    – Количество багов в коде, написанном разработчиком.
    – Скорость — любые баллы делим на время.
    – % отклонения от собственной или командной оценки.

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

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

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

    Что с этим делать?
    – Если хочется кого-то уволить или повысить — спросите менеджера отдела. Он всё знает без метрик. Для уверенности проведите 360-градусную оценку.
    – Всё равно измерять все возможные/удобные показатели, но не принимать решения только на них.

  • Как нанять разработчика: Отбор кандидатов

    Как нанять разработчика: Отбор кандидатов

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

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

    В анкете 50+ вопросов. Спросим про часовую ставку, условия работы, работает ли с таймером, пишет ли тесты и любые другие интересные нам детали.
    Самый большой блок — отдельные вопросы про каждую технологию и навык, который может потребоваться у целевого кандидата.
    Какой опыт с _____?
    Варианты ответа: Не было опыта, Изучал/Пробовал, Практик, Эксперт.

    Кажется, что тут легко обмануть и приукрасить. Да, но навряд ли на 2 ступени. 🤡
    Любой крупный обман в анкете вскроется на интервью и реальных задачах. А если что-то приукрасил — сам будет навёрстывать.

    Разработчик с удовольствем заполнит анкету вместо 30-минутного интервью с рекрутёром. Анкету можно заполнить на текущем рабочем месте или после работы. Без стресса и спешки.

    В итоге мы быстро отбираем лучших в таблице, а кандидаты не тратят время на ненужные звонки. Просто, удобно, минимум стресса.