В Руби есть gem "did_you_mean", который даже идет в стандартной поставке языка. Он тоже детектит опечатки, находит подходящий класс, метод, переменную или модуль, который скорее всего имел в виду автор, и падает с ошибкой, показыая правильное написание. Автор видит, что ошибся, исправляет ошибку, и код остается нормальным. С одной стороны, да, приходится опечатки исправлять, а с другой — все ж лучше получить нормальное сообщение об ошибке, а не "undefined is not a function".
Вам бы такой режим сделать, и саркастическая шутка может стать полезной вещью.
Я сам тоже довольно маргинальные технологии сипользую, и вакансий мало. Но и спецов тоже меньше, и вам в конце концов нужно не 100 параллельных работ, а только одна.
Booking.com и Амстердам — компания, которая пылесосит всех перловиков мира последние 15 лет. Пособеседуйтесь. По (ЗП — затраты на жизнь) будет примерно как Минск, может хуже, но получше Гомеля.
Ну или:
прокачиваемся на вопросах на Java-интервью. Класслоадеры, многопоточность, модель памяти, коллекции, Спринг — в наших краях примерно такое спрашивают.
вписываете в резюме в прошлых работах местами рядом с перлом Джаву. Для спокойствия спишитесь с тамошними вашими руководителями и объясните ситуацию.
если HR-фильтр не проходится, пойдите на местную сходку джавистов, раззнакомьтесь, приходите на собеседование сразу к лидам команд без HR
если не прошли, просите у собеседовавших вас людей фидбека, что не так. Очень может быть, что дело не в Перле, а в том, как вы речь свою строите, например.
Ну и дерзайте. Хороший прогаммист — он и на Java хороший программист, главное подкачаться.
Java можно заменить на что-то еще. Наверняка вам будет проще устроиться на Python, Rub. Node.
По вашему, программисты на Хабре — сплошные ретрограды. У современного человека 90% памяти на компе сжирают мутные процессы под названием Chrome Helper, Slack и прочие поделия на основе Electron. 300 мегабайт за вкладку с HTML — норма.
Java при всей ее любви к памяти не способна угнаться за Blink, и любимая IDE соседствует с маленьким и скромным хипстерским музыкальным плеером или приложением для заметок.
Ну раз человек их ввел, то в базу они и так попали. А потом, когда пришло время их "удалить", в колонку рядом ставится флажок и все. Ну, может быть, когда база распухает, пробегается батч, который данные из активной базу перекачивает в архивную. Перекачивает он все — лишний if для проверки "активно не активно" писать явно влом. После этого данные остаются в архивной базе. Плюс 100500 бекапов на разных стадиях.
И ведь все остальные так же поступают. В том числе и вы, если у вас база данных есть. DELETE в продакшен коде — это лишний риск. Кому он нужен?
И в РЖД никто ничего не удаляет, потому что зачем заморачиваться? Диски дешевые, ленты — тоже. Когда ленты кончаются, нужно допокупать новые, а это еще один контракт, еще одни премиальные сейлзу со стороны вендора и бонусы от вендора человеку, закрывшему сделку со стороны РЖД (в народе "откат", но слово уже вышло из моды).
Пора смириться с тем, что за годы у РЖД скопились сотни записей о вашем паспорте, которые лежат и в зашифорванном виде, и в открытом, и местами там с секьюрити совсем грустно, и т.д.
Если дело так обстоит, то почему бы галочку не поставить, правда?
Я — один из людей, поддерживающих развитие Rust, у меня есть код на Расте в продакшене, я много говорю и пишу про язык, слежу за развитием и т.д. Казалось бы, я должен вам кричать «да-да! Rust — лучший, берите». Но не рекомендую использовать Раст сегодня как основной язык на бекенде.
HTTP-стек у Раста очень сырой, все может работать в тепличных условиях, но как дело дойдет до реальных пользователей, сидящих на странных устройствах в странных сетях за странными проксями и VPNами, вы можете столкнуться с проблемами, которые вам будет сложно решать. Такая же ситуация была у Node.js в 2011 году, и прошло какое-то время, прежде чем оно стало работать стабильно.
Больших фреймворков уровня Rails/Django нет, а для тех, кто повторяет Sinatra/Express в Расте, еще нет достаточного количества middleware и плагинов, чтобы писать эффективно. ORM и Query Builders только появляются.
Так что если вы начнете писать все-все на Расте сегодня, то может оказаться, что через год ваш проект превратится в мессиво из реликтовых велосипедов. Вам это не нужно.
А что нужно, так это взять за основу другой язык — например, Go — и писать для вашей системы небольшие модули на Rust. Модули могут со временем превратиться в полноценные сервисы, а там глядишь и подоспеет экосистема.
У меня был опыт написания бекенда на Node с использованием нативных модулей, которые я написал на Rust. Код получился небольшой, приятный, с тестами и документацией, понравился заказчику и мне. То же самое люди делают с Go, Ruby и Python.
Я гоняю в продакшене на одном проекте, но там на расте только кусок, который как библиотека подключен в остальное приложение. Кусок просто перерабатывает данные и делает по ним статистику определенного рода. Работает хорошо, нареканий нет, добились снижения по потреблению памяти без проседания производительности, хотя это не было какой-то целью.
Делать сервер целиком на Расте я бы не стал, а вот на уровне extensions для Node, Python, Ruby он заходит очень хорошо.
Чингиза Айтматова читать стоит — все ж не зря человеку Героя соцтруда дали и Ленинскую премию.
Роман «Плаха» — в республиках Средней Азии входил в школьную программу, а в остальном Союзе часто включался в список книг «на почитать летом». Там есть соответствующий кусочек, начинающийся со слов
Дело оказалось немудрёное, но до предела выматывающее и по способу варварское.
Мне кажется, что нет смысла сравнивать чисто фреймворки/библиотеки. Возьмем Angular и Ember. Ребята из Эмбера сразу начнут нахваливать свой крутой раутер. А мы добавим в проект на Angular их UI-router, и разница с Эмбером будет уже меньше (Эмбер-раутер все равно круче, но не намного).
Но чтобы вот так стеки сравнивать, нужно быть очень осведомленным обо всем, что вокруг того или иного фреймворка иди библиотеки делается — это гораздо сложнее, чем пойти на официальные сайты и сравнить по документации и примерам.
Оригинальная статья очень старая, и многие пункты вообще неприменимы сегодня.
Например, аддонов у Эмбера уже больше 1000, HTMLBars уже давно в релизе, а в бете его дальнейшее развитие — Glimmer. Наверняка по другим фреймворкам ситуация похожая.
Берем Node.js, Go или что-то аналогичное. Обработку запросов делаем на них, а уже они пусть пробрасывают данные в Rust. Можно растовую часть скомпилировать как аддон или библиотеку, а можно общение между Node/Go и Rust сделать по bsd-соккетам или ZeroMQ, например.
Но вообще смысл HTTP запросы обрабатывать на языке с такой строгой типизацией мне кажется неудобным.
Но кстати, как выше написал lolmaus, лучше не инжектить сервисы напрямую в компоненты, а пробрасывать данные «вниз» по иерархии компонентов и экшены «вверх». Из-за большого упора Эмбера на раутинг обычно каждый конкретный «экран» вашего приложения — довольно простой, и совсем глубокой иерархии строить не приходится. Поэтому передача «вручную» на практике не является проблемой.
А инжекшен лучше оставить на уровне рутов. Конечно, если ваш компонент — это какая-то вещь в себе, то можно и сервисы напрямую в него подключать, чем заниматься жонглированием атрибутов и экшенов. Но тут как и везде — главное, думать головой.
Можно делать и проще: emberjs.com/api/classes/Ember.inject.html#method_service — т.е. DI в стиле Angular — инжектим «на месте». Появился недавно, и я от него не в восторге. Мотивация была в стиле «DI via Initializers» — это слишком сложно для неискушенных в Эмбере.
Есть разные парадигмы UI, которые так или иначе становились популярными в разное время.
Например, сейчас мы привыкли к тому, что если я, скажем, хочу себе аватарку поменять, я кликаю по самой аватарке, А вот лет 7-8 назад «интуитивно» было бы иметь рядом с аватаркой кнопочку «поменять аватарку». Qooxdoo — как раз из той эпохи, когда для выполнения действий мы использовали дополнительные UI-контролы рядом с данными, а не манипулировали самими данными.
Это не хорошо и не плохо, потому что всякому UI есть свое применение (тот же Vim популярен сегодня, несмотря на то, что консольный). Но многие из тех, кто начал разрабатывать пользовательские интерфейсы, скажем, года три-четыре назад, посмотрят на Qooxdoo, Dojo, или Ext JS с недоумением, тк не привыкли видеть в современных интерфейсах такой control-heavy-подход.
Плюс, как я погляжу, такой: пишем все на JS, a за CSS и HTML отвечает фреймворк. Наверняка, какие-то админки, или UI для внутреннего пользования на этом можно быстро сделать.
Например, я — научный сотрудник где-то там. Мне нужен UI, чтоб задавать параметры какой-то симуляции. Я умею кодить алгоритмы и переводить формулы из математики в код. Чем мне разбираться с веб-разработкой и делать все, как советуют хипстеры, я лучше возьму эту штуку и накидаю UI за несколько часов. Уж синтаксис JS и API этой штуки по примерам можно освоить довольно быстро, а с какими-то неприятными для новичка особенностями JS (типа variable hoisting and scoping или this) я вряд ли столкнусь.
Лет 15 назад такой UI люди бы на Java, Delphi или VisualBasic сделали. А сегодня вот такая штука есть.
В Руби есть gem "did_you_mean", который даже идет в стандартной поставке языка. Он тоже детектит опечатки, находит подходящий класс, метод, переменную или модуль, который скорее всего имел в виду автор, и падает с ошибкой, показыая правильное написание. Автор видит, что ошибся, исправляет ошибку, и код остается нормальным. С одной стороны, да, приходится опечатки исправлять, а с другой — все ж лучше получить нормальное сообщение об ошибке, а не
"undefined is not a function".Вам бы такой режим сделать, и саркастическая шутка может стать полезной вещью.
Я сам тоже довольно маргинальные технологии сипользую, и вакансий мало. Но и спецов тоже меньше, и вам в конце концов нужно не 100 параллельных работ, а только одна.
Booking.com и Амстердам — компания, которая пылесосит всех перловиков мира последние 15 лет. Пособеседуйтесь. По (ЗП — затраты на жизнь) будет примерно как Минск, может хуже, но получше Гомеля.
Ну или:
Ну и дерзайте. Хороший прогаммист — он и на Java хороший программист, главное подкачаться.
Java можно заменить на что-то еще. Наверняка вам будет проще устроиться на Python, Rub. Node.
По вашему, программисты на Хабре — сплошные ретрограды. У современного человека 90% памяти на компе сжирают мутные процессы под названием Chrome Helper, Slack и прочие поделия на основе Electron. 300 мегабайт за вкладку с HTML — норма.
Java при всей ее любви к памяти не способна угнаться за Blink, и любимая IDE соседствует с маленьким и скромным хипстерским музыкальным плеером или приложением для заметок.
Ну раз человек их ввел, то в базу они и так попали. А потом, когда пришло время их "удалить", в колонку рядом ставится флажок и все. Ну, может быть, когда база распухает, пробегается батч, который данные из активной базу перекачивает в архивную. Перекачивает он все — лишний if для проверки "активно не активно" писать явно влом. После этого данные остаются в архивной базе. Плюс 100500 бекапов на разных стадиях.
И ведь все остальные так же поступают. В том числе и вы, если у вас база данных есть.
DELETEв продакшен коде — это лишний риск. Кому он нужен?И в РЖД никто ничего не удаляет, потому что зачем заморачиваться? Диски дешевые, ленты — тоже. Когда ленты кончаются, нужно допокупать новые, а это еще один контракт, еще одни премиальные сейлзу со стороны вендора и бонусы от вендора человеку, закрывшему сделку со стороны РЖД (в народе "откат", но слово уже вышло из моды).
Пора смириться с тем, что за годы у РЖД скопились сотни записей о вашем паспорте, которые лежат и в зашифорванном виде, и в открытом, и местами там с секьюрити совсем грустно, и т.д.
Если дело так обстоит, то почему бы галочку не поставить, правда?
HTTP-стек у Раста очень сырой, все может работать в тепличных условиях, но как дело дойдет до реальных пользователей, сидящих на странных устройствах в странных сетях за странными проксями и VPNами, вы можете столкнуться с проблемами, которые вам будет сложно решать. Такая же ситуация была у Node.js в 2011 году, и прошло какое-то время, прежде чем оно стало работать стабильно.
Больших фреймворков уровня Rails/Django нет, а для тех, кто повторяет Sinatra/Express в Расте, еще нет достаточного количества middleware и плагинов, чтобы писать эффективно. ORM и Query Builders только появляются.
Так что если вы начнете писать все-все на Расте сегодня, то может оказаться, что через год ваш проект превратится в мессиво из реликтовых велосипедов. Вам это не нужно.
А что нужно, так это взять за основу другой язык — например, Go — и писать для вашей системы небольшие модули на Rust. Модули могут со временем превратиться в полноценные сервисы, а там глядишь и подоспеет экосистема.
У меня был опыт написания бекенда на Node с использованием нативных модулей, которые я написал на Rust. Код получился небольшой, приятный, с тестами и документацией, понравился заказчику и мне. То же самое люди делают с Go, Ruby и Python.
Жаль, не помню, что за радио было. И живо ли оно?
Делать сервер целиком на Расте я бы не стал, а вот на уровне extensions для Node, Python, Ruby он заходит очень хорошо.
Роман «Плаха» — в республиках Средней Азии входил в школьную программу, а в остальном Союзе часто включался в список книг «на почитать летом». Там есть соответствующий кусочек, начинающийся со слов
У меня sim-карта с Java Card Connected на сервлетах 100к запросв в секунду держит. Правда, мы ее деплоим на Nokia 3310
Но чтобы вот так стеки сравнивать, нужно быть очень осведомленным обо всем, что вокруг того или иного фреймворка иди библиотеки делается — это гораздо сложнее, чем пойти на официальные сайты и сравнить по документации и примерам.
Например, аддонов у Эмбера уже больше 1000, HTMLBars уже давно в релизе, а в бете его дальнейшее развитие — Glimmer. Наверняка по другим фреймворкам ситуация похожая.
Но вообще смысл HTTP запросы обрабатывать на языке с такой строгой типизацией мне кажется неудобным.
А инжекшен лучше оставить на уровне рутов. Конечно, если ваш компонент — это какая-то вещь в себе, то можно и сервисы напрямую в него подключать, чем заниматься жонглированием атрибутов и экшенов. Но тут как и везде — главное, думать головой.
Вот пример: guides.emberjs.com/v1.11.0/understanding-ember/dependency-injection-and-service-lookup/#toc_dependency-injection-with-code-register-inject-code Говорите что, куда и по какому имени инжектить. В качестве направления можно указать семейство типов — например, route — тогда сервис будет заинжекшен в каждый раут. А можно — конкретный тип: 'component:my-awesome-component' Тогда только конкретный компонент будет иметь доступ к сервису. Это удобно тем, что вы в одном месте контролируете видимость того или иного сервиса и не получите неожиданных зависимостей.
Можно делать и проще: emberjs.com/api/classes/Ember.inject.html#method_service — т.е. DI в стиле Angular — инжектим «на месте». Появился недавно, и я от него не в восторге. Мотивация была в стиле «DI via Initializers» — это слишком сложно для неискушенных в Эмбере.
Например, сейчас мы привыкли к тому, что если я, скажем, хочу себе аватарку поменять, я кликаю по самой аватарке, А вот лет 7-8 назад «интуитивно» было бы иметь рядом с аватаркой кнопочку «поменять аватарку». Qooxdoo — как раз из той эпохи, когда для выполнения действий мы использовали дополнительные UI-контролы рядом с данными, а не манипулировали самими данными.
Это не хорошо и не плохо, потому что всякому UI есть свое применение (тот же Vim популярен сегодня, несмотря на то, что консольный). Но многие из тех, кто начал разрабатывать пользовательские интерфейсы, скажем, года три-четыре назад, посмотрят на Qooxdoo, Dojo, или Ext JS с недоумением, тк не привыкли видеть в современных интерфейсах такой control-heavy-подход.
Плюс, как я погляжу, такой: пишем все на JS, a за CSS и HTML отвечает фреймворк. Наверняка, какие-то админки, или UI для внутреннего пользования на этом можно быстро сделать.
Например, я — научный сотрудник где-то там. Мне нужен UI, чтоб задавать параметры какой-то симуляции. Я умею кодить алгоритмы и переводить формулы из математики в код. Чем мне разбираться с веб-разработкой и делать все, как советуют хипстеры, я лучше возьму эту штуку и накидаю UI за несколько часов. Уж синтаксис JS и API этой штуки по примерам можно освоить довольно быстро, а с какими-то неприятными для новичка особенностями JS (типа variable hoisting and scoping или this) я вряд ли столкнусь.
Лет 15 назад такой UI люди бы на Java, Delphi или VisualBasic сделали. А сегодня вот такая штука есть.