Хроника гастрит/язва в 25% случаев не ассоциирована с Helicobacter pillori и почти не поддается медикаментозному лечению, есть рецидивы. Особенно если жить нормально, полноценно :-)
До сих пор иногда использую звуковую ISA-карту ThurtleBeach Multisound Pinnacle (куплена за 600$ в 1998) с чипом Kurzweil (аналог Курца 2500) на Windows NT4. Звучит до сих пор! Ну а в те далекие времена (GigaStudio, Reality) - звук синта и качество оцифровки казались вообще занебесными.
До сих пор SNR карты и шумовая полка на 20bit ADC - уделывают каждое третье современное изделие в этом же ценовом диапазоне. А ведь карта 97-го года (26 лет прошло).
Поддерживаю и попытаюсь обосновать. Алкоголь помимо притупления чувства меры во всем, имеет низкие (почти нулевые) калории, которые слабо конвертируются в жир. Однако алкоголь имеет довольно высокий инсулиновый индекс и повышает И., отключая программу жирожсжигания на сутки.
Ну а так как "толстячки тоже закусывают" - получаем у них задержку стула, вторичную интоксикацию метаболитами алкоголя и... перечеркивание прогресса похудения за неделю-две. Алкоголь заметно портит результаты похудения и требует психологического замещения. То есть является самостоятельной проблемой.
Безусловно, люди разные. При хронических болезнях ЖКТ стоит что-либо менять крайне аккуратно и медленно. Но "ЖКТ-хроника" (гастрит/язва, холецистит, панкреатит) - антиподы ожирения. Таким людям не до переедания.
Если человек без хроники с "нажранным" ожирением не может 11 часов продержаться без еды и начинает падать в голодные обмороки - значит слабак плохо позавтракал.
На pubmed много есть про то что жиросжигание в покое начинается только при низком уровне инсулина. Но управлять этим уровнем крайне сложно. Числовая метрика - дорога в получении и тоже не особо спасает: на способность И. проникать в клетки - влияет куча факторов и она индивидуальна.
Частое дробное питание не приводит к долговрмеенному повышению уровня инсулина и глюкозы (тут тоже должна быть ссылка на pubmed). Оно - совершенно нормально! Однако при нем не возникает минимумов инсулина, с которых начинается жиросжигание. Вот суть моего "открытия". И ни один диетолог мне эту простую мысль не донес, потому что она конфликтует с цеховыми правилами этой загадочной профессии.
Более того, часть полезных низкокалорийных продуктов - резко повышают уровень инсулина (напр. кисломолочные п.) и тем самым отключают жиросжигание и диеты. Хочешь видеть на весах одно и то же число месяцами - пей перед сном стакан кефира. Хочешь пользы - пей его раньше.
"Заморочиться" было бы эффективнее с мониторингом уровня самого инсулина, но это настолько дорого, что даже фармкомпании не особо балуют РКИ-исследованиями по динамике инсулинового индекса на фоне диет и лекарств. Но думаю корреляция между уровнем глюкозы и инсулина - высокая. Возможность хоть что-то точно измерить кроме веса и объема талии - дорогого стоит в подобного рода жизненных изменениях.
Есть холдинги где есть "все отделы", нет отделов из "одного человека", есть даже IT-безопасники, тестировщики и кодящие продажники. И вообще все штатное расписание - заполнено целиком. Но в них работает лишь 30% работников.
А вот другой части, 70% работников, повезло работать в "конторках" МСБ, где просто нет нужных отделов, есть отделы из одного человека и жуткая нагрузка из-за совмещения должностей. Вот именно про такой случай статья, и случай этот - массовый. Если прогер грамотно стал продавать - честь и хвала такому специалисту.
Многие звезды не только рерайтят райдер, но и сами своими занимаются концертами. Главврач занимается таким широким фронтом дел, что "продажа полисов ДМС" априори входит в их число. Я из семьи главврачей, насмотрелся :-)
Не вижу в удачном совмещении должностей чего-то неправильного. Спецы узкого профиля часто не закрывают многообразия изменчивого мира. У айтишников в силу кругозора, доступности самообучения и системности мышления - хорошие потенциал к full-stack и full-competence.
Многим привыкшим завтракать - предложенная автором интервальная диета 16/8 "не влезет" в 40-часовой график работы 8:00-17:00 с +1 или +2 часа сдвигом в крупных городах. Вот рабочее решение этой проблемы:
Личный опыт: работаю за городом 8:00-17:00, поэтому неизбежен завтрак в 07:00, а ужин - в 18:00 (получается схема 13/11, она далека от "методичек" и 16/8 автора статьи). Я сделал отрезки 11 и 13 часов - без обеда и к-либо перекусов. Получилось 2-х разовое, ничем не ограниченное питание 5 дней в неделю. В Сб/Вс - cheat meal, никаких ограничений ни по времени, ни по числу жоров. Спортзала нет, но 5 кг гантельки иногда дергаю, когда вспомню.
Результат: за 12 месяцев - плавно минус 24 кг (104 -> 80 кг, рост 176), результат удерживается 2 года, колебания веса +/-1,5 кг. Колебания, естественно, только после срывов, читмилов и праздников.
Почему это работает и жир, в т.ч. висцеральный, сам уходит (моя версия): как только мы перестаем есть совсем - уровень инсулина падает плавно и неуклонно, практически по прямой. Измерял глюкометром ежечасно 2 недели, потому что мог и чертовски хотелось хоть какой-то "научной" базы. Падению инсулина, как оказалось, не мешает ничто: ни чай/кофе без молока и сахара, ни совещания, ни кодинг, ни гантельки, ни сон. Главное не мешать ему падать (не есть ничего).
Так вот, по достижению какого-то индивидуального релевантного уровня глюкозы в крови (в моем случае 5,4 ммол/л) - начинается всеобъемлющее сжигание жира организмом. Это время наступает ночью в 1-3 часа и днем в 13-15:00. Ощущается наступление этого времени как легкое, проходящее за 10-15 минут недомогание/жар (стоит выпить воды/кофе/чаю без ничего). Неожиданный бонус: активное послеобеденное время. С полным желудком - 80% офиса сразу после обеда хотя спать неимоверно. У меня же, без обеда, - бодряк.
А мне наоборот. понравилось решение автора статьи и системные, программистские подходы в нем.
Технологии продаж обязаны эволюционировать, а продаж в IT - должны и вовсе "скакать" по стенам бытия, как и сами IT-технологии. Пока же мы, покупатели IT-решений. больше видим скучный "стандарт": кислые холодные встречи, заученных и прилизанных консультантов и ложь по срокам, суммам, эффектам. Демо-базы - полнейшая туфта с датами пятилетней давности. Загадочность и намеки на откатинг - в каждом втором разговоре. Референсы, как обычно, есть, но недоступны. И есть подозрение почему состоявшиеся референс-визиты даже превосходят россказни консалтеров. там все заряжено/ангажировано.
В тех же случаях когда есть не простой инсайдер, а нахантенный сотрудник - всплывает настолько неприглядный "хвост" из нерешенных проблем внедрений, что проще подождать другое ПО от нового вендора. Или перейти на opensource, который можно допилить самому, не давая собственнику "чахнуть над златом" и экономить на том, на чем только и удается чисто технически (на ЗП персонала).
Каждый из них применим, каждый можно похвалить за "находки" и удобные приемы. Многие есть за что поругать: старые зависимости (и необходимость использовать виртуальные среды), кое-где есть платный функционал (в Python и DS все привыкли что всё - бесплатно).
Общая точкой притяжения у либ, как ни странно - Pandas. Как верно заметил автор, бывает сложно найти нужную команду. Я проводил эксперимент на десяти "Excel-уверенных" людях: Что проще - pd.merge/pd.concat (~50 символов набрать) в Pandas или GUI-слияние в EDA-либах (50 раз кликнуть мышью)? На удивление - Pandas в JupyterLab в 64% случаев был назван более удобным, чем EDA-интерфейсы.
Радует также, что многие EDA-либы продуцируют поучительный Python-код. Он понятен благодаря простому синтаксису, даже несмотря на наличие "мусора" или сложных паттернов вроде списковых включений.
Мы все знаем как важно видеть трансляцию действий в код. С 1995 г. благодаря макрорекордеру VBA в Excel - миллионы людей узнали что такое программирование и многие таки-стали программистами. Авто-код - эдакий мостик между мирами бесправного юзерства и всемогущего кодерства. Вклад VBA в автоматизацию российского и немецкого бизнеса - колоссален, хоть и в чем-то постыден для отрасли (и многими скрывается). Фразу "убери VBA из резюме" можно услышать от многих HR. VBA ругают просто так все кому не лень. При этом все понимают что с 1995 по 2014 гг. - альтернативы ему не было.
SQL, Pandas и EDA-либы - исправляют эту ситуацию в значительной мере, приближая тотальную цифровизацию офисного труда. Сил айтишников для решения задач бизнеса сейчас явно недостаточно. Ростом зарплат проблему не решить, нужны выходцы "снизу". Те, кто зная предметную область - сами делают MVP, без ТЗ, сразу в прод. Открытые долгоиграющие продукты, вроде Pandas - позволяют делать ревью и помогать людям и бизнесу, постепенно спрыгивая с "иглы" VBA.
Согласен. Добавлю реальных цифр для понимания. Покупая "коробку тиражного решения 1С:ERP" на работающее предприятие за 1 млн. руб. - нужно быть морально и финансово готовым потратить еще 1-2 млн. руб. на более мощные сервер, СХД, сетевое оборудование и от 2 до 4 млн. руб. на своих или чужих IT-шников для внедрения.
Если эти ресурсы есть, а также есть несокрушимая воля собственника и всеобщее понимание что корпоративная система ресурсного планирования (суть ERP) принесет ощутимую пользу (она не первоочередная и далеко не единственная, кстати) - то тогда вперед! Но сроки нужно ставить реальные (год+ для бухупручета, 2+ для MRP и бюджетирования).
К сожалению (или к счастью?), большинство собственников, услышав такие "вводные" - откладывает идею "на потом". Все-таки это немалые ресурсы, а ROI от ERP посчитать сложно. В открытом доступе мы не найдем ТЭО к ТЗ или аналитики. Хуже когда решили что "ввяжемся в бой, потом посмотрим". Такие эксперименты конкретный бизнес может не пережить.
Есть ли ERP дешевле? - не знаю, бюджеты таких проектов строго засекречены или нагло перевраны на корпоративных порталах и СМИ. Есть ли ERP СПО-проекты - наверное, сделанные с "натяжкой", есть: Compiere, Odoo итп. У Odoo тысячи инсталляций в ЕС, но что интересно, предприятия - средние по размеру.
Можно ли заменить ERP лоскутной автоматизацией? Можно ли вообще жить крупному бизнесу без ERP? Наверное да, раз он вырос до крупного - значит точно не "умер". Сама идея "непрерывно взаимоувязанно перепланировать все аспекты деятельности" - увы, в изменчивой среде работает плохо и не становится инструментом управления. Но стоит все-таки дешевле чем вертолет.
Хорошие скрипты. Для любителей файлового менеджера Nautilus (он, вдобавок, умеет отображать мета-свойства файла в отдельных столбцах: автора, комментарий, ключевые слова, название документа итд) - так вот для Nautilus можно писать подобные PDF-скрипты на Python, с интеграцией в меню. Возможно их уже написано много, но написать свой под свой МФУ/документооборот/бизнес-процесс - не только зачетно, но и порой остро необходимо. В экосистеме Python много свободных PDF-либ для любых манипуляций:
segno - лучшая вставка QR и DataMatrix-кодов в готовый PDF
Справедливости ради стоит вспомнить что в истории человечества были длинные периоды (по неск. веков подряд), когда в живописи не происходило решительно ничего.
Те же Малевич, Кандинский, Петров-Водкин и др. - "выстрелили" со своим выпендрежем (читай - новаторством) - на фоне глобальных политических перемен, после разрухи, войн и культурологического "голода", на фоне привлекающей социализма как нового явления. То есть для них "было место". Есть ли это место сейчас для живописи от ИИ - вопрос. Но ИИ точно дождется своего часа в силу того что он не ограничен 75 годами жизни. И да, он креативен, потому что рандомизирует подбор вывод как и все ML.
Даже великий Моцарт баловался фигней: брызгал щеткой чернила на нотный стан и пытался "это" сыграть. Вылилось ли это хоть в одно толковое произведение - биографы не выяснили. Но факт был.
в metabase будет автокомплит по полям таблицы и результат запроса можно сразу же визуализировать и расшарить всем заинтересованным людям и он сам будет обновляться
Добавлю немного объективности кейса "DS-всезнайки с ноутом на совещяании". В JupyterLab (это полноценная web-IDE с пошаговой отладкой, стеком вызовов и внятным окном значений переменных) - автокомплит не только по именам полей таблиц, но и по важнейшим аналитическим сущностям (в терминологии 1С это т.н. "субконто") - по сути это текстовые переменные с оч. длинным именем, которые код формирует сам. У меня их 10k (названия основных материалов, подразделений итд). В основном это крупные сущности - папки справочников (в терминах 1С - "группы"), на которых и строится основная аналитика. Metabase крут и даже можно предположить что он локально развернут на ноуте датасататниста, но все же для ad-hoc аналитики "на совещании" он уступит Юпитеру в оперативности, в нем нет IDE, нет автокомплита переменных, он для витрин и RDBMS. А что позволено Юпитеру...
Сразу же визаулизировать - это прямо точно про Pandas. Ее метод df.plot() скопировали/повторили почти все графические либы: plotly, bokeh, vega итд. Там где в метабэйз пондобятся десятки кликов для простого графика - Pandas уже выведет график. Но это еще не всё. У меня написана UDF-обертка поверх plot(), дающая возможность одним аргументом из трех букв построить 10k разных графиков (10 периодов * 10 типов графиков * 2 компоновки * 10 статистик * 5 бэкендов). С этой оберткой визуализация стала проще численных стат-методов. Каждый график не просто строится сам, но еще и содержит динамический заголовок, констатирующий факт в человечной форме, типа "Динамика продаж: рост за 5 лет в 2 раза".
Полученный таким образом в Юпитере недо-dashboard живет в web-сервере, и может быть расшарен на проектор и смарт-тв переговорки по WiFi/BT. Плюс есть atoti, voila, panel, streamlit и др. для того чтобы сделать это красиво и много-пользовательски. Но это следующий уровень, и Metabase, Superset и все озвученные персоналии - хорошие инструменты для большой команды.
Да и питонисты плюются от питона. Нет идеальных инструментов, есть любимые. И почти все умеют в несколько языков, просто не всегда в этом охотно признаются.
Clickhouse мощен, спору нет. И витрины хороши, когда их кто-то для вас сделал. Но не на совещании всем этим заниматься - там действительно идет счет на секунды. Туда же лесом идут DAX и PowerPivot: только их одних - недостаточно, а платность - сильно против массовости. Своих детей я учить им не буду. Парой кликов там связь не создать, и сравнивать их с Pandas, пожалуй, уже поздно.
Очень люблю бенчмарки, и ссылку, конечно же, читал. "Однокотловый" Pandas медленный, но отвечает на любой мой запрос по бухучету по базе за 20 лет со скоростью 0,1-1 секунда. Да, индексы упорядочены, типа категоризованы и оптимальны, но раз это основной инструмент - почему бы и нет? Кликхауз это время не улучшает, а если и улучшит - то неосязаемо. Polars - еще быстрей, тот же Pandas, но и в нем нет потребности, когда и так результат - "сразу".
DS - те же аналитики, только толще. Нет разницы на чем запрашивать - на SQL или в Pandas. Но Pandas из-за RAM будет быстрее в десятки раз чем RDBMS. И да, она реальна на совещании. Не верю что кому-то по wifi из переговорки дают стучаться в прод-базу, с ноута, SELECT-ом с оконными функциями. Я бы и сам этого не стал делать. А вот в локальный 20 мегабайтный PKL - стучусь. Он вмещает 40-гигабайтную базу 1С.
Лицензия запрещает работать с БД напрямую, минуя оболочки 1С. Да и причем тут 1С - в ней нет всех данных. Приходится объединять c CSV/Excel-файлами, и Pandas тут "рулит".
Переиспользование кода в случае с SQL почти невозможно. Сравнивать журнал запросов, скажем, dBeaver и Jupyter-блокнот, не теряющим значения переменных для вычисленных ячеек - несерьезно.
Poetry сложнее чем venv-ы, до нее тоже надо "дорасти", либо сразу родиться большим. Poetry тоже не решает проблему до конца, как не решает ее ни один из подобных инструментов. Проблема pip-зависимостей - сильно преувеличена, хотя не скрою: по-первой она обескураживает до чертиков.
Но решения есть, о них написано всюду. Причиной отказа от сабжа - "проблема" может быть лишь в крайне заангажироанных или токсичных случаях, разобраться в которых часто не удается никому.
Языки программирования - да, меняют. Но это тоже "шок", имеющий свою цену. В любом крупном офисе найдется старое, полуживое ПО, которое не трогают, потому что оно работает. Это тоже неплохая, а главное простая тактика обеспечения работоспособности систем. Вот живет у нас на Python 2 на сервере под Vista с 4Гб RAM настоящая CRM/EDM-система уже 13 лет и не дохнет. Поменяем? - Да. Завтра? - Нет. И так уже 10 лет с окончания техподдержки. Думаю такой случай не единичен.
Осталось всех DS-тов пересадить с Python на стат/компиляторы и мощные десктопы - и заживем! Тут показателен пример с языком Julia: она все никак не убьет питон в DS.
И еще один парадокс - заметный рост числа и доли проектов для микроконтроллеров и realtime-проектов на MicroPython (и еще двух его клонах). Казалось бы - зачем он тут? Но люди упорно выбирают именно понравившийся инструмент вместо того, который навязывают. Значит плюсы таки-есть.
Вы обиделись на питонистов? В DS пришли не питонисты, а DS-ты, от которых требуют не код, а идеи, решения, выводы, графики, презентации, ML-модели. Времени у них, поверьте, чуть меньше чем у кодеров, сидящих "на техзадании+Git", потому что DS-ники работают на виду у руководства, часто это топ-менеджер. Динамический Python-интерпретатор позволяет ему быстрее писать как код с ошибками, так и код без ошибок. Но время - важнее.
Этим объясняется успех IPython, Jupyter/Lab и ipynb-блокнотов в бизнес-среде. Сейчас проникновение этих технологий сравнимо с пришествием в бизнес Excel, породившем такое понятие как personal computer.
Прямо во время совещания DS-ник "за минуту" на нотубуке в блокноте на Python готов ответить на любой вопрос вида "Сколько у нас в отделе разработки уволилось за время царствования г-на Петрова по сравнению с другими начальниками? " или "Почем мы покупали в прошлом квартале известь у всех, кроме ООО Ромашка и поставщиков от Петрова?
На статическом компилируемом языке - вы за эту минуту не объявите даже все переменные. 1C таких ответов не даст вообще или даст за 20 минут. А DS-ник на Python таки-выдаст ответы на эти вопросы, поймав 2-3 раза ошибку. Но результат он даст.
Время на компиляцию. Нет той глубины интроспекции кода из библиотек. Не та отладка. В DataScience, где итерация не просто часты, а необходимы - код который компилится быстро утомит.
Хроника гастрит/язва в 25% случаев не ассоциирована с Helicobacter pillori и почти не поддается медикаментозному лечению, есть рецидивы. Особенно если жить нормально, полноценно :-)
До сих пор иногда использую звуковую ISA-карту ThurtleBeach Multisound Pinnacle (куплена за 600$ в 1998) с чипом Kurzweil (аналог Курца 2500) на Windows NT4. Звучит до сих пор! Ну а в те далекие времена (GigaStudio, Reality) - звук синта и качество оцифровки казались вообще занебесными.
До сих пор SNR карты и шумовая полка на 20bit ADC - уделывают каждое третье современное изделие в этом же ценовом диапазоне. А ведь карта 97-го года (26 лет прошло).
Поддерживаю и попытаюсь обосновать. Алкоголь помимо притупления чувства меры во всем, имеет низкие (почти нулевые) калории, которые слабо конвертируются в жир. Однако алкоголь имеет довольно высокий инсулиновый индекс и повышает И., отключая программу жирожсжигания на сутки.
Ну а так как "толстячки тоже закусывают" - получаем у них задержку стула, вторичную интоксикацию метаболитами алкоголя и... перечеркивание прогресса похудения за неделю-две. Алкоголь заметно портит результаты похудения и требует психологического замещения. То есть является самостоятельной проблемой.
Безусловно, люди разные. При хронических болезнях ЖКТ стоит что-либо менять крайне аккуратно и медленно. Но "ЖКТ-хроника" (гастрит/язва, холецистит, панкреатит) - антиподы ожирения. Таким людям не до переедания.
Если человек без хроники с "нажранным" ожирением не может 11 часов продержаться без еды и начинает падать в голодные обмороки - значит
слабакплохо позавтракал.На pubmed много есть про то что жиросжигание в покое начинается только при низком уровне инсулина. Но управлять этим уровнем крайне сложно. Числовая метрика - дорога в получении и тоже не особо спасает: на способность И. проникать в клетки - влияет куча факторов и она индивидуальна.
Частое дробное питание не приводит к долговрмеенному повышению уровня инсулина и глюкозы (тут тоже должна быть ссылка на pubmed). Оно - совершенно нормально! Однако при нем не возникает минимумов инсулина, с которых начинается жиросжигание. Вот суть моего "открытия". И ни один диетолог мне эту простую мысль не донес, потому что она конфликтует с цеховыми правилами этой загадочной профессии.
Более того, часть полезных низкокалорийных продуктов - резко повышают уровень инсулина (напр. кисломолочные п.) и тем самым отключают жиросжигание и диеты. Хочешь видеть на весах одно и то же число месяцами - пей перед сном стакан кефира. Хочешь пользы - пей его раньше.
"Заморочиться" было бы эффективнее с мониторингом уровня самого инсулина, но это настолько дорого, что даже фармкомпании не особо балуют РКИ-исследованиями по динамике инсулинового индекса на фоне диет и лекарств. Но думаю корреляция между уровнем глюкозы и инсулина - высокая. Возможность хоть что-то точно измерить кроме веса и объема талии - дорогого стоит в подобного рода жизненных изменениях.
Есть холдинги где есть "все отделы", нет отделов из "одного человека", есть даже IT-безопасники, тестировщики и кодящие продажники. И вообще все штатное расписание - заполнено целиком. Но в них работает лишь 30% работников.
А вот другой части, 70% работников, повезло работать в "конторках" МСБ, где просто нет нужных отделов, есть отделы из одного человека и жуткая нагрузка из-за совмещения должностей. Вот именно про такой случай статья, и случай этот - массовый. Если прогер грамотно стал продавать - честь и хвала такому специалисту.
Многие звезды не только рерайтят райдер, но и сами своими занимаются концертами. Главврач занимается таким широким фронтом дел, что "продажа полисов ДМС" априори входит в их число. Я из семьи главврачей, насмотрелся :-)
Не вижу в удачном совмещении должностей чего-то неправильного. Спецы узкого профиля часто не закрывают многообразия изменчивого мира. У айтишников в силу кругозора, доступности самообучения и системности мышления - хорошие потенциал к full-stack и full-competence.
Многим привыкшим завтракать - предложенная автором интервальная диета 16/8 "не влезет" в 40-часовой график работы 8:00-17:00 с +1 или +2 часа сдвигом в крупных городах. Вот рабочее решение этой проблемы:
Личный опыт: работаю за городом 8:00-17:00, поэтому неизбежен завтрак в 07:00, а ужин - в 18:00 (получается схема 13/11, она далека от "методичек" и 16/8 автора статьи). Я сделал отрезки 11 и 13 часов - без обеда и к-либо перекусов. Получилось 2-х разовое, ничем не ограниченное питание 5 дней в неделю. В Сб/Вс - cheat meal, никаких ограничений ни по времени, ни по числу жоров. Спортзала нет, но 5 кг гантельки иногда дергаю, когда вспомню.
Результат: за 12 месяцев - плавно минус 24 кг (104 -> 80 кг, рост 176), результат удерживается 2 года, колебания веса +/-1,5 кг. Колебания, естественно, только после срывов, читмилов и праздников.
Почему это работает и жир, в т.ч. висцеральный, сам уходит (моя версия): как только мы перестаем есть совсем - уровень инсулина падает плавно и неуклонно, практически по прямой. Измерял глюкометром ежечасно 2 недели, потому что мог и чертовски хотелось хоть какой-то "научной" базы. Падению инсулина, как оказалось, не мешает ничто: ни чай/кофе без молока и сахара, ни совещания, ни кодинг, ни гантельки, ни сон. Главное не мешать ему падать (не есть ничего).
Так вот, по достижению какого-то индивидуального релевантного уровня глюкозы в крови (в моем случае 5,4 ммол/л) - начинается всеобъемлющее сжигание жира организмом. Это время наступает ночью в 1-3 часа и днем в 13-15:00. Ощущается наступление этого времени как легкое, проходящее за 10-15 минут недомогание/жар (стоит выпить воды/кофе/чаю без ничего). Неожиданный бонус: активное послеобеденное время. С полным желудком - 80% офиса сразу после обеда хотя спать неимоверно. У меня же, без обеда, - бодряк.
А мне наоборот. понравилось решение автора статьи и системные, программистские подходы в нем.
Технологии продаж обязаны эволюционировать, а продаж в IT - должны и вовсе "скакать" по стенам бытия, как и сами IT-технологии. Пока же мы, покупатели IT-решений. больше видим скучный "стандарт": кислые холодные встречи, заученных и прилизанных консультантов и ложь по срокам, суммам, эффектам. Демо-базы - полнейшая туфта с датами пятилетней давности. Загадочность и намеки на откатинг - в каждом втором разговоре. Референсы, как обычно, есть, но недоступны. И есть подозрение почему состоявшиеся референс-визиты даже превосходят россказни консалтеров. там все заряжено/ангажировано.
В тех же случаях когда есть не простой инсайдер, а нахантенный сотрудник - всплывает настолько неприглядный "хвост" из нерешенных проблем внедрений, что проще подождать другое ПО от нового вендора. Или перейти на opensource, который можно допилить самому, не давая собственнику "чахнуть над златом" и экономить на том, на чем только и удается чисто технически (на ЗП персонала).
Полезная статья. Экосистема Python регулярно пополняется EDA-инструментами, вот мой неполный чек-лист: autoviz, bamboolib, dabl, dataprep, datasette, dtale, lux, mitosheet, pandas_profiling, pandasgui, sweetviz.
Каждый из них применим, каждый можно похвалить за "находки" и удобные приемы. Многие есть за что поругать: старые зависимости (и необходимость использовать виртуальные среды), кое-где есть платный функционал (в Python и DS все привыкли что всё - бесплатно).
Общая точкой притяжения у либ, как ни странно - Pandas. Как верно заметил автор, бывает сложно найти нужную команду. Я проводил эксперимент на десяти "Excel-уверенных" людях: Что проще - pd.merge/pd.concat (~50 символов набрать) в Pandas или GUI-слияние в EDA-либах (50 раз кликнуть мышью)? На удивление - Pandas в JupyterLab в 64% случаев был назван более удобным, чем EDA-интерфейсы.
Радует также, что многие EDA-либы продуцируют поучительный Python-код. Он понятен благодаря простому синтаксису, даже несмотря на наличие "мусора" или сложных паттернов вроде списковых включений.
Мы все знаем как важно видеть трансляцию действий в код. С 1995 г. благодаря макрорекордеру VBA в Excel - миллионы людей узнали что такое программирование и многие таки-стали программистами. Авто-код - эдакий мостик между мирами бесправного юзерства и всемогущего кодерства. Вклад VBA в автоматизацию российского и немецкого бизнеса - колоссален, хоть и в чем-то постыден для отрасли (и многими скрывается). Фразу "убери VBA из резюме" можно услышать от многих HR. VBA ругают просто так все кому не лень. При этом все понимают что с 1995 по 2014 гг. - альтернативы ему не было.
SQL, Pandas и EDA-либы - исправляют эту ситуацию в значительной мере, приближая тотальную цифровизацию офисного труда. Сил айтишников для решения задач бизнеса сейчас явно недостаточно. Ростом зарплат проблему не решить, нужны выходцы "снизу". Те, кто зная предметную область - сами делают MVP, без ТЗ, сразу в прод. Открытые долгоиграющие продукты, вроде Pandas - позволяют делать ревью и помогать людям и бизнесу, постепенно спрыгивая с "иглы" VBA.
Согласен. Добавлю реальных цифр для понимания. Покупая "коробку тиражного решения 1С:ERP" на работающее предприятие за 1 млн. руб. - нужно быть морально и финансово готовым потратить еще 1-2 млн. руб. на более мощные сервер, СХД, сетевое оборудование и от 2 до 4 млн. руб. на своих или чужих IT-шников для внедрения.
Если эти ресурсы есть, а также есть несокрушимая воля собственника и всеобщее понимание что корпоративная система ресурсного планирования (суть ERP) принесет ощутимую пользу (она не первоочередная и далеко не единственная, кстати) - то тогда вперед! Но сроки нужно ставить реальные (год+ для бухупручета, 2+ для MRP и бюджетирования).
К сожалению (или к счастью?), большинство собственников, услышав такие "вводные" - откладывает идею "на потом". Все-таки это немалые ресурсы, а ROI от ERP посчитать сложно. В открытом доступе мы не найдем ТЭО к ТЗ или аналитики. Хуже когда решили что "ввяжемся в бой, потом посмотрим". Такие эксперименты конкретный бизнес может не пережить.
Есть ли ERP дешевле? - не знаю, бюджеты таких проектов строго засекречены или нагло перевраны на корпоративных порталах и СМИ. Есть ли ERP СПО-проекты - наверное, сделанные с "натяжкой", есть: Compiere, Odoo итп. У Odoo тысячи инсталляций в ЕС, но что интересно, предприятия - средние по размеру.
Можно ли заменить ERP лоскутной автоматизацией? Можно ли вообще жить крупному бизнесу без ERP? Наверное да, раз он вырос до крупного - значит точно не "умер". Сама идея "непрерывно взаимоувязанно перепланировать все аспекты деятельности" - увы, в изменчивой среде работает плохо и не становится инструментом управления. Но стоит все-таки дешевле чем вертолет.
Хорошие скрипты. Для любителей файлового менеджера Nautilus (он, вдобавок, умеет отображать мета-свойства файла в отдельных столбцах: автора, комментарий, ключевые слова, название документа итд) - так вот для Nautilus можно писать подобные PDF-скрипты на Python, с интеграцией в меню. Возможно их уже написано много, но написать свой под свой МФУ/документооборот/бизнес-процесс - не только зачетно, но и порой остро необходимо. В экосистеме Python много свободных PDF-либ для любых манипуляций:
segno - лучшая вставка QR и DataMatrix-кодов в готовый PDF
PyPDF2 - простая нумерация страниц и др. операции
pypdftk - разрезка/склейка/поворот/закладки/метаинформация
PyMuPDF - вообще почти все мыслимые манипуляции
Справедливости ради стоит вспомнить что в истории человечества были длинные периоды (по неск. веков подряд), когда в живописи не происходило решительно ничего.
Те же Малевич, Кандинский, Петров-Водкин и др. - "выстрелили" со своим выпендрежем (читай - новаторством) - на фоне глобальных политических перемен, после разрухи, войн и культурологического "голода", на фоне привлекающей социализма как нового явления. То есть для них "было место". Есть ли это место сейчас для живописи от ИИ - вопрос. Но ИИ точно дождется своего часа в силу того что он не ограничен 75 годами жизни. И да, он креативен, потому что рандомизирует подбор вывод как и все ML.
Даже великий Моцарт баловался фигней: брызгал щеткой чернила на нотный стан и пытался "это" сыграть. Вылилось ли это хоть в одно толковое произведение - биографы не выяснили. Но факт был.
Добавлю немного объективности кейса "DS-всезнайки с ноутом на совещяании". В JupyterLab (это полноценная web-IDE с пошаговой отладкой, стеком вызовов и внятным окном значений переменных) - автокомплит не только по именам полей таблиц, но и по важнейшим аналитическим сущностям (в терминологии 1С это т.н. "субконто") - по сути это текстовые переменные с оч. длинным именем, которые код формирует сам. У меня их 10k (названия основных материалов, подразделений итд). В основном это крупные сущности - папки справочников (в терминах 1С - "группы"), на которых и строится основная аналитика. Metabase крут и даже можно предположить что он локально развернут на ноуте датасататниста, но все же для ad-hoc аналитики "на совещании" он уступит Юпитеру в оперативности, в нем нет IDE, нет автокомплита переменных, он для витрин и RDBMS. А что позволено Юпитеру...
Сразу же визаулизировать - это прямо точно про Pandas. Ее метод df.plot() скопировали/повторили почти все графические либы: plotly, bokeh, vega итд. Там где в метабэйз пондобятся десятки кликов для простого графика - Pandas уже выведет график. Но это еще не всё. У меня написана UDF-обертка поверх plot(), дающая возможность одним аргументом из трех букв построить 10k разных графиков (10 периодов * 10 типов графиков * 2 компоновки * 10 статистик * 5 бэкендов). С этой оберткой визуализация стала проще численных стат-методов. Каждый график не просто строится сам, но еще и содержит динамический заголовок, констатирующий факт в человечной форме, типа "Динамика продаж: рост за 5 лет в 2 раза".
Полученный таким образом в Юпитере недо-dashboard живет в web-сервере, и может быть расшарен на проектор и смарт-тв переговорки по WiFi/BT. Плюс есть atoti, voila, panel, streamlit и др. для того чтобы сделать это красиво и много-пользовательски. Но это следующий уровень, и Metabase, Superset и все озвученные персоналии - хорошие инструменты для большой команды.
Да и питонисты плюются от питона. Нет идеальных инструментов, есть любимые. И почти все умеют в несколько языков, просто не всегда в этом охотно признаются.
Clickhouse мощен, спору нет. И витрины хороши, когда их кто-то для вас сделал. Но не на совещании всем этим заниматься - там действительно идет счет на секунды. Туда же лесом идут DAX и PowerPivot: только их одних - недостаточно, а платность - сильно против массовости. Своих детей я учить им не буду. Парой кликов там связь не создать, и сравнивать их с Pandas, пожалуй, уже поздно.
Очень люблю бенчмарки, и ссылку, конечно же, читал. "Однокотловый" Pandas медленный, но отвечает на любой мой запрос по бухучету по базе за 20 лет со скоростью 0,1-1 секунда. Да, индексы упорядочены, типа категоризованы и оптимальны, но раз это основной инструмент - почему бы и нет? Кликхауз это время не улучшает, а если и улучшит - то неосязаемо. Polars - еще быстрей, тот же Pandas, но и в нем нет потребности, когда и так результат - "сразу".
DS - те же аналитики, только толще. Нет разницы на чем запрашивать - на SQL или в Pandas. Но Pandas из-за RAM будет быстрее в десятки раз чем RDBMS. И да, она реальна на совещании. Не верю что кому-то по wifi из переговорки дают стучаться в прод-базу, с ноута, SELECT-ом с оконными функциями. Я бы и сам этого не стал делать. А вот в локальный 20 мегабайтный PKL - стучусь. Он вмещает 40-гигабайтную базу 1С.
Лицензия запрещает работать с БД напрямую, минуя оболочки 1С. Да и причем тут 1С - в ней нет всех данных. Приходится объединять c CSV/Excel-файлами, и Pandas тут "рулит".
Переиспользование кода в случае с SQL почти невозможно. Сравнивать журнал запросов, скажем, dBeaver и Jupyter-блокнот, не теряющим значения переменных для вычисленных ячеек - несерьезно.
Poetry сложнее чем venv-ы, до нее тоже надо "дорасти", либо сразу родиться большим. Poetry тоже не решает проблему до конца, как не решает ее ни один из подобных инструментов. Проблема pip-зависимостей - сильно преувеличена, хотя не скрою: по-первой она обескураживает до чертиков.
Но решения есть, о них написано всюду. Причиной отказа от сабжа - "проблема" может быть лишь в крайне заангажироанных или токсичных случаях, разобраться в которых часто не удается никому.
Языки программирования - да, меняют. Но это тоже "шок", имеющий свою цену. В любом крупном офисе найдется старое, полуживое ПО, которое не трогают, потому что оно работает. Это тоже неплохая, а главное простая тактика обеспечения работоспособности систем. Вот живет у нас на Python 2 на сервере под Vista с 4Гб RAM настоящая CRM/EDM-система уже 13 лет и не дохнет. Поменяем? - Да. Завтра? - Нет. И так уже 10 лет с окончания техподдержки. Думаю такой случай не единичен.
Осталось всех DS-тов пересадить с Python на стат/компиляторы и мощные десктопы - и заживем! Тут показателен пример с языком Julia: она все никак не убьет питон в DS.
И еще один парадокс - заметный рост числа и доли проектов для микроконтроллеров и realtime-проектов на MicroPython (и еще двух его клонах). Казалось бы - зачем он тут? Но люди упорно выбирают именно понравившийся инструмент вместо того, который навязывают. Значит плюсы таки-есть.
Вы обиделись на питонистов? В DS пришли не питонисты, а DS-ты, от которых требуют не код, а идеи, решения, выводы, графики, презентации, ML-модели. Времени у них, поверьте, чуть меньше чем у кодеров, сидящих "на техзадании+Git", потому что DS-ники работают на виду у руководства, часто это топ-менеджер. Динамический Python-интерпретатор позволяет ему быстрее писать как код с ошибками, так и код без ошибок. Но время - важнее.
Этим объясняется успех IPython, Jupyter/Lab и ipynb-блокнотов в бизнес-среде. Сейчас проникновение этих технологий сравнимо с пришествием в бизнес Excel, породившем такое понятие как personal computer.
Прямо во время совещания DS-ник "за минуту" на нотубуке в блокноте на Python готов ответить на любой вопрос вида "Сколько у нас в отделе разработки уволилось за время царствования г-на Петрова по сравнению с другими начальниками? " или "Почем мы покупали в прошлом квартале известь у всех, кроме ООО Ромашка и поставщиков от Петрова?
На статическом компилируемом языке - вы за эту минуту не объявите даже все переменные. 1C таких ответов не даст вообще или даст за 20 минут. А DS-ник на Python таки-выдаст ответы на эти вопросы, поймав 2-3 раза ошибку. Но результат он даст.
Время на компиляцию. Нет той глубины интроспекции кода из библиотек. Не та отладка. В DataScience, где итерация не просто часты, а необходимы - код который компилится быстро утомит.