Alexej Simakov

Все просто: для каждой платформы свой клиент. Не предоставляя мобильный клиент ты в лучшем случае лишаешь приложение части аудитории, а также уникальных возможностей.

Ведь мобильное приложение может, например, пользоваться железом мобильного телефона, как то, захват изображений с камеры и их удобная загрузка "в два касания". Или можно через шеринг передать файл в приложение. Это также и GPS, отслеживание маршрута и передача данных о твоем передвижении на сервер, для улучшения пользовательского опыта. Например, такси может видеть на карте где ты и быстрее и удобнее к тебе подъехать. Это и использование голосовых сервисов, и сервисов искусственного интеллекта, например, захват изображения с камеры распознавание текста на нем и произнесение "вслух". Или ты делаешь приложение для управления бюджетом и с помощью камеры и искусственного интеллекта даешь пользователю удобную возможность просто засканировать всю корзину и продукты автоматически добавятся в список и распределятся по категориям и так далее и тому подобное.

Т.е. если ты хочешь делать мобильное приложение нужно именно стараться задействовать возможности мобильного устройства и его операционной системы. Иначе это просто мобильная вебстраница.

Поэтому тут нельзя сравнивать что лучше что хуже. Вопрос скорее в том какие возможности мне как разработчику и продьюсеру (человеку заинтересованному в распространии сервиса), дает или не дает десктопный браузер по сравнению с мобильной платформой для реализации уникального ползовательского опыта.

На редактирование кода уходит хорошо если час-два в день. Два это уже хорошо. Остальное - осмысление проблемы, чтение документации, кода, иногда книг, поиск подходящего решения, выбор решения, осмысление выбора, переписка с другими людьми, если от них зависит твоя работа. Да, общаться приходится довольно много. На емейлы может уходить до нескольких часов в день. Писанина в багтрекере, написание публичных заметок (назовем это "документацией").
Чем ближе проект к кровавому энтерпрайзу, тем меньше ты программируешь. Если ты, например, пишешь ПО для ракеты как в НАСА, то там больше чертят диаграммы и проверяют все на бумаге, чем редактируют код. И вообще просто так нельзя вносить изменения в код без согласования. Ну это совсем крайний случай.

Я вот занимаюсь автоматизацией, у меня на проекте на написание новых тестов уходит от силы наверное 15% времени, все остальное время - проверка и разбор результатов тестов, заведение багрепортов, проверка фиксов. Отчетность, митинги (как я их терпеть не могу). Бывают - дни вообще ни одного коммита.

Смотреть как сверстаны чужие страницы, например. Ну и постоянно спрашивать Яндекс "как верстать сайты", там весь интернет этим завален.
Знание тегов это как знание назначения карандаша, красок и кисточки. Рисовать все равно надо учиться. Это процесс. И как в любом обучении быстрых путей нет. Можно быстро что-то сделать но научиться быстро чему-то нельзя. Я могу сделать яичницу, но чтобы научиться ее делать нужно посвятить этому куда больше времени чем я этому посвящаю. Так вот нужно ответить себе на вопрос, вам хочется быстрых результатов или вы хотите этому научиться, то есть посвятить этому часть своей жизни.

Когда я увлекался веб программированием, я мастерил маленькие финтифлюшки в онлайн редакторах типа jsfiddle и jsbin. Нужно постоянно решать какие-то задачи, только так нарабатываются навыки. Тренировка называется. И нужно доводить до конца. Что значит не выходит? Просто оно еще не готово. Делайте, продолжайте трудиться над этой конкретной задачей, и получится. Только когда вы одолеете свою задачу вы чему-то научитесь. Я повторюсь: быстрых путей нет.
Ну и важно, чтобы это вам было действительно интересно. Если предмет интересен, ты готов читать о нем и исследовать его весь день. А это положительно сказывается на результате. Вот такой секрет.

тестирование регистрации и аутентификации никак с точки зрения теста друг с другом не связаны.
в тестах регистрации вы хотите убедиться в том что если ввести невалидные данные то система даст отрицательный ответ. и если данные валидные то система ответит положительно.
при логине вы хотите убедиться в том что если послать системе данные не существующего аккаунта система даст отрицательный ответ. если дать данные заблокированного аккаунта (ну например есть у вас такая категория), система ответит правильным сообщением. и, если пользователь существует и не заблокирован система ответит положительно. Естественно чтобы провести эти тесты, вам понадобится один валидный аккаунт в базе, чтобы система могла ответить положительно, и данные одного не существующего аккаунта, и одного заблокированного аккаунта. Если логин в систему не работает, ваши тесты логина обнаружат баг.
Чтобы добится независимости от такого возможного бага, вы при тестировании запросов с залогиненым пользователем настраиваете систему перед тестом таким образом чтобы она не учитывала информацию по логину.

