Обновить
40

Инженер-программист

37
Подписчики
Отправить сообщение
Вроде, только при сложном течении болезни
Я правильно понимаю, что для того, чтобы статья из песочницы стала видна всем, её должны одобрить модераторы?
Так-то никто не заставляет читать. Не интересно — пролистайте дальше.

Интересно, есть ли возможность добавить какие-то теги в игнор лист? Если нет — то напишите разработчикам хабра, всё больше толку чем называть статьи мусором в комментариях.
>Беларусь, Россия и Великобритания сделали выбор в пользу естественной вакцинации, в ближайшие пару месяцев результаты будут видны.

Насчёт остального спорить смысла не увидел, но вот тут уже не сдержался.

Не знаком с ситуацией в ВБ, но Россия усиленно закрывает границы в том числе и с Беларусью, в которой пока все заражённые — это люди приехавшие из-за границы и их непосредственные контакты.

Так что как раз таки наоборот, вирусу не дают приникнуть в страну на вольный выпас, а блокируют все случаи на границах.
Да, вы правы, но Хиршберг позволяет восстанавливать ответ, то есть указывать, какие символы надо заменить, удалить, вставить, чтобы получить другую строку, и делает это за линейную память. Стандартный алгоритм требует всю матрицу для востановления, то есть квадратичную память. :)
В данной заметке мы рассмотрели способы оптимальной реализации алгоритма Вагнера-Фишера, который требует O(n*m) времени (два вложенных for). Хотя по ссылке выше есть и алгоритм Хиршберга, который работает за линейное время

Статья отличная, но вот в данном предложении, вроде бы, должна быть память, а не время, время и там, и там — квадрат.
Спасибо за ответ. Что джойны лучше убрать, где можно, это понятно. Под денормолизацией понимается ввиду хранение не 2 таблиц, которые нужно джойнить, а сразу сджойненную? Извиняюсь за ещё один глупый вопрос.
и что нам нужно немедленно всё останавливать и денормализовать всю структуру в БД для оптимизации под чтение (прямо как нас в универе учили!)

Извиняюсь, за глупый вопрос, последний раз базы трогал именно в универе. А как там можно ускорить чтение, помимо индексов?
Я даже не представляю, как при отображении таблички получить что-то хуже n^2.

Ну уже n^2, в начале было факториал. :)
А вообще всё зависит от задачи и сценариев использования. Допустим у нас данных даже 10000, допустим даже таблица строится за квадрат (т.е. 10^10), это для процессора, который может выполнять десятки миллирдов операций (как раз таки 10^10) несколько секунд (если не считать рендеры, я не знаю, как они работают, туда не лезу). А потом кому-то надо с этой таблицей работать и на каждой перезагрузке получаем уже k*N^2, где k — число перезагрузок, что вызывает уже боль. А не дай бог, потребуется сделать операцию над каждой ячейкой и она будет перересовываться именно после каждой ячейки. Уже получаем куб. В общем я согласен с вами, что знание рендера очень важно, но квадраты пихать тоже не стоит.
Я уже много беседовал на эту тему со свидетелями Священной Big O, и мне довольно-таки надоело, но напишу еще раз тут: для фронтэндера, например, вопрос знания сложности алгоритмов в лучшем случае примерно третий по важности, и на собеседовании особо не значим. Почему? Потому что высокая алгоритмическая производительность на фронтэнде иногда нужна, но весьма редко; а вот знать, как браузер грузит ресурсы и рендерит страницу — нужно практически для любого реального проекта. Быстродействие будет определяться именно этими двумя вещами, а не тем, что вы где-то там внутри дуболомно изобразили O(n!), вот только n всё равно выше десятка не вырастет даже в теории.


Главное, чтобы потом не надо было отобразить табличку, в которой более 100 элементов. А ведь иногда ещё и 1000 может прийти. Очень не каждый выдержит такое. Jira и confluence вот не всегда справляются.
Вообще топики про собеседования на хабре — это такая специальная олимпиада, где все воюют против всех.

