Учитывайте, что по информации ByFly радиус действия базовой станции в условиях городской застройки составляет около 1 км.

Качество архитектуры и программного кода продукта на работающем результате часто определить просто невозможно. Чем лучше отдел тестирования, тем меньше ошибки в архитектуре и коде влияют на стабильность работы программы. Наверное именно по этой причине многие разработчики и менеджеры считают, что на качество кода можно попросту “забить” — главное — результат. Очевидно, что в их словах есть рациональное ядро, ведь чем качественнее архитектура и код, тем дороже обойдется разработка продукта. А пользователь платит за работу программы, но не качество кода.

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

На практике даже в случае больших сложных и долгосрочных программных проектов встречается абсолютно наплевательское отношение к архитектуре и коду. Особенно это свойственно аутсорсинговым проектам, где пишут “не для себя”. Здесь главная задача — именно результат. Работу сдал, деньги получил и забыл. А с программой потом будут мучаться уже другие. Причем, это правило действует как в масштабе фирмы-аутсорсера, так и в масштабе конкретного разработчика.

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

Выходит, что чем меньше на проекте людей, тем выше должна быть их квалификация для получения того же результата. А как следствие — тем качественнее будут внутренности программы. В случае работы на перспективу такой подход получается выгоднее, так как наработав хорошую базу, ее легко и относительно недорого масштабировать, сопровождать, расширять. Этот подход и стараются применять компании, пишущие код для себя. Именно поэтому, в крупных компаниях типа Гугла, Яндекса работают преимущественно очень высококвалифицированные кадры. Каждый сотрудник этих компаний в состоянии решать сложные комплексные вопросы.

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

Но справедливости ради, надо заметить, что в последнее время аутсорсеры стараются выходить на путь качества, а не количества. Многие заказчики стали понимать, что им подсовывают каку и искать более серьезных партнеров. Так что похоже на то, что в среднесрочной перспективе 80% (по принципу Паретто) разработок должны быть по качеству архитектуры и кода выше среднего.

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

• количественный: много слабых разработчиков пишут много кода — получаем ожидаемый результат;
• качественный: мало сильных разработчиков пишут среднее количества кода — получаем такой же ожидаемый результат.

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

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

Все написанное выше является моим ИМХО и основано на личных наблюдениях. Контраргументы принимаются и тема подлежит обсуждению для выяснения истины.

Updated 21:10 15.04.2010 по Минску.

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

Докладчики очень приятные и профессиональные. Их было интересно слушать, с ними было интересно общаться. Все были максимально открыты.

Первым выступал Андрей Себрант — директор по маркетингу Яндекса. Общий доклад, ответы на общие вопросы. Убедительный рассказ о том, что время изобретения своих велосипедов с нуля прошло. Сейчас время сбора из комплектующих. Как раз поставой комплектующих и занимается Яндекс: ядро всех докладов — интеграция API сервисов Яндекса и партнерская поставка контента Яндексу в обмен на трафик.

Затем Александр Садовский рассказал о поиске и особенностях белорусской версии. Яндекс стремится к региональности. Результаты поиска в разных регионах существенно разнятся. Кроме того, теперь в поиске учитывается морфология белорусского языка (правда пока в зачаточной стадии). В идеале целью Яндекса является полная персонификация выдачи под клиента. Поисковые подсказки тоже региональные.

Александр заметил, что надо обращать внимание на такие вещи, как карта сайта и robots.txt для повышения позиции в выдаче. Кроме того, существует множество настроек и корректировок в интерфейсе Яндекс.Вебмастер, которые необходимо использовать.

Михаил Сенин кратко поведал о серверисе Яндекс.Сайт. Самый скромный доклад и практически ничего нового.

Если я не ошибся, то Илья Сегалович довольно интересно рассказал о юзкейсах API Яндекс.Карт и о перспективах сервиса. API сервиса постоянно совершенствуется, и уже сейчас доступны довольно мощные инструменты для интеграции. Например, практически неограниченное количество меток на карте (смотрите пример с терминалами Киви в Москве). Так же отмечу возможность в API поиска координат по адресу, точек в заданном радиусе от точки, расчет оптимальных маршрутов. Правда последнее для Минска пока не поддерживается из-за отсутствия хорошего графа дорог. По словам представителей Яндекса, купить такую информацию нее у кого, а собирать ее самим им пока не интересно.

