Я — профессиональный участник инновационной индустрии. Вместе с коллегами последние 10 лет мы участвуем в создании новых технологий.

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

Привет! Я три года назад читал в детском лагере лекцию про социнжиниринг, троллил детей и немного бесил вожатых. В итоге испытуемые спросили, что почитать. Мой дежурный ответ про две книги Митника и две книги Чалдини, вроде, убедителен, но только для примерно восьмиклассника и старше. Если младше — то надо сильно чесать голову.

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

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

Буду рассказывать на примере сайта по мужской психологии, который я открыл в 2011 году (год очень важен!) Информация о которой я рассказываю уже не особо актуальна, зато поможет вам сэкономить время и отказаться от идеи открыть свой тематический портал.

Итак, 2011 год, я глупый и наивный парнишка, мой первый тематический сайт!

В данный момент ноутбуки и персональные компьютеры сильно отличаются друг от друга. Под системным блоком стационарного компьютера, как правило, понимается «башня» преимущественно стандарта midi-tower, весом килограмм в 15-20 (или больше), занимающий огромное пространство под столом. Чтобы перемещать системный блок с места на место, как правило, требуются большие усилия.

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

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

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

Индексы — это первое, что необходимо хорошо понимать в работе SQL Server, но странным образом базовые вопросы не слишком часто задаются на форумах и получают не так уж много ответов.
Роб Шелдон отвечает на эти, вызывающие смущение в профессиональных кругах, вопросы об индексах в SQL Server: одни из них мы просто стесняемся задать, а прежде чем задать другие сначала подумаем дважды.

Привет, Хабр! Представляю вашему вниманию перевод статьи "Things I Don’t Know as of 2018" автора Дэна Абрамова.

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

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

Эта статья о том, как применить принципы Domain-Driven Design (DDD) к классам, отображаемым Entity Framework Core (EF Core) на базу данных, и почему это может быть полезно.

TLDR

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

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

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

В карьере нет ничего плохого или хорошего. Так же, как нет ничего плохого или хорошего в изучении 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»,
— Для чего каждый полёт стюардессы проводят инструктаж.

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