45:19 Насколько я знаю, если мы наперед можем предугадать, что ArrayList будет вмещать в себя определеннное количество элементов(или порядок их), то при инициализации мы заранее можем задать размер (capacity) листа, тем самым убирая пересоздание статического массива под капотом и не имея издержек в производительности. Артур Власов - теоритические знания на высшем уровне. Браво!
47:00 Скорее всего в Яве тоже можно реализовать фишку с использованием виртуальной памяти. Когда процесс запрашивает у ОС память через nmap (new, malloc, ...) ОС на самом деле ничего физического не выдает и можно запросить сильно больше чем есть реальной памяти в системе. Т.е. можно условно преаллоцировать памяти под массив "с запасом" (хоть 1 ТБ) но не трогать её (не инициализировать нулями или ещё как) и потом потихоньку писать в неё сколько нужно. По мере записи в массив ОС будет выдавать физические страницы, а сам массив будет оставаться линейным, без необходимости его расширения с копированием. При этом этот виртуальный 1 ТБ памяти никак на систему и другие процессы влиять не будет.
Дублировать код можно, только если не подразумевается масштабирования программы или сервиса. То есть Ваш продукт конечный для потребителя, и в него если и будут вноситься изменения, то только с учетом продублированного т.н. хард-кода. Дублированный код при масштабировании нуждается в дорогостоящем рефакторинге, что невыгодно с точки зрения бизнеса. НО он МОЖЕТ быть иногда выгодным с точки зрения сокращения времени на разработку законченного продукта, где не требуется особо тщательного тестирования, или, допустим, нужно что-то продублировать и затем использовать как метку для дальнейшей работы с кодом ( например, имена сценариев-скриптов использовать как метки, для какой-то уже существующей видеоигры, где по каким-то причинам невозможно эту метку записать в виде отдельного параметра в уже существующий тип объекта или сущности). Поподробнее о тонкостях масштабирования и работы с продублированным не-DRY кодом можете ознакомиться в Интернете.
Очень крутое собеседование! Было познавательно и интересно. Хотелось бы продолжения. Артур Власов -очень позитивный, целеустремлённый парень, который заслуживает успеха и больших достижений.
49:09 Ну про хешмап он не совсем верно ответил, видимо не до конца понимает. Массив линкед-листов это вовсе не хешмап и наоборот. И говоря что "по умолчанию там 16 корзин" надо уточнять что они будут расширяться по мере добавления элементов, а то это какая то бесполезная структрура данных получается, с 16ю корзинами и длинными линкед-листами. Количество ячеек (корзин) хешмапа должно быть чуть больше количества хранимых элементов в нем. Несколько элементов могут попасть в одну корзину только по причине коллизии хеш функции. А что бы определить корзину берется простой остаток от деления.
На Си и С++ сложнее вести редакции, если пишешь под большое количество платформ, включая Debian и Ubuntu Linux, Mac, Windows, Android, iOS (а также игровые платформы PlayStation, XBox, Nintendo, если это игровой проект или какой-то особый интерактив...). А у Java есть большое количество виртуальных машин под разные платформы, которые (машины эти) периодически обновляются с учетом нововышедших спецификаций. Если пишете только для одной-двух платформ, флаг в руки, Си будет более, чем достаточно, особенно если Вы уже набили руку и шишек на этом. Особенно Си хорошо себя зарекомендовал для микроконтроллеров, на нем очень легкие программы можно писать, для Java же нужно еще JVM запустить, что дорого само по себе, плата за универсальность. Но заметьте, что для Си нужно учитывать возможности устройства, далеко не каждая программа на Си пойдет на каком-то конкретном устройстве.
![BLACK BAG - Official Trailer [HD] - Only in Theaters March 14](http://i.ytimg.com/vi/Du0Xp8WX_7I/mqdefault.jpg)
45:19 Насколько я знаю, если мы наперед можем предугадать, что ArrayList будет вмещать в себя определеннное количество элементов(или порядок их), то при инициализации мы заранее можем задать размер (capacity) листа, тем самым убирая пересоздание статического массива под капотом и не имея издержек в производительности.
Артур Власов - теоритические знания на высшем уровне. Браво!
47:00 Скорее всего в Яве тоже можно реализовать фишку с использованием виртуальной памяти. Когда процесс запрашивает у ОС память через nmap (new, malloc, ...) ОС на самом деле ничего физического не выдает и можно запросить сильно больше чем есть реальной памяти в системе. Т.е. можно условно преаллоцировать памяти под массив "с запасом" (хоть 1 ТБ) но не трогать её (не инициализировать нулями или ещё как) и потом потихоньку писать в неё сколько нужно. По мере записи в массив ОС будет выдавать физические страницы, а сам массив будет оставаться линейным, без необходимости его расширения с копированием. При этом этот виртуальный 1 ТБ памяти никак на систему и другие процессы влиять не будет.
1:03:00 это как в DOS (которая старше Linux) код ERRORLEVEL, до сих пор осталось. А в DOS пришло из Unix конечно же.
56:00 а в Java рекомендовали делать выход из двух и более вложенных циклов с помощью специальной метки.
31:30 когда можно дублировать код? Сколько раз встречал дублирование, столько раз от дублирования были проблемы.
Дублировать код можно, только если не подразумевается масштабирования программы или сервиса. То есть Ваш продукт конечный для потребителя, и в него если и будут вноситься изменения, то только с учетом продублированного т.н. хард-кода. Дублированный код при масштабировании нуждается в дорогостоящем рефакторинге, что невыгодно с точки зрения бизнеса. НО он МОЖЕТ быть иногда выгодным с точки зрения сокращения времени на разработку законченного продукта, где не требуется особо тщательного тестирования, или, допустим, нужно что-то продублировать и затем использовать как метку для дальнейшей работы с кодом ( например, имена сценариев-скриптов использовать как метки, для какой-то уже существующей видеоигры, где по каким-то причинам невозможно эту метку записать в виде отдельного параметра в уже существующий тип объекта или сущности). Поподробнее о тонкостях масштабирования и работы с продублированным не-DRY кодом можете ознакомиться в Интернете.
Очень крутое собеседование! Было познавательно и интересно. Хотелось бы продолжения. Артур Власов -очень позитивный, целеустремлённый парень, который заслуживает успеха и больших достижений.
49:09 Ну про хешмап он не совсем верно ответил, видимо не до конца понимает. Массив линкед-листов это вовсе не хешмап и наоборот. И говоря что "по умолчанию там 16 корзин" надо уточнять что они будут расширяться по мере добавления элементов, а то это какая то бесполезная структрура данных получается, с 16ю корзинами и длинными линкед-листами. Количество ячеек (корзин) хешмапа должно быть чуть больше количества хранимых элементов в нем. Несколько элементов могут попасть в одну корзину только по причине коллизии хеш функции. А что бы определить корзину берется простой остаток от деления.
WET - we enjoy typing =)
Write once - debug everywhere (c) :)
Cи работает на большем количестве платформ чем Java.
На Си и С++ сложнее вести редакции, если пишешь под большое количество платформ, включая Debian и Ubuntu Linux, Mac, Windows, Android, iOS (а также игровые платформы PlayStation, XBox, Nintendo, если это игровой проект или какой-то особый интерактив...). А у Java есть большое количество виртуальных машин под разные платформы, которые (машины эти) периодически обновляются с учетом нововышедших спецификаций. Если пишете только для одной-двух платформ, флаг в руки, Си будет более, чем достаточно, особенно если Вы уже набили руку и шишек на этом. Особенно Си хорошо себя зарекомендовал для микроконтроллеров, на нем очень легкие программы можно писать, для Java же нужно еще JVM запустить, что дорого само по себе, плата за универсальность. Но заметьте, что для Си нужно учитывать возможности устройства, далеко не каждая программа на Си пойдет на каком-то конкретном устройстве.