Oracle 为 OS X 发布 Java 开发工具

8_101115141915_1.jpg

2010年末的时候,苹果宣布终止对OS X的Java支持,当时乔布斯表示苹果的Java版本总是比Sun/Oracle发布落后,导致苹果比其他所有平台的Java版本都要老,所以继续支持没 有意义了。之后过了几周,苹果和Oracle宣布计划将Oracle的OpenJDK项目扩展对OS X系统的支持,这意味着将Java SE 7带给了Mac用户。

今天Oracle发布Java SE 7 Update 4JavaFX 2.1进一步兼容OS X系统。对于Java开发者来说,这次更新是首次为Mac OS X开放Java Development Kit(JDK开发工具)和Java FX Software Development Kit开发工具。

OpenJDK团体继续为OS X消费者版本Java SE 7进行努力(Java Runtime Environment (JRE) for Mac OS X),Oracle表示为消费者公众发布的日期被定在了2012年末。

此次Oracle/OpenJDK继续对OS X的Java支持很显然与最近针对Java的病毒Flashback有关。乔布斯当初就说OS X平台的Java总比别的平台版本低,这次又验证了。Oracle在发现了Java漏洞后在2月份就为Windows等平台发布了补丁,而Mac平台就被 忽略了,导致了60万台Mac中招的事件发生。而苹果也不得不在东窗事发之后连续发布Java补丁来亡羊补牢。

MacX.cn 编译

Javascript 编程风格

Douglas Crockford 是 Javascript 权威,Json 格式就是他的发明。

去年 11 月他有一个演讲(Youtube),谈到了好的 Javascript 编程风格是什么。

我非常推荐这个演讲,它不仅有助于学习 Javascript,而且能让你心情舒畅,因为 Crockford 讲得很幽默,时不时让听众会心一笑。

下面,我根据这个演讲和 Crockford 编写的代码规范,总结一下"Javascript 编程风格"。

所谓"编程风格"(programming style),指的是编写代码的样式规则。不同的程序员,往往有不同的编程风格。

有人说,编译器的规范叫做"语法规则"(grammar),这是程序员必须遵守的;而编译器忽略的部分,就叫"编程风格" (programming style),这是程序员可以自由选择的。这种说法不完全正确,程序员固然可以自由选择编程风格,但是好的编程风格有助于写出质量更高、错误更少、更易于 维护的程序。

所以,有一点应该明确,"编程风格"的选择不应该基于个人爱好、熟悉程度、打字工作量等因素,而要考虑如何尽量使代码清晰易读、减少出错。你选 择的,不是你喜欢的风格,而是一种能够清晰表达你的意图的风格。这一点,对于 Javascript 这种语法自由度很高、设计不完全成熟的语言尤其重要。

一、大括号的位置

绝大多数的编程语言,都用大括号({})表示区块(block)。起首的大括号的位置,有许多不同的写法

最流行的有两种。一种是起首的大括号另起一行:

block

{

}

另一种是起首的大括号跟在关键字的后面:

block {

}

一般来说,这两种写法都可以接受。但是,Javascript 要使用后一种,因为 Javascript 会自动添加句末的分号,导致一些难以察觉的错误。

return

{

key:value;

};

上面的代码的原意,是要返回一个对象,但实际上返回的是 undefined,因为 Javascript 自动在 return 语句后面添加了分号。为了避免这一类错误,需要写成下面这样:

return {

key : value;

};

因此,

规则1:表示区块起首的大括号,不要另起一行。

二、 圆括号

圆括号(parentheses)在 Javascript 中有两种作用,一种表示调用函数,另一种表示不同的值的组合(grouping)。我们可以用空格,区分这两种不同的括号。

规则2:调用函数的时候,函数名与左括号之间没有空格。

规则3:函数名与参数序列之间,没有空格。

规则4:所有其他语法元素与左括号之间,都有一个空格。

按照上面的规则,下面的写法都是不规范的:

foo (bar)

return (a+b);

if (a === 0) {…}

function foo (b) {…}

function (x) {…}

三、分号

分号表示语句的结束。大多数情况下,如果你省略了句尾的分号,Javascript 会自动添加。

var a = 1

