Когда говорят «воровать» про коррупцию, имхо имеют в виду «присасываться к административным и бизнес-процессам, отщипывая себе и засылая, куда надо». В этом смысле в Сингапуре, одном из бизнес- и финансовых центров мира, воровать очень даже есть что. (Правда если бы так воровали, то он бы этим центром не был, но это уже отдельный вопрос)
Можно тренировать нейросеть не в каждой конкретной машине, а на фабрике, и распространять ее в готовой прошивке. При изменении правил ее нужно дообучить силами производителя машин и опять же распространить как патч.
Что же касается уверенности, то тесты-тесты-тесты-тесты. Как, собственно, и с любым другим ПО :)
Правда не знаю, как это сделать достаточно удобным и необременительным
По-моему, это просто: нужно судить работников салона как соучастников, а если салон не может найти виновных, то судить салон на большие деньги + потенциальная уголовная ответственность для руководства. Нет никакой сложности проводить операции типа восстановления сим-карты по паролю или персональному токену сотрудника.
import scala.languageFeature.reflectiveCalls
def executePoly(x: { def execute(): Unit }): Unit = {
x.execute()
}
class A {
def execute(): Unit = { println("Hello from A") }
}
class B {
def execute(): Unit = { println("Hello from B") }
}
class C
executePoly(new A)
executePoly(new B)
//Won't compile
//executePoly(new C)
Конечно, так почти не делают (без нужды), но техническая возможность удобный duck typing занести есть :)
Хм, вообще в обычной сборке Спарка это два ключа в sparkContext.hadoopConfiguration и вызов sequenceFile с соответствующей схемой в пути (s3n / s3a / s3). Вроде бы мне больше ничего не потребовалось для работы S3.
ИМХО, вряд ли в Спарк-джобах придется использовать самые продвинутые фишки скалы, поэтому любой толковый джавист не только без особого труда разберется в этом коде, но и сможет его писать. Поэтому скала в этом случае будет просто удобной «better Java».
Поэтому присоединяюсь к совету использовать скалу :)
Интересно, кто-то пользуется этими функциями типа хранения файлов, подписок, друзей и т.п.? У меня основной юзкейс: передавать URL между телефонами и браузерами на компьютерах.
Увидел нормальную демонстрацию устройства только когда посмотрел видео для старшей модели, но и оно на 80% состоит из калифорнийских пейзажей и маркетингового булшита. Да что ж за тенденция такая.
И еще, может быть, такое знаете.
Есть, скажем, логические выражения. Хочу, чтобы строки if(true), if (true) и if true разбирались хорошо, а iftrue — фейлилась.
Но получается, что если написать правило { "if" ~ zeroOrMore(" ") ~ Condition }, то успешно разберется iftrue. Если добавить к пробелам разделитель-скобку { "if" ~ (zeroOrMore(" ") | "(") ~ Condition }, то эта скобка не обработается правилом Condition, где для нее особая логика.
Пытался найти какой-то механизм, как возвращать куски входной строки обратно, чтобы их могло обработать следующее правило, или что-то подобное, но не нашел…
Что же касается уверенности, то тесты-тесты-тесты-тесты. Как, собственно, и с любым другим ПО :)
Конечно, так почти не делают (без нужды), но техническая возможность удобный duck typing занести есть :)
Хм, вообще в обычной сборке Спарка это два ключа в
sparkContext.hadoopConfiguration
и вызовsequenceFile
с соответствующей схемой в пути (s3n
/s3a
/s3
). Вроде бы мне больше ничего не потребовалось для работы S3.Поэтому присоединяюсь к совету использовать скалу :)
Есть, скажем, логические выражения. Хочу, чтобы строки
if(true)
,if (true)
иif true
разбирались хорошо, аiftrue
— фейлилась.Но получается, что если написать правило
{ "if" ~ zeroOrMore(" ") ~ Condition }
, то успешно разберетсяiftrue
. Если добавить к пробелам разделитель-скобку{ "if" ~ (zeroOrMore(" ") | "(") ~ Condition }
, то эта скобка не обработается правиломCondition
, где для нее особая логика.Пытался найти какой-то механизм, как возвращать куски входной строки обратно, чтобы их могло обработать следующее правило, или что-то подобное, но не нашел…