К сожалению, я сталкивался с такими ситуациями и сейчас могу точно сказать в чем проблема: вы не «программист от бога» и чтобы таки стать программистом вам надо жрать гранит зубами, компенсировать гибкость ума другими качествами (настойчивость, аккуратность, умение найти в интернете или книге ответ на вопрос). Т.е. правильно считать, что все остальные программисты имеют перед вами существенную фору и чтобы их догнать, вам надо приложить очень много усилий.
Подобные примеры случаются в любых отраслях — есть люди, которые могут без подсказок освоить любой музыкальный инструмент или по учебнику/ютубу за пару месяцев выучить иностранный язык. Или начать программировать в любом возрасте на любом языке. Если у вас этого нет, то это еще не крест, но работать придется очень много. Ну или выбрать другую профессию.
Вы знаете, это не такой уж и плохой ответ. Все-таки технологически тут и мобильная связь 4 поколений сразу, GPS + GLONASS, несколько сенсоров с десятками миллионов пикселей каждый, невероятная плотность хранения данных, сверчеткий дисплей. А как под эти телефоны пришлось инфраструктуру изменить-то — высокоскоростные сети везде, оптика между континентами, вышек мобильной связи больше, чем населенных пунктов в мире. Если раньше передовые разработки человечества были у военных и космической отрасли, то теперь они в кармане у каждого и поэтому стали видны и понятны даже спортсменам :)
А еще если 25 лет назад подобное спросить, то наверное ответили бы про автомобиль или микроволновку.
Когда-то мой знакомый ПМ в шутку сформулировал термин превентивное планирование — обработка и переформулирование задачи таким образом, чтобы ее можно было решить без написания программы :)
Алгоритм все так же применяется, просто на другой стадии — на подготовке данных. Т.е. наша инженерная школа подразумевает очень простое и точное решение этой задачи — «видишь не-СИ значение, приведи его к СИ». В данной формулировке задача решается в два умножения. То, чего хочет автор — решение с помощью графа — нам кажется нелогичным, но при этом нормально такой подход использовать для разворчивания намайненных данных в таблицу, т.е. на подготовительном этапе. Тут уже можно проявить фантазию в поиске наименьшего количества конверсий, проставлении коэффициентов достоверности и т.д. Но конкретно представители нашей школы на этом собеседовании будут ошеломлены и обескуражены, ведь это уровень средней школы.
Ну тут я вам не отвечу, я у гугла не был на собеседовании :)
Здравый смысл говорит о том, что рациональные числа в boost появились в 1999году. Через 20 лет реализовывать их заново это, кхм, странно. Ну может только чтобы впечатлить собеседника.
Во-первых, кустарной реализации на собеседовании (да и в коммерческой разработке) быть не должно, потому что рациональные дроби не делал только ленивый. Если говорить о .Net, то разумно использовать, н-р, Rationals.Net, где числитель и знаменатель задаются BigInteger — оберткой вокруг массива чисел, без ограничений по размеру и порядку. Для C++ берем cpp_rational с такими же свойствами.
Во-вторых, дробь с e-17 это совсем не много, задается 64-битными числами, пусть и близко к пределу.
В-третьих, при некотором желании (и желании сделать пару велосипедов) можно использовать представление с мантиссой и экспонентой (даже тот же double) и в рациональных дробях. Ошибка будет накапливаться только при очень большой разнице между исходной и результирующей величиной (ангстремы в парсеки).
Но задача отлично решается при наличии полной таблицы преобразований в метры. Значит перед работой надо неполную таблицу сделать полной, это подготовительная операция. А само преобразование уже потом делается в два умножения. Конечно, мы можем где-то потерять точность из-за количества операций с плавающей запятой, но это тоже решаемо, н-р, рациональными дробями.
Спасибо за перевод!
Эта статья подводит нас к очень интересной проблеме: американцы привыкли работать с несистемными размерами, поэтому для них естественно использовать цепочку преобразований для перевода попугаев в футы. Первое же, что приходит в голову человеку, знакомому с СИ — перевести все единицы в СИ и назад. Никакого графа, поиска в глубину и т.д. — все «общеизвестные преобразования» должны быть заранее вбиты в таблицу с коэффициентами вроде «1 фут = 0.3048 метра» и все вычисления должны происходить через метры. Если у нас нет таблицы таких «общеизвестные преобразований» в метры и программа стартует с пустой таблицей, то первым делом ее надо «обучить», наполнив эту таблицу. Если данные для обучения выданы в произвольном порядке, то их надо отсортировать так, чтобы они всегда опирались на уже существующие преобразования.
В любом случае, финальное вычисление после этого будет делаться в два умножения. Я просто не могу себе представить как у автора получился «интуитивный подход», это для нас совершенно неестественно.
Вы сделали bash скрипт, который шлет что-то с помощью sendmail и curl GET запроса, а затем добавили его в cron? Ну ок, а в чем была проблема? Все-таки это буквально самые азы администрирования под Linux/Unix, даже не пришлось подымать отдельные службы для этого.
P.S. Прочитал первые 5 слов заголовка как существительные и подумал непонятно что.
Моя история про Змейку.
В 91м году один из компьютерных журналов напечатал листинг Nibbles на QBasic. На то время у меня был ЕС1840 с GW-Basic на дискете с MS DOS, катастрофическая нехватка игр и неуемный оптимизм 8-летнего ребенка. Несколько дней я кропотливо перебивал код из журнала и исправлял опечатки, чтобы в итоге узнать, что инструкции QBasic и GW-Basic не полностью совместимы и код в принципе не запустится — обязательно нужны номера строк, отличаются некоторые операторы, а команда PLAY почему-то не издает звук и ее пришлось комментировать. Так я сделал первый в своей жизни порт. И понеслось :)
Конечно, использовать любой инструмент можно так, что выйдет какашка. Да и инструмент может быть не подходящий. Но опрометчиво говорить «да ну, не буду тянуть чужую либу, сделаю два сокета, проброшу по-быстрому сериализацию, прикручу шифрование и будет отличный сервер». Не будет. И в худшем случае вы это осознаете в продакшене.
Есть некоторые исключения, есть люди с огромным опытом, есть задачи, под которые ну никак не подойдет существующий продукт. А есть и грустные истории вроде онлайна Fallout 76 в 24 человека на сервер, который преподносится как игровая фича.
Если вы хотите сделать свой сетевой сервер, применяется правило такое же, как с желанием сделать игровой движок: не делайте этого! Скорее всего, с первой попытки у вас получится неповоротливый монстр, с кучей ошибок. Нужны годы, чтобы приблизиться по проработке и возможностям к какому-нибудь Photon Game Engine (или к Unreal Engine в случае 3д движка). И даже через годы вы все-равно будете находить ошибки из-за собственной реализации movement prediction или лаги из-за потери порядка udp пакетов. Массовое тестирование на сотнях проектов и десятках тысяч игроков вам тоже будет не доступно в большинстве случаев.
P.S. Потратил 15 лет жизни на собственный серверный и игровой движки.
Работают фултайм, получают по договоренности как парт тайм (с разными нюансами, долями и исключениями). Финансирую за счет моих личных проектов, которые еще не совсем слились. В целом, ситуация как у автора статьи — можно делать только финансово взвешенные шаги и если взять, н-р, художника из США на его обычную зарплату, то вся «подушка» закончится через два месяца, а игра еще не будет готова.
Переделка — ок, выглядит добротно и надежно. Правда, не смог прорваться сквозь дебри текста в поисках того, сколько часов будет заряжаться АКБ в 10-20 раз большей емкости, чем штатная. При таких доработках еще и зарядник принято переделывать, с возможностью выставления точных напряжений и таймингов.
Датчик Холла вместо шунта — ну в целом тоже сойдет, если точность не очень важна или он идеально откалиброван. Судя по тому, что он у вас не меряют токи меньше 0.1А, о точности тут речи нет.
Использование стартерной батареи, «чтобы было дешевле», но при этом впиливание туда измерительной станции за 2500р — в целом странно, не говоря о трудозатратах. Но этот как раз классная тема для обсуждения на Хабре, не бывает на 100% совпадающих точек зрения и это было бы нормально обговаривать в комментах, если бы не последний пункт.
Статья — не ок. Вам написали выше почему. В статистике голосов видно, что многие просто ставят вам минус за стиль и высокомерие, да и влазить в обсуждение после такого тона не очень хочется — дерьмом польют и спасибо не скажут.
Ну все же не в одного, нет. У меня есть художник, геймдизайнер, финансист, веб-программер и с недавних пор еще один программер клиента. Не сверх-опытные спецы и работают на удалёнке, но я в любом случае не могу сказать, что тяну «в одного».
Это весьма интересно! Зачастую инсайдерские рассказы пишут программисты, их текст информативен, но не всегда захватывает. У вас же получилось отлично передать эмоции и атмосферу, хотя и информативность не на высоте. Поэтому мы ждемжаждем продолжения :)
Однажды добрый дядя подарил 5-летнему карапузу дискету на 1.2 мегабайта, чтобы туда помещался Принц Персии и пара других игр целиком. Потому что карапуз приходил к маме на работу, дожидался, пока освободится ЕС1840 с двумя дисководами, доставал две дискетки, одну на 360кб, другую на 800кб, доставал засаленную бумажечку и набирал, высунув язык: a:
800.com
b:
mkdir prince
cd prince
pkunzip a:\prince.zip
prince.exe
Ну а после игры удалял, потому что места было мало. Да и дискетка на 800 долго не жила. Правда, и дискетка на на 1.2 тоже долго не прожила :)
30 лет прошло, а я все еще иногда пользуюсь зипом.
После установки WinG + Win32S можно было запускать некоторые программы даже от NT, а потом и 95й! Это был невероятный прорыв, особенно там, где замена ОС была запрещена.
Подобные примеры случаются в любых отраслях — есть люди, которые могут без подсказок освоить любой музыкальный инструмент или по учебнику/ютубу за пару месяцев выучить иностранный язык. Или начать программировать в любом возрасте на любом языке. Если у вас этого нет, то это еще не крест, но работать придется очень много. Ну или выбрать другую профессию.
А еще если 25 лет назад подобное спросить, то наверное ответили бы про автомобиль или микроволновку.
Здравый смысл говорит о том, что рациональные числа в boost появились в 1999году. Через 20 лет реализовывать их заново это, кхм, странно. Ну может только чтобы впечатлить собеседника.
Во-вторых, дробь с e-17 это совсем не много, задается 64-битными числами, пусть и близко к пределу.
В-третьих, при некотором желании (и желании сделать пару велосипедов) можно использовать представление с мантиссой и экспонентой (даже тот же double) и в рациональных дробях. Ошибка будет накапливаться только при очень большой разнице между исходной и результирующей величиной (ангстремы в парсеки).
Эта статья подводит нас к очень интересной проблеме: американцы привыкли работать с несистемными размерами, поэтому для них естественно использовать цепочку преобразований для перевода попугаев в футы. Первое же, что приходит в голову человеку, знакомому с СИ — перевести все единицы в СИ и назад. Никакого графа, поиска в глубину и т.д. — все «общеизвестные преобразования» должны быть заранее вбиты в таблицу с коэффициентами вроде «1 фут = 0.3048 метра» и все вычисления должны происходить через метры. Если у нас нет таблицы таких «общеизвестные преобразований» в метры и программа стартует с пустой таблицей, то первым делом ее надо «обучить», наполнив эту таблицу. Если данные для обучения выданы в произвольном порядке, то их надо отсортировать так, чтобы они всегда опирались на уже существующие преобразования.
В любом случае, финальное вычисление после этого будет делаться в два умножения. Я просто не могу себе представить как у автора получился «интуитивный подход», это для нас совершенно неестественно.
P.S. Прочитал первые 5 слов заголовка как существительные и подумал непонятно что.
В 91м году один из компьютерных журналов напечатал листинг Nibbles на QBasic. На то время у меня был ЕС1840 с GW-Basic на дискете с MS DOS, катастрофическая нехватка игр и неуемный оптимизм 8-летнего ребенка. Несколько дней я кропотливо перебивал код из журнала и исправлял опечатки, чтобы в итоге узнать, что инструкции QBasic и GW-Basic не полностью совместимы и код в принципе не запустится — обязательно нужны номера строк, отличаются некоторые операторы, а команда PLAY почему-то не издает звук и ее пришлось комментировать. Так я сделал первый в своей жизни порт. И понеслось :)
Есть некоторые исключения, есть люди с огромным опытом, есть задачи, под которые ну никак не подойдет существующий продукт. А есть и грустные истории вроде онлайна Fallout 76 в 24 человека на сервер, который преподносится как игровая фича.
P.S. Потратил 15 лет жизни на собственный серверный и игровой движки.
ждемжаждем продолжения :)a:800.com
b:
mkdir prince
cd prince
pkunzip a:\prince.zip
prince.exe
Ну а после игры удалял, потому что места было мало. Да и дискетка на 800 долго не жила. Правда, и дискетка на на 1.2 тоже долго не прожила :)
30 лет прошло, а я все еще иногда пользуюсь зипом.