Каркас для кроссбраузерной разработки ExtJS сейчас очень популярен. Это поистине грандиозный (и монструозный) набор компонентов, классов, функций, хелперов и т. п., которые могут как облегчить жизнь разработчика, так и усложнить ее. Говоря вообще, ExtJS (до 4-й версии) не устанавливает никаких «правил игры» для конечного разработчика: формально нет никаких требований и рекомендаций по проектированию и написанию надежных приложений.
Удивительно, что до сих пор качество пособий и туториалов для новичков ExtJS, мягко говоря, оставляет желать лучшего. Как и стандартная справка по ExtJS API, впрочем [1].
Цель данной статьи — показать, как писать приложения на базе ExtJS так, чтобы человеку, который будет поддерживать ваш код, не хотелось рвать волосы, а вам просто не было стыдно. А если серьезно, то в данной статье я предложу простой и короткий набор правил проектирования и написания приложений применительно к данному фреймворку.

Доброго времени суток.
Многим web-программистам рано или поздно нужно работать с видео. Такая задача возникла и у меня.
В Интернете есть много статей на форумах и блогах, как на русскоязычных, так и на зарубежных сайтах. Но, проделавши, так же как и предлагалось в инструкциях — результата ожидаемого не дало. Что и послужило поводом для этой статьи. Думаю, она поможет таким же как и я многим начинающим.

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

Самым простым вариантом отобразить древовидную структуру в HTML являются списки. Но нас интересуют деревья, обладающие динамическими свойствами. Без javascript тут не обойтись. Так как решение нужно обычно быстро, то использование jQuery позволяет создавать динамические деревья, экономя прилично времени на кодинге. Чтобы сэкономить себе еще кучу времени идем на поисковик и ищем подходящее решение. В целом часто на этом дело создание дерева на сайте и ограничивается, но бывают ситуации, когда дерево подходит, но не имеет какой-то маленькой фишки и тут уже ни чего не остается, кроме как модифицировать имеющиеся дерево.

Бектрекинг – механизм решения переборных задач. Позволяет выбрать либо 1 приемлемую альтернативу, либо наилучшую.

Оценка задач

При оценке сложности задач очень часто сложно выдать абсолютную оценку. Гораздо легче оценить относительный размер двух задач, т.е., например, сказать, что задача А в два раза больше задачи Б.
При agile-процессе разработки приходится оценивать много пользовательских историй.
Используя попарное сравнение снижается погрешность в определении оценок, и более того, эту погрешность можно вычислить.

Плагин Chosen создан для оформления красивых и удобных выпадающих списков с помощью jQuery и Prototype. Для установки плагина достаточно просто скачать файлы и прописать одну строчку:

$(".chzn-select").chosen()

(версия для jQuery)

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

Поскольку Chosen заменяет стандартный элемент HTML, то не нужно беспокоиться, как он работает с браузерами без поддержки JavaScript. Также не нужно ничего менять в бэкенде: формы сабмиттятся как обычно, изменения только в пользовательском интерфейсе.

Некоторые форки:
Chosen для MooTools
Модуль Chosen для Drupal 7

Здравствуйте, уважаемые коллеги.

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

Другим же условием хороших тестов является отсутствие сторонних эффектов (side effects), как например создание/удаление файлов, установка сетевых соединений, запись в порты и т.д.

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

Под катом вы найдете мое решение и, в качестве бонуса, еще одну ОПП-обертку к курлу, полностью покрытую тестами.

Приложения для Facebook могут иметь разнообразный функционал: например, часто приложению будет достаточно информации, полученной через API, во время работы пользователя с приложением. Но что делать, если ваше приложение должно работать с самыми “свежими” данными пользователе, даже если они не открывали его уже больше месяца?

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

1. Получить от пользователя offline_access permission (сохранить “вечный” пользовательский access_token) и получать необходимые данные “по расписанию” (дергать скрипт cron-ом).
2. Написать скрипт, который будет получать все изменения данных от Facebook, настроить и подписаться на обновления через Real-Time Updates.

Под катом вы узнаете виртуальный пример, как использование real-time updates помогает сократить за день количество запросов к API более чем в 100 раз в некоторых ситуациях. Мы напишем скрипт подписки на обновления и проверим его работу, получив данные о изменении объектов от самого Facebook.

Где-то год назад при разработке нашего проекта мы дошли до некой точки развития, когда или начинается кропотливая настройка и оптимизация MySQL-сервера, или начинается опять же кропотливое изучение запросов, которые идут в БД. Так получилось, что именно тогда был бум статей про MongoDB, CouchDB и прочие NoSQL базы данных и соблазн попробовать их на живом проекте был крайне велик.

