Готовясь к конференции DevCon'12 и, помня о Тостере по JavaScript, который проходил буквально на следующий день, мы решили, что было бы очень здорово сделать что-то полезное информационное для веб-разработчиков.

Как результат, родился плакат по современным веб-стандартам, вернее, как это принято в мире веб-разработки, черновик плаката, в который мы включили, как нововведения в самой спецификации HTML5:

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

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

Сначала разберемся с определениями. Под обновлением на лету мы подразумеваем такое обновление системы, при котором не нарушается штатная ее работа: клиенты работают, посетители ходят и никто не наблюдает ошибок, увеличившегося времени отклика или таблички “УЧЁТ”.

Зачем это нужно? Если вы задаетесь этим вопросом — вам не нужно. Вешайте табличку, садитесь обедать.

Как это делается? Сложно. Почему? Главных причин две:
— вы не можете обновить систему мгновенно и атомарно (то есть ровно между двумя HTTP запросами). При наивном подходе пользователи заметят как минимум долгое время отклика, а то и ошибку, если, к примеру, БД обновлена, а код еще нет;
— состояние и конфигурация системы существуют и на клиенте и на сервере. Примеры: данные в сессии, имена полей формы, адреса в ссылках, состояние в javascript на открытой у пользователя странице.

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

Если коротко

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

Официальный сайт
Руководство для новичков
На гитхабе

Примечание переводчика: данный пост является логическим развитием, а точнее «предысторией» поста Вникаем в include и extend и был подсказан в комментариях к нему пользователем murr, за что ему большое спасибо.

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

Если классы — это объекты, то у них должен быть свой собственный класс. Классом всех классов (как объектов) в Ruby является класс Class:

# один из способов создать новый класс
Dog = Class.new
    
# общепринятый способ создания класса
class Dog
    # какая-то реализация собачьего поведения
end

Dog.class
=> Class

Привет, Хабр. Меня зовут Александр. И я хочу поделится своей историей работы над одним крупным и сложным проектом.

В этой статье не будет кода и схем, в ней будет только история создания «от и до» самого проекта. Думаю, многим будет интересна данная статья. Итак, поехали!

Начало

Все началось летом 2011. На тот момент я был 3 года чистокровным фрилансером. То есть моя работа — это фриланс. Работал и работаю до сих пор только с западными заказчиками. Основная специализация — разработка проектов связанных с распознаванием образов, текста и т.д.

Все началось с того, что я, как всегда, с утра проверял почту, чистил спам, занимался рутинной работой. Обычно я не смотрю, что у меня в спаме, но тут я увидел письмо, с вполне реального адреса. Я открыл письмо, в котором одна компания искала программиста для допиливания крупного западного проекта. Причем эта компания требовала программиста именно из моего города и обязательно с опытом работы в области распознавания. Я ради любопытства ответил на это письмо. Буквально через час мне пришел ответ. А через два мы уже созвонились с менеджером проекта. Поначалу мне показалось, что ничего сложного в доработке нет, обычный набор функционала. После непродолжительного разговора с менеджером я огласил свой прайс, то есть ставку в час. И на этом мы попрощались. На следующий день мне сказали, что согласны на мой ценник и дали тестовое задание. Я его успешно выполнил в течении часа, и мы двинулись дальше. А здесь начинается самое интересное. Во-первых, меня пригласили в офис для того, чтобы подписать договор о неразглашении (Non-Disclosure Agreement). Во-вторых, и это логично, исходники проекта мне обещали отдать только после подписания договора. Если честно, меня это смутило, не знаю даже почему. И интуиция меня не подвела. Я потребовал хотя бы часть исходного кода, чтобы оценить сложность работы и попросил рассказать подробнее о проекте. Как оказалось проект на тот момент велся уже три года и я был 4 (!) исполнителем. До меня работала американская компания, потом индусы, потом компания, которая наняла меня, пыталась реализовать проект силами одной девочки-программиста, а потом это все чудо предложили разгребать мне. Меня это не просто удивило, а очень насторожило. Потом я узнал множество удивительных вещей, например о том, что заказчик 2 года не видел программу, а видел только скриншоты, а индусы кормили обещаниями этого заказчика. У меня не укладывалось в голове, как такое можно реализовать. Менеджеру индусов надо дать медаль «За находчивость».