等同于

var a = 1;

因此,有人提倡省略句尾的分号。但麻烦的是,如果下一行的第一个字元(token)是下面这五个字符之一,Javascript 将不对上一行句尾添加分号:"("、"["、"/"、"+"和"-"。

x = y

(function (){

})();

上面的代码等同于

x = y (function (){…})();

因此,

规则5:不要省略句末的分号。

四、with 语句

with 可以减少代码的书写,但是会造成混淆。

with (o) {

foo = bar;

}

上面的代码,可以有四种运行结果:

o.foo = bar;

o.foo = o.bar;

foo = bar;

foo = o.bar;

这四种结果都可能发生,取决于不同的变量是否有定义。因此,

规则6:不要使用 with 语句。

五、相等和严格相等

Javascript 有两个表示"相等"的运算符:"相等"(==)和"严格相等"(===)。

因为"相等"运算符会自动转换变量类型,造成很多意想不到的情况

0 == ”// true

1 == true // true

2 == true // false

0 == ‘0’ // true

false == ‘false’ // false

false == ‘0’ // true

" \t\r\n " == 0 // true

因此,

规则7:不要使用"相等"(==)运算符,只使用"严格相等"(===)运算符。

六、语句的合并

有些程序员追求简洁,喜欢合并不同目的的语句。比如,原来的语句是

a = b;

if (a) {…}

他喜欢写成下面这样:

if (a = b) {…}

虽然语句少了一行,但是可读性大打折扣,而且会造成误读,让别人误以为这行代码的意思是:

if (a === b){…}

另外一种情况是,有些程序员喜欢在同一行中赋值多个变量:

var a = b = 0;

他以为,这行代码等同于

var a = 0, b = 0;

实际上不是,它的真正效果是下面这样:

b = 0;

var a = b;

因此,

规则8:不要将不同目的的语句,合并成一行。

七、变量声明

Javascript 会自动将变量声明"提升"(hoist)到代码块(block)的头部。

if (!o) {

var o = {};

}

等同于

var o;

if (!o) {

o = {};

}

为了避免可能出现的问题,不如把变量声明都放在代码块的头部。

for (var i …) {…}

最好写成:

var i;

for (i …) {…,}

因此,

规则9:所有变量声明都放在函数的头部。

规则 10:所有函数都在使用之前定义。

八、全局变量

Javascript 最大的语法缺点,可能就是全局变量对于任何一个代码块,都是可读可写。这对代码的模块化和重复使用,非常不利。

规则 11:避免使用全局变量;如果不得不使用,用大写字母表示变量名,比如 UPPER_CASE。

九、new 命令

Javascript 使用 new 命令,从建构函数生成一个新对象。

var o = new myObject ();

这种做法的问题是,一旦你忘了加上 new,myObject ()内部的 this 关键字就会指向全局对象,导致所有绑定在 this 上面的变量,都变成全部变量。

规则 12:不要使用 new 命令,改用 Object.create ()命令。

如果不得不使用 new,为了防止出错,最好在视觉上把建构函数与其他函数区分开来。

规则 13:建构函数的函数名,采用首字母大写(InitialCap);其他函数名,一律首字母小写。

十、自增和自减运算符

自增(++)和自减(–)运算符,放在变量的前面或后面,返回的值不一样,很容易发生错误。

事实上,所有的++运算符都可以用"+= 1"代替。

++x

等同于

x += 1;

代码变得更清晰了。有一个很可笑的例子,某个 Javascript 函数库的源代码中出现了下面的片段:

++x;

++x;

这个程序员忘了,还有更简单、更合理的写法:

x += 2;

因此,

规则 14:不要使用自增(++)和自减(–)运算符,用+=和-=代替。

十一、区块

如果循环和判断的代码体只有一行,Javascript 允许该区块(block)省略大括号。

下面的代码

if (a) b (); c ();

原意可能是

if (a) { b (); c ();}

但是,实际效果是

if (a) { b ();} c ();

因此,

规则 15:总是使用大括号表示区块。

16 个新鲜的 CSS3 在线教程

用CSS3制作令人印象深刻的产品展示

使用jQuery和CSS3制作闪亮的旋钮控制

