Пару интересных ссылок за 3 апреля (вроде не первое)
Mozilla and Samsung Collaborate on Next Generation Web Browser Engine | The Mozilla Blog bit.ly/ZA02dX
Chromium Blog: Blink: A rendering engine for the Chromium project bit.ly/10atFGu
насправді не багато чого і змінилося
Да кто бы сомневался. War... War never change.
Translation from Bullshit to English ))
креатив отдаёт укушенностью и обидой, или показалось?
Укушенность — это у яблочников даже на логотипе. :)))
Apple очищает WebKit от наследия Chromium
habrahabr.ru/post/175579
Коментар порушує правила спільноти і видалений модераторами.
Микрософт скорее сдохнет, но не перейдет на вебкит.
превіт з 2021. як вам
Edge ?
Кстати, Servo пилят уже не один год, но после вчерашнего объявления о сотрудничестве с Самсунг все сделали вид, будто в первый раз о нем слышат. Ага.
В целом все понятно и так, вот тут очень хороший перечень причин: prng.net/blink-faq.html
Основная: Гугл не смог проталкивать через вебкит решения, которые могли бы каким-то образом навредить Apple или повернуть разработку так, чтобы им было удобнее. Вся история взаимодействия Google и Apple вокруг WebKit это подтверждает. Когда Гуугл релизнули Chrome, они хотели заменить JSC на V8 внутри Вебкита. Ребята с Webkit сказали им нет. Потом захотели вкрутить туда NaCl — им опять сказали нет. Потом сказали нет Dart’у. И наверняка еще ни раз говорили нет по разным мелким поводам.
Гугл пытался обойти проблему массой: нагнали дофига народу в WebKit. Коммитов у них суммарно столько же, сколько и у ребят из Apple, но в Apple это небольшая группа активных товарищей, а в Гугле — толпа народу, какждый из которых занимается Webkitом только парт-тайм. Потом перетянули к себе из Apple несколько ключевых конрибьюторов, в том числе и самого вожного: Eric Seidel. Но толку никакого: свои внутренние технологии проталкивать не получалось.
Вот решили отделяться — воевать-то как-то надо.
Доля хрома в 3 раза превышает долю сафари браузеров. Хром поддерживает разные платформы, Safari — одну. Почему Apple должен делать все что хочет, а Google подстраиваться под них?
Коммитов у них суммарно столько жеЭто вместе с отреджекчеными или только те которые Apple заапрувил?
Гугл не смог проталкивать через вебкит решения, которые могли бы каким-то образом навредить Apple
какая тут связь с этим:
Когда Гуугл релизнули Chrome, они хотели заменить JSC на V8 внутри Вебкита. Ребята с Webkit сказали им нет. Потом захотели вкрутить туда NaCl — им опять сказали нет. Потом сказали нет Dart’у.
Я правильно понимаю что любая фича от Google, автоматически вредит Apple?
Почему Apple должен делать все что хочет, а Google подстраиваться под них?
Сотрудники Apple — ключевые контрибьютеры проекта WebKit. Многие из них работают над проектом по 10 лет. В целом при принятии решений о развитии проекта их голоса имеют наибольший вес.
Это вместе с отреджекчеными или только те которые Apple заапрувил?
Какая разница? WebKit — огромный проект с кучей бранчей, портов и конфигураций,там нет одного такого места, куда коммитят все подряд и куда кого-то не пускают. У каждого такого подпроекта есть свои мейнтейнеры. Если что-то есть в QtWebKit, оно не обязательно попадает в WebKit-Gtk+. У Google в SVN вебкита хранилась достаточно большая часть кода, которая отвечала за интеграцию с V8, Skia, Chromium и т.д.
Я правильно понимаю что любая фича от Google, автоматически вредит Apple?
Нет. Но если фича приносит пользу Гуглу, но ребята из Apple ее не аппрувят, то Гуглу от этого становится хуже. Они терпели-терпели, да и форкнули.
ну, меня, ещё как и верстальщика, это не может не радовать, но с другой стороны — корпорация добра стала ещё «добрее» ))
Если гугл платит мозиле по 300 лямов в год за то, чтобы быть поисковиком по умолчанию, то я представляю какая стоимость этой гонки браузерных вооружений. А движок это основной козырь.
С одной стороны верстальщикам не позавидуешь, а с другой всегда будет работа, спрос и, соответственно, повышение зп.
Спасибо за ссылки.
Запуск проекта Blink — это понятное действие, главная задача которого — расколоть альянс WebKit. Сначала на уровне кодовой базы, а потом всё дальше развести проекты по совместимости с новыми (обычно придуманными в Google) стандартами. И более того, отсутствие отдельного префикса — тоже важный стратегический шаг. Позволяющий влиять на весь интернет в целом посредством внесения несовместимых изменений в свой рендеринг и браузер.
© Бобук
----
вот ещё точка зрения:
www.zdnet.com/...kit-7000013514
The fact that Google focused on simplifying the WebKit is telling. Sure, Google is interested in adding new features, but in such a multi-platform world, the idea of filling Blink with features that are incompatible with other rendering engines is almost unimaginable.
The reason Google wants Blink is down to one thing — the post-PC era.
WebKit is long in the tooth, and is a product of PC thinking.
Google wants to change that.
Когда Opera заявила, что сделает свой броузер object-oriented и добавит туда architecture, я подсознательно почувствовал неладное (А год был примерно
Вся дальнейшая история — это история попыток применения object-oriented к броузерам, можно не пересказывать, надеюсь сами помните (Тормозилла и пр.).
На фоне всей этой вакханалии, лично меня сильно порадовал Chrome в последние пару-тройку лет — им удалось ускориться, даже не взирая на OO. Какой ценой — мы тоже знаем.
И вот теперь — бац-вдруг-бах-трах кто-то захотел оптимизироваться...
Ну-ну, посмотрим, изобретут ли они велосипед (DOD), или всё снова будет как всегда... bit.ly/16xmB9q
Да чего мелочится, пусть вообще на асме кодят.
Да чего мелочится, пусть вообще на асме кодят.Неа, надо кодить на Руби например — чтобы открытие google.com минут на 5 вырубало ай-седьмой. :)
Или с другой стороны: Если речь идёт о производительности, чем вас, эстетов, не устраивает обычная старая добрая сишка? Синглетоны вам подавай, обджект-фектори, иначе не няшка? ;)
Неа. ООП, как и прочие парадигмы, был создан для уменьшения сложности. Паттерны были созданны для уменьшения сложности. Короче дешевле докупить памяти, чем оплатить время программистов, сражаюшихся с процедурным кодом. А браузеры сейчас тормозят из-за медленного соединения и сервер-кода, а не вашего любимого ООП.
Ничего себе медленное, сейчас эра онлайнмедиа, люди фильмы смотрят и музыку слушают через инет. Как раз тормоза происходят на стороне сервера, т.к. иногда на ООП можно так изощренно нагавнокодить, что сервак будет лопатить базу и огромные массивы несколько минут, чтобы отдать человеку 10 строк кода. Иногда гонят полбазы на сторону клиента с кучей библиотек, чтобы те же 10 строк вывести.
Архитекторов мало :)
ООП, как и прочие парадигмы, был создан для уменьшения сложности.А получилось — как всегда! :)
Паттерны были созданны для уменьшения сложности.А это — претендует на внесение на доску почёта. :)
Короче дешевле докупить памяти, чемЧем включить мозги.
А получилось — как всегда! :)
А это — претендует на внесение на доску почёта. :)Ну что тут скажешь, вы видимо не умеете их готовить.
Где-то была цитата из книжки по Дельфи, которую я как-то листал... о том, что оптимизация — это работа процессоров и компиляторов. А в жилах говнокодеров течёт голубая кровь! 8)Ну зачем вы так о МакКонеле.
Ну что тут скажешь, вы видимо не умеете их готовить.Меня поражает, как люди относятся к ОО как к некой религии - чур-чур что-то плохое о нём подумать.
Если люди не могут назвать ни одного, это лишь говорит что ОО — религия.
И я, кстати, уже перечислял, в памятной теме, и не так давно.
Если люди не могут назвать ни одного, это лишь говорит что ОО — религия.Почему ты так категоричен? На мой взгляд вполне могут быть абстракции без недостатков, а недостатки появляются уже в вариациях применения их в жизни
Простой вопрос: В чём преимущества а в чём недостатки, например, RDBMS? Любой технологии, которую использует специалист. Если этот специалист не может ясно назвать достоинства и недстатки, то это не специалист, а блондинка, в плохом смысле.
Для меня некоторые недостатки РДБМС более менее понятны, а вот с ООП не так, как скажем и с теоремой Каратеодори.
Ну ты хоть читал/понял то что Линус сказал об ОО?
Он писал о цпп а не о ООП. Нельзя так коверкать классиков.
Он писал о цпп а не о ООП. Нельзя так коверкать классиков.Ага. С третьего прочтения, я думаю, и ты поймёшь.
этот текст содержит очень ясную формулировку одного фундаментального недостатка ОО подхода.Ты видимо имеешь в виду:
Если там поменять object models на functions and structs ничего не изменится. Люди плодящие абстракции смогут их с легкостью наплодить и в структурном программировании.
inefficient abstracted programming models where two years down the road
you notice that some abstraction wasn’t very efficient, but now all
your code depends on all the nice object models around it, and you
cannot fix it without rewriting your app.
Мне кажется что это ты ударился в религию, Торвальдс очевидно написал этот пост в порыве чувств, скорее всего слабо себя контролировал, а эта ерунда разнеслась по интернетам будоража неокрепшие умы хомячков.
Ты видимо имеешь в виду:Суть этого высказывания проще выразить так:
неокрепшие умы хомячковВидимо ты имеешь в виду тех несчастных, которым вдолбили в голову что ОО есть абсолютное благо.
Ты принципиально исключаешь возможность существования других видов хомячков?
Но давай примем твою теорию, предположим я религиозная блондинка ищущая просветления, не мог бы ты озвучить недостатки ООП?
не мог бы ты озвучить недостатки ООП?Ну давай.
Ок, доводы формулировать не умеешь а отправляешь читателя самостоятельно просеивать кучи мусора
доводы формулировать не умеешьПросто не хочу. Не в настроении.
отправляешь читателя самостоятельно просеивать кучи мусораЛично я не один раз читал эти источники, и, думаю, большинству программистов очень полезно сделать это хоть раз. Но если для тебя это — «мусор»... нутыпонел.
Просто не хочу. Не в настроении.Блин, прийдется подождать пока у тебя появится настроение на что-то поконструктивнее чем плоские набросы
Но если для тебя это — «мусор»... нутыпонел.Это мусор в том смысле что и например тома Финтенгольца по отношению к топику, много умного текста(хотя конечно на 5 порядков умнее чем твои ссылки), а толку в контексте топика никакого — сплошной мусор.
Окей, перевожу на каанкретный язык. ;)
Недостатки ОО:
№ 1 Создание ненужных сущностей
№ 2 Чувствительность архитектуры к малым изменениям в требованиях
№ 3 Игнорирование потоков данных.
Ок, теперь было бы классно увидеть небольшие куски кода на джаве, и каком нибудь войтовичеугодном языке из которых были бы видны указанные тобой недостатки.
небольшие куски кодаО чего захотел! Это я щас полезу в кодебазу проекта и буду публиковать куски кода, которые являются собственностью заказчика? И что мне начальство на это скажет? Или заказчик? ;)
из которых были бы видны указанные тобой недостаткиПредставь себе ситуацию, когда у двух схожих параллельных проектов общая кодебаза. Но отличия всё-таки есть. Есть два пути разделения кода, 1) условная компиляция, и 2) полиморфизм. Так вот, народ, с колыбели пропитанный ООзмом, фанатично тулит полиморфизм, хотя при этом количество исходных файлов в проекте возрастает ВТРОЕ... если ты вообще понял о чём я.
О чего захотел! Это я щас полезу в кодебазу проекта и буду публиковать куски кода, которые являются собственностью заказчика? И что мне начальство на это скажет? Или заказчик? ;)А ты код не на работе писать не умеешь? Только холиварные коменты?
Но отличия всё-таки есть. Есть два пути разделения кода, 1) условная компиляция, и 2) полиморфизм. Так вот, народ, с колыбели пропитанный ООзмом, фанатично тулит полиморфизм, хотя при этом количество исходных файлов в проекте возрастает ВТРОЕ... если ты вообще понял о чём я.У меня есть глубокие сомнения по поводу «втрое», хотелось бы наглядных примеров, может у твоих товарищей руки просто не так настроены?
ИМХО, создание ненужных сущностей является скорее следствием недостатков «в ДНК», чем является собственно недостатком ОО*.
Достаточно начать проект словами «У нас всё будет по ОО и паттернам!», чтобы воздушные замки взлетели до небес. Лично видел эпик фэйл стори.
№ 1 bit.ly/16xmB9qОверинжениринг. Существует в любых парадигмах.
№ 2 bit.ly/17tVE7SТам вообще выброс в сторону плюсов, а не ООП в принципе. И даже игнорируя тот факт, что ООП плюсов не каноничное:
Если там поменять object models на functions and structs ничего не изменится. Люди плодящие абстракции смогут их с легкостью наплодить и в структурном программировании.
№ 3 Игнорирует потоки данных. Но это, я задеюсь, самоочевидно, и ссылка на авторитет здесь излишня.А это, как правило, и не нужно. Как говорил МакКонел — не оптимизируйте приложение, если не заставляют.
Как говорил МакКонел — не оптимизируйте приложение, если не заставляют.И, за одно, если нет ни совести, ни хорошего вкуса, ни стыда перед коллегами и потомками, ни здравого смысла.
Ваш код потом придётся кому то сопровождать. Пожалейте этого несчастного.
За 28 лет в программировании я уж постарался выработать хорошие привычки — мой код идеально читаем и тщательно откомментирован, в отличие от 95%... остальных... ;)
Но если Вы в Ваш код закладываете изначально неоптимизируемую архитектуру их воздушных замков, то я догадываюсь, кого нужно жалеть... :)
Ну окей. Пример кода OOP и его аналог с DOD в студию, посмотрим, что читаемее.
ООП:
class Забор
{
public:
Забор() {...}
virtual ~Забор() {...}
};
class ЖелезныйЗабор : public Забор
{
ЖелезныйЗабор () {...}
virtual ~ЖелезныйЗабор () {...}
};
класс ДеревянныйЗабор : public Забор
{
ДеревянныйЗабор () {...}
virtual ~ДеревянныйЗабор () {...}
};
ДОД:
enum Забор {Железный, Деревянный};
:)
Ты еще фабрику заборов забыл почему то, и билдер фабрик.
Смех и слёзы.
Ну что тут скажешь, вы видимо не умеете их готовить.
anonymous
Ivan Sorochan
Blitz
Sergii Voloshyn
Gremlin
Iaroslav Voitovych
Jo E
Jo E
Maksym Shysha
Андрей
Maks Slesarenko
Андрей
Апполинарий Эмануилович
anonymous
Iaroslav Voitovych
Blitz
Апполинарий Эмануилович
reality_hacker
Vitalii Maklai
public enum Материалы { Железо, Дерево }
public class Забор
{
public Материалы Материал { get; private set;}
public Забор(Материалы материал) {...}
}
PS: А заказчик — он такой. Сначала материалы, потом цвета попросит добавить, потом ещё что... Комбинаторику помните?
Ну я так сходу могу назвать один недостаток, правда существенный.
ООП не подходят для алгоритмов и концепций, которые не связанны с моделированием. Тут гораздо лучше справляется функциональная парадигма. Но ничего, ФшарпоСкалы нас спасут.
ООП не подходят для алгоритмов и концепций, которые не связанны с моделированием.как же мы жили без этого.
Тут гораздо лучше справляется функциональная парадигма.
ООП не подходят для алгоритмов и концепций, которые не связанны с моделированием.Какая чушь, право...
Не, батенька, чушь — это предложение применить оптимизационный паттерн к программам, которые мало того, что оптимизировать не надо, так ещё и сопровождать придётся. Ну а касательно моделирования — вы часто пробовали написать мат-приложение на чистом ООП языке?
оптимизационный паттернЭто о чём, о DOD что-ли? :)
мало того, что оптимизировать не надоА зачем оптимизировать правильно построенную систему? DOD даёт это по определению, OO не даёт этого в принципе.
так ещё и сопровождать придётсяИ дело это совершенно бесполезное, если речь идёт об ОО, потому как все воздушные замки из иерархий классов рассыпаются как карточний домик при одном лишь слове «оптимизация». :)
вы часто пробовали написать мат-приложениеЯ этим зарабатывал на хлеб, лет примерно 10 подряд.
на чистом ООП языке?А вот «чистый ООП язык» в контексте данной дискуссии — как марсианин в синагоге.
Очень забавно — методику, которая не является ущербной и однобокой, в отличие от ОО, обозвать какой-то частностью в рамках ОО?Ну это вы выдумываете. Паттерны есть везде, в любой парадигме. Недостактки тоже.
А зачем оптимизировать правильно построенную систему? DOD даёт это по определению, OO не даёт этого в принципе.ОО даёт системму понятную другому программисту. А оптимизацией в проектах, где быстродействие не является критичным, пусть занимается компилятор.
И дело это совершенно бесполезное, если речь идёт об ОО, потому как все воздушные замки из иерархий классов рассыпаются как карточний домик при одном лишь слове «оптимизация». :)А ООП и не для оптимизации делали.
Я этим зарабатывал на хлеб, лет примерно 10 подряд.Ну тогда понятно откуда батхёрт. 10 лет забивать гвозди плоскогубцами...
Ну это вы выдумываете. Паттерны есть везде, в любой парадигме. Недостактки тоже.На доску почёта! :)
ОО даёт системму понятную другому программисту.Какая чушь однако. Стопицотуровневая лозанья из врапперов — это понятный код? Вы ещё скажите, что следование канонам Александреску упрощает и код и сокращает его объём. :)
А оптимизацией в проектах, где быстродействие не является критичным, пусть занимается компилятор.Если программист живёт вот по таким «понятиям», то алгоритмы сложности O(N!) в O(NlnN) за него компилятор будет переделывать, ага. 8)
А ООП и не для оптимизации делали.ООП понятно для чего делали, вот только получилось как всегда. :)
10 лет забивать гвозди плоскогубцами...Юноша! Когда я забивыл гвозди, плоскогубцы ещё не изобрели, а Вы ещё не родились. 8)
На доску почёта! :)Тяжёлый у вас случай, ой тяжёлый... Вы бы GOF перечитали, что ли, там как раз во вступлении подробно объясняется, почему паттерны не есть ООП фича. Ладно, вот несколько паттернов функционального программирования: мемоизация, аккумулятор, продолжение.
Какая чушь однако. Стопицотуровневая лозанья из врапперов — это понятный код?Опять по кругу. Паттерны можно применять правильно и не правильно. Точнее к месту и не к месту. От-та копипаста с Хабра, которую вы пихаете как источник высшей истины, есть пример неуместного примения паттернов. Короче говнокодерства. То что говнокодеры неправильно используют методику — не делает её плохой.
Если программист живёт вот по таким «понятиям», то алгоритмы сложности O(N!) в O(NlnN) за него компилятор будет переделывать,Ну да, и виновато в этом ООП?! Не верю, пример в студию.
Юноша! Когда я забивыл гвозди, плоскогубцы ещё не изобрели, а Вы ещё не родились.Мне крайне сложно воспринимать вас серьёзно из-за обилия смайликов и планомерного обсирания 99% авторитетов и индустрии. Я и так еле сдержался от обвинения в неосиляторстве.
Ладно, вот несколько паттернов функционального программирования: мемоизация, аккумулятор, продолжение.На доску почёта Вы, юноша, угодили за эпичный аргумент в стиле «С точки зрения банальной эрудиции...», а не за знание вумных базвордов. :)
Опять по кругу. Паттерны можно применять правильно и не правильно.Это Вы, юноша, полностью сбились с толку, потому как речь шла именно об ОО, а не о паттернах. :)
От-та копипаста с Хабра, которую вы пихаете как источник высшей истины, есть пример неуместного примения паттернов.Это я взял дурной пример с реальностью-хакнутого, и лью свет в массы. :)
То что говнокодеры неправильно используют методику — не делает её плохой.Любая методика, используемая без понимания — суть КАРГО-КУЛЬТ. И, как мы выяснили в этой теме, НИКТО не понимает методику, так как понимание предполагает знание не только достоинств, но и недостатков. И персонально Вы — истый адепт Церкви Свидетелей ОО, потому как не смогли навзать ни одного его недостатка. :)
Мне крайне сложно воспринимать вас серьёзно из-за обилия смайликов и планомерного обсирания 99% авторитетов и индустрии.Смайлики: Я просто веселюсь, не могу сдержаться. А зачем ещё нужен ДОУ? :)
Это Вы, юноша, полностью сбились с толку, потому как речь шла именно об ОО, а не о паттернах. :)Тоже туда же.
Это я взял дурной пример с реальностью-хакнутого, и лью свет в массы. :)Вы взяли пример эпичного говнокода и выдаёте его за образец. Стыдно.
И персонально Вы — истый адепт Церкви Свидетелей ОО, потому как не смогли навзать ни одного его недостатка. :)Я привёл недостаток (который мне иногда мешает). Зато ваши доводы — это ЛОЛ.
№ 1 Создание ненужных сущностей
Неумение использовать.
№ 2 Чувствительность архитектуры к малым изменениям в требованиях
Неумение строить слабосвязные приложения.
№ 3 Игнорирование потоков данных.
Так и не должен, ООП помогает концетрироваться на предметной области, а не абстрактных потоках данных.
99% авторитетов: Авторитеты, как раз, тыкают ваше ОО мордочкой в его собственное г-но. Торвальдс. Степанов (Автор STL!). И даже Фаулер и Бек! МАЛО?И ещё Дейкстра. Но авторитетов — любителей ООП я могу привести гораздо больше. Поэтому то 99%, а не 100.
Перечислите три преимущества ООП.
Если по вашему их нету — тогда у вас это тоже, следуя вашем же понятиям — религия, только наоборот.
Если же вы их назовете, тогда ваш сер в сторону ООП — пустой треп.
Перечислите три преимущества ООП.Не преимущества, а достоинства. И их не три, их гораздо больше.
Кстати, интерестно — почему вот этот сайт настолько адски тормозит на айпаде и айфоне? Вроде, кучу сайтов в день посещаю с айпада — только этот умудряется джаваскриптами броузер подвесить. Интересно, это вина Вебкита?
ну раз в вебкитовом пока еще хроме все Ок, значит вина в непрямых руках отдельно взятой компании.
Какая версия айпада и айфона?
Тормозит до неюзабельности на 3GS, iPad1 и 4S. Иногда подвисает на iPad3. На компьютерном Сафари не тормозит.
У Макса сейчас как раз 4S, но в последнее время наблюдалось скорее ускорение работы, чем замедление, пару месяцев назад должно было тормозить больше.
Оно несомненно стало быстрее. Но все равно виснет.
Можете еще попробовать Chrome вместо Сафари на iOS, вдруг поможет.
А вообще изменения в коде ДОУ в лучшую сторону происходят регулярно, я, например, за последний месяц удалил 4К строк :), возможно, через некоторое время перестанет тормозить само по себе.
Эм. Я более чем доволен моим сафари — и мне действительно нужны всякие reading list. Читаю всякие реддиты со стековерфлоу, даже на ЖЖ не тормозит.
Вы уж тогда табличку на сай повесьте — что только в IE работаете.
Ну значит и ДОУ не будет тормозить — после очередного апдейта Сафари или ДОУ :)
Дело абсолютно точно не в Сафари.
а что значит тормозит? медленно загружается страница, медленно прокручивается, открывает каменты? Есть что-то типа фаербага? посмотреть сетевые задержки, ошибки JS, может какие-то модули стоят дополнительные или антивирус что-то блокирует. У меня была проблема, когда стоял Wappalyzer на слабеньком ноуте и он подвешивал Chrome на доувской странице, Firefox при этом работал нормально.
Тормозит все — скролл, прорисовка, т.д., включая набор текста. У меня впечатление — тормоза увеличиваются по мере кликов на счетчик непрочитаных коментов.
Антивируса нет (пользуюсь нормальными ОС), модулей нет. Как открыть веб инспектор на iPhone не знаю.
Попробуйте все таки поставить дополнительно хром или оперу и поработайте в них, правда в сафари вроде бы есть защита от фишинга, не знаю как это будет работать в хроме и опере без антивируса. Но по крайней мере можно посмотреть как будет вести себя доу.
Я читаю ДОУ чаще с телефона, сейчас это вполне шустро. Пару месяцев назад был ад.
Даже форма комментов стала более-менее. Непонятно, короче. Попробуй пожалуйста еще в режиме без регистрации
Сегодня сделали 2 небольшие оптимизации — перенесли вызов основного JS из «вниз» и отключили для мобильных Яндекс.Метрику и bigmit-счетчик, может не станет быстрее, но и не навредит.
Сафари — тормознутый броузер, если верить Peacekeeper, его все вставляют, даже ущербный IE, емнимс.
Ну и айфон — тоже невероятно скоростная платформа. :)
Среднестатистический пользователь Android проводит 18 минут в неделю объясняя, почему он не купил iPhone.
Среднестатистический пользователь Android проводит 18 минут в неделю объясняя, почему он не купил iPhone.
Середньостатистичний остроухов проводить 54 хвилини на тиждень, доводячи чи власники ондроєдів повні лохи і ніщеброди.п’ять
Середньостатистичний остроухов проводить 54 хвилини на тиждень, доводячи чи власники ондроєдів повні лохи і ніщеброди.При чем что удивительно он это сочетает с 10 постами о том как айфон тормозит и глючит. Очень противоречивая и не постоянная девушка.
Среднестатистический пользователь Apple в среднем 2,5 последних года своей жизни терпит насмешки и издевательства, и вынужден скрывать обиду, от чего психическая травма становится необратимой. 8)
Вы так долго не отвечали потому что розетки рядом не было?
Вы так долго не отвечали потому что розетки рядом не было?[:||||||||||||||||||||||||:]
Sandro Zakusilov
Євген Остроухов
Sergii Voloshyn
Max Ischenko
93 коментарі
Додати коментар Підписатись на коментаріВідписатись від коментарів