Я уже собралась реверсить обфусцированный код Android-приложения, чтобы узнать, как работает парсер
А пореверсить может и стоило. Или пофаззить. В парсерах часто бывают ошибки, знаете ли. Неучтенные крайние случаи. Глядишь, и RCE где завалялось. А тут готовый канал доставки.
Что-то не наблюдаю я такого. А наблюдаю совсем обратное. Отрасль движется в сторону дальнейшей специализации.
Честно скажите, сколько человек в вашей текущей команде знают на приличном уровне два языка и два стека технологий? Критерий "приличности": если человека перевести на другой участок, сроки не просядут на месяц.
Кэширование не отвалится, потому что обращение к ресурсу в бандле выполняется на более низком уровне, подменяя запрос по сети.
Но Гугл активно пропихивает AMP и тут бандлы ему очень пригодятся. А в дальней переспективе, вполне возможно, планирует вырастить из AMP конкурента Cloudflare.
Только вот идентифицирует пользователь этот документ совсем не по ID. А примерным интервалом дат и чем-то в комментарии, что "точно не помню, но как увижу, сразу узнаю". И именно грамотный пейджинг позволяет в таких ситуациях найти этот документ максимально быстро.
А как же кэш, история, загруженные медиафайлы и прочие следы на устройстве? При обнаружении в кэше картинки с "неправильным" мемом наличие/отсутствие скрытых аккаунтов уже не будет иметь значения.
Вроде серьезный подход у вас, а об этом ни слова..
Есть смутное ощущение, что "двойное дно" нормально реализуется только на системном уровне, через FDE например. Но могу и ошибаться.
А что было бы при эксплуатации скулятчера спустя время
Ваше решение исправно работало бы до тех пор, пока нагрузка оставалась в рамках его возможностей. Потом его переписали бы. Это нормальный рабочий процесс.
А вот что было бы, если из-за вашего overegineering бизнес про… скрамил момент выхода на рынок и провалился бы? Ваша душевная боль была бы больше или меньше?
Не очень понимаю, зачем любой гаджет пытаться превратить в смартфон.
Смартфон или ПК есть у каждого потенциального пользователя этого гаджета, пусть набивает базу ключей в нем, со всеми удобствами. Нужно только передать ID ключа по BT.
Я думаю, все-таки вы не поняли. Всего в таблице миллион емейлов, из них только 10 тыс. не в нижнем регистре. Остальные менять нет необходимости. Но можно и поменять, хуже не будет, конечный результат тот же. Только медленнее.
Это как перерисовывать весь экран при перемещении одного окна.
Но обычно вы не можете выбирать сколько записей вы вы обновляете — вся работа «нужная». «Требуется сделать емейлы в таблице капитализированными. А давайте только половину из них сделаем, ради ускорения!» — это имеет мало смысла.
Не передергивайте. Задача "требуется сделать так, чтобы все емейлы в таблице были в нижнем регистре". Ее можно решить несколькими способами, более или менее эффективными. Выбирать более эффективный имеет смысл.
Сейчас в тренде CVE-2020-1472 aka Zerologon. Его мониторить не пробовали?
Это дефолтное имя учетки, под которой работает сервер 1С. Но у нормального админа у этой учетки никогда не будет RDP доступа.
Для ситуаций, где используются велосипедные замки, 30 минут вполне достаточно, даже меньше.
А пореверсить может и стоило. Или пофаззить. В парсерах часто бывают ошибки, знаете ли. Неучтенные крайние случаи. Глядишь, и RCE где завалялось. А тут готовый канал доставки.
В данном случае радиосигналы.
Что-то не наблюдаю я такого. А наблюдаю совсем обратное. Отрасль движется в сторону дальнейшей специализации.
Честно скажите, сколько человек в вашей текущей команде знают на приличном уровне два языка и два стека технологий? Критерий "приличности": если человека перевести на другой участок, сроки не просядут на месяц.
А не высосана ли проблема из пальца? Почему компания не пользуется ЭДО?
P.S. Смахивает на рекламу ELMA, но тогда пример выбран неудачный.
Неужели можно будет выкинуть ShareIt?
defuz, откуда взят текст ответа? Ссылку дайте, пожалуйста.
Ответ не ученого, но чиновника.
Лучше бы СМИ с одноименным названием.
Кэширование не отвалится, потому что обращение к ресурсу в бандле выполняется на более низком уровне, подменяя запрос по сети.
Но Гугл активно пропихивает AMP и тут бандлы ему очень пригодятся. А в дальней переспективе, вполне возможно, планирует вырастить из AMP конкурента Cloudflare.
А у вас опыт, простите, юзера или разработчика?
Только вот идентифицирует пользователь этот документ совсем не по ID. А примерным интервалом дат и чем-то в комментарии, что "точно не помню, но как увижу, сразу узнаю". И именно грамотный пейджинг позволяет в таких ситуациях найти этот документ максимально быстро.
Но фича оказалась настолько полезной, что аналог в SQL все-таки добавили: recursive CTE.
А как же кэш, история, загруженные медиафайлы и прочие следы на устройстве? При обнаружении в кэше картинки с "неправильным" мемом наличие/отсутствие скрытых аккаунтов уже не будет иметь значения.
Вроде серьезный подход у вас, а об этом ни слова..
Есть смутное ощущение, что "двойное дно" нормально реализуется только на системном уровне, через FDE например. Но могу и ошибаться.
Ваше решение исправно работало бы до тех пор, пока нагрузка оставалась в рамках его возможностей. Потом его переписали бы. Это нормальный рабочий процесс.
А вот что было бы, если из-за вашего overegineering бизнес про… скрамил момент выхода на рынок и провалился бы? Ваша душевная боль была бы больше или меньше?
Не очень понимаю, зачем любой гаджет пытаться превратить в смартфон.
Смартфон или ПК есть у каждого потенциального пользователя этого гаджета, пусть набивает базу ключей в нем, со всеми удобствами. Нужно только передать ID ключа по BT.
Я думаю, все-таки вы не поняли. Всего в таблице миллион емейлов, из них только 10 тыс. не в нижнем регистре. Остальные менять нет необходимости. Но можно и поменять, хуже не будет, конечный результат тот же. Только медленнее.
Это как перерисовывать весь экран при перемещении одного окна.
Не передергивайте. Задача "требуется сделать так, чтобы все емейлы в таблице были в нижнем регистре". Ее можно решить несколькими способами, более или менее эффективными. Выбирать более эффективный имеет смысл.
Этот механизм есть в других СУБД, название может отличаться. Этот совет применим везде, где механизм доступен.
Транзакционный DDL есть в других СУБД.
Тут согласен. Механизмы для возврата результата из DML есть в других СУБД, но они сильно отличаются.
Наверное, совет должен звучать как "Изучите доступные типы индексов и используйте наиболее подходящий в конкретной ситуации.