Не только они. Вообще, наверно, большинство топиков с рейтингом больше 100 — это вот такие холивары, если не все топики.
Не раскрыта тема приятности в общении. Человек может ответить на все вопросы и прорешать все задачки, но вот предложения ему не дождаться, потому что запах изо рта, в общении тяжёлый, плохо реагирует на критику (а как тогда его код ревьюить), стесняется критиковать сам (а как тогда он джунов будет учить), а ему ещё в джире надо в тикетах отписывать и на митингах что-то предлагать, и вообще, не хочу я его видеть по 8 часов в офисе рядом с собой.
Мир устроен жестко — или ты вкалываешь жестко первые 20 лет своей жизни во время учёбы и расслабляешься на хорошей работе остаток своей жизни, или ты пинаешь первые 20 лет и расслабляешься как можешь — но зато остаток жизни вкалываешь как проклятый на такой вот работёнке.

Это всё конечно так, особенно в некоторых странах, но в других нет бесплатного обучения в колледже, и ты бы и рад отучиться на адвоката и получать несколько сотен тысяч в год, но приходится вкалывать в фастфуде за несколько десятков. Особенно, если у родителей нет денег оплатить тебе кредит на образование, зато есть счета из больницы, которая не менее платная, чем колледж.
Мне казалось из предыдущих статей, что индийцы как раз и модерируют фейсбук…

Ну судя по статье таки не все офисы ещё перенесли.
>Модераторы: Подают в суд на ютуб за то что они смотрят неприятный контент
на ютуб?)

Ожидается, что подобные иски подадут десятки, если не сотни, модераторов. Источник из юридической компании Coleman & Partners, работающей на Грея, рассказал нам, что новые документы будут отправлены в Верховный суд в этом месяце.

Думается фейсбук скоро наймёт компанию из Мумбая для модерации вместо компании из Дублина.
автор:
>Ненавистники Python всегда говорят, что Python — это медленно. Но то, что некая программа, независимо от используемого языка программирования, может считаться быстрой или медленной, очень сильно зависит от разработчика, который её написал, от его знаний и от умения создавать оптимизированный и высокопроизводительный код.

он же:
>Дело тут, в основном, в том, что встроенные механизмы языка реализованы средствами C. Если описывать нечто средствами Python — нельзя добиться того же уровня производительности.
Ну, это же чушь? Повторюсь, а если я **kwargs передаю через цепочку вызовов? То мне делать дополнительные конвертации?

Ну если вам не надо, то никому не надо, это очевидно.

а это пускай просто проверяет единственный аргумент на то True или False. Если передали больше одного аргумента — ошибка выполнения.


Там более весёлый механизм.

И вы не перепутали тело ф-ции и сигнатуру?
Зачем же ограничивать гибкость типов аргументов? В некоторых случаях использование имени параметра вместо его позиции будет бесполезным и неуместным. Ограничение так же позволит избежать проблем, если вы планируете изменить имена позиционных аргументов в будущем.


Некоторые ф-ции из стандартной библиотеки имеют такую сигнатуру, например bool.

Changed in version 3.7: x is now a positional-only parameter.


Что выглядит вполне логичным, действительно, какие имя дать этому параметру? `o`, `x`, `a`?

И вполне логично запретить вызов

bool(a=x)
Создали отдельную сущность, заметим, только в 2016м. Через восемь лет после выхода Python 3.0

Что подтверждает только то, что это не было первостепенной задачей ни для кого. Иначе ввели бы раньше.
Работа с однобайтовыми кодировками банально быстрее, чем с многобайтовыми. А для словаря с одним языков (99% случаев) многобайтовая кодировка не нужна.


