Если для каждой задачи делать «экран», то эти полторы тысячи экранов будут довольно разношерстными. Их будут дорабатывать в разное время, разные люди с разным уровнем понимания задачи.
Ну и плюс стоимость. Сделать и ПОДДЕРЖИВАТЬ полторы тысячи экранов примерно в 100 раз сложнее чем 15.
Те люди, которые будут принимать решение об оплате захотят увидеть альтернативу. И если альтернатива — «захламленное окно», будет в 100 раз дешевле, то who cares?
Или вы не пишите системы, в которых полторы тыс. разных видов справочников и документов?
А в чем сложность то?
При изменении объекта необходимо следить за целостностью целого объекта. Поэтому хоть ты изменяешь одно поле, хоть весь объект целиком, механизму конкурентных изменений должно быть все-равно.
Допустим, у нас optimistic concurrency. В обоих случаях это будет ровно одна проверка одного поля объекта. И, конечно, это поле нужно в XML варианте, хранить не в самом XML (чтобы его чтение было дешево).
Или имелось ввиду, что при XML потребуется больший объем трафика при небольших изменениях?
Изящно :) Особенно запись заполнения по мере ввода.
Однако автор не рассматривает аспект затрат разработчика на такое создание.
Если, например, разработчик с нуля нарисует форму ну допустим на Ext.Js, и потратит на это 15 минут, то данная форма будем иметь ряд недостатков: она будет тяжеловата, там не будет автосохранения и автоподгрузки.
Но это будет хорошее решение за 15 минут, работающее во всех браузерах.
Когда форм ввода не одна а десятка три, то вопрос стоимости разработки должен остро стоять у разработчика в голове.
Интересно, а можно как-то еще уменьшить объем занимаемой позиции?
В указанном расчете, например, не учтено, что пешки могут занимать только 6 клеток. Например, чтобы сохранить позицию половины фигур на доске (16 пешек), достаточно 36 бит.
Также в указанном расчете все 24 фигуры могут быть одного цвета. А мы знаем, что это не так. Более того, есть статистика, которая могла бы быть полезна для уменьшения хранения позиции. Например, в очень незначительном количестве позиций, участвующих в реальном расчете на доске есть более 3 ферзей, 4 слонов, 4 коней или 4 ладей.
Также точно известно что королей всегда ровно два.
Крайне любопытно, на сколько компактно ЭТО можно уложить? Можно ли уложить в 128 бит?
Ну и конечно, для реальной задачи надо учесть не только расстановку фигур. В шахматах две идентичные по расстановке позиции могут отличаться тем, что есть ли у каждой из сторон возможность провести рокировку в обе стороны, и можно ли следующим ходом какую-то пешку взять на проходе.
Не верю в такую высокую эффективность.
Я не смогу отличить близнецов. С каких это пор компьютерная система распознает образы лучше человека?
Где можно посмотреть результаты исследования?
Ага. Вы из группы компаний ИВС.
Посмотрел онлайн-демо, симпатично. Разве что немного напрягает, что тормозит при изменении значений в полях формы (фильтра?) и перегружает всю страницу целиком. При этом перегружает ИНОГДА! :)
Впрочем, статья не об этом :) Вопросы по статье:
Как вы ведете документацию? Что обычно пишет разработчик по завершении задачи? Если не секрет, можно пример статьи какой-нибудь технологической фичи? Жутко любопытно.
Как пишете тесты? Сперва тест, потом код, или наоборот. В какой момент появляются новые тесты? Разработчик сам пишет тест к каждой новой фиче или на тесты ставятся отдельные задачи?
Какое соотношение технологических разработчиков и прикладных?
Здорово. Интересно бы задать пару вопросов.
А можно сперва поинтересоваться, в какой команде вы работаете? Жутко интересно, а в статье не нашел.
И еще, Вы пишете «мы (технологи)». Правильно ли я понял, что технологи, это разработчики, занимающиеся технологическим слоем?
Можно узнать, какие вы видели примеры? Серьезно, очень хотелось бы посмотреть на некоторые рабочие примеры использования ExtJs (мы сами используем). Хочется понять, что для Вас означает «безбожно тормозить».
Блин, отличный обзор!
А было бы круто, если бы была сводная таблица в конце. Типа:
Множественная сортировка: 1С-да, Остальные — нет.
Контекстное меню: 1С, Ореодор — да, Остальные — нет.
Изменение порядка колонок: — Скрытие колонок: — …
ну и т.д.
Интересно было бы посмотреть…
Так вроде и автор говорит — не храните бэкапы в CVS. Только вы, по-моему, путаете: большие бэкапы, это на рабочих базах. А тут идет речь о процессе хранения данных в процессе разработки, где нет пользовательских данных.
А. Ну это да. Хотя, идея интересная…
И комменты есть, и осмысленность у них вынужденно будет хорошей. И не приходится по два раза какие-то очевидные вещи писать, сперва в комментах, потом в тексте кнопки.
Но я бы реквеставал статью по тому, как организованна локализация.
Ну и плюс стоимость. Сделать и ПОДДЕРЖИВАТЬ полторы тысячи экранов примерно в 100 раз сложнее чем 15.
Те люди, которые будут принимать решение об оплате захотят увидеть альтернативу. И если альтернатива — «захламленное окно», будет в 100 раз дешевле, то who cares?
Или вы не пишите системы, в которых полторы тыс. разных видов справочников и документов?
При изменении объекта необходимо следить за целостностью целого объекта. Поэтому хоть ты изменяешь одно поле, хоть весь объект целиком, механизму конкурентных изменений должно быть все-равно.
Допустим, у нас optimistic concurrency. В обоих случаях это будет ровно одна проверка одного поля объекта. И, конечно, это поле нужно в XML варианте, хранить не в самом XML (чтобы его чтение было дешево).
Или имелось ввиду, что при XML потребуется больший объем трафика при небольших изменениях?
Однако автор не рассматривает аспект затрат разработчика на такое создание.
Если, например, разработчик с нуля нарисует форму ну допустим на Ext.Js, и потратит на это 15 минут, то данная форма будем иметь ряд недостатков: она будет тяжеловата, там не будет автосохранения и автоподгрузки.
Но это будет хорошее решение за 15 минут, работающее во всех браузерах.
Когда форм ввода не одна а десятка три, то вопрос стоимости разработки должен остро стоять у разработчика в голове.
В указанном расчете, например, не учтено, что пешки могут занимать только 6 клеток. Например, чтобы сохранить позицию половины фигур на доске (16 пешек), достаточно 36 бит.
Также в указанном расчете все 24 фигуры могут быть одного цвета. А мы знаем, что это не так. Более того, есть статистика, которая могла бы быть полезна для уменьшения хранения позиции. Например, в очень незначительном количестве позиций, участвующих в реальном расчете на доске есть более 3 ферзей, 4 слонов, 4 коней или 4 ладей.
Также точно известно что королей всегда ровно два.
Крайне любопытно, на сколько компактно ЭТО можно уложить? Можно ли уложить в 128 бит?
Ну и конечно, для реальной задачи надо учесть не только расстановку фигур. В шахматах две идентичные по расстановке позиции могут отличаться тем, что есть ли у каждой из сторон возможность провести рокировку в обе стороны, и можно ли следующим ходом какую-то пешку взять на проходе.
Я не смогу отличить близнецов. С каких это пор компьютерная система распознает образы лучше человека?
Где можно посмотреть результаты исследования?
Посмотрел онлайн-демо, симпатично. Разве что немного напрягает, что тормозит при изменении значений в полях формы (фильтра?) и перегружает всю страницу целиком. При этом перегружает ИНОГДА! :)
Впрочем, статья не об этом :) Вопросы по статье:
Как вы ведете документацию? Что обычно пишет разработчик по завершении задачи? Если не секрет, можно пример статьи какой-нибудь технологической фичи? Жутко любопытно.
Как пишете тесты? Сперва тест, потом код, или наоборот. В какой момент появляются новые тесты? Разработчик сам пишет тест к каждой новой фиче или на тесты ставятся отдельные задачи?
Какое соотношение технологических разработчиков и прикладных?
А можно сперва поинтересоваться, в какой команде вы работаете? Жутко интересно, а в статье не нашел.
И еще, Вы пишете «мы (технологи)». Правильно ли я понял, что технологи, это разработчики, занимающиеся технологическим слоем?
Исходя из статьи вывод можно сделать пока только такой: Использование Django ORM приводит к заметным потерям.
Ждем анализа остальных ORM.
А было бы круто, если бы была сводная таблица в конце. Типа:
Множественная сортировка: 1С-да, Остальные — нет.
Контекстное меню: 1С, Ореодор — да, Остальные — нет.
Изменение порядка колонок: — Скрытие колонок: — …
ну и т.д.
Интересно было бы посмотреть…
И комменты есть, и осмысленность у них вынужденно будет хорошей. И не приходится по два раза какие-то очевидные вещи писать, сперва в комментах, потом в тексте кнопки.
Но я бы реквеставал статью по тому, как организованна локализация.