Всем привет! Продолжаем серию авторских публикаций в преддверии старта курса «Framework Laravel». В прошлой статье мы с вами посмотрели на теоретические основы Laravel. Однако теорию любого фреймворка можно изучать достаточно долго и ничего не понять, пока сам не напишешь ничего на практике.



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

Предисловие переводчика

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

Многие .NET разработчики слышали про Dynamic Language Runtime (DLR), но почти ничего о нем не знают. Разработчики, пишущие на языках типа C# или Visual Basic, избегают языков с динамической типизацией из-за боязни исторически связанных с ними проблем с масштабируемостью. Также их беспокоит тот факт, что языки типа Python или Ruby не выполняют проверку типов во время компиляции, что может привести к сложным для поиска и исправления ошибкам в рантайме. Это обоснованные опасения, которые могут объяснить, почему DLR не пользуется популярностью среди основной массы .NET разработчиков даже спустя два года после официального релиза [статья довольно старая, но с тех пор ничего не изменилось]. В конце концов, любой .NET Runtime, содержащий в себе слова Dynamic и Language в своем названии, должен предназначаться строго для поддержки таких языков, как Python, правильно?

Притормозите. В то время как DLR действительно была задумана для поддержки «Iron» реализации Python и Ruby в .NET Framework, её архитектура предоставляет гораздо более глубокие абстракции.

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

Обобщенные асинхронные типы возвращаемых значений — это новая возможность появившаяся в C# 7, которая позволяет использовать не только Task в качестве возвращаемого типа асинхронных (async/await) методов, но также и любые другие типы (классы или структуры), удовлетворяющие определенным требованиям.

В то же время async/await — это способ последовательно вызвать некий набор функций внутри некоторого контекста, что является сущностью шаблона проектирования Монада. Возникает вопрос, можем ли мы использовать async/await для написания кода, который будет вести себя так же, как если бы мы использовали монады? Оказывается, что да (с некоторыми оговорками). Например, приведенный ниже код компилируется и работает:

async Task Main()
{
  foreach (var s in new[] { "1,2", "3,7,1", null, "1" })
  {
      var res = await Sum(s).GetMaybeResult();
      Console.WriteLine(res.IsNothing ? "Nothing" : res.GetValue().ToString());
  }
  // 3, 11, Nothing, Nothing
}

async Maybe<int> Sum(string input)
{
    var args = await Split(input);//Нет проверки результата
    var result = 0;
    foreach (var arg in args)
        result += await Parse(arg);//Нет проверки результата
    return result;
}

Maybe<string[]> Split(string str)
{
  var parts = str?.Split(',').Where(s=>!string.IsNullOrWhiteSpace(s)).ToArray();
  return parts == null || parts.Length < 2 ? Maybe<string[]>.Nothing() : parts;
}

Maybe<int> Parse(string str)
    => int.TryParse(str, out var result) ? result : Maybe<int>.Nothing();

Далее я объясняю, как работает этот код ...

Микроконтроллеры AVR довольно дешевы и широко распространены. Наверно, с них начинает почти любой embedded разработчик. А среди любителей правит балом Arduino, сердцем которого обычно является ATmega328p. Наверняка многие задумывались: как можно заставить их звучать?

Если посмотреть на существующие проекты, то они бывают нескольких типов:

1. Генераторы квадратных импульсов. Генерация с помощью ШИМ или дергать пины в прерываниях. В любом случае, получается очень характерный пищащий звук.
2. Использование внешнего оборудования типа MP3 декодера.
3. Использование ШИМ для вывода 8 битного (иногда 16 битного) звука в формате PCM или ADPCM. Поскольку памяти в микроконтроллерах для этого явно не достаточно, то обычно используют SD карту.
4. Использование ШИМ для генерации звука на основе волновых таблиц, подобных MIDI.

Последний тип для меня был особенно интересен, т.к. почти не требует дополнительного оборудования. Представляю сообществу свой вариант. Для начала небольшое демо:



Заинтересовавшихся прошу под кат.

Здравствуй, читатель. Прошло уже достаточно много времени с момента выхода .NET Core 2.1. И такие крутые нововведения, как Span и Memory, уже рассмотрены весьма широко, про них можно достаточно много прочитать, посмотреть и услышать. Однако, к сожалению, библиотека под названием System.IO.Pipelines не удостоилась такого же внимания. Почти все, что есть по этой теме — единственный пост, который многие перевели и разместили у себя. Информации должно быть однозначно больше, чтобы интересующиеся могли взглянуть на технологию с разных углов.

