Ленивая загрузка компонентов в Angular? Может, речь идёт о ленивой загрузке модулей с помощью маршрутизатора Angular? Нет, мы говорим именно о компонентах. Текущая версия Angular поддерживает лишь ленивую загрузку модулей. Но Ivy даёт разработчику новые возможности в работе с компонентами.

Краткая суть ситуации: наш соотечественник fafhrd91 на протяжении 3 лет практически самостоятельно (см. кдпв) писал actix-web — один из популярнейших крейтов в инфраструктуре раста, лидер в большинстве различных бенчмарков, и за это время подвергался как минимум трём волнам гонений за "неправильное использование раста". После последнего раза автор психанул, и перенес репозиторий к себе в аккаунт с пометкой "Планирую скрыть репозиторий". Конечно, куча людей сразу наделало зеркал и бекапов, но на мой взгляд это не сильно исправляет ситуацию.

На месте репозитория автор оставил единственный postmortem, который я ниже и цитирую целиком:

Если вы читаете этот текст – значит, вы либо подумали, что с заголовком статьи что-то не то, либо увидели в нём название знакомой компьютерной игры. VVVVVV – это инди-игра в жанре «платформер», завоевавшая сердца многих игроков своей приятной внешней простотой и не менее приятной внутренней сложностью. Несколько дней назад VVVVVV исполнилось 10 лет, и автор игры – Terry Cavanagh – отметил этот праздник публикацией её исходного кода. Что же «вкусненького» можно в нём найти? Ответ читайте в данной статье.

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

Работая с Javascript / Typescript, я давно заметил, что асинхронное API работает медленней чем аналогичное синхронное, и даже знал что так должно быть. Но в последнем проекте асинхронная работа с файловой системой стала узким местом, и я озаботился замерами.

Известно, что await можно использовать только внутри функций или блоков async, а это значит, что если у нас самый нижний уровень API асинхронный, то придется использовать async/await практически везде, даже там, где оно очевидно не нужно.

К примеру, мы пишем сервисную функцию, которая достает из хранилища объект по ключу. В качестве хранилища мы можем использовать файл, БД, микросервис, то есть медленный источник с асинхронным интерфейсом. Для улучшения производительности — внутри нашей функции мы кэшируем ранее извлеченные объекты (складываем их в Map). По мере работы программы реальных обращений к хранилищу становится все меньше, объекты отдаются из быстрого кэша, но интерфейс функции остается асинхронным!

Какую цену мне приходится платить за каждый асинхронный вызов?
Результаты тестов удручают...

ЛОЛШТО?

Пожалуйста, не поймите меня неправильно. Я профессиональный разработчик с 30-летним стажем. Я могу читать и понимать почти двадцать языков, полных по Тюрингу. Я могу писать ясный и выразительный код на доброй дюжине из них. В языках, которые я действительно люблю и использую ежедневно — мое имя можно увидеть на доске почета StackOverflow (топ-20 в мире: ruby, elixir). Я по-настоящему люблю писать код, и я отклоняю все предложения «вырасти» по должностной лестнице, будь то руководство проектами, CTO, или что угодно в этом направлении, несмотря на потенциальное увеличение дохода в разы.

— Abraham Willemsens (Metropolitan Museum of Art)

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

С++, благодаря своей строгой типизации, может помочь программисту на этапе компиляции. На хабре уже довольно много статьей, описывающих как, используя типы, добиться этого, и это прекрасно. Но во всех, что я читал, есть один изъян. Сравним с++ подход и си подход с использованием CMSIS, привычный в мире программирования микроконтроллеров:

some_stream.set (Direction::to_periph)    SOME_STREAM->CR |= DMA_SxCR_DIR_0
   .inc_memory()                                          |  DMA_SxCR_MINC_Msk
   .size_memory (DataSize::word16)                        |  DMA_SxCR_MSIZE_0
   .size_periph (DataSize::word16)                        |  DMA_SxCR_PSIZE_0
   .enable_transfer_complete_interrupt();                 |  DMA_SxCR_TCIE_Msk;

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

