Пятнадцать лет назад трудно было представить, что когда-нибудь HTTP, HTML, CSS и Javascript станут основными технологиями для доступа к информации и заменят целые классы десктопных приложений. Например, вот десять примеров того, что сложно было ожидать от веб-технологий в 2010 году, но они это делают.

1. Интерактивный рендеринг физики ткани


2. Распознавание объектов на видео в реальном времени

Оглавление (на данный момент)

Часть 1. Описание, операции, применения.
Часть 2. Ценная информация в дереве и множественные операции с ней.
Часть 3. Декартово дерево по неявному ключу.
To be continued...

Декартово дерево (cartesian tree, treap) — красивая и легко реализующаяся структура данных, которая с минимальными усилиями позволит вам производить многие скоростные операции над массивами ваших данных. Что характерно, на Хабрахабре единственное его упоминание я нашел в обзорном посте многоуважаемого winger, но тогда продолжение тому циклу так и не последовало. Обидно, кстати.

Я постараюсь покрыть все, что мне известно по теме — несмотря на то, что известно мне сравнительно не так уж много, материала вполне хватит поста на два, а то и на три. Все алгоритмы иллюстрируются исходниками на C# (а так как я любитель функционального программирования, то где-нибудь в послесловии речь зайдет и о F# — но это читать не обязательно :). Итак, приступим.

Введение

В качестве введения рекомендую прочесть пост про двоичные деревья поиска того же winger, поскольку без понимания того, что такое дерево, дерево поиска, а так же без знания оценок сложности алгоритма многое из материала данной статьи останется для вас китайской грамотой. Обидно, правда?

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

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

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

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

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

Биопринтинг- печать органов

В ближайшее время САН ДИЕГО собирается распрощаться с институтом донорства и очередями за донорскими органами.

tweet-button — gem/plugin для генерации новой Twitter кнопки.

Использование

Включите TweetButton в вашем application хелпере. После этого в любом шаблоне можно вызвать хелпер:

<%= tweet_button %>

Поддерживаются так же дополнительные параметры:

<%= tweet_button(:via => «peterc», :url => «hashtrain.com», :text => «AWESOME.») %>

Исходный код и документация доступны на Github: http://github.com/intridea/tweet-button

В данной статье я расскажу об одном из способов, позволяющих с наименьшими усилиями трансформировать программный код на C/C++ в код, написанный на C#. Впрочем, рассказанные принципы подойдут и для других пар языков. Хочу сразу оговориться, что способ не рассчитан на трансформацию кода, реализующего GUI.

Для чего это делать? К примеру, я таким образом портировал известную графическую библиотеку LibTiff (и LibJpeg заодно) на C#. Это позволило использовать наработки многих людей, создававших LibTiff, в моей программе вместе с библиотекой классов .NET Framework. Примеры кода в статье будут в основном из LibTiff и LibJpeg.

Pirobox — легкий и быстрый скрипт галереи на jQuery.

