Здесь представлен фрагмент будущей книги «Основные инструменты и практики для начинающего разработчика программного обеспечения» Бальтазара Рубероля и Этьена Броду. Книга должна помочь образованию подрастающего поколения разработчиков. Она охватит такие темы, как освоение консоли, настройка и эффективная работа в командной оболочке, управление версиями кода с помощью git, основы SQL, инструменты вроде Make, jq и регулярные выражения, основы сетевого взаимодействия, а также лучшие практики разработки программного обеспечения и совместной работы. В настоящее время авторы упорно работают над этим проектом и приглашают всех поучаствовать в списке рассылки.

Содержание

• cat
• head
• tail
• wc
• grep
• cut
• paste
• sort
• uniq
• awk
• tr
• fold
• sed
• Реальные примеры
• Углубляемся: циклы for и xargs
• Итоги
• Что дальше

Rust становится первоклассным языком в самых разных областях. Мы в Discord успешно используем его и на серверной, и на клиентской стороне. Например, на стороне клиента в конвейере кодирования видео для Go Live, а на стороне сервера для функций Elixir NIF (Native Implemented Functions).

Недавно мы резко улучшили производительность одной службы, переписав её с Go на Rust. В этой статье объясним, почему для нас имело смысл переписать службу, как мы это сделали и насколько повысилась производительность.

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

Как часть этого проекта я реализовал Tyler — тайловый растеризатор, который мы проанализируем в данной статье. Моей целью при разработке этого проекта были масштабируемость. настраиваемость и понятность растеризатора для людей, которые хотят немного больше понять в этой теме и поэкспериментировать с ней. Эта статья достаточно сильно связана с тем, что объяснено в серии «Растеризация за одни выходные», поэтому лучше будет прочитать и её. Я не буду предполагать, что вы её изучили, но в статье будет больше высокоуровневых объяснений — я не хочу повторять уже сказанное и то, что можно найти в других источниках.

Краткий обзор

Тайловый рендеринг (tile-based rendering или tiled rendering) — это улучшенный по сравнению с традиционным immediate-mode-рендерингом; в нём render target (RT) разделяется на тайлы (т.е. субрегионы кадрового буфера), каждый из которых содержит примитивы, которые можно рендерить в тайлы по отдельности.


Обратите внимание на выражение «по отдельности», потому что оно подчёркивает одно из самых больших преимуществ этой техники по сравнению с immediate-mode: ограничение всех операций доступа внутри тайла буферами цветов/глубин, которые остаются в «медленной» DRAM благодаря использованию отдельного тайлового кэша на чипе.

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


Проблема высшего программистского образования в том что студенты весьма подробно изучают отдельные аспекты вырванные из контекста не понимая как это всё увязывается вместе. Несколько семестров высшей математики, чтобы понимать физику, чтобы понимать электротехнику, электроприборы, ассемблер, ОС, алгоритмы, системное программирование и куча других предметов утрамбованных в стандартную пятилетнюю программу. Обилие деталей и никто не объясняет как это вписывается в общую картину, предполагается что через 5 лет студент сам увяжет это в голове, а потом пойдёт работать с .Net и никогда не притронется к электронике и режиму ядра. Я считаю, что не нужно так подробно знать о работе компьютера, достаточно общего понимания что происходит ниже по технологическому стеку. Если бы люди составляющие программы обучения для ВУЗов открывали автошколы, вы бы учили русский язык, каллиграфию и гидродинамику, потому как надо общаться с инспекторами, менять жидкости и писать объяснительные. В статье будут некоторые неточности, так что для сдачи экзамена по профильным предметам она не подойдёт, но после неё будет легче понять устройство ПК.

Под катом трафик.

В конце прошлого года компания Red Hat опубликовала доклад с описанием принципов, которым должны соответствовать контейнеризированные приложения, стремящиеся к тому, чтобы стать органичной частью «облачного» мира: «Следование этим принципам обеспечит готовность приложений к автоматизируемости на таких платформах для облачных приложений, как Kubernetes», — считают в Red Hat. И мы, изучив этот документ, с их выводами согласны, а посему решили поделиться ими с русскоязычным ИТ-сообществом.



Обратите внимание, что эта статья является не дословным переводом оригинального документа (PDF), подготовленного Bilgin Ibryam — архитектором из Red Hat, активным участником нескольких проектов Apache и автором книг «Camel Design Patterns» и «Kubernetes Patterns», — а представляет основные его тезисы в довольно свободном изложении.

