С тех пор как в семье появился этот домашний зверёк мы совсем перестали покупать хлеб в магазине.

Зато теперь мы закупаем муку всевозможных видов — пшеничную, ржаную, рисовую, разрыхлители, дрожжи, мак и т.д. и т.п.

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

Выпекание занимает чуть больше трёх часов. Оказывается, для хлеба важным является порядок загрузки ингредиентов — важно, сначала залить воду, затем положить соль и другие ингредиенты, затем засыпать муку и в уже самом конце на муку положить дрожжи. Если дрожжи положить в воду — это их убъёт и ничего не получится. Именно так я загубил свою первую буханку. Кстати, сухие дрожжи лучше  покупать в маленьких пакетиках - в больших пакетиках они почемуто работают хуже.

Ещё важно соблюдать правильные пропорции продуктов - стоит немного положить больше воды или дрожжей и хлеб осядет но если положить больше муки то хлеб получится недостаточно мягким и клёклым. Для лучшего результата желательно на кухне иметь электронные весы.

Но зато, если все условия соблюдены идеально, на выходе получается вот такая изумительная буханка:

Приятного аппетита!

Несколько вещей которые мне нравятся у Git в сравнении с Subversion:

1. в Git нет дурацких папочек .svn в каждой директории проекта. Одна папка .git лежит в корне и все!
2. папки можно безбоязненно переименовывать - ведь в них больше нет папочек .svn (см. п. 1);
3. ignore лежит в корне проекта - это удобно;
4. каждый локальный репозиторий одновременно содержит и локальную версию проекта;
5. если квакнется удаленный репозиторий - локальный все равно содержит историю всех изменений;
6. можно использовать несколько удаленных репозиториев;
7. просматривать историю изменений при помощи .git реально быстро - она вся хранится локально;
8. Я так и не научился при доступе через SSH в Subversion обходиться без пароля - в Git правилом хорошего тона является использование ключей шифрования;
9. Git создал Линус Торвальдс — а это дорогого стоит;

Я не люблю Web 2.0.

Хоть по работе я и связан с созданием всяких там Web 2.0 штучек, мое искреннее убеждение, что Web 2.0 хуже по определению чем классический Web. И под Web 2.0 я подразумеваю переход к облачным вычислениям, когда вы запускаете приложение из облака и надеетесь, что оно будет работать как надо. Тоже относится к разным системам шаринга файлов или документов, различные централизованные онлайн чаты.

Я не люблю livejournal - это глупость хостить свои блоги на стороннем сервисе, по мне так безопасней иметь собственный блог на собственном хостинге. Желательно на домашнем сервере.

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

Ребята, что вы будете делать когда интернет сломается? Сегодняшнее падение Skype по всему миру лишний раз подтверждает идею, что Web 2.0 - sux.

Допустим, у вас есть какой нибудь сервер с доступом по SSH. На сервере стоит git. Мы хотим создать некую папку на удаленном сервере, содержимое которой должно синхронизироваться с локальной папкой на домашнем копьютере а также с локальной папкой на другом компьютере, например на работе.

Начнем с сервера (на нем Ubuntu).

1. если git не стоит установим его:

> sudo apt-get install git-core
> git config --global user.name "Uzumaki Naruto" #расскажем немного о себе
> git config --global user.email naruto@uzumaki.co.jp #свой емайл


2. создадим репозиторий

> cd /path/to/the/folder #переходи в папку которую будем шарить
> git init #создаем репозиторий
> git config receive.denyCurrentBranch ignore #это чтобы можно было заливать изменения

3. создаем файл README и добавим его в наш новый репозиторий:

> touch README #создаем пустой файл
> git add README #добавляем его в репозиторий
> git commit -a -m"first commit" #фиксируем изменения

Репозиторий создан. Теперь переходим на наш домашний компьютер. Прежде чем соединяться с удаленным сервером нам нужно залить на удаленный сервер публичный ключ домашнего компьютера чтобы мы могли соединяться с ним без пароля.

> ssh-keygen -t rsa -C"naruto@homeaddress.ru" #создадим ключ если не создан
> cat ~/.ssh/id_rsa.pub | ssh user@remoteserver.com 'cat >> .ssh/authorized_keys' #закинем ключ на удаленный сервер

скачиваем наш репозиторий с удаленного сервера:

> git clone user@remoteserver:/path/to/the/folder

Поздравляю, репозиторий скачан, мы можем отредактировать файл README локально и закачать изменения в репозиторий:

> git status #смотрим что изменилось
> git commit -a -m "local chages" #фиксируем изменения
> git push origin master

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

> git pull #все изменения сделанные дома зальются на рабочий компьютер.

Теперь, если перейти на удаленный компьютер, где лежит оригинальная версия файлов можно заметить, что файловая система удаленного репозитория осталась без изменений, т.е. файл README как был пустой так и остался, вызываем волшебную команду:

> git reset --hard

Проверям, содержимое файла README теперь такое же как и на нашей домашней машине, как и на рабочей машине.

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

Несколько замечаний.

1. для доступа к удаленному репозиторию по идее git не обязателено устанавливать на удаленной машине достаточно иметь к ней доступ по SSH - просто скопировать локально созданный репозиторий на удаленную машину, но в этом случае мы не сможем видеть изменения на удаленном сервере в виде живых файлов.

2. в примере используется SSH авторизация, если нужно чтобы к репозиторию обращалось несколько человек имеет смысл использовать gitosis см: https://help.ubuntu.com/community/Git

