1) Может я чего-то не понимаю, но сам Docker так же через переменные окружения рулится…
2) Тем самым вы отрезаете себя от протокола DLNA, которому нуден UDP. Хотя тут я тоже могу ошибаться…
3) --log-driver=journald вроде тоже самое делает…
Тут сложный вопрос. С одной стороны платишь один раз (хоть и приличные деньги). С другой стороны каждый год обещают выпускать дополнения (высадка на планеты, хождение по кораблю и т.п.) и это продаётся отдельно.
Т.е. если хватает текущего контента — то заплатил и пользуешься. Ели нет — платишь раз в год за дополнительный контент.
Ну и цены могут сильно меняться со временем. Как правило через пол года сильно дешевеет.
Я так понимаю, что это тоже будет только для входящего трафика? А для исходящего нужно иметь свой канал? Если да, то не совсем понятна целевая аудитория.
Новые прошивки сильно улучшились. Но главную проблему — не исправить. Т.к. основной потребитель — экран. Так что очень всё зависит от режима использования. Так в рабочие дни мне его стабильно хватает на 2,5 суток. В выходные могу и за день досуха выжать. Если нонстоп эксплуатирую.
В обще показывает, что на экран уходит около 80% энергии при любых раскладах. Правда в игры я не играю. В топовых играх, говорят, может по проценту в минуту утекать. Ну так там и мощщя немеренная, так что простительно.
Сам не сталкивался, но видел упоминание на 4pda о подобной проблеме. Видимо калибровка сенсора слетела. В принципе похоже на брак. И возможно даже подлежит ремонту/замене (если эта услуга оплачивалась при покупке). Но в тоже время поддается лечению через сервисное меню. Если руки из нужного места растут. К сожалению сам подробности рассказать не могу, т.к. просто прочитал про это и забыл. Но думаю, что на 4pda вполне можно найти всю необходимую информацию.
Можно написать пару маленьких программок и декомпилировать.
геттеры и сеттеры будут реализованы как методы getVarName() и setVarName(...)
Даже это делать не надо. В IDEA есть отдельное окно, показывающее, во что превратиться написанный на Kotlin'е исходник. Очень удобно и наглядно демонстрирует качество компилятора...
Null-safety: интересная штука, но на практике во все публичные методы добавляются проверки для каждого аргумента на null. Мне кажется несколько избыточным — и есть подозрение, что это негативно влияет на производительность. (Там не просто проверка, а вызов статического метода с передачей объекта-параметра и его имени как строки, чтобы можно было кинуть понятное исключение)
Это может и выглядит несколько нагружено, если смотреть в байткоде. Но на деле JVM отлично знает как это оптимизировать. И в рантайме никаких издержек выявить не удалось. Более того, если вы попробуете посмотреть, что получется уже на уровне машинного кода после JIT, то навряд ли найдёте эти проверки в явном виде. Где-то про это даже доклад был на одной из конференций.
И первый вопрос для затравки: какие планы по улучшению быстродействия работы плагина Kotlin в Idea?
Дело в том, что если в большом проекте добавить .kt файл, то IDE начинает просто очень медленно работать. Реакция code intelligence может достигать 10-ти секунд и более. Подсветка то слетает, то опять появляется ну и т.п.
Спасибо. К счастью ViewState'а у нас нету. Но вот то, что в Wildfly все коммуникации повесили на один порт (и http и EJB) — неприятно. Пытаюсь сообразить какие могут быть вектора атаки с учётом нашей инфраструктуры. Но для этого надо иметь на руках рабочий экспоид.
Странно. Хотел попробовать прогнать этот эксплоид на нашем приложении, но что-то пошло не так.
Даже если я просто создаю объект, как написано в статье, сериализую его, а потом тут же десериализую, то получаю ошибку десериализации:
Stacktrace
Exception in thread "main" java.lang.ClassCastException: java.lang.Integer cannot be cast to java.util.Set
at com.sun.proxy.$Proxy0.entrySet(Unknown Source)
at sun.reflect.annotation.AnnotationInvocationHandler.readObject(AnnotationInvocationHandler.java:443)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1017)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1893)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1798)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:370)
at ru.krista.exploid.Exploid1.deserialize(Exploid1.java:113)
at ru.krista.exploid.Exploid1.send(Exploid1.java:75)
at ru.krista.exploid.Exploid1.main(Exploid1.java:30)
Есть подозрение, что код специально подпорчен. Но вот где ошибка — понять не могу.
Возможно величина ускорения зависит от того, что именно (и как) используется при сборке. Так, например, maven-assembly-plugin не меняет своего времени исполнения, при этом может оказывать существенное влияние на время сборки.
Мы из-за этого выделили проекты, использующие такие плагины в сторону. Благо их немного и для целей разработки каждый раз их собирать вовсе не обязательно.
Ещё Takari не получается использовать со всякими нестандартными сборками а-ля kie-maven-plugin от drools.
Так что это вполне может быть связано с особенностями проекта. Если в проекте преимущественно простые jar артефакты, то ускорение получается очень вкусным.
С ошибками на чистом локальном репозитарии не сталкивались, хотя так делается ночная сборка. Возможно тут у Вас тоже какая-то специфика проекта. Или что-то упущено при настройке.
В целом сейчас никто у нас уже даже думать не хочет о возвращении обратно. Хоть местами это и вызывает некоторые неудобства.
Да с AST там не сильно понятно. Создаётся впечатление, что это должно быть где-то на поверхности, но когда попытался разобраться, то быстро заблудился. Возможно опыт личных навыков в этой области не хватило. Так-то у них даже есть модуль под названием kotlin-compiler-embeddable. Но никакой информации по поводу него найти не удалось.
Скорее всего где-то там AST искать надо. Если будет время вечером — попробую сделать ещё один заход в ту сторону. По крайней мере теперь есть конкретная мотивация.
Ну, например, бегло пробежавшись по исходникам, даже не понял толком, как это работает. Хотя толком не вникал. Было бы интересно получить некоторую развёрнутую информация как реализован функционал. Какие и как использовались технологии. Чтобы другим было легче разобраться и, возможно, попробовать что-либо добавить.
Ну как-то так. Извиняюсь, если слишком сумбурно. Просто тема очень взбудоражила, а работа тоже не ждёт…
Хочу попробовать собрать нормальный Docker образ на основе образа phusion
2) Тем самым вы отрезаете себя от протокола DLNA, которому нуден UDP. Хотя тут я тоже могу ошибаться…
3) --log-driver=journald вроде тоже самое делает…
Т.е. если хватает текущего контента — то заплатил и пользуешься. Ели нет — платишь раз в год за дополнительный контент.
Ну и цены могут сильно меняться со временем. Как правило через пол года сильно дешевеет.
В обще показывает, что на экран уходит около 80% энергии при любых раскладах. Правда в игры я не играю. В топовых играх, говорят, может по проценту в минуту утекать. Ну так там и мощщя немеренная, так что простительно.
Даже это делать не надо. В IDEA есть отдельное окно, показывающее, во что превратиться написанный на Kotlin'е исходник. Очень удобно и наглядно демонстрирует качество компилятора...
Это может и выглядит несколько нагружено, если смотреть в байткоде. Но на деле JVM отлично знает как это оптимизировать. И в рантайме никаких издержек выявить не удалось. Более того, если вы попробуете посмотреть, что получется уже на уровне машинного кода после JIT, то навряд ли найдёте эти проверки в явном виде. Где-то про это даже доклад был на одной из конференций.
И первый вопрос для затравки: какие планы по улучшению быстродействия работы плагина Kotlin в Idea?
Дело в том, что если в большом проекте добавить .kt файл, то IDE начинает просто очень медленно работать. Реакция code intelligence может достигать 10-ти секунд и более. Подсветка то слетает, то опять появляется ну и т.п.
Оказывается ошибка и должна быть. Но она происходит уже после срабатывания уязвимости. Просто я неудачную команду для выполнения выбрал.
Не работает. А вот
уже отрабатывает.
Даже если я просто создаю объект, как написано в статье, сериализую его, а потом тут же десериализую, то получаю ошибку десериализации:
Есть подозрение, что код специально подпорчен. Но вот где ошибка — понять не могу.
Возможно величина ускорения зависит от того, что именно (и как) используется при сборке. Так, например, maven-assembly-plugin не меняет своего времени исполнения, при этом может оказывать существенное влияние на время сборки.
Мы из-за этого выделили проекты, использующие такие плагины в сторону. Благо их немного и для целей разработки каждый раз их собирать вовсе не обязательно.
Ещё Takari не получается использовать со всякими нестандартными сборками а-ля kie-maven-plugin от drools.
Так что это вполне может быть связано с особенностями проекта. Если в проекте преимущественно простые jar артефакты, то ускорение получается очень вкусным.
С ошибками на чистом локальном репозитарии не сталкивались, хотя так делается ночная сборка. Возможно тут у Вас тоже какая-то специфика проекта. Или что-то упущено при настройке.
В целом сейчас никто у нас уже даже думать не хочет о возвращении обратно. Хоть местами это и вызывает некоторые неудобства.
Просто изначально не догадался начать с kotlin-maven-plugin. Который простой как палка.
Скорее всего где-то там AST искать надо. Если будет время вечером — попробую сделать ещё один заход в ту сторону. По крайней мере теперь есть конкретная мотивация.
Ну как-то так. Извиняюсь, если слишком сумбурно. Просто тема очень взбудоражила, а работа тоже не ждёт…