[ 英語發燒句 ] Part-40

213. "別以大欺小" 

A. That naughty boy is being mean to the children younger than he is.
B. We should tell him to pick on someone his own size.

214. "真高興聽到這個消息" 

A. I hear we're getting an extra couple of days of paid leave this year.
B. Really, That sure is music to my ears!

215. "你近視幾度" 

A. What's your prescription?
B. I'm -3 in my left eye and -2.5 in my right eye.

Note. 也可用 What's the prescription on your glasses? 名詞 prescription 指 "處方; 藥方", 在此指眼科醫師為矯正病人近視所診斷出的度數. 

216. "五十步笑百步" 

A. I think you watch too much television.
B. Well, that the pot calling the kettle black. You've been watching it with me all day!

217. "他還真能掰" 

A. Jim says he is going to become the salesman of the year at our company.
B. Well, he sure talks a good game, but I'm not sure if his sales number will beat mine.

218. "還不都一樣" 

A. Paul said he quit his job, but I think he was fired.
B. Same difference. He doesn't work at that company anymore.

[Scala 小學堂] Scala Gossic : 起步走 - 常用物件 (Array)

轉載自 這裡 
前言 : 
Scala 是一個可直譯、編譯、靜態、運行於 JVM 之上、可與 Java 互操作、融合物件導向編程特性與函式編程風格的程式語言. 從一些簡單的語法開始，了解 Scala 的許多特性，所以就算是起步走，東西也夠多了. 簡單的小程式可以使用 scala 指令，編譯的事就交給 scalac，編譯想快點就用 fsc. (Scala 官網), 在變與不變之間，先體會 Scala 更多特性. 

Array : 
在 Scala 中，如果要建立陣列，可以使用 Array 類別，建立陣列時，須指定陣列後存放的元素型態. 如以下建立長度為 5，內含Int、Double、Boolean、String等指定型態的陣列 : 

scala> val arr1 = new Array[Int](5)
arr1: Array[Int] = Array(0, 0, 0, 0, 0)

scala> val arr2 = new Array[Double](5)
arr2: Array[Double] = Array(0.0, 0.0, 0.0, 0.0, 0.0)

scala> val arr2 = new Array[Char](5)
arr2: Array[Char] = Array(?, ?, ?, ?, ?)

scala> val arr2 = new Array[Boolean](5)
arr2: Array[Boolean] = Array(false, false, false, false, false)

scala> val arr2 = new Array[String](5)
arr2: Array[String] = Array(null, null, null, null, null)

在建立陣列之後，如果內含元素是整數，則預設值為 0，浮點數則預設值為 0.0，字元則預設值為空字元（字元編碼為0的字元），布林值預設為 false，其它型態則預設值為 null（與 Java 的陣列類似）. 如果要多維陣列，基本上是以一維陣列來摸擬，例如要建立二維陣列 : 

scala> val arr=new Array[Array[Int]](5,5)
warning: there were deprecation warnings; re-run with -deprecation for details
arr: Array[Array[Int]] = Array(Array(0, 0, 0, 0, 0), Array(0, 0, 0, 0, 0), Array(0, 0, 0, 0, 0), Array(0, 0, 0, 0, 0), Array(0, 0, 0, 0, 0))

如果要存取陣列，必須指定陣列索引，與其它語言存取陣列慣例不同的是，在 Scala 中，指定陣列索引時是使用 () 而非 []，例如 : 

- Array1.scala 代碼 :

view plaincopy to clipboardprint?

1. val arr = new Array[Int](3)  
2. arr(0) = 10  
3. arr(1) = 20  
4. arr(2) = 30  
5. println(arr(0)) // 顯示 10  
6. println(arr(1)) // 顯示 20  
7. println(arr(2)) // 顯示 30  

事實上，當你使用 arr(0) = 10 這樣的指定方式時，Scala 會將之轉換為呼叫陣列的 update() 方法，而你用 arr(0) 的方式要取得指定索引的元素時，Scala 會將之轉換為呼叫 apply 方法。以下是個簡單的驗證方式 : 

- Array2.scala 代碼 :

view plaincopy to clipboardprint?

1. val arr = new Array[Int](3)  
2. arr.update(0, 10)  
3. arr.update(1, 20)  
4. arr.update(2, 30)  
5. println(arr.apply(0)) // 顯示 10  
6. println(arr.apply(1)) // 顯示 20  
7. println(arr.apply(2)) // 顯示 30  

在 Scala 中，指定索引進行存取時使用 () 而不是 []，其實是為了語法的一致性。這種在 () 中指定索引進行存取的方式，並非只有陣列專屬，只要是有提供 update() 或 apply() 方法的物件，其實都可以使用這樣的存取方式，像是在 String 也曾經使用過這樣的方式 : 