使用 CoffeeScript 创建一个类 iOS 的界面

使用 CSS3 制作报纸阅读

制作一个 CSS3 动画菜单

使用 jQuery 和 CSS3 制作更好的元素选择

CSS3 多级菜单,具有动画效果

制作你的第一个 Chrome 扩展

BounceBox 提示插件

色彩多样的滑动块

使用 jQuery 和 CSS3 创建一个音频播放器

CSS3和jQuery项目的模糊效果

CSS3 制作的动画按钮

CSS3 制作的圆形导航效果

创建一个卷帘菜单

制作 Photoshoot

via djdesignerlab

RSS 永生不灭

【编者按】本文作者为Swizec Teller |

本文是在看过《RSS之战》以及HackerNews上的一些激烈讨论之后有感而发,简而言之,RSS永生不灭。

RSS已死

在2009年的时候, Steve GillmorTechcrunch发了一篇文章,其中有这么一段话:

是时候完全放弃RSS选择Twitter了,RSS已不再具有价值,新闻之河已变成了新闻East River(美国纽约州东南部的海峡,位于曼哈顿岛与长岛之间,本句话寓意RSS价值不在,不值得留恋)。

这一言论激起了广泛讨论,忽然之间似乎每个人每种动物都以为RSS已死,我们应该弃它而去,Twitter将会满足我们的要求,RSS out了。

RSS真的死了吗

在2011年初的时候,RSS并没有像他们认为的那样,完全死掉。Quora上有用户问:如果RSS死了,谁来接班?其中Robert Scoble作了一个很官方的回答(当我见到他的时候,他还说我的创业想法很失败,因为一切都围绕RSS在转)。

既然说RSS死了,什么是死亡?如何定义?对于我来说,一种技术的消亡就意味着无人再有兴趣讨论这种技术,而且最具创新能力的公司也无法利用这种技术做出什么有用的东西。

这么说来,Scoble认为RSS死了,因为Google Reader对他已经毫无用处,也没有人能在RSS领域进行创新了。五个月后,Bummer写了一篇关于iPad上RSS阅读器Feedly的文章,建议 大家不要在iPad上安装Feedly。七个月前还发文声称为iPad开发RSS阅读器就是个愚蠢的做法。

RSS确实面临严峻考验

直到现在,RSS也没有完全消亡,《RSS之战》在黑客新闻上再一次引起了广泛讨论,有许多公司已经在产品中撤出RSS,他们更喜欢专用格式。

  • 苹果新一代Mac操作系统美洲狮似乎也不再支持RSS,并从Safari中,Mail中将RSS撤除。
  • 最新版本的Firefox也不再支持RSS,从原来的url栏消失。
  • Twitter也取消了为用户提供RSS新闻动态。
  • 据说Facebook曾支持过RSS,但很快就消失了,我甚至记不清,我是是否在Facebook见过它。
  • 在Chrome上根本就从未见过RSS。

难道真的RSS就要死掉了么?

其实没有那么糟糕

一种技术,三年以来大家都认为它死了,却还能激起强烈讨论,说明有某种力量在支撑着它。

曾经在Twitter上问过,是否还有人使用RSS,11个回答yes,一个很坚定的回答了no,其中一个不确定,为什么说RSS永生?很简单,它由用户力量的支撑。

在在线参与中有一个90-9-1法则,也就是有90%的内容都来自于1%的顶级参与者,如果这1%的人都是你的用户,那么你的技术是否会受到欢迎就 有保证了,这就是RSS为什么会存在,至少会存在更长一段时间的原因,因为那些分享最多的所有人中,有许多都还在使用RSS,这就是用户力量。

为什么用户还要使用RSS?

Twitter永远无法代替RSS,完全不能,Twitter太忙,我的Twitter每隔一到两分钟就会有差不读30条消息更新。如果你要关注重要消息,这不是个好的环境,不但消息短,更重要的是发出的时间太快,如果要想阅读500字以上的重要文章,更是不可能的事。

这时,RSS的优势显现出来了,在Google Reader上,可能一个小时才更新10则消息,不会很快被湮没,我可以订阅不同网站的内容,可以再左边的订阅网站中任意选择自己关心的内容,没有压力, 不会担心自己错过了什么重要消息,消息一直都在,一个星期,甚至一个月,而Twitter上的消息可能存在时间不超过一个星期。

