Почему по старинке не делаете - набором таблиц, а документом сохраняете информацию? Таблица banners отдельно, отдельно embeddings, counters и так далее? И апдейтите свои счетчики - поля int в строках.
А то выглядит так - перешли на волне моды на NoSQL, а теперь героически боретесь с основополагающими недостатками документ-ориентированной технологии.
Даже сейчас считаю возможным выделить часто изменяющиеся данные типа счетчиков в отдельные таблицы, да и вообще говоря, применить не sql-сервера, а например, хранилища ключ-значение.
Этот фреймворк слишком большой (перечисление всего, что написано в этой статье). Нужно написать новый фреймворк. Легкий. Быстрый. Безопасный.
Слишком много ошибок в велосипедах. Много кода. Читать невозможно. Применим вот эти и эти библиотеки. Они надежны.
Пользователи жалуются, что фреймворк почти ничего не умеет. Необходимо добавить два десятка фич. Открываем проект, даем всем желающим добавлять нужный функционал.
Фреймворк еле шевелится. Читать его невозможно. Апи невменяемое, глючное, противоречивое, непонятное. Размер огромный. При каждом изменении версий библиотек проект разваливается.
Два замечания. Нативный запрос (если я не ошибаюсь) выдает результат без помещения объектов в контекст, что может давать проблемы при использовании этих запросов в одной транзакции с нормальными jpa jpql запросами. Это надо учитывать.
Второе, хотелось бы подробное исследование по универсальным запросам - как сделать так, чтобы универсальные запросы по разным полями адекватно использовали индексы?
Можно, мы так и делаем. Во всяких отчетах, где нет возможности оперировать запросом, только так.
Но такой стиль плохо на производительность влияет. Впрочем, в универсальных запросах с условиями по разным полям с производительностью и так все плохо.
Про возраст сильно зависит от конторы. В каких-то "потогонках" спецом берут только молодняк. В других, высокотехнологичных, берут людей с опытом. Если контора клепает сайтики - там конечно нет высокого возраста. Если контора разрабатывает электронику - там обязательно будут водиться "зубры".
Имхо. Отлично. Приложения и должны быть одинаковыми. С одинаковым интерфейсом. С одинаковыми приемами работы. Чтобы раз и навсегда выработав привычки и набив руку, пользователь в ЛЮБОМ приложении чувствовал себя как дома. Не нужно было переучиваться в новых приложениях и ломать себя.
Так и было во временя Delphi. И это было замечательно. А потом свернули куда-то не туда и появились веб-приложения каждый со своим интерфейсом, заморочками.
Приложения ДОЛЖНЫ быть "скучными". Пользователь запускает приложение, чтобы делать что-то полезное для себя, а не развлекаться видом приложения. Терпеть не могу "осваивать" приложение.
Разработчики, и особенно, менеджеры, будут концентрироваться на пользе от приложения, а не на извращениях с интерфейсом. Изменения в интерфейсе и способах работы с приложением - это не "новое" и не фичи.
Какому "партнеру"? Супругу? С трудом понял, о чем речь.
Первый раз о такой проблематике услышал. Мы с супругой хоть и инженеры оба, но в радикально разных отраслях. С какой стати помогать супруге в работе? Она профессионал.
Если есть эта точка, значит, есть место творения. Значит размер вселенной ограничен. А раз ограничен, то есть вероятность, что вселенная - это какой-то предмет с размерами и соответственно, была создана кем-то.
Покоящегося! А нейтроны, движущиеся с околосветовой скоростью, живут НАМНОГО дольше. Во-первых, а во-вторых, 15 минут - https://ru.wikipedia.org/wiki/Время_жизни_квантовомеханической_системы, а значит ненулевое количество нейтронов может прожить и 30 минут, и миллиард лет, это дело случая.
Прочитал про VACUUM (не работаю с postgres), так вот в бытность работы с MS SQL как разработчику очень часто приходилось работать с аналогичными вещами, типа обновлением индексов, поскольку вопросы производительности от клиентов валятся на программистов.
Обижаете. Я, например, всю жизнь развивал легаси. Ни разу не начинал новый проект (кроме петов). И смею утверждать, что делаю это хорошо. И часто бывает очень интересно. И достижения на этом поприще тоже можно сделать. У меня - практически спасти проект от закрытия, поскольку на момент моего появления в команде обсуждался вопрос о закрытии проекта и начала нового по причине нарастающей лавины ошибок, "комка грязи" и невозможности развития. "Уважающие себя" разрабы (которые все это наворотили) ушли на новые проекты, в результате воткнули первого попавшего меня, не особо собеседуя. Ликвидировал все ошибки (даже клиенты отмечали улучшение), рефакторил, форматировал. В результате проект продолжил жизнь еще на десять лет.
Очень тяжелая и неприятная работа, но как говорят американцы, платят за дурно пахнущую работу.
Такшта, поддержка легаси не пугает, но как это говорить на собесах, не знаю.
Почему ScopedValue сравнивается с ThreadLocal? ThreadLocal по-сути - глобальная переменная в пределах потока. Через нее можно передавать значение в методы, минуя параметры (всякие кеши).
ScopedValue действует ограниченное время в пределах одного блока. Действие смахивает на
String v = "banana";
System.out.println(v);
{
String v = "apple"; //ERROR: variable v is already defined in method main(java.lang.String[])
System.out.println(v);
}
System.out.println(v);
В отличии от C++, такой код не скомпилируется. Поэтому, видимо, наворотили таких костылей с лямбдами.
Как будет работать f8 в идее с такими конструкциями? Будет курсор по f8 заходить в лямбду и шагать дальше?
В книжках по оптимизации Java вполне себе разбирается, как компилируется и во что код в class, и как потом этот class компилируется во время JIT-компиляции.
И вполне себе спрашивают, как и каким образом java-код компилируется. Плюс спрашивают про управление памятью в java (а их там несколько).
Не знаю Go, но подозреваю, что в java заморочек больше. И если в "компилируемых" языках вы управляете производительностью напрямую, то в Java очень-очень опосредовательно, что очевидно не проще. А проблем с производительностью в реальных приложениях полно.
Данный пример не очень релевантный, потому что можно исхитриться без Вальгаллы.
В случае, если в классе находятся примитивы одного типа, можно организовать класс с массивом двойной длины (в данном примере) и хранить в x в четных, y в нечетных ячейках массива. Организовать get и set соответствующим образом.
Буду признателен тому, кто подскажет, как несколько int из массива преобразовать в double. Иначе говоря, как в массиве int хранить значение double, без создания объектов, как это можно делать в C.
Почему по старинке не делаете - набором таблиц, а документом сохраняете информацию? Таблица banners отдельно, отдельно embeddings, counters и так далее? И апдейтите свои счетчики - поля int в строках.
А то выглядит так - перешли на волне моды на NoSQL, а теперь героически боретесь с основополагающими недостатками документ-ориентированной технологии.
Даже сейчас считаю возможным выделить часто изменяющиеся данные типа счетчиков в отдельные таблицы, да и вообще говоря, применить не sql-сервера, а например, хранилища ключ-значение.
Увы, в мире рынка компании будут писать компактные программы только тогда, когда это будет выгодно.
Когда будет выгодно писать компактные программы?
Когда клиенты будут покупать десктопные приложения, а не web-энтерпрайз.
Когда эксплуатация компактных десктопных приложений будет дешевле web-приложений.
"Калькулятор" нужно писать на Delphi/Lazarus.
Этот фреймворк слишком большой (перечисление всего, что написано в этой статье). Нужно написать новый фреймворк. Легкий. Быстрый. Безопасный.
Слишком много ошибок в велосипедах. Много кода. Читать невозможно. Применим вот эти и эти библиотеки. Они надежны.
Пользователи жалуются, что фреймворк почти ничего не умеет. Необходимо добавить два десятка фич. Открываем проект, даем всем желающим добавлять нужный функционал.
Наворотили фич, кода. "Все желающие" также наворотили фич, кода, понадобавляли библиотек.
Фреймворк еле шевелится. Читать его невозможно. Апи невменяемое, глючное, противоречивое, непонятное. Размер огромный. При каждом изменении версий библиотек проект разваливается.
Перейти к п. 1.
Два замечания. Нативный запрос (если я не ошибаюсь) выдает результат без помещения объектов в контекст, что может давать проблемы при использовании этих запросов в одной транзакции с нормальными jpa jpql запросами. Это надо учитывать.
Второе, хотелось бы подробное исследование по универсальным запросам - как сделать так, чтобы универсальные запросы по разным полями адекватно использовали индексы?
Можно, мы так и делаем. Во всяких отчетах, где нет возможности оперировать запросом, только так.
Но такой стиль плохо на производительность влияет. Впрочем, в универсальных запросах с условиями по разным полям с производительностью и так все плохо.
И даже так, сложность hasmap не является константой, а от O(1) в лучшем случае до O(n) в худшем.
В аналитики.
В каких вы конторах работали?
Про возраст сильно зависит от конторы. В каких-то "потогонках" спецом берут только молодняк. В других, высокотехнологичных, берут людей с опытом. Если контора клепает сайтики - там конечно нет высокого возраста. Если контора разрабатывает электронику - там обязательно будут водиться "зубры".
Пиши про второе высшее.
Есть задачи и ситуации, когда деньги не решают ровным счетом ничего. Точнее, никакое сколь большое количество денег не способно решить задачу.
Имхо. Отлично. Приложения и должны быть одинаковыми. С одинаковым интерфейсом. С одинаковыми приемами работы. Чтобы раз и навсегда выработав привычки и набив руку, пользователь в ЛЮБОМ приложении чувствовал себя как дома. Не нужно было переучиваться в новых приложениях и ломать себя.
Так и было во временя Delphi. И это было замечательно. А потом свернули куда-то не туда и появились веб-приложения каждый со своим интерфейсом, заморочками.
Приложения ДОЛЖНЫ быть "скучными". Пользователь запускает приложение, чтобы делать что-то полезное для себя, а не развлекаться видом приложения. Терпеть не могу "осваивать" приложение.
Разработчики, и особенно, менеджеры, будут концентрироваться на пользе от приложения, а не на извращениях с интерфейсом. Изменения в интерфейсе и способах работы с приложением - это не "новое" и не фичи.
Эппл как всегда на высоте, молодцы.
Какому "партнеру"? Супругу? С трудом понял, о чем речь.
Первый раз о такой проблематике услышал. Мы с супругой хоть и инженеры оба, но в радикально разных отраслях. С какой стати помогать супруге в работе? Она профессионал.
Если есть эта точка, значит, есть место творения. Значит размер вселенной ограничен. А раз ограничен, то есть вероятность, что вселенная - это какой-то предмет с размерами и соответственно, была создана кем-то.
Покоящегося! А нейтроны, движущиеся с околосветовой скоростью, живут НАМНОГО дольше. Во-первых, а во-вторых, 15 минут - https://ru.wikipedia.org/wiki/Время_жизни_квантовомеханической_системы, а значит ненулевое количество нейтронов может прожить и 30 минут, и миллиард лет, это дело случая.
Прочитал про VACUUM (не работаю с postgres), так вот в бытность работы с MS SQL как разработчику очень часто приходилось работать с аналогичными вещами, типа обновлением индексов, поскольку вопросы производительности от клиентов валятся на программистов.
Обижаете. Я, например, всю жизнь развивал легаси. Ни разу не начинал новый проект (кроме петов). И смею утверждать, что делаю это хорошо. И часто бывает очень интересно. И достижения на этом поприще тоже можно сделать. У меня - практически спасти проект от закрытия, поскольку на момент моего появления в команде обсуждался вопрос о закрытии проекта и начала нового по причине нарастающей лавины ошибок, "комка грязи" и невозможности развития. "Уважающие себя" разрабы (которые все это наворотили) ушли на новые проекты, в результате воткнули первого попавшего меня, не особо собеседуя. Ликвидировал все ошибки (даже клиенты отмечали улучшение), рефакторил, форматировал. В результате проект продолжил жизнь еще на десять лет.
Очень тяжелая и неприятная работа, но как говорят американцы, платят за дурно пахнущую работу.
Такшта, поддержка легаси не пугает, но как это говорить на собесах, не знаю.
Почему ScopedValue сравнивается с ThreadLocal? ThreadLocal по-сути - глобальная переменная в пределах потока. Через нее можно передавать значение в методы, минуя параметры (всякие кеши).
ScopedValue действует ограниченное время в пределах одного блока. Действие смахивает на
В отличии от C++, такой код не скомпилируется. Поэтому, видимо, наворотили таких костылей с лямбдами.
Как будет работать f8 в идее с такими конструкциями? Будет курсор по f8 заходить в лямбду и шагать дальше?
В книжках по оптимизации Java вполне себе разбирается, как компилируется и во что код в class, и как потом этот class компилируется во время JIT-компиляции.
И вполне себе спрашивают, как и каким образом java-код компилируется. Плюс спрашивают про управление памятью в java (а их там несколько).
Не знаю Go, но подозреваю, что в java заморочек больше. И если в "компилируемых" языках вы управляете производительностью напрямую, то в Java очень-очень опосредовательно, что очевидно не проще. А проблем с производительностью в реальных приложениях полно.
Данный пример не очень релевантный, потому что можно исхитриться без Вальгаллы.
В случае, если в классе находятся примитивы одного типа, можно организовать класс с массивом двойной длины (в данном примере) и хранить в x в четных, y в нечетных ячейках массива. Организовать get и set соответствующим образом.
Буду признателен тому, кто подскажет, как несколько int из массива преобразовать в double. Иначе говоря, как в массиве int хранить значение double, без создания объектов, как это можно делать в C.