Абсолютно у всех компаний, бизнесом которых не является само приложение, мобильные приложения ущербны чуть более чем совсем. Или тормознутые, или требуют кучу прав, или нестандартный вырвиглазный UI. Но чаще — всё это вместе. А ещё приложения дико колбасит, если вдруг посередине работы пропала сеть. Или приложение ушло в фон, в это время пропала сеть, и приложение вышло из фона. Речь про Android. И я спрашиваю, потому что сам никогда не писал за деньги под эту платформу, но есть опыт разработки приложения потокового вещания. И я помню, что Гугл корошо всё задокументировал — просто нужно пойти и прочитать. Вобщем, что не так с мобильными разработчиками? Ведь на Хабре постоянно выходят статьи о том как что-нибудь оптимизировать или написать правильно, по канонам (я всё ещё про мобильную разработку говорю). Причём зачастую статьи в блогах как раз этих самых компаний.
И отдельный вопрос — почему такие сложности с поддержкой старых платформ? Привязываем основную ветку к последней платформе, ответвляемся к предыдущей и дописываем недостающие компоненты. И так до самого низа. При обновлении основной ветки rebase должен быть без конфликтов, ведь мы не трогаем в основной ветке тот код, что есть в старых ветках. rebase делаем по цепочке от самой current ветки до самой старой. Это так сложно? Сраный сбер нанял кучу разработчиков и их банк-клиент — такое убожество. А клиент торгового терминала настолько убогий, что они забили на рефакторинг старого и просто написали новый! Известны они как "Cбербанк Инвестор" и "СберИнвестор Х". Правда, надо отдаль должное — сбер хотя бы работает в RuStore, чего нельзя сказать о многих других российских приложениях. Половина требует гуглосервисы.
Здравствуйте, cppguard, Вы писали:
C>И отдельный вопрос — почему такие сложности с поддержкой старых платформ? Привязываем основную ветку к последней платформе, ответвляемся к предыдущей и дописываем недостающие компоненты. И так до самого низа. При обновлении основной ветки rebase должен быть без конфликтов, ведь мы не трогаем в основной ветке тот код, что есть в старых ветках. rebase делаем по цепочке от самой current ветки до самой старой. Это так сложно? Сраный сбер нанял кучу разработчиков и их банк-клиент — такое убожество. А клиент торгового терминала настолько убогий, что они забили на рефакторинг старого и просто написали новый! Известны они как "Cбербанк Инвестор" и "СберИнвестор Х".
Ха, тут когда год назад обновился онлайн банк Альфы для веба, я у него там 3 разных веб приложения насчитал. Т.е. они тупо основные странички переписали и к ним также прилепили две старые. Дизайн причём прям сильно разный, но ничё — пипл хавает...
Здравствуйте, cppguard, Вы писали:
C>Абсолютно у всех компаний, бизнесом которых не является само приложение, мобильные приложения ущербны чуть более чем совсем. Или тормознутые, или требуют кучу прав, или нестандартный вырвиглазный UI. Но чаще — всё это вместе.
Потому что при захвате мобильного рынка был сделан финт ушами. Каждый платформодержатель решил запилить свою систему на виртуальных машинах для сторонних разработчиков.
Я думаю это было сделано для того чтобы.
1. Удержать сторонних разработчиков на своей платформе, ведь их приложение больше нигде не будет работать, а значит деваться им некуда.
2. Ослабить сторонних разработчиков, ведь вместо использования кроссплатформенных возможностей С++ они распыляются и не могут составить конкуренцию платформодержателю, который как раз таки пилит основной продукт на C/C++.
Всё это привело к попыткам всё таки создать кроссплатформу. Но получилось несколько решений.
1. Те же тормознутые приложения для виртуальных машин, но с претензией на кроссплатформенность.
2. Пишем веб и запихиваем браузер в мобильное приложение, чтобы получить уж совсем лютое говнище.
3. И лучик света в коричневом царстве говна, кроссплатформенные приложения на C++, это Qt5, игровые движки и так далее.
Теперь что касается программистов. Людям втирают в уши, что использовать какой-то язык программирования проще, чем другой. Что нужно меньше профессионализма, если сделать вот такой выбор, а не другой. А это не так.
Говорят даже яву можно сделать не такой убого тормознутой, если подойти к ней с правильной стороны. Производительности C++ там не будет, но всё же.
Но здесь мы подходим к тому, что у большинства людей хватает ресурсов только на то, чтобы создать веб-приложение под видом мобильного. Их не устраивает, что они могли бы просто сделать веб-приложение, а не заниматься ерундой с внедрением браузера.
Существует множество мобильных версий приложений, но при этом нет десктоповых приложений. Это говорит о том, что разработчики явно не понимают, что делают. Ведь уровень мобильного приложения должен соответствовать десктоповому. И если они не могут сделать нормальное десктоповое приложение, то и мобильное не смогут.
А много ли мы видим десктоповых клиентов к какому-нибудь веб-сервису. Очевидно нет. Где-то статья была в интернете о том, что мобильные приложения по большей части не нужны, так как пользователи не будут их устанавливать, что выявляется путём подсчёта установленных приложений.
И понятно, что чтобы сделать нормальное приложение нужно его сделать с помощью хорошей команды, а не заказать у кого попало просто потому, что это же так нынче модно.
Десктоповое и мобильное приложения должны иметь свои файлы или базы данных в которые они аккуратно закачивают внешние данные не перегружая диск лишними записями. И потом не лезут в интернет, а выдают данные из внутренней памяти.
То есть то, что понимает какой-нибудь программист школьник не понимают крупные бизнес дяденьки. А раз они не понимают, то и заказать нормально ничего не смогут. Им просто впарят встроенный браузер, ну или если повезёт накидают как попало формочек для виртуальных машин.
Раз уж речь о Сбербанке, то он вроде как должен выглядеть как удобное банковское приложение для управления деньгами. А выглядит он как обмазанный банерами сайт живущий на контекстной рекламе.
Да, нет элементарного понимания, что приложение должно приносить пользу. Им оно и не нужно, так как они действительно не продают продукт, а сделали чтобы было. И подключение к сервисам у них супер долгое, что они даже придумали заставку.
Здравствуйте, cppguard, Вы писали:
C>И отдельный вопрос — почему такие сложности с поддержкой старых платформ?
Потому что заказчики давно нахер не ходили. Потому что их дело, заказчиков — отдать деньги и отвечать на вопросы, а не заниматься микроменеджментом. Потому что разработка в формате "закрываем тикеты за спринт" показывает разработчикам, что они есть ничтожное взаимозаменяемое говно. Вот у них и результат получается так себе.
Это все равно что спрашивать "почему вода мокрая". Все ущербности мобильных приложений потому что они изначально мобильные. Во-первых — маленький экран. Во-вторых — спосооб ввода — только экран. Все рисования кнопочек на экране — это уже костыли и притягивание одного к другому. Например на телефоне нельзя "подвести курсор к кнопке", чтоб например тултип увидеть. Это невозможно. Можно только кликнуть. Ну или придумывать костыль на костыле типа виртуального курсора. Но это лимиты не приложений. Это лимиты того, что это все на мобилке. Да даже и планшеты не слишком тут далеко ушли.
Клавиатура. Ввод текстов на экранной клавитаутре — это ад. Именно потому что мы экран пытаемся натянуть на кнопочный функционал. А человеку нужна отдача от кнопок. Физическая. Экран этого дать не может.
Ну и к чему приходим? Да, единственное что родное на мобильном экране — это елозить пальцем туда-сюда. Все остальное — натягиваение совы. Даже кнопки. Потому и получаются они такие ущербные.
Ну попробуй сам что-то написать. Разработка на андроиде ущербна сама по себе. Я вот позавчера поставил андроид студию. Прям на чистый компьютер с нуля. Запускаю, создаю проект с пустым окошком. IDE Error. Они его вообще не тестируют. Глюки повсеместно. В ихнем SDK костыли идут вообще по дефолту. У меня дёргается глаз, когда мне приходится ради простейшего приложения включать многомегабайтные библиотеки. В андроиде так положено прям от производителя — support libraries которые якобы фиксят баги телефона. Т.е. вместо того, чтобы пофиксить баги в самом телефоне, они предлагают эти баги фиксить в каждом приложении, которое запускается на этом телефоне. Жизненный цикл activity — там наверное можно диссертацию писать. А жизненный цикл fragment внутри activity — сомневаюсь, что кто-то вообще понимает это всё.
И я не уверен, что в айфоне всё намного лучше. Учитывая, что ихние встроенные приложения частенько глючат, когда я поворачиваю экран, то бишь они сами не смогли базовый функционал реализовать без багов.
Андроид надо сжечь. Сегодня есть лишь одна платформа, на которую ругаться хочется не так сильно — это веб. Там хватает своих приколов, но качество совсем на другом уровне. Я думаю, что надо просто дождаться, пока люди дозреют до мысли, что мобильные приложения не нужны, а нужен мобильный сайт-приложение. Технологии уже дозрели.
Здравствуйте, vsb, Вы писали:
vsb>Андроид надо сжечь.
Поздно. Сейчас призывать к "Android must die" — успех будет еще меньше, чем призывы "Windows must die" и переход на Linux. Там хоть было что-то, на что можно было призывать перейти, а результат почти нулевой. А тут и призывать не к чему — не на что переходить.
Здравствуйте, velkin, Вы писали:
v> Потому что при захвате мобильного рынка был сделан финт ушами. Каждый платформодержатель решил запилить свою систему на виртуальных машинах для сторонних разработчиков.
И что за виртуальная машина у яблочных?
v> 2. Ослабить сторонних разработчиков, ведь вместо использования кроссплатформенных возможностей С++ они распыляются и не могут составить конкуренцию платформодержателю, который как раз таки пилит основной продукт на C/C++.
Здравствуйте, Нomunculus, Вы писали:
Н> Например на телефоне нельзя "подвести курсор к кнопке", чтоб например тултип увидеть. Это невозможно. Можно только кликнуть.
На ведроиде: touch на кнопке не отпуская палец — появляется tooltip. Так было, насколько я помню.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD> vsb>Андроид надо сжечь.
PD> Поздно. Сейчас призывать к "Android must die" — успех будет еще меньше, чем призывы "Windows must die" и переход на Linux. Там хоть было что-то, на что можно было призывать перейти, а результат почти нулевой. А тут и призывать не к чему — не на что переходить.
Здравствуйте, Pavel Dvorkin, Вы писали:
vsb>>Андроид надо сжечь.
PD>Поздно. Сейчас призывать к "Android must die" — успех будет еще меньше, чем призывы "Windows must die" и переход на Linux. Там хоть было что-то, на что можно было призывать перейти, а результат почти нулевой. А тут и призывать не к чему — не на что переходить.
Ну это так, эмоции. Понятно всё. Вроде гугл делает фуксию с интерфейсом на флаттере. Может чего и получится. Всё же андроид делали наспех.
Здравствуйте, cppguard, Вы писали:
C>Абсолютно у всех компаний, бизнесом которых не является само приложение, мобильные приложения ущербны чуть более чем совсем. Или тормознутые, или требуют кучу прав, или нестандартный вырвиглазный UI. Но чаще — всё это вместе. А ещё приложения дико колбасит, если вдруг посередине работы пропала сеть. Или приложение ушло в фон, в это время пропала сеть, и приложение вышло из фона. Речь про Android. И я спрашиваю, потому что сам никогда не писал за деньги под эту платформу, но есть опыт разработки приложения потокового вещания. И я помню, что Гугл корошо всё задокументировал — просто нужно пойти и прочитать. Вобщем, что не так с мобильными разработчиками? Ведь на Хабре постоянно выходят статьи о том как что-нибудь оптимизировать или написать правильно, по канонам (я всё ещё про мобильную разработку говорю). Причём зачастую статьи в блогах как раз этих самых компаний.
Будучи разработчиком под мобильные с iPhone 3G/Android 2.0 (а до этого под PalmOS и Windows Mobile) скажу, что обычно проблема в деньгах.
"Зачем тратить денег на мобильного разработчика, наш фронтендер на джаваскрипте всё напишет!"
Мобильная разработка требует некоего вложения в разработку, CI/CD, тестирование. А если в компании софтварный отдел — это "расходы", то стараются расходы "оптимизировать". "Ой ну мобильные же, чо там делать-то, мы вон сервер подняли какой, нешто не сможем".
C>Сраный сбер нанял кучу разработчиков и их банк-клиент — такое убожество. А клиент торгового терминала настолько убогий, что они забили на рефакторинг старого и просто написали новый! Известны они как "Cбербанк Инвестор" и "СберИнвестор Х". Правда, надо отдаль должное — сбер хотя бы работает в RuStore, чего нельзя сказать о многих других российских приложениях. Половина требует гуглосервисы.
У "сраного Сбера" (и некоторых других больших компаний как в нашей стране, так и за рубежом) обратная проблема — у них СЛИШКОМ МНОГО денег и много фич пытаются впихнуть в приложение, возникают проблемы от interlocking.
Здравствуйте, velkin, Вы писали:
V>Потому что при захвате мобильного рынка был сделан финт ушами. Каждый платформодержатель решил запилить свою систему на виртуальных машинах для сторонних разработчиков.
например, iOS? Там нет виртуальной машины. Оную придумал Андроид, а потом пытался придумать Майкрософт с ВонФоном7, но попустило к ВинФон8, а потом и не взлетело.
V>1. Удержать сторонних разработчиков на своей платформе, ведь их приложение больше нигде не будет работать, а значит деваться им некуда.
Ровно так же можно сказать про разработчиков любой платформы — c#/.net чтобы "удержать сторонних разработчиков на своей платформе, ведь их приложение больше нигде не будет работать".
V>2. Ослабить сторонних разработчиков, ведь вместо использования кроссплатформенных возможностей С++ они распыляются и не могут составить конкуренцию платформодержателю, который как раз таки пилит основной продукт на C/C++.
На самом деле могут, и делают. В iOS нативно, в Андроид через JNI (да, костыль, но лучше так чем никак).
V>3. И лучик света в коричневом царстве говна, кроссплатформенные приложения на C++, это Qt5, игровые движки и так далее.
Это не лучик света, это такое же говно как и два предыдущих, я про Qt. Игровые движки "честнее" — они делают маааааленькую оболочку на родных компонентах и дают С++ (ну или C# в Unity) для разработчиков, пишите всё что хотите. Qt попытался дать интерфейс к родным контролам через C++/Qt и это чудовищно.
V>И понятно, что чтобы сделать нормальное приложение нужно его сделать с помощью хорошей команды, а не заказать у кого попало просто потому, что это же так нынче модно.
+1
Здравствуйте, vsb, Вы писали:
vsb> Жизненный цикл activity — там наверное можно диссертацию писать. А жизненный цикл fragment внутри activity — сомневаюсь, что кто-то вообще понимает это всё.
Это как с латынью в медицине — вся не нужна. А что надо — используется один раз при написании приложения.
vsb>И я не уверен, что в айфоне всё намного лучше. Учитывая, что ихние встроенные приложения частенько глючат, когда я поворачиваю экран, то бишь они сами не смогли базовый функционал реализовать без багов.
Лучше. По крайней мере, в айфоне не пересоздаётся весь объект activity при повороте, как ещё недавно было в Андроиде. А просто надо layout сделать.
В layouting не все почему-то умеют, хотя это довольно просто как мне кажется.
vsb>Андроид надо сжечь.
Я очень не люблю Андроид (по сравнению с iOS), но альтернатив особо нет. Это как с Виндой — она отвратительна, но уникальна. Линуксом юзеры не пользуются, мак "дорого", а другого нет вообще ничего.
vsb>Сегодня есть лишь одна платформа, на которую ругаться хочется не так сильно — это веб. Там хватает своих приколов, но качество совсем на другом уровне. Я думаю, что надо просто дождаться, пока люди дозреют до мысли, что мобильные приложения не нужны, а нужен мобильный сайт-приложение. Технологии уже дозрели.
Ровно противоположное мнение — веб надо переписать с нуля, чтобы избавиться от того трэша, который там самозародился от внебрачных связей HTML, CSS и, особенно, самого ужасного языка вселенной, JS.
>Ввод текстов на экранной клавитаутре — это ад. Именно потому что мы экран пытаемся натянуть на кнопочный функционал. А человеку нужна отдача от кнопок. Физическая. Экран этого дать не может.
Когда уже сделают ввод морзянкой через 2 хардварные кнопки?
Друга ищи не того, кто любезен с тобой, кто с тобой соглашается, а крепкого советника, кто полезного для тебя ищет и противится твоим необдуманным словам.
Здравствуйте, Dair, Вы писали:
D>Ровно так же можно сказать про разработчиков любой платформы — c#/.net чтобы "удержать сторонних разработчиков на своей платформе, ведь их приложение больше нигде не будет работать".
Здравствуйте, Нomunculus, Вы писали:
Н>Это все равно что спрашивать "почему вода мокрая".
На f-droid много сносных, маленьких и шустрых приложений. Не скажу, что они идеальные, но, видимо, когда над душой не стоит эффективный менеджер, всё таки можно разрабатывать по-человечески. Приложения Гугла были неплохи, когда они ещё не стали нанимать исключительно представителей меньшинств. И, как я уже говорил, мне самому приходилось иметь дело с Android SDK, и там почти всё понятно и очевидно.
Здравствуйте, cppguard, Вы писали:
C>Абсолютно у всех компаний, бизнесом которых не является само приложение, мобильные приложения ущербны чуть более чем совсем.
Потому что бизнес такой. Не надо идеально, надо что бы доход приносило (Лучше так чем никак).
C>И отдельный вопрос — почему такие сложности с поддержкой старых платформ?
Сейчас так модно, не поддерживать старые платформы. (да и новые. документация, как правило, не актуальна)
Здравствуйте, vsb, Вы писали:
vsb>Ну попробуй сам что-то написать. Разработка на андроиде ущербна сама по себе. Я вот позавчера поставил андроид студию. Прям на чистый компьютер с нуля. Запускаю, создаю проект с пустым окошком. IDE Error. Они его вообще не тестируют. Глюки повсеместно. В ихнем SDK костыли идут вообще по дефолту. У меня дёргается глаз, когда мне приходится ради простейшего приложения включать многомегабайтные библиотеки. В андроиде так положено прям от производителя — support libraries которые якобы фиксят баги телефона. Т.е. вместо того, чтобы пофиксить баги в самом телефоне, они предлагают эти баги фиксить в каждом приложении, которое запускается на этом телефоне. Жизненный цикл activity — там наверное можно диссертацию писать. А жизненный цикл fragment внутри activity — сомневаюсь, что кто-то вообще понимает это всё.
Да пробовал я. Да, студия — говно. Причём, там ещё непонятно, говно ли это джетбрейновское или гугловое. А может их совместное творение. Но я ещё раз повторю — если следовать документации, то приложения получаются, как минимум, на троечку. Это если вообще не прилагать усилий и копипастить код из доков.
vsb>Андроид надо сжечь. Сегодня есть лишь одна платформа, на которую ругаться хочется не так сильно — это веб. Там хватает своих приколов, но качество совсем на другом уровне. Я думаю, что надо просто дождаться, пока люди дозреют до мысли, что мобильные приложения не нужны, а нужен мобильный сайт-приложение. Технологии уже дозрели.
А уведомления и интеграция с аппаратной частью? Тут спорно.
Здравствуйте, cppguard, Вы писали:
C>Да пробовал я. Да, студия — говно. Причём, там ещё непонятно, говно ли это джетбрейновское или гугловое.
Однозначно — гугловое. Я на жаве пишу в идее уже давно. Ну прям хвалить их не буду, но в целом для обычной жавы идея вполне себе адекватна и негатива не вызывает, особенно если не спешить с апгрейдами.
C>А уведомления и интеграция с аппаратной частью? Тут спорно.
Уведомления есть. До недавнего времени в ios не было, этим летом анонсировали, в новой версии то ли уже есть, то ли включат скоро. Для аппаратной части практически все апи есть. Для 99% приложений возможностей веб апи хватает.
Пусть есть. Может, и еще что-то есть. Может и, и еще что-то будет создано. Все это не имеет никакого значения.
Если бы речь шла о ПО, скажем, для контроллеров, с которым массовый пользователь не работает, то задача перехода на новое ПО решаема. Убедить программистов, что оно лучше, и они , пусть не сразу, но перейдут. Им менять инструменты не в диковинку.
А вот что касается Windows и теперь уже Android — заменить их смогли бы разве что Super-Windows и Super-Android. Которые делают совершенно все, что делают Windows и Android соответственно, под которыми работают все программы от них. Ну и что-то еще. Вот на такое ПО переход теоретически возможен. Теоретически — потому что в обозримом будущем это сделать невозможно, даже не касаясь вопроса о (C).
Потому что и Windows, и Android — ПО массового пользователя. И очень даже массового. И никакие технические соображения тут не заставят перейти. Как ни убеждали, что Linux лучше, как ни доказывали — результат на клиентских машинах чуть больше, чем 0. Массовый пользователь просто переходить не будет, ему это совершенно незачем. И убедить миллионы и миллиарды пользователей не удастся. Если же какая-то фирма начнет делать не на Android — ей проще просто затеять дело о самоликвидации, потому что покупать эти телефоны — все равно, что купить утюг, требующий напряжения 280В. Оригинально, конечно, а может, даже и лучше, чем 220, вот только напряжения такого ни в одной сети нет.
Я, конечно, не утверждаю, что Windows и Android — это forever. Всякое может случиться. Но если не произойдет радикальной революции в области железа, то есть не появятся какие-то совсем иные устройства — в обозримом будущем и та, и другая останутся, с модификациями, конечно.
Здравствуйте, cppguard, Вы писали:
C>Абсолютно у всех компаний, бизнесом которых не является само приложение, мобильные приложения ущербны чуть более чем совсем.
Можно подумать, что веб-приложения не ущербны. У моего банка, например — это лютый ужас. Причем банк далеко не из последних и бедных. Или, например, здесь в компании (опять же не из последних и бедных) есть веб-портал для организации командировок — так в этом унылом говнище регистрация пользователя через веб есть, но она в принципе не работает и похоже никогда не работала. Только через телефон
Да и десктопные понемногу двигаются в том же направлении.
А ответ простой — программистов сейчас набирают главным образом не за умение кодить, а за умение понравиться. Весь этот emotional intelligence и прочий бред.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Как ни убеждали, что Linux лучше, как ни доказывали
А он для клиента попросту не лучше. Дров для большинства железа вообще нет, например. И даже если заморочиться подбором железа по этому параметру — задолбаешься. Ну а катавасия с несколькими несовместимыми клипбордами — за такое вообще надо пороть на конюшне.
Здравствуйте, Codealot, Вы писали:
C>А он для клиента попросту не лучше. Дров для большинства железа вообще нет, например. И даже если заморочиться подбором железа по этому параметру — задолбаешься. Ну а катавасия с несколькими несовместимыми клипбордами — за такое вообще надо пороть на конюшне.
Как сказал один бывший (давно его не вижу) участник RSDN
В Linux вы все можете настроить. И вы, <censored> будете все настраивать
А пороть тут некого. Дитя семи нянек, и работать с ним как следует могут только опытные педагоги
Здравствуйте, Codealot, Вы писали:
C>А ответ простой — программистов сейчас набирают главным образом не за умение кодить, а за умение понравиться. Весь этот emotional intelligence и прочий бред.
Думаю, что дело не в этом, а в том, что мы имеем типичную голландскую болезнь по быстродействию процессора и объему памяти.
Купил неделю назад новый сотовый телефон. На прежнем было 4 Гб, ну а этот взял с 6 Гб.
В игры я на телефоне не играю и они не установлены.
Свободно из эти 6 сейчас 1.5 Гб.
Кто и зачем съел 4.5 Гб ? Что там такое есть на 4 Гб ? Данные ? Так нет у меня никаких гигабайтных данных. У меня и десятков Мб данных нет.
Банковское приложение занимает 236 Мб. Размер приложения 225 Мб.
Что там у вас, черт вас побери, на 225 Мб ? Это для того, чтобы мне посмотреть свои счета и провести оплату, нужно 225 Мб ?
Заставить бы вас уложить это приложение в 1 Мб, а не сделаете — уволить!
Кстати, вполне можно было такое приложение сделать во времена MS-DOS. И , наверное, были. А там за 640 Кб практически и не выйти.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Я, конечно, не утверждаю, что Windows и Android — это forever. Всякое может случиться. Но если не произойдет радикальной революции в области железа, то есть не появятся какие-то совсем иные устройства — в обозримом будущем и та, и другая останутся, с модификациями, конечно.
С развитием мобильного интернета все переползет в облако. Для нужд телефона нужен будет ограниченный функционал. Microsoft отчиталась о 20 млн пользователей Xbox Cloud Gaming — их число удвоилось за полгода
и солнце б утром не вставало, когда бы не было меня
V>2. Пишем веб и запихиваем браузер в мобильное приложение, чтобы получить уж совсем лютое говнище.
Можно и мобильный веб хорошо приготовить, но это дюже не просто. Сложнее хорошего натива. Подход "нахватали чужих npm" явно не годится, только лютая кастомщина, заточенная под конкретный случай, только хардкор.
V>3. И лучик света в коричневом царстве говна, кроссплатформенные приложения на C++, это Qt5, игровые движки и так далее.
О да. Но живой пример из неигрового мира вспоминается только один: старый maps.me. Весьма забористый комбайн был, с высокопрофессиональной командой. Средненький мобильный бракодел такое не потянет.
Здравствуйте, Serginio1, Вы писали:
S> С развитием мобильного интернета все переползет в облако. Для нужд телефона нужен будет ограниченный функционал.
А бог его знает. Примерно то же я слышал лет 15-20 назад. Мол, все будет в сети (тогда еще про облака не говорили), а нужен будет только тонкий клиент с доступом типа RDP. С минимумом возможностей : экран + клавиатура + модуль связи.
Это игры на любом устройстве без видео карты. Если посчитать цену карты, процессора памяти, то дешевле обходится арендовать это все в облаке.
Проблема только в скорости ответа. А она при развитии связи вполне адекватная. Зависит конечно от количества серверов.
PD>В Linux вы все можете настроить. И вы, <censored> будете все настраивать PD>А пороть тут некого. Дитя семи нянек, и работать с ним как следует могут только опытные педагоги
Разве это плохо? Наоборот, сие действо напоминает гонщиков классической эры, которые не только руль крутить умеют, но и своего железного коня пересобирать с закрытыми глазами. К тому же не так это сложно, как кажется. И железа совместимого предостаточно, и аппаратура из "серой зоны" (о которой не известно, совместимая она или нет) заводится зачастую отлично, но то уже вопрос везения, и рекомендовать такой подход я не буду.
D>Ровно противоположное мнение — веб надо переписать с нуля, чтобы избавиться от того трэша, который там самозародился от внебрачных связей HTML, CSS и, особенно, самого ужасного языка вселенной, JS.
Зачем с нуля? Берёшь канвас, берёшь webgl, берёшь WASM, да и рисуешь что душеньке угодно, на чём хочешь нативном)) Не используя бастардно-копролитные наслоения. Ну или используя по-минимуму, ибо не весь ГУЙ удобно ложится на плоскую и "ручную" парадигму. Обратно и не весь красиво описывается через DOM. Figma и Autodesk так делают в полны рост.
vsb>Уведомления есть. До недавнего времени в ios не было, этим летом анонсировали, в новой версии то ли уже есть, то ли включат скоро. Для аппаратной части практически все апи есть. Для 99% приложений возможностей веб апи хватает.
Ого, правда что ли? Уведомления, отсутствие многих аппаратные API, ограничения на storage и БД были как бы намеренными сдерживающими бастионами, не позволяющими web-приложениям на iOS достигать возможностей нативных. И тут Аппле возьмёт и просто так их уберёт? Они сами себе враги что ли?
Подозреваю, что добавить-то добавят, но в максимально мерзейше-кастрированном виде.
PD>Что там у вас, черт вас побери, на 225 Мб ? Это для того, чтобы мне посмотреть свои счета и провести оплату, нужно 225 Мб ? PD>Заставить бы вас уложить это приложение в 1 Мб, а не сделаете — уволить! PD>Кстати, вполне можно было такое приложение сделать во времена MS-DOS. И , наверное, были. А там за 640 Кб практически и не выйти.
Ну, положим, с мегабайтом Вы перебарщиваете, однако работал я когда-то в команде, где за расход RAM на iOS выше сорока мегабайт били по рукам. Было это, правда, в 2015-м, и сейчас я бы этот лимит поднял до 100-150. Что касается размера, то тут мнемоправило простое: раздражение вызывает загрузка приложения из стора, длящаяся более тридцати-сорока секунд, поэтому прикидываем скорости у целевой аудитории, и считаем сами. Если это прилага для контроля какого-нибудь медиа-центра, явно скачиваемая по WiFi в вальяжной обстановке, то это один сценарий, а если гид по незнакомому городу, то совершенно другой.
Здравствуйте, zx zpectrum, Вы писали:
vsb>>Уведомления есть. До недавнего времени в ios не было, этим летом анонсировали, в новой версии то ли уже есть, то ли включат скоро. Для аппаратной части практически все апи есть. Для 99% приложений возможностей веб апи хватает.
ZZ>Ого, правда что ли?
Safari (both desktop and mobile) appears to allow about 1GB. When the limit is reached, Safari will prompt the user, increasing the limit in 200MB increments. I was unable to find any official documentation on this.
If a PWA is added to the home screen on mobile Safari, it appears to create a new storage container, and nothing is shared between the PWA and mobile Safari. Once the quota has been hit for an installed PWA, there doesn't appear to be any way to request additional storage.
Нюансы есть, да.
> И тут Аппле возьмёт и просто так их уберёт? Они сами себе враги что ли?
Apple телефоны продают, AppStore им, конечно, какие-то доходы приносит, но вряд ли определяющие. Логика понятна но Apple хотя и отстаёт в части реализации стандартов от хрома, но далеко не фатально.
ZZ>Подозреваю, что добавить-то добавят, но в максимально мерзейше-кастрированном виде.
ZZ>Уведомления, отсутствие многих аппаратные API vsb>Каких именно?
Тот же полновесный AVFoundation и около для серьёзной работы с видео, Audio Units для аудио, или их функционально-эквивалентные аналоги из веб-мира, уже доступны на iOS?
ZZ>>ограничения на storage vsb>https://web.dev/storage-for-the-web/ vsb>Safari (both desktop and mobile) appears to allow about 1GB.
Здравствуйте, zx zpectrum, Вы писали:
ZZ>>Уведомления, отсутствие многих аппаратные API vsb>>Каких именно?
ZZ>Тот же полновесный AVFoundation и около для серьёзной работы с видео, Audio Units для аудио, или их функционально-эквивалентные аналоги из веб-мира, уже доступны на iOS?
Про такое не в курсе. В принципе в теории можно на webassembly скомпилировать компоненты ffmpeg или других библиотек, но с аппаратным ускорением, понятное дело, оно работать не будет. Такого АПИ наверное нет, ну или я про него не слышал. Вероятно видеоредактор в браузере делать ещё рано.
ZZ>>>ограничения на storage vsb>>https://web.dev/storage-for-the-web/ vsb>>Safari (both desktop and mobile) appears to allow about 1GB.
ZZ>То есть эта статья, утверждающая о 50 Мб хранилища для веб-аппок, вводит в заблуждение, получается? (https://www.tigren.com/blog/progressive-web-app-limitations/)
Я сам не проверял, поэтому не могу точно утверждать.
vsb>Про такое не в курсе. В принципе в теории можно на webassembly скомпилировать компоненты ffmpeg или других библиотек, но с аппаратным ускорением, понятное дело, оно работать не будет. Такого АПИ наверное нет, ну или я про него не слышал. Вероятно видеоредактор в браузере делать ещё рано.
Не, ну без ускорения оно и даром не нужно. Аффтара такого поделия потом и пользователи съедят живьём за неумеренный расход амперов от батарейки, и сумасшедшие эко-озабоченные анафеме предадут )))
Здравствуйте, zx zpectrum, Вы писали:
ZZ>Ну, положим, с мегабайтом Вы перебарщиваете
Согласен, перебарщиваю, но на что нужна память ? На мои счета ? На один счет 2 Кб хватит — там просто больше информации нет. А их у меня всего 2. На все трансакции ? Их у меня не тысячи, а будь тысячи — все равно все не покажешь и качать сразу все незачем, да и не показывают там много, там по месяцам обычно. Да и на трансакцию тоже, думаю, 2 Кб хватит. На список тех, кому я могу деньги переводить или от кого получать ? Так таких всего 2-3.
А больше у меня ничего там и нет. И если есть какие-то модули, отвечающие за то, что мне пока не нужно, то пусть себе сидят на "диске" и ждут, пока понадобятся. А в RAM им делать нечего.
Вот картинки — да. Если их заранее делать и хранить — место потребуется, верно. Но не 200 Мб.
Здравствуйте, zx zpectrum, Вы писали:
ZZ>Разве это плохо? Наоборот, сие действо напоминает гонщиков классической эры, которые не только руль крутить умеют, но и своего железного коня пересобирать с закрытыми глазами. К тому же не так это сложно, как кажется. И железа совместимого предостаточно, и аппаратура из "серой зоны" (о которой не известно, совместимая она или нет) заводится зачастую отлично, но то уже вопрос везения, и рекомендовать такой подход я не буду.
Плохо. Потому что массовый автомобилист должен получить автомобиль, в бак которого надо залить бензин, масло залить, сесть за руль и поехать. А не изображать из себя автомеханика и не лежать под машиной, равно как и не копаться в моторе.
Он не гонщик. У гонщика (программиста) это профессия, а для пользователя автомобиль — лишь средство для передвижения, а компьютер с ОС — средство для его работы, а не отладки и настройки.
PD>У гонщика (программиста) это профессия, а для пользователя автомобиль — лишь средство для передвижения, а компьютер с ОС — средство для его работы, а не отладки и настройки.
Но мы же здесь профессионалы, не так ли?
Делать это всем я, заметьте, и не предлагал.
Здравствуйте, zx zpectrum, Вы писали:
PD>>У гонщика (программиста) это профессия, а для пользователя автомобиль — лишь средство для передвижения, а компьютер с ОС — средство для его работы, а не отладки и настройки. ZZ>Но мы же здесь профессионалы, не так ли?
Мы — да. Но речь шла о юзерах. ZZ>Делать это всем я, заметьте, и не предлагал.
А придется. Не всем, так многим.
Чем Windows хороша — работает в 99% случаев из коробки. Максимум — драйвер поставить придется с инсталляционного диска для какого-то девайса, да и тот, скорее всего, ставить не понадобится, сама поставит.
Именно таким должно быть ПО конечного пользователя.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Думаю, что дело не в этом, а в том, что мы имеем типичную голландскую болезнь по быстродействию процессора и объему памяти.
Такая болезнь была, когда эти параметры удваивались каждый год. Но те времена уже давно прошли, а жручесть софта по прежнему удваивается.
C>Профессионал, который все настраивает — это сисадмин, а не программист.
Ваша концепция разделения обязанностей неприятно пованивает. От неё буквально один шаг до заместителя придворного заправлятеля ширинки в туалете, мистер обленившийся сибарит.
Здравствуйте, zx zpectrum, Вы писали:
ZZ>Ваша концепция разделения обязанностей неприятно пованивает. От неё буквально один шаг до заместителя придворного заправлятеля ширинки в туалете, мистер обленившийся сибарит.
Здравствуйте, Codealot, Вы писали:
C>Такая болезнь была, когда эти параметры удваивались каждый год. Но те времена уже давно прошли, а жручесть софта по прежнему удваивается.
Так объем памяти продолжает расти. Не в 2 раза каждый год, конечно, но растет.
Еще недавно 8 Гб было нормально, а сейчас я и не знаю, что есть стандарт де-факто для настольного ПК — 16 или уже 32 ?
Вот память они и жрут. Есть что жрать — жрут
Аналогично дисковая память.
На телефонах то же. У первого моего смартфона был 1 Гб. Сейчас 6 Гб.
Здравствуйте, zx zpectrum, Вы писали:
ZZ>Зачем с нуля? Берёшь канвас, берёшь webgl, берёшь WASM, да и рисуешь что душеньке угодно, на чём хочешь нативном)) Не используя бастардно-копролитные наслоения.
Здравствуйте, Codealot, Вы писали:
C>Фиг с ней, с памятью. Процессоры уже растут еле-еле, а тормознутость софта увеличивается теми же темпами.
Все же не совсем так. Рост потребностей в памяти влечет за собой рост количества операций. Что-то с этой памятью же делают...
А процессоры уже не растут лет 10, и если не будет какого-то революционного прорыва, то и не будут расти.
Но если почти на тех же процессорах делать в несколько раз больше действий (без которых можно бы и обойтись), то тормоза будут расти, никуда не денешься.
Поэтому какой-то сдвиг будет тогда, когда и объемы памяти перестанут расти. Сожрут всю память, а больше не добавить. Вот тогда и начнут задумываться — а что тут лишнее делается ?
Здравствуйте, cppguard, Вы писали:
C>Абсолютно у всех компаний, бизнесом которых не является само приложение, мобильные приложения ущербны чуть более чем совсем. Или тормознутые, или требуют кучу прав, или нестандартный вырвиглазный UI. Но чаще — всё это вместе. А ещё приложения дико колбасит, если вдруг посередине работы пропала сеть. Или приложение ушло в фон, в это время пропала сеть, и приложение вышло из фона. Речь про Android. И я спрашиваю, потому что сам никогда не писал за деньги под эту платформу, но есть опыт разработки приложения потокового вещания. И я помню, что Гугл корошо всё задокументировал — просто нужно пойти и прочитать. Вобщем, что не так с мобильными разработчиками? Ведь на Хабре постоянно выходят статьи о том как что-нибудь оптимизировать или написать правильно, по канонам (я всё ещё про мобильную разработку говорю). Причём зачастую статьи в блогах как раз этих самых компаний.
C>И отдельный вопрос — почему такие сложности с поддержкой старых платформ? Привязываем основную ветку к последней платформе, ответвляемся к предыдущей и дописываем недостающие компоненты. И так до самого низа. При обновлении основной ветки rebase должен быть без конфликтов, ведь мы не трогаем в основной ветке тот код, что есть в старых ветках. rebase делаем по цепочке от самой current ветки до самой старой. Это так сложно? Сраный сбер нанял кучу разработчиков и их банк-клиент — такое убожество. А клиент торгового терминала настолько убогий, что они забили на рефакторинг старого и просто написали новый! Известны они как "Cбербанк Инвестор" и "СберИнвестор Х". Правда, надо отдаль должное — сбер хотя бы работает в RuStore, чего нельзя сказать о многих других российских приложениях. Половина требует гуглосервисы.
А я бы не отказался даже от ущербного мобильного приложения для rsdn, сейчас сайт сверстан как в 90х годах, читать его на мобилке просто невозможно.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Так объем памяти продолжает расти. Не в 2 раза каждый год, конечно, но растет. PD>Еще недавно 8 Гб было нормально, а сейчас я и не знаю, что есть стандарт де-факто для настольного ПК — 16 или уже 32 ?
Я не знаю, что такое стандарт де-факто. Но вот статистика из местного магазина по ноутбукам (по числу моделей):
4 — 40
8 — 100
16 — 70
32 — 5
На мой взгляд можно смело утверждать, что стандарт де-факто для ноутбука сегодня это 8 GB. При этом цель, на которую надо ориентироваться, чтобы охватить большинство пользователей — 4 GB. В целом это совпадает с моими ощущениями.
Здравствуйте, microuser, Вы писали:
M>А я бы не отказался даже от ущербного мобильного приложения для rsdn, сейчас сайт сверстан как в 90х годах, читать его на мобилке просто невозможно.
Здравствуйте, rudzuk, Вы писали:
R>На ведроиде: touch на кнопке не отпуская палец — появляется tooltip.
Ни разу не видел. Хоть коротко нажми, хоть долго держи — всегда выполняется только основное действие. Это значит, что по умолчанию система не делает различия между коротким и долгим тапом на кнопке.
Если какие-то приложения и показывали tooltip, то явно через колхоз, и в незнакомых приложениях никто, по понятным причинам, этого пробовать не станет.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ> Если какие-то приложения и показывали tooltip, то явно через колхоз, и в незнакомых приложениях никто, по понятным причинам, этого пробовать не станет.
А толку с этого? Long Tap в андроиде — примерный аналог правого клика в винде. Но, если в винде "правокликнуть" любую визуальную кнопку — она заведомо не сработает действием по умолчанию. То есть, можно "правокликать" без опасения, что будет выполнено какое-то "финальное" действие. В андроиде же, если на элемент управления не повешено обработчика Long Tap, то при долгом нажатии тоже вызывается обычный, выполняющий предусмотренное действие.
Это означает, что в андроиде нет безопасного способа "потрогать" элемент, кроме как навести на него мышь (если она есть). Если мыши нет — никто в здравом уме не станет долго жать на элемент, чтобы узнать информацию о нем. В этом и заключается дебилизм разработчиков андроида.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ> R>https://developer.android.com/develop/ui/views/components/tooltips
ЕМ> А толку с этого? Long Tap в андроиде — примерный аналог правого клика в винде. Но, если в винде "правокликнуть" любую визуальную кнопку — она заведомо не сработает действием по умолчанию. То есть, можно "правокликать" без опасения, что будет выполнено какое-то "финальное" действие. В андроиде же, если на элемент управления не повешено обработчика Long Tap, то при долгом нажатии тоже вызывается обычный, выполняющий предусмотренное действие.
ЕМ> Это означает, что в андроиде нет безопасного способа "потрогать" элемент, кроме как навести на него мышь (если она есть). Если мыши нет — никто в здравом уме не станет долго жать на элемент, чтобы узнать информацию о нем. В этом и заключается дебилизм разработчиков андроида.
НажалДолго на копку. Если тултип не вылез отодвинул палец. Вполне безопасно. Лично я на своем 4.4 именно так и делал
Здравствуйте, rudzuk, Вы писали:
R>НажалДолго на копку. Если тултип не вылез отодвинул палец.
Какова доля руководств по использованию андроида, где описана эта техника, в общей массе? То есть — какой примерно процент пользователей имеет возможность ее знать без поиска специальной документации?
R>Лично я на своем 4.4 именно так и делал
А я ни в одном из пользовательских руководств такого не встречал.
Здравствуйте, vsb, Вы писали:
vsb>На мой взгляд можно смело утверждать, что стандарт де-факто для ноутбука сегодня это 8 GB. При этом цель, на которую надо ориентироваться, чтобы охватить большинство пользователей — 4 GB. В целом это совпадает с моими ощущениями.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ> R>НажалДолго на копку. Если тултип не вылез отодвинул палец.
ЕМ> Какова доля руководств по использованию андроида, где описана эта техника, в общей массе? То есть — какой примерно процент пользователей имеет возможность ее знать без поиска специальной документации?
ЕМ> R>Лично я на своем 4.4 именно так и делал
ЕМ> А я ни в одном из пользовательских руководств такого не встречал.
Здравствуйте, vsb, Вы писали:
vsb>На мой взгляд можно смело утверждать, что стандарт де-факто для ноутбука сегодня это 8 GB. При этом цель, на которую надо ориентироваться, чтобы охватить большинство пользователей — 4 GB. В целом это совпадает с моими ощущениями.
Ну а у меня при 8 Гб Windows 10 начала пару лет назад безбожно тормозить. Ничего особенного я на ней не делал. До этого как-то не тормозило.
В итоге заменил одну планку 2 Гб на 8 Гб, стало 14 и не тормозит. FAR говорит, что свободно сейчас 5.38 Гб.
Здравствуйте, Pavel Dvorkin, Вы писали:
vsb>>На мой взгляд можно смело утверждать, что стандарт де-факто для ноутбука сегодня это 8 GB. При этом цель, на которую надо ориентироваться, чтобы охватить большинство пользователей — 4 GB. В целом это совпадает с моими ощущениями.
PD>Ну а у меня при 8 Гб Windows 10 начала пару лет назад безбожно тормозить. Ничего особенного я на ней не делал. До этого как-то не тормозило.
PD>В итоге заменил одну планку 2 Гб на 8 Гб, стало 14 и не тормозит. FAR говорит, что свободно сейчас 5.38 Гб.
У меня с запущенным хромом потребление 3.3/15.9 по Task Manager-у. При том, что у меня винда, мягко говоря, не чистая. Тут Shmj обсуждал какую-то утилиту для проверки автостарта, я у себя запустил — мама родная, чего только не запускается, уже давно пора винду переустанавливать.
Лично мне 4 GB хватит. Да, будет свопиться, ну на SSD это не особо и заметно. 16 у меня из-за игр. Ну если виртуалки запускать, там да, хотя бы 8 желательно, но это уже не юз-кейс для обычных пользователей.
Здравствуйте, vsb, Вы писали:
vsb>У меня с запущенным хромом потребление 3.3/15.9 по Task Manager-у.
А сколько вкладок открыто в Хроме ?
>Тут Shmj обсуждал какую-то утилиту для проверки автостарта, я у себя запустил — мама родная, чего только не запускается, уже давно пора винду переустанавливать.
Да, надо проверить, хотя не думаю, что дело в этом. А переустанавливать-то зачем ?
P.S. Проверил. Действительно, много, но криминала не увидел.
Здравствуйте, vsb, Вы писали:
vsb>Лично мне 4 GB хватит. Да, будет свопиться, ну на SSD это не особо и заметно.
SSD быстро по коцается (там 300 полных перезаписей и диску п да, в лучшем случае — тысяча перезаписей)
vsb>16 у меня из-за игр.
16 ГБ — это минимально приемлемый размер RAM под винду для комфортного сёрфинга вот к примеру щаз занято около 9 из 16 GB (и это ещё щаз без кодинга)
но если по одной две вкладке браузера открывать (и только), то да — может и хватит по 4 GB RAM (но вообще это уже даже на андроид фонах практически минимально приемлемый размер, что уж говорить про ПК и ноуты)
Здравствуйте, Pavel Dvorkin, Вы писали:
vsb>>У меня с запущенным хромом потребление 3.3/15.9 по Task Manager-у.
PD>А сколько вкладок открыто в Хроме ?
Две.
>>Тут Shmj обсуждал какую-то утилиту для проверки автостарта, я у себя запустил — мама родная, чего только не запускается, уже давно пора винду переустанавливать.
PD>Да, надо проверить, хотя не думаю, что дело в этом. А переустанавливать-то зачем ?
Ну я не люблю копаться в загаженной винде, мне проще всё с нуля начать. Обычно раз в полгода-год всё переустанавливаю.
Здравствуйте, vsb, Вы писали:
vsb>Ну я не люблю копаться в загаженной винде, мне проще всё с нуля начать. Обычно раз в полгода-год всё переустанавливаю.
Ну вообще-то переустановка у меня закончится тем, что по AutoRuns будет примерно то же самое, что и сейчас, так как там все по существу.
Здравствуйте, Pavel Dvorkin, Вы писали:
vsb>>Ну я не люблю копаться в загаженной винде, мне проще всё с нуля начать. Обычно раз в полгода-год всё переустанавливаю.
PD>Ну вообще-то переустановка у меня закончится тем, что по AutoRuns будет примерно то же самое, что и сейчас, так как там все по существу.
Ну тогда смысла нет. Я просто часто на своей системе ставлю что-то, что потом нормально не вычищается. Игры любят какой-то мусор засунуть в систему, драйверы какие-нибудь, сертификаты корневые поменять и тд.
Здравствуйте, vsb, Вы писали:
vsb>Лично мне 4 GB хватит. Да, будет свопиться, ну на SSD это не особо и заметно. 16 у меня из-за игр. Ну если виртуалки запускать, там да, хотя бы 8 желательно, но это уже не юз-кейс для обычных пользователей.
Это фантастика какая-то, на 4 Гб уже лет 5 назад всё тормозило безбожно. Тогда это не работа, а посиделки с одной страницей в браузере. Даже когда не надо работать с кодом, у меня несколько вкладок в браузере, 2-3 мессенджера, документы в doc/xls/pdf. Нереально это всё уместить в 4 Гб
Здравствуйте, Nuzhny, Вы писали:
vsb>>Лично мне 4 GB хватит. Да, будет свопиться, ну на SSD это не особо и заметно. 16 у меня из-за игр. Ну если виртуалки запускать, там да, хотя бы 8 желательно, но это уже не юз-кейс для обычных пользователей.
N>Это фантастика какая-то, на 4 Гб уже лет 5 назад всё тормозило безбожно. Тогда это не работа, а посиделки с одной страницей в браузере. Даже когда не надо работать с кодом, у меня несколько вкладок в браузере, 2-3 мессенджера, документы в doc/xls/pdf. Нереально это всё уместить в 4 Гб
Ну у меня нет 2-3 мессенджеров и документы я открываю редко. Мой типичный workflow это открытая идея или vscode и пара страниц в браузере с документацией. Мессенджер у меня на телефоне, я в браузере их могу открыть, если что-то надо напечатать, но это скорей исключение.
Впрочем ладно, у меня на основном ноутбуке 64 GB RAM и пробовать работать на 4 я не буду. Но это не отменяет факта, что в магазине полно ноутбуков с 4 GB и вряд ли они там просто так лежат.
Здравствуйте, vsb, Вы писали:
vsb>Ну попробуй сам что-то написать. Разработка на андроиде ущербна сама по себе. Я вот позавчера поставил андроид студию. Прям на чистый компьютер с нуля. Запускаю, создаю проект с пустым окошком. IDE Error.
Какая у тебя на компе OS? Какую версию Android Studio установил?
Напиши, пожалуйста, подробнее (я знаком с Android Studio как в Windows, так и в Linux).
vsb>Они его вообще не тестируют. Глюки повсеместно. В ихнем SDK костыли идут вообще по дефолту. У меня дёргается глаз, когда мне приходится ради простейшего приложения включать многомегабайтные библиотеки.
Ну так это тренд IT отрасли последнее десятилетие.
vsb>В андроиде так положено прям от производителя — support libraries которые якобы фиксят баги телефона. Т.е. вместо того, чтобы пофиксить баги в самом телефоне, они предлагают эти баги фиксить в каждом приложении, которое запускается на этом телефоне.
Не совсем так. Т. к. каждая модель телефона имеет конструктивные особенности (размеры и разрешение экрана, чипсет и т.д.),
то оказывается, что новые разработки идут далеко не на всех моделях аппаратов, и не на всех версиях Android OS.
Для упрощения понимания этого, есть понятие API levels: https://apilevels.com
В самом начале разработки проекта в среде Android Studio — выбираем: какие уровни API должен поддерживать наш проект.
Жизненный цикл activity — там наверное можно диссертацию писать. А жизненный цикл fragment внутри activity — сомневаюсь, что кто-то вообще понимает это всё.
Ну и, конечно же, литература:
1) Android программирование для профессионалов Б.Филллипс, К.Стюарт, К.Марсикано (3-е издание) BigNerdRanch. Именно 3-е по Java (4-е по Kotlin).
2) Head First Программирование для Android Д.Гриффитс (2-е издание) O'REILLY.
3) Android для разработчиков П.Дейтел, Х.Дейтел, А.Уолд (3-е издание).
P.S. Конечно же, для программиста из desktop development в разработке под Android немало непривычных моментов.
Однко — дорогу осилит идущий
Здравствуйте, vsb, Вы писали:
vsb>Ну тогда смысла нет. Я просто часто на своей системе ставлю что-то, что потом нормально не вычищается. Игры любят какой-то мусор засунуть в систему, драйверы какие-нибудь, сертификаты корневые поменять и тд.
Здравствуйте, vsb, Вы писали:
vsb>Я не знаю, что такое стандарт де-факто. Но вот статистика из местного магазина по ноутбукам (по числу моделей):
vsb>4 — 40 vsb>8 — 100 vsb>16 — 70 vsb>32 — 5
vsb>На мой взгляд можно смело утверждать, что стандарт де-факто для ноутбука сегодня это 8 GB. При этом цель, на которую надо ориентироваться, чтобы охватить большинство пользователей — 4 GB. В целом это совпадает с моими ощущениями.
Есть у меня к этой выборке два простых вопроса:
a) Какой основной контингент покупателей в этом магазине? Домохозяйки? Программисты? Геймеры? Офисные_менеджеры?
b) Как соотносится покупка нового (среднестатистического) ноутбука к средне-месячным доходам покупателя?
Ведь одно дело — 1:1 когда покупатель может каждый месяц (теоретически) купить новый ноут,
другое дело — 1:10 когда покупателю десять месяцев, без любых других расходов, копить на новый ноут.
P.S. Если основной контингент — состоятельные (может за счёт мужей) домохозяйки — то имеем именно такой расклад.
Здравствуйте, AlexGin, Вы писали:
AG>P.S. Если основной контингент — состоятельные (может за счёт мужей) домохозяйки — то имеем именно такой расклад.
Плюс к этому я бы ещё добавил вариант купитьноут попроще, а потом доставить на него память/диск. Прогресс в процессорах сейчас не сказать бы что большой. А в ноуты с дохлыми, но достаточными процами ставят мало памяти и маленький диск. Поэтому есть вариант купить подешевле и проапгрейдить своими силами чуть ли не бу комплектующими.
P.S. Я на всех своих ноутах, купленных в течение последних 10 лет менял память и диски, на ноутах родственников тоже.
Здравствуйте, AlexGin, Вы писали:
vsb>>Ну попробуй сам что-то написать. Разработка на андроиде ущербна сама по себе. Я вот позавчера поставил андроид студию. Прям на чистый компьютер с нуля. Запускаю, создаю проект с пустым окошком. IDE Error.
AG>Какая у тебя на компе OS? Какую версию Android Studio установил? AG>Напиши, пожалуйста, подробнее (я знаком с Android Studio как в Windows, так и в Linux).
Здравствуйте, Pavel Dvorkin, Вы писали:
vsb>>Ну тогда смысла нет. Я просто часто на своей системе ставлю что-то, что потом нормально не вычищается. Игры любят какой-то мусор засунуть в систему, драйверы какие-нибудь, сертификаты корневые поменять и тд.
PD>Добавить памяти и создать виртуалку.
Игры в виртуалке не работают.
На самом деле если я буду собирать следующий игровой компьютер, я туда установлю две видеокарты: 1 для хоста и 1 для гостя. На хосте поставлю линукс, а вторую видеокарту буду прокидывать в гостя. Насколько я понимаю, при этом производительность будет хорошая. Но на текущем компьютере только одна видеокарта.
Здравствуйте, AlexGin, Вы писали:
vsb>>Я не знаю, что такое стандарт де-факто. Но вот статистика из местного магазина по ноутбукам (по числу моделей):
vsb>>4 — 40 vsb>>8 — 100 vsb>>16 — 70 vsb>>32 — 5
vsb>>На мой взгляд можно смело утверждать, что стандарт де-факто для ноутбука сегодня это 8 GB. При этом цель, на которую надо ориентироваться, чтобы охватить большинство пользователей — 4 GB. В целом это совпадает с моими ощущениями.
AG>Есть у меня к этой выборке два простых вопроса: AG>a) Какой основной контингент покупателей в этом магазине? Домохозяйки? Программисты? Геймеры? Офисные_менеджеры? AG>b) Как соотносится покупка нового (среднестатистического) ноутбука к средне-месячным доходам покупателя? AG>Ведь одно дело — 1:1 когда покупатель может каждый месяц (теоретически) купить новый ноут, AG>другое дело — 1:10 когда покупателю десять месяцев, без любых других расходов, копить на новый ноут.
У меня нет ответов на эти вопросы. Это обычный рядовой магазин компьютерной техники, думаю, что контингент там самый, что ни на есть, средний. Доходы в Казахстане не очень большие, ну можно считать, что примерно 10-20 тысяч рублей у большинства.
Здравствуйте, vsb, Вы писали:
vsb>macOS, последняя версия.
Ну тут я ничего не подскажу —
я с Android Studio работаю в Windows и Linux,
с macOS я никогда не сталкивался.
Но вообще с Android Studio работать достаточно удобно и комфортно, важно —
скачать перед работой все требуемые библиотеки разработки:
Настроим установленную Android Studio:
вызвать окно настроек можно как через пункт “Configure”,
так и через меню: File/Settings далее: “Appearance & Behavior /System Settings/Android SDK”.
На закладке "SDK Platforms" выбираем все птички чек-боксов от Android 4.4 (KitKat) и выше.
На закладке "SDK Tools" выбираем все птички чек-боксов имеющихся в окне.
Здравствуйте, cppguard, Вы писали:
C>Абсолютно у всех компаний, бизнесом которых не является само приложение, мобильные приложения ущербны чуть более чем совсем. Или тормознутые, или требуют кучу прав, или нестандартный вырвиглазный UI. Но чаще — всё это вместе. А ещё приложения дико колбасит, если вдруг посередине работы пропала сеть. Или приложение ушло в фон, в это время пропала сеть, и приложение вышло из фона. Речь про Android. И я спрашиваю, потому что сам никогда не писал за деньги под эту платформу, но есть опыт разработки приложения потокового вещания. И я помню, что Гугл корошо всё задокументировал — просто нужно пойти и прочитать. Вобщем, что не так с мобильными разработчиками?
Очевидно, ответ уже прозвучал: "сам никогда не писал за деньги под эту платформу" В кратце:
Компании, у которых бизнес где то там, слишком часто не умеют управлять разработкой софта. Например, многие банковские приложения плохи не потому, что там жээс, а потому, что разработкой частенько управляют банковские работники — пять менеджеров на одного разработчика, договориться не могут, требования меняют прямо под релиз, а сверх этого безопасники разных сортов и куча других непонятно каким боком причастных.
Однажды мвд-шник на серьезных щах рассказывал мне, тогда студенту, что софт вообще писать не надо — "хули ты дурью маешься, всё уже готово, просто скопируй куда надо и всё". Очевидно, если такого поставить ответсвенным за разработку софта, он будет воплощать именно такие принципы.
C>И отдельный вопрос — почему такие сложности с поддержкой старых платформ? Привязываем основную ветку к последней платформе, ответвляемся к предыдущей и дописываем недостающие компоненты. И так до самого низа. При обновлении основной ветки rebase должен быть без конфликтов, ведь мы не трогаем в основной ветке тот код, что есть в старых ветках.
Потому, что чудовищно дорого, даже если всё делать черипиком. Здесь нет разницы, андроид или нет.
Вот, скажем, я теоретически могу чери-пиком бакпортить фиксы и даже ичи версий на + пять назад.
На самом деле
1. даже такой вариант это дорого, т.к. это означает бОльшее количество приседаний — багфикса, билдов, тестов, инфраструктуры, планирования итд т.к. каждая версия при бакпорте дает некоторое количество дополнительной работы и так всё время жизни. Фактически умножаем время мейнтенанса на количество поддерживаемых версий.
2. юзерам нет смысла переходить на новые версии, пока мейнтейнятся старые — нужна новая схема монетизации
3. чем глубже углубляемся в обратную совместимость, тем меньше остаётся времени на разработку новых фич
Итого — п, 1 и 3 влекут удорожание, а п2 не так то легко протащить. При нынешних зп в ИТ, это все удорожания это ужос-ужос, сразу-нет, и всё такое.
Поэтому более разумной является другая стратегия — мейнтенить основную версию, а 1-2 старые багфиксить. Что мы и наблюдаем.
Здравствуйте, vsb, Вы писали:
vsb>Ну я не люблю копаться в загаженной винде, мне проще всё с нуля начать. Обычно раз в полгода-год всё переустанавливаю.
А если не загаживать, то можно и по пять-шесть лет не трогать.
Здравствуйте, velkin, Вы писали:
V>Существует множество мобильных версий приложений, но при этом нет десктоповых приложений. Это говорит о том, что разработчики явно не понимают, что делают. Ведь уровень мобильного приложения должен соответствовать десктоповому. И если они не могут сделать нормальное десктоповое приложение, то и мобильное не смогут.
Десктоп как платформа уже сдох. Его додушивает браузер.
V>А много ли мы видим десктоповых клиентов к какому-нибудь веб-сервису. Очевидно нет. Где-то статья была в интернете о том, что мобильные приложения по большей части не нужны, так как пользователи не будут их устанавливать, что выявляется путём подсчёта установленных приложений.
Пользователям нужны не сверла, а отверстия. Т.е. не десктоп/мобайл/веб приложения, а услуги конкретного сервиса. Все три типа приложений писать и поддерживать это чудовищно дорого.
В идеале — одно приложение, которое может работать везде. Сейчас это одно приложение это браузерное. Т.е. к этому и идем.
Здравствуйте, Serginio1, Вы писали:
S>Неправда. Xamarin. Announcing .NET MAUI for .NET 7 General Availability S>Жалко конечно, что Windows Mobile для 10 ки похерили. Там и UWP с .Net Native. Но сильно опоздали.
Такое надо было лет 20 назад выпускать. Но тогда микрософт всех перехитрили, включая себя, и ускорились за счет того, что прибили платформу гвоздями к винапи, а system.drawing к глюкодрому gdiplus.
Здравствуйте, Codealot, Вы писали:
C>Можно подумать, что веб-приложения не ущербны. У моего банка, например — это лютый ужас. Причем банк далеко не из последних и бедных. Или, например, здесь в компании (опять же не из последних и бедных) есть веб-портал для организации командировок — так в этом унылом говнище регистрация пользователя через веб есть, но она в принципе не работает и похоже никогда не работала. Только через телефон
C>Да и десктопные понемногу двигаются в том же направлении. C>А ответ простой — программистов сейчас набирают главным образом не за умение кодить, а за умение понравиться. Весь этот emotional intelligence и прочий бред.
Кодинга в работе программиста около 10%, всё остальное — разные виды коммуникации.
emotional intelligence это не умение нравится, а просто intelligence, ключевая вещь для коммуникации, нужна практически везде. Например, уже на этапе вхождения в коллектив. Если с коллективом отношения не сложились, кодинг здесь ничего не спасёт.
Слишком часто два крутых девелопера не могут решить тривиальную задачу, потому что друга на в х.й не ставят.
Здравствуйте, Pauel, Вы писали:
S>>Неправда. Xamarin. Announcing .NET MAUI for .NET 7 General Availability S>>Жалко конечно, что Windows Mobile для 10 ки похерили. Там и UWP с .Net Native. Но сильно опоздали.
P>Такое надо было лет 20 назад выпускать. Но тогда микрософт всех перехитрили, включая себя, и ускорились за счет того, что прибили платформу гвоздями к винапи, а system.drawing к глюкодрому gdiplus.
Ну UWP то как раз отвязана от винапи. Там больше проблемы как раз с .Net Core. Они нормальную версию только с .Net Core 2 сделали в 2017-08-14 https://en.wikipedia.org/wiki/.NET
Здравствуйте, Евгений Музыченко, Вы писали:
P>>Пользователям нужны не сверла, а отверстия.
ЕМ>Отверстия нужны пользователям отверстий. Пользователям сверл нужны таки сами сверла.
Я имел ввиду потребности. Нет у человека потребностей в приложениях. А вот в конечных услугах потребности были всегда.
Здравствуйте, Pauel, Вы писали:
P>Я имел ввиду потребности. Нет у человека потребностей в приложениях. А вот в конечных услугах потребности были всегда.
То есть, лично у Вас нет потребностей в зубной щетке, мыле и шампуне, а есть потребность лишь в сторонних "конечных услугах" по ежедневной чистке зубов и мойке кожи и волос?
Здравствуйте, Евгений Музыченко, Вы писали:
P>>Я имел ввиду потребности. Нет у человека потребностей в приложениях. А вот в конечных услугах потребности были всегда.
ЕМ>То есть, лично у Вас нет потребностей в зубной щетке, мыле и шампуне, а есть потребность лишь в сторонних "конечных услугах" по ежедневной чистке зубов и мойке кожи и волос?
Конечная услуга это не чистка зубов, а чистые зубы, чистая кожа, чистые волосы.
В зубной щетке, мыле, шампуне, колбасе итд потребностей нет, есть потребность в здоровье, творчестве, удовольствии и тд.
Здравствуйте, Serginio1, Вы писали:
S> Ну UWP то как раз отвязана от винапи. Там больше проблемы как раз с .Net Core. Они нормальную версию только с .Net Core 2 сделали в 2017-08-14 S>А в 2018 решили все похерить https://ru.wikipedia.org/wiki/Windows_10_Mobile
Вот такие шарахания отталкивают людей от микрософтовского десктопа. Собственно, у меня ощущение, что микрософт понабирала дизайнеров, которые сидят в макоси и рисуют ровно то, что видят. Какой смысл писать именно под винду — непонятно. Проще писать под электрон, благо браузерный движок постепенно вбирает в себя ключевые апи ос, и со временем приложения перекочуют именно туда.
Здравствуйте, Pauel, Вы писали:
P>Конечная услуга это не чистка зубов, а чистые зубы, чистая кожа, чистые волосы.
Чистые зубы, волосы и кожа — это не "услуга", а "состояние". Как нынче модно говорить — "деталь образа". По Вашим высказываниям видно, что Вы читали популярную литературу, любите ее пересказывать, но плохо поняли основы.
P>В зубной щетке, мыле, шампуне, колбасе итд потребностей нет, есть потребность в здоровье, творчестве, удовольствии и тд.
То есть, я правильно понимаю, что Вы не чистите зубы и не моетесь самостоятельно, а покупаете соответствующие услуги — или, хотя бы, стремитесь к этому? Колбасу Вам нравится "непосредственно вкушать", или "испытывать состояние удовольствия, возникающего после поедания колбасы", а сама колбаса здесь лишняя?
А как насчет секса? Вы предпочли бы непосредственно оказываться в состоянии послеоргазменного отдыха, без "всех этих нелепых телодвижений", и тем более — без объекта?
Подавляющее большинство людей, как ушедших с "микрософтовского десктопа", так и остающихся на нем, даже понятия не имеет о какой-то там Windows Mobile.
Здравствуйте, Pauel, Вы писали:
P>Здравствуйте, Serginio1, Вы писали:
S>> Ну UWP то как раз отвязана от винапи. Там больше проблемы как раз с .Net Core. Они нормальную версию только с .Net Core 2 сделали в 2017-08-14 S>>А в 2018 решили все похерить https://ru.wikipedia.org/wiki/Windows_10_Mobile
P>Вот такие шарахания отталкивают людей от микрософтовского десктопа. Собственно, у меня ощущение, что микрософт понабирала дизайнеров, которые сидят в макоси и рисуют ровно то, что видят. Какой смысл писать именно под винду — непонятно. Проще писать под электрон, благо браузерный движок постепенно вбирает в себя ключевые апи ос, и со временем приложения перекочуют именно туда.
А при чем тут Desktop? Речь то о Windows 10 Mobile
Здравствуйте, Евгений Музыченко, Вы писали:
P>>Конечная услуга это не чистка зубов, а чистые зубы, чистая кожа, чистые волосы.
ЕМ>Чистые зубы, волосы и кожа — это не "услуга", а "состояние". Как нынче модно говорить — "деталь образа". По Вашим высказываниям видно, что Вы читали популярную литературу, любите ее пересказывать, но плохо поняли основы.
Это никакая не деталь Чистые зубы, волосы, кожа это составляющие "здоровье", в чем потребность у человека была задолго до появления городов.
P>>В зубной щетке, мыле, шампуне, колбасе итд потребностей нет, есть потребность в здоровье, творчестве, удовольствии и тд.
ЕМ>То есть, я правильно понимаю, что Вы не чистите зубы и не моетесь самостоятельно, а покупаете соответствующие услуги — или, хотя бы, стремитесь к этому?
Ты как то усиленно пытаешься переиначить сказанное. Я говорю о потребностях, а не о том, что делаю или не делаю лично.
У человека есть потребность в здроровье. не в зубной щетве, а в здоровых зубах.
>Колбасу Вам нравится "непосредственно вкушать", или "испытывать состояние удовольствия, возникающего после поедания колбасы", а сама колбаса здесь лишняя?
Потребность не в колбасе, а в утолении голода, питании для организма, т.к. это условие продолжения жизни.
ЕМ>А как насчет секса? Вы предпочли бы непосредственно оказываться в состоянии послеоргазменного отдыха, без "всех этих нелепых телодвижений", и тем более — без объекта?
Это потребность в отдыхе, удовольствии, продолжении рода.
Здравствуйте, Serginio1, Вы писали:
P>>Когда на него переведут Skype, Teams, Azure, Mssql и подобные вещи?
S> А Azure и MSSql то ту т причем. Ты про SQL Server Management Studio?я
Здравствуйте, Pauel, Вы писали:
P>Чистые зубы, волосы, кожа это составляющие "здоровье", в чем потребность у человека была задолго до появления городов.
Верно. А имеет ли человек сейчас возможность получить это "здоровье" в виде "конечной услуги", без самостоятельного пользования зубной щеткой, мылом и шампунем? Если да, то где Вы это получаете?
P>Я говорю о потребностях, а не о том, что делаю или не делаю лично.
С какой целью Вы говорите о потребностях — чтобы просто поговорить, или чтобы указать способы их удовлетворения? Если второе — жду от Вас конкретной информации.
P>Потребность не в колбасе, а в утолении голода, питании для организма, т.к. это условие продолжения жизни.
То есть, Вы едите исключительно для того, чтобы питать организм? Если будет возможность делать это, например, с помощью внутривенного вливания — откажетесь от еды?
P>Это потребность в отдыхе, удовольствии, продолжении рода.
И какую "конечную услугу" в этой сфере нужно предложить Вам, чтобы Вы отказались от секса?
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, Pauel, Вы писали:
S>>> А Azure и MSSql то ту т причем. Ты про SQL Server Management Studio?я
P>>У них у всех приложения есть на электроне. S> Приложение или морда к приложению? Все течет и все меняется. Блазор в виде WebWindow намного выгоднее Электрона
Что там выгодного? По твоей ссылке показано, что товарищи наконец слепили дотнет апи к хрому. Ужос! Такое было сделано еще 8 лет назад, т.е. 8 лет назад появился первый нормальный вариант компонента.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, Pauel, Вы писали:
P>>Чистые зубы, волосы, кожа это составляющие "здоровье", в чем потребность у человека была задолго до появления городов.
ЕМ>Верно. А имеет ли человек сейчас возможность получить это "здоровье" в виде "конечной услуги", без самостоятельного пользования зубной щеткой, мылом и шампунем?
Имеет. Я же уже сказал — 99% времени человечество прожило без зубной щетки, мыла и шампуня. Неужели не понятно?
> Если да, то где Вы это получаете?
Ты хочешь меня пообсуждать, не терпится да?
P>>Я говорю о потребностях, а не о том, что делаю или не делаю лично.
ЕМ>С какой целью Вы говорите о потребностях — чтобы просто поговорить, или чтобы указать способы их удовлетворения? Если второе — жду от Вас конкретной информации.
Я говорю о том, что нужно отделять потребности от способа их удовлетворения.
P>>Потребность не в колбасе, а в утолении голода, питании для организма, т.к. это условие продолжения жизни.
ЕМ>То есть, Вы едите исключительно для того, чтобы питать организм? Если будет возможность делать это, например, с помощью внутривенного вливания — откажетесь от еды?
Именно так и делают во многих случаях, например, в больнице. Если делать это постоянно, это создаёт другие проблемы для здоровья.
P>>Это потребность в отдыхе, удовольствии, продолжении рода.
ЕМ>И какую "конечную услугу" в этой сфере нужно предложить Вам, чтобы Вы отказались от секса?
Както не интересовался. Забавно что ты снова меня пообсуждать хочешь.
Здравствуйте, Pauel, Вы писали:
P>Что там выгодного? По твоей ссылке показано, что товарищи наконец слепили дотнет апи к хрому. Ужос! Такое было сделано еще 8 лет назад, т.е. 8 лет назад появился первый нормальный вариант компонента.
P>Внутри браузера то какой код работать будет, ы?
Да работает. Но не на Webassembly, а на .Net
То есть вместо Mono и интерпретации .Net кода запускается среда с компиляцией сборок, аналогично компиляции на сервере.
Блазор чем и хорош, что он может выполняться где угодно и как угодно.
Вот в свое время нарыл кучу ссылок https://www.rsdn.org/forum/dotnet/7737579.all
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Pauel, Вы писали:
P>99% времени человечество прожило без зубной щетки, мыла и шампуня.
А еще больше времени оно прожило без "конечных услуг" в их современном понимании. Дальше разжевывать?
P>Ты хочешь меня пообсуждать
Не пообсуждать, а выяснить, понимаете ли Вы смысл собственных утверждений, или "этот пацак все время говорит на языках, продолжения которых не знает".
P>Я говорю о том, что нужно отделять потребности от способа их удовлетворения.
Ну так расскажите нам, как потребность в чистоте зубов или сексуальном удовольствии отделить от известных ныне способов их удовлетворения. Лучше всего — на личном примере.
P>Именно так и делают во многих случаях, например, в больнице.
Вы, очевидно, полагали, что мне это неизвестно?
P>Если делать это постоянно, это создаёт другие проблемы для здоровья.
Так как же будет выглядеть "конечная услуга" для означенной потребности?
Здравствуйте, Евгений Музыченко, Вы писали:
P>>99% времени человечество прожило без зубной щетки, мыла и шампуня.
ЕМ>А еще больше времени оно прожило без "конечных услуг" в их современном понимании. Дальше разжевывать?
Намекаешь, что пока не было медицины, не было ни здоровья ни потребности в нём? Вот так поворот!
P>>Ты хочешь меня пообсуждать
ЕМ>Не пообсуждать, а выяснить, понимаете ли Вы смысл собственных утверждений
По моему ты переиначиваешь фразы. Сказано — потребность в здоровье, а ты продолжаешь вопрошать про услуги и зубные щетки
P>>Я говорю о том, что нужно отделять потребности от способа их удовлетворения.
ЕМ>Ну так расскажите нам, как потребность в чистоте зубов или сексуальном удовольствии отделить от известных ныне способов их удовлетворения.
Что мешает тебе погуглить, как люди решали эти вопросы?
Заходим на какой сайт "что делать если", и смотрим, как содержать зубы в порядке если нет ни зубной пасты, ни щетки, ни магазина
1 относясь к ним бережно, избегая грызть все подряд. Это и сейчас актуально
2 употреблять здоровую пищу без лишних сахаров
3 правильное питание особенно в детстве
4 поддерживать чистоту полости рта — есть вещи типа моркови и подобных вещей, они снимают налет, пить воду
> Лучше всего — на личном примере.
Ты все рвёшся на личности перейти. Не надо себя сдерживать — переходи сразу к делу.
P>>Именно так и делают во многих случаях, например, в больнице.
ЕМ>Вы, очевидно, полагали, что мне это неизвестно?
Очевидно, что я считаю ты валяешь дурака. Юродствуешь, проще говоря.
P>>Если делать это постоянно, это создаёт другие проблемы для здоровья.
ЕМ>Так как же будет выглядеть "конечная услуга" для означенной потребности?
Потребность всё та же — питание, никуда она не девалась
Здравствуйте, Pauel, Вы писали:
P>Здравствуйте, Serginio1, Вы писали:
P>>>Внутри браузера то какой код работать будет, ы? S>>Да работает. Но не на Webassembly, а на .Net
P> Что за чудо такое, дотнет в хроме? Поделись ссылой?
Blazor WebAssembly поддерживает упреждающую компиляцию (AOT), с помощью которой вы можете скомпилировать код .NET непосредственно в WebAssembly. Компиляция AOT позволяет повысить производительность среды выполнения за счет увеличения размера приложения.
Без включения компиляции AOT приложения Blazor WebAssembly выполняются в браузере с использованием интерпретатора промежуточного языка .NET, реализованного в WebAssembly. Поскольку код .NET интерпретируется, приложения обычно выполняются медленнее, чем на стороне сервера среды выполнения JIT .NET. Компиляция AOT позволяет решить эту проблему с производительностью, выполняя компиляцию кода .NET приложения непосредственно в WebAssembly для выполнения собственной сборки через браузер. Повышение производительности AOT может привести к значительному улучшению приложений, выполняющих ресурсоемкие задачи. Недостаток использования компиляции AOT заключается в том, что приложения, скомпилированные с помощью AOT, обычно больше их аналогов, интерпретируемых с помощью IL, поэтому загрузка клиента при первом запросе обычно занимает больше времени.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
P>>>>Внутри браузера то какой код работать будет, ы? S>>>Да работает. Но не на Webassembly, а на .Net
P>> Что за чудо такое, дотнет в хроме? Поделись ссылой?
S>Я тебе могу ссылки на свои произведения
Здравствуйте, Pauel, Вы писали:
P>То есть, всё таки Webassembly
А что в этом плохого?
Что касается десктопа, то все выполняется в среде или можно скомпилировать через Native Aot
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Но если почти на тех же процессорах делать в несколько раз больше действий (без которых можно бы и обойтись), то тормоза будут расти, никуда не денешься.
Здравствуйте, Pauel, Вы писали:
P>Кодинга в работе программиста около 10%, всё остальное — разные виды коммуникации.
И такое я тоже видел. Так же как видел и такое, когда 90% — это кодинг. И норма для инженера — это второе, а первое — это гнилая отрыжка некомпетентного говноменеджерства.
P>Слишком часто два крутых девелопера не могут решить тривиальную задачу, потому что друга на в х.й не ставят.
А менеджер где и чем занимается, когда у него такая фигня в команде происходит? Клепает презентации и ждет, когда все как-нибудь само собой решится?
Слишком часто целая команда из двух десятков "хороших тим плейеров" с высоченным EQ делают работу вместо одного крутого девелопера, причем дольше и намного хуже.
Здравствуйте, Codealot, Вы писали:
P>>Кодинга в работе программиста около 10%, всё остальное — разные виды коммуникации.
C>И такое я тоже видел. Так же как видел и такое, когда 90% — это кодинг. И норма для инженера — это второе, а первое — это гнилая отрыжка некомпетентного говноменеджерства.
Если 90% времени это кодинг, то значит на подумать времени не было, нет и не будет.
Статистика такая, что бОльшую часть времени уходит на мейнтенанс, проектирование, документирование и отладку. А вот когда экомномят на таких активностях, то получается надо струячить код, ибо думать некогда.
Мейнтенанс это 90% багфкса — нужно воспроизвести баг, что далеко не всегда тривиально, поколупаться с отладкой, сходить к QA, посмотреть что у них, вернуться к себе. Тут оказывается, QA в другой таймзоне и работать не начинал. Подождал, созвонились, поговорили, выяснили подробности, потыкали — воспроизвелось. Типичный фикс — пара строчек от силы на полчаса.
Или так — надо написать, какое решение — не ясно, сначала надо придумать, выбрать вариант, и только потом закодить, протестировать вручную n раз и фиксануть накидать пару тройку тестов.
В процессе этого надо поговорить с тем или иным коллегой, выяснить кое какие подробности по компоненту который они писали.
Отдельная ведь код-ревью, когда коллега присылает PR на ревью, надо прочитать, покаментировать, обсудитить. Повторить цикл по количеству пуллреквестов.
Ровно то же, только наоборот, со своими изменениями.
После этого всего приходит QA и спрашивает, а на какие компоненты повлиял фикс. Надо поговорить, подобрать наилучшую стратегию для тестирования.
А еще периодически надо фиксить билды — здесь куча времени уходит на ожидание и разбор логов.
Потом приходит коллега, которому нужна помощь — он не знает как работает вон тот компонент, а там всё завязано на древнее легаси.
Проектирование, документирование они вообще слабо привязаны к кодингу, а отнимают чудовищное количество времени.
P>>Слишком часто два крутых девелопера не могут решить тривиальную задачу, потому что друга на в х.й не ставят. C>А менеджер где и чем занимается, когда у него такая фигня в команде происходит? Клепает презентации и ждет, когда все как-нибудь само собой решится?
Ну как же — в данном случае менеджер взял двух крутых девелоперов игнорируя что они никакие не коммандные игроки, а жосцкие индивидуалисты. Это и есть причина проблемы.
Дальше ему только и остаётся, что сидеть с ними, не дай бог они весь проект разнесут на кусочки.
C>Слишком часто целая команда из двух десятков "хороших тим плейеров" с высоченным EQ делают работу вместо одного крутого девелопера, причем дольше и намного хуже.
Здравствуйте, Pauel, Вы писали:
P>Если 90% времени это кодинг, то значит на подумать времени не было, нет и не будет.
Кодинг — это значит не только непосредственно писать код, но и думать. А вот когда 90% времени треплют языком, как предлагаешь ты — тогда времени на подумать точно нет.
P>Статистика такая, что бОльшую часть времени уходит на мейнтенанс, проектирование, документирование и отладку. А вот когда экомномят на таких активностях, то получается надо струячить код, ибо думать некогда.
Да, когда вместо отладки и прочего треплют языком — полная фигня получается.
P>Подождал, созвонились, поговорили
P>Потом приходит коллега, которому нужна помощь — он не знает как работает вон тот компонент, а там всё завязано на древнее легаси.
Так и запишем — документации нет, код полное говно.
P>После этого всего приходит QA и спрашивает, а на какие компоненты повлиял фикс.
То есть, по факту тестов тоже нет.
P>Проектирование, документирование они вообще слабо привязаны к кодингу, а отнимают чудовищное количество времени.
Здравствуйте, Pauel, Вы писали:
P>Намекаешь, что пока не было медицины, не было ни здоровья ни потребности в нём?
Намекаю, что Вы этаким менторским тоном сказанули "А", а как сказать "Б", толком не знаете.
P>По моему ты переиначиваешь фразы. Сказано — потребность в здоровье, а ты продолжаешь вопрошать про услуги и зубные щетки
Судя по всему, Вы так увлеклись, что позабыли контекст. Напоминаю: "Пользователям нужны не сверла, а отверстия", "Нет у человека потребностей в приложениях. А вот в конечных услугах потребности были всегда". Вот я и жду объяснения, какую "конечную услугу" мне нужно выбрать, чтобы удовлетворить свою ежедневную потребность в чистоте зубов, не прибегая к зубной щетке.
P>Заходим на какой сайт "что делать если", и смотрим, как содержать зубы в порядке если нет ни зубной пасты, ни щетки, ни магазина P>1 относясь к ним бережно, избегая грызть все подряд. Это и сейчас актуально P>2 употреблять здоровую пищу без лишних сахаров P>3 правильное питание особенно в детстве P>4 поддерживать чистоту полости рта — есть вещи типа моркови и подобных вещей, они снимают налет, пить воду
А где здесь "конечная услуга"? Я тут вижу сплошь инструменты — сиречь аналоги зубной щетки. Отверстие тоже можно проделать без сверла. Однако, если мы зайдем на сайт "что делать если", то снова увидим там прежде всего инструменты, а не предложения "конечных услуг" в виде "отверстия под ключ".
P>Ты все рвёшся на личности перейти.
А иначе никак. Вы рассказывали о неких сферических пользователях в вакууме, которые существуют неизвестно где. В таких случаях лучше всего предложить рассказчику выступить в роли такого пользователя. Или чукча — не читатель?
ЕМ>>Так как же будет выглядеть "конечная услуга" для означенной потребности?
P>Потребность всё та же — питание, никуда она не девалась
Так где же мне, все-таки, получить конечную услугу в области питания, не пользуясь ложкой, вилкой, посудой и всем остальным? У меня, по-Вашему, есть потребность в такой услуге. Кто ее предоставляет? Почему я нигде не вижу таких предложений, а вижу только ложки, вилки, тарелки, чашки и прочие инструменты для самостоятельного питания?
Здравствуйте, Евгений Музыченко, Вы писали:
P>>Намекаешь, что пока не было медицины, не было ни здоровья ни потребности в нём?
ЕМ>Намекаю, что Вы этаким менторским тоном сказанули "А", а как сказать "Б", толком не знаете.
Уже сказано многажды, осталось прочесть. Открой пирамиду Маслоу или подобную ей, и покажи ссылкой, в каком месте там "зубная щетка"
P>>По моему ты переиначиваешь фразы. Сказано — потребность в здоровье, а ты продолжаешь вопрошать про услуги и зубные щетки
ЕМ>Судя по всему, Вы так увлеклись, что позабыли контекст. Напоминаю: "Пользователям нужны не сверла, а отверстия", "Нет у человека потребностей в приложениях. А вот в конечных услугах потребности были всегда". Вот я и жду объяснения, какую "конечную услугу" мне нужно выбрать, чтобы удовлетворить свою ежедневную потребность в чистоте зубов, не прибегая к зубной щетке.
В который раз говорю — нет потребности чистить зубы. Есть базовая потребность иметь здоровье, в т.ч. с зубами.
P>>4 поддерживать чистоту полости рта — есть вещи типа моркови и подобных вещей, они снимают налет, пить воду
ЕМ>А где здесь "конечная услуга"? Я тут вижу сплошь инструменты — сиречь аналоги зубной щетки.
Здесь удовлетворяется базовая потребность — здоровье. У тебя же здоровье стало синонимом зубной щетки.
ЕМ>А иначе никак.
Вероятно это лично ты иначе не умеешь. Я другого объяснения не вижу.
P>>Потребность всё та же — питание, никуда она не девалась
ЕМ> У меня, по-Вашему, есть потребность в такой услуге.
У тебя есть потребность в здоровье, питании и тд. Соответствующие услуги давно уже так и называются. Но продолжаешь смотреть на это не как на потребность, а как на зубную щетку.
Здравствуйте, Codealot, Вы писали:
P>>Если 90% времени это кодинг, то значит на подумать времени не было, нет и не будет.
C>Кодинг — это значит не только непосредственно писать код, но и думать. А вот когда 90% времени треплют языком, как предлагаешь ты — тогда времени на подумать точно нет.
Кодинг это именно написание кода. Думать — это за проектирование, совершенно отдельный вид деятельности. В единицах кода это никак не выражается. Например, для "подумать" нужно понять требования, которые вообще никак к коду не привязаны — они одинаковы вне зависимости от ЯП, технологий и тд. Причина простая — требования растут от домена, а не от кода. И вот на это уходит основное время.
Т.е. вместо "кодить, кодить, кодить" используем "прочитал, подумал, понял, записал решение"
P>>Статистика такая, что бОльшую часть времени уходит на мейнтенанс, проектирование, документирование и отладку. А вот когда экомномят на таких активностях, то получается надо струячить код, ибо думать некогда. C>Да, когда вместо отладки и прочего треплют языком — полная фигня получается.
Вместо отладки частенько эффективнее спросить человека, например, он может рассказать то, чего в коде нет, и быть не может. Очевидно, что код не может вместить всю документацию.
P>>Потом приходит коллега, которому нужна помощь — он не знает как работает вон тот компонент, а там всё завязано на древнее легаси. C>Так и запишем — документации нет, код полное говно.
Ни разу не видел, что бы документация покрывала вообще всё. Обычно только паблик АПИ. Вот внутренности, все потенциальные странные кейсы — этого большей частью никогда и не бывает.
P>>После этого всего приходит QA и спрашивает, а на какие компоненты повлиял фикс. C>То есть, по факту тестов тоже нет.
Наоборот. Новый фикс — новые знания, поведение поменялось. А тесты как раз заточены под старое поведение.
1. их нужно найти, выявить новые, неизвестные баги
2. задокументировать, если нашлись
3. написать новые тесты
Вот для п1 и нужно представлять, на что влияет фикс. Например, если фикс влияет на старт приложения, то стоит сказать об этом тестировщку. Если фикс влияет на которые запросы к бд, тоже стоит сказать об этом.
Все предельно просто — у Qa нет чудесной магии обнаружить все баги. Ему нужно доработать свою стратегию тестирования, которая будет учитывать новые знания.
Впрочем, для девелопера который кодит 90% времени вполне нормально не знать, что такое новые неизвестные баги
P>>Проектирование, документирование они вообще слабо привязаны к кодингу, а отнимают чудовищное количество времени.
C>Сам танцую, сам пою, сам билеты продаю.
Именно. Проектировать, документировать свои решения нужно самому, а не надеяться на жирафа, которому виднее ибо шея длинная.
Здравствуйте, Pauel, Вы писали:
P>Открой пирамиду Маслоу или подобную ей, и покажи ссылкой, в каком месте там "зубная щетка"
Очевидно, что где-то рядом с "конечными услугами", которых там тоже нет.
P>нет потребности чистить зубы. Есть базовая потребность иметь здоровье, в т.ч. с зубами.
Есть ли у каждого возможность иметь здоровые зубы без их чистки специальными инструментами, хоть зубной щеткой, хоть морковкой? Если такой возможности нет, то есть и потребность в чистке — а следовательно, и в инструментах для нее.
P>>>4 поддерживать чистоту полости рта — есть вещи типа моркови и подобных вещей, они снимают налет, пить воду
ЕМ>>А где здесь "конечная услуга"? Я тут вижу сплошь инструменты — сиречь аналоги зубной щетки.
P>Здесь удовлетворяется базовая потребность — здоровье.
Напоминаю: Вы нас уверяли, что у человека якобы есть потребность в "конечных услугах". Почему мне не предлагают такой услуги по поддержанию здоровья зубов, а упорно впаривают зубные щетки, пасты, нити, чтобы я делал это сам? У них маркетологи хуже, чем те, которых Вы тут старательно пересказываете?
Нет, это у Вас все человеческие потребности свелись к "конечным услугам".
P>У тебя есть потребность в здоровье, питании и тд. Соответствующие услуги давно уже так и называются.
Ну так у меня есть потребность в питании без помощи тарелок, ложек, вилок, всех этих нелепых телодвижений и временнЫх затрат, но без потери удовольствия от процесса. Кто и где может предложить мне такие услуги, как они называются? Почему я везде вижу сплошь ложки, вилки и тарелки? Научите их уже, как правильно удовлетворять мои потребности.
Здравствуйте, Евгений Музыченко, Вы писали:
P>>нет потребности чистить зубы. Есть базовая потребность иметь здоровье, в т.ч. с зубами.
ЕМ>Есть ли у каждого возможность иметь здоровые зубы без их чистки специальными инструментами,
Есть просто потребность в здоровье и не надо тянуть сюда инструменты. Когда отделяем инструменты от потребности, то внезапно можно понять, что именно лично тебе надо — зубная щетка или туалетная бумага. А если смешивать, как ты это делаешь, то это всё едино. Смотри, не перепутай.
> хоть зубной щеткой, хоть морковкой? Если такой возможности нет, то есть и потребность в чистке — а следовательно, и в инструментах для нее.
Вот-вот. Потребность и способ её удовлетворения у тебя сливаются в одно целое.
P>>Здесь удовлетворяется базовая потребность — здоровье.
P>>У тебя есть потребность в здоровье, питании и тд. Соответствующие услуги давно уже так и называются.
ЕМ>Ну так у меня есть потребность в питании без помощи тарелок, ложек, вилок, всех этих нелепых телодвижений и временнЫх затрат, но без потери удовольствия
Есть просто потребность в пище и удовольствии. А ты снова притягиваешь сюда способы. Т.е. потребность и способ удовлетворения у тебя является одним целым. Эдакое синкретическое мышление "электричество берется из розетки".
>Кто и где может предложить мне такие услуги, как они называются? Почему я везде вижу сплошь ложки, вилки и тарелки? Научите их уже, как правильно удовлетворять мои потребности.
Элементарно — в разные времена люди питаются по разному. 99% времени человечество обходилось без ложки, вилки и тарелки. И этому не надо было учить в университетах, потому что университетов тоже не было.
Если отделять потребности от способа удовлетворения, то можно заметить, что первые постоянны, а вторые постоянно меняются.
А если сливать в одно целое, как у тебя, то только и остаётся что впаривать, и рассказывать "а у вас на самом деле есть потребность в вилке и ложке".
Здравствуйте, Codealot, Вы писали:
C>У меня 64. И я с трудом представляю насколько надо себя не любить, чтобы иметь меньше чем 32.
Я бы до сих пор сидел на 16, не будь браузеры такими неадекватно прожорливыми. Такое впечатление, что операции освобождения памяти в них вообще не используются.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Я бы до сих пор сидел на 16, не будь браузеры такими неадекватно прожорливыми. Такое впечатление, что операции освобождения памяти в них вообще не используются.
Здравствуйте, Pauel, Вы писали:
P>Например, для "подумать" нужно понять требования, которые вообще никак к коду не привязаны — они одинаковы вне зависимости от ЯП, технологий и тд.
Ну да, а как реализовать требования данными конкретными инструментами думать вообще не надо
Ни один вменяемый программист не станет изолировать "думать" от "кодить".
P>Вместо отладки частенько эффективнее спросить человека, например, он может рассказать то, чего в коде нет, и быть не может.
Ну заюлил. То доказывал что надо отлаживать, теперь стал доказывать что вместо этого лучше языком потрепать.
P>Ни разу не видел, что бы документация покрывала вообще всё. Обычно только паблик АПИ. Вот внутренности, все потенциальные странные кейсы — этого большей частью никогда и не бывает.
Это потому что документация у вас — говно. Именно странности она и должна покрывать в первую очередь. Всё, что не странно — и так легко понять.
И, кстати, документации как у тебя я видел много. В духе "чтобы открыть файл, нажмите File/Open", а всё что чуть сложнее — бери хрустальный шар и медитируй до умопомрачения.
P>1. их нужно найти, выявить новые, неизвестные баги
Если при прогоне тестов не выявляются баги, то по факту у вас никаких тестов нет. Есть их имитация или вообще ничего нет.
P>Именно. Проектировать, документировать свои решения нужно самому, а не надеяться на жирафа, которому виднее ибо шея длинная.
Ты сам писал, что документация имеет мало отношения к кодингу. Значит, и писать ее должен другой человек. Сапоги пусть делает сапожник, пироги пирожник, а расчистка говна — это к ассенизатору. Смешивать нежелательно.
Здравствуйте, Pauel, Вы писали:
P>Однажды мвд-шник на серьезных щах рассказывал мне, тогда студенту, что софт вообще писать не надо — "хули ты дурью маешься, всё уже готово, просто скопируй куда надо и всё".
Ты от него не так сильно отличаешься. Только ты веришь, что "нефиг дурью маяться, надо просто побольше общаться, а код как-нибудь сам собой образуется".
Здравствуйте, Codealot, Вы писали:
P>>Однажды мвд-шник на серьезных щах рассказывал мне, тогда студенту, что софт вообще писать не надо — "хули ты дурью маешься, всё уже готово, просто скопируй куда надо и всё".
C>Ты от него не так сильно отличаешься. Только ты веришь, что "нефиг дурью маяться, надо просто побольше общаться, а код как-нибудь сам собой образуется".
Здравствуйте, Codealot, Вы писали:
C>Ну да, а как реализовать требования данными конкретными инструментами думать вообще не надо C>Ни один вменяемый программист не станет изолировать "думать" от "кодить".
Странно, однако. Знакомство с доменом начинается задолго до того, как код увидишь. Вероятно ты пропускаешь эту часть.
P>>Вместо отладки частенько эффективнее спросить человека, например, он может рассказать то, чего в коде нет, и быть не может. C>Ну заюлил. То доказывал что надо отлаживать, теперь стал доказывать что вместо этого лучше языком потрепать.
Отладка это не пошаговое выполнение, а процесс устранения багов. И здесь стоит выяснять у других, а что именно они хотели кодом сказать. Мало ли, тогда были другие условия, может всё уже стоит выбросить.
P>>1. их нужно найти, выявить новые, неизвестные баги C>Если при прогоне тестов не выявляются баги, то по факту у вас никаких тестов нет. Есть их имитация или вообще ничего нет.
Покрытие тестами это фактически состояние знаний на момент написания тестов. Появились новые знания — надо добавить тесты.
Простой пример — что бы гарантировано найти любой баг в функции, где один аргумент Int64, нам надо всего то 2^64 тестов. Это при условии, что функция чистая, и не зависит ни от какого внешнего состояния.
Если у тебя меньше — всегда есть шанс, что ты при прогоне тесты чегото не найдут.
Как думаешь, к моменту окончания прогона солнце погаснет или нет?
Заметь — и это одна единственная функция. Полное покрытие более-менее сложной софтины требует в районе 2^100 или даже больше тестов.
P>>Именно. Проектировать, документировать свои решения нужно самому, а не надеяться на жирафа, которому виднее ибо шея длинная.
C>Ты сам писал, что документация имеет мало отношения к кодингу. Значит, и писать ее должен другой человек. Сапоги пусть делает сапожник, пироги пирожник, а расчистка говна — это к ассенизатору. Смешивать нежелательно.
Документация это смежная деятельность. Если девелопер запилил АПИ, то ему и документировать. Иначе придется пересказывать тому, другому, что значит каждый метод-параметр-результат, да еще и проверять, а что же в итоге вышло.
Здравствуйте, Pauel, Вы писали:
P>Знакомство с доменом начинается задолго до того, как код увидишь.
А, то есть ты еще и поклонник водопадной модели разработки. Ну ок.
P>Отладка это не пошаговое выполнение, а процесс устранения багов.
А теперь ты начал подменять одни понятия другими. Процесс устранения багов и отладка — разные вещи.
P>Простой пример — что бы гарантировано найти любой баг в функции, где один аргумент Int64, нам надо всего то 2^64 тестов.
То есть твои тесты сводятся к брут форсу.
P>Документация это смежная деятельность. Если девелопер запилил АПИ, то ему и документировать.
Ты сам писал, что документация имеет мало отношения к кодингу. Хватит юлить.
Документировать АПИ может как человек который его собственно проектировал, или отдельный технический писатель, или тестер. Можно конечно совместить все эти роли вместе с ролью программиста в одной, но вообще это ненормально.
Здравствуйте, Pauel, Вы писали:
P>Проще писать под электрон, благо браузерный движок постепенно вбирает в себя ключевые апи ос, и со временем приложения перекочуют именно туда.
Здравствуйте, Pauel, Вы писали:
P>Ты как то усиленно пытаешься переиначить сказанное. Я говорю о потребностях, а не о том, что делаю или не делаю лично.
Ты сам сказал про "услуги конкретного сервиса". Здоровье — это совсем другая категория.
Здравствуйте, Codealot, Вы писали:
C>Ты сам сказал про "услуги конкретного сервиса". Здоровье — это совсем другая категория.
Тут дело не в категориях, а в том, что удовлетворение каких-то потребностей человек предпочитает в виде результата, а каких-то — в виде процесса. Ту же чистоту зубов, кожи и волос большинство предпочло бы в виде результата (чтоб просто всегда были чистыми и не доставляли забот). Но в имеющихся условиях это объективно невозможно, а иметь пусть даже робота, который будет чистить тебе зубы и мыть голову — банально неудобно, проще сделать это самостоятельно. А коли так, потребность в состоянии чистоты (пресловутых "отверстиях") автоматически влечет за собой потребность в инструментах для достижения этого состояния (пресловутых "сверлах").
Ну а если наш гуру разработки и маркетинга организует, например, контору под эгидой "наши сотрудники быстро и качественно удовлетворят вашу жену", и предложит это в качестве "конечной услуги" для мужей, имеющих потребность в удовлетворении своих жен, то вряд ли его успех сравнится с успехом тренеров по сексуальным техникам или торговцев препаратами для улучшения эрекции.
Здравствуйте, Codealot, Вы писали:
P>>Знакомство с доменом начинается задолго до того, как код увидишь. C>А, то есть ты еще и поклонник водопадной модели разработки. Ну ок.
Так и вижу, как юный падаван лезет в код БЛ американского страхования не имея никаких об этом познаний.
P>>Отладка это не пошаговое выполнение, а процесс устранения багов. C>А теперь ты начал подменять одни понятия другими. Процесс устранения багов и отладка — разные вещи.
Похоже, что ты пользуешься своей терминологией. Цитирую:
debugging is the process of finding and resolving bugs (defects or problems that prevent correct operation) within computer programs, software, or systems.
P>>Простой пример — что бы гарантировано найти любой баг в функции, где один аргумент Int64, нам надо всего то 2^64 тестов. C>То есть твои тесты сводятся к брут форсу.
Ты лучше расскажи,
1 сколько тебе тестов понадобится, что бы задетектить любой баг в функции вида Int64 -> Int64.
2 хватит ли времени до скончания времён или надо попросить бога отдалить тепловую смерть вселенной.
P>>Документация это смежная деятельность. Если девелопер запилил АПИ, то ему и документировать. C>Ты сам писал, что документация имеет мало отношения к кодингу. Хватит юлить.
Я и пишу — смежная область, потому и мало отношения к собственно кодингу. Иногда она пишется еще до написания кода. Иногда — после.
Тем не менее, доку пишет тот, кто запилил АПИ.
C>Документировать АПИ может как человек который его собственно проектировал, или отдельный технический писатель, или тестер.
1 Технический писатель не в курсе кода, это мне придется надиктовывать ему все особенности АПИ
2 А тестер должен получить от меня доку, что бы проверить на соответствие заявленым фичам/аспектам/итд
Здравствуйте, Codealot, Вы писали:
P>>Проще писать под электрон, благо браузерный движок постепенно вбирает в себя ключевые апи ос, и со временем приложения перекочуют именно туда.
C>Вот он, звериный оскал говнокодинга.
Извините, а не могли бы вы перевести с фекального на русский?
Здравствуйте, Codealot, Вы писали:
P>>Ты как то усиленно пытаешься переиначить сказанное. Я говорю о потребностях, а не о том, что делаю или не делаю лично.
C>Ты сам сказал про "услуги конкретного сервиса". Здоровье — это совсем другая категория.
Сейчас здоровье стало названием соответствующей услуги. Что вобщем то объяснимо — инструменты, технологии вторичны.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Тут дело не в категориях, а в том, что удовлетворение каких-то потребностей человек предпочитает в виде результата, а каких-то — в виде процесса. Ту же чистоту зубов, кожи и волос большинство предпочло бы в виде результата (чтоб просто всегда были чистыми и не доставляли забот). Но в имеющихся условиях это объективно невозможно, а иметь пусть даже робота, который будет чистить тебе зубы и мыть голову — банально неудобно, проще сделать это самостоятельно. А коли так, потребность в состоянии чистоты (пресловутых "отверстиях") автоматически влечет за собой потребность в инструментах для достижения этого состояния (пресловутых "сверлах").
Потребность у человека это некоторая внутренняя психологическая недостаточность у человека. Например — здоровье. Ты пытаешься внутреннее, психологические, подменить внешним, технологическим, как будто это одно и то же.
На самом деле отношения между этими вещами цель-инструмент. Есть есть цель, понятно, что будут и разные инструменты. Но из этого никак не следует, что появится потребность в инструменте. Потребность как была, так и осталась — здоровье. А инструменты всегда меняются.
Будь у нас потребности в отвертке, ходили бы все как обмазавшись этими отвертками, зубными щетками и тд.
ЕМ>Ну а если наш гуру разработки и маркетинга организует, например, контору под эгидой "наши сотрудники быстро и качественно удовлетворят вашу жену",
Нету такой потребности "удовлетворённая жена". Есть отдых, есть удовольствие, из простых. Более сложные — у супругов есть потребность в прочных отношениях. Вот здесь пока что инструментов отличных от личного участия пока не просматривается.
Здравствуйте, Pauel, Вы писали:
P> Так и вижу, как юный падаван лезет в код БЛ американского страхования не имея никаких об этом познаний.
Чтобы посмотреть, как оно работает — можно и нужно.
P>
P>debugging is the process of finding and resolving bugs (defects or problems that prevent correct operation) within computer programs, software, or systems.
Идиотское у тебя определение. finding bugs — это тестирование. Найти, почему конкретно баг происходит — вот это уже отладка. Исправление бага — это опционально.
P>1 сколько тебе тестов понадобится, что бы задетектить любой баг в функции вида Int64 -> Int64.
А кто сказал про абсолютно любой баг? Найти абсолютно любой баг вообще в принципе невозможно, никакими средствами.
P>Тем не менее, доку пишет тот, кто запилил АПИ.
Как я и сказал — сам танцую, сам пою, сам билеты продаю.
P>1 Технический писатель не в курсе кода, это мне придется надиктовывать ему все особенности АПИ
Здравствуйте, Codealot, Вы писали:
P>> Так и вижу, как юный падаван лезет в код БЛ американского страхования не имея никаких об этом познаний. C>Чтобы посмотреть, как оно работает — можно и нужно.
Скорее всего тебя в код пустят только после того, как ты продемонстрируешь владение доменом.
P>>
P>>debugging is the process of finding and resolving bugs (defects or problems that prevent correct operation) within computer programs, software, or systems.
C>Идиотское у тебя определение. finding bugs — это тестирование. Найти, почему конкретно баг происходит — вот это уже отладка. Исправление бага — это опционально.
Это общепринятое.
P>>1 сколько тебе тестов понадобится, что бы задетектить любой баг в функции вида Int64 -> Int64. C>А кто сказал про абсолютно любой баг? Найти абсолютно любой баг вообще в принципе невозможно, никакими средствами.
Именно ты и сказал:
Если при прогоне тестов не выявляются баги, то по факту у вас никаких тестов нет.
Тут одно из трех:
1. или ты не знаешь, что такое новый, неизвестный баг, т.е. веришь в "качество это когда багов нет"
2. или не в курсе, что полное покрытие заведомо недостижимо
3. несешь пургу, абы чего накинуть
P>>Тем не менее, доку пишет тот, кто запилил АПИ. C>Как я и сказал — сам танцую, сам пою, сам билеты продаю.
Расскажи, как надо. Откуда технический писатель узнает, что делает моё апи?
P>>1 Технический писатель не в курсе кода, это мне придется надиктовывать ему все особенности АПИ
C>А ТЗ у вас в принципе нет?
Что бы диктовали, какое апи выставить наружу — такого нет. Обычно это моя забота, построить АПИ. Потому придется надиктовывать твоему техническому писателю, если вдруг приставят его ко мне.
Здравствуйте, Pauel, Вы писали:
P>Скорее всего тебя в код пустят только после того, как ты продемонстрируешь владение доменом.
Мне работа в вашей шарашкиной конторе нахрен не нужна. Но мне все же интересно, как ты оправдываешь запрещение джуниорам читать код.
P>Это общепринятое.
Говоришь за всех? Дурная привычка. Определений этого конкретного понятия — много разных.
P>Тут одно из трех:
Нет никакий гарантий что тестеры найдут твой новый, неизвестный баг. В особенности если они будут искать его там где ты же им и сказал, где искать, а не думать своими собственными головами.
Ты не знаешь где искать твои баги, потому что если знал бы — то уже исправил бы. Поэтому твоя информация тестерам в лучшем случае бесполезна, а в худшем — отправит в неверном направлении.
Не доходит?
P>Расскажи, как надо. Откуда технический писатель узнает, что делает моё апи? P>Что бы диктовали, какое апи выставить наружу — такого нет. Обычно это моя забота, построить АПИ. Потому придется надиктовывать твоему техническому писателю, если вдруг приставят его ко мне.
Сколько вообще людей в вашей шарашке и какого размера проект? Хотя, учитывая твою любовь к электрону, вопрос можно считать риторическим
Здравствуйте, Codealot, Вы писали:
P>>Скорее всего тебя в код пустят только после того, как ты продемонстрируешь владение доменом. C>Мне работа в вашей шарашкиной конторе нахрен не нужна. Но мне все же интересно, как ты оправдываешь запрещение джуниорам читать код.
Забавно, как у тебя плавно трансформируется понятие "кодинг" — теперь кодить это "джуниорам читать код"
C>Нет никакий гарантий что тестеры найдут твой новый, неизвестный баг.
А как же твоё
Если при прогоне тестов не выявляются баги, то по факту у вас никаких тестов нет.
Не то у вас тестов нет, не то ты сам себе противоречишь.
C>Ты не знаешь где искать твои баги, потому что если знал бы — то уже исправил бы.
Ложный вывод. Знать где искать, и количество потенциальных тесткейсов это две большие разницы.
Ну вот знаем, что изменения влияют на старт приложения, например, из за загрузчика конфига.
Всех дел — стартуем сервис на всех возможных комбинациях значений. Допустим, у нас в конфиге всего 100 булевых флажков.
Вопрос — какие из 2^100 конфигураций повалят приложение на старте и сколько времени на это уйдет?
> Поэтому твоя информация тестерам в лучшем случае бесполезна, а в худшем — отправит в неверном направлении.
Если ты знаешь, что фикс точно влияет на компоненты А, Б и В, то их нужно перепроверить в обязательном порядке, а возможно и дописать необходимые тесткейсы.
Например — приложение изредка, раз в день-неделю-месяц, делает кое какие реквесты. Каким образом тестировщик узнает, что ты добавил один из таких реквестов? Как ему проверить, что прилага корректно обрабатывает ошибки таких запросов?
Поэтому на вопрос тестировщика "а что/где поменялась" сообщаешь "телеметрия x-y-z c частотой раз в месяц начала слать вот это, включается конфигом вот так"
А вот всё остальное никто не отменял.
Собственно, сколько себя помню, тестировщики сами приходят и спрашивают, на что именно влияет фикс.
Элементарно — всегда нужно понять, стоит ли планировать регрессионное планирование после твоего фикса или хватит коротенького смок-теста, + пара-тройка новых автоматических тестов.
Например, если ты поменял нечто навроде object pool, что используется повсеместно, то после такого фикса нужно регрессионное тестирование, т.е. один фикс повлиял сразу на всё приложение.
C>Не доходит?
Похоже, тестирование у вас там отменили.
P>>Что бы диктовали, какое апи выставить наружу — такого нет. Обычно это моя забота, построить АПИ. Потому придется надиктовывать твоему техническому писателю, если вдруг приставят его ко мне.
C>Сколько вообще людей в вашей шарашке и какого размера проект? Хотя, учитывая твою любовь к электрону, вопрос можно считать риторическим
Судя по твоим познаниям в тестировании, шарашка это где то вокруг тебя.
Здравствуйте, Pauel, Вы писали:
P>Забавно, как у тебя плавно трансформируется понятие "кодинг" — теперь кодить это "джуниорам читать код"
Процитирую для тех, у кого проблемы с памятью.
P> Так и вижу, как юный падаван лезет в код БЛ американского страхования не имея никаких об этом познаний.
Чтобы посмотреть, как оно работает — можно и нужно.
Опять же, поменять что-нибудь и посмотреть в тестовом окружении, что сломается (если сломается) — не вижу вообще никаких проблем.
C>>Нет никакий гарантий что тестеры найдут твой новый, неизвестный баг. P>Не то у вас тестов нет, не то ты сам себе противоречишь.
Л — Логика.
P>Всех дел — стартуем сервис на всех возможных комбинациях значений. Допустим, у нас в конфиге всего 100 булевых флажков. P>Вопрос — какие из 2^100 конфигураций повалят приложение на старте и сколько времени на это уйдет?
Да, тяжело приходится вашим тестерам
P>Каким образом тестировщик узнает, что ты добавил один из таких реквестов?
То есть они у вас вообще не имеют никакого представления, как работает то что они "тестируют"?
P>Как ему проверить, что прилага корректно обрабатывает ошибки таких запросов?
Действительно, как?
P>Например, если ты поменял нечто навроде object pool, что используется повсеместно, то после такого фикса нужно регрессионное тестирование, т.е. один фикс повлиял сразу на всё приложение.
И как оно у вас делается?
P>Похоже, тестирование у вас там отменили.
Ты будешь пытаться доказывать, что ручное тестирование выявляет все мыслимые ошибки при всех мыслимых комбинациях условий? Да или нет?
P>Судя по твоим познаниям в тестировании, шарашка это где то вокруг тебя.
Здравствуйте, Codealot, Вы писали:
C>Процитирую для тех, у кого проблемы с памятью.
Я вот помню, что мы говорили про кодинг, а ты решил дать джуниору почитать код размером с операционку.
Итого — код только самой БЛ такого проекта это сотни и более тысяч строк кода, по самой скромной оценке, и каждый президент увеличивает этот хаос.
Вместо того, что бы все нюансы и детали извлекать из кода, нужно вначале ознакомиться с доменом, хотя бы с терминологией, это самое меньшее.
В противном случае страховая контора разорится выплачивать пенальти.
C>>>Нет никакий гарантий что тестеры найдут твой новый, неизвестный баг. P>>Не то у вас тестов нет, не то ты сам себе противоречишь. C>Л — Логика.
Именно. У тебя в сумме вот такое
1. нет гарантий, что тесты надут новый, неизвестный баг
2. если не нашли, то тесты — отстой
Если 1 это норма, то 2 это уже безграмотность. Именно потому я привожу кейс где у нас 2^100 комбинаций.
P>>Каким образом тестировщик узнает, что ты добавил один из таких реквестов? C>То есть они у вас вообще не имеют никакого представления, как работает то что они "тестируют"?
Забавно, что ты сам не можешь ответить.
Тестеры не в курсе, что именно ты добавил в софтину. Например, ты добавил запрос, который шлется крайне редко, а в обработчике ошибок ты забыл убрать отладочную хрень вида:
process.exit(-1) // просто для примера
Как думаешь, сколько времени надо убить на тесты, что бы обнаружить вот такое новое поведение, которое вызывается раз в месяц?
P>>Как ему проверить, что прилага корректно обрабатывает ошибки таких запросов? C>Действительно, как?
И снова ответа у тебя нет, о чем и речь.
В данном случае решение это вайт бокс тестирование, что очевидно. Блек боксом ты будешь искать такое до скончания времён.
Итого, здесь вайтбокс реализуется так:
— узнать у девелопера
— самому заглянуть в код изменений
Покрыть тесткейсами, прогнать вручную, и далее тесткейсы автоматизировать.
P>>Например, если ты поменял нечто навроде object pool, что используется повсеместно, то после такого фикса нужно регрессионное тестирование, т.е. один фикс повлиял сразу на всё приложение. C>И как оно у вас делается?
По известным тесткейсам есть автоматические тесты. При этом известные кейсы это только часть регрессионного. Далее этап exploratory, где тестировщик все проверяет ручными или полуавтоматическими методами, на предмет того, а не появилось ли что новое.
Соответственно, тестировщики планируют такую активность заранее, т.к. такая вещь может вполне себе загрузить цельную команду тестировщиков.
P>>Похоже, тестирование у вас там отменили. C>Ты будешь пытаться доказывать, что ручное тестирование выявляет все мыслимые ошибки при всех мыслимых комбинациях условий? Да или нет?
В целом никакое тестирование принципиально не может выявить мыслимые и немыслимые ошибки.
Потому половина твоих заявлений в этом треде есть обычная безграмотность.
А раз у нас нет чудесного 100% покрытия всех путей выполнения, то применяют различные эвристики, например
1. блек бокс, когда тестер отталкивается от требований, явных или неявных. Пример: тесткейс для требования "юзер должен иметь возможность запретить телеметрию"
2. вайт бокс, когда тестер отталкивание от знаний о внутреннем устройстве. Пример: тесткейс для вещей вида "в файле/строчке подозрительный реквест отсылается раз в месяц"
Здравствуйте, Pauel, Вы писали:
P>Вместо того, что бы все нюансы и детали извлекать из кода, нужно вначале ознакомиться с доменом, хотя бы с терминологией, это самое меньшее.
Не вместо, а вместе. Не доходит?
P>В противном случае страховая контора разорится выплачивать пенальти.
Как быстро ты перескочил от "поиграть с кодом в тестовом окружении" к "хренак-хренак и в продакшен".
P>Именно. У тебя в сумме вот такое
У меня в сумме — "нет вообще никаких способов гарантированно найти новый, неизвестный баг". Ни автоматически, ни вручную, вообще никак. Поэтому все твои рассуждения на тему гарантированного обнаружения багов — бессмысленная демагогия.
Негарантированно — можно. В том числе и автоматически, и даже с довольно неплохой вероятностью.
Все еще не доходит?
P>Итого, здесь вайтбокс реализуется так: P> — узнать у девелопера
Нет, вайтбокс реализуется совсем не так. Девелопер — по определению источник ненадежный, поэтому и спрашивать у него скорее вредно, чем полезно. Вайтбокс реализуется так: тестер — не мартышка с клавиатурой, а человек, который понимает как работает система и что от чего зависит, и способен понять, где что и почему может сломаться. Также, он должен быть способен посмотреть код и почитать логи и хотя бы приблизительно понять, что конкретно изменилось.
P>Далее этап exploratory, где тестировщик все проверяет ручными или полуавтоматическими методами, на предмет того, а не появилось ли что новое.
Все мыслимые комбинации параметров?
P>Потому половина твоих заявлений в этом треде есть обычная безграмотность.
Нет дружок, это всего лишь твоя демагогия и большая любовь к применению straw man.
Здравствуйте, Codealot, Вы писали:
P>>Вместо того, что бы все нюансы и детали извлекать из кода, нужно вначале ознакомиться с доменом, хотя бы с терминологией, это самое меньшее. C>Не вместо, а вместе. Не доходит?
Это так не работает. Фиксовать тебе никто не даст, пока ты внятно не освоишь домен.
Все дело в цене ошибки. Чем она выше, тем позже тебя пускают в код. Американское страхование это чудовищно сложная система с чудовищной ценой ошибки — кодить не зная домена никто тебе не даст. Сначала покажи, что владеешь темой, а потом уже от тебя примут фикс.
Ровно так же и с математикой — сначала покажи, что её знаешь, а потом от тебя примут фикс того или иного алгоритма.
C>У меня в сумме — "нет вообще никаких способов гарантированно найти новый, неизвестный баг". Ни автоматически, ни вручную, вообще никак. Поэтому все твои рассуждения на тему гарантированного обнаружения багов — бессмысленная демагогия.
Кто же тогда с твоего аккаунта написал вот это:
Если при прогоне тестов не выявляются баги, то по факту у вас никаких тестов нет.
Что именно ты имел ввиду? Ты внятно можешь пояснить?
C>Нет, вайтбокс реализуется совсем не так. Девелопер — по определению источник ненадежный, поэтому и спрашивать у него скорее вредно, чем полезно.
Это смотря что спрашивать. Раз девелопер внес изменения, то тестировщик априори не знает, где именно поменялось поведение системы.
А вот если ты ему скажешь, что фиксанул загрузку конфига на старте, то тестировщику будет понятно, на что обратить внимание в первую очередь.
Крайне странно ждать от тестировщиков, что они смогут прочесть и понять код системы.
P>>Далее этап exploratory, где тестировщик все проверяет ручными или полуавтоматическими методами, на предмет того, а не появилось ли что новое. C>Все мыслимые комбинации параметров?
Все основные пути, которые зафиксированы в тесткейсах.
P>>Потому половина твоих заявлений в этом треде есть обычная безграмотность. C>Нет дружок, это всего лишь твоя демагогия и большая любовь к применению straw man.
Факт номер 1: ты регулярно в том или ином виде транслируешь вот эту идею: "Если при прогоне тестов не выявляются баги, то по факту у вас никаких тестов нет."
Факт номер 2: что ты здесь подразумевал — пояснять отказываешься.
Факт номер 3: периодически ты и сам косвенно утверждаешь, что твое утверждение выше есть ересь
Здравствуйте, Pauel, Вы писали:
P>Это так не работает. Фиксовать тебе никто не даст, пока ты внятно не освоишь домен. P>Все дело в цене ошибки. Чем она выше, тем позже тебя пускают в код. Американское страхование это чудовищно сложная система с чудовищной ценой ошибки — кодить не зная домена никто тебе не даст. Сначала покажи, что владеешь темой, а потом уже от тебя примут фикс.
До тебя так и не дошла разница между "почитать код и поиграть с ним" и "делать фиксы в продакшен"?
P>
P>Если при прогоне тестов не выявляются баги, то по факту у вас никаких тестов нет.
P>Что именно ты имел ввиду? Ты внятно можешь пояснить?
Тесты должны выявлять новые баги, хотя и не гарантированно все. Но некоторые — должны выявлять. Если никакие новые баги твоими тестами не выявляются — значит, никаких тестов у тебя нет. Есть только их имитация.
Но я надеюсь, хотя бы тот факт, что ручное тестирование тоже не гарантирует выявление всех новых багов, до тебя дошел?
P>Крайне странно ждать от тестировщиков, что они смогут прочесть и понять код системы.
Если они не макако-тестеры, то не странно. Но тебе, я так понимаю, знаком только этот вид.
ЭФ>И получаешь позорнейший по производительности однопоток.
Замечание справедливо. Хорошо бы расковырять, как Autodesk и Figma эту ситуацию разруливают. Наверняка UI однопоточный, а для тяжелых или продолжительных операций прикручен какой-нибудь OperationQueue поверх Web Workers.
Здравствуйте, cppguard, Вы писали:
C>Правда, надо отдаль должное — сбер хотя бы работает в RuStore, чего нельзя сказать о многих других российских приложениях. Половина требует гуглосервисы.
Были какие-то проблемы, не встал оттуда, пришлось ставить не то из AppGallery, не то из apk.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
вот к примеру щаз занято около 9 из 16 GB (и это ещё щаз без кодинга)
Чистые зубы, волосы, кожа это составляющие "здоровье", в чем потребность у человека была задолго до появления городов.
