Сервис Transloadit.com запустил новую фичу: обработка видеофайла кодеком ffmpeg в процессе его загрузки на сайт. Серверы Transloadit обеспечивают скорость кодирования выше, чем скорость аплоада у большинства пользователей. Таким образом, теперь практически устраняется задержка между загрузкой и публикацией видеоролика.

Фича realtime-кодирования в некоторых случаях увеличивает «скорость кодирования» (то есть время между окончанием загрузки файла и окончанием кодирования) в 150 раз. Как это работает, показано на видео под катом или можно проверить самому в демо-секции на сайте Transloadit.com.

Задержка кодирования — очень неприятная штука. Например, на Youtube она раздражает очень многих пользователей. Хорошо, если ребята опыт коллег с Transloadit переймут разработчики других видеохостингов.

Доброе утро!

Сегодня мы выкладываем предпоследний видеодоклад с Дней HighLoad++ в Mail.Ru:

Юрий Ковалев (Performance Lab) — Нагрузочное тестирование без границ

Часть первая (20: 27): video.mail.ru/corp/miftahetdinova/2/3.html

Часть вторая (23:16): video.mail.ru/corp/miftahetdinova/2/4.html

Хорошего дня!

Продолжаю рассказывать о том, как я ставил на ноги Автотуристу.Ру.
Часть 1, Часть 2.

Глава 7. Цифры нефинансовые
Что ж, обещал в предыдущей части цифры и графики, буду держать своё слово. Сперва хотел бы продемонстрировать динамику роста моего проекта, начиная с первого посетителя и заканчивая 17.12.2010. Не знаю почему, но данные по уникам и просмотрам разительно отличаются в трёх основных (мною используемых) системах сбора статистики о посетителях: Liveinternet, Yandex.Metrica и Google Analytics. Лично я отдаю предпочтение последней по качеству и полноте отчётов, интерфейсу и авторитетности. Также, что, естественно в моих интересах, в GA фиксируется бОльшее кол-во посещений и просмотров страниц, нежели в двух остальных системах. Про Рамблер я промолчу, пожалуй.

Вот как по ГА выглядит обещанная динамика посещений:

Как находить тексты похожие по смыслу? Какие есть алгоритмы для поиска текстов одной тематики? – Вопросы регулярно возникающие на различных программистских форумах. Сегодня я расскажу об одном из подходов, которым активно пользуются поисковые гиганты и который звучит чем-то вроде мантры для SEO aka поисковых оптимизаторов. Этот подход называет латентно-семантический анализ (LSA), он же латентно-семантическое индексирование (LSI)

Добрый день, друзья,

Ниже еще один видеоролик из серии докладов на HighLoad++:

Сегодня это James Golick, с докладом: Scaling to Hundreds of Millions of Requests: What Worked and What Didn't

Часть первая, (22:31): video.mail.ru/mail/akulhot/_myvideo/1.html

Часть вторая, (21:35): video.mail.ru/mail/akulhot/_myvideo/2.html

Часть третья, (22:05): video.mail.ru/mail/akulhot/_myvideo/4.html

Надеемся, что и этот доклад окажется для вас полезным.

Приятного просмотра :)

Еще один видеоролик с HighLoad++:

Константин Осипов (Oracle) говорит о проблемах роста проекта и его команды в докладе MySQL: проблемы роста

Часть первая, (25:03): video.mail.ru/corp/mf/2/3.html

Часть вторая: (25:23): video.mail.ru/corp/mf/2/4.html

Часть третья: (25:38): video.mail.ru/corp/mf/2/5.html

Часть четвертая: (08:13): video.mail.ru/corp/mf/2/6.html

Хороших выходных :)

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

Добрый день,

Готов еще один видеоролик из серии докладов на октябрьском HighLoad++:

Bruce Momjian (PostgreSQL) — Building Global Teams Like Postgres

Часть первая, (31:42): video.mail.ru/corp/morozova/16/27.html

Часть вторая: (27:43): video.mail.ru/corp/morozova/16/28.html

Часть третья: (23:04): video.mail.ru/corp/morozova/16/29.html

Часть четвертая: (23:55): video.mail.ru/corp/morozova/16/30.html

Уже выложенные на Хабр доклады

Хорошего просмотра!

Мы обязательно выложим доклады остальных участников — все будет хорошо:)

