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

Load average может представлять собой непростой для понимания показатель производительности сервера. В этой статье мы попытаемся дать некоторое представление о том, что означают те величины, которые можно найти в выводе команды «top» и в других linux-командах. В статье, также объясняются параметры специфичные для виртуального хостинга, которые обычно не отображается в стандартном выводе команды top.

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

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

Теперь на Яндекс.Картах можно рассматривать самую северную территорию России — архипелаг Земля Франца-Иосифа. Например, исполинские ледники или живописные горы.

А меня зовут Ольга Паршина, и я специалист по съёмке сферических панорам компании neq4, партнёра Яндекса. В августе 2013 года я в составе научной экспедиции за 42 дня сделала панорамы 11 островов архипелага. В этом посте хочу рассказать вам о то, как выглядит летняя Арктика.




В экспедиции к Земле Франца-Иосифа я была среди тех немногих, кем двигал не научный интерес, а желание побывать на самом крайнем севере России. Остальные участники представляли Национальное географическое общество США, парк «Русская Арктика» и Русское географическое общество. Каждый из них — эксперт в своей области: одни изучали микробов, другие заведовали моржами, третьи отвечали за археологию и геологию. Чисто научное общество не первый раз пускается в Арктику, на этот раз в рамках проекта «Девственные моря».

26 июля 2013 года «Поларис» — наше круизное судно, построенное специально для плавания в арктических водах, — вышел из Мурманска и направился к ближайшему острову архипелага, Земле Александры.

Всем хорошо известен алгоритм преобразования массива байт в строку base64. Существует большое количество разновидностей данного алгоритма с различными алфавитами, с хвостовыми символами и без. Есть модификации алгоритма, в котором длина алфавита равна другим степеням двойки, например 32, 16. Однако существуют и более интересные модификации, в которых длина алфавита не кратна степени двойки, такими являются алгоритмы base85, base91. Однако мне не попадался алгоритм, в котором алфавит мог бы быть произвольным, в том числе большей длины, чем 256. Задача показалась мне интересной, и я решил ее реализовать.

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

EditorConfig это конфигурационный файл и набор расширений, к большому количеству редакторов кода и IDE (Далее просто IDE).

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

Файлы .editorconfig можно найти в таких проектах, как jQuery, Ruby, WordPress, и многих других.

Плагины доступны для большого количество IDE




Давайте разберемся, как это работает.

Всем программистам рано или поздно приходится передавать данные. Ни для кого не секрет, что библиотек сериализации в Java существует примерно >9000, а в C++ они вроде и есть, а вроде их и нет. К счастью для большинства, несколько лет назад появился Google Protobuf, который принёс достаточно удобный способ определять структуры данных и быстро завоевал всенародную любовь. Это была фактически первая, доступная широким массам библиотека, позволяющая гонять по сети готовые структуры данных, не связываясь при этом с чем-то вроде XML. На дворе был 2008 год.

Вернёмся немного назад. В 2006 году простой индийский программист (как бы подозрительно это ни звучало!) Анил Мадхавапедди, один из самых известных сейчас в мире OCaml-разработчиков и автор свежевышедшей книги Real World OCaml, защищал в Кембридже кандидатскую диссертацию. Именно о ней я сегодня вам и расскажу.

Анил сразу пошёл дальше, чем Google. Он сразу подумал, для чего люди обычно пересылают по сети какие-то формализованные структуры данных? Чтобы реализовать какой-то протокол. А что такое протокол? Это какой-то конечный автомат. А где мы можем взять хороший пример сложного, хорошо спроектированного и проверенного временем протокола? Да прямо в обычном сетевом стеке! Итак, были взяты набор сетевых структур данных и протоколов: Ethernet frame, IPv4, ICMP, TCP, UDP, SSH, DNS и DHCP и постановка задачи: большая часть этих протоколов (особенно SSH и DNS) реализуются, что называется «руками», а хочется, чтобы не было типичных для C переполнений буфера, все переходы совершались автоматически, это всё можно было верифицировать, и чтобы работало быстро, а не как обычно.

