Виталий Шумаков @starfair
Программист широкого профиля
Information
- Rating
- 5,444-th
- Location
- Краснодар, Краснодарский край, Россия
- Date of birth
- Registered
- Activity
Specialization
Software Developer, Application Developer
Middle
From 120,000 ₽
C++
Visual Studio
OOP
У меня самого недавно обнаружили кожную онкологию, ттт, не сильно зловредную и вырезали, надеюсь без дальнейших последствий.
У вас немного писимистичное представление о том, сколько на самом деле есть доступных материалов в онкоклиниках. Во первых, до недавнего времени никто эти фото не собирал в некие коллекции для последующего машинного обучения. Я прошел три онколога, и несколько иных врачей, так или иначе связанных с онкологией, и никто по внешнему виду моего случая, так и не смог поставить примерный диагноз, поэтому шли по варианту максимальному - как при меланоме. И что самое парадоксальное, и потом, когда уже делали анализ по "стеклышкам", ставили два разных вида онкологии. Так что, это очень субъективный процесс, и он доступен только для очень хорошо подготовленных медицинских центров. И то, при условии, колоссальной предварительной работы по сбору данных, их подготовке и обработке. А это деньги. И очень и очень не маленькие. Поэтому это уровень или очень богатых мед\фарм компаний, или же дело государства.
Во вторых, любые попытки систематизировать и автоматизировать работу на стадии диагностики достойны только самой большой похвалы! В любом раскладе, я буду очень благодарен любым разработкам, которые помогут в диагностики любых видов рака, не важно на чем они базируются. Ибо лучше испугаться и не обнаружить при проверке, чем отмахнуться, и загнуться за пол года.
Не соглашусь. Это сработает, и то не факт, только для абсолютных новичков в деле обработки изображений. Так же следует добавить, что за эргономикой интрефейса в таких крупных корпарациях как Adobe, Microsoft, Corel и т.п. стоит уже многомилионный в человеко-часах (а то и годах) опыт пользователей, которые давали обратную связь. Быть оригинальным одуванчиком, это может и хорошо, но вряд ли решит вопрос и с большим удобством использования, и с привыканием к новому интерфейсу. Хотя, конечно иногда, такое и срабатывает. Но это крайне редко.
В защиту автора: он же вроде как написал в дисклеймере, что пример отчасти надуманный. Для серьезных задач, так писать будет грамотным подходом. Как и описание в заголовке переменных. Это очень реально хорошо дисциплинирует программиста, и приучает его писать "чистый" код. За что напротив, следующий грамотный программист, ему скажет только спасибо.
Как я понимаю, о том, что плагины на VBA можно писать и в грамотном современном виде, а не только в виде спагетти кода из бешеного переплетения функций в одном модуле, собственно и вся статья.
У меня есть проекты на VBA (правда не для офиса а для CorelDraw), в которых несколько десятков модулей, классов и форм. И именно примерно такое разделение и позволяет сопровождать макросы уже много лет.
Для мелкой задачи, реально too match. Если думать о серьезном расширении наперёд, то такой подход может и имеет право на существование. Но с точки зрения ежедневного бытия офисного программиста, это в большинстве своём реально потеря времени и сил. Так сказать, искусство ради искусства. Особенно когда речь идёт уже про интерфейсы, наследование и всё такое прочее. Это в итоге может оказаться ещё более неудобным для следующего программиста, который попытается разобраться в структуре такого legacy доставшегося уже ему по наследству. То что решается просто - должно решаться просто. В исходном коде конечно есть ад и ужас в плане тех же наименований в стиле 1С только латиницей (хотя VBA вполне себе сразу поддерживает кирилицй в названиях и переменных и функций, но это бээээ), но в целом, если задача решается, её просто можно причесать, убрать очевидные просчёты от неграмотности предыдущего программиста, а не строить проект, с десятком модулей, изящными алгоритмическими ходами "на будущее" и потратить на это всё пару дней, вместо пары часов. А через год ещё пару дней, чтобы вспомнить зачем такая структура модулей была нагорожена и прыгать по открытым вкладкам VBE вспоминая что и для чего.
Но в плане именно большого проекта, с серьезными задачами - материал безусловно достоит плюса. Для большого проекта, люто поддерживаю!
Я бы не стал утверждать, что Lua изучается за один вечер. Да, основы какие то можно понять. Но что то посерьезнее, типа работы с Global и метаобъектов, это далеко не такие простые темы.
Ну, допустим в связке python+Jupyter Notebook: а) это всё надо так же изучить и наработать опыт; б) потом что с этими данными делать дальше?
Обычный офисный работник, довольно справедливо считает, что ему не платят за познания во всё новых и новых предлагаемых для офисной работы программ, и тем более, сред. Ему нужно чтобы все было в изученном более-менее "офисе" или 1С, и чтобы работало через пару нажатий на кнопку "сделай мне красиво". Своя логика в их позиции есть. Но если у вас другие коллективы, то конечно их можно научить и таким вариантам. Но скорее всего, это не в нашем, увы неидеальном мире.
Нет, не рассматриваем, ибо решения требуются крупному заказчику, у которого уже закуплены Р7.
Там никакого костылинга не было, были локальные задачи, которые были подобным образом автоматизированы и массово внедрены в крупной организации. Их надо просто заместить, на то что есть там теперь. Нужно использовать то что есть, чтобы заместить прежние инструменты в среде MSO, на Р7+"отечественное" импорто-замещение в области СУБД.
Вот вы сами и ответили. Это коммерческая организация, и её задача зарабатывать деньги (хотя, они сейчас и в сумашедших убытках)
Работая сейчас над задачами как раз по теме перенести Excel+PowerQuery -> Р7+(хоть что нибудь и как нибудь), могу сказать что наши офисные поакеты мягко говоря не приспособлены под локальную автоматизацию. Почти всё приходится придумывать вопреки, а не благодаря разработчикам офичных пакетов. Да, со скрипом и с помощью сторонних самописных расширений кое что выходит. Сейчас вот дошли даже до интеграции с 1С Fresh и Форсайт. Но честно говоря, до уровня удобства MSO и развитости его АПИ, Р7 мягко говоря как до луны.
Ну, оно и понятно. Хотя некоторые DYIщики даже газотурбиновые двигатели умудряются клепать. Мое мнение - обратиться с прадложением по дальнейшему НИОКР в Минобороны. Тема в принципе должна их интересовать, ибо это и генератор тепла+генератор тока, без движущихся деталей. По идее вполне их тема.
Язык как язык. В чём то хороший, в чём то - так себе. Его просто грамотно использовать надо, как и любой другой яп. О чем собственно и резюме в статье. А что до рук, то я про них и не писал ничего. Многие те, кто на нём научились писать несложные обработчики для форм, вряд-ли такие уж и программисты. Но и те, кто освоил крутые фреймворки на JS, так же не факт что имеет при этом такие уж прямые руки. Всё дело в голове, если уж на то пошло.
Ну, допустим сомнительное утверждение для статьи с положительным (на момент данного комментария) числом голосов. Лично я, например, с автором согласен, хотя ни разу не фронтэндщик, и вообще к js избегал прикасаться всю свой более чем 30летний стаж в программировании.
Язык действительно во многих смыслах наляпанный по мере необходимости затыкания разных текущих дыр в вэб-программировании. Его распространённость, как раз и есть обратная сторона его бестолковости. Он очень много прощает, что не простят многие другие языки. К тому же, есть очень много готовых решений. С помощью грамотного копипаста можно много чего быстренько слепить. Но как только потребуется что то серьёзно поменять под себя, в этих многочисленных фреймворках или модульных библиотеках - пиши пропало. Искать что, где и как надо поменять порой можно до "редькиного заговения" и в итоге пишется очередной ласапед, который хоть как то исправляет ситуацию. И в этом смысле, я полностью согласен с автором. Писать надо максимально читаемый и понимаемый код, без всех новомодных синтаксических фанктиков, которые потом сменятся согласно какого нибудь нового стандарта, и уже через год-другой никто не сможет толком пояснить, что делала та или иная функция. Для формы с парой кнопок не надо тянуть за собой Angular или React. А для больших приложений, и использовать нужно уже не Electron и т.п., а что то более для этого подходящее
Это ваше субъективное мнение по содержимому статьи, на которое вы конечно имеете право, тут никто и не спорит. Но скажите, какой смысл заполнять ленту комментариев такими односложными "протестами", вместо развёрнутого, по типу того, что вы мне ответили выше? Для этого есть система оценок. Если каждый кто минусет или плюсует будет ставить ещё и комменты по типу вашего, то ни писавший, ни заинтересованный читатель, просто до полезного чего-то, что могут сказать комментаторы можно и не добраться. Есть что по делу сказать - пиши. Нет - зачем спамить в комментах своими односложными "фи", или "спасибо"!?
Так он же всё равно ответить не сможет в таком случае. Посмотрит, и всё. Или надо иметь несколько аккаунтов тогда.
А зачем тогда комментировать? Это как минимум не уважению к писавшему. Заявление по типу "Не читал Бродского, но осуждаю!" (хотя если знать контекст, то и там не всё так просто было). Можно не соглашаться с автором, даже с первых слов его работы и это - нормально! Я тоже вот не согласен с тем, что детям надо начинать программировать с HTML+ JS. Это одна из худших связок, от которой потом очень тяжело будет увести в более формализованные языки, так как учит безолаберности в коде, ибо эта связка уж слишком "прощает" ошибки разработчика, и как следствие вырабатывает в нём привычку не думать о последствиях своих действий. А это для программиста, тем более если он потом в проекте с кем то работает - очень плохо. Я встречался с такими на проектах, и потом после них переделывать приходится 90% кода. Но возвращаясь к вашей фразе, так комментировать это извините, просто хамовато по отношению к труду писавшего. Не нравится - закрой вкладку и листай дальше.
"Блаженный верующие...."(С).
Я им в техподдержку по ряду глюков и просто необходимых для хоть какой то мало мальски нужной работы требуемых изменений и дополнений писал еще прошлым летом. Из перечисленного не сделано ничего! Хотя на самом деле, правки и добавки в рамках серьезной компании не такие уж и большие, а для работы конечному пользователю они очень бы даже сгодились. Впрочем, Р7 не намного расторопнее
МойОфис подобрался куда? Там такая огромная брешь в автоматизации процессов, что просто нереально её использовать для любой маломальски серьёзной СЭД. Впрочем, как и Р7 и Open(Libre)Office (хотя, про последние я знаю и меньше, но походу внешнее управление документами тоже не про них). А если как просто замена печатной машинки\продвинутого табличного калькулятора и призентаций, то да. Но тут они все примерно равны и на уровне где то MicrosoftOffice 6.0 года этак 2000
1.Зачем? HTML априори медленнее внутренней реализации. Я сейчас борюсь с таблицами в Р7, но даже там, при том что всё почти построено на JS+HTML на ядре Chromium,сама таблица рисуется бинарным кодом где то глубоко внутри и только выводится в канву. Поверьте, тот способ общения с таблицами что есть в Excel+VBA почти идеальный вариант любой работы с ними
2.Вы что то пытаетесь разные задачи в одну запихать. Иерархические справочники (и объекты в целом) чаще всего крайне не удобны для табличных представлений, и наоборот. Не даром, умные люди очень давно разделили это всё, и в одну кучу не пихают (если что, я про визуальную составляющую GUI, а не про форматы хранения такого рода представлений). То что вы описывате для примера, можно реализовать даже на VBA, но это будет крайне глючное, и медленное решение, так как для подобного рода задач вам нужен инструмент типа Access, но никак не Excel.
А что с поясняющими картинками ?
Много странных допущений. Солнце к тому времени после этапа Красного гиганта превратиться в карлик. Земля будет поглощена на стадии Красного гиганта и поэтому отсюда уже ничего увидеть нельзя будет. И даже если Солнце с системой и выбросит за пределы галактики, то оно будет светить столь слабо, что и дня то практически не будет, а только сумерки как примерно на Марсе сейчас.