Насчёт костыля: а сколько раз вам нужно было определить?
Если dll не совсем безумная и не передаёт вам то blocking, то non-blocking — то один раз посмотреть посредством костыля — вроде нормально (костыль не идёт в prodaction, оставшись в тулзе для внутреннего пользования).
Дык пожалуйста. Стандартный набор из 4096 слов — по сути, 12-битные символы. Полный перебор.
Я говорил об удобном способе набора именно этих слов (в 2-3 тапа каждое)
Вроде полезная подборка материала — и сделана картинками 8-O.
Это чтобы по ним искать нельзя было? Или считается, что кто освоил grep — обойдётся man'ом?
Всё равно при чтении в словарь заглядываю, а он историю пишет. Нет смысла слово вначале смотреть в словаре, потом добавлять в прогу — лучше сделать всё в одно действие. Тем паче в словарь я заглядываю гораздо проще, чем "скопировать и добавить" — просто long tap (а могу перенастроить — и буду смотреть просто по тапу на слово).
Хотя "скопировал и добавил", конечно, тоже полезная фича (как и обычно применяющаяся вместо неё в словарях андроидная фича "share").
Подробнее на прогу посмотрю, да (хотя пока предпочитаю AnkiDroid).
Есть чувство, что карточки наиболее полезны, когда сам выписываешь их из реального текста. Читаешь, наткнулся на незнакомое слово, посмотрел в словаре. Вечером экспортнул историю словаря в карточки и повторил.
Вот про «влезание» 40-50 символов как раз и вопрос — почему бы их не позволить?
Ввести сложнее — да (хотя как раз на экранной клавиатуре возня с переключением регистров для ввода цифр и знаков препинания тоже замедляет ввод). Теоретически — можно было бы сделать специальную «клавиатуру» для удобного ввода паролей из фиксированного набора слов. Или иметь возможность ввести пароль как в виде пачки слов (легко для запоминания), так и в «абстрактном» виде (смутно помню, что какой-то вариант OTP отдавал пароли в двух видах: N слов из словаря на 4096 элементов или 3*N 16-ричных цифр, но не могу найти, какой).
Для паролей такого типа стойкость посчитана же… Так что что касается брутфорса — всё упирается в количество слов. В первом приближении одно слово такого пароля заменяет два символа в пароле с буквами, цифрами и знаками препинания — если, конечно, оба сгенерили случайно. А запомнить легче.
Вот кстати да. Давно сами пароли никто не хранит — хранят лишь солёный хэш. Т.е. длина пароля вообще не имеет значения — ну, придётся хэш посчитать от 40 символов, а не от 20 — о чём вообще речь?
Инструмент-то отличный, но как только на сайте появился pop-up с предложением подписаться — я жму кнопку "блокировать", а сайт получает минус балл в моём личном рейтинге.
Такие вещи должны как-то адекватно проделываться — ну там, в личном кабинете на сайте, например (там, где управляешь подписками)
Хорошо, но изучили ли вы опыт предшественников? Конкретнее — посмотрите на anki, там заметно более продвинутый, чем у вас, алгоритм выбора момента показа слов.
Из функционала, который стОит сделать — интегрироваться со словарями на смартфоне. У многих есть возможность получить history — соответственно, её добавление в список для заучивания — идеально. Читаешь себе книжку на иностранном языке, смотришь незнакомые слова в словаре (лично я использую связку AlReader + GoldenDict, длинный тап на незнакомое слово), а потом повторяешь выписанные слова.
Лично я ещё со старой оперы привык к поиску вида буква-пробел-что_искать.
g текст — поиск в гугле
w текст — в вики
t текст — перевод
и так далее, очень удобно, мышь не нужна.
Вот насчёт addon api — не соглашусь с вами. По мне, так это просто праздник какой-то, что они похоронили эту старую кучу костылей. Там было очень много странного. Чего стоил один отказ от npapi плагинов в пользу js-ctypes? Типа, если вашему расширению надо обращаться к нативу — вы больше не можете использовать выполняющийся в отдельном процессе npapi-plugin, это несекьюрно. Вместо этого загрузите через js-ctypes свою либу прямо в процесс firefox.
Какое счастье, что это всё похоронили!
Глядите. Очередь/стек — это не конкретная структура, а объект, реализующий две операции: положить в очередь (push) и взять из очереди (pull). Для очереди порядок выдаются объекты в том же порядке — FIFO (First In First Out), для стека в обратном — LIFO (Last In First Out). Ну, есть ещё очередь с приоритетами — это когда первым выдаёт объект с наивысшим приоритетом.
Итого, если мы сделали нечто, умеющее правильно выполнять эти операции — это очередь :-)
Варианты реализации (на примере LIFO очереди):
Связный список. Ну, тут всё просто: push добавляет объект к концу списка, pull берёт из начала (и выкидывает этот объект из списка). Сложность обеих операций O(1), но надо выделять память на каждый push.
Массив. Если ограничить длину очереди — поверх массива делается кольцевой буфер: указатели на "голову" и "хвост" очереди.
push — кладём элемент на место, куда указывает хвост, сдвигаем указатель на 1 элемент направо (возвращаясь к началу массива, если перешли за конец).
pull — берём элемент из места, куда указывает голова, сдвигаем голову на 1 направо (опять же "закольцевав" движение)
Сложность обеих операций опять же O(1), но нет выделения памяти на каждый чих — работает быстрее.
В варианте 2 размер ограничен, если нужен неограниченный — при заполнении массива увеличиваем его — точнее, выделяем новый и копируем туда все данные. Удобно увеличивать размер ровно в два раза, тогда получаем амортизированную сложность (т.е. в среднем по куче операций) опять же O(1), но вот в худшем случае (когда увеличиваем массив) уже O(n).
Ну, можно придумать ещё кучу других реализаций, но это самые распространённые.
Ну да, просто после STL и прочих библиотек, в которых list == linked list, это было непривычно.
А учитывая, что явно указана сложность Item[i] как O[1] — это не абстрактная реализация списка, а именно аналог std::vector.
Из смешного по теме: в C# класс List — на самом деле массив, реальный список — LinkedList. Вот до такой степени MS верит в преимущество массивов в большинстве случаев.
Не будет выделений/освобождений в куче на каждый чих — существенный выигрыш. И вообще нет кучи мелких кусочков памяти, выделенных в куче, всё лежит локально (и удобно попадает в кэш проца для задач, где стек используется активно)
Если не выделить сразу сколько надо памяти — иногда (например, при каждом удвоении размера массива) придётся реаллоцировать, тут мы проиграем (в среднем быстродействие всё равно выше, чем у списка, но иногда операция добавления элемента может оказаться долгой — в некоторых задачах это неприемлемо)
В общем, редко когда имеет смысл делать очередь или стек на списке.
Кстати, напомню об ещё одной структуре для хранения вектора переменного размера: массив массивов (или список массивов). Позволяет объединить плюсы обоих подходов за счёт некоторого усложнения кода, но нужен редко.
Всё вперемешку. Ужас.
Очередь и стек — самостоятельные структуры данных? Ничего, что их можно реализовать и поверх массива, и поверх списка — с разными свойствами соответственно?
Мапа, сет, дерево, хэш-таблица на одном уровне? "Раньше я думал, что Карл Маркс и Фридрих Энгельс — муж и жена, а теперь я знаю, что это четыре разных человека" :-)
Насчёт костыля: а сколько раз вам нужно было определить?
Если dll не совсем безумная и не передаёт вам то blocking, то non-blocking — то один раз посмотреть посредством костыля — вроде нормально (костыль не идёт в prodaction, оставшись в тулзе для внутреннего пользования).
Что-то такое припоминаю (на кассе сканер штрих-кода подсоединён, как клавиатура), но там надо целую пачку штрих-кодов предъявлять было.
Я говорил об удобном способе набора именно этих слов (в 2-3 тапа каждое)
Вроде полезная подборка материала — и сделана картинками 8-O.
Это чтобы по ним искать нельзя было? Или считается, что кто освоил grep — обойдётся man'ом?
Всё равно при чтении в словарь заглядываю, а он историю пишет. Нет смысла слово вначале смотреть в словаре, потом добавлять в прогу — лучше сделать всё в одно действие. Тем паче в словарь я заглядываю гораздо проще, чем "скопировать и добавить" — просто long tap (а могу перенастроить — и буду смотреть просто по тапу на слово).
Хотя "скопировал и добавил", конечно, тоже полезная фича (как и обычно применяющаяся вместо неё в словарях андроидная фича "share").
Подробнее на прогу посмотрю, да (хотя пока предпочитаю AnkiDroid).
Есть чувство, что карточки наиболее полезны, когда сам выписываешь их из реального текста. Читаешь, наткнулся на незнакомое слово, посмотрел в словаре. Вечером экспортнул историю словаря в карточки и повторил.
Ввести сложнее — да (хотя как раз на экранной клавиатуре возня с переключением регистров для ввода цифр и знаков препинания тоже замедляет ввод). Теоретически — можно было бы сделать специальную «клавиатуру» для удобного ввода паролей из фиксированного набора слов. Или иметь возможность ввести пароль как в виде пачки слов (легко для запоминания), так и в «абстрактном» виде (смутно помню, что какой-то вариант OTP отдавал пароли в двух видах: N слов из словаря на 4096 элементов или 3*N 16-ричных цифр, но не могу найти, какой).
Для паролей такого типа стойкость посчитана же… Так что что касается брутфорса — всё упирается в количество слов. В первом приближении одно слово такого пароля заменяет два символа в пароле с буквами, цифрами и знаками препинания — если, конечно, оба сгенерили случайно. А запомнить легче.
Что проверить? Когда пользователь ввёл пароль — от него считается хэш. Всё, дальше пароль не используется, а хэш имеет фиксированную длину.
Если 20 символов хватает, чтобы хэш был "случайным" — то чем хуже 40? Почему нельзя позволить?
Вот кстати да. Давно сами пароли никто не хранит — хранят лишь солёный хэш. Т.е. длина пароля вообще не имеет значения — ну, придётся хэш посчитать от 40 символов, а не от 20 — о чём вообще речь?
Инструмент-то отличный, но как только на сайте появился pop-up с предложением подписаться — я жму кнопку "блокировать", а сайт получает минус балл в моём личном рейтинге.
Такие вещи должны как-то адекватно проделываться — ну там, в личном кабинете на сайте, например (там, где управляешь подписками)
Хорошо, но изучили ли вы опыт предшественников? Конкретнее — посмотрите на anki, там заметно более продвинутый, чем у вас, алгоритм выбора момента показа слов.
Из функционала, который стОит сделать — интегрироваться со словарями на смартфоне. У многих есть возможность получить history — соответственно, её добавление в список для заучивания — идеально. Читаешь себе книжку на иностранном языке, смотришь незнакомые слова в словаре (лично я использую связку AlReader + GoldenDict, длинный тап на незнакомое слово), а потом повторяешь выписанные слова.
Лично я ещё со старой оперы привык к поиску вида буква-пробел-что_искать.
g текст — поиск в гугле
w текст — в вики
t текст — перевод
и так далее, очень удобно, мышь не нужна.
Вот насчёт addon api — не соглашусь с вами. По мне, так это просто праздник какой-то, что они похоронили эту старую кучу костылей. Там было очень много странного. Чего стоил один отказ от npapi плагинов в пользу js-ctypes? Типа, если вашему расширению надо обращаться к нативу — вы больше не можете использовать выполняющийся в отдельном процессе npapi-plugin, это несекьюрно. Вместо этого загрузите через js-ctypes свою либу прямо в процесс firefox.
Какое счастье, что это всё похоронили!
Глядите. Очередь/стек — это не конкретная структура, а объект, реализующий две операции: положить в очередь (push) и взять из очереди (pull). Для очереди порядок выдаются объекты в том же порядке — FIFO (First In First Out), для стека в обратном — LIFO (Last In First Out). Ну, есть ещё очередь с приоритетами — это когда первым выдаёт объект с наивысшим приоритетом.
Итого, если мы сделали нечто, умеющее правильно выполнять эти операции — это очередь :-)
Варианты реализации (на примере LIFO очереди):
Ну, можно придумать ещё кучу других реализаций, но это самые распространённые.
Ну да, просто после STL и прочих библиотек, в которых list == linked list, это было непривычно.
А учитывая, что явно указана сложность Item[i] как O[1] — это не абстрактная реализация списка, а именно аналог std::vector.
Из смешного по теме: в C# класс List — на самом деле массив, реальный список — LinkedList. Вот до такой степени MS верит в преимущество массивов в большинстве случаев.
В общем, редко когда имеет смысл делать очередь или стек на списке.
Кстати, напомню об ещё одной структуре для хранения вектора переменного размера: массив массивов (или список массивов). Позволяет объединить плюсы обоих подходов за счёт некоторого усложнения кода, но нужен редко.
Всё вперемешку. Ужас.
Очередь и стек — самостоятельные структуры данных? Ничего, что их можно реализовать и поверх массива, и поверх списка — с разными свойствами соответственно?
Мапа, сет, дерево, хэш-таблица на одном уровне? "Раньше я думал, что Карл Маркс и Фридрих Энгельс — муж и жена, а теперь я знаю, что это четыре разных человека" :-)
Рано вам кого-то учить.