Перевод «Operating System Interface Design Between 1981-2009»

Графический пользовательский интерфейс (GUI — Graphical User Interface) это средства позволяющие пользователям взаимодействовать с аппаратными составляющими компьютера достаточно комфортным и удобным для себя образом.
В течении многих лет для большого количества операционных систем, таких как OS/2, Macintosh, Windows, AmigaOS, Linux, Symbian OS, и т. п., было создано еще большее количество графических интерфейсов.
Давайте попробуем взглянуть на эволюцию дизайна интерфейсов этих систем, начиная с 80-х годов.
Должен заметить, этот топик демонстрирует только значительные достижения и этапы в области графического дизайна (а не операционных систем в целом), да и не все системы существуют и по сей день.

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

Всем привет.

Боремся с пробками вместе

В рамках этого проекта в г. Красногорск, мы решили установить пару сетевых камер и сделать удобным просмотр потокового видео. Забегая вперед, результат можно посмотреть на нашем сайте или с мобильного телефона по wap www.ventumnet.ru/camera

С момента первого упоминания об AJAX в статье Джесси Джеймса Гарретта «Новый подход к разработке веб- приложений» 18 февраля 2005 года прошло уже 4 года. За это время наверно каждый веб- разработчик хоть раз испробовал эту технологию, и теперь обычного пользователя интернет уже не удивить динамической валидацией форм, автодополнением запросов в строке поиска, всплывающим контекстным меню и прочими ещё недавно диковинными вебдванольными интерактивными радостями, а современные JavaScript фрэймворки делают процесс разработки таких скриптов на порядок быстрей, эффективней и приятней для программиста. Но почему до сих пор подавляющее большинство разрабатываемых веб- сайтов придерживаются стандартной модели загрузки контента и не перешли полностью на AJAX платформу? Зачем каждый раз перезагружать всю страницу при нажатии на внутреннюю ссылку, когда нужно изменить только блок контента, а JavaScript файлы, CSS и большая часть HTML разметки не требует обновления?

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

Начало

Пару недель назад я заметил странную активность, направленную на мой DNS-сервер. Сразу скажу, что использую шлюз на Linux, соответственно там установлен DNS-сервер bind. Активность заключалась в том, что на порт 53 (DNS) моего сервера сыпалось по несколько UDP пакетов в секунду с различных IP-адресов:

10:41:42.163334 IP 89.149.221.182.52264 > MY_IP.53: 22912+ NS?. (17)
10:41:42.163807 IP MY_IP.53 > 89.149.221.182.52264: 22912 Refused- 0/0/0 (17)

Ни разу не слышал, чтобы наши (читай: совковые) вендоры коробочных CMS заказывали usability тестирование своих продуктов. Напрашивается два основных вывода:

1. Usability этих систем и так на высоте! В каждой компании есть свои usability специалисты, которые принимают участие в разработке на всех стадиях развития продукта – организуют тестирования, дают рекомендации, экспертную оценку и т.д. В таком случае это UDD – User-Driven Development.
2. Usability этих систем по-взрослому сосет. Программеры делают функционал. Дизайнеры делают дизайн. Маркетинг делает продажи. Программер думает об эклипсе. Дизайнер думает о фотошопе. Маркетолог думает о пауерпоинте. Ну а конечный пользователь периодически задумывается обо всех трех сразу – об их интеллекте, сексуальной ориентации и месте произрастания их передних конечностей. Это методология AUDD – Anti-User-Driven Development или Angry User Driven Development.

Если вам известны компании, которые работают по первой схеме, то дайте знать. На ребят, делающих все по второй схеме, я насмотрелся вдоволь, поэтому считаю полезной для всеобщего ознакомления публикацию «11 usability principles for CMS products» за авторством James Robertson. Далее позволю себе привести вольный пересказ списка из одиннадцати принципов CMS usability, которые выделяет Джеймс, с моими комментариями.

Хотел бы поинтересоваться у общественности о тонкостях становления Registred Apple Developer и о продаже через Apple Store в целом. Из того что я знаю:

• Для того чтобы продавать программы через Apple iTunes Store нужно купить участие в Apple Developer Connection за $99.
• Разработка только на Mac, Леопард. IDE бесплатно.

Дальше одни вопросы:

• Участие в Apple Developer Connection покупается за $99 через тот же Apple Store, но России в списке нет (насколько я понимаю они не работают в РФ). Предлагается отписаться в саппорт. Письмо автоматом пинают в европейское отделение, там они и гибнет: прошла неделя – ответа нет. Пытаться зарегаться в другой стране?
• У кого есть опыт покупки, чем там оплата? Российская Visa classic проходит?
• Если ты девелопер из штатов, с тебя удерживают налог. Если нет, то тебя просят это подтвердить, в какой форме? Насколько я знаю там нужно показать не пасспорт, а аналог штатовкого SSN. ИНН?
• Если программа продается, возможные варианты вывода денег? Только чеки или wire тоже возможен. Если первое, то сколько идет чек, и насколько просто его обналичить.
• Apple удерживает 30% с продаж. Какие еще минусы? Стоимость перевода чека?

Это продолжение, а точнее развитие, статьи написанной ранее.

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

Введение

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

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

На Хабре некоторое время назад спрашивали про курсы по оптимизации MySQL. Мы разработали такой курс и проводим его дистанционно через интернет. Вот программа курса.

