Сервис, выдающий IP-адреса устройствам в локальной сети, кажется одним из самых простых и всем знакомых. Тем не менее у моих младших коллег до сих пор временами всплывают вопросы вроде «компьютер что-то получает какой-то странный адрес», а появление второго DHCP-сервера в одном сетевом сегменте вызывает некоторый трепет или проблемы в работе сети.

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

Немного теории и решения интересных и не очень практических задач — под катом.

В современной локальной сети выдачей адресов обычно занимаются специализированные сервисы с поддержкой протоколов. Самым популярным из них является DHCP (Dynamic Host Configuration Protocol).

Zeroconf или зачем нам вообще какой-то DHCP

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

Получение IP-адреса (Automatic Private IP Addressing или APIPA). Система сама назначает себе IP из сети 169.254.0.0/16 (кроме сеток /24 в начале и конце диапазона), основываясь на MAC-адресе и генераторе псевдослучайных чисел. Такая система позволяет избежать конфликтов, а адрес из этой сети называют link-local — в том числе и потому, что эти адреса не маршрутизируются.

Поиск по имени. Система анонсирует свое сетевое имя, и каждый компьютер работает с ним как с DNS, храня записи у себя в кэше. Apple использует технологию mDNS (Multicast DNS), а Microsoft — LLMNR (Link-local Multicast Name Resolution), упомянутую в статье «Домены, адреса и Windows: смешивать, но не взбалтывать».

Поиск сетевых сервисов. Например, принтеров. Пожалуй, самым известным протоколом является UPnP, который помимо прочего умеет сам открывать порты на роутерах. Протокол довольно сложен, в нем используется целый набор надстроек вроде использования http, в отличие от второго известного протокола — DNS-SD (DNS Service Discovery), который попросту использует SRV-записи, в том числе при работе mDNS.

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

Немного раздражает, не так ли?

В системах Windows для отключения автонастройки на всех сетевых адаптерах необходимо создать параметр DWORD с именем IPAutoconfigurationEnabled в разделе HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters и поставить ему значение 0.

Разумеется, Zeroconf подходит разве что для небольших изолированных сетей (например, встретились с приятелем с ноутбуками, соединили их по Wi-Fi и давай играть Diablo II, не тратя время на какие-то сервера), да и выводить локальную сеть в интернет тоже хочется. Чтоб не мучаться со статическими настройками каждого компьютера, были созданы специальные протоколы, включая героя дня — DHCP.

DHCP и его прародители

Одна из первых реализаций протокола для выдачи IP-адресов появилась более 30 лет назад и называлась RARP (Reverse Address Resolution Protocol). Если немного упростить принцип его работы, то выглядело это так: клиент делал запрос на широковещательный адрес сети, сервер его принимал, находил в своей базе данных привязку MAC-адреса клиента и IP — и отправлял в ответ IP.

Схема работы RARP протокола.

И все вроде работало. Но у протокола были минусы: нужно было настраивать сервер в каждом сегменте локальной сети, регистрировать MAC-адреса на этом сервере, а передавать дополнительную информацию клиенту вообще не было возможности. Поэтому на смену ему был создан протокол BOOTP (Bootstrap Protocol).

Изначально он использовался для бездисковых рабочих станций, которым нужно было не только выдать IP-адрес, но и передать клиенту дополнительную информацию, такую, как адрес сервера TFTP и имя файла загрузки. В отличие от RARP, протокол уже поддерживал relay — небольшие сервисы, которые пересылали запросы «главному» серверу. Это сделало возможным использование одного сервера на несколько сетей одновременно. Вот только оставалась необходимость ручной настройки таблиц и ограничение по размеру для дополнительной информации. Как результат, на сцену вышел современный протокол DHCP, который является совместимым расширением BOOTP (DHCP-сервер поддерживает устаревших клиентов, но не наоборот).

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

• Клиент ищет сервер широковещательным запросом, запрашивая в том числе и дополнительные настройки.

• Сервер отвечает клиенту, предлагая ему IP-адрес и другие настройки.

• Клиент подтверждает принятую информацию широковещательным запросом, указав в подтверждении IP-адрес выбранного сервера.

• Сервер соглашается с клиентом, отправляя ему запрос, по получении которого клиент уже настраивает сетевой интерфейс или отвергает его.

Схема общения клиента с сервером пересылки и сервером.

Подробнее про схему взаимодействия сервера и клиента и про структуру запросов и ответов можно почитать, например, в материале «Структура, формат и назначение DHCP пакетов».

На нескольких собеседованиях меня спрашивали: «А какой транспорт и порт использует DHCP?» На всякий случай отвечаем: «Сервер UDP:67, клиент UDP:68».

С разными реализациями DHCP-сервера сталкивались многие, даже при настройке домашней сети. Действительно, сейчас сервер есть:

• На практически любом маршрутизаторе, особенно SOHO.

• На системах Windows Server. О сервере и его настройке можно почитать в официальной документации.

• На системах *nix. Пожалуй, самое популярное ПО — ISC DHCP Server (dhcpd) и «комбайн» Dnsmasq.

Конкретных реализаций довольно много, но, например, на SOHO-маршрутизаторах настройки сервера ограничены. В первую очередь это касается дополнительных настроек, помимо классического «IP-адрес, маска, шлюз, сервер DNS». А как раз эти дополнительные опции и вызывают наибольший интерес в работе протокола. С полным списком можно ознакомиться в соответствующем RFC, я же разберу несколько интересных примеров.

Удивительные опции DHCP

В этом разделе я рассмотрю практическое применение опций DHCP на оборудовании MikroTik. Сразу обращу внимание на то, что не все опции задаются очевидно, формат параметров описан в wiki. Следует отметить также то, что опции клиент применяет, только когда сам их попросит. В некоторых серверах можно принудительно отправить настройки: например, в ISC DHCP Server за это отвечает директива dhcp-parameter-request-list, а в Dnsmasq —* *—dhcp-option-force. MikroTik и Windows такого не умеют.

Option 6 и Option 15. Начнем с простого. Настройка под номером 6 — это серверы DNS, назначаемые клиентам, 15 — суффикс DNS. Назначение суффикса DNS может быть полезным при работе с доменными ресурсами в недоменной сети, как я описывал в статье «Как мы сокращали персонал через Wi-Fi». Настройка MikroTik под спойлером.

#Добавляем опцию 15. содержимое — сконвертированный в HEX суффикс.  /ip dhcp-server option  add code=15 name=dns-suffix value=0x57687920616c6c207468697320736869743f  #создаем набор опций  /ip dhcp-server option sets  add name=dns option=dns-suffix  #Добавляем опцию к DHCP-серверу для клиентов.  /ip dhcp-server network  set [find comment="wi-fi client dhcp"] dhcp-option-set=dns 

