Долгое время я пытаюсь понять, сколько места отведено вопросам параллельности и конкурентности выполнения кода в повседневной практике среднестатистического PHP-программиста. С одной стороны, разрабатывая серверное приложение, программист автоматически пишет код, который будет выполняться параллельно. С другой, на практике в PHP все проблемы этой области решались инструментами, которыми все пользовались — веб-сервер, сессия и СУБД.

Обращают ли на ваших проектах внимание на на проблемы синхронизации параллельно обрабатывающихся HTTP-запросов? Они решаются через транзакции, блокировки? Какие способы блокирования вы используете? Да и вообще, нужно об этом париться, или тема бесполезная? Узнаем мнение аудитории. Этот пост не дает ответов на вопросы. Здесь ведется разведка.

2 года назад я написал статью о классификации знаний в области программирования. Это было на волне интереса и моей активной деятельности по самообразованию в компьютерных науках. Написал статью и забыл о ней. Публиковать на Хабре не собирался. В конце концов, она базируется на моем личном опыте и знаних, которые могут оказаться весьма субъективны.

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

Но прежде, чем «запустить» материал, еще небольшое отступление. О том, почему вообще я все это писал. Дело в том, что у нас в странах бывшего СССР с образованием в области IT очень туго. С одной стороны нет программ обучения, которые подготовят специалистов на должном уровне (наверное, за очень редкими исключениями, которые можно отнести к погрешности). С другой стороны, из-за широких возможностей самообразования, программисты и не спешат учиться в ВУЗах — все стремятся начать практиковать как можно раньше. Часто изучается только одно направление (например PHP+Mysql — самое популярное) и в бой. Причем, на этом все заканчивается. В итоге у нас огромное количество программистов, которые и базовых вещей не знают. Отсюда вытекают проблемы с качеством кода, и с эффекивностью алгоритмов, с велосипедированием.

Но программирование — это полноценная область знаний, которая требует в том числе и инженерной подготовки. Точно так же, как строительство или телекоммуникации. Да, построить дом (особняк) можно своими руками и без образования. А поднять большинство сайтов можно прочитав пару книг по PHP и HTML. Но многоэтажку без специальной подготовки не построишь, как и Гугл не напишешь, не зная основ.

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

Поехали.

В компании, где я работаю, сейчас идут процессы по наведению порядка с доступом сотрудников в Интернет. В связи с этим я задался вопросом: а как же на сегодняшний день организован доступ в сеть в других айтишных конторах. Думаю, что результаты опроса будут интересны не только мне, но и другим системным администраторам и руководителям IT-отделов. Много лет назад повально практиковалось проксирование, но постепенно его вытесняла обычная маршрутизация и открытый канал для всех. Как же обстоят дела на сегодняшний день?

30 марта 2012 года вышел финальный релиз Proxmox VE 2.0. Первая публичная бета вышла 30 сентября 2011 — ровно 6 месяцев шла заточка напильником. RC1 был опубликован 16 февраля 2012.

Хочу поделиться неприятной историей, которая случилась со мной сегодня. Заодно, полезная информация для всех клиентов Selectel, и для менеджмента самой компании (возможно через Хабр до них информация дойдет быстрее, чем через собственный саппорт).

Сегодня днем сервис livejournal.com подвергся самой сильной в истории сервиса DDoS-атаке. Новостные сайты быстро раструбили эту тему, но конкретики указано мало. Есть и видео-версия.

Сам ЖЖ на домене livejournal.com сейчас не открывается вообще (происходит connection timeout). Livejournal.ru открывается, но даже авторизация на сервисе не работает.

Цитата:

В 16.00 руководитель российского ЖЖ Светлана Иванникова обратилась к пользователям сайта, пояснив, что портал подвергся нападению хакеров: «В настоящий момент LiveJournal действительно работает некорректно, мы подтверждаем эту информацию. Связано это с тем, что ЖЖ подвергается DDoS-атаке, но ее источник, как и адресата, мы не можем назвать. Администраторы „Живого журнала“ в курсе и уже работают над устранением проблемы»

Информация обь этом событии присутствует и на самом ЖЖ, но никакие подробности не раскрываются.

Как раз вышло хорошее продолжение новости "DDoS-атаки внесут в Уголовный кодекс (статьи 272–274)".

UPD. 22:34 Мск. Страницы ЖЖ начали открываться.

В MySQL 5 есть несколько типов данных для хранения даты и времени. Это TIMESTAMP, DATE, DATETIME, TIME и YEAR. Все они обладают своими особенностями, и выбор в пользу того или иного календарного типа должен производиться отдельно в каждой конкретной ситуации. Я хотел бы поделиться с вами результатом моего сегодняшнего миниисследования этих типов, в том числе в аспекте работы с временными зонами.

Как известно, в октябре в Москве впритык пройдут 2 известные ежегодные конференции: PHPConf (8—9) и HiLoad++ (12—13).

Посещение этих мероприятий для белорусов очень накладно, так как к стоимости участия (~280$ PC и ~190$ HL) нужно прибавить билет на поезд (~80$ min в обе стороны) и проживание (отели от 80$ в сутки).

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

