Статья является вольным переводом информации предоставленной на официальном сайте.

Введение

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

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

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

Чуточку ликбеза. Навеяно предшествующими копипастами разной чепухи на данную тему. Уж простите, носинг персонал.

IP-адрес (v4) состоит из 32-бит. Любой уважающий себя админ, да и вообще айтишник (про сетевых инженеров молчу) должен уметь, будучи разбуженным среди ночи или находясь в состоянии сильного алкогольного опьянения, правильно отвечать на вопрос «из скольки бит состоит IP-адрес». Желательно вообще-то и про IPv6 тоже: 128 бит.

Обстоятельство первое. Всего теоретически IPv4-адресов может быть:
2³² = 2¹⁰*2¹⁰*2¹⁰*2² = 1024*1024*1024*4 ≈ 1000*1000*1000*4 = 4 млрд.
Ниже мы увидим, что довольно много из них «съедается» под всякую фигню.

Записывают IPv4-адрес, думаю, все знают, как. Четыре октета (то же, что байта, но если вы хотите блеснуть, то говорите «октет» — сразу сойдете за своего) в десятичном представлении без начальных нулей, разделенные точками: «192.168.11.10».

В заголовке IP-пакета есть поля source IP и destination IP: адреса источника (кто посылает) и назначения (кому). Как на почтовом конверте. Внутри пакетов у IP-адресов нет никаких масок. Разделителей между октетами тоже нет. Просто 32-бита на адрес назначения и еще 32 на адрес источника.

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

Основные возможности

Классы

Классы и интерфейсы представляют из себя простой и понятный механизм для создания всевозможных АПИ. Эти конструкции добавляют инкапсуляцию и повторное использование методов и данных.

Опциональные типы

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

Библиотеки

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

Инструменты

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

Сейчас уже многие сайты не обходятся без JavaScript, и частенько приходится выключать NoScript для того чтобы, увидеть что же нам хотели показать. И вот я задался мыслью сделать легкий компактный фотоальбом на одной странице без JavaScript. Был использован лишь HTML и CSS.

Задача:
1 Большое изображение полностью занимает доступное пространство.
2 Миниатюры также максимально заполняют его.
3 Никаких кликов мышью (но можно и так) и прокручивания для просмотра следующего изображения (ну разве что если миниатюр больше чем на экран).
4 Просмотр с помощью клавиатуры и мыши.
5 Без скриптов.
6 С сохранением обратной совместимости.

Итак, у вас есть чистая Ubuntu, в консоли открыто ssh-соединение с сервером и консоль вас заманчиво приглашает — «root@my-awesome-host:~#» — и больше ничего нет. А хочется запустить и показать всему миру какое-то рельсовое приложение. Поехали от супа до орехов.

В далеком 2007 году, когда Ukrnames был еще маленьким и делал первые шаги, большую часть работы выполняли программисты. Они и разрабатывали систему управления доменами, и тестировали ее, и администрировали сервера, где все это добро работало.

А там где домены, там DNS. А какой самый простой способ сделать DNS-сервер? Поставить вездесущий BIND. Да BIND непростой, а с DLZ патчем, чтобы с MySQL дружил.

Шли годы, система работала, мощности серверов росли. А как водится, пока работает – не трогай. Так бы это все и продолжалось, если бы нагрузка не начала упираться в очередной 8-ми ядерный сервер.

В этот момент пришлось принять волевое решение и построить новую систему DNS-серверов, вместо того чтобы в очередной раз апгрейдить железо для ненасытного BIND+DLZ.

И тут закончилась сказка, и начались суровые будни администратора.

Перевод главы «Multithreading» книги David Thomas и Andrew Hunt «Programming Ruby: The Pragmatic Programmers' Guide, Second Edition».

Часто самым простым способом выполнить одновременно две вещи является использование потоков в Ruby. Они являются внутрипроцессными, встроенными в интерпретатор Ruby. Это делает потоки Ruby полностью переносимыми, т.е. независимыми от операционной системы. Но в то же время вы точно не получите выгоду от использования родных, нативных потоков. Что это значит?

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

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

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

Предыстория

Все началось с того, что год назад мы задумались о повышении надежности нашей системы и для общего процесса оптимизации потребовалось, чтобы наш DNS хостинг поддерживал достаточно низкий TTL, скажем 5 минут. К сожалению, ResellerClub, где зарегистрированы наши домены и держится DNS зона, не дает такой возможности. В поисках альтернативы стало понятно, что с помощью системы доменных имен можно не только балансировать трафик между серверами, но и, например, фильтровать его во время DDoS-атаки. В прошлом году мы провели анализ предложений и даже опубликовали результат наших исследований и проверок на Хабре.

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

Анализ

К разработке проекта мы подошли серьезно и начали с более детального анализа конкуренции. Основная масса предложений сводилась к пакету (1 домен + до 100 записей + до миллиона запросов) за 1-3 доллара в месяц. С технической стороны в большинстве вариантов предлагается поддержка популярных типов записей, обычный Round-robin, минимальный TTL в районе 1-5 минут. Количество серверов, обслуживающих конкурентные платформы, варьируется от 1 до 15 (за исключением Route 53 от Амазон).

