Какой самый смешной будет вариант? А. Раскроется, что это все же была LLM. Б. Это все же была LLM, но никто не узнает. В. Автор настоящий и его заминусуют за недоверие к "вежливому" паттерну.
Тоже об этом подумал. Если Array - это объект, то проверять, что он isArray вообще смысла не имеет. А если это неймспейс, то тут вопрос, возможно что-то вроде Array.isTypeOf(), но если импортировали всё из неймспейса, то останется просто isTypeOf()... Думаю зависит от конкретного языка и того, как обычно это используют.
Вот такие же размышления были по этому поводу, но решает обычно суд уже с правильной подачи фактов адвокатом, а при неправильной подаче есть еще обычно апелляция (при условии уверенности доказуемости правоты).
Я сам не пробовал моделировать физику связи в NFC, но насколько я понимаю, магнитное поле от антенны, скажем, телефона на расстоянии более 20 см будет слабее шумов, что и не позволяет сделать считыватель с больших расстояний.
Ну это скорее всего не так уж и сложно. Например, может быть конденсатор, которого гарантированно хватит на обработку одного блока. При потере питания последний блок обрабатывается и обработка останавливается.
Года 2 назад все решалось покупкой роутера на 5 Ггц — снова превосходное качество сети. Сейчас же сканером нашел около 20+ точек на 5 Ггц вокруг. Пинг скачет от 2 мс до 300 мс и иногда потери даже. Смены каналов особо не помогают уже, как и любые другие перенастройки. Единственное, что помогло — это покупка роутера, который умеет пространственное разделение делать (с 4 антеннами), но тоже далеко от идеала работает, хоть и лучше. Соединил в квартире, что можно было, через powerline адаптеры.
У нас как-то вирус был. Он патчил хром и добавлял уведомления с их сайтов и естественно эти уведомления нельзя было нигде выключить. После удаления хрома и установки заново, день работал без проблем и потом по-новой. Пока все не почистили от вирусов.
Ну так и далее через 50 лет может быть возможно будет намного проще считать магнитное, как и сейчас соорудить считыватель перфокарт?
Представьте: «берем универсальный магнитный считыватель и контролируемый двигатель для перемотки, запускаем прогу считывания разнообразных данных с автоматическим преобразованием в нужные форматы и через часик кассета считана».
Вот например, раньше для сканирования листа А4 нужно было покупать сканер, а сейчас фотку с телефона сделал в специальной проге и готово.
Коворкинга «3-е место» кажись уже нет. А когда был и там бывал, то интернет был через йоту — далеко не лучший вариант для звонков. Есть и по-лучше коворкинги в этом плане.
Немного странный вывод, если честно. Никогда меня это не останавливало от хорошего обдумывания названий переменных, и создания классов-оберток. По Вашему выходит «отвлекаешься от работы = пишешь хороший и понятный код»?
Я конечно понимаю, что связь теоретически может быть, но также прекрасно вижу людей, не обремененных большим количеством контекста в голове, отвлекающихся на мелочи и пишущих $ax4 = $bc3 + 13.
Я и сам когда-то так писал, пока не осознал суть проблемы и прочитав разные советы/книги/рекомендации начал писать нормальный код, ответственно подходя к понятности кода для других разработчиков в командах.
Вижу много не согласных, возможно это работает только со мной. Но написание большого количества логики сразу и потом сборка и проверка у меня выходит намного лучше, быстрее и содержит меньше ошибок. За последние 10 лет много раз проверял это и у меня это работает.
Всегда стараюсь заниматься самоанализом и, я так понимаю, работает это следующим образом. Если я не отвлекаюсь, то количество логики, которое я держу в уме, увеличивается гораздо и позволяет избежать ошибок в самой логике. В то же время IDE позволяет не ошибаться в типизации.
В противоположном случае, при паузах на сборку, мозг переключается на другие вещи/задачи/уведомления и теряется концентрация на логике. В результате у меня получается и больше времени на сборки/проверки и ближе к концу может обнаружиться какая-то необдуманная ситуация.
Для меня это работало и в 2000-ых на большом проекте на Delphi и работает сейчас на большом проекте на PHP. Хотя очень часто так и хочется проверить/отдебажить какой-то маленький кусочек кода (думаю приносит немного эндорфина).
Было бы интересно, если бы кто-то еще свои наблюдения рассказал по этому поводу, а не голые непроверенные утверждения.
@IBDesignable — это другой уровень, тут вопросов нет.
Когда-то работал в PHPStorm с большим PHP-Symfony проектов на MacBook Pro 13 2011 с установленными 16 GB памяти, в котором я тоже стал использовать RamDisk (сделал bash rsynс-скрипты для автоматизации создания диска и обратного копирования). Так работал проект в целом раза в 3 быстрее (обработка запросов, создание кэша) и намного быстрее стал работать PHPStorm с проектом. Пока не купил SSD, это было прям таки спасение. Но с покупкой SSD стало не актуально.
Много раз проводил собеседования, спрашивал и про SOLID в том числе. Спрашивал не для того, чтобы «завалить» на этом, а чтобы понять, насколько интересуется теорией человек. Нанимали несколько раз ребят, которые отвечали на часть вопросов только, но имели большое желание работать. Но в итоге их увольняли через несколько месяцев, т.к. за ними приходилось все переделывать. Простые сайты они то без проблем сделают и пофиксят какие-то мелкие ошибки. Но вот разработку, где нужно все продумать заранее, сделать абстрактные классы (чтобы 10 раз одно и то же не писать и ограничить возможности ошибок) они не могли.
Самая ГЛАВНАЯ проблема с ними в том, что без использования этих правил/принципов они писали код, который попросту нормально не работал — куча ошибок и непродуманных ситуаций. Причем в этой компании бизнесу без разницы какие они клевые, а главное, чтобы задача была выполнена и работала. Но частые ошибки приводили к возврату задач, а далее топы увольняли их, и потом мы переписывали все сами.
Брали человека, который ответил на все мои вопросы. Он мог исправить любую проблему и написать готовый код, который в будущем легко масштабируется и не содержит ошибок. Правда ушел позже на более интересный проект.
Все эти теоретические знания, шаблоны, принципы не просто так придумываются, а для решения многих проблем разработки. И если человек этого не знает, он будет вновь и вновь сам для себя их открывать по мере развития.
Надо просто писать больше кода между сборками.
2 строки кода, сборка, 2 строки, сборка — это так некоторые программисты генерируют видимость деятельности.
На самом деле себя тоже ловил на мысли, что я только и делаю, что тестирую (собираю) после каждого кусочка. Стал писать сразу много кода за раз — производительность работы возросла.
Мешает принцип установки связи между устройствами, который зависит не только от мощности сигнала. Так бы давно уже люди ходили с супер большими антеннами и читали карты.
Есть такое ощущение, что сейчас уже много таких.
Какой самый смешной будет вариант?
А. Раскроется, что это все же была LLM.
Б. Это все же была LLM, но никто не узнает.
В. Автор настоящий и его заминусуют за недоверие к "вежливому" паттерну.
(и да, мне тоже напоминает LLM)
Тоже об этом подумал. Если Array - это объект, то проверять, что он
isArrayвообще смысла не имеет. А если это неймспейс, то тут вопрос, возможно что-то вродеArray.isTypeOf(), но если импортировали всё из неймспейса, то останется простоisTypeOf()... Думаю зависит от конкретного языка и того, как обычно это используют.Вот такие же размышления были по этому поводу, но решает обычно суд уже с правильной подачи фактов адвокатом, а при неправильной подаче есть еще обычно апелляция (при условии уверенности доказуемости правоты).
Думается мне continue настолько же goto, насколько while является return'ом.
Пример кода из свежей Symfony:
Там далеко не джуниоры пишут проект, как мне кажется.
Я сам не пробовал моделировать физику связи в NFC, но насколько я понимаю, магнитное поле от антенны, скажем, телефона на расстоянии более 20 см будет слабее шумов, что и не позволяет сделать считыватель с больших расстояний.
Ну это скорее всего не так уж и сложно. Например, может быть конденсатор, которого гарантированно хватит на обработку одного блока. При потере питания последний блок обрабатывается и обработка останавливается.
Представьте: «берем универсальный магнитный считыватель и контролируемый двигатель для перемотки, запускаем прогу считывания разнообразных данных с автоматическим преобразованием в нужные форматы и через часик кассета считана».
Вот например, раньше для сканирования листа А4 нужно было покупать сканер, а сейчас фотку с телефона сделал в специальной проге и готово.
А задроты-физики? А биологи?
А что есть задрот вообще? почему это плохо или хорошо?
Я конечно понимаю, что связь теоретически может быть, но также прекрасно вижу людей, не обремененных большим количеством контекста в голове, отвлекающихся на мелочи и пишущих $ax4 = $bc3 + 13.
Я и сам когда-то так писал, пока не осознал суть проблемы и прочитав разные советы/книги/рекомендации начал писать нормальный код, ответственно подходя к понятности кода для других разработчиков в командах.
Вот пример: обматывал больше года назад, немного уже потерлось, но можно легко перемотать.
Всегда стараюсь заниматься самоанализом и, я так понимаю, работает это следующим образом. Если я не отвлекаюсь, то количество логики, которое я держу в уме, увеличивается гораздо и позволяет избежать ошибок в самой логике. В то же время IDE позволяет не ошибаться в типизации.
В противоположном случае, при паузах на сборку, мозг переключается на другие вещи/задачи/уведомления и теряется концентрация на логике. В результате у меня получается и больше времени на сборки/проверки и ближе к концу может обнаружиться какая-то необдуманная ситуация.
Для меня это работало и в 2000-ых на большом проекте на Delphi и работает сейчас на большом проекте на PHP. Хотя очень часто так и хочется проверить/отдебажить какой-то маленький кусочек кода (думаю приносит немного эндорфина).
Было бы интересно, если бы кто-то еще свои наблюдения рассказал по этому поводу, а не голые непроверенные утверждения.
@IBDesignable — это другой уровень, тут вопросов нет.
Самая ГЛАВНАЯ проблема с ними в том, что без использования этих правил/принципов они писали код, который попросту нормально не работал — куча ошибок и непродуманных ситуаций. Причем в этой компании бизнесу без разницы какие они клевые, а главное, чтобы задача была выполнена и работала. Но частые ошибки приводили к возврату задач, а далее топы увольняли их, и потом мы переписывали все сами.
Брали человека, который ответил на все мои вопросы. Он мог исправить любую проблему и написать готовый код, который в будущем легко масштабируется и не содержит ошибок. Правда ушел позже на более интересный проект.
Все эти теоретические знания, шаблоны, принципы не просто так придумываются, а для решения многих проблем разработки. И если человек этого не знает, он будет вновь и вновь сам для себя их открывать по мере развития.
2 строки кода, сборка, 2 строки, сборка — это так некоторые программисты генерируют видимость деятельности.
На самом деле себя тоже ловил на мысли, что я только и делаю, что тестирую (собираю) после каждого кусочка. Стал писать сразу много кода за раз — производительность работы возросла.