Благодаря нововведениям HTML5 создавать Drag and Drop интерфейсы стало гораздо проще. К сожалению, эти нововведения еще не обладают обширной поддержкой браузеров, но надеюсь в скором времени это изменится (на данный момент работает в Firefox 4+, Chrome и Opera 11.10).

А давайте сегодня взглянем на PHP немного с другой точки зрения, и напишем к нему расширение. Так как на эту тему уже были публикации на Хабре (здесь и здесь), то не будем углубляться в причины того, для чего это может оказаться полезным и для чего может быть использовано на практике. Эта статья расскажет, как собирать простые расширения под Windows с использованием Visual C++ и под Debian с использованием GCC. Также я постараюсь немного осветить работу с PHP-массивами внутри расширений и провести сравнение производительности алгоритма, написанного на native PHP и использующего код, написанный на C.

Всем доброго времени суток!

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

Дерево ван Эмде Боаса (van Emde Boas tree) — ассоциативный массив, который позволяет хранить целые числа в диапазоне [0; U), где U = 2^k, проще говоря, числа, состоящие не более чем из k бит. Казалось бы, зачем нужно еще какое-то дерево, да еще позволяющее хранить только целые числа, когда существует множество различных сбалансриованных двоичных деревьев поиска, позволяющих выполнять операции вставки, удаления и прочие за O(log n), где n — количество элементов в дереве?

Главная особенность этой структуры — выполнение всех операций за время O(log(log(U))) независимо от количества хранящихся в ней элементов.

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

Когда в изучении языка доходишь до нетривиальных вещей, бывает полезно сместить уровень абстракции, чтобы понять, как на самом деле всё устроено. Ведь, по большому счету, любые конструкции языков сколь угодно высокого уровня сводятся к старому доброму машинному коду. Писать в объектно-ориентированном или функциональном стиле можно и на чистом C, и даже на ассемблере. Грубо говоря, любой высокоуровневый язык — это зафиксированный на уровне компилятора или интерпретатора набор синтаксических карамелек и шоколадок. Повышение уровня абстракции позволяет писать более сложные программы с меньшими усилиями, но вот понять в начале пути, что конкретно имеется в виду под наследованием или замыканием, как это всё работает и почему, гораздо легче, разобравшись, каким образом всё это реализовано.

JavaScript, как никакой другой язык, нуждается в именно таком объяснении. Функциональная природа, скрытая за Си-подобным синтаксисом, и непривычная прототипная модель наследования поначалу сильно сбивают с толку. Давайте мысленно понизим уровень JavaScript до простого процедурного, наподобие Си. Отталкиваясь от этого «недоязыка», переизобретем функциональное и объектно-ориентированное программирование.

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

На Хабре уже есть несколько статей\переводов, в которых рассказывается о неизвестных фичах\тонкостях\возможностях Пайтона. Я буду пытаться не повторять их, а дополнять, но если уж так случилось, что вы это уже где-то видели — не огорчайтесь. Я уверен, что найдется что-то интересное и для вас.

Что же такое Sugar?
Это javascript-библиотека для работы со встроенными объектами javascript, которая:

• расширяет встроенные объекты языка, добавляя полезные и интуитивно-понятные методы;
• добавляет кросс-браузерную функциональность, где она сломана или ее нет;
• полностью покрыта тестами;
• легко взаимодействует с другими фреймоворками и сторонним кодом;
• проста в понимании и использовании

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

getLatestTweets(function(t) {
    var users = t.map('user').unique();
    var total = users.sum('statuses_count').format();
    var top = users.max('followers_count').first();
    var count = top.followers_count.format();
    var since = Date.create(top.created_at);
    return users.length + ' users with a total of ' + total + ' tweets.\n' +
    top.screen_name + ' is the top with ' + count + ' followers\n' +
    'and started tweeting ' + since.relative() + '.';
});


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

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

— Чем же он удивительный? Я знаю пару десятков языков и для меня не проблема изучить еще один новый, я просто уже не вижу необходимости.

Пролог — уникален. Это единственный язык представляющий парадигму декларативного программирования; это язык, который имеет сотни различных имплементаций, но они все равно называются Prolog, добавляя лишь префиксы и суффиксы к названию; это живой язык в котором не происходит никаких существенных изменений более 20 лет; это, наверное, единственный настолько популярный язык программирования, который не имеет применения в реальном программировании. Почему же Prolog?

