Разработчики JavaScript-фреймворка JQuery не перестают нас удивлять. После недавнего релиза JQuery 1.4.1 нам представили инструмент для unit-тестирования кода, написанного на JavaScript - QUnit

В данный момент поддерживаются такие функции как expect(), equals(), ok(), same(), log() и асинхронные тесты. Вместе с фреймворком распространяется css-файл, с помощью которого можно быстро и красиво выводить результаты тестов. Также разработчики активно используют его для тестирования самого JQuery, поэтому можно посмотреть уже готовые приверы от авторов фреймворка.

P.S. Что-то подсказывает мне что не загорами плагин для FireBug, по крайней мере, мне бы этого хотелось...


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

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

Реализация интерфейса IScriptControl, который состоит из 2-х методов, помагает реализовать нужную задачу в несколько строк кода (не считая, конечно-то ещё нескольких строчек на JavaScript).

 

 

  • В методе GetScriptDescriptors() мы создаём дескрипторы в которых говорим какие клиентские свойства должны быть у контрола.
  • Метод GetScriptReferences() возвращает список клиентских скриптов, которые нам нужны и будут автоматически загружены с помощью ScriptManager.
С серверной стороной мы практически закончили, осталось только добавить несколько строк в обработчики событий OnPreRender и Render:

 

С серверной стороной закончили. Теперь осталось совсем немного написать на JavaScript. Как всегда, большую часть за нас сделала Microsoft. Добавляем в проект js-файл типа AJAX ClientControl:

Для нас создастса уже готовый прототик контрола, где нам останется только объявить все наши свойства, getters & setters для них, события и методы. 

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

Хочу заметить, что всё описанное выше без каких-либо изминений можно применять только для WebControl. Если же нужно сделать UserControl, то в нём нужно поместить какой-либо контейнер (e.g. <div id="container" runat="server"></div>) и при создании дескрипторов указывать ID контейнера, иначе вы получите клиентскуб ошибку что не к сему привязать js объект.

Более подробно о каждом шаге можно почитать по ссылке http://en.csharp-online.net/Creating_Custom_ASP.NET_AJAX_Client_Controls—IScriptControl.GetScriptDescriptors_Method и в MSDN.

ScriptControlTest.zip (7.95 kb)


Устанавливая новое SDK для Google App Engine подумал о кроссплатформенности. Для себя решил что кроссплатформенность это:

 

  • для пользователя: везде и на всех компьютерах вeсь необходимый ему софт выглядит и работает одинаково;
  • для разработчика: код в любой среде компилируется с одними и теми же ключами для компилятора.

 


 

Регистрация началась немного раньше 9:00, т.к. уже в 8:30 у входа уже набралось такое количество людей, что уже все не помещались в вестибюле. При регистрации дали расписание докладов и немного спонсорской рекламы. Получил в гардеробе жетончик с номером “1” :).

10:00. Все ждут начала ивента, которое будет на 15 минут позже рннее заявленного времени. Есть весплатный wi-fi. В зале людй достаточно много, но всё-равно осталось много бейджиков для зарегистрированных участников.

10:02. Макс Ищенко со вступительным словом. Коротко, пости без рекламаы

Первый доклад. Почему Python - тормоз и как заставить его меньше тормозить.

Докладчик из Рамблера. Должо быть интересно. Питон сравнивается с С. Как можно? Теперь я знаю что С очень быстрый, а питон 2.6 быстрее 2.5. Пару месяцев назад в журнале Хакер была статья на это тему. Кажется, много общего. Не помню сейчас.  Оптимизпция кода на питоне такой, как она была представлена в докладе – действительно ли такая актуальная тема для pycamp? IMHO, не самый удачный доклад.

Второй доклад. Рецепты декораторов.

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

Третий доклад. Программирование на нервах.

Первое, что бросилось в глаза - никакого отношени к Python! Доклад, скорее всего, получился не как доклад, а как рассказ об личном опыте одного PM'а. Объективно сложно судить, т.к. я не согласен практически ни с чем, о чём говорилось. Автору доклада нужны не живие люди, а роботы, которые тупо, без эмоций выполняют свою работу. 

Четвертый доклад. Работа с хранилищем данных в Google App Engine, отличия от реляционной модели.

Ожидал больше технических подробностей. Все было слишком поверхностно и легко находилось в документации. Во время доклада задавал себе вопрос: "Зачем я здесь? Всё это можно прочитать в документации к GAE". Еще, imho, раз уж тема была сформулирована так, можно было бы немного больше уделить времени memcache. После доклада осталось много вопросов, которые многие задавали в перервыве докладчику. Я решил уж лучше почитаю документацию.

Пятый доклад. Redis: Дикий Запад баз данных.

Наверное, это было лучшее, что я услышал на pycamp. Отличный доклад. Хорошо подготовленный о понимающий о чём идёт речь докладчик. После доклада С первых минут доклада хотелось попробовать всё, о чем говорил докладчик. Вскоре, напишу пост об это БД.

Дальше был обед. По некоторым причинам, одна из которой - не очень хорошая подготовка докладов, решил не слушать остальные, хотя, было бы интересно послушать "Расширение и встраивание Python". Буду ждать видео. Почему-то, как только первый раз увидел тему докладов, сразу же не захотелось слешать "PyCharm – новая python IDE от JetBrains". IDE - хорошая, но лучше посмотреть вебкасты. IMHO.

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