понедельник, декабря 17, 2007

Требуется программист на удаленную работу

Здравствуйте, уважаемые читатели! А вот кого из вас интересует удаленная работа на Erlang-е? (не откажусь и от OCaml или Haskell, хотя они, скорее всего, меньше подходят для задачи).

В чем суть.

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

Краткое ТЗ.

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

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

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

Главное.

Хочется, чтобы все это было сделано на нормальном языке программирования. И думается мне, что для этого больше всего подходит Эрланг.

Детали.

Работа удаленная. Бюджет $4-5k (обсуждаемо). На разработку дается 3 месяца (желательно, конечно, быстрее). Далее поддержка (за отдельные деньги).

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

Звоните: ...
Пишите: ...

Вопросы и комментарии приветствуются.

А кросс-постинг в заинтересованные сообщества приводит в восторг ;)

пятница, октября 12, 2007

Correct by construction

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

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

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

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

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

Кстати, под интерфейсом я понимаю не только набор методов в классе, или функций в модуле, но еще и элементы языка программирования, ведь они тоже соединяют элементы программ (кстати, ни один из известных мне языков программирования не поддерживает полностью принцип Correct by construction, хотя некоторые и стремятся).

Что же подразумевается под корректными интерфейсом? Да собственно такой интерфейс, который физически нельзя использовать не по назначению. Примеры:

  • Если функция, в случае ошибки, возвращает -1, NULL, или любое другое магическое значение, то когда-нибудь это значение не будет обработано. А если функция возвращает опциональный тип (option, Maybe, или как он называется в вашем языке), то возможность забыть обработать ошибку отпадает сама собой.


  • Прямая работа с указателями или массивами в принципе не может дать гарантий безопасной работы с памятью. Но если к массивам можно достучаться только через функции вроде map, fold, iter, то no problemo: нет индексов — нет ошибок с индексами (а в будущем, надеюсь, проблема безопасного доступа к массивам по индексам решится при помощи dependent types).


  • Наличие явных функций open/close, create/destroy, alloc/free всегда оставляет возможность не освободить занятый ресурс. А если использовать RAII или функции типа with_resource, то у потенциального «дурака» в принципе не получится что-то забыть &mdash ведь не он теперь заведует ресурсом.


  • У вас много изменяемого состояния. Боитесь, что кто-то изменит его не в том порядке? Разбиваем на кусочки, делаем функциональный интерфейс, и уже ни у кого не получится перепутать вкл. и выкл.


  • Нельзя нажать на эту кнопку — так может ее вообще убрать или сделать disabled?


Список можно продолжать долго.

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

Система будет истинно корректной только тогда, когда ее нельзя некорректно использовать. И только из таких систем можно создавать еще большие корректные системы. Это и есть Correct by construction.

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

среда, сентября 26, 2007

И еще немного про скрипты

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

Но есть еще одна причина, по которой люди используют скрипты — расширяемость программ. И эта проблема уже больше психологическая. Программист, как и любой умник, хочет написать что-то клевое и универсальное (движок), чем потом можно будет как угодно рулить из скрипта: «Смотрите, вот вам exe-шник, а работать он будет так, как мы ему напишем в скриптах» (вернее, «Смотрите, какой я умный, умею создавать гибкие решения»). Внимание, вопрос! А не является ли ваш скрипт, по сути, очередным exe-шником или dll-кой? Не добьетесь ли вы такой же гибкости просто написав модуль к программе?

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

Soft coding — не лучшая замена hard coding-у. Чем отличается код скрипта в отдельном файле от обычного модуля программы? Тем, что красивше? Значит у вас недостаточно выразительный основной язык. Тем, что его можно динамически загрузить в рабочую программу? А разве обычный модуль нельзя?

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

PS: еще рекомендую почитать (не столько про скрипты, сколько про липовую расширяемость за счет «правильной» архитектуры): The Mythical Business Layer.

