Существует два способа взаимодействия со скайпом. Первый и основной - SkypeKit. Это набор из бинарного ядра, заботливо собранного мейнтейнером для всех ОС, и биндингов к нему на питоне, джаве и плюсах. Все это доступно по подписке, которая стоит 5 долларов разовым платежом и поставляется со скудной документацией, которая представляет собой скорее описание API (нам не привыкать к Epydoc, ага), да и то не всех методов и свойств. Зато в нагрузку вы получите с десяток разных предупреждений о секретности и конфиденциальности полученных файлов. А вот качество реализации очень хромает, ваш покорный слуга так и не смог найти тот event, который поднимается при получения запроса на авторизацию. В интернете, что характерно, информации тоже сущие крупицы и, в большинстве своем, по биндингу на C++, но, разобравшись со всем необходимым функционалом методом проб и ошибок, вы получите доступ к абсолютно всем функциям Skype. Ну и для запуска бинарника ядра из SkypeKit SDK в той же Linux версии никакие иксы не нужны, что тоже заметное преимущество перед вторым способом - Skype API. Этот вариант представляет из себя набор протоколов взаимодействия с скайповым гуем через Skype.framework для MacOS, X11 и DBUS для Linux, COM-интерфейс на Windows. Основные минусы: острая необходимость в запущенном клиенте, который жрет ресурсы и требует наличия иксов, ну и относительная глючность, сравнительно с первым вариантом. 

Возможно, данная статья должна была увидеть свет где-то год, а то и два года тому назад, а в наши с вами времена покорения космоса подобные размышления уже отдают не первой свежестью, но, тем не менее, только теперь у меня появилось время опробовать платформу гугла под разработку ресурсоемких приложений в облаках и повосхищаться ее возможностями и продуманностью. Я не буду детально останавливаться на описании самой технологии, об этом тонны книг и тысячи блогов уже написали, а лишь расскажу о плюсах и недостатках, ну и в конце поста - приведу пример и код реально работающего приложения. Скажу сразу, до знакомства с Google App Engine у меня уже был накоплен значительный опыт работы в облачных сервисах, преимущественно от компаний Amazon и Rackspace, а значит сравнивать мне есть с чем, хотя сравнение тут не особо уместно. Если вам все же лень читать описание всех этих клауд компьютингов, то постараюсь объяснить просто. Гугл предоставляет свою платформу, что-то вроде обычного шаред хостинга или готовый environment скорее, на котором уже установлены практически полнофункциональная версии Python и значительно куцая версия Java, которые обвешаны сверху разным API от гугла, в частности это интерфейсы хранения бинарных данных в BlobStorage, хранения табличных данных (как сложно писать тех. статью на русском, table data все же звучит как-то привычней) в подобии (еще раз, подобии, relation-ы тут реализуемы с помощью референсов, а это не совсем то) реляционной БД интересно объединенной с key-value стореджем в виде DataStorage, свой UrlFetch, своя реализация cron-а и многое другое. Лимитами же являются полное read-only операций с файловой системой и определенные ограничения в использовании системных ресурсов в виде процессорного времени, трафика и такого прочего, что, впрочем, стоит сущие копейки и элементарно докупается при первой надобности и применимо к аналогам-конкурента. Что касаемо того же Amazon EC2 или Mosso Rackspace, то вы получаете свой instance в виде голой операционной системы, которую должны настроить и запустить свой сервис на ней. Является ли это преимуществом? Однозначно, ведь вы, по сути, ограничены только материально и, как следствие из первого ресурса, лимитами облачной машины, которую сами и купили купили. К тому же, переносимость проекта на амазоновских или рэкспейсовских облаках не создает никаких проблем, в то время, как GAE - уникальная в своем роде платформа и без кардинальной смены кода вы никуда от нее не уйдете (нет, уйти то конечно можно, но не далеко и на костылях). Вот тут на самом деле вам может серьезно пригодится MVC паттерн для вынесение модели вне логики, на всякий пожарный. Что же до недостатков амазоновских иластиков - есть и такие. В частности, необходимость настройки программного обеспечения, его оптимизации и наличие прокладки в виде ОС между массивом облаков с виртуализацией и процессом пользователя дает меньшее быстродействие. Но, как я уже говорил, платформы абсолютно разные. Если GAE - только веб приложения, то AEC2 - все, что можно запустить в linux\windows окружении. Если вообще простым языком говорить, то в случае с GAE вы работаете на стройке, где уже готов фундамент и можно строить что хочешь, но только кирпичами и цементом гугла, которые строго ограничены и за превышения квот нужно платить, зато фундамент настолько крепкий, что не рухнет даже при землетрясении, т.к. выстроен профессионалами, то в AEC и иже с ним у вас есть площадка земли, вы можете завести те же кирпичи, вырыть котлован, построить дом, но нет никаких гарантий, что он не рухнет от ветра потому что вы забыли домешать песок в цемент или ваш root пароль брутфорсится за пол часа. Зато на этой же земле можно ничего и не строить, а засадить все цветами. В то время, как с гуглом такой номер не пройдет.

