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

«В течение примерно 80 минут служба, которая рассылает уведомления, испытывала недостаток дискового пространства», написал Гандотра в своем аккаунте Google + . «Поэтому наша система продолжала отправлять уведомления. Снова и снова. Жуть.»

Эта проблема по-разному затронула пользователей. Я получил 41 сообщение подряд​​, а другие пользователи не заметили никаких проблем. К счастью для меня (и я полагаю, многих других), Gmail самостоятельно перебросила уведомления в папку “спам”. А вот владельцам iPhone повезло меньше: им придется удалять кучу личных сообщений.

«Мы не ожидали, что количество пользователей будет расти так быстро. Впредь нужно иметь это ввиду», добавил Гандотра.

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

Гандотра несколько раз извинился за спам в своем послании. Он также отметиил, что Google + все еще находится в «стадии тестирования» – неплохая отговорка. К тому же большинство сервисов Google обычно функционируют в постоянном режиме бета-тестирования, что помогает компании откреститься от большинства технических проблем, которые возникают время от времени.

techdaily.ru

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

История вопроса

Главной задачей Украинского сетевого информационного центра (УСИЦ) было внедрение домена первого уровня .укр, однако сделать кавалерийским наскоком этого не удалось. ICANN, пока что, не дала добро на разворачивание домена. Руководители УСИЦ объяснили это тем, что сменилось правительство, и международной организации не с кем было договариваться.

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

Еще остается масса нерешенных вопросов с доменом . UA, администрация которым до сих пор остается в ведении частного лица. Вот куда бы надо направить главную энергию.

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

Правила регистрации

Для защиты от кибер-сквоттинга регистраторы ввели сроки регистрации на начальном этапе. Итак, пока что можно зарегистрировать кириллические доменные лишь в доменных зонах в com.ua и kiev.ua. На первом этапе, который будет продолжаться до 17 ноября этого года, это смогут сделать лишь владельцы словесных кириллических торговых марок и общеизвестных знаков при предъявлении соответствующих документов. Процедура первого этапа приоритетной регистрации IDN аналогична существующим требованиям и условиям регистрации доменных имен в домене верхнего уровня в .UA. За этот короткий период регистраторы вместе с «Хостмастером» смогут нарубить капусты, поскольку стоимость регистрации составит около 600 грн. за 1 год.

На втором этапе, который будет продолжаться c 19 ноября до 19 декабря 2010 года, уже сможет регистрировать имена кто-угодно, но на срок 10 лет. Опять же – для защиты от кибер-сквоттеров. Цена домена падает до нормального уровня – около 90 грн., однако на 10 лет – это около 900 грн.

И уже c 21 декабря 2010 года будет доступна свободная регистрация, которая ничем не будет отличаться от регистрации латинских доменов в зонах .com.ua и .kiev.ua, с такой же ценой.

Для регистрации допустимы символы кириллического алфавита в нижнем регистре, арабские цифры и символ дефиса “-”. В то же время не допустим украинский символ апострофа “'”. Кроме того, кириллические доменные имена не могут содержать символов других алфавитов. И еще для тех, кто уже думает, какое бы имя ему зарегистрировать, установлено еще одно правило: имя должно содержать как минимум одну уникальную букву, визуально отличимую от латинских букв и цифр. Для этого приводим таблицу уникальных символов.

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

Да и для пользователей удобств не прибавится – ведь теперь придется набирать доменное имя сначала  кириллицей, затем переключаться на латиницу, ведь доменные зоны-то остаются англоязычными. Разве что Punto Switcher (софт для автоматического переключения раскладок) введет соответствующую функцию. Хотя, этой прогой пользуется не каждый.

У кого и почем

Зарегистрировать новое кириллическое доменное имя теперь можно практически у любого регистратора, хотя они особо не афишировали новую услугу, поскольку большинство из них довольно скептически относятся к ней. В данном направлении отличилась лишь телекоммуникационная группа «Вега», входящая в холдинг CRV – структуру Рината Ахметова. Данная компания первой разослала пресс-релиз о новой услуге. Поэтому, отдавая пальму первенства, рассмотрим сначала цены у данной компании. Итак, на первом этапе стоимость регистрации для них составит 582 грн. за первый год использования и по 84 грн./год с НДС за каждый последующий год. На втором этапе надо будет выложить 840 грн. за 10 лет использования доменного имени. И, наконец, на третьем этапе этапе цена вопроса - 84 грн., максимальный срок регистрации – 10 лет.

