Ссылки Артемия Трегубенко о веб-разработке за сентябрь 2010

State of mobile web development, part 3/3: the mobile industry’s failings

Recently Mike Rowehl, a mobile developer with relatively little knowledge of the web world, confessed to being baffled by the attitude of web developers interested in mobile.

This is the last part of my reply. In parts one and two we talked about what web developers are doing wrong; now we’re going to talk about the errors of the mobile world.

Web developers, web developers, web developers

Mike says:

It was my impression that the next generation of mobile web technologies was supposed to cater to the existing set of web developers and make mobile an attractive option for them. I’m not seeing that happen however.

Everybody wants web technologies; nobody wants web developers.

Company after company declares its eternal and undying allegiance to the web. W3C Widgets, pioneered by Opera and Vodafone, are now more-or-less supported by Samsung, Nokia, and RIM. Palm staked its entire existence as a company on webOS.

Problem is, companies that choose for the web don’t bother to follow up with outreach to web developers. I was fascinated by webOS when it was announced in early 2009, but I was unable to establish a connection to Palm and in the end decided not to bother with it. Similar stories abound.

The first company that succeeds in really communicating with web developers will get its product accepted by an already-existing, large and tightly-knit development ecosystem that hasn’t taken sides yet in the mobile platform wars. As a result, its web-based platform will be filled to overflowing with cool applications.

But mobile companies just don’t seem to be able to do it. (Based on personal observations I’d say Vodafone, Palm, and RIM are willing; but they’re still in the process of getting their act together.)

Absent any change the prize will eventually go to Google or Microsoft (or possibly Opera) because these companies have already established communications with (desktop) web developers. (Apple could do it, too, but it’s not interested since it already has a platform filled to overflowing with cool applications.)

In other words, if the mobile companies don’t adapt to web developers they’ll be usurped by the old “fixed web” companies — at least, as far as web technologies are concerned.

Fiercely independent

I think I have a vague inkling of what the fundamental problem is. The web development ecosystem of blogs and conferences, books and barcamps, was created by web developers themselves by the sweat of their brows. Especially during the early formative years we got little support from large companies.

That changed, when (in no particular order) Adobe, Yahoo!, Microsoft, Google, Opera and some other companies were accepted by the web developers and were listened to seriously.

Why exactly these companies? Because they took the time and trouble to listen to web developers, meet them on their own ground, and make serious efforts toward standards compliance.

Still, web developers have learned to be fiercely independent and to distrust large companies, and especially marketing nonsense. They’re quite willing to listen to serious arguments, but those arguments have to be made in their style, at their conferences and blogs, and have to address issues that web developers deem important.

However, mobile companies are just telling their marketing people to establish contact, and web developers are allergic to marketeers. They want to be in touch with engineers and technicians. As a result there’s no meaningful communication.

Contests

The highest revealed truth about communicating with web developers is a kind of contest, where there’s an inordinate amount of money to be won with writing a widget, an HTML5 game, or whatever technology the organising company wants to push.

This doesn’t work. Sure, some web developers are swayed and participate in order to get some money. But, even if they win, will they ever make a mobile web product again, when there’s no specific incentive to do so?

As far as long-term results go the mobile companies could just as well have flushed their money down the toilet. If they’d spent a fraction of it on actually communicating with web developers on web developers’ terms, they would have some results to show now.

SDKs

Another point that just has to change is SDKs. Right now the revealed truth is that anyone who pushes anything into the mobile web space must release an SDK, too.

But web developers don’t use SDKs.

They’re just not necessary. If you want to make a website, you need a text editor, a graphics program, a web server, and some browsers to test in. That’s it, and many of the best web developers pride themselves on needing nothing more.

Besides, there’s far too many SDKs. If I were to take them seriously, I’d have to install the Android, BlackBerry, Samsung, Vodafone, Microsoft, and Nokia ones, plus probably a few more I can’t remember right now. Not only will that make an unholy mess of my computer, it’s also far too much cruft if I just want to make a website or mobile web app.

