О том, как я пыталась поступать в самые лучшие ВУЗы планеты на прикмат и что я из этого вынесла.

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

Результаты публикации этих 150 статей оказались очень и очень разными:

— Два поста оказались крайне успешными, добрались до главной страницы Hacker News (первый — о том, что произошло со всеми непрограммистами, второй — о читабельности, хакабельности и абстрагировании кода).

— Дэн Луу, после того, как увидел второй из вышеупомянутых постов, подписался на мой блог и начал слать на Hacker News многие мои материалы. В результате ещё штук 5 статей стали довольно-таки популярными. Это привело к приходу в мой блог первой волны подписчиков, с которыми я не знаком лично. Плюс — это дало мне серьёзную мотивацию писать дальше. Я и Дэн, в итоге, стали хорошими друзьями.

— Примерно 95% оставшихся постов получились совершенно непримечательными.

Это — очень типичный разброс результатов публикаций, на который могут рассчитывать блогеры: несколько «хитов» и куча «хлама». Через восемь лет я развил достаточно хорошее чутьё на то, какой пост найдёт отклик у читателей. В результате я смог почти полностью уйти от написания совершенного «хлама». Но, даже учитывая это, несколько моих лучших недавних постов (этот и этот) оказались гораздо успешнее других. Речь идёт о том, что многие делились с другими ссылками на них, и о комментариях к ним, вроде «то, что я узнал, сильно на меня повлияло».

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

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

Артем Мурадов — Senior Software Development Engineer в Amazon и автор курса «Алгоритмы: roadmap для работы и собеседований». Уже больше 14 лет он использует алгоритмы для решения рабочих задач и прохождения собеседований. С помощью алгоритмов он повышал производительность приложений, побеждал в спорах с коллегами и ускорял исследование ДНК. Даже попасть в Amazon ему помогло знание алгоритмов.

Мы пообщались с Артемом, чтобы узнать о его опыте. Он подробно рассказал, как изучал алгоритмы и как они помогали ему в работе.  

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

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

В Одноклассниках запросы пользователей обслуживает более 200 видов уникальных типов сервисов. Многие из них совмещают в одном JVM-процессе бизнес-логику и распределенную отказоустойчивую базу данных Cassandra, превращая обычный микросервис в микросервис с состоянием. Это позволяет нам строить высоконагруженные сервисы, управляющие сотнями миллиардов записей с миллионами операций в секунду на них.

Какие преимущества появляются при совмещении бизнес-логики и БД? Какие нюансы надо учесть, прибегая к такому подходу? Что с надёжностью и доступностью сервисов? Расскажем подробно об этом всём.

Всем привет, я — Сергей Бобрецов, CTO в Wildberries. 

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

Стоит начать с того, что основным генератором прогресса в WB с самого начала и по сей день является фактор роста. По бизнес-метрикам мы растем примерно х2 каждый год уже много лет, а по техническим (количестуву запросов / транзакций / трафику / объему данных и т. д.) — рост может быть даже быстрее, и это создает множество вызовов: технических, архитектурных и организационных. 

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

Сегодня я хочу рассказать немного про нашу инфраструктуру.

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

Для тех, кто предпочитает сразу прочитать выводы:

Альтернативой акциям индексного фонда (например, ETF FINEX FXRL) на индекс RTSI (IMOEX) на российском рынке являются акции Сбербанка, так как они с высокой точностью следуют за индексом (корреляция 0.7-0.9) и показывают большую доходность

Mac наступает со своим чипом M1. Новичков в этой экосистеме должно заметно прибавиться. Сам я многие годы с уважением смотрел на эти интерфейсы. Слушая какой же Mac удобный, плавный и интуитивный. Какой там великолепный Trackpad, что даже мышь не нужна и бла бла бла. И вот, после 15 лет работы CAD разработчиком, я решил поменять профиль и стать программистом. А чтобы не терять мотивацию в процессе обучения, выбрал для себя наиболее наглядное направление, как мне показалось — iOS разработка. Сказано — сделано. MacBook Pro 16” уже год мой основной компьютер.

К старту курса о Fullstack-разработке на Python мы подготовили сокращённый перевод опроса StackOverflow среди почти 83 000 людей, без малого 70 % из них — профессиональные разработчики. Опрос проводился с 15 июня по 25 мая, облачные платформы в нём впервые выделены из платформ в целом, также добавлен раздел о том, с какими языками, платформами, фреймворками и т. д. людям хотелось бы работать. Конечно, вы найдёте в опросе информацию о зарплатах и образовании. Подробности, как всегда, под катом.

Спор «фуллстек против узкой специализации» вечный. Но одно дело — спорить в комментах, а совсем другое — создать собственную компанию и проверить экстремальный подход на практике. Антон Кекс пошел по этому пути: стал сооснователем компании Codeborne, где разработкой занимаются исключительно «фуллстек-крафтсмены» и практикуется экстремальное программирование. И по его словам, там командами из 2-4 человек получается сделать то, на что другим требуется человек 50.

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

Можно не соглашаться с его позицией, но как минимум ознакомиться с ней полезно. И хотя доклад сделан еще пару лет назад, в 2021-м он продолжает собирать просмотры, поэтому мы решили сделать для Хабра текстовую версию. Под катом — и видеозапись, и текстовая расшифровка. Дальше повествование ведется от лица Антона.

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

Если вы следите за образовательными новинками, вас будет трудно удивить. Мультимедийные курсы, вебинары и тому подобные изобретения появляются каждый день. Учиться можно дома и на работе. Главный же недостаток новомодных курсов - материал исчезает из памяти так же быстро, как и проникает в нее. Но есть открытия в области образования, которые по-настоящему меняют то, как мы учимся, а иногда даже спасают человеческие жизни! Давайте разберемся в “компонентах” успешных курсов.

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

Проблема неполной индукции

Знаменитый древнегреческий философ Аристотель в своем трактате «Аналитика» выделяет два вида возможных умозаключений - индуктивное и дедуктивное.

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

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

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