⬝ 11 библиотек (наборов компонентов) для Angular, о которых стоит знать в 2018-м
⬝ 11 библиотек (наборов компонентов) для Vue, о которых стоит знать в 2018-м
⬝ 11 библиотек (наборов компонентов) для React, о которых стоит знать в 2018-м

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

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

В рекламных видео конечно никакой особой настройки нет, но жизнь — она сложнее, особенно если ваше ПО микросервисное. Почему? А всё очень просто.

Что в первую очередь должна делать система диагностики в микросервисной архитектуре?
Правильно, коррелировать диагностику от различных микросервисов в рамках одной операции.
Тыркнул пользователь в UI кнопочку — надо увидеть диагностику от всех N микросервисов, которые так или иначе обрабатывали этот тырк. Случился где-нибудь exception — надо увидеть не только в каком микросервисе он произошёл, но и в рамках какой операции это случилось.
Только вот Application Insights с точки зрения конкретного микросервиса — это в первую очередь SDK. И SDK таких есть несколько — есть для JS, есть для .NET Core, .NET (со своими особенностями настройки для MVC, WebAPI, WCF), есть для Java и т.д.

Какие-то из этих SDK — opensource, какие-то — внутренняя разработка MS. И чтобы всё завелось — их надо подружить.

В этом и состоит основная сложность.

Не скажу, что я достиг 100% просветления в этом вопросе.
Но по крайней мере, я уже собрал несколько граблей и у меня есть рабочий семпл с UI на ASP.NET MVC (не Core) + JS и двумя микросервисами (Asp.Net WebApi, WCF)

Кому интересно — прошу под кат.

Все как всегда, слышим звон, но не знаем где он

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

Что мы получим после этой статьи:

Систему сбора и анализа логов на syslog-ng, elasticsearch в качестве хранилища данных, kibana и grafana в качестве систем визуализации данных, kibana для удобного поиска по логам, elasticalert для отправки уведомлений по событиям. Приготовьтесь, туториал объемный.

Какие логи будем собирать:

• все системные логи разложенные по индексам в зависимости от их facility(auth,syslog,messages и т.д.);
• логи nginx — access и error;
• логи pm2;
• и др.

Обоснование выбора системы

Почему я выбрал связку с syslog-ng в качестве отправителя, парсера и приемщика логов? Да потому что он очень быстрый, надежный, не требовательный к ресурсам(да да — logstash в качестве агентов на серверах и виртуальных машинах просто убожество в плане пожирания ресурсов и требованием java), с внятным синтаксисом конфигов(вы видели rsyslog? — это тихий ужас), с широкими возможностями — парсинг, фильтрация, большое количество хранилищ данных(postgresql,mysql,elasticsearch,files и т.д.), буферизация(upd не поддерживает буферизацию), сторонние модули и другие фишки.

Требования:

• Ubuntu 16.04 или debian 8-9;
• vm для развертывания;
• Прямые руки.

Приступим или добро пожаловать под кат

С тех пор, как я посмотрел легендарное видео Wat Гэри Бернхардта, меня завораживает странное поведение некоторых языков программирования. Некоторые из них таят больше сюрпризов, чем другие. Например, для Java написана целая книга с описанием пограничных ситуаций и странной специфики. Для C++ вы просто можете почитать сами спецификации всего за $200.

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

«Додо Пицца» развивается в США. В середине 2016 года мы открыли доставку в Оксфорде и быстро поняли, что предпочтения клиентов в США и России отличаются. Американцы — индивидуалисты. Они привыкли, что можно собрать пиццу из любых ингредиентов: пусть даже бекон с шоколадным соусом. Поэтому нам надо было сделать такой функционал для американских Додо. Мы назвали проект «Своя пицца».

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

Чтобы разобраться, мы использовали сторимэп. Этот инструмент помог спланировать работу и запустить «Свою пиццу» за 2,5 месяца. В статье рассказываем, как применяем сторимэп.

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

Компьютер	Отклик (мс)	Год	Тактовая частота	Кол-во транзисторов
Apple 2e	30	1983	1 МГц	3,5 тыс.
TI 99/4A	40	1981	3 МГц	8 тыс.
Haswell-E 165 Гц	50	2014	3,5 ГГц	2 млрд
Commodore Pet 4016	60	1977	1 МГц	3,5 тыс.
SGI Indy	60	1993	0,1 ГГц	1,2 млн
Haswell-E 120 Гц	60	2014	3,5 ГГц	2 млрд
ThinkPad 13 ChromeOS	70	2017	2,3 ГГц	1 млрд
iMac G4 OS 9	70	2002	0,8 ГГц	11 млн
Haswell-E 60 Гц	80	2014	3,5 ГГц	2 млрд
Mac Color Classic	90	1993	16 МГц	273 тыс.
PowerSpec G405 Linux 60 Гц	90	2017	4,2 ГГц	2 млрд
MacBook Pro 2014	100	2014	2,6 ГГц	700 млн
ThinkPad 13 Linux chroot	100	2017	2,3 ГГц	1 млрд
Lenovo X1 Carbon 4G Linux	110	2016	2,6 ГГц	1 млрд
iMac G4 OS X	120	2002	0,8 ГГц	11 млн
Haswell-E 24 Гц	140	2014	3,5 ГГц	2 млрд
Lenovo X1 Carbon 4G Win	150	2016	2,6 ГГц	1 млрд
Next Cube	150	1988	25 МГц	1,2 млн
PowerSpec G405 Linux	170	2017	4,2 ГГц	2 млрд
Пакет вокруг света	190
PowerSpec G405 Win	200	2017	4,2 ГГц	2 млрд
Symbolics 3620	300	1986	5 МГц	390 тыс.

