Если вы всерьёз решили заняться учётом личных финансов, то одной из первых трудностей для вас, вероятно, будет сбор данных. В комментариях к предыдущей статье, где я неудачно пытался обосновать саму необходимость манименеджмента, отметились люди с высочайшим уровнем самодисциплины, для которых этот вопрос — не вопрос. Они дисциплинированно день за днём записывают свои траты в мобильный телефон на протяжении многих лет. Лично я за себя могу сказать, что мне никогда это не удавалось, и если быть честным с самим собой, вероятно, никогда не начнёт удаваться в будущем. Поэтому, этот путь явно не для меня.

Привет, Хабр. Появилась внутренняя потребность вновь излить тебе душу. В этой серии публикаци речь пойдёт не про какое-то там унылое IT, а про учёт личных финансов. Но учёт не простой, а в достаточной мере гиковский. Давай под CUT, короче.

Сайту Правдометр.ру на днях исполнилось два года. 19 апреля 2010 года вышла статья на Хабре, анонсировавшая запуск проекта. Можно оценивать результаты, а также неудачи, постигшие проект за это время.

Я люблю ходить по собеседованиям. Ничего не могу с собой поделать. Это занятие мне просто очень нравится.

Во-первых, это челендж. Это даёт мне заряд адреналина. Я доволен собой, когда ухожу с собеседования непобеждённым. Я рад, когда мне удаётся отвечать на все вопросы, когда все каверзные загадки рекрутёров я щёлкаю как семечки. В эти моменты я понимаю, что чего-то стою. В прямом смысле слова. Я стою денег.

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

Здравствуйте, уважаемые хабражители. Я бы хотел, чтобы вы высказали своё мнение по поводу моего маленького проектика.

Все мы следим за новостями, читаем статьи, смотрим интервью. Политики, экономисты, чиновники, политологи, аналитики делают заявления и многое обещают.
Но всегда ли эти обещания сбываются? — нет.

Именно для того, чтобы проверить насколько человек был честен и компетентен, появился проект «ПравдОметр» (www.pravdometr.ru).

Сегодня в очередной раз почувствовал себя идиотом.

В проекте, которым я сейчас занимаюсь мне потребовалось реализовать небольшую подпрограмку, которая бы занималась тем, что мониторила определённую папку (upload) и в случае появления там нового файла оповещала об этом удалённую систему по RPC. (Непосредственно мониторинг я реализовал при помощи inotify)

Так как я люблю ООП и не люблю процедурное программирование системных вызовов opendir и readdir мне показалось мало и я реализовал небольшой набор классов для работы с файловой системой по всем канонам ООП: абстрактный класс FSItem (с методами getName, getPath, с чисто виртуальными методами isFile, isDir) от которого наследуются Directory (с методом append) и RegularFile. Хотя скорее эти классы не служат для работы с файловой системой, а больше для хранения структуры какой-то директории в вот такой модели.

Так вот… Всё это уже реализовано в Boost.Filesystem.

Мораль: надо бы книжку купить по boost, хоть на английском языке (на русском похоже нету). Читать полную документацию по boost на работе правда некогда. (Зато есть время писать в блог… Мда.) А так перед сном можно пару страничек просмотреть и уже умнее стану.

Несмотря на то, что я пишу на Java уже 2 месяца (о да, это срок :) ), я ни разу не запускал remote debugger. При разработке на GWT этого делать и не нужно — оно как-то само всё это делает. :) Но вот настала весна, моё GWT приложения распустилось, и хочет, чтобы я его выложил на сервер. Но вдруг выяснилось, что просто так оно работать не захотело. А почему, я понять не могу. И значит мне нужен дебагер.

Принцип работы наверное любого удалённого отладчика (remote debugger) прост — контейнер (это может быть и какой-либо сервлет-контейнер, и php-интерпритатор. Полагаю, что интерпритаторы Ruby, Perl, Python работают аналогичным образом), который выполняет приложение настраивается таким образом, что при запуске приложения он либо начинал слушать определенный порт, либо сам пытался коннектиться куда-либо.

Я часто вижу на различных не очень хороших сайтах пренебрежение ajax-ом. Бывает это так: форма авторизации переводит пользователя на отдельную страницу, на которой написано большими буквами: «ВЫ АВТОРИЗОВАНЫ!» Или «ВАШЕ СООБЩЕНИЕ БУДЕТ ОПУБЛИКОВАНО ПОСЛЕ ПРОВЕРКИ МОДЕРАТОРОМ». Зачем создавать такие страницы на самом деле? Эта страница не несёт никакой полезной смысловой нагрузки. Смысловая нагрузка осталась на той странице, с которой пользователь перешёл для того, чтобы написать комментарий или авторизоваться. А теперь, он уже может быть забыл для чего это сделал. Я тоже так когда-то делал, когда не знал, что такое ajax. Эти страницы просто занимались обработкой параметров $_POST, и когда пользователь жал F5 на такой странице, post-запрос отправлялся повторно. Я и тогда понимал, что что-то есть неправильное в этом подходе, но что конкретно сказать не мог.

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

И вот недавно я для себя формализовал правила по применению ajax, которым следую неотступно:

• Страницы с полезной информацией генерируются без использования ajax. Традиционные страницы хорошо индексируются, имеют красивый запоминающийся URL, которым можно поделиться с друзьями.
• 2.Все функциональные контролы сайта только через ajax: добавление комментариев, форма авторизации, переключение тем сайта и т.д. Не за чем пользователю показывать страницу на которой одна строчка «Тема вашего блога изменена!» — он и так об этом знает. Кроме того, исключается возможность повторной отправки post-запроса. (Да, кстати, все ajax-контролы, которые изменяют состояние системы обязательно должны отправляться через post, но это тема другой статьи.)

Хз.

Как сделать так, чтобы заработал? А нужно просто писать код, не так как вы привыкли, а как придумали разработчики EPIC. У них в FAQ написано следующее:

#This code block will not work:

$smtp = new Net::SMTP;
$smtp->[no content assist]

#This one will work:

$smtp = Net::SMTP->new(.....);
$smtp->[content assist]


Может быть это и правильно. Перл, на мой взгляд, слишком уж демократичен к code-стайлу. А так получается, какой-никакой стимул к единообразию.

Отформатировать текст не смог. Хабр жрёт тэги и я видимо ламо.

Почему-то так получилось, что я очень активно в вэб-разработке использую 2 языка программирования: это perl и php. Php я использую, естественно собственно для отображения информации в браузере. А на perl я пишу разные утилитки в основном для работы с базой данных, которые запускаются по cron или в рукопашную.

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

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

Писать на perl отображение честно говоря почему-то страшновато. Возможно когда-нибудь я займусь этим. Ещё одна причина, по которой я ещё не перешел на perl основательно — огромное число различных CMS, FW и всевозможных библиотек для вэба написаных на PHP. (В частности я очень много работаю с CMS Битрикс.)

Испытывает ли кто-нибудь из хабра-люда подобные затруднения?

В процессе освоения чрезвычайно простой, но тем неменее необычайно бажной и бездарно написаной фриварной ajax-библиотеки коментариев Ajax Generic Comments Module, я столкнулся интересным и неочевидным для меня эффектом. Комментарии некоторых пользователей на моём сайте отображались корректно, а коментарии других в виде хабразябр. Кодировка сайта по умолчанию utf-8. Но посты некоторых пользователей появлялись в cp1251. Я пытался повторить баг, но не смог этого сделать ни в одном из установленных в моей системе браузеров. (Установлена Linux Debian — это и была моя ошибка. Браузеры: Opera 9, FireFox, Konqueror.) Не протестировав либу только в одном из известных браузеров я понял, что худшие опасения сбываются. Запустил Internet Explorer 6.0 и — эврика. (Есть способ запускать Internet Explorer в Linux — IEs4Linux)

Я приверженец xml. Мне очень нравится подход к проектированию вэб-приложений при котором бизнесс-логика отделена от представления посредствам xml/xslt. Я не сторонник изобретения велосипедов (шаблонизаторов типа Smarty), и вообще, прикручивания рогов и педалей к лопате.

На днях задался целью выяснить каких успехов достигли разработчики браузеров на ниве client side xslt-преобразования. Потому как выполнять преобразование на сервере не интересно — жрутся рессурсы, расходуется канал (что особо важно для пользователей слабеньких каналов и мощных компьютеров). Да и вообще, преобразование на стороне клиента на мой взгляд просто правильнее. Задача отображения документа — есть задача браузера. Вот пусть он этим и занимается.