В W3Cast #3 Денис ( CurlyBrace) затронул тему использования styleguides, а у меня как раз уже была статья по этой теме. Поэтому я решил поделиться ей, чтобы показать наглядные примеры, демонстрирующих возможности «стилевых гидов».
«Стилевые гиды» — это свод правил и соглашений, предоставляющих разработчикам информацию о структуре кода и принятых правилах оформления. Чаще всего используется группой разработчиков, при совместном участии в проекте или же для самодисциплины при разработке кода.
Если проект большой, то он обрастает многочисленными файлами CSS с различными цветовыми схемами, типографикой и другими стилевыми установками. Чтобы избежать путаницы в структуре кода и не забыть что да как, нужно разрабатывать структурированный код, который впоследствии будет проще использовать, править и частично использовать в других проектах.

Практически на каждом сайте нужно реализовывать меню. Обычно в этом нет никакой проблемы — заворачиваем все в ненумерованный список — ul, прописываем все наобходимые стили и готово.
Но очень часто дизайнеры, пытаясь создать очередной мегаопупительный макет, делают какие-либо 3D кнопки, либо кнопки с закругленными краями и кучей градиентов, либо еще что либо ужасное :)

Речь в данном топике пойдет о том, как реализовать такое меню, с учетом того, что размеры каждого пункта меню не фиксированны, то есть могут «тянуться».

С появлением новых проектов в сети иногда кажется, что задача эффективной организации пользовательских поддоменов (bob.someblog.com) кому-то представляется непростой. На самом деле, этот вопрос решается за одну минуту.
 

И так, дорогие друзья, я планирую открыть блог, посвящённый портальным технологиям.
Для разогрева, предлагаю вам коротенький рассказик, прочитав которую, вы узнаете что такое сервлет и зачем изобрели портлет. Места мало, обо всем напишу кратенько. Переписывать книжки, коих выпущено не одна сотня, я не собираюсь. Я буду писать о общих вещах, а так же о приёмах, которые существенно упрощают жизнь разработчику. Если вы хотите узнать больше, то лучше http://java.sun.com/javaee/index.jsp
вряд ли что-то может быть.
Приготовьтесь, вы ощутите мощь Java EE.

Как определить, что сайт сверстан качественно?
Есть много статей о том, как делать хорошо, но совсем нет – о том, как делать не надо, ведь даже валидный и кроссбраузерный сайт может быть сверстан отвратительно.

Из этой статьи вы узнаете:

• О плохих приемах современной верстки;
• О том, как даже не будучи профессионалом, за 5 минут определить плохо ли сверстан сайт или нет.

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

Существует много разных способов css разметки. Некоторые базируются на абсолютном позиционировании, другие используют float'ы. Первый метод плохо поддерживает «резиновость» макета, тогда как второй это неплохой способ разметки.

Но, как и многие мощные инструменты, float'ы имеют свои изъяны. Для начала, верстка на основе float'ов не такая простая к пониманию, а также float'ы есть источником многих багов (в основном в ИЕ), что делает их не идеальным вариантом в погоне за кроссбраузерностью.

Итак, речь далее пойдет о

Отчего-то всегда хотел сделать свой сервис для загрузки файлов. Всевозможные slil/zalil не устраивали своей скоростью. ifolder — обилием рекламы. Пользовался не очень популярным (от этого он ни чуть хуже не становился) сервисом up.spbland.ru. Но это как-то не правильно. И тут я решил написать свой сервис. Не буду вдаваться в подробности и рутину, только концепция.

Наверняка большинство программистов, работающих с современными веб-фрейворками, реализующими схему MVC, сталкивалось с таким небольшим затруднением: кэширование фрагмента View.

Хорошие фреймворки предлагают инструменты для полного кэширования страниц, фрагментарного, или кэширования экшенов. Недавно я посмотрел 90 выпуск подкаста Railscasts, посвященный именно фрагментарному кэшированию в Ruby on Rails и уважаемый автор решал проблему, как мне показалось, неоптимально.

Опишу ситуацию.
Мы в шаблоне страницы и хотим закэшировать ее часть, например, список новых товаров. Пока все хорошо, мы пользуемся встроенными во фреймворк удобными средствами и в две-три строчки окружаем блок — ура, он кэшируется. Но — чу!, контроллер-то об этом ничего не знает и продолжает выполнять свою работу по подготовке данных для View. Естественно, ведь проверка наличия кэша осуществляется уже из шаблона, а контроллер к тому моменту отработал.

Хочу еще раз поднять тему использования сессий для аутентификации пользователей. Надеюсь услышать критику приведенного в статье метода с высоты вашего опыта.

Хочу поделиться базой стран, регионов и городов на русском языке. Возможно, кому-то пригодиться в своих проектах. В базе 106 стран, 922 региона и 10969 городов!

Если кто не понял о чем речь, то вспомните, например, как на ВКонтакте указывается город: выбирается страна -> подгружается список регионов -> выбирается регион -> подгружается список городов

Однажды вечером я почувствовал, что пришло время расширить 97‐ й параграф «Ководства» Артемия Лебедева.

На клавиатуре одна чёрточка, она обычно правее нуля и повыше букв «З» и «Х». Неосведомлённые люди называют её попеременно то дефисом, то минусом, то тире. Лебедев объясняет нам, что это четыре (учитывая две разновидности тире) различных символа. На самом деле их как минимум девять, и об этом я и расскажу вам сейчас.

Ни для кого не секрет, что работа с базой данных занимает большую часть работы практически любого сайта. И именно работа с БД чаще всего является узким местом веб-приложений.
В этой статье хотелось бы дать практические советы использования MySQL.
Сразу оговорюсь:

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

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

1. Неиспользование или неправильное использование индексов.
2. Неправильная структура БД.
3. Неправильные \ неоптимальные SQL запросы.

Остановимся на каждой из этих групп подробнее.

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

Далее перевод :-)

Уф… наконец-то я решился написать свой первый пост.

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

Всем привет!
У меня есть проблема… Я работаю в небольшой IT-компании, рабочий день с 9 до 18, живу я в 20 минутах от работы, но тем не менее, раза два в неделю опаздываю на 5/10/15 минут (и я такой в офисе не один). Причин этого много, в основном просто просыпаю… Когда звонит будильник кажется, что можно подремать еще минут пять, в итоге встаешь через 10-20 и именно этих минут не хватает, чтобы успеть. Но, проблема, в принципе не в этом. Я работаю над самоорганизацией и определенные результаты есть.

Проблема в отношении начальства. Пока лично мне крупно не попадало, обычно все ограничивается не очень строгим выговором. Но вот коллегам угрожают снижением з/п или работой в выходные.
Хотелось бы услышать как с этим обстоит дело у вас, дорогие хабралюди. Как начальство имеет право покарать опоздунов, и как реально наказывает.
Ну и конечно советы по самоорганизации приветствуются :)

Я давно ломал голову, над тем, что бы такое всунуть в блог, чтобы выцедить скромную долю всемогущественной «кармы». И натолкнулся на насущную тему – мотивация меня любимого.

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

И так, что может быть проще? Надо ответить самому себе на вопросы:

1. Почему меня иногда просто тошнит от мысли о работе?
2. А почему же мне нравится это делать?

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

Достаточно давно я столкнулся с проблемой, что в хорошей и правильной программе TortoiseSVN (по-русски «тортойс эС-Ви-эН»), нету такой необходимой и желанной вещи, как экспорт только тех файлов, которые были затронуты определенными ревизиями. Особенно начинаешь страдать, когда приходится перезаливать на сервер весь проект, куда входят достаточно увесистые библиотеки и фреймворки. Можно, конечно, не включать библиотеки в Subversion, но это уже тема для другой беседы.
И вот, совсем недавно, один очень хороший гуру и друг совершенно ненавязчиво рассказал мне, как изящно и красиво решить эту проблему.

Внимание! Это все устарело, но публикацию не удаляю, чтобы все знали как мы мучались в 2007 году из-за IE6 :-)

Задача: сделать врезку с закругленными уголками с минимумом html-кода.

Как вы считаете, при автоматической переадресации (например, при логине на сайт) давать ли пользователю ссылку на страницу, на которую он будет переадресован, или это необязательно? Какой вариант предпочтительнее?

Вариант 1:
header ("Location: www.sitename.dom/page");
exit();

Вариант 2:
echo '';
die ("Redirecting to this page…");

Лично я раньше считал, что вариант 2 — однозначно правильнее, так как браузер пользователя может не поддерживать автоматическую переадресацию. Теперь я уже сильно в этом сомневаюсь, потому что таких браузеров практически не осталось — может, ими просто пренебречь? Минусы второго варианта очевидны: чтобы пользователь успел что-то прочитать, нужно хотя бы секунды три подождать, а это — время. Если сделать переадресацию через 0 секунд, перед пользователем промелькнут какие-то слова — меня лично такой шум раздражает.

Как вы считаете? По собственному или чужому опыту.