Около полугода назад я написал простой джейкверный плагин для галерей на сайтах. Назвал его Фоторамой и выложил в интернет. По клику кроссфейдом показывалась следующая фотография, клик с шифтом мотал назад — вот и всё.

За эти месяцы Фоторама повзрослела, обзавелась сайтом с логотипом и, думаю, теперь можно написать о ней на Хабре.

В Linux существует много полезных консольных команд, которые при необходимости хотелось бы запустить через proxy. Некоторые приложения имеют встроенную поддержку proxy, а некоторые нет. Далее описано как пользоваться востребованными утилитами через proxy, даже теми, которые этой поддержки не имеют.

curl: передача данных через proxy

curl имеет полноценную поддержку как HTTP proxy так и SOCKS.

Для тестирования возможно использовать proxy сервера из бесплатных списков (socks — sockslist.net, и HTTP proxy — proxyhttp.net). Проверка IP адреса будет производиться с помощью ресурса check-host.net

# Проверить HTTP proxy
curl --proxy 11.22.33.44:5555 check-host.net/ip
# Тоже самое, но если для HTTP proxy требуется авторизация
curl --proxy 11.22.33.44:5555 -U username:password check-host.net/ip
# Проверить socks4
curl --socks4 11.22.33.44:5555 check-host.net/ip
# Проверить socks5
curl --socks5 11.22.33.44:5555 check-host.net/ip
# Тоже самое, только преобразование имен идет также через SOCKS
# (подробнее о преобразовании имен можно прочитать ниже в подразделе "DNS запросы через proxy")
curl --socks5-hostname 11.22.33.44:5555 check-host.net/ip

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



Странно, но методики, которые родились непосредственно в области разработки ПО совсем не похожи на пришедшие извне.

Например достаточно простой SCRUM, описание которого вполне можно уместить на листок A4, но которым пользуется CERN. Или Agile, который можно описать десятом абзацев где содержатся весьма общие и идеалистические принципы в соответствии с которой был сделан GitHub и много других клевых штук. Можно ли их использовать в строительстве? А при создании самолетов?

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

(в качестве иллюстрации лицо типичной универсальной методики авторства RuxxSilver, которое на первый взгляд выглядит весьма привлекательно и правдоподобно)

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



Если искать аналогии в плане управления, то весьма схожем с производством ПО может показаться строительство. Мало того, менеджеров по разработке ПО нередко знакомят с управлением проектированием и строительством зданий и инженерных сооружений.

Однако, происходит некоторая подмена причин этого знакомства. Да, эта область в чем-то похожа, в первую очередь наличием понятий “требования”, “проектирование”, “проект”, “строительство” (construction), “контроль качества”, “человеко-часы”, “работы”, “сроки”, а сам процесс развивается от экономической потребности и идеи до некого конечного продукта. Но основная причина того, что строительство является хорошей аналогией в том, что это наглядная аналогия.

(В качестве иллюстрации фотография проекта А.Гауди «Sagrada Familia», степень выхода которого за сроки и бюджет до сих пор не могут даже приблизительно оценить)

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



Несколько дней назад я размышлял, почему так получилось, что тщательно прописанный и формализованный проект в очередной раз со свистом вылетел из сроков и бюджета, превысив их в разы. Иногда бывает, что проекты ведут себя по другому, но чаще происходит именно так. И это мало зависит от того, какую методику я использую для оценки объема работ и самой разработки. Даже McConnell, которого я считаю серьезным авторитетом в области разработки ПО, в начале книги Software Estimation: Demystifying the Black Art констатирует то, что простые методики оценки размера проекта удивительным образом оказывается ничуть не хуже сложных и испытывают те же самые проблемы. Возможно этот вывод можно распространить не только на методики оценки.

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

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

(на иллюстрации персонаж фильма «Железный человек 2» Иван Ванко в момент произнесения фразы «Ваш софт — говно»)

1. Индустрия на стероидах

    Наверняка многие из нас хоть раз думали про себя: «Черт побери, и везет же этим американцам!». Это касается многого, от магазинов с доставкой «только в пределах 48 континентальных штатов» до вполне серьезных контрактов, которые срываются только потому, что потенциальный заказчик в США категорически не желает иметь дело с иностранцами.

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

