Среди всей этой шумихи по поводу авторских прав есть один забавный пример — это крайний случай использования копирайта, который породила AT&T где-то в 1980-х. Речь идёт о программе /bin/true. Это пустая программа, которую обычно используют только для того, чтобы писать бесконечные циклы (while true do ...) в шелл-скриптах. Программа «true» не делает ничего, а только завершается с нулевым кодом. Такого поведения легко добиться — достаточно просто создать пустой файл и сделать его исполняемым, что и делали создатели первых Unix-систем. Пустой файл интерпретируется как шелл-скрипт, который не делает ровным счётом ничего. А, поскольку у него это вполне успешно получается, шелл возвращает нулевой код завершения. Но юристы AT&T решили, что это не помешает защитить копирайтом.

В оригинале название звучит как «How Not To Sort By Average Rating». Я подумал, что дословный перевод «Как не сортировать по усреднённому рейтингу» будет малопонятен и хуже отражает содержание статьи.

Постановка проблемы

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

Неправильное решение №1

Рейтинг= (Число положительных оценок) - (Число отрицательных оценок)

Автор оригинальной статьи — Майкл Эбраш, человек и пароход. Для тех, кому лень изучать википедию, отмечу, что это программист с более чем 30-летним стажем работы, который в свое время помог Кармаку сделать Quake, разработал GDI для Windows NT, приложил руку к созданию первых двух версий Xbox, а сейчас работает в R&D-отделе компании Valve.
В своей заметке он вспоминает, как зарождалась индустрия 3D-игр вообще и Valve в частности, рассказывает про свой опыт работы в различных корпорациях, приоткрывает завесу внутренней кухни Valve и ищет новых сотрудников. Статья большая, и я посчитал ее достаточно интересной для того, чтобы перевести на хабр.

---

Всё началось с Лавины*.

Если бы я не прочел её и не влюбился в идею Метавселенной, если бы она не заставила меня представить, насколько распределенная 3D сеть близка к воплощению в жизнь, если бы я не подумал я могу сделать это и, что более важно, я хочу сделать это, я бы никогда не встал на путь, который в конечном счете привел меня в Valve.

В 1994 году я уже несколько лет как работал на Microsoft. Однажды вечером, когда моя дочка рассматривала книги в магазине Little Professor в Sammamish Plateau, мне посчастливилось заметить Лавину на полке. Я взял книжку, прочитал первые страницы, решил купить и в итоге проглотил её за день. Параллельно я начал задумываться о том, что 80 процентов описанного в ней осуществимо прямо сейчас, и мне захотелось реализовать это сильнее, чем когда-либо вообще хотелось сделать что-то с компьютером — я всю жизнь читал научную фантастику, и вдруг мне выпал шанс превратить её в реальность. Так я попытался начать в Microsoft проект по созданию технологии сетевого 3D.

​12 апреля отмечается международный день полёта человека в космос. Более полувека прошло с того момента, когда Человечество сделало первый шаг в его освоение. Череда блестящих технических и научных побед сделала нас ближе к звёздам. Жажда открытий тянет постигать новые таинственные миры. Марс, красная «звезда» на небосводе, с древних времён притягивал к себе внимание людей. Невообразимо похожий на Землю, но всё-таки чужой мир до сих пор не покидает сознание многих исследователей. Вероятно в скором времени мы можем стать свидетелями тому, как на Марсе станут появляться небольшие исследовательские колонии людей. Инженерам предстоит столкнуться с многими проблемами. На Хабре присутствует большое количество специалистов разных областей, каждый обладает широким кругозором и определёнными знаниями. Предлагаю воспользоваться коллективным разумом и в этой статье поразмышлять о том, как бы выглядела связь на Марсе, если бы там существовали колонии людей.

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

Иллюстраций: 21, символов: 45 081.

Mosh — замена(или дополнение) SSH. Он быстрее и отзывчивее, особенно на линках с высокой задержкой, например, в мобильных сетях. Набираете символ, и моментально видите его на экране, так же, как и в локальном терминале. Почему? Потому, что в Mosh реализован так называемый local line editing, который не дожидается ответа от сервера, а сразу все отображает на экране. Работает даже в полноэкранных приложениях, вроде vim или emacs. И это далеко не единственный плюс!

