«Ищут пожарные, ищут милиция, ищут кадровые агентства нашей столицы...» Ищет СКБ Контур и Пульс Цен, Деловые Линии и Собака Павлова, Тинькофф и Сбербанк, Defa и AIC, Яндекс, перманентно ищет даже сам Лебедев. Причем очень многие ищут в буквальном смысле слова годами, исправно подновляя раз в месяц вакансию и меняя тестовое задание, дабы соискатели «не списывали» друг у друга. В общем, спрос на экспертов по UX превысил уже, кажется, все мыслимые показатели.

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



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

А кого же нужно? Разобраться в данном вопросе и призвана данная статья.

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

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

Примечание от Робина Слоана, который опубликовал запись в своём блоге 15 марта 2016 года: «Этот рассказ появился в моём защищённом ящике в конце прошлого месяца, вместе с просьбой опубликовать его на Facebook сегодня именно в таком формате. Я не могу поручиться за подлинность истории, но она показалась мне достаточно странной и интересной».

#

Записывать всё это — последнее, что мне хочется делать, но это необходимо. Частично ради людей, которые обязаны знать, что происходит с их публикациями на Facebook, но главным образом (99%) ради Джули Рубикон и того пика на графике.

Мои бывшие коллеги из Facebook Inc. в Менло-Парк, Калифорния — привет, Джейн, привет, Нил, привет… Марк? — немедленно поймут, кто это написал, и компания вероятно будет преследовать меня, но я думаю, они провернут всё тихо. Комиссия по ценным бумагам не ограничится тихим расследованием, если действительно нарушены соответствующие правила и нормы, но честно… вряд ли такие правила существуют.

Реклама на основе месторасположения все ощутимее набирает конкурентные преимущества — таков вывод из свежего исследования Forbes Insights совместно с xAd “Локация — императив стратегического маркетинга”.

Cтэнфордский курс CS183B: How to start a startup. Стартовал в 2012 году под руководством Питера Тиля. Осенью 2014 года прошла новая серия лекций ведущих предпринимателей и экспертов Y Combinator:

(картинка с сайта developer.apple.com)

Что это такое?

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

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

В статье я коротко опишу, что такое iBeacon, какие задачи мне пришлось с этой технологией решать, что удалось, что не очень.

Вчера я публиковал статью на тему того, когда лучше публиковаться на хабре. С тех пор мой паук собрал статистику за весь 2015 год, и картинка немного изменилась. Так же я построил несколько графиков, и в целом картина прояснилась. Осторожно, трафик!

Астрологи объявили месяц статистики, и пожалуй я присоединюсь на сегодня к авторам статистических статей.

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

Звучная аббревиатура BEM пришла к нам из лабораторий Яндекса. Там, как и в случае с XSLT, применение BEM решили возвести в абсолют: под BEM'ом в Яндексе понимают целое семейство утилит и подходов, объединенных единой идеологией блочной архитектуры веб-приложений. Как любая тоталитарная система, BEM требует соблюдения строгих правил при разработке, не редко вступающих в конфликт со здравым смыслом небольших проектов, не сравнимых по ресурсам с Яндексом. И да, то самое чувство, когда читаешь официальные доки по BEM.

Однако, как часто бывает в процессе эволюции больших систем, под давлением интеллекта и безлимитных сроков рождается технологический алмаз, настолько же маленький и самостоятельный, насколько и ценный, который огранят уже другие. Да, BEM с его спасительной строгостью — это явное откровение. Каждый, кто на моих глазах причащался, мгновенно становился счастливым. Однако, после первой волны наслаждения приходит осознание, что второй подход к этому снаряду может порвать ментальные связки по всему объему мозга. И вот уже слышны жалобы на слишком большую сложность освоения, на чрезмерную многословность, на (внимание!) увеличение количества мегабайт в HTML и CSS, и кто знает на что еще, не относящееся к делу.

Соглашусь, трудно взять и начать писать BEM без разбега: и нотация глаз колет, и старые трюки не проходят, и думать приходится системно. И вообще, писали как-то годами без BEM'а и писать будем! А ведь для легкого и непринужденного преодоления порога вхождения нужно сделать всего два движения. Во-первых, понизить сам порог, смягчив BEM. И во-вторых, немного подтянуться самим. Тогда переход будет ровненьким и мы мягко вкатимся в эру читабельного и поддерживаемого CSS.

В новом дайджесте – локализация для азиатского рынка, альтернативная жизнь без Google Play, два отчета о разработчиках (Stack Overflow и Developer Economics), новые инструменты, дизайн и истории разработки.

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

