Чего еще хотеть разработчику от ИИ!

Чего еще хотеть разработчику от ИИ!

Космонавтов, ученых, конструкторов, электронщиков, программистов, всех причастных и просто интересующихся — с праздником!

С днем космонавтики, космонавтики!

Будни не очень молодого ацца:
- сегодня моя очередь ехать в офис, ееее
- еду, громко слушаю музыку
- вот он мой офис, мой хорошенький, мой уединенненький, щас я столько всего запилю!
Три чашки кофе спустя:
- смеркается
- что там осталось сделать
- [censored]

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

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

Уже несколько лет услуга выпуска/обновления цифровых подписей — экстерриториальная. То есть ее вам должны оказать на любой планете в любом отделении ИФНС, где её в принципе оказывают.

В общем вынули свои подписи, показали. Процесс обновления занимает минут по 7 на лицо, а если менять молча, то по 3–4 минуты. Но молча менять можно и дома, поэтому инспектор конечно спросил, почему мы не меняем дома.

А я когда последний раз пытался дома сделать подпись, там была инструкция шагов на 20, а в середине программа сообщала, что произошла чудовищная ошибка и нужно все равно обращаться в ИФНС. Может, потому что два года цифровой МВД не может сообщить цифровому ФНС, что у меня адрес поменялся, ОКТМО, и другие страшные слова. А может еще почему. Так или иначе, аналоговый инспектор может всё, поэтому мы к нему и приехали!

У инспектора, впрочем, это игра такая. Он каждый год спрашивает, почему не едем на Походный, мы каждый год отвечаем что неудобно, далеко, и долго. Он каждый год — почему дома не обновляете. Мы каждый год — дома не работает, а к вам съездить быстрее. Да и вообще, вот где он живых людей увидит-то, если все дома свои подписи обновлять будут?

Кроме того, тут и булочная через дорогу. Сплошное счастье и благорастворение. Чего еще хотеть-то?

P.S. Нет, но вы все же прикиньте, до чего дошел бюрократический прогресс в отдельно взятом подмосковном городке. Съездить к инспектору быстрее, чем дома с компьютера сделать!

Сделал Telegram-бота — получил бэкдор и утечку данных в подарок
https://www.securitylab.ru/news/558562.php

Надо бы пых в басике обновить, до 8.2 хотя бы.

Вообще я нормально отношусь ко всем стилям форматирования кода. Кроме тех где открывающая фигурная скобка на отдельной строке - зачем вы так делаете, извращенцы?!

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

Однако если ты работаешь в команде, стиль у всех должен быть один сразу и навсегда. Любой тимлид скажет, как это прикольно - делать ревью на PR, где надо проскроллить сотни закоммиченных изменений отступов чтобы найти значимое изменение. А потом ещё раз, потому что у другого разраба другой стиль.

Это кажется очевидным, но как ни странно, практика показывает, что далеко не все разработчики об этом догадываются.

Хочешь стать, или хотя бы показаться в глазах коллег и руководства толковым специалистом? Вот тебе простой, но очень полезный софт-скилл.

Допустим, тебе дали задачу «с историей». Прочитай эту историю. Всю. От начала и, блин, до конца. А потом уже задавай вопросы. Сразу вырастешь в глазах коллег.

Ну или забей, и немедленно начни спрашивать и комментировать, ничего не читая. Внезапно окажется, что на все твои вопросы и комментарии уже даны ответы, надо только прочитать коммент прямо под твоим. И как только тебе на это укажут, в глазах руководства ты тут же станешь этим, которому надо всё два раза объяснять. Что в плане будущей карьеры конечно же будет тебе мешать. А избавиться от этого будет гораздо сложнее, чем сразу сделать правильно.

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

В поездке удалось испытать приложение Летим - это виртуальная карта в лирах. Можно пополнять по СБП, можно платить по QR, можно снимать деньги в банкоматиках.

Также можно заказать выпуск физической карты, её привезут в отель на месте. Я не стал, показалось излишним, но есть нюанс. Чтобы в банкомате снять денег не втыкая карту - надо сфоткать приложением QR на экране, чтобы оно выписало банкомату волшебного пня. То есть нужно чтобы интернет на телефоне в этот момент работал.

В целом полезная штука, чтобы не возить с собой кэш, для всех кто наслаждается санкциями. Оплачивать с неё тоже можно по QR, там где он на терминале есть.

Комиссию за сервис берут при пополнении и при снятии наличных. За оплату QRом - не берут. Размеры не изучал, вроде немного, но в любом случае её видно сразу, до операции.

А вот дома как международной картой для покупки всяких сервисов ей видимо не воспользоваться: платёжная система Troy как я понял годится только в Турции.

Все, пора домой, дальше будем про работу)

ИИ-мемы которые мы заслужили

Когда мы пишеем тесты на бэкенд-путь, который возвращает данные с отношениями, ($order, в нём $order→user, в нём $order→user→plan и т.д.) — следует избегать проверять отсутсвие тех или иных id через assertJsonMissing(['id' => $order2->id]) и ему подобные методы. Когда тестов окажется много, и мы их запустим разом, инкремент-айдишники в таблицах побегут и в какой-то момент внутри $order, который в json есть, внезапно окажется $user у которого id такой же как у $order2, и тест не пройдет.

Имеется в виду запуск всего пакета тестов, например, в Laravel с включенным трейтом RefreshDatabase: таблицы БД после каждого теста чистятся, но структура заново не пересоздается. Это и быстрее, и более похоже на «живую» среду.

И мы будем голову ломать, почему вдруг этот тест сломался на ровном месте и почему это проявляется, только если сразу все тесты запустить. И ладно мы, мы-то быстро найдем почему. А вот если мы работаем с ИИ, он половину рабочего кода искромсает своми правками, пока допрёт, что это было. Если допрёт вообще — мой вот не допёр.

В общем, проверять json ответа без декодирования в массивы/объекты не очень хорошо, т.к. может повлечь подобные ложные мэтчи.

Правильнее либо декодировать json в массив и сделать assert по
конкретной структуре, либо использовать замыкания в assertJson(), которые также позволяют проверять указанный уровень структуры документа.

Из примера в предыдущем посте может показаться, что подобные совпадения редки, но это совершенно не так. При достаточно большом количестве тестов они могут встречаться регулярно. Причем это количество — не такое уж и большое на самом деле. У меня например два ложных срабатывания произошли уже на таких числах: 558 tests, 2110 assertions.

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

Этот парадокс относится к «веридическим» (или по-нашему истинным) парадоксам — утверждениям, которые интуитивно кажутся людям парадоксальными, но на деле оказываюстя верными (то есть по сути парадоксами не являются). К таким парадоксам относится например известнейший парадокс Монти Холла про автомобиль за одной из трех дверей.

Если про дни рождения не слышали, то вкратце:

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

Сам по себе этот «парадокс» практической ценности для нас не имеет, однако есть часто встречающаяся проблема аналогичного свойства, у которой вероятность случайного мэтча выше, чем мы думаем. И о которой разработчики порой забывают. Это, конечно, хэши.

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

Но есть и более продвинутые решения, например библиотека Hashids, генерирующая уникальные хэши. Сейчас ее зачем-то переименовали в Squids , хотя hashids звучит значительно веселее. Рекомендую ознакомитсья, пользоваться, и генерируя хэши не забывать — случайности не случайны!