最初のフローを作る。Node-REDレクチャー2

Node-RED: Lecture 2 – Building your first flows

This lecture will introduce you to the Node-RED visual tool and get you started building your first flow. You’ll learn how to create simple flows, use debug nodes to track messages through the flows and how to use the function node to write simple JavaScript code that tailors the node to your specific needs.

このレクチャーでは、視覚的なNode-REDのツールを使って、最初のフローを組み立てます。シンプルなフローを作成する方法を習得し、debug ノードを使ってフロウの中のメッセージを追跡し、function ノードを使ってシンプルな JavaScript コードを書き自分の希望にあったノードに調整していきます。

To get you started, you’ll be using a free cloud service that provides you with a preconfigured Node-RED setup and a wide range of built-in nodes. Later lectures will explain how to set-up Node-RED for yourself on devices such as a Raspberry PI.

はじめるにあたって、前もって設定され広い範囲のnodeが組み込まれたNode-REDを提供する無料のクラウドサービスを使用していきます。のちのレクチャーではNode-REDをラズパイ等の自分のデバイスにセットアップする方法も紹介します。

At the end of this lecture you’ll be able to create your own simple flows, you’ll know your way around the Node-RED UI and you’ll be familiar with some of the basic built-in nodes that Node-RED offers.

このレクチャーの最後には、シンプルなフローを自分で作成できるようになり、Node-REDのUIや、Node-REDに組み込まれた基本的なノードについて理解できるようになります。

FRED フロント・エンド・フォー・Node-RED

FRED – Front end for Node-RED

FRED is a cloud service that we’ve created that allows you to sign up and use Node-RED without the hassle of downloading and installing on a device such as a PI. It makes it easy to get started with Node-RED by managing an instance of Node-RED for you, keeping the instance up to date with the latest code releases and applying bug fixes or patches. Also included is a set of extra Nodes that are contributed by the community, which add to the standard basic set you get when you install Node-RED yourself. However, FRED is just a wrapper for Node-RED, so anything you write in FRED will work on a Node-RED instance running on a Pi or a Beagleboard.

FRED はクラウドサービスで、私達が開発したものです。これはサインアップするだけですぐにNode-REDを使うことができるもので、ダウンロードしたりラズパイといったデバイスにインストールする手間がありません。なのでNode-REDを簡単に始めることができ、自分のNode-REDインスタンスを管理でき、インスタンスを最新のコードにアップデートし続けてくれ、バグフィックスのパッチも当てられています。またコミュニティーによって開発されたノードも追加されており、これはNode-REDにふくまれるベーシックなものとは別のものです。とはいえFREDはNode-REDのラッパーなので、FREDで書いたものは全て、ラズパイやBeagleboardで走るNode-REDの中でも同様に動きます。

To begin our examples, make sure you have created your own Node-RED instance in the cloud by signing up for a free account at http://fred.sensetecnic.com.

作例をスタートするために、自分のNode-REDインスタンスを、クラウドサービス内で立ち上げてください。サインアップし、フリーアカウントを取得しましょう。

After registering, make sure to activate your account via your email. You will not be able to log in until you validate your account.

登録した後に、Eメールによるアクティベイトが必要です。アカウントを証明するまではログインできません。

Node-REDのUIについて

The Node-RED UI

Once you have logged in to your FRED account, you’ll see the standard Node-RED UI which consists of three main panes, as shown in Fig 2.1

まずFREDにログインすると、一般的なNode-RED UIが立ち上がります。これは3つの中心的なパネルから構成されています。

Screen Shot 2015-10-22 at 4.53.21 PM.png

Figure 2.1 The Node-RED UI  – showing the node palette (left), flow canvas (centre) and output pane (right)

(左)ノードパレット、(中)フロー・キャンバス、(右) アウトプット窓

The main pane is the flow creation workspace in the middle. This is where you drag and drop nodes and connect them with wires. Along the top of the workspace pane is a set of tabs. Each tab opens a previously created workspace and shows any flows created using that workspace.

メインの窓は、フローを作成するためのワークスペースで、中央に配置されています。ここにノードをドラッグ・アンド・ドロップし、そしてワイヤーで結線していきます。ワークスペースの上部には、タブがあります。それぞれのタブは、以前に作成されたワークスペースを示しています。

On the left is the node pane that contains all the built-in nodes that your instance of Node-RED supports. In the example above, you are seeing the FRED node set which contains a large selection that has been added to the basic set that comes with Node-RED. In later lectures you will learn about these nodes and use them to develop new flows. As you can see, nodes are grouped into categories. Opening up a category shows the individual nodes.

左側には、ノードが全て配置されているノード窓があります。上記の例では、Node-REDに最初から組み込まれているものに加えて、FREDノードが追加されているのがわかります。レクチャーを通して、これらのノードを使ってフローを作る方法を学んでいきます。ご覧の通り、ノードはカテゴリー分けされています。カテゴリーをクリックして開くことで、その中に含まれているノードを見えるようにしてみましょう。

On the right-hand side is the output pane that can be toggled between the info and debug tabs. When info is selected, documentation for the selected node is shown there.  When debug is selected, it will display the output of debug nodes, errors and warnings.

右手には、アウトプット窓があります。info と debugタブを切り替えられます。infoタブが選択されているときには、選択されているnodeのドキュメントがそこに表示されます。debug タブが選択されているときには、debug ノードのアウトプットが示され、エラーやワーニングを通知します。

Above these three main panes is the usual toolbar, and on the right-hand side are three widgets, a deploy button, a user info icon and a pulldown menu for admin and control. You’ll look in more detail at the pulldown later in these lectures. The user info icon allows you to return to the FRED front page with links to tutorials, your account information, status and other information as well as to log out of the FRED service.

これら3つのメイン窓の上には、ツールバーがあります。ツールバーの右側には3つのウィジェットがあります。デプロイボタン、ユーザーインフォのアイコンと、adminとコントロールのためのプルダウンメニューです。プルダウンメニューの中身については、このあとのレクチャーで取り上げます。ユーザーインフォアイコンは、FREDのフロントページに戻ることができます。そこにはチュートリアルへのリンクがあったり、自分のアカウントの情報があったり、ステータスや、ログアウトするための画面、その他様々な情報があります。

The Deploy button is used when a flow has been constructed and causes the flow to be deployed onto the Node-RED system and executed. You’ll be introduced to the details of what’s actually happening under the covers in lecture 5 and beyond. For now just treat the Deploy button as the way to get your flow running.

Deployボタンは、フローが完成し、フローをNode-REDシステム上にデプロイし、実行する際に使用します。詳細についてはレクチャー5以降で説明します。今のところはデプロイボタンは、作成したフローを実行するために使用することになります。

 Node-REDのノードとメッセージの概略

A quick tour of Node-RED nodes and messages

As you saw in lecture 1, Node-RED allows you to wire together nodes to create flows which carry out your programming task. Messages pass between nodes, moving from input nodes through processing nodes to output nodes. Let’s take a brief look at nodes, flows and messages.

レクチャー1で見てきたように、Node-REDはノードをつなげ、フローを作り、プログラミングによってタスクを処理します。メッセージはノード間で渡され、Inputノードからプロセシングノードを通り、outputノードに到着します。ノード、フロー、メッセージについてさっと見ていきましょう。

There are three main  types of nodes:

主要な3つのノードがあります。

  1. Input Nodes (e.g. inject) Inputノード(injectノードなど)
  2. Output Nodes (e.g. debug) outputノード(debubノードなど)
  3. Processing Nodes (e.g. function) Processingノード(functionノードなど)

basic-fred-intro-02

Figure 2.2 The main types of nodes: input, output and processing

Input nodes allow you to input data into a Node-RED application or “flow”. They have at least one output endpoint represented by the small grey square only on their right side. You use input nodes to connect data from other services, for example the  Twitter, Google, serial, websockets or tcp nodes, or to manually input data into a flow using the inject node.

Inputノードは、データをNode-REDアプリケーション、つまりフローに入力させることができます。これらは、少なくとも1つ以上のoutputエンドポイントを持ちます。outputエンドポイントは、小さな灰色の四角で表され、右側に配置されています。Inputノードを使うことで、外部サービスのデータと接続することができます。例えばTwitter, Google, Serial, websocket, tcp といったものと接続することができます。ほかにも手動でデータをInputするためにも使うことができます。その場合にはinjectノードを使用します。

Output nodes allow you to send data outside of a Node-RED flow. They have a single input endpoint on their left side. You use output nodes to send data to other services, for example via Twitter, tcp, serial or email nodes, or to use the debug node to output to the debug pane.

Processing nodes allow you to process data. They have an input endpoint and one or more output endpoints. They allow you to transform the data type (e.g. json, csv, xml) nodes, use the data to trigger a message (e.g. trigger, delay) nodes and to write custom code that uses the data received (e.g. function node).

Note that some nodes, like the inject and debug messages, have a button that allows you to actuate a node (in the case of the inject node) or to enable and disable a node (in the case of the debug node).

Flows consist of multiple nodes wired together, with output tabs linked to input tabs of the next node in the flow. Messages flow along the nodes carrying data from node to node.

Node-RED nodes consume input messages and produce output messages. Messages are JavaScript objects that contain at least a “payload” parameter, like this:

Listing 2.1 A basic Node-RED message structure

  1. msg = {
  2.   payload:”message payload”
  3. };

Nodes consume and produce messages, usually using msg.payload as the main placeholder for the data they consume and produce. However, messages can be extended to contain other parameters. For example, to set the topic of a message and add a new parameter, location, you could create a new msg object as shown in listing 2.2.

Listing 2.2 A more complex Node-RED message structure

  1. msg = {
  2.   payload:”message payload”,
  3.   topic:”error”,
  4.   location:”somewhere in space and time”
  5. };

Let’s use this knowledge to create your first flow.

Example 2.1 Building your first flow: Hello World

Let’s go ahead and start building your first flow so that you can see how simple it is to use the Node-RED UI to build and deploy a flow.

Let’s start with the easiest flow possible, a node to inject some information into the flow, wired to a debug node to see the output from the flow as a debug message. Once you have that running, you’ll build it up to the full Hello World flow.

Since this is the first time you’ll be shown how to actually build a flow, let’s start slowly and explain each step with a screen-shot. Once you’ve created your first flow and seen how easy it is, you’ll mostly be shown a single picture of the final flow rather than all the screenshots.

Let’s start with the simplest Node, the comment Node. You’ll find this in the function section of the node palette. Drag and drop a comment node onto the flow workspace as shown in Fig 2.3.

 

Screen Shot 2015-07-31 at 2.03.20 PM.png

 

Figure 2.3: Using a comment node is a great way to add visible comments into flows

 

Once you’ve done that, take a look at the info pane on the right (remember to switch to info if the debug tab is selected). You’ll see a little info on the node, including the node name, a unique ID, and a properties field with a description of the node. For the comment node there’s not much to say; however, more sophisticated nodes have a lot more info.

Double-click on the comment node, and you’ll see a configuration window (Fig 2.4) You can give the comment node a name and add detailed text if you like.

 

Screen Shot 2015-07-31 at 12.16.33 PM.png

Figure 2.4 Give the comment a name and add any info you want in the text box

 

Ok, now let’s add the first node that actually does something, an inject node. The inject node is used to generate input into a flow and is one of the first nodes in the node palette under input. If you drag and drop an inject node onto the flow workspace, and then look at the info tab, you’ll see the documentation for the inject node. Note that the name of the node on the workspace changes from inject to timestamp, because the default behaviour for the node is to inject a timestamp – the current time in milliseconds since January 1, 1970.

 

Screen Shot 2015-07-31 at 12.03.59 PM.png

Fig 2.5 The inject node allows you to insert events as messages, defaulting to a timestamp

 

You’ll also notice that the inject node (now named timestamp) has a blue dot top right and a grey square centre right. The blue dot indicates that the node hasn’t been deployed since it was last changed; the grey square is the output point for the node. This is where you attach ‘wires’ that route output message from the inject node to the next node in the flow.

To get a sense for the inject node and the whole flow deployment process, let’s add a debug node to see what happens, wire them together and then deploy the flow and test it.

Start by dragging a debug node from the node palette to the workspace. Again you can look at the info for the node.

Then you’ll wire the two nodes together. To do that, click on the grey output point for the inject node and, holding the mouse button down, drag towards the debug node. An orange wire appears, which you can then attach to the grey input point on the debug node.

Screen Shot 2015-07-31 at 12.40.55 PM.png

Figure 2.6 Wiring an inject node to a debug node

 

This is the simplest flow possible and will send the current timestamp to the debug node for display in the debug pane. Let’s try it!

Click the deploy button in the Node-RED window (top right). You’ll see a pop-up saying the flow has been successfully deployed. You will also notice that the blue dots on the nodes disappear, indicating there are no undeployed changes.

Now, before you try the flow, make sure the the debug tab is selected on the right pane. Then click on the left tab on the inject node and look at what appears in the debug pane.

 

Screen Shot 2015-07-31 at 12.48.44 PM.png

Figure 2.7 Debug output from your first flow – the time when you clicked the inject node.

 

As you can see, the inject node, when clicked, generates a timestamp (number of milliseconds since January 1, 1970), which is converted to a message and sent along the output wire, which is delivered to the debug node as an input message. The debug node’s default behaviour is to show any message it receives, which it does in the debug pane on the right.

Congratulations, you created and deployed your first flow!

Let’s now augment it a little to see what else we can do with this simple flow. Firstly, we’ll edit the inject node to deliver a text message rather than a timestamp. To do that, select the inject node in the flow and double-click it. You’ll see a configuration window like the one in Fig 2.8.

 

Screen Shot 2015-07-31 at 12.54.29 PM.png

Figure 2.8 Editing an inject node to send text instead of a timestamp

 

In the payload field, select string instead of timestamp and then type any string you like into the blank field below the payload field. As is traditional, let’s start with “Hello World – from my first NR flow!”

Once you’ve made the change, click ok to save the changes and take a look at the flow. You’ll see the blue dot has appeared on the inject node (which has also returned to being called inject rather than timestamp) to indicate that you have undeployed changes. Click the deploy button again to resolve that and then go ahead and click the tab on the inject node. If you look at the debug output you’ll see that instead of a timestamp, your text has been delivered as a message to the debug node, which displays it as usual.

Screen Shot 2015-07-31 at 1.01.40 PM.png

Figure 2.9 Sending a text message rather than a timestamp

 

As you can see, it’s very easy to wire up some simple nodes and get data to pass through your flow as messages. At this stage, you’ll probably be wondering a little about the messages that are flowing between nodes. The debug node can be used to examine them in more detail.

All messages in Node-RED have three default properties: the payload, which we are seeing above, a message topic, which is a user-defined string describing what the message is about (its topic, if you will) and an internal identifier. You can actually see this information if you edit the debug node configuration. Let’s do that and look at the output (Fig 2.10)

 

Screen Shot 2015-08-06 at 11.15.08 AM.png

 

Figure 2.10: setting the debug node to show the internals of a message

 

Select the debug node, double click and change the node output field to “Complete msg object”. If you then save this, deploy again and click the inject node, you will see in the debug pane a JSON structure that contains 3 fields: a “topic” which is currently blank, a “payload” which contains the string you set in the inject node and an internal ID field “_msgid”. Generally the internal message ID field isn’t used. However, both the topic and payload are used extensively when developing flows. You’ll see more of that later in the lecture series.

These fields are extensible, so you can define new message properties, for example, msg.location, which could be used to add the latitude and longitude values for the source of the message. Let’s take a look at that in the next example flow.

 

You can find the node-red description of this flow at:

https://github.com/SenseTecnic/nrguideflows/blob/master/lesson2/2-1-firstflow.json

Example 2.2 A second flow: weather alerts

In this example, which is similar to the one introduced in lecture 1, you’ll monitor the weather in your hometown and send yourself a tweet when the weather looks like it’s going to be good. You’ll use a built-in weather node – openweathermap – that retrieves the weather from openweathermap.org for the location you set it for. A simple function node will be used to check for ‘clear weather’ and a Twitter node will be used to send yourself a tweet when the weather looks good.

First you will need to get an API key at OpenWeatherMap. OpenWeatherMap offers a great service that provides detailed weather information for worldwide locations. Visit http://openweathermap.org/appid and follow the instructions as shown in the screenshots below.

 

 

You will need to sign up for an OpenWeatherAccount as shown below:

After signing up you will be redirected to your Home page where you will be able to access or re-generate your API Key. It should look something like this:

Now, let’s use that API key to build a weather alerts flow. Drag and drop a weather node from the left pane onto the workspace, as shown in Figure 2.11.

 

Figure 2.11. Drag and drop a weather node onto a blank workspace

 