Потребовалось мне настроить процесс сборки и доставки на сайт пакетов программ из Git-репозитария. И увидев, ни так давно, тут на Хабре статью по buildbot (ссылка в конце) решил для этого попробовать его и применить.

Так как buildbot — это распределённая система, то будет логичным под каждую архитектуру и операционку сделать отдельный сборочный хост. В нашем случае это будут LXC-контейнеры (в случае linux) и qemu (в случае windows):

• vm-srv-build1 — centos 7, тут будет buildbot мастер (master) и один из рабочих (worker)
• vm-srv-build2 — debian 10, для сборки DEB пакетов
• vm-srv-build3 — windows 10, для сборки, сами понимаете, под что

Собирать будем Rac GUI — графическая морда к 1С rac для управления кластером серверов. Под линукс будут использоваться штатные средства под каждую ОС, для сборки exe-файла под windows из tcl-скрипта используется freewrap.

Переключатель функциональности — это инструмент, позволяющий переключаться со старой функциональности на новую, не пересобирая приложение и не выпуская его заново. Реализуется добавлением в код условного оператора (if), который дает возможность управлять поведением программы, просто меняя нужное значение в конфигурационном файле или базе данных. Если вы хоть раз редактировали настройки в ini-файле, то вам знакома эта технология.

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

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

В этой статье я расскажу об одной необычной формуле, которая позволяет взглянуть под новым углом на аффинные преобразования, а особенно на обратные задачи, которые возникают в связи с этими преобразованиями. Обратными я буду называть задачи, требующие вычисления обратной матрицы: нахождение преобразования по точкам, решение системы линейных уравнений, преобразование координат при смене базиса и т.д. Сразу оговорюсь, что в статье не будет ни фундаментальных открытий, ни уменьшения алгоритмической сложности — я просто покажу симметричную и легко запоминающуюся формулу, с помощью которой можно решить неожиданно много ходовых задач. Для любителей математической строгости есть более формализованное изложение здесь [1] (ориентированно на студентов) и небольшой задачник вот здесь [2].

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

Многие ругают CMake, и часто заслуженно, но если разобраться, то не всё так плохо, а в последнее время очень даже неплохо, и направление развития вполне позитивное.

В данной заметке я хочу рассказать, как достаточно просто организовать заголовочную библиотеку на языке C++ в системе CMake, чтобы получить следующую функциональность:

1. Сборку;
2. Автозапуск тестов;
3. Замер покрытия кода;
4. Установку;
5. Автодокументирование;
6. Генерацию онлайн-песочницы;
7. Статический анализ.

Кто и так разбирается в плюсах и си-мейке может просто скачать шаблон проекта и начать им пользоваться.

Как проверить идеи, архитектуру и алгоритмы без написания кода? Как сформулировать и проверить их свойства? Что такое model-checkers и model-finders? Требования и спецификации — пережиток прошлого?

Привет. Меня зовут Васил Дядов, сейчас я работаю программистом в Яндексе, до этого работал в Intel, ещё раньше разрабатывал RTL-код (register transfer level) на Verilog/VHDL для ASIC/FPGA. Давно увлекаюсь темой надёжности софта и аппаратуры, математикой, инструментами и методами, применяемыми для разработки ПО и логики с гарантированными, заранее определёнными свойствами.

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

Не буду лукавить: основная задача статьи — возбудить интерес. Так что в ней будет минимум пространных рассуждений и максимум конкретики.

Для лучшего понимания нижеследующего материала сначала рекомендуется ознакомится с Предыдушим постом

Рассмотрим пример развертки локального окружения состоящего из связки Nginx+PHP+MySql+phpMyAdmin. Данная связка очень популярна и может удовлетворить ряд стандартных потребностей рядового разработчика.

Как и в прошлом посте акцент будет смещен в сторону утилиты docker-compose, чем докера в чистом виде.

Итак, поехали!

Посвящается тем 45% .NET разработчиков, что до сих пор сидят на фремворках 2.0-3.5.

Да, вы не ослышались. async и await во втором дотнете. Но обо всём по порядку.

Зачем?

В какой-то момент мне надоело вручную возиться с написанием асинхронного кода. Async/awat выглядели слишком вкусными, чтобы не попробовать. Зная, что Microsoft при добавлении новых возможностей в язык и компилятор не привязывает их жёстко к фреймворку (так, extension-методы и LINQ отлично можно использовать во втором .NET, если где-нибудь объявить System.Runtime.CompilerServices.ExtensionAttribute), и видя Async CTP, добавляющего возможность использования async/await в 2010-ую студию при использовании в качестве целевого фреймворка .NET 4.0, я подумал, а почему бы и нет?

