Обновить
11
0
Dmitry Kireev@AutomationD

DevOps

Отправить сообщение
Встал в очередь.
Заметно что Амазон сильно инвестирует в распознавание голосом. Взять к примеру FireTV Voice search (рекламу с Gary Busey видели?), Amazon Dash , а теперь и Echo.
Amazon Prime Music — еще один продукт который по их замыслу должен взлететь на платформе Echo.

И это только начало!

Мне тоже интересно, ставил через RDO, работало хорошо. Но вот дальше?
Да, крутая штука, оживил машину с мертвым аккумулятором (был включен свет на протяжении 3х дней). После этого заряда устройства еще хватило чтобы зарядить телефон 3 раза. Вещь!
.py скрипт со всеми вложениями загрузится, создастся в редакторе (editor.make_new_file('AirHockey', contents), после чего его можно запустить через редактор либо через специальный ярлык со своим scheme (pythonista://MyScript?action=run).

Приложение, естественно, запускается в песочнице pythonista.
Кто-то уже пользовался ESP8266? Разве не это ли решение без Arduino?
Интересно то, что в pythonista можно делать вот такой трюк:
import urlib
import editor
url = 'https://raw.github.com/gist/mygist.py
contents = urllib.urlopen(url).read()
editor.make_new_file('AirHockey', contents)


Таким образом можно распространять приложения. Я бы, например, «поставил» бы парочку для управления той или иной открытой системой через ее api.
Так для себя четкой формулы не могу вывести что выгоднее — AWS (RackSpace, Softlayer, etc) или Private Cloud на своем железе (OpenStack, VmWare, etc)?

Пока что так рассуждаю:
— При малых операционных объемах и низкой требуемой мощности — AWS (позволяет уменьшать расходы на ресурсы до нуля)
— При средних операционных объемах и высокой требуемой мощности — Свое железо (позволяет максимально эффективно использовать вложенные средства, при известной траектории роста. Минимальная изменчивость инфраструктуры позволяет экономить на поддержке)
— При очень высоких операционных объемах и высокой требуемой мощности (также использование SAAS решений от Amazon) — опять AWS (позволяет контролировать расходы на обслуживание инфраструктуры а также позволяет быть максимально гибким в создании новых инфраструктур за минимальное время).

Кто как считает, было бы интересно послушать мнение Хабра?
UPD: Теперь по умолчанию это C:\ProgramData\chocolatey.
Также можно добавить что Ketarin замечательно подходит для создания пакетов с автоматическим обновлением версии.
Интересно, как они определили VPN трафик на шифрованном канале?
Видимо по Вы подключились по UDP.
Если я не ошибаюсь, шифрованный TCP ничем не отличался бы от https на 443 порту, или я все-таки ошибаюсь?
Посмотрите в сторону Kaffka + Cassandra, хорошо показывает себя (пример — gumgum.com).
Ради интереса, приведите пожалуйста параметры железа?
Так никто не отменял капание на мозг начальству и страшные секьюрити ревью об неугодном контенте, а также выдержки из анализа производительности других бюджетных предприятий закрывших развлекательные сайты…
Начальство прониклось — получаем приказ, всё закрыто все довольны…
Печаль…
Вы уже раза в два точно больше должны получать при таких амбиция и знаниях.
Не пробовались на удаленку устроиться куда-нибудь?
Разве «закрыть» что-то в нашем государстве не проще чем «открыть»?
Разве он частично не в списке «запрещенных» сайтов в России?
По какой-то причине я не использовал check_openmanage, ума не приложу почему… Пойду попробую еще разок)))
Ну это ясно, просто интересно мнение автора по поводу оригинальной nagios. Мы используем opsview, построена на базе nagios + web ui, шаблоны, серверные переменные, приятные rrd графики из коробки. Но автоматизацию выходит делать только через rest (конечно можно файлы nagios менять, но это не гарантирует что что-то не сломается), и нет «паков» как в zenoss. Хочу попробовать shinken, выглядит интересно. Никто не знает, как в Shinken обстоят дела с преконфигурированными сервис чеками для железа DELL чтобы не вводить десятки OID и их пороги вручную? Или может родное для nagios что-то хорошее есть?
Спасибо огромное за статью, было очень интересно прочитать. Мы тоже используем LS+ES+Kibana. Также обрабатываем логи наших приложений. Часто возникает «проблема неверных дат», когда одна из служб отсылает пару событий «из прошлого», на что LS+ES реагируют созданием нового индекса на этот день. Соответственно если это 100 событий с разными датами — 100 новых индексов. ES загибается, т.к. резервирует минимальные ресурсы под все индексы независимо от их размера.
Не подскажете, случались ли у Вас такие проблемы и как Вы с ними боролись и боролись ли на уровне LS+ES?

Второй вопрос, наверняка смотрели в сторону nagios, что можете сказать о сравнении о нем и связке ganglia+shinken?
Спасибо!
Амазон не совсем идеален в данной ситуации. Недавно на мой Paperwhite и Paperwhite жены пришло новое обновление, которое по каким-то причинам убило прошивку. Мой киндл был на гарантии, разобрался так же как описано в комментарии выше. А вот с киндлом жены пришлось повозиться, так-как он был уже не на гарантии. Сначала отказались вообще что-либо делать. После моего возмущения (жена вообще его не использовала в течение месяца, открыла а там тю-тю) — согласились поменять. Но прислали киндл с убитым экраном — четкость и качеству работы кристаллов электронных чернил оставалось желать лучшего. Ну а в целом да, амазон великолепен. Чего стоит только Amazon Fresh — как-то заказали продукты, а среди всех продуктов нам не пришел один лимон (да-да, один лимон). Так вот, после жалоб в службу поддержки мне вернули $0.40 и положили $35 на счет за неудобства… Класс!
:) Последняя строка впечатлила, и я, пожалуй, соглашусь. Именно поэтому я люблю IntelliJ Idea и PyCharm :)

Информация

В рейтинге
Не участвует
Откуда
New York, New York, США
Дата рождения
Зарегистрирован
Активность