В перспективе развития сервиса карт для Беларуси создание подробных карт областных центров.

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

Роман Иванов, руководитель отдела коммуникационных сервисов, рассказал про пользовательские виджеты в Яндекс.Баре. Бар сейчас существует для IE и Firefox. Виджеты могут быть динамическими (например, отображать количество писем в ящике). Создание виджетов — процесс не сложный. Уж точно не сравнится с процессом создания целого тулбара.

Антон Забанных, довольно эпотажная личность, поведал о возможностях Яндекс.Почты для доменов. Кстати, он руководитель группы сервисов персонального общения (почты). Самое интересное то, что сейчас для сайта действует ограничение в 1000 почтовых ящиков, но оно может быть без проблем и бесплатно повышено для конкретного сайта после контакта с саппортом сервиса. А через API сервиса можно создавать и удалять ящики без участия оператора. Довольно заманчивая возможность для серсвисов, которые хотят предоставить пользователям почту в своем домене.

Антон обозначил, что сервис не предназначен для использования в качестве релея (рассылка писем роботом через SMTP). В этом случае домен могут заблокировать до выяснения обстоятельств. Правда решить проблему можно с помощью прямых рассылок с помощью SPF.

Тигран Худавердян, руководитель отдела портальных сервисов, рассказал о пользе пользовательских виджетов для главной страницы Яндекса. Вера Лейзерович продемонстрировала процесс создания простейших виджетов. Кстати, на создание самого простого виджета ушло примерно 50 секунд.

Смысл создания виджетов в том, что у многих пользователей (в том числе из Беларуси) Яндекс установлен в качестве домашней страницы. Размещают виджеты около 15% этой аудитории. В итоге создатель виджета получает некислый трафик с главной Яндекса на свой сайт, Яндекс — качественный контент, а пользователь — то, что искал. Все счастливы.

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

Татьяна Исаева (руководитель группы контент-менеджеров Яндекс.Новостей) озвучила, пожалуй, самый тяжелый для прослушивания доклад про Яндекс.Новости. Длинный и монотонный.

В заключении Антон Волнухин рассказал про сервис Яндекс.Блоги и API, которое он предоставляет. Он собственно и является руководителем этого сервиса.

Все с удовольствие отвечали на вопросы в кулуарах. Особенно интересно было пообщаться с Larry Novsky (имя в миру не запомнил). Не знаю, кто он в Яндексе, но он отвечал на все вопросы, и больше всех знал про “телодвижения” Яндекса в Беларуси.

На мероприятии снимали видео и обещали его выложить. Также обещали выложить все презентации в открытый доступ. Ждем пополнения в разделе Яндекс.Субботников.

Обещали повторять Субботник примерно раз в год.

Яндекс молодцы! Спасибо!

Отзывы с Я.Субботника

—

Твитер. Фотографии. Еще фото.

Яндекс в Беларуси (конспект Я.Субботника) | Яндекс.Субботник в Минске. День 1

Debian 5.0. Как обычно, сначала требуется обновить систему. А затем:

0) Если еще не установлены, то устанавливаем

#lm-sensors apt-get install lm-sensors

1) Сливаем свежую версию (2010-02-19) sensors-detect. Файл можно взять готовый или выдернуть из официальных билдов.

Файл должен быть положен в: /usr/sbin/sensors-detect и иметь права 755.

2) Готовимся к сборке модуля ядра:

#apt-get install build-essential linux-headers-$(uname -r) linux-source-$(uname -r | awk -F’-’ ‘{print $1}’)

3) Патчим исходники стандартного дебиановского модуля coretemp

#cd /usr/src
#wget http://mabene.icomedias.com/coretemp.patch
#tar jxvf linux-source-$(uname -r | awk -F’-’ ‘{print $1}’).tar.bz2
#cd linux-source-$(uname -r | awk -F’-’ ‘{print $1}’)
#patch -p1 < ../coretemp.patch

