Давайте признаемся: подавляющее большинство пишет Java код, используя JetBrains IntelliJ IDEA Ultimate. Да, это отличная IDE. Для нее есть большое количество расширений, среда очень тесно интегрируется с Spring Framework и знает его особенности.
Тогда зачем пробовать что‑то другое?
Привет, Хабр! Меня зовут Константин Шибков, я Java‑разработчик в CDEK.
В какой‑то мере все Java‑разработчики стали заложниками IDEA. Она так привычна, что нет желания пробовать другое. Ведь всё такое удобное и знакомое за столько лет использования.
Но если у вас есть трудности с доступом к Ultimate версии, а Community вариант не достаточно функционален — самое время попробовать современную альтернативу — Visual Studio Code.
В статье делюсь опытом подготовки среды разработки и изучения вопроса: «А можно ли перейти на VSCode?».
HttpClient так, чтобы не получать 429 Too Many Requests.
Предисловие: этот пост представляет собой очень длинный перечень мыслей и проблем, возникавших у меня за годы работы; также в нём рассматриваются некоторые из аргументов, которые мне часто говорили. В посте выражено моё мнение, сформировавшееся у меня в процессе разработки игр на Rust в течение многих тысяч часов на протяжении многих лет и после множества завершённых игр. Это не хвастовство и не показатель успеха, я просто хочу сказать, что вложил достаточно много усилий в Rust; здесь не получится сказать «когда наберёшься опыта, тебе всё станет понятно».
Пост не будет ни научной оценкой, ни A/B-исследованием. Это моё личное мнение после разработки игр на Rust маленькой инди-командой (два человека) в попытках заработать достаточно денег, чтобы финансировать процесс. Мы не одни из тех разработчиков с бесконечными финансами от инвестора и многолетним запасом времени. Если вы находитесь в этой категории и получаете удовольствие от многолетней разработки систем, то всё написанное ниже к вам не относится. Я рассматриваю всё с такой точки зрения: «Мне хочется создать игру максимум за 3-12 месяцев, чтобы люди могли сыграть в неё, а я — немного заработать». Статья не написана с точки зрения «Я хочу изучить Rust, а разработка игр — это весело», хотя это и вполне нормальная цель; просто она никак не согласуется с тем, чего хотим мы — заниматься разработкой игр коммерчески успешным и самодостаточным образом.
Мы выпустили несколько игр на Rust, Godot, Unity и Unreal Engine, и многие люди сыграли в них в Steam. Мы создали с нуля собственный игровой 2D-движок с простым рендерером, а также в течение нескольких лет использовали Bevy и Macroquad во многих проектах, некоторые из которых были очень нетривиальными. Кроме того, я бэкенд-разработчик на полную ставку и пишу код на Rust. Этот пост — не какое-то поверхностное мнение после изучения нескольких туториалов или разработки небольшой игры для геймджема. За три с лишним года мы написали сильно больше ста тысяч строк кода на Rust.
Задача этого поста — развеять популярные и часто повторяемые аргументы. Но это всё-таки субъективное мнение; по большей части я написал пост, чтобы не объяснять снова и снова одно и то же. Пусть это будет справочный материал о том, почему мы, скорее всего, откажемся от Rust как от инструмента для разработки игр. Мы ни в коем случае не планируем прекращать создавать игры, просто не будем делать это на Rust.
Когда я только знакомился с принципами SOLID, я искал понятные статьи на Хабр. При этом пришлось прочитать не одну статью, и полное понимание пришло сильно позже. Хотелось бы, чтобы новички на более простых примерах смогли почувствовать, о чем эти принципы.
Привет! Меня зовут Александр Каленюк, и я крепко подсел на C++. Пишу на C++ 18 лет кряду, и все эти годы отчаянно пытаюсь избавиться от этой разрушительной зависимости.
Всё началось в конце 2005 года, когда мне довелось писать движок для симуляции 3D-пространства. В этом движке было буквально всё, чем язык C++ мог похвастаться в 2005 году. Трёхзвёздочные указатели, восьмиуровневые зависимости, C-подобные макросы повсюду. Кое-где – вкрапления ассемблера. Итераторы в стиле Степанова и мета-код в стиле Александреску. В общем, всё. Кроме ответа на самый важный вопрос: зачем?
Привет, Хабр!) Меня зовут Ильяс. В этой статье мы разберём известную идею — keepalive в межсервисном взаимодействии, которая спасла уже не одну компанию в трудное время :). Но чтобы добавить интереса, мы разберём, какие проблемы в keepalive принесли современные технологии (ведь что может пойти не так с этой простой идеей?). Поэтому в статье мы рассмотрим механизмы, которые позволяют проверять стабильность соединения между клиентом и сервером в случае, когда обычные TCP keepalive из-за сложности архитектуры не могут определить состояние сервера.
В комментариях к моей предыдущей статье и в комментариях к ролику было много вопросов и некорректных замечаний по поводу парадокса близнецов. Как оказалось, мое объяснение оказалось не настолько понятным, как я надеялся, поэтому в этой статье я решил максимально наглядно, подробно и последовательно объяснить парадокс близнецов и ответить на некоторые другие вопросы.
Кратко напомню суть парадокса
Берем двух близнецов, сажаем их на маленькую легкую планету (легкую, чтобы не учитывать влияние гравитации), одного оставляем неподвижным, а второго запускаем на ракете полетать и вернуться обратно. При их встрече оказывается, что летавший близнец постарел меньше, чем неподвижный.
Парадокс заключается в том, что неочевидно почему именно у летавшего время текло медленнее. Ведь, вроде бы, ситуация симметричная: в системе отсчета летавшего он был неподвижен, а планета с неподвижным близнецом полетала и вернулась, и это у них должно было натикать меньше времени.
Парадокс близнецов очень важен, т.к. это самый наглядный способ увидеть, что релятивистский эффект замедления времени не просто математический артефакт специальной теории относительности или иллюзия, а вполне реальное физическое явление.
Попросим бегущего кота четыре секунды (по его часам) бежать вправо со скоростью 75% скорости света, потом развернуться и прибежать с той же скоростью назад.
Вот визуализация на диаграмме.
На скриптовых языках удобно разрабатывать… И на этом удобство заканчивается. Вне машины разработчика начинаются проблемы. Особенно если вы пишете какой-то прикладной тулинг — cli-утилиты, вспомогательные приложения в вашем SDK и прочее. Вы даже не можете рассчитывать на то, что у пользователя будет pip, чтобы он смог поставить все ваши зависимости, вам все нужно организовать самостоятельно.
В этой статье поговорим о различных формах распространения Python-приложений. Какие есть подходы и инструменты, почему они могут не сработать и как чинить возникающие проблемы.
Если вам покажется, что в чем-то я ошибаюсь, добро пожаловать в комментарии. Буду рад услышать любые альтернативные точки зрения. Кроме, как я уже отметил в заголовке, рекомендации переписать все на Go/Rust/You name it :) Этот холивар мы уже проходили.
Боты под управлением системы GOAP (Goal Oriented Action Planning), источник
.NET разработчики знают, что такое ждать сборки кода. Работать при этом невозможно: пока не увидишь, как обновится приложение, — не перейдешь к следующему шагу. А переключиться на другую задачу за это время не успеешь. Получается, если в день переписать код 5 раз, можно потерять полчаса при сборке, а то и больше.
Теперь на примере платформы автоматизации маркетинга Mindbox. Основное программное решение — это монолит на C#: несколько миллионов строк, 50 проектов, над которыми одновременно работают десятки команд. Даже сэкономленная при сборке минута выливается в кучу продуктивных человеко-часов. Поэтому, когда речь зашла о переходе всей компании на MacBook в будущем, мы решили выяснить, как это отразится на производительности.
node_modules.
В 2020 году я опубликовал здесь статью, в которой описал свой советский растровый микроскоп МРЭМ-200 1987 года выпуска. Мне было приятно, что статья вызвала большой интерес и помогла мне познакомиться с людьми со схожими увлечениями.
Хочу рассказать о дальнейшей судьбе микроскопа и его усовершенствованиях. В статье хочу рассказать о внедрении системы прямого ввода изображения с микроскопа в компьютер и его последующей обработкой программными средствами.
За прошедшие годы микроскоп подвергся нескольким модернизациям, об одной из которых хочется рассказать. В 80-е годы изображения с мониторов микроскопа фиксировались для дальнейшего изучения и сохранения с помощью пленочного фотоаппарата. Для этого в комплекте с микроскопом шла специальная тубусная приставка, фиксирующаяся на мониторе. В третьем тысячелетии мне хотелось, конечно, уже иметь компьютерный захват картинки, как в современных растровых микроскопах. В начале я пошел по самому простому пути: стал использовать цифровой фотоаппарат Canon вместо пленочного фотоаппарата. Поскольку построение изображения в максимальном разрешении длится 41 секунду, мне пришлось перепрошить фотоаппарат на такую длительную выдержку. Работа с микроскопом сразу стала комфортней, но я понимал, что есть еще к чему стремиться.
В декабре 2022 года в Телеграмме я познакомился с еще одним владельцем микроскопа МРЭМ-200. В этой статье я буду, называть этого человека, по его просьбе, «Владелец МРЭМ-200 из Москвы, пожелавший остаться анонимным». Он решил проблему прямого компьютерного захвата, использовав видео с youtube (https://www.youtube.com/watch?v=ruuxn2u3yao) известного американского популяризатора науки Бена Краснова (Ben Krasnow). «Владелец МРЭМ-200 из Москвы, пожелавший остаться анонимным» творчески переработал информацию Бена Краснова, адаптировал софт под технические особенности своего микроскопа и любезно поделился со мной этим софтом. У меня появилась программа, которая замечательно строила и сохраняла изображение на экране компьютера синхронно с изображением на родных мониторах микроскопа. Между компьютером и микроскопом добавился отдельный модуль согласования, в котором помещался АЦП с выходом USB и операционные усилители с регулировкой коэффициента усиления: