Многие знают о механизме Event-Dispatcher-Listener'ов, реализованному во многих языках программирования. Я же создам подобный механизм не для Event'ов, а для любого метода объекта JavaScript — Object.
Я не претендую на оригинальность, нет. Основная цель статьи — рассмотреть интересные механизмы прототипирования в JavaScript, создание декораторов и, собственно, постараться хоть немного раскрыть мощь и гибкость это чудесного языка, который так часто обижают и недооценивают.

UPD1: краткое содержание:
1. Создание декоратора на JavaScript
2. Создание механизма Function call listener с помощью декораторов

UPD2: от 09.06.2009
В конце статьи я добавил раздел Update: Decorator Mark II. В нём — исправления и улучшения (я не перекраивал всю статью из-за этого)

Итак, первый (и, надеюсь, не последний) рецепт в моей поваренной книге JavaScript.

Спасибо всем! Статья набрала необходимое число плюсов и автор к нам присоединяется! Вот и он: elw00d
Представляю вниманию товарищей-дотнетчиков библиотечку собственного написания, с помощью которой можно легко обращаться с несложными математическими функциями, переводя их из строковой формы инфиксной записи в обработанное представление, составленное в постфиксной нотации, и обратно. Для чего это может понадобиться?

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

^{Системы рекомендаций:
— Советы от машины
— Холодное начало
— Введение в гибридные системы
— искусственные имунные системы и эффект идиотипов}


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

Для начала все-таки придется дополнить классификацию СР. Przemyslaw Kazienko и Pawel Kolodziejski предложили разделить все СР на пять типов: статистические, коллективные, ассоциативные и информационные. Начнем с самых простых.

В последнее время меня стала раздражать громоздкость кода, неповоротливые конструкции и наличие лишних строк.
Простой foreach в соответствии с codestyle превращается минимум в 4 строки текста

foreach(var element in collection)
{
  // Do something
}
* This source code was highlighted with Source Code Highlighter.

Поэтому образовалась вот такая обёртка.

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

Конечно же, нельзя быть абсолютно уверенным, что пользователь введёт именно то, что нужно, поэтому все данные необходимо тщательно проверить.

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

На практике это выливается с довольно длинные последовательности «if-else». Лично мне это жутко не нравилось, так как сложно с первого взгляда определить, какие поля как проверяются и какие сообщения выдаются в случае ошибок. А ведь полей в форме может быть и десять, тогда код проверки вообще затягивается. Вобщем, я задумался над тем, как можно минимизировать объём работ и вот что из этого получилось.

Хочу рассказать вам о фреймворке, который был создан для разработки «богатых» веб-приложений на ASP.NET. Фреймворк был создан в компании, в которой я работаю, и использован в нескольких боевых проектах.

Из ключевых особенностей фремворка:

• хороший JSON-форматтер (теперь на клиент можно передавать почти любые .NET-типы);
• мастерстраницы/страницы/контролы на клиенте представлены как объекты JavaScript (в JavaScript построить взаимодействие между ними теперь совсем просто);
• мастерстраницы/страницы/контролы можно наследовать, причем можно наследовать как серверный код, так и клиентский (да, даже разметку);
• можно использовать совместно с jQuery или (как делаем мы) с ExtJS;
• много всего приятного :)

Инициатор создания фремворка и его главный разработчик не я, а мой коллега. Я же просто разместил объяву хотел рассказать вам о замечательном продукте :)

Читать статью

P.S. — В топик-ссылку не поместилось описание, сделал как топик.