Допустим, у вас на Windows машине стоит MinGW (если у вас стоит git то MinGW ставится вместе с ним по умолчанию: Git Bash - это на самом деле терминал MinGW и есть) Если вы имеете учетную запись на github, значит вы уже имете пару ключей шифрования, которые лежат в папке <HOME>/.ssh по умолчанию они называются id_rsa и id_rsa.pub если нет их можно создать следующей командой:

$ssh-keygen -t rsa -C"your@emailaddress.ru"

Непосредственно использовать ключи сгенерированные при помощи OpenSSH в Putty нельзя. Для того чтобы их можно было использовать нужно сделать следующее:

1. открыть puttygen в меню в верхнем меню Conversions->Import Key выбрать сгенерированный при помощи OpenSSH приватный ключ;

2. сохранить закрытый ключ в формате PPK нажав на кнопку Save private key;

Полученный ключ полностью совместим с уже созданным соответствующим открытым ключём - все, что нужно это указать его в поле "Private key file for authentication" на вкладке SSH->Auth при настройке соединения в Putty.

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

Правда, с нового 2011 года, наше государство сделало малому бизнесу отличный подарок — повысило ECН с 24% до 34% всем, и отменила льготы по ЕСН упрощёнщикам — раньше они платили примерно 14%  теперь фирмы на упрощённой системе налогообложения будут платить единый социальный налог как все — 34%.

Думаю, теперь все с радостью будут выходить из тени, открывать свои доходы, и работать легально будет одно удовольствие.

Спасибо за поддержку малого бизнеса! а уж с новым законом о полиции, Россию можно будет на полном основании называть полицейским государством....

Задолбали спамом такого содержания:

Здравствуйте!

Я случайно наткнулся на ваш сайт в интернете - cpage.ru, он красивый но на нем не очень высокая посещаемость.

Предлагаю заняться его продвижением.

Мои услуги стоят недорого - от 6000 рублей.
Возможно оплата по факту, за результат.

Если это может быть вам интересно, пожалуйста свяжитесь со мной:
Телефон: +7 (495)5-1Ч4265
ICQ:  11885  8

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

Мне никак дает покоя Google Charts...

Наиболее популярными библиотеками для построения графиков на сегодняшний день являются JPGraph и Google Charts. Решение от Google - замечательное, удобное, простое, графики очень симпатичные. Однако, все графики генерируются на чужом сервере (речь идет о графиках построенных через URL API). Пользователю разрешается создать ограниченное количество графиков а потом его могут забанить. Конечно, это количество большое, но меня немного смущает сама возможность быть забаненным из за превышения количества показов. Кроме того, сервер гугла я не контролирую и никто не может гарантировать, что этот сервис будет работать вечно, или что завтра на моих графиках не появится реклама, или внешний вид этих графиков не будет изменен на тот, который мне не нравится.

Между тем, задача сделать график на экране компьютера под силу школьнику освоившему курс информатики (мы такое, помню делали в старших классах). Так зачем же отдавать такие "сложные" вычисления серверу гугла?

JPGpaph дает возможность создавать графические изображения на своем сервере, но все равно это — графические изображения, со всеми присущими графическим изображениям ограничениями.

У растровых графиков есть один недостаток — их полная неинтерактивность. На растровый график невозможно добавить эффекты анимации при наведении мышкой, нельзя добавить гиперссылки (imagemap не в счет). Так как изначально природа графиков векторная — лучшим решением будет использовать векторный движёк вместо растрового. У вектора есть несколько неоспоримых преимуществ - не нужно передавать изображения по сравнительно узким каналам связи - передается только сама информация для построения графика, при этом рендеринг изображения происходит на машине клиента.

На сегодняшний день в вебе наиболее популярными являются несколько технологий - Adobe Flash, Microsoft Silverlight и Canvas/SVG/VML. Выбирая между Canvas и SVG я отдаю предпочтение последнему так как эта технология позволяет создавать по настоящему интерактивные эффекты и ближе к VML используемому в браузерах от Microsoft.

Используя ztools создал несколько компонентов для построения различных графиков и диаграмм:

Конечно, эти компоненты еще не совершенны, это даже не бета версия. Но уже лучше чем ничего. Главным отличием от аналогичных являются: открытость исходного кода, простота, и (надеюсь) удобство использования. Замечания, пожелания, багрепорты и фичреквесты приветствуются.

> wget http://subversion.tigris.org/downloads/subversion-1.6.15.tar.bz2

> tar -xvjf subversion-1.6.15.tar.bz2

> wget http://subversion.tigris.org/downloads/subversion-deps-1.6.15.tar.bz2

> tar -xvjf subversion-deps-1.6.15.tar.bz2

> cd subversion-1.6.15

> ./configure --with-ssl

> make

> make install

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

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

В Связьпромбанке мне заявили что после инкассации банкомата денег они НЕ НАШЛИ, это в системе с двойным то учетом, где все операции многократно журналируются. Росбанке оказались люди более адекватные и посоветовали сразу обратиться в свой банк-эмитент, но на всякий случай у них тоже оставить заявление.

Короче, после безуспешных попыток вернуть свои денежки на родине я обратился в саппорт Payoneer. Пробиться в саппорт Paoyner онлайновыми методами сложно, я написал им на support at payoneer.ru и заполнил онлайновую форму, которую нашел на сайте. Описал как было дело, сказал, что в банке мне помочь отказались.

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

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

1. Обратиться в клиентский отдел банка списавшего сумму.
2. Если деньги возвращать отказываются - обратиться в Payoneer.

Саппорт Payoneer'а медленный, но в отличии от наших банков он может реально помочь.