DyadyaBob, это может говорить и о качестве собеседующих.
Я лично не программист, а админ, и у нас такие вопросы зададут, что такие вот с курсами никогда не пройдут. Смешно, но куча народу валится на простейшем вопросе "как работает DNS?"
Можно выучить ответы на некоторые вопросы, но имитировать больщой объём знаний и опыта намного сложнее.
Василий Банников, в частных случаях можно вообще много чего использовать. Например, капсом могут писаться названия и надписи, а в ass/ssa могут быть стили и имена персонажей.
kamik111, потенциально можно также учитывать время фраз, например, если между двумя фразами проходит минута тишины, то вряд ли их надо склеивать, даже если там не было точки.
У такой задачи не может быть лёгкого универсального решения. Очень сильно зависит от структуры данных и потребностей пользователей.
На моих глазах была подобная система, которая начиналась как база основных сведений и система рассылок подведомственным организациям, потом там сделали возможность делать "анкеты" из набора кастомных типизированных полей для сбора данных. Постепенно всё это вылилось в целую систему хранения и обработки данных: анкеты могли быть привязаны к организациям, к зданиям, к сотрудникам (и ещё некоторым сущностям), в них можно было использовать специальные макросы в качестве дефолтных значений (в том числе макросы позволяли вытягивать значения предыдущих анкет). Можно было в рассылаемых письмах и в прикладываемых файлах (шаблонах) использовать макросы. И, наконец, там был генератор отчётов, в котором можно было подгружать основные справочники (организации, здания, люди) и линковать к ним данные из анкет. Всё это дело было написано на ZF2+extjs. После загрузки и фильтраци данных результат можно было сохранять в файл.
Базовые справочники были самостоятельными таблицами, а анкеты же, конечно, нет. Но для той системы подобное было приемлемо.
Ruslan Website, это не "сервисы", любые такие подборки делаются вручную, и непонятно, почему кто-то будет делать вручную подборки по совершенно никому не интересным катагориям типа "сайт бюро переводов".
Именно что субъективно. Потому что вскусы у всех разные. Для меня практически любой сайт с анимацией - это говно. Анимация тратит моё время. И мешает мне получать информацию быстро и эффективно.
Хороший сайт прежде всего должен прям сразу давать понимание, что где тут лежит и как получить необходимую информацию. Сейчас модно делать сайт из одной почти бесконечной страницы, которая подгружается по мере прокрутки или тыкания на какие-то области экрана. И непонятно: то ли крутить страницу, то ли тыкать, сколько времени это займёт и вообще нужно ли мне во всём этом копаться в попытках понять, что тут где и есть ли мне нужное.
И это именно что говно, которое восторг вызывает только у людей, которые совершенно не ценят своё время, потому что их время практически ничего не стоит в силу их ограниченности.
Все эти "сайты бюро переводов" именно такое говно и есть. Куча воды (чтобы накрутить лапшу на уши поисковикам ради SEO), запутанный дизайн, полное отсутствие внятной структуры и куча потраченного времени.
888vld, программирование - это умение из простых кирпичиков составить решение задачи. Например, получить все файлы в каталоге можно с помощью os.walk или glob, создать архив с заданными файлами можно с помощью модуля zipfile, ну а уж как использовать циклы в любом учебнике написано.
В общем случае нет, но иногда внутри моноблока реально barebone, подключенный через HDMI к "монитору", и можно попытать вставить между ними KVM. Но это идея так себе, проще купить отдельно barebone, монитор и KVM.
Аналитика - слишком общее понятие. И тут важнее всего знать целевую предметную область. Аналитика в экономике требует познаний в экономике, в изучении эпидемий - в медицине - итд итп.
Alexey Dmitriev, протокол ARP кидает bcast по ff:ff:ff:ff:ff:ff на L2 и ему никакие маски не нужны. Можно даже эксперимент поставить - всё будет работать. А при наличии proxyarp на шлюзе может даже в некоторых сценариях заработать и в разных подсетях (но это категорически ненормально и может вызывать глюки).
Алексей Арх, так 823 и есть уникальный идентификатор сервера, это его инвентарник.
Переименовываются сервера редко. По сути, речь идёт о том, что сервер начинает совсем новую жизнь. В нём могут перебрать диски и память, поменять сетевухи... И перезаливают систему.
Что бы найти решение, близкое к идеальному.
Не совсем. Скорее мы отказались от идей, которые оказались бесполезными и неудобными, а также вернули вещи, которые применялись при старой концепции. Но, наверное, проще рассказать, как примерно это происходило, чтобы было понятнее.
На заре существования фирмы - когда оба её основателя лично программировали и админили всё это, серверов было мало и все они назывались короткими трёхбуквенными звучными именами типа tax, dix или sox. Приложения запускались прямо на этих серверах. Позже на серверах поднимались зоны Solaris с именами вида zcnrXX, zchlXX, zmngXX для коннекторов, каналов, менеджеров итд итп. Зоне при этом присваивался хостнейм вида zcnr06-dix или zchl05-tax, котороый отражал её расположение. При переезде зоны менялся хостнейм. В DNS этих имён с дефисами не было. Когда появились новые проекты, просто в имена зон добавлялись ключевые слова, например, zavicnrXX для коннекторов платформы avi, zpushrotXX для роутеров платформы push... Особых проблем с поддержанием всего этого хозяйства не было в силу не очень большого количества серверов и зон, а также из-за того, что админил всё это один человек, которому несложно было поддерживать в этом порядок.
При переезде на Linux от использования зон отказались. Во-первых, потому что в Linux сложнее с изкоробочным инструментарием для этого, во-вторых, потому что было принято важное решение не смешивать разные платформы на одних и тех же серверах. Также всерьёз думали над полным переводом на докер или мезос. У нас в какой-то момент было бурное двухчасовое обсуждение того, как всё же именовать сервера, и договорились до именования PXXXXD, где P - однобуквенный символ платформы (a - avi, p - push итд), XXXX - инвентарник, D - однобуквенный символ датацентра (например, k - KIAE). Все остальные варианты - алиасы в DNS. Первый админ фирмы почему-то очень не хотел цифр в именах и придумал остроумную схему именования на аббревиатурах, где каждой цифре соответствует буква, например 5 - p ("пять"), 9 - n ("найн", потому что d уже занята цифрой "два"). Поэтому у нас и были какое-то время сделанные им всякие странные алиасы типа pnp CNAME s0595k (поддерживал он их, впрочем, недолго). Сразу же стали делать алиасы без буквы датацентра (s0595 CNAME s0595k) и в целом буква датацентра оказалась никому не нужна, поэтому указывать её быстро забросили. На этом история формирования основного имени железных серверов закончилась. Предлагали ещё что-нибудь писать в TXT, но это не особо пошло, хотя у некоторых имён это применяется иногда (например, у виртуалок часто есть TXT со ссылкой на тикет, по которой её завели, чтобы в случае чего хотя бы примерно понять, куда искать, даже если на эту виртуалку нет логина и понимания как посмотреть её назначение).
Но я уже сказал, что был и процесс возвращения к истокам. Началось всё с того, что для платформы push сделали имена вида pushsrv00 CNAME p0882, причём в реальном употреблении внутри платформы были именно имена pushsrvXX (сами приложения при этом запускались докере, имена использовались только для указания места деплоя). После того как админу, который был главный ответственный за эту платформу, надоело в очередной раз вспоминать, что на сервере p0882 на самом деле pushsrv00, он вспомнил про концепцию времён Solaris и переименовал все свои сервера в вид pushsrv00-p0882.
Для некоторых других платформ позже сделали то же самое. Правда, там есть нюанс: имя XXXsrvXX было не CNAME, а адресом в другом VLAN, на котором работают эти платформы (там нет docker и приложения работают непосредственно на серверах, но по этим сервисным именам внутри кластера). Начальник в какой-то момент высказал этим недовольство и попытался потребовать сделать их CNAME на железные адреса серверов, но войско взбунтовалось^W^W админы возмутились и сказали, что нужно тогда ещё третий вид имён для сервисных, но смысла мало, так как вместо смотреть в DNS можно просто зайти на сервер и узнать его инвентарник, а если кому-то уж прям невероятно надо через DNS - пусть напряжётся и заполняет TXT-записи (что никто так и не сделал, и вопрос исчерпался).
В итоге достигли консенсуса, по сути не внося никаких существенных изменений. И что очень важно - целый ряд инициатив "как сделать лучше" просто на старте никак не прижились, так как оказались не такими нужными, как это казалось.
ambisinister One, стандарт - это не про то, что существует само по себе. Стандарт - это про соглашения. Скажем, болт и гайка объективно могут иметь какие угодно диаметры, шаг и направление резьбы, но чтобы их использовать как заменяемиые и унифицированные объекты, они должны иметь определённые согласованные параметры со специально оговоренными допусками на отступление от их конкретных значений. Чисто физически же их параметры могут быть какими угодно. Но для того, чтобы их существование и использование было бы полезно, нужно, чтобы был стандарт на их изготовление.
До кучи очень полезно смотреть историю команд, в том числе у других пользователей.