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

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

Поскольку на стандартной шахматной доске 8x8 черные побеждают элементарно, используем для игры доску 9x9 клеток. Эта игра очень простая (и нравится детям). При правильной игре, белые всегда побеждают.

В 2010 году, после прочтения на Хабре статьи о проблемах и недостатках SaaS, я вместе с её автором задался теми же вопросами: «Почему же никто не продает борщ?» и как уйти от недостатков, присущих современным SaaS решениям?

Я убежден, что решение всех обозначенных проблем – предоставление услуг в модели Dedicated SaaS. Что означает термин «Dedicated SaaS», и как этот подход справляется с проблемами традиционных SaaS решений?

Недавно на Хабре мы публиковали небольшой обзор системы управления задачами, над которой работаем. Одна из ее возможностей — односторонняя и двусторонняя синхронизация с Google Tasks. Настроив ее, можно существенно расширить возможности по работе с вашими задачами в Google Tasks, к примеру, достаточно быстро реализовав следующие «плюшки»:

• создание задач в Google Tasks по почте (причем каждая задача имеет свой адрес и можно отсылать подзадачи к любой задаче)
• сделать повторяющиеся задачи в Google Tasks (к примеру, каждый вторник будет возникать задача «Проверить операции по карте»)
• запланировать будущие задачи (т.е. они появятся в Google Tasks в нужную дату)
• уведомлять о приближении срока (даты завершения, due date) задачи из Google Tasks по почте (один или несколько раз)
• через некоторое время (к примеру, неделю) удалять уже выполненную задачу
• предоставить доступ к своим задачам другим пользователям Google Tasks (грубо говоря, расшарить свой список, подробнее ниже)

Реализация всего этого сделана через синхронизацию с нашим сервисом, т.е. мы не говорим о каких-то «хаках» или недокументированных возможностях Google Tasks, а реализуем их через обработку ваших задач у нас. Поэтому если вы не согласны доверить ваши тасклисты сторонним сайтам, то наше решение не для вас.

Какое-то время назад пролетала статистика от одного из преподавателей Coursera Марка Морли [1], что «около 3% записавшихся студентов доходят до стадии финального экзамена и лишь 1,5% сдают его».

Статистика наших онлайн программ чуть выше: у нас до конца всех занятий доходят около 20% слушателей. Мы, правда не делаем экзаменов, потому что искренне верим, что в теме управления людьми и коммуникаций формальные экзамены чуть более чем бесполезны. Но 20% точно прослушивают все занятия до конца (статистика собрана на 1500+ слушателях за 3 года). Ну так у нас и слушателей поменьше чем у Coursera, есть возможность практически личного воздействия на людей. :)

Однако, что та, что та статистика — не утешительна. Или нормально все? На эту тему мой коллега Слава Панкратов недавно написал отличный текст про то, как мы учимся по книгам (к курсам тоже применимо), которым текстом и хотелось бы поделиться.

Слава Панкратов «Синдром Алисы в зазеркалье: что и как читать?..»

Введение

«Нужно больше золота»
Непризнанный экономический гений

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

И тут на сцене появляется рекламщик/продажник. У него тоже есть свое мнение. И мнение это такое: к лешему красоту истинную и крикливый кич, выбросите на помойку споры по поводу идей; сайт должен работать, приносить прибыль: инициировать продажи, служить для брендинга, привлекать звонки — то, что требуется заказчику. Нужно исследовать целевую аудиторию — и выяснить, какой дизайн поможет добиться от неё нужной реакции. И создать с нуля именно то, что требуется для достижения цели. Типовые решения не годятся — они не продуманы для конкретного сочетания заказчик/целевуха. Хуже того, они примелькались.

«Хорошо», — согласятся с ним. Даже здорово. Но как сделать оригинальное решение там, где оригинальности быть в принципе не может (приведу пример из той дискуссии — «интернет-магазин по продаже букетов для новобрачных»)? И как понять, что именно хочет аудитория?

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

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

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

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

Сразу хочу сказать, что все книги на английском. Часть из них можно найти на русском, но без английского на уровне чтения и прослушивания подкастов будет тяжко – на русский клевые вещи об управлении продуктами переводят медленно и нехотя. Второй момент – чтение книг из этого списка не сделает из вас менеджера продукта. Как и книжка С++ за 21 день не сделает из вас С++ разработчика. Просто уровень вхождения в окологуманитарные профессии пониже, и это иногда создает напрасные иллюзии.

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

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

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

