Маломощные - конечно. Но большинство пользователей желает иметь мощные GPU, пригодные для игр, и так или иначе вынуждены использовать дискретные GPU.
Мощные GPU, пригодные для современных игр, переехали под крышку процессора относительно недавно, в последние 1-2 поколения процессоров. И дальше мощность этих GPU будет расти, постепенно снижая зависимость пользователей от дискретных GPU.
Конечно тут встанет вопрос с охлаждением всего этого пирога чипов, но его так или иначе решат. Пока же дискретные GPU все еще в приоритете у пользователей, не смотря на то, что последние поколения интегрированных GPU уже приближаются к возможностям дискретных GPU.
Это уже не HDD, и не SSD, а что-то уровня оптических накопителей. Были новости что что-то подобное есть у intel, для внутреннего хранения холодных архивов данных, вместо ленточных стримеров. Также в фантастике уже более полувека витает идея неких кристаллических накопителей, состоящих из собственно массива оптической памяти в виде некого прозрачного кристалла различных форм, и собственно считывающей головки в виде паза под кристалл с вмонтированным внутри лазером, оснащенным оптикой для трехмерного сканирования этого самого кристалла на предмет аномалий в структуре. Технически идея имеет право на жизнь, те же кристаллы всяких видов уже неплохо умеем выращивать, довольно недорого, высокого качества, а оптика и приводы дело нехитрое, тот же оптостаб схожего принципа в каждом смартфоне присутствует, управляющая электроника для всего этого тоже уже отработана, но тут есть фундаментальные проблемы в точности и энергетике, считывать данные не очень сложно, сложно их записывать, к тому же стандартов на такое пока нет и близко, не говоря уже о каких-либо серийных образцах таких накопителей, так что такие технологии пока виднеются где-то в далекой перспективе. Хотя мощные лазеры, способные прожигать кристаллы, уже существуют и очень доступны, доступна и недорогая оптика для них, и даже существуют серийные образцы схожих записывающих устройств низкой точности - их сейчас используют для производства всевозможных стеклянных игрушек, выжигая всякие узоры внутри объема стекла. Но вот все вместе в одном накопителе это совместить пока никому в голову не пришло.
В микросервисной архитектуре все так, да: каждая команда сама решает, без оглядки на остальных, главное чтобы протокол взаимодействия сервисов был документирован и соблюдался. Описанное в посте все же наверное больше проявляется именно в огромных монорепах: в одной части все на коллекциях, в другой на циклах, в третьей вообще рекурсия, а в четвертой автор упоролся в побитовые операции, потому что привык так писать для МК - несколько человек писали в разных стилях, как им было удобно, они свои задачи решили и забыли, а все последующие, стараясь соблюдать существующий стиль, продолжают писать именно в том стиле, который видят в конкретном месте кода, просто потому что проще сделать так, чем связываться с бюрократией и что-то менять. За редкими исключениями: у некоторых все же рано или поздно не выдерживают нервы, и они переписывают какие-то реализации в своем стиле, и таких переписываний туда-сюда за время жизни монорепы может быть несколько штук для одного и того же участка кода.
С микросервисами все гораздо проще: кода немного, его можно быстро понять, команда маленькая, можно со всеми договориться о чем угодно, ответственность за сервис полностью на команде, можно принимать самые смелые решения и делать так, как требуется, а не так, как вынуждает тонна легаси в монорепе, вот и получается что каких-то серьезных проблем с поддержкой просто не возникает, а те что бывают, их можно решить силами команды, просто пользуясь полной свободой в принятии решений.
Даже в пределах одной версии языка на большом моно-проекте в разных частях присутствует разный стиль, т.к. за разные части большого проекта отвечают разные люди, весь проект кому-то одному физически нет возможности охватить, это слишком большой объем информации для человеческого мозга. Разные части еще и написаны в разное время и разными людьми, многих из которых уже нет на проекте. А неизбежная текучка приводит к постепенной утрате экспертизы, и через несколько лет уже не остается тех, кто знает код достаточно хорошо - начинают появляться велосипеды и дублирующая функциональность: люди не знают что уже что-то где-то в недрах кода решено, и пишут свои реализации, и эти реализации множатся. Старый код постепенно начинает отмирать - появляются и растут фрагменты кода, которые больше ни за что не отвечают, не работают, не вызываются, но их просто некому удалить, уже никто уже не может сказать можно ли этот фрагмент трогать, и не поломает ли это что-то, и желающих рисковать нет. Затрудняется поддержка: команда больше не контролирует кодовую базу, кодовая база начинает жить своей жизнью, пухнуть в размерах и сложности. Растет количество ошибок: команда не контролирует код, боится его трогать, никто больше не понимает как он вообще работает, из каких частей состоит - проект превращается в огромный черный ящик. Поддержка такого кода становится настоящей болью для команды, и все меньше и меньше людей хотят в это ввязываться, и деньги тут уже второстепенный фактор, нервы дороже. А еще за эту боль никто не доплачивает: можно уйти на туже или большую зарплату в небольшой молодой проект и забыть про легаси-монстров с огромными монорепозиториями и вечным хаосом, болью и страданиями
Собственно почему и имеет смысл большие проекты разбивать на отдельные части, и связывать их общим публичным интерфейсом, который стандартизируется и закрепляется в документации, и выносить их код в отдельные репозитории. Тогда совершенно не важно что разные части написаны в разном стиле, т.к. за них отвечают отдельные команды, которые их полностью контролируют. Сам код, и соответственно сферы ответственности команд, никак не пересекаются с другими частями проекта, важно лишь чтобы все команды придерживались единого публичного интерфейса. И самим командам проще работать с такими проектами: уже не нужно разрываться и растекаться по огромной кодовой базе, достаточно наработать экспертизу по той небольшой ее части, за которую отвечает твоя команда, что сделать не так сложно. Людей на такие проекты тоже проще искать: погрузиться в небольшую кодовую базу значительно проще, чем в огромного легаси-монстра, в его темные джунгли, которые полны неизвестности и опасностей. Важно что команда способна полностью контролировать свою небольшую часть кодовой базы, и, если нужно, даже переписать ее с нуля, т.к. в сфере ответственности каждой команды вполне конкретная и относительно небольшая часть общего функционала, роль этой части в общем проекте четко описана, ожидаемое поведение документировано, детали реализации полностью отданы в руки конкретной команды. Сейчас такие архитектуры модно обзывать микросервисными, но это не обязательно могут быть прям отдельные сервисы, главное разграничить код и сферы ответственности, стандартизировать интерфейс взаимодействия, иначе быть беде
SSD чисто конструктивно технологичнее, а потому перспективнее, так что рано или поздно но они вытеснят сложные механические HDD. Все дело пока в болячках и прогрессе: SSD нужно еще решить ряд проблем, прежде чем они будут способны вытеснить HDD. Как минимум у них сейчас есть фундаментальная для технологии flash проблема с утекающим зарядом, а также накапливающийся износ из-за страничной организации ячеек. Возможно эти проблемы уйдут в прошлое, когда SSD перейдут на другие технологии хранения, например на мемристорные. А там далее анонсируют и объединение ОЗУ и ПЗУ в одно устройство, когда скорости/задержки технологий хранения позволят это сделать.
Также сейчас зарождается тенденция к уплотнению компоновки железа: GPU прямо сейчас потихоньку переезжают под крышку процессора, оперативка тоже туда скоро переедет, вендорами планы такие уже озвучены, а за ней и SSD потянутся. Так что через 1-2 десятилетия типичный компьютер в основной массе станет маленькой коробочкой с единственным модулем, под крышкой которого и будет почти вся начинка компьютера. Это в некотором роде даже удобно: можно будет выбрать конкретную версию модуля по своему бюджету, с разными емкостями ОЗУ/ПЗУ. Безусловно останутся и большие кастомные компьютеры, где будет точно такой же модуль, к которому можно снаружи на шины навесить дополнительный объем памяти, дисков и устройств, но большинству это будет просто не нужно, так что это станет уделом редких энтузиастов.
HDD при всем желании все эти чудеса не грозят: их под крышку процессора шанса засунуть нет.
На смартфонах анимации штука приятная, если сделано грамотно, т.е. не тормозит, и не замедляет слишком сильно переходы по интерфейсу. На практике таких примеров на весь рынок 1,5 штуки - почти у всех реализации отвратительные, и люди просто выключают анимации или выкручивают их скорость так, чтобы они мгновенно проскакивали.
На десктопах полностью аналогично: есть примеры, где это можно сделать красиво и приятно, например на kde с современным железом. Но в большинстве случаев, особенно из коробки, анимации реализованы ужасно, и их выключают.
С браузерами таже история: почти все рализации анимаций на сайтах ужасны и неудобны, доставляют только дискомфорт. Только анимации на браузерах не только замедляют интерфейс, но и натурально заставляют железо взлетать на вентиляторах охлаждения, или высаживают батарейку на глазах. Особенно мерзко выглядят сайты больших брендов с огромными бюджетами, где вся главная страница одна сплошная анимация, и тяжела не только вычислительно, но и натурально странички весит под сотню мегабайт, что даже просто прогрузить проблематично. Вот если делать простенькую анимацию, которая бы не сильно грузила железо, не слишком бросалась в глаза, и не тормозила интерфейс и переходы по нему - вот такой анимации цены бы не было. Но с браузерами в этом плане большие сложности: мало того что они сами по себе тормозят, так еще и у посетителей слишком большой зоопарк железа, от стареньких смартфонов на первых версиях андроида до современных флагманов, и этот факт большинство сайтов упорно не учитывает. Дополнительно посетителей злит тот факт, что они никак не могут влиять на анимации в браузерах, нет интерфейса чтобы их ускорить или хотя бы отключить, как в случае с анимациями ОС. Так что реализация анимаций на сайтах штука по сути неблагодарная: грамотно сделать сложно, дорого, требуется поддержка огромного зоопарка устройств, и всегда будут недовольные.
Тут такой принцип, что добровольные решения не работают от слова совсем: на практике, не смотря ни на что, никто себе это приложения скачивать даже не станет, кроме 3,5 человек, и мера окажется бессмысленной. Если хотят подобным образом выключать отвлекающий факторы, то это должно работать снаружи, автоматически, и для всех. С приложениями такое принципиально невозможно провернуть.
Ставить надо также и на поездах, в головной части, с антеннами направленными вперед, и радиусом действия хотя бы в 200-300 метров. Люди переходят не только по переходам, за пределами переходов сотни тропинок, пересекающих рельсы.
Статья сомнительная, тут согласен - слишком похоже на ИИ стиль. Идеи хоть и здравые, но более-менее очевидные.
Для себя в целом пришел примерно к тем же принципам, исходя из опыта и прошлых ошибок:
максимально строгий и простой публичный интерфейс, скорее даже контракт, он упрощает понимание и сокращает количество ошибок, делает взаимодействие частей системы прозрачным, повышает надежность и стабильность всей системы
модульность позволяет уменьшать степень связности, скрывать реализации и все их внутренние костыли, снижает когнитивную сложность и стоимость поддержки, и, самое главное, ограничивает бесконтрольный рост сложности и размывание ответственности: границы модулей затрудняют и замедляют рост новых связей между кишками разных модулей, позволяя оставаться в рамках публичного интерфейса, не дают наращивать когнитивную сложность и уменьшают риск появления не очевидных побочных эффектов, которые возникают из-за лишних связей в обход публичного интерфейса. В идеале разграничение должно быть как можно строже, на уровне разных команд и разных приложений, так как разнесение кода по модулям в пределах одного приложения и одной команды на практике работает не очень хорошо, всегда найдется тот, кто захочет срезать углы и добавить магии и скрытых связей, чтобы сэкономить силы или время, и препятствовать такому развитию событий довольно сложно и дорого, в то время как физическое разграничение по разным командам просто не даст самой возможности выйти за пределы публичного интерфейса какому-то одному конкретному разработчику, как бы ему этого не хотелось
принцип позднего связывания, на мой взгляд, автоматически вытекает из использования публичных интерфейсов: когда все взаимодействие частей системы строго расписано, уже не особо важно как и из чего сделана каждая отдельная часть, главное чтобы они придерживались публичного интерфейса. Их можно прозрачно менять, прямо во время работы системы, комбинировать, маршрутизировать каналы сообщений, архитектура такой системы очень гибкая
Что касается всего остального - это уже в целом напоминает философию, и это уже не особо интересно, интереснее сугубо прикладная, практическая часть, то, что принесет какие-то ощутимые выгоды, такие как например снижение когнитивной нагрузки. А практика показывает, что разработчики это штука нестандартная, творческая, и сильно зависимая от опыта. У каждого свои треки развития, свой набор шишек, опыта, знаний и усвоенных концепций, набор освоенных методик и инструментов, свои лайфхаки, и своя планка сложности идей, которую способен обработать мозг. Кто-то еще просто не готов к концепциям сложнее объектов и наследования, кто-то уже нахватался философии, но пока не понимает ее, и, в желании считаться тру разработчиком, усердно везде намазывает тонны абсолютно лишних абстракций, на любые замечания гневно крича про первичность принципов, не понимая этих самых принципов, подобно религиозному фанатику, по факту только усложняя жизнь себе и коллегам, а кто-то уже набил шишки и сам пришел к тем идеям, которые ему упростили жизнь, или набрался достаточно опыта, чтобы понять и оценить практические выгоды из чужих идей, прочитанных или подсмотренных где-то, и теперь начинает это применять сам, в своей работе. И требовать тут что-то бессмысленно: если опыта недостаточно, то формально все требуемое будет соблюдено, но в таком виде, что никто этому рад не будет. Остается только направлять и подсказывать, подсвечивать тонкие моменты, и ожидать пока человек вырастет сам до достаточного уровня, чтобы применять инструменты осмысленно.
У TOTP есть еще одно значимое преимущество, как у второго фактора: полная независимость от чего-либо. Работает идеально, чего не скажешь о других вторых факторах. Многие сервисы используют в качестве второго фактора смс или email, но сим-карты и почтовые ящики имеют свойство устаревать, и дарить пользователям проблемы на ровном месте, а TOTP просто продолжает работать.
Новое, вероятно, это пуши. Сайты могут присылать пуши, как и обычные приложения. Реботает это неплохо - можно получать уведомления от почтовиков или соцсетей/ютуба, вполне удобно. Но если пуши будут похожи на пуши официального приложения, это не очень хорошо, все таки к пушам доверия больше чем к смс, можно ткнуть и попасть на фишинговый сайт, который также похож на официальный, и отличается только парой букв домена. Другой вопрос - сперва на эти пуши нужно как-то подписаться, этот момент не раскрыт. Сомнительно что у левых сайтов есть какая-либо возможность без спроса рассылать пуши, вероятно в любом случае сперва нужно пройти по левой ссылке, чтобы пуши активировались именно через браузер.
А не работают они еще и по причине банальной лени. Вот не охота бухгалтеру что-то менять, и тебе устно отказывают в смене счета для получения выплат, вот прям вообще никакой возможности сменить счет нет, и все тут. Но стоит просто молча заявление подать, и... никаких отказов, тут уже отказ обосновать просто нечем. Бумажка есть бумажка.
Большинство обламываются уже на устном отказе и уходят, жалуясь что законы у нас не работают
А просто надо в рамках закона такие вопросы решать, тогда все работает замечательно
Можно сделать за 3 часа, раз, другой, третий, а на четвертый выгореть и послать все на три буквы, многие так вообще из профессии уходят, нервы дороже. Ну или опционально заработать себе серьезные проблемы со здоровьем - нервы не железные. Не все могут справится с такой высокой когнитивной нагрузкой и огромным потоком постоянно меняющихся требований, тут все таки больше психика играет, стрессоустойчивость, и здоровый пофигизм в какой-то мере. А у кого с психикой не очень, они просто спиваются - так им проще все это переносить, но... работает это не очень долго, так себе план
Так что нужно делать именно в своем ритме, как комфортно - только так можно преодолевать этот марафон из постоянного потока задач. Спешить стоит только в очень крайних случаях, ресурс для спешки у человека очень ограничен, спешка быстро просаживает психику и здоровье
А то что каждый раз нужно вчера - это обычные рабочие моменты: https://www.youtube.com/watch?v=hJ4JMN352xY конечно исключения есть, но тут все индивидуально. Все это приходит с опытом: когда у тебя каждый день все "срочно, вчера", значит ничего срочного нет, тут просто так принято. Можно просто завести себе канбан-доску и складывать все в очередь там, и делать столько, сколько делается, не надрываясь. Потому что надрываться дорого, и в первую очередь именно вам, при этом просаживается именно ваше здоровье, и его потом просто нет возможности восстановить, увы. Гореть смысла просто нет. Лучше накапливать силы для редких спринтов, которые действительно нужно пройти побыстрее, а не сидеть постоянно с нулем энергии. Но это именно редкие случаи. Все остальное - через очередь и обычный рабочий монотонный процесс. И эту очередь по желанию заказчика можно двигать, но не слишком часто, не чаще 1-2 раз в день, иначе эффективность просядет уже от переключения контекста, о чем хорошо изложено тут: https://habr.com/ru/companies/productivity_inside/articles/800563/ и тут https://habr.com/ru/articles/166715/
Велосипед может жить годами, обрастая новыми фичами и новыми связями. До поры до времени это как бы норм и беды не предвещает. Но именно с этой стороны и будут проблемы позже. Рано или поздно придет время выпилить велосипед, но к тому моменту он будет уже слишком сильно привязан, "врастет" в продукт
А выпилить велосипед потребуется как минимум по двум причинам: стандартизация и производительность. Общедоступные популярные инструменты уже прошли свой путь развития и доросли до highload, а велосипед придется протащить туда команде на своих плечах, это может быть слишком сложно/дорого. И рано или поздно придет время менять команду, новых разработчиков на поддержку велосипеда будет найти/обучить сложнее/дольше/дороже, чем на поддержку общедоступных популярных инструментов
В общем велосипеды - это слишком сильный фактор удержания. Само их существование мешает как дальнейшему развитию продукта, так и развитию карьеры: к тому моменту, как велосипед начнет ограничивать, слезать с велосипеда бизнесу будет уже слишком дорого, а менеджмент всеми силами будет пытаться удержать старую команду на поддержке этого самого велосипеда, потому что новых людей туда затащить будет слишком проблематично
Это к чему: тоже иногда приходится использовать велосипеды, в надежде скроить/сэкономить, но еще не было случая, чтобы об этом позже не пожалел. Каждый раз в итоге оказывается, что дешевле было потратить еще немножко времени, и разобраться с общедоступными инструментами, и сделать сразу как нужно, по-человечески
В мобильном клиенте там еще и свободный доступ к огромной сетевой базе с коллекциями карточек на любой вкус, и каждый может ее пополнить своими коллекциями
4000 циклов, режим 100-25 или дельта 75% за цикл - итоговая потеря емкости 20%
режим 75-45 или дельта 30% за цикл - итоговая потеря емкости 10%
На первый взгляд второй режим вдвое выгоднее, меньше деградация, и батарея дольше проживет
Но если присмотреться детальнее, посчитав энергию, оказывается, что батарея медленнее деградирует именно в первом случае. Смотрите сами: давайте переведем циклы и дельту в реальные единицы емкости, в энергию. 4000 циклов по 75%, перемножаем 4000 и 0.75C, и понимаем что это 3000C, а 4000 циклов при дельте 30% это 1200C, при этом в первом случае деградация на 20% емкости, а во втором на 10%. Получается, что в первом случае батарею в реальности эксплуатировали втрое интенсивнее, но деградация оказалась не втрое больше, а всего вдвое, т.е. получается что в более бережном режиме эксплуатации батарея деградирует примерно на 30% быстрее, чем в более интенсивном, на тот же объем пропущенной энергии, соответственно и полезной работы для нас менее интенсивно эксплуатируемая батарея способна выполнить на треть меньше, как будто мы заранее лишились трети ее емкости
Делаем выводы
Но более интересные выводы для себя можно сделать, если пересчитать все эти 3000С и 1200С в удельную потерю емкости на 1C емкости, выходит результат близок к константе, на уровне погрешности измерений: потеря емкости на каждые 1С емкости примерно 0,00007С против 0,00008С - это же практически одно и тоже! Грубо говоря 10Ач залил, 10Ач слил, и, независимо от режима эксплуатации, потерял 0,000075С(+/- 0,000005С) емкости. Все просто
pixel 5 за 3 года обычного использования, практически без быстрой зарядки, при подсчете емкости сторонним софтом, путем непрерывного анализа тока батареи, показывает уменьшение емкости с 4Ач до 2Ач, ощущения также подтверждают это, разряжается прямо на глазах, совсем не держит на холоде, а ОС показывает что батарея хорошая. Бывает и так
Батарея может быть многосекционной, ток кратно меньше на ячейку. Батареи приклеены широкой частью к теплорассеивающим пластинам, что немного облегчает им жизнь
Искать следующего и проходить собеседования можно без отрыва от текущей работы.
И не только можно, но и нужно. Хотя бы ради себя: ради того, чтобы адекватно воспринимать свою позицию на рынке и текущие потребности работодателей, чтобы иметь возможность подтягивать свои скилы до конкурентного уровня. Например так можно выяснить, что твой стек/умения/опыт уже малоинтересен рынку, и пора бы научиться чему-то новому. На собеседованиях ты общаешься с техническими специалистами, с руководством, получаешь информацию о внутренней кухне фирмы, ее потребностях, деятельности, каких-то проектах. И даже если ты на эти позиции даже минимально не проходишь - ничего страшного, это все равно на пользу тебе идет: с таким опытом приходит понимание в какую сторону нужно развиваться дальше.
В целом практика такого рода общения раскрепощает, позволяет тебе держаться на собеседованиях уверенно. Ты понимаешь как лучше себя подать, рассказать о своем опыте и ожиданиях, как лучше выяснить детали о фирме, какие вопросы стоит задавать, какие нет, как лучше отвечать на чужие вопросы, как лучше подготовить свое резюме. Ты понимаешь, что тебе всегда есть куда идти, и сменить работу на практике не так сложно, как казалось ранее. Все эти процессы становятся обыденностью, как сменить одежду например, это хорошо разгружает психику, снимает всякого рода переживания, позволяют смотреть в будущее с уверенностью, понимание, что даже если завтра тебя уволят, ты не пропадешь, ты уже знаешь что делать, и умеешь это делать.
При неспешном поиске без отрыва от работы можно искать вплоть до получения оффера/приглашения, и переоформления одним днем, по соглашению сторон - даже такое вполне бывает.
Конечно при появлении желания сменить работу обязательно нужно накопить подушку на несколько месяцев. Чтобы даже в худшем случае можно было комфортно найти новую работу, не боясь остаться без денег: такого рода страхи не только вызывают психологический дискомфорт, но и склоняют людей к тому, чтобы соглашаться на гораздо худшие условия, чем они могут получить. Т.е. отсутствие подушки кратно ухудшает как положение, так и перспективы, это недопустимо.
Именно так, маркетологи будут в восторге
Маломощные - конечно. Но большинство пользователей желает иметь мощные GPU, пригодные для игр, и так или иначе вынуждены использовать дискретные GPU.
Мощные GPU, пригодные для современных игр, переехали под крышку процессора относительно недавно, в последние 1-2 поколения процессоров. И дальше мощность этих GPU будет расти, постепенно снижая зависимость пользователей от дискретных GPU.
Конечно тут встанет вопрос с охлаждением всего этого пирога чипов, но его так или иначе решат. Пока же дискретные GPU все еще в приоритете у пользователей, не смотря на то, что последние поколения интегрированных GPU уже приближаются к возможностям дискретных GPU.
Это уже не HDD, и не SSD, а что-то уровня оптических накопителей. Были новости что что-то подобное есть у intel, для внутреннего хранения холодных архивов данных, вместо ленточных стримеров. Также в фантастике уже более полувека витает идея неких кристаллических накопителей, состоящих из собственно массива оптической памяти в виде некого прозрачного кристалла различных форм, и собственно считывающей головки в виде паза под кристалл с вмонтированным внутри лазером, оснащенным оптикой для трехмерного сканирования этого самого кристалла на предмет аномалий в структуре. Технически идея имеет право на жизнь, те же кристаллы всяких видов уже неплохо умеем выращивать, довольно недорого, высокого качества, а оптика и приводы дело нехитрое, тот же оптостаб схожего принципа в каждом смартфоне присутствует, управляющая электроника для всего этого тоже уже отработана, но тут есть фундаментальные проблемы в точности и энергетике, считывать данные не очень сложно, сложно их записывать, к тому же стандартов на такое пока нет и близко, не говоря уже о каких-либо серийных образцах таких накопителей, так что такие технологии пока виднеются где-то в далекой перспективе. Хотя мощные лазеры, способные прожигать кристаллы, уже существуют и очень доступны, доступна и недорогая оптика для них, и даже существуют серийные образцы схожих записывающих устройств низкой точности - их сейчас используют для производства всевозможных стеклянных игрушек, выжигая всякие узоры внутри объема стекла. Но вот все вместе в одном накопителе это совместить пока никому в голову не пришло.
В микросервисной архитектуре все так, да: каждая команда сама решает, без оглядки на остальных, главное чтобы протокол взаимодействия сервисов был документирован и соблюдался. Описанное в посте все же наверное больше проявляется именно в огромных монорепах: в одной части все на коллекциях, в другой на циклах, в третьей вообще рекурсия, а в четвертой автор упоролся в побитовые операции, потому что привык так писать для МК - несколько человек писали в разных стилях, как им было удобно, они свои задачи решили и забыли, а все последующие, стараясь соблюдать существующий стиль, продолжают писать именно в том стиле, который видят в конкретном месте кода, просто потому что проще сделать так, чем связываться с бюрократией и что-то менять. За редкими исключениями: у некоторых все же рано или поздно не выдерживают нервы, и они переписывают какие-то реализации в своем стиле, и таких переписываний туда-сюда за время жизни монорепы может быть несколько штук для одного и того же участка кода.
С микросервисами все гораздо проще: кода немного, его можно быстро понять, команда маленькая, можно со всеми договориться о чем угодно, ответственность за сервис полностью на команде, можно принимать самые смелые решения и делать так, как требуется, а не так, как вынуждает тонна легаси в монорепе, вот и получается что каких-то серьезных проблем с поддержкой просто не возникает, а те что бывают, их можно решить силами команды, просто пользуясь полной свободой в принятии решений.
Даже в пределах одной версии языка на большом моно-проекте в разных частях присутствует разный стиль, т.к. за разные части большого проекта отвечают разные люди, весь проект кому-то одному физически нет возможности охватить, это слишком большой объем информации для человеческого мозга. Разные части еще и написаны в разное время и разными людьми, многих из которых уже нет на проекте. А неизбежная текучка приводит к постепенной утрате экспертизы, и через несколько лет уже не остается тех, кто знает код достаточно хорошо - начинают появляться велосипеды и дублирующая функциональность: люди не знают что уже что-то где-то в недрах кода решено, и пишут свои реализации, и эти реализации множатся. Старый код постепенно начинает отмирать - появляются и растут фрагменты кода, которые больше ни за что не отвечают, не работают, не вызываются, но их просто некому удалить, уже никто уже не может сказать можно ли этот фрагмент трогать, и не поломает ли это что-то, и желающих рисковать нет. Затрудняется поддержка: команда больше не контролирует кодовую базу, кодовая база начинает жить своей жизнью, пухнуть в размерах и сложности. Растет количество ошибок: команда не контролирует код, боится его трогать, никто больше не понимает как он вообще работает, из каких частей состоит - проект превращается в огромный черный ящик. Поддержка такого кода становится настоящей болью для команды, и все меньше и меньше людей хотят в это ввязываться, и деньги тут уже второстепенный фактор, нервы дороже. А еще за эту боль никто не доплачивает: можно уйти на туже или большую зарплату в небольшой молодой проект и забыть про легаси-монстров с огромными монорепозиториями и вечным хаосом, болью и страданиями
Собственно почему и имеет смысл большие проекты разбивать на отдельные части, и связывать их общим публичным интерфейсом, который стандартизируется и закрепляется в документации, и выносить их код в отдельные репозитории. Тогда совершенно не важно что разные части написаны в разном стиле, т.к. за них отвечают отдельные команды, которые их полностью контролируют. Сам код, и соответственно сферы ответственности команд, никак не пересекаются с другими частями проекта, важно лишь чтобы все команды придерживались единого публичного интерфейса. И самим командам проще работать с такими проектами: уже не нужно разрываться и растекаться по огромной кодовой базе, достаточно наработать экспертизу по той небольшой ее части, за которую отвечает твоя команда, что сделать не так сложно. Людей на такие проекты тоже проще искать: погрузиться в небольшую кодовую базу значительно проще, чем в огромного легаси-монстра, в его темные джунгли, которые полны неизвестности и опасностей. Важно что команда способна полностью контролировать свою небольшую часть кодовой базы, и, если нужно, даже переписать ее с нуля, т.к. в сфере ответственности каждой команды вполне конкретная и относительно небольшая часть общего функционала, роль этой части в общем проекте четко описана, ожидаемое поведение документировано, детали реализации полностью отданы в руки конкретной команды. Сейчас такие архитектуры модно обзывать микросервисными, но это не обязательно могут быть прям отдельные сервисы, главное разграничить код и сферы ответственности, стандартизировать интерфейс взаимодействия, иначе быть беде
SSD чисто конструктивно технологичнее, а потому перспективнее, так что рано или поздно но они вытеснят сложные механические HDD. Все дело пока в болячках и прогрессе: SSD нужно еще решить ряд проблем, прежде чем они будут способны вытеснить HDD. Как минимум у них сейчас есть фундаментальная для технологии flash проблема с утекающим зарядом, а также накапливающийся износ из-за страничной организации ячеек. Возможно эти проблемы уйдут в прошлое, когда SSD перейдут на другие технологии хранения, например на мемристорные. А там далее анонсируют и объединение ОЗУ и ПЗУ в одно устройство, когда скорости/задержки технологий хранения позволят это сделать.
Также сейчас зарождается тенденция к уплотнению компоновки железа: GPU прямо сейчас потихоньку переезжают под крышку процессора, оперативка тоже туда скоро переедет, вендорами планы такие уже озвучены, а за ней и SSD потянутся. Так что через 1-2 десятилетия типичный компьютер в основной массе станет маленькой коробочкой с единственным модулем, под крышкой которого и будет почти вся начинка компьютера. Это в некотором роде даже удобно: можно будет выбрать конкретную версию модуля по своему бюджету, с разными емкостями ОЗУ/ПЗУ. Безусловно останутся и большие кастомные компьютеры, где будет точно такой же модуль, к которому можно снаружи на шины навесить дополнительный объем памяти, дисков и устройств, но большинству это будет просто не нужно, так что это станет уделом редких энтузиастов.
HDD при всем желании все эти чудеса не грозят: их под крышку процессора шанса засунуть нет.
Личное мнение: скорее раздражает, чем нет.
На смартфонах анимации штука приятная, если сделано грамотно, т.е. не тормозит, и не замедляет слишком сильно переходы по интерфейсу. На практике таких примеров на весь рынок 1,5 штуки - почти у всех реализации отвратительные, и люди просто выключают анимации или выкручивают их скорость так, чтобы они мгновенно проскакивали.
На десктопах полностью аналогично: есть примеры, где это можно сделать красиво и приятно, например на kde с современным железом. Но в большинстве случаев, особенно из коробки, анимации реализованы ужасно, и их выключают.
С браузерами таже история: почти все рализации анимаций на сайтах ужасны и неудобны, доставляют только дискомфорт. Только анимации на браузерах не только замедляют интерфейс, но и натурально заставляют железо взлетать на вентиляторах охлаждения, или высаживают батарейку на глазах. Особенно мерзко выглядят сайты больших брендов с огромными бюджетами, где вся главная страница одна сплошная анимация, и тяжела не только вычислительно, но и натурально странички весит под сотню мегабайт, что даже просто прогрузить проблематично. Вот если делать простенькую анимацию, которая бы не сильно грузила железо, не слишком бросалась в глаза, и не тормозила интерфейс и переходы по нему - вот такой анимации цены бы не было. Но с браузерами в этом плане большие сложности: мало того что они сами по себе тормозят, так еще и у посетителей слишком большой зоопарк железа, от стареньких смартфонов на первых версиях андроида до современных флагманов, и этот факт большинство сайтов упорно не учитывает. Дополнительно посетителей злит тот факт, что они никак не могут влиять на анимации в браузерах, нет интерфейса чтобы их ускорить или хотя бы отключить, как в случае с анимациями ОС. Так что реализация анимаций на сайтах штука по сути неблагодарная: грамотно сделать сложно, дорого, требуется поддержка огромного зоопарка устройств, и всегда будут недовольные.
Тут такой принцип, что добровольные решения не работают от слова совсем: на практике, не смотря ни на что, никто себе это приложения скачивать даже не станет, кроме 3,5 человек, и мера окажется бессмысленной. Если хотят подобным образом выключать отвлекающий факторы, то это должно работать снаружи, автоматически, и для всех. С приложениями такое принципиально невозможно провернуть.
Ставить надо также и на поездах, в головной части, с антеннами направленными вперед, и радиусом действия хотя бы в 200-300 метров. Люди переходят не только по переходам, за пределами переходов сотни тропинок, пересекающих рельсы.
Статья сомнительная, тут согласен - слишком похоже на ИИ стиль. Идеи хоть и здравые, но более-менее очевидные.
Для себя в целом пришел примерно к тем же принципам, исходя из опыта и прошлых ошибок:
максимально строгий и простой публичный интерфейс, скорее даже контракт, он упрощает понимание и сокращает количество ошибок, делает взаимодействие частей системы прозрачным, повышает надежность и стабильность всей системы
модульность позволяет уменьшать степень связности, скрывать реализации и все их внутренние костыли, снижает когнитивную сложность и стоимость поддержки, и, самое главное, ограничивает бесконтрольный рост сложности и размывание ответственности: границы модулей затрудняют и замедляют рост новых связей между кишками разных модулей, позволяя оставаться в рамках публичного интерфейса, не дают наращивать когнитивную сложность и уменьшают риск появления не очевидных побочных эффектов, которые возникают из-за лишних связей в обход публичного интерфейса. В идеале разграничение должно быть как можно строже, на уровне разных команд и разных приложений, так как разнесение кода по модулям в пределах одного приложения и одной команды на практике работает не очень хорошо, всегда найдется тот, кто захочет срезать углы и добавить магии и скрытых связей, чтобы сэкономить силы или время, и препятствовать такому развитию событий довольно сложно и дорого, в то время как физическое разграничение по разным командам просто не даст самой возможности выйти за пределы публичного интерфейса какому-то одному конкретному разработчику, как бы ему этого не хотелось
принцип позднего связывания, на мой взгляд, автоматически вытекает из использования публичных интерфейсов: когда все взаимодействие частей системы строго расписано, уже не особо важно как и из чего сделана каждая отдельная часть, главное чтобы они придерживались публичного интерфейса. Их можно прозрачно менять, прямо во время работы системы, комбинировать, маршрутизировать каналы сообщений, архитектура такой системы очень гибкая
Что касается всего остального - это уже в целом напоминает философию, и это уже не особо интересно, интереснее сугубо прикладная, практическая часть, то, что принесет какие-то ощутимые выгоды, такие как например снижение когнитивной нагрузки. А практика показывает, что разработчики это штука нестандартная, творческая, и сильно зависимая от опыта. У каждого свои треки развития, свой набор шишек, опыта, знаний и усвоенных концепций, набор освоенных методик и инструментов, свои лайфхаки, и своя планка сложности идей, которую способен обработать мозг. Кто-то еще просто не готов к концепциям сложнее объектов и наследования, кто-то уже нахватался философии, но пока не понимает ее, и, в желании считаться тру разработчиком, усердно везде намазывает тонны абсолютно лишних абстракций, на любые замечания гневно крича про первичность принципов, не понимая этих самых принципов, подобно религиозному фанатику, по факту только усложняя жизнь себе и коллегам, а кто-то уже набил шишки и сам пришел к тем идеям, которые ему упростили жизнь, или набрался достаточно опыта, чтобы понять и оценить практические выгоды из чужих идей, прочитанных или подсмотренных где-то, и теперь начинает это применять сам, в своей работе. И требовать тут что-то бессмысленно: если опыта недостаточно, то формально все требуемое будет соблюдено, но в таком виде, что никто этому рад не будет. Остается только направлять и подсказывать, подсвечивать тонкие моменты, и ожидать пока человек вырастет сам до достаточного уровня, чтобы применять инструменты осмысленно.
У TOTP есть еще одно значимое преимущество, как у второго фактора: полная независимость от чего-либо. Работает идеально, чего не скажешь о других вторых факторах. Многие сервисы используют в качестве второго фактора смс или email, но сим-карты и почтовые ящики имеют свойство устаревать, и дарить пользователям проблемы на ровном месте, а TOTP просто продолжает работать.
Новое, вероятно, это пуши. Сайты могут присылать пуши, как и обычные приложения. Реботает это неплохо - можно получать уведомления от почтовиков или соцсетей/ютуба, вполне удобно. Но если пуши будут похожи на пуши официального приложения, это не очень хорошо, все таки к пушам доверия больше чем к смс, можно ткнуть и попасть на фишинговый сайт, который также похож на официальный, и отличается только парой букв домена. Другой вопрос - сперва на эти пуши нужно как-то подписаться, этот момент не раскрыт. Сомнительно что у левых сайтов есть какая-либо возможность без спроса рассылать пуши, вероятно в любом случае сперва нужно пройти по левой ссылке, чтобы пуши активировались именно через браузер.
А не работают они еще и по причине банальной лени. Вот не охота бухгалтеру что-то менять, и тебе устно отказывают в смене счета для получения выплат, вот прям вообще никакой возможности сменить счет нет, и все тут. Но стоит просто молча заявление подать, и... никаких отказов, тут уже отказ обосновать просто нечем. Бумажка есть бумажка.
Большинство обламываются уже на устном отказе и уходят, жалуясь что законы у нас не работают
А просто надо в рамках закона такие вопросы решать, тогда все работает замечательно
Можно сделать за 3 часа, раз, другой, третий, а на четвертый выгореть и послать все на три буквы, многие так вообще из профессии уходят, нервы дороже. Ну или опционально заработать себе серьезные проблемы со здоровьем - нервы не железные. Не все могут справится с такой высокой когнитивной нагрузкой и огромным потоком постоянно меняющихся требований, тут все таки больше психика играет, стрессоустойчивость, и здоровый пофигизм в какой-то мере. А у кого с психикой не очень, они просто спиваются - так им проще все это переносить, но... работает это не очень долго, так себе план
Так что нужно делать именно в своем ритме, как комфортно - только так можно преодолевать этот марафон из постоянного потока задач. Спешить стоит только в очень крайних случаях, ресурс для спешки у человека очень ограничен, спешка быстро просаживает психику и здоровье
А то что каждый раз нужно вчера - это обычные рабочие моменты: https://www.youtube.com/watch?v=hJ4JMN352xY конечно исключения есть, но тут все индивидуально. Все это приходит с опытом: когда у тебя каждый день все "срочно, вчера", значит ничего срочного нет, тут просто так принято. Можно просто завести себе канбан-доску и складывать все в очередь там, и делать столько, сколько делается, не надрываясь. Потому что надрываться дорого, и в первую очередь именно вам, при этом просаживается именно ваше здоровье, и его потом просто нет возможности восстановить, увы. Гореть смысла просто нет. Лучше накапливать силы для редких спринтов, которые действительно нужно пройти побыстрее, а не сидеть постоянно с нулем энергии. Но это именно редкие случаи. Все остальное - через очередь и обычный рабочий монотонный процесс. И эту очередь по желанию заказчика можно двигать, но не слишком часто, не чаще 1-2 раз в день, иначе эффективность просядет уже от переключения контекста, о чем хорошо изложено тут: https://habr.com/ru/companies/productivity_inside/articles/800563/ и тут https://habr.com/ru/articles/166715/
Велосипед может жить годами, обрастая новыми фичами и новыми связями. До поры до времени это как бы норм и беды не предвещает. Но именно с этой стороны и будут проблемы позже. Рано или поздно придет время выпилить велосипед, но к тому моменту он будет уже слишком сильно привязан, "врастет" в продукт
А выпилить велосипед потребуется как минимум по двум причинам: стандартизация и производительность. Общедоступные популярные инструменты уже прошли свой путь развития и доросли до highload, а велосипед придется протащить туда команде на своих плечах, это может быть слишком сложно/дорого. И рано или поздно придет время менять команду, новых разработчиков на поддержку велосипеда будет найти/обучить сложнее/дольше/дороже, чем на поддержку общедоступных популярных инструментов
В общем велосипеды - это слишком сильный фактор удержания. Само их существование мешает как дальнейшему развитию продукта, так и развитию карьеры: к тому моменту, как велосипед начнет ограничивать, слезать с велосипеда бизнесу будет уже слишком дорого, а менеджмент всеми силами будет пытаться удержать старую команду на поддержке этого самого велосипеда, потому что новых людей туда затащить будет слишком проблематично
Это к чему: тоже иногда приходится использовать велосипеды, в надежде скроить/сэкономить, но еще не было случая, чтобы об этом позже не пожалел. Каждый раз в итоге оказывается, что дешевле было потратить еще немножко времени, и разобраться с общедоступными инструментами, и сделать сразу как нужно, по-человечески
Вот более удобный и доступный инструмент для интервального запоминания https://ru.wikipedia.org/wiki/Anki
В мобильном клиенте там еще и свободный доступ к огромной сетевой базе с коллекциями карточек на любой вкус, и каждый может ее пополнить своими коллекциями
Интересная закономерность:
4000 циклов, режим 100-25 или дельта 75% за цикл - итоговая потеря емкости 20%
режим 75-45 или дельта 30% за цикл - итоговая потеря емкости 10%
На первый взгляд второй режим вдвое выгоднее, меньше деградация, и батарея дольше проживет
Но если присмотреться детальнее, посчитав энергию, оказывается, что батарея медленнее деградирует именно в первом случае. Смотрите сами: давайте переведем циклы и дельту в реальные единицы емкости, в энергию. 4000 циклов по 75%, перемножаем 4000 и 0.75C, и понимаем что это 3000C, а 4000 циклов при дельте 30% это 1200C, при этом в первом случае деградация на 20% емкости, а во втором на 10%. Получается, что в первом случае батарею в реальности эксплуатировали втрое интенсивнее, но деградация оказалась не втрое больше, а всего вдвое, т.е. получается что в более бережном режиме эксплуатации батарея деградирует примерно на 30% быстрее, чем в более интенсивном, на тот же объем пропущенной энергии, соответственно и полезной работы для нас менее интенсивно эксплуатируемая батарея способна выполнить на треть меньше, как будто мы заранее лишились трети ее емкости
Делаем выводы
Но более интересные выводы для себя можно сделать, если пересчитать все эти 3000С и 1200С в удельную потерю емкости на 1C емкости, выходит результат близок к константе, на уровне погрешности измерений: потеря емкости на каждые 1С емкости примерно 0,00007С против 0,00008С - это же практически одно и тоже! Грубо говоря 10Ач залил, 10Ач слил, и, независимо от режима эксплуатации, потерял 0,000075С(+/- 0,000005С) емкости. Все просто
pixel 5 за 3 года обычного использования, практически без быстрой зарядки, при подсчете емкости сторонним софтом, путем непрерывного анализа тока батареи, показывает уменьшение емкости с 4Ач до 2Ач, ощущения также подтверждают это, разряжается прямо на глазах, совсем не держит на холоде, а ОС показывает что батарея хорошая. Бывает и так
Батарея может быть многосекционной, ток кратно меньше на ячейку. Батареи приклеены широкой частью к теплорассеивающим пластинам, что немного облегчает им жизнь
Искать следующего и проходить собеседования можно без отрыва от текущей работы.
И не только можно, но и нужно. Хотя бы ради себя: ради того, чтобы адекватно воспринимать свою позицию на рынке и текущие потребности работодателей, чтобы иметь возможность подтягивать свои скилы до конкурентного уровня. Например так можно выяснить, что твой стек/умения/опыт уже малоинтересен рынку, и пора бы научиться чему-то новому. На собеседованиях ты общаешься с техническими специалистами, с руководством, получаешь информацию о внутренней кухне фирмы, ее потребностях, деятельности, каких-то проектах. И даже если ты на эти позиции даже минимально не проходишь - ничего страшного, это все равно на пользу тебе идет: с таким опытом приходит понимание в какую сторону нужно развиваться дальше.
В целом практика такого рода общения раскрепощает, позволяет тебе держаться на собеседованиях уверенно. Ты понимаешь как лучше себя подать, рассказать о своем опыте и ожиданиях, как лучше выяснить детали о фирме, какие вопросы стоит задавать, какие нет, как лучше отвечать на чужие вопросы, как лучше подготовить свое резюме. Ты понимаешь, что тебе всегда есть куда идти, и сменить работу на практике не так сложно, как казалось ранее. Все эти процессы становятся обыденностью, как сменить одежду например, это хорошо разгружает психику, снимает всякого рода переживания, позволяют смотреть в будущее с уверенностью, понимание, что даже если завтра тебя уволят, ты не пропадешь, ты уже знаешь что делать, и умеешь это делать.
При неспешном поиске без отрыва от работы можно искать вплоть до получения оффера/приглашения, и переоформления одним днем, по соглашению сторон - даже такое вполне бывает.
Конечно при появлении желания сменить работу обязательно нужно накопить подушку на несколько месяцев. Чтобы даже в худшем случае можно было комфортно найти новую работу, не боясь остаться без денег: такого рода страхи не только вызывают психологический дискомфорт, но и склоняют людей к тому, чтобы соглашаться на гораздо худшие условия, чем они могут получить. Т.е. отсутствие подушки кратно ухудшает как положение, так и перспективы, это недопустимо.