The only thing that these SDKs hold that’s actually interesting to web developers is the various signing procedures for widgets; especially for the BlackBerry and Samsung bada platforms. I wonder if web developers are going to download them just for this one feature.

Sure, if you have a paying client you’ll do it, but I’m thinking of web developers that don’t have particular mobile clients but want to try their hand at these exciting new technologies. Will they download Eclipse plus a series of plugins for three, four, six, eight platforms? I don’t think so.

It would be very useful if signing procedures could be done online. Upload your widget and request a sign-off, and a few days later you’d get it back signed and ready to run. Unfortunately all mobile companies are still in walled-garden mode, so this won’t happen any time soon.

Concluding: mobile companies are fundamentally unable to communicate with web developers.

Browser detects

Mike says:

The technique that I see most folks using is segmenting their traffic and swapping things out on the web server. They design for desktop, high capability mobile, and low capability mobile. They detect what device they’re serving to normally based on the user-agent, and then serve up the correct version directly.

Twelve years ago this was the highest reveled truth about making websites. Nearly everybody did it.

And everybody was wrong. Not “there’s something to say for it but sometimes you don’t need it” wrong, but just plain “you have no clue what you’re doing” wrong.

Do you know why nearly all browsers start their UA string with Mozilla/? It’s because of browser detects. Not current browser detects, but those of the early nineties. Back then clueless people used the string Mozilla/ to determine whether a browser was modern (i.e. Netscape) or not.

When IE hit the market it could do most of what Netscape could. However, in order to end up on the right side of the browser detects, Microsoft, too, had to start its identification string with Mozilla/. All browsers that were released later followed suit.

That’s the kind of nonsense browser detection will lead to.

Just say no

I was one of the first web developers to speak out against this practice, and I will continue to do so now that I’ve moved to mobile. I aim to prove that it’s simply not necessary, besides being wrong on a fundamental level.

Why is browser detection so wrong?

It’s incomplete. There’s just no way we’re going to be able to incorporate all devices in this detect. And even if we miraculously did, the next week a new device would hit the market and we’d be incomplete again.
It’s unreliable. You’re always going to miss something or make a mistake in your detection.
It’s an arms race. If device detection really catches on, browsers will start to spoof their user agent strings to end up on the right side of the detects. Web developers will retaliate by even more finely-grained (and even less complete and reliable) detects, which will cause the browser vendors to improve their spoofing etc. This has happened on desktop (just ask Opera about it), and we should keep the mobile space free of this nonsense.
It’s cheating. If you make any mistake at all (and that’s inevitable, really), you’re either denying advanced functionality to a browser tht can handle it, or sending advanced functionality to browsers that can’t handle it. In either case you cheat your end users.
It’s inflexible. Sites that were created for any device will be much more flexible in all kinds of situations because the web developer planned for the unknown. Conversely, if you rigidly sort devices into groups and then code for those groups, this rigidity is going to make your site unable to react to the unforeseen.

As far as I’m concernd people who use it aren’t aware of current thinking in web development (and by “current” I mean anything that happened in the last twelve years).

What I’ve noticed far too often is that people who don’t know too much about the intricacies of web development choose this solution, mostly because it seems an easy way out of a tricky situation.

It was only a few months ago that I talked to someone from the mobile world who advocated device detection “because all Java programmers do it.” That’s the perfect summary of all that’s wrong with this technique.

That said, I must admit that even within the web development community some are arguing for a form of detection. It would not be based on the browser string, but rather on a list of capabilities created by some nifty JavaScript checks, and it would not serve completely different websites, but only those parts of the script that are necessary for the device, leaving out useless code branches meant for other devices.

To me, the crucial question is whether the server-side device detection takes place by browser string or otherwise. If by browser string, it’s just plain wrong. Period.

Conclusion

In this series we’ve seen that mobile web developers are making plenty of mistakes, but that that’s mostly due to an iPhone-centeredness that’s partially (but not entirely) caused by demand, coupled with a crippling lack of tools that are available on desktop but still have to be ported to mobile.

