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

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

В статье Шитова (студия Лебедева) описан полноценно работающий fixed.
Дошли у меня руки до создания такого fixed и решил попользоваться предложенным решением.
Но оно не заработало. Начал изучать исходный код статьи (ну там то работает) и в итоге выяснил, что дело в DOCTYPE. Как известно Лебедеву на него положить, а я вот написал его. Именно он выключал fixed в IE.

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

«Совершенный Ajax» — новый подход к построению web-приложений, при котором web-сервер не генерирует ни строчки HTML-кода и взаимодействует с внешним миром только посредством web-служб; а клиентский интерфейс реализуется только на основе клиентских HTML, CSS, JavaScript.

Статья состоит из двух частей. В первой части — более живой и провокационной я постараюсь заинтересовать проблемой, рассказать о технологии «Совершенный Ajax» и показать ее применение на примере нашего проекта «Система Интерактивного Тестирования Знаний “Синтез”» (который имеет ряд интересных особенностей, таких, как использование серверного JavaScript на платформе Mozilla Rhino, прототипно-ориентированная ORM и поддержка SPARQL — языка запросов к Semantic Web).

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

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


Попробуйте угадать: к какой архитектуре относятся web-приложения?

К клиент-серверной говорите? Я ожидал, что Вы так ответите :-)

Что ж, давайте разберемся. В клиент-серверной архитектуре выделяют:

• Сервер — отвечает за хранение данных и реализацию бизнес-логики приложения.
  
  
• Клиент — отвечает за взаимодействие с пользователем ^[1].
  
  

Реализация бизнес-логики на сервере и взаимодействие с пользователем на клиенте четко разделены.

Преимущества клиент-серверной архитектуры очевидны; мы их все знаем:

1. Бизнес-логика не смешивается с пользовательским интерфейсом.
2. Можно реализовать несколько клиентов с разными пользовательскими интерфейсами: интерфейс командной строки, оконный Windows-интерфейс, Flash, web-интерфейс, мобильный интерфейс и т.д.
3. Клиентский компьютер не требователен к ресурсам;
4. И т.д.

Но, относятся ли web-приложения к клиент-серверной архитектуре?

Действительно, в web-приложениях есть сервер, отвечающий за бизнес логику приложения.

Но! За реализацию интерфейса отвечает не клиент, а тоже сервер. На сервере происходит обработка клиентской формы. Сервер генерирует HTML-код пользовательского интерфейса.

Клиент, т.е. браузер лишь визуализирует уже готовый HTML-код интерфейса. Это, фактически, то же самое, что прицепить к серверу монитор и объявить этот монитор клиентом…

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

Что такое представление?

Представление (VIEW) — объект базы данных, являющийся результатом выполнения запроса к базе данных, определенного с помощью оператора SELECT, в момент обращения к представлению.

Представления иногда называют «виртуальными таблицами». Такое название связано с тем, что представление доступно для пользователя как таблица, но само оно не содержит данных, а извлекает их из таблиц в момент обращения к нему. Если данные изменены в базовой таблице, то пользователь получит актуальные данные при обращении к представлению, использующему данную таблицу; кэширования результатов выборки из таблицы при работе представлений не производится. При этом, механизм кэширования запросов (query cache) работает на уровне запросов пользователя безотносительно к тому, обращается ли пользователь к таблицам или представлениям.

Как правило, реализация любой идеи начинается с обсуждения планов, графиков и прочих неотъемлемых компонентов серьёзного проекта. Впрочем, бывает и так, что люди без лишних разговоров просто делают то, что считают полезным, тем самым преподнося сюрприз окружающим. Один из примеров тому — практически полный перевод на русский язык цикла статей, входящих в курс Web Standards Curriculum, являющийся частью образовательного проекта Opera. Посему приглашаю всех заинтересованных в данных статьях, но не обладающих хорошими навыками владения английским языком, ознакомиться с русскоязычным вариантом. Уверен, что вы найдёте массу полезной информации, пригодной для использования в своих разработках и проектах.

Читать Web Standards Curriculum на русском

Эта статья о мирном атомеXSS. Заставим зло работать на добро!

А зачем?

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

Методы организации XSS

