如何组织一场技术沙龙?

从去年到现在,我参加了几次技术沙龙。其中有组织的很好的,也有不尽如人意的。在这篇文章里,我以举办一次Go语言话题分享为例,谈谈我个人觉得该如何办好一场技术沙龙。

(1)组织

首先说一下沙龙的组织者与参与者之间沟通形式的问题。现在是信息高度发达的互联网时代,对于组织者来说,不仅有像meetup这样专门发布聚会信息的网站,还有各种IM群来让大家讨论,献计献策。而在试用过这些五花八门的工具后,我个人倒是觉得,古老的邮件列表可能是最好的联系方式。原因有以下两点:

a)你现在所使用的IM工具也许在某一天会消失,但是电子邮件不会,它依然是现在世界范围内最广泛使用的沟通工具;
b)邮件列表可以很好地把信息和资料保存起来,方便将来查找。

选好沟通工具后,组织者就可以向大家征集与会议题并展开讨论了。同时组织者还要联系场地和赞助,比如说可以提供一些抽奖奖品或是纪念品等等。这些纪念品不用价值很昂贵,个人觉得一个马克杯,一件T恤,或是一个普通笔记本就可以了。此外,对提供场地和赞助的公司或个人,也可以在沙龙上进行一下适度的宣传或广告。毕竟人家提供了帮助,这样也可以提高赞助者们未来提供更多帮助的积极性。

接下来说一下时间的问题。举办一次沙龙还是比较耗费时间和精力的,所以2~3个月一次就可以了。举办时间最好安排在周六的下午,这样可以方便喜欢周末睡懒觉的朋友。选择周六另外一个原因是:第二天是周日,仍然休息,所以即使这一天弄得太晚,也不用担心明天早起上班。

(2)选题

一般的技术沙龙会安排3~4个小时,而这还包含参与者提问和中间休息的时间,所以我觉得安排4个选题就够了。

第一个选题是“暖场”作用,不一定非要技术相关。可以讲讲Go语言社区这段时间的动态,一些轶闻趣事等等,目的是把大家的兴趣和积极性调动起来。

第二、三个选题应该是和Go语言技术紧密相关的了,可以介绍Go语言的使用技巧和调试方法,当前有哪些比较好的Go语言开源项目,以及各个公司使用Go语言的经验分享等等。

最后一个选题可以是其它技术的话题分享:因为Go语言不是孤立的,而是和它运行的环境紧密结合的,所以可以讲讲Unix系统的知识,运维经验的分享等等。

(3)扫尾

开完沙龙后,大家要帮忙把会场打扫干净,这样将来赞助方才更愿意提供场地设施。组织者也要把一些资料及时地发出来,方便大家参考。

以上就是我个人对如何组织一场技术沙龙的一点拙见,希望能给大家一点帮助。

“Understanding Caching”笔记

本文是“Understanding Caching”的笔记:

(1)什么是cache line

A cache line is the smallest unit of memory that can be transferred to or from a cache. The essential elements that quantify a cache are called the read and write line widths. These signify the minimum amount of data the cache must read or write from the memory or cache below it. Frequently, these quantities are the same, so caches often are quantified simply by the line width. Even if they differ, the longest width usually is called the line width.

(2)inclusiveexclusive

A multilevel cache can be either inclusive or exclusive. Exclusive means a particular cache line may be present in exactly one of the cache levels and no more than one. Inclusive means the line may be present simultaneously in more than one level of cache. Nothing prevents the line widths from being different in differing cache levels.

(3)Write throughwrite back

Write through means the cache may store a copy of the data, but the write must be completed at the next level down before it can be signaled as complete to the layer above. Write back means a write may be considered complete as soon as the data is stored in the cache. For a write back cache, as long as the written data is not transmitted, the cache line is considered dirty, because it ultimately must be written out to the level below.

(4)Coherency

A cache line is termed coherent when the data in the line is identical to the data stored in the main memory being cached. If this is not true, the cache line is termed incoherent.

没有coherency带来的两个问题:
a)所有种类cache都有可能发生(stale data):主存数据更新了,但是cache数据不是最新的。因此会导致读错误。如下图所示:

7105f1.inline

这是一个暂时的错误,因为正确的数据在主存中,只需cache重新读一下即可。

b)这种错误只发生在write back cache中:主存和cache里分别更新了数据,现在要使二者数据一致。由于每次cache要更新一个cache line,所以必然要导致更新的数据出现不一致。如下图所示:

7105f2.inline

Libuv笔记(1)—— 模型

Libuv使用的是异步的(asynchronous),非阻塞(non-blocking),事件驱动的(event-driven)编程模式。它的核心是提供了一个事件循环(event loop),并对感兴趣的事件注册了回调函数(callback)。伪代码如下:

当有事件需要处理:
    取出下一个事件
    如果这个事件注册了回调函数:
        调用回调函数