Пару месяцев назад на Хабре вышел обзор бесплатных нелинейных видеоредакторов, под которым быстро собрался тред из сотни комментариев. Некоторые из перечисленных инструментов относятся к профессиональным (Lightworks), другие — претендуют на звание бесплатной альтернативы профессиональным видеоредакторам (VSDC).

Штука в том, что определение «профессиональности» довольно расплывчатое, и какой именно при этом подразумевается функционал неясно. Захотелось выяснить, в чём же всё-таки хороши бесплатные аналоги, и можно ли ими заменить программы стоимостью в несколько десятков тысяч рублей. Забегая вперед, скажем, что получилась ситуация почти как по Гоголю:

Если бы губы Никанора Ивановича да приставить к носу Ивана Кузьмича, да взять сколько-нибудь развязности, какая у Балтазара Балтазарыча, да, пожалуй, прибавить к этому ещё дородности Ивана Павловича

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

-Я хочу устроить панику, понятно?
-Ты там бойню устроишь, а не панику.
«Большой куш»

В течение уже достаточно долгого времени мне попадаются на глаза посты, статьи и даже целые книги, задача которых — донести до читателя советы о том, как правильно делать Скрам. Все они, в общем-то, однотипны и построены на предположении, что большинство людей некорректно понимают предлагаемые практики, их назначение и важность. В этих источниках активно доказывается, что Скрам все-таки работает, говорится о принятии ценностей, о перестроении мышления на уровне компании, о тонкостях организации митингов и прочих нюансах, которых по итогам каждый раз набирается вагон и маленькая тележка. Судя по всему, проблема действительно существует, ведь даже Кен Швабер и Джеф Сазерленд описывают Скрам как “легковесный, простой в понимании и сложный в овладении” [1]. Но только ли дело в практиках? Может быть, люди не понимают саму суть Скрама? Когда что-то начинает приносить серьезные деньги, то не секрет, что именно прибыль становится путеводной звездой этого корабля. Может быть все эти тренинги, сертификации и спешно переучивающиеся в скрам-мастеров менеджеры проектов затмили собой изначальный посыл? Вполне вероятно. Но так ли это? Данный опус — это попытка взглянуть на проблему под немного другим углом, с точки зрения больше технической, чем какой-либо еще.

Автор оригинальной статьи Ali Mese добавил ещё 100 новых бесплатных сервисов. Все 400 потрясающих сервисов доступны здесь. И еще подборку +500 инструментов от 10 марта 2017 г. смотрите здесь.

A. Бесплатные Веб-Сайты + Логотипы + Хостинг + Выставление Счета

• HTML5 UP: Адаптивные шаблоны HTML5 и CSS3.
• Bootswatch: Бесплатные темы для Bootstrap.
• Templated: Коллекция 845 бесплатных шаблонов CSS и HTML5.
• Wordpress.org | Wordpress.com: Бесплатное создание веб-сайта.
• Strikingly.com Domain: Конструктор веб-сайтов.
• Logaster: Онлайн генератор логотипов и элементов фирменного стиля (new).
• Withoomph: Мгновенное создание логотипов (англ.).
• Hipster Logo Generator: Генератор хипстерских логотипов.
• Squarespace Free Logo: Можно скачать бесплатную версию в маленьком разрешении.
• Invoice to me: Бесплатный генератор счета.
• Free Invoice Generator: Альтернативный бесплатный генератор счета.
• Slimvoice: Невероятно простой счет.

Часть 1: Введение в ReactiveUI: прокачиваем свойства во ViewModel
Часть 2: Введение в ReactiveUI: коллекции

Мы уже обсудили возможности ReactiveUI, связанные с работой со свойствами, выстраиванием зависимостей между ними, а также с работой с коллекциями. Это одни из основных примитивов, на базе которых строится разработка с применением ReactiveUI. Еще одним таким примитивом являются команды, которые мы и рассмотрим в этой части. Команды инкапсулируют действия, которые производятся в ответ на некоторое событие: обычно это запрос пользователя или какие-то отслеживаемые изменения. Мы узнаем, что можно сделать с помощью команд в ReactiveUI, обсудим особенности их работы и выясним, чем команды в ReactiveUI отличаются от команд, с которыми мы знакомы по WPF и его родственникам.
Но прежде чем перейти к командам, рассмотрим более широкие темы, касающиеся реактивного программирования в целом: связь между Task<T> и IObservable<T>, и что такое горячие и холодные последовательности.

