Как меня достали холодные звонки!!! Да, мой номер утек в какие то маркетинговые базы а сменить его мне сложно. А теперь, благодаря вам, даже чтобы просто послать маркетолога мне нужно будет ждать и слушать рекламу.
Не понимаю, почему до сих пор ни одного комментария не пожелали вашей компании как можно быстрее заняться чем нибудь полезным или покинуть рынок.
Пожалуйста, продолжайте! Это еще один хороший обзор для новичков в авторском стиле, мне бы его не хватало в свое время для.
Кстати, если кто то считает, что тут нет ничего, что нельзя найти в других источниках, то смею заметить, что статьи для новичков такими и должны быть.
Поздно увидел статью и не смог уже ее плюсануть. Плюс улетел в карму.
Разработал в детстве (в 12 лет) на ней графический редактор
0. Рисование, копирование прямоугольных областей, заливка
1. С собственным форматом файлов (т.к. ничего не знал о bmp) в котором было собственное сжатие (ничего не знал о ЛемпелеЗиве)
2. С хранителем экрана на ассемблерной вставке (видел в NC) Т.к. на учительском компе уже не хватало оперативки на заставку, то детектил количество оперативной памяти для запуска.
Как много вещей в алгоритмистике я переоткрыл, работая над этим редактором. Именно Ямаха определила мою будущую профессию.
Вопрос: всегда интересовало, а как много энергии теряется из за стекла? Стекло не прозрачно для ультрафиолета с меньшей длинной волны (и более высокой энергией) чем видимый и инфракрасный свет. Вопрос, конечно, как много ультрафиолета в солнечном свете.
В общем, если знаете, то на сколько можно поднять КПД батареи избавившись от стекла?
Ага, Вас понял. Действительно, если на боевой вести разработку, то значительная часть проблем с поставкой — уходит.
Интересно, что у меня всю жизнь было (и есть) строго противоположное мнение: «после поставки решения на боевую систему у разработки не должно к нему быть доступа.» Возможности разработчика очень велики, и, мне кажется, сделать внутреннюю защиту от падения всей системы после исправления кода — очень сложно (невозможно).
Еще, мне кажется, в этом случае очень сложно детерминировать систему. Т.е. когда возникает плавающий баг или лаг, то когда его источник не очевиден возникает соблазн начать спрашивать всех разработчиков с пристрастием о том, кто что делал недавно на боевой системе.
И, мне кажется, подход «работаем на боевой» подходит только когда у вас ровно одна система. Т.е. когда вы автоматизируете свою компанию а не пишите код для 100 клиентов. У вас же нет боевых данных клиентов и вы не сможете зайти во все 100 систем и поправить руками данные справочника вместо централизованной поставки данных.
Или Вы нашли для последней проблемы какое то решение? Если да, то очень интересно, какое?
1. У вас ORM, значит в контроллере есть (должна быть) одна точка внесения изменений из системы. Значит реализация должна быть не очень сложной и достаточно надежной.
А вот защита от того, что разработчик или злоумышленник изменит боевую базу на прямую — ложится на плечи администратора БД. В частности, можно логировать все персональные логины в БД и какие запросы отправлял человек. А пользователя из под которого работает ORM — контролирует сама система.
Также авторитетно могу заявить, что можно добиться ситуации, когда к боевой базе у разработчиков вообще нет доступа (хотя это не просто и пару раз в году будут исключения)
2. Oracle Flashback Archive — это надстройка над ораклом. Понятно, что она может для таких запросов только создавать что то вроде транзакций на уровне изоляции «зеркалирование», внутри которых поднимать историю с помощью лога транзакций. И это ОЧЕНЬ ДОРОГО по затратам.
А если сама система параллельно будет слать информацию аудита изменений на второй сервер и там будет что нибудь типа Mongo, то будут убиты оба зайца. И разгрузится основной сервер БД и общие затраты на логирование снизятся (таже если Mongo будет стоять на том же сервере где и оракл).
При этом все затраты на разработку, это — вставить в ORM конфигурируемый механизм отправки изменений и сделать механизм просмотра изменений в системе не на SQL запросах. Дней десять разработки. Один спринт.
Но это, конечно, если у вас все изменения система осуществляет через ORM, а не так, что половина изменений пишется прямыми SQL запросами.
1. Увеличивается нагрузка на БД
Если все изменения вносятся контроллером, то необходимость триггеров на базе с данными — отсутствует. Контроллер может сам логировать все свои действия и использовать для этого НАСТРАИВАЕМЫЙ источник хранения. Например, посмотрите на какие нибудь программерские решения, вроде NLog. Т.е. я на боевом сервере настраиваю логнирование НА ДРУГУЮ БД, чтобы снизить нагрузку с основной, т.к. все данные аудита слабо связанны (не содержат ссылок на реальные объекты).
2. Не рациональное использование реляционной БД.
Если уж говорить об аудите изменений, то, как я сказал выше, он слабо связан с основными данными (т.е. может хранится в другом хранилище) и он НЕ РЕЛЯЦИОНЕН и НЕ ИЗМЕНЯЕМ. Т.е. во-первых все изменения идут мелкими, независимыми добавлениями, которые не требуют чтения данных перед записью, не требуют сложных уровней изоляции и т.д. Во вторых данные не изменяются, что можно также использовать.
Т.е. под хранение аудита изменений вместо громоздких реляционных БД можно и нужно использовать более специализированные и производительные key-value хранилища или NoSQL решения. Например, MongoDB.
И как сказано в п.1. — где хранить, на сколько подробно и как много данных, можно (нужно) конфигурировать на каждом продакшн решении.
Т.е. правильно ли я понял, общий код копируется из проекта в проект? Как вы тогда решаете проблемы поддержки общего кода в 100 решениях? И как решают проблему Ваши партнеры, если у них нет доступа к исходному коду (или все партнеры сами собирают решение из исходников?).
Спасибо за ответы! Из Ваших ответов, мне кажется, я понял, где есть интересная тема дискуссии.
На мой взгляд, один из факторов, отличающий ERP системы от, например GameDevelopment в требовании частых выпусков обновлений. Т.е. изменился процесс (например, добавили\изменили атрибуты учета товара) — изменилась система. Скорее даже наоборот, пока не изменилась система не изменился процесс.
При этом еще есть важный нюанс, ERP это софт с большим сроком поддержки кода, лет 10-15. Т.е. нужно быстро выпустить код, но потом его 10 лет поддерживать уже другой командой.
Кстати, разделяете ли Вы эти обе позиции?
По этому мне очень интересно узнать, какие достоинства у Вас есть с точки зрения обновления системы для:
1. разработчика базового решения
Например:
невысокие требования к прикладным разработчикам решения (все разработчики за 10 лет поменяются трижды),
богатый инструментарий мигрирования модели и данных (добавили новое поле, старое удалили, данные по алгоритмы мигрировали)
легкость автоматического тестирования (наличие тысячи тестов позволит сократить время выпуска версии, но если тесты писать сложно или невозможно, то этого преимущества не будет).
2. для аналитика
Например:
легкость развертывания конфигурация для тестирования (как сложно получить собственную копию боевой системы но с последними, еще не выпущенными доработками).
какие из действий, которые в других системах требуют вмешательства разработчиков, у Вас могут выполнятся аналитиками (например, в форме добавить фильтр на ссылочное поле «Сотрудник», так, чтобы можно было выбрать только сотрудников определенного отдела, ну или еще что нибудь?)
3. для бизнес пользователя
мердж данных, поставляемых из решения с пользовательскими.
Например: в классификатор товаров добавили и заполнили новую колонку с кодом соответствия другого классификатора, плюс изменили три значения. Я хочу, чтобы мои ранее сделанные изменения других 10 записей были сохранены.
Такой мердж, мне кажется, типовая задача. Хочется, чтобы аналитик без разработчика просто открыл копию системы, исправил классификатор так, как он должен выглядеть и сохранил. А при выпуске обновления данные сами смерджились на боевой системе в тех случаях, где нет коллизий в изменениях. При этом, хочется перед выпуском версии легко проверить, будут ли такие коллизии или нет, чтобы только тогда при необходимости привлечь разработчика для исправлений.
И так, что интересного у Вас есть для подготовки и выпуска обновлений?
Любопытно. Я архитектор и мы, вместе с командой разработчиков, пишем учетные системы внутри крупного финансового холдинга. А можно вопросов по задавать?
1. На чем пишут прикладные разработчики? (IDE и язык программирования).
2. Почитал про модульность и до конца не понял.
Что можно сделать в модуле? Можно и насколько широко можно его повторно использовать?
2.1 Вот могу я сделать модуль, например, который будет искать дубли в справочниках и удалять их с сохранением ссылочной целостности? Но так, чтобы потом этот модуль можно было использовать без доработок во всех решениях?
2.2 Могу ли я выпустить обновление своего модуля? Могут ли клиенты обновить в своем решении только мой модуль и ничего больше?
3. Как происходит выпуск обновлений? Могу ли я с обновлением поставлять данные?
Например, поставил я справочник. Далее пользователь вносит в него изменения (добавляя, редактируя и изменяя данные).
Теперь в очередном обновлении я также поставляю справочник с изменениями. Как мои изменения будут сливаться с изменениями пользователей?
4. Что в системе из следующего списка можно сделать на боевом проекте аналитику без привлечения программиста:
4.1 Подредактировать форму документа?
4.2 Настроить состав и порядок колонок в таблице справочника для всех пользователей?
4.3 Для пары полей «сотрудник» / «проект» добавить в форме проверку, что выбранный сотрудник входит в ранее выбранный проект.
О нет. И рейтинг ЭЛО — тот же самый и шансов у белкового шахматиста выиграть хотя бы одну из 100 партий у любой из четырех сильнейших программ www.chessbomb.com/arena/2014-tcec-s7st4 — практически отсутствует. Хотя разность в 400 очков должна давать вероятность 10% выигрыша, но для очень малых и очень больших значений рейтинга это по факту не происходит. В случае турнира Магнус наберет 10% очков на ничьих.
Вроде и тема мне интересная, и подход Ваш нравится, но статьи читаются с трудом. Особенно режут глаз «маркетинговые вставки» вроде:
Сегодня уже очень редко приходится «начинать с самого начала» и объяснять, зачем вообще нужен резервный датацентр. Сегодня, когда, с одной стороны, выросли объемы и ценность хранимой в ЦОДах информации, с другой — подешевели и получили широкое распространение многие решения для организации распределенного хранения и обработки данных, обычно уже не надо объяснять «зачем» компании нужен резервный ЦОД. Но все еще приходится смотреть на то, «как именно» и какой он нужен.
Nutanix, как компания молодая и возникшая «на острие потребностей» сразу ориентировалась на необходимость в современном датацентре иметь и резервный ЦОД, и правильную, многофункциональную репликацию.
Еще название можно было бы сделать например: «Nutanix: обзор асинхронной репликации.» или еще что нибудь говорящее.
А может быть вообще первые три абзаца с картинкой убрать? Вставить сразу первой картинкой, ту, что «номер 2»?
Удачи.
Кстати, а есть ли знающие люди в следующем вопросе: вечно в видео с визуализацией атомов и белковых стркуктур, все элементы там движутся как «управляемые». Т.е. вот в этом видео тонкая нить попала кончиком в отверстие с полуторным ее диаметром САМА.
А как это происходит в действительности?
Нельзя. Можно предположить наличие зашифрованного диска (по установленному софту TC и пустой области данных на разделе), но сколько в них контейнеров — нельзя. Таким образом, можно открыть первый контейнер, в котором содержимое второго будет просто пустой областью.
Можно ПРЕДПОЛОЖИТЬ что есть еще контейнер, но ни как доказать факт его существования и открыть его без пароля, на сколько мне известно, нельзя.
Достоверно знаю, что работают так: на момент угона ставят глушилку. Машину отгоняют и прибор, который позволяет определить примерное местоположение маяка (маяков).
Через неделю приходят и убирают все маяки.
А я вот хотел бы написать C# приложение, и чтобы оно работало в браузере.
Не понимаю, почему до сих пор ни одного комментария не пожелали вашей компании как можно быстрее заняться чем нибудь полезным или покинуть рынок.
Кстати, если кто то считает, что тут нет ничего, что нельзя найти в других источниках, то смею заметить, что статьи для новичков такими и должны быть.
Поздно увидел статью и не смог уже ее плюсануть. Плюс улетел в карму.
0. Рисование, копирование прямоугольных областей, заливка
1. С собственным форматом файлов (т.к. ничего не знал о bmp) в котором было собственное сжатие (ничего не знал о ЛемпелеЗиве)
2. С хранителем экрана на ассемблерной вставке (видел в NC) Т.к. на учительском компе уже не хватало оперативки на заставку, то детектил количество оперативной памяти для запуска.
Как много вещей в алгоритмистике я переоткрыл, работая над этим редактором. Именно Ямаха определила мою будущую профессию.
В общем, если знаете, то на сколько можно поднять КПД батареи избавившись от стекла?
Интересно, что у меня всю жизнь было (и есть) строго противоположное мнение: «после поставки решения на боевую систему у разработки не должно к нему быть доступа.» Возможности разработчика очень велики, и, мне кажется, сделать внутреннюю защиту от падения всей системы после исправления кода — очень сложно (невозможно).
Еще, мне кажется, в этом случае очень сложно детерминировать систему. Т.е. когда возникает плавающий баг или лаг, то когда его источник не очевиден возникает соблазн начать спрашивать всех разработчиков с пристрастием о том, кто что делал недавно на боевой системе.
И, мне кажется, подход «работаем на боевой» подходит только когда у вас ровно одна система. Т.е. когда вы автоматизируете свою компанию а не пишите код для 100 клиентов. У вас же нет боевых данных клиентов и вы не сможете зайти во все 100 систем и поправить руками данные справочника вместо централизованной поставки данных.
Или Вы нашли для последней проблемы какое то решение? Если да, то очень интересно, какое?
А вот защита от того, что разработчик или злоумышленник изменит боевую базу на прямую — ложится на плечи администратора БД. В частности, можно логировать все персональные логины в БД и какие запросы отправлял человек. А пользователя из под которого работает ORM — контролирует сама система.
Также авторитетно могу заявить, что можно добиться ситуации, когда к боевой базе у разработчиков вообще нет доступа (хотя это не просто и пару раз в году будут исключения)
2. Oracle Flashback Archive — это надстройка над ораклом. Понятно, что она может для таких запросов только создавать что то вроде транзакций на уровне изоляции «зеркалирование», внутри которых поднимать историю с помощью лога транзакций. И это ОЧЕНЬ ДОРОГО по затратам.
А если сама система параллельно будет слать информацию аудита изменений на второй сервер и там будет что нибудь типа Mongo, то будут убиты оба зайца. И разгрузится основной сервер БД и общие затраты на логирование снизятся (таже если Mongo будет стоять на том же сервере где и оракл).
При этом все затраты на разработку, это — вставить в ORM конфигурируемый механизм отправки изменений и сделать механизм просмотра изменений в системе не на SQL запросах. Дней десять разработки. Один спринт.
Но это, конечно, если у вас все изменения система осуществляет через ORM, а не так, что половина изменений пишется прямыми SQL запросами.
1. Увеличивается нагрузка на БД
Если все изменения вносятся контроллером, то необходимость триггеров на базе с данными — отсутствует. Контроллер может сам логировать все свои действия и использовать для этого НАСТРАИВАЕМЫЙ источник хранения. Например, посмотрите на какие нибудь программерские решения, вроде NLog. Т.е. я на боевом сервере настраиваю логнирование НА ДРУГУЮ БД, чтобы снизить нагрузку с основной, т.к. все данные аудита слабо связанны (не содержат ссылок на реальные объекты).
2. Не рациональное использование реляционной БД.
Если уж говорить об аудите изменений, то, как я сказал выше, он слабо связан с основными данными (т.е. может хранится в другом хранилище) и он НЕ РЕЛЯЦИОНЕН и НЕ ИЗМЕНЯЕМ. Т.е. во-первых все изменения идут мелкими, независимыми добавлениями, которые не требуют чтения данных перед записью, не требуют сложных уровней изоляции и т.д. Во вторых данные не изменяются, что можно также использовать.
Т.е. под хранение аудита изменений вместо громоздких реляционных БД можно и нужно использовать более специализированные и производительные key-value хранилища или NoSQL решения. Например, MongoDB.
И как сказано в п.1. — где хранить, на сколько подробно и как много данных, можно (нужно) конфигурировать на каждом продакшн решении.
На мой взгляд, один из факторов, отличающий ERP системы от, например GameDevelopment в требовании частых выпусков обновлений. Т.е. изменился процесс (например, добавили\изменили атрибуты учета товара) — изменилась система. Скорее даже наоборот, пока не изменилась система не изменился процесс.
При этом еще есть важный нюанс, ERP это софт с большим сроком поддержки кода, лет 10-15. Т.е. нужно быстро выпустить код, но потом его 10 лет поддерживать уже другой командой.
Кстати, разделяете ли Вы эти обе позиции?
По этому мне очень интересно узнать, какие достоинства у Вас есть с точки зрения обновления системы для:
1. разработчика базового решения
Например:
невысокие требования к прикладным разработчикам решения (все разработчики за 10 лет поменяются трижды),
богатый инструментарий мигрирования модели и данных (добавили новое поле, старое удалили, данные по алгоритмы мигрировали)
легкость автоматического тестирования (наличие тысячи тестов позволит сократить время выпуска версии, но если тесты писать сложно или невозможно, то этого преимущества не будет).
2. для аналитика
Например:
легкость развертывания конфигурация для тестирования (как сложно получить собственную копию боевой системы но с последними, еще не выпущенными доработками).
какие из действий, которые в других системах требуют вмешательства разработчиков, у Вас могут выполнятся аналитиками (например, в форме добавить фильтр на ссылочное поле «Сотрудник», так, чтобы можно было выбрать только сотрудников определенного отдела, ну или еще что нибудь?)
3. для бизнес пользователя
мердж данных, поставляемых из решения с пользовательскими.
Например: в классификатор товаров добавили и заполнили новую колонку с кодом соответствия другого классификатора, плюс изменили три значения. Я хочу, чтобы мои ранее сделанные изменения других 10 записей были сохранены.
Такой мердж, мне кажется, типовая задача. Хочется, чтобы аналитик без разработчика просто открыл копию системы, исправил классификатор так, как он должен выглядеть и сохранил. А при выпуске обновления данные сами смерджились на боевой системе в тех случаях, где нет коллизий в изменениях. При этом, хочется перед выпуском версии легко проверить, будут ли такие коллизии или нет, чтобы только тогда при необходимости привлечь разработчика для исправлений.
И так, что интересного у Вас есть для подготовки и выпуска обновлений?
1. На чем пишут прикладные разработчики? (IDE и язык программирования).
2. Почитал про модульность и до конца не понял.
Что можно сделать в модуле? Можно и насколько широко можно его повторно использовать?
2.1 Вот могу я сделать модуль, например, который будет искать дубли в справочниках и удалять их с сохранением ссылочной целостности? Но так, чтобы потом этот модуль можно было использовать без доработок во всех решениях?
2.2 Могу ли я выпустить обновление своего модуля? Могут ли клиенты обновить в своем решении только мой модуль и ничего больше?
3. Как происходит выпуск обновлений? Могу ли я с обновлением поставлять данные?
Например, поставил я справочник. Далее пользователь вносит в него изменения (добавляя, редактируя и изменяя данные).
Теперь в очередном обновлении я также поставляю справочник с изменениями. Как мои изменения будут сливаться с изменениями пользователей?
4. Что в системе из следующего списка можно сделать на боевом проекте аналитику без привлечения программиста:
4.1 Подредактировать форму документа?
4.2 Настроить состав и порядок колонок в таблице справочника для всех пользователей?
4.3 Для пары полей «сотрудник» / «проект» добавить в форме проверку, что выбранный сотрудник входит в ранее выбранный проект.
Еще название можно было бы сделать например: «Nutanix: обзор асинхронной репликации.» или еще что нибудь говорящее.
А может быть вообще первые три абзаца с картинкой убрать? Вставить сразу первой картинкой, ту, что «номер 2»?
Удачи.
А как это происходит в действительности?
Можно ПРЕДПОЛОЖИТЬ что есть еще контейнер, но ни как доказать факт его существования и открыть его без пароля, на сколько мне известно, нельзя.
Через неделю приходят и убирают все маяки.