VPN (англ. Virtual Private Network — виртуальная частная сеть) — обобщённое название технологий, позволяющих обеспечить одно или несколько сетевых соединений (логическую сеть) поверх другой сети (например, Интернет).
© Wikipedia

VPN используется для удаленного подключения к рабочему месту, для защиты данных, для обхода фильтров и блокировок, для выдачи себя за гражданина другой страны и вообще — штука незаменимая. Практически повсеместно в качестве простого средства для организации пользовательского VPN используется всем известный OpenVPN, который использовал и я. Ровно до тех пор, пока у меня не появился Macbook и OS X в придачу. Из-за того, что подход Apple к конфигурации DNS сильно отличается от подхода других *nix-систем, проброс DNS через VPN нормально не работал.

После некоторых исследований у меня получилось два варианта:
— Использование DNS «мимо» VPN, что сильно небезопасно, но решает проблему.
— Использование нативных для OS X VPN-протоколов: PPTP и семейства IPSec.
Разумеется, я выбрал второе и разумеется — IPSec, а не устаревший PPTP.

12 мая мы с товарищами зашли в московское метро с его открытием утром и, не выбираясь наверх, посетили все 199 доступных в данный момент станций до закрытия метрополитена. Зачем мы всё это сделали – совершенно не ясно, но я попробую рассказать, как так получилось.

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

По мере изучения вопроса я обнаружил, что идея сама по себе не то чтобы очень нова – в нью-йоркской подземке аналогичные соревнования проходят с 1966 года. Что же касается московского метро, то ЖЖ-пользователь estrella-de-sur полгода назад проехал его за 12 часов 36 минут (расчётное время – 11 часов 50 минут) по правилу «один шаг на каждую станцию». Но у нас была другая задача – мы хотели выйти на каждой станции и по возможности красиво её сфотографировать. Это означало, что нам в большинстве случаев придётся ждать на ней следующего поезда. Исходя из этого я и строил расчёт.

Предупреждение: если вы умеете решать задачу коммивояжёра на 200 узлах (с помощью генетических алгоритмов или без них) – вас, скорее всего, ждут в другом месте. Можете просто пролистать пост и посмотреть картинки.

Заинтересовавшись темой функционального программирования я встал на распутье, — какой фреймворк выбрать для ознакомления. ReactiveCocoa — ветеран в iOS кругах, по нему вдоволь информации. Но он вырос с Objective-C, и хотя это не является проблемой, но все же в данный момент я в основном пишу именно на Swift, — хотелось бы взять решение изначально спроектированное с учетом всех плюшек языка. RxSwift же порт Reactive Extensions, имеющего долгую историю, но сам порт свежий и написанный именно под Swift. На нем я и решил остановиться.
Но специфика документации по RxSwift в том, что описание всех команд ведет на reactivex.io, а там в основном дается общая информация, руки у разработчиков не дошли еще сделать документацию именно для RxSwift, что не всегда удобно. Некоторые команды имеют тонкости в реализации, есть те, о которых в общей документации нет ничего кроме упоминания.
Прочитав все главы вики с RxSwift гитхаба, я сразу решил поразбираться с официальными примерами, тут то и стало ясно, что с RX такое не пройдет, нужно хорошо понимать основы, иначе будешь как мартышка с копипастом гранатой. Я начал разбирать самые сложные для понимания команды, потом те, что вроде понятны, но задав себе вопросы по ним я понял, что лишь догадываюсь на то как верно ответить, но не уверен.
В общем ничтоже сумняшеся я решил проработать все операторы RxSwift. Лучший способ что то понять в программировании — запустить код и посмотреть как он отработает. Затем учитывая специфику реактивного программирования — очень полезны схемы, ну и краткое описание на русском. Закончив сегодня работу, я подумал, что грех не поделиться результатами с тем, кто лишь присматривается к теме реактивного программирования.
Много картинок и текста под катом, очень много!

Недавно я узнал об интересном классе устройств DAS (Direct Attached
Storage).



Это такой NAS, который не имеет собвственной операционной
системы на борту, но позволяет создать аппаратный рейд-массив из 2-8
дисков. Признаюсь, что если бы до этого у меня не было NASа, то я бы
усомнился в том, что такое устройство вообще может быть востребовано.
Непонятно, чем же оно лучше обычного выносного жёсткого диска. А
оказалось, что в определённых обстоятельствах DAS — это именно то, что
нужно.

Все мы знаем, что большинство гаджетов дешевле купить в США, чем у нас на родине, и особенно это относится к различным новинкам, цены на которые у нас просто взлетают к небесам! Так же всем известно, что самые «вкусные» предложения на eBay и в интернет магазинах США обычно имеют доставку US only и соответственно не доступны для нас. В этой статье я попытаюсь рассказать про еще один способ исправить это недоразумение. Конечно все более-менее опытные интернет-покупатели знают о посредниках, которые предоставляют услугу mail forwarding — тоесть пересылку посылок. Происходит это так — вы заказываете доставку товара на адрес в США, который вам выдал посредник, он получает посылку и пересылает ее вам, беря за это небольшую комиссию. Известные посредники это Shipito, Ebaytoday, Бандеролька и т.д. их достаточно много и все они предлагают набор услуг — пересылка, объединение нескольких посылок в одну, наоборот — разделение крупной посылки на несколько мелких и тд. Берут обычно фиксированную плату за каждую посылку + оплату за дополнительные услуги. Стоимость самой пересылки обычно рассчитывается по тарифам USPS и этой же службой отправляют посылку вам. Я же хочу рассказать про еще одну компанию — Meest.us, которая осуществляет пересылку посылок (среди различных других услуг) но в принципе ее работы есть некоторые интересные особенности.

Предисловие

Некоторые из вас наверняка недавно проходили Stanford'ские курсы, в частности ai-class и ml-class. Однако, одно дело просмотреть несколько видео-лекций, поотвечать на вопросики quiz'ов и написать десяток программ в Matlab/Octave, другое дело начать применять полученные знания на практике. Дабы знания полученые от Andrew Ng не угодили в тот же тёмный угол моего мозга, где заблудились dft, Специальная теория относительности и Уравнение Эйлера Лагранжа, я решил не повторять институтских ошибок и, пока знания ещё свежи в памяти, практиковаться как можно больше.

И тут как раз на наш сайтик приехал DDoS. Отбиваться от которого можно было админско-программерскими (grep / awk / etc) способами или же прибегнуть к использованию технологий машинного обучения.

Далее пойдёт рассказ о создании нейронной сети на Python 2.7 / PyBrain и её применении для защиты от DDoS'а.

Вступление

Около года назад, я собрался с мыслями, нашел свободное время и установил на недавно приобретенный компьютер Mac OS X 10.6.6 Snow Leopard, или проще говоря, «создал» себе Хакинтош. Я не буду описывать процесс установки и настройки, лишь факты: характеристика — что и как заработало. Характеристики хака были следующие:

• Материнская плата: ASUS P7P55D PRO — DSDT.aml имеется на сайте tonymacx86
• Процессор: Core i5-760 2.80 Ghz.
• SSD Диск: OCZ Vertex-2 (SATA-II) — нативно работает
• HDD: 1,5 TB; 1 TB
• Видеокарта: XFX ATI Radeon HD 6870 1gb — нативно поднимается в OS 10.7.x, и 10.6.7/8. В 10.6.6 с помощью драйверов от 10.6.7 и выше.
• Оперативная память: 4 Gb (2 x 2gb)
• Мышка, клавиатура: usb — нативно
• Сеть: официальные драйвера realtek
• Звук: завелся установкой voodoo kext

Об хакинтошах уже писал Kyrie1965 в своей статье «Хакинтош» — стоит ли игра свеч?, поэтому на вопросах «что? как? почему?» относительно хакинтоша я не буду заострять внимания. (Спрашивайте, если вдруг возникнут вопросы по данному железу под хак.)
Просидев на данном звере около года, обновившись в последствии до 10.7, я окончательно принял решение купить iMac. Об этом тонком процессе и пойдет речь ниже.

Читая Хабр в течении последних двух лет, я видел только несколько попыток разработки ОС (если конкретно: от пользователей pehat и iley (отложено на неопределённый срок) и Igor1024 (не заброшено, но пока больше походит на описание работы защищённого режима x86-совместимых процессоров, что бесспорно тоже необходимо знать для написания ОС под x86); и описание готовой системы от alman (правда не с нуля, хотя в этом нет ничего плохого, может даже наоборот)). Мне почему-то думается, что почти все системные (да и часть прикладных) программисты хотя бы раз, но задумывались о написании собственной операционной системы. В связи с чем, 3 ОС от многочисленного сообщества данного ресурса кажется смешным числом. Видимо, большинство задумывающихся о собственной ОС так никуда дальше идеи и не идёт, малая часть останавливается после написания загрузчика, немногие пишут куски ядра, и только безнадёжно упёртые создают что-то отдалённо напоминающее ОС (если сравнивать с чем-то вроде Windows/Linux). Причин для этого можно найти много, но главной на мой взгляд является то, что люди бросают разработку (некоторые даже не успев начать) из-за небольшого количества описаний самого процесса написания и отладки ОС, который довольно сильно отличается от того, что происходит при разработке прикладного ПО.

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

В свое время, в 1995-ом году, на меня произвел впечатление фильм «Хакеры». Можно
сказать, он стал мотиватором моей дальнейшей ИТ-карьеры. Далеко не эталон киноискусства, однако
стремление стать похожим на героев фильма, продолжилось в самообразовании. Далее первый выклянченный компьютер, первые строчки кода, начало проб и ошибок. Когда уже были написаны эти самые «хэлоу-ворды», «калькуляторы», затем испробованы несколько *nix'ов — на руки попалась болванка с «Antitrust». В одноголосном переводе и гиблом качестве. К слову, это не помешало, пересмотреть фильм пару десятков раз. Что послужило более зрелому стремлению, чем быть всемогущим кул-хакером. Под катом, перечислю увиденные мной фильмы IT-тематики, с кратким описанием. В основном из двухтысячных. Неувиденное или забытое, будем добавлять.

