Вот уже полгода, как я живу в Копенгагене, столице Дании. В этой статье я хочу показать, почему я считаю эту страну королевством адеквата.

«Доверяй, но проверяй» — это про Данию.

В этой статье я проиллюстрирую основные возможности Ruby для построения Domain Specific Languages(DSL). DSL, это небольшие, узкоспециализированные языки для решения конкретных задач. В отличие от языков общего назначения, таких как C++ или Java, DSL обычно очень компактны, и обладают высокой выразительностью в контексте решаемой задачи.

Различные DSL широко распространены в библиотеках и фреймворках для Ruby. Например в Rails DSL используются для создания миграций.

А теперь, давайте посмотрим какие возможности Ruby предоставляет для построения DSL

Данная статья предназначена для тех, кто использует или планирует начать использовать систему управления конфигурацией Opscode Chef.

Основная задача внедрения любой системы управления конфигурацией, будь то Chef, Puppet или что-то еще, — повторяемо воспроизводить и обновлять окружение всех сред, использующихся при разработке ПО (dev, CI, QA, stage, production). Отсюда следует, что само описание конфигурации необходимо однозначно хранить и обновлять. К сожалению, возможности по версионированию, которые есть в Chef, достаточно ограничены. Поэтому в связке с Chef в последнее время стали активно использовать Librarian. Но перед тем, как рассказать о нем, поговорим немного о кукбуках.

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

Создание интерфейсов в проектировании больших сайтов – это самый объемный и один из самых важных этапов. Поэтому я отдельно решил выделить принципы и законы проектирования интерфейсов.

• Принцип KISS. От англ. «keep it short and simple». Интерфейс должен быть простой и понятный, задачи должны решаться минимальным числом действий, все должно быть понятно и очевидно.
• Не заставляйте думать. Нужно избегать сложных действий, которые заставляют пользователей думать.
• Убираем очевидное. Не стоит показывать очевидные элементы интерфейса, нужно сосредоточиться только на действительно необходимых вещах.
• Соотношение сигнал / шум. В каждом интерфейсе есть важные элементы (сигналы) и маловажные или даже бессмысленные для определенной части системы (шум), естественно, нужно концентрироваться на сигналах и избегать шума.
• Проверенное лучше модного. Не стоит цепляться за моду и делать что-то только потому, что так делают другие, лучше отдать предпочтение проверенным элементам интерфейса.

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

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

Сегодня я хочу поделиться множеством таких практик, собранных вокруг работы с требованиями. За последние несколько лет перечисленные практики мне не раз довелось наблюдать за кулисами у успешных команд в роли agile-коуча и рассказывать о них на тренингах Certified ScrumMaster в роли скрам-тренера.

Я ни в коем случае не претендую на полноту практик и буду рад услышать дополнения. Некоторые из перечисленных практик заслуживают отдельных статей — это work in progress.

Привет, Хабр! В рамках цикла материалов про жизнь студий/агентств я решил поговорить про такой интересный момент, как организация работы с компетентным заказчиком. К счастью – сейчас такое явление становится все более и более распространенным.

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

Сначала определимся, кого в рамках данного материала я отношу к компетентным заказчикам. Итак, основные характеристики:

• Хорошее понимание специфики бизнеса собственной компании, бизнес-процессов, KPI;
• Полное владение аналитическими данными по своей отрасли;
• Отличное понимание специфики работы веб-студий и digital-агентств;
• Понимание всех аспектов digital-среды, владение цифрами;
• Зачастую: квалификация выше, чем у менеджера агентства.

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

«Война — неотъемлемая часть конкуренции...», Карл фон Клаузевиц

Я довольно давно интересуюсь юридической защитой бизнеса, ведь веду бизнес на просторах СНГ, где без этого работать нельзя! За последние 8 лет работы я собрал довольно много рецептов защиты, узнал много печальных историй незащищенных бизнесов и сложил это в довольно интересную схему работы. Сегодня я хочу поделиться этой информацией со всеми желающими, ибо очень люблю справедливость и не люблю ушлых товарищей, которые сегодня часто у кого-то что-то забирают, кидают, наезжают и т.д.

Сейчас я живу в Украине и больше знаком с украинским законодательством, но для других стран СНГ правила ведения бизнеса точно такие же, общая схема идентична, отличаются только нюансы и номера законов. Тех, кто увидят отличия для РФ и других стран СНГ – приглашаю в комментарии к статье.

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