view plaincopy to clipboardprint?

1. val str = "Scala"  
2. println(str(0)) // 顯示 'S'   
3. println(str(1)) // 顯示 'c'   
4. println(str(2)) // 顯示 'a'   
5. println(str(3)) // 顯示 'l'   
6. println(str(4)) // 顯示 'a'  

如果你要在建立陣列時，一併指定元素值，則可以直接使用以下的語法 : 

- Array3.scala 代碼 :

view plaincopy to clipboardprint?

1. val arr = Array(10, 20, 30)  
2. for(i <- nbsp="" span="">0 until arr.length) {  
3.     println(arr(i))  
4. }  

其實在 單例物件 中有介紹過了，Array(10, 20, 30) 這樣的寫法是個語法蜜糖，Scala 會將之轉換為呼叫 scala.Array 伴侶物件的 apply 方法，這個方法會傳回含指定元素的陣列。以下這個程式可以驗證這個說法 : 

- Array4.scala 代碼 :

view plaincopy to clipboardprint?

1. val arr = Array.apply(10, 20, 30)  
2. for(i <- arr="" nbsp="" span="">
3.     println(i)  
4. }  

上面這個範例程式，同時示範了迭代陣列的另一種方式，每一次迭代，都會將 arr 的元素取出指定給i。事實上，陣列提供 foreach 方法可以使用，上面的程式你可以這麼撰寫 : 

- Array5.scala 代碼 :

view plaincopy to clipboardprint?

1. val arr = Array(10, 20, 30)  
2. arr.foreach((i: Int) => println(i))  

在 簡單的函式 中有介紹過，foreach中是函式字面寫法，執行時期會傳入函式物件，每次取出一個元素，就會呼叫函式物件。你可以利用類型推斷，讓這個範例更簡短一些 : 

- Array6.scala 代碼 :

view plaincopy to clipboardprint?

1. val arr = Array(10, 20, 30)  
2. arr.foreach(i => println(i))  

arr.foreach(i => println(i)) 其實是 arr.foreach((i) => println(i)) 簡寫，因為只有一個參數，所以括號可以省略。事實上，就上面這個例子來說，最簡短的寫法是 : 

- Array7.scala 代碼 :

view plaincopy to clipboardprint?

1. val arr = Array(10, 20, 30)  
2. arr.foreach(println)  

事實上，foreach 中是 部份套用函式（Partially applied function）的寫法，這之後還會詳述. 像 foreach 這種傳入函式物件執行某個操作的作法，在 Scala 相當常見。例如陣列的 filter 方法，可以傳入一個會運算出布林值的函式物件，根據真或假決定結果要包括哪些元素，例如 : 

- Array8.scala 代碼 :

view plaincopy to clipboardprint?

1. val arr = Array(10, 20, 30, 40, 50, 60)  
2. arr.filter(x => x > 30).foreach(println)  

事實上，上面這個程式可以使用佔位字元語法（Placeholder syntax）撰寫為以下的方式 : 

- Array9.scala 代碼 :

view plaincopy to clipboardprint?

1. val arr = Array(10, 20, 30, 40, 50, 60)  
2. arr.filter(_ > 30).foreach(println) // 逐行顯示 40、50、60  

_ 作為佔位字元，就目前來說，你可以將看它看作是填充欄位，每一次取得的元素值將值入這個欄位（其實完整的語法應該是 (_ : Int) > 30，不過由於利用了類型推斷，所以可以推斷出_應該是 Int，因此可以寫為 _ > 30，佔位字元語言之後還會詳述）. 
類似地，如果你不僅是想過濾，還想對元素作某些運算後傳回的話，則可以使用 map 方法，例如將每個元素加 1 後傳回新陣列 : 

- Array10.scala 代碼 :

view plaincopy to clipboardprint?

1. val arr = Array(10, 20, 30)  
2. arr.map(_ + 1).foreach(println) // 逐行顯示 11、21、31  

陣列可以串接，不過不是使用 +，而是使用 ++（這是 Array 上定義的方法），這會將兩個陣列的元素取出，建立一個新陣列後傳回。例如 : 

scala> val arr1 = Array(10, 20, 30)
arr1: Array[Int] = Array(10, 20, 30)

scala> val arr2 = Array(40, 50, 60)
arr2: Array[Int] = Array(40, 50, 60)

scala> val arr3 = (arr1 ++ arr2)
arr3: Array[Int] = Array(10, 20, 30, 40, 50, 60) 
scala> arr3.foreach(x => print(x + " ")); println()
10 20 30 40 50 60

