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

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

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

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

Механические клавиатуры. Путеводитель.

Перевод статьи Джейсона Фридмана (Jason Freedman) "Everyone Sucks at Interviewing. Everyone." Оригинал статьи можно прочитать здесь.

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

Последние несколько лет я с большим интересом изучаю все, что связано с отбором и наймом сотрудников. Найти хорошего специалиста безумно сложно, и я вряд ли смогу назвать много фирм, у которых это хорошо получается. Даже у самых успешных в этом отношении компаний есть страшный секрет, заключающийся в следующем: как бы хорошо ни был организован процесс отбора, он все равно не может гарантировать, что нанятый сотрудник преуспеет на новом месте. Ходят слухи, что даже сложнейшие системы оценки кандидатов, применяемые HR-отделом Google, не в состоянии точно предсказать эффективность будущего сотрудника. Некоторые компании отмечают, что единственный показатель, который хоть как-то корреллирует с успешностью молодых разработчиков, — это их результаты в тесте SAT (американский аналог ЕГЭ).

Отгадайте загадку: в четырёх измерениях сидит и комплексными числами воротит?

Подсказка: это вектор со скаляром. И вещественная матрица. И придумал его Гамильтон.

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

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

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

Для начала, что есть «правильная настройка». Если вы хотя бы раз были в магазине электроники, то наверняка замечали, что все выставленные телевизоры показывают по-разному. С чем это связано? Какой из них лучше? Давайте разберемся.

Я думаю, вы согласитесь, что телевизор должен не просто показывать какую-то картинку, но и вносить как можно меньше искажений в исходный контент. Сам контент всегда создается с оглядкой на стандарты и рекомендации индустрии, и главная цель любого телевизора — донести до вас именно то изображение, которое вам хотели показать. Тут важно всё: и оттенок кожи у актера, и цвет неба на закате, и какие детали изображения должны быть видны, а какие спрятаны. Существуют международные стандарты, описывающие каким должно быть изображение на экране вашего телевизора. Все вы, наверняка, встречали аббревиатуры PAL, NTSC, или HDTV, вот за этими буквами и скрываются свойства видеосигнала и различные параметры изображения. С приходом HDTV в нашу жизнь, большая часть стандартов сразу же устарела, и, фактически, наиболее актуальным сейчас является стандарт REC709, который используется в телевидении высокой четкости (HD) и в Blu-Ray видео.

2012 год, сайт css-tricks.com:


versus:

1992 год, стандартный элемент интерфейса OS/2:



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

Современная web-технология, основанная на CSS/HTML (включая даже HTML5/CSS3) – это апофеоз бессистемности в архитектуре и фрагментации. Бессистемность в начальном дизайне и последующее наложение на нее фрагментации из-за несовместимых реализаций в браузерах породили каскады хаков для латания дыр. Эти хаки (типа CSS 2.x) сами по себе уже более системные, но их разработчики связаны тем полем (HTML/CSS 1.x), на котором приходится играть. Поэтому новые версии CSS мало что решают, к тому же не полностью поддержаны в реальных браузерах.

Открыв любой серьезный CSS-файл, например, написанный в Google или FB, увидишь в нем отрицательные границы элементов, relative позиционирование через сдвиги в пикселах, огромные длины, усекаемые затем с помощью overflow: none, использование свойства content и прочие извращения. Это семантически бессмысленные и нечитаемые другими программистами конструкции. Но без подобных вещей невозможно сверстать современный веб-два-нольный сайт. Или, например, ни в одной спецификации CSS не написано, что картинка из тега <IMG>, идущая вслед за <OL> с маркером-изображением, может вклиниться визуально между маркером и текстом пунктов списка (в некоторых браузерах и при некоторых вариантах верстки).

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

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


Изображение отрендерено с помощью Maxwell Render.

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

Demain n'existe pas!

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

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

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

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

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

Почему это глупо

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



Это скриншот из презентации «Beyond the mobile web by yiibu» (очень рекомендую).

Во-вторых, если вы не facebook или yandex, скорее всего, вы не потянете создание и поддержку разных версий сайта для каждого устройства. Да и это не имеет особого смысла. Потому что ситуация становится похожа на реалии пятнадцатилетней давности. Тогда делали сайт «под браузер», а сейчас автор предлагает делать сайт «под устройство».

Как сделать один сайт для всех устройств

Идея этой заметки навеяна статьей Александра Бындю “Дополнение к LSP” и может рассматриваться, как развернутый комментарий к статье Александра.

Итак, вопрос следующий, предположим, один из членов команды пытается реализовать интерфейс IListofT в классе DoubleListofT таким образом, чтобы при добавлении элемента с помощью метода Add, добавлялся бы не один, а два одинаковых элемента. Поскольку класс ListofT всегда добавляет только один элемент, то можно считать, что данное поведение нарушает принцип замещения Лисков (LSP – Liskov Substitution Principle).

