А никто и не говорил о знании. Но иметь представление о том, что это и для чего, необходимо. Во-первых хороший программист должен знать несколько языков для представления о существовании разных подходов и парадигм. Зацикливаясь на одном языке, человек уже мыслит. Во-вторых для каждой задачи свой инструмент. Когда вы выбираете инструмент, знание о максимально большом количестве инструментов пригодится. Ещё раз: никто не говорит о знании на профессиональном уровне, но общее представление полезно.
Вот объясните мне, зачем делать столько манипуляций для уменьшения эффекта от ссд? Все эти переносы файла подкачки и разных кешей на HDD делают систему более тормознутой. Вы для этого ССД брали? На сколько мне известно, смерти ссд от окончания ресурса записи давно уже можно не боятся благодаря умным контроллерам и в целом прогрессу. Вы наверняка поменяете ССД по причине устаревания или общего обновления железа значительно раньше.
К сожалению тестов я не проводил. Для меня главным тестом было то, что mc-server спокойно работал на моём нетбуке с Атомом на борту с где-то 5-ю подключенными клиентами. Оригинальный сервак даже одного клиента не вытягивает на таком железе. С тех пор в mc-servere многое изменилось и он стал ещё быстрее. С буккитом к сожалению не сравнивал.
Сейчас есть люди, которые собирают mc-server для RaspberryPi. Надеятся получить играбельный сервер.
Не минусовал, но отвечу. Формат хабра — это любые новые исследования или технические детали. В этой статье вы просто сообщаете о том, что вы это сделали. При чём сначала даже не понятно, что конкретно и из какой области знаний.
Возможно я очень внимательно наблюдаю за этим проектом, но даже при ознакомлении я быстро разобрался какой нужен клиент. Сейчас поддерживается 1.2.4. Обычно поддержка последней версии появляется через пару дней после выхода. Исключением была версия 1.2.0, кода очень существенно поменялся протокол и сама игра. Поддержка Anvil (новый формат мира) пилится до сих пор. Но все эти недостатки незначительны на фоне невероятной скорости работы.
Есть ещё одно применение для ActionScript 3.0 — не вызывать конструктор предка. Если программист этого не делает руками, то компилятор подставляет этот вызов в начало конструктора, а если компилятор найдёт его даже под if(false), то сам ничего делать не будет. В итоге получаем объект, для которого не вызван конструктор предка. Костыль конечно, но иногда можно использовать.
Я не автор, но отвечу.
На сервере хранится несолёный пароль. Потом к нему приклеивается время и считается md5.
+-60 секунд только перебором +-60 паролей. По-моему не так жирно.
Главный минус, который я сейчас вижу, — несолёные пароли на сервере. Слишком легко ломается, если утащат базу.
Пожалуй, приведённый в статье способ немного безопаснее. HTTPS легко подламывается через monkey in the middle с подменой сертификата. Браузер конечно выкидывает предупреждение о странном сертификате, но это не гарантия. Здесь такое не прокатит.
Хорошая статья по хорошему вопросу.
Оставлю это здесь. Это, имхо, одна из лучших теоретических статей про инкапсуляцию. Хорошо отражает то, что вы пишете про теоретиков.
Не увидел физики вообще. Да, 3D движок красивый, но, во-первых это не имеет отношения к физическому моделированию, во-вторых не верю в то, что эта демка имеет схожие системные требования с её аналогами с классической демосцены.
Тогда покажите мне игру на флеше с уровнем физики хотя бы как в World of Goo. Таких нет. Есть множество синтетических тестов, показывающих разницу в скорости с native кодом в разы, а то и на порядки.
Ничего не имею против флеша, это отличная платформа для своих задач, но говорить о хоть каком то сравнении скорости флеша и компилируемого кода — бред.
Я правда не видел реализацию гугла, но x86 виртуальная машина может быть очень быстра и не сильно уступать нативным программам.
Интересно получилось. Как автор предыдущей статьи скажу, что у вас получилось гораздо красивее с точки зрения синтаксиса. Я, кстати, на той статье не остановился и немного развил идею . Красивее не стало, зато теперь намного безопаснее. К ваше реализации есть пара претензий:
1) Использование чисто майкрософтовских «фич», которые нарушают кроссплатформенность. В студии и так есть свои проперти.
3) Неявное задание сеттеров и геттеров, которое ещё и обязывает по-вашему называть методы.
2) Не смог до конца разобраться, но как создать readonly свойство?
У меня сейчас бродят идеи реализации на основе новшеств C++11. Лямбды вместе с std::function помогут сделать обьяления методов доступа красивее, а возможность вызывать конструкторы друг из друга — выделить инициализацию свойств в отдельный конструктор.
Нет не одному, вот человек тоже считает что это не надо. А по поводу того, что тысячу раз писалось, гуглится на эту тему не так много. А так, не плохое упражнение, а если дописать под себя, то и в реальных проектах можно использовать.
Почти по всем пунктам один вопрос: зачем? Всё что вы пишете, нужно очень небольшому числу программистов. Да и если уж вам так понадобилось всё это — реализуйте в сеттерах и геттерах, ну или расширяйте этот класс. А конкретно третий пункт, считаю не только бесполезным, но ещё и вредным. В C++ идеалогия строгой типизации, «само» приводится не должно. Компиляторы не зря варнинги кидают даже на неявное приведение float к int.
А у кого написано? У Property можно без проблем посмотреть, а у обычных полей с методами set и get кроме как по отсутствию этих самых методов ничего и не скажешь.
Сейчас есть люди, которые собирают mc-server для RaspberryPi. Надеятся получить играбельный сервер.
На сервере хранится несолёный пароль. Потом к нему приклеивается время и считается md5.
+-60 секунд только перебором +-60 паролей. По-моему не так жирно.
Главный минус, который я сейчас вижу, — несолёные пароли на сервере. Слишком легко ломается, если утащат базу.
Оставлю это здесь. Это, имхо, одна из лучших теоретических статей про инкапсуляцию. Хорошо отражает то, что вы пишете про теоретиков.
Хотя samsung бесспорно шикарен.
Ничего не имею против флеша, это отличная платформа для своих задач, но говорить о хоть каком то сравнении скорости флеша и компилируемого кода — бред.
Я правда не видел реализацию гугла, но x86 виртуальная машина может быть очень быстра и не сильно уступать нативным программам.
1) Использование чисто майкрософтовских «фич», которые нарушают кроссплатформенность. В студии и так есть свои проперти.
3) Неявное задание сеттеров и геттеров, которое ещё и обязывает по-вашему называть методы.
2) Не смог до конца разобраться, но как создать readonly свойство?
У меня сейчас бродят идеи реализации на основе новшеств C++11. Лямбды вместе с std::function помогут сделать обьяления методов доступа красивее, а возможность вызывать конструкторы друг из друга — выделить инициализацию свойств в отдельный конструктор.
Система свойств есть, но заточена она по большей части под динамическое использование через мета-объектную систему.