If you select the info pane on the right, you can see a description of the openweathermap node with detailed information on how to configure and use it. Some interesting things to note:

  • It has a full JSON structure as its msg.payload, with quite a lot of weather detail, all presented as name:value pairs, e.g. wind speed and tempc
  • The node defines 3 new message properties, msg.location, msg.time and msg.data. As mentioned above, you are free to add properties to messages, and the openweathermap node has added these new properties to carry extra information associated with the message.

Let’s configure the node and look at the actual data structure it generates after it has queried your local weather. Start by double-clicking on the node and fill out the form with your location. Type your city and country in the fields. Add the API key you obtained from http://openweathermap.org/appid and click on “Ok” as shown in Fig. 2.12.

 

 

Figure 2.12. Set your city and country in the configuration form, use the API key you obtained in the step above.

 

Then drag and drop a debug node and wire it to the openweathermap node. Click on “Deploy” to see that the payload object from the openweathermap node in the debug pane.

 

Listing 2.3 The message payload for the openweathermap node is a JSON structure describing weather conditions, temperature, wind, cloud cover and sunrise times.

  1. {
  2.   “weather”: “Clear”,
  3.   “detail”: “sky is clear”,
  4.   “tempk”: 295.104,
  5.   “tempc”: 21.903999999999996,
  6.   “humidity”: 53,
  7.   “maxtemp”: 295.104,
  8.   “mintemp”: 295.104,
  9.   “windspeed”: 2.22,
  10.   “winddirection”: 273.007,
  11.   “location”: “Vancouver”,
  12.   “sunrise”: 1432038196,
  13.   “sunset”: 1432094081,
  14.   “clouds”: 8,
  15.   “description”: “Vancouver weather(49.25,-123.12) is Clear (sky is clear).”
  16. }

As you can see, the node delivers quite a lot of information about your local weather, all as the usual name:value pairs. For this example, you want to use the “weather” field which you’re going to test to see if it’s reported as “Clear”. If it’s “Clear” you’ll then send a tweet.

To program that logic, you’ll use a function node. You saw one of these in lecture 1, but without the details. Let’s see how they are used by dragging one onto the flow workspace and double clicking it to open up the node editor.

Figure 2.13. Add a function node and wire it to the openweathermap node.

Now double-click on the function node and type/copy this (Note if you use copy/paste – make sure you paste as plain text, wordpress sometimes inserts odd characters)

 

Listing 2.4 Function node “If Clear Weather”

  1. if (msg.payload.weather === “Clear”) {
  2.     msg.payload = “Clear skies ahead today!”
  3.     return msg;
  4. }
  5. return null;

Figure 2.14. Edit the function node adding the JavaScript shown in listing 2.4

Looking at Listing 2.4, you can see that this will parse the incoming message payload for the weather parameter and compare it to the string “Clear” (line 1). If it is equal, it will rewrite the message payload with your own string “Clear skies ahead today!” (line 2). Otherwise it will return a null message (line 5). This last bit is important because in Node-RED nodes ignore null messages.

You can do all sorts of things now, for example wire this message to an email node, or a pushbullet node. For this tutorial we will use the Twitter output node. Drag  a Twitter node onto the workspace, double-click and and fill out your Twitter account credentials as shown in Fig 2.15.

Figure 2.15. Set your Twitter account credentials into the node configuration

Once you’ve set up these credentials, Node-RED stores them and you can reuse them when you create another Twitter node in future flows.

Once you’ve wired up the flow, you can hit the deploy button and then watch your Twitter account to see the new tweet every time the weather is reported as clear.

Click on “Deploy”:

Figure 2.16. The full weather flow sending tweets if the weather report mentions clear skies.

Other useful UI features

One of the most useful features of the Node-RED UI is the ability to copy and paste nodes and even full flows using the standard cut’n’paste clipboard. Node-RED flows are simply coded as JSON strings and can be exported from a workspace, and imported into a workspace using the Node-RED pulldown menu in the top right of the Node-RED window.

Rather than building the flows in this example, or in fact anywhere in this lecture series, by hand yourself, you can simply copy them from our website and paste them into a workspace. After that all you need to do is configure them correctly, e.g. with credentials, and deploy them.

Let’s quickly show you how to do that.

Click on the link for this example which is at the end of the example below and look for the JSON code. Copy it to the clipboard using the usual CTL C or copy item in the edit menu.

Using the pulldown menu in the top right of the Node-RED window, select Import->Clipboard as shown in Fig 2.17

Screen Shot 2015-08-15 at 12.55.58 PM.png

Figure 2.17 Selecting the Import from Clipboard menu item in Node-RED

 

You will see a popup with an input field (Fig 2.18). Paste your clipboard into the input window and click OK.

 

Screen Shot 2015-08-15 at 12.56.27 PM.png

Figure 2.18 Pasting a flow into the import window of Node-RED

 

The new flow will appear in the current workspace and can be moved to a location and dropped. Once it’s in place, you can configure it as you would a flow you created yourself and deploy it.

 

You can find the node-red description of this flow at:

https://github.com/SenseTecnic/nrguideflows/blob/master/lesson2/2-2_weatheralerts.json

Summary

In this lecture you have created your first flows and seen how to wire together a set of basic nodes to achieve quite complex tasks. We’ve skipped over a few of the underlying details in order to get you going quickly, and we’ll return to those in lectures 3 and 4. However, so far you’ve seen how to use the Node-RED visual flow builder, the basic classes of input, output and processing nodes. You were given a brief overview of messages and how to use the function node to write your own JavaScript code to do simple processing on messages within a flow. In the next lecture, you’ll take a more in-depth look at the programming model of Node-RED and get a better understanding of the main programming elements and nodes and how to craft more complex flows using a variety of nodes.

Node-RED イントロダクション

Node-RED: Lecture 1 – A brief introduction to Node-RED

Node-RED: Lecture 1 – A brief introduction to Node-RED

This lecture will introduce you to some examples of Node-RED, both to give you a sense of its capabilities and to introduce its basic concepts. We’ll also discuss the history of Node-RED and its origins to give you an idea of what Node-RED is good for and of what types of tasks are best left to a more traditional programming language and environments.

このレクチャーでは Node-RED を用いた作例を紹介し、Node-RED でどのようなことができるか、またその基本概念についてもお伝えします。Node-RED の歴史と起源についても触れ、それによって Node-RED がどのようなタスクに向いていて、またどのようなタスクについては古典的なプログラミング言語で処理したほうがいいのか、ということについても考えていきます。

Node-RED is a powerful tool for building Internet of Things (IoT) applications with a focus on simplifying the ‘wiring together’ of code blocks to carry out tasks. It uses a visual programming approach that allows developers to connect predefined code blocks, known as ‘nodes’, together to perform a task. The connected nodes, usually a combination of input nodes, processing nodes and output nodes, when wired together, make up a ‘flows’.

Node-RED は IoT アプリケーションを構築するためのための強力なツールで、特に、様々な機能の連携をシンプルに実装することに注力しています。タスクを処理する役目を持つ「コードブロック」を、シンプルにつなぐだけで実装出来るのです。Node-RED は視覚的なプログラミング手法を採用しており、開発者は予め用意されたコード・ブロック = nodes をつなげることで、タスクを処理させます。通常は input 用の node があり、処理用の node があり、最後に output 用のノードがあります。これらが結線されて、「flows」を形成します。

Originally developed as an open source project at IBM in late 2013, to meet their need to quickly connect hardware and devices to web services and other software – as a sort of glue for the IoT – it has quickly evolved to be a general purpose IoT programming tool. Importantly, Node-RED has rapidly developed a significant and growing user base and an active developer community who are contributing new nodes that allow programmers to reuse Node-RED code for a wide variety of tasks.

Node-RED は IBM のオープンソースプロジェクトとして2013年に開発が始められました。IBM は、ハードウェアや各種デバイスを、ウェブサービスや様々なソフトウェアと接続する必要があり、そのために開発されたのです。つまり IoT におけるつなぎの役目を果たします。その後 Node-RED 急速に進展し、IoT 全般で用いることができるツールになりました。また Node-RED が特に優れているのは、 急速に莫大なユーザーを獲得し、それから開発者コミュニティーが成長し続けていることにあります。新しい node がどんどんと追加され、様々なタスクを処理することが可能です。

Although Node-RED was originally designed to work with the Internet of Things, i.e. devices that interact and control the real world, as it has evolved, it has become useful for a range of applications.

Node-RED はもともと IoT のために作られたものではあるのですが、今ではもっと広い範囲のアプリケーションの作成においても便利なものになっています。

This lecture will introduce you to some examples of Node-RED, both to give you a sense of its capabilities and to introduce its basic concepts. We’ll also discuss the history of Node-RED and its origins to give you an idea of what Node-RED is good for and of what types of tasks are best left to a more traditional programming language and environments.

このレクチャーでは Node-RED を用いた作例を紹介し、Node-RED でどのようなことができるか、またその基本概念についてもお伝えします。Node-RED の歴史と起源についても触れ、それによって Node-RED がどのようなタスクに向いていて、またどのようなタスクについては古典的なプログラミング言語で処理したほうがいいのか、ということについても考えていきます。

By the end of this lecture you should have a high-level understanding of Node-RED, its programming model and some simple pre-built nodes as well as an insight into the origins and best usage of Node-RED.

このレクチャーのおわりには、Node-RED の深い理解を得て、Node-RED プログラミングの構造と、予め用意された Node への理解、それから Node-RED の起源と、最適な使用状況についての理解を得ることが出来るはずです。

Node-RED を知ろう

Getting to know Node-RED

Let’s get started by looking at a few simple examples of the kinds of thing you can do with Node-RED. Our goal in this lecture is not to get you programming with Node-RED, but to give you a sense of its capabilities through some high level examples. If you really want to dive straight in, you can skip ahead to lecture 2 where you’ll be taken through the steps to create and run your first flow.

Node-RED でどんなことができるのか、シンプルな例をみていきましょう。この記事の目的は、Node-RED でのプログラミングの方法の学習ではなくて、作例をみながらどんなことが Node-RED によって可能になるのか、という知見をもってもらうことにあります。すぐにでもプログラミングを始めたい場合には、この記事はスキップしてレクチャー2に進んでください。そこでは実際にプログラミングをして最初のフローを作成していきます。

This first example flow will receive a message from a Twitter feed containing a hashtag and turn on and off a LED when a new tweet has arrived. For this example let’s assume that NODE-RED is running on a Raspberry PI – a common situation for many Node-RED users.

次の最初の flow の例は、Twitter からハッシュタグをもつメッセージをフィードから取得し、新しい Tweet がされた時に、LED を点滅させるものです。この例においては Node-RED は Rasberry PI 上で動作させられることが想定されています。これは Node-RED の使用方法として非常に一般的なものです。

例1.1 Twitter を用いて Raspberry PI をコントロールする

Example 1.1 Using Twitter to control a Raspberry PI

The Node-RED flow to check Twitter and to see if a hashtag #led is detected, turns on a LED connected to a Pi is shown in Fig. 1.1. As you can see, it’s quite simple; it consists of 3 nodes wired together – a twitter node on the left, a trigger node in the middle and a Raspberry Pi (gpionode) node on the right. (gpio stands for General Purpose Input/Output and is the name given to the generic Raspberry PI node that handles IO). The nodes, represented by rounded boxes, usually have an icon to represent their type, e.g. the Twitter bird icon in the first node, and a text name that can be set by the programmer.

Node-RED の flow は Twitter をチェックして、#led のハッシュタグが検知された場合には、Raspberry PI に接続された LED を点灯させます。これを示したのが下記の図です。ご覧の通り非常にシンプルです。3つの node がつなげられています。Twitter のためのノードは左側にあり、トリガー用のノードが真ん中に、Raspberry Pi 用のノード(goionode)は右側にあります。(gpio はGeneral Purpose Input/Output の略記で、同時にここでは Raspberry Pi のIn/Out をコントールする一般的な node のための名前でもあります) ノードは丸みを帯びた四角形で表され、通常はその役割を表すアイコンを持ちます。 また名前を自分でつけることができます。

Each of these three nodes is built into the Node-RED visual programming tool and can be dragged from a node palette onto the main workspace. They are then ‘wired’ together by joining their output tabs to the input tab of the next node in the flow (the little grey blobs on the right or left of the node boxes.) The next lecture will look at the UI in detail, but for now let’s focus on the high-level capabilities.

それぞれ3つのノードは、Node-RED に組み込まれており、ノード・パレットからメインの作業スペースにドラッグ・アンド・ドロップで配置することができます。ノードを接続するためには、outputを、フロー上で次にくるInputにつなぎます。(左右にある、小さい灰色の丸がそれです。) 次のレクチャーではUIをより詳細にみていきますが、いまのところは概念的な説明をしていきます。

The Twitter node is a built-in node in Node-RED and hides all of the complexity of using the Twitter API. It can be configured with a user’s account credentials and a variety of search strings, in our case it’s simply looking for hashtag ‘#led’.

Twitter 用の node は Node-RED に最初から組み込まれており、Twitter API を使う上で生じる複雑さに触れる必要がないようにしてくれています。必要なのは、ユーザー認証情報と、検索用の文字列、このケースでいえば単純に #led のハッシュタグを探していいます。

When the Twitter node sees the tag either in a tweet to the user, or the public tweet feed, it creates a new message with the details of the tweet, which is forwards to the next node in the flow. In our example, since the Twitter node’s output is wired to the trigger node’s input, the trigger node receives a message with the details of the tweet.

Twitter ノードは、ユーザーのツイートとそれ以外の全ユーザーのツイートにおいて、指定されたツイートがされたことを確認すると、そのツイートの詳細情報を元に新しいメッセージを作成し、これをフロー上の次のノードに渡します。この例では、ツイッターノードのoutputはトリガーノードのInputにつながっており、トリガーノードはツイートの情報をもったメッセージを受け取ります。

The trigger node is another built-in node in Node-RED and its default behaviour is to wait for any message on its input. When it receives a message, it ‘triggers’, and sends a message on its output with the value “1” as the message body. It then waits 1 second and sends a second message with the value “0” in the message body.

Trigger ノードも Node-RED に最初から組み込まれているノードで、デフォルトの挙動は、Inputにくるメッセージを待ち受けることです。メッセージを受け取ったら、「トリガー」し、outputにメッセージを送ります。そのメッセージのbody値は0です。その後、1秒待った後に、bodyの値が0のメッセージを送ります。

Since the trigger node is connected to the gpionode, which controls the Input/Output or IO pins on the Raspberry PI, it get’s these two messages, 1 second apart, on its input.

トリガーノードは、gpionode に接続されているので、gpinode は送られてくる2つのメッセージを、1秒開けて、Inputから受け取ります。

Again, the gpionode is a built-in node in Node-RED that hides the details of setting the IO pins on the PI. When it gets a message with a value of “1” in the body, it takes the IO pin high, and when it receives a message with body of “0”, it takes the pin low. In this example, the gpionode is configured to control pin number 12, and so the node shows that in the node icon.

繰り返しになりますが、gpionode はNode-RED に最初から組み込まれており、ラズパイのIOピンの詳細設定に触れる必要をなくしてくれています。このノードが、body が1であるメッセージを受け取ると、IO ピンをhighにし、0を受け取るとピンをlowにします。この例ではgpionodeはピンナンバー12をコントロールするように設定されていますので、それがノードのアイコンでも示されています。

If you have your PI wired up with an LED connected to Pin 12, the gpionode going high for 1 second and then low will cause the LED to blink on for 1 second.

ラズパイの12pinがLEDに接続されていれば、gpionodeは1秒high、その後lowになるので、LEDを1秒点滅させることになります。

If you think about what’s happening here, it’s actually an incredibly powerful example of Node-RED and the Internet of Things (IoT). It’s connecting the ‘Twitterverse’ to a PI and an LED, but requires no programming – all the tasks are carried out by pre-built nodes in Node-RED which just need configuring. This really demonstrates the power of Node-RED when running on a simple device such as a Raspberry PI.

ここでおきていることは、Node-RED と IoT の強力さを示しています。「ツイッターの世界」がラズパイとそのLEDに接続されているのですが、そのためにはプログラミングが必要ないのです。全てのタスクは、Node-RED に最初から用意されている node によってなされてしまうのです。この例はラズパイのようなシンプルなデバイス上で Node-RED を動かくことによるパワフルな効果を示す良い例です。

So just to recap. Node-RED is a flow-based programming tool with a visual editor that allows you to wire together nodes to create flows. In this case, 3 nodes create our first flow. Real-world events, e.g. a tweet with the #led hashtag, are converted to messages, which ‘flow’ along the wires between the nodes. Nodes process messages on their input and, as a result, send messages on their outputs to the next node in the flow. In this simple example, we look for a tweet with hashtag #led and use it to trigger a message to a Raspberry PI node that cause IO pin 12 to go high for 1 second, which in turns causes a LED to blink on for 1 second.