Для сравнения посмотрим на цены других компаний. Итак, Imena.ua и Iname.ua выставили абсолютно идентичные цены: 582 грн. за первый год на первом этапе и затем – по 86,4 грн. за год регистрации. То же самое, на втором этапе надо будет заплатить сразу за 10 лет.

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

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

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

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

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

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

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

Иными словами, Windows 8, вполне вероятно, появится на свет уже в 2012 году, хотя точная дата релиза, по понятным причинам, остается пока неопределенной. Что касается предполагаемой функциональности данной операционной системы, она может включать в себя некий аналог анонсированного недавно онлайн-магазина приложений  для Mac, а также опцию распознавания пользователя по лицу и ускоренную загрузку.

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

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

На втором этапе SEOLUX предлагает выполнить несколько проектов используя приобретенные навыки под руководством специалистов SEOLUX. Проекты позволят обучить сотрудников компании-разработчика используя процессы и инструменты RUP.

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

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

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

Таким образом, для каждого этапа набор работ будет следующим:

1. Составление перечня приемочных тестов

• QA анализирует требования к новому этапу.

• QA cоставляет список приемочных тестов для данного этапа. Лучше всего выделить эту группу в тест плане по версиям.

Набор тестов может быть прислан и заказчиком.

• QA утверждает список у PM-а.

2. Написание приемочных тестов

В отдельной тест кейс спецификации QA описывает запланированные на предыдущем шаге приемочные тесты.

3. Утверждение набора приемочных тестов

PM утверждает спецификацию приемочных тестов у заказчика.

4. Проведение приемо-сдаточных испытаний на стороне заказчика

При сдаче этапа (проекта) PM или QA на стороне заказчика демонстрирует успешное прохождение каждого утвержденного теста.

В один момент времени может быть до 2х веток кода:

• Основной branch – функционал, подлежащий сдаче в ближайшем деливери (текущем этапе).
• Вторичный branch – функционал, подлежащий сдаче через деливери (следующем этапе).

• 0й – разработка
• 1й – тестирование, fix, разработка, сдача этапа (деливери)
• 2й – тестирование, fix, разработка, сдача этапа (деливери)
• 3й – тестирование, fix, сдача проекта (релиз).

Кратко процесс можно описать так:

• 1. Для ближайшего деливери PM планирует объем необходимого функционала {Ф}.
• 2. Реализуется весь заданный функционал {Ф} (о чем свидетельствует PM).
• 3. Собирается билд для QA. QA приступает к тестированию функционала для ближайшего деливери {Ф}.
• 4. PM планирует объем функционала {Ф} для следующего деливери.
• 5. Разработчики приступают к разработке нового объема функционала {Ф}, параллельно исправляя дефекты, найденные в готовящемся деливери.
• ! У дефектов приоритет всегда выше, чем у нового функционала!
• 6. По мере исправления дефектов, имеющихся в готовящемся деливери, QA собирает промежуточные билды для тестирования.
• 7. QA сигнализирует о том, что весь необходимый для деливери функционал реализован и дефекты отсутствуют. PM собирает деливери.
• ! Деливери собирается и отправляется только после одобрения QA!
  • Деливери отправляется заказчику вместе с сопроводительной документацией.
• 8. PM инициирует слияние двух веток.
• 9. По мере реализации нового функционала для следующего деливери, QA собирает промежуточные билды для тестирования.
• 10. Процесс повторяется до выпуска финальной версии.

XX.YY.revision , где

Revision – номер внутренней сборки (Build number). Соответствует номеру последней ревизии в SVN, вошедшей в данную версию.

YY – номер поставки заказчику (Delivery number), обнуляется при увеличении XX.

XX – номер релиза (Release number).

1. Build для тестирования

