мммм, понимаю, что можем уйти в дискуссию, скажу мягко, что только частично согласен
яб написал явно "заменить все табуляции на пробелы", "заменить все переводы строки на пробелы"
К сожалению много пользователей было (> 100; < 1000) и к каждому лично не сходишь и не скажешь: "пожалуйста, не используйте: табы, разделители, прочее" - придётся целую лекцию читать каждому по пробелам и пробельным символам, и абсолютно точно большинство пропустит мимо ушей.
А учитывая источник данных (который может быть любым)
Пользователь может сам вручную заполнить текст и в процессе заполнения случайно вбить 2 лишних пробела;
Однако, не редко текст для заполнения с пробельными символами уже где-то написан (в Word-е, интернете и пр.) и его просто берут и копируют.
нужно был: короткое, мощное, покрывающее большинство случаев (надеюсь 99%) решение
И "да" регулярные выражения сложные, из-за чего однако я отважился их применить в самом что ни на есть минималистичном виде.
П.С. А вот с этим полностью соглашусь
И не потому, что я регэксп "не осилю", а потому, что у меня совершенно нет уверенности, что его быстро поймет и осилит тот, кто будет это после меня трогать когда-нибудь.
где-то статью читал с призываом не парсить html при помощи регулярных выражений, а использовать нормальные/адекватные библиотеки - вот в таком ключе 100% регулярки = антипаттерн
И по поводу функции .trim() - в Python это .strip() называется, но суть, не меняется удаляет начальные и конечные пробелы (и, "да", можно что-нибудь иное удалить но только на концах строки)
Такое ощущение, что многие сознательно обходят тему регулярных выражений. Всё что угодно, лишь бы их не использовать, может реально кто-то не слышал...
Скажем так: эта статья - компенсация за боль ручной вычистки )
Excel люблю, но вот финансовые формулы обходил - потому что они много внутри себя крутят и как говорил в статье - не очевидны.
Понимаю, что есть задачи, когда, условно, есть 100 варианов кредитов/инвестиций и нужно выбрать лучший/меньший/больший - тут да, бесспорно финансовые формулы тут must have - их компактность решает.
Вопрос, наверно, дискуссионный, и ответ как правильно поступать, боюсь, лежит где-то посередине.
Соглашусь, что чтобы быть профи, например, в lisp-е действительно нужно тренировать именно lisp.
Однако, никто не может гарантировать, что востребованность именно в этом языке как в инструменте со временем не угаснет и весь legacy код вдруг разом не будет переписываться на новый "модный, стильный, молодёжный".
Тут есть ограничение на ответ API hh - больше 2000 не выдает. Конечно желательно ограничивать выборку при помощи уточнения запроса
Все вакансии с "инженер" в названии релевантные, пусть там будет зп 300к или 50к.
Ну если "инженер-технолог" и/или "инженер-программист микроконтроллеров" и/или "инженер по охране труда" являются прям равнозначными, а следовательно релевантными, то, извините, помочь Вам не смогу.
Явно имеет место смешивание разных областей знаний - и стоит с громадным скепсисом отнестись к получаемой цифре.
А в качестве критики могу только сказать, что главная проблема - в данных. И в том чтобы правильно оценить свое место на полученном распределении.
Абсолютно верно. Это целая головная боль как из данных получить информацию. Не хотел бы вдаваться в пространные рассуждения, но придётся... Отмечу, что можно играться комплексно: где не помогают числовые методы - можно поставить административные (обоснованные) ограничители. Если 1 методика не раскрывает полноту, можно параллельно использовать несколько - увеличив, правда, порог вхождения.
Абсолютно верно
просто уточню (не принципиально) спущена сверху максимальная длина строки 255 символов
мммм, понимаю, что можем уйти в дискуссию, скажу мягко, что только частично согласен
К сожалению много пользователей было (> 100; < 1000) и к каждому лично не сходишь и не скажешь: "пожалуйста, не используйте: табы, разделители, прочее" - придётся целую лекцию читать каждому по пробелам и пробельным символам, и абсолютно точно большинство пропустит мимо ушей.
А учитывая источник данных (который может быть любым)
нужно был: короткое, мощное, покрывающее большинство случаев (надеюсь 99%) решение
И "да" регулярные выражения сложные, из-за чего однако я отважился их применить в самом что ни на есть минималистичном виде.
П.С. А вот с этим полностью соглашусь
где-то статью читал с призываом не парсить html при помощи регулярных выражений, а использовать нормальные/адекватные библиотеки - вот в таком ключе 100% регулярки = антипаттерн
И по поводу функции .trim() - в Python это .strip() называется, но суть, не меняется удаляет начальные и конечные пробелы (и, "да", можно что-нибудь иное удалить но только на концах строки)
https://ru.wikipedia.org/wiki/Trim
Нет, по умолчанию (условно) global = true, т.е. везде заменяет
А для номеров вхождений re.sub() имеет параметр count, т.е. вот так примерно:
https://translated.turbopages.org/proxy_u/en-ru.ru.c8cf6852-68b4889a-e1b508bf-74722d776562/https/stackoverflow.com/questions/3951660/how-to-replace-the-first-occurrence-of-a-regular-expression-in-python
Честно скажу - не знаю. Да и хотел покороче а "мыслию по древу растёкся" (
Просто видел вот такое (и не единожды в разных интерпретациях):
https://sky.pro/media/udalenie-lishnih-probelov-v-stroke-v-python/?ysclid=mezypmjc8s446455963
Такое ощущение, что многие сознательно обходят тему регулярных выражений. Всё что угодно, лишь бы их не использовать, может реально кто-то не слышал...
Скажем так: эта статья - компенсация за боль ручной вычистки )
Виноват, исправил, спасибо
Excel люблю, но вот финансовые формулы обходил - потому что они много внутри себя крутят и как говорил в статье - не очевидны.
Понимаю, что есть задачи, когда, условно, есть 100 варианов кредитов/инвестиций и нужно выбрать лучший/меньший/больший - тут да, бесспорно финансовые формулы тут must have - их компактность решает.
Потыкался немного...
Соглашусь, не получается при каких-то условиях досрочное погашение выгодным при больших % по депозитам.
(моральное удовлетворение от гашения можно не брать - не посчитать)
Добавил в список, спасибо, но без картинок
) угу )
На самом деле призадумался.
Вопрос, наверно, дискуссионный, и ответ как правильно поступать, боюсь, лежит где-то посередине.
Соглашусь, что чтобы быть профи, например, в lisp-е действительно нужно тренировать именно lisp.
Однако, никто не может гарантировать, что востребованность именно в этом языке как в инструменте со временем не угаснет и весь legacy код вдруг разом не будет переписываться на новый "модный, стильный, молодёжный".
Да, в принципе, можно...
Только с валютой проблемы будут - пока только пересчёт в рубли работает. Собственно из-за этого географию ужал до РФ.
Запрос был ожидаем, в MVP не входил. Ладно, придумаю что-нибудь сегодня вечером
Кстати, спасибо за вопрос. Действительно нужно об этой проблематике упомянуть не в комментариях, а явно в самой статье. Обновил "Недостатки".
Это действительно минус.
Тут есть ограничение на ответ API hh - больше 2000 не выдает. Конечно желательно ограничивать выборку при помощи уточнения запроса
Ну если "инженер-технолог" и/или "инженер-программист микроконтроллеров" и/или "инженер по охране труда" являются прям равнозначными, а следовательно релевантными, то, извините, помочь Вам не смогу.
Явно имеет место смешивание разных областей знаний - и стоит с громадным скепсисом отнестись к получаемой цифре.
Всё верно
Но опять же - не релевантные вакансии можно выкидывать
См. таблицу с перечнем вакансий, столбец "Берём?"
Т.е. пересчитается в зависимости от выбора пользователя (компьютерная версия браузера - у мобильной версии есть проблемы, что не хочет пересчитывать)
Исправлено, спасибо за подробную описание последовательность!
Спасибо большое за ободряющий комментарий!
Спустя длительное время возвращаюсь с ответом.
Абсолютно верно. Это целая головная боль как из данных получить информацию. Не хотел бы вдаваться в пространные рассуждения, но придётся... Отмечу, что можно играться комплексно: где не помогают числовые методы - можно поставить административные (обоснованные) ограничители. Если 1 методика не раскрывает полноту, можно параллельно использовать несколько - увеличив, правда, порог вхождения.
Если будет время/желание могу "прорекламировать" https://habr.com/ru/post/689990/ - тут именно "воплощение" идей данной статьи
Исполнено!
Если будет интересно: https://habr.com/ru/post/689990/
Соглашусь, надо бы помимо Венгерской нотации (одной из её метаморфоз) на типизированный Python переходить...
Исправлено, ещё раз спасибо!