(Проблема, по всей видимости, чрезвычайно экзотическая, но в плане «как оно внутри устроено» достаточно познавательная.)

Вот, допустим, работает у вас приложение, написанное на Эрланге (ну, скажем, тот же ejabberd). Давно работает, хорошо работает, но в один прекрасный день вы пытаетесь запустить управляющий скрипт (ejabberdctl, соответственно), а он вам выдает «nodedown» или еще что-нибудь страшное в этом духе, мол, не отзывается никто. При этом само приложение прекрасно отзывается на все клиентские запросы и слыхом не слыхивало о том, что оно down. По внезапному наитию вы запускаете epmd -names и — о, ужас! — получаете пустой список.

Программы на Эрланге используют для связи между собой нотацию node@host, физически же каждый узел (читай — системный процесс) открывает для этого случайный высокий порт. Задача сервиса epmd — связать между собой логическую адресацию по имени и физическую адресацию по номеру порта. Своего рода аналог DNS, с той разницей, что без реестра epmd кластер на Эрланге разваливается на кучку отдельных глухонемых узлов — что у нас только что по какой-то загадочной причине и произошло. Можно, конечно, начать искать виновных, но сначала все-таки неплохо бы поднять систему на место.

Что в такой ситуации делать? Можно, конечно, просто насильно перезапустить приложение, но, с одной стороны, клиенты отвалятся, с другой, такой красивый uptime жалко… Вот если б можно было как-нибудь восстановить реестр на живой системе, а?..

Идея использовать git для хранения всех своих фотографий.

Чего хотелось добиться?

1. Скидывать фотки одной кучей (DCIM), а когда будет время сортировать по папкам.
2. Скинуть фотки с одного компа, а работать с ними с другого.
3. Чтобы перемещение-переименование фоток и папок волшебным образом синхронизировалось на всех компьютерах.
4. Чтобы можно было редактировать фотки, но иметь возможность восстановить оригинал.
5. Чтобы сохранялась история правок.

Как оказалось, GIT с большим трудом справляется с этой задачей.

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

То, что мы сегодня создадим, корректнее будет назвать LKM (Linux Kernel Module или загрузочный модуль ядра). Стоит сказать, что драйвер – это одна из разновидностей LKM.

Писать модуль мы будем под ядра линейки 2.6. LKM для 2.6 отличается от 2.4. Я не буду останавливаться на различиях, ибо это не входит в рамки поста.

Мы создадим символьное устройство /dev/test, которое будет обрабатываться нашим модулем. Хочу сразу оговориться, что размещать символьное устройство не обязательно в каталоге /dev, просто это является частью «древнего магического ритуала».

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

Продолжение перевода здесь

В нашей сфере деятельности нам доступны огромные объёмы знаний, в особенности тех, которые позволяют разработчику стать эффективным. Но почему-то, несмотря на существование множества книг о специфических задачах и обязанностях менеджеров в нетехнических областях, я практически не вижу новых книг или статей о том, как стать хорошим ведущим разработчиком. Замечательным исключением, конечно, являются статьи Кейт Maцудайры [от переводчика: на фотографии, кстати, именно она], немало написавшей о культурных составляющих инженерии.

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

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

Помимо улучшения вашего приложения путем добавления в него всяких «завитушек», есть одна вещь, которую все хорошие разработчики должны сделать со своим кодом – обработать его утилитой Instruments!

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

Я замечательно провел время изучая Haskell в последние месяцы, и мне кажется, что сделать первые шаги в этом занятии сложнее, чем это могло бы быть на самом деле. Мне повезло работать в нужное время и в нужном месте, и в Facebook я прошел курс по Haskell от Bryan O'Sullivan, но Вы определенно сможете влиться в тему и без чужой помощи. Для этого можно поиграть в Haskell на сайте Try Haskell, а в конечном счете установить себе GHC.

