Джон Кармак о науке и искусстве разработки ПО

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

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

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

От автора транскрипции, Эндрю Ко

Я не особо увлекаюсь компьютерными играми, но, тем не менее, обязан им моим увлечением программированием (оно начиналось с алгоритмов отрисовки). Поэтому, когда я увидел в своей ленте выступление Джона Кармака на QuakeCon 2012, я подумал, что надо бы его послушать. Вдруг узнаю чего нового о создании компьютерных игр?

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

Ниже — моя транскрипция этого выступления. Заранее прошу прощения за ошибки.

Читать

Интервью с Чарльзом Уэзереллом

Сегодня у меня в гостях Чарльз Уэзерелл, автор книги «Этюды для программистов», изданной в 1978 году. До сих пор эта книга остается отличным источником интересных реальных задач из разных областей информатики для студентов, изучающих программирование. Сейчас Чарльз работает в компании Оракл, и любезно согласился рассказать немного о себе и о книге.

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


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


«Этюды» не похожи на другие учебники по программированию. В них есть задачи из наиболее важных областей, и преподнесены они весьма нетрадиционным образом. Как родилась идея собрать реалистичные задачи и обыграть их в виде законченных игровых ситуаций? Можете рассказать вкратце как родились «Этюды»?

С 1974 по 1979 я преподавал в университете UC Davis. Там была новая группа выпускников по специальности «Информатика», призванных составить учебную программу по этому предмету, но в реальности это была просто группа людей из разных факультетов. Департамент прикладных наук нанял меня как первого профессора по этой специальности для создания учебной программы. Вместе с небольшой группой других профессоров и преподавателей мы создали новый учебный план с учетом требований по специальности и начали преподавать новые и переработанные курсы.

Работая над учебной программой, мы сошлись во мнении, что студентам стоит иметь опыт работы над реальными задачами в дополнение к теоретическим знаниям. Но под «реальными» задачами я не имею в виду коммерческие или прикладные задачи, так как я убежден, что такие знания очень быстро устаревают. Вместо этого я хотел дать студентам задачи, в которых надо было понять требования и поработать над спецификациями. Кроме этого, необходимо было научить студентов работать в группе. Например, задача по созданию компилятора давалась группе студентов из 2-3 человек, и оценка ставилась всей группе. Также надо было описать, как они поделили работу, и был ли выбор удачным.

Через некоторое время мы решили начать курс программирования проектов, чтобы закрепить знания студентов по созданию законченных приложений. Я сформулировал несколько проектов, которые мы придумали. Но, когда потребовались еще идеи, вокруг были только книги с примитивными задачами, например, распечатать таблицу истинности булевых функций и пару задач, используемых в университете Карнеги-Меллон. Так, сам того не замечая, я уже писал «Этюды». Так вышло, что я ушел из университета UC Davis практически сразу после публикации книги и точно не знаю, продолжили ли они использовать книгу в курсе по проектам.
Читать

Wi-Fi: неочевидные нюансы (на примере домашней сети)

Сейчас многие покупают точки доступа 802.11n, но хороших скоростей достичь удается не всем. В этом посте поговорим о не очень очевидных мелких нюансах, которые могут ощутимо улучшить (или ухудшить) работу Wi-Fi. Всё описанное ниже применимо как к домашним Wi-Fi-роутерам со стандартными и продвинутыми (DD-WRT & Co.) прошивками, так и к корпоративным железкам и сетям. Поэтому, в качестве примера возьмем «домашнюю» тему, как более родную и близкую к телу. Ибо даже самые администые из админов и инженеристые из инженеров живут в многоквартирных домах (или поселках с достаточной плотностью соседей), и всем хочется быстрого и надежного Wi-Fi.
[!!]: после замечаний касательно публикации первой части привожу текст целиком. Если вы читали первую часть — продолжайте отсюда.

Несколько примечаний перед началом:

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

Читать

Протокол GRE

GRE (Generic Routing Encapsulation) — протокол туннелирования сетевых пакетов, разработанный фирмой Cisco. Протокол GRE обеспечивает механизм инкапсуляции произвольных пакетов в произвольный транспортный протокол. В наиболее общем случае система имеет пакеты, которые нужно инкапсулировать и маршрутизировать (информационные пакеты). Информация (payload) сначала инкапсулируется в пакет GRE, который может также содержать маршрут.

1

Полученный в результате пакет GRE инкапсулируется в пакет другого протокола (протокол доставки). В данной статье мы рассмотрим форматы пакетов проткола GRE.
Читать

Всеобщая айтишная обязанность

Вова проснулся от громкого крика: «Команда, подъём!» За три месяца этот мерзкий голос старшего (или, как его правильно называть, тимлида) Вове уже опротивел. Ему опротивела эта комната, ему опротивел старый компьютер, которым ему разрешали пользоваться, ему вообще опротивели все компьютеры и информационные технологии. Он уже много раз проклял того, кто всё это придумал. Всю жизнь Вова хотел быть учителем и работать с детьми.

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

