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

На Хабре достаточно много разработчиков работают с файлами на удаленных хостах. На локальной машине запускается IDE, отладчик, все необходимое, а сами файлы находятся на сервере, где они регулярно бакапятся, автобилдятся, тестируются и так далее. Очень удобный рабочий вариант. Да я сам его использую.
Единственная проблема, доставляющая неудобство — файлы все же находятся на другом компе, и доступ к ним не такой простой и прозрачный как к «своим».
Под катом — как сделать такой доступ максимально удобным. Чтобы он запускался автоматом когда надо, а самое главное — чтобы не запускался, когда не надо!

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

Недавно появился миниатюрный Linux-сервер — «Linux сервер в виде блока питания», изготовленный на system-on-chip (SoC) Marvell Sheeva CPU 1.2GHz с ARM-архитектурой.
Этот сервер вроде бы предназначен не для конечных (домашних) пользователей, и тогда возникает вопрос: зачем было этот сервер делать в виде блока питания под обычную домашнюю розетку?
Неужто нельзя было бы сделать его в виде маленького «Лезвия» — «Blade-сервера» для серверной стойки!
Вы только представьте как вы у своего хостера, разместите в стойку маленький Marvell`овский сервер, стоимостью всего 50$. Или же сам Хостер предложит вам новый сервис — размещения вашего сайта на таком маленьком и дешевеньком, но полноценном и независимым от всех соседей, сервере!
Для не очень больших сайтов (наверно до 10 — 20 одновременных сессий, а это ~ до 10 тысяч посетителей в день) его мощности должно вполне хватать (ну может только Flash-диск хотелось бы расширить, хотя бы до 2 — 4 Gb).
А для больших сайтов, надо объединять 100-ни и 1000-чи такие маленьких Blade`ов в единый кластер (чем например Google, обычно у себя занимается).
И каждый ваш сайт тогда от ныне будет иметь «не виртуальный», а свой полноценный — сервер!!!

Данная статья была создана по мотивам презентации, сделанной на конференции SQA Days. Статья впервые опубликованна на GUI.ru и теперь хотелось бы обсудить usability guideline с хабралюдьми

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

Что следует понимать под юзабилити? Определение юзабилити приведено в стандарте ISO 9241-11 как степень эффективности, продуктивности и удовлетворенности, с которой продукт может использоваться определёнными пользователями для достижения определённых задач в определённом контексте.

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

SET @mytable='users';
SELECT * FROM @mytable;

Такая конструкция работать не будет. А что же делать, чтобы она заработала?

Задача — сделать профиль пользователя доступным через example.com/user/username и через пользовательский поддомен username.example.com. Задача простая и с помощью Zend Framework решается парой строк кода. Трудности начались тогда, когда я решил действия регистрации, подтверждения регистрации, востановления пароля и собственно входа/выхода поместить в тот же контроллер, который выводит профиль пользователя. Теперь возникла задача научить контроллер не воспринимать example.com/user/register как пользователя.

Вступление

Забавно, но когда программист разрабатывает какой-либо продукт, он редко задумывается над вопросом могут ли на одну кнопку в один момент времени нажать одновременно 2000 человек. А зря. Оказывается могут. Как ни странно но большинство движков, написанных такими программистами, очень плохо ведут себя под большими нагрузками. Кто бы подумал, а всего один лишний INSERT, не проставленный index, или кривая рекурсивная функция могут поднять load averages чуть ли не на порядок.

В этой статье я опишу как мы, разработчики проекта, сумели выжать из одного сервера с Pentium 4 HT / 512Mb RAM, максимум, держа одновременно 700+ пользователей на форуме и 120,000 на трекере. Да, проект этот — торрент трекер. Предлагаю сразу оставить в стороне разговоры о копирайтах и правах, мне это не интересно, что действительно интересно — это HighLoad.

throw new Exception or not throw new Exception, вот в чём вопрос!

Доброе время суток!

Когда же использовать технологию исключений? Когда лучше воздержаться и стоит ли воздерживаться?

После моей статьи «Freelance: ожидания, реальность, признание» сразу несколько человек обратилось ко мне с вопросом о юридических проблемах в работе freelance'ра. Скажу сразу, я далеко не юрист, но в свое время оформлял себе ИП, именно для freelance'а, а потому имею опыт, и некоторые знания в этой сфере, и могу ими поделиться. Хотя конечно мои выводы могут быть ошибочны, и у юристов эта статья наверняка вызовет легкую улыбку (или приступ раздражения), скажу еще раз, я просто хочу поделиться опытом, и рассказать как я регистрировался в качестве предпринимателя, и что мне дала эта бумажка.

Перевод отличной статейки. Думаю, будет полезна как новичкам, которые только приступили к использованию jQuery, так и тем, кто уже какое-то время с ним работает. А кого-то, возможно, заставит глянуть эту чудесную библиотечку. Многие советы имеют отношение не только к jQuery, но и к JavaScript в целом. Лично для меня была весьма и весьма познавательной, посему и захотелось донести это «до масс». Перевод не дословный, но передающий смысл и максимально адаптированный к русскому языку.

Далее все написано от имени автора оригинальной статьи.

Введение

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

Я не эксперт в jQuery. И даже не претендую, поэтому, если встретите ошибки, смело поправляйте меня и вносите предложения по улучшению (поправлять и присылать поправки нужно автору статьи, а не перевода — зам. пер.).

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

Содержание