Сегодня я хочу вам рассказать о создании игры для iOS на основе Cocos2D на примере недавно вышедшей игры «Пчелогонки» (анг. – Bee Race).
Геймплей не содержит в себе ничего сложного – это по сути бесконечный ранер, в котором нужно собирать поинты и уворачиваться от препятствий. Только вместо рыжей девочки или кладоискателя – здесь летает двухмерная пчелка.
Для заинтересовавшихся, прошу под кат (Ахтунг! Минен унд много буквирен).
Основные разделы для рассмотрения:

1. Очень краткое введение в Cocos2D
2. Используем Cocos2D одновременно с StoryBoard
3. Краткое описание геймплея и структуры проекта
4. Покупаем инструменты и что делать, если душит жаба
5. Чем не пахнет приложение или подключаем in-app билинг
6. Социализируем. Подключаем Game Center и создаем мультиплеерную версию на два игрока
7. В чём промахнулся Акела
8. Паблиш

Спойлер:

Riak это NoSQL решение, честная DHT (key/value storage) с дополнительными возможностями для разруливания конфликтов.

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

client a: def o-value = DHT.get("some-key");
client a: def a-value = changeValue(o-value);
client b: def o-value = DHT.get("some-key");
client a: DHT.put("some-key", a-value);
client b: def b-value = changeValue(o-value);
client b: DHT.put("some-key", b-value);

Получилось, что клиент b переписал данные клиента a и никто об этом не знает (ни a, ни b, ни тот, кто прочтет данные по этому ключу позже).

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

Например, MongoDB использует compare-and-swap стратегию: с каждым документом (значением) храниться его версия, при обновлении указывается версия «предка» измененного документа, если в базе в момент обновления храниться предок, то обновление проходит, если нет, то нет: обновляющая сторона получает сообщение, и пытается провести обновление снова — аналог STM. Такой подход хорошо работает с шардами, но плохо с репликацией.

Riak решает проблему конкурентного доступа подобно системам контроля версий, он, как бы, сохраняет конфликтные версии в разных бранчах, предоставляя программе при следующей выборке провести merge. Такой подход позволяет разрешать конфликты, связанные не только с конкурентным доступом, но и с времянной изолированостью части кластера (partition tolerance: кластер машин может распаться на две части, обе части будут работать и смогут без проблем объединиться в будущем).

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

Привет, Хабр!

Меня всегда интересовал геймдев. Несколько лет назад я сделал шаг и окунулся в этот мир. Меня поражал успех Энгри Бердс (Angry Birds), взлёт и падение Зинги (Zynga), и одна мысль мне не давала спать — «Как же они сделали такие классные игры?».

Прошло немало времени, накопился ящик опыта, в закромах образовались какие-то отрывочные записи и комментарии. Я решил все структурировать и систематизировать, стараясь ответить на один из краеугольных вопросов — «Почему же пользователь вернётся в игру?».

Vdev, или Virtual Device — это базовая единица, на которой строится массив данных ZFS (zpool). Для работы ZFS необходим как минимум один vdev — виртуальное устройство, которое позволяет случайный доступ к информации на уровне блоков.

Обычно, в качестве таких блоков используются целые диски или iScsi/FC LUNы (raw-disk vdev), но можно также использовать разделы дисков или файлы. Целые диски предпочтительнее, так как для них ZFS использует onboard write cache, в результате чего производительность записи может значительно улучшиться. Я пока не буду объяснять разницу между logical vdev и leaf vdev — это топик для отдельной статьи про то как работает RaidzN и zfs mirror.

src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/fs/zfs/vdev_disk.c#314

if (vd->vdev_wholedisk == 1) 
{
	int wce = 1;
	/*
	 * If we own the whole disk, try to enable disk write caching.
	 * We ignore errors because it's OK if we can't do it.
	 */
	(void) ldi_ioctl(dvd->vd_lh, DKIOCSETWCE, (intptr_t)&wce, FKIOCTL, kcred, NULL);
}

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

Каждый vdev разделен на логические разделы (metaslab),

