Про Ethereum Classic какое-то абсурдное утверждение "часть разработчиков… продолжила поддерживать версию кода с уязвимостью". Получается что главная задача была в поддержке уязвимости в стороннем приложении?
На самом деле команда стала поддерживать блокчейн, но не код смарт контракта The DAO в котором была уязвимость. В самом блокчейне не было уязвимости, к тому же после взлома The DAO он перестал нормально функционировать в любом из форков, так что никто его не поддерживал.
Все можно сделать без union, оно так и сделано сейчас. Я нигде не утверждал что без него никак. Вообще все современные языки лишь дополнительное удобство, а технически все можно написать наверное и на Фортране.
Я не совсем понимаю чем мой ответ вас не устраивает, он же не выдуманный. Обычная ситуация когда внешний API в одном случае возвращает список с идентификаторами, в другом список с дынными. В одном случае лишь long во втором полноценный объект. Надо уметь работать и с тем и с тем.
Я думал я именно это ответил. Попробую пояснить — в моем примере используются разнородные объекты, но по факту это разные отражения одной сущности. В одном случае это указатель на данные, другой это полные данные. Long и MyDataInstance.
Это конкретный пример из жизни, не выдуманный.
Уточню еще что можно делать как угодно, все будет работать, проблема в том что это лишний код который приходится везде таскать и усложнять читаемость кода. В большинстве методов не важно же какой MyData<?> приходит, и вообще такой подтип незачем светить наружу. В идеале всегда нетипизированый MyData который уже
class MyOtherDataAny extends Union<Long, MyOtherData> {};
class MyData {
MyOtherDataAny other;
}
Не уточнил что чаще случается что такой класс обьявлен как generic, т.е. это инстанс ClassFoo<Long> или ClassFoo<ClassBar>. К сожалению в Java не получится сделать method overloading и метод объявляется как ClassFoo<Object>, как на прием так и на результат, и дальше программист кастит куда нужно
Да, не забывайте что методы не только принимают, но и возвращают значения. Поэтому по факту получается:
Часто read не знает что он прочитает заранее, частая проблема в API и интеграции. Поэтому имеем
Object read() {...}
а потом опять куча ифов и кастингов после чтения.
Или в более реальном случае
<T> myAction(MyData<T> data, Class<T> type) {
if (type.isAssignable(Long.class)) then {...}
else if (type.isAssignable(Instance.class)) then {...}
else throw new IllegalArgumetnException()
}
myActionAsData(MyData<Instance> data) {...}
myActionAsRef(MyData<Ref> data) {...}
<T> MyData<T> read(Class<T> type) {
if (type.isAssignable(Long.class)) then {...}
else if (type.isAssignable(Instance.class)) then {...}
else throw new IllegalArgumentException()
}
MyData<Object> read() {...}
Так как это в коде это может быть использовано много где, к тому же объекты могут быть зависимы а значит перемножаются. Конечно можно так писать, так и делают, но в итоге код становится нечитаемым и дорогим в поддержке (особенно добавлении нового подтипа). Может быть с Union это будет легче поддерживаемо
На мой взгляд это полезно для структурирования кода.
Сейчас если метод может принимать MyDataInstance или MyDataRefid, где первое это весь объект целиком, а второе скажем id. В такой ситуации чаще всего метод объявляется принимающим Object, и внутри идет проверка типа инстанса. Это дублированием кода, тестированием, проблемы с добавлением новой поддерживаемой структуры, отсутсвие самодокументируемости кода и пр. Не знаю как у остальных, но я часто сталкиваюсь с таким кодом.
Был бы union можно было объявить метод myMethod(Union<MyDataInstance, MyDataRefid> data) и решить все проблемы компилятором. Я не согласен с реализацией идеи в статье, но в целом что-то такое наверное попробую.
Непонятна претензия насчет Kotlin. В Java главное это байткод и даже в одном проекте можно свободно смешивать языки. Из последних проектов обычно 2-3 языка Java + Kotlin + Groovy (не считая кода библиотек). Также как и в node.js проекте часто используют Javascript + Typescript.
Насчет разных контрольных сумм, возможно вам поможет сброс дат для файлов входящих в слой. Т.е. проставлять 1970-01-01 для всех jar'ов
Если вы используете Gradle или Maven, как альтернативу можно использовать jib плагин (https://github.com/GoogleContainerTools/jib), он упаковывает приложения по слоями как у вас описано
Безотносительно размера докер образа, советую посмотреть на Jib github.com/GoogleContainerTools/jib Это инструмент упаковки Java приложений в Docker, поддерживает Spring Boot и выбор базовых образов.
Не уверен насчет JDK custom runtime, но у него много других преимуществ. Например он складывает внешние библиотеки, код приложения и ресурсы приложения в разные слои. Поэтому размер обновления, т.е. слоя который по факту нужно скачать на сервере, обычно равен размеру вашего кода.
Про Bitcoin получается сравнение совсем разных уровней.
Если вы заплатите 100 долларов кэшем вы уже не сможете позвонить в федеральный резерв и попросить отменить купюру номер Х потому что товар оказался ненадлежащего качества. С кэшем тоже операция необратимая, но он как вы сами сказали является резервом (карточки VISA/MC врядли признаются в этой роли).
А то что вы получаете в случае карт это обязательства VISA/MC по переводу вам денег. В случае Bitcoin это называет Layer 2, где первый уровень это физическая необратимая гарантированная передача (как наличные), на втором же уровне строй любые процессы, хоть карточную оплату которая после периода оспаривания заканчивается физическим переводом Bitcoin на первом уровне.
Я на корпоративный блог не подписан, но оно как-то попало в мою ленту, поэтому вопрос и возник.
Собственно вопрос и возник потому что обычно размещают статью с информационным содержанием, а здесь ничего толком нет, лишь реклама. Ну ок, даже если реклама, я не против, но можно же рассказать что за платформа, конкретней, с деталями, для технарей? Иначе зачем это здесь?
Они берут плату за полноценную vm с изоляцией, не за классы. Обычный GAE это типа shared hosting, несколько проектов на одной машине. Поэтому все системное, типа доступа к файловой системе и awt запрещены, чтобы не навредить соседям.
Я говорил про первый этап, про конвертацию незашифрованной базы. Не понял что вы говорите про проблему на втором этапе, когда база уже зашифрована.
Про второй случай тот кто хочет, тот ключ забекапит, кто не хочет бэкапить — тот потеряет историю, это очевидно. Можно шифровать тоже выборочно, по желанию (и даже спрашивать ключ для шифрования у пользователя)
А какой ущерб безопасности может быть при конвертации незашифрованной базы в зашифрованную? был пустой ключ, стал случайно сгенерированный, чем это хуже?
SGX также позволял скрыть ключи от соседнего админа на машине, который, к слову, мог получить право неправомерное, т.е. через другую уязвимость.
Постгрес действительно потребовал в 3 раза больше железа? Это в случае яндекса или средняя разница по потребляемым ресурсам?
Про Ethereum Classic какое-то абсурдное утверждение "часть разработчиков… продолжила поддерживать версию кода с уязвимостью". Получается что главная задача была в поддержке уязвимости в стороннем приложении?
На самом деле команда стала поддерживать блокчейн, но не код смарт контракта The DAO в котором была уязвимость. В самом блокчейне не было уязвимости, к тому же после взлома The DAO он перестал нормально функционировать в любом из форков, так что никто его не поддерживал.
Все можно сделать без union, оно так и сделано сейчас. Я нигде не утверждал что без него никак. Вообще все современные языки лишь дополнительное удобство, а технически все можно написать наверное и на Фортране.
Я не совсем понимаю чем мой ответ вас не устраивает, он же не выдуманный. Обычная ситуация когда внешний API в одном случае возвращает список с идентификаторами, в другом список с дынными. В одном случае лишь long во втором полноценный объект. Надо уметь работать и с тем и с тем.
Я думал я именно это ответил. Попробую пояснить — в моем примере используются разнородные объекты, но по факту это разные отражения одной сущности. В одном случае это указатель на данные, другой это полные данные. Long и MyDataInstance.
Это конкретный пример из жизни, не выдуманный.
(удалил, не та ветка)
Уточню еще что можно делать как угодно, все будет работать, проблема в том что это лишний код который приходится везде таскать и усложнять читаемость кода. В большинстве методов не важно же какой
MyData<?>приходит, и вообще такой подтип незачем светить наружу. В идеале всегда нетипизированый MyData который ужеНе уточнил что чаще случается что такой класс обьявлен как generic, т.е. это инстанс
ClassFoo<Long>илиClassFoo<ClassBar>. К сожалению в Java не получится сделать method overloading и метод объявляется какClassFoo<Object>, как на прием так и на результат, и дальше программист кастит куда нужноДа, не забывайте что методы не только принимают, но и возвращают значения. Поэтому по факту получается:
Часто read не знает что он прочитает заранее, частая проблема в API и интеграции. Поэтому имеем
а потом опять куча ифов и кастингов после чтения.
Или в более реальном случае
Так как это в коде это может быть использовано много где, к тому же объекты могут быть зависимы а значит перемножаются. Конечно можно так писать, так и делают, но в итоге код становится нечитаемым и дорогим в поддержке (особенно добавлении нового подтипа). Может быть с Union это будет легче поддерживаемо
Сейчас если метод может принимать MyDataInstance или MyDataRefid, где первое это весь объект целиком, а второе скажем id. В такой ситуации чаще всего метод объявляется принимающим Object, и внутри идет проверка типа инстанса. Это дублированием кода, тестированием, проблемы с добавлением новой поддерживаемой структуры, отсутсвие самодокументируемости кода и пр. Не знаю как у остальных, но я часто сталкиваюсь с таким кодом.
Был бы union можно было объявить метод myMethod(Union<MyDataInstance, MyDataRefid> data) и решить все проблемы компилятором. Я не согласен с реализацией идеи в статье, но в целом что-то такое наверное попробую.
Если вы используете Gradle или Maven, как альтернативу можно использовать jib плагин (https://github.com/GoogleContainerTools/jib), он упаковывает приложения по слоями как у вас описано
Не уверен насчет JDK custom runtime, но у него много других преимуществ. Например он складывает внешние библиотеки, код приложения и ресурсы приложения в разные слои. Поэтому размер обновления, т.е. слоя который по факту нужно скачать на сервере, обычно равен размеру вашего кода.
Если вы заплатите 100 долларов кэшем вы уже не сможете позвонить в федеральный резерв и попросить отменить купюру номер Х потому что товар оказался ненадлежащего качества. С кэшем тоже операция необратимая, но он как вы сами сказали является резервом (карточки VISA/MC врядли признаются в этой роли).
А то что вы получаете в случае карт это обязательства VISA/MC по переводу вам денег. В случае Bitcoin это называет Layer 2, где первый уровень это физическая необратимая гарантированная передача (как наличные), на втором же уровне строй любые процессы, хоть карточную оплату которая после периода оспаривания заканчивается физическим переводом Bitcoin на первом уровне.
Ну и вообще сложно сравнить функциональность, они же разные. Яблоки и апельсины.
Собственно вопрос и возник потому что обычно размещают статью с информационным содержанием, а здесь ничего толком нет, лишь реклама. Ну ок, даже если реклама, я не против, но можно же рассказать что за платформа, конкретней, с деталями, для технарей? Иначе зачем это здесь?
Про второй случай тот кто хочет, тот ключ забекапит, кто не хочет бэкапить — тот потеряет историю, это очевидно. Можно шифровать тоже выборочно, по желанию (и даже спрашивать ключ для шифрования у пользователя)