lolrofl01

Это задача поиска закономерности. То есть по сути вам нужно найти алгоритм, формулу, функцию, по которой эти числа генерируются. Это не простая задача.

Начнём с того, что может быть два варианта: либо формула есть, либо её нет. Случайное число относится к варианту, когда формулы нет. Хотя псевдослучайное число можно описать, но это отдельный, пограничный случай (потому что если число должно быть случайным, но имеется формула, то это по сути ошибка автора алгоритма, и ответ будет зависеть от того, что вам нужно и чем вы занимаетесь - исправлением ошибки или её эксплуатацией).

Но даже если формула есть, совсем не обязательно, что вы сможете её найти. Например, человечество давно занимается поиском закономерностей во внешнем мире с переменным успехом. Мы исходим из того, что всё как-то устроено, но как именно, мы можем догадываться. Смотрим, наблюдаем, а потом бац - замечаем закономерность, оформляем её в виде научного открытия и радуемся. Законы физики, химии, той же математики - это всё есть в результате поиска закономерностей и удачи.

Таким образом, что же можно простого предложить в вашем случае? Можете сформулировать гипотезу и проверить её. Потом ещё одну - тоже проверить. И так далее.

Автоматизировать это можно следующим образом. Делайте список математических функций и операций, которые, по-вашему, могли быть применены. Делаете прочие допущения. Например, о том, что каждая группа из 8 чисел не зависит от предыдущей, то есть вам нужно по первым числам из группы угадать остальные. Либо, наоборот, что следующая группа зависит от предыдущей, тогда надо угадать цифры, исходя из того, что было в прошлом. Ну и, собственно, осуществляете перебор алгоритмов (формул), как бы это дико ни звучало.

То есть формулы могут быть, например, такие: (N * 917 mod 512), или же (N * N mod 100 ) и так далее (mod - это остаток от деления, а N - номер числа). То есть это какие-то функции на основе каких-то аргументов. Вам надо придумать, в каком виде их представить как данные, и перебирать по очереди.

Но, как я сказал выше, формулы может не быть, либо вы её не угадаете даже с перебором, либо она может быть такой сложной, что умный всеобъемлющий перебор займёт годы. Удачи! :)

Работал с Nuxt в сумме примерно в течение года. Написал свой блог на нем (довольно большой), вот он на гитхабе: https://github.com/iliyaZelenko/blog-frontend

Недостатки которые заметил:

1) Он долго запускается при `nuxt dev` (мой блог запускается за 3-5 минут) и HMR обновляется в среднем 1-5 секунд (порой и дольше), даже если обновил просто template. Это больше всего напрягает.

2) После изменения кода, иногда папка `.nuxt` генерируется с ошибкой, приходится менять любую строчку в исходниках проекта чтобы опять запустить генерацию или порой полностью перезапускать Nuxt. Такая проблема была замечена не на всех проектах.

3) Бывает проблематично использовать модули которые не идут сразу на сервере и на клиенте, но это больше проблема SSR. Еще порой хочется получить сам nuxt контекст где store, router, плагины, но это нельзя сделать в некоторых местах, обычно эта проблема на клиенте. Например, на клиенте в store где state еще нет свойства window.$nuxt, нельзя обратится к плагину универсальных куков cookie-universal-nuxt и взять из куков значение и записать в state, а по другому к контексту nuxt не обратится. Store тяжело получить в самом store, порой это нужно.

4) Когда с ним использовал TypeScript, то иногда nuxt выдавал что типа (обычно интерфейса) не существует или другие ошибки типов, но этих ошибок на самом деле не было. Единственный выход — заново запускать nuxt dev и долго ждать, порой эта проблема возникала по несколько раз в течении 20 минут, приходилось перезапускать несколько раз.

В моем блоге мне почти всегда нужно было Dependecy Injection чтобы внедрять разные модули, но они были не доступны в `asyncData`, там нет this, пришлось получать прямо из контейнера. Пример кода:

const CategoryRepository = serviceContainer.get<CategoryRepositoryInterface>(TYPES.CategoryRepositoryInterface)

Взят от сюда.

Вообще вместе с vue-class-component нельзя использовать конструктор чтобы внедрять там зависимости, я использовал inversify для DI, но чтобы оно работало vue-class-component пришлось использовать костыль с vue-inversify-decorator (костыльный способ от разработчиков vue-class-component исправить эту проблему), писать `@Provide(container)` в layouts/default.vue (лучшего места не нашел к сожалениию, это тоже минус). Как было бы удобно если внедрил зависимости в конструктор и они сразу есть во всем компоненте и в `asyncData`.