После того как я выслушал удивительную историю, мы договорились с менеджером о том, что он мне отдаст исходный код и я оценю масштаб трагедии. Чтобы было более понятно, я расскажу более подробно о проекте. Этот проект — это инструмент для инженеров, архитекторов, электриков и других людей, которые занимаются строительством домов, небоскребов, одним словом зданий. Он служит для подсчета различных элементов на строительных планах, расчета площадей, измерения длин и составления смет. Грубо говоря есть строительный план и на нем есть розетки. Нам надо распознать и посчитать сколько этих розеток. Для распознавания использовалась библиотека написанная другим программистом. Сам проект написан на C#. Моя задача была собрать все воедино и доработать дополнительный функционал, а также привести программу к более менее стабильному состоянию. Кажется все просто и элементарно. Я тоже так подумал. Но не тут-то было.

После того как я получил исходники, я попытался скомпилировать проект. Это мне не удалось. После краткого анализа, я исправил ошибки и все же запустил проект. Но, к сожалению, он не заработал так как нужно. После нескольких часов анализа кода я пришел к выводу, что вся проблема в библиотеке распознавания. На тот момент у меня стояла 64-битная «семерка», а у менеджера 32-битная. У него все работало, у меня нет. Я попросил, что бы мне скомпилировали библиотеку под 64-битную платформу. Но разработчик библиотеки с пеной у рта доказывал, что не в разрядности дело. Я не мог ему ничего доказать, так как он дал очень немного информации о своей библиотеке и вообще берег ее как зеницу ока. Время шло и мне надо было хотя бы полностью провести процесс поиска. Я плюнул на все и поставил себе 32-х битную версию ОС. И о чудо! Все заработало. Отвлекаясь, хочу сказать о библиотеке, в будущем дело все же оказалось в ее разрядности.

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

1. Компоненты и контролы.

Проект очень сильно связан с графикой, но для ее вывода и обработки использовался обычный PictureBox. Самый маленький размер плана — 5400x3600 пикселей. Знающие люди поймут, что для PictureBox -это достаточно проблематичная тема с выводом больших картинок и их обработкой. Не стоит забывать, что помимо самих планов выводится еще много информации (площади, текст, найденные символы и т.д.). При запуске проекта с 5 маленькими планами, программа непременно падала с ошибкой «Out of memory». Что было очень большой проблемой, так как основной задумкой было то, что инструмент должен был работать по принципу «запустил и забыл».

2. Логика архитектуры исходного кода программы.

После публикации предыдущей статьи про SELinux поступило много предложений «на практике доказать полезность» этой подсистемы безопасности. Мы решили произвести тестирование. Для этого мы создали три уязвимых стенда с типовыми конфигурациями (Damn Vulnerable Web Application на CentOS 5.8). Отличия между ними были лишь в настройках SELinux: на первой виртуальной машине он был отключен, на двух других были применены политики «из коробки» — targeted и strict.

В таком составе стенд виртуальных машин подвергся тестированию на проникновение. Взглянем на результаты?

Недавно вышла книга The dRuby book — distributed and parallel computing with Ruby (перевод японской книги, написанной автором самой библиотеки). В этой статье я попытаюсь дать обзор глав книги, касающихся библиотеки DRb. Если вам захочется ознакомиться с темой более подробно, книгу можно купить или скачать. Сразу скажу, что я не буду говорить в этом посте ни о синхронизации потоков, ни о библиотеке Rinda.

Предположим, что вы пишите систему, которая работает с более чем одним процессом. Например, у вас есть веб-сервер, который в фоновом режиме запускает задачи, работающие долгое время. Или вам просто нужно обеспечить пересылку данных из одного процесса в другой и координировать их. Для таких ситуаций и нужна библиотека DRb. Она написана целиком на Ruby и включена в стандартную библиотеку, поэтому начать работать с ней можно моментально. Для её подключения достаточно написать require 'drb'

