Стой под стрелой

2022-05-30 16:26:21 Обожаю переписывать код. Многие системы развиваются дописыванием — рядом со старым пишется новое. А я люблю наоборот, старое грохнуть и сделать на его месте новое. Раза с третьего где-то уже более-менее нормально получается.

А у вас как? Открыть/Комментировать

2022-05-27 14:38:00 Напоминаю вам, что если вы не знаете, как расшифровывается

XSS, CORS, CSP, CPS, CSS, SVG, GIF, JPG, JPEG, PNG, APNG, BMP, MIDI, HTML, DHTML, SGML, RTF, RDF, ODF, PDF, OWL, JSON, JSONP, JSONB, RSS, MAML, XAML, YAML, VML, XSL, XSLT, XHR, PHP, APL, ML, ML, WHATWG, W3C, IEC, ISO, OSI, OIS, IOS, OASIS, WS-I, TCP, UDP, IP, HTTP, IMAP, SSH, SCP, FTP, SFTP, DHCP, LDAP, MQTT, NTP, POP, RTSP, SIP, SMTP, TLS, SSL, DSA, RSA, ECDSA, XMPP, SCTP, ICMP, PPP, MPLS, LSP, ID, CPP, BSD, GNU, GPL, LGPL, AFL, APSL, CDDL, EPL, MIT, MPL, WTFPL, OSS, FOSS, FLOSS, PDP, SVR, OSF, CSRG, QNX, AIX, POSIX, SFU, WSL, WSLG, NT, CD, VM, VMS, IPC, CPU, RAM, DMA, RDMA, UDMA, CPP, UB, USB, API, DSL, MBR, CLI, GUI, GUID, UEFI, APM, WOL, SDI, RPC, RFC, I/O, PIO, SoC, SSE, ALU, GPU, MMU, MP, MPI, AMP, SISD, MISD, SIMD, MIMD, SPMD, MPMD, SIMT, SMP, UMA, NUMA, COMA, CORBA, CUDA, GCC, LLVM, GPG, PGP, GPGPU, CRDT, LWW, I2P, P2P, VPN, IPFS, APFS, BFS, FAT, HFS, LFS, NTFS, ZFS, NAS, FUSE, SMB, SSHFS, DHT, LSMT, DAG, DNA, DAO, DOM, SOAP, ICO, NFT, SQL, NoSQL, NewSQL, DDL, DML, DFDL, OQL, CQL, SPARQL, LINQ, ACID, SOLID, CAP, CRUD, JDBC, ODBC, J2EE, JSR, JSP, JSF, EJB, JTA, JPA, PIP, CGI, SSI, FCGI, MSE, SSE, IDL, DI, EAP, GA

то вы ненастоящий программист. Идите доучивайтесь!

UPD: Подписчики добавили

RTFM, OMFG, HATEOAS, WYSIWYG, DDOS, MITM, DNS, LAMP, PKI, GOF, DDD, TDD, BDD, DOD, RTCP, RTC, NvME, KISS, DRY, YAGNI, AJAX, NLP, OLE, OLAP, OLTP, SFINAE, FIFO, LIFO, DBMS, RDBMS, JVM, JRE, JDK, REST, AWS, IAM, EC2, RDS, EBS, SQS, I18N, L10N, A11Y, K8S, MVCC, MVC, MVVM, OOP, FP

которые, конечно, тоже стыдно не знать! Открыть/Комментировать

2022-05-26 13:37:29 Вот программисты любят говорить «требования». Реализую требования, спустили требования, код соответствует требованиям.

Причем это звучит так, как будто требования это закон природы, или слово божье, или обстоятельства непреодолимой силы. «Я написал этот код, потому что так было в требованиях» с той же интонацией, что и «я переехал, потому что мой город смыло цунами».

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

Даже если требования это какой-то стандарт, то всегда есть еще решение соответствовать стандарту или нет, расширить его или реализовать неполностью, или вообще договориться о другом стандарте.

Короче, требования — это часть решения, а не часть проблемы. Думать своей головой и договариваться надо, а оправдывать плохо сделанную работу требованиями — нет. Открыть/Комментировать

2022-05-25 15:04:32 Давайте регэкспам научу за один пост?

Регэксп описывает шаблон, который вы хотите найти внутри строки.

Самый простой — буквальный. Что написано, то и ищем:


/abcd/ => "abcd", все остальное