Существуют и более серьезные недостатки GAE, как, например, невозможность привязать к своему приложению naked домен. Ну в смысле без сабдомена www, все это связано с технической особенностью, когда load balancing осуществляется с помощью направления всех запросов через CNAME ghs.google.com, а CNAME не может быть прилеплен вместо главное A записи. Приходится делать фитны ушами и искать дополнительные www-лайзеры или url-форвардеры, которые будут перенаправлять все запросы с голого домена на www, что само по себе противоречит идее распределения нагрузок, все эти сабдомены - прошлый век, как по мне. Еще есть некоторые глупые лимиты касаемо максимального куска данных, получаемого urlfetch за раз, лимит времени исполнения в 30 секунд, достаточно бородатая версия питона и django, кривая реализация сессий и много других спорных моментов. Впрочем, в отличии от конкурентов, гугл дает нам бесплатный аккаунт с квотами, которых хватит для маломальского приложения с головой, лишая нас проблем с бекапом данных, постоянными обновлениями серверного ПО, переживаниями по поводу новой уязвимости в apache или mysql, provision control (тут он хоть и примитивный, но удобный деплой с возможностью запуска нескольких версий приложения на разных сабдоменах аппспота) и такого прочего. Ну, пожалуй, хватит переливать из пустого в порожнее. Вернемся к реальному применению платформы GAE. У меня есть свой укорачиватель ссылок, который крутится на домене mclnk.me. Просто однажды были у меня сертификат на свободный домен и много времени, а хотелось ссылку короче битли и с просмотром контента типа роликов ютуба и картинок. До недавнего времени, она (обрезалка, укорачивалка - как хотите), как и весь этот блог, была написана на PHP и кушать особо не просила, но, путем случайного выбора, стала кандидатом на перенос себя в облака Google. В качестве языка реализации я выбрал Python. Он мне нравится с момента далеко знакомства в его бытности еще сырым языком первых версий, именно на данном инструменте должны учить программировать студентов, а не засорять их головы бейсиками да паскалями. Питон учит лаконичности, правильной разметке кода и дзену программирования. А вот второй вариант, Java, мною нелюбим за его избыточность. Нет, я конечно понимаю, что это обусловлено исключительно добрыми побуждениями и минимизирует вероятность возникновения ошибок исполнения в дальнейшем, но писать несколько экранов кода для элементарного функционала при ограниченных ресурсах времени, не седых пока еще волос и энергетиков мне не кажется целесообразным. Код приложения выглядит подобным образом, прошу прощения, что все навалено в кучу и пару раз я схалтурил (как при проверке валидности ссылки, например), но делалось это в прямом смысле на коленке левой рукой. Укорачиватель ссылок публично доступен по адресу http://mclnk.me, а результат обрезания выглядит подобным образом http://mclnk.me/e.

