Переписать всё на любимом языке (Java, C#) — это такое преимущество, прямо в ворота не пролезает. Конечно же все бросятся. Может быть, сайты-визитки — нет. Но корпоративные приложения, порталы, АРМы, крупные сложные площадки — короче то, за что нам платят бабки — тут же всё перетащат на джаву. Запомните этот пост!
Ссылка же на оригинал новости есть прямо в первом абзаце (и она была там всегда, до этого комментария).
Но это не перевод, а рерайт. Несмотря на в общем похожую структуру, есть важная разница в ряде моментов: например, я утверждаю что на .Net Core переходить нужно в любом случае просто потому что это Free Software, и мне как FS/OSS-человеку это самое важное. Я супер редко пользуюсь какими-либо продуктами Microsoft именно потому, что это не Free Software, неважно насколько качественными или полезными они при этом являются. Но это совершенно не годится на официальную позицию Microsoft.
На «официальную позицию» не годится так же идея о том, что текущий подход к портированию — неудобный, и людям которые хотят что-то портировать — им остается только страдать. На официальную позицию не тянет троекратное упоминания подозрения, что половина читающих эту статью — те еще быдлокодеры и копипастеры со StackOverflow.
В принципе, мне ставить галочку «перевод» даже выгодно. Но вряд ли Microsoft обрадывалось бы двачерским словечкам и оборотам, которые приписали бы им словом «перевод» в заголовке. Это важный для меня момент, т.к. я не собираюсь ни отказываться от двачерской лексики, ни от глумёжа и обвинений в быдлокодерстве, итп — это мой стиль. Но при этом не хочу иметь официальные конфликты с Microsoft.
Я думаю, так или иначе, большинство новостей в мире фреймворков вторичны, и новости будут так или иначе идти от корневых источников — мейлинг-листов и сайтов авторов. Так что в дальнейшем рерайты новостей я писать продолжу. Вряд ли стоит выражать вторичность новости в виде галки «перевод».
Какие выводы я сделал из вашего комментария: в будущем нужно будет делать более глубокую проработку новости и менять её структуру, чтобы она не была «переводом» на уровне структурных блоков (или хотя бы — порядка структурных блоков).
> getElementsAnnotatedWith и myClass.getAnnotations() здесь нет
так напиши сам! Делаешь декоратор, сигнатура — как у Object.defineProperty, дефайнишь проперти отдельно. Лукап по пропертям делаешь отдельно. Понимаешь на что намекаю? Точно то же самое в питоне.
с классами то же самое, только получается фабрика. По сути это то же самое, что в спринге, только более убогое (меньше свободы метапрограммирования). А как ты уже на практике знаешь, в спринге через биндефинишенфактори, итп можно сделать любую супермагию, и уж точно можно сделать аннотации (лучше чем джавовые аннотации). Куда ткнуть хз, глянь «spring потрошитель», и видосы с Барухом, когда они spring-context поднимали не из xml или аннотаций, а из ini-файла
Чего? Короче, даже знать не хочу, где я тебе ответил как быдло. Просто пойми, я из Новосиба, с Богдашки, мы с Васей-Молотом ещё в школе столько конкурентов по .NET-аутсорсу в тайге закопали, а тогда и .NET ещё не было. Накладывает отпечаток на стиль изложения.
Чтобы понять, что делает аннотация, не нужно читать мануал.
Нужно взять IDE и посмотреть использование аннотации по коду Спринга.
Зачастую через пару минут становится понятно, что происходит.
Мануалы искать бессмысленно хотя бы потому, что их тупо нет. То что дается в доках по Spring и Hibernate — это некий высокоуровневый Overview с перечислением корневых компонентов. К сожалению.
У Java в этом огромное преимущество перед JS, например. В джаве с помощью IDE можно найти что угодно, прицельно, быстро. В JS нужно делать все то же самое, но приходится целиком читать код библиотек.
Ну тут такое, release early, release often, как говорил батюшка наш Эрик Реймонд. Наверное, раз уж подписался на участие опенсорце, придется жить по опенсорцным заповедям: постоянно сидеть на превьюхах, мониторить новости, адоптить частые апдейты. И главное, справляться своими силами, а не ждать, пока добрый дяденька из Microsoft тебе всё запилит.
У Егора есть своя книжка — Elegant Objects. Я сам не читал, потому что надо её заказывать на Амазоне и ждать до пенсии (месяц?). Но я вживую общался с Егором, он переполнен хорошими идеями, и книжка должна быть стоящая.
Этот фреймворк (takes) судя по всему, написан Егором и единомышленниками. Соответственно, это образец правильного ООП дизайна (насколько такой дизайн вообще можно сделать в Java) и является живым воплощением идей из книжки.
Хотя бы за это стоит этот фреймворк если не использовать, то по крайней мере — ознакомиться с базовыми идеями
Не забывай, что скоро будет webassembly, JS перестанет быть единственным нативным языком браузера, и все JS фреймворки со стороны клиента можно будет просто переписать на Java. Тем более что тот же React это не бог весть какая сложная штука.
Чот ты какой-то позитивный. Всего несколько мегабайт? Прозреваю мегабайт эдак тридцать в лучшем случае :-) Но ведь их можно будет все закэшировать. А если есть кэш, то что такое тридцать мегабайт во времена высокоскоростного интернета?
Это в корне отличается от апплетов тем, что использует модель безопасности браузера. К апплетам была единственная претензия — дырявость (а учитывая что их используют банки — это было действительно важно и скалось на отношении к технологии в целом). Wasm будет рабоать относительно Хромиума, и все репутационные риски будет тащить на себе Хромиум вообще и Гугл в частности.
я буду искать не senior framework coder, а senior software engineer. То есть человека, который программирует на идеях, а не на конкретных реализациях. Тогда конкретную реализацию можно будет выбирать в зависимости от ситуации. А ситуации бывают разные (иначе всех программистов можно было бы автоматизировать по-Грефовски)
Но это не перевод, а рерайт. Несмотря на в общем похожую структуру, есть важная разница в ряде моментов: например, я утверждаю что на .Net Core переходить нужно в любом случае просто потому что это Free Software, и мне как FS/OSS-человеку это самое важное. Я супер редко пользуюсь какими-либо продуктами Microsoft именно потому, что это не Free Software, неважно насколько качественными или полезными они при этом являются. Но это совершенно не годится на официальную позицию Microsoft.
На «официальную позицию» не годится так же идея о том, что текущий подход к портированию — неудобный, и людям которые хотят что-то портировать — им остается только страдать. На официальную позицию не тянет троекратное упоминания подозрения, что половина читающих эту статью — те еще быдлокодеры и копипастеры со StackOverflow.
В принципе, мне ставить галочку «перевод» даже выгодно. Но вряд ли Microsoft обрадывалось бы двачерским словечкам и оборотам, которые приписали бы им словом «перевод» в заголовке. Это важный для меня момент, т.к. я не собираюсь ни отказываться от двачерской лексики, ни от глумёжа и обвинений в быдлокодерстве, итп — это мой стиль. Но при этом не хочу иметь официальные конфликты с Microsoft.
Я думаю, так или иначе, большинство новостей в мире фреймворков вторичны, и новости будут так или иначе идти от корневых источников — мейлинг-листов и сайтов авторов. Так что в дальнейшем рерайты новостей я писать продолжу. Вряд ли стоит выражать вторичность новости в виде галки «перевод».
Какие выводы я сделал из вашего комментария: в будущем нужно будет делать более глубокую проработку новости и менять её структуру, чтобы она не была «переводом» на уровне структурных блоков (или хотя бы — порядка структурных блоков).
так напиши сам! Делаешь декоратор, сигнатура — как у Object.defineProperty, дефайнишь проперти отдельно. Лукап по пропертям делаешь отдельно. Понимаешь на что намекаю? Точно то же самое в питоне.
с классами то же самое, только получается фабрика. По сути это то же самое, что в спринге, только более убогое (меньше свободы метапрограммирования). А как ты уже на практике знаешь, в спринге через биндефинишенфактори, итп можно сделать любую супермагию, и уж точно можно сделать аннотации (лучше чем джавовые аннотации). Куда ткнуть хз, глянь «spring потрошитель», и видосы с Барухом, когда они spring-context поднимали не из xml или аннотаций, а из ini-файла
Перечисляешь модули, какие тебе надо, на выходе — работающий проект
Даже для Викета такая страница где-то там на их сайте есть
Рельсы имхо плавно умирающая технология
Typescript даже близко по статике не стоял со статичной жабой.
Ломбок — это очень плохая идея.
Так это же замечательно. Минус одна надуманная проблема :) Тащить адовые архитектурные паттерны только по причине карго-культа это как то не того
Нужно взять IDE и посмотреть использование аннотации по коду Спринга.
Зачастую через пару минут становится понятно, что происходит.
Мануалы искать бессмысленно хотя бы потому, что их тупо нет. То что дается в доках по Spring и Hibernate — это некий высокоуровневый Overview с перечислением корневых компонентов. К сожалению.
У Java в этом огромное преимущество перед JS, например. В джаве с помощью IDE можно найти что угодно, прицельно, быстро. В JS нужно делать все то же самое, но приходится целиком читать код библиотек.
У Егора есть своя книжка — Elegant Objects. Я сам не читал, потому что надо её заказывать на Амазоне и ждать до пенсии (месяц?). Но я вживую общался с Егором, он переполнен хорошими идеями, и книжка должна быть стоящая.
Этот фреймворк (takes) судя по всему, написан Егором и единомышленниками. Соответственно, это образец правильного ООП дизайна (насколько такой дизайн вообще можно сделать в Java) и является живым воплощением идей из книжки.
Хотя бы за это стоит этот фреймворк если не использовать, то по крайней мере — ознакомиться с базовыми идеями
я буду искать не senior framework coder, а senior software engineer. То есть человека, который программирует на идеях, а не на конкретных реализациях. Тогда конкретную реализацию можно будет выбирать в зависимости от ситуации. А ситуации бывают разные (иначе всех программистов можно было бы автоматизировать по-Грефовски)