信息的宽面和窄面

诸如“某女星在某大会上大肆露胸”、“热火VS山猫首战,热火获胜”、“某网站被恶意攻击”等裹挟着有用无用的信息从社交网络扑面而来,即使你自身不想去接受这些信息,根本无法找到关闭提示的手机软件也会“叮”的一声提示你,又有新的信息会进入到你因为写代码而略微酸沉的大脑。

除去互联网带来的各种信息,包括报刊、杂志、电视、路边广告等信息亦无所不在的钻入到用户的大脑皮层,有的会被沉淀下来,而有的则会快速的被过滤掉,但是,信息无处不在。

摩尔定律提到:当价格不变时,集成电路上可容纳的晶体管数目,约每隔18个月便会增加一倍,性能也将提升一倍,这一定律揭示了信息技术进步的速度。对于程序员和开发者来说,技术的变革亦会随着时间的时间的叠加而出现快速的飞跃,每隔几年都会有一些新技术出现,时不时就会有各种大会,包括开发者交流大会、程序员交流大会、互联网大会以及涉及到开发者自己产品的大会等,这其中包含的“精致”信息亦会被开发者们不断吸收。

信息是宽的,比南美的亚马逊河还宽广

世界上最宽的河是南美的亚马逊河,在河流的入海处,其宽度达320千米,但是信息比亚马逊河还要宽。一条信息从和我们的另一边美国再传到国内,仅仅几分钟而已,如果是在上个500年里,这是无法想象的事情,至少,你想知道“美国的XXX很好吃”这条信息得流传很长一段时间,所以,如果用物理单位去衡量信息,它确实是很宽广的。

当然如果你不去主动接受某条信息,该条信息对于你个人是不存在的,你本身不喜欢“天蝎座”,该类信息要主动流通到你身上并不容易。

信息的宽度还体现在(作者微信公众号:郭静的互联网圈),用户每天都会主动、被动的接受各种各样的信息。先说主动性,一个开发者可能会主动去关注科技类、程序类、互联网、财经、时政、军事类信息,这些信息是开发者自己主动去接受的信息,当然也会被动的接受诸如女性、体育、娱乐等信息,其中就包括天文地理、鱼虫水鸟、代码开发等各类信息,整个信息的面是宽阔的。

为何我们会接受到如此宽阔的信息呢,虽然我们只是想知道“PHP框架”的信息。用户获取信息的渠道可以分为几大类,一个是互联网,其中包括新闻网站、论坛、社区、贴吧、微博、QQ、手机新闻客户端以及其他移动端流通出来的信息;二是报刊、杂志、书籍等纸质信息流通平台;三是电视类电子产品流通出来的信息;四是人自身流通眼睛“扫描”到的信息,如地铁、公交车、出租车等各处张贴的广告信息;五是其他用户输入的信息,比如三大姑八大姨、同事、朋友等都会向用户输入信息流。

用户接受宽广的信息的好处是:会让用户变成一个无所不知的“智者”,能侃侃而谈的的“资深专家”,用户不仅是一个程序员,还是一个“妇女之友”;不仅是一个C++工程师,还是一个“娱乐天王”,当然如果你是一个投资高手,广泛的信息量亦会给你提供不少帮助。

用户选择接受宽广的信息劣势是:宽泛的信息会向亚马逊河流一样快速流进用户脑海里,仅从互联网的渠道来看,微信、微博、新闻客户端、社交工具等方面流入的广大信息量,用户就很难一下子“吃进去”,而随着用户接受时间对信息的消耗,用户很容易被信息的横流给直接吞噬掉,所有的时间都被消耗在了凶猛的信息流中。再加上其他渠道流入的信息,用户接受信息的大脑会被宽广的信息冲的七零八落,大脑无法一次性储存如此多的信息量,没办法储存,信息就会直接流失。

信息是窄的,就像2.4mm的边框手机

