Skip to content

Commit

Permalink
Site updated at 2014-09-28 06:39:14 UTC
Browse files Browse the repository at this point in the history
  • Loading branch information
@Onetaway
Onetaway committed Sep 28, 2014
1 parent d0e29ea commit f0e2cf8
Show file tree
Hide file tree
Showing 6 changed files with 49 additions and 49 deletions.
24 changes: 12 additions & 12 deletions atom.xml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@
<title><![CDATA[Coding is Art]]></title>
<link href="http://Onetaway.github.io/atom.xml" rel="self"/>
<link href="http://Onetaway.github.io/"/>
<updated>2014-09-28T13:48:29+08:00</updated>
<updated>2014-09-28T14:37:56+08:00</updated>
<id>http://Onetaway.github.io/</id>
<author>
<name><![CDATA[Onet away]]></name>
Expand Down Expand Up @@ -114,32 +114,32 @@
<p>我们必须明智且审慎地设计这些。当你在思考 API 的时候，有两个关键的问题：</p>
<ul>
<li>What is the control?</li>
<li>控件是什么？</li>
</ul>
<p>This influences the interface and convenience methods. Is it a button? A slider? Your interface is obvious. Your convenience methods will follow the standard semantics of the control.</p>
<p>这影响着接口和便捷方法。它是一个按钮？或者是一个滚动条？你的接口是很明显的。你的便捷方法将会遵循控件的标准语意。</p>
<ul>
<li>What is the control like?</li>
<li>控件像什么？</li>
</ul>
<p>This influences the delegate and/or data-source model and notifications. If it’s a new type of control, is it essentially very similar to something else? An outline view is a linear table. A calendar widget is a date-picker. A collection of commands presented with a unified presentation is a menu.</p>
<p>这影响着代理、数据源模型以及通知。如果它是一种新的控件，那它本质上有和其他控件相似的地方么？一个大纲视图是一个线性表。一个日历小工具是一个日期选择器。命令的集合以统一的表现形式显示在菜单栏里。</p>
<p>Our core goal is consistency with existing components and models, so that we can turn an unfamiliar control into something the developer already understands. Use standard APIs, models, and patterns wherever possible (and that’s almost always). Familiarity and intuitiveness are just as important at code level as they are for the end user.</p>
<p>我们的核心目标是同现有的组件和模型保持一致，只有这样，我们才能将不熟悉的控件转换为开发者已经熟知的东西。尽量在任何地方使用标准的 API，模型和模式。熟悉感和直觉在代码级的重要性与在用户级的重要性一样。</p>
<p>Let’s look at the four components of the component API mentioned above.</p>
<p>让我们看一下上面提到的组件 API 中的四个要素。</p>
<p>Class interface</p>
<h3>类的接口</h3>
<p>Here’s the interface file for MGTileMenu.</p>
<p>这里是 <a href="https://github.com/mattgemmell/MGTileMenu/blob/master/MGTileMenu/MGTileMenuController.h">MGTileMenu 的接口文件</a>。</p>
<p>Before we even start talking about the specifics of the interface, we have a couple of over-arching rules:</p>
<p>在我们开始讨论特定的接口之前，我们先来看看一些重要的准则。</p>
<p>Rule 1: Use the local dialect</p>
<h2>准则1：使用本平台语言</h2>
<p>One the most common mistakes I see in API design is the use of foreign conventions. APIs belong to a platform and a developer ecosystem. You simply can’t use whatever idioms and architectures you’re used to from a different platform; to do so is to pollute your current codebase and to damage the productivity of your fellow developers.</p>
<p>在 API 设计中我见到的最普遍的错误是使用<em>其他平台的习惯</em>。API 属于一个平台和一个开发者生态系统。你不能使用你曾经熟悉的与本平台不同的平台的习语和架构，那样做，只会污染你当前的代码，并且降低后继开发者生产力。</p>
<p>Learn your target platform’s conventions before coding. For example, on iOS or OS X, don’t use exceptions for control flow. Name your methods in an appropriate manner (which usually means sufficiently verbose, but should also of course be sufficiently succinct).</p>
Expand Down
22 changes: 11 additions & 11 deletions blog/2014/09/18/apishe-ji/index.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -132,32 +132,32 @@ <h3>开发者的接口</h3>
<p>我们必须明智且审慎地设计这些。当你在思考 API 的时候，有两个关键的问题：</p>

