Pull to refresh
0
0
Send message

Плюсую. У меня был архивный тариф, с лимитированным трафиком. 25гб вроде, точно не помню. Недавно подняли мне абонентскую плату. А затем, когда попытался раздать интернет на ноут, чтобы поработать вне дома, мне пришло уведомление, что так делать больше нельзя. Плюнул на них, перенес номер к другому оператору.

Например, поднять низкие рейтинги накануне голосования. Рейтинг власти среди айтишного сообщества очень так себе.
Фиксированные взносы растут из года в год больше уровня инфляции. Также, не забудьте добавить 1% в ПФР от дохода, превышающего 300т.р. в год.

То есть, ИПшник должен наращивать доход, для того чтобы налоговый вычет покрывал взносы.
Главное, чтобы результатом обработки не оказалось что-то вроде «42»
В моем сервисе это реализовано как-то так:

Сущность Account имеет поле period
Баланс юзера счетается примерно так (пример абстрактный, не используйте в продакшн):
SELECT SUM(amount) as balance FROM Transaction WHERE account_id = account.id AND period <= account.period

Организовать блокировку можно средствами самой СУБД:
SELECT * FROM Account WHERE period < "current period" FOR UPDATE SKIP LOCKED LIMIT 10

Таким образом, условный мускул пикнет вам 10 аккаунтов и залочит их, так что параллельные транзакции не смогут получить доступ к этим записям. И перенос балансов можно повесить на крон, либо придумать что-то более эффективное, исходя из вашей конкретной ситауции. Почитайте про такие фичи как FOR UPDATE, SKIP LOCKED, NOWAIT
Хэш — вряд ли, но по идее можно хранить зашифрованный пароль пользователя в БД, и использовать ключ для дешифровки каким-то симметричным/асимметричным алгоритмом. Но тогда встает вопрос о возможности компрометации ключа. Не силен в криптографии, но как-то раз приходилось работать с PGP

Information

Rating
Does not participate
Registered
Activity