据称,全球最窄的手机边框只有2.4mm,可是信息却比它还要窄。当用户不去关注该条信息,该条信息对于用户就是“死”的,甚至是不存在的。用户在对信息吸收的过程中,会有选择性的吸收自己主动需求的信息,而被动接收的信息则随着时间的流逝而从脑海里消逝掉。

信息的窄面还体现在,当某开发者只试图关注开发者的相关信息的时候,用户会主动通过关键词订阅、新闻客户端订阅、微博订阅等“信息过滤”的方式,让宽广的信息流慢慢变窄,最后自己在进行吸收消化。当科技、互联网、金融、财政等各方面信息流从四面八方充斥而来,而用户自身只想关注互联网信息的时候,就需要对信息进行“切割整理”,让信息变得更窄。

用户让信息变窄的好处是:信息得到精准流动,除非不能改变的被动信息接收,其他不必要的信息均会主动被“紧闭”,另一方面用户花在接收信息的时间也会降低,不至于被海量的信息流淹没掉。

信息变窄的劣势是:开发者若只获取“C++、开发者大会”等“窄面”的信息,很有可能会让自己陷入更窄的生活群体,视野、视角都会有限,“一心只读C++,两耳不闻窗外事”的结局是,会因接收不到宽广的信息而被人认为是“怪癖男”、“程序猿”、“攻城狮”。

如何处理信息的宽面和窄面?

TMI(too much information,即信息过多的意思),信息疲劳、信息焦虑以及信息过剩是我们当前遇到的最严重的问题之一。互联网和移动互联网的崛起,改变了用户对信息获取的方式,同时也加深了信息的流速,而信息的宽面和信息的窄面问题显得愈来愈严重。

那么该如果处理信息的宽面和窄面问题呢?我认为首先肯定不能做“信息的囚徒”,即每天被各方的信息流冲击,微博提示用户“XXX地发生泥石流”,朋友圈XXX同学发布他正在某地旅游,黑色的企鹅图像不停的在桌面闪动,在有限的时间内,不能被海量的信息压垮。让用户成为一个信息的“独行侠”也是不对的,吃喝拉撒睡乐,信息都起着不可忽视的作用。

企业面对这种TMI信息的时候,需要将信息进行过滤,有选择性的关注微博、微信、朋友圈、新闻网站等信息平台,可选择订阅相关频道以及关键词设置,缩减信息的流入,在对外的信息上,则可以选择搜索引擎以及新闻客户端产品,都可以增大信息的宽面。

而对于企业自身的信息输出来说,信息想要通过如此广泛的信息流中流入到用户层面,会消耗大量财力、人力。新闻客户端产品中的频道设置,很好的解决了此问题,特别是地域性设置,企业通过对地域性的新闻流进行广告投放,避免广告价值被“流放”到其他平台,信息由宽面跳到窄面,信息的价值更具精准性。

为你的海量信息减负吧,远离TMI。

文/郭静,国内最大的自媒体联盟WeMedia联盟成员,微信公众号:郭静的互联网圈

信息的宽面和窄面

时间: 2024-11-05 11:42:45

信息的宽面和窄面的相关文章

宽字符和窄字符之间的转换,以及对中文的处理问题总汇

直接代码: 注:编译环境VS2010 SP1 1 /*实现宽字节和窄字符转换以及中文文件的输入输出*/ 2 3 #include <iostream> 4 #include <string> 5 #include <fstream> 6 #include <locale> 7 #include <codecvt> 8 #include <windows.h> 9 #include <tchar.h> 10 using na

立体匹配中宽基线与窄基线的定义

基线的本意是指立体视觉系统中两摄像机光心之间的距离.依据拍摄两幅图 像的视点位置关系可将对应点匹配问题分为宽基线(Wide Baseline)和窄基线匹配(Short Baseline).宽基线一词用于匹配时,泛指两幅图像有明显不同的情况下的匹配.产生这种情况的原因有可能为摄像机之间的位置相差很大,也有可能由于摄像机旋转或焦距的变化等因素产生的. 宽基线匹配和窄基线匹配的分界不是很严格,但是在窄基线匹配中存在如下假设:摄像机焦距及其它内参数变化不大:摄像机位置不会相差很远,不会有大的转动,对应点