Аналогичная услуга, но уже с поддержкой гео-таргетинга, продвинутой балансировкой, API и другими приятностями стоит уже намного дороже и, например у dyndns, начинается с 195 долларов. Посчитав себестоимость некоего пакета, мы пришли к выводу, что такой же набор услуг в пакете (1 домен + 100 записей + 1 миллионов запросов) мы можем предлагать всего за 2 доллара.

Как же свершить это чудо?

Думаю каждый кто работал с под-доменами в Rails 3 видел данный скринкаст.

Когда столкнулся с этим примером стояла задача сделать динамические поддомены + некоторые фиксированные. Динамические должны были соответствовать некоторому полю одной из моделей. Таким образом были выдвинуты условия для конечного решения:

• возможность указания фиксированного поддомена, либо группы поддоменов;
• возможность привязки к полю из модели ActiveRecord;
• удобный синтаксис для записи всего этого в routes.rb.

• Почему в трейсроуте после узла X идут звездочки?
• Сервис не работает, а трейсроут обрывается на узле X — значит проблема в узле X?
• Почему одинаковые трейсроуты с Windows и Unix показывают разные результаты?
• Почему трейсроут показывает большие задержки на определенном узле?
• Почему трейсроут показывает «серые» адреса при трассировке через интернет?
• Почему маршрутизатор отвечает на трейсроут не тем адресом, каким я хочу?
• Почему трейсроут показывает какие-то «не такие» доменные имена?
• Почему вообще вывод трейсроута отличается от интуитивно ожидаемого чаще, чем хотелось бы?

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

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

В данном посте я решил поделиться опытом разворачивания rails сервера на Amazon. Все предыдущие rails проекты я выкладывал на готовые сервера. Это были частные сервера, или широко известный сервис heroku. И единственные команды, которые я посылал серверу, были cap deploy и cap deploy:cold. Но в последнем проекте заказчик пожелал разместить сайт на своем амазоновском образе, поэтому пришлось погрузиться в тему более глубоко.

Это четвертая статья в серии «Введение в ОТП». Если вы только что присоединились к нам, рекомендую начать с первой части, в которой говорится о gen_server и закладывается фундамент нашей банковской системы. Если же вы способный ученик, можете взглянуть на готовые к настоящему моменту модули: eb_server.erl, eb_event_manager.erl, eb_withdrawal_handler.erl и eb_atm.erl.

Сценарий: Момент, который нам нравится в банках и банкоматах, заключается в том, что они всегда на том же месте. Используя банкомат, мы можем снять или положить деньги когда захотим, 24 часа в сутки. Или пойти в любое отделение банка, когда оно открыто, зная, что будем иметь полный доступ к нашим финансам. Чтобы гарантировать это, необходимо быть уверенным в том, что наша система автоматизации ErlyBank всегда остается рабочей: процессы должны быть запущены постоянно. ErlyBank поручил нам реализовать эту цель. Стопроцентный uptime! (Или настолько близкий, насколько мы сможем обеспечить)

Результат: Используя контролёр (supervisor) OTP, мы создадим процесс, чья обязанность — следить за запущенными процессами и удостовериться, что они активны.

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

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

Как это сделать

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

Прочитал пост про Kerning.js — небольшую js-библиотеку, можно даже сказать утилиту, для реализации чудес типографики на веб-страницах. И вспомнил, что пользовал не так давно нечто подобное — библиотеку Lettering.js.

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

Итак, Lettering.js — помощник «радикального» веб-типографа, Cryptico.js — помощник Штирлица и Rasta.js — такой простой ajax get/set помощник. Далее ссылки на сайты разработчиков этих библиотек и инструкций по их использованию.

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

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

Ссылки на предыдущие части можно найти в конце статьи.

Это третья статья в серии «Введение в ОТП». Рекомендую начать с первой части, в которой говорится о gen_server и закладывается фундамент нашей банковской системы, если вы до сих пор не сделали этого. С другой стороны, если вы способный ученик, можете взглянуть на готовые модули eb_atm.erl и eb_server.erl.

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

Результат: Мы создадим систему уведомлений, основанную на событиях, используя gen_event. Это даст нам базовый фундамент для создания в будущем и других уведомлений, в то же время позволяя легко интегрироваться в текущее серверное ПО.

Постоянно меняющиеся требования и сжатые сроки подтолкнули нас к использованию ExtJS 4 для создания прототипа.

Проблемы в ExtJS, с которыми мы столкнулись при разработке, едва ли превысили опыт, который мы получили при препарировании ExtJS.

В интернете много статей про ExtJS 4 уровня basic. Например очень порадовала эта статья http://css.dzone.com/articles/how-use-extjs-4-jquery. А вот серьезных “не кассовых” статей по решению (или созданию) каких-то проблем с помощью ExtJS не много.

Предлагаю вашему внимаю первую статью в рамках ExtJS patch lab… Ну и немного о самой соц. сети… совсем немного.

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

$ netstat -an | grep -c EST
1016313

Бэкенд WhatsApp работает на FreeBSD + Erlang. Они не первые, кто добился миллиона одновременных tcp-сессий на одном сервере.

По работе пришлось в течение некоторого времени разбираться с СУБД IBM DB2. Т.к. система коммерческая, то в интернете не так много информации на русском языке, поэтому решил описать некоторые особенности работы этой СУБД.