Свой вариант сохранил. Мне были интересны других. В частности, по-моему название было viking. Я не думал, что интернет можно "потереть". Остались только упоминания без исходных кодов
В 200х в определенных кругах было что-то типа соревнования на написание самого маленького резидентного вируса под dos. Там реально годами уменьшали по несколько байт. В начале соревнования было что-то типа 113 байт (точные цифры не помню), под конец 64. Я потратил несколько дней (!) для того чтобы добиться этих самых 64. Это была тяжелейшая головоломка. На всякий случай скажу, что эти вирусы никакой опасности не представляют ибо время доса ушло, это чисто спорт, вирус был фактически на бумаге. К сожалению все исходники этих микро вирусов Гугл потер(
Все знают ответ на эту загадку с детства. Уверен практически никто своей головой до этого не додумается. Можно ради интереса задать кому-то англоязычному
Можно для джунов, не особо знакомых с терминологией, пояснить. Вот я спускаюсь со склона, лыжи под каким-то углом. Я частично срываю снег и слегка перемещаюсь горизонтально. На крутых (для меня) склонах на этот срыв (торможение) тратится столько энергии, что ноги болят аццки. Что я делаю не так?) Также обратил внимание, что многие летают и вроде как притормаживают, как будто контролируют скорость. Попробовал также и понял что контроль скорости осуществляется тупо за счёт сопротивления воздуха, т.е когда стена воздуха не даёт тебе разогнаться до бесконечности. Это я не считаю контролем. Короче, если я применяю значительные усилия на срыв снега, то это из-за того что я ламак, а не хиляк?
Офтоповый вопрос: вы стрелочки с Клавы набираете или откуда-то копируете? Когда мне в тексте (программы) нужна стрелочка, я всегда гуглю utf8 arrow. А каменте на хабре написал бы просто ->
Приведу на perl, поскольку (внезапно) на нем лаконичнее. Самое простое, когда необходимо найти фрагмент, перед и/или после которого стоит определенный фрагмент:
$s = "This is a <b>test</b>!";
$s =~ m|<b>(.*?)</b>|;
print $1; # печатает test
Здесь, как я говорил, лучше не использовать сущность "найденный фрагмент" и заглядывания вперед/назад, а проще применить группировку ($1). Пример простой, а вот с заменой немногие, не имея опыта, догадатся сделать так:
# заменим "test" или "bug" на "code" только если впереди стоит фраза
# "this is a " или "that is a "
$s =~ s/(this|that) is a (test|bug)/$1 is a code/;
# или так
$s =~ s/(this is a|that is a) (test|bug)/$1 code/;
# добавим пробелы вокруг text в <любой tag>text</любой tag>
$s =~ s|(<[^>]+>)(.*?)(</[^>]+>)|$1 $2 $3|;
Если человек понимает больше чем час изучения регулярных выражений, во втором примере я ему еще и предложу использовать \1. За "более боевыми" примерами надо лезть в код проектов и находить такие пограниченые варианты, но мне кажется этого итак достаточно, чтобы понять о чем речь. Если кому-то мой вариант менее понятный чем заглядывания - ради бога, я не расстроюсь, что кому-то он не подходит.
Повторю: я дал совет исходя из своего и опыта коллег. Я и они решали практические задачи. Вот эти сотни практических задач подходят под мой принцип. Если у кого-то много регулярок с отрицаниями, которые надо исключить из поиска, тогда прошу прощения, мой совет не для вас. Но, повторюсь, в большинстве случаев он работает и позволяет не отвлекаться на чтение в доках постоянно забываемой фичи и обнаруживания, что у неё есть свой отдельный синтаксис для (не) жадности
Я же написал "почти все случаи". И перед тем как нажать на сабмит, подумал "но все равно отпишется человек, который найдёт контр пример". Очевидно, что раз фича есть, значит скорее всего от неё будет польза. Мой совет основан на опыте. Причём не только личном. Это и личные обращения" помоги составить регулярку, влом доки читать" и код ревью. Я лишь советую как облегчить себе жизнь. 99% практических регулярок оно покрывает
20 лет пишу регулярки (т.к поддерживаю несколько проектов на perl, хотя основной язык python) и могу дать один совет, который облегчит восприятие и логику регулярок: не пользутесь фичами с заглядывания вперед/назад. Да, призыв не использовать функционал звучит странно. Но столько людей спотыкаются в них и регулярно обращаются к документации чтобы освежить в памяти именно этот момент. Чем же их заменить? почти все случаи заменяются на такие приемы: 1) захватить в (блаблаблла) то, что должно присутствовать в тексте и не должно быть изменено, после чего этот же фрагмент вставить в результат как $1 ($2 и тд) 2) использовать [^чего_не_должно_быть] все это читается на раз-два, в отличие от всяких (?<=Y)X
Вы подгоняете результат: отсутствие светофоров — это не просто спонтанная идея взять и убрать. Это целый комплекс работ по проектированию и замедлению трафика — критическое сужение дороги, а в некоторых местах вообще невозможность разминуться не пропустив встречку.
А насчет отнять — сколько раз я отнимал, вроде бы все логично, никому не надо, ничего не ухудшится, а потом бац, у нас проблемы, телефон разрывается. Лучше не удалять того, чего не знаешь. Идеальная симметрия в примерах — это вообще удалить все, до абсолютного нуля. И никаких проблем. Вроде бы…
А пому так плохо?
1) Почему нельзя что-то разрабатывать без монетизации?
2) Почему нельзя делать бесплатные функции платными?
Просто я такой разработчик и хочу понимать, почему я поступаю плохо
Проблема такой технологии в том, что она решает частный случай. И если будет хотя бы 1% реально динамической информации, которую нужно отдавать в реальном времени, то придется параллельно с придуманной технологией использовать классические методы. Зоопарк получится. Т.е идея имеет смысл, но выгода от ее использования сомнительная. Недостаток я озвучил. Но фишка даже не в этом, реально проблемы в текущих технологиях по сути нет. Вот я хожу по сайтам. Скорость меня устаивает. Ну, то есть, если делать сайты/приложения нормально, оптимизировать запросы, кешировать и подобные фишки, все будет ок и без данного велосипеда
Картинка "у нас есть хх стандартов. Надо сделать универсальный. Теперь у нас хх+1 стандартов". Ну, т.е. теперь у нас хх+1 непонятных статей про интеграл.
Как уже сказали, много воды. Я купился, думая, "ну наконец-то теперь-то я пойму этот неприступный интеграл, не смысл, а саму сущность", но мои знания остались на уровне когда я был студентом, шел много км по улице домой и пытался логически сам прийти к выводу. И по-моему даже что-то получилось. И это, естественно, был вариант с площадью
Свой вариант сохранил. Мне были интересны других. В частности, по-моему название было viking. Я не думал, что интернет можно "потереть". Остались только упоминания без исходных кодов
В 200х в определенных кругах было что-то типа соревнования на написание самого маленького резидентного вируса под dos. Там реально годами уменьшали по несколько байт. В начале соревнования было что-то типа 113 байт (точные цифры не помню), под конец 64. Я потратил несколько дней (!) для того чтобы добиться этих самых 64. Это была тяжелейшая головоломка. На всякий случай скажу, что эти вирусы никакой опасности не представляют ибо время доса ушло, это чисто спорт, вирус был фактически на бумаге. К сожалению все исходники этих микро вирусов Гугл потер(
Все знают ответ на эту загадку с детства. Уверен практически никто своей головой до этого не додумается. Можно ради интереса задать кому-то англоязычному
Можно для джунов, не особо знакомых с терминологией, пояснить. Вот я спускаюсь со склона, лыжи под каким-то углом. Я частично срываю снег и слегка перемещаюсь горизонтально. На крутых (для меня) склонах на этот срыв (торможение) тратится столько энергии, что ноги болят аццки. Что я делаю не так?)
Также обратил внимание, что многие летают и вроде как притормаживают, как будто контролируют скорость. Попробовал также и понял что контроль скорости осуществляется тупо за счёт сопротивления воздуха, т.е когда стена воздуха не даёт тебе разогнаться до бесконечности. Это я не считаю контролем.
Короче, если я применяю значительные усилия на срыв снега, то это из-за того что я ламак, а не хиляк?
Автор напоминает чем-то dz - тот долго разрабатывал и толкал свою "вечную ос", не знаю чем все закончилось, но ничего о ней уже давно не слышал.
Офтоповый вопрос: вы стрелочки с Клавы набираете или откуда-то копируете? Когда мне в тексте (программы) нужна стрелочка, я всегда гуглю utf8 arrow. А каменте на хабре написал бы просто ->
Я в 2014м небольшую статейку написал на этот счёт. Будет как дополнение к этой: https://habr.com/ru/post/227021/
Вам надо regexp подучить
Вы забыли добавить, что с "Руссиновичем над одним проектом работали"
Приведу на perl, поскольку (внезапно) на нем лаконичнее. Самое простое, когда необходимо найти фрагмент, перед и/или после которого стоит определенный фрагмент:
Здесь, как я говорил, лучше не использовать сущность "найденный фрагмент" и заглядывания вперед/назад, а проще применить группировку ($1). Пример простой, а вот с заменой немногие, не имея опыта, догадатся сделать так:
Если человек понимает больше чем час изучения регулярных выражений, во втором примере я ему еще и предложу использовать \1. За "более боевыми" примерами надо лезть в код проектов и находить такие пограниченые варианты, но мне кажется этого итак достаточно, чтобы понять о чем речь. Если кому-то мой вариант менее понятный чем заглядывания - ради бога, я не расстроюсь, что кому-то он не подходит.
Хорошо, сегодня буду за компом, напишу. С мобилы не очень удобно регулярки писать
Повторю: я дал совет исходя из своего и опыта коллег. Я и они решали практические задачи. Вот эти сотни практических задач подходят под мой принцип. Если у кого-то много регулярок с отрицаниями, которые надо исключить из поиска, тогда прошу прощения, мой совет не для вас. Но, повторюсь, в большинстве случаев он работает и позволяет не отвлекаться на чтение в доках постоянно забываемой фичи и обнаруживания, что у неё есть свой отдельный синтаксис для (не) жадности
Я же написал "почти все случаи". И перед тем как нажать на сабмит, подумал "но все равно отпишется человек, который найдёт контр пример". Очевидно, что раз фича есть, значит скорее всего от неё будет польза. Мой совет основан на опыте. Причём не только личном. Это и личные обращения" помоги составить регулярку, влом доки читать" и код ревью. Я лишь советую как облегчить себе жизнь. 99% практических регулярок оно покрывает
20 лет пишу регулярки (т.к поддерживаю несколько проектов на perl, хотя основной язык python) и могу дать один совет, который облегчит восприятие и логику регулярок: не пользутесь фичами с заглядывания вперед/назад. Да, призыв не использовать функционал звучит странно. Но столько людей спотыкаются в них и регулярно обращаются к документации чтобы освежить в памяти именно этот момент.
Чем же их заменить? почти все случаи заменяются на такие приемы:
1) захватить в (блаблаблла) то, что должно присутствовать в тексте и не должно быть изменено, после чего этот же фрагмент вставить в результат как $1 ($2 и тд)
2) использовать [^чего_не_должно_быть]
все это читается на раз-два, в отличие от всяких (?<=Y)X
А насчет отнять — сколько раз я отнимал, вроде бы все логично, никому не надо, ничего не ухудшится, а потом бац, у нас проблемы, телефон разрывается. Лучше не удалять того, чего не знаешь. Идеальная симметрия в примерах — это вообще удалить все, до абсолютного нуля. И никаких проблем. Вроде бы…
1) Почему нельзя что-то разрабатывать без монетизации?
2) Почему нельзя делать бесплатные функции платными?
Просто я такой разработчик и хочу понимать, почему я поступаю плохо
Картинка "у нас есть хх стандартов. Надо сделать универсальный. Теперь у нас хх+1 стандартов". Ну, т.е. теперь у нас хх+1 непонятных статей про интеграл.
Как уже сказали, много воды. Я купился, думая, "ну наконец-то теперь-то я пойму этот неприступный интеграл, не смысл, а саму сущность", но мои знания остались на уровне когда я был студентом, шел много км по улице домой и пытался логически сам прийти к выводу. И по-моему даже что-то получилось. И это, естественно, был вариант с площадью