Регистрация на мероприятие начнется 16 мая. Количество мест ограничено.

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

Подробную информацию о мероприятии читайте здесь.

С одной стороны их труд действительно достоин уважения. Они сделали относительно недорогое решение за короткий срок в условиях ограниченных финансовых возможностей. Причем, эту услугу они вывели на мертвый рынок Беларуси. С другой стороны фейлов в Active Cloud получилось немало. Как раз об этих фейлах я и хочу рассказать.

Все описанное ниже касается белорусского Active Cloud. Я не знаю, отличаются ли услуги, предоставляемые в других регионах. Возможно, там что-то по-другому.

Начнем с панелей. Их две: биллинг и управление облаком. Панель биллинга общая для всего-всего и включает управление всеми подписками, от доменов и DNS, до облака. В этой панели объединено все, кроме управления самими машинами в облаке. Используется стандартное решение от Parallels. Оно очень тяжелое — страницы долго грузится. Причем, дело не только в канале интернета, но и во времени генерации страниц.

Навигация в этой панели просто ужасная. Сходу не понятно ничего. Я до сих пор до конца не понял концептуальной логики построения этой панели (проще говоря — что где искать), хотя пользуюсь ей уже несколько месяцев. Я часто с трудом нахожу то, что мне надо. Причем, делать это приходится буквально методом тыка. До интуитивности пока очень далеко. Очень.

В панели биллинга много непонятной и лишней информации, в том числе, похоже, никому ненужных цифр. Примером может служить вкладка «Статистика и анализ». Это обратная сторона универсальности («коробочное» решение от Parallels). Есть и баги. Например, у меня не работает вкладка «Статистика трафика» — она просто не подгружается.

Кстати, интерфейс для общения с саппортом — отдельная тикетная система с базой знаний. Раньше она была топором врублена в биллинговую панель — было жутко неудобно. Похоже, разработчики это поняли и стали открывать ее в новом окне. Однако, она осталась неудобной. Слоновые заголовки, «потеря» страницы после F5 (это следствие отсутствия правильного URL в address bar), опять лишняя информация, причем частично на русском, частично на английском. Засоряют экран специальные уведомительные тикеты, которые плодятся вместе со счетами и виртуальными машинами. Здесь достаточно было бы уведомлений по e-mail.

Вторая панель — управление облаком от Cloud.com. Она тоже тяжелая и тормозящая, хотя и меньше биллинга. Не очень удобная навигация, многое приходится делать в два-три клика, когда можно было бы в один.

В обеих панелях не работает браузерная функция запоминания пароля (Firefox). В облачной панели мне сделали 2 учетки. Первая была на демо-доступ и сам логин был таким, как я просил. Вторую сделали на полный доступ, но логин без спроса сделали новый вида xxx1235465, где xxx — мой старый логин. Не очень удобно, особенно в купе с неработающим запоминанием пароля. Сменить второй логин не смогли. Кроме того, не смогли убрать и из самого биллинга завершенную подписку демо-доступа и некую ошибочно созданную подписку. Видимо, они будут мозолить мне глаза вечно.

При создании виртуальной машины ей задается группа (вписывается в текстовое поле). Все группы видны в меню. Машину можно удалить, но при этом группа не удалится. И переименовать группу нельзя. Раздражает.

Консоль виртуальной машины вроде работает без Java. Но она сделана на картинках-слайсах. Т.е. при изменении изображения на виртуальном экране виртуальной машины (консоль или GUI) подгружается новые картинки-квадратики. Из-за этого консоль работает медленно и с большой задержкой. Пользоваться ей неудобно.

У Active.by классный сайт. У них в штате классный дизайнер. Но их панели — это полная противоположность их сайту. И дизайнер там почти не бывал.

Кроме того, в панелях были конкретные баги. Пару раз писал в саппорт, обещали поправить. Поправили или нет — не проверял.

Само облако поначалу сбоило. Лично мне несколько раз саппорт решал проблемы отвалившейся на моей ВМ сети. При мне сеть во всем облаке (толи целиком, толи в его куске) полностью падала на несколько часов. После этого столкнулся с тем, что свежеустановленная из образа Debian x64 не получала IP по DHCP на первом и всех последующих запусках (повторялось каждый раз). После обращения в саппорт проблема была решена за пару дней. Я был в шоке…

Надо отдать должное, что облако Active.by молодое. Оно было запущено в таком виде как сейчас в конце 2011 года. То, что описано выше, происходило в январе—феврале. Сейчас в марте проблем по доступности и функционированию машин и облака в целом замечено не было.

Изначально мы хотели перевести в облако свои серверы. Но сделать это не смогли. Основной причиной тому были непонятные проблемы с производительностью дисковой подсистемы. Хотя синтетические измерения вроде бы и выдавали нормальные скорости I/O, но фактическая производительность рабочего сервера на Windows у нас оказалась колоссально хуже, чем на аналогичном по конфигурации голом железе.

Возможно, проблемы были на большом количестве IOPS (частое чтение мелких блоков). Мы не выяснили это до конца. Но факт есть факт: то, что у нас нормально работает на физическом выделенном сервере, перенести в облако мы не смогли — сильно педалит. Причем, четко видно, что педалит не по CPU, и не по памяти. Педалит именно по дисковому I/O.

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

Мне нравится Active.by. Я желаю им успехов в развитии. И надеюсь, что мой пост поможет им раскрыть глаза на собственные недостатки и исправить их. Удачи им в этом!

Актуальность информации — апрель 2012 года.

StartSSL раздает валидные годовые SSL-сертификаты бесплатно. Другие компании берут за это деньги начиная примерно от $20 в год. StartSSL зарабатывает на сертификатах более высоких классов, включая сертификат с расширенной валидацией, а базовый сертификат делает бесплатно. Их идея заключается в том, что они не берут деньги за сервис, в котором не используется труд людей (базовая валидация домена производится автоматически).

1. О системе StartSSL и их сертификатах

Особенность функционирования сайта StartSSL заключается в том, что авторизация в панель управления производится через клиентский S/MIME сертификат. Это большая редкость в наши дни. Отсюда возникает непонимание процесса неподготовленными пользователями и тупняк на этапе освоения сервиса.

