А зачем делать что-то «в принципе эквивалентное SQL», если можно сделать прям самый настоящий SQL?
И если речь не о питоне, то о каком API? API ведь к языку привязано, не бывает сферического API в вакууме без указания языка. Даже если имеется в виду проекция одних и тех же методов некой объектной модели, в разных языках они никогда не будут эквивалентными. Так что я не очень понимаю, чего именно вы хотите. И для кого.
Я вот на запросы своих аналитиков ориентируюсь, с моего проекта.
Насмотревшись, что и как аналитики пишут на питоне (а на чём их ещё можно заставить писать?), я не могу согласиться с вашим пожеланием.
Питон язык отличный, не требующий программистского мышления, но он слишком высокоуровневый. За одним неосторожным обращением к свойству там легко может такая цепочка событий развернуться, что кластер будет просто стоять колом какое-то время. И если нужно каждый день инджестить сотню терабайт даты, то писать процессы на питоне — это верная смерть, какой бы крутой очередная кастомная обёртка над Dataset или Dataframe ни была.
По крайней мере, если ты не контора, которая железом закидывает код любой степени неоптимальности. То есть, крупняк какой-нибудь, типа телекомов. Ну, у них действительно есть такие инструменты, которые дают именно API. Но толку-то — это всё плохо отчуждаемые инструменты.
Поэтому мой выбор — ограниченный и заточенный под одну конкретную задачу диалект SQL, на котором заведомо что попало не напишешь. Впрочем, в следующий частях местами будет и что попало :)
Для японцев наличие учителя человека тоже обязательно. Сами они по документации почему-то не умеют ничего понимать, надо обязательно рассказывать, а лучше показывать. А если за спиной стоять, то схватывают как суперклей, с первого раза и навсегда.
С китайцами я не работал, зато довелось с японцами (из NTT DoCoMo, контора тоже масштаба немаленького), и впечатления довольно схожие. Жёсткая иерархичность, конкуренция без агрессии, неумение ждать без беганья по кругу, и они тоже никогда не говорят «нет» напрямую. Любого, кто провёл в энтерпрайзе западного образца несколько лет, это всё раздражает неимоверно.
Но у ихних технарей есть особая фишка: невероятная обучаемость. Достаточно один раз показать, как сделать более лучше (а «более лучше» в их понимании это «более эффективно»), и в дальнейшем процесс будет работать как часы, каким бы сложным ни был. Иероглифическая письменность таки в самом деле затачивает мозг на быстрое запоминание и воспроизведение шаблонов.
BTW, из забавного — за последние три года меня несколько раз звали в Хуавей, и каждый раз это был другой отдел :) И каждый раз другой HR находил меня самостоятельно, так что разные части конторы, по ходу, и в самом деле между собой совсем не дружат. Но там нет удалёнки, а я переезжать из своего маленького городка не собираюсь, так что не судьба.
в случае с wsl микрософт пошли на несколько шагов дальше, чем просто guest tools. если поискать в официальной доке на learning portal, то там вполне подробно расписано, что именно они докрутили (включая ядро — причём как линуксовое, так и nt), чтобы добиться минимального падения производительности.
а уж послушав доклады с //build так и вообще просто диву даёшься, насколько заморочились с интеграцией. но на это надо потратить время, конечно.
хочется сделать рукалицо. о каких «встроенных в винду» таких «оверхедах» идёт речь? я не понимаю, объясните мне глупому. если можно, то, пожалуйста, без троллинга и «бесполезных ядер». а то ведь по моим собственным замерам, скорость работы с ФС в wsl2 относительно голого железа меньше всего на 5%. я бы ещё понял, если от виртуализации на 25% падала хотя бы. но ведь нет такого.
от винды я использую десктопный офис, а особенно аутлук, без которого было бы сложно. ну и доменное окружение; всё же не фрилансером из кафе, а в офисе конторы работаю. корпоративный стандарт есть корпоративный стандарт.
у виртуализации нынче бывают разные уровни. конкретно wsl2 это виртуалка легковесная ("thin vm" в родной для hyper-v терминологии). ядро в ней, например, умеет у хоста забирать память при необходимости, и отдавать обратно при высвобождении, с дисками работает через специализированный интерфейс, и вообще вызывает сильно меньший оверхед, чем традиционная vm.
что касается wsl1, оно и сейчас в некоторых кейсах подходит лучше wsl2. я вполне успешно юзаю инстансы обеих версий для разных целей.
батенька, я совершенно без понятия, что вы делаете не так, но у меня целый отдел дата сатанистов прекрасно работает в указанной конфигурации уже 4 года.
десктоп виндовый (нужен офис и аутлук, энтерпрайз же), а локальные деплои и вся разработка в убунте под wsl.
я лично, как техлид, просто не нарадуюсь такому удобному инструменту как wsl. спарк штука крайне тяжёлая и неповоротливая, прежде нам приходилось виртуалки держать с 16 гигами оперативы, либо морочиться с дуалбутом. было очень больно. теперь нет.
значит, человек сам себе злобный буратино ¯_(ツ)_/¯ что ему мешает линуксовый проект в линуксовом разделе держать?
у меня spark проекты (которые по совокупности причин вообще не работают в винде) лежат на виндовых разделах (потому что intellij я предпочитаю виндовый), но деплоятся в wsl, где и запускаются без каких-либо проблем с трансляцией путей. и настраивается это совершенно без танцев с бубном.
в wsl2 убунта ведёт себя абсолютно идентично натуральной. вообще ничем не отличается от виртуалки, кроме скорости (заметно быстрее, почти как на железе). всё равно что в virtualbox со всеми возможными включенными интеграциями держать, только удобнее.
и абсолютно никаких проблем ни с гитом, ни с питоном, ни с жабой, ни даже с intellij в окружении wsl нет.
я вот вполне успешно живу в wsl ещё с бета-версии, и для разработки под aws и spark его более чем хватает. или это не достаточно «серьёзно», по-вашему?
Начал читать. Протёр глаза. Проверил календарь. Декабрь 2022 года, точно. Но ощущение, что читаю пост с sql.ru откуда-то из 2002, никак не проходит. Такой древностью повеяло, что аж страшно.
Автор, батенька, вы напрочь сварились в собственном соку. За то время, пока вы (судя по тону, в основном в одно лицо) разрабатывали ваш продукт, индустрия ушла уже очень далеко.
Я и сам не то что бы молод, и если бы я продолжал разрабатывать свой первый относительно успешный продукт с 2001 года по сей день, вероятно, написал бы что-то в таком же духе. Но я с тех пор трижды поменял технологический стек, а предметную область и того больше раз. Было тяжко каждый раз, но зато не застрял в прошлом. (А относительно успешным продуктом пускай лучше занимается молодёжь, уже без моего участия.)
Да просто чтение чужого кода, написанного с новым синтаксическим сахарком в очередном модном молодёжном стиле, здорово поднимает уровень осознанности того, что ты делаешь. Особенно хорошо, если этот чужой код на каком-то новом для тебя языке с другими акцентами.
Не тащите на себе это вечное легаси, в нём не будет счастья.
Когда моя матушка в конце 90-х работала в госкомстате, она вела подробный журнал доходов-расходов много лет для статистической отчётности. Была у них такая обязанность по работе. Ну и я, будучи старшеклассником / студентом, поглядывая на этот журнал, научился планировать личные финансы. Ни разу за всю самостоятельную жизнь ни потребительский кредит не брал, ни подбирался к нулю. Так что весьма полезная практика, особенно на относительно небольших отрезках времени.
Но всерьёз планировать накопить на безбедное будущее, живя в России… Как бы это помягче сказать, чтобы без нехороших слов. Глупая, бессмысленная, неконструктивная затея. Государство так устроено, что не получится у вас эти деньги сохранить, они обесценятся раньше, чем их удастся потратить с задуманной пользой. В 2008, 2015, и 2021 годах я в этом убедился на собственной шкуре.
Так что планировать имеет смысл на полгода, максимум на год.
Позволю себе не согласиться. В энтерпрайзе системы часто сразу создаются большими, а вовсе не вырастают из маленьких.
Я пару раз участвовал в разработке нескольких программных комплексов, у которых только эскизный архитектурный дизайн занимает сотни страниц (а частные ТЗ на модули и вовсе измеряются тысячами), и хорошо знаю, как там что. Так что простите, но вы говорите ерунду. В промышленном программировании никакого «органического роста» не бывает.
Система сразу проектируется на своём «птичьем» языке, и один только глоссарий, описывающий терминологию прикладной матмодели, может занимать десятки страниц. И ведь каждому из терминов может соответствовать несколько интерфейсов, эндпоинтов, структур данных в хранилище, и прочей требухи, представляющей его в коде.
Так вот, assistive tools по идее должны бы приносить наибольшую пользу именно в тех случаях, когда трудозатраты измеряются многими тысячами часов десятков разработчиков, но на практике ни фига подобного не происходит: инструменты не умеют понимать внутренние системные DSL.
Попытки кодогенерации на основе описаний (BPMN, UML, и т.д.) существуют, но большой пользы от них, опять же, не чувствуется.
Написание любой сколько-нибудь развитой системы равносильно по мощности проектированию отдельного искусственного языка. Классы являются существительными, методы — глаголами, атрибуты и аргументы — прилагательными, и так далее. И чем сложнее система, чем больше у неё внутренних правил, тем более развит её DSL.
Соответственно, код большого проекта с какого-то момента превращается в набор предложений на таком внутреннем языке, где инстансы классов, вызовы методов, и т.п. выступают различными частями речи в зависимости от контекста, и платформенный язык превращается в низкоуровневый слой. В проекте на полмиллиона строк кода на Java новые куски пишутся не вовсе на Java на самом-то деле, а скорее на существующем API.
Так что задача генерации кода at large scale на самом деле не является задачей сгенерировать что-то внятное на каком-то языке программирования, а скорее задачей сгенерировать самостоятельный язык, и перевести уже этот DSL в облик языка программирования.
И вот почему-то лично мне кажется, что разработчики assistive tools на таком уровне мыслить всё ещё не научились, от чего и особенного прогресса в этой области (равно как и большой пользы от самих инструментов) не видно.
Поручитесь, что ваш кейс типичный, и ваши практики универсально переносятся на любой другой ETL процесс в мире?
А зачем делать что-то «в принципе эквивалентное SQL», если можно сделать прям самый настоящий SQL?
И если речь не о питоне, то о каком API? API ведь к языку привязано, не бывает сферического API в вакууме без указания языка. Даже если имеется в виду проекция одних и тех же методов некой объектной модели, в разных языках они никогда не будут эквивалентными. Так что я не очень понимаю, чего именно вы хотите. И для кого.
Я вот на запросы своих аналитиков ориентируюсь, с моего проекта.
Насмотревшись, что и как аналитики пишут на питоне (а на чём их ещё можно заставить писать?), я не могу согласиться с вашим пожеланием.
Питон язык отличный, не требующий программистского мышления, но он слишком высокоуровневый. За одним неосторожным обращением к свойству там легко может такая цепочка событий развернуться, что кластер будет просто стоять колом какое-то время. И если нужно каждый день инджестить сотню терабайт даты, то писать процессы на питоне — это верная смерть, какой бы крутой очередная кастомная обёртка над Dataset или Dataframe ни была.
По крайней мере, если ты не контора, которая железом закидывает код любой степени неоптимальности. То есть, крупняк какой-нибудь, типа телекомов. Ну, у них действительно есть такие инструменты, которые дают именно API. Но толку-то — это всё плохо отчуждаемые инструменты.
Поэтому мой выбор — ограниченный и заточенный под одну конкретную задачу диалект SQL, на котором заведомо что попало не напишешь. Впрочем, в следующий частях местами будет и что попало :)
Для японцев наличие учителя человека тоже обязательно. Сами они по документации почему-то не умеют ничего понимать, надо обязательно рассказывать, а лучше показывать. А если за спиной стоять, то схватывают как суперклей, с первого раза и навсегда.
Антересный цикл статей, спасибо.
С китайцами я не работал, зато довелось с японцами (из NTT DoCoMo, контора тоже масштаба немаленького), и впечатления довольно схожие. Жёсткая иерархичность, конкуренция без агрессии, неумение ждать без беганья по кругу, и они тоже никогда не говорят «нет» напрямую. Любого, кто провёл в энтерпрайзе западного образца несколько лет, это всё раздражает неимоверно.
Но у ихних технарей есть особая фишка: невероятная обучаемость. Достаточно один раз показать, как сделать более лучше (а «более лучше» в их понимании это «более эффективно»), и в дальнейшем процесс будет работать как часы, каким бы сложным ни был. Иероглифическая письменность таки в самом деле затачивает мозг на быстрое запоминание и воспроизведение шаблонов.
BTW, из забавного — за последние три года меня несколько раз звали в Хуавей, и каждый раз это был другой отдел :) И каждый раз другой HR находил меня самостоятельно, так что разные части конторы, по ходу, и в самом деле между собой совсем не дружат. Но там нет удалёнки, а я переезжать из своего маленького городка не собираюсь, так что не судьба.
в случае с wsl микрософт пошли на несколько шагов дальше, чем просто guest tools. если поискать в официальной доке на learning portal, то там вполне подробно расписано, что именно они докрутили (включая ядро — причём как линуксовое, так и nt), чтобы добиться минимального падения производительности.
а уж послушав доклады с //build так и вообще просто диву даёшься, насколько заморочились с интеграцией. но на это надо потратить время, конечно.
хочется сделать рукалицо. о каких «встроенных в винду» таких «оверхедах» идёт речь? я не понимаю, объясните мне глупому. если можно, то, пожалуйста, без троллинга и «бесполезных ядер». а то ведь по моим собственным замерам, скорость работы с ФС в wsl2 относительно голого железа меньше всего на 5%. я бы ещё понял, если от виртуализации на 25% падала хотя бы. но ведь нет такого.
от винды я использую десктопный офис, а особенно аутлук, без которого было бы сложно. ну и доменное окружение; всё же не фрилансером из кафе, а в офисе конторы работаю. корпоративный стандарт есть корпоративный стандарт.
у виртуализации нынче бывают разные уровни. конкретно wsl2 это виртуалка легковесная ("thin vm" в родной для hyper-v терминологии). ядро в ней, например, умеет у хоста забирать память при необходимости, и отдавать обратно при высвобождении, с дисками работает через специализированный интерфейс, и вообще вызывает сильно меньший оверхед, чем традиционная vm.
что касается wsl1, оно и сейчас в некоторых кейсах подходит лучше wsl2. я вполне успешно юзаю инстансы обеих версий для разных целей.
батенька, я совершенно без понятия, что вы делаете не так, но у меня целый отдел дата сатанистов прекрасно работает в указанной конфигурации уже 4 года.
десктоп виндовый (нужен офис и аутлук, энтерпрайз же), а локальные деплои и вся разработка в убунте под wsl.
я лично, как техлид, просто не нарадуюсь такому удобному инструменту как wsl. спарк штука крайне тяжёлая и неповоротливая, прежде нам приходилось виртуалки держать с 16 гигами оперативы, либо морочиться с дуалбутом. было очень больно. теперь нет.
значит, человек сам себе злобный буратино ¯_(ツ)_/¯ что ему мешает линуксовый проект в линуксовом разделе держать?
у меня spark проекты (которые по совокупности причин вообще не работают в винде) лежат на виндовых разделах (потому что intellij я предпочитаю виндовый), но деплоятся в wsl, где и запускаются без каких-либо проблем с трансляцией путей. и настраивается это совершенно без танцев с бубном.
простите, но вы пишете какой-то булшит сейчас.
в wsl2 убунта ведёт себя абсолютно идентично натуральной. вообще ничем не отличается от виртуалки, кроме скорости (заметно быстрее, почти как на железе). всё равно что в virtualbox со всеми возможными включенными интеграциями держать, только удобнее.
и абсолютно никаких проблем ни с гитом, ни с питоном, ни с жабой, ни даже с intellij в окружении wsl нет.
интересно, каких именно «косяков».
я вот вполне успешно живу в wsl ещё с бета-версии, и для разработки под aws и spark его более чем хватает. или это не достаточно «серьёзно», по-вашему?
Начал читать. Протёр глаза. Проверил календарь. Декабрь 2022 года, точно. Но ощущение, что читаю пост с sql.ru откуда-то из 2002, никак не проходит. Такой древностью повеяло, что аж страшно.
Автор, батенька, вы напрочь сварились в собственном соку. За то время, пока вы (судя по тону, в основном в одно лицо) разрабатывали ваш продукт, индустрия ушла уже очень далеко.
Я и сам не то что бы молод, и если бы я продолжал разрабатывать свой первый относительно успешный продукт с 2001 года по сей день, вероятно, написал бы что-то в таком же духе. Но я с тех пор трижды поменял технологический стек, а предметную область и того больше раз. Было тяжко каждый раз, но зато не застрял в прошлом. (А относительно успешным продуктом пускай лучше занимается молодёжь, уже без моего участия.)
Да просто чтение чужого кода, написанного с новым синтаксическим сахарком в очередном модном молодёжном стиле, здорово поднимает уровень осознанности того, что ты делаешь. Особенно хорошо, если этот чужой код на каком-то новом для тебя языке с другими акцентами.
Не тащите на себе это вечное легаси, в нём не будет счастья.
Разве автор поста написал о намерении куда-то уехать из РФ?
См. ошибка выжившего. На 1, кто «успешно вышел» приходится 10 тех, кто не смог.
Когда моя матушка в конце 90-х работала в госкомстате, она вела подробный журнал доходов-расходов много лет для статистической отчётности. Была у них такая обязанность по работе. Ну и я, будучи старшеклассником / студентом, поглядывая на этот журнал, научился планировать личные финансы. Ни разу за всю самостоятельную жизнь ни потребительский кредит не брал, ни подбирался к нулю. Так что весьма полезная практика, особенно на относительно небольших отрезках времени.
Но всерьёз планировать накопить на безбедное будущее, живя в России… Как бы это помягче сказать, чтобы без нехороших слов. Глупая, бессмысленная, неконструктивная затея. Государство так устроено, что не получится у вас эти деньги сохранить, они обесценятся раньше, чем их удастся потратить с задуманной пользой. В 2008, 2015, и 2021 годах я в этом убедился на собственной шкуре.
Так что планировать имеет смысл на полгода, максимум на год.
Это не дизайна проблема, а UX. В новом трекере он напрочь сломан.
Позволю себе не согласиться. В энтерпрайзе системы часто сразу создаются большими, а вовсе не вырастают из маленьких.
Я пару раз участвовал в разработке нескольких программных комплексов, у которых только эскизный архитектурный дизайн занимает сотни страниц (а частные ТЗ на модули и вовсе измеряются тысячами), и хорошо знаю, как там что. Так что простите, но вы говорите ерунду. В промышленном программировании никакого «органического роста» не бывает.
Система сразу проектируется на своём «птичьем» языке, и один только глоссарий, описывающий терминологию прикладной матмодели, может занимать десятки страниц. И ведь каждому из терминов может соответствовать несколько интерфейсов, эндпоинтов, структур данных в хранилище, и прочей требухи, представляющей его в коде.
Так вот, assistive tools по идее должны бы приносить наибольшую пользу именно в тех случаях, когда трудозатраты измеряются многими тысячами часов десятков разработчиков, но на практике ни фига подобного не происходит: инструменты не умеют понимать внутренние системные DSL.
Попытки кодогенерации на основе описаний (BPMN, UML, и т.д.) существуют, но большой пользы от них, опять же, не чувствуется.
Написание любой сколько-нибудь развитой системы равносильно по мощности проектированию отдельного искусственного языка. Классы являются существительными, методы — глаголами, атрибуты и аргументы — прилагательными, и так далее. И чем сложнее система, чем больше у неё внутренних правил, тем более развит её DSL.
Соответственно, код большого проекта с какого-то момента превращается в набор предложений на таком внутреннем языке, где инстансы классов, вызовы методов, и т.п. выступают различными частями речи в зависимости от контекста, и платформенный язык превращается в низкоуровневый слой. В проекте на полмиллиона строк кода на Java новые куски пишутся не вовсе на Java на самом-то деле, а скорее на существующем API.
Так что задача генерации кода at large scale на самом деле не является задачей сгенерировать что-то внятное на каком-то языке программирования, а скорее задачей сгенерировать самостоятельный язык, и перевести уже этот DSL в облик языка программирования.
И вот почему-то лично мне кажется, что разработчики assistive tools на таком уровне мыслить всё ещё не научились, от чего и особенного прогресса в этой области (равно как и большой пользы от самих инструментов) не видно.
У меня ещё более старый классик то ли на 60, то ли на 80Гб — не помню, потому что тоже уже много лет живёт в машине.
Для синхронизации (которая бывает раз в пятилетку) до сих пор держу Винамп %)