Information
- Rating
- 9,005-th
- Registered
- Activity
Specialization
Software Architect, Low level system programming
Lead
From 5,000 $
Git
English
Research work
Software development
Programming microcontrollers
Assembler
C
C++
Specialists recruitment
Interview
Это конечно так, но кто и как будет подбирать людей в пары? Только метод проб и ошибок? Слишком много факторов — строить матрицу совместимости людей? И что делать в коллективе матерых интровертов, которых от ежедневных встреч-то тошнит? Нужна мотивация для людей, а не только для тимлида.
Если уж совсем честно, я нигде не видел ничего идеального. ПП тоже не идеально, и уж тем более независимо от его наличия нужна и документация и ревью и все остальное — поэтому это первично, а ПП — вторично. Может конечно есть какой-то эффект от парного ревью или парного написания документации, но я не уверен.
Если ПП практикует только часть (и тем более не самая большая) коллектива, то это вряд ли станет дополнительным фактором сплочения. Это примерно как сказать, что курение сплачивает коллектив, потому что в курилке народ что-то дополнительно обсуждает, даже если большая часть не курит и курить никто не заставляет. Однако ж курение никто так не рекламирует для увеличения эффективности программистов :)
Вообще, когда речь заходит о любых совместных, да еще и длительных, действиях, то вперед выдвигается совместимость людей, психология, социология, и т.д., а умение программировать уходит на задний план. Программисты часто бывают интроверты и им психологически тяжело выполнять совместную работу на регулярной основе.
Поэтому есть риск скатиться в ситуацию, когда кто-то один пишет одну часть, а второй другую (относительно независимую) или вообще думает о чем-то другом пока компьютер занят первым, хотя на бумаге они работают в паре — людям проще самим «поделить» задачу внутри и начать пересекаться очень слабо. Особенно опять же актуально для интровертов, которые не любят пускать посторонних в интимный процесс раздумий и попыток написания кода.
Что еще? По опыту ревью (да и аудит) кода надо делать независимо, а не параллельно в паре. В паре люди проникаются общей идеей и начинают не замечать ее недочеты, и чем дальше, тем больше. Переубедить может только независимый взгляд на код человека, который желательно вообще его не писал до этого. Так что для ревью это почти никак не экономит время, а синтаксические и стилистические ошибки проще ловить разными утилитами, а не глазами людей.
Про модный «онбординг» — грамотного специалиста надо учить архитектуре, основам и умению думать самостоятельно. В паре можно поработать недолго в самом начале. Иначе есть риск получить человека, который только в паре и будет способен что-то делать, а самостоятельно — не очень, потому что будет ждать совета от коллеги в паре.
Шаринг кода/процессов/знаний и т.д. все же лучше формализовывать в виде хотя бы статей на внутренней вики или чем-то подобном. Во-первых, это удобнее: можно сослаться на документ, а не объяснять что-то каждый раз. Во-вторых, в этом случае новые знания охватывают сразу всех, а не только двух в паре и обсуждать на вики можно именно их, не отвлекаясь на код. А если появилось что-то действительно важное — лучше периодически устраивать внутренние «конференции» и обсуждения проблем и новых практик в коде во всей команде.
Что касается сплочения коллектива — опять же спорно, что парные практики так уж сплачивают его. Люди все очень разные, если часть людей будет работать в паре, а часть категорически нет — значит ли это что сплачиваться будет только часть коллектива? По моему опыту хорошо сплачивает коллектив периодические встречи (строго добровольные!) вне рабочей тематики и регулярный мониторинг настроений и возможностей коллектива и подстройка планов под эти настроения. Люди ценят, когда о них заботятся, и еще более ценят, когда эта забота пусть и скромная, но зато регулярная.
Собственно, из-за вышеуказанного, я нигде особо не видел хорошо работающих парных практик. Периодически, те, кому удобно и легко и сами могут образовывать пары для решения задач совместно — это же не запрещается, но массово это похоже не работает.
Причем вышек 5g понадобится много, т.к. охват у них небольшой, поэтому видимо 5g будет только в центрах городов-миллионников, и смысла в нем будет не много. Вообще у нас площадь покрытия падает почти экспоненциально с ростом этого самого g (2g — наибольшее покрытие, 4g — наименьшее).
Возможно зависит от модели. Не для всех моделей есть «правильное» рекавери с поддержкой шифрования и патчи для vbmeta.
Согласен, могли бы разрешить запись для рута. Теперь остается только потрошить прошивку заранее, до загрузки в телефон.
Сейчас приходится шерстить xda/4pda в поисках нужной информации, но для новых моделей ее нет вообще (пока кто-нибудь не пройдется по всем граблям). Вот новую подлянку придумали начиная с android q/10 — после отключения доверенной загрузки слетает шифрование раздела данных. Зачем так сделано?..
Хотя возможно на этот вопрос ответит 2-ая часть? Тогда с удовольствием прочитаю.
Просто при поиске моделей хочется обходить эти стороной. Фильтра в яндекс.маркете такого нет, к сожалению.
Согласен, но это нисколько не противоречит моему примеру выше. В примере 2**-45 вполне представимое точно число (т.е. оно только одно соответствует этой записи, а не какой-нибудь диапазон чисел), использующее вообще только 1 бит мантиссы (о чем и говорит запись в сыром виде — 0x29000000), тем не менее имеющее более 16 десятичных знаков при точном переводе из двоичного вида. На то она и «плавающая точка», что имеет «плавающую точность», зависящую от диапазона переводимых чисел — от 8 до 105 знаков (для 32-х битных float). Если не верите мне, смотрите кучу примеров в сети, например randomascii.wordpress.com/2012/03/08/float-precisionfrom-zero-to-100-digits-2
Причем тут перевод 53 единиц в десятичное число?
Возьмем пример проще — абсолютно точно представимое число даже для 32-х битного float = 2**-45 (0x29000000). А теперь возведем 2 в степень -45 и посчитаем сколько это: 2.8421709430404007434844970703125e-14, как видите знаков сильно больше 16-ти, и все точные, т.к. число представимо точно. Вообще 32-х битные float могут иметь до 105 точных знаков 2**-149 = 1.40129846432481707092372958328991613128026194187651577175706828388979108268586060148663818836212158203125e-45, а уж 64-битный double так вообще 752 (2**-1074), а уж если брать 80-битный long double, то и вовсе 11497! Не буду копировать это число, текст будет слишком большим :)
Сначала была система полного доверия, типа ДОС, где каждая программа могла вытворять все что угодно, но и защищаться могла тоже как угодно.
Потом сделали разделение на пространство пользователя и ядра, «защищенный режим» и все такое.
Спустя некоторое время коду ядра уже нельзя было просто доверять, поэтому добавили слой гипервизора.
Однако ж гипервизорам тоже оказывается доверять нельзя. Поверх них добавили trustzone/EL3 (arm) или sgx/txt (intel).
А вдруг враги проберутся и туда? Добавили обвязку, которая стартует раньше всех и контролирует процессор, причем сначала изнутри (intel ME), а потом и снаружи.
Что дальше? Теперь весь «правильный» код надо подписывать, а за неподписанным следить, чтобы некоторые операции он не выполнял вообще. Разумеется следить будем с самого низа, потому что доверять выше никому нельзя — там же уже окопались враги.
Что дальше? Цензура кода уже есть, дискриминация тоже, ограничение в правах давно уже, подпись выданная уполномоченными органами тоже имеется, концлагеря (песочницы и виртуалки) тоже в наличии, что еще осталось-то? Социальный рейтинг?
Вот такой прогресс. А вирусы, а что вирусы? Они и не замечают похоже всей этой возни.
В остальном же, пробуя беззеркалки я, честно (на свой непрофессиональный взгляд) не увидел каких-то отличий от старых добрых зеркалок по части качества. Но сейчас это стало модным, так что скоро возможно зеркалок будут выпускать все меньше и меньше. Наверное, у беззеркалок всё решает меньший вес и габариты, правда постоянно работающий сенсор дает чуть больше шума на фото.