Это скорее похоже на кратковременный найм — то есть клуб нанимает исполнителя. Этакий трудовой договор. Притом все головняки с налогами и т.п. оказываются на нанимателе. Что-то аналогичное есть в виде гонораров за лекции, вознаграждений за авторство и т.п. Общее в этом что исполнитель не заморачивается фондами, отчислениями и т.п.
вести бизнес не для заработка а как побочное занятие или просто «для души»
Вот как-то взрывает это мозг. Думаю не я один воспринимаю «бизнес» как деятельность, направленную на систематическое получение прибыли.
Все-таки стоит наверное для иного применять нечто типа «народные промыслы» и т.п.
Притом всегда на этой границе между хобби и бизнесом моного мутного: вот кто-то коллекционирует марки, монеты, модельки и т.п… естественно это скорее затратнное хобби. Правда иногда часть коллекции продается и вроде как и не бизнес… Но в то же время есть некие личности, которые зарабатывают регулярно перепродавая, скупая те же марки/монеты/etc. У них это бизнеснезаконное предпринимательство. А вот отделить одних от других — крайне сложно.
То что касается самозанятых — по-моему максимально оптимальная конструкция для нерегулярного заработка «на конфеты»: исключая только абонплату банков — в остальном «прилетела копейка — снялся мизерный налог».
С ИП — ну опять же — это предпринимательство на свой страх и риск и изначально подразумевает систематическое извлечение прибыли. Все остальные варианты «поиграть в предпринимателя» — ну только от неверной оценки реальности.
Ну «крупняки» берут страховку на себя и поэтому некоторые даже с карт списывают без второй петли секьюрности и т.п. Аналогично *pay — выстраивают с банком доверенные отношения и платят «от себя», списывая с карты ни в чем себе не отказывая.
Правда возможно они используют какие-то интеллектуальные предположения и иногда вдруг могут попросить еще раз приложить палец или ввести пароль. Но очень редко.
Вот и так у большинства систем. Или DOS'ь запросами или никак (
Туда же, в todo было бы неплохо добавить еще вот такое:
что-то внешнее подписывается/прописывается на событие-запрос и ответ учитывается в дальнейшей логике. Тупой пример внешний сервис получает событие идентификации карты и отвечает что «да, для этой карты открыть дверь Х невзирая на остальное», в следующий раз он может ответь иное.
Прям из обязательств «увеличить число партийных в составе руководства к очередному съезду»)
Правда там был чит в виде смены партийности из off в on руководителя…
Спасибо. Посмотрел бегло. То ли пропустил то ли нету подписки/callback на события.
То есть поймать событие прохода/идентификации можно только непрерывно опрашивая систему?
А как-то можно в пару кликов увидеть описание api?
То есть вот для утилитарной, но относительно нетиповой задачи оценить возможности api в интересующем ключе. Конкретно например получать (подписываться) на события к примеру считывания карты и успевать (с оговорками) вмешаться в процесс принятия решения о пропуске/запрете прохода?
Сталкивался еще больше года назад в одном магазине: сумма была чуть больше 15000р. и пин не потребовался… Спросил у продавца — тот подтвердил что не один я удивляюсь… Эквайринг был бинбанка. В остальных местах блюлось такое «до 1000».
Насколько я слышал краем уха — вроде как лимиты рулятся как эквайрингом так и банком-эмитентом карты. В том числе существует абстрактная возможность задать таковые для своей карты индивиндуально.
Как мне кажется это не сильно далеко ушло от «зарядки мобильника в микроволновке».
И как смотреть на еще более вырожденную картину, когда уровень iq у Уаси настолько зашкаливает что он следует совету из чата «format c:»/«rm rf /» (кстати в первом можно его слегка обезопасить используя русские буквы о, с, а)?
уже можно говорить о 3000 для visa и с совсем недавнего времени 5000 для mastercard (в новостях мелькало о уже переключивших лимит штуках 5 банках в мае)
А у меня был 61 (это было нечто по сравнению с 21), но я долго страдал из-за отсутствия хранения как такового… а когда приобрел 52 — уже запал иссяк… Правда немного поразгонял его… несколько лет назад выкинул (
Это если хэшируют, не сложив предварительно plain в нечто отдельное СОРМо-подобное, где одни и те же механизмы этакого антимата случайно чекают не только логин/ник, но и пароль.
Все-таки стоит наверное для иного применять нечто типа «народные промыслы» и т.п.
Притом всегда на этой границе между хобби и бизнесом моного мутного: вот кто-то коллекционирует марки, монеты, модельки и т.п… естественно это скорее затратнное хобби. Правда иногда часть коллекции продается и вроде как и не бизнес… Но в то же время есть некие личности, которые зарабатывают регулярно перепродавая, скупая те же марки/монеты/etc. У них это
бизнеснезаконное предпринимательство. А вот отделить одних от других — крайне сложно.То что касается самозанятых — по-моему максимально оптимальная конструкция для нерегулярного заработка «на конфеты»: исключая только абонплату банков — в остальном «прилетела копейка — снялся мизерный налог».
С ИП — ну опять же — это предпринимательство на свой страх и риск и изначально подразумевает систематическое извлечение прибыли. Все остальные варианты «поиграть в предпринимателя» — ну только от неверной оценки реальности.
Правда возможно они используют какие-то интеллектуальные предположения и иногда вдруг могут попросить еще раз приложить палец или ввести пароль. Но очень редко.
Туда же, в todo было бы неплохо добавить еще вот такое:
что-то внешнее подписывается/прописывается на событие-запрос и ответ учитывается в дальнейшей логике. Тупой пример внешний сервис получает событие идентификации карты и отвечает что «да, для этой карты открыть дверь Х невзирая на остальное», в следующий раз он может ответь иное.
p.s. Иногда встречаю бумажные документы где в конце призыв к сохранению бумаги на двух листах…
Правда там был чит в виде смены партийности из off в on руководителя…
То есть поймать событие прохода/идентификации можно только непрерывно опрашивая систему?
А СОТ — Система Охранного Телефидения (в просторечии — «видеонаблюдение»)
При исполнении документации — как минимум оглядываются на ГОСТ Р 51241- 2008, ГОСТ Р 54831-2011 и т.п.
То есть вот для утилитарной, но относительно нетиповой задачи оценить возможности api в интересующем ключе. Конкретно например получать (подписываться) на события к примеру считывания карты и успевать (с оговорками) вмешаться в процесс принятия решения о пропуске/запрете прохода?
Насколько я слышал краем уха — вроде как лимиты рулятся как эквайрингом так и банком-эмитентом карты. В том числе существует абстрактная возможность задать таковые для своей карты индивиндуально.
И как смотреть на еще более вырожденную картину, когда уровень iq у Уаси настолько зашкаливает что он следует совету из чата «format c:»/«rm rf /» (кстати в первом можно его слегка обезопасить используя русские буквы о, с, а)?