程序员能力矩阵

为了团队技术发展,画个RoadMap总是必要的。一年多前看到这篇,今天得空翻译整理一下。分享之~

0

Rails太重?这要辩证的看

说Ruby,如果没有带上on Rails,总觉的缺点什么。或许从侧面说明了rails对于ruby的重要。

几乎从来没有见过哪个框架在某个语言有rails这样的统治地位。通常认为“垄断”不好,但rails的垄断地位是自己争来的,如果没有持续活跃和专业的社区,没有出色的发行版,rails不可能这么受欢迎。

最常听到对rails的抱怨是性能上的,内存占用问题,多线程问题,加载了太多的组件,真的是这样么?

Ruby是解释语言,很占内存?

某种意义上,是的。解释性语言通常比编译语言更占内存。但使用解释性语言就是因为它的轻便灵活。Ruby的内存机制亦非常重视这一点。因此,评价Ruby的内存状况和使用的vm关系极大。

如果简单点说,Ruby 1.8 以前版本内存消耗严重,非RubyEE几乎是不能用于生产环境的。1.9.3 以后版本对内存管理有非常好的优化,直观上占用可降低50%以上,甚至胜过号称超过MRI30%的RubyEE。 http://nerds.airbnb.com/upgrading-from-ree-187-to-ruby-193/

具体的比较在这里: http://blog.pothoven.net/2012/10/ruby-187-vs-193-performance.html

Rails加载了太多东西,很慢?

Rails是加载了不少东西,但是其一:其对性能影响对于访问量有限的网站并不显著;其二,可以定制加载,去掉不用的组件,比如使用MongoDB,就可以完全移除ActiveRecord,这并不是什么太麻烦的事情。

Rails不适合做Mobile Web?

No, No Rails或许不如Sinatra适合API型的应用,但对于Mobile,本身也是Web,确实没有什么水土不符的。如果觉得访问缓慢,或许应该考虑更多是代码逻辑或者部署配置。如果应用没有用到任何缓存,每次都调用几十次查询,那么用C也救不了。

应用开发者或许更了解操作系统和代码逻辑,对Web优化了解很少。Rails提供了不少工具,好好读读Rails Guide中assets和cache相关章节,会收益良多。

Rails做了很多,其中大多数是有用的

Rails已经不仅仅是Ruby一家的框架了。它几乎可以无代价的集成coffeescript, haml, less, sass… 这个列表可以无限制的列下去,甚至你自己的DSL也可以。

Rails 3 开始加入的assets pipe 绝对是神作,前端优化变成了傻瓜式操作。coffeescript作为去年发展最快的奇迹性语言,终于让javascript不那么笨了。haml节省了50%的HTML代码,优雅而简单。

如果不是rails,可能其中的一些不会那么快的推广普及。作为最有活力的社区之一,rails非常开放,能够快速接受新技术。

最重要的是:做出产品,而不是纠结每秒多处理几次请求

Rails成为创业公司最爱是有原因的,对于创业公司,执行力是最值钱的。

云时代,添置硬件就能解决的吞吐问题,在开始阶段都不是问题。为了提升一倍性能,花数月研究测试框架组件,给自己挖坑,还是每月多花几百块添多一台服务器?这应该是很简单的问题。

0

国内社会化评论(类DISQUS)插件哪个好?

社会话评论插件,让博客/网站轻松接入SNS。 神马微博开心人人豆瓣空间微信,流水的APP铁打的PR,互联网说到底是媒体,技术的目的只是尽可能降低渠道成本。

说太远,那么,disqus类插件,国内哪个好用呢?

这篇文章写于2013年12月,经过一段时间的使用,可以负责任的说:多说最新版本1.1

比较对象: 多说,友言,畅言,灯鹭,比较主题: 安装体验 使用体验 SEO优化

f04

安装体验

这几个产品都有标准Wordpress插件提供,自定义也只需要简单放入JS代码。注册账号后即可使用。