Здесь вы получите сообщение о неполном патче файла. Не пугайтесь, все хорошо. Последний кусок патча не применился, т.к. патч для Ubuntu, а в Debian сырец чуточку другой. Доведем патчинг до конца руками:

#nano drivers/hwmon/coretemp.c

Находим почти в конце файла строки:

/* check if family 6, models 0xe, 0xf, 0×16, 0×17 */
if ((c->cpuid_level < 0) || (c->x86 != 0×6) ||
!((c->x86_model == 0xe) || (c->x86_model == 0xf) ||
(c->x86_model == 0×16) || (c->x86_model == 0×17))) {

И заменяем их на:

/* check if family 6, models 0xe, 0xf, 0×16, 0×17, 0×1A, 0×1C */
if ((c->cpuid_level < 0) || (c->x86 != 0×6) ||
!((c->x86_model == 0xe) || (c->x86_model == 0xf) ||
(c->x86_model == 0×16) || (c->x86_model == 0×17) ||
(c->x86_model == 0×1A) || (c->x86_model == 0×1C))) {

Суть этой замены в том, что в комментарий и оператор добавляем еще лэйблы двух семейств (одно из них как раз Atom): (c->x86_model == 0×1A) || (c->x86_model == 0×1C)

4) Собираем (билдим) модуля ядра

#make -j 4 -C /lib/modules/$(uname -r)/build M=/usr/src/linux-source-$(uname -r | awk -F’-’ ‘{print $1}’)/drivers/hwmon/ modules

5) Копируем полученный собранный модуль ядра в нужное место:

#cp drivers/hwmon/coretemp.ko /lib/modules/$(uname -r)/kernel/drivers/hwmon/coretemp.ko

7) modprobe coretemp

Если ошибок нет, то все ок.

8) #sensors-detect (всегда отвечаем утвердительно)

9) #sensors (радуемся):

coretemp-isa-0000
Adapter: ISA adapter
Core 0: +13.0°C (crit = +95.0°C)

coretemp-isa-0001
Adapter: ISA adapter
Core 1: +17.0°C (crit = +95.0°C)

coretemp-isa-0002
Adapter: ISA adapter
Core 2: +12.0°C (crit = +95.0°C)

coretemp-isa-0003
Adapter: ISA adapter
Core 3: +16.0°C (crit = +95.0°C)

P.S. Если призагрузке модуля ядра coretemp у вас возникала такая ошибка:

# modprobe coretemp
insmod /lib/modules/2.6.26-2-686/kernel/drivers/hwmon/coretemp.ko
FATAL: Error inserting coretemp (/lib/modules/2.6.26-2-686/kernel/drivers/hwmon/coretemp.ko): No such device

то описанное выше решение именно для вас.

P.S.S. Спасибо: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/296478, http://www.didier-segura.fr/?p=66.

Этим летом, в самом конце июля я со своей девушкой Наташей отправился в 16-тидневное путешествие по восточной Европе. На автобусе с выездом из Минска мы проехали по территории 6 стран, 9 дней отдыхали на море. Сейчас я попытаюсь поделиться с вами впечатлениями от увиденного :).

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

Подгорица — это тихий безлюдный бедный городок.

Часть города вовсе обыкновенная деревня.

Часть занята жилыми кварталами советского типа.

Часть застроена более-менее нарядными зданиями.

Еще часть строений — административно-деловые. Здесь размещены все органы управления страной.

Даже многие правительственные здания находятся в ужасном состоянии.

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

И мост Миллениум через реку Морача.

Площадь в центре города выглядит с одной стороны так:

А с другой так:

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

На перекрестках часто встречаются камеры. Для каждой полосы отдельный светофор.

В городе есть один киоск.

Один памятник Высоукому.

Один большой хуй.

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

Есть в городе и приятные глазу места.

Например, пешеходная улочка (аналог Арбата).

В каждом магазине традиционные скидки.

Местами город оживает. Но таких мест мало.