Автор скрипта итальянец Diego Valobra (http://www.diegovalobra.com), талантливый человек.
В сжатом виде скрипт весит всего 10Кб, есть несколько тем внешнего вида, слайдшоу, корректная работа с PNG, клавиатурная навигация, проверка состояния ссылок (битая/не битая), возможность открыть картинку в новом окне.

На данный момент последняя версия — 1.2.2.

Официальный сайт
Скачать
Demo

При разработке баз данных зачастую требуется обеспечить поддержку версионности и хранения истории объектов. Например, у работника может изменяться должность, у должности в свою очередь может меняться оклад — в многомерном моделировании это называется Slowly changing dimensions(далее SCD) — редко изменяющиеся измерения, то есть измерения, не ключевые атрибуты которых имеют тенденцию со временем изменяться. Всего существует 6 основных типов(методов) SCD, которые определяют как история изменений может быть отражена в модели.

Последнее время, в области баз данных, внимание сконцентрировано на интенсивно развивающихся NoSQL решениях. Складывается обманчивое впечатление, что в секторе реляционных СУБД затишье: основные продукты давно известны, все ниши заняты. Казалось бы, новому игроку сюда так просто не попасть. Только если речь идёт не о проекте с пятнадцатилетней историей, не о развитой объектно-реляционной СУБД с открытым кодом, оптимизированной для использования в веб-приложениях, не о системе, которая имеет поддержку хранимых процедур, партиционирование, опции высокой доступности, репликацию и распределённые транзакции. Имя этой «тёмной лошадки» — CUBRID. И, судя по заявлениям создателей, она претендует на лавры MySQL.

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

В своей дипломной работе я проводил обзор и сравнительный анализ алгоритмов кластеризации данных. Подумал, что уже собранный и проработанный материал может оказаться кому-то интересен и полезен.
О том, что такое кластеризация, рассказал sashaeve в статье «Кластеризация: алгоритмы k-means и c-means». Я частично повторю слова Александра, частично дополню. Также в конце этой статьи интересующиеся могут почитать материалы по ссылкам в списке литературы.

Так же я постарался привести сухой «дипломный» стиль изложения к более публицистическому.

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

Unix-программисты выделяются на фоне этих «автоматизаторов окошек». В мире открытого ПО каждый может попробовать свои силы и в разработке системного «софта», и в сложных прикладных решениях. Достижения таких людей в мире открытого ПО доступны всем, и для меня они порой заменяют любые рекомендации. Потому что их работу видно.

Есть ряд книг, которые, на мой взгляд, являются своеобразными «библиями» для тех, кто решил связать свое будущее с разработкой ПО. С одной из них я хотел бы начать цикл статей. Это книга Эрика Рейнмонда, «Искусство программирования под Unix». Я бы рекомендовал эту книгу не только тем, кто выбрал для себя открытые операционные системы. В основе лежит довольно универсальная философия, пригодная абсолютно всем, связавшим свою профессию с программированием.

Эрик Реймонд выделяет 17 правил этой «философии». Я буду посвящать по одной заметке на каждое правило. Я постараюсь изложить эти концепции в максимально понятной, упрощенной и популярной форме, насколько это будет возможно.

Начнем с самого первого правила — Правила модульности. Оно звучит так: «Простые блоки связывайте друг с другом ясными и понятными интерфейсами» (Rule of Modularity: Write simple parts connected by clean interfaces).

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



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

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

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

Перевод статьи Тима Ферриса из его блога.


(Учебник Дзюдо Окано Исао, который я использовал для изучения японской грамматики)

Изучение языка не должно быть сложным.

Принципы когнитивной нейронауки и управления временем могут быть применены для достижения свободного владения языком на разговорном уровне (в данном случае определяется как 95%+ процентов понимания и 100% выразительных возможностей) в течение 1-3 месяцев.

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



Итак, как известно, мозг — важнейший орган нашего тела. Кто-то говорит, что он — самая сложная вещь во вселенной. И незнание некоторых его особенностей может очень плачевно сказать на жизни человека.

Но обо всем по порядку.

Понимание роли мозга

Нет невежества страшнее, чем невежество по отношению к самому себе.

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

Все, все будут писать тесты

Уже 3 года прошло, с тех пор как я увидел свою первую красную полоску. Что меня дернуло начать писать тесты, уже не важно. Я начал собирать информацию, перечитал весь wiki.agiledev.ru и торжественно запустил свой первый тест на SimpleTest. Конечно, эти тесты были ужасны, да и архитектура тоже (в моем сегодняшнем понимании). Тогда я, наверное, словил большинство ошибок, но зато замечательно провел время :)

Потом перешел на PHPUnit — просто было интересно, чем он отличается от SimpleTest и что в нем такого «навороченного».

А lime — гадость. Чего ребята из Symfony в него так вцепились? Понимаю ветка 1.*, наследие и все такое. Но 2.0 можно было бы и на PHPUnit начинать.

