手机浏览 RSS 2.0 订阅 膘叔的简单人生 , 腾讯云RDS购买 | 超便宜的Vultr , 免费部署 N8N 的 Zeabur 注册 | 登陆
浏览模式: 标准 | 列表分类:Misc

转:编程的艺术:漂亮的代码和漂亮的软件

最近在转一些装波一文,发发牢骚而已。现实中除了那些API和一些开源软件,真的很少看得到漂亮的代码,不过有一天帅朱给我看过一段代码,不错。。。Sun也能我看过一些,也不错。看看自己写的,一泡污啊

原文来自:http://kb.cnblogs.com/page/132236/

  英文原文:Beautiful Code and Beautiful Software
译者:legendsland

  2007-10-29

  编程很有意思,是因为我可以做一些很酷的东西,但是实际上让我着迷的却是那一行行代码的语法和语义。保持对好代码和坏代码之间差异的敏感相当激 励人,同时,去寻找编写高效、自文档化和经过深思熟虑良好组织的代码的方法将会永远吸引着我。这便是我对所在领域钟爱的原因 —— 编程的艺术 —— 这种奇妙的复杂物(complex craft)将会让你花费一生的时间去成为大师。

  续Ruby之后,我学习了Java和Objective-C,我开始享受到底层软件开发的乐趣。我是在一个讨厌繁缛语言开发的社区(Rails 社区)成长起来的,但是当我第一次接触这类语言之后,发现我喜欢上了它们。它们(和Ruby比较起来)是不同的语言,但仍然具有它们特有的乐趣。以 Java 里面的for循环为例,当以我的高级程序语言的背景,编写了一些这样的基础代码后,发现这种代码可以更好地帮助我理解面向对象的一些实践,但同时我也对 for循环本身产生了兴趣。这不仅仅是优美的语言吸引了我,也是语法背后的逻辑和不同语法形式让我着迷。计算机语言,以及它们之间的差异,本身就极具魅 力。

  当这学期我在学校学汇编语言的时候,获得了相同的满足感。汇编很繁琐,有时相当痛苦,但是让我去思考使用这种新的方式去实现基本的程序功能,跟痛苦相比,是完全值得的。当然,意识到自己编写的代码如此底层,也让我享受到了极客(Geek)的快感。

  情况变得更糟了!在今年的早些时候,当我读到Wolf的程序员不喜欢编码时, 我经历了一个很不错的自我发现过程。我确实是喜欢在编码过程中解决问题,进行优雅地创造,以及通过编码来学习,但实际上我意识到我也是因为喜欢编码而编 码。至少,这就是我享受CSS和XHTML的方式。我拥有大量的Web前端开发经验,并且最近没怎么碰到新的问题(事实上,难搞的问题和我从没有见过的 Bug会让我异常兴奋)。尽管如此,我仍然喜欢这些东西。比如,整理一下我完全理解的代码让它变得好看点,就像是在我的笔记本上重复地画一些卡通猫,或者 是坐在钢琴前重复地弹三个相同的音调一样,这让我感到放松。甚至仅仅去阅读漂亮的CSS(我自己写的CSS),上面每一样东西都整齐有序、缩进良好,并且 进行了正确的层叠(CSS里面很重要的一种技术)而感到心情舒畅;相反,当我看到某些论坛的样式表里面混乱的缩进、多余的空行、被注掉的一些老代码,以及 通过故意使用错误的属性名来屏蔽掉的样式的时候,我感到难受,就像是生病了一样。

  当你可以如此轻易地被激起兴趣 ,就是上面这个结果。仅仅是墙上的影子就足够让你继续生活下去(译注:看来,她对柏拉图很有兴趣)。你得不断地重新审视自己的敏感度,以便让你的声色品味与你口袋里的钞票相匹配。(你对代码或者软件的品味来自于你自己的能力水平)

  这样来讲吧,这些天我一直在思考(整个)软件开发中的软件部分。特别是软件中的用户界面设计。今年在BARcamp,我喜欢Aza Raskin的一个实验,他让所有的开发人员举起手,然后是设计人员,接着他说那些第一次举手的人在第二次也应该举手。所有的开发人员必须是设计人员。至 少,幸运的是,所有的开发人员在他们的工作中可以对软件设计发表自己的意见。

  我越来越对软件开发中设计部分的重要性感到兴奋,尤其是当我反思我对过去所做的事情在不同方面的热情与心得的时候。在Web应用领域,开发和设 计一般是分离的。有时候,设计部分的工作在项目中被最少化了,这是因为客户是为软件的特性买单,而不会为漂亮的设计付帐。在一个项目中,我同时扮演了开发 和设计的角色,回想起来,我对只分配了两天时间来完成可视化的设计感到耿耿于怀。这决不是两天的事情。这是一个很复杂的应用软件,需要花上几周的时间与客 户交流和迭代设计。不幸的是,客户并不会因此而买单。相反,客户对我花了几个小时的原型感到无比满意,就这样,我们有了这个产品的第一个版本。

  在今年的C4上我有了另一次觉悟。好像很多Mac下的开发人员都在(私下)做自己的产品。这样,他们真的必须既是设计师又是开发人员。事实上, 设计是最重要的部分,并且用户体验和制造了不起的产品看起来要比代码本身更具有热情。在C4的一个晚上,有人在向我描述他的工作的时候,无意中帮助我看到 了这一点:编码这个基本要素是最容易的部分。那仅仅需要几周而已。真正困难和耗费时间的是搞定UI的规格。

  哇噢,我在想,为什么这看起来如此正确?为什么对我而言是这么的酷?哦,是的,那是因为我是从设计人员开始的。我享受开发、设计和艺术的方式绝然不同,这就导致了这三种享受之间巨大的差别。我一直在尝试整合开发和艺术(这两个方面),但是我其实应该整合这三个方面。

  毕竟,我的天啊!我们想要漂亮的代码或者是漂亮的软件吗?我生活中的另一个观点是:由于我的思想极具开放性和强吸收性,我发现我自己可以接受各 种相互矛盾的观点,有时候甚至是相反的观点。这种问题目前不会困扰我,因为我正处在探索模式的阶段,而不是在只接受我所相信的阶段,但是,当然啦,为了保 持我思想自身的一致性,当它们有点头绪的时候必须要好好的整理一下。

  所以,为了后续的考虑,我按照软件开发给人们带来的由内至外的收获,简单地列出了这个清单。我没有选择其他一些极好的介质,比如社区、开源和挑 战等等,是因为这些都很难按顺序列到里面去,不过我相信你可以领会到其中的要点。这个顺序对我而言是极度重要的,因为心理学家讲过,内因的力量更为强大, 更能让你坚持。比如,一个为了想从击打和踢腿中感觉到力量和兴奋而参加空手道训练的人,肯定要比仅仅为了健康的人更容易达到黑段水平。

  编程也是如此吗?

  * 代码感(译者:还记得圣斗士里面的第六感吗?)