[转]宽基线与窄基线

基线的本意是指立体视觉系统中两摄像机光心之间的距离.依据拍摄两幅图 像的视点位置关系可将对应点匹配问题分为宽基线(Wide Baseline)和窄基线匹配(Short Baseline).宽基线一词用于匹配时,泛指两幅图像有明显不同的情况下的匹配.产生这种情况的原因有可能为摄像机之间的位置相差很大,也有可能由于摄像机旋转或焦距的变化等因素产生的. 宽基线匹配和窄基线匹配的分界不是很严格,但是在窄基线匹配中存在如下假设:摄像机焦距及其它内参数变化不大:摄像机位置不会相差很远,不会有大的转动,对应点

RDD Join中宽依赖与窄依赖的判断

1.规律 如果JoinAPI之前被调用的RDD API是宽依赖(存在shuffle), 而且两个join的RDD的分区数量一致,join结果的rdd分区数量也一样,这个时候join api是窄依赖 除此之外的,rdd 的join api是宽依赖 2.测试程序 1 package com.ibeifeng.senior.join 2 3 import org.apache.spark.{SparkConf, SparkContext} 4 5 /** 6 * RDD数据Join相关API讲解 7

Spark RDD 的宽依赖和窄依赖 -- (视频笔记)

窄依赖 narrow dependency map,filter,union , join(co-partitioned)制定了父RDD中的分片具体交给哪个唯一的子RDD 并行的,RDD分片是独立的. 只依赖相同ID的分片 range分片 one to dependency range dependency 内部可以previously computed partition 可以将计算合并,可以极大的提升效率,编写的时候可能是多个函数,执行的时候合并成一个函数,极大的减少了零碎内存或磁盘资源.

宽表和窄表的建设该如何选择?

https://blog.csdn.net/codemosi/article/details/44219687 原文地址:https://www.cnblogs.com/zwt20120701/p/12092653.html

volatile,可变参数,memset,内联函数,宽字符窄字符,国际化,条件编译,预处理命令,define中##和#的区别,文件缓冲,位域

 1.volatile:要求参数修改每次都从内存中的读取.这种情况要比普通运行的变量需要的时间长. #include <stdio.h> #include <stdlib.h> #include <time.h> void main() { time_t start, end; double res = 0; time(&start);  //获取时间,传递给start //volatile强制每次从内存读取 volatile int i; for (i =

tableview中index对英文字符汉字字符(窄字符宽字符)处理

[问题描述] 开发iOS通讯录项目,遇到一个tableview 索引的问题. 测试同学发现一个bug:添加一个名字为宽字符A不能归并到索引A的section中,而是使用了添加了一个叫A的索引,如图: 上图中:右侧索引尾部发生异常.ABX并没有归并到正常的索引中,而是出现在正常索引的Z和#之间了. [问题分析] 想了一下,应该是宽字符A和A的编码不一致导致的. 之前代码是这样的,看第二行使用正则表达式判断首字母是不是拉丁字母开头,然后标注此人是以某个字符开头的,代码如下: NSPredicate*

宽字符wchar_t和窄字符char——putwchar、wprintf

宽字符wchar_t 与 窄字符char 先说下窄字符char,这个大部分读者应该很清楚,char类型的变量占一个字节(byte)(也就是8个bit(比特)),能表示256个字符,那char的范围有两种 第一种(signed char):-128~127 第二种(unsigned char):0~255 (对char的范围感兴趣的读者可以看一下这篇文章:浅谈char类型范围) 但C标准并没有规定char 应该是unsigned还是signed,C标准定义了三种类型:char.signed cha