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 (и некоторых других языков) - одно из гениальнейших решений в программировании, когда исключается целый класс багов, возникающих из-за невнимательности программистов.
mayton2019,
Банки - это воплощение legacy; так они устроены
Банки - это Java (по большому счету)
SOAP напрямую ассоциируется с Java с самого начала своего существования
Банки, legacy, Java, SOAP
mayton2019, Просто сам SOAP мало кому нужен сейчас, и древний extension для PHP просто как legacy тащат.
Я очень давно этот SoapClient не использую, и могу наврать, но, если я верно помню, то перешёл на curl из-за того, что эти горе-кодеры переопределили у себя в расширении стандартный обработчик ошибок, из-за чего я не мог обработать ошибку с помощью try-catch, и заполучил много новых седых волос, прежде чем плюнул и перешёл на curl+XML.
Это решение прекрасно сработает в данном конкретном случае, когда человек ничего не уточнял.
Однако, нам, наверняка, придётся делать какой-то внутренний отступ у самого серого блока при помощи padding, либо задавать padding для этого самого last-child. Ведь будет некрасиво, если текст будет без отступа прилегать к нижнему краю.
Но это не универсальное решение, потому что нам могут понадобиться разные размеры этого отступа в зависимости от контента. Например, мы захотим последним элементом сделать изображение либо таблицу, и как раз сделать так, чтобы этот элемент прилегал книзу без отступов, либо отступы сделать специфическими для данного конкретного элемента. И в этом случае нам придётся уточнять стили :last-child вместо уточнения стилей конкретного элемента. Т.е. мы связываем родителя с дочкой. Это не всегда лучшее решение.
А вот, что будет если сделать при помощи. :before и :after. Нам больше ничего не нужно уточнять у контейнера, а всю стилизацию изображения делать только для этого самого изображения
Ankhena, Если мы внутри самогО серого блока сделаем флексы, и заменим margin на gap для параграфов, то мы не сможем позже вставить в этот текст внутри серого блока изображение, которое будет обтекаться текстом. Это ненужное ограничение, которое мы зачем-то вводим.
Если же мы сделаем флекс для внешнего контейнера, содержащего уже сами эти серые блоки, то мы жёстко привязываем эту внешнюю обёртку к дочерним серым блокам. И если этот серый блок будет использоваться где-то ещё, в другом месте, то мы снова увидим вылезающие марджины.
Ankhena, Перебором как раз являются гриды и флексы. Молодёжь пихает их куда надо и не надо. Попробуйте, например, сделать обтекаемую текстом картинку на гридах и флексах...
Первым ответом на подобный вопрос всегда должен быть WordPress. Потому что это безусловный лидер, и под этот движок написано столько плагинов, сколько другим и не снилось. Наверняка, там уже есть что-то подходящее, потому что подобная идея явно не уникальная.
Если по каким-то причинам WordPress вас не устроит, то я бы посоветовал написать что-то своё, а если и такой вариант не устраивает, то можете попробовать Drupal. Там очень хорошо сделана категоризация контента при помощи таксономии, есть уникальный модуль Views, с помощью которого легко выводить списки контента, тоже довольно много разных модулей, и сама по себе CMS более гибкая и мощная из коробки.
Если вы заметили, то Jetbrains Gateway - это beta продукт. И там могут быть подобные глюки. Советую сразу им тикет писать в поддержку. Этого и ждут от вас, когда дают вам бету... https://youtrack.jetbrains.com/issues/GTW
Не нужно стремиться делать код "красивым". Нужно стремиться делать код читаемым, чтобы он был понятен сразу, с первого взгляда. А вот побочным эффектом читаемости как раз может стать та самая "красота".
Кстати, ещё совет: чтобы избегать непоняток с тем, когда срабатывает тот самый ++, старайтесь его не использовать там, где это возможно.
Да, код может стать чуть длиннее. Да, вместо одной хитрой строчки может появиться две простые строчки. Но, читая код, вы не будете задумываться над тем, а когда же произойдет этот самый ++, когда изменится переменная. Это может избавить вас от многих багов. Простота лучше "красоты"