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

Преамбула

Какое-то время назад я писал о способах публиковать Evernote-заметки через джаббер. Способов тогда нашлось два: крайне медленный и неудобный (jabber -> tweet.im -> twitter -> evernote) через твиттер и неработоспособный (поскольку публичных траспортов не нашлось) через smtp-транспорт.

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

Использование

Бот живет по адресу xmpp:evernote@neko.im. Для того, чтобы получить справку по командам, достаточно отправить ему сообщение с произвольным текстом (и добавить в ростер, чтобы он светил он-лайн статус) или сообщение с текстом «help» после регистрации. Для авторизации бота используется OAuth (из соображений безопасности пришлось отказаться от регистрации по логину и паролю).

Добавлю только, что элементы синтаксиса можно комбинировать в произвольном порядке: "(( Заголовок )) [[ Блокнот ]] Текст заметки" или "[[ Блокнот ]] (( Заголовок )) Текст заметки" — кому как удобнее. Также бот позволяет отправлять и заметку без текста (при этом заголовок обязательно должен быть указан).

Баг-репорты, конечно же, очень приветствуются.

Приятного использования!

P.S. Если хабрасообществу интересно, позже могу рассказать про процесс разработки и выложить исходники на python в соответствующем блоге — тем, кто собирается работать с Evernote API (и особенно OAuth), может пригодиться, потому что я почти не нашел хороших примеров на эту тему.

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

Код — в конце статьи, а для начала я расскажу о некоторых особенностях работы с Evernote.

У любого серьезного web-сервиса есть собственная система уведомлений по электронной почте. Отправка email-сообщений сопровождает регистрацию пользователя, используется для восстановления пароля и подтверждения важных действий, письма-алерты напоминают о наступлении определенных событий. Еще больше сообщений получают администраторы и модераторы сервисов — им сообщают зачастую о «каждом чихе» их подопечных.

Весь этот поток сообщений, сдобренный личными письмами и густо перемешанный со спамом, валится на единственный почтовый ящик, после чего встает задача «отделения зерен от плевел» и приведение первых в некоторую структуру, позволяющую потом разобраться, где что. Для фильтрации писем в них должна быть некая информация, позволяющая почтовому клиенту определить, как обработать данное письмо. Вариантов, собственно, немного, и все они отражены в списке условий фильтра сообщений. Можно отправлять письма с разными темами с разных адресов (использовать различные name в name@domain.tld для каждого типа сообщений). Можно использовать тему письма или добавлять в нее специальные префиксы типа [SERVICE-EVENT]. Все это не улучшает читаемость сообщений и может приводить к различным проблемам. Однако есть способ, свободный от этих недостатков.

Так сложилось исторически (из-за соображений безопасности), что Javascript-обьект XMLHttpRequest, который лежит в основе AJAX, не может делать кросс-доменные вызовы. Это бесполезное ограничение: для злоумышленников не представляет особой проблемы, а для разработчиков создает некоторое неудобство. В следующих поколениях браузеров эту проблему обещали решить, но не раньше чем W3C хотя бы одобрит новые стандарты.

Есть море хаков чтобы обойти это ограничение, но самый популярный это Dynamic Script Tag Hack. Именно через этот хак организован доступ к многим API современных веб-приложений.

Дуве Осинга, инженер, команда Google Wave API
Алексей Шелестенко, маркетинг Google Россия

По горячим следам анонсированного недавно продукта Google Wave, спешим обрадовать (отчасти) всех заинтересовавшихся программистов и веб-девелоперов: у Google Wave появился свой блог для девелоперов. Там можно узнать о технических аспектах Google Wave, особенно о Google Wave API и Google Wave Federation Protocol. Сейчас мы кратко расскажем о тех Google Wave API, которые мы анонсировали во время девелоперского релиза Google Wave на конференции Google I/O.

Google Wave — это новый инструмент общения, позволяющий людям совместно работать в сети более эффективно. Если вы ещё не видели демонстрацию продукта, сходите на wave.google.com и посмотрите, что может Google Wave.

Есть два варианта Google Wave API: Embed и Extensions. Embed позволяет вам встраивать потоки общения из Wave в ваш собственный сайт, пользуясь простым JavaScript API. Например, встроив поток Wave на сайт, вы поспособствуете более активному общению посетителей. Extensions позволяет писать программы, называемые Роботами или Гаджетами, которые обеспечат богатую функциональность непосредственно внутри веб-клиента Google Wave.

Роботы — это автоматические участники, написанные на стороне сервера и выполняющие задачи от имени пользователей, включая синхронизацию данных с другими сервисами. На данный момент Роботы хостятся на Google App Engine, а библиотеки клиентов имеются на языке Java и Python. Мы работаем над более низкоуровневым API Роботов, которое может храниться на любом сервере в сети. Вот пример приложения, которое можно построить — Робот, которого мы ласково зовём "Tweety". Он облегчает использование Twitter внутри Google Wave.


Гаджеты, о которых вы могли знать из OpenSocial, являются программами на стороне клиента, позволяющими писать полноценные приложения внутри Google Wave. Что интересно, мы создали расширение для API гаджетов OpenSocial, позволяющее воспользоваться функцией совместной работы в Wave при написании гаджета. Например, посмотрите на скриншот гаджета с мультиплееровой игрой Судоку (образец доступен на code.google.com):


Если вы хотите узнать больше о Google Wave API, запросите доступ к sandbox, посмотрите на примеры кода и присоединяйтесь к нам на форуме Google Wave API.

Мы уверены, что Google Wave интересен и российским веб-разработчикам. Если у вас есть мысли и соображения по поводу Google Wave, Google Wave API или Роботам и Гаджетам, которые можно написать для этой платформы, оставляйте комментарии!

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

Нашел несколько полезных ссылок, спешу поделиться с теми, кто еще не успел найти подобное.

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

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


Крупный Open Source проект в разработке

В статье рассматривается метод перехвата данных отдаваемых через JSON с использованием метода "__defineSetter__", Этой уязвимости подвержены сайты JSON с которых: содержит конфиденциальные данные (иначе не спортивно), является валидным JS объектом, отдается по GET запросу. Требования к жертве: браузер поддерживает JavaScript, он включен, поддерживается метод __defineSetter__.

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

Бат-файлы лишены возможности передавать по сети какую-нибудь полезную информацию друг другу.

Знаете, фавикончики в ico это как-то прошлый век =) Давайте будем модными, современными и все такое. Короче, берем иконку в png (да-да, с прозрачностью и всеми делами), сохраняем в размере 16×16, на сайте (в блоке <head>, ага) подключаем так:

<link rel="icon" type="image/png" href="favicon.png" />

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

<link rel="apple-touch-icon" href="apple-touch-favicon.png"/>

Над записью витает дух уже почти сгнившего трупа IE6, который вообще не знает о чем это все, ну да и фиг с ним =) Все, изыди.

UPD: Спасибо хабраюзеру NickyX3 за интересное уточнение:

Автор забыл указать, что иконда для springboard тачей и яблофонов будет в таком варианте закруглена по углам и на нее будет наложен блик автоматически самоим девайсом. Для избежания этого (совсем красивая кастом иконка) вместо apple-touch-icon следует написать apple-touch-icon-precomposed.

Рекомендация первая: забудьте про блочную верстку. Весь лэйаут должен быть на таблицах. При этом, без крайней необходимости — их тоже лучше не использовать. Также следует выкинуть из головы представления о семантике, сокращенных css-правилах, валидации, плавающих блоках — и прочее. Самый распространенный в РФ почтовый сервис на данный момент (mail.ru) вообще не понимает стили (css). Любые тэги/атрибуты style заменяются на xstyle и не работают. Вообще все.

Так что, фактически, при вёрстке html для почтовой рассылки надо мысленно переместиться в 90-ые годы прошлого века и смело использовать все распространенные приёмы того времени.

Для тех, кто с ними не знаком (как я был) — напомню:

Сначала повторяем чужие ошибки, потом делаем свои, потом свои же повторяем ) Итак...

Задачи менеджера проекта (лидера) в работе с командой сводятся к повышению эффективности и снижению себестоимости разработки. Эффективность команды во многом зависит от ее участников. Что мешает нам добиться синергетического эффекта? Пробуем разобраться.

В работе менеджера проектов одно из наиболее ценных качеств – это опыт. Именно опыт формирует интуицию, помогает принимать правильные решения и завершать проекты успехом. Чаще всего наш опыт основан во многом на стандартных ошибках, в стандартных ситуациях. При этом, в текучке проблем, мы придумываем нестандартный выход из них (так проще), и забываем воспользоваться устоявшимся опытом многих предшественников, сведенным в систему. Напрасно. Система «в сознании» позволяет принимать уверенные решения, думать на несколько шагов вперед, и не тратить время на эксперементы с людьми. Описанная ниже схема покажется очевидной многим из нас, но часто мы не берем ее во внимание и совершаем ошибки, которые стоят всем денег.

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

Написал и попросил запостить zelenov.
_________

