blackyblack

С днём всех влюблённых

johnmalkovich@mail.ru — Wed, 11 Feb 2009 12:51:33 GMT

Любимая, поздравляю тебя с днём святого Валентина.
Милая Женечка, я тебя очень люблю и посвящаю эту запись тебе.

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

С праздником, милая! Я тебя люблю...

ООП

johnmalkovich@mail.ru — Fri, 23 Jan 2009 12:19:59 GMT

Читаю http://okmij.org/ftp/Computation/Subtyping/Preventing-Trouble.html.

Да, всё-таки у ООП есть проблемы. Может быть даже тяжелые проблемы. Вспоминаю все свои проекты и, пожалуй, ни одного успешного проекта с применением наследования припомнить не могу.
Конечно, часть такого результата во мне - всё ж таки некомандная разработка с участием не особо умного программиста. :) С другой стороны мейнстрим технология и не должна предполагать умного программиста как основного потребителя. Получается, что ООП доступно только софтверным гигантам, которые разрабатывают фреймворки, апи и прочую гадость. Для разработки же конечного продукта, на мой взгляд, ООП в чистом виде противопоказано.

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

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

Хотел ещё приписать сюда подход из предыдущей темы про сервисы, но решил что пока нет реальных опытных данных, лучше рекомендаций не давать.

Модульное программирование

johnmalkovich@mail.ru — Sat, 27 Dec 2008 20:50:39 GMT

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

Судя по гуглу, модульное программирование сквозь COM, RPC и корбу эволюционировало до веб-сервисов. Какой в этом видится вывод? Я здесь вижу то, что публиковать объекты неразумно - следует публиковать сервисы. Сервис, в отличие от объекта, можно продать, нарисовать, заменить аналогичным. Внутри самого сервиса может быть что угодно, но для клиента это должна быть хорошо задокументированная сущность с ясной целью и наобором интерфейсов (возможно стандартных).
Как выглядят сервисы сейчас и подходят ли они для настоящего модульного программирования? Сейчас это некое приложение, доступное как для локального пользователя, так и удалённого. Описание интерфейсов содержится в отдельном файле в платформонезависимой форме.
Я вижу здесь следующие недостатки:
- нет возможности взять готовый компонент и поместить его в своё приложение. Можно только обратиться к уже запущенному чужому сервису. Если же откопать этот компонент, то для того чтобы интегрировать с ним своё приложение придётся помучаться. Тут наблюдается некоторая проблема в том, что вам поставляется уже готовый сервис; если же вы желаете сами поднимать этот сервис, то будьте готовы к проблемам.
- нет возможности выбрать готовый компонент из каталога. Я не обнаружил никакого стандарта на описание веб-сервисов. Да и неявного стандарта тоже не заметно. Видимо это проистекает из первой претензии - нет как такового компонента - нет и описания.
- нет стандартных интерфейсов. Самая тяжёлая проблема. Вохможно в программировании стандартизация интерфейсов вообще недостижима. Если бы она была достигнута, то из готовых компонентов и адаптеров из интерфейса к интерфейсу можно было бы собрать всю систему без программирования вообще. Будем считать, что на данный момент эта задача неразрешима и интеграцию компонентов выполняет их хост.
- всё ещё нет толковых диаграмм для описания сервисно-ориентированной архитектуры. Предлагается какой-то бред.

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

Вот где-то так. Комментарии?

Русская ОС

johnmalkovich@mail.ru — Wed, 22 Oct 2008 06:47:34 GMT

Вот она где куётся http://www.rus-os.narod.ru/

Чем я занимаюсь на работе

johnmalkovich@mail.ru — Thu, 29 May 2008 10:51:21 GMT

Если вдруг кому интересно, то я работаю в конторе, которая называется "Профреабилитация". Ещё до меня эта контора освоила производство охранных систем на базе GSM и этим в основном и промышляет. Система называется "Редут-GSM" и установлена на многих ЧОПах в окрестностях Челябинска, Челябинской области и дальше.

Всего тут работает 4 человека:
- Винников - бухгалтер, директор и руководитель;
- Олег - радист, электронщик, разводит платы в основном;
- Ваня - программист, электронщик, специалист по общим вопросам :)
- Я - программист.
До меня тут работал другой программист, но он уехал в штаты, так что я в начале своей деятельности дорабатывал его глюки и несколько автоматизировал работу по созданию охранных блоков.

По ходу своей деятельности мы затеяли проект с GPS навигацией. Изначально планировалось сразу создание навигатора совмещённого с автосигнализацией. Кроме того, планировалось сделать брелок для сигналки на базе Зигби трансиверов (пакетная передача, низкое потребление, хорошая защищённость). Поэтому я немного экспериментровал с этими штуками, разными стеками и у нас тут лежат кое-какие образцы этих девайсов.
Однако в дальнейшем, всё же решили начать с более простого проекта и сделать чисто GPS навигатор с передачей данных на сервер, а с сервера в WEB и с кое-каким управлением внешними устройствами. Вот это и было моим основным полем деятельности.
По итогу сделали девайс на базе GSM/GPS модуля q2501 от Wavecom с двумя входами, одним выходом и АЦП. Обозвали его Redut-NAVI. Девайс цепляется на наш сервер и висит на нём всё время. Сам собирает данные в буфер и отправляет на сервер и периодически обменивается с сервером командами управления. Прошивку для этого девайса полностью писал я. По опыту работы качество прошивки вышло приличное, но выяснилось, что есть вероятность аппаратного зависания модуля и в связи с этим жестокая нехватка внешнего вотчдога. Кроме того, наблюдаются непонятные явления при входе в роуминг на некоторых операторах.
Софт для сервера тоже писал я. Принцип работы такой, что на входящие соединения создаётся тред и в нём обрабатываются данные и команды. Данные без обработки скидываются в базу на mysql. Затем другие процессы декодируют данные и перекидывают в базу для сайта с картой. Так что сервер сейчас выглядит как 6 экзешников, один из которых запускается как сервис и следит за остальными, запуская их как процессы. Качество сервера по итогу работ среднее. Так скорость работы с БД линейно падает с увеличением записей и пришлось писать специальный процесс-мусорщик. Кроме того, выяснилось, что по каким-то причинам сервер может перестать выдавать новые треды - надеюсь, что этот глюк я уже исправил. Так что есть вероятность, что сетевая часть будет переписана и будет изменена СУБД.
На данный момент проданы ~20 комплектов этой навигации и ожидается покупка порядка 15 штук в ближайшее время.
И ещё, на данный момент пишется новая версия навигации, на новой аппаратной платформе, с вотчдогом и возможностью удалённого обновления софта. Так что всё будет круто. :)

Erlang

johnmalkovich@mail.ru — Fri, 28 Mar 2008 09:56:22 GMT

Блин, у кого-нибудь Ерланг под виндой запускался?

Чё-то ни у кого такой проблемы не возникало, судя по гуглу, но у меня он не дружит с сетью, по всей видимости.
Симптомы: пытаюсь выполнить toolbar:start() и toolbar падает с ошибкой типа errnosocket. Если пытаюсь запустить erl.exe с ключом sname, то падает сам Ерланг.

Может кто знает, че за фигня?

End of Evangelion

johnmalkovich@mail.ru — Fri, 28 Mar 2008 09:39:21 GMT

Досмотрел в очередной раз NGE и ещё больше убедился во мнении, что End Of Evangelion должен идти после 24-й серии и перед 25,26 сериями. Это очень странно, если учесть, что EoE вышёл уже после того, как были показаны последние серии сериала, но тем не менее, вариантов больше не остаётся.

Судите сами: при рассмотрении дел различных персонажей в 25-й серии, показывают флэшбеки, которых не было в сериале, но которые были в EoE. Это кадры с Евой-02 под водой и Аска кричит, что не может ничего сделать. Также, кадры с расстрелянными персонажами Мисато и техников. Кроме того, на протяжении 25 и 26-й серии Синдзи показывают сидящим на фоне земного шара. Такое положение никак не следует из предшествующих серий, однако следует из событий EoE. Кроме того, Синдзи предлагают создать свою реальность, что также следует только из событий EoE.
В конце концов, в 26-й серии показывают, как после выбора Синдзи по земному шару прокатывается некая волна, что должно символизировать выбор новой реальности для всего человечества, что также следует только из EoE и никак не указано в самом сериале.

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

Искусственный интеллект. Продолжение.

johnmalkovich@mail.ru — Wed, 16 Jan 2008 11:42:40 GMT

В продолжение темы...

Для того, чтобы использовать в качестве носителя алгоритма конечный автомат, я попытался разыскать какую-нибудь удобную реализацию конечных автоматов (FSM по-английски). Таковой я пока что не нашёл. Если кто-нибудь может порекомендовать что-нибудь подходящее, желательно с внешним хранилищем таблиц переходов, например в xml, для Си/С# - милости просим.

Однако в процессе поисков я наткнулся на интересного человека по имени Lawrence J. Fogel. К сожалению, в прошлом году он умер... Так вот, ещё в 60-х годах он проводил работы по описанной мной идее. И именно над конечными автоматами. Правда ближе к 90-м взялся за эволюцию нейронных сетей, что несколько обескураживает. :)

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

Теперь я собираюсь найти и прочесть книгу Фогеля, чтобы не напороться на его грабли. :)

Вот ещё ссылка на заметку исследователей. Правда оформление похоже на рекламную листовку.
Статья "Artificial Intelligence Through Simulated Evolution"

Как сделать искусственный интеллект

johnmalkovich@mail.ru — Fri, 11 Jan 2008 08:21:09 GMT

Давненько я не писал в журнал и решил сделать новую запись и в ней выдать на суд общества кое-какие соображения по поводу Искусственного интеллекта (в дальнейшем ИИ).

Но начну я не с определения ИИ и не с рассмотрения существующих теорий построения ИИ, а начну я с соображений по поводу эволюционного развития и эволюционного программирования.

Введение.

Как нам известно, до сих пор так и не удалось создать действующую програмную модель интеллекта человека. Даже более того, мне неизвестно даже о существовании программной модели интеллекта таракана. По всей видимости, поведение этих структур настолько сложно, что не поддаётся существующим методам моделирования.
При всём при этом ценность программной модели интеллекта человека (ИИ) настолько велика, что если бы существующие методы позволяли его реализовать, то ИИ уже давно был бы реализован.
При всём при этом возможность построения ИИ доказывается тем, что, во-первых, интеллектов естественных построено уже порядка 6 миллиардов и это число растёт; во-вторых, существующие языки программирования позволяют реализовать любой алгоритм, а интеллект, я считаю, является алгоритмом.

Что такое эволюционное программирование.

Многие знакомы с эволюционным программированием на практике. Ещё это явление называют вуду-программированием. Так, обнаружив некую ошибку в существующей программе, неопытный программист начинает вносить изменения в код, до тех пор, пока программа не начнёт выдавать верный результат в предыдущих тестах. Недостатки этого подхода очевидны. Однако в природе эти недостатки практически исчезают...
1. Нечитаемость кода не приводит к каким-либо последствиям, потому что код читать никто не будет.
2. Размер получаемого кода не растёт, если в тестах есть предположение о минимальности решения при прочих равных.
3. Долгое время на получение положительного результата в природе никого не волнует и при малом времени жизни особи и большом числе особей время может быть значительно сокращено.
4. Появление новых ошибок в коде исключено, потому что среда предлагает полный набор тестов для выживания особи и решения всех специфических задач.
5. Смерть или ошибки одной особи не критичны. Это очень важный момент, так как в производстве смерть или ошибки конечного продукта критичны.

Каковы достоинства эволюционного программирования.

1. Самое важное достоинство: не требуется наличие программиста. Это позволяет программам создавать программы.
2. Выживают идеальные решения.
3. Наборы тестов можно варьировать в широчайших пределах.
4. Платформа для полученного кода может быть примитивной. Поддержка высокоуровневого кода не требуется.
5. Новые функции могут образовываться самопроизвольно.

Можно ли применять эволюционное программирование на практике.

В чистом виде я не представляю себе применения эволюционного программирования на практике. Но вообще, некое подобие могло бы работать например так:
- некий прибор имеет алгоритм по которому он работает;
- в алгоритм программистом вносится изменение и новый алгоритм зашивается в прибор;
- в случае "смерти" прибора или несовместимого со спецификацие функционирования старый алгоритм восстанавливается, а новый помечается как мёртвый.

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

В существующей программистской практике есть два направления, следующие из эволюционного программирования. Это системы управления версиями совместно с баг-трекерами и Test Driven Developement.

Что дальше.

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

Для этого нам надо:
1. Простую систему записи алгоритмов. Чем проще, тем лучше.
2. Хранилище алгоритма из пункта 1, взаимодействующее со средой.
3. Среда, передающая тесты хранилищам алгоритмов и управляющая разможением и смертью хранилищ
4. Источник изменчивости. Нечто, произвольно изменяющее существующие копии алгоритмов.

Мои предложения:
Для (1) взять таблицу переходов по состояния в зависимости от сигналов. Внешние сигналы определить в соответствии с задачей.
Для (2) создать простую оболочку, проходящую по состояниям (1). Получать от среды тесты, постоянно прогонять по (1) и генерировать оценку прохождения тестов. Хранить оценку по тестам.
Для (3) создать сетку N*N и поместить в каждую ячейку по экземпляру (2). Передавать тесты (2). Произвольно убивать (2). Если есть свободная ячейка, то выбирать из ближайших окружающих ячеек (2) с наилучшей оценкой по тестам и копировать (2) в свободную ячейку.
Для (4) произвольно вносить произвольные изменения в (1).

Всё это можно тактировать и можно работать. Интересно, что из этого получится? ;)

Нащёт возможности реализации ИИ через эту систему наверное в следующем выпуске... :)

Friends will be friends

johnmalkovich@mail.ru — Thu, 15 Feb 2007 12:05:05 GMT

Сегодня с удивлением обнаружил, что я являюсь чьим-то френдом... Странно. Ведь я в журнал ничего не пишу.

Видео-проектор

johnmalkovich@mail.ru — Wed, 09 Nov 2005 07:39:07 GMT

Из США я привёз видео-проектор. Оптома что-то там. И вот стоял у меня этот чёрный кирпич за штуку баксов, пылился, а я особо это дело не продвигал. Но вот, где-то через месяц приобрёл 10 метров S-Video шнура, 5 метров удлинителя и всё это дело включил. Повозился с оверлеями и оно заработало. Красота. Здоровенный экран на стенке :) Вот только экрана-то ещё и нету. Не нашёл приличного пока.

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

Маятник Фуко

johnmalkovich@mail.ru — Fri, 28 Oct 2005 19:03:21 GMT

29 октября сего года начал читать Маятник Фуко. Символика, концептуализм... Подозрительно похоже на попсового Дэна Брауна с его Кодом. Но, в то же время, язык не в пример лучше. Дерево Жизни, Сефирот... Надо бы уже ознакомиться с каббалистикой. Ерунда, конечно, по сравнению с Кастанедой, но что-то в ней есть. Все эти Кеф, Ицех. Занятица.