Мне было немного странно видеть, что в таком замечательном ресурсе мало обсуждения и самой темы о торговых марках, то есть наименовании IT продуктов и компаний (“торговой марки”, “торгового наименования”, “ТМ”, “trademark”). Очевидно, что любой программист и участник IT рынка (а особенно те, кто пишут свои продукты), рано или поздно столкнется с этим вопросом. Поэтому, чем раньше IT-шники об этом будут задумываться, тем меньше будет проблем в их бизнесе в будущем.

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

Как-то, во время ужина, моя подруга Валери заявила: «А мне все равно, если кто-нибудь обнаружит мои секреты. Потому что секрет – это всего лишь очередной факт, правильно? Так что если кто и залезет в мои личные вещи, например, и расстроится от того, что он там найдет – ну… это его проблемы».

Некоторое время назад, в силу определенных причин, мне пришла в голову мысль о том, чтобы начать изучать какой-нибудь новый язык программирования. В качестве альтернатив для этого начинания я определил два языка: Java и Python. После продолжительного метания между ними и сопутствующих нытья и долбежки головой о стену (у меня с новыми языками всегда так — сомнения, раздумья, проблема выбора и т.д.), я все-таки остановился на Python. Окей, выбор сделан. Что дальше? А дальше я стал искать материал для изучения…

Уже три года я публикую регулярные обзоры свежих статей по теме интерфейсов, новых инструментов и коллекций паттернов, интересных кейсов и исторических рассказов. Из лент нескольких сотен тематических подписок отбирается примерно 5% стоящих публикаций, которыми интересно поделиться. Предыдущие материалы: апрель 2010-сентябрь 2013.

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

Наследство

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

На примере профиля видно, как было «до» и что стало «после».

Спасибо людям, которые не стесняются поделиться своими мыслями и опытом, пусть даже негативным, по многим важным вопросам организации работы с системами БД. Я наткнулся на статью «Версионная миграция структуры БД: почему так лучше не делать», думал прокомментировать ее, но, рассмотрев дату публикации, решил написать свою. Совершенно очевидно, что автор имел собственное представление о значении и смысле слов, вынесенных им в заголовок. А неточное представление привело к тому, что решалась совсем не та задача. На Хабре довольно давно появились статьи, посвященные организации версионной миграции БД. Они легко обнаруживаются поиском по ключевым словам. Вот в этой статье: ВЕРСИОННАЯ МИГРАЦИЯ СТРУКТУРЫ БАЗЫ ДАННЫХ: ОСНОВНЫЕ ПОДХОДЫ приведено отличное введение в терминологию, задачи и основные методики их решения.
Мне хотелось бы на собственном примере рассказать о тех нежданных проблемах, которые без приглашения внезапно возникли перед нашей группой на одной из моих старых работ, и о том, чего нам тогда не хватало, для быстрого и эффективного разрешения ситуации – в общем, тоже негативный опыт — вдруг кому-то пригодится сейчас или в будущем. Несмотря на то, что в нашей компании мы более широко подходим к решению подобных задач, объединяя их под термином «Управление изменениями в БД», я постараюсь оставаться в поле терминологии из статьи выше.

ОПЫТ ПРОШЛЫХ ЛЕТ – О НЕРЕШЕННЫХ ПРОБЛЕМАХ

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

JavaScript занимательный язык программирования.

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

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

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

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

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

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

Проблема

Начиная работу над очередным сайтом понадобился datepicker. Самый известный такой datepicker — в jQuery UI, но так как jQuery UI в проекте не использовался — тянуть даже его часть не хотелось, принялся за поиски достойной альтернативы.

Требования следующие:

• Выбор даты, нескольких дат, интервала
• Простота настройки внешнего вида
• Желательно без каких-либо зависимостей кроме jQuery

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

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

«Когда человек не знает, к какой пристани он держит путь, для него ни один ветер не будет попутным». (С) Сенека, Луций Анней

Предисловие

Как-то один из топов уважаемой компании, которая занимается продуктовой разработкой ПО, пригласил меня, как эксперта, чтобы я оценил качество нового продукта. Я внимательно просмотрел и прослушал презентацию. Видно было, что коллеги очень старались и работали по 10-12 часов, чтобы продукт выглядел на высшем уровне. После чего меня спросили: «хороший получился продукт или нет?» Я поблагодарил за представленную презентацию, но попросил ответить на свой последний вопрос: «А какие процессы, и с какой целью вы собираетесь автоматизировать с помощью этого инструмента?» Вопрос почему-то вызвал замешательство у докладчиков. После небольшой паузы, топ, который, видимо, был идеологом нового продукта, ответил: «Был бы инструмент хороший, а какие процессы с его помощь автоматизировать мы найдем!» Мне пришлось сказать, что оценить продукт я не смогу. Не зная бизнес-целей, невозможно понять степень их достижения.

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

Для иллюстрации используем проект «Экспедиция за сокровищами Флинта»

Angular — зрелый и мощный JavaScript-фреймворк. Он довольно большой и основан на множестве новых концепций, которые необходимо освоить, чтобы работать с ним эффективно. Большинство разработчиков, знакомясь с Angular, сталкиваются с одними и теми же трудностями. Что конкретно делает функция digest? Какие существуют способы создания директив? Чем отличается сервис от провайдера?

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

В этой серии статей я собираюсь воссоздать AngularJS с нуля. Мы сделаем это вместе шаг за шагом, в процессе чего, вы намного глубже поймете внутреннее устройство Angular.

