Вот что не люблю на Хабре, так это примитивный, убогий подход к решению задач (ну и ограничение на коментарии раз в неделю).
Разве это решение — установить какой-то левый, тормозящий работу страницы и загрузку яваскрипт? Что за ограниченное мышление? И что делать пользователям без яваскрипта?
Большинство опечаток и ошибок, вроде слов «координально» (это ж надо такое придумать!) или запятых в стиле «завтра, я напишу продолжение, этого поста,...» можно обнаруживать (а также исправлять) полностью автоматически. Автор, советую вам бросить маяться дурью и написать уже робота-спеллфиксера для полностью автоматического обнаружения и исправления ошибок.
Ядро Линукса — тяжелое, монстроидальное, излишне монолитное, во многом устаревшее.
Для разработки важна поддержка мощных компаний. Представьте, что лет через 5 появятся новые стоядерные процессоры с многоконвейерной архитектурой и ядра ОС станут например асинхронными и микроядерными. Эппл и майкрософт перепишут свои ядра, а кто перепишет весь Линукс? Появится новая шина или новое устройство. Кто напишет драйвер под Линукс? (производитель устройства особо не заинтересован).
Для разработки ОС важно участие лучших разработчиков в мире. Лучшие разработчики работают в Гугл, Эппл и фейсбук, как их переманишь, прикормленных, на ниву свободного ПО?
Десктопный Линукс всегда был плох. В сравнении с оптимизированной по производительности и совместимости с приложениями виндой и вылизанным юзабилити маков. Когда-то авторы Gnome пытались разобраться, как сделать комфортной работу в среде при объеме памяти в 256 Мб, в итоге выяснилось, что проще всего подождать, пока на компьютерах станет больше памяти и проблема решится сама собой.
Что касается телефонов, тут лидер исключительно Эппл. Линуксу нужны космические инвестиции, чтобы хотя бы рядом встать.
Свободный софт, это конечно, красивая идея, но плохо жизнеспособная. С точки зрения бизнеса выгодно вкладывать средства в свой продукт, а не такой, который вовсю могут использовать твои конкуренты, и зарабатывать на твоих инвестициях. Эппл, например, вложила деньги, разработав превосходную проприетарную платформу, и получает огромные прибыли, выпуская хорошую технику. А была бы iOS опенсурс — мир был бы заполонен дешевыми некачественными китайскими клонами. Как он был заполонен уродливыми WinMobile и нокиами до этого.
Также, есть множество продуктов, которых нет в виде свободного ПО, например ПО для бухучета, фотошоп, и подобные вещи.
Также, что касается, нас, PHP-разработчиков, на мой взгляд, качество архитектуры и кода свободного ПО (а я люблю заглядывать в исходный код) очень низкое. Или же, наоборот, продукт страдает от оверинженеринга (Zend Framework).
На картинке замечательный офис. У опенспейса есть большое преимущество — (если конечно там не шумно) — вид того, что вокруг тебя сидит много людей и они все работают, мотивирует. И вообще, как-то лучше в большом помещении, чем в маленьком.
Мне кажется, в начале статьи стоило бы перечислить какие вообще есть способы устранения этих конфликтов, чтобы были понятны варианты решения проблемы.
Что касается эквалайзера, а разве звук инструмента не страдает от такой аггрессивной эквализации, когда кусок спектра вырезается начисто?
Отрезать частоты ниже 90 Гц — не слишком ли смело? Вроде бас легко залезает ниже (например, нижняя нота E)? Не будет ли бас с отрезанной основной гармоникой звучать странно?
А, еще вопрос при использование садчейна — ведь обычно атака басовой ноты совпадает с бочкой, и делая сайд чейн мы глушим атаку большинства нот, и линию баса становится труднее разобрать?
Также, интересная тема (жаль, не освещенная в статье) — запись гитарных партий, которые вообще чуть ли не весь слышимый спектр занимают и глушат все остальное.
Также, хотелось бы почитать про более интересные устройства, вроде Multiband Compressor. Говорят, они могут впихнуть в микс еще больше инструментов и сделать их еще громче.
Автор показывает полное незнание темы. Смарти уже лет 5 как устарел — зачем его упоминать? Он всегда был уродливым, тормозным и неудобным (а теперь у нас есть неудобный и уродливый Twig вместо него :) ). XSLT автор скромно прошел стороной (мог бы хоть недостатки описать). Zend_view не упомняул (хотя предложенные классы — упрощенная версия Zend_view). Про наследование шаблонов и макросы в шаблонах не рассказал. Про новые идеи типа HAML не упомянул.
Это статья о шаблонах? Это набор устаревших и неправильных занний. Код автора тоже плох. В его шаблонизаторе даже функции include нет. Также, почему имя шаблона передается в конструктор, а не в render()? Чем это объясняется? непродуманностью?
Рендеринг SVG явно медленнее, чем рендеринг растровой картинки. Плюс неизвестно, может браузер ради каждой иконки будет рендерить SVG-файл целиком. Непонятно, как это скажется на производительсности и потреблении памяти. Непонятно, что делать с IE.
То есть минусов много, плюс — всего один, и то в большинстве случаев ненужный.
Неуклюжий способ, так как в сигналах куча ограничений (многое делать нельзя), и нельзя делать стек обработчиков (так как установка нового отменяет старый). Неудобная система.
> и песня группы со странным названием «Мои Ракеты Вверх»
Меня тоже немного это напрягает, если уж рекламировать инди-музыку, то зачем брать песню на английском, которую никто не поймет, взяли бы лучше что-нибудь из репертуара «И Друг мой Грузовик».
Аналогии неправильные. Когда я слышу «фреймворки не нужны», это значит, что человек либо не умеет ими пользоваться, либо просто взял не тот инструмент для решения задачи и ругается.
Проводя аналогии, например IC и DI — это стандартные розетки и провода для хлеборезки. То есть до них все делали свою хлеборезку со своим собственным дизелем, своим типом двигателя и своим напряжением питания (а кто-то вообще на бензине), а потом догадались сделать розетку на 220В и 50 Гц и пошл-поехало. А теперь вот приходят люди и говорят: мне не нужна розетка на 220В, я свой дизель-генератор лучше соберу. Ну хозяин-барин, конечно.
Другой вопрос, что ява-фреймоврки излишне утяжелены и усложнены, но это уже не мои проблемы. Также, люди любят делать излишнюю расширяемость: например, нарежут все на кучу абстрактных классов и фабрик с наследоваием, вместо того, чтобы написать if/else. У нас в PHP такой проблемы нет: хочешь, пиши фреймворки с XML-конфигами и DI, хочешь пиши через функции и глобальные переменные.
XML дает валидацию через всякие Relax NG (альтернатива: писать и вымучивать код валидации шаблона руками, тратя гораздо больше времени). XML дает возможность легко делать всякие блоки с параметрами и много других вещей.
А Jade (хотя такой синтаксис по моему впервые использовался в HAML) — интересная вещь, но я бы не рискнул его применять, пока сам не потестировал и посмотрел на плюсы/минусы. Как минимум, при его использовании надо полученную от верстальщика HTML-верстку почти целиком переделывать в блоки — это надо либо автоматизировать, либо это лишняя работа. В то время как XML и HTML — братья-близнецы.
Хорошая статья. Потмоу, что я сам не раз ломал голову, как решить проблему возникающую в любом продвинутом аякс-приложении:
> два набора совершенно разных шаблонов на сервере и на клиенте.
От себя добавлю: не только шаблоны, если нужна офлайн работа, придется еще и модельки, их валидацию и хранилище дублировать. Мне пришли в голову такие идеи:
1) сделать Xml-based язык шаблонов и компилировать его в PHP (или что-нибуль Си-подобное если требуется скорость) и JS для клиента — заведомо FAIL, так как после богатых возможностей PHP с циклами, вызовами хелперов, константами, массивами на нем невозможно будет программировать
2) сделать шаблоны на PHP, а для клиента сделать транслятор PHP subset в JS — это во-первых, сложно, во-вторых, мало перенести конструкии языка, ведь в шаблонизаторе используются модели (класссы на PHP) и хелперы (PHP-функции) — их-то как перенести, а? Дублировать всю логику на клиентсайде что ли?
3) (не выход) перенести всю логику на клиента — не подходит, так как без яваскрипта не будет работать.
4) перейти на сторону тьмы и использовать уродливый тяжелый GWT — опять же, без JS он вроде нормально не работает.
Таким образом, проблем много, а решения я не вижу никакого. Выхода, как говорится, нет. Стоит отказаться от JSON и гонять с сервера шаблонизированные данные видимо.
Потому ваш подход все же не впечатляет. Node.JS вместо компиляции в Си++ на сервере, плюс слабые возможности, плюс нельзя в шаблоне использовать хелперы и серверные классы. Слишком много недостатков.
Самба не поддерживается? В топку тогда этот диск. Ибо я сомневаюсь, что по ихнему web-что-то-там протоколу можно перетащить сетевую папку с тысячами песен в плеер и он их распознает их, прочтет и проиндексирует теги за полминуты (через Samba — можно, его хватает даже для того чтобы тяжеленный flac играть через сеть).
У вас слишком искуственные тесты. Много ума не надо, написать Hello World. Вы сделайте псевдокнтроллер, который читает данные из фейковой модели, проверяет права доступа и отдает в фейковую вьюху. В таких, приближенных к реальности условиях, будет гораздо более объективный тест.
Для Питона, естественно, надо подключить всю махину Джанго.
А так, ваши тесты больше походят на тесты неадекватов из shootout.alioth, которые меряют для PHP скорость построения двоичного дерева и подобную дребедень. Покажите мне хоть один сайт, который строит красно-черные деревья при выводе страницы.
Разве это решение — установить какой-то левый, тормозящий работу страницы и загрузку яваскрипт? Что за ограниченное мышление? И что делать пользователям без яваскрипта?
Большинство опечаток и ошибок, вроде слов «координально» (это ж надо такое придумать!) или запятых в стиле «завтра, я напишу продолжение, этого поста,...» можно обнаруживать (а также исправлять) полностью автоматически. Автор, советую вам бросить маяться дурью и написать уже робота-спеллфиксера для полностью автоматического обнаружения и исправления ошибок.
Для разработки важна поддержка мощных компаний. Представьте, что лет через 5 появятся новые стоядерные процессоры с многоконвейерной архитектурой и ядра ОС станут например асинхронными и микроядерными. Эппл и майкрософт перепишут свои ядра, а кто перепишет весь Линукс? Появится новая шина или новое устройство. Кто напишет драйвер под Линукс? (производитель устройства особо не заинтересован).
Для разработки ОС важно участие лучших разработчиков в мире. Лучшие разработчики работают в Гугл, Эппл и фейсбук, как их переманишь, прикормленных, на ниву свободного ПО?
Десктопный Линукс всегда был плох. В сравнении с оптимизированной по производительности и совместимости с приложениями виндой и вылизанным юзабилити маков. Когда-то авторы Gnome пытались разобраться, как сделать комфортной работу в среде при объеме памяти в 256 Мб, в итоге выяснилось, что проще всего подождать, пока на компьютерах станет больше памяти и проблема решится сама собой.
Что касается телефонов, тут лидер исключительно Эппл. Линуксу нужны космические инвестиции, чтобы хотя бы рядом встать.
Свободный софт, это конечно, красивая идея, но плохо жизнеспособная. С точки зрения бизнеса выгодно вкладывать средства в свой продукт, а не такой, который вовсю могут использовать твои конкуренты, и зарабатывать на твоих инвестициях. Эппл, например, вложила деньги, разработав превосходную проприетарную платформу, и получает огромные прибыли, выпуская хорошую технику. А была бы iOS опенсурс — мир был бы заполонен дешевыми некачественными китайскими клонами. Как он был заполонен уродливыми WinMobile и нокиами до этого.
Также, есть множество продуктов, которых нет в виде свободного ПО, например ПО для бухучета, фотошоп, и подобные вещи.
Также, что касается, нас, PHP-разработчиков, на мой взгляд, качество архитектуры и кода свободного ПО (а я люблю заглядывать в исходный код) очень низкое. Или же, наоборот, продукт страдает от оверинженеринга (Zend Framework).
Что касается эквалайзера, а разве звук инструмента не страдает от такой аггрессивной эквализации, когда кусок спектра вырезается начисто?
Отрезать частоты ниже 90 Гц — не слишком ли смело? Вроде бас легко залезает ниже (например, нижняя нота E)? Не будет ли бас с отрезанной основной гармоникой звучать странно?
А, еще вопрос при использование садчейна — ведь обычно атака басовой ноты совпадает с бочкой, и делая сайд чейн мы глушим атаку большинства нот, и линию баса становится труднее разобрать?
Также, интересная тема (жаль, не освещенная в статье) — запись гитарных партий, которые вообще чуть ли не весь слышимый спектр занимают и глушат все остальное.
Также, хотелось бы почитать про более интересные устройства, вроде Multiband Compressor. Говорят, они могут впихнуть в микс еще больше инструментов и сделать их еще громче.
Это статья о шаблонах? Это набор устаревших и неправильных занний. Код автора тоже плох. В его шаблонизаторе даже функции include нет. Также, почему имя шаблона передается в конструктор, а не в render()? Чем это объясняется? непродуманностью?
То есть минусов много, плюс — всего один, и то в большинстве случаев ненужный.
Меня тоже немного это напрягает, если уж рекламировать инди-музыку, то зачем брать песню на английском, которую никто не поймет, взяли бы лучше что-нибудь из репертуара «И Друг мой Грузовик».
Проводя аналогии, например IC и DI — это стандартные розетки и провода для хлеборезки. То есть до них все делали свою хлеборезку со своим собственным дизелем, своим типом двигателя и своим напряжением питания (а кто-то вообще на бензине), а потом догадались сделать розетку на 220В и 50 Гц и пошл-поехало. А теперь вот приходят люди и говорят: мне не нужна розетка на 220В, я свой дизель-генератор лучше соберу. Ну хозяин-барин, конечно.
Другой вопрос, что ява-фреймоврки излишне утяжелены и усложнены, но это уже не мои проблемы. Также, люди любят делать излишнюю расширяемость: например, нарежут все на кучу абстрактных классов и фабрик с наследоваием, вместо того, чтобы написать if/else. У нас в PHP такой проблемы нет: хочешь, пиши фреймворки с XML-конфигами и DI, хочешь пиши через функции и глобальные переменные.
А Jade (хотя такой синтаксис по моему впервые использовался в HAML) — интересная вещь, но я бы не рискнул его применять, пока сам не потестировал и посмотрел на плюсы/минусы. Как минимум, при его использовании надо полученную от верстальщика HTML-верстку почти целиком переделывать в блоки — это надо либо автоматизировать, либо это лишняя работа. В то время как XML и HTML — братья-близнецы.
> два набора совершенно разных шаблонов на сервере и на клиенте.
От себя добавлю: не только шаблоны, если нужна офлайн работа, придется еще и модельки, их валидацию и хранилище дублировать. Мне пришли в голову такие идеи:
1) сделать Xml-based язык шаблонов и компилировать его в PHP (или что-нибуль Си-подобное если требуется скорость) и JS для клиента — заведомо FAIL, так как после богатых возможностей PHP с циклами, вызовами хелперов, константами, массивами на нем невозможно будет программировать
2) сделать шаблоны на PHP, а для клиента сделать транслятор PHP subset в JS — это во-первых, сложно, во-вторых, мало перенести конструкии языка, ведь в шаблонизаторе используются модели (класссы на PHP) и хелперы (PHP-функции) — их-то как перенести, а? Дублировать всю логику на клиентсайде что ли?
3) (не выход) перенести всю логику на клиента — не подходит, так как без яваскрипта не будет работать.
4) перейти на сторону тьмы и использовать уродливый тяжелый GWT — опять же, без JS он вроде нормально не работает.
Таким образом, проблем много, а решения я не вижу никакого. Выхода, как говорится, нет. Стоит отказаться от JSON и гонять с сервера шаблонизированные данные видимо.
Потому ваш подход все же не впечатляет. Node.JS вместо компиляции в Си++ на сервере, плюс слабые возможности, плюс нельзя в шаблоне использовать хелперы и серверные классы. Слишком много недостатков.
У вас слишком искуственные тесты. Много ума не надо, написать Hello World. Вы сделайте псевдокнтроллер, который читает данные из фейковой модели, проверяет права доступа и отдает в фейковую вьюху. В таких, приближенных к реальности условиях, будет гораздо более объективный тест.
Для Питона, естественно, надо подключить всю махину Джанго.
А так, ваши тесты больше походят на тесты неадекватов из shootout.alioth, которые меряют для PHP скорость построения двоичного дерева и подобную дребедень. Покажите мне хоть один сайт, который строит красно-черные деревья при выводе страницы.