В этой статье я хочу рассказать об одном из способов построения CLI-приложений на Java.
Собственно сама потребность в таких приложениях никуда не делась — так, например, в моем случае это было приложение для проведения функционального и нагрузочного тестирования серверной части. Конечно же были варианты в проведении необходимых тестов при помощи набора JUnit-ов, но мы были сильно ограничены во времени и хотелось получить решение, не требующее программирования со стороны отдела тестирования. Тем более, что бинарный протокол по которому взаимодействовали клиент и сервер был четко специфицирован.

Идея

В этот раз мне сильно не хотелось изобретать велосипед в создании тривиальных для CLI-приложения вещей — парсинг строки ввода, выделение команды и аргументов, валидация аргументов, исполнение команды, вывод подсказок и тому подобное.
Было принято решение поискать готовые компоненты.

На Хабре не так давно была статья о commons-cli. Сам commons-cli мне не понравился своим 'деревянным' API, однако из комментариев к самой статье я узнал про несколько альтернатив в числе которых был JCommander.

Привлек внимание именно он, поскольку:

• Естественная поддержка паттерна Команда;
• Удобный способ определения параметров вызова, основанный на аннотациях;
• Автоматическое формирование помощи по доступным командам;
• Неплохая документация;
• Бесплатно.

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

Проверял лично и убедился в том, что исправно работает под следующими браузерами:

IE7+, Opera 10.5+, FF 3.6+, Chrome 12+ (linux), Chrome 13+ (windows), Safari 5+(win) исходя из личного опыта, предполагаю о том, что работать исправно будет во всех свежих версиях Safari, FireFox, Opera и Chrome.

С помощью CSS можно построить вот такие вот симпатичные варианты:

Доброго времени суток, хабражители!
Этот пост есть краткий конспект многих часов раздумий, каляк на бумаге, набросков кода и, в конце-концов, реально работающего кода в продакшене.
Наш сайт (и далее — просто сайт) активно использует мемкеш для горячих данных. Код, заполняющий мемкеш, может работать очень долго (0,5 секунд — это долго) и при этом пользовательские запросы успевают запустить ещё сотню процедур обновления. Последстия понятны, однако долго мы просто не могли их заметить на уровне общей нагрузки. Только когда мы увидели всплески времени на обслуживание некоторых запросов (от возросшей нагрузки они ещё и попадали в SLOW_QUERIES_LOG MySQL) — тогда и закипела работа.

Довольно полезным сервисом является создание полноразмерных скриншотов web-ресурсов.
Реализуем этот сервис буквально за 5 минут.

Задачи:

1) Создание полноразмерных скриншотов сайтов (полный скриншот по длине и ширине, а не захват окна браузера)
2) веб-интерфейс

Технологии:

— ОС — Ubuntu 10.04
— xvfb — Виртуальный фреймбуффер (Fake Xserver)
— CutyCapt — кроссплатформенная утилита для рендеринга web-страниц
— php — для веб-интерфейса

Нас всё время спрашивают: какова погрешность сбора данных в Google Analytics? Какому счетчику лучше доверять? Нельзя ли избавиться ото всех несовпадений и получить точные цифры посещаемости?

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

Практически никто не понимает, что неточный сбор данных — это не единственная ошибка, влияющая на результат анализа. Даже идеально собранные данные не позволят нам точно подсчитать нужные показатели на сайте (прежде всего, процент конверсии). Собранных данных может быть недостаточно! Это понимает каждый: если на сайт пришли всего 15 посетителей и ни один из них не заполнил форму заявки на кредит, о конверсии говорить рано. Так подсказывает нам здравый смысл; но в какой момент можно сказать, что данных хватает? Ждать ли еще 100 посещений? 200? 500?

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

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

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

Давайте создадим интерактивную карту. Чего-нибудь. Что значит интерактивную? Ну, она должна взаимодействовать с пользователем и с данными на веб-странице, на которой она расположена. Думаю, этого достаточно, чтобы считать её интерактивной.

