Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 138
5 лет проработал в компании, где был собственный движок.
Задача сводилась к простому — изучить АПИ и делать все в абстракции (запросы к базе, построение форм, прочее).
Через пару лет я начинал осознавать насколько я начинаю отставать от новинок и прогресса. Пришлось догонять.
Сейчас стараюсь подбирать работу, что бы была работа, а не натягивание дизайна на готовые CMS. Второе проще и быстрее, но перспектив продвижения мало.
Задача сводилась к простому — изучить АПИ и делать все в абстракции (запросы к базе, построение форм, прочее).
Через пару лет я начинал осознавать насколько я начинаю отставать от новинок и прогресса. Пришлось догонять.
Сейчас стараюсь подбирать работу, что бы была работа, а не натягивание дизайна на готовые CMS. Второе проще и быстрее, но перспектив продвижения мало.
Я согласен, но буквально вчера я понял обратную сторону. Все проекты за последние несколько лет я делал на базе php-фреймворков (хотя у меня есть и один «наследственный» pure-php проект, для которого я – не выдержал – сделал activerecord-like прослойку для работы с бд). Каждый раз отрабатывалась архитектура и у меня сейчас есть очень неплохие представления о том, какой должна быть гибкая CMS.
Но вот понадобилось сделать что-то на modx – я скривился, но принялся за дело. И за день изучения мануалов нашел несколько идей, которые глобально решают мои проблемы. Продвижение оказалось моментальным.
Но вот понадобилось сделать что-то на modx – я скривился, но принялся за дело. И за день изучения мануалов нашел несколько идей, которые глобально решают мои проблемы. Продвижение оказалось моментальным.
Удобно, не спорю, в частности стандарты, которые все соблюдают, тогда новички, читая код понимают все, для чего и как.
Работодателям вообще удобно — ядро создают профи, а потом можно не парится и набирать обычных программистов и не боясь текучки.
Согласитесь, потеря ключевого программиста, который ядро делает, более печальнее, чем тот, кто собирает из кубиков модули.
Не стандартные ситуации — в поиск по ману.
Когда пишешь свой, а потом постоянный рефакторинг и фенечки — дают развитие.
Работодателям вообще удобно — ядро создают профи, а потом можно не парится и набирать обычных программистов и не боясь текучки.
Согласитесь, потеря ключевого программиста, который ядро делает, более печальнее, чем тот, кто собирает из кубиков модули.
Не стандартные ситуации — в поиск по ману.
Когда пишешь свой, а потом постоянный рефакторинг и фенечки — дают развитие.
MODX очень хороший. Особенно Revolution.
Мне тоже очень понравился, вот только слишком сложный интерфейс, претензии на аяксовость (когда при нажатии на пункт дерева слева страница все равно перезагружается) и глюк, с которым я столкнулся: при сохранении любого ресурса, который содержит поле шаблона, modx виснет на анимации сохранения (ошибка яваскрипта). Но это пол беды – он хотя бы изменения применяет. Но сменить шаблон уже невозможно. Похоже, прийдется заново начинать.
Претензии на аяксовость? Вся админка построена на ExtJS — он так работает.
При нажатии пункта меню слева вся страница перезагружается только для редактирования.
Это потому, что очень много все там грузится. Плюс к этому, получается прямая ссылка на документ в админке.
При переключении табов дерева и разворачивании подпунков страница не перезагружается. Более того, можно по правой кнопки во всплывающем окне редактировать элементы.
Про глюк с шаблоном можно подробнее, какая версия MODX?
При нажатии пункта меню слева вся страница перезагружается только для редактирования.
Это потому, что очень много все там грузится. Плюс к этому, получается прямая ссылка на документ в админке.
При переключении табов дерева и разворачивании подпунков страница не перезагружается. Более того, можно по правой кнопки во всплывающем окне редактировать элементы.
Про глюк с шаблоном можно подробнее, какая версия MODX?
Ну, все, что вы указали, я, по-прежнему, могу сделать и без перезагрузки :)
Версия – последняя 2.1.3. Судя по гуглу, такие проблемы возникают не только и совершенно по разным поводам и в разных версиях. Надеюсь, переустановка всего поможет.
Версия – последняя 2.1.3. Судя по гуглу, такие проблемы возникают не только и совершенно по разным поводам и в разных версиях. Надеюсь, переустановка всего поможет.
Ну то есть перезагрузка происходит только при переходе на документа\чанк\сниппет или раздел сайта. А где иначе? Или там так много аякса, что вы ожидаете вообще отсутствие перезагрузок страницы?
Про глюки — хз. У меня сейчас пара личных сайтов, штук 5 рабочих и в разработке еще штуки 4 — нету глюков.
Правда это все работает на VPS или Dedicated, собственноручно настроенных. Так что да, попробуйте просто переустановить все с начала.
Про глюки — хз. У меня сейчас пара личных сайтов, штук 5 рабочих и в разработке еще штуки 4 — нету глюков.
Правда это все работает на VPS или Dedicated, собственноручно настроенных. Так что да, попробуйте просто переустановить все с начала.
Вместе с аякс запросами которые начинаются после загрузки страницы и выполняются рекурсивно для каждого поддерева, переход и восстановление функциональности занимает много времени. Думаю, это можно сделать лучше. Или не претендовать на аяксовость, которая, на самом деле, замедляет работу, или убрать проволочки. И обработку таких ошибок, как у меня, тоже стоит добавить :)
Но поймите, я нисколько не умаляю остальные достоинства этой CMS. Осмелюсь сказать, что у меня просто свежий взгляд человека, который несколько лет не пользуется CMS и имеет возможность реализовать то, что ему кажется удобным.
Но поймите, я нисколько не умаляю остальные достоинства этой CMS. Осмелюсь сказать, что у меня просто свежий взгляд человека, который несколько лет не пользуется CMS и имеет возможность реализовать то, что ему кажется удобным.
Возможно вы правы.
на всякий случай — дерево вот это.
docs.sencha.com/ext-js/4-0/#!/api/Ext.data.Tree
на всякий случай — дерево вот это.
docs.sencha.com/ext-js/4-0/#!/api/Ext.data.Tree
С ExtJS я игрался мало, но дерево у них явно работает рекурсивно. Я же фанат MPath – можно было вывести все дерево в один проход и добавить с помощью яваскрипт всевозможные сворачивания. Это мой вариант
Это плохой вариант.
Одних только страниц сайта может быть несколько тысяч.
А в дереве слева 3 раздела. Ресурсы (страницы сайта), Элементы (шаблоны\сниппеты\чанки\плагины) и файловая система.
Вот и представьте вывод такого дерева в один проход. Дерево MODX вам не нравится ч эстетических соображений, возможно, но с функциоанльной точки зрения — там все верно. Сайт может быть ОЧЕНЬ большим.
P.S.
Кстати, я проводил опыт, и вывод одного раздела в админке с 2000 ресурсов подвешивал браузер на моем ноуте (core i3) на 5-10 секунд.
Одних только страниц сайта может быть несколько тысяч.
А в дереве слева 3 раздела. Ресурсы (страницы сайта), Элементы (шаблоны\сниппеты\чанки\плагины) и файловая система.
Вот и представьте вывод такого дерева в один проход. Дерево MODX вам не нравится ч эстетических соображений, возможно, но с функциоанльной точки зрения — там все верно. Сайт может быть ОЧЕНЬ большим.
P.S.
Кстати, я проводил опыт, и вывод одного раздела в админке с 2000 ресурсов подвешивал браузер на моем ноуте (core i3) на 5-10 секунд.
Пока все делаю на Evolution — Revolution слишком тяжеловесный ИМХО и у меня нет задач которые он глобально решает лучше 1.0.х
С модикс впервые работаю. Советуете? Насколько Эволюшн дегрессивнее Революшн? А то вдруг у меня все впечатление возьмет и испортится
Эво прекрасен! Начинать нужно с него, без вариантов. Шустрый, с огромными возможностями, кучей готовых сниппетов и наработок. Ну и освоить его проще.
Рево тяжелее, сложнее, но и позволяет больше в разы. На нем можно сайты строить, а можно писать полноценные веб-приложения. Сами авторы заявляют, что Рево — это фреймворк, просто с админкой для сайта в комплекте =)
Своим разнообразием и навороченной админкой он многих просто отталкивает.
А для посетителя обе системы работают приблизительно с одной скоростью. Поэтому, я делаю все на Рево — будет куда расширяться если что.
Рево тяжелее, сложнее, но и позволяет больше в разы. На нем можно сайты строить, а можно писать полноценные веб-приложения. Сами авторы заявляют, что Рево — это фреймворк, просто с админкой для сайта в комплекте =)
Своим разнообразием и навороченной админкой он многих просто отталкивает.
А для посетителя обе системы работают приблизительно с одной скоростью. Поэтому, я делаю все на Рево — будет куда расширяться если что.
С Рево я уже вполне разобрался и могу сделать все, что мне нужно – только этот глюк омрачает существование. Фреймворк с админкой – лучший подход, на мой взгляд. Попытки убрать из создания сайта программирование – совершенный бред, который ведет к созданию совершенно перегруженых и громоздких систем.
вообще-то Evo тоже позиционируется как CMF, а не чистый CMS
Да, наверное. Только там нет PDO и MVC, а без них сейчас как то не очень.
Ну и на своем сайте они обеих называют CMS.
Ну и на своем сайте они обеих называют CMS.
Раньше везде писали MODx CMF/CMS (еще кое-где осталось) — видимо пересмотрели позиционирование
работаю с ним с 2008 года, скорость разработки и гибкость очень высокая получается
на рево до сих пор не перешел, хотя он уже год как вышел
Начинайте с Эво
на рево до сих пор не перешел, хотя он уже год как вышел
Начинайте с Эво
Хороших разработчиков тупыми не сделает, а плохих уже ничего не спасёт. И так понятно, без разных там «наблюдений», что как-либо эффективно пользоваться фреймворком без знания core и прочих основ никак нельзя. Но говорить, что фреймворки «делают тупыми» тоже не вполне корректно. Знать как пользоваться командной строкой компилятора (в данном случае речь о java в том числе) и уметь написать и собрать в «блокноте» приложение — без сомнения необходимое умение, но нельзя же сказать при этом, что IDE делают тупыми? :)
Ну, не сами IDE или frameworks, а легкость, с которой можно выполнить определенные (вообще говоря, сложные) вещи. Значительно понижают порог входа и не требуют за это никакой ответственности
Так не надо входить с низких порогов) Надо и так и эдак уметь делать. Можно и знать сложные вещи и умело применять IDE и frameworks. Одно другому не мешает, в общем-то, а как раз дополняет. Понятно, что если человека посадить сразу за стратс с хибернейтом, то это сделает его хм… несколько «тупым» в java-разработке, да, пожалуй. Но никто не не подразумевает, что человек должен на этом зациклиться и не копаться в java core. В идеале начинать надо, разумеется, в обратном направлении.
Дело в том, что рынок насыщен неопытными работниками из-за того, что есть такие вот трамплины. И многие в итоге ноги ломают
Зря минусуете человека — дело говорит. Низкий порог вхождения часто играет с языком/технологией злую шутку в виде огромного числа низкоквалифицированных разработчиков не имеющих фундаментальные знания — именно это, например, является бичём и главной проблемой PHP, который создавался именно как язык с низким порогом вхождения в веб-разработку.
В случае с PHP — скорее не тупыми, а отвлекает от решения необходимых задач и уклонения в сторону псевдо-заученности, «идеологии» и «правильности». Когда для обработки одной ошибки нужно писать 2 класса (валидатор и обработчик), а если эта ошибка относится к определенному классу, то нужно (из-за того, что это «правильно» реализовывать еще и класс-родитель).
Чем не угодил простой Exception??? Зачем мне городить кучу кода ради проверки связки 2-3х значений, которые нигде кроме этого места у меня не появятся. Зачем, зачем, зачем!
Фреймворки, исходя из некоторого сферического проекта в вакууме, в своих библиотеках реализуют довольно сложную абстракцию, и навязываю разработчику свое видение проблемы.
Глядя на людей, которые ввязались в пучину Zend фреймворка, у меня возникает только только одна мысль в голове «нахуя!!!»
Я не знаю, какая ситуация в JAVA, но в PHP 90% необходимого функционала реализовано уже в стандарте языка, все это проверенно годами и работает относительно шустро.
Чем не угодил простой Exception??? Зачем мне городить кучу кода ради проверки связки 2-3х значений, которые нигде кроме этого места у меня не появятся. Зачем, зачем, зачем!
Фреймворки, исходя из некоторого сферического проекта в вакууме, в своих библиотеках реализуют довольно сложную абстракцию, и навязываю разработчику свое видение проблемы.
Глядя на людей, которые ввязались в пучину Zend фреймворка, у меня возникает только только одна мысль в голове «нахуя!!!»
Я не знаю, какая ситуация в JAVA, но в PHP 90% необходимого функционала реализовано уже в стандарте языка, все это проверенно годами и работает относительно шустро.
Есть и более легковесные фреймворки – из тех, с которыми я работаю – CodeIgniter и Kohana. Первый подпадает под вашу характеристику, сильно ограничивая разработчика. Но он учит его мыслить структурно и не городить огород, в котором никто другой разобраться не сможет. А вот Kohana гораздо свободнее в этом плане. И ничто не запрещает использовать Exception. Как и Validator. Но, похоже, что именно из-за этого некоторые разработчики теряются в поле и не продолжают работу с фреймворком.
Более того, Kohana своим хорошо документированным исходным кодом (ну и некоторой скудностью документации, что уж тут) просто подталкивает пользователей к изучению php :)
Отсутствие полноценных Jelly, Migration, DBForge и Formo для Kohana 3.1+ ой как подталкивает меня к грязным ругательства в последнее время :) А все случилось потому, что у Jonathan Geiger больше нет времени
Я-то их дописываю, но возобновленная Jelly (https://github.com/creatoro/kohana-jelly-for-Kohana-3.1) отличается архитектурой вглуби и не хватает моих сил в рабочее время переписывать довольно крупные классы :)
Jelly вполне себе работает. Остальные мне честно говоря неинтересны. Но, если основная часть модуля уже написана, что мешает портировать его в 3.1 или 3.2? Не с нуля ж писать.
Вообще, написание модулей под Kohana вполне себе увлекательный процесс, мне нравится
Вообще, написание модулей под Kohana вполне себе увлекательный процесс, мне нравится
Нынешняя ORM не так уж и плоха, как это было раньше, на мой взгляд. Однако, Jelly поддерживается сторонними разработчиками — посмотрите на форки. Ну а основные проблемы несовместимости, если память мне не изменяет, Джонатан пофиксил вскоре после официального релиза 3.1
Уже вышла 3.2, но это, кажется, не очень критично. Для меня большое горе, что не обновились модули самого Джонатана (майгрейт и дбфордж), а другие перестали поддерживать Jelly (как это случилось с формо).
Хотя, в целом, пережить можно, но когда есть планы на крупный движок на Кохане (в котором совсем не помешает ни формогенерация, ни автосинхронизация моделей) – это неприятно.
Хотя, в целом, пережить можно, но когда есть планы на крупный движок на Кохане (в котором совсем не помешает ни формогенерация, ни автосинхронизация моделей) – это неприятно.
«ООП ради ООП» же! Всё оттуда — как плюшки, так и простыни сомнительно полезного кода.
Фреймворки реализуют паттерны. Паттерны несут и добро и зло. Масштабируемость против избыточности. ООП в целом заставляет писать дополнительный код. Но если что-то начинаешь, то нужно продолжать и именно в рамках заданного стиля и озвученных правил. Что уж поделаешь…
>> Когда для обработки одной ошибки нужно писать 2 класса (валидатор и обработчик), а если эта ошибка относится к определенному классу, то нужно (из-за того, что это «правильно» реализовывать еще и класс-родитель). Чем не угодил простой Exception???
К примеру, в проекте много форм и, как следствие, много раз нужно выполнять их валидацию. К примеру, 25 раз в разных местах нужно проверить правильность ввода email. Ваше решение без валидатора и «обработчика» (не понял, что тут имеется в виду) на основе только Exception, пожалуйста.
>> Глядя на людей, которые ввязались в пучину Zend фреймворка, у меня возникает только только одна мысль в голове «нахуя!!!»
Для того, чтобы не разбирать спагетти-код доморощенных «Пэхопэ-гениев», которые считают, что они все умеют и все должны равняться именно на их код. Фреймворк полезен прежде всего неким соглашением по архитектуре кода. Если я вижу в коде, например, такое:
то я понимаю сразу, что мне хотел сказать предыдущий разработчик. А сколько «гениальных» способов получения параметров может придумать средний «индус» и как мне их потом разбирать?
Время вхождения в посторонний проект на ZF лично для меня практически равно 0. За пару часов я могу разобраться практически в любом ZF-коде. Если же проект написан на голом PHP, то там практически неограниченный простор для фантазии «доморощенных гениев» и разбираться в этом, подчас, бывает ой как мучительно.
К примеру, в проекте много форм и, как следствие, много раз нужно выполнять их валидацию. К примеру, 25 раз в разных местах нужно проверить правильность ввода email. Ваше решение без валидатора и «обработчика» (не понял, что тут имеется в виду) на основе только Exception, пожалуйста.
>> Глядя на людей, которые ввязались в пучину Zend фреймворка, у меня возникает только только одна мысль в голове «нахуя!!!»
Для того, чтобы не разбирать спагетти-код доморощенных «Пэхопэ-гениев», которые считают, что они все умеют и все должны равняться именно на их код. Фреймворк полезен прежде всего неким соглашением по архитектуре кода. Если я вижу в коде, например, такое:
$this->getRequest()->getParam('page', 1)то я понимаю сразу, что мне хотел сказать предыдущий разработчик. А сколько «гениальных» способов получения параметров может придумать средний «индус» и как мне их потом разбирать?
Время вхождения в посторонний проект на ZF лично для меня практически равно 0. За пару часов я могу разобраться практически в любом ZF-коде. Если же проект написан на голом PHP, то там практически неограниченный простор для фантазии «доморощенных гениев» и разбираться в этом, подчас, бывает ой как мучительно.
1. if(!isValidEmail($email)) throw new InvalidEmailException();
А уже в самом классе InvalidEmailException делать то, что нужно. Это в случае если проверка довольно часта в проекте. Формат возвращения данных от эксепшена уже зависит от проекта. В большинстве проектов даже не требуется наследоваться от класса Exception, можно просто вернуть, например Exception('#INVALID_EMAIL').
2. Если вы увидите в коде, например $_GET['page'], вы разве не поймете что хотел сказать разработчик? Более того, это намного понятней, чем $this->getRequest()->getParam('page', 1) — в записи $_GET['page'] с ходу понятно, откуда идет параметр и как его задавать.
Кроме того, что я сэкономил немного кода, я еще прибавил несколько микросекунд к быстродействию и выиграл в понятности.
Для меня, например, время вхождения в любой проект на PHP близко к 0. Пару часов на изучение архитектуры — и могу начинать проект. Дело привычки. Тем более мода на MVC конкретно подправила стандарты на создание приложений.
Лет 5 назад я бы с вами согласился безоговорочно — потому что ужасные поделки на PHP4 ежесекундно взрывали мозг. Но сейчас те, кто только начинает, намного чаще использует фреймворки, которые учат их правильным вещам, а потом уже переходят на голый PHP (или не переходят — это как повезет), поэтому качество кода улучшилось (или это мне так кажется)
А уже в самом классе InvalidEmailException делать то, что нужно. Это в случае если проверка довольно часта в проекте. Формат возвращения данных от эксепшена уже зависит от проекта. В большинстве проектов даже не требуется наследоваться от класса Exception, можно просто вернуть, например Exception('#INVALID_EMAIL').
2. Если вы увидите в коде, например $_GET['page'], вы разве не поймете что хотел сказать разработчик? Более того, это намного понятней, чем $this->getRequest()->getParam('page', 1) — в записи $_GET['page'] с ходу понятно, откуда идет параметр и как его задавать.
Кроме того, что я сэкономил немного кода, я еще прибавил несколько микросекунд к быстродействию и выиграл в понятности.
Для меня, например, время вхождения в любой проект на PHP близко к 0. Пару часов на изучение архитектуры — и могу начинать проект. Дело привычки. Тем более мода на MVC конкретно подправила стандарты на создание приложений.
Лет 5 назад я бы с вами согласился безоговорочно — потому что ужасные поделки на PHP4 ежесекундно взрывали мозг. Но сейчас те, кто только начинает, намного чаще использует фреймворки, которые учат их правильным вещам, а потом уже переходят на голый PHP (или не переходят — это как повезет), поэтому качество кода улучшилось (или это мне так кажется)
>> выиграл в понятности
Нет, ваш код не выполняет того, что делает мой код. Если бы вы реализовали полностью аналог, то это выглядело бы примерно так:
>> Лет 5 назад я бы с вами согласился безоговорочно — потому что ужасные поделки на PHP4 ежесекундно взрывали мозг
Может, вы везучий человек, но ужасные поделки никуда не исчезли, они просто перешли на новый уровень — ужасные поделки на PHP 5.3 — «теперь с нэймспейсами» (произносить нараспев голосом Урганта).
>> if(!isValidEmail($email)) throw new InvalidEmailException();
Несколько вопросов:
1. Является ли несоответствие email заданному формату исключением? Находится ли данная ошибка на одном уровне опасности для приложения с такими ситуациями как: отсутствие коннекта к базе, отсутствие важного файла и т.д.
2. isValidEmail — это глобальная функция? Вы используете процедурный подход или ООП подход? Или в своем приложении вы смешиваете несколько подходов в зависимости от ситуации и ваших желаний?
Нет, ваш код не выполняет того, что делает мой код. Если бы вы реализовали полностью аналог, то это выглядело бы примерно так:
$page = (array_key_exists('page', $_GET) && $_GET['page'] !== null)?$_GET['page']:1>> Лет 5 назад я бы с вами согласился безоговорочно — потому что ужасные поделки на PHP4 ежесекундно взрывали мозг
Может, вы везучий человек, но ужасные поделки никуда не исчезли, они просто перешли на новый уровень — ужасные поделки на PHP 5.3 — «теперь с нэймспейсами» (произносить нараспев голосом Урганта).
>> if(!isValidEmail($email)) throw new InvalidEmailException();
Несколько вопросов:
1. Является ли несоответствие email заданному формату исключением? Находится ли данная ошибка на одном уровне опасности для приложения с такими ситуациями как: отсутствие коннекта к базе, отсутствие важного файла и т.д.
2. isValidEmail — это глобальная функция? Вы используете процедурный подход или ООП подход? Или в своем приложении вы смешиваете несколько подходов в зависимости от ситуации и ваших желаний?
1. Жестоко вы. Просто
$page=isset($_GET['page'])?$_GET['page']:null
не хватило бы?
2. В большинстве случаем, несоответствие входным параметрам — это исключение выполнения, это говорит о том, что по каким-то причинам client-side проверки были не пройдены, и в данном случае лучше стопорнуться и использовать метод — «ошибка-обновление страницы» (если вдруг у человека не работает JS).
Ошибка неправильности входных параметров должна стопорить приложение, как и ошибка коннекта к базе и отсутствие важного файла. А каков ее уровень опасности, и что нужно делать в случае ее возникновения, должен решать класс эксепшена для этой ошибки.
isValidEmail глобальная функция. А что в этом ужасного? Но если поборники академически правильного ООП видят в этом разрушение Вавилона, то переписать это как DataCheckers::isValidEmail($email) дело нескольких минут.
$page=isset($_GET['page'])?$_GET['page']:null
не хватило бы?
2. В большинстве случаем, несоответствие входным параметрам — это исключение выполнения, это говорит о том, что по каким-то причинам client-side проверки были не пройдены, и в данном случае лучше стопорнуться и использовать метод — «ошибка-обновление страницы» (если вдруг у человека не работает JS).
Ошибка неправильности входных параметров должна стопорить приложение, как и ошибка коннекта к базе и отсутствие важного файла. А каков ее уровень опасности, и что нужно делать в случае ее возникновения, должен решать класс эксепшена для этой ошибки.
isValidEmail глобальная функция. А что в этом ужасного? Но если поборники академически правильного ООП видят в этом разрушение Вавилона, то переписать это как DataCheckers::isValidEmail($email) дело нескольких минут.
Кстати, если вы кидаете Exception('#INVALID_EMAIL'), то как вы собираетесь их отлавливать и где? Все исключения в одном месте, но в ситуации с email — нужно показать сообщение об ошибке и отобразить форму, а при отсутствии коннекта к ДБ — выдать 500 и спец. страницу. А если у вас все через один тип идет, то вы даже ловить каскадом через type hinting не сможете.
1. Как правильно кидать эксепшены, если в форме несколько ошибок и надо её вывести вместе с этими ошибками?
2. Вы не сэкономили в коде. Замена
это
В общем более похоже, что вам просто не нравятся фреймворки, но вы почему-то не хотите признаться себе в этом и вместо этого придумываете причины, почему без фреймворков лучше.
2. Вы не сэкономили в коде. Замена
$this->getRequest()->getParam('page', 1);это
isset($_GET['page']) ? $_GET['page'] : 1; Так что в понятности тоже выиграша нет. Сэкономленные микросекунды производительности врядли привысят погрешность измерения.В общем более похоже, что вам просто не нравятся фреймворки, но вы почему-то не хотите признаться себе в этом и вместо этого придумываете причины, почему без фреймворков лучше.
1. Есть чудесный язык client-side программирования, который называется Javascript.
Согласен, кидать эксепшен в случае неправильности одного e-mail — это плохая идея. Но опять же, зависит от условий использования.
«условия использования» — штука очень хитрая и всегда можно придумать такие, когда подход №1 — ерунда, а подход №2 — круто.
А некоторые болтологи смогут убедить вас, что и подход №1 — это круто.
Мне действительно не нравятся фреймворки, свое отношение я не скрываю, и главная моя претензия — излишняя избыточность кода, а так же навязывание избыточных и иногда не совсем корректных решений.
Единственные условия использования, когда необходимы фреймворки — это когда уже все написано на этом фреймворке. Хотя, с другой стороны, если уже что-то написано и оно некоторое время работает — это уже в своем роде фреймворк.
Таким образом, о чем бы мы с вами не философствовали, все равно придем к выводу — с чего бы ты не стартовал, всегда придешь к фреймворку. Тот, кто придет после тебя, скорее всего будет работать уже с фреймворком, и 100% найдет в нем миллион косяков.
Программисты очень похожи на волков — необходимость выживания продуктов вынуждает их сбиваться в стаи, где вожак диктует свои требования, но при этом каждый готов в случае прокола отгрызть вожаку голову и встать на его место со словами «вот уж так я точно делать не буду». В случае со сторонним фреймворком это не настолько явно — ведь, фактически, необходимость в системном архитекторе отпадает, и уже некому отгрызать голову.
Согласен, кидать эксепшен в случае неправильности одного e-mail — это плохая идея. Но опять же, зависит от условий использования.
«условия использования» — штука очень хитрая и всегда можно придумать такие, когда подход №1 — ерунда, а подход №2 — круто.
А некоторые болтологи смогут убедить вас, что и подход №1 — это круто.
Мне действительно не нравятся фреймворки, свое отношение я не скрываю, и главная моя претензия — излишняя избыточность кода, а так же навязывание избыточных и иногда не совсем корректных решений.
Единственные условия использования, когда необходимы фреймворки — это когда уже все написано на этом фреймворке. Хотя, с другой стороны, если уже что-то написано и оно некоторое время работает — это уже в своем роде фреймворк.
Таким образом, о чем бы мы с вами не философствовали, все равно придем к выводу — с чего бы ты не стартовал, всегда придешь к фреймворку. Тот, кто придет после тебя, скорее всего будет работать уже с фреймворком, и 100% найдет в нем миллион косяков.
Программисты очень похожи на волков — необходимость выживания продуктов вынуждает их сбиваться в стаи, где вожак диктует свои требования, но при этом каждый готов в случае прокола отгрызть вожаку голову и встать на его место со словами «вот уж так я точно делать не буду». В случае со сторонним фреймворком это не настолько явно — ведь, фактически, необходимость в системном архитекторе отпадает, и уже некому отгрызать голову.
1. Есть чудесный язык client-side программирования, который называется Javascript.
Согласен, кидать эксепшен в случае неправильности одного e-mail — это плохая идея. Но опять же, зависит от условий использования.
«условия использования» — штука очень хитрая и всегда можно придумать такие, когда подход №1 — ерунда, а подход №2 — круто.
А некоторые болтологи смогут убедить вас, что и подход №1 — это круто.
главная моя претензия — излишняя избыточность кода
Так это — не ответ на вопрос MangaRulit, в более-менее серьезной форме (много разносортных контролов с разными данными и динамической подгрузкой оных при вводе/валидации данных), со всяческими простыми и сложными клиентскими валидациями (с зависимостью[-ями] от состояния других контролов, к примеру), ваш код будет в разы больше кода для среднестатистического «излишне абстрактного» фреймворка. Js в таких случаях не спаситель…
А представьте, что эту форму до вас разрабатывал Вася Пупкин™, у которого свои понятия об программировании и MVC. Или он, к примеру, не знает паттерн MVC. Выигранные микросекунды могут обернуться
Еще в PHP есть asserts — тоже интересная штука, но я ими не пользуюсь, потому что не нашел применения. Кто бы что не говорил, PHP — очень гибкий язык, решение удовлетворяющее данным условиям использования всегда найти можно (и не одно).
Интересно, как же осваивали тот же Spring эти «претенденты»? Потому что в любой книжке по Spring первые несколько десятков страниц посвящены именно тому, зачем это все надо, для чего придумали Dependency Injection и т.д. Проблема с фреймворками надуманна, потому что когда вы их осваиваете, то читаете документацию, в которой написано, что как и зачем сделано в этом фреймворке.
Может, конечно, есть клинические случаи, когда человек изучает технологию не по доке, а по примерам кода, но не думаю, что так распространено.
Так что я считаю, что фреймворки не несут опасности отупления, они просто высвечивают тупость тех программистов, которые и без фреймворков писали бы плохой код, не понимая, что происходит в каждой строчке.
Может, конечно, есть клинические случаи, когда человек изучает технологию не по доке, а по примерам кода, но не думаю, что так распространено.
Так что я считаю, что фреймворки не несут опасности отупления, они просто высвечивают тупость тех программистов, которые и без фреймворков писали бы плохой код, не понимая, что происходит в каждой строчке.
Они изучали его выборочно, по Hello World. Все мы так иногда делаем. И, как я говорил выше: http://habrahabr.ru/blogs/htranslations/126812/#comment_4181804
Позволю себе прокомментировать ваше утверждение. Есть ещё второй вариант, когда молодой программист приходит на наполовину готовый проект, где всё настроено и его обучение сводится к тому, что бы «поставить сюда эту строчку, сюда — эту. Видишь на экране изменения?». И получается, что он вроде как и работает со Спрингом, и с Хибернейтом, но всё равно сконцентрирован на своей задаче. Так и получается — работать-то работал, а вот полной картины понимания фреймворка не имеет.
Давным давно я пытался понять ООП и не смог. В течении полугода я тыкался в фреймворк и интуитивно начал понимать как он работает. Так я понял ООП и отказался от фреймворков в узконаправленных проектах.
Каким образом вы его пытались понять? И каким образом его можно понять по фреймворкам? Думаю вы и сейчас не понимаете, что такое ООП и путаете его с паттернами…
Если хотите действительно понять, что такое ООП, почитайте Гради Буч Объектно-ориентированный анализ и проектирование с примерами приложений на С++ — мне в своё время очень помогло.
Если хотите действительно понять, что такое ООП, почитайте Гради Буч Объектно-ориентированный анализ и проектирование с примерами приложений на С++ — мне в своё время очень помогло.
Когда используешь ООП MVC фреймворк, в любом случае используешь структуру MVC и ООП. Естественно, я не по одному только фреймворку понял ООП, но он мне очень помог в этом. Язык PHP
«Когда используешь ООП MVC фреймворк, в любом случае используешь структуру MVC и ООП.»
Это иллюзия. Можно использовать, а можно писать по-своему. Я видел людей, которые в MVC писали весь код во вьюхе, и людей, которые писали на ООП-языке процедурно. «Don't program on a language, program into it», только наоборот.
Это иллюзия. Можно использовать, а можно писать по-своему. Я видел людей, которые в MVC писали весь код во вьюхе, и людей, которые писали на ООП-языке процедурно. «Don't program on a language, program into it», только наоборот.
А что вы хотите? Тех кто учится программировать с самых начал еденицы по сравнению с толпами вышеописанных попрышавших по верхам. Очень было забавно наблюдать за ними во времена расцвета делфи. Даже шутки слагали:
— что делает обычный программист когда ему надо реализовать функциональность X?
— реализует её на своем любимом языке программирования
— Что делает «дельфист»?
— Пишет на форуме: «у кого есть компонент для Х?»
— Вышеописанная статья вообще касается всей отрасли вцелом. Поверхностно нахватавшихся знаний, «делающих сайты за 2000 рублей», не понимающих разницу между технологией А и Б, но считающих себя ПРОГРАММИСТАМИ — толпы! Самое страшное что большая часть из них при этом никак не желает учится.
— что делает обычный программист когда ему надо реализовать функциональность X?
— реализует её на своем любимом языке программирования
— Что делает «дельфист»?
— Пишет на форуме: «у кого есть компонент для Х?»
— Вышеописанная статья вообще касается всей отрасли вцелом. Поверхностно нахватавшихся знаний, «делающих сайты за 2000 рублей», не понимающих разницу между технологией А и Б, но считающих себя ПРОГРАММИСТАМИ — толпы! Самое страшное что большая часть из них при этом никак не желает учится.
Да для .NET сейчас ровно тоже самое про компоненты.
я бы еще обобщил — хороших специалистов всегда мало. Пусть там не будет фрейморков — человек будет писать цикл потому что тут надо написать цикл, будет создавать класс для каждой дребедени, потому что его научили так делать, а сам думать он не умеет.
В нашей профессии я видел людей не понимавших азов создания программ, которые тем не менее пару лет работали в крупных конторах. Зато они прекрасно разбирались в ООП, могли поддержать беседу и вообще.
Пелевин, Чапаев и Пустота
В нашей профессии я видел людей не понимавших азов создания программ, которые тем не менее пару лет работали в крупных конторах. Зато они прекрасно разбирались в ООП, могли поддержать беседу и вообще.
— Только бы дело свое не посрамить — то-то оно, дело-то!.. Как есть
одному без другого никак не устоять… А ежели у вас кисель пойдет — какая
она будет война?.. Надо, значит, идти — вот и весь сказ, такая моя
командирская зарука…
…
Кстати, не объясните ли вы,
что такое зарука?
— Как? — наморщился Чапаев.
— Зарука, — повторил я.
— Где это вы услыхали?
— Если я не ошибаюсь, вы сами только что говорили с трибуны о своей
командирской заруке.
— А, — улыбнулся Чапаев, — вот вы о чем. Знаете, Петр, когда
приходится говорить с массой, совершенно не важно, понимаешь ли сам
произносимые слова. Важно, чтобы их понимали другие. Нужно просто отразить
ожидания толпы. Некоторые достигают этого, изучая язык, на котором говорит
масса, а я предпочитаю действовать напрямую. Так что если вы хотите
узнать, что такое «зарука», вам надо спрашивать не у меня, а у тех, кто
стоит сейчас на площади.
Мне показалось, что я понимаю, о чем он говорит. Уже давно я пришел к
очень близким выводам, только они касались разговоров об искусстве, всегда
угнетавших меня своим однообразием и бесцельностью. Будучи вынужден по
роду своих занятий встречаться со множеством тяжелых идиотов из
литературных кругов, я развил в себе способность участвовать в их беседах,
не особо вдумываясь в то, о чем идет речь, но свободно жонглируя нелепыми
словами вроде «реализма», «теургии» или даже «теософического кокса».
Пелевин, Чапаев и Пустота
xxx: пишу проигрователь и столкнулся с проблемой написания эквалайзера. кто чем может — помогите плиз
yyy: Могу помочь просьбой сформулировать вопрос конкретнее.
xxx: ну короче нужен эквалайзер типа как у винампа. ну там с басами и всем остальным. хотя бы 4-6 полос в эквалайзере
yyy: Нет, мой вопрос в другом. Ты хочешь, чтобы его за тебя написали? Или у тебя конкретный вопрос типа «Не знаю, как реализовать градиентную заливку у тени, отбрасываемой полосами. Перерыл весь MSDN, нашел только линейный градиент и конический градиент, а мне нужен градиент Безье (скажем)»? Или у тебя вопрос типа «Порекомендуйте мне литературу по обработке сигналов — мне нужно реализовать быстрое преобразование Фурье, а существующие реализации меня не устраивают потому-то и потому-то»? Или?
zzz: Или «я вставил на форму компоненту 'проигрыватель', где мне найти компоненту 'эквалайзер'?» =))
Может я чтото не понял, но вы хотите сказать что правильнее написать функциональность Х с нуля, нежели найти готовое, оттестированное, проверенное временем решение и использовать его?
А вот в чём существенная разница между интерпретируемыми мультипарадигменными языками с нестрогой динамической типизацией для «сайтов за 2000 рублей». Я вот не вижу существенной между языками «для говнокодеров» и «тру трендами». Есть нюансы, есть удобства в одном и неудобства в другом. Но вот кардинальных различий…
Так и не понял, в чем провальность первого интервью. В том, что он не рассказал, для чего нужен DI?
По поводу компиляции — ну и что, что компиляция все равно нужна, в коде-то менять не нужно же, и не будет коммитов с изменениями кода — это разве не плюс?
По поводу компиляции — ну и что, что компиляция все равно нужна, в коде-то менять не нужно же, и не будет коммитов с изменениями кода — это разве не плюс?
Опередили меня, я тоже хотел перевести эту статью:)
«Если вы действительно разбираетесь в Servlets и JSP – вам будет очень просто понять любой веб-фрейворк Java, как Struts, SpringMVC и так далее» — очень и очень спорное заявление насчет «простоты», хотя с рекомендациями изучать основы и стандарты невозможно не согласиться.
Автор сочетает в себе старческую раздражительность с юношеской категоричностью — даром, что индуист :)
Автор сочетает в себе старческую раздражительность с юношеской категоричностью — даром, что индуист :)
На самом деле, действительно понимать «все» после изучения основ проще. Это я могу сказать после того как усиленно готовился к SCWCD и SCBCD. После все этого, дейстивительно становится понятнее очень многое, в частности для чего вообще существуют фреймворки _поверх_ стандартной java (EE в том числе), и как они работают. Единственное, что сложно заставить одолеть себя 800 страничные талмуды, но экзамены этому очень способствуют.
Но я согласен, что у автора статьи действительно старческая разрадражительность и юношеская категоричность! Очень точно подмечено.
Но я согласен, что у автора статьи действительно старческая разрадражительность и юношеская категоричность! Очень точно подмечено.
А, так вот почему у него поголовно все такие на собеседованиях! Тоже, небось, индусы, почти поголовно страдающие отсутствием аналитического мышления.
Фреймворки делают тупыми тех разработчиков, которые никогда не изобретали велосипедов. имхо.
Касается не только фреймворков на Java, а вообще всех фреймворков (на Ruby, Python, PHP, .Net).
Кстати, не всем разработчикам обязательно понимать глубоко принцип работы фреймворков. Желательно, но не обязательно.
Другое дело, что в таком случае называть их Senior — некорректно.
Кстати, не всем разработчикам обязательно понимать глубоко принцип работы фреймворков. Желательно, но не обязательно.
Другое дело, что в таком случае называть их Senior — некорректно.
Я не знаю реалий страны в которой живёт автор статьи, но у нас это вполне возможно из-за того, что очень часто Джава и C# программисты не имеют профильного ВО, а программирование учили на платных годичных курсах.
Вот на этих курсах как раз и учат работе с фреймворками, паттернами и прочими вещами, которые обычно требуются при устройстве в энтерпрайз. То есть на выходе получаются кодеры, которые не умеют выйти за рамки того, чему их обучили.
Естесственно не все, но большая часть.
Вот на этих курсах как раз и учат работе с фреймворками, паттернами и прочими вещами, которые обычно требуются при устройстве в энтерпрайз. То есть на выходе получаются кодеры, которые не умеют выйти за рамки того, чему их обучили.
Естесственно не все, но большая часть.
Он индус. Из профиля: «Location: Hyderabad, Andhra Pradesh, India»
Оооо, расскажите мне про профильное ВО, где таки учат, зачем нужно DI, и в чем преимущества ORM.
Слышал, что на киевском факультете кибернетики выкладывают все паттерны за две потоковые лекции – и хотя факультет мне нравится, это смешно :) Студенты не успевают понять, зачем это нужно.
Ну вот, об этом высшем образовании это много говорит.
Это почти ничего не говорит об образовании. А у меня на физфаке одногрупники почти не усваивают материал. Зачастую, преподаватели зажаты между устаревшими законодательными нормами и студентами, которым ничего не надо.
Если бы мне прочитали хоть лекцию по паттернам – я бы выжал из преподавателя все, что мне нужно. И он был бы только рад. А раз мне никто лекции не читает – я читаю Gang of Four.
Дело ведь не в вузе, а в вас
Если бы мне прочитали хоть лекцию по паттернам – я бы выжал из преподавателя все, что мне нужно. И он был бы только рад. А раз мне никто лекции не читает – я читаю Gang of Four.
Дело ведь не в вузе, а в вас
В КПИ на факультете информатики и вычислительной техники по паттернам есть курс который читают один семестр. По J2EE тоже есть семестровый курс — там и сервлеты и jdbc и orm.
Вот сразу негатив. По крайней мере предложение выглядит именно как попытка ткнуть собеседника носом в какашки. Отбивает желание поддерживать дискуссию напрочь.
Я сам сейчас на подобных курсах учусь. Только C# и .NET 4.0. Вижу людей, которые со мной учатся. Нам преподают то, что в данный момент требуется на рынке труда. Устроиться на работу они смогут — каверзные вопросы, которые требуют глубоких знаний, задают далеко не везде. А Сениором у нас в большой компании можно стать благодаря стажу работы и полезным связям, насколько я в курсе.
Я сам сейчас на подобных курсах учусь. Только C# и .NET 4.0. Вижу людей, которые со мной учатся. Нам преподают то, что в данный момент требуется на рынке труда. Устроиться на работу они смогут — каверзные вопросы, которые требуют глубоких знаний, задают далеко не везде. А Сениором у нас в большой компании можно стать благодаря стажу работы и полезным связям, насколько я в курсе.
«Я сам сейчас на подобных курсах учусь.»
То есть про ВО сказать ничего не можете?
Речь-то не о курсах.
То есть про ВО сказать ничего не можете?
Речь-то не о курсах.
В университетах не научат ОРМ, но учат искать информацию и учат учиться в конце концов.
В этом смысле я упомянул ВО.
В этом смысле я упомянул ВО.
В этом смысле надо упоминать не «профильное ВО», а вообще ВО. Потому что учиться и искать информацию учат в любом хорошем ВУЗе, а не только профильном для программистов.
У меня складывается впечатление, что факт ВО ничего не означает. ВУЗ – отличное место, где можно найти тех людей, которые помогут получить квалификацию. Некоторые же методы обучения вводят меня в ступор; другие не стыковываются с моим образом жизни. Хотя это проблемы каждого отдельного студента.
«факт ВО ничего не означает»
Факт ВО ничего не означает. Факт хорошего ВО в хорошем ВУЗе (=означает, что человек умеет думать, (грамотно) излагать свои мысли, обладает некоторой критичностью (в том числе и к себе), умеет самостоятельно искать информацию и так далее.
Вот только списка хороших ВО и хороших ВУЗов, к сожалению, нет.
Факт ВО ничего не означает. Факт хорошего ВО в хорошем ВУЗе (=означает, что человек умеет думать, (грамотно) излагать свои мысли, обладает некоторой критичностью (в том числе и к себе), умеет самостоятельно искать информацию и так далее.
Вот только списка хороших ВО и хороших ВУЗов, к сожалению, нет.
<Сарказм он>Угу, главное в нашем деле — полезные связи <Сарказм офф>
Фреймворки дают разработчикам возможность не вникать в устройство работы, а использовать инструменты по принципу «черный ящик».
Очевидно, что лучше когда программист понимает принцип работы конкретного класса, но вряд ли он становится от этого тупее. Это уровень абстракции, так можно и до теории физических процессов в оперативной памяти дойти и возмущаться как это программисты этого не знают.
Очевидно, что лучше когда программист понимает принцип работы конкретного класса, но вряд ли он становится от этого тупее. Это уровень абстракции, так можно и до теории физических процессов в оперативной памяти дойти и возмущаться как это программисты этого не знают.
«Терпеть не могу тайны – от них воняет, как от тухлого белья» ©
Лично я каждый раз черный ящик раскурочиваю
Лично я каждый раз черный ящик раскурочиваю
Ну супер, однозначно не минус. Но это не говорит о том, что те, кто не «раскурочиваю» — тупые.
Я, например, лезу разбираться только если мне чего-то не хватает, глюки или проблемы с производительностью ну или очень интересно. Если любую мелочь изучать, то проект будет занимать очень много времени и тогда я точно стану тупым: есть нечего, еще и заказчик мозг съедает :)
Работает перевод интерфейса — работает, файлы подхватывает, ну чего мне туда лезть. То же и с более серьезными вещами, хотя тут нужно значительно аккуратнее, например, если сайт на пять страничек, а уплачено вообще за две, то нет смысл изучать устройство ORM в конкретном фреймворке, простые запросы вряд ли будут тормозить, итд.
Если бы это был опрос людей, которые работали год на одном проекте, где сталкивались и оптимизировали указанные в интервью моменты, тогда да — тупые быдлокодеры. А если они писали на нескольких языках, нескольких фреймворках и только бегло знакомились со spring и у них всего пара мелких проектов на нем, то не факт, что они не смогут изучить этот вопрос за пару дней. Я бы не откидывал сразу таких программистов, тем более, что они сейчас в дефиците.
Я, например, лезу разбираться только если мне чего-то не хватает, глюки или проблемы с производительностью ну или очень интересно. Если любую мелочь изучать, то проект будет занимать очень много времени и тогда я точно стану тупым: есть нечего, еще и заказчик мозг съедает :)
Работает перевод интерфейса — работает, файлы подхватывает, ну чего мне туда лезть. То же и с более серьезными вещами, хотя тут нужно значительно аккуратнее, например, если сайт на пять страничек, а уплачено вообще за две, то нет смысл изучать устройство ORM в конкретном фреймворке, простые запросы вряд ли будут тормозить, итд.
Если бы это был опрос людей, которые работали год на одном проекте, где сталкивались и оптимизировали указанные в интервью моменты, тогда да — тупые быдлокодеры. А если они писали на нескольких языках, нескольких фреймворках и только бегло знакомились со spring и у них всего пара мелких проектов на нем, то не факт, что они не смогут изучить этот вопрос за пару дней. Я бы не откидывал сразу таких программистов, тем более, что они сейчас в дефиците.
У меня это связано со спецификой opensource-фреймворков для php – во всех чего-то не хватает. Остается только изучать все и писать на самом простом и необременяющем. А удачные моменты забирать с собой. Правда, это уже похоже на рождение нового opensource-фреймворка
Это специфика работы программиста. Заказчику нужно заплатить 100$ и получить соответствующую фичу, ему все-равно, что фреймворк устарел и вообще всегда был «на любителя», а большинство кода проекта с дополнительным корнем «говно». Он не готов платить 2000$, что бы все переписать качественно и под хороший популярный фреймворк. Мало того, я согласен с этими заказчикам(и), это логично.
Хорошо, когда пишешь под любимый и уже самолично дописанный фреймворк/CMS, но такое не всегда возможно и, как правило, такая работа меньше стоит, так как значительно больше людей могут написать что-то «с нуля», чем доработать чужой говнокод, на неизвестном науке фреймворке.
Хорошо, когда пишешь под любимый и уже самолично дописанный фреймворк/CMS, но такое не всегда возможно и, как правило, такая работа меньше стоит, так как значительно больше людей могут написать что-то «с нуля», чем доработать чужой говнокод, на неизвестном науке фреймворке.
И снова вспоминается Джоель. (Много у него на эту тему.)
Любая абстракция полезная штука в работе, экономит время, а стало быть и деньги. Но нельзя забывать о байтах и даже битах, и даже о процессорных регистрах. Чтоб ездить на автобусе, не обязательно иметь даже водительские права, но если вы разрабатываете автомобили… (Придётся учить и химию и физику, и много чего ещё.)
Любая абстракция полезная штука в работе, экономит время, а стало быть и деньги. Но нельзя забывать о байтах и даже битах, и даже о процессорных регистрах. Чтоб ездить на автобусе, не обязательно иметь даже водительские права, но если вы разрабатываете автомобили… (Придётся учить и химию и физику, и много чего ещё.)
Что конкретно вам вспоминается?
Да многое, «о вреде обучения на JAVA», «О дырявых абстракциях», ну и конечно «Назад к основам», по сути всё что описано в этом треде Джоель описывал там.
Вкратце. Когда человек учится программировать только на высоком уровне (и забывает о низком) из него нередко получается продуктивный «конвеерник» (он может быстро реализовывать что надо, до тех пор пока не столкнётся с непредвиденной ситуацией) а разработка в более трудных условиях (когда надо искать нестандартные решения) увы требует понимания и более низкого уровня. (А привыкая к абстракциям, человек отвыкает думать «байтами» и начинает сразу думать «процедурами» или «объектами»)
Вкратце. Когда человек учится программировать только на высоком уровне (и забывает о низком) из него нередко получается продуктивный «конвеерник» (он может быстро реализовывать что надо, до тех пор пока не столкнётся с непредвиденной ситуацией) а разработка в более трудных условиях (когда надо искать нестандартные решения) увы требует понимания и более низкого уровня. (А привыкая к абстракциям, человек отвыкает думать «байтами» и начинает сразу думать «процедурами» или «объектами»)
Ну вы же не изучаете архитектуру процессора и его набор микрокоманд для написания функции, которая что-нибудь пишет в сокет? И я тоже. И это не повод для того, чтоб всех считать тупыми и поверхностными. Давайте еще изучим ту математику, которая лежит под Computer Science, и физику процессов в микросхемах, кремниевых кристаллах и т.д.
Во всем надо знать меру, в том числе и в поиске в глубину.
Для каждой узкой области должны быть специалисты, которые должны выставлять некие абстракции, которыми другие специалисты могут пользоваться, не изучая мелочи реализации. Это же основа прогресса, без этих абстракций каждому человеку приходилось бы изучать всё, что известно человечеству на данный момент.
Такой абстракцией стала уход от натурального хозяйства к разделению труда. Теперь каждый может купить какой-то «продукт», не задумываясь о цикле его производства, доставки и продажи.
Так что «вред обучения на JAVA» и «дырявые абстракции» — это личное заблуждение тов.Спольски
Во всем надо знать меру, в том числе и в поиске в глубину.
Для каждой узкой области должны быть специалисты, которые должны выставлять некие абстракции, которыми другие специалисты могут пользоваться, не изучая мелочи реализации. Это же основа прогресса, без этих абстракций каждому человеку приходилось бы изучать всё, что известно человечеству на данный момент.
Такой абстракцией стала уход от натурального хозяйства к разделению труда. Теперь каждый может купить какой-то «продукт», не задумываясь о цикле его производства, доставки и продажи.
Так что «вред обучения на JAVA» и «дырявые абстракции» — это личное заблуждение тов.Спольски
Никто (ни я ни тов.Спольски) не говорит что надо знать ВСЁ.
Человек который пишет в сокет строку, и принимает её, может не понимать как всё это работает. Но если всплывёт непредвиденная ситуация (баг в реализации его фреймворка например) то он быстрее и адекватнее среагирует если будет знать не только название функции чтения и записи, но и то как работает сеть в целом.
Человек который пишет в сокет строку, и принимает её, может не понимать как всё это работает. Но если всплывёт непредвиденная ситуация (баг в реализации его фреймворка например) то он быстрее и адекватнее среагирует если будет знать не только название функции чтения и записи, но и то как работает сеть в целом.
Вы сказали верную мысль, должна быть какая-то граница, глубже которой копать не имеет практического смысла. Но все люди разные, и каждый видит эту границу на разных уровнях погружения в предметную область. Так что наш с вами спор — это не очень-то и спор.
Замечу также. Я не назвал никого «тупыми и поверхностными» я сказал что в непредвиденных обстоятельствах, полезно знать хотя бы на уровень ниже (что в последнее время встречается всё реже и реже, а требуется всё чаще и чаще)
Какую ЗП предлагаете? Судя по собеседованию поток претендентов у вас очень большой, и ЗП видимо высока, раз так дотошно их можно отсеивать и не доучивать/переучивать.
Ох, это перевод… :)
Искренне сожалею, но мопед не мой. Но вы можете спросить у этого молодого человека: sivalabs.blogspot.com/p/my-profile.html
Вот поэтому я и не люблю неосторожно кидаться акронимами в речи, особенно на интервью. Например, REST — для большинства разработчикиов эта абревиатура зачастую означает «передавать данные между клиентом и сервером по HTTP, не используя при этом SOAP». Легче всего работать с таким HTTP API через JAX-RS. Вот люди и начинают думать о том, что раз JAX-RS, значит REST. Есть еще слово RESTful — тоже весьма скользкое, т.к. многие, произноя его, имеют в виду REST-like.
>> REST — для большинства разработчикиов эта абревиатура зачастую означает «передавать данные между клиентом и сервером по HTTP, не используя при этом SOAP»
Ну ведь правда, не обязательно использовать SOAP при реализации REST :)
Ну ведь правда, не обязательно использовать SOAP при реализации REST :)
Вообще-то SOAP и REST — это разные подходы. И фраза «использовать SOAP при реализации REST» звучит странно
REST — это архитектура, SOAP — протокол.
ru.wikipedia.org/wiki/REST
ru.wikipedia.org/wiki/REST
Друзия, пишите свои фреймворки, что бы не отупеть:)
автор оригинала из тех, кто считает что собеседование где не ищут работников, а место где собеседователь может показать какой он крутой.
если работник с помошью молотка умеет вбивать гвоздь, стоит задача вбить гвоздь, то не важно насколько он знает физику и разбирается в технологии создания этих самых молотков, он должен тупо вколачивать гвозди.
я за то, чтобы люди знали технологию изнутри, но в данной статье не показано, что это является ОБЯЗАТЕЛЬНЫМ условием, похоже, что это понты автора. вот автор явно был не готов к собеседованию и вопросы задавал не по теме.
если работник с помошью молотка умеет вбивать гвоздь, стоит задача вбить гвоздь, то не важно насколько он знает физику и разбирается в технологии создания этих самых молотков, он должен тупо вколачивать гвозди.
я за то, чтобы люди знали технологию изнутри, но в данной статье не показано, что это является ОБЯЗАТЕЛЬНЫМ условием, похоже, что это понты автора. вот автор явно был не готов к собеседованию и вопросы задавал не по теме.
Ты прав в целом, но тут нюанс вот в чём.
Если задача стоит разработать свой молоток, то соискатель должен понимать не столько «как забить гвоздь молотком» сколько «какие материалы сколько весят, насколько упруги, и прочны». А весь пост о том, что человек который работает только забивая молотком гвозди, чаще всего не следит за новинками в области химии, и даже если из школьного курса ухватил базовые понятия, то не факт что он не забыл даже их.
Если задача стоит разработать свой молоток, то соискатель должен понимать не столько «как забить гвоздь молотком» сколько «какие материалы сколько весят, насколько упруги, и прочны». А весь пост о том, что человек который работает только забивая молотком гвозди, чаще всего не следит за новинками в области химии, и даже если из школьного курса ухватил базовые понятия, то не факт что он не забыл даже их.
К сожалению, иногда оказывается, что если человек с помощью молотка умеет забивать гвозди, то и с шурупами он поступает точно так же.
Поэтому не грешно бы понимать, владеет ли кандидат областью определений молотка, и областью возвращаемых значений.
Поэтому не грешно бы понимать, владеет ли кандидат областью определений молотка, и областью возвращаемых значений.
То ли я не понял посыл статьи, то ли я какой-то полутупой. Когда начинал изучать программирование, то слова типа «фреймворк», «паттерны» и т. п. как-то в изданиях издательства «Диалог» и других не упоминались, а все считали циклы процессора и байты памяти, свято веря, что 640 КБ хватит всем :) Потом были разные языки и среды. Потом открыл для себя PHP, тоже без фреймворков и т. п. Потом в PHP появилось ООП, потом нормальный ООП :) Потом открыл для себя фреймворки. Не могу похвастать, что знаю каждую строчку в используемых, но уж основной путь прохождения запроса в дебаггере прошёл и не просто наблюдая как строчки меняются.
Но вот не так давно пытался изучить Ruby/Rails (чтобы понять что же такого там особенного, но это оффтоп) и чувствую себя тупым — я могу сделать какой-нибудь «бложик», но не понимаю как он работает. И дебаггер мало помогает как-то. Куда не ткнёшь точку прерывания — там уже сформованный контекст, отличающегося от голого Ruby
Но вот не так давно пытался изучить Ruby/Rails (чтобы понять что же такого там особенного, но это оффтоп) и чувствую себя тупым — я могу сделать какой-нибудь «бложик», но не понимаю как он работает. И дебаггер мало помогает как-то. Куда не ткнёшь точку прерывания — там уже сформованный контекст, отличающегося от голого Ruby
Ох, а мне вот пока везёт, и основную часть кода, который я пишу, идёт в движок MediaWiki, который сам себе фреймворк. Да не просто фреймворк, а в нём ещё для половины стандартных функцией есть собственные обёртки, для некоторых действий есть два а то и три интерфейса, которые не убираются из-за обратной совместимости с расширениями. Интерфейсов для расширений, кстати, тоже не мало.
Зато мозги постоянно работают. Так как движок используется на одном из top-10 сайтов в Интернете, который обслуживают меньше 500 серверов, производительность становится жизненно важным фактором. Все запросы приходится проверять через EXPLAIN на использование индексов, а функции работы с memcached я вспомню, даже если меня разбудят в 4 часа ночи. А когда выясняется, что данный кусок кода на PHP оптимизировать нельзя, и его приходится переписать на C…
Зато мозги постоянно работают. Так как движок используется на одном из top-10 сайтов в Интернете, который обслуживают меньше 500 серверов, производительность становится жизненно важным фактором. Все запросы приходится проверять через EXPLAIN на использование индексов, а функции работы с memcached я вспомню, даже если меня разбудят в 4 часа ночи. А когда выясняется, что данный кусок кода на PHP оптимизировать нельзя, и его приходится переписать на C…
Зачем JSP-то? Думаю, что-бы понимать нафига этот Spring сдался нужно написать велосипед (на любом языке), а знание Servlet и JDBC здесь не поможет :) Я особо и не изучал эти Servlet'ы и без справки не смогу написать приложение с Servlet'ом. Тем не менее, велосипедные фреймворки на PHP показали мне как всё работает на самом нижнем уровне. И почему лучше использовать готовое и зрелое решение, чем изобретать свой велосипед.
Никогда мой мозг не был совместим со Spring. Я так рад, что больше не пишу на Java… 
Примерно лет 10-12 назад по такой же схеме проходили собеседования про c++/asm.
Вопросы были из разряда «а вы сможете написать это на асме?». Ответы: «зачем мне писать это на асме, когда есть плюсы?».
И выводы делались примерно те же — «языки типа c++ делают разработчиков тупыми».
Фреймворки — обычный прогресс программирования.
Вопросы были из разряда «а вы сможете написать это на асме?». Ответы: «зачем мне писать это на асме, когда есть плюсы?».
И выводы делались примерно те же — «языки типа c++ делают разработчиков тупыми».
Фреймворки — обычный прогресс программирования.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Фреймворки делают разработчиков тупыми?