Достоинства библиотеки DRb большей частью проистекают из динамичности самого языка Ruby.
Во-первых, при затрате минимальных усилий на подготовительном этапе, дальше вы работаете с объектами не задумываясь, где они расположены: в одном процессе или в другом. Библиотека полностью маскирует от вас все технические детали.
Во-вторых, вы не обязаны жестко прописывать интерфейс. Любой руби-объект может выставить свой интерфейс наружу — таким образом вы можете как воспользоваться функциональностью одного из стандартных классов типа Hash или Queue, а можете сделать свой класс с любым интерфейсом. Кроме того вам ничто не мешает менять интерфейс прямо в процессе исполнения, и даже использовать method_missing для обработки любых запросов. И уж разумеется, обновление интерфейса сервера вообще никак не влияет на клиента, если тот не вызывает методы, которые изменили сигнатуру или поведение. Таким образом сервер и клиент максимально независимы.
И наконец, клиент даже не обязан знать классы объектов, которые ему возвращает сервер, он может их использовать и без этого. Таким образом сервер волен скрыть столько много деталей, сколько ему угодно.
Но, конечно, есть и подводные камни, и их предостаточно. К счастью, dRuby несложен в понимании, ну а понимание его устройства позволяет большей части проблем просто не допускать. Документация к этой библиотеке, к сожалению, не проясняет множества моментов, поэтому статья будет интересна и новичкам, и людям уже поработавшим с библиотекой.

Если вам приходилось настраивать Nginx под нужды веб-студии, сеошников или киберсквоттеров ;), то уже наверняка знаете про символ подчёркивания в качестве server_name. Тем не менее несколько других небесполезных приёмчиков из моего примера почерпнуть можно.

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

Конфиг делает следующее:
1. Отрезает «www» от адреса, дабы сервер нашел директорию с сайтом невзирая на эти буквы в URL.
2. Выдаёт отдельную страничку при запросе несуществующего сайта.
3. Делает стандартный редирект на index.php в корне сайта при запросе несуществующего пути.
4. Перенаправляет запрос на php-fpm при вызове .php файлов.
5. Добавляет возможность обработки .htm(l) файлов как PHP.

Согласитесь, каждый раз, когда вы видите человека, который использует Vim, вам кажется, что он знает то, чего не знаете вы. Иначе, как вы можете объяснить тот факт, что он использует редактор, который, по вашему мнению, является open-source мусором? Думайте, что хотите, но есть целый ряд причин, по которым програмисты поклоняются Vim.
Пока вы не потратите по крайней мере месяц на ознакомление с ним, вы, несомненно, будете его ненавидеть. Именно по этой причине большинство новичков работают с Vim около дня, после чего больше никогда к нему не притрагиваются. Они даже представить себе не могут, какой невероятной скоростью и гибкостью он обладает. Нужно всего-лишь найти в себе силы и преодолеть те трудности, которые встретятся вам на протяжении всего того времени, что вы знакомитесь с Vim.

Resque — ruby-библиотека для создания фоновых задач, составления очередей таких задач и их последующего выполнения. Задачи могут быть любым ruby-классом или модулем, содержащим метод perform. В ruby-сообществе Resque пришел на смену Delayed Job (не знаю, кстати, почему проект перестал развиваться, весьма удобная была вещь на мой взгляд) и обладает большим количеством различных преимуществ, таких как разделение задач по разным машинам, приоритеты задач, устойчивость к разным утечкам памяти и еще, и еще, и еще. На этом вступление для тех, кто не может самостоятельно перевести первый абзац из README прошу считать законченным.

В данной статье будет показано как использовать resque и resque-scheduler в rails-приложении.

Mosh — замена(или дополнение) SSH. Он быстрее и отзывчивее, особенно на линках с высокой задержкой, например, в мобильных сетях. Набираете символ, и моментально видите его на экране, так же, как и в локальном терминале. Почему? Потому, что в Mosh реализован так называемый local line editing, который не дожидается ответа от сервера, а сразу все отображает на экране. Работает даже в полноэкранных приложениях, вроде vim или emacs. И это далеко не единственный плюс!

Мы начали наблюдать много экспериментов над CSS3 анимацией и статьи о ней в 2011-м, но тогда поддержка этой анимации была ограничена браузерами на вебките. В середине 2011-го Firefox 5 тоже получил эту поддержку, а также мы можем ожидать ее в следующей реинкарнации Internet Explorer (10), поэтому сейчас идеальное время, чтобы разобраться с синтаксисом @keyframes (покадровой анимации). Этот пост предлагает краткий обзор 10-ти статей, в которых объясняется, как использовать это клевое CSS3 свойство, с примерами и демками.

В процессе превращения большей части web-проектов в браузерные приложения, появляется много вопросов. И один из самых весомых из них – обработка прав доступа без лишнего кода. Размышления на эту тему привели нас к большой проблеме: комфортного способа реализовать защиту на уровне полей модели для ActiveRecord просто нет (Егор, привет! ;). CanCan добавляет ограничения на уровне контроллеров, но это слишком высокий уровень чтобы решить все проблемы.

