Подозреваю, что 911 не столько для удобства, сколько для защиты от "залипания", когда 112 можно набрать случайно в кармане. Хотя наверное оно ещё с дисковых времён — тогда не совсем понятно почему.
Но для этого ведь не нужно стоять и кнопку жать 65000 раз. Через час забрать только, и каким-то образом вычислить какой сработал (видеорегистратор положить например), если это не ясно программно на этапе перебора.
прогноз погоды в аэропорту взлета и посадки, чтобы быть уверенным
"прогноз" и "уверенность" понятия столь же ортогональные ;) А потом оп, и испортилась погода. А топлива до запасного не хватит, максимум пару кругов над ВПП сделать.
Бывает еще полет над водой
Ну, скажем, над водой максимум что нужно — это курс. А над облаками нужно понимать что под ними и на какой высоте — горы, ЛЭП, ветряки, высота ВПП над уровнем моря, даже если заход визуальный (хотя это скорее вопрос удобства, нежели правил и известно заранее, если не вынужденная).
Ну допустим визуальный заход вроде как ночью не запрещён, но как летать ночью? В условиях плохой видимости (а точнее её отсутствия)?
И над облаками тоже.
Визуально? Как без IFR пересечь облака и летать над ними не залетая в них? А если вдруг получится (ну не знаю, взлететь в ясную погоду и налететь на облака), то как вы себе представляете визуальные полёты над облаками? Ориентироваться по солнцу конечно, можно, но чтоб вернуться обратно (по ту сторону облаков), всё-равно нужно лететь по приборам. А значит иметь IFR, как ни крути.
(Ещё не учился, но собираюсь, может чего не понимаю — растолкуйте :))
Визуальные правила, емнип, это когда видно ориентиры на земле.
Суть не в том что "не нужно оповещать о рекордах", а в том, что может и рекорда-то никакого не было.
Предыдущий рекорд по скорости полета к МКС были установлен «Прогресс МС-12» в середине 2019 года — тогда полет прошел за 3 часа 19 минут. А в апреле 2020 года продолжительность полета к станции грузового корабля «Прогресс МС-14» составила 3 часа 20 минут.
Из картинки выше — стандартное время на стыковку 3 часа и 21 минута ± 3 минуты. То есть изначально закладывался такой разброс. Где тут рекорд? Было что-то сделано для достижения рекорда или он "просто получился", потому что изначально закладывался разброс в три минуты?
внутри кода ядра линукса, куда ни один негр никогда в жизни не полезет и не увидит этого
Но ведь расизм это не когда негр увидел и обиделся. Расизм может быть сам по себе без участия оных.
Честно говоря, blacklist/whitelist действительно выглядят безобидно, я думаю, они просто попали под раздачу когда добрались до master/slave, что как-бы действительно странные термины для IT. Понятно что для нас оно звучит обычно, мы все говорим "мастер" и "слэйв" и никогда "хозяин" и "раб" как говорят это они. И вот именно в контексте хозяин/раб оно выглядит странно.
вместо удобных терминов стали неудобные
Разве? В статье приведены отличные варианты контекстного использования. В программировании вроде хорошая практика именовать "говорящими" именами. И контекстные варианты подходят куда как лучше, чем абстрактные master/slave, оторванные не то, что от контекста, а в принципе просто "исторически сложилось".
Комьюнити жаловаться не привыкло, потому что зачастую сидит на пиратке, а разработчики не слушают пиратов.
Не совсем понятно, что мешает писать фидбеки тем, кто купил. "Меня всё-равно не будут слушать", или пишете, но не слушают, потому что… думают что вы пират (нельзя проверить, что-ли)?
Конечно. Но от проекта к проекту, от команды к команды всё очень сильно разное. Технологии, год, когда изначально проект был разработан (когда самый продвинутый был, например, бекбон. Переписывать на реакт? Это банально дорого).
Неужели никогда не хотелось просто взять и подвигать элемент, изменяя его положение?
Честно говоря, нет. "Подвигать" можно столькими способами (и косвенно меняя отступы у совершенно других элементов, и меняя глобальные стили для группы элементов, и добавляя новые по хитрому селектору), что делать это мышкой не представляется возможным. Перетягивать трёхпиксельный паддинг, даже с зумом? Уф. Проще всё-таки инспектором.
Например, поигравшись с маржингами/шрифтами/другим в инспекторе, чтобы они автоматом применились к коду?
Или забросить компонент из библиотеки сразу на экран?
Ну вот глядя на тот же сторибук, они круто выглядят из коробки, но когда доходит до кастомизации, оказывается что нужно писать аддон, или править что-то готовое, писать фидбеки, потому что сходу нелегко разобраться в реализации, а потом таки разбираться, форкать и чинить, потому что на фидбеки не обращают внимания… Сейчас мы не используем готовые библиотеки. И я не особо хотел бы. Но, я скорее хотел бы иметь похожую обёртку-библиотеку для собственных разработанных компонентов. Своего рода UI список тех же реакт-компонент. Но это надо менять существующие подходы к разработке и форсить всех писать максимально изолированные компоненты (что, конечно, хорошо…)
Или чтобы изменения, сделанные дизайнером сразу применились к интерфейсу?
Обычно для чего-то супер-нового это да, отдельный дизайн, который потом имплементируется в коде. Правки потом редко поступают от дизайнера.
Касательно новых примерно однотипных страниц, достаточно сказать "сделай как на странице А, только вот тут нужно будет добавить другой список и сделать его скроллируемым". То есть чаще это дизайн-гайд (мы сейчас перешли на AntD), нет необходимости задизайнивать-утверждать всё страницу. Обычно дэвы сами видят, как оно должно выглядеть, и только в крайних случаях обращаются к дизайнеру.
В компаниях где много разноуровневых разработчиков, некоторым требуется чёткая постановка задачи — там да, нужна целиком задизайненная страница.
А как вы решаете вопрос со сложной анимацией?
Не понял вопрос. Ну как, решаем :) Сложная анимация редко только html-css-ная проблема, вступают в силу дополнительные обработки кодом, правила взаимодействия, исключения, оптимизации производительности, инициализации/сборка мусора, вынесение на более глобальный уровень и переиспользование, если большие структуры, а оно нужно внутри сотен под-компонент.
В общем, подводя итог, можно взять AntD, Storybook, и скрутить из них готовый продукт. Как и из вордпресса склепать Амазон, наверное, в теории. Но мне кажется сложность разработки после некоторого порога сильно превысит сложность разработки изначально вручную. И это точно нужно делать в начале пути, закладывая риски. Я видел проекты которые переписывались с нуля через каких-то пару лет, потому что предыдущая команда использовала какой-то хитрый подход, в котором сложнее (и дороже для компании) было разобраться (Вам может показаться "вот оно, вот она, ниша, нужен стандарт, по которому можно будет брать готовый проект и передизайнивать его с минимальными вложениями в код". Но нет. Было 11 стандартов, теперь их 12. А самый стандартный стандарт — это то, что есть сейчас).
Если так подумать, браузер со всеми этими стандартами и есть воплощение того инструмента, с помощью которого можно сделать буквально что угодно, максимально гибко. Всё остальное будет абсолютно точно гораздо менее гибче.
web-фуллстек я. Хотя больше работал с фронтэндом, конечно. Застал dreamweaver ещё когда он был от Макромедии, и уже тогда не особо ценился за тот мусор, который выплёвывал (может с тех пор что-то изменилось, давно его не тыкал). Последние года 4 работаю над крупными веб-приложениями (это которые разрастаются настолько, что сайтами уже не назовёшь). Сейчас, навскидку, страницы целиком добавляются редко, больше задач на изменить что-то в готовом функционале. Прикрутить Вашу идею, даже покрывающую 80% кейсов мне лично не представляется ни возможным ни целесообразным.
Для небольших студийных проектов — может быть, но… Тут мне сложно сказать. Обычно это или одностраничные лендинги, или магазины. И то и то чаще генерируется, берётся какой-нибудь вордпресс/джумла/e-commerce CMS, ещё что-то такое, готовые шаблоны и, при необходимости, правятся.
Потому что задачи не ставятся по принципу "наши инструмент может сделать такое", они ставятся по принципу "дизайнер нарисовал, задумал что оно будет работать именно так, надо сделать", например.
Потому что это ещё одна прослойка-чёрный-ящик. Может сработает, а может и нет. Вывод — нужен всё-равно квалифицированный верстальщик на случай если не сработает. А если нет — зачем пробовать? А если сработает — нужно перепроверять, смотреть как оно будет в разных браузерах, при разных условиях. Я, когда код пишу, уже знаю наверняка, как он будет где работать, а если готовое что-то взять — нужно разбираться в нём.
В общем, как по мне, сфера применения прослеживается слабо. Для лендингов полно генераторов. Для чего посложнее — всё-равно нужно ручками писать, проще это делать сразу. Тут нужно найти нишу, а её я не вижу.
Так чтоб перетягивать все возможные блоки из списка — может быть и нет, потому что для каждого блока можно указать сотни настроек не только отображения, но и поведения и взаимодействия с другими блоками.
Для статических форм со скриншота вариантов полно.
Пришлось разбираться с React и кодить каждый компонент формы. И я до сих пор не понимаю, почему не появилось никакого средства визуального проектирования, чтобы на выходе был html с дивами и css
Как-то непонятно, таки нужен React на выходе или html+css? Если последнее — зачем разбираться в Реакте?
Я б сказал, рассчитывать можно процентов на 30. Когда начнёте добавлять обработку пограничных случаев (в погоне хотя бы за 60%) начнётся такая нечеловеческая каша, которую ещё Dreamweaver/Word выдавали на выходе после wysiwyg редактирования.
Если говорить не о научной работе, а о продукте, то даже не то чтобы можно, но стоит рассчитывать на 30%. Типа вот продукт, он вам выплюнет на выходе валидную семантическую расширяемую вёрстку для лендинга.
Но таких продуктов вроде и так достаточно, по причине однообразности лендингов. Добавить хидер, три колонки, слайдер, картинка-текст блок, футер — лендинг готов.
А обрабатывать все возможные перекрытия… Ну так этим сейчас и браузеры занимаются уже много лет, и до сих пор баги вылазят. Но как научная работа без особой цели и конца — наверное почему бы и нет.
В наше потребительское время сложно однозначно сказать, что живущее 5 лет устройство, которое в наилучшем (далеко не всегда) случае оказывается на вторичном рынке — это хорошо. Вдруг учёные додумаются до припоя который разлагается через 5 лет? Хорошо это или плохо? Для тех, кто устройство не менял 15 лет плохо, конечно. Для экономики и природы в целом хорошо. Разрабатываются новые устройства, старые не загрязняют природу. Должен быть сбалансированный круговорот, вечные вещи на самом деле никому не нужны.
ЗЫ: конечно речь не идёт о технике, которая не должна стареть. Условно те же панели. Разные критические приборы, но думаю это и так очевидно. В первую очередь речь о всех тех девайсах, которые устаревают через год-два.
Ну так это процесс, а не единоразовое действие. Больше зелёной энергии — больше энергии для разработки компонентов для зелёной энергии — больше зелёной энергии.
Выносить очень далеко сложно по логистическим причинам. Если кто-то наставит в океане платформ, и наладит логистику производства и вывоза отходов — перенесут туда.
Проходят учения национального масштаба.
Подозреваю, что 911 не столько для удобства, сколько для защиты от "залипания", когда 112 можно набрать случайно в кармане. Хотя наверное оно ещё с дисковых времён — тогда не совсем понятно почему.
С одной поправкой — это не мнение, это вброс.
Но для этого ведь не нужно стоять и кнопку жать 65000 раз. Через час забрать только, и каким-то образом вычислить какой сработал (видеорегистратор положить например), если это не ясно программно на этапе перебора.
"прогноз" и "уверенность" понятия столь же ортогональные ;) А потом оп, и испортилась погода. А топлива до запасного не хватит, максимум пару кругов над ВПП сделать.
Ну, скажем, над водой максимум что нужно — это курс. А над облаками нужно понимать что под ними и на какой высоте — горы, ЛЭП, ветряки, высота ВПП над уровнем моря, даже если заход визуальный (хотя это скорее вопрос удобства, нежели правил и известно заранее, если не вынужденная).
Ну допустим визуальный заход вроде как ночью не запрещён, но как летать ночью? В условиях плохой видимости (а точнее её отсутствия)?
Визуально? Как без IFR пересечь облака и летать над ними не залетая в них? А если вдруг получится (ну не знаю, взлететь в ясную погоду и налететь на облака), то как вы себе представляете визуальные полёты над облаками? Ориентироваться по солнцу конечно, можно, но чтоб вернуться обратно (по ту сторону облаков), всё-равно нужно лететь по приборам. А значит иметь IFR, как ни крути.
(Ещё не учился, но собираюсь, может чего не понимаю — растолкуйте :))
Визуальные правила, емнип, это когда видно ориентиры на земле.
Правила полёта по приборам (в условиях плохой видимости) в основном.
Требуются для полётов над облаками в том числе.
Сдаются отдельно от PPL.
Видимо речь про обзорный режим.
Суть не в том что "не нужно оповещать о рекордах", а в том, что может и рекорда-то никакого не было.
Из картинки выше — стандартное время на стыковку 3 часа и 21 минута ± 3 минуты. То есть изначально закладывался такой разброс. Где тут рекорд? Было что-то сделано для достижения рекорда или он "просто получился", потому что изначально закладывался разброс в три минуты?
Справедливости ради, расшифровка интервью на то и расшифровка, а не адаптация/перевод.
Но ведь расизм это не когда негр увидел и обиделся. Расизм может быть сам по себе без участия оных.
Честно говоря, blacklist/whitelist действительно выглядят безобидно, я думаю, они просто попали под раздачу когда добрались до master/slave, что как-бы действительно странные термины для IT. Понятно что для нас оно звучит обычно, мы все говорим "мастер" и "слэйв" и никогда "хозяин" и "раб" как говорят это они. И вот именно в контексте хозяин/раб оно выглядит странно.
Разве? В статье приведены отличные варианты контекстного использования. В программировании вроде хорошая практика именовать "говорящими" именами. И контекстные варианты подходят куда как лучше, чем абстрактные master/slave, оторванные не то, что от контекста, а в принципе просто "исторически сложилось".
Не совсем понятно, что мешает писать фидбеки тем, кто купил. "Меня всё-равно не будут слушать", или пишете, но не слушают, потому что… думают что вы пират (нельзя проверить, что-ли)?
Конечно. Но от проекта к проекту, от команды к команды всё очень сильно разное. Технологии, год, когда изначально проект был разработан (когда самый продвинутый был, например, бекбон. Переписывать на реакт? Это банально дорого).
Честно говоря, нет. "Подвигать" можно столькими способами (и косвенно меняя отступы у совершенно других элементов, и меняя глобальные стили для группы элементов, и добавляя новые по хитрому селектору), что делать это мышкой не представляется возможным. Перетягивать трёхпиксельный паддинг, даже с зумом? Уф. Проще всё-таки инспектором.
Хром это умеет, но я этим практически не пользовался.
Ну вот глядя на тот же сторибук, они круто выглядят из коробки, но когда доходит до кастомизации, оказывается что нужно писать аддон, или править что-то готовое, писать фидбеки, потому что сходу нелегко разобраться в реализации, а потом таки разбираться, форкать и чинить, потому что на фидбеки не обращают внимания… Сейчас мы не используем готовые библиотеки. И я не особо хотел бы. Но, я скорее хотел бы иметь похожую обёртку-библиотеку для собственных разработанных компонентов. Своего рода UI список тех же реакт-компонент. Но это надо менять существующие подходы к разработке и форсить всех писать максимально изолированные компоненты (что, конечно, хорошо…)
Обычно для чего-то супер-нового это да, отдельный дизайн, который потом имплементируется в коде. Правки потом редко поступают от дизайнера.
Касательно новых примерно однотипных страниц, достаточно сказать "сделай как на странице А, только вот тут нужно будет добавить другой список и сделать его скроллируемым". То есть чаще это дизайн-гайд (мы сейчас перешли на AntD), нет необходимости задизайнивать-утверждать всё страницу. Обычно дэвы сами видят, как оно должно выглядеть, и только в крайних случаях обращаются к дизайнеру.
В компаниях где много разноуровневых разработчиков, некоторым требуется чёткая постановка задачи — там да, нужна целиком задизайненная страница.
Не понял вопрос. Ну как, решаем :) Сложная анимация редко только html-css-ная проблема, вступают в силу дополнительные обработки кодом, правила взаимодействия, исключения, оптимизации производительности, инициализации/сборка мусора, вынесение на более глобальный уровень и переиспользование, если большие структуры, а оно нужно внутри сотен под-компонент.
В общем, подводя итог, можно взять AntD, Storybook, и скрутить из них готовый продукт. Как и из вордпресса склепать Амазон, наверное, в теории. Но мне кажется сложность разработки после некоторого порога сильно превысит сложность разработки изначально вручную. И это точно нужно делать в начале пути, закладывая риски. Я видел проекты которые переписывались с нуля через каких-то пару лет, потому что предыдущая команда использовала какой-то хитрый подход, в котором сложнее (и дороже для компании) было разобраться (Вам может показаться "вот оно, вот она, ниша, нужен стандарт, по которому можно будет брать готовый проект и передизайнивать его с минимальными вложениями в код". Но нет. Было 11 стандартов, теперь их 12. А самый стандартный стандарт — это то, что есть сейчас).
Если так подумать, браузер со всеми этими стандартами и есть воплощение того инструмента, с помощью которого можно сделать буквально что угодно, максимально гибко. Всё остальное будет абсолютно точно гораздо менее гибче.
web-фуллстек я. Хотя больше работал с фронтэндом, конечно. Застал dreamweaver ещё когда он был от Макромедии, и уже тогда не особо ценился за тот мусор, который выплёвывал (может с тех пор что-то изменилось, давно его не тыкал). Последние года 4 работаю над крупными веб-приложениями (это которые разрастаются настолько, что сайтами уже не назовёшь). Сейчас, навскидку, страницы целиком добавляются редко, больше задач на изменить что-то в готовом функционале. Прикрутить Вашу идею, даже покрывающую 80% кейсов мне лично не представляется ни возможным ни целесообразным.
Для небольших студийных проектов — может быть, но… Тут мне сложно сказать. Обычно это или одностраничные лендинги, или магазины. И то и то чаще генерируется, берётся какой-нибудь вордпресс/джумла/e-commerce CMS, ещё что-то такое, готовые шаблоны и, при необходимости, правятся.
Потому что задачи не ставятся по принципу "наши инструмент может сделать такое", они ставятся по принципу "дизайнер нарисовал, задумал что оно будет работать именно так, надо сделать", например.
Потому что это ещё одна прослойка-чёрный-ящик. Может сработает, а может и нет. Вывод — нужен всё-равно квалифицированный верстальщик на случай если не сработает. А если нет — зачем пробовать? А если сработает — нужно перепроверять, смотреть как оно будет в разных браузерах, при разных условиях. Я, когда код пишу, уже знаю наверняка, как он будет где работать, а если готовое что-то взять — нужно разбираться в нём.
В общем, как по мне, сфера применения прослеживается слабо. Для лендингов полно генераторов. Для чего посложнее — всё-равно нужно ручками писать, проще это делать сразу. Тут нужно найти нишу, а её я не вижу.
Ну так в том-то и дело, что нынешние модные фреймворки сильно интегрированы в разметку. Для статики генерируют разными тильдами.
Да полно их. Вон, дедушка Dreamweaver ещё жив: https://www.adobe.com/products/dreamweaver.html
Так чтоб перетягивать все возможные блоки из списка — может быть и нет, потому что для каждого блока можно указать сотни настроек не только отображения, но и поведения и взаимодействия с другими блоками.
Для статических форм со скриншота вариантов полно.
Как-то непонятно, таки нужен React на выходе или html+css? Если последнее — зачем разбираться в Реакте?
Я б сказал, рассчитывать можно процентов на 30. Когда начнёте добавлять обработку пограничных случаев (в погоне хотя бы за 60%) начнётся такая нечеловеческая каша, которую ещё Dreamweaver/Word выдавали на выходе после wysiwyg редактирования.
Если говорить не о научной работе, а о продукте, то даже не то чтобы можно, но стоит рассчитывать на 30%. Типа вот продукт, он вам выплюнет на выходе валидную семантическую расширяемую вёрстку для лендинга.
Но таких продуктов вроде и так достаточно, по причине однообразности лендингов. Добавить хидер, три колонки, слайдер, картинка-текст блок, футер — лендинг готов.
А обрабатывать все возможные перекрытия… Ну так этим сейчас и браузеры занимаются уже много лет, и до сих пор баги вылазят. Но как научная работа без особой цели и конца — наверное почему бы и нет.
В наше потребительское время сложно однозначно сказать, что живущее 5 лет устройство, которое в наилучшем (далеко не всегда) случае оказывается на вторичном рынке — это хорошо. Вдруг учёные додумаются до припоя который разлагается через 5 лет? Хорошо это или плохо? Для тех, кто устройство не менял 15 лет плохо, конечно. Для экономики и природы в целом хорошо. Разрабатываются новые устройства, старые не загрязняют природу. Должен быть сбалансированный круговорот, вечные вещи на самом деле никому не нужны.
ЗЫ: конечно речь не идёт о технике, которая не должна стареть. Условно те же панели. Разные критические приборы, но думаю это и так очевидно. В первую очередь речь о всех тех девайсах, которые устаревают через год-два.
Ну так это процесс, а не единоразовое действие. Больше зелёной энергии — больше энергии для разработки компонентов для зелёной энергии — больше зелёной энергии.
Выносить очень далеко сложно по логистическим причинам. Если кто-то наставит в океане платформ, и наладит логистику производства и вывоза отходов — перенесут туда.