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

Или по крайней мере стараемся. )
Недавно я представил на суд общественности скрипт, позволяющий экспортировать фиды вместе с подзамочными записями из Livejournal.com.
И сразу послышались голоса разума:

payalnik: Какой нехороший метод открыть подзамки для всего интернета. Ждем первых скандалов.

anton: Вы же понимаете, что, сделав так, рискуете открыть подзамки всех своих друзей публично и через месяц найти их в поиске?

Целый день я ходил и пытался вспомнить: где-то я уже это видел. Кто-то уже рассказывал о подобном. И вспомнил!
А потом и найти источник не составило большого труда:
http://php.vanhecke.info/2008/01/20/republish-a-feed-or-other-data-protected-by-http-basic-authentication

Что касается персонализированных RSS лент, большинство служб не защищают контент требованием вводить логин/пароль, а предоставляют пользователю открытый, но случайный URL ленты.
Для web-based RSS агрегаторов, таких как Bloglines или Google Reader, есть ненулевая вероятность что другие пользователи наткнутся на приватное содержимое ваших лент.
Именно поэтому Bloglines представила директиву <access:restriction relationship=«deny» />
Если лента ee содержит, то Bloglines не будет отображать ее содержимое в открытом поиске.
Тем не менее, автор не нашел ни одного упоминания что Google Reader поддерживает эту директиву. Правда, эксперименты показали, что из-под другого аккаунта найти содержимое ленты с установленной директивой не удалось, хотя лента существует и добавлена уже месяц.

Ссылка на спецификацию: www.bloglines.com/about/specs/fac-1.0

Известно, что SQL — декларативный язык, который указывает, «что» мы хотим выбрать из базы, а «как» это сделать — СУБД решает сама. Задачу выбора для SQL-запроса конкретного способа его выполнения(плана) решает планировщик запросов, который есть практически в любой СУБД. Но иногда он выбирает не самый лучший план. Многие коммерческие СУБД предоставляют на этот случай «хинты», которые позволяют в ручном режиме подсказывать базе, как лучше выполнить запрос. В Open Source СУБД PostgreSQL такого механизма не было.

И вот, наконец, случилось то, о чем многие мечтали и чего уже устали ждать, а другие боялись. Японские разработчики из NTT реализовали хинты планера PostgreSQL. Причем, им удалось это сделать, не меняя ядро, в виде отдельного модуля pg_hint_plan, поддерживающего версии PostgreSQL 9.1 и 9.2. Модуль реализует хинты, позволяющие устанавливать методы сканирования и соединения таблиц, установку значений GUC. За деталями установки и использования добро пожаловать под кат.

Это продолжение серии статей про Firebug.

Весь цикл: Console, Commands, Debugging ,Profiling

Firebug имеет приятную особенность — собственные функции.
Некоторые из них вам уже встречались, например в Prototype.
И чтобы вы не сомневались в том, что все честно, то мы продолжим мучать домашнюю страничку Firebug, т.к. на ней нет подключенных js файлов.

Новичкам в Django будет полезно узнать об очень полезном инструменте отладки — debug-toolbar. Он настолько крут, что его называют Firebug for Django. На больших проектах без него (или другого отладчика) не обойтись.

Продолжение этой статьи

Долгое время в ветках SVN был один существенный недостаток. Система не помнила мержей, и программисту приходилось самостоятельно заботиться о том, что бы сохранить номер ревизии, когда происходило копирование изменений из транка. Проблема частично решалась добавлением комментариев в лог, но все таки это было чревато ошибками, и целиком ложилось на совесть программиста.
В версии 1.5, наконец-то, программисты Subversion выполнили свое давнее обещание, и добавили несколько полезных фич для работы с ветками.
Итак, в версии 1.5 команда merge обзавелась двумя новыми опциями: --record-only и --reintegrate.
Теперь ответственность за контроль копирования изменений ложится целиком на плечи SVN (merge tracking), а программист может легко, и без боязни выполнять merge так часто, словно это команда update.

Привет!

