Не в курсе механик движка Source, но если он реализован на «порталах» — можно заранее просчитать, из каких комнат какие видны. И отправлять клиенту данные только тех комнат, которые «видны» из его текущей. На некоторых демках можно видеть, что воллхак срабатывает немного случайно.
Тогда смысл "не-нуллабельности" вообще нулевой получается — с учётом что 95% нынешнего кода не на Kotlin. Я при работе с внешним кодом не получаю от компилятора абсолютно никакой помощи, и точно так же могу схлопотать NPE почти в любой момент. Смысл был бы как раз заставить проверять инварианты на внешнем коде или прогонять какой-то статический чекер. А так синтаксис покрасивше, не более.
ИМХО тут автор как раз прав — сакральный смысл таких "манипуляций" стремится к нулю. В тот же Spring таких аннотаций не понаставишь. Логичнее как раз считать всё "чужеродное" максимально "небезопасным", если не указано иное.
Вообще странно. Год или полтора назад я читал, что в Kotlin специально решили считать все ссылки родом из Java — Nullable по умолчанию. И даже гоняли над JRE специальный верификатор, который составлял "карту аннотаций". Решили не заморачиваться, что ли?
Для меня например использование настроек для нескольких способов питания в одном плане контр-интуитивно. Было бы логичней КМК сделать каждый "план" просто пачкой настроек. И набор переключателей о событиям — на подключение шнурка питания, на работу от батареи, на определённый уровень заряда. Понятно, что какая система есть — такая есть.
Кстати, некоторые вендоры ноутбуков примерно так и делают — из специальной утилитки переключают планы. И можно настроить, в каком режиме питания какой план использовать.
Skype for Business — нет, спасибо. Пользуюсь сейчас по необходимости — корп стандарт. Так вот — даже обычный скайп, с учётом как его испоганил МС, в разы лучше
Редкое тормозилово
Неотключаемые и непереназначаемые клавиши. Ctrl+Enter стартует звонок, и это не поменять — никак
Дикая котовасия при включении — отключении микрофона
При включении демонстрации экрана задержка до 10 секунд
Скорее всего побуду Кэпом. Это называется Dispatch Table и напрямую в Асм вроде как не выражается. А выражается в джамп с вычисляемым адресом, перед которым стоит проверка что джамп не улетит в космос.
Я конечно не спец, но разве для такого не существует специальных решений, которые позволяют вместо 50-100 шнуров тянуть 1-2 толстых шины? Та же оптика будет слишком дорогой? Есть ведь предел для плотности такой укладки — когда потолок ДЦ грохнется под тяжестью кабелей.
Не автор, но отвечу. Как правило — поддержка железа. Xiaomi Mi 3. На вендорской прошивке датчик "приближения к уху" работает нормально, на цианогене — глючит безбожно. Решения найти не смог.
Эх, 301 Pro до сих пор пользуюсь, хоть аккумулятор уже от старости выдохся, и корпус весь исцарапанный. А всё почему? А всё потому что поддержка кучи форматов, в т.ч. fb2. Не потеряйте это преимущество.
Когда я "искал себе жену" (примем такую формулировку), мне никто не пытался рекламировать невест на выданье. Впрочем, зная нынешних рекламщиков, мне бы скорее предлагали проституток по месту жительства.
Ваш пример с автомобилями неверен. Красивость тоже своего рода ТТХ — но я не буду покупать какую-нибудь Эдамскую косметичку" чтобы возить картошку с дачи — даже если она красивая.
По поводу нужности рекламы спорить не буду. Я даже наверное согласен что она нужна — в какой-то форме. Но блин не так что мне её, фигурально выражаясь, пытаются из катапульты в окно закидывать мешками по пол-центнера.
Тогда смысл "не-нуллабельности" вообще нулевой получается — с учётом что 95% нынешнего кода не на Kotlin. Я при работе с внешним кодом не получаю от компилятора абсолютно никакой помощи, и точно так же могу схлопотать NPE почти в любой момент. Смысл был бы как раз заставить проверять инварианты на внешнем коде или прогонять какой-то статический чекер. А так синтаксис покрасивше, не более.
ИМХО тут автор как раз прав — сакральный смысл таких "манипуляций" стремится к нулю. В тот же Spring таких аннотаций не понаставишь. Логичнее как раз считать всё "чужеродное" максимально "небезопасным", если не указано иное.
Вообще странно. Год или полтора назад я читал, что в Kotlin специально решили считать все ссылки родом из Java — Nullable по умолчанию. И даже гоняли над JRE специальный верификатор, который составлял "карту аннотаций". Решили не заморачиваться, что ли?
Ждём когда появится JEP на внедрение RAII, типов-смартпоинтеров и отделения ссылочности от типа :)
Это Вы С++ во всей его красе наверное не видели
Предложите что-нибудь на замену. К сожалению, 99% нынешних систем набиты костылями под завязку — даже перечислять не буду.
Для меня например использование настроек для нескольких способов питания в одном плане контр-интуитивно. Было бы логичней КМК сделать каждый "план" просто пачкой настроек. И набор переключателей о событиям — на подключение шнурка питания, на работу от батареи, на определённый уровень заряда. Понятно, что какая система есть — такая есть.
Кстати, некоторые вендоры ноутбуков примерно так и делают — из специальной утилитки переключают планы. И можно настроить, в каком режиме питания какой план использовать.
А подкиньте ссылочку пожалуйста
(del)
По поводу админов — у нас не собственный сервер, а облако МС.
Поделитесь косяками. Действительно интересно, без иронии.
Skype for Business — нет, спасибо. Пользуюсь сейчас по необходимости — корп стандарт. Так вот — даже обычный скайп, с учётом как его испоганил МС, в разы лучше
А Java умеет в метках диспатч-веток сложные неконстантные выражения?
А ещё гудбай статически просчитанный диспатч. Или надеяться на JIT.
Скорее всего побуду Кэпом. Это называется Dispatch Table и напрямую в Асм вроде как не выражается. А выражается в джамп с вычисляемым адресом, перед которым стоит проверка что джамп не улетит в космос.
Я конечно не спец, но разве для такого не существует специальных решений, которые позволяют вместо 50-100 шнуров тянуть 1-2 толстых шины? Та же оптика будет слишком дорогой? Есть ведь предел для плотности такой укладки — когда потолок ДЦ грохнется под тяжестью кабелей.
Не автор, но отвечу. Как правило — поддержка железа. Xiaomi Mi 3. На вендорской прошивке датчик "приближения к уху" работает нормально, на цианогене — глючит безбожно. Решения найти не смог.
То, что вы описали — JSDD == Job Safety Driven Development :)
Когда я "искал себе жену" (примем такую формулировку), мне никто не пытался рекламировать невест на выданье. Впрочем, зная нынешних рекламщиков, мне бы скорее предлагали проституток по месту жительства.
Ваш пример с автомобилями неверен. Красивость тоже своего рода ТТХ — но я не буду покупать какую-нибудь Эдамскую косметичку" чтобы возить картошку с дачи — даже если она красивая.
По поводу нужности рекламы спорить не буду. Я даже наверное согласен что она нужна — в какой-то форме. Но блин не так что мне её, фигурально выражаясь, пытаются из катапульты в окно закидывать мешками по пол-центнера.