• Как выбрать архитектуру автономного веб-приложения?

    @0x131315
    Да, все сильно зависит именно от концепции самого приложения.
    Если это что-то типа записной книжки - оно может и автономно работать, сеть нужна только как бекап и центральное хранилище для синхронизации с другими девайсами.
    А если это что-то связанное с деньгами или коммерческими сервисами - такое автономно работать в большинстве случаев не способно, т.к. для автономной работы потребуются закрытые данные, которые никто, в здравом уме, на клиент выгружать не будет.
    Сама по себе поддержка автономности требует серьезных дополнительных затрат: больше логики, больше кода, синхронизации, и нередко еще с наворотами. Много чего нужно продумывать: часть сущностей могут быть полностью автономны, часть только частично, а часть вообще не могут быть автономны, и приложение должно учитывать взаимосвязь таких сущностей и ситуации когда они становятся недоступны полностью или частично - это целая гора логики.
    Так что в большинстве случаев автономность не реализуют, если это не является основой функционала приложения. Максимум, так это хранят автономно какие-нибудь данные неавторизованных пользователей, короткое время, просто на случай если пользователь что-то сделает на сайте, важное для продаж, а потом зарегистрируется/авторизуется - например добавит товар в корзину или избранное/сравнение, что приближает его к моменту покупки, и потеря чего после авторизации может доставить негатива, что может стать поводом отказаться от покупки. Причем изрядная доля автономности таких сайтов обеспечивается браузерными кешами.
    Написано
  • Javarush.Стоит ли там учиться, или же лучше по книжкам?

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

    @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
    Поддерживаю. То и дело вокруг народ бездумно хватает всякие кривые библиотеки и исходники, потому что не понимает как работает то или другое, и не может написать сам. В то время как достаточно зайти на оффсайт, глянуть документацию, и там в двух словах точно описано что делает та или иная функция, и часто даже есть примеры использования. Текст документации настолько прост, что его можно понять даже без знания английского, переводчик если и понадобится, то максимум пару раз, в самых неясных моментах.