User
Эта статья будет полезна прежде всего работадателям, HR, но так же и тимлидерам и всем, кто принимает участие прямое или косвенно в вопросах, касающихся найма сотрудников в IT сфере.
Итак, на текущий момент времени в постсоветском пространстве сложилась крайне интересная ситуация на рынке труда. Эта проблема, так или иначе присутствовала всегда. Но в последнее время она достигла неимоверных размеров.
Всем привет! В свободное от не-работы время я CTO собственной компании (DigitalWand), и как следствие – чем мне только ни приходится заниматься! И вот недавно один из наших клиентов посетовал на проблемы в своей внутренней кухне: мол, вирус положил внутренние сервисы, включая git и площадки для разработки. И тут мне вспомнилась собственная аналогичная проблема, которая произошла год тому назад. Вот эту страшилку и хотел бы рассказать. Думаю, будет полезна как начинающим сисадминам и девопсам, так и вообще людям, которые каким-то боком с линуксовыми серверами связаны, но серьёзного пороха ещё не нюхали.
IT-специалисты - одни из самых востребованных сотрудников. А высокий спрос на профессию - это всегда высокие зарплаты.
Давайте посмотрим, так ли это на самом деле. Сегодня мы поговорим исключительно про IT-управленцев, а в следующих публикациях расскажем о том, сколько зарабатывают в других IT-профессиях.
Для написания небольшого, но интересного исследования мы использовали данные, подготовленные компанией «Апрайт».
Мы расспросили наставников и код-ревьюеров Яндекс Практикума, как перейти из джунов в мидлы, что требуют на собеседованиях, какие навыки нужны и как их развивать.
Loom — платформа видеосвязи для асинхронной работы, позволяет записывать изображение с экрана и веб-камеры, делать обзоры проектов, давать комментарии к документам, тем самым ускоряя рабочие процессы. Сегодня у Loom 21 млн пользователей из 200 тысяч компаний.
Однако в 2016 году компания была на грани провала. Буквально за две недели до банкротства фаундеры смогли придумать фичу, которая помогла им не просто удержаться на плаву, а сделать из умирающего стартапа единорога с оценкой $1,5 млрд.
Американское выражение fake it till you make it, взятое на вооружение нашим коллективным сознательным, похоже, сыграло с нами злую шутку. Мы, как водится, расслышали это только наполовину, и в обиход взяли только первую его часть. Fake it. По итогу наша уже почти целиком виртуальная реальность выглядит так: мы попросту транслируем и внутрь, и наружу себя то, чем мы не являемся, в конечном итоге просто начиная верить в это сами.
Представьте: к вам в компанию пришел славный с виду, скажем, маркетолог. Приехал на самокате. Представился, понятное дело, маркетологом, резюме у него классное, на собеседовании разговаривал уверенно. Вы ударили по рукам, и маркетолог влился в проект, но спустя некоторое время что-то пошло не так. У вас стало зарождаться смутное сомнение, что маркетолог не совсем маркетолог — а при глубокой проверке резюме выясняется, что соответствующее образование у него отсутствует, делает он унылую непрофессиональную шнягу, а при просьбах показать метрики заболевает или находится не в ресурсе.
Является ли человек на самом деле отличным маркетологом, вы не проверяли, — что тут проверять и портить ему настроение недоверием — сказал, маркетолог, значит так и есть. Более того, очевидно, что человек ни разу не врет — он на самом деле уверен в эксклюзивности своих профессиональных скилов. Он уверен, что он — маркетолог. Не уверены в этом только вы и огромная гора его криво реализованных задач.
Это — самая примитивная иллюстрация явления, которое порождено выражением accountability gap. В данном случае в него попали и вы, и самоназванный маркетолог. И про выражение это позвольте поговорить подробно отдельно.
Всем привет, на связи Юджин, (теперь уже) беспризорный backend-разработчик на Go. Сегодня я расскажу вам забавную и больную историю о том, как мы монолит распиливали. Кто-то, может, посмеётся, а может, найдёт в этом себя.
Не всегда провалы проектов связаны с плохим планированием, недостаточными компетенциями или ошибками в разработке. Иногда из-за «черных лебедей» проект начинает жить настолько бредовым и непредсказуемым образом, что ты ощущаешь себя героем трагикомедии.
У лукоморья дуб зеленый;
Златая цепь на дубе том:
И днем и ночью кот ученый
Все ходит по цепи кругом;
Идет направо – сайты кодит,
Налево – платы мастерит.
Там чудеса: там леший бродит,
…
(из поэмы А. С. Пушкина «Руслан и Людмила», две строки изменены автором этой статьи).
Кто не рискует, тот не запускает проектов. Ведь создавать что-то новое — это всегда небезопасно. Всегда есть шанс, что изначальный план предусмотрел не все, потребуется больше ресурсов для достижения результата или появятся новые факторы извне.
Поэтому в управление проектами всегда должна входить работа с рисками. Поиск их причин и вариантов предотвращения. Иначе одно непредвиденное обстоятельство может погубить весь ваш проект.
«Жизни многих людей в современном мире зависят от программного обеспечения, например, оно контролирует системы управления большими коммерческими авиалайнерами. Тем не менее, сфера разработки ПО практически никак не регулируется. Любой может стать разработчиком-самоучкой, при этом нет никаких сертификаций или правил, как в других профессиях с высокими ставками, например, в архитектуре или нейрохирургии. Это угрожающе нерегулируемая сфера, хотя несколько строк плохого кода могут привести к смерти».
В данной статья я хочу рассказать, как работать с X509 сертификатом используя OpenSSL 3.0.0 в С++, начиная от генерации своего сертификата и заканчивая его валидацией.
Так как информации в интернете по этой теме почти нет, то все, что я вам расскажу, я узнал исходя из своего печального опыта работы с этой библиотекой. Я очень надеюсь, что эта статья окажется вам полезной и сможет сохранить ваше время.
В данной статье, я не буду рассказывать вам, что такое X509 сертификат, надеюсь, что это вы уже знаете, а если нет, то ссылка на статью вот тут.
На своей первой «большой» работе я совершила глупую ошибку: увидев токсичного руководителя и хор активных подпевал, я не уволилась. В свои 22 года «вузовско-тепличная» я решила, что главное — хорошо работать, и тогда никто тебя не тронет. Ну то есть ты сидишь в роли компьютера, чётко выполняешь задачи, не косячишь и считай, дело в шляпе, а заботиться о выстраивании отношений не нужно. Ну это же работа! Между тем, оказалось, что работа — это отдельный социум со своими законами и правилами, все сотрудники — люди и характер на крючок рядом с курткой не вешают, а при желании можно найти провалы и пробелы в абсолютно любой задаче. На усвоение довольно строгих и важных уроков у меня ушло 4 года, которые закончились увольнением…из-за чисто человеческого конфликта на уровне «кто кого выживет». После такой практики вот уже 11 лет практически ни одного рецидива, не считая мелких и чисто личностных стычек. Главные выводы тех лет: 1) общаться придётся; 2) над отношениями нужно работать; 3) работать на фоне конфликта нереально тяжело и непродуктивно; 4) конфликты сажают здоровье.
Позже выяснилось, что таких исследователей отношений в коллективе немало — так почему бы с высоты социально опыта не собрать пачку лучших статей. Учитесь на чужих ошибках :-)
Разбор громких инцидентов с Road Show SearchInform на Хабре имеет шансы стать традицией. В прошлом году я представил реконструкцию инцидента, связанного с выносом базы данных за пределы одной финансовой компании. Его главным и единственным организатором был ловкий и умелый инсайдер «Иван Денисович».
В этот раз источником вдохновения послужило не менее любопытное дело. Оно также связано с утечкой информации, но уже с другими героями в главных ролях. Решил реконструировать инцидент. Как и в прошлый раз: «все выдумано, а совпадения случайны».
Участники: Карл - инсайдер, Клара - жертва, Кораллы - данные почтового ящика Клары.
Под катом рассказываю, как Карлу удалось украсть «кораллы» и нанести компании ущерб в 100+ млн рублей, каким образом его вычислили и как он оправдывал себя в суде. И самое главное – показываю, какими инструментами компания могла бы упростить себе поиски виновного и предотвратить инцидент.
Или как в банке внедрить облачные технологии так, чтобы это было удобно, безопасно, быстро и дёшево.
Облака, сценарии, подводные камни, IAAS, ГОСТы и безопасность — об этом поговорили 22 марта в офисе Альфы на Alfa Cloud Day, митапе об облачной инфраструктуре и технологиях. А ещё о том, почему cloud-инфраструктура не сильно дешевле и как при этом продать бизнесу идею «Нам нужно облако» в виде пошаговой «инструкции», которую вы сможете использовать, если захотите поэкспериментировать с облаками. Для тех, кто не смог побывать, собрали основные мысли и выложили видеоверсии докладов.
Недавно я решила попробовать реализовать задачу анализа эмоциональной окраски отзывов с Кинопоиска. Я бы хотела поделиться своим опытом и описать шаги, которые использовала для реализации стоящей передо мною задачей.
Итак, в самом начале у меня был только датасет и опорный план для дальнейшей реализации всего этого дела, приступим :)
Шаг 1: получение данных | main.py + reviews_data.zip
Скачиваем json-файлы с отзывами и затем читаем данные из файла. Добавляем полученные отзывы в общий список.
Сколько статей было написано на хабре от обучающих курсов, как тот или иной человек вошел в ИТ, несмотря на то, что он сам юрист и ему уже за 40 лет. Такие статьи вселяют надежду, как передающиеся из уст в уста рассказы о чудотворцах, которые могли исцелять одним касанием.
Давайте посмотрим немного повнимательнее на эту сферу ИТ, выбросим всю эту СМИ мишуру, снимем пару ведер лапши с ушей.
Интро
В статье разбираются когнитивные искажения в разрезе влияния на исследователя, она будет полезна как исследователям (особенно джунам и мидлам), так и заказчикам исследований, чтобы понимать какие опасности подстерегают нас всех в увлекательном путешествии под названием UX-исследования.
Естественно, читаю не все (сорри, но темы, которые уже знакомы, проходят только поверхностный фильтр адекватности), однако часто встречается и то, что привлекает внимание и заставляет прочитать полностью и делать для себя заметки. Еще реже появляются статьи, которые прямо хочется прокомментировать или тем более перевести. В этот раз мне попалась отличная, но платная, статья The dark side of User Research: How cognitive biases taint results, которую не только захотелось перевести, но и дополнить собственными комментариями и ссылками.
Получившийся лонгрид сложно охватить за чашечкой кофе или по пути на работу. Рекомендую делать заметки для лучшего запоминания и возвращаться к материалу, когда возникает такая потребность.
В сети вы можете найти множество статей на тему «UML мертв», «Почему системным аналитикам не нужен UML» и множество подобного. Работая на протяжении последних 15 лет в совершенно разных компаниях, с совершенно разным жизненным циклом приложений и систем, с различной структурой и методологиями разработки я вижу одно и тоже — попытки ускорения time‑to‑market за счет отказа от процесса управления требованиями, подаваемые под разными прекрасными аргументами, приводят 100% компаний к необходимости переписывать приложения не потому, что оно не отвечает требованиям, а потому что «никто не знает как или почему оно так работает».
Важной проблемой отказа от нормального процесса управления требованиями является то, что разрабатываемые без этого процесса приложения и системы получаются абсолютно не гибкими и даже элементарнейшие, с точки зрения заказчиков, изменения приводят к запуску полного цикла разработки.
Можно перечислить еще огромное количество проблем, к которым приводит разработка без модели требований.