Думаю никому из присутствующих не нужно объяснять важность резервного копирования.
Проблема в том, что из десятков готовых решений ни одно толком не удовлетворяет моим требованиям standalone *NIX-сервера на колокейшене.
Чего же хотелось от резервного копирования?
1) ежедневного полного бакапа всех данных. Никаких incremental-бакапов.
2) максимально быстрого восстановления отдельно взятого файла. Архиваторы (tar/gzip/bzip2/rar) отпадают
3) быстрого мониторинга «кто именно залил вчера на сервер 156Гб?!!!»
4) резервные копии хочется хранить максимально долго, насколько хватает свободного места на дисках.
5) хочется не заботиться об ручном удалении старых копий если место на диске всё-таки уже кончилось
Если в двух словах — то мне захотелось реализовать функционал MAC OS TimeMachine на Linux-сервере.
И я начал писать скрипт.

Некоторое время назад меня попросили настроить в удаленном филиале простейшую балансировку трафика. Работают они, бедолаги, через ADSL, и отправка электронных писем большого объема (сканы документов) забивает им весь обратный канал, что приводит к проблемам в работе с офисными онлайн-программами через VPN.
В качестве шлюза у них используется Linux (Fedora). До этого я пару раз видел, как подобная балансировка настраивается через ipfw на FreeBSD, а так как знаю механизм iptables достаточно хорошо, не ожидал особых проблем. Но поискав в Интернете, я был неприятно удивлен тем, что iptables мне тут совсем не помощник. И знания о порядке прохождения пакетов через его таблицы и правила мне почти не пригодятся. Нужно изучать tc из пакета iproute2.

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

Как-то незаметно для себя, я решил отойти от возни с классами и паттернами, и разобраться с самыми обычными Js функциями. Думал, что будет достаточно скучно, но ошибся — оказалось очень даже интересно.

В этой статье я расскажу об особенностях объявления функций, и некоторых полезных паттернах (кхе-хе, да, они есть и тут)

Я попытаюсь просто объяснить, как работают замыкания в Javascript, как работает this, как создавать конструкторы для своих классов и чем различаются различные подходы к их созданию.
Статья не претендует на новаторство, но достаточно доступные объяснения how it works для новичков я не видел, и на мой взгляд — это три самых узких места в Javascript (не привязанному к какому либо контексту, серверу или браузеру, например).

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

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

Но есть и другой путь. В некоторых случаях оказывается возможным использование ограничений, наложенных на материализованные представления, обновляемые по факту фиксации транзакций (fast refresh on commit). Такие ограничения будут работать как отложенные (deferred) и не будут позволять зафиксировать транзакцию, если вдруг целостность данных оказалась нарушенной. В рамках же модифицирующей транзакции ограничения могут нарушаться. С одной стороны это упрощает модификацию данных, с другой, мешает идентифицировать источник ошибки. В этой статье я хотел бы привести пару простых примеров реализации таких ограничений.

0. Присказка

В некотором царстве, в некотором государстве жил-был программист. Звали его, как полагается, Иван. Был он настоящим спецом, обладал всеми Тремя Великими Добродетелями Программиста, то есть был ленив, спесив и нетерпелив. Случилась в том царстве печаль великая: кризис. И выгнали Ваню с работы без выходного пособия. Горевал Ваня долго, а потом собрался с духом и разослал резюме по всему белу свету. Долго ли, коротко ли, вызвали Ваню на собеседование. Требований к соискателю было много, но главное — требовалось хорошо владеть регулярными выражениями. До собеседования — почти месяц, готовься — не хочу. Будучи человеком серьёзным, готовиться Иван решил обстоятельно. 3 недели и 3 дня он лежал на печи, почитывал Хабр и думал, как же неслыханно обстоятельно он будет готовиться. До собеседования остался 1 день. Ванюша мысленно обругал работодателей, которые назначают собеседование так скоро, что совсем подготовиться не успеваешь, слез с печи, сдал пивные бутылки и на вырученные деньги купил книжку по регексам. Читал он её до полного изнеможения, пока не отключился. Утром мы найдём сонную физиономию Ванюши лежащей, как на подушке, на этой самой книжке под Хабракатом.

Вопрос удаленного мониторинга сервисов компании для меня всегда стоял очень остро. И чего я только не пробовал. Nagios, Zenoss, Zabbix и пр. сменяли друг друга поражая своими возможностями и набором функций. Обещали просканировать, охватить и бдить денно и нощно, а в случае чего оповещать тут же. Но к сожалению мне всегда не хватало времени на настройку этих комбайнов, а мониторинг был нужен тут и сейчас. Поэтому однажды я сел и написал следующий скрипт.

Высоконагруженные сайты, доступность «5 nines». На заднем фоне (backend) куча обрабатываемой информации в базе данных. А что, если железо забарахлит, если вылетит какая-то давно не проявлявшаяся ошибка в ОС, упадет сетевой интерфейс? Что будет с доступностью информации? Из чистого любопытства я решил рассмотреть, какие решения вышеперечисленным проблемам предлагает Oracle. Последние версии, в отличие от Oracle 9i, называются Oracle 10g (или 11g), где g – означает «grid», распределенные вычисления. В основе распределенных вычислений «как ни крути» лежат кластера, и дополнительные технологии репликации данных (DataGuard, Streams). В этой статье в общих чертах описано, как устроен кластер на базе Oracle 10g. Называется он Real Application Cluster (RAC).

Статья не претендует на полноту и всеобъемлемость, также в ней исключены настройки (дабы не увеличивать в объеме). Смысл – просто дать представление о технологии RAC.

P.S. Beware of the многабукаф
Продолжение статьи

Продолжение статьи про Real Application Cluster (RAC). Окончание.

Начало статьи

Итак, Вам надоело набирать пароли, писать команды, смотреть на скучные обои? А хочется завоевать вселенную и почивать на лаврах? Заставьте роботов трудиться вместо cебя!

Существующая маска для IP адреса выросла из классового деления адресов, на заре эпохи IP:

Класс A: 8 бит для номера сети 24 бита для номера хоста
Класс B: 16 бит на сеть и 16 бит на хост
Класс C: 24 бита на сеть 8 бит на хост

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

IP адрес, десятичное:     10.      10.       0.       1
IP адрес, двоичное: 00001010.00001010.00000000.00000001
Маска, двоичное:    11111111.11111111.11111100.00000000
Маска, десятичное:       255.     255.     252.       0

Представление маски подобным образом, вполне, соотносится с термином битовой маски, т.е. единицы и нули определяют действия над конкретными битами в исходном числе, но плохо соотносится с форматом IP адреса – номер сети всегда определяется битами вначале, номер хоста битами в конце. Поэтому представление маски в виде 32-х битного поля является избыточным. Для однозначного определения маски можно определить только количество подряд идущих единиц с начала IP адреса от 0 до 32 – префиксное обозначение, обычно записывается через дробь после IP адреса: для примера выше 10.10.0.1/22 – 22 бита номер сети и 32-22=10 бит номер хоста. Если говорит про IPv6 адрес, то там определяется только префиксная запись маски/адреса – 2001:d8:a15e::1/48

Многие слышали и пользовались замечательной утилитой nmap. Ее любят и системные администраторы, и взломщики. Даже Голливуд знает про нее — в фильме «Матрица» при взломе используется nmap.

Кажется, только недавно ребята из Mozilla начали разработку PDF.js — движка для рендеринга PDF-документов средствами HTML5 и JavaScript, и вот они уже вышли на финишную прямую. Качество рендеринга достигло такого уровня, что разработчики решили выпустить экспериментальную версию расширения для Firefox (файл XPI).



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

Продолжение

Мало кто из знакомых со словами linux, *bsd не знает о Midnight Commander. Я не слишком ошибусь, если скажу, что все поначалу пользовались им. Отличный инструмент для задач, которые он решает, к тому же доступный на многих платформах. Последнее время проект, ранее развиваемый под крылом gnome.org, получил вторую жизнь. Новый сайт проекта радует темпами развития. Вот только поддержка актуальных версий пакетов в дистрибутивах хромает.

Последнее, что доступно в Debian — 4.7.0.9, и это при том, что совсем недавно вышел 4.7.5.4 в котором есть ряд вкусностей. Проект предоставлял бинарные сборки для RedHat-based систем и не поддерживал таковые для Debian/Ubuntu. Я решил восполнить этот пробел, запустив автоматическую сборочную среду.