Всем привет! Меня зовут Михаил Зотьев, я работаю Flutter-разработчиком в Surf. Мне, как, наверное, большинству других разработчиков, которые работают с Flutter, больше всего нравится то, как просто создавать с его помощью красивые и удобные приложения. Чтобы войти во Flutter разработку, нужно совсем немного времени. Недавно я работал в геймдеве, а теперь полностью переключился на кроссплатформенную мобильную разработку на Flutter.

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

Поскольку у Flutter открытые исходники, я решил разобраться с тем, что же там под капотом (on the Dart side of the Force), и поделиться этим с вами.

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

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

Инструкция написана в общем стиле и подойдет для руководителя почти любого уровня при смене места работы. Поехали!

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

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

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

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

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

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

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

Маркетинговый хак?

Бесполезно таить или скрывать то, что однажды вырвется наружу… Полезно находить то — что это таинство из себя на сегодняшний день представляет (метод для тех, кто любит ходить в ногу со временем). Благороднее — быть визионером, а значит чувствовать и видеть, предсказывать (хотя бы для самого себя), так сказать, то, что должно однажды вырваться и взорвать(ся)… Взорвать мир, сеть, общество, определённую сферу, нишу, комьюнити. Thom York, например, делает это в музыке. Записывает сегодня то, что будет понято лет через 5-10 (моё скромное мнение), ну, или, как минимум, проживёт все эти годы, а будет раскрыто, так на него повысится спрос!

Имплицировав в продукт идеи будущего, вероятно, можно получить его т.н. самовоспроизводимость и удлинить срок валидности. Скорей всего это даже можно как-то просчитать, но не буду вдаваться в глубокую аналитику или статистику. Конечно, бывает так, что продукт изначально задуман как life-time-long валидный, т.е. на него есть спрос на протяжении всей жизни клиента, пользователя. А вот как раскрутить сам продукт? Как, раскрутив его, не лишиться пользователей или покупателей и удержать уровень графика спроса?

Несмотря на то, что в любой уважающей себя ИТ-компании, как правило, имеется самостоятельное подразделение или отдельные сотрудники, выполняющие маркетинговые задачи, вопрос о том, имеет ли там место маркетинг как таковой, а если имеет, то в каком проявлении и для каких компаний (аутсорсинговых, сервисных, продуктовых), для нас по-прежнему остается открытым.
Не без элемента легкой провокации и честно декларируемого желания услышать мнение тех, кто знает ситуацию не понаслышке, хотим предложить вашему вниманию серию статей, посвященных маркетингу ИТ-продуктов и ИТ-услуг.
Данная серия – плод совместного исследования и творчества коллектива авторов, часть из которых – эксперты-практики ИТ-компаний, а часть представляет собой сотрудников белорусских университетов.
Указанное исследование начиналось в рамках академического проекта в 2011 году. На основе изучения и обобщения опыта длинного ряда белорусских ИТ-компаний были подготовлены статьи, выступления на конференциях и даже новый учебный курс для студентов-маркетологов.
В настоящее время авторы хотят перевести результаты исследования из разряда академических и в общем-то относительно закрытых для широкой публики в разряд общедоступных и, возможно, полезных для практиков.
Очень надеемся, что материал вам не только понравится, но и окажется полезным. И рассчитываем на объективную критику (или похвалу).

Всем привет! В этом топике мне хотелось бы обсудить одну из самых интересных и в тоже время загадочных тем для большинства, как мне кажется, инди-разработчиков – это продвижение своих собственных приложений. Скажу пару слов о себе: я примерно 2 года занимаюсь Android-разработкой (исключительно в качестве хобби, правда). У меня есть десяток приложений в Play Store, с совокупным количеством загрузок более 5 млн. Ни то что бы очень много, да и большая часть загрузок приходится на одно приложение, но какие-то выводы касательно маркетинга я для себя сделал. Здесь я хочу поделиться своим опытом, наблюдениями, а так же призываю Вас рассказывать о своих результатах в комментариях. Обмен опытом в этом вопросе был бы полезен всем, я думаю.

Паттерн Singleton появился, пожалуй, как только появились статичные объекты. В Smalltalk-80 так был сделан ChangeSet, а чуть в самых разных библиотеках стали появляться сессии, статусы и тому подобные объекты, которых объединяло одно — они должны были быть одни-единственные на всю программу.

В 1994 году вышла известная книга «Паттерны проектирования», представив публике, среди 22-х прочих, и нашего героя, которого теперь назвали Singleton. Была там и его реализация на C++, вот такая:

Пару лет назад я сильно заинтересовался UX и всем, что с ним связано. Постепенно пришло понимание, насколько важна визуализация информации, особенно сейчас. Прочитав Тафти, Кливеленда и Бертена, просто невозможно не думать в этом направлении. Постоянно приходят в голову идеи, как сделать вещи (в частности, в нашем продукте) более визуальными, более понятными.

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

И, как обычно, прощу прощения за объем статьи. Но, надеюсь, вам будет интересно дочитать до конца.