В данной статье рассматривается опыт внедрения Silverlight-клиента для организации возобновляемой загрузки файлов на проекте Файлы@Mail.Ru.

Зачем это нужно? Думаю, не нужно рассказывать, что загрузку файлов на сервер и их хранение сейчас предоставляет очень большое количество веб-проектов, от небольших до очень крупных. Причем загрузка обычно реализована в виде обычного <input type=file/>, реже — с помощью Flash, еще реже — иными средствами (загрузку по FTP в данной статье мы не рассматриваем).

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

Что делать?

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

Несколько лет назад ко мне пришел мой босс и сказал: «У нас есть новый проект для тебя. Это перенос сайта, который уже имеет 1 миллион посетителей в месяц. Тебенеобходимо его перенести и убедиться, что посещаемость может вырасти в будущем без всяких проблем.» Я уже был опытным программистом, но не имел никакого опыта в области масштабируемости. И мне пришлось познавать масштабируемость трудным путем.

Сегодня утром я зашёл на Google Maps и с радостью увидел там слой «Пробки». Сразу же глаз зацепился за интересное интерфейсное решение для выбора времени, на которое будет показана ситуация с пробками.

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

Самое время вспомнить, как пишутся плагины под jQuery.

Всегда нравилась идея онлайн-мониторинга чего-либо на карте. И вот представилась возможность сделать нечто подобное.
Процессом и результатом разработки хочу поделиться с сообществом.

Большинство разработчиков на MySQL знакомы с командой EXPLAIN, однако значительно меньше людей знают о команде EXPLAIN EXTENDED, появившуюся ещё в MySQL 4.1, и ещё меньше умеют ею пользоваться.

EXPLAIN EXTENDED умеет показывать, что же конкретно делает с Вашим запросом оптимизатор MySQL. Для разработчика может быть совсем не очевидно, насколько сильно может отличаться написанный им запрос от того, который в действительности будет выполнен сервером. Этот процесс называется механизмом перезаписи запросов (query-rewrite), и он является частью любого хорошего SQL-оптимизатора. Команда EXPLAIN EXTENDED добавляет дополнительные предупреждения (warnings) к выводу команды EXPLAIN, в том числе и переписанный SQL-запрос.

Обмен файлами всегда привлекал людей, для этого собственно и был изобретен протокол BitTorrent.

Большинство торрент трекеров написано на PHP, хотя встречаются и такие, которые написаны на C# языке, но для ознакомления мы будем использовать именно PHP.

Давайте рассмотрим что из себя представляет трекер.

В последнее время в высоконагруженных сайтах стали все чаще применять технику Partial Caching или блочного кеширования. Достигается это, как правило, за счет применения, казалось бы уже давно забытого, SSI или близких ему технологий (например, ESI). Например, в связках Nginx + Memcached + SSI или Varnish + ESI.

Недавно и на Хабре тоже появился топик в котором автор описывал данный метод кеширования.

В данном топике в 3м варианте решения автор предложил читателям топика привести свои варианты решения относительно данной задачи.

Этому, собственно, и посвящается этот топик.

Наконец-то сервис для общения Скайп- и неСкайп-пользователей готов к бета-тестированию.

Зачем этот сервис нужен:
1. Несмотря на популярность Скайпа, довольно много пользователей либо не ставят софтфоны на свои компьтеры (кому-то сложно, кто-то редко общается), либо используют другие программы (например, Agent или Xlite). И чтобы Скайп-пользователи могли с ними общаться, достаточно отправить мылом Скайп-ссылку вида gate2skype.com<Ваш_Skype-логин> — и общение налажено. Не нужно никаких регистраций и инсталляций.

2. Нередко бывает потребность позвонить по Скайпу с чужого компа, а там Скайпа нет. Что делать? Устанавливать на чужом компе Скайп не всегда получается, да и не этично без разрешения хозяина.

3. Свою Скайп-ссылку можно разместить в блогах, социальных сетях, в подписях к E-mail'ам (как с открытым, так и со скрытым Скайп-контактом) — и с владельцем ссылки можно связаться с любого компьютера одним кликом.

4. Скайп-ссылку можно разместить на сайте компании — и любой посетитель сайта может бесплатно позвонить в компанию. Это аналог SkypeMe, однако не требует наличия Скайпа у посетителя сайта.

5. Также можно звонить из Скайпа на SIP

В скором времени будет чат-общение. Видеозвонки пока не получается прикрутить.

Приглашаем всех желающих попробовать новый сервис. Ждем Ваши комментарии и предложения.

Совсем недавно натолкнулся на один занимательный CSS баг/фичу, решил поделиться, возможно кому пригодится.
Нужно было на сайте создать выбор городов из списка, стандартный список не подошел по эстетическим соображениям, результат должен был выглядить как «ссылка» при клике на которой выпадает список доступных городов, задача банальна, но тут случайно наткнулся на занимательное поведение браузеров, причем как оказалось у всех одинаковое.

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

В чём же заключается трудновыполнимость задачи? В первую очередь — в очень низкой скорости работы веб-приложений на айфоне. Например, мобильный Сафари по моим прикидкам работает раз в 100 медленнее своего десктопного собрата. Если на декстопе одна и та же операция выполняется 10 мс и совершенно незаметна для пользователя, то на айфоне она может выполняться больше секунды. Для сравнения: первая версия движка разбивала небольшую главу на страницы примерно за 15 секунд. Сейчас, спустя полгода, он делает то же самое менее, чем за секунду и вполне сносно работает в нашем приложении booq.

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