Да, мне это было интересно. Я активно писал тесты, даже честно пытался делать это перед тем, как писать код. Что-то не получалось, читал разные статьи на тему, как надо и не надо писать тесты, перечитывал wiki.agiledev.ru. Но внутри явно чего-то не хватало.

Сегодня на Hacker News наткнулся на пост о (похоже очень) новом языке "ooc". Бросил на день все дела, занялся ковырятельством — уж больно интересно выглядит.

Итак, "ooc — это современный, объектно-ориентированный, функционально(ватый), высокоуровневый, низкоуровневый, секси язык программирования". (Именно секси его и представляют разработчики, ну а я бы добавил что еще и "компилируемый")

По сути — ooc — транслятор языка высокого уровня в C со сборщиком мусора.

Как выразился один из посетителей сайта: "ooc для C, — это как Scala для Java" (jimbokun@HN).

Обязательный «Hello, World» на ooc:

hello.ooc:

"Hi, softer world =)" println()

на выходе hello.c и hello.exe.

ooc-компилятор транслирует это в c-код и использует доступный c компилятор (gcc, mingw, icc, tinycc) чтобы сделать из этого hello.exe (или ./hello). Поддержка tinycc заявлена, но в реальности ждем поддержки C99 в самом tinycc (автор обещал сделать обходные пути, но пока не работает), поэтому наслждаемся пока что довольно неслабого размера .exe'шниками (gcc от mingw других не делает).

Итак, что у нас уже есть в языке: классы, объекты, строгая типизация, угадывание типов (n := "Beer" length()), chaining (.dothis().dothat()), совместимость с c-библиотеками, абстрактные классы, шаблоны из C++, списки, разреженные(sparse) списки, хеши (ArrayList, SparseList, HashMap), for (i in list) { ... }, обертки для c-шных функций и классов, перегрузка операторов, полиморфизм, сборщик мусора (отключаемый), import file/name (не нужны .h, но .h можно использовать как extern), closures, eiffel's contracts, исключения, reflections, pattern matching, ranges, ternary operator, bindings, generics, coroutines, GTK, SDL, OpenGL, GLU, GLUT bindings…

Как сказал товарищ varjag@HN: «Я думаю это розыгрыш, сделанный пользователями Ruby, но нигде этого в тексте не вижу.» Нет, этот язык существует на самом деле. Примеры, линки, установка, подводные коряги — под катом…

Уже были статьи про основы гита (0, 1, 2), были и статьи про внутреннее устройство репозитория. Сегодня поговорим, как простому смертному работать с гитом на автопилоте и не морочить себе голову.

Во-первых, шорткаты (в порядке убывания популярности):

alias gst='git-status'
alias ga='git-add'
alias gc='git-commit -m'
alias gp='git pull && git push'
alias gull='git pull'
alias gush='git push'
alias gb='git-branch'
alias gco='git-checkout'
alias gd='git-diff'

Во-вторых, отображение текущей ветки в командной строке:

export PS1='`__git_ps1 "%s"` \w \$ '

Выглядит так:

lazy-args-in-futures ~/Work/io/oleganza-io.git $

(Как установить: ericgoodwin.com/2008/4/10/auto-completion-with-git)

Типичный поток работы в одной ветке

Я встречал в сети много tutorial'ов по установке своего сервера git как на gitweb, так и на webdav, но, увы, они либо были только по одному из вышеназванных пунктов, не освещая другой, либо банально не работали. Вчера возникла необходимость поднять свой сервер репозиториев. Потратил пару часов — поднял, теперь хочу поделиться опытом, потому что считаю проблему актуальной :)

1 Вступление

В топике освещаются не столько подробности работы с git, сколько его отличия от схемы разработки других систем контроля версий, и общий подход (выработанный по большей части личным опытом и Git Community Book) к работе.