coffee

""" 类定义： 关键字：class 语法： class 类名： # 类里面的代码 类名的命名规范：遵循标识符的命名规范，风格采用大驼峰命名法（每个单词的第一个字母大写） 通过类创建对象： 对象 = 类名() """ class Cat: pass class MyTestClass: pass # 关于对象：有人叫对象，也有人叫实例 # 通过类创建对象(实例化对象) kitty = Cat() print(kitty, id(kitty)) coffee = Cat() print(coffee, id(coffee)) 类属性和实例属性 """ 这一类事物拥有的共同特征，我们通常会定义为类属性 类属性：在类里面直接定义的变量，叫做类属性 # 通过对象访问类属性：对象名.属性名 # 通过类访问类属性：类名.属性名 实例属性：每个对象的属性值都有可能不一样，就应该定义为实例属性（对象属性） 实例属性的定义：对象.属性名 = 属性值 """ print("------------------类属性--------------------") class Cat: leg = "四条腿" tail = "长尾巴" kitty = Cat() coffee = Cat() # 通过对象访问类属性：对象名.属性名 print(kitty.leg) print(coffee.leg) #

如何在 node.js 中使用模块的本地版本。 例如，在我的应用中，我安装了coffee-script： npm install coffee-script 这会将它安装在 ./node_modules ，而coffee命令在 ./node_modules/.bin/coffee 。 当我位于项目的主文件夹中时，是否可以运行此命令？ 我猜我在寻找与bundler中的 bundle exec 类似的东西。 基本上，我想指定一个咖啡脚本的版本，参与该项目的每个人都应该使用。 我知道我可以添加 -g 标志以在全球范围内安装它，这样咖啡在任何地方都可以正常工作，但是如果我想每个项目使用不同版本的咖啡怎么办？ #1楼 更新 ：正如Seyeong Jeong在下面的答案中指出的那样，从npm 5.2.0开始，您可以使用 npx [command] ，这更加方便。 5.2.0之前的版本的旧答案 ： 推杆的问题 ./node_modules/.bin 进入PATH的地方是，它仅在当前工作目录是项目目录结构的根目录（即 node_modules 的位置） node_modules 与您的工作目录无关，您可以使用以下命令获取本地安装的二进制文件的路径： npm bin 要执行与您在项目目录层次结构中的位置无关的本地安装的 coffee 二进制文件，可以使用此bash构造 PATH=$(npm bin)

如果饿了就吃，困了就睡，渴了就喝，人生就太无趣了 1 定义 1.1 概念 在一个方法中定义一个算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以在改变算法结构的情况下，重新定义算法中的某些步骤。 1.2 类图 如图1，抽象类 AbstractClass 中的 templateMethod 方法定义了算法框架，将算法分步骤实现，每一步的定义为抽象方法 primitiveOperation1() 和 primitiveOperation2() 。由实现的 AbstractClass 的实例类进行重写该静态方法。 2 例子（咖啡店） 如图2：做咖啡的步骤，分为四步：烧水 boilWater() ,沸水冲咖啡 boilCoffeeGrinds() ,倒进杯子 pourInCup() ,加糖加奶 addSugarAndMilk() 。 如图3：做茶的步骤，也分为四步：烧水 boilWater() ,沸水泡茶包 steepTeaBag() ,倒进杯子 pourInCup() ,加柠檬 addLemon() 。 可以发现这两种做法有两个相同的步骤：烧水 boilWater() 和倒进杯子 pourInCup() 。 2.1 改进设计 如图4：设计一个抽象类 CoffeineBeverage ,将刚刚发现的共同点抽象出来在该类中实现，将 prepareRecipe() 方法作为抽象方法。

