Если я все правильно понял из примеров, то интеграцию с javascript лучше бы оставить, да вдобавок утащить в проект еще и js-код из примеров (с доработкой напильником, понятное дело).
Потому что без javascript, например, не будет работать такая фича — в случае, если плееров несколько на странице, и один из них играет, то при нажатии «play» на другом плеере предыдущий играющий плеер ставится на паузу.
А чем вам мешает эта функция? По соображениям безопасности? По соображениям экономии трафика?
Скоро будем сдавать проект, в котором будем использовать ваш плеер.
Плеер очень хорошо выполняет свои прямые обязанности, не было проблем ни с установкой, ни с натягиванием шкурки. Пожалуй, он наименее глючная часть проекта :-)
Большое спасибо за ваш труд.
Из замеченных недостатков: хотя интеграцию с javascript, имхо, стоило бы доработать — слишком много на мой вкус глобальных переменных вроде uppodStopAll. Да и недостаток документации ощущается — благо, пользуясь примерами, удалось разобраться быстро, что и как. Разумеется, все недостатки — чистое имхо.
«Очень многие» — это сколько?
У меня все больше возникает ощущение, что это не «те товарищи» разумных слов не понимают, а у «эти товарищей» этих слов нет.
Это, опять же, мое имхо, но вот судя по этому топику и тем же последним постам dileSoft, с аргументацией на «этой» стороне не того.
Вероятно, раз автор не оставил пост в черновиках, он хотел, чтобы его прочитали. Я к тому, что если хочешь кого-то убедить в чем-то — надо бы, наверное, предоставить какую-то аргументацию для этого.
Я, заметь, никак не посягаю ни на свободу абстрактного человека писать абстрактный текст и пользоваться при этом любыми аргументами, ни на свободу конкретно islander писать пост в конкретно его блог то и так, что он посчитает нужным.
Я веду к тому, что эффективность именно такой постановки вопроса и именно такой аргументации, если хочешь кого-то в чем-то убедить, очень низкая.
Разумеется, все вышенаписанное — мое личное мнение.
В посте написано — «оказалось, что в функции-обработчике события оказался вызов console.log». Точка. Именно вот это и было.
А то, что написано в коде — это я, обжегшись на молоке, решил дуть и на воду и добавил еще и удаление console.dir — ну, чисто на всякий случай — мало ли, кто-то еще погорит. То, что вы поняли это вот так, как вы поняли — это, простите, ваше личное дело. Написано было другое.
Не было ни коммита, ни релиза. Был форс мажор в разгаре разработки. Я думаю, об этом можно догадаться, прочитав, что билд был выкачен за полчаса до встречи — такого после сдачи проекта не бывает.
Вот как оно есть.
Из этого не следует ни а), ни б), ни в).
Что касается оперы — во-первых, популярность этого браузера не идет ни в какое сравнение с популярностью ff3 ни в целом по миру, ни по данным статистики сайта клиента. Кроме того, добавлю вот что — поддержка оперы стандартов долгое время оставляла желать лучшего, и даже сейчас им до вебкита далеко. Это я к тому, если вдруг кто не понял, что я отказываю опере как в определении «популярный браузер», так и в определении «браузер, поддерживающий стандарты». Такой вот я нелюбитель оперы, да.
Что касается того, что вы написали после этих ваших пунктов — начали вы с того, что обвинили меня в разработке под один браузер. Прочитайте еще раз ваше первый комментарий в этом треде.
Это не я подобрал неудачные слова, а вы неудачно их поняли. А после того, как неудачно их поняли, считаете нужным оставить за собой последнее слово, для чего ищете любые способы придраться к моим словам и выставить себя правым. Именно вот так я понимаю ситуацию.
1) Это не так, и, более того, это никак не следует из моих слов. Я писал, что нашелся неучтенный вызов console.log. Так что остальные браузеры бы спокойно под них работали. Вот регулярка, которую я написал, удалит также и вызов console.dir, но это скорее перестраховка, чем необходимость.
2) Список фич, отличающих webkit night build от safari 4.0 настолько мал, и мы настолько далеко от него разрабатываем, что можно с полной уверенностью утверждать, что все, работающее в webkit, работает и в safari.
Привычка тестировать все в webkit, а не в сафари у меня осталась с тех времен, когда в webkit'е были нормальные инструменты разработчика, а в safari — нет.
Меня не оставляет ощущение, что вы считаете себя исключительно умным человеком, который изволит объяснять что-то несмышленышу.
Конечно, эта манера увеличивает доверие к вашим словам. В разы.
Лично я вижу другую тенденцию. Тенденцию писать не под браузеры, а под стандарты. Мы писали все под ff 3.1+, но все работает и под ie8, safari4, chrome3, только в опере глюки иногда вылазят.
А тенденция следовать стандартам, на мой взгляд, только набирает силу, и, таким образом, наше приложение и через сравнительно длительное время будет живее всех живых.
В этот раз мы пишем корпоративное приложение, которое будет работать только в интранете одной компании, где везде установлен ff в качестве основного браузера.
Это программа — веб-морда CMS.
Есть еще сам публичный сайт, и он работает кроссбраузерно, но он давно написан и сдан, сейчас вот добиваем последние задачи перед сдачей CMS.
Прочитал и сам офигел — действительно, для корпоративных нужд используется не ie, а ff ;)
Гм. Я даже в прострацию какую-то впал, когда увидел ваш комментарий.
Зачем мне честь от того, что я проверяю код во всех браузерах? И что это за честь такая странная? :)
И почему вы решили, что в данном конкретном случае не идет речь о том, что все веб-приложение пишется ровно под один браузер — ff 3.1+ и что это прямо так и прописано в ТЗ, прямо самим заказчиком?
Для алгоритма Хаффмана, который используется в gzip и deflate, нет совершенно никакой разницы, насколько длинное название метода, он все равно заменит его на один символ+смещение.
Так что на размере итогового файла название метода не скажется, а вот эти вот имена переменных вроде d('message') скорее мешают разработке, чем помагают.
Ну хабр иногда так глючит — например, подгрузка новых комментариев и прокрутка до следующего не прочитанного, что я бы не стал ставить его как пример «того, как надо».
А при чем тут ООП в вашем решении — извините, не совсем понимаю.
Про нее есть статьи на хабре: Введение в Continuous Integration и Continuous integration для php.
Потому что без javascript, например, не будет работать такая фича — в случае, если плееров несколько на странице, и один из них играет, то при нажатии «play» на другом плеере предыдущий играющий плеер ставится на паузу.
А чем вам мешает эта функция? По соображениям безопасности? По соображениям экономии трафика?
Плеер очень хорошо выполняет свои прямые обязанности, не было проблем ни с установкой, ни с натягиванием шкурки. Пожалуй, он наименее глючная часть проекта :-)
Большое спасибо за ваш труд.
Из замеченных недостатков: хотя интеграцию с javascript, имхо, стоило бы доработать — слишком много на мой вкус глобальных переменных вроде uppodStopAll. Да и недостаток документации ощущается — благо, пользуясь примерами, удалось разобраться быстро, что и как. Разумеется, все недостатки — чистое имхо.
По git-svn гугл на первой странице отдает ссылки на несколько отличных статей. Правда, англоязычных.
Если есть необходимость подключиться к svn-репозиторию, использую git-svn.
У меня все больше возникает ощущение, что это не «те товарищи» разумных слов не понимают, а у «эти товарищей» этих слов нет.
Это, опять же, мое имхо, но вот судя по этому топику и тем же последним постам dileSoft, с аргументацией на «этой» стороне не того.
Я, заметь, никак не посягаю ни на свободу абстрактного человека писать абстрактный текст и пользоваться при этом любыми аргументами, ни на свободу конкретно islander писать пост в конкретно его блог то и так, что он посчитает нужным.
Я веду к тому, что эффективность именно такой постановки вопроса и именно такой аргументации, если хочешь кого-то в чем-то убедить, очень низкая.
Разумеется, все вышенаписанное — мое личное мнение.
Уже давно идет не обсуждение, а черте-что.
Надо будет попробовать.
А то, что написано в коде — это я, обжегшись на молоке, решил дуть и на воду и добавил еще и удаление console.dir — ну, чисто на всякий случай — мало ли, кто-то еще погорит. То, что вы поняли это вот так, как вы поняли — это, простите, ваше личное дело. Написано было другое.
Не было ни коммита, ни релиза. Был форс мажор в разгаре разработки. Я думаю, об этом можно догадаться, прочитав, что билд был выкачен за полчаса до встречи — такого после сдачи проекта не бывает.
Вот как оно есть.
Из этого не следует ни а), ни б), ни в).
Что касается оперы — во-первых, популярность этого браузера не идет ни в какое сравнение с популярностью ff3 ни в целом по миру, ни по данным статистики сайта клиента. Кроме того, добавлю вот что — поддержка оперы стандартов долгое время оставляла желать лучшего, и даже сейчас им до вебкита далеко. Это я к тому, если вдруг кто не понял, что я отказываю опере как в определении «популярный браузер», так и в определении «браузер, поддерживающий стандарты». Такой вот я нелюбитель оперы, да.
Что касается того, что вы написали после этих ваших пунктов — начали вы с того, что обвинили меня в разработке под один браузер. Прочитайте еще раз ваше первый комментарий в этом треде.
Это не я подобрал неудачные слова, а вы неудачно их поняли. А после того, как неудачно их поняли, считаете нужным оставить за собой последнее слово, для чего ищете любые способы придраться к моим словам и выставить себя правым. Именно вот так я понимаю ситуацию.
2) Список фич, отличающих webkit night build от safari 4.0 настолько мал, и мы настолько далеко от него разрабатываем, что можно с полной уверенностью утверждать, что все, работающее в webkit, работает и в safari.
Привычка тестировать все в webkit, а не в сафари у меня осталась с тех времен, когда в webkit'е были нормальные инструменты разработчика, а в safari — нет.
Но вообще работало бы во всех перечисленных браузерах — в каждом из них есть объект console.
Единственный браузер, в котором могли возникнуть проблемы — ff без установленного файрбага, и именно он и стоял у заказчика.
Конечно, эта манера увеличивает доверие к вашим словам. В разы.
Лично я вижу другую тенденцию. Тенденцию писать не под браузеры, а под стандарты. Мы писали все под ff 3.1+, но все работает и под ie8, safari4, chrome3, только в опере глюки иногда вылазят.
А тенденция следовать стандартам, на мой взгляд, только набирает силу, и, таким образом, наше приложение и через сравнительно длительное время будет живее всех живых.
Это программа — веб-морда CMS.
Есть еще сам публичный сайт, и он работает кроссбраузерно, но он давно написан и сдан, сейчас вот добиваем последние задачи перед сдачей CMS.
Прочитал и сам офигел — действительно, для корпоративных нужд используется не ie, а ff ;)
Зачем мне честь от того, что я проверяю код во всех браузерах? И что это за честь такая странная? :)
И почему вы решили, что в данном конкретном случае не идет речь о том, что все веб-приложение пишется ровно под один браузер — ff 3.1+ и что это прямо так и прописано в ТЗ, прямо самим заказчиком?
Для алгоритма Хаффмана, который используется в gzip и deflate, нет совершенно никакой разницы, насколько длинное название метода, он все равно заменит его на один символ+смещение.
Так что на размере итогового файла название метода не скажется, а вот эти вот имена переменных вроде d('message') скорее мешают разработке, чем помагают.
Я бы не отказался от такого :)
А при чем тут ООП в вашем решении — извините, не совсем понимаю.