Simultaneously, communication by the big mobile companies that don’t play a role in the desktop web, is shockingly bad.

As far as I’m concerned that explains why there’s such a discrepancy between what mobile web developers should do, what they actually do, and what mobile companies have to offer.

Incidentally, if you’re interested in these matters, why not join the Mobile Web?

RSI — как бороться с туннельным синдромом

Начальные симптомы туннельного синдрома у меня появились в конце девяностых. И конечно же, как и все другие будущие пациенты с RSI, я их проигнорировал. В 2000 году

oleyka прислала мне клавиатуру Acer Ergo 61 (ошибочно прозванную «13R Future» в Компьютерре), с которой первые симптомы практически исчезли, и я смог ещё несколько лет поработать в своём обычном темпе. Но клавиатура всего лишь позволила мне продолжать травмирующую активность более интенсивно.

А затем наступил звездец. Переработав более суток без перерыва при сдаче релиза, первого сентября 2005 года я не смог почистить себе зубы, так как не сумел открыть зубную пасту. Была дикая боль и одновременно слабость в руках.

Месяц спустя врач, к которому уговорили пойти меня коллеги в Cisco, диагностировал «a mild case of RSI/CTS» (repetitive strain injury / carpal tunnel syndrome). Первые три месяца я практически не прикасался к программированию. Затем ещё полгода делал минимально общественно полезную деятельность: 50 строчек в день считалось удачей. Это с учётом написания писем. Код же, с его постоянными двух- или трёхклавишными комбинациями (скобки, подчёркивания, camelcase) набирать было особо неприятно. Если это считается «mild case», тогда что же такое не mild case?..

Зато болезнь помогла мне читать книжки — а что ещё оставалось делать? Так был прочитан завал литературы, выучен Haskell, проштудирован Tufte.

Проверка предрасположенности к RSI у мужчин.

Я пытался применить систему голосового распознавания, но быстро бросил: она посадила мне голосовые связки так, что я не мог разговаривать в голос. Оказывается, у людей с врождённой предрасположенностью к RSI (предрасположенность проверяется путём доставания большим пальцем запястья той же руки), голосовые связки очень быстро садятся от постоянной активности. Так что, voice recognition мне не помог. Единственное, что осталось от этого эксперимента — неплохая USB-гарнитура, которую использую для Skype-переговоров.

Человеческий организм очень неумело заживляет внутренние травмы, типа RSI: эволюционно человек не предрасположен к монотонной многочасовой деятельности, и у него нет развитых механизмов обнаружения (например, рецепторов боли, как на коже) и лечения внутренних травм сухожильной сумки.

Соответственно, полугодового «отдыха от работы» мне не хватило. Я мог написать 50-100 строк кода в один день, но потом боль не давала мне работать всю оставшуюся неделю. Я пытался отдыхать от клавиатуры неделю, две без перерыва. Работать тыльной стороной ладони — суставом мизинца. Это снимало боль, но как только я начинал программировать, боль возвращалась буквально через несколько написанных строк.

Позволить себе год держать руки абсолютно без травмирующей активности я не мог — или по крайней мере думал, что не мог. Кроме того, в 2006 у меня родился сын.

В конце концов, после многих экспериментов с тем, сколько же я «теперь» могу работать, с периодами воодушевления (о, я уже второй день не чувствую боли!) и разочарования (уже неделю отдыхаю, но попытка нажать клавишу всё равно ведёт к болезненным ощущениям), у меня сформировалась некоторая система. Система не привела к тому, что у меня пропал RSI. Система другого рода — она позволила планировать мою активность, знать, сколько я могу работать, и точнее предсказывать сроки, в которые работа будет завершена.

Сначала замечу, что RSI почти не лечится, или лечится десятилетиями. То, на что вы можете рассчитывать — это законсервировать процесс на текущем уровне. Главное, что может в перспективе хоть как-то помочь — это прекращение травмирующей активности, то есть программирования и работы с клавиатурой. Уйдите в менеджмент, в конце концов: email меньше травмирует, чем кодирование кода. Используйте менее многословные языки программирования, например функциональные языки программирования, Perl. В этом отношении PHP лучше, чем многословная Java, а Haskell лучше, чем PHP.

