Бронированные окна в банке — это измывательство над клиентом. Почему я должен ОРАТЬ на все отделение о том какую операцию, сколько денег я хочу снять/положить? В Петербурге по-моему все два отделение где можно общаться с оператором с глазу на глаз — это на Старо-Невском и на ЛьваТолстого (там кстати на уровне лица стоит стекло — что тоже заставляет поидиотски наклоняться в дырочку)
Безопасноть? В ПетроЭлектроСбыте принимают деньги и без кассы и бронестекла. Так что не надо.
Будет туда очередь стоять? Сделайте несколько и электронную очередь и минимизируйте количество опреций, откройте дополнительные отделения.
И еще — надписи у операторов типа «Контроллер», «Кассир» не дают представления о том, какие услуги можно получить в том или ином окне.
Ха-ха, 5 баллов! Первая часть с описанием систем — именно так, как все и есть. Пока сижу на SVN, как-то привык, во всяком случае с логами не так запутанно как в git'е. Да и tortoisesvn помогает. Наверное, надо тоже выписать git команды на листочек. :)
Лично я пока имел только nokia телефоны. Могу сказать, что «молодежные» модели, а-ля качаем музыку, приглашаем друзей — то это конечно тот еще кусок говна — пластик, ненужные мульки, и т.п.
Модели бизнес-серий — 6***, 8****, E** получаются заметно лучше и стоят адекватных денег.
Хотя, я пересел с 6233 на e72, и немного был разочарован, потому что несмотря на бОльший функционал e72, symbian s40 выглядит более продуманнее. (например календарь расширили, но с записной книгой он не интегрируется, т.е. записи о ДР и имя контакта вставить нельзя), а symbian s60 не выглядит таким уж гибким да и webkit-браузер хотя лучше чем opera mobile, все равно не то. Здесь конечно iphone со своим appstore и нормальным safari впереди.
Вообщем Nokia с софтом стоит попотеть и сделать свою платформу более продуманной для новых версий телефонов. Я надеюсь они не залажают бизнес-модели
Но я не очень люблю reflection из-за некоторых просадок по перфомансу (http://stackoverflow.com/questions/435553/java-reflection-performance). Так что лучше использовать исходя из потребностей.
Согласен, DI не ограничивается XML и аннотациями. В любом случае это надстройка над setter\field\constructor injection, просто вынос DI конфигурации в отдельное место.
Увеличится или нет — это вопрос отдельный, проблема в другом.
Хорошей практикой считается разнесение контекстов — application context и servlet context (n-штук) и, соответственно, бинов в них по scope'у их работы (loose coupling, tight cohesion в действии). Куда в таком случае совать директуиву сканирования всех пакетов? Во все — будем иметь по инстансу на контекст, в один application context — не круто, там будут ненужные контроллеры и т.п.
Еще можно создать TO, который собственно будет содержать нужную информацию, которая нужна на клиенте. для этого создаются хелперные трансформеры вида
...
public static getTO(MyEntity entity) {
MyTO tobj = new MyTO();
tobj.setFirstData(entity.getFirstLazyData());
....
}
...
и вызываются у service уровня. Сессия там понятно есть.
Понятно, что создаются лишние классы transfer objects, но такова плата. Зато у нас меньше всякого reflection'а, все под контролем, нет неожиданных LazyInitExceptions
под фашизмом подразумевается проверка структуры класса на соответствие нормам. В принципе, это не такой уж фашизм, но, например, фэйлить сборку по такой проверке я рассматриваю как перебор
по-моему, смахивает на фашизм. Чекстайла, PMD, Findbugs я думаю в большинстве случае достаточно.
А вот если бы был плагин, который код форматировал в соответствии с чекстайлом — это было бы хорошо. Конечно, не все ошибки чекстайла можно исправить (остутствие комментария например), но стилевые вещи можно. А так приходится два конфига иметь — чекстайл и code formatting
Безопасноть? В ПетроЭлектроСбыте принимают деньги и без кассы и бронестекла. Так что не надо.
Будет туда очередь стоять? Сделайте несколько и электронную очередь и минимизируйте количество опреций, откройте дополнительные отделения.
И еще — надписи у операторов типа «Контроллер», «Кассир» не дают представления о том, какие услуги можно получить в том или ином окне.
Модели бизнес-серий — 6***, 8****, E** получаются заметно лучше и стоят адекватных денег.
Хотя, я пересел с 6233 на e72, и немного был разочарован, потому что несмотря на бОльший функционал e72, symbian s40 выглядит более продуманнее. (например календарь расширили, но с записной книгой он не интегрируется, т.е. записи о ДР и имя контакта вставить нельзя), а symbian s60 не выглядит таким уж гибким да и webkit-браузер хотя лучше чем opera mobile, все равно не то. Здесь конечно iphone со своим appstore и нормальным safari впереди.
Вообщем Nokia с софтом стоит попотеть и сделать свою платформу более продуманной для новых версий телефонов. Я надеюсь они не залажают бизнес-модели
Но я не очень люблю reflection из-за некоторых просадок по перфомансу (http://stackoverflow.com/questions/435553/java-reflection-performance). Так что лучше использовать исходя из потребностей.
Хорошей практикой считается разнесение контекстов — application context и servlet context (n-штук) и, соответственно, бинов в них по scope'у их работы (loose coupling, tight cohesion в действии). Куда в таком случае совать директуиву сканирования всех пакетов? Во все — будем иметь по инстансу на контекст, в один application context — не круто, там будут ненужные контроллеры и т.п.
В общем спорный момент.
А еще было бы очень круто иметь возможность включить рядом с ссылкой Gmail показ количества новых писем (например Gmail3)
и вызываются у service уровня. Сессия там понятно есть.
Понятно, что создаются лишние классы transfer objects, но такова плата. Зато у нас меньше всякого reflection'а, все под контролем, нет неожиданных LazyInitExceptions
А вот если бы был плагин, который код форматировал в соответствии с чекстайлом — это было бы хорошо. Конечно, не все ошибки чекстайла можно исправить (остутствие комментария например), но стилевые вещи можно. А так приходится два конфига иметь — чекстайл и code formatting
www.maccentre.ru/board/viewtopic.php?p=656344 — тут у товарища никак не получается