Прозрачность анимируется на верхней картинке, от "полностью непрозрачна" до "невидимая". Таким образом получается плавный переход от верхней картинки к нижней.
Дополню ответ:
Умение гуглить не всегда спасет, особенно в случае решения нетривиальных задач. Документация тоже не всегда идеальна, может отставать от актуальных версий библиотек/фреймворков. Знание РНР нужно на хорошем уровне, чтобы человек понимал процессы, которые происходят под капотом фреймворка, мог посмотреть в его исходник и не упасть в обморок. И в конце концов - вам писать свой продукт на РНР придется, правильно используя как возможности фреймворка, так и возможности самого языка.
Можно реализовать подобное, используя хеш-навигацию и шифрование, но зачем?
Аналогичный эффект даст переменная, обьявленная в window, которую между между запросами можно сохранять куда-либо.
Честно говоря, без описания конкретной задачи, где это было бы нужно сложно что-то внятное сказать. Скорее всего вы используете куки не по назначению.
И ещё кстати: с буферизированого канала таки можно читать оставшиеся значения.
Когда значения заканчиваются, чтение с канала будет бесконечно возвращать нулевое значение для типа, с которым был создан chan.
Пример: play.golang.org/p/SJw9qw-OVS
Кстати, конструкция как в 2м варианте, с закрытием канала в ветке select'a и мютексами у меня также паникует. Не могу понять причину... Ведь до того как случится 2й send канал уже должен бы быть закрыт...
Или может я ошибаюсь в корне, и select не перенаправляет в default, если канал закрыт, а сразу паникует?
Спасибо за столь дельный ответ.
В связи с вышеизложенным последний вопрос:
Как всё же реализовать такую гонку красиво и правильно, чтобы:
а) получать из chan только первое значение
б) не блокировать на записи остальные рутины, которые будут пытаться писать в этот chan.
Вариант с множеством chan'ов (по одному на рутину) и select'ом по ним не подходит, т.к. количество соревнующихся рутин заранее неизвестно, может меняться в процессе работы программы.
Мне приходят в голову костыльные варианты вроде дополнительной рутины для считывания всего того мусора, что остался в chan'e, или мютекса поверх попытки записи в chan, как-то так:
m:=sync.Mutex{}
ch:=make(chan interface{})
//в соревнующихся рутинах в месте отправки:
m.lock()
select {
case ch <- data: ch.close()
default:
}
}
m.Unlock()
Идея в том, что выигравшей будет счтитаться первая рутина, захватившая мютекс.
На остальных выполнение должно уйти в default ветку.
Понятное дело, что такой аттракцион будет одноразовым, да и люди не стоят в очереди, а сразу полезают в телегу и сидят там, пока она не заполнится доверха.
Доводку до условия оставляю автору.
На самом деле, судя по доках можно оставить триггер выключеным и подписываться на события физического движка (docs.unity3d.com/Manual/CollidersOverview.html)
Вместо OnTriggerEnter будет OnCollisionEnter. Не знаю, правильно ли я вас понял.
Кабель воткнут то в один, то в другой. В сети один из ноутов, если нужен другой - кабель переключается в него, но для провайдера по идее они не отличаются =)
Тоже так думал. Однако. Раздал инет через вайфай, обновил систему, прописал вообще все значения что имелись в /etc/network/interfaces и отдельно в нетворк менеджере - и сеть появилась. Хз что оказалось решающим моментом, пишу уже с проблемного ноута.
На Win у меня IP приходит по DHCP. Это 2 ноутбука. Провайдер определяет клиента по мак-адресу, поэтому на ubuntu мак клонируется. Я пытаюсь настроить обычное проводное соеддинение (ethernet).