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

Ставим задачу

Кого ищем? Ищем эффективных бойцов. Известно, что эффективность программистов со схожим опытом может отличаться в 10 раз (Ф. Брукс) или даже в 27 раз (Р. Гласс). Сразу, оговорюсь, эффективность это не только количество трупов врагов реализованных требований к ПО на единицу трудозатрат, но и умение результативно взаимодействовать с окружающими. Это важно, потому что по моим наблюдениям 50% проектных человеко-часов тратится на коммуникации. У нас это называется «синхронизация ментальных моделей».

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


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

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

На самом деле, у хрущёвок существует несколько десятков модификаций, но некая основа, сущность хрущёвки всё равно прослеживается.

В общем, недолго думая, я сел и написал генератор хрущёвок на C# под Unity3d. Под катом описание работы алгоритма и размышления на тему uv-карт, сабмешей и шейдеров.

Хочу рассмотреть интересную для меня тему создания пользовательского интерфейса. Вероятно, это будет серия статей.

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

Цель данной статьи: попытаться раскрыть понятие игры, а также её роли в творчестве. Понять, что отличает Игру от Искусства, Кино и Литературы?

Думаю стоит начать с определения того, что же такое таксономия. Таксономия согласно википедии — учение о принципах и практике классификации и систематизации.

Из всех подходов по выделению игрового сегмента продукта, наиболее интересным и простым для восприятия, на мой взгляд, является метод предложенный Крисом Кроуфордом. Крис Кроуфорд — геймдизайнер и писатель, отличившийся рядом отличных игр в 1980-х, основатель The Journal of Computer Game Design и организатор Конференции Разработчиков Компьютерных Игр.
В своей книге «Chris Crawford on game design», он определяет данный метод, как таксономию творческого самовыражения.

Рис.1 Таксономия творческого самовыражения по Кроуфорду

От переводчика: Это первая статья из цикла о Node.js от команды Mozilla Identity, которая занимается проектом Persona. Как клиентская, так и серверная часть Persona написаны на JavaScript. В ходе работы команда проекта создала несколько инструментов на все случаи жизни — от локализации до отладки, управления зависимостями и многого другого. В этой серии статей разработчики Mozilla делятся с сообществом своим опытом и этими инструментами, которые пригодятся любому, кто пишет высоконагруженный сервис на Node.js.

Первая статья цикла посвящена распространённой проблеме Node.js — утечкам памяти, особенностям утечек в высоконагруженных проектах и библиотеке node-memwatch, которая помогает найти и устранить такие утечки в Node.

Все статьи цикла:

1. "Охотимся за утечками памяти в Node.js"
2. "Нагружаем Node под завязку"
3. "Храним сессии на клиенте, чтобы упростить масштабирование приложения"
4. "Производительность фронтэнда. Часть 1 — конкатенация, компрессия, кэширование"
5. "Пишем сервер, который не падает под нагрузкой"
6. "Производительность фронтэнда. Часть 2 — кешируем динамический контент с помощью etagify"
7. "Приручаем конфигурации веб-приложений с помощью node-convict"
8. "Производительность фронтенда. Часть 3 — оптимизация шрифтов"
9. "Локализация приложений Node.js. Часть 1"
10. "Локализация приложений Node.js. Часть 2: инструментарий и процесс"
11. "Локализация приложений Node.js. Часть 3: локализация в действии"
12. "Awsbox — PaaS-инфраструктура для развёртывания приложений Node.js в облаке Amazon"

---

Зачем заморачиваться?

Вы можете спросить, зачем вообще отслеживать утечки памяти? Неужели нет более важных дел? Почему бы просто не перезапускать процесс время от времени, или просто добавить памяти на сервер? Есть три причины, по которым устранять утечки всё-таки важно:

1. Возможно, вы не сильно переживаете об утечках памяти, но этого нельзя сказать о V8 (движок JavaScript на котором работает Node). Чем больше памяти занято, тем активнее работает сборщик мусора, замедляя ваше приложение. Так что в Node утечки напрямую вредят производительности.
2. Утечки могут привести к другим проблемам. Протекающий код может блокировать ограниченные ресурсы. У вас могут закончиться файловые дескрипторы или вы вдруг не сможете открыть ещё одно соединение с БД. Такие проблемы могут возникнуть задолго до того, как кончится память, но обрушат ваше приложение ничуть не хуже.
3. Рано или поздно ваше приложение упадёт. И это наверняка случится во время наплыва посетителей. Вас все засмеют и будут писать про вас гадости на Hacker News.

