All streams
Search
Write a publication
Pull to refresh
33
0.4
Send message

a = 10; b = 5; op = 4'b0000; #10;

что означает последнее #10 в этой строке?

Есть подозрение, что статья не настоящая, а нейросетевая.

Чтобы погрузиться в чужой код, нужно в среднем 15-20 минут. После ревью — еще столько же, чтобы вернуться к своей задаче.

Я сомневаюсь в этих числах.

Вывод: Один пулл-реквест стоит команде почти два дня задержки

С чего бы ожидание реквеста стоило всей команде задержки?

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

И почему в отсутствии линтера виновато review ?

Когда фича «висит» в ревью 2-3 дня, страдает вся команда. Разработчики теряют контекст, не могут двигаться дальше, вынуждены переключаться на другие задачи.

Как-то у вас разработчики быстро теряют контексты.

Статья - нейросетевой мусор с громкими заявлениями.

OpenJDK же выпущен под GPLv2, значит вы выкладываете исходники?

Я глянул SimpleDateFormat.parse(), его вполне можно вызывать в нескольких потоках

Не надо стандартизовать то, что написано в этой статье, потому что это и есть самый настоящий велосипед. Нет ни одной чисто технической причины делать так, только организационные. И очень много недостатков, которые самими авторами упомянуты. Считайте, что эта статья - упражнение по JDBC.

Было бы странно писать брокер сообщений, используя другой брокер или очередь.

Почему? Они же как раз выполняют то, для чего они вам нужны.

Эх, так и норовят программисты использовать базу данных как shared memory, а в любой shared memory сделать очередь.

Мне кажется, в методе readPartitions() пропустили цикл с rs.next().

Я не автор, но по прочитанному отвечу

  1. Теоретически неограниченно, практически продюсеры и консьюмеры параллельно взаимодействуют с таблицей. Все consumer-ы получают все сообщения.

  2. Event сохраняется в базу, а то, с какого места эти event-ы потребляются consumer-ом, зависит от consumer-а, решение не содержит персиста для полученных событий. Теоретически каждое событие имеет uuid, поэтому consumer защищается от повторной доставки, храня uuid-ы для какого-то количество недавно обработанных сообщений. Практически же на уровне таблицы этот uuid не является ключом, так что можно вставить один и тот же event несколько раз, но на уровне чтения повторы отбросятся.

  3. Task/Event - это просто вспомогательный флажок на event-е, чтобы дёрнуть соотвествующий метод. По факту оно всё event, нет доставки единственному получателю из всех слушающих.

jshell умеет делать autocomplete, если сначала импортировать нужные пакеты

180 увеличивает вертикальную координату шарика на 1 (смещает его вниз). 185 печатает пробел на старом месте, где был нарисован шарик, стирая его. 190 завершит цикл, перепрыгнув на 100, а 110 напечатает шарик на новом месте.

Это и есть почти вся игра. Сверху вниз вертикально летит шарик (буква "o"), снизу игрок (буква "U"), который может перемещаться горизонтально кнопками "o" и "p" (стандарт для игр спектрума). Игрок должен поймать шарик. Строка 135 - пустой цикл, который даёт временную задержку, так устанавливается скорость игры. Нужно добавить в начале что-то вроде

30 LET px = 20

Смысл смещения на 1 в строке 200 в том, что символ игрока печатается с пробелами слева и справа (для стирания предыдущего символа игрока при движении), поэтому горизонтальная позиция собственно игрока py+1

Там нет регистров и оно не программируется.

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

Насчёт ног - это ULA, универсальная микросхема, дорабатываемая под заказчика на заводе производителя.

Так много комментов про СССР и так мало про ZX Spectrum. А я вот что думаю: спектрумы появились в восточной Европе и СССР только потому, что кто-то смог заменить рассыпухой ULA-микросхему, которую, в отличие от Z80, нельзя было купить. После этого появилась возможность клонировать. Вот как они ULA реверсили? Сидели с осцилографом, очень-очень медленно тактовали всю схему, и смотрели, на каких дорожках какой сигнал? Там же не так всё просто, счётчики скан-линий, латчи для байтов из памяти, сдвиговые регистры...

У меня есть несколько проблем с вашими текстами.

Первая проблема: я сильно подозреваю, что в программировании вы понимаете исчезающе мало, но при этом публикуете статьи на программисткие темы на программистском ресурсе. С высокой вероятностью всю программистскую часть ваших статей генерит нейросетка, и генерит банальщину. Зачем вы это делаете - я хз, возможно хотите пустить пыль в глаза коллегам-филологам, что публиковали у программистов, возможно хотите набайтить комментов и нарыть в них идеи для новых промптов нейросетке, чтобы наполнить материальчик. Но тут вы продаёте свои тексты как гуманитарное откровение для тупых технарей.

Вторая проблема: какую "глубинную" связь вы ищете? Код и разрабатывался для того, чтобы быть как человеческий язык, читаемым и легким в написании, поэтому на него естественно перенеслись все особенности человеческого языка. "Глубинная" связь не является магическим открытием, она сделана специально, и это тривиальный факт.

Нейросетка продолжает словоблудить. Какая к чёрту "полисемия" в функции len(), она делает ровно одну вещь во всех случаях, это одна семантика.

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

Ценность статьи невысокая, нет никакой острейшей необходимости привлекать в программирование филологию, важность проблемы с именами надумана.

Привет! Я снова душнить пришёл.

Из-за сегментной архитектуры x86, далёкий адрес строится таким образом:

let far_addr: u32 = (segment << 4) | offset (20 бит физический адрес)*
А чтобы его разобрать на составные части, придется делать уже две
операции, а не одну.

let segment: u16 = far_addr >> 16;
let offset : u16 = far_addr & 0xFFFF;

Я очень рекомендую не использовать операцию or для склеивания segment и offset: если окажется, что offset больше, чем 15, то биты наложатся и будет очень плохо. Лучше использовать сложение. В операции разложения дальнего адреса на segment и offset у вас большие ошибки: segment надо сдвигать вправо не на 16, а на 4, а для получения offset делать & 0x000F.

И так, чисто для связности изложения: то, что у вас в формуле расчёта размера программы обозначено как pages - это e_cp из MZ-заголовка, а size - это e_cblp.

 А токарь вполне себе может не понимать чем дюймовая резьба отличается от метрической.

У вас очень плохое представление о токарях. Конечно же он не может этого не понимать.

1
23 ...

Information

Rating
2,153-rd
Registered
Activity