Тогда этот пост не для вас. Вы и так все знаете.

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

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

Вы устали? Хотите выпустить пар? Вам требуется передышка? Предлагаю вам присоединится ко мне, тем более, что на дворе пятница.

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

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

Семен занимал одну из самых важных должностей в этом проекте и мог влиять на многие аспекты бизнеса. Вопрос, с которым он обратился к аудитории звучал примерно так: «Друзья, у нас довольно успешный интернет-магазин игрушек, но мне не нравится его дизайн. Например вот эта штука, или эта. Я бы хотел выслушать ваше мнение, что нам можно изменить или улучшить?»

Аудитория не заставила себя долго ждать и тут же начала извергать самые разные идеи, предлагать развитие функционала или отказ от чего-то.

Вот проблема только в том, что никому не было интересно, а что же происходит с данным магазином сейчас, какая у него конверсия? На этот вопрос Семен ответил несколько расплывчато. Он думал или вернее догадывался о конверсии в 2% во что мне верилось с трудом.

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

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

Оригинал: www.infoq.com/articles/atdd-from-the-trenches

ATDD с передовой

Разработка через приемочное тестирование для начинающих

Если вы когда-нибудь бывали в такой ситуации:

Тогда эта статья для вас — конкретный пример того, как начать разработку через приемочные тесты (Acceptance-test driven development) в действующих проектах с легаси кодом. В ней описан один из способов решения проблемы технического долга.
Это пример из реального проекта, со всеми изъянами и недостатками, а не отполированное упражнение из книги. Так что надевайте свои берцы. Я буду использовать Java и JUnit, без всяких модных сторонних библиотек (которыми, как правило, злоупотребляют).
Предупреждение: Я не утверждаю, что это единственный Правильный Путь, существует много других “стилей” ATDD. Так же в этой статье не так много чего-то нового и инновационного, здесь просто описаны хорошо себя зарекомендовавшие подходы и опыт из первых рук.

Если вы интересуетесь клиентским программированием, то как и я, вероятно, могли слышать о Meteor, уже не новом веб-фреймворке, который относится к набирающим популярность, так называемым «фулл-стек» фреймворкам. О нем уже писали на Хабре, чтобы не дублировать информацию, можно почитать здесь или тут. Я довольно давно слышал о метеоре, но все никак не решался его пощупать. И вот, пришли очередные выходные, и я снова наткнулся на него. В этот раз я решил честно попробовать, что это такое. Может быть, этот пост даст кому-то небольшой толчок к началу изучения или хотя бы знакомства с этим инструментом. Тогда это было бы не зря.
Disclaimer: может вызвать зависимость.
Давайте же сделаем первые шаги к освоению meteorjs, добро пожаловать под кат.

Перед загрузкой приложения на ревью в Apple App Store нам задают неожиданный вопрос, а не использует ли наше приложение криптографию?



И хотя соблазн ответить «нет» и загрузить наконец-то очень велик, и кто-то тихо шепчет, что ты мог и забыть про https или вообще не знать, как он работает, но совесть советует разобраться и в этом.
У меня много сил ушло, чтобы получить ERN(Encryption Registration approval from BIS), и я решил написать инструкцию.

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

Уровень слова

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

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

В статье идет речь о методе создания полиморфизма для связей many-to-many в Ruby on Rails.

Задача

Допустим, что необходимо разработать систему управления грузовым транспортом. В нашем распоряжении имеются несколько видов этого транспорта: поезда, вертолеты, грузовики и баржи. И известно, что каждое средство осуществляет перевозку только в строго определенные населенные пункты. Например, часть грузовиков катается по центральной части России, часть по южной, вертолеты работают в Сибири и на Камчатке, поезда вообще ограничены железнодорожным полотном и так далее.
Каждый вид транспорта в разрабатываемой системе будет представлен своим классом: Train, Copter, Truck, Ship соответственно.
Населенные пункты (города, поселки, научные станции, тут нас интересует не размер, а географические координаты), куда осуществляется перевозка, представлены классом Location.
Стоит условие: к каждой единице транспорта может быть привязано сколько угодно Location. В свою очередь к каждому населенному пункту может быть привязано сколько угодно единиц транспорта разных видов.

