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

Введение

В русскоязычной части Интернета присутствует большое количество статей, посвященных веб-службам на основе SOAP и XML-RPC, но почему-то почти ничего нет про вполне заслуживающую внимания (но менее распространенную) архитектуру RESТ.

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

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

Смена работы – это всегда стресс. Новое место, новые люди (каждый со своими, пока неизвестными особенностями), новые правила и новые обязанности. По моему опыту, среднее время адаптации в новом коллективе – 2-3 месяца. Плюс к тому, смена работы это риск. Риск не пройти испытательный срок, не прижиться в новой команде, не справиться с возложенной ответственностью.

Но, несмотря на все это, люди уходят с насиженных мест. Проработав 2/3/5 и более лет в компаниях, начинают изучать джоблист, и, в конце концов, уходят.

Чем это вызвано?

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

А вы знаете, что в 99% приложений и абсолютно всех CPAN-модулях таймеры и таймауты реализованы неправильно? Не верите? Правильно не верите! Есть, есть один CPAN-модуль, с корректной реализацией таймеров: EV. :) (Кстати, это, похоже, единственный CPAN-модуль из всех, реализующих event loop, который знает о проблеме использования fork вместе с event loop, описывает её в документации и даже пытается как-то решать!)

Проблема в том, что для реализации таймеров и таймаутов используются функции, возвращающие текущее время. А текущее время может быть изменено в любой момент в любую сторону на любую величину — админом или NTP-демоном. Поэтому получается так, что, например, таймаут установленный программой на 30 секунд, может сработать либо через 2 секунды, либо через пару суток — смотря как изменится текущее время после установки таймаута (а в особо запущенных случаях может не сработать никогда).

Единственный надёжный способ работать с таймерами и таймаутами — использовать монотонное время:
use Time::HiRes qw( clock_gettime CLOCK_MONOTONIC );
$now = clock_gettime(CLOCK_MONOTONIC);