1. Через тэг iframe
2. Через тэг script
3. Через flash<->javascript
4. Через window.name + iframe + form
5. Через CSS хак
6. Через canvas + img
7. Через прокси

Знание истории происхождения вещей и их названий, будь то простой карандаш, автомобиль или команда операционной системы, делает их повседневное использование намного интереснее. В этой заметке я постарался разобраться в причинах странного, казалось бы, наименования некоторых программ, используемых в операционной системе Unix и её родственниках: *BSD, Solaris, HP-UX, Linux и т.д.

Перепечатка моей статьи, написанной, в свою очередь, по мотивам страницы What does {some strange unix command name} stand for?

Сия заметка, плод трудов хабра-человека sevenov, ему и почёт, дабы в будущем ему хватило кармы оставить свой след на хабре самому ;)

~~~~

Сегодня возник вопрос о том, как сделать вот так:



После получасового гугления наткнулся на несколько тикетов на code.djangoproject.com (ссылок сейчас не подкину, в истории искать лень). В общем, суть их в том, что нужно переписать чуть ли не половину Django. Немного подумав, я реализовал по своему. Возможно это кто-то уже делал, но на решение я не наткнулся.

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

Чем хороша такая система? Пожалуй тем, что она прозрачна и незаметна: пользователь перемещается по страницам ничего для этого не делая, просто читая новости в своём rss ридере. Есть, конечно у такого подхода и недостатки, но заметка не об этом.

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

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

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

Больше о проблемах, возникающих при хранении файлов отдельно от БД можно почитать в презентации SQL Antipatterns, раздел Phantom Files, страница 60. Кстати, автор презентации предлагает решение — хранить файлы прямо в БД, в поле типа BLOB. Правда следует замечание, что это должно быть взвешенное решение в каждом конкретном случае. Ведь при таком способе хранения файлов вебсервер должен при каждом запросе вызывать некий скрипт, который будет извлекать файл из БД и отдавать пользователю, что неминуемо отрицательно скажется на производительности.
Для поиска решения данной проблемы был проведен мозговой штурм и придумано несколько вариантов решения проблемы:

Решился потренироваться в написании jQuery плагинов, и вот предлагаю на суд общественности мой первый плагин…

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

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

XFS — начало разработки 1993 год, фирма Silicon Graphics, в мае 2000 года предстала в GNU GPL, для пользователей большинства Linux систем стала доступна в 2001-2002 гг. Отличительная черта системы — прекрасная поддержка больших файлов и файловых томов, 8 эксбибайт — 1 байт (8*2⁶⁰-1 байт) для 64-х битных систем. Ко всему прочему обладает другими немаловажными особенностями — непрерывные области дискового пространства, задержка выделения пространства и онлайн дефрагментация. Является одной из старейших журналируемых файловых систем для *nix, и содержит в себе наиболее отлаженный, в этом контексте, исходный код.

ReiserFS (Reiser3) — одна из первых журналируемых файловых систем под Linux, разработана Namesys. Имеет некоторые врождённые головные боли, но в целом неплохая система, ведущая отсчёт дней своих с 2001 года. Оговорюсь, что смысл журналируемых систем заключается в дисковых транзакциях, которые последовательно пишутся в специальную зону диска (журнал, он же лог), перед тем как данные попадают в конечные точки файловой системы. Максимальный объём тома для этой системы равен 16 тебибайт (16*2⁴⁰ байт).

В предвестии новой 10-й версии браузера Opera, в одноимённом сообществе опять встал вопрос «курицы или яйца» в отношении основы современного интерфейса браузера — панели адресной строки и панели ввода адреса.
Итак, основные действующие лица: панель адресной строки, панель ввода адреса, и, собственно, сама страница. Что к чему крепится логически и технологически, что удобнее, что привычнее в использовании?
Мне, как пользователю браузера Opera с многолетним стажем, естественно, кажется привычней адресная строка с кнопками навигации внутри вкладки. Так же мне это кажется логичным со всех сторон, и, к тому же, я встречал эту модель не только в Опере, но и в таких программах как Adobe Dreamweaver:

