^{Длинный материал. Время чтения – около 40 минут.}



Доктор Ричард Хэмминг, профессор морской школы Монтерея в штате Калифорния и отставной учёный Bell Labs, прочёл 7 марта 1986 года очень интересную и стимулирующую лекцию «Вы и ваши исследования» переполненной аудитории примерно из 200 сотрудников и гостей Bellcore на семинаре в серии коллоквиумов в Bell Communications Research. Эта лекция описывает наблюдения Хэмминга в части вопроса «Почему так мало учёных делают значительный вклад в науку и так многие оказываются в долгосрочной перспективе забыты?». В течение своей более чем сорокалетней карьеры, тридцать лет которой прошли в Bell Laboratories, он сделал ряд прямых наблюдений, задавал учёным очень острые вопросы о том, что, как, откуда, почему они делали и что они делали, изучал жизни великих учёных и великие достижения, и вёл интроспекцию и изучал теории креативности. Эта лекция о том, что он узнал о свойствах отдельных учёных, их способностях, чертах, привычках работы, мироощущении и философии.

Этот пост в основном о веб-аналитике: о том, как корректно определять источники посетителей вашего сайта, и о моём модуле для Ruby on Rails, который помогает в этом нелёгком деле. В конце есть небольшая часть, на которую я попрошу обратить внимание участников Rails сообщества: она обо мне и Rails. Но давайте по порядку.

По работе я пишу тексты: посты на хабр, email-рассылку, статьи в СМИ. Пишу уже пару лет, последние полгода не меньше двух текстов в неделю. Значительным шагом в развитии моего навыка письма было открытие для себя информационного стиля и советов Максима Ильяхова.

Цель текста в информационном стиле — донести информацию до читателя. Информационный стиль: лаконичный, однозначный, точный и объективный. В информационных текстах нет лишних слов, эмоций, личного мнения. Они читаются легко и быстро.

Максим вводит понятие стоп-слов. Стоп-слова не характерны для текстов в информационном стиле и если вы встретили его — задумайтесь и перефразируйте это место. Стоп-слова это «кстати», междометия, модальные глаголы, отглагольные существительные и другие, всего около 100.

В какой-то момент мне стало сложно искать эти слова в текстах, поэтому я создал себе в помощь Test The Text. Test The Text выделяет в тексте слова нехарактерные для информационного стиля и объясняет почему.

Привет!
Прошлые два обзора полезных книг за 2010 и 2011 год собрали просто адовое количество закладок, поэтому я продолжу. Прошел ещё год, ещё около 250 прочитанных книг – и вот самые интересные под катом.

Кто сказал, что слоны не умеют танцевать? Возрождение корпорации IBM: взгляд изнутри (Герстнер Луис)

Отличная книга про то, как удалось восстановить IBM. То, что со стороны выглядело как бессистемное перемещение активов и последовательность приказов без особого смысла, через несколько лет начало складываться в единую систему.

Догнать зайца (Стивен Спир)

Отличная книга про дебаг производственных процессов. Одна из основных вещей – то, что все серьёзные проблемы возникают из-за сочетания некритичных багов. Есть примеры из американской ядерной программы, NASA и т.п. Я предлагаю прямо сейчас пойти и прочитать описание железнодорожного крушения на Каменской: один не отчитался, второй не проверил тормоза, третий зажал тангенту, четвёртый сорвал стоп-кран. Результат — катастрофа.

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

На самые популярные и важные вопросы дизайнер нового интерфейса Анна Котляревская ответила в интервью:



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

Как и обещал, пишу продолжение статьи, посвященной обучению на курсе Algorithms.

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

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

Итак, представим себе, что есть два программиста. Один из них умный, прочёл кучу статей на Хабре, знает каталог GoF наизусть, а Фаулера — в лицо. Другой же делает всё просто. Первого будут звать, например, Борис Н., а второго — Маркус П. Само собой, имена вымышленные, и все совпадения с реальными людьми и программистами случайны.

Итак, к ним обоим приходит проектный менеджер (если в вашей вселенной PM не ходит сам к программистам, назовите его как-то иначе, например BA или lead, сути это не изменит) и говорит:
— Ребята, нам нужно, чтобы делался хлеб.

Именно так, «делался», без уточнения способа производства.

Как же поступят наши программисты?

Неприятности случаются… Неожиданно плохой фидбек, проблемы с заказчиком или коллегами, не повысили зарплату, странные баги, внезапный овертайм или закрытие проекта — подобные события запускают цепочку реактивных реакций:

• Нет, тут есть ошибка -> сами гады -> а может все не так и плохо -> ппц -> ладно, давай выкручиваться

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

