Category: it

Из Facebook

Пропустил очередной выпуск YCombinator, смотрю на их проекты только сейчас, через месяц после демодня. Будущих единорогов пока не видно, но остроумные идеи есть. #стартапдня #1 Roofr – маркетплейс мастеров по починке крыш. Его фишка – использование спутниковых фотографий и основанная на них автоматическая оценка стоимости ремонта. Очевидно, что в основном это фейк, 99% проблем спутник увидеть не может, но зато вау-эффект, сарафанное радио о таком сервисе будет работать. #стартапдня #2 D-ID накладывает фильтры на фотографии лиц так, чтобы человек не замечал разницы, а алгоритмы распознавания сбоили. Цель – помешать злоумышленникам обмануть системы биометрической авторизации с помощью публичных фото. #стартапдня #3 PullRequest это маркетплейс для code-review. Суперквалифицированные программисты из Google или Facebook, которым скучно на рабочем месте, регистрируются в системе и в свободное время просматривают код менее экспертных коллег из других компаний. Да, всё, что требует знания проекта, таким способом не поймать, но наивные ошибки ловятся, довольные клиенты на такое ревью есть, выручка тоже появилась.
mail

"Психбольница в руках пациентов" Алан Купер

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

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

В качестве серебряной пули предлагается передать основную роль на проекте специальным проектировщикам интерфейсов, которые будут людьми, а не программистами и проектировать будут для ожидаемых клиентов, а не для себя. Дальше следует адрес и телефон конторы автора книги и расценки на её услуги.

К серебряной пуле, конечно, возникает масса вопросов. Во-первых, эмоционально, я, разумеется, не готов отдать контроль. Во-вторых, книга достаточно старая, большинство прогнозов автора не сбылось (сбылся только один, он верил в успех Apple), значит что-то не так. В-третьих, даже если хочется попробовать, то где ж их взять, этих спасителей (ну кроме как в конторе автора)? Ну и конечно игнорирование потребностей всех кроме гипотетических проектировщиков - фашизм ничем не хуже, чем нынешний фашизм программистов.

Но даже если не принимать предлагаемое решение, то умных мыслей высказано довольно много и прочесть их полезно. Я, например, впервые понял, зачем нужны персонажи, "воображаемые пользователи", которых всю жизнь считал бессмысленной тратой времени. Самоочевидна, но нуждается в произнесении вслух фраза о том, что пользователей интересуют стандартные ситуации, а программиста - исключительные. При том, что даже одна мысль на книгу - это неплохой результат, а я перечислил не всё, Купер рекомендуется к прочтению любому, хоть как-то связанному с разработкой или IT.
pochta.ru

экипаж корабля прощается с вами

QIP.ru и Почта.ru подружились. Пока процентов на 20, но на днях подружатся окончательно. Я уже писал подобный текст на тему newmail'а, и повторяться абзац в абзац глупо, но, блин, не каждый день закрываются проекты с десятилетней историей, а чувства примерно те же.

gornal@pisem.net/gornal@mailru.com (тогда они были алиасами и давались в паре) - не помню.

Зато помню радость от того, как мы у них отобрали домен mailru.com, и презрение к тому, как они глупо отреагировали. (А вот как сами домен этот проэтосамили - не помню. Но, кажется, при мне. Хотя виноват точно был не я, это бы запомнил. И вообще я в доменах традиционно не виноват :-) ).

Ещё в те же времена был клевый и гордый баннер на тему роста почтового ящика у "обычной почтовой службы". Завидовал. Сейчас найти, наверное, вполне реально, только какой смысл?

Чуть позже были волны спама про mail15.com. Действительно, круто, даже мне запомнились, при всем моем профессионально-невнимательном отношении.

Ребрендинги в hotbox и в pochta.ru я пропустил, даже годы не назову сейчас точно. Но нынешняя "дружба" это не очередной ребрендинг, проект перестал быть самостоятельным.

Потом после паузы безумное интервью Семакина, вроде бы единственное Рунет-интервью, которое я в блоге комментировал.
Ну а совсем потом - я то продюсер, то не продюсер, то опять продюсер. А оно несмотря на все эти фокусы - продолжает работать.

На данный момент я участвовал в редиректе *.list.ru (но не сам list), vspomni.ru, newmail и pochta.ru, не считая мелочи типа kards.ru, mos2.ru, blogi.ru и blogonline.ru - на фоне первых они явно не смотрятся. А самым трогательным был какой-то чат на одном из мейлрушных проектов (не chat.mail.ru, что-то мелкое типа bk.ru/chat), я его закрывал прямо в прямом эфире. Вот Мохнатик (или Пушистик? или Махнусик? склероз....) что-то написал, а вот ему ответить уже не смогли и никогда не смогут. 301.