Знание, что сервер DNS — это тоже опция, недавно пригодилось мне, когда разным клиентам нужно было выдать разные серверы DNS. Решение вида «выдать один сервер и сделать разные правила dst-nat на 53 порт» не подходило по ряду причин. Часть конфигурации снова под спойлером.

#настройка опций, обратите внимание, что ip экранирован одинарными кавычками  /ip dhcp-server option  add code=6 name=google value="'8.8.8.8'"  add code=6 name=cloudflare value="'1.1.1.1'"  #настройка клиентов  /ip dhcp-server lease  add address=10.0.0.2 dhcp-option=google mac-address=11:11:11:11:11:11 server=dhcp  add address=10.0.0.3 dhcp-option=cloudflare mac-address=22:22:22:22:22:22 server=dhcp 

Option 66 и Option 67. Эти настройки пришли еще с BOOTP и позволяют указать TFTP-сервер и образ для сетевой загрузки. Для небольшого филиала довольно удобно установить туда микротик и бездисковые рабочие станции и закинуть на маршрутизатор подготовленный образ какого-нибудь ThinStation. Пример настройки DHCP:

/ip dhcp-server option  add name="option66" code=66 value="s'192.168.88.1'"  add name="option67" code=67 value="'pxelinux.0'"  /ip dhcp-server option sets  add name="set-pxe" options=option66,option67 

Option 121 и Option 249. Используются для передачи клиенту дополнительных маршрутов, что может быть в ряде случаев удобнее, чем прописывать маршруты на шлюзе по умолчанию. Настройки практически идентичные, разве что клиенты Windows предпочитают вторую. Для настройки параметра маршруты надо перевести в шестнадцатеричный вид, собрав в одну строку маску сети назначения, адрес сети и шлюз. Также, по RFC, необходимо добавить и маршрут по умолчанию. Вариант настройки — под спойлером.

/ip dhcp-server option  add code=121 name=classless value=0x0A0000c0a8580200c0a85801 

Подробнее можно прочитать в статье «Mikrotik, DHCP Classless Route».

Option 252. Автоматическая настройка прокси-сервера. Если по каким-то причинам в организации используется непрозрачный прокси, то удобно будет настроить его у клиентов через специальный файл wpad (pac). Пример настройки такого файла разобран в материале «Proxy Auto Configuration (PAC)». К сожалению, в MiroTik нет встроенного веб-сервера для размещения этого файла. Можно использовать для этого пакет hotspot или возможности metarouter, но лучше разместить файл где-либо еще.

Option 82. Одна из полезнейших опций — только не для клиента, а для DHCP-релея. Позволяет передать серверу информацию о порте коммутатора, к которому подключен клиент, и id самого коммутатора. Сервер на основе этой информации в свою очередь может выдать уже клиенту какой-то определенный набор настроек или просто занести в лог — чтобы в случае необходимости найти порт подключения клиента, не приходилось заходить на все свитчи подряд (особенно, если они не в стеке).

После настройки DHCP-Relay на маршрутизаторе в информации о клиентах появятся поля Agent Circuit ID и Agent Remote ID, где первое — идентификатор порта коммутатора, а второе — идентификатор самого коммутатора.

Выдача адресов с option 82.

Информация выдается в шестнадцатиричном формате. Для удобства восприятия при анализе журнала DHCP можно использовать скрипты. Например, решение для решения от Microsoft опубликовано в галерее скриптов Technet под названием «Декорирование DHCP опции 82».

Также опция Option 82 активно используется в системе биллинга провайдеров и при защите сети от посторонних вмешательств. Об этом чуть подробнее.

Добавим сети надежности и безопасности

Ввиду простоты протокола и присутствия широковещательных запросов есть эффективные атаки на инфраструктуру — в основном типа MITM («человек посередине»). Атаки производятся посредством поднятия своего DHCP-сервера или релея: ведь если контролировать выдачу сетевых настроек, можно запросто перенаправить трафик на скомпрометированный шлюз. Для облегчения атаки используется DHCP starvation (представляясь клиентом или релеем, злоумышленник заставляет «родной» DHCP-сервер исчерпать свои IP-адреса). Подробнее про реализацию атаки можно почитать в статье «Атакуем DHCP», методом же защиты является DHCP Snooping.

Это функция коммутатора, которая позволяет «привязать» DHCP-сервер к определенному порту. Ответы DHCP на других портах будут заблокированы. В некоторых коммутаторах можно настроить и работу с Option 82 при ее обнаружении в пакете (что говорит о присутствии релея): отбросить, заменить, оставить без изменения.

В коммутаторах MikroTik включение DHCP Snooping производится в настройках бриджа:

#Включаем dhcp-snooping и option 82  /interface bridge  add name=bridge  set [find where name="bridge"] dhcp-snooping=yes add-dhcp-option82=yes  #ставим настраиваем доверенный порт  /interface bridge port  add bridge=bridge interface=ether1  add bridge=bridge interface=ether2 trusted=yes 

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

Стоит отметить, что не все модели MikroTik имеют полную аппаратную поддержку DHCP Snooping — она есть только у CRS3xx.

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

Красивая коммутационная — залог здоровья.

К другим методам защиты можно отнести Port Security («привязка» определенного MAC-адреса к порту маршрутизатора, при обнаружении трафика с других адресов порт будет блокироваться), Анализ трафика на количество DHCP-запросов и ответов или ограничение их количества, ну и, конечно, различные системы IPS\IDS.

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

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

Разберем более практичные варианты.

В системах Windows Server начиная с 2012 система резервирования DHCP работает «из коробки», в режиме балансировки нагрузки (active-active) или в режиме отказоустойчивости (active-passive). С подробным описанием технологии и настройками можно ознакомиться в официальной документации. Отмечу, что отказоустойчивость настраивается на уровне зоны, поэтому разные зоны могут работать в разном режиме.

Настройка отказоустойчивости DHCP-сервера в Windows.

В ISC DHCP Server для настройки отказоустойчивости используется директива failover peer, синхронизацию данных предлагается делать самостоятельно — например, при помощи rsync. Подробнее можно почитать в материале «Два DHCP сервера на Centos7…»

Если же делать отказоустойчивое решение на базе MikroTik, то без хитростей не обойтись. Один из вариантов решения задачи был озвучен на MUM RU 18, а затем и опубликован в блоге автора. Если вкратце: настраиваются два сервера, но с разным параметром Delay Threshold (задержка ответа). Тогда выдавать адрес будет сервер с меньшей задержкой, а с большей задержкой — только при выходе из строя первого. Синхронизацию информации опять же приходится делать скриптами.