Ниже представлен оригинал моей статьи принятой для публикации в отличный компьютерный журнал C`t, который, к сожалению, не выжил на рынке и пока пребывает в весьма подвешенном статусе. Статья не была опубликована из-за того, что выпуски больше не выходят. Поэтому я решил опубликовать ее на Хабре, благо она отлично попадает в формат.

Хотел бы сразу отметить, что статья достаточно объемная и часть информации уже была опубликована мной на Хабре. Цель данной статьи объединить максимальное количество информации про новую версию Internet Explorer и представить ее в приемлемом объеме.

В комментах принимаю замечания и исправления.

Многие из Вас наверняка стакивались с ситуацией — есть дело важное, интересное, прибыльное (нужное подчеркнуть;), есть время этим делом заняться. А душа к нему не лежит. Стоит только сесть за работу, как как будто черт дергает послушать музыку, побродить по интернету, початиться с друзьями. Один — другой раз, не куда ни шло, но это происходит постоянно, и часто под самыми благовидными предлогами (например: дабы узнать новую информацию необходимую для проекта). Не иначе как происки нечистого.

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

Итак, получили письмо от клиента

обычно есть следующие варианты

1. клиент явно перспективный и обратился «выборочно» именно к нам — есть большая вероятность, что переговоры будут удачными — тогда лучше сразу набивать стрелку и устанавливать личный контакт и все выяснять на месте. Хотя, границы бюджета лучше выяснить в любом случае.
2. клиент интересный, но многое неясно из его письма ( нет ТЗ, нет бюджета, он написал в несколько студий, сайт потенциально сложный, сайт неинтересный и тд. ). Тут важно прислать ему БРИФ на заполнение, выяснить сроки и бюджет. Согласовать бюджет сроки — уже потом встречаться в случае, если все устраивает.
3. Письмо подозрительно короткое и не «пахнет интересом». Например, «нужен обувной интернет-магазин, сколько стоит? Как быстро сделаете? Виталий» — тут вряд-ли чтото выгорит + вероятно это пробивон по ценам от конкурентов.
   В этом случае — цену говорим в полтора раза дето дороже, интересуемся «укладываемся ли мы в их бюджет» в положительном случае — можно встречаться. Иначе — скорее всего трата времени.

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

Проблема

На многих сайтах я наблюдаю следующий процесс:

1. Пользователь заходит на сайт
2. Пользователь находит что-то, что он хочет купить/скачать/сохранить
3. Пользователь переходит на страницу регистрации
4. Пользователь вводит свою информацию и ждёт письма с ссылкой активации
5. Пользователь получает письмо и переходит по ссылке
6. Пользователь попадает либо на страницу активации, либо на страницу логина, либо на страницу, откуда он начал регистрацию
7. Пользователь снова находит то что он хотел купить/скачать/сохранить
8. Пользователь покупает/скачивает/сохраняет

Суть проблемы: пользователь теряет контекст своего действия. После регистрации он вынужден снова искать то, что он изначально хотел купить/скачать/сохранить.

Решение

Сегодня я смотрела видео с презентации одного из мемберов команды 37 signals о том, как они, оставаясь маленькой компанией (из 12 человек), не привлекая венчурные инвестиции, умудряются успешно продавать свой продукт и быть чертовски прибыльными.

Обобщая идею презентации могу сказать следующее:

1. Создайте хороший продукт
2. Установите разумную цену
3. Попросите ваших пользователей заплатить за него

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

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

Несмотря на то, что некоторыми это может рассматриваться как инсайдерская информация – нам нечего скрывать:

//2500 пользователей пользуются нашими платными услугами

2500 пользователей платной услуги получаются при допущениях:
V нашего рынка = 1000 000 пользователей (согласно проведенному нами
исследованию)
Мы занимаем 5% рынка = 50 000 пользователей
5% из них пользуется нашими услугами = 2500 пользователей. (это 25% от 1% ;))

#1 вариант#
базовый: от 5 у.е. — 50% пользователей
средний: от 10 у.е. 40% пользователей
продвинутый: от 15 у.е. — 10% пользователей
1250 * 5 + 1000 * 10 + 250 * 15=
6250 + 10 000 + 3750 = 20 000 у.е. месяц
***дальше по тексту без расшифровки

#2 вариант#
базовый: от 5 60%
средний: от 10 30%
продвинутый: от 15 — 10%
7500 + 7500 + 3750 = 18 750 месяц

#3 вариант#
базовый: от 5 70%
средний: от 10 20%
продвинутый: от 15 — 10%
8750 + 5000 + 3750 = 17 750 месяц

#4 вариант#
базовый: от 5 75%
средний: от 10 20%
продвинутый: от 15 — 5%
9375 + 5000 + 1875 = 16 250

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

Возвращаясь к идее 37 signals: у вас есть оооочень маленькие шансы стать еще одним facebook’ом, myspace или google. Они есть, но совсем небольшие. Кроме того, даже эти компании не стали «звездами за 1 ночь», а развивали свою базу пользователей постепенно, пусть и очень большими шагами.

А теперь спросите себя: готовы ли вы переработать свою стратегию таким образом, чтобы ваш бизнес действительно приносил деньги, а не имел виртуальную стоимость (как происходит со многими стартапами, которые потом покупают)? Если да, то вперед!
Я думаю, что мы свой выбор уже сделали.

Рано или поздно все web-разработчики сталкиваются с ситуацией, когда Internet Explorer становится проблемой, тормозящей разработку проекта. Сайт свёрстан валидно, по стандартам. Нормально отображается в Mozilla, Opera, Safari и других нормальных браузерах. Но. Открываем его в IE. И видим. Как то, что мы подгоняли по пикселям, строго придерживаясь стандартов, размазано по странице. Ладно ещё в IE7 можно более-менее просто подогнать вёрстку (конечно зависит от дизайна), но от IE6 иногда волосы встают дыбом. К счастью, существуют способы, которые позволяют повлиять на ситуацию. Кто-то использует хаки, кто-то — conditional comments. Где-то можно пойти на компромис и упростить задумку дизайнеров, поддерживая пользователей недобраузеров.

В наше время среди СУБД самую большую распространенность получили реляционные базы данных, в которых основными объектами являются таблицы и отношения между ними. Таблицы — это очень хорошо, они позволяют решить большинство задач по хранению данных и манипуляции с ними. Но в реальном мире сущности требующие хранения не всегда представлены в табличном виде. Одним из таких очень распространенных видов структуры данных отличных от таблицы является древовидная структура, когда каждый элемент данных имеет предка и потомков. Примером такой структуры может быть структура штата предприятия, в котором во главе стоит директор (корень дерева), его заместители, отделы с начальниками, которые подчиняются определенным заместителям, сотрудники отделов, которые подчиняются начальникам.

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

Однако, разработчики СУБД MS SQL предлагают в своей новой версии MS SQL 2008 для реализации древовидной иерархии новый тип хранения данных hierarchyid.

Я никогда раньше не имел дело ни с одним AJAX Toolkit от Microsoft, но недавно у меня появилась необходимость добавить картографический функционал к проекту, который я веду. Нам нужно было, чтобы у пользователей появилась возможность перемещать маркер по карте, а у нас получать его новые координаты на сервере. Очевидно, что нам для этого придется использовать AJAX в каком-либо виде. Сегодня я вам покажу насколько просто использовать связку ASP.NET MVC на сервере и jQuery на клиенте. Так как jQuery теперь включен в поставку ASP.NET MVC, то больше нет оправдания его не использовать.

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

Итак задача:
Организовать удобное администрирование многодоменного web сервера.
Модель системы: linux -> nginx -> apache -> php -> mysql.

Раньше у меня для каждого домена были отдельные конфиги для nginx и apache,
и для добавления нового хоста требовалось добавить как минимум 2 конфига.

Работа была организована удобно. По сути, были 2 скрипта. 1 для добаления хоста к nginx, другой для apache. (ещё есть скрипт добавления хоста в bind но это другая история).

Но и это было не удобно в условия добавления удаления хостов… иногда забыл nginx прописать, иногда в апаче чтото не то…
Решено было следующим образом:

  Накануне на конференции PDC (все посмотрели пленарные доклады с анонсом Windows Azure, Windows 7, Office «14», Live Mesh и прочее?) было заявлено о первом выпуске Silverlight Toolkit (ранее — Silverlight Control Pack).
  Silverlight Toolkit — это набор дополнительных элементов управления и тем для Silverlight 2, распространяемые бесплатно, с открытым кодом и тестами по лицензии Ms-Pl.
  Silverlight Toolkit разрабатывается вместе с сообществом, причем отдельно от собственно создания Silverlight. Сейчас он уже включает 10 контролов и 6 тем:

Введение

Zend Framework — замечательная система. Такое мнение у меня сложилось на протяжение долгого времени тесного «общения» с этой системой. И замечательная она не в силу каких-то сверхвозможностей, предоставляемых программисту, а в силу того, что система эта удивительным образом приглашает программиста к собственному усовершенствованию для его, программиста, блага, предлагая простой и в то же время мощный фундамент для собственных разработок.
Работая над проектом с использованием Zend Framework, решил попытаться по максимуму использовать его возможности и сразу же обратил внимание на компонент Zend_Form (я намеренно называю Zend_Form компонентом, а не классом, поскольку компонент Zend_Form состоит из класса Zend_Form и целого набора сопутствующих классов и интерфейсов). В документации сказано достаточно просто: «Zend_Form упрощает создание форм и управление ими в ваших веб-приложениях». В общем-то это так, но без предварительной подготовки с вас семь потов сойдёт прежде, чем вы сможете создать и отобразить одну более или менее сложную форму. Концептуально форма в Zend Framework состоит из:

• элементов
• декораторов
• фильтров
• валидаторов

Элементы — это, собственно, то, что мы понимаем под элементами формы: поля ввода, выпадающие списки и пр.
Декоратор — это вся верстка, которая логически связана с элементом формы (окружает его), но не является его частью. Проще говоря, декоратор — оформление элемента формы.

В продолжение темы клиентской оптимизации слиянием ресурсов.

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

Есть три основных вида обращения к странице:

1. начальная загрузка (загружается и ядро, и ресурсы выбранной страницы)
2. загрузка новой страницы (ядро находится в кеше, загружаются ресурсы выбранной страницы)
3. загрузка старой страницы (и ядро, и ресурсы страницы находятся в кеше).

На скорость загрузки в третьем случае мы повлиять не можем. Кроме того, для ускорения начальной загрузки выгодно уменьшить объем ядра, поэтому оптимизация случая (1) ухудшает время загрузки в случае (2) и наоборот. Что делать?

Вот я прошёлся по блогам и сайтам, которые висят у меня в подписках, и понял, что всё печально. Если намеренно вызвать страницу 404-й ошибки, то можно напороться на все возможные отмазки, пустую страницу, либо на страницу, которую генерит сервер. Ну или на крайний случай — sitemap. Часто любят выкладывать туда смешную картинку.