• Feeds

  • Archive for the ‘tech’ Category


    出品人眼里的一次QCon技术大会

    上千人的技术大会非常壮观,这次QCon北京全球软件开发大会的参会人数有可能达到了历史新高。考虑到北京国际会议中心会场的容载能力不足,对于参会人员来说,在这次大会中选择听一些热门内容的演讲注定是一次艰苦的历程。演讲开始前如果刚好从别的分会场跑过来,就很有可能堵在门口进不去;坚守一个分会场不转场的同学保留住了席位,但几百人挤在一个会场持续几个小时,感觉离烤肉的距离已差不远。

    本次Tim继续担当了可扩展高可用专题分会场的出品人,可扩展是指软件架构中项目及产品在快速成长的阶段具备很好的扩展及应对能力。而可用性则关注项目在长时间运行以及碰到极端压力的情况下仍然具有较好的稳定性,包括应用柔性可用策略的能力。考虑到国内互联网创业的蓬勃发展,大量的成长型企业会碰到架构瓶颈的问题,前几个月曾经出现一个爆款的app太火,一堆外援的技术专家和云平台去救火的情形。因此预计专题会得到较多的关注,主办方也特意保留了一个较大的分会场并策划了全天的专题内容。跟以往的情况比较类似,考虑到在可扩展及高可用的行业代表性,分享的讲师大多是来自知名的互联网公司,但是在与讲师们准备演讲内容时,Tim会建议讲师将不具有广泛适用性(比如需要依赖大公司自研系统的一些做法)内容去除,让介绍的经验能让大部分参会群体包括初创型企业有较好的借鉴性,方便应用到听众各自的环境。

    由于此专题在历届QCon关注度和评价都不错,也曾经产生过不少互联网界经典的架构案例,因此本次的讲师们也都非常有压力,分享的内容在准备期间就经过多个版本的迭代,比如来自微博的讲师秦迪总结了一篇做一场不被喷的技术分享
    ,其对待分享的态度以及一场让听众满意的分享如何去做值得架构师参考。

    选择是否去参加一场技术大会也是个很痛苦的抉择,不去的话感觉错失了好多信息,尽管这些信息最终会通过社交媒体传到你眼前;去了的话又感觉学习效果还不如坐在书桌前喝着茶静静的看一个网上的演讲视频。当参会者选择艰苦的到达会场参会,通常希望能得到一些启发及经验,并进一步应用到自身的工作中,参会者把这些具有很强启发及可借鉴性的经验称为“干货”。由于资讯高效传播的特性,要做到这一点实际上越来越难。大公司中或者国外一些具有广泛借鉴意义的方法一经出现,就会迅速被各种技术媒体及技术大V在行业内传播,捂着一个好方法到某个技术大会再揭秘这种可能是非常低,讲师要将分享打造成一场受欢迎的演讲挑战越来越大,大多情况讲师介绍的内容属于大家日常通过网络可获取到的知识。

    尽管获得满意“干货”的机会不好保证,但最近几年参会的人员越来越多。思考其原因,技术大会越来越类似电影行业,技术大会的主角是各种技术大拿,还有幕后出谋划策的策划编辑及专题出品人;电影也是由导演、演员及剧本决定。由于观众的审美品位越来越高,相同的题材出现一次后就不太好再次重演,因此导演和技术大会的策划都在挖空心思寻找观众感兴趣的题材。从理性角度,如果在电影院碰到满意的的电影可能越来越低的情况,观众会减少去看电影。但在事实上,未得到满足的是观众还是一次次乐此不疲走进电影院。技术大会也越来越多的表现出这种倾向。

    也许,相比于其他获得启发的方式,观众就是喜欢这种通过现场感和全心身投入相应主题的专注感来获得思考及满足。一周前打包的slides放在网上(或躺在硬盘的角落)无人问津,赶2小时的地铁去看一场现场分享的事情却乐此不疲。

    一些人确实通过现场学到了一些新知识;另外一些人在体验不佳时候则选择更多通过大会去找大牛瞻仰或切磋、与很久没见到的同行交流等,当然也有抱着单一目的去认识更多牛人的。因此不少技术大会也被戏称程序员的线下社交平台。但是社交只是一个伴随物,经常出现在社区或者技术大会上,每个人都跟你有点头之交,但没有人想到跟你探讨专业问题,沉迷于交际的价值会非常有限。

    从讲师的角度,大部分讲师具有不错的行业代表性,但也不排除一些讲师是为了存在感而参与。一类讲师是有了非常满意的素材并且受邀才会出现在分享的讲台上;而也有一类讲师是先报名则去慢慢找演讲的题材,这种情况就表现出更多宣传及表达存在感的诉求。不过这两种例子都极端一些。

    (EOF)

    最后如果你是一位架构师或首席工程师,并且很愿意参加社区讨论,请了解下面介绍的这个可扩展高可用群的介绍。

    Tim也加入过不少会议群,99%的情形加了一群人之后还没留下一些有效的讨论就无疾而终了,一群缺乏组织的陌生人聚在一起的讨论区通常很难持久下去。在纠结的心情中创建了一个群,周末通过圈子之间的互相邀请目前积累了不少人,也暂时还没有沉寂,并意外的是还输出了一些不错的讨论内容,如这篇WebIM实践过程中可能遇到的问题及总结。这个群欢迎架构师、首席架构师、首席工程师或一线技术负责人加入,潜水的成员会定期清除,有兴趣的可以关注Tim公众号“TimYang_net”后回复“arch”获取群进入方式。

    修改WordPress主题以适配移动浏览

    考虑到网站不少用户是从移动媒体点过来阅读的,但之前的网站WordPress主题只是针对PC端设计,且几年未做过修改,因此周末将网站对移动端浏览适配做了优化。

    首先博客界面以内容阅读为主,一直选择极简风格,去掉了不必要的组件。由于主机不在国内,考虑到访问速度,也尽量减少CSS及JS文件的数量。因此在官网可选的主题就很不多,一些免费的主题也对移动界面做自动适配,但是测试后加载速度及一些细节问题不理想,另外大多主题内部的PHP结构复杂,不利用自定义修改。因此打算发挥工程师的hacker精神,自行修改一下CSS及相关的代码来适配移动浏览。

    Tim的WordPress是在一个叫R755的主题上修改的,这个主题比较简单,仅有一个CSS文件,PHP也是按照功能划分,所有PHP文件在10个以内,再加上页面布局主要是通过div来控制,因此比较容易修改。

    为了适应移动浏览,首先在HTML的meta里面添加viewport,
    <meta name=viewport content="width=device-width, initial-scale=1">
    主要是让iOS能够按照1倍初始缩放来展现文字。Viewport参数说明可以参看官方文档

    字体方面,由于主要为屏幕浏览设计,首选无衬线字体,这方面支持最广泛的就是Helvetica Neue,Mac及iOS的浏览器都支持,它据说也是乔布斯最喜爱的字体。如果你想单独对Mac做优化,可以考虑使用“Lucida Grande”,在Mac上有出色表现,但未在iOS支持。另外Mac/iOS也都支持Avenir,据说是下一代Mac/iOS的favorite字体,显示效果也不错,但个人感觉用在input/button/link等元素上面没有Helvetica正式,所以最终还是选择Helvetica Neue。

    字号方面可以选择16px或者18px,Tim是选择了18px。因此最终修改body的css如下
    font: 18px/1 "Helvetica Neue", Helvetica, Tahoma, Arial, \5b8b\4f53, sans-serif;

    其他div的字体定义最好通过使用em单位来定义,这样后续只需要修改一处字号就可以全局联动。

    排版方面,首先将原先所有div定义的width进行修改,先都去掉注释掉,改成自动适配宽度。但去掉宽度之后在PC端排版会横向无限拉宽,因此需要添加一个max-width来限制最大的宽度。右侧栏考虑到在移动屏幕的大小无法展示,因此通过JavaScript来控制,只在屏幕超过一定宽度时候才展现。

    由于Tim的blog浏览用户50%以上都是Chrome浏览器,因此优化调试过程中主要利用Chrome的developer模式来进行,它可以直接在打开页面时候在浏览器控制台调整CSS来实时观察效果,优化的大部分工作是将div的margin, border, padding等参数微调之后再在手机的Safari上验证效果。
    div
    (如图所示,Chrome中可以直接通过点击上图中边框的相应元素来直接修改展示效果,非常便利)

    最后,由于Gravatar也遭到了封禁,考虑到个人blog评论量不是特别大,而且考虑到加载速度,因此在后台禁用了显示Gravatar,但界面留下了一块空白区域,因此加了一个静态的默认头像。

    由于Tim是在Mac的工作环境修改的,修改完成之后,再在Windows下观察了Chrome, FireFox及IE下的表现,确保没有大的排版问题。

    如果装了xcode,可以在Mac上通过iOS模拟器来测试浏览器效果,不需要启动xcode的模拟器打开方法,命令行输入
    open "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/Applications/iPhone Simulator.app"

    另外也测试了Samsung自带的浏览器,其他手机终端未进行测试,目前测试本网站所有页面已经可以在iPhone/iPad正常显示,如果有严重的排版问题,也欢迎留言提出,留言时请告知手机型号及浏览器版本。如果你在PC浏览,可以通过下面二维码进入首页测试。
    timyang_net_qrcode

    技术晋升的误区


    每到年底,业内不少工程师又需面对晋升答辩的流程,如何让自己在最短的时间完成职级提升是大家关注的话题。在一个规范运作的公司里,基础的晋升通常由部门的经理或者技术负责人定夺,更高级别的评估通常由一个跨部门或公司范围的技术专业委员会(Technical Committee简称TC)来负责。本人有幸参与了几年TC的工作,很高兴看到不少人员的快速成长,但同时看到的一些成长认识误区如下。大家可以通过这些误区的了解,来合理的规划自己的职业生涯,获得更好的职业成长。

    • 罗列工作、项目或者KPI。技术委员会评估一个人的能力时,通常希望寻找论据来支持候选人符合更高级别的Level。但是支持点并不是凭工作量或者项目数的多少来决定。项目按时完成情况是一个辅助因素,但不是全部。因此在所罗列的项目中,寻找那些项目包含了能支撑你胜任高Level去介绍。
    • 没有重点及个人贡献。有些候选人介绍了几个形态各异的项目,但需要评委去仔细挖掘到底体现了候选人哪方面能力;另外一方面有些员工虽然参与了重点及有挑战的项目,但如果其中的个人贡献不好辨别则很难加分。评委可能想“嫦娥三号项目很伟大,可是这个家伙究竟是参与开发了玉兔号月球车,还是仅仅坐在监控大厅看显示器……”。仅强调项目成果评委无法判断候选人的能力,突出重点项目及个人的独特贡献,是材料展示的关键。
    • 承担过的项目与申请的Level不匹配。有些候选人参与过不少项目,对公司也有贡献。但是TC对不同的Level期望候选人展示的能力及规划能力是不同的,越是高阶Level申请,越是看在领域内的规划能力、影响力与愿景,如果目标仅停留在项目完成与否上,不管在哪个级别都会有所欠缺。
    • 可度量及可比性不强。技术行业中,分工越来越细,因此候选人从事一个大家不了解也没参与过的领域的情况越来越多。因此如何将这块的工作的好坏达到一个行业内的可比性也是很重要,帮助TC来理解你的工作。
    • 大篇幅罗列非专业领域的能力,比如项目管理、团队管理、跨团队协调成绩、培养新人成果、项目交付状况、创新成绩等。并不是说这些材料不好或不能讲,但是如果60%以上篇幅都是讲这些,TC无法判断你在专业上是否达到了申请的Level。通常TC对专业角度的考察会占到60%以上的权重。直接说出你打了哪几次胜仗,每场由于环境的变化你灵活使用了哪些兵法来克服困难,在某些特别的条件下,你灵活使用了一些没用过的兵法取得了良好效果。如果你发现过去缺少独立打仗的机会,请看下一条。
    • 岗位成长性差。这一点无关答辩技巧,更多是路线规划与上级主管的培养问题。由于注重结果导向,大部分主管更多精力会放在项目的交付及进度,对下属的安排主要是工作的分配及是否按时完成的监督,而对员工的技术成长、路线规划等则会偏少。碰到这种情况,更多的跟上级在专业发展方面进行交流。确定你的技术成长路线并寻求上级的资源支持,大部分上级也会很乐意提供资源的配合。

    (PS:曾打算写一篇晋升攻略,但考虑到每个人的目标及成长路线的多元化,很难给出公式化的建议,因此仅罗列一些误区供读者思考。)

    123...Last