Ну и да, мне понадобилось чуть больше трех лет, чтобы убить проект, на который меня взяли на работу и которому я обещал мировое господство :-)
дятел

Ваши телепаты в отпуске? Тогда мы идем к Вам!

Есть IT-среде такое расхожее выражение - "телепаты в отпуске", которое многие любят и едва ли не бравируют регулярным его использованием.

(Это была его коронная фраза. В каждом споре со своим собеседником он с
замиранием сердца ждал именно такого момента, чтобы сказать: "Вот тут-то
вы и ошибаетесь!"
)

Формально это предложение означает: "ты/Вы сформулировал(и) задачу/проблему недостаточно подробно, уточни(те)" и выглядит достаточно невинным, но обычно есть одна маленькая и на первый взгляд незаметная деталь.

(Был советский студент Мэлс, теперь перед нами стиляга Мэл. Казалось бы, всего одна буква. Правда, товарищи, такая малость?)

По сути, а не по букве, апелляция к телепатам обычно означает желание IT-специалиста, чтобы с ним говорили на его, специальном языке, а не на языке нормальных людей. И это, безусловно, плохо. С одной стороны, плохо для дела: понятно, что перевод с обычного на технический проще осуществить технарю (которые знает оба языка), чем не технарю (который тем и отличается, что знает только один). С другой стороны, плохо для самого айтишника - ведь по сути именно в переводе и заключается его работа, любую сформулированную на техническом языке задачу может решить (хорошо, хорошо, через 5 лет сможет решить) и компьютер, а наш герой окажется никому не нужен.

(Употребляющие эту или подобные словесные конструкции не догадываются о том, что Родину спасут вовсе не массовые расстрелы, а показательные.)
pochta.ru

Веб-технологии для чайников - 3. Серверные языки программирования.

Заранее признателен за комментарии, оценки и поправки (с учетом, что целевая аудитория - чайники).

Если всем пользователям при любых обстоятельствах требуется показывать одно и тоже, то соответствующий файл можно просто положить на сервер, но обычно этого недостаточно и хочется какого-то разнообразия. В таком случае на сервере нужно запустить программу, которая будет создавать HTML-текст необходимый в данном конкретном случае. Написание этих «серверных» программ (скриптов) и есть в общем-то основное дело веб-разработки, именно в них обычно скрывается 90% сложности и стоимости любого проекта. Т. к. программа выполняется на нашем сервере, а не на компьютере пользователя, то выбор инструментария полностью за нами и нет какого-то одного языка, на котором такие программы пишутся.

Первое и самое принципиальное решение, которое следует принять — операционная система нашего сервера. Теоретически это может быть что угодно, на практике в России в 93% случаев используют Unix, в 6.99% - Windows, в 0.01% - что-то иное. Я не совсем объективен, но не вижу ни одного аргумента в пользу Windows и два в пользу Unix, соответственно рекомендую всегда выбирать его. Аргумент первый: то, что более распространено, всегда удобнее, проще найти хостинг, проще найти специалиста, проще найти готовое решение какой-то подзадачи. Аргумент второй: стоимость лицензий на Windows/MS SQL/...; деньги там не запредельные, но всё же отличные от нуля. Если в качестве ОС мы выбрали Unix, то следующий естественный вопрос — какую его реализацию использовать — абсолютно незначителен и может быть решен исходя из личных предпочтений системного администратора.

Второе принципиальное решение — язык программирования. Выбор тут достаточно велик. Во-первых, есть целый класс языков, идеально подходящих для типичных задач web-программирования (а один из них специально для него и придуман) - "скриптовые языки". Сейчас это как минимум PHP, Perl, Ruby и Python. Именно на них написано подавляющее большинство сайтов от простейших интернет-магазинов до vkontakte.ru, например. По возможностям, удобству, производительности, средствам разработки, каким-то другим теоретическим показателям они примерно равны между собой, основная разница в наличии программистов. Прямо сейчас замеренные показатели рынка таковы: на 100 резюме PHP-программистов в России приходится 10 Perl и по 2-3 Ruby и Python-резюме. С другой стороны, из всех людей, которые называют себя PHP-программистами, к коду на пушечный выстрел нельзя подпускать 80%, для перловиков этот показатель в районе половины, а для Ruby и Python и того меньше. Понятно, что первые цифры объективны и взяты с рабочих сайтов, а вторые условная субъективная оценка и прямо перемножать их нельзя, но в любом случае, количество и программистов, и хороших программистов упорядочено именно в таком порядке: PHP, Perl, Ruby или Python, а средний их уровень в прямо противоположном. Таким образом, если у нас промышленный проект, с большим количеством разработчиков и текучкой кадров, то из Web-языков выбирать нужно PHP (допустимо использование Perl в случае каких-то очень важных локальных причин). Если же проект короткий, программист точно будет один и не будет меняться никогда, то выбор можно доверить ему, при этом выбор Ruby/Python может даже оказаться оптимистичным фактором.