Рекомендую книгу Dr. Pascarelli's Complete Guide to Repetitive Strain Injury: What You Need to Know About RSI and Carpal Tunnel Syndrome.

Так вот, нехитрый список правил того, как жить с RSI:

Мышку использовать нельзя. В списках причин RSI мышь стоит на первом месте. В опросниках у врачей по поводу RSI мышь стоит на первом месте: «Используете ли вы компьютерную мышку?» Используйте точпад. У меня есть точпад и планшет, но планшет мне неудобен для повседневной работы всё-таки. Некоторые говорят, что приноровившись, планшет эргономичнее. Чем что? Чем мышка — конечно. Чем точпад? Сомневаюсь.
Используйте vi, а не Emacs. Многоклавишные комбинации вредят эргономике процесса http://xahlee.org/emacs/emacs_hand_pain_celebrity.html
~~Коротко стригите ногти~~ Обрезайте ногти под ноль. Два миллиметра — уже много. Нажатие на клавиатуру подушечками пальцев щадит связки сильнее, чем нажатие или задевание части поверхности клавиши ногтями.
Используйте клавиатуру с мягким ходом клавиш, без «дребезга» и щелчков. Шелчки передаются связкам и травмируют их.
Сухожилия давят на сухожильную сумку и перетирают, раздирают её изнутри. Вывод: нужно держать руки так, чтобы сухожилие не проходило в запястье под углом. Эргономические клавиатуры нехило помогают, но не все клавиатуры, на которых написано «Ergonomic» являются такими. Например, клавиатуры с верхним рядом клавиш, расположенным выше (дальше от поверхности стола), чем нижний, такими не являются. Некоторые модели Kinesis рулят, Acer Ergo 31/61 рулит (но её невозможно достать). В крайнем случае, если уж совсем ничего нет, сойдёт Microsoft Ergonomic Keyboard.
Печатайте размеренно, в одном ритме и подчёркнуто медленно. Старайтесь делать одинаковые интервалы между нажатиями клавиш, и не допускайте особо вредных взрывных нагрузок, когда после относительно долгого обдумывания строчка или токен набиваются моментально, одним проходом рук. Лучше помедленней набрать, чем сорвать руку таким образом.
Для того, чтобы кисти приучались не изгибаться в процессе работы, нужны развитые кости и мышечный корсет. Если вам до 25 лет — идите в качалку, тренируйте мышцы рук. Это будет способствовать развитию костей. Если вы старше, то кости уже сформировались, и изменить их практически невозможно. Так что берите PowerBall и/или занимайтесь спортом, адресно тренирующим мышцы кистей: скалолазание или бадминтон, например. Не теннис.
Будете использовать PowerBall — используйте без фанатизма. Регулярное превышение 6-8 тысяч оборотов на нём вам сделает RSI, если его даже не было. Для того, чтобы укрепить мышцы, надо систематично крутить его на относительно небольших оборотах: «столько, пока комфортно терпишь, плюс ещё тридцать секунд».
Рука в процессе работы не должна лежать на клавиатуре или столе, а должна держаться на весу. Класть руку на подушку клавиатуры или на стол можно только если в это время не происходит нажатий на клавиши.
Для больших движений используйте большие мышцы, для малых — малые. Это значит, что набирать на верхних рядах клавиш нужно перемещая всю руку, а не путём доставания до крайних рядов клавиш вытягиванием пальцев. Во время печати кисть не должна двигаться влево-вправо или вниз-вверх, следите!
Сплинты — это такие медицинские перчатки без пальцев, укрепляющие кисть. Использовать их при работе нельзя, они приводят к деградации мышц при относительно недолгом использовании. Через неделю работы в сплинтах мышцы атрофируются настолько, что есть шанс совсем не суметь работать без сплинтов. Сплинты можно иногда использовать на ночь, чтобы во время сна не перегибать кисть. Но в конце концов надо от сплинтов избавиться. Я был только первые полтора года в сплинтах — спал в них, и лишь очень изредка работал.
Ибупрофен — копеечное, но очень действенное лекарство, с минимумом побочных эффектов. Оно эффективно снимает боль и обладает противовоспалительным эффектом. Оба свойства подходят для снятия симптомов боли и/или онемения. Но использовать его во время работы нельзя — воспаление-то оно чуть притушит (хорошо), но симптом боли снимет. В итоге вы не будете чувствовать, когда требуется срочно прекращать активность. Короче, если пользоваться ибупрофеном — а на начальных этапах лечения именно его и рекомендуют — ибупрофен надо принимать после травмирующей работы, или перед сном. Чтобы боль во время работы никуда не исчезала и была индикатором того, что надо завершать процесс.
Перед работой руки следует прогревать. Сначала тёплой водой под краном, затем разминающие, разогревающие мышцы и чуть-чуть растягивающие действия кистями.
Не работайте на ноутбучной клавиатуре, и тем более, не работайте на ноутбуке лёжа. День работы на ноутбуке мне стоит трёх дней отходняка.
Алкоголь дополнительно повреждает нервы в воспалённом районе кисти и, похоже, смазку сухожилий. FYI: пить вредно.