Хочу изучить next (react) чтобы было с чем сравнить.

Во-первых, событие должно быть input, а не change. Во-вторых, нативные события, и события, которые генерирует jquery (на них vue, очевидно, плевать) - это не одно и то же. Так что

$('#dateStart').trigger('change');

следует заменить на что-то вроде

this.dispatchEvent(new Event('input'));

UPD. Пара примеров того, как это может выглядеть:

раз - с использованием jquery-ui datepicker
два - с использованием air-datepicker.

var moment = moment();
Проблема в этом. В момент когда вы пишете var moment - глобальная переменная в этом контексте забывается и появляется локальная. Соответсвенно, когда вы делаете = moment() - он обращается не к глобальной переменной, которую создала библиотека, а к локальной, которую вы создали только что

Просто уберите эту строку и всё должно работать:
var moment = moment();

Как вариант можно сделать общую таблицу transport, содержащую поле name для всех видов транспорта. А ваши таблицы подключать к общей через join по необходимости.

В этом случае поиск будет намного быстрее и проще. И только по одной таблице.

Нагрузка будет зависит от алгоритмов и ПО которое вы используете. Так что на счёт нагрузки, как вы заметили, сложно дать однозначный ответ.
Необходимо правильно написать алгоритм для поиска. Желательно хотя бы 3-4 буквы начал искать. Это зависит от ваших потребностей. Так же нужно сделать так, что бы пользователь сначала ввёл нужные данные (буквы), и только с небольшой задержкой начался поиск.
Так же есть специальные модули/движки (называют по разному) для поиска (сфинкс и т.п.) (В этом не шарю). Которые оптимизированы под такие задачи.

однозначных решений нет. есть:
- делегирование: сервисы типа algolia. в минусах - платность, хотя при определенных условиях может быть и бесплатно.
- горячий кэш на быстрых хранилищах. в минусах - необходимость определения что чаще ищут, хотя иногда можно и чуть ли не все туда воткнуть.
- обычный поиск.

в реальности: 50-100 человек отправляющих одновременно запросы - не проблема для любого современного сервера. конечно, если код не писали распоследние слоупоки.

На виртуальном диске virtualbox и лежит - файлы виртуалки бэкапь и все.

Если конечно диск не сделал в отдельную папку.
Там от силы гигов 6 будет или еще меньше

Эластик это не база данных и таблиц там нет. Ну так, чтобы вы совсем в шок впали

Проблема в том, что внутри function своя область видимости и this внутри этой функции - это не тот же самый this, который выше.
Замените

.then(function (res) {
    this.enable = true;
})

на

.then(res => {
    this.enable = true;
})

Ну так ведь выборка из комментов знать не знает ничего про модель юзерс.

Стройте отношения между моделями и делайте выборку через with() или просто ленивой загрузкой.

Этот джоин тут совершенно не нужен в сыром виде.

Пробовал указать и a.href и a.getAttribute('href') и т.д.

Лучше бы попробовали документацию почитать.

@click.prevent="toPage"

toPage(e) {
  console.log(e.target.href)
}

Любой Cat5+.

Чтобы работало долго и выдерживало деформации - не берите омедненный алюмин. Чтобы работало быстро - берите восьмижильный. Остальные параметры, типа сечения жил на таком расстоянии особой роли не играют, намного важнее качественно обжать. Про категории можно в википедии почитать.

1) Если задача первого роутера только раздавать инет, то да, абсолютно любой, даже 4 жильный . Это если вам хочется 1гбитс скорости между роутерами, то там иначе думаьт надо.
2) Если не требуется особого хранения - влажность, вывод на улицу и подобного, то выбирайте любой.
3) если кабель будет лежать тупо по полу, и до него домогаться будет кот, то он перегрызет даже очень плотный кабель. Другое дело, что если вам часто надо будет делать передвижения кабеля, то лучше брать в лучшей оплетке и качества, так как самые дешевые, которыми пользуются инет провайдеры - ломаются на раз два при легком изгибе.

p.s. в годах так 2000-2006 локальные сети районные делали на витых парах, какие попадутся. И ничего, все работало. Сейчас то нет проблем вообще купить кабель. Так что покупайте тот, на который денег хватает. Я для дома себе 100м купил хорошего, порезал на все хотелки, которые хотел, еще и до соседа провел (~40-50 метров через подъезд).
ps2 И кабель можно найти дешевый на авито у вас в городе. Его там полно и дешевле чем в магазинах.