振り返ってみましょう。Node-RED はフロー・ベースのプログラミング・ツールで、視覚的なエディターをもっています。これによってノードをつなげて、フローを作成します。この例の場合は、3つのノードをつなげてフローを作成しました。実際の世界の変化が、ここでは#ledをもったツイートが、メッセージに変換され、結線されたノードの間を流れて=flowしていきます。NodeはInputに来たメッセージを処理し、アウトプットからメッセージをだし、それがフロー上の次のノードに渡されます。このシンプルな例においては、#ledをもつツイートを探しました。そしてラズパイ用のノードに送るメッセージをトリガーして、IO ピンの12番めを1秒ハイにすることで、LEDを1秒点滅させました。

This example – and the rest in this lecture – are mostly to show you the kinds of things we can do with Node-RED. If you want to play around with the example, you should look at lecture 2 to see how to setup an account with FRED (the cloud based Node-RED service we use) and how to get started. You can find the node-red description of this flow at:

この例、それから今後のレクチャーで用いられる例は、うまくNode-REDできることを伝えています。実際にNode-REDで作業をしたいのであれば、レクチャー2を参考にして、FRED(クラウドベースのNode-REDサービスです)のアカウントを設定して、はじめていきましょう。このフローの説明は次のリンクから確認できます。

https://raw.githubusercontent.com/SenseTecnic/nrguideflows/master/lesson1/1-1_twitter.json

例1.2 Node-REDを使ってトレーニングの予定を守らなかった時にアラートを鳴らす

Example 1.2 Using Node-RED to alert you when you’re falling behind on your exercise schedule

Our second example shows a different usage of Node-RED. Rather than controlling a device such as a Raspberry PI, this flow combines weather info and your fitbit usage to send you an email alert when the weather is good and you’re behind on your exercise schedule. The flow is a little more complicated, using 6 nodes (see Fig 1.2), but again, by using built-in nodes you can accomplish complex tasks with little or no programming.

付きの二つ目の例は、Node-REDの先ほどとは少し異なった使い方を示しています。ラズパイのようなデバイスをコントロールするのではなくて、このフローは天気情報とfitbit(訳注:フィットネス向けのアップルウォッチのようなウェアラブルデバイス、及び関連サービス)をつなげて、天気が晴れなのに、エクササイズをしていない時に、アラートメールを送ります。このフローは、少し複雑で、6つのノードを使います。しかしもとから用意されているノードを使うので、複雑なタスクを最小限にしてくれますし、もっといえばプログラミングのする必要もありません。

Figure 1.2 A simple flow to alert you when you are not exercising and the weather is good

As before, nodes are dragged from the node palette in the Node-RED UI and wired together on the flow canvas. Starting at the leftmost node, let’s begin with an openweather node which you can configure to check the weather for any major city at set intervals. When it checks, it packages up the results in a message which is forwarded to the next node, in this case, to a switch node. The switch node performs a simple test, checking the input message for a value and sending a message with a value of “1” if the test is true. In our case, it’s been configured to test the temperature value (tempc) to see if it’s 15 degrees celsius or higher.

先程と同じように、ノードをノードパレットからドラッグ・アンド・ドロップして、それをつなげていきましょう。一番左のノードから始めましょう。これは openweather ノードで主要な都市の天気を設定した間隔で確認することができます。確認をしたときに、その結果をメーセージにまとめあげて、次のノードに渡します。このケースではswitchノードです。switchノードは簡単な分析をします。つまり、Input送られてきたメッセージの値をチェックして、分析がtrueなら、値が1のメッセージを送信します。このケースでは、気温が(tempc)が15度以上であるかどうかを分析するように設定されています。

When the switch node tests to true, or ‘switches on’, it sends a message onto the fitbit node which is the next node in the flow. The fitbit node is another powerful built-in node that you can configure to get statistics on your fitbit device from the fitbit.com portal. The fitbit node packages the statistics for your device into a message and forwards it to the next node in the flow.

switchノードのテスト結果がtrueの場合には、「スイッチオン」になり、フローの次のノードにあるfitbitノードにメッセージを送ります。fitbitノードも最初から組み込まれている強力なノードで、fitbit.comポータルから、あなたのデバイスの情報を取得することができます。fitbitノードはその情報をパッケージにして、次のノードにメッセージとして送ります。

The next node is another switch node. This one has been configured to check if the number of steps you’ve walked today is less than 1000. It does this by testing to see if the fitbit data field, summary.steps, is less than 1000. Remember, it just got these statistics in a message from the fitbit node, which in turn got them by making a call to the fitbit API on fitbit.com.

次のノードもスイッチノードです。これは。今日あるいた歩数が1000より少ないかどうかをチェックします。fitbitデータのうち、summary.stepsの値をあっクニンして、1000より少ないかどうかを判断します。ここではあくまでfitbitノードから受け取った値を分析しているだけで、fitbit.com のAPIにアクセスしているのはfitbitノードです。

If you have walked less than 1000 steps today, then the switch node generates a message that is passed on through the flow to a function node. The function node is a generic all-purpose node that allows you to write your own programming logic in Javascript. This node will be discussed in more detail in the next lecture. For now you can assume that this node just creates a new message with an email subject line and a text body that can be sent by email.

もし今日1000歩歩いていなければ、スイッチノードはメッセージを作成し、次のファンクションノードに渡されます。ファンクションノードは、JavaScriptでロジックを自分で書くことができる、様々な目的のために使われるノードです。これについては次のレクチャーでより説明します。さしあたってここでは、このノードは単に新しいEメールのタイトルと、Eメールで送る内容をtext bodyとしてもったメッセージをつくっていると理解しておいてください。

Once this message is created within the function node, it is sent through the flow to the final node which is an email node. This node will take the body of any incoming message and send it to the email account configured when the node is initialized. In this case, you’d set it up to send a message to yourself.

このメッセージがファンクションノードの中で作られると、最後のノードに送られます。Emailノードです。このノードは、受け取ったメッセージのbodyをもとに、Eメールを設定されたアカウントに送ります。ここではあなた自身に送られるようにしておきます。

So again, a very simple flow that uses the power of Node-RED’s built-in nodes to check your local weather. And if it’s reasonably warm and you haven’t done much walking today, it sends you an email reminder.

振り返ってみましょう。とてもシンプルなフローですが、Node-REDが予め用意した便利なノードを使って天気をチェックします。そして温度がそれなりに暖かい日で、しかもあなたが今日十分に歩いていない場合には、リマインダーメールが送られます。

Although the example seems quite simple, just checking the weather and your fitbit activity, you can use similar flows to check the status of home devices, of computers in your server farm, of devices in a factory, etc., and you can then use output nodes to send mail, tweets, make API calls to back-office software, control real world devices – in fact the choices are endless. Node-RED is an extremely powerful tool for wiring together inputs and outputs and offers many nodes, either built in or developed by the Node-RED community, to carry out an amazing range of tasks.

この例はとてもシンプルで、天気やfibitの状態をチェックするだけですが、同様なフローを使って、家にある機器や、サーバーにあるコンピューターや、工場のデバイス等々をチェックすることができます。そしてoutputノードを使って、メールを送ったり、ツイートをしたり、バックオフィスにあるソフトウェアのAPIをたたり、実世界のデバイスをコントロールしたりすることができます。その選択肢は無限です。Node-REDはInputとoutputをつなぐパワフルなツールです。そのためのノードは、最初から組み込まれているものもありますし、ユーザーコミュニティによって開発されたものもあります。それによって驚くほど広範囲の処理をこなしてくれるのです。

You can find the node-red description of this flow at:

https://raw.githubusercontent.com/SenseTecnic/nrguideflows/master/lesson1/1-2_weatheralert.json

例1.3 Node-REDのHTTPノードを使って、シンプルなウェブサービスを構築する

Example 1.3 Building a simple web service using Node-RED’s built-in HTTP nodes

Our final example in this high-level introduction is yet another class of flows. It shows how to create a simple web service that responds to a browser sending a HTTP request by querying some real-world data, and then delivers a web page with a graphical representation of that data back to the browser – essentially Node-RED is being used to provide a web server and simple service all with a few nodes.

次の例は、ブラウザが送るHTTPリクエストによるリアルワールドの情報に対するqueryに応答する、シンプルなウェブサービスです。そしてデータをもとにしたグラフィカルな表示が含まれるウェブページを、ブラウザに返します。Node-REDはWebサーバを提供するためにも使えるので、シンプルなサービスであればかなり少ないノードで実現できます。

Sticking with the fitbit node introduced in the previous example, and this example creates a simple web service that allows you to query your fitbit stats for the day and, using a nice donut chart, display how many calories you’ve ‘burned off’ through exercise.

先程の例で紹介したFitbitノードをもう一度扱います。この例では、fitbitのその日の状態を問い合わせ、円グラフを使ってどれだけのカロリーを消費したかを示す、シンプルなアプリケーションを作ってみましょう。

The flow is shown in Fig 1.3 and consists of 4 nodes. The first and final nodes are http input and output nodes that work together to listen for HTTP requests and send HTTP responses. This flow listens for a HTTP request from any source, but let’s assume a regular browser here. When it arrives, it queries your fitbit stats from fitbit.com, then uses a template node to build a HTTP page, and passes that to the http output node which sends back the webpage to the browser.

次の図をみてください。4つのノードから構成されています。最初と最後のノードはHTTPに関するもので、outputとInputを担います。HTTPリクエストうけ、HTTPレスポンスを返します。どんなHTTPリクエストも受けることが出来るのですが、今回は一般的なブラウザからのリクエストを受けることにしましょう。HTTPリクエストが届くと、Node-REDはfitbit.comに問い合わせをして、fitbitの状態を取得します。そしてHTTPページを送信するためのテンプレートノードを使ってデータを作成し、それをHTTPoutputにわたし、そのウェブページをブラウザを介して返送します。

Figure 1.3 A simple web server example to graph fitbit data

Again, this is just to give you a sense of the power and flexibility of Node-RED without going into all the details of how this flow works. You’ll get to know more about that in later lectures. At a high level, the http input node has been configured to listen for HTTP requests on a URL, which is a combination of the hosting service that’s used in these lectures plus your login name {username} and the /fitbit string. This will be explained in more detail in lecture two.

振り返ってみましょう。HTTPInputノードは特定のURLへのHTTPリクエストを待ち受けます。これはホスティングサービスの名前と、それからユーザーネームと、fitbitという文字列から構成されています。これについてはレクチャー2で解説します。

When a HTTP request comes in, the http input node creates a message to trigger the fitbit node, which is the next node in the flow. The fitbit node gets the current statistics for the user, and then passes those statistics, as a message, to a template node. The html template node is another pre-built node in Node-RED, which, like the function node, allows you to build arbitrary code. However, rather than using JavaScript like the function node, the template node works with text such as HTML.

HTTPリクエストが送られてくると、HTTPインプットノードは、fitbitノードをトリガーするためのメッセージを生成します。fitbitノードは現在の状態を取得し、それをテンプレートノードにわたします。htmlテンプレートノードは、最初から用意されているノードの一つで、自由にコードをかくことができます。JSを書くことができるファンクションノードに似ていますが、テンプレートノードは、HTMLのような単なるテキストを作成するためにあります。

The HTML code in the template node is shown in Listing 1.1, so you can see what’s happening. However, there’s no need to examine it in detail if you don’t want to. Basically, the template node takes the calorie consumption data from fitbit and, using a 3rd party graphing library, creates a simple HTML file that will tell the receiving browser to use the 3rd party graphing library to display a donut chart of calorie consumption.

基本的にはテンプレートノードはカロリー消費のデータを受け取って、サードパーティーのグラフライブラリを使ってシンプルなHTMLファイルを作成し、そのファイルによってブラウザへ、ドーナッツを描画させているだけです。

Listing 1.1 A simple HTML template to display a donut chart of calorie usage

  1. <!doctype html>
  2. <head>
  3.     <title>A Node RED Example</title>
  4.     <link rel=”stylesheet” href=”//cdnjs.cloudflare.com/ajax/libs/morris.js/0.5.1/morris.css”>
  5.     <script src=”//cdnjs.cloudflare.com/ajax/libs/raphael/2.1.0/raphael-min.js”></script>
  6.     <script src=”//ajax.googleapis.com/ajax/libs/jquery/1.9.0/jquery.min.js”></script>
  7.     <script src=”//cdnjs.cloudflare.com/ajax/libs/morris.js/0.5.1/morris.min.js”></script>
  8. </head>
  9. <html>
  10.     <div id=”chart-example” style=”height: 250px;”></div>
  11.     <script>
  12.         Morris.Donut({
  13.            element: ‘chart-example’,
  14.            data: [
  15.              {label: “Activity Calories”, value: {{payload.summary.activityCalories}} },
  16.              {label: “Calories BMR”, value: {{payload.summary.caloriesBMR}} },
  17.              {label: “Calories Out”, value: {{payload.summary.caloriesOut}} }
  18.           ]
  19.        });
  20.     </script>
  21. </html>

Once the template node has generated the HTML file, it passes it as a message to the final node, which is a http response node. This node packages up the HTML as a HTTP response which it send back to the browser.

テンプレートノードがHTMLファイルを作成すると、それはメッセージとして最後のノード、HTTPレスポンスノードに渡されます。このノードがブラウザにレスポンスを返します。

The user will then see a simple donut chart of their calorie usage for the day (see Fig 1.4)  – all built and served by a simple Node-RED flow!

ユーザーはシンプルな円グラフによってこの日にどれだけのカロリーを消費したのかを確認することができます。全てNode-REDだけで作成され、そしてその上で機能しています!

 

 

Figure 1.4 A donut chart, served up by Node-RED showing calorie counts from fitbit

 

You can find the node-red description of this flow at:

https://raw.githubusercontent.com/SenseTecnic/nrguideflows/master/lesson1/1-3_webservice.json

The History of Node-RED

読めばわかる。ということで翻訳パス。

As the examples in the previous section have shown, Node-RED is a powerful tool for building IoT applications and services. Its genesis was triggered exactly by this need to rapidly prototype IoT applications and Node-RED was created as an open source project by the IBM Emerging Technologies group, in particular by two researchers, Nick O’Leary and Dave Conway-Jones. They created Node-RED initially as a tool for themselves as they were working on IoT projects and were “looking for a way to simplify the process of hooking together systems and sensors when building proof-of-concept technologies for customers.”

An initial version of Node-RED was released as an open source project in late 2013 and built up a small but active user and developer group during 2014. At the time of writing, Node-RED is still an emerging technology, but has already seen significant adoption by makers, experimentalists and a number of large and small companies experimenting with using it for their needs.

Today there is a vibrant user and developer community, with a core group working on the Node-RED code itself and most developers contributing nodes or flows to the flow library. You can check out the mailing list and github repositories using the links provided in Appendix A or just google them.

Since Node-RED is still a rapidly evolving technology, be aware that things can change quickly. These lectures were written against the 0.11.0 release of Node-RED and the examples will be updated as Node-RED evolves. However, it’s always wise, as with any new technology, to check compatibility if things aren’t working the way you expect.

Node-REDとIoT

Node-RED and the IoT

When the IBM folks created Node-RED, they were mostly focused on the Internet of Things, i.e connecting devices to processing and processing to devices. As a tool for rapid application development for the IoT, Node-RED is both powerful and flexible. Its power comes from a combination of two factors:

IBMのメンバーはNode-REDを作ったときには、IoTにフォーカスしていました。つまりデバイスをプロセスにつないだり、プロセスをデバイスにつなげるという使用方法です。IoTのための迅速なアプリケーション開発ツールであるので、Node-REDはパワフルであり、フレキシブルです。その強みは、次の2つの要素の組み合わせによってもたらされています。

  • Node-RED is an example of a flow-based programming model – messages representing events flow between nodes, triggering processing that results in output. The flow-based programming model maps well to typical IoT applications which are characterised by real-world events that trigger some sort of processing which in turn results in real-world actions. Node-RED packages these events as messages which offer a simple and uniform model for events as they flow between nodes that make up the flows.
  • Node-REDはフローベースのプログラミングモデルを採用しています。つまり、メッセージはイベントを表しており、これがノードの間を伝わっていきます。そして処理をトリガーして、その結果がoutputにもたらされます。フローベースのプログラミングモデルは、典型的なIoTアプリケーションに上手く適合します。つまり実世界のイベントが、ある処理をトリガーし、そしてそれが順番に処理されていって、最後に実世界へのアクションという結果を生むアプリケーションです。Node-REDはこれらのイベントをメッセージへとまとめあげて、イベントをシンプルで単一モデルで扱うことができ、ノード間をこのメッセージを流していきます。これがフロウです。
  • The set of built-in nodes is the second part of the Node-RED story. By building a set of powerful input and output nodes, each of which hides much of the complexity of interacting with the real world, Node-RED offers developers powerful building blocks to allow them to quickly put together flows that accomplish a lot, without having to worry about the programming details.
  • パワフルなinput/outputノードを組み立てることで、実世界と連携するための面倒事のほとんどから遠ざけてくれ、開発者は素早く問題解決のためのフローを作成することができます。プログラミングの細かいことを気にする必要がありません。

