若手のプログラマが軽めの技術情報と、技術系のポエムを書くブログです。

node-REDを弄ってみた。

仕事でnode-REDに触れる可能性があるので事前に調査を行い、実際に弄ってみました。

node-REDとは

node-REDは視覚的にnodeとedgeを描くことでハードウェアやデバイス、オンラインサービスを接続するためのツールです。

img

node-REDの特徴

ブラウザ上に構築されている

node-REDはブラウザで動作するFlowエディタを提供しており、視覚的にFlowを記述できます。

FlowはNode(プラグイン/モジュール)とEdge(Node間の接続)からなり、ワンクリックで実行環境にデプロイ可能です。

リッチテキストエディタJavascriptプログラミングが行えるNodeを利用してプログラムを作成することもできます。

作成したテンプレートやFlowはエディタに組み込まれたライブラリに保存し、再利用することもできます。

node.js上で構築されている

node.js上に構築されており、イベント駆動/ノンブロッキングモデルを活用できます。

そのためにRaspberry Piなどの低コストハードウェア、クラウド上で実行するにも理想的な環境が提供されています。

また、Node.jsのエコシステムに存在するモジュールを利用して、Node-REDを拡張できることも意味します。

Json形式のインポート/エクスポートによるFlowの共有

Node-REDで作成したFlowはJson形式でインポート/エクスポートすることで他の人と共有できます。

オンラインFlowライブラリにて、作成したFlowを公開、または利用することも可能です。

実際に弄ってみる

Node-REDのインストールと起動

Linux/OS Xで既にNode.jsをインストールしている場合はTerminalにて以下を実行します。

$ sudo npm install -g node-red
$ node-red

僕の場合は条件に合致しましたが、それ以外の場合は公式のGetting Startedを参照ください。

Node-REDへアクセス

デフォルトの場合はブラウザから以下のポートでアクセスできます。

http://localhost:1880/

アクセスするとブラウザでFlowエディタが立ち上がります。

Hello worldを表示してみる

新しい技術に触れた時はとりあえずHello worldだと思います。

ということでhttpで/helloworldエンドポイントへアクセスしたら、helloworldと表示するFlowを作ってみました。

最終的なFlowはこんな感じになります。

Flowの構成

Flowは、以下のNodeから構成されています。

  • HTTP Request Node
  • Template Node
  • HTTP Response Node

これらをつなげることで、「こんなリクエストがあった時、こんなメッセージを、こんな風に返す。」という一連の流れを記述できます。

今回の場合は、

  • /helloworldにGETされる
  • msgは'Hello World!'
  • msgをBodyに含むレスポンスを返す。

というようなFlowを作ります。

Flow作成の手順

HTTP Request Nodeを追加する

左側のペインから、任意のノードをドラックして中央のFlowペインへドロップすることでNodeが追加できます。 今回は、まずはエンドポイントを追加したいので、httpノードをFlowに追加します。

HTTP Requrest Nodeのパラメータを編集する

Flowペインへ追加したノードをダブルクリックすることで、Nodeにパラメータを設定するためのDrawerが表示されます。 今回は、以下の設定を行います。

  • Method: GET
  • URL: /helloworld
HTTP Response Nodeを追加する

Requestに対するResponseが必要なので、Nodeを追加します。 今回は特にResponseに設定は行わず、デフォルトのままにします。

Request Node と Response Nodeをつなげる

Request Nodeの右端とResponse Nodeの左端をつなげます。 これにより、これらのNodeを関連づけ、左から右へ流れるFlowにすることができます。

一旦デプロイしてみる

まだBodyを設定していませんが、正常に動くかデプロイしてみます。 デプロイの際は、画面右上のdepoloyボタンを押下します。 上からトーストが出たら成功です。

エンドポイントにアクセス

/helloworldエンドポイントにアクセスしてみます。 今回の場合ですとurlは以下になります。

http://localhost:1880/helloworld

空のレスポンスが帰ってきたら、ひとまずここまでは成功です。

