Спасибо за ссылку.
>Each of EVE's 5000+ star systems is loaded as a separate process onto any one of hundreds of IBM blade servers, with some high-load systems being given a server all to themselves and many low-load systems being combined and run on servers together
Интересно, что здесь не говорится про облако — «Каждая из 5000+ звёздных систем загружены как отдельные процессы на одном из сотен блейд-серверов».
Я сейчас не говорю что у них плохая система (всё-таки справляется с впечатляющей нагрузкой). Но, судя по всему, «на горячую» они переносить процессы не могут, и балансируется нагрузка не в реальном времени, а по статистике — «эти 4500 систем малопосещаемые, а эти 500 — загруженные, перетасуем их вместе».
Хочу немного порассуждать об архитектуре подобной системы.
Сейчас, как я понимаю, несколько процессов обработки систем (назову их нодами) висят на одном сервере, и разделить их сложно — необходимо остановить процесс (с потерей соединений) и поднять на новой машине.
А теперь пофантазируем. Поместим все расчётные ноды в облачный кластер — отдельный процесс обработки солнечной системы (ноду) в отдельную ВМ. За счёт возможности миграции виртуальной машины на другой узел кластера без остановки самой виртуальной машины появляется куча интересных возможностей по гибкому управлению нодами — балансировка нагрузкой серверов за счёт переноса нод, освобождение мощности сервера под возросшую нагрузку одной ноды вынесением остальных с сервера.
Получится ли перенести ноду, держащую нужную систему на сервер помощнее, как миграция относится к постоянным коннектам, сохранит ли?
За какое время осуществляется миграция, и что при этом происходит с самой машиной? Замораживается на несколько секунд/минут? Продолжает работать в штатном режиме, обрабатывая запросы?
P.S. Я только начал изучать возможности виртуализации, так что если вопрос ламерский — не обессудьте…
Вот такой пример. Предметная область — транспорт.
class Transport {...}
class RoadTransport extends Transport {...}
class AirTransport extends Transport {...}
А теперь нужно добавить подтип — пассажирский транспорт и грузовой. И пошли плодить подклассы:
PassengerRoadTransport, CargoRoadTransport, PassengerAirTransport, CargoAirTransport.
Либо наоборот — от транспорта наследовать грузовой/пассажирский, и от них уже наследоваться авто/жд/воздушный:
А можно сделать трейты Cargo и Passenger, в которых реализовать специфичные реализации (виртуальных) методов.
class Bus extends RoadTransport {
use Passenger;
…
}
P.S. Если можно как-то оптимизировать структуру дерева классов без трейтов — подскажите, я что-то не соображу…
И правда, потестил сейчас оба варианта. Конкат быстрее оказывается.
Странно, потому что читал о таком способе и там убеждали в быстроте join, и тесты приводили. Я тогда не проверил сам, но запомнил. Извиняюсь, что привёл непроверенную информацию…
Кстати, интересно, что по тестам jsperf.com/concat-vs-join444/2 в некоторых браузерах join всё-таки быстрее. Но в остальных браузерах настолько медленнее, что небольшое превосходство в некоторых браузерах не окупится.
Вот мой тест: jsperf.com/concat-vs-join445
Интересно то, что при повышении объема данных join становится хуже и хуже…
Быстрее будет не складывать строчки, а складывать их в массив и потом join-ить:
var html = [];
for (var i=0; i<100; i++) {
html.push('<div>');
html.push(i);
html.push('</div>');
}
$('#div').append(html.join(''));
Операция join быстрее срабатывает, чем множество +
Спасибо за проделанную работу! Интересный класс получается.
Хотелось бы всё-таки сравнение скорости для вашего класса, DbSimple и PDO. DbSimple ругают за медлительность (по крайней мере, кое-где видел).
Сам использую DbSimple, очень нравится, «магия» в возвращаемом значении select() не пугает.
Да, но Новый Русский влил «кучу миллионов денег», и ему весь дом за год сделали. А свой, бесспорно, красивый дом работящая семья всю жизнь строила. И не удивлюсь, если вас, въехавшего на денёк-другой, тоже попросят прикрутить что-нибудь к их дому.
И ведь оба подхода имеют право на существование, нельзя сказать, что какой-то подход априори лучше. Но строить бизнес на втором подходе? Не стоит.
Интересно было бы календарное — сколько затрачено времени от общего времени проекта, в какой момент начали и когда закончили. Понятно, что программист всё время работал. Но вот другие работы были начаты в определённый момент и закончены в определённый.
Например, «музыку мы начали делать за месяц до релиза (даты, когда в начале думали делать релиз:), продлилось 3 недели».
Подобная инфа была бы не менее ценной, чем по затратам.
Тот же Badoo часто проводит на различных конференциях мастер-классы по хай-лоад. Проводит Алексей Рыбак. Я был в этом году на PHPConf, превосходный семинар (на весь день почти). Очень рекомендую посетить при возможности — не пожалеете нисколько. На самом деле крутая инфа, разжёванно и понятно.
Интересно. Такая фишка дополненной реальности Юрий Никитин описал в «Трансчеловеке» (2006 года роман). Я тогда был в восторге от тех идей, а сейчас они уже начали воплощаться потихоньку.
А почему нет? Я кликнул на ссылку — и мне приятно (10ГБ вместо 5), и человеку хорошо. Благотворительность.
К тому же автор сам благословил (сейчас уже убрал эту фразу).
P.S. Я свою не размещал (хотя, может, и стоило...)
Странный список разрешённых символов в пароле на сайте:
>only contain numbers and the characters a-z or the following special characters: # $ + =., _ — Странно то, что не разрешают вполне безобидные !@%&*()
С другой стороны, тест unitCanTakeDamage тестирует не только наличие метода, но и фиксирует его интерфейс, и если вдруг кто-то добавит ещё один параметр к методу, то тест непременно упадёт, и сразу будет понятно, в чём именно дело. Что довольно ценно, на мой взгляд.
Увидел в начале комментария слово «Agile», и подумал, что он будет в поддержку тестирования. Наверное, я совсем не понимаю, что такое Agile. Как можно практиковать Agile без тестирования? Agile ведь подразумевает, что код будут рефакторить?.. Или вы просто упомянули Agile, но сами его не практикуете?
Да, я знаю, что в манифесте Agile нет про тестирование, но не понимаю, как можно строить процесс разработки, основанный на непрерывном рефакторинге, без использования тестов. Сам я в тех моментах, где приходится делать рефакторинг, уже сильно запарился ручками проводить тесты, и всё-равно вылезают баги. На собственном опыте убедился в необходимости тестирования.
Спасибо за хорошую статью! Просто, но понятно, и задаёт направление для дальнейшего развития. Я сам пока только примеряюсь к юнит-тесированию, и тоже хочу попробовать начать с чего-то такого вот.
Я бы пару тестов объединил в один, например, unitCanTakeDamage и damageTakenReducesUnitHealth. Не понимаю, зачем отдельный первый тест? Он же тестирует только наличие метода takeDamage(), но не его работу. Второй тест проверит и то и другое. Не будет ли разделение на два отдельных теста чрезмерным стремлением затестировать всё подряд? Или именно в этом и заключается TDD? У того же Кента Бека во всех тестах есть assert-ы.
Интересно, что в комментариях больше говорили о тестировании в целом, чем о примере применения тестирования в статье, нет комментариев по делу от гуру TDD. А именно этого просил автор, и хотел бы увидеть и я.
>Each of EVE's 5000+ star systems is loaded as a separate process onto any one of hundreds of IBM blade servers, with some high-load systems being given a server all to themselves and many low-load systems being combined and run on servers together
Интересно, что здесь не говорится про облако — «Каждая из 5000+ звёздных систем загружены как отдельные процессы на одном из сотен блейд-серверов».
Я сейчас не говорю что у них плохая система (всё-таки справляется с впечатляющей нагрузкой). Но, судя по всему, «на горячую» они переносить процессы не могут, и балансируется нагрузка не в реальном времени, а по статистике — «эти 4500 систем малопосещаемые, а эти 500 — загруженные, перетасуем их вместе».
Сейчас, как я понимаю, несколько процессов обработки систем (назову их нодами) висят на одном сервере, и разделить их сложно — необходимо остановить процесс (с потерей соединений) и поднять на новой машине.
А теперь пофантазируем. Поместим все расчётные ноды в облачный кластер — отдельный процесс обработки солнечной системы (ноду) в отдельную ВМ. За счёт возможности миграции виртуальной машины на другой узел кластера без остановки самой виртуальной машины появляется куча интересных возможностей по гибкому управлению нодами — балансировка нагрузкой серверов за счёт переноса нод, освобождение мощности сервера под возросшую нагрузку одной ноды вынесением остальных с сервера.
Получится ли перенести ноду, держащую нужную систему на сервер помощнее, как миграция относится к постоянным коннектам, сохранит ли?
За какое время осуществляется миграция, и что при этом происходит с самой машиной? Замораживается на несколько секунд/минут? Продолжает работать в штатном режиме, обрабатывая запросы?
P.S. Я только начал изучать возможности виртуализации, так что если вопрос ламерский — не обессудьте…
class Transport {...}
class RoadTransport extends Transport {...}
class AirTransport extends Transport {...}
А теперь нужно добавить подтип — пассажирский транспорт и грузовой. И пошли плодить подклассы:
PassengerRoadTransport, CargoRoadTransport, PassengerAirTransport, CargoAirTransport.
Либо наоборот — от транспорта наследовать грузовой/пассажирский, и от них уже наследоваться авто/жд/воздушный:
А можно сделать трейты Cargo и Passenger, в которых реализовать специфичные реализации (виртуальных) методов.
class Bus extends RoadTransport {
use Passenger;
…
}
P.S. Если можно как-то оптимизировать структуру дерева классов без трейтов — подскажите, я что-то не соображу…
Странно, потому что читал о таком способе и там убеждали в быстроте join, и тесты приводили. Я тогда не проверил сам, но запомнил. Извиняюсь, что привёл непроверенную информацию…
Кстати, интересно, что по тестам jsperf.com/concat-vs-join444/2 в некоторых браузерах join всё-таки быстрее. Но в остальных браузерах настолько медленнее, что небольшое превосходство в некоторых браузерах не окупится.
Вот мой тест: jsperf.com/concat-vs-join445
Интересно то, что при повышении объема данных join становится хуже и хуже…
var html = [];
for (var i=0; i<100; i++) {
html.push('<div>');
html.push(i);
html.push('</div>');
}
$('#div').append(html.join(''));
Операция join быстрее срабатывает, чем множество +
Хотелось бы всё-таки сравнение скорости для вашего класса, DbSimple и PDO. DbSimple ругают за медлительность (по крайней мере, кое-где видел).
Сам использую DbSimple, очень нравится, «магия» в возвращаемом значении select() не пугает.
Теперь бы ещё на Fabric.js версию… Может, kangax сделает?..
P.S. Как вам «Хоббит»? :)
И 2d, и 3d. Феерично! Но css-кода там много…
И ведь оба подхода имеют право на существование, нельзя сказать, что какой-то подход априори лучше. Но строить бизнес на втором подходе? Не стоит.
Например, «музыку мы начали делать за месяц до релиза (даты, когда в начале думали делать релиз:), продлилось 3 недели».
Подобная инфа была бы не менее ценной, чем по затратам.
А можно в таблицу с суммами ещё колонку с потраченным временем добавить?
Весь интернет не стоит жизни одного ребёнка, убитого педофилом.
К тому же автор сам благословил (сейчас уже убрал эту фразу).
P.S. Я свою не размещал (хотя, может, и стоило...)
>only contain numbers and the characters a-z or the following special characters: # $ + =., _ — Странно то, что не разрешают вполне безобидные !@%&*()
Да, я знаю, что в манифесте Agile нет про тестирование, но не понимаю, как можно строить процесс разработки, основанный на непрерывном рефакторинге, без использования тестов. Сам я в тех моментах, где приходится делать рефакторинг, уже сильно запарился ручками проводить тесты, и всё-равно вылезают баги. На собственном опыте убедился в необходимости тестирования.
Я бы пару тестов объединил в один, например, unitCanTakeDamage и damageTakenReducesUnitHealth. Не понимаю, зачем отдельный первый тест? Он же тестирует только наличие метода takeDamage(), но не его работу. Второй тест проверит и то и другое. Не будет ли разделение на два отдельных теста чрезмерным стремлением затестировать всё подряд? Или именно в этом и заключается TDD? У того же Кента Бека во всех тестах есть assert-ы.
Интересно, что в комментариях больше говорили о тестировании в целом, чем о примере применения тестирования в статье, нет комментариев по делу от гуру TDD. А именно этого просил автор, и хотел бы увидеть и я.