Какой-то символ может повторяться. Если сколько угодно раз (1 или больше), то плюсик:


/a+/ => "a", "aa", "aaa"


Если сколько угодно раз или ни разу (0 или больше), то звездочка:


/a*/ => "", "a", "aa", "aaa"


Если один раз или ни разу, то вопрос:


/a?/ => "", "a", "aa", "aaa", "aaaaaaa"


Все три применяются только к символу, который идет непосредственно перед:


/https?/ => "http", "https", "htt", ""


Теперь про сами символы. На одной букве далеко не уедешь, поэтому есть выбор. [abc] значит любой из a, b или c:


/[abc]/ => "a", "b", "c", "d"


Внутри квадратных скобок можно писать диапазоны:


/[a-z]+/ => "abc", "123", "ab12"
/[0-9]+/ => "123", "abc", "ab12"


Но в эпоху юникода использовать a-z не рекомендуется. Вместо этого есть Юникодный класс “Letter”:


/\p{L}+/ => "abc", "абв", "åbč", "1234"


У квадратных скобок есть еще одна особенность: можно сказать отрицание, то есть «что угодно кроме перечисленного»:


/[^a-z]+/ => "123", "абв", "a", "abc"


Полезно, например, чтобы делить строку по разделителю. Можно написать «что угодно кроме двоеточия ноль или более раз»:


/[^:]*/ => "", "123", "абв", "a:b", ":"


Еще один важный класс: пробел. \s включает все возможные варианты пробелов (неразрывные, em/em spaces, табы и т.п.):


/\s*/ => "", " ", " ", "abc"


\s* часто используется при парсинге «человекочитаемых форматов», т.к. люди любят пробельчиками отбивать все, или делать вид, что их не видят.

Точка. Точка значит «что угодно вообще»:


/.*/ => "", "123", "абв"


Крышечка и доллар — начало и конец строки. Обычно регрексп будет искать вам ПОДстроку. Чтобы проверить всю строку целиком, заверните ее:


/^[a-z]+$/ => "abcd", "abcd1"


Наконец, «или». Когда нужно выбрать из нескольких сильно разных вариантов — скобки и пайп:


/(http|ssh)/ => "http", "ssh", "htsh"


По использованию. В простейшей версии регэкспом вы просто проверяете, есть ли внутри строки подстрока, соответствующая шаблону:


/[a-z]+/.test("1abc2") => true
/[a-z]+/.test("123") => false


Но иногда строку хочется распарсить. Для этого интересующие вас части заверните в круглые скобки:


"__abc123__".match(/([a-z]+)([0-9]+)/) => ["abc123", "abc", "123"]


Штуки в скобках называются «capturing groups». match вернет вам сматчившуюся подстроку целиком плюс значения всех capturing groups.

Тут проблема, потому что скобки могут быть чисто техническими и использоваться просто для группировки. В этом случае пишут (?:), «non-capturing group». По сути те же скобки, но в результат match-а они не попадут.


"__abc123__".match(/(?:a|b|c)+([0-9]+)/) => ["abc123", "123"]


Теперь про недостатки. Самое неудобное — что каждый символ внутри значимый. То есть нельзя разбить регэксп для удобства чтения. Если вставите где-то лишний пробел, регэксп будет искать его в строке:


/( abc | def )/ => "abc", "def", " abc ", " def "


Второе — многие нормальные символы имеют специальное значение и их нужно эскейпить. Это очень трудно читать:


/(\(|\))/ => "(", ")"


Особенно легко попасть на точке:


/.*.jpg/ => "abcjpg"
/.*\.jpg/ => "abcjpg"


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

Поэтому простых регэкспов не бойтесь — их читать как раз несложно. Сложные иногда можно потерпеть ради компактной записи и перформанса.

Факультативно почитайте про lookahead/lookbehing, quantifier, named groups, greedy/lazy, флаги ignore case, unicode, multiline.

Как-то так. Открыть/Комментировать

2022-05-24 15:53:52 Если вам нужна хорошая метафора веб-разработки, то некто leoeelias в твиттере нашел, что чтобы провалидировать email, можно создать невидимый DOM-элемент input type=email, вставить в него значение и позвать checkValidity().

Мало того что это как вызвать бульдозер, чтобы разгладить складку на брюках, так потом еще и выяснилось, что эта самая валидация проверяет наличие символа @ в строке и всё. Как всегда, хочешь сделать хорошо — доверься веб-стандартам ¹ ²