Суть заключается в том, что вместо логина и пароля вам выдается сертификат. Почти такой же сертификат, какой выдается для подтверждения подлинности сервера. Этот сертификат отправляет на сервер ваш браузер при авторизации (автоматически после вашего подтверждения). Браузер берет его из хранилища, куда сертификат должен быть импортирован до проведения авторизации. Если сертификата в хранилище не окажется, то при авторизации вы увидите браузерное сообщение об ошибке, на подобии «Не удаётся завершить защищённую транзакцию».

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

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

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

Кроме того, на домене должна работать почта. На один из ящиков из фиксированного списка (webmaster@домен, postmaster@домен, hostmaster@домен или адреса, указанные в Whois) придет письмо с кодом проверки.

2. Регистрация

Зайдите на сайт StarSSL и начните регистрацию (кликаем Sign-up). При этом нельзя использовать Google Chrome (можно Opera, Firefox, IE).

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

2.2. Укажите код подтверждения e-mail-а. Как правило, письмо с кодом приходит сразу или в течение минуты.

2.3. Дождитесь проверки указанных данных персоналом StartSSL. Да, они проверят то, что вы ввели в форме. Вручную. Если их ничего не смутит (а как правило ничего не смущает в реальных данных), вам придет ответ на e-mail, в котором будет указана ссылка на вторую активацию аккаунта (с кодом). Обратите внимание, что ссылка действует только в течение 24 часов.

Они могут задать дополнительные вопросы по e-mail для уточнения регистрационных данных. Отвечать на них имеет смысл, и опять-таки — честно.

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

Для генерации ключа выбираем 2048 бит (в выпадающем меню), так как меньшую битность StartSSL не поддерживает, а в большей едва ли есть смысл.

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

Устанавливаем обязательно.

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

Этот сертификат необходимо «достать» из браузера и сохранить в надежном месте. В случае потери установленного сертификата (например, переустановка ОС или браузера) вы сможете его вновь импортировать. Кроме того, сертификат нужен для того, чтобы войти в панель с другого компьютера.

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

Формат экспорта — с секретным ключем PKCS#12. Если такого формата нет и вы не знаете, какой формат экспорта лучше выбрать (при условии, что их несколько), экспортируйте во все :). Если вы экспортируете сертификат без ключа, смысла в этом не будет — он не будет работать.

Если вы потеряете сертификат, утратите доступ к панели. Это значит, что для получения новых сертификатов и продления старых (через выписку нового), необходимо будет заново регистрироваться.

3. Итак, ваша учетная запись подтверждена и у вас есть персональный сертификат для авторизации в панели StartSSL. Теперь самое время зайти в панель. Нажимаем на кнопку с ключами и попадаем на страницу авторизации (смотрите на первом изображении в статье). Нажимаем «Authenticate». Подтверждаем передачу серверу нашего персонального сертификата. Авторизация пройдена — вы в панели.

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

Самое тяжелое позади. Теперь необходимо заказать и получить сертификат для вашего сайта. Он будет выдан на год. Спустя 11 месяцев необходимо зайти на сайт и получить новый сертификат на тот же сайт (то же имя). Как таковой процедуры продления сертификатов нет ни для сайта, ни для персональных сертификатов. Об окончании срока действия сертификатов StartSSL несколько раз раз предупреждает по почте.

Панель StartSSL состоит из 3-х разделов (вкладки на изображении выше):

• Tool Box — инструментарий. Большая его часть бесполезна. Можно отметить только разделы для получения корневых и промежуточных сертификатов StartSSL и получения ранее созданных сертификатов.
• Certificates Wizard — мастер создания нового сертификата. С него начинается заказ нового сертификата для сайта или персонального сертификата. Для создания сертификата должен быть заранее подтвержден домен или адрес e-mail соответственно.
• Validations Wizard — это как раз и есть мастер проверки сайта и e-mail (а кроме того платных проверок личности и организации). С него нужно начинать получение сертификата для сайта. Каждая проверка действует 30 дней, так что при «продлении» сертификатов проверки необходимо повторять.

Итак, начинаем процесс получения сертификата для сайта.

3.1. Проверка (валидация) домена. Переходим в Validations Wizard, выбираем проверку домена (Domain Name Validation):

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

3.2. После проверки принадлежности домена нужно заказать для него сертификат. Для этого перейдите в Certificates Wizard, выберите Web Server SSL/TSL Certificate. Далее выберите из списка один из предварительно проверенных доменов.

На следующем шаге есть два варианта:

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

Первый вариант выбирают те, кто знает, что такое CSR и как его сделать. В любом случае обратите внимание на то, что размер ключа (Keysize) не должен быть менее 2048 бит.

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

На следующем шаге повторно выберите домен. Далее, укажите для него поддомен. Сертификат будет действителен для выбранного домена и указанного сабдомена (например, www).

На следующем шаге просто подтверждается заказ сертификата. После этого вы получите сам сертификат (PEM-encoded). Сохраните его.

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

openssl rsa -in ssl.key -out ssl.key

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

1. Мы хотим контролировать скачивание больших файлов, проверяя права доступа или считая количество закачек. Мы используем nginx и PHP (или другой серверный язык).

Это реализуется очень просто через заголовок Accel-Redirect. nginx получает запрос, передает его скрипту, скрипт в заголовки ответа выдает Accel-Redirect с ссылкой на файл, который нужно выдать пользователю. Если файл выдавать нельзя (например, нет прав), скрипт просто выдаст ошибку (например, 403).

В данном случае не важно, работает ваш PHP через проксирование из nginx на Apache, либо на *CGI. Предположим, что вы хотите отдавать на скачку файлы, которые находятся в каталоге /var/files. Тогда в секции server в nginx добавьте:

location /_download_files {
        root /var/files;
        internal;
}

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

header("X-Accel-Redirect: /_download_files/filename.zip");

Никакой выдачи (echo) делать не надо, после отдачи заголовка можно завершить работу скрипта. В этом случае будет скачан файл /var/files/filename.zip. Вместо filename.zip может быть любой длинный путь с каталогами, который должен повторять путь к файлу в /var/files/.

В принципе этого достаточно, чтобы переложить выдачу файла на плечи nginx. Если нужно обязательно показать диалог закачки (даже если файл такого типа, который браузер может показать сам), нужно добавить выдачу заголовка:

header("Content-Type: application/x-force-download");

Обратите так же внимание на то, что в случае проксирования на Apache последний обязательно установит Content-Type (по умолчанию обычно text/html) в случае PHP-скриптов, и этот тип отправится пользователю, так как nginx его не перепишет при выполнении Accel-Redirect. Т.е. в этом случае эту строку нужно писать обязательно. Как будет в случаях с *CGI, не знаю — не проверял.

Чтобы предложить пользователю имя файла для сохранения, отличное от того, что в адресной строке (это особо актуально в случаях «download.php&file_id=12332″), отправим такой заголовок:

Content-Disposition: attachment; filename="Super File Name.zip";

2. В такой схеме при проксировании на Apache не работает докачка. Исправляем.

Докачка в HTTP работает через HTTP-заголовок Range. В нем указывается с какого байта начать передачу. Можно так же указать, сколько байт нужно передать. Это передается в запросе. Например:

Range: bytes=33-
Range: bytes=33-100

Первый вариант просит отдать весь файл, начиная с 33 байта (включительно). Второй вариант просит отдать с 33 байта по 100. Чтобы браузер понял, что докачка поддерживается, сервер отдает в ответе заголовок:

Accept-Ranges: bytes

Докачка не работает из-за того, что HTTP-заголовок Range попадает в Apache после просирования и последний думает, что его просят отдать кусок PHP-файла. А он это делать не хочет и отдает ошибку: HTTP/1.1 416 Requested Range Not Satisfiable.

Исправляется это довольно легко — просто зануляйте при проксировании Range (это нужно добавить туда, где у вас описано проксирование на Apache в конфиге nginx):

proxy_set_header   Range   "";

Тогда Apache (или PHP-скрипт) ничего знать про него не будут и спокойно сделают свое дело. А nginx после Accel-Redirect отдаст ответ в соответствии с запрошенным Range.

Если жизненно необходимо видеть в скрипте запрошенный Range, то его можно либо передать через дополнительный заголовок при проксировании (proxy_add_header), либо последовать совету отсюда.

3. Даже так не работает докачка в IE 9.

Да. На сколько я понял методом простого тыка, IE требует поддержки ETag сервером для работы докачки. Игорь Сысоев (разработчик nginx) отказался внедрять в nginx поддержку ETag. Поэтому из коробки работать докачка в IE 9 не будет точно. Если это жизненно необходимо, пробуйте смотреть сюда (Ctrl+F Etag).

4. А как работает докачка в других браузерах?

Везде есть свои особенности. В общих чертах случай докачки выглядит так. Запрос/ответ на скачку (начало скачки):

GET /file.zip HTTP/1.1
Host: example.com

HTTP/1.1 200 OK
Server: nginx/1.0.3
Date: Tue, 06 Mar 2012 18:09:47 GMT
Content-Type: application/x-force-download
Content-Length: 13686314
Last-Modified: Thu, 23 Feb 2012 13:50:26 GMT
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Content-Disposition: attachment; filename="Supre File Name.zip";
Accept-Ranges: bytes

Запрос/ответ на докачку:

GET /file.zip HTTP/1.1
Host: example.com
Range: bytes=5393683-

HTTP/1.1 206 Partial Content
Server: nginx/1.0.3
Date: Tue, 06 Mar 2012 18:10:11 GMT
Content-Type: application/x-force-download
Content-Length: 8292631
Last-Modified: Thu, 23 Feb 2012 13:50:26 GMT
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Content-Disposition: attachment; filename="Super File Name.zip";
Content-Range: bytes 5393683-13686313/13686314

На практике ни один браузер не ограничивается таким набором заголовков. Все хотят защитить пользователя от скачки битого файла. Это может получиться так: начал закачку, поставил на паузу; в это время на сервере скачиваемый файл обновился; продолжил закачку с нужно места и получил кусок обновленного файла. В результате скачается «битый» файл — половина старая версия, половина — новая.

Opera. Она шлет указание на то, что «если файл не менялся со времени Last-Modified в первом ответе, дай мне указанный кусок; иначе — отдай мне весь файл заново». Делается это с помощью заголовка If-Range в запросе:

