Так и не понял из текста, что же скрывается под "множество терабайтов и миллиарды строк". Это мешает понять, какими же реально масштабами они оперируют.
плагины на VBA можно писать и в грамотном современном виде
Только отчасти. VBA все равно останется устаревшим языком, с кучкой странных по сегодняшним временам решений. Чуть лучше сделать можно - но страдать все равно придется.
Если автор переписал 100 строк в 380, то мне приходилось переписывать 120 тысяч строк кода, которые были намного сложнее, чем работа с данными внутри листов таблицы. Там были и файловая система, и шина данных, и сложный UI.
Если у вас реально стоит задача переписать в современном виде - возьмите и перепишите на C#, будет намного, намного лучше.
Ну вот хорошо что у автора 0-арная функция. А если мы заходим использовать аргументы? Я пытался как-то разобраться с expressions, но так и уперся в отсутствие документации, скажем, непонятно где вот эти InternalRow взять, и что с ними можно делать.
Реализация генератора UUID с использованием UDF проста.
Я бы хотел отметить, что на самом деле все не всегда так просто, даже для такой простой функции. Дело в том, что UDF сериализуются и передаются в executors, это во-первых (ну, те кто программирует на спарке, уже должны это обычно знать).
Но тут еще могут добавляться вопросы с класслоадерами. Скажем, мы как-то попытались создать экземпляр UDF и зарегистрировать его в groovy скрипте, который динамически выполнялся из кода на спарке. Так вот, ничего не получилось, потому что класслоадер оказался другой, и наша функция имела сигнатуру, отличную от нужной. А как устроены класслоадеры в спарке, описано примерно так же, как описано создание catalyst выражений из этой статьи - т.е. примерно никак.
Не, ну спортивно или нет - это другая история. Ну вот последний проект, что я смотрел - это был apache kerby, который является открытой java реализацией Kerberos - сервера и клиента. Ну т.е. это проект достаточно крупный, и в тоже время это проект, который можно охватить целиком (пусть и не за 15 минут). И там, для сравнения, всего 43 pom.xml (я посчитал). Вот мне поэтому и интересно - у вас проект, условно, в три раза сложнее? Или ваши модули по какой-то причине наполненные, но мелкие? Ну или еще проще - у вас очевидно есть проблемы с управлением этими сотнями модулей - вы про них статью написали, так? А вот где профит от таких мелких модулей в большом количестве? Ну раз вы их в таком количестве создаете - значит это чем-то удобно?
Как по мне, тут не хватает одной вещи - оценки масштаба проектов с какой-то другой точки зрения. Ну т.е. вот у вас 120 модулей получилось - у вас в проекте скажем сколько LOC? Как понять, много это модулей, или мало, как оценить объективно?
Ну, да, но я бы сказал, что в каком-то смысле это одно и тоже. Если вы в другой плоскости - вам просто понадобится еще много характеристической скорости, чтобы эту плоскость повернуть. Причем я много раз сталкивался с тем, что люди, не изучавшие баллистику, не понимают интуитивно, насколько это "много" (ну т.е. не держат в голове, что скорость это вектор, и что поворот вектора - это может быть большая дельта, даже если модуль не изменился).
Ну вы можете смотреть на дельту, разумеется, и это правильно. Тем не менее, если в тексте (не для специалистов) написано "орбита 450 км, близкая к геостационарной", и ничего не написано про дельту (про критерий "близости") - этот текст мне кажется неграмотным. Да не, наверное даже не кажется, а он такой и есть.
Мне кажется, вы усложняете. Повесить трубку, и в черный список. Какие могут быть минусы, даже если это настоящий капитан (я оцениваю вероятность такого варианта в контексте разговора как строго нулевую)?
И еще заметьте - такая штука, как синтез голоса, уже реальность. Чем больше вы наговорите с этим "капитаном" - тем больше шансы, что из вашего образца голоса потом что-то синтезируют. А оно вам надо?
Я верю, что Роскосмос отличает 450 км от геостационара, и что в другом месте где-то все написали правильно. Меня смущает, что в данном тексте в одном предложении утверждается, что 450 км это близко к геостационару. И хотелось бы понять, кто это так лажает?
Вот упомянутый вами разгонный блок «Орион» - вот его и должны были вывести на 450 км, и это было бы ожидаемо. Только он и не полезная нагрузка, строго говоря.
Ну я даже не уверен, что худшее. Это человек, который пишет про бизнес. Пусть не про свой бизнес, а чей-то чужой. Самый разный, и про разные его стороны. Мне лично это не интересно вообще, но как мы видим, кто-то это читает, и статьи популярны.
Ну т.е. это человек у которого есть своя тема, пусть она и не всем интересна. Есть ли что-то хуже? Как по мне, еще хуже - это толпа генераторов информационного шума, у которых своей темы вообще нет. И которым сказать по сути нечего.
Если меня заинтересует мода, я пойду на тематический ресурс.
Я бы даже так сформулировал - если мне будет нужно улучшить свой имидж, я пойду к конкретному специалисту, который учтет мои особенности и мои вкусы. А не буду читать какие-то непрошенные советы "для всех и ни для кого конкретно", потому что не бывает двух одинаковых ИТ-ников.
С теми же статьями Славы Рюмина - там хотя бы интересное чтиво.
Ну, тут кому как. Но я бы заметил, что появилась кучка последователей, которые прямо заявляют: "А чо, вот ему можно про пельмени, а мне почему нет?" - и понеслась. То есть, имеем очевидное следствие публикации таких вот "интересных чтив".
передача данных между функциями уже медленное место.
Я думаю вы совершенно правы. Как минимум это одна из проблем.
Когда мы пишем на питоне (или любом медленном скриптовом языке) в стиле "скрипт" -> готовый быстрый фреймворк -> результат, то все нормально. А если фреймворк должен вызывать нашу функцию, которая что-то там считает внутри процесса в самом фреймворке, и которая написана на медленном языке - начинается передача данных туда-сюда, много раз в цикле, преобразования, и прочая и прочая. Это помимо того, что медленный кусок сам выполняется не быстро.
Это вполне типичная проблема, она например в Apache Spark имеет место - просто PySpark дает приемлемую производительность, но стоит на питоне написать UDF (ту самую функцию, которая каждую строку данных будет обрабатывать) - вот это вот все и начинается, с тормозами как следствие.
Ходят слухи, что CSS таки полный по Тьюрингу (я не проверял и мне не особо интересно, но каждый желающий нагуглит кучу обсуждений этой темы сам при желании). Но автор это ни разу не доказал. Вот даже вообще не близко было.
Так и не понял из текста, что же скрывается под "множество терабайтов и миллиарды строк". Это мешает понять, какими же реально масштабами они оперируют.
Только отчасти. VBA все равно останется устаревшим языком, с кучкой странных по сегодняшним временам решений. Чуть лучше сделать можно - но страдать все равно придется.
Если автор переписал 100 строк в 380, то мне приходилось переписывать 120 тысяч строк кода, которые были намного сложнее, чем работа с данными внутри листов таблицы. Там были и файловая система, и шина данных, и сложный UI.
Если у вас реально стоит задача переписать в современном виде - возьмите и перепишите на C#, будет намного, намного лучше.
О, давайте-давайте, будем ждать.
Ну вот хорошо что у автора 0-арная функция. А если мы заходим использовать аргументы? Я пытался как-то разобраться с expressions, но так и уперся в отсутствие документации, скажем, непонятно где вот эти
InternalRow взять, и что с ними можно делать.Я бы хотел отметить, что на самом деле все не всегда так просто, даже для такой простой функции. Дело в том, что UDF сериализуются и передаются в executors, это во-первых (ну, те кто программирует на спарке, уже должны это обычно знать).
Но тут еще могут добавляться вопросы с класслоадерами. Скажем, мы как-то попытались создать экземпляр UDF и зарегистрировать его в groovy скрипте, который динамически выполнялся из кода на спарке. Так вот, ничего не получилось, потому что класслоадер оказался другой, и наша функция имела сигнатуру, отличную от нужной. А как устроены класслоадеры в спарке, описано примерно так же, как описано создание catalyst выражений из этой статьи - т.е. примерно никак.
Ну мне оценить сложно, насколько это может быть полезно, но идею я понял.
Ну то есть это скорее особенность андроида, нежели ваших проектов?
Не, ну спортивно или нет - это другая история. Ну вот последний проект, что я смотрел - это был apache kerby, который является открытой java реализацией Kerberos - сервера и клиента. Ну т.е. это проект достаточно крупный, и в тоже время это проект, который можно охватить целиком (пусть и не за 15 минут). И там, для сравнения, всего 43 pom.xml (я посчитал). Вот мне поэтому и интересно - у вас проект, условно, в три раза сложнее? Или ваши модули по какой-то причине наполненные, но мелкие? Ну или еще проще - у вас очевидно есть проблемы с управлением этими сотнями модулей - вы про них статью написали, так? А вот где профит от таких мелких модулей в большом количестве? Ну раз вы их в таком количестве создаете - значит это чем-то удобно?
Как по мне, тут не хватает одной вещи - оценки масштаба проектов с какой-то другой точки зрения. Ну т.е. вот у вас 120 модулей получилось - у вас в проекте скажем сколько LOC? Как понять, много это модулей, или мало, как оценить объективно?
Нууу... я по умолчанию сегодня исхожу из того, что позвонили на мобильный. Все же стационарные телефоны уже более редки нынче.
Ну, да, но я бы сказал, что в каком-то смысле это одно и тоже. Если вы в другой плоскости - вам просто понадобится еще много характеристической скорости, чтобы эту плоскость повернуть. Причем я много раз сталкивался с тем, что люди, не изучавшие баллистику, не понимают интуитивно, насколько это "много" (ну т.е. не держат в голове, что скорость это вектор, и что поворот вектора - это может быть большая дельта, даже если модуль не изменился).
Ну вы можете смотреть на дельту, разумеется, и это правильно. Тем не менее, если в тексте (не для специалистов) написано "орбита 450 км, близкая к геостационарной", и ничего не написано про дельту (про критерий "близости") - этот текст мне кажется неграмотным. Да не, наверное даже не кажется, а он такой и есть.
Мне кажется, вы усложняете. Повесить трубку, и в черный список. Какие могут быть минусы, даже если это настоящий капитан (я оцениваю вероятность такого варианта в контексте разговора как строго нулевую)?
И еще заметьте - такая штука, как синтез голоса, уже реальность. Чем больше вы наговорите с этим "капитаном" - тем больше шансы, что из вашего образца голоса потом что-то синтезируют. А оно вам надо?
Я верю, что Роскосмос отличает 450 км от геостационара, и что в другом месте где-то все написали правильно. Меня смущает, что в данном тексте в одном предложении утверждается, что 450 км это близко к геостационару. И хотелось бы понять, кто это так лажает?
Вот упомянутый вами разгонный блок «Орион» - вот его и должны были вывести на 450 км, и это было бы ожидаемо. Только он и не полезная нагрузка, строго говоря.
450 км это ни разу не близко к геостационарной орбите. Позволю себе процитировать википедию:
Примерно 36 тысяч км и 450 км - это две большие разницы. Это о чем вообще?
Да я вроде вас правильно понял )
Ну я даже не уверен, что худшее. Это человек, который пишет про бизнес. Пусть не про свой бизнес, а чей-то чужой. Самый разный, и про разные его стороны. Мне лично это не интересно вообще, но как мы видим, кто-то это читает, и статьи популярны.
Ну т.е. это человек у которого есть своя тема, пусть она и не всем интересна. Есть ли что-то хуже? Как по мне, еще хуже - это толпа генераторов информационного шума, у которых своей темы вообще нет. И которым сказать по сути нечего.
Я бы даже так сформулировал - если мне будет нужно улучшить свой имидж, я пойду к конкретному специалисту, который учтет мои особенности и мои вкусы. А не буду читать какие-то непрошенные советы "для всех и ни для кого конкретно", потому что не бывает двух одинаковых ИТ-ников.
Ну, тут кому как. Но я бы заметил, что появилась кучка последователей, которые прямо заявляют: "А чо, вот ему можно про пельмени, а мне почему нет?" - и понеслась. То есть, имеем очевидное следствие публикации таких вот "интересных чтив".
Я думаю вы совершенно правы. Как минимум это одна из проблем.
Когда мы пишем на питоне (или любом медленном скриптовом языке) в стиле "скрипт" -> готовый быстрый фреймворк -> результат, то все нормально. А если фреймворк должен вызывать нашу функцию, которая что-то там считает внутри процесса в самом фреймворке, и которая написана на медленном языке - начинается передача данных туда-сюда, много раз в цикле, преобразования, и прочая и прочая. Это помимо того, что медленный кусок сам выполняется не быстро.
Это вполне типичная проблема, она например в Apache Spark имеет место - просто PySpark дает приемлемую производительность, но стоит на питоне написать UDF (ту самую функцию, которая каждую строку данных будет обрабатывать) - вот это вот все и начинается, с тормозами как следствие.
Ходят слухи, что CSS таки полный по Тьюрингу (я не проверял и мне не особо интересно, но каждый желающий нагуглит кучу обсуждений этой темы сам при желании). Но автор это ни разу не доказал. Вот даже вообще не близко было.