<ul>
<li>What is the control?</li>
<li>控件是什么？</li>
</ul>


<p>This influences the interface and convenience methods. Is it a button? A slider? Your interface is obvious. Your convenience methods will follow the standard semantics of the control.</p>
<p>这影响着接口和便捷方法。它是一个按钮？或者是一个滚动条？你的接口是很明显的。你的便捷方法将会遵循控件的标准语意。</p>

<ul>
<li>What is the control like?</li>
<li>控件像什么？</li>
</ul>


<p>This influences the delegate and/or data-source model and notifications. If it’s a new type of control, is it essentially very similar to something else? An outline view is a linear table. A calendar widget is a date-picker. A collection of commands presented with a unified presentation is a menu.</p>
<p>这影响着代理、数据源模型以及通知。如果它是一种新的控件，那它本质上有和其他控件相似的地方么？一个大纲视图是一个线性表。一个日历小工具是一个日期选择器。命令的集合以统一的表现形式显示在菜单栏里。</p>

<p>Our core goal is consistency with existing components and models, so that we can turn an unfamiliar control into something the developer already understands. Use standard APIs, models, and patterns wherever possible (and that’s almost always). Familiarity and intuitiveness are just as important at code level as they are for the end user.</p>
<p>我们的核心目标是同现有的组件和模型保持一致，只有这样，我们才能将不熟悉的控件转换为开发者已经熟知的东西。尽量在任何地方使用标准的 API，模型和模式。熟悉感和直觉在代码级的重要性与在用户级的重要性一样。</p>

<p>Let’s look at the four components of the component API mentioned above.</p>
<p>让我们看一下上面提到的组件 API 中的四个要素。</p>

<p>Class interface</p>
<h3>类的接口</h3>

<p>Here’s the interface file for MGTileMenu.</p>
<p>这里是 <a href="https://github.com/mattgemmell/MGTileMenu/blob/master/MGTileMenu/MGTileMenuController.h">MGTileMenu 的接口文件</a>。</p>

<p>Before we even start talking about the specifics of the interface, we have a couple of over-arching rules:</p>
<p>在我们开始讨论特定的接口之前，我们先来看看一些重要的准则。</p>

<p>Rule 1: Use the local dialect</p>
<h2>准则1：使用本平台语言</h2>

<p>One the most common mistakes I see in API design is the use of foreign conventions. APIs belong to a platform and a developer ecosystem. You simply can’t use whatever idioms and architectures you’re used to from a different platform; to do so is to pollute your current codebase and to damage the productivity of your fellow developers.</p>
<p>在 API 设计中我见到的最普遍的错误是使用<em>其他平台的习惯</em>。API 属于一个平台和一个开发者生态系统。你不能使用你曾经熟悉的与本平台不同的平台的习语和架构，那样做，只会污染你当前的代码，并且降低后继开发者生产力。</p>

<p>Learn your target platform’s conventions before coding. For example, on iOS or OS X, don’t use exceptions for control flow. Name your methods in an appropriate manner (which usually means sufficiently verbose, but should also of course be sufficiently succinct).</p>