Для остановки нет причин — 
Иду, скользя.
И в мире нет таких вершин,
Что взять нельзя.
В. Высоцкий

Если бы эта статья вышла не на Хабре, а в образовательном журнале, я бы начал её так: «Вспомните сайты, которые вам нравятся, на которых удобная навигация и приятный интерфейс. А знаете ли вы, что это только верхушка айсберга…». Но на Хабре это знают, пожалуй все, поэтому никакой лирики. Бэкенд любого веб-проекта — это сложная система, которая позволяет приложению быстро работать, качественно искать, шустро отдавать информацию пользователю, надёжно и безопасно хранить данные и при необходимости работать с другими внешними системами. Это как швейцарские часы: покупают их за стиль и шильдик, но ценители знают, что под сдержанным циферблатом кроется волшебный мир часового механизма. И бэкенд-разработчики — это маги механизмов, организмов, кишочек, внутренностей или как вы ещё это называете у веб-приложений. Эх, без лирики не удалось! 

Короче, сегодня разбираем очередную профессию в серии «Профессия…». Итак, а что, если пойти в бэкенд-разработчики? 

Бэкенд это всегда немного боль

Доброго времени суток, друзья!

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

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

Буду признателен за развернутые комментарии. Все замечания будут учтены при редактировании статьи.

Итак, поехали.

Доброго времени суток, друзья!

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

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

Давно, ещё в 1960-х, Гордон Мур, один из основателей компании Intel, заметил, что количество транзисторов, которые можно уместить на кремниевом чипе, удваивается примерно каждые два года. Поскольку количество транзисторов связано с вычислительной мощностью, это означало, что, по сути, вычислительная мощность удваивается каждые два года. Так родился закон Мура, обеспечивший для работающих в компьютерной индустрии людей – по крайней мере, для тех, кому ещё нет сорока – такую же надёжную основу, какую ньютоновские законы движения обеспечили для инженеров-механиков.

Есть в мире вещи, которые мы принимаем как нечто само собой разумеющееся, хотя они являются истинными шедеврами. Одними из таких вещей являются утилиты Linux, такие, как ls и ps. Хотя они обычно воспринимаются как простые, это оказывается далеко не так, если мы заглянем внутрь. И таким же оказывается ELF, Executable and Linkable Format. Формат файлов, который используется повсеместно, но мало кто его понимает. Это краткое руководство поможет вам достичь понимания.



Прочтя это руководство, вы изучите:

• Зачем нужен формат ELF и для каких типов файлов он используется
• Структуру файла ELF и детали его формата
• Как читать и анализировать бинарное содержимое файла ELF
• Какие инструменты используются для анализа бинарных файлов

Меня зовут Андрей Артемьев, я работаю в Microsoft над ядром ОС Windows 10, ранее я работал над Windows 10x (WCOS), XBox, Windows Phone и Microsoft Edge. Я хочу популярно в образовательных целях рассказать о том как работает компьютер на примере клавиатурного ввода и Windows 10. Данный цикл статей рассчитан в первую очередь на студентов технических специальностей. Мы рассмотрим какой путь проходит информация о нажатой клавише от клавиатуры до отображения в Notepad.exe. В виду обширности и междисциплинарности темы в статьях могут быть неточности, о которых сообщайте в комментариях. Какая-то информация может быть устаревшей в виду скорости с которой развивается Windows.

Вершина технологий того времени.

В 1993 году id Software выпустила шутер от первого лица Doom, который быстро превратился в феномен. Сегодня считается, что это одна из игр, оказавших самое большое влияние за всю историю.

Десять лет спустя после выпуска Doom, в 2003 году, журналист Дэвид Кушнер опубликовал книгу об id Software под названием Masters of Doom, которая с тех пор стала каноническим описанием процесса создания Doom. Я прочитал Masters of Doom несколько лет назад и почти ничего уже не помню, но одна история из книги о ведущем программисте Джоне Кармаке сохранилась в моей памяти. Моё описание будет не совсем точным (подробнее см. ниже), но если вкратце, то на раннем этапе разработки Doom Кармак осознал, что написанный им для игры 3D-рендерер при рендеринге отдельных уровней начинал тормозить. Это было неприемлемо, потому что Doom должен был стать активной и даже бешеной игрой. Осознав, что проблема рендерера была настолько фундаментальной, что ему придётся искать более оптимальный алгоритм рендеринга, Кармак начал читать исследовательские статьи. В результате он реализовал технику под названием «двоичное разбиение пространства» (binary space partitioning, BSP), которая раньше никогда не применялась в видеоиграх, и значительно ускорил таким образом движок Doom.

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

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

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

