это называет router on a stick — клиентские пк имеют default gw ваш шлюз, а дальше он рутит траффик на модем.
модем и один из адресов шлюза должны быть в другой подсети, нежели клиентские ПК, иначе рутинг на модеме будет нетривиальный
плюс к описанному шлюз имеет, например, 192.168.0.2 и на него рутиться сеть 192.168.1.0/24 на модеме
vlan, как и количество сетевых карт, тут ни при чем — это уровенем ниже. Если хочется разделить траффик до шлюза и от шлюза до модема, то можно использовать либо vlan-ы либо 2 карты, но это не обязательно.
да и NAT таки на модеме, либо между шлюзом и модемом надо гонять уже белые адреса.
Это уже снято с производства, и новые серии намного лучше работают. www.ubnt.com/airmax
и можно купить дешевле чем на этом сайте. по крайней мере нанобриджи за 100$ находятся легко
Гайд действительно древний и более того на саляру или сан-ос был — не помню уже. Но в принципе, если дамп и своп девайс один, то до сих пор верный.
Но повторяю, между выделить 64гиг для свопа и разбираться надо ли именно 64 гига или можно 32 или 48 или по какой-то другой хитрой формуле, я выбираю первое, потому что времени жалко, а диска у меня обычно дофига.
Фиг знает зачем вам комп — может вы только пасьянс на нем и раскладываете. У меня на тачках 16-32Г и своп время от времени пользуется.
мне не влом будет почистить диск, а важное я все равно в репозиториях держу, собственно десктоп я могу в любой момент форматануть без ущерба для себя. делать же своп меньше размера памяти — верный путь получить проблему на ровном месте, собственно не вижу смысла мелочиться и тратить на эту «проблему» время большее чем пару секунд — сказано было еще в каком-то древнем гайде «2 рамы» — значить «2 рамы».
jsplumb.org/jquery/demo.html
и что мне нравиться — оно простое текстовое, при этом вполне интерактивное, плюс JS оставляет поле для расширения функционала
ну и зачем вам вся таблица?
вы хотите отправить единомоментно 250к писем? или хотите передать список во внешний сервис?
в первом случае вам надо использовать постраничный вывод таблицы ( вместе с именами ) через limit — mysql не oracle, он сразу грузит данные в память, справедливо считая что либо памяти достаточно либо админ/программер умнее его.
во втором сделать view и экспортировать его сразу в файл
Мадженто как раз для больших магазинов с большим количеством позиций и нацелена.
Да жрет много и лучше сразу VPS ставить, но встроенное кэширование позволяет стабильно держать нагрузку при увеличении количества товаров и запросов
Да кастомизация геморрой еще тот и надо либо искать спеца либо потратить время на изучение, но правильная кастомизация не ломает движек и не создает проблем с нагрузкой
Но ничего лучше для больших магазинов нету.
Известные мне «кадровики» в мелких конторах сложно отнести к проффесиональным кадровикам.
Известные мне хорошие кадровики очень быстро делают карьеру и предпочитают крупные конторы ( не кадровые агентства ) и я их понимаю.
странная позиция.
если HR ищет специалиста в написании резюме я бы ее понял, а так похоже просто ленятся выяснить реальный уровень соискателя. И по тому контингенту, который присылает кадровое агентство, я бы сказал что вообще работать не умеют. по крайней мере не оправдывают ожиданий.
и да, умение писать отчет можно поднатаскать за очень короткое время, а вот грамотный технический специалист на дороге не валяется и вполне может написать отвратительное резюме. И даже лучше, для работодателя, если он не умеет писать резюме и работает на своем месте :) Я бы лично таких специально искал :)))))
отдельные, в смысле альтернативные, css это хорошо ( к стати их можно сразу включить в head и переклацывать их атрибуты, а не менять ссылку как в приведенном примере ), но с ними проблемы — не закешируешь толком, слияние с основной не сделаешь и вообще
Я пришел в конце концов к изменению определенного класса для body и в альтернативных стилях просто приписывать body.your-style перед правилом.
Сам свитчер при этом при этом простой — список div для каждого стиля и небольшой js что бы поставить в body нужный класс. И чуток работы с куками
Мгновенная сортировка делается только при индексации. Скорее всего хром этим и занимался при импорте.
Индексы имеет смысл тогда, когда они используются. Если пользователи хотят сортировать по полю — там должен быть индекс.
Вообще идея ворочить данные на клиенте, когда их больше 1к — имхо мертворожденная.
К стати если данные меняются медленно то хорошо работает кеширование — ставим ключи сортировки и прочего в урл и кешируем в nginx
Оракл так тоже сработает, остальные не в курсе, но по идее должны, если есть уникальные индексы и ignore для update.
Но по опыту нальзя строить совместимый с насколькими базами движек не абстрагируясь на уровень выше SQL запросов. Например в mysql при вставке всегда можно получить id для autoindex поля, а в оракл надо дополнять запрос хитрой конструкцией, или в mysql есть limit, а оракл имеет rownum и так далее. Сделать запрос совместимым очень сложно если это не простой select даже join уже будет по разному выглядеть и всегда по разному работать.
тут просто много вариантов, в зависимости от того насколько критичен авторизованный доступ от клиентов. Если ни на что не влияет — можно завести новую пару и пропускать, если наоборот за этим стоят деньги, то блокировать токен совсем. В любом случае можно письмо кинуть что появиласть новая неавторизованная пара.
Разбираться надо, поскольку это может быть просто смена адреса у клиента. Могут быть совсем экзотичные вещи типа несколько адресов на сервере и падение одного из аплинков.
Когда запросы сложные то активно используются алиасы для таблиц и зачастую они короткие типа u1, pm2, хотя с любыми таблицами линковка a1.some_id=b2.some_id понятнее и менее ошибочна чем some1.id=b2.some_id
Вот прямо сейчас у меня 2 базы под примерно одинаковые задачи и, понятно что, имеющие похожие структуры. Я работаю с обеими паралельно. И составлять запросы в ту что имеет полное имя для поля намного проще и понятнее.
А в обьектах у меня тоже самое userId ( или user_id если не верблюд :) ), отчасти потому что обьекты формируются по записи в базе, но что важнее, имя поля должно однозначно говорить что там есть. Так, к стати, проще в случае усложнения сущностей — я могу просто скинуть все поля user в post и знаю что все потом в базу ляжет как надо по именам.
Безликие id, i и n я допускаю только там где они действительно не важны. В базе это только неиспользуемое поле автоинкремента id или timestamp, используемый исключительно в триггерах.
>раз нос тор он него
этонечто!