I never thought that I would travel in Japan since I witnessed countless breathtaking landscapes in Western Sichuan and Tibet. However, things changed after I landed at Narita Airport.

I gotta say, I had a pretty good experience travelling here. I remember as soon as I stepped off the jet bridge, I could smell a refreshing fragrance in the airport (it was present wherever people had been, and the scent was remarkably consistent; I even suspected that everyone in this country used the same perfume). Later, I realized that it might be because I was using the same laundry detergent or fabric softener.

Besides, the people here are generally very clean. I saw that the streets were clean, the cars were clean, the houses were clean, and even the toilets were clean. Although I had heard about this online before, seeing it in person was still quite impressive; it’s wonderful. Also, I realized as I was leaving that I didn’t seem to smell any secondhand smoke on the street, which is a real relief for someone like me with rhinitis.

What’s more, based on my experience with the locals (mainly those in the service industry), they were all very polite. Although I don’t understand Japanese, the various honorifics and bows made me feel a little uncomfortable. Anyway, I would definitely come back if I had the chance.

台场眺望东京塔&六本木，天气之子打卡地

苫小牧海岸

苫小牧王子造纸

苫小牧海岸

札幌新千岁机场

洞爷湖

隅田川

羽田机场

Tokyo Dome 东京巨蛋

浅草寺

隅田川

东京站&丸之内

Roppongi, Tokyo Tower and Rainbow Bridge

品川港

森户海岸&真名濑海岸

真名濑车站

森户海岸&真名濑海岸

叶山町&逗子市

叶山町&逗子市

叶山町&逗子市

日暮里站附近

海岸

同时进近成田的国内航班，海航or深航

进近东京成田机场，左手方向 富士山

{"slidestoshow":3,"slidestoscroll":1,"dots":"true","arrows":"true","autoplay":"true","autoplay_interval":3000,"speed":300,"loop":"true","lazyload":""}

In August 2025, we went to Yunnan again! The weather in Yunnan is literally cozy, the landscape here is pleasing to the eyes, and the cuisine is mouth-watering!

Since the weather in Sichuan was extremely terrible and the temperature was almost over 40°C. That made me feel like I’m melting. Plus, I promised Dr. He to go to Yunnan together earlier. I decided to have a road trip to Yunnan based on these issues.

I took 2 days to drive to Kunming (capital city of Yunnan) from Sichuan. There were only a few people outdoors along the way cause it was highly hot.

After entering Yunnan, the situation improved a lot. The air was no longer humid or hot. A cool breeze hit me, which made me feel relaxed.

I picked up Dr. He at Kunming South Rail Station and we had a small meal and embarked the trip to Chengjiang, the place where Fuxian Lake located.

The evening clouds there was not as amazing as I imagined but the vibe there was cozy as the breeze was mild and we walked along the lakeside and talked a lot.

The shown line chart represents the useage figures for distinct energy sources in America between 1980 and 2030 from a message.

According to the graph above, the data for petrol and oil showed a dramatic rising trend with a few fluctuations and which is far more than other categories of energy sources. At the same time, it is obvious that the usage of coal increased gradually from 1980 (16 quadrillion units) to 2024 (27 quadrillion units) and is projected to increase to reach 30 in 2030 based on the prediction. On the other hand, the development of natural gas grew slowly from 1980 to 2024 and will almost remain stable in the future.

It is clear from the data that the amount of clean energy generally rose slightly from 1980 to 2024 and will continue to keep steady in the future, particularly the figure of hydropower experienced a minor fluctuation between 1980 and 2010 and returned its original level.

 the utilization of fossil fuel kept a obvious increase over the past 4 decades and will remain a constant upward trend in the next 7 years.

In general, fossil fuel dominated the energy market and will keep their advantage in the future. In contrast, the clean energies only accounted for a small percentage in the utilization of energy.

Actually, I collected many videos and photos to make this vlog. I may have taken over 20 hours or more on image and video editing. When I found the photos and videos I took at that time, many experiences from that time came to my mind, which were very interesting and unforgettable. I believe that life is an adventure. I’m looking forward to my next trip and I hope life will always be on the journey.

