В VSCode такая же популярная как Android Studio для разработки под Android? Я ничего не перепутал? Судя по расширению https://marketplace.visualstudio.com/items?itemName=adelphes.android-dev-ext оно требует установленные тулзы и представляет собой только отладчик. А установка всего фарша нужного для разработки (sdf, build-tools, platform-tools, ndk, cmake, emulator) это вы уже как-нибудь руками. И у расширения пока только 4 отзыва. :)) Окей, написали, а теперь надо ошибки искать и профилировать. Что будем делать в VSCode? :))
Можно и на микросервисах кашу сделать. Не панацея. Это с опытом приходит как рефакторить и где бритвой Оккама проводить. Тупое следование правилам, конечно не поможет. "Всюду микросервисы!" - "Всюду фабрики" - "Склеить все воедино!". Крайности не помогут.
Красавцы. Все делают микросервисы, чтобы легче управлять зависимостями и тестировать отдельные модули. А вы собрали монолит, который в себе будет содержать дополнительную сложность.
Истина где-то посередине. С одной стороны 5 слоев абстракций конечно во вред. И лишние интерфейсы не нужны. С другой стороны они позволяют избежать спагетти кода, и внятно и коротко описать и протестировать логику работы, прочитать и быстро понять код.
Но при проектировании все не учтешь. Потому сначала пишется решение которое работает, а потом причесывается и разбивается на блоки так, чтобы было легко дальше поддерживать.
А по мере решения прикладных проблем вроде выравнивания груза в стволе этой пушки gaussa во время разгона пушка будет становиться все тяжелее и тяжелее, и грузу нужна будет какая-то защита. И какая-то сортировочная станция для подачи грузов в нужном порядке на отправку. И еще склад для этих грузов по мере их поступления с Земли. Рядом поместим схожую трубу, которая будет вырабатывать электричество и затормаживать влетающие грузы с Луны или Марса. Ну и как обеспечить подъем такого объема грузов на орбиту без космического лифта?!
Очень не хватает в начале статьи описания соли алгоритма. В чем его основное преимущество? Мол, вместо линейного сравнения первого символа подстроки с каждым символом строки мы сравниваем последний символ подстроки с соответствующим символом строки и движемся вперед большими прыжками. Размер прыжка вычисляем по таблице, которую готовим вначале. Минус - надо готовить таблицу прыжков. Плюс - прыгаем на большие расстояния. Резюме: Для длинных текстов получается значительное ускорение поиска." А потом уже можно переходить к практической части. Ну и "напишем цикл", это как-то совсем для школьников. Вы же алгоритм объясняете, а не программировать учите.
Пока цена портирования и поддержка платформы выше, чем выручка с нее — можно и не начинать. Для игры имеет смысл рассматривать iOS и iPadOS как платформу для жизни, где много денег и пользователей. Может быть даже больше, чем в windows. И для indie игры в первую очередь стремиться туда. С выходом Catalina портировать игру на macOS большого труда не составит. И будет сразу одним релизом будет закрыто три платформы.
Разумно было бы до идентификации разрешить оплачивать услуги со своей банковской карты, а кошелек пополнять не давать. И услуга оплачена и денег лишних на счету не зависнет.
Я сам попал в ту же ситуацию лет 5 назад. Хотел кому-то денег перевести на ЯД, к себе на кошелек кинул, а перевести уже не смог. Хотя пополнить чужой кошелек со своей карточки можно без проблем. А казалось бы это равноценные операции.
5 лет прошло, а воз и ныне там.
Все хорошо. Но как быть если интернет пропал? Сразу говорить пользователю чтобы шел к машине? Или вы зашли в здание и GPS уплыл в соседний район. У вас ломается предсказание, сколько идти обратно и не ясно в какую сторону. Может начать думать, что машина рядом, а может наоборот.
Расскажу свою историю: Мы делаем фреймворки для офлайн карт, навигации, поиска на iOS и Android. Код максимально шарится между платфомами. Приведу пример: Для того чтобы показать вьюху с картой на стороне ОС мы обрабатываем касания, реализуем API для взаимодействия с компонентом и создаем surface для рендера. Весь остальной код пишется на C++. И там его очень много. Парсинг данных, парсинг стиля, применение стиля к данным, подготовка данных для OpenGL/Metal, весь сетевой стек, очереди фоновых задач, обработка данных пользователя. API, которое видит разработчик — это просто верхушка айсберга. Это с одной стороны. Много сложного кода, его лучше писать один раз. И ошибки ловить один раз.
При этом мы делаем приложения Guru Maps на своих же фреймворках. И тут ситуация обратная весь интерфейс и большинство кода этих приложений пишутся так, как это принято на конкретной архитектуре. Общий код на C++ тоже есть, но его мало. Это работа с данными и конверсия между бинарным форматом,GPX,KML в любую сторону.
Категоричный вывод о том что общий код на C++ вреден — я бы не делал. Он сильно облегчает жизнь. Но это должно быть что-то такое, в чем нужна скорость и нет зависимости от специфичных для платформы плюшек.
И не только номера. Любопытно будет посмотреть на проверку атаки. Кто возьмет валидное пространство номеров телефонов для страны и попробует найти там номер по 3 байтам 32 байтного хэша. Интересно сколько там будет коллизий.
Так у большинства стоит настройка. «Принимать файлы только от знакомых». Все остальные запросы с мусором даже появляться не будут. Без превью, без соблазнительных картинок и т.д.
А в чем собственно проблема? Вы же сейчас прочитали абстрактный кусок кода, сделали какие-то выводы и спрашиваете у меня верны ли эти выводы.
Да я считаю, что конверсию типов надо проверять. Да, все ошибки, которые возвращает api надо проверять. Да, если что-то может пойти не так, надо проверить, все ли хорошо. И если произошло что-то нештатное, действовать по обстоятельствам: отправлять ошибку выше по стеку, обрабатывать, пробовать снова или что-то еще.
Но это все риторика о том как обрабатывать ошибки.
Усложнение концепции языка не защитит от ошибок, а наоборот сделает код сложнее и ошибок станет больше. Несмотря на благие намерения. Стандартные библиотеки go показали, как на нем можно решать прикладные задачи и без дженериков.
Может быть я не работал на сложных проектах на Go. Но работал на сложных проектах на C++. Где стрелять себе в ногу проще по многим причинам. И если есть возможность не писать хреновый код, его не надо писать. Могу понять студенческие поделки, но в продакшене такого быть не должно. Язык сам дает инструменты, чтобы проверять, что все норм. Почему бы ими не воспользоваться?
Тут у вас есть возможность проверить, успешный ли каст или нет. Добавили проверку — все работает.
В каком случае может возникнуть необходимость делать касты без проверки я не могу представить.
А корова-то дойная!
В VSCode такая же популярная как Android Studio для разработки под Android? Я ничего не перепутал? Судя по расширению https://marketplace.visualstudio.com/items?itemName=adelphes.android-dev-ext оно требует установленные тулзы и представляет собой только отладчик. А установка всего фарша нужного для разработки (sdf, build-tools, platform-tools, ndk, cmake, emulator) это вы уже как-нибудь руками. И у расширения пока только 4 отзыва. :)) Окей, написали, а теперь надо ошибки искать и профилировать. Что будем делать в VSCode? :))
Можно и на микросервисах кашу сделать. Не панацея. Это с опытом приходит как рефакторить и где бритвой Оккама проводить. Тупое следование правилам, конечно не поможет. "Всюду микросервисы!" - "Всюду фабрики" - "Склеить все воедино!". Крайности не помогут.
Красавцы. Все делают микросервисы, чтобы легче управлять зависимостями и тестировать отдельные модули. А вы собрали монолит, который в себе будет содержать дополнительную сложность.
Истина где-то посередине. С одной стороны 5 слоев абстракций конечно во вред. И лишние интерфейсы не нужны. С другой стороны они позволяют избежать спагетти кода, и внятно и коротко описать и протестировать логику работы, прочитать и быстро понять код.
Но при проектировании все не учтешь. Потому сначала пишется решение которое работает, а потом причесывается и разбивается на блоки так, чтобы было легко дальше поддерживать.
См. Optimised battery charging. Тем не менее через год использования Battery health показывает 93% от максимальной емкости.
Взял Air на M1 год назад и не пожалел ни секунды. Легкий, быстрый, тихий (совсем), автономный и не дорогой (Привет M1 MAX).
А по мере решения прикладных проблем вроде выравнивания груза в стволе этой пушки gaussa во время разгона пушка будет становиться все тяжелее и тяжелее, и грузу нужна будет какая-то защита. И какая-то сортировочная станция для подачи грузов в нужном порядке на отправку. И еще склад для этих грузов по мере их поступления с Земли. Рядом поместим схожую трубу, которая будет вырабатывать электричество и затормаживать влетающие грузы с Луны или Марса. Ну и как обеспечить подъем такого объема грузов на орбиту без космического лифта?!
Очень не хватает в начале статьи описания соли алгоритма. В чем его основное преимущество? Мол, вместо линейного сравнения первого символа подстроки с каждым символом строки мы сравниваем последний символ подстроки с соответствующим символом строки и движемся вперед большими прыжками. Размер прыжка вычисляем по таблице, которую готовим вначале. Минус - надо готовить таблицу прыжков. Плюс - прыгаем на большие расстояния. Резюме: Для длинных текстов получается значительное ускорение поиска." А потом уже можно переходить к практической части. Ну и "напишем цикл", это как-то совсем для школьников. Вы же алгоритм объясняете, а не программировать учите.
Я сам попал в ту же ситуацию лет 5 назад. Хотел кому-то денег перевести на ЯД, к себе на кошелек кинул, а перевести уже не смог. Хотя пополнить чужой кошелек со своей карточки можно без проблем. А казалось бы это равноценные операции.
5 лет прошло, а воз и ныне там.
Офлайн навигация не так сложна, как может показаться. Но пользователю надо будет предварительно качать навигационные данные для своего города.
При этом мы делаем приложения Guru Maps на своих же фреймворках. И тут ситуация обратная весь интерфейс и большинство кода этих приложений пишутся так, как это принято на конкретной архитектуре. Общий код на C++ тоже есть, но его мало. Это работа с данными и конверсия между бинарным форматом,GPX,KML в любую сторону.
Категоричный вывод о том что общий код на C++ вреден — я бы не делал. Он сильно облегчает жизнь. Но это должно быть что-то такое, в чем нужна скорость и нет зависимости от специфичных для платформы плюшек.
Да я считаю, что конверсию типов надо проверять. Да, все ошибки, которые возвращает api надо проверять. Да, если что-то может пойти не так, надо проверить, все ли хорошо. И если произошло что-то нештатное, действовать по обстоятельствам: отправлять ошибку выше по стеку, обрабатывать, пробовать снова или что-то еще.
Но это все риторика о том как обрабатывать ошибки.
Усложнение концепции языка не защитит от ошибок, а наоборот сделает код сложнее и ошибок станет больше. Несмотря на благие намерения. Стандартные библиотеки go показали, как на нем можно решать прикладные задачи и без дженериков.
Тут у вас есть возможность проверить, успешный ли каст или нет. Добавили проверку — все работает.
В каком случае может возникнуть необходимость делать касты без проверки я не могу представить.