Более месяца назад в статье FAQ по JavaScript: задавайте вопросы был задан вопрос «Подскажите примеры хорошего подхода организации JS кода к сайту на достаточно высоком уровне. Как можно узнать подробнее практики реализации например gmail?».

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

Эта статья о том, как сделать крупное веб-приложение расширяемым и поддерживаемым: архитектура, подходы, правила.

Однажды, nickivanov нарисовал миниатюры для кучи разных флагов и выложил их в свободный доступ. А недавно, artpolikarpov собрал их в один спрайт и написал к нему удобный css, который позволяет легко отобразить любой флаг просто указанием нужного класса.

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

И был бы этот топик топиком-ссылкой, да по необъяснимым причинам не разрешает Хабр в топиках-ссылках указывать авторов, заслуживающих похвал. Так что вот они ссылки:
Описание: artpolikarpov.ru/projects/flags
Архив с флагами: artpolikarpov.ru/projects/flags/flags.zip

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

Что такое спам? Это 80% почтового трафика в интернете и 20% эффективности. Обычная, грамотно сделанная email рассылка, будет в разы эффективнее. Но даже с самыми благими намерениями всегда есть риск попасть в чистилище папки «Нежелательная почта». Чтобы этого избежать, нужно учитывать ряд нюансов.

Как обычно, саммари в начале статьи и дальше — подробные пояснения. Итак, 9 простых правил:

1. Не занимайтесь спамом
2. Спрашивайте у адресатов согласия на рассылку
3. Обновляйте ваши базы адресов
4. Не используйте покупные базы
5. Храните подтверждения о законности вашей базы
6. Давайте возможность отписаться прямо из рассылки
7. Не повторяйтесь
8. Красиво и грамотно составляйте письма
9. Учитывайте требования спам-фильтров

Некоторые замечания о времени

• UTC: время на нулевом меридиане называется Всемирное координированное время, Universal Coordinated Time. Несовпадение акронима было вызвано необходимостью универсальности его для всех языков.
• GMT: ранее вместо UTC использовалось среднее время по Гринвичу (Greenwich Mean Time, GMT), так как нулевой меридиан был выбран так, чтобы проходить через Гринвичскую королевскую обсерваторию.
• Прочие часовые пояса могут быть записаны как смещение от UTC. Например, Австралийское восточное стандартное время (EST) записывается как UTC+1000, то есть время 10:00 по UTC есть 20:00 по EST того же дня.

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

До появления HTML5 единственное, что мы не могли контролировать и управлять (без перезагрузки контента или хаков с location.hash) — это история одного таба. С появлением HTML5 history API все изменилось — теперь мы можем гулять по истории (раньше тоже могли), добавлять элементы в историю, реагировать на переходы по истории и другие полезности. В этой статье мы рассмотрим HTML5 History API и напишем простой пример, иллюстрирующий его возможности.

Основные понятия и синтаксис

History API опирается на один DOM интерфейс — объект History. Каждый таб имеет уникальный объект History, который находится в window.history. History имеет несколько методов, событий и свойств, которыми мы можем управлять из JavaScript. Каждая страница таба(Document object) представляет собой объект коллекции History. Каждый элемент истории состоит из URL и/или объекта состояния (state object), может иметь заголовок (title), Document object, данные форм, позиция скролла и другую информацию, связанную со страницей.

Основные методы объекта History:

1. window.history.length: Количество записей в текущей сессии истории
2. window.history.state: Возвращает текущий объект истории
3. window.history.go(n): Метод, позволяющий гулять по истории. В качестве аргумента передается смещение, относительно текущей позиции. Если передан 0, то будет обновлена текущая страница. Если индекс выходит за пределы истории, то ничего не произойдет.
4. window.history.back(): Метод, идентичный вызову go(-1)
5. window.history.forward(): Метод, идентичный вызову go(1)
6. window.history.pushState(data, title [, url]): Добавляет элемент истории.
7. window.history.replaceState(data, title [, url]): Обновляет текущий элемент истории

Если в один прекрасный момент вам ударило в голову желание насадить разумное, доброе, вечное, и пересадить всех с SVN на GIT, сразу встают три проблемы:

• Объяснить зачем это нужно разработчикам и руководству
• Ввести в обиход новую схему работы с кодом
• Научить ничего не подозревающих девелоперов новым техникам

Некоммерческая организация Khan Academy начала публиковать микролекции по языку программирования Python для начинающих. Первый урок посвящён написанию простой программки вычисления факториала с использованием цикла.



P.S. Khan Academy специализируется на массовом образовании. С 2006 года её основатель Салман Хан записал более 2300 микролекций в области науки и математики. По данным на июнь 2011 года, у канала Khan Academy на YouTube зафиксировано около 64 млн просмотров.

Khan Academy на YouTube

Вышла в свет обновленная версия русскоязычной базы данных стран и городов. Основные изменения:
— за счёт новой базы ipgeobase.ru повысилась точность определения городов Украины
— из бесплатной версии базы geobaza.ru исчезли города, поэтому точность определения городов других стран СНГ понизилась
— добавлен скрипт, с помощью которого вы можете самостоятельно обновлять базу (без добавления новых городов и стран)
— таблицы net_ru_2 и net_su удалены из базы, изменены примеры запросов
Результат этой работы доступен для свободного скачивания.

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

