Возможно речь шла о какой-то очень специфической форме контракта типа open book, где подрядчик раскрывает свои затраты. Но и там все делается официально, через аудиторов, а не через конверты
Если говорить про бесплатные, то FreeCAD самый очевидный кандидат. Он конечно по юзабилити сильно уступает Солиду, но для проектирования простых корпусов его более чем достаточно. И у него есть отличный модуль для работы с листовым металлом
Еще есть Onshape он облачный и бесплатный для хобби-проектов, очень мощный
Золотой совет. Я бы даже сказал, что это не может быть, а должно быть. Пытаться сразу делать в металле, не проверив геометрию на дешевом макете просто сжигание денег и времени
Вся эта боль с поиском производства главная причина, почему DIY в металле почти мертв. С печатными платами все просто - загрузил герберы на сайт, оплатил, через неделю получил. А с металлом начинается квест- найди кто возьмется, согласуй цену (которую назовут с потолка), жди два месяца... Проще и быстрее купить готовый корпус и доработать его дремелем
Раст защищает от небезопасного доступа к памяти (гонки данных, висячие указатели), но он не может защитить от логических ошибок - если у тебя в коде баг, из-за которого ты пишешь в массив screen за его пределами, но при этом попадаешь в соседний массив memory, то с точки зрения раст все будет легально - работаешь в пределах выделенной тебе памяти, он не знает что эти два массива для тебя разные сущности
Проблемы с памятью, таймингами, прерываниями - все это решалось бы в разы быстрее, будь у вас с самого начала нормальный JTAG-отладчик. Но вы выбрали путь printf-дебаггинга, и в итоге каждый шаг превращался в многодневное детективное расследование
Как верно заметили выше главная ценность книги для новичка это структура. Она дает базу и правильный скелет знаний, а ИИ просто умный ассистент, который помогает решать уже конкретные задачи, когда база есть. Одно другому не мешает
Интересно на какую версию Flutter и Dart ориентирована книга, если они разбирают там какие-то фундаментальные вещи, которые не меняются, то может быть полезно, но если там есть примеры с использованием конкретных версий библиотек, то через год эти примеры просто перестанут компилироваться
В embedded мире часто приходится жертвовать идиоматичностью и красотой кода ради соответствия жестким ограничениям по памяти или производительности, пример с дешаблонизацией как раз из этой оперы - код становится чуть сложнее для чтения, но зато прошивка влезает в чип
Полезный разбор полезный, но хотелось бы увидеть больше цифр. Например, "включили флаг -Os - выиграли 200 КБ. Заменили std::visit - еще 50 КБ. Перешли с shared_ptr на unique_ptr - 30 КБ". Без этого сложно оценить реальный вклад каждого из методов
Идея понятна, но реализация вызывает массу вопросов. Кто будет платить за доработку биллингов операторов и систем всех ОРИ? Как именно ОРИ будет проверять этот статус? Через какой-нибудь API к госсистеме? Это же колоссальная нагрузка и еще одна точка отказа для половины рунета. Звучит как очередной дорогой IT-проект с очень туманным результатом
Все эти советы про 80% хороши для ноутбука, который 99% времени воткнут в розетку. Для смартфона, который должен дожить до вечера, это просто нереально. Проще смириться и через пару лет поменять батарею
Это база. Зарядка в диапазоне 20-80% - самый щадящий режим для литиевой химии. И то что производители начали добавлять эту функцию в настройки только в последние пару лет, - лучшее доказательство теории "запланированного устаревания"
На главный вопрос из заголовка "почему живут так мало?" ответ довольно размытый.
По сути, все сводится к "не перегревайте, не переохлаждайте, не разряжайте в ноль", это все итак знают, а вот почему у одного телефона батарея умирает за два года, а у другого живет пять при одинаковом использовании - про это почти ничего нет
Классический список вопросов, чтобы почувствовать себя умным на собеседовании и завалить кандидата. Вместо того чтобы дать простую бизнес-задачу и посмотреть, как человек ее решит, мы будем гонять его по @layer и will-change. Идеальный способ нанять теоретика, а не инженера
Возможно речь шла о какой-то очень специфической форме контракта типа open book, где подрядчик раскрывает свои затраты. Но и там все делается официально, через аудиторов, а не через конверты
Мораль: никакие нормы не заменят здравого смысла и понимания реальных процессов.
Если говорить про бесплатные, то FreeCAD самый очевидный кандидат. Он конечно по юзабилити сильно уступает Солиду, но для проектирования простых корпусов его более чем достаточно. И у него есть отличный модуль для работы с листовым металлом
Еще есть Onshape он облачный и бесплатный для хобби-проектов, очень мощный
Золотой совет. Я бы даже сказал, что это не может быть, а должно быть. Пытаться сразу делать в металле, не проверив геометрию на дешевом макете просто сжигание денег и времени
Вся эта боль с поиском производства главная причина, почему DIY в металле почти мертв. С печатными платами все просто - загрузил герберы на сайт, оплатил, через неделю получил. А с металлом начинается квест- найди кто возьмется, согласуй цену (которую назовут с потолка), жди два месяца... Проще и быстрее купить готовый корпус и доработать его дремелем
Была бы
Раст защищает от небезопасного доступа к памяти (гонки данных, висячие указатели), но он не может защитить от логических ошибок - если у тебя в коде баг, из-за которого ты пишешь в массив screen за его пределами, но при этом попадаешь в соседний массив memory, то с точки зрения раст все будет легально - работаешь в пределах выделенной тебе памяти, он не знает что эти два массива для тебя разные сущности
Вся история - отличная реклама хорошей отладки)
Проблемы с памятью, таймингами, прерываниями - все это решалось бы в разы быстрее, будь у вас с самого начала нормальный JTAG-отладчик. Но вы выбрали путь printf-дебаггинга, и в итоге каждый шаг превращался в многодневное детективное расследование
Поучительно, но не очень эффективно :)
Как верно заметили выше главная ценность книги для новичка это структура. Она дает базу и правильный скелет знаний, а ИИ просто умный ассистент, который помогает решать уже конкретные задачи, когда база есть. Одно другому не мешает
Интересно на какую версию Flutter и Dart ориентирована книга, если они разбирают там какие-то фундаментальные вещи, которые не меняются, то может быть полезно, но если там есть примеры с использованием конкретных версий библиотек, то через год эти примеры просто перестанут компилироваться
В embedded мире часто приходится жертвовать идиоматичностью и красотой кода ради соответствия жестким ограничениям по памяти или производительности, пример с дешаблонизацией как раз из этой оперы - код становится чуть сложнее для чтения, но зато прошивка влезает в чип
Ответ на ваш вопрос в самом начале статьи:
Овчинка стоит выделки, когда альтернатива - это сказать заказчику, что его дорогое железо больше не будет получать обновления
Полезный разбор полезный, но хотелось бы увидеть больше цифр. Например, "включили флаг -Os - выиграли 200 КБ. Заменили std::visit - еще 50 КБ. Перешли с shared_ptr на unique_ptr - 30 КБ". Без этого сложно оценить реальный вклад каждого из методов
Добро пожаловать обратно в эру CDMA, когда телефон нужно было прошивать у оператора - технологическая деградация под соусом безопасности
Идея понятна, но реализация вызывает массу вопросов. Кто будет платить за доработку биллингов операторов и систем всех ОРИ? Как именно ОРИ будет проверять этот статус? Через какой-нибудь API к госсистеме? Это же колоссальная нагрузка и еще одна точка отказа для половины рунета. Звучит как очередной дорогой IT-проект с очень туманным результатом
Все эти советы про 80% хороши для ноутбука, который 99% времени воткнут в розетку. Для смартфона, который должен дожить до вечера, это просто нереально. Проще смириться и через пару лет поменять батарею
Это база. Зарядка в диапазоне 20-80% - самый щадящий режим для литиевой химии. И то что производители начали добавлять эту функцию в настройки только в последние пару лет, - лучшее доказательство теории "запланированного устаревания"
На главный вопрос из заголовка "почему живут так мало?" ответ довольно размытый.
По сути, все сводится к "не перегревайте, не переохлаждайте, не разряжайте в ноль", это все итак знают, а вот почему у одного телефона батарея умирает за два года, а у другого живет пять при одинаковом использовании - про это почти ничего нет
от JS-разработчика это сильно
Это примерно как хирург, который не помнит, где находится сердце. Можно конечно и без этого знания резать, но как-то тревожно
- "Мы поддерживаем Safari 16"
- "Ок, тогда половину вопросов из списка можно вычеркивать, они неактуальны"
Классический список вопросов, чтобы почувствовать себя умным на собеседовании и завалить кандидата. Вместо того чтобы дать простую бизнес-задачу и посмотреть, как человек ее решит, мы будем гонять его по @layer и will-change. Идеальный способ нанять теоретика, а не инженера