Http Response Bodyを設定する

では、レスポンスにBodyを設定するにはどうしたらよいのでしょうか。 HTTP ResponseNodeは、左端に接続されているNodeのmsg.payloadの値をBodyとして返します。 ということで、Template Nodeを現在の2つのノードの間に追加して、msg.payloadに値を設定します。

差分デプロイを行う。

今回の変更では、すべてをデプロイし直す必要はないため、差分デプロイを行います。 そうすることで必要最低限だけ、デプロイし直してくれます。

再度エンドポイントへアクセスする

/helloworldエンドポイントへアクセスしてみると、無事にHello Wolrd!と表示されていることがわかります。

まとめ

このようにNode-REDでは、基本的に以下の流れで素早く開発ができます。

  • Nodeを追加
  • Nodeのパラメータの設定
  • 複数Nodeを関連付けてFlowを作成
  • デプロイを行う

素早いプロトタイピング

このような素早いプロトタイピングは、Node-REDを導入するメリットの一つだと思います。

主にIoT分野での活用を想定しているツールだそうですが、個人的にはプロトタイピングやプログラミング学習などにも利用できるのではないかと思っています。

関数型プログラミングとの共通点

関数型プログラミングの特性が現れているのも面白い部分の一つです。

ノードをつなげていくと、ちょうどフローチャートの様にも見えますが、ifやwhileと行った制御構文は登場しません。

これは、ノードを使って記述しているのは処理そのものではなく、あくまでメッセージの受け取りと、加工、そして結果の受け渡しだからです。

今後について

今後は、ひとまず一通りどんなノードがあるのかを調べつつ引き続き学習していきます。 各種ノードについてのまとめをしていきますので、よかったらご覧ください。

参考リンク

構造コード vs リアルコード

ZERO BUGSを購入して読んでみたところ、構造 vs リアルコードという章があり興味深かったので抜粋して少し考えてみる。

2種類のコード

この章の中で著者はコードを構造コードとリアルコードの二つに分類している。

自分が書いているコードがどちらに当たるのかを考えてみることで、本来の目的を見失わずに済むかもしれない。

構造コードとは

構造コードとは、ものをつなぎ合わせるためのコード。

処理を共通化を行うコードや、デザインパターンなどがそれにあたり、繰り返し出現する構造を抽出して柔軟性を高めたい場合などに記述される。

著者は1行の構造コードは2つの異なる場所で必要とされた場合にのみ描かれるべきだと言う。

リアルコードとは

リアルコードとは、実際に何かを行うコード。

ファイルを開いたり、画面に何かを描画したり、月までの距離を計算したりするのがリアルコード。

構造コードに対比させるならば、1行のリアルコードは目的の達成に必要とされた場合にのみ書かれるべきだと思う。

高品質のコードを目指すために

高品質なコードを目指すためには、構造コードを可能な限り減らすことが必要となる。

コードの良さを表す関数gの最適化問題

以下の式ではrはリアルコード、sは構造コード、fは必要とされる柔軟性、そしてtはタスクを完了させるために必要なコードを表す。

g(r, s) = r - s
  s >= f
  r == t

ここでの目的は、gを最大化させることである。

rに対しsが大きすぎるならば、それだけgも小さくなってしまう。

必要な柔軟性だけを担保し、タスクに対してコードを書いていくと良いことがわかる。

構造コードを書くべき時

著者は、後方互換性が必要な局面において3か所以上で参照されることがわかっている場合には、構造コードを書くべきだとしている。

これはKISSやYAGNIにも共通する考え方である。

後々のことを考えて、というのは構造コードを追加する理由にはならないということだ。

「初めて何かを行うときは、ただやるのみだ。2回目に何か似たようなことを行うとき重複に気付いてたじろぎ、それでも同ようにやるだろう。似たようなことを行うのが3回目なら、リファクタリングしよう。」

同じコードを3回書いた時、これらを共通化できないか、するならばどんな構造コードが必要かを問いかけるようにすると良いだろう。