Что же, и возьмём мы SVG. Почему? Да потому что с ним легко работать человеку, знакомому с HTML. SVG — это векторный формат, основанный на XML. То есть у SVG-рисунка есть своя DOM, к различным элементам можно применять CSS-правила и управлять старым добрым JavaScript'ом.

Что же, начнём?

Не так давно Яндекс.Метрика анонсировала открытый API, с помощью которого можно получить доступ практически ко всем функциям Метрики из собственной программы.
Сегодня я хочу немного рассказать об использовании этого API и о том, как на его основе создать простой widget для Android-устройств.

Привет, хабр!

О StartSSL я узнал от небезызвестного lissyara, в связи с чем ему очень благодарен.

Для начала расскажу, что же за зверь это. Как известно, SSL сертификаты выдаются центрами сертификации, чьи корневые сертификаты хранятся в хранилище сертификатов браузера\ОС (либо другого ПО, использующего SSL). Цена на большинство сертификатов зашкаливает, и платить приходится за каждый сертификат. Но у StartSSL весьма интересный подход — сами сертификаты у них бесплатные, вы платите только за проверку вашей личности.

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

Riak это NoSQL решение, честная DHT (key/value storage) с дополнительными возможностями для разруливания конфликтов.

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

client a: def o-value = DHT.get("some-key");
client a: def a-value = changeValue(o-value);
client b: def o-value = DHT.get("some-key");
client a: DHT.put("some-key", a-value);
client b: def b-value = changeValue(o-value);
client b: DHT.put("some-key", b-value);

Получилось, что клиент b переписал данные клиента a и никто об этом не знает (ни a, ни b, ни тот, кто прочтет данные по этому ключу позже).

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

Например, MongoDB использует compare-and-swap стратегию: с каждым документом (значением) храниться его версия, при обновлении указывается версия «предка» измененного документа, если в базе в момент обновления храниться предок, то обновление проходит, если нет, то нет: обновляющая сторона получает сообщение, и пытается провести обновление снова — аналог STM. Такой подход хорошо работает с шардами, но плохо с репликацией.

Riak решает проблему конкурентного доступа подобно системам контроля версий, он, как бы, сохраняет конфликтные версии в разных бранчах, предоставляя программе при следующей выборке провести merge. Такой подход позволяет разрешать конфликты, связанные не только с конкурентным доступом, но и с времянной изолированостью части кластера (partition tolerance: кластер машин может распаться на две части, обе части будут работать и смогут без проблем объединиться в будущем).

Riak накладыват больше условий на разработку, но обеспечивает масштабируемость и надежность данных при работе с большим объемом информации. Статья опишет, как «обойти» ограничения Riak при разработке типичных web приложений.

Оптимизация явно не является коньком MySQL сервера. Цель данной статьи объяснить разработчикам, которые плотно не работают с базами данных и иногда не понимают, по какой причине запрос, который успешно отрабатывает в других СУБД, в MySQL безбожно тормозит, каким образом оптимизируется конструкция between в MySQL.
MySQL использует rule based оптимизатор. Зачатки cost based оптимизации в нем конечно присутствуют, но не в должной мере, в какой их хотелось бы видеть. По этой причине часто мощности получаемых после применения фильтров множеств вычисляются неверно. Это приводит к ошибкам оптимизатора и выбору неверного плана выполнения. При чем полученные between оптимизации невозможно изменить явным указанием: индексов для выполнения запроса и порядка соединения таблиц.

Метод критической цепи: эффективное управление проектами с использованием буферов времени и ресурсов

Работа стремится занять все время, отпущенное на нее.
Закон Паркинсона.
Если какая-нибудь неприятность может произойти, — она случается.
Закон Мерфи.

Немного статистики

Одной из причин выделения управления проектами в отдельную область знаний является неопределенность. То, как мы управляем неопределенностью в проекте (в том числе и рисками), напрямую влияет на длительность проекта, на его успех.
По данным многочисленных исследований Standish Group¹ для традиционных методов управления проектами, только 44% проектов обычно завершаются вовремя. В среднем проекты занимают 222% процента от изначально запланированной длительности, 189% от начального бюджета. 70% проектов сокращают исходный объем работ проекта, 30% проектов закрываются досрочно.
И хотя в последнее время, с развитием инструментов и техник управления проектами, эти цифры стали уменьшаться, общая картина говорит о том, что мы как менеджеры проектов плохо делаем свою работу.
Данная статья рассматриваем использование относительно новый метод управления проектами, метод критических цепей (МКЦ), сравнивая его с традиционным подходом к управлению проектами.

