Открыл исходники Morphologic
В апреле я открыл доступ к своему хобби-проекту Morphologic.
Как я и опасался, штука оказалась для очень частных случаев. Настолько, что даже я её особо за эти 3 месяца не использовал.
В то же время я всё ещё думаю, что сама по себе она полезна, а значит проект останется доступен для всех.
В рамках наведения порядка я решил открыть его исходники под лицензией BSD.
Ссылка на репозиторий: https://github.com/Tiendil/morphologic
Все заметки из Google Docs переехали в issues.
В телеграм есть группа для обсуждения проекта: https://t.me/morphologic_soft
Если кто-нибудь хочет вписаться в разработку Morphologic, я с радостью эту инициативу поддержу.
На текущий момент планы по проекту у меня следующие:
- Ждать, пока он мне реально и сильно понадобится, чтобы получить интересный пример использования.
- Если будет настроение, опубликую статью на Хабре про морфологический анализ со ссылкой на Morphologic в конце. Лишние звёзды на гитхабе и карме ещё никому не мешали :-D
Софт для «поддержки принятия решений»
Обновлено: исходники проекта открыты — https://github.com/Tiendil/morphologic
В марте я писал в фейсбуке про софт для «поддержки принятия решений». О том, что не могу найти ничего подходящего.
В итоге я решил, что если гора не идёт к Магомету, то Магомет пишет необходимый софт сам.
На текущий момент у меня есть рабочий прототип, который очень надо проверить на людях.
Софт может пригодиться, если вам необходимо найти решение / выбрать архитектуру / определить лучшее сочетание параметров в сложной и / или слабо формализированной области.Например, вы знаете, что решение может обладать свойствами A, B, C, D, … Z, но не знаете какое сочетание свойств будет оптимальным. При том, что A и D несовместимы, а сочетание свойств B+X+Y выглядит лучше, чем P+Q.
В этом случае вы можете ввести список свойств, ограничения, и поэкспериментировать, меняя правила подбора и оценки решений.
По сути, софт помогает делать полный перебор всех вариантов решений с ограничениями.
На странице софта есть более подробноее описание и инструкция.
Посмотрите пожалуйста. В основном на предмет полезности для вас лично и идей в какую сторону двигать разработку.
Прототип:: https://tiendil.github.io/morphologic/
Группа в телеграм для обсуждения: https://t.me/morphologic_soft
Изменение восприятия сложности
Написал философской рефлексии пост про изменение восприятия сложности за последние полвека.
Когда надо слушать пользователей
Вечные направления.
Первое, чему учат начинающего разработчика — это не слушать хотелки своих пользователей. Умение игнорировать чужие идеи даже важнее урезания фич, не говоря уже о какой-то там монетизации. Начнёте потакать им (или менеджменту, хе-хе) и всё, считай нет продукта, вместо него адская химера.
Конечно, в реальной жизни всё не так однозначно и данное табу полезно только для неокрепших умов. Мы же люди опытные, поэтому вместо безусловного запрета подведём небольшую теоретическую базу под этот вопрос. Ладно, не теоретическую базу, просто хочу сделать пару заметок.
Так кого и когда необходимо слушать при разработке ПО?
Верификация через дублирование логики
Привет.
В посте Тесты, которые тестируют тесты я описал свой взгляд на верификацию программ через дублирование их логики в виде отдельной модели и последующее сравнение с ней. В качестве частного случая выступили юнит-тесты.
В этот раз, опираясь на изложенные идеи, я попробую сформулировать общий подход к оценке уровня верифицированности ПО.