These two factors make Node-RED a powerful tool for IoT application development. When combined with the flexibility to create and use nodes such as the function node, which allows the developer to quickly write arbitrary JavaScript, plus the Node-RED community, who are constantly creating and sharing new nodes, Node-RED is likely to be one of the main tools in the IoT developers toolbox.

この2つの要因によって、Node-REDはIoTアプリケーション開発のための強力なツールになります。JSで書けるより柔軟性の高いファンクションノードや、Node-REDコミュニティが提供するノードを使うことで、IoT開発者にとって主要なツールとなったのです。

However, Node-RED isn’t always the best tool for IoT application development. While powerful and flexible, it isn’t always the right solution. Some situations where Node-RED may not be the first choice include:

しかし、Node-RED は常にベストなツールとは限りません。パワフルでフレキシブルではありますが、常に最適な解決法ではありません。Node-REDが第一の選択肢に上がらない場合には、次のようなケースがあるでしょう。

  • Complex multi-function IoT applications. Node-RED excels at rapid application development and at acting as the glue for connecting events to actions, or sensors to actuators, if you like. However, when an application gets above a certain size, it becomes complex to visually program and manage through Node-RED. There are some features to help with this, e.g. sub-flows (see lecture 5), but eventually the UI becomes a bottleneck.
  • 複雑で複数の機能を持つIoTアプリケーションの場合。Node-REDは迅速な開発、それからイベントやアクションをつなぐための「のり」としての役割においては、他を圧倒しますが、アプリケーションの規模がある程度大きくなってしまうと、ビジュアル・プログラミングで扱うには複雑すぎ、Node-REDで管理をするのが難しくなってきます。もちろんこの問題をサポートする幾つかの機能はあります。例えばsub-flows(これはレクチャー5で扱います)などがありますが、しかしいつかはUIがボトルネックになるときがきます。
  • Flow-based programming is a programming model that is not always the most suitable for application development. In much the same way that certain programming languages excel at some tasks but not others, flow-based programming has its weaknesses. A good example are loops: Node-RED is cumbersome when handling loops.
  • フローベースのプログラミングは、アプリケーション開発にとって常に最適なモデルだとは限りません。あるプログラミング言語がある特定のタスクに向いていても、他のタスクについてはそうではないように、フローベースののプログラミング言語にも弱点があります。例えばループはNode-REDでは扱うのがとても面倒です。
  • Specific use cases. Flow-based programming is a general purpose model and not targeted or optimized for specific needs, for example Data Analytics or User Interface development. At the moment Node-RED has no specific support for these type of applications and no easy way to add such support. Obviously, because the underlying technology of Node-RED is JavaScript, you can leverage its capabilities for these needs. If want to use Node-RED to prototype something, one approach is to implement parts or all of your application in another language more suited to your task and use Node-RED for the overall control.
  • 特定のケース。フローベースのプログラミングは、汎用的な目的に使われるモデルであって、特定の目的のために最適化されていません。例えば、データアナリティクスやユーザーインタフェースの開発には向いていません。今のところNode-REDはこういった種類のアプリケーション開発をサポートしていませんし、それらの機能を追加するのも簡単ではありません。Node-REDはJavaScriptによってできているので、その能力を使うことでこういった問題に対処することはできます。Node-REDをプロトタイプの作成に使いたいのであれば、一つの方法として、アプリケーションでつかうパーツや、もしくはアプリケーション全体を、他のもっと適した言語で作成し、Node-REDは、全体をコントロールするためだけに使う方法があります。

Having said that, as has been shown in this lecture and will be demonstrated in the following lectures,  Node-RED is a powerful tool for a large number of IoT applications. As it evolves it will become both more sophisticated and more usable in a wider range of circumstances.

既に説明してきたように、Node-REDはかなり範囲の広いIoTアプリケーションにとってパワフルなツールです。進化続けてきたことで、様々な状況において便利で洗練された解決策を提供します。

Perhaps just as important, as you explore Node-RED in subsequent lectures, you will realise that although Node-RED’s roots are in the IoT, it is a tool that can be used to build a wide variety of applications, not just IoT applications. In fact, in these lectures you will see example of Node-RED being used for web apps, social media apps, back-office integration, IT task management, i.e. across the range of modern computing tasks.

Node-REDの続くレクチャーにおいて探求していくにつれてわかると思うのですが、Node-REDはIoTに軸足を持ちつつも、IoTだけではない、より広い範囲のアプリケーションをつくるためにも有効です。Node-REDをウェブアプリのために使ったり、SNSアプリのためにつかったり、バックオフィスの統合のために使ったり、ITタスクのマネジメントのために使うことができます。コンピューターを使っておこなわれるタスク全体をカバーします。

Our hope is that by the end of this lecture course, you will see Node-RED, as we do, as a flexible and powerful tool that can be used in many situations, both for prototyping but also for production level development.

このレクチャーを通して、Node-REDがフレキシブルで強力なツールであり、さまざまな状況で使うことができ、プロトタイプの作成にとっても、製品レベルの開発においても、有効であることが伝われば幸いです。

要約

Summary

In this lecture we’ve taken you through a high-level look at Node-RED. You’ve seen how Node-RED wires together building blocks, using a visual tool to rapidly create simple flows that actually carry out sophisticated real-world tasks. You’ve also learnt a little about the origins of Node-RED as a rapid application development tool for the IoT and how, as it has evolved, it’s now being used for a variety of tasks, not just IoT programming. Finally, we’ve discussed the limitations of Node-RED and indicated some areas where other languages and tools may serve you better. In the next lecture, we’ll start on some real programming and show you how to build your own flows using the basic nodes that Node-RED provides.

このレクチャーでは、Node-REDの概念について説明してきました。Node-REDはブロック同士を接続し、視覚的なツールをつかって速攻でシンプルなフローを作成し、洗練された方法で実世界のタスクを処理してくれます。またNode-REDの起源と歴史についても説明しました。IoTのためのツールで、迅速に開発するために生まれたのですそして今ではより広い範囲のタスクを処理するためにも使うことができ、IoTの範囲に留まりません。最後に、Node-REDの限界について検討し、一般的な他の言語やツールをもちいたほうがよいシーンについても考察しました。次のレクチャーでは、実際のプログラミングをしていきながら、フローを作成していきます。ここでは最初から組み込まれたノードを使っていきます。

WebStorm の設定を複数の端末で共有する

WebStorm の設定、例えばショートカットキーやエディター画面の色、等を Git で管理して、保存、参照することができます。現在の最新版、WebStorm 2017.1 には必要なプラグインが最初から入っています。

同期といってもローカルの設定を変更した場合に、それがリモートのリポジトリに勝手に反映されるのではないようです。ローカルでの変更をリモートのリポジトリに反映させたい場合には、File → Setting Repository から Overwrite Remote してあげればいいようです。

なので運用としては、常にローカルの設定をリモートと同期させておいて、ローカルで設定変更をしたら、それをリモートにプッシュ。でいいのではないでしょうか。

https://www.jetbrains.com/help/webstorm/2017.1/settings-repository.html

Sharing Your IDE Settings

On this page:

Introduction

WebStorm allows you to share your IDE settings between different instances of WebStorm (or other IntelliJ platform-based) products installed on different computers.

WebStorm は、複数の異なるコンピューターにインストールされていても、その設定を共有することができます。

This is useful if you are using several WebStorm installations, or want to implement the same settings among your team members or company-wide.

この機能は次の場合に有用です。例えばウェブストームを複数のパソコンにインストールしている場合や、同じ設定をチームメンバーや会社で共有したい場合です。

Prerequisites

 

Before you start working with Settings Repository, make sure that the Settings Repository plugin is enabled. The plugin is bundled with WebStorm and is activated by default. If the plugin is not activated, enable it on the Plugins page of the Settings / Preferences Dialog as described in Enabling and Disabling Plugins.

設定保存用のレポジトリでの作業をするまえに、まずは Setting Repository プラグインが有効になっていることを確認してください。このプラグインはウェブストームに最初から含まれており、初期設定で有効になっています。もし有効になっていなければ設定画面のプラグインページで有効にしてください。

Configuring settings repository

If you want to share your IDE settings, perform the following steps:

IDE の設定を共有するためには、次の作業をおこなってください。

  1. Create a Git repository on any hosting service, such as Bitbucket or GitHub.  Git リポジトリを Bitbucket や GitHub といたホスティングサービス上で作成してください。
  2. On the computer where the WebStorm instance whose settings you want to share is installed, navigate to File | Settings Repository. Specify the URL of the repository you’ve created and click Overwrite Remote.
    共有したい設定がされているウェブストームがインストールされているパソコンで次の作業をします。File → Settings Repository → 設定を保存するためのリポジトリのURLを記入します。その上で Overwite Remote を選択して、リポジトリに上書きします。
  3. On each computer where you want your settings to be applied, in the Settings/Preferences dialog, expand the Tools node and choose Settings Repository, specify the URL of the repository you’ve created, and click Overwrite Local.You can click Merge if you want the repository to keep a combination of the remote settings and your local settings. If any conflicts are detected, a dialog will be displayed where you can resolve these conflicts.
    次に、保存した設定を適用させたいパソコンでは次の作業をおこないます。Settings/Preferences → Tools → 先程作り設定を保存したリポジトリの URL を設定します。そして Overwrite Local をクリックしてローカルの設定を上書きします。もしリモートリポジトリの設定と自分のローカルの設定との組み合わせにしたい場合は、Merge を選択します。それによってコンフリクトが発生した場合は、そのコンフリクトを解消するようにダイアログが表示されます。If you want to overwrite the remote settings with your local settings, click Overwrite Remote.
    ローカルセッティングをリポジトリに上書きしたい場合には Overwrite Remote を選択します。

    Your local settings will be automatically synchronized with the settings stored in the repository each time you perform an Update Project or a Push operation, or when you close your project or exit WebStorm.

    ローカルの設定は自動的にリポジトリに保存された設定と、次のタイミングで同期します。プロジェクトをアップデートした時、プッシュした時、プロジェクトを閉じた時、ウェブストームを閉じたときです。

If you want to disable automatic settings synchronization, navigate to File | Settings | Tools | Settings Repository and disable the Auto Sync option. You will be able to update your settings manually by choosing VCS | Sync Settings from the main menu.

設定の自動同期を無効にしたい場合は、File → Setting → Tools → Settings Repository から Auto Sync を向こうにしてください。その場合は、VCS → Sync Setting から手動で同期を行うことができます。

Authentication

On the first sync, you will be prompted to specify a username and password.

It is recommended to use an access token for GitHub authentication. If, for some reason, you want to use a username and password instead of an access token, or your Git hosting provider doesn’t support it, it is recommended to configure theGit credentials helper.

Note that the macOS Keychain is supported, which means you can share your credentials between all IntelliJ Platform-based products (you will be prompted to grant access if the original IDE is different from the requestor IDE).

Configuring a read-only source

Apart from the Settings Repository, you can configure any number of additional repositories containing any types of settings you want to share, including live templates, file templates, schemes, deployment options, etc.

These repositories are referred to as Read-only sources, as they cannot be overwritten or merged, just used as a source of settings as is.

To configure such repositories, do the following:

  1. In the Settings/Preferences dialog, expand the Tools node and choose Settings Repository.
  2. Click /help/img/idea/2017.1/add_icon.png and add the URL of the GitHub repository that contains the settings you want to share.

Synchronization with the settings from read-only sources is performed in the same way as for the Settings Repository.

ScrollMagic のドキュメントを翻訳する

http://scrollmagic.io/docs/index.html

ランディングページで多用される、スクロール位置でトリガーされるアニメーションを実装するために便利なライブラリ、ScrollMagic について学びます。

今回は上から全部翻訳するのではなく、必要な順番に進めていきました。

結果できたもの

https://codepen.io/nakanishi/project/full/ZBwaVX/

Getting Started : How to use ScrollMagic

まずは次の記事を読むことで基礎的な使い方を理解。

https://github.com/janpaepke/ScrollMagic/wiki/Getting-Started-:-How-to-use-ScrollMagic

How does ScrollMagic work?

ScrollMagic はどのように動作しますか?

The principle design pattern of ScrollMagic is a controller[1] that has an arbirtary number of scenes[2] attached to it.

ScrollMagic は基本的に、controller[1] と、それに紐付けられる任意の下図の scenes[2] から構成されています。

  1. There is one controller for each scroll container. In most cases there is only one controller object and the scroll container is the browser window. But you can also use DIV elements for scrolling and even have multiple containers on your page. The controller also defines which direction should be scrolled (horizontal or vertical) and is responsible for keeping all scenes updated.

スクロールするコンテナ毎にそれぞれ1個の controller をもつようにします。大抵のサイトでは、ブラウザ・ウィンドウ用に1つのコントローラーをもつことになります。他にもスクロールする複数の要素を保つ場合には、複数のコントローラーを用意し、それぞれのスクロールに対して ScrollMagic を使うこともできます。controller は、どちらの方向に(縦か横か)スクロールするかを定義することができ、?また全てのシーンを常に最新の状態で保持します。

  1. A scene defines what should happen when, meaning at which scroll position. It can trigger animations, pin an element, change element classes or anything else you might desire.

Scene は、何が、いつ(つまりどのスクロールポジションで)始まるかを定義します。scene はアニメーションをトリガーしたり、要素を固定したり、要素のクラスを変更したり、他にもなんでもできます。

Defining the Controller

コントローラーを定義する

As mentioned above in most cases the scroll container is the browser window. To create a ScrollMagic controller with the default settings we use the main ScrollMagic.Controller()class. We create a new instance of it and assign it to a variable, so we can reference it later:

既に述べたように、多くの場合は controller はブラウザ・ウィンドウ用に一つだけ作成する場合が多いでしょう。ScrollMagic の controller を初期設定の状態で作成するには、ScrollMagic.Controller() クラスを使用します。これを用いて新しいインスタンスを作成し、これに対して変数を与えます。変数については後述します。

var controller = new ScrollMagic.Controller();

That’s it! Now for the more interesting part:

これだけです。では続いて、ScrollMagic の面白いパートに進みましょう。

Defining Scenes

Scene を定義する

Scenes are created by using the ScrollMagic.Scene() class. A ScrollMagic.Scene defines where the controller should react and how. Here we define a variable called “scene” and we’ll create a new ScrollMagic.Scene() instance.

Scene は ScrollMagic.Scene() クラスを用いて作成します。ScrollMagic.Scene は、どの位置から controller が反応し、そしてどのような動作をするかを定義します。次のコードで、scene という名前の変数を指定し、その中に ScrollMagic.Scene() で作成した新しいインスタンスを代入しましょう。

var scene = new ScrollMagic.Scene();

Inside ScrollMagic.Scene we can place an object of associated properties and values that are made available according to the docs
These options describe the behavior of our Scene and in order to figure out what value has what effect you can play around in the Scene Manipulation Example

ScrollMagic.Scene の中に、オブジェクトを配置することができます。このオブジェクトはプロパティと値を持ちます。どんなものが使用可能かは docs  を参照してください。これらのオプションでどのような挙動をシーンにさせるのかを定義します。どんな効果があるのかを Scene Manipulation Example で色々試してみてください。

var scene = new ScrollMagic.Scene({
  offset: 100, // start scene after scrolling for 100px
  duration: 400 // pin the element for 400px of scrolling
})

100px スクロールした後に scene をスタートさせて、400px スクロールするまで固定します。

Adding Scenes to Controller

Scene を コントローラーに追加する

In order to have the scenes react to the scrolling of the container we have to add our scene to the controller we defined at the very beginning…

scene をコンテナのスクロールに反応させるために、scene を controller に追加しなくてはいけません。そう、一番最初に定義した controller にです。

var scene = new ScrollMagic.Scene({
  triggerElement: '#pinned-trigger1', // starting scene, when reaching this element この要素にスクロールが到着したら、シーンを始めます
  duration: 400 // pin the element for a total of 400px 要素を400px固定します
})
.setPin('#pinned-element1'); // the element we want to pin 固定したい要素を指定します

// Add Scene to ScrollMagic Controller シーンを Controller に追加します
controller.addScene(scene);

