Но даже несмотря на его невероятную распространённость, и профессионалам в области JS всегда будет чему поучиться.
Почему это не в разделу юмор? Вы серьезно считаете, что человек может называть себя "профессионалом в области JS", если он не знал всего этого ещё тогда, когда был джуном?
Вы раскрываете свое виденье, но вопрос, сами берете таких джунов? Сколько их у вас и сколько им платите?
Что-то мне подсказывает, что если студия не работает над большими проектами, то не могут брать человека "который может внести правки", а возьмут того, кто умеет все от и до, пусть и слабо понимает какой-нибудь Git, особенно с учётом того, что маленькие проекты — это скорость разработки важнее возможности поддержки в будущем.
В общем, минусы за странности в статье, плюсы — за старания и поднятие темы.
Конечно, это несправедливые суждения. CRM-ки и прочий софт для бизнеса нужны лишь для того, чтобы освободить работников от нервозности, рутины и необходимости держать всё в голове и неудобных файлах.
Я конечно надеюсь, что у Вас все не так, надеюсь Вы настраиваете все под клиента, но большинство современных облачных CRM вообще никак не связаны с реальными бизнес-процессами и являются какими-то франкинштейнами. Они реально больше мешают людям, когда руководству впаривают такую систему и сотрудников заставляют в них работать.
У нас, когда столкнулись с сайтом на Ruby, люди сделали какашку, а нам предлагали взять после них на поддержку, родилась шутка, что сайты нужно было делать на Erlang, а дальше как в анекдоте:
Украинец и еврей отбились от каравана в пустыне, каждый естественно прихватил самое дорогое себе, украинец -мешок с салом, еврей — мешок с золото. Еврею кушать хочется, и говорит:
Давай играть в рынок. Ты будешь продать сало, а я буду покупателем.
Хорошо.
Сколько у тебя стоит 100 грамм сала?
Мешок золота.
Не может быть, почему так дорого?
Ну не знаю, у меня так, походи по рынку, может дешевле найдешь.
Сознательно или несознательно, но выбор технологий сделан так, чтобы никто ничего не правил...
"Мощная ERP", один человек делал… Что-то совсем не сходится. Я бы ещё понял, если бы лёгкая и персонализированная под конкретного заказчика без лишнего функционала...
Если под RPC иметь ввиду SOAP, то его ругают за то, что аналог с REST будет легче весить (сам запрос и ответ).
А если говорить о настоящем RPC, особенно для общения между однотипными системами типа RMI у Java, то он просто не нужен для того говнокода, который сейчас пишут.
Если речь идёт о фронт-энд, то там особых последствий не будет. Ну придется потратить времени и немного покопаться. Критичного ничего нет.
А вот когда мы уже говорим о бек-энд. На сколько люди реально проверяют библиотеки, которые они используют?
В принципе, в большинстве фреймворков никто не мешает получить объект запроса, проверить ip, и если он нужный отправить в ответ всю базу данных. И это можно сделать не сразу, а с каким-то обновлением. Все ли отслеживают каждую строчку? Конечно за основными библиотеками следят много людей и большая вероятность, что что-то найдут, но если речь идёт о какой-то второстепенной вещи без большого сообщества.
Я понимаю, что пример про базу данных сильно натянутый, но сама идея, что код может вообще все делать на сервере.
А если совместить с темой поднятой автором во второй части статьи, что и у зависимостей есть свои зависимости...
Автору не помешает послушать выступление Алексея Шипилева, осознать всю бренность бытия, а заодно и то, что большинство людей, которые пытаются сравнивать производительность, на самом деле сравнивают что-то типа глубины с температурой… И в общем больше не заниматься глупостями.
Там есть специальная профессия мерять производительность, называется Performance Engineer.
Не соглашусь. В этом примере выглядит все логично, достаточно красиво и компактно. Для того же Flex-Box будет больше кода. Вопрос в другом, как это все будет выглядеть в том случае, если будет не 4 элемента на страницу, а хотя бы 100? Как будут выглядеть вложености?
Кстати, если там не одна буква для обозначения, то можно писать более полно, а для прода минифицировать…
В общем, я хочу сказать, что есть много вопров, и что многие технологии красивы на уровне «Hello, world!», а потом превращаются в кашу.
У меня не достаточно прав чтобы поставить лайк, но я Вас поддерживаю. Реально дешёвая попытка напарить свое.
Вот просто бы рассказали о рисках при внедрении CRM и возможных скрытых платежах о которых стоит узнать и оставили бы ссылочку для тех, кому интересно что они предлагают, на много бы больше людей обратило бы внимание.
Почему?
Грань очно толстая, в PHP, как в языке с динамической типизацией не может быть перегруженных функций.
Переопределение — это, по сути, исчезание родительской функции у класса и возможность ее вызвать только через приведение типа.
Перегрузка — это добавление функции и разрешение в зависимости от аргументов.
В общем, разница очень большая.
Не понял о чём статья и для кого. Вот сидит "ужасный кандидат" или "ужасный рекрутер" такой читает статью и думает, "как я раньше так жил? Нужно срочно что-то делать!". Так?
Мне кажется проблема в том, что из достаточно адекватной и понятной позиции HR как "human resources", эти две буквы превратились в "human recruiter".
Если первый вариант подразумевает все от поиска и постоянного и безграничного счастья сотрудника до создания и поддержания хорошей атмосферы в коллективе, что в принципе подразумевает основную компетенцию с сфере психологии.
То второй вариант должен или подразумевать техническую компетентность достаточную, чтобы оценить кандидата, или это должен делать младший помощник третьей секретарши, который посмотрит ресурсы с информацией о кандидатах, сверит буквы которые есть в резюме с теми, которые нужны для вакансии, задаст три контрольных вопроса и назначит встречу с компетентным сотрудником для интервью.
P.S. Последнюю часть второго варианта можно вообще заменить скриптом. Он хоть будет понимать значение нужных комбинаций букв в отличии от сами знаете кого...
Я тоже поддержу возмущение, Си даёт слишком мало абстракции для первого языка, лучше сначала учить Java или C#, а потом уже учить Си, чтобы понимать что реально происходит когда работает VM и на сколько это не эффективно :-D
Больше похоже на высер, чем на анализ. Вот реально, без рассмотрения конкретных задач, которые принципиально по разному решаются с помощью разных инструментов (в данном случае фреймворков) все это ни о чём!
Кстати, а Вы не думали, куда придется засунуть компоненты с Laravel или Symfony, если потом нужно будет переписать на Java или Go?
По итогу, Yii2 отличный фреймворк, который хорошо справляется со своими задачами. Спасибо тем, кто тратит своё время и силы на его развитие.
Почему это не в разделу юмор? Вы серьезно считаете, что человек может называть себя "профессионалом в области JS", если он не знал всего этого ещё тогда, когда был джуном?
Вы раскрываете свое виденье, но вопрос, сами берете таких джунов? Сколько их у вас и сколько им платите?
Что-то мне подсказывает, что если студия не работает над большими проектами, то не могут брать человека "который может внести правки", а возьмут того, кто умеет все от и до, пусть и слабо понимает какой-нибудь Git, особенно с учётом того, что маленькие проекты — это скорость разработки важнее возможности поддержки в будущем.
В общем, минусы за странности в статье, плюсы — за старания и поднятие темы.
Я конечно надеюсь, что у Вас все не так, надеюсь Вы настраиваете все под клиента, но большинство современных облачных CRM вообще никак не связаны с реальными бизнес-процессами и являются какими-то франкинштейнами. Они реально больше мешают людям, когда руководству впаривают такую систему и сотрудников заставляют в них работать.
Жалкая пародия на этот фундаментальный труд:
https://learn.javascript.ru/write-unmain-code
У нас, когда столкнулись с сайтом на Ruby, люди сделали какашку, а нам предлагали взять после них на поддержку, родилась шутка, что сайты нужно было делать на Erlang, а дальше как в анекдоте:
Украинец и еврей отбились от каравана в пустыне, каждый естественно прихватил самое дорогое себе, украинец -мешок с салом, еврей — мешок с золото. Еврею кушать хочется, и говорит:
Сознательно или несознательно, но выбор технологий сделан так, чтобы никто ничего не правил...
Мне кажется, Вы просто не понимаете разницу между бинарным и тестовым форматом.
"Мощная ERP", один человек делал… Что-то совсем не сходится. Я бы ещё понял, если бы лёгкая и персонализированная под конкретного заказчика без лишнего функционала...
Если под RPC иметь ввиду SOAP, то его ругают за то, что аналог с REST будет легче весить (сам запрос и ответ).
А если говорить о настоящем RPC, особенно для общения между однотипными системами типа RMI у Java, то он просто не нужен для того говнокода, который сейчас пишут.
Он с таким же успехом вместо "кеширование" мог написать "зеленый", содержательность не пострадала бы.
Если речь идёт о фронт-энд, то там особых последствий не будет. Ну придется потратить времени и немного покопаться. Критичного ничего нет.
А вот когда мы уже говорим о бек-энд. На сколько люди реально проверяют библиотеки, которые они используют?
В принципе, в большинстве фреймворков никто не мешает получить объект запроса, проверить ip, и если он нужный отправить в ответ всю базу данных. И это можно сделать не сразу, а с каким-то обновлением. Все ли отслеживают каждую строчку? Конечно за основными библиотеками следят много людей и большая вероятность, что что-то найдут, но если речь идёт о какой-то второстепенной вещи без большого сообщества.
Я понимаю, что пример про базу данных сильно натянутый, но сама идея, что код может вообще все делать на сервере.
А если совместить с темой поднятой автором во второй части статьи, что и у зависимостей есть свои зависимости...
Жизнь — боль!
Автору не помешает послушать выступление Алексея Шипилева, осознать всю бренность бытия, а заодно и то, что большинство людей, которые пытаются сравнивать производительность, на самом деле сравнивают что-то типа глубины с температурой… И в общем больше не заниматься глупостями.
Там есть специальная профессия мерять производительность, называется Performance Engineer.
Кстати, если там не одна буква для обозначения, то можно писать более полно, а для прода минифицировать…
В общем, я хочу сказать, что есть много вопров, и что многие технологии красивы на уровне «Hello, world!», а потом превращаются в кашу.
У меня не достаточно прав чтобы поставить лайк, но я Вас поддерживаю. Реально дешёвая попытка напарить свое.
Вот просто бы рассказали о рисках при внедрении CRM и возможных скрытых платежах о которых стоит узнать и оставили бы ссылочку для тех, кому интересно что они предлагают, на много бы больше людей обратило бы внимание.
Почему?
Грань очно толстая, в PHP, как в языке с динамической типизацией не может быть перегруженных функций.
Переопределение — это, по сути, исчезание родительской функции у класса и возможность ее вызвать только через приведение типа.
Перегрузка — это добавление функции и разрешение в зависимости от аргументов.
В общем, разница очень большая.
"Добавлена возможность перегружать абстрактные функции (RFC)".
Может всё-таки переопределять?
Не понял о чём статья и для кого. Вот сидит "ужасный кандидат" или "ужасный рекрутер" такой читает статью и думает, "как я раньше так жил? Нужно срочно что-то делать!". Так?
Мне кажется проблема в том, что из достаточно адекватной и понятной позиции HR как "human resources", эти две буквы превратились в "human recruiter".
Если первый вариант подразумевает все от поиска и постоянного и безграничного счастья сотрудника до создания и поддержания хорошей атмосферы в коллективе, что в принципе подразумевает основную компетенцию с сфере психологии.
То второй вариант должен или подразумевать техническую компетентность достаточную, чтобы оценить кандидата, или это должен делать младший помощник третьей секретарши, который посмотрит ресурсы с информацией о кандидатах, сверит буквы которые есть в резюме с теми, которые нужны для вакансии, задаст три контрольных вопроса и назначит встречу с компетентным сотрудником для интервью.
P.S. Последнюю часть второго варианта можно вообще заменить скриптом. Он хоть будет понимать значение нужных комбинаций букв в отличии от сами знаете кого...
Я тоже поддержу возмущение, Си даёт слишком мало абстракции для первого языка, лучше сначала учить Java или C#, а потом уже учить Си, чтобы понимать что реально происходит когда работает VM и на сколько это не эффективно :-D
Больше похоже на высер, чем на анализ. Вот реально, без рассмотрения конкретных задач, которые принципиально по разному решаются с помощью разных инструментов (в данном случае фреймворков) все это ни о чём!
Кстати, а Вы не думали, куда придется засунуть компоненты с Laravel или Symfony, если потом нужно будет переписать на Java или Go?
По итогу, Yii2 отличный фреймворк, который хорошо справляется со своими задачами. Спасибо тем, кто тратит своё время и силы на его развитие.