Поговорим о самом удобном shell-е для Linux. Знакомьтесь — это zsh. Многие пользователи Linux не променяют bash ни на что другое, но я, будучи склонным к экспериментам, не поленился и поставил zsh.

Сегодня мы научимся набирать в Vim загадочные и просто редко- (а кем-то часто-)используемые символы, такие как ½, ?, £, ©, ®, ™, «, » и т.д. Особенно полезно это людям, связанным с типографикой, но не только.

Для набора этих замечательных вещей есть много способов, некоторые из них уже были описаны на Хабре. Способы эти сводятся либо к установке специального ПО, либо к созданию собственной раскладки клавиатуры. Ещё можно (во всяком случае, под Windows) запоминать магические комбинации и набирать символы с помощью Alt+цифры_на_цифровой_клавиатуре_если_она_есть.

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

Update: похоже, что после обновления хабра появились проблемы с постингом больших статей. Старый текст, который был здесь ранее, хабр обрезал до середины, залить же новый мне не удалось — все время выдается ошибка «Возникла ошибка в получении XML данных: Internal Server Error» (насколько я понял, проблемы именно в большом объеме). Честно говоря, у меня сейчас нет ни времени ни желания разбираться с этим (к тому же переформатирование статьи из блога под хабр занимает довольно много времени), поэтому отсылаю вас к оригиналу — Очередной HowTo по Vim.

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

Давайте сразу же договоримся — эти советы подходят в основном программерам, ну и, скажем так, сильно технишн людям. Зададимся вопросом — что такое «продуктивность»? Не знаю как вы, а я вкладываю в это слово очень простое значение. Человек продуктивен, когда выполняет необходимые ему действия с минимальным напрягом для себя и максимальной отдачей для других. В случае программера идеально продуктивным является человек, который легко и непринужденно пишет хороший код за минимальное время. Хватит слов — вот вам советы:

1. Никогда не ищите глазами, пользуйтесь функциями поиска. Всегда, всегда используйте поиск, если вы печатаете быстро. Хороший пример — открытие файла в редакторе. Используйте поиск или комплишн (в зависимости от редактора) и вы увидите насколько это быстрее. То же относится к выбору таба/буфера, если редактор не позволяет перейти в нужный буфер — выкиньте его, иначе смотрите в пункт 4. Идеальный редактор работает так — нажимаем кнопочку (в моем случае Ctrl-X + b) и в строке ввода вписываем первые несколько букв открытого в другом табе файла. Завершаем всё нажатием tab и enter. Таким методом я переключаю открытый буфер за 0.2 секунды. Мышью и глазами я переключаю его за 1.4 секунды. Что приводит нас к следующему пункту.

2. Не повторяйте что-либо более 10 раз. Это критическое число для всех разное, для меня оно именно десять. Автоматизируйте. Больше. Чаще, но не увлекаясь глобализмом. Причем не только в коде, в редакторе, в среде, но и в жизни. Нужно разбить 20 куриных яиц? Сделайте коробочку с дырочками и отсекайте острую часть яйца. 11 раз написать триграмматон на заборе? Сделайте шаблон и купите балон с краской. Не забывайте, что клавиатурные шорткаты есть почти во всем софте. Каждый раз когда вы снимате руки с клавиатуры — теряете время.

3. Учитесь скриптовым языкам. Python, Ruby, Perl, Bash, Javascript, CMD, VBasic. Просто хватайте тот, который ближе к вам и пишите-пишите-пишите. Понятно, что выбрать просто, если вы работаете в windows — для вас только CMD и VBasic. Юниксоидам доступно чуть больше, думаю это одна из причин почему гики так активно пересаживаются на Linux. Я знаю, что учиться не легко — но надо. Есть один странный рецепт — попробуйте в течение 2-3 недель работать из консоли. Нет, не надо отказываться от окон и тп — просто откройте окно терминала или cmd и работайте из него, запустив нужный вам скриптовый интерпретатор. И ради бога, никаких far/mc/nc и тп. — ваша цель научиться писать скрипты. После этих 2х недель вы вернетесь к привычной среде с довольно большим знанием о том, как же устроен скриптовый язык. Напомню, для python и ruby есть ipython и iruby. Для perl есть mshell, остальные интерпретируемы сами по себе.

4. Изучите свой IDE настолько, насколько это возможно. В идеале — откажитесь от IDE в пользу хорошего текстового редактора. Я имею ввиду редактора. Например ViM или Emacs. Пользователи MacOS могут использовать и TextMate, однако мне он кажется жалким подобием левой руки (слабой пародией на MicroEmacs). Да, и уверяю вас — оба редактора, и ViM, и Emacs имеют столько возможностей, сколько не снилось любому другому. В то же время оба они прекрасно работают без донастройки, хотя я предпочитаю Emacs. Конечно многие еще помнят что Emacs раcшифровывается как Eight Megs And Constantly Swaping, но 8 метров памяти уже давно перестали быть чем-то из ряда вон выходящим. Окей, вернемся. Выберите редактор. И теперь используйте его везде, где только можно. Вбейте себе в голову — вы используете ТОЛЬКО этот редактор. Потому что достаточно хорошо знать два редактора невозможно. Знатоки утверждают что работая со своим редактором на полную катушку вы получаете буст к производительности в 200-500%. И глядя на Бацека, например, я в это верю. И единственный минус от этого знания только в одном — вы не сможете от этого отвыкнуть.

5. Изучайте технологии и пишите маленькие программки. Выделяйте себе 20-30 процентов времени на ковыряние в новых движках или базах данных. Да, двадцать-тридцать процентов времени. Я знаю что обычно на это выделятся куда меньше — но меня-то не надо обманывать, я ж сам такой был, и хорошо знаю сколько процентов времени программист пишет код. Подвиньте чуть-чуть время, выделяемое вами на чтение LiveJournal и закопайтесь по локоть в Django. Или сядьте и напишите скрипт для накручивания голосов на Хабре. В общем проводите время весело и с пользой. Это сильно помогает отдохнуть на работе не теряя темпа. А главное — это очень неплохо сказывается на структуре вашего кода — теперь вы знаете как и что делают другие.

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

Давно у меня была идея ограничить в правах Firefox, как самое опасное приложение на десктопе, а новости о появления кросс платформенного эксплоита Jinx(http://www.opennet.ru/opennews/art.shtml?num=17217) только усилили мои желания. Я уже использую apparmor для ограничения skype и скриптов на серверах, сегодня решил увеличить безопасность рабочей станции, уменьшив права доступа для Firefox.

Сегодня происходит бум социальных сетей — и на Западе, и у нас первопроходцы разогрели рынок и вполне естественно, что многие стартапщики решили заработать на этой теме. Однако в большинстве случаев дело не идет дальше копирования «Одноклассников» или «Facebook», «только еще с кучей дополнительных фишек», которые, на взгляд их основателей, и должны переманить пользователей с уже раскрученных ресурсов. Тем не менее тема социальных сетей все еще перспективна — нужно просто обратить внимание на нишевые соцсети. Именно они имеют максимальный потенциал, и именно нишевые сети, как показывает практика, наиболее востребованы сейчас покупателями. О такой соцсети и пойдет речь в данной статье, оригинал которой размещен на моем сайте IdeaBlog.ru.

Анализируемый в этой статье стартап CodeIDE.com интересен мне по нескольким причинам. Во-первых, это «наш» стартап (точнее, украинский, но я не разделяю украинцев и россиян). Во-вторых, его основатели нацелены не на русскоязычный, а на глобальный рынок (что является редкостью для стартапов из бывшего СССР). В третьих, интересен путь, которым идут основатели стартапа, развивая свой сервис. И в-четвертых, этот стартап ориентирован на очень перспективный, по моему мнению, рынок. Кроме того, мне интересно оценить перспективу развития стартапа, когда он еще не выложил в сеть всего своего функционала, но при этом я знаю от его основателей как он будет выглядеть в ближайшем будущем. Статья большая, поэтому те, кто не любит читать длинные посты, могут не открывать его.