Дело было глубокой осенью. Мне поручили разработку раздела, основной задачей которого является указание местоположения объектов фильтрации и поиска на карте. Что стало заметно сразу же — даже при отображении 10 объектов на карте, можно уменьшить зум до такого, при котором они просто сливаются. Если их будет 100 — появятся жутковатые наложения и тени. Не комильфо!

Поиск решения

Решение очевидное, маркеры нужно группировать. В процессе поиска наткнулся на хабростатью, в которой рассмотрены различные способы группировки большого количества маркеров на карте. Нас вполне устраивали «костыли 1-2», то есть группировка маркеров на клиентской стороне, однако… если бы они подошли, не писал бы я сейчас статью ;)

Так получилось, что последние несколько лет мне приходится принимать участие исключительно в распределенных проектах. Руководство проекта в США, business owner во Франции, разработка в России и Бразилии, а тестирование в Китае — это нормальная ситуация. В таких проектах — очень важна грамотная организация коммуникаций. В разных проектах использовались разные системы. Идеала найдено не было, потому то и был написан собственный «неидеал»: EmForge Portal, который я и хочу сегодня представить, надеясь что кому-то он может оказаться полезным

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

Наверняка многие из вас слышали об ужасно сложных интервью для желающих работать в компаниях типа «Microsoft», «Google» или «Apple» (на самом этот список можно продолжать и продолжать). Еще бы — общеизвестно, что Google каждый день получает порядка 1000 резюме, все именитые компании рассказывают направо и налево, что они ищут не меньше, чем гениев, а на просторах безграничного интернета время от времени появляются вопросы, которые задавались на интервью вроде «Как вы сдвинете гору Фудзи?» или «Сколько мячиков влезет в автобус?» или даже «Как создать хорошую поисковую систему, вроде Google?».

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

Итак, допустим цель «получить работу мечты» поставлена. Что же делать дальше?

Недавно к панорамам московских улиц на Яндекс.Картах  добавились панорамы улиц Санкт-Петербурга, Выборга и Гатчины. С тех пор многие уже успели обойти Москву и Питер вдоль и поперек, осмотреть все главные достопримечательности, найти знакомые маршруты или просто забавные кадры. Некоторые используют Панорамы улиц очень творчески – например, сайт moscowwalks.ru выпустил серию подкастов об истории некоторых столичных улиц.

А мы приглашаем вас на виртуальную экскурсию – по местам Санкт-Петербурга, которые все ищут, но далеко не все знают, где их найти. Это места, где принято загадывать желания. О том, куда в Питере приводят мечты, рассказывает и показывает Маша Орлова, менеджер проекта «Панорамы улиц».

И пусть всё сбудется!

Маша Орлова и Аня Ламтюгина, верим в чудеса

Условия

Мы используем MySQL для хранения любых данных FriendFeed. Наша база данных растёт вместе с числом пользователей. Сейчас у нас более 250 миллионов записей, это записи пользователей (post'ы), комментарии, оценки («likes»)

По мере того как росла база данных, мы время от времени имели дело с проблемами масштабируемости. Мы решали проблемы стандартными путями: slave-сервера, используемые только для чтения, memcache для увеличения пропускной способности чтения и секционирование для увеличения пропускной способности записи. Однако, по мере роста, использованные методы масштабируемости привели к затруднению добавлению новой функциональности.

В частности, изменение схемы базы данных или добавление индексов к существующим 10-20 миллионов записей приводили к полной блокировке сервера на несколько часов. Удаление старых индексов требовало времени, а не удаление ударяло по производительности, так как база данных продолжала использовать их на каждом INSERT. Существуют сложные процедуры с помощью которых можно обойти эти проблемы (например создание нового индекса на slave-сервере, и последующий обмен местами master'a и slave), однако эти процедуры настолько тяжелые и опасные, что они окончательно лишили нас желания добавлять что-то новое, требующее изменение схемы или индекса. А так как наши базы сильно распределены, реляционные вещи MySQL как например JOIN никогда не работали для нас. Тогда мы решили поискать решение проблем, лежащее вне реляционных баз данных.

Существует множество проектов, призванных решить проблему хранения данных с гибкой схемой и построением индексов на лету (например CouchDB). Однако, по-видимому ни один из них не используется крупными сайтами. В тестах о которых мы читали и прогоняли сами, ни один из проектов не показал себя стабильным, достаточно зрелым для наших целей (см. this somewhat outdated article on CouchDB, например). А все это время MySQL работал. Он не портил данные. Репликация работала. Мы уже в достаточной мере понимали все его узкие места. Нам нравился MySQL именно как хранилище, вне реляционных шаблонов.

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

Начало работы

В пабле нет ни одной нормальной библиотеки для работы с Last.FM «Submission» API PHP, пришлось разбираться и писать самому…
Для начала Вам необходимо перейти на страницу регистрации вашего API аккаунта.
После ввода всех данных, Вам предоставят 2 ключа: публичный и секретный.

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

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