У меня процесс разработки совпадает с вашим почти во всем пунктам. И самое интересное, при всех этих подводных камнях, тоже остается впечатление в перспективности платформы
Разработку перенесли силами нашего js-программиста в FF
Вот меня избили в карму за статью о DI в JS. Но благодаря этому подходу, перенос приложения в chrome у меня занял меньше 10 минут, путем замены четырех строчек в файлах с зависимостями. Ни одной строки в коде приложения изменено не было.
Ок. Спасибо.
И уделяйте по больше внимания JS, второй раз сталкиваюсь с тем, что заказчик хочет чтобы было написано именно на JS а не AS. У них предрассудки (вполне оправданные) что флеш теперь будет ограничен только десктопными платформами, и будущего для остальных платформ него нет.
Angry Birds есть. (Правда он на ActionScript)
Да, я читал на форуме про разницу в производительности флеша в 2011 и 2012 платформах. Невольно сложилось впечатление что самсунг просто забил на предыдущие платформы, начав реальную поддержку с 2012 версии (производительность, webkit, etc.)
Ну вот по поводу API, а конкретнее по поводу IMEShell, я уже писал на вашем форуме в этой теме.
Пользуясь случаем, хочу сказать что API выполнено отвратительно в плане юзабилити, а судя по примерам в документации, оно еще и реализовано так-же. Глобальные переменные, структурный код, отсутствие какой-либо абстракции.
Ребята из самсунг только проснулись? Они в курсе, что в RIA/SinglePageApp's обычно javascript генерирует весь интерфейс? Поэтому все ссылки на элементы уже есть в программном скопе, а их API не рассчитано, чтобы передавали линку на элемент, им нужен только ID элемента, и обязательно, чтобы он УЖЕ был в DOM, иначе всё.
Кажется, что консультантами у них были не Javascript-programmers а Frontend-Guys которые дальше jquery и сайтиков в лес не ходят.
То как ime2.js втупую добавляет свой html код в приложение это вообще сказка, мало того что я потратил кучу времени не понимая почему он у меня не работает, т.к. у моих сцен свои конструкторы и деструкторы которые чистят за собой дом. Ребята, нельзя что ли сгенерировать DOM менюшки и делать appendChild/removeChild по необходимости? Или нужно тупо инъецировать third party code в DOM структуру приложения? Так они еще не упомянули об этом в гайде, или упомянули где-то далеко.
На счет гайда тоже прикольно, вот пример ляпа с мана по тому же IME:
var widgetAPI = new Common.API.Widget(); // объявление сущности
widgetAPI.registIMEKey();//Использование ее метода
Только в коде который я скачал видно что registIMEKey является методом другого (Common.API.Plugin) API, а так мне пришлось убить еще времени для того чтобы понять в чем дело. А за моё время платит клиент. И будет ли он доволен за кучу потраченного впустую времени? Потом он просто откажется от вашей платформы, как не актуальной. Вместо того чтобы дать девам мощные инструменты, дать возможность сделать или портировать что-то вроде angry-birds, тем самым подняв популярность девайса и рубить процент с продаж, самсунг тупо забил на девов. Я конечно заделиверил приложение клиенту, но ощущения после работы с вашим девайсом (2011), просто отвратительные.
Спасибо за внимание.
И вот таких мелочей у вас в каждом компоненте по пачке.
ps: Извините если пост оказался немного резким. То был очень длинный и сложный день.
На данный момент ваша основная деятельность SmartTV? Если да, то под какую модель пишите?
Сам пишу под линейку SmartTV 2011, крайне отвратительные впечатления от производительности и API девайса. А интерфейс у API, мягко сказать — бездарный.
Моё приложение занимается показом оцифрованной прессы (т.е. работа с большими количеством больших изображений), и проигрыванием подкастов. В один момент приложению просто перестало хватать памяти для отображения получаемых изображений. Это при том что я провел тщательный профайлинг JS и даже написал свой garbage collector следящий чтобы все невидимые изображения уничтожались и не оставалось на них ссылок, слабо помогло. Использую vanillaJS. До меня, в компании над этим приложением посадили работать какого-то фронтэндчика, парень уже на подсознательном уровне подключил Jquery и начал писать приложение в стиле DOM Driven Design, в итоге приложение уже было нестабильно еще даже не успев достигнуть ни одного acceptance criteria. Пришлось всё переписывать с нуля.
Причем девайс ложился и на более простых моментах, например при парсинге (относительно) больших XML.
В итоге пришлось часть приложения писать на ActionsScript, причем в 2011 в JS приложениях можно использовать только Flash 8 и AS2, чему я был несказанно рад. Про FPS а флеше можно узнать о отзывах на форуме.
Считайте этот комент криком души, не могу больше молчать.
В общем, очень интересно, какие у вас впечатления от работы с SmartTV.
Не соглашусь. В Service Locator классы сами определяют свои зависимости, пусть даже и при помощи Service Locator. В моей реализации классы получают все зависимости извне, и они не знают, как и кем, они определяются и передаются. Безусловно, я написал там, что это не Auto DI как таковой, но по идеологии он намного ближе к нему, а не к Service Locator.
Интересно, месяц назад написал адаптацию классического паттерна призванного решать эти же проблемы. Но получил минусы в карму с аргументацией — «В Javascript это не нужно!».
Это очевидно, просто люди которые из jquery не вылазят практически никогда, зачастую даже не слышали о querySelector, а он работает даже с IE8.
И тут вопрос больше не в сокращении кода, а в правильности кода. Работать с DOM через BOM-ссылки по-моему не очень корректно, смазывается абстракция.
Java-программисты как раз наоборот стараются уйти от xml-конфигурирования проекта
А в какую сторону они уходят? Я, по большей части, lamp разработчик, так что немного далек от того что происходит в Java.
* IDE плохо поддерживает такие нотации;
Если конфиг находится в xml формате, тут не поспоришь.
* при рефакторингах приходиться менять в 2х местах (код + конфигурация);
По-моему это надуманная проблема. Вроде — «Мы не будем писать тесты т.к. уходит много времени на поддержку их в актуальном состоянии» :)
Тем более, в конфиге прописываешь только внешние компоненты используемые классом, а не какую-либо логику. А если уж рефакторинг зашел так далеко, что класс поменял компоненты которые он использует, нужно готовится к тому что переписывать нужно будет многое. [blah-blah mode]
Но в итоге, кода писать нужно будет меньше. Например часто вместо того чтобы создавать отдельный подкласс, можно просто запросить существующий класс, только другой сборки. Например, у нас была проблема, в приложении было два контроллера для старого и нового API, так получилось, что в новое API не успели перенести все методы из старого, и для определенного списка команд мы использовали старое API. Причем у одного API ответ был в XML, у другого в JSON, да и их структура была сильно отличной. Нам пришлось написать производный DAO, который парсил JSON и новый формат данных. И в разных модулях пришлось использовать DAO в зависимости от используемого API. Когда же всё перевели в новый API нам пришлось облазить весь код в поисках мест где использовался старый DAO и заменить его на новый.
Используя DI подход, единственное что мы бы меняли в коде это — написали бы новый парсер. А в DI сделали бы основную сборку DAO, и ее алиас который бы использовал другой парсер. И по ходу обновления api мы бы меняли только конфиг зависимостей, не трогая код.
А один раз встала необходимость вывести один виджет на всех поддерживаемых языках, вроде простая задача, и пришлось переписывать существующие компоненты. «Случай 4
» примерно об этом. [/blah-blah mode]
Очень выручили бы аннотация, но в js их нет :(
Ну, это уже другая песня и на мотив метапрограммирования. Использовать аннотации для внедрения зависимостей, по-моему, это как микроскопом забивать гвозди :). А вообще, правда, их в JS не хватает. Я даже придумал механизм для создания, своего рода, «хуков» в js объектах, даже собираюсь написать о нем в новой статье. Но она у меня уже вышла больше этой, так что опубликую ее наверное в октябре, к тому же хочу взять за привычку написание демо приложений, чтобы показать подход на практике, как в этот раз.
Рефлекшен, это по сути это возможность читать и обрабатывать не объекты (как в вашем случае), а их конструкторы (классы). И таким способом вы не прочтете локальный скоуп объекта и сигнатуру методов.
Например, не инстанцируя объект от этого конструктора вы не прочтете его публичный метод, а до локальных вы вообще никак не достучитесь.
var Class = function(){
var privateMethod1 = function(a, b){
return a + b;
};
var privateMethod2 = function(c, d){
return c + d;
};
this.publicMethod1 = function(e, f){
return e + f;
};
}
tzlom выше написал вполне неплохое решение для рефлекшенов в JS.
Спасибо!
Но проблема в том что это не оригинальный подход, а уже довольно обыденный, и успешно используемый в других языках, например на такую реализацию меня частично подтолкнул DI в ZendFramework 2.0. Я же просто адаптировал и применил этот подход в Javascript, и для моих целей он себя оправдал.
А меня бьют в карму за то что показал какие есть подходы в разработке ПО, в том числе для JS. Так будто это я придумал этот паттерн.
Относитесь к этому как к имени сущности. Вы, наверное, заметили eval в коде, я его использую только потому, что сейчас пишу под SmartTV и планирую перенести на Node.js. Где разные объекты отвечают за глобальную область видимости.
В изначальном варианте eval’a нет, я извлекал непосредственно сущность с глобальной области видимости в JS так:
var SomeGlobalClass = function(){
this.say = function(){
console.log('I\'m here');
};
};
var str = 'SomeGlobalClass';
new window[str]().say(); // I'm here
Еще раз повторюсь, для примера я выбрал самый наглядный вариант, видимо зря, более истинный вариант в демо, где я передаю исключительно имена сущностей которые в принципе можно выцепить window скопе. Безусловно — увы мне за хаки в примерах.
у вас все равно логика реализована в конфиге.
Можете указать конкретный момент? Вы, кажется, не поняли сути DI.
Понимаете, что когда вы пишете подобный код:
var Menu = function(){
var ajax, domBouilder;
var constructor = function(){
ajax = new AJAXclass();
domBouilder = new SomeDOMboilder();
};
...
};
new Menu();
То это уже не правильный код, вы создали класс, в котором зависимости прописаны хардкодом. И это в любом языке будет не правильно. Даже в теории программирования желательно придерживаться чистых функций, об этом даже где-то тут писали. И да, этот момент можно решить фабриками для всех типов сущностей. Но, по-моему, это куда более тяжеловесный и трудоёмкий процесс и в принципе не полностью соответствует Open/closed principle.
Это же решение полностью решает такую проблему, и довольно элегантно. Я не выношу логику за приложение, я выношу определение компонентов (в данном случае AJAXclass и SomeDOMboilder) используемых в «классе», за его пределы.
Не путайте методологию разработки с формированием архитектуры. Эта аналогия уровня «многим нравится программировать на клавиатуре mitsumi» — связи с DI столько-же.
Безусловно. Имелось в виду, что использование такого подхода сразу подразумевает использование как минимум половины SOLID принципов разработки. Я это упомянул в статье, такой подход заставляет писать правильно.
Так напишите что сподвигло вас на это. DI ради DI никому не нужно.
Из этого состоит «Вступление», спасибо что внимательно прочли.
Тем что у вас код, например console.log записан в текстовой переменной он не перестает быть кодом.
Извините, я говорил об Open/closed principle. А Вы о чем?
Какое-то программирование на конфиг-файлах получается.
А TDD это вообще программирование тестами. Но многим нравится.
Извините, за оффтоп. Мне всегда не нравилось что на хабре мало статей о такой замечательной, и быстроразвивающийся, технологии как Javascript. Я говорю о статьях с приемами программирования, или организации кода (как эта), а не статьи вроде — «Вышла новая либа нa JS» или «Пишем слайдер картинок вместе». И вот моя первая статья на хабре, но меня никто не понял.
Я понимаю, что это очень узкое направление в JS, но оно имеет право жить. Может кому-то будет интересно, а может даже и полезно.
в яваскрипте, где в основном мы обеспечивам рендеринг html, работу интерфейса и проброску событий туда-сюда
Если ваши задачи на Javascript не выходили за эти рамки, мне нечего вам возразить. 90% людей пришедших в Javascript — это бывшие Front-end Guy, действительно, для них эта статья будет бесполезна. Но люди которые занимаются профессионально программированием на JS, часто сталкиваются со сложными задачами, когда нужно написать большое приложение не имея возможности построить нормальную абстракцию inbox инструментами.
Сейчас для меня web-браузер – это не основная, а одна из платформ для JS. А созданием GUI для обычных сайтов я вообще никогда не занимался.
Интересно, кстати, утверждение про тесты с учётом того, что в проекте на гитхабе они напрочь отсутствуют.
Я не утверждал, что моё приложение покрыто тестами. Эта демка, для людей которые после прочтения статьи задаются вопросом – «А что дальше, как это будет выглядеть на практике в рабочем приложении?». Увы, в этот раз я был сильно ограничен по времени для покрытия демо приложения тестами. Тем более у меня была в мыслях идея написать статью о TDD в JS.
Вот меня избили в карму за статью о DI в JS. Но благодаря этому подходу, перенос приложения в chrome у меня занял меньше 10 минут, путем замены четырех строчек в файлах с зависимостями. Ни одной строки в коде приложения изменено не было.
И уделяйте по больше внимания JS, второй раз сталкиваюсь с тем, что заказчик хочет чтобы было написано именно на JS а не AS. У них предрассудки (вполне оправданные) что флеш теперь будет ограничен только десктопными платформами, и будущего для остальных платформ него нет.
Да, я читал на форуме про разницу в производительности флеша в 2011 и 2012 платформах. Невольно сложилось впечатление что самсунг просто забил на предыдущие платформы, начав реальную поддержку с 2012 версии (производительность, webkit, etc.)
И вот таких мелочей у вас в каждом компоненте по пачке.
ps: Извините если пост оказался немного резким. То был очень длинный и сложный день.
Сам пишу под линейку SmartTV 2011, крайне отвратительные впечатления от производительности и API девайса. А интерфейс у API, мягко сказать — бездарный.
Моё приложение занимается показом оцифрованной прессы (т.е. работа с большими количеством больших изображений), и проигрыванием подкастов. В один момент приложению просто перестало хватать памяти для отображения получаемых изображений. Это при том что я провел тщательный профайлинг JS и даже написал свой garbage collector следящий чтобы все невидимые изображения уничтожались и не оставалось на них ссылок, слабо помогло. Использую vanillaJS. До меня, в компании над этим приложением посадили работать какого-то фронтэндчика, парень уже на подсознательном уровне подключил Jquery и начал писать приложение в стиле DOM Driven Design, в итоге приложение уже было нестабильно еще даже не успев достигнуть ни одного acceptance criteria. Пришлось всё переписывать с нуля.
Причем девайс ложился и на более простых моментах, например при парсинге (относительно) больших XML.
В итоге пришлось часть приложения писать на ActionsScript, причем в 2011 в JS приложениях можно использовать только Flash 8 и AS2, чему я был несказанно рад. Про FPS а флеше можно узнать о отзывах на форуме.
Считайте этот комент криком души, не могу больше молчать.
В общем, очень интересно, какие у вас впечатления от работы с SmartTV.
И тут вопрос больше не в сокращении кода, а в правильности кода. Работать с DOM через BOM-ссылки по-моему не очень корректно, смазывается абстракция.
А в какую сторону они уходят? Я, по большей части, lamp разработчик, так что немного далек от того что происходит в Java.
Если конфиг находится в xml формате, тут не поспоришь.
По-моему это надуманная проблема. Вроде — «Мы не будем писать тесты т.к. уходит много времени на поддержку их в актуальном состоянии» :)
Тем более, в конфиге прописываешь только внешние компоненты используемые классом, а не какую-либо логику. А если уж рефакторинг зашел так далеко, что класс поменял компоненты которые он использует, нужно готовится к тому что переписывать нужно будет многое.
[blah-blah mode]
Но в итоге, кода писать нужно будет меньше. Например часто вместо того чтобы создавать отдельный подкласс, можно просто запросить существующий класс, только другой сборки. Например, у нас была проблема, в приложении было два контроллера для старого и нового API, так получилось, что в новое API не успели перенести все методы из старого, и для определенного списка команд мы использовали старое API. Причем у одного API ответ был в XML, у другого в JSON, да и их структура была сильно отличной. Нам пришлось написать производный DAO, который парсил JSON и новый формат данных. И в разных модулях пришлось использовать DAO в зависимости от используемого API. Когда же всё перевели в новый API нам пришлось облазить весь код в поисках мест где использовался старый DAO и заменить его на новый.
Используя DI подход, единственное что мы бы меняли в коде это — написали бы новый парсер. А в DI сделали бы основную сборку DAO, и ее алиас который бы использовал другой парсер. И по ходу обновления api мы бы меняли только конфиг зависимостей, не трогая код.
А один раз встала необходимость вывести один виджет на всех поддерживаемых языках, вроде простая задача, и пришлось переписывать существующие компоненты. «Случай 4
» примерно об этом.
[/blah-blah mode]
Ну, это уже другая песня и на мотив метапрограммирования. Использовать аннотации для внедрения зависимостей, по-моему, это как микроскопом забивать гвозди :). А вообще, правда, их в JS не хватает. Я даже придумал механизм для создания, своего рода, «хуков» в js объектах, даже собираюсь написать о нем в новой статье. Но она у меня уже вышла больше этой, так что опубликую ее наверное в октябре, к тому же хочу взять за привычку написание демо приложений, чтобы показать подход на практике, как в этот раз.
Например, не инстанцируя объект от этого конструктора вы не прочтете его публичный метод, а до локальных вы вообще никак не достучитесь.
tzlom выше написал вполне неплохое решение для рефлекшенов в JS.
Но проблема в том что это не оригинальный подход, а уже довольно обыденный, и успешно используемый в других языках, например на такую реализацию меня частично подтолкнул DI в ZendFramework 2.0. Я же просто адаптировал и применил этот подход в Javascript, и для моих целей он себя оправдал.
А меня бьют в карму за то что показал какие есть подходы в разработке ПО, в том числе для JS. Так будто это я придумал этот паттерн.
Относитесь к этому как к имени сущности. Вы, наверное, заметили eval в коде, я его использую только потому, что сейчас пишу под SmartTV и планирую перенести на Node.js. Где разные объекты отвечают за глобальную область видимости.
В изначальном варианте eval’a нет, я извлекал непосредственно сущность с глобальной области видимости в JS так:
Еще раз повторюсь, для примера я выбрал самый наглядный вариант, видимо зря, более истинный вариант в демо, где я передаю исключительно имена сущностей которые в принципе можно выцепить window скопе. Безусловно — увы мне за хаки в примерах.
Можете указать конкретный момент? Вы, кажется, не поняли сути DI.
Понимаете, что когда вы пишете подобный код:
То это уже не правильный код, вы создали класс, в котором зависимости прописаны хардкодом. И это в любом языке будет не правильно. Даже в теории программирования желательно придерживаться чистых функций, об этом даже где-то тут писали. И да, этот момент можно решить фабриками для всех типов сущностей. Но, по-моему, это куда более тяжеловесный и трудоёмкий процесс и в принципе не полностью соответствует Open/closed principle.
Это же решение полностью решает такую проблему, и довольно элегантно. Я не выношу логику за приложение, я выношу определение компонентов (в данном случае AJAXclass и SomeDOMboilder) используемых в «классе», за его пределы.
Безусловно. Имелось в виду, что использование такого подхода сразу подразумевает использование как минимум половины SOLID принципов разработки. Я это упомянул в статье, такой подход заставляет писать правильно.
Из этого состоит «Вступление», спасибо что внимательно прочли.
Извините, я говорил об Open/closed principle. А Вы о чем?
А TDD это вообще программирование тестами. Но многим нравится.
Извините, за оффтоп. Мне всегда не нравилось что на хабре мало статей о такой замечательной, и быстроразвивающийся, технологии как Javascript. Я говорю о статьях с приемами программирования, или организации кода (как эта), а не статьи вроде — «Вышла новая либа нa JS» или «Пишем слайдер картинок вместе». И вот моя первая статья на хабре, но меня никто не понял.
Я понимаю, что это очень узкое направление в JS, но оно имеет право жить. Может кому-то будет интересно, а может даже и полезно.
Если ваши задачи на Javascript не выходили за эти рамки, мне нечего вам возразить. 90% людей пришедших в Javascript — это бывшие Front-end Guy, действительно, для них эта статья будет бесполезна. Но люди которые занимаются профессионально программированием на JS, часто сталкиваются со сложными задачами, когда нужно написать большое приложение не имея возможности построить нормальную абстракцию inbox инструментами.
Сейчас для меня web-браузер – это не основная, а одна из платформ для JS. А созданием GUI для обычных сайтов я вообще никогда не занимался.
Я не утверждал, что моё приложение покрыто тестами. Эта демка, для людей которые после прочтения статьи задаются вопросом – «А что дальше, как это будет выглядеть на практике в рабочем приложении?». Увы, в этот раз я был сильно ограничен по времени для покрытия демо приложения тестами. Тем более у меня была в мыслях идея написать статью о TDD в JS.