Хм… Есть пара интересных инструментов. Нужно будет посмотреть что еще они сделали, особенно с их ORM.
Я уже довольно долго использую CakePHP 2.x, но ограничил его применение небольшими проектами из-за излишней магии, которую нельзя отключить не поменяв код фреймворка, что в итоге и пришлось сделать =( С того момента я поставил на CakePHP крест. До сих пор его использую только из-за того, что у меня на нем уже куча наработок для несложных сайтов и все-равно периодически матерю его магию (мыши плакали, кололись, но продолжали жрать кактус).
Пока я склоняюсь к Symfony — мне понравилось как он устроен. Достаточно ненавязчиво, хотя и посложнее чем CakePHP.
он зарегистрировал домен hmcts-gsi-gov.org.uk — тайпсквоттинг от hmcts.gsi.gov.uk
…
Затем Нил Мур с этого домена отправил на адрес тюрьмы поддельное письмо с указанием отпустить его на свободу
Это скорее дыры в протоколе «Внимательность и Знание» у служащих.
Детские примеры только потому, что они чаще всего играют важную роль т.к. частенько вылезают боком.
Партиционирование для postgresql нужно немного допилить напильником чтобы оно было автоматизированным, но зато есть гибкость настройки. У mysql список ограничений больше всей остальной документации по партиционированию. Уж не знаю насколько ограничения критичны, но их многовато и их нужно все знать чтобы грабли не дали по лобешнику.
Еще полезно знать и использовать типы транзакций ибо deadlockи никому не нужны.
С having да, проблемка. Не знаю точно причины почему так, но предполагаю, что проблема с производительностью.
На своем опыте с myslq я страдал намного чаще чем с postgresql. Возможно причина в том, что учили меня использовать стандартный sql (использовали interbase), который чуть что не так — плюется ошибкой, и я по инерции ожидал такого поведения от mysql, но не тут-то было =)
Хотя я mysql до сих пор использую, но не делаю на нем ничего сложнее простых сайтов с 8-12 таблицами в БД. В таких случаях он все же лучшее решение. Хотя все-равно страхую кешированием =)
Ок. Не прошло и 10 лет =)
Все-равно яблоко от яблони далеко не падает =) mysql сама по себе сделана вопреки стандартам языка sql, так что научить ее чему-то реально полезному сложно.
К примеру, задав поле как int(11), вы можете вставить туда текст
По хорошему одно приложение (одна логика, много инстансов) должна работать со «своими» данными и предоставлять апи всем остальным.
Оно так и будет, но только когда вы обнаружите эту ошибку =) Мое мнение такое — если пришла непонятная или неожидаемая фигня, то приложение должно упасть, известив вас о произошедшем. Тогда тупые ошибки по недосмотру вылавливаются моментально, а не после часа поисков. И вот тут жесткая типизация postgresql приходит вам на помощь
Вот уж не думаю что после миграции на mysql из mongo они бы получили прирост к производительности =)
Зато они получили такой набор функционала от postgresql, что они вполне могут довольно сильно поднять производительность.
Минусы mysql можно долго описывать и уже не раз это делалось.
Например, для меня самые главные минусы: нежесткая типизированость и отсутствие адекватного планировщика запросов. Как следствие, например, order by по 2м индексированным полям в разы дольше чем order by по 1 полю + сортировка в коде и многое другое чем postgresql не страдает. А уж что еще умеет postgresql, того в mysql никогда и не будет, скорее всего.
Ах да, я забыл про пляски с бубном при настройке mysql =)
По факту лучше 1 раз разобраться с postgresql и получать profit чем страдать с mysql.
Это да. Хотя учитывая силу с которой нужно погнуть тот пропеллер (он только немного погнулся при падении, а там удар был сильный), думаю что другой дрон просто не сможет этого сделать или по крайней мере нужно будет приложить много усилий для этого. Но это все догадки.
Насколько видно на одном из видео — после падения с большой высоты он просто поправил лопость пропеллера и дрон без проблем полетел дальше. Вероятно уже есть или планируется и защитный каркас для пропеллеров. По сути заменить пропеллер не проблема, а вот заменить каркас и электронику — считай купить нового дрона.
Я бы сказал что js еще больше «НЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕТ!» т.к. там ад не только для новичков. Без понимания что такое «ссылка», «событие», «closure», асинхронность в него лучше не лезть. А возможность в именованной функции переписать «саму себя» (хотя по факту — это что-то типа переопределения) может вызвать взрыв мозга =)
Как сказал один знакомый — «JavaScript — гениальный язык. Имея минимальное количество команд и возможностей, из них можно сделать практически все, что угодно». А теперь он есть и для серверной части…
PS: вспомнилась задача «выстрелить в ногу»:
JavaScript: Вы прочитали 3 книги, изучили 10 наглядных примеров, разработали потрясающий интерфейс и теперь, кажется, готовы к тому, чтобы выстрелить себе в ногу. Потом в процессе стрельбы обнаруживаете, что пули имеют радиус действия, равный длине ствола, и испаряются прямо на выходе.
node.JS: Вы начинаете асинхронно стрелять из асинхронных рук в асинхронные ноги, асинхронно не попадаете и запутываетесь в этой каше.
Говорю как пхпшник со стажем: НЕЕЕЕЕЕЕЕЕЕТ!
Для обучения — хуже языка чем php найти сложно (среди широко используемых) т.к. php не учит многим полезным вещам, например типизации, правильной работы с классами, понимание как работать с памятью и что это за память вообще такая (хотя бы в общем виде) и т.д. Он слишком упрощен для этого. Тем, кто обучался на основе php будет невероятно сложно освоить типизированные языки, про работу с памятью я вообще молчу. Его нельзя использовать как основной язык обучения. Хотя я вообще считаю плохой практикой использовать в обучении только 1 язык. Основам программирования нужно обучать на строго типизированном языке — это будет наиболее полезно (С, С++, С#, Java и т.п.). Это даст понимание происходящего. Далее лучше всего познакомить с нетипизированным/слаботипизированным языком (php, js и т.п.). На таких языках проще реализовывать некоторые алгоритмы, где важнее понимание алгоритма, чем заморочки с его реализацией, хотя это спорный момент.
Немного статистики из личных наблюдений:
Многие из тех, кто начинал с php становился говнокодером и ничего сложного им не доверяли.
Большинство из тех кого я знаю, и кто начинал с C/C++, но по каким-то причинам работает с php, говнокодерами почему-то не стали и преуспели в программировании в целом.
персонаж после 3го обычного удара начинает тупить когда жмешь правую кнопку. Если уж там нет спец-скила, то однозначно стоит туда продублировать удар левой кнопки
Соглашусь, есть такая проблема. Но если её решать через временное дублирование другого спелла, то есть риск научить игрока неправильному, развить вредную привычку, от которой ему потом придётся избавляться, что по-моему страшнее.
Я что-то не понял какую вредную привычку можно выработать? С моей точки зрения катастрофически плохо заставлять игрока беситься из-за того что персонаж затупил из-за невовремя нажатой правой кнопки. Это к чертям ломает боевую систему т.к. она становится ущербной из-за того, что есть такие вот паузы, которые полностью сбивают ритм боя. В фехтовании есть такое понятие «ритм», так вот если он сбивается у кого-то, то он считай труп. Каждый раз когда персонаж залипает, игрок теряет ритм и концентрацию. И все. Он уже не в бою т.к. он отвлекся. Ну и в добавок — это бесит т.к. система работает совершенно не так, как это от нее ожидается — она вообще не реагирует на действие игрока (а задалбывающее биканье интерфейса на каждое нажатие раздражает еще больше). Как по мне лучше уж псевдо-вредная привычка чем потеря интереса к боевой системе и, в итоге, к игре.
«Метроном» же заключался скорее в том, что после каждого удара надо выдерживать субъективно неприятную паузу, чтобы использовать желаемую комбу. В таком виде, я надеюсь, его скорее удалось побороть.
Для игроков, привыкших спамить нажатием на кнопки как раз наоборот. Приходится включать метроном нажатий, сознательно замедлять частоту нажатий до непривычного ритма + считать сколько ударов реально сделал персонаж. Учитывая что ритм ударов разный и достаточно быстрый, к этому достаточно сложно приспособиться. И из-за этого часто возникает худшая ситуация когда нажатие на правую кнопку влечет за собой затык персонажа из-за того, что обычный удар оказался 3м, а после него нет спец-удара. Тут одна проблема влечет за собой другую.
Я не так уж и наркозависим, но переиграл во много мморпг, хотя надолго не задерживался. В случае если игра зацепила, то после получения топового уровня меня хватает максимум на месяц. В лучшем случае качаю 2го перса с интересным классом, но во 2й раз это достаточно быстро т.к. есть уже средства и понимание игры. Я по сути играю в «исследование возможностей игры», поэтому как только интересное было изучено, забиваю на игру.
PS: Согласен с вашим «Пы. Сы.», но в la2 не нон-таргет система =)
Поиграл вчера. Играл паладином чтобы полностью оценить боевку.
Боевка довольно таки неплохо сделана, но до динамичности и вариативности слешеров ей далеко. Интересная идея со скилами на правой кнопке мыши, но ее нужно довести до ума т.к. не смотря на желание избавить от однообразности и метронома, получилось это не полностью. Причем скорее даже в худшую сторону т.к. довольно часто вместо спец-скила (тот что на правой кнопке) после 1го обычного удара, делается 2й спец-скил из-за того что часто нажимаешь на левую кнопку (привет от диабло и дота-like игр) и часто 2й обычный удар проходит быстрее чем нажал на правую кнопку или еще по какой-то причине, но в итоге непроизвольно включаешь меторном чтобы делать именно тот спец-удар, который хотел. Еще очень странно когда персонаж после 3го обычного удара начинает тупить когда жмешь правую кнопку. Если уж там нет спец-скила, то однозначно стоит туда продублировать удар левой кнопки. Хуже от этого точно не будет.
Периодически очень странно себя ведет атотаргет: стою я перед мобом, жму левую кнопку, а персонаж ничего не делает (сообщение типа «нет врагов для атаки», которое в добавок дико бесит своим биканьем, пришлось выключить звуки интерфейса). Пока не затаргетишь вручную он так и будет тупить. Похоже, что в фокус попал моб, который явно не там, куда я собирался бить. И вообще — зачем блокировать атаку, если рядом никого нет? Что плохого если я начну мечем размахивать в пустоту? Если уж иначе нельзя, то тогда сделайте хотябы чтобы если таргета нет в зоне удара, то выбирался бы моб, который в этой зоне и в поле видимости. Хотя тут уже могут быть проблемы с потерей таргета.
Надо еще с геймпада попробовать, может ситуация получше будет.
В целом: идея интересная, но с косяками
Ага. Но она от этого разнообразнее не становится. Я видел и массовые замесы и пвп — это интересно, но однообразно, хотя в массовухе особо некогда красоты рассматривать, разве что когда тебя уже вынесли. Если на бой выйдут 2 одинаковых класса предпочитающие одинаковое оружие, то они как клоны, делают почти одно и тоже т.к. основных скилов мало и вариаций их связок тоже. Про пве вообще молчу
в GuildWars 2 значительно другой бой. Есть пересечения, но не настолько чтобы говорить «уже было реализовано». И в GW2 бой достаточно скучен и однообразен после какого-то времени в игре. В neverwinter бой хоть и динамичен (за лучника играю — приходится постоянно бегать, уклоняться и т.п.), но скучноват. Но там вообще больше проблемы с бесконечно долгим и довольно частым и бессмысленным перемещением по городу.
Я уже довольно долго использую CakePHP 2.x, но ограничил его применение небольшими проектами из-за излишней магии, которую нельзя отключить не поменяв код фреймворка, что в итоге и пришлось сделать =( С того момента я поставил на CakePHP крест. До сих пор его использую только из-за того, что у меня на нем уже куча наработок для несложных сайтов и все-равно периодически матерю его магию (мыши плакали, кололись, но продолжали жрать кактус).
Пока я склоняюсь к Symfony — мне понравилось как он устроен. Достаточно ненавязчиво, хотя и посложнее чем CakePHP.
Это скорее дыры в протоколе «Внимательность и Знание» у служащих.
Партиционирование для postgresql нужно немного допилить напильником чтобы оно было автоматизированным, но зато есть гибкость настройки. У mysql список ограничений больше всей остальной документации по партиционированию. Уж не знаю насколько ограничения критичны, но их многовато и их нужно все знать чтобы грабли не дали по лобешнику.
Еще полезно знать и использовать типы транзакций ибо deadlockи никому не нужны.
С having да, проблемка. Не знаю точно причины почему так, но предполагаю, что проблема с производительностью.
На своем опыте с myslq я страдал намного чаще чем с postgresql. Возможно причина в том, что учили меня использовать стандартный sql (использовали interbase), который чуть что не так — плюется ошибкой, и я по инерции ожидал такого поведения от mysql, но не тут-то было =)
Хотя я mysql до сих пор использую, но не делаю на нем ничего сложнее простых сайтов с 8-12 таблицами в БД. В таких случаях он все же лучшее решение. Хотя все-равно страхую кешированием =)
Все-равно яблоко от яблони далеко не падает =) mysql сама по себе сделана вопреки стандартам языка sql, так что научить ее чему-то реально полезному сложно.
Оно так и будет, но только когда вы обнаружите эту ошибку =) Мое мнение такое — если пришла непонятная или неожидаемая фигня, то приложение должно упасть, известив вас о произошедшем. Тогда тупые ошибки по недосмотру вылавливаются моментально, а не после часа поисков. И вот тут жесткая типизация postgresql приходит вам на помощь
Зато они получили такой набор функционала от postgresql, что они вполне могут довольно сильно поднять производительность.
Например, для меня самые главные минусы: нежесткая типизированость и отсутствие адекватного планировщика запросов. Как следствие, например, order by по 2м индексированным полям в разы дольше чем order by по 1 полю + сортировка в коде и многое другое чем postgresql не страдает. А уж что еще умеет postgresql, того в mysql никогда и не будет, скорее всего.
Ах да, я забыл про пляски с бубном при настройке mysql =)
По факту лучше 1 раз разобраться с postgresql и получать profit чем страдать с mysql.
Как сказал один знакомый — «JavaScript — гениальный язык. Имея минимальное количество команд и возможностей, из них можно сделать практически все, что угодно». А теперь он есть и для серверной части…
PS: вспомнилась задача «выстрелить в ногу»:
JavaScript: Вы прочитали 3 книги, изучили 10 наглядных примеров, разработали потрясающий интерфейс и теперь, кажется, готовы к тому, чтобы выстрелить себе в ногу. Потом в процессе стрельбы обнаруживаете, что пули имеют радиус действия, равный длине ствола, и испаряются прямо на выходе.
node.JS: Вы начинаете асинхронно стрелять из асинхронных рук в асинхронные ноги, асинхронно не попадаете и запутываетесь в этой каше.
Для обучения — хуже языка чем php найти сложно (среди широко используемых) т.к. php не учит многим полезным вещам, например типизации, правильной работы с классами, понимание как работать с памятью и что это за память вообще такая (хотя бы в общем виде) и т.д. Он слишком упрощен для этого. Тем, кто обучался на основе php будет невероятно сложно освоить типизированные языки, про работу с памятью я вообще молчу. Его нельзя использовать как основной язык обучения. Хотя я вообще считаю плохой практикой использовать в обучении только 1 язык. Основам программирования нужно обучать на строго типизированном языке — это будет наиболее полезно (С, С++, С#, Java и т.п.). Это даст понимание происходящего. Далее лучше всего познакомить с нетипизированным/слаботипизированным языком (php, js и т.п.). На таких языках проще реализовывать некоторые алгоритмы, где важнее понимание алгоритма, чем заморочки с его реализацией, хотя это спорный момент.
Немного статистики из личных наблюдений:
Многие из тех, кто начинал с php становился говнокодером и ничего сложного им не доверяли.
Большинство из тех кого я знаю, и кто начинал с C/C++, но по каким-то причинам работает с php, говнокодерами почему-то не стали и преуспели в программировании в целом.
Я что-то не понял какую вредную привычку можно выработать? С моей точки зрения катастрофически плохо заставлять игрока беситься из-за того что персонаж затупил из-за невовремя нажатой правой кнопки. Это к чертям ломает боевую систему т.к. она становится ущербной из-за того, что есть такие вот паузы, которые полностью сбивают ритм боя. В фехтовании есть такое понятие «ритм», так вот если он сбивается у кого-то, то он считай труп. Каждый раз когда персонаж залипает, игрок теряет ритм и концентрацию. И все. Он уже не в бою т.к. он отвлекся. Ну и в добавок — это бесит т.к. система работает совершенно не так, как это от нее ожидается — она вообще не реагирует на действие игрока (а задалбывающее биканье интерфейса на каждое нажатие раздражает еще больше). Как по мне лучше уж псевдо-вредная привычка чем потеря интереса к боевой системе и, в итоге, к игре.
Для игроков, привыкших спамить нажатием на кнопки как раз наоборот. Приходится включать метроном нажатий, сознательно замедлять частоту нажатий до непривычного ритма + считать сколько ударов реально сделал персонаж. Учитывая что ритм ударов разный и достаточно быстрый, к этому достаточно сложно приспособиться. И из-за этого часто возникает худшая ситуация когда нажатие на правую кнопку влечет за собой затык персонажа из-за того, что обычный удар оказался 3м, а после него нет спец-удара. Тут одна проблема влечет за собой другую.
PS: Согласен с вашим «Пы. Сы.», но в la2 не нон-таргет система =)
Боевка довольно таки неплохо сделана, но до динамичности и вариативности слешеров ей далеко. Интересная идея со скилами на правой кнопке мыши, но ее нужно довести до ума т.к. не смотря на желание избавить от однообразности и метронома, получилось это не полностью. Причем скорее даже в худшую сторону т.к. довольно часто вместо спец-скила (тот что на правой кнопке) после 1го обычного удара, делается 2й спец-скил из-за того что часто нажимаешь на левую кнопку (привет от диабло и дота-like игр) и часто 2й обычный удар проходит быстрее чем нажал на правую кнопку или еще по какой-то причине, но в итоге непроизвольно включаешь меторном чтобы делать именно тот спец-удар, который хотел. Еще очень странно когда персонаж после 3го обычного удара начинает тупить когда жмешь правую кнопку. Если уж там нет спец-скила, то однозначно стоит туда продублировать удар левой кнопки. Хуже от этого точно не будет.
Периодически очень странно себя ведет атотаргет: стою я перед мобом, жму левую кнопку, а персонаж ничего не делает (сообщение типа «нет врагов для атаки», которое в добавок дико бесит своим биканьем, пришлось выключить звуки интерфейса). Пока не затаргетишь вручную он так и будет тупить. Похоже, что в фокус попал моб, который явно не там, куда я собирался бить. И вообще — зачем блокировать атаку, если рядом никого нет? Что плохого если я начну мечем размахивать в пустоту? Если уж иначе нельзя, то тогда сделайте хотябы чтобы если таргета нет в зоне удара, то выбирался бы моб, который в этой зоне и в поле видимости. Хотя тут уже могут быть проблемы с потерей таргета.
Надо еще с геймпада попробовать, может ситуация получше будет.
В целом: идея интересная, но с косяками