Подробнее
it-юмор,geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор,переписка,выдуманные переписки,bash.org.ru
Еще на тему
it-юмор geek переписка выдуманные переписки bash.org.ru 
Подробнее
it-юмор,geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор,переписка,выдуманные переписки,bash.org.ru
Подробнее
it-юмор,geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор,переписка,выдуманные переписки,bash.org.ru
Стал сидхом.
Билет продался? Продался. Какие вопросьі?
Неправильно продался.
Это нюансы.
От этих нюансов зависит уходит твоё очко в зрительный зал, или останется при тебе
Когда неправильно покупаешь - продаётся, соответственно, неправильно. Виноват покупатель. Пусть обратится с паспортом в мфц, подаст заявку на рассмотрение, подождёт неделю, получит отказ ввиду неверного заполнения заявления, потом снова подаст, снова в мфц. Короче, через годик - другой оформить возврат.
продался правильно. билет оказался у покупателя.
неправильно выдалась дата - даты никто не тестировал, это не ко мне.
Звучит не очень правдоподобно, но за такое не только тестировщика, но и разраба и аналитика надо нагреть
Зато на либе с датапикером сєкономили)
Юзеру нельзя доверять, валидация на стороне апи обязательна.
Да норм, в базе сохраняется как String.
Валидация строки на не пустую и не null прошла успешно.
Смех смехом, но в SharePoint 2013 в виде строки сохраняется дата последнего обслуживания базы данных (RBS). Формат что-то вроде "15 Jun 2024". По этой причине, если снять бекап базы с англоязычной MS SQL и восстановить на русскоязычной MS SQL, то ничего не будет работать до тех пор, пока руками не поправишь строку на "15 Янв 2024". Enterprise он такой, да.
А если ещё и забраться в дебри локалей...
То работать будет, но не правильно.
да, кстати, я тоже, помню ахуел от мелкософтовских решений в 2005 году, по моему.. бля, забыл как продукт назывался, но помню, что когда увидел, как специальный чел ищет в базе какие-то хэш ключи и правит их вручную, чтобы стстема работала корректно. что такое внешние ключи и ссылочная целостность, да и вообще, нормализация и принципы проектирования в мелкософте никогда не знали.
это бвл какой-то продукт связанный с документооборотом и xmlформами..память не та уже
а АНАЛитика за шо
Что в итоге задача прилетела в таком виде что стало возможно такую дату делать. Плюс тест кейсы сам аналитик не делает но их по описанию задачи формируют
Так там наверняка было написано "поле с датой" или типа того. Это разработчик тупанул.
Не может в задаче о заказе билетов быть просто "поля с датой". Билеты на что угодно существуют только на определенные даты, и это абсолютно обязательно должно быть прописано в задаче.
Вывод: аналитика на мороз, если просто "поле с датой". Он нихуя не анализирует и задачу сам не понимает.
Вывод: аналитика на мороз, если просто "поле с датой". Он нихуя не анализирует и задачу сам не понимает.
Если на каждый элемент интерфейса писать все граничные случаи, то это займет кучу времени
А если не писать, то получается какая-то хуйня вместо продукта.
Я уже не говорю, что дата это не просто элемент интерфейса, при заказе билетов при изменении даты тебе надо всё с сервера переподтягивать, на ней куча валидаций и прочей хуеты.
так тестировщик должен был доложить если что-то не так.
вот и получается - либо хуёвщик-тестировщик не тестил и не доложил, либо проблема плавающая на некоторые даты (типо высокосного года, когда дней не 365 а 366)
вот и получается - либо хуёвщик-тестировщик не тестил и не доложил, либо проблема плавающая на некоторые даты (типо высокосного года, когда дней не 365 а 366)
либо шарашкина контора в которой нет тестировщика и всё за собой тестит девелопер.
ничем другим я не могу в принципе объяснить вопрос "тестировал ли ты Н?". только шарашкиной конторой.
ничем другим я не могу в принципе объяснить вопрос "тестировал ли ты Н?". только шарашкиной конторой.
Иногда хеппи-паса достаточно. Иногда фронтовой валидации. А иногда надо так заєбаться с часовьіми поясами, високосньми годами, проверить все преобразования и т. д., что жить неохота :D
Тут же видимо, юзер никуда ехать не желал, или накодили какое то говно.
Абсолютно не выдуманные диалоги, о которых невозможно молчать
у них всех даже стилистика одинаковая!
сидит же ж где-то мудак, рисует, старается...
сидит же ж где-то мудак, рисует, старается...
Зачем рисовать, если есть онлайн-генераторы.
Вот потому и мудак, что работает по устаревшим технологиям
И не работаю
- Владислав, ты тестировал генератор it-мемов
- Да
- Клиент сейчас сгенерировал мем про покупку билетов онлайн. Либо ты сейчас скажешь ему, что это прохладная история, либо переводим тебя на должность бояниста.
Я даже не стараюсь
пост реально выглядит пиздабольски, но у нас в прошлом году было несколько раз:
- а вы это тестировали/тестируете?
- Да.
- А почему эти кейсы не тестируете и мы узнали от третьих лиц о проблеме?
В ответ либо молчание либо оказывается что в тесткейсах нет этого. И функционал разный, от не часто используемого до достаточно критического.
В итоге мы в один момент сели тимой девов и разбирались чего не хватает в кейсах. Тот еще, неприятный опыт был.
Хз, у нас каждую пятницу такое обсуждение. И, учитывая размер проекта, это уже стало будничной процедурой. Послушали, прониклись, завели таски, зафиксили, прогнали тесты, закрыли.
ну у нас немного другое флоу, но обсуждения есть. Дополнительно тест кейсы(те что как девы придумали) мы описываем после имплеменатции новых фич или если что-то кардинально фиксится.
наверное потому что жопы в креслах, которые сидят и надувают щеки про цифровизацию, не в курсе что сколько систему не тестируй, она все равно ломается непредсказуемым образом и что то, что они подразумевают под тестированием - это совсем не то тестирование, которео делается и что тесты в принципе не гарантируют работоспособность - они гарантируют только то, что известные проблемы были изучены программистами и не будут повторяться... и то не гарантируют, потому что многие тесты вообще ничего не тестируют на самом деле, а просто процессорное время гоняют
Интересно, а куда подевались все адепты автотестов, которые несколько лет назад бегали толпами, и втирали, как TDD решит все проблемы ошибок в ПО? У них проекты наконец дожили до прода и начались реальные баги, а не ими самими придуманные и покрытые тестами? Или что с ними? Я волнуюсь, давно не видел, хотя раньше их активность прям заполоняющая была.
TDD спрашивают на hh.ru, но не очень часто, потмоу что, на самом деле, этому очень сложно следовать
Я вроде году в 15 или 16 по собеседам бегал, так вот тогда хипсторы в каждой первой галере показно удивлялись "каак, вы не используете новое пиздатое ТДД?". Впрочем, исключительно на галерах, продуктовики слабее подвержены массовому помешательству.
Не то, чтобы я против, автотесты это инструмент, просто отмечаю пропажу тех, кто его проповедовал как религию.
Не то, чтобы я против, автотесты это инструмент, просто отмечаю пропажу тех, кто его проповедовал как религию.
сейчас эпоха микросервисов и поэтому фокус тестирования смещен на интеграции, где а). никакого ТДД в принципе быть не может, б). тестировать интеграции никто толком не умеет
Ты еще бы адептов парного программирования вспомнил )
Кстати я стал писать больше юнит тестов после того, как купил copilot )
Ой, ну один был ничего так. Я не уверен, что то, чем мы занимались, было всегда программированием, но пара из него была отличная.
Их стало существенно меньше, но еще есть упоротые, у нас один такой работает. В основном работает отлично но время от времени с ним бодаемся (он напрямую к нашей тиме не относится), когда находит по его мнению баг, а это не баг или перепедалит архитектуру тестов, а потом у него не работает и виновато приложение которое особо не менялось с тех времен...
На прошлой работе тоже был один упоротый автотестер но его быстро турнули и наняли более адекватного.
Но по отзывам куа, автотесты таки сильно экономят время, но это таки не замена человеку
Так я именно про упоротых. Автотесты полезны как инструмент, но при упарывании ими начинается пиздец.
Обычо чего-то нет в кейсах потому что или к тестировщикам относятся как к объезьянкам, которые только кликать могут или от того, что просто времени не дают даже подумать нормально, не то, чтобы подогнать куашный "технический долг" по апдейтам онбоардинга и существующих тестов для регрессии.
Ещё есть шанс, что все заебались и знают, что всё равно фиксить будут только те баги, которые уже клиенты принесли.
ну у наших есть время (кроме как перед релизом, там да, жопы горят) и вроде как по флоу должны новые кейсы заносить в свой список и тестить, но увы и ах. Но вроде исправились
Классика покойного Баш.Орг
Прям bashем повеяло.
http://ibash.org.ru/quote.php?id=15674
13 лет офигеть
Чот какая-то пиздаболия.
Но если представить, что это так, то у меня вопросы не только к тестировщику:
1) сэкономили на архитектуре - какого хуя у них нет стандартного типа "дата" который изначально не примет такой хуйни?
2) сэкономили на бекенде - какого хуя нет валидации входных значений, даже если значения были бы строго-типизированные?
3) сэкономили на фронтэнде - какого хуя пользователь может не выбрать из существующего перечня билетов, которые заведомо есть, а вбить произвольные данные?
С учётом этого всего, у меня есть неплохое такое подозрение, что там надо выкинуть всё и написать заново, потому что это будет тупо быстрее, чем даже делать ревью всего, что уже написано, чтобы понять как заткнуть дыры, которые возникают из-за отсутствия типизации, отсутствия валидации и допустимости свободного ввода данных.
Тот, кто писал на эту систему ТЗ - идиот.
Тот, кто принимал эту систему - клинический идиот.
Всё, разговор с выдуманной перепиской закончил)
Или 4) фронтэндщик перестарался и вместо валидации начал исправлять неправильные значения. Тогда на бекэнд ушла какая-то реальная дата, на которую билет и продали.
5) Пришло по API, а его не тестировали
6) Сломало нормальную дату при миграции на новую версию
7) Из того, что там 3 непонятных числа, возможно переполнение, когда мамкин нахер решил побаловаться с чем-то типа 12024 года.
и т.д.
Меня здесь смущает, что клиент именно *купил* билет. То есть, наличие билета проверили и запись о покупке внесли в базу. Поэтому и думаю, что какое-то автоисправление даты или обработка исключений по принципу "при ошибке даты берём текущую".
(Впрочем, чужая голова -- потёмки...)
- Билет просрочен на 2816 лет. В связи с этим деньги вернуть не можем. Всего Вам доброго!
Вот тож хотел отметить. Билет продали? - Продали!
Деньги получили? - Получили!
Вот пусть умник и летит/выезжает в указанную дату прямиком нахуй!
Давным давно разрабатывали систему продажи билетов в кинотеатр. В общем использовали
какую-то библиотеку, для генерации id сессии(sid) при входе пользователя, и вроде все было хорошо и на тестовом и на проде. Но в какой-то момент, она стала генерить один и тот же sid всегда, и пользователи стали заходить под аккаунтами друг друга. В итоге все закончилось благополучно, все попали в кино, кто-то сходил на халяву :)) Но вспотел я в ту субботу неплохо, пытаясь понять, а че блять происходит .
Вот поэтому во многих конторах есть политика, которая обязывает доказвть целесообразность включения любой сторонней либы в проект. Чтобы не получалось, что для элементарного функционала, который пишется меньше чем за день, вешать на себя навсегда якорь чужого кодв, чужих багов, сайд эффектов, дополнительную боль в управлении зависимостями, и адскую боль в деплое/смене энвайнронмента/переезде вверх по версиям чего угодно.
Кстати, если ты не против, я утащу себе этот пример. Он прям ахуенный. Вместо функции на несколько строк(рандом и мапа активных сессий для избегания повтора), сторонняя либа - это прям шикарно.
и наступили на другие грабли, которые автором либы уже были учтены
Или не были. Или то, что автору либы грабли, тебе - благо, зато то, что ему фича, тебе кость в горле. Но ты это можешь узнать не сразу.
Свой код хорош полным контролем над ним, и в случае выяснения проблемы с ним, фикс быстрый и лёгкий. В отличие от либ.
Мейтенанс либ это дорого, хотя кажется, что добавить её просто, и это круто.
Я уже молчу про производительность, на неё забивают большинство, и потому половина интернета работает так, как будто запущена на чём-нибудь из 70-х годов, а не на сервере с гигагерцами.
ну так и свой код поддерживать дорого. хотя бы все должны знать, что он в принципе есть - онбординг проводить надо, доки писать, в актуальном состоянии их держать, примерчики-хуерчики. и если свой код сложен, то возни с ним не меньше, чем со сторонней либой. и версионирование тоже будет.
но не будет проверки этого кода кучей стороннего народу. и нельзя джуна прост послать на ютубе глянуть, как этим пользоваться
Ну, если у вас в конторе на "стороннюю проверку" возлагаются бОльшие надежды, чем на квалификацию собственных программистов, то... Да, наверное, вам лучше либы.
ну не абы какие либы. я на жабе пишу, тут либы от всяких гуглов, ораклов, микрософтов, редхат - такие я без раздумий предпочту любому самопальному решению. апач, эклипс - тоже норм
в плане секурити, я, например, даже себе не сильно доверяю. хотя я наверн самый прошаренный в этих делах в конторе
О, у секьюрити с открытыми либами особенные взаимоотношения. Каждый раз, когда в публичных либах, которые использует половина энтерпрайза и куча остальных, находят критическую секьюрити уязвимость, у безопасников контор, где вообще имеет смысл безопасность(это на самом деле куда меньше, чем кажется, абсолютное большинство контор и их данных - Неуловимый Джо), возникают два вопроса.
1. Можно ли выяснить, использовали ли злоумышленники эту уязвимость у нас в тихую, до того, как детали уязвимости стали известны публично?
2. Если да, то КАК ДОЛГО они это делали? Год? Два? Десять? Судя по коду либы, уязвимость там жила всегда...
И ответы на эти вопросы ахуенно тревожно-безрадостные.
Слушай, ну ты же джавист. Код любой либы у тебя на расстоянии одного клика от твоего. Когда ты проводил поверхностный аудит кода либы перед использованием, ты не отбивал себе лицо от этого творчества гугла, апача и прочих? И у тебя нет счётчика индусов-авторов либ, которых ты хотел бы убить??
бывало, но в среднем по больнице код либ всё равно лучше, чем код коллег
есть вездесущие папочки utils по всему проекту, вот там народ изощряется в написании чего-то "реюзабельного". ко всем компонентам требования одинаковые, поэтому и в утилях этих часто попадается одно и то же, тока написанное разными людьми в разное время. и чаще всего это очередная манипулировалка коллекциями, типа гуавы или коммонс-коллекшнс, if you know what I mean
ичсх эти либы даже прикручены к проекту уже. максимум что надо сделать - дописать зависимость в сборочный скрипт
каждый раз фэйспалмлю, глядя на эти поделия. тут у нас опшеналы, тут нуллы, там эксепшены кидаем - ооо бля
каждый наверн думал, что пишет настолько охуенный код, что все щас им начнут пользоваться, а не наваяют такую же хрень рядом
я уже не говорю о том, чтобы задокументировать что-то или тупо оповестить коллег, что вот, что-то такое новое "реюзабельное" появилось
Ну, коллекции и утилы, если у вас стандартный энтерпрайз, действительно лучше из либ(у нас нельзя, но у нас есть этому причина - запрет выделения памяти, и ещё куча других, мы и стандартную либу жвм не используем кроме особых случаев).
Коллекции крайне обобщены, смысла обычно писать к ним свой код мало.
Коллекции крайне обобщены, смысла обычно писать к ним свой код мало.
по либам коллекций у нас вообще бинго собрано, но даже этого кому-то мало
давай хохму расскажу про самопальные решения
есть рест-апи. энное количество "микро"-сервисов. урл вида имя-сервиса/контроллер/залупень-какая-то
когда-то решили, что потребителям этого апи мы его отдаём не как есть, а через проксю, делающую реврайты урлов. типа так стабильнее, вы можете перекидывать контроллеры с места на место, выделать больше сервисов, вся хуйня
и хотим из этой херни сгенерить сваггер-описание этой апихи. но так, как оно выглядит снаружи. вот тока в коде-то нет инфы, как оно выглядит снаружи. эта инфа есть в конфигах прокси
ну и вот, пропатчили плагин, генерящий схему сваггера, чтобы он читал эти конфиги и на лету менял урлы. конфиги эти представляют собой регэкспы, и надо было еще регэксп "развернуть" - найти строчки, которые могли бы быть получены заменой по данному регэкспу, что в общем случае, конечно же, невозможно, но нахуячили ad hoc под то, что есть, как-то оно работает
вот такая вот хуйня у нас существует. никто не понимает, как оно работает, и если чота поломается, как эту хуйню чинить. легаси 80го левела
между такой хуйнёй и либой я бы предпочел либу, просто потому, что такую хрень в либы не оформляют, и никуда не выкладывают - стыдно
и решение на либе наверн бы заставило понапрягать мозги, и прийти в итоге к более-менее цивильному решению, а не вот это вот всё
Так нормальное решение, только с регекспами это вы погорячились.
И да, на лицо злостнрая конфигурация головного мозга. Конфиги, которые никто не конфигурирует, не нужно в конфиги, тем более, это внутренняя кухня. Люди боятся хардкода, совершенно зря на самом деле.
побойся б-га, какое же оно нормальное. эта прокся могла бы быть совершенно незасимым компонентом, если б не вот такая зависимость генерилки сваггера от нее. генерилка отрабатывает при сборке проекта
мб я плохо описал всю дичь. но мои коллеги тоже не все видят в этом проблему. работает - и хуй с них
а по поводу боязни хардкода - полностью согласен. ее последствия у нас тоже повсеместно
Самое не нормальное, что тут есть - это сама идея отдавать любые внутренние данные и апи вот так, на автоматике. С описанием, которое их вашего внутреннего сваггера тянется.
Но, видимо, ресурсов на поддержку внешнего апи нормально не выделили.
Но, видимо, ресурсов на поддержку внешнего апи нормально не выделили.
а там не любые данные. вторая причина существования этой прокси - некоторые запросы снаружи внутрь не проходят
Что вам мешало сделать банально дублирование всех контроллеров(или что у вас там хендлит запросы), которые нужны во внешке, со своими урлами и правилами, котрые внутри просто вызывают ваш внутренний? Ну, или не просто - это хорошее место для валидации, конвертировке данных, и прочего. Вывод куда-то в отдельный урл это уже забота админов.
хз, я пришел уже на имеющуюся в таком виде архитектуру. могу предположить, что объём кода. его и так за 3 ляма строк. и большинство как раз такая: возьми жсонину - переложи куда-то еще
Возьми aider, прицепи его к жпт(но лучше к платному claude), добавь все нужные контроллеры, создай папку для внешнего апи, и дай ему тот злоубучий конфиг регекспов вашей прокси.
Попроси его нагенерить контроллеры для внешнего апи с урлами по регекспам, и маппинг nginx для них.
Оно справится, такую чухню ИИ прекрасно делает. Выполнишь месячную работу сотни джунов за 5 минут.
Попроси его нагенерить контроллеры для внешнего апи с урлами по регекспам, и маппинг nginx для них.
Оно справится, такую чухню ИИ прекрасно делает. Выполнишь месячную работу сотни джунов за 5 минут.
пожалуй, воздержусь :)
потому что мне же придется потом со всеми эту хуйню согласовывать. начальству обосновывать трудозатраты, qa, одминам инструкции давать с примерчиками (сборище долбоёбов, за ручки их везде водить приходится), за миграциями следить, доки писать запарят меня же и т.д
и еще ближайшие месяца 3 все баги продукта на меня будут скидывать не глядя: "он же трогал, по-любому он и поломал"
я подобные масштабные темы периодически поднимаю, когда уже терпеть невозможно, но на это еще у меня щас сил нет. другие сидят, не рыпаются - молодцы, бабок наверн столько же имеют...
поди тестовый мок загнали в прод, не?
Тут в комментах все почему-то наивно предполагают, что из вопроса "ты тестировал?" следует, что обращаются к тестировщику. Ха-ха.
Копеечный фрилансер говорит сам с собой?
Ладно, это точно фейк. Дата билета пошла бы именно как дата. Там не было бы отрицательных значений. Автор переписки даже не из ИТ.
Ладно, это точно фейк. Дата билета пошла бы именно как дата. Там не было бы отрицательных значений. Автор переписки даже не из ИТ.
Шутка из 1998 года. Лет пятнадцать уже точно никто не будет пилить свой компонент с датой. Лет десять уже точно никто не будет продавать "билеты" через какую-то самописную хуйню
Оригинал цитаты был опубликован на айбаше в сентябре 2012 года. В те времена ещё делали кастомные компоненты под работу с датой
Да не, уже всё это в либах было, зачем?
Это ДБЯ или ПБЯ.
Отличный комментарий!