Мы выпустили первую версию Chrome Frame в сентябре 2009 года. Нашей целью было расширить область применения современных веб-технологий, а также помочь веб-разработчикам использовать все возможности HTML5. И что самое впечатляющее, мы получили множество отзывов от разработчиков, которым Chrome Frame помог создать приложения, свободные от унаследованного (legacy) кода, которые, таким образом, гораздо легче создавать, поддерживать и оптимизировать.

Тем не менее, оставалась одна проблема, мешающая широкому применению Chrome Frame всеми пользователями Internet Explorer: для установки Chrome Frame пользователь должен был обладать правами администратора. В этом году, на конференции Google I/O мы объявили о том, что эта проблема, наконец, полностью решена.

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

Краткое содержание поста:

1. тестирование веб-сайтов — это сложно и непонятно
2. юнит-тесты в django
3. тестовая БД и как с ней бороться
4. smoke testing
5. покрытие кода (code coverage)

Читаете ли вы бизнес-блоги, в которых автор раз за разом описывает свои неудачи?
Нет, потому что вы хотите перенять успешный опыт, а не узнать о полученном опыте от парня, который сам еще не преуспел.

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

Приведу несколько историй, которые помогут понять серьезность этой проблемы.

Следы от пуль

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

Желая увеличить вероятность возвращения экипажей домой, британские инженеры изучали расположение следов от пуль. Инженеры считали, что в тех местах, где больше всего попаданий, нужно дополнительно бронировать корпус самолета. Разумеется, была найдена закономерность: много следов располагалось на крыльях, хвосте и в районе хвостового пулемета. На кабине пилота и топливных баках следов было мало.

Логично заключить, что нужно добавить брони в тех местах, где больше всего следов. Но это неверно.

1. Комментировать изменения в конфигах — не нужно. На память вы не жалуетесь, amiright?
2. QoS — не нужен. Всегда проще купить канал, заведомо превышающий потребности компании.
3. Бессмысленно проверять возможность удаленного управления оборудованием перед отправкой в удаленный офис.
Вы — профессионал и не могли ошибиться в настройке такой элементарной функции.
4. Устная договоренность с сетевиками ISP является полноценной разновидностью SLA.
5. Сертификация — незначима. Экзамены всегда можно сдать с помощью дампов.
6. Прямой доступ через serial к оборудованию — анахронизм. IP-интерфейс — удобнее.
7. С системой мониторинга должен работать соответствующий отдел. Сотрудники там опытные, разберутся, что к чему.
8. Во внутренних маршрутах никогда не будет более 15 хопов.
9. Остановка работы компании из-за разрыва линка со стороны ISP — не ваша вина.
10. Одного гигабитного линка будет достаточно для всех.
11. Никто никогда не соединит 2 сетевые розетки патчкордом. Зачем это делать?
12. Какой смысл ставить 2 маршрутизатора в ядре, если загрузка одного менее 50%?

Это интервью Криса Уонстрота, CEO и сооснователя Github. Данное интервью — часть серии “Bootstrapped, Profitable, & Proud” о компаниях с выручкой более миллиона долларов, обошедшихся без венчурного финансирования на старте и приносящих доход.

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

Проблемы контроля версий баз данных и миграций между версиями уже не раз поднимались как на Хабре (1, 2, 3 и др.), так и в Интернете (преимущественно, англоязычном).

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

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

^*)Писать сами тесты — действительно элементарно. Создать инфраструктуру, позволяющую легко писать тесты — чуть сложнее.

В статье описывается:

• Примеры использования блокирующих сокетов
• Преимущества асинхронных сокетов и Linux epoll
• Примеры асинхронного использования сокетов через epoll
• Вопросы производительности
• Исходный код

Далее представлена кроссбраузерная реализация скроллинга страницы средствами jQuery.

Как всё начиналось

В последнее время на многих сайтах можно увидеть в той или иной вариации кнопки для прокручивания страницы вверх или вниз. Смотрится это довольно мило, удобно в использовании, и просто в реализации. Столкнувшись с проблемой прокрутки объёмного контента в очередном разрабатываемом проекте, решил реализовать подобную функциональность.
Задача была следующая: сделать две кнопки. По нажатию на одну осуществлять прокрутку страницы в самое начало, по нажатию на другую – в самый конец. Также было решено дополнительно реализовать возможности чисто визуального характера, типа анимации, исчезновения кнопок и прочее, здесь я останавливаться на этом не буду, так как тема это – кросбраузерность. Собственно это стало основной проблемой в процессе написания кода.
Нарисовав симпатичные кнопочки, прикрутив анимацию и исчезновение кнопок, и реализовав собственно саму прокрутку, я обнаружил, что в разных браузерах наблюдаются проблемы со скроллингом. Раздосадованный (и почему-то ни капли не удивленный…) этим фактом (а также тем, что не получится уйти с работы пораньше), я решил ознакомиться с аналогичными реализациями в Интернете. Просмотрев несколько примеров, точно также, не воспринимающих какой-либо браузер, а подчас и работающих только в одном определённом, было решено заняться прототипированием, экспериментированием, решением задачи методом тыка (нужное подчеркнуть).
Далее я приведу кроссбраузерный вариант реализации простенького скроллинга страницы вверх/вниз, с пояснениями, где и что может пойти не так и в каком браузере (ни в коем случае не претендую на оригинальность решения, это просто желание поделиться собственным опытом, и сэкономить людям время при решении аналогичных задач). Ах да, забыл оговориться, подавляющая часть кода написана на jQuery.