Парадокс. В мире так много и так мало прекрасных вещей одновременно. Потому что зачастую они просто тонут в том количестве негатива, который культивирует пресса, СМИ, Интернет.

Политика, коррупция, войны, стихийные бедствия, болезни…

И как бы это дико не звучало, но на фоне всего этого негатива некоторые прекрасные вещи кажутся еще прекраснее… Еще заметнее! Они удивительным образом выделяются из своего окружения и обретают смысл. Вспомните хотя-бы то знаменитое фото поцелуя на фоне беспорядков в Ванкувере!
Не будь там разъяренной толпы, перевернутых машин и полицейских с дубинками, осталось ли это фото таким же заметным? Облетело ли оно весь мир? Любовь на фоне большой трагедии… Сколько Оскаров в свое время получил “Титаник”, балансируя на эмоциях зрителей?

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

Если ты всегда мечтал написать свой язык программирования — добро пожаловать. Здесь ты наверняка найдёшь для себя что-нибудь интересное.

GitHub-юзер yawnt собрал чудесную подборку ссылок для любителей драконов, языков и прочих вкусных внутренностей. А знающие камрады в комментариях наверняка поделятся с тобой и другими яствами.

Пишет yawnt следующее:

С каждым днём мне всё интереснее тема компиляторов, интерпретаторов и дизайна языков программирования в целом. И я решил поделиться с народом ссылками на собранные мной материалы (большую часть мне самому ещё предстоит прочитать :<). Надеюсь, кому-нибудь они окажутся полезными.

Я не включил (и не собираюсь) в список ссылки на официальную документацию, т. к. считаю очевидным, что первым делом следует смотреть именно туда ;P.

Как это вам надо две недели на эту задачу? Что, правда? Вот на эту элементарную формочку с тремя полями и двумя кнопками? Две недели? Да вы надо мной издеваетесь, наверное! Давайте разбираться.

Что? Нужна ли валидация данных при вводе? Ну, конечно, нужна! И вообще, вот это поле лучше разбить на два, так понятнее. А вот в это добавить маску. А вот это — заменить на выпадающий список. Где брать варианты для этого списка? В базе на сервере, конечно. Как это их там нет? А, ну да, это же в другом проекте они у нас были… Ну, значит надо добавить. Взять там и добавить сюда. Сейчас я дам вам контакт разработчика того проекта — обсудите с ним. Он, правда, у нас уже не работает, но я думаю, вполне можно спросить что и как — он расскажет, скорее всего.

Мы всё обсудили? Нет? Что ещё?

Scrum — достаточно простая методология. Работать же по скраму не так и просто. Точно так же происходит со многими инструментами, например с покером для планирования. Практика сама по себе вполне понятная, но продуктивно её использовать в течении длительного времени затруднительно.
В этой статье я расскажу про технику, которая упрощает процесс оценок в работе скрам команды.
Итак, в чём же сложность?
Как вы знаете, story points — это относительные оценки объёма работы в истории. Нет способа оценить одну единственную историю в story points, вы всегда сравниваете историю с другими историями через story points. Покер может хорошо сработать в начале проекта, когда команды оценивает много историй в течении короткого промежутка времени.
Но позже, во время регулярной переоценки существующих историй и оценок новых историй становится значительно труднее, потому что калибровка одного story point забывается: «что такое один story point», «что-то я не уверен, что эта история действительно в 3 раза больше нашего золотого эталона», «эти две истории размером 5 не выглядят одинаковыми в размере, с моей точки зрения». Знакомые проблемы?

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

Статистика, как известно, знает всё. В том числе ей прекрасно известны глобальные тенденции и движения, имеющие место в нашей цивилизации. Одна из таких тенденций – всеобщая и повальная урбанизация. Согласно прогнозам, двое из трех родившихся в ближайшие 30 лет будут жить в городах. Естественно, будут увеличиваться и сами города: к нынешним 500 «миллионникам» за 20 следующих лет прибавятся еще 200. Как эффективно управлять мегаполисом, как сделать его максимально удобным для проживания? Естественно, с помощью с цифровых технологий. В этом посте – рассказ об «умном городе», каким его представляет компания Intel.

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

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

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

Далее, обобщать уникальных специалистов — это все равно что пытаться рассуждать об музыкантах, к примеру, вообще. Музыканты — это, мол, народ странный, и вот особенно родившиеся после 70х. А то, что кабацкий певец, солист оркестра или выдающийся оперный певец — это три совершенно разных музыканта и тысячи разных людей, как-то в пример не берется.

Но идем дальше.

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

6 декабря 2012 г. Google прекратил регистрацию новых аккаунтов для бесплатной версии Google Apps.

У клиентов нашей компании постоянно возникает потребность в электронной почте, обслуживающей их сайты.
Раньше мы настраивали им Google Apps, но после 6 декабря, изучив предлагаемые на рынке решения, решили, что настала пора строить собственную почтовую систему.

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

• масштабируемость (неограниченное количество обслуживаемых доменов, общий объем почтовых ящиков 100 терабайт и больше);
• отказоустойчивость (все промежуточные сервисы должны быть продублированы);
• расширяемость (добавление новых узлов в систему должно быть легким и простым).

Начали с выбора хранилища под письма...

На самом деле выбор был небольшой:

• dovecot/cyrus с хранением в файловой системе через maildir/mailbox;
• dbmail с хранением в базе данных.

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

• доступ к ящикам через IMAP, POP3;
• sieve-скрипты для сортировки почты;
• прием почты через smtp и lmtp протоколы;
• администрирование через cli и SQL-запросы.

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

Вот, к примеру, что советует президент Microsoft в России для борьбы с нехваткой времени:

• Планируйте график таким образом, чтобы решать как можно меньше второстепенных срочных задач, а важные — решать до того, как они станут срочными;
• Занимайтесь любимым делом с максимальной вовлечённостью;
• Рассматривайте принцип жизненного баланса как важную личную и менеджерскую задачу.

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

Добрый день, Хабр!

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

1. я — дилетант. Хотя моя жизнь напрямую связана с программированием уже более 10 лет, я отношусь тем людям, которым интересно в IT очень многое от 3D моделирования до робототехники. А потому бывает, не знаю элементарных для специалиста вещей. Иногда это помогает, иногда мешает, но что есть, то есть.
2. если вы хотите в результате «пощупать» технологию в деле, вынужден разочаровать. Все дальнейшее – только изложение мыслей и идей. Создать готовый движок на хорошем уровне у меня не хватит ни времени, ни умений. Впрочем, если кто-то заинтересуется изложенным – я готов всячески содействовать разработке.

Суть идеи.

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

При обычной верстке html – задает структуру контента, а css – управляет и позиционированием и визуальным представлением документа. Эта двойственность css приводит к раздутым файлам стилей, внутри которых бывает сложно ориентироваться. Одни и те же свойства управляют и положением и внешним видом элементов – это вносит путаницу и затрудняет отладку.

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

Visual Studio – поистине потрясающий инструмент для разработки приложений вообще (чувствуете всю маркетинговую мощь этой фразы?) и web-разработки в частности. Но сила Visual Studio не только в возможностях, которые в ней есть «из коробки», но и в наличии тысяч полезных расширений. Одним из моих любимых расширений, которое добавляет поддержку LESS, Zen Coding и CoffeeScript, а также содержит множество других возможностей, является расширение Web Essentials 2012 (скачать), о котором мы и поговорим в данной статье.

Не смотря на то, что цикл выпуска обновлений для Visual Studio 2012 короче, чем для предыдущих версий, а первое крупное обновление уже доступно, нам, как разработчикам, обычно, хочется получать новые полезные возможности как можно раньше. И расширение Web Essentials позволяет это делать.

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



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

Посмотрим как они выкрутятся?

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

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

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

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

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

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

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

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

Это перевод небольшой заметки, написанной вчера Lea Verou, в ней предлагается интересная, хотя и не новая техника для решения повседневных задач.

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

Если примеры кажутся вам сложными, рекомендую играть с ними в консоли, по мере прочтения. И Заранее прощу прочтение за пугающее название.

Статья

Если вы какое-то время используете регулярные выражения, то наверняка вы сталкивались с разными вариантами следующих задач:

• Пересечение:«Что-то, что совпадает с шаблоном А и шаблоном Б»
  Например: Пароль, минимум 6 символов, в котором хотя бы одна цифра, хотя бы одна буква, и хотя бы один специальный символ
  
  
• Исключение: «Я хочу что-то, что совпадает с шаблоном А, но не совпадает с шаблоном Б»
  Например: Любое целое число, которое не делится на 50
  
  
• Отрицание: Все. Что не совпадает с шаблоном А
  Например: Строка, которая не содержит в себе слово «Foo»

Дарова, хабр! (ничего оригинальнее не придумал)

Сомневаюсь что эта заметка тянет на полноценный пост, но я все же оставлю ее здесь. О чем же пойдет речь?

Все мы слышали о Git. Все мы знаем что он — хорош. Но лишь немногие пытаются что-то с ним делать, как-то его протвикерить. Сразу говорю, тут не будет ничего паранормального, только немного работы с файлом .gitconfig. Да-да, именно с тем файлом, который так трепетно пылится у вас в домашней директории.

Так, мне уже немного надоело писать этот, по сути, бессмысленный вступительный текст, так что давайте уже начнем что-то делать.

Эта статья была написана после серии докладов на семинарах нашей компании, которые показали что тема крайне интересна многим специалистам и заказчикам. Надеемся, и вам понравится. Будем рады комментариям. Соавтор статьи — Алексей Шкарупа, менеджер проекта Домино.

Как определить большой проект?

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

2012 был «освежающим» годом для безопасности OS X — как минимум для специалистов или исследователей. Все дело в том, что за год произошло несколько событий, сумевших потрепать всем нервы. Но, несмотря на то, что некоторые из них сумели смутить и саму Apple, компания серьезно взялась за дело, когда оно коснулось безопасности ее пользователей.

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

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

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

Задача банальная — заменить переводы строк на <br/>, за исключением случая, если перед этим шел html-тэг (для простоты только символ >). Отходя от темы — такой алгоритм замены нужен чтобы иметь и автоматическое добавление переводов строки внутри блоков текста в стиле хабра, и при этом не ломать обычную HTML верстку.