На Android хоть нету большого количества запросов, но какой-нибудь ui тоже может заставить поломать голову - всякие рисовалки, до rv свои варианты кто-то пилил, drawable всякие по типу gif из glide, shimmer, progress view. Да и некоторые свои loader пишут (не все ktor/retrofit используют), а на сервере вроде это всегда часть фреймворка. В общем и логики хватает - кеширование всякое, некоторые автономные приложения до сих пор пилят.
Что мешает отдельно нарисовать настоящую битмапу и вырезать все в ней? Пусть и нативными средствами через Canvas() у Android? Да и у iOS я уверен есть что-то похожее.
При очень большом желании можно и byte array руками собрать, оно даже универсальные наверное будет.
А трансформации с жестами корректно работают? Я просто не очень в курсе. Если я помню, у меня не получилось заменить трансформацию внутри QML динамически - но я не qt программист.
Вероятно все проходят стадию реализации зуммирования. Я тоже делал, правда на не на qt.
Я верно понимаю, что виджет обернут в mouse area, т.е. если мы хотим не qwidget а qt quick то в целом подход тот же, сделали наследника от qquickpainteditem и обернули в mouse area, передали события?
Что flutter, что qt выходят за пределы именно Авроры. Да, они имеют специфику - qt имеет силику, что там во flutter не интересовался, но технически писать на них можно и под что-то другое. На ПК например на qt писать можно вообще без проблем.
Прям более бесполезную статью ещё поискать если честно. Это точно статья о том как писать приложения - на qt, flutter, kt multiplatform что-то не видно ни строчки кода. Как не видно разборов нюансов разработки под мобильный Линукс вообще и Аврору с ее песочницей в частности.
Я честно говоря делал не точно такие (обрезку руками не реализовывал), но похожие с точки зрения требований (отрисовка произвольных фигур и paths), и не до конца понял зачем вам нужны матрицы? Ну т.е. тема интересная, я бы с удовольствием сам бы почитал, но разве у flutter нет методов translate и scale которые это могут под капотом сделать?
Прямоугольник кстати прям на канвасе рисовать можно, не знаю как в flutter, но в compose есть drawWithContent, где можно нарисовать что-то своё поверх (или за) контентом. Во flutter тоже что-то похожее должно быть точно.
Так и я веду к тому же. Что 1с программист получает больше бухгалтера не потому что разбирается в предметной области лучше, а потому что кодить умеет. А тут рассказывают, что знание предметной области чуть ли не то, за что платят деньги.
Да кто угодно их пишет. Вы же понимаете что это машина состояний покрытая тестами со всех сторон. Ну и изначальный посыл автора был что платят не за навыки программирования а за знания в предметной области. Что я и пытался выяснить, что именно нужно какому-либо разрабу для iOS/Android пишущий интернет магазин к примеру от платежного шлюза? Ему(или специалистам сервера) дадут сдк и будут все с ним работать.
Я понимаю что писать систему управления платежами сложно, но насколько я понимаю основные проблемы в отсутствии багов и куче тестов, т.к. ошибки дороги, а не в сложной логике. Какая-нибудь СУБД будет посложнее, но это мое мнение, на ?% правильность не претендую.
Ну другими словами вы считаете, что если у вас есть хороший сотрудник, который доделал интернет магазин, а следующий заказ у вашей студии графический редактор (возьмём для удобства мобильное приложение, чтобы нельзя было утверждать, что это разные платформы), то первого сотрудника мы увольняем и ищем нового, с компетенциями в графике? Я верно вас понял?
Ну т.е. обычный неплохой разработчик вполне может за всю свою долгую карьеру не столкнуться с цос, я же верно понял, что свой sofdevice - я так понимаю, это что-то типа интерфейса в ООП - никогда писать не придется?
Не подумайте что я против знаний, вовсе нет. Но среднестатистическому неплохому разработчику решающему задачи бизнеса все это может же не понадобиться, судя по нашей беседе.
Любой реалтайм (а есть ли он в МК с конвейерами?) можно или на прерывании таймера написать, или сделать ассемблерную вставку - вроде у компиляторов для МК с этим проблем нет.
А разве подавляющее большинство rf устройств не строится по одной из следующих схем:
Ядро МК общается с внешним по отношению к нему устройством, находящемся в одном с ним корпусе - nrf24xxx
Вместе с МК поставляются скомпилированные библиотеки реализующие протокол, насколько я знаю nordic так делае
Если это так, то рядовой разработчик все равно не работает со всем этим матаном и типовая его задача это максимум pid
Что касается компилятора, то вроде хвостовые вызовы он оптимизировать умеет неплохо. Но я понимаю что вы имеете ввиду. Но в любом случае патчить код после компилятора мало кто будет, если он с регистрами не напорьачит какими-нибудь - к примеру нестандартный адрес списка векторов прерываний, который в программе надо перенести.
Ну т.е. вы считаете что json спарсить кратно легче? А свой парсер generic типа написать легче?
А какая вам нужна тензорная математика и что вам надо знать о dct? Что вы с цос делать собираетесь? Если вы мне хотите за фильтры и свертку рассказать, то их как минимум могут выполнять библиотеки. Но даже без них свёртка не очень сложная штука например.
Я не специалист ни в цос, ни в МК, но насколько я знаю цос на МК не самая частая задача. Ну т.е. оно конечно считается, но вот не каждый разработчик этим занимается. Да и библиотеки уже должны быть, но это мое предположение.
За фильтр признаю, т.к. это линейная система, чисто в теории он и цифровым может быть, но могут быть и не линейные системно схемотехнические решения.
Да и не думаю что рядовой программист МК будет антенну или трансформатор рассчитывать.
Что касается внутренней схемотехники, ну так она цифровая и да туда много кто лезет, но я уже встречал мнение что ассемблер знать например не надо, а он как раз к той самой схемотехнике прямо относится.
Ну иногда да, а иногда просто использует сдк и ничего не знает о внутрянке. Те же платежные шлюзы свое сдк дают, о платежах не известно ничего, но задача выполнена. Так что это как минимум не всегда так. А ещё часто проекты могут не совпадать от слова совсем - к примеру сегодня делаю интернет магазин, а завтра графический редактор. И что, программист на одном проекте хороший специалист, а на другом нет?
По вашему простой программист, который без всех вами перечисленных нюансов нормально зарабатывать не сможет? Ну тот который там архитектуру красиво разделяет, но ни в матан (линейную алгебру же в школе проходят, ну как минимум вектора и системы уравнений), ни в бух учёт не лезет. Странно это звучит, если честно. Потому что сервер можно писать без глубокого понимания складского порядка, а прося непосредственных работников проконсультировать. И, о боже, даже в каких-то особых специфичных вопросах, алгоритм могут запросить на стороне, например в университете. А программист МК может вообще в схемотехнику фильтров не лезть.
Так что можно развернуть вашу мысль про специфические знания?
Ну если статья про другое, то зачем вообще qa нужны логи? От qa вроде сам баг и порядок шагов для его выполнения требуется. Логи обычно разработчикам нужны, может я чего-то не понимаю, проясните?
На Android хоть нету большого количества запросов, но какой-нибудь ui тоже может заставить поломать голову - всякие рисовалки, до rv свои варианты кто-то пилил, drawable всякие по типу gif из glide, shimmer, progress view. Да и некоторые свои loader пишут (не все ktor/retrofit используют), а на сервере вроде это всегда часть фреймворка. В общем и логики хватает - кеширование всякое, некоторые автономные приложения до сих пор пилят.
Что мешает отдельно нарисовать настоящую битмапу и вырезать все в ней? Пусть и нативными средствами через Canvas() у Android? Да и у iOS я уверен есть что-то похожее.
При очень большом желании можно и byte array руками собрать, оно даже универсальные наверное будет.
А трансформации с жестами корректно работают? Я просто не очень в курсе. Если я помню, у меня не получилось заменить трансформацию внутри QML динамически - но я не qt программист.
Вероятно все проходят стадию реализации зуммирования. Я тоже делал, правда на не на qt.
Я верно понимаю, что виджет обернут в mouse area, т.е. если мы хотим не qwidget а qt quick то в целом подход тот же, сделали наследника от qquickpainteditem и обернули в mouse area, передали события?
Что flutter, что qt выходят за пределы именно Авроры. Да, они имеют специфику - qt имеет силику, что там во flutter не интересовался, но технически писать на них можно и под что-то другое. На ПК например на qt писать можно вообще без проблем.
Прям более бесполезную статью ещё поискать если честно. Это точно статья о том как писать приложения - на qt, flutter, kt multiplatform что-то не видно ни строчки кода. Как не видно разборов нюансов разработки под мобильный Линукс вообще и Аврору с ее песочницей в частности.
Я честно говоря делал не точно такие (обрезку руками не реализовывал), но похожие с точки зрения требований (отрисовка произвольных фигур и paths), и не до конца понял зачем вам нужны матрицы? Ну т.е. тема интересная, я бы с удовольствием сам бы почитал, но разве у flutter нет методов translate и scale которые это могут под капотом сделать?
Прямоугольник кстати прям на канвасе рисовать можно, не знаю как в flutter, но в compose есть drawWithContent, где можно нарисовать что-то своё поверх (или за) контентом. Во flutter тоже что-то похожее должно быть точно.
Так и я веду к тому же. Что 1с программист получает больше бухгалтера не потому что разбирается в предметной области лучше, а потому что кодить умеет. А тут рассказывают, что знание предметной области чуть ли не то, за что платят деньги.
Да кто угодно их пишет. Вы же понимаете что это машина состояний покрытая тестами со всех сторон. Ну и изначальный посыл автора был что платят не за навыки программирования а за знания в предметной области. Что я и пытался выяснить, что именно нужно какому-либо разрабу для iOS/Android пишущий интернет магазин к примеру от платежного шлюза? Ему(или специалистам сервера) дадут сдк и будут все с ним работать.
Я понимаю что писать систему управления платежами сложно, но насколько я понимаю основные проблемы в отсутствии багов и куче тестов, т.к. ошибки дороги, а не в сложной логике. Какая-нибудь СУБД будет посложнее, но это мое мнение, на ?% правильность не претендую.
Ну другими словами вы считаете, что если у вас есть хороший сотрудник, который доделал интернет магазин, а следующий заказ у вашей студии графический редактор (возьмём для удобства мобильное приложение, чтобы нельзя было утверждать, что это разные платформы), то первого сотрудника мы увольняем и ищем нового, с компетенциями в графике? Я верно вас понял?
Я не программист МК, так, любитель. Моя профессиональная деятельность лежит в области мобильных приложений, но спасибо за совет :)
Спасибо за ответы, это была интересная беседа :)
Ну т.е. обычный неплохой разработчик вполне может за всю свою долгую карьеру не столкнуться с цос, я же верно понял, что свой sofdevice - я так понимаю, это что-то типа интерфейса в ООП - никогда писать не придется?
Не подумайте что я против знаний, вовсе нет. Но среднестатистическому неплохому разработчику решающему задачи бизнеса все это может же не понадобиться, судя по нашей беседе.
Любой реалтайм (а есть ли он в МК с конвейерами?) можно или на прерывании таймера написать, или сделать ассемблерную вставку - вроде у компиляторов для МК с этим проблем нет.
А разве подавляющее большинство rf устройств не строится по одной из следующих схем:
Ядро МК общается с внешним по отношению к нему устройством, находящемся в одном с ним корпусе - nrf24xxx
Вместе с МК поставляются скомпилированные библиотеки реализующие протокол, насколько я знаю nordic так делае
Если это так, то рядовой разработчик все равно не работает со всем этим матаном и типовая его задача это максимум pid
Что касается компилятора, то вроде хвостовые вызовы он оптимизировать умеет неплохо. Но я понимаю что вы имеете ввиду. Но в любом случае патчить код после компилятора мало кто будет, если он с регистрами не напорьачит какими-нибудь - к примеру нестандартный адрес списка векторов прерываний, который в программе надо перенести.
Ну т.е. вы считаете что json спарсить кратно легче? А свой парсер generic типа написать легче?
А какая вам нужна тензорная математика и что вам надо знать о dct? Что вы с цос делать собираетесь? Если вы мне хотите за фильтры и свертку рассказать, то их как минимум могут выполнять библиотеки. Но даже без них свёртка не очень сложная штука например.
Я не специалист ни в цос, ни в МК, но насколько я знаю цос на МК не самая частая задача. Ну т.е. оно конечно считается, но вот не каждый разработчик этим занимается. Да и библиотеки уже должны быть, но это мое предположение.
За фильтр признаю, т.к. это линейная система, чисто в теории он и цифровым может быть, но могут быть и не линейные системно схемотехнические решения.
Да и не думаю что рядовой программист МК будет антенну или трансформатор рассчитывать.
Что касается внутренней схемотехники, ну так она цифровая и да туда много кто лезет, но я уже встречал мнение что ассемблер знать например не надо, а он как раз к той самой схемотехнике прямо относится.
Ну иногда да, а иногда просто использует сдк и ничего не знает о внутрянке. Те же платежные шлюзы свое сдк дают, о платежах не известно ничего, но задача выполнена. Так что это как минимум не всегда так. А ещё часто проекты могут не совпадать от слова совсем - к примеру сегодня делаю интернет магазин, а завтра графический редактор. И что, программист на одном проекте хороший специалист, а на другом нет?
По вашему простой программист, который без всех вами перечисленных нюансов нормально зарабатывать не сможет? Ну тот который там архитектуру красиво разделяет, но ни в матан (линейную алгебру же в школе проходят, ну как минимум вектора и системы уравнений), ни в бух учёт не лезет. Странно это звучит, если честно. Потому что сервер можно писать без глубокого понимания складского порядка, а прося непосредственных работников проконсультировать. И, о боже, даже в каких-то особых специфичных вопросах, алгоритм могут запросить на стороне, например в университете. А программист МК может вообще в схемотехнику фильтров не лезть.
Так что можно развернуть вашу мысль про специфические знания?
А можно узнать какие знания высшей математики вам нужны в it? Ну просто для понимания.
Ну если статья про другое, то зачем вообще qa нужны логи? От qa вроде сам баг и порядок шагов для его выполнения требуется. Логи обычно разработчикам нужны, может я чего-то не понимаю, проясните?