Сергей

Поместив HTML, XML, SVG и т.д. и т.п. файл на домене usercontent.google.com можно
манипулировать куками домена google.com и фишить. Поэтому пользовательский контент всегда отдается с отдельных sandbox-доменов.
Так же с отдельных доменов обычно отдается статический контент, это позволяет использовать CDN и упрощает управление кэшированием.
Отдельный домен обычно используется для PTR-записей (например 1e100.net). Для PTR часто нужна двойная валидация, т.е. PTR должна разрешаться в имя и имя обратно в тот же IP. При этом на одном IP может хоститься много доменов и быть установлено много сертификатов, включая вайлдкарды. И наоборот, один домен может хоститься на многих IP. Чтобы исключить прямое обращение к хосту по "неожиданному" для него имени в своем домене, обычно используются PTR записи в нейтральном домене. Кстати исторически принято использовать именно домены в .net. Google так же использует 1e100.net как нейтральный домен для подписи транзитных писем, раньше для этого использовался собственно домен google.com и это приводило к забавному багу, позволявшему подделывать подписи на письмах от google.com, я рассказывал о нем на PHDays 2014.
Географические домены исторически используют для организации региональных датацентов и ускорения доступа, например yahoo.jp физически расположен в Японии.

Таблица принятия решений (таблица решений) - очень эффективное решение для такого рода задач.
Из русской Википедии:

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

На английском - Decision table - можно найти гораздо больше полезного материала, чем на русском. Допустим, это видео с объяснением.
Таблицы можно хранить в СУБД и обмениваться при помощи CSV.
IBM и многие другие компании применяют их в разных своих продуктах. Особенно полезны для описания деятельности бухгалтерии, складского учета и пр.

знаете 1000 слов - покрываете 80% повседневных потребностей
знаете 5000 слов - покрываете 95%
Кроме того, есть закон Ципфа, согласно которому 2-е распространённое слово встречается в 2 раза реже, чем первое, 3-е - в 3 раза, 100-е - в 100 раз реже, и т. д.
То есть, вопрос не в том, что вы знаете N слов, а в том, какие именно это слова. Первую 1000 (см. ссылку, которую я дал) можно выучить примерно за неделю, если поставить перед собой такую цель.
Изучить хотя бы базовую грамматику (9 основных времён) - ещё неделя.
И так, за пару недель можно в принципе научиться понимать 80% английских неспециализированных текстов.

Для более глубокого изучения, советую читать. И читать не stackoverflow, а художественную литературу на английском (хоть того же Гарри Поттера, впрочем, это дело вкуса). При этом лезть в словарь не нужно. Просто читайте и старайтесь угадать, что то или иное слово означает (без словаря). Не задерживайтесь долго. Если предложение не понятно, постарайтесь хотя бы уловить общий смысл абзаца и пр. Опять же, словарь не трогайте.
Для фонетики смотрите фильмы на английском и с английскими же субтитрами (без перевода). Желательно незнакомые фильмы, чтобы "перевод" из памяти вас не смущал. Старайтесь улавливать, о чём говорят и оттачивайте навыки восприятия языка на слух (читая субтитры). В общем, это уже отдельная тема.
Начните с первой тысячи слов и основ грамматики.

При повторной потере мотивации алгоритм следующий:
1) Идем высыпаемся. По-нормальному так, без будильников. Чтоб глаза вообще больше не закрывались.
2) Если мотивация не вернулась (возвращается в 70% случаев) - берем велик (хотя можно и пешком) - и на улицу. Если есть приличный парк в городе - находим пару нестандартных физ. упражнений (можно боевых), пытаемся выполнить. Работа с телом и физические нагрузки - это совершенно другая часть вашего сознания, про нее нужно не забывать.
3) Если мотивация не вернулась (уже где-то 85% случаев) - берем случайную книгу (не техническую), в идеале - из жанра который вам нравится. Читаем. Спокойно, страницы не считаем.
4) Если не вернулась, повторить с п. 1 до пяти раз, не думая о времени и выполняя только самые важные дела (срочные задачи по учебе, работа, если есть), можно даже попросить родных/знакомых помочь по дому и бытовым делам, чтобы себя разгрузить.
5) Если не помогло после 5 раз, задаем новый вопрос на тостере, подробно описываем что делали).

