«Анекдот — небольшой забавный, смешной рассказ» (Из толкового словаря).
Наверное, надо бы предупредить читателей, что мол «Детям до 40 лет читать не рекомендуется». Но я, пожалуй, этого делать не буду. Все чинно и благородно.

В статье речь пойдет об одном очень не новом проекте, который создавался совсем в другое время и совсем в других условиях. Это моя старенькая RTS под названием Земля онимодов (Onimod land). Чтобы было сразу понятно, что она собой представляет, можно посмотреть коротенькое видео:

Не поймали за хвост удачу в виде главного бага известного сервиса, нет желания “толкаться” на oDesk или не хочется делать то же, что уже и так делаете в рабочее время?

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

Примечание переводчика: визит под кат этого поста означает большие объёмы потреблённого трафика. И это иронично, если учесть поднятую тему. Но всё сразу встаёт на свои места, если помнить, что в оригинале это было выступление в прошлом ноябре в Сиднее длиной почти в час. Чтение поста занимает куда меньше времени. В форме видеозаписи (1280×720) речь занимает два гигабайта. Пост же занимает всего лишь 12 МиБ. Рекомендуется просмотр на широких мониторах.



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

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

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

Представим себе, что в один прекрасный день вам пришла в голову идея процессора собственной, ни на что не похожей архитектуры, и вам очень захотелось эту идею реализовать «в железе». К счастью, в этом нет ничего невозможного. Немного верилога, и вот ваша идея реализована. Вам уже снятся прекрасные сны про то, как Intel разорилась, Microsoft спешно переписывает Windows под вашу архитектуру, а Linux-сообщество уже написало под ваш микропроцессор свежую версию системы с весьма нескучными обоями.
Однако, для всего этого не хватает одной мелочи: компилятора!
Да, я знаю, что многие не считают наличие компилятора чем-то важным, считая, что все должны программировать строго на ассемблере. Если вы тоже так считаете, я не буду с вами спорить, просто не читайте дальше.
Если вы хотите, чтобы для вашей оригинальной архитектуры был доступен хотя бы язык С, прошу под кат.
В статье будет рассматриваться применение инфраструктуры компиляторов LLVM для построения собственных решений на её основе.
Область применения LLVM не ограничивается разработкой компиляторов для новых процессоров, инфраструктура компиляторов LLVM также может применяться для разработки компиляторов новых языков программирования, новых алгоритмов оптимизации и специфических инструментов статического анализа программного кода (поиск ошибок, сбор статистики и т.п.).
Например, вы можете использовать какой-то стандартный процессор (например, ARM) в сочетании с специализированным сопроцессором (например, матричный FPU), в этом случае вам может понадобиться модифицировать существующий компилятор для ARM так, чтобы он мог генерировать код для вашего FPU.
Также интересным применением LLVM может быть генерация исходных текстов на языке высокого уровня («перевод» с одного языка на другой). Например, можно написать генератор кода на Verilog по исходному коду на С.



КДПВ

Эта статья – о рисках смены руководства в больших компаниях и характерных явлениях при попытках игнорировать закон эффективного управления собственностью:

Эффективно управлять можно только той собственностью, которую мог бы создать сам.
Кто не может создать, – будет только разрушать!
И.А. Дедюхова, Кодекс Хамурапи

Картинка для привлечения внимания читателей из поколений Y и Z:

Краткое содержание

Новый директор себе в подчиненные и советники пригласит своих «проверенных людей». Увеличение штата топ-менеджеров в условиях фиксированного ФОТ повлечет за собой сокращение рядовых сотрудников на значительный процент.
Новый директор в первую очередь будет сокращать те подразделения, работу которых он не понимает. Под прессом психологического давления руководители этих подразделений возмут на себя обязательства самостоятельно разработать планы по сокращению и принять на себя все риски их реализации.
Сокращения пройдут под флагом повышения эффективности, но для «непонятных директору» подразделений не смогут сформулировать критерии этой эффективности, кроме «минимизации затрат». Цель по минимизации затрат без дополнительных обоснованных ограничений – это цель по уничтожению, и не имеет отношения к настоящей оптимизации.
Отсекая непонятные ему части компании (выводя в аутсорс и т.п.), директор попытается превратить компанию в ту, работу которой он полностью способен понять, которой он в полной мере способен управлять.
Проблему нехватки знаний в технической области новый директор и его команда компенсируют «помощью» от западных консалтинговых компаний. Это приведет к ситуации внешнего управления, причем без всякой ответственности за диктуемые извне решения.
Внешняя и внутренняя отчетность о работе компании до самого конца не будет показывать никаких признаков проблем, т.к. тому, кто принес плохие вести не выдают премию, а рубят голову.

