Search
Write a publication
Pull to refresh
-1
0
Send message

То есть, вы полагаете что полностью загруженный условный "боинг" летает обычно ниже чем пустой, так что ли? Очевидно нет. Используемый лайнером эшелон при его полной загрузке не меняется.

Вы неправы. Полностью загруженный самолёт действительно летает ниже, чем может лететь пустой. Если полёт достаточно далеко, то по мере выработки топлива обычно стараются забраться повыше, на те эшелоны, которые были недоступны сразу после вылета из-за большого веса, называется step climb.

"С миру по нитке" - это и про Boeing, и про Airbus: там производителей комплетующих и материалов просто тьма самых разных стран и брендов, "с миру" в данном случае буквально, а не просто фигура речи. К МС, увы, это уже в меньшей степени применимо. Не говорю, хорошо это или плохо, просто факт.

Тяговооруженность любого из современных лайнеров будет примерно на одном уровне по одной простой причине: снизу она ограничена требованиями к тому, чтобы на одном из двух двигателей самолёт мог безопасно набирать высоту с отрыва, а сверху она ограничивается экономикой - делать что-то избыточное невыгодно, так как это выше расход, выше масса, собственно, снова выше расход. Вот и получается, что любой современный двухдвигательный лайнер так умеет на показательных полётах без пассажиров, груза и с минимумом топлива.

Спасибо за наводку, не знал, надо будет поискать подобное про SSJ-100.

Простите, не могу не поправить. Самое смешное, что он сертифицирован, да-да, причем как МС-21-300 с PW, так и МС-21-310 с ПД-14, можете в интернете самостоятельно найти сертификат FATA-01010A с изменениями от 28 декабря 2022 года. Как самолёт, про финальный облик которого еще даже сам производитель толком не знает, получил сертификат, - вот в чем вопрос еще. Абсурд :)

А если учесть, что тележка стоит посередине прохода, то реальный "прирост" получается 9-10 см (с каждой стороны), да? Можно прям бегать, ага.

Поставки в условном следующем году обещают уже много-много лет. Что конкретно сейчас принципиально изменилось, чтобы вот именно в этот раз пресловутое "в следующем году" сработало, а не как всегда? Хочется верить, но верится с трудом.

Да никак. Стрижка в России за 4-5 евро и в Ирландии за 15 - это просто стрижка, никакой разницы.

Хамство на почте и не только — это просто злость работника, который работает за МРОТ, и ему эта работа не нравится.

Простите, но вот тут не соглашусь. Потребитель не виноват, что этому человеку не нравится его работа за МРОТ, и выплёскивать своё недовольство на постороннего человека — это как раз невоспитанность. Он может адресовать это своему руководству или какому-нибудь профсоюзу, но не левому человеку, который тут совершенно не при делах.


Про инфраструктуру вы правы, однако я хотел сделать акцент не на самом факте выбрасывания мусора в яму, а на том, как это воспринималось — как норма. Вот что страшно. Одно дело — поступать так от безысходности, понимая, что это неправильно, но вариантов нет; и совсем другое — считать это нормальным поведением. Тут пример с мелким мусором на улице более показателен: в городе, в отличие от дачи, ведь никогда не было проблемой дойти до урны и выбросить бумажку туда, однако было нормальным бросить и просто на землю там же, где и идешь, например билетик после поездки в трамвае или автобусе. Разруха в головах прежде всего, к сожалению.


Но становится лучше, и это не может не радовать.

А у меня обратное наблюдение про воспитание. К сожалению, прекрасно помню, как мы в детстве с дедушкой на даче мусор вывозили на тележке просто к лесу и там закапывали. Я понимаю, что это связанно в первую очередь с отсутствием инфраструктуры, но при этом я не помню даже мыслей о том, что тут что-то не так, всё казалось естественным и нормальным, не вызывало никаких мук совести. Сейчас такого гораздо меньше. Купить шоколадку или лимонад в ларьке, употребить, а фантик или бутылку просто бросить на улице в моём детстве тоже считалось почему-то нормальным. Окурки и пустые пачки от сигарет тоже валялись повсюду. Сейчас такого массово не наблюдаю, попадаются единичные уникумы, конечно, но не в таких масштабах. Хамства от прадовцов в магазинах или на почте какой-нибудь я не слышал уже лет 10, до этого это было нормой, сейчас все вежливые и приветливые, особенно кто помоложе. Стащить что-то с завода домой считалось не воровством, а нормальной ситуацией. Да, моё детство пришлось на 90-е и начало 0-ых, но разве взрослые тогда — это не те самые люди с хваленым советским образованием и воспитанием? Может, я просто хочу видеть улучшение, и выдаю желаемое за действительное, но субъективно сейчас комфортнее живется.

А потом пароль срочно понадобился вам в другом городе… Возить шкафчик с собой? Или, не дай бог, пожар, и нет больше вашего шкафчика, его бэкапить нужно было… Да и этот шкафчик ничем принципиально не отличается от менеджера паролей: ваш хитрый алгоритм + фото = шифрование + мастер пароль, шкаф = база с паролями. Так что и эта схема не лишена серьезных недостатков. Идеального пока не придумали ничего, каждый должен для себя решить, какие риски для него приемлимы, а какие нет.

1) Все пароли лежат в одном месте. «Не храните все яйца в одной корзине» по понятным причинам. Да и цель злоумышленников, которые знают что вы пользуетесь менеджером паролей теперь очевидна.

Можно использовать несколько баз.


2) Если в одном из менеджеров паролей найдут багу, то вы просто попадете под волну аттак.

