我写了一个 Alfred Workflow,用于新建和加入 Zoom 会议。
现在支持免费和付费帐号,如果没有登录也可以直接进入会议。

使用方法:
1、直接在 Alfred 里面粘贴 Zoom 的会议链接,按下回车就可以自动加入会议。如果 Zoom 还没有运行,也会自动运行起来。
2、 直接在 Alfred 里面粘贴 Zoom 的会议链接后,按下 Command 键会 新建一个会议,而不是加入现有的会议。并且会自动把新建的会议的 url 放入剪贴板,我们只要直接粘贴就可以。
3、有 `zm` 关键字,直接按下回车就是新建一个会议;
4、在 `zm` 关键字后面可以继续添加 meeting id,按下回车会自动加入;
5、在 `zm` 关键字后面无论是否有 meeting id,按下 Command 键都会新建一个会议。

源码:https://github.com/chaifeng/alfred-zoomus

下载:https://github.com/chaifeng/alfred-zoomus/releases

This Alfred Workflow is used to start or join a Zoom meeting.

Support free or paid account, you can join a meeting without logged in

Usage:

  1. Paste a Zoom meeting URL in Alfred directly, press Enter, this will join an existing meeting.
  2. Paste a Zoom meeting URL in Alfred, press Command + Enter, it will start a new meeting. And put the URL of this new meeting into your clipboard automatically.
  3. A new keyword “zm” is used to start a new meeting.
  4. Append an existing Zoom meeting ID after the keyword “zm”, it will join this meeting.
    for examples: zm 123-456-789, zm 123456789
  5. Whether or not there is a meeting ID after keyword zm,press Command + Enter will always start a new meeting.

Source code: https://github.com/chaifeng/alfred-zoomus

Download: https://github.com/chaifeng/alfred-zoomus/releases

在上世纪90年代的时候,PC 开始逐步走到我们的生活中。那时除了 PC 还有一个名词叫做 MPC,这是 Multimedia PC 的缩写,也就是『多媒体个人电脑』。

在当时,PC 给人的感觉是字符界面下的文字以及科学计算。虽然在 1995年的时候,Windows 95 已经发布。不过不要说播放视频了,就算听 MP3 都会卡顿。所以如果给一台 PC 添加了一个 CDROM、一个声霸卡以及用于解压电影的『硬解压卡』就可以让一台『普通』的 PC 做更多的多媒体的工作。于是就升级为『多媒体 PC』,也就是 MPC。在当时 MPC 还有级别之分,根据 CPU 的主频、内存、显卡支持的颜色数量等等指标来划分。

很快的,MPC 这个名字就淡出了我们的记忆。大概在1997、98年之后,已经很难看到这个名词了,因为那时的硬件性能遵循着摩尔定律在高速的发展中。已经无需添置硬解压卡就能看电影,CDROM 和声卡都已经成标配。现在对于一台 PC 可以做文字处理、科学计算、看电影、玩游戏、上网聊天就已经最为基本的功能了。PC 就是 PC!

从功能单一枯燥的 PC 和多媒体的 MPC,慢慢的,就只有了 PC。

而程序员这个职业,在以前就是程序员。当时,程序以单机或者客户端服务器端的为主,程序员要自己搞定客户端和服务端。除了开发,还要做程序的安装、系统的配置和调优。知道如何启用 386 增强模式,如何使用高位内存。不要说配置防火墙和路由器了,连网线都会做。当时的网线可能都是同轴电缆,而且必须接上终结头,否则网络都不通。所以,以前的程序员真的是要会修电脑,而且很多程序员都以此为乐趣。甚至还有朋友会找程序员修电视,因为电脑也有个显示屏,和电视都很像。连电脑这么高科技的都会修,电视还能不会修?

很快的,IT 就发展到我们的身边每一个角落了。软件的规模也越来越复杂,程序员的职业也越来越细分。有前端程序员有后端程序员,有做开发的有做测试的有做运维的。现在如果说自己是程序员,可能还要补充上自己是前端或者后端。而且还出现了程序员的鄙视链,C 程序员鄙视 Java 程序员,Java 程序员鄙视 PHP 程序员,搞开发的鄙视做测试的。

