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

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

Определим первую часть как вводную. Здесь мы поговорим о хардварном инкапсуляторе ethernet-трафика, созданном на FPGA, обсудим его основные функции, архитектурные особенности и преимущества по сравнению с программными решениями.

Вторая часть, назовем ее «сетевой», будет более интересна для разработчиков железа, желающих ознакомиться с сетевыми технологиями поближе. Она будет посвящена тому, какую роль «Etherblade.net» может занять в сетях операторов связи. Так же разговор пойдет о концепции SDN (software defined networking) и о том, как открытое сетевое железо может дополнять решения больших вендоров, таких как «Cisco» и «Juniper», и даже конкурировать с ними.

И третья часть — «хардварная», которая скорее заинтересует сетевых инженеров, желающих приобщиться к аппаратному дизайну и начать разрабатывать сетевые устройства самостоятельно. В ней мы подробно рассмотрим FPGA-workflow, «союз софта и железа», FPGA-платы, среды разработки и другие моменты, рассказывающие о том, как подключиться к участию в проекте «EtherBlade.net».
Итак, поехали!

Однажды я разговаривал с основателем израильского стартапа, который разрабатывал скоростную базу данных на GPU. В их стеке были Haskell и C++, и основатель жаловался, как тяжело найти людей в команду. В Москву он прилетал в том числе искать хороших программистов.

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

Все, что я слышал про Хаскель со стороны с тех пор, сводилось к одному — «с ним шутки плохи». Чтобы узнать хаскелистов получше, я пришел с расспросами к ним в телеграм-чат. Было довольно страшно, и как оказалось, не зря.

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

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

История реальная, я все видел своими глазами.

Несколько лет один парень, как и многие из вас, работал программистом. На всякий случай напишу так: «программистом». Потому что он был 1Сником, на фиксе, производственной компании.

До этого он пробовал разные специальности – 4 года во франче программистом, руководителем проектов, умел закрывать по 200 часов, одновременно получая процент с проекта, за руководство и немного занимаясь продажами. Пробовал самостоятельно разрабатывать продукты, был начальником IT-отдела в большой компании, численностью 6 тысяч человек, примерял разные варианты применения своей кавычечной профессии – программиста 1С.

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

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

Что это такое, и с чем его едят.

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

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

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

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

Возможно, это последний мой текст, потому что вчера у меня в жизни случился крутой поворот.

^{Одно из изданий этой механики}

Есть колода из 100 карт с натуральными числами от 1 до 100, каждого по одному. Вы и второй игрок берёте по 3 карты из этой колоды. Задача — одну за одной выложить их на стол в порядке возрастания. Но нельзя меняться информацией между собой и показывать карту до момента, пока она не будет положена на стол. То есть нельзя говорить, стучать по столу, подмигивать и так далее — ничего нельзя.

Если в конце игры 6 карт выложены правильно, оба игрока выигрывают. В момент, когда первая же карта ложится неправильно — оба игрока проигрывают.

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

Не спешите под кат, сначала подумайте чуть-чуть, пожалуйста.

Ветеран программирования трёхмерной графики Майкл Абраш на примере разработки первого Quake рассказывает о необходимости творческого мышления в программировании.

Много лет назад я работал в теперь уже не существующей компании-производителе видеоадаптеров Video Seven. Там я помогал в разработке клона VGA. Мой коллега Том Уилсон, долгие месяцы круглосуточно работавший над разработкой VGA-чипа Video Seven, стремился сделать VGA как можно более быстрым, и был уверен, что его производительность оптимизирована почти по максимуму. Однако когда Том уже вносил в конструкцию чипа последние штрихи, до нас донеслись слухи, что наш конкурент Paradise достиг ещё большей производительности в своём разрабатываемом клоне, добавив в него FIFO.

На этом слухи заканчивались — мы не знали, ни что это за FIFO, ни насколько он помог, ничего другого. Тем не менее, Том, обычно приветливый и расслабленный человек, превратился в активного, одержимого фанатика со слишком большим процентом кофеина в крови. Исходя из этих крупиц информации, он пытался выяснить, что же удалось сделать Paradise. В конце концов он пришёл к выводу, что Paradise вероятно вставил FIFO-буфер записи между системной шиной и VGA, чтобы когда ЦП выполнял запись в видеопамять, записываемые данные сразу же попадали в FIFO, и это позволяло ЦП продолжать обработку, а не простаивать каждый раз, когда он выполнял запись в память дисплея.

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

Зачастую при разработке алгоритмов мы упираемся в предел вычислительной сложности, который, казалось бы, преодолеть невозможно. Преобразование Фурье имеет сложность $$, а быстрый вариант, предложенный около 1805 года Гаусом¹ (и переизобретенный в 1965 году Джеймсом Кули и Джоном Тьюки) $$. В данной статье хочу вам показать, что можно получить результаты преобразования за линейное время $$ или даже достичь константной сложности $$ при определенных условиях, которые встречаются в реальных задачах.

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