В качестве заключения, у GAE есть своя ниша, ведь достаточно мощный RDS (lighttpd + php-fcgi + mysql на другом хосте) начинал захлебываться с la под 2 при ab -n 1000 -c 500, а вот google hosted проглотил и даже не подавился, подняв 25 инстансов для обработки запросов и отдав все без дилеев (речь сейчас не об link shortener, разумеется). Много пока еще не хватает, тот же Google Storage, который сейчас только по инвайтам и, если верить слухам, должен стать серьезным конкурентам Amazon S3, но Roadmap проекта внушает хорошие надежды в светлое будущее. Подумайте только об одном, а нужно ли вам это? Или пусть дальше ваш уютненький бложек живет на хостинге по $3 в месяц? Я же просто попробовал это just for fun и решил для себя, что следующий крупный проект с уверенностью можно поднимать на платформе Google App Engine, сэкономив деньги, нервы и бесценное время. 

Прежде чем начинать свое повествование, маленькое сообщение для всех, кто прочитал топик поста и закачал убеленной сединой\лысиной головой с неприкрытым укором: да, я знаю о существовании BIND и да, я знаю про MySQL BIND SDB, или даже про MyDNS тоже слышал, и настроить кеширующий child неймсервер умею. Увы, реализация такой комбинации не виделась мне целесообразной по ряду причин о которых я не буду тут писать. В любом случае, мне нужно было сделать DNS с фильтрацией определенных доменных имен с хранением списка этих имен на центральном сервере в MySQL базе данных. Нужно было сделать его не намного медленней родного варианта, что было вполне нетривиальной задачей. Думаю, что для начала мне стоит объяснить, зачем это все задумывалось. Как упоминалось в прошлом посте, я работаю в компании основным направление деятельности которой является предоставление сервиса защищенного VPN туннеля для обхода корпоративных фаерволов, шифрования трафика, защиты от man-in-the-middle и прочих мерзких снифферов, получения своего личного реального IP где-то в странах экваториальной Америки, ну и для защиты от вирусов с помощью решений от тов. Касперского. В качестве серверных площадок используются разнообразные virtual dedicated и root dedicated от разных провайдеров по всему миру. И вот тут возникает основная проблема, которая загубила большинство подобных сервисов - торренты. Да, в большинстве TOS-ов большинства хостеров ясно прописано, что если с вашего сервера будет замечена подозрительная активность по загрузке из интернета нелегального контента, то вы автоматически лишаетесь предоставляемой услуги без какой-либо надежды на материальное возмещение. Звучит достаточно печально, учитывая предоплату на целый год. В итоге, часто получаешь подобные письма, рассылаемые полуавтоматическими системами правозащитных ищеек, что не добавляет хорошего настроения в твой и так не особо веселый рабочий день. Каким образом они отслеживают попытку скачивания торрента? Fake Seed к примеру? Или просто фильтруют запросы к торрент трекерам? Я без понятия, но вот если правильным образом не среагировать на подобное письмо, убедив хостера, что этот мудак, качающий Спанжбоба, физически устранен, а вся его семья стерилизована - можно получить серьезные проблемы. Вплоть даже до судебного разбирательства, все мы новости читаем. Это проблема, теперь поговорим о решении. Любой системный администратор скажет вам, что не существует оптимального решения перекрытия кислорода p2p трафику. Да, можно ограничивать количество udp сессий одного хоста (что достаточно глупое решение, учитывая саму природу протокола с неявным закрытием соединения), можно вообще закрыть udp (что еще глупее, одним махом лишаем пользователя всяких скайпов\сипов, а торрент клиенты могут спокойно и через TCP работать), можно использовать всякие модули фильтрации уровня iptables вроде ipp2p, OpenDPI, l7-filter (на сайте пишут про высокий perfomance, но у меня la вскакивал до 1 при 10 соединениях и иногда всплывали defunct зомби) или вообще пускать весь трафик OpenVPN  в лоб через фильтрующий прокси сервер (мною было опробовано все из списка, увы, все решения крайне требовательны к системным ресурсами из-за необходимости прочесывания регулярками большого потока данных и по этой причине не подошли, не все сервера в сети могли позволить себе такую роскошь). Есть еще решения для дураков: закрытие типичных портов, что не работает в условиях современных клиентов и тот вариант, который выбрал я - DNS блокировка главных торрент трекеров. Защита ужасная, ничто не мешает клиенту после подключения выставить вместо присваиваемого неймсервера какой-то другой, данное решение к тому же не помогает, если пользователь начал скачивание торрента до подключения к нашему VPN-у (хотя моя практика показывает, что в таких случаях правозащитные ищейки молчат, что еще раз служит подтверждением конспирологической теории, что софт копирайтеров просто отслеживает announce запросы к трекерам), и конечно же данный вариант не спасает от DHT, которому вообще ничего не нужно: ни трекеры, ни днсы. Но работает же, количество писем от правообладателей сократилось до 1-2х за 3 месяца, возвращаем NXDOMAIN для всех доменных имен в блеклисте и живем припеваючи. Кстати, если кто имеет идеи, как побороть bittorrent в сети - скиньте мне хоть пару строк на mail@smirnoff.sumy.ua, чтоб я примерно знал, куда копать. С меня благодарности в приемном для вас эквиваленте.

