Это всего лишь комментарий на Reddit. Но он мне показался весьма интересным, а упоминаний в русскоязычных дискуссиях я не видел. Абзацы, помеченные TL;DR, пропущены.

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

При этом почти все приличные светодиодные лампы, которые можно купить в России, производятся в том же самом Китае.

Однажды в комментариях к моей статье о плохих китайских лампочках-свечках один из комментаторов написал: «Я отцу взял эти 5w. В люстре у него 15 штук. Доволен выше крыши и ещё попросил 15 штук.»

Я не пожалел кровных пяти долларов и решил проверить, заказав две лампочки.

В статье описан личный опыт создания и применения древовидных поддержек при печати сложных объектов на 3D-принтере.



Обычно поддержки создаются при 3D-печати в ПО для генерации gcode, например в Cura, прямо перед генераций gcode. Проще всего на 3D-принтере печатаются объекты в форме пирамиды. Тогда каждый следующий слой ложится на предыдущий и не нависает над пустым пространством. Поддержки позволяют печатать нависающие части объектов, но стандартные поддержки не всегда оптимальны с точки зрения расхода пластика и простоты их последующего отделения от самого объекта, поэтому в этой статье я опишу личный опыт создания и применения древовидных поддержек.

В этой статье мы поговорим об ошибках, совершаемых программистами на Bash. Во всех приведённых примерах есть какие-то изъяны. Вам удастся избежать многих из нижеописанных ошибок, если вы всегда будете использовать кавычки и никогда не будете использовать разбиение на слова (wordsplitting)! Разбиение на слова — это ущербная легаси-практика, унаследованная из оболочки Bourne. Она применяется по умолчанию, если вы не заключаете подстановки (expansions) в кавычки. В общем, подавляющее большинство подводных камней так или иначе связаны с подстановкой без кавычек, что приводит к разбиению на слова и глоббингу (globbing) получившегося результата.

По сей день в Интернете можно встретить споры о том, какой же графический API лучше: Direct3D или OpenGL? Несмотря на свой религиозный характер, такие словесные баталии приносят полезный результат в виде неплохих исторических обзоров развития аппаратно-ускоренной графики.



Целью данного поста является перевод одного из таких экскурсов в историю, написанного Джейсоном МакКессоном (Jason L. McKesson) в ответ на вопрос «Почему разработчики игр предпочитают Windows». Этот текст вряд ли отвечает на поставленный вопрос, но историю развития и противостояния двух самых популярных графических API он описывает очень красочно и довольно подробно, поэтому в переводе я сохранил авторскую разметку. Текст написан в середине 2011 года и охватывает промежуток времени, начинающийся незадолго до появления Direct3D и до момента написания. Автор оригинального текста является опытным разработчиком игр, активным участником StackOverflow и создателем обширного учебника о современном программировании 3D-графики. Итак, предоставим слово Джейсону.

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

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

В настоящей статье я исследую человеческие и машинные аспекты задержки при печатании (вводе с клавиатуры или «запаздывание ввода») и представляю экспериментальные данные по задержке при работе с популярными редакторами текста и кода.

С недавних пор Задержка стала горячей темой в компьютерном мире — сейчас есть клавиатуры с малой задержкой, мониторы на 144 Гц, специальные технологии, уменьшающие время задержки (как, например, FreeSync или G-Sync), интересующиеся этим сообщества и прочее и прочее. Конечно, часть этой моды создана маркетингом, но правда в том, что малая задержка стала возможной и желательной.

Очевидно, что геймеры — первые, кто выигрывает от таких улучшений. В некоторых областях, таких как виртуальная реальность, задержка оказывается решающим фактором, даже когда речь идёт об одной миллисекунде. Но что сказать о программистах? Нужно ли нам «печатать с удовольствием», чтобы «разрабатывать с удовольствием»? Давайте разберёмся.

Что мы имеем:
1. компьютер с осью и установленными mysql, apache, php (тут ничего писать не буду, благо мануалов хватает)
2. интернет с присваиваемым динамическим IP, роутер.

Что мы хотим:
1. Что бы люди вбивая в адресную строку браузера доменное имя второго уровня (купленное нами или полученное на каком либо сервисе), попадали на наш сайт (в независимости от того на каком IP он сейчас находиться).
2. Хотим это бесплатно.

Итак, то как это было реализовано мной в виде краткой инструкции можно прочитать под катом, быть может кому-нибудь это пригодиться или просто-напросто будет интересно. Так же, буду рад объективной критике. Спасибо за внимание, и кому интересно добро пожаловать под хабракат.

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

Вы заметили, что Фейсбук обрёл сверхъестественную способность распознавать ваших друзей на ваших фотографиях? В старые времена Фейсбук отмечал ваших друзей на фотографиях лишь после того, как вы щёлкали соответствующее изображение и вводили через клавиатуру имя вашего друга. Сейчас после вашей загрузки фотографии Фейсбук отмечает любого для вас, что похоже на волшебство:

Вы бы никогда не подумали, но это прогулка по пространству нейросети-фальшивомонетчика. Сделано крутейшими людьми Anders Boesen Lindbo Larsen и Søren Kaae Sønderby

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

