Прекрасный материал! Жалко, что решение не масштабируемое: в статье рекомендуется делать все локально, но в реалиях живой команды - когда люди приходят и уходят, появляются зеленые джуны - хотелось бы, чтобы активация хуков была или автоматом, или максимально просто.
У меня тоже этот аппарат (2/32), весьма позитивный опыт использования, кроме двух вещей:
— gps ловит раз в полгода
— тачскрин не особо радует точностью — при тесте линии он рисует синусоиду с амплитудой в 7-8мм
Если с первым я просто не особо заморачивался, то второе не очень приятно — программа калибровки в меню телефона просто падает с ошибкой при заходе в нее. Не слышали, как это решается?
Телефон с оригинальной прошивкой, ничего не делал специального.
Да и вообще, когда один разработчик работает на OS X, другой на Windows, а продакшен на Debian, то жди беды, это не считая того, что каждый делает работу по настройке окружения.
Не соглашусь, при должном подходе факт разработки на разных платформах заставляет делать код и скрипты мультиплатформенными и позволяет выловить редкие баги раньше.
Особенно это очевидно, если разработка, к примеру, под виндой, а продакшн сервер — *nix.
На чем-то ее же надо было создателям написать) Да чтоб еще и работало легко на всех платформах.
Какую современную утилиту не возьми, мне приходится устанавливать или perl, или python, или node.js, или ruby, или java…
В итоге, я просто поставил однажды все это и больше у меня голова не болит.
Об удаленке надо договариваться позже, через пару месяцев, в бою показав хорошие качества.
После этого сможете себе позволить 1, а потом и 2 дня на удаленке в неделю. Не так плохо.
У вас разработка архитектуры в какой-то двухчасовой транзакции. Чуть что не так — откатилась :)
Я наоборот, предпочитаю пару дней просто поспать с идеями, особо их не думая. В определенный момент «щелкает», — 10 минут, и вся архитектура готова на бумажке.
найти заказчика, который бы смог мне оплачивать $15/час 8ч*20дней — просто не реально
Наверное, вы рассматриваете только русскоязычные заказы?
Работаю на oDesk, за значительно более интересные деньги, чем $15/h, занят 30-40 часов в неделю уже полгода, русскоязычные биржи и заказы даже не рассматриваю. Если кратко — жадные, глупые.
Один момент по поводу моей реализации тестов:
По ходу подготовки к тесту и его запуска, автоматически тестируется еще:
1. Слой миграций — все ли миграции БД прошли на in-memory БД и все ли хорошо. Тест неявно это покажет.
2. Слой ORM. Бывает, что не очень понятно, как замаппить такую-то колонку БД на поле объекта, особенно в связях many-to-many и каскадных сохранениях данных. Тесты с участием реального ORM очень помогают не «удивляться» особенностям ORM, вылезшим на PROD.
Для своих проектов весь слой базы данных я выделяю в отдельный интерфейс (или несколько).
Это сделано для того, чтобы можно было легко поменять реализацию БД, или вообще перейти на другой тип хранилища.
Получается, что этот слой содержит
1. Запросы к БД
2. Какую-то нехитрую логику.
К примеру, метод
User getOrCreateUser(String firstName, String lastName)
Ищет пользователя по имени, если не находит — создает пользователя и заполняет служебные колонки: dateCreated, dateUpdated.
Очевидно, это надо протестировать. Также как и автор статьи, я использую базенку в памяти.
Как бы вы все сделали?
И как называются такие тесты? Которые запускаются с юнит-тестами, на них похожи, полностью автономны от внешних зависимостей и т.п.
Ironic
Прекрасный материал! Жалко, что решение не масштабируемое: в статье рекомендуется делать все локально, но в реалиях живой команды - когда люди приходят и уходят, появляются зеленые джуны - хотелось бы, чтобы активация хуков была или автоматом, или максимально просто.
— gps ловит раз в полгода
— тачскрин не особо радует точностью — при тесте линии он рисует синусоиду с амплитудой в 7-8мм
Если с первым я просто не особо заморачивался, то второе не очень приятно — программа калибровки в меню телефона просто падает с ошибкой при заходе в нее. Не слышали, как это решается?
Телефон с оригинальной прошивкой, ничего не делал специального.
www.liquibase.org/documentation/generating_changelogs.html
Не соглашусь, при должном подходе факт разработки на разных платформах заставляет делать код и скрипты мультиплатформенными и позволяет выловить редкие баги раньше.
Особенно это очевидно, если разработка, к примеру, под виндой, а продакшн сервер — *nix.
Какую современную утилиту не возьми, мне приходится устанавливать или perl, или python, или node.js, или ruby, или java…
В итоге, я просто поставил однажды все это и больше у меня голова не болит.
numbers.forEach(System.out::println);Мы передали обычный метод статической переменной «out».
После этого сможете себе позволить 1, а потом и 2 дня на удаленке в неделю. Не так плохо.
Я наоборот, предпочитаю пару дней просто поспать с идеями, особо их не думая. В определенный момент «щелкает», — 10 минут, и вся архитектура готова на бумажке.
Наверное, вы рассматриваете только русскоязычные заказы?
Работаю на oDesk, за значительно более интересные деньги, чем $15/h, занят 30-40 часов в неделю уже полгода, русскоязычные биржи и заказы даже не рассматриваю. Если кратко — жадные, глупые.
Писал как-то статью про мой фриланс.
habrahabr.ru/post/186700/
И, конечно, исходник должен быть в паблике.
Это самые верные доказательства, что библиотека готова к реальным проектам.
Один момент по поводу моей реализации тестов:
По ходу подготовки к тесту и его запуска, автоматически тестируется еще:
1. Слой миграций — все ли миграции БД прошли на in-memory БД и все ли хорошо. Тест неявно это покажет.
2. Слой ORM. Бывает, что не очень понятно, как замаппить такую-то колонку БД на поле объекта, особенно в связях many-to-many и каскадных сохранениях данных. Тесты с участием реального ORM очень помогают не «удивляться» особенностям ORM, вылезшим на PROD.
Это сделано для того, чтобы можно было легко поменять реализацию БД, или вообще перейти на другой тип хранилища.
Получается, что этот слой содержит
1. Запросы к БД
2. Какую-то нехитрую логику.
К примеру, метод
User getOrCreateUser(String firstName, String lastName)
Ищет пользователя по имени, если не находит — создает пользователя и заполняет служебные колонки: dateCreated, dateUpdated.
Очевидно, это надо протестировать. Также как и автор статьи, я использую базенку в памяти.
Как бы вы все сделали?
И как называются такие тесты? Которые запускаются с юнит-тестами, на них похожи, полностью автономны от внешних зависимостей и т.п.