If you desire multiple scenes at once you can pass them to the controller just as the example shows below:

一度に複数のシーンを追加したい場合には、次のように書くこともできます。

// Add Scene to ScrollMagic Controller
controller.addScene([
  scene1,
  scene2,
  scene3
]);

Instead of telling the controller what scenes to add you can also tell the scene to be added to a certain controller:

controller に対してどのシーンを追加するかを指定するのではなくて、シーンに対してどの controller に自分自身を追加するかを指定することもできます。

var scene = new ScrollMagic.Scene({
  triggerElement: '#trigger1'
})
.addTo(controller); // Add Scene to ScrollMagic Controller

var scene2 = new ScrollMagic.Scene({
  triggerElement: '#trigger2'
})
.addTo(controller); // Add Scene to ScrollMagic Controller

In the above example we’re using a technique called ”chaining” with the addTo(). If no Semicolon ends the line, we can continue adding ScrollMagic.Scene methods and ”chain” them together.

上記の例で、addTo()の部分でいわゆる「チェイニング」という技術を使っています。セミコロンが行の終わりにない場合には、ScrollMagic.Scene のメソッドを続けていくことができ、それによって連結していくことができます。

Next let’s start adding some animation to our scenes in the next Chapter: Tweens

Plugin: Velocity

ScrollMagic 単体よりも、Velocity.js と連携することでより多用なアニメーションを可能にすることが出来る。そのためのプラグインとメソッドについて。

http://scrollmagic.io/docs/animation.Velocity.html#Scene.setVelocity

This plugin is meant to be used in conjunction with the Velocity animation framework. It offers an easy API to trigger Velocity animations.

このプラグインは アニメーションのためのフレームワークである Velocity と連携するためのものです。これによって 簡単に Velocity のアニメーションをトリガーする API を使うことができます。

With the current version of Velocity scrollbound animations (scenes with duration) are not supported.
This feature will be added as soon as Velocity provides the appropriate API.

現在の Velocity のバージョンでは、scrollbound アニメーションは対応していません。(scene に duration を与えた場合) これは Velocity 側が適切な API を提供をしてくれれば、すぐに実現できます。

To have access to this extension, please include plugins/animation.velocity.js.

この拡張機能を使うには次のプラグインをインストールしてください。

Source:

(訳注:多分ここからも手に入る https://github.com/janpaepke/ScrollMagic/tree/master/scrollmagic)

Scene.setVelocity(elems, properties, options) → {Scene}

順番が逆になりますが、こちらのほうが重要なので。

Add a Velocity animation to the scene. The method accepts the same parameters as Velocity, with the first parameter being the target element.

Velocity アニメーションをシーンに追加します。このメソッドは Velocity と同じパラメーターを使うことができます。最初のパメーターは対象の要素になります。

To gain better understanding, check out the Velocity example.

より理解するために、次のサンプルを参照してください。Velocity example.

Parameters:

Scene.setVelocity(elems, properties, options) → {Scene}

Name Type Description
elems object | string One or more Dom Elements or a Selector that should be used as the target of the animation.

1つ以上の Dom 要素か、セレクタを指定します。これがアニメーションの対象となります

properties object The CSS properties that should be animated.

アニメーション用の CSS プロパティ

options object Options for the animation, like duration or easing.

アニメーションのためのオプション
例えば duration や easing

Source:
Returns:

Parent object for chaining. { Scene }

Example
// trigger a Velocity animation
scene.setVelocity("#myElement", {opacity: 0.5}, {duration: 1000, easing: "linear"});

Scene.removeVelocity(reset) → {Scene}

?あとで

Remove the animation from the scene. This will stop the scene from triggering the animation.

Using the reset option you can decide if the animation should remain in the current state or be rewound to set the target elements back to the state they were in before the animation was added to the scene.

Parameters:
Name Type Argument Default Description
reset boolean <optional> false If true the animation will rewound.
Source:
Returns:

Parent object for chaining. { Scene }

Example
// remove the animation from the scene without resetting it
scene.removeVelocity();

// remove the animation from the scene and reset the elements to initial state
scene.removeVelocity(true);

Plugin: addIndicators

http://scrollmagic.io/docs/debug.addIndicators.html#Scene.removeIndicators

This plugin was formerly known as the ScrollMagic debug extension. It enables you to add visual indicators to your page, to be able to see exactly when a scene is triggered.

このプラグインは以前 ScrollMagic debug extension と呼ばれていました。このプラグインを使うことで、ページにデバグ用のインジケーターを追加し、視覚的にシーンがいつトリガーされるのかを確認することができます。

To have access to this extension, please include plugins/debug.addIndicators.js.

Source:

 

new ScrollMagic.Controller(options)

Every ScrollMagic.Controller instance now accepts an additional option.
See ScrollMagic.Controller for a complete list of the standard options.

それぞれの ScrollMagic.Controller インスタンスは、追加オプションを受け取ることができます。受け取ることが出来るオプションの全リストは ScrollMagic.Controller をみてください。

Parameters:

Name Type Argument Description
options object <optional> Options for the Controller.

Properties

Name Type Argument Default Description
addIndicators boolean <optional> false If set to true every scene that is added to the controller will automatically get indicators added to it.

true を指定すると、このコントローラーに追加された全てのシーンに対して、自動的にインジケーターを表示するようになります。

Source:

Example

// make a controller and add indicators to all scenes attached
// コントローラーを作り、このコントローラーに追加される全てのシーンに対して、インディケーターを表示させる
var controller = new ScrollMagic.Controller({addIndicators: true});

// this scene will automatically have indicators added to it
// 次のコードで作成されたシーンは自動的にインディケーターが表示されます

new ScrollMagic.Scene()
               .addTo(controller);

triggerHook

http://scrollmagic.io/docs/ScrollMagic.Scene.html#constructor

これはシーンが持つことができるオプションの一つで、シーンのトリガー位置を微調整できる。( ここで試すといい http://scrollmagic.io/examples/basic/scene_manipulation.html )

triggerHook number | string  トリガーフックの持つことが出来るパラメーターは数字か文字列
デフォルトの設定は “onCenter”
Can be a number between 0 and 1 defining the position of the trigger Hook in relation to the viewport. 0から1までの数字を設定でき、これによってどの視線位置(ブラウザのどの位置)からトリガーを開始するかを指定する。

Can also be defined using a string: 次のように文字列で指定することもできる。

“onEnter” => 1 //これはブラウザの一番下の部分でスタートさせる
“onCenter” => 0.5 //これはブラウザの真ん中
“onLeave” => 0 // これはブラウザの一番上でスタート

// create a standard scene and add it to a controller
new ScrollMagic.Scene()
.addTo(controller);

// create a scene with custom options and assign a handler to it.
var scene = new ScrollMagic.Scene({
duration: 100,
offset: 200,
triggerHook: “onEnter”,
reverse: false
});

reverse

これも triggerHook と同じで、シーンが持つことができるオプションの一つで、スクロール位置を戻した時に、アニメーションを逆再生するかしないかを指定する。

boolean をとる
true が初期値
Should the scene reverse, when scrolling up? スクロールを戻した時に、アニメーションを逆再生させるかどうかを指定する。

CodePen Project 機能がやってきた! 有料会員になった!

CodePen の新機能、Project がやってきた!

たくさんの人達にサポートしてもらいながら、日々圧倒的成長をさせていただいているわけですが、「人間以外」では、CodePen に一番お世話になっています。コンパイルが必要な Sass や ES6 に対応しているし、jQuery や Vue.js といった外部ソースも使えるので、すぐにコードを試すことができます。実務でうまくいかないコードは、一旦 CodePen のシンプルな環境で実装することで切り抜けてきました。ありがとう CodePen。

そんなコードペンに大型新機能登場ということで、ついに有料会員になり、実際につかってみました。

結論から言うと、Sass, ES6 をコンパイルしてくれる。Webpack を使えるので import export もできる。普通のウェブサイトとしてディプロイできる。です。特に import export できるので、今まで CodePen でできなかった可能性が広がります。

作ったやつはこれです。

出来たページ https://6af12e09bc6d4b859434da10c5631970.codepen.website

エディター https://codepen.io/nakanishi/project/editor/DWRrRA/

まずは、恒例の勝手に全文日本語訳です。公式サイトの発表記事です。実際に自分が作業したメモは一番下です。

CodePen Projects Is Here!

CodePen Projects Is Here!

CodePen にプロジェクト機能がやってきました!

What is CodePen Projects?

コードペン・プロジェクトとはなんですか?

If you’re familiar with the term, you can think of it as an IDE (Integrated Development Environment) for building websites. Like all of CodePen, you use it right in your web browser.

プロジェクトという用語を聞いたことがあれば、IDE のことを思いうかべたはずです。このプロジェクト機能は、CodePen の他の機能と同じように、ウェブブラザ上で使うことが出来ます。

You have a sidebar with all your files. You can create new files and folders there (even by drag and dropping from your computer), as well as delete, duplicate, and rename them.

スライドバーの中にプロジェクトに使用するすべてのファイルがあるのがわかります。新しいファイルやフォルダをこの中に作成することができます。(自分のコンピューターからドラッグ・アンド・ドロップで追加することも出来ます) もちろん削除や、複製や、リネームも可能です。

You can view, edit, and rearrange your files in separate tabs.

各ファイルを編集するために、それぞれ別のタブを開くことができます。

Files can be preprocessed and tidied.

各ファイルはプリプロセッサで処理され、出力されます。

There is debugging in that your code can be checked for errors and you will be notified of problems.

デバグ機能を搭載していているので、コードにエラーがないかチェックし、問題を指摘してくれます。

 

You can preview what you are building as you build it.

リアルタイムにプレビューされます。

The CodePen Project Editor is both very powerful and very comfortable. There is no setup, you just start using it.

コードペン・プロジェクト・エディターは、パワフルで、しかも快適です。セットアップも必要ありませんから、すぐに使い始めることが出来ます。

Aside from this blog post, you can also check out our dedicated page for explaining Projects, as well as our documentation.

このブログの他にも、次の3つの記事も参照してください。

How Does it Work?

どうやって動いているの?

If you want a peek behind the curtains of how CodePen Projects works, stay tuned to CodePen Radio where we’ll be discussing that in coming weeks.

コードペンプロジェクトがどのように動いているのか知りたい人は、CodePen Radio をチェックしてください。数週間以内にこのテーマについて話をする予定です。

Here’s a high-level overview. When you start a new project or open an existing one, you have a direct connection to a real mini-server in the cloud. It’s actually a Docker container, set up just for this, with a real file system including all your files.

かなり大雑把に言えば次の様になっています。プロジェクトをスタートしたり既にあるプロジェクトを開くと、クラウド上にある実際のサーバーにアクセスします。具体的にはこのプロジェクトのために用意された Docker コンテナで、ここにあなたのアップロードしたすべてのファイルも配置されています。

When you add/delete/edit (then save) files, we’re watching that file system and doing the things we need to do to make it work. For example, we’ll process all the files (with our Gulp build process) and put them into place, and refresh your preview window. If you use Live View, it will update that as well.

あなたがファイルを追加したり、削除したり、編集して、保存をすると、我々のサーバーはそれを監視しているので、すぐにそれらの操作に対して、必要な作業を行います。例えば、ファイルを Gulp によるビルド・プロセスで処理し、その結果を適切な場所に配置し、そしてあなたが見ているウィンドウを再描画します。Live View 機能を使っていれば、それも同時に再描画します。

What Happens to Pens?

CodePen の標準機能はどうなりますか?

Nothing! The Pen Editor is here to stay. We often say it’s the heart and soul of CodePen. There are well over 10,000,000 Pens created with it.

何も変わりません!Pen Editor はそのままです。日頃からお伝えしていることですが、Pen Editor は CodePen の心臓であり、魂であります。優に1000万を超える Code があるんですから!

The Pen Editor and the Project Editor will co-exist. You can use whichever one makes sense to use for any given thing you are working on.

Pen Editor と Project Editor は共存していきます。あなたのプロジェクトに最適なほうを選んで使ってください。

How is it Different to the Pen Editor?

どんなところが Pen Editor と Project Editor では異なりますか?

Aside from being able to have multiple files and assets all together in one project, it isn’t too much different!

違いがあるのは唯一、Project Editor は複数のファイルや、画像などのアセットを一つのプロジェクトで使用できることができる点だけなので、そこまで違いはありません!

We try to make coding as comfortable as possible in both.

どちらの機能も、最大限快適なコーディングができるように努力していきます。

You Can Deploy & Domain Map Your Projects

自分のプロジェクトをディプロイし、独自ドメインと結びつけることができます

This deserves some of these: !!!!!

これはかなりすごいことですよ!

We think sharing a URL to the Project Editor is extremely cool. Like Pens, you’re getting to see the behind-the-scenes action of how the web is built. And with the live preview, you aren’t just looking at the code, but what the code is doing.

プロジェクトエディターは、ペンエディターと同じように、そのプロジェクトをシェアするための URL を発行しますが、この機能を私たちはとても気に入っています。これによってウェブサイトがどのように作られているのか、その裏側を見ることができるからです。しかもライブ・プレビューしてくれるので、コードを見るだけではなく、実際にコードが何をしてくれるのかも見ることが出来ます。

But we also want you to be able to build real things with CodePen Projects that are for the world to see. We want you to be able to share a website you’ve built without any of the CodePen interface. Just a website like any other.

しかしそれだけではなくて、さらに、皆さんが「本物」をコードペンプロジェクトで作り、そしてそれを世界中に公開できるようにもしたいと思ったのです。みなさんがつくったウェブサイトを、コードペンのインターフェイスが邪魔しない形で、公開できるようにするということです。シンプルなウェブサイトとしてです。

You can deploy a website to a special CodePen URL at any time. That will be an exact copy of your website. It is entirely public, for anyone to see.

プロジェクトエディターで作ったウェブサイトを、どのタイミングでも、特別な CodePen URL にたいしてディプロイすることが出来ます。これはあなたがエディターで作ったウェブサイトの完全なコピーです。完全にパブリックで、誰でも見ることが出来ます。

Deployments are on demand. Your deployed website will not change until you deploy it again. That’s nice, because it means you can work on your project without affecting the deployed site. Development and production!

ディプロイは自分の好きなタイミングで行うことが出来ます。また、一度ディプロイしたものは、再度ディプロイするまでは更新されません。これは気が利いた機能だと思うのですが、この仕様のおかげで、ディプロイしたサイトに影響をあたえることなく、自分のプロジェクトを編集することができます。

Taking this one step further, you’re able to map a real domain name to your deployed project. We give you IP addresses you can point DNS A-records at. Then your CodePen Project just becomes the way you manage your own website!

さらになんと、プロジェクトエディターで作ったサイトを、独自に用意したドメイン・ネームと結びつけることもできます。Codepe が IP アドレスを用意しますので、これを DNS の A レコードに設定できます。 つまり、あなたがコードペンプロジェクトで作ったものを、自分のサイトとして管理することができるのです!

Differences in PRO Plans

PRO プランとの違い

Free users are limited to one Project with 10 CodePen-hosted files, but otherwise all the same coding features that everyone else gets.

無料ユーザーは、1つのプロジェクトを作ることしか出来ません。また 10 個のファイルを保持することしか出来ません。しかし、それ以外のコーディングに関する機能は、無料ユーザーもすべてを使うことが出来ます。

PRO is really where Projects shines. Of course you get more Projects to work with with more files allowed per Project. Also, you get the deployment and domain mapping features we talked about. You’ll also get other PRO features you’re used to getting from CodePen, like Live View. Live View is great for writing code full-screen in one browser window and previewing in another. Not to mention testing across different devices in real time.

PRO ユーザーになっていただけば、プロジェクト機能を本当に輝いた形で使用をできます。まず無料ユーザーよりもよりたくさんのプロジェクトを立ち上げることが出来ますし、より多くのファイルを使うことができます。そして、ディプロイ機能と独自ドメインとのヒモ付もできます。他にも Live View のように、CodePen の Pro ユーザーに提供していた機能も、使用できるものがあります。Live View 機能は、コーディングはフルスクリーンのブラウザでしておいて、それを他の端末でプレビューすることが出来ます。いうまでもなくこれは様々なデバイスでリアルタイムにテストするのに最適です。

Here’s the breakdown:

Examples / Templates

When you start a brand new Project, you’ll see an (ever evolving) set of template projects in the sidebar:

まずプロジェクトを開始すると、テンプレートプロジェクトがスライドバーにあることに気がつくはずです。(このテンプレートの数は、常に増え続けています)

You don’t have to use those, they are just there to give you some ideas or demonstrate how different types of Projects might work. If you upload a file or manually create one, those template options will disappear and you can work from scratch.

この機能は必ずしも使わなくてはいけないわけではありませんが、どんなことができるのかというアイデアを与えてくれますし、また様々なタイプのプロジェクトがどんなふうに機能するのか、ということを確認することが出来ます。自分のファイルをアップロードしたり、作成した後には、このテンプレートオプションはなくなります。そしてそこからは自分の作業をはじめることができます。

You can also Explore Projects to find other folks interesting work:

他の人が作った面白いプロジェクトを探してみるのもいいでしょう。

Things Will Evolve

進化し続けます

This should go without saying, but of course, this is just our first release of Projects, and we have lots of ideas for improving it as we go.

いうまでもなく、これは私達の最初のリリースにすぎません。まだまだ改善のアイデアがありますので、それに取り組んでいきます。

If you have questions or comments, as always, hit us up in support.

疑問や意見があれば、どんなものでもいいで、教えてください。

ということで使ってみる

まずはプリプロセッサ

File Processing in Projects

対応しているものに関しては、拡張子をつけると勝手に処理してくれる。

読み込むときは、この.processed.こみの名前のファイルを読み込むと。

なるほど。

Autoprefix もしてくれる

このトグルスイッチ、日本人的には非常にわかりにくいんですが、白い丸ボタンが寄ってる方が選ばれてます。つまり下の画像なら、Autoprefixer 使う、Webpack と Babel 使う、です。

確かにしてくれる。(とはいえこれは CodePen にもあった)

WebPack も使える !?

Using Babel in your CodePen Project

まずは app.js で import する。

WebPack と Babel を ON にして、エントリーポイント、つまり Webpack がまとめてくれる対象を決める。

で、それを HTML で読み込む。

順番が前後してしまいましたが、import の対象のファイルを作る。

おおお!!! import 出来ている!!!!

なお、エラーチェックをすると、ES6 を使えなさそうな雰囲気の赤い帯が出るが、もちろん使えます。紛らわしい!Babel で処理してくれてるじゃん!

できたやつ!

出来たページ https://6af12e09bc6d4b859434da10c5631970.codepen.website

エディター https://codepen.io/nakanishi/project/editor/DWRrRA/

ディプロイはさらに一個上の有料アカウントじゃないとできない…

さらに一個上の有料アカウントは高いのと、別のサーバーに自分のドメインで公開すればいいだろう!ということで、やりませんでした。

けっこういい!

せっかく有料会員になったのでガンガン使っていきたいと思います。

npm とは何か / Package と module の違い

npm とは何か

例によって公式ドキュメントを勝手に日本語にします。

What is npm?

npm makes it easy for JavaScript developers to share and reuse code, and it makes it easy to update the code that you’re sharing.

npm は JavaScript 開発者がコードを共有したり、使いまわすことを簡単にしてくれます。またシェアしているコードをアップデートすることも簡単にしてくれます。

If you’ve been working with Javascript for a while, you might have heard of npm: npm makes it easy for Javascript developers to share the code that they’ve created to solve particular problems, and for other developers to reuse that code in their own applications.

JavaScript の開発をしている人であれば npm のことは聞いたことがあるはずです。npm を使えば、開発者は問題を解決するために使ったコードを多くの人と簡単に共有することが出来るので、他の開発者はそれを自分のアプリケーションで使うことができるようになります。

Once you’re depending on this code from other developers, npm makes it really easy to check to see if they’ve made any updates to it, and to download those updates when they’re made.

npm によって管理されているコードを使えば、そのコードにアップデートがある場合、すぐに確認してダウンロードすることができます。

These bits of reusable code are called packages, or sometimes modules. A package is just a directory with one or more files in it, that also has a file called “package.json” with some metadata about this package. A typical application, such as a website, will depend on dozens or hundreds of packages. These packages are often small. The general idea is that you create a small building block which solves one problem and solves it well. This makes it possible for you to compose larger, custom solutions out of these small, shared building blocks.

これらの再利用可能なコードの断片を「Packages」と呼びます。もしくはモジュールという場合もあります。パッケージは単なるディレクトリで、その中にはファイルがあります。この中には package.json というファイルもあります。これにはそのパッケージに関するメタデータが記録されています。例えばウェブサイトのような典型的なアプリケーションは、何百ものパッケージを用いています。これらのパッケージ一つ一つは大抵の場合、小さなものです。一般的な考えとして次のようなものがあります。問題一つをうまく解決してくれる小さなブロックを作るのがよい。そしてその小さなブロックをつかってより大きく、個別性の高い問題の解決策を作ることが出来ます。

There’s lots of benefits to this. It makes it possible for your team to draw on expertise outside of your organization by bringing in packages from people who have focused on particular problem areas. But even if you don’t reuse code from people outside of your organization, using this kind of module based approach can actually help your team work together better, and can also make it possible to reuse code across projects.

こういった考え方を推進するにあたって npm は大きな貢献します。パッケージを使用することで、外部のある特定の問題についての専門家の助言を採用するのと同じ利益を享受します。もちろん誰か他の人が作ったパッケージを使用しなくても、自分の組織内でうまく再利用可能なコードを作るためにも npm は役に立ちます。

You can find packages to help you build your application by browsing the npm website. When you’re browsing the website, you’ll find different kinds of packages. You’ll find lots of node modules. npm started as the node package manager, so you’ll find lots of modules which can be used on the server side. There are also lots of packages which add commands for you to use in the command line. And at this point you can find a number of packages which can be used in the browser, on the front end.

自分に役立ちそうなパッケージを探すためには npm のウェブサイト検索してください。たくさんのパッケージがありますが、npm は node 用のパッケージとしてスタートしたものなので、サーバーサイドで動くモジュールがたくさんあります。またコマンドラインで実行できるコマンドを増やすパッケージもあります。また現在ではブラウザーで動く、つまりフロントエンド用のパッケージもあります。

So now that you have an idea of what npm can do, let’s talk about how it works. When people talk about npm, they can be talking about one of three things. They could be talking about the website, which we’ve just been looking at. Or they could be talking about the registry, which is a big database of information about packages that people are sharing. Or the third thing they could be talking about is the client: when a developer decides to share their code, they use the npm client which is installed on their computer to publish that code up to the registry. And once there’s an entry for this package in the registry, then other developers can use their npm clients to install the package from the registry. The entry in the registry for this package is also reflected on the website, where there’s a page dedicated to this new package.

さあ npm がどんなことをしてくれるか概要がわかったと思うので、今度は npm がどのように機能しているのかについてお話しします。npm について誰かが話題にしていたら、これは次の3項目のうちのどれかについて話をしています。まずはウェブサイトについてです。これについては今までお話してきましたね。次に、レジストリについて話してる場合もあります。ここでいうレジストリとは、公開されたパッケージに関する膨大な情報をもったデータベースのことです。最後にクライアントについてです。開発者がコードを共有する場合に npm クライアントを用いてレジストリにコードを公開します。そして他の人が npm クライアントを用いてそのコードを使います。公開されたコードウェブサイトに使われます。

So that’s what npm is. It’s a way to reuse code from other developers, and also a way to share your code with them, and it makes it easy to manage the different versions of code.

npm がどのようなものかわかりましたね。npm は第三者が開発したコードを再利用する方法であり、開発者がコードを共有するための方法であり、そしてそれらのコードのバージョンを管理しやすくしてくれるシステムです。

Package と module の違いとは

https://docs.npmjs.com/how-npm-works/packages

One of the key steps in becoming immersed in an ecosystem is learning its vocabulary. Node.js and npm have very specific definitions of packages and modules, which are easy to mix up. We’ll discuss those definitions here, make them distinct, and explain why certain default files are named the way they are.

ある生態系について詳しくなるためには用語を学ぶことが重要です。Node.js と npm はパッケージとモジュールについてかなり詳細な定義をしています。そしてこれは混同しやすいです。これらの定義について説明しながら、明確にし、なぜ module と呼ばれるものと package と呼ばれるものがあるのかを説明します。

Quick Summary

  • A package is a file or directory that is described by a package.json. This can happen in a bunch of different ways! For more info, see “What is a package?, below.
  • A module is any file or directory that can be loaded by Node.js’ require(). Again, there are several configurations that allow this to happen. For more info, see “What is a module?”, below.
  • パッケージは package.json によって記述されるファイルもしくはディレクトリです。これは様々な方法でブランチを作ります。
  • モジュールは Node.js の require() によってロードされるファイルもしくはでょレクトリです。

What is a package?

平たくいってa)だけが重要。package.json を含んでいるということ。それを圧縮したり、url だったり色々形式はあるとのこと。

A package is any of the following:

a) a folder containing a program described by a package.json file
b) a gzipped tarball containing (a)
c) a url that resolves to (b)
d) a <name>@<version> that is published on the registry with (c)
e) a <name>@<tag> that points to (d)
f) a <name> that has a latest tag satisfying (e)
g) a git url that, when cloned, results in (a).
Noting all these package possibilities, it follows that even if you never publish your package to the public registry, you can still get a lot of benefits of using npm:

if you just want to write a node program, and/or
if you also want to be able to easily install it elsewhere after packing it up into a tarball
Git urls can be of the form:

git://github.com/user/project.git#commit-ish
git+ssh://user@hostname:project.git#commit-ish
git+http://user@hostname/project/blah.git#commit-ish
git+https://user@hostname/project/blah.git#commit-ish

The commit-ish can be any tag, sha, or branch which can be supplied as an argument to git checkout. The default is master.

What is a module?

A module is anything that can be loaded with require() in a Node.js program. The following are all examples of things that can be loaded as modules:

モジュールは Node.js の require() によってロードされるものです。次リストはモジュールとしてロードされるものの例です。

  • A folder with a package.json file containing a main field.
  • main フィールドを持つ package.json があるフォルダー
  • A folder with an index.js file in it.
  • index.js ファイルを持つフォルダー
  • A JavaScript file.
  • ただのJavaScript ファイル

Most npm packages are modules

Generally, npm packages that are used in Node.js program are loaded with require, making them modules. However, there’s no requirement that an npm package be a module!

大抵の場合 npm パッケージは Node.js の中でロードされます。ということはモジュールだということです。しかしながら、npm パッケージが必ずしも module である必要はありません。

Some packages, e.g., cli packages, only contain an executable command-line interface and don’t provide a main field for use in Node.js programs. These packages are not modules.

パッケージには、例えばCLI 用のパッケージなどは、コマンドラインで実行できるコマンドを含んでいるだけで、Node.js が使う main フィールドがないものがあります。こういったパッケージはモジュールではありません。

Almost all npm packages (at least, those that are Node programs) contain many modules within them (because every file they load with require() is a module).

ほとんどすべての npm パッケージは、(少なくともノードプログラムの場合には) たくさんのモジュールを内部に持っています。(なぜならノードの require() によってロードされるファイルはモジュールだからです。)

In the context of a Node program, the module is also the thing that was loaded from a file. For example, in the following program:

ノードのプラグラムにおいては、モジュールはファイルからロードされるものでもあります。例えば次のコードをみてください。

var req = require(‘request’)

we might say that “The variable req refers to the request module”.

このコードは「変数 rew は request モジュールを参照している」ということをいています。

File and Directory Names in the Node.js and npm Ecosystem

So, why is it the node_modules folder, but package.json file?
Why not node_packages or module.json?

なぜ node_modules フォルダーという名前で、そしてその中には package.json ファイルがあるのでしょうか。またなぜ node_package というファイルに module.json というファイルがあってはだめだったのでしょうか。

The package.json file defines the package. (See “What is a package?”, above.)

package.json ファイルはパッケージを定義しています。

The node_modules folder is the place Node.js looks for modules. (See “What is a module?”, above.)

node_modules フォルダは Node.js が「モジュールを探しに行く場所」です。

For example, if you create a file at node_modules/foo.js and then had a program that did var f = require(‘foo.js’), it would load the module. However, foo.js is not a “package” in this case because it does not have a package.json.

例えば node_modules の中に foo.js というファイルを作って、さらにそれを var f = require(‘foo.js’) とロードするプログラムを書いたとすると、これはモジュールをロードしていることになります。しかしながら、foo.js はパッケージではありません。なぜならpackage.json を持っていないからです。

Alternatively, if you create a package which does not have an index.js or a “main” field in the package.json file, then it is not a module. Even if it’s installed in node_modules, it can’t be an argument to require().

またパッケージを作ったとしても、index.js をもたないか、もしくはpackage.json に main フィールドを持たない場合、これはモジュールではありません。例え node_modules の中にあったとしても、require() の対象にはなりません。

npm script を調べる

なぜ npm script  に興味を持ったか

Sass を CSS にコンパイルしたり、ES6 を ES5 に変換したり、こまごました作業を今は Gulp で実行する人が多いと思います。Gulp は Node.js 上で動いており、Gulp で require() している対象は Node のモジュール = Node Package Module = npm  です。ということは npm のことがもっとわかれば Gulp のこともわかるはずだ、というのが npm についてもっと調べようと思った理由の一つです。

もう一つの理由は、これが直背的な理由なのですが、Gulp で Gulp 用のプラグインを使うためには、Gulp に特化した記法の学習が必要で(基本的な用途であればそこまで難しくないのですが)、それよりも CLI(コマンドラインインターフェイス、つまり Mac ならターミナルからコマンドで実行する方法など) のほうが楽だという流れがあるらしく、たしかにいくつかの作業は CLI から直接 npm を実行したほうが簡単にできました。(例えば Browserify のビルドを、対象のファイルをウォッチして、さらに差分だけをビルドする作業は、Wachify を CLI から実行すると非常に簡単です。しかし Gulp-watchify を使って Gulp のタスクを書くのは私には非常に複雑に思えました) そしてこの CLI で実行するためのコマンドは、package.json に npm script という形で記述すれば、CLI から npm start といった簡略したコマンドで実行できることもわかりました。ですので、この npm script という仕組みをより学べば、npm を実行する方法をより理解することができると思いました。

さらに具体的には、一部の npm は CLI で実行する際に明記するオプションを、どうやら package.json の中にかけるのですが、これがどういった仕組みで参照されているのかわからなかったので、npm script についての理解をもっと根本的にする必要を感じました。具体的には次のような packgage.json ファイルです。(引用元)

babel, browserify といった項目があり、これが明らかに CLI で npm を実行する際に必要なオプションの内容であるのは間違いないのですが、なぜここに書いて参照されるのか謎でした。

{
  "name": "front-end-starter",
  "version": "1.2.0",
  "description": "This is a starter kit of the Web front-end development.",
  "author": "akabeko",
  "license": "MIT",
  "main": "index.js",
  "keywords": [
    "web",
    "frontend",
    "starter"
  ],
  "repository": {
    "type": "git",
    "url": "https://github.com/akabekobeko/examples-web-app"
  },
  "babel": {
    "presets": [
      "latest"
    ],
    "env": {
      "development": {
        "presets": [
          "power-assert"
        ]
      }
    }
  },
  "browserify": {
    "transform": [
      "babelify"
    ]
  },
  "esdoc": {
    "source": "./src/js",
    "destination": "./esdoc",
    "test": {
      "type": "mocha",
      "source": "./test"
    }
  },
  "scripts": {
    "test": "mocha --compilers js:babel-register test/**/*.test.js",
    "start": "npm run watch",
    "esdoc": "esdoc",
    "build:css": "stylus -c --include-css ./src/stylus/App.styl -o ./src/assets/bundle.css -m --sourcemap-base ../stylus",
    "build:js": "browserify ./src/js/App.js -d | exorcist ./src/assets/bundle.js.map &amp;amp;amp;gt; ./src/assets/bundle.js",
    "build": "npm-run-all -p build:css build:js",
    "watch:css": "stylus -c -w --include-css ./src/stylus/App.styl -o ./src/assets/bundle.css -m --sourcemap-base ../stylus",
    "watch:js": "watchify ./src/js/App.js -v -o \"exorcist ./src/assets/bundle.js.map &amp;amp;amp;gt; ./src/assets/bundle.js\" -d",
    "watch:server": "browser-sync start --server ./ --startPath src/assets/",
    "watch": "npm-run-all -p watch:css watch:js watch:server",
    "release:css": "stylus -c --include-css ./src/stylus/App.styl -o ./dist/bundle.css",
    "release:js": "cross-env NODE_ENV=production browserify ./src/js/App.js | uglifyjs -c warnings=false -m &amp;amp;amp;gt; ./dist/bundle.js",
    "release:clean": "rimraf ./dist",
    "release:copy": "cpx \"./src/assets/**/!(*.js|*.css|*.map)\" ./dist",
    "release": "npm-run-all -s release:clean release:copy -p release:css release:js"
  },
  "dependencies": {
    "normalize.css": "^5.0.0"
  },
  "devDependencies": {
    "babel-preset-latest": "^6.16.0",
    "babel-preset-power-assert": "^1.0.0",
    "babel-register": "^6.18.0",
    "babelify": "^7.3.0",
    "browser-sync": "^2.18.6",
    "browserify": "^13.3.0",
    "cpx": "^1.5.0",
    "cross-env": "^3.1.4",
    "esdoc": "^0.5.2",
    "exorcist": "^0.4.0",
    "mocha": "^3.2.0",
    "npm-run-all": "^4.0.0",
    "power-assert": "^1.4.2",
    "rimraf": "^2.5.4",
    "stylus": "^0.54.5",
    "uglify-js": "^2.7.5",
    "watchify": "^3.8.0"
  }
}