Следуя этой системе, теперь — через пять лет после пика травмы — я могу ежедневно писать до 100 строк кода или пропорциональное количество плейнтекста, не боясь долгое время провести в отходняке. Ну или можно написать до 300 строк, если знать, что следующие два-три дня можно устроить себе выходной и «отлежаться».

PHP и UTF-8

Все уже на UTF-8, а PHP как-то не успел запрыгнуть на поезд. Я сейчас исследую тему перевода одного большого веб-сервиса на UTF-8, а он, так случилось, написан на PHP.

Увы, с UTF-8 в PHP всё очень тяжело. «Голый» PHP c UTF-8 работать, можно сказать, не умеет. Положение несколько скрашивает модуль Multibyte String, особенно тем фактом, что он умеет заменять некоторые функции на их Unicode-аналоги автоматически. Увы, не для всех строковых функций PHP в этом модуле есть аналоги, например, для strspn его не существует. Таких функций, увы, больше, чем хотелось быть.

Немного праздника в этот однобайтный склеп привносит тот замечательный факт, что UTF-8, в общем-то, придумали неглупые люди — по виду байта всегда можно отличить где мы — в начале последовательности символа или нет. Это позволяет таким функциям, как str_replace или strtr работать и с UTF-8 тоже.

Печальнее всего с двумя вещами.

Во-первых, PHP самой распоследней версии всегда считает, что строки содержат символы размером в один байт, на практике это значит, что $str[$index] вернёт на не $index-й символ, а $index-й байт последовательности символов, а это существенная разница. Найти все такие места в коде и не перепутать их с адресацией к массиву — задача непростая. Я придумал для этой цели использовать специальную функцию, которая, если на вход ей подаётся массив, работает с ним правильно, тихонько логгируя все такие вызовы.

Вторая проблема заковыристее. В PHP испокон веков аж три модуля для работы с регулярными выражениями — PCRE, Regular Expression (POSIX Extended) и уже знакомый нам Multibyte String. Первый работает с Perl-совместимыми регулярными выражениями, оставшиеся — с POSIX-синтаксисом, причём «Multibyte String» содержит UTF-8-аналоги всех функций из «Regular Expression (POSIX Extended)».

PCRE в таких помощниках не нуждается, потому что сам умеет работать с UTF-8, у него даже ключ специальный есть — «u» («Unicode»). Это в теории. На практике код

    if (preg_match('/(\w)/iu', 'ПриветN', $m)) {
        var_dump($m);
    }

Выдаст нам… букву «N». Почему? Находить в строке UTF-8-символы куда сложнее, чем символы размером в один байт, поэтому для производительности разработчики решили, что… Впрочем, слово разработчикам:

