20 ноября впервые после 14-ти месяцев ремонта и модернизации, специалисты CERN пустили пучок протонов по большому 27 километровому радиусу в одном направлении. Этот пучок был погашен и 21 ноября был запущен пучок в противоположном направлении. Эксперимент, по сообщению представителей CERN в своем микроблоге, прошел в штатном режиме. После несколько миллионов тестовых витков в каждом из направлений коллайдер был запущен на разгон пучков в противоположных направлениях одновременно. Все четыре детектора, установленных на БАК, успешно регистрируют поток протонов.

Случайно наткнулся в сети на такой ролик:



Очень удивился, а потом сел и разобрался. Всё просто и похоже на умножение столбиком. Сначала рисуем пересекающиеся группы линий для обоих чисел. Для каждого разряда рисуется одна группа из линий. Количество линий совпадает со стоящем в этом разряде числом (если в разряде будет стоять ноль — можно нарисовать пунктирную линию чтобы не потерять разряд). А затем по диагоналям подсчитываем кол-во пересечений и собираем результат. Способ по сравнению с умножением в стобик получается более наглядным, на мой взгляд.

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

Не пиар Вконтакта, а просто мои размышления и совет, скажем, как веб-мастера. Наблюдаю как реализация сервисов в виде этих приложений становится всё более «модной» практикой. Посмотреть общее количество приложений Вконтакте можно здесь (надо быть зарегистрированным). Больше года назад их почти не было. Сейчас их 1023 («общих», то есть не игр — 260). Через год их будет раз в 5 больше (оценка моя, кто точней думает — поправьте). Направление только начинает набирать популярность. Даже если выбросить из них игровые и развлекательные (конечно же таких большинство и они самые популярные, все-таки работает правило 95%), нужных и полезных всё равно останется очень и очень много.

Ну, например, навскидку: интернет-радио, платежные системы (Webmoney, Roboxchange), icq-клиенты, отправка смс. Очень много приложений дублирующих функционал каких-то полезных сайтов: Last.fm, 4konverta.ru, барахолка мобильных mobad.ru, всякие гороскопы/органайзеры/прогнозы погоды/программы телепередач. Есть даже тренажёр для клавиатуры!

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

У вас уже есть сайт/ресурс с неким полезным уникальным функционалом? Подумайте, можно ли реализовать его некий дубликат в виде приложения для Вконтакте. Если да — могу вас поздравить. Вы нашли ещё один способ увеличить размер постоянной аудитории своего проекта.

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

Мониторить на серверах можно всё — загрузку памяти и CPU, трафик сети и жесткого диска, какие-то сервисы и кол-во запросов к этим сервисам.

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

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



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

• выкатили обновление, а оно стало работать медленней (напортачил где-то программист);
• какие-то закономерные всплески (например какой-нибудь другой сервис начинает в определённое время «песочить» этот сервис и дёргать с него страницы, дискредитируя тем самым других пользователей, нужно тщательней планировать время или частоту запросов этого стороннего «сканера»);
• отвалился какой-нибудь внешний источник данных, с которого этот сервис берёт результат, и теперь его график уже ненормально выделяется среди других (проблема не наша, но нужно разбираться с внешним источником, сообщить его администратору о проблеме);
• периодические задержки выдачи временем более секунды уже говорят о том, что где-то что-то не то, и нужно садиться ковыряться с сервисом и выяснять где именно образовалось узкое место;
• список можно продолжить...