Чтобы получить пятно в 5мм на расстоянии в 10км для, допустим, длины волны 555нм (видимый, зелёный), ваша фокусирующая система линз должна иметь диаметр основной линзы объектива примерно 35см.
Для расстояния в 20км нужно либо согласится на линзы вдвое шире, либо на пятно у цели вдвое шире, либо уменьшить длину волны вдвое (уже невидимый ультрафиолет). Ну, и так далее для 100-200км.
PS кстати, вот видео на котором нечто похожее наглядно изображено. Обратите внимание, как на 14:00 там подстраивают длину фокусировки.
Я тоже усмехнулся, мол, автор нашёл пример "попроще", чтобы знакомиться с докером. Но ничего, дожал до конца, показал нюансы с jdk и jre. Можно ведь и в другую крайность податься:
Берете ваш статически-линкованный бинарь (откуда он взялся, оставим за скобками).
Вы и ваш оппонент оба правы. Мне, безусловно, приятнее работать с человеком, который мыслит как вы, но я отдаю себе отчёт, что, скажем, можно нанять "девопса", который знает ноль целых, хрен десятых про айти и линуксы в широком смысле, но он решит 99% проблем разработки, которые сводятся к какой-нибудь банальщине, типа "ошибся с отступами в ямл-файле" и бизнесу будет норм.
А для реально важных вещей можно раз в полгода привлечь достойного спеца, который ни за что в ваше болото работать не пойдёт, но по старой дружбе выручит советом.
Простите, осуждаю. Возникло впечатление, что разработчик познал дзен хороших практик в разработке и побежал в отдел датасатанистов, дабы открыть им истину. Творческий процесс в науке (будь это наука о данных или о чём либо ещё) немного не так работает. Зачастую, глубоко плевать на версионирование 95% итераций (а если так параметры подкрутить? А сяк? А если ещё слой нейронов добавить?) Ещё 4% наиболее интересных попыток будут сохранены, чтобы вернуться к ним и/или кому-то показать. Наконец, оставшийся 1% будет признан удачным и, вероятно, на его основе уже напишут какое-то более чистое решение для продакшена, в котором уже будут применяться подходы из разработки. Но это уже будет самая простая часть работы, после всех предыдущих мучений.
Я наоборот, чтобы кандидат не гадал, чего мне не понравилось в его ответах и "вообще, чего этого душнилу не устроило", всегда стараюсь рассказать кандидату правильный ответ на вопрос, если он ответил плохо или неправильно.
ситуация с несколькими разработчиками на собеседовании (если вас допрашивают на протяжении часа 3 человека - сделайте вывод о тайм-менеджменте компании)
А меня бесит, когда меня собеседует большой начальник, с которым я потом пересекаться раз в месяц буду. Совершенно нет возможности понять, в какой коллектив я вольюсь. Идеально, когда собеседующие - это мой будущий тимлид плюс 1-2 инженера, с которыми мне предстоит в одной команде работать.
Причин проходить собеседования -- вагон и маленькая тележка: - Дорваться до технического специалиста/нанимающего менеджера, который гораздо лучше рекрутёра обрисует внутреннюю кухню. - Оттачивать навык прохождения собеседований. - Быть в курсе, что нынче спрашивают на собеседованиях, что востребовано. - Оценить собственную стоимость, свои сильные и слабые стороны. - Получить оффер для обоснования повышения з/п на текущей работе.
В разговоре или переписке с вами будет общаться только рекрутёр, причём в переписке он, с большой вероятностью, поленится писать многобукафф.
Если человек настолько не проштудировал вопрос, что даже не смог скачать Bolt для такси, то я не удивлён, что у него такой плохой экспириенс по всем пунктам.
Работодателю разрушить миф Но.2 ничего не стоит, кроме как проглотить свои собственные надуманные ограничения. Но это значит, что линейный менеджер должен не зассать, а пойти к начальнику или даже к начальнику начальника и попросить своим личным согласованием разрешить текущему джуну поднять зп до мидла, нежели нанимать мидла за полтора ценника. Очевидно, что хороших менеджеров, которые не ссут открывать дверь начальства с ноги и требовать необходимое в разы меньше, чем мидлов.
Если тимлид не может выбить заслуженное повышение подчинённому, он не дорабатывает. Если тимлид может, а это просто начальство такое недалекое, то его везде с руками оторвут и он сможет быстро найти работу с более дальновидным начальством.
Мир изменчив, гит не может сохранить все детали реализации вселенной вокруг себя.
Вывод - гитопс плохой, да здравствует CIops (во второй части статьи).
По моему, это какой-то детский идеализм, который не помогает продукту работать и приносить прибыль.
Автор сделал полезную тулзу и выложил в открытый доступ без регистрации и СМС? Боже, куда мир катится...
Спасибо!
Ясно, я принял пиктограмму роутера на вашей фотке за обсуждаемое устройство. Век живи...)
Как правило роутер так же выступает в роли днс сервера. Вот и резолвит mycloud.com в собственный ip, наверное.
Чтобы получить пятно в 5мм на расстоянии в 10км для, допустим, длины волны 555нм (видимый, зелёный), ваша фокусирующая система линз должна иметь диаметр основной линзы объектива примерно 35см.
Для расстояния в 20км нужно либо согласится на линзы вдвое шире, либо на пятно у цели вдвое шире, либо уменьшить длину волны вдвое (уже невидимый ультрафиолет). Ну, и так далее для 100-200км.
PS кстати, вот видео на котором нечто похожее наглядно изображено. Обратите внимание, как на 14:00 там подстраивают длину фокусировки.
Вам доводилось работать в компании, где куча очень сеньорных архитекторов в принципе не пишут код? Там рождаются очень интересные "решения".
Я тоже усмехнулся, мол, автор нашёл пример "попроще", чтобы знакомиться с докером. Но ничего, дожал до конца, показал нюансы с jdk и jre. Можно ведь и в другую крайность податься:
Берете ваш статически-линкованный бинарь (откуда он взялся, оставим за скобками).
FROM scratch COPY ./app /app ENTRYPOINT ["/app"]
docker build, docker run
???
PROFIT!!1
Что только люди не делают, лишь бы не
Кстати,
Тоже работает.
Вы и ваш оппонент оба правы. Мне, безусловно, приятнее работать с человеком, который мыслит как вы, но я отдаю себе отчёт, что, скажем, можно нанять "девопса", который знает ноль целых, хрен десятых про айти и линуксы в широком смысле, но он решит 99% проблем разработки, которые сводятся к какой-нибудь банальщине, типа "ошибся с отступами в ямл-файле" и бизнесу будет норм.
А для реально важных вещей можно раз в полгода привлечь достойного спеца, который ни за что в ваше болото работать не пойдёт, но по старой дружбе выручит советом.
Простите, осуждаю. Возникло впечатление, что разработчик познал дзен хороших практик в разработке и побежал в отдел датасатанистов, дабы открыть им истину. Творческий процесс в науке (будь это наука о данных или о чём либо ещё) немного не так работает. Зачастую, глубоко плевать на версионирование 95% итераций (а если так параметры подкрутить? А сяк? А если ещё слой нейронов добавить?) Ещё 4% наиболее интересных попыток будут сохранены, чтобы вернуться к ним и/или кому-то показать. Наконец, оставшийся 1% будет признан удачным и, вероятно, на его основе уже напишут какое-то более чистое решение для продакшена, в котором уже будут применяться подходы из разработки. Но это уже будет самая простая часть работы, после всех предыдущих мучений.
Я наоборот, чтобы кандидат не гадал, чего мне не понравилось в его ответах и "вообще, чего этого душнилу не устроило", всегда стараюсь рассказать кандидату правильный ответ на вопрос, если он ответил плохо или неправильно.
К слову, у многих есть отдельный этап собеседования с CTO или аналогичное, но уже к концу процесса. Это норм.
Не понял, вы мне оппонируете или просто доводите мысль до абсурда)
А меня бесит, когда меня собеседует большой начальник, с которым я потом пересекаться раз в месяц буду. Совершенно нет возможности понять, в какой коллектив я вольюсь. Идеально, когда собеседующие - это мой будущий тимлид плюс 1-2 инженера, с которыми мне предстоит в одной команде работать.
Причин проходить собеседования -- вагон и маленькая тележка:
- Дорваться до технического специалиста/нанимающего менеджера, который гораздо лучше рекрутёра обрисует внутреннюю кухню.
- Оттачивать навык прохождения собеседований.
- Быть в курсе, что нынче спрашивают на собеседованиях, что востребовано.
- Оценить собственную стоимость, свои сильные и слабые стороны.
- Получить оффер для обоснования повышения з/п на текущей работе.
В разговоре или переписке с вами будет общаться только рекрутёр, причём в переписке он, с большой вероятностью, поленится писать многобукафф.
А как быть, если работа не нужна, но всё же было интересно посмотреть, что предложат?
Если человек настолько не проштудировал вопрос, что даже не смог скачать Bolt для такси, то я не удивлён, что у него такой плохой экспириенс по всем пунктам.
В Китае рождаемость последние годы стремительно падает...
Работодателю разрушить миф Но.2 ничего не стоит, кроме как проглотить свои собственные надуманные ограничения. Но это значит, что линейный менеджер должен не зассать, а пойти к начальнику или даже к начальнику начальника и попросить своим личным согласованием разрешить текущему джуну поднять зп до мидла, нежели нанимать мидла за полтора ценника. Очевидно, что хороших менеджеров, которые не ссут открывать дверь начальства с ноги и требовать необходимое в разы меньше, чем мидлов.
Если тимлид не может выбить заслуженное повышение подчинённому, он не дорабатывает. Если тимлид может, а это просто начальство такое недалекое, то его везде с руками оторвут и он сможет быстро найти работу с более дальновидным начальством.