Хотя бы один из п. 1-3 выполняем для профилактики каждый выходной.
P.S. в принципе плохо сравнивать себя с кем-то - для "сравнения" на свете есть всякие соревнования и состязания, где есть правила и контекст. В жизни правил нет, один учится в MIT, другой учится в колледже в России - какие могут быть сравнения? Вы думаете тут большинство людей за один год все узнало и всего добилось? Вы глубоко заблуждаетесь) PHP-шники-выскочки не в счет, у них искаженное представление о реальности.

Я расскажу Вам про личный опыт, без претензий на истину в последней инстанции...

Для чего идеальна MongoDb? Примеры приложений, где монга будет лучше mysql?

Для человека который привык работать с реляционными БД, смириться с логикой и вообще с подобными БД - довольно сложно. Для тех, кто работает с реляционными БД профессионально - сделать это ещё сложнее...

Если сравнивать с реляционными БД и с оглядкой на конкретно MySQL - монга идеально вписывается там, где структура данных заранее неизвестна. Тут я хотел привести пример, но не смог придумать ни одного дельного примера, после того как начал плотно работать с PostgreSQL... Давайте попробую из практики. Мы один раз применяли монгу в проекте где есть десятки и сотни тысяч товарных позиций и у каждой из них свой уникальный набор различных свойств. На основе уже имеющихся свойств, "соседних" товаров, контентщику предлагался наиболее вероятный набор параметров, которые нужно заполнить, но в любой момент он мог удалить или добавить любое поле и/или множество значений одного из них, например, "Цвет: черный, серый, фиолетовый". Всё это дело попадало под разные динамические фильтры и далее по цепочке... В то время, насколько я помню ещё не было поддержки JSONB-формата у PostgreSQL, по этому мы остановились на MongoDB. Ну и конечно же, желание "воткнуть ультра новую и модную БД в проект" сыграло свою роль...

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

Безусловно, не редко можно встретить проекты в которых даже в реляционных БД не прописаны, например, внешние ключи и контроля целостности данных как такового нет, но обычно это происходит по следующим причинам:
1. Очень низкая квалификация администратора БД проекта
2. В попытке выжать из базы больше производительности, не найдя других методов оптимизации
3. Данных настолько много, что БД/ключи - начинают "сыпаться", не редко это связано с п.1

Так же, последние тесты показывают, что PostgreSQL почти не уступает MongoDB даже в её родной среде (на уровне данных в формате JSON). А в некоторых аспектах даже превосходит её... Подробности Вы можете увидеть на некоторых конференциях по Postgres (да, на конференциях по MongoDB, Вы вряд ли увидите, как кто-то будет рассказывать, что [их любимая] монга "хуже" некоторых других движков...). Кстати, поддержку формата JSON стандартизировали (наконец-то) на уровне SQL-стандарта (если я не ошибаюсь) и в самом ближайшем будущем, думаю стоит ожидать полноценную поддержку оного в SQL-базах, в т.ч. поддержку в бинарном виде с возможностью индексации данных (кстати, некоторые SQL-базы уже такое умеют).

Моё понимание, ответа на вопрос, "когда действительно стоит использовать MogoDB?" звучит примерно так: Исключительно в тех случаях, когда Вы понимаете, что она станет действительно хорошим решением для поставленной задачи и сейчас и в будущем. В моей практике, таких проектов можно было бы насчитать ничтожно мало, а точнее около нуля, особенно с учётом развития некоторых современных SQL-БД и вообще направления "JSON в SQL" в целом. Но, безусловно такие проекты могут быть и есть (в данном случае, не у меня). Но, тут стоит обратить внимание на крайне важный факт - когда всплывает такой проект, что бы адекватно оценить наиболее оптимальную БД под него - нужно знать как минимум пару-тройку SQL-БД, со всеми их особенностями, достоинствами и недостатками... причем не просто "знать", а хорошо знать, "изнутри". А так же знать все характерные черты монги, а так же её особенности, достоинства и т.д. То есть, если Вы задаётесь вопросом, "а хорошо ли впишется монга в проект N?" и не можете найти на него однозначного ответа, вероятнее всего, что в долгосрочной перспективе, в "проект N" она впишется плохо.

P.S. В заключение, хочу ещё раз напомнить, что "JSON в SQL" - активно развивается... Со всеми вытекающими.

методично, всерьёз и надолго погрузиться в тему

Погружайся)) Методичнее некуда)