Кратко суть верстки: внешний элемент a поставляет картинку начала кнопки (левая часть) и делать отступ слева на ширину это картинки, первый вложенный span добавляет конец кнопки и отступ справа, второй вложенный span заливает фон кнопки и объявляет ее высоту.  Последний вложенный span нужен для размещения текста кнопки по-середине.

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

Тестировалась и работает правильно в IE 7, Opera 10, Firefox 3.5, Safari 3.1.2, Chrome 3.0.195.27.

Демонстрация…

Там особая атмосфера, особый размах. Этот город не такой красивый, как Питер, но там есть что посмотреть.

Перед отъездом в Москву меня убеждали, что там помойка. Нет, там чисто. Не.jpg” alt=”" width=”1000″ height=”563″ /> грязнее, чем в Минске, — это точно.

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

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

Особенно завораживающе находиться у подножья такого здания и смотреть вверх.

Ведь умели же раньше строить, не то что сейчас. Умели строить красиво.

А сейчас умеют строить прямоугольные коробки. А гордятся-то этим как! Научились строить такие здания, которые в США уже в начале прошлого века умели.

Таких зданий по городу много. Одно унилие другого.

Ими застроена практически вся набережная. Маршрут по Москве-реке, который предлагается туристам, скучен и неинтересен именно из-за отсутствия достойных строений на набережной (от Киевского вокзала до Кремля и назад).

БольшАя часть набережной заселена деревьями.

Еще кусок занимают производственные здания.

Ну и Кремлевский сегмент.

Почти отовсюду видны небоскребы Москва-Сити.

Местами даже красиво.

А вот так выглядят современные спальные районы Москвы, отдаленные от центра.

Или вот так…

***

Особенности города.

На Воробьевых горах собираются байкеры.

В метро прессу и мелочи продают автоматы за монеты.

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

БМВ рекламируется возле Кремля.

Даже у Путина баннер меньше.

В цетре города стоит НЛО.

В центре на переходах рельефная плитка. Вообще, в Москве только и переходи дорогу, если ты слепой. Сразу переедут. Без вариантов.

А в транспорте турникеты.

По всему городу развешены флаги России и Москвы в связке. Отдельно флаг России встретил только в двух местах, одно из которых — Кремль.

Московский ГУМ ночью похож на здание из рекламы Кока-Колы.

Хороший контраст Кремлю на Красной площади.

Кстати, куранты. Я раньше думал, что эта башня где-то по-центру. Оказалась скраю.

Закрытые казино на Новом арбате еще не успели разобрать.

А Старый арбат — скучная пешеходная улочка с кучей кофеен (сбился со счету) и синим троллейбусом.

Селиться надо в Измайлово-Вега. Недорого, но шикарно.

А отличный повод съездить в Москву — следующий HighLoad++.

Пакетная обработка фотографий на Линуксе — это просто!

* — apt-get install imagemagick

Вначале краткая характеристика каждого из типов:

• TIMESTAMP — тип данных для хранения даты и времени. Данные хранятся в виде количества секунд, прошедших с начала «эпохи Юникса». Диапазон значений: 1970-01-01 00:00:00 — 2038-12-31 00:00:00. Занимает 4 байта.
• YEAR — тип данных для хранения года. Диапазон значений: 1901 — 2155. Занимает 1 байт.
• DATE — тип данных для хранения даты. Диапазон значений: 1000-01-01 — 9999-12-31. Занимает 3 байта.
• TIME — тип данных для хранения времени. Диапазон значений: −828:59:59 — 828:59:59. Занимает 3 байта.
• DATETIME — тип данных для хранения даты и времени. Диапазон значений: 1000-01-01 00:00:00 — 9999-12-31 00:00:00. Занимает 8 байт.

Хозяйке на заметку. Интересно то, что большинство программистов полагают, что понятие «timestamp» — это и есть Unix-время. На самом же деле, timestamp — это метка, которая представляет собой последовательность символов, обозначающих дату и / или время, когда определенное событие произошло. А «время Юникса» (Unix time) или POSIX time — это количество секунд, прошедших с полуночи 1 января 1970 года по UTC. Понятие timestamp шире, чем Unix time.

