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

Поэтому мы особенно рады, что впервые «привели» в Рунет секьюрити-проект Web Of Trust, который оценили уже миллионы пользователей по всему миру.

Что это такое? Web Of Trust создан в 2006 году в Финляндии. Уже сегодня проект объединяет свыше 22 миллионов пользователей по всему миру и их число постоянно растет.

Хотим поделиться радостью: мы успешно перевели нашу почту на UTF-8. Теперь можно спокойно переписываться с арабами, китайцами, японцами, греками, грузинами, писать письма на иврите и идише, блеснуть знанием финикийской письменности или зашифровать послание нотами. И при этом быть уверенным, что адресат получит именно то, что ему отправили, а не квадратики или «кракозябры».

Как и многие серьезные изменения, процесс перехода потребовал серьезной подготовки и имел большую «подводную» часть – перед разработчиками стояла задача обработать 6 петабайт писем в более чем сотне миллионов ящиков. Первые эксперименты начались осенью 2010 года, и весной 2011 все ящики были успешно переведены на новую систему. Одновременно с этим символично сменился домен проекта «почта»: вместо основного домена win.mail.ru и исторических koi.mail.ru и mac.mail.ru, которые выдавали сайт в соответствующих кодировках, теперь используется e.mail.ru, выдающий все страницы в UTF-8. Вся почта также хранится, обрабатывается и выводится в UTF-8. Это означает, что в письмах можно использовать любые живые и мертвые языки, математические и нотные символы, причем как в виде plain-text, так и с форматированием.

Чтобы напомнить, как обстояли дела с международным общением еще недавно, мы подготовили небольшой экскурс в историю кодировок.

Вначале была цифра

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

Не считая в чистом виде двоичной азбуки Морзе, первым кодом, превратившимся в стандарт, стал код Бодо. Этот 5-битный синхронный код позволял телеграфам передавать примерно 190 знаков в минуту (а в последствие до 760) или 16 бит в секунду. Кстати, те, кто покупал первые модемы, помнят, что скорость значилась именно в бодах – единицах измерения имени Эмиля Бодо, изобретателя кода и высокоскоростного телеграфного аппарата.

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

Итак, Highscreen GPS-1699 (он же Black Box) — «двусторонний» видеорегистратор со встроенным GPS-приемником и датчиком ускорения. Соответственно, он пишет два потока видео, данные с GPS (координаты и скорость) и показания датчика ускорения по трем осям. Не буду грузить техническими характеристиками (они есть на официальном сайте), лучше расскажу личные впечатления.

Для записи используются карточки microSD (почему micro — непонятно, в его корпус легко влезет слот для большой карты). Производитель обещает до 1 часа записи на гигабайт, на деле у меня получалось раза в полтора меньше. Но не думаю, что длительность записи является проблемой, тем более, что девайс поддерживает карточки до 32 гб — сутки видео! Разумеется, запись ведется «циклически», то есть заботиться об очистке места на карте не надо.

Вообще, устройство очень простое в использовании.

Поводом для этой публикации послужили недавние серьезные изменения, внесенные в механизм борьбы со спамом в рамках нашего почтового сервиса. Нам хочется поделиться новостью, но не в форме сухого пресс-релиза. Поэтому мы решили рассказать о том, как устроен АнтиСпам в Почте@Mail.Ru, и конечно — с удовольствием ответить на ваши вопросы. Итак…

Архитектура антиспама Mail.Ru

Собственный антиспам в Mail.Ru существует уже много лет. Желание разработать собственный продукт вполне объяснимо, т.к. на определенном этапе развития проекта требования к качеству и масштабируемости механизма борьбы со спамом стали слишком велики, чтобы их могли удовлетворить даже очень сильно кастомизированные «чужие» продукты. Конечно, какие-то сервисы и компоненты независимых поставщиков мы используем по-прежнему (например, для проверки писем на вирусную составляющую), но их роль сейчас уже не является определяющей.

Рады представить вам новшество для пользователей Почты@Mail.Ru в Internet Explorer 9 — теперь вашу Почту можно перетащить себе на панель задач Windows 7.

Для этого просто прикрепите иконку Mail.Ru из строки браузера Internet Explorer 9 на панель задач.

Каковы плюсы?

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

Как оказалось, «прилепить» сайт на панель задач очень просто.

За годы своего существования, почтовые сервисы прошли путь от plain text до красочно оформленных html-писем с мультимедийными вложениями. Чтобы идти в ногу со временем, Почта@Mail.Ru недавно обновила интерфейс написания писем. Что же изменилось? И, главное, что дали эти изменения?

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



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

Изменилась и область написания письма. На Mail.Ru (как и в среднем по Рунету) более 20% пользователей приходят с разрешением 1024x768.