Concise Binary Object Representation (сжатое бинарное представление объекта) — формат данных, который был спроектирован таким образом, чтобы обеспечить максимально простой код реализации, формирования компактных выходных данных и возможность расширения формата без необходимости обмена информацией о версии.

Стандарт формата CBOR был официально анонсирован комитетом IETF в октябре 2013 года в новом документе RFC 7049, авторами которого являются Carsten Bormann и Paul Hoffman. Взглянув на имя первого автора, можно предположить другую причину происхождения аббревиатуры для названия формата, но возможно это просто совпадение. Формат CBOR получил MIME-тип application/cbor.

На данный момент существует, вероятно, сотни всевозможных бинарных форматов для представления структурированных данных, ряд которых стандартизирован, популярен и широко применяется (например, BER и DER для ASN.1, MessagePack и BSON). Все существующие стандарты решают поставленные перед ними задачи, и CBOR здесь не исключение. К формату было предъявлено семь важных требований, и, поскольку ни один из существующих форматов в полной мере не мог им удовлетворить, был создан новый (да, тут напрашивается картинка ).

Привет %username%! У нас отличные новости: вышла официальная версия NinjaMock — онлайн-сервиса для создания прототипов. Теперь ты можешь рисовать отличные прототипы веб- и мобильных приложений совершенно бесплатно!

Привет, Хабраюзеры! На улице противная погода, ангина не дает покоя моему воспаленному горлу, почему бы не написать статью? Это моя первая проба пера на Хабре, поэтому не судите строго. Название ее навеяно огромным количеством книг, имеющих схожее название. В этой статье я постараюсь описать путь воина-автоматизатора для юных падованов, коим в некоторой мере являюсь сам. Речь пойдет о подходе, который при определенном старании, поможет в краткие сроки познакомиться с таким инструментом кроссплатформенной автоматизации, как CHEF. А также, при сильном старании – овладеть ним в достаточной мере для первых серьезных опытов. Эта статья – некий “guiding way” для людей, мало знакомых с процессом автоматизации.

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

Всем привет!

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

Меня зовут Сергей. Чтобы сказать про себя «я плохой докладчик», нужно хотя бы им, докладчиком, быть. Я вообще не оно. Свою первую и одну из последних презентаций я провел в 18 лет в Испании, перед аудиторией человек в 100. Мой весьма средний на тот момент английский синхронно переводили на испанский, народ зевал и почесывал репы, ожидая когда ЭТО недоразумение закончит блеять и объявится кофебрейк.

Сказать что мне было стыдно — это ничего не сказать, красный как рак, я свалил вторым выходом, забился в свой номер и боялся показаться на глаза. Всякие public professionals типа Карнеги сказали бы «позор!» и «never again!». Для себя я решил — все что угодно, хоть жигулевское пиво по пятницам, только не публичные экзекуции

К чему это я? Многие, глядя на ИТшников, путают скромность со стеснительностью. Да и фиг с ними. Главное — чтобы мы сами не путали. Я — стеснительный, поэтому буду смотреть в пол и читать по бумажке. Я бы выпил, конечно, для смелости, граммчиков сто (а лучше сто пятьдесят), но организаторы запретили. Ну что, пусть фигово, зато честно!

Я владелец компании П, в которой мы уже лет 13 или 14 занимаемся разработкой всякой фигни, про которую никто не слышал. Не имея таланта делать что-то красивое и эстетичное, мы довольствуемся подводной частью айсберга: софт-свитчи и клиенты для IP-телефонии, аппаратно-программные решения для высоконагруженных систем обработки контента, системы имперсонализации web и e-mail для виртуального присутствия, облачное видеонаблюдение, несколько справочных и торговых интернет-порталов, ну и еще пара проектов в стадии стартапа, говорить о которых рано, потому что стыдно

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

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

Devise — это ruby-гем, предоставляющий возможности для аутентификации в rails-приложениях. Devise работает в связке с гемом Warden, который в свою очередь предоставляет сам механизм для аутентификации в rack-базированных ruby-приложениях. Основные особенности Devise описаны ниже:

• основан на Rack;
• является законченным MVC-решением, основанным на Rails;
• разрешает вход в систему по нескольким моделям одновременно;
• основан на модульности: использует только то, что вам действительно необходимо.

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

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



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

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