Мне кажется, основной мессадж статьи вот в этом абзаце:
Вторым параметром мы рассмотрим мощность вещания беспроводной сети. Для домашнего использования нам с лихвой хватит слабого сигнала/среднего сигнала (сам лично пользуюсь слабым, поскольку максимально-удалённая точка квартиры от роутера находится в 6 метрах, считая стены). Если вы не носитесь с ноутбуком по всей квартире, прячась от эфира за холодильником, пытаясь скачать только что вышедший фильм с торрент-трекера, то слабого сигнала хватает с запасом.
Т.е. зачем выдувать в антенны роутера 100% мощности, если все потребители находятся в пределах комнаты.
— Все разработчики собираются, допустим, раз в месяц, выделяют несколько дней и досконально изучают весь код, обсуждая (и исправляя) спорные места.
— Архитектор держит в голове всю структуру проекта и следит за каждым коммитом, пинная разработчика если тот коммитает что-то эдакое. Тоже code-review в каком-то смысле :)
Проводим, но редко, когда возникают проблемы, и не всего кода.
Надо бы регулярно по идее, штука очень полезная. Все осложняется roadmap'ом и огромным количеством кода и подпроектов.
> Помню LiveView от Sony Ericsson — но там минимум функций
В самом аппарате их (функций) вообще почти нет. Аппарат может только показывать картинку, передаваемую со смарта и передавать на смарт нажатия сенсоров. Т.е. без смартфона — он ничего не умеет.
Категорически плюсую, очень интересные и неочевидные вещи попадаются. Еще добавлю в копилку слов для гугления полезных советов — «java exceptions anti-patterns».
> Код с анонимными классами читается гораздо трудней и сложен для восприятия.
Ну я бы поспорил, это очень субъективно, и еще зависит от конкретного кода. Часто такие решения достаточно универсальны и красивы.
> String status = plan.getStatus();
> if (status.equals(«draft»)) {
Еще можно добавить, что это не только медленно, но и небезопасно, т.к. plan.getStatus() теоретически может вернуть null, и тогда огребем NPE при вызове equals().
Лучше сравнивать строки так:
> Да, есть Java и иже с ней. Беда только в том, что она не может обеспечить истинную и прозрачную персистентность объектов (ведь здесь нужна поддержка со стороны ОС) и удобную прозрачность распределения (абстрагируемся от локальности/удалённости вызываемого объекта).
Да вы, батенька, пессимист.
«Украдут», «скопируют».
Спец, который смог придумать и детально разработать такой мега-интерфейс — сам по себе уже на вес золота, и крупная корпорация будет рада прибрать его к своим рукам.
У них есть свои API для аналогичных целей, вполне реально своими силами реализовать регистрацию/авторизацию.
> т.е. в любом случае надо оставлять регистрацию обычную
Ну вот тут мы и упираемся в проблему — если сильно упростить процедуру регистрации и позволять такие «анонимные» аккаунты — то будет нашествие ботов.
Имхо, для российских условий, достаточно будет ВК, майл.ру, гугл, твиттер, фейсбук. У 90-95% посетителей будет аккаунт в одном из этих мест. Для оставшихся 5-10% можно оставить обычную процедуру регистрации, но с вопросами/капчами и обязательным подтверждением через электропочту.
А вот такую штуку — rpxnow.com/ не пробовали? Имхо, спамботов должно только так отсекать, и все действия пользователя при регистрации сведены практически к паре кликов.
1. Зачем батарейки если подключаемся к сети? Может быть было бы проще использовать аккумулятор с возможностью зарядки прямо в аппарате?
2. Можно ли подключать аппарат к компу для сбора данных/настройки?
Вторым параметром мы рассмотрим мощность вещания беспроводной сети. Для домашнего использования нам с лихвой хватит слабого сигнала/среднего сигнала (сам лично пользуюсь слабым, поскольку максимально-удалённая точка квартиры от роутера находится в 6 метрах, считая стены). Если вы не носитесь с ноутбуком по всей квартире, прячась от эфира за холодильником, пытаясь скачать только что вышедший фильм с торрент-трекера, то слабого сигнала хватает с запасом.
Т.е. зачем выдувать в антенны роутера 100% мощности, если все потребители находятся в пределах комнаты.
Пересмотр кода ведь бывает разный. Например:
— Перекрестное ревью коммитов (т.е. один разработчик проверяет код, закоммитанный другим)
— Все разработчики собираются, допустим, раз в месяц, выделяют несколько дней и досконально изучают весь код, обсуждая (и исправляя) спорные места.
— Архитектор держит в голове всю структуру проекта и следит за каждым коммитом, пинная разработчика если тот коммитает что-то эдакое. Тоже code-review в каком-то смысле :)
CR не панацея, и не спасает от всего. Речь в голосовании идет, как я понял, о пересмотре-рефакторинге всего кода, а не только нового.
Надо бы регулярно по идее, штука очень полезная. Все осложняется roadmap'ом и огромным количеством кода и подпроектов.
Валяется, подтверждаю. Большой и неудобный, как показала практика :(
В самом аппарате их (функций) вообще почти нет. Аппарат может только показывать картинку, передаваемую со смарта и передавать на смарт нажатия сенсоров. Т.е. без смартфона — он ничего не умеет.
Категорически плюсую, очень интересные и неочевидные вещи попадаются. Еще добавлю в копилку слов для гугления полезных советов — «java exceptions anti-patterns».
Ну я бы поспорил, это очень субъективно, и еще зависит от конкретного кода. Часто такие решения достаточно универсальны и красивы.
> String status = plan.getStatus();
> if (status.equals(«draft»)) {
Еще можно добавить, что это не только медленно, но и небезопасно, т.к. plan.getStatus() теоретически может вернуть null, и тогда огребем NPE при вызове equals().
Лучше сравнивать строки так:
«draft».equals(status)
А зачем именно Java? Вон есть тот же Erlang с его распределенностью
«Украдут», «скопируют».
Спец, который смог придумать и детально разработать такой мега-интерфейс — сам по себе уже на вес золота, и крупная корпорация будет рада прибрать его к своим рукам.
Вы путаете понятия «лицензирование» и «патентование».
В описанном случае, есть как минимум такие варианты:
1. Распостранять (продавать) этот мега-интерфейс под определенной лицензией, запрещающей перепродажу/перелицензирование/передачу/дарение/etc.
2. Выложить в паблик-портфолио несколько концепций/макетов, и продаться потом крупной корпорации.
3. Выложить в паблик общие макеты, и продавать услуги по кастомизации под конкретных заказчиков.
У них есть свои API для аналогичных целей, вполне реально своими силами реализовать регистрацию/авторизацию.
> т.е. в любом случае надо оставлять регистрацию обычную
Ну вот тут мы и упираемся в проблему — если сильно упростить процедуру регистрации и позволять такие «анонимные» аккаунты — то будет нашествие ботов.
Имхо, для российских условий, достаточно будет ВК, майл.ру, гугл, твиттер, фейсбук. У 90-95% посетителей будет аккаунт в одном из этих мест. Для оставшихся 5-10% можно оставить обычную процедуру регистрации, но с вопросами/капчами и обязательным подтверждением через электропочту.
А ЭЦП в наших судах вообще прокатит? Ну т.е. если в договоре ввести требование — вся электронная переписка и все эл.документы должны быть подписаны.
2. Можно ли подключать аппарат к компу для сбора данных/настройки?
Вот здесь посмотрите еще — wiki.agiledev.ru/doku.php?id=aop:aop_php — некоторые проекты вроде еще живы.