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

Иногда необходимо сделать быструю выгрузку данных в интерфейсе 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 не уделяет должного внимания логированию как к «спасательному кругу» в случае возникновения ошибок. Более того, большая часть разработчиков не совсем понимает зачем нужно логировать информацию об ошибках и самое главное, не совсем понимают что делать и как использовать эту информацию в будущем.

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