Pull to refresh
44
0.1
Валерий Вырва @valery1707

Java backend

Send message
Прекратите пытаться не выглядеть глупо.

Выражения выглядеть глупо и выглядеть глупым имеют всё же разный подтекст.

А может кто-нибудь пояснить за стоимость курса Погружение в Python?
На сайте есть таблица, но нет самих цен:

В Java:


public class ModuloTest {
    public static void main(String[] args) {
        System.out.println("19 %  12 = " + 19 % 12);
        System.out.println("19 % -12 = " + 19 % (-12));
    }
}

Будет вот так:


19 %  12 = 7
19 % -12 = 7

Сайт это хорошо, но может стоит на нём добавить описание о том как можно получить файл без которого ничего и не работает?
Я вот хотел посмотреть на Воронеж и Караганду.

У меня вместо bash-алиасов использованы git-алиасы:


git config --global alias.st status
git config --global alias.co checkout
git config --global alias.ci commit
git config --global alias.br branch

И git checkout превращается в git co, что выглядит, на мой взгляд лучше чем go.
А gpuoh у вас и нет.

alias gp="git push -u origin master"

А от этого польза есть?
Я вот вижу только вред: обычно всё же работа идёт в рамках git-flow/аналогов и ветка отнюдь не одна, так что пушить строго в master не нужно.

В моём отделении в Воронеже электронная очередь работала чуть больше месяца в начале прошлого года. С тех пор опять только живая. Столбик стоит, но не работает.

Я правильно понимаю что у вас IPv4-адрес бесплатен для сервера, а за подключение IPv6 нужно платить?
А почему так?
Почему не наоборот — ведь IPv4 мало, а IPv6 очень много?

Тут больше подробностей по ограничениям

Бенчмарк, сырые данные, табличка, вывод: с кешем быстрее.
Возможно сказывается то что кешированный размер лежит в локальной переменной, а не достаётся через обращения к полю/методу другого объекта.

Да я и сейчас не понял.


Вы предлагаете узнать профит от кеширования размера коллекции при обходе new int[]{1, 2, 3} и Arrays.asList(1, 2, 3)?

большинство проверок — лишние.

Я это понимаю — я тут заодно прокачивал свой навык написания бенчмарков на JMH :)


Что действительно нужно сравнивать — так это ArrayList и обычные массивы.

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


Сильно подозреваю что доступ к элементу массива будет быстрее доступа к элементу ArrayList-а, но опять же копеечно и только из-за того что каждый вызов ArrayList#get(int) это:


  • собственно вызов метода
  • проверка выхода за правую границу
  • вызов внутреннего метода для каста
  • обращение к массиву по индексу

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

Я понимаю что бремя доказательства лежит на Marvinorez, а не на вас и вам доказывать ничего не нужно.
Хотя именно у вас есть опыт в создании JMH-тестов — могли бы и помочь человеку, но не захотели — бывает :)


Я решил помочь. Вот тесты производительности, вот их сырые результаты — если я что-то не то или не так тестировал — милости просим в PR.


И вот табличка с результатами (Habr не смог переварить такую большую таблицу :( ).
И я, из результатов тестов, вижу что кеширование размера коллекции может давать профит, но в зависимости от типа коллекции:


  • java.util.HashSetвыгодно
  • java.util.TreeSet — не выгодно
  • java.util.ArrayListвыгодно
  • java.util.LinkedListвыгодно
Формат номера +7 (город) номер — ещё одно бездумное следование «традиции».

Вообще есть стандарт E.164 (точнее рекомендация, но всё же), согласно которому номер рекомендуется вводить в формате ${страна} ${оператор} ${абонент}, и для России страна всегда +7, оператор — это код города или префикс оператора, а остальное уже идёт как номер абонента.
Библиотека LibPhoneNumber от Гугла, при отображении номера в национальном формате, код оператора отбивает просто пробелами и разбивает номер абонента на три части через -.

Ну не знаю. Мне, например, не всё равно ни на имена полей ни на их тип. (String, Карл, String!)

Я же говорю, это не противопоставление, это дополнение.

Ну вообще-то пост называется Разработка на CUBA — большой шаг в сторону от Spring? и это выглядит именно как противопоставление.


Да и отвечал я на комментарий jreznot про Vaadin.

Кроме того, скрипты SQL, которые генерирует CUBA, делаются в виде файлов и можно посмотреть, что было сгенерировано и даже поправить руками или дописать свое, если требуется, перед тем, как применять изменения. Это не черный ящик. Скрипты SQL попадают в codebase, коммитятся в Git и они вообще часть проекта.

А вот это уже хорошо.

Version ставится над полем, в 90% случаев, я думаю, это поле будет называться version и дальше про него все забудут. Зачем нужен бойлерплейт?
То же самое можно сказать про @CreatedDate и @LastModifiedDate.

С доводом относительно version можно согласиться, а вот на счёт Creatable и Updatable я совсем не согласен.
Spring предполагает (по именам аннотаций) поля createdDate, createdBy, lastModifiedDate и lastModifiedBy. Причём в любом количестве и всё же с любыми именами.
Я предпочитаю createdAt, createdBy, updatedAt и updatedBy.
CUBA же жёстко заставляет использовать конкретно и только createTs, createdBy, updateTs и updatedBy.
Причём только по 2 вместе. То есть я не могу контролировать только даты — если я хочу дату я должен дать и пользователя.
Более того у CUBA автор изменений это только строка. В Spring это может быть любой класс и я использовал entity-класс пользователя — консистентность, гибкость, удобство, круть. А тут — строка. Консистентность? Гибкость? Удобство? Хм…
Это не говоря о том что дата создания изменения это строго java.util.Date. JSR 310: Date and Time API — не не слышали :(


Зачем нужен бойлерплейт?

А его реально много?
Вот это без одно поле в базовом классе без Lombok:


@Entity
@MappedSuperclass
public class SomeBaseEntity {
    @NotNull
    @CreatedDate
    private LocalDateTime createdAt;

    public LocalDateTime getCreatedAt() {
        return createdAt;
    }

    public void setCreatedAt(LocalDateTime createdAt) {
        this.createdAt = createdAt;
    }
}

А вот так с Lombok:


@Data
@Entity
@MappedSuperclass
public class SomeBaseEntity {
    @NotNull
    @CreatedDate
    private LocalDateTime createdAt;

В любом случае это делается 1 раз в базовом классе.
Я вот не уверен что цена которую требует CUBA за уничтожение бойлерплейта (жёсткие имена полей, странные типы данных) стоит того объёма бойлерплейка который будет убран

CUBA Studio это автоматом делает, IDEA тоже может автоматизировать эту работу. И сущности делаются не так часто, так что неудобство минимальное.

Ну одно дело один раз указать пакет с сущностями и потом указать @Entity, и совсем другое каждый раз указывая @Entity помнить ещё и про xml.
Я тут для тестов одного функционала создал десяток сущностей — ваше минимальное неудобство не такое уж и минимальное.

Vaadin — это только UI, никакой инфраструктуры, не говоря уже про кэширование данных, кластер, права доступа и hot-deploy.

Инфраструктура обеспечивается Spring и Spring Boot.
Кеширование им же и Hibernate.
Про кластеризацию не скажу — не было нужды.
Права доступа — есть и в Vaadin-е, плюс Spring.
Hot deploy обеспечивается JVM, правда если не сильно меняли классы. А CUBA может в hot deploy при изменении интерфейса классов?

Information

Rating
3,764-th
Location
Воронеж, Воронежская обл., Россия
Date of birth
Registered
Activity