Можно посмотреть и со стороны замещения рутины, которая есть в каждой должности. Человек работал, выполнял 100% своих обязанностей. Например, 80% это была рутина и отсутствие автоматизации. 20% чистое творчество. ИИ замещает эти 80% и пытается продуцировать 20% творчества, но уже с апрувом от человека. Получается, что ИИ заберёт рутину на себя, а самые творческие и креативные могут не переживать
Суммы сильно приблизительные. Нет смысла их приводить точно. Одно можно сказать однозначно — это дорого, но затягивает. Двигатель может стоит и 500 и 5000 рублей. Вопрос лишь в толщине кошелька. Кто соберется приобщиться к этому хобби прикинет комплектацию, которую ему хочется — дорого? — можно тут урезать, там урезать, тут все же качественное сразу взять — вот уже и потянуть можно — берем, паяем, настраиваем и в небо!
У нас немного другая структура проекта habrahabr.ru/post/154779/ но столкнулись с теми же проблемами. Решилось просто — написанием полноценного maven-плагина, который начинает выпускать текущий модуль, спускается по иерархии зависимостей до самого низа и запускает выпуск версий\подверсий модулей, предварительно проверяет, есть ли релиз для текущего снэпшота, если есть, то берет его. В итоге время выпуска сократилось раз в 5 и рутинная работа по сверке версий, коммитам в SVN пропала.
Работает этот подход, правда, только когда сборка корректна. А то бывает такое, что некоторые разработчики начинают использовать транковые версии модулей в ветках сопровождения, но с этим мы боремся и сделали защиту выпусков в плагине.
Жестковатые условия, но надо участвовать. Зачем же принудительно все свои технологии заставлять использовать (в частности внутренний биллинг)? Достаточно было и одной Smart Chord Apps.
Технически с ODT нет никаких ограничений, но есть категорическое нежелание гос-заказчика (в лице ведомств, заказывающих ИС) работать с такими документами. Только DOC, XLS и редко PDF. Возможно, они просто не знают и не понимают альтернатив.
Обычно так делают в самом начале проекта. Идеальный ORM — универсальный ORM. Когда же начинаются реально высокие нагрузки, то алгоритмы специализируются на данных. Вплоть до того, что вот из этой таблицы мы всегда извлекаем быстро N-записей, это и будет верный результат. Извлекать вот так-то очень быстро. Естественно без джоинов. Нормальные формы часто тоже становятся препятствием, но не во всей же БД делаются такие «заточки», а только в самых узких местах.
Тюнинг БД из той же оперы.
Одиночные операции вместо пакетных
Конвейер наше все. Как начал Форд их использовать, так мы и продолжаем. Те же видеокарты, имеют кучу конвейеров. Промышленные ЭВМ содержат специфические конвейеры для разных операций. Например, лучше быстро складывать числа, чем иметь универсальный модуль, но жутко медленный.
Еще пример. По сети приходят пакеты. Мы их как-то обрабатываем и пишем в БД. 100 пакетов в минуту. Наша ИС обрабатывает 10 пакетов в минуту, но зато быстро пишет в БД. Обрабатываем первый пакет, потом сразу берем пачку, обрабатываем и быстро пишем в БД. Частый прием оптимизации.
Никаких кэшей
Кеш надо использовать правильно, тогда не будет проблем с актуальностью данных. Если придерживаться совета из статьи, то ни о каких распределенных системах и речи быть не может, это же какие накладные расходы на синхронизацию.
Используйте единственный примитив синхронизации
Какой? Все зависит от задачи. Мой сосед по общежитию как то сказал профессору на экзамене по ассемблеру: «Мой код на ассемблере никогда не будет так эффективен, как ассемблерный код, выданный компирятором». Свои велосипеды надо писать когда другие средства уже не помогают, а это, поверьте мне, бывает очень редко.
Применяйте как можно более простые алгоритмы
Конечно, все используют эффективные алгоритмы. Других просто нет. Все зависит от задачи и проблемы. Где простые алгоритмы дают приемлемую производительность, то сложные (реально сложные) алгоритмы могут дать колоссальную производительность. Обратное тоже верно.
Используйте умолчательные настройки
На старте да, это возможно, но как только начинается продуктивная эксплуатация, то ни о каких стандартных настройках и речи быть не может. Самый простой пример: у меня, как у разработчика, вся ИС размещается в 2-ух гигабайтах оперативной памяти. Вполне приемлемый объем. На сервере же, эта система запросто может занимать от 16-и гигабайт и выше. Хочешь выделить памяти виртуальной машине — задай нужный флаг. А это уже настройка.
Локальное взаимодействие ничем не отличается от удаленного
Да, классный вариант для архитектуры. Есть клиент, есть сервер. Никакой разницы, на одной машине выполняется код или на разных. Но это до поры до времени. 99% ИС это устроит. Но вот если вам надо обмениваться реально большими объемами данных, то тут и shared-memory и собственные блоки памяти, управляемые из аддона к ядру ОС и пр. шалости.
Однозначно не хватает. Уже после первого принципа начал ее искать — не нашел. Это скорее антипаттерны, но все зависит от конкретного контекста. Немного увеличить производительность — да, это может помочь. В настоящем HighLoad это антипаттерны, представленные как серебрянная пуля. Был в гостях у Елизарова на jug.ru/, объективно говорилось совершенно об обратном.
Можно посмотреть и со стороны замещения рутины, которая есть в каждой должности. Человек работал, выполнял 100% своих обязанностей. Например, 80% это была рутина и отсутствие автоматизации. 20% чистое творчество. ИИ замещает эти 80% и пытается продуцировать 20% творчества, но уже с апрувом от человека. Получается, что ИИ заберёт рутину на себя, а самые творческие и креативные могут не переживать
Именно так. Мы в шаге от, возможно, самой существеной смены наших парадигм. А дальше читаем фантастов
Безопасники нарасхват нынче. Книга по хакингу устройств позволит вспомнить специальность по диплому.
И денег за помочь семья не попросит
Спасибо
Возможность показать свою статью сразу 20к пользователям за утро раньше очень мотивировала. При публикации всегда был лёгкий мандраж
Да, есть такое :)
Спасибо за развернутый коментарий!
Есть и такое, тут тренироваться можно на коллегах, наполняя базу знаний. Правда, иногда такое понапишут...
Поддерживаю!
@tinkoff_bank, думаю, может дать комментарий без проблем
— Да, айтишник
— Да, на есть Хабре.
— Да, пишу посты
— Нет, инвайт не дам
Работает этот подход, правда, только когда сборка корректна. А то бывает такое, что некоторые разработчики начинают использовать транковые версии модулей в ветках сопровождения, но с этим мы боремся и сделали защиту выпусков в плагине.
Обычно так делают в самом начале проекта. Идеальный ORM — универсальный ORM. Когда же начинаются реально высокие нагрузки, то алгоритмы специализируются на данных. Вплоть до того, что вот из этой таблицы мы всегда извлекаем быстро N-записей, это и будет верный результат. Извлекать вот так-то очень быстро. Естественно без джоинов. Нормальные формы часто тоже становятся препятствием, но не во всей же БД делаются такие «заточки», а только в самых узких местах.
Тюнинг БД из той же оперы.
Одиночные операции вместо пакетных
Конвейер наше все. Как начал Форд их использовать, так мы и продолжаем. Те же видеокарты, имеют кучу конвейеров. Промышленные ЭВМ содержат специфические конвейеры для разных операций. Например, лучше быстро складывать числа, чем иметь универсальный модуль, но жутко медленный.
Еще пример. По сети приходят пакеты. Мы их как-то обрабатываем и пишем в БД. 100 пакетов в минуту. Наша ИС обрабатывает 10 пакетов в минуту, но зато быстро пишет в БД. Обрабатываем первый пакет, потом сразу берем пачку, обрабатываем и быстро пишем в БД. Частый прием оптимизации.
Никаких кэшей
Кеш надо использовать правильно, тогда не будет проблем с актуальностью данных. Если придерживаться совета из статьи, то ни о каких распределенных системах и речи быть не может, это же какие накладные расходы на синхронизацию.
Используйте единственный примитив синхронизации
Какой? Все зависит от задачи. Мой сосед по общежитию как то сказал профессору на экзамене по ассемблеру: «Мой код на ассемблере никогда не будет так эффективен, как ассемблерный код, выданный компирятором». Свои велосипеды надо писать когда другие средства уже не помогают, а это, поверьте мне, бывает очень редко.
Применяйте как можно более простые алгоритмы
Конечно, все используют эффективные алгоритмы. Других просто нет. Все зависит от задачи и проблемы. Где простые алгоритмы дают приемлемую производительность, то сложные (реально сложные) алгоритмы могут дать колоссальную производительность. Обратное тоже верно.
Используйте умолчательные настройки
На старте да, это возможно, но как только начинается продуктивная эксплуатация, то ни о каких стандартных настройках и речи быть не может. Самый простой пример: у меня, как у разработчика, вся ИС размещается в 2-ух гигабайтах оперативной памяти. Вполне приемлемый объем. На сервере же, эта система запросто может занимать от 16-и гигабайт и выше. Хочешь выделить памяти виртуальной машине — задай нужный флаг. А это уже настройка.
Локальное взаимодействие ничем не отличается от удаленного
Да, классный вариант для архитектуры. Есть клиент, есть сервер. Никакой разницы, на одной машине выполняется код или на разных. Но это до поры до времени. 99% ИС это устроит. Но вот если вам надо обмениваться реально большими объемами данных, то тут и shared-memory и собственные блоки памяти, управляемые из аддона к ядру ОС и пр. шалости.