• Как правильно располагать ресурсы для ускорения загрузки и рендеринга страницы?

    @0x131315
    Дополню
    Подход со ссылками работает значительно лучше, если сервер корректно работает с кешем или используется CDN.
    В этом случае повторного обращения по ссылкам просто не происходит - эффективнее некуда.
    Что касается мелких спрайтов - если дошли до такого уровня оптимизаций, их сшивают в карты спрайтов.
  • Зачем делают backend на разных языках?

    @0x131315
    Adamos, это так. Но во многих случаях это не норма, а косяк.
    Если внятного ТЗ нет на старте разработки - значит постеснялись "дожать" заказчика.
    Из-за кривого ТЗ время разработки увеличивается в 2-3 раза, растет риск срыва сроков.
    Оно того не стоит. Проще "дожать" заказчика и родить ТЗ.

    А после запуска проект неизбежно меняется. Но это уже не ТЗ, а адаптация.
    Становится понятно на что стоит ориентироваться, и проект меняется.
    Так везде: пока что-то не попробуешь, не поймешь какие тут реалии и куда нужно развиваться.
    Плюс маркетинг постоянно генерирует гениальные идеи одна за одной - тысячи правок в год.
  • Зачем делают backend на разных языках?

    @0x131315
    Принцип Парето (80/20) наглядно.
    Основу разрабатываем с минимальными затратами сил и времени.
    По мере роста нагрузки оптимизируем некоторые наиболее медленные части, переносим на другие языки если так нужно.
    Доля оптимизируемого кода от всего кода минимальна - минимальны и затраты.
  • Подключение платежного шлюза СберБанк. Как реализовать подключение?

    @0x131315
    Александр Анкудинов, обычно при заключении договора создают личный кабинет и логины/пароли для test/prod окружений. А без договора такое и смысла не имеет.
    Документация здесь:
    https://securepayments.sberbank.ru/wiki/doku.php/start
    https://pokupay.ru/documents
  • Как хранить подключение к БД для удобного обращения из других классов без глобальной переменной?

    @0x131315
    LionG, даже такой случай как смешанное конструирование разобран в официальной документации)
    Просто изучи её подробнее, там всё есть.
  • Как хранить подключение к БД для удобного обращения из других классов без глобальной переменной?

    @0x131315
    LionG, так в чём проблема?
    Опиши в конфиге фабрику, которая и соберёт тебе объект с любыми параметрами и по любым условиям.
    В ней можно использовать любой код и любые другие зависимости (которые опять же разрешит сам контейнер по инструкциям из конфига), или данные из любых объектов - в общем полная свобода.

    Да и без фабрики оно умеет не только любые аргументы в конструктор прокидывать, но и вызывать сеттеры, и даже перезаписывать поля объекта - там активно используется reflection api под капотом. Т.е. через неё можно настроить абсолютно любой объект, даже если автор не предусмотрел его настройку через сеттеры или конструктор, а сам код по какой-либо причине (например это чужая библиотека) менять нельзя. На оффсайте php-di есть примеры на все случаи жизни.

    В том то и ценность этой штуки, что она полностью избавляет от таких цепочек зависимостей, позволяет их "развязать", получив хороший чистый код.
    В статье из моего предыдущего коммента это раскрывается.

    Т.е. не нужно тянуть зависмость через всю цепочку, если она нужна только последнему в цепочке - просто указываешь зависимость только для последнего в цепочке.
    Когда последний в цепочке будет конструироваться, контейнер увидит, что объекту не хватает зависимости, сконструирует эту зависимость по тем инструкциям, что ему передал программист, и передаст последнему объекту в цепочке, избавив тем самым от необходимости таскать зависимости через код без реальной нужды.

    В этом и прелесть: код никак не зависит от контейнера, и даже не знает о его работе, и в то же время получает все необходимые зависимости, как будто их ему передали в конструктор напрямую.

    Что совсем замечательно, можно прийти к практике в качестве зависимостей указывать не классы, а вообще только интерфейсы, а конкретную реализацию выбирать в конфиге, причем в том числе динамически: этот объект получит файловый логгер, а этот вот пусть в кибану логи пишет.
  • Подключение платежного шлюза СберБанк. Как реализовать подключение?

    @0x131315
    Алексей Колесников,
    После всех экспериментов вылилось вот в такое

    $request = [
                'language' => 'ru',
                'currency' => 643,
                'pageView' => 'MOBILE',
                'orderNumber' => 'order1',
                'amount' => 10 * 100,
                'returnUrl' => 'http://store.com/order/order1',
                'merchantLogin' => 'merchantId',
                'jsonParams' => json_encode(
                    [
                        'email' => 'user@mail.com',
                        'phone' => '+79999999999',
                        'backToShopUrl' => 'http://store.com',
                        'backToShopName' => 'Назад в магазин',
                    ]
                ),
                'orderBundle' => json_encode(
                    [
                        'orderCreationDate' => '2021-03-14T12:59:00',
                        'customerDetails' => [
                            'email' => 'user@mail.com',
                            'phone' => '+79999999999',
                            'contact' => 'user',
                            'deliveryInfo' => [
                                'deliveryType' => 'delivery',
                                'country' => 'RU',
                                'city' => 'город',
                                'postAddress' => 'адрес',
                            ],
                        ],
                        'cartItems' => [
                            'items' => [
                                [
                                    'positionId' => 1,
                                    'name' => 'спички',
                                    'quantity' => [
                                        'value' => 1,
                                        'measure' => 'шт.',
                                    ],
                                    'itemPrice' => 10 * 100,
                                    'itemAmount' => 10 * 1 * 100,
                                    'itemCode' => 'артикул',
                                    'itemCurrency' => 643,
                                ],
                            ],
                        ],
                        'installments' => [
                            'productType' => 'INSTALLMENT',
                            'productID' => 10,
                        ],
                    ]
                ),
                'userName' => 'login',
                'password' => 'password',
                'dummy' => 'true',
            ];
            $url = 'https://3dsec.sberbank.ru/sbercredit/register.do?' . http_build_query($request);
            $curl = curl_init();
            curl_setopt($curl, CURLOPT_URL, $url);
            curl_setopt($curl, CURLOPT_RETURNTRANSFER, true);
            curl_setopt($curl, CURLOPT_CUSTOMREQUEST, 'GET');
            curl_setopt($curl, CURLOPT_HTTPHEADER, ['Content-Type:application/json']);
            $response = curl_exec($curl);

    Нужно подставить свои логин, пароль и мерчант для теста.
    И 3dsec - это исключительно тестовый шлюз.
  • Как не превысить количество обращений к стороннему ресурсу со своего домена?

    @0x131315
    r0semary, когда неизвестно время обновления информации на внешнем ресурсе - вполне обычная ситуация.
    Если на внешнем ресурсе информация не обновляется или обновляется редко кеш можно хранить долго. Например неделю.
    Если обновляется часто или нужно быстро отреагировать на изменения - кеш обновляют чаще, например раз в час или раз в день.
    Даже если кеш обновляется раз в час - это уже экономит тысячи запросов, т.к. к внешнему ресурсу будут идти обращения вместо нескольких раз в секунду - всего раз в час.

    И еще такой момент - иногда бывает кеш уже истек, и его нужно удалить, а внешний ресурс упал.
    Технически можно отдать данные из устаревшего кеша, т.к. лучше устаревшие данные, чем ничего.
    Но в большинстве случаев такое не продумывают, и в случае падения внешнего сервиса сайт лишается данных, а то и тоже падает.
    Этот момент стоит предусмотреть заранее: перед зачисткой кеша убедиться, что данные для его обновления получены.
  • Как стать топовым WEB разработчиком?

    @0x131315
    yskl24, найди себе команду.
    Это не обязательно офисная работа, многие и на удаленке работают.
    Но первое время лучше в офисе, в прямом контакте с разработчиками - за полгода натаскают до уровня, когда можно работать самостоятельно, без присмотра. С учетом пандемии пока офис особо никому не светит.
    Стек команды подбирай под себя, на чем планируешь работать в ближайшие годы.
    Команд много, каждая на своем стеке и в своей сфере работает, так что выбор есть.

    Основа командной работы - коммуникации. Чаты (от телеграм и скайпа до всякой экзотики типа слака), трекеры задач, gitlab.
    Впрочем по этому натаскают за полмесяца - там ничего сложного.
    Главное - по любому вопросу обращайся к коллегам. Чем больше спрашиваешь - тем быстрее прогрессируешь. Впрочем прежде чем идти к коллегам, сперва лучше у гугла спросить или уточнить - большинство простых вопросов/проблем там разобрано более чем подробно, вполне вероятно что этого хватит.

    Не обязательно сразу рваться делать все - сперва можно попробовать себя в роли верстальщика или фронтенд-программиста (это верстка + js).
    Если совсем худо - можно начать дизайнером (фигма), тестеровщиком, или стажером, там требования гораздо менее строгие.

    Если хочешь освоить полный цикл - придется помимо фронта освоить и бек.
    Тогда выбирай стек на ближайшие 10 лет. Бек-технологии меняются довольно медленно, по сравнению с фронтом.
    Рекомендую также параллельно основной работе пробить у руководства какой-нибудь курс по беку, и заниматься им в свободное время - поможет с фундаментом.

    Для верстальщика/фронта/бека/фулла обязательно также освоить git. Курсов бесплатных много - не проблема. Будет плюсом в резюме.
    Для бека/фулла обязательно нужно освоить sql.

    Если идешь на должность стажера - всему этому натаскают/обучат. С одной стороны это потеря всего пары месяцев, потом переведут на должность разработчика, с другой стороны стажеров мало кто готов брать, так что выбор будет меньше.
    Тут каждый сам для себя решает - самостоятельно освоить базу, чтобы сразу разработчиком пойти, или попытать счастья пристроиться стажером.

    Но по факту не так важно кем идти, главное опыт, главное получить работу и посмотреть самому как что устроено.
    Уже через пару месяцев начнет доходить, стоит ли продолжать и кем, каких знаний не хватает, хочешь ли сменить сферу деятельности, или компанию.
  • Linux для начинающих?

    @0x131315
    Сява, начни с простого и дружелюбного - минт, убунта.
    Через год-два начнёшь понимать как устроена система, сможешь уверенно экспериментировать с окружения и и дистрибутивами.
    Сильно извращаться не стоит - пользуйся популярным, по остальному информации в Гугле почти нет, проблемы будет трудно решать.
  • Как эффективно выучить PHP?

    @0x131315
    Hey One, очень реально. В айти сейчас кадровый голод, многие готовы обучать свои кадры.
  • Объясните цикл разработки веб-фронтенда?

    @0x131315
    У меня в команде нет четкого деления на бек, фронт и верстку.
    ТЗ приходят от бизнеса, извне, и не часто делятся на верстку/фронт/веб, хорошо если есть верстка и внедрение, но часто просто уровня "запилить фичу", а дальше задача последовательно передается спецам разной направленности.
    Из должностей есть только менеджер, программист и верстальщик. Но нет чисто бекеров или чисто верстальщиков. Менеджер просто мостик между бизнесом и командой, анализ, уточнение ТЗ и оценку делают сами программисты/верстальщики.
    Несколько человек - fullstack, а остальные - кто-то сильнее в беке, кто-то во фронте.
    Хотя этого от них и не требуют, но все верстальщики отвечают не только за верстку, но и за фронт, а пара человек также может немного в бек, на уровне внедрить верстку в php-шаблон.
    Все программисты отвечают за бек, фронт от них не требуют, а тем более верстку, но многие неплохо знают js, а пара человек фуллстеки, и сами верстают.
    Человек целиком и полностью отвечает за задачу. Сколько он может - столько делает сам, что не может - передает тому, кто может.
    На задачу дается неделю, потом задача уходит к тестерам либо переносится на следующий релиз. Тесты длятся неделю, в это же время идет шлифовка и допиливание фичи.
  • Как в PHP вывести маленькое дробное число без изменения количества знаков после запятой и перевода в формат "e"?

    @0x131315
    aldroid, дело в том, что компьютеры не хранят незначащие нули, а значит у кода просто нет информации, сколько нулей нужно выводить. Отсюда косяки с методами вывода, требующими указания точности - ты тоже не можешь указать верную точность им, т.к. тоже не знаешь её.
    Напиши новый класс, в котором храни строковое и числовое представление, и используй его для обмена данными.
    При инициализации парси строку в число, и сохраняй внутри класса точность, которая была в строке.
    При вычислениях используй число.
    При выводе - подставляй в вывод сохраненную точность, и получишь то, что нужно.
    Класс нужен для привязки точности к конкретному числу. Но это не обязательно - точно также можно пользоваться массивами, или переменной, если вычисления точечные.
  • В чем суть миграций БД?

    @0x131315
    89109983838,
    Чот как то не укладывается в голове это определение необходиости миграции!!?

    Миграции - это история изменений структуры БД во времени
    Они хранятся вместе с приложением

    Новый код рассчитан на работу с последней версией БД
    При обновлении приложения код определяет версию текущей БД (номер последней примененной к ней миграции), и по очереди применяет к БД новые миграции, повышая версию БД до необходимой коду для нормальной работы
    Таким образом нет необходимости вручную следить за структурой БД, и менять ее

    Более того, миграции содержат не только логику обновления БД, но и логику отката изменений, сделанных миграцией - это позволяет безопасно (без потери старых данных), менять версию БД как вперед, так и назад
    Особенно помогает при ошибках - в случае плохого кода или плохой миграции всегда можно откатиться на стабильную версию, быстро и безопасно
  • Пожалуйста оцените мое убогое ООП?

    @0x131315
    Adamos, таки да.
    Но очень забавно наблюдать, как клиент постепенно отходит от архитектуры cms, и от самой cms.
    Сначала "всё делаем на Битриксе, он крут". Ок, делаем. Итог: что-то не работает, многое глючит, какие-то ограничения непреодолимы в рамках Битрикс.
    Потом "хорошо, нам это важнее Битрикса, давайте подумаем как обойти". Ок, обходим, пишем свои сервисы, от Битрикс остаётся только ядро, сайт по большей части работает в обход Битрикс. Итог: жуткая гора говнокода. Что-то сделано хорошо, но многое плохо, поддерживать тот ещё ад. Потому что разработка не спланирована и несогласована - параллельно несколько команд, приоритет у команды клиента, только уровень этой команды оставляет желать лучшего. Невнятные ТЗ, отсюда большие потери времени на простые задачи. В общем цирк)
    Потом "ой, как всё плохо получилось, а давайте тогда вынесем логику на промежуточный прокси на Symfony, а Битрикс будет просто отдавать контент")

    Вот как агрессивная реклама работает)
    Клиент всё никак не может отпустить Битрикс) Хотя он ему уже не нужен, и приложение почти полностью переезжает на Symfony

    Что ещё забавнее - никто не хочет сразу на Symfony делать, больно дорогая разработка, надо здесь и сейчас.
    Но сэкономив на разработке, в итоге теряют на порядки больше времени и ресурсов, чтобы дойти до решения, которое надо было выбрать сразу

    Если бизнес требует решения здесь и сейчас, можно конечно сделать первую версию на Битрикс, но нужно держать в голове, что это временное решение, основная цель которого - выиграть время на разработку основного, полноценного решения
  • Как преодолеть кризис начинающего специалиста?

    @0x131315
    Добавлю
    Поскольку работа рутинна, и особо ничему полезному не учит, программисты тратят много времени на самообразование и делятся друг с другом опытом. Иначе никак
    Если этого не делать, можно на годы погрузиться в рутину, и застыть во времени и навыках
    И чем больше нагрузка - тем более липкая эта рутина, тем больше поглощает и сложнее выбраться. Но выбираться надо
  • Что почитать по Gradle на русском языке?

    @0x131315
    Поддерживаю. То и дело вокруг народ бездумно хватает всякие кривые библиотеки и исходники, потому что не понимает как работает то или другое, и не может написать сам. В то время как достаточно зайти на оффсайт, глянуть документацию, и там в двух словах точно описано что делает та или иная функция, и часто даже есть примеры использования. Текст документации настолько прост, что его можно понять даже без знания английского, переводчик если и понадобится, то максимум пару раз, в самых неясных моментах.
  • AdBlock зачем ты так?

    @0x131315
    Я к тому, что адблок в данном случае работает нормально. Приведенный текст - как раз типичная реклама.
    Ничего странного в его поведении здесь нет. Он делает ровно то. что должен - вырезает рекламу.
  • Какие Вы знаете источники знаний о PHP?

    @0x131315
    Идеальное решение. Спасибо за идею. Хотя она и так очевидна, и даже иногда приходила в голову, но именно ваш коммент наконец-то "перещелкнул" что-то в голове.

    Тоже не раз в фоне задумывался о чем-то подобном: потенциально все могёш, убедился в своем потенциале к обучению, за все, что берешься - получается, но все это как-то бесцельно. Однажды генератор целей иссякает, и все, обучение повисло, все начинает забываться. Смешная ситуация на самом деле - таким образом уже около дюжины ЯП недовыучил.

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

    Без рынка нет целей, но без целей нет и опыта, а без опыта - нет рынка, замкнутый круг, который непонятно как разорвать.
    В тоже время знаешь, что за обучение надо платить, и даже готов платить своим заработком.
    Остается только в голове связать эти две вещи, и оп!
    Решение гениально как по своей простоте, так и по очевидности - выходить на рынок и набираться опыта, продаваясь бесплатно, пока не почувствуешь, что твоя работа стоит того, чтобы начать за нее брать деньги. Но несмотря на очевидность, на то, что оно буквально витает на языке, ухватить его не удается долгое время, пока однажды не встречаешь такой пост, или сам не обучаешь другого, и внезапно для себя не высказываешь ему такую мысль, которая и тебе самому помогает.

    Все-таки человеку важно материализовывать мысли - без этого что-то не отрабатывает в голове, какой-то из уровней ассоциаций видимо проходит через внешний мир.
    Иногда даже просто пишешь свои мысли или высказываешь их устно, перечитываешь/вслушиваешься в то что написал/сказал, и совершаешь открытие, которое почему-то не мог сделать до материализации мыслей.