НЕЛЬЗЯ работать с деньгами при помощи float.
Бухгалтера убивают за такое. Погуглите, в чём проблема.
Если вам нужны две цифры после запятой, то используйте копейки вместо рублей. Т.е. умножайте на 100. Таким образом все операции будут проходить над целыми числами, а отображать разряды будете уже исключительно на выходе (на экране, на бумаге).
Aleksandr Yurchenko,
Предлагаю следующее:
- Вернитесь к коммиту до обновления
- Переведите всё на атрибуты с rector
- В версии 2.7, по-моему, уже можно описывать дополнительно и атрибуты из новой системы, которую нам "подарили" в 3-й версии. Просто они работать не будут. Зато после обновления на 3-ю заработают.
- Внимательно посмотрите на все "deprecated" логи и ликвидируйте это всё в своём коде
- После этого обновляйтесь и решайте проблемы, которые возникнут. Их будет гораздо меньше, чем если сразу всё скопом делать
Прислушайтесь к совету насчёт rector.
Я буквально две недели назад переводил аннотации в атрибуты, так после автоматической конвертации ни одной ошибки не было
Rerurk,
"Чем больше интерфейс, тем слабее абстракция." - Роб Пайк.
Использование подхода SMI (Single Method Interfaces) - это один из идиоматических подходов в Go.
Самое первое что приходит в голову для демонстрации, почему это хорошо, - это юнит-тесты. Представьте, что вам нужно протестировать функцию, которая принимает репозиторий в виде параметра, но сама функция использует только лишь один метод Create из этого репозитория. Если вы притащите в качестве аргумента интерфейс с полным набором всех CRUD методов, то вам придётся писать моку, в которой придётся добавить все заглушки в эти методы.
Используя такие интерфейсы, мы можем сделать нашу программу невероятно гибкой. А эти же самые интрерфейсы переиспользовать для совершенно других целей.
Например, у нас может появиться дополнительно к основной какая-то база данных, в которой можно только добавлять записи, но нельзя изменять и удалять. Если мы будем использовать одно-методные интерфейсы во всей нашей программе, то мы сможем переиспользовать почти весь наш код для работы с данными и для этой новой базы данных
Конечно, тяжело без работающего примера, но можно попробовать перед переходом по роутеру остановить анимацию, добавив к элементу с анимацией, например такой класс:
alexalexes, Именно так, в каждом проекте. Потому что бардак в коде гораздо хуже 15 минут, "потерянных" на рефакторинг.
В PHP уже давно есть RFC по запрету укороченных тэгов. И однажды они их таки отменят
Sanes, Лечь рядом с ним и начать плакать.
А если серьёзно, то шансов положить тот же самый nginx, работающий в качестве балансера, крайне мало. У него простая работа - перебросить трафик. Он в базу не лезет, памяти не кушает. А если использовать не свой сервер, а тот же Cloudflare, то там ещё и дополнительные меры принимаются даже против ddos
MishaXXL,
Не нужно стремиться делать код "красивым". Нужно стремиться делать код читаемым, чтобы он был понятен сразу, с первого взгляда. А вот побочным эффектом читаемости как раз может стать та самая "красота".
Кстати, ещё совет: чтобы избегать непоняток с тем, когда срабатывает тот самый ++, старайтесь его не использовать там, где это возможно.
// Вместо этого
i++;
// Лучше вот так.
i = i + 1;
// или
i += 1;
Да, код может стать чуть длиннее. Да, вместо одной хитрой строчки может появиться две простые строчки. Но, читая код, вы не будете задумываться над тем, а когда же произойдет этот самый ++, когда изменится переменная. Это может избавить вас от многих багов. Простота лучше "красоты"
suspect47, 2 Гб - это очень много. Бубунта столько всякого ненужного мусора устанавливает, что просто страх. Даже у Плазмы будет значительно меньше. А если посмотреть в сторону минималистичных окружений, то вот тут вы увидите, что такое "летает" на самом деле.
EpIvIaK,
Я тоже перешёл на Go. Но... Если вы уже начали учить PHP - это вам не повредит. Программист - это не язык программирования. Программист - это адепт секты формальной логики. Если вы научитесь воплощать бизнес-логику заказчиков в код, помогать бизнесу решать его проблемы, то язык тут совершенно не важен. А ещё программист - это существо творческое, что бы там кто ни говорил. А творческому человек необходимо хотя бы немножко получать удовольствие от того, что он делает. Поэтому, можете попробовать немного и то, и другое. И выбирайте то, что вам больше нравится.
Go сейчас на подъёме, и вы не ошибётесь, если выберете его. Но... PHP - далеко не умирающий язык, на нём работает большая половина интернета (WordPress). И вы ещё очень долгое время сможете обеспечить себе хлеб с икоркой...
У Go великолепная стандартная библиотека, просто восхитительные инструменты по отладке, форматированию когда, тестам и т.д. и т.п. Я наслаждаюсь этим языком, хотя многие его считают скучным и многословным.
На PHP написаны два устоявшихся фреймворка (Laravel и Symfony), которые невероятно облегчат вам жизнь. Они умеют всё, что касается веба. На них можно, например, в прямом смысле за полчаса собрать CRUD API с интерактивной документацией.
Если решите идти в PHP, обязательно изучайте WordPress. Потому что установщиков плагинов много, а написать плагин самостоятельно умеют не только лишь все. И такие специалисты ценятся.
При любом выборе самое главное - это английский язык. Без него просто никуда. Потому что на русском языке толковой информации крайне мало.
shurshur, Почему современные разработчики не очень любят ORM?
Потому что в самом начале разработки ORM тебе помогает. Но на поздних этапах, а особенно, при рефакторинге, при серьезных изменениях бизнес-логики, ты начинаешь сражаться не только с самими задачами, но и с ORM, которая диктует, навязывает проекту свои строгие правила.
Поэтому, надо всегда понимать, какой инструмент и почему ты выбираешь. И если сомнений нет, все за и против рассмотрены, то нет ничего плохого в использовании ORM, потому что она может очень значительно ускорить разработку при определенных условиях.
Так используйте оба!
Например, можно использовать паттерн Repository и общаться с базой на более абстрактном уровне. А внутри репозитория в каждой конкретной функции использовать тот инструмент, который подходит для данного конкретного случая
Adamos,
1. Новое поле - это наглядность. Посмотреть старых пользователей можно будет хоть прямо в базе мгновенно, без лишних проверок.
2. Возможность вернуться назад - это redundancy на случай проблем, которые могут потенциально возникнуть в процессе перехода. По окончании перехода это всё, конечно же, надо начисто удалить
Kolja Pluhin, К большому сожалению, на Винде и Линуксе альтернатива, наиболее похожая на Atom - это VSCode. Редактор отличный и полностью заменяет Atom. Тем более, несколько мне известно, там есть расширения, в которых есть и темы Атома, и иконки из Атома. Почему, к сожалению, потому что это тоже Electron.
На Маке же совсем недавно появился отличный нативный редактор Zed. Расширений там пока мало, но я в восторге от него
videxerion, Может быть, мне ещё и проект за вас дописать? ))
Понятно, что ошибки надо обрабатывать, и хорошая IDE вам непрозрачно на это намекнет. Тем более, что и я вам намекнул на это комментарием сразу после cient.Get. Что именно делать с ошибкой - это уже только вы знаете. Логгировать, падать, возвращать? Я-то откуда знаю?
Главное - это defer, который отрабатывает в любом случае, что бы у нас там ни случилось уже после соединения при чтении данных и т.д. Эта конструкция языка Go (и некоторых других языков) - одно из гениальнейших решений в программировании, когда исключается целый класс багов, возникающих из-за невнимательности программистов.