Мобильные приложения, это не будущее разработки, это уже настоящее. В настоящее время пользователей мобильных приложений уже 1.2 млрд. человек, и это количество постоянно растет (Wikipedia). Вскоре количество мобильных устройств превзойдет количество людей на планете. Если скорость роста количества мобильных устройств останется неизменной, то к 2017 году ими будут пользоваться 5.1 млрд. человек.
Для нас, как для разработчиков приложений, важно разрабатывать свои приложение с учетом мобильных пользователей, если мы хотим чтобы они были востребованы. В AngularJS реализована поддержка мобильных устройств, написанная как командой AngularJS, так и сообществом.
В этой статье мы будем работать с двумя различными способами, чтобы дать читателям опыт в разработке мобильных приложений.

I-Tier: Расщепление монолита

Недавно мы завершили годовой проект миграции веб-трафика компании Групон в США от монолитного Ruby on Rails приложения к новому стеку Node.js и получили существенные результаты.

С самого начала весь веб-фронтенд американского Групона был единым исходным кодом Ruby. Код фронтенда быстро развивался, что затрудняло его поддержку и усложняло процесс добавления новых фич. В качестве решения проблемы с этом гигантским монолитом мы решили реструктурировать фронтенд посредством его разделения на меньшие, независимые и более простые в управлении части. Основой этого проекта стало разделение монолитного вебсайта на несколько независимых Node.js приложений. Мы также переделали инфраструктуру, чтобы обеспечить совместную работу всех приложений. Результатом стал Interaction Tier (I-Tier).

Вот некоторые из важных моментов этой глобальной архитектурной миграции:

• Страницы на сайте загружаются значительно быстрее

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

• Мы можем избежать повторной разработки одних и тех же фич в разных странах, где доступен Групон.

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

Разработка, Направленная на Создание Мусора

Популярным способом процесса разработки в некоторых крупных фирмах является Разработка, Направленная на Создание Мусора, или сокращенно РНСМ. РНСМ питается верой в то, что единственно необходимая для получения денег вещь — это хорошая идея. Очевидный нонсенс, но он является опорой для людей, страдающих недостатком воображения. В данной теории говорится, что Идея — это редкая, ценная и уникальная вещь и вся хитрость в том, чтобы поймать её.

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

Это работает так:

Более 10 лет занимаясь ядрёной смесью из математики, программирования и управления проектами – всем тем, что входит в современное понимание Информационных Технологий — я сформулировал простые правила, которые считаю подходящими для любого профессионала, связанного с ИТ.

Резюме

Мы будем использовать VirtualBox с установленными windows и photoshop, затем интегрируем виртуальную машину в ubuntu. В итоге, мы, практически, не будем ощущать, что используется эмулятор.

Привет, Хабр! Мы продолжаем наш цикл материалов про бизнес веб-студий в рамках Осеннего Ускорения с NetCat и сегодня подробно говорим о маркетинговой стратегии веб-студии, а также публикуем шаблон карты маркетинговых активностей.

На нашем рынке творится полный кошмар с позиционированием и маркетингом студий/агентств. Каждая первая компания гордо объявляет себя «молодым динамично развивающимся digital-агентством полного цикла» — и в результате все игроки сливаются в единую серую безликую массу. Обсудим, как можно этого избежать, и как сформировать грамотную маркетинговую стратегию развития своей компании. Я не претендую на то, что такая структура документа является единственно верной, но на моем опыте такой формат всегда себя оправдывал.

Введение

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

Жизненный цикл клиента (англ. Customer Lifecycle) — это термин, описывающий этапы, которые проходит клиент, когда узнает о продукте компании, принимает решение о покупке, оплачивает, использует и становится лояльным потребителем. Разумеется, что это общее определение и когда речь заходит за конкретную индустрию, требуется внести ряд уточнений. Зачастую очень существенные, особенно если речь идет о SAAS.

В начале 2012 года в Mail.Ru Group было реорганизовано e-commerce-направление, и перед нами встала задача провести обновление всех сервисов. В рамках обновления интерфейсы всех проектов были приведены к единому знаменателю. В этом посте я расскажу о том, что на практике дает унификация, и какими методами можно свести к минимуму затраты при работе с масштабными проектами.

Вводные данные

В направление электронной коммерции Mail.Ru Group входят Товары, Деньги, Недвижимость и Путешествия. Кроме них, в течение года мы работали над новыми продуктами — спутниками основных сервисов. Итогом стало появление новых проектов Авиабилеты, Финансы и Ремонт.

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

В начале лета ко мне обратился знакомый владелец небольшого бизнеса и попросил о том, «сам не знаю о чем, ну, в общем такой электронный менеджер». Несмотря на растущий бизнес, он долго сокрушался и из его рассказа стало понятно, что мониторы менеджеров сплошь заклеены стикерами-напоминалками, таблицы MS Excel неудобны для ведения клиентов, сделки стали срываться хотя бы потому, что о некоторых из них забывали. После небольшого опроса выяснилось, что к старту осеннего бума продаж и клиентов он хочет приобрести программу, которую «раз и открыл», занес клиента, закрыл, проконтролировал, прикрепил документ, проверил оплату, поздравил всех с завершением сделки. Ну и, само собой, недорого и быстро. Дополнительным требованием была возможность доступа сотрудников с их iPad, устройств на Android и с домашних терминалов. Ответ для него возник незамедлительно: CRM, причем лучше в облаке, благо что бизнес не предъявляет особых требований к безопасности.

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

Конечно, абсолютно все CRM рассмотреть невозможно, выбор пал на те, что на слуху, на первой странице поиска или в Яндекс.Директе.