пятница, августа 24, 2007

Скриптовые языки — оно вам надо?

Вот Вы, да, Вы. Зачем Вы используете скриптовые языки? У Вас есть большая программа и хочется добавить в нее гибкости, сделать расширяемой, менять что-то отдельно, не трогая основы? А как это сделать — конечно же, добавить скриптовую обвязку: Lua, Python, Tcl, Lisp, да что угодно. Некоторые даже придумывают собственные языки.

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

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

Тем не менее, скрипты «со скрипом» прикручиваются. Ведь на них все пишется короче и быстрее, а программа становится расширяемой — игра стоит свеч!

СТОП. А теперь задумаемся. Не потому ли мы используем скриптовые языки, что наш основной язык (например, С++) является слишком сложным и низкоуровневым для простых, «скриптовых» задач?

Не только — скажете Вы:

  • скрипты экономят время на компиляцию;


  • скрипты можно хранить отдельно от основной программы;


  • и, наверное, еще что-то.

Только вот время, сэкономленное на компиляции, с лихвой потратится на отладку. А хранить отдельно от основной программы можно многое. Как минимум OCaml и Haskell умеют загружать отдельные модули в основную программу. Причем модули, скомпилированные в нативный, а не в байт-код.

Более того, практически на любом языке можно сделать динамически загружаемый модуль (.dll или .so), который хранится отдельно от основной программы. А если не использовать в качестве языка С++ с морем template-ов, то время компиляции такого модуля становится несущественным.

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

Может быть, стоит сменить основной язык разработки? И тогда Вы забудете про множество глупых проблем (ошибки в скриптах и обвязке; тормоза при загрузке и работе), а заодно начнете использовать гораздо более продуктивные инструменты.

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

Короче. К черту скрипты, пишем все на одном мощном, удобном, кратком и продуктивном языке.

понедельник, июля 30, 2007

Маленький совет

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

И будьте осторожны на воде. На 5-й минуте человека еще можно откачать, а дальше уже нет. Даже если вы хороший пловец, но у вас плохое самочувствие — не лезьте в воду! Это может закончится очень плохо.

Спасибо, надеюсь вы будете больше думать о своем здоровье.

Дима Макеев. 26.10.1971—21.06.2007

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

Дима был отличным музыкантом, светлым, веселым и очень жизнерадостным человеком.

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

Царствие тебе небесное, и пусть земля тебе будет пухом.

четверг, апреля 26, 2007

Ищем программиста

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

Обязательные требования:

  • желание разрабатывать игры;


  • умение пользоваться GNU toolchain;


  • знание Linux на уровне опытного пользователя;


  • хороший алгоритмический базис;


  • знание C++ на хорошем уровне;


  • скриптовые языки (желательно, python).


Желательно:
  • знание OpenGL, GLSL, OpenAL, wxWidgets;


  • умение собирать линукс с нуля (gentoo, lfs, etc.);


  • простое администрирование серверов (apache, backup);


  • огромным плюсом является знание Haskell или Ocaml (мы пишем на OCaml, если возможно, и на C++, если необходимо).


Обязанности:
  • написание инструментария для создания и тестирования игр;


  • сборка Linux-а, работающего в игровом автомате;


  • администрирование внутреннего сервера разработки (по мелочи);


  • и, конечно же, разработка игр.


Условия:
  • з/п от $800;


  • офис рядом со ст. м. Южная (г. Москва);


  • оформление по ТК;


  • график работы с 12:00 до 20.00, возможно гибкий;


  • возможен прием студента последних курсов.


Контакты:
  • E-Mail: <vshabanoff@gmail.com>;


  • Телефон: +7 926 536-27-96 (Владимир Шабанов);


PS: Комментарии приветствуются.

UPD: вакансия закрыта, желающие программировать на Haskell или OCaml по прежнему интересуют (на будущее), есть желание, скидывайте резюме на мыло, в будущем посмотрим.

