У каждого программиста в процессе роста формируется свой собственный набор решений тех или иных задач. Поэтому посмотреть, как выполняется какая-то задача, в каком-то фреймоворке и сделать так же у себя — это полезное занятие.
Я разбирал работу не одного фреймворка, многое переписывал под себя. Да, и про исходники на десятки мегабайт Вы явно загнули.
Почитал вдумчиво предыдущие ответы… Бред какой-то Вам советуют.
Вы тупо перегораете на работе, не успеваете отдохнуть и напряжение накапливается.
Всякие медитации, гитары, хобби, обсуждения и журналы требуют времени (при чём часто ежедневно), которого скорее всего у Вас нет. То есть сразу отпадают.
Физические занятия хороши, т.к. можно во время занятий думать о проекте. У Вас в этом случае есть своеобразный контроль: думать о проекте или сбрасывать напряжение. Но после рабочего дня весьма проблематично заставить себя физически заниматься + всё равно требуется время.
Поэтому я предпочитаю принимать карнитин-L, который позволяет мне быть в рабочем состоянии 14 часов вместо 10.
Тоже присоединяюсь — Asus Transformer.
При активной(!) работе даже с док станцией (она имеет дополнительный аккумулятор) на два дня не хватит, но на день хватит точно.
Alt + Перетаскивание
Не уж то это так сложно? Или Вы написали это, потому что не умеете работать с Gimp.
p.s.
Давайте не продолжать этот бессмысленный спор — есть области, в которых Photoshop превосходит Gimp, и есть области, в которых Gimp превосходит Photoshop.
Вы не правильно меня понимаете.
Допустим у нас поединок между 2 игроками. При загрузке страницы мы имеем данные об обоих игроках. Один игрок атакует другого. На клиенте производится расчёт может ли он это сделать и как он это сделает. Если он это может сделать, то только тогда отправляется запрос. Сервер принимает этот запрос, проверяет может ли игрок выполнить это действие по тем же алгоритмам что и на клиенте (как он это сделает неважно), производит расчёт результата или подтверждает действие, ставит результат в очередь рассылки всем игрокам. И т.д.
Разница в том, что:
— Лишние запросы не делаются;
— Расчётов на сервере, как выполнить действие, нет.
Весьма странно. Рассинхронизацию можно получить, если клиент действует без подтверждения действия сервера. Подозреваю, что Вы слабо представляете, как действует толстый клиент.
«Просто такими рассуждениями любая задача сведется лишь к 1/2/5/50 запросам к БД»
— Не больше 5 запросов. У пошаговых игр логика простая.
«В моем случае клиент запрашивал состояние объекта, например противника в бою, и получал в ответ json с необходимыми характеристиками, на основе которого на клиенте отображалось состояние объекта»
— Зачем? Почему бы просто перед началом боя не передать все необходимые данные и далее передавать только изменения (если они вообще есть)?
По поводу подходов:
Вижу тут нарастает спор «Тонкий клиент против толстого клиента». Мои аргументы в пользу толстого клиента:
— Удобно производить отладку и разработку, т.к. всё видно на клиенте.
— Меньше запросов.
— Двойная проверка данных.
damirazo, Вы называете сложным: 2 запроса к базе, сравнение результатов с сессиоными данными и формирование ответа на основе этого?
Это элементарные действия. На клиенте происходят (должны происходить) точно такие же действия + отрисовка.
Fally, а ваша ММОРПГ браузерная? Потому что тонкий клиент используют, по моим наблюдениям, только в играх с отдельными приложениями, либо люди делавшие такие игры.
На сервере аналогичная проверка данных, что и на клиенте. Соответственно сначала пишется проверка данных на клиенте (т.к. удобно производить отладку), а потом дублируется на сервере. Переписать код с одного ЯП на другой не составляет сложности. Поэтому сложность разработки серверной части браузерной игры низкая и сводиться к элементарным действиям.
taliban, здесь дело в часах, выделенных на курс.
Обычно дают 60-80 часов (у автора гораздо больше, поэтому к нему это не относиться). Из этих часов 10-40 уходит на базовое знакомство с языком. Поэтому на нормальное изучение более современных языков, включающих в себя большое количество понятий и функций, времени не остаётся. Перед преподавателем в итоге стоит выбор — либо начать с простого Pascal и успеть изучить побольше алгоритмов, либо поверхностно изучить более современный ЯП.
Питон сложнее в восприятии, чем Паскаль. Хотя спор этот уже пустой — у автора 130+60 часов на курс. За такое время можно любой язык довольно хорошо изучить.
Я разбирал работу не одного фреймворка, многое переписывал под себя. Да, и про исходники на десятки мегабайт Вы явно загнули.