Распределенные системы контроля версий (DVCS) постепенно замещают собой централизованные. Если вы еще не используете одну из них — самое время попробовать.

В статье я постараюсь показать, как можно быстро начать экспериментировать с git, используя сайт github.com.

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

Есть задачи, которые в рамках реляционных СУБД не имеют универсальных решений и для того чтобы получить хоть какой-то приемлемый результат, приходится придумывать целый набор костылей, который ты потом гордо называешь “Архитектура”. Не так давно мне как раз встретилась именно такая.

Предположим, имеется некоторые сущности А и Б, связанные между собой по принципу One-to-Many. Количество экземпляров данных сущностей достаточно велико. При отображении сущностей для пользователя необходимо применить ряд независимых критериев, как для сущности А так и для сущности Б. Причем результатом применения критериев являются множества достаточно большой мощности — порядка нескольких миллионов записей. Критерии фильтрации и принцип сортировки задается пользователем. Как (я бы ещё спросил: Зачем им миллионы записей на одном экране? — но говорят надо) показать все это пользователю за время 0 секунд?
Решать такие задачи всегда интересно, но их решение сильно зависит от СУБД, под управлением которой крутится твоя база данных. Если у тебя в рукаве козырной туз в виде Oracle, то есть шанс, что эти костыли он подставит сам. Но спустимся на землю — у нас есть только MySQL, так что придется почитать теорию.

Этот материал продолжает серию ежемесячных обзоров свежих статей по теме интерфейсов, новых инструментов и коллекций паттернов, интересных кейсов и исторических рассказов. Из лент нескольких сотен тематических подписок отбирается примерно 5% стоящих публикаций, которыми интересно поделиться. Предыдущие материалы: апрель 2010-май 2011.

Пользуясь юбилеем — как раз в августе, 10 лет назад был опубликован^[1] The Agile Manifesto еще раз предлагаю сейчас, в летнее затишье, загрузить на будущее в себя немного Agile (когда пойдут дедлайны, будет уже не до этого).

А именно, посмотреть-почитать материалы докладов с прошедшей в Москве конференции AgileDays-2011. Далее, будет небольшое пояснение, почему эти материалы интересны, смотрибельны и читабельны, а также аннотированная тематическая классификация докладов, с ссылками на материалы — видеозаписи, слайды, рецензии и т.п.

Автор: Кристина Бьоран
Источник: www.uxbooth.com/blog/psychological-manipulation-in-ecommerce-design

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

В июле 2011 года в одном из выпусков интернет-издания Wired, профессор психологии и специалист в области поведенческой экономики, Дэн Ариели, опубликовал статью на тему психологических приемов, используемых сегодня несколькими крупнейшими веб-сайтами. В этой статье, которая называлась «Gamed» («Пойманные»), автор продемонстрировал, как такие сайты, как Amazon и Groupon, при помощи элементов дизайна стимулируют определенные сценарии поведения, направленные на осуществление покупки.

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

[('съешьте', 'глаг.'), ('еще', 'нареч.'), ('этих', 'местоим. прил.'), ('мягких', 'прил.'), ('французских', 'прил.'), ('булок', 'сущ.'), ('да', 'союз'), ('выпейте', 'глаг.'), ('чаю', 'сущ.')]

Зачем это нужно? Например, для автоматического определения тегов для блог-поста (для отбора существительных). Морфологическая разметка является одним из первых этапов компьютерного анализа текста.

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

Если вы сами проводили конкурсы и всё было ок — не читайте топик. Если где-то ждал облом — добро пожаловать под кат.

Уважаемые хабровчане, представляю вам вольный перевод статьи Avoiding common HTML5 mistakes. Здесь мы рассмотрим частые ошибки в HTML5 разметке с точки зрения семантики, и как их избежать.