суббота, апреля 21, 2007

Корректность, типизация и Erlang

В последнее время все чаще встречаю упоминания об использовании Erlang на просторах ex-USSR.

Судя по всему, возрастающее применение Erlang оправдывается достаточно большим количеством success stories. К тому же Erlang поддерживается не только группой исследователей и community, как это происходит с Haskell и OCaml, но и такой немаленькой фирмой, как Ericsson. Это позволяет легче убедить менеджмент в пригодности Эрланга для серьезной разработки.

Но, как и в предыдущем посте, я хочу поговорить о корректности программ.

С Эрлангом наблюдается очень забавная картина: с одной стороны он предназначен для написания fault-tolerant программ и обладает замечательной runtime системой, хорошо подходящей для написания распределенных пуленепробиваемых non-stop приложений. С другой стороны — это язык с динамической типзацией, что, по моему мнению, противоречит написанию корректных программ.

Как можно написать корректную программу, если язык позволяет допустить практически любую опечатку? А как я поправлю ВСЕ места, где использовался модуль, принцип работы которого я только что поменял? Возможно, у Эриксон и есть столько денег на тестеров, но что делать более экономным людям?

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

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

Короче, если вы никогда не опечатываетесь, никогда не редактируете большие программы, пишете юнит-тесты для всех функций в системе, и, самое главное, вам не лень делать работу, которую можно автоматизировать, то Эрланг, лисп, питон, перл, tcl, lua — это все для вас. Я завидую вашему кунг-фу :)

PS: Ни в коем случае не хочу сказать, что эрланг — плохая платформа. Если ваша программа на 90% состоит из сетевого трафика, то, возможно, Эрланг вам и подходит. Но вот как язык...

PPS: Еще одна, несколько другая, жалоба на отсутствие статической типизации в Эрланге.

пятница, апреля 20, 2007

Немного по OCaml и Haskell

От людей, пишущих программы на OCaml и Haskell часто слышно о том, что они в 10 строках описали то, что на C++/C#/Java занимало 100 строк, или за 2 недели написали то, что другие делали 2 месяца.

Это — всем известные факты. Программы на любом более менее вменяемом языке, будь то erlang, lisp, python, и т.д., в среднем занимают в 5-10 раз меньше места и, по личному опыту, пишутся в 3-5 раз быстрее.

Однако сейчас я хочу сказать про другую черту — корректность программ. Как часто вам приходится пользоваться отладчиком? Можете ли вы себе представить, что отладчик — вещь ненужная? В OCaml и Haskell это действительно так!

Хотя в OCaml есть чудесный отладчик, позволяющий ходить по программе и вперед и назад, никакой потребности в нем за последние 3 года я не ощутил. Да. За последние 3 года я ни разу не пользовался отладчиком для программ, написанных на OCaml. Он просто не нужен! Если и возникают какие-то непонятки, то все решается отладочной печатью или запуском проблемных мест в интерпретаторе.

Не могу сказать, что мои OCaml-программы никогда не падали. Было такое, но виновата была только C++ часть.

А в целом в OCaml и Haskell вы никогда не встретите:

  • access violation — нет pointer arithmetics;


  • NullPointerException — нет NULL :), а на любые места, где возможен None, компилятор вам укажет;


  • SIGSEGV или BSOD — ну нельзя тут загадить память.

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

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

пятница, марта 30, 2007

SICP: Впечатления от прочтения

Не прошло и полгода с момента закупки SICP, и я наконец-то ее прочел!

Сразу скажу: SICP — это не учебник по Lisp, это книга по Программированию. Если вы просто хотите изучить Lisp или Scheme, то SICP не для вас, лучше попробовать что-нибудь попроще.

Книга стала пожалуй одним из самых интересных и серьезных текстов, прочитанных мною за последнее время. После книг Кернигана и Ритчи, Страуструпа, книг по OCaml, Haskell, кучи тьюториалов, мануалов, статей и прочей литературы, SICP стала для меня чем то вроде откровения, откровения о том, какой должна быть книга по программированию.

Книга действительно предназначена для первокурсников. Она не требует никаких предварительных знаний по программированию.

В отличии от обычных книг, SICP не учит синтаксису (его у лиспа почти нет), а учит базовым вещам, необходимым для понимания того, как надо программировать. Причем, выбор этих базовых вещей и уровень их объяснения поистине шедеврален.

Уже на 20-й, 30-й странице мы узнаем о нормальном порядке вычислений, lexical scoping, рекурсивных и итеративных процессах, функциях высших порядков, lambda-выражениях, замыканиях и прочих вещах, о которых я узнал гораздо позже, чем надо. А к концу второй главы знаний хватает на то, чтобы писать 90% встречающегося кода. И мы еще не дошли до изменяемого состояния, модулей и объектов!

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

И вот мы доходим до модулей, объектов, потоков, параллелизма, распространения ограничений. Вы думаете, сейчас вам будут рассказывать, как пользоваться готовыми фреймворками или специально заточенными элементами языка программирования? Фигушки! Вам объяснят, как это сделать с нуля, из тех самых базовых кирпичиков, изученных в первых двух главах. Ничего больше не нужно! Это потом, в других языках (или на следующем курсе), вы увидите, как это можно сделать короче и запутаннее. Сейчас вы должны понять основы, как это сделать самому. И что самое приятное, все это сопровождается общими объяснениями, жизненными примерами и интересными упражнениями.

Теперь, казалось бы, мы знаем основные методики программирования. Только этого мало. Для лучшего понимания процесса вычислений нам надо построить несколько интерпретаторов: самой Scheme, схемы с ленивыми вычислениями, с недетерминистским вычислением, а также интерпретатор для среды логического программирования. Четвертая глава вам в этом поможет.

Что, скилл в вычислениях прокачан и карма аж светится? Но ведь вы все это время были далеки от железа и не знаете, как все это работает уровнем ниже Scheme! Тут то (в заключительной главе) вам и расскажут про регистровые машины, даже парочку-троечку спроектируют. Чтобы было на чем их проверять, вам опишут имитатор регистровых машин. Вы узнаете про стек. Вам расскажут про сборку мусора (и конечно покажут, как ее сделать с нуля ;). Чтобы прокачать понимание регистровых машин, вы напишете интерпретатор Scheme на своеобразном ассемблере. Но ведь интерпретатор — это медленно, надо написать компилятор! А компилятор сам по себе не очень удобен (нет интерактивной разработки), так что скрестим его с интерпретатором. Страшно? Ничего, ребята действительно хорошо все объясняют.

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

Выводы

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

А если Вы программист со стажем, то следует почитать хотя бы для наведения порядка в голове.

PS: Paul Graham сказал про SICP:

„Я впервые прочел ее 15 лет назад и до сих пор не уверен, что усвоил все, чему эта книга может научить.“

воскресенье, февраля 04, 2007

StarDict: Кросплатформенный словарь

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

Однако, случайно я обнаружил замечательный словарик StarDict, open source альтернативу Lingvo.

StarDict работает и под windows и под linux, умеет переводить слова в других программах при наведении на них мышкой, умеет осуществлять нечеткий поиск (по словам с опечатками), а главное — бесплатен.

На сайте программы можно найти большое количество словарей. Причем, для английского языка их побольше чем у Lingvo, плюс есть толковые словари (и даже словарь Даля) и, если кому нужно, есть словари для японского, китайского и тайваньского языков. Кроме того, есть записи произношения около 20000 английских слов.

Так что я уже пользуюсь StarDict и не чувствую себя пиратом, а вы? :)

суббота, января 20, 2007

И немного про LaTeX

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

