IT-сфера — штука неблагодарная и прогнозы тут такие же, как  с погодой прошлым летом, всё равно замёрзнешь. Или промокнешь. Или солнечный удар жахнет. Но с предсказаниями на 2019, как показало время, у нас вышло неплохо, поэтому мы решили рассказать о трендах CRM 2020, какими мы их видим для малого и среднего бизнеса. У нас их получилось совсем не символично 11, да и какие символизм и провидение в инженерной работе. Всё, что мы помещаем в тренды по версии нашей команды, основано на 14-летнем опыте работы на CRM-рынке, текущих делах в отрасли и запросах наших клиентов. В общем, за прогноз отвечаем.

Этой зимой погоду определять только так :-(

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

Чтобы направить вас на веселую и праздничную ноту, хочу поделиться с вами примерами тернистого пути тимлида с отсылкой ĸ сериалу Мандалорец.

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


Итак, немного о рабочих буднях тимлида:

1. Берешь на работу джуна, учишь его, лелеешь. Вкладываешь в него силы и время, а через год он расправляет крылья и уходит искать лучшее место с зарплатой в три раза выше.
   Таков путь.
2. Полгода отĸрыта ваĸансия на разработчиĸа без результата. На собеседования приходят мидлы, просят зарплату больше твоей и говорят, что уже есть офферы на эту сумму в других ĸомпаниях.
   Таков путь.

Привет, Хабр! Представляю вашему вниманию подборку, которая является переводом моей оригинальной статьи.

Если есть идеи что добавить в подборку — буду рад пообщаться в комментах. Наслаждайтесь!

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

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

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

Задумать разработку облачной хелпдеск-системы в 2018 году со стороны казалось не самой трезвой идеей — на первый взгляд рынок есть, отечественные и зарубежные решения есть, самописных систем тоже хватает. Задумать разработку новой системы, когда у тебя уже есть большая CRM-разработка и более 6000 «живых» и активных клиентов, которым постоянно что-то нужно, — так вообще ресурсное безумие. Но именно эти вот шесть тысяч и стали причиной, по которой мы взялись и написали свой хелпдеск. Параллельно мы проводили исследование рынка, общались с будущими своими конкурентами, мучали фокус-группу, тестили демо-версии в скромной надежде понять, что всё придумано до нас. Но нет — поводов остановить разработку мы не нашли. А первый выход на Хабр в начале августа показал, что всё было не зря. Поэтому сегодня несколько субъективно — о наших наблюдениях мира хелпдеск систем. 


Когда техподдержка работала как-то не очень

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

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

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

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

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

Чаще всего тарпиты применяют для защиты. Технику впервые разработали для защиты от компьютерных червей. А сейчас её можно использовать, чтобы испортить жизнь спамерам и исследователям, которые занимаются широким сканированием всех IP-адресов подряд (примеры на Хабре: Австрия, Украина).

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

«В течение недели мне предложили должность инженера-программиста в Google, Facebook, Amazon, Apple, LinkedIn и Yelp. Вот как я проходил у них собеседование.


Что если я скажу вам… что собеседования не так страшны, как кажется?

В последнее время веб-разработка разделилась. Теперь мы все не full-stack программисты — мы фронтендеры и бэкендеры. А самое сложное в этом, как и везде, это проблема взаимодействия и интеграции.

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

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

Привет! В рамках проекта devleads мы с ребятами решили сделать подкаст для всех неравнодушных к менеджменту в IT-сфере — тимлидов, руководителей разработки и им подобных.

Кто мы:

• Я, Илья Царев, руководитель мобильной разработки Альфа-Банка.
• Илья Кузнецов, imJustik, iOS-тимлид Альфа-Банка.
• Никита Майданов, NikoGenn, руководитель мобильной разработки в Welps.

В этом выпуске мы затронем тему профессионального выгорания (в частности — выгорания тимлида) и связанных с ним мифов. А поможет нам в этом психолог Анастасия Калашникова.

Мы поговорим о профилактике выгорания, о том, почему нормально говорить коллегам «Нет», что делать, если шеф сидит на работе по 10 часов, а вам неудобно из-за этого уходить вовремя, и о многом другом.

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

— Расскажи, пожалуйста, что такое вообще «выгорание».

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

Решение нужно было на PHP и следующий час был потрачен на его поиск. Удивительно, как об этом мало информации (хотя нет, не удивительно… кто вообще пишет такое на PHP...). В общем, дорога со StackOverflow привела к MadelineProto. На библиотеку довольно мало ссылок в сети.

Что такое Madeline?

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

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

Привет, Хабр! Представляю вашему вниманию перевод статьи How I Shipped My First SaaS Side Project While Working Full Time Тиграна Хакобяна, который работая в известном сервисе отложенного постинга Buffer смог запустить свой проект и даже его монетизировать.

Сайты по-прежнему загружаются слишком медленно. В самый критический момент процесса загрузки канал зачастую практически полностью простаивает. Новая технология, предложенная инженером Кадзухо Оку из Fastly, поможет лучше использовать эту критическую первую пару секунд.

Вы когда-нибудь загружали сайт на телефоне — и смотрели в течение 10 секунд на страницу без текста? Никто не любит сидеть и глядеть на пустой экран, пока загружается какой-то необычный шрифт. Поэтому есть смысл перенести загрузку таких важных вещей на максимально раннее время. Предзагрузка Link rel=preload должна была частично решить проблему. Первым делом браузер парсит HTTP-заголовки, так что это идеальное место, чтобы указать на предварительную загрузку ресурса, который точно понадобится позже.

В выпуске: PHP 7.3.0 alpha 3, PHPStan 0.10, Yii 1.1.20 и другие релизы, свежее предложение из PHP Internals по сравнению объектов, порция полезных инструментов, и многое другое.
Приятного чтения!

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

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

1. Дмитрий Ковпак, кандидат мед.наук, президент российской Ассоциации когнитивно-поведенческой психотерапии (КПТ), доцент кафедры психологии и педагогики СЗГМУ им. И.И. Мечникова.

2. Алексей Демьяненко, психотерапевт, заведующий Городским Психотерапевтическим Центром Санкт-Петербурга, руководитель регионального отделения Российской Психотерапевтической Ассоциации.

3. Наталия Дзеружинская, доктор мед.наук, врач-психиатр высшей квалификационной категории, профессор кафедры психиатрии и наркологии Национального медицинского университета имени А.А. Богомольца Украины. Более 30 лет работы в сфере психического здоровья.

4. Мария Берлин, организационный психолог, тренер, корпоративный психолог ЗАО РТК МТС(2015-2016), преподаватель института «Иматон», автор программы подготовки специалистов «Работа с эмоциональным выгоранием – комплексный подход».

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

Всем привет. Это моя юбилейная статья на Хабре. За почти 7 лет я написал 10 статей (включая эту), 8 из них — технические. Общее количество просмотров всех статей — около полумиллиона.
Основной вклад я внёс в два хаба: PHP и Серверное администрирование. Мне нравится работать на стыке этих двух областей, но сфера моих интересов гораздо шире.

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

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

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

Большинство разработчиков знают о важных и нужных HTTP-заголовках. Самые известные — Content-Type и Content-Length, это почти универсальные хедеры. Но в последнее время для повышения безопасности начали использоваться заголовки вроде Content-Security-Policy и Strict-Transport-Security, а для повышения производительности — Link rel=preload. Несмотря на широкую поддержку в браузерах, лишь немногие их используют.

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

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

Преамбула

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

1. Описывать своим коллегам правила обращения к серверу на пальцах
   Этот метод быстр и не требует долгосрочной поддержки, но высока вероятность, что вас за это будут бить.
   
2. Руками составлять Google-docs/Wiki/Readme в проекте
   Удобно тем, что однажды написанная документация не требует повторного объяснения. Её можно показать коллегам и даже иногда заказчику. Минусом данного метода является долгосрочная поддержка такой документации. Когда Api в проекте вырастает до таких размеров, что сама мысль "А когда же я обновлял документацию?" вызывает холодок по спине, тогда вы понимаете, что дальше так продолжаться не может. Формально вы можете обновлять документацию очень часто и маленькими фиксами, но это до первого отпуска.

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