Возвращаемся к теме реализации. Прежде всего, отвечаю на вопрос: зачем мне нужно много неймсерверов, а не один центральный без всех этих заморочек с MySQL и т.д. В качестве master мы будем использовать Google Public DNS, на нем был замечен load balancing для некоторых крупных сайтов, на запрос по тому же ютубу с разных географических точек отдавались разные A-записи. К тому же, проводить NS query с гонконгского сервера через туннель на центральный сервер где-то в Люксембурге или США - очень медленно, поэтому наши DNS-ы будут отвечать по тому же адресу, что и шлюз. Языком реализации стал Perl. Почему? Да просто в нем есть все необходимые нам компоненты. Использовать мы будем Net::DNS для резолвера и Net::DNS::Nameserver для сервера. Разумеется, без кеширования никуда. В качестве решения я советую смотреть в сторону Cache::Bounded, которое является по сути оберткой вокруг Cache::MemoryCache с оптимизацией и обнулением кеша по достижению определенного размера, что спасет нас от переполнения памяти. В результате получилось что-то вроде такого кода. Сразу замечу, что 3 цикла for при чтении ответа из кеша - необъяснимая мною мистика. Казалось бы с помощью тех же элементов исходного массива путем перебора формируем новый, а вот простое присваивание - не работает. И хоть ты тресни. По скорости вполне нормально, первый запрос конечно отнимает определенное время, но в дальнейшем из кеша в памяти все читается очень быстро. В качестве бонуса, держите список из 1800 самых крупных торрент трекеров для блокировки.

Как по мне, сервисы vpn туннелей должны служить исключительно 2м целям: скачивание торрентов в странах, где за это находят и бьют по рукам; и просмотр католическими священниками детской порнографии там, где это тоже не особо приветствуется. Первых случаев становится все больше, а последних - все меньше. Мы же нашим TOS-ом запрещаем основные приоритетные направления. А все остальные истории с  защитой вашей информации, все это сказки для детей. Мы то с вами знаем, что от паяльника еще ни один фаерволл или канал с шифрованием не спасал. 

В качестве предыстории: я в поте лица и прочих не менее неудачных частей своего бренного тела работаю на славу, процветание и доброе имя компании, которая занимается разработкой "убийцы http://hidemyass.com/" и доброго десятка подобных ему сервисов. О развертывании и структуре сети vpn серверов на базе openvpn, борьбе с torrent трафиком, тоннами спамма, дешевыми vds-ками, индусским англоговорящем на китайском саппортом и прочими прелестями я напишу чуть позже, сегодня мы поговорим с вами об анонимайзере. Вас ист дас, Фальдемар? Дас ист такой себе быстрый браузерный "прокси", что-то типа http://www.hidemyass.com/proxy/, вы вводите ссылку, скрипт скачивает ее и отдает вам, минуя ограничения корпоративных firewall-ов например или скрывая ваш user-agent (кому в хуй ввалился ваш юзерагент, простите? ох уж эта paranoia™). В Педевикии есть много текста по данной теме. Как по мне, между нами девочками, - абсолютно ненужная затея, учитывая все сложности ее функционирования. Но, имей мое мнение хоть какой-либо удельный вес, мы бы сейчас занимались производством русского студенческого качественного порно, а не разработкой сервисов анонимности и безопасности в сети. Что достаточно грустно, спрос на порнуху все же много больше, ящетаю. Игнорирование потребностей рынка ведет нас в глухой угол.

