首页 文章 精选 留言 我的

精选列表

搜索[混元翻译]，共10000篇文章
优秀的个人博客,低调大师

Linux 小知识翻译 - 「架构 续」（arch）

上次，从「计算机的内部构造」的角度解释了架构这个术语。这次，介绍下架构中经常提到的「i386架构」及之后的「i486」，「i586」。 安装Linux的时候，很多人即使不了解但也会经常听到i386架构这个词。因此，会误认为「自己的PC的架构是i386架构的」。现在用i386的人是非常少的。 i386的 i 就是「Intel」的首字母。i386是1985年发布的架构，那么如今还在用i386电脑的人... ...将近20年没有换过电脑了。（这篇文章应该是作者2005年左右写的） 实际上i386的CPU正式名称是「80386」。80386之前是8086和80286，之后还有80486。80386其实就是「80x86」系列CPU中的一种。 这个「80x86」系列，作为「个人电脑」被世界上很多PC所采用。 注:8086之后也有 80186，只不过在PC上用的不多，所以不是那么普遍。 i386是「80x86系列」中第一个32位的CPU。而且，Linux也是在i386上诞生的。 之后，x86系列再次升级，出现了 80486，再之后... ... 实际上官方是不存在 80586 这种型号的CPU的。由于商标的问题，80486之后是「Pentium」（也就是曾经流行的奔腾机），再之后是「Pentium Pro/Pentium II/Pentium III」。 但是，当时比较流行称呼 80x86，所以Pentium被称为「i586」，「Pentium Pro/Pentium II/Pentium III」被称为「i686」。 后来基于Pentium III的Xeon也被包含在i686里面了。之后再发布的各种架构，关于谁是「i786」？有很多争论。（大部分情况下认为Pentium 4是「i786」） 其实，i786和i886这种名称之后几乎没有人使用了。 这里提到的架构都是继承于i386的，「面向i386的OS和应用程序」都能在这些架构上运行。 IA-64之类64位的架构上，面向i386的应用程序有很多是无法运行的，所以把架构「暂且都当成i386」来看的话有点危险， 不过，在面向普通用户的PC上，可以认为面向「i386」的应用程序都能运行。 本文转自wang_yb博客园博客，原文链接：http://www.cnblogs.com/wang_yb/p/3798162.html，如需转载请自行联系原作者
2017-10-19
优秀的个人博客,低调大师

Linux 小知识翻译 - 「X Window系统」

X Window System是给Unix系的OS提供的一套窗口管理软件或者说是组件。X Window System已经成为了在Linux上使用GUI环境的不可或缺的东西了。 X Window System诞生于马萨诸塞州(美国州名)工科大学的研究组，现在主要由X.Org Foundation这个组织来负责开发。目前的版本是「X11」（version 11）。 上面所说的内容可能很多人都知道，但 X Window System 的架构「采用了服务端·客户端模式」这点就不那么广为人知了。正因此点，通过网络来使用X Window System称为可能。 比如，在一台电脑上运行的应用程序，可以通过网络在另一台电脑上远程显示它的画面。 请注意，接下来的内容可能容易混淆。对于 X Window System，用户所使用的电脑上运行的是「X服务器」，通过它再和其它各式各样的「客户端」通信。 也就是说，和大多数的服务端·客户端架构的系统是相反的，「用户操作的是服务端，远程运行的是客户端」。 为什么会这样呢？这是因为 X Window System 的功能是由服务端提供的，而且用户也需要操作这些功能。 对于 X Window System，看着似乎懂了，其实还有很多不懂的。其内容出乎意料的深奥。 本文转自wang_yb博客园博客，原文链接：http://www.cnblogs.com/wang_yb/p/3799235.html，如需转载请自行联系原作者
2017-10-18
优秀的个人博客,低调大师

Docker 中管理数据 【已翻译100%】