Метафора, может быть, с некоторой моральной двусмысленностью, но в целом пример не хуже прочих — деньгам (банкнотам) определенно свойственна какая-то сложная структура, тут у них цифра, тут буква, а там хитрые водяные знаки. Предположим, нам нужно понять, как они сделаны, и узнать правило, по которым их печатают. Какой план?

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

Ну, раз так, давайте попробуем их подделать.

Я уверен, что многим программистам знакома формула:


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

Вычисляет она относительную яркость цвета (relative luminance или в некоторых контекстах luma; не путать с lightness и brightness) и широко применяется для преобразования цветного RGB-изображения в Grayscale и связанных с этим задач.

Формула растиражирована и процитирована в тысячах статей, форумных обсуждений и ответов на StackOverflow… Но дело в том, что единственно-правильное её место — на свалке истории. Использовать её нельзя. Однако же используют.

Но почему нельзя? И откуда же взялись именно такие коэффициенты?

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

«Мутации» машинного кода

В качестве примера возьмём приставку NES (известную у нас как Dendy), в которой используется процессор 6502. Система команд у него очень проста — опкод представлен всегда одним байтом, и каждый из 256 хоть что-то, да делает. Никаких «защит» от дурака не предусмотрено, и почти любой случайный набор байт будет выполняться без сопротивления со стороны процессора. Таким образом, мы можем взять ROM какой-нибудь игры, исправить в нём случайные биты (будем называть это «мутациями») — и после запуска наблюдать забавные глюки в разных неожиданных местах, но при этом в целом игра скорее всего будет работоспособной. Похоже, что на YouTube имеется целый жанр подобного видео. Полученный таким образом машинный код наверняка не очень корректен, но в большинстве случаев процессор сможет его выполнить и что-то сделать.

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

Являясь большим фанатом Python и фреймворка Django постоянно искал решение, как сделать разработку новых веб-проектов быстрее и удобнее.

Все, кто знаком с разработкой на Django, знают насколько неудобно строить на нем интуитивно понятную админ.панель. До мегапопулярного WordPress очень далеко, что делает порог вхождения в разработку сайтов выше, чем у PHP-фреймворков и CMS.
После долгого поиска и тестирования различных решений я нашел для себя оптимальный вариант — Wagtail CMS.

Wagtail — это полноценная CMS написанная на Django компанией Torchbox. За что им большое спасибо. Проект с открытым исходным кодом, поддерживается сообществом энтузиастов и выпускается под BSD лицензией.

Азбука безопасности Ubuntu

«Мои первые 5 минут на сервере» Брайана Кеннеди — отличное введение, как быстро обезопасить сервер от большинства атак. У нас есть несколько исправлений для этой инструкции, чтобы дополнить ею наше полное руководство. Также хочется подробнее объяснить некоторые вещи для более юных инженеров.

Каждое утро я проверяю почтовые уведомления logwatch и получаю основательное удовольствие, наблюдая несколько сотен (иногда тысяч) безуспешных попыток получить доступ. (Многие довольно прозаичны — попытки авторизоваться как root с паролем 1234 снова и снова). Приведённая здесь общая методика подходит для серверов Debian/Ubuntu, которые лично мы предпочитаем всем остальным. Они обычно служат только хостами для контейнеров Docker, но принципы те же.

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

Примечание: Эта справка создана как базовая азбука. Её следует расширить и дополнить в соответствие с вашими потребностями.

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

Поиск по хабру показал что ещё никто не рассказывал об инструменте, который я решил использовать. Важным отличием этого инструмента является то, что это настоящий unix-way, что намекает на одинаковую её работу на всех GNU/Linux дистрибутивах, хотя по слухам утилита работает и на ОС от Apple и даже на MS Windows (cygwin), хотя автор не очень рад такому использованию.

Клонирование объектов в JavaScript довольно частая операция. К сожалению, JS не предоставляет быстрых нативных методов для решения этой задачи.

К примеру, популярная Node.JS ORM Sequelize, которую мы используем на backend-е нашего проекта, значительно теряет в производительности на предвыборке большого (1000+) количества строк, только на одном клонировании. Если вместе с этим, к примеру, в бизнес-логике использовать метод clone известной библиотеки lodash — производительность падает в десятки раз.

Но, как оказалось, не всё так плохо и современные JS-движки, такие как, например, V8 JavaScript Engine, могут успешно справляться с этой задачей, если правильно использовать их архитектурные решения. Желающим узнать как клонировать 1 млн. объектов за 30 мс — добро пожаловать под кат, все остальные могут сразу посмотреть реализацию.

Продолжаем серию статей о мобильном геймдеве. В этой статье я расскажу как рендерить UTF-8 текст с помощью SDF Bitmap шрифтов, как эти шрифты создавать и как использовать эту технику для качественного рендеринга иконок.

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

Итак, пока наши новые повелители отдыхают, давайте я попробую рассказать как работает AlphaGo. Пост подразумевает некоторое знакомство читателя с предметом — нужно знать, чем отличается Fan Hui от Lee Sedol, и поверхностно представлять, как работают нейросети.