Веб-разработка *

1. Верстка, аутсорсинг и технические задания

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

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

Сегодня мне кинули ссылку на прикольный сервис для быстрого генерирования изображений-заглушек. Может пригодиться для html-верстки. На мой взгляд, это удобно тем, кто и так использует заглушки — экономит время при вёрстке, т.к. сами заглушки уже готовы. Можно цвета/размеры подбирать, меняя только числа/буквы в коде, не отвлекаясь на сам файл картинки — и сразу видеть эффект. И сами размеры видеть написанными, если нужно, чтоб к коду не возвращаться для проверки. Или вместо размеров можно текст добавить, чтоб всегда знать, для чего эта заглушка (типа «Бан(н)ер» или там «Лого», или «Фотография»).

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

<img src="http://placehold.it/350x50" />

и получаете:


Update. Благодаря усилиям k0rv1n, найден вариант этого сервиса, только лучше :)
Во-первых, там поддерживается кириллица. Во-вторых, там даны ссылки на исходники для разных языков.
Автор dummyimage.com — тот же Russell Heimlich, что и у placehold.it. У placehold.it есть ещё один автор, но будем считать, что он делал дизайн (дизайн там правда круче, но видимо как раз из-за понтового шрифта Unicode и не выходил).

Примеры (см. под хабракатом) я поменял с placehold.it на dummyimage.com, раз уж он функциональнее…

Если вы полагаете, что масштабируемость Вашего нового, web приложения — это основное на чем Вам надо сосредоточиться,… подумайте дважды. Можно с уверенностью утверждать, что в обозримом будущем массового нашествия пользователей не ожидается. Вместо этого этого следует готовиться к медленному увеличению количества посетителей, с возможным пиком увеличения их числа (прим. переводчика: хабраэффект например). Но сосредотачиваться на архитектуре и масштабируемости Вашего приложения до миллионов пользователей — не очень хорошая идея. Миллионы это много. Скорее следует приготовиться к борьбе за первую тысячу пользователей. Возможно даже меньше, если Ваш сервис платный.

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



В этой заметке я хотел бы поговорить о создании простого эмулятора игровой платформы CHIP-8 из далеких 70-х. Во-первых, мы прикоснемся к истории, а во-вторых, эта платформа из за своей простоты позволит создать полностью функциональный эмулятор даже начинающим программистам.

Интерес к холсту (<canvas>), а равно и к мобильным приложениям, приводит к возрождению прежней художественной школы восьмибитных изображений. Joe Huckaby из Effect Games поигрался с зацикливанием цвета, что привело к несколько ошеломляющим результатам.

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

Здесь также происходит искусная оптимизация — вместо того, чтобы очищать и перерисовывать всю сцену в каждом кадре, Джо обновляет только те пикселы, которые изменяются:

Чтобы достигнуть во браузере быстрой смены кадров, мне пришлось устроить слегка безумную оптимизацию движка. Отображение картинки 640×480 с индексированным цветом на тридцатидвухбитном RGB-холсте означало бы обход и прорисовку 307200 пикселов в каждом кадре джаваскриптом. Это обход обширного массива, так что некоторые браузеры просто не в состоянии справиться с этим. Я преодолел их медлительность предварительной обработкою изображений, когда они впервые загружаются, и сбором тех пикселов, которые ссылаются на анимируемые цвета (то есть на цвета, входящие в зацикливаемые подмножества палитры). Координаты этих пикселов хранятся в отдельном (меньшем) массиве, и оттого одни только изменяемые пикселы обновляются на экране. Этот финт оптимизации сработал настолько превосходно, что анимация действительно крутится на весьма неплохой скорости в моём iPhone 3GS и iPad!

Добрый день.
Недавно одни из наших заказчиков выразили желание получать дополнительную информацию о посетителях своего сайта, конкретнее — о людях, заполнивших контактную форму. Это крупная европейская компания и им хотелось бы «фильтровать» своих потенциальных клиентов. Поясню на примере — допустим, решают они организовать выставку своего оборудования в Венгрии и им нужно решить, кто из венгров, оставлявших им свои контакты, скорее всего стоящий клиент, а кто «мимо проходил».
Основными показателями «надежности» клиента для нас стали: число посещений сайта, время проведенное на сайте, количество просмотренных страниц. Всю эту информацию мы получили из Google Analytics Cookies.

Что же из себя представляют печеньки от Google?

