Ну,внешние файлы-коллекции для макросов, это сравнительно позднее нововведение в Exсel. И что то я его не встречал для Word, к примеру. А в том же CorelDraw, там макросы изначально внешние файлы (gms) и просто физически их нельзя включить в состав документа. Такое использование скорее лишь частные случаи А то, о чем пишете вы, конечно имеет место быть, но в повседневной практике это скорее исключение, нежели правило, если рассматривать макросы в Excel
Тем хотя бы, что отличие по использованию от того же VBS в общем то, только в отсутствии типизации данных и небольшого дополнительного синтаксического сахара, типа "объектов" и визуальных форм. То что это всё добавили, чтобы из скриптового языка внешней автоматизации (VBS),майкрософт сделал скриптовый язык внутренней автоматизации (VBA), не делает чем то особо иным, чем он есть по своей сути.
Причем тут VBS? Речь идёт о конкретнs[ парадигме в составе средств автоматизации и чем отличаются они в Р7 и MSO. В Р7 тоже есть конструктор документов и к нему апи, но по сути это совсем не то, что требуется для тех же СЭД.
Чем докажите? Чем он по сути использования отличается от того же java script, который в названии даже имеет скрипт? Он так же выполняется не отдельно, а в составе некой среды. Служит для описания взаимодействия пользователя и ядра программы и т.п.
Это не ООП в полном смысле этой парадигмы. Просто более удобный способ описания модулей в виде обобщенной структуры данных и функция, для обращения к ним через префикс. Но в целом, так же можно обращаться по имени модуля, и получим почти те же самые "классы"
Мы сейчас работаем как раз по OData в рамках импортозамещения. Пишем коннектор под Р7-Офис. Решение с OData конечно малоприятное, но с другой стороны, для начала хотя бы что то. Тем более, что в Р7, писанном на js, особых вариантов коннекта с внешними источниками данных, кроме работы по http и нет. А потребность данные выдёргивать из 1С у бизнеса имеется вот и приходится использовать что есть. Но конечно в рамках больших объёмов данных, это всё туфта будет и потребуется что то типа интегрированных в 1С решений. Надеюсь, что отечественные разрабы наконец договорятся между собой, и начнут интеграцию решений, наподобии тех, что давным давно имеются у западных аналогов.
Нужно. В любое время число интересующихся техникой к общему числу людей где то на уровне 5%. И из этих 5% потом и вырастают Королёвы, Глушко, Джобсы и Маски, в конце концов.Если нет реальной материальной базы, то и эти 5% вряд ли смогут найти свой путь. А тут по себе знаю - чем раньше, тем лучше.
Спасибо за перевод, но честно говоря, в нынешней ситуации с MS Office и прочими западными программами, где используется VBA как инструмент автоматизации (как по мне, так до сих пор непревзойдённый именно в этом ключе), данные статьи выглядят скорее как некрофилия из анекдота про мертвую стюардессу. Если уже сами мелкомягкие можно сказать - забросили VBA b переходят в макросах на JS и Phyton, то видимо даже они понимают, что новое поколение программистов просто не будут лезть в автоматизации в устаревшие парадигмы программирования, сколь много плюсов в них не было заложено 30 лет назад.
Там где крутятся данные о больших деньгах, и соответственно и речь о больших рисках в случае утечки данных, то будут. Про мелкие компании никто и не говорит, ибо они в большинстве своём и нафик никому не уперлись, чтобы тратить силы на взлом их протоколов. Там rest самое то. А для крупных игроков,не вложится в разработку на основе тяжёлых протоколов - себе дороже. О чем собственно и статья
Согласен. Лет двадцать назад, писал свой фреймворк для полнодесктопных приложений полностью перекрывающих экран в винде. Писалось на чистом WinAPI и GUI+ (ещё 1 версии). Все контролы писались с нуля, так как я сделал свою поддержку скинов (популярная тогда тема) и в принципе, когда хорошо прописываешь архитектуру на нижнем уровне (а я подсел тогда на новые тогда идеи банды 4 с их системой паттернов программирования ), то масштабировать код от простой кнопки на другие контролы не так и сложно оказалось. Жаль только, потом увлёкся другими идеями, а то в принципе можно было бы в нормальное что то вывести. А так да, сам порой сталкиваюсь со схожими как у автора целями, и в итоге кроме Qt, ничего внятного то и нет, увы.
Пробежался бегло по руководству разработчика для версии 3.0. Ну что же, прогресс имеется Особенно порадовало что теперь у вас нормальное модульное разделение для обработчиков событий и команд (жаль только в рамках табличного редактора). И изложение становится всё более логичным и сгруппированным. Но товарищи, где развитие нормального GUI в надстройках? У вас настолько обкоцанная версия LuaQt, что просто плакать хочется уже который го! А ведь там даже особо ничего доделывать не надо. Просто верните возможности до исходных, и будет сторонним разработчикам счастье! Ну как так то, что у вас даже цвета виджетов, рамки группировок и т.п. мелочи просто недоступны?! Вас Р7 потому и бьет во многом, что там программистам на местах вся мощь фреймворков под javascript доступна!
Еще раз, повторю свою мысль: такая нейросеть должна выдавать диагноз не просто по одному снимку, но и по куче сопутсвующих медицинских фактов. Ни один нормальный онколог, не возьмется прямо сразу утверждать, у вас меланома, если она допустим ещё первой или даже второй степени. Про всякие плоскоклеточные виды опухоли вообще молчу! На этих стадиях они вполне себе могут быть похожи на какие нибудь кератомы, невсусы, или другие пигментозные новообразования. Нужны сопутствующие медицинские данные, чтобы нейронные связи устанавливались не только по схожести самого внешнего вида, но и по другим векторам, которые на первый взгляд могут быть совсем не очевидными, но выявиться именно путем нейрообучения ИИ. И тут просто картинки мало чем могут помочь. Опять же - приведу свой пример. Мне два опытных врача - онколога при осмотре поставили диагнозом меланому. Два других (кстати не онкологи в общем то, но встречавшихся с нею не раз у своих пациентов), её так же отвергли и сказали что это вообще не похоже на онкологию. В итоге оказалось что это и не меланома, и в тоже время онкология, но совершенно другого класса, которая слава богу была на нулевой стадии и не агрессивной формы. Но опять же, это установили уже по биопсии послеоперационного материала. И то - со второго раза. Поэтому, даже очень крупный набор исходных фото, может дать такой же большой набор ложных диагнозов, если при этом помимо фото не даются иные вводные данные, позволяющие перейти на более высокий уровень связей между конкретным случаем, и статистикой по установленным уже ранее диагнозам. А вот с этим, скорее всего и будет проблема у крупных наборов просто картинок с диагностированными опухолями.
Ну ок. Спорить глупо, VBA это и правда с точки зрения современного программиста - очень устаревший язык. На смену ему, мелкомягкие предлагают как вариант работать на современном и прогрессивном JS. Ну так в гробу я видал такую замену! Там такой ад и слёзы, чтобы начать хоть что то серьезной писать, что я лучше буду автоматизировать на старом добром VBA, как делает автор! Или лучше что-ли когда вообще нет альтернатив, например как в наших "отечественных" редакторах? Попробуйте там чего-нибудь автоматизировать так же просто как на VBA, где парой строк можно подтянуть в интерфейс любой установленный в системе COM+ ActiveX компонент, или системную библиотеку dll, с использованием почти любых внутренних функций, используя при этом голый Lua (в МойОфис) или на js с его сопутствующими ограничениями для вэб программирования, когда нужны возможности для десктоп приложений (в Р7). То-то крупные фирмы ищут-ищут компании кто бы перевел их наработки автоматизации с MSO в импортозамещаемые офисные пакеты, да никак найти не могут.
Причем здесь ОС и конкретные программные продукты, да ещё для достаточно консервативной прослойки пользователей, как фотографы, дизайнеры и диджитал художники, которым важно работать быстро и привычно, нежели копаться в настройках и изучать новый интерфейс? Но если говорить именно про ваш пример, то тут спорить не стану. Не даром, главный оппонент - Apple, в свое время куда как более глубоко поработал с пользовательским опытом, и построил системы, которые мегаконсервативные но при этом удобные для тех людей, которым важнее интуитивность в работе, нежели свобода в возможности настроить всё под себя.
Почему же зря? Наборы это хорошо! Другое дело, что набор-набору рознь. Учитывая, что помимо самих изображений, тут ещё важна и достоверность и вообще точное описание к каждому изображению, такое как: точный типа онкологии, степени дифференцированости опухоли, точно подтвержденная стадия опирающаяся на послеоперационное исследование образца опухоли и ещё многих факторов, без которых потеряется достоверность и точность такого рода наборов. Не спорю, найти картинки сейчас наверное не так уж и проблематично. Проблематичнее построить модель ИИ, которая бы как можно меньше ошибалась в своей диагностике. А потом ещё и дообучитть её в чем она конкретно ошибается, дабы исправить подобные ошибки на будущее. Поэтому, наверное локально собранные наборы пусть и не столь репрезентативны из-за количества возможных вариаций опухолей, но зато обладают куда большим сопутствующим набором данных, для построения последующих векторных БД, которые будут опираться не только на саму картинку, ну а допустим и на другие факторы: пол, рост, вес и разного анамнеза, которые сомнительно что доступны для таких открытых баз.
Вот вот! Я ещё в далеких уже восьмидесятых учился, и тогда все, даже преподаватели сами, называли именно так - художка
Ну,внешние файлы-коллекции для макросов, это сравнительно позднее нововведение в Exсel. И что то я его не встречал для Word, к примеру. А в том же CorelDraw, там макросы изначально внешние файлы (gms) и просто физически их нельзя включить в состав документа. Такое использование скорее лишь частные случаи А то, о чем пишете вы, конечно имеет место быть, но в повседневной практике это скорее исключение, нежели правило, если рассматривать макросы в Excel
Тем хотя бы, что отличие по использованию от того же VBS в общем то, только в отсутствии типизации данных и небольшого дополнительного синтаксического сахара, типа "объектов" и визуальных форм. То что это всё добавили, чтобы из скриптового языка внешней автоматизации (VBS),майкрософт сделал скриптовый язык внутренней автоматизации (VBA), не делает чем то особо иным, чем он есть по своей сути.
И микроскопом можно убить, если использовать не по назначению.
Причем тут VBS? Речь идёт о конкретнs[ парадигме в составе средств автоматизации и чем отличаются они в Р7 и MSO. В Р7 тоже есть конструктор документов и к нему апи, но по сути это совсем не то, что требуется для тех же СЭД.
Чем докажите? Чем он по сути использования отличается от того же java script, который в названии даже имеет скрипт? Он так же выполняется не отдельно, а в составе некой среды. Служит для описания взаимодействия пользователя и ядра программы и т.п.
Это не ООП в полном смысле этой парадигмы. Просто более удобный способ описания модулей в виде обобщенной структуры данных и функция, для обращения к ним через префикс. Но в целом, так же можно обращаться по имени модуля, и получим почти те же самые "классы"
Мы сейчас работаем как раз по OData в рамках импортозамещения. Пишем коннектор под Р7-Офис. Решение с OData конечно малоприятное, но с другой стороны, для начала хотя бы что то. Тем более, что в Р7, писанном на js, особых вариантов коннекта с внешними источниками данных, кроме работы по http и нет. А потребность данные выдёргивать из 1С у бизнеса имеется вот и приходится использовать что есть. Но конечно в рамках больших объёмов данных, это всё туфта будет и потребуется что то типа интегрированных в 1С решений. Надеюсь, что отечественные разрабы наконец договорятся между собой, и начнут интеграцию решений, наподобии тех, что давным давно имеются у западных аналогов.
Нужно. В любое время число интересующихся техникой к общему числу людей где то на уровне 5%. И из этих 5% потом и вырастают Королёвы, Глушко, Джобсы и Маски, в конце концов.Если нет реальной материальной базы, то и эти 5% вряд ли смогут найти свой путь. А тут по себе знаю - чем раньше, тем лучше.
Да, я в курсе. Пробовал я там на JS писать. Чушь у них ещё большая нежели у Р7 выходит.
Спасибо за перевод, но честно говоря, в нынешней ситуации с MS Office и прочими западными программами, где используется VBA как инструмент автоматизации (как по мне, так до сих пор непревзойдённый именно в этом ключе), данные статьи выглядят скорее как некрофилия из анекдота про мертвую стюардессу. Если уже сами мелкомягкие можно сказать - забросили VBA b переходят в макросах на JS и Phyton, то видимо даже они понимают, что новое поколение программистов просто не будут лезть в автоматизации в устаревшие парадигмы программирования, сколь много плюсов в них не было заложено 30 лет назад.
Там где крутятся данные о больших деньгах, и соответственно и речь о больших рисках в случае утечки данных, то будут. Про мелкие компании никто и не говорит, ибо они в большинстве своём и нафик никому не уперлись, чтобы тратить силы на взлом их протоколов. Там rest самое то. А для крупных игроков,не вложится в разработку на основе тяжёлых протоколов - себе дороже. О чем собственно и статья
Согласен. Лет двадцать назад, писал свой фреймворк для полнодесктопных приложений полностью перекрывающих экран в винде. Писалось на чистом WinAPI и GUI+ (ещё 1 версии). Все контролы писались с нуля, так как я сделал свою поддержку скинов (популярная тогда тема) и в принципе, когда хорошо прописываешь архитектуру на нижнем уровне (а я подсел тогда на новые тогда идеи банды 4 с их системой паттернов программирования ), то масштабировать код от простой кнопки на другие контролы не так и сложно оказалось.
Жаль только, потом увлёкся другими идеями, а то в принципе можно было бы в нормальное что то вывести. А так да, сам порой сталкиваюсь со схожими как у автора целями, и в итоге кроме Qt, ничего внятного то и нет, увы.
Пробежался бегло по руководству разработчика для версии 3.0. Ну что же, прогресс имеется Особенно порадовало что теперь у вас нормальное модульное разделение для обработчиков событий и команд (жаль только в рамках табличного редактора). И изложение становится всё более логичным и сгруппированным. Но товарищи, где развитие нормального GUI в надстройках? У вас настолько обкоцанная версия LuaQt, что просто плакать хочется уже который го! А ведь там даже особо ничего доделывать не надо. Просто верните возможности до исходных, и будет сторонним разработчикам счастье! Ну как так то, что у вас даже цвета виджетов, рамки группировок и т.п. мелочи просто недоступны?! Вас Р7 потому и бьет во многом, что там программистам на местах вся мощь фреймворков под javascript доступна!
Полностью с вами согласен. Увы, но походу всё так и есть
Еще раз, повторю свою мысль: такая нейросеть должна выдавать диагноз не просто по одному снимку, но и по куче сопутсвующих медицинских фактов. Ни один нормальный онколог, не возьмется прямо сразу утверждать, у вас меланома, если она допустим ещё первой или даже второй степени. Про всякие плоскоклеточные виды опухоли вообще молчу! На этих стадиях они вполне себе могут быть похожи на какие нибудь кератомы, невсусы, или другие пигментозные новообразования. Нужны сопутствующие медицинские данные, чтобы нейронные связи устанавливались не только по схожести самого внешнего вида, но и по другим векторам, которые на первый взгляд могут быть совсем не очевидными, но выявиться именно путем нейрообучения ИИ. И тут просто картинки мало чем могут помочь.
Опять же - приведу свой пример. Мне два опытных врача - онколога при осмотре поставили диагнозом меланому. Два других (кстати не онкологи в общем то, но встречавшихся с нею не раз у своих пациентов), её так же отвергли и сказали что это вообще не похоже на онкологию. В итоге оказалось что это и не меланома, и в тоже время онкология, но совершенно другого класса, которая слава богу была на нулевой стадии и не агрессивной формы. Но опять же, это установили уже по биопсии послеоперационного материала. И то - со второго раза. Поэтому, даже очень крупный набор исходных фото, может дать такой же большой набор ложных диагнозов, если при этом помимо фото не даются иные вводные данные, позволяющие перейти на более высокий уровень связей между конкретным случаем, и статистикой по установленным уже ранее диагнозам. А вот с этим, скорее всего и будет проблема у крупных наборов просто картинок с диагностированными опухолями.
Ну ок. Спорить глупо, VBA это и правда с точки зрения современного программиста - очень устаревший язык. На смену ему, мелкомягкие предлагают как вариант работать на современном и прогрессивном JS. Ну так в гробу я видал такую замену! Там такой ад и слёзы, чтобы начать хоть что то серьезной писать, что я лучше буду автоматизировать на старом добром VBA, как делает автор! Или лучше что-ли когда вообще нет альтернатив, например как в наших "отечественных" редакторах? Попробуйте там чего-нибудь автоматизировать так же просто как на VBA, где парой строк можно подтянуть в интерфейс любой установленный в системе COM+ ActiveX компонент, или системную библиотеку dll, с использованием почти любых внутренних функций, используя при этом голый Lua (в МойОфис) или на js с его сопутствующими ограничениями для вэб программирования, когда нужны возможности для десктоп приложений (в Р7).
То-то крупные фирмы ищут-ищут компании кто бы перевел их наработки автоматизации с MSO в импортозамещаемые офисные пакеты, да никак найти не могут.
Причем здесь ОС и конкретные программные продукты, да ещё для достаточно консервативной прослойки пользователей, как фотографы, дизайнеры и диджитал художники, которым важно работать быстро и привычно, нежели копаться в настройках и изучать новый интерфейс?
Но если говорить именно про ваш пример, то тут спорить не стану. Не даром, главный оппонент - Apple, в свое время куда как более глубоко поработал с пользовательским опытом, и построил системы, которые мегаконсервативные но при этом удобные для тех людей, которым важнее интуитивность в работе, нежели свобода в возможности настроить всё под себя.
Почему же зря? Наборы это хорошо! Другое дело, что набор-набору рознь. Учитывая, что помимо самих изображений, тут ещё важна и достоверность и вообще точное описание к каждому изображению, такое как: точный типа онкологии, степени дифференцированости опухоли, точно подтвержденная стадия опирающаяся на послеоперационное исследование образца опухоли и ещё многих факторов, без которых потеряется достоверность и точность такого рода наборов.
Не спорю, найти картинки сейчас наверное не так уж и проблематично. Проблематичнее построить модель ИИ, которая бы как можно меньше ошибалась в своей диагностике. А потом ещё и дообучитть её в чем она конкретно ошибается, дабы исправить подобные ошибки на будущее. Поэтому, наверное локально собранные наборы пусть и не столь репрезентативны из-за количества возможных вариаций опухолей, но зато обладают куда большим сопутствующим набором данных, для построения последующих векторных БД, которые будут опираться не только на саму картинку, ну а допустим и на другие факторы: пол, рост, вес и разного анамнеза, которые сомнительно что доступны для таких открытых баз.
Упс, не туда ответил...