到目前我们介绍了一些Docker的基础概念, 知道了如何使用Docker的image， 也知道了如何在多个container间通过网络通讯. 在这章里我们将介绍如何在docker的container内管理数据以及如何在不同的container间共享数据。 我们将介绍两种主要的在docker中管理数据的方法： Data volumes Data volume container Data volumes 一个 data volume 就是一个在一个或者多个container里的特殊用途的目录。它绕过了 Union File System (译者： 这里不确定， 需要研究)为持久化数据、共享数据提供了下面这一些有用的特性： Data volumes 可以在不同的container之间共享和重用数据 对 Data volume 的修改及时生效（译者：data volumn是一个目录， 多个container都挂载这个目录， 具体的可以通过 docker inspect 看 volumne的信息) 对 data volume 修改内容在升级image的时候不会被包括进去 (译者：在docker的整个设计中image是一个无状态的， 这样对升级重用非常有利。而标记状态的数据， 比如数据库的数据， 生产的log之类的应该放到volume里。volume的持久化和恢复在下面有介绍， 是通过文件的形式的， 而不是通过image) Volumes 的持久化直到没有container使用他们 添加数据卷 你可以在docker run 的时候使用 -v 来添加一个 data volume。这个参数在docker run 的时候可以多次使用来添加多个 data volumes。让我们为我们的web application container挂载一个 volume。 $ sudo docker run -d -P --name web -v /webapp training/webapp python app.py 这里一个新的volume会创建到container里的 /webapp. （译者：如果你通过ssh或者通过 -i 登陆到你的container的一个shell里， 使用 ls /webapp 可以验证挂载成功了) 注意: 你也可以在Dockerfile里添加 VOLUME 字段，这样在创建一个新的image的 container是就会自动的创建新的volume. 安装一个目录作为数据卷 使用 -v 不仅能创建一个新的 volume， 还可以把宿主机一个目录mount到container里。 $ sudo docker run -d -P --name web -v /src/webapp:/opt/webapp training/webapp python app.py 这条命令会把本地目录 /src/webapp mount到container里的 /opt/webapp 目录上。用这个方法来测试程序非常方便， 比如我们可以把我们的源代码通过这个方法mount到container里， 修改本地代码后立即就可以看到修改后的代码是如何在container里工作的了。宿主机的目录必须是绝对路径， 如果这个目录不存在docker会为你自动创建。 注意 这里是没法用 Dockerfile实现的， 因为这样的用法有悖于可移植性和共享. 因为本地目录就像他名字告诉我们的， 是和本地相关的， 不一定可以在所有的宿主机上工作.(译者: 鬼知道你在使用image的时候的host是啥样子的） Docker默认设置volume是可读写的，但是我们也可以mount一个目录为只读: $ sudo docker run -d -P --name web -v /src/webapp:/opt/webapp:ro training/webapp python app.py 这里我们同样mount了 /src/webapp 目录， 但是我们加上了 ro 参数， 告诉docker这个volume是只读的. 创建并安装数据卷容器 如果你有一些持久化的数据， 并且想在不同的container之间共享这些数据， 或者想在一些没有持久化的container中使用， 最好的方法就是使用 Data Volumn Container, 在把数据mount到你的container里.(译者：如开篇译者提到的docker的container是无状态的， 也就是说标记状态的数据，例如：数据库数据， 应用程序的log 等等， 是不应该放到container里的， 而是放到 Data Volume Container里, 这点和funcational programming很像， 所以我喜欢把一般的docker container 叫做 functional container用来区分 data volume container ） 让我们创建一个有名字的 Data Volume Container 来共享数据. $ docker run -d -v /dbdata --name dbdata training/postgres 这样做之后就可以通过 --volumes-from 把 /dbdata mount到其他的container里了 $ docker run -d --volumes-from dbdata --name db1 training/postgres 还可以继续共享到另外一个container里 $ docker run -d --volumes-from dbdata --name db2 training/postgres -volumes-from 可以多次使用来 mount 多个conatainer里的多个volumes。 这个操作是链式的， 我们在db1 中通过 --volumes-from mount进来的 volume可以继续被其他container使用 $ docker run -d --name db3 --volumes-from db1 training/postgres (译者: 这里我们不是直接使用 volume container， 而是使用db1 这个functional container 把volume 挂载到另外一个 funcational container上的，所谓的链式就是 dbdata -> db1 -> db3) 如果你把所有mount volumes的container都移除掉， 包括初始化的那个 dbdata container， volume才会被移除掉。通过这个属性可以方便的升级升级数据或者在不同container间migrate数据. 备份、恢复和移植数据卷 Volume的另外一个用处就是备份、恢复和migrate数据。 具体的做法如下，使用 --volumes-from 来创建一个新的container mount这个volume $ sudo docker run --volumes-from dbdata -v $(pwd):/backup ubuntu tar cvf /backup/backup.tar /dbdata 这里我们启动了一个新的container， 从 dbdata 挂载了一个volume。同时挂载了一个本地目录到这个container里。最后我们通过一个 tar命令把 dbdata 里的数据备份到了 /backup 里。命令结束并且停止这个container后我们就在本地得到了一个备份的数据. (译者: 这里使用的 ubuntu container， 就是为了把volume中的数据打包备份到host的某一个目录里。) 备份的数据可以恢复到这个container， 或者其他使用这个volume的container。首先创建一个container $ sudo docker run -v /dbdata --name dbdata2 ubuntu 之后un-tar备份文件到 data volume 里 $ sudo docker run --volumes-from dbdata2 -v $(pwd):/backup busybox tar xvf /backup/backup.tar 你可以使用你喜欢的工具加上上面的技术来自动备份，迁移和恢复数据
2017-06-01
优秀的个人博客,低调大师

[Android]使用MVP解决技术债务（翻译）

以下内容为原创，欢迎转载，转载请注明 来自天天博客：http://www.cnblogs.com/tiantianbyconan/p/5892671.html 使用MVP解决技术债务 原文：https://medium.com/picnic-engineering/tackling-technical-debt-with-mvp-67e805ed5103#.couu0d5i0 免责申明：这篇博客并不是讲关于怎么使用MVP的方式（上帝知道关于这些已经太多了）去写Android代码。而仅仅是我的个人经验，关于怎么转换我们的表现层到MVP架构来帮助我们解决一些累积的技术债务，而且在这个过程中也会帮助我们的app从一个原型转变成一个更具维护性的产品。 任何从事Android工作足够久、项目足够大的开发者最有可能达到一个点，他们面对他们的代码库，觉得应该有更好的实现方案。我们在Picnic也是一样，在Android app开发开始后大约八个月，我们到达了的那一刻，就在我们向公众发布第一个版本的时候。 这一刻正好是在我们app推出的时候这也并不意外。直到那时，我们以一个非常快的速度在前进，不断敲打我们的键盘，从零开始构建一个完整的产品，尝试新的东西，结合用户反馈到我们的app中，在每天的基础上增加和丢弃特性。 为了跟上公司的速度我们砍掉了这里那里的边边角角。这样的工作对我们来说很好，这也是我们能够在这么短的时间内构建这个app的原因之一。但是正如预期那样，最后这些决定的影响开始以技术债务的形式显示出来。幸运的是这些技术债务是在数月之内建立的，在app的性能和稳定性上面并没有任何真正的影响。反而我们是在其它领域开始注意到它： 新功能迭代时间的增加。 新入职的开发者遇到困难 它被证实难以实现自动化测试 整体功能的复杂性在增加 我们已经有了一个很好的想法和一个易于理解的架构，用于网络层、错误处理和app内部模块通信。但是像大多数Android开发者，我们会对把太多的逻辑放进Activity和Fragment中会产生内疚。 旁注：这是Android开发者的共同的问题，而作为开发者需要在黑暗中摸索，因为Google对这个话题保持沉默。我们从它们那里得到的第一个（算是）官方回复是来自Android团队的一个开发者在 Google+ post，说明我们应该把核心的Android API作为一个‘系统框架’，意味着他们会带我们手把手地到达Android核心的组件（Activity, BroadcastReceiver, Service 和 ContentProvider）。之后我们做什么都是看我们自己了。而且就在最近，Google终于提供了一系列的例子用来解决关于怎么构建一个Android app的共同问题，它着重于MVP。尽管只是beta，但是它可以在这里查看：Android Architecture Blueprints。 无论如何，这其实是一件好事，因为这意味着我们可以自由地去实验任何我们喜欢的方式，而不是被强制在一个平台遵循一个特定的模式。 现在讲回我们的故事… 除非你处在Android开发世界的远古时期，你应该会注意到表现层架构是现在的热门。关于最好的方式是什么，每个人甚至连他妈妈似乎都有自己的观点。工作中标准的Android方式（类似MVC），到MVP，到通过data-binding的MVVM，所有的方式都沿用了 Uncle Bob 的 clean architecture。每一种方式围绕赞成或者反对的意见都有一些有趣的讨论，但是有一件事我们要明确知道，那就是我们应该避免喝Kool-Aid（译者注：这里是比喻，表示非常愚昧地接受信奉某种观点或者思想）和期望其中一种是银色子弹（译者注：这里是比喻为具有极端有效性的解决方法）然后永远解决所有问题。 当在考虑怎么去重构我们的表现层时，我们已经有近一年的代码库的积累，我们很清楚我们的缺陷在哪里，然后我们需要使用一个新的实现（以上主要表示一些能够解决我们的技术债务的点）来达到我们的目标。我们在虚拟的项目中试玩了一些，体验了各种方法的不同之处，然后最终决定使用MVP。从它的核心来说，MVP本身仅仅是一个概念，而Android框架，根据设计，并不强制任何模式，我们可以自由地选择实际的实现细节。 在Android团队中，首先我们是不过度工程的信徒，让代码随着时间的推移自然地发展，而不是过早地在试图为自己不可预知的未来做准备的抽象之上增加抽象。正因为这个原因，我们选择另一风味的MVP，使得可以最低限度地保持我们的抽象层次。在代码级别，这意味着有一个单独的接口来表示View。所有其它的组件都是具体的类。你可能会问自己，怎么会只有View使用接口？考虑到我们迫切的需要，这是真正受益于这样的接口的唯一的组件，因为我们实际上有不同的具体的Views来共享相同的接口。所以在我们的案例中，这里的一个接口将被允许我们去重用Presenters。一些MVP实现建议给所有组件（M，V和P）设置接口。尽管这样会工作得很完美，但是我们在较早的阶段并不提倡，因为添加之后的成本是代码可读性和维护性，尤其是当我们考虑到新入职对MVP陌生的初级开发者的时候，好处超过面向接口编程的方式。 相比其他，MVP实现是非常标准的。View（Activity，Fragment或者一个自定义View）负责创造和维护Presenter，而Presenter处理各种业务相关的逻辑（数据获取，存储，格式化等等），然后根据需要通过更新UI回调到View。在我们的案例中，数据层已经是相当模块化了，构造用于表示数据模型的POJOs，以及一个预先存在的控制层用于处理网络通信。 这是一个非常标准的MVP设置，也因为它很简单，我们可以在几周的时间内替换几乎我们的所有的UI代码。因为我们已经存在独立的数据层来处理所有与后端的API交互，所以真正需要重构的只是Views和Presenters的交互。 在重构的过程中，我们也学习了一些可能会派得上用场的东西： 生命周期：因为Presenter是View创建的，我们需要确保完全地理解View的生命周期，特别是因为它将最有可能去处理状态更新和异步数据。举个例子，每一个Presenter应该在View destroyed的情况下有一个取消异步任务的方式，或者应该在用户暂停或者恢复视图事件时重置到原始状态等等。最后但同样重要的是，当View已经被销毁，试图从Presenter去更新View元素，始终需要注意可怕的NPEs。 保持Views尽可能地愚蠢：我们的Views应该不再包含任何业务相关的逻辑。它应该只包含Android框架inflate和设置View的这些最低限度的东西。任何用户交互应该派发到Presenter。根据经验，如果你的views有任何其它方法去更新UI元素或者响应用户触发的事件，那么你可能应该去检查它们的实现。 保持Presenter尽可能地纯粹：这一点，我们的意思时你应该尽可能地避免有Android相关的代码在你的presenters中。为这些组件编写纯粹的单元测试，而不需要使用其它如Robolectric等测试框架，这明显地得到了简化。这明显说起来比做起来容易得多，因为你终归会在某些地方遇到这种情况，举个例子，你将需要有一个Context的引用用来比如数据加载、访问strings文件等等。 结论 那么，说了那么多，最终的结论是什么呢？总的来说，我很高兴使用了MVP。它一定程度上帮我们解决了我们快速开发所累积的技术债务，然后，我们准备了更多来针对第二阶段的开发。 一些值得一提的事情： 测试数：在重构之前，测试的数量用两只手都可以数得过来。这是一个巨大的任务来针对包含了所有逻辑如执行数据解析、格式化、网络请求、错误处理和管理自己的生命周期的Activity编写测试。仅思考如果在这些条件下编写测试就足以让我们去寻找其它的方式了。一旦转换我们的第一份代码到MVP，对此编写测试就变得碎片化了。通过一个清晰的合同明确什么View能够处理，我们可以把自己的代码与Android UI框架隔离开，然后仅仅测试实际调用的是否是正确的方法，并给出每个测试场景。现在实际的业务相关逻辑被放置在Presenters中，因为它们绝大多数都不需要有Android OS相关的认知（或者小部分相关的可以被mocked），我们也可以针对它们编写非常有效率的单元测试，因此，在过去几个月里，我们的测试用例从原来的10增加到900，而且还在增长中。 可预见性：这个是有一点软度量，但是非常强大的一点。针对UI，我们选择并坚持一个通用的模式，我可以在代码库中获得可预见的好处。这意味着，无论是哪种开发者眼里的UI元素（Activity，Dialog，Fragment等等），如果理解其中一个怎么工作，那也就能理解所有怎么工作。打开一个就算不是你写的文件也不再会遇到让你觉得惊喜的东西了。明确规定职责，每一单个的UI组件都遵循相同的明确的模式。让新入职的新开发者从第一天起就是高效的，这是非常宝贵的。 我们别忘记MVP并不只是用于表现层，但是作为前端开发人员，这里花费了我们太多的时间。所以努力去寻找一个解决方案来给我们带来更好的可预见性和在新的开发者加入我们的时候也能让我们快速迭代是值得的。经过全面的考虑，我们可以有把握地说MVP是可以帮助我们达到这个目标的一个重要的里程碑。 P.S. 如果你仍然渴望看到一些源代码，这里有一个我们MVP实现‘忘记密码’用例的剥离下来的版本，展示MVP组件与用户的交互，用户点击‘重置密码’按钮进入他们的邮件地址（为保持代码的简洁，Android模版代码已经移除）： // BasePresenter.java (Base class for all our Presenters) public abstract class BasePresenter<V> { private WeakReference<V> mView; public void bindView(@NonNull V view) { mView = new WeakReference<>(view); } public void unbindView() { mView = null; } public V getView() { if (mView == null) { return null; } else { return mView.get(); } } protected final boolean isViewAttached() { return mView != null && mView.get() != null; } } // IForgotPasswordView.java (view interface) public interface IForgotPasswordView { void showLoading(); void hideLoading(); void setEmailText(String email); void showEmailNotValidError(); void showPasswordRequestOk(String message); void showPasswordRequestFail(); } // ForgotPasswordFragment.java (view implementation) public class ForgotPasswordFragment implements IForgotPasswordView, View.OnClickListener { // Triggered by the user clicking a button public void onResetPasswordClick() { String email = mEmailEditText.getText().toString(); // Forward all logic to the Presenter mPresenter.requestPasswordChange(email); } } // ForgotPasswordPresenter.java public class ForgotPasswordPresenter extends BasePresenter<IForgotPasswordView> { public void requestPasswordChange(String email) { if (!Utils.isEmailValid(email)) { // Make sure the view is still alive before trying to access it if(isViewAttached()) { getView().showEmailNotValidError(); } } else { requestPasswordChangeAsync(email); } } private void requestPasswordChangeAsync(String email) { // Update the view's UI elements if(isViewAttached()) { getView().hideKeyboard(); getView().showLoading(); // Call our API (results are posted back on an EventBus) api.forgotPassword(email); } } // Subscription to the event bus @Subscribe public void onEvent(final Event event) { if (isViewAttached()) { // Update the view's UI elements getView().hideLoading(); switch (event.getType()) { case FORGOT_PASSWORD_OK: getView().showPasswordRequestOk((String) event.getData()); break; case FORGOT_PASSWORD_FAILED: getView().showPasswordRequestFail(); break; } } } }
2016-09-20

资源下载

更多资源
腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

时间: 2026-08-21 大小: 1MB 下载: 10次
Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

时间: 2026-09-24 大小: 189MB 下载: 9次
Spring

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

时间: 2026-08-21 大小: 5MB 下载: 2次
Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能，例如代码缩略图，Python的插件，代码段等。还可自定义键绑定，菜单和工具栏。Sublime Text 的主要功能包括：拼写检查，书签，完整的 Python API ， Goto 功能，即时项目切换，多选择，多窗口等等。Sublime Text 是一个跨平台的编辑器，同时支持Windows、Linux、Mac OS X等操作系统。

时间: 2026-08-21 大小: 9.84MB 下载: 40次
热门标签
DeepSeek Jdk25 OpenAi HarmonyOS6 Nacos3 SpringBoot4 SpringCloud Docker Kubernetes Service Mesh Redis Gemini3 Rocky

欢迎您来访！

登录后，您将获得更多功能！
热门文章
联系我们

有任何问题或合作意向欢迎联系我们

Email: 99873273@qq.com

QQ: 99873273

用户登录
用户注册