Matching characters by Unicode property is not fast, because PCRE has to search a structure that contains data for over fifteen thousand characters. That is why the traditional escape sequences such as \d and \w do not use Unicode properties in PCRE

То есть «\d» (цифры), «\w» (буквы) и, кстати, «\b» (граница слова) и «\s» (пробельные символы) работают только с однобайтовыми кодировками. Ужасно? Не то слово! Всё потеряно? К счастью, нет.

Вообще-то в PCRE есть специальные последовательности для различных классов Unicode-символов, например, «\p{L}» — это буквы, «\p{N}» — цифры и так далее. Можно заменить все не-Unicode последовательности этими аналогами. Но и это достаточно тяжело, особенно на тех объёмах, с которыми я имею дело. Простым поиском с заменой не обойтись — «[\w\s]» должен раскрываться уже иначе, не так же как «(\w|\s)».

Если внимательно читать документацию по PCRE, то найдётся много интересного, в том числе решение и этой проблемы. В одной из версий этой библиотеки появилась экспериментальная конструкция, называемая «глаголом» (VERB), «глаголы» умеют очень многое, но нас интересует специфический «глагол» «UCP», который (ура) занимается тем, что переключает «\w», «\s», «\d» и «\b» в полностью юникодный режим.

То есть такой код даст нам ожидаемый результат:

    if (preg_match('/(*UCP)(\w)/iu', 'ПриветN', $m)) {
        var_dump($m);
    }

Победа? Ничего подобного. Этот глагол работает начиная с PCRE 8.10, в самой последней стабильной версии PHP (5.3.3) содержится PCRE 8.02, там этот глагол ещё не поддерживается, я проверял.

Нужная нам версия 8.10 войдёт в PHP 5.3.4. Но, во-первых, её ещё нужно дождаться (пока нет даже кандидата в релизы), во-вторых, 5.3 — это совсем другая ветка, ещё пока недостаточно стабильная, я как-то уже упоминал, что пара попыток перевести кое-какие проекты на PHP 5.3 закончились провалом, причём из-за багов этой версии PHP.

Но не стоит опускать руки, 4-5 лет назад я уже сталкивался с подобной ситуацией и помню, что при компиляции PHP есть возможность указать внешнюю PCRE-библиотеку (ключ «--with-pcre-regex=DIR»), что полностью решает проблему, я вчера проверил.

Подведём итоги. Для перевода (большого) проекта на UTF-8 необходимо найти все функции, которые обращаются к строкам, заменить их на Unicode-аналоги (если они есть в модуле Multibyte String, то оттуда, если их там нет — на аналоги, написанные на PHP), функции implode, explode, str_replace, strtok, strtr (возможно, какие-то ещё) в аналогах не нуждаются, операции $str[$index] заменить на функцию, которая умеет работать и с Unicode-строками и с массивами, вкомпилить в PHP PCRE версии 8.10 и в регулярных выражениях добавить ключ «u» и «глагол» «UCP».

Ну а так же не забыть про внешние источники данных — перевести базу на UTF-8, сконвертировать шаблоны, комментарии в коде и тому подобные места.

Ссылки Артемия Трегубенко о веб-разработке за сентябрь 2010

Me, on Twitter: The Web for me is still URLs and…

маленький плюс html 5 здесь и сейчас

State of mobile web development, part 3/3: the mobile industry’s failings

Web developers, web developers, web developers

Fiercely independent

Contests

SDKs

Browser detects

Just say no

Conclusion

Алексей Капранов: Using CDN Hosted jQuery with a Local Fall-back Copy - Jon Galloway

Алгоритмы / Как работают алгоритмы сортировки

Поддержка OAuth 2.0 в Mail.ru

отладка user javascript

Rethinking the mobile web

правильные имена полей для формы оплаты кредиткой

RSI — как бороться с туннельным синдромом

PHP и UTF-8

Некоторые программисты стыдятся знания PHP

Web-разработка / Сообщаем о ремонтных работах на сервере