软件的规模越来越大、越来越复杂,但是程序员关注的范围却是越来越小。做前端的不懂后端,做后端的不了解前端。开发中的沟通成本和复杂就变得越来越高,随着互相的不了解,软件在集成的时候就特别容易出现问题,很多软件的缺陷就因此而产生。为了减少因为沟通和理解造成的软件缺陷,『全栈工程师』就出现了,虽然不要求你一定精通前端与后端的方方面面,但起码不会因此而出现沟通上的理解偏差。很多公司里面,全功能团队也在逐步的取代特性开发团队。

以前会修电脑会做客户端服务端会网络会调优的程序员,慢慢的变成了,只会开发前端和后端或者会开发的不会运维的程序员。而那种什么也会做的就是『全栈工程师』。

快捷办法就是直接找现成的:

  1. Opera Developer 最新版内置了 VPN,而且还是免费的。还支持选择不同地区的服务器,目前看来只有三个地区。下载 http://www.opera.com/developer,在2016年4月23日的最新版是 38.0.2205.0。
  2. 有个专用于外贸的 Chrome 修改版,貌似只有 Windows 版本,在 http://mychrome.cn
  3. 有个叫『灯笼』的软件,与洋葱不太一样,在 https://getlantern.org/
    1. 这是个开源的,如果无法下载就去官方仓库看看 https://github.com/getlantern/lantern-binaries
    2. 在官方仓库还有一些好用的地址 https://github.com/getlantern/mirror
      1. 提醒一下,每隔5分钟,这个页面上的链接都会被更新。
      2. 如果这个页面无法访问,我们可以注册一个用于收藏文章的服务,可以通过邮箱把目标页面的地址发过去,然后你就看到页面上的内容了。比如 How to save to Pocket via email
    3. 这个也有安卓的版本
    4. 还附带了一个上国外微博的 https://firetweet.io/
  4. 注意以下几点
    1. 建议通过官方链接下载,我们无法保证从第三方下载的会不会被修改过
    2. 并且确认是 https 协议
    3. 而且浏览器没有提示证书问题

购买现成的 VPN、代理等服务不是说不行,只是有点鱼龙混杂。我相信,有很多是不太安全的,还是建议自己购买 VPS 搭建一个。

而且购买 VPS 也不是很贵,一年3百多人民币可以搞定,有的 VPN 服务商的价格也超过一个便宜的 VPS 了。当然了,这些服务商会很专业,有多地的服务器可供你选择。

19. March 2014 · Write a comment · Categories: 技术文章 · Tags:

3月9日星期天举行了太原 QClub 社区在2014年的第一次活动,这次是在太原理工大学迎西校区的学术交流中心,所以活动现场的学生就占了绝大多数。大概到场人数有50人,除了工大的同学之外,还有一些职业程序员。我们还准备了5本签名版的《MacTalk:人生元编程》作为小礼品。

这次的活动主题是聊一聊2014年我们程序员该关注哪些技术,考虑到同学们估计比较多,所以还有一个面向同学们的话题是雷晓宝分享的《大学计算机课程与实践》。首先是我分享了一个云计算的普及话题,IaaS、PaaS、SaaS 分别为我们解决了什么问题?很多同学都认为云计算就是一堆虚拟机,也确实没错,绝大多数的云计算都有虚拟化的应用。而且虚拟化也确实是云计算中一个重要的技术,但仅仅虚拟化是不够的,用虚拟机代替物理机也不是云计算的全部。这些名词或技术的出现,一定是为我们解决了某一方面的问题。然后我用了一些比喻和例子给同学们分享了一下这三个名词分别做了什么。随后就是雷晓宝同学的《大学计算机课程与实践》的话题了,在这个话题中晓宝分享了计算机专业的一些理论课程分别对应在平时实际使用的哪些技术上,也提到了 IT 行业中不同的工作需要侧重哪些不同的技术。这个话题其实是比较大的,而且内容也很多,足足分享了一个多小时。最后就是解读 ThoughtWorks 的 2014 年第一季度技术雷达,TW 的技术雷达可以说是 IT 行业的风向标。因为涉及的内容非常多,所以我们精选了一些比较有趣的内容。比如移动设备的持续交付、客户机和服务器使用相同的代码(我们在去年的一次活动上就是一起写代码研究这个技术)、云开发环境、JavaScript 的依赖管理、Docker、Clojure、CoffeeScript、等等。活动的过程中,有5位同学与我们的讲师互动,幸运的获得《MacTalk:人生元编程》,在 5点半的时候结束当天的活动。最后我们还和几位热心的同学一起聚餐,又聊到晚上8点多。