В сентябре прошлого 2010 года компания Яндекс открыла для публичного использования DNS-хостинг в рамках Почты для доменов. Радости пользователей не было предела, топик был встречен массой положительных комментариев, а Яндекс был объявлен корпорацией добра.

К сожалению администрирование DNS-записей было предусмотрено только через web-интерфейс. API для администрирования предусмотрено не было, до сих пор не появилось, и возможно еще долго не появится. Этот факт опечалил многих владельцев доменов с динамическим IP не меньше, чем перевод отличного бесплатного сервиса free.editdns.net на платную основу (для custom доменов), в связи с покупкой последнего компанией DynDNS.

Убедившись, что чуда не случилось, я взял в руки Python напильник с целью исправить эту несправедливость…

Понедельник

• Новости: ученые изобрели машину времени, вышел новый ноутбук толщиной 80 нанометров, Google покупает Microsoft, Facebook увольняет 1000 программистов.
• Вылез стартап. Попиарился, лёг под хабраэффектом, встал, собрал замечания, поблагодарил, пропал навсегда.
• Вышла новая версия третьего слева линукса. Качать срочно.
• Я негодую — счет за телефон оператор округлил до кратности числу Пи.

Вторник

• Опровержение новостей: ученые изобрели всего-лишь более точные часы, 80 нанометров — это техпроцесс, а не толщина ноутбука, Google покупает какой-то стартап, который отказался купить Microsoft, Facebook набирает 5000 программистов.
• Начало холивара, модного на этой неделе (чай vs кофе, бинокль vs подзорная труба, черное vs белое)
• Очень важный технический ресурс (ЖЖ, порнолаб, Sony Network) взломан (заДДОСен, конфискован УБОПом). Паника и отчаяние.

… или что такое на самом деле 'raid edition' для жёстких дисков

Немного теории

Существуют две стратегии поведения НЖМД при обнаружении ошибки:

• standalone/desktop — пытаться прочитать до последнего. Это ощущается как «тормозящий винт», который всё-таки работает, если это единичный сбой, то «затупило, но прошло», плюс характерный перестук перекалибрующихся головок.
• raid — отваливаться тут же. Это ощущается как «внезапно была ошибка диска но потом mhdd и т.д. НИЧЕГО НЕ НАШЁЛ ЧТО МНЕ ДЕЛАТЬ».

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

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

Расшифровка названия

Возможность управления поведением диска при ошибках называется очень и очень путанно: SCT ERC. Это расшифровывается как SCT Error Recovery Control. SCT в свою очередь название общего протокола SMART Command Transport. SMART в свою очередь расшифровывается как Self-Monitoring, Analysis and Reporting Technology, таким образом, полная расшифровка SCT ERC звучит так: Self-Monitoring, Analysis and Reporting Technology Command Transport Error Recovery Control (выдохнули).

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

Я достаточно часто сталкивался с подобным мнением и не придавал ему особого значения, но когда женский коллектив нашей организации поздравил программистов с 23-м февраля по доброму назвав их «космическими войсками», решил всё же расставить определенные акценты в данном вопросе, т.к. одна из моих профессий связана напрямую с психоанализом. Да и баш уже не молчит.

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

Когда я показываю босу, что окончательно пофиксил баг



Когда проджект-менеджер входит в офис

Недавно участвовал в разработке одного проекта — фото конкурса. По задумке, рейтинг фото альбомов должен формироваться из суммы всех публикаций в социальных сетях: Facebook, Вконтакте, Twitter. Т.е. общий рейтинг фотоальбома расчитывается:

Рейтинг фотоальбома = кол-во «Share» в Facebook + кол-во «Сохранить» в Вконтакте + кол-во «Retweet» в Twitter

На макетах, вид кнопок несколько отличался от предоставляемых социальными сетями плагинов, формируемых функциями api. В частности вид счетчиков:

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

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

Итак:

• количество лайков будем получать от REST сервисов каждой социалки
• кнопки рисуем свои и обрабатываем событие click

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

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

[Автор этой статьи — Джеф Этвуд (Jeff Atwood), один из основателей stackoverflow.com. Сама же статья, несмотря на довольно приличный возраст (она написана в 2007 году) до сих пор популярна, а введенный в ней термин «FizzBuzz question» стал общеупотребительным. Оригинал можно найти здесь.]

Я весьма скептически отнесся к следующему наблюдению Реджинальда Брейтвайта (Reginald Braithwaite):

«Меня немного удручает тот факт, что 199 из 200 соискателей программистских вакансий не умеют программировать. Повторю: они не умеют писать код. Вообще.»