Expand Down
2 changes: 1 addition & 1 deletion blog/categories/du-shu-bi-ji/atom.xml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@
<title><![CDATA[Category: 读书笔记 | Coding is Art]]></title>
<link href="http://Onetaway.github.io/blog/categories/du-shu-bi-ji/atom.xml" rel="self"/>
<link href="http://Onetaway.github.io/"/>
<updated>2014-09-28T13:48:29+08:00</updated>
<updated>2014-09-28T14:37:56+08:00</updated>
<id>http://Onetaway.github.io/</id>
<author>
<name><![CDATA[Onet away]]></name>
Expand Down
24 changes: 12 additions & 12 deletions blog/categories/fan-yi/atom.xml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@
<title><![CDATA[Category: 翻译 | Coding is Art]]></title>
<link href="http://Onetaway.github.io/blog/categories/fan-yi/atom.xml" rel="self"/>
<link href="http://Onetaway.github.io/"/>
<updated>2014-09-28T13:48:29+08:00</updated>
<updated>2014-09-28T14:37:56+08:00</updated>
<id>http://Onetaway.github.io/</id>
<author>
<name><![CDATA[Onet away]]></name>
Expand Down Expand Up @@ -62,32 +62,32 @@
<p>我们必须明智且审慎地设计这些。当你在思考 API 的时候，有两个关键的问题：</p>
<ul>
<li>What is the control?</li>
<li>控件是什么？</li>
</ul>
<p>This influences the interface and convenience methods. Is it a button? A slider? Your interface is obvious. Your convenience methods will follow the standard semantics of the control.</p>
<p>这影响着接口和便捷方法。它是一个按钮？或者是一个滚动条？你的接口是很明显的。你的便捷方法将会遵循控件的标准语意。</p>
<ul>
<li>What is the control like?</li>
<li>控件像什么？</li>
</ul>
<p>This influences the delegate and/or data-source model and notifications. If it’s a new type of control, is it essentially very similar to something else? An outline view is a linear table. A calendar widget is a date-picker. A collection of commands presented with a unified presentation is a menu.</p>
<p>这影响着代理、数据源模型以及通知。如果它是一种新的控件，那它本质上有和其他控件相似的地方么？一个大纲视图是一个线性表。一个日历小工具是一个日期选择器。命令的集合以统一的表现形式显示在菜单栏里。</p>
<p>Our core goal is consistency with existing components and models, so that we can turn an unfamiliar control into something the developer already understands. Use standard APIs, models, and patterns wherever possible (and that’s almost always). Familiarity and intuitiveness are just as important at code level as they are for the end user.</p>
<p>我们的核心目标是同现有的组件和模型保持一致，只有这样，我们才能将不熟悉的控件转换为开发者已经熟知的东西。尽量在任何地方使用标准的 API，模型和模式。熟悉感和直觉在代码级的重要性与在用户级的重要性一样。</p>
<p>Let’s look at the four components of the component API mentioned above.</p>
<p>让我们看一下上面提到的组件 API 中的四个要素。</p>
<p>Class interface</p>
<h3>类的接口</h3>
<p>Here’s the interface file for MGTileMenu.</p>
<p>这里是 <a href="https://github.com/mattgemmell/MGTileMenu/blob/master/MGTileMenu/MGTileMenuController.h">MGTileMenu 的接口文件</a>。</p>
<p>Before we even start talking about the specifics of the interface, we have a couple of over-arching rules:</p>
<p>在我们开始讨论特定的接口之前，我们先来看看一些重要的准则。</p>
<p>Rule 1: Use the local dialect</p>
<h2>准则1：使用本平台语言</h2>
<p>One the most common mistakes I see in API design is the use of foreign conventions. APIs belong to a platform and a developer ecosystem. You simply can’t use whatever idioms and architectures you’re used to from a different platform; to do so is to pollute your current codebase and to damage the productivity of your fellow developers.</p>
<p>在 API 设计中我见到的最普遍的错误是使用<em>其他平台的习惯</em>。API 属于一个平台和一个开发者生态系统。你不能使用你曾经熟悉的与本平台不同的平台的习语和架构，那样做，只会污染你当前的代码，并且降低后继开发者生产力。</p>
<p>Learn your target platform’s conventions before coding. For example, on iOS or OS X, don’t use exceptions for control flow. Name your methods in an appropriate manner (which usually means sufficiently verbose, but should also of course be sufficiently succinct).</p>
Expand Down
22 changes: 11 additions & 11 deletions index.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -244,32 +244,32 @@ <h3>开发者的接口</h3>
<p>我们必须明智且审慎地设计这些。当你在思考 API 的时候，有两个关键的问题：</p>

