Вот такие же размышления были по этому поводу, но решает обычно суд уже с правильной подачи фактов адвокатом, а при неправильной подаче есть еще обычно апелляция (при условии уверенности доказуемости правоты).
Я сам не пробовал моделировать физику связи в 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 строки, сборка — это так некоторые программисты генерируют видимость деятельности.
На самом деле себя тоже ловил на мысли, что я только и делаю, что тестирую (собираю) после каждого кусочка. Стал писать сразу много кода за раз — производительность работы возросла.
Мешает принцип установки связи между устройствами, который зависит не только от мощности сигнала. Так бы давно уже люди ходили с супер большими антеннами и читали карты.
Ни «спасибо», ни «вы ничего не знаете о ...» читать в комментариях на техническом ресурсе не интересно ни капли, в отличие от «оператор Х обладает сайдэффектом Y (из документации ссылка Z)».
Спасибо — стрелка вверх. Не интересно — иди дальше. Бесполезный/вводящий в заблуждение материал/совсем велосипед — стрелка вниз.
В комментарии технические вопросы-ответы по делу без перехода на личности вообще.
Есть пример по-проще. Не так давно в проекте надо было почистить кэш, пальцы делают уже автоматически, но они иногда ошибаются.
В итоге вместо $ rm -rf app/cache
написал $ rm -rf app /cache
То есть добавил всего один пробел случайно перед слэшем. В итоге удаленная директория app целиком. Пришлось повозиться немного с восстановлением файлов в IDE, хорошо, что все в истории есть.
Между тем через много лет :)
python3: 38.629s
php7: 11.693s
node5: 1.893s
java8: 0.546s
неприятно удивил питон, думал он будет наравне с php по математике или даже быстрее
Вот такие же размышления были по этому поводу, но решает обычно суд уже с правильной подачи фактов адвокатом, а при неправильной подаче есть еще обычно апелляция (при условии уверенности доказуемости правоты).
Думается мне continue настолько же goto, насколько while является return'ом.
Пример кода из свежей Symfony:
Там далеко не джуниоры пишут проект, как мне кажется.
Я сам не пробовал моделировать физику связи в NFC, но насколько я понимаю, магнитное поле от антенны, скажем, телефона на расстоянии более 20 см будет слабее шумов, что и не позволяет сделать считыватель с больших расстояний.
Ну это скорее всего не так уж и сложно. Например, может быть конденсатор, которого гарантированно хватит на обработку одного блока. При потере питания последний блок обрабатывается и обработка останавливается.
Представьте: «берем универсальный магнитный считыватель и контролируемый двигатель для перемотки, запускаем прогу считывания разнообразных данных с автоматическим преобразованием в нужные форматы и через часик кассета считана».
Вот например, раньше для сканирования листа А4 нужно было покупать сканер, а сейчас фотку с телефона сделал в специальной проге и готово.
А задроты-физики? А биологи?
А что есть задрот вообще? почему это плохо или хорошо?
Я конечно понимаю, что связь теоретически может быть, но также прекрасно вижу людей, не обремененных большим количеством контекста в голове, отвлекающихся на мелочи и пишущих $ax4 = $bc3 + 13.
Я и сам когда-то так писал, пока не осознал суть проблемы и прочитав разные советы/книги/рекомендации начал писать нормальный код, ответственно подходя к понятности кода для других разработчиков в командах.
Вот пример: обматывал больше года назад, немного уже потерлось, но можно легко перемотать.
Всегда стараюсь заниматься самоанализом и, я так понимаю, работает это следующим образом. Если я не отвлекаюсь, то количество логики, которое я держу в уме, увеличивается гораздо и позволяет избежать ошибок в самой логике. В то же время IDE позволяет не ошибаться в типизации.
В противоположном случае, при паузах на сборку, мозг переключается на другие вещи/задачи/уведомления и теряется концентрация на логике. В результате у меня получается и больше времени на сборки/проверки и ближе к концу может обнаружиться какая-то необдуманная ситуация.
Для меня это работало и в 2000-ых на большом проекте на Delphi и работает сейчас на большом проекте на PHP. Хотя очень часто так и хочется проверить/отдебажить какой-то маленький кусочек кода (думаю приносит немного эндорфина).
Было бы интересно, если бы кто-то еще свои наблюдения рассказал по этому поводу, а не голые непроверенные утверждения.
@IBDesignable — это другой уровень, тут вопросов нет.
Самая ГЛАВНАЯ проблема с ними в том, что без использования этих правил/принципов они писали код, который попросту нормально не работал — куча ошибок и непродуманных ситуаций. Причем в этой компании бизнесу без разницы какие они клевые, а главное, чтобы задача была выполнена и работала. Но частые ошибки приводили к возврату задач, а далее топы увольняли их, и потом мы переписывали все сами.
Брали человека, который ответил на все мои вопросы. Он мог исправить любую проблему и написать готовый код, который в будущем легко масштабируется и не содержит ошибок. Правда ушел позже на более интересный проект.
Все эти теоретические знания, шаблоны, принципы не просто так придумываются, а для решения многих проблем разработки. И если человек этого не знает, он будет вновь и вновь сам для себя их открывать по мере развития.
2 строки кода, сборка, 2 строки, сборка — это так некоторые программисты генерируют видимость деятельности.
На самом деле себя тоже ловил на мысли, что я только и делаю, что тестирую (собираю) после каждого кусочка. Стал писать сразу много кода за раз — производительность работы возросла.
Спасибо — стрелка вверх. Не интересно — иди дальше. Бесполезный/вводящий в заблуждение материал/совсем велосипед — стрелка вниз.
В комментарии технические вопросы-ответы по делу без перехода на личности вообще.
Думаю если бы так было всегда — было бы идеально…
В итоге вместо
$ rm -rf app/cache
написал
$ rm -rf app /cache
То есть добавил всего один пробел случайно перед слэшем. В итоге удаленная директория app целиком. Пришлось повозиться немного с восстановлением файлов в IDE, хорошо, что все в истории есть.
python3: 38.629s
php7: 11.693s
node5: 1.893s
java8: 0.546s
неприятно удивил питон, думал он будет наравне с php по математике или даже быстрее