* 编码的知识
* 享受计算机逻辑
* 享受计算机语言
* 优雅的语法
* 优美的语义
* 学习代码
* 问题求解
* 了解问题
* 获得可用性
* 完成一个产品
* 优雅的软件
* 解决人的问题
* 解决商业的问题
* 满足市场需求
* 赚钱
* 有一个稳定的职业

  哪个是最能持续激励人的收获?更重要的是,哪种动机可以制造出最好的软件?有时候我很想在这个话题上做一个很正式的研究,当我们希望软件既满足 可用,又具备可维护性,同时还叫买,而且还要满足一些其他的目标的时候,我很确信这个答案就是清单上面各种条目之间健康的平衡。我同时还很确信这种平衡性 是因情况和人而异的。现在,我已经勾画出了一条钟形曲线(正态分布),那些可以促成最佳的软件的动机位于曲线的中间部分;但是,我想实际上所有的动机在某 些方面都是有益的,并且当程序员有她自己的优先级的时候,动机自然是越多越好。

  我们领域的悲哀在于大多数程序员并不会欣赏上面大部分的收获,尤其是那些更为重要的。这个清单很有用,因为大多数编程的工作无法满足那些关心所 有这些事情的人。同样地,我很好奇,如果我们每个人都从内心关心我们做的东西,并且不会有人为了稳定的工作而去选择计算机科学者个专业,那么这个(软件) 领域将会成为什么样子呢?我好奇这样会对整个世界产生什么影响?

  我想我每年都应该反思一下这种问题,以便成为一个更好的软件开发人员。尽管如此,我还是觉得我的信念已经固定下来了:越是成长,就越希望能够在 一个足够自由的环境里面创造美妙的东西。值得注意的是,美妙和自由都是模糊和主观的概念,可以任意地去理解。我只知道,在大多数的编程工作中对代码之美和 软件设计之美的妥协永远会让我感到不满。如果到最后,我选择成为一个自由开发者去做Web设计,以满足这种自我的生活风格,我不会对此感到意外。

  最终我会从计算机上面退休,并且用我剩下的时间在国外美丽的农场里面画画。或者是,过上在街头涂涂抹抹和牢房之间互动的感性城市生活。想象一 下,当我觉得技术玩完了的时候,接下来要去哪里将是很有趣的。但愿永远不要发生这种事情,因为我希望成为一个酷酷的guru奶奶,到时候给孩子们上一些编 程的必修课呢!(Fantastic guru girl !!)

