Фреймворк приятный, но у нас с ним был не очень успешный опыт работы. Пытались использовать Sencha Touch в одном из наших проектов, но в итоге отказались т.к. не смогли побороть некоторые проблемы с тормозами.
Так, например, в Android-приложении прокрутка списков состоящих из даже 20+ элементов (с не сильно сложным содержанием) заметно подтормаживала.
Я продолжаю удивляться. Пост, как называется? «Выбор технологии для разработки браузерных игр». Посмотрите на популярные браузерные игры, какие у них требования? А вы не задумывались почему?
То, что разработчики не хотят поддерживать старые версии, это понятно, они этого никогда не хотят, но условия рынка диктуют совершенно другое.
Представляю заказчика, который заказывает игру и говорит: «А что IE 7, 8, куча пользователей, не, у нас новые технологии, а пользователи пусть сами выкручиваются».
Так почти никогда не бывает.
У автора и так 7 наименований браузеров, т.е. о кроссбраузерности он все же задумывается. )
Пользователей IE реально много, и они от игра не откажутся, они просто пройдут мимо, когда поймут что что-то там не поддерживает. Т.к. они могут просто не хотеть/не уметь/не иметь возможности что-то менять в своем привычном окружении.
Причем здесь это? Я говорю о коммерческой выгоде, в данном случае вы теряете большой кусок пирога когда отказываетесь от поддержки большинства пользователей IE.
Ответил выше, на похожий комментарий от TheShock'a.
Мой поинт в том, что есть куча пользователей, которые не скоро поставят IE9 или вообще замену IE, и о них забывать нельзя т.к. это тоже весомая часть рынка.
Мне и вам не тяжело, но попробуйте это объяснить всем тем кто еще только вчера с IE6 на IE8 перешел или даже еще не перешел, что им надо куда-то там переходить. А ведь таких пользователей очень много. А при разработке продукта рассчитанного на широкую аудиторию о них забывать ну ни как нельзя.
Как старый поклонник FAR'а его и использую для работы с Linux серверами из под Win. Т.е. FAR + WinSCP plug-in. Может хранить произвольное число профилей серверов + все плюсы от FAR'а (colorer и т.п.).
Получается для работы и в Win и в Linux один менеджер, но, правда, у меня и задача по части Linux'а не особо сложные.
Спасибо, но есть проблема. Т.к. скрипт работает для habrahabr.ru/add/*, то если пост хотя бы раз попал в черновик, а я часто сохраняю еще неготовую версии в черновик, то он работать не будет, т.к. адрес будет уже другой. Если же добавить туда и habrahabr.ru/edit/*, то это будет не очень удобно т.к. изменения к уже готовой и опубликованной статье (тот же адрес), наверно, подтверждать не нужно, т.к. скорее всего они незначительны.
Т.е. это должно работать только для статей, которые еще не были опубликованы.
Т.е всякие потверждения «Действительно опубликовать?» я был не хотел.
Смотря как сделать ) Если, например, по нажатию опубликовать попадать на предпросмотр с заменой стандартных кнопок на аля: подтвердить и назад, возможно будет выглядеть ненапряжно. Но уверен есть уже проверенные решения для таких ситуаций.
Менять расположение кнопок — тоже многим будет мешать… Вот если бы 5 лет назад это сделать, тогда да )
… где она останется навсегда, а это не очень красивое решение.
Если же ее доделать в черновике и снова опубликовать, то она будет опубликована датой первой «публикации» т.е. затеряется за уже опубликованными статьями.
Т.е. что в ссылке приведенной вами есть method overloading вас не смущает, а method overriding смущает? Вы же написали, что method overriding это не полиморфизм.
Ладно. Итого, я считаю, т.к. в стандарте нет точно описания, что можно считать полиморфизмом, а что нет, все рассуждения на эту тему высказывание собственного мнения, которое не может считаться конечной инстанцией.
Мы пришли к такому же выводу. Но т.к. были ограниченны во времени, то пришлось смотреть в сторону других решений.
Так, например, в Android-приложении прокрутка списков состоящих из даже 20+ элементов (с не сильно сложным содержанием) заметно подтормаживала.
То, что разработчики не хотят поддерживать старые версии, это понятно, они этого никогда не хотят, но условия рынка диктуют совершенно другое.
Представляю заказчика, который заказывает игру и говорит: «А что IE 7, 8, куча пользователей, не, у нас новые технологии, а пользователи пусть сами выкручиваются».
Так почти никогда не бывает.
Пользователей IE реально много, и они от игра не откажутся, они просто пройдут мимо, когда поймут что что-то там не поддерживает. Т.к. они могут просто не хотеть/не уметь/не иметь возможности что-то менять в своем привычном окружении.
Мой поинт в том, что есть куча пользователей, которые не скоро поставят IE9 или вообще замену IE, и о них забывать нельзя т.к. это тоже весомая часть рынка.
> Explorer 9+
Вы видимо отпечатались? Иначе большинство пользователей Windows вас возненавидят с таким подходам к разработке браузерных игр )
Получается для работы и в Win и в Linux один менеджер, но, правда, у меня и задача по части Linux'а не особо сложные.
Спасибо за скрипт!
P.S. ИМХО централизованное решение все же было бы лучше, но видимо здесь это нереально, т.к. всем не угодишь.
Т.е. это должно работать только для статей, которые еще не были опубликованы.
Смотря как сделать ) Если, например, по нажатию опубликовать попадать на предпросмотр с заменой стандартных кнопок на аля: подтвердить и назад, возможно будет выглядеть ненапряжно. Но уверен есть уже проверенные решения для таких ситуаций.
Копки сейчас ведь ужасно выглядят, ИМХО конечно.
Если же ее доделать в черновике и снова опубликовать, то она будет опубликована датой первой «публикации» т.е. затеряется за уже опубликованными статьями.
ИМХО, самое полезное было бы, если бы вы перечислили эти преимущества и недостатки )
Ладно. Итого, я считаю, т.к. в стандарте нет точно описания, что можно считать полиморфизмом, а что нет, все рассуждения на эту тему высказывание собственного мнения, которое не может считаться конечной инстанцией.