Василий Банников

Можно. Весь 20-й век почти так делали. База была главной. Эдакая себе царица. Ее любили. Холили.
Приложения были двухзвенки. Оконная апликуха коннектилась к базе и все расчеты
проводились в базе. Апликуха только показывала результаты в гридах и вводила формочки.
Джобы тоже запускались в базе как процедуры на PL/SQL по скедулеру. Для пуска их клиент
был тоже не нужен. Плановые задачи БД запускала самостоятельно. Это и было видение
бизнес логики из 20-го века.

В 21-м веке с развитием веба появился слой middle. И разработчики вынесли в него максимальную
часть логики. Это произошло естественным путем. А базе досталась участь быть просто хранилищем
таблиц. Потому что держать 2 копии логики или поддерживать было уже неудобно. В команде
должен быть тогда разработчик и Java и PL/SQL одновременно. В современной парадигме
разработки с ORM база стала просто чем-то вторичным. И на уровне ORM абстракций
даже заменяемым на другие типы баз.

Но не все так плохо.

Фактически, логика современного приложения размазана по 3м слоям. Даже в браузере
есть какая-то минимальная логика, например при аутентификации или при проверке
валидности емейла. И какая-то логика агрегации (sum/group by) полюбому есть в базе.
Потому что агрегировать в приложении все - глупо. Это лишний трафик.

И нет такого архитектора который говорит "нельзя". Просто есть best-practices современной разработки,
исходя из развитя железа, сетей и вообще рынка всего остального. Кто знает может в мобилах вернуться
к двузвенкам. Смотря под каким углом смотреть на современные мобильные приложения? Who knows.

У каждого из подходов есть свои преимущества и недостатки.
К недостаткам можно отнести:

• Сложность отладки и тестирования
  
• Затрудненная версионность
  
• Зависимость от конкретной СУБД
  
• Ограниченные возможности языка
  
• Сложности с масштабированием
  
• Возможные side-эффекты
  

К преимуществам:

• Уменьшение трафика
  
• Цетрализованная логика
  
• Безопасность данных
  

Копайте в сторону программы записи и настроек звука. Скорее всего софт микширует данные выхода звука и микрофона.


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

я боюсь, что администраторы его забанят.

Увы, в таком случае всего два варианта:

• Собственный физический сервер, доступ к которому имеете только вы;
  
• т.н. абузоустойчивый хостинг;
  

ещё и бесплатно

С чего вы взяли, что компания, которой вы не заплатили ни копейки, хоть немного будет заботиться о сохранности ваших данных?

а код уже перевалил за 200 строк

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

Нормально ли писать программу одним большим файлом?

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

Может посоветуете книгу

Ну, например, прочитайте книгу "Рефакторинг (кода на JavaScript). Улучшение проекта существующего кода". В ней как раз на примере монолитного проекта разбирается как что переделать, чтобы код проекта стал гибким.

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

покупаете домен, и делаете там простейший скрипт который берет адрес, меняет в нем domen.com на disk.yandex.com и делает редирект.

Использование проприетарных персонажей, изображений, сеттинга какой-либо игры в своей разработке требует получения соответствующей лицензии от правообладателя. Монетизация здесь абсолютно не важна.

зарегистрировать юр лицо заграницей и открыть там счет в банке...

Curved монитору может навредить резкий перепад температур, матрицу корпус выдавит, пойдут полоски. Смотрите чтобы на дисплей прямые лучи не падали (если у вас 1000R). Также принтер стоит убрать в недосягаемое до излучателя место, так как повышенная температура может влиять на сопла, настолько всё маленьких размеров, что измеряется в мкм, и если жидкости становятся отличной вязкости, от той что предполагалась на стенде, то вы его просто выбросите. От прямого воздействия, любого излучения, необходимо любую оргтехнику отодвигать, будь то ИК, УФ, неважно. Соблюдать температурный режим, который указан в руководстве. Там это есть, если почитать внимательно, чтобы было не выше и не ниже. Если комуто в коморке, просто "пекло в ухо, и ничего небыло", то это не значит что у него специфическая периферия использовалась. Мониторы лопаются просто на ура изогнутые. Высокая или низкая температура, может повлиять даже не ход свитчей, если у вас механическая клавиатура. Я уже даже молчу про появление конденсата, при резком её перепаде. Клавиатура и т.п. это всё ничего, самое главное ещё беречь носители информации, от любого подобного излучения, особенно где используется много механики, HDD как пример, если в кармане будет стоять на столе воткнутый, то не думаю что это пойдёт ему на пользу в т.ч.. Суть обогревателя ИК ведь в том, что он обогревает помещение предметами не пропускающими ИК излучение, тоесть по сути, вы пытаетесь периферией обогреть помещение, которая для этого не предназначалась.

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

У меня лет шесть висел излучатель UFO на стене, на 1.8кВт, если не ошибаюсь, метрах в трех от компьютера. Работал не постоянно, а только когда батареи не вытягивали. Ухо припекало мне - было дело, что отсаживался от этой штуки подальше. Никаких особых воздействий на пластик я не заметил.

https://pages.github.com/

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

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

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

Причина 1 (расширяемость)
Если в будущем добавлять новые варианты NumberStyles, которые null должны обрабатывать иначе, либо какую-нибудь комбинацию, которая при null возвращает int.MinValue (например), то при проверке на null код сработает неправильно.

Причина 2 (контракт)
На вход всегда должны подаваться правильные данные. Очень странно, если будешь выполнять какую-либо работы с неправильными входными значениями.
Я, например, всегда валидирую данные перед тем как выполнять работу.

Причина 3 (легаси/совместимость)
Может в старых версиях (.NET Framework) было такое поведение - исключение при неправильных данных