Вижу, что я не единственный… Но думаю на хабре писать мало… Отписал в твиттер, в тех. саппорт, комментом в блог… Может, если нас будет много, то Гугл сделает это чудо хотя бы опциональным. А в остальном мне очень даже нравится новый дизайн.
Спасибо за ответ, но, как верно заметил Dolios, я не нашел пояснений по-поводу проблем с переправкой США->Россия — кто будет нести ответственность в случае потери посылки или её повреждения на этом этапе?
Интересно конечно, но есть некоторые вопросы. Насколько я понимаю, если посылка не доходит мне при покупке на ebay — то я имею право и могу потребовать деньги обратно — ebay меня поддержит. В случае же, если я буду покупать через вас — то товар доходит вам, происходит подтверждение доставки, и теперь никто не несет ответстенности за то дойдет ли Мне товар от вас?..
Пока не понял преимуществ покупки не напрямую с ebay(payPal делается довольно просто), буду рад разъяснениям…
Только меня расстраивает панель слева?.. Ужасно неудобно ( Они пару дней назад в твиттере спрашивали «как оно вам?»… Мольбы сделать панель хотя-бы опциональной игнорируют…
Nginx пользует предварительно выделенную память, пользует epoll/kqueue, в конце концов да, также может использовать sendfile, является FSM заточенным под отдачу статики… Зачем же занимать Thread Pool томката на отдачу статики, если с этим и так прекрасно справляется nginx?.. Мне кажется вполне логичным четко распределять отдачу static и dynamic контента в системе…
Где вы нашли машину с LPT? =) Было бы интересно почитать про реализацию такой лампы, только основанную на Bluetooth… С проводами сильно не хотелось бы возиться…
Что-то мне подсказывает, что без силы воли получится с тем же успехом оставлять 5-8 непрочитанных rss записей, вместо 5-8 не прочитанных из книги страниц в день ) Сам rss не пользуюсь — перевел все подписки через twitterfeed в твиттер, и хожу только по ссылкам на интересные мне заголовки, так нету гнетущего чувства: «еще 10 непрочитанных» ;-)
Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans
Patterns of Enterprise Application Architecture by Martin Fowler
Вот что вспомнилось на вскидку из must read кроме Кериевски
1) У вас UpdateManager САМ создает экземпляры updater'ов, т.е. он осведомлен об их реализации, и в тоже время пользуется ими через интерфейс, получается двояко — вроде бы и пользуемся через интерфейс и быть там может все что угодно, но в тоже время сами создаем экземпляры и знаем что там внутри, т.е. зависимость то есть, уместнее было бы настраивать Manager, передавая ему его worker'ов через интерфейс, тогда не было бы никакой связи между реализациями.
2 ) При реализации updater'ов, вы заставляете того кто их пишет заботиться о том чтобы вызвать самостоятельно у manager'а метод «next», и если этого не произойдет — случится коллапс, паровоз не поедет, все застрянет… «Нужно писать так, чтобы легко было пользоваться правильно, и сложно было пользоваться неправильно» (с) не помню кто писал, так вот тут этот принцип явно не в силе получается.
3) Нет никакой индикации о том что процесс завершился и в тоже время если вызвать метод «runUpdateProcess» повторно — то старый Instance просто потеряется(утечет), будет конкурентное обращение к очереди да и вобщем-то скорее всего будет очередной коллапс в тот момент, когда обе задачи попробуют зарелизить instance…
Отлично получилось, ждем отчета о зимней температуре ;-) Год назад провел приблизительно тот же набор операций на своей лоджии + вывели с комнаты дополнительно батарею. После прошедшей зимы планирую переделать утепление +)
Сколько мальку годиков? ) Мой точно также облюбовал новую комнату и постепенно она превратилась в маленькую игровую площадку с бесплатно прилагающимся папой на борту )
Когда появилось два указателя, подумал что сейчас через pinch/shrink будут аккардион раздувать ) Молодцы, нужно иметь выдержку чтобы делать все на симуляторе ) Уже хочется подержать в руках )
Шикарный ноутбук. Хотя мне кажется, что использование компьютера, будь то стационарный вариант или ноутбук в качестве игровой приставки сейчас все больше становится не актуальным… Имхо покупка для таких целей XBox, PS, Wii выглядит гораздо более оправданной…
Пока не понял преимуществ покупки не напрямую с ebay(payPal делается довольно просто), буду рад разъяснениям…
Patterns of Enterprise Application Architecture by Martin Fowler
Вот что вспомнилось на вскидку из must read кроме Кериевски
1) У вас UpdateManager САМ создает экземпляры updater'ов, т.е. он осведомлен об их реализации, и в тоже время пользуется ими через интерфейс, получается двояко — вроде бы и пользуемся через интерфейс и быть там может все что угодно, но в тоже время сами создаем экземпляры и знаем что там внутри, т.е. зависимость то есть, уместнее было бы настраивать Manager, передавая ему его worker'ов через интерфейс, тогда не было бы никакой связи между реализациями.
2 ) При реализации updater'ов, вы заставляете того кто их пишет заботиться о том чтобы вызвать самостоятельно у manager'а метод «next», и если этого не произойдет — случится коллапс, паровоз не поедет, все застрянет… «Нужно писать так, чтобы легко было пользоваться правильно, и сложно было пользоваться неправильно» (с) не помню кто писал, так вот тут этот принцип явно не в силе получается.
3) Нет никакой индикации о том что процесс завершился и в тоже время если вызвать метод «runUpdateProcess» повторно — то старый Instance просто потеряется(утечет), будет конкурентное обращение к очереди да и вобщем-то скорее всего будет очередной коллапс в тот момент, когда обе задачи попробуют зарелизить instance…
Надеюсь на правильное отношение к критике…
Сколько мальку годиков? ) Мой точно также облюбовал новую комнату и постепенно она превратилась в маленькую игровую площадку с бесплатно прилагающимся папой на борту )
>Использовать-то можно, а местами буст незаменим. Главное, чтоб использующий с головой дружил.
Так вот мы приходим к выводу, что в данном посте описано целесообразное применение boost ;-)