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

Доброго времени суток!

Введение

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

Я хочу описать простой минималистский подход к разработке сложных JavaScript приложений. Из внешних библиотек будут использоваться только jQuery и мой js-шаблонизатор, причём из jQuery используются только $.ready(), $.ajax() и $.proxy() — т.е. суть не в библиотеках (их тривиально заменить на предпочитаемые вами), а в самом подходе.

В основе подхода лежат две идеи:

1. JavaScript виджеты — небольшие модули, каждый из которых «владеет» определённой частью веб-странички (т.е. всё управление этой частью странички происходит исключительно через методы этого модуля, а не через прямую модификацию DOM — инкапсуляция). Виджет отвечает исключительно за функциональность, но не за внешний вид; поэтому прямая модификация части DOM, которым «владеет» виджет, снаружи виджета допускается — но только для чисто дизайнерских задач (для архитектуры и общей сложности приложения нет принципиальной разницы между коррекцией внешнего вида через CSS или jQuery).
2. Глобальный диспетчер событий. Взаимодействие между виджетами осуществляется путём посылки сообщений глобальному диспетчеру (слабая связанность, паттерн Mediator/Посредник), а уже он принимает решение что с этим сообщением делать — создать/удалить виджеты, дёрнуть методы других виджетов, выполнить дизайнерский код, etc. В отличие от динамического подхода к обработке событий (когда обработчики конкретного события добавляются/удаляются в процессе работы) статический диспетчер сильно упрощает понимание и отладку кода. Безусловно, есть задачи, для которых нужны именно динамические обработчики событий, но в большинстве случаев это избыточное усложнение, поэтому всё, что можно, делается статическими обработчиками.

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

Если бы вы могли вернуться в прошлое, к самому началу своей карьеры разработчика и сказать самому себе: «прочитай именно эту книгу», в самой начале своей карьеры разработчика, какую бы книгу вы рекомендовали?

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

Однако в данном небольшом посте я возьму на себя смелость перечислить ТОП-5 тех самых книг, победивших в голосовании, переведенных на русский язык. И дать небольшие комментарии, ведь книги действительно этого достойны. Да, лично я бы поменял некоторые места, однако положимся на «мнение зала» ресурса Stack Overflow.

Вступление

Я, как руководитель проектов, всё больше и больше замечаю, что эффективность работы команды (и каждого программиста в частности) – это ключевой фактор, определяющий успех проекта. При эффективной работе даже самые тяжёлые проекты со сжатыми сроками удаётся завершить успешно, а неэффективная способна «завалить» простейшие проекты с минимумом рисков. Поэтому, я хотел бы поделиться своими мыслями об одном из ключевых понятий – понятии «работы потоком».

В не столь давно вышедшей версии jQuery 1.7 появился новый объект Callbacks, о котором сегодня и пойдёт речь.
В официальной документации jQuery.Callbacks описан, как многоцелевой объект, представляющий собой список функций обратного вызова (callbacks — далее просто колбэков) и мощные инструменты по управлению этим списком.

Я просматривал возможности этого объекта, когда он был ещё только в разработке, и надо сказать, что возможностей у него изначально было немного больше, чем осталось в релизной версии. Например, сейчас отсутствует возможность создания очереди (queue) колбэков, которые вызываются по одному на каждый вызов fire(). Видимо, команда jQuery, решила немного подсократить код, убрав «ненужные/редкоиспользуемые» возможности, чтобы сэкономить в весе библиотеки. Это маленький экскурс в историю Callbacks, но далее я буду описывать только доступные сейчас функции и в конце напишу небольшое возможное улучшение этого объекта.

Известно, что следуя идеям старой школы, а именно, добавляя ссылки на JS и CSS в страницы, может обернуться большим временем загрузки страницы. Браузер отображает страницу по мере скачивания, но останавливается, если натыкается на тег script со ссылкой, до того момента, пока скрипт не будет загружен и выполнен. Сайты стали использовать всё большее количество скриптов, начальное отображение страницы занимает всё больше времени, к примеру, на этой странице, которую вы читаете, 13 скриптов, 7 из которых находятся в head'е. Ко всему прочему, некоторые браузеры по-прежнему придерживаются ограничений на одновременное количество загрузок с одного хоста.

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

Существует несколько решений, как то:
— поместить стили и скрипты прямо в страницу;
— установка аттрибутов async/defer тегу script;
— склеить все скрипты в один файл;
— помесить ссылки на скрипты в конец body;
— разместить все файлы на CDN/на разных хостах;
— свой вариант…

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

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

Начитавшись в интернете про новые, простые, быстрые и масштабируемые технологии, захотелось их всех попробовать. Вдруг они окажутся лучше уже привычной мне связки postgresql + django + json-rpc.

Идея проекта

Так как никакой идеи не было, но был свободный домен uglyrater.org — пришлось делать рейтинг.
Суть проста: есть список пользователей, которым можно расставить + и -. Новые пользователи в рейтинг добавляются по адресу страницы ВКонтакте.

PHP-фреймворк Webasyst, ориентированный на создание веб-приложений с бекендом и бизнес-приложений, теперь стал полноценной CMS-кой. С помощью системного приложения «Сайт» на фреймворке можно создавать сайты. Приложение бесплатное (LGPL).



Обычно в «классических» CMS всегда используются два понятия: 1) общий макет и 2) встраиваемые в него отдельные модули (ленты новостей, облака тегов, блоги, магазины и т.д.). Мы пошли несколько нестандартным путем и приняли другую архитектуру: адресное пространство, отведенное сайту, разделяется между независимыми приложениями без «навязывания» им общего макета. То есть не модули встраиваются в общий макет, а каждый модуль (в нашем случае приложение) использует свой собственный макет (тему оформления).

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