Nikodemus' Common Lisp FAQ

---

Последнее обновление: 2012-04-13

Это очень неофициальное ЧаВО по языку Common Lisp, отражающее субъективное мнение Nikodemus Siivola. Этот текст частично основан на других ЧаВО, встречавшихся на просторах интернета и comp.lang.lisp.
Если вы думаете, что я воспользовался вашим текстом, буду рад признаться в этом, поэтому пишите на nikodemus@random-state.net.
Текущая версия этого ЧаВО доступна по следующим адресам:
http://random-state.net/files/nikodemus-cl-faq.txt
http://random-state.net/files/nikodemus-cl-faq.html
ЧаВО также периодически публикуется в comp.lang.lisp.

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

Немного о проекте

Собственно, делали мы интерактивную книгу одного популярного российского писателя. Книжка написана на JS, шаблонах ECT-JS и LESS. Сборкой, конкатенацией, минификацией и деплоем занимается Grunt, книжка работает на iPad’е под Phonegap.

Технически, мы делали прототип — мы активно изучали и применяли различные технологии. С чем-то получилось круто, с чем-то не очень. Как бы то ни было, книга работает, и ее даже можно скачать в App Store.

Думаю, что этого достаточно. Теперь можно перейти к GruntJS…

Сколько памяти занимает 1 миллион целых чисел?

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

Не нашёл на хабре — спешу поделиться. Восхитительное выступление Александра Соловьёва ingspree на конференции JavaScript Frameworks Day 2013. На видео ниже просто набор отрывков из него, желающим посмотреть полностью — сюда.

Денис Крючков (deniskin) рассказал Roem.ru о том, что он смог выкупить акции «Тематических медиа» у Mail.Ru Group и теперь сможет управлять компанией единолично. Мы думаем, что это одно из самых эпохальных событий в истории «Хабрахабра» и по такому случаю у Дениса стоит взять интервью



— Привет, позволь тебя поздравить. Как у тебя получилось выкупить долю Mail.ru в «Хабре»? Никто же не будет продавать курицу, несущую золотые яйца
— Спасибо! Да, конечно, для этого пришлось довольно долго искать деньги.

В последнее время все больше говорят про «NoSQL» — прямо «модный» тренд образовался. «Технологию» начинают активно использовать известные авторитетные компании, в т.ч. в высоконагруженных проектах с немалыми объемами данных — и кто-то восхищается, а кто-то обливает себя бензином и факелом выпрыгивает с 35 этажа с криком: "SQL ACID forever!"


Причем о каком бы продукте не говорили, будь то MongoDB или Cassandra — нередко приходится наблюдать прямо таки религиозную восторженность и трепет, как будто речь идет о чем-то новом и священном.

Предлагаю перейти на сторону зла, на темную сторону программирования. Ситхи сильнее джедаев. И печенек хватит на всех. Предупреждаю, прежде чем начнете читать далее. Характер при переходе на темную сторону портится.
Прошу под кат

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

«Node.js не подходит для серьезных сайтов и веб-приложений, а только для написания небольших API».
This is bull*hit. I have to say it.

От переводчика: недавно на coderwall.com появилась интересная статья от Ionut-Cristian Florescu об использовании Node.js для создания обычных («типовых») веб-проектов. До ее прочтения я был полностью согласен с заголовком статьи, но сейчас мое мнение несколько поменялось. Позиция автора может быть спорной во многих моментах, но его аргументы достаточно интересны. Если у вас есть собственное мнение по этому поводу, оставляйте его в комментариях.

Перевод статьи Smashing Magazine Creative And Innovative Navigation Designs.

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

Toybox

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

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

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

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

Но даже Программист грешен, если не соблюдает семь заповедей.

Не возомни паству пастырем

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

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

Введение

Firebug добавляет глобальную переменную с именем «console» к каждой веб-странице, загруженной в Firefox. Этот объект содержит много методов, которые возволят Вам писать на консоль Firebug и показывать информацию, проходящую через скрипты.

firebug.ru

К нашему счастью, не только firebug обладает данным функционалом:

• Chrome Javascript console — практически точный аналог
• Opera Dragonfly console — функционал реализован частично
• Firefox Web console — функционал реализован частично

Эта статья — мануал по Console API.
Примеры даны из Chrome 28.0.1500.72 m, Firebug 1.11.3, Firefox 22.0, Opera 12.15 (версия до ухода с presto)

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

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

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