<ul>
<li>What is the control?</li>
<li>控件是什么？</li>
</ul>


<p>This influences the interface and convenience methods. Is it a button? A slider? Your interface is obvious. Your convenience methods will follow the standard semantics of the control.</p>
<p>这影响着接口和便捷方法。它是一个按钮？或者是一个滚动条？你的接口是很明显的。你的便捷方法将会遵循控件的标准语意。</p>

<ul>
<li>What is the control like?</li>
<li>控件像什么？</li>
</ul>


<p>This influences the delegate and/or data-source model and notifications. If it’s a new type of control, is it essentially very similar to something else? An outline view is a linear table. A calendar widget is a date-picker. A collection of commands presented with a unified presentation is a menu.</p>
<p>这影响着代理、数据源模型以及通知。如果它是一种新的控件，那它本质上有和其他控件相似的地方么？一个大纲视图是一个线性表。一个日历小工具是一个日期选择器。命令的集合以统一的表现形式显示在菜单栏里。</p>

<p>Our core goal is consistency with existing components and models, so that we can turn an unfamiliar control into something the developer already understands. Use standard APIs, models, and patterns wherever possible (and that’s almost always). Familiarity and intuitiveness are just as important at code level as they are for the end user.</p>
<p>我们的核心目标是同现有的组件和模型保持一致，只有这样，我们才能将不熟悉的控件转换为开发者已经熟知的东西。尽量在任何地方使用标准的 API，模型和模式。熟悉感和直觉在代码级的重要性与在用户级的重要性一样。</p>

<p>Let’s look at the four components of the component API mentioned above.</p>
<p>让我们看一下上面提到的组件 API 中的四个要素。</p>

<p>Class interface</p>
<h3>类的接口</h3>

<p>Here’s the interface file for MGTileMenu.</p>
<p>这里是 <a href="https://github.com/mattgemmell/MGTileMenu/blob/master/MGTileMenu/MGTileMenuController.h">MGTileMenu 的接口文件</a>。</p>

<p>Before we even start talking about the specifics of the interface, we have a couple of over-arching rules:</p>
<p>在我们开始讨论特定的接口之前，我们先来看看一些重要的准则。</p>

<p>Rule 1: Use the local dialect</p>
<h2>准则1：使用本平台语言</h2>

<p>One the most common mistakes I see in API design is the use of foreign conventions. APIs belong to a platform and a developer ecosystem. You simply can’t use whatever idioms and architectures you’re used to from a different platform; to do so is to pollute your current codebase and to damage the productivity of your fellow developers.</p>
<p>在 API 设计中我见到的最普遍的错误是使用<em>其他平台的习惯</em>。API 属于一个平台和一个开发者生态系统。你不能使用你曾经熟悉的与本平台不同的平台的习语和架构，那样做，只会污染你当前的代码，并且降低后继开发者生产力。</p>

<p>Learn your target platform’s conventions before coding. For example, on iOS or OS X, don’t use exceptions for control flow. Name your methods in an appropriate manner (which usually means sufficiently verbose, but should also of course be sufficiently succinct).</p>

Expand Down
4 changes: 2 additions & 2 deletions sitemap.xml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -29,14 +29,14 @@

<url>
<loc>http://Onetaway.github.io/blog/archives/</loc>
<lastmod>2014-09-28T13:48:29+08:00</lastmod>
<lastmod>2014-09-28T14:37:56+08:00</lastmod>
<changefreq>weekly</changefreq>
<priority>0.7</priority>
</url>

<url>
<loc>http://Onetaway.github.io/</loc>
<lastmod>2014-09-28T13:48:29+08:00</lastmod>
<lastmod>2014-09-28T14:37:56+08:00</lastmod>
<changefreq>weekly</changefreq>
<priority>1.0</priority>
</url>
Expand Down

0 comments on commit f0e2cf8

Please sign in to comment.