例えば CLI で Browserify を実行するためには、次のように transform オプションを入力しますが、上記の npm script “build:js”には全く書いておらず、そのかわりにそれに相当する文言は繰り返しになりますが package.json に書かれています。

$ browserify main.js -o app.js -transform [ babelify --presets [ es2015 ] ] --debug

ということで、npm と npm script への理解を深めれば、環境構築のための基礎知識が深まり、根本的な理解をすることができるようになる、というのが今回の動機です。

npm とは

例によって公式ドキュメントを勝手に日本語にします。(もちろん日本語で npm を詳細に解説しているサイトは無限にあるのですが、最終的には自分で公式ドキュメントを読まなくてはいけないフェーズが必ずくるので、なるべくは公式を読むようにしています)

What is npm?

npm makes it easy for JavaScript developers to share and reuse code, and it makes it easy to update the code that you’re sharing.

npm は JavaScript 開発者がコードを共有したり、使いまわすことを簡単にしてくれます。またシェアしているコードをアップデートすることも簡単にしてくれます。

If you’ve been working with Javascript for a while, you might have heard of npm: npm makes it easy for Javascript developers to share the code that they’ve created to solve particular problems, and for other developers to reuse that code in their own applications.

JavaScript の開発をしている人であれば npm のことは聞いたことがあるはずです。npm を使えば、開発者は問題を解決するために使ったコードを多くの人と簡単に共有することが出来るので、他の開発者はそれを自分のアプリケーションで使うことができるようになります。

Once you’re depending on this code from other developers, npm makes it really easy to check to see if they’ve made any updates to it, and to download those updates when they’re made.

npm によって管理されているコードを使えば、そのコードにアップデートがある場合、すぐに確認してダウンロードすることができます。

These bits of reusable code are called packages, or sometimes modules. A package is just a directory with one or more files in it, that also has a file called “package.json” with some metadata about this package. A typical application, such as a website, will depend on dozens or hundreds of packages. These packages are often small. The general idea is that you create a small building block which solves one problem and solves it well. This makes it possible for you to compose larger, custom solutions out of these small, shared building blocks.

これらの再利用可能なコードの断片を「Packages」と呼びます。もしくはモジュールという場合もあります。パッケージは単なるディレクトリで、その中にはファイルがあります。この中には package.json というファイルもあります。これにはそのパッケージに関するメタデータが記録されています。例えばウェブサイトのような典型的なアプリケーションは、何百ものパッケージを用いています。これらのパッケージ一つ一つは大抵の場合、小さなものです。一般的な考えとして次のようなものがあります。問題一つをうまく解決してくれる小さなブロックを作るのがよい。そしてその小さなブロックをつかってより大きく、個別性の高い問題の解決策を作ることが出来ます。

There’s lots of benefits to this. It makes it possible for your team to draw on expertise outside of your organization by bringing in packages from people who have focused on particular problem areas. But even if you don’t reuse code from people outside of your organization, using this kind of module based approach can actually help your team work together better, and can also make it possible to reuse code across projects.

こういった考え方を推進するにあたって npm は大きな貢献します。パッケージを使用することで、外部のある特定の問題についての専門家の助言を採用するのと同じ利益を享受します。もちろん誰か他の人が作ったパッケージを使用しなくても、自分の組織内でうまく再利用可能なコードを作るためにも npm は役に立ちます。

You can find packages to help you build your application by browsing the npm website. When you’re browsing the website, you’ll find different kinds of packages. You’ll find lots of node modules. npm started as the node package manager, so you’ll find lots of modules which can be used on the server side. There are also lots of packages which add commands for you to use in the command line. And at this point you can find a number of packages which can be used in the browser, on the front end.

自分に役立ちそうなパッケージを探すためには npm のウェブサイト検索してください。たくさんのパッケージがありますが、npm は node 用のパッケージとしてスタートしたものなので、サーバーサイドで動くモジュールがたくさんあります。またコマンドラインで実行できるコマンドを増やすパッケージもあります。また現在ではブラウザーで動く、つまりフロントエンド用のパッケージもあります。

So now that you have an idea of what npm can do, let’s talk about how it works. When people talk about npm, they can be talking about one of three things. They could be talking about the website, which we’ve just been looking at. Or they could be talking about the registry, which is a big database of information about packages that people are sharing. Or the third thing they could be talking about is the client: when a developer decides to share their code, they use the npm client which is installed on their computer to publish that code up to the registry. And once there’s an entry for this package in the registry, then other developers can use their npm clients to install the package from the registry. The entry in the registry for this package is also reflected on the website, where there’s a page dedicated to this new package.

さあ npm がどんなことをしてくれるか概要がわかったと思うので、今度は npm がどのように機能しているのかについてお話しします。npm について誰かが話題にしていたら、これは次の3項目のうちのどれかについて話をしています。まずはウェブサイトについてです。これについては今までお話してきましたね。次に、レジストリについて話してる場合もあります。ここでいうレジストリとは、公開されたパッケージに関する膨大な情報をもったデータベースのことです。最後にクライアントについてです。開発者がコードを共有する場合に npm クライアントを用いてレジストリにコードを公開します。そして他の人が npm クライアントを用いてそのコードを使います。公開されたコードウェブサイトに使われます。

So that’s what npm is. It’s a way to reuse code from other developers, and also a way to share your code with them, and it makes it easy to manage the different versions of code.

npm がどのようなものかわかりましたね。npm は第三者が開発したコードを再利用する方法であり、開発者がコードを共有するための方法であり、そしてそれらのコードのバージョンを管理しやすくしてくれるシステムです。

Package と module の違いとは

https://docs.npmjs.com/how-npm-works/packages

One of the key steps in becoming immersed in an ecosystem is learning its vocabulary. Node.js and npm have very specific definitions of packages and modules, which are easy to mix up. We’ll discuss those definitions here, make them distinct, and explain why certain default files are named the way they are.

ある生態系について詳しくなるためには用語を学ぶことが重要です。Node.js と npm はパッケージとモジュールについてかなり詳細な定義をしています。そしてこれは混同しやすいです。これらの定義について説明しながら、明確にし、なぜ module と呼ばれるものと package と呼ばれるものがあるのかを説明します。

Quick Summary

  • A package is a file or directory that is described by a package.json. This can happen in a bunch of different ways! For more info, see “What is a package?, below.
  • A module is any file or directory that can be loaded by Node.js’ require(). Again, there are several configurations that allow this to happen. For more info, see “What is a module?”, below.
  • パッケージは package.json によって記述されるファイルもしくはディレクトリです。これは様々な方法でブランチを作ります。
  • モジュールは Node.js の require() によってロードされるファイルもしくはでょレクトリです。

What is a package?

平たくいってa)だけが重要。package.json を含んでいるということ。それを圧縮したり、url だったり色々形式はあるとのこと。

A package is any of the following:

a) a folder containing a program described by a package.json file
b) a gzipped tarball containing (a)
c) a url that resolves to (b)
d) a <name>@<version> that is published on the registry with (c)
e) a <name>@<tag> that points to (d)
f) a <name> that has a latest tag satisfying (e)
g) a git url that, when cloned, results in (a).
Noting all these package possibilities, it follows that even if you never publish your package to the public registry, you can still get a lot of benefits of using npm:

if you just want to write a node program, and/or
if you also want to be able to easily install it elsewhere after packing it up into a tarball
Git urls can be of the form:

git://github.com/user/project.git#commit-ish
git+ssh://user@hostname:project.git#commit-ish
git+http://user@hostname/project/blah.git#commit-ish
git+https://user@hostname/project/blah.git#commit-ish

The commit-ish can be any tag, sha, or branch which can be supplied as an argument to git checkout. The default is master.

What is a module?

A module is anything that can be loaded with require() in a Node.js program. The following are all examples of things that can be loaded as modules:

モジュールは Node.js の require() によってロードされるものです。次リストはモジュールとしてロードされるものの例です。

  • A folder with a package.json file containing a main field.
  • main フィールドを持つ package.json があるフォルダー
  • A folder with an index.js file in it.
  • index.js ファイルを持つフォルダー
  • A JavaScript file.
  • ただのJavaScript ファイル

Most npm packages are modules

Generally, npm packages that are used in Node.js program are loaded with require, making them modules. However, there’s no requirement that an npm package be a module!

大抵の場合 npm パッケージは Node.js の中でロードされます。ということはモジュールだということです。しかしながら、npm パッケージが必ずしも module である必要はありません。

Some packages, e.g., cli packages, only contain an executable command-line interface and don’t provide a main field for use in Node.js programs. These packages are not modules.

パッケージには、例えばCLI 用のパッケージなどは、コマンドラインで実行できるコマンドを含んでいるだけで、Node.js が使う main フィールドがないものがあります。こういったパッケージはモジュールではありません。

Almost all npm packages (at least, those that are Node programs) contain many modules within them (because every file they load with require() is a module).

ほとんどすべての npm パッケージは、(少なくともノードプログラムの場合には) たくさんのモジュールを内部に持っています。(なぜならノードの require() によってロードされるファイルはモジュールだからです。)

In the context of a Node program, the module is also the thing that was loaded from a file. For example, in the following program:

ノードのプラグラムにおいては、モジュールはファイルからロードされるものでもあります。例えば次のコードをみてください。

var req = require(‘request’)

we might say that “The variable req refers to the request module”.

このコードは「変数 rew は request モジュールを参照している」ということをいています。

File and Directory Names in the Node.js and npm Ecosystem

So, why is it the node_modules folder, but package.json file?
Why not node_packages or module.json?

なぜ node_modules フォルダーという名前で、そしてその中には package.json ファイルがあるのでしょうか。またなぜ node_package というファイルに module.json というファイルがあってはだめだったのでしょうか。

The package.json file defines the package. (See “What is a package?”, above.)

package.json ファイルはパッケージを定義しています。

The node_modules folder is the place Node.js looks for modules. (See “What is a module?”, above.)

node_modules フォルダは Node.js が「モジュールを探しに行く場所」です。

For example, if you create a file at node_modules/foo.js and then had a program that did var f = require(‘foo.js’), it would load the module. However, foo.js is not a “package” in this case because it does not have a package.json.

例えば node_modules の中に foo.js というファイルを作って、さらにそれを var f = require(‘foo.js’) とロードするプログラムを書いたとすると、これはモジュールをロードしていることになります。しかしながら、foo.js はパッケージではありません。なぜならpackage.json を持っていないからです。

Alternatively, if you create a package which does not have an index.js or a “main” field in the package.json file, then it is not a module. Even if it’s installed in node_modules, it can’t be an argument to require().

またパッケージを作ったとしても、index.js をもたないか、もしくはpackage.json に main フィールドを持たない場合、これはモジュールではありません。例え node_modules の中にあったとしても、require() の対象にはなりません。

 

代表的なNode Module

  • Babel
  • Node-Sass
  • Browserify

Intro to Vue.js: Vue-cli and Lifecycle Hooks 日本語へ翻訳

Intro to Vue.js: Vue-cli and Lifecycle Hooks

Vue-cli and build processes

If you haven’t yet read the last section on Vue.js components and props, I highly suggest you do so before reading this section, otherwise, some things we’ll cover will lack context.

まだ前回の コンポーネントと props についての記事を読んでいなければ、そちらを読んでからこの記事を読むよう強く推奨します。そうでないと理解できないところがあるかもしれません。

Vue offers a really nice cli that gets you up and running with your choice of a few build tools, and really nice simple starter boilerplate. It’s a lovely tool. Before installing vue-cli, you might want to check that your versions of node, and npm or yarn are up-to-date. You’d first want to install vue-cli (the -g helps you install it globally)

Vue.js は素晴らしい CLI を提供しており、これをつかえば素早く作業ができ、しかも少ないツールで済みます。また非常にシンプルなスタート用のテンプレートも用意されています。本当に素晴らしいツールです。vue-cli をインストールする前に、ノードと npm もしくは yarn のバージョンが最新のものになっているか確認しましょう。その後にインストールします。 (訳注:npm が2系だと動かなかったので、私は node を 7系、npm を3系にしたところ動いた)

$ npm install -g vue-cli

There are many builds available to you, but in our example, we’ll use webpack:

ビルドの方法がたくさんありますが、ここでは webpack を使うことにしましょう。

$ vue init webpack <project-name>

You can go through the commands that the output will give you, which will help you cd into the directory, install everything, set up your `package.json` file, and then finally serve up a local dev server at localhost:8080 with the command:

このコマンドを実行すると、Vue.js は必要なもの一式を作成し、そのディレクトリに移動し、必要なものをインストールして、package.json ファイルも生成してくれます。そして次のコマンドを実行すると、ローカル開発サーバーを立ち上げてくれます。(訳注:と書いてあるが、ディレクトリに自分で移動し、インストールも自分でnpm init でしなくてはいけない。vue-cli のバージョン2.8.1の場合)

$ npm run dev

You’re up and running! I love that the setup is so clean. You’ll start off with an App file in your `/src/` directory with a `Hello.vue` file in the `/components/` directory. This is really nice because you can see already how you’d set up these files, and how imports and exports might work.

さあ走り出しました。非常に簡潔なこのセットアップ手順を愛しています。では手始めに/src/ディレクトリの中の/components/ディレクトリ内のHello.vue ファイルを見てみましょう。これをみればファイルをどうセットアップして、インポートやエクスポートをすればいいかわかるので便利ですね。

Let’s go over this new `.vue` file extension for a moment, because if you haven’t worked with vue, you won’t have come across it before.

「.vue」拡張子がついたファイルについて少し説明をします。Vue.js に取り組んだことがない人は初めてみるファイルだと思いますので。

In your `.vue` file, you can place everything you need for your component. We no longer have to wrap our templates in <script type=”text/x-template”>, now we’ll more semantically create files that follow this logic:

.vue ファイルにはコンポーネントを作成するために必要なものを配置します。今回はもう面倒な<script type=”text/x-template”>を書く必要はなく、次のようにより見通しのいい書き方ができます。

I’ve made a repo of Vue snippets for Sublime Text to quickly spin up boilerplate like this for `.vue` files (this is what the snippet vbasewould output). There’s also this one for atom, (though it specifies version 1+, and Vue is at v2), and this for vscode.

A few things to note here: just like in React, you have to return exactly one enclosing tag, here I’ve used a div. I’ve also used <g>elements in SVG. It can be anything, but the entire template must be wrapped in the one tag.

You’ll see that we’ll use export default here to write our scripts such as the data function or methods we used previously, but if we were to use components as children in this `.vue` document, we would also have to import them (more on this in a minute).

Intro to Vue.js: Components, Props, and Slots

なるべくもとの文章に忠実に翻訳するようにしましたが、原文だけでは自分が理解できない箇所に関しては、大幅に文言を追加しています。

元の記事

Intro to Vue.js: Components, Props, and Slots

Components and Passing Data

コンポーネントとコンポーネントにデータを渡す方法

If you’re familiar with React or Angular2, the idea of components and passing state won’t be new to you. In case you’re not, let’s go through some of the main concepts.

React や Angular2 に馴染みがある人であれば、コンポーネントという概念をご存知でしょうし、状態をコンポーネントに渡すというのも、目新しいものではないとおもいます。しかし、今回はあまり馴染みがない人のために、コンポーネントの主要な機能について体験していこうと思います。

Websites large and small are usually composed of different pieces, and abstracting them into smaller pieces makes them easy to structure, reason about, reuse, and makes our code more legible. Instead of digging through all of the markup in long, multi-faceted page, we could comprise it of components like this:

ウェブサイトは大きなものであれ小さなものであれ、様々な断片によって構成されていますが、これらの断片を抽象化することによって、構造化することも、理解することも、使いまわすことも、簡単になりますし、そしてなによりもコードの可読性を上げてくれます。何ページにもわたる非常に長いコードを書くのではなく、次のようにコンポーネントで構成することができます。

This is a simplified example, but you can see how useful this type of composition can be as you start to build out the structure of your site. If you were to dive into this code as a maintainer, it wouldn’t take much to understand how the application is structured or where to look for each piece.

