Нет. Валюта есть в экономе. И патент тоже есть.
Но есть жирный минус, патент реализован очень коряво. Нельзя например за него платежку в эльбе сформировать.
И еще Эльба убрала облачную подпись, а подпись через мобильное приложение еще не сделали, если так и останется придется искать замену.
Эльба работает с валютными счетами. Контрактами и инвойсы это уже ваша задача. На самом деле у эльбы, конечно есть раздел документы, но я не вижу от него пользы в случае работы с одним-двумя заказчиками.
В регионах где патент стоит дороже 18 т.р. будет и этот процент из-за того что сумма по патенту будет больше 300 т.р.
В таких случаях может иметь смысл работа на УСН несколько первых месяцев пока не набежит УСН на сумму годовых взносов которые полностью вычитаем из УСН и потом берем патент на оставшуюся часть года.
Страшен не ВК, там страшны санкции даже за самые мелкие нарушения. Типа найдут косяк в документах и насчитают штраф 75-100% за платеж трехлетней давности. Остается только все делать максимально четко уповать что пронесет.
С 2019 года (вроде с марта) ВК чуть упростили и теперь для экспорта, а удаленщик экспортирует услуги
до 200 т.р. Документы предоставлять не нужно
от 200 т.р. до 6 млн. достаточно инвойса, акта и т.п.
от 6 млн нужно регистрировать контракт
При этом если платежи идут от одного источника. Скорее всего понадобиться регистрация контракта когда сумма входящих по итогу достигнет 6 млн.
Не рубят в Китае шифрованый трафик. Может в каких-то регионах типа Тибета и Уйгурии. Но в крупных городах (Пекин, Шанхай, Гуанчжоу) работает. Заблокированы крупные VPN провайдеры,TOR, но личный VPN или от малоизвестного прова работает. Гораздо большая проблема плохой канал заграницу.
Вы, как я вижу, сильно пострадали от баша. Я тоже на самом деле :)
Я однозначно согласен с вами про то что построение инфраструктуры на shell это дорога
в ад. Например в случае с init скриптами этим адом оказался systemd (шутка)
Но все же вы утрируете, 10 строк если не использовать монструозные конвееры это так себе скрипт. В него даже толком не запихать необходимых проверок.
Для себя я вполне допускаю использовать баш в следующих случаях
Вы со своей колокольни судите. Вы на такую позицию не пойдете, я на такую позицию не пойду. Но на самом деле найти человека на shell скриптинг проще чем готового ansible/chef/puppet специалиста. И стоить он будет дешевле.
Изначально мой тезис был про то что CTO не увольняет конкретного исполнителя за говнокод на баше. Увольнять тут скорее нужно лида, архитектора, продакт оунера или кто там у них. В моей практике было полно случаев когда я говорил что так делать нельзя, это нарушение процесса, сейчас может ничего страшного не случится, но мы огребем в конце концов. Но мидл-менеджмент наваливался кучкой и приходилось делать.
Спасибо за развернутый ответ. Не очень, конечно, хорошо то что все стартанет в конце. Попробую при случае. Хэндлеры использовал внутри хост группы, а получается что и глобально можно.
А по хорошему, конечно, порядок старта это зло, нужно максимально избегать на этапе проектирования.
Совместимости читай зависимости. Если компонент А требует версию компонента Б, то не давать ставить А. Но это уже детали.
Мне уже стало интересно как у вас все реализовано :)
Вот смотрите есть у нас DB, backend, frontend. И они зависят друг от друга по нисходящей. Миграция DB ведет к рестарту backend, а затем frontend. Апдейт версии backend влечет рестарт frontend. Получаем у нас есть три возможных артифакта и 7 вариантов деплоя.
И как реализовать деплой не плодя плэйбук на каждый случай? Я представляю что это можно решить через группы. И/или расписать все шаги и на каждом шаге проверять условия. Но мне кажется, что поддержка такого будет не слаще чем скриптов. Помним что пример абстрактный, и компонентов у нас на самом деле несколько десятков.
Текущая инфраструктура бывает разной. Когда для того чтобы задеплоить компонент нужно несколько других остановить, причем на разных хостах. Потом поднять это дело в нужной последовательности и с проверками. А еще неплохо как-нибудь совместимость версий компонентов отследить… Тут приходит боль :)
Мне понравилось такое на XL deploy делать, но он сильно платный.
Сильно зависит от workflow. Когда нужно готовить хост с нуля они подходят очень хорошо. Но если надо менять кирпичик в уже построеном доме, то все становится очень печально… Т.е. сделать можно, но никакой эстетики.
Не везде.
Устройство при регистрации в сети сообщает что оно может это раз. Т.е. можно сразу обрубать девайсы которые умеют данные, но не умеют голос.
Устройство сообщает IMEI это два.
Возможно конкретно пользователь KbRadar к тому проекту отношения не имеет, но на сайте который который есть в ватермарке на видео или еще его можно нагуглить по словам «global energy transmission» есть кроме беспроводного питания квадрокоптеров раздел «GET Power Tower» А по ссылке Team найдем тех же самых персонажей которые собирали деньги.
Но есть жирный минус, патент реализован очень коряво. Нельзя например за него платежку в эльбе сформировать.
И еще Эльба убрала облачную подпись, а подпись через мобильное приложение еще не сделали, если так и останется придется искать замену.
В таких случаях может иметь смысл работа на УСН несколько первых месяцев пока не набежит УСН на сумму годовых взносов которые полностью вычитаем из УСН и потом берем патент на оставшуюся часть года.
до 200 т.р. Документы предоставлять не нужно
от 200 т.р. до 6 млн. достаточно инвойса, акта и т.п.
от 6 млн нужно регистрировать контракт
При этом если платежи идут от одного источника. Скорее всего понадобиться регистрация контракта когда сумма входящих по итогу достигнет 6 млн.
Все мы чего-то не знаем, но вы пишете про L7 фильтрацию, но не знаете базовых вещей про https…
Тут только установка своего сертификата на клиенты и прокся-перекодировщик вам помогут, типа казахский вариант.
Этот кривой mp3-tut.net просто делает редирект на http.
Я однозначно согласен с вами про то что построение инфраструктуры на shell это дорога
в ад. Например в случае с init скриптами этим адом оказался systemd (шутка)
Но все же вы утрируете, 10 строк если не использовать монструозные конвееры это так себе скрипт. В него даже толком не запихать необходимых проверок.
Для себя я вполне допускаю использовать баш в следующих случаях
— стартап скрипты
— простейшие развертывания (удалить, разархивировать, скопировать)
— крон-джобы
Помним что случае разные бывают, не всегда инфраструктура полностью подконтрольна, не везде есть python и пр.
Изначально мой тезис был про то что CTO не увольняет конкретного исполнителя за говнокод на баше. Увольнять тут скорее нужно лида, архитектора, продакт оунера или кто там у них. В моей практике было полно случаев когда я говорил что так делать нельзя, это нарушение процесса, сейчас может ничего страшного не случится, но мы огребем в конце концов. Но мидл-менеджмент наваливался кучкой и приходилось делать.
Во-вторых директора интересуют факты работает/не работает и в срок/не в срок. Остальное детали.
А по хорошему, конечно, порядок старта это зло, нужно максимально избегать на этапе проектирования.
Мне уже стало интересно как у вас все реализовано :)
Вот смотрите есть у нас DB, backend, frontend. И они зависят друг от друга по нисходящей. Миграция DB ведет к рестарту backend, а затем frontend. Апдейт версии backend влечет рестарт frontend. Получаем у нас есть три возможных артифакта и 7 вариантов деплоя.
И как реализовать деплой не плодя плэйбук на каждый случай? Я представляю что это можно решить через группы. И/или расписать все шаги и на каждом шаге проверять условия. Но мне кажется, что поддержка такого будет не слаще чем скриптов. Помним что пример абстрактный, и компонентов у нас на самом деле несколько десятков.
Мне понравилось такое на XL deploy делать, но он сильно платный.
Устройство при регистрации в сети сообщает что оно может это раз. Т.е. можно сразу обрубать девайсы которые умеют данные, но не умеют голос.
Устройство сообщает IMEI это два.