Массив целых чисел или список, что весит больше?

Оговоримся, что мы сравниваем массив и список основанный на массиве - ArrayList.

Вообще, правильный ответ дали сразу же.

Мы не можем в списке хранить примитивы, а в массиве можем.

Примитивы весят меньше классов оберток.

А значит, массив примитивов весит меньше списка оберток 🎮

Но возник вопрос, а что если будет массив оберток?

В этом случае список все равно будет весить больше 🙃.

Список - это объект
Массив - это объект

Но список основан на массиве, и внутри объекта списка лежит объект массива. И внутри ArrayList лежит не только массив но и другие поля, которые тоже занимают память.

Это как с матрешкой. Большая матрешка с маленькой внутри не могут весить меньше, чем отдельно маленькая матрешка 🫥

Вроде разобрались, список жирнее.

Дабы не быть голословным, вот некоторая инфа о том сколько памяти занимают разные объекты в Java:

🎮 Memory usage of some typical Java objects

🎮 Sizes of primitive types

🎮 How to calculate the memory usage of a Java array

Список весит больше массива. Вроде бы все просто, но есть одно маленькое но.

Допустима ситуация, при которой список будет весить меньше массива.

Сможете ли вы описать такой кейс?

Что самое важное в изучении Java?

Пет-проекты. По нескольким причинам.

🏜 В пет-проекте ты учишься делать цельное приложение. Тебе приходится решать комплекс взаимосвязанных друг с другом задач, а не решать задачки в отрыве от реальности

🏜 В отличии от теоретической подготовки, которая несомненно важна, в пет-проекте ты обретаешь навыки, которые тебе будут нужны всегда, а не только во-время прохождения собеса

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

Это не голые умозаключения. Это инфа проверенная на опыте.

У меня было 5 учеников. Мы тратили минимум 80% времени на создание проектов, а остальные 20 раскидали на подготовку к собесам и консультации по тестовым заданиям. Каждый из 5 нашел работу.

С каждым из них мы делали индивидуальный проект. Логика в проектах была разной, где-то даже интерфейс был на иврите 😅.

Но по большей части набор технологий был схож, как и структура.

Теперь у меня есть маленькая мечта. Преподнести эту информацию не кому-то персонально, а группе людей. Поэтому в мае я стартую первую итерацию своего курса по созданию пет-проектов на Spring Boot.

Что будет?

Я наберу людей в закрытую группу, где раз в неделю буду выкладывать по уроку.
Вместе мы будем разрабатывать небольшое приложение для маленькой кофейни, с бонусной картой и системой лояльности ☕️.

Это самая универсальная идея для дальнейшей кастомизации. Каждый сможет потом сделать практически идентичное приложение, но не для кофейни, а для салона красоты, пекарни, автомойки и тд.

Мы напишем приложение на Spring Boot с авторизацией, блэк-джеком и хостингом.

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

И как я сказал - это моя первая итерация и первый курс. Неизбежны какие-то шероховатости.

Поэтому сейчас я буду предлагать его на порядок дешевле, чем в будущем, когда я оптимизирую подачу материала и автоматизирую сам процесс обучения.
И поэтому в этой итерации я всегда буду на связи и буду саппортить аки самый ответственный инженер технической поддержки 👨‍🔧.

Но есть и плюшки.

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

От каждого ученика я слышал слова, что то, что я им дал, на рынке стоит в разы дороже. Это так, и им обошлось это не так дорого, потому что это был мой первый опыт наставничества. Сейчас у вас есть такая же возможность залететь на мой первый курс.

По подробностями залетайте в лс, или ставьте + в коментах, я с вами свяжусь.

До 28 апреля действуют самые вкусные условия

🔓 Принцип KISS в программировании

Принцип KISS (Keep It Simple, Stupid) гласит: "Делай проще, глупыш(ка)". Это означает, что программы лучше работают, когда они просты в понимании, создании и использовании.

🔍 Как придерживаться принципа KISS при разработке на Java:

1. Разбивайте код на маленькие части: Пишите небольшие кусочки кода, которые легко читать и понимать. Это поможет другим разработчикам легко разбираться в вашем коде.
2. Давайте понятные имена: Используйте имена переменных и функций, которые описывают, что они делают. Это сделает ваш код понятнее для всех.
3. Избегайте многоуровневой вложенности: Не создавайте несколько уровней вложенности, таких как вложенные циклы или ветвления. Это может усложнить ваш код и сделать его трудным для понимания.
4. Тестируйте свой код: Напишите тесты, чтобы убедиться, что ваш код работает правильно. Это поможет избежать ошибок.
5. Не усложняйте зависимости: Используйте только те библиотеки, которые вам действительно нужны. Это сделает ваше приложение проще и быстрее.
6. Документируйте свой код: Пишите комментарии к коду, чтобы другие разработчики могли быстрее разобраться в нем.
7. Разрабатывайте постепенно: Начните с простой версии вашего приложения и добавляйте новые функции постепенно.


