Поиск русского гайда по сдаче на OCAJP 7 не увеньчался успехом, так что я решил написать свой.

Что это за сертификат рассказывают в этом видео. Сдавать или нет каждый решает для себя сам, но этот сертификат является базовым в иерархии Oracle для интересующихся Java.

Для себя я решил сдавать на OCP чтобы во-первых систематизировать знания, а во-вторых поднять привлекательность для работодателей.

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

Проектирование форм может оказаться настоящей проблемой. Чтобы получилось что-то стоящее и удобное для пользователей необходимо принять во внимание кучу разных рекомендаций и правил. В данной статье я постарался составить полезный список таких рекомендаций. Для его составления я использовал свой опыт и статьи экспертов.

Основные рекомендации и ввод данных

• Стремитесь к краткости.
• Убедитесь, что в форме используется один язык (обороты, термины).
• Если на странице находится только форма и ничего кроме нее, то при загрузке страницы стоит ставить фокус на первое поле формы, это позволит сэкономить немного времени (страница поиска, входа, регистрации).
• Поддерживайте ясный путь заполнения формы.
• Избегайте вторичных действий, если это возможно.
• В противном случае четко разделяйте основное и дополнительные действия.
• Выравнивайте основное действие так же как и поля формы, это упрощает восприятие формы.
• Цветная подложка у главной кнопки сделает её более видимой.
• Отключайте кнопку «Отправить» после того как пользователь на нее нажал, это позволит избежать двойной отправки данных.
• Еще лучше — показывайте индикатор отправки.

Современные системы мониторинга “из коробки” позволяют отслеживать практически все показатели отдельного узла системы, но обладают рядом существенных недостатков

• зная все об одном узле, о работе системы в целом они не имеют никакого представления — попробуйте из коробки выдать руководству “в данный момент у нас 1200RPS на фронте, 90% страниц отдается за 300мс, 95% за 650мc, системных ошибок и таймаутов происходит меньше 10 в секунду” (см картинку под катом)
• выход за рамки одного из системных показателей одного из узлов системы еще не значит, что стоит бить тревогу — возможно узел попал под повышенную нагрузку, или разработчики сменили алгоритм
• в рамках мониторинга отдельных узлов практически невозможно уследить постепенную деградацию сервиса — как правило он срабатывает только когда уже “ничего не работает”
• деградация производительности внешних сервисов не отслеживается в принципе (вас никогда не банил CDN?)

На исходной у нашей площадки более 1.000.000 уников, ~100.000.000 http запросов на фронтенд в сутки и развесистый, в плане сопровождения, зоопарк проектов. Набор ключевых слов — nginx, apache, php (двух вариаций), oracle. С заядлой периодичностью возникают ситуации “у нас все работает” по отдельно взятым зонам ответственности либо, что тоже не редкость, “у вас ничего не работает”. На границах ответственности идет сплошная передача тикетов.
Мы не стали изобретать велосипед и решили сделать мониторинг по времени и корректности отклика пользователю с отслеживанием отклика бекендов, а также какие из них были задействованы при обработке конкретного запроса. Ну и плюс наши объемы — не сильно большие, но несколько граблей по ходу изложения можно продемонстрировать.

Этот пост — перевод ответа на вопрос «Как сделать заполнение онлайн-форм весёлым (fun)» на сайте Quora.

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

Проверка данных

Сейчас проверка данных обычно выглядит как наказание — если вы понимаете, о чём я. Вы заполняете форму, кликаете «ОК»… и получаете страшную надпись типа «ТЫ ЗАПОЛНИЛ ЭТО ПОЛЕ НЕПРАВИЛЬНО, ПРИДУРОК. ИДИ ИСПРАВЬ». Ну, может, конечно, придурком вас напрямую не называют, но ощущение остаётся именно такое. Чем дальше мы сможем от этого уйти, тем лучше.

Попробуйте «позитивную» проверку. То есть, вместо того, чтобы говорить пользователю, когда он ошибся, сообщайте ему о том, что он сделал правильно.

Мне очень нравится форма на этом сайте. Посмотрите — они сообщают пользователю, что он с чем-то справился сразу вместо того, чтобы пост-фактум известить его об ошибке:
www.junkmycar.com

В этом повествовании я бы хотел описать свой собственный опыт в области домашней автоматизации на уровне любителя. В своих экспериментах я столкнулся с довольно простыми в использовании системами HomeMatic и X10, применение которых и хотел бы здесь затронуть.
В новостях часто появляются сообщения, что можно управлять чайником или новогодней гирляндой с iPhone (причем обязательно с iPhone, а то новость не будет понята воспринята массами). При этом у меня каждый раз появляется негодование: ну почему люди так бурно реагируют на такие сообщения? Ведь уже давно существуют решения, которые позволяют это сделать. При этом управлять домом из любого браузера, и да… с iPhone тоже!


WebFront

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

Зачем что-либо измерять?

Есть проект. Ваш любимый, родной, которому вы желаете расти и процветать.
Но как вы оцените его процветание, если нет критериев этого самого процветания?
Как вы сможете оперативно среагировать на проблемы до того, как они стали неисправимыми, если не будете использовать «датчик грядущей Ж»?
Как вы поймёте, что именно следует улучшать, если вам неизвестен источник проблем?

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

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

А если не приходят, значит метрику можно смело выбросить ;)

Поздравляю всех с пятницей и в качестве небольшого развлечения предлагаю представить, как бы выглядел популярный CSS-фреймворк Twitter Bootstrap, если бы он был от Google? Встречайте Plusstrap.