С введением формального протокола LSP, Microsoft свела знаменитую проблему M x N к проблеме (M x L) + N.
M = Различные языки (C, C++, PHP, Python, Node, Swift, Go и т.д.).
N = Различные редакторы кода (VSCode, Eclipse, Notepad++, Sublime Text и т.д.).
L = Различные языковые серверы LSM
У Гугла тоже все, что ты пришешь в личное время — принадлежит Гуглу по умолчанию. Хочешь, чтобы было твое — пиши заявление с описанием проекта. Гугл уже решит нужно это им или нет.
As part of your employment agreement, Google most likely owns intellectual property (IP) you create while at the company. Because Google’s business interests are so wide and varied, this likely applies to any personal project you have. That includes new development on personal projects you created prior to employment at Google.
В больших компаниях это типично добавлять в контракт раздел про интеллектуальную собственность, в котором сказано, что любой результат интеллектуального труда: софт, патенты, копирайты — все принадлежит компании. Даже если в нерабочее время и на домашнем компьютере.
Сам с таким столкнулся.
Clubhouse has responded saying they have not experienced a breach of their systems and said that the data is already publicly available and that it can be accessed via their API
«Физика невозможного» Митио Каку
Рассматриваются различные технологии из научной фантастики и объясняется почему это невозможно при современном развитии науки. Например, силовой щит, лазерный меч, телепатия, путешествие во времени и т.д. Самое интересное оценивается степень невозможности этой технологии.
1 технологии невозможные сейчас, но не нарушающие законов природы.
2 если это вообще возможно, то реализация займет тысячи или миллионы лет.
3 технологии нарушающие известные физические законы
Читается интересно и попутно простым языком объясняются сложные физические теории, вроде теории струн.
Скорее всего это заново сгенерированный пароль, а не тот что установил предыдущий владелец. Вы не помните, был ли он похож на придуманный человеком или это был случайный пароль?
Большинство таких «утечек» на деле оказывались кражей паролей пользователей с помощью фишинга, кейлогинга и прочих способов.
Вероятность того, что крупная интернет компания хранит в базе нехешированные пароли равна бесконечно малой величине.
Кроме того, программирование — это всегда поиск компромисов. Между производительностью, количеством кода и безопасностью использования. Если типичное использование билдера выглядит так:
То можно пренебречь возможностью менять объект через билдер. Вконце концов даже значение final поля можно изменить через рефлекшн, если SecurityManager это позволяет.
Исходя из каких убеждений вы сделали эти утверждения?
Я имел ввиду Java компилятор, не JIT.
Если бы Java компилятор мог самовольно инлайнить публичные методы, мы бы остались без библиотек.
С JIT ситуация другая. Он работает уже с окончательным кодом, который нужно выполнить и волен решать сам как это делать.
Тем не менее проблема билдера и многопоточности несколько надумана. Точнее она ничем не отличается от обычного вызова конструктора в многпоточном коде. Очевидно, это задача клиентского кода синхронизировать доступ к общим ресурсам. Как, например, при использовании StringBuilder'а.
Эта проблема связана с тем, что в байткоде создание объекта это две инструкции — NEW и INVOKESPECIAL.
Тем не менее Билдера эта проблема не касается. Вызов конструктора происходит в отдельном методе build() и только потом возвращается ссылка на объект. Даже если компилятор поменяет порядок внутри метода, ни один конкурентный поток не увидит ссылку на недостоенный объект. Разве что компилятор решит сделать inline методу, хотя я уверен, что на публичный метод у него рука не поднимется.
без final на полях Вы не получите от JVM тех же гарантий видимости для многопоточного кода
Модификатор final используется только на этапе компиляции. В байткоде его нет и JVM про него ничего не знает. Какие «гарантии видимости» вы имеете ввиду?
Поля приватные, сеттеров нет. Единственный способ изменить поля объекта без рефлексии — только через билдер, а у него время жизни короткое.
Чем не иммутабельность?
С введением формального протокола LSP, Microsoft свела знаменитую проблему M x N к проблеме (M x L) + N.
M = Различные языки (C, C++, PHP, Python, Node, Swift, Go и т.д.).
N = Различные редакторы кода (VSCode, Eclipse, Notepad++, Sublime Text и т.д.).
L = Различные языковые серверы LSM
opensource.google/docs/iarc
Сам с таким столкнулся.
www.joelonsoftware.com/2016/12/09/developers-side-projects
Clubhouse has responded saying they have not experienced a breach of their systems and said that the data is already publicly available and that it can be accessed via their API
Рассматриваются различные технологии из научной фантастики и объясняется почему это невозможно при современном развитии науки. Например, силовой щит, лазерный меч, телепатия, путешествие во времени и т.д. Самое интересное оценивается степень невозможности этой технологии.
1 технологии невозможные сейчас, но не нарушающие законов природы.
2 если это вообще возможно, то реализация займет тысячи или миллионы лет.
3 технологии нарушающие известные физические законы
Читается интересно и попутно простым языком объясняются сложные физические теории, вроде теории струн.
Вероятность того, что крупная интернет компания хранит в базе нехешированные пароли равна бесконечно малой величине.
Возможно зависит от компании. Мой работодатель оплачивает и медстраховку и пенсионный фонд.
Кроме того, программирование — это всегда поиск компромисов. Между производительностью, количеством кода и безопасностью использования. Если типичное использование билдера выглядит так:
То можно пренебречь возможностью менять объект через билдер. Вконце концов даже значение final поля можно изменить через рефлекшн, если SecurityManager это позволяет.
Я имел ввиду Java компилятор, не JIT.
Если бы Java компилятор мог самовольно инлайнить публичные методы, мы бы остались без библиотек.
С JIT ситуация другая. Он работает уже с окончательным кодом, который нужно выполнить и волен решать сам как это делать.
Тем не менее проблема билдера и многопоточности несколько надумана. Точнее она ничем не отличается от обычного вызова конструктора в многпоточном коде. Очевидно, это задача клиентского кода синхронизировать доступ к общим ресурсам. Как, например, при использовании StringBuilder'а.
После прочтения Java memory model в JLS я в этом уже не далеко не уверен.
К сожалению очевидно ошибочный комментарий удалить уже нельзя.
Эта проблема связана с тем, что в байткоде создание объекта это две инструкции — NEW и INVOKESPECIAL.
Тем не менее Билдера эта проблема не касается. Вызов конструктора происходит в отдельном методе build() и только потом возвращается ссылка на объект. Даже если компилятор поменяет порядок внутри метода, ни один конкурентный поток не увидит ссылку на недостоенный объект. Разве что компилятор решит сделать inline методу, хотя я уверен, что на публичный метод у него рука не поднимется.
Модификатор final используется только на этапе компиляции. В байткоде его нет и JVM про него ничего не знает. Какие «гарантии видимости» вы имеете ввиду?
Одно из назначений этого паттерна в том, чтобы избавиться от конструтора с кучей параметров и при этом сделать класс немутабельным.
Поля приватные, сеттеров нет. Единственный способ изменить поля объекта без рефлексии — только через билдер, а у него время жизни короткое.
Чем не иммутабельность?