Очень тяжело начать писать статью. Т.е очень тяжело придумать вступительное слово. Хочется рассказать обо всём и сразу :) Но нет. Будем последовательны.
Начну с того что совсем недавно проходил Highload++ 2008 на котором мне удалось побывать.
Скажу сразу — мероприятие было проведено по высшему клаcсу, докладов было много и все были очень интересными.
Одной из самых запомнившихся презентаций была лекция Аско Ойя об инфраструктуре серверов баз данных в Skype. Лекция в большей степени касалась различных средств с помощью которых достигается такая производительность серверов.
По словам Аско, база данных Skype выдержит даже если все жители Земли захотят подключится к скайп в один момент.

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

UPD: Как правильно заметил хабраюзер descentspb в статье присутствует досаднейшая ошибка. В следствие своей невнимательности я подумал что PgBouncer надо устанавливать между прокси и клиентом. Но, как оказалось, та проблема которую я решал с помощью PgBouncer не решится если установить его именно так. Правильнее надо устанавливать боунсер между нодами и прокси. Мало того, именно так и рекомендуется делать в оффициальном мануале на сайте PL/Proxy.
В любом случае использование PgBouncer так как указано на моей схеме также даст прирост производительности. (Разгрузит Proxy).

Однажды холодной сибирской зимой начальство решило согреть нашу команду горячей начальственной любовью и передало в наши руки еще один проект. С первого же взгляда обнаружилось несколько серьёзных проблем:

• Это было написано на PHP;
• Это было написано на таком PHP, что **** **** ***;
• Захардкожено было всё, и ни о какой расширяемости или настраиваемости речи не шло. А ведь нагрузка росла не по дням.

В общем, как настоящие русские парни, мы решили все сломать к хренам собачьим и построить заново, сделав красиво. Почесав репу решили, что apache+modperl — это для старпёров и не интересно, а fastcgi — путь слабых духом, поэтому все будем делать на nginx + его вечноэкспериментальный встроенный перл.

Позже я почувствовал себя на густозасеянном разного размера глаблями поле…

Это перевод довольно новой статьи, которая вышла 4 июля 2008 года. Если вы уже читали ее, то навряд ли найдете что-то новое, но для тех, кто не знаком с оригиналом в статье найдется масса интересного. Сначала я хотел перевести и подписи к картинкам, но позже понял, что не стоит этого делать, так как статья ориентирована на грамотного читателя, который способен сам определить простейшие фразы.

UPD: Опубликована вторая часть статьи habrahabr.ru/blogs/ui_design_and_usability/45680

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

Тем не менее, разработка дизайна веб-форм — это не простое дело. И здесь есть одна простая причина: никто не любит заполнять формы — ни в оффлайне ни в онлайне. Следовательно, как дизайнеры, мы обязаны найти дизайнерские решения, чтобы сделать заполнение форм делом простым, интуитивным и безболезненным.

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

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

Данная статья — первая из цикла на тему укрощения CSS. Сегодня мы рассмотрим технологию CSS Reset.

Зачем это нужно?

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

Например, вы используете элемент a в вашем документе. Большинство браузеров, как Internet Explorer и Firefox, добавляют ссылке синий цвет и подчёркивание. Однако представьте, что через пять лет кто-то решил создать новый браузер (назовём его UltraBrowser). Разработчикам браузера не нравился синий цвет и раздражало подчёркивание, поэтому они решили выделять ссылки красным цветом и полужирным шрифтом. Именно исходя из этого, если вы установите базовое значение стилей для элемента a, то он гарантированно будет таким, каким вы хотите его видеть, а не как предпочитают его отображать разработчики UltraBrowser.

Добрый вечер, после написания предыдущего поста прошло уже, наверное, более трех недель, с тех пор мое направление немножко изменилось, да MVC хороший паттерн, но сейчас для js он еще слишком громоздкий. Мы стремимся выбрать более прозрачные и тонкие решения, которые бы позволяли видеть как все работает, вот почему мне нравится jQuery, он вводит тот самый минимум, который позволяет абстрагироваться от типа браузера, но при этом он не убирает ощущение того, что ты пишешь именно на js. Вот почему когда стремясь реализовать паттерн Document-View на js, хотелось сделать его как можно более тонким, незаметным и как мне кажется мне удалось добиться тех же легких ощущений, что все таки это тот же js, просто он немножко расширился.
Как и в WinForms, в jsForms все строится на компонентах. Итак приступим.