まとめ

無意味な構造コードを書きがちな自分にとっては良い戒めであり、すっと理解できた。

設計や構造をあれこれするよりも、言語のAPIを上手く利用したり、品質の良いライブラリを活用することで、1行のリアルコードが為すタスクを最大にすることを考える必要がある。

著者は2種類に分けるのは教えるのに便利だからであり、どちらのカテゴリにも当てはまらないものがある。だから原理を一度理解したならば、その先へ進んで欲しいと言う。

しばらくは、この2つの分類でコードを考えてみようと思う。

参考文献

リファクタリングを読んで。

リファクタリングについて

リファクタリングとは、プログラムの機能を変えずに、設計と実装を改善することです。 その目的は主に、現存するプログラムのscalability(拡張性)やMaintainability(保守性)を高めることです。 しかし、それがなぜ重要なのかを説明することや、実践することは難しく、すでに定着していない場合は導入がし辛いように思います。 現に現場の実務プロセスでは、バグ改修以外の理由でのコードの改変が認められていないプロジェクトも存在します。 それでもなお、僕はリファクタリングが開発を行う上で有用な考え方だと思います。 それは少し学習しただけでも、以下のような幾つかの気づきがあったからです。

リファクタリングの学習を始めたことによる気づき

  • 良い設計の適用方法のガイドラインになる。
  • IDEなどのツールの活用方法の理解を助ける。
  • テストを書く習慣づけを身につけることができる。

これらはあくまで学習と技術力向上という観点で見たリファクタリングのメリットです。 実際の開発でどのように役に立つかは、まだ経験がないため、その他の方へ譲ります。 つまり、プログラミング上での作法がなぜ重要なのか、それに反するものにどう対処すれば良いのかは学べます。

作法とリファクタリングの関係

例えば変数の命名には以下のような作法があります。 変数名は名詞で、省略せず、短く簡潔に意図を伝えるようにすること。

これを守ることで、同じ変数に対する複数回の代入は行いづらくなります。 なぜなら意味に反する値を入れるわけにはいかないからです。(プログラム上は出来ますが、論外です) すると、結果的にはそれによって式の結果を保持する一時変数が増えます。

ここで例えば、問い合わせによる一時変数の置き換えというリファクタリング手法を適用します。 式の結果を変数に格納するのではなく、式の結果を返すメソッドを作成し、それを利用する。というものです。 このメリットは、メソッドとする事で、その他のプログラムから利用できるようになる事です。

すると、必然的にメソッドが増えていきます。 そうなれば、クラスの抽出というリファクタリング手法が使えるかもしれません。

このように考えると作法が、これらの単純な設計上の問題を導き出すことがわかります。 このようにして、プログラムを書いている中で生まれる設計上の問題に対して、どう対処すべきかをリファクタリングの手法は教えてくれます。

実際のプロジェクトへの適用

個々人による開発能力を向上させることは、多かれ少なかれ全体へ影響を与えます。 上にあげたようにして、個人が良い設計を行なっていく。というような場合にはリファクタリングには大きな価値があると思います。 しかし、実際のプロジェクトへ抜本的に導入することは難しいかもしれません。

なぜならば、個々人の能力と取り組みに左右されることが大きいように思うからです。 それにあくまで拡張性と保守性への改善の取り組みであって、機能追加のような見える成果は出づらいからです。 しかし、よく整理されたプログラムは開発の速度へ影響を与えます。 開発期間中に要件が変わる場合、その場で拡張性が求められることもありえます。

日頃から、プログラマ個々人がすべき時にすることとして、徐々に始めるしかないのかもしれません。

まとめ

マーティン・ファウラーリファクタリングを読んで、実際に幾つかのテクニックを試してみて気づいたことをまとめました。 個人的に一番興味深かったことは、変更を加える際、既存のコードを残したままに変更を加えていた事です。 そうする事で、終始テストはグリーンのまま、レッドになった際は手順のミスが発覚します。 以前は、自分はいきなり破壊的な変更を加えるような事もあったため、安全な手順を踏んだ変更を加えるための手順と原則がわかった事は重要でした。