Кроме рассмотренных близнецов-братьев скриптовых языков (выбор между которыми чисто социальный), есть языки и другие, имеющие другие технические характеристики и соответственно другие ниши для применения.

Язык C. Язык, требующий максимальной аккуратности программиста, наиболее сложный в поиске ошибок, с наименьшим количеством доступных готовых решений и с самой низкой скоростью разработки. Все эти минусы он компенсирует только одним плюсом: производительностью, которая на несколько порядков лучше производительности PHP и его аналогов. В принципе, железо сейчас дешевое, а рабочая сила дорогая, плюс этот важен достаточно редко. Условно, если в проекте предполагается менее миллиона показов в сутки, то про C можно забыть смело, но, если показов больше, о нем следует только думать, а не принимать безоговорчно. На C написан, например, счетчик liveinternet.ru.

Язык С++. Обладает всеми теми же недостатками, что и С, но в менее явной форме, взамен дает соизмеримую, но меньшую производительность. Обычно применяется там, где производительность всё же требуется, а бизнес-логика очень сложна и находится на грани научности. Классический пример — поисковые сервисы. Важный недостаток, не дающий ему полностью вытеснить С на его нише, это большая свобода для неподдерживаемого кода. Как и в случае табличной верстки, на С все пишут примерно одинаково, и если код удовлетворяет формальным и проверяемым требованиям качества (не допускает утечки памяти, корректно обрабатывает ошибки и т. п.), то он скорее всего будет на вполне приемлемом уровне и по неформализуемым, но важным характеристикам типа «понятности» и «связности». А вот на C++ можно соблюдая все формальные требования написать, как великолепно, так и отвратительно. И естественно второе встречается чаще.

Язык Java. С технической точки зрения отличается от C++ примерно так же, как C++ отличается от C. Т. е. переход от C++ на Java это потеря ещё половины порядка производительности, но новый выигрыш в скорости разработки и библиотека готовых решений уже соизмерима со скриптовыми языками. С точки зрения социальной, количество программистов на Java меньше и количества программистов на C++, и количества программистов на PHP, при этом они в среднем дороже и, на мой субъективный взгляд, в среднем хуже тех и других. Причина такого странного расклада — в довольно большом рынке Java-разработки корпоративных систем, который с одной стороны поднимает зарплаты, а с другой прививает свою культуру и подход к программированию, который только вреден в вебе. В итоге, я не вижу ни одной ситуации, когда применение Java в веб-разработке было бы обосновано. (Но тем не менее odnoklassniki.ru написаны именно на Java и успешно работают.)

Если мы успели совершить ошибку и выбрали в качестве операционной системы Windows, то кроме перечисленных языков (все они в принципе больше ориентированы на Unix, но могут быть использованы везде) появляются ещё два варианта: это VBScript (некий аналог PHP) и C# (аналог Java). Т. к. я не вижу выигрыша от Windows, то и их рекомендовать не могу.

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

Все существующие (по крайней мере все популярные) инструменты универсальны. На каждом из них можно реализовать абсолютно всё что угодно, вопрос только в том, что с некоторыми инструментами это будет быстрее и дешевле, а с другими дороже и медленнее. В принципе, никто не запрещает использовать в одном проекте два разных серверных языка, но обычно это приводит к ухудшению управляемости проекта — мы зависим от двух специалистов (или двух групп специалистов) вместо одного, которые кроме собственно проектной работы должны тратить усилия на согласование как чисто социальное (общение между собой), так и техническое. Единственное оправдывающее себя исключение это связка одного из скриптовых языков с кем-то из пары C/C++. «Поверхностная» часть кода, отвечающая за интерфейс, пишется на скриптовом, а наиболее критичная к производительности внутренняя — на С или С++. При этом соотношение между частями в разных проектах может быть совершенно разным. Например, ulov-umov.ru представляет из себя очень алгоритмически сложный C++ проект, реализующий по сути собственную поисковую систему и небольшую Perl-обертку, рисующую пользовательский интерфейс из буквально 10 страниц. А внутри полностью PHP-шного readme.ru есть один маленький C-шный модуль, который по готовым данным быстро-быстро рисует информеры. Важно, что производительный язык всегда «внутри», а уж какую долю от объёма он занимает — зависит от локальных факторов.
pochta.ru