Конечно, Вове всё это не нравилось, но у него не было выбора. В 2040 году с развитием информационных систем дефицит IT-специалистов стал катастрофическим, и правительство приняло закон «Об обязательной IT-специальности». Согласно этому закону, каждый человек мужского пола был обязан отработать год айтишником. Место работы выбрать было нельзя. Вся работа велась под жёстким контролем сверху. Естественно, никто никого не спрашивал, хочет ли парень работать в IT, есть ли у него к этому способности. Понятно, что из людей, которые не хотят или не могут работать в IT, специалисты получались не слишком хорошие, потому к серьёзной работе допускали мало кого из «обязанных», заставляя их в основном заниматься бессмысленным и бесполезным ручным трудом.

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

Вова тяжело вздохнул и начал подниматься. «Надо было давно уехать из этой страны», — думал он.

отсюда: http://ithappens.ru/story/9714

Настройка сети в OpenWRT

В этой статье я расскажу о том как настроить сеть в OpenWRT. В частности расскажу о том как сделать несколько SSID на одной радиокарте, настроить WPA2-Enterprise, поднять VLAN и как настроить программный свитча(swconfig).

UCI

Все настройки будем проводить через консоль так как она не ограничена в возможностях в отличии от веб интерфейса. Для настроек системы в OpenWRT используется подсистема UCI(Unified Configuration Interface), которая позволяет централизовано настраивать всевозможные сервисы начиная с сервиса монтирования файловых систем и заканчивая сервисом QoS. Все настройки UCI находятся в директории «/etc/config/» и имеют одинаковый синтаксис. Для управления системой UCI используется программа uci. С помощью неё можно редактировать конфигурационные файлы, просматривать текущие настройки и прочее. uci очень удобно использовать для конфигурирования системы из скриптов. Так-же есть возможность писать расширения для uci. Синтаксис конфигурационных файлов такой:

config 'example' 'test'
        option   'string'      'some value'
        option   'boolean'     '1'
        list     'collection'  'first item'
        list     'collection'  'second item'

config ‘example’ ‘test’ — начало секции, example — тип по которому uci поймет как трактовать опции в этой секции, test — идентификатор секции. option или list определяет тип настроек, list — составные настройки(например список интерфейс для прослушивания apache’ем). string, boolean, collection — названия переменных.
Читать

Microsoft предлагает Google пойти на мировую

Сегодня компания Microsoft в лице Брэда Смита и Орацио Гутьереза опубликовала пресс-релиз или даже скорее открытое письмо с обращением к Интернет-гиганту Google. Редмондская корпорация предлагает Google сесть за стол переговоров и подписать мирное соглашение, которое по мнению Microsoft решит разногласия гигантов в отношении свободной операционной системы Android, разрабатываемой компанией Google в партнёрстве с консорциумом Open Handset Alliance.

Данный топик представляет обзор рядового наблюдателя происходящих событий с акцентом на противостояние Microsoft и Motorola Mobility/Google (текст большой, много ссылок и конкретных патентов). Если есть какие-то замечания и дополнения, то пишите их в комментариях или на хабрапочту.

Читать

Самый большой FAQ по SSH

abstract: В статье описаны продвинутые функций OpenSSH, которые позволяют сильно упростить жизнь системным администраторам и программистам, которые не боятся шелла. В отличие от большинства руководств, которые кроме ключей и -L/D/R опций ничего не описывают, я попытался собрать все интересные фичи и удобства, которые с собой несёт ssh.

Предупреждение: пост очень объёмный, но для удобства использования я решил не резать его на части.

Оглавление:

  • управление ключами
  • копирование файлов через ssh
  • Проброс потоков ввода/вывода
  • Монтирование удалённой FS через ssh
  • Удалённое исполнение кода
  • Алиасы и опции для подключений в .ssh/config
  • Опции по-умолчанию
  • Проброс X-сервера
  • ssh в качестве socks-proxy
  • Проброс портов — прямой и обратный
  • Реверс-сокс-прокси
  • туннелирование L2/L3 трафика
  • Проброс агента авторизации
  • Туннелирование ssh через ssh сквозь недоверенный сервер (с большой вероятностью вы этого не знаете)


Читать

Оборудование и Linux. Новая страница: sysfs

Владимир Попов

Версия 2007.02.19, posix.ru
Впервые опубликовано: LinuxFormat, 2006, 77

20 Февраль 2007 г

Вместо предисловия

Вам никогда не казалось парадоксальным, что Linux, который используется в мобильных телефонах и на суперкомпьютерах, пользователи IBM PC часто упрекают в том, что он «плохо поддерживает оборудование»? Не будем вспоминать, что для MicroSoft (а ведь именно с Windows сравнивают Linux на персональных компьютерах) львиную долю работы по поддержке оборудования выполняют производители этого самого оборудования, просто попытаемся проанализировать, есть ли реальные основания для таких упрёков.

Настоящая статья представляет собой попытку «защиты» Linux, опирающуюся на информацию о новой драйверной модели, ставшей частью ядра версии 2.6.

Читать

Еще раз про udev

Алексей Федорчук

http://alv.me/

17 Июнь 2009 г

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

Udev — это механизм поддержки настраиваемого динамического именования устройств в Linux, пришедшая на смену виртуальной файловой системе устройств devfs; во FreeBSD эта функция возлагается на последнюю. Первый и основной разработчик udev — Грег Кроа-Хартман (Greg Kroah-Hartman).

Читать