Pull to refresh
63
0
Сева Родионов @Jabher

Джаваскрипт-шалун

Send message

купил, а зачем — не знаю, поэтому вообще не страшно, что задержка произошла :) как придет — тогда и буду играться

может, github codespaces/gitlab ide поможет?
ну или https://gitpod.io/

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

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


WAF стоит ставить, если есть понимание, что кодовая база крайне низкокачественная, и быстро исправить ее нельзя.

У Dashlane (менеджера паролей) есть такая функциональность — еще один приватный ключ регистрируется, файл с паролями отдается, если ты не заходил фиксированное время (3-6-12 месяцев)

А можно ли это решение установить on-premise? Или оно только в SaaS-режиме может работать?

Я про свой опыт говорил, не автора.

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


  1. Релокейшн. Стоимость релокейшна, как мне показалось, чудовищно раздута в том числе в целях удержания сотрудников.
    Мне не предоставили (или я сам не нашел) точную разбивку, но интереса ради я просуммировал розничные цены на все, что было предоставлено (отель, риэлтор, перевоз вещей, денежные бонусы), и суммарная стоимость была меньше. Не хочу думать плохое про разные откатные схемы, поэтому просто не буду строить теории, как такое может быть.


  2. Уровень дохода. Да, ниже. Да, теоретически с опционами становится рыночной. Да, есть велком-бонус, которым можно компенсировать почти до среднерыночных. Но бонус точно так же выдается долгом на год, иначе говоря — получаешь почти рыночную зарплату только если пробудешь в компании год. Иначе — сильно ниже рынка. + на 2-3 год получаешь ниже, т.к. объем вестящихся RSU не такой большой (возможно, по кадровой модели если ты просидел год, ты достаточно лоялен, чтобы получать ниже рынка).


  3. Нежелание нести ответственность.Это есть и у менеджеров тоже.
    Как мне кажется, уши у этой модели растут от системы фидбека. Люди привыкли жаловаться в фидбечницу. Часто. Любая вещь, которая их не устраивает или просто задевает, улетает в фидбечницу. В том числе на базе фидбечницы ставятся оценки, включая эмоциональный фидбек. Разбор ситуации и "кто прав" особо не проводится, главное — чтобы всем, а точнее тем, кто успел первым пожаловаться в фидбечницу, было комфортно. Как человек, который сидел на калибровках — видел такое своими глазами в исполнении многих людей. К сожалению, критическое мышление начал включать позже, чем стоило, и брал на веру услышанное на них.
    Тут могу быть предупрежденным, потому что видел это в рамках одного юнита (группы проектов).


  4. Активная жизненная позиция — ее возможность сильно зависит от команды.
    Во многих местах хорошие начинания глохнут, как в болоте, из-за общей инертности команд. Где-то — протолкнуть можно. "На-ура" — принимают редко.
    Тут могу быть тоже предупрежденным, по тем же причинам.


trunk-driven в многих ипостасях на самом деле имеет ответ, как делать — "закоммиттил, создал свой PR, отсмотрел хотя бы один-два, начал делать дальше". Эдакие помидорки, но из кода.

Монорепозиторий !== микросервисы.
Вот вообще ни разу не равно.
В моем случае — есть 3 разных фронтэнд-проекта, использующих общую кодовую базу. Они имеют разный жизненный цикл и должны деплоиться по-разному, но при этом больше чем наполовину имеют общий код.
И отлаживать этот общий код в отдельных репозиториях было бы безумием чуть более, чем полностью.

через cherry pick, в статье же написал. Либо заново имплементируют, если прям несовместимые изменения, но тут очевидно и так.


Ну и да, очень сложно аргументировать, когда твои аргументы не смотрят даже.

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

Объем кода-то тот же. Более того, смотреть отдельные изменения проще, чем одно большое разом. Если у вас отсмотр 10 PR на 100 строк занимает сильно больше времени, чем одного на 1000, значит, у вас хреново построен процесс отсмотра PR-ов.

ОК, а что вы делаете в такой ситуации?


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

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


Тут есть две стратегии, обе не идеальны, это либо cherry-pick из мастер-ветки в релиз, либо двойной PR в мастер-ветку и в релиз-ветку.

Да, это так. В этом и смысл TBD в целом — он призывает делать максимально атомарные изменения. Добавил метод, создал класс, удалил класс. Шансы конфликтов резко падают.
Мне больше всего нравится объяснение его в этом выступлении — https://www.youtube.com/watch?v=hIW5ynk8HWc.

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

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


К монорепе и декомпозиции, кажется, рано или поздно приходят почти все (а если не пришли — надо просто подождать лет пять), поэтому подстраховаться будет не лишним, но если не очень хочется, можно жить с этим, держа в уме, что при появлении второго репозитория и потребности в оркестрации параллельных релизов GitFlow сломается и будет дергаться в конвульсиях.


Длинные ветки не проблема, если в команде 3 человека, работающие над разными частями. Если команда начала раздуваться — пора переходить на короткоживущие.


Я же как раз ровно об этом пишу.

На всякий случай: это не моя позиция, а просто анализ ситуации.


насколько я понимаю (но я не бухгалтер), уход в декрет — это принуждение работодателя выплачивать как минимум 5 зарплат и невозможность уволить даже после этих выплат, то есть нельзя просто взять и даже отдав эти деньги нанять кого-то другого, что критично, если для этой конкретной должности есть только одна позиция, и нет смысла ее растить — придется свеженанятого сотрудника увольнять (или работать по ГПХ и иметь риски с налоговой). Но я могу не разбираться в бухгалтерии и вообще неправильно трактовать это все.


Но если я правильно понимаю: девушка-айтишница за 150к это риск в 1.3 млн рублей минимум в глазах нанимателя.

сработает — если именно f8 нажать, а не тащить мышь к дебаггеру, все ок

А от атак browser-in-the-middle это решение не защищает вообще?

Information

Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Date of birth
Registered
Activity