В самом начале своей карьеры я имел честь в одно лицо разрабатывать проект, предназначенный для массового пользователя. Надо сказать, что почти все основополагающие принципы того, как провалить проект, были соблюдены, однако, он до сих пор жив. Проект был предназначен для принудительного использования определенной категорией работников бюджетной сферы. Технического задания, аналитики, дизайн-документов, макетов в Фигме, лавандового смузи, и прочих этих ваших модных слов, без которых N лет назад строили БАМ и Траннсиб не было от слова совсем. Зато, были процессы “в бумаге”, которые требовалось оцифровать. Поэтому то, что можно было принять за ТЗ, выглядело как “Эти (работники) заполняют вот это (бумаги) потом несут тем (проверяющим) а дальше все это хранится, сделай чтобы они с компьютера могли загрузить и отправить, у нас тут целый этаж бумагами занят, пожар начнется - всему хана”. Используя весь свой багаж знаний и опыта в построении высоконагруженных систем (на этом месте я отошел от написания статьи сначала проржаться а потом поплакать), я приступил к реализации.

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

Данный пост написан по заявкам трудящихся, которые с завидной периодичностью спрашивают о том "Как запустить Illuminate / Symfony / MyOwnPsr7 приложение в докере". Давать ссылку на ранее написанный пост уже не хочется, так как взгляды относительно того, как следует решать поставленную задачу, довольно сильно изменились.

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

В качестве приложения так же буду использовать Laravel, так как он мне наиболее знаком и довольно широко распространен. Адаптировать под другие PSR-7-based фреймворки/компоненты возможно, но этот рассказ не про это.

Введение

Гравитационная тяга в системе отопления и естественная тяга в вентиляции зданий

Гравитационная или естественная тяга- это явление, которое своими проявлениями нас окружает постоянно.

Именно ему мы обязаны сквознякам из окон зимой и быстрому таянью льда на водоёмах весной.

Ветер на улицы- это тоже следствии наличия гравитационной тяги в больших объёмах атмосферы планеты.

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

Гравитационная тяга в трубах водяного отопления.

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

Ранее я слегка касался этой темы в статье про попутные и тупиковые системы отопления (см. статью по сылке).

https://habr.com/ru/articles/770464/

Теперь же стоит разобрать вопрос подробнее.

В гравитационной системе отопления циркуляция воды в замкнутом  контуре из труб и радиаторов обусловлена постоянно присутствующей разницей плотности воды в горячих и холодных участках труб. (см.рис.1)

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

Год назад мы выпустили «Маскировщик» — промышленный софт, который обезличивает персональные данные, сохраняя их качество и смысл. То есть гендерный баланс; социально‑демографическую структуру; родственные связи; страну и оператора в телефоне; валидность паспортов, ИНН, СНИЛС. В общем, «Маскировщик» делает так, чтобы вы тестировали продукты и обучали ML‑модели будто бы на «живых» ПД.

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

Мы в API отказались от большого количества unit-тестов в пользу большого количества интеграционных/системных, чтобы тестировать меньшим количеством кода большее количество функций, а также наблюдать за взаимодействием разных частей системы.

На самом деле мы просто решили писать тесты не на отдельные классы/методы, а на интерфейс api, которым пользуются клиенты - на сервисы этого API. Тестируя их, мы убиваем двух зайцев: проверяем логику работы сервисов api + форматирование результата.

А такое тестирование сопряжено с несколькими проблемами.

При визуализации геопространственных данных часто используется картографическая подложка в виде Яндекс/Google/OSM/etc, которая в основном бывает двух видов - векторная или растровая. Однако, когда дело доходит до интеграции карт в свое приложение, то не всегда очевидно какой тип больше подойдет.

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

Требовалось кешировать используемые в разных проектах NPM пакеты (+ хранить свои пакеты) на отдельном сервере.

Было решено делать это с помощью репозитария Verdaccio (по нему есть достаточно хорошая офф. дока), крутится это все должно в Docker, а разворачиваться на отдельном сервере через GitLab CI/CD.

Т.к. реализация данной схемы заняла у меня некоторое время (Хотелось бы и по меньше), решил написать короткий туториал по этой теме, с описание нюансов, которые для меня казались не очевидными.

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

В данной статье не будут "размусолены" принципы работы и тонкости Push уведомлений, только код

Ребята, свершилось! После долгих шести недель ожидания наконец вышла версия Rust 1.15 с блекджеком и процедурными макросами.

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

А что же это дает простым смертным? Практически бесплатную [де]сериализацию, удобный интерфейс к БД, интуитивный веб фреймворк, выводимые конструкторы и много чего еще.

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

curl https://sh.rustup.rs -sSf | sh

Впрочем, обо всем по порядку.

От переводчика:
Предлагаю вашему вниманию перевод краткого (действительно краткого) руководства по ES6. В нём можно ознакомиться с основными понятиями стандарта.
Оригинальный текст в некоторых случаях был дополнен или заменён на более подходящий источник. Например, часть определения ключевого слова const является переводом документации с MDN.
Чтобы лучше разобраться в некоторых концепциях (для выполнения качественного перевода) использовалось описание стандарта на сайте MDN, руководство "You Don't Know JS: ES6 & Beyond" и учебник Ильи Кантора.

Перевод выложил на Гитхаб: https://github.com/etnolover/ES6-for-humans-translation. В случае нахождения ошибок пишите, исправлю.
Ссылка на оригинальный текст: https://github.com/metagrover/ES6-for-humans

Update 22.07.2016: добавил опрос про const

Содержание

• let, const и блочная область видимости
• Стрелочные функции
• Параметры по умолчанию
• Spread/Rest оператор
• Расширение возможностей литералов объекта
• Восьмеричный и двоичный литералы
• Деструктуризация массивов и объектов
• Ключевое слово super для объектов
• Строковые шаблоны и разделители
• for...of против for...in
• Map и WeakMap
• Set и WeakSet
• Классы в ES6
• Тип данных Symbol
• Итераторы
• Генераторы

• Промисы

  
  
• Опрос: в каком регистре писать const?

• DOM, который многие ошибочно считают эквивалентом самого языка JavaScript, обладает очень неудачным API.
• Когда переходишь на JavaScript с языков С и Java, то попадаешь в ловушку синтаксиса, который устроен не так, как в императивных языках. Это очень часто приводит к багам и сильно раздражает.