Тот, кому доводилось иметь дело с выбором ORM для Scala, наверняка, наслышан о таких библиотеках, как Slick (Scala Query), Squeryl, Circumflex и пр., и, не менее вероятно, согласится со следующими утверждениями: они не абстрагируются от реляционных концепций, они требуют описания модели специфическими способами, API зачастую запутан и рассредоточен, и, наконец, то, насколько предложенные этими библиотеками абстракции в действительности упрощают работу с базой данных является, по меньшей мере, сомнительным.

Так и родилась идея создать фреймворк, который

1. возведёт абстракцию над базой данных до более высокого уровня, представляя её через стандартные типы данных Scala: примитивы, кортежи, опции, коллекции и тд., а так же стандартные кейс-классы, представляющие собой сущности,
2. выполняя первую задачу, будет «чистым», что означает полное исключение концепций реляционной стороны из API фреймворка: никаких таблиц, строк и реляционных связей,
3. возведёт в принцип основы функционального программирования: только немутируемые типы данных, сведение State к минимуму,
4. будет выполнять за пользователя всё, что он может, за счёт чего достигнет минимизации boilerplate.

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

Как устроены графические движки популярных игр с мировым именем? Какие технологии применяют разработчики в самых крупных игровых компаниях? Действительно ли, чтобы сделать красивую игровую графику необходимо применять самые передовые технологии современной 3D графики? На эти вопросы мы попробуем ответить на примере рендер части игры Diablo3, от компании Blizzard Entertainment.

В последнее время мои коллеги начинают знакомство с git'ом. И один из интересующих их вопросов — как откатиться до определённой ревизии. В интернете можно найти набор команд, но хочется, чтобы было понимание каждой из них. Баловство с комадами git'а без понимания может привести к потере истории разработки.

В этой статье я хочу рассказать о командах git checkout и git reset с ключами --soft и --hard.

Текстовый редактор — это основной инструмент для любого программиста, вот почему вопрос его выбора становится причиной яростных дебатов. Unix традиционно тесно связан с двумя своими многолетними фаворитами, Emacs и Vi, и их современными версиями GNU Emacs и Vim. Эти редакторы имеют очень разный подход к редактированию текста, но при этом сравнимы по мощи.

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

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

• Что есть информация?
• Как мозг представляет знания?
• Что такое язык?
• Какова роль языка в мышлении?
• Как совершаются поступки?
• Как осуществляется планирование?
• Какова природа фантазий и воспоминаний?
• Что такое мотивация?
• Какова природа эмоций?
• Откуда берется многообразие эмоциональных оценок?
• Что есть смысл?
• Как рождается мысль и какова ее природа?
• Что такое внимание?
• Что есть любовь?
• Что есть гармония и красота?

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

Erica Sadun, The iPhone Developer's CookBook

Дисклеймеры

• Приведенные здесь куски кода работают на обычных iPhone (включая 4S) и iPad (включая new iPad) и не требуют jailbreak.
• Все решения написаны и протестированы на iOS 5. Все решения также протестированы на совместимость с iOS 4.3, т.е. работают с iOS 4, если не сказано обратное. Основная часть статьи была написана до выхода iOS 6, так что приведенные решения не тестировались на совместимость с iOS 6.
• Использование недокументированных API может привести к тому, что ваше приложение не допустят в AppStore. А может и не привести :-)
  Для тех, кому интересно, как Apple опрделяет использование приваетных API:«Как Apple узнаёт, что ты используешь приватные API?»
  
• Apple может изменить реализацию вместе со следующим релизом iOS, и в вашем коде что-то сломается. Впрочем, это решаемо, и ничем принципиально не отличается от реализации обратной совместимости для документированных API. Ниже я рассмотрел эту проблему чуть подробнее.
• Я не могу гарантировать, что у найденных мной API нет побочных эффектов. Используйте на свой страх и риск.
• Лицензионное соглашение Apple Developer Program запрещает реверс-инжинеринг iOS.
• Статья в процессе доработки. Конструктивная критика приветствуется!

