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

Дано: объём данных 10гб. Входящий канал – 200к, есть некоторые ограничения. В офисе исходящий канал 50к, ограничений нет. На крайний случай есть домашний канал – 100к исходящего канала.

Решение первое: порезать по частям и заливать на бесплатные файлопомойки.

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

Решение второе: порезать по частям и поднять файлы на локальном http/ftp сервере.

Если необходимо разделить файлы на два исходящих канала – требуются дополнительные движения извилин и мониторинг.

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

Решение третье: торрента и p2p-соединения.

1. На исходящем канале поднимается торрента (в виде мю-торрента, легковесного клиента).

2. В мю-торренте подбирается исходящий порт, видимый для клиента. В случае ограничения можно выбрать “полезные” порты: 80, 8080, 443 и подобные. Если требуется, порт необходимо открыть(прокинуть) на мопеде через “порт-форвардинг”. Порт тестируется (получателем) через браузер до достижения успешного результата в виде “инвалид реквест”.

3. В качестве вспомогательного инструмента можно воспользоваться сервисом типа динднс, это безусловно полезно если провайдер интернета  даёт динамический айпи-адрес. Да и вообще динднс в хозяйстве может пригодиться.

4. Создаётся торрент-файл для целевой папки. Треккер в него прописывать не надо (впрочем можно копнуть сюда). Добавляем веб-сиды для “раздающих”.

5. Торрент-файл отправляем (по почте) получателю и подкладываем в мю-торрент, перехешируем и запускаем.

6. На входящем канале получатель также ставит мю-торренту и добавляет торрент файл. Сразу всё может и не зафырчит, следует вручную добавить раздающего на закладке Пиры. Требуется указать его в виде ip-адрес:порт (см пункты 2 и 3).

7. Затем с файлами и торрент-файлом перемещаемся к домашней точке раздачи. Пробегаемся по пунктам 1-2-3-5.

Результат – достигается суммарная исходящая скорость 50к+100к, нет особой возни с балансировкой, томами и файлами, контроль целостности достигается микроблоками и легко исправляется. Архивация не требуется в целях контроля целостности, только для сжатия данных. Папка с тучей файлов или один большой файл – также особого значения не имеет.

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

Сортировка почты – вещь ну просто необходимая при большом потоке писем. Есть куча методов и подходов к сортировке.

например, продвинутым моментом я считаю такую настройку, при которой письма сами раскладываются по папкам, на основании заголовков и адресной книги. То есть так, чтоб при этом не надо было постоянно подкручивать правила сортировки – по правилу “один раз настроил – и работает”.

Ещё есть интересные моменты скриптования прямо на сервере – это называется Sieve.

Пишешь скриптик, и он работает в моменты, когда происходит обработка писем на сервере.

Например, я пока повесил на один из ящиков скрипт:

require ["reject"];

if address :is ["To", "Cc"] ["contact@sample.com"] { }
else {
    reject "Banned";
    stop;
}

Здесь contact@sample.com – адрес ящика, на который я повесил этот скрипт, а “Banned” – текст в отлупе.

Скрипт делает следующее: реагирует отлупом на все письма, которые направлены не напрямую в этот ящик (спам, рассылки и подобные письма). Проходят только письма, у которых этот ящик указан в полях Кому(To) и Копия(CC), но не в Скрытой/Слепой Копии (BCC).

Пока поставил, поживём – увидим, что будет дальше.

Я давно уже отмечаю, что эти два монстра друг на друга похожи, но никогда не сравнивал их.

Очень многие сервисы повторяют друг друга: 

• Почта и поисковик – это только основная открытая часть
• ГуглТолк против Я.Онлайн
• Метрика Яндекса против Гугловой Аналитики
• Лента Яндекса против Гуглового Ридера
• ЯндексДирект против “как-эта-штука-называется-у-гугла”
• Фотки Яндекса против ГуглоПикасы
• Ютуб против ЯндексВидео
• и так далее…

Часто используются не только похожие принципы, но и похожая реализация. Различие кроется в деталях.

Вот можно, например, детально сравнить Ленту с Ридером:

• Яндекс имеет рекламный блок, у Гугла всяческая реклама отсуствует
• Яндекс имеет прокрутку по полной странице, Гугл имеет прокрутку по вложенным спискам
• Гугл имеет полный AJAX, а у Яндекса он, похоже, только частичный.
• Яндекс использует постраничное разбиение списка новостей, а Гугл использует прокрутку и динамическую подгрузку
• Гугл имеет колаборативные сервисы “нравится, общие, комментарии”, а у Яндекса есть только репостеры в ЖЖ, Твит и иже с ними
• Гугл умеет оперировать статистикой подписки – причем как серверной, так и юзерной, а у Яндекса такие возможности почти отсуствуют – можно посмотреть только количество подписчиков
• Рекомендации Гугла основываются на текущей подписке, но вот откуда сложились рекомендации у яндекса – для меня загадка
• Гугл позволяет лепить дополнительные теги на новости, а классификация Яндекса останавливается на папках
• Возможности настройки интерфейса у Гугла более серьёзные, нежели у Яндекса
• …

 

В разрезе данного сервиса мне видится преимущество Гугла несомненным.

Борьба с энтропией сродни борьбе с ветряными мельницами. И моё скептическое отношение к дизайну лежит в области энтропии.

Энтропия — мера беспорядка системы, состоящей из многих элементов.

Если рассматривать любой сайт, то он нужен для структурирования изложенной информации. Поэтому правильный сайт должен снижать энтропию интернета. Для этого и придумали целую тонну разных CMS – систем управления содержимым.

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

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

(далее…)

Информационная архитектура блогов
Надо прочитать эту статью пару раз
http://www.alik.su/articles/uprising-against-blogs/

Есть очень много над чем задуматься…

(далее…)

Для интереса и общего развития прошел несколько тестов на сайте «Специалист.Ру»

Специалист Microsoft Excel 2007
Специалист Microsoft Word 2007
Пользователь Microsoft Office 2007 (Word, Excel)
Настройка офисных и домашних компьютеров
Базовые навыки управления ИТ службой в компании
Основы ANSI SQL
Базовые офисные компьютерные технологии. Windows Vista и Microsoft Office 2007
Работа в глобальной сети Интернет 2005

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

К сожалению, там нет профильных тестов.