话不多说,上图:

在前几天刚刚闭幕的 QCon 北京大会最后一天下午,有几场小型的演讲。其中,国内知名的安全专家、微信“道哥的黑板报”的作者道哥就分享了一个有关黑客的话题,现场观众们不时的发出一阵阵的惊呼。关于安全呢,我也不算是小白。在大学以及刚毕业两三年的时候,对安全领域还是很关心的,也见到并认识了不少国内安全领域的朋友们。随着在二线城市苦逼的 Java 码农日子一天天的混下去,我已经渐渐远离这一领域,但是很多安全的习惯还基本保留着。

道哥在 QCon 上就说到,他的电脑一直就是裸奔的,也就是没有安装任何的安全防护软件。我在 06 年之前主要使用 Windows XP,就是裸奔的。一是因为机器配置低;二是也没啥必要;三是 Linux 内核与笔记本上的某个芯片组不太兼容,会时不时的死机。07年之后,我就全面切换到 Linux 下工作和娱乐,这就更是裸奔了。在 2010 年的 QCon 北京大会的某一天晚餐后,我遇见了国内技术领域的大牛周爱民,我们相谈甚欢,和大众点评、百姓网的几位朋友一直聊到凌晨2点。那个晚上我就提到了平时我是怎样注重网络安全和隐私的,记得当时他们用“变态”一词来形容我。

又回到今年 QCon 闭幕的第二天,我在地铁上犯了安全大忌,连接了一个未知的 WiFi,并发了一条微博。很快大连的谊昌老兄就立刻回复我说“看了昨天道哥的演讲后,俺决定再也不连自己不清楚的wifi了~”,这个我得承认,当时没有开启 VPN。虽然这个 WiFi 的名称是 “AndroidAP”,但是不能保证这是一个普通的 Android 手机。

说了这么多,想必很多人已经知道不能随便连接免费的 WiFi,但是他们却很放心的连接酒店里提供的网络。事实上,免费的 WiFi 背后不一定都是坏人,但是国内酒店网络的背后则一定是不安全的,泄露自己的隐私的几率一定是 100%,你的一举一动都在老大哥的眼皮底下。

回到酒店后,我决定把酒店网络背后的东西拿出来给大家看看。这里就不讨论如何入侵酒店的网络和后台,只给大家看看背后的这一个管理平台。

正题开始……

酒店里上网可能会需要密码,就在这里设定的。当时我入住的就是 2111 这个房间,第一个密码显然是前一个入住客人的,酒店前台没有删除。第二个密码是在我办理入住的时候设定的,但是我一直没有使用过。

20130430161855

 

还能看到 IP 地址与个人的关系。

20130430164951

 

在这里还能获取到入住客人的身份证信息,省略省略

20130430162203

 

一旦你连入酒店网络,你的哪些隐私会被泄露呢?哇哦,有个用户上网日志查询,就是这里,但是还需要一个密码。这个密码应该是给平平和安安用的,要不酒店的前台就能随便看了。而且这个密码或许是个比较复杂的,md5 的哈希值是 47e57be0904ce7174115a08cb1a1e304,我用几个在线的 md5 数据库都没有查到对应的明文,如果有查到的朋友还望不吝告知。大家看到这里不要失望,跳过去也是很容易的,略过不表,且看下文。

20130430201827

 

输入了查询密码后就能查询用户上网日志了,看看吧,会不会让你的后背发凉?搞不明白的是,为啥还要监控这几个游戏呢?

20130430163934

 

 

给大家看看 MSN 的日志,查询了最近三天的记录,只有一条。结合前面的用户管理功能,我很容易知道这个 MSN 的主人是谁。

20130430164333

 

哈哈,肯定有人迫不及待的想知道 QQ 的搜索结果,给大家看两条,关键字2那里就是 QQ 号码。同理,结合房间号,嗯嗯,哈哈。

20130430164645

 

还有网站浏览记录,这里只记录了域名,显然酒店员工黑夜就是去youku看看视频。

20130430203804

 

看看电子邮件的记录,2221 这个客房的客人真是发了好多啊,应该是给公司同事群发的。