Типы System.Tuple были введены в .NET 4.0 с двумя существенными недостатками:

1. Типы кортежей являются классами;
2. Не существует языковой поддержки для их создания/деконструкции (deconstruction).

Чтобы решить эти проблемы, в C# 7 представлена новая возможность языка, а также новое семейство типов (*).

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

Предыстория

Начинается новый проект, собрана смышленая команда человек так из 7, намечен roadmap, согласованы сроки и бюджет ,- вроде бы все идет по плану, и счастью разработчиков нет предела. Так и слышны фразы: “Наконец-то не придется писать на (подставить angular 1, jquery, vanilla js) и можно будет использовать по-настоящему современные, модные и быстрые фреймворки! Вот в этом проекте все точно будет как надо: каждый метод будет задокументирован, 100% code coverage, CI интеграция, scrum с естимейтами, webpack, babel и стакан с реактовским смузи…” Все дружно хейтят старые глючные приложения, в которых никто толком не может разобраться, и восхваляют новое, которое, по их суждению, будет просто огонь. Знакомая ситуация, не правда ли? Но если вы хоть раз сталкивались с данным сценарием, то прекрасно и без меня знаете, что происходит через 3-4 месяца активной работы

Написать эту статью меня побудила заметка уважаемого jobgemws "Отправка запроса на все базы данных всех указанных серверов на примере MS SQL Server и C#.NET"

Я расскажу, как схожую задачу можно решить штатными инструментами MSSQLSERVER, а именно – SSMS (или, для экстремалов от администрирования — sqlcmd), быстро, без программирования, с помощью крошечного лайфхака.

Итак, у нас в организации имеется несколько десятков разнотипных MSSQLSERVER, разных редакций. Express превалирует, но это – не важно. Инфраструктура – старая, целиком унаследованная, и — «кусочно-непрерывная».

Задача: «запустить один и тот же запрос/пакет на нескольких серверах в нескольких базах данных», у нас, что называется, «редко бывает, но часто случается».

И то, что это «редко бывает» — не позволяет изобрести достойного обоснования для закупки или написания полноценного софта для централизованного администрирования всего зоопарка, а то, что «часто случается» — бывает, требует мгновенного решения в стиле «5 секунд до взрыва».

Но всё это – лирическое отступление, дисклаймер и всё такое.

В прошлом году немецкий разработчик Mimimi Productions привлёк большое внимание к своей игре в жанре тактического стелса реального времени Shadow Tactics: Blades of the Shogun, вдохновлённой такими старыми проектами, как Desperados и Commandos.

Shadow Tactics имеет интригующий дизайн (см. эту статью о механике динамического распознавания). Она стала огромным успехом для Mimimi — несмотря на то, что в процессе выпуска компания едва не развалилась. Подробнее о том, как это произошло (и о том, какие уроки извлекли разработчики) можно прочитать в этом честном постмортеме игры, написанном коллегами-основателями Mimimi Иоганнесом Ротом и Домиником Абе.

Около года назад Mimimi была ещё мало кому известна. Наша предыдущая трёхмерная экшн-адвенчура The Last Tinker: City of Colors показала себя хорошо, но не собрала большой аудитории.

К декабрю 2016 года наши самые большие мечты осуществились: Shadow Tactics: Blades of the Shogun, наше признание в любви к Commandos и Desperados, наконец вышла и завоевала признание игроков и прессы.

В то же самое время мы были почти банкротами и уже уволили бо́льшую часть команды. У нас уже не было денег, чтобы пережить ещё один месяц.

В этом постмортеме два основателя Mimimi Доминик Абе (креативный директор) и Иоганнес Рот (управляющий директор) подробно расскажут о том, в чём они были правы, а в чём (ужасно) ошиблись.

Все мы давно хотим перелезть на .NET Core, но постоянно что-то мешает. Например, ничего не поделаешь, когда не хватает важных API. В версии 2.0 процесс упростили благодаря .NET Standard 2.0, но это ещё не всё. Ну что ж, Microsoft-боги вняли нашим молитвам и завезли 20 000 API, доступных в виде одного-единственного пакета в NuGet!

Современные жесткие диски являются сложнейшими высокотехнологичными приборами. Только представьте: размер пишущей части магнитной головки составляет всего 120 нанометров, а считывающей — лишь 70 нанометров. Чтобы вообразить подобный масштаб, достаточно посмотреть на то, как выглядит блок головок под 39-кратным увеличением на фоне монеты достоинством в 10 центов.


Сравнение размеров блока головок и монеты в 10 центов

