Конечно подходят. В основном, нужно смотреть на тип переключателя. Если брать silent версии линейных или тактильных, то будет очень даже тихо. Главное не купить кликающие, тогда праведный гнев вам гарантирован

ABS пластик мягче PBT и зачастую толщина самого кейкапа меньше. Поэтому может быть слегка тише, но не намного. Ещё ABS, в основном гладкие, а PBT слегка шершавые.
Субъективно разница в тактильных ощущениях намного больше, чем в тишине. Но лучше попробовать на своём опыте, так как цены на ABS в среднем меньше, чем на вторые

В мене є і к2 і к3. Перша мені подобається набагато більше. За розмірами вони майже однакові, тільки к2 вище. Це ніяк не заважає, хоча чув про неї панані відгуки за висоту. Але це було у першій версії, у другій зробили кращий кут нахилу. к3 дуже крута, але легше промахуєшся із-за профілю ковпачків та коротший хід свічу теж не додає задоволеня. OEM профіль на к2 набагато кращий та й стандартні свічі дозволяють змінити їх на велику кількість кастомних. Про китайські клавіатури нічого не можу сказати, але думаю що софт так якість можуть бути гіршими за keychrone.

Если решение принято, то зачем тратить время на разбирания со старой технологией?

Это может быть побочным эффектом миграции, потому что в процессе может возникнуть необходимость что-то переписать/переконфигурировать. А для этого надо хорошо разбираться в новой и старой технологии.

Что? Вам дали систему в состоянии Х. Вы ничего не делали и у «системы сопровождаемость ухудшается или перформанс проседает». Просто протухло со временем?

Если система писалась условные 5-10 лет назад, то она могла быть рассчитана, к примеру на одновременное использование 100 пользователями, а база данных имела приемлемый ответ при условных 100 000 записей. Но за это время кол-во пользователей увеличилось и данные накопились. И вот вам

Просто протухло со временем?

Например, мы мигрировали вермию джавы, потому что в той которую мы использовали, была критическая уязвимость (с ТЛС вроде). Можно было бы заказть фикс у оракла, но это было бы очень дорого, проще было обновить систему.

Я же не против вынужденной миграции, но это не единственная причина для миграции. Вообще если версия какой-то библиотеки уже не поддерживается и критические уязвимости/баги там не фиксятся, то лучше бы заранее обновиться.

Спасибо за инфу

Согласен, что перегнул с 99% процентами. Не учитывал компании, которые могут позволить собственные датацентры. Потому что вариант миграции в таких объемах — это явно вне моей компетенции и таким опытом не владею. Но так как работал на проекте, который анализировал перформанс инфраструктур сознанных при помощи VMware vSphere, то могу сказать, что только поддержание всего этого счастья в идеальном состоянии стоит немалых денег. Поэтому мне даже интересно сравнить затраты таких компаний на содержание своей инфраструктуры vs AWS/GCE/Azure на каких-то партнерских правах.

+ интересно бы посмотреть на источник информации по поводу 80% компаний Fortune 500

Не аргумент, ибо можно разбираться и без внесения рисков для проекта

Конечно можно и тут не поспоришь. Но идея заключается в том, что если принято решение мигрировать, то можно разобраться еще лучше. Сомневаюсь что разработчик через пол года, год ковыряния одного проекта будет с большим желанием разбираться во всех тонкостях, когда есть список заданий, которые нужно выполнить.

Еще один классный аргумент: мы за ваши деньги будем изучать технологию которую больше не будем использовать и ту которую __хотим__ использовать (при том что ваша работала нормально).

Уже упоминал в статье, что нужна четкая аргументация и миграция ради миграции или меркантильных соображений — не вариант.

Для миграции может быть только одна причина — технология с которой мигрируют не решает бизнес-задач.

Под фразой не решение бизнес-задач можно вообще все что угодно написать, что вы с успехом и сделали:

Технология содержит критическую уязвимость или баг, которые нельзя/очень дорого исправлять.

Если этот критический баг никак не влияет на заказчика и он может забить на него не потратив денег, то это не бизнес-задача для него.
А вот если сопровождаемость ухудшается или перформанс проседает — это тоже легко может подпадать под бизнес-цели, так как в долгосрочной перспективе это может стоит больших денег.

Тренды трендами, но нужно отталкиваться от нужд проекта и выбирать оптимальный вариант. Что бы работать с выделенными серверами и настраивать там инфраструктуру нужно тратить много времени и сил, если вы программист. Нужно докинуть базу данных или кэш на отдельный сервак — дополнительные сложности, если нужны лоад балансеры — еще сложнее. В общем тема обширная и достойна отдельной статьи.

Как и писал, миграция ради миграции — это плохо. Но в любом серьезном проекте перед миграцией придется пройти несколько кругов ада, что бы аргументировать необходимость. Реализовать, как минимум тестовую/минимальную миграцию, что бы показать на практике плюсы минусы и понять обьем миграции и усилий. А потом уже пойти на поклон к заказчику. Не вдавался в такие детали, потому что статья не про это, а про то, что миграция может дать сильный буст многим качествам (включая софт скилы) разработчика.

Так как Дмитрий ушел через пол года, то ответ на вопрос в заголовке очевиден. Но за рвение к самосовершенствованию однозначно плюс.

Очень интересная тема, спасибо за статью

Согласен по поводу софт скилов и даже писал на эту тему статью dou.ua/...​lenta/articles/hum-skills но это уже выходит за рамки этой статьи

Круто, сам вот начал писать — помогает.

Классный вариант, сразу после увольнения еще отключил инет в телефоне. Помогает!

Со спортом все просто. Играю в футзал, и когда приходишь на тренировки или игры в разобранном состоянии, то сразу же травмируешься ( После одной из травм восстанавливался более двух месяцев.

), мой любимый коуб на эту тему coub.com/view/2hyqm