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Ач, ощущения также подтверждают это, разряжается прямо на глазах, совсем не держит на холоде, а ОС показывает что батарея хорошая. Бывает и так
Батарея может быть многосекционной, ток кратно меньше на ячейку. Батареи приклеены широкой частью к теплорассеивающим пластинам, что немного облегчает им жизнь
Искать следующего и проходить собеседования можно без отрыва от текущей работы.
И не только можно, но и нужно. Хотя бы ради себя: ради того, чтобы адекватно воспринимать свою позицию на рынке и текущие потребности работодателей, чтобы иметь возможность подтягивать свои скилы до конкурентного уровня. Например так можно выяснить, что твой стек/умения/опыт уже малоинтересен рынку, и пора бы научиться чему-то новому. На собеседованиях ты общаешься с техническими специалистами, с руководством, получаешь информацию о внутренней кухне фирмы, ее потребностях, деятельности, каких-то проектах. И даже если ты на эти позиции даже минимально не проходишь - ничего страшного, это все равно на пользу тебе идет: с таким опытом приходит понимание в какую сторону нужно развиваться дальше.
В целом практика такого рода общения раскрепощает, позволяет тебе держаться на собеседованиях уверенно. Ты понимаешь как лучше себя подать, рассказать о своем опыте и ожиданиях, как лучше выяснить детали о фирме, какие вопросы стоит задавать, какие нет, как лучше отвечать на чужие вопросы, как лучше подготовить свое резюме. Ты понимаешь, что тебе всегда есть куда идти, и сменить работу на практике не так сложно, как казалось ранее. Все эти процессы становятся обыденностью, как сменить одежду например, это хорошо разгружает психику, снимает всякого рода переживания, позволяют смотреть в будущее с уверенностью, понимание, что даже если завтра тебя уволят, ты не пропадешь, ты уже знаешь что делать, и умеешь это делать.
При неспешном поиске без отрыва от работы можно искать вплоть до получения оффера/приглашения, и переоформления одним днем, по соглашению сторон - даже такое вполне бывает.
Конечно при появлении желания сменить работу обязательно нужно накопить подушку на несколько месяцев. Чтобы даже в худшем случае можно было комфортно найти новую работу, не боясь остаться без денег: такого рода страхи не только вызывают психологический дискомфорт, но и склоняют людей к тому, чтобы соглашаться на гораздо худшие условия, чем они могут получить. Т.е. отсутствие подушки кратно ухудшает как положение, так и перспективы, это недопустимо.
Недостатки есть везде. Но для меня главная ценность OpenSource - это то, что можно найти репозитории, где есть более-менее пригодное к использованию решение практически любой задачи. Многие из таких репозиториев будут мертвы, обновляются раз в несколько лет, или вообще не обновляются. Но даже в таких случаях есть возможность форкнуть репозиторий, и по-быстрому дофиксить решение, довести до работоспособного состояния, и использовать, вместо того чтобы изобретать что-то с нуля. И с большой вероятностью кто-то все это уже сделал и где-то уже существует готовое к использованию решение, т.к. потребность в схожих инструментах обычно бывает сразу у множества людей. Причем инструменты эти разных уровней, от простеньких скриптов до более-менее серьезного софта - выбор есть часто. А еще есть возможность изучить код и доработать его, или перенести на более удобный язык/стек. Или присоединиться к какому-то популярному инструменту и внести в него те правки, которых не хватает, вместо того чтобы повторять функционал с нуля. И решения эти иногда уникальны: например как-то возникла потребность скачивать видеозаписи из IP-камеры, официального инструмента для этого не нашлось, не считая интеграций с сетевыми шарами, зато нашлись чьи-то наработки на гитхабе, которые буквально за 20 минут удалось запустить и использовать, т.е. OpenSource позволил решить задачу, решением которой не озаботился сам производитель.
Это беда всех пакетных дистров, каждый выпуск может быть разный набор софта. Менее болезненно это на роллинг-дистрибутивах, типа арча или манжаро - там изменения наступают более плавно, и релизы не приносят столько много изменений. Но общая беда и тех и других, по сравнению с виндой - иерархия зависимостей: в винде можно держать несколько версий библиотеки, каждая под свой софт, а в этих дистрибутивах так сделать не получится. Если вдруг в системе оказываются программы, которые зависят сразу от двух-трех версий библиотеки, а такое иногда бывает, обязательно что-то ломается. Выходят из ситуации пока костылями типа флатпак, изолируя сам софт и все его зависимости в контейнерах, но это тоже не очень хорошее решение. Вот и получается что везде свои плюсы и минусы, везде свои особенности.
Это просто неконтролируемый рост сложности. Кто были первыми, те заложили основу на пустом месте, и им никто не мешал, они делали что хотели. Те, кто был после них, они уже вынуждены учитывать прежние наработки, их решения уже ограничены той архитектурой, что была заложена до них. Поэтому с каждым новым циклом разработки добавляются костыли, чтобы реализовать что-то, не предусмотренное архитектурой. И раз в n-лет принимается сложное решение допилить архитектуру, что порождает ситуацию n+1 стандарт. И все, кто приходит на поддержку этого многослойного пирога костылей и багов, они не в состоянии разобраться из чего он состоит (да и вряд ли человеку вообще по силам в этом разобраться), и просто наворачивают сверху еще один слой реализации уже существующих технологий, потому что только этот слой им и знаком, они его сами сделали. Получается гора кода, которую никто по сути не в состоянии контролировать, и ее просто "обслуживают": фиксят очевидные баги, добавляют где-то сбоку новый фичи, стараясь не залазить слишком глубоко в основной код, чтобы ничего случайно не поломать, как оно там работает уже давно никто толком не знает, любой случайно задетый костыль может оказаться несущим. Хорошо быть первым и творить, и плохо быть тем, кто приходит на поддержку легаси, когда уже ничего изменить нельзя и никакого пространства для творчества просто не осталось, остается лишь продлевать жизнь полумертвому коду, латая бесконечные баги
Мерзкая ситуация на самом деле. Ресурсов и воли все это выкинуть и реализовать как нужно ни у кого просто нет. Да собственно нет возможности даже просто перечислить фичи, которые нужны, и описать как они должны работать - этого уже никто не знает, экспертиза давно утеряна, люди ушли, а у тех кто еще доступен давно все стерлось в памяти
А в крупных корпорациях все это сдобрено еще и тоннами бюрократии: отдельный разработчик не имеет права ничего менять, пока это изменение не согласуют сто инстанций сверху, что произойдет в лучшем случае через несколько лет, после сотен обсуждений на всех уровнях управления, когда сам автор уже давно давно забыл об этом, или даже уже уволился
Так вроде никто в опасных условиях и не должен пытаться сесть - полосы закрывают, всем кто еще в воздухе командуют лететь в другой аэропорт, где поспокойнее
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Ач, ощущения также подтверждают это, разряжается прямо на глазах, совсем не держит на холоде, а ОС показывает что батарея хорошая. Бывает и так
Батарея может быть многосекционной, ток кратно меньше на ячейку. Батареи приклеены широкой частью к теплорассеивающим пластинам, что немного облегчает им жизнь
Искать следующего и проходить собеседования можно без отрыва от текущей работы.
И не только можно, но и нужно. Хотя бы ради себя: ради того, чтобы адекватно воспринимать свою позицию на рынке и текущие потребности работодателей, чтобы иметь возможность подтягивать свои скилы до конкурентного уровня. Например так можно выяснить, что твой стек/умения/опыт уже малоинтересен рынку, и пора бы научиться чему-то новому. На собеседованиях ты общаешься с техническими специалистами, с руководством, получаешь информацию о внутренней кухне фирмы, ее потребностях, деятельности, каких-то проектах. И даже если ты на эти позиции даже минимально не проходишь - ничего страшного, это все равно на пользу тебе идет: с таким опытом приходит понимание в какую сторону нужно развиваться дальше.
В целом практика такого рода общения раскрепощает, позволяет тебе держаться на собеседованиях уверенно. Ты понимаешь как лучше себя подать, рассказать о своем опыте и ожиданиях, как лучше выяснить детали о фирме, какие вопросы стоит задавать, какие нет, как лучше отвечать на чужие вопросы, как лучше подготовить свое резюме. Ты понимаешь, что тебе всегда есть куда идти, и сменить работу на практике не так сложно, как казалось ранее. Все эти процессы становятся обыденностью, как сменить одежду например, это хорошо разгружает психику, снимает всякого рода переживания, позволяют смотреть в будущее с уверенностью, понимание, что даже если завтра тебя уволят, ты не пропадешь, ты уже знаешь что делать, и умеешь это делать.
При неспешном поиске без отрыва от работы можно искать вплоть до получения оффера/приглашения, и переоформления одним днем, по соглашению сторон - даже такое вполне бывает.
Конечно при появлении желания сменить работу обязательно нужно накопить подушку на несколько месяцев. Чтобы даже в худшем случае можно было комфортно найти новую работу, не боясь остаться без денег: такого рода страхи не только вызывают психологический дискомфорт, но и склоняют людей к тому, чтобы соглашаться на гораздо худшие условия, чем они могут получить. Т.е. отсутствие подушки кратно ухудшает как положение, так и перспективы, это недопустимо.
Недостатки есть везде. Но для меня главная ценность OpenSource - это то, что можно найти репозитории, где есть более-менее пригодное к использованию решение практически любой задачи. Многие из таких репозиториев будут мертвы, обновляются раз в несколько лет, или вообще не обновляются. Но даже в таких случаях есть возможность форкнуть репозиторий, и по-быстрому дофиксить решение, довести до работоспособного состояния, и использовать, вместо того чтобы изобретать что-то с нуля. И с большой вероятностью кто-то все это уже сделал и где-то уже существует готовое к использованию решение, т.к. потребность в схожих инструментах обычно бывает сразу у множества людей. Причем инструменты эти разных уровней, от простеньких скриптов до более-менее серьезного софта - выбор есть часто. А еще есть возможность изучить код и доработать его, или перенести на более удобный язык/стек. Или присоединиться к какому-то популярному инструменту и внести в него те правки, которых не хватает, вместо того чтобы повторять функционал с нуля. И решения эти иногда уникальны: например как-то возникла потребность скачивать видеозаписи из IP-камеры, официального инструмента для этого не нашлось, не считая интеграций с сетевыми шарами, зато нашлись чьи-то наработки на гитхабе, которые буквально за 20 минут удалось запустить и использовать, т.е. OpenSource позволил решить задачу, решением которой не озаботился сам производитель.
Это беда всех пакетных дистров, каждый выпуск может быть разный набор софта. Менее болезненно это на роллинг-дистрибутивах, типа арча или манжаро - там изменения наступают более плавно, и релизы не приносят столько много изменений. Но общая беда и тех и других, по сравнению с виндой - иерархия зависимостей: в винде можно держать несколько версий библиотеки, каждая под свой софт, а в этих дистрибутивах так сделать не получится. Если вдруг в системе оказываются программы, которые зависят сразу от двух-трех версий библиотеки, а такое иногда бывает, обязательно что-то ломается. Выходят из ситуации пока костылями типа флатпак, изолируя сам софт и все его зависимости в контейнерах, но это тоже не очень хорошее решение. Вот и получается что везде свои плюсы и минусы, везде свои особенности.
Это просто неконтролируемый рост сложности. Кто были первыми, те заложили основу на пустом месте, и им никто не мешал, они делали что хотели. Те, кто был после них, они уже вынуждены учитывать прежние наработки, их решения уже ограничены той архитектурой, что была заложена до них. Поэтому с каждым новым циклом разработки добавляются костыли, чтобы реализовать что-то, не предусмотренное архитектурой. И раз в n-лет принимается сложное решение допилить архитектуру, что порождает ситуацию n+1 стандарт. И все, кто приходит на поддержку этого многослойного пирога костылей и багов, они не в состоянии разобраться из чего он состоит (да и вряд ли человеку вообще по силам в этом разобраться), и просто наворачивают сверху еще один слой реализации уже существующих технологий, потому что только этот слой им и знаком, они его сами сделали. Получается гора кода, которую никто по сути не в состоянии контролировать, и ее просто "обслуживают": фиксят очевидные баги, добавляют где-то сбоку новый фичи, стараясь не залазить слишком глубоко в основной код, чтобы ничего случайно не поломать, как оно там работает уже давно никто толком не знает, любой случайно задетый костыль может оказаться несущим. Хорошо быть первым и творить, и плохо быть тем, кто приходит на поддержку легаси, когда уже ничего изменить нельзя и никакого пространства для творчества просто не осталось, остается лишь продлевать жизнь полумертвому коду, латая бесконечные баги
Мерзкая ситуация на самом деле. Ресурсов и воли все это выкинуть и реализовать как нужно ни у кого просто нет. Да собственно нет возможности даже просто перечислить фичи, которые нужны, и описать как они должны работать - этого уже никто не знает, экспертиза давно утеряна, люди ушли, а у тех кто еще доступен давно все стерлось в памяти
А в крупных корпорациях все это сдобрено еще и тоннами бюрократии: отдельный разработчик не имеет права ничего менять, пока это изменение не согласуют сто инстанций сверху, что произойдет в лучшем случае через несколько лет, после сотен обсуждений на всех уровнях управления, когда сам автор уже давно давно забыл об этом, или даже уже уволился
Работать на окладе 30к программистом - ну такое
Так вроде никто в опасных условиях и не должен пытаться сесть - полосы закрывают, всем кто еще в воздухе командуют лететь в другой аэропорт, где поспокойнее