Я давний подписчик блога «GTD» (уст. Учись работать).

С 2008 года я активно читал статьи на Хабре и в Интернете и пробовал:
— вставать в 5:00 утра
— делать зарядку
— обливаться холодной водой
— бегать по утрам
— питаться правильно (особенно зачитывался вегетарианством)
— вести свои делало системе GTD (Things установлен на всех гаджетах :)
— выключать компьютер вовремя (хотя бы до 23:00)
— ну и конечно, сделать 100 отжиманий и кубики на животе…

Ммм… Вы уже наверное догадались через сколько дней заканчивались порывы моей души и все возвращались на круги своя? :) Я думаю не ошибусь, если скажу, что таких как я очень и очень много.

Что изменилось в январе 2012 года?

Рано… в начале кратко обо мне:
— Возраст: 26 лет;
— Семейное положение: женат (с февраля 2012), детей пока нет;
— живем отдельно в Санкт-Петербурге.
— Работаю в офисе 5 дней в неделю с 8:30 до 17:30.
— Иногда задерживаюсь, но не часто.

Если Вы считаете, что опыт Вам не подойдет… Ваше право, но мы же понимаем, что оправдания всегда можно придумать? Я их придумывал лет 5. Я знаю о чем говорю.

Задача: как получить деньги от другого человека здесь и сейчас?

Вы оказываете услуги, но при этом не предприниматель. Вы решили что-то продать. Вы расплачиваетесь за всех. Вам нужно погасить задолженность по кредитной карте. Вот лишь небольшой список тех ситуаций, когда нужно передать деньги от одного человека другому.
Вообще вариантов передачи денег несколько: отдать наличными, перевести электронными деньгами, оформить платеж через интернет-банк, сделать перевод с банковской кары на банковскую карту Visa или Mastercard. Каждый способ по-своему хорош, но карты все же рулят!
Мне было интересно сделать review российских сервисов P2P-переводов по банковским картам.

На Июль 2013 г. найдено 6 сервисов по переводу средств с карты на карту по технологиям Visa Money Transfer® и MasterCard MoneySend®:

• MasterCard Mobile
• Qiwi
• Альфа- Банк
• RuRu
• PayOnline
• Русский Стандарт

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

Когда я только перешёл от офисной работы к домашней, первое время был на седьмом небе от счастья. С ума сойти – можно спать столько, сколько хочется! Можно работать тогда, когда есть «стих», а когда его нет – ходить дышать воздухом и развлекаться так, как только в голову придёт. Не счастье ли это? Примерно полгода я провёл в таком состоянии постоянного кайфа, а потом постепенно начал привыкать. А дальше началось то, что обычно бывает у большинства узников «домашнего офиса». И вот, через полтора года такой жизни я задался вопросом – а так ли уж хороша она у меня, как казалась вначале?

От переводчика: данный текст даётся с незначительными сокращениями по причине местами излишней «разжёванности» материала. Автор абсолютно справедливо предупреждает, что отдельные темы могут показаться читателю чересчур простыми или общеизвестными. Тем не менее, лично мне этот текст помог упорядочить имеющиеся знания по анализу сложности алгоритмов. Надеюсь, что он окажется полезен и кому-то ещё.
Из-за большого объёма оригинальной статьи я разбила её на части, которых в общей сложности будет четыре.
Я (как всегда) буду крайне признательна за любые замечания в личку по улучшению качества перевода.

Опубликовано ранее:
Часть 1

Сложность

Из предыдущей части можно сделать вывод, что если мы сможем отбросить все эти декоративные константы, то говорить об асимптотике функции подсчёта инструкций программы будет очень просто. Фактически, любая программа, не содержащая циклы, имеет f( n ) = 1, потому что в этом случае требуется константное число инструкций (конечно, при отсутствии рекурсии — см. далее). Одиночный цикл от 1 до n, даёт асимптотику f( n ) = n, поскольку до и после цикла выполняет неизменное число команд, а постоянное же количество инструкций внутри цикла выполняется n раз.

Я люблю слушать музыку и узнавать новых исполнителей. Так получилось, что музыку я слушаю целиком альбомами, а про новых исполнителей узнаю через FunkySouls и LastFM. Некоторое время я слушал музыку через Prostopleer и Muzebra, пока ими можно было пользоваться. А еще я уже один раз делал приложение для ВКонтакте и неплохо поработал с их API. В общем я решил сделать небольшой мэшап и кажется получилось круто.

Listen! — это новое приложение для Google Chrome, в котором можно слушать и искать музыку ВКонтакте, сохранять ее в облако Google Drive для прослушивания без интернета и даже скачивать ее на компьютер (sic!). А с помощью базы данных от LastFM можно знакомиться с альбомами целиком, а также похожими исполнителями.

