Annual Open Tech Conference - ISsoft Insights 2021. June 19. Learn more.
×Закрыть
Oracle PL/SQL TechLead в Dukascopy Bank
  • Пенсия

    Любомир, а как регулируется вопрос вывода средств в случае смерти инвестора? Ведь в этом случае все счета в украинских банках блокируются, и вывести средства на них становится невозможным. А вывод на счета другого человека, я думаю, будет запрещен самими брокерами.

    Раз мы думаем о пенсии, не нужно скидывать со счетов и этот немаловажный момент.
    Возможно, невнимательно читал, но можно попросить Вас осветить этот вопрос более детально?

  • Чим насправді небезпечний для ФОПів в ІТ сфері новий законопроект Мінсоцполітики? Давайте розберемося!

    доказування їх відсутності покладається на відповідача

    Погодите, а кто ответчик по этой статье? ФЛП Иванов И.И.? Или все-таки компания, с которой сотрудничает ФЛП? Мне кажется, именно второе. То есть придут не к ИТ-шнику, а к компании (если конечно у этой самой компании есть хоть какое-нибудь представительство в Украине). И доказывать это будем не мы, а юристы компаний, которые в этих вопросах более квалифицированные. И думаю, рабочий процесс ни разу не пострадает, если не будет беспредела в виде изымания рабочей техники (ЕМНИП соответствующие запреты уже были внесены в нормативку).

  • Сбережения и Инвестиции — Результаты опроса

    А Вас в Гугле забанили? С января 2017 (емнип) вклады ФЛП гарантируются Фондом в пределах 200 тысяч гривен, вклады Ощада гарантируются в полном объеме государством согласно ЗУ О банковской деятельности.

  • Сбережения и Инвестиции — Результаты опроса

    Представляем. Депозиты юриков — уже гарантируются Фондом. Депозит на крупную сумму — в Ощадбанк государством гарантируется 100% вклада, курсовые потери при банкротстве банка — риск, который минимизируется выбором нормального банка с адекватными депозитными ставками, бетон и бизнес как по мне более рискованная инвестиция

    Поддержал: Andrii Batyiev
  • 12 ошибок при построении архитектуры ПО

    Можете придумать надёжное и простое решение, что если запись в БД не была сделана — то удалить файл?

    Можем. Писать файл непосредственно в БД (если БД поддерживает, конечно). Плюсы такого подхода: полная транзакционность. Минусы тоже очевидны — распухание БД, бекапов, времени восстановления после сбоя и т.д.
    Как только у нас задействуется два и более источника для сохранения данных, которые (источники) никак не связаны друг с другом и не имеют интерфейсов для работы друг с другом, мы в любом случае рано или поздно получим конфликт в данных, который нужно разруливать в рамках «стороннего наблюдателя». У нас в компании на такие случаи существуют мониторинги, которые фиксируют такие случаи и помещают их на ручную обработку. Человек потом должен проанализировать, есть ли проблемы, и пофиксить их. Причем удаление чего-либо автоматически не очень хорошее решение: рано или поздно будет удалено совсем не то, что ожидалось. И проблема некорректной записи чего-либо усугубится некорректным удалением чего-попало...

  • 12 ошибок при построении архитектуры ПО

    валидацию на уникальные значения я предпочитаю делать read запросом к хранилищу

    Думаю, предпочтительно делать валидацию данных как можно ближе к месту их обработки и хранения. Тогда read-запрос будет происходить в самом хранилище. Там же может быть корректно обработан случай на наличие уникального значения, возможно установить оптимистическую или пессимистическую блокировку и т.д.

    Чем дальше от места хранения данных выносится валидация, тем дорогостоящей, сложнообрабатываемой и неполной она выйдет в результате. В идеале, при валидации данных вообще не должно быть никаких исключений, потому как уже заметили ранее: ошибка во входящих данных — это не исключительная ситуация, а вполне рабочий процесс. А эскалация такого исключения на более высокие уровни может привести к его преобразованию в необрабатываемую глобальную ошибку с потерей деталей исключения в худшем случае...

  • 12 ошибок при построении архитектуры ПО

    Код не должен зависеть от данных!

    И снова вопрос спорный.

    Данные в БД хранятся как в таблицах фактов, так и в таблицах измерений. И если по поводу фактов вопросов не возникает (зависимость от этих данных в коде недопустима!), то по поводу измерений вопрос неоднозначный.

    Предположим, существует зависимая от данных в таблице измерений логика как в слое DTO (и выше), так и в слое БД. Самое худшее решение в этом случае — независимость такого кода от данных: тогда очевидно, что связи между этими данными в разных слоях нет. А эта связь очень часто требуется. И тогда придется либо приводить к общему знаменателю (генерация справочника в слое DTO на основе справочника в БД), либо на уровне БД производить маппинг значений из разных слоев (по сути, выносить хардкод справочника из слоя DTO в слой БД). Как мне кажется, вариант 1 более правильный.

  • 12 ошибок при построении архитектуры ПО

    Согласен, вопрос спорный. Но удаление записи из справочника — задачка еще та, особенно если на ID уже навешаны Foreign Keys. И в 99% случаев именно удаление не требуется, часто решается добавлением аттрибута Active/Inactive и периодом действия.

  • 12 ошибок при построении архитектуры ПО

    Да, проблема в разном понимании термина «без необходимости» и даже «без особой необходимости», особенно в случае, когда ты как тимлид объясняешь его пришедшему новичку. И он потом, чтобы не нарушать корпоративный стандарт, начинает рассчитывать вычисляемые поля где-то в промежуточных слоях, вовне БД. И ведь потом не придерешься, сам ведь сказал «без необходимости».

    Я бы переформулировал Ваш тезис таким образом:

    Если есть поля A, B и C и по ним можно вычислить поле D, то ПО ВОЗМОЖНОСТИ, это поле должно быть в информации, получаемой из БД!

    БД отвечает за обработку/хранение/трансформацию/выдачу информации, и самое подходящее место для любых вычисляемых значений (если эти значения основаны на данных БД) — как раз слой БД.

    Поддержали: Mykhailo Sorokin, Oleg Shastitko
  • 12 ошибок при построении архитектуры ПО

    Несколько комментариев с точки зрения разработчика БД относительно архитектуры ПО.
    С моей точки зрения, ошибки при проектировании описаны верно, но хотелось бы дополнить.

    Избыточные, а особенно дублирующие поля — это зло, которое создаёт чуть ли не более половины всех проблем в проекте.

    Да, поэтому следующий шаг — исключить зависимости слоя DTO от структуры БД. Как вариант решения — вынести логику работы с БД в хранимые процедуры. Таким образом, результат выборки будет возвращаться в виде REF-курсора, с необходимой избыточностью/дублированием где это необходимо. При этом структура БД остается за кадром и за нее отвечают разработчики БД. Слой DTO изолируется от «архитектора из Сербии», который может на вверенном ему участке как угодно менять структуру БД, руководствуясь любыми аргументами.

    Если есть поля A, B и C и по ним можно вычислить поле D, то без особой необходимости поля D не должно быть в БД! Иначе это всё влечёт за собой то же самое — это поле нужно сопровождать, менять при изменении одного из полей и прочие радости жизни.

    Это не всегда верно. В современных СУБД вычисляемые поля и материализированные представления берут на себя львиную долю работы по сопровождению и изменению поля. В идеале, для слоя DTO механизм расчета значения должен быть скрыт, по бОльшей части это задача СУБД — быстро и правильно рассчитать/выдать значение. Для части случаев имеет смысл реализовать накопление кумулятивных данных в обход этих механизмов, если расчет сложный и данные либо механизмы расчета данных за прошлые/текущие периоды могут изменяться.

    То есть клиентская часть передаёт новый объект, и нам нужно обновить текущий объект в БД. Мы не знаем...

    Верно, но это и не обязательно знать на уровне DTO. Достаточно знания того, что что-либо изменилось (чтобы лишний раз не вызывать процедуру, изменяющую/добавляющую данные, хотя и этот аспект можно исключить). Задача DTO — по событию передать массив данных в процедуру вставки/изменения, и эта процедура уже сама должна «разрулить», что и как должно быть изменено/добавлено.

    Если логика приложения зависит от выбранного значения, то, скорее всего, стоит использовать enum

    Наверное, наиболее гибким способом использования enum будет его генерация на основе ID сущности из таблицы БД (где она используется в FK/PK и так просто не может быть изменена). При этом каждому ID назначается более удобочитаемый Alias (который и используется далее в коде), в идеале — он берется тоже из таблицы БД. Дополнительные ограничения по поводу изменяемости можно обеспечить как организационными методами, так и методами самой БД. Конечно, если сущность enum никак не представлена в структуре данных БД, то это исключительно служебная информация и Ваши изложения верны.

    Нарушение SRP (Single Responsible Principle)

    В случае использования хранимых процедур разработчики БД могут производить изолированно какой угодно сложный рефакторинг. Это никак не влияет на слой DTO, набор входных/выходных параметров процедуры при этом не меняется. И это касается не только рефакторинга, но и решения проблем производительности, изменения структуры таблиц/схем БД и прочих активностей. Эти задачи остаются целиком в зоне ответственности разработчиков БД и в идеале никак не должны влиять на слой DTO.

    Если правило чуть сложнее примитивной логики (которая контролируется ключами и constraints) — нужно писать триггер

    Это не самое лучшее решение. Повторюсь, но как мне кажется, наилучшим решением есть хранимая процедура как единая точка входа данных в БД. Гранты напрямую к таблицам слой DTO иметь не должен, даже на чтение, исключая возможно какие-то служебные таблицы, обеспечивающие работоспособность самого слоя DTO.

    Использование Exceptions

    Мое видение относительно SQLException. Исходя из вышесказанного, слой DTO должен быть изолирован от системных ошибок в БД вида ORA-00001 unique constraint (string.string) violated. Хранимая процедура либо в REF-курсоре, либо в отдельных выходных параметрах должна вернуть причину ошибки в удобочитаемом и понятном виде, либо информационное сообщение с описанием того, как при необходимости разобраться в деталях ошибки. Конечно, это не исключает необходимости обрабатывать SQLException в слое DTO, т.к. могут быть проблемы с самим вызовом процедуры/при фетче курсора/необходимостью реконнекта к БД и т.д. Но перечень таких ошибок, как и возможная реакция на них, намного меньше. Более того — каждая такая ошибка должна рассматриваться как нестандартное поведение, с соответствующим логгированием/реакцией на нее. Высшим пилотажем является внедрение глобального справочника кодов ошибок с их описанием и механизмом обработки/реакции на них.

  • Как кратно ускорить разработку

    Выскажу свои мысли по этому поводу, со стороны ТехЛида команды Oracle разработчиков, вовлеченных в разработку множества Legacy-приложений компании.

    1.1. «Непрерывно ищем более сильных и классных».

    Сразу вспоминается тезис: «Пишу быстро, качественно, недорого. Выберите любые два пункта». Насколько я понимаю, приоритет к аттрибутам «Быстро» и «Качественно».
    И мы сходу получаем «Дорого».

    1.2. «Прощаемся со слабыми».

    То есть, после выполнения пункта 1, вы прощаетесь с одним из разработчиков, нанятых на прошлом этапе.
    Если учесть, что «слабый» разработчик тоже нанимался по тезисам п.1, то он априори является «Дорогим» для компании, уже имеющим опыт разработки именно под ваши требования.
    Получается, что вы меняете более дорогого, но уже опытного относительно нюансов компании разработчика на менее дорогого, но более перспективного.
    А если ожидания не оправдаются, то на время, пока компания ищет разработчика по требованиям п.1.1, оставшимся достается кусок работы уже уволенного, что явно не добавит им хорошего настроения.

    1.3. «Вовлекаем в разработку более 40 часов в неделю».

    Ок, но необходимо учитывать, что НЕ КАЖДЫЙ разработчик, нанятый в п.1.1, будет готов к такому режиму работы.
    Скажу больше, профессиональный разработчик практически всегда негативно относится к переработкам, даже оплачиваемым по ставке xN.
    А исходя из моего опыта, внеурочка для разработчика (исключая форс-мажоры) является прямым следствием недоработки других участников проекта.
    Забегая вперед, в Вашем случае переработки будут ВСЕГДА, и это является прямым сигналом того, что на разработчика навесили кучу обязанностей, с которыми он справляется плохо.
    То есть, тут надо «не кровати переставлять, а девочек менять» ©.

    2.1. Каждый может разработать и бэкенд, и фронтенд.
    2.3. Есть дизайн-система
    3.2. Отсутствие взаимозависимости между командами
    3.3. Отсутствие зависимостей от внешних обстоятельств

    Сам имея опыт фуллстек-разработчика, который впоследствии стал узкоспециализированным, могу согласиться.
    Но если возвращаться к п.1.1, то быстрее и качественнее будет разработка каждой из частей конкретным специалистом,
    ПРИ УСЛОВИИ обеспечения между ними нормальной рабочей коммуникации.
    Если с коммуникацией проблемы — то фиксить нужно именно эту проблему.
    Вы же предлагаете искать специалистов, которым не нужно между собой коммуницировать.
    То есть, просто заметая проблему под ковер. Ок, тоже подход.

    2.2. Разработчики выполняют роль девопсов.
    2.4. Разработчики — как маленькие продакты.

    То есть, Вы на одном человеке замыкаете весь жизненный цикл приложения: он является Менеджером, Девелопером, Администратором.
    Смелое, очень смелое решение.
    Но краеугольный камень безопасности: девелопер никогда, ни при каких обстоятельствах не должен иметь доступ к продуктовой среде, на которой крутится разработанный им код.
    В который, к тому же, он может внедрить любое решение, аргументируя это выданными ему обязанностями менеджера проекта.
    Если Вы ПОКА не понимаете всю опасность данной ситуации, то просто поверьте на слово. Рано или поздно выстрелит так, что мало не покажется никому.
    К тому же, прохождение аудита такого продукта становится попросту невозможным.
    То есть, мы однозначно приходим к выводу, что такой подход имеет право на жизнь на мелких, достаточно некритичных к потери данным продуктам.

    3.1. Автономность в коде.
    3.4. Отсутствие зависимости от принятия решений.

    Судя по Вашему же описанию, наличие Архитектора прямо конфликтует с п.2.1 и п.2.3.
    Не понятна его роль в продукте. Каждый девелопер ведь «лучший из лучших», и из вашего описания прямо выходит, что сам девелопер является Архитектором.
    И в п.3.4 Вы это явно указываете: девелопер просто обязан принимать решения самостоятельно, не ориентируясь на мнение других членов команды (я так понимаю, и заказчика тоже).

    4.1. Мы не боимся ошибиться.

    Нельзя не согласиться. Здравый и достаточно разумный подход в условиях высокой конкуренции.
    При наличии культуры разработки в компании. И я так понял, определение того где можно рискнуть, а где нет — тоже предоставляется девелоперу?
    То есть ваш девелопер еще выполняет роль и Риск-менеджера, и подразумевается, что он это тоже должен делать «быстро и качественно».

    4.2. Мы минимизируем объем взрыва.
    4.3. Мы умеем бороться с последствиями.

    Я честно не понял, как у вас на этапе разработки закладываются на возможные проблемы и вырабатывают способы их минимизации.
    То есть, при разработке четко видят, что это костыль, и вместо того, чтобы его сделать правильно, вырабатывают способы починки в ситуации, когда костыль сломается?
    Оригинальный подход.

    Резюме:

    Плюсы: девелопер в вашей компании действительно будет быстро расти, т.к. будет совмещать в себе все возможные роли в проекте.
    Это школа, и школа отличная.

    Минусы: такая компания однозначно не является дрим-тим, и при получении определенного количества опыта человек благополучно спрыгнет в узкую специализацию чего-то из того, с чем он имел дело у вас в проекте.
    И заметьте, на бОльшие деньги и мЕньший объем работы (практически всегда).
    И очень навряд ли к вам пойдет работать человек, действительно являющийся экспертом хотя бы в нескольких направлениях (а такие есть, и ценятся они на вес золота).

  • Воєнний стан

    Подозреваю, что бо-бо прилетит совершенно с другой стороны. Понятно, что ужесточать санкции. Но это так, между делом. А за кадром осталась позиция международных морских перевозчиков и организаций. Которые живут по определенным законам и ужас как не любят пиратства и откровенно преступных действий на море. Лично я в ближайшее время буду мониторить этот аспект, т.к. ожидаю прилета хорошей оплеухи для агрессора с этой стороны. Международное морское право оно такое, никогда не знаешь как оно вывернет.

  • Воєнний стан

    Одни кричат, что доверяют абсолютно. Другие, что не доверяют абсолютно.

    Это называется «демократия», коллега.

    От доверяющих только вопли в стиле кремлеботов

    Хмм, какие вопли? Пока все четко и понятно. А гнать зраду по трубам — это многие на раз-два готовы. А если взять сухую выжимку из того, что произошло, то все выглядит не в таком и черном свете.

    не пора-ли искать нового работодателя

    Так что на Вашем месте я бы со сменой работодателя еще чуток повременил :-)

  • Воєнний стан

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

    Как мне видится, итог будет примерно такой:

    — ВП в определенных районах. С учетом того, что эти «определенные районы» и так де-факто живут в режиме ВП, думаю мало что изменится в этом отношении. Скорее, де-факто будет приведено в соответствии с де-юре;

    — мобилизация небыстрый процесс. За 60 дней успеют провести разве что мобилизационные мероприятия и слаживание резерва 1 очереди, да и то если постараются. Т.к. обширная мобилизация — это сильно затратный процесс, то думаю что обширная мобилизация сильно маловероятна (ИМХО);

    — руководство четко озвучило, что банки и фин. сфера работает в обычном режиме, гражданские права и свободы планируют максимально сберечь. Про комендантский час вообще речи не идет;

    Как мне кажется, основную ставку сделают на международном фронте, чтобы максимально сделать бо-бо вконец охреневшим «мышебратьям». А тут перспективы открываются значительные.

    Поддержали: Mikhail Boiko, Serhii Solohub, Dmytro Rak, Sergey Kotov, Igor Markov, Alexander Mazuruk, Nikolay Gardamala, Dmytro Savochkin, Ivan Kukobko, Pavlo Saikevych, Sergii Berezovych, Vitaliy Berdinskikh, Oleksandr Tkalenko, Игорь Зайцев, Andrey Sevastianov, Дмитрий Ляш, anonymous, Vitalii Hnatovych, Sergey V, Микола Рудим, anonymous, Sasha Kozlov, Oleksandr Golovatyi, Dmitry Hryppa, Dmitry Bugay, Ludmila Kovalenko, Іван Пащенко, Vladyslav Andrieiev, Николай Симута, Mykola Martynenko, Stanislav Demchenko, Андрій Козачук, Владислав Кондратенко, Denys Ievstratenko, Dima Kravtsov, belmondo, Andrusenko Dmitry, Макс Скляр, Olexandr, Artem Komisarenko, Дмитрий Демьяненко, Volodymyr Spodaryk, Max Mozok, Александр Матяш, Олександр Федоров, Sergiy Voznyak, Kulchytskyi Roman, Max Kushnir, Artem Ryzhko, Valerii Shevchuk, Mark Sorokin, Buckley The-Cat, Sergii Sinelnychenko, anonymous, Slava Zubko, Alexandr, Ivan Skvortsov, Viktoria Muzychko, Sergey Podobry, Anna Slavutskaya, Ювженко Денис, Alex Fogol, Oleksandra Dobrozhan, Anatolii Medvedchuk, Mykhailo Matviishyn, Nikita Sadkovskyi, Oleg Zarevych, Віталій Мартиник, Yuriy Kostyuk, Anton Momot, Евгений Козлов, Yurii Smyrnov, Andrii Shchurkov, Taras Murzenkov, Taras Barshchovskyi, ZeRMiuNT ZeRM, Михаил Мироненко, AZ, Anton Smolyarov, Oleksandr Katykhin, Володимир, Kseniia Fesik, Dmytro Kolbin, Vlad Stelmahovsky, Евгения Невская, wife of an acrobat
  • Как обналичить предпринимательский счёт с минимальной комиссией?

    Совершенно бесплатно можно обналичить средства, не покидая Приват. Шаг 1: перевод средств на Универсальную (комиссия 0). Шаг 2: оформление месячного депозита (бесплатно). Шаг 3: через месяц перевод средств от депозита на КДВ. Шаг 4: снятие в ближайшем банкомате.
    Недостатки подхода: месячная задержка. Достоинства: проценты от депозита, все действия выполняются онлайн.

  • ДФС почала перевірку банківських рахунків ФОПів

    Вот только налоговая и так получается эту информацию где-то так с года

    Так да не так. Захожу в свою электронную карточку плательщика налогов, иду в пункт меню «Облікові дані платника», ищу «Дані про банківські рахунки» и что я там вижу?
    А вижу я там далеко не полный перечень моих счетов ФЛ.

    По факту, Монобанк (УниверсалБанк) и Приват (в котором я некоторое время обслуживался как ФОП) не передали данные о моих счетах ФЛ. Хотя во всех анкетах я четко указывал, что являюсь ФОП-ом. Что и как они там собираются мониторить с такой статистикой — непонятно...

  • Об автоматической генерации тестовых данных, или Зона комфорта для ваших тестов

    Не всегда этот подход применим, т.к. на проде запросто могут быть сенситивные данные, не предназначенные для глаз девелоперов. А если генерировать SQL не по данным продакшена — то упираемся в несоответствие распределения этих данных. Если допустима обфускация сенситивные данных — то это выход (если нет данных, зависящих от инстанса). И ещё много подобных нюансов. На более-менее крупной системе задача становиться достаточно нетривиальной (не по технической части, а с точки зрения безопасности чувствительных данных)

  • Отмена наличных денег — ваше отношение?

    У нас сьогодні не працює термінал. Тільки готівка

    Это гнилая отмазка, рассчитанная на незнающих покупателей с одной стороны, и неумением/нежеланием работать с терминалом с другой стороны.

    Любой современный терминал поддерживает оффлайн-операции, при которых связь с банком вообще не требуется.

    Поддержал: anonymous
  • Верховна Рада прийняла закон про валюту

    УкрСиб

  • Верховна Рада прийняла закон про валюту

    У меня даже инвойсы уже не нужны. Где-то год назад сотрудник валютного контроля сказал, что достаточно контракта и нечего выносить нам мозг этой макулатурой...

← Сtrl 1... 1516171819...28 Ctrl →