Но что, если разделить ответственность за задание между руководителем и сотрудником?
Если за что-то ответственны несколько человек - то, пойди что не так, сразу начнётся blame game. Менеджеры в этих blame game собаку съели в отличие от работников. Поэтому статья выглядит как урок для менеджеров среднего звена как по-тихому переложить часть, а лучше всю ответственность на плохо соображающих в этих вещах работников.
Не, далеко не все. Например в моей текущей конторе споткнулись о проблемы с авторизацией в приватных pypi (нужный сценарий не поддерживался). В итоге pip, и полет нормальный.
Хардскиллы переоценены. Да, думаю сейчас это действительно так. Почти все разработчики большую часть своего времени создают микросервисы, суть которых в перекладывании json'ов из одного места в другое. Что касается творческих задач, их не так много, как хотелось бы.
Вы здесь причину со следствием путаете. Вакансий, где нужно "творить" действительно существенно меньше, чем тех, где нужно json по БД раскладывать. Но и людей с соответствующими хард и софт скилами - ещё меньше. Определённый уровень всех этих скилов в целом является необходимым минимумом на ту или иную роль.
И всякие вещи типа знания алгоритмов и структур данных, знания мат. статистики, и всякая подобная теория - всё это помогает предотвратить ошибки именно на раннем этапе проектирования. Без этого человек "натворит" так, что потом уж очень долго разгребать придётся.
Из моего опыта - человек с большим опытом но без знания этих самых структур данных (по его же признанию) наваял как-то для некоторого сервиса пред-заполнение кэша для поиска - сложный алгоритм со всякой денормализацией данных для последующей быстрой выдачи. В результате штука работала по несколько часов, тогда как свежие результаты поиска хотелось получать быстрее. Пара месяцев работы и рефакторинг в стиле "ArrayList.contains() замененить на Set.contains()" и кэш стал обновляться за 5 минут.
В целом, то что Вы описали - это middle engineer уровень без особых перспектив роста в senior+ engineer, зато с отличной возможностью вырости в engineering manager.
Почему нельзя использовать две камеры - одну для съёмок в ближнем инфракрасном свете, а другую с каким-нибудь узкополосным оранжевым фильтром? По-идее должно сильно повысить контраст объекта - в море не так много оранжевого плавает.
Хельсинки из исследования, это порядка Пскова по населению и по площади. Все эти меры в более крупных городах перестают работать при численности от примерно 1,5 млн в самом городе - но да, в ЕС таких городов раз, два и обчелся, и их не любят исследовать.
По опыту работы в одной из "крупных технологических компаний" такие продукты создаются как костыли внутри компании потому, что есть какие-то уникальные особенности компании, или потому, что за красивый новый продукт можно получить больше плюшек, чем за использование чего-то стороннего.
В какой-то момент продукты опенсорсятся в надежде, что кто-то ещё начнёт их использовать и, как следствие, вкладывать в поддержку/развитие.
Для сторонних контор же внедрять такое без переманивания хотя бы одного-двух исходных разработчиков - себе дороже.
Определяем N самых ярких точечных источников на фото. Каждая звезда достаточно хорошо описывается гауссианой
Берём каталог звёзд
С помощью триангуляции, нехитрой математики и доброго слова получаем однозначное направление инструмента, с которого фотографировали (даже тулза давно есть - https://www.astromatic.net/software/sextractor/)
По каталогу определяем звёзды, которые будут в поле зрения. По известным положениям проверяем, достаточные ли были условия для того, что бы увидеть звёзды.
Метод работает в очень плохих условиях, даже когда видно буквально несколько звёзд. Штука в том, что их взаимное расположение - вещь уникальная и заранее известная. По крайней мере пока мы не научились летать к другим звёздам:)
Справедливости ради zsh теперь default shell on MacOS. Но ровно из-за этого пришлось откатиться от bash к sh-compatible, что бы скрипты одинаково работали локально и на каком debian/centos/mandrake/whatever.
Ну как бы ЗЯТЦ включает в себя обычные реакторы. Доля бридеров в получаемой энергии примерно 20-25%. Поэтому так всё медленно идёт и только в России - зачем делать ЗЯТЦ, если U235 есть, его (относительно) много, а бридеры дороже и сложнее обычных реакторов?
Вообще считаю, что нужно ввозимый уран именовать не отработанным ядерным топливом, а топливом для реакторов-размножителей (breeder reactor fuel). Если название популяризировать, то на нытьё Гринписа можно гордо отвечать "Франция поставляет ядерное топливо в Россию!".
Если за что-то ответственны несколько человек - то, пойди что не так, сразу начнётся blame game. Менеджеры в этих blame game собаку съели в отличие от работников. Поэтому статья выглядит как урок для менеджеров среднего звена как по-тихому переложить часть, а лучше всю ответственность на плохо соображающих в этих вещах работников.
Не, далеко не все. Например в моей текущей конторе споткнулись о проблемы с авторизацией в приватных pypi (нужный сценарий не поддерживался). В итоге pip, и полет нормальный.
Ога. Только у профессора обычно прилично грантов - и рабочее место обустроить, и по стране и миру на конференции (почти равно отдыху) съездить.
Не software engineer конечно, но и не бедствуют далеко.
Неправильно вы стандарты пишите. Нужно `<meta name="agent-of" content="USA; agency=CIA" />`
Вы, стало быть, эти контракты изучили и готовы дать юридическую оценку изменений их исполнения?
Вот кстати РБ не отрабатывали как бы не чаще РН, если я не ошибаюсь.
Вы здесь причину со следствием путаете. Вакансий, где нужно "творить" действительно существенно меньше, чем тех, где нужно json по БД раскладывать. Но и людей с соответствующими хард и софт скилами - ещё меньше. Определённый уровень всех этих скилов в целом является необходимым минимумом на ту или иную роль.
И всякие вещи типа знания алгоритмов и структур данных, знания мат. статистики, и всякая подобная теория - всё это помогает предотвратить ошибки именно на раннем этапе проектирования. Без этого человек "натворит" так, что потом уж очень долго разгребать придётся.
Из моего опыта - человек с большим опытом но без знания этих самых структур данных (по его же признанию) наваял как-то для некоторого сервиса пред-заполнение кэша для поиска - сложный алгоритм со всякой денормализацией данных для последующей быстрой выдачи. В результате штука работала по несколько часов, тогда как свежие результаты поиска хотелось получать быстрее. Пара месяцев работы и рефакторинг в стиле "ArrayList.contains() замененить на Set.contains()" и кэш стал обновляться за 5 минут.
В целом, то что Вы описали - это middle engineer уровень без особых перспектив роста в senior+ engineer, зато с отличной возможностью вырости в engineering manager.
Почему нельзя использовать две камеры - одну для съёмок в ближнем инфракрасном свете, а другую с каким-нибудь узкополосным оранжевым фильтром? По-идее должно сильно повысить контраст объекта - в море не так много оранжевого плавает.
Хельсинки из исследования, это порядка Пскова по населению и по площади. Все эти меры в более крупных городах перестают работать при численности от примерно 1,5 млн в самом городе - но да, в ЕС таких городов раз, два и обчелся, и их не любят исследовать.
В Японии по закону работодатель оплачивает дорогу.
Ближайшее удобное место - обратная сторона Луны. Закинуть туда груз - сама по себе задача не простая.
Спутники гораздо проще перехватить: траектория известна сильно заранее, сами спутники гораздо больше и лучше видны в всех диапазонах.
У Linkedin — DataHub;
у Lyft — Amundsen;
у WeWork — Marquez;
у Airbnb — Dataportal;
у Spotify — Lexikon;
у Netflix — Metacat;
у Uber — Databook.
По опыту работы в одной из "крупных технологических компаний" такие продукты создаются как костыли внутри компании потому, что есть какие-то уникальные особенности компании, или потому, что за красивый новый продукт можно получить больше плюшек, чем за использование чего-то стороннего.
В какой-то момент продукты опенсорсятся в надежде, что кто-то ещё начнёт их использовать и, как следствие, вкладывать в поддержку/развитие.
Для сторонних контор же внедрять такое без переманивания хотя бы одного-двух исходных разработчиков - себе дороже.
Осталось только не нарисовать, а вышить крестиком…
Когда-то решал такую задачу без ИИ:)
Решение выглядело так:
Определяем N самых ярких точечных источников на фото. Каждая звезда достаточно хорошо описывается гауссианой
Берём каталог звёзд
С помощью триангуляции, нехитрой математики и доброго слова получаем однозначное направление инструмента, с которого фотографировали (даже тулза давно есть - https://www.astromatic.net/software/sextractor/)
По каталогу определяем звёзды, которые будут в поле зрения. По известным положениям проверяем, достаточные ли были условия для того, что бы увидеть звёзды.
Метод работает в очень плохих условиях, даже когда видно буквально несколько звёзд. Штука в том, что их взаимное расположение - вещь уникальная и заранее известная. По крайней мере пока мы не научились летать к другим звёздам:)
Справедливости ради zsh теперь default shell on MacOS. Но ровно из-за этого пришлось откатиться от bash к sh-compatible, что бы скрипты одинаково работали локально и на каком debian/centos/mandrake/whatever.
Ну как бы ЗЯТЦ включает в себя обычные реакторы. Доля бридеров в получаемой энергии примерно 20-25%. Поэтому так всё медленно идёт и только в России - зачем делать ЗЯТЦ, если U235 есть, его (относительно) много, а бридеры дороже и сложнее обычных реакторов?
https://t.me/ecologica1
Может и не корректно, но куда ближе к действительности, чем «отходы»;)
Это глава отрасли, ее лицо. Так что наоборот, нельзя не проецировать его поступки и слова.
Для тематического сообщества в телеге нарисовал этот процесс: https://drive.google.com/file/d/1VDESpAewloc6zpT77NS_NiSNnrIzDgmC/view?usp=sharing
Основная проблема: что Гринпис или какой схематозник (см. выше - https://habr.com/ru/company/itsoft/blog/583502/#comment_23592732 ) ляпнет за 2 минуты, можно опровергнуть только с числами.
Вообще считаю, что нужно ввозимый уран именовать не отработанным ядерным топливом, а топливом для реакторов-размножителей (breeder reactor fuel). Если название популяризировать, то на нытьё Гринписа можно гордо отвечать "Франция поставляет ядерное топливо в Россию!".