Проанализировав описание типов, представленное выше, можно сделать практически все выводы о достоинствах и недостатках тех или иных типов. Все довольно просто и очевидно.

Но прежде, чем рассказать об использовании этих типов, хочу заметить, что на практике часто используется другой тип для хранения даты и времени: целочисленное значение (для хранения даты — INT (4 байта), даты и времени — BIGINT (8 байт)). Отличие использования целочисленных типов от DATE и DATETIME лишь в том, что при выводе данные не форматируются, а в вычислениях с датами и временем целые числа требуется преобразовывать в соответствующий календарный тип. Кроме того, не производится проверка на валидность представленного значения перед сохранением. Возможности сортировки сохраняются. Поэтому INT и BIGINT имеет смысл использовать в тех же случаях, как DATE и DATETIME, с целью максимизации переносимости и независимости от СУБД. Других преимуществ я не вижу, если они есть, предлагаю указать в комментах.

Использование календарных типов данный в MySQL

Начнем с самого простого — тип YEAR. Единственное его достоинство — малый размер — всего-то 1 байт. Но из-за этого действует строгое ограничение по диапазону допустимых значений (тип может хранить только 255 разных значений). Мне сложно представить практическую ситуацию, когда может потребоваться хранить года строго в диапазоне от 1901 до 2155. Кроме того, тип SMALLINT (2 байта) дает диапазон, достаточный в большинстве ситуаций для хранения года. А экономить 1 байт на строке в таблице БД в наше время смысла нет.

Типы DATE и DATETIME можно объединить в одну группу. Они хранят дату или дату и время с довольно широким диапазоном допустимых значений, независимую от установленной на сервере временной зоны. Их использование определенно имеет практический смысл. Но если требуется хранить даты исторических событий, уходящие в прошлое за Нашу эру, придется выбрать другие типы данных. Для хранения дат неких событий, потенциально выходящих за рамки диапазона типа TIMESTAMP (дни рождений, даты выпуска продуктов, избрания президентов, запуски космических ракет и т.д.), отлично подойдут эти типы. При использовании этих типов нужно учитывать один важный нюанс, но об этом ниже.

Тип TIME можно использовать для хранения промежутка времени, когда не нужна точность меньше 1 секунды, и промежутки времени меньше 829 часов. Добавить тут больше нечего.

Остался самый интересный тип — TIMESTAMP. Рассматривать его надо в сравнении с DATE и DATETIME: TIMESTAMP тоже предназначен для хранения даты и/или времени происхождения неких событий. Важное отличие между ними в диапазонах значений: очевидно, что TIMESTAMP не годится для хранения исторических событий (даже таких, как дни рождений), но отлично подходит для хранения текущих (логирование, даты размещения статей, добавления товаров, оформления заказов) и предстоящих в обозримом будущем событий (выходы новых версий, календари и планировщики и т.д).

Основное удобство использования типа TIMESTAMP состоит в том, что для столбцов этого типа в таблицах можно задавать значение по умолчанию в виде подстановки текущего времени, а так же установки текущего времени при обновлении записи. Если вам требуется эти возможности, то с вероятностью 99% TIMESTAMP – именно то, что вам нужно. (Как этоделать, смотрите в мануале.)

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

Итак, тип TIMESTAMP используем для хранения дат и времени свершения событий нашего времени, а DATETIME и DATE — для хранения дат и времени свершения исторических событий, или событий глубокого будущего.

Диапазоны значений — это важное отличие между типами TIMESTAMP, DATETIME и DATE, но не главное. Главное то, что TIMESTAMP хранит значение в UTC. При сохранении значения оно переводится из текущего временной зоны в UTC, а при его чтении — во время текущей временной зоны из UTC. DATETIME и DATE хранят и выводят всегда одно и то же время, независимо от временных зон.