Эта статья задумана мной как сборник некоторых интересных моментов по использованию и оптимизации SQL запросов в БД MySQL, на мой взгляд, плохо освещенных в интернете. Так, из статьи вы узнаете о конструкции with rollup, и о том, как переписать подзапросы in и not in на join'ы, а так же обновление и удаление данных в нескольких таблицах — одним запросом, и многое другое. Начнем по порядку.

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

• возможность наблюдать через интернет
• не обязателен режим реального времени, достаточно вечером просмотреть основные события за день (скажем, узнать, сидит ли кто-нибудь за вашим любимым компом, пока вы на работе)
• отсутствие необходимости тратить часы на отсмотр результатов
• максимально возможное качество картинки
• минимальная стоимость

Исходя из критериев, можно было бы остановиться на готовых решениях в виде IP-камер. Однако, проведенный на скорую руку анализ рынка показал, что в устройствах, стоимостью до $100, размер картинки редко превышает 640x480 точек, и, при этом, они не могут похвастать хорошими возможностями для настройки софта. То есть, вполне возможно, что купив такую камеру, вам придется мириться с кривизной заводской прошивки и невозможностью в полной мере реализовать свои замыслы.

В противовес готовым решениям, самоделка на Raspberry Pi – это достаточно недорого, куда более увлекательно, и гораздо более гибко, благодаря полноценной ОС на борту и терабайтам готового софта на любой вкус.

Утром 1 октября 2013 года календарь проделанной работы над открытым исходным кодом, расположенный на моей гитхабовской странице, выглядел вот как:



Это не было простой случайностью. Я нарочно решил (руководствуясь GTD-соображениями) достаточно долгое время стараться каждый день чего-нибудь делать на Гитхабе, а затем (если дело пойдёт) поделиться на Хабрахабре наиболее ценными впечатлениями от именно такой манеры работы (назовём её, скажем, calendar-driven development), когда впечатления накопятся.

И поделяюсь.

(Вы не любите Seagate? Вы просто не умеете их готовить!)
Для NAS пришлось купить HDD 3TB WD Caviar Green IntelliPower (других трёшек просто не было). Руки привычно взяли «напильник» и начали «снимать фаску», из глаз слёзы обиды — семь с половиной тысячи за ЭТО. Да «гарантия», да RAID5, но держать в уме предстоящий через 6-8 месяцев ребилд 6 террабайтного массива?! И тут новость о снижении вендорами сроков гарантии. Нет, я отлично понимаю, почему уменьшают гарантию,- ЭТО работать вообще не должно. Но почему не повышают качество изделий? Впрочем, и это понимаю,- надо чтобы продавалось много, а не работало долго. А то вот мои три 2ТБ Барракуды уже второй год под торрентом 7/24 работают и не бэдят, а Seagate голодает.
И так, если вас греет гарталон — этот топик вам будет не интересен. Если у вас RAID6 из Seagate 7200 Constellation ES — ваше время слишком дорого стоит, что бы читать такие мелочи. Если вы потратили свои кровные и хотите «что бы не было мучительно больно» — загляните под кат, может найдёте что-то полезное.

Доброго времени суток, уважаемые хабровчане.

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

Благодаря этому опыту, а также счастью работать в полностью ITIL-compliant организации, у меня сложился ряд представлений о том, как должна вестись работа (речь скорее о внутренней «кухне»). Хотелось бы ими с Вами поделится. На их правильности я не настаиваю, однако такое «кредо» очень здорово помогает мне (а, соответственно, и моему работодателю) вести успешную работу и не переставать радовать клиентов.

Все остальное — под катом.

Все мы наслышаны о красивом коде. Книги и страницы специализированных ресурсов пестрят рекомендациями, стандартами и просто хорошими советами. Современные языки предлагают множество путей изящного выражения идей разработчика. Вообще все хорошо. Вроде бы. Но реальная жизнь сурова. По ряду вполне объективных причин только самые счастливые из нас имеют возможность работать с действительно качественной кодовой базой. Большинство же, зная чуть ли не все подробности идеального способа работы, живут здесь и сейчас, за пределами рая, довольствуясь имеющимся.

Но как сделать свою жизнь лучше? Как заставить уровень качества кода расти. Приведу несколько собственных правил-размышлений на эту тему.

Здравствуйте, уважаемые хабравчане.

Вот уже несколько месяцев ковыряюсь в прекрасном продукте FreeSWITCH. Он не перестает меня удивлять функциональностью, надежностью и производительностью (даже в тех областях, в которых от него этого не ждешь).

Один из моих экспериментов, который в скором времени, скорей всего, перейдет в продакшн касался изумительной, с моей точки зрения, функции mod_sofia recover. Функция recover позволяет FreeSWITCH (FS) восстановить вызовы после краша или же, если FS работает в высоко доступном кластере подхватить вызовы на второй ноде! ВНИМАНИЕ! без обрывов вызовов абонентов, как в случае проксировании RTP, так и без него.