Лично я в свое время изрядно потрепал себе нервов, когда в сети «случайно» появился роутер, подключенный в локальную сеть и WAN, и LAN интерфейсами.
Расскажите, а вам приходилось сталкиваться с проказами DHCP?

Уверен, IT-блогеры, маркетологи, деврелы и пиарщики найдут для себя много интересного.

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

Если вы вдруг не знаете, кто такой Сергей Абдульманов (milfgard), держите краткую справку: бизнес-евангелист, директор по маркетингу в «Мосигре», совладелец PR-агентства, автор трех книг и один из топовых блогеров на Хабре.

Мы побеседовали, пока Сергей добирался до «Сапсана» – следующим днем планировалось его выступление на фестивале TechTrain.

– Тебя знают на Хабре как одного из главных людей в «Мосигре» и как топового автора…

– В «Мосигре» я занимался тем, что мне было интересно. Плюс у меня есть свое PR-агентство Loft, где мы ведем несколько PR-проектов. Может быть, я когда-нибудь смогу об этом рассказать. Впрочем, про Билайн уже рассказывал.

– Почему в прошедшем времени? И как ты совмещаешь агентство и «Мосигру»?

– На этой неделе я полностью вышел из операционных процессов в «Мосигре» и теперь консультирую по стратегии. А началось с того, что в мае я стал раскладывать письма в своем ящике на то, что я хочу дальше делать и что не хочу. Это история про правильное делегирование. Оно мне давалось всегда сложно. И если с «Мосигрой» удалось разделить обязанности и оставить то, что мне интересно, то с агентством весь этот год мы болезненно проходим подготовку к минимизации моего участия.

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

Про обучение

– Современный человек должен все время учиться, как учишься ты?

– До разговора с тобой я сел в такси и загрузил четыре книги, чтобы читать их в «Сапсане». А вообще образование сейчас заметно продвинулось. Для тех, кто начинал учиться в конце 90-х, начале нулевых, это прям волшебная история! Раньше у тебя не было полноценного доступа к знаниям. Я в университет пошел в 99-м, и это были большие вилы, потому как ты фактически переписывал то, что лектор говорил. Это вообще не похоже на то, как сейчас образование устроено.

История образования это история четырех слоев того, что тебе рассказывают. Четвертый слой – технологическая история. То, что мы привыкли называть рецептом: делай так и получишь то. Она никому не нужна, но почему-то все считают, что она самая важная. Первый слой – это объяснение, зачем ты это делаешь, почему ты это делаешь, и обзор – что будет в результате.

Когда мы с «Билайном» работали, там была прекрасная история – они рассказывали, как инженеры инженеров учат. У них есть университет в Москве. Для него регулярно выдергивали людей из регионов, чтобы они делились опытом. Это было пять лет назад, и я не уверен, что до сих пор так все работает. И там была проблема – обычно инженер приходит и говорит: «так, сели, достали блокноты, и я покажу, как все это настраивается». Все охреневают, и никто не понимает, зачем этого человека слушать.

И в университете начали учить этих людей правильно выступать. Они говорят: «объясни, зачем это».

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

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

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

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

Учиться сейчас стало легко потому что, во-первых, поменялись курсы. Вот был такой фетиш в бизнесе – MBA. Сейчас он уже не так котируется. У него очень размыт образ. Во-вторых, вот пример: в «Стэнфорде» есть программа исполнительных директоров, которая короче, интенсивнее и на две головы выше. В частности по практическому результату.

Отдельно есть прекрасная Coursera, но там проблема – это видео.

У меня знакомый занимался тем, что переводил курсы Coursera и просил переводчика делать титры, которые потом читал, чтобы видео не смотреть. Ему это сжимало время, а сообщество получало переведенный курс.

Но если взять молекулярную генетику, то видео окажется очень важным. Не потому, что там что-то нарисовано, а потому, что уровень упрощения материала достаточен, т.е. его нужно воспринимать с определенным темпом.

Я пробовал по методичке и по видео. По видео получалось лучше. Но это редкий случай.

Есть и другие курсы, когда ты без видео просто не пройдешь, типа введения в классическую музыку, но в 80% случаев оно не нужно. Хотя поколение Z ищет уже даже не в Google, а на YouTube. Что тоже норм. Видео надо также научиться классно делать, как и тексты. И где-то за этим будущее.

Про работу с текстами и заказчиками

– Сколько времени в день тебе удается выделить на тексты?

– 2-3 часа в день я обычно что-то пишу. Но не факт, что все это коммерческое. Я канал свой веду, пытаюсь написать следующую книгу.

– Сколько ты успеваешь написать за 2-3 часа?

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

– Где тебе комфортнее работать с текстами, дома или в офисе?

– Я сейчас иду по улице и в руках у меня планшет с откидной клавиатурой. Я с ним буду ехать в «Сапсане» и наверняка успею что-то написать. Но это возможно когда ты пишешь по заранее подготовленному материалу и без картинок. А так у меня десктоп дома, я очень долго выбирал клавиатуру. 10 лет у меня была клавиатура за 270 рублей (Cherry, «пленка»). Сейчас у меня «механа», но с ней тоже есть проблема. Она для геймеров сделана, и я хочу передать пламенный привет поддержке Logitech, этим прекрасным людям, которые не выполняют свои же гарантийные обязательства. Клавиатура красивая и удобная, но проработала 2-3 месяца. Потом я понес ее в официальный сервис, где сказали, что поломка по вине производителя. Но Logitech пофиг на безусловную гарантию, и ремонт был платный. Они тикет разбирали три недели: типа, пришлите видео, пришлите серийник, а там в изначальном обращении всё было.

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

– Как ты подбираешь темы?

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

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

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

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

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

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

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

Приходится каждый раз объяснять, обосновывать. Последние годы удается отстаивать эту позицию. В этом плане всегда прикольным был «Билайн», с которым мы четыре года работали, в частности, по «Хабру». Они не стеснялись говорить про самые жуткие вещи, потому что у них хорошая команда в пиаре подобралась. Это они выкатили дохлого голубя на блогеров: в слегка затопленный подвал спускаются блогеры разные, и на них выплывает дохлый голубь. Это прекрасно было. Они показывали вообще все, не стесняясь. И это очень много чего давало. Но сейчас уже не так.

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

