Я должен признаться. Я ненавижу docker. Всей своей душой. Это самая ужасная софтина, которую я видел за последние 10 лет.

С одной стороны, я очень уважаю одноименную компанию. Ребята из Docker Inc. реально популяризировали контейнеризацию. Теперь о ней не знает только ленивый. С другой стороны, ничего принципиально нового они не изобрели — контейнеризация на момент, когда Docker "выстрелил", уже существовала более 30 лет (начиная от chroot, вспомним еще jails и zones, ну, и наконец-то — namespaces & cgroups).

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

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

Disclaimer: все написанное ниже является личным мнением автора и может как отражать реальность, так и не отражать реальность. Материал строго провокационного характера и основной целью является не унизить или обидеть кого бы то ни было, а скорее заставить людей включить голову и осознать масштабы глубин (с).

Продолжение перевода небольшой книги:
«Understanding Message Brokers»,
автор: Jakub Korab, издательство: O'Reilly Media, Inc., дата издания: June 2017, ISBN: 9781492049296.

Предыдущая часть: Понимание брокеров сообщений. Изучение механики обмена сообщениями посредством ActiveMQ и Kafka. Глава 2. ActiveMQ

Западная культура для многих ассоциируется с вежливостью и ее подчеркнутой демонстрацией – иногда даже не совсем искренней, но «обязательной». Людям с другим менталитетом трудно ориентироваться в культуре, где негатив принято максимально смягчать. В частности, лично мне всегда было непонятно, как правильно говорить «нет» на английском?

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

Приветствую вас, хабровчане! Как и обещал в конце прошлой статьи, я обратил свой взгляд на игровой движок. Правда мне больше приглянулся Godot.

Почему? Тема для отдельной статьи размышления, а я не умею долго думать и, тем более, размышлять.

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

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

Внимание! Под катом много скринов.

Поскольку исходный код данного проекта никому не принадлежит, я выложил его на GitHub.
А всем желающим прочитать мой опыт welcome под кат.

О Python

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

О данной статье

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

Имея это в виду, в этой статье представлен «топ-10» тонких, трудных для обнаружения ошибок, которые могут допустить даже продвинутые разработчики Python.

Перед вами перевод статьи Genevieve Hayes, Data Scientist с 15-летним опытом работы. Автор рассказывает о том, какие навыки стоит развивать, чтобы значительно увеличить шансы найти работу в Data Science. Чтобы определить эти навыки, она проанализировала 100 вакансий, размещенных работодателями из Австралии, Канады, Великобритании и США.

Это перевод публикации «Les Forges Pixel Art Course».

pdf на английском.

Часть 1: Правильные инструменты
Часть 2: Линии и кривые
Часть 3: Перспективы
Часть 4: Тень и свет
Часть 5: Палитры цветов
Часть 6: Сглаживание
Часть 7: Текстуры и размытие
Часть 8: Мир тайлов

Предисловие

Есть много определений пиксель-арта, но здесь мы будем использовать такое: изображение пиксель-арт, если оно создано целиком руками, и присутствует контроль над цветом и позицией каждого пиксела, который нарисован. Несомненно, в пиксель арте включение или использование кистей или инструментов размытия или машин деградации (degraded machines, не уверен), и других опций ПО, которые «современны», нами не используются (вообще-то put at our disposal значит «в нашем распоряжении», но по логике вроде правильнее так). Он ограничен инструментами такими как «карандаш» и «заливка».

Тем не менее не скажешь, что пиксель-арт или не-пиксель-арт графика — более или менее красива. Справедливее сказать, что пиксель-арт другой, и он лучше подходит для игр стиля «ретро» (как Супер Нинтендо или Гейм Бой). Вы можете также комбинировать техники изученные здесь, с эффектами из не-пиксель-арта, для создания гибридного стиля.

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

* Michael G. Noll — активный контрибьютор в Open Source проекты, в том числе в Apache Kafka и Apache Storm.

Статья будет полезна в первую очередь тем, кто только знакомится с Apache Kafka и/или потоковой обработкой [Stream Processing].

