Есть настоящие профи по управлению проектами или те гении, которые придумывают изящные решения для заказчика. Однако почти в каждом, даже самом многообещающем проекте рано или поздно возникают проблемы. Иногда эти проблемы принимают монструозные масштабы, и команда проекта уже не может справиться с ними самостоятельно. И я тот самый человек, который их решает. Как я это делаю - тема отдельной статьи. Почему практически  каждый раз получается? Ответ прост: всегда  полезен взгляд со стороны. Однако наступил момент, когда этого оказалось мало. Я вляпался в настоящий факап, и единственным выходом из него были переговоры. 

Иногда необходимо сделать быструю выгрузку данных в интерфейсе Formspider при нажатии на кнопку "Export to XLS", к примеру. Для этого в Formspider создаётся объект ACTION в котором указывается пакет и его процедура, скачивающая нужные данные.

В теле процедуры объявлена переменная формата BLOB, которой присваивается значение, возвращаемое функцией, которой я и хочу поделиться с общественностью (выгрузка из PL/SQL делается при помощи пакетов DBMS_SQL и AS_XLSX).

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

По революционным праздникам в СССР проводились торжественные демонстрации. Для взрослых участие нередко было обязательным. Ну а детям -- им, что ни праздник, всё в радость. Торжественная обстановка, можно помаршировать со взрослыми в стройных колоннах, покричать "ура", поразмахивать красными флажками и надувными шариками...

Шарики. Кажется, именно с них-то всё и началось.

Согласно советским открыткам, демонстрация должна была выглядеть как-то так:

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

— Почему ты закрыл людям доступ? — спросил он Сисадмина, когда они после перекура пили кофе.

— Потому что такие сайты не нужны для работы.

— А курить нужно для работы?

— Вообще-то нет…

— А кофе пить?

— Ну…

— Ну тогда, — сказал Учитель, — открой людям доступ.

Наткнулся на любопытный материал, в котором автор систематизировал и записал свой опыт инженера-программиста в 20 тезисов. Я работаю в коммерческой разработке ПО больше 25 лет, и этот текст отозвался во мне практически каждой буквой — большинство советов я тоже регулярно практикую, не облекая их в формат ёмких афоризмов. В общем, решил сделать перевод.

Особенно отзываются пункты «стройте компактные системы» и «лучший код — это отсутствие кода». Последний совет я превращаю в цитату из какого-то второсортного фильма про самураев: «Лучшая победа — та, которую ты одержал, не доставая меч из ножен» (думаю, сослуживцы за моей спиной уже закатывают глаза). И, конечно, бесконечные разговоры про легендарных 10x-программистов постоянно хочется прервать советом не связываться с 0,1x-программистами (которые реально существуют, в отличие от 10x).

Практически любая enterprise-система (под которой мы будем подразумевать некоторое ПО, где пользователи работают постоянно в течение всего рабочего дня) в современном мире стремится вырасти вместе с управляемым ей бизнесом в высоконагруженное web-решение вроде нашего СБИС.

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

Когда, где и как их может вызвать затаившийся до поры диверсант?

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

Добрый день! Работая разработчиком Oracle PL/SQL, часто ли вам приходилось видеть в коде dbms_output.put_line в качестве средства debug-а? Стоит признать, что к сожалению, большинство (по моему личному мнению и опыту) разработчиков Oracle PL/SQL не уделяет должного внимания логированию как к «спасательному кругу» в случае возникновения ошибок. Более того, большая часть разработчиков не совсем понимает зачем нужно логировать информацию об ошибках и самое главное, не совсем понимают что делать и как использовать эту информацию в будущем.

Как свалить самому?

Вторая часть — https://habr.com/ru/post/563484/

Вокруг темы синтеза речи сейчас много движения: на рынке есть огромное число тулкитов для синтеза, большое число закрытых коммерческих решений за АПИ (как на современных технологиях, так и на более старых, т.е. "говорилки") от условных GAFA компаний, большое количество американских стартапов, пытающихся сделать очередные аудио дипфейки (voice transfer).

Но мы не видели открытых решений, которые бы удовлетворяли одновременно следующим критериям:

• Приемлемый уровень естественности речи;
• Большая библиотека готовых голосов на разных языках;
• Поддержка синтеза как в 16kHz так и в 8kHz из коробки;
• Наличие своих собственных голосов у авторов решения, не нарушающих чужие права и лицензии;
• Высокая скорость работы на "слабом" железе. Достаточная скорость работы на 1 потоке / ядре процессора;
• Не требует GPU, команды ML инженеров или какой-либо дополнительной тренировки или для использования;
• Минимализм и отсутствие зависимостей / использование в 1 строчку / не надо ничего собирать или чинить;
• Позиционируется именно как готовое решение, а не очередной фреймворк / компиляция чужих скриптов / тулкитов для сбора плюсиков;
• Решение никак не связано и не аффилировано с закрытыми экосистемами и продуктами Гугла / Сбера / Яндекса / вставить нужное;

Мы попытались учесть все эти пункты и представить комьюнити свое открытое некоммерческое решение, удовлетворяющее этим критериям. По причине его публичности мы не заостряем внимание на архитектуре и не фокусируемся на каких-то cherry picked примерах — вы можете оценить все сами, пройдя по ссылке.