Дополню немного по поводу переезда с Postman на Bruno из собственного опыта. Тесты с использованием pm не конвертируются, поэтому может потребоваться их переписать. Если надо валидировать схемы JSON, то будет сложнее, если нет, то код может не потребоваться писать вообще, есть простые ассёрты на проверки респонса, что удобно. И нет мока (что из моего опыта не так часто используют) и перехватчика запросов (который в постмане тоже относительно недавно). И нет возможности редактирования переменных, может потребоваться их читать-писать скриптом, но работа в этом направлении идет.
А так подтверждаю, Bruno очень неплохая, при этом легковесная замена, которая во многом лучше, и постепенно развивается.
Мы уже шутили на работе, что, когда ИИ отберет работу у программистов, в конторе останутся только биэй и куэй, и биэй застрелится, потому что ему придется в 10+ раз точнее и детальнее описывать требования к генерируемому коду.
Ну, тут не совсем однозначный ответ, я бы сказал, но скорее да, чем нет.
Наличие возможности удаленки - определенно хорошо.
Я поясню.
Постоянная удаленка с точки зрения работников - в зависимости от персональных черт. Тем, кто лучше работает из дома - лучше. Тем, кто лучше работает из офиса - хуже. В этом смысле свобода выбора решает, потому что откуда работать - это один из факторов повышения личной эффективности, уровня стресса в процессе и, как итог, возврата на доллар зарплаты.
Говорят, что гибридный режим работает лучше всего, но не всегда говорят, что гибридный режим - это не только "два дня из офиса", но и "вот этот человек ничего не выигрывает от работы в офисе, и его работа в офисе не ведет ни к каким выгодам для компании, а вот этот выигрывает, и его работа из офиса дает больше пользы, чем работа из дома".
Для компаний удаленка это абсолютно точно плюс, если хочешь найти людей не из одного города, где есть офис, а по всей стране, или по региону, и можешь позволить себе нанять опытных людей, которых не надо сильно учить, при этом сэкономив серьезные деньги и усилия на релокации. Ну, и минус, если хочешь контролировать от и до, вместо того, чтобы доверять. В любом варианте тот, кто хочет не работать, а про@бываться, работать на полную не будет, независимо от того, в офисе он или дома.
Способов мониторить производительность удаленщиков без чипа в каждом отверстии предостаточно. Я пару лет назад как раз занимался тем, что объяснял руководству, что и как работает в их компании, и почему текущая производительность труда команды разработки оптимальна, и даже один пример того, как выглядит выгорание на цифрах. Самым неэффективным оказался бизнес аналитик, который чаще всех работал из офиса.
У нас полная удаленка в двух странах, что увеличивает пул кандидатов раз в 50 по сравнению с офисами, так что мы можем набирать людей, которым удаленка комфортна. По одному маленькому офису в стране, они нужны в основном для встреч с клиентами. И один человек в 5 часовых зонах на запад, которому удобно проводить технические работы по ночам, потому что у него еще не ночь.
Что-то я опять много написал, хехе, простите.
В общем, возможность удаленки - это хорошо, но только когда люди понимают, что это просто "вариант нормы" и умеют им правильно пользоваться.
В конечном итоге все сводится к получению прибыли, и, если понимать, как от удаленки получать больше прибыли (или тратить меньше) при большей гибкости, то это просто замечательно. Если еще и люди при этом чувствуют себя хорошо, то вообще отлично.
Я не могу сказать, что понимаю все факторы и их влияние по отдельности и в совокупности, но на некоторых новостях бывает понятно, что имеет смысл покупать, со временем некоторые шаблоны начинаешь распознавать, просто по опыту, и к каким краткосрочным и долгосрочным эффектам это может потенциально привести. Например, какое-то заявление в прессе, которое не подтверждено цифрами, может временно уронить цену акции, которая потом отскочит обратно буквально через несколько дней, за это время кто надо сделает несколько миллионов. Или анонс НВидиа по поводу нового направления, которое будет иметь длительный эффект, с моей подачи один мой знакомый сделал на этом порядка 300% от вложений. При всех трясках за последние полтора года мой маленький, но интересный портфель инвестиций вырос на 69%, причем в пассивном режиме, я просто относительно вовремя покупаю, на росте или перед тем как начинает расти. Если бы я этим занимался не от нефиг делать, а постоянно, могло бы быть лучше. Ну и твиттера у меня нет, в основном из-за того, как там ситуация шатается из стороны в сторону, если бы мне были интересны эти шатания, я бы занимался форексом.
Окончание пандемии само по себе не имеет экономического эффекта, оно ведет к каким-то событиям (на основе решений, принятых по окончании пандемии), которые имеют прямое экономическое влияние. Сокращение штатов непосредственно влияет на экономические показатели. Возвращение в офисы само по себе может не иметь экономического эффекта, либо иметь эффект, которым на средних сроках можно пренебречь (я не верю, что люди внезапно станут сильно лучше работать из офиса, но верю, что онбординг молодых кадров может быть лучше, опять же, в некоторых случаях, и некоторые компании используют возвращение в офис как показатель лояльности и отбор кадров, которые можно выжимать чуть сильнее, чем в среднем по больнице), но это также ведет к добровольному сокращению штатов, что имеет прямой экономический эффект. Тут я бы предположил сокращение расходов от ухода сотрудников, что будет заметно сразу, и некоторый эффект от выжимки человеческих ресурсов, который будет виден вначале (и это радостно будут рассказывать во всех газетах), но упадет по мере выгорания людей (этого рассказывать не будут).
Ну, и возвращаемся, соответственно, от вопроса "в курсе ли инвесторы, что людям не нравится в офисе?" к вопросу "а что происходит с чистой прибылью и котировками акций компании, когда количество работников, и, соответственно, самая большая статья расходов бюджета, уменьшается?". Когда компания снижает операционные расходы - акции растут. Если люди сами принимают решение уйти, а не компания принимает решение их уйти, бренд компании страдает заметно меньше, чем при очередном лэй-оффе (на примере предыдущих акробатических этюдов Маска, например). И инвесторы очень даже в курсе этого. Можно посмотреть, что происходит со стоимостью акций других компаний, которые возвращают работников в офисы, и, до определенной степени, сделать некоторые выводы. Если происходит странная фигня, которую для широких масс обосновывают моралью (а не финансами), имеет смысл посмотреть, кто имеет с этого профит, или кто мог бы поиметь с этого профит в недалеком будущем.
Во-первых, Маск сам объявил, что у него синдром Аспергера, не исключено, чтобы оправдать кое-что из своего поведения.
Во-вторых, обновите, может быть, свою информацию о расстройствах аутистического спектра, куда синдром Аспергера включен с, если не ошибаюсь, 2013 года, отсутствие эмпатии у людей с аутизмом было опровергнуто уже много лет как. С начала 1990-х это уже не рассматривалось как факт, и с того времени было подтверждено уже наверное парой сотен исследований, в 2012 году появился термин "проблема двойной эмпатии". Кроме того, эмпатию разделяют на эмоциональную и интеллектуальную. Первая - способность испытывать те же чувства, что другие, вторая - способность понимать их, даже при невозможности испытывать.
Ваше категоричное утверждение "У Маска синдром Аспергера, следовательно нет эмпатии" полностью ошибочно. Между этими двумя частями нет причино-следственной связи, что научно подтверждено, и ни одна их них не является абсолютно истинной.
Соответственно, решение Маска об отмене удаленки выглядит не как результат внутренней мотивации, а как результат внешней мотивации, которую мы, скорее всего, в открытом виде никогда не узнаем. Это запросто может быть пинок в зад от инвесторов за все те импульсивные поступки в последние несколько лет как с Твиттером, так и с Теслой, и прочим.
Полностью согласен. Из своего опыта могу сказать, что именно те, кто пытается "переходить" с винды на чего-то-бунту (без разницы, с какой оболочкой), больше всех ругаются, и потом "переходят" обратно, толком даже не начав. И потом говорят, мол, этот ваш линукс нестабильный.
Это как если бы я со стабильного Дебиана щас перешел на Microsoft Insider Builds, и потом канифолил всем мозг на тему "Этот виндовс вапще ни разу не стабильный".
Вот, спрашивается, на кой мучаться с дистрибутивом из нестабильной пакетной базы, если есть куча более стабильных вариантов? Это оно подается как дистрибутив для домохозяек, на самом деле там неопытному пользователю может быть тяжелее, чем на арче или манджаре, потому что то тут всё сломали, то там зависимости не обновили, то тут впилили версию, которую еще никто не тестил, и хрен ты это починишь сам.
В результате начинается использование виртуальной памяти, что замедляет производительность из-за более медленного доступа к данным.
Тут требуется уточнить, мне кажется.
Десктопные приложения в принципе с самого начала работы используют виртуальную память, которую операционная система им выделяет, а не оперативную память напрямую. Приложение может запросить больше памяти, чем физически доступный объём оперативной памяти в системе, и операционная система может вполне себе выделить этот объём. Она потому и называется виртуальной, что где хранить страницы памяти, в оперативной памяти или на диске (в свопе), решает операционная система, приложение обычно не может сказать "хочу столько-то физической оперативной памяти". Начинает тормозить обычно в случае, когда происходит активный обмен страницами между оперативной памятью и диском, что для самого приложения должно быть прозрачно. И основная причина - приложению требуется иметь доступ к бОльшему объему памяти, чем операционная система позволяет разместить в данный момент в оперативной памяти (либо потому,что другим приложениям она тоже требуется, либо потому, что приложение хочет больше, чем доступно физической памяти).
Погодите-ка. Давайте разберём эти странные цифры из википедии.
16 экзабайт - это теоретический максимум размера файла для NTFS. Максимальный имплементированный размер файла - 8 PB. 256 TB минус 64 килобайта - это максимальный размер раздела с размером кластера 64Кб. Максимальный размер кластера, поддерживаемый NTFS - 2MB. Максимальный теоретический размер раздела для 2MB кластера - 32*256 TB?
Судя по всему, имеет смысл все-таки говорить о том, что имплементировано, и это, похоже, 8PB c кластером 2Mb для раздела и столько же для максимального размера файла.
Зависит от проекта и того, какой подход используется - Application Action или Page Object Model. Можно в Dictionary, можно в отдельный класс Selectors, можно как проперти Page Object, можно enum. Главное, чтобы в самих тестах использовались имена для элементов, с которыми вы работаете, а не селекторы напрямую.
При использовании Application Action может быть проще.
Пример. У меня был случай, когда был набор из нескольких веб-приложений построенных на одной кастомной UI библиотеке с 2-3 разными версиями этой самой библиотеки. Разные тестовые пакеты (один пакет на приложение) включают класс приложения. Класс приложения имеет проперти Locators, это проперти - объект, унаследованный от CommonHelpers.CommonLocators и расширяющий его специфическими для данного приложения локаторами. Объект - потому что туда же можно добавить методы для динамической генерации селекторов, а точные селекторы как проперти. В том случае, если в каком-то приложении селектор отличается от того же в CommonLocators, он просто добавляется в локальный класс Locators через override. Когда тестируемое приложение обновилось до совпадающей с CommonLocators версии UI библиотеки, локальные селекторы просто удаляются из локального класса селекторов и автоматически за счет наследования используются общие селекторы.
Для поиска одинаковых селекторов можно написать скрипт, который тупо пройдет по CommonLocators и всем классам для отдельных приложений, найдет одинаковые/разные селекторы и выдаст вам список того, что можно удалять за ненадобностью и где. Общие селекторы добавлялись после того, как более чем одно из приложений получали одну и ту же версию UI компонентов, остальные догоняют по мере обновления. Тут больше регулярная организационная работа и надо отдельно смотреть в каждом случае, можно ли "автоматизировать автоматизацию" скриптами, но в целом такой подход сильно сократил время на поддержку и дал больше времени на написание новых тестов.
При этом в самих тестах скрипты остаются без изменений месяцами (потому что тестовые сценарии на меняются и используются те же веб-элементы), подавляющая часть локаторов находится в одном файле, соответственно, при обновлении в одном месте они будут использоваться во всех тестовых пакетах, обновление селекторов можно планировать, если есть информация об апдейтах приложений в джире (таск на обновление версий компонентов), классы селекторов для отдельных приложений остаются примерно одного размера, плюс-минус 20 селекторов в разное время, и так далее.
Я в целом тоже предпочитаю XPath, просто стараюсь писать менее хрупкие селекторы по возможности.
Уважаю ваше мнение, но по некоторым моментам могу сказать из практического опыта. Единый стиль селекторов - это практике обычно "nice to have". Поясню.
Приложения могут писаться в течение долгих лет кучей разных людей и даже команд. На практике сложно наладить коммуникацию и внедрение id и name везде, если разработка не затрагивает более старые части приложения. Прямо сегодня они должны (на самом деле нет) писаться с добавлением уникальных идентификаторов, с этим согласен, но на практике я не скажу разработчикам "тут нет айди, иди переделывай", я скорее всего просто использую xpath и подожду, пока этот id там появится. Кроме того, он, в отличие от id, name и CSS, подходит для поиска элементов, которые содержат определенный текст, например, что бывает полезно иногда.
Если тесты становятся плохо читаемы из-за того, что какие-то селекторы меняются, значит надо отделять тесты от селекторов. Сам тест не должен зависеть от селекторов, плюс централизованное их использование позволяет пофиксить кучу тестов иногда просто обновив одну строчку, не трогая код самих тестов при этом.
С динамическими приложениями, в которых элементы генерируются автоматически, номер с id и name очень часто не пройдет, поэтому там проще использовать селектор-генераторы, функции, которые генерируют селекторы на основе xpath-шаблона для элементов определенных типов.
Я бы тоже предпочёл иметь везде id, потому что это не только проще использовать, но и сложнее сломать, но, к сожалению, это не всегда реалистично. XPath сильно гибче, но менее надёжен, если UI в активной разработке. Про CSS, который генерируется автоматом и минимизируется на каждый билд, поэтому меняется полностью каждый билд, вообще молчу. Поэтому временами приходится комбинировать и то, и то, и то, и просто стараться соблюдать баланс между покрытием, стабильностью тестов и удобством поддержки. В любом случае, это всё не для того, чтобы сделать вам приятно, а для того, чтобы бизнес мог решать свои задачи.
По поводу быстродействия полностью согласен. Разница в поиске была заметна во времена древних версий Internet Explorer может быть, ни для одного современного браузерного движка это не проблема, любой простой запрос на бэк + обновление DOM tree обычно занимает дольше.
Вместо 65 плюсов можно было показать в статье как организуются и работают циклы, и заодно сократить длину программы. Согласен с комментарием @bfDeveloper по поводу того, что алгоритмы - это про логику, а не конструкции языка. Было бы отлично показать больше логики в статье, на мой вкус получилось так себе, хоть и не минусовал. Плюс, для такого транслятора разворачивать аж целый python runtime чувствуется как солидный оверхэд. Но это ладно. Если использовать match (с версии 3.10, если не ошибаюсь), код можно сделать проще. Плюс начало цикла "[" само по себе ничего не делает, а просто служит точкой останова для "]". ] - это буквально "проверить значение в текущей ячейке, и, если не ноль, уменьшать индекс рабочей ячейки в массиве программы, пока не найдено [, увеличить индекс на 1 (>)". Как-то так.
Если интересуют "более другие" варианты писать на BF, есть отличная среда программирования bfdev (HTTP без S), включающая в том числе расширения языка и автоматическую оптимизацию кода, насколько помню. Я ее использовал, когда преподавал курс по BF лет 7 назад.
В своё время работал с провиженингом девайсов от разных производителей (ealink, правда, мало застал, в основном Cisco и Polycom), лучшая защита передаваемых данных - это использовать HTTPS, а не TFTP. Тогда можно использовать клиентские сертификаты устройств и двустороннюю TLS аутентификацию.
Многие, если не все, производители добавляют в прошивку клиентские сертификаты, содержащие Mac-адрес телефона. В этом случае можно отсекать нелигитимные запросы прямо на этапе хэндшейка (мак-адрес из сертификата, название запрашиваемого файла, intermediate сертификат производителя, которым подписан сертификат телефона), и заодно китайские подделки с клонированными чипами. Правда мы это делали в промышленном масштабе, 5+20 - это мало, у нас были пяти-шестизначные цифры, но, тем не менее, приципиально это ничего не меняет. Просто валидация CA на сервере, без всего остального, сильно усложняет запросы от всего, что не телефон, причем быстро.
TFTP в пределах одной организации вполне себе может быть, если SIP-шлюз тоже внутри. Не все хотят заморачиваться с безопасностью в локальной сети в малых организациях. Любой выход наружу - HTTPS, плюс защитные меры выше, плюс еще кучу проверок можно добавить если запрос каким-то чудом проскочил mutual authentication, можно валидировать вообще всё, что приходит в запросе, до отдачи конфига (заголовки HTTP-запроса, например, размер запроса, и так далее). Ломать SSL/TLS - так себе занятие. Дорого, скучно, проще другого провайдера найти, с защитой попроще. Ломать SSL/TLS + проверки провиженинг-сервера - это надо быть очень целеустремлённым.
Сами телефоны обычно пароль не отображают, в открытом виде или в виде хэша, в гуе, и многие при скачивании конфигов его в эти конфиги не пишут. Передача - внутри HTTPS, что уменьшает шансы перехвата, оставляя, в общем, только MITM с кучей дополнительных телодвижений, что, опять же, и долго, и недёшево, и явно того не стоит.
В общем, хотите безопасности - используйте провиженинг-сервер и HTTPS, а не DHCP+TFTP.
Представьте: вы сможете удержать в кратковременной памяти не 3-4 концепта, а 40-50! И не просто удержать в памяти, а мгновенно выделить несколько взаимосвязанных концептов, сформулировать эту связь и сделать вывод. Потом использовать этот вывод как ещё один концепт, найти новые связи... И ни один этап не вызовет затруднений.
Отлично представляю, потому что примерно так мой мозг и работает. Но есть нюанс. Так работает мозг людей с расстройством аутистического спектра в гиперфокусе. Тут вы, на удивление, даже в количеством концептов угадали. На самом деле можно больше (раза в три), просто тогда время начинает идти субъективно неравномерно, и устаешь быстрее.
Не уверен, получилось бы у нейротипичного мозга так работать или нет.
Так что я бы сказал так: главный инструмент тестировщика - автоматизированные тесты.
После работы тестировщиком больше 12 лет могу сказать, что главный инструмент тестировщика - это мозг.
Да, я умею писать правильные автотесты. Нет, не все пишут их правильно. Нет, разработчики не покрывают тестами всё, что надо. Нет, для того, чтобы быть хорошим тестировщиком, не обязательно уметь кодить. Да, можно уметь кодить и при этом писать отвратные автотесты.
И, кроме того, автотесты - это checks, а не tests.
Да, я согласен, что если что-то надо делать руками регулярно, это можно автоматизировать, чтобы освободить время для exploratory тестинга. И Cypress - это отличный инструмент в некоторых случаях (в том числе и за счет cy.intercept()), как и Playwright (который тоже умеет в перехват запросов). Единственное только, тестирование - это контекстно-зависимая штука, и контекст, в котором вы говорите, насколько я понял, - это только фронтенд. Не все могут в контекст.
Я не согласен, что автотесты это прям главный инструмент. Это скорее главный инструмент автоматизации регрессионных проверок в этом контексте, только и всего. А это достаточно малая часть тестирования. Плюс поддержка и актуализация этого всего. Опять же, на фронтенде свет клином не сошелся, там кроме него еще лютое количество вещей, которые надо тестировать.
Тестирование - это гораздо более широкая область, чем вы тут описали.
По поводу вашего коммента ниже - тоже согласен, можно автоматизировать проверки на фронте за пару пятничных вечеров, но, вы же понимаете, что это только самое начало? Мало написать, надо поддерживать, актуализировать, где возможно и имеет смысл - спускать на более низкий уровень пирамиды тестирования. Просто хотя бы потому, что я могу прогнать 300 API тестов за минуту и гораздо меньше E2E сценариев за то же время, даже если перехватывать запросы на бэк. И зря вы так категорично сразу про GraphQL. Хорошая штука, но... Если на бэк идет много запросов (почему, собственно, он их и отдает, он же не сам решает вам жысонов в браузер напихать), то надо думать об архитектуре в первую очередь, доменной области и как там представлены данные, и почему в этой модели фронтенд хочет эти разные данные. Может так случиться, что GraphQL не понадобится, потому что он только сделает хуже, хотя бы потому, что данные через REST можно получать в параллель, и так далее.
Проблема не написать скрипты. Проблема соблюдать баланс в течение длительного времени, чтобы не гонять потом E2E скрипты часами после каждого мёрджа. Кстати говоря, если вы гоняете E2E исключительно на фронте (без бэка), то это тоже не обязательно хорошо, ибо синтетическое окружение, после интеграции можно получить кое-каких сюрпризов, если у вас бэк не прям реактивный.
К статье еще бы добавил блокировку запросов по маске в Dev Tools.
Извините, что так много. В заключение могу сказать, что, если вас устраивает то, что у вас есть, и облегчает жизнь людям, то и хорошо. Надо просто понимать, что тестирование это много больше, чем автотесты.
Ну или разделать, учитывая, чем этот товарищ из Питера выше интересовался.
Дополню немного по поводу переезда с Postman на Bruno из собственного опыта. Тесты с использованием pm не конвертируются, поэтому может потребоваться их переписать. Если надо валидировать схемы JSON, то будет сложнее, если нет, то код может не потребоваться писать вообще, есть простые ассёрты на проверки респонса, что удобно. И нет мока (что из моего опыта не так часто используют) и перехватчика запросов (который в постмане тоже относительно недавно). И нет возможности редактирования переменных, может потребоваться их читать-писать скриптом, но работа в этом направлении идет.
А так подтверждаю, Bruno очень неплохая, при этом легковесная замена, которая во многом лучше, и постепенно развивается.
Мы уже шутили на работе, что, когда ИИ отберет работу у программистов, в конторе останутся только биэй и куэй, и биэй застрелится, потому что ему придется в 10+ раз точнее и детальнее описывать требования к генерируемому коду.
Ну, тут не совсем однозначный ответ, я бы сказал, но скорее да, чем нет.
Наличие возможности удаленки - определенно хорошо.
Я поясню.
Постоянная удаленка с точки зрения работников - в зависимости от персональных черт. Тем, кто лучше работает из дома - лучше. Тем, кто лучше работает из офиса - хуже. В этом смысле свобода выбора решает, потому что откуда работать - это один из факторов повышения личной эффективности, уровня стресса в процессе и, как итог, возврата на доллар зарплаты.
Говорят, что гибридный режим работает лучше всего, но не всегда говорят, что гибридный режим - это не только "два дня из офиса", но и "вот этот человек ничего не выигрывает от работы в офисе, и его работа в офисе не ведет ни к каким выгодам для компании, а вот этот выигрывает, и его работа из офиса дает больше пользы, чем работа из дома".
Для компаний удаленка это абсолютно точно плюс, если хочешь найти людей не из одного города, где есть офис, а по всей стране, или по региону, и можешь позволить себе нанять опытных людей, которых не надо сильно учить, при этом сэкономив серьезные деньги и усилия на релокации. Ну, и минус, если хочешь контролировать от и до, вместо того, чтобы доверять. В любом варианте тот, кто хочет не работать, а про@бываться, работать на полную не будет, независимо от того, в офисе он или дома.
Способов мониторить производительность удаленщиков без чипа в каждом отверстии предостаточно. Я пару лет назад как раз занимался тем, что объяснял руководству, что и как работает в их компании, и почему текущая производительность труда команды разработки оптимальна, и даже один пример того, как выглядит выгорание на цифрах. Самым неэффективным оказался бизнес аналитик, который чаще всех работал из офиса.
У нас полная удаленка в двух странах, что увеличивает пул кандидатов раз в 50 по сравнению с офисами, так что мы можем набирать людей, которым удаленка комфортна. По одному маленькому офису в стране, они нужны в основном для встреч с клиентами. И один человек в 5 часовых зонах на запад, которому удобно проводить технические работы по ночам, потому что у него еще не ночь.
Что-то я опять много написал, хехе, простите.
В общем, возможность удаленки - это хорошо, но только когда люди понимают, что это просто "вариант нормы" и умеют им правильно пользоваться.
В конечном итоге все сводится к получению прибыли, и, если понимать, как от удаленки получать больше прибыли (или тратить меньше) при большей гибкости, то это просто замечательно. Если еще и люди при этом чувствуют себя хорошо, то вообще отлично.
Я не могу сказать, что понимаю все факторы и их влияние по отдельности и в совокупности, но на некоторых новостях бывает понятно, что имеет смысл покупать, со временем некоторые шаблоны начинаешь распознавать, просто по опыту, и к каким краткосрочным и долгосрочным эффектам это может потенциально привести. Например, какое-то заявление в прессе, которое не подтверждено цифрами, может временно уронить цену акции, которая потом отскочит обратно буквально через несколько дней, за это время кто надо сделает несколько миллионов. Или анонс НВидиа по поводу нового направления, которое будет иметь длительный эффект, с моей подачи один мой знакомый сделал на этом порядка 300% от вложений. При всех трясках за последние полтора года мой маленький, но интересный портфель инвестиций вырос на 69%, причем в пассивном режиме, я просто относительно вовремя покупаю, на росте или перед тем как начинает расти. Если бы я этим занимался не от нефиг делать, а постоянно, могло бы быть лучше. Ну и твиттера у меня нет, в основном из-за того, как там ситуация шатается из стороны в сторону, если бы мне были интересны эти шатания, я бы занимался форексом.
Окончание пандемии само по себе не имеет экономического эффекта, оно ведет к каким-то событиям (на основе решений, принятых по окончании пандемии), которые имеют прямое экономическое влияние. Сокращение штатов непосредственно влияет на экономические показатели. Возвращение в офисы само по себе может не иметь экономического эффекта, либо иметь эффект, которым на средних сроках можно пренебречь (я не верю, что люди внезапно станут сильно лучше работать из офиса, но верю, что онбординг молодых кадров может быть лучше, опять же, в некоторых случаях, и некоторые компании используют возвращение в офис как показатель лояльности и отбор кадров, которые можно выжимать чуть сильнее, чем в среднем по больнице), но это также ведет к добровольному сокращению штатов, что имеет прямой экономический эффект. Тут я бы предположил сокращение расходов от ухода сотрудников, что будет заметно сразу, и некоторый эффект от выжимки человеческих ресурсов, который будет виден вначале (и это радостно будут рассказывать во всех газетах), но упадет по мере выгорания людей (этого рассказывать не будут).
Ну, и возвращаемся, соответственно, от вопроса "в курсе ли инвесторы, что людям не нравится в офисе?" к вопросу "а что происходит с чистой прибылью и котировками акций компании, когда количество работников, и, соответственно, самая большая статья расходов бюджета, уменьшается?". Когда компания снижает операционные расходы - акции растут. Если люди сами принимают решение уйти, а не компания принимает решение их уйти, бренд компании страдает заметно меньше, чем при очередном лэй-оффе (на примере предыдущих акробатических этюдов Маска, например). И инвесторы очень даже в курсе этого. Можно посмотреть, что происходит со стоимостью акций других компаний, которые возвращают работников в офисы, и, до определенной степени, сделать некоторые выводы. Если происходит странная фигня, которую для широких масс обосновывают моралью (а не финансами), имеет смысл посмотреть, кто имеет с этого профит, или кто мог бы поиметь с этого профит в недалеком будущем.
Во-первых, Маск сам объявил, что у него синдром Аспергера, не исключено, чтобы оправдать кое-что из своего поведения.
Во-вторых, обновите, может быть, свою информацию о расстройствах аутистического спектра, куда синдром Аспергера включен с, если не ошибаюсь, 2013 года, отсутствие эмпатии у людей с аутизмом было опровергнуто уже много лет как. С начала 1990-х это уже не рассматривалось как факт, и с того времени было подтверждено уже наверное парой сотен исследований, в 2012 году появился термин "проблема двойной эмпатии". Кроме того, эмпатию разделяют на эмоциональную и интеллектуальную. Первая - способность испытывать те же чувства, что другие, вторая - способность понимать их, даже при невозможности испытывать.
Ваше категоричное утверждение "У Маска синдром Аспергера, следовательно нет эмпатии" полностью ошибочно. Между этими двумя частями нет причино-следственной связи, что научно подтверждено, и ни одна их них не является абсолютно истинной.
Соответственно, решение Маска об отмене удаленки выглядит не как результат внутренней мотивации, а как результат внешней мотивации, которую мы, скорее всего, в открытом виде никогда не узнаем. Это запросто может быть пинок в зад от инвесторов за все те импульсивные поступки в последние несколько лет как с Твиттером, так и с Теслой, и прочим.
Полностью согласен. Из своего опыта могу сказать, что именно те, кто пытается "переходить" с винды на чего-то-бунту (без разницы, с какой оболочкой), больше всех ругаются, и потом "переходят" обратно, толком даже не начав. И потом говорят, мол, этот ваш линукс нестабильный.
Это как если бы я со стабильного Дебиана щас перешел на Microsoft Insider Builds, и потом канифолил всем мозг на тему "Этот виндовс вапще ни разу не стабильный".
Вот, спрашивается, на кой мучаться с дистрибутивом из нестабильной пакетной базы, если есть куча более стабильных вариантов? Это оно подается как дистрибутив для домохозяек, на самом деле там неопытному пользователю может быть тяжелее, чем на арче или манджаре, потому что то тут всё сломали, то там зависимости не обновили, то тут впилили версию, которую еще никто не тестил, и хрен ты это починишь сам.
"ЛюбвИАбильный динозавр" - это какая-то игра слов, или вы правда считаете, что это слово так пишется?
Видимо туда же, куда TLS
Он еще и в целом приятный человек. Переписывался с ним по поводу дисковой подсистемы JSLinux году в 2013 или около того. Отлично пообщались.
Тут требуется уточнить, мне кажется.
Десктопные приложения в принципе с самого начала работы используют виртуальную память, которую операционная система им выделяет, а не оперативную память напрямую. Приложение может запросить больше памяти, чем физически доступный объём оперативной памяти в системе, и операционная система может вполне себе выделить этот объём. Она потому и называется виртуальной, что где хранить страницы памяти, в оперативной памяти или на диске (в свопе), решает операционная система, приложение обычно не может сказать "хочу столько-то физической оперативной памяти". Начинает тормозить обычно в случае, когда происходит активный обмен страницами между оперативной памятью и диском, что для самого приложения должно быть прозрачно. И основная причина - приложению требуется иметь доступ к бОльшему объему памяти, чем операционная система позволяет разместить в данный момент в оперативной памяти (либо потому,что другим приложениям она тоже требуется, либо потому, что приложение хочет больше, чем доступно физической памяти).
Погодите-ка. Давайте разберём эти странные цифры из википедии.
16 экзабайт - это теоретический максимум размера файла для NTFS. Максимальный имплементированный размер файла - 8 PB. 256 TB минус 64 килобайта - это максимальный размер раздела с размером кластера 64Кб. Максимальный размер кластера, поддерживаемый NTFS - 2MB. Максимальный теоретический размер раздела для 2MB кластера - 32*256 TB?
Судя по всему, имеет смысл все-таки говорить о том, что имплементировано, и это, похоже, 8PB c кластером 2Mb для раздела и столько же для максимального размера файла.
Зависит от проекта и того, какой подход используется - Application Action или Page Object Model. Можно в Dictionary, можно в отдельный класс Selectors, можно как проперти Page Object, можно enum. Главное, чтобы в самих тестах использовались имена для элементов, с которыми вы работаете, а не селекторы напрямую.
При использовании Application Action может быть проще.
Пример. У меня был случай, когда был набор из нескольких веб-приложений построенных на одной кастомной UI библиотеке с 2-3 разными версиями этой самой библиотеки. Разные тестовые пакеты (один пакет на приложение) включают класс приложения. Класс приложения имеет проперти Locators, это проперти - объект, унаследованный от CommonHelpers.CommonLocators и расширяющий его специфическими для данного приложения локаторами. Объект - потому что туда же можно добавить методы для динамической генерации селекторов, а точные селекторы как проперти. В том случае, если в каком-то приложении селектор отличается от того же в CommonLocators, он просто добавляется в локальный класс Locators через override. Когда тестируемое приложение обновилось до совпадающей с CommonLocators версии UI библиотеки, локальные селекторы просто удаляются из локального класса селекторов и автоматически за счет наследования используются общие селекторы.
Для поиска одинаковых селекторов можно написать скрипт, который тупо пройдет по CommonLocators и всем классам для отдельных приложений, найдет одинаковые/разные селекторы и выдаст вам список того, что можно удалять за ненадобностью и где. Общие селекторы добавлялись после того, как более чем одно из приложений получали одну и ту же версию UI компонентов, остальные догоняют по мере обновления. Тут больше регулярная организационная работа и надо отдельно смотреть в каждом случае, можно ли "автоматизировать автоматизацию" скриптами, но в целом такой подход сильно сократил время на поддержку и дал больше времени на написание новых тестов.
При этом в самих тестах скрипты остаются без изменений месяцами (потому что тестовые сценарии на меняются и используются те же веб-элементы), подавляющая часть локаторов находится в одном файле, соответственно, при обновлении в одном месте они будут использоваться во всех тестовых пакетах, обновление селекторов можно планировать, если есть информация об апдейтах приложений в джире (таск на обновление версий компонентов), классы селекторов для отдельных приложений остаются примерно одного размера, плюс-минус 20 селекторов в разное время, и так далее.
Я в целом тоже предпочитаю XPath, просто стараюсь писать менее хрупкие селекторы по возможности.
Уважаю ваше мнение, но по некоторым моментам могу сказать из практического опыта. Единый стиль селекторов - это практике обычно "nice to have". Поясню.
Приложения могут писаться в течение долгих лет кучей разных людей и даже команд. На практике сложно наладить коммуникацию и внедрение id и name везде, если разработка не затрагивает более старые части приложения. Прямо сегодня они должны (на самом деле нет) писаться с добавлением уникальных идентификаторов, с этим согласен, но на практике я не скажу разработчикам "тут нет айди, иди переделывай", я скорее всего просто использую xpath и подожду, пока этот id там появится. Кроме того, он, в отличие от id, name и CSS, подходит для поиска элементов, которые содержат определенный текст, например, что бывает полезно иногда.
Если тесты становятся плохо читаемы из-за того, что какие-то селекторы меняются, значит надо отделять тесты от селекторов. Сам тест не должен зависеть от селекторов, плюс централизованное их использование позволяет пофиксить кучу тестов иногда просто обновив одну строчку, не трогая код самих тестов при этом.
С динамическими приложениями, в которых элементы генерируются автоматически, номер с id и name очень часто не пройдет, поэтому там проще использовать селектор-генераторы, функции, которые генерируют селекторы на основе xpath-шаблона для элементов определенных типов.
Я бы тоже предпочёл иметь везде id, потому что это не только проще использовать, но и сложнее сломать, но, к сожалению, это не всегда реалистично. XPath сильно гибче, но менее надёжен, если UI в активной разработке. Про CSS, который генерируется автоматом и минимизируется на каждый билд, поэтому меняется полностью каждый билд, вообще молчу. Поэтому временами приходится комбинировать и то, и то, и то, и просто стараться соблюдать баланс между покрытием, стабильностью тестов и удобством поддержки. В любом случае, это всё не для того, чтобы сделать вам приятно, а для того, чтобы бизнес мог решать свои задачи.
По поводу быстродействия полностью согласен. Разница в поиске была заметна во времена древних версий Internet Explorer может быть, ни для одного современного браузерного движка это не проблема, любой простой запрос на бэк + обновление DOM tree обычно занимает дольше.
Буква A может выглядеть так:
Вместо 65 плюсов можно было показать в статье как организуются и работают циклы, и заодно сократить длину программы. Согласен с комментарием @bfDeveloper по поводу того, что алгоритмы - это про логику, а не конструкции языка. Было бы отлично показать больше логики в статье, на мой вкус получилось так себе, хоть и не минусовал. Плюс, для такого транслятора разворачивать аж целый python runtime чувствуется как солидный оверхэд. Но это ладно. Если использовать match (с версии 3.10, если не ошибаюсь), код можно сделать проще. Плюс начало цикла "[" само по себе ничего не делает, а просто служит точкой останова для "]". ] - это буквально "проверить значение в текущей ячейке, и, если не ноль, уменьшать индекс рабочей ячейки в массиве программы, пока не найдено [, увеличить индекс на 1 (>)". Как-то так.
Если интересуют "более другие" варианты писать на BF, есть отличная среда программирования bfdev (HTTP без S), включающая в том числе расширения языка и автоматическую оптимизацию кода, насколько помню. Я ее использовал, когда преподавал курс по BF лет 7 назад.
В своё время работал с провиженингом девайсов от разных производителей (ealink, правда, мало застал, в основном Cisco и Polycom), лучшая защита передаваемых данных - это использовать HTTPS, а не TFTP. Тогда можно использовать клиентские сертификаты устройств и двустороннюю TLS аутентификацию.
Многие, если не все, производители добавляют в прошивку клиентские сертификаты, содержащие Mac-адрес телефона. В этом случае можно отсекать нелигитимные запросы прямо на этапе хэндшейка (мак-адрес из сертификата, название запрашиваемого файла, intermediate сертификат производителя, которым подписан сертификат телефона), и заодно китайские подделки с клонированными чипами. Правда мы это делали в промышленном масштабе, 5+20 - это мало, у нас были пяти-шестизначные цифры, но, тем не менее, приципиально это ничего не меняет. Просто валидация CA на сервере, без всего остального, сильно усложняет запросы от всего, что не телефон, причем быстро.
TFTP в пределах одной организации вполне себе может быть, если SIP-шлюз тоже внутри. Не все хотят заморачиваться с безопасностью в локальной сети в малых организациях. Любой выход наружу - HTTPS, плюс защитные меры выше, плюс еще кучу проверок можно добавить если запрос каким-то чудом проскочил mutual authentication, можно валидировать вообще всё, что приходит в запросе, до отдачи конфига (заголовки HTTP-запроса, например, размер запроса, и так далее). Ломать SSL/TLS - так себе занятие. Дорого, скучно, проще другого провайдера найти, с защитой попроще. Ломать SSL/TLS + проверки провиженинг-сервера - это надо быть очень целеустремлённым.
Сами телефоны обычно пароль не отображают, в открытом виде или в виде хэша, в гуе, и многие при скачивании конфигов его в эти конфиги не пишут. Передача - внутри HTTPS, что уменьшает шансы перехвата, оставляя, в общем, только MITM с кучей дополнительных телодвижений, что, опять же, и долго, и недёшево, и явно того не стоит.
В общем, хотите безопасности - используйте провиженинг-сервер и HTTPS, а не DHCP+TFTP.
Отлично представляю, потому что примерно так мой мозг и работает. Но есть нюанс. Так работает мозг людей с расстройством аутистического спектра в гиперфокусе. Тут вы, на удивление, даже в количеством концептов угадали. На самом деле можно больше (раза в три), просто тогда время начинает идти субъективно неравномерно, и устаешь быстрее.
Не уверен, получилось бы у нейротипичного мозга так работать или нет.
После работы тестировщиком больше 12 лет могу сказать, что главный инструмент тестировщика - это мозг.
Да, я умею писать правильные автотесты. Нет, не все пишут их правильно. Нет, разработчики не покрывают тестами всё, что надо. Нет, для того, чтобы быть хорошим тестировщиком, не обязательно уметь кодить. Да, можно уметь кодить и при этом писать отвратные автотесты.
И, кроме того, автотесты - это checks, а не tests.
Да, я согласен, что если что-то надо делать руками регулярно, это можно автоматизировать, чтобы освободить время для exploratory тестинга. И Cypress - это отличный инструмент в некоторых случаях (в том числе и за счет cy.intercept()), как и Playwright (который тоже умеет в перехват запросов). Единственное только, тестирование - это контекстно-зависимая штука, и контекст, в котором вы говорите, насколько я понял, - это только фронтенд. Не все могут в контекст.
Я не согласен, что автотесты это прям главный инструмент. Это скорее главный инструмент автоматизации регрессионных проверок в этом контексте, только и всего. А это достаточно малая часть тестирования. Плюс поддержка и актуализация этого всего. Опять же, на фронтенде свет клином не сошелся, там кроме него еще лютое количество вещей, которые надо тестировать.
Тестирование - это гораздо более широкая область, чем вы тут описали.
По поводу вашего коммента ниже - тоже согласен, можно автоматизировать проверки на фронте за пару пятничных вечеров, но, вы же понимаете, что это только самое начало? Мало написать, надо поддерживать, актуализировать, где возможно и имеет смысл - спускать на более низкий уровень пирамиды тестирования. Просто хотя бы потому, что я могу прогнать 300 API тестов за минуту и гораздо меньше E2E сценариев за то же время, даже если перехватывать запросы на бэк. И зря вы так категорично сразу про GraphQL. Хорошая штука, но... Если на бэк идет много запросов (почему, собственно, он их и отдает, он же не сам решает вам жысонов в браузер напихать), то надо думать об архитектуре в первую очередь, доменной области и как там представлены данные, и почему в этой модели фронтенд хочет эти разные данные. Может так случиться, что GraphQL не понадобится, потому что он только сделает хуже, хотя бы потому, что данные через REST можно получать в параллель, и так далее.
Проблема не написать скрипты. Проблема соблюдать баланс в течение длительного времени, чтобы не гонять потом E2E скрипты часами после каждого мёрджа. Кстати говоря, если вы гоняете E2E исключительно на фронте (без бэка), то это тоже не обязательно хорошо, ибо синтетическое окружение, после интеграции можно получить кое-каких сюрпризов, если у вас бэк не прям реактивный.
К статье еще бы добавил блокировку запросов по маске в Dev Tools.
Извините, что так много. В заключение могу сказать, что, если вас устраивает то, что у вас есть, и облегчает жизнь людям, то и хорошо. Надо просто понимать, что тестирование это много больше, чем автотесты.
Спасибо, что объяснили, не очень понятно было. Извините, с суммами с недосыпа это я тупанул конечно.