В этой статье, возможно, в первой из мини-серии, я хочу объяснить концепции Стримов [Streams] и Таблиц [Tables] в потоковой обработке и, в частности, в Apache Kafka. Надеюсь, у вас появится лучшее теоретическое представление и идеи, которые помогут вам решать ваши текущие и будущие задачи лучше и/или быстрее.

Содержание:

* Мотивация
* Стримы и Таблицы простым языком
* Иллюстрированные примеры
* Стримы и Таблицы в Kafka простым языком
* Пристальный взгляд на Kafka Streams, KSQL и аналоги в Scala
* Таблицы стоят на плечах гигантов (на стримах)
* Turning the Database Inside-Out
* Заключение

Вам нужна недорогая «печатная машинка», но вместо нее Microsoft и Acer сделали для вас «китайскую поделку» с заведомо неработоспособной конфигурацией.



Под катом о том, как выглядит работа системы с бюджетным процессором, Windows 10 и накопителем в 32 ГБ.

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

Первоначально эту нишу занимали крупные инновационные интернет-компании типа Google или Twitter, однако такие требования к приложениям начали всплывать во многих областях индустрии. Финансовые и телекоммуникационные компании первыми начали внедрять новые практики, чтобы удовлетворить новым требованиям, а теперь подтягиваются и остальные.

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

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

Python — это язык, который любят многие программисты. Этим языком невероятно легко пользоваться. Всё дело в том, что код, написанный на Python, отличается интуитивной понятностью и хорошей читабельностью. Однако в разговорах о Python часто можно слышать одну и ту же жалобу на этот язык. Особенно тогда, когда о Python говорят знатоки языка C. Вот как она звучит: «Python — это медленно». И те, кто так говорят, не грешат против истины.

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



Есть несколько способов ускорения Python-программ. Например, можно применять библиотеки, рассчитанные на использование нескольких ядер процессора. Тем, кто работает с Numpy, Pandas или Scikit-Learn, можно посоветовать взглянуть на программный комплекс Rapids, позволяющий задействовать GPU при проведении научных расчётов.

Приветствую сообщество, встала передо мной задача написать социальную сеть. А коль скоро язык программирования, которым я более-менее владею — это Python, я выбрал фреймворк Django для реализации проекта. Чтобы не тратить время на написание HTML шаблонов и CSS стилей, эти файлы я беру в интернете с пометкой Free. В основном это шаблоны от Colorlib.

Поехали.

Сразу оговорюсь, что использую PyCharm, поэтому могу не знать все команды из файла manage.py.

Ретро-игры с простыми механиками и пиксельной графикой способны пробуждать тёплые воспоминания у опытных игроков, и в то же время вполне доступны для более юной аудитории. Сегодня многие игры называются «ретро», но для создания ностальгического стиля требуются усилия и планирование. Именно поэтому мы пригласили ребят из Mega Cat Studios помочь нам в обсуждении этой темы. В этом посте мы рассмотрим всё необходимое для создания аутентичной графики в стиле игр для NES, в том числе важные параметры Unity, графические структуры и цветовые палитры.

Создание аутентичного арта в стиле NES

Для начала мы рассмотрим основы создания графики для игр, соответствующих ограничениям классической Nintendo Entertainment System. Это поколение консолей накладывает серьёзные ограничения на художников, стремящихся воспроизвести его аутентичную графику. Это ограничения на используемые палитры и на размер и количество объектов на экране. Кроме того, важно учитывать, что разрешение этой консоли составляет 256×240 пикселей.

Палитры

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


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

Недавно я обнаружил вот такую статью: Разница между bin, sbin, usr/bin, usr/sbin. Хотелось бы поделиться своим взглядом на стандарт.

/bin

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

Там ожидается присутствие таких команд:

cat, chgrp, chmod, chown, cp, date, dd, df, dmesg, echo, false, hostname, kill, ln, login, ls, mkdir, mknod, more, mount, mv, ps, pwd, rm, rmdir, sed, sh, stty, su, sync, true, umount, uname.

Можно сделать симлинки на /usr, но хотя во времена systemd /usr на отдельном устройстве не встречается, его еще можно встретить на встраиваемой системе, светофоре, кофемолке и PDP-11 обслуживающем важный прибор в одной из лабораторий Академии Наук.

/sbin

Утилиты, используемые для системного администрирования (и другие команды только для root), /sbin содержит двоичные файлы, необходимые для загрузки, восстановления, восстановления и/или восстановления системы в дополнение к двоичным файлам в /bin. Программы, выполняемые после того, как /usr монтируется (когда проблем нет), обычно помещаются в /usr/sbin. Локально установленные программы системного администрирования должны быть помещены в /usr/local/sbin.

Ожидаются:

fastboot, fasthalt, fdisk, fsck, getty, halt, ifconfig, init, mkfs, mkswap, reboot, route, swapon, swapoff, update.

Один из способов защиты системы от шаловливых рук юзеров — это запрет запуска этих утилит кому-попало, установкой атрибута x.
К тому же, замена /bin и /sbin на копии из архива (одинакового для всех однотипных систем) является быстрым способом починки систем без пакетного менеджера.

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

К сожалению, некоторые невысокие программисты всерьёз полагают, что Dockerfile с какой-нибудь вообще любой командой внутри — это уже сам по себе микросервис и его можно деплоить хоть сейчас. Докеры крутятся, лавешка мутится. Такой подход оборачивается проблемами начиная с падения производительности, невозможностью отладки и отказами обслуживания и заканчивая кошмарным сном под названием Data Inconsistency.

Если вы ощущаете, что пришло время запустить ещё одну аппку в Kubernetes/ECS/whatever, то мне есть чем вам возразить.

English version is also available.

Здравствуйте! Меня зовут Максим Газизов. Ранее я публиковал пост на Хабре о своих успехах и ошибках в геймдеве. И затем, спустя год работы над своим детищем под названием Wasteland Wars, я пропал из эфира. Всё потому, что меня настолько затянул процесс, как никогда раньше. Кстати, так вышло, что я потерял свой прежний аккаунт и вот создал новый.

Когда я исследую безопасность ПО, то одним из пунктов проверки является работа с динамическими библиотеками. Атаки типа DLL hijack («подмена dll» или «перехват dll») встречаются очень редко. Скорее всего, это связано с тем, что и разработчики Windows добавляют механизмы безопасности для предотвращения атак, и разработчики софта аккуратнее относятся к безопасности. Но тем интереснее ситуации, когда целевое ПО уязвимо.

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

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



Под катом будет несколько вариантов создания таких библиотек — как в виде кода, так и утилитами.

Громкий бренд или имя спикера с высокой должностью помогают заполнить конференц-залы. Люди тянутся к “звездам”, чтобы быть в тренде и узнать об их ошибках и победах. Только вот в конце выступлений участники ставят таким спикерам далеко не самые высокие оценки.
В студии создания презентаций и инфографики VisualMethod выяснили у предпринимателей и корпоративных сотрудников, что больше всего их разочаровало в докладах на конференциях. Оказалось, когда опытные спикеры игнорируют организационные слайды и переходят сразу к описанию процесса или кейса, теряется доверие. Некоторые опрошенные даже назвали такое поведение спикеров высокомерным (“не представился вообще”) и невнимательным (“в теме одно, а на словах другое”). Подробно рассказываем о том, о каких слайдах важно помнить.

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

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

«Agile мёртв». Люди всё время так говорят. Но обязательно добавляют: «Мы просто шутим». Они типа имели в виду, что это у тебя такие неправильные и глупые практики, что это для тебя Agile мёртв. Но «настоящий» Agile не мёртв. Просто все его делают неправильно. Так что я понял: настоящий Agile — это, знаете ли, Agile в теории. Даже я его внедрял. И знаете что? Мне надоело.

Недавно я видел в статьях ту же самую старую защиту: «Но-но-но, проблема в водопаде, скраме и неправильной реализации Agile, несоблюдении Манифеста… бла-бла-бла». Тогда Боб Маршалл сказал мне правду. Он сказал: «Заткнись, Чарльз. Манифест Agile — это кувшин, который мы наполняем». Он сделал несколько замечаний, с которыми мне пришлось согласиться. Я задумался. Результатом стала эта статья.