Поскольку никто не будет читать диссертацию, сразу скажу: это более чем удалось. По результатам работы были написаны референсные реализации DNS и SSH-сервера и произведено сравнение с BIND и OpenSSH. OCaml-реализации давали по сравнению с традиционными прирост производительности от незначительного, до почти двухкратного. Кроме того была найдена ошибка в RFC на SSH (рабочая группа была уведомлена и RFC исправлен). О том, что было сделано, и как с этим жить, читайте под катом.

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

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

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

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

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

На Хабре недавно проскочила ещё одна статья про вычисления на шаблонах C++ от HurrTheDurr. В комментариях к ней лично я увидел вызов:

> С каждым новым релизом количество способов нетривиально вывихнуть себе мозг при помощи С++ продолжает увеличиваться)
> > Особенно, если не менять подход к реализации игрового поля и продолжать пытаться все вычисления выполнять не над константами, а над типами.

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

Чуть раньше AveNat опубликовала введение в лямбда-исчисление в двух частях, так что вдохновение пришло мгновенно. Хотелось, чтобы можно было (образно) писать так:

#include <iostream>

#include <LC/kernel.h>
#include <LC/church_numerals.h>

int main()
{
    // Представление натуральных чисел в виде лямбда-абстракций
    typedef ChurchEncode<2> Two;    // 2 = λfx.f (f x)
    typedef ChurchEncode<3> Three;  // 3 = λfx.f (f (f x))

    // * = λab.λf.a (b f)
    typedef Lambda<'a', Lambda<'b', Lambda<'f',
                Apply<Var<'a'>, Apply<Var<'b'>, Var<'f'> > >
        > > > Multiply;

    // Вычисление (* 2 3)
    typedef Eval<Apply<Apply<Multiply, Two>, Three>> Output;

    // Переход обратно от лямбда-абстракций к натуральным числам
    typedef ChurchDecode<Output> Result;

    std::cout << Result::value;
}

А на выходе получать такое:

ilammy@ferocity ~ $ gcc cpp.cpp
ilammy@ferocity ~ $ ./a.out
6

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

Под катом находится очередное прокомментированное конструктивное доказательство Тьюринг-полноты шаблонов C++ в виде compile-time интерпретатора бестипового лямбда-исчисления (плюс печеньки в виде макросов и рекурсии).

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

Первая часть дала нам теоретическое представление о том, что есть лямбда-исчисление. В этой статье мы последуем неофициальной його-заповеди «Practice-practice-practice» и увидим его в действии.

Часто путают терминал и шелл. В тех же *nix есть шеллы (bash, csh, zsh, …) и терминалы (konsole/guake/yaquake/tilda и т.д. и т.п.) Для мира Windows общеизвестный терминал только один – стандартное консольное окошко, которое часто ошибочно называют «cmd.exe». И мало кто знает о существовании множества других эмуляторов терминала. Известных шеллов больше, их целых два: cmd.exe и powershell.exe. И хотя есть как минимум три порта bash (MinGW, CygWin, GIT) многие юниксоиды предпочитают ругать cmd.exe.

Меня не устраивал ни один из найденных альтернативных терминалов (как в 2009-м, когда я начал работу над ConEmu, так и сейчас). Казалось бы требований немного, вот основные:

Это перевод статьи Analysis Paralysis: Over-thinking and Knowing Too Much to Just CODE Скотта Хансельмана за 30 марта.

Прочитал сегодня пост на ArsTechnica «Я знаю слишком много чтобы программировать быстро. Что мне делать?» — это обзор вот этого вопроса на StackOverflow:

Я стал замечать, что чем более опытным я становлюсь, тем больше времени у меня занимает выполнение проектов или задач. Я не теряю квалификацию от возраста, нет. Проблема в том, что я вижу слишком много способов чему-то сломаться. А количество потенциальных ошибок и просто нюансов, о которых мне известно, становится всё больше и больше.

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

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