プログラマに必要な能力とは

プログラマに必要な能力といえば何が思い浮かぶだろう。 それぞれがそれぞれに考えがあるように思うけれど、自分にとってはその時々によって答えが変わってくる質問だと思う。 今の自分ならデザインパターンリファクタリングの手法を用いて、設計上の問題を解決する能力を思い浮かべる。

ちょうどマーティン・ファウラーリファクタリングを読み始めたばかりだが、自分はつくづく影響を受けやすいのだと思う。

この質問は時々問い直して、自分の答えの推移を見れたら面白いかもしれない。

SNSとしてのGithub

まず始めに、僕はGithubが大好きです。 なぜならGithubはエンジニアの理想を体現していると言っても過言ではないからです。

何かを食べた、何かを観た、聴いた。どこどこへ行ったというような情報はSNSに溢れています。 面白画像や動画、アンケート、ちょっと食傷気味になるくらいにいろいろなコンテンツがあります。 SNS上では人が何を考え、何をしたかを共有しています。

僕はGithubでも同じことが起こっているように思います。

例えば好きなアカウントをフォローすることができますし、Starを投げて応援することもできます。 コミットログはタイムラインに成りえますし、コードは投稿されるコンテンツです。

常に重要なことに目を向けたい、何かに貢献したい、そういう人達にとっては、一番楽しいSNSたり得ると思います。

1年目のプログラマとして今年を振り返る

はじめに

1年目のプログラマが、今年一年で触れた技術について振り返りたいと思います。 現在はWeb系の受託開発及び技術者の人材派遣を行っている企業に勤めています。

プログラマとして働き始めたのが去年の10月ですが、今年が1年目ということもあり、自分が触れた技術と資料などを忘備録としてまとめようと思い立ちました。

ちょうど友人が来年度からプログラマとして就職するという話も聞いていて、1年前の自分と彼に記事を書くとしたらどんなものが良いかな、と思いつつ書きました。

アウトライン

今年使用した技術

言語とツール

今年を振り返って

1年を振り返れば主にWebを基盤としたシステムの開発に携わっており、Javaをメインに開発していました。 自主的にRubyを学習したり、案件で必要だと言われPHPを学習したり(結局業務では使わず)、目標を定めずに学習してしまったのは効率が悪かったなと考えています。 しかし、それぞれの文化的な違いや記述の違い、得意分野などを大まかにでも知れたことは良かったと考えています。

来年の目標

来年度は合目的的に学習することを目標として、 今後も業務でも多く用いるであろうJavaをメインに、Rubyを自学したいと思っています。 理由としては以下が挙げられます。

  • Javaとその周辺技術に興味がある
  • Web系のBtoC開発を行う事を目標としていること

まず一つ目ですが、型による補償が手厚い言語の元で開発、テスト、デバッグの基本を身につけられたことは良かったと思っています。 データ構造やアルゴリズムを学習していくと、Javaの堅さはそれらに基づく抽象データ型を表現するにはメリット足り得ると気づけました。

二つ目ですが、自分がやりたいことは、BtoCのWeb開発だということ気づいたため、それを目標としています。

その為そこでの需要があるであろう言語に熟達したいという事、 またタイプの違う二つの言語に触れることはプログラマとしてのスキルを磨く良い方法だと考えているからです。

動的型付け言語に対する興味もありますが、コミュニティの文化の違いも個人的には興味深いです。

開発環境

去年初めてプログラミングを始めた際には、苦しみながらC言語を学んでいました。 そのため、ターミナルでソース作成、コンパイル、実行を行っていました。 何故Cなのかという話ですが、単純に何も知らなかった上、プログラミングとやらが出来ればそれで良いと思っていたからです。 仕事を始めてからは、ほぼほぼEclipseを使ってJavaで開発していました。 もともとキーボードショートカットマニアなところがあり、効率的に作業ができそうな場合には、都度調べて統合開発環境のキーボードショートカットを覚えていきました。 それを社内で公言していたこともあり、たまに先輩などからも質問されたりと、自分のキャラクターになってきているのは自分でも良い傾向だなと思っています。

