а юзать куки или свой заголовок - какая разница если данные будут в заголовках при любом раскладе

к слову по поводу того же CSRF - видел где-то реализацию без сессий

как раз на JWT

Что за Uncle Bob ?

из jvm чатика

если ты пишешь сайтик - тебе дорога в сессии и куки. Если ты пишешь апишку - stateless JWT

сказал как отрезал ;)

из jvm чатика

ну блин, бывают жуниоры. Забыл?)

Оптимизации zval, immutable массивы и профилирование blackfire. Transient паттерн, когда хочется и immutable объектов и память сэкономить. Конференция PHP Australia. RIPS. http://podcast.ostretsov.ru/2016/12/30/php-podcast-14/

В прошлой конторе у нас тоже был биллинг на пхп. И работал даже, и pci-dss даже успешно проходил. Мне кажется фразы типа "биллинг на пхп" вызывают недоумение у людей которые большую часть времени проработали настройщиками вордпресов. Пхп это ж язык всего-лишь. А вот кто на этом языке будет писать и что он напишет - это уже другой вопрос. Настройщик вордпресов биллинг на пхп врядли напишет. А вот более опытный девелопер пописавший на разных языках и умеющий в "архитектуру" вполне себе сможет :)

bc math есть - можно делать билинг

ну или инты)

в php плохо с интами(

uint64 === string

(

хотя в js не лучше)

там тоже нельзя делать unsigned int

(

я тут балуюсь потиху с PHP-pm и phpfastcgi

прикольные штуки

bc math есть - можно делать билинг

эт если тебе микро трейдинг какой-то нужен

эт если тебе микро трейдинг какой-то нужен

почему же?

хотя мне нужен)

потому что в основном хватает банкинг раунда до 2х чисел после запятой

потому что в основном хватает банкинг раунда до 2х чисел после запятой

Не хватает

пример кейса?

Ты же в базе хранишь обычно, и если у тубя есть любая операция сложения, деления, и т.д. Будут потери

потому что в основном хватает банкинг раунда до 2х чисел после запятой

ну тогда надо своя функция банковского округления

Так что, ИМХО, хранить только в int

Ты же в базе хранишь обычно, и если у тубя есть любая операция сложения, деления, и т.д. Будут потери

есть такая практика - округлять всегда только в сторону ближайшего четного. Это позволяет минимизировать риски потерь

конкретный кейс..

ну тогда надо своя функция банковского округления

PHP_ROUND_HALF_EVEN

воу

есть такая практика - округлять всегда только в сторону ближайшего четного. Это позволяет минимизировать риски потерь

Можно уменьшить потери, это и призвано сделать банковское округление, но это не спасает от потерь

не знал что пых это умеет

конкретный кейс..

Да хоть бы узнать суммы всех депозитов

при сумме у тебя проблем не будет

Да хоть бы узнать суммы всех депозитов

ну все будет ок же, четные числа и все такое. Нет ошибки округления

0.01+0.02 - что тут может пойти не так?

0.1 + 0.2 )))))

ну все будет ок же, четные числа и все такое. Нет ошибки округления

Я тоже так думал

Увы на практике ловил проблемы даже с простым сложением

0.1 + 0.2 )))))

0.30000000000000004

Допускаю что это был просто баг, было довольно давно

0.30000000000000004

да, я про это же)

ну, короче, либо инты

либо bc_math

ну собственно да, так проще

ну в целом да, лучше в центах хранить сразу

у меня кванты)

хипстота с блокчейнами

Ну в центах не катит

хипстота с блокчейнами

о вчера на разборе полетов они блокчейны обсасывали

там чувак на rust хуярит их

ну можно выяснить у бизнес-пипл сколькими знаками они оперируют

Нужно хранить int + decision

Нужно хранить int + decision

так и храним

так и храним

И мы тоже =)

и это то о чем говорит @mkusher

у меня такое ощущение, что мне надо пойти позавтракать(

что я делаю не так? http://img.netpeak.ua/denya/2016-12-30_20c5f0.png

все нормально же

?

через number_format можешь вывести

ERROR: S client not available

Чо за хуйня?))

это числа с плавающей точкой, тут php не особо виноват)

IEE 774

так в большинстве языков

0.1 + 0.2 = 0.30000000000000004

https://gist.github.com/mkusher/09b53dcd833b8f90eca09d65781dc686

и никакого обсуждения?(

скоро праздник

все уже думают о другом

чего бы бухнуть

у нас все холодильники на кухнем бухлом забиты и пол отдела играет в кс

я тоже кс играю

заебца)

https://www.youtube.com/watch?v=Cpv6MD2ofyU

скоро праздник

тип как зарелизиться?

Камрады, подскажите как правильно написать тест на примерно такой метод: public someMethod() { $user = $this->userRepository->findOneBy(...); if ($user) { // update user .... } else { //create new user $this->entityManager->persist($user); } } Т.е. как правильно замокать репозиторий юзеров и ентитименеджер, а то я немного в растерянности) Если есть примеры на гитхабе, вообще шикарно будет)

Я же правильно понимаю что юнит тесты в базу не лазят(не должны)?

кто мешает мокнуть findOneBy?

Я же правильно понимаю что юнит тесты в базу не лазят(не должны)?

фикстуры для этого

В принципе никто) Я наверное вопрос не совсем корректно сформулировал)

ой-ой

а почему entityManager->persist?

userRepository->add($user)

и тогда надо работать только с интерфейсом UserRepository

Тут нужно написать фикстуры и шариться по них?)

да и findOneBy я бы заменил на что-то более точное, типа findSomethingSpecial()

userRepository->add($user)

Спасибо) Сейчас подправлю)

да и findOneBy я бы заменил на что-то более точное, типа findSomethingSpecial()

до кучи я бы порекомендовал юзать партиаллоад :) и тянуть только то, что реально нужно

это уже деталь реализации этого самого findSomethingSpecial

итого, user repository мокается и проверяется, что 1. юзер правильно апдейтится 2. юзер правильно создается

если он структура данных

если он нормальная сущность, то надо проверять соблюдение интерфейса работы с ним