Если код не дошел с первой попытки, то нужно повторить. Тогда "Получить код" нужно нажать еще раз, ну или "Получить еще раз", хотя фактически первого "получения" не было.
В этом смысле "Отправить код" и "Отправить еще раз" выглядят логичнее.
И еще момент. Пользователь получает код на другом устройстве. Т. е. отправляет из браузера на десктопе (например) получает в телефоне.
В статье проблема с логикой рассуждений и об этом уже написали.
Это, например, может означать, что автор неплохо справляется с абстрактными задачами и алгоритмами, но, возможно, не очень хорошо с прикладной бизнес-логикой (но не обязательно). В продуктовых проектах, в основном, пишут бизнес-логику, а не алгоритмы.
В отрыве абстрактных задач от прикладной бизнес-логики, вероятно, и лежит противоречивый подход к собеседованиям. Прикладные разработчики постоянно практикуют решение бизнес-задач, но, практически не практикуют алгоритмы, только если это занятие само по себе не представляет для разработчика личного интереса.
Соответственно, для прохождения интервью требуется специально затачивать навык на всяких литкодах. После прохождения интервью навык утрачивается за ненадобностью.
Да, помню... Отец приносил с работы. Это был такой монстр из проводов. Отдельными девайсами - монитор, дисковод, пк и к каждому блок питания. Иногда это нужно было переносить из комнаты на кухню и обратно.
В конце 11-ого класса ночью писал выпускную программу по информатике на Бейсике. Что-то типа игры "Президент", купля-продажа акций... Записал на пятидюймовую дискету, отнес в школу и преподаватель вставив в ДВК и увидев просто кол-во строк в программе и послушав объяснения, посмотрел на меня круглыми глазами и поставил пять. Я такой был один на всю школу )))
Я ни в коем случае не умоляю достоинств Flutter. Даже наоборот с энтузиазмом следил несколько лет. Но, все это время, как, вероятно, и многие другие. не могу отделаться от мысли, "ну, почему не Kotlin??"
Тут есть еще причины стилистического и синтаксического характера.
Например, фронт-енд разработчику, привыкшему к React и Typescript, интересны два варианта либо React Native либо Kotlin Compose. С Native связывает JS/TS, а с Compose синтаксически схожий с TS Kotlin. А Dart "ни то, ни сё". В этом дилемма.
Он снова внимателен, хоть и не так, как в самом начале. Традиционно в нижнем правом углу находятся кнопки призыва к действию. Например, «Купить», «Зарегистрироваться» или «Подробнее».
Действительно ли это правило работает?
У всех основных онлайн-магазинов кнопки "Положить в корзину", "Продолжить оформление" или "Купить", находятся в верхней правой части или, как минимум, на уровне карточки товара.
Инфа про то, что побочный продукт или про язык - неудачник? Побочный продукт следует из "язык - неудачник", а про яп пытавшийся заменить JS можно и в вики найти, ну или быть живым свидетелем.
Для себя я ориентируюсь на то, как к своим продуктам относятся их создатели.
Без Котлина уже трудно представить себе JetBrains. Они его создали и вкладываются. И вполне успешно.
Дарт для Google сейчас выглядит как побочный продукт. Дарт - язык неудачник. Одна из его первых задач была заменить Яваскрипт. Ну, и чтобы не пропала работа приспособили к Флаттеру. Это, конечно, не означает, обреченность и этого проекта, но, что называется, осадочек остался.
В неподготовленности и был смысл стресс-теста. Это опыт клиента/ов, которые начинают чаще пользоваться указанными сервисами и после определенного рубежа, готовые глубже разобраться и настраивать под себя приложение.
Спасибо за виджеты, я про них не вспомнил. Возможно, сделаю еще апдейт статьи
Спасибо, учту. К сожалению, обновить на моем телефоне пока не удается. Вероятно, это не только моя проблема. Это старенький андроид и переполненная память. Т.е. случай некоторого процента пользователей.
Окей, но, мы все равно должны соблюдать какую-то консистентность, а так: здесь "получить", а там "отправить".
Есть еще один кейс.
Если код не дошел с первой попытки, то нужно повторить. Тогда "Получить код" нужно нажать еще раз, ну или "Получить еще раз", хотя фактически первого "получения" не было.
В этом смысле "Отправить код" и "Отправить еще раз" выглядят логичнее.
И еще момент. Пользователь получает код на другом устройстве. Т. е. отправляет из браузера на десктопе (например) получает в телефоне.
Это такой фото-детокс. Для тех кто обычно обвешан несколькими Марками, кучей телеобъективов, вспышками и прочими штативами.
Чисто на прогулку с семьей.
В статье проблема с логикой рассуждений и об этом уже написали.
Это, например, может означать, что автор неплохо справляется с абстрактными задачами и алгоритмами, но, возможно, не очень хорошо с прикладной бизнес-логикой (но не обязательно). В продуктовых проектах, в основном, пишут бизнес-логику, а не алгоритмы.
В отрыве абстрактных задач от прикладной бизнес-логики, вероятно, и лежит противоречивый подход к собеседованиям. Прикладные разработчики постоянно практикуют решение бизнес-задач, но, практически не практикуют алгоритмы, только если это занятие само по себе не представляет для разработчика личного интереса.
Соответственно, для прохождения интервью требуется специально затачивать навык на всяких литкодах. После прохождения интервью навык утрачивается за ненадобностью.
Да, помню... Отец приносил с работы. Это был такой монстр из проводов. Отдельными девайсами - монитор, дисковод, пк и к каждому блок питания. Иногда это нужно было переносить из комнаты на кухню и обратно.
В конце 11-ого класса ночью писал выпускную программу по информатике на Бейсике. Что-то типа игры "Президент", купля-продажа акций... Записал на пятидюймовую дискету, отнес в школу и преподаватель вставив в ДВК и увидев просто кол-во строк в программе и послушав объяснения, посмотрел на меня круглыми глазами и поставил пять. Я такой был один на всю школу )))
Делай хорошо: сотни и тысячи строк кода, так и не попавшие в прод. Просто потому что бизнес сначала решил, а потом "что-то пошло не так".
Делай плохо: сотни и тысячи строк напиши хоть как-то чтобы сдать проект. Потом перепишем.
Я ни в коем случае не умоляю достоинств Flutter. Даже наоборот с энтузиазмом следил несколько лет. Но, все это время, как, вероятно, и многие другие. не могу отделаться от мысли, "ну, почему не Kotlin??"
Тут есть еще причины стилистического и синтаксического характера.
Например, фронт-енд разработчику, привыкшему к React и Typescript, интересны два варианта либо React Native либо Kotlin Compose. С Native связывает JS/TS, а с Compose синтаксически схожий с TS Kotlin. А Dart "ни то, ни сё". В этом дилемма.
Действительно ли это правило работает?
У всех основных онлайн-магазинов кнопки "Положить в корзину", "Продолжить оформление" или "Купить", находятся в верхней правой части или, как минимум, на уровне карточки товара.
Инфа про то, что побочный продукт или про язык - неудачник? Побочный продукт следует из "язык - неудачник", а про яп пытавшийся заменить JS можно и в вики найти, ну или быть живым свидетелем.
Для себя я ориентируюсь на то, как к своим продуктам относятся их создатели.
Без Котлина уже трудно представить себе JetBrains. Они его создали и вкладываются. И вполне успешно.
Дарт для Google сейчас выглядит как побочный продукт. Дарт - язык неудачник. Одна из его первых задач была заменить Яваскрипт. Ну, и чтобы не пропала работа приспособили к Флаттеру. Это, конечно, не означает, обреченность и этого проекта, но, что называется, осадочек остался.
Ну, джаву на котлин меняют раз в 15-20 лет. Сразу как создадут новый яп, который станет популярнее предыдущего.
Да, примерно, такие же ощущения испытал :)
Да, вероятно, этому стоит посвятить отдельную публикацию. Но, увы, это не входит в мою компетенцию.
В неподготовленности и был смысл стресс-теста. Это опыт клиента/ов, которые начинают чаще пользоваться указанными сервисами и после определенного рубежа, готовые глубже разобраться и настраивать под себя приложение.
Спасибо за виджеты, я про них не вспомнил. Возможно, сделаю еще апдейт статьи
NFC на используемом телефоне нет.
Очень интересный пример.
Обновил приложение и дополнил статью
Спасибо, учту. К сожалению, обновить на моем телефоне пока не удается. Вероятно, это не только моя проблема. Это старенький андроид и переполненная память. Т.е. случай некоторого процента пользователей.