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


А ты записался добровольцем прошел собеседование?

Интервью состоит из трех частей, занимает 30-60 минут.
1. Рассказ программиста о себе.
2. Короткие вопросы на кругозор.
3. Решение задач

Рассказ программиста о себе.

В первую очередь прошу человек рассказать, как пришел к web-программированию. Когда начал, когда подсел на программирование :)
Очень спрашиваю про последнее место-два работы, что человек делал, за что отвечал, что в техническом и организационном плане там делал.

Нужно, чтобы человек расслабился.
Когда-то на этом этапе спрашивал про пять вариантов, почему люки круглые и прочие вопросы, но это давно отмерло, потому что не дает ничего :)

Как только становится понятно, что движет человеком и какой у него опыт, переходим к технической части.

Статье 14 лет. Но, что удивительно, перевода этой классики на Хабре нет. Значит, будет.

Итак, вы называете себя «проектировщиком интерфейсов»? Если не сможете на все вопросы ответить быстро и обоснованно — вон из профессии!

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

А если вы не знаете, что такое «закон Фиттса», просто пройдите тест, не подсматривая в ответы. Это прояснит, какими стереотипами вы руководствовались. В ответах — подробный разбор задействованных принципов, и вы можете сравнить свои стереотипы с моими ответами. И не пугайтесь плохих результатов: большинство людей, даже давно знакомых с компьютерами, в первый раз проходит тест очень плохо. Зато во второй раз ответы получаются правильные, и большинство считает эту статью самой ценной на моём сайте: одно её прочтение улучшит все интерфейсы, спроектированные в дальнейшем.

Эти вопросы предполагают, что всё экранное пространство под вашим полным контролем. Просто представьте себе, что вы главный дизайнер в Microsoft или Apple.

На сайте немало постов о том, какие условия нужно включать в договор на создание сайтов и программ (краткий список ниже), но нет договора в формате, который можно взять за основу для составления своего договора. Мы изучили условия из постов (спасибо авторам), подумали над ними, переработали и учли в предлагаемой на ваш суд форме договора. Так что договор пока можно считать частично «захабренным».

Некоторое время назад мне довелось организовывать новую группу разработки, которая должна была заняться развитием OLAP и BI продуктов в дружеской софтверной компании. А так как группа была собрана из свежих выпускников ВУЗов, то мне пришлось написать «краткий курс молодого бойца» для того чтобы максимально доступно дать начальные понятия об OLAP людям, которые ни разу с ним не сталкивались, но уже имели опыт программирования и работы с БД.

Выкладываю теперь это Введение в Общественное Достояние.

В статье несколько смешиваются понятия OLAP, Business Intelligence, и Data Warehouse, но и в жизни часто сложно понять, где проходит граница. А уж в реальных проектах, так и подавно, все они ходят рядом. Поэтому прошу не судить строго.

От переводчика

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

Снова прошу прощения за отсутствие перевода словосочетания “computer science”.

Кратко

• Боритесь за закон Парето, следите за тем, чтобы 20% вашего труда давало вам 80% результата;
• Расставляйте приоритеты, ведь минимализм нужен для того, чтобы делать то, что нужно, а не распыляться по мелочам;
• Лучшее — враг хорошего: сначала просто сделайте, потом сделайте правильно, потом сделайте лучше;
• Убивайте в зародыше, не бойтесь начать всё сначала. Чем быстрее ошибётесь, тем быстрее научитесь;
• Повышайте свою ценность. Постоянно думайте о том, чем можно помочь команде, — и развивайтесь в этом направлении;
• Сперва основы. Мыслите последовательно, ориентируясь на лучшие практики мира Computer Science;
• Посмотрите с разных сторон. Простое получается тяжелее, чем сложное, поэтому включайте воображение;
• Синтаксис — основа взаимодействия. Мы пишем код для людей, а не для машин;
• Не запутывайте. Старайтесь проектировать слоями, по мере возможности не зависящими друг от друга;
• Вычищайте оставленное-на-всякий-случай. Минимализм борется с отвлекающим от основного.

За последнее время я несколько раз успел поучаствовать в дискуссиях о том, чем Angular лучше или хуже Knockout и других JS-фреймворков. И очень часто я сталкивался с тем, что есть некоторое непонимание сути различий в подходах, заложенных в эти продукты. Иногда дело доходило даже до того, что в качестве преимущества Knockout приводились валидные по умолчанию префиксы «data-», что ну просто совсем смешно (не говоря уж о том, что их можно использовать и в Angular).

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

1. Модульная организация кода, тестируемость и жестокая война с любыми глобальными данными.
2. Пропаганда декларативного подхода через создание собственных HTML-директив.
3. Механизм проверки изменения данных в дата-биндинге без использования коллбэков.

И третий пункт мне здесь видится наиболее сложным для понимания. Поговорим именно о нем.

Кто-то вчера шутил, а кто-то занимался реально полезными вещами. Как например болгарский разработчик Мартин Ангелов, опубликовавший впечатляющий обзор JS библиотек:
http://tutorialzine.com/2013/04/50-amazing-jquery-plugins/
Настоятельно рекомендуется к обозрению.
PS Куда-то пропал тип топика «Ссылка» :(

Эта маленькая библиотека позволяет очень просто создать пошаговое введение для сайта или приложения. Достаточно добавить атрибуты data-intro и data-step с описанием и номером шага соответственно к нужным элементам страницы. Вот так:

<a href='http://google.com/' data-intro='Hello step one!' data-step='1'></a>

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

Автозаполнение в текстовых полях

Используя HTML5-элемент datalist вы можете создать текстовое поле с автозаполнением. Очень удобно!

<input name="frameworks" list="frameworks" />

<datalist id="frameworks">
	<option value="MooTools">
	<option value="Moobile">
	<option value="Dojo Toolkit">
	<option value="jQuery">
	<option value="YUI">
</datalist>

AngularJS — прекрасный фреймворк для построения веб-приложений. У него замечательная документация, снабженная примерами. В обучающих «пробных» приложениях (вроде TodoMVC Project) он очень достойно показывает себя среди остальных прочих фреймворков. По нему есть отличные презентации и скринкасты.

Однако если разработчик никогда ранее не сталкивался с фреймворками, подобными Angular, и пользовался в работе в основном библиотеками вроде jQuery, то ему может быть трудно изменить свой образ мышления. Как минимум, так было со мной, и я бы хотел поделиться некоторыми заметками на эту тему. Может быть, кому-то это будет полезно.

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

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

В связи с приближающимся праздником спешим поделиться с вами woman-related идиомами. Некоторые из них могут пригодиться в общении, а некоторые — как говорится, just for lulz. Итак, поехали:

woman's reason — женская логика

a woman of letters — женщина-литератор, гуманитарий, писательница

a woman of the world — светская, искушённая женщина

there's a woman in it — «здесь замешана женщина», «ищи женщину» (фр. cherchez la femme)

the old woman is picking her geese — идёт снег, букв. «старушка ощипывает гусей»

teach one's grandmother to suck eggs — поучать старших; учить учёного; «яйца курицу не учат»

a bachelor girl — независимая одинокая девушка, «холостячка»

Правило №1 в DIY: никогда не довольствуйтесь тем, что вам дано. Вы можете проапгрейдить или улучшить все что угодно обладая скромными познаниями и приложив немного усилий, особенно если вы немного знакомы с электроникой. Под катом 10 домашних предметов, которые вы можете круто прокачать, используя капельку припоя и ряд DIY ноу-хау.

Случилось то, чего мы ждали уже давно. Благодаря усилиям Jason Walton теперь CoffeeScript поддерживает Source Maps, и мы можем отлаживать код на CoffeeScript прямо в браузере (Chrome, Firefox Nightly, Webkit Nightly). Теперь практически не осталось причин не использовать этот великолепный язык в своих веб-проектах.

Отладка с данным нововведением выглядит вот так (поддерживаются breakpoints, можно смотреть переменные, стек и т.п.):

Здравствуй!
Тема борьбы с нежелательной смс-рекламой на Хабре поднималась уже не раз^[1]. Хочу внести свой небольшой вклад в дело борьбы с многоголовой гидрой спама.

Я, как и наверное многие, частенько получаю смс сообщения с «ненавящевой» рекламой такси, кредитов, фитнес-центров и прочих радостей жизни. И вот сегодня наткнулся на сервис smsnenado.ru^[2], предлагающий отписаться от смс-рассылок.

%username%, я к данному сервису не имею никакого отношения, предупреждаю сразу

Когда увидел репост новости о данном проекте — отнесся скептически, но любопытство пересилило, и я пошел в разведку.

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

Продолжение перевода здесь

В нашей сфере деятельности нам доступны огромные объёмы знаний, в особенности тех, которые позволяют разработчику стать эффективным. Но почему-то, несмотря на существование множества книг о специфических задачах и обязанностях менеджеров в нетехнических областях, я практически не вижу новых книг или статей о том, как стать хорошим ведущим разработчиком. Замечательным исключением, конечно, являются статьи Кейт Maцудайры [от переводчика: на фотографии, кстати, именно она], немало написавшей о культурных составляющих инженерии.

Но в то же время, все мои знакомые преуспевающие разработчики помнят своих наставников, которые научили их тому, что значит быть „ведущим“.

Продолжение перевода статьи Джона Оллспоу о личных качествах ведущих разработчиков.

Зрелые разработчики не жалуются просто так

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

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

Под катом можно узнать, как в ближайшее время будет работать скролл в 2ГИС Онлайн.

Полгода назад здесь была опубликована статья, которая меня возмутила. В комментариях я обещал, что напишу свою версию. С другой стороны мне не хотелось этого делать, так как получу закономерные вопросы: «А ты собственно кто такой?». Не люблю подписываться в интернет-постах, у меня портилось мнение о многих писателях после того, как читал их жж-блог. Читаешь книгу, думаешь: «Классный чувак!», почитаешь блог, мнение меняется: «Что за кретин?». Такая разница возникает из-за того, что книга проходит пост-обработку, много раз редактируется.
Данная статья переписывалась несколько раз, в этом варианте, считаю, что она получилась наиболее взвешенной. Статья вполне подходит для хабрахабр, так как от людей технической направленности выходило немало известных произведений. И кому-то из вас захочется написать свою историю.

Творческая беседа Дэна Шиппера, кофаундера Firefly и Джейсона Фрайда, кофаундера 37signals привела автора статьи к занятным выводам о том, как и кому продавать ПО. Надеемся, и вам, Хабражители, принесет пользу.

Переведено компанией-локализатором Alconost