• Что из себя представляет поиск по диалогам в мессенджере?

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

    @0x131315
    Пора освоить внедрение зависимостей.
    https://m.habr.com/ru/post/350708/comments/#commen...
    Это такие штуки, которые сами подставляют в конструктор класса требуемые ему зависимости.
    Например можно взять php-di пакет в composer.
    Ответ написан
  • Почему двухфакторная аутентификация не ухудшает безопасность?

    @0x131315
    Активировав 2fa, получаешь одноразовый токен для устройства и десяток одноразовых резервных токенов для входа.
    При утере устройства, входишь через один из резервных токенов, анулируешь токен устройства, и перевыпускаешь новый.
    Утеря устройства и утеря/исчерпание резервных токенов - потеря аккаунта.
    Ответ написан
  • Знание middle backend developer PHP?

    @0x131315
    База: ООП, базовые алгоритмы и структуры данных, умение гуглить.
    База для работы в команде: коммуникабельность, неконфликность, стрессоустойчивость.
    База по беку: php7, mysql, git, http, ssh, linux, phpstorm.
    База по фронту: html/css/js/ajax/jquery, работа с панелью разработчика в браузере.
    То, что отличает мидла от джуна, опыт: 2-3 года коммерческой разработки - основные проблемы с серверами, БД, сервисами, архитектурой, основные способы их решения, боль, примеры как не нужно делать, умение писать лаконичный, понятный, поддерживаемый код, библиотека готовых удачных решений (можно в голове, главное понимать, почему лучше сделать так, а не иначе), решительность. Умение рассказать об этом опыте, о встреченных проблемах и найденных решениях - без этого оффера, само собой, не будет.
    Это то, что требуется почти везде.

    Бонусом будет gitlab, postgres, docker, unit-тесты, curl, rest, elastic, regexp, операции над множествами (для фильтрации/поиска/пересечений массивов данных). Всё это можно добрать по необходимости, но работу упростит и время сэкономит.

    Конкретный бек и фронт фреймворк не проблема добрать во время работы, под конкретный проект - документация есть.
    Но как минимум по одному нужно пощупать на беке и фронте, чтобы понимать общий принцип. Я бы рекомендовал symfony и vue, но это, конечно, не принципиально.

    На некоторых позициях фронта нет совсем, или заявляется, что нет фронта. Но как правило он там есть, и база по фронту лишней не будет.
    Фронта нет только на узких api-проектах, там только работа с curl и БД. Но если проект предоставляет личный кабинет, настройки - этот личный кабинет и формы настроек придется писать и поддерживать, а это фронт.
    В общем php без html почти не бывает, а html без css/js/ajax и подавно.

    Верстка скорее не нужна, чем нужна.
    На большинстве позиций в IT-компании базы по фронту достаточно, т.к. основную работу по вёрстке будут отдавать конкретно верстальщикам или фронту, от тебя максимум, что потребуется - точечно поправить какие-то мелкие баги верстки(поправить размер/цвет/текст), внедрить ajax, натянуть вёрстку, вывести данные, подключить стили/скрипты. База по фронту позволит серьезно сэкономить время, понимая 80% происходящего на фронте, выполнять работу быстрее за счёт намного более редкого обращения к вёртальщикам/фронтендерам, т.к. правки минутные, а бюрократия может занять дни.
    В непрофильных конторах заинтересованы в человеке-оркестре, чтобы за одну зарплату купить целый IT отдел. Но и зарплаты там намного меньше, чем в IT-компаниях, т.к. IT в непрофильных конторах не является основным источником дохода, а скорее идёт как довесок, без которого нельзя, но от которого хотелось бы избавиться. Так что требований будет больше: админ-фуллстек-дизайнер-менеджер за 30к.
    Ответ написан
  • Как не превысить количество обращений к стороннему ресурсу со своего домена?

    @0x131315
    Тебе нужен кеш.
    Кеш - это хранилище, где каждый блок данных имеет как минимум два параметра: идентификатор и время жизни.
    В простейшем случае это папка с файлами, где имя файла - это идентификатор, а время жизни вычисляется по разнице времени модификации файла и текущего времени.
    Идентификатор однозначно идентифицирует блок данных. Обычно идентификатор - это хэш от сериализованного массива, в который помещают всё параметры, от которых зависит содержимое блока данных.
    Например если данные на api зависят только от пути - айди это хэш от пути. А если ещё и от get-параметров, то к пути нужно добавить и эти параметры.
    В таком случае, прежде чем обращаться к api, нужно посчитать хэш от запроса, и проверить, есть ли файл с таким именем в папке кеша, и не слишком ли он старый, и либо отдать данные из файла, либо обратиться к api, перезаписать файл полученными данными, и отдать данные.

    Но вместо того, чтобы во всё это вникать и пилить велосипеды, лучше просто подключить в композере любой из популярных кешей, он не только будет работать лучше самописного, но и предоставит множество инструментов для обслуживания кеша.
    Ответ написан
  • Как стать топовым WEB разработчиком?

    @0x131315
    Сейчас одиночки нафиг никому не нужны.
    Серьезные деньги только у крупных компаний.
    Например возьми сайт DNS - в одиночку протянешь? Со всеми сервисами и интеграциями? С отладкой, и не дольше, чем средняя команда разработчиков?
    Вот поэтому одиночки не нужны.

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

    Формирование одних только ТЗ у целого отдела аналитиков занимает полгода. Множество туров переговоров и согласований.
    И вот пришел топовый разработчик, и за месяц смог не только все это прочитать, оценить, но и сделать.
    Ответ написан
  • Как обновляется информация на сайтах?

    @0x131315
    Крупные проекты так или иначе используют CMS.
    Это выглядит как специальный интерфейс для редактирования статей и товаров.
    Через него можно редактировать старые, и добавлять новые.
    Также сайт часто связан с какими-то бизнес-системами, типа CRM, 1С, и обменивается с ними информацией.
    Например склады и магазины работают с 1С, соответственно цены и остатки товаров приходят на сайт из 1С.
    Службы доставки работают с CRM, соответственно цены и условия доставок приходят от CRM.
    А на самом сайте хранятся характеристики товаров, фотографии, видео - всё это в 1С и CRM не нужно, но нужно покупателям на сайте.
    Инициировать изменение данных может множество людей через множество систем: постоянно идёт какая-то аналитика, прогнозы, стратегии, маркетинговые акции. Начальники планируют политику, и вводят свои ограничения.
    Сайт всё это отображает и учитывает.
    Нет какого-то одного человека, который бы лично следил за всем. На каждом уровне управления множество людей, оперирующих разными понятиями.
    Ответ написан
  • На каком языке сейчас чаще всего программируют микроконтроллеры?

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

    С симками ситуация иная - там важно было реализовать кроссплатформенный код. Поэтому используют java, не смотря на ресурсы.

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

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

    Так что все зависит от здравого смысла и стоимости.
    Просто так везде пихать java - немного глупо.
    Ответ написан
  • Как вы справляетесь с тупняком в программировании?

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

    Быть может большая часть прочитанного/услышанного не будет использоваться, но однажды, когда встанет соответствующая задача, эти кусочки всплывают в памяти и встраиваются в общую картину.

    Опыт нужен, но от неопытных его не почерпнуть. Авантюры с новичками мало что дают, т.к. перенимается только худшее, костыли. Нужно ориентироваться на более опытных товарищей.
    Хороший вариант - открытые проекты в github, как минимум можно посмотреть как люди решают те или иные задачи, почерпнуть некоторые фишки, пообщаться в комментах с теми, кто в теме, как максимум - можно влиться в разработку, отхватить кучу гневных комментов в стиле "что за говнокод?", но заодно и получить пинок в правильную сторону быстрее, где бы то ни было.

    И помни: топтаться на месте и ходить кругами можно долго. Шансы на то, что это приведет к успеху - минимальны.
    Так что обязательно нужно что-то делать для развития.
    Можно пройти онлайн-курсы за год. Это даст хороший уровень.
    Или, если ты ленивая жопа, податься стажером на галеру - там за полгода тебя заставят прокачаться до хорошего уровня.

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

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

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

    Разработчики записывают всё время по задаче, как им удобно, в свободной форме, но с привязкой к задаче. Это может быть непосредственно разработка, поддержка, аналитика, консультации - любая полезная деятельность должна быть оплачена.
    Записывают как и когда им удобно, но заранее предупреждаются о сроке закрытия спринта/сделки, чтобы успели проставить время.
    От закрытого времени напрямую зависит их (и не только их) доход, так что если что-то не записали - значит работали бесплатно, мотивация трекать более часто. Опять же нужна прозрачность, чтобы разработчики понимали, что от их записей зависит и их доход и фирмы.

    Систем трекинга много, всяких.
    Но это разработчики - так что в ходу много кастомных, внутренних, даже частных трекеров, которые сливают записи по api в кастомный корпоративный трекер.
    Есть всевозможные клиенты для корпоративного трекера, в т.ч. веб-морда и mobile apps. Разрабатываем сами, кому как удобно, что-то приживается, что-то отмирает - живая экосистема.
    Корпоративный трекер в свою очередь можно синхронизировать с редмайнами. Некоторые клиенты умеют заливать и в трекер и в редмайны, т.к. хранят данные в универсальном формате.

    Оценка по комфортному времени позволяет разработчикам чаще укладываться в оценку, чем не укладываться. Поэтому почти с каждой задачи остаётся какой-то процент неиспользованного времени. Плюс оценка на риски менеджера.
    В конце спринта все неиспользованные часы складываются, и из них покрывается овертайм.
    Овертайм бывает на небольшом проценте задач, но иногда значительный: 200-300%. Не всё можно предусмотреть.
    Почти всегда суммарного запаса часов хватает: например в спринте 10 задач, разработчики оценили их по 5ч каждую, менеджер заложил ещё 5ч на риски, итого 10ч каждая - зарезервировано 100ч на спринт, по итогу 2 задачи уши в большой овертайм, и скушали 30ч, 3 задачи ушли в овертайм, но уложились в риски - ещё 30ч, зато оставшиеся 5 задач уложились в оценку (без рисков), и на них ушло по 5ч - итого зарезервировано 100ч, затрачено 85ч(30+30+5*5), в оценку уложились, заказчик доволен.
    Но так плохо редко бывает, в основном, т.к. разработчики оценивают комфортное время, реально уходит меньше оценки, т.е. оценили в 5ч, сделали за 3-4ч.
    А те часы, что остались после покрытия овертайма, в счёт не выставляются, так что работа обходится как правило дешевле договоренностей. Небольшой приятный бонус для заказчика. Можно смело присваивать эти лишние часы, но долгосрочные отношения на обмане не построить, так что нафиг.
    В случае совсем форс-мажоров, когда выходим за все риски - обсуждаем с заказчиком возможные варианты. Обычно заказчики идут на встречу, и выделяют дополнительные ресурсы.

    Плюсы подхода: почти всегда укладываемся в бюджет, часто обходимся дешевле договоренностей, хорошие отношения с заказчиками.
    Минус подобного подхода - приходится часть бюджета резервировать на риски, эта часть бюджета замораживается на два спринта, и может быть влита в 3й.
    Как итог заказчику приходится закладывать бюджет чуть больше необходимого, но за счёт этого получаем намного более предсказуемое и стабильное планирование, к тому же в большинстве случаев этот небольшой переизбыток бюджета остаётся неиспользованным, и в среднем это бесплатно: то, что заморожено в текущем спринте, будет разморожено в следующем, и через спринт может быть пущено в дело.
    Ответ написан
  • Как грамотно изолировать сервисы на linux-сервере?

    @0x131315
    ИМХО наиболее актуально - докер.
    Банально - прост в настройке, есть уже собранные образы на любой вкус, минимальные накладные расходы (можно позволить себе меньше памяти и дешевле железо), лёгкий мониторинг и управление сервисами. Умеет изолировать сервисы, сети и ресурсы. Умеет поднимать упавшие сервисы. Умеет управлять кластерами. Есть множество удобных веб-морд для управления/мониторинга из любого места, где есть браузер.

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

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

    Также и с FPM, можно держать несколько общих контейнеров с разными версиями - глобальный nginx легко заставить маршрутизировать каждый проект в нужную версию FPM. Но это тоже не особо критично, т.к. FPM тоже дешёвые.
    Специфичные настройки FPM под каждый проект нередко можно компенсировать подключением полифилов внутри проекта, чтобы сэкономить память.

    Естественно все это нужно собирать под docker compose
    И придерживаться правила: всё, что нужно проекту для работы, должно быть в одном docker compose файле (читай - каждый проект в своей папке)

    Ну и в хост-системе, понятно, не должно быть нативно того софта, что работает в контейнерах - будут проблемы с настройками, портами, и вообще, софт в хост-системе по факту не нужен, докером намного удобнее управлять, особенно когда есть несколько несовместимых проектов, и нужны две-три версии одного и того же софта. Без докера такое настраивать - ад.
    Ответ написан
  • Стоит ли начинать учить программирование в 26 лет. Как это скажется на карьере если на позицию джуна претендовать в 26 лет?

    @0x131315
    Тут решает не возраст, а желание.
    Просто с возрастом падает спрос - меньше компаний готовы будут сделать оффер.
    Но 30 - это не тот порог, проблемы будут если начинать в 40-50, это будет гораздо сложнее.
    Впрочем, если наработать портфолио, пройти курсы, получить сертификаты, в общем заиметь что-то, что можно будет предъявить как доказательство своих компетенций - проблем с трудоустройством не будет.
    Основная сложность у компаний не возраст, а риск: потянет этот стажёр свои обязанности, или его найм - потеря денег и времени.
    Понятное дело, если есть хоть что-то, кроме слов и обещаний - это уже весомый аргумент.

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

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

    Комитить каждую строчку бессмысленно, а коммитить огромные куски кода черевато большими проблемами, особенно при конфликтах.

    Ежедневные/ежемесячные коммиты - это вообще жесть.
    Git - это история, каждая запись в ней должна иметь смысл.
    Ответ написан
  • Как найти источник медленных запросы MySQL?

    @0x131315
    Многие запросы на битрикс немного ускоряются, если уточнить запрос, например вместо 'IBLOCK_ID'=>10 указывать '=IBLOCK_ID'=>10
    Ответ написан
  • Подключение платежного шлюза СберБанк. Как реализовать подключение?

    @0x131315
    В процессе интеграции sbercredit. Аналогичные проблемы.
    В документации запросы странного вида, такие не выдает ни http_build_query, ни key-value подстановка.
    Плюс запросы GET, но с требованием POST-заголовка application/x-www-form-urlencoded)
    Примеры POST-запросов в документации неадекватные, и завести их так и не удалось ни в каком виде.
    Оказалось что API принимает только GET, и http_build_query вполне хватит.

    Проблема была в документации: запросы составлялись по их документации, но... ничего не работало. И API не умеет говорить ничего, кроме system error)
    Разобрал их API по кусочкам, оказалось что оно документации мало соответствует - многие необязательные поля на деле обязательны.

    Сейчас следующий круг ада: API принимает запрос, отдает данные для перехода на шлюз, но... теперь шлюз отдает ошибки в web-интерфейсе)
    Оказалось поле muasure было обязательным. При этом в документации в примерах запросов оно пустое, и API на пустое поле ошибок не выдает. Такие дела.
    Ответ написан
  • Как эффективно выучить PHP?

    @0x131315
    ИМХО ключевое в php, когда имеешь базу - это не сам язык, а понимание того, какую роль он выполняет, и какое место в архитектуре эта роль занимает.
    Что касается php, то это в первую очередь скриптовый язык, созданный специально для связи Фронта с Беком, т.е. основная его функция - предоставление доступа к БД сервиса для html и js-кода, работающих на фронте.

    На сегодняшний день php решает следующие задачи:
    -доступ к БД
    -вспомогательные вычисления
    -шаблонизация
    -связь с внешними сервисами
    -предварительное кеширование

    Нужно в первую очередь понять как работает Веб, что такое фронт и бек, как они взаимодействуют, что такое хит, что такое ajax, как происходит идентификация посетителя (в частности как работают сессии и куки). Это основные моменты.

    ООП стоит учить и использовать сразу, благо основные идеи ООП просты и доступны каждому. А вот всякие паттерны и хитрости лучше отложить - постигнешь их по мере надобности.
    Все, что тебя отделяет от ООП - это автозагрузка, освой composer, и написание кода станет лёгким и приятным занятием.

    Очень важно иметь хоть какую-то базу по алгоритмам и структурам данных. Если её нет - её следует подтянуть. Без этого будешь строить велосипеды на ровном месте, и запугаешь народ своим кодом.

    Очень важно изучить php.net
    Не обязательно штудировать всё, но стоит как минимум взглянуть что там вообще есть.
    Этот сайт - нечто вроде документации по STDLIB языка, в ходе практики ты к нему будешь возвращаться ещё тысячи раз.
    Многие задачи, которые ты планируешь решить велосипедом, уже решены за тебя, и входят в язык - нужно просто знать про то, что язык умеет из коробки, а что нет.

    Очень важно поработать с фреймворками и репозиторием composer: большинство из задач, которые встанут перед тобой, уже кем-то решены, и существует либо готовая библиотека, либо как минимум публичный интерфейс, который ты можешь реализовать, чтобы не натворить архитектурных ошибок.
    Посмотри на symfony, почитай стандарты PSR.
    Большинство задач решается декомпозицией алгоритма, и сборкой приложения из готовых библиотек или PSR-интерфейсов. Остаётся только это всё сконфигурировать, и дописать немного кода для склейки всего этого в единое приложение.

    Т.к. php - это прокладка между html и БД, обязательно нужны основы html, SQL, и практика по развертыванию, проектированию, и управлению какой-либо СУБД.
    Наиболее популярная и простая СУБД - MySQL, на ней и сконцентрируйся. Намного позже, когда будет опыт, обязательно попробуй postgres - это намного более совершенная СУБД, но она сложнее MySQL, и новичкам с неё начинать не стоит.
    Особо углубляться в sql не стоит, т.к. в чистом виде с ним будешь работать мало, по большей части взаимодействие с БД сведётся к установке ORM-библиотеки, например doctrine2. Вот ORM стоит изучить плотнее, они предоставят тебе простой и приятный доступ к данным в БД, и обеспечат лёгкие миграции состояния БД.

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

    Очень сильно поможет хороший редактор кода, например phpstorm - он будет подсвечивать твои ошибки, предоставит интерактивные подсказки по коду, и позволит быстро инспектировать код большого проекта, параллельно работая с ФС сервера, БД и docker-контейнерами. Серьезно ускоряет и упрощает работу.
    Ответ написан
  • Чем пользоваться при планировке баз данных?

    @0x131315
    Выбираю СУБД. От неё сильно зависят возможности: типы данных, индексы, промежуточные таблицы.
    Разбиваю куски данных на сущности - тематические наборы данных.
    Раскидываю сущности по таблицам - определяю что именно за поля должны быть в каждой сущности, для чего они нужны, какие типы данных будут оптимальны.
    Связываю сущности отношениями. Выясняю, действительно ли необходимы каскадные операции отношениям, или нет, где лучше сохранить устаревшие данные, где можно подчистить, а где нужно сохранять актуальные связи по id.
    Оцениваю получившуюся структуру, оптимизирую её: денормализую некоторые сущности, добавляю данные в связи, где не хватает, добавляю служебные поля, индексы.
    Далее гоняю несколько итераций в голове на типичные сценарии использования: где-то всплывает неоптимальность структуры, или типа поля, где-то отсутствие необходимого поля, где-то можно сохранить дополнительную информацию, которая сейчас не нужна, но в некоторых сценариях значительно ускорит выборку данных из БД.

    Идеал все равно не получится, остальное допиливается миграциями по мере необходимости. Но самых крупных косяков можно избежать, как следует подумав что хранить, зачем, в каком виде, как это будет использоваться, как работает СУБД, как ей помочь.
    Ответ написан
  • Старт в бэкенд-разработке (Python). Можно ли обойтись без знания фронтенд-технологий?

    @0x131315
    Конечно можно.
    Совсем без фронта обойтись скорее всего не выйдет - много где на банке лежит html и js, и поправить что-то самому намного быстрее, чем объяснить задачу фронтендеру.
    Но верстать не обязательно.
    Много задач чисто по бекенду, часто очень сложные, требующие именно специалиста. Работа с БД, бизнес-логика, общий код - все это чисто бекенд.
    Ответ написан
  • MySQL+PHP и компилируемый язык?

    @0x131315
    Исходя из описания, будет большая БД и простенький клиент для неё.
    Основные требования - именно к БД: распределенность, отказоустойчивость, расширяемость.
    С первыми двумя всё просто: кластер.
    А вот расширяемость напрямую зависит от архитектуры БД - над ней стоит поработать как следует, потом что-то исправить здесь будет очень сложно и дорого.
    С кривой архитектурой не поможет ни кластер, ни оптимальный код клиента - БД будет тормозить всегда, проект придется свернуть.
    Так что всё правильно сказали - язык не столь важен, как БД. Клиентов можно наделать сколько угодно, и на любых языках - клиенты примитивные.
    А вот бизнес-логика, если она есть - её поддерживать на нескольких языках дорого. Если она есть - нужно под неё выбрать один язык, и писать всё на нем.
    Сейчас для такого в ходу go, python и php. Выбирать лучше то, что знаешь - масштабировать под нагрузку всё это можно легко.
    Для клиентов на этом языке делается api, за которым скрывается бизнес-логика.
    В таком варианте код клиентов простой и дешёвый, логика поддерживается в одном варианте, и всегда согласованна со всеми клиентами.
    Ответ написан