Не буду писать про 1992-й год, когда в ходу ничего особо и не было, кроме асма и паскаля.
Низкоуровневое программирование.
Микроконтроллеры — да.
Можно писать так, что понимаешь, как это транслируется без лишних затрат.
Плюсы были излишними.
Насколько это востребованно сейчас — невостребованно.
Только с очень редкими вакансиями, которых почти нет.
Да, гусеницы и колёса выглядят более надёжно. Но, судя по наблюдаемой эволюции, человек с руками и ногами оказывается более универсален. Залезет на что угодно, пройдёт через всё. И да, колёса, гусеницы и крылья, инструменты тоже не помешают как дополнение. Но руки и ноги более универсальны, думаю.
Ну, это же challenge.
Может, не очень практично сейчас, но перспективу имеет не плохую, думаю. Сложность задачи рождает сложные (думаю, чудовищно сложные) алгоритмы, конструктивные решения, наработки, те же патенты.
Spot — вполне себе удачная модель, по Марсу ходить сможет, домики строить, если немного подкорректировать. А ненадёжность механики — решаемо со временем, думаю.
Насколько я изучил его биографию, пытался понять его характер, ему это не интересно (на Земле). Тут и так разведётся куча компаний, сами собой, обычными бизнес-процессами, или через подрядчиков.
А вот на Марс они никогда не полезут. Кишка тонка. А ему интересно. (не идеализирую его, но так вижу, по делам)
Да, мечтатель (скорее всего с детства, воспитан на sci-fi). Как видел, он не говорил о окупаемости новых проектов, а просто чуствовал и шёл по наитию. Удача его преследовала, что необычно в нашем мире для «мечтателей».
По всем ним — особо никто из них не «мечтатель», или не получается (Безос), или денег нет (Ebay). Всем им удачи. Коммерция, расчёт, окупаемость в первую очередь, как я вижу, просто классический бизнес.
Не буду гадать, что Маск мог бы притаить в рукаве в плане освоения Марса, но его идеи мне импонируют. И это его деньги, не наши, не из бюджета РФ и прочее.
Ну, человек живёт мечтой, что не очень привычно для традиционных бизнесменов/управленцев, поэтому логика не очень вписывается в традиционные проекты типа «срубить бабла, залезть на холм, а потом доить» (AT&T, Microsoft, Amazon, Ebay etc).
Ну хочет, пусть делает, он таким видит мир. К тому же, видно, что он совсем не неудачник.
Он же ни у кого денег не просит, не так ли? А гнобить кого-то, кто думает не как все — это довольно старая традиция. От Да Винчи, до «мы его на бочку с порохом посадили, пущщай полетает».
Натрий всё ещё очень активно используется в «лампах, не предназначенных для освещения жилищ», например, в тепличных хозяйствах. И синий спектр там как раз очень важен. Но это же, формально, тоже лампа.
Только чистые изображения позволяют оценить состояние вегетации
Не помогут. Точнее, покажут, то, что уже всё невозвратимо плохо.
Идея хорошая, но это как запасной огнетушитель, если первый не сработал.
Первый огнетушитель — агроном — осмотр плантаций, этому его и учили. Цвет и характер листьев надо смотреть глазами, с земли, со спутников не видно. И есть возможность быстро подправить ситуацию, когда всё ещё не критично.
Я только по своему опыту скажу, кратко, и о том, что было по-другому:
Общение с клиентами.
Баг-репорты всегда приходят в основном от PM (не считая Sentry), т.к. прямой связи с клиентами не было. Закидывает тикет в Highest, и пили срочно.
расти в разные управленческие роли, вплоть до CEO
Да, это управленческая и коммуникативная профессия, в основном не техническая.
Написание требований к продукту и согласование функционала с командой разработки, согласование MVP.
Никогда не было. PM — не программист, ни с какого бока. Пишет, что надо сделать, как должно работать, и не более. Часто — без тикетов, на словах. Сам себе пишешь тикет, отправляешь на согласование, получаешь добро, и пилишь.
У нас PM выполнял роль Testing в Workflow, и было очень эффективно:
Ready => In Progress => Review => Testing (PM) => Deploy => Done.
Существуют сотни способов защиты программы, однако все они также имеют свой обход.
Золотые слова, защиты много не бывает.
Немного не в тему, больше по железу.
Был проект на PIC-контроллере, которые прошивались как EPROM. И его надо было защитить (16C622), денег и времени было вложено много. Там есть бит «CP (Code Protection)», которым ты навсегда лочишь считывание ROM. Ну, думаешь, что навсегда.
Сначала появились инциденты спиливания корпуса и фокусированного UV в ту точку кристалла, где хранился этот бит (word). Программа была в отдельном месте.
Microchip просекли это. Закрыли Me-слоем, который не пропускал UV. Потом «умельцы» научились аккуратно вскрывать корпус и стравливать этот защитный слой. Но стоило такое безумно дорого.
Применение всех этих методов защиты очень значительно увеличило время и ресурсы, необходимые на кряк нашей программы
Да, баланс нужен. Помню, как дизассемблировал программы под DOS известным дизассемблером. Всё было хорошо, когда программа была нормально собрана компилятором. Но если в неё натыкать ассемблерными вставками типа «засунуть в стек то, и это, и вызвать функцию по абстрактному адресу», то дизассемблер не мог показать нормальный листинг, ему башку сносило.
И про возраст — заметил.
Все отрицают, что это не важно, но это есть, негласно.
Мне 48, начинал с C на 286, но кому это сейчас интересно?
Советовали убрать даты из резюме. Так и поступлю.
Надо быть стильным, модным, молодёжным.
Okay, you'll get what you want to.
Когда ты устраиваешся как работник, ты смотришь со своей стороны. Да, к задачкам с leetcode уже готов. Про опыт рассказал. Код показал. Тестовое задание написал, сначала быстро, потом оптимально. По-душам пообщался. Ждёшь.
Когда ты teamlead, и надо собрать команду, чешешь репу — а как их найти? Придумываешь коварные вопросы для tech собеседования. По тестированию — фантазия по логике, которая никому не нужна. Только мозги претендента проверяешь. По практике — в каждой компании свои внутренние дела. Кони (промисы) в вакууме — тоже не о чём. «Как бы вы решили, если...» — более-менее нормально.
Нет пока решения этого вопроса.
Единственное — хотелось бы, чтобы HR'ы и собеседующие давали развёрнутый feedback.
И, понятное дело, ты можешь пройти собеседование, но не вписаться в компанию.
Под каждую систему (задачу) — свой подход.
Ну, например, невозможно впихнуть ARM везде, где только можно.
1. Во-первых, когда есть требования по потреблению — например, 80uA в спящем режиме, почти постоянным сном, просыпаешься только по внешним прерываниям или прерыванию от таймера, в остальное время ядро спит.
2. Планируется крупный тираж, и надо, чтобы было дёшево. Экономишь на железе на каждой копейке. Сравнивается твоё время на работу, «впихнуть в невпихуемое», и выбор компонентов на тираже.
3. В этом случае C++ — чисто для удобства, C — норма, ASM — круто, но долго. Пишешь код на C так, что в голове понимаешь, как оно будет компилиться. Ограничения по RAM и ROM.
Но это крайний случай, конечно. Но для дешёвых и энергоэффективных устройств распространён, в случае крупной партии.
(Начинал с PIC 16C622 N-дцать лет назад. Было очень критично. Архитектуру контроллера, ASM надо было знать на 200%, про схемотехнику не говорю. Запихнуть всё сложное в 2kW RAM, 128 bytes SRAM, 2kB EEPROM, эх… По 100_000 строк не было, каюсь)
Вот именно для этого скилл коммуникаций тоже нужен для Senior+.
Не чувствуй себя гуру.
Общайся с бэком (если ты на фронте).
Выноси на общие обсуждения, с первого раза, со второго.
Ты должен решить проблему в любом случае, и лучше, чтобы оптимально.
Даже если у тебя тяжёлые времена прям сейчас, и ты готов на меньшую зарплату. Будут считать, что ты сбежишь в любой подходящий момент. Это большая проблема — притвориться потупее, чем ты есть, когда чуствуешь это.
Сложилось устойчивое мнение, что для фронта это не надо никогда. Я про реализацию сортировки вручную, а не нативными методами .sort((el) => a — b).
На клиенте нет Big Data, и быть не должно.
Для этого есть Back End, там это может понадобиться, и нередко алгоритмы надо реализовывать руками в особых случаях с запутанными зависимостями. Это уже зависит от задачи, БД, заранее продуманной архитектуры.
Но в 1% это помогает и на фронте тоже иногда, когда он очень запутан. Не количеством данных, а сложностью алгоритма.
Вырастающее с возрастом чувство ответственности за детей и семью ни кто не отменял.
Кто-то и ядерные реакторы в гаражах изобретает, кто-то ракеты строит, чтобы доказать, что земля плоская, кто-то просто не очень психически здоров, оставаясь при этом профессионалом.
Ну, и программисты, как увлечённые и творческие люди, одни из них, наверное, с точки зрения общественности.
Низкоуровневое программирование.
Микроконтроллеры — да.
Можно писать так, что понимаешь, как это транслируется без лишних затрат.
Плюсы были излишними.
Насколько это востребованно сейчас — невостребованно.
Только с очень редкими вакансиями, которых почти нет.
Может, не очень практично сейчас, но перспективу имеет не плохую, думаю. Сложность задачи рождает сложные (думаю, чудовищно сложные) алгоритмы, конструктивные решения, наработки, те же патенты.
Spot — вполне себе удачная модель, по Марсу ходить сможет, домики строить, если немного подкорректировать. А ненадёжность механики — решаемо со временем, думаю.
Да и просто красиво, с этим сложно спорить.
А вот на Марс они никогда не полезут. Кишка тонка. А ему интересно. (не идеализирую его, но так вижу, по делам)
Да, мечтатель (скорее всего с детства, воспитан на sci-fi). Как видел, он не говорил о окупаемости новых проектов, а просто чуствовал и шёл по наитию. Удача его преследовала, что необычно в нашем мире для «мечтателей».
По всем ним — особо никто из них не «мечтатель», или не получается (Безос), или денег нет (Ebay). Всем им удачи. Коммерция, расчёт, окупаемость в первую очередь, как я вижу, просто классический бизнес.
Не буду гадать, что Маск мог бы притаить в рукаве в плане освоения Марса, но его идеи мне импонируют. И это его деньги, не наши, не из бюджета РФ и прочее.
Ну хочет, пусть делает, он таким видит мир. К тому же, видно, что он совсем не неудачник.
Он же ни у кого денег не просит, не так ли? А гнобить кого-то, кто думает не как все — это довольно старая традиция. От Да Винчи, до «мы его на бочку с порохом посадили, пущщай полетает».
Идея хорошая, но это как запасной огнетушитель, если первый не сработал.
Первый огнетушитель — агроном — осмотр плантаций, этому его и учили. Цвет и характер листьев надо смотреть глазами, с земли, со спутников не видно. И есть возможность быстро подправить ситуацию, когда всё ещё не критично.
Дроны были бы уместнее, думаю.
По вашему опыту.
Баг-репорты всегда приходят в основном от PM (не считая Sentry), т.к. прямой связи с клиентами не было. Закидывает тикет в Highest, и пили срочно.
Да, это управленческая и коммуникативная профессия, в основном не техническая.
Никогда не было. PM — не программист, ни с какого бока. Пишет, что надо сделать, как должно работать, и не более. Часто — без тикетов, на словах. Сам себе пишешь тикет, отправляешь на согласование, получаешь добро, и пилишь.
У нас PM выполнял роль Testing в Workflow, и было очень эффективно:
Ready => In Progress => Review => Testing (PM) => Deploy => Done.
С окошком было бы значительно по-проще.
Немного не в тему, больше по железу.
Был проект на PIC-контроллере, которые прошивались как EPROM. И его надо было защитить (16C622), денег и времени было вложено много. Там есть бит «CP (Code Protection)», которым ты навсегда лочишь считывание ROM. Ну, думаешь, что навсегда.
Сначала появились инциденты спиливания корпуса и фокусированного UV в ту точку кристалла, где хранился этот бит (word). Программа была в отдельном месте.
Microchip просекли это. Закрыли Me-слоем, который не пропускал UV. Потом «умельцы» научились аккуратно вскрывать корпус и стравливать этот защитный слой. Но стоило такое безумно дорого.
Да, баланс нужен. Помню, как дизассемблировал программы под DOS известным дизассемблером. Всё было хорошо, когда программа была нормально собрана компилятором. Но если в неё натыкать ассемблерными вставками типа «засунуть в стек то, и это, и вызвать функцию по абстрактному адресу», то дизассемблер не мог показать нормальный листинг, ему башку сносило.
Сейчас по-другому, наверное.
Все отрицают, что это не важно, но это есть, негласно.
Мне 48, начинал с C на 286, но кому это сейчас интересно?
Советовали убрать даты из резюме. Так и поступлю.
Надо быть стильным, модным, молодёжным.
Okay, you'll get what you want to.
Когда ты устраиваешся как работник, ты смотришь со своей стороны. Да, к задачкам с leetcode уже готов. Про опыт рассказал. Код показал. Тестовое задание написал, сначала быстро, потом оптимально. По-душам пообщался. Ждёшь.
Когда ты teamlead, и надо собрать команду, чешешь репу — а как их найти? Придумываешь коварные вопросы для tech собеседования. По тестированию — фантазия по логике, которая никому не нужна. Только мозги претендента проверяешь. По практике — в каждой компании свои внутренние дела. Кони (промисы) в вакууме — тоже не о чём. «Как бы вы решили, если...» — более-менее нормально.
Нет пока решения этого вопроса.
Единственное — хотелось бы, чтобы HR'ы и собеседующие давали развёрнутый feedback.
И, понятное дело, ты можешь пройти собеседование, но не вписаться в компанию.
Ну, например, невозможно впихнуть ARM везде, где только можно.
1. Во-первых, когда есть требования по потреблению — например, 80uA в спящем режиме, почти постоянным сном, просыпаешься только по внешним прерываниям или прерыванию от таймера, в остальное время ядро спит.
2. Планируется крупный тираж, и надо, чтобы было дёшево. Экономишь на железе на каждой копейке. Сравнивается твоё время на работу, «впихнуть в невпихуемое», и выбор компонентов на тираже.
3. В этом случае C++ — чисто для удобства, C — норма, ASM — круто, но долго. Пишешь код на C так, что в голове понимаешь, как оно будет компилиться. Ограничения по RAM и ROM.
Но это крайний случай, конечно. Но для дешёвых и энергоэффективных устройств распространён, в случае крупной партии.
(Начинал с PIC 16C622 N-дцать лет назад. Было очень критично. Архитектуру контроллера, ASM надо было знать на 200%, про схемотехнику не говорю. Запихнуть всё сложное в 2kW RAM, 128 bytes SRAM, 2kB EEPROM, эх… По 100_000 строк не было, каюсь)
Не чувствуй себя гуру.
Общайся с бэком (если ты на фронте).
Выноси на общие обсуждения, с первого раза, со второго.
Ты должен решить проблему в любом случае, и лучше, чтобы оптимально.
Over skilled тоже не любят.
Даже если у тебя тяжёлые времена прям сейчас, и ты готов на меньшую зарплату. Будут считать, что ты сбежишь в любой подходящий момент. Это большая проблема — притвориться потупее, чем ты есть, когда чуствуешь это.
Но сбежишь всё равно.
На такие темы я могу пообщаться, т.к. ФРТК МФТИ в лохматые годы.
Видимо, адресно ищут. Или по интересам.
Senior должен знать всё ).
На клиенте нет Big Data, и быть не должно.
Для этого есть Back End, там это может понадобиться, и нередко алгоритмы надо реализовывать руками в особых случаях с запутанными зависимостями. Это уже зависит от задачи, БД, заранее продуманной архитектуры.
Но в 1% это помогает и на фронте тоже иногда, когда он очень запутан. Не количеством данных, а сложностью алгоритма.