А вы собираетесь туда ехать? На чем? Где жить? Может кто-то едет группами? Естественно, эти вопросы адресованы проживающим в РБ.

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

^{P.S. Топик открыт только подписчикам блога Байнет (не забывайте это, если отправите ссылку друзьям).}

 

С недавнего времени белорусская версия Гугла доступна на домене второго уровня google.by.

Долгое время белорусская версия была доступна по адресу google.com.by из-за того, что домен google.by был занят. Если точнее, то он был выкуплен Денисом Кораблевым — руководителем компании activemedia.by. В это время на сайте крутился поисковый интерфейс Гугла, который вел на сам google.com, продавалась контекстная реклама и ссылки с главной страницы. Правда в сентябре 2008 сайт закрылся.

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

Многие хабрапользователи уже давно знают об этом сервисе, зарегистрированы на нем и разместили в сети свои Хаброметры. Знают они о нем потому, что примерно месяц назад я уже публиковал информацию о сервисе в закрытом блоге I ♥ Habrahabr. После этого многое было переработано, исправлены ошибки, проведена оптимизация. А теперь настало время рассказать о сервисе всем хабралюдям.

Вчерашний вечер я посвятил возне с http-сервером nginx в качестве фронтэнда к apache. Как известно, nginx — легковесный надежный HTTP-сервер, написанный Игорем Сысоевым (сотрудником Rambler). Он отлично подходит для выдачи статических страниц, особенно под нагрузкой. Обычно настраивается связка nginx+apache, в которой nginx обслуживает все входящие на сервер запросы, статические файлы отдает своими силами, а запросы на динамическое содержимое проксирует на apache.

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

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

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

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

Все таки к хорошему привыкаешь быстро… Хабрахабр — замечательное сообщество.

UPD. Кстати, первый же коммент наталкнул на мысль написать в этом послании чуть-чуть познавательной информации. Наверняка многие не знают, когда «Вы» надо писать с прописной буквы, когда со строчной. Так вот, в издательстве, в котором я работаю, принято так: когда обращение идет к одному контретному человеку (например письмо по e-mail), пишется с прописной буквы. А когда обращение к неопределенной группе (например к читателям), пишется со строчной.

В комментариях предлагаю обсудить, как удобнее общаться вам на форумах и соцсетях: «на ты» или «на Вы»?

Еще вчера вечером был выпущен последний релиз PHP четвертой ветки. В нем исправлены несколько серьезных уязвимостей и обновлена версия PCRE до 7.7.

На этом поддержка и обновления PHP 4 заканчиваются. Хотя уже давно широкими шагами идет по миру PHP 5, на многих хостинговых площадках все еще остается четверка (часто совместно с пятеркой).

Итак, сегодня эпоха PHP 4 официально закончена.

Новость о выходе версии 2.2 на официальном сайте.

Добавлено:

• Компоненты — CheckboxGroup / RadioGroup
• Помощник работы с кнопкой Back — History
• Компоненты — MultiSelect / ItemSelector
• Компонент — FileUploadField
• Компонент — XmlTreeLoader
• Компонент для карт google.maps — GMapPanel

Кроме того, конечно же, исправлены баги, обеспечена полная поддержка Firefox 3, добавлены подробные примеры Drag and Drop, увеличена производительность движка и т.д.

Пользователям 2-й ветки рекомендуют обновиться. Скачать версию 2.2.

На работе в новом проекте используется СУБД PostgreSQL. Так как до сих пор я работал с MySQL, сейчас приходится изучать и открывать для себя Постгри. Первая проблема, которая меня заинтересовала — замена мускулевского SQL_CALC_FOUND_ROWS. При использовании этой константы в MySQL можно получить количество всех найденных по запросу записей, даже если запрос с limit'ом — это незаменимо при постраничном выводе поисковых результатов, когда используются «тяжелые» запросы.
Сходу готового решения найти не удалось. На форумах просто констатировали, что SQL_CALC_FOUND_ROWS в Постгри нет. Некоторые писали, что надо юзать count(*). И больше никакой информации. Но еще из MySQL мне было известно, что поиск с count()-запросом работает почти в 2 раза медленнее, чем с SQL_CALC_FOUND_ROWS. Я консультировался у тех, кто пользуется PostgreSQL, день мучал google и в результате получил 4 варианта замены SQL_CALC_FOUND_ROWS в PostgreSQL, один из которых вполне приемлимый по скорости.

По просьбам трудящихся, а так же учитывая, что есть статья по установке SVN (правда +Trac) под Linux, решил написать краткое описание установки и настройки SVN для Windows.
Ничего нового для людей, хорошо знающих и работающих с SVN, здесь не будет. Цель статьи — помочь некоторому проценту новичков, пребывающих на Хабре, таки осилить изучение этой системы контроля версий.

Сегодня решил разобраться, как PHP определяет ключ в массив $_GET для параметров, поступивших соответственно методом GET. Честно говоря, такой алогичности в работе этого механизма увидеть я не ожидал. Хотя в целом, почему так получилось, понятно…