первое. интересно, как они собираются выявлять такие сообщения? по шаблону текста? чтобы "тарифицировать отдельно" и блокировать.
далее, очень интересное заявление "смс не являются предметом для перепродажи". вот где здесь перепродажа? вознаграждение премиумом? и вообще, какая разница, как я использую свои честно купленные смс? или я их покупала, чтобы солить они пропадали неиспользованными?
они уже хотели тарифицировать voip трафик как gsm, потом дополнительно обложили раздачу интернета. а теперь банально хотят заработать ещё. при этом чтобы абонент как обычно переплачивал, не расходуя весь заявленный план.
упростит всякое мошенничество. чел может же прислать не то же самое, а что-то похожее. или вообще что-то новое со ссылкой. а человек уже привык, что с левых номеров приходит конфиденциальная инфа и не заметит подвоха.
вот если бы это ещё как-то подписывалось... да и то, смс с левых номеров не должны читаться.
впрочем, ожидая доставку или такси мы вполне склонны отвечать на звонки и читать сообщения от левых номеров.
но всё же, не стоит приучать людей верить в сообщения с незнакомых номеров.
Koin это не DI полноценный, требует каких-то лишних телодвижений, когда в спринге в большинстве случаев обходится одной аннотацией.
koin-annotations позволяют точно также обходиться аннотацией
Ktor тоже создает простыню кода, когда как спринг одной аннотацией справляется.
этот код и есть конфигурация. остальное во многом зависит от вас. впрочем, по сравнению со спрингом действительно "маловато" волшебных аннотаций, которые всё за вас сделают. ну, товарищ, разбаловал вас спринг, давно вы сервлетов не писали :)
воровство [личных данных и свободы] и издевательство над людьми в интернете - это то, чем активно занимаются и власти и корпорации (всякие там утекающие облака и подписки, превращающиеся в тыквы) и точно не свобода.
и мы свою свободу с лёгкостью отдаём (нуаче, бесплатно же, удобно же)
Например, отказ от выдачи пароля поттребованию органов - это само по себе преступление.
шиза? не всегда, зависит от ситуации. например, если это поможет в поимке маньяка (скажем, точно известно, что на телефоне есть нужная для этого информация), то да, иначе это сокрытие. а если органы хотят узнать в ту же секунду, когда вы посмотрели хентай и приписать вам педофилию а себе лишнюю звёздочку - то шиза.
и вот если раньше возможно было такое, что если заметил уязвимость и обратился к владельцу, чтобы тот исправил, то теперь за такое точно спасибо не скажут.
умнее было бы штрафовать не за сам факт утечки, а за халатное отношение к безопасности: утечки бывают у абсолютно всех (даже у таких гигантов, как Гугл или Мета**), что означает, что почти невозможно сделать абсолютно защищённую систему (как минимум, очень уязвимы прокладки между стулом и монитором). но вот за всякое элементарное типа $DB.select("select "+$POST["field"]+" from users") надо бить долго и очень больно. особенно когда такие тикеты висят годами, а владелец отбрехивается "это не критично, и вообще это не баг а фича", исполнитель (кодер) подрабатывает в свободное время от учебы и про азы безопасности ещё и не слышал (ну да, бизнес гонит "сделай за 5 минут хоть абы как, нам эта фича нужна ещё вчера".
вот и получается, что у соседа дверь висит на соплях, ему говорят а он и в ус не дует, но открывать эту дверь нельзя. а с другой стороны, даже мастера спорта положит на лопатки пуля, так очень ли он в том виноват?
пробовала ktor/koin и осталась довольна. и для реализации того же, требуется немного больше времени. впрочем, на spring boot мы получаем рабочий продукт практически мгновенно.
да, возможно будет ещё вопрос: а нельзя ли spring boot использовать вместе с kotlin? можно! но есть нюансы. нюанс первый, больше связан скорее не со spring boot, а с jpa/hibernate. так, например, сериализовать kotlin класс java подходом не получится (там есть цикличные ссылки, и вообще, на выходе получается не совсем требуемый java bean), а это нужно hibernate. во-вторых, если весь spring придерживается философии "правильно аннотируй код и сконфигурируй его в application.properties/application.yml", то в котлин-коде очень редко используются аннотации и их обработчики, очень часто используются dsl-лямбды. а потому spring-boot на котлине выглядит несколько странно. и в целом, spring лучше интегрирован с java, котлин здесь ещё гость, поэтому могут быть и другие нюансы
да, ещё одна java боль: дженерики и type erasure. котлин старается вовсю, введя reified types и inline, но, поскольку это архитектурное ограничение самой jvm, то полной информации о дженериках в рантайме нет и не будет. однако, язык спроектирован достаточно хорошо, никаких исключений во время выполнения точно не будет, а явных вынужденных приведений исчезающе мало по сравнению, как часто заставляет делать это java.
скажу за котлин - чудесный язык! сильная строгая типизация на этапе компилирования, ненулевые типы, полная кроссплатформенность (jvm, js, native и mobile), иммутабельность, мультипарадигменность (возможность писать в ооп-стиле, процедурном или функциональном стилях), лёгкая интеграция с java, из мелочей: алясы типов и импортов, var/val/const, богатая стандартная библиотека с операциями над коллекциями, it в качестве имени аргумента лямбды по умолчанию, адекватное поведение this при этом с возможностью ссылаться на this изнутри замыканий, приятные методы захватывания this/it (так, например v.apply {p=0} позволяет устанавливать свойства объекта в стиле builder), бесскобочная запись лямбда аргумента позволяет конструировать dsl-записи, чем активно все пользуются включая тот же gradle, методы-расширения (возможность добавить в сторонний класс новый метод) и свойства, и конечно, именованные аргументы и аргументы по умолчанию, а также интерполяция строк (корректно компилируемая в string builder, в рантайме нет разбора и подстановки). есть баланс между многословностью(обилием ключевых слов) и засилием символов. есть делегируемость свойств, что позволяет делать ещё один вид магии, например, ленивые свойства или реактивные (наблюдаемые свойства). и да, просто свойства, никакого кошмара джависта getXXX/setXXX и соответственно lombok не нужен. и на сладкое - официальные библиотеки для сериализации во многие форматы и coroutines для всех платформ выводят язык на современный уровень. а возможность написания gradle-плагинов доставляет возможность генерировать код во время компиляции: так, например, плагин serialization генерирует сериализатор для всех аннотированных классов. аналогично можно написать свой плагин и избавиться от рефлексии и генерации кода в рантайме, заметно повышая производительность. имеется и работа с сетью, например ktor позволяет писать серверную часть и http клиент тоже (при этом существует возможность писать html и css тоже на котлине благодаря dsl). более того, на kotlin-awesome можно найти библиотеки/фреймворки для практически любой задачи. наконец, для скомпилированного в js кода есть поддержка sourcemaps, что позволяет в devtools видеть и дебажить не высер компилятора, а котлин-код. и наконец, используя javafx и javapackager можно легко и приятно писать десктоп-приложения с инталлятором, при этом не заставляя пользователя иметь jvm и не тащить её всю - только необходимый для работы конкретного приложения минимум. а gradle при правильном написании может собрать всё (вместе с инсталлятором) одной командой gradle package
недостатки, конечно, есть: более медленная компиляция, особенно тяжёл сам gradle, хоть он и стандарт де-факто в java мире по сравнению с "устаревшим" maven. оверхед компилированного кода также есть, что связано с, например, проверками на nullable (т.к. в jvm нет такого понятия). но, всё же он меньше, чем у groovy или scala. ещё, всё ещё нет хорошей документации к js байндингам (имею ввиду kotlin-wrappers), поэтому пока что достаточно утомительно писать react фронт (в частности, из-за типизации). native-разработка, аналогично, утомительна из-за своих особенностей.
но, в итоге, имхо, язык предоставляет максимум для лёгкого, быстрого и приятного кодинга почти всего на свете. наверное, вопросы целесообразности использования остаются там, где очень критична скорость и/или ограниченные ресурсы. ну и, собственно, почему-то сложилось так, что фронт как писали так и пишут на typescript, ,java сервера на spring boot, и только в android-разработке kotlin более популярен.
Следом будет генерация контента третьего рода (обезличено совсем: "найдено", "обнаружено", "показано").
а это не уже? вот это "раскрыт секрет...", "эксперты нашли..." и т.д.? скорее, следующая ступень"шок, сенсация! вам достаточно всего лишь" - и на хабре
"Лучшие специалисты за забором" вряд-ли на ту же ставку пойдут, а если пойдут, то вряд-ли это "лучшие специалисты", их и так в других местах на хорошую ставку возьмут.
это пока "другие места" не закончатся. а когда уходить будет некуда, что "лучший специалист" поделает? вариант один - уезжать. что не все могут в силу каких-то личных обстоятельств (думаю, кто мог уехать, тот уже уехал)
не подсказывайте. ведь засчитают. и ещё иноагентом признают.
смешно, в стране большая часть населения -
шпионыиностранные агенты.первое. интересно, как они собираются выявлять такие сообщения? по шаблону текста? чтобы "тарифицировать отдельно" и блокировать.
далее, очень интересное заявление "смс не являются предметом для перепродажи". вот где здесь перепродажа? вознаграждение премиумом? и вообще, какая разница, как я использую свои честно купленные смс? или я их покупала, чтобы
солитьони пропадали неиспользованными?они уже хотели тарифицировать voip трафик как gsm, потом дополнительно обложили раздачу интернета. а теперь банально хотят заработать ещё. при этом чтобы абонент как обычно переплачивал, не расходуя весь заявленный план.
упростит всякое мошенничество. чел может же прислать не то же самое, а что-то похожее. или вообще что-то новое со ссылкой. а человек уже привык, что с левых номеров приходит конфиденциальная инфа и не заметит подвоха.
вот если бы это ещё как-то подписывалось... да и то, смс с левых номеров не должны читаться.
впрочем, ожидая доставку или такси мы вполне склонны отвечать на звонки и читать сообщения от левых номеров.
но всё же, не стоит приучать людей верить в сообщения с незнакомых номеров.
зато для вас не будет неприятным сюрпризом, а вы привыкнете и отнесётесь к этому спокойно/s
что ж, blm всякие победили - недостойно угнетателей рисовать!
а если серьезно - на чём обучали, то и получили.
koin-annotations позволяют точно также обходиться аннотацией
этот код и есть конфигурация. остальное во многом зависит от вас. впрочем, по сравнению со спрингом действительно "маловато" волшебных аннотаций, которые всё за вас сделают. ну, товарищ, разбаловал вас спринг, давно вы сервлетов не писали :)
именно, точно так же защищаются от детей, которых они "защищают"
это реклама по борьбе с борьбой - а вдруг новый Сноуден утащит ещё что-нибудь секретное и скандальное.
или занимаются аналогичным не в интернете
воровство [личных данных и свободы] и издевательство над людьми в интернете - это то, чем активно занимаются и власти и корпорации (всякие там утекающие облака и подписки, превращающиеся в тыквы) и точно не свобода.
и мы свою свободу с лёгкостью отдаём (нуаче, бесплатно же, удобно же)
шиза? не всегда, зависит от ситуации. например, если это поможет в поимке маньяка (скажем, точно известно, что на телефоне есть нужная для этого информация), то да, иначе это сокрытие. а если органы хотят узнать в ту же секунду, когда вы посмотрели хентай и приписать вам педофилию а себе лишнюю звёздочку - то шиза.
и вот если раньше возможно было такое, что если заметил уязвимость и обратился к владельцу, чтобы тот исправил, то теперь за такое точно спасибо не скажут.
умнее было бы штрафовать не за сам факт утечки, а за халатное отношение к безопасности: утечки бывают у абсолютно всех (даже у таких гигантов, как Гугл или Мета**), что означает, что почти невозможно сделать абсолютно защищённую систему (как минимум, очень уязвимы прокладки между стулом и монитором). но вот за всякое элементарное типа $DB.select("select "+$POST["field"]+" from users") надо бить долго и очень больно. особенно когда такие тикеты висят годами, а владелец отбрехивается "это не критично, и вообще это не баг а фича", исполнитель (кодер) подрабатывает в свободное время от учебы и про азы безопасности ещё и не слышал (ну да, бизнес гонит "сделай за 5 минут хоть абы как, нам эта фича нужна ещё вчера".
вот и получается, что у соседа дверь висит на соплях, ему говорят а он и в ус не дует, но открывать эту дверь нельзя. а с другой стороны, даже мастера спорта положит на лопатки пуля, так очень ли он в том виноват?
потому что дети выбирают свободу, когда взрослые давно выбрали безопасность ценой свободы...
пробовала ktor/koin и осталась довольна. и для реализации того же, требуется немного больше времени. впрочем, на spring boot мы получаем рабочий продукт практически мгновенно.
да, возможно будет ещё вопрос: а нельзя ли spring boot использовать вместе с kotlin? можно! но есть нюансы. нюанс первый, больше связан скорее не со spring boot, а с jpa/hibernate. так, например, сериализовать kotlin класс java подходом не получится (там есть цикличные ссылки, и вообще, на выходе получается не совсем требуемый java bean), а это нужно hibernate. во-вторых, если весь spring придерживается философии "правильно аннотируй код и сконфигурируй его в application.properties/application.yml", то в котлин-коде очень редко используются аннотации и их обработчики, очень часто используются dsl-лямбды. а потому spring-boot на котлине выглядит несколько странно. и в целом, spring лучше интегрирован с java, котлин здесь ещё гость, поэтому могут быть и другие нюансы
да, ещё одна java боль: дженерики и type erasure. котлин старается вовсю, введя reified types и inline, но, поскольку это архитектурное ограничение самой jvm, то полной информации о дженериках в рантайме нет и не будет. однако, язык спроектирован достаточно хорошо, никаких исключений во время выполнения точно не будет, а явных вынужденных приведений исчезающе мало по сравнению, как часто заставляет делать это java.
скажу за котлин - чудесный язык! сильная строгая типизация на этапе компилирования, ненулевые типы, полная кроссплатформенность (jvm, js, native и mobile), иммутабельность, мультипарадигменность (возможность писать в ооп-стиле, процедурном или функциональном стилях), лёгкая интеграция с java, из мелочей: алясы типов и импортов, var/val/const, богатая стандартная библиотека с операциями над коллекциями, it в качестве имени аргумента лямбды по умолчанию, адекватное поведение this при этом с возможностью ссылаться на this изнутри замыканий, приятные методы захватывания this/it (так, например v.apply {p=0} позволяет устанавливать свойства объекта в стиле builder), бесскобочная запись лямбда аргумента позволяет конструировать dsl-записи, чем активно все пользуются включая тот же gradle, методы-расширения (возможность добавить в сторонний класс новый метод) и свойства, и конечно, именованные аргументы и аргументы по умолчанию, а также интерполяция строк (корректно компилируемая в string builder, в рантайме нет разбора и подстановки). есть баланс между многословностью(обилием ключевых слов) и засилием символов. есть делегируемость свойств, что позволяет делать ещё один вид магии, например, ленивые свойства или реактивные (наблюдаемые свойства). и да, просто свойства, никакого кошмара джависта getXXX/setXXX и соответственно lombok не нужен. и на сладкое - официальные библиотеки для сериализации во многие форматы и coroutines для всех платформ выводят язык на современный уровень. а возможность написания gradle-плагинов доставляет возможность генерировать код во время компиляции: так, например, плагин serialization генерирует сериализатор для всех аннотированных классов. аналогично можно написать свой плагин и избавиться от рефлексии и генерации кода в рантайме, заметно повышая производительность. имеется и работа с сетью, например ktor позволяет писать серверную часть и http клиент тоже (при этом существует возможность писать html и css тоже на котлине благодаря dsl). более того, на kotlin-awesome можно найти библиотеки/фреймворки для практически любой задачи. наконец, для скомпилированного в js кода есть поддержка sourcemaps, что позволяет в devtools видеть и дебажить не высер компилятора, а котлин-код. и наконец, используя javafx и javapackager можно легко и приятно писать десктоп-приложения с инталлятором, при этом не заставляя пользователя иметь jvm и не тащить её всю - только необходимый для работы конкретного приложения минимум. а gradle при правильном написании может собрать всё (вместе с инсталлятором) одной командой gradle package
недостатки, конечно, есть: более медленная компиляция, особенно тяжёл сам gradle, хоть он и стандарт де-факто в java мире по сравнению с "устаревшим" maven. оверхед компилированного кода также есть, что связано с, например, проверками на nullable (т.к. в jvm нет такого понятия). но, всё же он меньше, чем у groovy или scala. ещё, всё ещё нет хорошей документации к js байндингам (имею ввиду kotlin-wrappers), поэтому пока что достаточно утомительно писать react фронт (в частности, из-за типизации). native-разработка, аналогично, утомительна из-за своих особенностей.
но, в итоге, имхо, язык предоставляет максимум для лёгкого, быстрого и приятного кодинга почти всего на свете. наверное, вопросы целесообразности использования остаются там, где очень критична скорость и/или ограниченные ресурсы. ну и, собственно, почему-то сложилось так, что фронт как писали так и пишут на typescript, ,java сервера на spring boot, и только в android-разработке kotlin более популярен.
а это не уже? вот это "раскрыт секрет...", "эксперты нашли..." и т.д.? скорее, следующая ступень"шок, сенсация! вам достаточно всего лишь" - и на хабре
это пока "другие места" не закончатся. а когда уходить будет некуда, что "лучший специалист" поделает? вариант один - уезжать. что не все могут в силу каких-то личных обстоятельств (думаю, кто мог уехать, тот уже уехал)
иногда это единственный способ быть услышанным