Прочитав текущую и предыдущую статьи, не совсем понял их посыл. Ок, вы отклонили существующие подходы к генерации sql запросов и создали свой инструмент - QueryBuilder, иии что дальше? Если вы его рекламируете, то выкладывайте в опенсорс, пишите документацию и кейсы использования.
show(); // undefined (в строгом режиме) или 'Ирина' (в обычном)
В строгом режиме будет ошибка this is undefined, а в обычном режиме напечатает undefined. Скорее всего, вы ненамеренно ошиблись, но лучше такие вещи проверять.
Вы смешали теплое с мягким. Идея написать приложение без внешних зависимостей никак не зависит от правил хорошего тона при разработке. Сама по себе себе интересная, реализация немного хромает.
К слову даже PoC можно за полчаса наговнякать так, что сам не разберешься через месяц, а можно постараться написать так, что код будет хорошо читаем. Это все приходит с опытом.
Это интересный проект для джуна, чтобы проверить свои силы и знания. Но раз мы делимся кодом с окружающими, то давайте делиться качественным кодом. Позвольте отметить несколько моментов, дабы новички не приняли на веру.
Общие замечание.
Многие вещи стоило унести в утилиты. Например, если даже мы используем jul, то можно было бы написать адаптер для удобного использования.
Форматирование кода просто нечитаемое. Но это скорее вкусовщина.
debugMessages = Boolean.parseBoolean(...); тут можно и нужно унести в static final, раз сделали ее shared переменной
TinyDI notDI = new TinyDI(); notDI.setup(...) если мы делаем свой IoC контейнер, может сделать более удобный API использования? есть тысяча способов сделать это, у Жени Борисова есть Live-coding доклад, где он за пару часов созадет IoC контейнер.
int[] topoSort(ArrayList> adj) не нужно привязываться к реализации коллекций
Map sessions = new HashMap<>(); public Session getSession public synchronized String registerSessionFor в многопоточном коде все операции должны быть под одним монитором. но проще конечно же здесь и в других местах использовать конкурентные коллекции.
static void toJson(StringBuilder out, BookRecord r) написать общий сериализатор в JSON дело часа-двух. забыли про экранирование спецсимволов в toJson.
if (match(Boolean.TRUE.toString())) вместо сравнения со строковой константой каждый раз дергаем метод.
OutputStream os = t.getResponseBody(); os.close(); try with resources был бы правильным решением.
new String(getResource("/static/html/template/main.html")) а какая кодировка будет использоваться при разборе байт в строку?
В свете релиза виртуальных потоков стоило отметить, что подходов к synchronized стоит избегать и отдавать предпочтение ReentrantLock. Кроме того ReentrantLock / Condition имеют куда более гибкий и читаемый api.
В статьях часто используют примечания (сноски) – по сути это ссылки на источники с указанием автора, работы, страницы. Т.е. такой подход известен уже давно.
Понятно, что статья больше для рекламы продукта и пиара компании, но давайте делать примеры с качественным кодом.
Версионирование миграций вида V1__ V2__ сразу же сломается, когда 2 разработчика начнут делать фичи параллельно. Для обхода этого есть подход использовать таймштампа в версии https://www.jeremyjarrell.com/using-flyway-db-with-distributed-version-control/
видимо пошла из помогаторов вида jpa buddy. Неужели не проще и более читаемо делать проверку на instanceof? У нас классы расширяются cglib-ом через наследование и прокси-класс будет наследником класса entity. Как по мне более читаемо:
if (!(o instanceof Comment comment)) return false;
Непонятно, зачем задано ограничение на строку комментария varchar(255)? Во-первых, почему именно 255? Чем так привлекло это число, почему не varchar(4000)? Во-вторых, для текста в Postgres есть почти безлимитный text.
Еще непонятно, почему для даты используется timestamp without time zone, который по смыслу хранит локальное время LocalDateTime? Если у нас 1 клиент БД с одной TZ, то вроде бы и ок. Но если у нас появится клиент (приложение) в другой TZ, то время будет уже неверным.
По своей сути это библиотечный каталог только для просмотра микрофильмов. Библиотеки и каталоги, индексные указатели существуют тысячи лет. Да, здесь сделано нечто большее, возможность просмотра фильмов и т.п., но это никак не концепция базы данных.
Насчет нанотехнологий не скажу, но что именно вам смущает в цифровизации экономики?
Я лично вижу повальное внедрение ЭДО (бухгалтерия, кадры, управление предприятиями), вижу развитие ИС для общества (Госуслуги, Электронные медкарты, Электронные дневники).
Хайповые ли это темы? Возможно. Может ли в них быть место неправомерному использованию средств? Может, как и в любой другой сфере. Везде где есть люди есть место мошенничеству и воровству.
Хорошая статья, которая может стать отправной точкой для более глубокого изучения материала.
В случае с race condition допущена неточность. В ЯП с многозадачностью на потоках различают race condition и data race.
Состояние гонки – это когда корректность программы зависит от того, в каком порядке выполняются части кода. Частным случаем является TOCTOU проблема – когда в нескольких потоках делаем некую проверку, а потом исполняем код на основе этой проверки. Например, на балансе лежит 100руб, мы проверяем можем ли купить товар, допустим, за 90руб, и в случае успеха списываем. Если не делать синхронизации и запустить такой код в 2 потоках, то проверка на 100руб > 90руб успешно пройдет в обоих потоках и спишет 180руб, в итоге на балансе станет -80руб.
Гонка данных в свою очередь – это когда несколько потоков читают переменную, и хотя бы 1 поток пишет. Например, в одном потоке мы бегаем в цикле flag = true; while(flag); а в другом потоке меняет флаг flag = false; Без корректной синхронизации такой код может выполняться вечно.
Азотная кислота не состоит в списках веществ, оборот которых ограничен на территории РФ, в отличие от той же серной кислоты, ацетона или марганцовки. Тонну азотной кислоты вы вряд ли купите, но пару литров вполне продадут в магазине хим. реактивов. Могут попросить паспорт, но арестовывать точно никто не будет.
Если кандидат нас устраивает по хард/софт скилам, но попросил меньше, чем в среднем у нас получают сотрудники на данной должности, то мы дадим по уровню остальных. Мы стараемся выравнивать сотрудников по его грейду / зарплате на руки: каждый год делаем переоценку грейдов и делаем индексацию/повышение окладов.
Кандидат присылает резюме, в резюме многие сразу указывают желаемую ЗП. Если ЗП в резюме не указана, то hr спрашивает желаемый уровень. Если по резюме и ЗП я вижу, что бюджет позволяет, то мы назначаем встречу с hr и кандидатом, где уже устно общаемся, спрашиваем про опыт работы, я спрашиваю по техническим моментам. Если все устраивает - мы делаем оффер с озвученной кандидатом ЗП.
Если человек имеет какой-то опыт (даже на пет проектах), ответил на технические вопросы и приятен нам в общении, то мы такого возьмем, вероятно это уже больше чем просто "джун".
А если человек выходец с инфоцыганских курсов, который научился делать примитивные crud-приложения по шаблону и ничего больше не умеет, то это простой манки-кодер. Был бы у него потенциал, он бы расширил свои знания вширь, отточил сам на пет-проектах и стал бы чем-то большим.
Вообще, выходцы с курсов это коты в мешке, потому меня так это задевает. Мы уже несколько раз натыкались на таких, давали им шанс, понимая риски, и за испытательный срок они не вывозили. Сейчас более настороженно проводим собеседования.
Кандидату не надо угадывать. Кандидат озвучивает свой ценник на этапе первичного общения с HR. Смотрите в чем нюанс, если поставить в вакансии вилку ЗП условно от 1к$ до 3к$, то большинство кандидатов будут просить по максимуму, проверено на опыте.
Возможно, вы не так поняли. Если джун подошел по новыкам и попросил в пределах условной вилки ЗП, то мы его возьмем. Если же джун попросил сильно больше, например, 2к$, то скорее всего мы ему откажем. Как уже упоминал в других комментариях, мое подразделение в небольшом городе в глубинке, и так или иначе мы берем во внимание уровень жизни в нашем городе. У меня рука не поднимается платить зеленым джунам по 2 средние зп инженеров с завода. Я считаю это ненормально.
В другом ответе на комментарий я уже помянул. Я считаю неадекватным, когда приходят джуны с околонулевым опытом и сразу просят 2к$. Джун не может самостоятельно выполнять любые задачи, во многом нужна помощь и развитие, и при этом мы ему даем две средние зп инженеров местного завода. Я считаю это перебор.
Я привел конкретный пример: даже в моем городе на вакансии джунов приходят кандидаты, которые просят по 2к$. Джуны, которые полноценно не могут выполнять задачи. И вы считаете это нормально?
На самом деле все "зависит от". По своей практике найма, как руководителя разработки, могу подсветить пару моментов:
-- С одной стороны раздулся пузырь зарплат. До сво западные компании заманивали зп под 5к$ и более, и московские компании стали подтягиваться под этот ценник. В итоге даже в нашем Мухосранске джуниоры стали просить оклад под 2к$.
-- Качество джунов/миддлов сильно упало. Если раньше приходили выпускники профильных специальностей, которые МОГЛИ, то сейчас все чаще приходят выпускники инфоцыганских курсов, которые обучены делать только А и Б и совсем не знают базы.
Потому я бы перефразировал вашу фразу: на рынке дефицит специалистов по адекватному ценнику. Поэтому кстати и у нас скрыта вилка з/п. На собесе я провожу оценку опыта и знаний кандидата и предлагаю зп согласно его уровню и его ожиданиям.
Плохой пример привели.
1. Информация о типах колонок лежит в бд - у ИИ нет доступа к вашей БД.
2. Формировать ДТО по результату запроса (выборке с данными) - какая-то глупость.
3. ДТО должно задаваться явно на бэкенде, на основе среза сущностей, или там автогенерации кода.
Прочитав текущую и предыдущую статьи, не совсем понял их посыл. Ок, вы отклонили существующие подходы к генерации sql запросов и создали свой инструмент - QueryBuilder, иии что дальше? Если вы его рекламируете, то выкладывайте в опенсорс, пишите документацию и кейсы использования.
В строгом режиме будет ошибка this is undefined, а в обычном режиме напечатает undefined. Скорее всего, вы ненамеренно ошиблись, но лучше такие вещи проверять.
Вы смешали теплое с мягким. Идея написать приложение без внешних зависимостей никак не зависит от правил хорошего тона при разработке. Сама по себе себе интересная, реализация немного хромает.
К слову даже PoC можно за полчаса наговнякать так, что сам не разберешься через месяц, а можно постараться написать так, что код будет хорошо читаем. Это все приходит с опытом.
Это интересный проект для джуна, чтобы проверить свои силы и знания.
Но раз мы делимся кодом с окружающими, то давайте делиться качественным кодом.
Позвольте отметить несколько моментов, дабы новички не приняли на веру.
Общие замечание.
Многие вещи стоило унести в утилиты. Например, если даже мы используем jul, то можно было бы написать адаптер для удобного использования.
Форматирование кода просто нечитаемое. Но это скорее вкусовщина.
debugMessages = Boolean.parseBoolean(...);
тут можно и нужно унести в static final, раз сделали ее shared переменной
TinyDI notDI = new TinyDI();
notDI.setup(...)
если мы делаем свой IoC контейнер, может сделать более удобный API использования?
есть тысяча способов сделать это, у Жени Борисова есть Live-coding доклад, где он за пару часов созадет IoC контейнер.
int[] topoSort(ArrayList> adj)
не нужно привязываться к реализации коллекций
Map sessions = new HashMap<>();
public Session getSession
public synchronized String registerSessionFor
в многопоточном коде все операции должны быть под одним монитором.
но проще конечно же здесь и в других местах использовать конкурентные коллекции.
static void toJson(StringBuilder out, BookRecord r)
написать общий сериализатор в JSON дело часа-двух.
забыли про экранирование спецсимволов в toJson.
if (match(Boolean.TRUE.toString()))
вместо сравнения со строковой константой каждый раз дергаем метод.
OutputStream os = t.getResponseBody();
os.close();
try with resources был бы правильным решением.
new String(getResource("/static/html/template/main.html"))
а какая кодировка будет использоваться при разборе байт в строку?
В свете релиза виртуальных потоков стоило отметить, что подходов к synchronized стоит избегать и отдавать предпочтение ReentrantLock. Кроме того ReentrantLock / Condition имеют куда более гибкий и читаемый api.
В статьях часто используют примечания (сноски) – по сути это ссылки на источники с указанием автора, работы, страницы. Т.е. такой подход известен уже давно.
Понятно, что статья больше для рекламы продукта и пиара компании, но давайте делать примеры с качественным кодом.
Версионирование миграций вида V1__ V2__ сразу же сломается, когда 2 разработчика начнут делать фичи параллельно. Для обхода этого есть подход использовать таймштампа в версии https://www.jeremyjarrell.com/using-flyway-db-with-distributed-version-control/
Генерация портянки кода вида
видимо пошла из помогаторов вида jpa buddy. Неужели не проще и более читаемо делать проверку на instanceof? У нас классы расширяются cglib-ом через наследование и прокси-класс будет наследником класса entity. Как по мне более читаемо:
Непонятно, зачем задано ограничение на строку комментария varchar(255)? Во-первых, почему именно 255? Чем так привлекло это число, почему не varchar(4000)? Во-вторых, для текста в Postgres есть почти безлимитный text.
Еще непонятно, почему для даты используется timestamp without time zone, который по смыслу хранит локальное время LocalDateTime? Если у нас 1 клиент БД с одной TZ, то вроде бы и ок. Но если у нас появится клиент (приложение) в другой TZ, то время будет уже неверным.
По своей сути это библиотечный каталог только для просмотра микрофильмов. Библиотеки и каталоги, индексные указатели существуют тысячи лет. Да, здесь сделано нечто большее, возможность просмотра фильмов и т.п., но это никак не концепция базы данных.
Насчет нанотехнологий не скажу, но что именно вам смущает в цифровизации экономики?
Я лично вижу повальное внедрение ЭДО (бухгалтерия, кадры, управление предприятиями), вижу развитие ИС для общества (Госуслуги, Электронные медкарты, Электронные дневники).
Хайповые ли это темы? Возможно. Может ли в них быть место неправомерному использованию средств? Может, как и в любой другой сфере. Везде где есть люди есть место мошенничеству и воровству.
Хорошая статья, которая может стать отправной точкой для более глубокого изучения материала.
В случае с race condition допущена неточность. В ЯП с многозадачностью на потоках различают race condition и data race.
Состояние гонки – это когда корректность программы зависит от того, в каком порядке выполняются части кода. Частным случаем является TOCTOU проблема – когда в нескольких потоках делаем некую проверку, а потом исполняем код на основе этой проверки. Например, на балансе лежит 100руб, мы проверяем можем ли купить товар, допустим, за 90руб, и в случае успеха списываем. Если не делать синхронизации и запустить такой код в 2 потоках, то проверка на 100руб > 90руб успешно пройдет в обоих потоках и спишет 180руб, в итоге на балансе станет -80руб.
Гонка данных в свою очередь – это когда несколько потоков читают переменную, и хотя бы 1 поток пишет. Например, в одном потоке мы бегаем в цикле flag = true; while(flag); а в другом потоке меняет флаг flag = false; Без корректной синхронизации такой код может выполняться вечно.
Азотная кислота не состоит в списках веществ, оборот которых ограничен на территории РФ, в отличие от той же серной кислоты, ацетона или марганцовки. Тонну азотной кислоты вы вряд ли купите, но пару литров вполне продадут в магазине хим. реактивов. Могут попросить паспорт, но арестовывать точно никто не будет.
Если кандидат нас устраивает по хард/софт скилам, но попросил меньше, чем в среднем у нас получают сотрудники на данной должности, то мы дадим по уровню остальных. Мы стараемся выравнивать сотрудников по его грейду / зарплате на руки: каждый год делаем переоценку грейдов и делаем индексацию/повышение окладов.
Кандидат присылает резюме, в резюме многие сразу указывают желаемую ЗП. Если ЗП в резюме не указана, то hr спрашивает желаемый уровень. Если по резюме и ЗП я вижу, что бюджет позволяет, то мы назначаем встречу с hr и кандидатом, где уже устно общаемся, спрашиваем про опыт работы, я спрашиваю по техническим моментам. Если все устраивает - мы делаем оффер с озвученной кандидатом ЗП.
Возможно мы с вами подменяем понятия.
Если человек имеет какой-то опыт (даже на пет проектах), ответил на технические вопросы и приятен нам в общении, то мы такого возьмем, вероятно это уже больше чем просто "джун".
А если человек выходец с инфоцыганских курсов, который научился делать примитивные crud-приложения по шаблону и ничего больше не умеет, то это простой манки-кодер. Был бы у него потенциал, он бы расширил свои знания вширь, отточил сам на пет-проектах и стал бы чем-то большим.
Вообще, выходцы с курсов это коты в мешке, потому меня так это задевает. Мы уже несколько раз натыкались на таких, давали им шанс, понимая риски, и за испытательный срок они не вывозили. Сейчас более настороженно проводим собеседования.
Кандидату не надо угадывать. Кандидат озвучивает свой ценник на этапе первичного общения с HR. Смотрите в чем нюанс, если поставить в вакансии вилку ЗП условно от 1к$ до 3к$, то большинство кандидатов будут просить по максимуму, проверено на опыте.
Возможно, вы не так поняли. Если джун подошел по новыкам и попросил в пределах условной вилки ЗП, то мы его возьмем. Если же джун попросил сильно больше, например, 2к$, то скорее всего мы ему откажем. Как уже упоминал в других комментариях, мое подразделение в небольшом городе в глубинке, и так или иначе мы берем во внимание уровень жизни в нашем городе. У меня рука не поднимается платить зеленым джунам по 2 средние зп инженеров с завода. Я считаю это ненормально.
В другом ответе на комментарий я уже помянул. Я считаю неадекватным, когда приходят джуны с околонулевым опытом и сразу просят 2к$. Джун не может самостоятельно выполнять любые задачи, во многом нужна помощь и развитие, и при этом мы ему даем две средние зп инженеров местного завода. Я считаю это перебор.
Я привел конкретный пример: даже в моем городе на вакансии джунов приходят кандидаты, которые просят по 2к$. Джуны, которые полноценно не могут выполнять задачи. И вы считаете это нормально?
На самом деле все "зависит от". По своей практике найма, как руководителя разработки, могу подсветить пару моментов:
-- С одной стороны раздулся пузырь зарплат. До сво западные компании заманивали зп под 5к$ и более, и московские компании стали подтягиваться под этот ценник. В итоге даже в нашем Мухосранске джуниоры стали просить оклад под 2к$.
-- Качество джунов/миддлов сильно упало. Если раньше приходили выпускники профильных специальностей, которые МОГЛИ, то сейчас все чаще приходят выпускники инфоцыганских курсов, которые обучены делать только А и Б и совсем не знают базы.
Потому я бы перефразировал вашу фразу: на рынке дефицит специалистов по адекватному ценнику. Поэтому кстати и у нас скрыта вилка з/п. На собесе я провожу оценку опыта и знаний кандидата и предлагаю зп согласно его уровню и его ожиданиям.