приплющить или «покусать» работает для R6, для LR6 опасно повреждением корпуса.
R6 заряжать нельзя, LR6 кратковременно и один-два раза и опыт сочетается с описанным в статье. LR6 это как раз Alkaline.
эффект «покусать» дает возможность добраться остаткам электролита до графитового стержня, помогает когда батарейка не столько разрядилась, сколько «высохла»
А ведь достаточно было всего лишь сделать сделать например миллион вложенных итераций хэша SHA256.
А можно тут по подробнее? Просто для не посвещенных не очень понятна фраза «миллион вложеных итераций»
Т.е. для вычисления hash делаем не
hash = sha(номер+соль), а
i = 1 000 000;
hash = номер + соль
while(i --> 0) hash = sha(hash);
?
И уже учтенные значения вычисляем так же и сравниваем hash?
«ноль» не изобрели еще :)
использовался прочерк, пропуск, чаша, получаша и т.д., но понятия «ноль» или ничего не существовало в общем смысле.
В Европе долгое время 0 считался условным символом и не признавался числом; даже в XVII веке Валлис писал: «Нуль не есть число». В арифметических трудах отрицательное число истолковывалось как долг, а ноль — как ситуация полного разорения.
Только по опыту обычно люди ждут что их «отправят», а сами выбирать куда им подрости не хотят. Ну и если человек достиг линейного уровня, то и растить его дальше смысла нет, как конвейер на заводе, собирает одну деталь хорошо, пусть дальше это делает и не надо его трогать.
За последние пару лет растились люди задачами и грамотным планированием трафика задача-погружение-попытка решения-обсуждения-решение-результат.
вопрос цены открыт
вот всё что выше написано умею, делал, трогал.
Только личное администрирование мертво уже лет как 5, только аутсорс (но опять же вопрос в цене)
CI/CD, L2, L3, BGP тянут на 3-5$к
есть статистика заражения, по ней никто на расстоянии 4 метра не заразился воздушно-капельным путем (видел статистику с Китая от февраля). На расстоянии 1,5 метра единичные заражения, но они попадают по статистическую ошибку, но факты были. (отсюда дистанцирование в 1.5 метра, а не в 4)
Если у вас контакт ближе чем 1.5 метра, то любой вдох — выдох может донести до вас необходимую порцию вируса, чтобы вирусной нагрузки хватило на заражение.
одиночный на улице в парке, не уверен, там и ветер и ультрафиолет.
А человек выше говорил про помещение.
Если вы недолго находитесь в помещении, то хорошим тоном будет использовать маску, чтобы «не загрязнить помещение», а если вы находитесь долго, то это обсуждается внутри коллектива. Коллективный иммунитет вырабатывается не только в рамках государства, но и в рамках малых групп.
Поддержу, часто встречал разработчиков, которые уходили в кодстайл и проходили через все паттерны и все правила рефакторинга по Фаулеру в задачах на 2 дня, что выливалось в 2 недели — месяц. И часто это было последствием неправильного менеджмента в начале карьеры (проф деформация), либо неправильная постановка задачи (например одноразовый скрипт, который будет выкинут в мусор через 2 недели, но сэкономит много денег в будущем)
при текущем росте (последние 5 лет) раньше появится бот, который будет задачи от менеджера переводить в SMART формат, только потом можно будет говорить о замене разработчиков.
«Если бы мне платили доллар каждый раз когда я слышу эту фразу» :)
Это и называется «риски».
Они бывают скрытыми и явными (в очень упрощенном виде). Если у вас оценка зависит от проекта или его тех устройства, то это явный риск и его можно учесть. Если проект ваш, то архитектура известна (либо у вас будут вопросы к тех персоналу), если проект чужой, то основные архитектуры описаны и это можно учесть, но «фактор» говнокода всегда присутствует.
Поэтому при оценке будет x часов архитектура 1, y часов архитектура 2, риски такие то, и это приемлемо.
а это зависит от задач. Если вы в своей жизни сделали 50 одинаковых фич в разных проектах, то знаете сколько времени это занимает. Если вы делаете фичу первый раз в жизни, то тут только декомпозиция.
Т.е. задачи делятся на 2 типа
1 производственные
2 исследовательские
Производственные легко считаются, так как описаны кем либо где либо и т.д. (чужой код не учитываю)
исследовательские «мне надо 3 дня, чтобы дать оценку между вилкой 100-1000 часов»
А эффективность разработчика не оценивается в затраченных им часах на работе. Если он полезен бизнесу, то получает больше денег. Вот в этот момент начинается движение на встречу работника и работодателя, подключаются софт скиллы, хард скиллы и деньги со стороны работодателя.
Но тут есть одно но. Производственные оценки обычно уже известны менеджерам или тимлидам, нет смысла ими напрягать линейного разраба.
Ну при 100 активных линейных задачах на человека можно брать ТМО (теория массового обслуживания) и не париться в управлении. Сроки и загрузки считать по эрлангу и добавлять известные риски комнады.
О сроках(датах) в такой постановке не может быть и речи.
Ну и при таком потоке нейронку можно натренировать оценивать задачи :)
Тут сразу сказали «выиграть заказ».
Т.е. речь идет об уровне КП. В статье хорошо всё описано когда заказ ваш, но нет понимания об оценках до получения заказа.
Ну и нельзя дать разработчику 2-3 дня, если клиент эти дни не оплатил.
R6 заряжать нельзя, LR6 кратковременно и один-два раза и опыт сочетается с описанным в статье. LR6 это как раз Alkaline.
эффект «покусать» дает возможность добраться остаткам электролита до графитового стержня, помогает когда батарейка не столько разрядилась, сколько «высохла»
А можно тут по подробнее? Просто для не посвещенных не очень понятна фраза «миллион вложеных итераций»
Т.е. для вычисления hash делаем не
hash = sha(номер+соль), а
i = 1 000 000;
hash = номер + соль
while(i --> 0) hash = sha(hash);
?
И уже учтенные значения вычисляем так же и сравниваем hash?
использовался прочерк, пропуск, чаша, получаша и т.д., но понятия «ноль» или ничего не существовало в общем смысле.
Только по опыту обычно люди ждут что их «отправят», а сами выбирать куда им подрости не хотят. Ну и если человек достиг линейного уровня, то и растить его дальше смысла нет, как конвейер на заводе, собирает одну деталь хорошо, пусть дальше это делает и не надо его трогать.
За последние пару лет растились люди задачами и грамотным планированием трафика задача-погружение-попытка решения-обсуждения-решение-результат.
пятница, 7 вечера :)
а зачем?
не моё мнение, сталкивался с такими
вот всё что выше написано умею, делал, трогал.
Только личное администрирование мертво уже лет как 5, только аутсорс (но опять же вопрос в цене)
CI/CD, L2, L3, BGP тянут на 3-5$к
Если у вас контакт ближе чем 1.5 метра, то любой вдох — выдох может донести до вас необходимую порцию вируса, чтобы вирусной нагрузки хватило на заражение.
А человек выше говорил про помещение.
Если вы недолго находитесь в помещении, то хорошим тоном будет использовать маску, чтобы «не загрязнить помещение», а если вы находитесь долго, то это обсуждается внутри коллектива. Коллективный иммунитет вырабатывается не только в рамках государства, но и в рамках малых групп.
В каждом «чисто мужском коллективе» большой численности, особенно если у коллектива это первая и основная работа на протяжении 5-10-15 лет.
Это и называется «риски».
Они бывают скрытыми и явными (в очень упрощенном виде). Если у вас оценка зависит от проекта или его тех устройства, то это явный риск и его можно учесть. Если проект ваш, то архитектура известна (либо у вас будут вопросы к тех персоналу), если проект чужой, то основные архитектуры описаны и это можно учесть, но «фактор» говнокода всегда присутствует.
Поэтому при оценке будет x часов архитектура 1, y часов архитектура 2, риски такие то, и это приемлемо.
Т.е. задачи делятся на 2 типа
1 производственные
2 исследовательские
Производственные легко считаются, так как описаны кем либо где либо и т.д. (чужой код не учитываю)
исследовательские «мне надо 3 дня, чтобы дать оценку между вилкой 100-1000 часов»
А эффективность разработчика не оценивается в затраченных им часах на работе. Если он полезен бизнесу, то получает больше денег. Вот в этот момент начинается движение на встречу работника и работодателя, подключаются софт скиллы, хард скиллы и деньги со стороны работодателя.
Но тут есть одно но. Производственные оценки обычно уже известны менеджерам или тимлидам, нет смысла ими напрягать линейного разраба.
О сроках(датах) в такой постановке не может быть и речи.
Ну и при таком потоке нейронку можно натренировать оценивать задачи :)
Если у вас в трекере все задачи «срочные», то по факту нет срочных задач
Т.е. речь идет об уровне КП. В статье хорошо всё описано когда заказ ваш, но нет понимания об оценках до получения заказа.
Ну и нельзя дать разработчику 2-3 дня, если клиент эти дни не оплатил.