Да, но по умолчанию чаты облачные (а для групп и каналов других опций и нет), и, думаю, 99,9% переписки по Telegram проходит в них.
Это важно помнить, если хочется использовать Telegram для чувствительных данных — никаких обычных чатов и любых групп для такой информации.
А для облачных чатов никаких гарантий приватности, кроме репутации компании и доверия ее источникам финансирования (и управления) нет. В этом плане WhatsApp выглядит более защищенным — в нем нет даже опции облачных чатов (а значит и человеческого фактора, когда участники беседы не знают таких технических деталей или случайно раскрывают чувствительную информацию, не задумываясь, что она таковой является или преуменьшая риски), и даже бекапы хранятся у третих лиц (причем разных для разных платформ — iCloud для iOS, Google Drive для Android).
Потенциальные закладки и пр. я здесь не рассматриваю. Это отдельный сложный вопрос, где исходный код, если нет контроля того, что работает на сервере, не спасает (и даже с этим контролем спасает только частично — возможна хитроумная закладка, которая может долго не вскрываться аудитом). Федеративность — тоже не панацея сама по себе, если нет гарантий, что все стороны дискуссии соблюдают жесткие меры безопасности на уровне своих провайдеров сервиса.
val a = "5:11 2:41 1:31 3:8 1:6 2:31".split(' ').map { it.split(':').map(String::toInt) }
var h = a.fold(0) { s, a -> s + a[0] }
var m = a.fold(0) { s, a -> s + a[1] }
h += m / 60
m %= 60
println("$h:$m")
Чуть упрощенная версия:
var (h, m) = "5:11 2:41 1:31 3:8 1:6 2:31"
.split(' ')
.map { it.split(':').map(String::toInt) }
.reduce { s, a -> listOf(s[0] + a[0], s[1] + a[1]) }
h += m / 60
m %= 60
println("$h:$m")
Задача:
Посчитать время, потраченное на разработку нескольких формочек
Решение:
Ну, Apple полностью отказались от поддержки 32 бит в Catalina, хотя это убило ряд приложений, включая большинство нативных игр на Steam. Думаю, их и описанная вами ситуация не остановит. Тем более что последнее время они фокусируются на сервисах, а пользователи, которые ставят на мак Windows сервисами Apple явно пользоваться не будут.
Ну так это свободный выбор. Apple пытается сделать законченное устройство, не ориентированное на кастомизацию. Кому-то это нравится, кому-то нет — благо, Apple не монополист.
Мне лично будет очень интересно посмотреть, что из этого выйдет — за счет вертикальной интеграции Apple зачастую делает качественно очень интересные вещи (AirPods, FaceID, Handoff, синхронизация Bluetooth-подключений между устройствами).
И интересно было бы посмотреть in-depth сравнение между A-серией и Intel/AMD. Не только в плане чистой производительности, но и в плане различных VT, AVX и пр.
Скорее всего, те же кейсы виртуализации ARM->x86 будут работать хуже, чем родная x86->x86. :( Они через эмуляцию будут мигрировать ПО?
Дополнительно удерживаются заушным загибом, поэтому их можно достать из уха, и они останутся на нем «висеть» (хотя выглядит это так себе, я так не делаю)
Работают долго, поэтому кейс можно с собой не носить, а убирать в сумку, наушники — в карман
При этом — в отличие от AirPods, которые я тоже очень люблю, — они шумоизолирующие и лучше подходят для прогулок и офисной работы наедине с музыкой.
А меня просто «убивают» собеседования которое начинаются с фразы "- расскажите немного о себе"
Вообще, конечно, бесполезный вопрос, как и пресловутые «кем вы себя видите через N лет» и «назовите 3 своих сильных качества»
Расслабить — это хорошая цель) Если надо расслабить, я бы более конкретные и персонализированные вопросы задавала, еще как вариант — немного рассказать о себе для начала
никак не могу понять почему многие программисты, у которых должен быть хорошо прокачан анализ и понимание различный процессов и взаимодействий, системное мышление и прочее, тоже страдают этой болезнью Дартаньянов, и даже не пытаются разобраться, при любом несогласии — «он дурак — я дартаньян».
Вы слишком идеализируете программистов. Это такие же люди, как и все остальные. И далеко не у каждого, безотносительно профессии, получается переносить знания из одной предметной области в другую.
Считается, что не нужно быть поваром, чтобы оценивать блюда, но при этом трудно согласиться, что можно оценивать сложный код на Haskell, имея представление о программировании лишь по нескольким роликам на YouTube и статьям на РИА Новости. Так и с бизнесом, экономикой и организациями.
(хотя, кстати, я неправ — Kotlin даже не позволит сделать такие хаки, тогда для таких случаев только делать подобный код на Java без синтаксического сахара)
Иначе небезопасно — поведение становится неконсистентным. Оно зависит от того, проставлен ли у меня член-делегат в корректное значение, или нет. Тогда даже имея корректный not null объект MyCollection, я все равно не могу быть никогда уверен, что я могу вызывать на нем с гарантированно корректными аргументами методы интерфейсов, которые он должен реализовать.
Если бы авторы языка такое разрешили — вы бы от каждой новой библиотеки (или нового обновления старой) вздрагивали при попытке использовать. А используют ли там делегацию? А точно ли проставлен дочерний объект?
А так у вас есть гарантии — на not null объекте всегда можно корректно вызывать методы интерфейсов, которые он реализует, и дальнейшее поведение зависит только от реализации.
Хотите поменять вложенный объект, который определяет поведение? Вы всегда можете сделать вместо:
class Derived(b: Base) : Base by b
вот так:
class Derived(var b: Base) : Base by b
и потом где-то в коде:
derived.b = otherB
и компилятор также проверит, что otherB — not null, и поведение останется консистентным.
Если вы хотите это обойти и действительно понимаете, что делаете. Вы всегда можете сделать очень грязный и плохой хак:
derived = Derived(null!!) // не делайте так
или даже так:
class Derived(var b: Base = null!!): Base by b // не делайте так тем более!
На данный момент лимит памяти задается для используемой RAM, но не для Persistent Memory, поэтому, да, ситуация, когда в Persistence лежит в разы больше данных, чем в RAM — возможна, и это один из сценариев использования Persistence.
СУБД — узкое место при сохранении данных
Непонятно, как PDS решает эту «проблему». Данные все равно на диск писать надо.
Проблема решается через горизонтальное масштабирование. Традиционные реляционные СУБД сложно и дорого масштабировать, и даже когда они масштабируются, они масштабируются на уровень нескольких узлов. Apache Ignite может размещаться на десятках и сотнях узлов, работать на нескольких связанных геораспределенных кластерах, размазывая IO и его издержки.
СУБД — единая точка отказа
Често говоря, зувучит как спекуляция. Якобы нет масштабируемых отказоустойчивых СУБД.
Здесь речь идет, скорее, о классических реляционных СУБД, которые обычно плохо горизонтально масштабируются и имеют ограниченные возможности обеспечения отказоустойчивости при сохранении ACID-гарантий. Если говорить о сравнении с разными классами продуктов для хранения данных, можно привести такую иллюстрацию:
Здесь замечу также, что Apache Ignite является в том числе распределенной СУБД с поддержкой ACID и SQL, но помимо этого имеется множество других возможностей, которые в СУБД других классов зачастую отсутствуют.
Невозможность одновременно выполнять SQL поверх данных в Ignite и в СУБД
Аргумент конечно хороший. Но нет ни слова про ACID. SQL — просто язык запросов. Интересно как релизован(и реализован ли ACID в случае работы с PDS)?
При использовании PDS гарантии ACID остаются в силе.
Необходимость прогрева
Ну вот вообще непонятно. Прогревать нужно и в случае PDS. А если использовать «lazy-run», то возникает вопрос, зачем мне вообще in-memory. Т.е. если после поднятия некоторое время нода будет работать со скоростью обычной реляционной базы и я могу себе это позволить, то получается что in-memory мне и не нужен.
Ранее в принципе не было возможности стартовать быстро, с диска. У некоторых задач есть потребность после рестарта кластера какое-то время поработать медленно, но начать принимать запросы сразу, и после прогрева получить все преимущества распределенного in-memory. Теперь необходимость такого сценария не блокирует выбор Apache Ignite.
Обращу внимание, что важными сторонами Ignite является не только In-Memory, но еще, например, горизонтальная масштабируемость и функционал грида. Далее, в зависимости от задачи, от платформы выбирается тот набор функций, который лучше всего подходит задаче.
Если же для меня критична скорость работы, то возникает вопрос что случится если(а так и будет) часть данных, необходимых для запроса, лежит на нодах, которые не падали, а часть на только что поднятой. Верно ли, что в таком случае время ответа будет равно времени ответа самой медленной ноды(читай реляционной БД)?
Если часть необходимых для запроса данных лежит на узле, где они еще не поднялись с диска, то они будут прочитаны с диска, время выполнения запроса будет соответствующим. Но такой запрос хотя бы можно будет выполнить. Что важнее для задачи — выполнить любой ценой или выполнить только быстро — зависит от задачи. И для того, и для другого сценария есть инструменты реализации.
Здесь вопрос не только в обработке данных в памяти, но и в горизонтально высокомасштабируемой распределенной обработке данных с соответствующей инфраструктурой (колокация, обеспечение отказоустойчивости, удобные интерфейсы доступа и т.д.). Более того, начиная с версии 2.1 Ignite работает не только с памятью, но и с диском.
Очень обстоятельный и детальный комментарий! Спасибо за позитивный отзыв о нас.
Учитывая, что система у вас, судя по всему, достаточно сложная и нагруженная, нужно подробнее изучить ситуацию, конфигурацию нашу и Cassandra, после чего думать, как решить ваши проблемы. Напишу вам в ЛС с предложением пообщаться подробнее на эту тему.
И очень надеюсь, что версия 2.1 приятно удивит.
Должен. Там мы добавим наше собственное распределенное дисковое хранилище с возможностью вытеснять часть данных из памяти на диск (а backup-ы данных и вовсе держать только на диске пока жива primary-копия), делать сквозные SQL-запросы как по данным в памяти, так и по данным на диске, научимся lazy run-у с диска и прогревом памяти уже во время работы узлов кластера, начнем добавлять алгоритмы машинного обучения поверх алгебры, которая появилась в 2.0 и т.д.
Дисковое хранилище можно уже пощупать в вышедшем пару дней назад GridGain 8.1. Код передан в Apache и как только сообщество его переварит и интегрирует в себя, хранилище в полном виде появится и в Apache Ignite, это будет как раз в 2.1, в проприетарной версии будет дополнительно функционал по снятию snapshot-ов.
Данных может быть очень по-разному. Здесь важно понимать, что Apache Ignite, как и Apache Cassandra, — распределенная партиционированная система, поэтому «уместиться в RAM» не значит «уместиться в RAM на одной машине».
В отрыве от Cassandra, некоторые пользователи работают на гигабайтах или десятках гигабайт, некоторые имеют кластеры из нескольких сотен узлов, где на каждом до терабайта памяти, суммарно получая распределенное масштабируемое хранилище на сотни терабайт с анализом данных в реальном времени и возможностью потоковой обработки и CEP.
Соответственно, если есть инсталляция Cassandra, например, на сотни гигабайт, и необходимо добавить скорость вплоть до анализа в реальном времени и возможность работы с произвольными запросами, можно поднять в связке с ней несколько машин с Apache Ignite, с суммарным объемом RAM в несколько сотен гигабайт (сколько — зависит от данных и коэффициента избыточности, которая нужна для HA), после чего обслуживать запросы с кластера Ignite.
Учитывая, что RAM активно дешевеет, а также появляются такие технологии как NVRAM, это может быть во многих сценариях интересным вариантом, который позволяит делать то, что раньше было невозможно.
Пример компании, которая использует Ignite и Cassandra.
https://www.optioncarriere.be/jobviewx/0310e7c44f1afde7a9e89aa5c7c7e259.html — You will work with the team that builds the core of the One Digital Backbone solution providing new digital channels for ING worldwide. We mainly use the following technologies and frameworks: Java 8, Apache Ignite/GridGain, Spring, Kafka, Cassandra, Jenkins, Maven and Nolio.
Из того, что сразу приходит на ум — один из наших клиентов использует для хранения и обработки данных с IoT-устойств десятки наших узлов в кластере, за которым стоит более сотни узлов Cassandra, другой наш клиент — крупный западный банк — также использует Ignite в связке с Cassandra. Cassandra может очень хорошо и быстро сохранять данные, при этом она замечательно масштабируется и обеспечивает отказоустойчивость. Ignite может очень эффективно обрабатывать данные на потоке в реальном времени, обогащая их и отвечая на поступающие запросы, в том числе обеспечивая ad-hoc аналитику.
Думая над автоматизацией задач машинного обучения (нужной для анализа экспериментальных данных медико-биологических исследований), видимо, рано или поздно, придётся придти к чему-то подобному.
Apache Ignite, кстати, действительно используют для научных исследований, в том числе связанных с медициной и фармацевтикой. Например, технологии Ignite использует E-Therapeutics. Поэтому, да, это один из возможных инструментов, который можно применять в этой отрасли, теперь, когда у нас появляются распределенные алгоритмы машинного обучения, таких применений может быть больше, и они могут становиться более легкими и дешевыми.
Можно ли каким-нибудь образом вникнуть в предлагаемый здесь Вами вариант реализации? Имеет ли смысл что-нибудь предлагать, если, в результате понимания реализации и понимания самих методов машинного обучения, появятся идеи, как это можно было (следовало бы) реализовать?
Мы планируем в ближайшее время сделать отдельную техническую статью исключительно про машинное обучение в Apache Ignite, думаю, она сможет в структурированном виде ответить на часть вопросов. Также, естественно, можете спросить на какие-то интересующие темы здесь, на Хабре, или, если есть какой-то более плотный интерес, написать в личку, и мы сможем отдельно встретиться и рассказать больше. Мы, естественно, рады мнениям и предложениям, особенно, от людей из отрасли.
Это важно помнить, если хочется использовать Telegram для чувствительных данных — никаких обычных чатов и любых групп для такой информации.
А для облачных чатов никаких гарантий приватности, кроме репутации компании и доверия ее источникам финансирования (и управления) нет. В этом плане WhatsApp выглядит более защищенным — в нем нет даже опции облачных чатов (а значит и человеческого фактора, когда участники беседы не знают таких технических деталей или случайно раскрывают чувствительную информацию, не задумываясь, что она таковой является или преуменьшая риски), и даже бекапы хранятся у третих лиц (причем разных для разных платформ — iCloud для iOS, Google Drive для Android).
Потенциальные закладки и пр. я здесь не рассматриваю. Это отдельный сложный вопрос, где исходный код, если нет контроля того, что работает на сервере, не спасает (и даже с этим контролем спасает только частично — возможна хитроумная закладка, которая может долго не вскрываться аудитом). Федеративность — тоже не панацея сама по себе, если нет гарантий, что все стороны дискуссии соблюдают жесткие меры безопасности на уровне своих провайдеров сервиса.
Задача:
Получить строку из ASCII кодов.
Решение:
Чуть упрощенная версия:
Задача:
Посчитать время, потраченное на разработку нескольких формочек
Решение:
Количество приведений типов даже меньше (отсутствует float to int **magic** ;) )
А для третьих героев будет Parallels.
Мне лично будет очень интересно посмотреть, что из этого выйдет — за счет вертикальной интеграции Apple зачастую делает качественно очень интересные вещи (AirPods, FaceID, Handoff, синхронизация Bluetooth-подключений между устройствами).
И интересно было бы посмотреть in-depth сравнение между A-серией и Intel/AMD. Не только в плане чистой производительности, но и в плане различных VT, AVX и пр.
Скорее всего, те же кейсы виртуализации ARM->x86 будут работать хуже, чем родная x86->x86. :( Они через эмуляцию будут мигрировать ПО?
При этом — в отличие от AirPods, которые я тоже очень люблю, — они шумоизолирующие и лучше подходят для прогулок и офисной работы наедине с музыкой.
;)
Вы слишком идеализируете программистов. Это такие же люди, как и все остальные. И далеко не у каждого, безотносительно профессии, получается переносить знания из одной предметной области в другую.
Считается, что не нужно быть поваром, чтобы оценивать блюда, но при этом трудно согласиться, что можно оценивать сложный код на Haskell, имея представление о программировании лишь по нескольким роликам на YouTube и статьям на РИА Новости. Так и с бизнесом, экономикой и организациями.
Если бы авторы языка такое разрешили — вы бы от каждой новой библиотеки (или нового обновления старой) вздрагивали при попытке использовать. А используют ли там делегацию? А точно ли проставлен дочерний объект?
А так у вас есть гарантии — на not null объекте всегда можно корректно вызывать методы интерфейсов, которые он реализует, и дальнейшее поведение зависит только от реализации.
Хотите поменять вложенный объект, который определяет поведение? Вы всегда можете сделать вместо:
вот так:
и потом где-то в коде:
и компилятор также проверит, что otherB — not null, и поведение останется консистентным.
Если вы хотите это обойти и действительно понимаете, что делаете. Вы всегда можете сделать очень грязный и плохой хак:
или даже так:
Проблема решается через горизонтальное масштабирование. Традиционные реляционные СУБД сложно и дорого масштабировать, и даже когда они масштабируются, они масштабируются на уровень нескольких узлов. Apache Ignite может размещаться на десятках и сотнях узлов, работать на нескольких связанных геораспределенных кластерах, размазывая IO и его издержки.
Здесь речь идет, скорее, о классических реляционных СУБД, которые обычно плохо горизонтально масштабируются и имеют ограниченные возможности обеспечения отказоустойчивости при сохранении ACID-гарантий. Если говорить о сравнении с разными классами продуктов для хранения данных, можно привести такую иллюстрацию:
Здесь замечу также, что Apache Ignite является в том числе распределенной СУБД с поддержкой ACID и SQL, но помимо этого имеется множество других возможностей, которые в СУБД других классов зачастую отсутствуют.
При использовании PDS гарантии ACID остаются в силе.
Ранее в принципе не было возможности стартовать быстро, с диска. У некоторых задач есть потребность после рестарта кластера какое-то время поработать медленно, но начать принимать запросы сразу, и после прогрева получить все преимущества распределенного in-memory. Теперь необходимость такого сценария не блокирует выбор Apache Ignite.
Обращу внимание, что важными сторонами Ignite является не только In-Memory, но еще, например, горизонтальная масштабируемость и функционал грида. Далее, в зависимости от задачи, от платформы выбирается тот набор функций, который лучше всего подходит задаче.
Если часть необходимых для запроса данных лежит на узле, где они еще не поднялись с диска, то они будут прочитаны с диска, время выполнения запроса будет соответствующим. Но такой запрос хотя бы можно будет выполнить. Что важнее для задачи — выполнить любой ценой или выполнить только быстро — зависит от задачи. И для того, и для другого сценария есть инструменты реализации.
Учитывая, что система у вас, судя по всему, достаточно сложная и нагруженная, нужно подробнее изучить ситуацию, конфигурацию нашу и Cassandra, после чего думать, как решить ваши проблемы. Напишу вам в ЛС с предложением пообщаться подробнее на эту тему.
Должен. Там мы добавим наше собственное распределенное дисковое хранилище с возможностью вытеснять часть данных из памяти на диск (а backup-ы данных и вовсе держать только на диске пока жива primary-копия), делать сквозные SQL-запросы как по данным в памяти, так и по данным на диске, научимся lazy run-у с диска и прогревом памяти уже во время работы узлов кластера, начнем добавлять алгоритмы машинного обучения поверх алгебры, которая появилась в 2.0 и т.д.
Дисковое хранилище можно уже пощупать в вышедшем пару дней назад GridGain 8.1. Код передан в Apache и как только сообщество его переварит и интегрирует в себя, хранилище в полном виде появится и в Apache Ignite, это будет как раз в 2.1, в проприетарной версии будет дополнительно функционал по снятию snapshot-ов.
В отрыве от Cassandra, некоторые пользователи работают на гигабайтах или десятках гигабайт, некоторые имеют кластеры из нескольких сотен узлов, где на каждом до терабайта памяти, суммарно получая распределенное масштабируемое хранилище на сотни терабайт с анализом данных в реальном времени и возможностью потоковой обработки и CEP.
Соответственно, если есть инсталляция Cassandra, например, на сотни гигабайт, и необходимо добавить скорость вплоть до анализа в реальном времени и возможность работы с произвольными запросами, можно поднять в связке с ней несколько машин с Apache Ignite, с суммарным объемом RAM в несколько сотен гигабайт (сколько — зависит от данных и коэффициента избыточности, которая нужна для HA), после чего обслуживать запросы с кластера Ignite.
Учитывая, что RAM активно дешевеет, а также появляются такие технологии как NVRAM, это может быть во многих сценариях интересным вариантом, который позволяит делать то, что раньше было невозможно.
https://www.optioncarriere.be/jobviewx/0310e7c44f1afde7a9e89aa5c7c7e259.html — You will work with the team that builds the core of the One Digital Backbone solution providing new digital channels for ING worldwide. We mainly use the following technologies and frameworks: Java 8, Apache Ignite/GridGain, Spring, Kafka, Cassandra, Jenkins, Maven and Nolio.
Из того, что сразу приходит на ум — один из наших клиентов использует для хранения и обработки данных с IoT-устойств десятки наших узлов в кластере, за которым стоит более сотни узлов Cassandra, другой наш клиент — крупный западный банк — также использует Ignite в связке с Cassandra. Cassandra может очень хорошо и быстро сохранять данные, при этом она замечательно масштабируется и обеспечивает отказоустойчивость. Ignite может очень эффективно обрабатывать данные на потоке в реальном времени, обогащая их и отвечая на поступающие запросы, в том числе обеспечивая ad-hoc аналитику.
Apache Ignite, кстати, действительно используют для научных исследований, в том числе связанных с медициной и фармацевтикой. Например, технологии Ignite использует E-Therapeutics. Поэтому, да, это один из возможных инструментов, который можно применять в этой отрасли, теперь, когда у нас появляются распределенные алгоритмы машинного обучения, таких применений может быть больше, и они могут становиться более легкими и дешевыми.
Мы планируем в ближайшее время сделать отдельную техническую статью исключительно про машинное обучение в Apache Ignite, думаю, она сможет в структурированном виде ответить на часть вопросов. Также, естественно, можете спросить на какие-то интересующие темы здесь, на Хабре, или, если есть какой-то более плотный интерес, написать в личку, и мы сможем отдельно встретиться и рассказать больше. Мы, естественно, рады мнениям и предложениям, особенно, от людей из отрасли.