Фрилансер - сам себе бигбосс, менеджер проектов, тимлид, миддл и джун. Он привык тащить кучу всего, не относящегося к разработке. В офисе от этого придется отвыкать - а это бывает довольно болезненно - когда ты, весь такой опытный, прекрасно знаешь, что задача А решается способом B, а тимлид говорит, что она должна быть решена способом C - более медленным и затратным, но нужным по каким-то там непонятным соображениям.
Это не отличие именно фрилансера. Любой специалист может столкнуться с ситуаций, когда тимлид будет требовать решать задачу провальным способом, и опытный пошлет его куда подальше, потому как знает, что получится говно и спрашивать будут с него. Невменяемый тимлид, который не слышит команду - это печально в любом случае.
Другое дело, если фрилансер уверен, что именно он все знает лучше всех и никакие аргументы не работают, ибо он "звезда", который зашибал огромное бабло, пока неудачники из команды "работали на дядю". Тогда будут проблемы.
Пробовал через терминал поменять ориентацию командой "xrandr -o normal", но выдаёт "Can't open display".
Разумеется, откуда ему знать какие вы иксы имеете ввиду. Укажите нужный через переменную DISPLAY, если, конечно, не грузится только DE, а не иксы падают.
Или ищите в настройках DE, где это указывается.
nevidimka110011, добавлю, что, там где используют Oracle, как правило активно пользуются PL. Но надо понимать, что это не язык общего назначения, он специализирован на базах данных. Безусловно в него что только не засунули, начиная от отправки почты заканчивая веб-разработкой (для этого потребуется отдельная система APEX - свой вебсервер и фреймворк). Сам Oracle очень дорогое удовольствие, но и специалисты дорогие.
А что не получается? Проверяйте, отправляйте.
В ReactPHP есть возможность зарегистрировать функции для асинхронного выполнения с указанием интервала проверки. Используйте этот функционал.
order_worker_statuses.order_id -> orders.id
orders.order_worker_status_id -> order_worker_statuses.id
Таблицы связаны перекрестно друг с другом. Непонятно зачем нужны такие связи.
weranda, первая схема выглядит ошибочной, перекрестные ссылки - это ужас. И зачем разбивать связь один к одному на 2 таблицы? Для этого должно быть какое-то обоснование, не вижу такой необходимости.
Из вашего описания статусы должны выглядеть так:
Новый
В работе
Проверка менеджером
Проверка руководителем
Готово
По этим статусам заказ идет последовательно. Плюс статусы для нестандартных ситуаций, например "Брак".
В этом случае у заказа всегда будет только 1 статус. В вашем варианте, для проверок нужно будет делать подстатусы, а значит дополнительные условия в коде, и усложнение всего workflow.
В основном безопасники занимаются бумажной работой, регламенты, соблюдение законов и т.п.
Есть довольно редкие случаи, когда они ищут уязвимости, здесь нужно хорошо знать языки программирования, но в ином аспекте нежели разработчикам. И кстати, это довольно монотонный труд, примерно такой же как у тестировщиков, с разницей, что идет перебор на устойчивость к известным уязвимостям. И уж точно, не идет речи о креативе в поиске новых способов взлома, даже в компаниях "белых хакеров", разве что, может быть в органах гос.безопасности. Поэтому причем здесь Computer Sience? Или "настоящее ООП"? Разработка здесь вообще не причем. Не нужно изобретать градиентный бустинг, наплевать какое ООП правильное, важно знать как тот или иной код можно использовать не по назначению. Равно как и системное администрирование, безусловно знать нужно и сети, и различные продукты, но ровно в той плоскости, которая требуется для взлома. Как минимум, генерация запросов вручную, с подменой необходимых параметров. Как максимум, знание уязвимостей различного ПО по версиям и умение их эксплуатировать.
Но все перечисленное встречается исключительно редко, а в общем случае - смотрите первое предложение.
Sinus_314, толстые контроллеры - это не антипатерн, это ошибка при использовании MVC. Просто потому, что это рушит весь смысл MVC. И да, вы можете не использовать MVC, и когда пользовательские запросы приходят одинаково, обработка их одинакова, а вывод тоже всегда один и тот же, то проблем не будет.
Yurii Diduk, я больше не про технологии, а про процесс CD, как он проходит, что и как делается, что автоматически, что нет. Что делает указанный пайплайн и т.п.
Прочитать можно в доке GitHub. Сейчас глянул туда, вероятно лучше это реализовать через status checks. Вероятно - потому как все равно не понятно, что конкретно делает пайплайн и какое у него место в деплое.
Расскажите, как у вас устроен CD, и CI если есть связь.
Если имелось ввиду просто, чтобы нельзя было смержишь пулрек, если не отработали, к примеру, тесты. То достаточно сделать Jenkins обязательным ревьюером и пусть он ставит апрув или не апрув по результатам проверок.
Антон Швец, в гите нужно хранить исходники. То что разное на разных машинах - это не исходники. Сделаете вы то, что хотите через хук или гитигнор - безразницы, вы нарушите работу проекта. Т.к. получится что в гите у вас набор кода, который не соответствует тому, что вы разворачиваете. Как вы будете что-то разрабатывать и тестировать, если код везде различается?
Роми, в ARPANet использовался протокол IP, прямого отношения к протоколу ARP нет, просто похожие абревиатуры. Основные запросы ARP это чтото вроде "Кто знает ethernet-адрес для такого-то IP?", он организовывает связку ethernet-протоколоа и IP-протокола.
В принципе внутри локальной сети можно использовать любой протокол для адресации, хоть свой придумайте, главное чтобы ОС внутри сети понимали его. Разве что коммутаторы сейчас все умные, и разбирают пакет на уровне ethernet-протокола, простых повторителей уже наверное не найти.
Ethernet-протокола достаточно, чтобы адресоваться внутри сети, т.к. есть адрес отправителя, и есть адрес получателя. Но даже локальные сети обычно сегментированы, неговоря уже про интернет. Между сегментами стоят шлюзы, и вот тут нужен IP протокол, чтобы не слать пакет во все сегменты, мы определяем нужный по подсети протокола IP. Формируя пакет в нем указываем IP адрес целевой машины, а вот ethernet-адрес будет машины-шлюза. Коммутаторы опираясь на ethernet-адрес прокинут этот пакет до машины-шлюза. А она уже ориентируясь на IP-адрес отправит пакет в нужный сегмент сети и назначит уже другой целевой ethernet-адрес пакету, соответствующий нужной машине.
Разумеется это все может быть гораздо сложнее, но главное что все завязано на протокол IP. И выбирать можно только между IPv4 и IPv6 (там где он поддерживается).
С DNS все проще, соответствие доменного имени конкретному ip вы можете брать хоть из файлика. Но что у Васи в интернете есть домен page1.vasya.ru может оказаться знает только DNS который установлен у Васи. DNS "точки" знает где искать DNS сегмента ru, DNS ru знает где искать vasya.ru. Поэтому опять же придется взаимодействовать через глобальные DNS (разумеется обычно это все кешируется), либо напрямую запрашивать Васин DNS.
Тимур Мамедов, вам нужно не данные подбирать, а написать код так, чтобы он не ломался при любых данных, даже если делаете проект только для себя. Используйте подготавливыемые запросы, там все проще, чем кажется.
Так уже точно не будет работать. Я имел ввиду, что в переменной description присутствует кавычка, это и нарушает синтаксис выражения. Посмотрите на ваш запрос после подстановки переменных и все станет понятно.
Ещё раз, используйте подготавливыемые запросы, это решит вашу проблему, а заодно даст защиту от sql-инъекций.
Проанализируйте сетевые пакеты, кто кому и что отправляет в каждом из случаев. Думаю, станет понятно где проблема.
Тупо, навскидку, ваш сервер обрабатывает, только get запросы, что вы видите в браузере, но не обрабатывает post, а передача данных скорее всего идёт через него. А может версия http или ещё что. И что значит не видит? Какая именно ошибка?
Roman Kitaev, да, резонно, хотя охлаждение более актуально для игр, там действительно это проблема. Для разработки, тем более, когда не нужно собирать и компилировать что-то тяжёлое это уже не так актуально.
Посмотрел сейчас недорогую msi, там seq read около 2Гб. В играх, когда при старте заканчивается большое кол-во последовательные данных 3Гб вероятно будет шустрее. Но при разработке вряд ли чем-то поможет.
Тут "как пример" не вариант, разумеется у маков хорошее железо, но и цена не низкая. Поэтому не факт, что это оптимальный вариант по цене качеству.
И все очень сильно зависит от задач. Для разработчика крайне важна оперативка, 16Гб уже маловато. Терпимо, но я бы брал больше. Разумеется для того, кто пишет не в нотпаде, и вагранты или виртуалки для него норма. Проц мощнейший не обязателен, ну не собирает фронтендер код из исходников, компиляция ts в js не в счёт, нет тяжёлых вычислений. Быстрый ssd всегда хорошо, но я бы смотрел на random read, это будет полезнее, для той же индексации в Storm.
Это лишь мой взгляд, но знаю, что у каждого фронтендера обязательно должен быть мак.
Roman Kitaev, экран каждый выбирает по душе. По мне, классная матрица, но 13 дюймов, очень маленький экран. Тачпад важен тому, кто не пользуется мышью. Алюминиевый корпус это понтово, но к решению задач, обозначенных автором не имеет отношения. Ssd в 3Гб это прекрасно, но не уверен, что все модели оборудованы им, не увидел у Apple такого описания, равно как и у других брендов. Кроме того, а зачем автору 3Гбс в seq read? Где ему ежедневно понадобится высокая скорость последовательного чтения? Тут уместнее смотреть random read.
А вот кол-во оперативы гораздо важнее, вариант с 8Гб,который он рассматривает, вообще не вариант для разработки.
Это не отличие именно фрилансера. Любой специалист может столкнуться с ситуаций, когда тимлид будет требовать решать задачу провальным способом, и опытный пошлет его куда подальше, потому как знает, что получится говно и спрашивать будут с него. Невменяемый тимлид, который не слышит команду - это печально в любом случае.
Другое дело, если фрилансер уверен, что именно он все знает лучше всех и никакие аргументы не работают, ибо он "звезда", который зашибал огромное бабло, пока неудачники из команды "работали на дядю". Тогда будут проблемы.