Поддержка CLOCK_MONOTONIC была добавлена в Time::HiRes (по моей инициативе :)) два года назад. И вот сегодня я снова, как и два года назад, поискал на CPAN модули с правильной реализацией таймеров и таймаутов… и нашёл только один. :(

Думаю, любой программист на Perl довольно регулярно добавляет в программу вспомогательный код, который не должен выполняться всегда. Это может быть отладочный код, сбор статистики о скорости работы разных частей кода, вывод в лог, и т.д. С этим кодом связано сразу несколько проблем:

1. Он мешает читать основной код.Он замедляет выполнение программы.Из-за первых двух причин его зачастую удаляют, как только необходимость в нём пропадает… только, к сожалению, необходимость в нём регулярно возникает снова, и этот код, матерясь, снова пишут… чтобы через несколько часов снова удалить.Борьба с первой проблемой, как правило, обречена на неудачу. Ибо если код должен выполняться, то он должен быть написан. А если он написан, то он царапает глаза, разрывает основной код, раздувает код, отвлекает и раздражает. Решить эту проблему, как правило, удаётся только тогда, когда этот код должен быть написан в самом начале и/или конце функции — тогда можно автоматически сгенерировать функцию-обёртку, которая спрячет внутри себя этот код.
   
   А вот со второй проблемой бороться можно вполне успешно:

Недавно в офисе Хабра я хотел прочитать своим коллегам небольшой доклад об объектной ориентации и наследовании классов в JavaScript.

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

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

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

Весь текст подеён на 5 разделов:

1. ООП в Java Script (1/5): Объекты
2. ООП в Java Script (2/5): Классы
3. ООП в Java Script (3/5): Свойства и методы класса
4. ООП в Java Script (4/5): Наследование классов
5. ООП в Java Script (5/5): Полезные ссылки

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

Основы масштабирования

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

Обычно о масштабировании начинают думать тогда, когда один
сервер не справляется с возложенной на него работой. С чем именно он не
справляется? Работа любого web-сервера по большому счету сводится к основному
занятию компьютеров — обработке данных. Ответ на HTTP (или любой другой) запрос
подразумевает проведение некоторых операций над некими данными. Соответственно,
у нас есть две основные сущности — это данные (характеризуемые своим объемом) и
вычисления (характеризуемые сложностью). Сервер может не справляться со своей
работой по причине большого объема данных (они могут физически не помещаться на
сервере), либо по причине большой вычислительной нагрузки. Речь здесь идет,
конечно, о суммарной нагрузке — сложность обработки одного запроса может быть
невелика, но большое их количество может «завалить» сервер.

Представляю на суд сообщества перевод интервью Питера Муна с президентом фонда свободного программного обеспечения Ричардом Столлманом. В интервью Ричард повествует о том, что заставило его приступить к разработке свободной операционной системы GNU, объясняет свое видение понятий «свободное ПО» и «ПО с открытым исходным кодом» и их различия, призывает пользователей к борьбе с проприетарным ПО, а также просит не называть Linux просто Linux`ом.

Вчера мне пришла одна интересная мысль как достичь недеяния.

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

Примечание: ниже расположен перевод статьи «jQuery for JavaScript programmers», в которой автор высказывает свое мнение об этой библиотеке, ориентируясь, в первую очередь, на продвинутых программистов, и приводит несколько десятков примеров ее использования.

Когда jQuery увидела свет в январе 2006, я подумал: «очередная красивая игрушка». Выбор CSS-селекторов в качестве базиса было, конечно, изящной идеей (подробнее о ней в моей заметке getElementsBySelector), но использование цепочек преобразований выглядело немного замысловато, и сама библиотека, по-видимому, не покрывала всех возможных случаев. Я расценивал тогда jQuery только как временное и проходящее решение.

Только несколько месяцев спустя понял я, насколько же ошибался по отношению к ней. jQuery является просто произведением инженерного искусства. Она умело покрывает достаточно широкой диапазон повседневных функций и предоставляет при этом удобный API для расширений, с помощью которых можно добавить любую другую функциональность. Абстрактность в ней заложена на уровне ядра — речь идет о выборе DOM-элементов — и она извлекает из него максимум пользы. И что важнее всего, использование этой библиотеки подразумевает следование хорошему стилю в программировании и хорошо сочетается с другими частями JavaScript-кода.

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

FWC:SmartSelect 2.7

хей йо)
начну.
всем известны проблемы с тегом select в html: отсутствие возможности настройки внешнего вида, перекрывание абсолютно позиционированных слоев, отсутствие комбобоксов (выпадающих списков с возможностью ввода), отсутствие нормального мультивыбора и некоторые другие. все они имеют некоторые, чаще всего корявые, решения, которые врядли можно назвать панацеей.

когда мне всё это надоело, я написал тулкит, который решает все эти проблемы одним махом.
этот тулкит позволяет максимально просто создать «поддельный» выпадающий список, который на первый взгяд идентичен стандартному тегу select, но лишенный всех его недостатков.

кроме того он позволяет использовать некоторые очень полезные функции, крайне популярные в последнее время. например, удобный API для управления списками и пунктами (создание, редактирование, удаление), ajax-подгрузка каскадных списков (когда содержимое некоторых списков зависит от других), а также создание простых текстовых полей с автоподстановкой значений при вводе (в том числе и из серверных ресурсов, аналогично Google Suggest).

все настройки для компонентов smartselect описываются в отдельном xml-файле или json-строкой.

Примечание: ниже перевод обзорной статьи «JSON vs XML», посвященной JSON и его сравнению с XML по ряду критериев. Публикуется в целях популяризации JSON среди читателей Хабрахабра.

JSON (англ. JavaScript Object Notation) — формат обмена данными, легко читаем людьми, легко обрабатывается и генерируется программами.

Основан на подмножестве языка JavaScript, Standard ECMA-262 3rd Edition — декабрь 1999.

JSON — Википедия

Что является правильным форматом ответа на XMLHttpRequest в AJAX-приложениях? Для большинства приложений, основанных на разметке, ответ будет простым — (X)HTML. Для информационно-ориентированных приложений выбор будет лежать между XML и JSON. До недавнего времени я не сильно задавался вопросом, что лучше использовать, XML или JSON. Я просто предполагал, что в каждом конкретном случае стоит выбирать наиболее подходящий формат, и все. Но недавно мне довелось проверить на практике этот подход. В этой заметке я опишу критерии, по которым проводил сравнение между XML и JSON, и собственные умозаключения.

Итак, критерии следующие.

• Удобочитаемость кода.
• Простота создания объекта данных на стороне сервера.
• Простота обработки данных на стороне клиента.
• Простота расширения.
• Отладка и исправление ошибок.
• Безопасность.

В своих архивах я обнаружил перевод старого и хорошо известного, но не потерявшего актуальности руководства brian d foy по отладке программ на Perl.

JT Smith, президент Plain Black, создатель WebGUI, и одного из незамеченных успешного применения Perl в бизнесе, недавно прислал мне это эссе. Он разрешил мне издать его полностью здесь.

Кажется, каждый день меня спрашивают, почему я пишу на Perl, а не на PHP, Java, C#, Ruby, Python, или [вставьте ваш любимый язык здесь]. Люди говорят «Perl больше не используется, не так ли?» Сейчас, когда я пишу это, есть миллионы Perl программистов во всем мире. Perl5 активно поддерживается, и разрабатывается Perl6. Более 3000 модулей Perl было выпущено в 2006, и более чем в 2 раза, должны быть выпущены в этом году. Действительность состоит в том, что Perl совсем не умер.

Не могу не начать с этого вопроса: действительно ли исходный код ядра Линукса нарушает какие-либо патенты компании Майкрософт?

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

По словам Марка Шаттлворта (Mark Shuttleworth), наиболее важной особенностью дистрибутивов Линукса является их бесплатность. Он говорил, что эта система погибнет, если весь мир перестанет покупать запакованную в подарочную упаковку Виндоуз и начнет покупать запакованный в точно такую же упаковку Линукс. Как вы можете прокомментировать данное высказывание?

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

Возможно, «sucks» это слишком грубое слово, но по аналогии с
«Why C sucks»
и
«Why C++ sucks»
это, вероятно, подходящий заголовок.

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

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

Итак, вот мой список проблем в Perl:

Наличие хорошего инструментария критично для веб-разработчика когда речь идет о высокой производительности. Дополнения к Firefox могут здорово помочь при верстке HTML, валидации, редактировании стилей CSS, отладке JavaScript и прочей рутине. Поэтому я подумал что было бы неплохо сформировать список наилучших расширений Firefox на которых я остановился. Вот десятка тех, которые экономят мое время и спасают ежедневно.

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

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