Итак, представляю публике проект под девизом «Поменьше писанины! Побыстрей, дебаг!» Набор для скоростной разработки на Джанго.

Это 2 шаблона:

• шаблон конфига buildout, который подтягивает и собирает все необходимые проекту пакеты
• шаблон проекта, а именно настройки, включающие все нужные инструменты, и набор статики (готовые файлы на Haml и Sass)

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

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

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

Введение

Уважаемый читатель, эта статья является второй частью цикла статей, посвященных вёрстке.

В первой части мы верстали шаблон Corporate Blue от студии Pcklaboratory с помощью стандартных средств на чистом HTML и CSS. В данной статье мы попробуем сверстать этот же шаблон, но с помощью CSS фреймворка Bootstrap 3.

Уважаемый читатель, этой статьей я открываю цикл статей, посвященных вёрстке.
В первой части будет описано, как это сделать с помощью стандартных средств на чистом HTML и CSS. В последующих частях рассмотрим как сделать тоже самое, но с помощью современных фреймворков и CMS.

Часть 1. Верстка стандартными средствами

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

Итак, давайте приступим. В качестве нашего подопытного мы возьмем бесплатный psd шаблон Corporate Blue от студии Pcklaboratory.

Недавно Brian Haveri в блоге vermilion.com сделал отличное наглядное сравнение популярных CSS-фреймворков (статья), которые можно использовать для разработки адаптивных сайтов.

За последний год мне удалось поработать со всеми этими фреймворками: Bootstrap, Foundation и Skeleton, и могу сказать, что в свое время такая табличка сохранила бы кучу времени. Поэтому я перевел ее на русский язык, добавив немного своих комментариев. Надеюсь будет полезно хабровчанам.

Сегодня слово «framework» стало обыденным в web dev'е. Как только jQuery и Prototype, Rails и Django получили широкое распространение, кажется, что теперь каждый использует какой-нибудь framework для создания своего сайта.
Но что же такое framework? Они полезны программистам, или даже веб дизайнеры могут воспользоваться их преимуществами?..

Это перевод оригинальной статьи Design Patterns: When Breaking The Rules Is OK

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

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

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

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

Кто ответит за дизайн?

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

CSS Refresher

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

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

Приветствую всех, меня зовут Максим Иванов, и сегодня я подготовил для вас перевод заметок разработчика из Сан-Франциско Васанта Кришнамурти (Vasanth Krishnamoorthy) «CSS Refresher». Web-программирование одна из самых быстро развивающихся отраслей в наше время. Казалось бы, возьми какой-нибудь видеокурс на tuts+ и освой html-верстку, однако, как говорил разработчик Opera Software Вадим Макеев, выступая на конференции CodeFest, они все равно это делают плохо. Но давайте посмотрим, может мы итак все это знаем.

Содержание

1. Позиционирование (position)
2. Отображение элемента в документе (display)
3. Плавающие элементы (float)
4. CSS селекторы
5. Эффективные селекторы
6. Переотрисовка и перерасчет
7. CSS3 свойства
8. CSS3 медиа-запросы
9. Адаптивный web-дизайн
10. CSS3 переходы
11. CSS3 анимации
12. Масштабируемая векторная графика (SVG)
13. CSS спрайты
14. Вертикальное выравнивание
15. Известные проблемы

Мы в «Латере» занимаемся созданием биллинга для операторов связи. В блоге на Хабре мы не только рассказываем об особенностях нашей системы и деталях ее разработки (например, обеспечении отказоустойчивости), но и публикуем материалы о том, как другие компании работают с ИТ-инфраструктурой. Сегодня мы представляем вашему вниманию адаптированный перевод заметки главного разработчика Azure Джеффа Уилкокса, о том, как более двух тысяч членов команды проекта переезжали на GitHub.

За последние четыре года Azure очень многое перенял от opensource-сообщества, поэтому нам пришлось пересмотреть подходы к работе и минимизировать количество выполняемых вручную операций, необходимых для поддержания крупной GitHub-организации. Мы автоматизировали большую часть управленческих функций, создав веб-приложение с открытым исходным кодом, которое использует некоторые из сервисов Azure (это App Service, Active Directory и Azure Storage), GitHub API и другие свободно распространяемые решения.

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

Разработчики и организации любых размеров сразу почувствуют, насколько может быть полезным наш портал: Azure Active Directory дает инженерной группе доступ к инструментам для работы с GitHub.



Веб-портал, созданный с использованием Azure, GitHub API и Node.js, позволяет автоматизировать работу с GitHub и ускорить адаптацию новых сотрудников.