Зачем, кому это нужно, чем это сделать

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

• видеть связь: требование➝вопрос➝изменение в требовании➝новое требование;
• избежать дублирования требований/вопросов;
• отследить задействованные в реализации системы (от обратного: чтобы представитель каждой системы видел требования, реализация которых хоть как-то касается его системы);
• получать подтверждение по каждому требованию — что да, требование понято и зафиксировано верно, что реализация возможна;
• проследить связь с требованиями другого, очень похожего на наш проект проекта — чтобы иметь знание, что вот это уже там реализовано, и мы будем просто использовать сделанные наработки;

Да и вообще.

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

Взявшись за написание небольшого, но реального и растущего проекта, мы «на собственной шкуре» убедились, насколько важно то, чтобы программа не только хорошо работала, но и была хорошо организована. Не верьте, что продуманная архитектура нужна только большим проектам (просто для больших проектов «смертельность» отсутствия архитектуры очевидна). Сложность, как правило, растет гораздо быстрее размеров программы. И если не позаботиться об этом заранее, то довольно быстро наступает момент, когда ты перестаешь ее контролировать. Правильная архитектура экономит очень много сил, времени и денег. А нередко вообще определяет то, выживет ваш проект или нет. И даже если речь идет всего лишь о «построении табуретки» все равно вначале очень полезно ее спроектировать.

К моему удивлению оказалось, что на вроде бы актуальный вопрос: «Как построить хорошую/красивую архитектуру ПО?» — не так легко найти ответ. Не смотря на то, что есть много книг и статей, посвященных и шаблонам проектирования и принципам проектирования, например, принципам SOLID (кратко описаны тут, подробно и с примерами можно посмотреть тут, тут и тут) и тому, как правильно оформлять код, все равно оставалось чувство, что чего-то важного не хватает. Это было похоже на то, как если бы вам дали множество замечательных и полезных инструментов, но забыли главное — объяснить, а как же «проектировать табуретку».

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

Данная статья является попыткой ответить на эти вопросы хотя бы в первом приближении.

В октябре в Минске состоялся ProductCamp — ежегодный BarCamp для экспертов в области продуктового менеджмента. На мероприятии были затронуты различные тематические области управления продуктом: от маркетинговых исследований и разработки до вывода на рынок и оперирования. Все участники кэмпа — профессионалы по управлению и маркетингу продуктов, что способствовало активному неформальному общению, обмену знаниями и опытом.
На кэмпе свои доклады представили специалисты Wargaming, Яндекс, Localway/Anywayanyday, Дневник.ру, Ecwid, SEMRush, Нетология-групп, Skyeng, Tutu.ru.

Под катом вы найдете записи выступлений:

• Превращаем стратегические цели компании в продукты / Ярополк Раш, Wargaming
• Customer Development это невыносимо просто / Иван Замесин, Яндекс
• Анализ своего продукта и сравнение с конкурентами / Александр Токмаков, Localway/Anywayanyday
• Бесплатные продукты. Куда все идет? / Глеб Кудрявцев, Дневник.ру
• 10 недостатков Product manager / Алексей Журба, Wargaming
• 5 ошибок при работе с новым продуктом в новой сфере / Иван Масленников, SEMRush
• Как воспитать продуктовых дизайнеров? / Женя Некрасов, Нетология-групп
• Поиск работы Product Manager / Александр Атцик
• Эксперимент со SmartTV / Алёна Паньшина, Яндекс
• Метрики наше все! / Илья Забелин, Яндекс
• Прототипируй или умирай / Харитон Матвеев, Skyeng
• Системный анализ как точка роста продукта / Артур Евстефеев, tutu.ru
• Как определить, понравится ли обновление / Светлана Половинкина, Wargaming

Приятного просмотра!
Присоединяйтесь к сообществу ProductCamp в Facebook, а также следите за анонсами на сайте.