Надеюсь эти простые рекомендации помогут вам делать все проще и создавать более понятные программы на Java!

Короче, что не так с ООП?

Во-первых, мне приятно, что я своим вопросом, судя по комментариям, будто немного задел чувства верующих.

Контент, который вызывает эмоции - крутой контент. 🔥

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

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

Это все круто, но с ООП то что не так?

Ну во первых, минусов у него так мало, что пол поста приходится говорить о взрывающихся пердаках.

А во вторых, в ООП количество ссылок на объекты распределенных по всей системе растет такими же темпами, как количество разрывающихся от негодования пуканчиков в постах из примера выше.

По просту говоря - взрывными темпами.

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

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

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

Оно потребляло всю память и умирало, его реанимировали, а оно снова падало. Из-за огромного размера кодовой базы вырезать опухоль оперативно было невозможно. Приходилось судорожно прикладывать подорожники, слушая во сколько тысяч долларов обходятся минуты простоев 🗡.

Второй опыт был эталонным примером обращения внимания на эту проблему 🛡.

Я работал в команде харденинга. От английского закаливать (а может и нет, уже хз). Все что делала эта команда - получала один из существующих сервисов и занималась только одним. Оптимизацией. Конкретно в моем случае мы разгружали память приложения вынося его кэш в Reddis.

Какая у всего этого мораль?

Одной из самых сложных для меня тем на собесах (когда собесят меня) является потребление памяти.

Если вдруг почувствуете, что ваш пукан взрывается от потребления какого-то контента, знайте, скорее всего вами манипулируют.

Затушите огонь благого гнева изучением Java Memory Model, почитайте про различные сборщики мусора и алгоритмы их работы и получите +100 к привлекательности на собесах 📿🧣❤️‍🔥

Задачка

Поделюсь примером того, чем приходится заниматься 40 часов в неделю 🖥

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

Представим также, что фронты пожаловались, что им приходит большое количество координат, и попросили уменьшить объем передаваемых данных, но так, чтобы трек все еще можно было отрисовать 🤯

Одно из предложенных решений - передавать в фильтре дополнительный временной интервал - количество минут. Его задача отсеивать лишние координаты следующим образом:

Допустим, что у нас есть координаты транспорта за каждую секунду. Если значение этого фильтра равно 2, тогда передается первая координата, затем та, которая идет минимум через 2 минуты, затем та, которая идет минимум за 2 минуты и тд.

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

🅰️🅰️🅰️

Для упрощения представим, что у нас есть класс с координатой x (другие опустим для упрощения), а также меткой времени, в которое эта координата измерена.

Необходимо реализовать тело метода filterCoordinates

class Scratch {
    public static void main(String[] args) {
        List<Coordinate> coordinates = getCoordinates();
        List<Coordinate> filtered = filterCoordinates(coordinates, 1);
    }

    static class Coordinate {
        int x;
        LocalDateTime dateTime;
        Coordinate(int x, LocalDateTime dateTime) {
            this.x = x;
            this.dateTime = dateTime;
        }
    }

    static List<Coordinate> filterCoordinates(
            List<Coordinate> coordinates,
            int minutesInterval) {
        // TODO реализовать фильтрацию
        return coordinates;
    }
    
    static List<Coordinate> getCoordinates() {
        List<Coordinate> coordinates = new ArrayList<>();
        LocalDateTime now = LocalDateTime.now();
        for (int i = 1; i <= 300; i++) {
            coordinates.add(new Coordinate(i, now.plusSeconds(i)));
        }
        return coordinates;
    }
}

Привет, ребят!

Давненько ничего не писал.

Не писал по нескольким причинам.

Первая причина это ты, а главная причина - это отсутствие понимания какой контент я хочу генерить для себя и вас.

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

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

Вот возьмем меня. Я подписан на каналы по джаве. В них постится полезный контент. Читаю ли я его? Нет. Отпишусь ли я? Нет. Потому что внутри мне хочется самому себе казаться человеком, который хочет развиваться, а не ржать и угарать над кринжовыми историями.

А по факту я хочу ржать и угарать над кринжовыми историями. Читать людей, которые делятся своими трудностями, болями. Читать о том, как настоящие, живые люди достигают успеха, иногда терпят неудачи.

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

И появляется прям сверх задача. Сверх задача, которая отпугивает, заставляет тебя откладывать, и твоим ежедневным ритуалом становится фраза: ладно, завтра попробую.

Можно было бы отложить и сегодня, если бы на помощь не пришел мой здоровый перфекцехуизм. Когда хочется идеально, но если не получается, то и... 👌

И я решил, а почему бы вам не рассказать о том, что у меня появились ученики?

Вот например сегодня я, кабардинец, из Санкт-Петербурга, рассказывал кыргызу в Ирландии о том, как работать с базой данных из IDEA на английском языке 🤯

Да что там рассказывать? Сами смотрите 📺.

Как думаете, это попадает под категорию весело и полезно? 🤔