А всё, сам нашёл. На тостере в похожих вопросах вывелось - nodesquad.blogspot.ru/2013/04/blog-post.html

В параметрах mstsc нельзя задать имя пользователя и пароль. Либо он должен быть уже сохранен, либо он будет запрошен в графическом интерфейсе.
Если принципиально все делать из ком.строки, то сохранить пароль можно утилитой cmdkey, после чего mstsc автоматически подхватит этот логин/пароль. Этой же утилитой сохраненный логин можно и удалить. Просмотреть сохраненные учетные данные можно в "диспетчере учетных данных".
Если на клиентском компьютере работают несколько пользователей и всем нужен доступ к терминальному серверу, то сохранять учетные данные надо для каждого локального пользователя отдельно.

уникальный текст лень писать, поэтому источник
https://www.iphones.ru/iNotes/464190
или гугл:
"Установка Linux на Mac"
///
***железо Mac здесь непричем совершенно.***

Решение очень простое, если кто-то думает что это сложно, Вы не правы.
попробуйте.

После выполнения нижеуказанных действий никаких манипуляций с режимом legacy не нужно. ВООБЩЕ. Забудьте о нем.
Нужно только включить загрузку с external drive и железо увидит вашу флешку и начнет установку ОС.

Нужен Mac os, можно через virtualbox.(тоже легко)

открываем ссылку и выполняем пункты номер 3 и 4.
Только их.

3. Откройте утилиту Терминал. Наша задача – конвертировать скачанный образ ISO в общепринятый в среде Mac IMG/DMG. Для этого нам потребуется запустить выполнение несложной команды.
hdiutil convert -format UDRW -o ~/path/to/target.img ~/path/to/ubuntu.iso
дальше см. ссылку....

4. Разворачиваем установочный образ на флешку. После выполнения вышеуказанной команды в папке Загрузки появился новый файл LinuxInstall.img.dmg. Наша задача – развернуть его на флешку. Убедитесь, что USB-накопитель подключен к Mac и в Терминале введите следующую команду:
diskutil list
дальше см. ссылку....

///
после вы будете удивлены тем, что железо увидело флешку)
лично я, был просто ошарашен когда переустанавливая oracle linux на imac решил "ради развлечения" попробовать вставить загрузочную флешку с линуксом в vaio без legacy.
ошарашен, что установка с флешки загрузилась.

netstat -na | findstr ^:443 ;)

netsh advfirewall firewall add rule name="Block IP" dir=in interface=any action=block remoteip=192.168.1.123/32

Пробел. И не только в веб-формах, а и в самой винде. И некоторые выделенные кнопки им активируются.

Было. Если кратко, один влан - отдельный широковещательный домен. Много подсетей в одном влане - все равно один широковещательный домен. Нужно понимать, как работает Ethernet и IP.

Вопрос исключительно общий. Начните с изучения самых основ, со способов представления информации и с систем счисления.

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

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

Чтобы понимать значение конкретных байтов, нужно знать контекст, тип файла. В случае файла с данными, их значение описано в спецификации формата хранения. В случае исполняемого файла всё чуть сложнее, потому что архитектура фон Неймана подразумевает хранение в общей памяти и исполняемых команд, и данных. Таким образом, однозначно определить, какой байт является командой процессору, а какой данными, довольно сложно, для этого нужно знать формат исполняемых файлов конкретной операционной системы, по этому формату найти первый байт, который будет исполнен процессором, и по очереди просматривать все байты, следить за ходом выполнения. В простейшей случае команды исполняются одна за другой, но возможны условные переходы. Их все отслеживают и таким образом отделяют данные от команд. Обычно это делается не вручную, а с помощью специальных программ дизассемблеров, которые на выходе дают программу, написанную на языке ассемблер, в котором одна команда соответствует одной операции процессора. По этому коду уже относительно не сложно понять, что делает программа.

Ручное создание бинарных файлов — это исключительно редкая ситуация в наше время. С файлами данных это и так очевидно (существуют редакторы на любой вкус и цвет). С исполняемыми файлами это тоже редко, так как существуют языки программирования высокого уровня, которые похожи на человеческий язык и переводятся в двоичные файлы компиляторами. Только в ряде особых случаев пишут на том самом ассемблере, который очень близок к машинным кодам и даёт возможность программисту практически однозначно определить содержимое итогового исполняемого файла.

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