如果你要比較兩個陣列的內含值是否相同，由於要逐一比對陣列中每個陣列的元素物件內含值，所以不能直接使用 == 比較，而要使用 deepEquals 方法。例如 : 

scala> val arr1 = Array(10, 20, 30)
arr1: Array[Int] = Array(10, 20, 30)

scala> val arr2 = Array(10, 20, 30)
arr2: Array[Int] = Array(10, 20, 30)

scala> arr1 == arr2
res1: Boolean = false

scala> arr1 deepEquals arr2
warning: there were 1 deprecation warnings; re-run with -deprecation for details
res2: Boolean = true

scala> arr1.deep
res3: IndexedSeq[Any] = Array(10, 20, 30)

scala> arr2.deep
res4: IndexedSeq[Any] = Array(10, 20, 30)

scala> arr1.deep.equals(arr2.deep)
res5: Boolean = true

Supplement 
* Tutorialspoint - Scala Arrays

[ 文章收集 ] Visualizing Docker Containers and Images

Source From Here 

Introduction 
This post is meant as a Docker 102-level post. If you are unaware of what Docker is, or don't know how it compares to virtual machines or to configuration management tools, then this post might be a bit too advanced at this time. This post hopes to aid those struggling to internalize the docker command-line, specifically with knowing the exact difference between a container and an image. More specifically, this post shall differentiate a simple container from arunning container. 
 

I do this by taking a look at some of the underlying details, namely the layers of the union file system. This was a process I undertook for myself in the past few weeks, as I am relatively new to the docker technology and have found the docker command-lines difficult to internalize. 

Tangent: In my opinion, understanding how a technology works under the hood is the best way to achieve learning speed and to build confidence that you are using the tool in the correct way. Often a technology is released with a certain breathless and hype that make it difficult to really understand appropriate usage patterns. More specifically, technology releases often develop an abstraction model that can invent new terminologies and metaphors that might be useful at first, but make it harder to develop mastery in latter stages.

A good example of this is Git. I could not gain traction with Git until I understood its underlying model, including trees, blobs, commits,tags, tree-ish, etc. I had written about this before in a previous post, and still remain convinced that people who don't understand the internals of Git cannot have true mastery of the tool.

Image Definition 
The first visual I present is that of an image, shown below with two different visuals. It is defined as the "union view" of a stack of read-only layers. 

On the left we see a stack of read-layers. These layers are internal implementation details only, and are accessible outside of running containers in the host's file system. Importantly, they are read-only (or immutable) but capture the changes (deltas) made to the layers below. Each layer may have one parent, which itself may have a parent, etc. The top-level layer may be read by a union-ing file system (AUFS on my docker implementation) to present a single cohesive view of all the changes as one read-only file system. We see this "union view" on the right. 

If you want to see these layers in their glory, you might find them in different locations on your host's files system. These layers will not be viewable from within a running container directly. In my docker's host system I can see them at /var/lib/docker in a subdirectory called aufs. 

Container Definition 
A container is defined as a "union view" of a stack of layers the top of which is a read-write layer. 


I show this visual above, and you will note it is nearly the same thing as an image, except that the top layer is read-write. At this point, some of you might notice that this definition says nothing about whether this container is running, and this is on purpose. It was this discovery in particular that cleared up a lot of confusion I had up to this point. 

Takeaway: A container is defined only as a read-write layer atop an image (of read-only layers itself). It does not have to be running.

So if we want to discuss containers running, we need to define a running container. 

Running Container Definition 
A running container is defined as a read-write "union view" and the the isolated process-space and processes within. The below visual shows the read-write container surrounded by this process-space. 


It is this act of isolation atop the file system effected by kernel-level technologies like cgroups, namespaces, etc that have made docker such a promising technology. The processes within this process-space may change, delete or create files within the "union view" file that will be captured in the read-write layer. I show this in the visual below: 
 

To see this at work run the following command: docker run ubuntu touch happiness.txt. You will then be able to see the new file in the read-write layer of the host system, even though there is no longer a running container (note, run this in your host system, not a container): 

# find / -name happiness.txt
/var/lib/docker/aufs/diff/860a7b...889/happiness.txt

Image Layer Definition 
Finally, to tie up some loose ends, we should define an image layer. The below image shows an image layer and makes us realize that a layer is not just the changes to the file system. 
 

The metadata is additional information about the layer that allows docker to capture runtime and build-time information, but also hierarchical information on a layer's parent. Both read and read-write layers contain this metadata. 
 

Additionally, as we have mentioned before, each layer contains a pointer to a parent layer using the Id (here, the parent layers are below). If a layer does not point to a parent layer, then it is at the bottom of the stack. 


Metadata Location: 

At this time (and I'm fully aware that the docker developers could change the implementation), the metadata for an image (read-only) layer can be found in a file called "json" within /var/lib/docker/graph at the id of the particular layer:
/var/lib/docker/graph/e809f156dc985.../json
where "e809f156dc985..." is the elided id of the layer.

The metadata for a container seems to be broken into many files, but more or less is found in /var/lib/docker/containers/ where is the id of the read-write layer. The files in this directory contain more of the run-time metadata needed to expose a container to the outside world: networking, naming, logs, etc.

Tying It All Together 
Now, let's look at the commands in the light of these visual metaphors and implementation details. 

The 'docker create' command adds a read-write layer to the top stack based on the image id. It does not run this container. 


The command 'docker start' creates a process space around the union view of the container's layers. There can only be one process space per container. 


One of the first questions people ask (myself included) is "What is the difference between 'docker start' and 'docker run'. You might argue that the entire point of this post is to explain the subtleties in this distinction. 



As we can see, the docker run command starts with an image, creates a container, and starts the container (turning it into a running container). It is very much a convenience, and hides the details of two commands. 
Tangent: 

Continuing with the aforementioned similarity to understanding the Git system, I consider the 'docker run' command to be similar to the 'git pull'. Like 'git pull' (which is a combination of 'git fetch' and 'git merge') the 'docker run' is a combination of two underlying commands that have meaning and power on their own. In this sense it is certainly convenient, but potentially apt to create misunderstandings.

The command 'docker ps' lists out the inventory of running containers on your system. This is a very important filter that hides the fact that containers exist in a non-running state. To see non-running containers too, we need to use the next command. 

The command 'docker ps -a' where the 'a' is short for 'all' lists out all the containers on your system, whether stopped or running. 


The 'docker images' command lists out the inventor of top-level images on your system. Effectively there is nothing to distinguish an image from a read-only layer. Only those images that have containers attached to them or that have been pulled are considered top-level. This distinction is for convenience as there are may be many hidden layers beneath each top-level read-only layer. 


This command 'docker images -a' shows all the images on your system. This is exactly the same as showing all the read-only layers on the system. If you want to see the layers below one image-id, you should use the 'docker history' command discussed below. 


The command 'docker stop' issues a SIGTERM to a running container which politely stops all the processes in that process-space. What results is a normal, but non-running, container. 


The command 'docker kill' issues a non-polite SIGKILL command to all the processes in a running container. 


Unlike 'docker stop' and 'docker kill' which send actual UNIX signals to a running process, the command 'docker pause' uses a special cgroups feature to freeze/pause a running process-space. The rationale can be found here:https://www.kernel.org/doc/Documentation/cgroups/freezer-subsystem.txt, but the short of it is that sending a Control-Z (SIGTSTP) is not transparent enough to the processes within the process-space to truly allow all of them to be frozen. 


The command 'docker rm' removes the read-write layer that defines a container from your host system. It must be run on stopped containers. It effectively deletes files. 


The command 'docker rmi' removes the read-layer that defines a "union view" of an image. It removes this image from your host, though the image may still be found from the repository from which you issued a 'docker pull'. You can only use 'docker rmi' on top-level layers (or images), and not on intermediate read-only layers (unless you use -f for 'force'). 

The command 'docker commit' takes a container's top-level read-write layer and burns it into a read-only layer. This effectively turns a container (whether running or stopped) into an immutable image. 

The 'docker build' command is an interesting one as it iteratively runs multiple commands at once. 

We see this in the above visual which shows how the build command uses the FROM directive in the Dockerfile file as the starting image and iteratively 1) runs (create and start) 2) modifies and 3) commits. At each step in the iteration a new layer is created. Many new layers may be created from running a 'docker build'. 

The 'docker exec' command runs on a running container and executes a process in that running container's process space. 


The command 'docker inspect' fetches the metadata that has been associated with the top-layer of the container or image. 


The command 'docker save' creates a single tar file that can be used to import on a different host system. Unlike the 'export' command, it saves the individual layers with all their metadata. This command can only be run on an image. 

The 'docker export' command creates a tar file of the contents of the "union view" and flattens it for consumption for non-Docker usages. This command removes the metadata and the layers. This command can only be run on containers. 


The 'docker history' command takes an image-id and recursively prints out the read-only layers (which are themselves images) that are ancestors of the input image-id. 

Conclusion 
I hope you enjoyed this visualization of containers and images. There are many other commands (pull, search, restart, attach, etc) which may or may not relate to these metaphors. I believe though that the great majority of docker's primary commands can be easier understood with this effort. I am only two weeks into learning docker, so if I missed a point or something can be better explained,