---

В Яндексе – идеальные для ИТ отцы-основатели… а какую позитивную книгу о них и об идеологии Яндекса Соколов-Митрич написал… Но что в Яндексе сложилось за несколько лет «внизу»? В этом посте последняя ссылка показывает – полный мрак.
Второй пример – Магнитом управляет такой умный и правильный Сергей Галицкий (почитайте его интервью), но «внизу» творится какой-то ад: «Мы не рабы» кричат его сотрудники.

Почему так? Что же за злой рок преследует большие компании?

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

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

1. Усиление строгости при движении приказов сверху-вниз.
2. Положительная обратная связь и искажение отчетности при движении информации снизу-вверх.
3. Уменьшение взаимопонимания с ростом количества промежуточных звеньев между сотрудниками.

Далее рассмотрим их подробнее и сформулируем:

4. Советы сотрудникам, идущим работать в большие компании.
5. Своё собственное скромное мнение, почему Яндекс всё ещё хорош на фоне многих других.


Движение сверху-вниз приказов и всего прочего. Вы же не ожидали увидеть здесь другую картинку?

Объяснение закона гравитации из мультфильма «Физика для самых маленьких»

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

Я хотел бы подарить сообществу Хабра статью, в которой стараюсь дать достаточно полное описание подходов к алгоритмам подсчёта единичных битов в переменных размером от 8 до 64 битов. Эти алгоритмы относятся к разделу так называемой «битовой магии» или «битовой алхимии», которая завораживает своей красотой и неочевидностью многих программистов. Я хочу показать, что в основах этой алхимии нет ничего сложного, и вы даже сможете разработать собственные методы подсчёта единичных битов, познакомившись с фундаментальными приёмами, составляющими подобные алгоритмы.

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



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

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

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

Кто лишится в ближайшие лет десять работы, а у кого будут новые перспективные вакансии.

— Что такое векторное управление?
— Держать ток под 90 градусов.

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

Если бы язык С был оружием

От автора: Наброски для этой статьи появились еще в начале 2015 года, правда, до публикации материалов дело так и не дошло. Наконец, решив, что в ящике моего письменного стола от вышеупомянутого «черновика» не будет никакой пользы, представляю его вашему вниманию в исходном виде. Единственное, что изменилось в тексте – год, с 2015 на 2016.

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

Итак, статья ...

Первое правило программирования на С – не используйте его, если можно обойтись другими инструментами.

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

Кладбище мессенджеров, на котором обязательно должны оказаться Skype, Viber, WhatsApp, Hangouts, ooVoo, Apple iMessage, Telegram, Line, Facebook messenger и еще сотни мессенджеров, которым только предстоит выйти в ближайшее время.

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

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

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

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

Меня зовут Владимир Пляшкун и в сегодняшней статье я собираюсь представить бесплатный статический анализатор Verone для C++03/C++11/C++14, главной особенностью которого является анализ на лету.

В данном посте мы бы хотели познакомить пользователей Хабра с базовыми правилами программирования криптографических алгоритмов. Этот набор правил под названием «Стандарт криптографического программирования» (“Cryptography coding standard”) был создан в 2013 году по инициативе одного из гуру современной криптографии Жана-Филиппа Омассона. Несмотря на то, что описанные в нем подходы хорошо известны тем, кто профессионально занимается разработкой систем защиты, новичкам и студентам, думаем, будет интересно ознакомиться с предлагаемым текстом, являющимся переводом набора правил с сайта cryptocoding.net.

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

