Ну вот хорошо что у автора 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 таки полный по Тьюрингу (я не проверял и мне не особо интересно, но каждый желающий нагуглит кучу обсуждений этой темы сам при желании). Но автор это ни разу не доказал. Вот даже вообще не близко было.
Да, наверное вы правы. Я просто прикинул, у меня-то кобол был пятым языком, а PL/1 третьим, после Алгола-60 и Фортрана. Поэтому я явно не так все это воспринимаю. А для тех кто писал экономические задачи, и переходил на PL/1 с кобола, все вполне могло выглядеть и так.
Ну как бы вы вольны начинать с чего угодно. Я говорил о том, что у нормальной взрослой СУБД консоли как таковой обычно вообще нет, у нее интерфейс наружу - это как правило сокет, куда подключается тот или иной клиент, который уже может быть и читает с консоли. И начиная разработку с консоли, вы вот эту вот часть архитектуры просто опускаете, если не теряете. И вместо клиент-серверной архитектуры СУБД получается некая однопользовательская штука, умеющая выполнять запросы. А в данном конкретном случае вообще получился REPL, который не умеет пока ничего. Если уж задумывать REPL, то было бы желательно сделать автокомплит для SQL, например. А в текущей реализации вообще нет никаких признаков автокомплита. Более того, написанный уже код будет мешать его реализовать.
Спокойно отвечаю на такое "да, без проблем, кинь встречу в календарь".
Вот что конкретно было сделано. Если это вас сбивает с концентрации - ну я не знаю. Это более чем рутинное движение, не требующее приложения мозгов практически.
Ну то есть я в целом понимаю, о чем вы, но то чего вы желаете, достигается только способом "не читать ваще эту почту весь день". Иначе отвлекать все равно будут. А не читать весь день не все могут позволить.
Ну вот хорошо что у автора 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 таки полный по Тьюрингу (я не проверял и мне не особо интересно, но каждый желающий нагуглит кучу обсуждений этой темы сам при желании). Но автор это ни разу не доказал. Вот даже вообще не близко было.
Да, наверное вы правы. Я просто прикинул, у меня-то кобол был пятым языком, а PL/1 третьим, после Алгола-60 и Фортрана. Поэтому я явно не так все это воспринимаю. А для тех кто писал экономические задачи, и переходил на PL/1 с кобола, все вполне могло выглядеть и так.
Ну как бы вы вольны начинать с чего угодно. Я говорил о том, что у нормальной взрослой СУБД консоли как таковой обычно вообще нет, у нее интерфейс наружу - это как правило сокет, куда подключается тот или иной клиент, который уже может быть и читает с консоли. И начиная разработку с консоли, вы вот эту вот часть архитектуры просто опускаете, если не теряете. И вместо клиент-серверной архитектуры СУБД получается некая однопользовательская штука, умеющая выполнять запросы. А в данном конкретном случае вообще получился REPL, который не умеет пока ничего. Если уж задумывать REPL, то было бы желательно сделать автокомплит для SQL, например. А в текущей реализации вообще нет никаких признаков автокомплита. Более того, написанный уже код будет мешать его реализовать.
Вот что конкретно было сделано. Если это вас сбивает с концентрации - ну я не знаю. Это более чем рутинное движение, не требующее приложения мозгов практически.
Ну то есть я в целом понимаю, о чем вы, но то чего вы желаете, достигается только способом "не читать ваще эту почту весь день". Иначе отвлекать все равно будут. А не читать весь день не все могут позволить.