Да в какой-то степени Вы правы. Если к нам приходит новый человек он какое-то время учится. Но знайте, что самое интересное? Когда-то у нас была попытка написать проект на рельсах. Взяли человека который утверждал, что рельсы он знает очень хорошо. Проект был достаточно сложный, как в общем и все наших проекты. Это был маркетплейс по покупке с доставкой сыпучих строительных материалов. Там было более 2к в водил которые размещали свои предложения и, когда заходил покупатель, для него нужно было автоматически сформировать наилучшее предложение на основании имеющихся прайсов (порядка 60к) расстояния доставки и еще некоторых факторов.
Так вот пока писалась общая «обвязка» проблем не было. Но как только дело дошло до основного функционала тут все и застряло. Чтобы понять как это сделать нашему новому сотруднику приходилось лезть в маны, в которых далеко не всегда получалось найти нужную информацию. То есть пять же учиться. Причем учить чужой продукт, согласитесь сложнее чем свой. А для части функционала решения вообще найти не удалось и пришлось писать костыли. В результате — время разработки выросло непомерно и продукт получился, честно говоря не очень.
Так вот мораль сей басни такова — если Вы пишите какие-то стандартные проекты, в которых нет особо сложного, уникального функционала Вы вполне можете обойтись коробочными решениями. Тем более для большинства их заказчиков те mc, о которых я писал, честно скажем, значения не имеют. Но если вы делаете, что-то более сложное и уникальное то тут «швейцарский нож» с кучей инструментов не подойдет. Нужен «десантный нож» который может и не «умеет» кофе подавать, но в своей специализации на высоте. И иногда его приходится «ковать» самим. Потому мы и не берет дешевые проекты )
Кто сказал что мы кого то приглашаем? А по поводу ни кто не пишет — почитайте посты выше. Да и за месяц Вы программистом точно не станете. Это байки «интернет экспертов»
Вот тут позволю себе не согласиться. Весь функционал постоянно дорабатывается и улучшается. У нас часть наших программистов работает над проектами заказчиков, а часть над инструментом для них и это процесс постоянный.
Как раз про Jquery я написал что цитата " При этом jq имеет кучу других плюсов ради которых я готов освоить новый синтаксис. " ))
А вообще я уже прочитал здесь столько мнений… С какими то я согласен с какими то нет Но однозначно думаю пора бы написать еще одну статью и как то все это суммировать )
А про «ScrollTop» вы даже не представляете сколько мне приходилось встречать сайтов где ради одной элементарной функции человек подключал кучу какого то барахла про который часто даже ни кто не слышал.
Более того как то прочила в блоге у одного товарища «После этого подлючаем наш замечательный less который из одной строчки нашего кода генерит 20к строк в css фале» (как то так) и все это только ради того что бы залить окружность радиальным градиентом с переходами.
Возможно. Понятно, что досконально разбираться в коде всех у меня возможности не было. Нужно еще и работать.
Но интересно. Такое впечатление что половина тех кто пытается комментировать даже не поняла о чем статья. Увидела что ругают их любимые фреймверки и понеслась в бой. Я не против «инструментов» оптимизирующих работу. Я против того какие они. Точнее большинство из них в настоящее время.
Вы всегда можете попытаться реализовать их самостоятельно с достаточным уровнем качества, стабильности и защищенности, чтобы с большой вероятностью иметь возможность убедиться, что это не совсем элементарные функции.
Именно так мы и поступили. Написали на Си gem для Ruby в котором собрали все что используем чаше всего и теперь на нем работаем. Не уверен можно ли здесь публиковать ссылки потому если будет интересно — напишите. Пришлю где его можно посмотреть.
Кроме всего прочего автор даже не знает полного алгоритма. )))) То что он описал — лишь первая часть ))
Так вот пока писалась общая «обвязка» проблем не было. Но как только дело дошло до основного функционала тут все и застряло. Чтобы понять как это сделать нашему новому сотруднику приходилось лезть в маны, в которых далеко не всегда получалось найти нужную информацию. То есть пять же учиться. Причем учить чужой продукт, согласитесь сложнее чем свой. А для части функционала решения вообще найти не удалось и пришлось писать костыли. В результате — время разработки выросло непомерно и продукт получился, честно говоря не очень.
Так вот мораль сей басни такова — если Вы пишите какие-то стандартные проекты, в которых нет особо сложного, уникального функционала Вы вполне можете обойтись коробочными решениями. Тем более для большинства их заказчиков те mc, о которых я писал, честно скажем, значения не имеют. Но если вы делаете, что-то более сложное и уникальное то тут «швейцарский нож» с кучей инструментов не подойдет. Нужен «десантный нож» который может и не «умеет» кофе подавать, но в своей специализации на высоте. И иногда его приходится «ковать» самим. Потому мы и не берет дешевые проекты )
А вообще я уже прочитал здесь столько мнений… С какими то я согласен с какими то нет Но однозначно думаю пора бы написать еще одну статью и как то все это суммировать )
А про «ScrollTop» вы даже не представляете сколько мне приходилось встречать сайтов где ради одной элементарной функции человек подключал кучу какого то барахла про который часто даже ни кто не слышал.
Более того как то прочила в блоге у одного товарища «После этого подлючаем наш замечательный less который из одной строчки нашего кода генерит 20к строк в css фале» (как то так) и все это только ради того что бы залить окружность радиальным градиентом с переходами.
Но интересно. Такое впечатление что половина тех кто пытается комментировать даже не поняла о чем статья. Увидела что ругают их любимые фреймверки и понеслась в бой. Я не против «инструментов» оптимизирующих работу. Я против того какие они. Точнее большинство из них в настоящее время.
Именно так мы и поступили. Написали на Си gem для Ruby в котором собрали все что используем чаше всего и теперь на нем работаем. Не уверен можно ли здесь публиковать ссылки потому если будет интересно — напишите. Пришлю где его можно посмотреть.