Wott

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

Если начальство никак не оплачивает и не компенсирует ожидания во внерабочее время — это просто жлобство, а точнее попытка украсть время у работника, потому что взять и не оплатить это и есть кража. Аргумент типа «он же ничего не делает», то в ответ надо просто выключать телефон — неоплаченное, а следовательно личное время — как хочу так и провожу. Охранники тоже большую часть времени ничего не делают, так же дежурные в МЧС и так далее, но если работа требует дежурства — следовательно все время ожидания это рабочее время.

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

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

То есть единственного правильного ответа на заданный вопрос нет.
кг/ам в чистом виде.

ЯП в данной задаче суть третьестепенная задача после разбора html и поиска ключевых элементов.
Поскольку именно последняя задача самая главная, то и ориентироваться надо на нее — обычно кучка регулярок и некий контроллер для отработки вариаций и исключений, поскольку регулярки не идеальный инструмент для этого случая.

Я писал похожую систему для книжного агрегатора на php, но только лишь потому что WP.

Раз решили пострелять — то примите тот факт что
1. мышка — расходный материал. Ломается все и браки есть у всех. Я перещупал кучу разных в свое время и «мышка» за 100$ — это еще фигня. Да статистика это когда штук 50, а две-три — это везет/невезет.
2. вам придется перепробывать много мышек что бы найти ту самую, которая и по руке и живучая, но через 2-3 года ее снимут с производства и все начнется заново. Самое сложное — «по руке» — у каждого свои особенности и если для обычного программиста или офисного работника разница не заметна, то накликать себе боли в руке на не своей мышке — легко, зато подходящая для руки мышка позволяет забыть боли в руке как страшный сон. Но заранее сказать можно лишь приблизительно — большой лапе — большой грызун и наоборот.

Раньше я предпочитал логитек, но они последовательно сняли с производства кучу подходящих мышек, а прочие как-то не выдерживают конкуренции. Последнее время я предпочитаю a4 — живут они безусловно меньше, зато доступны и дешевы, можно сразу по 3-5 штук брать.

Берете и ставите себе тот же апач и нагиос и кактус и заббикс и что там еще бывает и конфигурируете. Пропишите сайт ( вместо bind можно hosts пока что пользовать ), поставьте на него cms любую, нагрузите его ab и посмотрите статистику. Возьмите с домашнего роутера статистику по snmp. И так далее — практика лучший учитель.

Это зависит от. Например сейчас у нас UI для asteriska для своих и там % и _ вовсю пользуются, а вот для публичного сервиса лучше не стоит, иначе непонятной квалификации пользователь получит непонятную для него ситуацию если вдруг тот же % всплывет в данных.

Есть классическая книга Фридла, немножко нудная, в несколько старых реалиях, но даже тупого научит
Знаний для старта в принципе достаточно в статье на вики, а научиться писать и тем более понимать регулярки можно только с опытом.

Ну и мое, чуть более развернутое, мнение можно найти в статьях на хабре.

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

Потом надо считать сколько надо места на диске и хватит ли сети.
Видео всегда жмется, и можно спокойно SD ужать в 1Mb/с канал, но качество будет дерьмовым, лучше канал иметь 3-4 Мб. HD жмется от 3 до 12 Мб/с опять же смотря какая картинка и разрешение. На диске места занимать будет сильно меньше, потому что большая часть времени картинка не меняется ( пустой коридор например ) но заранее предсказать сложно, бывает что 1Тб хватает на несколько HD камер в день, а иногда одна SD легко забивает за сутки.

firewall, где по дефолоту все форвардится на http сервер, а тем кто прошел «авторизацию» на этом сервере создается правило для свободного выхода наружу, которое убивается при истечении времени аренды адреса.

О, чувствуется вам очень нравятся «волшебные правила», а вникать в суть желания немного. Тямы не хватает?

Регулярки — инструмент со вполне определенным кругом задач.
Технический долг — методика ускорения ближайших фаз проекта, за счет последующих.
Это абсолютно разные вещи.
Примерно также как «увлечение русским языком увеличивает долю ненормативной лексики в устной речи»
или «регистрация на хабре/вк/steam ухудшает производительность»
или тоньше «курение сокращает продолжительность жизни» :)

железо в zabbix — там есть инвентаризация, помимо хостов, сервисов, но на самом деле в mysql
пользователи в mysql, а оттуда в dhcp и dns попадают

чисто технически:
делать тестовые звонки — плохая идея.
проще на номер ( я правильно понимаю что он групповой? ) поставить перенаправление при неответе или по таймеру включать какой-то дополнительный ext на котором уже будет вестись статистика, а лучше сидеть начальник или вроде того…

zapret-info.gov.ru/?

не стоит использовать сленг, которым вы не владеете — можете попасть в очень пикантную ситуацию :)

Правильно указывать lang в качестве свойства тега html:

<html lang="ru">

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

для пользователя имхо надо бы смотреть на его Accept-Language и подбирать из имеющихся альтернатив, если это внешняя ссылка и давать возможность менять, запоминая в куках. Урл менять как-то не хорошо, хотя полезно иметь жесткий модификатор в урле типа ?lang=ru, но не использоваться его.

Сейчас легко можно собрать малошумящий сервер — проц с низким TDI, мать под него и качественный кулер в 10-ку уложатся имхо.

правильно выдавать таки страницу, но при этом иметь в тексте link rel='canonical' с правильным урлом.
Как вариант выдавать 301-ую но это как-то старомодно.

гугл и прочие поисковики пробуют любой урл, который найдется на самом сайте или на любом другом.

слепая печать, приходиться набирать ОЧЕНЬ много текста, стирать и снова набирать
арифметика, часто приходиться считать +1-1+1-1, редко больше
хорошая память — переменные, вызовы — все что написал надо помнить
тренированная задница и мочевой пузырь — часа два-три сидеть на одном месте, полностью отвлекаясь от материального, чревато

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