Третья вещь – нужно понимать что интересно людям в целом. Что человек в компании может рассказать при взгляде на историю. Классическая хардкорная ошибка – пытаться айтишникам рассказывать про технологии. Это очень узкий сегмент всегда, и пока человек не столкнется с этой технологией напрямую, ему это читать будет не особо интересно. Т.е. как бы интересно, но практического применения не будет. Поэтому всегда надо рассказывать о смысле этой истории. Надо ее всегда расширять до взгляда бизнеса, если про IT пишем, например. Что-то, что происходит в реальном мире и как отражается на IT-процессах, и как эти процессы что-то меняют потом. А обычно рассказывают так: «вот мы тут взяли технологию, прикрутили к этому и вот получилось». Если ты посмотришь на старый блог Яндекса, под редактурой Zalina (не только её посты, а именно, что разработчики писали), он примерно в похожем плане идет – с позиции взгляда бизнеса на технологии.

– Разработчики часто стесняются рассказывать про свою работу, боятся, что у них что-то не так, что они не настолько круты, их заминусуют. Как избавиться от этих хмурых мыслей?

– У нас гораздо чаще другая история случается: человек, например руководитель отдела, публиковался в нескольких СМИ, говорил везде официальным языком, а теперь боится писать на Хабре неофициальным.

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

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

Второй важный момент, который недооценен – война правок на предмет того, чтобы пиар не гладил текст до состояния полной зализанности.

– Какие бы ты выделил критерии классного поста?

– На «Хабре» есть кейс про «Билайн», там это выделено. В целом: хорошая актуальная тема, интересная людям, нормальный взгляд на систему, не чисто про технологии, а почему это важно и с чем это связано, хороший простой язык. Это базовые вещи, а остальное уже детали: что за материал, на какую тему и т.д. Ну и я про это много писал в книге «Евангелист бизнеса».

– Какие ошибки авторы совершают чаще всего? Что не стоит делать на «Хабре»?

– Одно официальное слово и тебе на «Хабре» хана. Как только появляется подозрение того, что к тексту приложил руку маркетолог, то все. Можно ставить крест на посте, он не взлетит. На «Хабре» успех поста – это когда его начинают растаскивать по соцсетям и телеграм-каналам. Если ты видишь пост до 10 тыс., можешь не сомневаться, что он прошел только внутри Хабра. А если пост на 20-30 тыс. и больше, значит его растащили, и на «Хабр» приходил внешний трафик.

– Было ли в твоей личной практике так, что ты пишешь-пишешь, а потом все удаляешь и делаешь заново?

– Да, было. Но чаще бывает так, что начинаешь писать, откладываешь материал на 2-3 недели, потом возвращаешься к нему и думаешь, стоит ли его доделывать или не стоит. У меня так лежат четыре недоделанных материала с прошлого года, потому как я чувствую, что что-то в них не хватает, а что, обосновать не могу. Я раз в месяц их просматриваю и думаю, стоит ли с ними что-то делать или не стоит.

Я тебе больше скажу, я книгу переписывал с нуля два раза. Которая «Бизнес на свои». Пока писали ее, у нас представления о бизнесе менялись. Было очень смешно. Хотели еще раз переписать, но решили, что нужно зафиксироваться.

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

– А посты ты тестируешь на ком-то?

– Нет. Я даже корректору не скидываю. Не так давно на «Хабре» появилась возможность сообщать об ошибках, и стало жутко удобно. Мне один пользователь написал правки по посту чуть ли не пятилетней давности, который прочитало 600 тыс. человек. То есть вся эта куча людей не увидела или было лень отправлять, а он вот нашёл.

– Как быстро человек может натренировать у себя писательские скилы? Сколько прошло времени до того, как ты научился писать классные посты?

– У меня история немного особенная, потому что я чуть не в 14 лет начал работать в издании. Тогда я работал в поддержке и писал совсем чуть-чуть, а в 18 уже был редактором детской газеты в Астрахани. Страшно сейчас вспоминать, но было невероятно весело. Программа у нас была как у «Школы Известий», и учились частично у них. Кстати, на тот момент это был суперуровень в России. Я не говорю, что в Астрахани все было также как там, но много чего мы оттуда взяли, и система подготовки там очень хорошая была. И был доступ к лучшим людям: лингвисты, два психолога, один был супер прям, все действующие корреспонденты. Мы работали на радио, мне до сих пор положен километр пленки в год. Корочка, кстати, пригодилась мне в жизни один раз, когда в Португалии сотрудники музея спросили меня, не сотрудник ли я прессы. Мол тогда ты вместо десяти евро заплатишь один. Затем спросили про удостоверение, которого у меня не было с собой, и поверили мне на слово.

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

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

Вспомнил забавный случай: на Joker в пакете спикера была черная футболка с надписью «ДЖАВА». И в Исландии в баре до меня докопалась девчонка, мол что это за рок-группа такая. Говорю, что русская. Она в ответ, что видит, вот эта буква «Ж» — русская, и ты мол русский и играешь в группе. Было смешно. Кстати, да, Исландия, это страна, где девушки с тобой сами знакомятся, потому как на острове возможности для перекрестного опыления весьма ограничены. И я писал про это, и ещё раз отмечу, что это был не поход по барам, а глубокое изучение генетической базы.

– Как ты считаешь, сколько времени нужно простому технарю, чтобы развить писательский скил, почувствовать аудиторию?

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

Чтобы написать хороший материал, нужно сложить в одном месте тезисы и построить логику изложения. Языку учиться очень долго, но логике изложения можно научиться очень быстро. Когда я учил людей писать на курсах в Tceh, один парень в пределах трех недель написал хороший материал про свою работу, который на «Хабре» очень зашел. Его, кстати, из песочницы два раза не выпускали, потому как язык там был просто беда. Коряво и с орфографическими ошибками. Это известный мне минимум. Если объективно – то полгода, наверное, медиана.

– А бывали у тебя случаи, когда Акелла промахнулся – ты выкатывается пост, и там что-то не то?

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

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

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

Для одной компании делали пост. У них там было тестирование оборудования. А косяк был в том, что мы не знали, что те тесты, которые они сделали, написаны вендором именно под это оборудование. Вендор купил компанию, которая проводит тесты, они написали методологию и получили тесты, подогнанные под их железо. Народ это в комментах выяснил, и дальше начали просто минусовать. Предвидеть это было невозможно, потому что спикер сам не знал этой истории. После этого мы ввели дополнительную процедуру «если бы я был конкурентом, до чего бы я докопался»? И эта проблема закрылась.

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

Был случай, когда ночью клиент поменял заголовок. В 9 утра была публикация, и все было отлично. Затем клиент чего-то испугался и поменял заголовок радикально. Это штатный случай, мы сразу его предупредили, что после этого просмотры сразу можно делить на четыре. Но они решили, что так нужно. В итоге они набрали свои 10 тыс. просмотров, но это как бы ни о чем.

– Насколько тебе тяжело работать с заказчиками? В моей практике четверть попадала в категорию «трудных».