Как правило, очередной build собирает QA. Версия равна XX.YY.revision.

2. Объединение веток (merging)

Ветки объединяет руководитель проекта или техлид. Версия равна XX.YY.revision.

3. Сборка Delivery

Деливери собирает также руководитель проекта или техлид.

Версия устанавливается вручную в XX.YY (ревизия отбрасывается, YY увеличивается).

Также, рекомендуется для каждого билда писать примечание к версии (Release notes), что облегчит работу как с заказчиком, так и QA инженерами.

Что входит в управление изменениями проекта:

• Анализ и сбор всех требований Заказчика.
• Фиксирование всех требований (общий бизнес-процесс, GUI, функционал) в спецификации.
• Регистрация всех требований, подлежащих реализации, в багтрекинговой системе. Соответствующая пометка тех требований, которые должны войти в деливери. Ответственный – руководитель проекта.
• Обязательный групповой анализ каждого запроса на изменение или доработку (руководитель проекта, QA, бизнес аналитик, техлид). Полное уточнение информации, принятие решения (отклонение запроса, запуск в реализацию, оформление дополнительным оплачиваемым этапом и т.п.)
• Оформление каждого запроса на изменение или доработку в форме Change Order, подлежащего подписи заказчиком (отвечает за оформление – бизнес аналитик, за подписание – руководитель проекта).
• После утверждения изменений должно проходить обязательное обновление спецификаций, тест-кейсов и т.д.
• Определение целесообразности начала тестирования следующего деливери.

Критерий начала:

• Все или большинство требований, относящихся к следующему деливери (фазе), реализованы.

Определяет готовность версии к тестировании по багтрекинговой системе, ответственный QA. Все требования, которые необходимо реализовать в определенном деливери, внесены в багтрекинговую систему с пометкой «Реализовать в x.y.» и, соответственно, попадают в фильтр «Деливери x.y.». Когда все или большинство требований, попадающих в фильтр, будут реализованы, версию можно передавать на тестирование QA.

• Определение готовности деливери к отправке. Критерии готовности:

• все требования, относящиеся к данному деливери (фазе), реализованы;
• открытые дефекты, относящиеся к данному деливери (фазе), отсутствуют.

Определяет по багтрекинговой системе QA и уведомляет руководителя проекта. Все требования, которые необходимо реализовать в определенном деливери, внесены в багтрекинговую систему с пометкой «Реализовать в x.y.» и, соответственно, попадают в фильтр «Деливери x.y.». Когда все требования и дефекты, попадающие в фильтр, будут закрыты, версию можно отсылать заказчику.

Мы рассмотрели пример процесса управления изменениями в ИТ проекте. Одна из распространенных ошибок – одноособное управление требованиями исходящее от руководителя проекта. Залог успеха – групповое обсуждение изменений, достижение компромисса со всеми учасниками.

План-график работ проекта (лучше всего – в MS Project). Должен показывать:

• Объем и дату каждого деливери.
• Объем работ на каждом этапе.
• Основные вехи.

Примеры основных вех:

• MILESTONE- утверждение спецификаций (в план должно быть заложено время на ревю и утверждение спецификаций заказчиком).
• MILESTONE- утверждение плана тестирования деливери Х (QA менеджер составляет план тестирования следующего деливери, который должен быть утвержден менеджером проекта).
• MILESTONE- завершение кодирования по деливери X (разработчики успешно закончили кодирование функционала, предназначенного для сдачи в деливери X).
• MILESTONE- QA приемка деливери (QA тестирует деливери на территории заказчика, если требуется, и дает «добро»).
• MILESTONE- готовность деливери Х к отправке (все фичи реализованы, а дефекты успешно исправлены – деливери можно отправлять заказчику).
• MILESTONE- готовность пользовательской документации (финальная документация, которую необходимо передать заказчику, должна пройти ревю менеджера проекта).
• MILESTONE- приемка деливери заказчиком (используя набор приемочных тестов, PM получает формальное одобрение продукта заказчиком).
• MILESTONE- проведен тренинг (заказчика необходимо обучить согласно заранее подготовленному плану).

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