Введение

В данном посте будет описано создание простого упаковщика исполняемых файлов под linux x86_64. Предполагается, что читатель знаком с языком программирования си, языком ассемблера для архитектуры x86_64 и с устройством ELF файлов. В целях обеспечения ясности из приведённого в статье кода была убрана обработка ошибок и не были показаны реализации некоторых функций, с полным кодом можно ознакомится перейдя по ссылкам на github (загрузчик, упаковщик).

Идея состоит в следующем — мы передаём упаковщику ELF файл, на выходе получаем новый со следующей структурой:

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

Два основных блока:

1. Откуда взять идею (фидбек, метрики, конкуренты).
2. Как выбрать нужную идею, приоритизация.

Как происходит процесс

Выстраиваем иерархию целей. На верхнем уровне находятся:

1. Цели компании: чего на данный момент хочет компания (владельцы, стратегический менеджмент), в том числе, от вас, как от одного из руководителей. Далее, у компании есть набор сервисов, внутренних или внешних, и следующий уровень —
2. цели и метрики конкретного сервиса, который вы представляете. На третьем уровне определяем
3. идеи под цели и метрики сервиса – фичи, которые хотели бы реализовать, и которые скоррелированы с метриками вашего сервиса. Этапы:
   
   а) сбор,
   б) категоризация,
   в) приоритизация.
   
   После этого получаем
4. планы по релизам, которые уже отправляем в разработку.

1. Цели компании

Цели меняются с ростом продукта. Продукт проходит несколько стадий (от зарождения до стагнирования), и на каждой стадии фокусные метрики меняются вместе с целями.

1 стадия: хороший продукт

У нас появилась какая-то идея, и есть цель – сделать качественный продукт, убедиться, что он пользуется спросом, и что люди готовы за него платить. У цели есть метрики, на которые смотрит компания: это могут быть показатели:

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

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

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

Статья доработана с учетом ценных комментариев, дополнен список источников.
Данный чек-лист — компиляция нескольких источников, я его делал для себя, когда в конце 2019 года покупал 13" б/у макбук 2015 года, последний из имевших нормальную клавиатуру и набор портов, перед тем как Apple перешла на клавиатуру-бабочку и usb-с порты.

Какую модель б/у макбука стоит брать? Вместо введения

На этот вопрос нет однозначного ответа, поскольку все зависит от ваших задач. Для начала 2020 года и задач «офисной» работы и серфинга я бы сформулировал ответ так — можно брать любой мак от 2014 и более позднего года выпуска, на полноценном процессоре (m5 и m7 брать скорее нежелательно). Macbook pro таким образом предпочтительнее macbook air, поскольку у последних процессор и система охлаждения обычно проигрывает в сравнении.

Оптимальный выбор, который проработает еще несколько лет без проблем — это модели с четырехядерным процессором (не путать с четырехпоточным!), такие ставили обычно в 15" модели. Оперативки не менее 8 Гб, SSD лучше 256 Гб и больше, хотя на 128 с определенными неудобствами жить тоже можно. Батарея оптимально с менее чем 500 циклами перезарядки.

Стоимость 13" макбуков 2014-2016 годов колеблется от 40 до 55 тыс. рублей, причем варианты в хорошем состоянии около 40-45 тыс. мне кажутся наиболее выгодными с точки зрения дилеммы «взять б/у или доложить и взять новый».

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

Моделей с клавиатурой-бабочкой (2016-2019 гг) не то что бы надо избегать, но надо отдавать себе отчет, что они требуют радикально более бережного к себе отношения, чтобы клавиатура проработала дольше. Сейчас полно предложений продажи mac mini — это тоже хороший вариант, особенно если он базируется на нормальном четырехядерном процессоре.

Системы контроля версий уже давно стали повседневным инструментом разработчика. В больших монорепозиториях требования к ним оказываются весьма специфическими. Из-за этого компании либо адаптируют существующие решения, как это делает Facebook с Mercurial и Microsoft с Git, либо разрабатывают собственные системы: Piper и CitC в Google и Arc VCS в Яндексе.