Теперь давайте рассмотрим, так ли это, если речь идет о платформе .NET, ну и вообще поговорим о том, можем ли мы утверждать, что метод нарушает принцип замещения Лисков при отсутствии формальной спецификации того, что этот метод должен делать.

Перевод статьи из блога Джефа Этвуда, одного из основателей Stack Exchange Network, сети вебсайтов, посвященных работе с вопросами и ответами в различных областях. Среди прочих вебсайтов этой сети стоит выделить Stack Overflow — самый первый вебсайт, созданный в рамках Stack Exchange Network и посвященный вопросам и ответам в области программирования. Отдельная благодарность karaboz за помощь и вдохновение.

---

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

Когда люди спрашивают меня о самой большой ошибке, которую я совершил в процессе создания Stack Overflow (Прим. переводчика — далее SO) я рад, что не надо выдумывать и говорить банальности. Я могу честно и открыто рассказать об огромной, нелепой и, до смешного, дурацкой ошибке, которую совершил в самом начале разработки SO. Что ещё хуже, я могу рассказать о такой ошибке, которую продолжал совершать потом ещё и на протяжении девяти месяцев на фоне продолжающихся протестов сообщества.

Введение

Обычно, при оптимизации программы для многоядерных компьютеров первым шагом является выяснение возможности разделения алгоритма на части, выполняющиеся параллельно. Если для решения задачи необходимо параллельно обрабатывать отдельные элементы из большого набора данных, то первыми кандидатами станут новые возможности параллельности в .NET Framework 4: Parallel.ForEach и Parallel LINQ (PLINQ)

Parallel.ForEach

Класс Parallel содержит метод ForEach, представляющий собой многопоточную версию обычного цикла foreach в C#. Подобно обычному foreach, Parallel.ForEach выполняет итерации над перечислимыми данными (enumerable), но с использованием множества потоков. Одна из более часто используемых перегрузок Parallel.ForEach выглядит следующим образом:

public static ParallelLoopResult ForEach<TSource>(
			 IEnumerable<TSource> source,
			 Action<TSource> body)

Ienumerable указывает на последовательность, по которой нужно выполнить итерации, а Action body задает делегат, вызываемый для каждого элемента. Полный список перегрузок Parallel.ForEach можно найти здесь.

PLINQ

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

Выполнение независимых операций

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

Изначально пост планировалось посвятить ошибке 64х-битового компилятора xlc которую я безуспешно отлавливал многие часы и которая имеет место быть на серверах фирмы IBM архитектуры AIX. Но так уж получилось, что подобная ошибка затрагивает многие компиляторы, не стал исключением и Visual Studio 2010 с установленным пакетом обновления SP1. Что в итоге кажется забавным, так как наводит на мысли, что специалисты Microsoft сотрудничают с разработчиками из IBM в деле создания оптимизирующих компиляторов.

Немного предыстории. Есть один научный проект, который был написан на С++ достаточно давно и сейчас успешно переносится на многие платформы, среди которых можно отметить мейнфреймы HP-UX, IBM AIX, Oracle Solaris. Перенос по большому счету состоит в том, что исправляются ошибки времени компиляции, запускается группа тестов и если все тесты проходят, то делается вывод о работоспособности кода.

Так как скорость выполнения математических процедур очень даже важна, компиляция проходит с включенным ключом оптимизации по скорости -O2. Но на архитектуре IBM AIX компилятор xlc почему-то не может создать работоспособный код, удовлетворяющий набору тестов. В то же время без ключа -O2 все работает нормально.

Я бы, конечно, мог попробовать отловить эту ошибку непосредственно на мейнфрейме IBM AIX, будь у меня в запасе достаточно времени, но за отсутствием отладчика (в debug mode ошибка не проявлялась) ловить приходилось по-старинке, методом вставки printf в участки кода. Удаленный доступ к IBM AIX мне так и не дали, приходилось работать непосредственно в дата-центре и за те несколько часов, проведенных за терминалом, ничего внятного понять не удалось, кроме того, что ошибка имеет место быть и достаточно устойчивая. В итоге, ошибка так и сидела в коде на протяжении долгого времени.

Так продолжалось до тех пор, пока я не попробовал перенести код на Visual Studio 2010 SP1.

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

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

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

Предисловие

В последнее время был поднят ажиотаж вокруг светодиодных ламп, которые должны заменить собой обычные лампы Ильича. И как поведал главный нанотехнолог России, такие лампы скоро поступят в продажу в Москве и Санкт-Петербурге. Конечно, всё было обставлено с пафосом: первым оценил новинку В.В.Путин. Мне удалось достать лампочку от «Оптогана» одним из первых, к тому же в руках у меня оказались ещё одна лампочка российского производства («СветаLED» или «SvetaLED»), правда побитая жизнью, но рабочая, и китайский NoName, которую с лёгкостью можно купить на ebay или dealextreme.com.