*** ВНИМАНИЕ: Блог переехал на другой адрес - demin.ws ***

вторник, 22 декабря 2009 г.

Wiki2blog: онлайновый wiki-редактор для Blogspot

Как я уже писал, что из-за неудобства онлайнового редактора Blogspot'а я перешел на использование Wiki на Google Code для написания и хранения постов. То есть я пишу пост, используя язык разметки Wiki, отлаживанию разметку, заливаю картинки и т.д., а затем просто конвертирую wiki-файл с помощью скрипта на php в html. Фишка тут в том, что скрипт должен учитывать некоторые "особенности" Blogspot'а — необходимость убирать разделители строки после блочных тэгов типа blockquote, pre, списков и т.д., чтобы не появлялись ненужные отступы. В результате выходной html становится практически нечитаемым.

Удобство же wiki-разметки в том, что исходник поста выглядит красиво и пригоден для последующего редактирования.

Но в таком подходе цикл работы над постом несколько длинноват: редактор, push через Mercurial на Google Code, просмотр как выглядит на Wiki, затем прогон через скрипт, и если все хорошо, то "cut-paste" в онлайн-редактор Blogspot и финальный отсмотр там. А если обнаруживаются шероховатости, что цикл повторяется сначала. И еще меня раздражал сам скрипт — корявый и непонятный.

Хотелось чего-нибудь легкого и более менее WYSIWYG.

Порыскав в сети на наткнулся на wiki2html. И это оказалось то, что нужно. Я немного подкорячил это под свой формат wiki-разметки и, в итоге получилось это: онлайновый редактор с препросмотром для подготовки постов в Blogspot.

Теперь цикл такой: набиваешь пост в этом редакторе, а он автоматически отображает preview по мере набора вместе с htmlем. Затем cut-paste html-я в Blogspot, и с большой вероятностью форматирование должно выглядеть как задумано.

Ни разу не претендую на возможные странности моего диалекта Wiki. Желающие могут изменить под себя, ибо форматировщик крайне простой.

Редактор состоит из одного файла wiki2html.html. Его можно просто сохранить локально и поиграться.

Под занавес привожу поддерживаемые команды wiki-разметки (таблиц пока нет).

Ссылки и картинки

[http://example.com/test] — ссылка: http://example.com/test

[http://example.com/test ссылка с текстом]ссылка с текстом

[http://github.com http://github.com/images/icons/public.png] — картинка со ссылкой

[http://github.com/images/icons/public.png] — картинка

[http://github.com/images/icons/public.png картинка по ссылке]картинка по ссылке

Текст

'''bold'''bold

''italic''italic

@@[http://google.com]@@ — экранирование любой wiki-разметки

моно`ширин`ный текст — моноширинный текст

Заголовки

= Заголовок1 =

== Заголовок2 ==

=== Заголовок3 ===

==== Заголовок4 ====

===== Заголовок5 =====

Цитирование

Цитата начинается с двух пробелов.

Разделитель

---


Ненумерованный список

Код:

* это
** ненумерованный
* список

Как выглядит:

  • это
    • ненумерованный
  • список

Нумерованный список

Код:

# это
## нумерованный
# список

Как выглядит:

  1. это
    1. нумерованный
  2. список

Исходники

Код:

{{{

#include <io.h>

int main() {

  int a = 1;

  return a;

}

}}}

Как выглядит:

#include <io.h>
int main() {
  int a = 1;
  return a;
}

Видео

[http://www.youtube.com/watch?v=FrufJFBSoQY]

Собственно, этот пост я подготовил по описанной технологии. Можно посмотреть как его исходник выглядит в wiki-формате.

Посты по теме:

среда, 16 декабря 2009 г.

Тренинг Steve Dewhurst'а "C++ Common Knowledge"

Побывал на тренинге Steve Dewhurst'а "C++ Common Knowledge". У меня уже давно есть его книга:



и в целом конкретно этот тренинг посвящен темам из нее.

Очень прикольный дядька. Нескучно, разбавлено подколами аудитории и шутками типа что ребята из Boost'a не иначе как курят шаблоны и т.д. Мне очень понравилось.

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

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

Рекомендация такая: сначала задаешь себе вопрос: а нужно ли мне тут множественное наследование? а нужно ли мне виртуальное множественное наследование?? а нужно ли мне виртуальное множественное наследование с данными в базовом виртуальном классе??? И даже после долгого раздумья лучше сказать "нет". Лично я не имею ничего против множественного наследования. Но мне не очень нравится как это сделано в С++. И мне не очень нравится как это сделано в Java. Мне очень нравится, как сделано в Go. А именно: в Go полностью разнесены понятия структур данных и интерфейсов. Структуры данных не могут быть унаследованы. Они могут только реализовывать интерфейсы. А наследовать можно только интерфейсы. Поэтому в принципе нельзя при наследовании подцепить чужие данные, а только методы. А нет данных, не и проблемы их инициализации.

Итак, могу просто собрать общие рекомендации от Стива:
  • стараться использовать виртуальные функции и полиморфизм в целом вместо "if" и "case"
  • стараться использовать алгоритмы STL/Boost и функторы вместо циклов
  • использовать только "умные" указатели при работе с динамической памятью
  • не использовать классические массивы, а контейнеры STL (так как, например, std::vector гарантирует линейное размещение элементов, то можно смешивать "старый" код, работающий с указателями, с использованием контейнеров)
  • тщательно продумывать операции копирования сложных классов (лучше всего реализовать конструктор копирования и метод swap, а оператор присваивания реализовать через них)
  • всегда объявлять в коде класса конструктор копирования и оператор присваивания, и даже если они не используются, то просто закомментировать их объявление с пояснением, почему они не нужны
  • никогда не использовать приведения типов в стиле С, только С++ (static_cast, const_cast и т.д.), так как они длинные, их нудно набивать и они уродуют вид программы - в общем, все, что нужно для минимизации их наличия
  • помнить, что наследование - это re-use интерфейсов, а не кода как такового
  • не слишком верить компилятору ;-) (Стив их писал и знает, что они могут и подставить)

вторник, 15 декабря 2009 г.

Peter Seibel, "Coders at Work"

Неспешно дочитал "Coders at Work".

Peter Seibel, Coders at Work



Книга состоит из интервью с десятком известных программистов. Тут есть создатели UNIX, Netscape, JavaScript, Smalltalk, Haskell, Erland, Ghostscript, ЖЖ и также есть просто Дональд Кнут. В общем, не самые последние люди.

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

Многие ссылаются на разные книги - я значительно пополнил свой список на "прочитать".

Забавно, что почти никто не отозвался однозначно положительно о С++. Либо было однозначное нет типа "очень перегружено, сложно и т.д.", либо "ну раз уж более ничего пока лучше нет для создания native кода промышленной сложности, то пусть будет".
Лирическое отступление. Я тут покуриваю Go, и чем дальше, тем больше меня прет. Могу сказать, что я почти для всех своих плюсовых привычек нашел альтернативу в Go. Ну а его врожденная мультипотоковость и ультра быстрая компиляция довершают все.
Также интересно мнение на тему обязательно ли для всем уважающим себя программистам прочитать "Искусство программирования" Кнута или хотя бы иметь в своей библиотеке. Многие признали, что не читали от корки до корки, но как справочник используют.

Как всегда убедился, что я даже и не слышал о некоторых крайне известных вещах. Например, Literate programming от Дональда Кнута или фильтр Блума.

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