Рубрика «Fidonet» - 3

Имею честь быть знакомым с ребятами из проекта http://ru.gplvote.org/. Суть его проста как песня и нужна как воздух. Ребята создают полностью распределенную систему голосования на открытом исходном коде.
Надеюсь, здесь всем понятно, что для системы голосования означает «распределённость» и «opensource».

У ребят есть целая концепция организации верификации голосов, на GPL PGP которая не требует единого координационного центра. Читайте их сайт, интересно.
У меня есть подозрение, что если бы выборы в КС оппозиции делался на этой платформе, то… но, история не терпит сослагательности, кроме как в книжках про войну…
Читать полностью »

Имею честь быть знакомым с ребятами из проекта http://ru.gplvote.org/. Суть его проста как песня и нужна как воздух. Ребята создают полностью распределенную систему голосования на открытом исходном коде.
Надеюсь, здесь всем понятно, что для системы голосования означает «распределённость» и «opensource».

У ребят есть целая концепция организации верификации голосов, на GnuPG, которая не требует единого координационного центра. Читайте их сайт, там интересно.
У меня есть подозрение, что если бы выборы в КС оппозиции делались на этой платформе, то… но, история не терпит сослагательности, кроме как в книжках про войну…
Читать полностью »

Node.js на узле Фидонета: автоматизация периодических публикацийНекоторые фидошники сталкиваются с необходимостью периодически публиковать в той или иной фидонетовской эхоконференции одно и то же сообщение (один и тот же текстовый файл) раз в несколько дней.

Например, модератору (или комодератору, в зависимости от распределения их обязанностей) приходится раз в неделю-другую класть в свою эхоконференцию её правила. Чуть другим (но всё же подобным) примером являются те фидошники, которые взяли на себя поддержку некоторого FAQ и также публикуют его в одной или нескольких тематически соответствующих эхоконференциях. (В эхе Fidonet.History её FAQ содержит своеобразную летопись истории Фидонета, выраженную в вопросах и ответах, в эхе SU.IP.Point — список узлов, набирающих новых пойнтов, в SU.FidoTech — разъяснение ряда технических терминов и алгоритмы нескольких полезных приёмов. В эхоконференциях, посвящённых тому или иному программному продукту, FAQ поясняет его настройку. И так далее.)

Если узел (или пойнт) работает беспрерывно на одном и том же компьютере, то такая публикация автоматизируется простым, бесхитростным способом: публикацию файла вписывают в список задач для демона cron (в UNIX-подобных системах) или его аналога в других системах.

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

Сегодня мы рассмотрим, каким подспорьем может движок Node.js стать в исполнении этой задачи.

Читать полностью »

в 16:56, , рубрики: Fido, Fidonet, java, ORMLite, tosser, метки: , , ,

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

История

Как я уже писал, в 2010 году я получил узловой номер 2:5020/848. Не имея достаточного количества задач на работе, я испытывал «творческий голод», и искал, куда можно было-бы приложить свои силы. И нашел! Менее чем за месяц было написано некоторое количество ПО, которое давало различные дополнительные возможности пользователям моего узла — доступ к Fido через форум или NNTP, трансляция входящей и исходящей почты в email и многое другое.
К тому моменту, как весь этот зоопарк заработал стабильно, интерес к развитию узла я практически потерял и просматривал почту пару раз в месяц.
В 2011 году мне в голову пришла мысль переписать часть своего ПО на Java и запустить как отдельный узел, для чего я даже получил узловой номер 2:5020/849, но дальше проекта дело не пошло.
А буквально месяц назад один человек попросил меня прислать ему исходники ПО, управляющего пользователями на моем узле. Присылать их в сыром виде было бы некрасиво, поэтому код пришлось как следует почистить. И тогда, посматривая весь этот код, я решил что раз уж алгоритмы все придуманы, то почему-бы не переписать это все на Java, как я и планировал год назад? Ну вот и понеслась…
Читать полностью »

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

  • «Программирование на КОБОЛе калечит мозг, поэтому обучение ему должно трактоваться как преступление». («The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense».)
     
  • «Студентов, ранее изучавших Бейсик, практически невозможно обучить хорошему программированию. Как потенциальные программисты они подверглись необратимой умственной деградации». («It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration».)

Дейкстра умер 6 августа 2002 года. Сегодня, спустя десять с небольшим лет после его смерти, мы вправе оглянуться вокруг и спросить себя: а насколько изменились обстоятельства? Иными словами: а сейчас (в наши дни) среди широко употребляемых языков программирования есть ли такие языки, использование которых влечёт для склонных к ним программистов почти неминуемый риск заметной профессиональной деформации?

Как мне кажется, они есть; и это прежде всего те языки, которые подпадают под определение write-only language, то есть поощряют написание такого исходного кода, прочтение и понимание которого слишком трудно, неоправданно трудно (как правило, даже труднее, чем его написание автором кода), хотя в нормальных языках должно быть наоборот.

Наиболее употребительным из таких языков является Perl.

Будьте покойны: я не намерен просто ткнуть пальцем в Perl и объявить, что он плох. Это вышло бы слишком малоубедительно без доказательств и подробностей. И именно поэтому прямо сейчас на примере, взятом из жизни, я покажу вам четыре механизма, при помощи которых Perl воздействует на сознание программиста и поощряет сочинение им такого кода, который оказывается неприглядным write-only.

Читать полностью »

Сегодня у меня две причины пробежаться по клавишам.

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

Node.js на узле Фидонета: читаем джаваскриптом заголовки эхопочты, хранимой в формате JAMВо-вторых, ≈полгода назад (26 ноября 2011 года) ertaquo поинтересовался, зачем мне хочется использовать Node.js в Фидонете. Тогда я сообщил, что мне просто нравится название (помню те времена, когда термин «node» или «нóда», если употреблялся без уточнения, в российском околокомпьютерном мире по умолчанию означал узел Фидонета), но не мог привести никакого наглядного примера работающего кода, а сейчас приведу.

Итак, пример будет двойным. Предлагаю вашему вниманию анализ заголовков писем фидонетовской эхопочты, хранимой в формате JAM. Этот формат популярен в Фидонете со времён далёких и незапамятных (в Википедии говорится, что появление JAM относится к 1993 году). Сразу скажу, что давно предпочитаю JAM другому популярному формату (Squish), потому что этот последний хранит в заголовке у письма идентификаторы не более чем девяти откликов на него, тогда как JAM вместо массива ограниченной длины использует более гибкую структуру данных (связный список), так что позволяет выстроить полное дерево ответов даже в самых оживлённых и разветвлённых обсуждениях.

Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js