Их (массивы) точно лучше передавать по ссылке, как PHP передаёт объекты
Точно лучше? Вообще, явно передавать что-то по ссылке надо, только если вам это действительно нужно. Например, если вам надо изменять в вызываемом методе/функции содержимое огромного массива, так чтобы это изменение сохранилось в вызывающем контексте. Но это весьма частный кейс, и возможно вы что-то делаете не так.
Используйте for
Вот так, без каких либо условий, всегда? Так себе совет. Используйте for в тех случаях, когда вы знаете для какой конкретно цели он вам нужен. Например, если вам надо итерируясь по огромному массиву менять его содержимое, так чтобы они сохранилось по завершению цикла... Что также достаточно редкий кейс.
Это кто-то читал? Тем кто еще не читал, советую и не читать.
То ли кривой перевод, то ли сразу ChatGpt. Если все-таки перевод, то поделитесь ссылкой на оригинал, может там будет понятнее.
Мы поможем вам определить, как мы разделяем и распределяем нагрузку между различными типами работников в центре обработки данных
Каких работниках? зачем нам определять как вы разделяете?
Каждый раз, когда мы разрабатываем новое ИТ-решение, нам необходимо учитывать и учитывать определенные архитектурные аспекты, которые являются неотъемлемой частью любого чертежа систем
Учитывать и учитывать и учитывать? А что за чертежи?
архитектура доступна для наблюдения, если она предоставляет подсказки и подсказки о своих внутренних условиях
Нужно больше подсказок. Особенно об условиях.
Код базируется на контролируемых версиях системы контроля версий
we need to go deeper...
Состояние должно быть бесхранилищным
Бесхранилищный... это шедевр
Сервисы должны быть легковесными и обработчиками.
На улице шли двое - дождь и я.
Приложение должно быть развернуто на нескольких экземплярах.
На нескольких экземплярах чего?
Административные задачи должны выполняться через один-time-процессы
один-time-процессы - интересный термин. В копилку к "бесхранилищный".
Как SRE, наша первая задача дня — обеспечить разделение и балансировку рабочей нагрузки между общими ресурсами и вспомогательными службами.
Первая задача дня - это вместо дейлика, каждое утро?
Germany's Blue Card Долгосрочная виза для высококвалифицированных работников, право на получение определяется по системе баллов. Получатель: работник Диплом: да Семья: да Продолжительность: 4 года Возобновляемый: да Стоимость: не указана Требования: высокий уровень владения немецким языком и ваша работа должна позволять вам зарабатывать не менее 50 800 € в год Время рассмотрения: не указано
Вы многое путаете. Бальной системы для BlueCard нет. Это для нового третьего способа "Chancenkarte" который только обсуждают и еще не приняли.
Диплом был обязателен не на 100%, раньше можно было показать опыт работы около 3х лет на должности, которая требует сопоставимого уровня знаний. Но сейчас это не работает для граждан РФ.
Продолжительность 4 года - это максимум на который дают блюкард, но бывает и меньше. Потом можно продлевать. Некоторые после 4-5 лет так и остаются на блюкард, и не получают ПМЖ по собственному желанию. Первые 2 года вид на жительство (по блюкард, не ПМЖ) привязан к работодателю, и поменять работу можно только согласовав новый контракт в администрации по делам иностранцев.
Высокий уровень владения немецким языком - нет такого требования на получения визы и временного вида на жительство по блю кард. Показать знание языка потребуется потом, когда будете подаваться на ПМЖ и гражданство. От уровня зависит то, как рано сможете подать документы. Сейчас в процессе рассмотрения закон о новых сроках, типа паспорт за три года, если сдадите немецкий на C2. Закон пока не принят.
сколько времени надо провести в стране до получения ПМЖ (если это в принципе возможно) + условия сохранения ПМЖ (в некоторых странах достаточно выехать на полгода, чтобы потерять постоянный вид на жительство)
сколько времени до паспорта (если это в принципе возможно, некоторые страны не дают паспорт, кроме как по браку с гражданином(гражданкой))
есть ли разрешение на работу у супругов приехавших по воссоединению семьи
требования по знанию языков (далеко не в каждой стране будет комфортно только с английским, не все готовы учить язык на котором говорит меньше 1 млн человек в мире)
Про совместимость API: > Из возможностей, доступных в первом выпуске DragonFly отмечается поддержка протокола RESP2 и 130 команд Redis, что примерно соответствует функциональности выпуска Redis 2.8 Это было полгода назад. Разработчики постепенно добавляют поддержку команд из более новых версий Redis, но о полной совместимости говорить рано.
Про быстродействие: По бенчмаркам команды Redis (ниже приводил ссылку на офсайт), они быстрее чем DragonFly. При этом они конечно запускали не один инстанс Redis на многопоточном процессоре, а несколько.
можно, более того, именно это и советуют на официальном сайте Redis, в ответ на критику со стороны разработчиков многопоточных форков. И в ответ приводят бенчмарки, в которых видно что правильно приготовленный Redis даже быстрее конкурентов См. тут https://redis.com/blog/redis-architecture-13-years-later/
Это не мой пример, это ваш (и не только) пример. Он хорошо показывает "как работают генераторы" и плохо показывает "как получить пользу от применения генераторов". Я всего лишь спросил, надеясь на ваш богатый опыт, нет ли другого примера, где использование генератора приводит к реальной экономии ресурсов, которой не достичь без оного. Ну нет, так нет.
Попробую ответить самому себе, какое у меня к данному моменту сложилось впечатление (но может, у кого-то еще найдется пример): - Чтобы реализовать аналогичный функционал без генератора, вам придется или использовать свой объект с состоянием, или вынести весь код в тело цикла, где и будет состояние выполнения тех или иных операций. В первом случае все довольно просто, но дополнительная писанина и размножение сущностей. Во втором случае - может получиться сложночитаемая каша. Таким образом главная выгода от генераторов - сокращение и упрощение кода, но вовсе не экономия ресурсов. И выгода тем больше, чем больше этаких "задач с состоянием" мы пытаемся выполнить за такт цикла, и чем больше кода в каждой "задаче".
но зачем загружать файл в память целиком? Если вы его можете обрабатывать построчно с генератором, читайте так же построчно без генератора. обработали строку, выдали результат - взяли следующую.
И если вам для работы с файлом, по условию задачи, необходимо считать его весь в память (ну мало ли, что там за формат внутри) , то генератор вам уже не поможет, все равно придется считать.
Спасибо за статью, интересно. Но всё же, как надоел это пример про генераторы и корутины с чтением файла по строкам! "Конечно, нужно отметить, что мы получаем возможность работы с потенциально бесконечными задачами, что без генераторов невозможно."
Но почему-то всегда приводится этот пример, который элементарно переписывается без всяких генераторов. При этом, также останется чтение по строкам, без считывания всего файла в память. И в обычной работе, в коде вроде порой хочется ввернуть генератор. Даже напишешь, а потом понимаешь что можно проще и понятнее без него.
Может есть какой-то пример, где действительно без них никак, и есть настоящая польза?
В данном случае это вовсе не попытка придумать новый подход к разработке сайтов. Технически, подходы те же что и раньше, может чуть в другой обертке для отвода глаз. Так что же это за волна статей про всякий «no code»?
Я думаю это банальная попытка заработать. Кому-то будет очень выгодно, если все избавятся от своих программистов и начнут пользоваться для любых целей API, которые поставляются сначала условно бесплатно, а при каких-то объемах — за вполне серьезные деньги.
Сначала — откажитесь от своих почтовых серверов, пользуйтесь Гугл, майлру и т.д. и т.п.
потом — откажитесь от своих веб серверов, пользуйтесь хостингом, потом пользуйтесь облаками. Откажитесь от своих файловых хранилищ и БД — пользуйтесь облаками. Теперь — откажитесь от своего кода.
Итог — вырастили монстров вроде гугла, амазона и т.д., которые полностью контролируют всех вокруг. Они могут «забанить» пользователя за не соответствующее текущему хайпу мнение — и разорять целые компании без тени сожаления. Гигантские бездушные бюрократические машины.
Всё это распрекрасно API и сторонние сервисы — без них уже никуда.
Сторонний сервис может:
— не отвечать
— потерять (удалить) ваши данные
— поменять API сломав обратную совместимость
— внезапно прекратить существование. Не дав выкачать «все что нажито»
— допустить утечку данных ваших клиентов
— сбоить так что ваши клиенты потеряют деньги — не те покупки, не туда доставки и т.д.
Но вот у них происходит сбой — и ваш бизнес встал. И от вас ничего не зависит. И убытки вам никто не компенсирует, разве что часть месячной подписки. А еще за утечку «у них» государство (ну или ваши клиенты через суд) может наказать вас.
А мне наоборот, бегать — скучно. Все эти школьно-институтские кроссы, и километры на время. Вот если бегать со смыслом, например играя в футбол — вот это удовольсте от физкультуры.
А вот фехтованием (шпага) занимался с удовольствием. Тут тебе и азарт и игра к «кошки-мышки» с соперником и физ-нагрузки в одном флаконе. Жаль секцию прикрыли. До сих пор дома лежат запчасти для сборки нового клинка.
Примерно на том же уровне что и фехтование, мне нравится настольный теннис — там тоже надо быть быстрым, ловким и хитрым.
От таких физических нагрузок и получаешь удовольствие, а не от бесконечных монотонных повторений упражнений.
Положительная оценка не означает что было выдано предложение о трудоустройстве
Именно это тезис я и комментировал.
расстройство будет только следствием его домысливания (или фантазии)
Когда речь идет о будущих событиях, человеку всегда приходится домысливать и фантазировать, на основе оценок вероятности наступления того или иного события (нет, 100% гарантий не бывает). И положительная оценка выданная до принятия решения о приеме можетпривести кандидата к невыгодным для него решениям.
Представьте себе немного другой вариант — ищете вы работу, допустим месяц уже, и ипотека не дает расслабится. На руках уже две недели как есть оффер от одной компании — там вроде норм, но не супер (мелкие недостатки, но несколько сразу). Еще одно собеседование — вам все понравилось, проект, команда, плюшки. Интервьюеру все понравилось — сразу дал вам положительный фидбек. Теперь у вас дилемма: принимать ли тот оффер что уже есть (две недели как висит, звонят через день, спрашивают «Когда примите решение? Или нам другого кандидата уже позвать?») или ждать ответа? Тут без додумывания и фантазии не обойтись.
Читал статью про то что большинству людей свойственно верить в хорошее развитие событий, планировать свои успехи и более тщательно рассматривать именно «удачные кейсы». С такими вводными положительный фидбек выданный заранее — повышает в глазах кандидата вероятность наступления «положительного события», приема на работу.
А может и другая ситуация получится — вы дали человеку положительный фидбек, что вам все понравилось. И человек ушел довольный, думая что у него наверняка место в кармане.
После этого он отсобеседовался еще в пару мест, и его в принципе берут, но у вас ему понравилось что-то чуть больше. И он отказывается от офферов/собеседований в другие компании.
За это время вы пособеседовали еще других кандидатов, и кто-то оказался сильнее и взяли его. Далее вы сообщаете первому кандидату отказ.
Он в шоке — как так? все же прошло хорошо, он же получил положительный фидбек, да еще и сразу же?? Он отказался от других предложений и рассчитывал на это место, и теперь чувствует себя обманутым. Хотя бы в том что фидбэк был положительным, а решение — отрицательным.
К сожалению уровень многих HR не сильно отличается от этих вчерашних грузчиков. Все кто не могут в «QA» толпами ломятся в «IT-рекрутер». И начинают пытаться всех подходящих и неподходящих пытаться устроить хоть куда-то, лишь бы получить «процент за сделку».
Точно лучше? Вообще, явно передавать что-то по ссылке надо, только если вам это действительно нужно. Например, если вам надо изменять в вызываемом методе/функции содержимое огромного массива, так чтобы это изменение сохранилось в вызывающем контексте. Но это весьма частный кейс, и возможно вы что-то делаете не так.
Вот так, без каких либо условий, всегда? Так себе совет. Используйте for в тех случаях, когда вы знаете для какой конкретно цели он вам нужен. Например, если вам надо итерируясь по огромному массиву менять его содержимое, так чтобы они сохранилось по завершению цикла... Что также достаточно редкий кейс.
Я то думал, что основной минус Тайваня - возможность военного конфликта с Китаем и вмешательством третьих сил.
А оказывается - существование налогов и омс... не уверен что многие захотят жить в тех странах, где сейчас нет таких "основных недостатков".
Это кто-то читал? Тем кто еще не читал, советую и не читать.
То ли кривой перевод, то ли сразу ChatGpt.
Если все-таки перевод, то поделитесь ссылкой на оригинал, может там будет понятнее.
Каких работниках? зачем нам определять как вы разделяете?
Учитывать и учитывать и учитывать? А что за чертежи?
Нужно больше подсказок. Особенно об условиях.
we need to go deeper...
Бесхранилищный... это шедевр
На улице шли двое - дождь и я.
На нескольких экземплярах чего?
один-time-процессы - интересный термин. В копилку к "бесхранилищный".
Первая задача дня - это вместо дейлика, каждое утро?
даже боюсь читать дальше...
Вы многое путаете. Бальной системы для BlueCard нет. Это для нового третьего способа "Chancenkarte" который только обсуждают и еще не приняли.
Диплом был обязателен не на 100%, раньше можно было показать опыт работы около 3х лет на должности, которая требует сопоставимого уровня знаний. Но сейчас это не работает для граждан РФ.
Продолжительность 4 года - это максимум на который дают блюкард, но бывает и меньше. Потом можно продлевать. Некоторые после 4-5 лет так и остаются на блюкард, и не получают ПМЖ по собственному желанию. Первые 2 года вид на жительство (по блюкард, не ПМЖ) привязан к работодателю, и поменять работу можно только согласовав новый контракт в администрации по делам иностранцев.
Высокий уровень владения немецким языком - нет такого требования на получения визы и временного вида на жительство по блю кард. Показать знание языка потребуется потом, когда будете подаваться на ПМЖ и гражданство. От уровня зависит то, как рано сможете подать документы. Сейчас в процессе рассмотрения закон о новых сроках, типа паспорт за три года, если сдадите немецкий на C2. Закон пока не принят.
Виза это хорошо, но нужна еще информация:
сколько времени надо провести в стране до получения ПМЖ (если это в принципе возможно) + условия сохранения ПМЖ (в некоторых странах достаточно выехать на полгода, чтобы потерять постоянный вид на жительство)
сколько времени до паспорта (если это в принципе возможно, некоторые страны не дают паспорт, кроме как по браку с гражданином(гражданкой))
есть ли разрешение на работу у супругов приехавших по воссоединению семьи
требования по знанию языков (далеко не в каждой стране будет комфортно только с английским, не все готовы учить язык на котором говорит меньше 1 млн человек в мире)
в тексте договора медицинского страхования.
Про совместимость API:
> Из возможностей, доступных в первом выпуске DragonFly отмечается поддержка протокола RESP2 и 130 команд Redis, что примерно соответствует функциональности выпуска Redis 2.8
Это было полгода назад. Разработчики постепенно добавляют поддержку команд из более новых версий Redis, но о полной совместимости говорить рано.
Про быстродействие:
По бенчмаркам команды Redis (ниже приводил ссылку на офсайт), они быстрее чем DragonFly. При этом они конечно запускали не один инстанс Redis на многопоточном процессоре, а несколько.
А вот еще одно небольшое сравнение redis vs keyDB, и тут тоже не вышло превосходства keyDB в 5-25х маркетинговых раз.
можно, более того, именно это и советуют на официальном сайте Redis, в ответ на критику со стороны разработчиков многопоточных форков. И в ответ приводят бенчмарки, в которых видно что правильно приготовленный Redis даже быстрее конкурентов
См. тут https://redis.com/blog/redis-architecture-13-years-later/
Вроде уже было, комиксы про кубер:
https://www.cncf.io/phippy/phippy-goes-to-the-zoo-book/
Это не мой пример, это ваш (и не только) пример. Он хорошо показывает "как работают генераторы" и плохо показывает "как получить пользу от применения генераторов".
Я всего лишь спросил, надеясь на ваш богатый опыт, нет ли другого примера, где использование генератора приводит к реальной экономии ресурсов, которой не достичь без оного. Ну нет, так нет.
Попробую ответить самому себе, какое у меня к данному моменту сложилось впечатление (но может, у кого-то еще найдется пример):
- Чтобы реализовать аналогичный функционал без генератора, вам придется или использовать свой объект с состоянием, или вынести весь код в тело цикла, где и будет состояние выполнения тех или иных операций. В первом случае все довольно просто, но дополнительная писанина и размножение сущностей. Во втором случае - может получиться сложночитаемая каша. Таким образом главная выгода от генераторов - сокращение и упрощение кода, но вовсе не экономия ресурсов. И выгода тем больше, чем больше этаких "задач с состоянием" мы пытаемся выполнить за такт цикла, и чем больше кода в каждой "задаче".
но зачем загружать файл в память целиком? Если вы его можете обрабатывать построчно с генератором, читайте так же построчно без генератора. обработали строку, выдали результат - взяли следующую.
И если вам для работы с файлом, по условию задачи, необходимо считать его весь в память (ну мало ли, что там за формат внутри) , то генератор вам уже не поможет, все равно придется считать.
Спасибо за статью, интересно. Но всё же, как надоел это пример про генераторы и корутины с чтением файла по строкам!
"Конечно, нужно отметить, что мы получаем возможность работы с
потенциально бесконечными задачами, что без генераторов невозможно."
Но почему-то всегда приводится этот пример, который элементарно переписывается без всяких генераторов. При этом, также останется чтение по строкам, без считывания всего файла в память. И в обычной работе, в коде вроде порой хочется ввернуть генератор. Даже напишешь, а потом понимаешь что можно проще и понятнее без него.
Может есть какой-то пример, где действительно без них никак, и есть настоящая польза?
В IDE от JetBrains — например, PHPStorm
Я думаю это банальная попытка заработать. Кому-то будет очень выгодно, если все избавятся от своих программистов и начнут пользоваться для любых целей API, которые поставляются сначала условно бесплатно, а при каких-то объемах — за вполне серьезные деньги.
Сначала — откажитесь от своих почтовых серверов, пользуйтесь Гугл, майлру и т.д. и т.п.
потом — откажитесь от своих веб серверов, пользуйтесь хостингом, потом пользуйтесь облаками. Откажитесь от своих файловых хранилищ и БД — пользуйтесь облаками. Теперь — откажитесь от своего кода.
Итог — вырастили монстров вроде гугла, амазона и т.д., которые полностью контролируют всех вокруг. Они могут «забанить» пользователя за не соответствующее текущему хайпу мнение — и разорять целые компании без тени сожаления. Гигантские бездушные бюрократические машины.
Всё это распрекрасно API и сторонние сервисы — без них уже никуда.
Сторонний сервис может:
— не отвечать
— потерять (удалить) ваши данные
— поменять API сломав обратную совместимость
— внезапно прекратить существование. Не дав выкачать «все что нажито»
— допустить утечку данных ваших клиентов
— сбоить так что ваши клиенты потеряют деньги — не те покупки, не туда доставки и т.д.
Но вот у них происходит сбой — и ваш бизнес встал. И от вас ничего не зависит. И убытки вам никто не компенсирует, разве что часть месячной подписки. А еще за утечку «у них» государство (ну или ваши клиенты через суд) может наказать вас.
А вот фехтованием (шпага) занимался с удовольствием. Тут тебе и азарт и игра к «кошки-мышки» с соперником и физ-нагрузки в одном флаконе. Жаль секцию прикрыли. До сих пор дома лежат запчасти для сборки нового клинка.
Примерно на том же уровне что и фехтование, мне нравится настольный теннис — там тоже надо быть быстрым, ловким и хитрым.
От таких физических нагрузок и получаешь удовольствие, а не от бесконечных монотонных повторений упражнений.
Именно это тезис я и комментировал.
Когда речь идет о будущих событиях, человеку всегда приходится домысливать и фантазировать, на основе оценок вероятности наступления того или иного события (нет, 100% гарантий не бывает). И положительная оценка выданная до принятия решения о приеме можетпривести кандидата к невыгодным для него решениям.
Представьте себе немного другой вариант — ищете вы работу, допустим месяц уже, и ипотека не дает расслабится. На руках уже две недели как есть оффер от одной компании — там вроде норм, но не супер (мелкие недостатки, но несколько сразу). Еще одно собеседование — вам все понравилось, проект, команда, плюшки. Интервьюеру все понравилось — сразу дал вам положительный фидбек. Теперь у вас дилемма: принимать ли тот оффер что уже есть (две недели как висит, звонят через день, спрашивают «Когда примите решение? Или нам другого кандидата уже позвать?») или ждать ответа? Тут без додумывания и фантазии не обойтись.
Читал статью про то что большинству людей свойственно верить в хорошее развитие событий, планировать свои успехи и более тщательно рассматривать именно «удачные кейсы». С такими вводными положительный фидбек выданный заранее — повышает в глазах кандидата вероятность наступления «положительного события», приема на работу.
После этого он отсобеседовался еще в пару мест, и его в принципе берут, но у вас ему понравилось что-то чуть больше. И он отказывается от офферов/собеседований в другие компании.
За это время вы пособеседовали еще других кандидатов, и кто-то оказался сильнее и взяли его. Далее вы сообщаете первому кандидату отказ.
Он в шоке — как так? все же прошло хорошо, он же получил положительный фидбек, да еще и сразу же?? Он отказался от других предложений и рассчитывал на это место, и теперь чувствует себя обманутым. Хотя бы в том что фидбэк был положительным, а решение — отрицательным.