у нас сотрудники сами могут разблокировать свою AD учетку используя комбинацию секретный вопрос+ пин из RSA токена — разработали специальный сервис.
дайте людям self-service услугу и пусть сами решают свою проблему, главное обеспечить безопасность
есть там все, .dacpac файл при деплое может сам сдиффить базу и сгенерировать миграционый скрипт (только изменения). Он даже предупредит, если ожидаются потери данных (удалили столбец например)
я слышал такую теорию, что после 30 лет человек слушает музыку, о которой узнал до 30 лет.
Для меня работает также, все мои плейлисты это то, про кого я узнал до 30, из современных не слушаю и даже не знаю никого, кроме Тейлор Свифт (знаю ее, т.к. она красивая, но песен ее не слышал)
один вопрос, я люблю Сишарп, но почему многие крутые data engineering фреймворки написаны на Java/JVM языках, а не на шарпе?
типа хадуп, спарк например и его части.
Есть ли аналоги-конкуренты чего-то из экосистемы Хадуп написанные на шарпе?
были в практике случаи, когда все было завернуто через хранимки, но с ростом базы все начинало тормозить, особенно генерация отчетов.
лечилось тем, что база делилась надвое: на горячие операционные данные для OLTP, и на холодные исторические данные для OLAP. Такие решения не всегда будут очевидны бекендеру, а для DBA это один из шаблонов проектирования.
По моему опыту сложность разработки и сопровождения получается от того, что бекенд приложения ведет, а база остается ведомой. Когда залепят фичу в приложении, а потом думают как это засунуть в базу и перелопачивают хранимки затронутые изменением.
Я бы сказал, что когда растет сложность надо наоборот: делать базу — ядром системы, которое ведет вперед разработку продукта, независимо от бекенда.
Ну и соотв-но нужно иметь отдельного человека/команду которая только работает со схемой базы и ее развитием, и не отвлекается на бекенд.
минусы хранимок высосаны из пальца, все прекрасно версионируется и работает.
единственная проблема с хранимками — разработчики, которые не умеют в хранимки и три простыни кода засовывают в одну процедуру, еще делают 5-6 вложенных вызовов хранимок внутри хранимок, или вообще навернут дичь с триггером на INSERT на таблицу в которую данные льются по 100 раз в секунду, а потом жалуются, что:
1. хранимка и весь этот ваш SQL тормозит
2. тяжело поддерживать и понимать код
3. код очень хрупкий, любое изменение, может быть валидным SQL, но вызывать ужасную ошибку на уровне бизнес-логики
решение:
1. НЕ ПОДПУСКАТЬ формошлепов, яваскриптеров и пограмистов к написанию хранимок. Хранимки должны писать только Админами базы (DBA) или как минимум людьми, которые несколько лет ботали движок базы и знают тонкости работы базы, движка хранения(storage engine), планировщика запросов. Именно потому, что хранимка это часть схемы базы данных, и требуются спец знания движка. для написание эффективных хранимок.
2. Архитектурно продумывать схему базы и активно ее менять/поддерживать, как только растет база/клиенты/данные. Считайте, что база это еще один бекенд (ядро бекенда) для вашего бекенд-приложения
3. Хранить схему в виде кода (DDL), настраивать CI/CD на тестовый стенд
4. Писать бизнесовые тесты. Очень много проблем, когда код хранимки вроде бы парсится как валидный SQL, но с точки зрения бизнес-логики не валиден. В этом плане прблемы такие же как и в тестировании фронт-енда и решается также. Также как фронтендеры используют Селениум и headless chrome/DOM для тестов фронта, нужно брать бекап реальной базы и прогонять типовые сценарии через все хранимки, чтобы все расчтеты в базе были правильными. Эмулировать реальную нагрузку функционально. Нагрузочно тестировать тоже нужно.
тот факт, что почти все банки в пост-советском пространстве используют АБС, где ядро написано на хранимках (например Новосибирский ЦФТ), и ни копейки там не теряется в их системах, говорит, что на хранимках можно построить многомиллионный бизнес и сответствовать всем требованиям разных регуляторов.
олимпиадное програмимрование дает три основных навыка: декомпозиция задачи, умение строить свои структуры данных, и создавать свои алгоритмы/применять известные алгоритмы к прикладным задачам. И все в рамках нескольких часов.
Именно эти навыки и тестируют крупные западные компании во время технического интервью (знаменитый hackerrank). Интернет полон людей которые не знают ничего про олимпиадное программирование и плачут про то, какие сложные задачки задает треклятый фейсбук/гугл на интервью
функцию сброса вы можете передать в виде коллбека, а выделяя действие в функцию вы можете использовать композицию и собирать несколько действий в одну цепочку.
если не выделять эту строчку в функцию, каждый раз придется создавать лямбду и т.д.
мой зарубежный банк предлагает услугу виртуальной карты для онлайн покупок. я ее всегда держу выключенной и только включаю на минуту когда хочу совершить покупку. не было еще сюрпризных списаний, зато иногда приходят емейлы типа: не удалось списать деньги за вашу подписку от всяких хитрых сайтов, которые сохраняют данные карты у себя без спроса
в таком виде, в каком приведены были примеры — перечисления нафиг не нужны в РНР. Сила РНР в динамичности всего и вся, а наворачивая перечисления, вы попросту хардкодите часть логики в коде.
Я бы наоборот, держал бы все инстансы перечисления в базе и подгружал бы.
Вместо хардкода Season::autum, просто буду работать с объектом класса Season, и пусть он сам решает что ему положено делать.
Перечисления имеют смысл только в компилируемых языках, имхо
в крупных компаниях много бумагомарания, большие бюджеты выделяются только пройдя через бесчисленные комитеты и митинги, и для таких целей подойдет Архитектор.
Человек который создает L0/L1 диаграмму всего проекта — набросок архитектурного решения и поддерживает ее в актуальности. Большой софт обычнл имеет кучу взаимосвязей и интеграций, и индивидуальные вещи могут аутсорситься на галеры, и Архитектор помогает разбить предметную область на домены и очертить границы — гдя чья ответственность, а также как будет вырисовываться интеграция.
простой пример: Компании нужен интранет-сайт для сотрудников для планирования отпусков. Разработчик-формошлеп модет сказать: да щас я забацаю это на реакте за неделю.
А архитектор скажет, так тут нужен модуль SSPI авторизация через AD, чтобы не спрашивать пароль, также standby база и сервак нужны в другом датацентре как hot standby на слуяай disaster recovery, согласно стандартам компании, а данные по отпускам нужно подсасывать из системы учета кадров/data warehouse, а вот функции аппрувала отпусков нужно делегировать двум вышестоящим менеджерам, на члуяай если один из них в отпуске и т.д и т.п
со временем эта идея "давайте забайаем сайт с двумя формами" превращается в типичное ентерпрайзное решение благодаря архитекторам (гуглите FizzBuzz Enterprise Edition для примера)
можно изучать Си в школе, если цель решать олимпиадные задачки. Си очень быстрый и стандартной библиотеки хватает чтобы решать олимпиадное программирование. Плюсы: понимаешь алгоритмы, структуры данных с нуля, можно пробиться в хороший вуз с медалями олимпиад и оттуда в науку/рисерч зарубеж
если же цель — вырастить формошлепа/править ямлы/джейсоны, то питон или яваскрипт это самое то, что надо. Плюсы: понимаешь базовые взять данные с фоомы, засунуть в базу, отобразить хтмл/джейсон и тд, и пробиться на галеру.
Также можно выучить РНР и делать сайты на вордпрессах, я сам РНР обожаю и также с рнр начинал
дайте людям self-service услугу и пусть сами решают свою проблему, главное обеспечить безопасность
модель акторов напоминает мне нечто среднее между распределенным детерминированным автоматом и направленного ациклического графа вычислений
есть там все, .dacpac файл при деплое может сам сдиффить базу и сгенерировать миграционый скрипт (только изменения). Он даже предупредит, если ожидаются потери данных (удалили столбец например)
Для меня работает также, все мои плейлисты это то, про кого я узнал до 30, из современных не слушаю и даже не знаю никого, кроме Тейлор Свифт (знаю ее, т.к. она красивая, но песен ее не слышал)
типа хадуп, спарк например и его части.
Есть ли аналоги-конкуренты чего-то из экосистемы Хадуп написанные на шарпе?
хорошая статья, чтобы понять как не надо делать.
автор, а вы слышали про XAMPP?
лечилось тем, что база делилась надвое: на горячие операционные данные для OLTP, и на холодные исторические данные для OLAP. Такие решения не всегда будут очевидны бекендеру, а для DBA это один из шаблонов проектирования.
По моему опыту сложность разработки и сопровождения получается от того, что бекенд приложения ведет, а база остается ведомой. Когда залепят фичу в приложении, а потом думают как это засунуть в базу и перелопачивают хранимки затронутые изменением.
Я бы сказал, что когда растет сложность надо наоборот: делать базу — ядром системы, которое ведет вперед разработку продукта, независимо от бекенда.
Ну и соотв-но нужно иметь отдельного человека/команду которая только работает со схемой базы и ее развитием, и не отвлекается на бекенд.
единственная проблема с хранимками — разработчики, которые не умеют в хранимки и три простыни кода засовывают в одну процедуру, еще делают 5-6 вложенных вызовов хранимок внутри хранимок, или вообще навернут дичь с триггером на INSERT на таблицу в которую данные льются по 100 раз в секунду, а потом жалуются, что:
1. хранимка и весь этот ваш SQL тормозит
2. тяжело поддерживать и понимать код
3. код очень хрупкий, любое изменение, может быть валидным SQL, но вызывать ужасную ошибку на уровне бизнес-логики
решение:
1. НЕ ПОДПУСКАТЬ формошлепов, яваскриптеров и пограмистов к написанию хранимок. Хранимки должны писать только Админами базы (DBA) или как минимум людьми, которые несколько лет ботали движок базы и знают тонкости работы базы, движка хранения(storage engine), планировщика запросов. Именно потому, что хранимка это часть схемы базы данных, и требуются спец знания движка. для написание эффективных хранимок.
2. Архитектурно продумывать схему базы и активно ее менять/поддерживать, как только растет база/клиенты/данные. Считайте, что база это еще один бекенд (ядро бекенда) для вашего бекенд-приложения
3. Хранить схему в виде кода (DDL), настраивать CI/CD на тестовый стенд
4. Писать бизнесовые тесты. Очень много проблем, когда код хранимки вроде бы парсится как валидный SQL, но с точки зрения бизнес-логики не валиден. В этом плане прблемы такие же как и в тестировании фронт-енда и решается также. Также как фронтендеры используют Селениум и headless chrome/DOM для тестов фронта, нужно брать бекап реальной базы и прогонять типовые сценарии через все хранимки, чтобы все расчтеты в базе были правильными. Эмулировать реальную нагрузку функционально. Нагрузочно тестировать тоже нужно.
тот факт, что почти все банки в пост-советском пространстве используют АБС, где ядро написано на хранимках (например Новосибирский ЦФТ), и ни копейки там не теряется в их системах, говорит, что на хранимках можно построить многомиллионный бизнес и сответствовать всем требованиям разных регуляторов.
Именно эти навыки и тестируют крупные западные компании во время технического интервью (знаменитый hackerrank). Интернет полон людей которые не знают ничего про олимпиадное программирование и плачут про то, какие сложные задачки задает треклятый фейсбук/гугл на интервью
какие-то есть вообще рекомендации, чтобы избежать узявимостей вообще?
если не выделять эту строчку в функцию, каждый раз придется создавать лямбду и т.д.
мой зарубежный банк предлагает услугу виртуальной карты для онлайн покупок. я ее всегда держу выключенной и только включаю на минуту когда хочу совершить покупку. не было еще сюрпризных списаний, зато иногда приходят емейлы типа: не удалось списать деньги за вашу подписку от всяких хитрых сайтов, которые сохраняют данные карты у себя без спроса
в таком виде, в каком приведены были примеры — перечисления нафиг не нужны в РНР. Сила РНР в динамичности всего и вся, а наворачивая перечисления, вы попросту хардкодите часть логики в коде.
Я бы наоборот, держал бы все инстансы перечисления в базе и подгружал бы.
Вместо хардкода Season::autum, просто буду работать с объектом класса Season, и пусть он сам решает что ему положено делать.
Перечисления имеют смысл только в компилируемых языках, имхо
в крупных компаниях много бумагомарания, большие бюджеты выделяются только пройдя через бесчисленные комитеты и митинги, и для таких целей подойдет Архитектор.
Человек который создает L0/L1 диаграмму всего проекта — набросок архитектурного решения и поддерживает ее в актуальности. Большой софт обычнл имеет кучу взаимосвязей и интеграций, и индивидуальные вещи могут аутсорситься на галеры, и Архитектор помогает разбить предметную область на домены и очертить границы — гдя чья ответственность, а также как будет вырисовываться интеграция.
простой пример: Компании нужен интранет-сайт для сотрудников для планирования отпусков. Разработчик-формошлеп модет сказать: да щас я забацаю это на реакте за неделю.
А архитектор скажет, так тут нужен модуль SSPI авторизация через AD, чтобы не спрашивать пароль, также standby база и сервак нужны в другом датацентре как hot standby на слуяай disaster recovery, согласно стандартам компании, а данные по отпускам нужно подсасывать из системы учета кадров/data warehouse, а вот функции аппрувала отпусков нужно делегировать двум вышестоящим менеджерам, на члуяай если один из них в отпуске и т.д и т.п
со временем эта идея "давайте забайаем сайт с двумя формами" превращается в типичное ентерпрайзное решение благодаря архитекторам (гуглите FizzBuzz Enterprise Edition для примера)
можно изучать Си в школе, если цель решать олимпиадные задачки. Си очень быстрый и стандартной библиотеки хватает чтобы решать олимпиадное программирование. Плюсы: понимаешь алгоритмы, структуры данных с нуля, можно пробиться в хороший вуз с медалями олимпиад и оттуда в науку/рисерч зарубеж
если же цель — вырастить формошлепа/править ямлы/джейсоны, то питон или яваскрипт это самое то, что надо. Плюсы: понимаешь базовые взять данные с фоомы, засунуть в базу, отобразить хтмл/джейсон и тд, и пробиться на галеру.
Также можно выучить РНР и делать сайты на вордпрессах, я сам РНР обожаю и также с рнр начинал
Таблица-куча. Какие есть варианты?