При выборе главную роль сыграла фраза «CouchDB предназначен именно для веба», а также то, что для доступа не требовались никакие прослойки — доступ осуществляется по любимому мной REST, а API выглядит очень простым и изящным. Вдобавок к этому CouchDB имеет крайне удобный веб-интерфейс для администрирования Futon, чего на тот момент не было у MongoDB, а также железную устойчивость к падениям.

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

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

Всем привет. Данная статья посвящается методологии Разработки через тестирование (TDD) в применении c JavaScript.
Напишу лишь вкратце о методологии TDD, более подробную информацию можно почерпнуть из ссылки выше.

Разработка через тестирование подразумевает, что перед написанием кода необходимо:

• создать тест, который будет тестировать несуществующий код, тест соответственно не пройдет
• написать код и убедиться, что тест прошел
• почистить код
• повторить

Введение

Предлагаю Вашему вниманию обзор посвященный оптимизации изображений формата PNG и JPEG без потери качества. Под «без потери качества» подразумевается, что визуально оригинальные и оптимизированные изображения ни чем не будут отличаться. Я читал на Хабре довольно много статьей посвященных данному вопросу, но скажу, большая часть — полная чушь, в них констатируются факты, а не причины. Данный обзор посвящен людям, которые имеют базовые знания об оптимизации изображений.

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

От переводчика: Я думаю многие читали статью Rey Bango — What to Read to Get Up to Speed in JavaScript, но до хабра обсуждение так и не докатилось. Предлагаю закрыть этот пробел и поговорить о хороших книгах, блогах, тренингах и конференциях, посвященных в первую очередь клиентскому JavaScript и клиентской веб-разработке. Чтобы не копипастить оформляю статью в виде перевода.

Сейчас в рассылке JSMentors JavaScript идет обсуждение книг, который стоит прочитать, чтобы улучшить свои знания. Там было много позитивных отзывов и предложений. Я хочу показать вам те книги и интернет-ресурсы, который я считаю важными и которые помогут вам в обучении. На этой странице я перечислил большое количество источников, разделенных по уровням.

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

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

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

Основы

Мы начнём с несложного обзора модульного подхода, хорошо известного с тех пор, как Эрик Миралья (Eric Miraglia) из YUI впервые об этом написал. Если вам уже знаком модульный подход, переходите сразу к «Продвинутым техникам».

Анонимные замыкания

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

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

Без использования unit-тестов и TDD очень легко выстрелить себе в ногу. С тестами и TDD сделать это намного сложнее, но если у вас получится, вы останетесь без ноги.

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

В этой статье я постараюсь объяснить о чем, собственно, разговор. Для чего нужно TDD и как его аккуратно использовать.

Что такое TDD в двух словах? — это написание разработчиком тестов до реализации функциональности.
По совету Роя Ошерова разобьем вопрос применимости TDD на два:

• Зачем писать тесты?
• Зачем писать тесты до реализации?

Введение

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

Деревья принятия решений

Дерево принятия решений — это дерево, в листьях которого стоят значения целевой функции, а в остальных узлах — условия перехода (к примеру “ПОЛ есть МУЖСКОЙ”), определяющие по какому из ребер идти. Если для данного наблюдения условие истина то осуществляется переход по левому ребру, если же ложь — по правому.

Большинство людей не умеют писать unit-тесты. И даже те, кто применяет модульные тесты в ежедневной разработке, зачастую признают, что получившиеся тесты иногда не очень эффективны по определенным причинам. К этой категории людей я могу отнести и себя. В первую очередь, такой «причиной» является некоторая появляющаяся «инертность» кода, заключающаяся в том, что если требуется немного изменить какой-то ключевой алгоритм, добавить пару строчек кода, то при этом «падают» ~100 модульных тестов и приходится тратить продолжительное время на то чтобы заставить их работать вновь. Итак, приступим к «хорошим рекомендациям» при написании автоматических модульных тестов. Нет, я не буду капитаном очевидностью, в очередной раз описывая популярный стиль написания тестов под названием AAA (Arange-Act-Assert). Зато попытаюсь объяснить, чем отличается Mock от Stub-а и что далеко не все тестовые объекты — «моки».

Очень краткий обзор поисковика по файлообменной сети Direct Connect.
Subj ходит по основным хаблистам и на данный момент знает о ~740 миллионах файлов.

dc.proisk.ru