Pull to refresh
14
0
Владимир Храмцов @Chrome

Web-разработчик

Send message

В теории можно сделать всё проще, написав в репо метод с fetch join, в котором перечислить дополнительные нужные вам сущности и вы сможете получить сразу всё, что нужно, через один запрос и доктрина вам заботливо это разложит в удобном виде.

Что-то в последнее время часто встречаю хранение данных, относящихся к деньгам в float. Неужели уже вычисления с плавающей точкой стали настолько точными и 2,3 + 3,2 всегда будет равняться 5,5? Зачем сразу учить плохому?
Может я конечно слишком стар, но как по мне, так слон больше эмо, чем панк.
Ну если вы так настаиваете, то… ну я ещё раз подумаю :)
SamDark, я тут покопался на сайте конференции и не нашёл никакой программы. Можно ли как-то узнать, во сколько начнётся конференция и какое будет расписание? Если я не нашёл это то ссылки будет достаточно.

Спрашиваю я потому, что 13.05 у нас в стране рабочий день и у меня 100% будут активности по работе. Хотелось бы узнать кто в какое время будет выступать, потому как от этого зависит, есть ли смысл мне регистрироваться на конференцию.

Заранее спасибо за ответ.
Т.е. получается я фактически кладу в репозиторий все свои зависимости и таскаю это за собой. В чем принципиальная разница с тем, чтобы я сейчас залил в репу node_modules? Т.е. разворачивание у меня сводится просто к чекауту и всё. Возникает вопрос, зачем мне тогда .lock файл, если все зависимости я таскаю с собой в репозитории? Да и вообще тогда получается мне yarn нужен только чтобы залить зависимости в репозиторий. Я верно понимаю?
При добавлении пакета он (и все его зависимости), в виде zip архива добавляется в кеш, в папку .yarn в папке пакета (как .git)

И последствия
Можно добавлять этот кеш напрямую в гит — и тогда после чекаута у вас сразу будет актуальная версия приложения со всеми зависимостями.


Это кэш уровня проекта или пакета? Если пакета, то я получаю две копии одного и того же, одна установлена и в той же директории ещё и zip? В любом случае обычно не очень оптимально хранить иметь что-то, что можно потом установить с помощью пакетного менеджера. Это приведёт к тому, что репозиторий будет просто пухнуть, а при обновлерии пакетов в PR будут огромное количество файлов, которое по сути там не нужно.

Будет ли команда очистки кэша? Ну чтобы хоть каким-то образом поддерживать этот кэш в актуальном состоянии.
Хм, да ошибся. Обычно просто использую Debian и Ubuntu, там Opcode Cache расширение ставится автоматом.
Если говорить про Opcode Cache, то в 7.1 с такими проблемами не сталкивался, потом мы сразу на 7.3 прыгнули. Т.е. я бы не сказал что он сильно забагованный был. Ну и зачем отказываться от дополнительной производительности, которую можно получить за просто так. Ну и нюанс в том, что Opcode Cache расширение ставится прямо при установке пыха, его не надо отдельно доставлять, так что проблема достаточно критична. Его придётся скорее специально отключать.
Спасибо за дайджест!
По поводу php 7.4 сразу в прод я бы не торопился. Сейчас мы сидим на 7.3, сегодня обновились до 7.3.14. До обновления, если не сбрасывать опкэш три или четыре дня подряд, начинались проблемы нереализованными (типа) абстрактными методами, которые пропадали после перезапуска fpm. Так что к 7.4 стоит подходить к осторожностью и первое время точно стоит держать руку на пульсе.
Чисто моё личное мнение.
Спасибо, вам ответный привет. Может как-нибудь и скооперируемся касательно докладчиков и ты ды.
Надеюсь что и здесь будет отчёт с видео. Удачной встречи, знаю скольких трудов стоит это все организовать :)
А видео будет? А то приехать я не смогу, а доклад про миграцию интересный, сами как раз сейчас мигрируем.
Как ни странно, всегда можно лушче (я ещё ни разу не видел код, который нельзя улучшить), я не касаюсь [sarcasm]фатальных недостатков ПО (типа код написан не нами и код написан не на нашем любимом языке программирования)[/sarcasm]. В данном случае, если не зашли, то можно почерпнуть оттуда сведения чтобы обойти все грабли, на которые люди уже наступили в этих проектах, ну и знание какие варианты вообще есть. А вообще писать что-то своё всегда полезно, хотя бы просто для понимания.
Nelmio api doc bundle умеет генерировать документацию из аннотаций и может работать в паре с rest api bundle для симфони . Заодно можно получить sandbox на халяву так сказать. И писать ничего не надо, прямо пишем метод, в аннотациях к нему пишем документацию и эту документацию сразу преобразуем в html используя этот бандл
Можно вообще ключ сделать UUID
Запись призводится только тогда, когда большинство серверов с ней согласится, т.е. происходит синхронное согласование. Если происходит сплит, то запись согласуется решением большинства, т.е. надо чтобы было большинство в одном из регионов, иначе будет доступ только на чтение. Далее, при восстановлении соединения, надо учитывать что понадобится некоторое время чтобы нагнать репликацию и там, в зависимости от дельты, будет либо простая репликация, либо стягивание полностью снапшота переключением донора только на чтение. Как-то так.
А не сталкивались с проблемой, когда надо прочитать только что сохранённые данные? Например данные могут записаться на мастере не не успевают попасть на slave, тогда в ответе от сервера будут не все данные, которые только что ввели.
К сожалению, репорт не избавляет от необходимости обходить этот баг. По моему опыту, у разных пользователей могут быть разные, порой даже очень старые версии IE. Был случай, когда приходилось проверять скрипты в трёх(!) разных билдах одной и той же версии IE, т.к. в каждой версии были свои уникальные тараканы.
Кэширование — это только один аспект NOW(), это влияет за собой репликацию как минимум. Что касается системных часов, то я всегда считал что они должны синхронизироваться с эталоном (будет эталоном общедоступный сервер времени или локально поднятый, здесь уже не так важно).
P.S. Я редко сталкивался с проектами, в которых рассинхронизация времени на милисекунды была бы критична.

Information

Rating
Does not participate
Location
Минск, Минская обл., Беларусь
Date of birth
Registered
Activity