Привет, Хабр! Представляю вашему вниманию перевод статьи "Docker Tips: Clean Up Your Local Machine" автора Luc Juggery.

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

Привет, Хабр! В последнее время уделяю много внимание архитектуре и решил поделиться с сообществом переводом статьи Clean Architecture with Typescript: DDD, Onion автора André Bazaglia.

Введение

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

Целью данной статьи является не детальное покрытие сложных тем по DDD и Слоистой архитектуре, а пример реализации этих двух подходов в Typescript. Используемый проект является базовым и может быть доработан и расширен, например с использованием подхода CQRS.

Привет! Сегодня я расскажу о том, как можно прийти в небо, что нужно для этого сделать, сколько оно все стоит. Также поделюсь своим опытом обучения на частного пилота в Великобритании и развею некоторые мифы, связанные с авиацией. Под катом много текста и фоточек :)

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



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

В декабре 2015 вышел PHP 7.0. Компании, которые перешли на «семерку» отметили, что увеличилась производительность, а нагрузка на сервера — уменьшилась. Первыми перешли на семерку Vebia и Etsy, а у нас Badoo, Авито и OLX. Для Badoo переход на семёрку обошелся в 1 млн. долларов экономии на серверах. Благодаря PHP 7 в OLX средняя нагрузка на сервер снизилась в 3 раза, повысилась эффективность и экономия ресурсов.

Дмитрий Стогов из Zend Technologies на HighLoad++ рассказал, благодаря чему повысилась производительность. В расшифровке: о внутреннем устройстве PHP, об идеях в основе версии 7.0, об изменениях в базовых структурах данных и алгоритмах, которые и определили успех.

Disclaimer: На март 2019 года 80% сайтов работают на PHP, и 70% из них — на PHP 5, хотя с 1 января 2019 эта версия не поддерживается. Доклад Дмитрия от 2016 года про принципы, благодаря которым произошел двукратный скачок производительности между PHP 5 и 7, — актуален и в марте 2019. Для половины сайтов — точно.

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

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



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

Довелось мне как-то после нескольких проектов на React поработать над приложением под Angular 2. Прямо скажем, не впечатлило. Но один момент запомнился — управление логикой и состоянием приложения с помощью Dependency Injection. И я задался вопросом, удобно ли управлять состоянием в React используя DDD, многослойную архитектуру, и внедрение зависимостей?

Если интересно, как это сделать, а главное, зачем — добро пожаловать под кат!

Расскажу, как нам удалось написать линтер, который получился достаточно быстрым, чтобы проверять изменения во время каждого git push и делать это за 5−10 секунд при кодовой базе в 5 миллионов строк на PHP. Мы назвали его NoVerify.

NoVerify поддерживает базовые вещи вроде перехода к определению и поиску использований и умеет работать в режиме Language Server. В первую очередь наш инструмент ориентирован на поиск потенциальных ошибок, но умеет проверять и стилистику. Сегодня его исходные коды появились в open-source на GitHub. Ищите ссылку в конце статьи.

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

На конференции HolyJS доклад об опыте использования WebAssembly получил высокие оценки зрителей, и теперь специально для Хабра подготовлена текстовая версия этого доклада (видеозапись также приложена).

Давно я хотел написать эту статью. Все думал — с какой стороны зайти правильнее? Но, вдруг, недавно, на Хабре появилась подобная статья, которая вызвала бурю в стакане. Больше всего меня удивил тот факт, что статью начали вбивать в минуса, хотя она даже не декларировала что-то, а скорее поднимала вопрос об использовании кодов ответа web-сервера в REST. Дебаты разгорелись жаркие. А апофеозом стало то, что статья ушла в черновики… килобайты комментариев, мнений и т.д. просто исчезли. Многие стали кармо-жертвами, считай, ни за что :)

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

Предупреждаю, все ниже написанное является реальным опытом, а не когнитивной эквилибристикой. И так, погнали.

JS-приложения, сайты и другие ресурсы становятся сложнее и инструменты сборки — это реальность веб-разработки. Бандлеры помогают упаковывать, компилировать и организовывать библиотеки. Один из мощных и гибких инструментов с открытым исходным кодом, который можно идеально настроить для сборки клиентского приложения — Webpack.

Максим Соснов (crazymax11) — Frontend Lead в N1.RU внедрил Webpack в несколько больших проектов, на которых до этого была своя кастомная сборка, и контрибьютил с ним несколько проектов. Максим знает, как с Webpack собрать бандл мечты, сделать это быстро и конфигурировать так, чтобы конфиг оставался чистым, поддерживаемым и модульным.


Расшифровка отличается от доклада — это сильно усовершенствованная пруфлинками версия. По всей расшифровке рассыпаны пасхалочки на статьи, плагины, минификаторы, опции, транспайлеры и пруфы слов докладчика, ссылки на которые просто не поставить в выступление. Если собрать все, то откроется бонусный уровень в Webpack :-)

Headhunter — продуктовая компания, нам очень важно качество кода. Чем он лучше, тем быстрее мы можем выпускать новые бизнес фичи и чаще радовать пользователей.

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

Продолжаем разговор про 3Д шутер за выходные. Если что, то напоминаю, что это вторая половина:

• Часть первая: отрисовка стен
• Часть вторая: населяем наш мир + оконный интерфейс