Курс продолжается 2 месяца (начать можно в любое время) и построен на выполнении практических заданий под руководством преподавателя. Все задания взяты из реальной практики, преподаватель ответит на все возникающие вопросы. Действует гарантия 100% возврата средств в течение первых двух недель по первому требованию.

Кризис не самое оптимальное время, чтобы пиарить новую услугу, но это оптимальное время для получения новых знаний. Получить знания можно не только на нашем курсе, но и используя открытые источники:
I. Видеозаписи докладов на Highload++:

• Петр Зайцев, «Масштабирование InnoDB»
• Константин Осипов, «Масштабирование СУБД MySQL на системах с многоядерной архитектурой»,
• Ваш покорный слуга, «Архитектура MySQL Cluster»
• Василий Степанов, мастер-класс «Оптимизация работы с MySQL»

II. Статьи по оптимизации MySQL на webew.ru
III. Задать интересующий вопрос на форуме SQLinfo.ru

[ Часть I. Доставка видеоконтента ] [ Часть II. CDN своими руками ]

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

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

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

Такой шаг необходимо сделать при желании выйти на международный рынок, а также при региональном развитии внутри РФ. Сегодня в регионах очень часто самыми популярными сайтами являются региональные порталы, которые предоставляют различные сервисы, в том числе и сервис видеохостинга, а их популярность обусловлена как стоимостью трафика, так и скоростью доступа/временем отклика. Можно представить, что пользователь готов подождать открытия страницы, загрузки плеера, но тяжело предположить, что пользователь согласится смотреть видео, которые прерывается из-за постоянной буферизации, или смотреть вещание, которое доходит до пользователя в виде слайдшоу (после пропуска пакетов остались только опорные кадры видео).

Таким образом, осознав необходимость географической распределенности для контента, мы покупаем/арендуем сервера в непосредственной близости от потребителя: в Европе, США, Украине, Екатеринбурге и т.д.

Мы продолжаем исследовать тему такого класса ПО как очереди сообщений применительно к РНР веб-системам. В прошлой статье мы рассмотрели некоторое ПО, в частности представителей как самой верхней области (Apache Active MQ, возможности которого находятся на уровне уже корпоративного ПО), так и достаточно простые варианты, например, MQS. Но не рассмотренными остались еще несколько достаточно интересных проектов, так что наше исследование продолжается.

Quicky — hi-end шаблонизатор, написанный на PHP отличающийся гибкой функциональностью, и в то же время, высокой производительностью. За основу взят синтаксис и функционал Smarty.

содержание:
— переход со Смарти, на Quicky
— — чем Quicky лучше Smarty?
— Quicky быстрее PHP-native?
— Quicky темная сторона силы.
— Комьюнити Quicky. (теперь все тут http://code.google.com/p/quicky/)
— Богатые возможности Quicky.
— Вместо заключения. Личное мнение.

Поводом для написания данной статьи послужили некоторые дебаты в одной из групп linkedin, связанной с MySQL, а также общение с коллегами и хабролюдьми :-)

В данной статье хотел написать что такое вообще JOINы в MySQL и как можно оптимизировать запросы с ними.

Рано или поздно многие крупные проекты сталкиваются с проблемами производительности при постраничной навигации по записям. Некоторые из них решают эту проблему ограничением количества доступных для просмотра записей (скажем, не больше 1000). Вполне приемлемое решение. Но в этом случаем могут возникнуть проблемы с индексированием сайта сторонними поисковиками, которые и представляют наибольшую угрозу. В этой статье я хотел бы отказаться от привычной для всех панели навигации вида «1..2..3..4..» в пользу простой «вперед… назад» (будет проще объяснить), но это не проблема реализовать подобное и с первым вариантом.
Более точно определить тему, назвав, какое количество записей считать достаточно большим для появления тормозов, не получится, так как эта цифра для всех разная и сильно зависит от того, насколько быстрые у Вас жесткие диски, сколько памяти, и какая часть Ваших данных уже закеширована в ней и тд. Но если Вы и Ваши сервера ощущают, что n-ная страница при выводе даётся тяжелее первой, и при этом не знаете, что с этим делать – статья для Вас. Но для начала, я хотел бы на пальцах объяснить, почему ОНО работает медленно.

Кстати, тест происходит на виртуальной машинке, работаю я с СУБД под рутом, версия MySQL – 5.0.32.

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

Сейчас сервис ГеоКонтакт работает на территории около 500 населенных пунктов. У проекта уже сформировалось ядро из постоянных пользователей. Каждый день регистрируются 30-50 новых пользователей. Для старта это неплохой результат, учитывая, что мы не рекламируем сайт. Некоторые пользователи предложили безвозмездную помощь по включению их городов в зону действия сервиса.

В повседневной работе приходится сталкиваться с довольно однотипными ошибками при написании запросов.

В этой статье хотелось бы привести примеры того, как НЕ надо писать запросы.

По заявкам трудящихся решил написать еще одну статью, посвященную оптимизации запросов в MySQL.

В прошлой статье habrahabr.ru/blogs/mysql/38907 рассматривались вопросы оптимизации LIMIT, GROUP BY, COUNT.

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

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

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

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

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

К делу

Внешне задумка выглядит так: