Alex Efros @powerman
Software Architect, Team Lead, Lead Go Developer
Information
- Rating
- 1,904-th
- Location
- Харьков, Харьковская обл., Украина
- Date of birth
- Registered
- Activity
Specialization
Backend Developer, Software Architect
Lead
From 10,000 $
Designing application architecture
Golang
Linux
Docker
Network security
Modular testing
Mentoring
Development of tech specifications
Software development
High-loaded systems
Австралийских законодателей это не остановило - обязали компании внедрять для спецслужб бэкдоры и одновременно запретили компаниям сообщать об этом. Я был дико изумлён, что после этого у Атлассиан не просто остались клиенты, а вообще нельзя даже сказать, чтобы их стало меньше. Всем плевать, как выяснилось, по крайней мере - бизнесам.
Давайте не будем расширять тему. Потому что CBDC как технология - это одно, а последствия внедрения этой технологии конкретно для банковской системы - это совсем другое.
Факт в том, что после внедрения CBDC банки перестанут быть нужны в роли кастодианов. Их другие функции, вроде выдачи кредитов, могут остаться востребованными, но это определённо будут уже совсем не те банки, которые сегодня.
Да, государство может попытаться смягчить/компенсировать эту ситуацию, хотя бы на переходный период - делегируя какие-то подзадачи CBDC банкам или дотируя их для компенсации оттока пользовательских средств в CBDC. Но в конечном итоге будет как всегда - прогресс пойдёт дальше, а кто не адаптировался - вылетит с рынка.
Учитывая это, я бы на месте банков не доверял никаким обещаниям со стороны государства из серии "CBDC ничего не изменит и банки по-прежнему будут нужны и будут ключевыми участниками экосистемы CBDC" и из всех сил саботировал внедрение CBDC - это вопрос выживания банковской системы в текущем виде хотя бы в среднесрочной перспективе.
Значительно раньше квантовых компов по банковской системе в части стран нанесёт удар CBDC.
В целом - да. Но, видите ли в чём дело, та "единственно верная" точка зрения на эту ситуацию, которую навязывали во время ковида, ровно так же была совершенной политотой и не содержала в себе ничего фундаментально научного и никакой истины. Поэтому данный доклад полезен и показателен - он работает в противовес на том же поле, что и предыдущая "истина о ковиде".
Ценность его не в том, какую конкретно позицию он поддерживает, а в том, что чуть больше людей осознает, что всё это было и есть - политота.
Я не юрист, так что могу ошибаться, но из того, что попадалось в статьях - тупо подвели под "длящееся преступление" ситуации с постами/лайками/донатами совершёнными в прошлом (когда они не нарушали закон). Старые посты, например, чтобы они не являлись "длящимся преступлением", нужно удалять после выхода новых законов, по которым эти посты начинают считаться неприемлемыми, а если ты не уследил за новыми законами или не имеешь технической возможности удалить, то ты уже внезапно преступник. С лайками - вообще безумие, кто вообще может помнить что и где он когда-то лайкал.
Это правда. Но если утекает в одном месте это же не повод не затыкать утечку из других. Чем из большего количества мест течёт, тем больше данных получится собрать, объединить, сделать их более точными и детальными - и всё это однозначно работает против нас. Так что вполне разумно хотя бы уменьшать масштаб проблемы насколько это возможно сделать самостоятельно, нежели поднять лапки и сдаться.
Вы же понимаете, что проводите аналогию между тем, чтобы скрыться с места преступления создавая этим препятствия расследованию и тем, чтобы добровольно и круглосуточно докладывать товарищу майору о всех своих передвижениях, покупках, разговорах и половых актах? Всем есть что скрывать - это обычно называется тайна частной жизни, тайна переписки, банковская тайна и т.п. - причём про всё это даже есть статьи в УК и ГК РФ. Более того, речь ведь даже не про товарища майора, а про слив данных посторонним бизнесам вроде Вашего провайдера или упомянутой ранее кафешки.
Тема "мне нечего скрывать" в целом уже многократно обсуждена, все доводы за и против известны, и очевидно является банальной провокацией со стороны тех, кто хочет всё знать про других - условно того товарища майора. Не надо повторять эту глупость, если, конечно, Вы не эксгибиционист и не товарищ майор.
Это тоже глупость. Во-первых уже сегодня VPN используется настолько массово, что это абсолютно нереально сделать. А во-вторых - по какому конкретно делу они начнут обходить всех пользователей VPN? По каждому открытому делу без явных подозреваемых? Это же просто смешно.
Объяснение очень простое: недоверие властям.
По большому счёту - никаким, но особенно - своей страны, в какой бы стране Вы не жили. Власти не действуют в интересах большинства собственного населения (может не везде, может в каких-то странах это не так, но мне о таких неизвестно). Актуальная политическая повесточка (и западная и в РФ) периодически изменяется, плюс возникла практика наказания за действия совершённые в прошлом, до возникновения актуальной повестки/законов - причём и в РФ и на западе, что характерно. Поэтому даже не будучи преступником и ничего не нарушая сегодня - завтра можно неожиданно для себя самого оказаться преступником, причём за что-то совершенно безобидное и непредсказуемое: лайки, смайлики… И это не выдумки и не теория заговоров - это наша сегодняшная реальность.
Помимо недоверия властям ещё есть дополнительный фактор: крайне слабая информационная безопасность абсолютно всего. Все (включая кафешку, через WiFi которой вы что-то гуглили) собирают любые им доступные данные обо всём о чём только возможно, а потом эти данные продаются, воруются и взламываются (после чего или продаются или выкладываются в общий доступ бесплатно). А покупает их кто? Правильно, мошенники всех мастей. А зачем? Правильно, чтобы использовать эти данные против Вас чтобы что-то с Вас поиметь.
В таких условиях чем меньше о Вас знают те, кто может за Вами прийти с целью что-то отобрать - будь то бизнес, деньги или свободу, - тем лучше. Поэтому, да, VPN это то, что нужно использовать везде и всегда просто по умолчанию - не для обхода каких-то конкретных ограничений, а для того, чтобы минимизировать доступную посторонним (и потенциально враждебным) людям информацию о себе.
Вы знаете, с одной стороны Вы абсолютно правы - это звучит дико. С другой - мы все видели, что и как происходило, это уже исторические факты которые глупо игнорировать. С третьей, так уж случилось, что я как раз член правления нашего кооперативного дома, и хорошо знаком с задачей уговаривания жильцов прийти к единому мнению… и единственный механизм, который реально работает в таких ситуациях - это шантаж и угрозы (т.е. запугивание). Скорее всего ещё неплохо работает подкуп, но на практике пока не было возможности это проверить. Полагаю, у кого-то нашлось достаточно грязи на всех ключевых фигурантов либо достаточно средств для подкупа, и невозможное резко стало возможным.
Глобалисты. И практика показала, что хоть у них действительно была в тот момент невероятная власть, но даже её не хватило чтобы в полном объёме реализовать их задумки. А второго шанса у них уже не будет.
Всё верно.
В том-то и дело, что, внезапно, каким-то невероятным образом хаоса не возникло, наоборот, абсолютное большинство стран и крупных компаний начали делать одно и то же. А по логике должен был возникнуть именно хаос. Именно поэтому применение Бритвы Оккама и приводит к выводу, что всё это было неплохо организовано, т.е. всё-таки за этим стояла чья-то конкретная воля.
По WASM это не просто разговоры, я лично видел проекты и на Go и на Rust (но, скорее всего, похожие есть и на других языках), которые позволяют писать фронт на этих языках. Пока не появляется желание быстро-дёшево подключить какой-нибудь привычный UI виджет (банальный выпадающий список с type-ahead результатами или удобный календарик) это всё даже неплохо работает. Но в этот момент ты выясняешь, что либо тебе надо реализовать такой виджет самостоятельно с нуля на этом языке, либо добавлять в проект JS плюс решать проблему как объяснить этому конкретному WASM-движку что какой-то кусочек DOM будет обновляться не им а сторонней JS-библиотекой и решать вопросы взаимодействия/синхронизации между ними. И это совершенно не тот объём работы (и времени на него), который бизнес считает приемлемым сегодня для решения такого рода задач.
Ну, на мой взгляд (очень издалека, я полноценно фронт не писал уже много лет) похоже на то, что TS принципиально проблему разработки фронта не решил, хоть с ним и стало явно лучше. У JS шансов её решить нет в принципе - всё, что из него можно было выжать уже давно выжато. Так что сейчас всё выглядит так, что надежда осталась только на WASM. Но написание полноценного фронта целиком на WASM сегодня упирается в то, что на JS уже написана тьма виджетов/компонентов/библиотек без которых современный фронт сделать сложно, использовать их параллельно с WASM не очень хочется потому что портит всю идею (да и технические сложности при таком подходе тоже наблюдаются), а шансы переписать всё реально полезное и нужное с JS на WASM пока выглядят туманными. Вполне возможно, что если кто-то сделает реально хорошую и обширную библиотеку(и) UI-компонентов на WASM, то это станет game changer для фронтенд-разработки.
Безусловно, в бигтехе есть R&D отделы в которых заниматься такими исследованиями вполне нормально. Но здесь в обсуждении речь шла о вполне обычных задачах обычных компаний. Эти задачи довольно часто тоже содержат в себе элементы с высокой неопределённостью, которые требуется исследовать перед тем как садиться писать код в продакшн. И вот в таких компаниях и на таких задачах нет возможности сказать проджект-менеджеру или тимлиду "может сделаю за пару дней а может займёт год, всё, я пошёл работать, и не дёргайте меня в ближайший год больше". Поэтому от разработчика требуется итеративно (раз в несколько дней) обновлять статус (какие перспективы и варианты уже понятны, что планирует исследовать следующим) и оценку (сколько времени займёт следующий этап и/или всё в целом) - чтобы бизнес имел возможность в любой момент принять решение нужно ли продолжать это исследование или оно стало неприемлемо дорогим, и нужно ли делать задачу одним из уже найденных подходов или лучше отменить всю задачу вообще.
Ну, условно, на бэке тоже одна и та же платформа - линух. Но никаких тенденций в эту сторону не наблюдается.
В целом, идея описывать шаблоны на основном языке разработки (если я правильно понял куда Вы клоните в статье) не нова, и вполне жизнеспособна. Но и пользу от синтаксического сахара не стоит недооценивать. Просто в качестве сахара иногда может выступать удачный API вспомогательной библиотечки-хелпера, с помощью которой и на основном языке можно сделать приемлемо выглядящий DSL.
На фронте, безусловно, всё ещё творится полная порнография. Но единый инструмент - это тоже перебор. Посмотрите на бэк, или на нативные десктопные приложения - там нет такого мельтешения технологий и фреймворков как на фронте, да, есть некоторая сменяемость языков, но в целом пока никаких признаков того, что всё текущее разнообразие заменит единый инструмент - потому что задачи всё-таки несколько отличаются, и под разные задачи нужны разные инструменты. Крайне маловероятно, что на весь фронт, в отличие от бэка, задача ровно одна и её идеально решит единый инструмент. Мобилки в этом плане действительно отличаются, но там причина не в том, что единый инструмент решает все вопросы, а в том, что вся экосистема достаточно сильно контролируется одной (или второй) компанией, плюс оно всё-таки заметно моложе и веба и тем более десктопа.
А где Вы увидели конфликт между этими вопросами? В моём подходе часть стран запретит перелёты, часть введёт карантин (хочется верить, что настоящий, а не иллюзию для галочки) для прилетевших, часть не станет вводить ограничения - в зависимости от оценок рисков каждого варианта для конкретной страны. Мне всё ещё кажется, что в плане выживания популяции в целом - это вполне здраво и уж точно лучше того театра безопасности, который мы наблюдали в ковид.
Кому-то что-то показалось. И он решил, что вправе потребовать, чтобы кто-то другой "прогнулся". Так происходящее описывается намного корректнее.
Никаких объективных оснований для этого не было: и "проблема" очень сильно похожа на натягивание совы на глобус, и выдвинувший требование не являлся непосредственным начальником или официальным экспертом по этому вопросу, и технически никакой пользы от переименования не было.
По сути, посторонний чувак предъявил левую претензию по вопросу, который его не касается. Единственное, что тут необычно - это то, что у этого постороннего чувака внезапно в руках оказалось столько власти в данном комитете, чтобы иметь возможность устранять тех, кто имеет наглость с ним не соглашаться!
В общем и целом всё это сильно напоминает действия аналогичных посторонних чуваков, которые набегали в посторонние проекты с требованиями переименовывать master в main, добавлять мутные CoC.md и т.п. Этим действиям нет оправдания, в них нет технического смысла или пользы для общества, это всё просто чья-то политика и не надо это их поведение даже пытаться оправдывать.
Главных веток в гите тоже нет. Например, когда рядом с main есть ветка prod - кто из них "главнее"? Или когда у продукта есть несколько одновременно поддерживаемых и развиваемых версий вроде v2 и v3 с соответствующими ветками (плюс к main, разумеется) - кто из них главнее? А в подходе gitflow ветка main вообще мало используется, а роль "основной" по сути играет ветка develop.
Да, в зависимости от подхода к веткам на конкретном проекте где-то main и может отражать суть лучше master - но суть же не в этом, а в том, что от этих переименований нет пользы для проекта, особенно когда это делается насильно, везде и без учёта специфики конкретного проекта.
А то, что делаете Вы - это стокгольмский синдром. В нормальном мире те, кому не нравится слово "master" просто не использовали бы его в своих проектах. Возможно, попытались бы убедить других переименовать его, если в конкретном проекте другое имя лучше отражало бы суть ветки. А текущий подход "я решил что меня оскорбляет слово X поэтому весь мир должен перестать его использовать" - это безумие, у нас так вообще все слова закончатся. Но на самом деле это просто политика, кто-то с кучей власти и денег зачем-то решил взрастить группу маргиналов дав им возможность навязывать почти всему миру несколько безумных идей (и это не первая такая ситуация, раньше этот подход отрабатывался на "зелёных" и "террористах"). У всех есть своя правда, но нет права силой навязывать эту правду всем остальным. Поэтому, не делайте так - не оправдывайте тех, кто Вам насилует мозги.
Судя по всему, Вы - математик: даёте точный, но совершенно бесполезный ответ.
На практике у нас и величины не случайные, и точность оценки маленьких задач возникает не только потому что они лучше и подробнее поставлены (нередко всё совсем наоборот, из-за того что задача маленькая она вообще детально не описывается помимо того что в названии задачи), и в случае "задачи на год" типичное отклонение будет не 100% (которое Вам кажется маловероятным) а все 200% (потому что сроки в среднем срываются в 3 раза), и нет, срыв сроков по маленьким задачам - это исключение, а не "обычное дело".
То, что Вы описали - это теория. Причём базирующаяся на неверных входных данных, что ещё больше всё портит. А я описываю как оно работает на практике. И на практике единственный работающий способ получить достаточно точную оценку сколько времени займёт реализация функционала размером примерно на 3-4 человеко-месяца - это декомпозировать его на задачи размером от 1 часа до 3 дней, сложить сроки задач и умножить на корректирующий коэффициент для конкретной команды, причём чем меньше будут задачи тем точнее получится финальная оценка.
Я даже допускаю, что если понять фразу "чем меньше таска" буквально (как математик) и попытаться дробить на задачи не в интервале 1 час - 3 дня (со средним размером задачи примерно 0.5-1 дня) а на задачи в интервале 1-60 минут (со средним размером задачи в 23 минуты), то мы действительно получим описанный Вами результат в виде сильного уменьшения точности оценок. Но на практике так всё-равно никто не делает, потому что глупость такого подхода очевидна всем.
Не похоже это на правду, совсем. У него на сайте выложены документы показывающие его участие между 2013 и 2016, никакого ChatGPT тогда не было. И да, раз у него штук 20 личных репо на гитхабе с разными проектами, то его определённо можно называть программистом. В общем, поменьше верьте анонимам на реддите и побольше делайте факт-чекинг самостоятельно.
Это всё вполне логично и верно. Разве что я не вижу ничего "страшного" в том, что правда у каждого своя и одного простого ответа на все вопросы не существует - вне области точных наук так было всегда и рассчитывать на иное столь же наивно, как и делить всё на чёрное и белое.
Проблема того, как проходил ковид в другом. Кто-то сумел навязать почти всему миру одну единственную точку зрения, и затыкал рты всем остальным (может и не "более правым", но как минимум "тоже правым") не имея на то никаких объективных оснований. Его действия нанесли гигантский ущерб и здоровью и экономике всего мира. Более того, даже в процессе ковида по некоторым ситуациям многим людям с критическим мышлением было вполне очевидно, что предпринятые меры совершенно неадекватны реальной угрозе. И вот за это было бы неплохо, чтобы кто-то таки ответил "по всей строгости". Чтобы другим неповадно было в следующий раз. А ещё важнее не наказать кого-то, а учесть все ошибки и в следующий раз в принципе не допустить навязывания настолько разрушительных и при этом малоэффективных мер всему миру.
На мой взгляд, человечество сильно как раз разнообразием. Именно благодаря тому, что мы все разные, у человечества в целом хорошие шансы выжить в большинстве катастроф. И в этом плане как раз будет крайне вредно если все станут делать одно и то же (например, колоть одну и ту же вакцину, какой бы полезной она в этот момент не казалась - потому что ошибка в этой вакцине может причинить намного больше вреда, чем вирус, против которого она была разработана). Так что да, у разных специалистов будут разные идеи как бороться с вирусом, и, на мой взгляд, это правильно: нужно чтобы разные страны/города следовали разным рекомендациям разных специалистов, причём учитывая специфику конкретных стран/городов/etc. а не делали все одно и то же - так наши шансы будут намного выше.