Питон изумителен.

Удивительно, но это довольно неоднозначное заявление. Что я имею ввиду под “Питоном”? Может, абстрактный интерфейс Питона? Или CPython, распространенная реализация Питона (не путать с похожим по названию Cython)? Или я имею ввиду что-то совсем иное? Может, я косвенно ссылаюсь на Jython, или IronPython, или PyPy. Или может я отвлекся так сильно, что говорю о RPython или RubyPython (которые очень сильно отличаются).

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

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

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

Все начинается с понимания того, чем на самом деле является “Питон”.

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

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

Под катом попробуем разобраться чем отличаются «высокотехнологичные» компании от «низкотехнологичных», что нужно, чтобы высокотехнологичные компании могли рождаться и выживать, почему с софтом у нас лучше, чем с хардом, с чего начиналась кремниевая долина в США и можно ли её «скопировать», почему Китай всех рвет, а также — окинем взором все, что происходит в Сколково, Роснано, фонде перспективных исследований и приведут ли они к расцвету российских инноваций. Безусловно, я где-то могу ошибаться — буду рад дополнениям в комментариях.

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

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


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

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

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

Речь сегодня пойдёт о генерации изображений с картой расстояний (Signed Distance Field). Данный вид изображений примечателен тем, что фактически позволяет получить «векторную» графику на видеоускорителе, причём даром. Одной из первых данный метод растеризации предложила компания Valve в игре Team Fortress 2 для масштабируемых декалей в 2007 году, но до сих пор он не пользуется особой популярностью, хотя позволяет рендерить прекрасного качества шрифты, используя текстуру всего 256х256 точек. Данный метод прекрасно подходит для современных экранов высокой чёткости и позволяет серьёзно сэкономить на текстурах в играх, он не требователен к железу и прекрасно работает на смартфонах.



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

Как же создавать такие изображения? Очень просто, ImageMagick позволяет сделать это одной командой:

convert in.png -filter Jinc -resize 400% -threshold 30% \( +clone -negate -morphology Distance Euclidean -level 50%,-50% \) -morphology Distance Euclidean -compose Plus -composite -level 45%,55% -resize 25% out.png

На этом можно было бы поставить точку, но так полноценного топика не получится. Что ж, под катом — описание быстрого алгоритма расчёта SDF, пример на C++ и немного шейдеров для OpenGL.

Существуют три вида лжи: ложь, наглая ложь и статистика (источник)

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

Статистика, инфографика, big data, анализ данных и data science — этим сейчас кто только не занят. Все знают как правильно всем этим заниматься, осталось только кому-то написать как НЕ нужно этого делать. В данной статье мы именно этим и займемся.


Hazen Robert "Curve fitting". 1978, Science.

Структура статьи:

1. Введение
2. Предвзятая выборка (Sampling bias)
3. Правильно выбираем среднее (Well-chosen average)
4. И еще 10 неудачных экспериментов, про которые мы не написали
5. Играем со шкалой
6. Выбираем 100%
7. Скрываем нужные числа
8. Визуальная метафора
9. Пример качественной визуализации
10. Заключение и дальнейшее чтение

Жил да был у меня роутер одной хорошей фирмы на букву «Dead». Ну, это с ним, собственно, и случилось.
Посмотрел я на цены новых, на кучу компьютерного хлама в углу, на список подключений на домашнем компе… И понял, что не нужен мне роутер. Соберу свой, с нормальной маршрутизацией, DNS, WINS, i2p, блекджеком и так далее.

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

Технологии изменили человеческую физиологию, пишет 8banks. Они заставили нас думать по-другому, чувствовать по-другому, даже видеть сны по-другому. Они влияют на нашу память, внимание и циклы сна. Это связано с научным явлением, известным как нейропластичность — способности мозга изменять привычное поведение на основе нового опыта. В этом случае это интерактивные технологии и огромный объем информации поступающий из интернета.