P. S. Статья содержит математические формулы, добавленные макросами хабраредактора. Говорят, что они иногда не отображаются. Также есть много анимаций в формате gif.

Да-да, именно «байт» и именно по индейски (не по индийски). Начну по порядку. В последнее время тут, на Хабре, стали появляться статьи о байт-коде. А когда-то давным-давно я развлекался тем, что писал форт-системы. Конечно, на ассемблере. Они были 16-ти разрядными. На x86-64 никогда не программировал. Даже с 32 поиграться не удалось. Вот и пришла такая мысль — а почему бы нет? Почему бы не замутить 64х разрядный форт, да ещё с байт-кодом? Да еще и на Linux, где я тоже ничего системного не писал.

У меня есть домашний сервер с Linux. В общем, я немного погуглил и узнал, что ассемблер на Linux называется GAS, а команда as. Подключаюсь по SSH к серверу, набираю as — есть! Он у меня уже установлен. Ещё нужен компоновщик, набираю ld — есть! Вот так, и попробуем написать что-нибудь интересное на ассемблере. Без цивилизации, только лес, как у настоящих индейцев :) Без среды разработки, только командная строка и Midnight Commander. Редактор будет Nano, который висит у меня на F4 в mc. Как там поет группа «Ноль»? Настоящему индейцу нужно только одного… Что еще нужно настоящему индейцу? Конечно, отладчик. Набираем gdb — есть! Ну что же, нажмем Shift+F4, и вперед!

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


Только за последние 18 лет люди придумали множество языков, среди которых, вероятно, самыми популярными стали Swift, Kotlin и Go. При этом отличительная черта языка программирования 21 века — это отсутствие каких-либо отличительных черт. Самое приятное в работе с такими языками — за изучением одного из них можно провести выходные и под конец заявить, что вам удалось освоить популярную новинку, по факту же не узнав ничего нового. В них действительно нет ничего нового. Все современные языки созданы на основе какой-либо правильной и проверенной формулы, имя которой, вероятнее всего, Objective-C, Java или C.

«Отсутствие новизны» можно считать ценной чертой, но подобная ситуация вызывает один вопрос. Действительно ли перед нами языки нового, 21 века, или все это — просто отражение плохих привычек программирования 20 века?

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

Долой синтаксис!

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

Предисловие

Данный текст предполагает, что читатель ознакомлен с т.н. agile-манифестом разработки программного обеспечения и его т.н. основополагающими принципами.

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

Содержание

1. Манифест жёсткого программиста
2. Основополагающие принципы манифеста жёсткого программиста
3. Комментарии

Манифест жёсткого программиста

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

Концепция важнее новых требований
Качество важнее скорости
Делать как надо важнее, чем делать как просят

То есть, не отрицая важности того, что справа, мы всё-таки более ценим то, что слева.

В недавней статье товарищ KvanTTT поднял вопрос:

Можете пояснить что вам не нравится в современной записи (математических положений и) формул и как ее можно улучшить?

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

Сразу скажу, материал холиварный. Местами слишком эмоциональный. Очень спорный. Слишком личный — часто основан на собственном опыте, небогатом, хоть и разнообразном. Пост касается школьных и университетских текстов учебников: у «профессиональной» литературы своя специфика, своя аудитория. Решения у проблемы в текущих реалиях нет. При этом, часть «моих» наблюдений задолго до меня высказывали такие авторитеты, как Кнут и Хэмминг; чуть менее популярные ребята даже запилили инструкцию "Как читать математику".

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

Этим постом мы завершаем серию лекций с Data Fest. Одним из центральных событий конференции стал доклад Дмитрия Ветрова — профессора факультета компьютерных наук НИУ ВШЭ. Дмитрий входит в число самых известных в России специалистов по машинному обучению и, начиная с прошлого года, работает в Яндексе ведущим исследователем. В докладе он рассказывает об основах байесовского подхода и объясняет, какие преимущества дает этот подход при использовании нейронных сетей.


Под катом — расшифровка и часть слайдов.

Томас (имена вымышленные) был очень успешным и спокойным юристом, волновавшимся по поводу своего пристрастия к спиртному. Когда он попал ко мне на сеанс психотерапии, он потреблял 6-7 стаканов вина за вечер, и он уже начинал прятать эту привычку от домашних и чувствовать её влияние на свою работу. Мы обсудили стратегии лечения и назначили новую встречу. Но когда он вернулся через две недели, то был совершенно подавлен: с потреблением алкоголя ничего не изменилось.

«Я просто не могу себя ограничивать. Наверно, у меня нет силы воли».

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

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

• на личном уровне подталкивают к прокастинации;
• в стартапе по мере его успеха и роста приводят к потере прежней творческой «внутренней атмосферы» и нарастанию бюрократии;
• в больших компаниях приводят к «иерархическому регрессу».

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

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