GET /file.zip HTTP/1.1
User-Agent: Opera/9.80 (Windows NT 6.1; U; ru) Presto/2.10.229 Version/11.61
Host: example.com
Accept text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/webp, image/jpeg, ..., */*;q=0.1
Accept-Language: ru-RU,ru;q=0.9,en;q=0.8
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
If-Range: Thu, 23 Feb 2012 13:50:26 GMT
Range: bytes=5393683-

Firefox. Он делает немного иначе. Используется заголовок If-Unmodified-Since с указанием того же времени из Last-Modified. В этом случае сервер либо вернет запрошенный кусок (если файл не менялся), либо отдаст ошибку 412 Precondition Failed. Выглядит это так:

GET /file.zip HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ru-ru,ru;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: keep-alive
Range: bytes=5878651-
If-Unmodified-Since: Thu, 23 Feb 2012 13:50:26 GMT

Chrome. Этот «пильмень» — самый хитрый. Он вообще не поддерживает докачку, хотя делает вид, что поддерживает. При постановке закачка на паузу он просто шлет некие TCP-пакеты для поддержания соединения. Когда сервер понимает, что его дурят, он разрывает соединение. Если дождаться этого момента и нажать в Хроме «Продолжить», он сделает умный вид, будто файл полностью скачался и все ОК, но при этом он останется в том размере, в котором успел скачаться до паузы.

Вся эта информация получена методом наблюдения. Возможно в какой-то другой ситуации Хром повел бы себя иначе, но я через WireShark наблюдал именно такую картину.

IE. Про версию 9 уже сказано выше. Она требует работы Etag для поддержки докачки. В данном контексте ETag — это просто контрольная сумма файла. Когда Etag файла передается в первом ответе от сервера, IE даст возможность прервать скачку. При попытке докачки он отдаст заголовки:

GET /file.zip HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
Host: falcongaze.com
Range: bytes=3494051-
Unless-Modified-Since: Mon, 05 Mar 2012 08:31:06 GMT
If-Range: "1448453-f77f31-4ba7abf5a8680"
Connection: Keep-Alive

В добавок к If-Range он передает нестадартный заголовок Unless-Modified-Since — вероятено IIS его обрабатывает (только не понятно, зачем он, если есть стандартный If-Unmodified-Since; может для поддержки старых версий IIS?).

Собственно в первом ответе Etag выглядит примерно так (если он поддерживается сервером, например, Apache):

...
ETag: "1448453-f77f31-4ba7abf5a8680"

Дополнительная информация:

• RFC 2616. Header Field Definitions;
• List of HTTP header fields.

Ценность материала в том, что:

1) это хороший способ взглянуть на себя со стороны огромному числу программистов PHP, так как общая средняя квалификация этого класса программистов значительно ниже среднего по другим более серьезным языкам; взгляд со стороны поможет понять свои проблемы и найти способы их преодоления;

2) конкретные советы о том, что следует почитать/посмотреть.

Ссылка на материал: Как стать хорошим программистом и хорошим php-программистом в частности?

А ниже позволю себе сделать частичный копипаст предложенных решений.

Мастерство программирования (или скорее можно назвать Основы)

• Совершенный код,
• Чистый код,
• Рефакторинг,
• Программист-прагматик,
• Архитектура корпоративных программных приложений,
• Кодеры за работой.

Нашел очень хорошую и исчерпывающую статью на английском: How to be a Programmer: A Short, Comprehensive, and Personal Summary

Курсы, выложенные по MIT OCW:

• MIT Electrical Engineering and Computer Science

Курсы Стэнфорда:

• Mashine learning
• Natural Language Processing class
• Software Engineering for Software as a Service class

На каждом сайте внизу есть ссылки на другие курсы Стэнфорда.

Алгоритмы.

Как развивать:

Искусство программирования Кнутта — читать и выполнять задания.

Project Euer — задания по алгоритмам, можно писать на PHP.

ООП и Шаблоны проектирования

PHP: объекты, шаблоны и методики программирования М. Зандстра сейчас, наверное, лучшая книга для введения в шаблоны проектирвания для PHP.

Head First Design Patterns, на русском Паттерны проектирования — очень рекоммендуют, как очень хорошо разъясняющую книгу.

какие книги, методы обучения, задачи порекоммендуете?

PHP основы

Как развивать:

собственно работа по профессии и набор опыта,

Профессиональное PHP программирование — вроде как лучшая книга по основам PHP (читать, чтобы заполнить пробелы по основам языка, начиная с типов и далее. Посмотреть, что есть из того, чего я не казался в работе, чтобы расширять кругозор.

Потом есть stackoverflow, там введи в поиск ~php~ и читай вопрос, давай свой ответ (про себя), потом смотри, что другие написали. Будешь по тегам смотреть заодно, что пхп-ники изучают.

Javascript Основы

Как развивать:

собственно работа по профессии и набор опыта,

JavaScript. Подробное руководство. Д. Флэнаган (читать и разбираться в пропущенных основах – типы, обьектная модель и др.)

JavaScript: The Good Parts

JavaScript. Шаблоны

Источник: Как стать хорошим программистом и хорошим php-программистом в частности? Ни автор, ни комментаторы не имеют ко мне никакого отношения.

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

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

Хочется поехать на рынок и купить новой одежды? Значит, хочется созидать. Хочется программировать? Это также желание созидания. А вот если появилось желание почитать книгу или какие0нибудь статьи, «полистать» интернет, пообщаться с друзьями, то можно говорить о желаниях потребления.

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

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

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

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

Между этими периодами есть короткий срок, который представляет собой неопределенность. В это время нет явных желаний ни на потребление, ни на созидание. Либо не хочется вообще ничего, либо всего, но понемногу. Состояние в это время может становиться депрессивным. Этот период можно назвать «ломкой».

Все это напоминает всем известные биоритмы. Я никогда не вникал в эту тему и для меня слово «биоритм» ассоциируется только с графиком (ко)синусоиды, и все. Есть подозрение, что я для себя как раз и открыл биоритмы. Пока не знаю.

Все описанное выше можно изобразить на графике:

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

Очевидно, что периоды не сменяют друг друга моментально: вчера хочу одно, сегодня совсем другое. Их смена происходит плавно. Сначала желание постепенно усиливается, доходя до максимума (пика), потом постепенно угасает. Время перехода тоже растягивается на некоторый отрезок времени.

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

Во время явно выраженных периодов созидания и потребления лучше заняться делом – производством или самообучением в профессиональном плане; наведением порядка в жилище, починкой и обслуживанием личного транспорта или изучением/просмотром интересных материалов (статей, фотографий, фильмов) в плане свободного времени.

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

Конечно, это не значит, что нужно строго следовать описанное схеме. Например, отдыхать и уделять время семье нужно всегда. При этом легче определить, каким делам следует отдать предпочтение.

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

Все предложения хостинга можно разделить на 4 группы: Shared hosting (общий сервер), VPS (virtual private server — частный виртуальный сервер), Dedicated (выделенный сервер) и Cloud (облачный хостинг). Colocation (размещение сервера) в расчет не берется, так как это просто аренда места в стойке, а не хостинг.

Итак, с чем же можно провести аналогию?

Первое, что пришло в голову — ресторан. Shared — небольшой стол, заполненный едой, а вокруг стоя тянет руки толпа студентов. VPS — типичный ресторанный стол, у каждого своя еда на тарелке, присутствует малая группа людей. Dedicated — один за столом. Cloud — вот тут самое интересное. Толком придумать идею не получилось. Если у кого получится, велкам в комменты.

Чтобы восстановить пробел с Cloud, решил перенести фокус со стола на одну емкость — стакан. Shared — стакан с жидкостью забит трубочками. VPS — стакан перегородками поделен на 4 равные части, в каждой части своя трубочка. Dedicated — одна трубочка в стакане. Cloud — система стаканов, соединенных трубочками. К этой системе равномерно подключаются трубочки «клиентов».

Всё сходится, аналогия получается хорошая. Но нормально изобразить ее графически у меня не вышло. Выкладываю то, что получилось :) Если кто-то сможет нормально нарисовать эту красоту, буду весьма признателен :)

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

Решение. В консоли выполняем следующие команды:

$ sudo modprobe -r psmouse
$ sudo modprobe psmouse proto=imps

Заработал скрол? У меня — да. Если у вас тоже, по результат надо закрепить. Для этого открываем /etc/modprobe.d/options и добавляем туда строку.

sudo gedit /etc/modprobe.d/options

Строка:

options psmouse proto=imps

Теперь и после ребута скрол останется работать.

P.S. Печальные последствия такого способа заключаются в том, что из настроек мыши пропадает вкладка Touchpad.

Решение отсюда: http://superuser.com/questions/136568/get-back-the-touchpad-scrolling-missing-in-kubuntu-10-04

Если взять одного из ведущих российских облачных хостеров — selectel.ru, у которого самая низкая стоимость за Гб/час хранения данных (0,005 р), то месяц хранения бэкапов будет стоить 360—540 рублей в месяц. Это около $15. Много. При этом, платить надо еще за трафик и работу виртуальной машины во время синхронизации.

Рассмотрим сервис хранения файлов от Amazon. До терабайта там цена от $0.093 за Гб. Для хранения моих бэкапов понадобится от $9,3—14. Это поменьше, но там нет виртуальной машины, а значит сложнее синхронизация.

Для сравнения посмотрим на Dropbox. Мы знаем, что он хранит пользовательские данные на Amazon S3. Значит, не должно быть дешевле, чем в расчетах Амазона. Аккаунт Pro (100 Гб) стоит $20 в месяц. Да, дороже более чем в 2 раза.

Может Ubuntu One? 20 Гб у них стоят $3. Значит я заплачу примерно $14—22. Тоже дорого…

Стоимость внешних HDD от 250 Гб начинается от $55. Хоть надежность такого бэкапа будет гораздо ниже, чем в случае облаков, да и возни больше (ведь нельзя хранить винчестер в той же локации, где и сервер; а значит нужно либо носить его туда-сюда, либо договариваться с кем-то о бэкапах через интернет). Зато цена приятная: даже по Амазону наш HDD окупится через 6 месяцев.

Во всех расчетах не учитывались затраты на трафик. При первой синхронизации они будут велики ($10—20 для облаков), но при последующих синхронизациях они будут относительно небольшими (трудно подсчитать, ну пусть будет $1—2 в мес.). Для внешнего HDD затрат на первый слив не будет.

Есть также сервис, специализирующиеся на бэкапе в облака. Гуглятся по запросу «cloud backup». Я несколько штук посмотрел, но цен ниже $15 в месяц за 100 Гб не видел. Только больше.

Чтобы попасть в список Labs, нужно зайти в Google Maps и нажать на шестеренку в правом верхнем углу. В выпадающем меню выбрать «Maps Labs».

Откроется окно со списком, где можно включить/отключить ту или иную фичу.

Полезными я бы назвал только две первых: измерение расстояний и быстрый зум. Причем, расстояния — это то, чего мне больше всего не хватало в гуглокартах. В принципе, я считаю наличие измерителя расстояний в стандартной морде Яндекс.Карт самым весомым их преимуществом.

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

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

Тестовое задание сходу дают не все, а вот резюме читают, пожалуй, все работодатели. В зависимости от конъюнктуры рынка (отношения спроса к предложению) на этапе просмотра резюме отсеиваются до 90 % соискателей. У меня нет точных среднестатистических данных, но эмпирически рискну предположить, что в среднем отсеиваются 60—70% соискателей.

Это значит, что резюме играет очень весомую роль в процессе поиска персонала и поиска работы. Работодателю очень важно получить максимально качественное резюме, чтобы не отсеять хорошего кандидата из-за плохого резюме. Соискателю важно максимально качественно составить резюме, чтобы не упустить хорошую работу, где плохие резюме обязательно отложат в пачку «fail», т.к. ценят свое время.

Выходит, что всем выгодно, когда резюме составлено хорошо. А что значит хорошо? Это значит, что соискатель хорошо подаст все свои навыки, опыт и преимущества перед конкурентами, а работодатель получить всю первичную интересующую его информацию о кандидате.

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

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

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

С позиции работодателя расскажу о своем видении резюме веб-разработчика. Язык программирования при этом значения не имеет.

От соискателя в резюме важно получить следующую информацию:

1. минимальную информацию о себе, как о личности;
2. краткую информацию об образовании;
3. подробную информацию о предыдущих местах работы;
4. подробную информацию о навыках и опыте соискателя в контексте вакансии (позиции, должности).

Эти четыре пункта обычно содержит любое резюме по любой специальности. И на этом уровне оно стандартное. А вот какую информацию нужно писать по этим пунктам и как ее преподнести? Это уже позиционно-уникально.

1) Коротко о себе
Таблица или список со следующими строками. Все строки обязательны. Приложенная фотография является плюсом, т.к. психологически предполагает более серьезное восприятие резюме работодателем.

1.1) ФИО (отсюда станет ясен пол, так что писать нужно полностью)
1.2) Год рождения (или возраст, если резюме рассчитано на короткий период)
1.3) Город (место жительства, адрес не нужен)
1.4) Семья (брак, дети)
1.5) Образование (высшее/среднее/базовое или др.)
1.6) Отношение с армией (не обязательно писать, но все равно об этом спросят)
1.7) Иностранные языки (перечислить языки с указанием уровня влядения; не стоит тут писать русский, украинский или белорусский)
1.8) Позиция (должность; в одной организации может быть несколько вакансий, к которым подойдет ваше резюме, поэтому указать позицию или позиции, на которые претендует соискатель, нужно обязательно)
1.10) Желаемая заработная плата (реальная заработная плата, на которую нацелен соискатель в настоящее время; это очень важная для работодателя информация, и если соискатель знает, что он хочет, нужно обязательно указать, если не знает — на это укажет отсутствие данной информации; можно писать в стиле «от Х»)

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

2.1) Учебное заведение
2.2) Факультет
2.3) Специальность
2.4) Годы обучения (лучше указать время начала и окончания обучения, т.к. иногда возникают непонятные ситуации, когда указан только один год)
2.5) Окончен ли успешно? (если обучение прервано, об этом обязательно нужно написать отдельно)

3) Места работы
Работодателю важно знать предыдущий опыт работы соискателя. Этот опыт с разных точек зрения характеризует соискателя как профессионала. Важно не только, где работал соискатель, но и чем занимался, за что отвечал, чего добился, чем пользовался. Здесь лучше всего подходит таблица, но можно оформить и списком.

3.1) Название компании (так, как оно пишется «в миру»)
3.2) Сколько человек в организации/подразделении (опционально, если компания неизвестная, просто поможет оценить ее масштаб)
3.3) Должность (позиция, так, как она называлась в компании; можно дополнить общепринятым названием позиции, если оно отличается от принятого в компании)
3.4) Время работы (лучше всего в формате мм.гггг — мм.гггг / н.в.)
3.5) Обязанности (тезисно: что реально входило в круг обязанностей, пояснения и комментарии будут уместны)
3.6) Сколько человек в подчинении (если были люди в подчинении, об этом обязательно стоит упомянуть, иначе — пропускается пункт — 0 писать не нужно)
3.7) Проекты (это отдельный список проектов, в которых соискатель принимал участие в компании; если подход не проектный или если нет желания все расписывать, можно просто описать в текстовом виде, что соискатель сделал, работая в компании)
3.7.1) Название проекта с кратким описанием (из этого должно быть понятно, какие разработки велись в рамках проекта)
3.7.2) Временные рамки участия в проекте
3.7.3) Результаты (как личные, так и общие)
3.8) Причина ухода (если указывать желания нет, не надо, но все равно скорее всего на собеседовании спросят)

4) Технологии
Очень важный блок. Из него должно стать понятно, каким навыками соискатель владеет, с какими технологиями имел опыт работы и какой этот опыт, как соискатель оценивает свои знания. Информация обычно подается в табличном виде с колонками: название технологии, оценка своего уровня (по любой шкале, но не менее чем из 3-х уровней: начальный, средний, продвинутый), сколько лет опыта.
Здесь нужно писать только то, что уместно в контексте позиции. Не стоит указывать технологии, по которым уровень соискателя такой, который не позволит применение технологии на практике без дополнительного обучения. Информация разбивается на отдельные группы:

4.1) Языки программирования, разметки, запросов и т.д. (т.е. все, что является языком чего-либо или близко к этому)
4.2) Фрэймворки и библиотеки (стоит указывать только общеизвестные; нет смысла указывать самостоятельно разработанные библиотеки и фрэймворки, если ими пользуется только сам соискатель или его [бывшие] коллеги)
4.3) Технологии (то, что не является языком или библиотекой, но существует как стандартизированная и/или общеизвестная технология: AJAX, Web Services (SOAP), COM/OLE и т.д.)
4.4) Операционные системы (если у соискателя в арсенале опыт работы только с несколькими версиями Windows, этот пункт лучше вообще опустить; он имеет смысл, когда есть опыт работы с 2-мя и более разными ОС; версии одной и той же ОС лучше объединить в одну строку; разные дистрибутивы Linux/BSD/UNIX = разные ОС; необходимо указание уровня: администрирование сервера, либо использование в качестве десктопа)
4.5) Прикладное программное обеспечение (IDE, ПО для проектирования, разработки, тестирования, специфичное для специальности; не стоит сюда писать программы общего назначения, такие как Total Commander, FAR,  MS Office, gedit и т.д.)
4.7) Другое (если есть еще что-то важное, о чем соискателю хочется рассказать, следует это сделать)

Резюме лучше всего распространять в формате PDF. Если в качестве формата все же выбран Microsoft Word, то это должен быть формат DOC не выше версии Word 2003. Категорически не рекомендуется размещать резюме прямо в письме или в текстовом файле. Лучше сделать вложение к письму (не стоит размещать ссылку на скачивание резюме). Невыполнение этих требований говорит о неуважении к работодателю и вызывает аналогичное отношение к соискателю.

В моей практике был случай, когда в ответ на вакансию я получил письмо следующего содержания: «Здравствуйте. Слать резюме надоело, поэтому не буду. Если у вас действительно есть сложные задачи и хорошо поставлен рабочий процесс, звоните +37529…..». Сомневаюсь, что с таким подходом человеку удастся найти работу. Естественно, это письмо я проигнорировал. Через несколько дней этот человек перезвонил по телефону. Конечно, стоило сразу сообщить ему, что даже разговаривать с ним нет желания. Но я этого не сделал, и постарался более-менее вежливо с ним поговорить. Через пару минут разговор был закончен по смыслу тем, что он нам не подходит.

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

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

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

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

Факторную модель можно составить для любой специальности, но она должна быть специализирована. Делать универсальную модель для всех сразу нет смысла — ее точность будет очень плохая. Я составил модель для своей специальности — разработчик ПО.

Факторный анализ места работы для разработчика ПО

1. Интерес
   • Проект
     • тематика
     • технологии
     • уровень сложности
     • нагрузки в продакшане
   • Зона ответственности
     • разброс обязанностей
     • принятие решений
   • Подчиненные
     • количество
     • качество
   • Заказчик
     • локальность
     • культурные различия
     • требовательность
2. Условия труда
   • Офис
     • эстетика
     • расположение
     • размер, оформление  комнаты и ключевых узлов
     • вентиляция и кондиционирование
     • ремонт (состояние)
     • стоянка
   • Рабочее место
     • компьютер
     • монитор
     • админские права и ограничения по ОС/ПО
     • интернет и ограничения
     • стол, стул
     • освещение
   • Коллеги и руководство
     • размер команды
     • адекватность руководителя
     • простота административной структуры
     • постановка работы команды
   • График
     • время работы
     • гибкость графика
     • отработки
3. Оплата
   • Зарплата
     • сумма
     • валюта
     • рост
   • Социальные вопросы
     • социальный пакет
     • корпоративы
   • Проблемы
     • задержки зарплаты
     • штрафы
     • ограничения контракта

Оценка по каждому фактору:

• 0 — нейтрально, нормально,
• ­­−1 — плохо,
• +1 — хорошо.

Проставляется оценка по каждому фактору 3-го порядка. Важно понимать, что оценка +1 всегда обозначает, что по данному вопросу обстоятельства в вашу пользу. Не важно как называется фактор: «уровень зарплаты» или «штрафы», +1 всегда будет обозначать, что по этому фактору вы в положении «хорошо» для себя. Соответственно −1 — значит «плохо» для вас.

Оценки суммируются по группам — факторам 1-го порядка. Каждому фактору 1-го порядка выставляется субъективный вес, который приводится к коэффициентам. Например, устанавливаются веса: «Интерес» — 10, «Условия труда» — 7, «Оплата» — 8. Тогда коэффициенты будут: «Интерес» — 40% (10/(10+7+8)=0,4), «Условия труда» — 28% (0,28), «Оплата» — 32% (0,32).

Коэффициент при факторе 1-го порядка покажет, какую долю в оценке займет этот фактор. Такой подход позволяет сильно влиять на результат в зависимости от предпочтений разных людей не меняя модели: кому-то уровень заработной платы в 2 раза (условно) важнее интереса в работе, а кому-то наоборот. В первом случае «Интерес» может получить 20%, «Оплата» — 40%, во втором соответственно наоборот.

Полученная сумма по каждому фактору 1-го порядка умножается на коэффициент этого фактора и делится на количество его факторов 3-го порядка. Затем полученные числа суммируются.

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

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

Самый лучший способ заполнить факторную модель — наличие «своего» человека в организации. Это особенно актуально, когда работу предлагают по рекомендации.

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

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

Модель должна быть сбалансирована по факторам 2-го порядка. Если фактор 2-го подяка имеет важное и широкое значение, то факторов 3-го порядка в нем должно быть много. Если значение слабое — мало. В остальных случаях количество факторов 3-го порядка должно быть примерно равным и относительно небольшим.

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

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

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

Материал разделен на три части: А — теория, Б — практика, В — создание мультизагрузочной флэшки.

А. Общая теория (популярно).

1. Железо.

Все физические устройства, которые используются нами повседневно для хранения информации (HDD, CD-ROM, флэшка, и даже флопик) — это блочные устройства ввода/вывода (block I/O device). Они могут подключаться к компьютеру через различные интерфейсы: IDE, SATA, eSATA, USB. Операционная система предоставляет единый прозрачный для пользователя и программиста прикладного ПО способ чтения/записи информации с/на эти носители.

С железом напрямую общаются драйвера. Драйвер — это программа, загруженная в операционную систему. Он является прослойкой между ОС и устройствами, представляя для ОС стандартный программный интерфейс блочных устройств I/O.

2. Данные на физическом диске.

Блочными эти устройства называются потому, что информация на них записывается и считывается блоками (секторами, кластерами) фиксированного размера. Размер блока кратен 512 байт. Блочный подход необходим для обеспечения высокой скорости работы дисковой подсистемы.

Сам диск форматируется (размечается) на низком уровне (на заводе). Диск состоит из цилиндров. Цилиндр — это окружность на пластине диска. Первые цилиндры расположена в центре пластины диска, последние — на внешнем краю. Каждый цилиндр делиться на секторы. В пределах секторов организуются блоки на диске. Помимо самих данных в блоках записывается информация для контроля ошибок. С этой информацией работает контроллер внутри жесткого диска и она не видна снаружи. Драйвер посылает команды контроллеру диска на уровне «считать 10 блоков 10 цилиндра 20 сектора».

Все полезные данные, записанные на носитель, организованы в разделы. В Windows каждый раздел обычно представлен в виде логического диска (C, D, E, …). На сменных носителях (флэшка, компакт-диск, флопик) как правило создан один единственный раздел, на внутренних жестких дисках — наоборот — обычно несколько разделов. Данные в разделе организованы в файловой системе.

Для каждого раздела может независимо устанавливаться свой размер блока — размер кластера. Он регулирует баланс скорость/экономичность. Блок — это минимальная адресуемая единица разметки на диске. Кластер объединяет несколько блоков — это минимальная адресуемая единица в разделе.

Таким образом устанавливается следующая логическая иерархия (от внизу вверх): блок, сектор, цилиндр — кластер — раздел — файл, каталог.

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

3. Разметка физического диска.

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

Так как на диске может быть несколько разделов, их нужно где-то перечислить с указанием пределов и свойств каждого раздела. Для этого служит таблица разделов, которая находится в начале физического диска (начало диска — это его первый блок в соответствии с адресацией). В классическом случае она входит в состав MBR (master boot record), которая целиком занимает первый блок. На всю таблицу разделов выделено 64 байта. Каждая запись таблицы состоит из адресов начала и конца раздела, типа раздела, количества секторов в разделе и флага «загруженности» раздела и занимает 16 байт. Таким образом максимальное количество разделов на диске ограничено четырьмя (16 × 4 = 64).

Так сложилось исторически, но со временем стало очевидно, что 4 раздела не всегда достаточно. Решение проблемы было найдено. Те разделы, которые размечены в заголовке диска (в MBR), назвали Primary (первичные). Их по прежнему должно быть до 4-х включительно. Дополнительно ввели понятие Extended (расширенных) разделов. Расширенный раздел включает один или более подраздел и не содержит файловой системы. Сам он является полноценным первичным разделом.

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

Разметка расширенного раздела описана в в его начале. По аналогии с MBR существует EBR (Extended boot record), расположенная в первом секторе. В ней описывается разметка логических дисков данного расширенного раздела.

На оптическом диске и флэшке обычно размещается только один раздел, так как более мелкое деление там не имеет смысла. Обычно при записи компакт-диска применяется файловая система ISO 9660. Образ диска с этой файловой системой называется ISO-образ. Он часто используется в отрыве от физического диска в качестве контейнера для передачи данных, т. к. любой образ — это побитовая точная копия физического носителя.

4. Файловая система.

Каждый раздел диска, предназначенный для хранения данных (т. е. все разделы, кроме расширенного) форматируется в соответствии с некоторой файловой системой. Форматирование — это процесс создания структуры файловой системы в некотором пространстве на диске — в разделе. Файловая система организует пользовательские данные в виде файлов, расположенные в некоторой иерархии каталогов (папок, директорий).

Структура каталогов и файлов в разделе в классическом случае описана в таблице файлов. Как правило таблица занимает некоторое место в начале раздела. После таблицы пишутся сами данные. Таким образом создается система, где структура описана отдельно, а данные (файлы) хранятся отдельно.

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

В процессе работы на диске могут возникать физические повреждения. Некоторые блоки могут становиться недоступными для чтения. Эти блоки называют «бэдами» (bad sector). Если в процессе чтения диска попадает бэд, происходит ошибка ввода/вывода (I/O error). В зависимости от того, в каком месте появился бэд-блок и сколько их появилось, может потеряеться либо часть содержимого файлов, либо в часть таблицы файлов.

При попытке записи в бэд-блок контроллер диска должен определить проблему и выделить для этого блока новое место на поверхности диска, а старое место из использования изъять (relocate bad block). Он делает это незаметно для ОС и драйверов, самостоятельно. Происходит это до тех пор, пока есть резерв места для переноса.

5. Работа с диском.

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

В ОС семейства UNIX все устройства хранения данных представлены в виде файлов в каталоге /dev:

• sda, sdb, sdc, … — физические диски (HDD, включая внешние, флэшки, IDE-сидиромы);

• fd0, fd1 — флопики.

Разделы на каждом из дисков доступны в виде sda1, sda2, sd3, …

Нумерация дисков происходит в том порядке, в котором их видит BIOS. Нумерация разделов — в порядке создания разделов на диске.

Чтобы сделать образ (образ — это побитовая копия информации, размещенной на диске или в разделе) диска целиком (например первого по BIOS — sda), нужно вычитать данные из /dev/sda в любой другой специально созданный для образа файл, используя программу последовательного копирования содержимого файла. Чтобы записать образ в файл, нужно при помощи той же программы вычитать данные из образа в /dev/sda. По аналогии можно создать/восстановить образ раздела (например, первого на первом диске — sda1), обращаясь к /dev/sda1 вместо /dev/sda.

6. Монтирование.

Чтобы «превратить» дисковое устройство в набор файлов и каталогов, к которым можно получить доступ, его необходимо примонтировать. В Windows как такового монтирования не существует. Там разделы просто подключаются к логическим дискам (C:, D:, E, …). Информация о том, какую букву присвоить какому диску, хранится в самой ОС.

В UNIX понятие монтирования является основоположным в работе с дисками и дает значительно больше гибкости, чем есть в Windows. Монтирование — это процесс привязки некоторого источника образа диска (это либо сам диск, либо файл с его образом) к некоторому каталогу в файловой системе UNIX. Файловая система в UNIX начинается из одной точки — от корневого каталога (/), и никаких логических дисков C, D, E не существует.

В начале загрузки ОС семейства UNIX в корневой каталог / монтируется раздел диска, помеченный как root (корневой). На разделе диска должны быть созданы служебные каталоги ОС, находящиеся в корне файловой системы. К ним могут монтироваться другие разделы, либо файлы могут записываться прямо в основной раздел (примонтрированный к /).

Ключевой момент заключается в том, что источник образа диска (блочное устройство, файл с образом или каталог уже примонтированной файловой системы) можно монтировать к любому каталогу на любом уровне вложенности файловой системы, которая начинается с /. Таким образом, разные логические разделы физического диска представляются каталогами в единой файловой системе в противоположность отдельным файловым системам разных логических дисков в Windows (там каждый диск рассматривается как автономная файловая система, имеющая свой корень).

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

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

7. MBR — загрузочная область.

В начале физического диска обычно расположена MBR (master boot record). Это загрузочная область диска. При загрузке компьютера BIOS определяет какой диск является первичным (primary) и ищет на нем MBR. Если она найдена, то ей передается управление. Если нет, выводится ошибка о том, что загрузочный диск не найден.

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

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

Код GRUB слишком большой, чтобы поместиться в MBR. Поэтому он устанавливается на отдельном разделе (обычно в том разделе, который монтируется в /boot) с файловой системой FAT, FFS или Ext2. В MBR записывается код, который загружает код GRUB с определенного раздела и передает ему управление.

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

Сделать бэкап загрузочной области диска так же легко, как бэкап всего диска или отдельного раздела. Суть в том, что MBR занимает первые 512 байт диска /dev/sda. Следовательно, для бэкапа MBR необходимо вычитать первые 512 байт /dev/sda в файл, а для восстановления — наоборот — файл вычитать в /dev/sda.

Озадаченно смотрю на версии «свежего софта»…

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

Объясните — в чем смысл? Только в «проверенности» и стабильности этих версий?

Ответ:

Да. И это «только» весьма дорогого стоит. Более того, в рамках политики дебиана обновляться версии будут только на security fix’ы, то есть никаких новых фич до момента явного dist-upgrade’а. Сравните с убунтой, в которой каждые N дней пачка обновляемых пакетов.

Для десктопа это, может быть и нормально, но для сервера — неприемлимо. Я лично несколько раз сталкивался с дурацкими проблемами при обновлении версий (к счастью, только на декстопе). В списке лидеров — evolution (похерил архив почту), krusader (похерил половину настроек), deluge (криво подцепил старые настройки).

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

Таким образом, stable — это идеальное решение для сервера. А sid/ubuntu — вполне хорошо для _своего_ десктопа (решать проблемы похерившейся почты у себя неприятно, но решать их же у главбуха — куда грустнее).

Кстати, ровно той же политики придерживается и RHEL (CentOS) — у них в пятой версии до сих пор 2.6.18, хоть и с кучей бэкпортов.

© amarao, Хабрахабр.

Полностью защитить протокол общения пользователя с сервером можно только одним способом — шифрование трафика. Экзотические способы шифрования, а также создание различного вида тоннелей мы не рассматриваем. Только обычное SSL-шифрование протокола HTTP, которое поддерживает любой современный браузер — HTTPS.

Причем, работает нормально HTTPS только в том случае, если для пользователя не произошло незаметной подмены сертификата (как это делает софт на подобии SecureTower). В случае, если сертификат подменяется незаметно или пользователя в открытую заставляют принять невалидный сертификат (т.к. иначе ничего не будет вообще) HTTPS работать перестает.

И вот, учитывая это, возникает вопрос: если полностью защитить трафик мы не можем, то можем ли мы защитить хотябы самое важное? Например, пароль. В принципе, можем, но тоже не на 100%. Пароль можно хэшировать до передачи на сервер JavaScript-ом. Тогда перехватчик получить хэш. Он сможет по нему авторизоваться, но сам пароль не увидит. Правда, его можно подобрать брутфорсом. С шифрованием самого пароля (вместо хэширования) картина примерно та же, только реализация гораздо сложнее.

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

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

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

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

Именно так поступили в Яндексе. У них я подсмотрел способ определения доступности HTTPS. Подгружается JS с https://, который устанавливает флаг в DOM-модели страницы. Форма авторизации ведет себя по разному в зависимости от этого флага.

Хэшировать ли пароль? Это может иметь значение только в одном случае: если у пользователя один пароль на несколько сервисов. Тогда перехватчик не увидит пароля в открытом виде, чтобы использовать его на других сервисах. Но подобрать брутфорсом пароль все равно возможно. Только это уже не так тривиально, как подсмотреть в открытом виде. Так что если вы на стороне пользователя, постарайтесь пароль хэшировать до передачи.

А как делают другие?

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

Mail.ru ведет себя как Яндекс, только их способа определения поддержки HTTPS я не нашел (хотя и не глубоко искал).

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

Facebook, как и Google, прекрассно работает по HTTPS. Авторизация по умолчанию защищенная. Пароль в открытом виде.

Вконтакте, Одноклассники, TUT.BY и Onliner.by по HTTPS не отвечают, защищенную авторизацию не предлагают, пароль идет в открытом виде.

oz.by по HTTPS предлагает принять самоподписанный сертификат, чтобы потом произвести редирект на HTTP. Пароль в открытом виде.

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