• Почему медленно открываются сайты через mikrotik с Wireguard?

    @elexterem
    1 ) Вариант
    Попробуй это. Мне помогло.
    /ip firewall mangle 
    add action=change-mss chain=forward new-mss=clamp-to-pmtu out-interface=wireguard protocol=tcp tcp-flags=syn

    Это правило корректирует размер mss
    Если у тебя есть правило fasttrack, то отруби его и перезагрузи роутер

    2) Второй вариант если не поможет первый Как определить оптимальный размер MTU?
    Ответ написан
    3 комментария
  • Как улучшить качество декомпозиции в Go?

    mayton2019
    @mayton2019
    Bigdata Engineer
    неприлично долго думаю над тем что нужно вынеси в отдельный пакет, а что достаточно вынести в отдельную структуру


    Такая-же проблема и у меня. Я тоже долго думаю над дизайном. Но суть в том что в большинстве задач
    ты и бизнес не всегда знаете куда пойдет проект дальше. И поэтому нарисовать идельный дизайн нельзя.
    Я-бы даже сказал что попытка сопровождать идеальный дизайн - может затянуть внедрение проекта.

    Поэтому просто откажись от декомпозиции. Пиши сначала прототип в олимпиадном стиле. Тоесть функция
    main - и погнал писать как чукча. Что вижу то и пою.

    И после того как ты напишешь 1000 строк например к тебе придет понимание как следует декомпозировать.
    И к этому моменту у тебя будут ДОКАЗАТЕЛЬСТВА выгодности твоего дизана. И теоретические споры можно
    уже исключить.
    Ответ написан
    1 комментарий
  • Можно ли как либо защитить php-проект от "угона" другим наёмным программистом (фрилансером)?

    @Shavadrius
    Как по мне не имеет большого смысла. Если ключевое "ноу-хау" в самой идее, то ее можно понять просто имея доступ к интерфейсу приложения. Если вся суть в каких-то хитрых алгоритмах, пайплайнах или расчетах - то их можно скрыть за микросервисом, как тут отмечали ранее.
    Больше влияет рейтинг, клиентура, реклама, продвижение, собственно, бренд. Аналогов всего и вся сотни, но знакомы многие только с единицами.
    Ответ написан
    1 комментарий
  • Как фильтровать нецензурную лексику в telegram боте?

    mayton2019
    @mayton2019
    Bigdata Engineer
    Опыт модерирования форумов рунета подсказывает что это все бесполезно.
    В русском языке очень много способом ругаться завуалированно. Посылать стихотворные формы.
    Метафоры. Можно печатать через пробел. Заменять кириллицу на похожие по начертанию
    Unicode символы. Печатать псевдографикой.

    Вобщем фильтрацией мата обычно занимаются админы канала. Более того. Если вы вводите
    интеллект который видоизменяет сообщения - то часть пользователей уйдут с канала. Эти
    либералы будут считать что у них есть свобода печати текста а вы - цензурите в авто-режиме.
    И есть мамкины хакеры которые будут день и ночь хачить ваш фильр мата и они его будут в конце
    побеждать. Потому что это борьба снаряда и брони - бесконечна. А вы - устанете вводить новые
    правила.
    Ответ написан
    Комментировать
  • Почему нельзя/можно писать бизнес-логику в sql?

    ThunderCat
    @ThunderCat
    {PHP, MySql, HTML, JS, CSS} developer
    Когда в руках молоток, все вокруг становится похожим на гвоздь... Если вы хорошо разбираетесь в языках запросов, это не говорит о том что это распространенный навык.
    Самый простой аргумент - посмотрите на рынок, много ли движков, построенных на бд/sql?
    Много ли специалистов по бд вообще на рынке труда?
    Кто из них разрабатывал логику на стороне бд?
    Кроме того, слои яп-бд можно разнести на разные инстансы, что сильно распределит нагрузку, а бд сама по себе умеет в пожрать ресурсы...

    Можно долго перечислять плюсы и минусы. Смысл в том что если вы будете разрабатывать это сами или для себя и вы уверены в собственной способности построить всю логику на одной технологии- флаг в руки, это будет оригинальным решением, вполне возможно даже что найдутся ценители.
    Если же проект для заказчика, и в разработке будут участвовать 2+ людей, то тут то вы хапнете проблем большой ложкой. Найти спецов которые прям пишут логику на скуеле, чтобы они стоили приемлемых денег, завтра не ушли в другой проект так как тут надо делать кучу непрофильных дел: как-то делить задачи, вести версионирование, не пересекаться с другими задачами функционалом... проще пойти в нормальную контору, где от дбшника требуют только структуру, пару триггеров и он там один отвечает за бд, так как больше не нужно и ни с кем из коллег не надо 10 раз утверждать изменения в структуре/процедурах/етц. Короче это не специфично и мало кто захочет все это изучать с новой стороны. Про поддержку такого чуда я вообще молчу.

    Это еще не учитывая того что в проекте все равно понадобится пара программистов на каком-то ЯП, для формирования отображения и какой-то прослойки между пользователем и бд, которые должны будут разобраться с этим зоопарком наоборот.
    Ответ написан
    4 комментария
  • Почему нельзя/можно писать бизнес-логику в sql?

    mayton2019
    @mayton2019
    Bigdata Engineer
    Можно. Весь 20-й век почти так делали. База была главной. Эдакая себе царица. Ее любили. Холили.
    Приложения были двухзвенки. Оконная апликуха коннектилась к базе и все расчеты
    проводились в базе. Апликуха только показывала результаты в гридах и вводила формочки.
    Джобы тоже запускались в базе как процедуры на PL/SQL по скедулеру. Для пуска их клиент
    был тоже не нужен. Плановые задачи БД запускала самостоятельно. Это и было видение
    бизнес логики из 20-го века.

    В 21-м веке с развитием веба появился слой middle. И разработчики вынесли в него максимальную
    часть логики. Это произошло естественным путем. А базе досталась участь быть просто хранилищем
    таблиц. Потому что держать 2 копии логики или поддерживать было уже неудобно. В команде
    должен быть тогда разработчик и Java и PL/SQL одновременно. В современной парадигме
    разработки с ORM база стала просто чем-то вторичным. И на уровне ORM абстракций
    даже заменяемым на другие типы баз.

    Но не все так плохо.

    Фактически, логика современного приложения размазана по 3м слоям. Даже в браузере
    есть какая-то минимальная логика, например при аутентификации или при проверке
    валидности емейла. И какая-то логика агрегации (sum/group by) полюбому есть в базе.
    Потому что агрегировать в приложении все - глупо. Это лишний трафик.

    И нет такого архитектора который говорит "нельзя". Просто есть best-practices современной разработки,
    исходя из развитя железа, сетей и вообще рынка всего остального. Кто знает может в мобилах вернуться
    к двузвенкам. Смотря под каким углом смотреть на современные мобильные приложения? Who knows.
    Ответ написан
    2 комментария
  • Как корректно изменить DNS запись для сервера при миграции на другой хост?

    @Drno
    на старом - запускаешь реверс прокси с редиректом на новый сервер. можно банально порт с помощью IPTABLES перенаправить
    меняешь запись DNS
    через 2 дня отключаешь старый
    Ответ написан
    Комментировать
  • Чем деплоиться на bare metal?

    saboteur_kiev
    @saboteur_kiev
    software engineer
    Да все пишется скриптами.
    Любой инструмент, который может подключиться по ssh или имеет свой агент.
    Начиная от дженкинс/ансибл и заканчиваая какими-нить ентерпрайзными IBM uDeploy/Octopus

    Нужно понимать, что bare metal или просто виртуалки не умеют откатываться автоматически - им просто руками нужно прописать откат, а для этого во время деплоя просто делать бэкап (fs snapshot, tar.gz, или версионирование как сам придумаешь).

    В подавляющем большинстве случаев, проблема отката больше с тем как базу назад откатить.
    Ответ написан
    Комментировать
  • Можно ли одновременно запустить вторую ОС с внешнего диска?

    @pfg21
    ex-турист
    "внутрь" виртуалбокса можно пробросить "железный" носитель.
    https://www.virtualbox.org/manual/ch09.html#rawdisk
    Ответ написан
    Комментировать
  • Какие лучшие proxy сервера c ipv4 для соединения с Японией?

    Скорость света в вакууме 300,000 км/с, расстояние до Японии от Москвы по поверхности земли примерно 7500 км или 15000 км туда и обратно, что дает 50мс задержки. С учетом коэффициента преломления оптоволокна (порядка 1,5) - 75мс. Можно немного сократить, если пробурить канал напрямую вглубь земли и передавать световым пучком в вакууме без оптоволокна.

    Но вместе с пингом 40мс вы все равно получите Нобелевскую премию по физике.

    На самом деле каналов по прямой до Японии нет, данные идут достаточно сложным маршрутом и не в вакууме и 300мс это более-менее ожидаемый результат. Типичный маршрут для российских провайдеров - Европа - Северная Африка/Средний восток - Юго-восточная Азия - Япония. Можно поискать провайдера у которого есть пиринг с азиатскими IX минуя Европу, чтобы маршрут был "прямее", вы можете получить задержки. скажем, вдвое меньше. Прокси может быть найти сложнее, т.к. надо чтобы был прямой трафик до прокси и от прокси. Имеет смысл посмотреть в точки где может быть пиринг с европейской Россией и Азией, например наш дальний восток или Казахстан. Прокси в Японии скорей всего никакого преимущества не даст, нужен прокси где-то, куда есть более-менее прямой канал от вашего провайдера и откуда есть прямой канал на пиринги в Азии.
    Если хотите маленький пинг - вам надо клиентский софт располагать в Японии (возможно вместе с сотрудником), а не прокси-сервер. Для высокочастотного трейдинга его располагают не просто в той же стране, где биржа, но и как можно ближе у того же провайдера или на самой бирже.
    Ответ написан
    1 комментарий
  • В каких случаях надо использовать kubernetes, а в каких mesos, docker swarm?

    firedragon
    @firedragon
    Не джун-мидл-сеньор, а трус-балбес-бывалый.
    Есть такой анекдот:
    Когда в руках молоток, все вокруг превращается в гвозди.

    Если умеете docker swarm используйте его, даже если есть модные молодежные тулзы.
    Вы стандартизируете инструменты в пределах компании и нарабатываете опыт. Переход же на другой инструмент стоит денег, и размывает ваши силы и компетенции.
    Ответ написан
    Комментировать
  • Как тестировать и разрабатывать без продуктовых данных?

    vasilyevmn
    @vasilyevmn
    DevOps
    Нужно обезличить данные.
    Почитайте тут https://habr.com/ru/company/technoserv/blog/490740/
    Ответ написан
    Комментировать
  • FIFO-пайпы и Unix Sockets?

    @shuraosipov
    pipe - это механизм коммуникации между процессами. pipe, как уже было сказано выше, является однонаправленным потоком данных, все данные, записанные процессом в пайп перенаправляются ядром другому процессу для чтения.
    pipe это объект VFS (Virtual File System), поэтому pipe не имеет соответсвутющего образа на диске, грубо говоря он хранится в памяти (pipefs).
    Главным недостатком pipe является тот факт, что невозможно открыть уже существующий pipe. Поэтому два произвольных процесса не могут использовать одновременно один и тот же pipe, за исключением случаев если pipe был создан общим родительским процессом.

    fifo (named pipe) - это специальный файл, очень похожий на pipe, за исключением того, что fifo inode содержится в файловой системе, плюс fifo это двунаправленный механизм обмена данными между двумя и более процессами, поэтому доступ к fifo на чтение и запись может получить любой процесс. Грубо говоря процесс общения с использованием fifo выглядит следующим образом - "сервер" создает fifo файл, который успользуется "клиентами" для выполнения запросов. Каждый "клиент", прежде чем установить соединение с "сервером", создает другой fifo файл, в который "сервер" может записать ответ клиенту, при это указывая имя fifo в изначальном запросе.

    socket (unix socket) - это специальный файл, используемый для коммуникации между двумя и более различными процессами, выполняющимися на одной машине. Процессы обращаются к socket по его inode.

    Итак в чем же отличие fifo (named pipe) от unix socket:
    1. "Сервер" (или принимающий процесс) в fifo не умеет различать "Клиентов".
    "Клиенты", использующие unix socket имеют отдельные соединения с сервером. В fifo различные "клиенты" могут писать в pipe, но "Сервер" не может различить "Клиентов" друг от друга.
    2. При создании fifo и unix socket используются различные системные вызовы.
    Unix socket создается системным вызовом "socket()". fifo создается "mkfifo()"
    3. Для подключения к fifo и unix используюся различные системные вызовы.

    Сравнение по производительности - fifo vs unix socket:
    1. unix socket обеспечивает лучшую производительнось при передаче большого объема данных
    2. для малых объемов unix socket уступает в производительности fifo. это вызвано накладными раскодами, связанными с созданием сокета, инициализацией и подключением к нему.
    Ответ написан
    Комментировать
  • Wordpress в docker, хорошая ли мысль?

    mihdan
    @mihdan
    WordPress-евангелист, ведущий РНР - разработчик
    Несколько лет используем докеры для разворачивания сайтов на WordPress - просто, понятно, удобно и в песочнице и самое главное окружение локальное, тестовое и продуктовое полностью совпадает.

    Деплой отлично строится автоматически на основе GitHub + TravisCI.

    Нет поганой виртуализации как при испльзовании Vagrant, нет зависимостей от Virtualbox.

    Вижу только плюсы.
    Ответ написан
    6 комментариев
  • В чем проблема ошибки "read error on connection" в Redis?

    egor_nullptr
    @egor_nullptr
    Дело в том, что когда Redis занимается сохранением дампа на диск он не реагирует на внешние воздействия. Где-то в issues на github можно отыскать подробное описание. Проблема кроется в системном вызове fsync, приёме copy-on-write в OS, и волшебном сочетании этого в Redis. Выход и решение: завести slave для Redis, на котором и делать периодический дамп (опция save), а на master-е отключить save вообще.
    Ответ написан
    7 комментариев
  • Как в VueJS в цикле v-for выполнить один раз?

    Ni55aN
    @Ni55aN
    Если стиль статический, то можно в CSS определить его как класс с :first-child
    Ответ написан
    Комментировать
  • Как ускорить mysql запрос с JOIN LEFT?

    Rsa97
    @Rsa97
    Для правильного вопроса надо знать половину ответа
    Для начала - записать запрос понагляднее. В условиях ON записать поля присоединяемой таблицы в левых частях сравнений:
    SELECT * 
      FROM `tbl_1` 
      LEFT JOIN `tbl_2` ON `tbl_2`.`id_fp` = `tbl_1`.`foto_id` AND `tbl_2`.`sklad` = 'Склад' 
      WHERE (deleted="no" AND `where`="arh")  AND (`type`="Cloth" ) 
      ORDER BY `foto_id` ASC 
      LIMIT 9447,20;

    Теперь видно, что для ускорения JOIN'а стоит сделать в таблице `tbl_2` составной индекс (`id_fp`, `sklad`).
    Затем надо смотреть EXPLAIN и, возможно, переносить условия из WHERE в предварительную выборку из `tbl_1`.
    Но, если к одной строке из `tbl_1` присоединяется несколько строки из `tbl_2`, то ORDER BY и LIMIT надо оставить снаружи.
    SELECT * 
      FROM (
        SELECT *
          FROM `tbl_1` 
          WHERE (deleted="no" AND `where`="arh")  AND (`type`="Cloth" ) 
          ORDER BY `foto_id` ASC 
          LIMIT 9447,20
      ) AS `t1`
      LEFT JOIN `tbl_2` ON `tbl_2`.`id_fp` = `t1`.`foto_id` AND `tbl_2`.`sklad` = 'Склад'

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

    sim3x
    @sim3x
    Посмотрите в оферту хостера - когда платили, вы с ней согласились

    Поменяйте ип, и настройте cloudflare
    Ответ написан
    3 комментария
  • Насколько легко взломать сайт на Wordpress?

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

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

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