Давайте разберем на примере: представьте вы тестируете инсталляцию системы пожарной безопасности в секретной лаборатории. Доступ в помещение только по электронной карте. Внутри помещения есть кнопка включения сигнализации, при срабатывании которой должны закрыться все окна в помещении и должен быть разблокирован замок двери.
Вы тестируете замок двери отдельно. А для теста сигнализации и срабатывания оконной механики вы отключаете систему входа по карточке, и делаете его свободным. потому что идентификация при входе в помещение не является предметом теста для системы сигнализации (закрывание окон). В этой точке достигается независимость тестов.
Но отключив замок двери для теста, вы не сможете убедиться в том что замок открывается при срабатывании сигнализации (второе условие) . Вам придется непосредственно перед проверкой снова включить дверной замок.

Однако в случае если при тестировании входа выяснится что дверной замок не работает, то включить дверной замок для теста не получится, и второй тест скажет что мол замок двери открылся, все хорошо, однако на самом деле замок был все время открыт, потому что неработал. (т.н. false positive)

вы дизайнер графических интерфейсов, так? ив вы говорите что все уже придумано? То есть все интерфейсы которыми вы пользуетесь и с которыми знакомы идеальны и не нуждаются в улучшении?
Тогда не понятно почему фирмы делают редизайн из года в год. Непонятно зачем гугл придумал material design, зачем эппл меняет дизайн Mac OS, зачем хабр делает редизайн , почему меняется дизайн навигационных систем..

само это занятие называется web scraping или web harvesting, по этой теме инфы очень много в интернете.

У нас хорошо идут презентации на тему. Вы что-то умеете лучше остальных? Соберите людей и расскажите им как вы решаете проблемы. А какие проблемы выбрать темой вы сами наверное уже определили. Достаточно будет нескольких таких воркшопов.

я тестировал это все 1000 раз но эту комбинацию в голову не пришло сделать

может имеет смысл принять на вооружение методику pairwise и инструмент PICT.
По этой теме есть доклады, вот один из них для примера https://www.youtube.com/watch?v=Bqmuw3ZJ75g
Цель методики заключается в том чтобы из бесчисленного количества возможных комбинаций выбрать те которые обеспечат максимальное покрытие, при минимальном наборе тестов.
P.S. ну и автоматизация тестирования в обязательном порядке, если ее еще нет.

программирование - перевод из человеческого языка на язык компьютера.
при этом человеческий язык неоднозначен по своей природе, а компьютерный - не допускает двусмысленности.

"Кроссплатформенные приложения на базе современных веб технологий."
и рассмотреть могут ли веб-приложения стать заменой классическим платформозависимым приложениям.
Хороший пример например тот же офисный пакет google drive. И десятки других примеров.
Потом вполне можно себе представить формат программых пакетов которые можно будет написать один раз и они будут работать и на компьютерах(на ноде в качестве платформы) и на мобильных устройствах. Пространство для фантазии огромное. Но тут конечно надо вам подумать в какую сторону тему развивать в зависимости от времени и навыков.
Вот еще пару ключевых слов: Webassembly, Progressive Web App, стандарты на w3c.org

ГК РФ Статья 406. Просрочка кредитора

Начальство боится потерять то, что уже есть и как-то работает. Если вы будете делать новое параллельно , во внеурочное время, думаю никто не будет против :) У меня такой опыт;
Нам передали проект с говнокодом, и архитектор и сен. дев. сказали что нужно переписать все с нуля, иначе это нам потом аукнется. Ответственный руководитель, добрый но трусливый, не дал ход изменениям. Через год руководитель ушел. И мы остались сидеть на говнокоде. А переписать все заняло бы наверно 2 недели упорной работы. Теперь просто некогда. Жаль что не решились. В принципе начальника можно было тогда уломать, но никто не был достаточно настойчив.

По моему опыте с обобщающими ассоциациями нужно быть осторожным. Это может интерпретироваться как болтология и нежелание работать. Мол возмущаться и жаловаться все горазды..

Думаю самый очевидный аргумент, что такая архитектура не расширяется и достигла своего предела. Если мы планируем расширяться, то нужна новая, модульная, распределенная архитектура, где несколько людей смогут работать над несколькими файлами параллельно, а фреймворк гарантирует что это все вместе будет потом работать. Посмотрите еще сколько эта страница загружается. Наверняка дольше чем нужно. Скажите что это негативно влияет на конверсию (Это чистая правда, есть статьи на хабре)

Google search: sites like codzhouse.co жмак

попробуйте ввести в поисковик: книги по дизайну site:toster.ru
лень смотреть все, посмотрите этот ответ: Книга по дизайну сайтов?

И добавлю, учебник дизайна - это нонсенс. Mаксимум в так называемых книгах по дизайну покажут примеры каких-то решений. Я настраивал свое восприятие на рецензиях опытных дизайнеров у самизнаетекого

Скажу на собственном опыте: пытаясь "совместить приятное с полезным" сильно удлаяешься от основной задачи. И в конечном итоге не сделано ни то ни то. Это горькая правда из той самой поговорки про двух зайцев. Хотите изучить яву, изучайте, не надо тратить время на блоги. Для закрепления материала будет лучше обьяснить пройденый материал другу.
Если вы чувствуете что вас больше тянет в сторону блогов, то может вам и не нужна ява а нужно посмотреть в сторону веб-разработки.