• Как узнать каждое состояние и предугадать следующее?
• Как помочь выйти себе и собеседнику из цепочки?
• Что не делать, чтобы не усугубить ситуацию?

Этой весной, Питер Тиль (Peter Thiel), один из основателей PayPal и первый инвестор FaceBook, провел курс в Стенфорде — «Стартап». Перед началом Тиль заявил: «Если я сделаю свою работу правильно, это будет последний предмет, который вам придется изучать».

Один из студентов лекции записывал и выложил транскипт. В данном хабратопике я делаю перевод первого занятия. Если пост покажется стоящим — продолжу переводить и выкладывать.

Конспект лекций — Питер Тиль (курс: CS183) Стартап — Стэнфорд, весна 2012 г.

Занятие 1: Вызов будущего
Занятие 2: Снова как в 1999?
Занятие 3: Системы ценностей
Занятие 4: Преимущество последнего хода
Занятие 5: Механика мафии
Занятие 6: Закон Тиля
Занятие 7: Следуйте за деньгами
Занятие 8: Презентация идеи (питч)
Занятие 9: Все готово, а придут ли они?
Занятие 10: После Web 2.0
Занятие 11: Секреты
Занятие 12: Война и мир
Занятие 13: Вы — не лотерейный билет
Занятие 14: Экология как мировоззрение
Занятие 15: Назад в будущее
Занятие 16: Разбираясь в себе
Занятие 17: Глубокие мысли
Занятие 18: Основатель — жертва или бог
Занятие 19: Стагнация или сингулярность?

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

Прочтение этой статьи: 15 минут
Осмысление методики: 10 минут
Ощутимые результаты: 30 минут

После недавнего выпуска Retina MacBook Pro и The new IPad, экраны с увеличенной плотностью пикселей начали активно входить в нашу жизнь. Что это значит для веб-разработчиков?

Для начала разберемся в терминологии.

Физические пиксели

Последнее время я очень часто натыкаюсь на перепост статьи о том, как плохо людям работать в больших компаниях. Стоит кому-то запостить эту ерунду, как тут же набегает толпа недовольных хомячков и начинает вопить о том, что всё это правда и большие компании отнимают у них лучшие годы жизни, не давая ничего взамен. Всякий раз, когда я это вижу, у меня в голове возникает одна простая как тапок мысль: «Найди другую работу, тудыть тебя через коромысло!» Если я имею неосторожность озвучить эту мысль, мне обычно возражают, что все компании одинаковы, всё плохо, и вообще, 4 мая 1925 года Земля налетит на небесную ось.
Что ж, позвольте представить вам несколько иной взгляд на вещи. Мне 25 лет, и я работаю рядовым инженером-программистом в крупной компании, название которой не разглашается в интересах следствия. В этой небольшой статье я пройдусь горячим утюгом сатиры по каждому из пунктов оригинальной статьи, и объясню, почему это полный буллшит. Большинство примеров будет являться описанием реальной обстановки в нашей компании.

Одна из постоянных проблем верстальщиков адаптивных сайтов — это задача удобно представить обычные таблицы на мобильных устройствах. Вот как выглядят такие таблицы чаще всего:


Не очень удобно, правда? К счастью уже существует несколько хитрых способов решить такую проблему.

«Год или два, с момента начала работы в Bell Labs, я работал в паре с Кеном Томпсоном над интерактивным графическим языком, разработанным Джерардом Хольцманом (Gerard Holzmann). Я печатал быстрее, поэтому я сидел за клавиатурой, а Кен стоял позади меня. Мы работали быстро, и когда компилятор выдавал ошибку, я рефлективно начинал закапываться в проблему, изучая стек вызовов, вывод программы, запускал отладчик и так далее. Но Кен просто стоял рядом и думал, игнорируя меня и код, который мы только что написали. Вскоре я заметил закономерность: Кен зачастую понимал, в чем проблема, раньше меня и произносил: „Я знаю, что не так“. Обычно он был прав. Я понял, что Кен выстраивал ментальную модель кода и, когда что-то ломалось, это была ошибка в модели. И думая о том, как эта проблема могла возникнуть, он выяснял, в каком месте модель была неверна или где наш код мог неправильно эту модель отразить.

Порядка 600 операторов в 4 странах, обрабатывающих звонки клиентов на американские (и немного на российские) номера.
Примерно 200 одновременных разговоров в пиковое время.
Примерно 15 000 звонков в день.
Возможность за несколько минут масштабировать это решение в несколько раз (по нашим прикидкам до ~1000 параллельных звонков, прежде чем начнутся проблемы).

Ну и конечно же, плотная интеграция с внутренними системами (CRM, сопровождение покупок, приоритеты операторов и клиентов и много-много других плюшек).

Кому интересно как это это работает и почему именно так — добро пожаловать