----------

看完到最后的时候,我在想guru是什么,有道告诉我,这是专家的意思。哦,

Tags: 艺术

惊闻某人离职了

得到某人离职的消息,意料之外又意料之中。所幸结果应该还算是不错。HOHO。
bobby说,篱笆网又改版了,我才想起,原来我已经有大约1年半左右没有打开过篱笆网的网站了。
输入网址后,发现果然变化很大,啥也没做,先让我登录。好吧,输入帐号密码,登录之后果然是一点都不认识了,粗一看,怎么感觉成了SNS?
我果然OUT了。
http://bbs.liba.com/t_13_7011351_1.htm
大小: 25.95 K
尺寸: 246 x 338
浏览: 1320 次
点击打开新窗口浏览全图
黎叔说过:人心散了,队伍不好带了。

大小: 31.01 K
尺寸: 500 x 89
浏览: 1313 次
点击打开新窗口浏览全图

这个,真心不应该啊。博士带队,不会差的

Tags: 篱笆网

记录,更换硬盘

在vampire的帮助和支持下,将mac的硬盘换成了SSD的,果然启动速度和程序的运行速度快了好多。
准备装一个app cleaner将以前删除 的程序清理干净

细细想一下,其实苹果的这种软件删除也不会特别干净,将配置文分开存放而不是象windows那样放在注册 表里。好处有坏处同样有。

软件app直接拖到回收站,但其实一些配置什么的都没有清理干净。只不过windows是在注册表里而已。

今天换硬盘的同时,学会了如何对拷硬盘,果然USB的速度超级慢啊。

关注:移动开发中HTML5能否替代本地程序?

标题很有诱惑力,所以我略看了一下并且转载了。在我现在的工作中就是遇到了这样的问题,是该坚持HTML5还是坚持 native的程序?还是两者混用。HTML5的好处当然有,可以随时更新新的样式。native的话就不行,但是内存消耗会小上很多。而且很多基于后台运行的任务,HTML5也不能完美实现。所以混用就成了现在大多数人的用法(用native做外包装,捕获HTML发送的一些接口、事件,这样就几乎可以两全其美了)。比如淘宝HD、add资讯、flipboard等。但是从工作量来说,就麻烦了。找一个好的IOS、androidOS开发人员容易,找一个Javascript开发人员难啊。UI是也是HTML和native之间永远的痛

不乱说,上原文:原文来自:http://www.cnbeta.com/articles/173420.htm
新闻来源:涂雅
现在越来越多的公司进入到移动互联网这个领域,选择HTML5做跨平台的解决方案,还是针对不同的平台开发,这是一个十分艰难的选择。早期的技术选型很重要,稍有不慎,后患无穷,是超前使用HTML5,还是稳妥地针对性开发,或者两者折中? 随着移动设备越来越先进,对HTML5的支持度越来越高,我们进军移动领域的时候,都会遇到一个问题,是选择HTML5和还是Native(用 原生 代码编写的本地程序)?HTML5的前景无疑是诱人的,一句“Write once, run anywhere”就可以秒杀一切。笔者最近两年来对HTML5与Native有较为深入的研究,觉得两者之间不能仅仅是二分法来选择,还要根据企业自身 的情况、团队的构成、公司的战略以及产品的特点来综合选择。

HTML5的发展前景我无疑是非常看好的,各大公司也不遗余力的推动,目前主流的三大智能机操作系统iOS、Android和WIndows Phone都已经支持大部分的HTML5特性。而移动设备硬件军备竞赛也为HTML5扫清硬件障碍。按照现在的发展速度,我判断是在三年以内甚至更快,移 动设备运行HTML5将会完全没有压力,无论是标准还是硬件。现在主流的智能机已经配置双核浏览器和1G及以上的内存,今年再出智能机没这个配置你都不好 意思发布了。

谈谈HTML5

1.HTML5可以让你摆脱对平台的依赖,用户打开浏览器,直接就可以访问你的应用,而不需要经过各种Store的审核。

