Простите, насчёт «далёкого от реальности» я что-то, по-видимому, не так понял. Если Вы поясните свою точку зрения, то давайте продолжим дискуссию.
Про архитектурную секцию в целом согласен, но реальность показывает, что не все хорошие архитекторы хороши в разработке алгоритмов, равно как и наоборот.
CRUD-задачка у меня за всё время, кажется, была одна. Остальное существенно интереснее.
Работа, чтобы платить ипотеку, у меня была, и я оттуда ушёл, поскольку она не удовлетворяла мою потребность в творческой самореализации.
Я бы не сказал, что решение алгоритмических задач — навык, далёкий от реальности. Да, в реальной работе напрямую сливать массивы мы, скорее всего, не будем. Но в любой реальной задаче чуть сложнее, чем написать CRUD, нужно понять, как в принципе сделать то, что нужно (и не сделать то, что не нужно), какие граничные случаи могут возникнуть, не сломается ли оно тогда, когда данных станет больше, и т. д. А алгоритмические задачи, на мой взгляд, представляют собой своего рода минимальный пример, где все эти навыки можно продемонстрировать.
Для меня сложно представить себе хорошего разработчика, для которого слияние отсортированных массивов — это сложная задача. И, конечно, на собеседовании мне хочется показать свои сильные стороны. Так что к тезису «люди в здравом уме не будут усложнять собеседования» я бы добавил — если оное собеседование позволяет адекватно продемонстрировать релевантные навыки.
А вот что касается ВК, то описанное Вами наводит на мысль: это не случайное моё невезение, это — система.
Да, на этапе согласования оффера в Яндексе была некоторая бюрократия (и я про это написал). Но в остальном-то всё было максимально прозрачно и чисто — особенно на фоне ВК, где были постоянные переносы встреч, отсутствие какого-то ясного плана, ответы в телеграме на следующий день или через несколько дней на протяжении всего процесса.
Нет, я накатал такую простыню не ради вывода «не всё так однозначно». Мне было весело и прикольно, и я был рад, что сформированные ожидания не оправдались, и этой радостью я хочу делиться
На основание упомянутых в начале статей у меня сформировалось мнение, что «алгоритмические задачи никак не связаны с реальностью». Реальность это мнение скорректировала: навыки, нужные для прохождения подобных интервью, пригождаются на деле и в работе.
А если произвольно понадёргать фраз, то можно подвести основания под любое мнение.
Что же касается количества этапов, то для меня это не выглядело неадекватным (в отличие от универсального интервью про всё на свете от ВК).
Если логика для всех трёх случаев имеет мало общего (а, скорее всего, оно так и есть), то можно объявить трейт AsLabelList с единственной функцией has_label реализовать его для всех нужных типов. Тогда можно указать для «единой» функции требование трейта и пробрасывать вызов дальше. Это отлично оптимизируется, а ещё позволяет пользователю реализовывать трейт для своих типов, которые тоже можно будет передать в нашу функцию
Было бы по-настоящему здорово не перереализовывать уже имеющийся как минимум в Windows и macOS функционал (десять лет назад у меня винда прекрасно меняла обои автоматом — там были разные раскрашенные фрагменты множества Мандельброта), а написать, допустим, кроссплатформенную утилиту, которая эти системные настройки выставляет унифицированно, например. Закинул список URL, а он тебе все их скачал и поставил в ротацию средствами системы. И обновляет ещё периодически, когда новые картины появляются.
Ну и отдельное количество недоумение — Electron. Тащить целый браузер ради того, чтобы просто продублировать системный функционал...
Но хорошо, что удалось поупражняться в реализации своих идей, этого не отнять.
Про R я в принципе знаю достаточно давно, но именно на tidyverse меня навела ChatGPT, так что какие-то базовые вещи я освоил меньше, чем за день. Правда, она довольно быстро перестала помогать и начала мешать, поэтому дальше я, собственно, читал статьи на сайте tidyverse.
Вот, кстати, добрался до компьютера и могу привести те самые две строчки (и масса «обвеса») для ваших данных:
# подключаем библиотеки
library(tidyverse)
library(jsonlite)
# читаем данные
d <- read_json('file.json')
# или можно распарсить JSON прямо из буфера обмена, пользуюсь этим
d <- parse_json(clipboard())
# а теперь, собственно, превращаем history в таблицу
hist <- d$data$accountBalanceHistory$history %>% enframe %>% unnest_wider(value)
# преобразуем даты и рисуем график
# технически это одна строка, просто разбитая :)
hist %>%
mutate(across(balanceChangeDate, parse_datetime)) %>%
ggplot(aes(x=balanceChangeDate)) + geom_histogram()
Из неочевидных плюшек NSE, о котором упоминал в комментарии ниже, например, возможно такое:
hist %>%
# разбираем как дату все столбцы, оканчивающиеся на Date
mutate(across(ends_with("Date"), parse_datetime)) -> hist
# да, присваивание можно делать не только влево, но и вправо
Из-за того, что называется NSE — non-standart evaluation. R ленив, и вычисляет значения аргументов только при необходимости. Более того, их можно превратить обратно в языковые конструкции и проинтерпретировать иначе. В итоге каждая функция может иметь свой мини-синтаксис для аргументов. Потенциально это может, конечно, вести к хаосу, но на деле это делает синтаксис яснее и понятнее, например:
df %>% select(starts_with("c"))
оставит только те столбцы, имена которых начинаются с c , позволяя не перечислять их имена.
С тех пор, как я освоил rectangling (https://tidyr.tidyverse.org/articles/rectangle.html) при помощи tidyr, анализ JSON'ов любой сложности перестал представлять какие-либо проблемы.
В приведённом примере с датами операций их можно извлечь примерно одной строкой, а второй строкой преобразовать строки в настоящие даты и построить в соседнем окошке график
Здесь, на мой взгляд, есть два принципиально разных подхода. Первый, условно, заказная разработка: там есть место и торговле, и уступкам и т. п., короче говоря, разработка и заказчик по разные стороны. Второй вариант — когда заказчик и разработка "в одной лодке" и в конечном счёте ищут оптимальное по времени и качеству решение общих задач.
Да, для вывода имплементации From можно воспользоваться одним из этих крейтов. Ещё хочу обратить внимание на статью, где автор избавляется от unsafe, одновременно делая код более выразительным и не снижая (а иногда и повышая) производительность
Я назвал, сколько я хочу, и мне сказали, что я могу на это рассчитывать, что меня полностью удовлетворило
У меня впечатление прямо противоположное, а как Вы пришли к такому выводу?
Простите, насчёт «далёкого от реальности» я что-то, по-видимому, не так понял. Если Вы поясните свою точку зрения, то давайте продолжим дискуссию.
Про архитектурную секцию в целом согласен, но реальность показывает, что не все хорошие архитекторы хороши в разработке алгоритмов, равно как и наоборот.
CRUD-задачка у меня за всё время, кажется, была одна. Остальное существенно интереснее.
Работа, чтобы платить ипотеку, у меня была, и я оттуда ушёл, поскольку она не удовлетворяла мою потребность в творческой самореализации.
Я бы не сказал, что решение алгоритмических задач — навык, далёкий от реальности. Да, в реальной работе напрямую сливать массивы мы, скорее всего, не будем. Но в любой реальной задаче чуть сложнее, чем написать CRUD, нужно понять, как в принципе сделать то, что нужно (и не сделать то, что не нужно), какие граничные случаи могут возникнуть, не сломается ли оно тогда, когда данных станет больше, и т. д. А алгоритмические задачи, на мой взгляд, представляют собой своего рода минимальный пример, где все эти навыки можно продемонстрировать.
Для меня сложно представить себе хорошего разработчика, для которого слияние отсортированных массивов — это сложная задача. И, конечно, на собеседовании мне хочется показать свои сильные стороны. Так что к тезису «люди в здравом уме не будут усложнять собеседования» я бы добавил — если оное собеседование позволяет адекватно продемонстрировать релевантные навыки.
А вот что касается ВК, то описанное Вами наводит на мысль: это не случайное моё невезение, это — система.
Да, на этапе согласования оффера в Яндексе была некоторая бюрократия (и я про это написал). Но в остальном-то всё было максимально прозрачно и чисто — особенно на фоне ВК, где были постоянные переносы встреч, отсутствие какого-то ясного плана, ответы в телеграме на следующий день или через несколько дней на протяжении всего процесса.
Нет, я накатал такую простыню не ради вывода «не всё так однозначно». Мне было весело и прикольно, и я был рад, что сформированные ожидания не оправдались, и этой радостью я хочу делиться
На основание упомянутых в начале статей у меня сформировалось мнение, что «алгоритмические задачи никак не связаны с реальностью». Реальность это мнение скорректировала: навыки, нужные для прохождения подобных интервью, пригождаются на деле и в работе.
А если произвольно понадёргать фраз, то можно подвести основания под любое мнение.
Что же касается количества этапов, то для меня это не выглядело неадекватным (в отличие от универсального интервью про всё на свете от ВК).
Если логика для всех трёх случаев имеет мало общего (а, скорее всего, оно так и есть), то можно объявить трейт
AsLabelListс единственной функциейhas_labelреализовать его для всех нужных типов. Тогда можно указать для «единой» функции требование трейта и пробрасывать вызов дальше. Это отлично оптимизируется, а ещё позволяет пользователю реализовывать трейт для своих типов, которые тоже можно будет передать в нашу функциюДарю вам прекрасный термин «конкорд», которым, в частности, обозначаются те же квинтоктавы по отношению к старинной музыке.
А вот что действительно жаль, так то, что тоны означенных созвучий выбираются случайно
Было бы по-настоящему здорово не перереализовывать уже имеющийся как минимум в Windows и macOS функционал (десять лет назад у меня винда прекрасно меняла обои автоматом — там были разные раскрашенные фрагменты множества Мандельброта), а написать, допустим, кроссплатформенную утилиту, которая эти системные настройки выставляет унифицированно, например. Закинул список URL, а он тебе все их скачал и поставил в ротацию средствами системы. И обновляет ещё периодически, когда новые картины появляются.
Ну и отдельное количество недоумение — Electron. Тащить целый браузер ради того, чтобы просто продублировать системный функционал...
Но хорошо, что удалось поупражняться в реализации своих идей, этого не отнять.
Про R я в принципе знаю достаточно давно, но именно на tidyverse меня навела ChatGPT, так что какие-то базовые вещи я освоил меньше, чем за день. Правда, она довольно быстро перестала помогать и начала мешать, поэтому дальше я, собственно, читал статьи на сайте tidyverse.
Вот, кстати, добрался до компьютера и могу привести те самые две строчки (и масса «обвеса») для ваших данных:
Из неочевидных плюшек NSE, о котором упоминал в комментарии ниже, например, возможно такое:
Можно пощупать прямо в бразуере
Из-за того, что называется NSE — non-standart evaluation. R ленив, и вычисляет значения аргументов только при необходимости. Более того, их можно превратить обратно в языковые конструкции и проинтерпретировать иначе. В итоге каждая функция может иметь свой мини-синтаксис для аргументов. Потенциально это может, конечно, вести к хаосу, но на деле это делает синтаксис яснее и понятнее, например:
оставит только те столбцы, имена которых начинаются с
c, позволяя не перечислять их имена.Ну и pipe-оператор, действующий так:
Из-за этого код получается короче и яснее
С тех пор, как я освоил rectangling (https://tidyr.tidyverse.org/articles/rectangle.html) при помощи tidyr, анализ JSON'ов любой сложности перестал представлять какие-либо проблемы.
В приведённом примере с датами операций их можно извлечь примерно одной строкой, а второй строкой преобразовать строки в настоящие даты и построить в соседнем окошке график
В 1.21 выводит, как у автора, а в 1.22 — как по «здравому смыслу»: поправили. Про это писали недавно
Не «о чём», а «зачем». Ответ есть в конце статьи
Современная нотация фиксирует существенно больше, чем 88 вариантов высот, распределённых во времени...
Тот случай, когда комментарии полезнее статьи. По-моему, эта история может стать отличной статьёй
Здесь, на мой взгляд, есть два принципиально разных подхода. Первый, условно, заказная разработка: там есть место и торговле, и уступкам и т. п., короче говоря, разработка и заказчик по разные стороны. Второй вариант — когда заказчик и разработка "в одной лодке" и в конечном счёте ищут оптимальное по времени и качеству решение общих задач.
Да, для вывода имплементации
Fromможно воспользоваться одним из этих крейтов. Ещё хочу обратить внимание на статью, где автор избавляется от unsafe, одновременно делая код более выразительным и не снижая (а иногда и повышая) производительность