Немножко пободавшись, мы написали два милых гема. Встречайте, Heimdallr (Хеймдаль) и его расширение Heimdallr::Resource. Они принесут в ваши модели мир и безопасность.

Envision.js библиотека для создания быстрых динамических и интерактивных визуализаций данных на HTML5.


Возможности:

1) Визуализация в реальном времени.
2) Временная шкала
3) Визуализация валют ( как на яндексе прям )
4) Поддержка Ajax в интерактиве.
5) Можно побаловаться фракталами.

Доброго времени суток, Хабровчане!

Сразу же извините меня за мой русский, так как мой родной язык украинский.

Я Ruby On Rails разработчик и много раз сталкивался с потребностью модальных окон в моих проектах. Перепробовал я много готовых таких как facebox, fancybox, диалоги с jQuery UI и тд.
На одном из моих последних проектов заказчик захотел добавить конфирм диалог перед удалением какого либо ресурса. Надо было выводить красивое диалоговое окно, а не джаваскриптовый алерт который дает нам rails ujs. Тогда в нас использовался facebox и мне пришлось лазить по всему проекту допиливать все это для фейсбокса. И тогда я решил написать что-то свое, но чисто для рельсов, так все выше упомянуты легко прикрутить куда угодно.
Основной фишкой гема стало то что стандартные рельсовские конфирмейшены можно заменить лишь прописав одну строчку в application.js файле. Добавил еще поддержку картинок чтобы не было необходимости ставить еще что-то если на проекте надо простая галерейка. Все занимает только 5kb. Работает во всех браузерах и в ie начиная с седьмой версии.

Выглядит вот так:

«Chicago Boss — бескомпромиссный веб-фреймворк, любимый дизайнерами, инженерами и этим парнем с пейджером.» — © chicagoboss.org

«Erlang — язык для создания отказоустойчивых распределенных приложений. Это — один из немногих функциональных языков, который давно и успешно применяется на практике. Например — в телекомах (Ericsson AXD-301 switch), банковских системах, системах автоматизации, высоконагруженных веб-приложениях (Facebook Chat). При этом Erlang — продукт с открытым исходным кодом и распространяется бесплатно.» — говорит нам сайт русскоязычного сообщества Erlang.

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

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

Здравствуйте, хабравчане-маководы!

Сегодня мы с вами попробуем разобраться в азах создания виджета для Dashboard в Mac OS X. Нам понадобится программа Dashcode, предназначенная как раз для этого.

Для начала немного теории. Виджет в Dashboard — это специально сформировання веб-страничка, упакованная в бандл вместе со всем ресурсами. Ну, и немного служебной информации в довесок. Соответственно, используемый язык программирования — JavaScript. Если Вы уже знакомы с ним, а так же с HTML/CSS (хотя это вряд ли понадобится), то Вы уже способны написать простенький виджет. Если же нет, то не стоит расстраиваться, этот язык очень прост и интуитивно понятен, разобраться с ним можно достаточно быстро. Далее я буду считать, что с JS читатель более-менее знаком. Сама же статья рассчитана на новичков, так что прошу не ругать за «слишком простое изложение и детальное разжёвывание элементарных вещей». Кроме того, за дизайн тоже прошу не пинать — ну не дизайнер я, не дизайнер! Если кто хочет помочь с этим делом — welcome =)

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

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

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

Лет 6 назад, в мою бытность сисадмином в одной конторе, мне приходилось обслуживать несколько серверов на FreeBSD — прокси, почтовик, web-сервер, ftp, ipfw, в общем, все как у всех. Работало все на двух физических серверах, и было у меня желание заиметь какую-нибудь универсальную графическую оболочку для удобства управления всем этим хозяйством. Ну и, конечно же, таковой нигде не было. Были попытки разных умельцев создать свои GUI для управления подсистемами по отдельности: один для squid, другой для sendmail и т. д. Конечно, можно было какую-то часть управления выполнять и в webmin, но это не доставляло никакого удовольствия. Как говорили мне — неправильно работать с *nix-системами через GUI. Нет, естественно работа в командной строке не доставляла неудобства, но хотелось чего-то более универсального. В итоге, я написал несколько скриптов, которые вызывали псевдографику на черном экране, где можно было добавлять/удалять правила, рулить пользователями и т. д., на чем как-то все остановилось, хотя интерес к удобству управления через GUI и не пропал.