Эта история началась много-много ревизий назад – тогда SVN Репозиторий был девственно чист, и ни один баг еще не осквернил его своим присутствием. Первые коммиты, первые откаты, просмотры лога – все это было так захватывающе, так ново. И разве мог Репозиторий тогда предполагать, что эти первые, такие приятные шаги впоследствии приведут его на хирургический стол?

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

В первой статье в блоге .NET «Работаем с XML» в комментариях народ потребовал статьи LINQ to XML. Что же, попробуем раскрыть принципы работы этой новой технологии от Microsoft.

Создадим базу для ведения каталога аудиозаписей.

До недавнего времени мне ужасно не нравилось работать с XML файлами, я старался избегать этого где только можно, по просту заменяя их стандартными конфигурационными файлами приложения. Но где нужно было использовать обмен данными – от XML’а было не уйти. Приходилось создавать большой объем кода для того чтобы сконвертировать либо прочитать небольшой объем информации. Да, таков уж XML Document Object Model (DOM) API.

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

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

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

Это вторая часть из серии Hg Init: Учебное пособие по Mercurial от Джоэля Спольски (Joel Spolsky). Возможно, вы захотите прочитать и первую часть «Переобучение для пользователей Subversion».

Даже если вы работаете в одиночку, то вам стоит использовать Mercurial. Так вы сможете получить все прелести контроля версий. Эта часть покажет насколько просто добавить каталог в Mercurial, чтобы с легкостью отслеживать предыдущие версии.

Часть 2. Основы Mercurial

Mercurial — это система контроля версий. Разработчики используют ее для администрирования исходного кода. У нее два основных назначения:

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

В связи с недавним выходом новой версии этой «библиотеки знаний», и в связи с отсутствием новостной поддержки на Хабрахабре, заполняю этот пробел. Итак если вы:

• Долго искали примеры реализации той или иной части API Windows и не могли найти
• Хотите чтобы у вас на жестком диске было обширное количество работающих примеров
• Если вы программируете на C#, C++ или VB.NET
• Хотите чтобы для вас написали примеры работающего кода представители Microsoft MSDN Team

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

Элементы Android GUI и некоторые основные экраны в одном PSD-файле, версия 2.0.



Взялся за проектирование интерфейса приложения под Android и понял, что первой версии Android GUI PSD от Pavel Maček мне не хватает. Тогда и решил сделать свой набор, взяв за основу первую версию. В общей сложности на отрисовку элементов в vector path в Photoshop'e затратил около 3 дней. К PSD файлу прилагаются шрифты Droid Serif, Droid Sans, Droid Sans Mono, которые желательно установить.

Сравнение PhoneGap vs. Titanium vs. Rhodes

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

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

Добрый день!

Не так давно, мне потребовался инструмент или фреймворк, для того чтобы в краткие сроки, создать небольшой сайт — витрину. Особых требований не было. Собственно, сама витрина и простейшая админка, с возможностью подредактировать параметры публикуемого контента. Главным требованием была скорость. Нужно было сделать это все за 1-2 дня, с учетом необходимости верстки дизайна.

HgAssist — repositories are synced!

Пользуясь системой управления кодом Mercurial мы часто сталкивались с тем, что забывали делать push после того, как в локальный репозиторий были сделаны комиты.

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

Поэтому мы написали HgAssist.

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

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

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

Правило кодоэкономии: разрабатывайте большие программы только при наличии объективных причин это делать

Отверстал PDF-версию перевода руководства, изложенного в первой и второй частях.
Объем 48 страниц.
Выложил на амазон, чтобы всегда был доступен.
В документе оглавление, букмарки, все ссылки оригинала.
Критика, пожелания, поправки приветствуются.

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

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

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

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

Введение

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

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

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

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

Первая статья цикла

Интро

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

Всегда нравилась идея онлайн-мониторинга чего-либо на карте. И вот представилась возможность сделать нечто подобное.
Процессом и результатом разработки хочу поделиться с сообществом.

Мемоизация — (Memoization, англ) вариант кеширования, заключающийся в том, что для функции создаётся таблица результатов, и будучи вычисленной при определённых значениях параметров результат заносится в эту таблицу. В дальнейшем результат берётся из данной таблицы.
Эта техника позволяет засчёт использования дополнительной памяти ускорить работу программы.Данный подход очень частно применяется в функциональных языках программирования, однако и в императивных ему так же можно найти применение. В данном топике рассматривается использование мемоизации в языке java приводятся различные примеры мемоизации и в конце производится небольшое сравнение производительности данных методов.

Эрик Липперт (Eric Lippert) — личность достаточно известная, он является ведущим разработчиком комплиятора C#, и автор одного из самых интересных блогов в этой области «Fabulous Adventures In Coding». Кроме того, Эрик является активным участинком сайта stackoverflow, откуда он периодически черпает вдохновение для своих постов.

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

Мы потратили несколько часов, исследуя онлайн-сервисы из списка Webware 100 Top Web Apps 2008 и изучая их бизнес модели. Следующая диаграмма показывает результаты исследования — 34% сервисов используют рекламную модель, 12% различные схемы подписки, 8% продают виртуальные товары (чаще всего в виде данных для скачивания), такая же доля сервисов предлагает сопутствующие продукты (обычно большие компании-разработчики предлагают бесплатный вариант продукта для привлечения к их платформе) и еще 8% сервисов используют схему «оплата за использование».

Поискал на Хабре, не нашел рецензии на русское издание знаменитой книги Гая Кавасаки The Art of the Start (2004) (на англоязычную было), поэтому решил «закрыть брешь» и поделиться ее кратким содержанием и своими мыслями.

Итак, в русской версии книга получила название «Стартап. 11 мастер-классов от экс-евангелиста Apple и самого дерзкого капиталиста Кремниевой долины».

Если вы производите прорывной софт для разведения креветок, то эта книга точно для вас.