¹ Кроме мобильного Сафари
² Сарказм Открыть/Комментировать

2022-05-23 15:09:26 Больше всего меня бесят непрозрачные АПИ. Возился в пятницу с Файрбейзом, и у них чтобы авторизоваться, нужен обязательно их клиент, которому нужно подложить какой-то json-файл с креденшлами, который нужно где-то еще сгенерить. Гуд лак сделать запрос из скрипта на CI.

Придется расчехлять программирование, причем на одном из языков, которые мне не нравятся, но которые соизволил выбрать за тебя гугл. Открытая, понимаешь, экосистема. Не надо так.

Вторая странность это сам файл с креденшлами. Нормальные люди делают как? Нажал в интерфейсе где-то кнопку, тебе сгенерили ключ символов на 100, ты его скопировал и всю жизнь пользуешься.

А у Гугла как? Скачиваешь JSON-файл. Запускаешь гугл-клиента. Он делает за тебя запрос. Получаешь короткоживущий ключ. И вот им уже можно пользоваться (недолго). А файл таскай с собой.

Зачем? Почему? Концепция короткоживущих временных ключей мне как-то слабо понятна, если честно. На клиенте еще можно как-то объяснить тем, что мол враждебная среда, чужой код вокруг, тыры-пыры, но на сервере-то зачем?

Json-файл тоже смешной, например, там внутри куча полных URL-ссылок на гугл же. Видимо это какой-то «самоописывающий» формат, я помню была мода на такие. Типа, делаешь запрос, а тебе в ответе ссылка «на следующие десять записей» полным урлом, с доменом и всей байдой.

Какая-то на редкость бесполезная фигня, как по мне. Тебе все равно надо уметь делать запрос на любую страницу в любой момент, так что ты все это и так и так уже захардкодил, и в ответе тебе просто придет то, что ты и так уже знаешь. Плюс дублирование, скажем, в документации написано делать example.com/page10, а в ответе приходит www.example.com/page-10. И что, кому верить?

Не делайте так, короче. Делайте REST API, которые не требуют клиента, и простые вечноживущие ключи, которые можно послать в header. Открыть/Комментировать

2022-05-23 00:59:58 Посмотрел несколько часов суда Джонни Деппа и Амбер Херд. Раньше мое представление о судебной системе США ограничивалось фильмами про адвокатов. Ну там знаете, Вердикт, 12 разгневанных мужчин, Сбежавшее жюри, Филадельфия, Адвокад дьявола, Блондинка в законе, Голиаф, Чикагская семерка. А тут — видеозапись, как оно на самом деле.

Ну и конечно, первое, что бросается в глаза — там никому особо не интересно, что произошло на самом деле, а интересно провести допрос так, чтобы показалось (именно показалось), что он больше перевешивает в твою сторону, независимо от того, что было на самом деле сказано.

Но весь кайф в конкретике. Например, юрист может показать чью-то запись/документ и попросить автора ее прочитать. Автор может начать пытаться объяснять, что же он имел в виду (свои же слова!), или дать контекст, но ему не дают. И вообще говорить и что-то уточнять не приветствуется. Прям могут сказать: пожалуйста, не уточняйте. Почему что-то неидеально сформулированное в один момент в прошлом имеет какие-то преимущества перед более взвешенным взглядом _того же самого человека_ из сегодня, непоятно.

Еще более странно — нельзя пересказывать слова других людей. Можно говорить где ты их видел, что происходило, что они сделали, но что они сказали — нельзя. То есть речь считается каким-то странным действием, неэквивалентным другим действиям. Понятно, что все действия пересказываются с пометкой «по моему мнению», но вот именно речь так почему-то нельзя.

Ну и самое странное — наводящие вопросы. Точнее, я даже не знаю, как это назвать. Вопросы, которые выглядят примерно так (Деппу): «Перед вами газетный заголовок “У Джонни Деппа проблемы с выпивкой”. Я правильно его прочитал?». «Да». «Отлично, следующий вопрос». То есть вопрос в том, правильно ли он прочитал, а что по сути заголовка — отвечать нельзя. И не не хочется, а именно нельзя!

Вот что это было вообще? Какие выводы надо из этого сделать? При всей юркости адвокатов (а они очень, очень не стесняются возражать — objection — по любому поводу) именно этот паттерн почему-то никто не пресекает.

Открытые вопросы бывают, но их как будто меньшинство. Я так понимаю «своя» сторона может этим рискнуть, а оппоненты стараются максимально конкретный и наводящий вопрос задать, типа, когда вы перестали пить коньяк по утрам. При этом «нет» как будто никого не смущает. Не угадал? Пофиг, погнали дальше. Предполагается, что эти вопросы как-то замарают обвиняемого/обвинителя независимо от ответа, или что?

Там есть мужик, которого заставляют пяток заголовков прочитать, не им написанных, просто, вот мол была такая газета, спрашивают: видели? Он на каждый говорит: нет, не видел. И после пяти таких отказов адвокат как ни в чем ни бывало: вот этот кризис в карьере Деппа, о котором вы тут говорите... И опять же — нельзя сказать «я ничего такого не говорил, это вы придумали», потому что надо отвечать на вопрос, а не рассказывать, что ты думаешь или что видел. А вопрос такой тебе, конечно, не зададут, если это невыгодно.

При этом непонятно кем написанные газеты вполне себе цитируются без возражений, а эксперту, сидящему прямо тут прямо в зале, можно легко заткнуть рот. Потому что не документ.

Да, юристы и в культуре обычно рисуются скользкими и аморальными типами, но я не представлял, насколько эти манипуляции плохо спрятаны и очевидны в жизни. Про суды у меня была иллюзия какой-то осмысленности происходящего, но на деле кажется это что-то кафкианское и бессмысленное.

В любом случае было очень любопытно взглянуть на конкретные примеры. Что они там с такими подходами насудят, конечно, вопрос, но, в общем-то понятно, почему в суд никто идти не хочет даже с очень хорошим кейсом. Результат может вполне оказаться рандомом и зависеть, например, от красноречия или плохо сформулированного ответа.

P.S. Для проигрывания видео используется обычный виндовый VLC :) А еще в какой-то момент все ждут пару минут, пока загрузится винда. Не боги горшки обжигают Открыть/Комментировать

2022-05-20 16:14:50 Хакер ньюз, как и Хабр, конечно уникальный сайт. Где еще выпадет возможность заглянуть в разум «среднего айтишника»? Почувствовать настроения эпохи?

Мои статьи периодически попадают туда, и, в целом, обсуждаются с неплохим коэффициентом полезности.

Но иногда они попадают туда второй, третий раз или просто спустя какое-то время. И вот тут меня больше всего веселит, как люди обсуждают-обсуждают содержание, а потом комментов через тридцать кто-то вдруг находит дату публикации и врывается в дискуссию:

2019! 2019, ребят!

Типа, вы чего? Этому посту уже три года! Он воняет! Не тратьте свое время, мол, эти идеи давно протухли! Человек из 2019-го уж явно не мог ничего дельного сказать! Да какой человек, дед! Натурально, дед уже, если в 2019 уже писать умел! Как он вообще в 2019-м это опубликовал? Через факс? На пергаменте? Пером?

Не, ну правда, где еще можно так полно погрузиться в разум «среднего айтишника»? Взглянуть, чем он живет, какими идеалами, какими переживаниями?

Не то что комментарии в этом паблике. Комментарии тут — самые лучшие, а комментаторы — далеко впереди «среднего айтишника». Ну, как по мне. Люблю вас! Открыть/Комментировать

2022-05-19 17:15:35 На Leetcode задача 65. Valid Number — провалидировать строковое представление числа с плавающей точкой.

Во-первых, она там идет под сложностью Hard (почему? Наверное, для тех, кто не знает регэкспов), а во-вторых, поразительно мало решений на regexp-ах (ладно-ладно, не буду эту тему поднимать сегодня, вы еще молодые).

Но мое внимание привлекло четвертое по популярности решение, озаглавленное «A clean design solution By using design pattern».

Автор пишет:

> The point here is not how you design a algorithm, it is how you handle all cases well. There is no a clear standard for whether is a number valid, is it .50 , 39. a legal float point number? Are there only valid formats given by the example? Is hex format such as 0x12ab legal?

Условие максимально четкое. Все случаи перечислены. Ничего сверх решать не требуется.

> How about if we need to add another format such as roman number like "I, II , IV" as legal format.

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

> I found all solution are just plug logic into one function, there are lots of switch case, if else in there. It is problematic, easy for bugs, difficult to add new features, and of course, in-reusable, and here I propose a design to handle this problem easily and nicely.

Опять же, решение в одной функции приводится как недостаток. С чем я решительно несогласен! Одну функцию как раз легче всего читать и модифицировать, потому что все что тебе нужно на одном экране, контракт ограничен передаваемыми аргументами, а внтури полная свобода реализации.

Дальше он предлагает создать interface NumberValidate, реализовать IntegeValidator, FloatValidator, ScienceValidator, использовать «chain of responsibility design patter (from book of GOF)»

Следуя словам автора, это упростит исправление ошибок, потому что каждая проблема будет в одном из трех валидаторов и называет это «encapsulation» (???). Типа, если несешь ахинею, то хоть какая-то внутренняя логика в ней должна быть? В одной функции наверное проще что-то искать, чем в трех классах?

Дальше он говорит, что это «close for modification open for extension», потому что всегда можно добавить новый валидатор. Вот этого я тоже не понимал никогда, а почему в исходную функцию-то нельзя добавить? Какая разница, класс писать или функцию менять?

Все это кульминирует в трехсотстрочной реализации. Для сравнения соседи, которые FSM вручную реализуют, укладывются в 30 с небольшим строчек. В ДЕСЯТЬ РАЗ МЕНЬШЕ!

Ну а решение на регэкспе так вообще одна строчка (ну ладно, две, одна еще на `import re`). В 150 раз меньше!

Короче, главное, что нужно про код понимать: чем его меньше, тем лучше. Количество багов, легкость чтения, отладки, изменения — все это пропорционально количеству кода тоже. Количество кода приоритетнее, чем любые архитектурные изыски, точки расширения, «красота». Если что-то можно написать в одну строчку вместо тридцати — надо писать в одну строчку. Вам и компьютер, и коллеги спасибо скажут.

Ну а второе — не надо планировать наперед. Придет время — перепишете, тоже мне проблема. Новички пытаются думать на расширение, потому что, мне кажется, боятся менять уже существующий код. Ну, 300 строк ООП со случайно торчащими и непонятно кем используемыми методами я бы тоже боялся. Но вообще удалять и переписывать — это нормально и даже хорошо. «Когда меняется ситуация, я меняю свое мнение».

В общем-то я и внимания бы не обратил, если бы не нашел решение в папке Most voted. Чему молодежь учится! Будьте осторожны, не слушайте дядю Боба и его последователей.

А, ну и учите регэкспы Открыть/Комментировать

2022-05-18 14:50:51 Самая бесполезная фича редакторов — автозакрывание скобок. Это когда ты нажимаешь на клавиатуре [, а услужливый редактор сам за тебя добавляет еще и ]. Нажал одну кнопку, получил две. Ух как бесит. Отключаю первым же делом всегда и везде.

Почему? Если очень поверхносто про это подумать, то кажется как будто логично. Более-менее во всех языках программирования скобки в конечном итоге должны быть сбалансированы: каждой открывающей должна соответствовать такая же закрывающая. Ну и кажется, что если закрывающую скобку тебе рано или поздно все равно ставить, чего бы не помочь тебе сразу?

Но если подумать чуть глубже, получается ерунда. Во-первых, конечно же, есть миллион ситуаций, когда скобки не балансируются. Например :). Или (str "[" xxx "]"). Или """. Или \(. В наспех сделаных редакторах такие ситуации еще и ломают подсветку синтаксиса, кстати.

А во-вторых, и это более фундаментальная проблема, скобки добавляются автоматически, но удалять их нужно вручную. А с кодом же какая проблема? Никто не может сразу написать его правильно. К конечной записи приходишь после нескольких попыток редактирования, в которых скобки и уровни вложенности добавляются, удаляются, меняются местами. И вот тут-то автодобавленные скобки не в тему начинают путаться под ногами.

Ну и наконец третья проблема, более системная. Настроили вы редактор, чтобы он добавлял вам скобки. А потом пошли в браузер-твиттер-почту что-то писать, а там скобки не добавляются. И чего? Приходится переучиваться, держать в голове два режима и владеть обоими. Проблема таких специфичных режимов редактирования в том, что они работают только в одной специальной программе, а текст надо набирать много где. По этой же причине я когда-то ушел с Вима: да, можно неплохо надрочиться писать код в нем, но безумно при этом бесит, что больше нигде после этого ты писать не можешь.

В комментарии обязательно придут фанатики paredit-а, этот абзац про них. Да, есть paredit, я знаю. Нет, не пользуюсь. Смотри выше. Открыть/Комментировать