Ровно три месяца назад, 27 сентября, мы объявили Хабрасообществу о старте нашего проекта. Больше всего комментариев и пожеланий тогда мы услышали о необходимости реализации посайтового учета времени проведенного в различных браузерах.

Итак, приступим пожалуй. Я люблю Scala не только за то, что она позволяет писать в два раза меньше кода, чем на Java. Понятного и выразительного кода. Помимо этого на Scala можно делать вещи вообще недоступные разработчикам на Java: generic’и высшего порядка, узнавать типы generic’ов в runtime при помощи манифестов.

Одна из таких вещей, о которой пойдёт речь — это компиляция Scala-кода во время исполнения программы. Это может быть нужно, когда хочется выполнить приходящий из удалённого источника код или написать самомодифицируемую программу, аналог функции eval в JS.

Введение

Доброго времени суток! Сразу оговорюсь, что цель этой статьи — познакомить и, возможно, заинтересовать вас такой штукой, как мнемоника. Мнемоника — наука о запоминании. То бишь совокупность способов и уловок, которые помогут вам запомнить большие объёмы информации в правильной последовательности (Например, 100 случайных слов (чисел) можно запомнить последовательно с интервалом в среднем в 6 секунд). Некоторые умудряются запомнить несколько тысяч цифр после числа Пи. Так же мнемотехника помогает в освоении иностранного языка ). Но нам пока рано об этом думать. Вы спросите:«Зачем мне ета ваша мнемоника?». Я отвечу: вы можете использовать её не только как хобби (от простого облегчения жизни, до того, что можете удивлять друзей, предложив с ними поочерёдно запомнить N информации поочерёдно), но и участвовать в соревнованиях (да-да, есть соревнования по запоминанию, где участвуют не прирождённые гении, а люди, натренировавшие себе память).

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

Например, встречались такие варианты:

if ($error['type'] == E_ERROR || $error['type'] == E_PARSE || $error['type'] == E_COMPILE_ERROR){…}

или

if(in_array($error['type'], array(E_ERROR, E_PARSE,  E_COMPILE_ERROR)) {…}

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

Те, кто до этого времени использовали класс vk.wallpost.php, возможно, столкнулись с проблемой работы данного скрипта на хостинге. Данный класс был написан пользователем xbreaker и подробно разобран по частям в статьях: Часть 1 и Часть 2.

Скрипт замечательно работает на локальном компьютере. Но когда его закидываешь на хостинг он перестает отсылать сообщения.

Уходя от использования роутинга в .htaccess файле, в первую очередь пришёл к стандартному направлению на index.php: разбирал там URL и вызывал соответствующие контроллеры — долгое время был доволен такой техникой. Однако совсем недавно осознал, что что-то делаю не так, что можно сделать эффективнее и лучше.
Далее я расскажу о своём роутинге, использующем XML для хранения правил и в последующем использующем его сериализованный вид.

Эта статья является второй из серии статей о нововведениях на сайте Государственной Думы (статья 1).

В настоящий момент набирает популярность концепция open government («открытое государство»). К примеру, на сайте data.gov публикуются большие объемы данных государственных ведомств США, а на сайте data.gov.uk публикуются аналогичные материалы Великобритании. Важным аспектом публикации структурированной информации является возможность её получения в машиночитаемом виде. Понятно, что и HTML таблицу можно достаточно успешно распарсить, но предоставление информации в удобном для интеграции с внешними системами виде — очень важный показатель открытости. Поэтому, разработка API для системы поиска по законопроектам стала важным этапом реализации концепции «открытое государство» в рамках сайта Государственной Думы. Теперь данные о законопроектах могут быть легко интегрированы во внешние информационные системы. Например, аналитический портал может рядом со статьей, посвященной тому или иному законопроекту, разместить виджет, который будет отражать актульную информацию о ходе рассмотрения законопроекта.

Добрый день. Несколько дней назад появилась необходимость использовать слайд-шоу на своём сайте, но оно должно было быть нестандартным, чтоб привлекало внимание пользователей. Искал в течение дня и ничего нормального не мог найти, были более менее подходящие «слайдеры», но душа хотела клубнички. После того как я облазил весь рунет, переключился на «забугорных» друзей и… удача! Забегая наперёд хочу сказать: этот обзор сделан потому, что в рунете нет никакого упоминания про это слайд-шоу, отсюда и логика.

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

• как установить рабочее окружение Node.js на своем компьютере;
• как писать код;
• как отлаживаться;
• как развернуть то, что получилось на удаленном сервере.

А тесты производительности в конце статьи возможно дадут ответ на вопрос зачем собственно вам может понадобится изучать Node.js.

Данный пост является началом серии статей про оптимизацию и улучшение производительности GWT-приложений. Поскольку материала у меня накопилось достаточно много, решил разбить его на 2-3 части.
Приступим к описанию того, что нас ждёт в первой статье.

Последние четыре года я работал верстальщиком в разных питерских веб-студиях.

От полуподвальных контор из 3-5 человек до больших фирм 25-40 человек, работающих на рынке дорогих сайтов для крупных заказчиков. Но независимо от размера компании задачи были одни и те же.

• нужно продать дизайн
• сделать сайт, который не стыдно положить в портфолио
• сделать оригинально, как еще не делали конкуренты

Таким образом, задачи верстальщикам и дизайнерам ставились одинаковые: «давайте что-то креативное, свежее, интересное».

Я очень хорошо понимаю верстальщиков, дизайнеров и владельцев веб-студий, поэтому чтобы облегчить им поиск плагинов под готовый функционал и в то-же время показать что-то свежее, чего еще многие [возможно] не видели, решил уволиться отовсюду, и запустить проект Plugin Detector



В этой статье будет затронуто: