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

Не найдя ничего стоящего, я взялся написать свой велосипед. И, по-сидев два с лишним вечера, сочинилась небольшая js-библиотека с generic-названием iWet.

UPD: Версия 0.2

• Добавил белую маску. См. Демо.
• Выложил исходик маски в .psd
• Вылечил баг с мельканием картинки при загрузке страницы
• Добавил readme.txt и licence.txt
• Минимальные косметические изменения кода

Недавно на Хабре была опубликована статья под провокационным заголовком и призывом к прекращению изобретений велосипедов в API-строении. Поскольку тема мне интересна, то я просто не мог пройти мимо.
Увы, реальность за хабракатом меня сильно разочаровала — я увидел очередной велосипед, да еще и с квадратными колесами. (Коллеги, ничего личного, только техническое обсуждение.) Правда, авторы честно сказали, что увидели на нескольких сайтах модное слово REST и решили сделать по нему. Только вот поняли они этот «РЭСТ» по-своему, примерно как Дед Щукарь читал и понимал толковый словарь.
В этом топике я призываю по-настоящему покончить с велосипедами в API сайтов. Ведь получается какой анекдот: АПИ разрабатывается для упрощения доступа к сайту и легкости подключения внешних систем, а получается такой, что с ним еще сложнее, чем без него :)

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

В повествовании будут рассмотрены следующие вопросы:

1. Базовые технологии: XML-RPC, REST, SOAP и краткое сравнение
2. Дао вебсервиса
3. Просветленные API
4. Как отличить сайтовое API от говна
5. Выводы

История моего знакомства с этим движком началась очень просто — начальство потребовало корпоративный сайт, при чем желательно на Wiki движке. MediaWiki не прошел по правам доступа, DokuWiki слишком прост, JSPWiki был очень близок, но что-то не нашлось способа скрестить его с доменными учетками. Потом накинулись более важные задачи и на пару месяцев пришлось отложить весь проект.

А потом в один прекрасный день натыкаюсь на опеннете на новость об открытых проектах, которые могут заинтересовать бизнес. Среди них обнаружился MindTouch Deki Wiki. Беглый осмотр показал годность движка. Больше всего удивило то, что я на него до сих пор не наткнулся. Установка с использованием готового образа виртульной машины прошла быстро и безболезненно. Интерфейс симпатичный, страницы редактируются в WISIWIG редакторе. Картинки вставляются с превьюшками, можно развешивать тэги, но это все не главное. Самое лучше в этом проекте — документация. FAQ подробный и полный, рассмотрены нужные и полезные вещи. Английский язык не сложный, команды линукса интернациональны. С помощью этого самого FAQ связал wiki с доменом и дал права по умолчанию доменным пользователям за 30 минут с перерывом на чай. Кроме логина по username подгружает полное имя пользователя. Движок поддерживает расширения, но мне они не пригодились Желающие могут связывать свой вики-сайт с фликром, диггом или гуглокартами.

Из недостатков могу отметить то, что в качестве идентификатора используется имя пользователя, соответственно смена имени — пока трудоемкий ручной процесс апдэйта таблиц. Хорошо, что он описан в том же FAQ. А еще постоянно ругается на оперу, мол не поддерживается и т.д., но на вид функционирует и в ней нормально.

Резюме: Если хочется корпоративный вики-сайт — присмотритесь к Deki Wiki.

изображения взяты с wiki.opengarden.org/Deki_Wiki

Не реально? Реально, если собрать самому и правильно подобрать комплектующие.
А теперь слайды:

В виду достаточно большого парка серверов/свитчей/модемов и иного активного оборудования в конторе, была установленная система мониторинга zabbix и успешно использовалась продолжительное время. Zabbix имеет замечательную возможность отправки уведомлений о возникших проблемах.
Для этого был написан скрипт отправки sms сообщений через шлюз email-to-sms оператора связи, ограничение по количеству смс с одного адреса в сутки было обойдено путем ротации исходящих адресов, работало более или мение сносно, но в последнее время смс сообщения через данный шлюз начали доходить с задержкой порядка 10-15 минут, что уже не очень нравилось.
Итак, было решено организовать отправку уведомлений через собственный GSM-терминал, порывшись в прайсах поставщиков и не обнаружив там подходящих по цене и характеристикам GSM модемов весьма огорчился.
И тут вспомнилось что дома валяется старый Siemens CX65 да еще и data-кабель к нему, после подключения телефона и курения доков по отправке sms сообщений пришел к не очень радостному выводу, оказывается siemens не поддерживает отправку sms в текстовом режиме, команда AT+CMGF=1 возвращает error.
Отправка сообщений в данных аппаратах возможна только в режиме PDU, ради спортивного интереса и для размятия мозгов было решено реализовать эту систему, был написан скрипт для перекодировки в PDU формат сообщений и отправки через телефон.

grep

Многим любителям шела нравится чудная команда grep.
К сожалению, windows нативно не имеет такой команды, по этому некоторые ставят себе наборы различных консольных утилит в *nix стиле, включая grep.

Мне, как любителю посидеть в консоли Windows очень мешало отсутствие грепа, по этому мои скрипты под Win всегда были не так хороши, как могли бы быть. Но мои скрипты должны работать на любой (ну, или почти на любой) Windows, так как же быть?

В одном из проектов необходимо регулярно выкладывать код из ветки stage на staging сервер. Начали делать это вручную — входишь через ssh, делаешь git push origin stage, если нужно — обновляешь базу и затем перезапускаешь apache. К концу этой недели решили, что хорошо бы все эти действия выполнять одной командой. Я прошерстил блоги — сейчас очень активно пишут про использования для этих целей библиотеки Fabric (это аналог Capistrano из Ruby on Rails).

Доброго времени суток!

Еще одна часть серии моих переводов раздела о моделях из документации Django.

Перевод Django Documentation: Models. Part 1
Перевод Django Documentation: Models. Part 2

___Мета-параметры
___Методы моделей
_____Переопределение предопределенных методов
_____Использование SQL
___Наследование моделей
_____Абстрактные базовые классы
_______Мета-наследование
_______Будьте аккуратны с related_names


Перевод Django Documentation: Models. Part 4 (Last)

Обсуждая с различными людьми — в большинстве своём опытными разработчиками — классический труд «Приёмы объектно-ориентированного проектирования. Паттерны проектирования» Гаммы, Хелма и др., я с изумлением встретил полное непонимание одного из базовых подходов ООП — различия классов и интерфейсов.

Долго думал писать или не писать этот топик, но всё-таки решился, ведь все свои :) Надеюсь откликнетесь. Я как-то писал о своём небольшом проекте MountManager, максимальная версия которого 0.2.6. Эта программа вошла в репозиторий Ubuntu и об этом я писал здесь. На kde-apps.org у неё рейтинг 83 и 3800 закачек. Программа переведена на испанский, турецский, польский, португальский, чешский и английский. Каждую неделю мне кто-нибудь из иностранцев присылает баг репорт или пожелания. А некоторые даже пишут рецензии с многими комментариями(Пример). Эти факты говорят мне о том, что подобная программа действительно кому-нибудь да нужна, но одному управлять этим проектом очень тяжело. Поэтому я решил попросить помощи у Вас, уважаемые хабравчене.

Здравствуйте. Сегодняшний топик я хотел написать о том, что механизм анимации в jQuery не эффективен, создает кучу таймеров, каждый из которых работает по отдельности, что приводит к чрезмерно частой перерисовки контента и сильно тормозит браузер, и хотел описать некоторые приемы написания «правильной анимации». В ходе подготовки примеров я понял, что я ошибался. Механизм анимации jQuery действительно не эффективен, создает кучу проблем, но причины этих проблем вовсе не в создании большого количества таймеров, а в нечте совсем другом, и, кажется, я добился замечательных результатов в устранении этих проблем.

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

Всем доброго дня и пятничного настроения.
Хочу поделиться с вами замечательной программой которая спасла мне многие-многие человеко-часы и решила довольно сложную задачу за пару секунд.

Предыстория такова. Слил я как-то все песни Владимира Высоцкого, всего 32 альбома, но кодировка в них была cp1251. Так как я давно для себя решил, что вся информация у меня будет храниться только в Юникоде, cp1251 в такой большой коллекции меня это не устраивало.

Стал я искать, проги для перекодирования. Их и под Windows немного а для Linux-а я нашел только EasyTag. Но производительность моего труда, с использованием данной программы оставляла желать лучшего. На ручную перекодировку одного альбома, у меня уходило полчаса, а автоматизировать процесс у меня никак не получалось. Настройки были мне не совсем понятны и при неверном выборе все кодировки меток могли мгновенно превратиться в не читаемую и невосстановимую белиберду.

Мистер Томпкинс — человек уже довольно приличного возраста. Первое знакомство с ним состоялось в далеком 1938 году, когда физик и одессит Георгий Антонович Гамов опубликовал в Британском журнале Discovery серию рассказов о человеке, который в своих снах попадал в альтернативные миры, где значения физических констант радикально отличаются от значений оных в реальном мире, что приводит к совершенно неожиданным результатам. Так Гамов популярно объяснял концепции современной физики неискушенному читателю. Незадачиливым же соней был тот самый Мистер Томпкинс.

Практически 60 лет спустя Том ДеМарко решил поделиться свой безграничной мудростью и в столь же популярной форме преподнести идеи из Peopleware, написанной в соавторстве с Тимоти Листером. Итогом стал "Роман об управлении проектами", в котором наш старый знакомый Мистер Томпкинс похищается сексапильной брюнеткой Лаксой Хулигэн и увозится в загадочную страну Моровию, где ему представляется возможность провести настоящий эксперимент по управлению проектами разработки программного обеспечения…

В конце каждой главы Мистер Томпкинс подводит итоги и записывает свои мысли, которые, по сути, являются аксиомами и постулатами управления проектами по ДеМарко и Листеру. Разумеется, лучше будет прочесть всю книгу в целом — иначе не понять, как эти принципы применяются в «реальной» жизни. Но если времени нет (или же просто хочется освежить память), то вашему вниманию предагается…

Примечание: ниже представлен официальный перевод статьи «On having Layout» на русский язык. Статья не является окончательной. Этот перевод отражает 9 версию от 23.10.2007.

UPD текст статьи полностью убран в связи с его неконтролируемыми изменениями с момента публикации. Перепечатка доступна здесь

В недавнем посте «Кредитные хакеры»: методика банковских манипуляций
была выжимка методов махинаций кардеров с Бюро Кредитных Историй в США.
В том посте давалась ссылка на полный материалпо этой теме за авторством Кристофера Согояна (Christopher Soghoian). За перевод данного материала я и взялся, так как самому было интересно, да и нашлись еще хабрапользователи, кому было бы интересно почитать.
Так как текст довольно объемный, то решил его публиковать частями по мере перевода.
Содержание
1. Введение
2. Система потребительских кредитов в США
3. Как получить выгоду от кредитной системы
4. Кредитные уязвимости и эксплоиты
5. Предлагаемые улучшения 
6. Заключение

PS ссылки в тексте не переведены и находятся в оригинале перевода.
PS2 спасибо юзеру rusxg, который неожиданно подключился к переводу текста.

Преамбула

Из нескольких способов развертывания Django я сразу отмёл mod_python, потому что мне не хотелось поднимать тяжеловесный Apache. Решил развернуть на легком веб-сервере. На данный момент основных легковесных альтернатив Апачу две — lighttpd и nginx. Первоначально я выбрал первый, но столкнулся с проблемами, связанными с URL. Я подумал, что, может, nginx будет работать получше, и развернул приложение на нём. В этом деле мне очень сильно помог один скринкаст, уже не помню точно чьего авторства.
Всё было отлично, но когда я захотел использовать админку Django(удобная вещь, кстати), меня постигло разочарование — форма логина показывалась, но при попытке войти меня выбрасывало на admin. После получаса гугления, я нашёл топик на небезызвестном форуме Ивана Салагаева, в котором описывалось решение проблемы. После того, как я последовал описанным советам, все заработало на-ура. Представляю вашему вниманию необходимую конфигурацию сервера и Django.

В издательстве Apress вышла книга Beginning Python Visualization: Crafting Visual Transformation Scripts, посвящённая визуализации данных с помощью Python и смежных инструментов. Это уникальная в своём роде работа, потому что на Питоне такие вещи делают довольно редко. Автор книги говорит, что сам искал такое руководство для своей работы, но не нашёл, и ему пришлось разбираться самостоятельно.

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

Самое главное в книге — подробная демонстрация, как работать с известными для визуализации математических и научных данных MatPlotLib, NumPy и SciPy, а также с библиотекой PIL (Python Imaging Library) для простейшей обработки изображений.

Полистать книгу можно в магазине Amazon (по ссылке выше).

На сей раз в статье хотелось бы сказать пару слов о том, как делалась первоапрельская видео-открытка про Баро и Тагара.