Ну как это ничто не мешает? При вроде из Российского аккаунта насильно переводят на .ru сайт (раньше можно было как-то зафорсить, а вот после редезайна - уже никак), и приложение тоже, при попытке войти с Российским аккаунтом говорит использовать Российское приложение и закрывается.
Так expect-то он тоже не для повседневного использования. По-хорошему, expect тоже нельзя использовать если есть альтернативы, а только там где он никогда не должен вызваться в рантайме, т.к. в большинстве случаев программа не должна паниковать, а должна пузырьковать ошибку обратно в main() и там грациозно завершаться с ошибочным exit code.
А эта подписка хоть месяц проработала? Интересно, много найдется желающих купить Twitter Gold, если не известно не появится ли новая подписка ей на смену через 1-2 месяца..
Еще как смотрят. Когда 3.5 года назад менял работу, несмотря на 7 лет опыта программистом - 2/3 компаний либо отклоняли сразу, либо уже во время интервью, когда замечали что высшего образования нет.
В одной из контор, кажется в СберТехе, после интервью их IT специалист прямым текстом сказал что даже с половиной моего опыта и навыков они бы готовы были меня нанять на месте, если бы у меня был бы хоть бакалавр даже не по специальности, а вот без ВО совсем - физически не могут взять. Даже посоветовал поступить в любой "левый" колледж на заочку и проплатить все, лишь бы дали корочку, и с ней подать резюме еще раз..
привлекать в IT-сферу работников со средним профессиональным образованием.
Сначала сами себе создали проблемы сделав так что высшее образование (даже непрофильное) имеет приоритет на голову выше опыта и навыков при приеме на работу IT специалистов, и требуя его обязательного наличия, а теперь "решают" эту проблему отменяя это требование... Браво, можно похлопать себя по спине за успешную работу
"Well... Duh". Если посты не криптографически подписаны то кто-угодно может их публиковать от чьего-угодно имени, если у них есть доступ к базе, даже не нужно никакого специального GodMode интерфейса для этого
Стоит добавить что для Rust "?" работает не только для `Result<T, Error>` но и для `Option<T>`. И, если задействовать https://crates.io/crates/try-block, то им можно пользоваться "локально" а не выходя из всей функции (т.е. аналог for в Scala). Так же для Result, ? не требует чтобы ошибки были одного типа если существует From имплементация из этой ошибки в ту которая ожидается на выходе функцией (что есть очень болезненный момент в Scala где даже если ошибки наследуются от общего предка - компилятор не может само это сообразить и приходится прописывать все тайп-параметры руками при вызове таких функций в for).
А на nightly, в процессе стабилизации, существует трейт который позволит использовать ? для произвольных типов для которых этот трейт выполнен.
голову ломают как бы втиснуть компоненты в заданные габариты изделия
Так а кто эти габариты задавал такие, что втиснуться в них можно только "изобретая велосипед" для каждой детали? Никто ж не говорит что это инженерам так хочется самовыразиться что они делают каждую модель каждого устройства "единственной и неповторимой".
Что такое "анализ лучших решени" и кто его будет проводить?
Скорее всего что-то вроде: иметь ход одного devops который прошел официально одобренный курс "Цифровой безопасности ЭВМ" 2000-мохнатого года, который будет обновляться раз в пятилетку, иметь установленным официально одобренный "народный" антивирус созданный по госзаказу компанией которая предложила выполнить за наименьшую цену... Ну и т.д., как везде
Под "последним" я подразумевал "последний оставшийся. Т.е.
"array": [
{"foo": 1}
]
"array": [
]
А вот в YAML удалив последний элемент из
array:
-foo: 1
мы получим
array:
что есть null а не пустой массив. И вместо этого нужно переключится на другой синтаксис массива
array: []
И когда после этого требуется добавить значение обратно - в JSON все так же логично и consistent, в вот в YAML мы не можем в этот пустой массив добавить новый `foo: 2` - для этого нужно переключаться обратно на многострочный синтаксис массива.
В комментарии DirectoriX не было примера такого массив в pretty-printed JSON. И, если я правильно понял что "непустое объявление пустого массива" означает необходимость писать "[]"... То что именно должно в этом смущать?
В JSON как и во всех нормальных форматах, есть синтаксис, которому нужно следовать независимо от того пустой массив или нет.
В YAML же, синтаксиса для массивов 2 (как минимум). при этом один синтаксис используется для массивов простых объектов И позволяет объявлять пустой массив, а второй синтаксис позволяет делать массивы сложных обхектов, НО не позволяет объявлять пустой массив. Что приводит к интересным моментам как, например, невозможность просто удалить строку с последним элементом массива (т.к. это сделает этот ключ равным null, ан е пустому массиву) и вместо этого необходимость переписать этот массив на однострочный синтаксис. А когда потом потребуется снова добавить значение - переписать обратно.
Такая несогласованность не может не "ломать" разработчика привыкшего к "форматам трезвого человека". А вот в JSON я что-то подобных проблем не припомню, отсюда и просьба привести пример.
В домашних проектах, где ты и вся команда разработки, и devops, и product owner, и менеджер, и CTO & CEO, и даже клиент, все в одном лице - конечно всегда. А вот в коммерческих проектах такой идеализм как правило выживает не больше пары недель со старта проекта...
"Заходи через не-Российский VPN" + "плати не-Российской картой" + "заказывай на не-Российский адрес" дает в сумме "не живи в России", как бы
А оплачивать/доставлять после этого не в Ирландию можно будет?
Ну как это ничто не мешает? При вроде из Российского аккаунта насильно переводят на .ru сайт (раньше можно было как-то зафорсить, а вот после редезайна - уже никак), и приложение тоже, при попытке войти с Российским аккаунтом говорит использовать Российское приложение и закрывается.
Так не Россия же решила отделиться от мировой банковской системы, следовательно виноватыми быть не могут в невозможности оплатить.
Так expect-то он тоже не для повседневного использования. По-хорошему, expect тоже нельзя использовать если есть альтернативы, а только там где он никогда не должен вызваться в рантайме, т.к. в большинстве случаев программа не должна паниковать, а должна пузырьковать ошибку обратно в main() и там грациозно завершаться с ошибочным exit code.
Так это середина 2000х, вы бы еще 90е вспомнили. А у Apple такая проблема все еще, в 2020х годах
А эта подписка хоть месяц проработала? Интересно, много найдется желающих купить Twitter Gold, если не известно не появится ли новая подписка ей на смену через 1-2 месяца..
А некоммерческого это как, OpenSource? Возможно разные условия в разных регионах - мой опыт из Ростова на Дону
Еще как смотрят. Когда 3.5 года назад менял работу, несмотря на 7 лет опыта программистом - 2/3 компаний либо отклоняли сразу, либо уже во время интервью, когда замечали что высшего образования нет.
В одной из контор, кажется в СберТехе, после интервью их IT специалист прямым текстом сказал что даже с половиной моего опыта и навыков они бы готовы были меня нанять на месте, если бы у меня был бы хоть бакалавр даже не по специальности, а вот без ВО совсем - физически не могут взять. Даже посоветовал поступить в любой "левый" колледж на заочку и проплатить все, лишь бы дали корочку, и с ней подать резюме еще раз..
Сначала сами себе создали проблемы сделав так что высшее образование (даже непрофильное) имеет приоритет на голову выше опыта и навыков при приеме на работу IT специалистов, и требуя его обязательного наличия, а теперь "решают" эту проблему отменяя это требование... Браво, можно похлопать себя по спине за успешную работу
"Well... Duh". Если посты не криптографически подписаны то кто-угодно может их публиковать от чьего-угодно имени, если у них есть доступ к базе, даже не нужно никакого специального GodMode интерфейса для этого
Кажись не тот крейт вставил. Тот который я хотел упомянуть это https://crates.io/crates/tryvial
Стоит добавить что для Rust "?" работает не только для `Result<T, Error>` но и для `Option<T>`. И, если задействовать https://crates.io/crates/try-block, то им можно пользоваться "локально" а не выходя из всей функции (т.е. аналог for в Scala). Так же для Result, ? не требует чтобы ошибки были одного типа если существует From имплементация из этой ошибки в ту которая ожидается на выходе функцией (что есть очень болезненный момент в Scala где даже если ошибки наследуются от общего предка - компилятор не может само это сообразить и приходится прописывать все тайп-параметры руками при вызове таких функций в for).
А на nightly, в процессе стабилизации, существует трейт который позволит использовать ? для произвольных типов для которых этот трейт выполнен.
Удалено т.к. отправил коммент не в ту ветку
Так а кто эти габариты задавал такие, что втиснуться в них можно только "изобретая велосипед" для каждой детали? Никто ж не говорит что это инженерам так хочется самовыразиться что они делают каждую модель каждого устройства "единственной и неповторимой".
Скорее всего что-то вроде: иметь ход одного devops который прошел официально одобренный курс "Цифровой безопасности ЭВМ" 2000-мохнатого года, который будет обновляться раз в пятилетку, иметь установленным официально одобренный "народный" антивирус созданный по госзаказу компанией которая предложила выполнить за наименьшую цену... Ну и т.д., как везде
Под "последним" я подразумевал "последний оставшийся. Т.е.
А вот в YAML удалив последний элемент из
мы получим
что есть null а не пустой массив. И вместо этого нужно переключится на другой синтаксис массива
И когда после этого требуется добавить значение обратно - в JSON все так же логично и consistent, в вот в YAML мы не можем в этот пустой массив добавить новый `foo: 2` - для этого нужно переключаться обратно на многострочный синтаксис массива.
Так понятнее?
В комментарии DirectoriX не было примера такого массив в pretty-printed JSON. И, если я правильно понял что "непустое объявление пустого массива" означает необходимость писать "[]"... То что именно должно в этом смущать?
В JSON как и во всех нормальных форматах, есть синтаксис, которому нужно следовать независимо от того пустой массив или нет.
В YAML же, синтаксиса для массивов 2 (как минимум). при этом один синтаксис используется для массивов простых объектов И позволяет объявлять пустой массив, а второй синтаксис позволяет делать массивы сложных обхектов, НО не позволяет объявлять пустой массив. Что приводит к интересным моментам как, например, невозможность просто удалить строку с последним элементом массива (т.к. это сделает этот ключ равным null, ан е пустому массиву) и вместо этого необходимость переписать этот массив на однострочный синтаксис. А когда потом потребуется снова добавить значение - переписать обратно.
Такая несогласованность не может не "ломать" разработчика привыкшего к "форматам трезвого человека". А вот в JSON я что-то подобных проблем не припомню, отсюда и просьба привести пример.
А можно с примером что именно должно в нем смущать?
В домашних проектах, где ты и вся команда разработки, и devops, и product owner, и менеджер, и CTO & CEO, и даже клиент, все в одном лице - конечно всегда. А вот в коммерческих проектах такой идеализм как правило выживает не больше пары недель со старта проекта...