zsh, vim, tmuxは b4b4ro7さんのqiita記事、さいつよのターミナル環境を構築するを読み、思い切り影響を受けた結果です。 Dotfileを作成しましたが、実務ではほとんど利用できず、メンテナンスもできていないことが残念です。

来年度の目標

来年度は、Javaの開発環境に関しては業務上レガシーな事が多かったため、自宅で最新の環境を構築する事と、rubyの学習を含めターミナル環境をメンテナンスすることを目標とします。

情報収集と学習

全体的にインプットに対してアウトプットが足りていない事が問題だと考えています。 読んだ書籍について、自分で解決した課題について自分自身でまとめるだけでも定着度が違う事は経験でわかっていますが、焦りから大量に情報を欲する癖があるため、それらの整理が来年度の課題になると考えています。 対策として、以下を定期的に行える環境を作るつもりです

  • ブログやqiitaなどで記事を書く
  • 社内での発表の機会には学習した事を発表する。
  • 個人プロジェクトの公開を目標に、計画的に学習をする。

書籍

読んだ書籍に関しては、 趣味として読んでいたプログラマとしての心構えや方法論について書かれたものがほとんどです。 こちらはよくネットで進められているものを、出退社時や昼休みに読んでいました。 個人的には良い頭休めと、知識の下地になったと思っていますが、意識に技術と環境が追いついていない感覚が常にありました。 実際の現場では、本で読んだアンチパターンが沢山起こる事、本を読むだけではコードは書けない事を学びました。

技術書に関しては、必要に迫られて読んだものが多く、Java関係が3冊にRuby関係が1冊、PHP関係が1冊という結果です。 実際に手を動かしたものに関しては、振り返ってみても定着しているため、来年度は技術書の割合を高くして、手を動かしつつ読む事にします。

指南書

入門書

専門書

Web記事

やはり最新の情報を集めるには、Web記事はいいなと思います。 環境構築の手順や、ツールの利用方法、サンプルコードが載せてある記事からはとても恩恵を受けました。 しかし、それらを体系的に管理するツールを知らず、ほとんど記録を残せていないことは勿体無いと思っています。 今後は、ウェブクリップでも良いので、何か良い方法を見つけて管理したいと思っています。

ただ、1年間で公式の情報に敵う情報はないことだけはわかりましたので、公式のドキュメント読む前にググることはもうやめます。

エセ医療系サイトの問題もありましたし、悲しいことにWebは今あまり綺麗ではないのかもしれません。 プログラマの心構えや基本的な考え方についての記事に関しては、プログラマが知るべき99の事とリーダブルコードで必要な知識は十分揃うと思いますし、似たような記事は多いです。

ただ、独自の主張をしている記事は面白いですし、むしろ本では手に入らない生の声に近いものがあると思います。 個人的に以下に今年印象に残った記事をまとめました。

最後に

最後に、今年一年を振り返って

良かった点

まず良かった点から振り返ると、

  • 1日に一問問題を解くことを始めた
  • 多くのものから貪欲に吸収しようとしていた
  • 空き時間を有効に活用できていた

今年の後半から始めましたが、プログラミングの問題を1日一問解くことを初めてから、少しずつですがコードの質が上がったように思います。 データ構造やアルゴリズムといったアカデミックな知識に対する意欲も生まれるという副次的効果もありました。

また、自宅で自分自身で興味を持ったことを積極的に試していたことは、評価できるように思います。

通勤時や昼食休憩時、意図せず列に並ぶ羽目になった時には、本を取り出す、kindleまたはpocketにためていた記事を読む、podcastを聞くと言った行動を選択するように心がけていたことも、○です。

