В прошлых статьях (проверка C#, кажется) писали, что Java проверять не интересно, т.к. это не проприетарная платформа.
И вот статья о проверке Java, интересно что повлияло на изменение курса?
Проблема не нова и всем известна. Правда мало кто задумывается о том, что является первоисточником проблемы.
Боль и убытки приносят те джуны, которые начитались бложиков по развитию от 24-летних Синьеров, которые вечно трубят, что компания и девочки-hr'очки должны целовать песок по которому они (программисты) ходили, и проповедуют переходы между компаниями каждые полгода, чтобы повысить ЗП на 20-100%.
Но если не рассматривать таких джунов, то проблема до боли простая: Джун не знает/не понимает зачем ему нужен менторинг, зачем ему пилить этот бесполезный учебный проект, который он даже в резюме не добавит, и, более того, ему даже не пытаются объяснить этого.
Нужно заинтересовать джунов, а не просто сказать «компания тратит кучу денег на взращивание», после чего каждый остается при своем мнении: «Компания меня использует и не дает ничего взамен», «Это глупый джун, который не хочет работать, а компания из-за него страдает».
А ведь если разжевать скилы и поставить цели, дать нужный курс развития и объяснить Зачем нужна какая-то фича, пусть даже в тестовом проекте, то «Младшенькому» будет интереснее и это будет для него вызов, после которого он захочет еще и еще, а не «непроходимая стена» из-за которой он будет проклинать текущую компанию и искать новую.
в качестве примера:
Бекэнд джун (java, .net, ruby, php etc.), которому дают задачу запилить фронтенд часть (html + js), джун не понимает и не хочет делать фронтенд, он же бекэндщик. Но если ему объяснить, что качественную систему можно построить только если знаешь как работают все ее компоненты и как они коммуницируют, дополнив это тем, что это повысит его ценность и востребованность на рынке труда, а самое главное — рассказать, что эта задача ему поставлена, чтобы он получил опыт интеграции двух подсистем не был упертым девом: «вот мне это сложно сделать, делай это у себя», а задумывался о сложности реализации на какой-то из сторон.
Там в тексте этого пункта было написано про наличие свободного времени.
Да и в целом когда кто-то говорит, что это не его дело — это дико раздражает, т.к. чаще всего это значит, что коллега просто не хочет работать (лучше ютубчик посмотреть).
«можно» — это еще не значит, что «будут».
при варианте с Redux Можно прикрутить jQuery и в обработчиках изменять DOM =)
Если возвести Абсурд в абсолют, можно слить абсолютно любую технологию.
А то, что сейчас называют спасением в виде Redux активно использовали еще до появления реакта в «мертвом» Flash =)
Как написал в комменте по другой ветке, имел ввиду Redux + e-commerce, но и на текущий вопрос могу ответить:
На данный момент повезло (или не очень) работать на проектах с AEM (бывший Adobe CQ), у этой платформы своя компонентная модель (java + jsp у CQ 5, и java + sightly у AEM), которая хранится в репозитории самой платформы и отдается как статика.
На данный момент есть небольшой опыт по использованию lodash+bbq+dust в одном проекте и BB (как набор моделей и некий pub\sub для общения) в другом.
По ощущениям BB использовать в текущих условиях приятнее: отсутствие кодогенерации из шаблонов при сборке дает преимущество во время разработки и отладки (не нужно делать редеплой, чтобы сгенерировать новый шаблон и залить его в репозиторий платформы и при необходимости можно непосредственно в репозитории сделать правку).
Компонентная модель реакта очень привлекательная, но в данном случае не очень применима: придется прикручивать компонентную модель одного фреймворка к компонентной модели другого, а это всегда чревато проблемами.
Прошу прощения, имел ввиду Redux, пока аппрувили коммент, истекло время для редактирования.
Для e-commerce в виде интернет-магазинов на много выгоднее использовать максимум статического контента для продвижения в поисковых выдачах. Идеальный вариант, это когда каждый продукт имеет свою собственную страницу, и поисковые выдачи можно оформлять как отдельные страницы (по крайней мере без ajax прогрузки первой страницы выдачи).
Подход старый, очень неприятный для многих современных разработчиков, но тем не менее более действенный.
SPA хоть и выглядит шикарно, но в данном случае для результата будет лучше использовать старые технологии. А прикручивать SPA стек там, где он не нужен, согласитесь, не лучшее решение.
Меня 1С, к счастью, тоже обошел стороной, но как знакомые на нем пишут видел, — читать базовые конструкции языка, не так тяжело (но с непривычки — не приятно), а вот бизнес логику воспринимать еще тяжелее. Вместо привычных репозиториев и DAO и прочего — там регистры, словари и прочее, но это уже больше DSL.
А для размышления, могу предложить идею, которой когда-то на первом курсе в университете баловался на С/С++ через макросы:
Даны целые А = 5, Б = 6. Вывести минимум от (А, Б). Вывести сумму (А, Б).
можно ради удовольствия попробовать развить эту идею =)
забавно и даже лучше, чем у коллеги из недавних постов)
но всегда, когда вижу такую русификацию вспоминается увиденный код в 1С: новый НТТРЗапрос() // ЭнТэТэЭр Запрос =)
как ни крути, все новые технологии и вся терминология появляется в англоязычном мире, и большинство термином даже сейчас не имеет адекватного перевода (а те, что имеют хоть какой-то — лучше бы не имели оного), поэтому любая локализация ЯП всегда будет сталкиваться с «суржиком».
на счет того, что статьи описывают идеи я понимаю, но ведь описано не очень хорошо, как писал раньше: то через апи, то через кишки (хотя, судя по тому, как пишут код в доках mobX — это их путь).
но хорошо, пойдем по пути документации: https://mobxjs.github.io/mobx/refguide/observable.html
аннотация/декоратор вешается только на массив, логично ждать срабатывания только, если изменится состояние структуры массива (добавили, удалили, заменили элементы).
но события публикуются и при изменении данных, которые лежат в массиве.
а соответственно, если необходимо изменить 2+ поля в данных — это породит 2+ событий, обойти это можно только если никогда не изменять данные, которые уже лежат в массиве: пересоздавать + перезаписывать данные.
> если вы начинаете додумывать и программировать в уме то делайте рефакторинг там же и подписывайтесь на конкретный todo
на конкретный туду — не исправит проблемы, зато кода будет в разы больше и он будет в разы хуже.
ps: а разве программировать можно как-то иначе, кроме как в уме? херяк-херяк, авось заработает — это плохой подход.
observableTodoStore.addTodo(«try MobX»);
observableTodoStore.todos[0].completed = true;
…
const store = observableTodoStore;
store.todos[0].completed = !store.todos[0].completed;
store.todos[1].task = «Random todo » + Math.random();
store.todos.push({ task: «Find a fine cheese», completed: true });
странный подход — то работать через апи, то прямо в кишки лезть…
а ведь если работать через апи класса, то неконсистентного состояния и быть не могло бы =)
В целом MobX привносит «магию» для замены простой концепции event dispatching (или pub/sub, если так приятнее).
Более того, если в апи добавить метод change, который будет изменять название и описание задания то, согласно коду выше, это породит 2 события изменения и изменение DOM произойдет 2 раза.
И это на примере кода уровня «hello world».
под этим подразумевал "Placement: None" в разделе Editor > General > Editor Tabs
но в целом, если Placement любой другой — результат тот же;
для обновленной Mac OS X до 10.11.4, эффек тот же; https://habrahabr.ru/company/JetBrains/blog/280019/#comment_8818523 чтобы не писать лишний коммент
при переходе из файла с кодом на проектные файлы (command + 1) и обратно (второй раз command + 1) не происходит возврата фокуса на редактор (может поможет: скрыты все табы)
часто/постоянно сворачивается дерево проекта в Project меню (для флеш проекта, при рефакторинге удаления файла или чего-то подобного, не сильно разбирался, для джава-проекта вроде нормально все)
Objective-C ближе к Си, чем C++.
И вот статья о проверке Java, интересно что повлияло на изменение курса?
Боль и убытки приносят те джуны, которые начитались бложиков по развитию от 24-летних Синьеров, которые вечно трубят, что компания и девочки-hr'очки должны целовать песок по которому они (программисты) ходили, и проповедуют переходы между компаниями каждые полгода, чтобы повысить ЗП на 20-100%.
Но если не рассматривать таких джунов, то проблема до боли простая: Джун не знает/не понимает зачем ему нужен менторинг, зачем ему пилить этот бесполезный учебный проект, который он даже в резюме не добавит, и, более того, ему даже не пытаются объяснить этого.
Нужно заинтересовать джунов, а не просто сказать «компания тратит кучу денег на взращивание», после чего каждый остается при своем мнении: «Компания меня использует и не дает ничего взамен», «Это глупый джун, который не хочет работать, а компания из-за него страдает».
А ведь если разжевать скилы и поставить цели, дать нужный курс развития и объяснить Зачем нужна какая-то фича, пусть даже в тестовом проекте, то «Младшенькому» будет интереснее и это будет для него вызов, после которого он захочет еще и еще, а не «непроходимая стена» из-за которой он будет проклинать текущую компанию и искать новую.
в качестве примера:
Бекэнд джун (java, .net, ruby, php etc.), которому дают задачу запилить фронтенд часть (html + js), джун не понимает и не хочет делать фронтенд, он же бекэндщик. Но если ему объяснить, что качественную систему можно построить только если знаешь как работают все ее компоненты и как они коммуницируют, дополнив это тем, что это повысит его ценность и востребованность на рынке труда, а самое главное — рассказать, что эта задача ему поставлена, чтобы он получил опыт интеграции двух подсистем не был упертым девом: «вот мне это сложно сделать, делай это у себя», а задумывался о сложности реализации на какой-то из сторон.
Да и в целом когда кто-то говорит, что это не его дело — это дико раздражает, т.к. чаще всего это значит, что коллега просто не хочет работать (лучше ютубчик посмотреть).
«можно» — это еще не значит, что «будут».
при варианте с Redux Можно прикрутить jQuery и в обработчиках изменять DOM =)
Если возвести Абсурд в абсолют, можно слить абсолютно любую технологию.
А то, что сейчас называют спасением в виде Redux активно использовали еще до появления реакта в «мертвом» Flash =)
ps: а Redux разве еще не устарел?
На данный момент повезло (или не очень) работать на проектах с AEM (бывший Adobe CQ), у этой платформы своя компонентная модель (java + jsp у CQ 5, и java + sightly у AEM), которая хранится в репозитории самой платформы и отдается как статика.
На данный момент есть небольшой опыт по использованию lodash+bbq+dust в одном проекте и BB (как набор моделей и некий pub\sub для общения) в другом.
По ощущениям BB использовать в текущих условиях приятнее: отсутствие кодогенерации из шаблонов при сборке дает преимущество во время разработки и отладки (не нужно делать редеплой, чтобы сгенерировать новый шаблон и залить его в репозиторий платформы и при необходимости можно непосредственно в репозитории сделать правку).
Компонентная модель реакта очень привлекательная, но в данном случае не очень применима: придется прикручивать компонентную модель одного фреймворка к компонентной модели другого, а это всегда чревато проблемами.
Для e-commerce в виде интернет-магазинов на много выгоднее использовать максимум статического контента для продвижения в поисковых выдачах. Идеальный вариант, это когда каждый продукт имеет свою собственную страницу, и поисковые выдачи можно оформлять как отдельные страницы (по крайней мере без ajax прогрузки первой страницы выдачи).
Подход старый, очень неприятный для многих современных разработчиков, но тем не менее более действенный.
SPA хоть и выглядит шикарно, но в данном случае для результата будет лучше использовать старые технологии. А прикручивать SPA стек там, где он не нужен, согласитесь, не лучшее решение.
Если пользователю дать форму приведенную последней* он вас возненавидит! И ему будет плевать, что у вас там под капотом Крутой Реакт или Плохой-ББ ;-)
*- habrastorage.org/files/ec9/814/337/ec98143373b74e54820851c91d572901.png
А вот для формы из второго примера — без разницы какой фреймворк использовать, тут можно даже на Ванильном JS все сделать, будет даже быстрее =)
Ах, да, есть варианты, где React не уместен по тем или иным причинам: e-commerce, как вариант.
А для размышления, могу предложить идею, которой когда-то на первом курсе в университете баловался на С/С++ через макросы:
Даны целые А = 5, Б = 6. Вывести минимум от (А, Б). Вывести сумму (А, Б).
можно ради удовольствия попробовать развить эту идею =)
но всегда, когда вижу такую русификацию вспоминается увиденный код в 1С: новый НТТРЗапрос() // ЭнТэТэЭр Запрос =)
как ни крути, все новые технологии и вся терминология появляется в англоязычном мире, и большинство термином даже сейчас не имеет адекватного перевода (а те, что имеют хоть какой-то — лучше бы не имели оного), поэтому любая локализация ЯП всегда будет сталкиваться с «суржиком».
но хорошо, пойдем по пути документации: https://mobxjs.github.io/mobx/refguide/observable.html
аннотация/декоратор вешается только на массив, логично ждать срабатывания только, если изменится состояние структуры массива (добавили, удалили, заменили элементы).
но события публикуются и при изменении данных, которые лежат в массиве.
а соответственно, если необходимо изменить 2+ поля в данных — это породит 2+ событий, обойти это можно только если никогда не изменять данные, которые уже лежат в массиве: пересоздавать + перезаписывать данные.
> если вы начинаете додумывать и программировать в уме то делайте рефакторинг там же и подписывайтесь на конкретный todo
на конкретный туду — не исправит проблемы, зато кода будет в разы больше и он будет в разы хуже.
ps: а разве программировать можно как-то иначе, кроме как в уме? херяк-херяк, авось заработает — это плохой подход.
observableTodoStore.todos[0].completed = true;
…
const store = observableTodoStore;
store.todos[0].completed = !store.todos[0].completed;
store.todos[1].task = «Random todo » + Math.random();
store.todos.push({ task: «Find a fine cheese», completed: true });
странный подход — то работать через апи, то прямо в кишки лезть…
а ведь если работать через апи класса, то неконсистентного состояния и быть не могло бы =)
В целом MobX привносит «магию» для замены простой концепции event dispatching (или pub/sub, если так приятнее).
Более того, если в апи добавить метод change, который будет изменять название и описание задания то, согласно коду выше, это породит 2 события изменения и изменение DOM произойдет 2 раза.
И это на примере кода уровня «hello world».
расширение оной — плохой шаг в развитии языка.
кортеж — в целом не плохой вариант, но сильно увеличивает сложность восприятия кода, вот пример кода:
void DoSomeWith(int x, int y, int z);
DoSomeWith(target.vector);
теперь метод с тремя параметрами вызывается как метод с одним параметром — удобненько! *сарказм*
но в целом, если Placement любой другой — результат тот же;
для обновленной Mac OS X до 10.11.4, эффек тот же;
https://habrahabr.ru/company/JetBrains/blog/280019/#comment_8818523
чтобы не писать лишний коммент
Из ошибок, сразу встретил:
при переходе из файла с кодом на проектные файлы (command + 1) и обратно (второй раз command + 1) не происходит возврата фокуса на редактор (может поможет: скрыты все табы)
часто/постоянно сворачивается дерево проекта в Project меню (для флеш проекта, при рефакторинге удаления файла или чего-то подобного, не сильно разбирался, для джава-проекта вроде нормально все)