Хабрахабр: Коллективные / Блоги / Захабренные Голосов: 10 Адрес блога: http://habrahabr.ru/blog/ Добавлен: 2007-10-24 18:05:40 блограйдером Robin_Bad

JavaScript / Imperavi: удобный и действительно красивый JS WYSIWYG редактор

2011-07-25 23:07:19 (читать в оригинале)

В продолжение темы о красивой и удобной JS визуализации (http://habrahabr.ru/blogs/javascript/124899/) хочу рассказать вам о WYSIWYG редакторе, на который сегодня случайно наткнулся.

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

Таких редакторов существуют десятки, но все они мне почему-то не нравилисись: то выглядит уж очень топорно, то работает совершенно криво. В конце концов я остановился на TinyMCE. Он хоть и ужасен на вид, но рабоет стабильно.

И вот сегодня я совершенно случано наткнулся на редактор, который мне полностью подходит:

• работает стабильно
• выглядит очень стильно
• написан на jQuery

Имя этому чуду – Imperavi.
Попробуйте сами и думаю, что вам понравится.

Скриншот:


UPD
Более новая версия редактора: http://imperavi.ru/redactor/.

---

XSLT / [Из песочницы] Производительный и читабельный XSLT: сборник советов

2011-07-25 22:49:00 (читать в оригинале)

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

Именованные шаблоны

Многие «проблемы» XSLT связаны с тем, что мы слишком часто пытаемся писать на нём в процедурном стиле. Мы постоянно пытаемся сделать из него Smarty, но упираемся в один простой факт — XSLT является декларативным языком, как бы необычно это для нас не выглядело.
Например, мы пытаемся использовать именованные шаблоны, воспринимая их как процедуры, выводящие данные в определённом формате:

<xsl:template name="CreateItemLink">
    <xsl:param name="item"/>
    <a href="/item/?id={$item/id}">
        <xsl:value-of select="$item/name"/>
    </a><br/>
</xsl:template>

* This source code was highlighted with Source Code Highlighter.

Наверное, многие программисты именно так написали свой первый шаблон. И он неплохо решает свою задачу. Декларативный XSLT предлагает немного другой подход:

<xsl:template match="item">
    <a href="/item/?id={id}">
        <xsl:value-of select="name"/>
    </a><br/>
</xsl:template>

* This source code was highlighted with Source Code Highlighter.

Разница совсем не велика. Дело вкуса и стиля программирования. Давайте посмотрим, как шаблон будет использоваться в дальнейшем.

---

JAVA / [Перевод] Сравнение потребления памяти у разных структур хранения данных

2011-07-25 22:41:40 (читать в оригинале)

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

Какая будет разница по потреблению памяти между конструкциями `new int[1024]` и `new Integer[1024]`?

int[] ints = new int[1024];
for (int i = 0; i < ints.length; i++) ints[i] = i;

Integer[] ints = new Integer[1024];
for (int i = 0; i < ints.length; i++) ints[i] = i;


---

Системы управления версиями / [Ссылка] Книга Version Control by Example

2011-07-25 22:21:21 (читать в оригинале)

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

---

.NET / [Из песочницы] C# и нечувствительная сериализация

2011-07-25 22:03:10 (читать в оригинале)

Очень часто при работе над каким-либо проектом (как учебным, так и коммерческим) я сталкиваюсь с необходимостью сохранения каких-либо сложных данных на диск и чтения их оттуда. Казалось бы — сделай свой формат, хоть текстовый, хоть бинарный, опиши методы чтения/записи и пользуйся, ни о чем не думая.

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

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

Сразу хочу предупредить, что для самой процедуры чтения/записи файла я буду использовать бинарную сериализацию. Кое-что из того, что будет сказано в дальнейшем, применимо и к XML-сериализации, но в своей текущей работе мы с коллегами используем именно бинарную (из-за меньшего объема получающихся файлов и большей скорости работы системы в целом).

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