Принято считать, что между пиратами и копирастами идёт война. Это очень похоже на правду. Но правда и то, что их противостояние подпитывает и укрепляет обе стороны. Разве пиратские партии в Европе смогли бы набрать сколько-нибудь значительное количество сторонников без громких юридических расправ, учинённых копирастами? Разве авторы продолжали бы довольствоваться крохами со стола корпораций и кабальными условиями эксклюзивных контрактов, если бы копирасты не были их единственной защитой от принудительного пиратского «коммунизма»?

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

Demain n'existe pas!

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

Специально ко Дню Защитника Отечества на препарационный стол легли LCD и E-Ink дисплеи, которые, так или иначе, достались мне в несколько побитом жизнью виде.

Как Антон кидал телефон об стену, а также о результатах скрупулёзного разбора дисплеев читайте под катом.

Эта картина сгенерирована программой Context Free по следующему описанию:

startshape T
// FLIGIZ
background{b -1}
tile {s 2.5}
rule T {3*{r 120 hue 30}S{x .3}}
rule S 3{CIRCLE{hue 30}4*{r 20 b.007 sat .1}S[s.3.7y.9]}
rule S {CIRCLE{hue 15}9*{r 20 b.05 hue -3}S[s.3.7y.9]}
rule S {S{flip 90}}

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

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

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

Введение

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

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

Если бы вы могли вернуться в прошлое, к самому началу своей карьеры разработчика и сказать самому себе: «прочитай именно эту книгу», в самой начале своей карьеры разработчика, какую бы книгу вы рекомендовали?

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

Однако в данном небольшом посте я возьму на себя смелость перечислить ТОП-5 тех самых книг, победивших в голосовании, переведенных на русский язык. И дать небольшие комментарии, ведь книги действительно этого достойны. Да, лично я бы поменял некоторые места, однако положимся на «мнение зала» ресурса Stack Overflow.

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

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

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

Карта

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

Прослушав вебинар «How Google Tests Software» я был так вдохновлен, что решил записать некоторые тезисы. Эта статья и есть мой конспект. Прежде всего, я должен внести ясность относительно ее содержания. Это не дословный перевод. Здесь описаны только те вещи, которые показались мне важными. Проще говоря, здесь описано не все, что прозвучало в вебинаре. Так же существует вероятность, что я понял что-то не до конца или даже понял неправильно. Поэтому горячо рекомендую прослушать вебинар самостоятельно.
Его ведет Джэймс Витакер, который в данный момент занимает пост технического директора по тестированию ПО в Google. Джэймс совместно с коллегами готовится выпустить одноименную книгу. В ней можно будет получить исчерпывающую информацию о том, как проводят тестирование GoogleMaps, Google+, ChromeOS, Android и т.д…

Является преждевременная оптимизация дорогой в ад? Или подход «потом исправим» превращает программистов из «специалистов» в презираемую всеми «школоту»?

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

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

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

Теперь давайте посмотрим, как поступит в этом случае типичный джуниор. Есть задача – её надо решить. Их так учили в университетах. Многие из них ещё находятся под влиянием маргинального лозунга «пиши код, б##дь!». Итак, он наливает себе растворимого кофе, надевает наушники с чем-нибудь пожёстче и погромче и уходит в поток на пару-тройку часов.

Всё бы ничего. Я ничего не имею против кофе, наушников или состояния потока. Более того, обычно это наиболее эффективный и, зачастую, единственный способ писать хороший код. Но мы рассматриваем типичный случай молодого и неопытного программиста, поэтому давайте посмотрим на результаты.

Посмотрите на рисунок. Вот так конфигурируется классический NAT на маршрутизаторе Cisco, допустим там больше ничего не сконфигурировано. А теперь ответьте сами себе на вопрос. Может ли при определенных условиях кто-либо обратиться извне на RDP порт (TCP 3389) супер секретного сервера 192.168.0.250 и попытаться подобать пароль к нему. Уточним, что сервер стоит одиноко в сети и никуда сам не обращается (имеется в виду, что на нем нет никаких троянов, автоматических обновлений и прочих прелестей).

Считаете — нет? Вспомним анекдот.

Лекция по филологии. Старый профессор рассказывает:

— В некоторых языках мира двойное отрицание означает согласие. В других, двойное отрицание так и остается отрицанием. Но, нет ни одного языка в мире, в котором двойное согласие означает отрицание. Голос с задней парты:

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

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