Хотя люди обычно признают удобства ФП фич, ведь намного приятнее писать:

int Factorial(int n)
{
    Log.Info($"Computing factorial of {n}");
    return Enumerable.Range(1, n).Aggregate((x, y) => x * y);
}

чем ужасные императивные программы вроде

int Factorial(int n)
{
    int result = 1;
    for (int i = 2; i <= n; i++)
    {
        result *= i;
    }
    return result;
}

Так ведь? С одной стороны да. А с другой именно вторая программа в отличие от первой является функциональной.

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

Оглавление

Предисловие
1. Настройка git
....1.1 Конфигурационные файлы
....1.2 Настройки по умолчанию
....1.3 Псевдонимы (aliases)
2. Основы git
....2.1 Создание репозитория
....2.2 Состояние файлов
....2.3 Работа с индексом
....2.4 Работа с коммитами
....2.5 Просмотр истории
....2.6 Работа с удалённым репозиторием
3. Ветвление в git
....3.1 Базовые операций
....3.2 Слияние веток
....3.3 Rerere
4. Указатели в git
....4.1 Перемещение указателей
5. Рекомендуемая литература

Предисловие

Git — самая популярная распределённая система контроля версиями.[1][2]

Основное предназначение Git – это сохранение снимков последовательно улучшающихся состояний вашего проекта (Pro git, 2019).

Рендеринг текста: насколько сложным он может быть? Оказывается, невероятно сложным! Насколько мне известно, буквально ни одна система не выводит текст «идеально». Где-то лучше, где-то хуже.

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

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

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

Как увидеть цвет, которого в природе не бывает?



Четыре года назад на Хабре был пост с интересным и полезным видео «Как устроен цвет». Лектор — Дмитрий Николаев, заведующий сектором зрительных систем ИППИ РАН.

Я сделал расшифровку (в меру своего понимания материала), потому что считаю и тему важной и подачу — отличнейшей. Пока набирал текст, чуть не поменял своё φ(λ). Слово спикеру:

Поговорим о математике и геометрии цвета, о том, какие абстрактные структуры заложены в этом слове.

Что такое «цвет» не знает никто.

Цвет — это что-то, о чем говорит человек, наблюдающий и познающий мир с помощью глаза.

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

В физике нет цвета, а есть спектральные свойства излучения.

«Цвет» связан с относительным распределением спектральной энергии, мощности или потока излучения. (При прохождении через призму человек видит характерную «радугу».)

Совершенно точно, «цвет» — психологический феномен. Цвет — это ощущение, к объективной физике не имеющий отношения.

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

Javascript — странный. Не верите? Ну попробуйте тогда преобразовать массив строк в целые числа с помощью map и parseInt. Запустите консоль (F12 на Chrome), вставьте код ниже и нажмите Enter

['1', '7', '11'].map(parseInt);

Вместо ожидаемого массива целых чисел [1, 7, 11] мы получаем [1, NaN, 3]. Но как так? Чтобы узнать в чём тут дело, сначала нам придётся поговорить о некоторых базовых концепциях Javascript. Если вам нужен TL;DR, пролистывайте статью до самого конца.

«какая-то странная антикварная х██ня, написанная ирландским кулибиным в 1847 ну, хорошо, что и такая бывает, конечно» Миша Вербицкий

В 16-м году мне на глаза попались «Начала» Евклида в интерпретации Оливера Бирна. Фишка этой книги в том, что вместо буквенных обозначений навроде «треугольник ABC» там прямо в текст помещаются миниатюры частей построения, то есть, например, картинка с соответствующим треугольником. Насколько сделать такую книгу, как можно представить, было адовой работой в середине XIX века, настолько же легко, с правильными инструментами, это должно бы быть теперь. И, в общем, решил я в этом убедиться наверняка.

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

Мы торопимся исправить это годами длящееся недоразумение.

Итак, мы предлагаем вашему вниманию набор данных из 4000 часов аннотированной устной речи, собранный из различных интернет-источников.

Подробности под катом.