Хорошо продуман выбор уровня, меню, ненавязчивое обучение вначале.
Графика на двойку. Вот хотя бы для примера поставьте рядом:
Сразу видны недоделки:
— задний фон не должен быть таким заметным;
— «замыленность» графики — это плохо, она никому не нужна, кроме неумелого художника;
— монстр не должен быть отталкивающим; он должен быть симпатичным ублюдком; сейчас он напоминает страдающего непроходимостью кишечника колобка (уж извините);
— опять-таки монстр и другие объекты должны выделяться по-разному; посмотрите как в birds — для монстров используется черная окантовка и это ненавязчиво отделяет их от других игровых объектов переднего плана.
И т.д. Короче не пренебрегайте графикой в играх! :-)
На рисунке в статье ширина блока first (от которой считается 30% вложенного блока) указана голубоватой стрелкой как расстояние от левого края блока до правого.
Но это неверно. Ширина блока не включает отступы (говорим про обычный, не quirks, режим).
Ширина блока в модели W3C это ширина content (без padding).
Типа картинка, связанная с каждой буквой, интерактив, простейшие слова, какие-то ассоциации.
Чтобы буква «произносилась», когда в нее «тыкали» и что-то в этом роде.
Какие-то минимальные элементы игры, связанные с каждой буквой: «заливка» форм краской, складывание букв из кирпичиков.
Как логините пользователей? SSL используете? Куда бекапитесь и как часто? Как следите за загрузкой сервера (мониторинг)? Как боретесь с роботами при регистрации? Насколько сложно было прикрутить робокассу?
Накладные расходы на запись/чтение level с лихвой компенсируются простотой кода — то есть малыми размерами — то есть скоростью. Я для интереса нашел реализацию AVL на Delphi и сравнивал, AVL отставал на 10-20%. Понимаю, что утверждение, что АА-дерево всегда быстрее AVL требует более строгих тестов, тем не менее в моих тестах оно было быстрее.
level это дополнительные 4 байта на вершину. Но, вообще говоря, не думаю, что в реальности можно столкнуться с деревьями, глубина которых превышает 256, ведь тогда кол-во элементов будет примерно 2^256 (что довольно много :-) ). Так что можно ограничиться одним байтом.
Что касается копирования узлов — его можно избежать, введя указатель на parent и меняя исходные ссылки на вершины (а не сами вершины).
Я буду рад сравнить скорость Вашей самой быстрой реализации AVL-дерева с AA-деревом.
Уровень вершины — это некая вспомогательная величина, которая есть у каждой вершины и листовая вершина получает вначале в качестве 1. Далее уровень меняется при балансировке таким образом, что всегда в АА-дереве две вершины одного уровня связаны только правой связью.
Это и есть определение «уровня вершины», это понятие нельзя выразить в виде высоты или еще как-то.
Скобки не нужны. Регулярку можно упростить еще сильней. Суть не в этом, а в том, что Вы можете это выражение взять из другой части кода. Где оно реально что-то выделяло. И забыть убрать флаг global.
И получить эту трудноотлавливаемую проблему.
Почти все системы баз данных, которые мы используем, являются реляционными, такие как Oracle, SQL Server, MySQL, Sybase, DB2, TeraData и так далее.
Причины такого доминирования неочевидны.
… автору статьи. Потому что остальные знают про язык SQL, который и явился причиной взрывного роста РСУБД.
На протяжении всего существования реляционных БД они постоянно предлагали наилучшую смесь простоты, устойчивости, гибкости, производительности, масштабируемости и совместимости в сфере управлении данными.
Однако чтобы обеспечить все эти особенности, реляционные хранилища невероятно сложны внутри.
Что это за аргумент — «сложно устроен внутри»? А с чего устройство-то должно быть простым?
Потому что автор дебиловат и не может понять?
Хотя реляционные хранилища и обеспечивают наилучшую смесь простоты, устойчивости, гибкости, производительности, масштабируемости и совместимости
А где, соб-но, доказательства этого утверждения?
Это означает, что данные, как правило, дублируются между разными доменами. Это приемлемый подход, поскольку дисковое пространство дешево. Главное, что он позволяет все связанные данные хранить в одном месте, что улучшает масштабируемость, поскольку исчезает необходимость соединять данные из различных таблиц. При использовании реляционной БД, потребовалось бы использовать соединения, чтобы сгруппировать в одном месте нужную информацию.
Конечно, конечно, только из-за дисков и нормализуют базы.
Как насчет целостности и достоверности?
Если у нас 13 копий одной и той же записи счета клиента с разными значениями суммы на счете — чо делаем?
Случайно выбираем одну, остальные удаляем?
Первое преимущество хранилищ типа ключ-значение состоит в том, что они проще, а значит обладают большей масштабируемостью, чем реляционные БД.
Автор статьи наивно умолчал проблемы, связанные с распределенным хранением данных.
Он как бы подразумевает, что если я разложу записи с ключами по разным серверам,
то это автоматически ХОРОШО и решило все проблемы.
Ага, конечно.
Проблемы-то никуда не ушли, наоборот, только увеличились. Транзакционность? Достоверность? Распространение обновлений? Гарантия непротиворечивости?
Ну и напоследок, делаем NOSQL.
Берем SQLITE. Ну или другую БД, не суть.
CREATE TABLE NOSQL(key int not null primary key autoincrement, obj text not null)
Delphi не умер, он вполне жив. Skype под Windows написан на Delphi. Это о чем-то говорит, разве нет?
Если стоит задача сделать небольшое приложение под Windows с интерфейсом, то Delphi вне конкуренции, ИМХО. Удобный дизайнер, много готовых компонентов. Синтаксис языка Delphi менее запутан, чем C++: программы выглядят «стройнее». Фантастическая скорость компиляции. Довольно эффективный код. Отличная IDE со множеством расширений.
«Говноформы» получаются, в основном, из-за простоты внесения кода в код самой формы. Delphi навязывает эту концепцию (например, создавая обработчики событий). В результате, View тесно сливается с Model. В маленьких проектах это неважно. Однако, никто не обязывает это делать в больших проектах.
Беда в том, что вектор развития Delphi был как-то… потерян что-ли… Возобладали какие-то странные стремления (наверное, маркетинговые). К примеру, в Delphi в стандартной библиотеке так и не появился аналог STL map, то есть полноценный набор пар имя-значение (полноценный, в смысле, с производительностью O(log(N)) ). Зато появилась масса ненужных компонент, бессмысленное портирование под Linux, «дружба» с .Net и т.д.
Мне кажется, нужно было развивать Delphi, как «вещь в себе», как платформу — дополнять его библиотеку средствами шифрования, работой с XML, регулярными выражениями, сетевыми возможностями и пр. и пр. Причем нужно было делать это аккуратно, системно.
Вообще, Delphi нужно любить. В умелых руках это чрезвычайно мощный инструмент. И большое сообщество в Сети это подтверждает. А если начать разбирать достоинства по пунктам, то всегда найдется лучший аналог :-)
Система объектов, которая что-то делает, является тем же классом. Только с более сложным поведением. То есть ее состояние теперь разделено между разными объектами. Но для использования этой системы это знать не нужно.
Если я неправ в сценарии, укажите — где? Если я допустил некорректный вывод, опять-таки, поясните.
Фраза «не нравится виджеты — отключите» как раз весьма характерна, не находите?
Она означает, что без них вполне можно жить…
Могу попробовать ответить на вопросы, если у кого возникнут :)
Хорошо продуман выбор уровня, меню, ненавязчивое обучение вначале.
Графика на двойку. Вот хотя бы для примера поставьте рядом:
Сразу видны недоделки:
— задний фон не должен быть таким заметным;
— «замыленность» графики — это плохо, она никому не нужна, кроме неумелого художника;
— монстр не должен быть отталкивающим; он должен быть симпатичным ублюдком; сейчас он напоминает страдающего непроходимостью кишечника колобка (уж извините);
— опять-таки монстр и другие объекты должны выделяться по-разному; посмотрите как в birds — для монстров используется черная окантовка и это ненавязчиво отделяет их от других игровых объектов переднего плана.
И т.д. Короче не пренебрегайте графикой в играх! :-)
padding: 100px;?
На рисунке в статье ширина блока first (от которой считается 30% вложенного блока) указана голубоватой стрелкой как расстояние от левого края блока до правого.
Но это неверно. Ширина блока не включает отступы (говорим про обычный, не quirks, режим).
Ширина блока в модели W3C это ширина content (без padding).
Типа картинка, связанная с каждой буквой, интерактив, простейшие слова, какие-то ассоциации.
Чтобы буква «произносилась», когда в нее «тыкали» и что-то в этом роде.
Какие-то минимальные элементы игры, связанные с каждой буквой: «заливка» форм краской, складывание букв из кирпичиков.
Не думали о таком проекте?
level это дополнительные 4 байта на вершину. Но, вообще говоря, не думаю, что в реальности можно столкнуться с деревьями, глубина которых превышает 256, ведь тогда кол-во элементов будет примерно 2^256 (что довольно много :-) ). Так что можно ограничиться одним байтом.
Что касается копирования узлов — его можно избежать, введя указатель на parent и меняя исходные ссылки на вершины (а не сами вершины).
Я буду рад сравнить скорость Вашей самой быстрой реализации AVL-дерева с AA-деревом.
Это и есть определение «уровня вершины», это понятие нельзя выразить в виде высоты или еще как-то.
Это как бы переменная условия-инварианта.
На рисунке после выполнения операции split:
R.level = X.level + 1 = T.level + 1 = A.level + 2 = B.level + 2
То есть разбалансировка (две правые связи) решается добавлением нового уровня и перегруппировкой.
И получить эту трудноотлавливаемую проблему.
И потом не так уже часто в этом блоге статьи пишутся, разве нет?
Почти все системы баз данных, которые мы используем, являются реляционными, такие как Oracle, SQL Server, MySQL, Sybase, DB2, TeraData и так далее.
Причины такого доминирования неочевидны.
… автору статьи. Потому что остальные знают про язык SQL, который и явился причиной взрывного роста РСУБД.
На протяжении всего существования реляционных БД они постоянно предлагали наилучшую смесь простоты, устойчивости, гибкости, производительности, масштабируемости и совместимости в сфере управлении данными.
Однако чтобы обеспечить все эти особенности, реляционные хранилища невероятно сложны внутри.
Что это за аргумент — «сложно устроен внутри»? А с чего устройство-то должно быть простым?
Потому что автор дебиловат и не может понять?
Хотя реляционные хранилища и обеспечивают наилучшую смесь простоты, устойчивости, гибкости, производительности, масштабируемости и совместимости
А где, соб-но, доказательства этого утверждения?
Это означает, что данные, как правило, дублируются между разными доменами. Это приемлемый подход, поскольку дисковое пространство дешево. Главное, что он позволяет все связанные данные хранить в одном месте, что улучшает масштабируемость, поскольку исчезает необходимость соединять данные из различных таблиц. При использовании реляционной БД, потребовалось бы использовать соединения, чтобы сгруппировать в одном месте нужную информацию.
Конечно, конечно, только из-за дисков и нормализуют базы.
Как насчет целостности и достоверности?
Если у нас 13 копий одной и той же записи счета клиента с разными значениями суммы на счете — чо делаем?
Случайно выбираем одну, остальные удаляем?
Первое преимущество хранилищ типа ключ-значение состоит в том, что они проще, а значит обладают большей масштабируемостью, чем реляционные БД.
Автор статьи наивно умолчал проблемы, связанные с распределенным хранением данных.
Он как бы подразумевает, что если я разложу записи с ключами по разным серверам,
то это автоматически ХОРОШО и решило все проблемы.
Ага, конечно.
Проблемы-то никуда не ушли, наоборот, только увеличились. Транзакционность? Достоверность? Распространение обновлений? Гарантия непротиворечивости?
Ну и напоследок, делаем NOSQL.
Берем SQLITE. Ну или другую БД, не суть.
CREATE TABLE NOSQL(key int not null primary key autoincrement, obj text not null)
В obj заносим JSON объекта.
Скорость выборки? Фантастическая.
Масштабируемость? Для SQLITE, см. www.sqlite.org/limits.html
Транзакционность? Осталась.
SQL? Полноценный, остался.
Фсе, построили NOSQL. Расходимся.
Если стоит задача сделать небольшое приложение под Windows с интерфейсом, то Delphi вне конкуренции, ИМХО. Удобный дизайнер, много готовых компонентов. Синтаксис языка Delphi менее запутан, чем C++: программы выглядят «стройнее». Фантастическая скорость компиляции. Довольно эффективный код. Отличная IDE со множеством расширений.
«Говноформы» получаются, в основном, из-за простоты внесения кода в код самой формы. Delphi навязывает эту концепцию (например, создавая обработчики событий). В результате, View тесно сливается с Model. В маленьких проектах это неважно. Однако, никто не обязывает это делать в больших проектах.
Беда в том, что вектор развития Delphi был как-то… потерян что-ли… Возобладали какие-то странные стремления (наверное, маркетинговые). К примеру, в Delphi в стандартной библиотеке так и не появился аналог STL map, то есть полноценный набор пар имя-значение (полноценный, в смысле, с производительностью O(log(N)) ). Зато появилась масса ненужных компонент, бессмысленное портирование под Linux, «дружба» с .Net и т.д.
Мне кажется, нужно было развивать Delphi, как «вещь в себе», как платформу — дополнять его библиотеку средствами шифрования, работой с XML, регулярными выражениями, сетевыми возможностями и пр. и пр. Причем нужно было делать это аккуратно, системно.
Вообще, Delphi нужно любить. В умелых руках это чрезвычайно мощный инструмент. И большое сообщество в Сети это подтверждает. А если начать разбирать достоинства по пунктам, то всегда найдется лучший аналог :-)
ООП — это не возможности языка, это архитектура приложения.