А тот, кто вкалывает получает плюшек больше и раньше — строитель, строивший дом, заселиться в многокомнутую квартиру раньше ханурика и тунеядца, которого в свою очередь определят в спецприют, дабы не сдох на морозе, потому что это тоже человек, который продолжает иметь право на труд и исправление. Справедливо? Разве это не стимул? Но олигарха да, в этой схеме нету — иначе бы строитель, живя в бараке, строил вилу бы ему, пока тот нихера не делает на яхте, а хонурик бы к утру окочурился рядом с этим бараком в картонном ящике. Мотивация бывает со знаком плюс, а бывает со знаком минус. Так вот при капитализме те, кто двигают экономику, вкалывают в основном, чтоб выжить.
Это инетересная мысль. Если на данный момент специалист незаменим на каком-то ключевом участке работы (пусть будет тот же космос), со стороны бизнеса было бы логично заинтересоваться в детальном документировании и обучении новых кадров на этом участке — т.е. в активных коммуникациях и предоставлении детальной информации со стороны данного сотрудника. Для чего? Для того, чтоб если он станет неудобным, начнет рассуждать о бренности бытия, подбивая коллег на требования о повышении ЗП, или просто надолго заболеет, его бы можно было спокойно выкинуть на помойку, поскольку замена уже подготовлена — бездушный бизнес от этого ничего не потеряет, потому что он про деньги. Специалист это понимает, так как он не идиот — идиот бы с работой на этом участке не справился, и поэтому выстраивает защиту своей незаменимости. Если человек не захочет кого-то учить — он может просто делать вид, что учит, лить воду и пр… А бизнес от этого уже теряет. Вот чем крут социализм — работая на общее благо, зная, что государство тебя не кинет, ты не останешься без жилья, без бесплатной медицинской помощи в случае не трудоспособности, а те, кто тебе обеспечит пенсию в старости — это люди, которых ты обучишь сейчас, ты это и делаешь с большим энтузиазмом. И тебя за это уважают, а не смотрят, как на дебила, который просрал бизнесу свою незаменимсоть.
Или ищи единомышленников для апгрейда легаси системы, типа СССР. Потому как работа на отдельных дядей с их притянутыми за уши фальшивыми ценностями и миссиями привело к тому, что всем дружно впердолили повышение пенсионного возраста. Это чтоб ты в своей антиприродной позе (а сидение за компом 8 часов в день — это не естественная поза) сразу же и сдох. Так пенсию платить не надо. Ну, и чтоб самому не стать таким дядькой. Хотел же Сталин сократить рабочий день до 5 часов больше, чем полвека назад, чтоб оставалось пространство для саморазвития, а тут в 21 веке кое-где выясняется, что и 8 мало. Некоторые конторы еще любят притендовать на твое личное время. Дедлайн, ага.
Отмените корпоративы, если хотите, чтобы у ваших сотрудников была мотивация работать лучше и эффективнее.
Ведущие мозговеды называют этот психологический механизм рационализаций. Не захотелось, например, индивиду тратить бабло на корпоративы и под этот бессознательный (?) порыв он подвел рациональную теоретическую базу. Ежу же понятно, что пьяные коллеги, и тем более начальник — это и есть тот самый праздничный микс на унылую и до блевоты заезженную песню. Люди раскрываются с новой, яркой, неизведанной стороны…
Запомните: человек действует под давлением среды. Когда вы пытаетесь добиться результата от сотрудника, вы должны обеспечить ему давление. Это может быть личное давление...
С таким подходом, я бы тоже опасался корпоративов — эти бородатые задpoты могут и отомстить по пьяни.
А как вы подходите к постановке задач разработчикам?
Со своей точки зрения, как разработчика, скажу, что бывает чертовски приятно поработать с аналитиком, который учился в техническом ВУЗ-е и сумел закончить хотя бы курс второй. Значит он\она наверняка слышал про такого чувака, как Фаулер М., с книгой — «UML. Основы», где есть глава 9 — Прецеденты. И про чувака Коберн А. с его «Современными методами описания функциональных требований к системам». Это, как бы, несколько букв из азбуки, которую должен знать бизнесс-аналитик. Ну, а если программеру приходится работать и тем, и другим, потом еще все это тестить в одно рыло, а за одно чинить поломанные спинки офисных стульев, раз уж пришел на работу, то непонятно зачем вообще придумали разделение труда. Тут вы правы — такая контора будет отставать от конкурентов. Но вы, судя по статье, уже на правильном пути. Книги могу подкинуть, если надо.
на этот раз в неё включены практически все самые популярные опции из Standard и даже Enterprise Edition
Когда-то скачал XE, кажется еще 11g, и жестко обламывался сообщениями, типа, этот функционал недоступен в данной редакции — помнится, это касалось аналитических функций (то за что любил оракл) и, кажется, работой с XML, XPatch там не поддерживался вроде, да? Выругался и больше его никогда не ставил. Как сейчас с этим? В плане разработки на PL SQL доступно прямо таки все, что в ентрепрайсе, все пакеты и операторы? И регулярками можно пользоваться?
либо сталкивались с реальными аналогичными задачами, либо просто интересна сам тема?
И то, и другое. Архитектура типичная, еще наверное столкнусь с подобными. Мой интерес – это увидеть адекватный интерфейс редактора сценарев \ правил, в котором мог бы без бутылки разобраться и работать специалист соответствующей предметной области, а не человек из ИТ. Реальный кейс, чтоб раскрыть тему. Зашел как-то на проект, где сценарии описывались UML-подобной диаграммой состояний. Есть класс\объект — банковский счет, который м.б. в состояниях: активен, заморожен, арестован, закрыт и др — это узлы графа. Рёбра графа по переходу между состояниями соответствовали операциям и на них навешивались не только условия перехода, но и сопутствующие действия. Например, клиент (актор 1) пришел в банк и написал заявку на закрытие счета, операционист (актор 2) кликнул операцию закрытия на счёте в системе. Собственно ребро перехода счета из сост. активен в закрыт, так и называется “Операция закрытия счёта”. На ребре проверяется условие – если на счёте нулевой остаток, переход выполняется сразу. Если же остаток есть, из текущего сценария вызывается другой сценарий, где объект, который меняет состояние — это уже заявка на снятие клиентом оставшихся денег в кассе. Порожденная заявка может дальше менять состояния по своему сценарию, согласовываться кассиром (актор 3) с начальником отделения (актор 4) и т.д., а сам счет будет в это время находится в состоянии ”ожидает закрытия” и т.д. Это всего лишь эпизод из жизни счёта, а она у него бурная… К чему я? Вынести сценарии в админку, а не хардкодить — идея отличная, экономия трудозатрат по итогу должна быть серъезная. Но когда я открыл диаграмму в админке, то увидел нечитаемую картинку из наложенных друг на друга палок и говна. Растащить сотню состояний так, чтоб можно было сразу что-то понять оказалось нереально, при том, что граф местами может быть цикличный, например, если клиенту не выдали деньги в кассе, то из ожидания закрытия счет уходит обратно в состояние активный… Смысл в такой админке? Как сделать её для «самого тупого юзера»? Да, еще доводилось писать подобный мастер условий-правил перехода между состояниями, как у вас на скрине с условями пропуска согласанта. Но по ходу эксплуатации системы НЕ самым тупым юзером, вдруг выяснилось, что запись на 1С-подобном языке, типа
ЕСЛИ
Заявка.Остаток > 100 000 и Заявка.Вылюта = "рубль" ТО
На_согласовнаие_к ("Занаида Павловна")
более удобоварима для восприятия, чем нагромождение элементов управления на форме. А если текст разукрасить, то вообще. Но возможно, есть смысл объеденить подходы – хочешь пользуйся мастером, а хочешь пиши скриптом – одно в другое должно автоматом конвертироваться. Но опять же, блин, идет уход от тупого юзера в ИТ. А я мечтаю полностью вылечить пациента, а не передавать его другим докторам… По поводу нотификации чуть позже еще мысль подкину, может пригодиться.
Интересно взглянуть на интерфейс конструктора воркфлоу. Это просто список\таблица узлов в определенном порядке или графический мини-редактор, где можно прорисовать дерево, а условия пропуска навешать по клику на узел? Сколько себя помню, дьявол в подобных архитектурах кроется в подсистеме администрирования бизнес-процесса. Она может быть настолько непрозрачной для конечного пользователя, что админом становиться сам разработчик, т.к. кроме него никто не может разобраться в хитросплетениях правил и переходов, ну или да — людям потом мучаться. Особенно когда кол-во узлов перевалит за десяток, а то и сотню. По вашей задаче, на вскидку — допустим у нас есть 3 участника: экономист, валютчик и главбух. Сценариий 1: если валюта рубль и сумма < 1000 000, заявка от инициатора попадает только к экономисту (конечная инстанция), если валюта НЕ руб. и сумма < 1000 000 в руб. эквиваленте, то только к валютчику (тоже конечная инстанция), а если сумма >= 1000 000 в руб. эквиваленте, то сразу к главбуху, минуя экономиста и валютчика. Сценарий 2: все тоже самое, только к главбуху на согласование заявка должна попасть после экономиста и валютчика в любом случае, конечная инстанция — всегда главбух. Т.е в обоих сценариях – это будет одна и та же прямая линия узлов, которые отличаются только условиями пропуска, в которых не дай бох ошибиться? И чтоб увидеть полную картину сценария, надо ковырнуть каждый узел на предмет условий пропуска? Ну такое. Когда их 2-3 еще может быть. Я бы скорее смотрел в сторону дерева с навешиванием условий перехода (а не пропуска) на ребра графа, а не на узлы. Визуально узел – это, например, прямоугольник с именем\должностью\ролью согласующего, от него линия на следующий «этаж» к ромбику\трапеции с условиями, и может даже с несколькими выходами по кол-ву условий на следующий «этаж» других согласующих с валидацией полноты и непротиворечивости этих условий и т.д. Еще на конструктор полей формы из админки интересно было бы глянуть, как он работает. И к какому событию прихардкодили нотификацию? Сейчас угадаю — при согласовании\отклонении заявки одним из участников или при её закрытии, об этом сразу оповещаются все участники цепочки, не? В любом случае спасибо, что поделились опытом.
Что делать, если мы, допустим, захотим добавить в непустую таблицу NOT NULL-поле и не снабдим его DEFAULT-значением? Ведь если такое поле не заполнить предварительно данными, то база данных не даст выполнить ALTER TABLE ADD-скрипт. А если мы хотим добавить Foreign Key, но не все данные в таблице удовлетворяют ограничен им? А если, допустим, логика приложения изменилась и требуется перенести данные из одного столбца в другой?
Почему бы не снабдить CONVERGE опциями, в которых будут разруливаться возможные проблемы. Например, самое страшное, если в конверге ошибочно «потеряется» столбец, который есть в таблице и он дропнится со всеми данными. Пусть конверге идёт с опцией запрета на удаление по умолчанию, а при необходимости можно добавить в конце что-то типа enable drop columns (col1, 2 ). Другие 2 опции — before converge begin… end, after converge — т.е. по сути триггеры уровня DDL, где можно прописать и перенос данных из 1-й колонки в другую, и заполнение not null поля чем хочешь, а не только default значением, и сохранение какой-то истории, данных в буфер и т.д. Это так, к размышлению.
И второй момент — получается надо выбрать что-то одно, или использование хранимок для всех DML с таблицей или использование триггеров. На большом проекте не видел, чтоб выбор останавливали на первом. Возможно из-за аргумента приведенного в пред. посте (сегодня таблица маленькая, завтра разрослась и апдэйты стали массовыми), возможно из-за того, что он менее интуитивно понятен для вновь подключившихся к проекту, если надо сделать UPD таблицы чел может сразу не допереть, что все, оказывается, идет через хранимки (а использовать, повторюсь, надо что-то одно — хранимка или триггер, иначе могут быть траблы). Верно?
Вы имеете в виду хранимки вообще вместо триггеров? Возможно да, так будет наглядней. Но на скольо я помню, процедуру, например, для апдэйта можно вызывать при одиночном апдэйте, если же это массовый апдэйт большого количества строк, то вызов процедуры одиночного апдейта в курсорном цикле будет работать медленнее, чем один массовый апдэйт с триггером.
Интересно, а в PostgreSQL нет аналога nvl2? Это вроде SQL-ный стандарт. Coalesce, я так понял, как и в Oracle, выбирает первое встретившееся не NULL значение — подойдет, если все поля таблицы NOT NULL. Если в таблице у Неподкупного затереть профессию, то вместо прокурора мы получим кота. И еще интересно, может знаете, есть ли в постгрессе аналог ораклового rowid — глобальный уникальный системный идентификатор строки (как в 3-м способе для таблиц без поля с уникальным айдишником)?
LATERAL- это да, сам впервые узнал. Докину в статью пожалуй.
«CREATE TABLE table_name AS ...» — тоже вещь. Кроме того, что часто просто удобно, загружает данные в таблицу плотно, без свободных областей в «куче» — используется для direct-path загрузок.
Запостил еще пару задачек, возможно также обнаружите для себя что-то новое: голивуд и выборы. В PostgreSQLтоже.
Ну да, читал, оттуда грабли и растут :-)
Может я чего не понимаю, но зачем надо было привязывать диапазон регулярок по умолчанию к NLS_SORT?
Наверное, чтоб разрабы себе бошки поразбивали, прежде чем поймут, что вся соль в этом маленьком кусочке документации. Это же так анти-интуитивно.
Я бы сказал — не совершенен. Еще в 11-й версии буква Ё жила отдельной жизнью, не попадая в диапазон, надо было явно в шаблоне прописывать, а тут был приятно удивлен. Механизма «Просмотр вперёд и назад» нет. Но в целом все равно выручают.
Как-то надо было реализовать отправку платежей от посредника (процессинговой конторы) сторонней организации, скажем мобильному провайдеру. В платежах (упрощенно) было два поля — номер телефона и поступившая на него сумма.
Отправляемых платежей могло быть сотни тысяч, а могло и не быть вовсе (временное прекращение обслуживания и т.п.).
Если платежей не было, то в отправляемом файле должна была быть хоть одна строка. Например с теми же двумя полями; «Платежей нет», 0. На стороне провайдера ПО обрабатывало такие ситуации. Смысл в том, что таким образом провайдер убеждался, что платежей действительно не было. Ведь если бы от процессинговой конторы приходил просто пустой файл — это могла бы быть ошибка его ПО, или потеря данных в ходе отправки.
С таким подходом, я бы тоже опасался корпоративов — эти бородатые задpoты могут и отомстить по пьяни.
Со своей точки зрения, как разработчика, скажу, что бывает чертовски приятно поработать с аналитиком, который учился в техническом ВУЗ-е и сумел закончить хотя бы курс второй. Значит он\она наверняка слышал про такого чувака, как Фаулер М., с книгой — «UML. Основы», где есть глава 9 — Прецеденты. И про чувака Коберн А. с его «Современными методами описания функциональных требований к системам». Это, как бы, несколько букв из азбуки, которую должен знать бизнесс-аналитик. Ну, а если программеру приходится работать и тем, и другим, потом еще все это тестить в одно рыло, а за одно чинить поломанные спинки офисных стульев, раз уж пришел на работу, то непонятно зачем вообще придумали разделение труда. Тут вы правы — такая контора будет отставать от конкурентов. Но вы, судя по статье, уже на правильном пути. Книги могу подкинуть, если надо.
Когда-то скачал XE, кажется еще 11g, и жестко обламывался сообщениями, типа, этот функционал недоступен в данной редакции — помнится, это касалось аналитических функций (то за что любил оракл) и, кажется, работой с XML, XPatch там не поддерживался вроде, да? Выругался и больше его никогда не ставил. Как сейчас с этим? В плане разработки на PL SQL доступно прямо таки все, что в ентрепрайсе, все пакеты и операторы? И регулярками можно пользоваться?
ЕСЛИ
Заявка.Остаток > 100 000 и Заявка.Вылюта = "рубль"
ТО
На_согласовнаие_к ("Занаида Павловна")
более удобоварима для восприятия, чем нагромождение элементов управления на форме. А если текст разукрасить, то вообще. Но возможно, есть смысл объеденить подходы – хочешь пользуйся мастером, а хочешь пиши скриптом – одно в другое должно автоматом конвертироваться. Но опять же, блин, идет уход от тупого юзера в ИТ. А я мечтаю полностью вылечить пациента, а не передавать его другим докторам… По поводу нотификации чуть позже еще мысль подкину, может пригодиться.
Ок
Почему бы не снабдить CONVERGE опциями, в которых будут разруливаться возможные проблемы. Например, самое страшное, если в конверге ошибочно «потеряется» столбец, который есть в таблице и он дропнится со всеми данными. Пусть конверге идёт с опцией запрета на удаление по умолчанию, а при необходимости можно добавить в конце что-то типа enable drop columns (col1, 2 ). Другие 2 опции — before converge begin… end, after converge — т.е. по сути триггеры уровня DDL, где можно прописать и перенос данных из 1-й колонки в другую, и заполнение not null поля чем хочешь, а не только default значением, и сохранение какой-то истории, данных в буфер и т.д. Это так, к размышлению.
«CREATE TABLE table_name AS ...» — тоже вещь. Кроме того, что часто просто удобно, загружает данные в таблицу плотно, без свободных областей в «куче» — используется для direct-path загрузок.
Запостил еще пару задачек, возможно также обнаружите для себя что-то новое: голивуд и выборы. В PostgreSQLтоже.
Может я чего не понимаю, но зачем надо было привязывать диапазон регулярок по умолчанию к NLS_SORT?
Наверное, чтоб разрабы себе бошки поразбивали, прежде чем поймут, что вся соль в этом маленьком кусочке документации. Это же так анти-интуитивно.
Отправляемых платежей могло быть сотни тысяч, а могло и не быть вовсе (временное прекращение обслуживания и т.п.).
Если платежей не было, то в отправляемом файле должна была быть хоть одна строка. Например с теми же двумя полями; «Платежей нет», 0. На стороне провайдера ПО обрабатывало такие ситуации. Смысл в том, что таким образом провайдер убеждался, что платежей действительно не было. Ведь если бы от процессинговой конторы приходил просто пустой файл — это могла бы быть ошибка его ПО, или потеря данных в ходе отправки.