反省点

次に反省点ですが、

  • 仕入れていた情報が古いことがままあった
  • 自分自身の方針が不明瞭だったこともあり、触った程度で全く身についていないものも多くあった

原因を分析すると、 一点目に関してはアウトプットが少なかったことと、それによりフィードバックが足りていないことによるものと思われます。

二点目に関しては、元来飽き性なことと、事前知識が乏しいままに色々なものに手を出した結果、手を出しては引っ込めの繰り返しが多かったためだと思われます。

今後の目標

反省点に対する改善策としては

  • 計画的に物事を進める
  • 積極的に他者と関わり、新たな情報を仕入れる。
  • アウトプットを行った上でフィードバックをもらい、改善に努める

  抽象的な目標としては、 また現在わからないことは、わからないと認め、それを表現すること。 全てを自己解決しようとしないことは、学習や成長においては大事なことだと思います。

また年が明けた際に、上記に沿った具体的な目標を立てていこうかなと思っています。

それでは皆さん、良いお年を。 

ブログを始めてみる

ブログを始めてみることにした。

簡単に自己紹介と、このブログの趣旨、ブログを始めるに至った経緯をまとめる。

 

まずは自己紹介

職業: アシスタントプログラマー

趣味: 音楽、読書、プログラミング、たまにゲーム

好きなもの: 音楽と、キーボードショートカット、文字のみのコミュニケーション

 

なぜブログを始めるのか

一言で言うと、自分の考えを表現することが必要だと考えたからだ。

それを細かく分けるなら、主に3つの理由がある。

さらにそれらをリストにまとめると、

  • 社会人1年目として業務をこなす中で、自分の考えを表現する能力が求められているため
  • 日々の中では消化できない疑問について、自由に考える場所が欲しいため
  • 自分自身の発表の場を持ち、それらを人に見てもらいたいため

以下に、それぞれを詳しく考えてみたものをまとめる。

 

資料を作成する能力

アシスタントプログラマとして、

業務をこなす中で気づいたことは、

想像していたよりもドキュメントを作成することが多いということである。

会話でのコミュニケーションも多かったが、成果物としてのドキュメントを求められることがとても多い。

 

例えば、業務ではコードを書く前に、まず設計書というものを書くことになる。

プログラミング言語でのコーディングの前に、自然言語によって要求と仕様を明らかにするという為だ。

 

いきなりコードを書こうとして、失敗した経験も確かに多かった。

それならばいっそ、文章を書き、人に伝える、という能力を身につけようと思った。

 

日々の中で生まれる疑問について考える

例えば、もっとうまくやれるのではないか?

なぜこれをしているのか?

これを突き詰めていって初めて、自分ならこうするはずだという考えが出てくるのだと思う。

 日々の疑問点をそのままにせず、自分の考えにまで昇華させたい。

そう思ったのが二つ目の理由だ。

 

自分自身の発表の場として

昔から創作に対しての興味が強く、絵を描いたり、音楽を作ったりしては遊んでいた。

今では自分自身仕事でシステム開発などに携わっているものの、個人でツールやゲームを開発している人にはそういう意味でも憧れがある。

 

そのために日々勉強したこと、自分で何か作ってみたこと、そしてそれらをまとめ、発表する場所がと考えたことが三つめの理由である。

 

これが一番単純な動機だが、単純なことってそんなに悪くないじゃん。とも思う。 

 

とまあ、始めた理由はこれで良いとして、では何をしますか?という話だ。

 

ブログの趣旨について

簡単に言えば、音楽、プログラミングについて、日々の学習や創作のまとめをしようと思う。

 

以下に、その頻度と、トピックについてまとめる。

メイントピック: 創作の息抜きと、やりたいこと

サブトピック: 学習メモと、そこからの発展

たまに: 時事ネタと考察

上の三つを軸に、継続しながら考えてゆけたらと思う。

 

大事なことは継続と、気楽にやること。

 

三日坊主にはならないように。

 

ではでは。