Этой весной, Питер Тиль (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: Стагнация или сингулярность?

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

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

Что до моего опыта, то свой первый заказ я выполнил на бирже поздней весной 2005, а уже зимой 2006 ушел с работы и никогда туда больше не возвращался. Мне посчастливилось всегда держать на очень высоком уровне конвертацию заявки в заказ. Как исполнитель я последний раз выходил на биржу во время кризиса 2008-2009, быстро восстановился и с того же 2009 использую их только как заказчик. Вам решать, насколько мои советы будут полезны. А желающих приглашаю под кат и за парты.

Отличную идею реализовали на сайте Github.com: это командная строка, встроенная прямо в веб-интерфейс.



Есть автодополнение и история команд: кнопка ↑ для предыдущей команды, прямо как в консоли.

По данным 2ГИС в Омске 134 веб-студии. Мы с nem, увидев эту цифру, поначалу обалдели. Ведь у всех на слуху есть 3-4 большие компании, несколько дизайн-студий и несколько мелких и средних аутсорсинговых контор. Все, на этом кругозор заканчивается.
Ан нет, 134!

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

Чтобы не перегружать вас словами, нарисуем картинку.

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

Предположим, что единственный способ представления кода — лямбда-выражение, а единственная доступная структура данных — массив:

square = ->(x) { x * x }
square.(4) # => 16

person = ["Dave",:male]
print_person = ->((name,gender)) {
  puts "#{name} is a #{gender}"
}
print_person.(person)

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

Пользуясь юбилеем — как раз в августе, 10 лет назад был опубликован^[1] The Agile Manifesto еще раз предлагаю сейчас, в летнее затишье, загрузить на будущее в себя немного Agile (когда пойдут дедлайны, будет уже не до этого).

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

Как известно, в MediaWiki, движок Википедии встроена функция «Список наблюдения» (Watchlist). Зарегистрированные участники добавляют статьи в список и потом все правки в этих статьях в реальном времени отображаются на специальной странице. Это очень эффективный инструмент для отслеживания вандализма в реальном времени, который угрожает всем открытым вики-проектам, но не только. Список наблюдения можно использовать и в качестве очень интересной персонально (!) настраиваемой ленты новостей, поскольку в Википедию правки вносятся порой быстрее, чем появляются статьи в СМИ. Хотите быть в курсе исследований ацтеков? Просто подпишитесь на статью «ацтеки». Но это я отвлёкся.

Преимущества OpenStreetMap такие же — информация очень быстро обновляется. В самом OpenStreetMap, к сожалению, нет хорошего списка наблюдения как и нет «свежих правок» (в Истории почему-то отображаются не все правки) — ещё одного инструмента отслеживания вандализма. Что же делать? Как бороться с вандализмом? Вандалы же полностью испортят карту и никто этого даже не заметит!

К счастью, стороннее решение проблемы было найдено разработчиком Matt'ом. Представляю вам С.О.В. OWL — OpenStreetMap Watch List. С помощью этого сервиса можно не только отслеживать вандализм, но и узнавать что новенького (новые магазины, построенные дороги и здания и прочее, можно даже узнавать об изменении часов работы или номера телефона (!) какого-нибудь кафе) появилось в вашем районе или любом другом участке карты.

Всем привет,

Хочу поделиться библиотекой tumblr-dashboard-rss и простым приложением на Sinatra для генерации RSS из постов на вашем Tumblr dashboard.

Топик навеян впечатлениями от докладов на swpiter и постом о том, как не продать машину :)

Как работать над стартапом и всегда оставаться в выигрыше?

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

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

1. Идея!

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

Самое важное в идее — это не терять мотивацию вплоть до 10 шага и тогда вы в любом случае получите для себя выгоду.

2. Детализация идеи

Необходимо хотя бы примерно ответить на эти вопросы:

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

На этом этапе ещё рано отвечать на вопросы:

• сколько времени вы можете уделить (если идея вас реально интересует, вы перейдёте к следующим этапам)
• сколько на это нужно денег
• кто вам ещё нужен для реализации идеи

Дорогие коллеги!

26 и 28 октября в Mail.Ru прошли дни HighLoad ++. Как всегда, мы облегчили жизнь нашим многочисленным разработчикам высоконагруженных проектов, избавив их от необходимости выезжать в полном составе на конференцию.

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

Выбирайте, голосуйте!

Stoyan Stefanov (Yahoo) — Progressive Downloads and Rendering
Joe Damato — Performance tweaks and tools for Linux
Bruce Momjian (PostgreSQL) — Building Global Teams Like Postgres
James Golick — Scaling to Hundreds of Millions of Requests: What Worked and What Didn't
Константин Осипов (Oracle) — MySQL проблемы роста (о проблемах роста проекта и его команды)
Юрий Ковалев (Performance Lab) — Нагрузочное тестирование без границ
Петр Зайцев — Диагностика и исправление проблем производительности MySQL

Полтора года назад мною был представлен стартап домашняя бухгалтерия онлайн — drebedengi.ru.

С тех пор в жизни проекта произошло много интересных, «жизненных» вещей. О самых интересных из них и хочется поведать любителям стартапов. Да и вообще всем.

Прекрасная тридцатиминутная история (на английском) от Джеймса Голика — CTO американской бдсм-соцсети выдерживающей 180 000 000 реквестов в месяц, при среднем времени отдачи ~200 мс, имея шесть серверов. В двух словах — смотрите тэги.

Насколько все быстро растет

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

Далее я расскажу о реальном использовании.