При этом магнитные головки парят над пластинами на высоте около 12–15 нанометров, что достигается за счет экранного эффекта: под каждой из них, словно под крылом боинга на взлете, образуется воздушная (или гелиевая, если речь идет о решениях на платформе HelioSeal) подушка, обеспечивающая необходимую подъемную силу. С учетом столь мизерного расстояния, поверхность самих блинов должна быть идеально гладкой, ведь малейшая неровность приведет к необратимому повреждению компонентов устройства. Точность изготовления пластин легко оценить на следующем примере.

Если бы мы могли увеличить 2,5-дюймовый накопитель приблизительно в 13 миллионов раз так, чтобы зазор между пластиной и магнитной головкой достиг 1 метра, то последняя преодолевала бы путь, сопоставимый с расстоянием между Нью-Йорком и Сан-Франциско (> 4000 километров), причем перепад высот на всем его протяжении не превышал бы 4 сантиметров.


Точность исполнения современных HDD в масштабах реального мира

Тем удивительнее становится тот простой факт, что базовые принципы конструкции HDD не меняются на протяжении вот уже 60 лет! О том, какой тернистый путь преодолели винчестеры со времен монструозного RAMAC до настоящего времени, мы и расскажем в сегодняшней публикации.

Недавно мне посчастливилось начать работу с одной относительно немаленькой компанией (~100 человек), где, как выразился наниматель, “по-отдельности все хорошие специалисты, а вместе работать не получается”. Ну, думаю, я как раз специализируюсь на создании команд, дай, думаю, помогу чем смогу. Пообщались на собеседовании на тему общего понимания цели компании, об условиях, в которых возможна успешная совместная работа, о максимальном использовании компетенций сотрудников и о вовлечении в общее дело. Казалось бы, мысли у нас с нанимателем сходятся, но сам держу ухо востро — знаю о негативной репутации компании у потенциальных соискателей в городе. Ну что же, тем интереснее будет задача!

Уже много лет JavaScript — самый популярный язык программирования в мире. С этим, конечно, можно и поспорить, однако, совершенно определённо можно говорить о том, что этот язык прошёл долгий путь со дня своего рождения в 1995-м.

Возможно, многие сталкивались с исторически сложившейся за годы, до появления на проекте, ситуацией, когда на таблице создали все возможные индексы со всеми include’ами. Я видела индекс на доставшейся «в наследство» БД, который содержал все поля таблицы. При этом, не всегда есть возможность быстро поменять индексы, так как часто нужна гарантия, что изменения не повлияют на работоспособность системы.

При росте объема таблицы становится мучительно больно за бесцельно занятое место, но просто так индекс уже не убьешь, а статистика использования показывает, что индекс используется.
Описаный пример консолидации индексов на высоконагруженной БД, работающей в режиме 24/7. Приложение использует только хранимые процедуры. Версия MS SQL Server 2012 SP3.

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

Сегодня мы расскажем, к каким источникам рекомендуют обращаться программисты, инженеры и резиденты тематических платформ (Stack Exchange, Stack Overflow и др.), если вам нужно изучить новый язык или углубить знания в какой-то отдельной области. Также приведем несколько их рекомендаций о том, как с такой литературой «работать».

От переводчика: данная статья является переработкой английской статьи по паттернам разработки. В процессе адаптации на русский немало пришлось изменить. Оригинал

---

Выбор между различными паттернами разработки, всегда сопровождается рядом споров и дискуссий, а разные взгляды разработчиков на это еще больше усложняют задачу. Существует ли решение этой идеологической проблемы? Давайте поговорим о MVC, MVP, MVVM и MVI прагматично. Давайте ответим на вопросы: “Почему?”, “Как найти консенсус?”

В этой статье я рассмотрю компоненты платформы .NET Core 2.0, необходимые для загрузки и выполнения .NET Core-приложений, а также артефакты для двух возможных типов развертывания.

Текст объемный и рассчитан на:

• начинающих разработчиков, которые только знакомятся с платформой .NET Core;
• опытных разработчиков, выполняющих роль DevOps-инженеров в produсtion-окружении.

В статье не упоминается процесс создания приложений при помощи SDK (dotnet CLI), однако эта информация будет полезной для понимания, как работает SDK, а именно её основной компонент (ядро) — «драйвер» dotnet.dll, поскольку эта библиотека является управляемой сборкой и выполняется на .NET Core.

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

Сегодня мы представляем вам шестую часть серии материалов, которые посвящены особенностям работы всего того, что связано с JavaScript. Здесь мы поговорим о WebAssembly. А именно, детально проанализируем эту технологию, рассмотрим особенности её работы, а так же то, как она соотносится с обычным JavaScript в плане производительности. Речь пойдёт о времени загрузки кода, о скорости выполнения программ, о сборке мусора, об использовании памяти, о доступе к API платформы, об отладке, о многопоточности и о переносимости WebAssembly-кода. Эта технология, хотя и находится сейчас в самом начале своего развития, уже начала менять взгляды на разработку веб-приложений. Если разработчику нужна высочайшая производительность браузерного кода, ему просто необходимо познакомиться с WebAssembly.