Все более-менее сложные программные системы содержат ошибки (если и не собственные, то наведённые используемыми библиотеками или по причине неточного осознания поведенческих парадигм используемых фреймворков).
Часто, для тестирования системы на этапе разработки используются Unit-тесты.

Так программист может контролировать поведение системы на контрольных точках и пограничных значениях.
Часто именно неверная отработка пограничных значений приводит к проблемам. И опытные программисты это знают и учитывают при проектировании Unit-тестов.

Удобство Unit-тестов ещё и в том, что изменяя код вы ожидаете получить предсказуемые результаты и провести полностью автоматическое тестирование по имеющимся сценариям, чтобы быстро выявить наведённые изменениями неприятности.

Например, вы пишите код для работы на Intel и PPC, разрабатываете его на Intel, но учитываете порядок байтов. Потом прогоняете свои Unit-тесты, чтобы сравнить выходные данные с эталоном и обнаруживаете расхождения — понятно, где-то забыли байты перевернуть — исправляете — всё в порядке.

Однако, любой пользователь всегда несёт в себе элемент случайности.

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

Если программа делает больше чем печать «Hello World!», то скрытые ошибки в любом случае остаются.
Это могут быть ошибки и в логике в том числе.

Программа компилируется, все Warning'и устранены… но иногда что-то идёт не так… у пользователя (который живёт далеко в домике на островке в тихом океане — приехать к нему и пощупать нет возможности). Программист прокликал и протестировал со своей стороны всё что мог, но ошибки не нашёл. Что же делать?

Доброго утра, дорогие Хаброчитатели!

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

В этой статье я хочу поделиться скромным микровелосипедом, который помогает мне в нелегком деле сайтостроительства.

Наше первое знокомство с вами оказалось очень интересным, и я искренне признателен вам, за вашу конструктивную критику. Надеюсь продолжить в том же ключе.

Итак, для себя я сформулировал задачу по следующим криетриям:

1) Каждый модуль должен содержать все необходимое для работы в одной папке — и шаблоны, и модель, и контроллер. Дабы его легко можно было скопипастить, подправить — и вуаля — новый модуль.
2) Модуль ничего не должен знать о тех, кто его создает — все необходимые ему для работы данные он получает через конструктор. Это для того, чтобы модуль работал не только на моем сайте, но и на всех сайтах моих друзей и клиентов без всякого допиливания напильником.
3) Для того, чтобы пользоваться модулем его не должно быть нужно где-либо регистрировать или инклудить дополнительные файлы. Это тупо раздражает.
4) Модуль может состоять из модулей. Т.е. должна быть поддержка вложенных модулей.
5) Ссылки (a href=...) внутри шаблонов модулей должны быть относительными, не зависящими от того, на какой глубине вложенности находится модуль. Чтобы банально не править шаблоны, если мы перемещаем модуль из одного родительского модуля в другой.
6) Сам сайт тоже должен быть модулем, раз уж на то пошло. Дабы можно было купить у друга уже рабочий сайт, положить себе в папку и встроить весь его на какую-нибудь страницу без лишних переделок.

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

Обещанное этим летом облако Селектела, в котором оплачиваются только потреблённые ресурсы, наконец-то, готово.

На самом деле мы запустились ещё месяц назад, но решили не устраивать себе хабраэффект, а принимать клиентов по чуть-чуть. Благодаря этому мы смогли внимательно изучить возникающие затруднения и решать проблемы в очень индивидуальном порядке. Стратегия себя окупила, так как за время «полузапуска» нашлась одна неприятная опечатка в шаблоне у одной виртуальной машины, несколько мелких огрехов в интерфейсе. Заодно, спокойно, без предпусковой суматохи, были реализованы дополнительные функции управления виртуальными машинами.

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

Владельцы сайтов против правообладателей

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

На множестве сайтов можно найти контрафактный контент, который в отдельных случаях становится предметом судебных исков. Если его выкладывает сам владелец сайта, то в таких случаях никаких неясностей не возникает. Но вот кто должен отвечать за то, что выложено пользователем? Есть распространенное мнение о том, что «владелец несет полную ответственность за то, что публикуется на его сайте». Как правило, пропагандируют его «профессиональные истцы» и прочие пропагандисты «закручивания гаек» в области копирайта. Однако, в законодательстве и в судебной практике оно подтверждения не находит. В этом мы сейчас и убедимся.