2.实时更新,通常平台的审核都需要七个工作日左右的时间,如果你发布之后发现问题怎么办?Web方式就不存在这种问题。

3.Write once, run anywhere?

这是多少程序员的梦想,也曾经是Java让人心动的地方,但真正做过跨平台解决方案的人都知道,这只是一句口号而已,跨平台没那么容易玩转的。没 错,HTML5可以实现Write once, run anywhere,但我们总不能写一个Hello World来run anywhere吧。不同平台有自己的特性,不同平台用户也有自己的操作习惯,如果你想讨好所有人,也就意味着你无法讨好任何人。

4.减少开发工作量或者让开发变得更简单?

对老板来说,这是一个非常诱人话题,因为工作量的减少就意味着节省更多的钱,没有老板不喜欢用更少的钱办更多的事。而且目前一个非常大的问题是,移动设备 开发人员特别是iOS开发人员非常不好找,因为技术好的都自己做应用了,人家自己也能赚个月薪上万甚至更多,为什么要进你的公司?怎么说也是自己的事业, 拥有无限可能,还可以充分享受自由。但如果可以充分利用HTML5,那么我们就可以招聘Web前端的开发人员来构建移动应用,这样就不愁招人的有问题。因 为在许多人的眼里,HTML5/CSS/Javascript都是没多大技术含量的东西,实在找不到人,找些实习生学学也就会了。

但问题是,工作量真的会减少吗?技术门槛真的那么低么?答案是NO!

我曾经花了半年的时间去开发一个基于HTML5的移动框架,用来模拟Native应用,让HTML5应用看起来尽可能看起来像本地应用,注意:是 像。这有点像jTouch,但不一样的是,它能和Native程序很好地交互,并且能调用本地资源等等特性。但最后结果确不是那么令人满意,比如 HTML5在动画切换的时候,有时候候会有一些莫名其妙的问题,当然你可以告诉我把动画效果关了,但这看起来很死板,最后我不得不关闭某些动画。而用 Objective-c编写程序就没这么多事了,几句简单的代码可以实现很酷的动画,用HTML5需要更多的代码,甚至根本无法实现。

而且移动设备上的HTML5开发对开发人员的技术有非常高的要求,不是一般的Web前端人员能解决的,通常拥有这样技术的人才,工资水平也不会比 Native开发人员低多少。如果你仅仅是要开发一个移动设备上的网站,这会简单很多,但如果你希望模拟Native应用,并且拥有较高的效率和优雅的用 户体验,这就很有技术含量了。不要小看Javascript这类Web开发语言,通常我的看法是越简单的语言越会体现出技术人员的水平,特别是规划设计能 力。

5.其它问题,资源调用的限制,比如说在iOS中有Javascript运行不能超过15秒的限制,不能调用本地硬件设备(如相机等),无法使用推送服务等。
如何选择?

是否这样,我们就不要选择HTML5了呢?我在前面说过:“要根据企业自身的情况、团队的构成、公司的战略以及产品的特点来综合选择”,我最近在关于 HTML5讨论的微博上也有谈到:“HTML5是战略性方向,Facebook和Google已经布局,Google Mobile在iPhone上的体验可以媲美Native。基本上Native+Web App可以秒杀多数应用,如果不愿意受制于各种Store,单独的Web App也是一个不错的方向。对于游戏类和对硬件环境依赖严重的应用,只能是是Native”,相关链接:摘录微博——对移动互联网的一些看法。仅管有这样那样的问题,但HTML5是一种趋势,在未来三至五年,HTML5将会取代很多本地应用,但就像多年前我们一直在谈B/S架构取代C/S架构一样,这需要一个过程。

通常在HTML与Native之间,我们有三种选择——HTML5、Native App以及HTML5+Native,HTML5就是指纯Web的移动应用,用户需要打开浏览器,然后输入应用的网址访问。Native指的是基于特定平 台开发的应用。Native+HTML5实际上是一种加壳的方式,将HTML5用和浏览器封装起来,但这对用户是不可见的,用户没有任何异物感,和 Store上下载的App没有什么两样。

就我个人而言,我是比较推崇HTML5+Native的,这种加壳的方式,可以让你享受Native与HTML5的双重好处,但缺点是对技术含量要 求较高。当然我这里指的不是简单地把HTML5封装到一个浏览器里面,Native与HTML5会有许多的交互,实际上这有点像混合硬盘,我们即便享受 SSD的快速,但我们又想获得机械硬盘的高性价比。我认为在5-10年内,这都会是一种不错的解决方案,当HTML5和硬件发展到一定水平之后,我们再完全转向HTML5成本也会非常低的。

