А разряжать конденсатор куда предполагается, на сопротивление или индуктивность? В идеальном случае второй вариант не даст изменения массы всей системы. Для первого варианта, до разряда конденсатора на сопротивление, система будет иметь ту же массу, а во время разряда тягу даст (или нет) тепловое излучение с сопротивления.
Похоже на поведенческие юнит тесты на моках, т.н. mockist подход — один из двух подходов (школ) в юнит тестировании описанных в статье Фаулера Mocks Aren't Stubs. Я в основном использую моки. Классические тесты использую в основном для сервисов хранения (запись/чтение в память, файл).
Моя «пирамида» примерно такая-же 90% юнит + 10% «интеграционных» тестов. При этом мои интеграционные тесты (в отличие от классических) проверяют исключительно сборку объектов — возврат результата из фабрики + assert'ы для зависимостей внутри классов; что делает их очень быстрыми и непротухающими.
For verification that the transparent drop consists of molten hydroxide, it was quickly removed out of the reaction vessel at the stage shown in Figure 1E with a stainless steel mesh. After solidification the drop was crumbled to powder which was spread on a KCl window, then molten and resolidified. Finally, transmission infrared spectra were recorded using a Bruker Equinox Fourier transform infrared spectrometer with an optical resolution of 2 cm-1 The reference spectrum was analogously recorded by prepa
ring a 1:1 mixture of NaOH (Fluka, 99%) and KOH (Sigma-Aldrich, 99.99%). To study the various details of the reactions, additional high-speed recording with up to 30000 frames per second was performed by a MotionProY4 high-speed camera of IDT/Imaging Solutions.
Хм, верно. Давно смотрел эту тему. Видимо идея появления прозрачности из-за потери электронов моя собственная, и скорее всего не имеет ничего общего с реальностью. К сожалению не могу прочесть статью. В приведенном мною видео Мейсон сомневается в верности предположения о природе явления. Возникает ряд вопросов, на которые я не нашел внятных ответов. Есть ли подтверждения того, что прозрачная капля является гидроксидом? Способна ли поверхность воды удерживать тело большей плотности (капля давит на водяной пар, пар давит на воду)? Почему раскаленный алюминий не плавает на поверхности при сходных условиях? Почему капля чернеет перед тем как стать прозрачной?
В supporting information есть видео рекции металла с водой без взрыва
В конце капля все-таки взрывается. Вот если бы ее можно было спасти и провести анализ состава…
Вот демонстрация youtu.be/DJGVZNth68k
Если вкратце, материал пропускает или не пропускает видимый свет в зависимости от наличия электронов, способных поглотить энергию проходящих через материал фотонов. В металлах — это как раз валентные электроны. Электроны на нижних уровнях имеют слишком большой потенциальный барьер, и энергии фотонов видимого света недостаточно, чтобы их поднять на более высокий уровень. Таким образом, при потере валентых электронов (в реакции с водой), натрий становится прозрачным.
Конечно, каждая сторона выставляет информацию в определенном свете. Но не все так категорично.
Что касается приведенных изданий, можно сказать, что они плохо используют инфоповод из-за своей «попсовости». Крупные ресурсы, ориентированные на технологии и науку, обязательно публикуют обновления в виде отдельных статей с заголовками, чтобы увеличить посещение сайта и просмотр рекламы.
Давайте оставаться объективными. На остальных ресурсах так же достаточно заголовков об успешном запуске FH. Про разбившийся блок будут писать все мировые СМИ так как есть инфоповод.
Возможно у вас другая практика ревью и структура команды, размер проекта, время жизни проекта…
У нас плоская структура (Scrum), тимлида как такового нет, есть более опытные разработчики и менее опытные. Историю читают все. Знания шарятся между всеми разработчиками проекта (уменьшаем bus-factor) в том числе посредством код ревью. Для эффективности этого процесса нужно минимизировать изменения, иначе код ревью превращается в проверку код-стайла, так как понять суть изменений слишком сложно.
Для долгоживущего проекта время разработки не критично, критично время внесения изменений. И feature toggl'ы — позволяют поддерживать это время на приемлемом уровне, так же как и SOLID, юнит тесты, TDD.
CI можно гонять для всех юнит тестов и для интеграционных тестов продакшн конфигурации. Но это отдельная тема.
Если работать с большими изменениями, то я пожалуй соглашусь, что мердж будет менее трудозатратным (у меня был такой опыт).
Однако большие изменения возникают не сами по себе, а из подхода к разработке. Введение feature-toggle'ов позволяет коммитить частично готовый функционал (например набор оттестированных классов/функций), что способствует работе со свежим мастером и быть в курсе изменений в нем. Также большие изменения почти неизбежны при работе с legacy (читай «говно-») кодом, который требует обширного рефакторинга, но после некоторого времени, при правильном подходе, эта проблем уходит.
Тут конечно дело вкуса. Для большого, динамично развивающегося проекта я выбираю trunk-based с feature-toggle'ми.
Конфликты в случае rebase просто изчезают, превращаются в осмысленные изменения, как если бы автор начал разработку с коммита, на который был сделан rebase. У нас есть описание коммита, в котором указано, что было сделано в этом коммите, это намного лучше, чем изменения поверх устаревшего мастера с последующим мердж с конфликтами, где нам нужно сначала понять изменения (при этом вспомнить как выглядел мастер неделю назад), потом понять как эти изменения были влиты в мастер.
Коммиты нужно стараться минимизировать, это упростит код ревью и сделает историю более подробной и понятной (для аннотаций и bisect в том числе). Конечно такая организация требует дополнительных усилий, как и поддержание чистоты кода.
Относительно хаоса: а зачем вы используете историю, что оно вас волнует?
Да просто посмотреть лог за неделю, что было сделано. Приятнее видеть список, а не гордиев узел из мердж коммитов.
Коммит должен представлять законченный набор изменений. Если это так, то имеет смысл влить его в мастер, а не держать в ветке.
Я собственно веду к подходу trunk-based разработки, к которому в итоге пришел за много лет, так как этот подход дает стабильный мастер (с возможностью релиза с любого коммита) при большом количестве ежедневных изменений, простоту код-ревью, список изменений понятный каждому участнику проекта.
На мой взгляд, слияния — бесполезные коммиты, которые представляют собой скрещивание бульдога с носорогом, смысловой нагрузки в таких изменениях нет, невозможно понять мотивацию автора мердж коммита при разрешении конфликтов.
Инкрементальную, одномерную последовательность коммитов намного легче анализировать.
А зачем мерджить пачку коммитов? Как в этом случае вообще гарантировать работоспособность каждого коммита в отдельности? CI обычно запускается на ветку, то есть на последний коммит.
Сливание пачки в один коммит решает эту проблему.
Что касается rebase, его делает автор изменений, убедившись, что все работает на свежем мастере. Разрешение конфликтов мало чем отличается от такового в случае merge, но в последнем мы получаем два коммита на одно изменение, что добавляет хаоса в проект.
загрузка изображения в память происходит в главном потоке
это относится как раз ко второму (UIImageView). Сам UIImage и его кеш потокобезопасны, а UIImageView должен использоваться только на главном потоке. Во время рендеринга UIImage считывает данные из файла, блокируя поток на это время. На WWDC (довольно давно) была презентация на эту тему.
Моя «пирамида» примерно такая-же 90% юнит + 10% «интеграционных» тестов. При этом мои интеграционные тесты (в отличие от классических) проверяют исключительно сборку объектов — возврат результата из фабрики + assert'ы для зависимостей внутри классов; что делает их очень быстрыми и непротухающими.
В конце капля все-таки взрывается. Вот если бы ее можно было спасти и провести анализ состава…
на примере калия youtu.be/BIGMfai_ICg
Если вкратце, материал пропускает или не пропускает видимый свет в зависимости от наличия электронов, способных поглотить энергию проходящих через материал фотонов. В металлах — это как раз валентные электроны. Электроны на нижних уровнях имеют слишком большой потенциальный барьер, и энергии фотонов видимого света недостаточно, чтобы их поднять на более высокий уровень. Таким образом, при потере валентых электронов (в реакции с водой), натрий становится прозрачным.
Что касается приведенных изданий, можно сказать, что они плохо используют инфоповод из-за своей «попсовости». Крупные ресурсы, ориентированные на технологии и науку, обязательно публикуют обновления в виде отдельных статей с заголовками, чтобы увеличить посещение сайта и просмотр рекламы.
Давайте оставаться объективными. На остальных ресурсах так же достаточно заголовков об успешном запуске FH. Про разбившийся блок будут писать все мировые СМИ так как есть инфоповод.
У нас плоская структура (Scrum), тимлида как такового нет, есть более опытные разработчики и менее опытные. Историю читают все. Знания шарятся между всеми разработчиками проекта (уменьшаем bus-factor) в том числе посредством код ревью. Для эффективности этого процесса нужно минимизировать изменения, иначе код ревью превращается в проверку код-стайла, так как понять суть изменений слишком сложно.
Для долгоживущего проекта время разработки не критично, критично время внесения изменений. И feature toggl'ы — позволяют поддерживать это время на приемлемом уровне, так же как и SOLID, юнит тесты, TDD.
CI можно гонять для всех юнит тестов и для интеграционных тестов продакшн конфигурации. Но это отдельная тема.
Однако большие изменения возникают не сами по себе, а из подхода к разработке. Введение feature-toggle'ов позволяет коммитить частично готовый функционал (например набор оттестированных классов/функций), что способствует работе со свежим мастером и быть в курсе изменений в нем. Также большие изменения почти неизбежны при работе с legacy (читай «говно-») кодом, который требует обширного рефакторинга, но после некоторого времени, при правильном подходе, эта проблем уходит.
Тут конечно дело вкуса. Для большого, динамично развивающегося проекта я выбираю trunk-based с feature-toggle'ми.
Коммиты нужно стараться минимизировать, это упростит код ревью и сделает историю более подробной и понятной (для аннотаций и bisect в том числе). Конечно такая организация требует дополнительных усилий, как и поддержание чистоты кода.
Да просто посмотреть лог за неделю, что было сделано. Приятнее видеть список, а не гордиев узел из мердж коммитов.
Коммит должен представлять законченный набор изменений. Если это так, то имеет смысл влить его в мастер, а не держать в ветке.
Я собственно веду к подходу trunk-based разработки, к которому в итоге пришел за много лет, так как этот подход дает стабильный мастер (с возможностью релиза с любого коммита) при большом количестве ежедневных изменений, простоту код-ревью, список изменений понятный каждому участнику проекта.
Инкрементальную, одномерную последовательность коммитов намного легче анализировать.
Сливание пачки в один коммит решает эту проблему.
Что касается rebase, его делает автор изменений, убедившись, что все работает на свежем мастере. Разрешение конфликтов мало чем отличается от такового в случае merge, но в последнем мы получаем два коммита на одно изменение, что добавляет хаоса в проект.
это относится как раз ко второму (UIImageView). Сам UIImage и его кеш потокобезопасны, а UIImageView должен использоваться только на главном потоке. Во время рендеринга UIImage считывает данные из файла, блокируя поток на это время. На WWDC (довольно давно) была презентация на эту тему.
Стоило бы помнить об обратной ситуации несколько лет назад, когда все приложения начали поголовно менять удобный таббар на гамбургер (VK в том числе).