В докладе разработчик Владимир Кихтенко kikht рассказывает, зачем Яндексу понадобилась собственная система контроля версий и как она работает. Рассмотрим её со стороны рядового разработчика: как получить доступ к исходному коду, отвести ветку для разработки и интегрировать изменения в общую кодовую базу. Заглянем под капот — узнаем про внутреннее представление данных и их отображение в виртуальной файловой системе с рабочей копией. Обсудим трудности при реализации функций VCS в виртуальной файловой системе и при ленивой загрузке данных. Поговорим о том, как обеспечивать надежность серверной инфраструктуры репозитория. В конце можно посмотреть неофициальную запись доклада.

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

Привет, Хабр! Представляю вашему вниманию перевод статьи «On let vs const» автора Дэна Абрамова.

Мой предыдущий пост содержит такой параграф:

let vs const vs var: Обычно, все что вам нужно, — это let. Если вам нужно запретить перезаписывание переменной, вы можете использовать const. (Некоторые очень педантичны по этому поводу и предпочитают использовать const, когда бывает только одно назначение переменной).

Это утверждение оказалось очень спорным, на Twitter'e и Reddit'e сразу же начались жаркие обсуждения по этому поводу. Похоже наиболее популярное мнение (или по крайней мере, устно высказанное большинством) это то, что следует всегда использовать const и обращаться к let только при необходимости, что может быть обеспечено ESLint правилом prefer-const.

В этом посте я коротко перечислю все за и против, которые я встретил, и выскажу свое личное мнение по этому поводу.

Примечание переводчика: в текущий момент я подготавливаю материалы для обещанной статьи по монадам. К сожалению, это занимает довольно много времени, не говоря о том, что я всё же должен заниматься основной работой и уделять время семье, но процесс идёт. А пока представляю вам перевод небольшой свежей заметки от замечательного товарища Mark Seemann'а, которая мне показалась любопытной.

Я часто становлюсь участником длительных и жарких дебатов на тему статической типизации против динамической. Сам я определенно отношу себя к сторонникам статической типизации, но эта статья не о достоинствах статической типизации. Цель статьи — устранить распространённое заблуждение насчет статически типизированных языков.

Церемонность

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

Церемония — это то, что вы делаете до того, как начнете делать то, что вы действительно собирались сделать.

Venkat Subramaniam

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

Это привело меня к мысли о том, что существует злосчастная Зона Церемонности:

Конечно же, эта диаграмма всего лишь упрощение, но я надеюсь, что она демонстрирует суть. C++, Java и C♯ — языки, которые требуют церемонности. Справа от них находятся языки, которые мы могли бы назвать транс-церемониальными, включая F♯ и Haskell.

Вершина технологий того времени.

В 1993 году id Software выпустила шутер от первого лица Doom, который быстро превратился в феномен. Сегодня считается, что это одна из игр, оказавших самое большое влияние за всю историю.

Десять лет спустя после выпуска Doom, в 2003 году, журналист Дэвид Кушнер опубликовал книгу об id Software под названием Masters of Doom, которая с тех пор стала каноническим описанием процесса создания Doom. Я прочитал Masters of Doom несколько лет назад и почти ничего уже не помню, но одна история из книги о ведущем программисте Джоне Кармаке сохранилась в моей памяти. Моё описание будет не совсем точным (подробнее см. ниже), но если вкратце, то на раннем этапе разработки Doom Кармак осознал, что написанный им для игры 3D-рендерер при рендеринге отдельных уровней начинал тормозить. Это было неприемлемо, потому что Doom должен был стать активной и даже бешеной игрой. Осознав, что проблема рендерера была настолько фундаментальной, что ему придётся искать более оптимальный алгоритм рендеринга, Кармак начал читать исследовательские статьи. В результате он реализовал технику под названием «двоичное разбиение пространства» (binary space partitioning, BSP), которая раньше никогда не применялась в видеоиграх, и значительно ускорил таким образом движок Doom.

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