Реализуется это достаточно просто, благодаря использованию внешней СУБД и настройкам mod_sofia, отвечающего за SIP стэк. Т.е. mod_sofia хранит всю информацию о текущих вызовах во внешней БД, и при краше у второй ноды кластера есть возможность эти настройки прочесть и подхватить вызовы.

У меня есть стационарный ip телефон, и раутер под ubuntu-server раздающий интернет. Проблема в том, что телефон отдает свой локальный ип (192.168.0.6) sip серверу, и соответственно дозвонится мне уже не возможно. Проброска портов здесь тоже не поможет.
Первое что пришло в голову — завести Asterisk PBX (программная АТС), но данное решение кажется избыточным для дома с одним телефоном, одним SIP провайдером и без FXO интерфейса. Совершенно случайно нашел небольшую утилиту реализующую как раз-то, что нужно: siproxd. Данная программа есть в репозитории дебиана и убунты.

Настройка siproxd.conf:

Если в один прекрасный день вам придется на скорую руку разобраться, что есть VoIP (voice over IP) и что значат все эти дикие аббревиатуры, надеюсь, эта методичка поможет. Сразу замечу, что вопросы конфигурирования дополнительных видов обслуживания телефонии (такие как перевод вызова, голосовая почта, конференц-связь и т.п.) здесь не рассматриваются.

Итак, с чем мы будем разбираться под катом:

1. Базовые понятия телефонии: типы аппаратов, схемы подключения
2. Связка SIP/SDP/RTP-протоколов: как это работает
3. Как передается информации о нажатых кнопках
4. Как происходит передача голоса и факсов
5. Цифровая обработка сигналов и обеспечение качества звука в IP-телефонии

Статья ориентирована на начинающих пользователей Asterisk, которые, тем не менее,
имеют знания о работе компьютерных сетей на уровне CCNA и которые изучали основы IP-телефонии без специализированных курсов.

Оптимизация явно не является коньком MySQL сервера. Цель данной статьи объяснить разработчикам, которые плотно не работают с базами данных и иногда не понимают, по какой причине запрос, который успешно отрабатывает в других СУБД, в MySQL безбожно тормозит, каким образом оптимизируется конструкция between в MySQL.
MySQL использует rule based оптимизатор. Зачатки cost based оптимизации в нем конечно присутствуют, но не в должной мере, в какой их хотелось бы видеть. По этой причине часто мощности получаемых после применения фильтров множеств вычисляются неверно. Это приводит к ошибкам оптимизатора и выбору неверного плана выполнения. При чем полученные between оптимизации невозможно изменить явным указанием: индексов для выполнения запроса и порядка соединения таблиц.

Есть задачи, которые в рамках реляционных СУБД не имеют универсальных решений и для того чтобы получить хоть какой-то приемлемый результат, приходится придумывать целый набор костылей, который ты потом гордо называешь “Архитектура”. Не так давно мне как раз встретилась именно такая.

Предположим, имеется некоторые сущности А и Б, связанные между собой по принципу One-to-Many. Количество экземпляров данных сущностей достаточно велико. При отображении сущностей для пользователя необходимо применить ряд независимых критериев, как для сущности А так и для сущности Б. Причем результатом применения критериев являются множества достаточно большой мощности — порядка нескольких миллионов записей. Критерии фильтрации и принцип сортировки задается пользователем. Как (я бы ещё спросил: Зачем им миллионы записей на одном экране? — но говорят надо) показать все это пользователю за время 0 секунд?
Решать такие задачи всегда интересно, но их решение сильно зависит от СУБД, под управлением которой крутится твоя база данных. Если у тебя в рукаве козырной туз в виде Oracle, то есть шанс, что эти костыли он подставит сам. Но спустимся на землю — у нас есть только MySQL, так что придется почитать теорию.

Начиная с версии 5.1 в MySQL появилась такая полезная фича как партиции. Конечно же большинство разработчиков БД сразу не побрезговали ей воспользоваться. Спустя пару лет работы я наконец пожал плоды всей ущербности реализации этой технологии специалистами MySQL AB …

Параллельно с развитием технологий защиты интернет-трафика от несанкционированного доступа развиваются и технологии перехвата защищенного трафика. Перехватить и изучить незашифрованный трафик пользователя уже давно не составляет труда даже для рядового юзера. Практически каждому известно слово «сниффер». Теоретически, защищенные SSL/TSL-соединения перехватить обычными средствами невозможно. Но так ли это?

Предыдущие статьи по SIP:

1. Взаимодействие клиентов SIP. Часть 1 (Простое взаимодействие)
2. Взаимодействие клиентов SIP. Часть 2 (Взаимодействие с использованием Proxy-сервера)
3. SIP URI и URL. Часть 1 (URI, URL и URN)

В первой части статьи мы разобрались, что такое URL, URN и URN. Пришло время поговорить о URI и URL, используемых в SIP.