Я так много раз делал с ноутбуками, когда их ещё можно было разбирать более одного раза)) Если нормально высушить, проблем нет, правда именно платы прямо струёй воды не мыл.
Если код проприетарный - хрен пойми как его исследовать, но зато понятно к кому претензии. А если open source - все наоборот - исследовать легче, но не к кому претензии предъявлять. Сколько еще таких мелких либ используется, сколько еще таких сюрпризов будет...
Допустим схема может быть защищена авторским правом. Но если на ней использованы микросхемы, операционники или там даже составные транзисторы, т.е. по сути устройства у которых есть своя схема внутреннего устройства, с другими правами, тогда как? Бездонная тема для юристов и патентных троллей?
Я лично такое видел в виде статьи в одной местечковой газете. Кроме головной боли и давления, еще школьники стали агрессивными. Но БТС, о которой шла речь в статье, на тот момент к электропитанию еще не была подключена.
100%. Нормальная машинка стоит дороже дешевой гитары. А дешевая машинка которая установлена в дешевой гитаре - просто не дает ее нормально настроить. А если и дает, то не держит строй. И это если не пользоваться этой самой машинкой. А если попробовать воспользоваться, то сразу хочется другую гитару, где ее нет.
У меня со временем астигматизм развился и требования к монитору снизилось)) А до того, лично у меня реально влияло на утомляемость глаз число точек на дюйм (PPI) - точно числа не скажу, но на слабых в этом плане мониторах, глаза реально "цеплялись" за картинку и сильно чувствовалось усталость. Может даже из-за работы за таким монитором и снизилось зрение за несколько лет.
kotlin на бекэнде вполне себе ок, проверено лично в разных проектах. особенно если иметь в виду, что intellij насчёт java нигде в документации не использует слово совместимость (compatibility), они пишут interoperability.
Китай вроде только на третьем месте по добыче лития. Причем первые два (Чили и Австралия) добывают больше раз в шесть. Китай лидер по вредному производству , связанному с обработкой добытой руды, но никак не по добыче самого лития.
Несколько бывших фейсбукеров рассказали несколько офисных слухов (более чем десятилетней давности). Вряд ли это можно считать реальной статьей, описывающей причины принятия такого решения.
Я столкнулся с тем, что если у некоторых компонентов (отдельных java проектов) файл build.gradle (да и сам gradle) не обновлялся достаточно давно, то задействование bom с помощью platform (и тем более force platform) приносит кучу проблем, по сути ломая механизм разрешения зависимостей. Так что лучше перед использованием bom избавиться от зоопарка версий gradle (если он конечно есть), а также привести скрипты build.gradle к "общему знаменателю" - убрать, например, compile/runtime и другие устаревшие штуки.
Мне кажется стоило добавить о коллекциях и sequence в kotlin, о их влиянии на performance, и о том, что некоторые операции .collect() при совпадении ключа, в java вызовут ошибку, которая призовет к использованию другого, соответствующего коллектора (где можно указать, что делать в такой ситуации), а то время как в Котлин все отработает "молча", но не всегда так, как нужно автору кода. По моему опыту, это частые подводные камни при подобном переходе.
Хуже, это Rasathurai Karan.
Интересно, вообще из какого года эти советы
Если kotlin вспомнили, тогда и Ceylon нужно было вспомнить
Я так много раз делал с ноутбуками, когда их ещё можно было разбирать более одного раза))
Если нормально высушить, проблем нет, правда именно платы прямо струёй воды не мыл.
Если код проприетарный - хрен пойми как его исследовать, но зато понятно к кому претензии. А если open source - все наоборот - исследовать легче, но не к кому претензии предъявлять.
Сколько еще таких мелких либ используется, сколько еще таких сюрпризов будет...
Допустим схема может быть защищена авторским правом. Но если на ней использованы микросхемы, операционники или там даже составные транзисторы, т.е. по сути устройства у которых есть своя схема внутреннего устройства, с другими правами, тогда как? Бездонная тема для юристов и патентных троллей?
Никогда не используйте то, чем не умеете пользоваться.
Я лично такое видел в виде статьи в одной местечковой газете. Кроме головной боли и давления, еще школьники стали агрессивными.
Но БТС, о которой шла речь в статье, на тот момент к электропитанию еще не была подключена.
100%. Нормальная машинка стоит дороже дешевой гитары. А дешевая машинка которая установлена в дешевой гитаре - просто не дает ее нормально настроить. А если и дает, то не держит строй. И это если не пользоваться этой самой машинкой. А если попробовать воспользоваться, то сразу хочется другую гитару, где ее нет.
У меня со временем астигматизм развился и требования к монитору снизилось))
А до того, лично у меня реально влияло на утомляемость глаз число точек на дюйм (PPI) - точно числа не скажу, но на слабых в этом плане мониторах, глаза реально "цеплялись" за картинку и сильно чувствовалось усталость.
Может даже из-за работы за таким монитором и снизилось зрение за несколько лет.
Я когда-то слышал что ими описывают распространение ржавчины в металлах
kotlin на бекэнде вполне себе ок, проверено лично в разных проектах. особенно если иметь в виду, что intellij насчёт java нигде в документации не использует слово совместимость (compatibility), они пишут interoperability.
Китай вроде только на третьем месте по добыче лития. Причем первые два (Чили и Австралия) добывают больше раз в шесть. Китай лидер по вредному производству , связанному с обработкой добытой руды, но никак не по добыче самого лития.
Отсылка к 1brc понятна, но там все-таки был миллиард строк))
а за нарушение международных норм есть какая-то реальная (практическая) ответственность?
Несколько бывших фейсбукеров рассказали несколько офисных слухов (более чем десятилетней давности). Вряд ли это можно считать реальной статьей, описывающей причины принятия такого решения.
500 страниц - какая мелочь ))
https://habr.com/ru/companies/dcmiran/articles/493018/
Интересно мнение графологов о подписи товарища Т.Р.Нурбагандова ))
Я столкнулся с тем, что если у некоторых компонентов (отдельных java проектов) файл build.gradle (да и сам gradle) не обновлялся достаточно давно, то задействование bom с помощью platform (и тем более force platform) приносит кучу проблем, по сути ломая механизм разрешения зависимостей. Так что лучше перед использованием bom избавиться от зоопарка версий gradle (если он конечно есть), а также привести скрипты build.gradle к "общему знаменателю" - убрать, например, compile/runtime и другие устаревшие штуки.
Ну лично мне эта статья показалось очень иллюстративной
https://typealias.com/guides/when-to-use-sequences/
Мне кажется стоило добавить о коллекциях и sequence в kotlin, о их влиянии на performance, и о том, что некоторые операции .collect() при совпадении ключа, в java вызовут ошибку, которая призовет к использованию другого, соответствующего коллектора (где можно указать, что делать в такой ситуации), а то время как в Котлин все отработает "молча", но не всегда так, как нужно автору кода.
По моему опыту, это частые подводные камни при подобном переходе.