– Вот сейчас не про Хабр, а вообще. У меня проект-менеджер с ума сходит от компаний с государственным участием. Потому что там согласования такие что… 6 месяцев на пост в Facebook – норма.

У меня позиция всегда такая: если все слишком сложно, то разрываем контракт. Ну а дальше соучредительница меня уговаривает, что контракт надо сохранить, и она все порешает. Тут история такая, что на рынке нет никого, кто работает примерно как мы. Все стелятся под клиента, но результат получают плохой, как правило. Клиент не специалист в этих площадках, если мы говорим про Хабр, он обращается к экспертизе. А потом он в эту экспертизу начинает вносить правки, считая, что лучше знает аудиторию и площадку, что можно и что нельзя на ней, и получается печально. И если этот момент не зафиксировать, причем даже на уровне договора, то все будет грустно. Мы отказывались от трех клиентов точно. Обычно делаем пилот, работаем пару месяцев, и если понимаем, что все плохо, то заканчиваем.

– Насколько активно ты работаешь с комментариями, на «Хабре» ведь всегда набегают умные мужики и начинают ковыряться в деталях?

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

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

У меня проблем с комментариями нет, но есть у клиентов, на которых наезжают из-за определенных их косяков. Ну а дальше целая методология как с этим работать. Если кратко, надо стараться не попадать в ситуации, когда на тебя могут наехать. Заранее обозначать минусы и иметь решение проблемы, ну а на случай неадекватов есть целая методология, как это делать. Если откроешь книгу «Евангелист бизнеса», там чуть ли не треть посвящена работе с комментариями.

– Есть сформировавшееся мнение, что на «Хабре» достаточно токсичная аудитория.

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

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

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

– Спасибо тебе за интересную и содержательную беседу!

P.S. возможно, эти материалы вам также будут интересны:
— Когда искусство соединяется с крафтом: издатели сетевых СМИ про технологии, ИИ и жизнь
— 13 самых заминусованных статей минувшего года

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

Таллин: развитая стартап-экосистема

Несмотря на то, что население всей Эстонии составляет примерно 1,3 млн человек, а в столице живет около 425 тысяч, здесь наблюдается настоящий бум развития IT-сектора и технологических стартапов. На сегодняшний день четыре связанных с Эстонией стартапа добились статуса единорога – их капитализация превысила $1 млрд. В этом списке проекты Skype, гемблинговая платформа Playtech, сервис вызова такси и аренды транспорта Bolt и система денежных переводов TransferWise.

Всего в Эстонии насчитывается около 550 стартапов, а общий объем инвестиций в них за последний год составил €328 млн.

Качество и стоимость жизни в Таллине

Страна и ее столица демонстрируют хорошие результаты и по уровню жизни. По данным аналитической компании Mercer, эстонская столица входит в сотню лучших городов по уровню жизни. Таллин занял в рейтинге 87 место. Для сравнения, Москва оказалась лишь на 167 месте, а Санкт-Петербург занял 173 строчку.

Также, по данным сайта Numbeo, стоимость жизни в Таллине ниже, чем в Москве и многих других европейских столицах (Берлин, Вена и т.п.). Так цены на аренду недвижимости в Таллине, в среднем, более чем на 27% ниже, чем в Москве. На 21% меньше нужно будет заплатить в ресторане, а цены на потребительские товары ниже на 45%!

Еще один плюс Таллина – Эстония входит в Евросоюз и Шенгенскую зону, из нее легко и недорого можно добраться до любой точки Европы.

Авиабилет из Таллина в Лондон можно найти за $60-80

Работа в Эстонии: как найти, сколько можно заработать

На сегодняшний день профессия разработчика – одна из самых востребованных в Эстонии, поскольку сотням местных IT-компаний очень не хватает кадров.

Вакансии программистов в Таллине

Что касается зарплат, то Эстония входит еще и в зону евро. Во многом поэтому, и платят здесь больше, чем в странах Евросоюза, сохранивших свою валюту, вроде Венгрии… Беглый анализ стартап-вакансий с Angel.co показывает, что стандартная вилка зарплат в ИТ-секторе сегодня составляет €3,5-5 тысяч в месяц до вычета налогов, но есть и компании, которые платят ощутимо выше – например, те же Эстонские единороги.

При этом даже зарплата разработчика начального уровня для Эстонии будет очень хорошей. Средний заработок в стране во втором квартале 2019 года составлял 1419 евро до вычета налогов – страна все же находится на окраине Европы и не входит в число самых богатых.

Поговорим о том, на каких сайтах можно искать работу в IT-секторе страны. На список сильно влияет тот факт, что значительная часть компаний отрасли – это стартапы:

• Angel.co – на популярном сайте для стартапов есть и раздел с вакансиями, где их можно фильтровать в том числе по стране.
• StackOverflow – тут периодически выкладывают вакансии для разработчиков с возможностью релокации.
• Glassdoor – приличное количество вакансий можно найти и на Glassdoor.

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

Кроме того, «стартаперский» подход к найму предполагает и нестандартные возможности поиска – например, нередки всевозможные хакатоны и соревнования, организованные компаниями из Эстонии.

По результатам таких конкурсов часто также можно получить Job Offer. К примеру, прямо сейчас идет онлайн-чемпионат для разработчиков от компании Bolt – призовой фонд составляет 350 тысяч рублей, а лучшие программисты смогут пройти собеседование и получить оффер с возможностью релокации всего за день.

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

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

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

После въезда и получения ВНЖ, вы сможете познать всю прелесть эстонского электронного правительства. Огромное количество услуг в стране можно получить онлайн – даже выписанные врачом рецепты привязаны к ID и их можно просматривать онлайн. Все это очень удобно.

Еще один плюс Эстонии, который особенно бросается в глаза тем, кто переезжает из мегаполисов – компактность. Практически в любую точку Таллина можно добраться минут за 15-20, часто – пешком. Даже аэропорт расположен очень близко к городу.

Общение и развлечения

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

Развитая стартап экосистема хороша наличием большого количества профессиональных митапов и тусовок – по их количеству маленький Таллин не уступит огромной Москве.

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

Конечно, есть и вещи, к которым в маленькой стране нужно будет привыкать – например, IKEA в Эстонии появилась совсем недавно, а до этого мебель приходилось покупать в других местах. Насыщенность культурной жизни также в целом пониже, чем в Москве или Петербурге – в городе на 425 тысяч человек просто не может быть, например, столько же театров, как в мегаполисе.

Итого

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

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

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

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

О чем этот пост?

Идея поста родилась во время летнего корпоратива, когда мы с коллегами внезапно заговорили о первых шагах в программировании. И мы с iseregin решили собрать их воспоминания и поделиться с общественностью. Итак…

Первые строчки кода

Казалось бы, что интересного в первых строчках кода? Некоторые тоже сначала так подумали.

Dev 1: Я думал, что у всех первая строчка кода была что-то вроде:

!#/bin/bash echo "Hello World"

Dev 2: В нашей местности это было скорее: MsgBox "Hello World". Потому что найти диск с линуксом надо было еще постараться.

Дискуссия, можно сказать, завязалась уже с первых реплик в чате. А потом мы получили несколько интересных и развёрнутых ответов, которыми хотим поделиться. Вот что нам рассказали коллеги из Авито.

Андрей Shodan Аксёнов, руководитель инфраструктуры поиска: «Самые первые строчки кода, которые я в принципе в компьютер вводил, точно были не мои. Это были какие-нибудь странные программки на Basic, которые я перепечатывал из журналов (потому что суровое детство, восьмибитные игрушки). Но зато точно помню, как моей программой впервые воспользовались другие люди.

Это была эпоха излёта DOS. Я написал программку на ассемблере, которая захватывала экран в графическом режиме. Причем, в отличие всего, что на «рынке» было, она справлялась вообще со всеми видеорежимами, в том числе совершенно безумными хакерскими. Например, если штатный режим работы VGA это было 320×200 и на 256 цветов, то люди какими-то гнусными хаками и перепрограммированием контроллера, который лучи по ЦРТ-трубочке гоняет, добивались 360×240. Я умудрился написать программку, которая со всем этим справлялась, захватывала экран (видеопамять), сохраняла его в файл, и потом из этого дампа ты мог ловко .bmp сохранить отдельной офлайновой утилиткой. Я довёл эту программку до конца, выложил ее в интернеты и успешно забыл.

Прошло чуть ли не 12-15 лет с этого момента. Мне на e-mail пришло письмо. Такая простыня, как будто Лев Николаевич Толстой пишет, на трех листах — и это только первая фраза. “Здравствуйте, я водитель-дальнобойщик из Канады. Активный пользователь вашей программы. Денег у меня нет, а пять детей есть. И я на помойке нашел 486-й компьютер, плюс какие-то старые игры в интернетах украл, и теперь у меня дети дико шпилятся на этом компьютере в разные игры. При этом самая любимая их игра ничего не умеет: ни общую доску почёта сохранять, ни хотя бы один топовый high score сохранять, и даже скриншот сделать невозможно, потому что как раз используется какой-то наркоманский видеорежим. А ваша утилита с этим отлично справляется, и дети ей постоянно пользуются. Да я и сам, бывает, между рейсами… Так вот, поскольку мы активные пользователи вашей древней программы, я решил вас поощрить. Вот вам код перевода Western Union на 20 долларов”. Я практически прослезился и решил, что в самый черный день, когда он наконец наступит и я буду голодать, вот я возьму этот MTCN (код перевода), обналичу его и проем. К несчастью, уже и с этого момента прошло еще много лет, поэтому где сейчас MTCN, достоверно неизвестно. Возможно, есть в старых архивах почты, если я их за это время не потерял. Узнаю в самый черный день».

Артём Разинов, ведущий iOS-разработчик: «В пятом классе написал в детской программе Лого Миры самостоятельно код, пока все остальные более успешные ребята играли в игры. Я сотворил программу, и она работала. В этот день я решил стать программистом».

Даниил Попов, старший android-разработчик: s := width * height; «Это была строчка на Pascal, которая вычисляла площадь прямоугольника. Дело было на курсах по программированию для школьников в восьмом классе. Меня тогда больше всего впечатлило то, что я могу давать компьютеру команды, а он беспрекословно их выполняет. Эдакий повелитель машин. С тех пор очень люблю, когда выстроенная последовательность действий (алгоритм) приводит к результату».

Дмитрий Белов, старший бэкенд-разработчик: «Это был первый заказ на зарубежном фрилансе. Голодное студенчество, хотелось заработать хоть небольшую денежку, и не так важно было, на чём писать: знаний почти не было, изучать всё равно почти с нуля.

Попался заказ сделать анимированную открытку на Флэше. Пришлось немного поучить Action Script. Стэковерфлоу ещё не было, приходилось читать документацию.

Заказчик остался доволен, удалось сдать проект сразу. Заработал свои первые пятнадцать долларов на фрилансе».

Илья Грибов, фронтенд-разработчик: «Программированием увлекался с 8 класса школы (Basic, Pascal), но потом был долгий перерыв. Вновь вернулся к этому делу только после университета, и пришлось многое вспоминать!
Зима, 6 утра, крепкий кофе, перед выходом на работу (работал тогда совсем не в IT)

static void main(String[] args) {     System.out.println("Привет!"); }

Эмоции: ЧТО ТАКОЕ String[] args???».

Владимир Акимов, старший фронтенд-разработчик: «Моя первая строчка кода была написана, потому что я очень хотел войти в рэп-тусовку. Мне было лет 17, я не умел читать рэп и писать музыку, и решил войти в крутую команду через дизайн.

Тогда никто не занимался продвижением независимых артистов в интернете. Так, нарисуют обложку друзья, выпустят диск, раздадут знакомым. И был сайт MySpace, где можно было круто оформить страничку музыканта. Я посмотрел, как это делают заграничные ребята. В какой-то момент наткнулся на парня, который жил в Германии и сделал страницу для Серёги. Того, который пел «Черный Бумер, помните»? Я решил подсмотреть, как делать подобное. MySpace был свёрстан на таблицах, я расколупал всю эту страницу, понял его идею и позаимствовал её.

Первые мои страницы были похожи на его страницы. Я делал одну за другой, пытался продвигать их. Так я подружился с одной командой. Там был дизайнер, который предложил мне писать код, а на себя взял картинки. Мы начали для всех наших популярных русских рэп-артистов делать MySpace-страницы. А потом меня пригласили работать в питерский офис MySpace работать.
Потом я написал там много строчек кода — однотипных, табличных: это были CSS и верстка, ничего сложного. Сейчас в этом любой джуниор разберётся и сделает круче. Но тогда это было «вау», потому что мы работали с IE5 и другими браузерами, для которых надо было делать кучу всего магического.

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

Константин Селезнев, бэкенд-разработчик: «На программирование меня «подсадил» мой одноклассник еще в седьмом классе (воистину, как на наркотик):
— Псс, парень, не хочешь немножко программирования? — примерно так он мне и сказал, всучив мне диск с Borland Development Studio и огромной коллекцией статей про Delphi.

Позже в одной из таких статей я нашел следующее: «Давайте прикольнёмся над пользователем. Например, выведем внезапно сообщение “Пора спать” и… вырубим монитор! Включить его чудилка уже не сможет…». Я попробовал приведенный в статье код, и у меня все получилось! Чувствовал себя настоящим хакером!

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

procedure TForm1.Button1Click(Sender: TObject); begin     MessageDlg('Уже поздно. Будь послушным мальчиком. Туши свет и вали спать!', mtInformation, [mbOk], 0);     SendMessage(Application.Handle, WM_SYSCOMMAND, SC_MONITORPOWER, 0); end;

А вот истории от ведущих подкаста Podlodka.

Стас Цыганов, руководитель мобильной разработки, Туту.ру: «Мама работала учителем информатики, и у меня довольно рано появился доступ к компьютерам. А моим первым опытом в программировании была Кукарача для MS-DOS. С интересом узнал, что она жива до сих пор и даже портирована на Windows.

ЭТО Ух  ПОВТОРИ 5 ВПРАВО КОНЕЦ

А первый код у меня был примерно такой».

Егор Толстой, руководитель разработки App Platform, Авито: «Лет в десять приехал в гости к старшему брату, у которого тогда появился первый компьютер, еще на MS-DOS. Помимо безудержных зарубов в первый GTA (в российской локализации он назывался прекрасным именем «Автовор») и Duke Nukem мы открыли для себя программирование. Математика меня тогда не сильно привлекала, а вот логические ветвления и рисование – в самый раз! Так первой программой и стала генерация супрематических композиций из кругов и линий: CIRCLE(10, 10), 50».

Катя Петрова, руководитель разработки Frontend Architecture, Авито: «Заставить черепашку в лого-мирах рисовать круги и писать «Hello world» на Pascal на уроках информатики — это, конечно, было занимательно и познавательно. Но ещё увлекательнее было в 8-м классе гонять на боссов в WoW Classic (тогда ещё не мейнстрим). Поэтому вот мои реально ПОЛЕЗНЫЕ первые строчки кода».

#showtooltip Regrowth /cast [@mouseover,exists,help][@player] Regrowth(Rank 5)

Женя Кателла, руководитель мобильной разработки, Яндекс.Транспорт: «Где-то в 8 или 9 классе я заинтересовался программированием, поэтому родители мне купили книжку по Turbo Pascal. До сих пор помню, что она была красная. И вот сначала там были простые вещи, вроде циклов и условий. А потом, кажется, первая глава заканчивалась рассказом про то, что такое рекурсия. И нужно было решить задачку про ханойскую башню. Поэтому, если не считать хеллоуворлдов, её и можно считать первой моей программой».

Самая запомнившаяся строчка кода

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

Андрей Shodan Аксёнов, руководитель инфраструктуры поиска: «Давным-давно, когда я трудился в геймдеве, мы руками сдуру ума написали свой собственный движок. Так делать в целом нельзя, это невозможно, но нам никто этого не рассказал. Поэтому мы написали с нуля свой и собственный движок, и весь инструментарий для разработки игры, и построили на этом игру, и всё это успели сделать за три года. Ну и в частности в ходе этого игростроя я придумал и сделал вот какой ловкий финт ушами. На самом-самом первом поколении графических программируемых ускорителей, где шейдера только ещё приделали, был недлинный период, когда GPU можно было программировать на ассемблере и руками раскладывать инструкции по слотам. Потом эту возможность отключили, оставили только HLSL, но в самом начале было можно. Вот мы в один проход умудрялись использовать четыре текстуры за раз (это тривиально), и одновременно считать освещение, карту неровностей, тени накладывать и еще что-то (а вот это никто не умел). У нас в компании было тогда если не 3 ноу-хау, то 2 ноу-хау, вот эта штука была основным. Потом, через годик-другой, когда технологии сдвинулись вперед и оно несколько потеряло актуальность, с разрешения начальства я статеечку в книжке ShaderX4 про это опубликовал. Это было очень красивое честное инженерное решение, за которое мне не стыдно до сих пор. Но это не одна строчка кода, а целых десять!».

    Listing 5.      #define POW c3 // c3.b=B, c3.a=A, for m=2. see [Beaudoin02]      dp3_sat r1.rgb, t1_bx2, t2_bx2       // (1) (N.H)      dp3_sat r0.rgb, t1_bx2, v1_bx2       // (2) (N.L)     +mad_x4_sat r0.a, r1.b, POW.a, POW.b // (2) (N.H)*A+B      mul_x4_sat r1.rgb, r0.a, r0.a        // (3) (N.H)^n     +mad r1.a, t0.b, SPECK.b, SPECK.a    // (3) specshadow      mul_sat r0.rgb, r0, r1_bx2.a   // (4) (N.L)*diffshadow     +mul_sat r0.a, r1.b, r1.a      // (4) ((N.H)^n)*specshadow      mad_sat r0.rgb, r0, DIFF, v0   // (5) (N.L)*shadow*diffcol+ambi     +mul_sat r0.a, r0.a, t1.a      // (5) ((N.H)^n)*shadow*specmap      mul_sat r0.rgb, r0, t3         // (6) diffmap*difflighting      mad_sat r0.rgb, r0.a, SPEC, r0 // (7) result     +mov r0.a, t3.a                // (7) diffuse map alpha

Даниил Попов, старший android-разработчик:

i  = 0x5f3759df - ( i >> 1 ); // what the fuck? 

Это фрагмент функции, которая вычисляет быстрый обратный корень из x. Такие вычисления нужны в игровых движках для обсчета освещения сцены. Этот нечитаемый код стал широко известным после выхода Quake III: Arena.

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

Илья Грибов, фронтенд-разработчик: «Мне запомнился этот код. Я подумал: “Как же просто и лаконично!)”».

>>> comp_list = [x ** 2 for x in range(7) if x % 2 == 0] >>> print(comp_list) // [4, 16, 36]

Михаил Юдин, старший android-разработчик: «Писал красно-черное дерево будучи студентом второго курса на acm.timus.ru по книжке Кормана, и что-то поехала крыша, и я проверил this на равенство null. Такая ситуация невозможна. Мне написали что я Ъ (типа true, суров)».

if (this == null)

Николай Рябов, старший фронтенд-разработчик: «Как-то, на моей первой работе, связанной с фронтендом, где я был ещё совсем-совсем зелёным джуниором, мне подкинул эту строчку для размышлений такой же начинающий разработчик, как и я, со словами: “друг, уже битый час пытаюсь понять что это такое и как оно работает — давай страдать вместе!”. В итоге голова моя была занята только этим и спустя пару часов я всё же понял что это такое, и что мы в результате получим в foo. Но объяснить я этого тогда ещё не мог.

const foo = Function.prototype.call.bind(Array.prototype.slice)

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

