Мне кажется, гораздо проще построить архитектуру таким образом, чтобы клиент занимался только рендерингом и диспатчингом событий. Например, в EVE Online есть имитационный движок Destiny. На серверной стороне постоянно хранятся состояния. Когда игрок выполняет какое-то действие, на сервер отправляется команда (например, переместиться на метр вправо). Эта команда обрабатывается имитационным движком, состояния обновляются, и эти обновления (не вся куча данных сцены, а только обновлённые состояния) рассылаются всем участникам сцены. Далее, клиент делает рендеринг на основании этих состояний. Игрок стреляет — на сервере вычисляется, куда и с каким качеством прилетит его выстрел (на основании текущих состояний в имитационном движке). Ну, и так далее, по такому принципу.
Просто таким способом вы решите кучу проблем, связанных с читерством игроков. Сейчас же получается, что после решения одной проблемы (уровень урона) у вас появляется другая проблема (телепорты). Потом появится третья проблема, а за ней ещё одна, и так до бесконечности: пока вы доверяете игрокам хоть немного, они будут находить всё новые и новые способы этим доверием воспользоваться. В корне всего лежит именно доверие к игрокам. Оно будет вас принуждать наворачивать кучу кода, каждый кусок которого защищает от определённого типа читерства. В итоге, это всё выродится в монструозную конструкцию, которую будет страшно трогать и которая будет жутко тормозить в плане производительности.
Если вы избавитесь от лишнего доверия к игрокам, вы сможете сосредоточиться на других более интересных задачах. Например, на оптимизации производительности и новых фичах. Сам архитектурный подход с использованием имитационного движка будет вас защищать от читерства, и вы сэкономите в будущем кучу времени, которое иначе тратили бы на разработку защиты от конкретных его видов.
Лицензию AppCode нужно будет покупать раз в год и цена первого года $199. Потому будет дешевле $159, а потом совсем дешево — $119.
Вы немного неправильно понимаете схему лицензий JetBrains. Это цены для компаний. Такой тип лицензии позволяет одному человеку в компании использовать AppCode — без привязки к конкретному человеку.
Ещё есть тип лицензии «Personal» — человек покупает на своё имя и использует лицензию только для себя. Цены здесь ниже: 89, 71 и 53 доллара.
При определённых условиях можно получить лицензию бесплатно — нужно заниматься OpenSource. А если есть ящик в домене apache.org, проблем с бесплатной лицензией вообще не будет.
P.S. Я всё это упомянул потому, что если компания покупает лицензии, то человеку, который собирает всё это железо, будет всё равно на цену лицензии, потому что платить за неё будет не он. Если человек фрилансит и сам оплачивает оборудование и ПО, то он будет использовать personal-лицензию, которая в два раза дешевле.
Мне кажется, цель у статьи одна — пожаловаться. Об этом сигнализирует одна из меток к статье — та, которая с тремя звёздочками в середине слова. Но оформлено зачётно — акцент смещается с простой жалобы куда-то в другое место. Например, появляется желание сравнивать логотипы из примеров. И не появляется раздражение, которое обычно появляется, когда кто-то использует Хабр в качестве жалобной книги. Это самая интересно написаная жалоба, которую я видел на этом ресурсе (ИМХО, конечно же).
В это же время T. Rowe Price продолжает урезать инвестиции в свой актив: изначальные $15,8 млн превратились к 2015 году в $10,296 млн. Платформа Elance в январе 2016 года была полностью отключена от вливаний.
Если кому-нибудь всё ещё интересна эта тема, то к концу 2016-го года совокупная стоимость ценных бумаг Upwork во владении T. Rowe Price снизилась до $8,192 млн. (количество осталось тем же: 1 101 889 — Series A1, 102 917 — Series A2 и 793 184 — Series B1). Так что, за 2016-й год Upwork упала в цене примерно на 13–14% (по сравнению с концом 2015-го).
Речь шла о «значимых» проектах, чьи участники принимали участие в формировании стандарта.
Если речь шла о значимых проектах, для чего вы кидали ссылку на http://sideeffect.kr/popularconvention#php в подтверждение ваших слов про «большинство»?
И что тогда вы хотели этим сказать? :)
Я хотел сказать, что из-за невнимательности люди начинают оспаривать слова, которые я не говорил. И этим тратят моё время впустую.
Но вы же писали, что большинство так писало. Разве не так? Про то, что не нужно всех спрашивать — это уже другая опера. К тому же, если вы перечитаете мои комментарии, я нигде не утверждал, что нужно было спрашивать большинство. Я только озвучил факт, что всенародного голосования не было, и стиль брали из самых известных проектов, что на тот момент давало FIG политические очки.
А вы не обратили внимание, что там 64% — это открывающие скобки на той же строке для функций/методов? Получается противоречие с тем, что «Большинство изначально использовало такой стиль». А в случае с классами ситуация близка к 50/50.
Вы, похоже, не до конца поняли ситуацию и не видите, что после этого возникнет дублирование инфромации, которое можно будет безболезненно удалить из текста, упрощая его. :)
Вы, кстати, упустили ещё одну деталь. В первом варианте фигурная скобка иногда пишется на той же самой строке, что и закрывающая круглая для методов/функций (это есть и в PSR-2 и в PSR-12):
When the argument list is split across multiple lines, the closing parenthesis and opening brace MUST be placed together on their own line with one space between them.
Так что, случаев больше получается, чем два. А ведь можно было бы всё упростить, если, хотя бы для методов/функций, открывающая фигурная скобка писалась всегда на той же самой строке. Кучу «лишнего кода» ведь можно было бы тогда выкинуть из текста. :)
Если не сложно, поясните, что именно я путаю с единообразием? Я не совсем понял. Я путаю «выглядеть некрасиво», или я путаю «к стандарту», или что-то ещё?
И все-таки это ну никак не «архитектурная» проблема
Мне кажется, она похожа на архитектурную проблему. Всё-таки эта проблема касается совокупности факторов. Если бы речь шла просто о том, что нужно или не нужно ставить скобки на отдельной строке, это была бы не архитектурная проблема. Но раз речь идёт о том, что можно единообразно относиться к похожим явлениям, и это единообразие поможет избавиться от избыточных описаний в стандарте, то это больше похоже на архитектурную проблему.
Если вы немного внимательнее почитаете мои комментарии, вы увидите, что я нигде не призывал к всенародному голосованию. Я только отметил факт, что его не было.
А мог бы быть один: «всегда та же строка». И это было бы проще, и было бы единообразие.
Кто пишет анонимки с открывающей скобкой на следующей строке — поднимите руки.
Добавьте это в стандарт и потихоньку все начнут писать так. Будет выглядеть некрасиво из-за контекста, в котором они обычно используются, но всё равно люди будут подтягиваться к стандарту.
По-моему, PSR-12 не упрощает некоторые вещи. И основная архитектурная проблема остаётся на месте: в одних случаях у функций и классов отрывающая фигурная скобка находится на той же самой строке, в других случаях — на следующей. Можно было бы сократить и упростить структуру стандарта, если бы фигурные скобки всегда писались на той же самой строке для классов и функций/методов — вне зависимости от того, анонимные они или нет.
Просто таким способом вы решите кучу проблем, связанных с читерством игроков. Сейчас же получается, что после решения одной проблемы (уровень урона) у вас появляется другая проблема (телепорты). Потом появится третья проблема, а за ней ещё одна, и так до бесконечности: пока вы доверяете игрокам хоть немного, они будут находить всё новые и новые способы этим доверием воспользоваться. В корне всего лежит именно доверие к игрокам. Оно будет вас принуждать наворачивать кучу кода, каждый кусок которого защищает от определённого типа читерства. В итоге, это всё выродится в монструозную конструкцию, которую будет страшно трогать и которая будет жутко тормозить в плане производительности.
Если вы избавитесь от лишнего доверия к игрокам, вы сможете сосредоточиться на других более интересных задачах. Например, на оптимизации производительности и новых фичах. Сам архитектурный подход с использованием имитационного движка будет вас защищать от читерства, и вы сэкономите в будущем кучу времени, которое иначе тратили бы на разработку защиты от конкретных его видов.
Вы немного неправильно понимаете схему лицензий JetBrains. Это цены для компаний. Такой тип лицензии позволяет одному человеку в компании использовать AppCode — без привязки к конкретному человеку.
Ещё есть тип лицензии «Personal» — человек покупает на своё имя и использует лицензию только для себя. Цены здесь ниже: 89, 71 и 53 доллара.
При определённых условиях можно получить лицензию бесплатно — нужно заниматься OpenSource. А если есть ящик в домене apache.org, проблем с бесплатной лицензией вообще не будет.
P.S. Я всё это упомянул потому, что если компания покупает лицензии, то человеку, который собирает всё это железо, будет всё равно на цену лицензии, потому что платить за неё будет не он. Если человек фрилансит и сам оплачивает оборудование и ПО, то он будет использовать personal-лицензию, которая в два раза дешевле.
Это вы про Drak Net наверное, да? :)
Да, требование иметь ОС, которая ещё не вышла, — это простое требование, точно. :)
Если кому-нибудь всё ещё интересна эта тема, то к концу 2016-го года совокупная стоимость ценных бумаг Upwork во владении T. Rowe Price снизилась до $8,192 млн. (количество осталось тем же: 1 101 889 — Series A1, 102 917 — Series A2 и 793 184 — Series B1). Так что, за 2016-й год Upwork упала в цене примерно на 13–14% (по сравнению с концом 2015-го).
Да и своё собственное тоже.
Если речь шла о значимых проектах, для чего вы кидали ссылку на http://sideeffect.kr/popularconvention#php в подтверждение ваших слов про «большинство»?
Я хотел сказать, что из-за невнимательности люди начинают оспаривать слова, которые я не говорил. И этим тратят моё время впустую.
Так что, случаев больше получается, чем два. А ведь можно было бы всё упростить, если, хотя бы для методов/функций, открывающая фигурная скобка писалась всегда на той же самой строке. Кучу «лишнего кода» ведь можно было бы тогда выкинуть из текста. :)
Если не сложно, поясните, что именно я путаю с единообразием? Я не совсем понял. Я путаю «выглядеть некрасиво», или я путаю «к стандарту», или что-то ещё?
Мне кажется, она похожа на архитектурную проблему. Всё-таки эта проблема касается совокупности факторов. Если бы речь шла просто о том, что нужно или не нужно ставить скобки на отдельной строке, это была бы не архитектурная проблема. Но раз речь идёт о том, что можно единообразно относиться к похожим явлениям, и это единообразие поможет избавиться от избыточных описаний в стандарте, то это больше похоже на архитектурную проблему.
А мог бы быть один: «всегда та же строка». И это было бы проще, и было бы единообразие.
Добавьте это в стандарт и потихоньку все начнут писать так. Будет выглядеть некрасиво из-за контекста, в котором они обычно используются, но всё равно люди будут подтягиваться к стандарту.