Статья состоит из двух частей:

1. Краткое описание некоторых архитектур сетей по обнаружению объектов на изображении и сегментации изображений с самыми понятными для меня ссылками на ресурсы. Старался выбирать видео пояснения и желательно на русском языке.
2. Вторая часть состоит в попытке осознать направление развития архитектур нейронных сетей. И технологий на их основе.

Рисунок 1 – Понимать архитектуры нейросетей непросто

Все началось с того, что сделал два демонстрационных приложения по классификации и обнаружению объектов на телефоне Android:

• Back-end demo, когда данные обрабатываются на сервере и передаются на телефон. Классификация изображений (image classification) трех типов медведей: бурого, черного и плюшевого.
• Front-end demo, когда данные обрабатываются на самом телефоне. Обнаружение объектов (object detection) трех типов: фундук, инжир и финик.

Введение.

Все, кто хорошо знаком с современным С++ слышал, что начиная с С++11 в стандарт был введен спецификатор constexpr, при помощи которого можно проводить лимитированные compile-time вычисления. В последующие стандарты были добавлены if constexpr и constexpr lambdas которые в некоторой степени снимают ограничения и помогают писать код с compile time вычислениями. Сегодня мы поговорим о случайной кодогенерации в compile time.

Интерфейс в Java сильно эволюционировал за прошедшие годы. Давайте рассмотрим, какие изменения произошли в процессе его развития.

Язык запросов Cypher изначально разработан специально для графовой СУБД Neo4j. Целью Cypher является предоставить человеко-читаемый язык запросов к графовым базам данных похожий на SQL. На сегодня Cypher поддерживается несколькими графовыми СУБД. Для стандартизации Cypher была создана организация openCypher.

Основы работы с СУБД Neo4j описаны в статье Основы работы с Neo4j в браузере.

Для знакомства с Cypher рассмотрим пример генеалогического дерева заимствованный из классического учебника по Прологу за авторством И. Братко. На этом примере будет показано как добавлять узлы и связи в граф, как им назначать метки и атрибуты и как задавать вопросы.

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

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

1. Для императивной реализации — выигрыш от Rust получился всего 20 %. Это означает, что JVM вплотную приблизилась к нативной производительности, и тут уже нечего улучшать.
2. Для функциональной реализации — Rust оказался быстрее в 4.5 раза, потребление памяти снизилось в 5.5 раза, а отсутствие сборщика мусора сделало программу более стабильной (меньше разброс показателей). Это интересно для тех, кто хочет писать быстрые функциональные программы.
3. Концепция единственного владельца данных (и единственной мутабельной ссылки), принятая в Rust, очень близка концепции иммутабельности, в результате чего функциональные алгоритмы, основанные на неизменяемости, рекурсии и копировании, легко ложатся на Rust практически без переписывания, тогда как императивные алгоритмы заставляют редизайнить код, учитывать мутабельность ссылок, времена жизни, и т.д.

Вывод — Rust как будто специально создан для ФП, хотя возможности его синтаксиса пока не дотягивают до Scala.

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

Уже довольно давно я пишу свой игровой фреймворк — такой pet project для души. А так как для души нужно выбирать что-то, что нравится (а в данном случае — на чём нравится писать), то выбор мой пал на nim. В этой статье я хочу поговорить именно про nim, про его особенности, плюсы и минусы, а тема геймдева лишь задаёт контекст моего опыта — какие задачи я решал, какие трудности возникли.

Давным-давно, когда трава была зеленее, а небо чище, я встретил nim. Хотя нет, не так. Давным-давно я хотел заниматься разработкой игр, чтобы написать свою Самую Классную Игру — думаю, многие проходили через это. В те времена Unity и Unreal Engine только-только стали появляться на слуху и, вроде как, ещё не были бесплатными. Я не стал их использовать, не столько из-за жадности, сколько из-за желания написать всё самому, создать игровой мир полность с нуля, с самого первого нулевого байта. Да, долго, да, сложно, зато сам процесс приносит удовольствие — а что ещё для счастья надо?