Это история личного опыта, опыта поиска бага в чужом, старом, неподдерживаемом коде.
Все начиналось как обычно, передо мной стояла простая на первый взгляд задача: сделать упаковку файлов в текущей папке в ZIP архив с определенным паролем на C++/Qt, казалось бы что может быть проще?
Естественно, первый помощник это Google, он и подсказал что существует две Qt библиотеки для работы с ZIP архивами:
QuaZIP и OSDab ZIP, помимо всего, сам Qt поддерживает методы qCompress и qDecompress для упаковки.
Мною было выяснено что методы мне мало подходят, потому что они умеют лишь жать поток, все заголовки и шифрование на совести разработчика. Этот путь был слишком долог и от него я отказался сразу и обратил свое внимание на библиотеки.
OSDaB ZIP пришлось отбросить сразу, не смотря на то, что это отличная библиотека, ее код распространяется только под лицензией GPL, мне же нужно было встроить функционал в проприетарное приложение. К счастью QuaZIP оказался с двумя лицензиями GPL и LGPL. На нем я и остановился. Особо не вникая в его устройство, я набросал простейший класс для работы ним и начал тестировать.

Введение

Хочу рассказать об одной интересной задаче, которая возникла передо мной и моим коллегой в университете. Хоть сейчас и лето, но жизнь там не угасает ни на минуту. Все суетятся, обрабатывают документы, подсчитывают абитуриентов, если все обобщать – сезон поступления в ВУЗы. Учусь я на техническом факультете университета, причем, учусь неплохо, поэтому нам предложили написание электронной очереди для поступления абитуриентов. Не долго думая, я и мой коллега (и по группе и по работе) согласились. Причиной не желания воспользоваться уже какими-то готовыми продуктами для университета стала заоблачная цена данных разработок, которая составляла порядка 300т.р. Может и не много, но для нашего города цена высокая, наверное, поэтому и решили привлечь студентов своего университета, ко всему прочему это ещё и неплохой опыт работы в данной отрасли.

Программисты с Etsy.com поделились опытом, как им удалось эффективно решить задачу по пакетному ресайзингу фотографий с 1,5 МБ до 3 КБ (после смены дизайна оказалось, что старые превью-окошки не вписываются в новые шаблоны страниц). Задача не такая банальная, как кажется. Дело в том, что Etsy.com — крупный интернет-аукцион, и количество изображений различных товаров превышает 135 млн штук.

Ради шутки они прикинули, сколько займёт эта работа вручную в «Фотошопе». Если на каждую фотографию отдать по 40 секунд, то выходит 170 лет непрерывного труда. Затем они начали считать, можно ли отдать пакет в облако EC2 и во сколько это встанет. Посмотрев на получившуюся сумму, программисты решили поискать другой способ.

В итоге им удалось завершить обработку 135 млн фотографий всего за 9 дней, задействуя четыре 16-ядерных сервера. Средняя скорость обработки составила 180 изображений в секунду.

Начиная разработчиком на тогда еще сверх продвинутом IDE от компании Borland, bc++ 3.11, работающая в операционной системе DOS, в которой тогда единственное, чего не хватало — так это поддержки dos4gw (который вышел, если мне не изменяет память, парой годами позже), я любил эту IDE и мне казалось, что на ней можно сделать все что угодно. Была куча драйверов, которые писались энтузиастами, меняющие шрифты консоли, кодировку, была целая система работы с памятью… Прорывом были отгружаемые динамически библиотеки на диск, созданные чтобы вмесить все в память. Сегменты (ну, современные программисты, что такое сегменты оперативной памяти, и откуда 640К?), нижняя память, верхняя память… 640 килобайт… Люди придумывали все новые задачи компьютерам, а гении своего дела эти компьютеры придумывали. И ведь на самом-то деле это не так давно было… Это было почти вчера.

С завидной периодичностью в блоге разработчиков браузера Опера появляются сообщения, что Опера не может распарсить ту или иную страницу и пользователь видит примерно такую ошибку:



Эффект можно посмотреть по любой из этих ссылок. При этом, в других популярных браузерах страницы отображаются нормально, так же как и в Опере, если попросить распарсить документ как HTML, а не как XML (ссылка «Reparse document as HTML»).

Собственно, сам код

В последнее время Вы, наверное, много слышали о том, что Flash является умирающей технологией и о том, как она будет вскоре заменена на HTML5. Лично я считаю, что HTML5 будет постепенно заменять Flash лишь для некоторых вещей, но Flash всегда будет иметь место, особенно при разработке сложных игр и насыщенных интернет-приложений. Если вы еще не видите, что можно сделать с помощью HTML5, я ограничусь десятью примерами, чтобы показать некоторые из возможностей HTML5.



Так что же вы думаете – HTML5 заменит Flash?

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

Египетские операторные скобки

if (a == b) {<br>  printf("hello");<br>}<br><br>

В мире визуальных редакторов есть CKeditor, есть tinyMCE — монстрообразные, не гибкие, их сложно изменять под задачи сайтов и интерфейсов. Есть небольшие, простые, они часто с ужасным дизайном, не развиваются, не поддерживаются. Как настоящий разработчик, несколько лет назад я решил написать свой редактор и в течение этого времени постоянно развивал его и упрощал. Суть редактора постепенно свелась к простым требованиям:

