Pull to refresh
4

Механизатор профиля

-0,3
Rating
2
Subscribers
Send message

Приветствую! В предыдущем посте это написано https://habr.com/ru/posts/1025122/
Пока не понял как связать посты, что бы они были в одной логической цепочке.

Вот как раз думаю не использовать  json  и другие  human readable форматы, но об этом тоже позже.

Об этом будет в следующих постах. Разбираюсь постепенно/

Тут в чем проблема, с С/С++ я давно работал и сначала придется не идеями заняться а много чего вспомнить...

Обратная связь, без нее никак :)

Вы хотели написать наивный? :)

Думал о новых языках, в частности о rust, даже в отпуске читал его спецификацию глядя с террасы на Эльбрус :) Скажу честно, я не понял преимуществ перед C/C++ в частности в удобстве управления памятью. Но собственно суть моего проекта это общение и обмен опытом... и может быть вы подскажите

Да, C/C++ думаю и в эту сторону. Старый добрый C++ идеально для управления памятью и аппаратным обеспечение. Когда то много писал на нем, но сейчас больше на java. Возможно перееду на него.

Моя карма с треском и грохотом падает :))) Спасибо за комментарий!

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

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

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

Насчет технической части, нужны ли virtual threads? А вот я не знаю наверняка, это и предстоит узнать :). По поводу выбора языка программирования? А почему не JVM  язык? Да, я бы посмотрел в сторону C/C++ в виду того что там возможно эффективное управление памятью, насколько удобно работать с  rust?  Пока неясно. GO кажется каким то призрачным, к тому же его придется изучить :)

У меня нет цели заставить сообщество все бросить и заинтересоваться. Мне будет если подтянуться интересные люди, будут подкидывать идеи и обсуждать. Поэтому я начал представлять проект не с прототипа, а с идеи...

Масштаб проекта? Планку нужно ставить всегда выше того уровня до которого вы допрыгиваете - я так думаю!

Вот все об этом пишут, пишут :) Как вы относитесь к тому что метод Objects#requireNonNull вызывают для проверки аргументов метода и там как раз выкидывается NullPointerException. По сути тоже что пишет автор :)

Спасибо большое. Все больше начинаю понимать насколько Хабр - ценный ресурс!

Пока что сравнения нет, в слудующую публикацию пожалуй посвящу этой теме. Буду признателен если сделаете ревью.

В текущей версии нет, в принципе можно передавать сразу java.lang.reflect.Type, но с точки зрения количества букв в коде это будет не сильно меньше, поскольку это самый Type как то необходимо сконструировать, например при помощи org.apache.commons.lang3.reflect.TypeUtils.

objectFactory.get(Map<String, Person>.class)

В scala думаю что так сделать можно.

Спасибо, я ждал этот вопрос :) Ответ простой, в 2021 году когда начал впервые работать над проектом genthz,я ее попросту не нашел. Прямо сейчас я посмотрел, история репозитория instancio началась в 03.03.2022 . Многие идеи у нас совпадают.

Одну вещь я у них спер :) это использование getter'ов и setter'ов вместо строковых имен полей, при указании специфических генераторов для них (у меня это [FieldMatchers](https://github.com/mathter/genthz/blob/dev/3.1.x/genthz-core/src/main/java/org/genthz/FieldMatchers.java) у них Select#field(...)).

Точно могу сказать, что документация у них пока что лучше :)

Библиотека хорошая, но определенные моменты, с точки зрения использования, мне кажутся у меня более удачными и более прозрачными. Например, у меня, как мне кажется, все более единообразно, нет этого огромного количества методов stream - отдельно для стрима, ofList - отдельно для листов, у меня всегда единнобразно ObjectFactory.get(List.class, String.class) ObjectFactory.get(List.class, Person.class.

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

1) Возможно, возможно стоит сделать ребрендинг :). Название dasha использовал в честь имени дочери, по праву создателя проекта.

2) Наверное согласен, пожалуй даже скорректирую текст;

3) Библиотеки как оказались есть, одну указали в одном из комментариев к статье https://github.com/instancio/instancio . Как ни странно, уже после начала работы над своим проектом я её не нашел, точнее в 2021 году ее еще не было. Нашел большое сходство идей, которые заложил в свою библиотеку я и авторы instancio. Но процесс уже пошел и решил продолжить работу - составить им конкуренцию. Некоторые вещи мне кажется я сделал более удачно, у меня есть Dsl у них Model. Мой Dsl это в сущности собранные вместе Model для использования это удобно;

4) Эта тема очень обширная, для больших систем, интеграционных тестов и пр. действительно используются слепки БД с прода. Мы их тоже используем, на это все накладываются куча ограничений административных и ограничения безопасности и т.д и т.п. Я создавал библиотеку в которой в одном месте (`Dsl`) задает параметры для генерации объектов "на лету".

Если тест не помогает понять на более высоком уровне

Да, как раз имел в виду документацию в более широком смысле. В более узком смысле и сам код можно считать документацией, такой подход тоже есть, вопрос в эффективности…

Иногда нужно понимание того как А или В следует понимать в рамках более общего бизнес процесса. Сферический код в вакууме как и тесты к нему скорее всего не будут интересны.

Процессы не конкурируют за блокировки, процессы конкурируют за ресурсы.

Information

Rating
Does not participate
Location
Россия
Registered
Activity

Specialization

Бэкенд разработчик, Разработчик мобильных приложений
Ведущий