Прям классика из серии "Кратко о том, почему не стоит работать в ...".
К парням, которые пытались в силу знаний и умений, но хоть как-то решить текучку — вопросов нет: работает и ладно.
А вот чем занимались тим лид и пм по внутренним разработкам? Если их не было, то почему? В крупнейшем интеграторе не хватает специалистов по катанию серверов на оленях? А если были, то почему поделка на уровне фриланса за 3$/час?
Планирует ли автор выложить полный исходный код приложения на гитхаб? Будут ли рассматриваться пулл-рекввесты сообщества? Готовы ли юнит-тесты для полноценной интеграции?
Нужные десктопные уведомления, где интерефейс доступа? Или это бэкенд? А какие базы данных поддерживаются? Очень нужна %database_name%!!1
Как и обещал — всё очень просто.
Рассматривает ли автор возможность миграции на более производительную платформу разработки?
Есть готовые наработки для bash :-P
Это, мягко говоря, не правда: master процесс в nginx при старте форкает воркеров, которые в асинхронном режиме обрабатывают соединения (по одному воркеру на поток ядра проца).
В вашем же случае, мастер процесс будет обрабатывать соединения, и только потом форкать процессы.
При определенной нагрузке, ядро проца, на котором работает мастер процесс приложения, встанет колом по CPU из-за затраченного времени на переключения контекстов в ядре ос.
Stateless система под это дело совсем не подходит, поскольку нельзя делать откат ревизий, и, как следствие, нормальное A/B проходит мимо.
Кроме того, у них в гайдлайне написано, дескать: не делайте параметризированных ролей, лучше копипаста.
И получается, что сделать обычную роль для nginx с темплейтами и инклудами конфигов, которая в рамках одного inventory намазывается по разным серверам, — это целая, блин, задача с юнит-тестам, бл.
Создание/удаление контейнеров/виртуальных машин;
Создал, запустил, упал, перезапустил, упал. И так в цикле, пока apdex не просядит и мониторинг не начнёт орать, да? :-}
А стэктрейсы после запуска толстого плэйбука хотя бы на 50+ хостов смотреть? >____<
К примеру, когда в template неправильно указан аргумент src, а изменений много, и вносил их кто-то другой:
output -vvvv
An exception occurred during task execution. The full traceback is:
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/ansible/executor/task_executor.py", line 124, in run
res = self._execute()
File "/usr/lib/python2.7/dist-packages/ansible/executor/task_executor.py", line 446, in _execute
result = self._handler.run(task_vars=variables)
File "/usr/lib/python2.7/dist-packages/ansible/plugins/action/template.py", line 80, in run
source = self._loader.path_dwim_relative(self._task._role._role_path, 'templates', source)
File "/usr/lib/python2.7/dist-packages/ansible/parsing/dataloader.py", line 236, in path_dwim_relative
if source.startswith('~') or source.startswith('/'):
AttributeError: 'NoneType' object has no attribute 'startswith'
fatal: [localhost]: FAILED! => {"failed": true, "msg": "Unexpected failure during module execution.", "stdout": ""}
У «Почты России», надо заметить, очень интересные технические вакансии висят: много linux и foss. Если требования к реализации и эксплуатации софта достаточно высокие, то там прям есть над чем поработать. Жалко, что находятся в пригороде, да и денег там не особо :|
Если увлекаешься метеорологией, то обрати внимание на Норвежский Метеорологический Институт: http://www.met.no/English
У них отличная собственная система прогнозирования, которая используется, например, в мобильным приложением yr.no ( https://play.google.com/store/apps/details?id=no.nrk.yr ).
Вот и всё. Вы можете тестировать работающее приложение.
Тема апдейтов в pubspec.yaml и работа dart pub не раскрыта, ибо отсутствуют:
— хладные басни про настройку PUB_HOSTED_URL, когда основная репа дарта, висящая на одном (!) заокеанском сервере, упала;
— хладные басни про pub get vs pub upgrade при работе с git, когда непонятно с какой версией собирается и почему нужная версия не выкачивается;
— хладные басни про PUB_CACHE, когда pub upgrade говорит: «ок», но ничего не выкачивает вообще.
Те, кто осилил спеку [1] — всё знают, ибо растут эти понятия из пирамиды Cloud Computing: IaaS <=> PaaS <=> SaaS, где админы «продают» инфраструктуру девопсам, которые в свою очередь «продают» программистам среды и инструменты для разработки и исполнения приложений.
Драма заключается в том, что чем больше и сложнее сервис, тем более явно прослеживаются различия специализаций. Соответственно, чем меньше сервис, тем менее очевидны границы разделения обязанностей. Поэтому нет ничего удивительного в том, что в каких-то компаниях граница м/у админами и девопсам уж слишком размыта, а то и вообще отсутствует.
Под большими и маленькими сервисами не подразумевается количество кода или его сложность. Основной кейс тут один — распределенные вычисления. К слову, ведь именно из-за сложности в обслуживании распределенных софтовых сервисов, состоящих из кучи и тучи микросервисов, гугл и ввёл термин SRE, но многие почему-то неправильно трактуют понятие Site, или вообще его не трактуют.
[1] «The NIST Definition of Cloud Computing», http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf
Немного нелепо выглядит сей релиз сугубо внутренней наработки на фоне вливания evernote в pootle, ибо функционал вашего Серёжи практически идентичен translate-toolkit.
Плюсы использования промежуточной базы на обычном SQL для конвертации форматов — весьма сомнительны на первый взгляд: откат состояний там не предусмотрен, снапшотов нет, то есть никакой защиты от факапов: роллбэк не сделать при плохом вливании, ибо проще сразу базу переналивать. Я так понимаю, что ровно плыть вам помогает именно тот факт, что внутри компании есть «домашние» переводчики и менеджеры локализаций? Опять же, работа с памятью переводов реализована через обычный скрипт, а реалтаймовые матчинги для переводчиков делает вполне себе эластик же, да?
Получается, что в сухом остатке у вас, вероятно, имееются неплохие парсеры, ибо perl традиционно хорошо работает со строками… ну и всё.
Из всего этого вытекает вполне себе резонный вопрос: если perl лошадка сдохла, то надо ли с неё слезать? :3 Ну а если без сарказма, то планирует ли компания работать над расширением функционала pootle и соответствующих утилит, или вы таки только с Сережёй дружить будете? :-}
Разница в том, что с dpkg вы используете бинарные пакеты, собранные один раз в правильном окружении, а pip install вызывает gcc и билдит модули при каждом деплое.
Кейсов тут несколько:
1. Если вы захардкорили версии зависимостей во избежании dependencies hell, то никто вам не гарантирует, что данный конкретный пакет будет доступен всегда. В один их тех самых доджливых вечеров в четверг, pip вам скажет, что нужного пакета нет.
2. Вы уверены, что все -devel файлы, которые используюся при компиляции — идентичны? И что unexpected behaviour на callback внешней функции в продакте не настигнет вас через 2 месяца после того самого дождливого четверга, а вы как на зло с семьей посредине средиземного моря на лайнере?
3. Компилятора на сервере быть не должно.
Да, поддерживать все это в приличном состоянии можно, стóит это неимоверных усилий, но моментально рассыпается под шаловливыми руками отдельно взятых личностей. Такие дела, и всё это уже сто раз проходили в связке perl + cpan.
Я постараюсь описать идеальные варианты настройки тестового веб-севера, хотя понимаю, какой бардак на них обычно творится.
Тестовый стенд не должен быть идеальным, он должен архитектурно соответствовать продакту. А маленький срачЪ в qa env — всегда соответствует большой «помойке» на проде.
Да и вообще, вы всю дорогу тёплое и мягкое путаете.
Если есть несколько независимых команд, то нужно поставть балансировщик, прописать upstream's, и для особо буйных команд сливать реквесты а) в контейнеры или б) на выделенные хосты, а уже там должны сидеть ваши *cgi и ci-agent, да билдить и управлять всей хурмой из vcs's.
И отдельным пунктом хотелось бы отметить, что virtualenv дальше компа разработчика уходить не должен. Надо стороннюю библиотеку на сервере — соберите пакет и используйте локальную репу для деплоя, а с setuptools, pip и gcc обращаться надо осторожно, а лучше вообще не дружить.
Очень нестабильно работает git-plugin, багтрекер постоянно заваливается идентичными тикетами, дескать git scm polling не в себе — и вроде фиксят, а вроде и опять не работает.
В терминах-то не путайтесь? Одно дело — сертификация, другое — лицензирование.
Google просят денег за использование торговой марки и проприетарных решений — сертифицировать тут нечего :-}
Раньше была Android, но уже пару лет как условия сертификации Android и GMS значительно ужесточились, и на равных с Google сейчас могут разговаривать разве что AT&T и Verizon.
Если абстрагироваться от того, что Ubuntu Touch — это ядро Android, вкоряченое в lxc контейнер, свой маленький mir, да два десятка убогих приложений, то остаётся один вопрос — а кому нужен смартфон, на которым нет не только ни одного востребованного приложения, но и никакой альтернативы?
Ставил pre-release на Nexus 4 дважды — получил кирпич 3310 с HD дисплеем :3
Да, «кирпич» работал в 3 раза дольше, но исключитель по той причине, что там нет ни одного синхронизирующегося приложения (с заменой Dalvik на ART данная особенность в значительной степени нивелировалась). Парни сто лет обещают запилить контейнеры под запуск нативных приложений из google play, правда дальше срачей в рассылке дело, видимо, не пошло. И даже если через 2-3 года унификация мобильных и десктопных приложений выстрелит, то товарищи из Cannonical к тому времени заработают себе «отличную» репутацию по выпуску топорного неюзабельного вторичного шлака, ибо ответа на главный вопрос «а кто будет писать приложения?», — до сих пор не последовало. Сами же шаттлвортовцы из года в год не только ничего толкового написать не могу, но уверенно корябают и чужие наработки.
Прям классика из серии "Кратко о том, почему не стоит работать в ...".
К парням, которые пытались в силу знаний и умений, но хоть как-то решить текучку — вопросов нет: работает и ладно.
А вот чем занимались тим лид и пм по внутренним разработкам? Если их не было, то почему? В крупнейшем интеграторе не хватает специалистов по катанию серверов на оленях? А если были, то почему поделка на уровне фриланса за 3$/час?
Планирует ли автор выложить полный исходный код приложения на гитхаб? Будут ли рассматриваться пулл-рекввесты сообщества? Готовы ли юнит-тесты для полноценной интеграции?
Нужные десктопные уведомления, где интерефейс доступа? Или это бэкенд? А какие базы данных поддерживаются? Очень нужна %database_name%!!1
Рассматривает ли автор возможность миграции на более производительную платформу разработки?
Есть готовые наработки для bash :-P
В вашем же случае, мастер процесс будет обрабатывать соединения, и только потом форкать процессы.
При определенной нагрузке, ядро проца, на котором работает мастер процесс приложения, встанет колом по CPU из-за затраченного времени на переключения контекстов в ядре ос.
Стабильнее и быстрее? Ну-ну.
Kernel /= OS
Stateless система под это дело совсем не подходит, поскольку нельзя делать откат ревизий, и, как следствие, нормальное A/B проходит мимо.
Кроме того, у них в гайдлайне написано, дескать: не делайте параметризированных ролей, лучше копипаста.
И получается, что сделать обычную роль для nginx с темплейтами и инклудами конфигов, которая в рамках одного inventory намазывается по разным серверам, — это целая, блин, задача с юнит-тестам, бл.
Создал, запустил, упал, перезапустил, упал. И так в цикле, пока apdex не просядит и мониторинг не начнёт орать, да? :-}
А стэктрейсы после запуска толстого плэйбука хотя бы на 50+ хостов смотреть? >____<
К примеру, когда в template неправильно указан аргумент src, а изменений много, и вносил их кто-то другой:
У них отличная собственная система прогнозирования, которая используется, например, в мобильным приложением yr.no ( https://play.google.com/store/apps/details?id=no.nrk.yr ).
Тема апдейтов в pubspec.yaml и работа dart pub не раскрыта, ибо отсутствуют:
— хладные басни про настройку PUB_HOSTED_URL, когда основная репа дарта, висящая на одном (!) заокеанском сервере, упала;
— хладные басни про pub get vs pub upgrade при работе с git, когда непонятно с какой версией собирается и почему нужная версия не выкачивается;
— хладные басни про PUB_CACHE, когда pub upgrade говорит: «ок», но ничего не выкачивает вообще.
Драма заключается в том, что чем больше и сложнее сервис, тем более явно прослеживаются различия специализаций. Соответственно, чем меньше сервис, тем менее очевидны границы разделения обязанностей. Поэтому нет ничего удивительного в том, что в каких-то компаниях граница м/у админами и девопсам уж слишком размыта, а то и вообще отсутствует.
Под большими и маленькими сервисами не подразумевается количество кода или его сложность. Основной кейс тут один — распределенные вычисления. К слову, ведь именно из-за сложности в обслуживании распределенных софтовых сервисов, состоящих из кучи и тучи микросервисов, гугл и ввёл термин SRE, но многие почему-то неправильно трактуют понятие Site, или вообще его не трактуют.
[1] «The NIST Definition of Cloud Computing», http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf
Плюсы использования промежуточной базы на обычном SQL для конвертации форматов — весьма сомнительны на первый взгляд: откат состояний там не предусмотрен, снапшотов нет, то есть никакой защиты от факапов: роллбэк не сделать при плохом вливании, ибо проще сразу базу переналивать. Я так понимаю, что ровно плыть вам помогает именно тот факт, что внутри компании есть «домашние» переводчики и менеджеры локализаций? Опять же, работа с памятью переводов реализована через обычный скрипт, а реалтаймовые матчинги для переводчиков делает вполне себе эластик же, да?
Получается, что в сухом остатке у вас, вероятно, имееются неплохие парсеры, ибо perl традиционно хорошо работает со строками… ну и всё.
Из всего этого вытекает вполне себе резонный вопрос: если perl лошадка сдохла, то надо ли с неё слезать? :3 Ну а если без сарказма, то планирует ли компания работать над расширением функционала pootle и соответствующих утилит, или вы таки только с Сережёй дружить будете? :-}
Кейсов тут несколько:
1. Если вы захардкорили версии зависимостей во избежании dependencies hell, то никто вам не гарантирует, что данный конкретный пакет будет доступен всегда. В один их тех самых доджливых вечеров в четверг, pip вам скажет, что нужного пакета нет.
2. Вы уверены, что все -devel файлы, которые используюся при компиляции — идентичны? И что unexpected behaviour на callback внешней функции в продакте не настигнет вас через 2 месяца после того самого дождливого четверга, а вы как на зло с семьей посредине средиземного моря на лайнере?
3. Компилятора на сервере быть не должно.
Да, поддерживать все это в приличном состоянии можно, стóит это неимоверных усилий, но моментально рассыпается под шаловливыми руками отдельно взятых личностей. Такие дела, и всё это уже сто раз проходили в связке perl + cpan.
Тестовый стенд не должен быть идеальным, он должен архитектурно соответствовать продакту. А маленький срачЪ в qa env — всегда соответствует большой «помойке» на проде.
Да и вообще, вы всю дорогу тёплое и мягкое путаете.
Если есть несколько независимых команд, то нужно поставть балансировщик, прописать upstream's, и для особо буйных команд сливать реквесты а) в контейнеры или б) на выделенные хосты, а уже там должны сидеть ваши *cgi и ci-agent, да билдить и управлять всей хурмой из vcs's.
И отдельным пунктом хотелось бы отметить, что virtualenv дальше компа разработчика уходить не должен. Надо стороннюю библиотеку на сервере — соберите пакет и используйте локальную репу для деплоя, а с setuptools, pip и gcc обращаться надо осторожно, а лучше вообще не дружить.
Очень нестабильно работает git-plugin, багтрекер постоянно заваливается идентичными тикетами, дескать git scm polling не в себе — и вроде фиксят, а вроде и опять не работает.
Google просят денег за использование торговой марки и проприетарных решений — сертифицировать тут нечего :-}
«Based on the cross-platform Qt framework, QML features an extensive set of APIs that cover the needs of the most demanding developers.» ©
developer.ubuntu.com/en/apps/qml/
Условия сертификации чего и кем? И что такое GMS?
Ставил pre-release на Nexus 4 дважды — получил кирпич 3310 с HD дисплеем :3
Да, «кирпич» работал в 3 раза дольше, но исключитель по той причине, что там нет ни одного синхронизирующегося приложения (с заменой Dalvik на ART данная особенность в значительной степени нивелировалась). Парни сто лет обещают запилить контейнеры под запуск нативных приложений из google play, правда дальше срачей в рассылке дело, видимо, не пошло. И даже если через 2-3 года унификация мобильных и десктопных приложений выстрелит, то товарищи из Cannonical к тому времени заработают себе «отличную» репутацию по выпуску топорного неюзабельного вторичного шлака, ибо ответа на главный вопрос «а кто будет писать приложения?», — до сих пор не последовало. Сами же шаттлвортовцы из года в год не только ничего толкового написать не могу, но уверенно корябают и чужие наработки.