Так надо не игры писать, и не калькуляторы, а узкоспециализированные приложения.
Да, у вас не будет сотен миллионов пользователей, но вам же и доходы нужны не миллионные. А нишевость приложения сильно упрощает раскрутку: вам не нужно перекрикивать всех в общей толпе, а достаточно на специализированном форуме написать "вот я создал решение нашей нишевой проблемы".
А ниши могут быть самые разные: специальные программы для вышивания крестиком (их всего парочка, кстати, и не фонтан), мобильный вариант какой-нибудь desktop-only программы (Syncthing под iOS), редактор какого-нибудь экзотического формата (а-ля TrueCrypt под ту же iOS).
И если при поиске существующих решений находится только множество (это важно) постов, что решений нет — решайте, отписывайтесь в тех же постах, и монетизируйте на здоровье.
А чем выставленный наружу парольный менеджер отличается от выставленного наружу облака, в котором лежит файл с паролями?
Тем, что в случае взлома облачный парольный менеджер потенциально начинает работать против вас. Тогда как утёкшая база с паролями — это зашифрованный набор байт, совершенно бесполезный без мастер-ключа.
Делаю open source проект, монетизация по модели freemium. Подавляющее большинство юзеров пользуются бесплатным вариантом, поэтому я добавил донаты. За прошлый месяц получил 22 доната. Однако на каждого донора приходятся десятки (!) покупателей премиум-лицензии. То есть премиум-версия генерит в десятки раз больший доход.
Конечно, есть проекты где доноры типа Google вносят миллионы. Но большинству FOSS проектов это не грозит. Остаётся или довольствоваться донатами масштаба "на конфеты", или пилить премиум-версию и не отвлекаться на мелочи. Донаты инди-разработчика не прокормят, увы.
У меня была/есть такая же проблема. iOS приложение, опубликовал под GPL, отдельная лицензия для AppStore. Чтобы не было проблем с Apple, у меня должны быть все права на код. Поначалу единственным решением тоже казалось не принимать пулл-реквесты.
Но есть и немного лучшее решение: Contributor License Agreement (CLA). По сути, контрибьютор передаёт автору проекта все возможные права на внесённый код. Принятие соглашения легко автоматизируется через cla-assistant.
С юридической стороны всё отлично: автор проекта может лицензировать новый код как угодно.
С практической стороны, конечно, это антигуманно. Мало того, что контрибьютор сделал доброе дело, так его/её ещё заставляют читать несколько страниц забористого юридического жаргона и отказываться от своих прав в пользу автора проекта. В общем, CLA отпугивает контрибьюторов даже эффективнее чем "спасибо, но мы не принимаем пулл-реквесты." Но всё таки даёт хотя бы теоретическую возможность принимать пулл-реквесты.
Онлайн, офлайн, дерево, вложенные файлы — есть практически во всех живых приложениях, совместимых с KeePass. Однако с отработкой одновременных изменений с нескольких устройств могут быть проблемы.
Шаблоны пока есть только в KeePass на Windows, и в довольно ограниченном виде. Сообщество ведёт разработку более гибкого стандарта, который будет поддерживаться всеми приложениями. Но это может занять и год...
Там даже есть поддержка шаблонов, но довольно рудиментарная: стандартные поля (логин, пароль, URL, заметки) всё равно прибиты гвоздями и от них не избавиться.
Да, ссылка на файл почему-то становится негодной. Судя по логам от пользователей, система периодически теряет связь с интегрированными облаками. Если дело в этом, то фиксика будут звать iOS 14.1...
Если каждый 20 мужчина имеет такое поражение, как описано в статье, то моя выборка (насчитывающая существенно больше 20 мужчин) как-то удивительно не коррелирует с этим фактом. Или же кто-то очень умело скрывает свой дальтонизм.
Это ещё и от профессии зависит.
Повар, для которого сырое мясо выглядит аналогочно жареному, недалеко уйдёт. Как и врач, который не заметит, что у пациента покрасневшая кожа (ожог, воспаление). Как и дизайнер, который в заказе на семь красных линий нарисует две зелёным цветом. Про витую пару ниже уже упомянули. Есть и другие примеры (например здесь, на с. 172)
А если работа не особо получается — человек может и в другую область уйти. Согласно этой статье, особенности цветового восприятия повлияли на выбор профессии у 43% дихроматов и 29% аномальных трихроматов.
Вроде же ещё в 2014 определились, что отпечатки пальцев даже живого гражданина — это предмет, а не информация, и следовательно не подпадает под пятую поправку.
Иными словами, если телефон защищён паролем — выдавать его подозреваемый не обязан; а вот пальцы к телефону полиция может прижать и принудительно.
Про деградацию Li-Ion батарей слышали?
Если нет — просветитесь.
Если слышали, то Ваше сравнение времени работы старого и нового девайса — бессовестное очковтирательство.
Учёные далеко не всегда читают статью целиком — статей-то много, а времени мало. Для экономии времени можно воспользоваться особенностью научного стиля: в правильно написанной статье каждый элемент следует структуре «введение-суть-вывод». То есть своё введение и вывод есть не только у статьи, но и у каждой главы, и даже у каждого параграфа.
Для большинства читателей важнее понять основную идею статьи и её результаты, чем все тонкости экспериментальных методов. Поэтому гораздо быстрее читать статью «не в глубину» (последовательно каждое слово), а «с итеративным углублением»:
1) Название статьи и аннотация;
2) Введение/заключение статьи (соответстующие главы);
3) Введение/заключение каждой главы (первый/последний параграфы);
4) Введение/заключение каждого параграфа (первое/последнее предложение);
5) И, наконец, полное чтение всего текста.
С таким подходом, опытному учёному зачастую достаточно углубиться на один-два уровня (остальное будет очевидным). Если в статье есть нестандатртые подходы, требующие детального прочтения — можно избирательно углубиться в соответствующую часть.
Каюсь, иконка редактора была взята из комплекта иконок под Linux от дизайнера Everaldo Coelho. Если что потом перерисуем, просто времени на это не было.
Эта иконка распространяется под лицензией GPL. Используя любой GPL-лицензированный компонент, вы автоматически делаете весь ваш код доступным по этой лицензии. Таким образом, использовав одну маленькую иконку, вы сейчас обязаны предоставить исходники программы любому желающему.
Тут не каяться надо, а паниковать…
Так надо не игры писать, и не калькуляторы, а узкоспециализированные приложения.
Да, у вас не будет сотен миллионов пользователей, но вам же и доходы нужны не миллионные. А нишевость приложения сильно упрощает раскрутку: вам не нужно перекрикивать всех в общей толпе, а достаточно на специализированном форуме написать "вот я создал решение нашей нишевой проблемы".
А ниши могут быть самые разные: специальные программы для вышивания крестиком (их всего парочка, кстати, и не фонтан), мобильный вариант какой-нибудь desktop-only программы (Syncthing под iOS), редактор какого-нибудь экзотического формата (а-ля TrueCrypt под ту же iOS).
И если при поиске существующих решений находится только множество (это важно) постов, что решений нет — решайте, отписывайтесь в тех же постах, и монетизируйте на здоровье.
Тем, что в случае взлома облачный парольный менеджер потенциально начинает работать против вас. Тогда как утёкшая база с паролями — это зашифрованный набор байт, совершенно бесполезный без мастер-ключа.
У GoDaddy всё очень, очень плохо. И давно, очень давно.
Был даже сайт такой, nodaddy.com (через несколько лет GoDaddy его купил и закрыл).
Скорее её переоценивают пользователи.
Делаю open source проект, монетизация по модели freemium. Подавляющее большинство юзеров пользуются бесплатным вариантом, поэтому я добавил донаты. За прошлый месяц получил 22 доната. Однако на каждого донора приходятся десятки (!) покупателей премиум-лицензии. То есть премиум-версия генерит в десятки раз больший доход.
Конечно, есть проекты где доноры типа Google вносят миллионы. Но большинству FOSS проектов это не грозит. Остаётся или довольствоваться донатами масштаба "на конфеты", или пилить премиум-версию и не отвлекаться на мелочи. Донаты инди-разработчика не прокормят, увы.
У меня была/есть такая же проблема. iOS приложение, опубликовал под GPL, отдельная лицензия для AppStore. Чтобы не было проблем с Apple, у меня должны быть все права на код. Поначалу единственным решением тоже казалось не принимать пулл-реквесты.
Но есть и немного лучшее решение: Contributor License Agreement (CLA). По сути, контрибьютор передаёт автору проекта все возможные права на внесённый код. Принятие соглашения легко автоматизируется через cla-assistant.
С юридической стороны всё отлично: автор проекта может лицензировать новый код как угодно.
С практической стороны, конечно, это антигуманно. Мало того, что контрибьютор сделал доброе дело, так его/её ещё заставляют читать несколько страниц забористого юридического жаргона и отказываться от своих прав в пользу автора проекта. В общем, CLA отпугивает контрибьюторов даже эффективнее чем "спасибо, но мы не принимаем пулл-реквесты." Но всё таки даёт хотя бы теоретическую возможность принимать пулл-реквесты.
Приятно увидеть свое приложение в списке рекомендованных, а уж тем более первым :)
(Только оно App Ninja, а не NinjaApp.)
Онлайн, офлайн, дерево, вложенные файлы — есть практически во всех живых приложениях, совместимых с KeePass. Однако с отработкой одновременных изменений с нескольких устройств могут быть проблемы.
Шаблоны пока есть только в KeePass на Windows, и в довольно ограниченном виде. Сообщество ведёт разработку более гибкого стандарта, который будет поддерживаться всеми приложениями. Но это может занять и год...
Там даже есть поддержка шаблонов, но довольно рудиментарная: стандартные поля (логин, пароль, URL, заметки) всё равно прибиты гвоздями и от них не избавиться.
Да, ссылка на файл почему-то становится негодной. Судя по логам от пользователей, система периодически теряет связь с интегрированными облаками. Если дело в этом, то фиксика будут звать iOS 14.1...
Ну, в нём много чего не хватает. Но я работаю над этим ;)
Повар, для которого сырое мясо выглядит аналогочно жареному, недалеко уйдёт. Как и врач, который не заметит, что у пациента покрасневшая кожа (ожог, воспаление). Как и дизайнер, который в заказе на семь красных линий нарисует две зелёным цветом. Про витую пару ниже уже упомянули. Есть и другие примеры (например здесь, на с. 172)
А если работа не особо получается — человек может и в другую область уйти. Согласно этой статье, особенности цветового восприятия повлияли на выбор профессии у 43% дихроматов и 29% аномальных трихроматов.
Иными словами, если телефон защищён паролем — выдавать его подозреваемый не обязан; а вот пальцы к телефону полиция может прижать и принудительно.
Если нет — просветитесь.
Если слышали, то Ваше сравнение времени работы старого и нового девайса — бессовестное очковтирательство.
Для большинства читателей важнее понять основную идею статьи и её результаты, чем все тонкости экспериментальных методов. Поэтому гораздо быстрее читать статью «не в глубину» (последовательно каждое слово), а «с итеративным углублением»:
1) Название статьи и аннотация;
2) Введение/заключение статьи (соответстующие главы);
3) Введение/заключение каждой главы (первый/последний параграфы);
4) Введение/заключение каждого параграфа (первое/последнее предложение);
5) И, наконец, полное чтение всего текста.
С таким подходом, опытному учёному зачастую достаточно углубиться на один-два уровня (остальное будет очевидным). Если в статье есть нестандатртые подходы, требующие детального прочтения — можно избирательно углубиться в соответствующую часть.
Тут не каяться надо, а паниковать…