Представлю вам последнее видео, посвященное языку программирования Scheme. Дальше мы переходим на Пролог, а напоследок постараемся реализовать классы в функциональном языке.


Если не доступен режим HD, то перейдите, пожалуйста, на vimeo.

Полное решение третьего задание по курсу Programming Paradigms, включающее набранный в видео код.

Видео доступно:

• На Vimeo
• На YouTube (часть 1, часть 2)
• На rpod.ru

Часть 1

Продолжаем разговор о секционировании. В прошлый раз мы рассмотрели простую задачу о таблице, разбитой на секции для каждого дня — так называемый range partitioning. Разбив таблицу на секции мы столкнулись с новой проблемой — поддержка секционированной таблицы. Мы должны вовремя создавать новую секцию, архивировать устаревшие, изменять соответствующим образом триггер, управляющий вставкой новых данных.

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

У моего проекта несколько зависимостей. Бóльшая часть зависимостей живет в гитовых репозиториях. Сам проект тоже живёт в гите.

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

Раньше я просто копировал зависимости в папку проекта, и добавлял к каждой файл VERSION.TXT с её версией. Но, если нужно работать с текущей версией стороннего кода, это неудобно. Да и копировать файлы руками когда есть гит как-то глупо. Хочется найти более современное решение.

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

С mod_rewrite есть одна проблема, об которую набиты уже наверное 15 миллионов шишек: он просматривает список правил снова и снова, пока URL удается хоть как-то изменить.

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

Хочу поделится достаточно простым и универсальным средством борьбы с такой особенностью, который обнаружил только-что :-)

Вообще-то изначально я планировал перевести статью Энди Джеффриса (Andy Jeffries) 25 Tips for Intermediate Git Users, но в процессе я отбросил бестолковые, общеизвестные или самые простые советы вроде «настройте первым делом user.name и user.email», которые явно не подходят людям, уже более-менее плотно знакомым с Git.
Взамен я дополню статью моментами из личной практики («Своя практика»! Звучит здорово, будто я частный врач или адвокат! :-] )

Доброго времени суток, %username%.
Представляю твоему вниманию анонс Ample SDK, новой кросс-браузерной библиотеки интерфейса пользователя.

Познакомиться с проектом Ample SDK тебе будет интересно по следующим причинам:

• упрощает создание клиентских веб-приложений
• реализует стандартные веб технологии и API кросс-браузерно
• повторяет архитектуру веб-браузера (ничего нового учить не надо!)
• позволяет использовать SVG в HTML (также в Internet Explorer, хм!?)
• позволяет использовать XUL в любом современном браузере
• позволяет легко определять новые доменно-зависимые UI технологии
• проект с открытым (MIT/GPL) исходным кодом (на GitHub)

Для затравки, один и тот-же SVG Tiger документ отображенный в Internet Explorer 6 и Google Chrome 3:



Интересно?

Проблема

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

Довольно часто, особенно при написании подсистем, скрыть те или иные методы и классы довольно непросто. Неприятности начинаются, кода подсистема достаточно большая, и для лучшей организации кода необходимо завести несколько под-пакетов.
Например, если есть класс com.system.InternalProperty, который используется и в com.system.persist.PropertyManager, и в com.system.network.PropertyUpdater, то InternalProperty должен быть объявлен public.

В этом посте я постараюсь рассказать о существующих решениях и предложить новую идею.

Самое сложное в любой работе — это начать её. Итак, с чего же начать наше огромное клиентское приложение? В этой части я расскажу с чего начать и затрону три темы: Как организовать код, Что такое фасад, как его построить, что такое компоненты (и, конечно, как их начать писать).

Публикую топик, за который получил инвайт на Хабр =)

Давно подумывал поделиться опытом разработки расширений для PHP, но все время забывал =)
Сейчас, увидев хабратопик об основах создания расширений для PHP в VS2008, решил наконец это сделать.
Поскольку основы были изложены в этом топике, я сразу перейду к более тонким моментам.

Пока nerezus сочиняет статью о встраивании PHP, я постараюсь продолжить его рассказ о написании расширений. Рассказано будет далеко не всё, поскольку я считаю, что сложность наращивать надо постепенно, иначе материал будет трудноусвояемым и совсем не питательным. В связи с этим я всё-таки не расскажу в этот раз, как подменить операторы в классе, кто захочет, может почитать исходники модуля Operator от Сары Големон — основного автора какой бы то ни было информации о разработке расширений PHP.
Поскольку разработку я веду исключительно в линуксе, то писать мы будем без всяких хитрых аддонов к Visual Studio, ручками, с нуля :) А что, лучше сразу разобраться, а потом уже упрощать свой труд.

Часть 2

Добрый вечер/день/утро уважаемые хабралюди! Продолжаем развивать и дополнять блог о моей любимой open source rdbms Postgresql. Чудесным образом так получилось, что тема сегодняшнего топика еще ни разу здесь не подымалась. Надо сказать, что секционирование в postgresql очень хорошо описано в документации, но разве ж это меня остановит?).

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

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

Такое ограничение сразу приводит к вычеркиванию из списка методов оплаты заполнение квитанции в Сбербанке. Да, это тоже метод, но метод небыстрый. Особенно, если на дворе поздний вечер, пользователь расслабился за бутылкой пива чашкой чая. Какой Сбербанк, тёпленьким его брать, тёпленьким!

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

Немного статей на хабре посвящены новому движению в IT индустрии — NoSQL. Я решил изменить это и написал статью-перевод-обзор об одном из докладов с конференции NoSQL прошедшей 5 октября в Нью-Йорке. В этой статье будет говорится о системе Riak, с которой мне довелось иметь счастье работать последнее время.

Что такое Riak? Многие модные слова популярные сейчас, можно отнести к Riak. Riak — это документно-ориентированная база данных. Riak — это децентрализованное key-value хранилище данных, с поддержкой стандартных операций — get, put и delete. Riak — это распределенное, масштабируемое, отказоустойчивое решение для хранения информации. А так же Riak — это система с открытым исходным кодом и поддержкой обращений с помощью HTTP, JSON и REST. Ну и конечно RIAK — это NoSQL.

Browser persistence — техника, позволяющая хранить в браузере довольно большие объемы данных, которые в отличие от cookie не отсылаются на сервер при каждом запросе.

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

Довольно давно не заходил на сайт ExtJs. Что же там нового?
Обновился фреймворк до версии 3.0.3 и вместе с ним добавилось много новых фич. Обновился блог. Обновился раздел документации. Обновился раздел демо-приложений. Скорее всего обновился и визуальный редактор, но по недавним причинам, обычные смертные его не увидят. Только если подписчики ;)

Mы только что открыли α-тестирование проекта Uniquation. Это математическая поисковая система, которая ищет решения среди уравнений, равенств и прочих математических объектов, размещенных в интернете. На текущем этапе развития её можно мыслить как развивающуюся CAS (wiki). Помимо этого поста про неё можно прочитать в нашей презентации.

Поздравляю, коллеги! 3 дня назад увидела свет треться альфа-версия самого мощного на сегодняшний день ORM-фреймворка для PHP: Doctrine.

И эта новость по большему счету заслуживает внимания потому что в Doctrine 2.0 произошли очень существенные изменения в сравнении с предыдущими версиями. Сразу замечу, что вкусности эти потребуют от нас ни много ни мало — поддержку php 5.3.