А где будет находиться объект, куда указывает "глупый" указатель? В куче не может - цель уйти от кучи. На стеке может только в aligned_storage, а из этого вытекают разные вопросы, которые попытался решить в статье.
В общем случае - что в куче, что на стеке, под отдельной переменной или в хранилище. Меня заявления смутили во вводной части с причиной использования именно unique_ptr (а не вообще любого указателя), слайсингом (который иногда может быть приемлем) и "только в куче":
Одна из самых популярных причин использования этого указателя - динамический полиморфизм. Если мы на этапе компиляции не "знаем", объект какого именно класса будем создавать в некой точке выполнения, то из-за этого не знаем значение, на которое надо увеличивать указатель стека, а значит такой объект на стеке создавать нельзя - можем создать его только в куче.
А хранилищем не обязательно должно быть aligned_storage, можно хоть самому написать: например, тупо взять на стеке char[N] и хранить там разнородные объекты, используя placement new, арифметику указателей, ну и дополнительный реестр.
К сожалению не понял, что имеется в виду под "нельзя переиспользовать объект"
Я имел в виду shared_ptr / weak_ptr - оба можно копировать и предоставлять множественный доступ к объекту. Объект будет жить, пока есть хотя бы одна копия shared указателя на него. А ваш указатель, если я правильно понял, как и unique_ptr, надо либо передавать через move, отбирая его у предыдущего владельца, либо вкладывать в другой объект (поле класса или контейнер) и шарить уже его.
sp::static_ptr p; // ... в p лежит объект TObj obj{std::move(*p)};
Теперь я не понял :) почему в p лежит объект? Указатель ведь. И что остается в p на месте объекта после move? Так понимаю, что мусор и p больше использовать нельзя. Еще тут Вы вовсе отказываетесь от своего указателя: извлекаете объект и используете напрямую, возвращаясь к старому управлению его жизненным циклом.
Одна из самых популярных причин использования этого указателя - динамический полиморфизм. Если мы на этапе компиляции не "знаем", объект какого именно класса будем создавать в некой точке выполнения, то из-за этого не знаем значение, на которое надо увеличивать указатель стека, а значит такой объект на стеке создавать нельзя - можем создать его только в куче.
Важными причинами использования умных указателей я бы назвал решение проблемы утечек памяти и управление совместным доступом к объекту. А в описанном случае с выделением памяти и семейством классов (slicing problem), сгодится и "глупый" си-шный указатель, разве нет? И, кстати, вовсе необязательно на кучу, сам концепт вашего указателя это подтверждает.
Сделать свой умный указатель/аллокатор/контейнер - интересная задачка, но получился аналог только одного из трех классических - unique_ptr, что, конечно, и решает проблему утечек, и стеком вместо кучи дает оперировать, но не позволяет даже просто переиспользовать объект без полной передачи или вложения в другой объект. Вы не рассматривали вариант написать/взять стековый аллокатор/делитер для использования с уже существующими указателями?
Это если одновременно и условия ипотеки не изменятся, и зарплата подрастет. А вот если зарплата индексируется, например, как у некоторых контор, раз в 2-3 года и не более, чем на 1%, плюс какое-нибудь "в несправедливых условиях, созданных недружественными странами, необходимо выровнять ставки, чтобы помочь экономике", плюс риски нестабильной ситуации - я бы и 10, и 20 раз подумал.
Спасибо, конечно, за статью, но наскоро пробежался по ссылкам и далеко не все результаты исследований кажутся достоверными. А в вводной части и вовсе классическая манипуляция из последовательности "все знают, что [правда] => все знают, что [правда] => все знают, что [правдоподобное утверждение]".
Где-то выборка крайне мала (за несколькими исключениями): 17, 24, 30 человек - это ни о чем, на таких размерах пусть и можно формально заявить p<=0.05, но вероятность банального совпадения или постороннего влияния еще слишком высока. А их ведь еще и на группы надо делить.
Где-то в результатах исследования авторы прямо пишут, что необходимы дополнительные. Вот, например, про размер гиппокампа (https://bjsm.bmj.com/content/49/4/248): всего 86 участников, увеличение подтверждено, но, во-первых, авторы пишут, что надо еще выяснить, действительно ли повлияло это увеличение на способности, а во-вторых, если я правильно понял, то увеличение левого гиппокампа связывают наоборот с ухудшением (!) обоих параметров. Хотя не уверен, звучит странно.
After accounting for baseline cognitive function and experimental group, increased left hippocampal volume was independently associated with reduced verbal memory and learning performance as indexed by loss after interference
В итоге просто бомбардируете сервер тяжелыми запросами, да еще и подгоняете интервалы под нюансы реализации бэка: таких глубоких сведений у фронта быть не должно, это слишком жесткая связь за пределами интерфейса. Ну и если сейчас 5 секунд достаточно, то когда-нибудь под нагрузкой их перестанет хватать и решение будет работать со сбоями.
Какие я вижу варианты:
На бэке при получении формы заказа возвращаем ошибку "интервал не существует", на фронте при ее получении запрашиваем интервалы и просим пользователя вернуться и выбрать заново. Минимум запросов и правок, простая логика, не остается тупика, но чуть напрягаем пользователя.
Тяжелый обсчет интервалов по крону? Кладем результат в кеш и отдаем фронту из кеша. Запрашивай хоть каждую секунду. Просто, дешево и быстро. Хорошо дополняет предыдущий вариант, но и само по себе годится.
Неизвестно, когда интервалы обновились, а почему-то все равно надо дергать тяжелый запрос? Делаем еще один эндпоинт, возвращающий дату последнего обновления интервалов. Он дешевый, дергать можно будет часто, а интервалы запрашивать, только если полученная дата свежее, чем на клиенте.
Если на бэке работы не провести, то вот еще как можно выкрутиться на фронте:
Интервалы обновляем однократно перед отправкой формы заказа, а если изменились и выбранные пользователем больше не применимы - выдаем пользователю уведомление и просим еще раз их выставить, показав уже новые. Почти как первый вариант, но без бэка.
В конце концов, можно отслеживать активность пользователя на вкладке с сайтом: движения мыши, клики, нажатия клавиш. Если он надолго ушел, то перестать впустую нагружать сервер, а загрузить интервалы, когда он вернется после перерыва.
Занимательно, но позанудствую: было бы неплохо отделять свойства самого числа от свойств одного из вариантов записи этого числа. Так, например, в восьмеричной системе 89 становится симметричным - 131 и является самому себе зеркальным отражением; в двоичной содержит равное количество нулей и единиц - 0101 1001, а зеркало - какое-то 154 (1001 1010); в римской записи, к сожалению, довольно скучно как в правильном виде - LXXXIX, так и в неправильном - IXC; азбукой морзе тоже ничего особенного - "-.... -..-". Но все это ведь вторично и ничего не говорит о самом числе)
Все-таки прокомментирую, хоть и не новый доклад, потому что вижу много спорных утверждений и выводов.
Прежде всего, доклад для меня выглядит как описание интересного и крутого опыта, но опыта маленькой, почти не растущей компании (https://www.inforegister.ee/ru/11885355-CODEBORNE-OU), работающей над небольшими проектами. Причем, это не продуктовая разработка, а аутсорс: разработка множества проектов на заказ. И через призму этой единственной роли оценивается вообще вся разработка.
Мир IT можно поделить на startup и enterprise (маленькие, не растующие проекты отбросим, потому что там толком нет активности), требования к разработке у которых сильно разнятся. В стартапе важно с минимальными затратами за кратчайшее время выйти на рынок. Получить MVP и проверить жизнеспособность. Здесь разработчик ценен умением работать быстро, умением работать без ТЗ, умением пообщаться с основателем и клиентами, знанием всех технологий и актуальных деталей проекта, чтобы мочь в любой момент реализовать любую внезапно потребовавшуюся фичу, возможностью всегда быть на связи, потому что людей-то мало, а кризисы случаются, возможностью хоть как-то закрыть совсем непрофильную компетенцию типа составления и подписания договоров или поиска и найма людей в одиночку - опять-таки, людей и денег же мало. Здесь полностью согласен с докладчиком, на ранних этапах проекта фуллстеки идеально вписываются в требования.
В энтерпрайзе же, то бишь уже устоявшемся бизнесе, задачи другие: в первую очередь сохранить то, что уже есть, а потом уже по возможности развиваться дальше с оглядкой на обстановку. Спешка тут может сильно навредить: можно банально не справиться с ростом и развалить всю компанию. Цена ошибок тоже велика: есть, что терять. Отсюда выстраивание процессов разработки: код-ревью, юнит-тесты, авто-тесты, формализованные релизы или CI/CD. Тут от разработчика требуются углубленные знания теории в целом и конкретных технологий в частности (привет, специализация!), чтобы пропускать минимум своих и чужих проблем на прод, умение общаться с коллегами по поводу архитектуры и кодовой базы и поддерживать и менять общее техническое видение продукта (привет, техдир/архитектор!), умение не нарушать процессы, даже если очень хочется.
С ростом проекта приходится управлять инфраструктурой более серьезно: подход "инфраструктура как код" необходим. Здесь уже неизбежно появляется еще одна специализация: admin/sysops/devops, где как называют (хотя девопс все же не совсем то). И высшему руководству уже как-то неохота постоянно общаться с разработчиками по поводу цветов раскраски кнопок -> нужен зам по этом вопросам -> привет, техлид/тимлид/глава отдела! И все актуальнее становится вопрос безопасности: компанию замечают конкуренты и просто нехорошие личности, повышается риск атаки/взлома/утечки и серьезность последствий - появляется безопасник. И поток обращений клиентов растет до неприличных размеров - нужен саппорт. И за конкурентами следить надо, и свою репутацию поддерживать - отдел маркетинга. И размер кодовой базы становится настолько велик, что отдельному разработчику просто не под силу хорошо знать все компоненты проекта и быть в курсе всех изменений - специализация по подпроектам/областям/отделам. И технологий становится много, потому что нет одного универсального языка. И легаси проявляется с устаревшими версиями/фреймворками. И так далее, и так далее.
В скраме есть, как мне кажется, хорошее понятие: T-shaped специалист. Человек, который очень хорошо знает небольшой набор технологий и поменьше разбирается в широком круге других. Отсюда две крайности: когда человек разбирается в огромном количестве вещей, но в каждой из них весьма посредственно, или сосредоточился на узкой области, но достиг в ней больших высот. В докладе подробно пропесочиваются проблемы второго типа, но замазывается главная проблема первого: невозможно быть экспертом сразу во всем. Если ты пишешь на 5-10 языках, то при прочих равных в каждом из них ты будешь слабее того, кто пишет условно на 1-3. Если ты разрабочик, то тестировщик найдет больше багов, чем ты. Админ лучше знает, как настроить сервер/сеть, подтюнить базы и шины данных и т.д. Безопасник найдет больше проблем, качественнее закроет дыры и гораздо лучше справится с грянувшей атакой. Как успевать еще и знания актуальными поддерживать и не на поверхностном уровне? А как скоро бизнес поймет, что с ростом проекта недостаточно компетентные в каждой конкретной области специалисты становятся неприемлемо опасными?
Докладчик, конечно, упоминает об этом и даже предлагает свое определение фуллстек-разработчика: "вы знаете все стеки вашего собственного проекта". Но много вы знаете людей, которые действительно хорошо умеют одновременно, ну например, в php5+php7, python2+python3, bash+powershell, java, c++, js+typescript клиентский и серверный, 1-2 фреймворка на перечисленных языках, Android(java/kotlin), iOS(swift), sql+nosql, пишут пайплайны, могут тонко подтюнить виндовые и линуксовые сервера, настроить сети между несколькими датацентрами, организовать мониторинг zabbix+prometheus, поднять и поддерживать кластеры DB+ELK+RMQ, описать прод и дев инфраструктуру в ansible+terraform, могут провести аудит безопасности и сертифицировать компанию по ISO, а заодно работают 1/2/3 линией техподдержки и лично общаются с клиентами через почту и телефонию, верстают и отправляют почтовые рассылки, делают клиентские и технические аналитические сводки и прогнозы... и я подчеркиваю - хорошо умеют все это делать, потому что даже по словам докладчика все нужно сразу делать хорошо. Давайте даже выкинем все, не относящееся к разработке, оставим только работу с кодом и часть админского шаманства. Мне вот на питоне однажды пришлось писать компонентик строк эдак в тысячу-две, впервые имея дело с этим языком. Уже можно зачесть это как развитую компетенцию в рамках фулстека или все-таки любой мидл-питонист этот код на помойку выкинет?
Описывая "конфликты" между специализациями людей, свой прошлый опыт и даже опыт в Codebourne, докладчик сам называет проблему: нет общения. А если и "крафтсмен" заменить на "разработчик, погруженный в предметную область", то все встает на свои места: специалисты максимально эффективно вносят вклад в продукт, потому что хорошо знают его в целом, применяют свои самые сильные стороны и работают сообща. Точка.
Ну и немного по тексту:
Потом вы берете какой-то новый язык программирования, играетесь с ним пару дней, и после можете так же круто перформить, как вы делали это на Java, например.
Не знаю ни одного языка и ни одного разработчика, который мог бы за пару дней достичь высокого уровня в совершенно новом для себя языке. За пару дней можно синтаксис изучить, базовые типы данных и конструкции, но язык - это и stl, и библиотеки, и сложившиеся практики, и уникальные прблемы, и т.д.
И нас теперь понизили до API-разработчиков.
Очень сильно зависит от предметной области и размаха проекта. Где-то в UI вся суть продукта, а где-то UI - это лишь маленькое окошко в огроменную систему, где и происходит вся магия.
Все доходит до того, что есть разработчик функции X и функции Y, и считается, что мы разные, и мы не общаемся
Кто сказал? Коммуникации жизненно необходимы, будь то внутри команды или между отделами, иначе будет как с пошивом пальто у Аркадия Райкина.
Если мы посмотрим немного в прошлое, то увидим, что в прошлом все программисты были фуллстек-крафстменами
Тогда мир IT был намного-намного меньше.
«Совершенство достигается не тогда, когда вам больше нечего добавить, а когда вам больше нечего убрать».
Мне тоже нравится эта цитата, Микеланджело похожее видел в творчестве: "Я беру камень и отсекаю всё лишнее.". Вот только фулстек - это как раз о том, чтобы напихать всего, да побольше.
Это вас на поддомен pokupki выкидывало? Тоже офигел, когда первый раз заметил - половина ссылок теперь туда ведет, а на старые страницы категорий через текстовый поиск попадать приходится. Поиск с фильтрами, сравнения и цены там пока еще есть, но тоже ищу аналоги: кроме екаталога еще по крупным магазинам брожу - компьютерюниверс, ситилинк и т.д. А вот цены подбирать на маркете однозначно себе дороже, там такой треш теперь попадается со 100% рейтингом, что волосы на голове шевелятся.
О да, самые интересные истории получаются, когда такиие звезды сходятся… из забавных мелочей вспомнилось: у меня когда-то в древности был проект на поддержке с рассылкой ежемесячных отчетов. В один Новый Год между отчетами пропала целая неделя. Расследование показало, что изначально в проект вкралась ошибка с определением принадлежности рубежной недели к уходящему или к грядущему году. Несколько лет эта бомбочка мирно тикала и накапливала сдвиг, после чего снесла неделю из отчетов.
А, хорошо, значит, мне показалось :)
Но с короткоживущим токеном я все равно вижу потенциальный риск в реализации: сам токен может быть шифрованным контейнером, содержащим, например, ID пользователя и дату создания. Тогда можем получить старый токен, расшифровать, проверить ID и дату, но тоже ошибочно аутентифицировать пользователя. Поэтому как раз хотел подчеркнуть, что стоит избавиться от информации о логине в самом токене.
В дополнение к комменту от mals: мне кажется, вы даже сейчас в статье не то называете главной проблемой. Опасно то, что токен генерируется повторяемо (!) из логина. У вас есть для этого особое требование?
Вечный токен — конечно, риск, но на описанную ситуацию вы бы нарвались даже с короткоживущим токеном, достаточно уложиться в срок его жизни.
UUID вместо порядковых ID помог бы с конкретным случаем, но что, если токен пользователя скомпрометирован? Как его заменить? Или, что еще хуже, скомпрометирован алгоритм получения токена из логина?
ИМХО более безопасным подходом будет создание случайного токена, а затем связывание его с пользователем. Получаем возможность создавать множество токенов для пользователя и легко их отзывать, не вкладываем никакой информации о логине в токен, можем даже спокойно оставить инкрементный ID.
Немножко поковырялся в политике протона. Заявления от него самого я так и не нашел, только цитаты в журналистских статьях.
Содержимое писем (конфиденциальность) и сведения о владельце ящика (анонимность) остаются сокрытыми. Из статьи по ссылке:
Proton declined to comment on specifics of the email, saying that its encryption made it impossible to "access or verify the contents of the message."
"However, we are able to see when the message was sent, and we can confirm that the message in question was sent after the plane was redirected," the Swiss company said in a statement.
В privacy policy же протон открыто указывает, какая информация ему все-таки доступна:
Account activity: Due to limitations of the SMTP protocol, we have access to the following email metadata: sender and recipient email addresses, the IP address incoming messages originated from, message subject, and message sent and received times. We do NOT have access to encrypted message content but unencrypted messages sent from external providers to ProtonMail are scanned for Spam and Viruses to pursue the legitimate interest of the protection of our users. We also have access to the following records of account activity: number of messages sent, amount of storage space used, total number of messages, last login time.
А вот факт раскрытия таймстемпа действительно спорный и, как мне кажется, зависит от того, считать ли его конфиденциальной информацией отправителя. К тому же, письмо со стороны получателя уже опубликовано. А сокрытия самого факта передачи письма протон не гарантирует, насколько я понял.
We will only disclose the limited user data we possess if we are instructed to do so by a fully binding request coming from the competent Swiss authorities (legal obligation). While we may comply with electronically delivered notices (see exceptions below), the disclosed data can only be used in court after we have received an original copy of the court order by registered post or in person, and provide a formal response.
Последний вопрос интереса ради решил разбирать без напрашивающегося частотного анализа, вручную: попросту читая текст и выискивая короткие слова и закономерности. Например, пара «так» и «как»,"*-либо". Держал параллельно исходник в нижнем регистре и результат с заменами в верхнем; перегонял прямо на странице джаваскриптом.
Ушло около 20 минут на полную расшифровку, получил море удовольствия от задачи.
В чем ценность статьи? Если выкинуть детское описание известных каждому веб-разработчику уязвимостей, останется вводный абзац, заключение и упоминание iframe — еще одной популярной технологии. Ни подробностей, ни примечательных техник.
Те, кто против, просто не пользуются. Предлагаешь услугу — имеешь право выставлять требования, тут глупо возмущаться.
Дело в том, что по законопроекту все юр. лица будут обязаны так поступать под угрозой крупных штрафов. И каждый публичный Wifi будет доступен только с паспортом или телефоном — не останется ни одного открытого.
Потом нужно будет запрещать почтовые ящики (физические). А то как это так — можно анонимно отправить бумажное письмо! Только лично в филиале, с паспортом. А там и электронку перевести исключительно на одобренные государством сервисы.
*thinking* действительно, незачем. Без аллокатора недостаточно, с аллокатором не нужно - только если сам конкретный тип требует.
В общем случае - что в куче, что на стеке, под отдельной переменной или в хранилище. Меня заявления смутили во вводной части с причиной использования именно unique_ptr (а не вообще любого указателя), слайсингом (который иногда может быть приемлем) и "только в куче":
А хранилищем не обязательно должно быть aligned_storage, можно хоть самому написать: например, тупо взять на стеке char[N] и хранить там разнородные объекты, используя placement new, арифметику указателей, ну и дополнительный реестр.
Я имел в виду shared_ptr / weak_ptr - оба можно копировать и предоставлять множественный доступ к объекту. Объект будет жить, пока есть хотя бы одна копия shared указателя на него. А ваш указатель, если я правильно понял, как и unique_ptr, надо либо передавать через move, отбирая его у предыдущего владельца, либо вкладывать в другой объект (поле класса или контейнер) и шарить уже его.
Теперь я не понял :) почему в p лежит объект? Указатель ведь. И что остается в p на месте объекта после move? Так понимаю, что мусор и p больше использовать нельзя. Еще тут Вы вовсе отказываетесь от своего указателя: извлекаете объект и используете напрямую, возвращаясь к старому управлению его жизненным циклом.
Важными причинами использования умных указателей я бы назвал решение проблемы утечек памяти и управление совместным доступом к объекту. А в описанном случае с выделением памяти и семейством классов (slicing problem), сгодится и "глупый" си-шный указатель, разве нет? И, кстати, вовсе необязательно на кучу, сам концепт вашего указателя это подтверждает.
Сделать свой умный указатель/аллокатор/контейнер - интересная задачка, но получился аналог только одного из трех классических - unique_ptr, что, конечно, и решает проблему утечек, и стеком вместо кучи дает оперировать, но не позволяет даже просто переиспользовать объект без полной передачи или вложения в другой объект. Вы не рассматривали вариант написать/взять стековый аллокатор/делитер для использования с уже существующими указателями?
Это если одновременно и условия ипотеки не изменятся, и зарплата подрастет. А вот если зарплата индексируется, например, как у некоторых контор, раз в 2-3 года и не более, чем на 1%, плюс какое-нибудь "в несправедливых условиях, созданных недружественными странами, необходимо выровнять ставки, чтобы помочь экономике", плюс риски нестабильной ситуации - я бы и 10, и 20 раз подумал.
Спасибо, конечно, за статью, но наскоро пробежался по ссылкам и далеко не все результаты исследований кажутся достоверными.
А в вводной части и вовсе классическая манипуляция из последовательности "все знают, что [правда] => все знают, что [правда] => все знают, что [правдоподобное утверждение]".
Где-то выборка крайне мала (за несколькими исключениями): 17, 24, 30 человек - это ни о чем, на таких размерах пусть и можно формально заявить p<=0.05, но вероятность банального совпадения или постороннего влияния еще слишком высока. А их ведь еще и на группы надо делить.
Где-то в результатах исследования авторы прямо пишут, что необходимы дополнительные. Вот, например, про размер гиппокампа (https://bjsm.bmj.com/content/49/4/248): всего 86 участников, увеличение подтверждено, но, во-первых, авторы пишут, что надо еще выяснить, действительно ли повлияло это увеличение на способности, а во-вторых, если я правильно понял, то увеличение левого гиппокампа связывают наоборот с ухудшением (!) обоих параметров. Хотя не уверен, звучит странно.
Или сон (https://www.sciencedirect.com/science/article/abs/pii/S1755296611000317?utm_medium=sw&utm_source=link&utm_campaign=improve-cognitive-function-exercise): значительный эффект, 3к участников, но результаты получены со слов самих людей и авторы говорят о необходимости точных исследований
А готовые решения искали? Чем не подошли? Для PHPUnit, например, есть https://github.com/redaxmedia/phpunit-provider-autoloader, который и структуру зафиксирует (соглашения - дело не очень надежное), и избавит от копипасты.
В итоге просто бомбардируете сервер тяжелыми запросами, да еще и подгоняете интервалы под нюансы реализации бэка: таких глубоких сведений у фронта быть не должно, это слишком жесткая связь за пределами интерфейса. Ну и если сейчас 5 секунд достаточно, то когда-нибудь под нагрузкой их перестанет хватать и решение будет работать со сбоями.
Какие я вижу варианты:
На бэке при получении формы заказа возвращаем ошибку "интервал не существует", на фронте при ее получении запрашиваем интервалы и просим пользователя вернуться и выбрать заново. Минимум запросов и правок, простая логика, не остается тупика, но чуть напрягаем пользователя.
Тяжелый обсчет интервалов по крону? Кладем результат в кеш и отдаем фронту из кеша. Запрашивай хоть каждую секунду. Просто, дешево и быстро. Хорошо дополняет предыдущий вариант, но и само по себе годится.
Неизвестно, когда интервалы обновились, а почему-то все равно надо дергать тяжелый запрос? Делаем еще один эндпоинт, возвращающий дату последнего обновления интервалов. Он дешевый, дергать можно будет часто, а интервалы запрашивать, только если полученная дата свежее, чем на клиенте.
Если на бэке работы не провести, то вот еще как можно выкрутиться на фронте:
Интервалы обновляем однократно перед отправкой формы заказа, а если изменились и выбранные пользователем больше не применимы - выдаем пользователю уведомление и просим еще раз их выставить, показав уже новые. Почти как первый вариант, но без бэка.
В конце концов, можно отслеживать активность пользователя на вкладке с сайтом: движения мыши, клики, нажатия клавиш. Если он надолго ушел, то перестать впустую нагружать сервер, а загрузить интервалы, когда он вернется после перерыва.
Занимательно, но позанудствую: было бы неплохо отделять свойства самого числа от свойств одного из вариантов записи этого числа. Так, например, в восьмеричной системе 89 становится симметричным - 131 и является самому себе зеркальным отражением; в двоичной содержит равное количество нулей и единиц - 0101 1001, а зеркало - какое-то 154 (1001 1010); в римской записи, к сожалению, довольно скучно как в правильном виде - LXXXIX, так и в неправильном - IXC; азбукой морзе тоже ничего особенного - "-.... -..-". Но все это ведь вторично и ничего не говорит о самом числе)
Все-таки прокомментирую, хоть и не новый доклад, потому что вижу много спорных утверждений и выводов.
Прежде всего, доклад для меня выглядит как описание интересного и крутого опыта, но опыта маленькой, почти не растущей компании (https://www.inforegister.ee/ru/11885355-CODEBORNE-OU), работающей над небольшими проектами. Причем, это не продуктовая разработка, а аутсорс: разработка множества проектов на заказ. И через призму этой единственной роли оценивается вообще вся разработка.
Мир IT можно поделить на startup и enterprise (маленькие, не растующие проекты отбросим, потому что там толком нет активности), требования к разработке у которых сильно разнятся. В стартапе важно с минимальными затратами за кратчайшее время выйти на рынок. Получить MVP и проверить жизнеспособность. Здесь разработчик ценен умением работать быстро, умением работать без ТЗ, умением пообщаться с основателем и клиентами, знанием всех технологий и актуальных деталей проекта, чтобы мочь в любой момент реализовать любую внезапно потребовавшуюся фичу, возможностью всегда быть на связи, потому что людей-то мало, а кризисы случаются, возможностью хоть как-то закрыть совсем непрофильную компетенцию типа составления и подписания договоров или поиска и найма людей в одиночку - опять-таки, людей и денег же мало. Здесь полностью согласен с докладчиком, на ранних этапах проекта фуллстеки идеально вписываются в требования.
В энтерпрайзе же, то бишь уже устоявшемся бизнесе, задачи другие: в первую очередь сохранить то, что уже есть, а потом уже по возможности развиваться дальше с оглядкой на обстановку. Спешка тут может сильно навредить: можно банально не справиться с ростом и развалить всю компанию. Цена ошибок тоже велика: есть, что терять. Отсюда выстраивание процессов разработки: код-ревью, юнит-тесты, авто-тесты, формализованные релизы или CI/CD. Тут от разработчика требуются углубленные знания теории в целом и конкретных технологий в частности (привет, специализация!), чтобы пропускать минимум своих и чужих проблем на прод, умение общаться с коллегами по поводу архитектуры и кодовой базы и поддерживать и менять общее техническое видение продукта (привет, техдир/архитектор!), умение не нарушать процессы, даже если очень хочется.
С ростом проекта приходится управлять инфраструктурой более серьезно: подход "инфраструктура как код" необходим. Здесь уже неизбежно появляется еще одна специализация: admin/sysops/devops, где как называют (хотя девопс все же не совсем то). И высшему руководству уже как-то неохота постоянно общаться с разработчиками по поводу цветов раскраски кнопок -> нужен зам по этом вопросам -> привет, техлид/тимлид/глава отдела! И все актуальнее становится вопрос безопасности: компанию замечают конкуренты и просто нехорошие личности, повышается риск атаки/взлома/утечки и серьезность последствий - появляется безопасник. И поток обращений клиентов растет до неприличных размеров - нужен саппорт. И за конкурентами следить надо, и свою репутацию поддерживать - отдел маркетинга. И размер кодовой базы становится настолько велик, что отдельному разработчику просто не под силу хорошо знать все компоненты проекта и быть в курсе всех изменений - специализация по подпроектам/областям/отделам. И технологий становится много, потому что нет одного универсального языка. И легаси проявляется с устаревшими версиями/фреймворками. И так далее, и так далее.
В скраме есть, как мне кажется, хорошее понятие: T-shaped специалист. Человек, который очень хорошо знает небольшой набор технологий и поменьше разбирается в широком круге других. Отсюда две крайности: когда человек разбирается в огромном количестве вещей, но в каждой из них весьма посредственно, или сосредоточился на узкой области, но достиг в ней больших высот. В докладе подробно пропесочиваются проблемы второго типа, но замазывается главная проблема первого: невозможно быть экспертом сразу во всем. Если ты пишешь на 5-10 языках, то при прочих равных в каждом из них ты будешь слабее того, кто пишет условно на 1-3. Если ты разрабочик, то тестировщик найдет больше багов, чем ты. Админ лучше знает, как настроить сервер/сеть, подтюнить базы и шины данных и т.д. Безопасник найдет больше проблем, качественнее закроет дыры и гораздо лучше справится с грянувшей атакой. Как успевать еще и знания актуальными поддерживать и не на поверхностном уровне? А как скоро бизнес поймет, что с ростом проекта недостаточно компетентные в каждой конкретной области специалисты становятся неприемлемо опасными?
Докладчик, конечно, упоминает об этом и даже предлагает свое определение фуллстек-разработчика: "вы знаете все стеки вашего собственного проекта". Но много вы знаете людей, которые действительно хорошо умеют одновременно, ну например, в php5+php7, python2+python3, bash+powershell, java, c++, js+typescript клиентский и серверный, 1-2 фреймворка на перечисленных языках, Android(java/kotlin), iOS(swift), sql+nosql, пишут пайплайны, могут тонко подтюнить виндовые и линуксовые сервера, настроить сети между несколькими датацентрами, организовать мониторинг zabbix+prometheus, поднять и поддерживать кластеры DB+ELK+RMQ, описать прод и дев инфраструктуру в ansible+terraform, могут провести аудит безопасности и сертифицировать компанию по ISO, а заодно работают 1/2/3 линией техподдержки и лично общаются с клиентами через почту и телефонию, верстают и отправляют почтовые рассылки, делают клиентские и технические аналитические сводки и прогнозы... и я подчеркиваю - хорошо умеют все это делать, потому что даже по словам докладчика все нужно сразу делать хорошо. Давайте даже выкинем все, не относящееся к разработке, оставим только работу с кодом и часть админского шаманства. Мне вот на питоне однажды пришлось писать компонентик строк эдак в тысячу-две, впервые имея дело с этим языком. Уже можно зачесть это как развитую компетенцию в рамках фулстека или все-таки любой мидл-питонист этот код на помойку выкинет?
Описывая "конфликты" между специализациями людей, свой прошлый опыт и даже опыт в Codebourne, докладчик сам называет проблему: нет общения. А если и "крафтсмен" заменить на "разработчик, погруженный в предметную область", то все встает на свои места: специалисты максимально эффективно вносят вклад в продукт, потому что хорошо знают его в целом, применяют свои самые сильные стороны и работают сообща. Точка.
Ну и немного по тексту:
Не знаю ни одного языка и ни одного разработчика, который мог бы за пару дней достичь высокого уровня в совершенно новом для себя языке. За пару дней можно синтаксис изучить, базовые типы данных и конструкции, но язык - это и stl, и библиотеки, и сложившиеся практики, и уникальные прблемы, и т.д.
Очень сильно зависит от предметной области и размаха проекта. Где-то в UI вся суть продукта, а где-то UI - это лишь маленькое окошко в огроменную систему, где и происходит вся магия.
Кто сказал? Коммуникации жизненно необходимы, будь то внутри команды или между отделами, иначе будет как с пошивом пальто у Аркадия Райкина.
Тогда мир IT был намного-намного меньше.
Мне тоже нравится эта цитата, Микеланджело похожее видел в творчестве: "Я беру камень и отсекаю всё лишнее.". Вот только фулстек - это как раз о том, чтобы напихать всего, да побольше.
Это вас на поддомен pokupki выкидывало? Тоже офигел, когда первый раз заметил - половина ссылок теперь туда ведет, а на старые страницы категорий через текстовый поиск попадать приходится. Поиск с фильтрами, сравнения и цены там пока еще есть, но тоже ищу аналоги: кроме екаталога еще по крупным магазинам брожу - компьютерюниверс, ситилинк и т.д. А вот цены подбирать на маркете однозначно себе дороже, там такой треш теперь попадается со 100% рейтингом, что волосы на голове шевелятся.
Но с короткоживущим токеном я все равно вижу потенциальный риск в реализации: сам токен может быть шифрованным контейнером, содержащим, например, ID пользователя и дату создания. Тогда можем получить старый токен, расшифровать, проверить ID и дату, но тоже ошибочно аутентифицировать пользователя. Поэтому как раз хотел подчеркнуть, что стоит избавиться от информации о логине в самом токене.
Вечный токен — конечно, риск, но на описанную ситуацию вы бы нарвались даже с короткоживущим токеном, достаточно уложиться в срок его жизни.
UUID вместо порядковых ID помог бы с конкретным случаем, но что, если токен пользователя скомпрометирован? Как его заменить? Или, что еще хуже, скомпрометирован алгоритм получения токена из логина?
ИМХО более безопасным подходом будет создание случайного токена, а затем связывание его с пользователем. Получаем возможность создавать множество токенов для пользователя и легко их отзывать, не вкладываем никакой информации о логине в токен, можем даже спокойно оставить инкрементный ID.
Немножко поковырялся в политике протона. Заявления от него самого я так и не нашел, только цитаты в журналистских статьях.
Содержимое писем (конфиденциальность) и сведения о владельце ящика (анонимность) остаются сокрытыми. Из статьи по ссылке:
В privacy policy же протон открыто указывает, какая информация ему все-таки доступна:
https://protonmail.com/privacy-policy
А вот факт раскрытия таймстемпа действительно спорный и, как мне кажется, зависит от того, считать ли его конфиденциальной информацией отправителя. К тому же, письмо со стороны получателя уже опубликовано. А сокрытия самого факта передачи письма протон не гарантирует, насколько я понял.
Ушло около 20 минут на полную расшифровку, получил море удовольствия от задачи.
Дело в том, что по законопроекту все юр. лица будут обязаны так поступать под угрозой крупных штрафов. И каждый публичный Wifi будет доступен только с паспортом или телефоном — не останется ни одного открытого.
Потом нужно будет запрещать почтовые ящики (физические). А то как это так — можно анонимно отправить бумажное письмо! Только лично в филиале, с паспортом. А там и электронку перевести исключительно на одобренные государством сервисы.