Хиханьки-хахоньки, но изначально были осмотрены 2 бесплатных решения. PHPproxy и Glype. Вот только как-то не удалось мне получить дозу эстетического удовольствия от внутренностей и что самое главное - быстродействия, ну пацаны, 30 регулярок на 1 страницу - как-то слишком, ага. Да и совместимость с современными сайтами, расфуференными AJAX-ами, оставляла желать лучшего. Пришлось писать собственный велосипед. Сразу прошу простить за PHP, увы и ах, но таковы требования заказчиков для "глубокой интеграции" этого говна в глотку сайта. Прежде всего, я отказался от передачи URL проксимизируемого сайта в GET переменной, избрав более интересный путь. Для наглядного примера, данный блог, открытый посредством моего web-прокси, выглядит как https://mindcollapse.com.proxy.domain.com/blabla.html. Плюсы такого элегантного решения: удобная работа с кукисами, которые просто можно назначать данному сабдомену, а не хранить во временных файлах, как это делали вышеназванные реализации, легкость подмены ссылок в странице, в том числе и relative links, которые вообще трогать не нужно.  То бишь, мы просто добавляем .proxy.domain.com после доменного имени и направляем весь трафик через наш сервер. Теперь по поводу технологий реализации. Для начала, нам не помешает wildcard SSL сертификат с маской *.domain.com. Ну и никак не обойдемся без *.proxy A Record на неймсерверах нашего с вами домена. В апачевский конфиг sites-enabled/proxy.domain.com.conf добавляем ServerAlias *.proxy.domain.com. Пол работы сделано, теперь дело за малым - написать обработчик данных. Прежде всего, нам нужен правильный .htaccess с RewriteRule ^(.*)$ /proxy.php?$1 [L]. Теперь любые запросы будут реврайтится в REQUEST_URI proxy.php. Не забываем и про RewriteCond %{REQUEST_FILENAME} !-f, а иначе получите вечный редирект в поисках счастья. 

Лирическое отступление по поводу содержания proxy.php. Я как-то уже давненько не подходил к PHP, все в компилируемых языках, да в перлах по самые локти. Кстати, насчет последнего, кто там говорит, что перл мертв - посмотрите на количество живых велосипедов в CPAN. Одних только интерфейсов кеширования хватит даже чрезвычайно изощренному уму. Ну а про скоропостижную кончину кричит всякая школота, читающая клоаку вроде хабрахабра и мечтающая о заветном инвайте. Да, есть RubyForge и RubyGems, есть Pypi для монти пайтона, даже C# в Microsoft Visual Studio имеет менеджер компонентов, а совсем недавно силами коммьюнити еще и nuget вышел, который я все никак не посмотрю. И да, есть PEAR для PHP. Набор библиотек в нем, мягко говоря, скудный. PEAR "из коробки" не дает ставить пакеты у который релиз статус ниже stable, а как это отключить - приходится гуглить или устанавливать по ссылке, как-то не очень сопоставляется данные действия с определением "удобного менеджера компонентов". Ну да не важно, для нашего прокси мы будем использовать обвязку не вокруг CURL-а, а над fsockopen. Называется HTTP_Request2. Библиотека, между прочим, очень даже ничего. Пожалуй, хватит ходить вокруг да около: вот вам код proxy.php в копипастере. Хочу заметить, что это скорее болванка из которой я убрал большу часть кода используемую при разборе джаваскриптов и css, да и добрый 10к плагинов, которые заставляли работать ютубы и фейсбуки. Ничего там сложного нет, просто firebug или chrome developer tools вам в руки и копайтесь в куче непонятных кукисов и сжатых js-скриптов. Для последних, кстати, есть отличная утилита - JSBeautifier. Так что не нужно кричать "хааа, лох, у тебя же никак не проверяется вводимый урл, хаааа". Проверяется. Христом богом клянусь. У меня все.