Пролог — уникален по своей природе, он появился благодаря счастливому совпадению (таинственному устройству мира). Когда-то в 60-х годах очень бурно развивалась теория автоматического доказательства теорем и Робинсоном был предложен алгоритм резолюций, который позволял доказать любую верную теорему (вывести из аксиом) за конечное время (за какое не известно). Как оказалось позже, это наилучшее решение общей задачи, невозможно доказать теорему за ограниченное число операций. Простыми словами, алгоритм представляет собой обход (в общем случае бесконечного) графа в ширину, естественно, что предсказуемость работы алгоритма практически равно 0, соответственно для Языка Программирования — это абсолютно не подходит. И в этот момент Кальмэроу нашел блестящее сужение задачи, благодаря которому доказательство некоторых теорем выглядело как процедурное исполнение программы. Стоит отметить, что класс доказуемых теорем достаточно широк и очень хорошо применим для класса программируемых задач. Вот так в 1972 появился Prolog.

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

Некоторое время назад я увлекался созданием оконной библиотеки под Windows на C++. И сегодня я расскажу как написать простую обертку над WinAPI для создания оконных приложений.

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

Прошлым летом совершенно неожиданно для себя я приобрел смартфон Nexus One. Своей покупкой был страшно доволен и подолгу ковырялся в его софтовой начинке, восхищаясь продуманностью системы. Поскольку я уже давно являюсь разработчиком игр, захотелось смастерить что-то свое и для этого устройства. После достаточно плотного изучения платформы, чтения специальной литературы, появились и первые ласточки в виде различных украшательств экрана. Надо заметить, что несмотря на то, что я с java никогда серьезно не работал, язык показался легко осваиваемым и интуитивно понятным. Очень сильно помогла и документация от Гугла. Все это в совокупности вселяло надежды на успешную разработку первого серьезного проекта, дизайн которого уже начал складываться с первых шагов изучения Android. Энтузиазма добавил и тот факт, что после пробного выкладывания приложения с живыми обоями на маркет за первые сутки его скачало почти тысяча пользователей. В голове завертелись мысли о коммерческих проектах и «легкой наживе».

Это была лирично-оптимистичная преамбула, а теперь перейдем к реальной действительности.

Многим программистам знакомы концепции пар и кортежей (pair и tuple) — их реализации есть в STL, Boost (и может быть где-нибудь еще). Для тех, кто не знает, что это такое, я коротко поясню — это шаблоны, позволяющие сгруппировать несколько значений (пара — только 2, tuple — много) с целью хранить\передавать\принимать их вместе.
Пример из MSDN:

   pair <int, double> p1 ( 10, 1.1e-2 );
   pair <int, double> p2 = make_pair ( 10, 2.22e-1 );
   cout << "The pair p1 is: ( " << p1.first << ", " << p1.second << " )." << endl;
   cout << "The pair p2 is: ( " << p2.first << ", " << p2.second << " )." << endl;
 

Поначалу идея кажется заманчивой, ведь:

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

Но есть и тёмная сторона этой силы.

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

На сегоднящний день известно множество сервисов, предоставляяющих доступ облачного хранения данных (наиболее популярный из них — dropbox). Почти во всех есть бесплатный аккаунт с ограниченным объёмом данных. В статье Прокачиваем DropBox в режиме «Full auto» рассказывалось как можно увеличить объём вашего dropbox аккаунт а на 8 Гб не тратя при этом никаких усилий.
Однако в данной статье пойдёт речь о получении «неограничнного» объёма в облаке, используя сервисы на основе WebDAV.
Кому интересно – добро пожаловать!

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

Ведь если сверстано на таблицах, с пустыми gif'ами для отступов — результат «монолитный», но не дай бог такое редактировать контент-менеджеру. Моментально всё поедет, да и не умеют нормально визивиги работать с таким ужасом.

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

Производительные приложения

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

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

Более месяца назад в статье FAQ по JavaScript: задавайте вопросы был задан вопрос «Подскажите примеры хорошего подхода организации JS кода к сайту на достаточно высоком уровне. Как можно узнать подробнее практики реализации например gmail?».

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

Эта статья о том, как сделать крупное веб-приложение расширяемым и поддерживаемым: архитектура, подходы, правила.

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

1. Что это такое и зачем это нужно?

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

Программисты с Etsy.com поделились опытом, как им удалось эффективно решить задачу по пакетному ресайзингу фотографий с 1,5 МБ до 3 КБ (после смены дизайна оказалось, что старые превью-окошки не вписываются в новые шаблоны страниц). Задача не такая банальная, как кажется. Дело в том, что Etsy.com — крупный интернет-аукцион, и количество изображений различных товаров превышает 135 млн штук.

Ради шутки они прикинули, сколько займёт эта работа вручную в «Фотошопе». Если на каждую фотографию отдать по 40 секунд, то выходит 170 лет непрерывного труда. Затем они начали считать, можно ли отдать пакет в облако EC2 и во сколько это встанет. Посмотрев на получившуюся сумму, программисты решили поискать другой способ.

В итоге им удалось завершить обработку 135 млн фотографий всего за 9 дней, задействуя четыре 16-ядерных сервера. Средняя скорость обработки составила 180 изображений в секунду.