Для Firefox существует расширения для удобной работы с вкладками - Sidebery. Там и профили вроде бы есть, но ими не пользовался.
А так, на мой личный вкус, что хром, что лиса - оба полное г. Рабочая сессия в хроме + средний проект в IDE уже вызывают затруднения при 16гб озу. В лисе постоянно то с отрисовкой пдф проблемы (при сворачивании иногда начинает полосить черным), то на самоподписанный сертификат не пускает.
Честно говоря, арчем уже не пользуюсь. Это первый дистрибутив Linux, который я поставил (не спрашивайте). Много чего узнал, но несколько таких отвалов после обновлений мне хватило, переехал на Manjaro со стабильными пакетами, с тех пор на ней и сижу.
Согласен. В этом плане мне понравилось как сделали JetBrains для своих IDE (понятно, что такое не только у них есть). Прилетело обнова с новым UI, сразу была возможность выключить (или было выключено и предложили включить, не помню). Но в настройках точно есть пункт переключения верисии интерфейса.
Синтаксически мы стали еще немного ближе к Kotlin. В связи с этим, интересно, через многие десятки версий, сотни ошибок, и тысячу новых идей, могут ли языки прийти к одинаковому синтаксису, но разной подкапотной реализацией (для разных задач) или нет?
Да. Проблема возникла с тем, что сортировка происходит в 2 режимах: строк и целых чисел. Я не работал с дженериками раньше и свести задачу к дженерик сортировке у меня не вышло. Тем не менее, профайлер поведал мне, что непосредственно сортировка занимает менее 60% времени.
Еще интересно, что BufferedReader, видимо, работает не так, как я предполагал. При слиянии временных отсортированных файлов у меня были открыты эти ридеры в обертках (класс по методу getNext просто выдает следующий элемент на запись среди всех временных файлов (типо указатели при слиянии)), причем буффер на каждый я выделял на основе свободной озу в рантайме. В обертках я сделал метод peek(), который использовал методы BufferedReader'а mark, readline и reset (по сути откатиться после прочтения) и это занимало очень много времени при слиянии. Затем я просто добавил поле "кэша" в обертку, чтобы снова не вызывать методы ридера при peek() и pop(), а брать из поля и время метода уменьшилось В 10 РАЗ. Это странно, тк в доках написано, что системных вызовов быть не должно, но, видимо, что то там все же есть.
Забавно, что я буквально вчера отправил тестовое на схожую тему (сортировка слиянием файлов, которые не влезают в озу, без ограничения по времени правда), но не на сеньера и даже не на стажера, а в качестве студента на курсы при одной крупной конторе. (12Гб файл со включенным профайлером прошел за 13 минут)
Для Firefox существует расширения для удобной работы с вкладками - Sidebery. Там и профили вроде бы есть, но ими не пользовался.
А так, на мой личный вкус, что хром, что лиса - оба полное г. Рабочая сессия в хроме + средний проект в IDE уже вызывают затруднения при 16гб озу.
В лисе постоянно то с отрисовкой пдф проблемы (при сворачивании иногда начинает полосить черным), то на самоподписанный сертификат не пускает.
Скоро реально на lynx перейду.
Честно говоря, арчем уже не пользуюсь. Это первый дистрибутив Linux, который я поставил (не спрашивайте). Много чего узнал, но несколько таких отвалов после обновлений мне хватило, переехал на Manjaro со стабильными пакетами, с тех пор на ней и сижу.
Когда сидишь на арч, вводишь sudo pacman -Syu и молишься, чтобы не отвалилась жопа)
I use arch, btw
Было бы интересно увидеть статью про более подробный процесс издания книги.
Согласен. В этом плане мне понравилось как сделали JetBrains для своих IDE (понятно, что такое не только у них есть). Прилетело обнова с новым UI, сразу была возможность выключить (или было выключено и предложили включить, не помню). Но в настройках точно есть пункт переключения верисии интерфейса.
Синтаксически мы стали еще немного ближе к Kotlin. В связи с этим, интересно, через многие десятки версий, сотни ошибок, и тысячу новых идей, могут ли языки прийти к одинаковому синтаксису, но разной подкапотной реализацией (для разных задач) или нет?
Есть еще double shift - поиск по всему (файлы, настройки, комамнды IDE, Git и тд)
Короче задачу, видимо, можно настолько сильно развить, что она от уровня стажера перейдет на уровнь сеньера, все зависит только от ее интерпретации))
Да. Проблема возникла с тем, что сортировка происходит в 2 режимах: строк и целых чисел. Я не работал с дженериками раньше и свести задачу к дженерик сортировке у меня не вышло. Тем не менее, профайлер поведал мне, что непосредственно сортировка занимает менее 60% времени.
Еще интересно, что BufferedReader, видимо, работает не так, как я предполагал. При слиянии временных отсортированных файлов у меня были открыты эти ридеры в обертках (класс по методу getNext просто выдает следующий элемент на запись среди всех временных файлов (типо указатели при слиянии)), причем буффер на каждый я выделял на основе свободной озу в рантайме. В обертках я сделал метод peek(), который использовал методы BufferedReader'а mark, readline и reset (по сути откатиться после прочтения) и это занимало очень много времени при слиянии. Затем я просто добавил поле "кэша" в обертку, чтобы снова не вызывать методы ридера при peek() и pop(), а брать из поля и время метода уменьшилось В 10 РАЗ.
Это странно, тк в доках написано, что системных вызовов быть не должно, но, видимо, что то там все же есть.
Разумеется: https://github.com/scroogemcfawk/cft-shift-java-test-task
Сортировку сделал однопоточной, в условии ничего про производительность не было сказано, разве что файлы могут целиком не влезать в озу.
Забавно, что я буквально вчера отправил тестовое на схожую тему (сортировка слиянием файлов, которые не влезают в озу, без ограничения по времени правда), но не на сеньера и даже не на стажера, а в качестве студента на курсы при одной крупной конторе. (12Гб файл со включенным профайлером прошел за 13 минут)