Как я и говорил, я всеми силами поддерживаю желание в студентах делать что-то своими руками. В частности, когда я читаю курс лекций по введению в программирование, то в качестве практических занятий я оставляю им практически полную свободу. Ограничений только два: язык программирования (С++) и тема проекта, это должна быть видеоигра. Вот пример одной из сотен игр, которые сделали мои студенты-первокурсники:


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

Этот текст предназначен для тех, кто только осваивает программирование. Основная идея в том, чтобы показать этап за этапом, как можно самостоятельно сделать игру à la Wolfenstein 3D. Внимание, я совершенно не собираюсь соревноваться с Кармаком, он гений и его код прекрасен. Я же целюсь совсем в другое место: я использую огромную вычислительную мощность современных компьютеров для того, чтобы студенты могли создавать забавные проекты за несколько дней, не погрязая в дебрях оптимизации. Я специально пишу медленный код, так как он существенно короче и просто понятнее. Кармак пишет 0x5f3759df, я же пишу 1/sqrt(x). Мы преследуем разные цели.

Я убеждён, что хороший программист получается только из того, кто кодит дома в своё удовольствие, а не только просиживает штаны на парах в университете. В нашем университете программистов учат на бесконечной череде всяких библиотечных каталогов и прочей скукоте. Брр. Моя цель — показать примеры проектов, которые интересно программировать. Это замкнутый круг: если интересно делать проект, то человек проводит над ним немало времени, набирается опыта, и видит вокруг ещё больше интересного (оно же стало доступнее!), и снова погружается в новый проект. Это называется проектное обучение, вокруг сплошной профит.

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

• Часть первая: отрисовка стен
• Часть вторая: населяем наш мир + оконный интерфейс

Выполнение кода из моего репозитория выглядит вот так:


Это не законченная игра, но только заготовка для студентов. Пример законченной игры, написанной двумя первокурсниками, смотрите во второй части.

Мне кажется, настало время поделится подходом для написания ReactJS App, я не претендую на уникальность.

Первый абзац можно пропустить. Я занимаюсь web разработкой уже давно, но последние четыре года я плотно сижу на ReactJS и меня все устраивает, в моей жизни был redux, но примерно два года назад я познакомился с MobX, буквально пару месяцев назад я попытался вернуться на redux, но я не смог, было ощущение что я что-то делаю лишнее, может вообще что то не верное, на эту тему переведено уже много байт на серверах, статья не о крутости одного перед другим, это всего лишь попытка поделится своими наработками, может кому-то реально зайдет этот подход, и так к сути.

Задачи которые мы будем решать:

• подключение di для компонентов
• серверный рендеринг с асинхронной загрузкой данных

В последнее время веб-разработка разделилась. Теперь мы все не full-stack программисты — мы фронтендеры и бэкендеры. А самое сложное в этом, как и везде, это проблема взаимодействия и интеграции.

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

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

Автор: Денис Цыплаков, Solution Architect, DataArt

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

Если вы не делаете что-то принципиально новое, например, первый в мире интернет-поисковик или искусственный интеллект для управления запуском ядерных ракет, создать дизайн хорошей системы довольно просто. Достаточно учесть все требования, посмотреть на дизайн похожих систем и сделать примерно так же, не совершив при этом грубых ошибок. Звучит как чрезмерное упрощение вопроса, но давайте вспомним, что на дворе 2019 год, и «типовые рецепты» дизайна систем есть практически для всего. Бизнес может подкидывать сложные технические задачи — скажем, обработать миллион разнородных PDF-файлов и вынуть из них таблицы с данными о расходах — но вот архитектура систем редко отличается большой оригинальностью. Главное тут — не ошибиться с определением того, какую именно систему мы строим, и не промахнуться с выбором технологий.

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

^{Долина внутри кратера вулкана, маленький «Затерянный мир», тёплый и надёжно защищённый от непогоды снаружи. Озеро так вообще +75 градусов Цельсия в некоторых местах.}

Азорские острова — это архипелаг посреди Атлантического океана, примерно на полдороге между Европой и Америкой. Поскольку это единственные острова на многие километры вокруг, есть три классных спецэффекта:

• Тут очень изолированный биом. Например, есть эндемичный азорский снегирь Pyrrhula murin (хотя тут вечное лето, даже на Новый год). Среди животных нет ничего ядовитого или иначе опасного для человека.
• Очень высокая влажность из-за температурных инверсий и «шершавых» гор, останавливающих облака (как следствие — рай для флоры)
• И тут очень важный перевалочный пункт как по дороге из Африки и Индии (вспоминаем времена Ост-Индской торговой кампании), так и начиная со Второй Мировой — база для дозаправки и встреч конвоев.

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

И ещё на островах очень, очень интересно. Сейчас расскажу.

В наше время использование HTTPS становится обязательным для всех сайтов и веб-приложений. Но в процессе разработки возникает проблема корректного тестирования. Естественно, Let’s Encrypt и другие CA не выдают сертификаты для localhost.

Традиционно есть два решения.

Незнакомая мобильная среда

Я, возможно, также как и вы, пришел к React Native как разработчик JavaScript нежели как разработчик нативных мобильных приложений. Абсолютно новый мир со своими нюансами и хитростями.

Одной из самых важных тем для изучения станет тестирование. Когда все более или менее понятно с модульными тестами (unit), что делать с тестами интерфейса и сквозными тестами (end-to-end)? iOS. Android. На рынке смесь разных типов устройств.

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

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