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

Сразу скажу: я не считаю, что строить карьеру — это правильно, без этого никак и кто не строит — валенок. При этом я и не считаю, что не строить карьеру — правильно.

В карьере нет ничего плохого или хорошего. Так же, как нет ничего плохого или хорошего в изучении ERP, ремонте своей квартиры или прохождении курса «100 отжиманий». Карьера — это проект с определенной целью, в который человек сознательно вступает, чтобы чего-то получить. Взамен он должен потратить больше ресурсов, чем расходовал до этого — времени, нервов, денег.

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

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

Надеюсь, мы договорились. Возвращаемся к карьере.

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

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

Если вы ощущаете, что пришло время запустить ещё одну аппку в Kubernetes/ECS/whatever, то мне есть чем вам возразить.

English version is also available.

Объектно-ориентированная парадигма — стандарт для прикладного ПО. Реляционные СУБД — стандарт хранения данных в прикладном ПО. Да, можно писать и на Haskell и хранить данные исключительно в ClickHouse. Но речь о мейнстриме.

ORM позволяет натянуть сову на глобус сделать вид, что RDBMS'а нет и данные хранятся в объектной модели, более подходящей для ООП. Остается «маленькая» такая проблемка — эта абстракция, как и многие другие, «течет». Там где в объектной модели ссылка на другой объект в базе данных foreign key и id. В момент материализации сущности мы встаем перед выбором:

1. Загрузить все и упасть с out of memory / timeout
2. Явно указать какие зависимости мы хотим загрузить, а какие — нет и нарушить принцип tell don't ask
3. Загружать зависимости неявно по требованию с помощью Lazy Load и получить проблемы с производительностью где-то в вызываемом коде

Какую-же ногу себе отрезать: левую или правую?

TLDR Lazy Load не так плох, если использовать только для записи и не использовать при чтении. Но все не так просто и есть куча нюансов.

Проект

Прошедший год для Международного Экспериментального Термоядерного Реактора ИТЭР (о проекте) стал, для внешнего наблюдателя, наверное, одним из самых спокойных за все годы строительства (с 2009 года). Для меня же лично этот год был отмечен посещением площадки ИТЭР в сентябре 2018 года, поэтому этот ежегодный отчет будет разбавлен личными впечатлениями и фотографиями.



Три года назад у проекта официально сменился директор — им стал энергичный француз Бернар Биго. Осознавая сложное положение, в котором ИТЭР находился в момент начала его правления (нарастающее колоссальное отставание графика и перерасходы ставили вопрос о закрытии), Биго предпринял несколько важных управленческих решений, в том числе — создание “всеобъемлющего плана сооружения”. Как известно, графики такого масштаба точно соблюдаются только в момент создания/обновления, и за 2 прошедших года можно констатировать, что 100% следования даже новому графику нет. Однако, ситуация явно лучше, чем было в период 2009-2015 годов, и отставание на сегодня составляет 6-9 месяцев, тем более, что появляются варианты “уплотнения” планов сборки реактора. Величина в пределах года не слишком критична для такого проекта, вопрос в основном — что будет с динамикой отставания дальше?

Дальнейший текст — моя точка зрения. Возможно, она позволит кому-то по-новому взглянуть на дизайн языков программирования или увидеть какие-то преимущества и недостатки конкретных фич. Я не буду лезть в частные подробности типа "в языке должна быть конструкция while", а просто опишу общие подходы. P.S. У меня когда-то была идея создать свой язык программирования, но это оказалось довольно сложным процессом, который я пока не осилил.

Влияние предыдущего опыта

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

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

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

Мой опыт: когда-то я начинал с паскаля, впоследствии познакомился с Java, Kotlin, C++, Python, Scheme, а основными языком считаю Scala. Как и в вышеописанном случае, мой "идеальный" язык имеет много общего со Scala. По крайней мере, я отдаю себе отчёт в этом сходстве)

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

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

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

источник картинки

Встречали ли вы в C# конструкцию типа using (var scope = new TransactionScope(TransactionScopeOption.Required))? Это значит, что код, выполняющийся в блоке using, заключается в транзакцию и после выхода из этого блока изменения будут зафиксированы или отменены. Звучит понятно, пока не начинаешь копать глубже. И чем глубже копаешь, тем «страньше и страньше» становится. Во всяком случае, у меня при более близком знакомстве с классом TransactionScope и вообще транзакциями .NET возникла целая уйма вопросов.

Что за класс TransactionScope? Как только мы используем конструкцию using (var scope = new TransactionScope()), все в нашей программе сразу становится транзакционным? Что такое «управляющий ресурсами» (Resource Manager) и «управляющий транзакциями» (Transaction Manager)? Можно ли написать свой управляющий ресурсами и как он «подключается» к созданному экземпляру TransactionScope? Что такое распределенная транзакция и правда ли, что распределенная транзакция в SQL Server или Oracle Database — это то же самое, что и распределенная транзакция .NET?

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

