Картинка не очень радостная. Раньше злодейство ограничивалось естественным слабоумием злодеев, теперь у них есть доступ к технологическим костылям, дающим им невиданные возможности - BigData + LLM + космические вычислительные мощности. Уверен, они сразу же попытаются сделать мир лучше, ведь они всегда к этому стремились, правда ведь? Я перестал в этом сомневаться, когда язык запросов google стал настолько совершенен, что потерял способность сортировать результаты запроса по дате.
Спасибо за интересную статью. Перепробовал разные способы ведения своей базы знаний, долго обдумывал разработку своей программы, но остановился базе знаний, построенной вокруг обычной файловой системы (каталоги, текстовые файлы, иногда - html файлы), как наиболее универсальной для переноса между устройствами и с возможностью доступа без всяких средств, кроме текстового редактора.
Да, но можно использовать те пути, что предлагает теория:
Сообщение достаточно большой жопе дополнительного кванта, влекущего за собой телепортацию жопы на вышестоящий уровень
Декомпозицию жопы умелым групповым наскоком, что приводит к увеличению их количества, но уменьшению частного жопного потенциала, позволяющего спихнуть всё это скопом ниже по уровню
Когда-то давным давно, в одной далёкой галактике, существовало такое понятие как "общественный договор" и такие дикие традиции, как право на самостоятельную оценку полезности, достоверности и истинности той или иной информации для лиц, не поражённых в гражданских правах. Дико.
Теперь в этой галактике всё гораздо более правильно. Теперь оценку осуществляет не разумное существо, наделённое обществом полномочиями и ответственностью, а абстрактный математический алгоритм, не имеющий ни полномочий, ни ответственности, ни даже способностью осознать анализируемое высказывание. Как и полной неспособностью ту или иную оценку аргументировать.
А какие проблемы с программированием контролов на WinAPI?
Используете функцию RegisterClassEx, создаёте окно класса CHILD, во флагах указываете, что оно само себя рисует, не имеет оформления и в процедуре окна рисуете и отрабатываете всё что вам надо. Можно запихать таких окон сколько угодно в библиотеку и получится ещё один набор пользовательских элементов управления.
Это очень просто и недорго. Я так делал из интереса на чистом асме когда ещё masm'ом и tasm'ом баловался во времена динозавров (на XP точно работало). Советую найти и скачать win32api_big.chm файл, там весь API очень удобно собран и документирован, работать ничуть не сложнее чем с QT или GTK.
Трудно с этим согласиться. Если ваша задача - извлечь из текста информацию максимально быстро, то разумно выбрать текст с минимальным количеством воды при прочих равных условиях.
Если же ваша задача и интерес - сам процесс чтения, тогда разумно сделать обратный выбор при тех же ограничениях.
Поэтому статья на две страницы будет гарантированно прочитана по-диагонали или опущена вовсе. А заметка в два абзаца - почти наверняка будет прочитана полностью, если там будет хотя бы одно ключевое слово.
Всё-таки чтение как информационный процесс отличается от чтения для развлечения. Но даже здесь - короткие анекдоты всегда самые лучшие :)
Да, здорово. Я так прикинул, батарея ~ МВт*ч и весом ~ 4 тонны. 37 тонн груза + 4 тонны батарея, плюс тонн 7-8 сам тягач. Итого, 20 кВт*ч на тонну. В принципе, вполне себе реально.
На мой взгляд, прекрасные рекомендации, сам пользуюсь и много раз убедился в эффективности этих методов даже для людей вроде меня, с памятью, как у дрозофилы.
Всего вам наилучшего, Владимир, на вашем пути. Только зрелые люди способны взять свою судьбу в свои руки и начать, наконец, жить своими, а не навязанными целями и интересами.
Я не очень понимаю, каким образом отсутствие академического образование исключает возможность самообразования? И если такому человеку надо освоить изучение матриц, это просто означает необходимость прочитать полторы страницы учебника и потратить максимум два дня неспешного изучения. Разобраться же на уровне понятий и терминологии - это вообще задача на 15 минут.
Когда я принял для себя решение профессионально заняться 1С (что-то в районе 2001 года), то я начал с покупки брошюры по бухгалтерскому учёту :)
Как показала моя дальнейшая профессиональная деятельность, это было правильным решением. Мне был вполне понятен бухгалтерский учёт по его сути, но его практическая реализация в РФ на уровне Налогового Кодекса и ПБУ - это совсем другая история. Поэтому я специализировался в разработке, вполне себе успешно.
Но, так или иначе, постоянно занимаясь самыми разными вопросами автоматизации бухучёта, вникая в возникающие проблемы и почитывая статьи "на злобу дня", настолько проникаешься глубоко вторичными к программированию проблемами, что иногда отличить по тоске в глазах программиста от главного бухгалтера становится уже затруднительно.
Как итог, спустя годы работы, вполне возможна ситуация, когда человек становится универсалом - будь это разработка ИС "с нуля" от постановки задачи до внедрения, или консультация по типовым механизмам, или даже консультации по чисто учётным вопросам на основании законодательства.
В моём случае, всё равно остался приоритет за разработкой, потому что тратить своё время на бесконечные и, часто, трудно осмысляемые повороты законодательной базы, желание пропало. Оно не окупается, для этого есть аудиторы.
Если же заниматься исключительно консультированием по реализованным в прикладных решениях механизмам - то это тоже проклятие и тлен. Постоянные изменения, бесконечные, никогда не исчезающие баги в реализации и мало творческий труд - мне не интересно это.
На основании всего этого могу сказать, что специализация - неизбежное следствие профессионального роста, и является безусловным добром. Но несовершенство этого мира вынуждает (пускай лично меня) быть человеком-оркестром и специалистом сверхширокого профиля. Даже скажу крамольное - мне это нравится. Пусть я не умею делать что-то идеально. Но за то, я умею дела очень-очень многое хорошо ;)
RabelStar, Dizzy и Elite. Но все эти игры с треском проигрывали по играбельности пакету Zeus, Gens+Mons а потом турбоассемблеру Tasm. Расставание с Pentagon 128 было очень грустным, а после армии игрушки и игры стали другими... Но могу точно сказать, ZX Spectrum предопределил мою профессию и интересы на многие-многие годы вперёд.
А самый дерзкий и молодой Смотрел на солнце над водой.
"Не все ли равно,- сказал он,- где? Еще спокойней лежать в воде".
Адмиральским ушам простукал рассвет: "Приказ исполнен. Спасенных нет". (с) Николай Тихонов, "Баллада о гвоздях"
Бизнесу нужны рождающие ликвидность машины, а в наличии лишь слабые органические тела, да ещё и не всегда взаимозаменяемые. Поэтому бизнес берёт что есть и бросает в котёл.
Пока юноша юн, он горяч и не умеет сходу узреть меру и достаточность. Отсюда проистекают ошибки соразмерности. А хитрый бизнес это понимает и умело использует. Сгорел один? Несите следующего.
Наиболее производительным являются первые 4 часа труда. Дальше соотношение результат/затраченное время начинает стремительно уменьшаться.
Спасибо, мне было интересно, но, мне кажется, слишком в "общих чертах" :)
Delphi как инструмент никуда не делся, есть прекрасный проект Lazarus IDE, вполне себе жизнеспособный.
Какой смысл гнаться за "современностью"? Лично у меня ничего кроме раздражения не вызывает бесконечное обновление php, python и подобного поделья, с хроническим разрушением обратной совместимости, это не инженерный подход и на подобных инструментах весьма рискованно делать что-то, что будет работать дольше пары лет. Но это так, брюзжание.
На мой взгляд, вообще нет никакого значения, что изучают в институтах. Изучение любого языка для начала разработки на нём - занимает считанные дни, максимум - недели, при наличии опыта работы с любым языком программирования универсального применения. А во многих случаях достаточно двух-трёх часов и примера кода, чтобы начать работу, так что чему учать в институтах - без разницы, там вообще мало чему учат.
Ваше успешное внедрение принесло уже очень значительный результат - как минимум, удалось выявить и формализовать все основные технологические и производственные операции, вопрос их реализации с помощью того или иного инструмента - уже глубоко вторичен и должен отвечать лишь критерию целесообразности. Так что если всё нормально работает - первое правило инженера не стоит нарушать, "работает - не трожь!"
Архитектура "клиент-сервер" не лучше и не хуже любой другой архитектуры, она либо отвечает, либо не отвечает требованиям конкретной задачи, так же как перевозки ж/д транспортом не устарели от появления самолётов, и даже велосипеды не удалось вытеснить ;)
Возможно, я что-то недопонимаю, но, по-моему, задача имеет явно асинхронную природу и не может решаться "в лоб"
Как бы сделал я?
При открытии приложения, его настройки запрашиваются с сервера. В этот момент, пока данные не получены, изменять настройки можно, но их состояние сохраняется только локально, а пользователь может получать уведомление "синхронизация", если изменения критичны для общего функционала.
Во время синхронизации отображается последнее сохранённое ЛОКАЛЬНО состояние настроек приложения и никакие данные настроек на сервер не передаются до их получения.
После получения с сервера и сравнения состояния, конфликты разрешаются, после чего новое состояние отправляется на сервер и только после подтверждения сервером получения новых настроек синхронизация считается законченой и может произойти отправка новых изменений на сервер. До этого момента все изменения только локальны.
Если сервер отказывает в каких-либо изменениях, приложение сообщает об этом и фиксирует этот факт в локальной копии конфигурации
Всё. При таком подходе вообще невозможно возникновение каких-либо проблем подобного рода при вполне доступной возможности изменять настройки приложения.
Если пользователь поменял "флажок" и ушёл с экрана - приложение лишь изменило своё состояние на "запрос синхронизации", сохранив своё состояние локально и ожидая подтверждения изменений данных на сервере.
Учитывая, что приложение по природе своей клиент-серверное и настройки прямо влияют на поведение приложения и передаваемые сервером данные, приоритет синхронизации настроек видится необходимым.
Отработка критичных аварийных ситуаций только внешней автоматикой, релейной или электронной, но без применения каких-либо программных анализаторов. Например, реакция на сигнал "ПОЖАР" - отключение вентиляторов, включение аварийных клапанов - никакого ПЛК, только электромеханика.
Кнопки "Пуск" и "Стоп", тем более, "Аварийный останов" должны быть "железные". Это не только отучает тыкать в экран, но и освобождает его для его прямой функции - индикации состояния объекта управления.
Если панель оператора не является частью ПЛК, это ещё одно звено, понижающее надёжность и оперативность. Мне сейчас трудно вспомнить конкретные ситуации, которые привели к таким выводам, но они были и не зависили от производителя ПЛК.
Дизайн - это очень сложный вопрос, дизайн это во-первых - вопрос функциональности, во-вторых - эргономики и только в третьих - эстетики. Это не то же самое, что дизайн мобильника или телевизора. Речь идёт об управлении технологической системой, имеющей серьёзные отличия от бытового прибора.
Delta прекрасные контроллеры. Помню их по серии DVP-PS, у меня даже дома их есть парочка. Но с какими бы я не работал, а это много разных - и Delta и Овены и КОНТАР и Siemens и многие другие - их надёжность никогда нельзя принимать в 100% вешая на них отработку ситуаций, которые могут стоить жизни человеку.
Картинка не очень радостная. Раньше злодейство ограничивалось естественным слабоумием злодеев, теперь у них есть доступ к технологическим костылям, дающим им невиданные возможности - BigData + LLM + космические вычислительные мощности. Уверен, они сразу же попытаются сделать мир лучше, ведь они всегда к этому стремились, правда ведь? Я перестал в этом сомневаться, когда язык запросов google стал настолько совершенен, что потерял способность сортировать результаты запроса по дате.
Хорошо быть таким способным. А я учусь учиться всю свою жизнь и так и не уверен, что достаточно хорошо научился :)
Спасибо за интересную статью. Перепробовал разные способы ведения своей базы знаний, долго обдумывал разработку своей программы, но остановился базе знаний, построенной вокруг обычной файловой системы (каталоги, текстовые файлы, иногда - html файлы), как наиболее универсальной для переноса между устройствами и с возможностью доступа без всяких средств, кроме текстового редактора.
Да, но можно использовать те пути, что предлагает теория:
Сообщение достаточно большой жопе дополнительного кванта, влекущего за собой телепортацию жопы на вышестоящий уровень
Декомпозицию жопы умелым групповым наскоком, что приводит к увеличению их количества, но уменьшению частного жопного потенциала, позволяющего спихнуть всё это скопом ниже по уровню
Когда-то давным давно, в одной далёкой галактике, существовало такое понятие как "общественный договор" и такие дикие традиции, как право на самостоятельную оценку полезности, достоверности и истинности той или иной информации для лиц, не поражённых в гражданских правах. Дико.
Теперь в этой галактике всё гораздо более правильно. Теперь оценку осуществляет не разумное существо, наделённое обществом полномочиями и ответственностью, а абстрактный математический алгоритм, не имеющий ни полномочий, ни ответственности, ни даже способностью осознать анализируемое высказывание. Как и полной неспособностью ту или иную оценку аргументировать.
А какие проблемы с программированием контролов на WinAPI?
Используете функцию RegisterClassEx, создаёте окно класса CHILD, во флагах указываете, что оно само себя рисует, не имеет оформления и в процедуре окна рисуете и отрабатываете всё что вам надо. Можно запихать таких окон сколько угодно в библиотеку и получится ещё один набор пользовательских элементов управления.
Это очень просто и недорго. Я так делал из интереса на чистом асме когда ещё masm'ом и tasm'ом баловался во времена динозавров (на XP точно работало). Советую найти и скачать win32api_big.chm файл, там весь API очень удобно собран и документирован, работать ничуть не сложнее чем с QT или GTK.
Увы, не взлетело (Telegram 4.3.3, Linux x86_64):
https://imgur.com/PnZ702y
Ошибка возникает во время загрузки игры в окне телеграм, индикатор загрузки при этом во второй половине шкалы.
"В июле и августе 1991 года я, с подачи Гвидо Ван Россума, проводил технические интервью на позицию Middle Python Backend developer"
Ну друзья, это же САРКАЗМ! Спасибо, посмеялся от души. Шутки с каменным лицом - они такие.
Трудно с этим согласиться. Если ваша задача - извлечь из текста информацию максимально быстро, то разумно выбрать текст с минимальным количеством воды при прочих равных условиях.
Если же ваша задача и интерес - сам процесс чтения, тогда разумно сделать обратный выбор при тех же ограничениях.
Поэтому статья на две страницы будет гарантированно прочитана по-диагонали или опущена вовсе. А заметка в два абзаца - почти наверняка будет прочитана полностью, если там будет хотя бы одно ключевое слово.
Всё-таки чтение как информационный процесс отличается от чтения для развлечения. Но даже здесь - короткие анекдоты всегда самые лучшие :)
Да, здорово. Я так прикинул, батарея ~ МВт*ч и весом ~ 4 тонны. 37 тонн груза + 4 тонны батарея, плюс тонн 7-8 сам тягач. Итого, 20 кВт*ч на тонну. В принципе, вполне себе реально.
На мой взгляд, прекрасные рекомендации, сам пользуюсь и много раз убедился в эффективности этих методов даже для людей вроде меня, с памятью, как у дрозофилы.
Всего вам наилучшего, Владимир, на вашем пути. Только зрелые люди способны взять свою судьбу в свои руки и начать, наконец, жить своими, а не навязанными целями и интересами.
Я не очень понимаю, каким образом отсутствие академического образование исключает возможность самообразования? И если такому человеку надо освоить изучение матриц, это просто означает необходимость прочитать полторы страницы учебника и потратить максимум два дня неспешного изучения. Разобраться же на уровне понятий и терминологии - это вообще задача на 15 минут.
Когда я принял для себя решение профессионально заняться 1С (что-то в районе 2001 года), то я начал с покупки брошюры по бухгалтерскому учёту :)
Как показала моя дальнейшая профессиональная деятельность, это было правильным решением. Мне был вполне понятен бухгалтерский учёт по его сути, но его практическая реализация в РФ на уровне Налогового Кодекса и ПБУ - это совсем другая история. Поэтому я специализировался в разработке, вполне себе успешно.
Но, так или иначе, постоянно занимаясь самыми разными вопросами автоматизации бухучёта, вникая в возникающие проблемы и почитывая статьи "на злобу дня", настолько проникаешься глубоко вторичными к программированию проблемами, что иногда отличить по тоске в глазах программиста от главного бухгалтера становится уже затруднительно.
Как итог, спустя годы работы, вполне возможна ситуация, когда человек становится универсалом - будь это разработка ИС "с нуля" от постановки задачи до внедрения, или консультация по типовым механизмам, или даже консультации по чисто учётным вопросам на основании законодательства.
В моём случае, всё равно остался приоритет за разработкой, потому что тратить своё время на бесконечные и, часто, трудно осмысляемые повороты законодательной базы, желание пропало. Оно не окупается, для этого есть аудиторы.
Если же заниматься исключительно консультированием по реализованным в прикладных решениях механизмам - то это тоже проклятие и тлен. Постоянные изменения, бесконечные, никогда не исчезающие баги в реализации и мало творческий труд - мне не интересно это.
На основании всего этого могу сказать, что специализация - неизбежное следствие профессионального роста, и является безусловным добром. Но несовершенство этого мира вынуждает (пускай лично меня) быть человеком-оркестром и специалистом сверхширокого профиля. Даже скажу крамольное - мне это нравится. Пусть я не умею делать что-то идеально. Но за то, я умею дела очень-очень многое хорошо ;)
Всем радости.
RabelStar, Dizzy и Elite. Но все эти игры с треском проигрывали по играбельности пакету Zeus, Gens+Mons а потом турбоассемблеру Tasm. Расставание с Pentagon 128 было очень грустным, а после армии игрушки и игры стали другими... Но могу точно сказать, ZX Spectrum предопределил мою профессию и интересы на многие-многие годы вперёд.
А самый дерзкий и молодой Смотрел на солнце над водой.
"Не все ли равно,- сказал он,- где?
Еще спокойней лежать в воде".
Адмиральским ушам простукал рассвет:
"Приказ исполнен. Спасенных нет". (с) Николай Тихонов, "Баллада о гвоздях"
Бизнесу нужны рождающие ликвидность машины, а в наличии лишь слабые органические тела, да ещё и не всегда взаимозаменяемые. Поэтому бизнес берёт что есть и бросает в котёл.
Пока юноша юн, он горяч и не умеет сходу узреть меру и достаточность. Отсюда проистекают ошибки соразмерности. А хитрый бизнес это понимает и умело использует. Сгорел один? Несите следующего.
Наиболее производительным являются первые 4 часа труда. Дальше соотношение результат/затраченное время начинает стремительно уменьшаться.
Как-то так мне видится)
Спасибо за автобиографический очерк, прекрасно написано, подняли настроение)
Спасибо, мне было интересно, но, мне кажется, слишком в "общих чертах" :)
Delphi как инструмент никуда не делся, есть прекрасный проект Lazarus IDE, вполне себе жизнеспособный.
Какой смысл гнаться за "современностью"? Лично у меня ничего кроме раздражения не вызывает бесконечное обновление php, python и подобного поделья, с хроническим разрушением обратной совместимости, это не инженерный подход и на подобных инструментах весьма рискованно делать что-то, что будет работать дольше пары лет. Но это так, брюзжание.
На мой взгляд, вообще нет никакого значения, что изучают в институтах. Изучение любого языка для начала разработки на нём - занимает считанные дни, максимум - недели, при наличии опыта работы с любым языком программирования универсального применения. А во многих случаях достаточно двух-трёх часов и примера кода, чтобы начать работу, так что чему учать в институтах - без разницы, там вообще мало чему учат.
Ваше успешное внедрение принесло уже очень значительный результат - как минимум, удалось выявить и формализовать все основные технологические и производственные операции, вопрос их реализации с помощью того или иного инструмента - уже глубоко вторичен и должен отвечать лишь критерию целесообразности. Так что если всё нормально работает - первое правило инженера не стоит нарушать, "работает - не трожь!"
Архитектура "клиент-сервер" не лучше и не хуже любой другой архитектуры, она либо отвечает, либо не отвечает требованиям конкретной задачи, так же как перевозки ж/д транспортом не устарели от появления самолётов, и даже велосипеды не удалось вытеснить ;)
Возможно, я что-то недопонимаю, но, по-моему, задача имеет явно асинхронную природу и не может решаться "в лоб"
Как бы сделал я?
При открытии приложения, его настройки запрашиваются с сервера. В этот момент, пока данные не получены, изменять настройки можно, но их состояние сохраняется только локально, а пользователь может получать уведомление "синхронизация", если изменения критичны для общего функционала.
Во время синхронизации отображается последнее сохранённое ЛОКАЛЬНО состояние настроек приложения и никакие данные настроек на сервер не передаются до их получения.
После получения с сервера и сравнения состояния, конфликты разрешаются, после чего новое состояние отправляется на сервер и только после подтверждения сервером получения новых настроек синхронизация считается законченой и может произойти отправка новых изменений на сервер. До этого момента все изменения только локальны.
Если сервер отказывает в каких-либо изменениях, приложение сообщает об этом и фиксирует этот факт в локальной копии конфигурации
Всё. При таком подходе вообще невозможно возникновение каких-либо проблем подобного рода при вполне доступной возможности изменять настройки приложения.
Если пользователь поменял "флажок" и ушёл с экрана - приложение лишь изменило своё состояние на "запрос синхронизации", сохранив своё состояние локально и ожидая подтверждения изменений данных на сервере.
Учитывая, что приложение по природе своей клиент-серверное и настройки прямо влияют на поведение приложения и передаваемые сервером данные, приоритет синхронизации настроек видится необходимым.
Я бы добавил от себя вот что:
Отработка критичных аварийных ситуаций только внешней автоматикой, релейной или электронной, но без применения каких-либо программных анализаторов. Например, реакция на сигнал "ПОЖАР" - отключение вентиляторов, включение аварийных клапанов - никакого ПЛК, только электромеханика.
Кнопки "Пуск" и "Стоп", тем более, "Аварийный останов" должны быть "железные". Это не только отучает тыкать в экран, но и освобождает его для его прямой функции - индикации состояния объекта управления.
Если панель оператора не является частью ПЛК, это ещё одно звено, понижающее надёжность и оперативность. Мне сейчас трудно вспомнить конкретные ситуации, которые привели к таким выводам, но они были и не зависили от производителя ПЛК.
Дизайн - это очень сложный вопрос, дизайн это во-первых - вопрос функциональности, во-вторых - эргономики и только в третьих - эстетики. Это не то же самое, что дизайн мобильника или телевизора. Речь идёт об управлении технологической системой, имеющей серьёзные отличия от бытового прибора.
Delta прекрасные контроллеры. Помню их по серии DVP-PS, у меня даже дома их есть парочка. Но с какими бы я не работал, а это много разных - и Delta и Овены и КОНТАР и Siemens и многие другие - их надёжность никогда нельзя принимать в 100% вешая на них отработку ситуаций, которые могут стоить жизни человеку.