これは単純化された例であって実際に機能するものではありませんが、このように構成することができればどんなに便利なことか、御理解いただけるはずです。もちろん一からウェブサイトの構成を作り上げるときにも便利ですし、また他人が作ったコードをメンテナンスする際にも、どのような構造になっているのか理解するための時間を減らすことになりますし、どこに何があるのか探すのも簡単です。

Vue lets us create components in a few different ways. Let’s work from simple to complex, keeping in mind that the complex example is truest to form for what an average Vue application would look like.

Vue.js でコンポーネントを作る方法はいくつかあります。簡単なものから初めて複雑なものにも一緒にチャレンジしていきましょう。?次の一文わからず

This works, but isn’t terribly useful as it can only be used once and we’re not yet passing the information to different components. One way to pass data from a parent to a child is called props.

これでも機能はしますが、そこまで便利というわけではありません。なぜなら使いまわすことができませんし、情報を異なるコンポーネントに渡してもいません。情報を親から子へ渡す方法として「Props」という機能があります。

This is as simple an example as I could make, so that it’s super clear. Remember that the :text in the HTML is a shortcut for Vue binding. We covered this last time in the section on directives. Binding can be used for all kinds of things but in this instance, it keeps us from having to place the state in a mustache template, like this {{ message }}.

次の例はできるだけ簡単になるように努力しましたので、非常にわかりやすいはずです。「:text」は v-bind の省略形です。(詳しくは前回を見てください) Vue.js におけるバインディングは様々な用途に用いられますが、今回は口ひげ構文({{ message}})と書くことなく状態 = state を配置するために使用しています。

訳者解説:次のcodepenを参照してください。v-bind:text=””と:text=””は同じ効果を発揮します。そしてその効果は、コンポーネントの props に””内の値を渡すことです。ただし、v-bind 等のディレクティブを付けた場合、””内は JS として理解されますので、”message”は単なる文字列ではなく、Vue.message、つまりVueインスタンス内のデータの message プロパティの値を参照します。 また、単に文字列を渡すだけであれば、v-bind を用いずに、text=””とし、 props に渡すこともできます。同様に text=”message” のように、v-bind は用いずに、しかしVue インスタンスを参照した場合には、アップデートはされず、DOM が生成された時に一度だけ参照することになります。

See the Pen used vue.jscomponent by nakanishi (@nakanishi) on CodePen.

In the code below, Vue.component is the component, and new Vue is called the instance. You can have more than one instance in an application. Typically, we’ll have one instance and several components, as the instance is the main app.

下記のコードでは、「Vue.component」はコンポーネントを作成しており、「new Vue」はインスタンスを作成しています。アプリケーション中でいくつものVuie インスタンスを作ることができますが、通常は 1つだけのインスタンスに、複数のコンポーネントを関連付けて使用します。

Now we can reuse this component as many times as we like through our application:

上記のようにすれば、コンポーネントを好きなだけ何回でも使いまわすことができます。

We can also add validation to our props, which is similar to PropTypes in React. This is nice because it’s self-documenting, and will return an error if it’s not what we expected, but only in development mode:

validation (訳注:データの型やデータの有無をチェックする仕組み) を加えることもできます。これは React のPropTypes とよく似た機能です。これによってどんな値が入るべきなのか、コード自体が自分自身を説明してくれますし、制限外の値が入ってきた場合には、開発モードであればエラーを返します。

In the example below, I’m loading Vue in development mode, and purposefully passing an invalid type into our prop validation. You can see the error in the console. (It also helpful lets you know you can use Vue’s devtools and where to find them).

下記の例では、開発モードで意図的に誤った値を validation を与えた prop に代入してみました。すると、エラーがコンソールに表示されます。

Objects should be returned as a factory function and you can even pass as a custom validator function, which is really nice because you can check values against business, input, or other logic. There’s a nice write-up of how you’d use each type in the guide here.

(訳に自信なし、というか英文ではなくて挙動をもとに書いてます、ここ) コンポーネントの props に値を渡すためには、Vue インスタンスの data の中身は、factory function によって作られたオブジェクトが return されるようにしましょう。またこうすれば validation をも与えることができます。 (つまりdata(){return {message:”hello”, count:0} }というような形で書かれる必要がある。このdata関数は、実行されると新しいオブジェクトを作成する。このあたらしくオブジェクトを作成する性質=ファクトリーだと思われる。こうしなくてはいけない理由は次にカウントアップのコードをみるとわかる。毎回別のオブジェクトがつくられないと、データーの中身を共有することになるので、同一のコンポーネントから作られたものは、全てデーターがおなじになってしまう。それを避けるためには、コンポーネントが作成された際に、data関数が実行されて、新しいオブジェクトが返されるようにすればいい、ということだろうか…)

You don’t need to necessarily pass the data in props to the child, either, you have the option of using state or a static value as you see fit:

コンポーネントに props を介してデータを、必ず与えなくてはいけないわけではありませんし、渡す場合にも Vue インスタンスの 状態=state を渡す選択肢と、固定値 = static value を渡す選択肢の2つがあります。これは自分の必要とする機能に応じておこなえばよいでしょう。

The difference is whether or not you’re passing a property and binding it:

Vue インスタンスのプロパティを渡してバインディングするか、しないかの違いについて説明します。

Not using the state
<child count=”1″></child>

上記の例は Vue インスタンスのプロパティを渡していませんし、またバインディングもしていません。つまり単に定数の 1 を渡しているだけです。

vs

Using the state
<child :count=”count”></child>

上記の例は「:」によってバインディングをしているし、Vue インスタンスの値、つまり状態 = state である「count」を props を通して渡しています。

Up until now, we’ve been creating content in our child component with a string, and of course if you’re using babel so that you can process ES6 in all browsers (which I highly suggest), you could use a template literal to avoid potentially hard-to-read string concatenation:

バベルを使って ES6 を使えば、面倒な文字連結が簡単になるよ。

This is a little more useful, but there’s still a limit to how much content we probably want to put in that string, even with the help of template literals. Eventually in this comment form we’d want to have photos and the names of the authors, and you can already probably guess how crowded it would get with all that information. We also won’t have any useful syntax highlighting within that string.

上記のコードのように、コンポーネントにテンプレートを与えると便利なことは確かなのですが、文字列を延々書いていくことになるので、限界があります。最終的にはこのコメントフォームにコメントした人の画像と、名前を入れたいと思っているのですが、そうするとかなりソースがごちゃごちゃしそうですよね。しかし、残念なことに、コンポーネントにテンプレートを与えて、その中に文字列を書いていく方法では、これ以上うまく書く構文はありません。

With all those things in mind, let’s create a template. We’ll wrap some regular HTML in special script tags and use an id to reference it to create a component. You can see that this is a lot more legible when we have a lot of text and elements:

こういった問題を念頭において、テンプレートをつくってみましょう。普通の  HTML を特別なスクリプト・タグで包み込み、これをidで参照することでコンポーネントを作ります。こうすることで可読性がさらに高まり、テンプレートの中に沢山の要素を配置して文字列が長くなっても理解できます。

See the Pen Photo App post with Vue.js by Sarah Drasner (@sdras) on CodePen.

ここまでの訳者の個人的なまとめ

props と template をコンポーネントに与える書き方。

See the Pen used vue.js matome1 by nakanishi (@nakanishi) on CodePen.

HTML 内に script としてテンプレートを規定して、コンポーネントから ID でそれを参照する記法。

See the Pen used vue.js matome2 by nakanishi (@nakanishi) on CodePen.

コンポーネントにそれぞれ個別の値を持たせるためには、コンポーネントの定義にfunction(){return{オブジェクト}}を与える。そうすれば、コンポーネントが作成された時に、そのインスタンスにこの値が与えられる。factory 関数。

See the Pen used vue.js matome3 by nakanishi (@nakanishi) on CodePen.

Slots

This is a lot better. But what happens when we have two components with slight variations, either content or style deviations? We could pass all the different content and styles down into the component with props, and switch everything out each time, or we could fork the components themselves and create different versions of them. But it would be really nice if we could reuse the components, and populate them with the same data or functionality. This is where slots come in really handy.

上記のサンプルはかなりよくなりました。でも、微妙に異なる2つのコンポーネントを使用したい場合、どうすればいいでしょうか?コンテンツやスタイルが少し異なる場合です。今のところ props を使って、それぞれ微妙に異なるコンテンツやスタイルを渡すことで実現してきました。しかしもっと簡単にそれを実現する方法があります。それが slot です。

Let’s say we have a main app instance using the same <app-child> component twice. Inside each child we want some of the same content, and some different content. For the content we want to stay consistent, we would use a standard p tag, and for the content we want to switch out, we’ll put an empty <slot></slot> tag.

同じコンポーネントを二回使いながら、しかしそれぞれに異なるコンテンツと、それからもちろん共通するコンテンツを含むようにしていきましょう。次のコード例では、変化しない共通部分を通常の p タグで記述し、入れ替えたい部分を slot タグで記述しました。

Then, in the app instance, we can pass content inside the <app-child> component tags and it will automatically fill up the slots:

そうすることで、<app-child>コンポーネントの中に記述したコンテンツを(訳注:例えば<h3>this is slot..</h3>や<small>I can put more ..</small>など)自動的にスロットの中に挿入してくれるのです。

You can have default content within slots as well. If, in the slot itself, rather than writing <slot></slot>, you can populate it with:

slot に対してデフォルトのコンテンツを設定することもできます。次のように記述してください。

<slot>I am some default text</slot>

That default text will be used until you fill the slot with other material, which is so useful! High fives all around.

デフォルトテキストは、slotに何もないときにだけ使用されます。便利ですね!やった!

You can also have named slots. If you were to have two slots in a component, you could differentiate between them by adding a name attribute <slot name=”headerinfo”></slot> and we could access that particular slot by writing <h1 slot=”headerinfo”>I will populate the headerinfo slot!</h1>. This is extremely useful. If you have multiple slots that are named and one that isn’t, Vue will put the named content into the named slots, and whatever is left will be used to fill the remaining unnamed slots.

名前を slot につけることもできます。コンポーネント内に2つのスロットがあるとすれば、名前をつけることで識別することができます。<slot name=”headerinfo”></slot>と名前を付けたのならば、<h1 slot=”headerinfo”>とすることで、そのスロットにアクセスできます。これはとても便利です。名前が付けられたスロットとそうではないものがある場合、名前を指定したコンテンツは対応する名前付きのスロットに配置され、なにも指定しなかったコンテンツは、名前がついていないスロットに配置されます。

Here’s an example of what I mean:

Personally, if I am using more than one slot at a time, I will name all of so that it’s super clear what is going where for other maintainers, but it’s nice that Vue provides such a flexible API.

個人的には複数のスロットをコンポーネントに使う場合には全てのスロットに名前を付けます。そうしたほうが、他の誰かがメンテナンスをする時にわかりやすいからです。でも、Vue.js が柔軟な API を用意してくれているのもとてもいいと思います。

Slots example

Alternatively, we can have particular styles assigned for different components, and keep all of the content inside the same, therefore quickly and easily changing out the appearance of something. In the wine label maker below, one of the buttons will toggle the component and color based on what the user selects, and the background of the bottle and label and text will all switch, while keeping the content within stable.

ほかのアプリケーションをつくってみましょう。今度は、コンテンツは全てキープしたまま、異なるコンポーネントに切り替えてみます。つまり見た目などだけを簡単に切り替えれるようなアプリケーションです。次のコードは、ワインのラベルを作るアプリケーションで、ボタンを押すとコンポーネントが切り替わります。ユーザーが選んだ色にバックグランドが変わって、ラベルやテキストのスタイルもユーザーがボタンで選んだ内容によって切り替わります。しかし、その中のコンテンツは一定のままにしたいとしましょう。

Now, we’re putting all of the SVG image data in the main app, but it’s actually placed inside the <slot> in each component. This allows us to switch out pieces of content, or style things differently based on the usage, which is a really nice feature. You can see that we’ve allowed the user to decide which component they’ll be using by creating a button that changes the “selected” value of the component.

SVG 画像のデータは全てメインの HTML ファイルに書いてあります。これはスロットを介して渡されています。こうすることで見た目や一部のコンテンツを切り替えることができます。素晴らしい機能です。このアプリケーションはユーザーにどのコンポーネントを使うのか、ボタンで選ばせています。このボタンはコンポーネント選択のために参照している”selected”の値変更します。

Right now we have everything in one slot but we could also use multiple slots, and differentiate them through naming if we’d like:

いまはスロットは一つだけですが、もちろん名前をつけて複数のスロットを使うこともできます。

We can switch between different components with the same referenced slots easily, but what happens when we want to be able to switch back and forth, but hold on to the individual state of each component? Currently, when we switch between black and white the templates switch out and the content stays the same. But maybe we have a situation where we want the black label to be completely different than the white label. There’s a special component you can wrap it in called <keep-alive></keep-alive> that will retain the state as you switch.

違うコンポーネントに切り替える場合、スロットの中身を同じものにするのは簡単です。しかし「それぞれ」のコンポーネントの状態を残したまま、コンポーネントを切り替えるにはどうしたらいいでしょうか。今のコードだと、コンポーネントを黒から白に切り替えた場合、テンプレートが切り替わりますが、コンテンツはそのままです。しかし黒のラベルのコンテンツと白のラベルのコンテンツをそれぞれ完全に分けたいこともあるはずです。そんな場合には<keep-alive><keep-alive>でラップすることで、コンポーネントを切り替えても、コンテンツをそれぞれキープしてくれます。

Check out this deviation of the example above- create a black label, and then a different white label, and switch between them. You will see that the state of each is preserved, and are different from one another:

下記のコードと上記のコードの挙動の違いを確認しましょう。黒いラベルを作成した後に、白いラベルにいって違う内容を作ります。そして両者を切り替えてください。それぞれの状態が保存されているのが確認できるはずです。それぞれの状態は異なっていますね。

See the Pen used simpler Vue Wine Label Maker by nakanishi (@nakanishi) on CodePen.

I love this feature of the API.

This is all nice, but for simplicity’s sake, we’ve been sticking everything in one or two files. It would be much better organized while we build out our site if we could separate the components out into different files, and import them as we need them, and truly that’s how real development in Vue is typically done, so let’s run through that next. Tune in for the next part when we talk about Vue-cli, build processes, and Vuex for state management!

私はこの API を愛しています。これでもとても素晴らしいのですが、問題を簡単にするために1つか2つのファイルの中に全てを詰め込んでしまいました。しかし、そうするよりもさらに整頓できる方法があります。コンポーネントを別のファイルに分けて、それを必要な時にインポートするという方法です。これが実際の開発現場で Vue を使う方法です。次回はこれをやってみましょう。次回は Vue-cli、ビルド、Vuex による状態管理を扱います。

ここまでの訳者の個人的なまとめ

<component :is=”状態を参照”>で、動的にコンポーネントを変えることが出来る。参照している状態が変われば、コンポーネントが変わる。

コンポーネントの中でスロットを使ってコンテンツを挿入する場合、状態とバインドした値を使っていれば、コンポーネントが変わっても、バインドされているので残される。

See the Pen used simpler dynamic component by nakanishi (@nakanishi) on CodePen.

さらに変化するコンポーネントをキープアライブで囲っておくと、コンポーネントごとに値を保ってくれる?ので、白から黒にコンポーネントを変えても、白のコンポーネントの中身は保存されており、黒から白へ戻した時に、フォントカラーや文字の内容が戻る。

See the Pen used simpler dynamic component keep-alive by nakanishi (@nakanishi) on CodePen.

名前について

キャメルケース(superMan)とケバブケース(super-man)を使い分ける必要性について。HTMLは大文字小文字を区別しないので、HTMLの中で、属性を記述するときにはケバブケースで書くこと。

  • コンポーネント名はキャメルケースで書き(childFood)、HTMLの中でカスタム要素のように書く場合にはケバブケースで書けば(child-food)、何故か対応するようにしてくれる。
  • propsについても同様で、コンポーネントの中ではhelloWorldと書いて、HTMLの中では:hellow-world=””と書けば対応する。なお、{{}}の仲やv-bind=””の中はJSになるので、キャメルケースで書いて良い。むしろキャメルケースじゃないと正確に認識しない。

See the Pen used vue.js camel by nakanishi (@nakanishi) on CodePen.

vue.js のドキュメントを日本語にする

勝手にドキュメントを日本語にするシリーズ、第二弾。先日行われたウェブ勉強会、Dist #14 のテーマでもあった Vue.js のドキュメントを勝手に日本語にします。既に日本語版のドキュメントは作られているのですが、自分の勉強のために車輪の再発明をします。

Introduction

“vue.js のドキュメントを日本語にする”の続きを読む