Mt Yala

Haizi Mountain and Sister Lakes by the G318

The galaxy on the Katzilla Mountains

Mt Yala

Red lake in Kangting

A snowy mountain nearby Ranwu Lake and the sunset on it, taken by Bob.

A colorful hillside

A long road without a few cars on it, taken by Bob.

The well-known seventy-two turns on the G318

The well-known seventy-two turns, taken by Bob.

Zada soil forest in Zhada county

Zhada soil forest and Himalayas in the distance

Zhada soil forest

Namunani Peak

Mt Gang Rinpoche in Tibet, taken by Bob.

A Tibetan fox at the G318

A Tibetan Fox by the G318

A salt lake in Ngari

A few Tibetan wild donkeys in a reserve

Two Tibetan wild donkeys by the G109

The National Road 109 to Golmud, taken by Bob.

Sunset glow in Selintsok, taken by Bob.

A dark mountain nearby National Road 317, taken by Bob.

A few wild horses galloping on the Qiangtang Grassland, taken by Bob.

A single soil forest in the sunset, taken by Bob.

The road to Zada County, taken by Bob.

A Tibetan wild donkey in Ngari Prefecture, taken by Bob.

A car parking at the lakeside of Peiku-tso, taken by Bob.

A relic in Dingri County, taken by Bob.

Midui glacier nearby G318, taken by Bob.

Ranwu Lake in autumn, taken by Bob.

Mount Everest and Cho Oyu, taken by Bob.

{"slidestoshow":3,"slidestoscroll":1,"dots":"true","arrows":"true","autoplay":"true","autoplay_interval":3000,"speed":300,"loop":"true","lazyload":""}

