Интернет пестрит захватывающими историями о людях, которые бросили наёмную работу ради собственного бизнеса. У Сергея Парахина, разработчика из московского офиса EPAM, ситуация другая. Он больше 20 лет развивал свой собственный бизнес, который всегда был связан с IT. По иронии судьбы именно стремительное развитие информационных технологий в корне изменило его компанию, и бизнес всё дальше уходил от IT-сферы. Это побудило Сергея задуматься о смене профессии, и он решил стать разработчиком.

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

Я работаю в коммерческой разработке с 2011 года. С конца 2012 занимаюсь разработкой под iOS. Свою первую техническую статью я написал на Хабре в начале 2017 года про подход к локализации мобильных приложений. Потом выпустил ещё несколько статей по iOS-разработке на Хабре и в конце 2017 года я перешёл в новую компанию и решил вести блог про solution architecture https://medium.com/@nvashanin, где начал описывать общие концепты, обязанности архитектора, его скилл-сет и т.д. К лету 2020 года количество просмотров моих статей перевалило за 800 тысяч, а количество времени, которое люди потратили на прочтение — больше 6 млн минут, или около 12 лет чистого времени. Флагманская статья была переведена другими людьми на разные языки: например, польский или испанский.

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

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

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

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

Будут затронуты следующие темы:

• Как ClickHouse хранит данные на диске и выполняет запрос, почему такой способ хранения позволяет на несколько порядков ускорить аналитические запросы, но плохо подходит для OLTP и key-value нагрузки.
• Как устроена репликация и шардирование, как добиться линейного масштабирования и что делать с eventual consistency.
• Как диагностировать проблемы на production-кластере ClickHouse.

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

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

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

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

В современной индустрии уже много десятков лет доминирует парадигма ООП и у многих разработчиков складывается впечатление, что она лучшая или и того хуже — единственная. На эту тему есть прекрасное видео Why Isn't Functional Programming the Norm? про развитие языков/парадигм и корни их популярности.

SOLID изначально были описаны Робертом Мартином для ООП и многими воспринимаются как относящиеся только к ООП, даже википедия говорит нам об этом, давайте же рассмотрим так ли эти принципы привязаны к ООП?

Во время тотальной самоизоляции разработчики стали ещё активнее интересоваться онлайн-ивентами, где можно поучиться и попробовать силы в конкурсах. На этой волне мы запустили грантово-образовательный проект для нашего комьюнити. Не мелочась, заложили призовой фонд в 15 миллионов рублей. В этой статье расскажем, почему конкурс не сбавляет оборотов даже сейчас, когда никто уже не сидит дома, что ждёт VK Fresh Code дальше и какие приложения победили в первом этапе.

Если ваша IT инфраструктура растёт слишком быстро, вы рано или поздно столкнётесь с выбором – линейно увеличивать людские ресурсы на её поддержку или начинать автоматизацию. До какого-то момента мы жили в первой парадигме, а потом начался долгий путь к Infrastructure-as-Code.

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

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

Для наглядности я создал демо-сайт. Вот он.

Нажмите на каждую из трёх кнопок Page → На всех трёх один и тот же идентификатор.
Закройте окно браузера и снова откройте сайт → Идентификатор не поменялся.
Выключите компьютер и зайдите на эту веб-страницу завтра → Идентификатор всё тот же.
Проверьте ваши куки → Демо-сайт не записывает куки и не считывает их.
Проверьте URL → Сомнительные строки запроса отсутствуют.

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

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



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

Предисловие

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

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

Автор статьи: Елена Ленсу (Психотерапевт).
Специализации: организационное консультирование, долговременная терапия, работа с травмой, сексология.

---

Бизнес консультант, ex.HRD Pravo.Tech и Rocket10. Автор статей и преподаватель онлайн-курса «IT-Recruiter» в OTUS.

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

Критика — указание только на недостатки в том, что было сделано.

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

Мне, с того момента, как мы объявили о том, что в npm 7 будут поддерживаться файлы yarn.lock, несколько раз задавали один и тот же вопрос. Он звучал так: «Зачем тогда оставлять поддержку package-lock.json? Почему бы не использовать только yarn.lock?».



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

Спрос на IT-специалистов растет с каждым днем, вместе с этим увеличивается конкуренция. Для построения карьеры в хорошей компании уже недостаточно только профессиональный навыков (hard skills). Работодатели стали также обращать внимание и на так называемые “мягкие” навыки — soft skills. Это навыки, которые не связаны с профессией, а относятся больше к личностным качествам (коммуникабельность, креативность, эмпатия и тд). О том, действительно ли это так важно, какие навыки требуются и как их развивать — поговорим сегодня.

Почему soft skills стали необходимы?

Все мы знаем “известный” образ программиста: интроверт, в бабушкином свитере, растянутых штанах и очках. Конечно, в момент зарождения профессии (и появления этого стереотипа) ни о каких soft skills речи не шло, потому что, если ты умел писать код, то был уже крут! Сейчас сфера IT и сама профессия существенно изменилась.

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

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

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

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

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

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

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

Сложно такое осознать, я думал, меня настигнет эта участь несколько позже, когда мне будет хотя бы 30+ и я буду каким-нибудь крутым разрабом в известной компании, но мне 26 и я в NoName конторе.

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