Julia — это Python++?
Давно хотел посмотреть на Julia, так как встречал его (её?) упоминание в очень разных и не всегда относящихся напрямую к программированию местах. Пока изучил только документацию и ничего серьёзного на нём не писал (это будет следующим шагом), но уже хочется сказать пару слов. В соответствии с собственными заветами :-D
Изначально я планировал сделать что-то вроде сводной таблицы «плюсы и минусы Julia», но по прочтении документации передумал.
Во-первых, язык достаточно самобытен, имеет множество мелких нюансов, эффекты которых проявляются только эмерджентно, а копировать всю документацию сюда я не планирую.
Во-вторых, такие таблицы уже есть.
Поэтому я ограничусь личными впечатлениями и пересказом его идеологии, как я её вижу.
Модная типизация в Python
Разработчики пришивают типы к Python.
Раз в несколько лет я нахожу время, чтобы покопаться в наработках сообщества по «продвинутым» проверкам типов. Благо у меня под рукой есть взрослый, большой и нетривиальный проект, на котором можно безбоязненно ставить эксперименты.
Не могу сказать что я разделяю оптимизм по поводу продвинутой типизации в Python. Наоборот, считаю, что это как попытка пришить змее ноги — забавно, но вряд ли удобно. Но раз куча людей тратит на это время, надо быть в курсе.
В этот раз я:
- Посмотрел что из себя представляет mypy и чем может быть полезно (мало чем).
- Посмотрел чем можно автоматически сгенерировать аннотации типов (ничего рабочего нет).
- Подумал о том, как правильно использовать проверку типов в Python, раз их так форсят.
- Нашёл библиотеку, реализующую идеологически верный подход.
Рассказывать буду тезисно, без глубоких обоснований, так как делать нормального качества обоснования для таких холиварных вопросов слишком долго, а я уже дней 5 на копание в этом потратил.
Большая часть поста не про mypy, а про философию проверки типов и будущее Python. Поэтому должно быть интересно, даже если сам mypy вас не интересует.
Софт для «поддержки принятия решений»
Обновлено: исходники проекта открыты — 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
Как я делал и делал бы поддержку GDPR
Удалось столкнуться с этой штукой в момент её появления и в авральном режиме впилить в крупную мобильную игру. Поскольку делать эту функциональность мне явно придётся ещё не раз, а также потому, что иногда спрашивают про неё запишу тут свои мысли о практической реализации поддержки этого закона.
Без юридических тонкостей, так как они не моя специальность, могу насоветовать не того. В целом, с подозрением относитесь к любым не программистским утверждениям в этом тексте, их надо перепроверять!
Про GUI я тут тоже говорить не буду.
Этот текст не отражает ни конкретную реализацию, ни идеальную, а является скорее собранием накопившегося опыта и мыслей.
Уникальные идентификаторы для связи исходников. Как?
Хочу странного, может подскажете способ сделать.
Итак, хочу вести список фичей (в репозитории, рядом с исходниками) и когда пишу логику (тесты, документацию, вёрстку) иметь возможность поставить какой-то идентификатор рядом с реализацией (тестом, документацией, вёрсткой). Дескать вот тут реализуется (тестируется, документируется, отображается) именно эта фича. И потом по этим кроссылками генерировать всякую полезную аналитику.
Фичей не в смысле больших user-story, а в смысле конкретных пунктов, реализацию которых надо контролировать. Например «имя гильдии должно быть уникально», «Это поле должно отображаться только залогиненому пользователю».
Фактически я уже так работаю, записывая каждую мелкую фичу в туду-листе и удаляя их по факту реализации. Не хочется, чтобы знания терялись. Логичный следующий шаг — хранить историю фичей и их реализации.
Вопрос вот в чём: как делать идентификаторы, которые будут связывать фичи с кодом?
Варианты, которые вижу:
- Писать руками. Проблемы: геморрой и простор для ошибок/опечаток.
- Плагин для emacs (любого другого редактора), который в файле с фичами генерирует уникальные идентификаторы, после чего копировать их куда надо. Проблемы: его надо сделать, нужно поддерживать уникальность между файлами, хочу фичи не только в отдельном файле, но и в коде, если это будет удобно.
- Литературное программирование: писать фичу сразу там, где реализуется. Проблемы: фича реализуется в нескольких местах (код, тесты, вёрстка, документация), поэтому идентификаторы всё равно нужны.
- Идентификатором делать сам текст фичи. Проблемы: занимает много места, текст может меняться и будет геморойно менять его везде.