Эта статья — частичный перевод одной интересной статьи с sqlite.org, в которой подробно рассматривается реализация транзакций в SQLite. На самом деле я очень редко работаю с SQLite, но тем не менее мне очень понравилось это чтиво. Поэтому если хотите просто развить кругозор — будет интересно почитать. Первые две секции не включены в перевод, так как там нет ничего интересного, да и мне лень их набивать (пост и так огромный).

3.0 Однофайловый коммит

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

3.1 Начальное состояние

Состояние системы, когда соединение с БД только что было поднято, поверхностно изображено на рисунке справа. Справа показана информация, которая хранится на энерго-независимом носителе. Каждый прямоугольник — это сектор. Синий цвет говорит о том, что этот сектор содержит оригинальные данные. Посередине изображён дисковый кеш операционной системы. В самом начале нашего примера кеш холодный, это изображено белым цветом. На левой части рисунка — содержимое оперативной памяти процесса, который использует SQLite. Соединение с БД только что было открыто, и никакой информации прочитано не было.

Пару недель назад, Zeev Suraski, один из главных контрибьюторов PHP и по совместительству co-founder Zend, предложил включить в ядро PHP Zend Optimizer+.
Zend Optimizer+ это, так же как и Apc, кешер опкодов. Но, в отличии от Apc, он также неплохо умеет применять стандартные паттерны оптимизации кода.
Помимо этого, оптимайзер дает одну хорошую плюшку — его разработку поддерживает коммерческая организация, например стабильная поддержка трейтов в нем появилась почти одновременно с релизом PHP 5.4, в то время как APC нужно было ждать около полугода. В данный момент он уже поддерживает PHP 5.5.

Одним из самых больших нововведений в PHP 5.5 будет поддержка генераторов и корутин (сопрограмм). Генераторы уже достаточно были освещены в документации и в нескольких других постах (например в этом или в этом). Сопрограммы же получили очень мало внимания. Это гораздо более мощный, но и более сложный для понимания и объяснения, инструмент.

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

Генераторы

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

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

Что такое массивы на уровне PHP?

На уровне PHP, массив — это упорядоченный список скрещенный с мэпом. Грубо говоря, PHP смешивает эти два понятия, в итоге получается, с одной стороны, очень гибкая структура данных, с другой стороны, возможно, не самая оптимальная, точнее, как выразился Anthony Ferrara:

PHP arrays are a great one-size-fits-all data structure. But like all one-size-fits-all <anything>, jack-of-all-trades usually means master of none.

Ссылка на письмо

(на картине изображен HashTable с Bucket-ами, В. Васнецов)

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

В этой статье я постараюсь раскрыть именно эти темы.

Abstract

Переменные в PHP выражены в виде неких контейнеров, которые хранят в себе тип переменной, значение, кол-во ссылающихся переменных на этот контейнер, и флаг — является ли эта переменная ссылочной.

Как-то я наткнулся на интересную тайм-ленту предполагаемых событий вселенной на википедии, но она была довольно скудной и без картинок, так что я залез в гугл и поискал «future time line», и первое, что увидел, — этот сайт. Мне очень понравилась эта статья и я решил перевести ее, заодно и вычитать ее получше.
Все, что здесь изложено — лишь предположения и теории, вполне возможно, что все или некоторые события будут не такими. Весь пост представлен в виде тайм-ленты от 10000 до 10¹⁰⁰ года, и содержит много интересных картинок и ссылок на вики, читать много и интересно.

---

10 000 – 15 000 Н.Э.

Гиперновая из звездной системы Эта Киля начинает воздействовать на наш регион Галактики

