Пробовали пролистать до конца страницы? Там будет плашка «Предыдущие дни», при нажатии которой подгрузятся плейлисты прошлого дня, затем позапрошлого и т.д.
В приложении даже нажимать ничего не нужно, просто прокрутить до конца.
Если вы заметили, функционал приложения Яндекс.Музыки без подписки значительно более урезанный, чем у веб-версии. Так что логично, что веб-версия для мобильных устройств, в т.ч. планшетов, и не предназначалась.
Кстати, похожие проблемы могут появиться в Java — при работе с потоками в конструкторе.
А именно — если у объекта есть final поля, то гарантируется, что после вызова конструктора их значения будут правильными для всех потоков. Но это неверно, если ссылка на объект была куда-то (например в другой поток) передана внутри конструктора.
Если делать для России, получится ещё хуже для Google — подумают, что в руководство проникли русские шпионы, которые собираются влиять на выборы в Америке. Или сохранять Путина при власти.
С чего вы взяли? Наоборот, как правило хорошо параллелящиеся алгоритмы требуют больше (часто сильно больше) операций.
Тут извиняюсь, ошибся. Хотел написать «хуже».
Всё поведение основано на цепочках, которые гораздо короче, чем цепочка связанных объектов, отрабатывающих клики при наборе текста на вот этой вот страничке Хабра.
С другой стороны, у поведения имеется огромное количество когнитивных погрешностей, которые возникли именно из-за этой оптимизации. Представьте, что вы сотню лет пишете и переписываете код этой странички. Естественно, за это время вы успеете перепробовать тонну подходов, выучите или создадите ассемблер и напишете на нём. И это будет дико эффективно.
Где-то мы свернули «не туда» в дизайне компьютерных систем
Если у нас были кубики «О», «П», «А» и «Ж» — мы не могли сложить «Вечность». Всем требуется выпускать продукты «быстрее, ещё быстрее». А написать быстро, без ошибок и производительное — выберите два, как говорится.
Человек — это скорее FPGA. Мозг сильно заточен под распознавание лиц людей, например, поэтому именно с этим проблем нет. Нетривиальная логика — тоже есть. То есть те функции, на которые миллионы лет оптимизировала эволюция. А попробуйте перемножить два int32 числа, или удержать в памяти с сотню байт — у вас это получится намного хуже, чем даже у 100гц компьютеров.
Касательно «выкидывания в корзину» параллельных алгоритмов — это вы сейчас странное сказали. Любой параллельный алгоритм может быть выполнен последовательно. Следовательно, хорошо параллелящийся алгоритм не может быть хуже плохо параллелящегося по общему количеству затраченного времени. Другое дело, что задача создавать параллелизуемые алгоритмы сама по себе не ставилась. Но они и менее эффективны в целом, и требуют затрат на синхронизацию, и для понимания сложнее, так что до недавнего времени не были так востребованы.
Ну и не стоит останавливаться только на параллельности. Можно развивать FPGA и делать хорошие конвейеры. Возможно, в будущем у процессоров или отдельно по PCI будет несколько FPGA массивов, и высокопроизводительные приложения будут их использовать, как сейчас видеокарты.
Попап с входом на отдельной странице не так уж и связан. Я видел и системы, где после ввода пароля вас редиректили прямо обратно( по Referer или параметром в адресе страницы логина). Я видел, когда после ввода логин/пароль в сайдбаре вас выкидывало на главную страницу сайта.
По датам точно совпадает, и именно поэтому не может быть причиной. Хотя бы просто потому, что когда арестовали Калви, в Америке была ночь. Некому было отключать Россию от Splunk.
В приложении даже нажимать ничего не нужно, просто прокрутить до конца.
А именно — если у объекта есть final поля, то гарантируется, что после вызова конструктора их значения будут правильными для всех потоков. Но это неверно, если ссылка на объект была куда-то (например в другой поток) передана внутри конструктора.
И сделано это буквально вчера.
Тут извиняюсь, ошибся. Хотел написать «хуже».
С другой стороны, у поведения имеется огромное количество когнитивных погрешностей, которые возникли именно из-за этой оптимизации. Представьте, что вы сотню лет пишете и переписываете код этой странички. Естественно, за это время вы успеете перепробовать тонну подходов, выучите или создадите ассемблер и напишете на нём. И это будет дико эффективно.
Если у нас были кубики «О», «П», «А» и «Ж» — мы не могли сложить «Вечность». Всем требуется выпускать продукты «быстрее, ещё быстрее». А написать быстро, без ошибок и производительное — выберите два, как говорится.
Касательно «выкидывания в корзину» параллельных алгоритмов — это вы сейчас странное сказали. Любой параллельный алгоритм может быть выполнен последовательно. Следовательно, хорошо параллелящийся алгоритм не может быть хуже плохо параллелящегося по общему количеству затраченного времени. Другое дело, что задача создавать параллелизуемые алгоритмы сама по себе не ставилась. Но они и менее эффективны в целом, и требуют затрат на синхронизацию, и для понимания сложнее, так что до недавнего времени не были так востребованы.
Ну и не стоит останавливаться только на параллельности. Можно развивать FPGA и делать хорошие конвейеры. Возможно, в будущем у процессоров или отдельно по PCI будет несколько FPGA массивов, и высокопроизводительные приложения будут их использовать, как сейчас видеокарты.
Так что ваши варианты, увы, не подходят.