在Google Reader里边显示的消息,虽然很长,讲的却是不同的东西,很有价值,而Twitter里边的,虽然更新速度快,但大多数消息讲的几乎都是同样的事情,围绕某件事情转发评论,一天真正发出的消息可能只有一条。

对于我这种人来说,Twitter有时让人厌烦,都是一些我不太关心的瞎扯,闲聊,分享的很多链接还不是来自web或者博客,而RSS则展示了更多的内容。

对一些普通用户来说,RSS可能是失败的,有点点复杂,有点点怪异,但对于一些重要用户,或者RSS粉丝来说,RSS永远不会死。

Via Zemanta

文/雷锋网

我最喜欢的10条编程语录

今天也在国外程序员 Senthil Kumar 的博客看到了他最喜欢的10条编程语录。其中大部分已经分享过,现再次综合分享给大家。

(提示:正如广为流传的经典段子,有些经典语录有多个版本,作者署名都不一样。从下文就可以看出来。英文原文我保留了 Senthil Kumar 的。中文版本后面的作者署名是我当时所看到的署名。)

09. If debugging is the process of removing software bugs, then programming must be the process of putting them in. – Edsger Dijkstra
如果调试程序是移除臭虫(软件缺陷)的过程,那编写程序就是把臭虫放进来的过程。—— 迪杰斯特拉
If debugging is the process of removing software bugs, then programming must be the process of putting them in.
08. The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time. – Tom Cargill
软件开发的时间通常是这样的:一开始的90%开发工作用掉了整个计划90%的时间,剩下的10%同样需要整个计划90%的时间,而最终发布前的修改也是如此。—— N.J. Rubenking
Writing the first 90 percent of a computer program takes 90 percent of the time.  The remaining ten percent also takes 90 percent of the time and the final touches also take 90 percent of the time. ~N.J. Rubenking
 
07. “There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.”- C.A.R. Hoare
设计软件有两种方法:一种是简单到明显没有缺陷,另一种复杂到缺陷不那么明显。—— 托尼·霍尔
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
 
06. Measuring programming progress by lines of code is like measuring aircraft building progress by weight. – Bill Gates
用代码行数来衡量程序的开发进度,就好比用重量来衡量飞机的制造进度。—— 比尔·盖茨
Measuring programming progress by lines of code is like measuring aircraft building progress by weight.
 
05. “Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.” – Martin Golding
在编写代码的时候,你要经常想着,那个最终维护你代码的人可能将是一个有暴力倾向的疯子,并且他还知道你住在哪里。—— 里克·奥斯本
补充:关于这条语录,StackOverflow 上也有个讨论帖,给出的答案可能是 John Woods。
 
04. “The trouble with programmers is that you can never tell what a programmer is doing until it’s too late.” – Seymour Cray
程序员的问题是,你无法知道他在做什么,直到为时已晚。—— 西摩·克雷
 
03. Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. – Rick Cook
今日之编程,已是竭力要建立更大更反白痴程序的软件工程师,和正塑造更大更优质白痴的现实世界之间的比赛。目前来看,现实世界赢了。—— Rick Cook
 
02. “Most of you are familiar with the virtues of a programmer. There are three, of course: laziness, impatience, and hubris.” – Larry Wall
你们大部分人都熟悉程序员的美德。当然了,是这三种:懒惰、急躁、傲慢。—— 拉里·沃尔 (Perl 语言之父)
 
01. “Sometimes it pays to stay in bed on Monday, rather than spending the rest of the week debugging Monday’s code.” – Christopher Thompson
有的时候宁愿付钱让你周一在床上待着,也不想让你用这周剩下的时间去调试你在周一所写的代码。 —— 丹·所罗门
 
00. Walking on water and developing software from a specification are easy if both are frozen. – Edward V Berard
在水中行走,和根据一份需求开发软件一样,如果它们都“冻”住了,那就容易了。—— 爱德华·贝拉尔德
 
英文原文:Senthil Kumar  编译:伯乐在线 – 黄利民