Временные зоны устанавливаются в СУБД MySQL глобально или для текущего подключения.Последнее можно использовать для обеспечения работы разных пользователей в разных временных зонах на уровне СУБД. Все значения времени физически будут храниться в UTC, а приниматься от клиента и отдаваться клинту — в значениях его временной зоны. Но только при использовании типа данных TIMESTAMP. DATE и DATETIME всегда принимают, хранят и отдают одно и то же значение.

Функция NOW() и ее синонимы возвращают значение времени в текущей временной зоне пользователя.

Учитывая все эти обстоятельства, необходимо быть крайне внимательными при изменении временной зоны в пределах подключения к серверу и использовании типов DATE и DATETIME. Если надо хранить дату (например, дату рождения), то никаких проблем не будет. Дата рождения в любой зоне одинаковая. Т.е. если вы родились 1 января в 0:00 UTC/GMT+0, то это не значит, что в Америке будут праздновать ваш день рождения 31 декабря. Но если вы решите хранить время события в столбце DATETIME, то тут уже построить работу с пользовательскими временными зонами на уровне СУБД просто не выйдет. Поясню на примере:

Пользователь X работает в зоне UTC/GMT+2, Y — в зоне UTC/GMT+3. Для соединений пользователей с MySQL установлена соответствующая (у каждого своя) временная зона. Пользователь размещает сообщение на форуме, нас интересует дата написания сообщения.

Вариант 1: DATETIME. Пользователь X пишет сообщение в 14:00 UTC/GMT+2. Значение в поле «дата» сообщения подставляется как результат выполнения функции NOW() — 14:00. Пользователь Y считывает время написания сообщения и видит те же 14:00. Но у него в настройках стоитзона UTC/GMT+3, и он думает, что сообщение было написано не только что, а час назад.

Вариант 2: TIMESTAMP. Пользователь X пишет сообщение в 14:00 UTC/GMT+2. В поле «дата» попадает результат выполнения функции NOW() — в данном случае — 12:00 UTC/GMT+0. ПользовательY считывает время написания сообщения и получает (UTC/GMT+3)(12:00 UTC/GMT+0) = 15:00 UTC/GMT+3. Все получается ровно так, как мы хотим. И главное — пользоваться этим крайне удобно: для поддержки пользовательских временных зон не нужно писать никакой код приведения времени.

Возможности подстановки текущего времени и работы с временными зонами в типе TIMESTAMP настолько весомы, что если вам в неком логе надо хранить дату без времени, все равно стоит использовать TIMESTAMP, вместо DATE, не экономя 1 байт разницы между ними. При этом на “00:00:00″ просто не обращать внимания.

Если же вы не можете использовать TIMESTAMP из-за относительно малого диапазона его значений (а обычно это 1—2 случая против 10—15 в базе сайта), придется использовать DATETIME и аккуратно его корректировать значения в нужных местах (т.е. при записи в это поле переводить дату в UTC, а при чтении — во время в зоне считывающего пользователя). Если вы храните только дату, то скорее всего не важно, какая у вас временная зона: новый год все празднуют 1 января по локальному времени, ничего переводить тут не понадобится.

Детектить версии нужно только популярных в СНГ немобильных версий браузеров, поэтому в моем коде определяется только Opera, Firefox, Safari, Internet Explorer и Google Chrome. Если вам потребуется определить версии большего числа браузеров, код можно легко дополнить.

Чтобы не раскидывать функции по проекту, весь код я оформляю в классы. Создадим статический класс, в котором будут два метода: определение версии браузера и сравнение версии с данными барьерными версиями по каждому из браузеров. Назовем его BrowserUtils.

Класс состоит из двух методов: определение браузера и его версии и сравнении полученной версии с пороговыми версиями по разным браузерам. Использовать класс очень просто:

Единственный нюанс по коду есть у Safari. Все версии этого браузера всегда посылали в UserAgent тег Safari/build, где buld — версия их движка. Это большая первая цифра, например 528.16. Так версии Safari отображаются в Google Analytics. Но более поздние версии стали писать свою версию в теге Version. Выглядит это примерно так: Version/4.0.2.

Так как мне требовалось выводить версию пользователю, я использовал код считывания версии из тега Version, а для старых версий не детектит номер версии.

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