Да уж, мне особенно за Xfce4 обидно. Оно же безумно удобное! Я за одну поддержку часовых поясов в часах его обожаю (привет гному с часами без часовых поясов, но с погодным информером).
Первый код я написал на листочке тетрадки после прочтения начальных глав книги по какому-то бэйсику. Посколько главы покрывали только ввод-вывод и ветвления, то код получился у меня ну очень интересный (а писал я какой-то тест). Жаль, что листок не сохранился, но выражение лица того программиста, которому я этот код гордо показал я запомнил на всю жизнь.
P.S. Это было в начальной школе и компьютера у меня не было вообще никакого.
Спасибо. Жаль что в проектах, где я учавствую вся многопоточность разруливает блоками синхронизации. То есть даже java.util.concurrent.* из 1.5 не используется толком.
Но будет больше стимула написать «проект выходного дня» и показать разницу в производительности.
Да. Только переходник нужен, потому что штырьки другие. И вообще, у него там стандартный mini-USB, я его чаще заряжаю подключая к USB-проводку фотоаппарата (который у меня всегда из компа торчит).
А штатный адаптер использую для всего остального, заряжающегося по mini-USB. А это два телефона…
Я этот адаптер использовал в России, Хорватии и Канаде — проблем не было.
Скажу как пользователь (два года как уже) — с кнопочками всё в порядке! А играю я каждый день в метро. Экран у меня безбожно поцарапан и захватан, но это я сам виноват, положил как-то в карман с ключами и поехал на велосипеде — после этого я экран уже не берёг.
Так что рекомендую. А ещё меня батарейка радует. При каждодневной игре заряжать надо раз в несколько недель (правда я яркость экрана на минимум ставлю).
Блин, а в то же время всякая гадость вроде badoo через FB спамит напропалую. Я их уже везде заблокировал и написал жалобы через все формы обратной связи, которые на FB нашёл. И их не отключают! А более-менее нейтральное приложение вырезают с корнем…
Не знаю точно как у Asus, но если они основаны на продуктах Always Innovating, то там ещё и дополнительная батарея и внутреннее пространство для донглов. Ну и горячее переключение между разными OS (через стандартный U-Boot) очень полезна фича.
Жаль только, что Always Innovating никак вторую модель своего Touch Book'а не доделают. Последняя информация — опять сдвинули, теперь обещают в апреле.
Плюс: из коробки Ubuntu и можно ставить всё что угодно, позиционируется именно как домашний сервер, а не как недо-NAS. А ещё у них есть вариант с HDMI портом, только дорог чрезмерно.
Минус: заказал себе неделю назад, всё никак не доедет…
Именно! Мы учли этот опыт и в следующем проекте хостимся в облаке. Я об этом чуть выше в комментариях уже писал. Правда этот сервис ещё не скоро уйдёт в продакшен (в июне), так что про надёжность Cassandra в облаке я пока говорить не могу.
1 и 2 так и было. Потом нужно было сделать nodetool removetoken (описано тут). Иначе при включении старой ноды её узнают другие по IP-адресу и выдадут обратно старый участок кольца. Я это не проверял, но так сказали на семинаре.
После этого в конфиге на ноде выставлялся initialToken (в XML конфиге, у нас 0.6.x, в котором ещё XML). И я запускал сервис кассандры.
На счёт ухода диапазона в оффлайн — это не проблема как раз. Другие ноды это видят и принимают операции к себе, временно. И я даже видел, что это работает. С самой первой упашей нодой, после включения обратно после 15-минутного downtime на одной из других нод (кажется на следующей по кольцу) образовался файл в streams, который затем отправился на вернувушуюся ноду.
Проблема в том, что диапазон задаётся одним числом — границей конца диапазона. Поэтому чтобы получить сбалансированное кольцо надо было много раз перевтыкать ноды.
И ещё, это уже может быть моя паранойя, но я постоянно, когда после очередных перестановок все ноды включены, командовал nodetool repair. Это самая трудная команда. Известно, что в ней есть баги, нет никакой возможности узнать заверешилась ли починка. Зато известно, что нельзя одновременно чинить несколько нод. В общем я её запускал, ждал, глядя на статистику загрузки на всех нодах, и, когда мне казалось что починка закончилась, продолжал свои перестановки.
Вообще-то кусочек данных я всё-таки при этом потерял. Повезло, что это было в некритичной Column Family — кэше для данных из внешнего сервиса. Они повредились и возникала ошибка чтения. Кстати, при повреждённых данных я видел два разных эксепшена:
1. BufferUnderFlow — тут всё просто, мы получили два байта для int вместо четырёх и упали.
2. SocketTimeoutException на Read. Тут было сложнее, потому что сначала я думал, что эти эксепшены от перегрузки кластера, то есть реальный тайм аут. Но потом заметил, что эксепшен повторяется в 100% случаев для одних и тех же записей. Тогда появилась идея, что виновато повреждение данных, и удалил эти записи через консольный клиент.
Насколько я знаю, Facebook больше не использует Cassandra вообще. Они используют HBase для тех задач, для которых раньше использовали Cassandra. Но я не в FB работаю, так что точно знать не могу.
Во-первых, в кластере не может быть меньше нод, чем Replication Factor. Минимальный рекомендуемый RF — 3. Это объясняется тем, что в случае проблем и порчей информации на одной ноде всё равно будет большинство нод с правильной информацией.
Во-вторых, сервера у нас неудачные, с маленькими жёсткими дисками и просто по объёму данных надо столько серверов. В нашем кластере ресурсы CPU и RAM избыточны, HDD недостаточно.
Следующий проект на Cassandra (который уже разработан, но ещё не запущен в продакшн) хостится в облаке. Как раз чтобы не было такого дисбаланса по ресурсам.
Возможно меня ввели в заблуждение на семинаре. Семинар вели два человека: один всё время гвоорил, второй подключался в сложных местах и в ответах на сложные вопросы. В остальное время он писал код Cassandra (я заглядывал через плечо).
Формат совместим. Но есть опасность получить не совместимость по commitlog. Этом случае можно просто удалить его. Чтобы гарантировано избежать этого надо выполнить nodetool drain перед выключением — это запрешает write операции на ноде и довольно быстро (секунды) приводит к очищению commitlog.
Первый код я написал на листочке тетрадки после прочтения начальных глав книги по какому-то бэйсику. Посколько главы покрывали только ввод-вывод и ветвления, то код получился у меня ну очень интересный (а писал я какой-то тест). Жаль, что листок не сохранился, но выражение лица того программиста, которому я этот код гордо показал я запомнил на всю жизнь.
P.S. Это было в начальной школе и компьютера у меня не было вообще никакого.
Но будет больше стимула написать «проект выходного дня» и показать разницу в производительности.
А штатный адаптер использую для всего остального, заряжающегося по mini-USB. А это два телефона…
Я этот адаптер использовал в России, Хорватии и Канаде — проблем не было.
Так что рекомендую. А ещё меня батарейка радует. При каждодневной игре заряжать надо раз в несколько недель (правда я яркость экрана на минимум ставлю).
Жаль только, что Always Innovating никак вторую модель своего Touch Book'а не доделают. Последняя информация — опять сдвинули, теперь обещают в апреле.
Вот здесь почти такой же отчёт с разборкой.
Плюс: из коробки Ubuntu и можно ставить всё что угодно, позиционируется именно как домашний сервер, а не как недо-NAS. А ещё у них есть вариант с HDMI портом, только дорог чрезмерно.
Минус: заказал себе неделю назад, всё никак не доедет…
После этого в конфиге на ноде выставлялся initialToken (в XML конфиге, у нас 0.6.x, в котором ещё XML). И я запускал сервис кассандры.
На счёт ухода диапазона в оффлайн — это не проблема как раз. Другие ноды это видят и принимают операции к себе, временно. И я даже видел, что это работает. С самой первой упашей нодой, после включения обратно после 15-минутного downtime на одной из других нод (кажется на следующей по кольцу) образовался файл в streams, который затем отправился на вернувушуюся ноду.
Проблема в том, что диапазон задаётся одним числом — границей конца диапазона. Поэтому чтобы получить сбалансированное кольцо надо было много раз перевтыкать ноды.
И ещё, это уже может быть моя паранойя, но я постоянно, когда после очередных перестановок все ноды включены, командовал nodetool repair. Это самая трудная команда. Известно, что в ней есть баги, нет никакой возможности узнать заверешилась ли починка. Зато известно, что нельзя одновременно чинить несколько нод. В общем я её запускал, ждал, глядя на статистику загрузки на всех нодах, и, когда мне казалось что починка закончилась, продолжал свои перестановки.
Вообще-то кусочек данных я всё-таки при этом потерял. Повезло, что это было в некритичной Column Family — кэше для данных из внешнего сервиса. Они повредились и возникала ошибка чтения. Кстати, при повреждённых данных я видел два разных эксепшена:
1. BufferUnderFlow — тут всё просто, мы получили два байта для int вместо четырёх и упали.
2. SocketTimeoutException на Read. Тут было сложнее, потому что сначала я думал, что эти эксепшены от перегрузки кластера, то есть реальный тайм аут. Но потом заметил, что эксепшен повторяется в 100% случаев для одних и тех же записей. Тогда появилась идея, что виновато повреждение данных, и удалил эти записи через консольный клиент.
Во-вторых, сервера у нас неудачные, с маленькими жёсткими дисками и просто по объёму данных надо столько серверов. В нашем кластере ресурсы CPU и RAM избыточны, HDD недостаточно.
Следующий проект на Cassandra (который уже разработан, но ещё не запущен в продакшн) хостится в облаке. Как раз чтобы не было такого дисбаланса по ресурсам.
Я перезапускал по одной ноде за раз. Таким образом в кластере всегда было 4 рабочих ноды.