TGTGInsightтелеграм анализLIVE / telegram public index
← Такты, стеки, два колеса

TGINSIGHT SIMILAR POSTS

Намери подобно съдържание

Изходен канал @clockstackwheels · Post #983 · 11.05

Художник Gudim написал у себя в Телеграме пост о том, что главная проблема соцсетей — умные ленты. В более-менее продвинутой среде и правда принято хейтить умные ленты, включать, где возможно, хронологические, юзать альтернативные клиенты и вообще ругать корпорации за то, что они делают плохо и пользователям и авторам контента одновременно. Вездесущие умные ленты — действительно часть процесса оговнения, но дело не только в нём. Gudim сделал отсылку к классике в шутку, но на самом деле угадал: главная проблема соцсетей ровно такая же, как и главная проблема музыки — это ты. Давайте разберёмся. В теории ты подписываешься на авторов контента в соцсети, они публикуют свои посты по мере желания и готовности, посты выстраиваются в ленту, и ты от новых к старым их читаешь, подобно свежей газете или сводке новостей. Звучит хорошо до того момента, пока ты не подпишешься на условный паблик с приколами. Паблик с приколами ведут 10 человек, а сами приколы они тащат с Реддита и 9гаг, поэтому публикация занимает 5 минут. При этом от пользователей они получают охваты, которые конвертируются в деньги с рекламы. Больше охватов — больше денег. Очень быстро система приходит к тому, что им выгодно постить так часто, как они вообще способны. В идеале они хотят, чтобы вся лента каждого юзера состояла только из паблика с приколами, потому что тогда они заработают ещё больше. Вообще я лично видел рекомендации от СММщиков для пабликов ВК постить 3-5 записей в день. Каждый день. А теперь вспомните, как часто постят ваши друзья или, например, независимые авторы, которые контент не где-то берут, а создают. И вот 2-3 таких подписки, и ваша лента — неюзабельный мусор. Не обязательно паблик с приколами: спамить мотивирован вообще любой автор, потому что его доля присутствия в вашей ленте равна его заработку. Но хороший контент делается долго, на это нужно время, так что в реальности особенно удаётся спамить как раз плохому и дешёвому контенту. Как это решить: 1. "Не подписывайтесь на мусор", "Человек сам виноват, что он подписался на спам-паблик!". Да, а ещё человек совершенно добровольно решает начать курить или, скажем, принимать наркотики, но эти области всё равно в разной степени контролируются извне. Потому что авторы спам-паблика (как и наркоторговцы) ОЧЕНЬ мотивированы затянуть новых людей в свою схему заработка, и они будут использовать для этого множество разных средств, на которые неминуемо попадётся значимое число клиентов. То есть в масштабах одного конкретного человека с железной дисциплиной этот подход работает, но в масштабах системы из множества произвольных людей — нет, не работает совсем. 2. Остаётся только одно — каким-то образом фильтровать мусор. Тут возникает сразу много других проблем: начиная с того, что для разных людей понятие мусора разное, и заканчивая тем, что, да, в какой-то момент появляются ещё и интересы площадки. Площадка хочет не давать людям приятный и интересный контент, а давать людям то, что увеличивает таймспент и заработок с рекламы. И внезапно получается так, что таймспент растёт не от качества контента, кто бы мог подумать. Самые популярные в мире соцсети (Инста и Тикток) — целиком основаны на алгоритмической подаче информации. И эта информация очень "жвачкообразная" — короткая, клиповая, с быстрым захватом внимания. Так что да, если ругаете умные ленты, то просто поругайте какого-от своего друга, который пользуется Инстой, потому что именно поведение юзеров и отсутствие дисциплины у них делает такие ленты выгодными для корпораций. #web

Hashtags

Резултати

Намерени 38 подобни публикации

Търсене: #asyncio

当前筛选 #asyncio清除筛选
djangoproject

@djangoproject · Post #96 · 11.07.2016 г., 12:16

https://docs.python.org/3/library/asyncio-task.html#asyncio.run_coroutine_threadsafe #asyncio.run_coroutine_threadsafe(coro, loop) Submit a coroutine object to a given event loop. Return a concurrent.futures.Future to access the result.

Hashtags

djangoproject

@djangoproject · Post #75 · 28.06.2016 г., 10:29

https://docs.python.org/3/library/asyncio-eventloop.html The event loop is the central execution device provided by #asyncio. It provides multiple facilities, including: Registering, executing and cancelling delayed calls (timeouts). Creating client and server transports for various kinds of communication. Launching subprocesses and the associated transports for communication with an external program. Delegating costly function calls to a pool of threads.

Hashtags

djangoproject

@djangoproject · Post #337 · 09.05.2017 г., 08:28

http://blog.povilasb.com/posts/python-asyncio-vs-nginx-performance/ While I was playing with Python #asyncio I got interested in how well it performs serving data over TLS compared to #Nginx. So I implemented a small HTTPS server with asyncio:

djangoproject

@djangoproject · Post #152 · 03.09.2016 г., 20:18

https://glyph.twistedmatrix.com/2014/02/unyielding.html As we know, #threads are a bad idea, (for most purposes). Threads make local reasoning difficult, and local reasoning is perhaps the most important thing in software development. With the word “threads”, I am referring to shared-state multithreading, despite the fact that there are languages, like Erlang and Haskell which refer to concurrent processes – those which do not implicitly share state, and require explicit coordination – as “threads”. #asyncio

djangoproject

@djangoproject · Post #311 · 25.04.2017 г., 11:59

http://programtalk.com/python-examples/aiohttp.web.Application/?ipage=1 Here are the examples of the python api #aiohttp.web.Application taken from open source projects. By voting up you can indicate which examples are most useful and appropriate. #asyncio#learn

djangoproject

@djangoproject · Post #268 · 26.02.2017 г., 05:52

https://pawelmhm.github.io/asyncio/python/aiohttp/2016/04/22/asyncio-aiohttp.html 👌Making 1 million requests with python -#aiohttp Apr 22, 2016 - by Paweł Miech - about: #asyncio, aiohttp, #python In this post I’d like to test limits of python aiohttp and check its performance in terms of requests per minute. Everyone knows that asynchronous code performs better when applied to network operations, but it’s still interesting to check this assumption and understand how exactly it is better and why it’s is better. I’m going to check it by trying to make 1 million #requests with aiohttp client. How many requests per minute will aiohttp make? What kind of exceptions and crashes can you expect when you try to make such volume of requests with very primitive scripts? What are main gotchas that you need to think about when trying to make such volume of requests?

djangoproject

@djangoproject · Post #319 · 29.04.2017 г., 07:54

https://github.com/aio-libs/aiobotocore Async client for amazon services using #botocore and #aiohttp/#asyncio. Main purpose of this library to support amazon s3 api, but other services should work (may be with minor fixes). For now we have tested only upload/download api for s3, other users report that SQS and Dynamo services work also. More tests coming soon.

ПредишнаСтр. 1 от 4Следваща