Масса познавательного. Благодарю.

Слово состоит из двух лексем — smell и fungus. И переводится оно как «нюхать гриб».

Кстати, fungus в американском английском означает плесень/грибок (а не гриб) и от этого значение меняется.
Также, smell зачастую трактуется как "пахнуть чем-то" (it smells bad), поэтому вольное трактование smellfungus может быть: вонючка. :)

Обычные домашние проекты, которые неспеша выходят на коммерческие.

https://www.ebay.com/itm/353200398868 x2 и старые SAS SSD с большим остаточным ресурсом.

Намучались с переносом .Net приложения с ORM NHibernate c дата центра в облако - ORM генерит массу запросов и если в облаке веб сервер и бд на разных машинах (а всегда на разных) то latency предсказать невозможно.

Облака замечательны, но для своих пет-проектов за $120/мес разместил в датацентре 2 стареньких сервера на 40 ядер, 1.5тб памяти и 10тб SSD диска, 15 статических IP и давно отбил начальное вложение в б/у серверы. Все железо под моим контролем и производительность адекватна нагрузкам.

Может что-то упустил, но чем не подошел стандартный "sql server full text search" с их CONTAINS, NEAR, RANK, etc.?

Используем на больших массивах. Скорость высокая. Хотя, изначально тоже что-то пытались создавать свое через CLR-ки.

Замечательная идея.
Благодарю, что нашли время оформить и поделиться.

Schemathesis as a Service. Мы работаем над тем, чтобы всё было в один клик. Просто вводим адрес схемы и всё замечательно тестируется, не надо писать никакого кода.

Первая реакция по ходу чтения - сделать тестер/валидатор доступным как сервис.
Подписался.
Сервис планируется сделать коммерческим или будут другие опции?
Например, я бы заплатил и использовал в своих API.

Есть опыт в построении и многолетнем использовании такой системы.
Вкратце на английском, чтоб не запутать в терминологии:
- Data storage: data-driven definition for storage and storage access.
- Backend: data-driven schema, constraints, relations, business logic.
- Frontend: data-driven library of UI controls
- Frontend: data-driven UI to manage the control properties
- Frontend: data-driven support for multiple web and mobile applications
Вобщем, кодовая база минимальна. Остальное - metadata.

В итоге:
- с 2017 несколько коммерческих продуктов - полет нормальный
- планов перехода на классическую разработку нет
- доработка существующих или разработка новых продуктов сократилась на порядок

Детали:
Pros:

1. надежность выше по сравнению с классической разработкой

2. нет необходимости "протаскивать" изменение схемы по слоям

3. по сравнению с ORM (EF и NHibernate), работает шустрее и легче переносится в облако. ORM тенденция генерить массу мелких запросов, которые в облаке при небольшой latency между серверами вызывает серьезные задержки.

4. хранение в метаданных: схемы приложений (ERD), диаграмм процессов (BPMN), UI, бизнес логики.

5. мощная система управления правами доступа

6. идеально для стартапов: позволяет создать MVP и продолжать до полноценного продукта, без переделок.

7. extremely high "time to market"

Cons:

1. Порог вхождения выше

2. Change tracking усложнен т.к. классические VCS (Git) построены на сравнении text data, а в системе сравнивать нужно транзакции (record changes).

3. Сложно найти разработчиков, на иную модель разработки т.к. переиспользование знаний нулевое и в резюме не напишешь

Больная тема. Спасибо что поделились.

Насколько сложно расширить вывод?

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

... а так ли pyolite/pyodide равноценен полноценной анаконде с ее базой пакетов и энвиронментами.

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

Если накоплен опыт, хорошо бы еще раскрыть сценарии ошибок при поднятии стартапов.
Общих фраз масса, но рабочие примеры усваиваются лучше.

Например, сейчас на стартапе, где за прекрасной идеей в процессе разработки MVP были 3 (три) переделки UI. Т.е. заказчик не может остановить перфекционизм и заваливает разработку переделками.
Или еще: scope creep, когда заказчика "несет" и в MVP пытаются впихнуть малозначимые фишки и "рюшечки" UI, тем самым теряя время.
Или, когда MVP фокусируется на UI больше, чем это необходимо для донесения идеи по тестовой группы.

Для заказчиков нужно проводить ликбез - как довести идею про продукта, не растеряв бюджет и не завалив сроки. :)

У Tesseract были сложности со структурированными данными.

Есть большой сектор в бизнесе по перегонке PDF форм в данные.
Интересно было-бы прочитать опыт со структурированными данными.
Пока ABBYY FC наиболее рабочее решение.

После хвалебных статей о Вебикс, решил все-же написать.

Начал работать с Вебикс с 2014, когда он был еще в бете: прототипировали платформу на Вебикс.
Своевременно апдейтились с помощью консультантов XB.
Ожидался переход с v6 на v7 с серьезными архитектурными изменениями.
Заранее договорился с XB.
В момент апгрейда ребята из XB сказали что консультатнтов не будет, все заняты.
Затем мы взяли крупный проект и в итоге налопатили столько кода, что спустя пол-года уже не могли проапгрейдиться - трудоемко.

Итог душной истории: мы сидим на старой 6-ке и благодарим XB за поддержку.
Мигрировать уже не реально.

Поэтому, пожалуйста, посыпьте соль, расскажите какие классные фишки вы реализовали в v8, 9, etc.

На арм ядрах работают контролеры, которые моргают фотодиодами.

Аккуратности ради - фотодиодами нельзя "моргать", они работают на прием света, а не на отдачу.

Встречался с RFID на 134 kHz (для животных 12мм и 8мм).
Flipper поддерживает 134 kHz?

Используем Pydantic в FastAPI.
Значительно упрощает формирование сложной схемы request/response в OpenAPI.

Если есть конкретные аргументы против InfluxDB, поделитесь пож.

Можете посоветовать иные Time Series DBMS в качестве альтернативы?

Ребята, вы постите полезную маркетинговую информацию, но либо площадка, либо материал не подходят.

С кармой "-5" сложно доверять вам маркетинг или рассматривать ваши инструмены.
Ведь, если вы не можете заинтересовать IT-шников и получить положительные отзывы на ваш материал, ваши уверения в профессионализме не убедительны. Где гарантия что вы и ваши инструменты справятся на других площадках?

Отзыв бывшего пользователя Linguix:

1. прекрасная идея

2. задержка, иногда, необъяснимо высокая

3. обучить (запомни, что это сЛоВо, это норм для моего текста) не получилось. Снова и снова предложение исправить слово, которое уже, вроде, должно быть в словаре нормальных.

4. перегруженный UI

Результат: пользуюсь Grammarly.

Стартап, данные хранились тоже в Firebase.

Шустрая разработка, пока не потребовалось нормализовать данные и реализовать ссылки, ссылочную целостность, простую логику на уровне базы.
Решили переписать с переходом на классику - реляционную базу.

Почему Гитлаб?
Гитлаб нравится, но молодой.

У Jenkins масса примеров использования.
Пока тестируем Jenkins как альтернативу Bitbucket (у нас лицензия до 2024).
Полет норм.

bitbucket

Больше не продают лицензии.