• он должен быть красивым и одновременно ненавязчивым, чтобы вписывался без внешних изменений почти в любой интерфейс;
• обязательно быстрым и легкий, потому что никому не нравится сидеть даже полминуты в ожидании загрузки всех кнопок и плагинов;
• гибкий для разработки, доработки и встраивания под все возможные нужды;
• с простым и понятным интерфейсом. В идеале визуальный редактор — это просто поле для ввода текстов, без лишних кнопок и функций. Просто люди пишут тексты в вебе и это все что им нужно.

У веб-программистов со временем вырабатываются привычки, которые въедаются в рабочий процесс на уровне рефлексов. Взять хотя бы данные из формы — каждый толковый программист, как только встречает их, тут же обрабатывает на предмет корректности. Порою даже сам не замечает.

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

Количество элементов на одной странице

Разбиваете список на страницы? Как будет выглядеть вторая страница для списка из 101 элемента, если ваше волшебное число 100?

Недавно по наследству от грязного, вонючего контрактора (который утверждал, что его знания и умения так хороши, чтоб не трогать его пока, он не закончит проект) мне досталось веб-приложение. К сожалению, мы поверили ему на слово. На первый взгляд большинство функционала веб-приложения работало как надо. Однако, как только клиент начал использовать приложение в реальных условиях, – весна показала, кто где срал оно начало барахлить. Контрактор исчез после оплаты (умри репутация!), а я остался, чтобы попытаться починить то, с чем пока мучился клиент.
Я решил описать некоторые из тех ошибок, с которыми столкнулся. Это ошибки, которые, каждый хороший программист давно уже должен уметь избегать… но, очевидно, что некоторым людям нужно о них напоминанать.

Google Font API — API для подключеня нестандартных шрифтов.

<html>
  <head>
    <link rel="stylesheet" type="text/css" href="_http://fonts.googleapis.com/css?family=Tangerine">
    <style>
      body {
        font-family: 'Tangerine', serif;
        font-size: 48px;
      }
    </style>
  </head>
  <body>
    <h1>Making the Web Beautiful!</h1>
  </body>
</html>

Кажется войне Theora против H.264 пришёл конец. В битве между свободным и лучшим победило свободное и лучшее.

Как мы помним, Google недавно купила компанию On2. Это компания известна не только тем, что открыла VP3, который лёг к основу свободного кодека Theora, но и тем, что создала отличный видео-кодек VP8 который вполне может потягаться с текущим лидером H.264. Компании Google (как и многим другим) очень не выгодна война кодеков вокруг тега <video> в HTML5. Поэтому как только On2 была куплена сразу начали говорить, что VP8 скоро откроют, что и произошло недавно (лицензия BSD).

Однако VP8 — это только видео-код. Чтобы смотреть фильм, нужно ещё кодировать звук и собрать все потоки данных в один файл. Поэтому был предложен набор WebM: Vorbis в качестве аудио-кодека (известен некоторым под неправильным названием Ogg) и Matroska в качестве контейнера (известен из раздач торрентов, обладает кучей функций и основан на бинарном XML).

Конечно же новый стандарт не захватит мир сразу — он ещё в статусе dev preview, надо добавить поддержку в браузеры, на сайты и в чипы мобильных устройств. Поддержка уже есть в ночных сборках Firefox, Chromium, Opera и ffmpeg. А YouTube уже отдаёт видео в WebM (нужно включить HTML5 и добавить &webm=1 в URL) и наверняка на него перейдёт Википедия, потому что он свободный. Процесс пошёл и победа WebM — лишь вопрос времени.

Адрес проекта: webmproject.org.

В мире существуют тысячи CMS для самых разных целей, самого разного качества, самой разной перспективы, стоимости, распространённости и так далее. Серьёзно опробовать их все — нереально. Поэтому когда я только знакомился с миром движков для сайтов, выбирать приходилось наугад. Ниже я опишу свои впечатления от знакомства с теми или иными движками для тех или иных целей. К некоторым приложу краткое описание особенностей, впечатление о прочих состоит только из заглядывания в админку. Заметки эти составлялись и редактировались в течении долгого времени, но сейчас я решил, что лучше опубликовать их в нынешнем виде, чем ещё полгода-год по чуть-чуть редактировать не добавляя ничего принципиально нового.
Преимущество отдаётся бесплатным движкам. Платные будут рассматриваться только для сравнения или от безысходности, т.е. если нет бесплатных аналогов. Также ограничение на технологии: php. О движках на перле и питоне я не более чем слышал, на шарпе и джаве имел дело с самописными.
Итак, рассматриваются

• CMS общего назначения. Информационные сайты, визитки, блоги…
• Многофункциональные монстры.
• Галереи.
• Социальные сети.
• Форумы.
• Интернет-магазины.