Еще подход, который используют в некоторых пролиожениях — использовать вебкитовскую обертку вместо Фонгапа и проксировать только те нативные API, которые вашему приложению нужны.
1) Количество задач, решаемых в Angular, сущесвенно больше: он дает вам структуру приложения, компонентизацию, раутинг, сервисы и т.д. Knockout предполагает, что для всего остального вы будете использовать другие инструменты. Например, Sammy JS для раутинга, Breeze JS для синхронизации данных с сервером, и т.д. В целом, выбор того или иного фреймворка — дело опыта и вкусовых предпочтений.
2) Показывать график без кода самого бенчмарка смысла нет. Легким гуглением можно найти ссылки на JSPerf, в которых как и Knockout, так и Angular оказываются быстрее. Все зависит от кода. Например, jsperf.com/angular-vs-knockout-vs-ember/161 Если пощелкать разные версии, то то один, то другой фреймворк оказывается впереди. По всей видимости, проблема не дает покоя фанатам каждого из них. На практике все эти фреймворки близки по скорости, и стоит обращать внимание на производительность в контексте вашей задачи (страница тормозит — открыли профайлер).
Не только вам, у меня в Опере почти никогда меньше 500 закладок не бывает. Хром, Новая Опера и ИЕ такой нагрузки на моих компьютерах не выдерживают. А вот стал пользоваться Firefox, и засчет tabs on demand он может Оперу заменять весьма достойно — живу сейчас на уровне 1500-2000 табов, одновременно загружены около 300.
Мы используем фингерпринты в своем продукте для борьбы с абьюзом. Очень эффективное средство, рекомендую. Только приготовьтесь к тому, что данных будет действительно много: для около миллиона асктивных учетных записей мы получаем около 8-10 миллионов новых записей фингерпринтов в месяц. Пока что мы их просто периодически чистим, хотя статистику по ним можно собрать весьма интересную.
Ну, такое. В/На/в Украине стандартная практика: если нужно изъять сервера, то выносят весь датацентр подчистую, не разбираясь, где чье железо. Возможно, это не так для совсем больших датацентров, но таких в стране немного.
Сейчас наблюдаю такую картину: на мобильном направлении полно проектов недели на 4, на 6. Т.е. если человек приходит на работу в компанию, то через 3-4 месяца у него в этой компании уже 3 проекта, ему все надоело, и он выходит на рынок. В результате уже который год для iOS-разработчика менять три-четыре работы в год — это нормально, и все HR и владельцы компаний это понимают.
В Опере (Mobile, Mini и Blink) если скролить, появляется кнопочка, при тапе на которую можно переместиться в начало или конец страницы — самая удобная прокрутка, которую видел на мобильниках. Как ее еще никто не скопировал?
Я не говорил про JS, просто привел его в качестве примера. По факту я могу с уверенностью трактовать условия GPL только для языков, производящих компилируемые артефаты: C, C++, Haskell, Fortran или Ada, например. Для языков, подразумевающих распространение в виде исходников — Python, Perl, JavaScript, Ruby и т.д. — я не могу быть до конца уверенным. С другой стороны, с CDDL, MPL, APL, BSD или MIT у меня не возникает никаких сомнений в плане использования. Поэтому я считаю, что эта неопределенность — недостаток самой GPL. Причем, у авторов GPL была возможность этот недостаток исправить, когда разрабатывалась третья версия.
Вот-вот, и никто не может сказать. И сколько людей, столько и мнений со своими аргументами. Нормального FAQ от самих FSF по GPL нет, есть какой-то 20-илетней давности, который вообще не отвечает современным сценариям. Спрашиввается, как можно ожидать, что люди будут продолжать использовать вашу лицензию, если она (или информация вокруг нее) не отвечает нуждам разработчиков?
Если у меня в компании GPL код на сотне серверов, но никаким третьим сторонам я его не отдаю, то я не являюсь его распространителем, и следовательно, релизить в опенсорс ни свои наработки, ни изменения в GPL-коде не должен. Таким образом, например, в Google используются свои версии Linux, компоненты сетевого стека и бессчетное число форков разных OpenSource-проектов,
AGPL по идее должен был решить эту проблему, но он не распространен из-за своей несовместимости с обычным GPL.
А вот если я серверный код распространяю*, то тоже непонятно, как быть. Допустим, у меня веб-приложение на Питоне, и я использую GPL-код на сервере. И допустим, я организовал свое приложение в виде нескольких изолированных модулей, которые хоть и крутятся на одном порту, но меж собой общаются только по HTTP. Мне обнародовать все приложение? А почему не только те модули, которые используюут GPL-код? А если я все компоненты разнесу по разным серверам, что-то изменится? А если некоторые модули будут общаться не по HTTP, а по какому-то другому протоколу — через те же системные вызовы, например?
*Например, я разработчик и пишу серверный софт для своей компании — это не считается распространением. А вот если я — внешний контрактор, то уже спорно.
1. Нет ни строчки о патентах. А патенты — дело мутное. Формально, в наших странах software patents не действуют, но при этом мы признаем патенты, выданные в других странах — членах WPO. В том же GPL, Apache и прочих есть пункты о патентах, сводящиеся к тому, что мои пользователи защищены, и если меня судят, то я отнимаю право на свои патенты у атакующего и могу использовать их против него. Но во-первых, у меня нет патентов и скорее я по незнанию нарушу чей-то патент, чем придумаю и запатентую что-то новое. А во-вторых, судиться с кем-то у меня нет желания и возможности. Проще о патентах вообще не говорить.
Кстати, если бы я выпускал опенсорс продукт как компания и зарабатывал на нем, я бы предпочел Apache, чтобы обеспечить своим клиентам дополнительную защиту. С другой стороны, Google для своего WebM сделал вообще финт ушами: отдельно лицензия BSD, где нет ни слова о патентах, и отдельно — патентный грант. Я несколько часов убил, пытаясь понять, чем такой «бутерброд» отличается от Apache лицензии, но так и не въехал. Так что ну их нафиг, эти патенты.
2. Я сам пишу закрытый софт и считаю, что другие тоже должны иметь на это право. Поэтому не копилефт. Возможно, я использовал бы «файловую» лицензию типа MPL 2.0, но не хочу добавлять геморроя тем, кто будет использовать мой код в своих проектах. Проще сказать «пулл-реквесты принимаются с благодарностью». Кто-то пришлет мне баг-репорт, кто-то забъет и поправит у себя в своем форке. Но мне не кажется, что использование MPL или LGPL заставит кого-то из «забивших» все-таки прислать мне патч или багрепорт.
3. Не BSD, т.к. их миллион разных видов, и между ними большая путаница. MIT с вероятностью 99% означает одно и тоже (нет гарантий, все даром, укажите меня в титрах).
4. С GPL или LGPL есть непонятки с тем, как она работает для некомпилируемых языков. Для Java, например, есть отдельный их вариант, а вот как ее интерпретировать для JavaScript, вообще непонятно. Скажем, вставил я на клиенте Ext JS, что мне теперь нужно обнародовать? Только те JS- файлы, где я использую Ext? Только тот код, который загружается на страницах, где есть Ext? Как быть с фреймами? Может, всю клиентскую часть приложения открыть? Или вообще все приложение целиком? Влияет ли возможность использования приложения в оффлайне на это? Т.е. я использую HTTP для дистрибуции моего приложения на JS, а сервер — это просто сервис данных, и частью приложения он не является :) Мутно в общем. И на сервере та же история.
5. Есть Boost License и WTFPL — еще более разрешительные (можно не указывать автора в титрах), но мне приятно знать о том, что кто-то моим софтом пользуется.
6. Бонус: раз я не беспокоюсь о патентах, и моя лицензия совместима практически со всеми, это означает, что мне не нужно заморачивасться с Contributions License Agreement, чтобы принимать патчи и пул-реквесты.
Да уж, или попадется какой-нибудь клиент, который ничего кроме GET и POST не умеет. Вариант с ?method=DELETE выглядит корявее, чем явное указание действия.
Если озаботиться поддежкой всякого безобразия вроде Outlook XP или 2003, то придется верстать таблицами и вспомнить про spacer.gif. Хорошо, что есть онлайн-сервисы вроде Litmus, которые показывают, как ваше письмо будет выглядить в разных клиентах. Оно стоит каких-то денег, но обычно достаточно сделать нормальные шаблоны, а потом уже новые письма делать по ним. И дальше вполне достаточно проверять для верности в Outlook.com и не тратить денег. Там микрософтовцы постарались часть косяков своих десктоп-продуктов воспроизвести, за что им спасибо. Не знаю, насколько это было сложно, но наверняка не тривиально.
К Гуглу я коннекчусь через IMAP, и там у всех все шито-крыто. Но есть у меня и ящики на почтовых сервисах, где IMAP нет или он платный, но где есть POP3. Например, в Outlook.com действительно все настраивается, и письмо уходит в каталог deleted/POP3. Другое дело, что если я проверяю этот ящик с помощью Opera Mail, то письмо отмечается как прочитанное, но ни в какую папку не перемещается, а остяется в инбоксе. Причем, я ничего для этого специально не делал. И мне лично как-то больше нравится, когда мой почтовый клиент не шебуршит письмами в моем почтовом ящике — простого mar read/reply/forward вполне достаточно.
Я тоже по началу расстроился, а потом вот что подумал. С учетом того, как верстают письма, чтобы те отображались в Outlook XP, 2003 и новее, возможностей Presto для писем и RSS хватит лет на 10. Если к тому времени у Opera Mail будет достаточно пользователй, то в компании найдутся ресурсы перевести ее на Blink.
Между прочим, на маке Opera Mail намного адекватнее родного почтовика работает с POP3. Apple Mail при отметке писем как прочитанные посылает на POP3-сервер запрос на удаление письма оО, а Opera Mail себе такого не позволяет.
Ну и статья от ЛинкдИна по теме длинных списков: engineering.linkedin.com/linkedin-ipad-5-techniques-smooth-infinite-scrolling-html5 Ничего суперграндиозного, просто описывают, как можно поэтапно упрощать структуру DOM, оставляя интерфейс отзывчивым.
1) Количество задач, решаемых в Angular, сущесвенно больше: он дает вам структуру приложения, компонентизацию, раутинг, сервисы и т.д. Knockout предполагает, что для всего остального вы будете использовать другие инструменты. Например, Sammy JS для раутинга, Breeze JS для синхронизации данных с сервером, и т.д. В целом, выбор того или иного фреймворка — дело опыта и вкусовых предпочтений.
2) Показывать график без кода самого бенчмарка смысла нет. Легким гуглением можно найти ссылки на JSPerf, в которых как и Knockout, так и Angular оказываются быстрее. Все зависит от кода. Например, jsperf.com/angular-vs-knockout-vs-ember/161 Если пощелкать разные версии, то то один, то другой фреймворк оказывается впереди. По всей видимости, проблема не дает покоя фанатам каждого из них. На практике все эти фреймворки близки по скорости, и стоит обращать внимание на производительность в контексте вашей задачи (страница тормозит — открыли профайлер).
в списке фич, что browser.js из Opera Presto переехал в каком-то виде в Opera Blink? И если это так, интересны подробности: как? зачем?
AGPL по идее должен был решить эту проблему, но он не распространен из-за своей несовместимости с обычным GPL.
А вот если я серверный код распространяю*, то тоже непонятно, как быть. Допустим, у меня веб-приложение на Питоне, и я использую GPL-код на сервере. И допустим, я организовал свое приложение в виде нескольких изолированных модулей, которые хоть и крутятся на одном порту, но меж собой общаются только по HTTP. Мне обнародовать все приложение? А почему не только те модули, которые используюут GPL-код? А если я все компоненты разнесу по разным серверам, что-то изменится? А если некоторые модули будут общаться не по HTTP, а по какому-то другому протоколу — через те же системные вызовы, например?
*Например, я разработчик и пишу серверный софт для своей компании — это не считается распространением. А вот если я — внешний контрактор, то уже спорно.
1. Нет ни строчки о патентах. А патенты — дело мутное. Формально, в наших странах software patents не действуют, но при этом мы признаем патенты, выданные в других странах — членах WPO. В том же GPL, Apache и прочих есть пункты о патентах, сводящиеся к тому, что мои пользователи защищены, и если меня судят, то я отнимаю право на свои патенты у атакующего и могу использовать их против него. Но во-первых, у меня нет патентов и скорее я по незнанию нарушу чей-то патент, чем придумаю и запатентую что-то новое. А во-вторых, судиться с кем-то у меня нет желания и возможности. Проще о патентах вообще не говорить.
Кстати, если бы я выпускал опенсорс продукт как компания и зарабатывал на нем, я бы предпочел Apache, чтобы обеспечить своим клиентам дополнительную защиту. С другой стороны, Google для своего WebM сделал вообще финт ушами: отдельно лицензия BSD, где нет ни слова о патентах, и отдельно — патентный грант. Я несколько часов убил, пытаясь понять, чем такой «бутерброд» отличается от Apache лицензии, но так и не въехал. Так что ну их нафиг, эти патенты.
2. Я сам пишу закрытый софт и считаю, что другие тоже должны иметь на это право. Поэтому не копилефт. Возможно, я использовал бы «файловую» лицензию типа MPL 2.0, но не хочу добавлять геморроя тем, кто будет использовать мой код в своих проектах. Проще сказать «пулл-реквесты принимаются с благодарностью». Кто-то пришлет мне баг-репорт, кто-то забъет и поправит у себя в своем форке. Но мне не кажется, что использование MPL или LGPL заставит кого-то из «забивших» все-таки прислать мне патч или багрепорт.
3. Не BSD, т.к. их миллион разных видов, и между ними большая путаница. MIT с вероятностью 99% означает одно и тоже (нет гарантий, все даром, укажите меня в титрах).
4. С GPL или LGPL есть непонятки с тем, как она работает для некомпилируемых языков. Для Java, например, есть отдельный их вариант, а вот как ее интерпретировать для JavaScript, вообще непонятно. Скажем, вставил я на клиенте Ext JS, что мне теперь нужно обнародовать? Только те JS- файлы, где я использую Ext? Только тот код, который загружается на страницах, где есть Ext? Как быть с фреймами? Может, всю клиентскую часть приложения открыть? Или вообще все приложение целиком? Влияет ли возможность использования приложения в оффлайне на это? Т.е. я использую HTTP для дистрибуции моего приложения на JS, а сервер — это просто сервис данных, и частью приложения он не является :) Мутно в общем. И на сервере та же история.
5. Есть Boost License и WTFPL — еще более разрешительные (можно не указывать автора в титрах), но мне приятно знать о том, что кто-то моим софтом пользуется.
6. Бонус: раз я не беспокоюсь о патентах, и моя лицензия совместима практически со всеми, это означает, что мне не нужно заморачивасться с Contributions License Agreement, чтобы принимать патчи и пул-реквесты.
GETиPOSTне умеет. Вариант с?method=DELETEвыглядит корявее, чем явное указание действия.Между прочим, на маке Opera Mail намного адекватнее родного почтовика работает с POP3. Apple Mail при отметке писем как прочитанные посылает на POP3-сервер запрос на удаление письма оО, а Opera Mail себе такого не позволяет.