И не только код

Закончить этот пост я хочу, процитировав коллегу Андрея Shodan Аксёнова:

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

Часть историй, которые тут рассказаны, iseregin снял на видео и выложил на нашем ютуб-канале. Загляните, если любите видео.

Ещё раз поздравляем всех программистов (и заодно тех, кто с ними тесно работает). Проведите этот день приятно и интересно.
И делитесь в комментариях строчками и историями, которые вам больше всего запомнились!

Пару месяцев назад к нам в Ratio пришёл backend-разработчик по имени Алексей. У него за плечами травмирующий опыт: человек два года работал на себя, но это не было похоже на фриланс под пальмой.

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

Рабочее время

Фриланс: нет постоянного графика. Иногда работаешь 2-3 часа в день, но если приходит горящий проект, то нагрузка может прыгнуть до 12-14 часов в сутки. Зато в спокойные периоды можно посвятить целый день личным делам, фриланс в этом плане гибче.

Удалённо в штате: рабочий день 7 часов. Все переработки только по собственной инициативе, закрывать больше 35 часов в неделю никто не заставляет. Время начала и конца работы не контролируется, но как-то сам переходишь на офисный график: с 9-10 утра до 17-18 вечера. Так удобнее быть на связи с коллегами.

Финансы

Фриланс: доходы выше, после перехода в штат я потерял 30%.

Удалённо в штате: теряешь в зарплате по сравнению с фрилансом, но соотношение денег и затраченного времени выгоднее — дополнительные 30% получались за счёт переработок.

Стабильность

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

Самое обидное, когда тебя банально кидают. Вот список самых весёлых отмазок от моих заказчиков:

• «у меня нет денег заплатить тебе»
• «ты все сделал по ТЗ, но сейчас мне это уже не нужно»
• «ты договаривался не со мной, а с моим подчиненным — вот с него и требуй деньги»
• «интернет-банк глючит, деньги не переводятся»
• «сайт криво работает в Internet Explorer 7, платить не буду» (!)

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

Удалённо в штате: зарплата раз в две недели. Можно планировать взносы по кредитам и в целом вести более осознанную финансовую жизнь.

Юридические вопросы

Фриланс: юридически я был почти не защищен. За два года на моё имя написали две досудебных претензии, по которым пришлось возвращать предоплату. И вот почему эти проекты не были выполнены на самом деле:

• Заказчик не предоставил точное описание функций.
• Дизайнеры рисовали макеты в течение полугода. После клиент потребовал завершить все работы в течение двух недель. Разработка оценивалась в три месяца и за такой короткий срок выполнить её было нереально. В итоге я вернул 100 тысяч рублей предоплаты — у клиента были сильные юристы, суд скорее всего был бы не на моей стороне.

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

А вот с налоговой всё было спокойно. Дела вёл через контур.эльба, проблем не возникло.

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

Поток задач

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

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

Удалённо в штате: есть чёткое понимание, что и в каком порядке необходимо делать. Сидишь и спокойно разбираешься с делами в порядке очереди.

Менеджерская нагрузка

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

Но со временем я понял, что трачу жизнь не на то, что по-настоящему нравится. Менеджерская нагрузка может занимать от 30% до 80% дня, поэтому ресурсов на написание кода почти не остаётся.

При этом за менеджмент как таковой много денег не возьмёшь. Большинству клиентов кажется, что если для решения задачи нужно написать 10-20 строк кода, то и заплатить можно за 30 минут работы. Не учитывается, что задачу несколько раз обсуждали на созвонах, формулировали ТЗ и потом тестировали продукт. Итог: оплата за 30 минут, реально было потрачено 5 часов.

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

Нервотрёпка

Фриланс: постоянно находишься в стрессе. Первая причина: бесконечные коммуникации, клиент может позвонить в 6 утра или в 11 вечера. После попыток объяснить, что это неуместно, чаще всего следует прекращение сотрудничества. Но адекватные заказчики тоже попадались.

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

Третья причина: неадекватные заказчики. Некоторые позволяют себе оскорбления, даже матом кроют. У меня был клиент, который обещал «лично приехать и поговорить» из-за того, что я требовал предоставить материалы для разработки.

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

Удалённо в штате: объективно нервотрепки меньше. Но бывают дни, когда есть срочные задачи, которые нужно сделать как можно быстрее, бросив всё остальное. Также переживаешь о том, чтобы не подвести команду, но это обычные рабочие моменты.

Здоровье и отдых

Фриланс: Появились проблемы со здоровьем в виде головных болей и повышенного давления — следствие бессонных ночей и бесконтрольного употребления кофе и энергетиков.
Не был в отпуске 2 года. Забыл, что такое выходные (теперь вспомнил). Жена видела только мою спину по вечерам, мы практически перестали общаться.

На спортзал времени не было. Из-за сидения за компом по 10-14 часов в сутки я набрал около 25 кг.

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

Уровень задач

Фриланс: деградация как специалиста. Проекты в основном доставались типовые: сайт-визитка, интернет-магазин. Интересного было мало, поэтому профессиональный рост прекратился.

Удалённо в штате: за два месяца работы в Ratio я узнал нового больше, чем за два года фриланса. Со мной постоянно возится мой тимлид и руководитель отдела разработки, отвечая на любые, иногда даже самые глупые, вопросы. Большое преимущество работы в команде — это возможность обменяться опытом. Мне дают советы, подсказывают, как сделать задачу быстрее.
Я начал использовать паттерны проектирования, разобрался с синтаксисом последних версий PHP. Код в целом стал получаться лучше структурированным. Также приятно вместе поработать над кодом: раньше писал в одиночку, часто без системы контроля версий.

Социализация

Фриланс: одичал, почти всё время проводил за компом. Из дома выбирался два-три раза в неделю, ничем, кроме работы, заниматься не получалось. Для меня было нормой не стричься по 2-3 месяца, бороду отрастил — полный набор. Новую одежду также покупал крайне редко, я же никуда не выходил.

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

Как я адаптировался к работе в штате

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

Сложно было перестроить восприятие: руководство поначалу казалось теми же заказчиками, которые будут драть за малейший косяк. Умом я понимал, что это не так, но подсознательно все равно такие мысли всплывали. Первое время простой вопрос «как дела/что с задачей» вызывал приступ паники — вплоть до отпаивания валерьянкой, очень боялся, что уволят. Позже пришло понимание, что тимлид спрашивает это для того, чтобы подсказать и помочь, если где-то возникли трудности.

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

Фриланс не для меня, но вы держитесь

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

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

Фриланс, каким он был у меня — это болото, возвращаться в которое нет никакого желания. Но у вас может быть другой опыт. Расскажите о нём в комментариях!