У меня были все преимущества. Я уже был внутри сети. Я был вне подозрений. Но они обнаружили мой взлом, выкинули из сети… и выследили физически.

Ровно 30 лет назад с космодрома Байконур на ракете-носителе «Энергия» в свой единственный полёт отправился корабль «Буран». В полностью автоматическом режиме он совершил 2 витка вокруг Земли и успешно приземлился спустя 205 минут. Это стало несомненным триумфом советской космонавтики, впервые в мире сумевшей посадить многоразовый космоплан в автоматическом режиме на землю.

Но спустя всего год работы по проекту были приостановлены, а в 1993 году — и вовсе прекращены. В 2002 году единственный летавший в космос «Буран» был навсегда погребён под обломками цеха в котором хранился. Об предпосылках к появлению проекта «Энергия-Буран», его ходе и печальном завершении, пойдёт сегодня речь.

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

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

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

Некоторые люди как-то неправильно поняли WebAssembly. Есть те, кто считает, что раз браузеры уже поддерживают выполнение WebAssembly (ещё с 2017 года), значит всё уже готово. Даже и близко ещё нет, готов лишь MVP (минимально жизнеспособный продукт). Я могу предположить откуда произрастает корень этого заблуждения: после релиза MVP его разработчики пообещали поддерживать обратную совместимость на уровне «любой написанный сейчас код будет работать и в будущем». Но это ведь не значит, что разработка WebAssembly закончена, совсем нет! Множество фич разрабатывается прямо сейчас и планируется к разработке в ближайшем будущем. И когда они будут реализованы — всё очень сильно изменится.

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

Давайте посмотрим на то, что у нас уже есть сейчас и что нам ещё предстоит открыть.
(Под катом много картинок, трафик)

Это сделала птица:



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

Основные вещи:

— Аварийная посадка в неровную кустарниковую степь часто безопаснее посадки на воду.
— Парашюты как системное явление снизят безопасность пассажиров.
— 30 лет — нормальный срок жизни самолёта. 20 лет — самолёт ещё молод.
— При отказе двигателя на взлёте есть ситуации, когда надо продолжать взлёт.
— Отказ всех двигателей не означает катастрофу при определённой скорости.
— В меру жёсткий удар при посадке безопаснее, чем «kiss landing»,
— Для чего каждый полёт стюардессы проводят инструктаж.

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

Для большинства разработчиков использование expression tree ограничивается лямбда-выражениями в LINQ. Зачастую мы вообще не придаем значения тому, как технология работает «под капотом».

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

Вы узнаете, как пользоваться expression tree напрямую, какие подводные камни приготовила технология и как их обойти.



Под катом — видео и текстовая расшифровка моего доклада с DotNext 2018 Piter.

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

Что это вообще, блин, такое?

Доброго конца недели, хабралюди! Как было заметно из прошлых статей, посвящённых Марсу и околомарсианской тематике, тема хардкорной колонизации Марса будоражит умы многих неравнодушных граждан. Если ты из тех самых граждан и увидеть цветущие под марсианским небом яблони — для тебя вопрос принципа, то заходи.

Привет, Хабр! Мы выложили видеозаписи докладов с конференции DotNext 2018 Piter. Получился плейлист из 26 видео! В нашей подборке под катом будут десять, но только самых лучших, получивших высшие оценки от зрителей. Если есть силы смотреть все доклады из плейлиста — мы только рады.
 
Традиционно, чем ниже доклад по списку, тем выше его рейтинг. Но очень важно понимать: все доклады имеют примерно одинаковые оценки, около 4,36-4,49 баллов, и расположение может легко измениться, стоит немного поменять методику подсчета. К примеру, на доклад, занявший второе место с рейтингом 4,48, отзывов в несколько раз больше, чем на лучший доклад с рейтингом 4,49. В общем, смотреть нужно всё.

Под катом все видео разбиты с оглавлением по содержимому поста, презентациями и короткими описаниями.

Ваш компьютер не является быстрой версией PDP-11

Привет, Хабр!

Меня зовут Антон Довгаль, я С (и не только) разработчик в Badoo.

Мне попалась на глаза статья Дэвида Чизнэлла, исследователя Кембриджского университета, в которой он оспаривает общепринятое суждение о том, что С — язык низкого уровня, и его аргументы мне показались достаточно интересными.

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

Производители процессоров не одиноки в этом. Разработчики компиляторов C/C++ тоже внесли свою лепту.

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

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

Такие офисы обычно ужасны, но есть варианты

Об авторе: Джейсон Фрайд — основатель и исполнительный директор Basecamp



На прошлой неделе DHH [создатель Ruby on Rails, основатель и технический директор Basecamp — прим. пер.] разнёс в пух и прах открытые офисы. Он прав. Но погодите, ведь мы сами работаем в офисе такого типа. И мы проделали достойную работу, чтобы улучшить ситуацию. Может, есть смысл поделиться опытом.