重点提出批评的是灯鹭,完全程序员风格。虽然我是程序员,但我已经受不了其文档和安装步骤的晦涩难懂了。 另外插件质量也是几个中最差的。

使用体验

说道插件质量,畅言的体验是最好的,但是功能就简单了点。

多说和友言相比,多说的配置等功能更多点,易用性也比较好。

所有这些产品都具有基本功能—微博等工具转发,自动发文,使用时多数功能体验良好。

多说比竞争对手现代一点,开源了主题模板,让自定义主题显得比较容易。

评论框体验上,友言对URL判断比较不智能,随便加个参数,比如url?subkey=xxxx 就认为另外一个页面了。对比多说的控件体验就差很多。因为有些APP,比如微信,会自动改变URL,多带几个参数过来。

API方面,导入导出,用户信息等各有千秋。 灯鹭最强,畅言和多说次之,友言弱一些。虽然数据很重要,但如果没有足够多资源开发,也不用太斤斤计较,能够导出迁移就足够了。

SEO优化

多说的WORDPRESS插件可对爬虫显示静态内容。 灯鹭似乎也有类似功能。其他的不太确定

把评论内容静态显示对SEO优化是很有好处的,特别是对于评论多的网站。

综合

作为drop-in的解决方案,多说是最佳选择。畅言似乎很有希望,但短时间来看功能不足。

友言令人非常奇怪,有很好的首发位置,但目前实在让人惋惜。至于灯鹭,实在是需要反省,到底打算做成什么。

更多的参考

1

多说两句图片验证码

早上看神经网络的材料,遇到了个有意思的演示,于是发了微博,at了 @程序员的那些事 然后小火了一下,人民群众纷纷表示:

  1. 示例太简单了,不能体现现有技术;
  2. 字符识别不难,分区比较难;
  3. 现在的验证码人都认不出来,还机器呢……

这按顺序一看有意思,1被2推翻了,示例是简单,但对各种变体的识别也没有那么复杂;

至于2,在某种意义上被3推翻了,根据传闻,对微软Live Mail验证码的分区成功90%,总体破解超过60%。

关于3,就不引用传闻机器算法的识别率比人高;但是,大家有木有被轻微花眼的老爸老妈叫去输验证码的经历,我是经常啊,而且现在很多验证码自己都要输几次,严重怀疑是不是眼睛也快挂了。至于逆天的中文验证码,特别是还没有规律的,输不了词组,那是要敲键盘多少次啊!

更糟糕的是,图片验证码越来越复杂,用户体验越来越糟糕;

Paybal安全官预言靠密码的身份验证要消失,个人看来,图片验证码应该消失的更快。

再说说那个关于用户真实需求的笑话:

某富翁想要娶老婆,有三个人选,富翁给了三个女孩各一千元,请她们把房间装满。
第一个女孩买了很多棉花,装满房间的1/2。
第二个女孩买了很多气球,装满房间3/4。第三个女孩买了蜡烛,让光线充满房间。
最终,富翁选了胸部最大的那个。 

图片验证码应用的常见场景是:防止暴力破解 和 防止恶意注册。为此带来的用户利益/用户成本如果到了不合理的地步,就没有必要存在了。

原本是一时好玩POST的微博,大家讨论一下,忽然觉得应该认真点讨论下这个问题,个人看法,欢迎指正。

退一步看图片验证码

图片验证码,作为差不多最早和最简单易行的CAPTCHA,被广泛采用。

CAPTCHAs Completely Automated Public Turing test to tell Computers and Humans Apart

全自动区分计算机和人类的图灵测试这个问题可以由计算机生成并评判,但是必须只有人类才能解答。或许人可以问出只有人类能够回答的问题,但让计算机问出只有人类能回答的问题?木有能力证明,直觉有点不靠谱。

绝对做不到,相对做到也很有用。怎样才能让问题更适合人而不是机器,就能更适合我们的应用场景。

机器比较难以处理什么:演绎、规划、知识表达,学习、知觉、创造等等。 这些领域了解有限,Google的猫的科学家们或许能够解释更多。

图片验证码基本上可以归为知觉部分,随着技术的进步,越来越依赖更复杂更大信息量的感知,机器处理难了,人处理也难了。

能不能换个办法

改进方案是很多的,有些效果还不错,引用一个介绍:替代验证的六种办法

其中几个感觉比较典型和有意思的分析一下:

技能测试

数学题

解个微分方程 这个例子极端了点,不过常见简单运算的还是人人都可以的。类似的还可以问same这个单词的第一个字母是啥。 这个方法使用了知识表达演绎能力,如果做成图片方式,则更加安全且易于使用。

简单任务

enter image description here

井字游戏 和解方程原理差不多,不过有趣很多。困难的是,或许有的人真的不会…… 应用了感知知识表达演绎

第三方认证

这是回避问题,不过如果没有足够的资源实现安全的方式,通过第三方是个解决防止暴力破解,转移责任的好方法。

什么都不做

是的,用户什么都不做。但后台要做的更多。

可以根据行为:是否重复尝试?

根据上下文:是否先访问了登录页,再输入账户密码?是否有先阅读用户须知,再注册?

根据内容:类似Akismet阻止垃圾评论的方式。

这些方法,通过实时欺诈检测手段,在基本不影响用户的基础上实现保护。

后记

抛砖引玉,期待指正。

5

Redmine Linux下 PDF 和 PNG 中文问题

Redmine使用了RMagick来处理图片,fpdf处理PDF,并在调用时设定了字体

PDF中文字体

Redmine 中关于PDF字体设置的代码

          case pdf_encoding
          when 'UTF-8'   
            @font_for_content = 'FreeSans'  
            @font_for_footer  = 'FreeSans'  
          when 'CP949'   
            extend(PDF_Korean)              
            AddUHCFont() 
            @font_for_content = 'UHC'       
            @font_for_footer  = 'UHC'       
          when 'CP932', 'SJIS', 'SHIFT_JIS'
            extend(PDF_Japanese)            
            AddSJISFont()
            @font_for_content = 'SJIS'      
            @font_for_footer  = 'SJIS'      
          when 'GB18030' 
            extend(PDF_Chinese)             
            AddGBFont()  
            @font_for_content = 'GB'        
            @font_for_footer  = 'GB'        
          when 'BIG5'    
            extend(PDF_Chinese)             
            AddBig5Font()
            @font_for_content = 'Big5'      
            @font_for_footer  = 'Big5'      
          else
            @font_for_content = 'Arial'     
            @font_for_footer  = 'Helvetica' 
          end

在中文时,Redmine 使用了GB字体,在debian or Ubuntu系统中,可使用APT安装

apt-get install ttf-arphic-bkai00mp ttf-arphic-bsmi00lp ttf-arphic-gbsn00lp ttf-arphic-gbsn00lp

参考 Chinese Debian Mini Howto

图片中文问题(PNG)

图片中文也是类似的原理,下面是Redmine config/configuration.yml 中的内容

# This setting is not necessary in non CJK.                                                                                            
#
# Examples for Japanese: 
#   Windows:             
#     rmagick_font_path: C:\windows\fonts\msgothic.ttc                                                                                 
#   Linux:               
#     rmagick_font_path: /usr/share/fonts/ipa-mincho/ipam.ttf                                                                          
#
rmagick_font_path:  

修改这段代码,设定适当的中文字体路径即可,如:

rmagick_font_path: /usr/share/fonts/truetype/arphic/gbsn00lp.ttf

重新启动服务器,现在中文导出应当正常了。

本文使用的Redmine版本为 2.2.3

0

Xtext – eclipse DSL 编辑器

如果只说是一个DSL(Domain Specific Language)编辑器,感觉是有点委屈它了,这基本上是个语言设计器。

包含了解析,链接,编译,解释等全套的语言工具,除此之外,还有如下特色功能:

  1. 语法高亮
  2. 上下文辅助
  3. 校验及快速更正建议
  4. 整合Java