Чуть больше года назад я рассказывал, как прийти к успеху и заработать первый миллион, если покурить, уйти из семьи, набраться смелости и бросить успешную карьеру банковского служащего с перспективами карьерного роста, помошника депутата или там судьи, уйдя в интернет заработки, работая на фриланс бирже или на условиях аутсорсинга. Шутка. Ха-ха. На самом деле, хочу поделиться очередной порцией советов о том, как не ударить в грязь лицом, если вы решили работать на экономику заграницы программистом, дизайнером, иллюстратором или копирайтером, не дай бог.

Основное в каждой работе это умение себя преподнести. Мне и в жизни приходилось часто наблюдать, когда бестолковые пиздоболы, умея отлично расчесать начальству или клиентам какую-то полную чушь из сферы диаметрально противоположной их специализации, продвигались по карьерной лестнице много быстрее бородатых пузатых гениев с уровнем коммуникабельности на уровне среднестатистического аутиста с дефектами речи. Как мы выяснили в прошлых сериях повествования, работать нужно на иностранцев, потому как, если один славянин начинает управлять другим, первый сразу начинает чувствовать себя всемогущим царьком в масштабах одной офисной "коробки", что мешает здоровым профессиональным отношением. С иностранцами же возникает следующая проблема - языковой барьер. Пожалуй, этой стеной отсекается, как говорят у нас в Одессе, большая половина претендентов. Причем первостепенной важностью обладает отнюдь не богатый словарный запас или там диплом IELTS в позолоченной рамке на видном месте в кабинете. Нет, главное для экспортера своих мозгов и талантов - business english. По сути, это даже не язык, а набор церемониальностей. И если те же европейцы обычно довольно спокойно относятся к фривольному стилю общения, то для американцев даже один имейл с отсутствием приветствия и правильной подписи может быть истолкованный, как личное оскорбление и крайняя степень неуважения. По сути, тут та же ситуация, что и в Китае, когда на традиционном китайском говорит минимум, а в большинстве своем общение проходит по упрощенной схеме. То же самое и с европейцами, если вы выучили язык Шекспира по подлинникам и хотели провести беседу на совещании в стиле викторианской эпохи, вы будете разочарованы - на вас, в лучшем случае, повесят клеймо чудака. Иногда это даже выводит из себя, каждую неделю, включаясь в видеоконференцию в скайпе, приходится проходить процедуру how-are-you-канья. И не дай бог команде будут представлять новенького: пока все не наведут справки о его делах, поулыбаются, представят друг друга, обменяются бизнес комплиментами, работы не будет. Еще очень важным моментом является обтачивание своего языка. И нет, я совсем не подразумеваю то, о чем хихикают девятиклассники на задних партах. Уберите из своей речи "категоризмы" can not, will not, do not и прочее. Это очень обижает заграничных ребят, используйте нейтральные формы речи по типу I wish I could, but. Не нужно бояться грамматических и лексических ошибок, избегая их по возможности. Конечно, писать что-то типа I work do like money pay you in time thank you не стоит, вы же не мастер Йода, а мы не на Арракисе, но и строить вычурные многоуровневые конструкции не нужно - вас могут не понять, попросить повторить последнюю фразу, а это чаще всего оказывается проблематичным. Из личного опыта, могу посоветовать иногда разряжать атмосферу длительных текстовых конференций какой-то шуткой или остротой. Но тут опять таки нужно быть крайне осторожным и тактичным, фраза "вот если бы этот черножопый Джон из американской команды тестировщиков родился на 50 лет раньше, мы бы могли высекать его бамбуковыми палками за каждый пропущенный баг" может поставить крест на вашей профессиональной карьере. При общении не забывайте про субординацию. Обращайтесь к высшему начальству, минуя своего непосредственного руководителя, в исключительных случаях. Прежде всего, высшее начальство может быть вообще не в курсе решаемого вопроса, а может и просто не считать своей обязанностью общение с какое-то чернью из Восточной Европы. Ваш начальник получит выговор, а вы потом еще долго будете страдать от проявленной инициативы.