Эта Киля – одна из самых больших и нестабильных звезд в нашей Галактике. Ее температура настолько высока, что ее гравитация не в состоянии удерживать газ, утекающий с ее поверхности по сформированным потокам вверх, от нее. Она впервые была замечена в 1843 году, когда ее звездная величина (читай величина свечения) достигла -0.8, сделав ее второй по яркости звездой в ночном небе.
Она в дальнейшем утихла на какое-то время, и снова «засветила» в конце 1990-х. Эта флуктуация продолжается с периодичным вспыхиванием и затуханием, и будет продолжаться до тех пор, пока не случится неизбежное. Не в состоянии совладать с собственной массой и плотностью, она коллапсирует и, потом, превращается в одну из самых смертельных сил, известных в природе – в гиперновую.
На какое-то время, этот колоссальный взрыв освещает всю галактику. Это будет достаточно ярко, чтобы заметить в дневное время с Земли, в то время как ночью это сравнимо с полной луной.
Но гораздо больше вреда принесут убийственные струи гамма-излучения, выброшенные умирающей звездой. Они будут выброшены на таких высоких энергиях, что даже системы в тысячах световых лет от Эта Киля будут задеты. В результате, на многочисленных планетах в нашем регионе Галактики произойдет вымирание живых организмов в это время.

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

Этот пост — продолжение разбора алгоритмов сортировки (в прошлый раз был Hacker News). В этот раз, мы разберем как работает сортировка постов и комментариев на Reddit. Алгоритмы у Реддита достаточно простые, чтобы понять их и реализовать.

Первая часть этой записи будет сфокусирована на сортировке постов, а вторая на сортировке комментариев. Они довольно сильно различаются, и за идеей способа сортировки комментариев стоит Randall Munroe (автор xkcd).

Разбираем сортировку постов

Реддит open-source-ный проект и его код полностью доступен на гитхабе. Он написан на питоне, исходники вы можете увидеть тут. Их алгоритмы сортировки написаны под Pyrex, для дальнейшей компиляции (трансляции) в C-код. Pyrex был выбран из-за производительности. Я переписал их реализации на чистый питон, чтобы они легче читались.

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

А о чем собственно сабж?

Завтра (06.08), в 9:20 по МСК (неточное время), автономно-управляемый аппарат Nasa, названный Curiosity, будет совершать посадку на поверхности Марса.
Сажать аппарат так далеко от Земли сложно тем, что человек не может вмешаться в процесс, точнее может, но уже, скорее всего, будет поздно. От нас до Марса, радио-сигнал идет 14 минут.
Таким образом — правильно сесть на планету, с очень разряженной атмосферой и огромным слоем космической пыли на поверхности, очень не легко. Перед учеными стояла задача — спланировать эту посадку от начала и до конца, и вот как они ее решили:


(Здесь в хорошем качестве, но без субтитров.

Здравствуйте, в этой маленькой заметке расскажу немного про ООП в JS, объект XMLHttpRequest, паттерн прокси, и дружелюбие джаваскрипта в этом плане.

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

Эта статья с месяц висела у меня в черновиках, пока кто-то мне наконец не привел карму к тонусу. Не знаю кто, но спасибо тебе

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

Всем привет!
Наверно многие уже слышали про проект под названием HabraWars, если коротко — это игра для программеров, в которой вы сами пишите искусственный интеллект для собственного робота на JS.

Я думаю что это будет не первая моя статья на данную тему, хотя бы потому, что здесь я не собираюсь раскрывать всю тему, а лишь ее часть. Но сначала, я думаю, нужно сформировать некую концепцию робота… Сразу говорю, что в js я далеко не спец и вообще мои знания этого языка, на мой взгляд, довольно скудны… Итак, как-же должен выглядеть наш робот изнутри, а изнутри у него должна быть логика, как бы это очевидно не звучало, но логика это довольно сложная штука, она будет управлять роботом, задавая вопросы(типа: «Летит ли в меня(робота) снаряд») и основываясь на ответах вызывать функции, отвечающие за действия робота… Но начну я не с логики(я сам еще не начинал даже ее писать:)), а начну с функций, отвечающих за выполнение действий, порученных логикой.