Возможно, одна из самых основных причин почему мне нравится докер это то, что он позволяет избавиться от необходимости установки на компьютер различных сервисов. К их числу можно отнести и сам веб-сервер Apache или Nginx, базы данных и прочие компоненты инфраструктуры приложения. Вся инфраструктура прописана в конфигурационном файле docker-compose.yml и запускается одной командой вместе с вашим приложением. Все что нужно разработчику работающему с докером, это по сути сам докер и любимая среда разработки и ВСЕ!

Часть 1
Часть 2
Часть 3
Часть 4

В этой серии постов мы внимательно рассмотрим один из главных ингредиентов в контейнере – namespaces. В процессе мы создадим более простой клон команды docker run – нашу собственную программу, которая будет принимать на входе команду (вместе с её аргументами, если таковые имеются) и разворачивать контейнер для её выполнения, изолированный от остальной системы, подобно тому, как вы бы выполнили docker run для запуска из образа.

О чем мы расскажем:

— Почему мы решили перейти на LXC контейнеры?
— Как создать контейнер и запустить на нем хост на базе Битрикс?

Для кого это будет полезно:

Для всех, кто хочет попробовать новое решение, при этом используя меньше ресурсов.

Есть в графиках что-то магическое. Изгиб кривой мгновенно раскрывает всю ситуацию — историю развития эпидемии, паники или периода процветания. Эта линия просвещает, пробуждает воображение, убеждает.
― Генри. Д. Хаббард

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

Вряд ли кто-то станет отрицать, что в современном HTML5 вебе JavaScript — самая универсальная и простая технология для визуализации данных. Так что, если вы занимаетесь фронтенд-разработкой, то вы, скорее всего, либо уже имели дело с созданием JS чартов, либо столкнетесь с этим в (скором) будущем.

Существует множество JavaScript библиотек для построения графиков и диаграмм, каждая из которых (как и любые другие инструменты) имеет свои плюсы и минусы. Чтобы облегчить вам жизнь, я решил рассказать о тех из них, которые нравятся мне больше всего. Я считаю, десять следующих библиотек — это лучшие JS библиотеки для создания графиков, и они действительно способны помочь решить практически любую задачу по визуализации данных. Давайте вместе пройдемся по списку и убедимся, что они вам известны хотя бы базово и вы не упустили из виду какую-нибудь хорошую библиотеку, которая может оказаться полезной в текущих или будущих больших проектах.



Что ж, приступим: вот лучшие JS библиотеки для визуализации данных!

Кажется, мне довелось сделать десятки презентаций для коллег, заказчиков и публичных выступлений за мою карьеру в IT. Многие годы Powerpoint как средство изготовления слайдов оставался для меня естественным и надёжным выбором. Но в этом году ситуация качественно изменилась. С февраля по май мне довелось выступить на пяти конференциях, и слайды к докладам надо было готовить в сжатые сроки, но качественно. Встал вопрос о делегировании той части работы, что касается визуального дизайна слайдов, другим людям. Как-то раз я попытался работать с дизайнером, пересылая файлы .pptx по почте, но работа превратилась в хаос: никто не знал, какая версия слайдов «самая новая», а вёрстка «ехала» по причине различия версий Powerpoint и шрифтов на наших машинах. И я решил попробовать что-то новое. Попробовал, и с тех пор не думаю возвращаться к Powerpoint.

С тех пор, как я начала работать с сообществом над переносом десктопных приложений с .NET Framework на .NET Core, я заметила, что существует «два лагеря»: представители одного хотят очень простой и короткий список инструкций для переноса своих приложений на .NET Core, в то время как представители другого предпочитают более принципиальный подход с большим количеством исходной информации. Вместо того, чтобы писать документ по типу «швейцарского армейского ножа», мы собираемся опубликовать два сообщения в блоге, по одному для каждого «лагеря»:

• Данный пост — простой случай. Он ориентирован на простые инструкции и небольшие приложения и рассматривает самый простой способ переноса приложения на .NET Core.
• Позднее мы опубликуем еще один пост для более сложных случаев. В нем основное внимание будет уделено нетривиальным приложениям, таким как WPF-приложение с зависимостями от WCF и сторонних UI-пакетов.

Если вы предпочитаете смотреть видео, а не читать, то вот видео, где я делаю все, что описано ниже.