模板方法（Template Method） Intent 定义算法框架，并将一些步骤的实现延迟到子类。 通过模板方法，子类可以重新定义算法的某些步骤，而不用改变算法的结构。 Class Diagram Implementation 冲咖啡和冲茶都有类似的流程，但是某些步骤会有点不一样，要求复用那些相同步骤的代码。 public abstract class CaffeineBeverage { final void prepareRecipe ( ) { boilWater ( ) ; brew ( ) ; pourInCup ( ) ; addCondiments ( ) ; } abstract void brew ( ) ; abstract void addCondiments ( ) ; void boilWater ( ) { System . out . println ( "boilWater" ) ; } void pourInCup ( ) { System . out . println ( "pourInCup" ) ; } } public class Coffee extends CaffeineBeverage { @Override void brew ( ) { System . out . println ( "Coffee.brew" ) ;

　　原文链接： http://survivejs.com/webpack_react/webpack_compared/ 开始正文 　　当你把Webpack放到过往历史中你就会很好地理解为什么它的方法是如此的有力。在早些时候，它的能力对于仅仅把一些脚本连接在一起是足够的。然而时光变迁，现在分布你的Javascript代码可以是个复杂的奋斗者号。 　　 SPA（单页应用）的崛起 　　 随着单页应用（SPAs,single page application）的崛起，这个问题已经逐渐凸显出来。它们倾向于使用非常多笨重的库。你最不想看到的应该是一次性地把它们全部加载出来。其实有很多很好的解决办法，Webpack与它们中的很多都可以紧密配合使用。 　　得益于Node.js的火爆，Node.js的包管理器npm提供了许多环境。在之前，npm还难以让开发人员去使用这些依赖。现在，随着npm已经因为前端开发而变得广为熟知，环境已经发生了很多变化。依赖管理也是越来越简单了。 　　 任务运行工具和打包工具 　　从历史上来讲，已经有了很多的构建系统。 Make 可能是最广为数值的，并且仍然是个可行的选项。为了让工作简单一些，专业的任务运行工具，类似于Grunt和Gulp出现了。通过npm可获得的插件使得这些任务运行工具变得非常好用。 　　任务运行工具已经是高水准中的非常棒的工具了

Spring Boot 中的 RestTemplate 在springboot中，有两种方式去配置： 自己new 新建一个RestTemplate实例作为bean 放到容器当中 springboot 给我们提供了一个RestTemplateBuilder，通过RestTemplateBuilder.build()去获得一个RestTemplate RestTemplate中的常用方法： GET请求： getForObject() / getForEntity() POST请求： postForObject() /postForEntity() PUT请求： put() DELETE请求： delete() 构造 URI UriComponentsBuilder 构造 URI ServletUriComponentsBuilder 构造相对于当前请求的 URI MvcUriComponentsBuilder 构造指向 Controller 的 URI 常用构造方式： URI uri = UriComponentsBuilder . fromUriString ( "http://localhost:8080/hotels/{hotel}?q={q}" ) . build ( "west" , "123" ) ; URI uri = UriComponentsBuilder .

Spring MVC 的异常解析 核心接口 • HandlerExceptionResolver 实现类 • SimpleMappingExceptionResolver • DefaultHandlerExceptionResolver • ResponseStatusExceptionResolver • ExceptionHandlerExceptionResolver Spring MVC 的异常解析HandlerExceptionResolver这个核心接口和其他几个实现类完成的，ResponseStatusExceptionResolver 处理 的是带ResponseStatus注解的一些方法和类，我们可以在异常类上面添加ResponseStatus这个注解，以表明在抛出这个异常类的时候，我的http响应码是什么。 DispatcherServlet如何处理异常 首先进入DispatcherServlet，找到doService方法。在doService方法中，在处理doDispatch时，我们进入doDispatch，在doDispatch中，我们可以看到，如果我们抛出异常，这些异常会被捕获住，然后，放在dispatchException当中，使用processDispatchResult处理结果，进入processDispatchResult，在处理结果的时候

在日常的工作生活中，有这些场景:（还有其他生活场景） 去银行办理业务一般会经过四个流程：取号、排队、办理业务以及办理完业务后对工作人员进行评分等流程，其中取号、排队和对银行工作人员进行评分的业务对每个顾客都是同样的，可以在父类中实现；但是办理的业务每个人是不同的，取款、存款或者转账等，个人的具体业务可以在子类中实现。 一个人每天起床、吃饭、做事及睡觉等，其中做事情因为每个人不同而异，因此我们可以将起床，吃饭，以及睡觉定义为父类，做事定义为子类等 简历模板，论文模板，word模板等都可以定义为父类，每个人简历，论文，word模板又不同，可以定义为子类。 以下介绍 模板方法 模式将解决上述问题。 一 定义 模板方法 (Template Method)模式定义为：定义了一个操作中的算法骨架，而将算法的部分步骤延迟到子类，使得子类可以不改变该算法结构的情况下重新定义该算法的某些特定的步骤。是一种 类行为型 模式。 二 特点 模板方法模式的优缺点如下 优点 封装不变部分，扩展可变部分。不变部分的算法封装到父类中去实现，而把可变部分算法由子类去继承实现，便于子类扩展。 父类中提取了公共的代码部分，便于代码复用。 部分的方法是由子类实现，子类拓展相应的功能，符合了开闭原则。 缺点 对每个不同的实现都需要一个子类，导致了类的个数增加，系统变得庞大。 父类中的抽象方法是由子类实现

最近移植coffee fs, 为了了解coffee细节，方便调试，因此在pc上编译coffee。 考虑到开虚拟机麻烦，费资源。因此安装Cygwin,在Cygwin下面编译。 1. Create cfs-coffee folder Create folder example-coffee/ in path contiki-2.5/examples/ Copy example-shell/ file to example-coffee/ Rename example-shell.c to example-coffee.c in the example-coffee/ 2. Modfiy Makefile Modify example-coffee/Makefile 1 CONTIKI_PROJECT = example - coffee 2 all : $(CONTIKI_PROJECT) 3 4 APPS = serial - shell 5 CONTIKI = . . / . . 6 7 include $(CONTIKI) / Makefile . include 8 Modfiy contiki-2.5/platform/native/Makefile.native 1 CONTIKI_TARGET_SOURCEFILES = contiki - main . c clock

一 基本概念 helm 类似于Linux系统下的包管理器，如yum/apt等，可以方便快捷的将之前打包好的yaml文件快速部署进kubernetes内，方便管理维护。 helm：一个命令行下客户端工具，主要用于kubernetes应用chart的创建/打包/发布已经创建和管理和远程Chart仓库。 Tiller：helm的服务端，部署于kubernetes内，Tiller接受helm的请求，并根据chart生成kubernetes部署文件（helm称为release），然后提交给 Kubernetes 创建应用。Tiller 还提供了 Release 的升级、删除、回滚等一系列功能。 Chart： helm的软件包，采用tar格式，其中包含运行一个应用所需的所有镜像/依赖/资源定义等，还可能包含kubernetes集群中服务定义 Release：在kubernetes中集群中运行的一个Chart实例，在同一个集群上，一个Chart可以安装多次，每次安装均会生成一个新的release。 Repository：用于发布和存储Chart的仓库 简单来说： helm的作用：像centos7中的yum命令一样，管理软件包，只不过helm这儿管理的是在k8s上安装的各种容器。 tiller的作用：像centos7的软件仓库一样，简单说类似于/etc/yum.repos.d目录下的xxx