Ой, да бросьте. Все мои эксперименты на сегодня заканчивались тем, что на просьбу написать код для сравнения двух больших (не влезает в память?) прямоугольных таблиц с первичными ключами (например на Scala с применением Spark) оный "ИИ" первое что делал - это загружал оные большие таблицы в память, и дальше пытался мне впарить код сравнения в памяти. А на мои резонные замечания, какого мол хрена, он сначала впилил в исходный вариант (вполне валидный, просто ужасно неэффективный) некий код из Spark ML, чего в задаче вообще было не нужно, а потом просто потерял контекст, и начал гнать код на питоне (тоже с применением Spark ML). Ну т.е. первая попытка - в тему, но не рабочая, а все попытки исправить - фейл на фейле сидит и им же погоняет.
Ну т.е. edge cases тут просто близко не лежали. Тут даже базовая логика не была реализована. Ну т.е. в текущем виде я бы сказал, что оно вообще ничего кроме отдельных кусков кода сгенерить не может. И те лишь иногда.
Не, ну сжатие и индексы - это даром не дается, очевидно. Вы же не считаете тот факт, что типичная реляционная СУБД строит/достраивает индексы при каждой операции обновления, недостатком? Это скорее фича, особенность, с учетом которой надо выбирать инструмент. Желательно чтобы эта фича отключалась, очевидно, и настраивалась.
Вот это и странно. Как правило, если есть специализация - должны быть минусы в тех областях, на которых продукт не специализируется. А попытки сделать что-то универсальное как правило имеют минусы повсюду :) А тут... документация, хм.
Тесты в VBA пишутся точно так же, как в любом другом языке. Просто инструмент их запуска будет другой.
Что до C#, то я скорее хотел сказать, что автоматизировать работу с Excel можно практически на любом языке, который поддерживает Windows, потому что он скорее всего поддерживает COM. Скажем, я это делал примерно на четырех разных языках. И если вам так уж хочется - то ActivePython это умеет не помню уже сколько лет (больше 20-ти точно).
Разумеется, автор может выбрать любой удобный ему стек, чтобы работать с данными. Это не отменяет того факта, что недостатки Excel из коробки тут описаны, прямо скажем, предвзято. Давайте по пунктам:
Какие есть серьезные проблемы при работе в Excel файлами, кроме очевидных преимуществ.
Нужно писать на языке VBA, чтобы автоматизировать рутину: например, очищать данные, или приводить их к нужному виду. Или вам приходится заказывать эти скрипты в it отделе, а они почему то не спешат вам помочь.
Трудно работать с версиями, делать бэкапы. Код макроса может внезапно перестать работать, а на наладку может уйти много времени.
Нужна лицензия на полноценную работу, есть привязка к Windows, что сейчас крайне актуально для многих компаний в РФ с переходом на Linux. А python и СУБД (Например SQLite или PostgreSQL) имеют открытый исходный код и распространяются свободно.
Код макроса может перестать работать после обновления Excel.
Ограничение excel по размеру в миллион строк, и зависание при работе на больших массивах (более 200 000 строк на средних офисных машинах)
Нет, VBA не нужно. Уже давно можно писать на любом языке, поддерживающем COM, включая кстати и питон. А так штатный язык я бы сказал на сегодня C#.
Это также верно и для любого другого стека. Если у вас поменяется структура документа - ваш код сломается. Что же до версий скрипта - то его надо делать плагином, а не держать в одной таблице с данными - и все с ним будет хорошо, включая возможность хранить его в VCS.
Ну разумеется нужна. Это платный продукт. За эти деньги вы получаете свои плюсы. А за пользование продуктом бесплатным вы тоже платите - своим временем, как правило.
Ваш код тоже может перестать работать по многим разным причинам.
Да, ограничение по размеру конечно есть. И я бы даже сказал более сильное, чем миллион строк. Если у вас датасет правда больше - вам прямой путь к СУБД. Это не проблема Excel, это ограничение, его надо было учесть при выборе технологии.
Ну то есть, я бы сказал, что три претензии - не сильно по делу, и еще две - валидные, но намекают на то, что пользоваться Excel и автоматизировать работу в нем тоже нужно уметь.
Ну, в каком-то смысле сложность вопросов растет с опытом. Т.е. типовая картинка несоответствия выглядит примерно так - кандидат пишет в резюме, знаю мол PostgreSQL, и еще немного Oracle. Начинаем спрашивать что-то специфически оракловое - плавает. Специфически постгресное - плавает. На прямой вопрос, а что вы делали в прошлом проекте, отвечает честно, что писал простые запросы, даже без JOIN. Что это, если не опыт? Ну то есть просто копаем в глубину и в ширину, чтобы найти где у этого опыта дно. Бывает же что в процессе можно выяснить, что человек пусть и нарисовал опыт, но на самом деле что-то знает, пытается расти, и в конце концов принимается решение, что он нам подходит. Почему нет?
требовать нотариально заверенную копию трудовой, рекомендации со всех мест работы и
Ну я совсем не это имел в виду, скорее реагировать иначе.
Тут как-бы сказать, у меня обычно не вызывает проблем выявить накрученный опыт работы скажем с СУБД, ну тупо потому, что своего опыта у меня примерно с 1986 года. Тут вопрос скорее в масштабировании такого подхода, потому что я же не могу собеседовать всех? А у коллег у самих опыт может быть меньше, или просто другой. Очевидный ответ - готовиться, записывать хорошие вопросы, планировать собеседования.
Она существует потому что накручивают. Не обязательно два года с нуля, могут два года с 8 до 10 накрутить. Ну то есть как-то на это надо реагировать.
Ну то есть, я тут не пытался как-то оценивать ваш текст, я скорее прокомментировал его с другой точки зрения, ответов же на вопросы у меня нет.
Для меня по моему опыту интервью это выглядит примерно так - есть кучка кандидатов с опытом, описанным как под копирку. То что они делали веб приложения - это не удивительно, понятно что веб приложения - один из массовых типов приложений, их объективно много, но и все остальное - практически идентично.
Впечатление такое, что их на курсах учили описывать опыт )
Ой, автор накрутил себе 2 года опыта. Прям страшно аж стало, и как же мы теперь будем нанимать джунов, как будем оценивать (спойлер - это был сарказм, ничего не изменится).
А ничего, что два года опыта это практически тоже самое что отсутствие опыта? Ну во всяком случае с моей точки зрения. Был джун без опыта, стал джун с небольшим опытом. И что?
Поехали дальше, попробую по пунктам показать, как можно иначе на описанный опыт посмотреть:
У меня 2 года коммерческого опыта программирования ( Go + python )
Я работал в разработке известной сети магазинов косметики
Проект был очень интересный: мы разрабатывали сервис скидочных карт - можно в админке ввести номер карты и получить всю информацию о покупках пользователя
По архитектуре - это был большой монолит на джанго, мы отпиливали микросервисы на go ( нотификации всякие и т.д.). База - postgres
В команде было 2 фронта, 2 бэка, 1 QA
Основная сложность - постоянно меняющиеся требования
Известная сеть магазинов косметики - т.е. не ИТ компания, налаженных процессов скорее всего нет, ничему научить не могут. Ставим минус.
Проект был до тошноты скушный. Я такие просто игнорирую. Если автору, как джуну, это и было интересно - то мне какое до этого дело на интервью? Пункт нерелевантный.
В команде было... а нам какое дело? Впрочем, не было аналитика, и непонятно, кто ставил задачи. Т.е. скорее всего грамотной постановки задач не было. Ставим минус.
Требования менялись? Ну и что? Это везде так. Пункт нерелевантный.
Итого, из приведенных шести пунктов накрученного опыта два нерелевантные, и два скорее минусы, чем плюсы. Я тут не придираюсь, я просто показываю, что к некоторым пунктам при желании можно и придраться.
У вас минут 5-10, максимум 15, больше разговаривать об опыте как-то не принято, вопросы надо придумать в риалтайме, пока я рассказываю текст выше.
Во-первых, "вопросы здесь задаю я" (с). Сколько надо, столько и будем спрашивать, пока нам не надоест. А во-вторых, как уже ответили, мы не просто можем подготовиться заранее, а давно подготовились, потому что вы у нас не первый кандидат, а скажем 101. Или 1001, смотря сколько у кого опыта.
Я это все к чему - проблема накрутки опыта она конечно существует. Просто автор смотрит на нее со своей точки зрения, и пытается опыт приукрасить так, как понимает. А с точки зрения нанимающего это приукрашивание ничего не дает, кроме лишних красных флагов и пары мест "а вот тут надо еще внимательнее поспрошать". Разумеется, это сильно зависит от того, каков опыт у нанимающего. И какие у него вообще мотивы. Совершенно не исключаю, что в каких-то случаях такой опыт можно будет выдать за реальный. А может и наоборот, станет хуже.
Ну вот просто для примера еще немножко - декларировали вы тут, что знаете/пользовались postgresql, Go и питоном. Ну вот вы серьезно считаете, что при желании интервьюер не найдет у вас десятки пробелов в знаниях по этим трем (бездонным) темам? Каждый такой конкретный пункт, который вы приписываете себе в опыт - это повод задать вам конкретный вопрос по этому пункту, и хороший шанс завалиться на этом вопросе. А уж что дальше будет - зависит от кучи факторов.
Нет, все вполне понятно. Просто я изначально говорил немного о другом. Я сравниваю (возможно это не явно выделено в комментарии) один аналоговый индикатор (пусть будет высоты) и один цифровой (тоже высоты). А вы рассказываете о том, что можно сделать систему из двух и более компонент, которые будут сразу показывать и высоту, и скорость, и все это скомбинировать так, что будет удобнее. В том числе сделать сочетание аналоговых стрелок и циферок, что видно в ваших примерах. Тут одно другому не противоречит, просто я говорил о простейшем случае, а вы рассматриваете реальные сложные.
P.S. На ваших примерах лично мне проще читать аналоговый. Там стрелка показывает что-то типа 3.6. А цифровое я бы сказал перегружено информацией. Впрочем, это разумеется вопрос обучения и привычек.
Спасибо, не надо. Если что, я писал на PS. И я бы сказал, что это два совершенно разных по назначению языка. Это не значит, что PS плохой, вовсе нет. Но далеко не факт, что для той задачи, что мы сегодня имеем, он был бы лучше.
Вот как эта статья может иметь +12, при том что в ней куча проблем? И тоже кучка комментариев, поясняющих, почему и где эти проблемы. И текст там такой же бессмысленный, как и этот... 100 вопросов про SQL.
Я так понял вы хотели ответить мне, но написали комментарий уровнем выше. Ну не важно.
есть ещё счётчик
Ну как бы, вы предлагаете два индикатора вместо одного. Который решал ту же задачу. Совсем не факт, что это правда будет лучше.
Я совершенно не склонен спорить, что цифровые индикаторы можно сделать более гибко, и в итоге практически любыми, под любые задачи. Это правда, и я это в том числе и пытался проиллюстрировать на примере уровня. Более того, если это на самом деле экран, то он и стрелочные индикаторы вполне может эмулировать, и на сегодня это уже не так и дорого.
Методика по крайней мере неполная. Достаточно очевидно, что стрелочный индикатор может кроме самого значения показывать скорость и направление его изменения. Ну просто как пример - высотомер в самолете. Вы видите что стрелка движется/вращается, и видите в какую сторону, и как быстро - видите тоже. Спидометр - примерно тоже самое.
В этих случаях (я заранее согласен, что не все случаи такие) у цифрового индикатора нет шансов.
Скорее всего, есть и обратные случаи. Например, цифровой индикатор (даже не потому что он цифровой, а потому что к нему прилагается цифровое устройство) может отражать некоторые дополнительные показатели, например, цифровой уровень может пищать, когда у нас нет вертикали/горизонтали, и изменять тон пищалки, когда мы к нужному углу приближаемся или удаляемся. Наверное в теории можно такое сделать и для аналогового - но по факту, такие цифровые я встречал живьем, а аналоговые никогда.
Ну и еще. Есть цифровые измерители скажем расстояния. И они уже очень давно позволяют измерения записывать, а недавно я видел рекламу прибора, который позволяет измерение прикрепить к сделанной прибором фотографии. Т.е. мы не просто меряем один размер, а обмеряем объект, и фиксируем множество измерений на модели объекта. С трудом себе представляю, как это реализовать на аналоговом индикаторе - записываем-то мы всегда циферки, то есть текст, а не картинку со стрелочками.
Да блин, в том-то и дело, что уже десятки лет есть более нормальные способы. Как тот же упомянутый ниже VBScript (а еще точнее - wscript/cscript), где все что нужно есть, в более удобном для написания скриптов виде. Намного более удобном. Причем там в обоих случаях доступны COM объекты, так что с найденными файлами вполне можно будет сделать что-то с их помощью - скормить их ворду, или записать их имена в Excel, ну так, просто для примера. То есть это будет полноценное решение, причем вполне штатными средствами ОС, а не это вот убожество.
Ой, да бросьте. Все мои эксперименты на сегодня заканчивались тем, что на просьбу написать код для сравнения двух больших (не влезает в память?) прямоугольных таблиц с первичными ключами (например на Scala с применением Spark) оный "ИИ" первое что делал - это загружал оные большие таблицы в память, и дальше пытался мне впарить код сравнения в памяти. А на мои резонные замечания, какого мол хрена, он сначала впилил в исходный вариант (вполне валидный, просто ужасно неэффективный) некий код из Spark ML, чего в задаче вообще было не нужно, а потом просто потерял контекст, и начал гнать код на питоне (тоже с применением Spark ML). Ну т.е. первая попытка - в тему, но не рабочая, а все попытки исправить - фейл на фейле сидит и им же погоняет.
Ну т.е. edge cases тут просто близко не лежали. Тут даже базовая логика не была реализована. Ну т.е. в текущем виде я бы сказал, что оно вообще ничего кроме отдельных кусков кода сгенерить не может. И те лишь иногда.
Не, ну сжатие и индексы - это даром не дается, очевидно. Вы же не считаете тот факт, что типичная реляционная СУБД строит/достраивает индексы при каждой операции обновления, недостатком? Это скорее фича, особенность, с учетом которой надо выбирать инструмент. Желательно чтобы эта фича отключалась, очевидно, и настраивалась.
Вот это и странно. Как правило, если есть специализация - должны быть минусы в тех областях, на которых продукт не специализируется. А попытки сделать что-то универсальное как правило имеют минусы повсюду :) А тут... документация, хм.
Как по мне, такой вопрос - это не просто с подвохом, а с подвохом в три слоя :)
Тесты в VBA пишутся точно так же, как в любом другом языке. Просто инструмент их запуска будет другой.
Что до C#, то я скорее хотел сказать, что автоматизировать работу с Excel можно практически на любом языке, который поддерживает Windows, потому что он скорее всего поддерживает COM. Скажем, я это делал примерно на четырех разных языках. И если вам так уж хочется - то ActivePython это умеет не помню уже сколько лет (больше 20-ти точно).
Регулярки для парсинга языка типа HTML это вообще фуу. И кстати, ИИ об этом не догадывается, естественно.
Разумеется, автор может выбрать любой удобный ему стек, чтобы работать с данными. Это не отменяет того факта, что недостатки Excel из коробки тут описаны, прямо скажем, предвзято. Давайте по пунктам:
Нет, VBA не нужно. Уже давно можно писать на любом языке, поддерживающем COM, включая кстати и питон. А так штатный язык я бы сказал на сегодня C#.
Это также верно и для любого другого стека. Если у вас поменяется структура документа - ваш код сломается. Что же до версий скрипта - то его надо делать плагином, а не держать в одной таблице с данными - и все с ним будет хорошо, включая возможность хранить его в VCS.
Ну разумеется нужна. Это платный продукт. За эти деньги вы получаете свои плюсы. А за пользование продуктом бесплатным вы тоже платите - своим временем, как правило.
Ваш код тоже может перестать работать по многим разным причинам.
Да, ограничение по размеру конечно есть. И я бы даже сказал более сильное, чем миллион строк. Если у вас датасет правда больше - вам прямой путь к СУБД. Это не проблема Excel, это ограничение, его надо было учесть при выборе технологии.
Ну то есть, я бы сказал, что три претензии - не сильно по делу, и еще две - валидные, но намекают на то, что пользоваться Excel и автоматизировать работу в нем тоже нужно уметь.
Ну, в каком-то смысле сложность вопросов растет с опытом. Т.е. типовая картинка несоответствия выглядит примерно так - кандидат пишет в резюме, знаю мол PostgreSQL, и еще немного Oracle. Начинаем спрашивать что-то специфически оракловое - плавает. Специфически постгресное - плавает. На прямой вопрос, а что вы делали в прошлом проекте, отвечает честно, что писал простые запросы, даже без JOIN. Что это, если не опыт? Ну то есть просто копаем в глубину и в ширину, чтобы найти где у этого опыта дно. Бывает же что в процессе можно выяснить, что человек пусть и нарисовал опыт, но на самом деле что-то знает, пытается расти, и в конце концов принимается решение, что он нам подходит. Почему нет?
Ну я совсем не это имел в виду, скорее реагировать иначе.
Тут как-бы сказать, у меня обычно не вызывает проблем выявить накрученный опыт работы скажем с СУБД, ну тупо потому, что своего опыта у меня примерно с 1986 года. Тут вопрос скорее в масштабировании такого подхода, потому что я же не могу собеседовать всех? А у коллег у самих опыт может быть меньше, или просто другой. Очевидный ответ - готовиться, записывать хорошие вопросы, планировать собеседования.
Она существует потому что накручивают. Не обязательно два года с нуля, могут два года с 8 до 10 накрутить. Ну то есть как-то на это надо реагировать.
Ну то есть, я тут не пытался как-то оценивать ваш текст, я скорее прокомментировал его с другой точки зрения, ответов же на вопросы у меня нет.
Для меня по моему опыту интервью это выглядит примерно так - есть кучка кандидатов с опытом, описанным как под копирку. То что они делали веб приложения - это не удивительно, понятно что веб приложения - один из массовых типов приложений, их объективно много, но и все остальное - практически идентично.
Впечатление такое, что их на курсах учили описывать опыт )
Ой, автор накрутил себе 2 года опыта. Прям страшно аж стало, и как же мы теперь будем нанимать джунов, как будем оценивать (спойлер - это был сарказм, ничего не изменится).
А ничего, что два года опыта это практически тоже самое что отсутствие опыта? Ну во всяком случае с моей точки зрения. Был джун без опыта, стал джун с небольшим опытом. И что?
Поехали дальше, попробую по пунктам показать, как можно иначе на описанный опыт посмотреть:
Известная сеть магазинов косметики - т.е. не ИТ компания, налаженных процессов скорее всего нет, ничему научить не могут. Ставим минус.
Проект был до тошноты скушный. Я такие просто игнорирую. Если автору, как джуну, это и было интересно - то мне какое до этого дело на интервью? Пункт нерелевантный.
В команде было... а нам какое дело? Впрочем, не было аналитика, и непонятно, кто ставил задачи. Т.е. скорее всего грамотной постановки задач не было. Ставим минус.
Требования менялись? Ну и что? Это везде так. Пункт нерелевантный.
Итого, из приведенных шести пунктов накрученного опыта два нерелевантные, и два скорее минусы, чем плюсы. Я тут не придираюсь, я просто показываю, что к некоторым пунктам при желании можно и придраться.
Во-первых, "вопросы здесь задаю я" (с). Сколько надо, столько и будем спрашивать, пока нам не надоест. А во-вторых, как уже ответили, мы не просто можем подготовиться заранее, а давно подготовились, потому что вы у нас не первый кандидат, а скажем 101. Или 1001, смотря сколько у кого опыта.
Я это все к чему - проблема накрутки опыта она конечно существует. Просто автор смотрит на нее со своей точки зрения, и пытается опыт приукрасить так, как понимает. А с точки зрения нанимающего это приукрашивание ничего не дает, кроме лишних красных флагов и пары мест "а вот тут надо еще внимательнее поспрошать". Разумеется, это сильно зависит от того, каков опыт у нанимающего. И какие у него вообще мотивы. Совершенно не исключаю, что в каких-то случаях такой опыт можно будет выдать за реальный. А может и наоборот, станет хуже.
Ну вот просто для примера еще немножко - декларировали вы тут, что знаете/пользовались postgresql, Go и питоном. Ну вот вы серьезно считаете, что при желании интервьюер не найдет у вас десятки пробелов в знаниях по этим трем (бездонным) темам? Каждый такой конкретный пункт, который вы приписываете себе в опыт - это повод задать вам конкретный вопрос по этому пункту, и хороший шанс завалиться на этом вопросе. А уж что дальше будет - зависит от кучи факторов.
ну почему, есть парочка-троечка :)
user: 'root' pass: 'passwd' db: 'appdb'Нет, все вполне понятно. Просто я изначально говорил немного о другом. Я сравниваю (возможно это не явно выделено в комментарии) один аналоговый индикатор (пусть будет высоты) и один цифровой (тоже высоты). А вы рассказываете о том, что можно сделать систему из двух и более компонент, которые будут сразу показывать и высоту, и скорость, и все это скомбинировать так, что будет удобнее. В том числе сделать сочетание аналоговых стрелок и циферок, что видно в ваших примерах. Тут одно другому не противоречит, просто я говорил о простейшем случае, а вы рассматриваете реальные сложные.
P.S. На ваших примерах лично мне проще читать аналоговый. Там стрелка показывает что-то типа 3.6. А цифровое я бы сказал перегружено информацией. Впрочем, это разумеется вопрос обучения и привычек.
До какой такой пенсии? Вы же видели у автора:
так это вот верный способ до пенсии не дотянуть.
Спасибо, не надо. Если что, я писал на PS. И я бы сказал, что это два совершенно разных по назначению языка. Это не значит, что PS плохой, вовсе нет. Но далеко не факт, что для той задачи, что мы сегодня имеем, он был бы лучше.
Я вам больше скажу - бывают имена файлов в разном регистре. И даже в Windows.
Я бы тоже хотел это понять. Причем это не единичный случай далеко.
https://habr.com/ru/articles/794604/
Вот как эта статья может иметь +12, при том что в ней куча проблем? И тоже кучка комментариев, поясняющих, почему и где эти проблемы. И текст там такой же бессмысленный, как и этот... 100 вопросов про SQL.
Я так понял вы хотели ответить мне, но написали комментарий уровнем выше. Ну не важно.
Ну как бы, вы предлагаете два индикатора вместо одного. Который решал ту же задачу. Совсем не факт, что это правда будет лучше.
Я совершенно не склонен спорить, что цифровые индикаторы можно сделать более гибко, и в итоге практически любыми, под любые задачи. Это правда, и я это в том числе и пытался проиллюстрировать на примере уровня. Более того, если это на самом деле экран, то он и стрелочные индикаторы вполне может эмулировать, и на сегодня это уже не так и дорого.
Методика по крайней мере неполная. Достаточно очевидно, что стрелочный индикатор может кроме самого значения показывать скорость и направление его изменения. Ну просто как пример - высотомер в самолете. Вы видите что стрелка движется/вращается, и видите в какую сторону, и как быстро - видите тоже. Спидометр - примерно тоже самое.
В этих случаях (я заранее согласен, что не все случаи такие) у цифрового индикатора нет шансов.
Скорее всего, есть и обратные случаи. Например, цифровой индикатор (даже не потому что он цифровой, а потому что к нему прилагается цифровое устройство) может отражать некоторые дополнительные показатели, например, цифровой уровень может пищать, когда у нас нет вертикали/горизонтали, и изменять тон пищалки, когда мы к нужному углу приближаемся или удаляемся. Наверное в теории можно такое сделать и для аналогового - но по факту, такие цифровые я встречал живьем, а аналоговые никогда.
Ну и еще. Есть цифровые измерители скажем расстояния. И они уже очень давно позволяют измерения записывать, а недавно я видел рекламу прибора, который позволяет измерение прикрепить к сделанной прибором фотографии. Т.е. мы не просто меряем один размер, а обмеряем объект, и фиксируем множество измерений на модели объекта. С трудом себе представляю, как это реализовать на аналоговом индикаторе - записываем-то мы всегда циферки, то есть текст, а не картинку со стрелочками.
Да блин, в том-то и дело, что уже десятки лет есть более нормальные способы. Как тот же упомянутый ниже VBScript (а еще точнее - wscript/cscript), где все что нужно есть, в более удобном для написания скриптов виде. Намного более удобном. Причем там в обоих случаях доступны COM объекты, так что с найденными файлами вполне можно будет сделать что-то с их помощью - скормить их ворду, или записать их имена в Excel, ну так, просто для примера. То есть это будет полноценное решение, причем вполне штатными средствами ОС, а не это вот убожество.