Краткая инструкция по поиску в SDK

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

Кирпичёв правильно пишет про небрежность интуитивного понимания императивных языков: http://antilamer.livejournal.com/300607.html.

Однако, мне кажется, что важно было бы озвучить, что всё то, что сейчас скрывается под именем «монада» — само по себе достаточно спутанно в плане педагогики и евангелизма.  Классическая шутка SPJ/Вадлера звучит как «нам следовало назвать ЭТО warm fuzzy things, чтобы не пугать людей теоркатом».  Шутка поразительно недальновидная.   Проблема лежит в той же плоскости, что и называние стоящих перед тобой задач словом «stuff» (это то, с чем борется Аллен в своём GTD).  
Монады в настоящий момент являются миру как сложный ком из исторически обусловленных причин, проблем, решений, технических возможностей и теоретических основ (как алгебраических, так и аспектов теории вычислений). 
Все эти наслоения можно (и нужно) расщепить в первом приближении так (порядок приблизительно случайный):

• стремление к экспликации эффектов (чистое внедрение императивно-подобных моментов в вычисление), (см. труды Вадлера);  здесь мы включаем ввод-вывод, STM, параллельные вычисления и проч.)
• удобный механизм для материализации базовых микро-стратегий вычисления — вызов функции (call-by-name/call-by-value), многозначность, смена состояния (присваивания!), обработка исключений, останов при неудаче, continuations, бэктрекинг;

• typeclasses как механизм внесения монад в язык, и как следствие — удобный механизм для мета-перехвата вычисления (невероятно удобно для domain-specific embedded languages);
• строгая проверка типов, проистекающая из использования typeclasses, и позволяющая механически проверять корректность использования объектов;
• существование монадических законов, в которые укладываются монады, что позволяет материализовывать абстрактные комбинаторы; это позволяет находить порой неожиданные изоморфизмы между различными предметными областями, а также помогает при оптимизации и верификации программ;
• проработанная теоретическая основа (теория категорий), на которой базируются монады; это облегчает жизнь создателям базовых библиотек, на которых потом базируется всё реальное программирование;
• монады — лишь один из классов в длинной цепочке интересных алгебраически обусловленных классов, некоторые из которых слабее монад, а некоторые — сильнее: Functor, Applicative, Monoid, Traversable, Foldable, Monad со товарищи, Arrow со товарищи;
• стремление к материализации некоторых видов вычислений в алгебраическую структуру (моноидальные вычисления); это открывает широкий простор для оптимизаций, верификации программ, создания абстрактных комбинаторов, а также устранение unbounded recursion — по мощности результатов это похоже на то, как когда-то ввод-вывод был надежно изолирован в IO Monad;

Потратим по паре абзацев на каждый пункт.

Приветствую.

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

Не так давно, в команду пришлось приглашать нового программиста и знакомить его с Erlang. Для ускорения процесса обучения я решил перевести уже давно лежавший у меня материал Erlang Programming Rules and Conventions. Чем в принципе и хочу поделиться с хабровчанами. Надеюсь что он будет полезен тем, кто собирается изучать или уже использует этот замечательный язык. Сразу скажу, что перевод вольный, так что не критикуйте сильно.

Недавно на хабре появилась неплохая статья про вычисление N-ного числа фибоначи за O(log N) арифметических операций. Разумный вопрос, всплывший в комментариях, был: «зачем это может пригодиться на практике». Само по себе вычисление N-ого числа фибоначи может и не очень интересно, однако подход с матрицами, использованный в статье, на практике может применяться для гораздо более широкого круга задач.

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

loop 1000000000
  loop 1000000000
    loop 1000000000
      a += 1
      b += a
    end
  end
end
end

Незамедлительно выведет a = 1000000000000000000000000000, b = 500000000000000000000000000500000000000000000000000000, несмотря на то, что если бы программа выполнялась наивно, интерпретатору необходимо было бы выполнить октиллион операций.