20130430203144

 

FTP 的日志,关键字1就是 IP,关键字2就是用户名

20130430203503

 

还有个系统用户日志查询,记录的还挺详细。

20130430202922

 

20130430202650

 

管理界面里还有系统设置,我们再去看看。有个 VIP 主机的设置,应该就是设置不纳入计费范围的,反正我是把自己电脑的 MAC 地址填入这里,就直接上网了,当然了,这个 MAC 地址是伪造的啦。再没有弹出需要密码的页面,至于监控与否就不清楚了。

20130430165554

 

 

这里可以设置哪些 IP 段需要认证,我把起始IP修改到了 192.168.50.3,把自己电脑的 IP 设置为 192.168.50.2,好像是不能上网的。

20130430165956

 

 

有一个关键的设置,一定是大家很感兴趣的,就是这些信息被传送到什么地方呢?答案就在这里,有兴趣的朋友可以去研究研究哈。

20130430170257

 

呸,网络神探

20130430170815

 

还有一个设置应该是配合网络神探使用的,估计要是我修改了这里的设置,我用自己的电脑就能监控整个酒店的网络了,嗯,或许吧。

20130430204216

 

大家可能感兴趣的内容大概就这些吧,记住了,在酒店上网一定要开启 VPN。建议使用 OpenVPN,如果 OpenVPN 的服务器端口是 80 就更好了。

强烈建议大家禁止系统中的 CNNIC 的根证书,在酒店的这个网络环境中,很容易实现中间人攻击。

另外,酒店应该不会记录很详细的网络内容,因为这个会占用大量的存储空间,除非触发了敏感词。平平和安安要求保留至少90天的记录,如果记录下详细的内容,可能会占用大量的存储空间。

 

Dreamhost 的空间就要到期了,实在无法忍受在中国访问的龟速了。

昨天正式迁移到 Linode 东京机房,速度那叫一个爽,基本上带宽全占满。

前天是女性朋友的节日,大早上的写了一个段子,昨天竟然发现上了新浪微博的热门,Cooooool。

兜兜的照片也好久不放了,很纠结,担心万一被坏人利用把我家兜兜给骗走。

这一次的 QClub 活动是我的老东家山西鑫慧林赞助的,本来打算邀请两位讲师,后来一位来自北京的讲师因为时间和行程问题,最终只邀请到 Tinyfool 一人。不过 Tinyfool 还是很给力的,一口气说了一个半小时,最后意犹未尽的结束演讲。微博上也有朋友戏言,太原一时伞贵啊 http://weibo.com/1400229064/z1najn7yL

这次活动到场将近40人,其中有几位山大的学生,当然还是出现了一些新面孔。本来预定的是一楼的100人会场,但是因为会场工作人员的失误,让我们和另外一个会议冲突了,于是就把我们安排在三楼的大会议室,结果诺大的会议室坐着3、40人显得空空荡荡。在照片中看到人不多,细数下来也将近40人。

Tinyfool 演讲完毕后,赞助商买了不少的啤酒,给 Tinyfool 单独准备了一瓶竹叶青。大家一起喝酒聊天,聊的是不亦乐乎。

Tinyfool 的微博上也分享了他的首次太原之旅 http://weibo.com/1400229064/z1Z5lykVU

 

把基本情况先简述一下,首先是周六太原大雨,影响了到场率,不过还是有将近40人,而且还看到一些新面孔。其次是两位讲师的话题都很给力,演讲都超时,而且QA环节大家都很踊跃的提问。郭振的话题用了1个半小时才结束,张龙的话题更是达到了2个小时。最后5点50结束本次活动。

以下文绉绉的总结出自专业编辑李洋之手:

7月21日,QClub太原站如期在山西出版传媒集团一楼会议室举行,这已经是QClub第三次来到太原举行活动。今天的龙城太原下起雨来,这给炎炎夏季带来了丝丝凉意;而这场期盼已久的QClub技术社区活动对于技术相对滞后的太原地区而言,也是如同久旱逢甘霖一般及时与酣畅。此次活动中,增添了很多新的面孔,他们为QClub太原站社区活动添加了新的血液与活力。

