Что-то не так. Клиент-серверная архитектура и там и там. Бэкенд можно описать как склонный к rest api/crud и асинхронности. Проблемы по масштабированию, оптимизации алгоритмов после определенных масштабов возникают и там и там. В нетривиальных случаях может наблюдаться необходимость навыков CS. Язык не принципиален, ибо задачи и архитектура похожи. Что касается клиентской части, то в вебе это место занимает js. Это динамический и очень свободный язык, я склонен считать, что написать на нем поддерживаемую архитектуру значительно сложнее, чем на любом статически типизированном и классик-ооп языке. Технологий больше, свободы в связывании html/js больше. Потенциально эта область сложнее. Не надо забывать, что веб рвется в мобильную сферу (titanium sdk, и я даже знаю успешные проекты на нем), у меня нет сомнений, что рано или поздно он займет там свою нишу. Принципиальной разницы здесь нет, всего лишь разные инструменты. Существуют некоторые проблемы с тем, что на мобильных платформах сильно ограничены ресурсы, но это не решающий фактор в перспективе.
Итого я не вижу принципиальной разницы, немного иная идеология и инструменты, но в целом, с научной, так скажем, точки зрения все это одного поля ягоды. И еще раз повторюсь, что динамические языки вроде js/python в долгосрочной перспективе требуют большего внимания к архитектуре, а кроме этого еще и дают колоссальную свободу. Это усложняющий фактор, а не упрощающий.
Мне кажется, корректнее рассуждать так:
1) Количество документации.
2) Степень использования штук из CS.
Чем меньше первый пункт и больше второй, тем сложнее область, тем меньше специалистов. И чем больше человек специалист (исходя из моей классификации), тем больше он специалист автоматически в конкретном инструменте (после его освоения, конечно).
Но да, я люто, крайне люто не люблю, когда говорят так про веб-разработку. Тут низкий входной порог за счет высокого уровня абстракции, НО не более того. Разработка, например, сетевых сервисов/приложений (например, пилить модуль для iptables на сях для внутренних задач) на низком уровне отличается меньшим количеством "человеколюбивой" документации и более низким уровнем разработки, меньшей популярностью, но про нее точно также можно сказать: ха, любой десятиклассник может прочитать доки и все будет круто. Но это не показатель.
В дефиците человек, обладающий комплексными знаниями и хорошими знаниями инструмента, обладающий научным мышлением и, если угодно, чутьем.
Так что не соглашусь. Наверное, мой комментарий можно рассматривать как ответ на топик, хых.
Почему же? Если имеется класс, потенциальный селектор (например, #nav > .item) будет быстрее, чем его бесклассовая версия (#nav > li). Хотя для меню и подобного это некритично. Неиспользование класса сэкономит несколько байт в html, что опять же некритично для меню и подобного. Неиспользование классов также обязывает использование селектора >, потому как в противном случае можно задеть лишние элементы в каких-нибудь иных списках. Делаю вывод, что обращаться по li/div/etc менее красиво, всегда нужны классы.
p.s. Вообще, здесь есть какой-то кривой момент. Например, есть header, на странице их может быть несколько. В итоге появляются конструкции типа <header id="h"></header> или <header class="item-header"></header> и т.п. Не совсем понимаю модный и семантический html. А БЭМ и смежные/похожие идеи красивы, да.
Евгений Петров: Посмотрел также пример по ссылке у вас. jsfiddle.net/e4xo5gy7 - если убрать overflow: hidden, то пропадает новый formatting context, в итоге, несмотря на то, что stacking context новый есть (position: relative и z-index: 1), но все равно размеры родителя ни на что не влияют (потому что контекста по X/Y нет). При этом с таким же успехом будет работать overflow-y: hidden (потому что контекст блочный, как я понимаю).
То есть я к тому, что position: relative; как создает stacking context (который влияет на Z), так и привязывает дочерний позиционированный элемент к себе (то есть определяет containing block). Но без overflow, отличном от visible, это ничего не дает, так как absolute-позицинирование будет находиться в своем formatting context.
Евгений Петров: Floats, absolutely positioned elements, block containers (such as inline-blocks, table-cells, and table-captions) that are not block boxes, and block boxes with 'overflow' other than 'visible' (except when that value has been propagated to the viewport) establish new block formatting contexts for their contents.
Именно про него и говорю. Создается новый formatting context. Без position: relative; у родителя позиция высчитывается относительно root element (в вашем примере). В CSS3 formatting context назвали flow root, что логичнее. И overflow, отличный от visible, создает flow root. Но если дочерний элемент с position: absolute, а у родительского нет position: relative, то для него flow root будет уже другим. overflow отвечает только за те элементы, которые находятся в его formatting context. position: relative может просто привязать новый formatting context к containing block (www.w3.org/TR/CSS21/visudet.html#containing-block-...), а поэтому начинает работать overflow.
Создание контекста по вертикали (stacking context) здесь ни при чем. Просто этот контекст также создается при position: relative и все дочерние элементы попадают в него, но это ось Z, а я говорю про Y. И автор говорит про Y.
Я, конечно, читаю спецификацию CSS21, но посмотрел по ссылке box model css3 - вроде бы расхождений не вижу.
userAlexander то, о чем говорит Евгений, описано тут: www.w3.org/TR/CSS21/visuren.html
Он говорит про контексты "отображения"/форматирования. Тема действительно большая, но если очень коротко: все в CSS есть коробки-прямоугольники (box). Они бывают разных типов (display за это отвечает). В зависимости от типа они образуют инлайновый или блочный контекст отображения/форматирования. По умолчанию, если нет флоатов, абсолютного позиционирования, table-cell и т.п. - это "стандартный поток". Можно представить это как колонку в газете, где блоки друг за другом вертикально. Если же мы создаем новый блочный контекст (а это абслюты, флоаты и т.п.), то у нас другие элементы остаются в "стандартном потоке", а текущий элемент создает новый контекст форматирования (для контента внутри этих блоков). Бывают блоки (containing blocks), относительно которых рассчитываются позиции дочерних блоков. Например, поэтому часто можно увидеть, что у родителя стоит position: relative, чтобы запозиционировать position: absolute; относительно него, потому что это способ задать containing block (www.w3.org/TR/CSS21/visudet.html#containing-block-...). Инлайновые контексты - это такие, где элементы распространяются горизонтально. Но и там есть свои нюансы: например, если применить float к инлайновому элементу (а он был в инлайновом контексте), то он станет блочным (применится width к нему), при этом он будет находиться в новом контексте форматирования, а не в normal flow (jsfiddle.net/q4nLqx0b).
Так вот, если position: relative; - это определяет containing block, то overflow отвечает за отображения контента блока (www.w3.org/TR/CSS21/visufx.html#overflow). Контент - это любые элементы.
Причем overflow-таки формирует контекст, если он отличен от visible, здесь Евгений ошибается Евгений Петров ). Об этом говорит вот этот пример (и также слова в стандарте по ссылке выше): jsfiddle.net/96t6x5n0 Либо я что-то не так понял.
Конечно, это не вся инфа, тема тянет на отдельную статью. Например, Евгений написал про "generated content", один из примеров приведен тут (www.w3.org/TR/CSS21/visuren.html#box-gen): к инлайновому элементу в потоке вместе с блочными лучше относиться тоже как к блочному (в вопросе отображения относительно них), т.к. он, по сути, будет являться анонимным блочным элементом. Но на практике все очень и очень просто, достаточно рассуждать "газетными коробочками" и прочувствовать поведение коробочной модели CSS.
mamkaololosha: я недавно читал порядка 2-3 статей от Яндекса про их сотрудников, у меня сложилось иное мнение про компанию в целом. Кроме того, я также недавно смотрел вакансии. И у них есть не закрытая вакансия как раз менеджера проектов: https://yandex.ru/jobs/vacancies/proj_man/pm_poisk/ Так что про инсайдерскую не надо мне таким тоном затирать. Продолжать беседу с вами не буду, неинтересно.
7 центось. Сетевые интерфейсы (говорю за initscripts) инициализацируются раньше basic.taget, в котором находится iptables. В свою очередь sysinit.target, где systemd-sysctl, стартует позже basic.target. С NetworkManager не смотрел, но сути вряд ли поменяет, ведь главное, что sysctl вступит в силу после iptables.
Посмотрел также на archlinux, там такая же картина, просто все раскидано в немного другие таргеты.
Склонен думать, что так на всех systemd-based, ибо это поведение напоминает стандартное.
В остальных, особенно в bsd-like (crux, slackware), лучше все проверить, думаю, возможны разные варианты :)
Вообще, главное решать задачи. Однажды, движемый только фаном, я поставил CRUX (см. вики) на веб-сервер: он тащил lxc, dns, несколько nginx, gunicorn/python, vpn + фаерволл с прокидом портов, натом для lxc-сетей, еще что-то было. Ну, в общем, такая типичная ситуация. Кроме того, я на этом же сервере еще и разрабатывал. Так вот, я просто курил мануалы, не ленился собирать ПО, даже пересобрал ядро, и у меня все работало. Клиенты довольны были. Я потратил время только при первичной настройке. А если вы спросите об этом на форумах, то вам скажут что-то в стиле: "ты идиот? какой CRUX?". Правда, перед тем, как отдать проекты, я перекатил все на центу, как на попсовую ОС, чтобы не подвергнуть будущего разработчика фрустрации, чтобы ему не пришлось быть еще и админом))
Поэтому, в качестве совета, просто изучайте инструмент. Крутой и популярный - это Linux. Крутой и непопулярный - это *bsd. Некрутой, менее популярный, менеджерско-продающе-бизнесовый - это Window.
И да, главное в сетевых ОС понимать, как работают сети, чтобы мыслить "так, я хочу получить от фаервола вот это и вот это, пошел в мануал", а не "блин, тут надо вот это сделать, чет ваще хз, как оно, это вообще возможно, или как-то по-другому, пойду спрошу на форуме конфигурацию, как это ваще решают с помощью iptables, зачем мне man iptables, LARTC или RFC по IP".
Ответ на ваш второй вопрос: будущее есть. Но надо дать пару комментов.
FreeBSD находится, скорее, в андерграунде, но при этом будущее у нее есть, умирать точно не собирается, не слушайте все эти холивары. Из особенностей, которые лично меня очень зацепили, там есть киллер-фичи наподобие netgraph (https://ru.wikipedia.org/wiki/Netgraph): как по мне, это сродни гениальному представить все в виде узлов-модулей графа и рулить между ними взаимодействие. В одном из манов читал идею представить вообще все устройства подобным образом (в том числе и диски), это все очень интересно. В плане фаерволлов там выбор шире. Из минусов можете на вики прочитать (про поддержку оборудования, порты и т.п.), я просто хочу заостриться на том, что с точки зрения сетей эта система ну просто мощь, пожалуй, она может все. У линухи другая лицензия (менее дружелюбная к бизнесу, так скажем), другая модель разработки, другое ядро, другие приложения для работы с сетью. Они вряд ли хуже или лучше, это дело вкуса, кто к чему привык. Я вот, например, люблю iptables, iproute, tc, ip и все в этом духе (см. LARTC), не вызывает оно никакой боли, а только восхищение, но так не у всех. По количеству задач, которые можно решить, эти системы, думаю, эквиваленты в целом. Так что если вас тянет к тру POSIX идеологически, к более монолитной системе, более соответствующей идеологии UNIX, более "прямолинейной" (и об этом говорят все ее утилиты вроде route, ifconfig, которые в линухе давно RIP в пользу iproute2, плюс при первом сравнении ipfw мне показался проще и прозрачнее, чем iptables, а pf (еще один их фаерволл) решает многие проблемы более коротко/высокоуровнево, чем iptables, при этом iptables содержит потенциально больше фишек из-за возможности подключать к нему разные модули (советую собрать ядро линухи с нуля хотя бы разок, чтобы просто оценить масштабы и, мб, появится мотивация прочитать про устройство ОС) что, по моему мнению, крайне важно любому айтишнику), скорее всего, чуть медленнее), вам нужно BSD. Это холиварный вопрос, тут не то, чтобы кто-то лучше или хуже. Но вот кто-то любит блюз, а кто-то джаз. И корни-то одни и иногда блюзмен может джазить и наоборот, но идеологии в целом разные. Если у вас глаза не загорелись после такого введения в bsd-like и, тем более, нет серьезных сетевых задач, то выбирайте Linux и глубоко его изучайте. Он крутой, интересный, другой.
Ну и в целом понимание сетей, UNIX-like систем... там миграция туда-сюда не будет проблемой, а просто упрется в мануал, если вдруг ВНЕЗАПНО придет осознание, что что-то интересно. Я вот, например, будучи линуксоидом лет 7+ (как дома, так и по работе в сетях/серверах) иногда заглядываю в bsd-маны, чтобы просто посмотреть, "как оно у них там". Это интересно.
Что касается "почему винда с таким большим куском"... Я не знаю. Про нее я вообще ничего не знаю, вот все эти 7 лет я слышу от знакомых админов, что администрация win - это ад, а сам я ее не использую нигде. На веб-серверах вполне может быть, ведь это C# и вендор-лок в сравнении со скриптовыми технологиями, например. Потенциально там лучше поддержка, кому-то это важно. Но только если представить, там нет ничего сравнимого с iptables, там нет даже пакетного менеджера и нормального шелла, в целом изначально это не сетевая ОС, а ее идеология, которая "закрыто-окошечно-неконсольно-нажмите-f1-для-справки-вместо-man" - это провал. Да и вообще мне нравится стиль изложения в документациях и манах по *nix: он не держит меня за покупателя что ли. Я как будто наравне общаюсь со скилловым админом. Это все мне нравится. Так что за счет чего такой большой кусок? Поддержка, вендор-лок, пиар, ориентированность на бизнес изначально - вот это все.
Roman Kitaev: надо смотреть, какая посещаемость, какая конверсия. У меня был опыт с сайтами, которые по несколько лет работали и ни разу не превышали лимит. При этом обычные формы, никаких каптч (правда, формы на JS + я использовал "защиту" от ботов, называя поле с емейлом как "city", на практике 99% ботов через нее не пройдут). Допустим, 5000 посещений в сутки, если у них конверсия 5% касательно формы, что очень-очень много, то это 250 сообщений всего. У Гугла ограничение в 500 в сутки, а у google apps вообще в 2000. В таких случаях можно не париться. Если же ресурс/конверсия больше, совершаются набеги на форму, то да. То есть я исхожу из задачи, есть проекты, для которых это оверкилл.
А если рассуждать о "красоте решения", то я бы, конечно, сделал все красивее в абстрактном мире. Но не стану утверждать, что это очевидная необходимость.
Нативный send_mail действительно умеет все, что нужно. Это обертка для smtplib, кстати.
В качестве smtp-сервера обычно использую Яндекса/Гугла, но если ожидается много сообщений, то лучше использовать очередь: собирать письма и отправлять разово, например, утром. Это cron, либо celery. Тогда нагрузка на smtp-сервер минимальна.
А для чего она вам? Я даже без статистики скажу, что *nix на первом месте в целом (сюда и bsd-like и linux-like). Сетевой стек в этих ОС просто идеальный, без комментариев (хотя если нужны, могу написать). И что у нас еще остается? Windows? Оно никакое в сравнении (есть куча элементарных задач, которые там не решаются, например, я могу поднять ipip-тоннель за несколько секунд легко и непринужденно на любой линухе, а в винде - даже не знаю...).
Статистика по конкретным дистрибутивам Linux/BSD особого смысла не имеет, ибо везде те же яйца, только в профиль. Можно смотреть по популярности дистрибутивов.
То есть я не понимаю изначальной вашей задачи и какие данные вы хотите получить, ведь проценты того или иного дистрибутива ничего вам не дадут. То есть я знаю, что Windows в меньшинстве, а это значит, что, эмпирически, оно не более 20%. Какая разница, сколько там конкретно? Какая разница, больше Debian или RedHat, потому что конкретному админу будет фиолетово, а окружение в обоих случаях одно и то же?
Итого я не вижу принципиальной разницы, немного иная идеология и инструменты, но в целом, с научной, так скажем, точки зрения все это одного поля ягоды. И еще раз повторюсь, что динамические языки вроде js/python в долгосрочной перспективе требуют большего внимания к архитектуре, а кроме этого еще и дают колоссальную свободу. Это усложняющий фактор, а не упрощающий.
Мне кажется, корректнее рассуждать так:
1) Количество документации.
2) Степень использования штук из CS.
Чем меньше первый пункт и больше второй, тем сложнее область, тем меньше специалистов. И чем больше человек специалист (исходя из моей классификации), тем больше он специалист автоматически в конкретном инструменте (после его освоения, конечно).
Но да, я люто, крайне люто не люблю, когда говорят так про веб-разработку. Тут низкий входной порог за счет высокого уровня абстракции, НО не более того. Разработка, например, сетевых сервисов/приложений (например, пилить модуль для iptables на сях для внутренних задач) на низком уровне отличается меньшим количеством "человеколюбивой" документации и более низким уровнем разработки, меньшей популярностью, но про нее точно также можно сказать: ха, любой десятиклассник может прочитать доки и все будет круто. Но это не показатель.
В дефиците человек, обладающий комплексными знаниями и хорошими знаниями инструмента, обладающий научным мышлением и, если угодно, чутьем.
Так что не соглашусь. Наверное, мой комментарий можно рассматривать как ответ на топик, хых.