моя мысль — отдать максимальное количество сил при проектировании и конструировании программного обеспечения, чтобы потом при дальнейшей поддержке приложения не отдать максимальное количество нервных клеток.
Судя по вашей цели, у меня те же мысли. Только подход у нас разный. Я бы сказал, что вы ориентируетесь на оптимальные, управляемые и прогнозируемые отношения между, пусть это будет, бизнес объектами. Я к этому тоже стремлюсь, назовем проще, бизнес логике. Только для меня это следующий этап.
Сейчас меня больше интересует форма, а не содержание. Конкретно, программный интерфейс. При всей кажущейся простоте, работа с ним достаточно сложная, особенно если хочешь выйти за пределы стандарта.
Но программная логика и бизнес логика, естественно, тоже имеют значение и их тоже надо учитывать. Вы предлагаете это «продумывать» и я тоже. Концептуально, я решил использовать для этого, скажем так, временную бинарную модульность. Ее, кстати, можно делать и постоянной, если устроит производительность приложения.
Как я уже заметил, даже кажущиеся относительно независимые части приложения имеют, на самом деле, сильную связь. Разорвать которую, иначе говоря, распараллелить используемую программную модель, достаточно сложно. Но, пока, интересно. Тем более что в век потоков, субъядер и многопроцессорным систем этим сам Бог велел заниматься. Кстати, как вы управляете потоками в своем приложении?
В моей парадигме, «быстро собирать приложения», конечно, хорошо, но главное, пожалуй, не это. Важна именно логическая независимость бинарных модулей, а, следовательно, и большая легкость их отладки и тестирования. Да и разбираться, последовательно, с работой каждого модуля, все же проще, чем сразу со всем программным монолитом.
Так что разногласия наши естественны, я ни разу не встречал, человека с абсолютно похожими интересами, если только это не работа по принуждению.
P.S. Что касается моей проблемы с закрытием дочернего окна, созданного в плагине, то, скорее всего, это связано с тем, что при завершении работы приложения, не осуществляется выгрузка dll, хотя я даю команду на это. Операционная система, она ведь «умнее» программиста, она просто уменьшает счетчик ссылок на объекты этой длл и выгрузит ее не раньше, чем он обнулится. А у меня ведь плагин еще и дополнительный пункт меню из dll создает. В общем, нужен как бы мониторинг всех объектов, работающих с ресурсами длл. Да, и в теории плагинов написано, что выгрузка длл, это не тривиальная задача. Нужно ли с этими вещами разбираться? Очевидно, каждый ответит по-разному.
Если я правильно понимаю, то паттерны это алгоритмы кода высокого уровня, другими словами, идеи реализации.
WinAPI либо WTL / ATL на С++, это, в принципе, все, что мне надо. Но чтобы реализовывать там паттерны (идеи, в моем понимании), нужно понимать протоколы работы функций и компонент WinAPI, т.е., знать документацию, типа MSDN.
Вот я и споткнулся там, на «правильном» протоколе удаления дочернего окна. Документация говорит, что, в дочернем окне надо использовать вызовы: «DestroyWindow(hWnd); break;», при сообщении WM_CLOSE, и вызовы: «PostQuitMessage(0); break;», при сообщении WM_DESTROY. Но это-то как раз и приводит к краху при выходе из приложения, при открытом дочернем окне. Но если его вручную закрыть, то программа, потом, завершается нормально.
Естественно, использовал уже различные мыслимые и немыслимые варианты, как со стороны главного окна, так и со стороны «плагина». Тем более что я могу отслеживать все сообщения, и дочернего окна, и его родителя. Но все упирается в отсутствие механизма «хорошего» удаления окна (созданного в dll), во всех случаях. Иногда срабатывает и обычный способ, но не всегда.
Сейчас пытаюсь анализировать опенсорс с поддержкой плагинов. Естественно, есть какой-то нюанс, который я пока не понимаю. Но сама идея бинарной модульности для целей разработки и тестирования приложений с последующей сборкой «монолитного» проекта скриптом на Питоне, достаточно интересна. Однако, Дьявол, как всегда кроется в деталях… :)
Статья интересная и достаточно сложная для первого восприятия. Возможно, я к ней еще не раз вернусь. Но пока хочется чего-нибудь более простого и наглядного.
Я, как любитель, делал много попыток написания разного кода на С++ с фреймворками. По истечении некоторого времени, все благополучно забывалось, и надо было начинать все сначала. Поэтому решил озадачиться идеей модульного программирования, так чтобы проблемы можно было бы искать в пределах одного модуля, а не всего проекта.
Но модульность у меня двоякая. Проектирование и тестирование должно использовать бинарную модульность, практически, плагины. А конечный проект, формально монолитный, но структурно модульный, должен генерироваться автоматически из независимого кода модулей (плагинов) в общий код проекта, с помощью скрипта на Питоне.
Другими словами, сначала делаем проект, состоящий из одних плагинов и минимального главного модуля – приложения, которое автоматически загружает все наши плагины. При этом одному плагину соответствует один пункт меню (с горячими клавишами) и одно самодостаточное окно. Кроме того, плагины могут работать с клиентской частью главного окна приложения и, соответственно, не требовать горячих клавиш и меню. Также допустимы сложные плагины, которые подгружают другие зависимые от них плагины.
Но это все «теория». Начал я свои эксперименты (недавно) с самого простого варианта. Сгенерировал мастером VS C++ простейшее оконное приложение на WinAPI, содержащее всего два пункта меню: «Выход» и «О программе», которое оформил не в виде диалога, а виде дочернего окна. Последний удалил и преобразовал в виде плагина. Однако, несмотря на кажущуюся простоту, связь между главной программой и ее плагином «About», оказалась достаточно сильной. Это и общие переменные (нужно выработать стратегию по работе с ними) и конструирование объединенного меню и, главное, совместная, непротиворечивая, работа всех циклов сообщений. Здесь, как ни странно, трудности возникли с закрытием дочернего окна, в некоторых случаях происходят утечки памяти и зависание программы с ее полным крэшем.
Хотелось бы найти готовый прототип подобного примера в Интернете, но плагины там не любят работать с окнами, только с консолью. Поэтому приходится изобретать очередной велосипед самому.
Просто мне нужно то, что вам не нужно и, скорее всего, наоборот. А нужен мне, для моего проекта, легкий интерфейс. WTL идеально подходит, С / С++ достаточно удобные, привычные и мощные. Что лично мне еще надо? Можно купить еще более удобным интерфейсом, например, как в опенсорсном Win32++ ( sourceforge.net/projects/win32-framework/files ). Но там все сделано в стиле MFC (от которого я уже отвык, кстати, и сам MFC M$ сделали уже опенсорсным, но, как для меня, слишком поздно), поэтому предпочитаю оставаться на WTL.
Поэтому я все эти тёрки «лучше» / «хуже» плохо воспринимаю. Народ здесь попался какой-то обидчивый («забирай свои игрушки и не писай в мой горшок!»). Каждый работает в том, что лично ему больше нравится и больше подходит. Обсуждать, в общем-то, и нечего.
А «нас» устраивает! Тем более что проблема высосана из пальца. Не хотите C++ / WTL, используйте кроссплатформенный C++ / wxWidgets либо C++ / Qt. Какие проблемы? В любом случае, фундаментальный Си / С++ будет актуальным еще долго!
А как насчет поддержки оконного интерфейса? Консольные программы это конечно хорошо, но в мире Windows как-то более привычны «форточки». Если уж рекламировать язык программирования, то, желательно, что-нибудь GUI-ёвое.
Вот взял я недавно простую задачку. Есть код на С++ / WinAPI, сгенерированный мастером VS. Там всего ничего, окно, простое меню с выходом и диалогом о программе. Нужно в основной программе убрать пункт меню «О программе» и сам этот диалог, но взамен, написать плагин, который грузится автоматически и добавляет этот пункт и диалог либо имитацию его в виде обычного окна. Как бы задача, проще некуда, но сложностей достаточно много. Уже где-то процентов на 80, реализовал эту задачу, но вариантов ее улучшения еще более, чем.
«Берем произвольную страницу французско-английского онлайн-словаря, например, www.larousse.fr/dictionnaires/francais-anglais/passer/661830. Ее можно предварительно скачать на компьютер. Требуется извлечь все данные (слова, транскрипцию, грамматические категории, фразы, идентификаторы звуковых файлов, ссылки на таблицы спряжений французского языка (для английского не надо), наименования тем и топиков словарных статей, в виде текстового файла, например, типа json. Годится и обычный текстовый файл, с отступами для уровней, именами для элементов данных (выбираются произвольно, но разным типам данных должны соответствовать разные имена, а одинаковым – одинаковые) и разделителями для разных записей (содержащих определенную группу данных) одного уровня.»
и достаточно времени для решения. Если справится, то будет программистом, если нет, останется техническим кодером, как сейчас. Использовать он может что угодно и сколько угодно, в том числе помощь других, главное, чтобы понимал смысл результата.
Я тоже думал, что проще: программирование или литературное творчество? В итоге пришел к мнению, что программирование. По крайней мере, для людей, с техническим складом ума.
Но в чем именно сложность писательства?
Для себя я ответил, что в большей степени свободы и соответственно большей неопределенности. Отсюда даже получил парадоксальный вывод, в стиле Оруэлла, что свобода это ограничения!
Действительно, в программировании, ты скован массой ограничений, но это, обычно, не напрягает (в случае чего, всегда можно сменить платформу программирования). В литературе, теоретически, нет ограничений, пиши что хочешь, о чем хочешь и как хочешь. Однако это вызывает ступор и два классических вопроса: «О чем писать?» и «Как писать?». Ну, и что важнее?
В программировании, вопрос «Как писать?» не стоит. Там все определяется технологией языка. Что писать, в смысле, какую именно задачу реализовывать, выбирать как-то проще. Просто смотришь, какие задачи еще не решены либо решены не слишком хорошо (в понимании программиста) и с какой задачей ты в состоянии справится. Ею и занимаешься.
В литературе, понятия «реализации задачи» как бы нет. Ну, а то, что писатель формулирует для себя как «задачу», сразу упирается в вопрос, а как ее решать в принципе? Поэтому, для непрофессиональных литераторов, как мне кажется, «как писать» куда важнее, чем «что писать». Просто потому, что в литературе нет явной технологии творчества. Хотя, допускаю, что если есть ТРИЗ / АРИЗ (технология решения изобретательских задач / алгоритм решения изобретательских задач) Г.А. Альтшуллера, то и, где-то в недрах Голливуда, есть, если не технология литературного творчества (ТЛЧ), то технология создания сюжетов фильмов и сценариев, поставленная на поток. А сейчас еще и «Искусственный Интеллект» напрашивается.
Кстати, можно спросить, а в чем принципиальная разница между литературным творчеством и программированием?
Смотрим, принципиально, программирование это:
1. Код.
2. Реализация исполнения этого кода, например, в компьютере.
3. Потребитель результата.
Для литературы:
1. Литературный текст, и как код и как реализация этого кода.
2. Потребитель результата.
Под реализацией кода литературного текста я понимаю генерацию логически связанного и последовательного воображения у читателя («производство впечатлений», как ныне говорят).
Вот, представьте себе, что нет компьютеров. Легко ли было бы реализовывать программистские алгоритмы? Так и в литературе. Инструмента для «производства впечатлений» там нет, все должен делать сам текст, который вполне можно воспринимать как литературный код. Вплоть до того, что даже возможна постановка задачи по декомпиляции литературного кода (с целью выявления секретов литературных мастеров). Но это уже отдельная задача, очень непростая, даже для ИИ.
Ну, а теперь, по вопросу, что писать? Для этого надо, сначала, ответить на вопрос, а что такое литература, в технологическом смысле?
Современные генераторы текстов, на базе ИИ, заточены на, скажем так, вероятностное копирование. Т.е., из сверхбольшой базы данных выбирается наиболее вероятное, для предыдущего созданного текста, продолжение. Понятно, что здесь нужна, начальная точка отсчета, например, некоторая осмысленная фраза. Далее компьютер генерирует, наиболее вероятное по смыслу, но оригинальное по тексту, продолжение. Иногда, даже получается ничего. Со временем здесь явно будет какой-то прогресс.
Однако, с моей точки зрения, литература, технически, это процесс отражения действительности в мозге наблюдателя, который эти свои мысли преобразует в текст. Тем самым, литература глубоко субъективна. Иной раз даже не знаешь, чего ты узнаешь больше в чтении книг, новой информации или личностного эмоционального и ментального отпечатка автора. Есть, конечно, и безличностные документы, составленные группой авторов, например, Конституция, но там, скорее, присутствует коллективный эмоциональный след.
В итоге, вопросы: «Что писать?» и «Как писать?» остаются открытыми, что говорит о том, что тема литературного творчества – неисчерпаемая.
Тем не менее, можно предложить концепцию универсального литературного сюжета (и его обобщение):
Особое событие порождает необычный процесс с непредсказуемым результатом.
которое я сформулировал в статье ««Hello, World!» для начинающих литераторов» ( habr.com/ru/post/342512 ).
Часто доходило до крайностей — вопросы возникали такие, которые можно было нагуглить за 1-2 минуты, а ответ было в первых пяти ссылках на первой странице поисковика.
У меня лично нет возможности ни у кого ничего спросить, поскольку рядом нет программистов вообще. Однако к Гуглу у меня отношение двоякое. С одной стороны там можно нарыть много чего интересного, а с другой, на простейшие вопросы часто нет ответов по существу, вплоть до того, что приходится изобретать велосипед самостоятельно.
Пару примеров. Понадобились мне обычные меню в дочерних окнах. Как это сделать с помощью C++ / WTL? Перерыл весь интернет, ничего путного не нашел, кроме одной случайной фразы, где-то в комментариях по вопросу на аналогичную тему. Однако пока довел дело до практической реализации, без явных глюков, пришлось повозиться. Просто, M$ в свое время решил, что локальных меню, в подчиненных окнах, быть не должно в принципе, это блокируется на уровне системных библиотек. Контекстные меню – пожалуйста, эмуляция с помощью кнопок – то же, можно даже наваять собственное меню с нуля, но это все было явно не то.
Потом захотелось портировать опенсорсный консольный видеопроигрыватель FFplay.c в виндоуз приложение. Просто поменять main() на WinMain() не выйдет, ну, не любят линусоиды «форточки». Опять же, пришлось хорошо повозиться, пока удалось реализовать задуманное и даже поместить проигрыватель в отдельный поток.
Теперь вот кинулся делать плагины к своей собственной программе (чтобы реализовать идею бинарной модульности). Думал, тема то проходная, опенсорса тут валом, информации должно быть тоже. Однако болт! Кое-что есть, естественно, как же без этого, но так чтобы найти подходящий прототип это сами, сами, сами. Главные проблемы – во взаимодействии различных циклов сообщений (поскольку в dll реализуются дочерние окна). Но, постепенно, собственный велосипед получается и здесь.
Иногда думаю, как было бы здорово, если бы кто-то был рядом, кто мог бы ответить на все мои вопросы по программированию! Эффективность процесса программирования возросла бы на порядок.
интервальное повторение фрагментов видео для изучения иностранных языков
Ну, я называю это «повторы и паузы». Я для этого брал видео с внешними субтитрами и с помощью, написанной на Питоне программе, создавал скрипты, типа *.ssa и *.pdf для проигрывателя PotPlayer. Первый скрипт отвечал за вывод двуязычных субтитров, нужного цвета, размеров и положения (перевод делал с помощью Гугл-переводчика), а второй – организовывал повторы и паузы. Думал даже опубликовать здесь статью на эту тему, но практическая проверка эффективности метода на себе показала его не очень высокую эффективность. Да и PotPlayer иногда глючил с повторами и паузами.
После этого решил делать пересборку оригинального видео, в разных вариантах, так чтобы не заморачиваться со криптами PotPlayer, а сразу наблюдать результат в любом видео проигрывателе. Этот вариант мне понравился больше, примеры моих экспериментов (для изучения французского языка) можно посмотреть на Видео.майл.ру: my.mail.ru/mail/emmerald/video/_myvideo.
Однако и здесь, эффективность оказалось не очень высокой. Да, после просмотра видео роликов десятки раз, слова и фразы начинают уже сниться по ночам. Однако оказалось, что смотреть материалы с повторами и паузами быстро надоедает. Практический смысл имеют только оригинальные ролики и те же ролики, с двуязычными субтитрами.
Постепенно пришел к пониманию, что нужна обучающая программа для работы с интерактивным звуком. Прототип подобной программы есть на моем сайте: scholium.webservis.ru. Но та программа очень древняя, поэтому начал писать ее современный аналог на C++ / WTL. Большая ее часть уже сделана, но пока еще не закончена. Плюс предстоит большая работа с данными, но это отдельный разговор.
Я сам вряд ли смогу работать в команде, даже если «энтузиасты» будут. А то, что никого «не вдохновляет», это нормально. Меня тоже чужие проекты мало радуют. Главное, что нравится лично мне. Единственный смысл в подобной публичной переписке я вижу только в одном, что найдется некто, у кого будет достаточно сил, знаний и желаний, чтобы реализовать собственный проект а-ля 1С77 либо аналогичный, именно так, как он это понимает. А мы просто посмотрим на готовое. Понравится, будем использовать, не понравится, не будем – какие проблемы? А я всего лишь любитель, работаю в этом направлении только потому, что профессионалы не хотят этим заниматься, а чем они хотят, мне не нравится.
P.S. Вот, посмотрите: sourceforge.net/projects/wt-erp-crm и соответствующее видео: www.youtube.com/watch?v=U8E25nlTBqM. Может быть, вас такого рода приложения интересуют? Ниже дан перевод Гугла:
WTERP – это полностью бесплатное программное обеспечение, которое очень подходит для управления малым бизнесом. Который разработан на C # /. Net. IIS WebService и версия SQL Server Community бесплатной среды и базы данных в среде приложений на основе WinForm, включая серверную веб-службу, основную программную структуру, организационную структуру, контроль полномочий, навигацию по меню, основные данные, системные параметры, управление журналами, задачи синхронизации, WTERP включает корпоративные CRM, SD, MM, WM, OA, HR, Workflow и другие информационные системы и призван помочь пользователям улучшить управление.
Функции
• Классы, студент, Управление регистрацией
• Контакты, управление клиентами и поставщиками
• Управление квитанциями и счетами
• Управление заказами
• Управление контрактами
• Управление бронированием аудитории / суда
• Управление сотрудниками
• Управление рабочим процессом
• Расписания
• Управление запасами
• Множество других внешних модулей (технические интерфейсы или бизнес-функции)
Почему стоит начать изучение программирования с языка C
А почему не с ассемблера? Хотя бы на уровне erfaren.narod.ru. Кстати, «народный» дизассемблер IdaPro, Ильфака Гильфанова, позволяет переводить ассемблерный бинарный код, типа dll и exe-файлов, в Си код.
Тем не менее, я лично предпочитаю С++, поскольку на этом языке можно проще и удобней организовать модульность. Для примера возьмем опенсорсный консольный видеопроигрыватель FFPlay.c и пробуем его внедрить в собственное оконное приложение. Я, лично, пока не перевел этот код в классы, не мог решить подобную проблему.
С другой стороны, Си-код SQLite ни в какие классы переводить не нужно. Оно и понятно, это не оконное приложение, а консольное, поэтом просто внедряем его в свой С++ проект и все прекрасно работает без «напильника».
Короче говоря, для общего развития, ассемблер и Си нужны, но не более. Для серьезной работы хорош С++. А для разовой подготовки (обработки) данных очень эффективен Питон и другие скриптовые языки. Однако краеугольным камнем программирования я считаю С++.
Там репликация идет между базами, а не на каждый компьютер-клиент.
Я ведь не собираюсь делать один в один. Скорее, это будет похоже на планы обмена в «восьмерке».
1. Использовать SQL-сервер, самые тяжелые вычисления будут на нем.
Это хорошо для корпоративного сектора, для малых и средних предприятий можно выбрать вариант попроще.
2. Все вычисления делать на сервере, тогда не нужен терминал, так работает Фузина.
Не очень понятно отличие от первого варианта. Какие именно вычисления? Запросы? Или вычисления, типа, расчета зарплаты?
Да, расчет зарплаты нужно делать на сервере, а клиентам реплицировать нужные им результаты. Однако вопрос с запросами остается. У меня будет два вида запросов: локальные и глобальные. Если данных на локальном компьютере достаточно, например, табельная анализирует рабочее время сотрудников, а кадры, делают выборку по данным сотрудников, то им нет необходимости обращаться к серверу. А вот общие запросы для бухгалтерии или там регламентной отчетности могут потребовать информации с сервера (поскольку именно там будет находиться наиболее полная и релевантная база данных). Он их и будет делать. Только вот движок базы данных везде будет легким – SQLite для индексов и MMF для навигации по данным. Если его станет недостаточно, то тогда нужно будет переходить к другому классу задач и другой программе. Если этим и заниматься, то не ранее, чем после создания простейшей учетной платформы.
А Фузина мне не нравится из-за интерфейса. Ну не люблю я веб-интерфейс. Предпочитаю WTL-интерфейс. Да и вообще, вести учет в браузере это явно не мое, только на десктопе.
Была (есть) официальная компонента 1С77 – УРБД, которая как раз делает репликации. Да, коряво, через одно пикантное место, но делает.
А работа с «семеркой», по сети, как с файл-сервером, практически неэффективна, если пользователей больше трех и более-менее приличная база. Выход только с помощью терминал-сервера. Тогда и база может быть поприличней и пользователей больше десяти, на том же оборудовании.
Я же говорил, что хуже, чем платформа 1С77 не должно быть. По крайней мере, «семерка» это прототип, на который можно ориентироваться.
Вопросы могут быть только по рознице. Но, у меня почти нет опыта работы в этой сфере. Немного, по касательной, занимался автоматизацией аптек. Когда будет готова программа, можно будет вернуться к старым клиентам, для тестовых экспериментов в их области учета.
Это верно для бумажных словарей, просто для типографий это большой напряг, печатать транскрипцию. А так, да, есть целые справочники, посвященные только правилам чтения, но там десятки слов исключений чуть ли не для каждого правила.
Однако есть и хорошая новость. Онлайн-словари. Там могут быть транскрипции для всех слов, без исключения. Смотрите, например, www.larousse.fr/dictionnaires/francais-anglais/passer/661830, для самого «объемного» французского слова «passer». Причем транскрипция приведена для каждой грамматической категории и, особый плюс, все слова и фразы имеют озвучку.
Да, на этом сайте нет словарей с русским языком, но русская озвучка нам и не нужна, а перевод слов и фраз можно сделать в переводчике Гугла. Да это долго, но быстрее слова и фразы вы все равно не запомните.
Более того, в Интернете можно найти и готовые базы данных словарей с транскрипцией (типа, французско-английского). Там надо немного повозиться с извлечением данных, но составить, в итоге, собственный, полный электронный французско-русский словарь вполне по силам.
Судя по вашей цели, у меня те же мысли. Только подход у нас разный. Я бы сказал, что вы ориентируетесь на оптимальные, управляемые и прогнозируемые отношения между, пусть это будет, бизнес объектами. Я к этому тоже стремлюсь, назовем проще, бизнес логике. Только для меня это следующий этап.
Сейчас меня больше интересует форма, а не содержание. Конкретно, программный интерфейс. При всей кажущейся простоте, работа с ним достаточно сложная, особенно если хочешь выйти за пределы стандарта.
Но программная логика и бизнес логика, естественно, тоже имеют значение и их тоже надо учитывать. Вы предлагаете это «продумывать» и я тоже. Концептуально, я решил использовать для этого, скажем так, временную бинарную модульность. Ее, кстати, можно делать и постоянной, если устроит производительность приложения.
Как я уже заметил, даже кажущиеся относительно независимые части приложения имеют, на самом деле, сильную связь. Разорвать которую, иначе говоря, распараллелить используемую программную модель, достаточно сложно. Но, пока, интересно. Тем более что в век потоков, субъядер и многопроцессорным систем этим сам Бог велел заниматься. Кстати, как вы управляете потоками в своем приложении?
В моей парадигме, «быстро собирать приложения», конечно, хорошо, но главное, пожалуй, не это. Важна именно логическая независимость бинарных модулей, а, следовательно, и большая легкость их отладки и тестирования. Да и разбираться, последовательно, с работой каждого модуля, все же проще, чем сразу со всем программным монолитом.
Так что разногласия наши естественны, я ни разу не встречал, человека с абсолютно похожими интересами, если только это не работа по принуждению.
P.S. Что касается моей проблемы с закрытием дочернего окна, созданного в плагине, то, скорее всего, это связано с тем, что при завершении работы приложения, не осуществляется выгрузка dll, хотя я даю команду на это. Операционная система, она ведь «умнее» программиста, она просто уменьшает счетчик ссылок на объекты этой длл и выгрузит ее не раньше, чем он обнулится. А у меня ведь плагин еще и дополнительный пункт меню из dll создает. В общем, нужен как бы мониторинг всех объектов, работающих с ресурсами длл. Да, и в теории плагинов написано, что выгрузка длл, это не тривиальная задача. Нужно ли с этими вещами разбираться? Очевидно, каждый ответит по-разному.
WinAPI либо WTL / ATL на С++, это, в принципе, все, что мне надо. Но чтобы реализовывать там паттерны (идеи, в моем понимании), нужно понимать протоколы работы функций и компонент WinAPI, т.е., знать документацию, типа MSDN.
Вот я и споткнулся там, на «правильном» протоколе удаления дочернего окна. Документация говорит, что, в дочернем окне надо использовать вызовы: «DestroyWindow(hWnd); break;», при сообщении WM_CLOSE, и вызовы: «PostQuitMessage(0); break;», при сообщении WM_DESTROY. Но это-то как раз и приводит к краху при выходе из приложения, при открытом дочернем окне. Но если его вручную закрыть, то программа, потом, завершается нормально.
Естественно, использовал уже различные мыслимые и немыслимые варианты, как со стороны главного окна, так и со стороны «плагина». Тем более что я могу отслеживать все сообщения, и дочернего окна, и его родителя. Но все упирается в отсутствие механизма «хорошего» удаления окна (созданного в dll), во всех случаях. Иногда срабатывает и обычный способ, но не всегда.
Сейчас пытаюсь анализировать опенсорс с поддержкой плагинов. Естественно, есть какой-то нюанс, который я пока не понимаю. Но сама идея бинарной модульности для целей разработки и тестирования приложений с последующей сборкой «монолитного» проекта скриптом на Питоне, достаточно интересна. Однако, Дьявол, как всегда кроется в деталях… :)
Я, как любитель, делал много попыток написания разного кода на С++ с фреймворками. По истечении некоторого времени, все благополучно забывалось, и надо было начинать все сначала. Поэтому решил озадачиться идеей модульного программирования, так чтобы проблемы можно было бы искать в пределах одного модуля, а не всего проекта.
Но модульность у меня двоякая. Проектирование и тестирование должно использовать бинарную модульность, практически, плагины. А конечный проект, формально монолитный, но структурно модульный, должен генерироваться автоматически из независимого кода модулей (плагинов) в общий код проекта, с помощью скрипта на Питоне.
Другими словами, сначала делаем проект, состоящий из одних плагинов и минимального главного модуля – приложения, которое автоматически загружает все наши плагины. При этом одному плагину соответствует один пункт меню (с горячими клавишами) и одно самодостаточное окно. Кроме того, плагины могут работать с клиентской частью главного окна приложения и, соответственно, не требовать горячих клавиш и меню. Также допустимы сложные плагины, которые подгружают другие зависимые от них плагины.
Но это все «теория». Начал я свои эксперименты (недавно) с самого простого варианта. Сгенерировал мастером VS C++ простейшее оконное приложение на WinAPI, содержащее всего два пункта меню: «Выход» и «О программе», которое оформил не в виде диалога, а виде дочернего окна. Последний удалил и преобразовал в виде плагина. Однако, несмотря на кажущуюся простоту, связь между главной программой и ее плагином «About», оказалась достаточно сильной. Это и общие переменные (нужно выработать стратегию по работе с ними) и конструирование объединенного меню и, главное, совместная, непротиворечивая, работа всех циклов сообщений. Здесь, как ни странно, трудности возникли с закрытием дочернего окна, в некоторых случаях происходят утечки памяти и зависание программы с ее полным крэшем.
Хотелось бы найти готовый прототип подобного примера в Интернете, но плагины там не любят работать с окнами, только с консолью. Поэтому приходится изобретать очередной велосипед самому.
Поэтому я все эти тёрки «лучше» / «хуже» плохо воспринимаю. Народ здесь попался какой-то обидчивый («забирай свои игрушки и не писай в мой горшок!»). Каждый работает в том, что лично ему больше нравится и больше подходит. Обсуждать, в общем-то, и нечего.
Согласен!
Вот взял я недавно простую задачку. Есть код на С++ / WinAPI, сгенерированный мастером VS. Там всего ничего, окно, простое меню с выходом и диалогом о программе. Нужно в основной программе убрать пункт меню «О программе» и сам этот диалог, но взамен, написать плагин, который грузится автоматически и добавляет этот пункт и диалог либо имитацию его в виде обычного окна. Как бы задача, проще некуда, но сложностей достаточно много. Уже где-то процентов на 80, реализовал эту задачу, но вариантов ее улучшения еще более, чем.
Я бы дал ему задачу для Питона:
«Берем произвольную страницу французско-английского онлайн-словаря, например, www.larousse.fr/dictionnaires/francais-anglais/passer/661830. Ее можно предварительно скачать на компьютер. Требуется извлечь все данные (слова, транскрипцию, грамматические категории, фразы, идентификаторы звуковых файлов, ссылки на таблицы спряжений французского языка (для английского не надо), наименования тем и топиков словарных статей, в виде текстового файла, например, типа json. Годится и обычный текстовый файл, с отступами для уровней, именами для элементов данных (выбираются произвольно, но разным типам данных должны соответствовать разные имена, а одинаковым – одинаковые) и разделителями для разных записей (содержащих определенную группу данных) одного уровня.»
и достаточно времени для решения. Если справится, то будет программистом, если нет, останется техническим кодером, как сейчас. Использовать он может что угодно и сколько угодно, в том числе помощь других, главное, чтобы понимал смысл результата.
Но в чем именно сложность писательства?
Для себя я ответил, что в большей степени свободы и соответственно большей неопределенности. Отсюда даже получил парадоксальный вывод, в стиле Оруэлла, что свобода это ограничения!
Действительно, в программировании, ты скован массой ограничений, но это, обычно, не напрягает (в случае чего, всегда можно сменить платформу программирования). В литературе, теоретически, нет ограничений, пиши что хочешь, о чем хочешь и как хочешь. Однако это вызывает ступор и два классических вопроса: «О чем писать?» и «Как писать?». Ну, и что важнее?
В программировании, вопрос «Как писать?» не стоит. Там все определяется технологией языка. Что писать, в смысле, какую именно задачу реализовывать, выбирать как-то проще. Просто смотришь, какие задачи еще не решены либо решены не слишком хорошо (в понимании программиста) и с какой задачей ты в состоянии справится. Ею и занимаешься.
В литературе, понятия «реализации задачи» как бы нет. Ну, а то, что писатель формулирует для себя как «задачу», сразу упирается в вопрос, а как ее решать в принципе? Поэтому, для непрофессиональных литераторов, как мне кажется, «как писать» куда важнее, чем «что писать». Просто потому, что в литературе нет явной технологии творчества. Хотя, допускаю, что если есть ТРИЗ / АРИЗ (технология решения изобретательских задач / алгоритм решения изобретательских задач) Г.А. Альтшуллера, то и, где-то в недрах Голливуда, есть, если не технология литературного творчества (ТЛЧ), то технология создания сюжетов фильмов и сценариев, поставленная на поток. А сейчас еще и «Искусственный Интеллект» напрашивается.
Кстати, можно спросить, а в чем принципиальная разница между литературным творчеством и программированием?
Смотрим, принципиально, программирование это:
1. Код.
2. Реализация исполнения этого кода, например, в компьютере.
3. Потребитель результата.
Для литературы:
1. Литературный текст, и как код и как реализация этого кода.
2. Потребитель результата.
Под реализацией кода литературного текста я понимаю генерацию логически связанного и последовательного воображения у читателя («производство впечатлений», как ныне говорят).
Вот, представьте себе, что нет компьютеров. Легко ли было бы реализовывать программистские алгоритмы? Так и в литературе. Инструмента для «производства впечатлений» там нет, все должен делать сам текст, который вполне можно воспринимать как литературный код. Вплоть до того, что даже возможна постановка задачи по декомпиляции литературного кода (с целью выявления секретов литературных мастеров). Но это уже отдельная задача, очень непростая, даже для ИИ.
Ну, а теперь, по вопросу, что писать? Для этого надо, сначала, ответить на вопрос, а что такое литература, в технологическом смысле?
Современные генераторы текстов, на базе ИИ, заточены на, скажем так, вероятностное копирование. Т.е., из сверхбольшой базы данных выбирается наиболее вероятное, для предыдущего созданного текста, продолжение. Понятно, что здесь нужна, начальная точка отсчета, например, некоторая осмысленная фраза. Далее компьютер генерирует, наиболее вероятное по смыслу, но оригинальное по тексту, продолжение. Иногда, даже получается ничего. Со временем здесь явно будет какой-то прогресс.
Однако, с моей точки зрения, литература, технически, это процесс отражения действительности в мозге наблюдателя, который эти свои мысли преобразует в текст. Тем самым, литература глубоко субъективна. Иной раз даже не знаешь, чего ты узнаешь больше в чтении книг, новой информации или личностного эмоционального и ментального отпечатка автора. Есть, конечно, и безличностные документы, составленные группой авторов, например, Конституция, но там, скорее, присутствует коллективный эмоциональный след.
В итоге, вопросы: «Что писать?» и «Как писать?» остаются открытыми, что говорит о том, что тема литературного творчества – неисчерпаемая.
Тем не менее, можно предложить концепцию универсального литературного сюжета (и его обобщение):
Особое событие порождает необычный процесс с непредсказуемым результатом.
которое я сформулировал в статье ««Hello, World!» для начинающих литераторов» ( habr.com/ru/post/342512 ).
У меня лично нет возможности ни у кого ничего спросить, поскольку рядом нет программистов вообще. Однако к Гуглу у меня отношение двоякое. С одной стороны там можно нарыть много чего интересного, а с другой, на простейшие вопросы часто нет ответов по существу, вплоть до того, что приходится изобретать велосипед самостоятельно.
Пару примеров. Понадобились мне обычные меню в дочерних окнах. Как это сделать с помощью C++ / WTL? Перерыл весь интернет, ничего путного не нашел, кроме одной случайной фразы, где-то в комментариях по вопросу на аналогичную тему. Однако пока довел дело до практической реализации, без явных глюков, пришлось повозиться. Просто, M$ в свое время решил, что локальных меню, в подчиненных окнах, быть не должно в принципе, это блокируется на уровне системных библиотек. Контекстные меню – пожалуйста, эмуляция с помощью кнопок – то же, можно даже наваять собственное меню с нуля, но это все было явно не то.
Потом захотелось портировать опенсорсный консольный видеопроигрыватель FFplay.c в виндоуз приложение. Просто поменять main() на WinMain() не выйдет, ну, не любят линусоиды «форточки». Опять же, пришлось хорошо повозиться, пока удалось реализовать задуманное и даже поместить проигрыватель в отдельный поток.
Теперь вот кинулся делать плагины к своей собственной программе (чтобы реализовать идею бинарной модульности). Думал, тема то проходная, опенсорса тут валом, информации должно быть тоже. Однако болт! Кое-что есть, естественно, как же без этого, но так чтобы найти подходящий прототип это сами, сами, сами. Главные проблемы – во взаимодействии различных циклов сообщений (поскольку в dll реализуются дочерние окна). Но, постепенно, собственный велосипед получается и здесь.
Иногда думаю, как было бы здорово, если бы кто-то был рядом, кто мог бы ответить на все мои вопросы по программированию! Эффективность процесса программирования возросла бы на порядок.
Ну, я называю это «повторы и паузы». Я для этого брал видео с внешними субтитрами и с помощью, написанной на Питоне программе, создавал скрипты, типа *.ssa и *.pdf для проигрывателя PotPlayer. Первый скрипт отвечал за вывод двуязычных субтитров, нужного цвета, размеров и положения (перевод делал с помощью Гугл-переводчика), а второй – организовывал повторы и паузы. Думал даже опубликовать здесь статью на эту тему, но практическая проверка эффективности метода на себе показала его не очень высокую эффективность. Да и PotPlayer иногда глючил с повторами и паузами.
После этого решил делать пересборку оригинального видео, в разных вариантах, так чтобы не заморачиваться со криптами PotPlayer, а сразу наблюдать результат в любом видео проигрывателе. Этот вариант мне понравился больше, примеры моих экспериментов (для изучения французского языка) можно посмотреть на Видео.майл.ру: my.mail.ru/mail/emmerald/video/_myvideo.
Однако и здесь, эффективность оказалось не очень высокой. Да, после просмотра видео роликов десятки раз, слова и фразы начинают уже сниться по ночам. Однако оказалось, что смотреть материалы с повторами и паузами быстро надоедает. Практический смысл имеют только оригинальные ролики и те же ролики, с двуязычными субтитрами.
Постепенно пришел к пониманию, что нужна обучающая программа для работы с интерактивным звуком. Прототип подобной программы есть на моем сайте: scholium.webservis.ru. Но та программа очень древняя, поэтому начал писать ее современный аналог на C++ / WTL. Большая ее часть уже сделана, но пока еще не закончена. Плюс предстоит большая работа с данными, но это отдельный разговор.
P.S. Вот, посмотрите: sourceforge.net/projects/wt-erp-crm и соответствующее видео: www.youtube.com/watch?v=U8E25nlTBqM. Может быть, вас такого рода приложения интересуют? Ниже дан перевод Гугла:
WTERP – это полностью бесплатное программное обеспечение, которое очень подходит для управления малым бизнесом. Который разработан на C # /. Net. IIS WebService и версия SQL Server Community бесплатной среды и базы данных в среде приложений на основе WinForm, включая серверную веб-службу, основную программную структуру, организационную структуру, контроль полномочий, навигацию по меню, основные данные, системные параметры, управление журналами, задачи синхронизации, WTERP включает корпоративные CRM, SD, MM, WM, OA, HR, Workflow и другие информационные системы и призван помочь пользователям улучшить управление.
Функции
• Классы, студент, Управление регистрацией
• Контакты, управление клиентами и поставщиками
• Управление квитанциями и счетами
• Управление заказами
• Управление контрактами
• Управление бронированием аудитории / суда
• Управление сотрудниками
• Управление рабочим процессом
• Расписания
• Управление запасами
• Множество других внешних модулей (технические интерфейсы или бизнес-функции)
А почему не с ассемблера? Хотя бы на уровне erfaren.narod.ru. Кстати, «народный» дизассемблер IdaPro, Ильфака Гильфанова, позволяет переводить ассемблерный бинарный код, типа dll и exe-файлов, в Си код.
Тем не менее, я лично предпочитаю С++, поскольку на этом языке можно проще и удобней организовать модульность. Для примера возьмем опенсорсный консольный видеопроигрыватель FFPlay.c и пробуем его внедрить в собственное оконное приложение. Я, лично, пока не перевел этот код в классы, не мог решить подобную проблему.
С другой стороны, Си-код SQLite ни в какие классы переводить не нужно. Оно и понятно, это не оконное приложение, а консольное, поэтом просто внедряем его в свой С++ проект и все прекрасно работает без «напильника».
Короче говоря, для общего развития, ассемблер и Си нужны, но не более. Для серьезной работы хорош С++. А для разовой подготовки (обработки) данных очень эффективен Питон и другие скриптовые языки. Однако краеугольным камнем программирования я считаю С++.
Я ведь не собираюсь делать один в один. Скорее, это будет похоже на планы обмена в «восьмерке».
Это хорошо для корпоративного сектора, для малых и средних предприятий можно выбрать вариант попроще.
Не очень понятно отличие от первого варианта. Какие именно вычисления? Запросы? Или вычисления, типа, расчета зарплаты?
Да, расчет зарплаты нужно делать на сервере, а клиентам реплицировать нужные им результаты. Однако вопрос с запросами остается. У меня будет два вида запросов: локальные и глобальные. Если данных на локальном компьютере достаточно, например, табельная анализирует рабочее время сотрудников, а кадры, делают выборку по данным сотрудников, то им нет необходимости обращаться к серверу. А вот общие запросы для бухгалтерии или там регламентной отчетности могут потребовать информации с сервера (поскольку именно там будет находиться наиболее полная и релевантная база данных). Он их и будет делать. Только вот движок базы данных везде будет легким – SQLite для индексов и MMF для навигации по данным. Если его станет недостаточно, то тогда нужно будет переходить к другому классу задач и другой программе. Если этим и заниматься, то не ранее, чем после создания простейшей учетной платформы.
А Фузина мне не нравится из-за интерфейса. Ну не люблю я веб-интерфейс. Предпочитаю WTL-интерфейс. Да и вообще, вести учет в браузере это явно не мое, только на десктопе.
А работа с «семеркой», по сети, как с файл-сервером, практически неэффективна, если пользователей больше трех и более-менее приличная база. Выход только с помощью терминал-сервера. Тогда и база может быть поприличней и пользователей больше десяти, на том же оборудовании.
Вопросы могут быть только по рознице. Но, у меня почти нет опыта работы в этой сфере. Немного, по касательной, занимался автоматизацией аптек. Когда будет готова программа, можно будет вернуться к старым клиентам, для тестовых экспериментов в их области учета.
Однако есть и хорошая новость. Онлайн-словари. Там могут быть транскрипции для всех слов, без исключения. Смотрите, например, www.larousse.fr/dictionnaires/francais-anglais/passer/661830, для самого «объемного» французского слова «passer». Причем транскрипция приведена для каждой грамматической категории и, особый плюс, все слова и фразы имеют озвучку.
Да, на этом сайте нет словарей с русским языком, но русская озвучка нам и не нужна, а перевод слов и фраз можно сделать в переводчике Гугла. Да это долго, но быстрее слова и фразы вы все равно не запомните.
Более того, в Интернете можно найти и готовые базы данных словарей с транскрипцией (типа, французско-английского). Там надо немного повозиться с извлечением данных, но составить, в итоге, собственный, полный электронный французско-русский словарь вполне по силам.