 |
| ru |
 |
updated 06.09.11 23:55 06-09-11 @ 23:48
СэрАртём  
|
Очередной раз о**ел от кода, на котором "живёт" БК. "Шедевр" обитает по адресу /main.pl?skills=1
Разумеется, я помню, что игра написана только под один браузер.
Вот код функции:
function SaveSkill( This ) {
var sHref = "main.pl?upr=save&tmp=0.9626364283553&";
for( var i in arrChange )
if( arrChange[ i ] > 0 )
sHref += "&" + i + "=" + arrChange[ i ];
if (This) {
This.href = sHref;
} else {
document.URL = sHref;
}
return true;
}
ну и что, что этот браузер забил на стандарты? - забьём и мы! вместо того, чтобы сделать так, как принято во всём мире (изменяем или document.location.href, или window.location.href, или (на крайний случай) меняем значение атрибута src у iframe-элемента), мы присвоим значение read-only свойству URL.
Комсомольцы, блин: создаём трудности, которые потом успешно будем решать
Mood: enraged  |
Total disscussion threads: 1 Pages: 1
«« « 1 » »»
Post reply | Post reply with quote
Comment deleted Comment deleted Comment deleted
 | | СэрАртём
07-09-11 @ 03:00
Re: Re: Re: Re: |
 |
|
php - лёгкий путь. догадаешься, к чему приведёт?
никаких проблем у .NET с GC я не видел. да, в разработке встречались ситуации, когда GC не успевал освобождать память, но для этого есть принудительный запуск GC.
А что касается масштабируемости: форма делала решение на базе датацентра из 30-40 разноролевых серверов (WEB Front-end over LB, App, Cache, SQL, OLAP) - всё летало.
Однако, говорить что-либо плохое или хорошее о внутренней архитектуре системы, не зная архитектуры, нельзя. Я вижу лишь клиентский код - и делаю выводы только о нём |
 |
|
|
Comment deleted
|
|
1. возможно, это рационально при условии, когда объём памяти, необходимый для обработки запроса известен заранее.
2. веб-приложения используют объекты, время жизни которых больше, чем время выполнения запроса. эта отличие .NET от PHP меня радует больше всего
3. хочешь, чтобы все данные лежали в стеке - используй не объекты, а структуры и простые типы.
По окончании запроса измеряй объём оставшейся памяти и, если есталось меньше определённого значения, вызывай GC.
если бы это решение было оптимальным с точки зрения быстродействия, простоты поддержки и надёжности - я бы так и сделал.
на крысоцыпах ботов нет (почти нет). однако, имеем (имели) лаги по старту. причём, не в момент создания данжа, а когда игроки начинали делать первые шаги. и группа из 24 персов делала лаги на 2-3 минуты. думаю, там была проблема не в файлах.
чтобы размазать нагрузку между городами, придётся ставить несколько БД или делать несколько кешей. |
|
|
|
|
Comment deleted Comment deleted
| | СэрАртём
07-09-11 @ 13:11
Re: Re: Re: Re: Re: Re: |
|
|
+100500
хочешь войны? :)
поднимать ещё одну машину на клиенте ради вызова нескольких строк кода? - не будет этого. Java с его апплетами уже 13 лет (или хз, сколько там) не может одолеть клиентскую часть, а JS уже достаточно агрессивно выдавливает Flash. В общем, скриптовые языки умирают так же, как "умирает" БК :) |
|
|
|
|
Comment deleted
| | СэрАртём
07-09-11 @ 13:34
Re: Re: Re: Re: Re: Re: Re: Re: |
|
|
| утопия. |
|
|
|
|
Comment deleted Comment deleted Comment deleted Comment deleted Comment deleted Comment deleted Comment deleted Comment deleted Comment deleted
| | СэрАртём
09-09-11 @ 23:46
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: |
|
|
на интерфейс - это указатель на объект, реализующий этот интерфейс. и никак иначе. если разработчик счёл правильным использовать коллекцию объектов, реализующих какой-либо интерфейс, значит, так надо. и для того, чтобы вызвать метод у объекта такой коллекции, нет необходимости приводить типы или проверять наличие интерфейса: компилятор и среда исполнения не допустят, чтобы в такую коллекцию попали "левые" объекты.
коллекция объектов - это просто коллекция объектов. и разгребать эту кучу *овна тоскливо на любом языке программирования. а вот когда язык программирования не предоставляет таких возможностей, как типизированная коллекция - это печально. из-за этого при разработке многие вещи приходится дерхать в голове.
хотя, меня JS не особо напрягает |
|
|
|
|
Comment deleted
| | СэрАртём
10-09-11 @ 02:20
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: |
|
|
единственное, что я знаю, - это объект, реализующий интерфейс. любого другого там, в принципе, быть не может
ну-ну...
когда программировал на асме, объёмы кода и количество библиотек были на порядок меньше.
начиная с времён делфи использую интеллисенс - овощем, вроде, не стал |
|
|
|
|
Comment deleted
| | СэрАртём
10-09-11 @ 23:19
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: |
|
|
а мы об одном и том же говорим? я вообще-то речь вёл о современных языках, а не о порождении 80-х.
о какой строгой типизации можно говорить, когда язык позволяет делать такое: int* SomeInt = (void*)&SomeString ?
не платят за это. три года разрабатывал АТС уровня районного коммутационного узла (три типа процессоров и микроконтроллеров, включая сигнальные; две версии операционной системы с кооперативной многозадачностью - и всё это в 16К ROM + 16К RAM) - похоронили АТС, потому что проще покупать за бугром и делать крупноузловую сборку и локализовать пользовательский интерфейс. |
|
|
|
|
Comment deleted
| | СэрАртём
11-09-11 @ 23:42
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: |
|
|
с памятью? на C#? зачем? мне надо распределить гиг памяти для своих целей - буду использовать unmanaged код. всё остальное сделает .NET
их стандарты до сих пор развиваются, не спорю. однако, язык, позволяющий программисту допускать ошибки, будет всегда пользоваться меньшей популярностью, чем язык, просто не позволяющий ошибок на этапе написания кода.
с другой стороны, у языков, имеющих явные преимущества, есть шанс жить. асм, C, C#, php - это языки, у которых есть преимущества. у каждого свои. и они будут жить |
|
|
|
|
| | СэрАртём
09-09-11 @ 18:07
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: |
|
|
Нормальные языки программирования позволяют найти все вызовы конкретного метода (с конкретной сигнатурой) конкретного класса. А потом можно сделать с этим вызовом всё, что угодно: переименовать, изменить порядок передачи параметров, сделать вложенный вызов. Если парадигма языка не позволяет сделать такой финт, ни о каком автоматическом рефакторинге речи быть не может.
Я пишу на C# и использую средства рефакторинга, встроенные в IDE. Я при переименовании методов не парюсь вопросом: "Этот вызов метода Connect нужно переименовывать в ConnectPoint или это какой-то другой Connect, который связан с сокетами?" |
|
|
|
|
Comment deleted
| | СэрАртём
09-09-11 @ 23:51
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: |
|
|
и у разработчика не бывало такого, что методы разных классов назывались одинаково, хотя реализовывали абсолютно разную функциональность?
о ужас! я представляю, как называются эти методы в продукте, который разрабатывался несколькими компаниями. мне кажется, это сравнимо комментам в коде типа: /* изменено 29/02/2008 Василием Пупкиным. Исправление issue #62346
"Курсор отображается в виде стрелки, а должен быть в виде часиков" */ |
|
|
|
|
|
|
вопрос о преимуществах/недостатках этого решения открыт: возможно, оно и не такое уж плохое
сомневаюсь я, что латают... клиентский код модифицируется очень мало. и код, который был добавлен за последний год, содержит точно такие же ошибки, как и код 2-3-летней давности
|
|
|
|
|
Post reply | Post reply with quote
Total disscussion threads: 1 Pages: 1
«« « 1 » »»
|
 |