Сейчас каждый новый месседжер вызывает огромный диссонанс в обществе, и многие просто метаются между разными программами. Может, просто нет лидера, а все программы похожи друг на друга как две капли воды?

30 мая 2009 года пройдёт 11-й по счёту ежегодный чемпионат по программированию Internet Problem Solving Contest. Зарегистрироваться можно на официальном сайте по адресу http://ipsc.ksp.sk. Приглашаю к участию всех хабролюдей, интересующихся спортивным программированием.

Некоторые сведения о контесте:

1. Участвовать можно одному или командой из двух или трёх человек. При этом можно использовать для решения задач любое число компьютеров и любые языки программирования. Ведутся отдельные рейтинги для команд из одного человека и команд из школьников. Более подробно читайте в правилах.
2. Задачи по тематике схожи с задачами ACM ICPC, т.е. в основном алгоритмического плана. Отличие от ICPC состоит в том, что в качестве решений на проверку отсылается не исходный код, а выходные данные для заданных входных. У каждой задачи есть два набора входных данных — простой и сложный. За решение простого набора даётся 1 очко, сложного — 2. Задачи, входные/выходные данные и решения прошлых лет можно посмотреть в архиве.
3. Этот контест очень популярен среди «спортивных» программистов. Участвуя в нём, вы имеется шанс посоревноваться с лучшими в мире. Для примера почитайте отзыв Дениса Остапенко об IPSC 2008.
4. Контест длится 5 часов. Даётся 10-15 задач. Время начала в вашей временной зоне можно узнать здесь. По Москве это 16:00.

Здравствуйте. Не так давно в обсуждениях нового сервиса микроблоггинга от квипа (если мне не изменяет память) какой то юзер сетовал на то, что нельзя удалить сервис почты. Мне и самому не подуше такая модель, когда тебе навязывают все сервисы, не спрашивая тебя. Так же была старая претензия к квипу за то, что, переходя на новый qip infium мне пришлось зарегистрировать еще один jabber ID (мне своих 2х и так с головой хватает). Потом я, конечно узнал о так называемом isolated режиме работы qip клиента, и надобность в jabber ID от qip у меня отпала. Но как удалить аккаунт? Если удалять профиль из клиента, то удалятся только данные на локальном компьютере. Зайдя на сайт, в настройках тоже нельзя удалить аккаунт. И тут я вспомнил что у протокола jabber есть возможность удаления аккаунта. Вспомнив, о реализации такой возможности в клиенте Psi, я быстро настроил его на работу с сервером qip.ru, а потом, зайдя в настройки аккаунта, удалил аккаунт с сервера. Вуаля, ни жабера, ни почты, ни микроблогов.

_{Статья приводится в сокращении из-за ограничения на объем материала.}

Для меня программирование — это не только технология, но и, во многом — искусство. И, поэтому, большое значение имеет красота кода.

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

1. Объявление всех переменных в начале программы;
2. Возврат результата функции через ее параметр;
3. Отсутствие локальных функций;
4. Отсутствие else if;
5. Использование параллельных массивов;
6. Хранение размера массива в отдельной переменной;
7. Доступ к свойствам объекта через obj.getProperty() и obj.setProperty(value);
8. Использование рекурсии для вычисления факториалов и Чисел Фибоначчи;
9. Отсутствие именованных параметров функции;
10. Невозможность объявления объектов «на лету».

Наверняка, в некоторых местах вы будете со мной несогласны — ведь чувство красоты у всех разное.

Объявление всех переменных в начале программы

В двух словах:

Переменные должны объявляться в начале логического блока, в котором они используются, а НЕ в начале функции или программы.

Будем считать, что вы уже активно осваиваете хитрости настройки через консоль. Пришло время рассказать ещё несколько тонкостей. О чём имеет смысл подумать при настройке маршрутизаторов и коммутаторов cisco.

Тонкость 1. Аккуратность.
Часто возникает задача что-нибудь добавить в текущую конфигурацию. Наверняка вы знаете, что многие элементы пишутся отдельно, а отдельно применяются (на интерфейс, ко всей железке и т.д.). Будьте крайне осторожны, изменяя настройки таких технологий, как PBR (route-map), QoS (policy-map), IPSec (crypto map), NAT. Лучше всего сначала снять их с использования, потом изменить, потом повесить снова. Связано это с тем, что все изменения вы вносите сразу же в состояние железки. Иногда то, что уже работает (например, подгружено в оперативку) конфликтует с новым конфигом. Не редки ситуации, когда железка уходит в перезагрузку после попытки изменения конфига.

Пример: пусть у нас есть route-map, примененный на интерфейс. Пусть нам надо его изменить. Наиболее «чистый» способ такой: