Я часть подобных задач когда-то, когда интернета почти не было и много чего приходилось изобретать самому, или додумывать по немногим книгам о С++, писал по молодости лет. Если не брать чью-то базу, а пилить свою с нуля, то почти каждая задача в реальности на 3-4 месяца, а то и год довольно плотного программирования. Но если конечно привлекать ИИ, то может и уложишься в такие сроки, но это явно уже не твоё достижение будет
Да, незачто! Я сам давно страдаю подобными задачами, только до реализации универсальных решений так и не дошел, увы. Но мысли остались. Чего бы не поделиться с теми, кто может их воплотить :)
Понимаю, что так конечно так проще, создавать снапшот всего состояния проекта. Но если таковая история сильно разрастётся для проекта, который сам по себе может быть не столь прост и при этом объёмен, то получится нехилая такая куча файлов очнь сильно сжирающая место на носителе. В принципе, в git примерно такая же схема, но она вроде как все равно разностная. Мне думается, что все таки более идеальным решением было бы делать именно сохранение разностей между состояними, с указанием от какого состояния берется разность. Тогда можно более менее просто пройти по графу и сделать либо откаты, либо слияния. По сути, в такой схеме нужно нечно наподобии того, что делается при ужатии видеоряда видеокодеками: Есть ключевые р кадры которые практически не ужимаются (или ужимаются с минимальной потерей информации на них), а к ним строятся разностные i кадры, которые по сути наборы векторов смещений тех ил ииных полей на кадре по отношению к предыдущему состоянию. Таким образом потом можно делать перемотки в почти любой момент времени. В такой схеме и место экономится, и есть некие стабильные состояния, к которым можно откатиться безболезненно
Не читая всех комментов чисто по статье. Как и все диалектическое, оба подхода в целом верные. Суть написания хорошей программы в балансе бестпрактикс, личного опыта и конечных целей. Для локальной утилиты, чаще всего нет нужды городить ООП и применять паттерны и прочие хорошие но не практичные на коротких дистанциях пректики. Для серьезного ПО, да ещё и в команде, это становится жизнено необходимо, особенно когда уровень разработчиков в команде разный, и не ясно кто придет вослед. И не важно, через 5 лет будет доработка, или завтра. Но, такие усилия даром не даются. Это труд хорошего архитектора с огромным опытом, который правильно понимает и предметную область и инструменты, которыми будут пользоваться при написании. А значит - это и большие деньги. Но которые в целом отбиваются далее на расширении и поддержке решения хоть в какой то обозримый промежуток времени. Мало кто думает, я сейчас возьму и напишу новую нелтленку аля фотошоп или блендер. Но если есть инвестор, который серьезно в проект решился вложиться, то как раз и возникает вопрос в анализе и создании архитектуры проекта, которую желательно создать "на берегу", и стараться по максимуму её придерживаться, даже если она окажется ошибочной. Грамотный модульный проект, даже при ошибочном проектировании архитектуры, затем куда проще исправить, нежели мешанину из "работает - не трожь". Поэтому - все подходы правильные! Главное - понимать когда стоит лениться, а когда надо делать над собой усилия и писать по установленным лекалам.
Ой не факт! Если ошибка зарыта, например, в логике действий пользователя. которую ты изначально не предусмотрел то никакой стаический анализатор, линтер и прочие ИИ её не отловят, это к гадалке не ходи! И да, можно с колосальным опытом в трех строчках ловить ошибку, которая воспроизводится при "нелепом" стечении факторов, например при обработке асинхронных запросов.
Аналогично, но немного с иной позиции. Я начинал проект на js, хотя по чесноку, ни разу не писал до этого на js. Естественно, начал писать в парадигме мне привычной, аля C++., но на функциоанльном базисе (да в общем то иного и не требовалось, ибо в целом задачи были не такие сложные). Далее проект передали человеку, который решил привести мой "спагетти код" в парадигму ООП. Как итог, из 5 файлов, по каждому на отдельное окно, теперь их около 20, где даже вызов обработчиков событий нажатия на кнопку ведётся через статические методы отдельного специального класса, которые не очень хорошо в итоге обсфуркцируются! Ну и прочие "радости", которые придется теперь уже мне причесывать в хоть какой то логический порядок, чтобы потом продолжить расширять проект на новые задачи. Так что, статья - зачет! И рекомендовал бы её почитать подавляющему большинству современных программистов.
Для соревновательных роботов, где скорости и усилия другие, нужны куда более прочные но разъемные соединения, о чем miskin79 и написал. Лего это чисто быстрое баловство!
Р7 он не однопоточный. Ядро там вполне себе бинарное и в теории вполне себе параллелится.. А вот UI, для каждого отдельного документа да, однопоточный JS, впрочем который стратует через worker, что немного спасает, но не сильно.
Распотрашили БД Access на кучу отдельных экселевских таблиц (впрочем, они туда и загонялись изначально, на какой то ляд), и оттуда дергали с помощью js библиотеки AlaSQL. Очень рекомендую, для схожих задач вполне норм решение. Есть вариант ещё через Питон дергать непосредственно из файла базы, но у нашего заказчика возникли некие сложности с установкой Питона на рабочих местах, так что пришлось импровизировать таким вот способом
Очень спорное утверждение! Не понимаю всю это новоявленную любовь к ИИ. Начнем с того, что ИИ ( в том числе и ChatGPT) очень много придумывает своих вариантов несуществующего АПИ, которые мягко говоря надо чистить. Или обучать на примерах, которые опять же надо ручками сперва создать. И причем не простейшие варианты типа - покрасить ячейку это так то, а открыть внешнюю связь, это загрузить либу такую то, скачать данные из файла так то, и потом дергаем там ячейку таким - то образом. Плюс, в большом числу случаев, большие куски кода просто удаляются, и где то есть только пометка, что типа тут пилите напильником, ибо JS не поддерживает то, что жлементарно в VBA И т.п. И видно такие пропуски далеко не сразу чаще всего. И это не говоря про то, что АПИ в Р7 мягко говоря далеко не столь полное как в MS Office+VBA
Лучше даже не пробовать. Это создавалось только чисто для облегчения деплоя макрсов через облако. Но создавать эти макросы там такое же ковыряние и головная боль, как и в Р7!
А теперь представьте, когда это все НАДО переносить в Р7, потоу что есть приказ перейти. И на этом плохопахнущем идет прогнозирование на многие миллиарды руб... И когда ещё и консолидация нужна из нескольких файлов, да ещё и раньше это все работало в связке с Access (недавний кейс нашей конторы) Перенос 3 макросов в итоге занял 3 месяца, и продолжается с плясками и бубнами ещё какое то время точно
Оно то хорошо, пока не дойдет до багов. Уверены что их не будет, и будете в состоянии хоть что то с этим сделать? Ладно, игры это не так страншно, а когда речь зайдет о чем то более серьезном. Связаным например с финансами. или прости господи, с инженерными расчетами? А такое скоро начнется и повсеместно
В норме русского языка, говорить "ты", когда имеется в виду абстрактный пример, говорящий про действие не обращенное конкретно к кому то, а само по себе. То есть, как в данном случае: стоит самому проверить, прежде чем доверять коду который сгенерировал ИИ. И это не конкретно к вам обращение, а к любому кто так делает. О чем, кстати, люто подтверждаю ибо почти каждый день встречаюсь с вопросами ко мне как к эксперту в определённой области, по такому сгенерированному коду. Не надо сразу все сразу на свой счет воспринимать.
У меня три монитора, и порой не хватает и их. Каждый для своей цели, но при сильном мозговом штурме или отладке, явно требуется четвертый, который был бы чисто вторым под виртуалкой, чтобы не приходилось переключаться в виртуалке между IDE и отлаживаемой программой.
Вы лучше не переводы делайте, а приведите в порядок свои средства автоматизации. Особенно что касается надстроек! Когда вы внедрите нормальное использование библиотеки LuaQt, а не ту кастрированную версию, в которой ничего толком нельзя использовать?!
Хорошо, но всё таки, вот мне больше был по душе более глубокий и последовательный подход, которые были в книгах Борисов "Юный радиолюбитель" и Свореня "Электроника шаг за шагом" Но понимаю, современное поколение тик-ток детей с их фрагментарным мышлением вряд ли настолько усидчивые, чтобы ещё и теорию высиживать
Ещё раз, вы не табличные редакторы "приручаете", а в лучшем случае - тип документов пользователя (табличный). С таким же успехом, если я напищу универсальный составитель SQL запросов под разные типы популярных СУБД, я по вашему приручу все эти базы данных? Типично кликинбайтный заголовок. Хотя, спорить не стану, в целом для разработчиков информация у вас полезная.
Я часть подобных задач когда-то, когда интернета почти не было и много чего приходилось изобретать самому, или додумывать по немногим книгам о С++, писал по молодости лет. Если не брать чью-то базу, а пилить свою с нуля, то почти каждая задача в реальности на 3-4 месяца, а то и год довольно плотного программирования. Но если конечно привлекать ИИ, то может и уложишься в такие сроки, но это явно уже не твоё достижение будет
Да, незачто! Я сам давно страдаю подобными задачами, только до реализации универсальных решений так и не дошел, увы. Но мысли остались. Чего бы не поделиться с теми, кто может их воплотить :)
Понимаю, что так конечно так проще, создавать снапшот всего состояния проекта. Но если таковая история сильно разрастётся для проекта, который сам по себе может быть не столь прост и при этом объёмен, то получится нехилая такая куча файлов очнь сильно сжирающая место на носителе. В принципе, в git примерно такая же схема, но она вроде как все равно разностная. Мне думается, что все таки более идеальным решением было бы делать именно сохранение разностей между состояними, с указанием от какого состояния берется разность. Тогда можно более менее просто пройти по графу и сделать либо откаты, либо слияния.
По сути, в такой схеме нужно нечно наподобии того, что делается при ужатии видеоряда видеокодеками:
Есть ключевые р кадры которые практически не ужимаются (или ужимаются с минимальной потерей информации на них), а к ним строятся разностные i кадры, которые по сути наборы векторов смещений тех ил ииных полей на кадре по отношению к предыдущему состоянию. Таким образом потом можно делать перемотки в почти любой момент времени. В такой схеме и место экономится, и есть некие стабильные состояния, к которым можно откатиться безболезненно
Не читая всех комментов чисто по статье.
Как и все диалектическое, оба подхода в целом верные. Суть написания хорошей программы в балансе бестпрактикс, личного опыта и конечных целей. Для локальной утилиты, чаще всего нет нужды городить ООП и применять паттерны и прочие хорошие но не практичные на коротких дистанциях пректики. Для серьезного ПО, да ещё и в команде, это становится жизнено необходимо, особенно когда уровень разработчиков в команде разный, и не ясно кто придет вослед. И не важно, через 5 лет будет доработка, или завтра. Но, такие усилия даром не даются. Это труд хорошего архитектора с огромным опытом, который правильно понимает и предметную область и инструменты, которыми будут пользоваться при написании. А значит - это и большие деньги. Но которые в целом отбиваются далее на расширении и поддержке решения хоть в какой то обозримый промежуток времени.
Мало кто думает, я сейчас возьму и напишу новую нелтленку аля фотошоп или блендер. Но если есть инвестор, который серьезно в проект решился вложиться, то как раз и возникает вопрос в анализе и создании архитектуры проекта, которую желательно создать "на берегу", и стараться по максимуму её придерживаться, даже если она окажется ошибочной. Грамотный модульный проект, даже при ошибочном проектировании архитектуры, затем куда проще исправить, нежели мешанину из "работает - не трожь". Поэтому - все подходы правильные! Главное - понимать когда стоит лениться, а когда надо делать над собой усилия и писать по установленным лекалам.
Ой не факт! Если ошибка зарыта, например, в логике действий пользователя. которую ты изначально не предусмотрел то никакой стаический анализатор, линтер и прочие ИИ её не отловят, это к гадалке не ходи! И да, можно с колосальным опытом в трех строчках ловить ошибку, которая воспроизводится при "нелепом" стечении факторов, например при обработке асинхронных запросов.
Аналогично, но немного с иной позиции. Я начинал проект на js, хотя по чесноку, ни разу не писал до этого на js. Естественно, начал писать в парадигме мне привычной, аля C++., но на функциоанльном базисе (да в общем то иного и не требовалось, ибо в целом задачи были не такие сложные). Далее проект передали человеку, который решил привести мой "спагетти код" в парадигму ООП. Как итог, из 5 файлов, по каждому на отдельное окно, теперь их около 20, где даже вызов обработчиков событий нажатия на кнопку ведётся через статические методы отдельного специального класса, которые не очень хорошо в итоге обсфуркцируются! Ну и прочие "радости", которые придется теперь уже мне причесывать в хоть какой то логический порядок, чтобы потом продолжить расширять проект на новые задачи.
Так что, статья - зачет! И рекомендовал бы её почитать подавляющему большинству современных программистов.
Для соревновательных роботов, где скорости и усилия другие, нужны куда более прочные но разъемные соединения, о чем miskin79 и написал. Лего это чисто быстрое баловство!
Р7 он не однопоточный. Ядро там вполне себе бинарное и в теории вполне себе параллелится.. А вот UI, для каждого отдельного документа да, однопоточный JS, впрочем который стратует через worker, что немного спасает, но не сильно.
Распотрашили БД Access на кучу отдельных экселевских таблиц (впрочем, они туда и загонялись изначально, на какой то ляд), и оттуда дергали с помощью js библиотеки AlaSQL. Очень рекомендую, для схожих задач вполне норм решение. Есть вариант ещё через Питон дергать непосредственно из файла базы, но у нашего заказчика возникли некие сложности с установкой Питона на рабочих местах, так что пришлось импровизировать таким вот способом
Очень спорное утверждение! Не понимаю всю это новоявленную любовь к ИИ.
Начнем с того, что ИИ ( в том числе и ChatGPT) очень много придумывает своих вариантов несуществующего АПИ, которые мягко говоря надо чистить. Или обучать на примерах, которые опять же надо ручками сперва создать. И причем не простейшие варианты типа - покрасить ячейку это так то, а открыть внешнюю связь, это загрузить либу такую то, скачать данные из файла так то, и потом дергаем там ячейку таким - то образом. Плюс, в большом числу случаев, большие куски кода просто удаляются, и где то есть только пометка, что типа тут пилите напильником, ибо JS не поддерживает то, что жлементарно в VBA И т.п. И видно такие пропуски далеко не сразу чаще всего. И это не говоря про то, что АПИ в Р7 мягко говоря далеко не столь полное как в MS Office+VBA
Лучше даже не пробовать. Это создавалось только чисто для облегчения деплоя макрсов через облако. Но создавать эти макросы там такое же ковыряние и головная боль, как и в Р7!
Уже нет, почти как год.
А теперь представьте, когда это все НАДО переносить в Р7, потоу что есть приказ перейти. И на этом плохопахнущем идет прогнозирование на многие миллиарды руб... И когда ещё и консолидация нужна из нескольких файлов, да ещё и раньше это все работало в связке с Access (недавний кейс нашей конторы) Перенос 3 макросов в итоге занял 3 месяца, и продолжается с плясками и бубнами ещё какое то время точно
Оно то хорошо, пока не дойдет до багов. Уверены что их не будет, и будете в состоянии хоть что то с этим сделать? Ладно, игры это не так страншно, а когда речь зайдет о чем то более серьезном. Связаным например с финансами. или прости господи, с инженерными расчетами? А такое скоро начнется и повсеместно
Мне интересна эта тема! Спасибо за материал! Если будет ещё чем поделиться - было бы здорово! У нас не так много на эту тему публикуется, увы.
В норме русского языка, говорить "ты", когда имеется в виду абстрактный пример, говорящий про действие не обращенное конкретно к кому то, а само по себе. То есть, как в данном случае: стоит самому проверить, прежде чем доверять коду который сгенерировал ИИ. И это не конкретно к вам обращение, а к любому кто так делает. О чем, кстати, люто подтверждаю ибо почти каждый день встречаюсь с вопросами ко мне как к эксперту в определённой области, по такому сгенерированному коду. Не надо сразу все сразу на свой счет воспринимать.
У меня три монитора, и порой не хватает и их. Каждый для своей цели, но при сильном мозговом штурме или отладке, явно требуется четвертый, который был бы чисто вторым под виртуалкой, чтобы не приходилось переключаться в виртуалке между IDE и отлаживаемой программой.
Вы лучше не переводы делайте, а приведите в порядок свои средства автоматизации. Особенно что касается надстроек! Когда вы внедрите нормальное использование библиотеки LuaQt, а не ту кастрированную версию, в которой ничего толком нельзя использовать?!
Хорошо, но всё таки, вот мне больше был по душе более глубокий и последовательный подход, которые были в книгах Борисов "Юный радиолюбитель" и Свореня "Электроника шаг за шагом" Но понимаю, современное поколение тик-ток детей с их фрагментарным мышлением вряд ли настолько усидчивые, чтобы ещё и теорию высиживать
Ещё раз, вы не табличные редакторы "приручаете", а в лучшем случае - тип документов пользователя (табличный). С таким же успехом, если я напищу универсальный составитель SQL запросов под разные типы популярных СУБД, я по вашему приручу все эти базы данных? Типично кликинбайтный заголовок. Хотя, спорить не стану, в целом для разработчиков информация у вас полезная.