N图胜千言

1

Familiar 朋友们的照片墙

聚会想发照片?传到微博上?

不但很快就被别的微博刷没了,照片这种东西,还需要一点点隐私控制。

Familiar,对于国内用户来讲,套用妹纸的话,就是照片版的朋友圈。

配有iOS, Andorid, PC, Mac等全系列版本,对平板的支持也很好。

当然作为这个时代的应用,社交网络是不能少的,虽然必然主要是F和T两家……

各种屏保动画很完整,还可以互相评论,有兴趣就来尝试吧。

unnamed6a015436ecdafc970c017744518c8b970d-500wi

 

0

Hadoop Family Related Project

全文摘选自 Alex Holmes 《Hadoop in Practice》,关于 Flume, Sqoop, Oozie, Hive, HBase, Avro, Thrift, Pig, R, Mahout 等流行组件的概括描述。

A.2. Flume

Flume is a log collection and distribution system that can transport log files across a large number of hosts into HDFS. It’s an Apache project in incubator status, originally developed and currently maintained and supported by Cloudera.

A.3. Oozie

Oozie is an Apache project which started life inside Yahoo. It’s a Hadoop workflow engine that manages data processing activities.

A.4. Sqoop

Sqoop is a tool for importing data from relational databases into Hadoop, and vice versa. It can support any JDBC-compliant database, and also has native 

connectorsfor efficient data transport to and from mySQL and PostgreSQL.

A.5. HBase

HBase is a real-time key/value distributed column-based database modeled after Google’s BigTable.

A.6. Avro

Avro is a data serialization system that provides features such as compression, schema evolution, and code generation. It can be viewed as a more sophisticated version of a SequenceFile, with additional features such as schema evolution.

A.7. Protocol Buffers

Protocol Buffers is Google’s data serialization and Remote Procedure Call (RPC) library, which is used extensively at Google. In this book we’ll use it in conjunction with Elephant Bird and Rhipe. Elephant Bird requires version 2.3.0 of Protocol Buffers (and won’t work with any other version), and Rhipe only works with Protocol Buffers version 2.4.0 and newer.

A.8. Apache Thrift

Apache Thrift is essentially Facebook’s version of Protocol Buffers. It offers very similar data serialization and RPC capabilities. We’ll use it with Elephant Bird to support Thrift in MapReduce. Elephant Bird only works with Thrift version 0.5.

A.9. Snappy

Snappy is a native compression codec developed by Google, which offers fast compression and decompression times. It can’t be split (as opposed to LZOP compression). In the book code examples where we don’t need splittable compression, we’ll use Snappy because of its time efficiency. In this section we’ll cover how to build and set up your cluster to work with Snappy.

A.10. LZOP

LZOP is a compression codec that can be used to support splittable compression in MapReduce. Chapter 5 has a section dedicated to working with LZOP. In this section we’ll cover how to build and set up your cluster to work with LZOP.

A.11. Elephant Bird

Elephant Bird is a project that provides utilities for working with LZOP-compressed data. It also provides a container format that supports working with Protocol Buffers and Thrift in MapReduce.

A.12. Hoop

Hoop is an HTTP/S server which provides access to all the HDFS operations.

A.14. Hive

Apache Hive is a data warehouse project that provides a simplified and SQL-like abstraction on top of Hadoop.

A.15. Pig

Apache Pig is a MapReduce pipeline project that provides a simplified abstraction on top of Hadoop.

A.16. Crunch

Crunch is a pure Java library that lets you write code that’s executed in MapReduce without having to actually use MapReduce specific constructs.

A.17. R

R is an open source tool for statistical programming and graphics.

A.18. RHIPE

RHIPE is a library that improves the integration between R and Hadoop.

A.19. RHadoop

RHadoop is an open source tool developed by Revolution Analytics for integrating R with MapReduce.

A.20. Mahout

Mahout is a predictive analytics project that offers in-JVM as well as MapReduce implementations for some of its algorithms.

0