如何做?

假定现有一个对本地环境依赖不那么严重的项目,如微博客户端,各种社交美食甚至LBS应用,我们都可以采用HTML5+Native。如图所示,我 们可以将核心的代码Core层用封装起来,这个代码和平台无关,主要是业务逻辑以及和Shell的交互,代码用Web语言编写。在Core层上我们再根据 不同的移动平台制作不同的UI。最后我们将上述两层放到各平台的Shell中,这个Shell主要是由浏览器来完成工作,当然还包括一些硬件操作和读取本 地资源,如GPS、重力感应、相机调用、地图、推送通知或者IAP等。



我们可以把Web的升级部分部署到服务器上,用户运行App后,App会向服务器讲求获取最新的Web程序并下载运行,这样可以达到跳过各种 Store的更新审核,达到快速更新的目的。而且假如用户无法访问互联网,我们可以让用户使用上一个版本的程序,不会像纯Web App那样要求用户一定要联网。

好处

1.用户可以离线使用

2.更新下载量及少,可以全部更新,也可以选择替换部分文件

3.代码很安全安全,众所周知Web应用有一个很大的问题就是代码安全的问题,但现在我们可以将Web代码全部加密,本地应用解密后再运行,大大的提供了代码的安全性。

4.可以通过浏览器作为中介充分利用Native的好处,比如说可以使用GPS、照相机、本地相册、读取本地联系人,也可以使用推送功能等,最重要的是,某些Web无法实现的功能,我们可以利用Native来实现。

5.跨平台,多数核心代码不用重写,Javascript的代码用得好的话,在许多地方都可以用到,包括移动应用、移动网站、PC网站、各种浏览器 插件,甚至可以用WebKit封装作为跨平台的应用程序。诚然,这种方式并非完全跨平台,但这样也足以减少很多工作量了,特别是后期的维护。而且完全的跨平台是没有意义的,不同平台有自己的风格,为了更好的用户体验,界面层还是需要针对性开发的。

坏处

我觉得最大的坏处是技术难度高,如果仅仅是简单的浏览器封装几个HTML文件,那没什么技术难度,但如果要打造一个系统级的东西,这就很有技术难度了。这 要求有人要了解三个主流平台的浏览器特性,通晓Native程序的开发,要精通HTML5/CSS3/Javascript,最重要的是,要有较强 的架构设计能力。

如果要再找一个坏处的话,就是它不能满足所有的需要,它并不能代替Native,但我认为他可以替代大部的Native。
适合我们吗?

首先从产品的角度考虑,你的产品是否严重依赖于本地环境,比如说图像处理和华丽的游戏之类的。第二要考虑的是你的技术团队的构成,如果你们的团队有一个能 解决这些问题的牛人,并且有一些清通Web前端的人,那我觉得你可以考虑用这种方式。技术选型非常重要,稍有不慎,后患无穷。第三个要考虑你们公司的战 略,对HTML5未来发展的看法,愿意在移动互联网上付出多少代价,是否愿意做前瞻性的事,是否愿意在前期投入较多的资源,是否允许试错等等。

杂谈

碎碎念
1、倒车:我还好,基本没什么问题,估计下一次就是换车位了(不知道名词术语怎么说来着),反正也就那样了。倒车,脚酸呐。。。

2、网站出国,速度还能接受,希望我这台VPS对应的服务器不要超售 我就开心了。水月说的200多MS,其实真不算什么了,要知道,以前在怒江双线机房,国内访问也得200多MS了。。

3、长宽,总还是有人打电话过来,但,其实问题依旧。算了,我也不想折腾了。如果他们愿意退钱是最好,否则我就忍忍吧。毕竟我原来出问题只是在打开我自己的博客才会出问题。现在我换到国外了,也不会出问题了。

4、开始尝试使用YII的CDataProvidor做后台数据列表,果然真的是超级方便,以前没用它,太可惜了。

5、小朋友开始读英文了,外教,主要不是为了学,是娱乐。幼儿园居然体罚,吃冷饭。虽然说小朋友是会犯错,但吃冷饭就不太上路了。怕小朋友在幼儿园有阴影,所以到外面报个学校学习学习。目前看来不错,只是,外教看上云邋遢了一点。其他还好,比在学校开心多了。(一周一节课,当然是比每天都上课开心,只是2年的费用贵了点。嗯,两台mac book pro没了)