Веб-технологии для чайников - 2. Javascript.

Буду очень благодарен за комментарии, оценки и поправки, но помним, что всё для чайников.

Принципиально важным расширением HTML является язык программирования Javascript. Программа («скрипт») на этом языке записывается прямо в тексте HTML-страницы и исполняется в момент её просмотра. Javascript — полноценный язык программирования, позволяющий производить разнообразные вычисления, обработку данных. Типичным результатом javascript-программ является модификация HTML-страницы, на которой он расположен.

Происходить исполнение программы может как сразу после загрузки, так и после каких-то действий пользователя. Первый способ используют, например, некоторые счетчики посещаемости типа liveinternet.ru. Их код, добавляемый в каждую страницу, которая должна обсчитываться счетчиком, представляет из себя маленькую javascript-программу, исполняемую сразу после загрузки. Программа эта вставляет в страницу картинку с сервера счетчика, и добавляет в адрес дополнительную информацию, которая должна быть учтена статистикой счетчика (например, разрешение экрана).
Типичный javascript-код, реагирующий на действие пользователя — кнопка «выделить всё» рядом с любым списком чего-нибудь на множестве сайтов. При нажатии на неё исполняется javascript-программа, которая собственно и ставит галочки выделения на всех элементах.

Очень важно понимать, что программа на javascript выполняется внутри браузера. Т. е. доступная ей информация, которую она может использовать — это информация, известная браузеру, а возможные действия происходят внутри браузера. Javascript-программа «знает»
содержимое этой страницы, действия пользователя на этой странице (что он нажал, куда двинул мышку, сколько времени «сидит» на этой странице), часть общей информации о компьютере пользователя (операционную систему, браузер, некоторые настройки браузера).
Но она не «знает» и не может использовать данные сервера (кроме тех, которые были заранее вставлены в страницу). Кроме того, из соображений безопасности, ей закрыта большая часть информации о компьютере, которая по идее могла бы быть открыта (доступ к локальным файлам или к большинству настроек операционки, например). «Сделать» javascript-программа может практически любое изменение своей HTML-страницы, плюс небольшой набор эффектов за пределами страницы: системное предупреждение, открытие или закрытие нового окна браузера, переход на новый адрес,...

Раз Javascript выполняется в браузерах, то в точности как и в случае с HTML, в каждом браузере он это делает чуть-чуть по-разному, и каждый браузер нужно поддерживать чуть-чуть отдельно. При этом, лично мне кажется, что размер этого «чуть-чуть» у Javascript'а больше, чем у HTML, и каждый новый браузер дается Javascript'еру дороже, чем верстальщику.

Ещё раз подчеркну, что HTML и Javascript это две разные технологии, а верстальщик и javascript-программист это в общем случае два разных человека. Да, минимальные знания (на уровне «выделить всё») javascript'а для верстальщика практически обязательны, а javascript'ер обязан знать базу HTML, но в обоих случаях речь идет о минимуме, а не о полных профессиональных знаниях. При этом каждый из них, если и сможет сделать чужую работу, то обычно хуже и медленнее, чем узкий специалист, а программисту к тому же это часто будет «в падлу».

Поддержку javascript пользователь теоретически может отключить. На практике на персоналках так делает крайне малое количество людей, но нельзя забывать про мобильники, где он крайне урезан.
pochta.ru

Веб-технологии для чайников - 1. HTML и CSS.

Комментарии, оценки, поправки приветствуются, но помним, что для чайников.

Любая страница любого сайта с точки зрения браузера это некий текст, в который кроме собственно текста включены специальные управляющие слова (теги), указывающие как именно должен выглядеть текст — что подчеркнуть, что выделить жирным, что является ссылкой, и куда какую картинку добавить. Язык этих тегов называется HTML (HyperText Markup Language). Пример HTML, как это выглядит в коде:

<b>Qip.Infium</b> — самый <u><i>удобный</i></u> мультипротокольный <b>Интернет-мессенджер</b> с поддержкой ICQ, М-Агента и Jabber'а.