1. Загружайте фреймворк с Google Code
2. Используйте «шпаргалку» (cheat sheet)
3. Соединяйте все ваши скрипты и уменьшайте размер файла
4. Используйте возможности Firebug для ведения логов
5. Минимизируйте операции выборки в пользу кэширования
6. Сводите манипуляции с DOM-деревом к минимуму
7. Оборачивайте все в единый элемент, когда речь идет о любой вставке в DOM
8. Используйте «id» вместо классов, где это возможно
9. Задайте контекст своим селекторам
10. Используйте последовательности вызовов методов с умом
11. Научитесь правильно использовать анимацию
12. Научитесь назначать и делегировать события
13. Используйте классы для сохранения состояния
14. Еще лучше — используйте встроенный в jQuery метод data() для сохранения состояния
15. Пишите собственные селекторы
16. Подготавливайте HTML и модифицируйте его, когда страница загружена
17. Используйте «отложенную загрузку» (lazy loading) для определенного контента для выигрыша в общей скорости и преимуществ для SEO
18. Используйте служебные функции jQuery
19. Используйте «noconflict» для переименования глобального объекта «jquery», когда используете его с другими фреймворками
20. Как узнать что картинки загружены?
21. Всегда используйте последнюю версию
22. Как проверить, что элемент существует?
23. Добавляйте класс «JS» в элемент «html»
24. Возвращайте «false» для отмены поведения по-умолчанию
25. Короткая запись для события готовности документа

Готовим макет для клиента. Часть II: Если гладить, то как?

Часть I: Гладить или нет?
Часть II: Если гладить, то как?

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

Готовим макет для клиента. Часть I: Гладить или нет?

Часть I: Гладить или нет?
Часть II: Если гладить, то как?

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

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

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

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

Часть I — Часть II — Часть III — Часть IV — Часть V — Часть VI

Часть V

Очевидно, что в сфере высоких технологий развитие зачастую происходит быстро и бурно. Так произошло и со средствами отображения информации. В течении каких-то двух-трёх лет обычные ЭЛТ-мониторы почти целиком и полностью были вытеснены стремительно дешевеющими ЖК-собратьями. Что позволило существенно улучшить как геометрию отображения, так и цветопередачу, а также снизить утомляемость глаз за счёт отсутствия вредного мерцания. И если несколько лет назад подобное утверждение в пользу TFT-панелей можно было бы оспорить, то теперь этот факт не вызывает ни у кого сомнений: ЖК-дисплеи намного лучше для повседневной работы рядового пользователя. В связи с этим фактором возникла необходимость поиска качественно новых алгоритмов отображения шрифтов. Одно из таких решений пусть не сразу, но всё же получило определённое признание в среде пользователей, и на сегодняшний день является чуть ли не самым популярным на современных платформах. Речь, конечно же, о технологии рендеринга ClearType, которая послужила причиной разработки новых веб-ориентированных шрифтов…

Часть I — Часть II — Часть III — Часть IV — Часть V — Часть VI

Часть IV

Итак, настала пора выяснить, какие шрифты и с какой долей вероятности могут оказаться установленными в тех или иных операционных системах либо в результате каких-то особых ситуаций (например, при установке пакетов Microsoft Office, Adobe Creative Suite или CorelDRAW! Suite), либо в «девственно чистых» ОС (что, несомненно, наиболее приемлемый вариант). А также узнать, какие из этих шрифтов пригодны для использования и в каких конкретно случаях.

Часть I — Часть II — Часть III — Часть IV — Часть V — Часть VI

Часть III

Оказалось, что аж ещё со времён Windows 98 в стандартный комплект включается шрифт под названием Lucida Sans Unicode, который особо нигде не используется. Попробуем заменить им эппловский Lucida Grande.

Часть I — Часть II — Часть III — Часть IV — Часть V — Часть VI

Часть II

Во-первых, увеличились размеры экранов, улучшилась чёткость отображения и качество передачи цветов. В наше время всё реже используются старые ЭЛТ-дисплеи с небольшим разрешением, выпуклым экраном, мерцанием или ограниченной цветопередачей (помните CGA/EGA/VGA?). Фактически, количеством таких мониторов по сравнению с современными плоскими ЖК-дисплеями уже сегодня можно смело пренебречь. Изменились и негласные стандарты de facto и для разрешения: если в самом начале сайты создавались под размер экрана в 640х480 пикселей, потом для 800х600, то сегодня используется стандарт 1024х768. С появлением широкоэкранных (wide) мониторов начал было маячить новый стандарт 1280х960, но большую популярность в последнее время приобрели компактные устройства вроде Asus eeePC или Apple iPhone, так что не исключён факт возвращения в качестве стандарта разрешения меньшего, чем 1024х768. Впрочем, в данном случае это не столь важно, поскольку в любом случае на сегодняшний день разрешение экрана напрямую зависит от его физического размера, а величина одной отображаемой точки достаточно мала по сравнению с пикселями десятилетней давности, что позволяет на любых современных устройствах отображать шрифты одинаково качественно. Это, кстати, приводит и ко второму фактору.

Часть I — Часть II — Часть III — Часть IV — Часть V — Часть VI

Часть I

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

Итак, какова ситуация в области современной веб-типографики и какими способами следует решать возникающие проблемы?

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

Данной статей я хочу начать серию, посвященную всеми любимому Add-on к Firefox под названием Firebug.

Весь цикл: Console, Commands, Debugging ,Profiling

Я постараюсь раскрыть известные и не очень его возможности, которые могут пригодиться любому Web-разработчику(а могут и не пригодиться, но это врядли).

Если у вас его еще нету, то можно скачать со страницы http://getfirebug.com.