Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 239
Напомнило «Казалось бы, зачем убийце убивать убийцу убийцы, но Донцову уже было не остановить… ».
Просто гениально. Вроде хороводоводоведофилофобы.
мы представим единую фабрику фабрик фабрик инструментов
Просто гениально. Вроде хороводоводоведофилофобы.
теперь я понял, кто стоит за тенденциями в современном программировании — Донцова :)
Если брать J2EE как сущность в целом, то оно давно уже стало нечто монстроподобным. Оттуда можно брать только отдельные технологии. Для большинства приложений достаточно веб-контейнера (Tomcat, например) и для удобства как надстройку над сервлетами ещё какой-нибудь маршрутизирующе-темплейтный движок.
Остается только 1 вопрос: «Почему вы ненавидите фреймворки?»
За что минисуем господа? Я просто совсем не понял о чем пост, почему автор против фреймворкоа и как это аргументирует?
Когда стоит задача написать более-менее нормальное веб приложение, он его берет и с нуля пишет? А потом борется с союственными косяками, объясняет всем членам команды как оно работает, ибо документации конечно нет и так далее?
Или он хочет написать приложение которое принимает на вход картинку а выдает отресайзенный вариант и жалуется, что в фреймворке много лишнего?
Или он пишет приложение без hibernate, spring или jboss и сам с нуля пишет их функционал?
Мне кажется что статья глупая и не обоснованная! Атор или неправильно выбирает инструменты для задачи или неправильно понимает задачу или просто ему не хватает опыта и знаний.
Когда стоит задача написать более-менее нормальное веб приложение, он его берет и с нуля пишет? А потом борется с союственными косяками, объясняет всем членам команды как оно работает, ибо документации конечно нет и так далее?
Или он хочет написать приложение которое принимает на вход картинку а выдает отресайзенный вариант и жалуется, что в фреймворке много лишнего?
Или он пишет приложение без hibernate, spring или jboss и сам с нуля пишет их функционал?
Мне кажется что статья глупая и не обоснованная! Атор или неправильно выбирает инструменты для задачи или неправильно понимает задачу или просто ему не хватает опыта и знаний.
зачем вы столь серьёзны? это же шутка
Ровно через неделю окажется, что абстракции не всегда работают, потому что не каждый хабраюзер способен производить цепочку умозаключений, которую должны подразумевать абстракции. Посему хитом следующей недели станет хаотичная система функций, генерирующая абстракции ответа на вопрос, позволяя максимально автоматизировать процесс формирования цепочки умозаключений, которую ваш мозг конечно же проделает с присущей индивидуальной манерой, но с посеянным зерном сомнений. Торопитесь, наверняка тираж таких систем будет ограничен!
Говорила мне мама: «Никогда не пользуйся чужими программами. Тебе что, своих багов мало?»
я тоже
> «J2EE portlet-enabled JSR-compliant MVC role-based CMS web service application container фреймворков»
1. Разобрать кашу в голове
2. Выбрать технологию
3.…
4. PROFIT!
1. Разобрать кашу в голове
2. Выбрать технологию
3.…
4. PROFIT!
это и отличает наверное новичка от опытного разработчика…
У меня другой вопрос. За что вы так не любите девушек (пусть даже бывших)? :(
Они так мерзко кричат, так грязно брызгают кровищщей, так жалко пытаются уползти, когда наконец загонишь им в башку молоток с круглым бойком. (А может, ледоруб.) Фу, гадость. Нет ничего хуже бывших девушек.
На всякий случай поясню, что это не моё мнение, а моя попытка проникнуть во вкусы автора первоисточника блогозаписи.
Вспомнился Ганнибал. Мда. Хотя лучше писать, чем делать. Здоровья вам.
«What if I were to cut you up and mail each part
to a different town? It would take the most
brilliant private eye the rest of his life
just to put you together.
a piece in each mailbox all over the planet
from Moscow to Tokyo to Guadalajara.»
prostopleer.com/tracks/4533126fjPk
to a different town? It would take the most
brilliant private eye the rest of his life
just to put you together.
a piece in each mailbox all over the planet
from Moscow to Tokyo to Guadalajara.»
prostopleer.com/tracks/4533126fjPk
Я тоже ненавижу фреймворки.
И я принципиально не понимаю, например, почему многие Java-библиотеки, реализующие, казалось бы, достаточно простые функции, состоят из сотен классов и тянут за собой несколько зависимостей, еще по 500 классов каждая.
Или другой пример: возьмём opensource медиа-сервер RED5 и посмотрим на его составные части. Среди прочего, мы увидим всякие страшные и нафиг не нужные вещи вида spring application framework, библиотеки для логгинга, библиотеки для ввода/вывода, библиотеку HTTP-сервера и так далее. В результате получается монструозное нечто, запускающееся минуту и при ошибках выдающее километровые stack trace. А ведь если бы фреймворки не использовали, оно работало бы быстрее, было бы менее требовательно к ресурсам и разработка стала бы проще.
Упрощайте.
И я принципиально не понимаю, например, почему многие Java-библиотеки, реализующие, казалось бы, достаточно простые функции, состоят из сотен классов и тянут за собой несколько зависимостей, еще по 500 классов каждая.
Или другой пример: возьмём opensource медиа-сервер RED5 и посмотрим на его составные части. Среди прочего, мы увидим всякие страшные и нафиг не нужные вещи вида spring application framework, библиотеки для логгинга, библиотеки для ввода/вывода, библиотеку HTTP-сервера и так далее. В результате получается монструозное нечто, запускающееся минуту и при ошибках выдающее километровые stack trace. А ведь если бы фреймворки не использовали, оно работало бы быстрее, было бы менее требовательно к ресурсам и разработка стала бы проще.
Упрощайте.
>А ведь если бы фреймворки не использовали, оно работало бы быстрее, было бы менее требовательно к ресурсам и разработка стала бы проще.
Угу. Только тогда вам пришлось бы написать вдобавок к своей аппликухе не только сам медиа-сервер, но и HTTP-контейнер к нему (а как он будет работать без этого?). Ну, и в процессе бы выяснилось, что логгинг туда тоже не мешало бы прикрутить, да и без библиотеки ввода-вывода ни куда… :)
Угу. Только тогда вам пришлось бы написать вдобавок к своей аппликухе не только сам медиа-сервер, но и HTTP-контейнер к нему (а как он будет работать без этого?). Ну, и в процессе бы выяснилось, что логгинг туда тоже не мешало бы прикрутить, да и без библиотеки ввода-вывода ни куда… :)
Нафига HTTP-контейнер RTMP-серверу, если для этого придуманы веб-сервера? Зачем специальная библиотека для логгинга, если можно обойтись одним классом, который пишется за две минуты, или вообще System.out.println()?
> System.out.println()?
А я хочу вырубить логирование в этой библиотеки, чтобы оно мне спамило консоль. Или перенаправить вывод именно этой библиотеки в определённый файл.
А я хочу вырубить логирование в этой библиотеки, чтобы оно мне спамило консоль. Или перенаправить вывод именно этой библиотеки в определённый файл.
Мало ли зачем может понадобиться HTTP-контейнер RTMP-серверу на Java:)
Например, для веб-консоли или купертино-стримминга.
Что бы не счищать кору с бревна каменными ножими можно купить ящик с набором инструментов.
Редкий заказчик захочет заплатить за разработку базовой инфраструктуры, фреймворк — возможность получить ее с минимальными вложениями.
Проблема не в универсальных решениях, а в головах. Решайте сложные задачи максимально простым из способом приемлемых и используйте самые простые подходящие для этого инструменты.
Но
В случае одноразового ПО такой подход имеет право на существование, но пожалуйста, никогда не пишите серверный софт.
Например, для веб-консоли или купертино-стримминга.
Что бы не счищать кору с бревна каменными ножими можно купить ящик с набором инструментов.
Редкий заказчик захочет заплатить за разработку базовой инфраструктуры, фреймворк — возможность получить ее с минимальными вложениями.
Проблема не в универсальных решениях, а в головах. Решайте сложные задачи максимально простым из способом приемлемых и используйте самые простые подходящие для этого инструменты.
Но
[...] можно обойтись одним классом, который пишется за две минуты, или вообще System.out.println()?
В случае одноразового ПО такой подход имеет право на существование, но пожалуйста, никогда не пишите серверный софт.
В единичном случае это так. Но когда вы написали один класс за 5 минут, второй за 5 минут, третий и т.д. И когда возникает потребность что-то поправить в проекте, вот тогда вы поменяете свое мнение. А если не возникнет то и не поменяете. И в данном случае это будет лучшим решением.
Спорить тут бессмысленно. Если то что вы делаете полностью вас устраивает, думаю не стоит что-то менять. Лично меня никогда не устраивает мой результат работы.
Спорить тут бессмысленно. Если то что вы делаете полностью вас устраивает, думаю не стоит что-то менять. Лично меня никогда не устраивает мой результат работы.
>Нафига HTTP-контейнер RTMP-серверу, если для этого придуманы веб-сервера?
И протокол ЦГИ, что ли? Да, помню, лихие 90-е, cgi и скрипты на пёрле :).
>Зачем специальная библиотека для логгинга, если можно обойтись одним классом, который пишется за две минуты, или вообще System.out.println()?
Очевидно, для удобства. Ещё более очевидно — для мирного сосуществования с окружающей средой и единого места конфигурации. Чуть менее очевидно — для работы в многопоточном окружении, например.
Да, ничего этого не надо, если у вас наколенная аппликуха для раздачи хомпорн трём вашим друзьям. А когда часть большой системы, в которой каждая тварь конфигурит тот же логгинг в стопиццот разных местах стопиццот разными способами…
И протокол ЦГИ, что ли? Да, помню, лихие 90-е, cgi и скрипты на пёрле :).
>Зачем специальная библиотека для логгинга, если можно обойтись одним классом, который пишется за две минуты, или вообще System.out.println()?
Очевидно, для удобства. Ещё более очевидно — для мирного сосуществования с окружающей средой и единого места конфигурации. Чуть менее очевидно — для работы в многопоточном окружении, например.
Да, ничего этого не надо, если у вас наколенная аппликуха для раздачи хомпорн трём вашим друзьям. А когда часть большой системы, в которой каждая тварь конфигурит тот же логгинг в стопиццот разных местах стопиццот разными способами…
Не джавой единой )
Посмотрите на Django/Ror. В первой так вообще чтобы какая-то новая фича попала в состав фреймворка должно произойти что-то невообразимое.
Посмотрите на Django/Ror. В первой так вообще чтобы какая-то новая фича попала в состав фреймворка должно произойти что-то невообразимое.
KISS всем посоны!!!
Вы что-то перепутали… Вещи обмотаные синей изолентой вообще не разваливаются!
А еще вы забыли, что профессиональные молотки уже не продаются :)
Если человек не умеет орудовать молотком, не понимает, как устроен шкафчик, то ему и не стоит его делать, лучше купить готовый. Если он хороший менеджер и сумеет управиться с этой махиной фабрик, то он так и должен сделать.
А на деле, всё должно зависеть от масштабов проекта, именно поэтому, в реальной жизни, молотки продаются.
А на деле, всё должно зависеть от масштабов проекта, именно поэтому, в реальной жизни, молотки продаются.
>с которым просто
С которым просто текущему хозяину. А потом он тоже уезжает, приходит новый, видит этот шкафчик и думает: «А вдруг он развалится, если я его потяну не за ту ручку — такое у меня уже бывало, больше не хочу. Выкину ка я его лучше сейчас, и поставлю свой, в котором я точно знаю за какие ручки тянуть»
С которым просто текущему хозяину. А потом он тоже уезжает, приходит новый, видит этот шкафчик и думает: «А вдруг он развалится, если я его потяну не за ту ручку — такое у меня уже бывало, больше не хочу. Выкину ка я его лучше сейчас, и поставлю свой, в котором я точно знаю за какие ручки тянуть»
Вообще-то, ни одна крайность не есть хорошо. Но тут я согласен — если что-то может привести к усложнению в неумелых руках, это не значит, что нужно зарубить паттерн на корню. Пример со шкафчиком, возможно, не самый удачный. Все-таки, молотка действительно может и хватить, а фабрика фабрик фабрик молотков явно лишняя.
У кого есть голова и руки делают хороший шкафчик обычными инструментами.
У кого этого нет, приходится пользоваться фабрикой фабрик.
У кого этого нет, приходится пользоваться фабрикой фабрик.
фреймворки тут непричем.
речь идёт про DI и IoC — а они используются не во всех фреймворках.
речь идёт про DI и IoC — а они используются не во всех фреймворках.
Еще вспомнилась картинка про MVC:
Вызов страницы hello world в фреймворке Zend PHP.
habrastorage.org/storage2/057/eed/f75/057eedf756201072ad7051ff768d7259.png
Задействовано 125 файлов и 5.5 тыс вызовов функций.
Источник
habrastorage.org/storage2/057/eed/f75/057eedf756201072ad7051ff768d7259.png
Задействовано 125 файлов и 5.5 тыс вызовов функций.
Источник
Чтобы долго никто не искал, вот ссылка на большой рисунок github.com/eryx/php-framework-benchmark/raw/master/result-20111201/zf2/funmap0.png
Из этого простой вывод — если вам нужна страничка выводящая Hello World и более ничего — не стоит использоваться Zend )
Едрит-мадрит…
И причем тут IoC и DI?
В принципе, любой фреймворк и есть IoC. А DI — частный случай IoC.
«любой фреймворк и есть IoC»
Поясните мысль?
Поясните мысль?
Лучше всего мою мысль пояснит цитата:
Одной важной характеристикой фреймворка является то, что методы, определенные пользователем для адаптации фреймворка под свои нужды, будут чаще всего вызываться внутри самого же фреймворка, а не из кода приложения пользователя. Фреймворк часто играет роль главной программы в координации и последовательности действий приложения. Такая инверсия управления дает фреймворку возможность служить расширяемым скелетом приложения. Методы, предоставляемые пользователем, адаптируют общие алгоритмы, определенные фреймворком, под определенное приложение.
Ральф Джонсон и Брайан Фут.
Без умных слов, попробую. Типичны два варианта непосредственного использования стороннего (для проекта) кода: библиотеки и фреймворки (про копипаст замнём для ясности). Существенная, имхо, разница в контроле со стороны разработчика над потоком выполнения — с библиотеками мы запускаем свой код, вызывающий код библиотеки, когда сочтём нужным, а с фреймворками мы запускаем код фреймворка, который вызывает наш код, когда сочтёт нужным. Во втором случае мы можем только намекнуть ему, что хотим в такой-то ситуации получить управление — «магия», соглашения, конфиги. и т. п.
Правда с этой точки зрения большинство популярных фреймворков являются «2-в-1» — есть как каркас приложения, который вызывает наш код, так и обычная библиотека, код которой мы вызываем. Ещё больше запутывает то, что вызываемый код библиотеки может тоже вызывать наш код — например, библиотека с использованием колбеков- такие библиотеки отчасти тоже можно считать фреймворками.
Правда с этой точки зрения большинство популярных фреймворков являются «2-в-1» — есть как каркас приложения, который вызывает наш код, так и обычная библиотека, код которой мы вызываем. Ещё больше запутывает то, что вызываемый код библиотеки может тоже вызывать наш код — например, библиотека с использованием колбеков- такие библиотеки отчасти тоже можно считать фреймворками.
С этим я не спорю и полностью согласен. Сам проектировал несколько специализированных фреймворков и работал со многими.
Но я бы ни за что не стал утверждать, что «Framework = IoC». Во-первых, это может быть не так, а во-вторых, IoC, как архитектурный подход, все же, более конкретен, чем определение фреймворка. Фреймворк может использовать конкретные приемы/паттерны, или концепцию IoC для своего «control flow», а может не использовать. В частности, фреймворк отнюдь не обязательно уменьшит связанность между компонентами (основная задача IoC), а скорее задаст некоторое «направление» приложению.
Так что, на мой взгляд, это совершенно разные вещи.
Но я бы ни за что не стал утверждать, что «Framework = IoC». Во-первых, это может быть не так, а во-вторых, IoC, как архитектурный подход, все же, более конкретен, чем определение фреймворка. Фреймворк может использовать конкретные приемы/паттерны, или концепцию IoC для своего «control flow», а может не использовать. В частности, фреймворк отнюдь не обязательно уменьшит связанность между компонентами (основная задача IoC), а скорее задаст некоторое «направление» приложению.
Так что, на мой взгляд, это совершенно разные вещи.
По-моему тут IoC имелся в виду не как паттерн, а как принцип работы фреймворка в целом. Просто если не фреймворк вызывает наш код, а мы вызываем его, то в чём его отличие от библиотеки? Плюс, субъективно далеко не всё, что называется (авторами или сообществом — не суть) фреймворком им на самом деле является.
>мы представим единую фабрику фабрик фабрик инструментов
Я могу ошибаться, но такой маразм типичен в первую очередь для Java. За время моего знакомства с ней (ксчастьюсожалению, впрочем, довольно краткого), мне хватило, например, этого маразма.
Я могу ошибаться, но такой маразм типичен в первую очередь для Java. За время моего знакомства с ней (к
Не осилил DocumentBuilderFactory? Печаль.
Что там осваивать? Не монады в Хаскелле поди.
Сам факт что это реализовано таким…… ТАКИМ способом (а судя по ответам на мой коммент, это ещё и в порядке вещей в этом языке), вызывает грусть, печаль, уныние и снижение валового продукта в стране.
Сам факт что это реализовано таким…… ТАКИМ способом (а судя по ответам на мой коммент, это ещё и в порядке вещей в этом языке), вызывает грусть, печаль, уныние и снижение валового продукта в стране.
Так именно же — осваивать нечего, всё просто.
Вас Factory pattern пугает?
Вас Factory pattern пугает?
>Вас Factory pattern пугает?
Он меня не пугает. Он у меня вызывает раздражение. (То же самое, судя по всему, можно сказать и о авторе данного топика, к слову).
Он меня не пугает. Он у меня вызывает раздражение. (То же самое, судя по всему, можно сказать и о авторе данного топика, к слову).
Я вам сочувствую, но это ваша проблема.
Ничего плохого в Factory паттерне нет. А пост, между прочим, шуточный (-:
Конкретной в данной ветке комментариев речь идёт не вообще о бесконечном громождении Factory of Factory of Factory каком-то, а о DocumentBuilderFactory конкретно. И в случае с DocumentBuilderFactory никакого громождения нет, нет мета-уровня над DocumentBuilderFactory.
И пусть в некотороых случаях есть мета-уровень когда есть Factory of Factory, но есть ли в этом смысл — нужно разбираться в каждом конкретном случае.
Паттерны ООП это _хорошо_, если вам не нравятся паттерны, а значит, видимо, и ООП, это ваше личное горе, и никак иначе.
Ничего плохого в Factory паттерне нет. А пост, между прочим, шуточный (-:
Конкретной в данной ветке комментариев речь идёт не вообще о бесконечном громождении Factory of Factory of Factory каком-то, а о DocumentBuilderFactory конкретно. И в случае с DocumentBuilderFactory никакого громождения нет, нет мета-уровня над DocumentBuilderFactory.
И пусть в некотороых случаях есть мета-уровень когда есть Factory of Factory, но есть ли в этом смысл — нужно разбираться в каждом конкретном случае.
Паттерны ООП это _хорошо_, если вам не нравятся паттерны, а значит, видимо, и ООП, это ваше личное горе, и никак иначе.
>Паттерны ООП это _хорошо_, если вам не нравятся паттерны, а значит, видимо, и ООП, это ваше личное горе, и никак иначе.
Я долго думал, как на это ответить.
Так вот. Я не имею ничего против ООП.
Когда его использование оправдано.
Я могу понять объектную реализацию дерева DOM, создаваемого парсером XML.
Мне трудно понять, зачем нужно создавать объект DocumentBuilder, практически единственной функцией которого и является парсинг XML — документа. Вы меня извините, я может быть чего то не понимаю, но по-моему, в docs.oracle.com/javase/1.4.2/docs/api/javax/xml/parsers/DocumentBuilder.html — всё, кроме разве что getDOMImplementation() можно засунуть в вызов единственной функции с перегрузками под разные источники входящих данных (последнее — оковы статической типизации, что уж поделать).
Но смысл существования DocumentBuilderFactory — класса, который нужен только и единственно затем чтобы его инстанциировать и плодить (ненужные) объекты DocumentBuilder, присыпая их разными конфигурационными параметрами самого создаваемого парсера, я осознать не могу.
Точнее нет. Я могу. Я сочувствую работникам IT-отрасли индийского происхождения, которым платят за SLOC. Этот язык, с его идеологией, в принципе является инструментом, благотворным для них.
Я долго думал, как на это ответить.
Так вот. Я не имею ничего против ООП.
Когда его использование оправдано.
Я могу понять объектную реализацию дерева DOM, создаваемого парсером XML.
Мне трудно понять, зачем нужно создавать объект DocumentBuilder, практически единственной функцией которого и является парсинг XML — документа. Вы меня извините, я может быть чего то не понимаю, но по-моему, в docs.oracle.com/javase/1.4.2/docs/api/javax/xml/parsers/DocumentBuilder.html — всё, кроме разве что getDOMImplementation() можно засунуть в вызов единственной функции с перегрузками под разные источники входящих данных (последнее — оковы статической типизации, что уж поделать).
Но смысл существования DocumentBuilderFactory — класса, который нужен только и единственно затем чтобы его инстанциировать и плодить (ненужные) объекты DocumentBuilder, присыпая их разными конфигурационными параметрами самого создаваемого парсера, я осознать не могу.
Точнее нет. Я могу. Я сочувствую работникам IT-отрасли индийского происхождения, которым платят за SLOC. Этот язык, с его идеологией, в принципе является инструментом, благотворным для них.
OMG
Фабрика здесь для того, чтоб отделить создание конкретной реализации от интерфейса, ибо DocumetnBuilder это интерфейс, а имплементации у него разные. Вы вообще в курсе зачем Factory паттерн нужен?
И потом, DocumentBuilder-ы они не thread safe, и поэтому нельзя создать один и юзать его в хвост и в гриву, или засунуть эту не thread-safe функциональность «в вызов единственной функции», которая статическая должна быть видимо, и пользовать одну функцию на всё.
Если вы скажете «нафиг ООП» и засунете логику парсания в одну статик функцию, вы не сможете например подменять имплементации этой функции для unit-тестирования. И если уж вы пишете на объектно ориентированном языке программирования, то к чёрту 100500 статических функций — пишите нормально, с объектной моделью.
Если же вам процедурное программирование мило, а ООП — зло, вам пора в машину времени и в 80-е.
> Я сочувствую работникам IT-отрасли индийского происхождения
А я сочувствую вам.
Фабрика здесь для того, чтоб отделить создание конкретной реализации от интерфейса, ибо DocumetnBuilder это интерфейс, а имплементации у него разные. Вы вообще в курсе зачем Factory паттерн нужен?
И потом, DocumentBuilder-ы они не thread safe, и поэтому нельзя создать один и юзать его в хвост и в гриву, или засунуть эту не thread-safe функциональность «в вызов единственной функции», которая статическая должна быть видимо, и пользовать одну функцию на всё.
Если вы скажете «нафиг ООП» и засунете логику парсания в одну статик функцию, вы не сможете например подменять имплементации этой функции для unit-тестирования. И если уж вы пишете на объектно ориентированном языке программирования, то к чёрту 100500 статических функций — пишите нормально, с объектной моделью.
Если же вам процедурное программирование мило, а ООП — зло, вам пора в машину времени и в 80-е.
> Я сочувствую работникам IT-отрасли индийского происхождения
А я сочувствую вам.
А пост, между прочим, шуточный (-:
В каждой шутке есть доля… шутки.
В каждой шутке есть доля… шутки.
А мне статья напомнила эту habrahabr.ru/post/139535/, делая акцент на универсиализации (да простит меня русский язык).
Вы сделали мой день.
Вы сломали мой русский мозг.
Насколько я понял, имелось ввиду выражение «Make my day»
Сарказм засчитан. Просто вы поздно пришли — тут товарища DeusModus сначала стали минусовать, видимо по незнанию зарубежных мемов — я просто пояснил.
Трудности перевода, простите :)
и не русский тоже
Если автор ненавидит фреймворки, его никто не заставляет их использовать.
Он всегда может написать свой фреймворк, и убедить всех, что этот фреймворк гениален, ведь решает только нужные автору задачи.
Он всегда может написать свой фреймворк, и убедить всех, что этот фреймворк гениален, ведь решает только нужные автору задачи.
Вот именно, он будет решать только нужные автору задачи, это не модно — нужно создавать фреймворк для построения фреймворков которые будут решать нужную задачу, но поскольку очень обременительно создавать по фреймворку для создания фреймворков под определенный круг задач, стоит озаботится созданием одного универсального фреймворка для создания фреймворков для создания фреймворков под определенный круг задач.
Язык программирования — это и есть универсальный фреймворк для создания фреймворков для создания фреймворков под определённый круг задач.
Впрочем, всегда остаётся возможность написания своего собственного языка программирования (с блэкджеком и указателями) для написания своих собственных языков для создания универсальных фреймворков… ну в общем, вы поняли.
Впрочем, всегда остаётся возможность написания своего собственного языка программирования (с блэкджеком и указателями) для написания своих собственных языков для создания универсальных фреймворков… ну в общем, вы поняли.
И назвать его «Молоток».
Фреймворк фреймворку рознь. Взять, к примеру, Django — пять лет назад я впервые прошел по ней туториал и сделал гостевую книгу. Если проделать те же шаги сейчас, с самым последним транком, мы получим ту же гостевую книгу. Это отличный пример того, как фреймворк с годами обрастает фичами, не превращаясь в непонятного монстра, напичканного уймой разных модных технологий.
Как сказали выше, не нужно впадать в крайности.
Как сказали выше, не нужно впадать в крайности.
А мне по этой же причине CodeIgniter на PHP нравится, вот просто по-человечески нравится. Да, я знаю про все его недостатки, но зато в нем можно взять только то, что нужно тебе, и сделать на базе этого что-то быстрое и чистое.
Согласен!
Можно ссылочки почитать про недостатки?
Можно ссылочки почитать про недостатки?
Недостаток — в его критике, коей довольно много. Из-за этого новички трижды подумают, прежде чем его изучать. А это отрицательно сказывается на его развитии и продаваемости решений на нём.
Чистую правду сказал ainu, основной недостаток — чересчур критичное отношение к нему сообщества. Разработчики вообще очень критичны к тому, что отлично от привычных им инструментов. Про недостатки конкретных слов найти сложно, в основном пеняли всегда за тяжелое наследие пхп4, несколько нестандартную модель ооп, отсутствие некоторых жизненно необходимых некоторым людям модулей… Ну и за неповоротливость в развитии, но как по мне, так сами критиканы в этом и виноваты, что народ отпугивают.
Да, с рельсой такое не пройдет, и меня это огорчает :(
Ощущения от фреймворков автор передал просто шикарно.
браво!
п.с. не все фреймворки, правда, настолько плохие. имхо.
п.с. не все фреймворки, правда, настолько плохие. имхо.
Даа, любую проблему можно решить путём введения дополнительного уровня абстракции… :)
Текстик старенький, конечно, но…
Классика бессмертна.
P.S. Блин, где же я видел этот текст? Точно же помню, что видел. Гугл подводит.
Классика бессмертна.
P.S. Блин, где же я видел этот текст? Точно же помню, что видел. Гугл подводит.
Спасибо за небольшое освещение проблемы фреймворков!
… не зря интуиция подсказывала мне — писать собственный: и документация всегда в голове, и архитектура — как на ладони, а отсюда — гибкость.
… однако, перевод достаточно грубоват: не стоит уничтожать глаза, да и девушки не виноваты. Хоть это и было в оригинале.
… не зря интуиция подсказывала мне — писать собственный: и документация всегда в голове, и архитектура — как на ладони, а отсюда — гибкость.
… однако, перевод достаточно грубоват: не стоит уничтожать глаза, да и девушки не виноваты. Хоть это и было в оригинале.
Документация всегда в вашей голове! Много ли сейчас проектов пишет разработчик соло?
К тому же, код, написанный год тому назад, не узнаваем сегодня.
К тому же, код, написанный год тому назад, не узнаваем сегодня.
Актуально, если вам нужен всего один шкафчик. А если вы продаете их клиентам.
И вот приходит к вам клиент и говорит: «А я хочу вот такой же шкафчик только со стеклянными дверками». А молоточек-то у вас не подходит. Вы идете в магазин и покупаете еще один инструмент, подходящий, чтобы стеклянные дверки сделать.
А потом другой клиент говорит: «А я хочу такой же вот, только на колесиках». Вы идете опять в магазин и покупаете новый инструмент и задумываетесь, не лучше было бы с самого начала фабрику инструментов купить?
И вот приходит к вам клиент и говорит: «А я хочу вот такой же шкафчик только со стеклянными дверками». А молоточек-то у вас не подходит. Вы идете в магазин и покупаете еще один инструмент, подходящий, чтобы стеклянные дверки сделать.
А потом другой клиент говорит: «А я хочу такой же вот, только на колесиках». Вы идете опять в магазин и покупаете новый инструмент и задумываетесь, не лучше было бы с самого начала фабрику инструментов купить?
Никто не заставляет использовать фреймворки. Напишите CGI приложение и подключите его к Apache/IIS/… Правда по некоторым квалификациям тут уже веб-сервер будет выполнять роль фреймворка. Значит просто пишем демон, слушающий сокет на 80м- порту и обрабатывающий HTTP по всем спецификациям. Для очистки совести можно перед ним повесить прокси-сервер, обрабатывающий статику. Или даже преобразующий HTTP-запрос в запрос FastCGI/WSGI/SCGI…
Я пробовал такой путь на Java/C#/Python/Ruby/Erlang — муторно, но даёт ответ на вопрос зачем нужны фреймворки: чтобы не писать самому циклы обработки сокетов и преобразования приходящих в сокет данных в структуры данных ЯП, последовательности вызовов обработчиков и преобразование результата в виде структур в ответ, отсылаемый по сокету. А дальше уже вопрос выбора конкретного фреймворка — насколько сильное преобразование вам нужно. Может достаточно преобразования HTTP в массив/хэш, а может нужен разбор параметров и гибкая диспетчеризация, плюс архитектура MVC, кэширование, скафоолдин и прочее.
Я пробовал такой путь на Java/C#/Python/Ruby/Erlang — муторно, но даёт ответ на вопрос зачем нужны фреймворки: чтобы не писать самому циклы обработки сокетов и преобразования приходящих в сокет данных в структуры данных ЯП, последовательности вызовов обработчиков и преобразование результата в виде структур в ответ, отсылаемый по сокету. А дальше уже вопрос выбора конкретного фреймворка — насколько сильное преобразование вам нужно. Может достаточно преобразования HTTP в массив/хэш, а может нужен разбор параметров и гибкая диспетчеризация, плюс архитектура MVC, кэширование, скафоолдин и прочее.
Знакомая ситуация :)
Может получиться так, что пока Петя искал фабрики фрэймворков фабрик на Java, конкурент Вася слепил за неделю веб-приложение на PHP, которое работает медленно, содержит баги, имеет только 50% от функционала, состоит из говнокода чуть менее, чем полностью, яваскрипт перемежается в нём эскуэлем, и будущие программисты вынужденные добавлять новый функционал проклянут Васю и перепишут приложение пару раз с нуля.
Но оно уже работает и приносит деньги :)
Может получиться так, что пока Петя искал фабрики фрэймворков фабрик на Java, конкурент Вася слепил за неделю веб-приложение на PHP, которое работает медленно, содержит баги, имеет только 50% от функционала, состоит из говнокода чуть менее, чем полностью, яваскрипт перемежается в нём эскуэлем, и будущие программисты вынужденные добавлять новый функционал проклянут Васю и перепишут приложение пару раз с нуля.
Но оно уже работает и приносит деньги :)
Только его не Вася зовут, а так да, приносит деньги.
Ага, только тормозит, пользователи плюются, фичи добавляются медленно и ломают старые, а когда появляется конкурент с нормальным функционалом — быстро переходят к нему, лишая старого тех крох, которые вы назвали деньгами и всего остального.
Вот же вы какие а!
Может получится так, что пока Петя искал фабрики фрэймворков фабрик на Javа, конкурент Вася сделал за неделю качественное веб-приложение на PHP, которое работет быстро безглючно, в нем нет багов, потому что Вася профессионал в своем деле, не содержит говнокод, хорошо документированно, разделено на слои, и будущие программисты будут читать код и восхищатся.
Язык программирования всего лишь инструмент, вы думаете на PHP нельзя сделать фабрики фабрик фабрик, или на Java нельзя наговнокодить, как же вы заблуждаетесь. Просто для всего свое место.
Может получится так, что пока Петя искал фабрики фрэймворков фабрик на Javа, конкурент Вася сделал за неделю качественное веб-приложение на PHP, которое работет быстро безглючно, в нем нет багов, потому что Вася профессионал в своем деле, не содержит говнокод, хорошо документированно, разделено на слои, и будущие программисты будут читать код и восхищатся.
Язык программирования всего лишь инструмент, вы думаете на PHP нельзя сделать фабрики фабрик фабрик, или на Java нельзя наговнокодить, как же вы заблуждаетесь. Просто для всего свое место.
Энтерпрайз-стайл замечательно описывается чудесным стихотворением: «Дом, который построил Джек».
Зато потом, когда уже построили дом, со всеми предварительными фабриками фабрик фабрик, так просто и приятно можно будет сделать перепланировку, добавить к дому комнату или целый этаж, загон для кроликов и просторную конюшню — буквально в пару кликов.
Но это будет сильно потом, а пока — пишем тонны однообразного кода :)
Но это будет сильно потом, а пока — пишем тонны однообразного кода :)
Фабрика домов, который построил Джек
Зачем вам веб приложение? Лучше пишите рассказы.
Огромный фреймворк — огромная беда. Предпочитаю использовать небольших библиотеки, с понятными входами\выходами. Их всегда можно отладить\заменить, они дают в руки те самые молотки и рулетки, а уж думать головой как их использовать — я буду сам.
Понадобилось одному джуниору написать тулзу на Java, которая парсит билд-лог большого продукта и рассылает результаты с прикрепленной информацией из SVN по корпоративной почте. Что же в classpath этой тулзы?
Зато с задачей джуниор справился быстро и тулза работает. Область применения тулзы не накладывает никаких ограничений на потребления ресурсов, время выполнения и прочее. Тулзу легко изменять и кастомизировать.
Мораль: не так уж плохи фрэйморки, просто нужно понимать где и как их можно/нужно использовать. А молотки на самом деле никто не отменял, они все так-же доступны для использования всем желающим.
Зато с задачей джуниор справился быстро и тулза работает. Область применения тулзы не накладывает никаких ограничений на потребления ресурсов, время выполнения и прочее. Тулзу легко изменять и кастомизировать.
Мораль: не так уж плохи фрэйморки, просто нужно понимать где и как их можно/нужно использовать. А молотки на самом деле никто не отменял, они все так-же доступны для использования всем желающим.
слишком хорошо для джуниора
Религия мне не позволяет называть себя не джуниором, до тех пор пока я все-таки не переосилю свою лень и не прочитаю пару книжек. Фрэйморки с документацией, гуглы и форумы, это все конечно хорошо, но java-core нужно знать, и книжки читать. А лезть в гугл что бы вспомнить чем отличается ArrayList от LinkedList — такое позволительно только джуниору.
а зачем там транзакции?
jboss-transaction? hibernate-core тянет как зависимость.
«парсит билд-лог большого продукта и рассылает результаты с прикрепленной информацией из SVN по корпоративной почте»
А хибернейт то зачем?..
И одновременно драйвер SQLite (SQLJet) и Derby… что-то явно лишнее.
Промежуточные данные не обязательно хранить в БД, и уж тем более не обязательно для каких-то промежуточных данных использовать ORM.
Хотя освоить ОРМ это конечно круто (-:
А хибернейт то зачем?..
И одновременно драйвер SQLite (SQLJet) и Derby… что-то явно лишнее.
Промежуточные данные не обязательно хранить в БД, и уж тем более не обязательно для каких-то промежуточных данных использовать ORM.
Хотя освоить ОРМ это конечно круто (-:
И если Вы хотите убить свою бывшую девушку, то ничто не заменит молотка с круглым бойком. — спасибо, буду знать.
Я тоже ненавижу фреймворки вроде JQuery.
Всё, что они предлагают либо уже есть, либо реализуется в несколько строк кода без всяких JQuery.
Всё, что они предлагают либо уже есть, либо реализуется в несколько строк кода без всяких JQuery.
А зачем писать 15 строк, если можно просто написать?
$('#element').fadeIn();
1 function fadeIn(el, total,period) {
2 var step=total/(period*30),period=1000/30;
3 setTimeout(
4 (function (el, period, step,total) {
5 var opa=0;
6 return function () {
7 opa+=step;
8 opa < total&&setTimeout(arguments.callee, period);
9 el.style.opacity=opa;
10 }
11 })(el, period, step,total),
12 period);
13 }
Лучше подключить ещё один говнофреймворк с кучей ненужных функций с кучей избыточного кода, увеличить время загрузки страницы и добавить лишнюю зависимость.
И ещё, минусуйте на здоровье.
2 var step=total/(period*30),period=1000/30;
3 setTimeout(
4 (function (el, period, step,total) {
5 var opa=0;
6 return function () {
7 opa+=step;
8 opa < total&&setTimeout(arguments.callee, period);
9 el.style.opacity=opa;
10 }
11 })(el, period, step,total),
12 period);
13 }
Лучше подключить ещё один говнофреймворк с кучей ненужных функций с кучей избыточного кода, увеличить время загрузки страницы и добавить лишнюю зависимость.
И ещё, минусуйте на здоровье.
В старых IE — не работает, arguments.callee — depracated, куча магических чисел. Что значит period*30? Зачем вы потом его делаете равным 1000/30 (это, видимо, 30 фпс?).
Что, если элемент уже отображён, или его opacity равно 0.5? Что, если кто-то запустил второй fadeIn или fadeOut к этом элементу паралельно? Например, навели на коммент на хабре — он начал появлятся, убрали мышку с коммента до того, как он появился — элемент пропадает. Зачем дважды повторять setTimeout? Если два элемента паралельно запустить — у них может быть рассинхрон из-за того, что в разных таймаутах — будет стробить.
Давайте, так по чуть-чуть и вы тут в комментах jQuery напишите)
Что, если элемент уже отображён, или его opacity равно 0.5? Что, если кто-то запустил второй fadeIn или fadeOut к этом элементу паралельно? Например, навели на коммент на хабре — он начал появлятся, убрали мышку с коммента до того, как он появился — элемент пропадает. Зачем дважды повторять setTimeout? Если два элемента паралельно запустить — у них может быть рассинхрон из-за того, что в разных таймаутах — будет стробить.
Давайте, так по чуть-чуть и вы тут в комментах jQuery напишите)
1 о стандартах
Если браузер не соответствует стандартам, то это проблема браузера, а не разработчика.
Кроссбраузерные извращения не нужны, если код использует стандартные функции, которые работают соответственно стандарту.
Если используются нестандартные расширения (которые почти всегда дают выигрыш, например toSource или btoa и atob мозиллы), тогда проблема разработчика — предусмотреть их отсутствие.
Так что на старый ие и я, и все нормальные разработчики давно клали.
Более того, я вообще ие не учитываю, так как этот браузер ощутимо проигрывает хрому, файрфоксу и опере, пусть лучше посетитель сменит это г**** на нормальный браузер.
Посетитель от этого выиграет.
То, что в некоторых фирмах не разрешают устанавливать браузер по вкусу — проблема фирмы.
Скажи админу, админ установит. Уверен, что ему тоже не нравится эксплорер. Также можно отлично юзать портативку.
2 >deprecated
bugs.ecmascript.org/show_bug.cgi?id=263
3 вы правильно поняли, что 30 — это fps
1000 — микросекунд в секунде
period — время анимации, после присваивания используется в качестве времени между кадрами
step=total/(period*30) — приращение непрозрачности
пришлось покапитанствовать
30 не вынесена в константу из соображений 13 строк кода
4 >Что, если элемент уже отображён, или его opacity равно 0.5
исчезнет и проявится, вполне в соответствии с названием
изменить, чтобы проявлялось от текущего уровня несложно.
>Что, если кто-то запустил второй fadeIn или fadeOut к этом элементу паралельно
Я просто исходя из названия набросал функцию проявления до определённой непрозрачности.
Возможность параллельного запуска (как и fadeIn/fadeOut) не была предусмотрена, ибо во-первых нафиг (мы же не jquery пишем, а функцию под конкретные задачи), а во-вторых вряд ли бы уложился в 13 строк кода. Просто нужно тогда к DOMNode прицепить свойство — состояние фейда, и от него плясать.
5 >Давайте, так по чуть-чуть и вы тут в комментах jQuery напишите)
это вряд ли
Если браузер не соответствует стандартам, то это проблема браузера, а не разработчика.
Кроссбраузерные извращения не нужны, если код использует стандартные функции, которые работают соответственно стандарту.
Если используются нестандартные расширения (которые почти всегда дают выигрыш, например toSource или btoa и atob мозиллы), тогда проблема разработчика — предусмотреть их отсутствие.
Так что на старый ие и я, и все нормальные разработчики давно клали.
Более того, я вообще ие не учитываю, так как этот браузер ощутимо проигрывает хрому, файрфоксу и опере, пусть лучше посетитель сменит это г**** на нормальный браузер.
Посетитель от этого выиграет.
То, что в некоторых фирмах не разрешают устанавливать браузер по вкусу — проблема фирмы.
Скажи админу, админ установит. Уверен, что ему тоже не нравится эксплорер. Также можно отлично юзать портативку.
2 >deprecated
bugs.ecmascript.org/show_bug.cgi?id=263
3 вы правильно поняли, что 30 — это fps
1000 — микросекунд в секунде
period — время анимации, после присваивания используется в качестве времени между кадрами
step=total/(period*30) — приращение непрозрачности
пришлось покапитанствовать
30 не вынесена в константу из соображений 13 строк кода
4 >Что, если элемент уже отображён, или его opacity равно 0.5
исчезнет и проявится, вполне в соответствии с названием
изменить, чтобы проявлялось от текущего уровня несложно.
>Что, если кто-то запустил второй fadeIn или fadeOut к этом элементу паралельно
Я просто исходя из названия набросал функцию проявления до определённой непрозрачности.
Возможность параллельного запуска (как и fadeIn/fadeOut) не была предусмотрена, ибо во-первых нафиг (мы же не jquery пишем, а функцию под конкретные задачи), а во-вторых вряд ли бы уложился в 13 строк кода. Просто нужно тогда к DOMNode прицепить свойство — состояние фейда, и от него плясать.
5 >Давайте, так по чуть-чуть и вы тут в комментах jQuery напишите)
это вряд ли
Об этом и речь. А я написал одну строчку и обо всём этом даже не задумывался
Если браузер не соответствует стандартам, то это проблема браузера, а не разработчика.
Ну как-то уж совсем…
Если браузер не соответствует стандартам, то это проблема браузера, а не разработчика.
Отбросим экономический эффект такой точки зрения. А вот навскидку — с каким стандартом совместим этот код?
Отбросим экономический эффект такой точки зрения. А вот навскидку — с каким стандартом совместим этот код?
скажите, вы зачем пробелы экономите?
За такое тимлид может и ледорубом.
А потом столкнуться с тем, что не хватает «вот такого» эффекта? Или «вот эдакого»? Потом с тем, что в одном браузере все не так, как в другом. И т.д., и т.п.
Можете убить меня, но я подключаю jQuery с надеждой, что его код более оттестированyный и кроссбраузерный, чем любые 15 строк, которые я напишу на чистом JavaScript.
Я тоже ненавижу языки вроде С++.
Всё, что они предлагают либо уже есть, либо реализуется в несколько строк ассемблерного кода без всяких C++.
Всё, что они предлагают либо уже есть, либо реализуется в несколько строк ассемблерного кода без всяких C++.
вот только jQuery — это не фреймворк
Это прокладка между другим фреймворком (браузером) и вашим кодом :) Внутренняя обёртка, или скорее обивка. Но для разработчика это фреймворк получается, инкапсулирующий другой фреймворк.
это же просто библиотека
Сложно, по-моему, сказать «библиотека» про инструмент который позволяет навешивать обработчики на внешние события. Типичный сценарий использования jQuery (по крайней мере мой) выглядит как инициализация и последующее ожидание внешних событий, и то инициализация зачастую тоже вешается на событие и собственно исполняемый код заключается в $(document).ready(Init) — по сути установка точки входа, минимально необходимое конфигурирование фреймворка, потом мой код теряет поток выполнения и дальше вызывается только в ответ на события.
Почему я склонен считать jQuery фреймворком (работающим поверх, хотя вернее внутри другого фреймворка — браузера) — мой код не владеет потоком выполнения, он вешает события посредством jQuery и как бы от него же (а может и только от него, не смотрел код bind и т. п., не исключаю, что jQuery оборачивает мои хэндлеры в свои) время от времени получает события для обработки. По сути типичная для фреймворка схема — свой код непосредственно не исполняется, а получает управление на время с помощью хуков, событий или конвенций.
Почему я склонен считать jQuery фреймворком (работающим поверх, хотя вернее внутри другого фреймворка — браузера) — мой код не владеет потоком выполнения, он вешает события посредством jQuery и как бы от него же (а может и только от него, не смотрел код bind и т. п., не исключаю, что jQuery оборачивает мои хэндлеры в свои) время от времени получает события для обработки. По сути типичная для фреймворка схема — свой код непосредственно не исполняется, а получает управление на время с помощью хуков, событий или конвенций.
Фреймворк — это каркас приложения.
А браузер это не каркас js-кода в клиентском веб-приложении? А jQuery не инкапсулирует этот каркас в себя (оставляя возможность к нему достучаться, но для многих задач снимая необходимость взаимодействовать с браузером напрямую)?
С тем же успехом каркасом приложения можно считать winapi.
Отчасти да. WinAPI задаёт структуру большинства win-приложений (цикл получения событий и их обработка, какие-то оконные функции и т. п., емнип — давно это было).
Нужно понимать, что большинство фреймворков сочетают в себе собственно фреймворк (инверсия управления — фремйворк вызывает ваш код когда «хочет») и библиотеки «хелперов» (код, который вы можете вызывать из своего когда хотите).
Нужно понимать, что большинство фреймворков сочетают в себе собственно фреймворк (инверсия управления — фремйворк вызывает ваш код когда «хочет») и библиотеки «хелперов» (код, который вы можете вызывать из своего когда хотите).
В англоязычной Википедии определение фреймворка вот какое: «It is a collection of software libraries providing a defined application programming interface (API)».
кажется, я осознал гениальность IKEA
Не блин, тут не про фреймворки, а про то, что абстракции должны быть там, где они реально нужны. Over-engineering — известная проблема, но это не значит, что не нужны фреймворки или какие-то паттерны.
Но статья классная — для тех, кто постоянно норовит за-over-engineer'ить решение.
Но статья классная — для тех, кто постоянно норовит за-over-engineer'ить решение.
Почему я ненавижу гнилой базар. Просто будучи гипотетически начальником не взялся бы за разработку на продуктах, которые несут сами по себе кучу рисков на абсолютно ровном месте. При этом находятся «проплаченные» и идиоты, которые орут от восторга, как все замечательно. Но за гнилой базар надо отвечать, хотя бы делом.
И обсуждать это нет никакого смысла.
И обсуждать это нет никакого смысла.
Название поста нужно переформулировать так «Почему я ненавижу Java-фреймворки».
«Жизнь слишком коротка, чтобы писать всё на Assembler'е»
С одной стороны, начинать программировать с какого-то продвинутого движка, который строится на продвинутом фреймворке, который базируется на продвинутом языке, который компилируется в продвинутый промежуточный язык, который затем исполняется на продвинутом процессоре с сотнями вспомогательных инструкций, который содержит продвинутые блоки, которые состоят из продвинуто-скомпонованных транзисторов, которые делаются по продвинутым методам фотолитографии, которая базируется на продвинутых свойствах оптики и химии… Можно продолжать бесконечно. Это вопрос прогресса вообще. Времена, когда человек мог поместить в себе все научные знания о мире прошли, поэтому мы всё чаще полагаемся на здравый смысл и мануал. К счастью, есть ещё в мире люди, которые пытаются делать всё с пол-пинка, и благодаря им мы с одной стороны получаем больше как специалисты, а с другой — иногда безумство даёт жизнь гениальным идеям.
Если резюмировать — хорошо, что есть фреймворки.
С одной стороны, начинать программировать с какого-то продвинутого движка, который строится на продвинутом фреймворке, который базируется на продвинутом языке, который компилируется в продвинутый промежуточный язык, который затем исполняется на продвинутом процессоре с сотнями вспомогательных инструкций, который содержит продвинутые блоки, которые состоят из продвинуто-скомпонованных транзисторов, которые делаются по продвинутым методам фотолитографии, которая базируется на продвинутых свойствах оптики и химии… Можно продолжать бесконечно. Это вопрос прогресса вообще. Времена, когда человек мог поместить в себе все научные знания о мире прошли, поэтому мы всё чаще полагаемся на здравый смысл и мануал. К счастью, есть ещё в мире люди, которые пытаются делать всё с пол-пинка, и благодаря им мы с одной стороны получаем больше как специалисты, а с другой — иногда безумство даёт жизнь гениальным идеям.
Если резюмировать — хорошо, что есть фреймворки.
Фреймворки помогают мне. Общие соглашения помогают коммуникации. Конечно, если ваш проект будет использоваться только вами, то смысла в фреймворках солидно меньше, ведь часто проще написать под требования свой код.
В любом случае, специфика решает. Где-то действительно имеются навязанные производетелем решения, часто весьма невысокого качества документации или самого кода, но в моей специализации — веб-разработке, пишут на голом языке (JS или PHP) либо для максимальной скорости, либо для изучения чего-либо. Люди, которые разрабатывают несколько похожих задач, часто вырабатывают свой стиль кода, собирают свою библиотеку классов, принимают различные архитектурные соглашения, что по сути можно назвать и разработкой собственного фреймворка.
Возможно я не очень понял про маркетинговый аспект разработки ПО, можете пояснить подробнее?
В любом случае, специфика решает. Где-то действительно имеются навязанные производетелем решения, часто весьма невысокого качества документации или самого кода, но в моей специализации — веб-разработке, пишут на голом языке (JS или PHP) либо для максимальной скорости, либо для изучения чего-либо. Люди, которые разрабатывают несколько похожих задач, часто вырабатывают свой стиль кода, собирают свою библиотеку классов, принимают различные архитектурные соглашения, что по сути можно назвать и разработкой собственного фреймворка.
Возможно я не очень понял про маркетинговый аспект разработки ПО, можете пояснить подробнее?
Мировой заговор? Не думаю. Экономика. Времени слишком мало, чтобы писать снова то, что давно написано. Времени слишком мало, чтобы адаптироваться к другой реализации банальной идеи в очередном проекте. Времени слишком мало даже на привыкание к очередному стилю форматирования кода. Да, пока мистер Мур нам помогает, но возможно так будет не всегда, и тогда «время — деньги» будут осмысливаться несколько по-другому.
Что значит не дают хороших инструментов? Программисты сами себе делают инструменты (в отличии от многих других профессий). Не можешь найти хороший — сделай свой.
И не согласен с тем, что фреймворк — это мастерская или фабрика. Это скорее универсальный инструмент со сменными рабочими насадками. Та же электродрель или миксер. Задаётся общий принцип работы (вращать стандартный патрон), известны ограничения (крутящий момент, диапазон скоростей вращения, диаметр и тип патрона, напряжение питание и т. п.) и оставляется выбор насадок, в том числе и других производителей или вообще самодельных.
А вот как будете использовать этот инструмент зависит целиком от вас. Если попытаетесь просверлить отверстие сверлом или сделать коктейль венчиком, то при наличии простых навыков получится. А вот если решите использовать электродрель в качестве привода автомобиля или миксер в качестве бетономешалки, то, да, могут быть проблемы.
И не согласен с тем, что фреймворк — это мастерская или фабрика. Это скорее универсальный инструмент со сменными рабочими насадками. Та же электродрель или миксер. Задаётся общий принцип работы (вращать стандартный патрон), известны ограничения (крутящий момент, диапазон скоростей вращения, диаметр и тип патрона, напряжение питание и т. п.) и оставляется выбор насадок, в том числе и других производителей или вообще самодельных.
А вот как будете использовать этот инструмент зависит целиком от вас. Если попытаетесь просверлить отверстие сверлом или сделать коктейль венчиком, то при наличии простых навыков получится. А вот если решите использовать электродрель в качестве привода автомобиля или миксер в качестве бетономешалки, то, да, могут быть проблемы.
ИМХО совершенно неверная аналогия. Фреймворк — это не фабрика фабрик фабрик молотков. Фреймворк — это набор инструментов, включающий в себя молоток. Можно, конечно, воспользоваться одним молотком и, когда нужно будет закрепить полочку на бетонной стене, до победного конца вколачивать гнущиеся гвозди. А можно просверлить дырку дрелью из набора, вколотить туда дюбель из набора и закрепить на нем полочку отверткой (из того же набора, да).
Сдается мне автор намекает на то, что люди которые собрали для вас набор инструментов и положили туда молоток, дрель и отвертку обычно не останавливаются на достигнутом, продолжая развивать и унифицировать набор :)
Набор инструментов — это библиотека. А фреймворк — это деревянный ящик, забитый до отказа деревянными же досками-полочками. Из него нужно вытащить лишние, и прибить те, что остались нужными. Сам ящик допилить чтобы стал походить на шкаф. Инструменты в него не входят. Инструменты — это библиотеки и языки.
Не очень верная аналогия. Прежде всего любая программа это не шкаф, а инструмент для создания шкафов. Шкаф — результат нужный пользователю. Он загружает в него дощечки (а то и просто указывает где их взять), нажимает кнопку и получает шкаф.
А фреймворк это скорее конвейер, вдоль которого стоят универсальные приводы для разных видов рабочих органов со стандартизированными гнёздами. Универсальная сборочная линия типа. Чтобы эта линия выпускала нужные вам шкафы нужно вставить в гнёзда нужные инструменты и настроить приводы. Если у вас шкафы примитивные, то можно часть приводов демонтировать, чтобы линия потребляла меньше ресурсов. Если сложные (сложнее чем те, в расчёте на которые создавалась линия), то придётся устанавливать свои или подключать к имеющимся рабочие органы, превосходящие приводы по сложности и изменять саму линию, а то и вообще создать свою с нуля. Но для типичных шкафов, особенно если не стоит задача максимальной эффективности использования ресурсов, не так уж сложно настроить эту линию.
А фреймворк это скорее конвейер, вдоль которого стоят универсальные приводы для разных видов рабочих органов со стандартизированными гнёздами. Универсальная сборочная линия типа. Чтобы эта линия выпускала нужные вам шкафы нужно вставить в гнёзда нужные инструменты и настроить приводы. Если у вас шкафы примитивные, то можно часть приводов демонтировать, чтобы линия потребляла меньше ресурсов. Если сложные (сложнее чем те, в расчёте на которые создавалась линия), то придётся устанавливать свои или подключать к имеющимся рабочие органы, превосходящие приводы по сложности и изменять саму линию, а то и вообще создать свою с нуля. Но для типичных шкафов, особенно если не стоит задача максимальной эффективности использования ресурсов, не так уж сложно настроить эту линию.
Тэг «юмор» — лишний.
p.s. спасибо, этот пост сделал мой день.
p.s. спасибо, этот пост сделал мой день.
gem install hammer
gem install rell
gem install level-instrument
gem install rell
gem install level-instrument
Мне кажется, что язык, в данном случае Java — это молоток. А вот фреймворки скорее всего представляют собой наборы готовых элементов для сборки шкафов — чуть допили, прикрути, подправь — и шкаф готов. Сначала выбери тот набор, который лучше всего подходит для нужного шкафа, потом берешь молоток с легкостью приводишь шкаф в нужное состояние. Конечно, лучше всего получится, когда ты уже несколько раз использовал этот набор. Ошибся с выбором — шкаф будет сделать тяжело, потому что придется много допиливать.
If you have a problem and decide to use Java… Now you have a Problem, ProblemImpl, ProblemException, and a ProblemFactory.
А вообще, тут двояко.
С одной стороны, Sun очень круто подсадили всех на свою технологию, и все заверте. Возможно, это программисты неосознанно создают избыточную сложность, и затем требуют большей оплаты своего труда (а также железа под тормозную яву и тд). Что же, красивое решение вопроса нужности своей профессии, что-то наподобие постоянного выпуска новых версий винды или фотошопа, чтобы было, что кушать.
Потому как согласно Макконнеллу, основная задача разработки ПО — это управление сложностью. И в выражение «достаточно хороший» все чаще попадают более простые языки. На том же PHP работает Фейсбук, Википедия, и не обламывается — и PHP разработчики при этом стоят дешевле, понтов меньше, а шарят иногда гораздо больше (из-за сильной конкуренции).
Так что Ява — это действительно круто ИМХО. Но для мобильных приложений, или софта. Для веба есть более простые решения, менее требовательные к железу, уровню разработчиков и так далее, которые прекрасно решают бизнес-задачи. Что становится очевидно после сравнения короткого изящного кода на Питоне или чуть более страшного на ПХП с монстро-вызовами Явы.
ИМХО разумеется.
С одной стороны, Sun очень круто подсадили всех на свою технологию, и все заверте. Возможно, это программисты неосознанно создают избыточную сложность, и затем требуют большей оплаты своего труда (а также железа под тормозную яву и тд). Что же, красивое решение вопроса нужности своей профессии, что-то наподобие постоянного выпуска новых версий винды или фотошопа, чтобы было, что кушать.
Потому как согласно Макконнеллу, основная задача разработки ПО — это управление сложностью. И в выражение «достаточно хороший» все чаще попадают более простые языки. На том же PHP работает Фейсбук, Википедия, и не обламывается — и PHP разработчики при этом стоят дешевле, понтов меньше, а шарят иногда гораздо больше (из-за сильной конкуренции).
Так что Ява — это действительно круто ИМХО. Но для мобильных приложений, или софта. Для веба есть более простые решения, менее требовательные к железу, уровню разработчиков и так далее, которые прекрасно решают бизнес-задачи. Что становится очевидно после сравнения короткого изящного кода на Питоне или чуть более страшного на ПХП с монстро-вызовами Явы.
ИМХО разумеется.
То же самое на PHP:
P.S. Это к тому что для каждой задачи все-таки свой инструмент нужен
Hello, <?=$_GET['name']?>!P.S. Это к тому что для каждой задачи все-таки свой инструмент нужен
Для однобайтных кодировок
С многобайтными уже не так просто.
Hello, <?=$_GET['name'][0]?>!С многобайтными уже не так просто.
Что-то типа этого:
Hello, <?=mb_substr($_GET['name'],0,1)?>!
Hello, <?=mb_substr($_GET['name'], 0, 1, 'UTF-8') ?>!Функция mb_substr входит в расширение mbstring, не включенном (включается на этапе конфигурирования компиляции) по умолчанию в «ванильном» PHP, но в большинстве инсталляций и в пакетах популярных дистрибутивов включена, насколько я знаю (исключений на практике не встречал). Указание кодировки не обязательно, если нужная указана в настройках (в статических, перекрываемых в рантайме по необходимости или в рантайме) как дефолтная.
А что мешает то же самое сделать в JSP?
как по мне, так даже «элегантней», не?
Hello, <%=request.getParameter("name")%>!
как по мне, так даже «элегантней», не?
Как раз для хорошего решения бизнес задач(автоматизации БП) лучше использовать монстроподобные языки, такие как Java, C#. Сам javaEE проектировался как «все для бизнеса в одном флаконе»
А вообще, не бывает идеального языка/технологии для решения какждого типа задач. Опытный разработчик выбирает инструмент для решения текущей проблемы.
На пример, в текущем проекте мы используем стэк из Java, Python, C.
А вообще, не бывает идеального языка/технологии для решения какждого типа задач. Опытный разработчик выбирает инструмент для решения текущей проблемы.
На пример, в текущем проекте мы используем стэк из Java, Python, C.
Вообще PHP недалеко от Java находится и многое из неё явно берёт, насколько я могу судить (Java знаю весьма поверхностно, как ещё один «Си с классами»). Ключевых отличий (как у языков), имхо, два — слабая динамическая типизация (и то, type hinting) и возможность (legacy?) писать в процедурном стиле. Остальное, имхо, нюансы. Но такая типизация в основном используется для одноразового вывода типа переменной, а в процедурном стиле пишут все реже, ведь в нём сложнее управлять сложностью. А монстровызовы Java получаются в основном из-за необходимости задавать тип на каждый чих.
Две стороны медали.
Лично я заметил, что в последнее время за фреймворки берутся те, кто не знает толком самого языка. Человек не может сам написать класс роутера, и берется за фреймворк, который делает это за него.
Вообще согласен с автором статьи — большой фреймворк содержит много лишнего, а меленький фреймворк можно написать самому и под свои потребности.
С другой стороны — для совместной разработки часто более подходит какой-нибудь известный фреймворк по причине того, что можно найти по нему специалиста, если один из работающих специалистов уйдет, кроме того — это стандартизация и поддержка сообщества.
//Сам я все же использвую фреймворк Yii.
Лично я заметил, что в последнее время за фреймворки берутся те, кто не знает толком самого языка. Человек не может сам написать класс роутера, и берется за фреймворк, который делает это за него.
Вообще согласен с автором статьи — большой фреймворк содержит много лишнего, а меленький фреймворк можно написать самому и под свои потребности.
С другой стороны — для совместной разработки часто более подходит какой-нибудь известный фреймворк по причине того, что можно найти по нему специалиста, если один из работающих специалистов уйдет, кроме того — это стандартизация и поддержка сообщества.
//Сам я все же использвую фреймворк Yii.
Собственно поэтому считаю, что изучение «платформы» нужно начинать снизу вверх и желательно без резких скачков. Чтобы хотя бы понимать, что собственно фреймворк (в идеале каждый его слой и компонент) делает. Грубо говоря, написать свой велосипед, сравнить с имеющимися решениями и, в большинстве случаев, начинать использовать их.
Жаль сам этой практике далеко не всегда следую или приходится делать резкие скачки — от использования CGI «хелловорлдов» к использованию full stack веб-фреймворков.
Жаль сам этой практике далеко не всегда следую или приходится делать резкие скачки — от использования CGI «хелловорлдов» к использованию full stack веб-фреймворков.
Прекрасно Вас понимаю — я сам изначально писал говнокод без всяких фреймворков, а потом сразу перескочил на использование оных. Правда, когда набрался опыта — стал колупать исходники фреймворков, изучать их и т.д. — и должен сказать, это все же не худший путь развития, так как изучая исходники фреймворка после долгого его использования, я улучшил знания самого языка, уже умея пользоваться фреймворками.
Увы, далеко не у всех возникает желание колупать исходники фреймворков или хотя бы изучить диаграмму классов или что-то в этом роде. Многие используют фреймворки как чёрный ящик, а иной раз даже не представляют всех предоставляемых фреймворков возможностей.
Это Вы как раз про меня сказали :) Я когда начал пользоваться фреймворками, то сначала использовал разве что роутер, автолоадер, гриды (предоставляемые фреймворком) и еще по мелочам — в остальном же писал толстенные контроллеры, смотря на которые сейчас я бы впал в шок)
По поводу черного ящика — негативные стороны сокрытия реализации за интерфейсом — пользователю дают понятный апи, и он плевал что-то еще знать. В итоге получаются забавные программисты — я, например, знал одного «фреймворщика», который определял длину строки на PHP с помощью регулярных выражений)
По поводу черного ящика — негативные стороны сокрытия реализации за интерфейсом — пользователю дают понятный апи, и он плевал что-то еще знать. В итоге получаются забавные программисты — я, например, знал одного «фреймворщика», который определял длину строки на PHP с помощью регулярных выражений)
Хочу похвалить автора за великолепный перевод: «Автор! Ты молодец!»
Фабрика — легкая промышленность
тяжелая промышленность — заводы
молоток — тяжелая промышленность
тяжелая промышленность — заводы
молоток — тяжелая промышленность
Довольно рекурсивное повествование.
Вот одного не пойму. Если Вам нужно сделать шкафчик для специй, почему Вы начали читать про фреймворки?
Вот одного не пойму. Если Вам нужно сделать шкафчик для специй, почему Вы начали читать про фреймворки?
Видно, что человека достало :) И, в драке волос не считают, он прав.
О! Я помню пару лет назад пытался разобраться, почему Hibernate не пишет в лог-файл Glassfish! Узнал много нового про log4j, commons-logging и slrf4j (я сам не джавист, мог чутка напутать с названиями) :))
с самого начала статьи есть одна серьёзная ошибка
фреймворки это скорее как современные строительные уровни (инструмент такой)
там и углы обозначены, и горизонталь найти можно, и размеры есть
если тебе надо отмерять на бумаге 10см — уровень не нужен. но если тебе нужно сделать ремонт в квартире. то вместо отвеса+линейки+транспартира+плоскойдощечки(для всяких строительных нужд) лучше использовать всё-таки уровень
фреймворки это скорее как современные строительные уровни (инструмент такой)
там и углы обозначены, и горизонталь найти можно, и размеры есть
если тебе надо отмерять на бумаге 10см — уровень не нужен. но если тебе нужно сделать ремонт в квартире. то вместо отвеса+линейки+транспартира+плоскойдощечки(для всяких строительных нужд) лучше использовать всё-таки уровень
Есть люди которые пишут проекты на фреймворках, есть люди которые пишут фреймворки, а есть люди которые пишут велосипеды и называют их своим «ядром» ну или хз как еще, а еще есть люди которые просто пишут говно код. Обычно «самопис», то-есть с ноля, это примерно 99-98% говнокода.
Есть ещё другой тип людей. Они пишут фреймворки под свои нужды, но не с нуля, а используя атомарную единицу ф-ционала, протестированную и независимую от остальных. Я нашел для себя золотую середину, чего и всем желаю. Вот отличный пример того как с нуля делается свой фреймворк. Остановиться можно на любом шаге. Вы сами регулируете уровень абстракции, балансируя между скоростью, сложностью, масштабируемостью
Как же я Вас понимаю…
Одно радует, помимо фабрик фабрик, молотки никуда не делись, более того, продолжают совершенствоваться.
Помнит ли кто-нибудь похожую статью, она тоже была в те годы 2012-2014, не помню точно. Кажется была посвящена одному из JS-фреймворков. Там шел диалог в духе что мне надо чтобы установить… реакт? типа — установи nodejs — что это? это вот то-то, но тебе еще нужен webpack… — а это зачем? а вот затем, а еще нужен grunt… gulp… babel… и т.д. и заканчивалась статья в духе «иди к черту, i'm going back to jQuery!». Не могу сейчас ее найти что-то никак.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему я ненавижу фреймворки