Второй важный момент - умение правильно оценить себя. Да-да, в денежном эквиваленте. Тут нужно побороть 2 основополагающих начала человеческой сущности: алчность и скромность, найдя какой-то компромисс. Схемы оплаты в основном могут быть 3х видов. Это либо почасовая тарификация, либо фиксированная сумма за определенный тип работ, либо ежемесячные денежные вознаграждения за выполненный труд. Особых советов тут быть не может, замечу лишь, что и среди западных людей изредко встречаются нечистые на руку. Если вы решили свести свои рабочие отношения к общению в скайпе без заключения договоров (особенно это имеет сенс при работе фрилансером с разовыми заказами), то советую несколько месяцев настоять на предоплате. Не стоит верить в добродетель древней Европы, жадность и хитрость есть везде. В дальнейшем, схема расчетов будет оговариваться вами и работодателем лично, могу лишь посоветовать проанализировать объемы выполняемой работы. Мне сейчас выгодней оплата за месяц, так как проект был успешно запущен, все работает и лишь иногда нужно вносить какие-то мелкие коррективы, что не отнимает много времени. В начале же, при разработке, расчет со мной проводился по почасовому тарифу. Это сложнее, вам нужно отчитываться за все проделанные таски, вести свой тайм-менеджмент календарь и быть честным. Последнее вообще практически невыполнимая задача. Ведь иногда так хочется в redmine поставить напротив "remove old backups from server", что делается 1й командой rm -rf /mnt/backup_server/old, параметр "estimate time", равный 10 часам, например. Пару раз, безусловно, может и прокатить, но в итоге с вас непременно спросят. Деньги все считать умеют.

Распространенной ошибкой является несерьезный подход к работе. Мол, начальника не видно, работа через интернет, а значит и можно опаздывать, делать что-попало, а еще умудряться спорить с тим менеджером. Это такая проблема нашей ментальности: гетьмана не видно, козаки в загул. Очень грусняво, но с таким подходом вы вернетесь обратно на скучную работу за гроши, где вас будет каждую неделю сношать руководство за отставания от плана. Конечно, у всех у нас в жизни бывают экстренные ситуации, все это решается одним email-ом или sms-кой. Никто вас не будет рвать на части, если вы соизволите предупредить о своем опоздании или отсутствии, более того - поблагодарят за ответственность. Еще важный момент, научитесь управлять своим временем и правильно оценивать его использование. Чаще всего перед или непосредственно после назначения таска, вас спросят "how much time will it take". Ответ very-many-very-much тут не прокатит, даже если раньше вы подобным не занимались. Я бы даже советовал вам завести свой собственный time plan, где рядом с названием определенного вида работ стоит approximate time. Не будете путаться в своем вранье.

Кто не любит визуальное отображение информации? Избегайте больших объемных текстов по некоторым причинам: чем больше букв, тем больше вероятность, что вы допустите какую-то нелепую ошибку, а люди по ту сторону монитора снисходительно улыбнутся, да и вероятность, что вместо прослушивания вашего монотонного чтения, клиент-заказчик будет раскладывать пасьянс косынку, кивая иногда из вежливости, очень велика. Сделали какую-то клевую фишку в программе? Потратьте 5 минут для powerpoint презентации. Весь процесс функционирование или своей работы пытайтесь выразить в форме блок-схем, найдите учебник по информатике за 9й класс и прочитайте тему алгоритмы - в жизни не раз будет помогать подобный навык. Четыре квадрата со стрелочками всегда будут смотреться лучше и понятней, чем скучный шаблон "at first ..., then ..., and after ..., in the end ...".

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