Пока ехал и сам понял что одно и то же по сути.
И слияние без перебора никак не придумывается. Точнее придумывается, но деревья появляются и вообще одинаково со статьей получается.
Я не понимаю этого нехотения писать код. Писать код это то что мы хорошо умеем делать. Это то за что нам платят деньги. Просто логично на собеседовании показать свое лучшее умение.
Забытый кусок синтаксиса это ну настолько мелкая проблема. Всегда можно честно сказать я забыл как именно это пишется. Поэтому считаем массив заранее инициализированным. Тонкости синтаксиса гуглятся за минуту. Все в курсе.
Есть множество людей которые не способны писать код. Вообще. При этом у них будет красивое резюме (мы же не хотим проводить расследование о правдивости резюме для каждого кандидата?), они будут очень красиво говорить общие слова и даже смогут ответить на типовые теоретические вопросы. На работе они будут копипастить со SO без понимания как и почему. Как таких отсеять? Отсеивание на испытательном сроке это очень печально, его надо всеми силами избегать.
Проверяем умение писать код. Простой. Абстрактный. Это точно проще чем любой продакшен код. И это как минимум гарантирует что человек лабы в университете делал сам. Таких меньшинство.
Я лично собеседовал человека у которого в резюме было слово SQL, а в вакансии было слово Оракл. У него судя по резюме был опыт, он довольно красиво рассказывал про нормальные формы и прочую теорию.
Только вот с задачей написать простенький селект с джойном и групбаем из пары табличек на бумажке он не справился. От слова вообще. Такое ощущение, что он синтаксис sql впервые увидел. О чем после такого может идти речь?
Я сильно подозреваю что на вакансии Java, С итп такие же кадры приходят. Резюме вроде хорошее работал, сделал итд. Теорию зазубрить несложно. На собеседованиях очень типовые вещи по теории спрашивают. А вот написать десяток строк кода человек не может.
Отмазки мол я не могу без IDE написать десять строк кода это глупости. Базовый синтаксис у любого человека пишущего код за деньги в подкорке сидит. Каждый день же используешь. В практических задачах использовать что-то кроме базового синтаксиса никогда не надо. О сложных вещах можно и просто поговорить.
Спрашивать сложные вещи по теории хуже чем заставлять писать код. Они как раз каждый день не используются и великолепно забываются.
Я наверно что-то не понял, но зачем так сложно? Нечто вроде баскет сорта великолепно сработает.
Заводим лист с номерами корзин и мапу с самими корзинами.
HashMap<String, Integer> baskets;
List basketNumbers;
Первую пару кладем в нулевую.
Далее для каждой пары: Если любое слово из пары найдено в любой корзине, второе добавляем в туже. Если ничего не найдено заводим новую с новым номером. Если найдены в разных, то ставим им одинаковый номер.
Далее тривиально ищем номера корзин для всех отличающихся слов в строках для поиска.
Сложность O(m+n)
m количество пар
n количество слов в минимальной строке для поиска
Вы отказываетесь писать работающий код на собеседовании на должность программиста? Не домашнее задание на неделю работы, а именно на собеседовании в офисе.
Вот мне даже интересно как такие люди вообще работу находят?
Современный JIT великолепен. После прогрева он выдает результат отличающийся от идеально сферического на считанные проценты. А где ваши тесты быстродействия можно посмотреть?
Ну начать можно с того что Прогрессы и Союзы стыкуются к Звезде. Он стоит за Зарей. Формат стыковочных узлов Звезды с Юнити может оказаться несовместимым.
И продолжить можно тем что собирали все с Шатлов. После многих лет в космосе разборка ну никак не проще сборки будет. А с учетом всего что вокруг Юнити и Зари наворотили так и сложнее. Шатлов давно уже нет, и замены с аналогичными возможностями (та же рука) пока не видно. Вспоминая видео вскрытия Союза вручную не потянут.
Вот в не видно вариантов разборки, даже не учитывая потенциальные трубопроводы и прочие внутренние проблемы. Нечем разбирать и некуда стыковаться.
Базовые модули заменить нереально. Так станцию строили. Заря это как раз базовый модуль.
При слишком частых поломках или проблемах всю станцию надо в океан.
Новую станцию уже можно попробовать спроектировать уже с учетом ремонта и замены базовых модулей.
В остальном — а нельзя ли эту задачу выполнять по индукции? Ну, т.е. нашли решения для доски n x n, а затем придумываем как перейти к решению для (n + 1) x (n + 1). Явно, что это правило перехода должно быть универсальным. Или… нет?
Доказательство такой возможности, даже без алгоритма, потянет на серьезную математическую премию.
PDF Хорош своей стабильностью и универсальностью. Любой файл на любом устройстве будет показан одинаково.
И плох ей же. К примеру, электронные книги не могут отрисовывать странички красиво под свой размер.
Количество костылей в PDF просто зашкаливает. Начиная от кучи древних форматов хранения картинок. Там есть такая экзотика… Включая забагованный JBIG2.
И заканчивая множествами вариантами для производства одной операции. Все можно сделать несколькими способами. Зачем непонятно. Результат абсолютно одинаков. Нет даже рекомендаций как рекомендуется делать.
Очень хочу новую ревизию с deprecated всей экзотики и рекомендациями по использованию методов для типовых вещей. Вот в этом замучаешься разбираться: T*, Tc, Td, TD, Tj, TJ, TL, Tm, Tr, Tw, Tz И это только базовый вывод текста. Функционал дублируется раза 3.
Как именно шифровать это не важно в данном случае. Но необходимо понимать общий принцип шифрования. Пакет отдельно, пользовательские данные в нем отдельно. Ключ от пакета сессионный, ключ от пользовательских данных только у получателя.
Миллион пользователей это мало. Мессенджеры нынче живут на миллиарде пользователей. И любая разработка должна быть готова к работе с таким объемом. Миллиард это 10Тб шаренной и доступной со всех узлов входа ОЗУ только на сессии. Это уже много. Очень много. Да и просто держать столько открытых tls сессий это задача ну очень нетривиальная.
Проблема что это плохо масштабируется горизонтально.
Проблема что это плохо будет работать за фаерваллами.
Это будет плохо работать за двойными натами.
Это плохо совместимо с проксями.
Это проблема консистентности статуса клиента и сервера.
Это в конце концов кастомный низкоуровневый протокол. То есть все типовые балансировщики с ним будут работать плохо или не будут вообще.
Реверс прокси работать не будет точно.
И ради чего все это? Чтобы пользователь имел повышенный шанс отправить сообщение при ухудшении сигнала? Оно того не стоит.
Вы вот так вот сразу отказали от End2End шифрования. В 2019 году. Вы это серьезно?
Шифруем все в 2 слоя. Первый пакет до сервера, второй само сообщение.
Сессионный ключ клиента это не паблик ключ сервера. Это именно сессионный ключ. Чтобы в случае компрометации серверного ключа трафик нельзя было расшифровать. Да и использовать один ключ неопределенно долгое время это не очень. Азы же.
1. Вы считаете размер пакета, а надо считать размер инфы которою нужно хранить на серверах для поддержания сессии.
2. Всю историю можно хранить на дисках и не париться о скорости. Подгрузка истории это процесс не требующий особой скорости. Клиент готов подождать пока у него загрузится история на новой устройстве. А вот информация о сессиях нужна в памяти. К ней нужен очень быстрый доступ.
3. Проблема не в сообщениях, а в клиентах. С сообщениями все понятно. таймстемп последнего и хеш от него же.
При https да. Именно так и делаем и все просто. Вы же хотите кастомный udp протокол. На сервер будет приходить шифрованный массив. Надо найти от него ключ, расшифровать, найти клиента, валидировать что все ок и уже потом передать на обработку.
4. Сессионные ключи строго обязательны в 2019 году. Я выше написал.
Это даже на идею не тянет. Не говоря уже о прототипе. Отправка по UDP пакета и ожидание ответа сервера перед отправкой следующего максимум на лабораторку тянет.
Решается, только масштабируется не очень. Нам нужен как минимум id клиента, id сессии, ключ шифрования и хеш с таймстемпом последнего сообщения. Пара килобайт точно. Если подумать точно еще что-то вылезет что надо хранить. На миллиарде клиентов это терабайты данных.
Шардирование делать сложно. Пакеты шифрованные. В начале надо терминировать tls. Проблема явно решаемая, но не с налету.
Вот чувствую зря я про совсем потом на писал. Там и без этого пункта проблем с stateful выше крыши.
Вы находитесь здесь...
И слияние без перебора никак не придумывается. Точнее придумывается, но деревья появляются и вообще одинаково со статьей получается.
Забытый кусок синтаксиса это ну настолько мелкая проблема. Всегда можно честно сказать я забыл как именно это пишется. Поэтому считаем массив заранее инициализированным. Тонкости синтаксиса гуглятся за минуту. Все в курсе.
Есть множество людей которые не способны писать код. Вообще. При этом у них будет красивое резюме (мы же не хотим проводить расследование о правдивости резюме для каждого кандидата?), они будут очень красиво говорить общие слова и даже смогут ответить на типовые теоретические вопросы. На работе они будут копипастить со SO без понимания как и почему. Как таких отсеять? Отсеивание на испытательном сроке это очень печально, его надо всеми силами избегать.
Проверяем умение писать код. Простой. Абстрактный. Это точно проще чем любой продакшен код. И это как минимум гарантирует что человек лабы в университете делал сам. Таких меньшинство.
Я лично собеседовал человека у которого в резюме было слово SQL, а в вакансии было слово Оракл. У него судя по резюме был опыт, он довольно красиво рассказывал про нормальные формы и прочую теорию.
Только вот с задачей написать простенький селект с джойном и групбаем из пары табличек на бумажке он не справился. От слова вообще. Такое ощущение, что он синтаксис sql впервые увидел. О чем после такого может идти речь?
Я сильно подозреваю что на вакансии Java, С итп такие же кадры приходят. Резюме вроде хорошее работал, сделал итд. Теорию зазубрить несложно. На собеседованиях очень типовые вещи по теории спрашивают. А вот написать десяток строк кода человек не может.
Отмазки мол я не могу без IDE написать десять строк кода это глупости. Базовый синтаксис у любого человека пишущего код за деньги в подкорке сидит. Каждый день же используешь. В практических задачах использовать что-то кроме базового синтаксиса никогда не надо. О сложных вещах можно и просто поговорить.
Спрашивать сложные вещи по теории хуже чем заставлять писать код. Они как раз каждый день не используются и великолепно забываются.
Я наверно что-то не понял, но зачем так сложно? Нечто вроде баскет сорта великолепно сработает.
Заводим лист с номерами корзин и мапу с самими корзинами.
HashMap<String, Integer> baskets;
List basketNumbers;
Первую пару кладем в нулевую.
Далее для каждой пары: Если любое слово из пары найдено в любой корзине, второе добавляем в туже. Если ничего не найдено заводим новую с новым номером. Если найдены в разных, то ставим им одинаковый номер.
Далее тривиально ищем номера корзин для всех отличающихся слов в строках для поиска.
Сложность O(m+n)
m количество пар
n количество слов в минимальной строке для поиска
Вот мне даже интересно как такие люди вообще работу находят?
Зря вы так плохо думаете о разработчиках Фейсбука.
И продолжить можно тем что собирали все с Шатлов. После многих лет в космосе разборка ну никак не проще сборки будет. А с учетом всего что вокруг Юнити и Зари наворотили так и сложнее. Шатлов давно уже нет, и замены с аналогичными возможностями (та же рука) пока не видно. Вспоминая видео вскрытия Союза вручную не потянут.
Вот в не видно вариантов разборки, даже не учитывая потенциальные трубопроводы и прочие внутренние проблемы. Нечем разбирать и некуда стыковаться.
При слишком частых поломках или проблемах всю станцию надо в океан.
Новую станцию уже можно попробовать спроектировать уже с учетом ремонта и замены базовых модулей.
А для научного спутника на такой странной орбите вопрос не актуален. Отработал гарантийный срок и хорошо. Переработал вообще замечательно.
Доказательство такой возможности, даже без алгоритма, потянет на серьезную математическую премию.
Или есть еще какая причина использовать велосипед, вместо отраслевого стандарта?
И плох ей же. К примеру, электронные книги не могут отрисовывать странички красиво под свой размер.
Количество костылей в PDF просто зашкаливает. Начиная от кучи древних форматов хранения картинок. Там есть такая экзотика… Включая забагованный JBIG2.
И заканчивая множествами вариантами для производства одной операции. Все можно сделать несколькими способами. Зачем непонятно. Результат абсолютно одинаков. Нет даже рекомендаций как рекомендуется делать.
Очень хочу новую ревизию с deprecated всей экзотики и рекомендациями по использованию методов для типовых вещей. Вот в этом замучаешься разбираться: T*, Tc, Td, TD, Tj, TJ, TL, Tm, Tr, Tw, Tz И это только базовый вывод текста. Функционал дублируется раза 3.
Миллион пользователей это мало. Мессенджеры нынче живут на миллиарде пользователей. И любая разработка должна быть готова к работе с таким объемом. Миллиард это 10Тб шаренной и доступной со всех узлов входа ОЗУ только на сессии. Это уже много. Очень много. Да и просто держать столько открытых tls сессий это задача ну очень нетривиальная.
Проблема что это плохо масштабируется горизонтально.
Проблема что это плохо будет работать за фаерваллами.
Это будет плохо работать за двойными натами.
Это плохо совместимо с проксями.
Это проблема консистентности статуса клиента и сервера.
Это в конце концов кастомный низкоуровневый протокол. То есть все типовые балансировщики с ним будут работать плохо или не будут вообще.
Реверс прокси работать не будет точно.
И ради чего все это? Чтобы пользователь имел повышенный шанс отправить сообщение при ухудшении сигнала? Оно того не стоит.
Шифруем все в 2 слоя. Первый пакет до сервера, второй само сообщение.
Сессионный ключ клиента это не паблик ключ сервера. Это именно сессионный ключ. Чтобы в случае компрометации серверного ключа трафик нельзя было расшифровать. Да и использовать один ключ неопределенно долгое время это не очень. Азы же.
1. Вы считаете размер пакета, а надо считать размер инфы которою нужно хранить на серверах для поддержания сессии.
2. Всю историю можно хранить на дисках и не париться о скорости. Подгрузка истории это процесс не требующий особой скорости. Клиент готов подождать пока у него загрузится история на новой устройстве. А вот информация о сессиях нужна в памяти. К ней нужен очень быстрый доступ.
3. Проблема не в сообщениях, а в клиентах. С сообщениями все понятно. таймстемп последнего и хеш от него же.
При https да. Именно так и делаем и все просто. Вы же хотите кастомный udp протокол. На сервер будет приходить шифрованный массив. Надо найти от него ключ, расшифровать, найти клиента, валидировать что все ок и уже потом передать на обработку.
4. Сессионные ключи строго обязательны в 2019 году. Я выше написал.
Решается, только масштабируется не очень. Нам нужен как минимум id клиента, id сессии, ключ шифрования и хеш с таймстемпом последнего сообщения. Пара килобайт точно. Если подумать точно еще что-то вылезет что надо хранить. На миллиарде клиентов это терабайты данных.
Шардирование делать сложно. Пакеты шифрованные. В начале надо терминировать tls. Проблема явно решаемая, но не с налету.
Вот чувствую зря я про совсем потом на писал. Там и без этого пункта проблем с stateful выше крыши.