Судя по картинке, у него там Windows 7 установлена. С таким раскладом, вероятно, комп вообще к интернету не подключен никак, иначе эту древность давно бы уже взломали)
User flow диаграмма — это хорошо. Еще лучше, если дизайнеры делают прототип. Можно это сделать с помощью marvelapp.com, к примеру. Тут плюсы в том, что сам дизайнер может проверить, насколько хорошо работает его дизайн и можно заказчику продемонстрировать будущую логику работы приложения. Если сильно заморочиться, можно и валидацию дизайна на пользователях замутить. Но на это заказчики редко идут, конечно, т.к. дополнительного времени и денег у них обычно нет.
Первые два плюса относительны.
Дома никто не отвлекает, если дома никого нет. А если есть, то отвлекают покруче, чем в open space, приходится ругаться чтобы дали спокойно поработать.
Не тратится время и силы на дорогу. Зато приходится тратить столько же времени и сил, если не больше, чтобы поддерживать нормальную физическую форму.
Любую технологию нужно применять с умом. Цель статьи — разъяснить особенности и отличия двух подходов к выполнению одних и тех же действий, а не убедить, что именно этот подход является единственно верным.
Пусть реализует только те, которые используются в данном сценарии, в чем проблема? IDE не сгенерит заглушки? Или же пусть создает один универсальный осмысленный mock для DAO, реализующий все методы, который будет использоваться во всех тестах. Если DAO описывает интерфейс между логикой программы и хранилищем, то mock должен симулировать это хранилище.
Можно и так. Но для меня, например, чем меньше методов у мокнутого класса — тем проще работать с его моками.
А к чему еще он должен быть привязан? Это же DAO этой сущности! Нафига тогда он нужен, если он ничего ни знает о самой сущности? И как Repository нас избавляет от необходимого рефакторинга при изменении типа поля? В том, что типы заткнуты в Specification?
А почему он должен быть к ней привязан и что-то про нее знать? Чтобы что с этим делать? В описанном примере репозиторий знает только к какому бекэнду стучаться и все. ORM осуществляется так же каким-то другим классом, как я понимаю. Поэтому чем меньше репозиторий знает про модель — тем лучше, т.к. изменения в модели не тянут за собой изменений в логике репозитория.
И как мокировать данный метод? Вы можете по этому методу сказать, какие запросы тут нужно мокировать? Если бы стоял простой findByUserName(), все было бы просто и понятно. Здесь же приходится писать дополнительную логику, узнающую specification, переданную в параметре.
Какие вы будете выполнять запросы к БД — те и подставляйте в качестве моков. На каждый запрос отдельный мок. И, может, не один — чтобы проверить все возможные варианты со всеми возможными параметрами (корректными и некорректными).
P.S. Мне кажется, вы слишком цеплятесь за конкретные вещи в статье, посвященной довольно абстрактной тематике. Ну, замените мысленно Hibernate на MongoDB, если оно вам так режет глаз.
Спасибо за комментарий!
The Busy Coder's Guide to Android Development или Android Programming The Big Nerd Ranch Guide. Первая распространяется по подписке и постоянно обновляется для соответствия новым версиям Андроида. Вторая малость устарела, но понимание основ дает хорошее. А основы со времен Android 4.0 мало поменялись.
Допустим, пришел я к менеджеру, спросил, что мне надо делать чтобы ЗП росла. Менеджер обещал подумать. Через неделю сообщил, что повысил мне ЗП, но никакой новой работы не дал. И что дальше? Это означает, что я изначально получал ниже рынка? Или что у менеджера много шальных денег? Что будет в следующий раз когда я приду с таким вопросом? Не решил ли менеджер, что я из него «выбил» повышение и не стал ли придумывать план как меня сплавить и заменить более дешевым сотрудником (работы-то у меня не прибавилось)? В общем, алгоритм, предложенный в статье ничем не лучше алгоритма «сменил работу — получил прибавку». Надо просто исходить из своих интересов: если текущая работа нравится — идти на разговор к начальству, если хочется сменить обстановку — идти по собеседованиям.
Прочитал первый абзац перевода. Чувак решил стать более продуктивным путем полного исключения всей другой деятельности кроме изучения продуктивности из своей жизни на один год. Попахивает фейлом как-то, но статью дочитаю.
Добро пожаловать в стан программистов!
Тоже в свое время перескочил из сетевых администраторов (работал в магистальном ISP) в программисты и нисколько не жалею. В админстве больше всего напрягало, что нужно держать в голове кучу знаний, из которых в текущей работе нужны, от силы, процентов пять. Но если вдруг случается коллапс, то надо в срочном порядке поднимать пласты из самых дальних закоулков памяти и применять их в условиях наличия орущего над ухом шефа. В общем, то еще развлечение :-)
Спасибо за статью! Маск действительно очень интересный человек и пытается двигать вперед технологии в сфере своих интересов. Только вот не думаю я, что из-за Маска что-то поменяется в нашей космической промышленности. Даже если Россия лишится зарубежных контрактов на запуск спутников и тому подобного, всегда останется внутренний заказ.
У нас в офисе бесплатный чай, кофе, сок, газировка. За обед (приготовленный на собственной кухне собственным поваром) платим очень скромные деньги — в день выходит намного меньше, чем в самой паршивой столовке. Качество обедов бывает разное — иногда хочется еще порции три сожрать, а иногда выбрасываешь практически все.
Возможно, вы правы. Но, по-моему, 99% таких библиотек, созданных только ради того, чтобы написать очередной тетрис, так и останутся лежать на винчетсерах их создателей. И для следующего своего проекта такой разработчик будет с нуля писать очередной велосипед.
Безусловно, существует вероятность, что при таком подходе программист создаст новую крутую библиотеку, которая сэкономит сотни тысяч человеко-часов для всего мира. Но вероятность того, что такая библиотека уже есть, а из вновь написанной будет использоваться в текущем проекте не больше 10%, намного выше. В словах автора главное, я думаю, «для создания очередного тетриса». То есть, если задача тривиальна, надо ее просто решать наиболее быстрым способом. Писать фреймворки стоит в тех случаях, когда существующие решения объективно не очень хороши.
В статье есть интересные мысли. Но заявления о том, что образование есть познание Бога и о необходимости найти ментора, который поможет пройти кризисы роста, полностью перечеркивают все доверие к словам автора.
Полностью поддерживаю. У нас все университеты носят гордое звание «Федеральное государственное бюджетное образовательное учреждение
высшего ПРОФЕССИОНАЛЬНОГО образования». Профессия предполагает наличие знаний и навыков, за применение которых работодатели готовы платить деньги. По факту, в 99% случаев, человек, окончивший университет, ими не обладает. И, кстати, у довольно большого числа моих друзей и занкомых университет отбил всякое желание получать какие-либо новые знания. Научили учиться, ага.
Я бы купил смартфон с интересным дизайном, хорошими ТТХ и качественным софтом. Страна, в которой зарегистрирован производитель, при этом не особо важна — все равно сборочный конвейер находится в Китае. Если российской компании удалось добиться от китайцев чтобы те собрали для нее удачный аппарат — так это хорошо и здорово. Буду с удовольствием пользоваться и, на задворках сознания, радоваться, что «поддержал отечественного производителя».
Профиль нагрузки сильно зависит от ее вида. На моих задачах LA может иметь приблизительно одинаковые значения на протяжении нескольких суток. Вы правильно заметили — резкое изменение показателя LA — это симптом. А проблемы может, на самом деле, и не быть. Нужно просто обращать внимание на колебания LA и исследовать причины его «нестандартного поведения».
Дома никто не отвлекает, если дома никого нет. А если есть, то отвлекают покруче, чем в open space, приходится ругаться чтобы дали спокойно поработать.
Не тратится время и силы на дорогу. Зато приходится тратить столько же времени и сил, если не больше, чтобы поддерживать нормальную физическую форму.
Можно и так. Но для меня, например, чем меньше методов у мокнутого класса — тем проще работать с его моками.
А почему он должен быть к ней привязан и что-то про нее знать? Чтобы что с этим делать? В описанном примере репозиторий знает только к какому бекэнду стучаться и все. ORM осуществляется так же каким-то другим классом, как я понимаю. Поэтому чем меньше репозиторий знает про модель — тем лучше, т.к. изменения в модели не тянут за собой изменений в логике репозитория.
Какие вы будете выполнять запросы к БД — те и подставляйте в качестве моков. На каждый запрос отдельный мок. И, может, не один — чтобы проверить все возможные варианты со всеми возможными параметрами (корректными и некорректными).
P.S. Мне кажется, вы слишком цеплятесь за конкретные вещи в статье, посвященной довольно абстрактной тематике. Ну, замените мысленно Hibernate на MongoDB, если оно вам так режет глаз.
Спасибо за комментарий!
Тоже в свое время перескочил из сетевых администраторов (работал в магистальном ISP) в программисты и нисколько не жалею. В админстве больше всего напрягало, что нужно держать в голове кучу знаний, из которых в текущей работе нужны, от силы, процентов пять. Но если вдруг случается коллапс, то надо в срочном порядке поднимать пласты из самых дальних закоулков памяти и применять их в условиях наличия орущего над ухом шефа. В общем, то еще развлечение :-)
высшего ПРОФЕССИОНАЛЬНОГО образования». Профессия предполагает наличие знаний и навыков, за применение которых работодатели готовы платить деньги. По факту, в 99% случаев, человек, окончивший университет, ими не обладает. И, кстати, у довольно большого числа моих друзей и занкомых университет отбил всякое желание получать какие-либо новые знания. Научили учиться, ага.