Да, это минус, спору нет. Остаётся надеяться на то, что такие продукты сильнее защищены, чем рядовые продукты, от которых пароли в нем хранятся.

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

Так у всех сервисов разные требования к паролям. Одним нужны разные регистры, специальные символы, цифры, другим ещё какие-то требования… На всех не угодишь. А потом перебирай эти 20 фраз на сервисе, в котором ты зарегистрировался год назад и больше не заходил, а после 5 неудачных попыток тебя банят… Так себе удовольствие тоже.

Прекрасно! Еще вспомнилось:


Три забегаловки рядом. На первой вывеска — "Лучшие бургеры в стране". На второй — "Лучшие бургеры в мире". На третьей — "Лучшие бургеры на этой улице".

Да ради бога, как удобнее в вашей ситуации, так и делайте. Логин скорее всего не нужен так как совпадает с текущим обычно, порт как правило дефолтный, пароль либо запрашивается либо не нужен если по ключам авторизация идёт, каталог может быть ~/ или /tmp, имя сервера копируется из соседней вкладки консоли, ведь вам и так надо залогиниться туда чтобы продолжить работу и вы его так и так знаете… Так что в моём типичном случае всё ограничивается "scp patch server2:~/".


Если в вашем случае это получается сложнее, то спокойно не используйте, как будто вас кто-то заставляет делать именно так и никак иначе. Если в какой-то ситуации этот прием пригодится — хорошо. Не пригодится — тоже хорошо. Удобнее тыкать мышкой — да пожалуйста. Нужно пользоваться тем, что привычно и удобно.

Просто в применении dif'а вместо git'а я вижу первый шаг к тому, чтобы предложить создать zip-архив с git репозиторием и тащить его домой на флешке. И всё ради красоты в твоей личной ветке репозитория.

Это не так. Во-первых, не вместо git'а, а с его же помощью, это часть его функционала. Во-вторых, вариант с diff-ом я предложил как ещё один альтернативный вариант (не основной) применительно к одной конкретной ситуации — когда вам нужно быстро переключиться с одной машины на другую с минимумом телодвижений и без необходимости делать временные коммиты, добавлять файлы в них и придумывать для этих временных коммитов комментарии типа WIP. Такой ведь был изначально вопрос? Применять это для чего-то ещё я смыла не вижу. Каким боком это ведет к zip-архиву на флешке, я тоже не понимаю.


Атомарность коммита это очень хорошо, но работает только когда программист сидит за рабочим местом круглые сутки и никогда не переключается от своей задачи к другой. А что делать, если при реализации какой-то фичи в коде тебе вдруг приходят и говорят срочно исправить баг в другой твоей фиче? Неужто клонировать проект в другое место? Если работник уезжает в отпуск, не доделав фичу? Если офис переезжает? Если проходит плановый апгрейд рабочего места?

Не понимаю, в чем проблема-то? Значит делаете коммит в том состоянии, как есть сейчас, и переключаетесь на другую задачу. Если нужно ехать в отпуск или кто-то другой будет это допиливать — пушите этот коммит в отдельную ветку на сервере. Локально / на неофициальных ветках можно творить что угодно. Но перед мержем в мастер / релиз хорошим тоном считается всё причесать, хотя бы из чувства уважения перед коллегами, которым придётся через год в этом копаться.

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


Я отношусь к системе Git как к инструменту, а не как к идеальной летописи, и поэтому допускаю в таких случаях неатомарные коммиты на неосновных ветках. При желании можно делать rebase --interactive и исправлять историю. Можно даже создавать отдельную ветвь на каждый неатомарный коммит, а потом объединять такие коммиты, как надо.

Так я то же самое и написал в первую очередь, как основной вариант.


Но, имхо, в этом немного смысла.

Смысл лишь в поддержании порядка и удобстве потом, когда надо change log собрать или что-то откатить. Откатывать атомарные коммиты куда проще.


Насчёт второго варианта, быстрее и удобнее — не всегда, бывает наоборот, сравните:


git status
git add file1 file2 file3 fileN
git commit 
git push

и


git diff > patch
scp patch ...

Использовать commit -a чтобы автоматически все файлы добавить не всегда прокатывает, потому что бывает что есть левые изменения, которые не нужны в коммите, и тогда либо добавлять все нужные файлы руками, либо commit -a и их потом придётся выковыривать с помощью всяких там ресетов и интерактивных ребейзов. Поэтому что "быстрее, надёжнее, удобнее" зависит от ситуации.


Применяйте то, что знаете, и то, что вам удобнее.

Да никто никому ничего не должен, это лишь рекомендации, но ведь так проще: не надо переводить на русский термины из предметной области, имена классов и функций. Когда всё на одном языке, как-то проще работается, избегаются проблемы неточного перевода, да и потом, когда команда разрастется или изменится, поддержку продукта передадут в другую, не русскоязычную команду или даже компанию, будут проблемы. Но если с английским совсем уж туго, то пожалуйста. Процессы должны помогать, а не наоборот. Если это создаёт больше проблем, чем решает, то игнорируйте данный совет. Это лишь набор рекомендаций.

Если вы работаете с этим репозиторием один, то ничего плохого, дело ваше. Но надо уважать своих коллег, я считаю, иначе как потом анализировать историю изменений среди всего этого мусора? Коммит должен быть атомарным, то есть состояние системы должно быть законченное в какой-то степени. И не должен содержать побочных изменений, только что-то неразрывно связанное между собой. Это делается в том числе для того, чтобы можно было легко что-то откатить в случае необходимости, не затрагивая лишнее, и чтобы при этом система осталось рабочей.

Information

Rating
Does not participate
Location
Нижний Новгород, Нижегородская обл., Россия
Registered
Activity