Вы явно путаете ООП и программирование с использованием классов и объектов. Простое оборачивание вашего процедурного кода в обертки из классов не делает его ОО кодом.
В случае CD обычно код без тестов не пропустит пайплайн.
А во вторых — ни один нормальный разработчик не согласится деливерить свой код не будучи уверенным в том, что он работает.
Нет, бывают просто объемные задачи для решения которых надо написать большое количество кода.
Особенно, когда работаешь по TDD и у тебя CD, тогда бывает, что на небольшую, понятную задачу надо написать до сотни тестов.
Некоторое время велся на подобные штуки, переживал по поводу проектов и все такое. А потом понял, что мое рабочее время — 8 часов в день. И если я не смог выполнить работу за это время — это не моя проблема. И задержаться на часик сегодня я могу только, если завтра я на этот самый часик меньше поработаю. И вот как-то аж легче жить стало.
Хм. Ну не знаю, если бы я увидел в вакансии QT/Linux, то в первую очередь мне на ум пришли бы ТВ приставки, автомобильная и другая встраиваемая электроника (только нативная, а не поделки на андроиде). Это то, чем занимается большинство моих знакомых QTшников.
Несмотря на то, что статья получила большое количество минусов — в карме у вас плюс.
А это большая редкость.
То есть сообществу не понравилась ваша статья, но понравились лично вы.
Так что сделайте выводы — полезных советов вам, действительно, дали достаточно и не унывайте.
На мой взгляд проблема в том, что ты мечешься от одного к другому.
Это не есть хорошо. Нужно наращивать экспертность. И, по сути, неважно что это будет за язык.
Для старта я бы выбрал что-то довольно старое, строго типизированное и объектно-ориентированное. C# или Java подойдут идеально.
Для старта — никаких фреймворков — только чистый язык и стандартная библиотека.
И далее потрать на изучение этого 1000 часов. Изучение, я имею ввиду 20 процентов чтения документации и книг и 80 процентов попыток решения практических задач. Да, хотя бы, с того же leetcode.
Тогда, может быть, что-нибудь из этого и выйдет.
А иначе никак. Программирование — это не развлечение, а труд. И достичь мастерства можно только постоянно практикуясь, причем постоянно углубляя свои знания.
Использование статических методов, это очень профессионально
Наверное, лекциями Егора Бугаенко увлекаетесь?
Так вот, static — это нормально в двух случаях:
1. Когда у нас утилитная функция и она идемпотентна. Такие функции не надо мокать. Тот же Apache Commons на 90 процентов состоит из таких функций. И их использование — это хорошая практика.
2. При обращении к ThreadLocal. Как бы некоторые эксперты не критиковали подобный механизм многие задачи без него просто не решаются. Например, попробуйте решить задачу сквозного прокидывания в логи уникального requestId запроса. Не переписывая при этом половины проекта. SecurityContextHolder внутри как раз и держат ThreadLocal. Так что ничего зазорного в том, чтобы обратиться к нему нет.
А вот в остальных ситуациях статические методы это действительно зло. Классический пример такого зла это System.currentTimeMillis(), который, к слову, не мокается вообще ничем.
Смысл JWT токена как раз в том, что он нигде не хранится. Поэтому отозвать его нельзя. Отзывается, обычно, как раз refresh токен.
На каких нескольких?
RBAC на уровне контроллера/сервиса/репозитория. С союзом И. Служит для того, чтобы в случае ошибки программиста не дать пользователю с правами READ право записать что-то в базу.
можно и через хедер.
Конечно, можно. Но только его надо где-то будет хранить на стороне браузера. Обычно это local/session storage. А к нему имеет доступ клиентский javascript. Привет компрометации токена.
как пробросить авторизованного юзера в метод контроллера
Есть такие штуки, как лучшие практики. И перед тем как предлагать production-ready решение, а уж тем более писать статьи об этих решениях на профильные ресурсы их лучше изучить.
Хороший пример как делать не надо.
Время жизни токена 24 часа? А как в случае его компрометации его отзывать? Для этого существует подход с access/refresh токенами.
RBAC? Проверка уровней доступа на нескольких уровнях? Сделайте его кастомно и получится Spring Security.
Передача токена в заголовках? Исходя из вашей статьи вы разрабатываете сайты, то есть токен хранится на фронте.
Если да, то токены должны храниться только в куках с HTTP/Secure only. Иначе компрометируется это удовольствие на ура.
В аутсорсинговых/аутстаффинговых компаниях возникает такая проблема, что сотрудники часто ассоциируют себе с компанией-заказчиком, а не компанией-работодателем.
Но на самом деле работают они то на работодателя и подобные вопросы — это компетенция работодателя.
Да, заказчик может каким-то образом повлиять на решение данного вопроса, но все-равно это интимное дело компании-работодателя.
Это все-равно, что жена предъявляла претензии мужу по поводу того, что ей нравится или не нравится в сексе не лично мужу, а привлекала к обсуждению всех родственников.
Почему? Ведь как раз 2 из 3 говорит, что если вы делаете работу долго и с умом, то не обязательно напрягаетесь и так далее. Вообще можно погуглить про их Leadership Principles по которым собственно и оценивают кандидатов.
Но, конечно, это не касается складов и логистики — там ад, конечно.
В появлении сленговых слов/выражений обычно есть какой-то утилитарный смысл, обычно это банальная экономия букв. Но, в тоже время, сленг должен быть понятен и произносим. Поэтому дс = data scientist — я не представляю как это можно употребить и понять.
А вот репа = репозиторий и постгря = postgreSQL прижилось.
И именно поэтому обычно говорят джава, а не используют сленговое жаба ибо экономии 0, а потратить мыслетопливо на расшифровку сленгового обозначения необходимо
У Амазона есть этап интервью на котором обсуждается соответствие кандидата ценностям Амазона. Тем не менее Амазон один из лучших работодателей. Так что обсуждение корпоративных ценностей на берегу вообще не показатель
В реальности все немного сложнее и арбитраж не является безрисковой сделкой.
Так в вашем примере доллары за евро вы купили, а вот евро за доллары по той цене на которую вы рассчитывали уже нет — их кто-то уже купил. Например, такой же арбитражник.
Размеры лотов, на самом деле не безлимитны и текущая цена может поменять за то время, пока вы принимали решение.
А это время включает в себя период обновления стакана на бирже, сетевая задержка к вам, расчет алгоритмами, сетевая задержка обратно.
В лучшем случае это сотни миллисекунд, в худшем — несколько секунд (например, когда стакан отдается не чаще чем раз в 3 секунды, хоть ты тресни).
Если вы хотели написать действительно интересную статью, а не из серии «капитан очевидность», я бы советовал включить следующие пункты:
— акцент на том, что нужен не только реальный, но и статический айпишник. Также что делать если статический не дают
— как рулить фаерволом — какие варианты. Какие достоинства/недостатки каждого из них.
— как выпускать и продлять SSL сертификаты. Настройка перенаправления с HTTP на HTTPS
— настройка автоматизированного мониторинга. htop — ни о чем
Ну и так далее. Больше системности, больше проблематики.
Вы явно путаете ООП и программирование с использованием классов и объектов. Простое оборачивание вашего процедурного кода в обертки из классов не делает его ОО кодом.
Как пример:
А во вторых — ни один нормальный разработчик не согласится деливерить свой код не будучи уверенным в том, что он работает.
Особенно, когда работаешь по TDD и у тебя CD, тогда бывает, что на небольшую, понятную задачу надо написать до сотни тестов.
А это большая редкость.
То есть сообществу не понравилась ваша статья, но понравились лично вы.
Так что сделайте выводы — полезных советов вам, действительно, дали достаточно и не унывайте.
Это не есть хорошо. Нужно наращивать экспертность. И, по сути, неважно что это будет за язык.
Для старта я бы выбрал что-то довольно старое, строго типизированное и объектно-ориентированное. C# или Java подойдут идеально.
Для старта — никаких фреймворков — только чистый язык и стандартная библиотека.
И далее потрать на изучение этого 1000 часов. Изучение, я имею ввиду 20 процентов чтения документации и книг и 80 процентов попыток решения практических задач. Да, хотя бы, с того же leetcode.
Тогда, может быть, что-нибудь из этого и выйдет.
А иначе никак. Программирование — это не развлечение, а труд. И достичь мастерства можно только постоянно практикуясь, причем постоянно углубляя свои знания.
Наверное, лекциями Егора Бугаенко увлекаетесь?
Так вот, static — это нормально в двух случаях:
1. Когда у нас утилитная функция и она идемпотентна. Такие функции не надо мокать. Тот же Apache Commons на 90 процентов состоит из таких функций. И их использование — это хорошая практика.
2. При обращении к ThreadLocal. Как бы некоторые эксперты не критиковали подобный механизм многие задачи без него просто не решаются. Например, попробуйте решить задачу сквозного прокидывания в логи уникального requestId запроса. Не переписывая при этом половины проекта. SecurityContextHolder внутри как раз и держат ThreadLocal. Так что ничего зазорного в том, чтобы обратиться к нему нет.
А вот в остальных ситуациях статические методы это действительно зло. Классический пример такого зла это System.currentTimeMillis(), который, к слову, не мокается вообще ничем.
Смысл JWT токена как раз в том, что он нигде не хранится. Поэтому отозвать его нельзя. Отзывается, обычно, как раз refresh токен.
RBAC на уровне контроллера/сервиса/репозитория. С союзом И. Служит для того, чтобы в случае ошибки программиста не дать пользователю с правами READ право записать что-то в базу.
Конечно, можно. Но только его надо где-то будет хранить на стороне браузера. Обычно это local/session storage. А к нему имеет доступ клиентский javascript. Привет компрометации токена.
SecurityContextHolder.getContext().getAuthentication()
Есть такие штуки, как лучшие практики. И перед тем как предлагать production-ready решение, а уж тем более писать статьи об этих решениях на профильные ресурсы их лучше изучить.
Время жизни токена 24 часа? А как в случае его компрометации его отзывать? Для этого существует подход с access/refresh токенами.
RBAC? Проверка уровней доступа на нескольких уровнях? Сделайте его кастомно и получится Spring Security.
Передача токена в заголовках? Исходя из вашей статьи вы разрабатываете сайты, то есть токен хранится на фронте.
Если да, то токены должны храниться только в куках с HTTP/Secure only. Иначе компрометируется это удовольствие на ура.
Есть одна проблема. Await блокирует вызывающий поток и весь смысл асинхронности теряется. Так что код который вы написали не асинхронный аж никак.
Но на самом деле работают они то на работодателя и подобные вопросы — это компетенция работодателя.
Да, заказчик может каким-то образом повлиять на решение данного вопроса, но все-равно это интимное дело компании-работодателя.
Это все-равно, что жена предъявляла претензии мужу по поводу того, что ей нравится или не нравится в сексе не лично мужу, а привлекала к обсуждению всех родственников.
Но, конечно, это не касается складов и логистики — там ад, конечно.
А вот репа = репозиторий и постгря = postgreSQL прижилось.
И именно поэтому обычно говорят джава, а не используют сленговое жаба ибо экономии 0, а потратить мыслетопливо на расшифровку сленгового обозначения необходимо
У Амазона есть этап интервью на котором обсуждается соответствие кандидата ценностям Амазона. Тем не менее Амазон один из лучших работодателей. Так что обсуждение корпоративных ценностей на берегу вообще не показатель
Так в вашем примере доллары за евро вы купили, а вот евро за доллары по той цене на которую вы рассчитывали уже нет — их кто-то уже купил. Например, такой же арбитражник.
Размеры лотов, на самом деле не безлимитны и текущая цена может поменять за то время, пока вы принимали решение.
А это время включает в себя период обновления стакана на бирже, сетевая задержка к вам, расчет алгоритмами, сетевая задержка обратно.
В лучшем случае это сотни миллисекунд, в худшем — несколько секунд (например, когда стакан отдается не чаще чем раз в 3 секунды, хоть ты тресни).
— акцент на том, что нужен не только реальный, но и статический айпишник. Также что делать если статический не дают
— как рулить фаерволом — какие варианты. Какие достоинства/недостатки каждого из них.
— как выпускать и продлять SSL сертификаты. Настройка перенаправления с HTTP на HTTPS
— настройка автоматизированного мониторинга. htop — ни о чем
Ну и так далее. Больше системности, больше проблематики.