То, что вы написали (а также много чего не написали) является декларируемыми целями, задачами, результатами…
И ваша позиция подтверждает, что общественные мнения на сабжевые вопросы сформированы и таргетированы более чем успешно.
А вот реальные цели и задачи несколько иные — и далеко не каждый может сходу их увидеть и распознать.
Поэтому, говорить что инфраструктура не будет ничего предпринимать — по меньшей мере наивно. Более того — части данной инфраструктуры, включая технические и социальные стороны, уже во многом готовы, тестируются и даже успешно работают. И когда система заработает целиком — вы даже не успеете понять, в какой момент это случилось…
Впрочем, изменить все равно вряд ли что получится, товарищ КЭПитан, виноват, товарищ майор!..
Неправильный вывод.
А правильный — вопрос соотношения цены и необходимости.
Как только будет позволять вся остальная инфраструктура сделать это ненапряжно и не особо дорого — сразу же реализуют задуманное.
Такое впечатление, что многие далеки от настоящих реалий жизни.
И как будто бы никто не знает, как работает механизм внедрения чего-либо куда-либо.
Поверьте — если будет очень нужно что-то сделать — этого обязательно добьются и сделают.
Как сказал один киногерой: «Значит пока еще такой задачи не стояло! „
Ну так исправляйте, кто мешает то?
Из двух высказываний типа:«Смотрите, как я решил проблему типизации в PHP, как здорово получилось!», или
«В PHP нет нормальной типизации, в Java намного лучше, PHP отстой!»
вам что больше по душе?
Рациональный подход в реальной жизни не только может, но и должен быть! И я ничего не имею против «гибридов» и сращивания технологий и других сущностей, но я о другом говорю.
Я против негативного отношения к тому, чем приходится пользоваться в силу различных обстоятельств, в данном случае PHP. Посмотрите на это с другой стороны — то, что у PHP есть недостатки, которые остались с прошлого и которые со временем стали все сильнее мешать, это не вина языка, это недоработка тех, кто принимает решения по разработке проектов и использованию конкретных инструментов. Это они неправильно или не вовремя приняли решение об использовании необходимых инструментов и технологий, это они не позаботились и не предусмотрели текущие проблемы с языком PHP, хотя знали про них ранее. Поэтому говорить о том, что язык PHP плохой, что у него нет того то, что он не умеет то то — в корне неверно. А чем думали раньше?? Это, к примеру, как переходить через большую яму по узкой досочке — если туда бухнешься, то кто виноват — узкая досочка, по которой решил перейти «умный человек», зная что вероятность падения более 90%?? Ах да, "… проект достался от предыдущих разработчиков, вот если бы я начинал с нуля, то..." — через некоторое количество времени ситуация бы снова повторилась.
Поэтому, будет правильным, как мне кажется, спокойно относится к недостаткам текущей реализации языка, по возможности добавлять сторонние «костыли» для расширения возможностей, а когда «костылирование» перейдет черту рациональности — просто поменять инструментарий со всеми вытекающими. Но не хаять то, с чем вы работаете. Ибо работа должна приносить удовольствие, тогда и результат будет соответствующий.
Вот именно в такой интерпретации я с вами полностью согласен. Но, как мне показалось, автор имел ввиду несколько другое. Не то, что инструмент можно улучшить за счет каких-то правильных дополнений, а то, что в целом сам инструмент плохой, даже если добавить ему эти отсутствующие дополнения.
По поводу заимствования — это прекрасно, что оно имеет место быть, но все должно быть в разумных пределах. К примеру, некоторые экстравагантные инженеры приделывают к автомобилю крылья и винты, и у некоторых это чудо инженерной мысли даже летает, но с практической точки зрения получившееся поделие ухудшило свойства автомобиля, и так и не стало самолетом. К чему я — надо улучшать и заимствовать то, что относится к изначальной целевой применимости сущности, а не просто потому что какая то фича есть у другой сущности, эта фича удобная и привычная, значит ее надо пихать во все другие сущности, хотя может быть там это совсем не к месту и сильно изменит саму эту сущность. Пример — любые паттерны программирования, которые суют везде, где надо и не надо. В общем, я думаю так — машине крылья не нужны! Если хотите крылья — делайте самолеты!
P.S. И кстати, по поводу типизации PHP был лишь пример, а не именно причина для обсуждения. Я имел ввиду абстрактную ситуацию в целом относительно языков.
В вашем комментарии вы правильно используете аналогию с напильником — значит я верно донес мысль.
В данном случае напильник — это инструмент, а каждый инструмент предназначен для выполнения предназначенных этому инструменту действий. И поэтому топором мы рубим, а отверткой закручиваем, а не наоборот. И мы не стараемся из отвертки сделать топор, а из топора отвертку. И если у нас нет отвертки, то мы идем в магазин и покупаем ее (ну или у кого то берем и др.)
А в случае, обозначенном автором, как раз и усматривается ситуация, когда человек не хочет использовать подходящий по ситуации применения инструмент, а хочет подогнать инструмент под применение. К примеру, нет отвертки для вкручивания шурупа. Что делаем? Правильно, молоток! Несколько ударов — и шуруп вкручен! Наверняка каждый из нас хоть раз, но делал так. Так и в случае автора — есть PHP, который был сделан для веба, и причем сделан давно, и он был сделан под тот, старый веб, а не современный, который и чисто вебом назвать уже нельзя, т.к. веб трансформировался уже в нечто большее и глобальное. Да, PHP доделывают, совершенствуют, улучшают. Но эти улучшения более косметические, чем принципиальные. А автор пытается сравнивать PHP с современными языками либо с языками другого назначения и применения. А зачем это делать? Если автору нужна строгая типизация, так пусть берет Java и пользуется на здоровье. Зачем тащить фичи из одних языков в другие, когда можно брать уже готовый нужный язык и пользоваться им? На то они и разные языки, чтобы быть разными! Или автор хочет из PHP сделать Java? Сейчас столько языков, на любой вкус и цвет — пользуйся, не хочу. Я никогда не понимал, когда хают один язык, а другой восхваляют. Это — не профессионально! У каждого языка есть свои плюсы и свои минусы, и зачем тащить одни в другие, не понимаю. Сейчас все языки в одинаковой категории по производительности примерно равны, по памяти ограничений почти нет, и нет смысла холиварить на тему лучше-хуже, надо просто пользоваться тем, что удобнее для тебя и все. Вот как-то так…
P.S. Есть опыт использования разных языков, в том числе PHP и Java.
Вот вы сами и ответили на свои же, скажем так, «вопросы».
Время шло, «фейсбуки превращались», «напильники перестали подходить», но вместо того, чтобы брать для работы другие, более подходящие напильники (треугольные, квадратные, и другие разные инструменты), мы продолжаем мужественно стачивать грани у круглого напильника, превращая его во всё более плоский…
Позвольте вас дополнить.
В целом обсуждение сводится к той ситуации, когда есть два напильника — плоский и круглый, и, автор, взяв в руки круглый напильник, рассказывает нам, как же плохо им выравнивать плоскую поверхность — то он соскальзывает, то канавки в поверхности делает, то вообще очень медленно точит! И, говорит, неплохо бы этому круглому напильнику грани сделать — тогда и с плоскими поверхностями намного удобнее будет работать! У автора то уже есть один удобный плоский напильник, тот то хорошо плоскости обрабатывает, значит надо к этому стремиться, сделать все напильники плоскими. Автор просто редко занимается округлыми поверхностями, но в те редкие моменты, когда это все же происходит, он тихим шепотом сыплет проклятия тому, кто ему подсунул эти неплоские поверхности, возможно даже изредка подумывая о круглом напильнике…
Привязка к ip на самом деле не так уж и «неюзерфрендли», как вы говорите. И, если подумать, то будет правильным, если смена сессии и смена ip будет происходить в один и тот же момент времени.
К примеру, ip изменился, а сессия осталась та же. Почему изменился ip? Вариантов ответа несколько, часть из них совсем «неюзерфрендли», а даже скорее «хакераттакли». Поэтому привязка JWT к ip в несложных случаях повысит безопасность на достаточно много процентов.
Наоборот, тимлид просто обязан быть очень хорошим разработчиком и отличным менеджером. Иначе он будет «ни там ни тут»… И как правильно сказано, он должен уметь оценить техническую сторону вопроса и принять правильное управленческое решение. Одно без другого будет ничто. Ну или «как обычно»…
Право слово, надоели уже с этой библиотекой jQuery.
Это просто библиотека, которая содержит набор различных методов, и исключительно ваше право какие из них использовать, какие нет, а какие реализовывать нативно.
В той или иной степени различные аналогичные библиотеки (фреймворки) также реализуют одни и те же методы, что и в jQuery, полностью или частично или более расширенно.
Ранее использовали jQuery потому что:
— можно сделать короче и понятнее код,
— это было модно.
Сейчас, в основной массе, используют другие принципы построения структуры веб -приложения, — сайта, — ..., и, соответственно, применяют другие библиотеки (фреймворки), более подходящие к конкретным задачам.
Поэтому нет смысла хаять или хвалить jQuery, эта библиотека может быть полезна и сейчас для определенного круга задач. А может быть полезна и другая библиотека (фреймворк).
И я совершенно не понимаю, когда ругают за использование jQuery, но при этом ковыряют ее исходники и выдергивают оттуда код какого-то метода. Писали бы сами что ли, раз все так плохо.
И я, к примеру, часто использую jQuery в проектах, хотя понимаю, что есть оверхед по КПД использования методов библиотеки примерно 20-50%, ну и что. Сейчас интернет позволяет прогрузить +- 100-200 kB дополнительных данных в запросе, работает кеширование разных уровней, отложенные загрузки, минификации и другие инструменты оптимизации. Гораздо печальнее выглядят различные зависимости, вот где КПД использования зашкаливает — требуется зависимость ради одного метода — вот это мне кажется черезчур жестким и неоправданным. Поэтому для не хайлоад вполне пойдет и jQuery для облегчения писанины нативных методов, а там где хайлоад — там подходы и критерии к оптимизации совершенно отличаются от standart.
И все возражения против jQuery в настоящее время — просто дань моде, не более. Сейчас практически все специалисты используют инструменты по назначению — и, если будет необходимость в jQuery — ее будут использовать. Без оглядки на моду.
P.S. Не холивара ради, истины для.
Есть ли разница, где отписываться: в beforeDestroy или destroyed?
У меня тоже были проблемы с памятью, но после добавления отписок в destroyed от части утечек памяти избавился.
И ваша позиция подтверждает, что общественные мнения на сабжевые вопросы сформированы и таргетированы более чем успешно.
А вот реальные цели и задачи несколько иные — и далеко не каждый может сходу их увидеть и распознать.
Поэтому, говорить что инфраструктура не будет ничего предпринимать — по меньшей мере наивно. Более того — части данной инфраструктуры, включая технические и социальные стороны, уже во многом готовы, тестируются и даже успешно работают. И когда система заработает целиком — вы даже не успеете понять, в какой момент это случилось…
Впрочем, изменить все равно вряд ли что получится, товарищ КЭПитан, виноват, товарищ майор!..
А правильный — вопрос соотношения цены и необходимости.
Как только будет позволять вся остальная инфраструктура сделать это ненапряжно и не особо дорого — сразу же реализуют задуманное.
И как будто бы никто не знает, как работает механизм внедрения чего-либо куда-либо.
Поверьте — если будет очень нужно что-то сделать — этого обязательно добьются и сделают.
Как сказал один киногерой: «Значит пока еще такой задачи не стояло! „
Из двух высказываний типа:«Смотрите, как я решил проблему типизации в PHP, как здорово получилось!», или
«В PHP нет нормальной типизации, в Java намного лучше, PHP отстой!»
вам что больше по душе?
Я против негативного отношения к тому, чем приходится пользоваться в силу различных обстоятельств, в данном случае PHP. Посмотрите на это с другой стороны — то, что у PHP есть недостатки, которые остались с прошлого и которые со временем стали все сильнее мешать, это не вина языка, это недоработка тех, кто принимает решения по разработке проектов и использованию конкретных инструментов. Это они неправильно или не вовремя приняли решение об использовании необходимых инструментов и технологий, это они не позаботились и не предусмотрели текущие проблемы с языком PHP, хотя знали про них ранее. Поэтому говорить о том, что язык PHP плохой, что у него нет того то, что он не умеет то то — в корне неверно. А чем думали раньше?? Это, к примеру, как переходить через большую яму по узкой досочке — если туда бухнешься, то кто виноват — узкая досочка, по которой решил перейти «умный человек», зная что вероятность падения более 90%?? Ах да, "… проект достался от предыдущих разработчиков, вот если бы я начинал с нуля, то..." — через некоторое количество времени ситуация бы снова повторилась.
Поэтому, будет правильным, как мне кажется, спокойно относится к недостаткам текущей реализации языка, по возможности добавлять сторонние «костыли» для расширения возможностей, а когда «костылирование» перейдет черту рациональности — просто поменять инструментарий со всеми вытекающими. Но не хаять то, с чем вы работаете. Ибо работа должна приносить удовольствие, тогда и результат будет соответствующий.
По поводу заимствования — это прекрасно, что оно имеет место быть, но все должно быть в разумных пределах. К примеру, некоторые экстравагантные инженеры приделывают к автомобилю крылья и винты, и у некоторых это чудо инженерной мысли даже летает, но с практической точки зрения получившееся поделие ухудшило свойства автомобиля, и так и не стало самолетом. К чему я — надо улучшать и заимствовать то, что относится к изначальной целевой применимости сущности, а не просто потому что какая то фича есть у другой сущности, эта фича удобная и привычная, значит ее надо пихать во все другие сущности, хотя может быть там это совсем не к месту и сильно изменит саму эту сущность. Пример — любые паттерны программирования, которые суют везде, где надо и не надо. В общем, я думаю так — машине крылья не нужны! Если хотите крылья — делайте самолеты!
P.S. И кстати, по поводу типизации PHP был лишь пример, а не именно причина для обсуждения. Я имел ввиду абстрактную ситуацию в целом относительно языков.
В данном случае напильник — это инструмент, а каждый инструмент предназначен для выполнения предназначенных этому инструменту действий. И поэтому топором мы рубим, а отверткой закручиваем, а не наоборот. И мы не стараемся из отвертки сделать топор, а из топора отвертку. И если у нас нет отвертки, то мы идем в магазин и покупаем ее (ну или у кого то берем и др.)
А в случае, обозначенном автором, как раз и усматривается ситуация, когда человек не хочет использовать подходящий по ситуации применения инструмент, а хочет подогнать инструмент под применение. К примеру, нет отвертки для вкручивания шурупа. Что делаем? Правильно, молоток! Несколько ударов — и шуруп вкручен! Наверняка каждый из нас хоть раз, но делал так. Так и в случае автора — есть PHP, который был сделан для веба, и причем сделан давно, и он был сделан под тот, старый веб, а не современный, который и чисто вебом назвать уже нельзя, т.к. веб трансформировался уже в нечто большее и глобальное. Да, PHP доделывают, совершенствуют, улучшают. Но эти улучшения более косметические, чем принципиальные. А автор пытается сравнивать PHP с современными языками либо с языками другого назначения и применения. А зачем это делать? Если автору нужна строгая типизация, так пусть берет Java и пользуется на здоровье. Зачем тащить фичи из одних языков в другие, когда можно брать уже готовый нужный язык и пользоваться им? На то они и разные языки, чтобы быть разными! Или автор хочет из PHP сделать Java? Сейчас столько языков, на любой вкус и цвет — пользуйся, не хочу. Я никогда не понимал, когда хают один язык, а другой восхваляют. Это — не профессионально! У каждого языка есть свои плюсы и свои минусы, и зачем тащить одни в другие, не понимаю. Сейчас все языки в одинаковой категории по производительности примерно равны, по памяти ограничений почти нет, и нет смысла холиварить на тему лучше-хуже, надо просто пользоваться тем, что удобнее для тебя и все. Вот как-то так…
P.S. Есть опыт использования разных языков, в том числе PHP и Java.
Время шло, «фейсбуки превращались», «напильники перестали подходить», но вместо того, чтобы брать для работы другие, более подходящие напильники (треугольные, квадратные, и другие разные инструменты), мы продолжаем мужественно стачивать грани у круглого напильника, превращая его во всё более плоский…
В целом обсуждение сводится к той ситуации, когда есть два напильника — плоский и круглый, и, автор, взяв в руки круглый напильник, рассказывает нам, как же плохо им выравнивать плоскую поверхность — то он соскальзывает, то канавки в поверхности делает, то вообще очень медленно точит! И, говорит, неплохо бы этому круглому напильнику грани сделать — тогда и с плоскими поверхностями намного удобнее будет работать! У автора то уже есть один удобный плоский напильник, тот то хорошо плоскости обрабатывает, значит надо к этому стремиться, сделать все напильники плоскими. Автор просто редко занимается округлыми поверхностями, но в те редкие моменты, когда это все же происходит, он тихим шепотом сыплет проклятия тому, кто ему подсунул эти неплоские поверхности, возможно даже изредка подумывая о круглом напильнике…
К примеру, ip изменился, а сессия осталась та же. Почему изменился ip? Вариантов ответа несколько, часть из них совсем «неюзерфрендли», а даже скорее «хакераттакли». Поэтому привязка JWT к ip в несложных случаях повысит безопасность на достаточно много процентов.
Это просто библиотека, которая содержит набор различных методов, и исключительно ваше право какие из них использовать, какие нет, а какие реализовывать нативно.
В той или иной степени различные аналогичные библиотеки (фреймворки) также реализуют одни и те же методы, что и в jQuery, полностью или частично или более расширенно.
Ранее использовали jQuery потому что:
— можно сделать короче и понятнее код,
— это было модно.
Сейчас, в основной массе, используют другие принципы построения структуры веб -приложения, — сайта, — ..., и, соответственно, применяют другие библиотеки (фреймворки), более подходящие к конкретным задачам.
Поэтому нет смысла хаять или хвалить jQuery, эта библиотека может быть полезна и сейчас для определенного круга задач. А может быть полезна и другая библиотека (фреймворк).
И я совершенно не понимаю, когда ругают за использование jQuery, но при этом ковыряют ее исходники и выдергивают оттуда код какого-то метода. Писали бы сами что ли, раз все так плохо.
И я, к примеру, часто использую jQuery в проектах, хотя понимаю, что есть оверхед по КПД использования методов библиотеки примерно 20-50%, ну и что. Сейчас интернет позволяет прогрузить +- 100-200 kB дополнительных данных в запросе, работает кеширование разных уровней, отложенные загрузки, минификации и другие инструменты оптимизации. Гораздо печальнее выглядят различные зависимости, вот где КПД использования зашкаливает — требуется зависимость ради одного метода — вот это мне кажется черезчур жестким и неоправданным. Поэтому для не хайлоад вполне пойдет и jQuery для облегчения писанины нативных методов, а там где хайлоад — там подходы и критерии к оптимизации совершенно отличаются от standart.
И все возражения против jQuery в настоящее время — просто дань моде, не более. Сейчас практически все специалисты используют инструменты по назначению — и, если будет необходимость в jQuery — ее будут использовать. Без оглядки на моду.
P.S. Не холивара ради, истины для.
Спасибо, теперь понятно, в чем отличие.
У меня тоже были проблемы с памятью, но после добавления отписок в destroyed от части утечек памяти избавился.