Процессоры, используемые в наших продуктах — это, в основном, 16- и 32-битные микроконтроллеры Microchip, имеющие RAM от 8 до 32 кБ, и ROM от 128 до 512 кБ, без MMU. Иногда, для самых простых устройств, используются еще более скромные 8-битные чипы.

Очевидно, что у нас нет (разумных) шансов использовать ядро Linux. Так что нам нужна какая-нибудь RTOS (Real-Time Operating System). Находятся даже люди, которые не используют никаких ОС в микроконтроллерах, но я не считаю это хорошей практикой: если железо позволяет мне использовать ОС, я ее использую.

Несколько лет назад, когда мы переходили с 8-битников на более мощные 16-битные микроконтроллеры, мои коллеги, которые были гораздо более опытными, чем я, рекомендовали вытесняющюю RTOS TNKernel. Так что это — та ОС, которую я использовал в разных проектах в течение пары лет.

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

На момент написания этого текста текущей версией Android Studio была версия 1.0.1. Компилятор Intel C++ Compiler for Android, будучи частью Intel Integrated Native Developer Experience (Intel INDE), поддерживает Android Studio 1.0.1 в Intel INDE 2015 Update 1. Поскольку Android Studio 1.0.1 не поддерживает Android NDK, в этой статье описаны шаги для создания нативного Android-приложения с использованием Android NDK r10d и компилятора Intel C++ Compiler for Android. Поехали!

Android Studio в качестве системы сборки использует Gradle. На момент написания статьи Gradle в процессе сборки вызывала систему NDK. В Android NDK r10 и более поздней версии после инсталляции Intel INDE компилятор Intel C++ Compiler for Android (ICC) не является более используемым по умолчанию компилятором в системе сборки NDK.

Думаю, что большинство из местных обитателей знакомы с понятием сниффера. Несмотря на то, что конечная цель у них одна и та же (перехват пакетов, соответствующих определённым критериям), достигают они её совершенно разным образом. Какой-то софт слушает указанный сетевой интерфейс (например, Wireshark, где это реализовано при помощи библиотеки Pcap), а какой-то — перехватывает вызовы ответственных за взаимодействие с сетью WinAPI-функций. И у того, и у другого метода есть свои плюсы и минусы, однако если по задаче необходим перехват пакетов от конкретного заранее известного приложения, то второй вариант, как правило, банально удобнее. В этом случае нет нужды узнавать IP-адреса и порты, которые использует данная программа (особенно учитывая тот факт, что их может быть довольно много), и можно просто сказать «я хочу перехватывать все пакеты вот этого приложения». Удобно, не правда ли?

Пожалуй, самым популярным на сегодняшний день сниффером, работающим по принципу перехвата вызовов определённых WinAPI-функций, является WPE Pro. Возможно, многие из вас слышали о нём на различных форумах, посвящённых онлайн-играм, ведь именно для получения преимуществ в различных играх этот сниффер в большинстве случаев и используется. Свою задачу он выполняет прекрасно, однако у него есть один неприятный недостаток — он не умеет работать с 64-битными приложениями. Так уж вышло, что по одной из возникших задач мне как раз понадобилось перехватывать пакеты от 64-битного приложения, и я посмотрел в сторону Wireshark. К сожалению, использовать его в данной ситуации было не очень удобно — исследуемое приложение отправляло данные на разные IP-адреса, каждый раз открывая новый порт. Погуглив немного, я обнаружил, что готовых аналогов WPE Pro с поддержкой x64 нет (если они всё же есть, буду признателен за ссылки в комментариях — обратите внимание, что речь идёт о Windows). Автор WPE Pro не оставил никаких контактных данных на официальном сайте и в самом сниффере, так что я принял решение разобраться в этом вопросе самостоятельно.

Как протекал процесс и что из этого вышло, читайте под катом.

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

Рассмотрим пример паспорта гражданина РФ, на котором легко увидеть периодический голографический узор.



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

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