Cегодня мы поговорим о компонентах для высокопроизводительной и масштабируемой архитектуре на основе сервера memcached, а именно — распределённой базе для хранения данных MemcacheDB и системы очередей сообщений MemcacheQ.



Сначала рассмотрим, а что у нас есть в распоряжении для создания распределённой инфраструктуры хранения данных для веб-приложения. Ну, первое, что приходит в голову — кластеризация базы данных, это теперь поддерживается во всех распространённых системах, а также различные технологии репликации. Например, самая популярная СУБД для веб-проектов, MySQL поддерживает как репликации так и кластеризацию. Ещё можно обратится к традиционным файловым система и хранить данные в файловой системе, к примеру, Apache Hadoop. Но часто это слишком высокоуровневое решение, обычно же требуется гораздо проще варианты — когда нужно хранить и оперировать просто парами ключ-значение. Если серьёзно посмотреть, такая функциональность позволит покрыть потребности 90% веб-приложений. А если мы прибавим к этому возможность очень и очень быстро оперировать данными, хранить их в виде распределённой многосерверной системе и возможность постоянного хранения, устойчивого к сбоям — получим очень привлекательную платформу.

Всем привет,

Собираюсь поделиться с вами технической стороной того, как я за 16 недель сделал новый вебовый rss ридер, и чуть не сошел с ума.
Отходя от долгой предыстории, будем считать, что все началось в феврале этого года, когда мы с Дэвидом (dmiloshev, UI-дизайнер) решили сделать прототип нашего детища вдвоем.
«В одиночестве» — потому, что не было никаких скрамов, совещаний, «коллективного разума», а всю техническую часть, довелось делать самому.

Если бы меня попросили описать всю статью в одном предложении, то получилось бы:
No-SQL, mongodb, node.js, фак мой мозг, Evented I/O, очереди, выводы, git, nginx, memcached, Google Reader, Atom, TTL, PHP, ZF, jQuery, выводы.

С проблемой медленной отдачи статического контента рано или поздно сталкивается каждый сисадмин.

Проявляется это приблизительно так: иногда 3Kb картинка грузится так, как будто бы она весит 3Mb, на ровном месте начинают «залипать» (отдаваться очень медленно) css-ы и JavaScript-ы. Вы нажимаете ctrl + reload — и уже, вроде, проблемы нет, потом спустя всего несколько минут все повторяется опять.

Не всегда истинная причина «тормозов» очевидна и мы косо поглядываем то на nginx, то на хостера, то на «забитый» канал, то на «тормозной» или «глючный» браузер :)

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

В этой статье я предложу Вам свое решение этой проблемы, основанное на практическом опыте использования SSD дисков совместно с web-сервером nginx.

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

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

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



Я не буду говорить о дизайне, проблемах вёрстки и т.п. — это технические нюансы, и каждая студия разбирается с ними самостоятельно. Речь пойдёт о конкретных деталях, которые свойственны практически всем, но от этого не становятся менее глупыми.

#1: Текст главной страницы

Надеюсь, не нужно объяснять, насколько важен для web-сайта хороший текст. Особенно, если сайт коммерческий. Но, в то же время, тексты 90% сайтов web-студий СНГ бесполезны. Почему я так считаю?

Давайте посмотрим на вопрос со стороны заказчика и будем предельно откровенны. Сколько студий «уже 10 лет на рынке web-разработки»? Сотни. В скольких студиях «работают только квалифицированные специалисты»? Во всех. У какой студии «самая качественная и расширяемая CMS»? У каждой.

Топик Много книг, хороших и разных навёл на мысль сделать похожий каталог наиболее удачных и интересных книг по веб разработке.

Поэтому предлагаю здесь собрать и структурировать такие книги с небольшим описанием, вашим рейтингом и просто пообсуждать их.

update: Теперь есть электронные версии книг!

Начнём…

Кто виноват?

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

Вот некоторые примеры таких ситуаций:

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

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

В этом посте расскажу о собственном опыте создания и продвижения стартапа YesterdayMe.ru. Пост построю как перечисление наиболее значимых наблюдений и рекомендаций в ходе развития проекта, но намеренно не буду делать обширных выводов, чтобы уместиться в читаемый объем. Коротко, по делу, исходя из опыта первых семи месяцев работы сервиса.

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

Сегодня у сервиса около двух тысяч активных пользователей (пользуются сервисом хотя бы раз в неделю).