Ещё раз, python не про скорость и не работу с бинарными данными, он про читаемость, файл с несколькими кодировками — это не к читаемости. Создатели python не предусматривали такой сценарий, естественно, он в таком формате неоптимален, но люди, смешивающие кодировки, должны страдать.
В тоже время куча людей создаёт сайты на django, тесты и скрипты автоматизации на python и не жалуется.

Зачем вы храните разные кодировки в одном файле?


Потому что так удобнее.


Вы уверенны? Новички, приходящие в вашу команду, как это воспринимают? Интуитивно понятно?

была такая беда в Fedora — всё накрывалось медным тазом из-за того, что строка сообщавщая об успешном завершении установки выбрасывала UnicodeError…


Текст — это сложно. Я про это отписал, как починили по итогу?

Ну и как, я извиняюсь, это может работать? Ни один из предложенных там вариантов не позволит мне сохранить данные после декодирования.

Почему? Вы прочли бинарные данные — перегнали их в текст, обработали — перегнали обратно в бинарные. Можно даже сразу обрабатывать бинарные, `b'my_string'` вам в помощь. Если формат файла более-менее постоянен и позволяет описать их константами.

И вы так и не написали, как реализованы строки в C++.
То, что в них нельзя засунуть произвольную последовательность байт, очевидно. Например вы не можете имя файлы (которое в Windows не обязано быть валидной UTF-16 последовательностью, а в Linux валидной UTF-8 последовательностью) поместить в строку и проверить — не начинается оно с нужного вам префикса.


Это проблемы python или ОС, которые сохраняют имена файлов в чём попало? Строка в python имеет определённую кодировку, вполне логично запретить туда записывать мусор. Для работы с файлами создали отдельный механизм, потому что это отдельная сущность. Зачем ломать из-за этого общий механизм?

Ну и кому и зачем это может быть нужно? Зачем оптимизировать работу под операции которые никогда не используются (или используются исключительно редко) за счёт операций, которые используются часто?


Ну если вам ненужно, очевидно, что всем не нужно. Напишите в почтовую рассылку, просветите заблудшие души.

Есть C, который гораздо лучше подходит под обработку бинарных данных, python вообще не про это.


А про что он вообще тогда?


Про читаемость. Это если одним словом, если несколькими — это к дзену, там про бинарные данные ничего нет.

Никак — ошибка же в дизайне. Остаётся только смириться. Ну вот такой вот бессмысленный высер, который обошёлся индустрии в миллиарды и не дал никакой прибыли. Конструктивно — нужно убрать человека, который его затеял, чтобы больше такого не повторялось.


Опять же, могу только посоветовать написать в рассылку. Кстати, а как вы подсчитали урон? Можете поделиться?

В Python3 любое простое решение «правильно на 99.9%», но вот оставшийся 0.1% — исправить, зачастую, возможно только полными переписываением всей программы. Что дорого и сложно.


Утверждение верное для любой технологии, даже молотка.

Простейший пример, которым я всегда тыкаю в нос — простенький файл для работы со словариком и там буквально пяток функций для каждого языка. Которые просто возвращают список гласных, список согласных и так далее. Для английского, немецкого, польського и русского (там ещё что-то было — но эти ключевые). Функции, работающие с немецким рассчитаны на Latin-1, на польский — на Latin-2, Руссики — windows-1251… ну и комментарии в UTF-8 для удобства.

Всё это, ещё раз повторяю, в одном файле. Инструменты старого образца (Emacs, Far или тот же Python2) — вообще не проблема. Говорим, что это последовательность байт и всё. Что-то сделать в Python3… практически невоможно.

Ну потому что этот текстовый файл в Python3 строку — не лезет. Ну никак.


Это простой пример? Зачем вы храните разные кодировки в одном файле? В чём скрытый смысл? Как вы его обрабатываете сейчас? Чем? Зачем?

С этого момента — поподробнее: как его применять для редактирования подобного файла?


Читаете файл, как бинарный блоками, на блоке вызываете decode/encode

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность