К написанию данной статьи меня побудил вопрос на Тостере, связанный с WSL. Я, после нескольких лет использования систем на ядре Linux, около полугода назад перешел к использованию Windows 10 на домашнем ПК. Зависимость от терминала и Linux окружения в моей работе практически сразу привели меня к вопросу: или ставить виртуалку или попробовать WSL. Я выбрал второе, и остался вполне доволен.

Под катом я расскажу как установить и настроить WSL, на какие я наткнулся проблемы и ограничения, как запускать Linux приложения из Windows и наоборот, а так же как интегрировать элементы окружения Xfce в окружение рабочего стола Windows.

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

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

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

Всем привет! Я тут недавно начал разбираться в одной очень интересной теме, связанной с обработкой цифровой информации. Объектом моего исследования стали помехоустойчивые коды. Когда я был студентом, я даже писал студенческую научную статью, в которой представил код на Си для кодирования информации кодом Хэмминга на Arduino. Только вот коды Хемминга вряд ли можно применить в каких‑нибудь сложных каналах связи по типу WiFi или LTE, поэтому я начал изучать другие коды. Немного погуглив, я понял что мейнстримом среди помехоустойчивых кодов являются LDPC коды.

На Хабре была статья на тему помехоустойчивого кодирования и LDPC кодов. В ней автор очень круто описал основные принципы обработки информации, закодированной LDPC кодом, и даже привел пример декодирования методом SPA и некоторые мысли о том, как это дело можно оптимизировать. Я решил привнести свою лепту и подготовил свою небольшую статью в которой расскажу про кодирование информации на примере метода Ричардсона‑Урбанке (Richardson — Urbanke method), а также рассмотрю вариант декодирования информации методом minsum и различные способы оптимизации этого метода.

Привет! Меня зовут Александр, я работаю в VK в команде браузера Atom. В его основе лежит open source-движок Сhromium. Сегодня хочу поговорить о системе мета-сборки GN. Её используют в крупных проектах Google (Chrome, Fuchsia, а также связанных с ними), и, например, когда разрабатывают браузеры на основе Chromium (то есть почти все браузеры, кроме Mozilla, Safari и совсем какой-то экзотики). Система мета-сборки GN используется для генерации ninja-файлов, описывающих этапы сборки проекта.

Изначально этот материал планировался как урок в PHP-курсе по полиморфизму. Но он, в конце концов, перерос сам урок, и я решил сделать из него отдельную статью. В ней практически ничего PHP-специфичного, поэтому рекомендуется для прочтения всем без исключения.

Напомню, что модель классов PHP взята из Java. Наличие интерфейсов и всех сопутствующих элементов очень сильно влияет на способ организации кода в PHP. Этот способ часто отличается от того, как организуется код в JavaScript, Ruby или Python. И ещё больше отличается от таких языков, как Clojure или Elixir. И всё это на фоне того, что в каждом из этих языков есть ООП.

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

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

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

Архитектура опирается на особенности среды, в рамках которой она применяется, а не на конструкции языка. Например, в вебе господствует HTTP, который построен вокруг концепции "запрос-ответ". Именно поэтому микрофреймворки разных языков выглядят так похоже, независимо от того, есть там ООП или нет: в каждом микрофреймворке есть запрос, ответ и обработчик ответа.

Подробнее о разработке я пишу в своем телеграм-канале организованное программирование. Присоединяйтесь если статья понравилась :)

CE поддерживает 69 языков, более двух тысяч компиляторов и широкий спектр архитектур, включая x86, arm, risc-v, avr, mips, vax, tensa, 68k, PowerPC, SPARC и даже древний 6502.

Хаха :). Не, я серьезно. Позвольте мне объяснить.

Хорошо. Что такое типизированный массив?

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

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

Можно ли на него ответить?

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

Одна из простых задач звучит так: «При переводе картинки из цветового пространства RGB в YUV мы выполняем прореживание, то есть выкидываем каждый четный столбец и каждую четную строку в компонентах U и V (все компоненты пикселя по 1 байту). Вопрос: во сколько раз меньше данных у нас стало?» Эта операция называется chroma subsampling и широко используется при сжатии видео, например.

Забавно, что когда-то давно, когда винчестеры были меньше, а дискеты больше, студенты реально отвечали на этот вопрос быстро. А в последние годы регулярно народ в ступор впадает. Приходится разбирать по частям: «Если выкинуть каждую четную строку и каждый четный столбец, во сколько раз меньше данных будет у компоненты?» Почти хором: «В четыре». Начинаю подкалывать: «Отлично! У нас было 3 яблока, первое осталось как есть, а от второго и третьего осталось по четвертинке. Во сколько раз меньше яблок у нас стало?» Народ ржет, но, наконец-то, дает правильный ответ (заметим, не все). 

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

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

Кому интересно как теряют мозг студенты масштабы бедствия и что с этим делать — добро пожаловать под кат!

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

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

В 2008 году я устроился ведущим инженером в НИИ Физических измерений, г. Пенза.

Для меня работа в этом НИИ была более чем знакома, я там работал с середины 80-х по середину 90-х. НИИФИ с момента своего создания было сосредоточено на создании датчиков и специализированной измерительной аппаратуры для космической отрасли.

Начало 2000-х характеризовалось тем, что цены на нефть поползли вверх, в государстве появились какие-то деньги, но одновременно стала происходить череда ярких и красочных неудач с нашими ракетами. И вопрос – а что же там происходит с нашими ракетами – создал на НИИФИ фокус ощутимого финансового потока.

Поскольку в этой организации работает куча людей, связанных между собой родственными связями, то, помимо официального молчания по всем щепетильным вопросам, организация была пронизана слухами, что у нас общий бюджет НИИ достиг сначала 0,7 (примерно 2008–2009), далее 0,9; потом 1,3; 2,1 и 2,7 (2012) миллиарда рублей.

Здесь можно задаться очень простым вопросом – а вот кто будет делать интеллектуальное наполнение проектов под эти в общем-то огромные финансовые потоки.

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

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

Кроме вакансий для стажёров я иногда случайно нажимал на объявления о вакансиях «сеньор-разработчика». Помню, больше всего меня поражало то, что первой строкой шло требование определённого количества лет работы: «Эта должность требует 5+ лет опыта».

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

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

• С опытом программирование не становится намного проще, о «проще пареной репы» можно только мечтать.

• Написание кода для множества «больших проектов» — это не только неинтересное, но и опасное занятие, гораздо менее увлекательное, чем решение алгоритмических задач в LeetCode.

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

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

Большинство из нас в повседневной жизни постоянно сталкивается с различными компьютерными системами: процессорами общего назначения (general-purpose, в основном x86) в ноутбуках и рабочих станциях, их мощными многоядерными версиями в датацентрах, мобильными процессорами в телефонах, многочисленными контроллерами в бытовой технике и на транспорте. Но помимо всех упомянутых вариантов есть ещё одно важное, хотя и редко упоминаемое семейство: цифровые сигнальные процессоры, чаще именуемые Digital Signal Processors или просто DSP.

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

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

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