Пару недель назад ко мне в руки попала электронная читалка PocketBook 302. Интересна эта модель прежде всего мощной начинкой — тут и touch screen, и wifi с bluetooth, и встроенные приложения. Честно скажу, это первая читалка, которой я пользовался дольше нескольких часов, поэтому я с удовольствием описал свои личные впечатления и мысли по поводу.

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

Учет задач мы ведем не в солидном таск-трекере, а в… текстовом файле. Точнее не просто текстовом, а в расшаренном документе Google Docs. Происходит это так:

• Записываем возникающие задачи обычным черным шрифтом в виде обычного ненумерованного списка.
• Размером шрифта отмечаем приоритет задач — чем крупнее, тем важнее.
• Цветом помечаем задачи, назначенные на конкретного человека — за каждым разработчиком закреплен свой цвет.

В начале файла обычно помещаем "легенду", чтобы всегда можно было вспомнить, где чей цвет. Вот как это выглядит:

Многие социальные сети предлагают пользователям такую платную услугу как «подарки». Обычно это символические знаки внимания, представленные в виде картинок, которые можно подарить другому пользователю, оплатив подарок sms-кой. Типичная стоимость подарков лежит в диапазоне от доллара до $7 за штучку.



Мы задумались: а что можно изобрести нового, необычного, интересного в этой области? И посвятили теме подарков недавнюю встречу клуба Brain Exchange. Участники встречи генерили новые мысли в формате мозгового штурма, поэтому часть идей может показаться странными или не подходящими — но наверняка их можно развить во что-то полезное. Мы делимся этими идеями со всеми желающими.

Собираю dbase для php5:

…
Build complete.
Don't forget to run 'make test'.

# make test
make: don't know how to make test. Stop

Забавно.

P.S. Встала нормально, конечно :)

Я давно перешел на использование gmail как единственной почты и счастлив :) Но одного сильно не хватало — возможности выводить текст письма моноширинным шрифтом. Это бывает просто необходимо при чтении всяких писем с «отформатированными» простым текстом табличками (и прочим ASCII-art), потому что в gmail они выглядят так:



В мире существует несколько решений, позволяющих использовать fixed font в gmail — но я не нашел ни одного удобного в использовании и работающего с современной версией интерфейса gmail. Поэтому я написал grasemonkey-скрипт для решения этой проблемы: userscripts.org/scripts/show/37471 — он добавляет в правой колонке страницы просмотра письма ссылку «Fixed Font», переключающую режим отображения. Теперь

Два месяца назад я купил новый ноутбук, на котором в частности была установлена 60-дневная демо-версия Microsoft Office 2007. Два месяца я без проблем пользовался этим офисом (даже привык к новому интерфейсу), но вот испытательный срок кончился, и теперь офис вместо работы предлагает его купить. Как честный гражданин, я решил заплатить несколько тысяч рублей за удовольствие пользоваться лицензионным софтом — и нажал «хочу купить через интернет».

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

Основы масштабирования

Масштабируемость — способность устройства увеличивать свои
возможности
путем наращивания числа функциональных блоков,
выполняющих одни и
те же задачи.
Глоссарий.ru

Обычно о масштабировании начинают думать тогда, когда один
сервер не справляется с возложенной на него работой. С чем именно он не
справляется? Работа любого web-сервера по большому счету сводится к основному
занятию компьютеров — обработке данных. Ответ на HTTP (или любой другой) запрос
подразумевает проведение некоторых операций над некими данными. Соответственно,
у нас есть две основные сущности — это данные (характеризуемые своим объемом) и
вычисления (характеризуемые сложностью). Сервер может не справляться со своей
работой по причине большого объема данных (они могут физически не помещаться на
сервере), либо по причине большой вычислительной нагрузки. Речь здесь идет,
конечно, о суммарной нагрузке — сложность обработки одного запроса может быть
невелика, но большое их количество может «завалить» сервер.

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

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

Пусть у нас есть $hash — ссылка на хэш с несколькими полями, и мы хотим обновить три из них. Банальный способ записать это:

<font color="gray">$hash->{foo} = 456;
$hash->{bar} = $bar;
$hash->{baz} = 'baz';

</font>

Можно воспользоваться hash slice — и вместо трех операторов скалярного присваивания достичь того же эффекта одним оператором присваивания списков:

Вчера был на фестивале фейерверков (благо, для этого надо было всего лишь выйти из офиса), получилось несколько красивых фотографий. Решил поделиться :)

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



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

В хабравики есть такие слова про карму: «повысить / понизить карму другого пользователя — карма >5». По моему, это ведет к тому, что в сообществе хабра образуется положительная обратная связь, опасная для сайта. Поскольку плюсовать других могут только обладатели высокой кармы — в плюс вылезут только те, кто «симпатичен» хабраэлите. А все «инакомыслящие» будут быстро загнаны в минус, и повлиять на сообщество уже не смогут. Опасаюсь, что скоро это приведет к вырождению сообщества :(