Photographers would adjust the exposure, aperture, and shutter speed.
Фотографы настраивали выдержку, диафрагму и скорость затвора.
Exposure переводится как экспозиция, а shutter speed - как выдержка.
За словосочетание скорость затвора нужно вообще бить по лицу учебником русского языка. К сожалению, сама фраза и в оригинале неправильно написана, т.к. экспозицией управляют через сочетание выдержки и "диафрагмы".
brightnesses can only vary by a few hundred degree
яркость которых меняется лишь на несколько сотен градусов
Яркость в градусах не измеряется. Degree - это не только градусы, но и степени, ступени, уровни. Здесь речь про то, что яркость пикселя на обычном мониторе варьируется от 0 до 256.
человеческое зрение более чувствительно к краям, чем к абсолютному освещению
Простите за откровенность, но в целом получился гугл-транслейт: обычные бытовые фразы переведены гладко. А сколько-нибудь специфичные тезисы превратились в бессмысленный набор слов.
автор указывал на нестойкость это жидкости к ультрафиолету, что потребовало бы полностью закрытого корпуса, а это противоречит моим требованиям к эстетике решения
обычное стекло не пропускает ультрафиолет
Водоблоки охлаждают только ту часть оборудования, к которой они прилегают, иммерсионное охлаждение же более равномерное
я бы это утверждение переформулировал: водоблоки снимают теплоту непосредственно в месте её формирования, а иммерсионное охлаждение равномерно нагревает все окружающие элементы
Проект основательный, сделано всё с вниманием к деталям. Очень круто!
gmail, yandex и многие другие почтовые сервисы позволяют наращивать свой адрес через +
например, письма направленные на v.pupkin+gosuslugi@gmail.com придут в тот же ящик, что и отправленные просто на v.pupkin@gmail.com. Главное, не использовать базовый адрес ни для каких нужд.
Найти упоминание регистрозависимости JSON в спецификации - еще более сложная задача
да ладно, это в rfc8259 описано отдельным параграфом:
8.3. String Comparison
Software implementations are typically required to test names of object members for equality. Implementations that transform the textual representation into sequences of Unicode code units and then perform the comparison numerically, code unit by code unit, are interoperable in the sense that implementations will agree in all cases on equality or inequality of two strings.
Escape-последовательности раскрываются в Unicode, а затем такие подготовленные строки бинарно сравниваются. Т.е. имена членов объектов регистрозависимы.
Больше похоже на какие-то негативные ассоциации второго порядка. Повелительное наклонение - вполне естественная форма в диалоге, в обращении к другому человеку, просьбе.
Вас же не смущает: "Подскажите, пожалуйста, как пройти", "Передайте, пожалуйста" и т.п.
"Прошу прощения" как раз выбивается и формой, и смыслом из типичного ряда обращений с просьбой к кому либо.
"Прошу прощения" - скорее отстранённая констатация факта. Формализм - вроде и про "прощение", но и без прямого обращения, без призыва к общению.
можно посвятить себя науке и не идти в армию. Правда, нужно периодически появляться в ВУЗе, писать какие-то работы.
можно посвятить себя семье - завести ребёнка, потом второго и не идти в армию
здоровых людей нет, есть недообследованные. В каждой шутке, есть доля правды, у многих реально есть проблемы со здоровьем и хронические заболевания, просто их игнорируют пока не станет поздно
у кого-то неполные семьи, больные родственники и т.п. - содержащие иждивенцев освобождаются от службы
не знаю, как сейчас, но лет -дцать назад были специаьные туры в Израиль(?) - служишь там в армии пару месяцев. И в России уже не подлежишь призыву, как служивший в другом государстве
Прочитал обе статьи, но так и не понял: что вы с этой "документацией" в итоге делаете?
С Word'ом, xml и т.п. понятны сложности, неудобства и прочая попо-боль, но понятно ради чего: есть небольшое количество соглашений по разметке: описывая пользовательский интерфейс клавиатурные комбинации обозначаем одним стилем, окна/формы - другим, пункты меню - третьим. В итоге "лёгким движением руки" получаем общий справочник клавиатурных комбинаций, а в печатном/гуёвом выводе они красиво отрисованы как кнопочки. Биндим это с файлами локализации - получаем заготовку для переводчика, где все видимые пользователю сущности уже переведены так, как оно есть в продукте.
Реализуем процессы-алгоритмы - в описании размечаем стилями/тэгируем: "контракты", высокоуровневые сущности предметной обрасти, детали реализации, обращения к сторонним компонентам/библиотекам. В итоге можем автоматически получить тезаурус решений для последующего переиспользования, какие-то FAQ по реализациям и использованию внешних компонентов.
AsciiDoc, насколько я понимаю, не подразумевает семантическую разметку, это просто текст слегка обогащённый красивостями.
Есть много модных слов типа "теории игр" и т.п., но если по простому, то каждая сторона делает то, что максимально рациональным образом принесёт ей выгоды. А прочие стороны могут либо что-то сделать, чтобы рациональным оказалось другое поведение; либо воспользоваться исходным поведением исходной стороны для уже своих выгод.
Что рядом с зоной конфликта чаще проходят учения, а боеготовность и концентрация войск на повышенном уровне - это ожидаемо. Особенно в сочетании с громки политическими заявлениями о признании независимости. Что план вторжения существовал - это тоже ожидаемо: в мирное время штабы только тем и занимаются, что заранее продумывают самые невероятные сценарии.
США прогнозировали войну именно сейчас не только и не столько потому, что разведка что-то увидела. А потому, что их аналитики пришли к выводу, что это - наиболее рациональный шаг со стороны России.
Зеленский говорил, что всё эти новые санкции нужно было вводить заранее, чтобы предотвратить. Возможно, чтобы предотвратить, нужно было отменять санкции. Ничего этого не было сделано потому, что см. первый абзац - прочим сторонам оказалось максимально выгодно спрогнозированное поведение, а не его предотвращение.
На этом глобусе царит закон джунглей, куда ни беги - вот что печально.
Экран хоть и крохотный, но сдвинут к лицу - почти полностью занимает поле зрения, примерно как сейчас 30" монитор.
...глаза наверное, можно на помойку относить уже через месяц работы. А для какого-нибудь терминала-каталога в библиотеке для эпизодического использования - прям круто.
Справедливости ради, - это разные скорости: в договоре с юриками всё же чаще прописывают гаранированную полосу пропускания до какой-либо точки обмена трафиком. А в договоре с физиками - скорость которую обещают специально не зарезать, а всё остальное - ну, как повезёт.
Сильно снижает уровень ИБ как раз подмена сертификата: шлюз/proxy становится точкой через которую проходят все пароли и прочая конфиденциальная информация проходят в открытом виде. Сам пользователь не в состоянии проверить достоверность целевого сайта. И вообще конечный пользователь перестаёт нести какую-либо отвественность, т.к. в итоге его данные может читать и подменять неопределённый круг лиц обслуживающий эти proxy подменяющие сертификаты.
Что касается удобства разработчиков на макбуках с sudo, упомянутого @shifttstas - вся эта свобода более-менее работает при разработке web-, облачных, всяких saas-сервисов, т.к. лицензии на код много чего позволяют для конечного использования. Если писать ПО для продажи - начинается ад учёта совместимости даже открытых лицензий.
нормальный историк, знает историю постройки Александрийского столпа
подлинная история постройки Александрийского столпа так же неизвестна: сам Монферран хранил "цеховой секрет" и оставил лишь эскизы и зарисовки в мелких деталях не всегда складывающихся в общую картину. А официальная история излишне драматизирована и больше напоминает художественный роман в духе соцреализма: сплошные превозмогания и трудовые подвиги.
SOAP работает не так. Обычно API сервиса описано в виде xml. SOAP-библиотека на клиенте формирует по этому описанию объекты/классы/пространства имён. Транспортный xml разработчик не видит, вопросов парсинга/формирования xml при типовом использовании SOAP нет, разработчик работает с готовыми языковыми сущностями.
Если взаимодействие по API в типовом случае предполагает атомарные операции, SOAP избыточен и тяжеловесен, разработчику разработчику сервиса стоит предпочесть REST-подход.
Если на клиенте нужна полноценная модель данных и предполагается постоянное разноплановое взаимодействие, при REST-подходе потребуется изобрести много велосипедов. Нередко, это берут на себя сами разработчики сервиса и предоставляют готовые велосипеды библиотеки для популярных языков.
Ага "какое-то левое приложение" - это запускаемая виртуалка; игра; редактор, в котором большой файл открываешь.
Помнится я так со Слаком и дружил: запускаешь сначала виртуалку, потом Слак. В обратном порядке не получается.
То, что падают новые приложения, а не старые, - чуть лучше в плане сохранности данных. Но всё равно подобные жадные алгоритмы создают неудобства для пользователей.
В значительной мере сам факт внедрения слегка взбодрил/мобилизовал сотрудников. Они стали внимательнее следить за настройкой скорости. Раньше "про запас" ручку регулировки поворачивали на пол-оборота, а теперь - на одно деление.
Exposure переводится как экспозиция, а shutter speed - как выдержка.
За словосочетание скорость затвора нужно вообще бить по лицу учебником русского языка. К сожалению, сама фраза и в оригинале неправильно написана, т.к. экспозицией управляют через сочетание выдержки и "диафрагмы".
Яркость в градусах не измеряется. Degree - это не только градусы, но и степени, ступени, уровни. Здесь речь про то, что яркость пикселя на обычном мониторе варьируется от 0 до 256.
Простите за откровенность, но в целом получился гугл-транслейт: обычные бытовые фразы переведены гладко. А сколько-нибудь специфичные тезисы превратились в бессмысленный набор слов.
обычное стекло не пропускает ультрафиолет
я бы это утверждение переформулировал: водоблоки снимают теплоту непосредственно в месте её формирования, а иммерсионное охлаждение равномерно нагревает все окружающие элементы
Проект основательный, сделано всё с вниманием к деталям. Очень круто!
ящик ≠ адрес
gmail, yandex и многие другие почтовые сервисы позволяют наращивать свой адрес через +
например, письма направленные на v.pupkin+gosuslugi@gmail.com придут в тот же ящик, что и отправленные просто на v.pupkin@gmail.com. Главное, не использовать базовый адрес ни для каких нужд.
да ладно, это в rfc8259 описано отдельным параграфом:
Escape-последовательности раскрываются в Unicode, а затем такие подготовленные строки бинарно сравниваются. Т.е. имена членов объектов регистрозависимы.
Больше похоже на какие-то негативные ассоциации второго порядка. Повелительное наклонение - вполне естественная форма в диалоге, в обращении к другому человеку, просьбе.
Вас же не смущает: "Подскажите, пожалуйста, как пройти", "Передайте, пожалуйста" и т.п.
"Прошу прощения" как раз выбивается и формой, и смыслом из типичного ряда обращений с просьбой к кому либо.
"Прошу прощения" - скорее отстранённая констатация факта. Формализм - вроде и про "прощение", но и без прямого обращения, без призыва к общению.
конечно, по простому "не хочу" не получится, но
можно посвятить себя науке и не идти в армию. Правда, нужно периодически появляться в ВУЗе, писать какие-то работы.
можно посвятить себя семье - завести ребёнка, потом второго и не идти в армию
здоровых людей нет, есть недообследованные. В каждой шутке, есть доля правды, у многих реально есть проблемы со здоровьем и хронические заболевания, просто их игнорируют пока не станет поздно
у кого-то неполные семьи, больные родственники и т.п. - содержащие иждивенцев освобождаются от службы
не знаю, как сейчас, но лет -дцать назад были специаьные туры в Израиль(?) - служишь там в армии пару месяцев. И в России уже не подлежишь призыву, как служивший в другом государстве
Наверняка, есть и другие способы решения вопроса.
входящие зависимости - incoming dependencies - это от чего зависит пакет, они левее от выделенного, с цифрой нуль
Прочитал обе статьи, но так и не понял: что вы с этой "документацией" в итоге делаете?
С Word'ом, xml и т.п. понятны сложности, неудобства и прочая попо-боль, но понятно ради чего: есть небольшое количество соглашений по разметке: описывая пользовательский интерфейс клавиатурные комбинации обозначаем одним стилем, окна/формы - другим, пункты меню - третьим. В итоге "лёгким движением руки" получаем общий справочник клавиатурных комбинаций, а в печатном/гуёвом выводе они красиво отрисованы как кнопочки. Биндим это с файлами локализации - получаем заготовку для переводчика, где все видимые пользователю сущности уже переведены так, как оно есть в продукте.
Реализуем процессы-алгоритмы - в описании размечаем стилями/тэгируем: "контракты", высокоуровневые сущности предметной обрасти, детали реализации, обращения к сторонним компонентам/библиотекам. В итоге можем автоматически получить тезаурус решений для последующего переиспользования, какие-то FAQ по реализациям и использованию внешних компонентов.
AsciiDoc, насколько я понимаю, не подразумевает семантическую разметку, это просто текст слегка обогащённый красивостями.
Есть много модных слов типа "теории игр" и т.п., но если по простому, то каждая сторона делает то, что максимально рациональным образом принесёт ей выгоды. А прочие стороны могут либо что-то сделать, чтобы рациональным оказалось другое поведение; либо воспользоваться исходным поведением исходной стороны для уже своих выгод.
Что рядом с зоной конфликта чаще проходят учения, а боеготовность и концентрация войск на повышенном уровне - это ожидаемо. Особенно в сочетании с громки политическими заявлениями о признании независимости. Что план вторжения существовал - это тоже ожидаемо: в мирное время штабы только тем и занимаются, что заранее продумывают самые невероятные сценарии.
США прогнозировали войну именно сейчас не только и не столько потому, что разведка что-то увидела. А потому, что их аналитики пришли к выводу, что это - наиболее рациональный шаг со стороны России.
Зеленский говорил, что всё эти новые санкции нужно было вводить заранее, чтобы предотвратить. Возможно, чтобы предотвратить, нужно было отменять санкции. Ничего этого не было сделано потому, что см. первый абзац - прочим сторонам оказалось максимально выгодно спрогнозированное поведение, а не его предотвращение.
На этом глобусе царит закон джунглей, куда ни беги - вот что печально.
Holborn прекрасен!
Экран хоть и крохотный, но сдвинут к лицу - почти полностью занимает поле зрения, примерно как сейчас 30" монитор.
...глаза наверное, можно на помойку относить уже через месяц работы. А для какого-нибудь терминала-каталога в библиотеке для эпизодического использования - прям круто.
вы статью читали?
С тем же успехом можно сказать про старые "закрытые старнции": конструктивно - обычные пилонно-стеновые. Просто в проёмах установлены двери.
неправда, станция "Зенит" (бывшая Новокрестовская) открытая в 2018 году - закрытого типа (по вашей терминологии).
ID довольно короткий, юные хекеры будут периодически зачищать чужие одноразовые записки простым перебором
Справедливости ради, - это разные скорости: в договоре с юриками всё же чаще прописывают гаранированную полосу пропускания до какой-либо точки обмена трафиком. А в договоре с физиками - скорость которую обещают специально не зарезать, а всё остальное - ну, как повезёт.
Сильно снижает уровень ИБ как раз подмена сертификата: шлюз/proxy становится точкой через которую проходят все пароли и прочая конфиденциальная информация проходят в открытом виде. Сам пользователь не в состоянии проверить достоверность целевого сайта. И вообще конечный пользователь перестаёт нести какую-либо отвественность, т.к. в итоге его данные может читать и подменять неопределённый круг лиц обслуживающий эти proxy подменяющие сертификаты.
Что касается удобства разработчиков на макбуках с sudo, упомянутого @shifttstas - вся эта свобода более-менее работает при разработке web-, облачных, всяких saas-сервисов, т.к. лицензии на код много чего позволяют для конечного использования. Если писать ПО для продажи - начинается ад учёта совместимости даже открытых лицензий.
подлинная история постройки Александрийского столпа так же неизвестна: сам Монферран хранил "цеховой секрет" и оставил лишь эскизы и зарисовки в мелких деталях не всегда складывающихся в общую картину. А официальная история излишне драматизирована и больше напоминает художественный роман в духе соцреализма: сплошные превозмогания и трудовые подвиги.
Сейчас у больших мониторов аппаратное разделение на два - чуть ли не дэфолтная фича.
Тяжелый случай.
SOAP работает не так. Обычно API сервиса описано в виде xml. SOAP-библиотека на клиенте формирует по этому описанию объекты/классы/пространства имён. Транспортный xml разработчик не видит, вопросов парсинга/формирования xml при типовом использовании SOAP нет, разработчик работает с готовыми языковыми сущностями.
Если взаимодействие по API в типовом случае предполагает атомарные операции, SOAP избыточен и тяжеловесен, разработчику разработчику сервиса стоит предпочесть REST-подход.
Если на клиенте нужна полноценная модель данных и предполагается постоянное разноплановое взаимодействие, при REST-подходе потребуется изобрести много велосипедов. Нередко, это берут на себя сами разработчики сервиса и предоставляют готовые
велосипедыбиблиотеки для популярных языков.Ага "какое-то левое приложение" - это запускаемая виртуалка; игра; редактор, в котором большой файл открываешь.
Помнится я так со Слаком и дружил: запускаешь сначала виртуалку, потом Слак. В обратном порядке не получается.
То, что падают новые приложения, а не старые, - чуть лучше в плане сохранности данных. Но всё равно подобные жадные алгоритмы создают неудобства для пользователей.
В значительной мере сам факт внедрения слегка взбодрил/мобилизовал сотрудников. Они стали внимательнее следить за настройкой скорости. Раньше "про запас" ручку регулировки поворачивали на пол-оборота, а теперь - на одно деление.