Спасибо LaTeX-у за то, что я теперь реже ругаюсь матом.

пятница, января 19, 2007

Небольшой обзор персональных wiki-систем

На работе давно пользуюсь wiki, входящей в состав Trac. Wiki — это дико удобная вещь для создания заметок и их дальнейшего связывания друг с другом. Можно начать с маленького черновика, и дорасти до настоящей проектной документации. Или даже до чего-то большего, например, до Wikipedia.

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

Конечно, можно завести себе доменное имя, сервак, и установить на него Trac, а лучше MediaWiki, но возиться не хочется. И решил я поискать — что же мне предложит старик интернет?

И вот, что я нашел и попробовал:

  • http://stikipad.com/ — выделяет 30 MB для фришного аккаунта, что для обычного текста без картинок более чем достаточно; позволяет делать приватные вики (вход только по паролю); форматирование textile или markdown или WYSIWYG, т.е. не такое, как привычное мне форматирование в Trac или форматирование в MediaWiki (см. также тут); позволяет делать примитивные TODO-шки (не Trac, конечно); есть теги.


  • http://pbwiki.com/ — простая, как peanut butter sandwich — утверждает сайт; действительно простая; выделяет 10 MB для фришного аккаунта; также позволяет приватность; лично мне не очень понравился внешний вид; формат pbwiki тоже простой (не такой как у всех остальных wiki, нечто среднее).


  • http://serversidewiki.com/ — очень своеобразная штука — все прыгает и бегает (ajax & ruby on rails, основан на TiddyWiki), стоит посмотреть поприкалываться, может кому-нибудь понравится (я сам прикололся, но потом подумал, что для меня статичные сайты лучше — на этом даже ссылку не сделаешь); в сентябре станет платным, и фришным аккаунтам будет выделяться не более 10-ти страниц-tiddler-ов, т.е. система только на посмотреть; есть мега-удобные TODO-шки; теги; приватность делается постранично, через тег private (который неудобно вставлять каждый раз); форматирование textile.


  • http://wikispaces.com/ — выдают 2 GB и говорят, что можно расширить (Just drop us a line); приватным делается за 5$/мес; форматирование WYSIWYG или как у pbwiki; поиск почему-то через google, а не свой (как у всех остальных wiki); теги.


  • http://wetpaint.com/ — симпатичный сайт; есть только WYSIWYG редактор; система заточена на community и соответственно никакой приватной wiki; ограничения на объем пока нет; пожалуй, самая простая wiki — для домохозяек :).


  • http://wikia.com/ — все прелести википедии (MediaWiki), но надо делать открытый, идейный коммьюнити-проект, т.е. это вообще не персональная wiki-система.


  • http://www.google.com/notebook/ — очень простая система, даже не вики, а так просто раскидывать текстовые заметки по блокнотикам. Стоит посмотреть — возможно вам будет достаточно.


  • http://www.wiki-site.com/ — персональная MediaWiki; никакой приватности — ваши страницы могут смотреть и изменять (хотя можно защищать отдельные страницы от правки); сайт открылся где-то полгода назад и несколько сырой; ограничений на объем нет, но советуют швырять всякую мультимедию на youtube.com и imageshack.us. Т.к. это единственная персональная MediaWiki-система, которая мне попалась, я забил на открытость и пока остановился на ней.


Практически все эти системы живут за счет рекламы. См. сюда, чтобы узнать, как от нее избавиться.

Дополнительную информацию по некоторым из этих wiki-систем можно узнать в статье Сделай собственную Wiki.

Надеюсь, обзор вам хоть чуть-чуть помог, и вы сможете быстрее попробовать и выбрать себе wiki-систему. Рекомендую выбирать между stikipad, wikispaces, wetpaint и wiki-site.

PS: Если вы знаете какой-нибудь еще бесплатный wiki-хостинг (особенно, если это MediaWiki-хостинг), напишите мне. Буду благодарен.