大雨并没有浇灭前来参加活动人们的热情,在不小的会议室当中坐得是满满当当。技术开发人员也都希望在这场难得的“Android应用开发”的主题讲座中汲取自己所需要的养分并希望借此来解决在工作中所遇到的实际问题。好了,我们现在直入主题,看看讲师们今天会给我们分享那些先进理念与经验以及会带给我们哪些意想不到的惊喜!

首先是来自盛大创新院的高级研究员、乐众ROM项目组总架构师郭振分享的 Android 备份框架的架构与设计,以及如何将自己的服务集成到 Android 系统中。此次活动有一点明显地改善就是参与者的积极性与主动性较前两次有了显著地提高。在互动环节当中,参与者与讲师之间的交流更加自然,提问也是更加踊跃,奖品更是抢手……

接下来是联想集团全球应用开发部的高级工程师、InfoQ翻译团队编辑张龙分享的Android跨进程通信机制与AIDL,介绍了Activity与Service之间的通信原理。张龙这个名字,大家一定不陌生,这已经是第二次来到太原与大家分享经验,算是QClub太原站的老朋友了。大家对于张龙刚刚翻译出版的《Android Web应用高级编程》这本书产生了浓厚的兴趣,这本书涉及到一些跨平台移动开发技术的内容。这本书也是作为活动中的奖品来发放,在互动过程中大家的热情都很高涨,很想要获得这本精美IT图书,因此互动问答过程就格外积极与踊跃!

这已经是山西书海数字网络传媒科技有限责任公司第三次成功举办QClub太原站活动了,书海传媒对于推动太原地区IT技术交流,应该说是功不可没。最后,我们还是要再次感谢QClub太原站活动的本地赞助商——书海传媒的鼎力支持。

from 2002-06-14

 

17. May 2012 · Write a comment · Categories: 技术文章 · Tags:

(Source: http://sw1nn.com/blog/2012/04/11/clojure-stm-what-why-how/

Clojure 有很多功能可以帮助在程序中处理并发问题。本文将关注软件事务内存(Software Transactional Memory,缩写 STM),不过这些并发问题的共性都是由多个部分共同运行来得以解决,因此我们期待一些其他思想的渗入……

STM 是什么?

软件事务内存 (STM) 是一种模拟数据库事务的并发控制机制来控制在并行计算时对共享内存的访问控制。它是锁的一种替代机制。

维基百科 – http://zh.wikipedia.org/wiki/软件事务内存

STM 允许在内存中更新多个数据,这些变更对于其他同时在执行相同逻辑的线程来说,显而易见是原子性的。类似数据库中的事务,如果因为某些原因有些更新没有完成,然后就会取消所有更新操作。

一个典型例子就是银行的交易 – 你希望把你的账户中的一些钱转账到我的账户……,我们将使用这个作为我们的例子,因为从概念上来说大家都熟悉。

目前在计算机科学中,STM 的实现还不是一个已经解决的问题,正在进行的研究是怎样更好的完成它。Clojure 选择了一个基于多版本并发控制(MVCC)的方法,MVCC在一个事务中维护多个(逻辑)版本数据的引用。在你的事务执行过程中,你看到的是一份数据的快照,与事务开始时看到的数据是一样的。当你认为在Clojure中普遍使用持久性数据完成你的很多事情,而不需要做太多额外的工作时,MVCC就是一个显而易见的选择。

为什么我们需要 STM?

STM 的核心是 ref 和 dosync,让我们看一个例子……

(def account1 (ref 100))
(def account2 (ref 0))

; to read the current value of a ref, use (deref refname):
;=> (deref account1)
100
;=> @account1 ; @refname is equivalent to (deref refname)
100

(defn transfer [amount from to]
    (dosync
       (alter from - amount)   ; alter from => (- @from amount)
       (alter to   + amount))) ; alter to   => (+ @to amount)

;=> @account1
100
;=> @account2
0
;=> (transfer 100 account1 account2)
100
;=> @account1
0
;=> @account2
100

你们看到我们在这里定义了两个账户,第一个账户 account1 初始化了 100。(transfer) 函数接收一个数量参数amount,一个来源账户 from 和一个目标账户 to,然后使用 alter 修改两个账户,从 from 账户中减去 amount 的数量,添加同样的 amount 数量给 to 账户。这段代码运行在一个单线程中,但是考虑一下,如果还有一个线程在两个 alter 语句之间运行,修改了两个账户中的值,这会发生什么呢?如果没有 STM 的保护,就很容易丢掉其中一个或者两个账户的变更。

另外一个例子;假设在一天结束时,银行希望给所有账户生成一份结算报表。可能这份报表需要很长时间的运行,但是在报表的生成过程中,依然可以对账户交易,并且为了报表目的,我们应该看到的是一致的数据视图。

在 Clojure 中 STM 是怎样工作的

看下面的这张图,你会看到粉色盒子中的三个事务,你也会看到最左边一列中ref值的不同版本。当一个事务通过 (dosync) 开始后,就会获取到ref的版本。获取到的值是在事务执行过程中 (deref) 返回的值(也就是说在事务中读取的ref都是不变的)。

让我们看看最左面的两个事务,两个事务同时开始,同时获取到了相同的 ref 值,因此两个获得的都是 ref 版本为 0 的一份副本。在事务中会执行一些操作,ref 的值将会被更新。第一个(最左面)的事务首先结束,所以赢得了比赛,把 ref 更新为新值。当第二个事务结束时,它尝试写入它的值,但是写失败了(图例中的红色箭头),因为 ref 的版本不是预期的。在这个例子中,事务就重新执行了。注意当事务重新执行时,它首先获得了 ref 新版本的副本,也就是看到的是第一个事务中变更后的值。然后由于没有其他事务尝试更新 ref,这次第二个事务就完成了。

你也看到这一切在进行的同时,第三个事务一直在运行,但是事务的处理过程中没有更新 ref 的值,所以不需要重试事务操作,事务运行完成。

如果保存在 ref 中的值是持久化的数据结构,在内存中保存这些数据结构的多个逻辑版本是很有效率的,因为这些数据结构会共享内部结构。当然,也会使用额外的资源,在一些场景中可能也会出现问题。当定义 ref 时,你还有一些选项来决定在运行时如何管理这些 ref 的历史(也就是上面讨论的这些版本数字)。

; pre-allocate history and limit max-history
(def myref (ref 1 :min-history 5 :max-history: 10))

; supply a function to validate the ref before commit.
(def myvalidref (ref 1 :validator pos?))

这个可以让你通过使用预分配和限制历史资源的使用,来提高在读取-失败中的边界效率。

宽松的一致性和副作用

在一些并发的事例中,你可以放宽松一点,以获得一些的效率。举个例子,假设你要保留一天的交易日志。如果你知道最后的交易结果始终是正确的,你可能就不大关心这些交易的顺序。说实在的,如果你收到两笔分别是 ¥100和¥50的存款,你可能就不在乎它们是被记录为¥100然后¥50,还是¥50然后¥100。存款的两个事务是可交换的,Clojure 也提供了一个并发操作 (commute) 来完成这样的事情……

(defn log-deposit [account amount]
     (dosync
        (println "Depositing $" amount " into account, balance now: "
            (commute account + amount))))

(def myaccount (ref 0))

(log-deposit myaccount 100)
(log-deposit myaccount 50)

; (as good as) equivalent to 

(log-deposit myaccount 50)
(log-deposit myaccount 100)

需要注意 (commute) 的是,当函数调用时,它设置了ref在事务中的值,但是在提交的时候才会真正的做出修改,是通过再次运行传入给 commute 的函数和最新的 ref 值。 这意味着在你的事务中你计算的值可能不是最终提交给 ref 的值。这需要考虑的认真点,你要确保你的操作过程中不依赖最新的 ref 值。

最后,你可能会疑惑上面例子中的 (println),在事务重试的事件中会产生什么副作用呢?会发生一个很简单的副作用。对于上面的例子,这个可能是个不太重要的事情,就是日志将会不一致,但是数据的真实来源将会是正确的。

Clojure 也提供了一个宏,也就是 io!,这个允许你把代码标记为不允许运行在一个事务中。你可以用这个来保护你自己无意中在一个事务里面调用了有副作用的代码。

例如:

(defn log [s]
   (io!
      (println s)))

(log "Hello World") ; succeeds

(dosync (log "Hello World!")) ; throws IllegalStateException

要正确的在一个事务内部完成 IO,你最好从事务内部把消息扔给Agent,Clojure 中的 Agent 是和 STM 整合在一起的,这样当事务成功时就会发送消息,如果事务失败就会被丢弃。