Указанная реализация больше похожа на попытку запустить express.js на jvm и проверить производительность. Или для попытки сделать более простым написание нативного кода, чтобы повысить производительность. Но никак не для того, чтобы предоставить мост для миграции с java на js.
Запуск Node.js на JVM позволяет легче провести миграцию для любого, кто использует большой Java стек, но хочет начать использовать Node.js. Например, Вы можете запустить на Node.js сервер (такой как Express.js) и вызывать существующие методы Java для обработки запросов.
Интересно каким образом это облегчит миграцию?
Если у вас какой-то javaEE сервер, допустим TomCat — вам нужно будет задеплоить в него этот javaj-express-js и это уже будет Веб-сервер внутри веб-сервера. Чтобы уйти от EE монстра создадим еще большего монстра.
А для маленьких standalone серверов нету смысла использовать такой подход, легче будет сразу переписать все на node.js и не заморачиваться.
Указанный подход лишь породит ошибки, которые не свойственны ни js, ни java, которые будут где-то на стыке и которые никак не отловить. Кроме того, производительность такого решения будет хуже чем чистое JVM или чистое Node.JS решение, JNI вызовы дорогие и они плохо отпимизируются.
По-моему, это уже можно назвать непониманием. В любом случае, нужно уметь договориться. В некоторых случаях костыль лучше делать на фронте, а в некоторых на беке. Если совместно не разобрать все плюсы и минусы отбросив абстрактные «костыль» или «лишний код», то любые споры кто должен запилить — это простой треп.
Для меня эта работа сильно опустила мой проф. уровень и я лично не советую работать на компанию где пишут плохой код
Это демотивирует, это угнетает, но такой опыт тоже полезен. Чтобы понять, что не все в мире идеально, чтобы понять, зачем все же нужны эти тесты, проектирование, и почему не стоит спешить накодить.
Да и в целом, чтобы понять, что ИТ мир полностью построен на костылях, на сколько грязных и коварных, что можно лишь удивляться, как это все еще работает.
оптимизируйте БД еще до ее создания, подумайте какие запросы у вас должны будут «бегать» к вашей БД, продумайте индексы, конечно же нормализируйте вашу модель данных
Совет правильный — ко всему нужно подходить с умом. Но тут нужно быть осторожными, т.к. очень легко свалиться в Преждевременную оптимизацию. А от этого в перспективе вреда будет на много больше, чем пользы.
Например, хорошо нормализованная база данных на старте проекта в перспективе выльется в большое количество запросов или в сложный запрос с множеством джоинов, чтобы вытянуть одно поле.
Если инженер (фронт, бек) отойдет от дел на 1 год — он забудет как код пишется в принципе. Даже 1 месяц пропустить — это очень много для ИТ мира.
Да, фронтенду сейчас сложнее, но не из-за того, что постоянно появляется что-то новое, а из-за того, что постоянно кто-то тянет одеяло в свою сторону и не хочет придерживаться стандартов ни для HTML, ни для CSS, и даже для JS не хотят.
Если раньше были «браузерные войны», то сейчас это можно расценивать как «холодная война браузеров»: с одной стороны и придерживаются стандартов, но с другой — вводят новый функционал, который есть только у них и больше ни у кого. Или придумывают одну и ту же фичу, но делают ее по-разному.
В бекэндах в этом плане проще. Не гнаться за чужими маркетинговыми причудами (хотя это тоже присутствует: то все на рельсы кинутся за рубинами, то на js бекенды писать начнут, то в Go начнут играть). В бекендах все по стандартам и по спецификациям коих несметная гора.
ps: Фронтенду нужно гнаться за тем, что сейчас популярно, а бекенду нужно изучать тонны материалов, которые уже существуют.
Ведь никто и не говорил, что фронт должен пилить бек. Фронт должен понимать как работает бек. Как минимум, чтобы было понятно почему иногда нужно делать «еще один костыль на фронтенде». Или подсказать, что он может сделать, чтобы этот костыль и вовсе не пришлось бы пилить.
Автор прав, фронтенд разработчик должен знать это все, хотя бы для понимания как это работает и почему иногда нужно прислушиваться с бекенд-проблемам, а не ныть о своих.
Но все, что автор говорил про фронтенд, в равной мере относится и к бекэнду. Бекэнд разработчик тоже должен знать это все и думать о том, чтобы выполнить свою задачу так, чтобы фронтенду было проще (у них так много боли). А не «отвалите от меня! я сделал свою часть!».
В идеале (и это достижимо) и те и другие должны уметь и хотеть разбираться во всем, и самое важное — уметь договориться как они будут решать поставленную задачу!
Судя по всему — абсолютным новичкам. По моему опыту люди, которые пытались войти в ИТ и при этом не имели какой-либо подготовки, часто очень долго не могли понять как два объекта одинаковые по содержанию не равны между собою по ==.
Описанная автором система программирования — это некий язык, который можно будет подсунуть даже обезьяне и она на нем сможет написать валидную программу. И этому примату тяжело будет понять различие между по-ссылке и по-значению.
Если не переопределять такой оператор, то сравнение будет происходить по диапазону памяти или будет ошибка компиляции?
В первом случае количество ошибок не станет меньше, они просто будут другими. Во втором же случае для любого сравнения нужно будет писать код (тонны бессмысленного кода).
Вы лишь подтвердили мое утверждение на счет бессмысленных графиков.
Ваш график показывает соотношение количества уязвимых систем из какой-то выборки сайтов с привязкой к языкам PHP, Java и с некоторому среднему показателю по больнице (по всем другим языкам).
Ваше сравнение можно описать как: Средний уровень каких-то разработчиков каких-то систем на каком-то языке Выше/Ниже, чем средний уровень каких-то других разработчиков каких-то других систем.
Стоимость систем, сроки разработки и уровень подготовки специалистов — эти переменные не учитываются.
В чем вообще смысл этого сравнения?
Выводов, резюме статьи вы не прикрепили, и если не сильно задумываться о правильности сравнения, то согласно вашей статье «PHP и Java — плохой выбор для реализации любых веб-систем», т.к. у остальных языков средний показатель ошибок ниже (согласно вашему комментарию), или же «На PHP — сейчас разрабатывают системы с наименьшим количеством уязвимостей».
У статьи должен быть эпиграф: «Бессмысленные графики дадут +10 к ощущению важности данных».
График
Каждое веб-приложение на PHP в среднем содержит 9,1 критически опасных уязвимостей, приложение на Java — 10,5. Для всех других языков программирования и средств разработки в среднем на каждую систему приходится лишь 2 критически опасные уязвимости.
На графике «какой-то показатель» уязвимостей среднего уровня равен 100% для всех языков!!!
А показатель для Критических уязвимостей противоречит комментарию. У Java этот показатель должен быть выше всех, а у Other — практически в ноль должен уходить, однако на графике совсем другая картина.
Описанная концепция идеального языка — очень хороша!
Но эта концепция имеет недостаток — она беспощадна к вычислительным ресурсам.
Имутабильность не уменьшит количество ошибок, она переведет их в другую плоскость. И в добавок заставит GC сгореть на работе.
Отсутствие деления целых и вещественных типов по размеру потребует использовать полиномиальные типы данных, а это медленно и очень много памяти. Уровень потребления памяти будет во много раз выше, чем у той же Java, которую за это обычно не любят.
Множество различных видов целого и вещественного чисел — это для динамических языков уже не нужная особенность.
Но отсутствие разделения на целые и вещественные числа — это дополнительные ошибки.
Вещественные типы страдают потерей точности, а это иногда очень критичный показатель. Целые, в свою очередь, страдают ограниченностью диапазона, что может привести к ошибкам переполнения.
Хорошим решением было бы выделить всего 2 класса: Int и Float, которые под капотом были бы представлены массивами. Возможно к этому когда-то придут, но сейчас живем с тем, что есть.
Cравнение по значению — это всегда очень медленно.
Так же есть довольно скользкий момент: иногда в объектах есть поля, которые не должны участвовать в сравнении. Например, какие-то служебные данные.
> сеньоры
обычно пишут абстракции над абстракциями =)
мидлы просто решают проблему в лоб, а потом выкидывают код и пишут новый, если потребуется внести правку.
Через декораторы несколько разных инстансов сделать не получится, да.
Но в контексте DI, если вам нужны разные инстансы коннекторов — они описываются в конфиге, а в сервисы вы уже подтягиваете нужный инстанс:
function Inject(field, instanceName) {
return function(target) {
target[field] = CONFIG[instanceName];
}
}
@Inject("pgConnection", "pgConnector")
@Inject("mongoConnection", "mongoConnector")
class MyService {
var pgConnection;
var mongoConnection;
}
А можете что-то рассказать про CreateJs, который поддерживается Adobe и его Animate CC? Пробовали? Как впечатления?
Интересно каким образом это облегчит миграцию?
Если у вас какой-то javaEE сервер, допустим TomCat — вам нужно будет задеплоить в него этот javaj-express-js и это уже будет Веб-сервер внутри веб-сервера. Чтобы уйти от EE монстра создадим еще большего монстра.
А для маленьких standalone серверов нету смысла использовать такой подход, легче будет сразу переписать все на node.js и не заморачиваться.
Указанный подход лишь породит ошибки, которые не свойственны ни js, ни java, которые будут где-то на стыке и которые никак не отловить. Кроме того, производительность такого решения будет хуже чем чистое JVM или чистое Node.JS решение, JNI вызовы дорогие и они плохо отпимизируются.
Это демотивирует, это угнетает, но такой опыт тоже полезен. Чтобы понять, что не все в мире идеально, чтобы понять, зачем все же нужны эти тесты, проектирование, и почему не стоит спешить накодить.
Да и в целом, чтобы понять, что ИТ мир полностью построен на костылях, на сколько грязных и коварных, что можно лишь удивляться, как это все еще работает.
Совет правильный — ко всему нужно подходить с умом. Но тут нужно быть осторожными, т.к. очень легко свалиться в Преждевременную оптимизацию. А от этого в перспективе вреда будет на много больше, чем пользы.
Например, хорошо нормализованная база данных на старте проекта в перспективе выльется в большое количество запросов или в сложный запрос с множеством джоинов, чтобы вытянуть одно поле.
Да, фронтенду сейчас сложнее, но не из-за того, что постоянно появляется что-то новое, а из-за того, что постоянно кто-то тянет одеяло в свою сторону и не хочет придерживаться стандартов ни для HTML, ни для CSS, и даже для JS не хотят.
Если раньше были «браузерные войны», то сейчас это можно расценивать как «холодная война браузеров»: с одной стороны и придерживаются стандартов, но с другой — вводят новый функционал, который есть только у них и больше ни у кого. Или придумывают одну и ту же фичу, но делают ее по-разному.
В бекэндах в этом плане проще. Не гнаться за чужими маркетинговыми причудами (хотя это тоже присутствует: то все на рельсы кинутся за рубинами, то на js бекенды писать начнут, то в Go начнут играть). В бекендах все по стандартам и по спецификациям коих несметная гора.
ps: Фронтенду нужно гнаться за тем, что сейчас популярно, а бекенду нужно изучать тонны материалов, которые уже существуют.
Но все, что автор говорил про фронтенд, в равной мере относится и к бекэнду. Бекэнд разработчик тоже должен знать это все и думать о том, чтобы выполнить свою задачу так, чтобы фронтенду было проще (у них так много боли). А не «отвалите от меня! я сделал свою часть!».
В идеале (и это достижимо) и те и другие должны уметь и хотеть разбираться во всем, и самое важное — уметь договориться как они будут решать поставленную задачу!
Судя по всему — абсолютным новичкам. По моему опыту люди, которые пытались войти в ИТ и при этом не имели какой-либо подготовки, часто очень долго не могли понять как два объекта одинаковые по содержанию не равны между собою по ==.
Описанная автором система программирования — это некий язык, который можно будет подсунуть даже обезьяне и она на нем сможет написать валидную программу. И этому примату тяжело будет понять различие между по-ссылке и по-значению.
В первом случае количество ошибок не станет меньше, они просто будут другими. Во втором же случае для любого сравнения нужно будет писать код (тонны бессмысленного кода).
Ваш график показывает соотношение количества уязвимых систем из какой-то выборки сайтов с привязкой к языкам PHP, Java и с некоторому среднему показателю по больнице (по всем другим языкам).
Ваше сравнение можно описать как: Средний уровень каких-то разработчиков каких-то систем на каком-то языке Выше/Ниже, чем средний уровень каких-то других разработчиков каких-то других систем.
Стоимость систем, сроки разработки и уровень подготовки специалистов — эти переменные не учитываются.
В чем вообще смысл этого сравнения?
Выводов, резюме статьи вы не прикрепили, и если не сильно задумываться о правильности сравнения, то согласно вашей статье «PHP и Java — плохой выбор для реализации любых веб-систем», т.к. у остальных языков средний показатель ошибок ниже (согласно вашему комментарию), или же «На PHP — сейчас разрабатывают системы с наименьшим количеством уязвимостей».
На графике «какой-то показатель» уязвимостей среднего уровня равен 100% для всех языков!!!
А показатель для Критических уязвимостей противоречит комментарию. У Java этот показатель должен быть выше всех, а у Other — практически в ноль должен уходить, однако на графике совсем другая картина.
Но эта концепция имеет недостаток — она беспощадна к вычислительным ресурсам.
Имутабильность не уменьшит количество ошибок, она переведет их в другую плоскость. И в добавок заставит GC сгореть на работе.
Отсутствие деления целых и вещественных типов по размеру потребует использовать полиномиальные типы данных, а это медленно и очень много памяти. Уровень потребления памяти будет во много раз выше, чем у той же Java, которую за это обычно не любят.
Множество различных видов целого и вещественного чисел — это для динамических языков уже не нужная особенность.
Но отсутствие разделения на целые и вещественные числа — это дополнительные ошибки.
Вещественные типы страдают потерей точности, а это иногда очень критичный показатель. Целые, в свою очередь, страдают ограниченностью диапазона, что может привести к ошибкам переполнения.
Хорошим решением было бы выделить всего 2 класса: Int и Float, которые под капотом были бы представлены массивами. Возможно к этому когда-то придут, но сейчас живем с тем, что есть.
Cравнение по значению — это всегда очень медленно.
Так же есть довольно скользкий момент: иногда в объектах есть поля, которые не должны участвовать в сравнении. Например, какие-то служебные данные.
обычно пишут абстракции над абстракциями =)
мидлы просто решают проблему в лоб, а потом выкидывают код и пишут новый, если потребуется внести правку.
Но в контексте DI, если вам нужны разные инстансы коннекторов — они описываются в конфиге, а в сервисы вы уже подтягиваете нужный инстанс:
И следом:
Spread operator — это ES6 стандарт, как и Классы и let, которые идут в примерах.