由于系统中有定时任务自动执行，而启动定时任务时是非www用户，同时该任务中含有写日志的部分(按天生成日志），此时目录下尚无当日的日志，于是生成了权限为非www用户的日志文件，当后续www用户操作需要写日志时，就没有写入的权限了，因此后续程序全部被中断。

经过比较，解决方案如下：

第一种，取消正在运行的定时任务，指定执行定时任务的用户为www用户，重新启动定时任务；

第二种，为了不影响线上业务，不取消定时任务，用脚本定时检查日志文件是否对www开放写入权限，如果没有则加入；

第三种，利用laravel日志中的channel功能，在www用户需要写入日志的地方，指定channel写入，不与定时任务产生的日志文件相冲突。

出处：http://www.cnblogs.com/yangecnu/ http://www.cnblogs.com/yangecnu/p/Introduce-Hashtable.html

基于无序列表的顺序查找，基于有序数组的二分查找，平衡查找树，以及红黑树，下图是他们在平均以及最差情况下的时间复杂度：

Different structure with different efficient

可以看到在时间复杂度上，红黑树在平均情况下插入，查找以及删除上都达到了lgN的时间复杂度。

那么有没有查找效率更高的数据结构呢，答案就是本文接下来要介绍了散列表，也叫哈希表(Hash Table)

什么是哈希表
哈希表就是一种以 键-值(key-indexed) 存储数据的结构，我们只要输入待查找的值即key，即可查找到其对应的值。

哈希的思路很简单，如果所有的键都是整数，那么就可以使用一个简单的无序数组来实现：将键作为索引，值即为其对应的值，这样就可以快速访问任意键的值。这是对于简单的键的情况，我们将其扩展到可以处理更加复杂的类型的键。

使用哈希查找有两个步骤:

使用哈希函数将被查找的键转换为数组的索引。在理想的情况下，不同的键会被转换为不同的索引值，但是在有些情况下我们需要处理多个键被哈希到同一个索引值的情况。所以哈希查找的第二个步骤就是处理冲突
处理哈希碰撞冲突。有很多处理哈希碰撞冲突的方法，本文后面会介绍拉链法和线性探测法。
哈希表是一个在时间和空间上做出权衡的经典例子。如果没有内存限制，那么可以直接将键作为数组的索引。那么所有的查找时间复杂度为O(1)；如果没有时间限制，那么我们可以使用无序数组并进行顺序查找，这样只需要很少的内存。哈希表使用了适度的时间和空间来在这两个极端之间找到了平衡。只需要调整哈希函数算法即可在时间和空间上做出取舍。

哈希函数
哈希查找第一步就是使用哈希函数将键映射成索引。这种映射函数就是哈希函数。如果我们有一个保存0-M数组，那么我们就需要一个能够将任意键转换为该数组范围内的索引（0~M-1）的哈希函数。哈希函数需要易于计算并且能够均匀分布所有键。比如举个简单的例子，使用手机号码后三位就比前三位作为key更好，因为前三位手机号码的重复率很高。再比如使用身份证号码出生年月位数要比使用前几位数要更好。

在实际中，我们的键并不都是数字，有可能是字符串，还有可能是几个值的组合等，所以我们需要实现自己的哈希函数。

1. 正整数
   获取正整数哈希值最常用的方法是使用除留余数法。即对于大小为素数M的数组，对于任意正整数k，计算k除以M的余数。M一般取素数。
2. 字符串
   将字符串作为键的时候，我们也可以将他作为一个大的整数，采用保留除余法。我们可以将组成字符串的每一个字符取值然后进行哈希，比如

public int GetHashCode(string str)
{
char[] s = str.ToCharArray();
int hash = 0;
for (int i = 0; i < s.Length; i++)
{
hash = s[i] + (31 * hash);
}
return hash;
}
上面的哈希值是Horner计算字符串哈希值的方法，公式为:

h = s[0] · 31L–1 + … + s[L – 3] · 312 + s[L – 2] · 311 + s[L – 1] · 310

举个例子，比如要获取”call”的哈希值，字符串c对应的unicode为99，a对应的unicode为97，L对应的unicode为108，所以字符串”call”的哈希值为 3045982 = 99·313 + 97·312 + 108·311 + 108·310 = 108 + 31· (108 + 31 · (97 + 31 · (99)))

如果对每个字符去哈希值可能会比较耗时，所以可以通过间隔取N个字符来获取哈西值来节省时间，比如，可以 获取每8-9个字符来获取哈希值：

public int GetHashCode(string str)
{
char[] s = str.ToCharArray();
int hash = 0;
int skip = Math.Max(1, s.Length / 8);
for (int i = 0; i < s.Length; i+=skip)
{
hash = s[i] + (31 * hash);
}
return hash;
}
但是，对于某些情况，不同的字符串会产生相同的哈希值，这就是前面说到的哈希冲突（Hash Collisions），比如下面的四个字符串：

hash code collision

如果我们按照每8个字符取哈希的话，就会得到一样的哈希值。所以下面来讲解如何解决哈希碰撞：

避免哈希冲突
拉链法 (Separate chaining with linked lists)
通过哈希函数，我们可以将键转换为数组的索引(0-M-1)，但是对于两个或者多个键具有相同索引值的情况，我们需要有一种方法来处理这种冲突。

一种比较直接的办法就是，将大小为M 的数组的每一个元素指向一个条链表，链表中的每一个节点都存储散列值为该索引的键值对，这就是拉链法。下图很清楚的描述了什么是拉链法。

seperate chaining with link list

图中，”John Smith”和”Sandra Dee” 通过哈希函数都指向了152 这个索引，该索引又指向了一个链表， 在链表中依次存储了这两个字符串。

该方法的基本思想就是选择足够大的M，使得所有的链表都尽可能的短小，以保证查找的效率。对采用拉链法的哈希实现的查找分为两步，首先是根据散列值找到等一应的链表，然后沿着链表顺序找到相应的键。 我们现在使用我们之前介绍符号表中的使用无序链表实现的查找表SequentSearchSymbolTable 来实现我们这里的哈希表。当然，您也可以使用.NET里面内置的LinkList。

首先我们需要定义一个链表的总数，在内部我们定义一个SequentSearchSymbolTable的数组。然后每一个映射到索引的地方保存一个这样的数组。

public class SeperateChainingHashSet : SymbolTables where TKey : IComparable, IEquatable
{
private int M;//散列表大小
private SequentSearchSymbolTable[] st;//

public SeperateChainingHashSet()
    : this(997)
{

}

public SeperateChainingHashSet(int m)
{
    this.M = m;
    st = new SequentSearchSymbolTable<TKey, TValue>[m];
    for (int i = 0; i < m; i++)
    {
        st[i] = new SequentSearchSymbolTable<TKey, TValue>();
    }
}

private int hash(TKey key)
{
    return (key.GetHashCode() & 0x7fffffff) % M;
}

public override TValue Get(TKey key)
{
    return st[hash(key)].Get(key);
}

public override void Put(TKey key, TValue value)
{
    st[hash(key)].Put(key, value);
}

}
可以看到，该实现中使用

Get方法来获取指定key的Value值，我们首先通过hash方法来找到key对应的索引值，即找到SequentSearchSymbolTable数组中存储该元素的查找表，然后调用查找表的Get方法，根据key找到对应的Value。
Put方法用来存储键值对，首先通过hash方法找到改key对应的哈希值，然后找到SequentSearchSymbolTable数组中存储该元素的查找表，然后调用查找表的Put方法，将键值对存储起来。
hash方法来计算key的哈希值， 这里首先通过取与&操作，将符号位去除，然后采用除留余数法将key应到到0-M-1的范围，这也是我们的查找表数组索引的范围。
实现基于拉链表的散列表，目标是选择适当的数组大小M，使得既不会因为空链表而浪费内存空间，也不会因为链表太而在查找上浪费太多时间。拉链表的优点在于，这种数组大小M的选择不是关键性的，如果存入的键多于预期，那么查找的时间只会比选择更大的数组稍长，另外，我们也可以使用更高效的结构来代替链表存储。如果存入的键少于预期，索然有些浪费空间，但是查找速度就会很快。所以当内存不紧张时，我们可以选择足够大的M，可以使得查找时间变为常数，如果内存紧张时，选择尽量大的M仍能够将性能提高M倍。

线性探测法
线性探测法是开放寻址法解决哈希冲突的一种方法，基本原理为，使用大小为M的数组来保存N个键值对，其中M>N，我们需要使用数组中的空位解决碰撞冲突。如下图所示：

open address

对照前面的拉链法，在该图中，”Ted Baker” 是有唯一的哈希值153的，但是由于153被”Sandra Dee”占用了。而原先”Snadra Dee”和”John Smith”的哈希值都是152的，但是在对”Sandra Dee”进行哈希的时候发现152已经被占用了，所以往下找发现153没有被占用，所以存放在153上，然后”Ted Baker”哈希到153上，发现已经被占用了，所以往下找，发现154没有被占用，所以值存到了154上。

开放寻址法中最简单的是线性探测法：当碰撞发生时即一个键的散列值被另外一个键占用时，直接检查散列表中的下一个位置即将索引值加1，这样的线性探测会出现三种结果：

命中，该位置的键和被查找的键相同
未命中，键为空
继续查找，该位置和键被查找的键不同。
实现线性探测法也很简单，我们只需要两个大小相同的数组分别记录key和value。

public class LinearProbingHashSet : SymbolTables where TKey : IComparable, IEquatable
{
private int N;//符号表中键值对的总数
private int M = 16;//线性探测表的大小
private TKey[] keys;
private TValue[] values;

public LinearProbingHashSet()
{
    keys = new TKey[M];
    values = new TValue[M];
}

private int hash(TKey key)
{
    return (key.GetHashCode() & 0xFFFFFFF) % M;
}

public override TValue Get(TKey key)
{
    for (int i = hash(key); keys[i] != null; i = (i + 1) % M)
    {
        if (key.Equals(keys[i])) { return values[i]; }
    }
    return default(TValue);
}

public override void Put(TKey key, TValue value)
{
    int hashCode = hash(key);
    for (int i = hashCode; keys[i] != null; i = (i + 1) % M)
    {
        if (keys[i].Equals(key))//如果和已有的key相等，则用新值覆盖
        {
            values[i] = value;
            return;
        }
        //插入
        keys[i] = key;
        values[i] = value;
    }
}

}
线性探查（Linear Probing）方式虽然简单，但是有一些问题，它会导致同类哈希的聚集。在存入的时候存在冲突，在查找的时候冲突依然存在。

性能分析
我们可以看到，哈希表存储和查找数据的时候分为两步，第一步为将键通过哈希函数映射为数组中的索引， 这个过程可以认为是只需要常数时间的。第二步是，如果出现哈希值冲突，如何解决，前面介绍了拉链法和线性探测法下面就这两种方法进行讨论：

对于拉链法，查找的效率在于链表的长度，一般的我们应该保证长度在M/8~M/2之间，如果链表的长度大于M/2，我们可以扩充链表长度。如果长度在0~M/8时，我们可以缩小链表。

对于线性探测法，也是如此，但是动态调整数组的大小需要对所有的值从新进行重新散列并插入新的表中。

不管是拉链法还是散列法，这种动态调整链表或者数组的大小以提高查询效率的同时，还应该考虑动态改变链表或者数组大小的成本。散列表长度加倍的插入需要进行大量的探测， 这种均摊成本在很多时候需要考虑。

哈希碰撞攻击
我们知道如果哈希函数选择不当会使得大量的键都会映射到相同的索引上，不管是采用拉链法还是开放寻址法解决冲突，在后面查找的时候都需要进行多次探测或者查找， 在很多时候会使得哈希表的查找效率退化，而不再是常数时间。下图清楚的描述了退化后的哈希表：

hashCollision

哈希表攻击就是通过精心构造哈希函数，使得所有的键经过哈希函数后都映射到同一个或者几个索引上，将哈希表退化为了一个单链表，这样哈希表的各种操作，比如插入，查找都从O(1)退化到了链表的查找操作，这样就会消耗大量的CPU资源，导致系统无法响应，从而达到拒绝服务供给(Denial of Service, Dos)的目的。之前由于多种编程语言的哈希算法的“非随机”而出现了Hash碰撞的DoS安全漏洞，在ASP.NET中也曾出现过这一问题。

在.NET中String的哈希值内部实现中，通过使用哈希值随机化来对这种问题进行了限制，通过对碰撞次数设置阈值，超过该阈值就对哈希函数进行随机化，这也是防止哈希表退化的一种做法。下面是BCL中string类型的GetHashCode方法的实现，可以看到，当碰撞超过一定次数的时候，就会开启条件编译，对哈希函数进行随机化。

[ReliabilityContract(Consistency.WillNotCorruptState, Cer.MayFail), SecuritySafeCritical, __DynamicallyInvokable]
public override unsafe int GetHashCode()
{
if (HashHelpers.s_UseRandomizedStringHashing)
{
return InternalMarvin32HashString(this, this.Length, 0L);
}
fixed (char* str = ((char) this)) { char chPtr = str;
int num = 0x15051505;
int num2 = num;
int* numPtr = (int*) chPtr;
int length = this.Length;
while (length > 2)
{
num = (((num << 5) + num) + (num >> 0x1b)) ^ numPtr[0];
num2 = (((num2 << 5) + num2) + (num2 >> 0x1b)) ^ numPtr[1];
numPtr += 2;
length -= 4;
}
if (length > 0)
{
num = (((num << 5) + num) + (num >> 0x1b)) ^ numPtr[0];
}
return (num + (num2 * 0x5d588b65));
}
}

总结
基于无序列表的顺序查找，基于有序数组的二分查找，平衡查找树，以及红黑树，本篇文章最后介绍了查找算法中的最后一类即符号表又称哈希表,并介绍了哈希函数以及处理哈希冲突的两种方法：拉链法和线性探测法。各种查找算法的最坏和平均条件下各种操作的时间复杂度如下图:

search method efficient conclusion

在实际编写代码中，如何选择合适的数据结构需要根据具体的数据规模，查找效率要求，时间和空间局限来做出合适的选择

目前,每到各种节假日和营销事件出现的时候,朋友圈会转发各种H5,比如2018年底的年终总结类的,其他时候各种测评类的,以及商家为营销做的各种趣味游戏类的.公司也做了大量的H5,累计了大量的数据,这些数据应该如何产生价值?

1.通过H5可以获得什么数据?

H5是移动互联网时代重要的传播形式,通过它,可以累计的足够多的数据(包括用户之间的阅读,分享,转发等).根据经验,我们不难得出下面的结论

• 根据用户之间的转发关系和分享链,可以发掘出每一场传播中的KOL是哪些人群;
• 根据每个H5的转发总量,可以知道信息最终传达到多少用户手中;
• 而根据不同时间段的阅读次数,可以得到用户使用移动设备的高低峰时间,从而指导我们在正确的时间去发送和传播内容;
• 分析用户的地区,设备品牌,型号,使用场景,用户性别等数据可以制订出更加精准的内容和营销策略,进一步提升效率….

2.关于数据可视化

目前开发人员经常接触和使用的一般是Echarts 和 highcharts 两款js插件,文档都比较齐全,使用比较方便.不仅能渲染柱状图,折线图.饼状图等基本图表,还可以渲染更高级的内容

echarts 和 highcharts 使用方法大同小异,都是在页面中引用库文件,同时提供对应格式的数据进行初始化并且执行渲染.

简单的使用例子:

<script src="https://cdn.bootcss.com/echarts/4.2.0-rc.2/echarts.min.js"></script>
    <div id="main" style="width:auto;height:300px;"></div>
    <script>
        {{--绘制图表,初始化数据--}}
        echarts.init(document.getElementById('main')).setOption({
            series: {
                type: 'pie',//选择类型
                data: [
                    {name: 'A', value: 1212},//提供数据
                    {name: 'B', value: 2323},
                    {name: 'C', value: 1919}
                ]
            }
        });
    </script>

而我们目前在项目中使用的基本是通过PHP查询数据表中数据,整理成如上述代码中的data参数所需要的格式,并且在整个个页面加载前就直接转换为json并直接在页面保存,供js使用

3.关于后台处理逻辑

目前H5统计项目原理:

(1).综合浏览趋势

综合浏览趋势数据主要为查询表中指定H5_id,且类型为浏览的结果,并根据时间进行分类,最终将结果返回页面

综合浏览趋势数据:

(2)综合传播渠道

综合传播渠道目前统计前5级(0~4)传播量,做了两个处理方案:
–1.前端处理,原链接URL不带有传播层级参数,用户主动浏览,属于第0级传播,请求接口时传参level=0;当用户进行分享时,检测当前链接中是否带有level参数(level在URL中混淆加密处理),若有则level+=1,否则level=1,以此类推,减轻服务器处理的压力;
–2.后端处理,每小时自动运行,后端对数据表中的分享记录进行递归处理,查询指定H5_id的记录,根据用户openid分组去重,和若没有父级节点,则当前传播为第0级传播,若有父级节点,则再查询相同H5_id且openid=父级节点的记录,以此类推,假如查询了三层父节点时停止,则表示当前传播为第3级….这种方式随着数据量的提升,运算规模会变为N的N次方的N次方…容易导致内存溢出,因此目前使用的是第一种方案

(3)综合分享去向

这里比较简单,根据分享类型查询数据,并且去重即可

(4)综合分享关系

原理类似综合传播渠道,查询的时候还带上了用户之间的分享关系,同时带上了用户性别,分享数量等数据,位于中心点的向四周发送数据的点表示分享者,分享线条越多,该用户越可能是KOL,是传播该H5的关键用户

(5)pv地域分布

此处的数据是根据页面请求分享记录接口时,服务到获取到的ip地址进行处理而得来的用户地域分布,使用了纯真ip地址库解析出物理位置,并且渲染数据而得来

(6)用户设备品牌

根据前端发送的user-agent信息匹配而来,目前识别的主流的手机品牌,其余未能识别的归入到其他品牌中

(7)用户性别分布

根据获取用户微信授权时拿到的基本数据得来

(8)用户设备操作系统和使用网络

获取方式同(6)

(9)关键传播用户

原理同传播渠道和分享关系类似,数据展示为表格化,包含用户基本信息和头像

4.关于对目前界面的优化建议

页面分页分部分处理;
H5pv/uv排行;
缺失数据的处理;
每一个H5统计中根据文章/H5的标签给KOL用户贴标签;