Имя элемента несёт семантическую роль. Это шапка, это артикль, и тд. Для нужд вёрстки приходится использовать куда больше элементов, чем это требуется для семантики, поэтому никуда не деться от кучи "лишних" дивов. Например, какая семантическая роль будет у элемента, чьё предназначение - быть контейнером для стиля clearfix?
Очень даже логично. Самокат и автомобиль - настолько разные вещи, что с тем же успехом можно назвать водителем и пешехода - ведь он водит собственное тело. Почему тогда у этих самых пешеходов законодательно нет ограничения скорости?
Другое дело, что подобное устройство, на котором можно сидеть и которое разгоняется до 85 км/ч, самокатом называется явно по недоразумению. Давайте теперь вообще все мотоциклы и скутеры самокатами будем называть, чего уж там.
И на скорости 85 км/ч мы поиграем в игру криворукий самокатчик против разявы-пешехода. [...] Ну а если не выживете — вы напишите заранее, что претензий не имеете.
А давайте сыграем в другую игру. Я отломаю ветку потолще и дам вам ей по голове со всей силы.
Будем теперь деревья запрещать? Или там, кухонные ножи? Знаете, сколько народу ими режет друг друга в квартирах? Дебилов надо запрещать, а не инструменты.
Это просто пример того, что даже на полностью статическом сайте можно сделать поиск без участия бекенда. Я не призываю так делать во всех случаях.
Можно делать поисковый запрос со статического сайта в отдельный апи-эндпоинт, и даже не обязательно свой. Например, vuejs.org не держит свой сервер с эластиком, вместо этого пользуясь услугами www.algolia.com. Сам сайт они через hexo.io компилят.
Именно так. А если контента не слишком много, то и поиск можно сделать аналогично — заранее сгенерировать поисковый индекс отдельным файлом и подгружать его по запросу, как вариант, ограничиваясь только заголовками.
Относительно технологий, — спасибо за советы, но мы то ищем специалиста для решения определенной задачи, а не технологию.
На мой взгляд, это неправильный подход. Вы ведь не разовую задачу хотите закрыть, верно? Нужно оценивать именно с точки зрения технологий: насколько большой рынок специалистов именно по этой технологии, насколько легко что-то сделать, насколько легко потом дорабатывать, насколько легко можно идти вразрез с принципами фреймворка или cms, если надо сделать что-то, не укладывающееся в парадигму, и, самое главное, насколько технология устаревает со временем и насколько легко в будущем будет найти человека, который будет это дорабатывать, а так же насколько легко в будущем можно будет мигрировать от одной технологии к другой без слома функционала, если на то появится необходимость. И уже после этого искать специалиста.
А то ведь может сложиться неприятная ситуация, когда вы наймете специалиста по %cms_name%, он сделает эдак 95% всего того, что нужно сделать, а потом окажется, что самые главные 5% вообще никак не получаются, и нужно либо начинать всё с нуля, либо форкать саму %cms_name%, чтобы что-то там дописать.
Я бы вам посоветовал вообще не рассматривать все эти вордпрессы и друпалы. Такие движки удобны, когда ты клепаешь типовые сайты и забываешь о них уже на следующий день. Если проект «живой» и планируется его развитие со временем — непременно упретесь в ограничения архитектуры, а кастомизировать всё это сложно, потому что крутые спецы обычно уходят из этих cms в нормальное программирование, а начинающие просто не умеют этого делать.
Вообще, если бы лично мне понадобилось сделать такой сайт, я бы остановился на двух вариантах, у каждого есть свои преимущества и недостатки.
1. Использовать ruby on rails для всего, т.е. никакого разделения на фронт и бек, апи, отдельного фронтенд-фреймворка и подобного. Это даст скорость в разработке и легкость в будущих доработках, если вдруг понадобится получившуюся буханку превратить в троллейбус :)
По поводу поиска: на начальном этапе вообще не заморачиваться с эластикчерчем или сфинксом. У вас нет собственного отдела разработки, так что надо стараться использовать как можно меньше технологий. Используя postgres как базу данных, можно в нём же и делать полнотекстовой поиск, как обычный, так и по триграммам: www.postgresql.org/docs/current/textsearch.html Вряд ли у вас в ближайшем будущем будут нагрузки на уровне даже десятков тысяч запросов в секунду, чтобы запускать отдельный кластер на эластике.
2. Использовать статический генератор сайтов — тысячи их — писать статьи в формате markdown, билдить и заливать получившиеся файлы на сервер. Либо использовать гибридную модель — когда html пререндерится заранее, а после загрузки страницы на клиенте разворачивается js-фреймворк и через апи подгружает какие-то динамические данные, превращая статичаский сайт в spa.
Что в этом подходе хорошо — можно в начале сделать сам сайт, наполнять его статьями, а на динамические штуки, вроде поиска, нанимать отдельных людей. Но это скорее вариант для желающих поэкспериментировать, если же хочется предсказуемости, то я бы остановился на рельсах.
Недостаток обоих подходов в том в том, что это будет дороже. Если на вордпрессе можно найти типичного такого «веб-мастера», который за чашку кофе всё это сделает (оставляя за скобками разговор о качестве), то тут нужен нормальный программист.
У вас верное впечатление. Вся эта бюрократия из других сфер до айти ещё не добралась, поэтому сейчас ещё можно позволить себе отбирать людей по их навыкам, а не по бумажкам.
Ещё раз, смысл обучения — это сделать так, чтобы человек смог предсказывать исход развития ситуации, не встречавшись именно с этой ситуацией ранее.
Думаю, что вы с фондовым рынком раньше не встречались, верно? Предскажете мне, куда акция определенной компании пойдет?)
То, что в жаваскрипте из вашего прошлого предмета «5» + 3 == «53» — это просто особенность работы конкретного ЯПа, это можно запомнить и пойти дальше. Неприятно конечно, да. Но это не помешает сделать какую-нибудь браузерную игрушку или домашнюю страничку. Целые толпы фронтендеров-верстальщиков всех мастей, которые ну ни разу не учились на программистов, успешно с этим справляются, а ваши школьники вдруг на непреодолимую преграду наткнутся? Вы их за умственно-отсталых держите?
Мир несовершенен, а созданное руками человека несовершенно вдвойне. Не думаю, что школьнику будет сложно понять такую простую истину.
Я ещё далеко не старик, но чем больше я живу, тем отчетливей вижу, что нет никакого обновления общества. Поколение за поколением наступает на одни и те же грабли. Да, каждый раз эти грабли выглядят по-разному, но по факту, это просто краска другая, сами грабли ровно те же самые.
А ещё мне интересно, если бы великие учёные не умирали бы от старости и болезней, а их разум не ослабевал со временем, в каком мире бы мы бы сейчас жили.
Так вот, автор задает вопрос: нафига? Половое созревание, рождение потомства, и его взращивание, лет 35. Ну окей, социализация, проблемы золотого мииллиарда и т.д. — 50 лет. Внуки — 75 лет, правнуки — 100. В чем смысл дальше? Банальный вопрос, но — нафига?
В чем смысл дальше? Я бы задал вопрос по-другому: а в чем смысл раньше был? В жизни нет никакого смысла, мы живём просто потому что живём. Если человек нужен только чтобы родить детей, а дети нужны только для того, чтобы родить своих детей, а самый последний ребёнок закончит свою жизнь вместе с тепловой смертью вселенной, то глобальная цель всего этого процесса вызывает вопросы.
Спрошу напрямик: автор, почему ты еще себя не убил? У тебя есть какая-то точная цифра, вроде «жить надо ровно 99 лет, не больше и не меньше», и по достижении этой цифры ты в ту же секунду завершишь своё существование? Если да, то я бы хотел услышать обоснование, почему именно столько, и если ты прав, то, возможно, нам следует на законодательном уровне начать убивать всех по достижению этой цифры. Если же нет, то вся эта статья и яица выеденного не стоит.
Сегодня я бы хотел прожить хотя бы еще один день. Завтра я так же захочу прожить хотя бы еще один день. Применяя индукцию, можно сделать вывод, что не будет такой даты, когда я скажу «всё, достаточно, пора умирать». И я не думаю, что на всей планете найдется хоть один адекватный человек, который будет считать по-другому. Разумеется, если исключить из такого мысленного эксперимента негативные внешние факторы — вроде маразма, сильной боли, принуждения, и подобного.
[...] но для знакомства с основами от паскаля в школьном курсе толку будет явно больше чем от гайдов современного образца «подключите библиотеку такую-то и она вам всё волшебным образом сделает»...
Кому именно будет больше толку?
Паскаль — это не самый нижний уровень абстракции. Почему-то вы не предлагаете начать с машинных кодов, или с самостоятельного конструирования вентилей интегральной схемы. Кому надо — тот и сам уйдет вниз, смотреть, что у подключаемых библиотек под капотом. А кому не надо — хотя бы будут уметь писать простые скрипты для решения бытовых задач. Знание какого-нибудь питона будет в десятки раз полезней знания паскаля.
Не забывайте, речь идет про информатику в школе, а не про обучение на программиста. Если будущий бухгалтер, ученый, строитель, водитель, будет уметь пользоваться компьютером — это гораздо лучше, чем если он будет думать, что программирование — это какая-то сложная муть для задротов, типа математики.
Дело в том что в трубах накапливается пыть, влага и тепло — это идеальные условия для развития разных опасных микроорганизмов: золотого стафилакока, леагианелы и т.д.
Можно на "последней миле" трубы обрабатывать входящий в квартиру воздух ультрафиолетовым светом, определённой длины волны. Не думаю, что на это будет много электроэнергии уходить.
Я могу ещё тысячу разных вариаций применений тегов div сказать, их все будем в стандарт добавлять?
Имя элемента несёт семантическую роль. Это шапка, это артикль, и тд. Для нужд вёрстки приходится использовать куда больше элементов, чем это требуется для семантики, поэтому никуда не деться от кучи "лишних" дивов. Например, какая семантическая роль будет у элемента, чьё предназначение - быть контейнером для стиля clearfix?
Так и запишем, Аморалист хочет запретить деревья.
Очень даже логично. Самокат и автомобиль - настолько разные вещи, что с тем же успехом можно назвать водителем и пешехода - ведь он водит собственное тело. Почему тогда у этих самых пешеходов законодательно нет ограничения скорости?
Другое дело, что подобное устройство, на котором можно сидеть и которое разгоняется до 85 км/ч, самокатом называется явно по недоразумению. Давайте теперь вообще все мотоциклы и скутеры самокатами будем называть, чего уж там.
Будем теперь деревья запрещать? Или там, кухонные ножи? Знаете, сколько народу ими режет друг друга в квартирах? Дебилов надо запрещать, а не инструменты.
Можно делать поисковый запрос со статического сайта в отдельный апи-эндпоинт, и даже не обязательно свой. Например, vuejs.org не держит свой сервер с эластиком, вместо этого пользуясь услугами www.algolia.com. Сам сайт они через hexo.io компилят.
Так что было бы желание, а способов уйма.
А то ведь может сложиться неприятная ситуация, когда вы наймете специалиста по %cms_name%, он сделает эдак 95% всего того, что нужно сделать, а потом окажется, что самые главные 5% вообще никак не получаются, и нужно либо начинать всё с нуля, либо форкать саму %cms_name%, чтобы что-то там дописать.
Вообще, если бы лично мне понадобилось сделать такой сайт, я бы остановился на двух вариантах, у каждого есть свои преимущества и недостатки.
1. Использовать ruby on rails для всего, т.е. никакого разделения на фронт и бек, апи, отдельного фронтенд-фреймворка и подобного. Это даст скорость в разработке и легкость в будущих доработках, если вдруг понадобится получившуюся буханку превратить в троллейбус :)
По поводу поиска: на начальном этапе вообще не заморачиваться с эластикчерчем или сфинксом. У вас нет собственного отдела разработки, так что надо стараться использовать как можно меньше технологий. Используя postgres как базу данных, можно в нём же и делать полнотекстовой поиск, как обычный, так и по триграммам: www.postgresql.org/docs/current/textsearch.html Вряд ли у вас в ближайшем будущем будут нагрузки на уровне даже десятков тысяч запросов в секунду, чтобы запускать отдельный кластер на эластике.
2. Использовать статический генератор сайтов — тысячи их — писать статьи в формате markdown, билдить и заливать получившиеся файлы на сервер. Либо использовать гибридную модель — когда html пререндерится заранее, а после загрузки страницы на клиенте разворачивается js-фреймворк и через апи подгружает какие-то динамические данные, превращая статичаский сайт в spa.
Что в этом подходе хорошо — можно в начале сделать сам сайт, наполнять его статьями, а на динамические штуки, вроде поиска, нанимать отдельных людей. Но это скорее вариант для желающих поэкспериментировать, если же хочется предсказуемости, то я бы остановился на рельсах.
Недостаток обоих подходов в том в том, что это будет дороже. Если на вордпрессе можно найти типичного такого «веб-мастера», который за чашку кофе всё это сделает (оставляя за скобками разговор о качестве), то тут нужен нормальный программист.
Понятное дело, что никто не думает "где бы мне мошенника найти, чтобы у него купить?", это просто словесный оборот.
У вас верное впечатление. Вся эта бюрократия из других сфер до айти ещё не добралась, поэтому сейчас ещё можно позволить себе отбирать людей по их навыкам, а не по бумажкам.
То, что в жаваскрипте из вашего прошлого предмета «5» + 3 == «53» — это просто особенность работы конкретного ЯПа, это можно запомнить и пойти дальше. Неприятно конечно, да. Но это не помешает сделать какую-нибудь браузерную игрушку или домашнюю страничку. Целые толпы фронтендеров-верстальщиков всех мастей, которые ну ни разу не учились на программистов, успешно с этим справляются, а ваши школьники вдруг на непреодолимую преграду наткнутся? Вы их за умственно-отсталых держите?
Мир несовершенен, а созданное руками человека несовершенно вдвойне. Не думаю, что школьнику будет сложно понять такую простую истину.
Я ещё далеко не старик, но чем больше я живу, тем отчетливей вижу, что нет никакого обновления общества. Поколение за поколением наступает на одни и те же грабли. Да, каждый раз эти грабли выглядят по-разному, но по факту, это просто краска другая, сами грабли ровно те же самые.
А ещё мне интересно, если бы великие учёные не умирали бы от старости и болезней, а их разум не ослабевал со временем, в каком мире бы мы бы сейчас жили.
В чем смысл дальше? Я бы задал вопрос по-другому: а в чем смысл раньше был? В жизни нет никакого смысла, мы живём просто потому что живём. Если человек нужен только чтобы родить детей, а дети нужны только для того, чтобы родить своих детей, а самый последний ребёнок закончит свою жизнь вместе с тепловой смертью вселенной, то глобальная цель всего этого процесса вызывает вопросы.
Сегодня я бы хотел прожить хотя бы еще один день. Завтра я так же захочу прожить хотя бы еще один день. Применяя индукцию, можно сделать вывод, что не будет такой даты, когда я скажу «всё, достаточно, пора умирать». И я не думаю, что на всей планете найдется хоть один адекватный человек, который будет считать по-другому. Разумеется, если исключить из такого мысленного эксперимента негативные внешние факторы — вроде маразма, сильной боли, принуждения, и подобного.
Паскаль — это не самый нижний уровень абстракции. Почему-то вы не предлагаете начать с машинных кодов, или с самостоятельного конструирования вентилей интегральной схемы. Кому надо — тот и сам уйдет вниз, смотреть, что у подключаемых библиотек под капотом. А кому не надо — хотя бы будут уметь писать простые скрипты для решения бытовых задач. Знание какого-нибудь питона будет в десятки раз полезней знания паскаля.
Не забывайте, речь идет про информатику в школе, а не про обучение на программиста. Если будущий бухгалтер, ученый, строитель, водитель, будет уметь пользоваться компьютером — это гораздо лучше, чем если он будет думать, что программирование — это какая-то сложная муть для задротов, типа математики.
Можно на "последней миле" трубы обрабатывать входящий в квартиру воздух ультрафиолетовым светом, определённой длины волны. Не думаю, что на это будет много электроэнергии уходить.