Ага. Больная тема. Недавно бился над кодом на js, который в начале октября час в сутки падал на тестах.
При том, что я JS не знаю, а начало октября- не самое очевидное время для падения- было весело. Оказалось, что прокралась автралийская таймзона- там как раз на зиму переход уже был :D
Просто надо мержить ветку сразу. Тогда можно переключатся с вида «все изменения» на «по коммитам»- как удобнее. И тогда несколько коммитов всегда лучше одного.
Такой путь плохо поддерживается в gerrit. Но это проблема gerrit'а.
Возможны два варианта:
1. Ничего не восстановить, расчёт на лоха.
2. После оплаты надо что-от отправить на почту, чтобы получить персональный ключ.
В прошлых вариантах шифровальщиков встречался второй вариант, тут (или на хабре) были статьи.
Никак. Он шифрует файлы парой несимметричным ключём.
Если авторы вируса реально расшифровыают файлы- то они присылают пару к ключу шифрования.
Если всё сделано правильно- то никакой антивирус (и вообще никто) не поможет, а вымогатели- помогут.
Если речь про JMC — то ещё возможность семплирования (но работает только в safe-points, а это недостоверно).
Если про EMT — то GC-root как-то лучше работает (в visualVM оно то ли не работает, то ли неработоспособно). Но памяти этот зверь кушает- очень хорошо.
PS: apangin вроде как делал своё семплирование, которое работает вне safe-point — но всё ссылку на утилитку не могу найти. Подскажите, кто помнит, пожалуйста :)
Статья в стиле «чтобы нарисовать кошку надо нарисовать кружок, потом треугольники ушей, несколько сосисок- лап, а потом дорировать кошку».
Чтобы искать утечку памяти надо глубоко понимать программу, в которой утечки ищутся. Чтобы заметить странность. А как её видеть- объяснить сложно. Временами методика поиска напоминает анекдот про апельсин.
Для понимания, какая «преждевременная» оптимизация есть зло, какая благо- надо посмотреть лекцию Шипилёва с joker-2016 (да, доступна пока только тем, кто покупал билет, но будет вроде и публичной) — она не про java, по сути.
Там хорошо поделены все они на
зелёную зону — упрощаем код, делая его лучше как с точки зрения читаемости, так и с точки зрения перформанса за счёт использования хороших алгоритмов из стандартных библиотек и т.п.
жёлтую зону — когда пишется понятный, но многословный код для повышения производительности
красную зону — грязные хаки, использование непубличного API и обход багов платформы.
Если оптимизация из зелёной зоны- она хороша всегда. И никогда не будет преждевременной. Убрать лишние абстракции, странные наследования, использовать оптимизированную библиотеку вместо самописного костыля (или просто заменить библиотеку от apache на аналог от google) и т.д. и т.п.
Жёлтой- только если иначе нельзя, когда «зелёная» не помогла, а проблемы остались. Это может быть преждевременно.
Красная- «если Вы это читаете, значит Вам этого делать нельзя». Это всегда плохо. Но редко нужно (чем чаще- тем хуже платформа).
Интересно сделать (официальный, велосипеды есть в т.ч. в production) сборщик yang-only.
Т.е. пока в OldGen есть место- живём.
Кончилось вместо fullGC- рестарт.
Вот чего _сильно_ не хватает в gitlab- это возможность писать группу комментириев (как в gerrit).
1. Это полезно, когда читая 10й файл мерж-реквеста понимаешь, что комментарий к первому файлу лучше переписать (или вообще удалить).
2. Когда есть 10 комментариев, то логично получить одно письмо, а не 10 (а то у тимлидов столько сыпется всего, что не поймёшь).
Проблема более глобальная- изначально открытый и стандартизированный интернет заменяется на сборище закрытых приватных сообществ — fb/vk/lj/habr.
И то, что самое популярное сообщество имеет непрозрачную и ненадёжную систему модерирования- проблема хоть и случайная (проблема могла возникнуть в vk, к примеру), но в целом закономерная (где-нибудь это должно было случится).
При том, что я JS не знаю, а начало октября- не самое очевидное время для падения- было весело. Оказалось, что прокралась автралийская таймзона- там как раз на зиму переход уже был :D
Чтобы была подсветка (автовыбор и ручной выбор языка) и «сворачивание» фрагмента.
Кто поддерживает?
Такой путь плохо поддерживается в gerrit. Но это проблема gerrit'а.
1. Ничего не восстановить, расчёт на лоха.
2. После оплаты надо что-от отправить на почту, чтобы получить персональный ключ.
В прошлых вариантах шифровальщиков встречался второй вариант, тут (или на хабре) были статьи.
Если авторы вируса реально расшифровыают файлы- то они присылают пару к ключу шифрования.
Если всё сделано правильно- то никакой антивирус (и вообще никто) не поможет, а вымогатели- помогут.
Если про EMT — то GC-root как-то лучше работает (в visualVM оно то ли не работает, то ли неработоспособно). Но памяти этот зверь кушает- очень хорошо.
PS: apangin вроде как делал своё семплирование, которое работает вне safe-point — но всё ссылку на утилитку не могу найти. Подскажите, кто помнит, пожалуйста :)
Чтобы искать утечку памяти надо глубоко понимать программу, в которой утечки ищутся. Чтобы заметить странность. А как её видеть- объяснить сложно. Временами методика поиска напоминает анекдот про апельсин.
Там хорошо поделены все они на
Если оптимизация из зелёной зоны- она хороша всегда. И никогда не будет преждевременной. Убрать лишние абстракции, странные наследования, использовать оптимизированную библиотеку вместо самописного костыля (или просто заменить библиотеку от apache на аналог от google) и т.д. и т.п.
Жёлтой- только если иначе нельзя, когда «зелёная» не помогла, а проблемы остались. Это может быть преждевременно.
Красная- «если Вы это читаете, значит Вам этого делать нельзя». Это всегда плохо. Но редко нужно (чем чаще- тем хуже платформа).
Т.е. пока в OldGen есть место- живём.
Кончилось вместо fullGC- рестарт.
1. Это полезно, когда читая 10й файл мерж-реквеста понимаешь, что комментарий к первому файлу лучше переписать (или вообще удалить).
2. Когда есть 10 комментариев, то логично получить одно письмо, а не 10 (а то у тимлидов столько сыпется всего, что не поймёшь).
И то, что самое популярное сообщество имеет непрозрачную и ненадёжную систему модерирования- проблема хоть и случайная (проблема могла возникнуть в vk, к примеру), но в целом закономерная (где-нибудь это должно было случится).