Как это выглядит в браузере:

Qip.Infium — самый удобный мультипротокольный Интернет-мессенджер с поддержкой ICQ, М-Агента и Jabber'а.

Естественно это максимально простой пример, в жизни всё куда сложнее, но общую логику он отражает верно. Что важно понимать и помнить про HTML, очень кратко и тезисно.

HTML это достаточно мощный язык, с его помощью профессиональный верстальщик может создать практически любую картинку, удовлетворив практически любые требования. Но при этом, чем ближе требуемая картинка к квадратно-гнездовой структуре, тем проще будет её реализовать, а значит работа будет выполнена качественнее и быстрее.

HTML сам по себе ничего не делает, он отображается в браузерах. Каждый браузер имеет какие-то свои особенности и работает чуть-чуть по-разному, учет особенностей и даже проверка результата в каждом из них — это дополнительная работа, которая будет (или не будет) делаться за счет чего-то другого. В данный момент существенную (>5%) долю в России имеют 5 браузеров (IE 6, IE 7, FF3, Opera 9, Opera Mini), причем Opera Mini — браузер мобильников, т. е. отличается от остальных гораздо сильнее, чем они между собой.

Кроме браузера и его версии важным внешним фактором, влияющим на отображение страницы, является размер окна, в котором она открыта. Я не встречал соответствующих исследований, но обычно неявно предполагается, что подавляющее большинство пользователей запускают браузер в режиме «на весь экран» и размер окна определяется разрешением монитора. Популярные варианты сейчас — 1024x768, 1280x1024, 1280x800 — втроем занимают 75% рынка. Меньше 1024 по горизонтали только мобильники (но забывать про них сейчас уже нельзя) и совершенно раритетные 800x600 (а вот про них можно и забыть). Естественно, как и в случае с браузерами, чем больше разных разрешений полноценно поддерживаются, тем это сложнее и дороже.

HTML это язык отображения и не более того! В нем нет логики, обработки данных, ещё какого-то анализа. Простейший, иллюстрирующий мысль, пример: пусть на странице указывается имя пользователя, и если это имя оказывается длинным, то оно не влезает в отведенное ему место, начинаются лишние переносы или другие искажения. Верстальщик НЕ может сделать так, чтобы длина имени была фиксирована, а последние символы при необходимости сокращались до многоточия . Это может сделать только программист (серверный или js).


В применении к верстке, часто приходится слышать слово CSS (Cascade Style Sheets). В практическом смысле проще всего считать, что это отдельное название для одного из разделов языка HTML. Да, теоретически это разные вещи, но практически применяются они только в связке, специалист всегда должен знать как то, так и другое, никаких промежуточных результатов, использующих что-то одно, не существует. В общем, не погружаясь в глубокую теорию разделить их невозможно, так что это и не нужно.

Важные решения о верстке, которые приходится принимать менеджеру, а не специалисту распадаются на два типа: решения, касающиеся требований, и одно-единственное, касающиеся реализации. Начнем с требований.

1. Список и степень поддержки браузеров. Классическая дилемма цены и качества. Лично я считаю, что рациональная позиция для сайтов общего назначения сейчас такая: идеальная поддержка IE6, IE7, FF3, Opera 9, и посматривать, чтобы работали основные функции в Opera Mini, последнем Chrome, последнем Safari и FF2.

2. Поддерживаемые разрешения. Сейчас общепринято делать идеальные сайты под 1024 и 1280, которые могут хуже смотреться под большими разрешениями (появляется пустое место) и совсем плохо под 800x600 (появляется скроллинг). Opera Mini на мобильных при этом занимается адаптацией верстки за нас.

3. Устойчивость к нестандартным пользовательским настройкам. Должен ли сайт быть красивым и нормально работать при отключенном показе картинок? А при увеличенных или уменьшенных шрифтах? Тут опять чистый вопрос цены, естественно дополнительная поддержка стоит дополнительной работы. Надежной статистики настроек я не встречал, обычно предполагается, что с ними играются единицы процентов пользователей.

4. Фиксированный или «резиновый» дизайн. Должен ли при увеличении размера окна сайт оставаться фиксированной ширины, и висеть в центре экрана с расширяющимися полями по бокам или он тоже должен расширяться («резиновый» вариант)? Во втором случае надо так же определиться с тем, какая (или какие) именно колонки сайта будут расширяться. Вопрос скорее эстетический, чем технический, и может быть даже отнесен к дизайну, а не к верстке.

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