SHAMELESSLY, ну то что ты приводил в картинке - это логгирование. По крайней мере я это так всегда называл. Ты теггировал топик С++ - значит используй и делай отступ как я говорил.
WbICHA, у нас на проектах было такое правило что текст коммита удовлетворяет шаблону. Например если проект имеет код PROJ то комментарий тикета выглядит как RROJ-001 : Fixed performance bug
Это удобно для среды разработки. Можно в панели git набрать PROJ-001 и сразу увидишь все свои коммиты.
Контролировать такое правило тоже можно там либо хуки были либо какие-то CI/CD скрипты неважно. Главное что если команда договорилась то так и дальше все пойдут строем.
Не совсем понимаю вас почему номер тикета может потеряться. Эта документация живет вечно пока жив проект и я не знаю случаев когда бизнес решал бы удалять сведенья из JIRA/Confluence. Я практически всегда находил самые старые исторические тикеты за 5 и за более число лет.
Попробуй оставшиеся выражение разложить по этому шаблону и все получится.
Ситуацию запутывает этот странный :else который как-бы выпадает из общего ситаксиса.
Также непонятна типизация. Почему сначала сравниают с атомом 0. А после cond идет
попытка сравнить со списком (13 42 100500) ?
Вобщем это крайне неудачный софистический пример цель которого запутать.
Владимир Коротенко, да. Зависит от проекта. Никто не вытесняет С++ из того сегмента который он щас занимает. Но возможно откроются какие-то новые направления где другие требования будут важны. Это как банковский ентерпрайз. Java образца 1996 года была гадким утёнком. Она медленно работала и практически не поддерживала нормально мультипоточность. Но прошло 10 лет и открывается целое направление. Я думаю такой-же путь нащупывает для себя Rust. И стартовые условия у него - гораздо лучше чем у Java. По крайней мере по производительности его отставание от С++ близко к стат-погрешности. Там где торг идет за 5% я-бы как бизнес например вообще не брал это в расчет. Для меня было-бы важнее видеть другие качества. Безопасность. Кросс-платформенность. И способность быстро найти бригаду разработчиков.
Хм... тут скорее всего go непричем. А причем Windows и ее семантика блокирующего удаления.
Если ты пишешь на сях то попробуй этот же метод реализовать вот с этой функцией https://learn.microsoft.com/en-us/windows/win32/ap...
и если эффект повторяется - то ничего поделать тут нельзя.
Если удаляешь по списку то попробуй для каждого удаления запускать поток (горутин в твоем языке)
чтоб ждать асинхронно до тех пор пока удаление не сработает за какое-то разумное время.
Владимир. Давайте поговорим о самом важном и самом ценном для вас. А именно о ваших деньгах. Я привлекаю этот аргумент обычно в тех случаях когда хочу показать эволюционный путь современных языков. Безусловно С++ обладает массой полезных свойств. На нем пишут игры и общесистемный софт и это хорошо. Но С++ также обладает самой большой историей уязвимостей. Фактически 70% мировых дыр в софте имеют прямое отношение с C/C++. И когда мы переносим разговор в плоскость инфо-безопасности например браузера, то здесь компромиссов быть не может. Когда я или вы заходите в личный кабинет вашего банка для управления вашим личным счетом - мы хотим быть уверены ... нет не на 100. Даже на 200 процентов что наши операции будут тайны и безопасны. Тоесть мы здесь хотим быть безкомпромиссны. Браузеры дырявы. И не только по причине криворуких кодеров. Я думаю что тесты проникновения и линтеры по ним гоняют ойойой... Полный фарш. Но видимо и в этой доменной отрасли мы достигли некой точки где дальнейшая разработка будет просто параллизована без привлечения нового языка. Тоесть гиганты браузерной индустрии больше просто не могли справляться с потоком угроз и при этом продолжать разработку. И они решили что нужен язык не потому что он быстрее там или красивее. А просто потому что ДЕНЬГИ. Наши деньги в опасности. В конечном счете смысл большинства атак - это кража ключей или паролей или подсаживание wanna-cry где опять-же все идет на тему ваших денег.
При этом я здесь никакой не амбассадор. Я даже не програмист на Rust. Я просто пользователь браузера.
У Pandas есть недостатки. Наши аналитики пытаются запускать pandas-скрипты в databricks кластере но использование кластера идет неэффективно. Pandas не умеет себя распараллеливать на вычислительных нодах. Фактически Пандас видит только driver-node (хост где изначально запускаются процессы биг-даты). Worker nodes - не видит. Да и не втом дело видит или не видит. Технологически не умеет делать партишенинг длинных операций. Поэтому где как только performance issue - мы панду выкидывает за ухо на улицу и затаскиваем Dataframes из технологии Spark .
JhaoDa, я могу еще раз медленно написать что ORM нельзя использовать в задачах массовой загрузки.
Трансформация здесь определенно есть. Автор об этом пишет. Но нужно поробовать сначала ее реализовать
в БД уже после загрузки. Или можно сделать enrichment csv файла. Но это все тоже не имеет прямого
отношения к ORM.