無料ブログはココログ

論文研修会最終回 - タイトルとあらましは論文を示す -

SRA Advent Calendar 2019 の記事です。

論文を書き方に最も大切なことを書きます。

ふりかえり

ここまで論文の書き方を説明してきました。

そのポイントは構造で、論理的思考につながるもので技術文書全般に利用できるものです。
私たちが学んだ起承転結(wikipedia)ではなく、パラグラフライティングを基本としたあらかじめ全体像や見通しを示した後に詳細を示す構造です。

重要性

パラグラフ(段落)だけでなく文章全体がその示す単位の全体像や見通しから始まっているのですから、タイトルやあらましは論文そのものの価値を示す最も重要な部分です。

「論文の採否はタイトルとあらましで6~7割決まる。いや8割かもしれない」そう教わりました。実際、論文の査読の際はタイトルとあらましで大まかに担当者が決められたりするでしょうし、論文を読む際もタイトルとあらましで期待を高めたり、困惑しながら読み始めます(ちなみに、タイトルとあらまし、はじめに、結論と読んでから他の部分を読む人が多いようです)。

何を書くか

端的に言うとアピールすべきことです。論文というのは、書きたいことを書くものではありません。もちろん採録されることだけが目的ではないですが、中身を理解してもらって採録されなければ論文を読んでもらうこともできません。書きたいことではなく、書かないといけないことを書いてください。

論文は研究者あるいは現場の人が研究成果や経験を書くもので、研究論文なら新規性、一般性、信頼性、経験論文なら有効性、一般性、信頼性を評価されます(シンポジウムなら参加者のニーズなどが入る場合もあるでしょう)。ですので、文字数は少ないながらもタイトルやあらましにこれらの内容を書書ないといけません。

タイトルには色々な流派がありますが、例えば「Aを目的としたB法によるC(問題)の(対策)D」のように対象分野、問題、手法、どこまで解決しを明確にするとともに示します。こう書くと一般性に制限を付けたように読めるかもしれませんが、そもそも論文とはこれまで積み上げられてきた研究という巨人の肩に乗って、少しだけ良くしたものです。適用分野明確にすることや方法を示すことで信頼性を上げています。一般性や有効性はXXを目的としたで示します。新規性は問題と解決法の組み合わせで示すことが多いようです。

あらましにも色々な流派がありますが、整理しやすいパターンとしては以下のような項目を書いています。

  • 本論文ではXX(タイトルの内容)を示す
  • YYによる評価の結果、ZZだとわかった
  • XXを用いることで、これまで××だったAがより〇〇に△△できるようになった

さらに必要なら、課題と将来性にふれることもあります。

タイトルとあらましは最後に書く

タイトルとあらましは論文の顔です。明確な問題設定がなければ書くことができません。開発現場の人が論文を書く際に難しいのは、経験しすぎていることです。自分の実現したことも、なかなか端的に表現できません。

そこで「はじめに」を書いて問題を絞っていくことから始めましたが、結論まで書いたところで一度「はじめに」を見直してください。問題とはやったことの裏返しです。解決したことがどのような問題を解決したかをよく考えて、必要なら書き直してください。

はじめにの見直しができたなら、ようやくタイトルとあらましを書くことができます。発表準備にタイトルとあらましが必要になるかもしれませんが、それはあくまで仮のものです。問題設定がふらついているのに魅力的なタイトルと思ってしまうとそれに引きずられて、わかりにくくなりますので、注意してください。

おわりに

これまで説明した論文の書き方を踏まえて、タイトルとあらましの書き方を説明しました。ここに書いた内容は筆者の限られた経験から書いていますので、他にももっと良い書き方があるでしょう。ぜひ、多くの論文を読んであなた流の書き方を作ってください。その際にこのブログが少しでも役立ったなら幸いです。

さて、今回の研修は論理的思考を身に着けてもらうために実施しました。論文を書く行為は、説明しないといけない内容を、決められた構造に合わせて、組み立て、整理することです。整理された内容は構造化されていますので、検索して容易に取り出すことができますし、組み合わせることも可能です。また、新しい情報に出会った際にも応用や修正が可能でしょう。(参考: 実装者のための計算量のはなし - O(logN)などをわかり易く説明しました -

説明しないといけない内容は、相手の求めていることです。相手の求めていることに合わせて、説明し、アピールする、そういった当たり前のことが難しいのは、説明すべき構造に合わせて単純化できていないからです。論文の書き方を応用することで、話が長い、理解されない、勘違いするといったことが改善されるでしょう。ぜひ、実社会に役立ててください。

このエントリーをはてなブックマークに追加

論文研修会(情報を正確に伝える構造)

SRA Advent Calendar 2019 17日目の記事です。

論文をはじめとする技術文書はパラグラフライティングが基本です。パラグラフライティングの作法 -書き手にもメリットのある文配置ルール- によると、

パラグラフライティングは,文章のまとまりを作るルールと,各まとまりの中での文の配置のルールに則って文を書く方法です.そのルールを簡単に言えば,「共通の話題で括れる内容は一つのまとまりとする」というものと,「各まとまりの先頭には最も重要な文を置き,それ以後にはその文の補足説明のための文を置く

というものです。これはパラグラフ(段落)だけでなく、文章全体も同じような構造になっています。いわゆる起承転結と違い、結果を先に示した上で詳細を説明します。

このような構造はドラマ「刑事コロンボ」や円蔵師匠の落語、最近ではドラマ「時効警察」の一部でもそのような構造になっています。先に結果を示すことで結果に至る過程を楽しむことができます。

論文の構成は基本的に以下のような構成になっていて、随所で要点と全体の見通しが示され、情報が正確に伝わるようにガイドします。

あらまし

論文で何を提案するか、評価の結果、その価値などアピールする点を説明します。

はじめに

対象とする問題とその一般的な意味を説明します(これは問題設定と呼ばれます)。そして最後に論文の構成を示します。

関連研究

この章でどのような関連研究を示すかを述べた後、関連研究の説明をします。この説明は一般にどういわれているかではありません。提案の扱う問題と解決手法がこれまでどこまで行われ、提案する手法以外では解決されていないこと、いわゆる新規性を示します。

提案手法、評価方法、結果、考察

これらも先に構造を示すと、見通しが良くなり読みやすくなります。また、それぞれの説明の中で互いの関係を示すと内容をよく理解してもらえるでしょう。

おわりに

論文で提案した内容とその効果、将来展望と課題を示します。

あらまし、はじめに、おわりに、は同じような内容です。それぞれの位置づけに合わせて、どこを詳しく書くかが異なるだけです。

正確に情報が伝わるように

論文を読みなれている人は、あらまし、はじめに、おわりに、結論の順に読んで論文の主張を理解した上で、他の章を読み出します。これらの内容に一貫性があり、さらにほかの章が論文の適切なアピールに役立っているなら、読者はきちんと評価してくれるでしょう。

逆に、各章や全体の見通しが悪かったり、話がずれていると、素晴らしい成果であっても読者は理解できないでしょう。論文はある問題に対する解決法を提案するものであって、それ以外の情報は要りません。書かないといけないものを書くのであって、書きたいことを書くのではありません。

このことは論文だけではありません。技術文章をはじめ、お客様への提案賞など、仕事にかかわる文章すべてが同じです。要点を絞り、結論と全体像を示せは、情報を正しく伝えることができるでしょう。

最終回に続く

このエントリーをはてなブックマークに追加

[#Node-RED] ファンクションノードのデバッグどうしてる?

今年はNode-RED UG Osaka勉強会 vol.3 で発表しました。

Node-REDのファンクションノードはJavascriptでプログラミングすることができます。一つのノードで複数の処理を行えますので、ループ処理も一つのノードで実現できます。

その反面、Node-REDであるにもかかわらず、工夫をしないとVisualなデバッグはできません。この発表では、デバッグ方法に応じたテクニックを説明しました。

1.プログラムを一時的に修正して確認する

デバッグの際はプログラムを一部修正して動作を確認します。しかし確認が終われば元に戻さないといけません。できれば簡単に変更して、簡単に戻したいものです。

• デバッグ用に端子を増やしても既存コードは そのままで良い

ファンクションノードの端子は簡単に増減できます。それぞれの端子にmsgを送るには配列をnode.send()しないといけません。しかし、配列の要素と端子数は必ずしも一致しなくてよいので、最終端子をデバッグ用に使えば、簡単にデバッグ情報の追加削除が(フロー的に)できます。

• コメントアウトは[CTRL]+[ / ]

とはいえ、ファンクションノードのプログラムに追記する必要がありますし、console.log()が使いやすい場合もあるでしょう。そのようなデバッグのコードをコメントアウトする際は、[CTRL]+[ / ]を使うと行単位でコメントできます。再度[CTRL]+[ / ]するとコメントが外せます。

2.処理の追跡が容易なこと

デバッグの際は、プログラムがどのように、あるいはどこまで進んだかを確認して、どこが間違っているかを確認します。

• デバッグノードの出力を切り分ける

デバッグノードの出力は標準のデバッグタブのほか、ステータスやコンソールにも出力できます。ほかの情報があまり出力されていない出力先を選べば、確認が容易になるでしょう。

• イベント的なものにはディレイノードや Dashboardのnotificationが便利

今どこを処理しているかを確認したい場合は、短時間表示された後に自動的に消えるディレイノードや Dashboardのnotificationが便利です。特にディレイノードはディレイする時間だけ表示されるので便利です。

• httpStaticにログ等を出力する

大量なログの場合、ファイルノードを使って出力する方法があります。その出力先をseting.jsのhttpStaticに指定されたディレクトリに置くと、ブラウザで取り出せるようになります。単純なファイルはもちろん、CSVやHTML形式にすると、色々と応用できるでしょう。

3.プログラム状態を見分けやすいこと

処理の経路ではなく状態を示したい時もあるでしょう。

• ファンクションノードやデバッグノードのstatusで状態を表示

一瞬ではなく状態を表示したままにするのには、ファンクションノードやデバッグノードのstatusが便利です。一度表示すると、新しい情報を表示するまで状態を確認できます。

• Dashboardのtextも便利

Dashboardのtextはブラウザで確認することができます。


このようにファンクションノードのデバッグ方法は多様です。必要に応じて使ってください。

 

このエントリーをはてなブックマークに追加

論文研修会(WS はじめに編)

この記事は SRA Advent Calendar 2019 16日目の記事です。
今回は実際に論文(実際は事例報告の要旨)の「はじめに」を書いてもらいました。「はじめに」は論文の問題設定と問題に対する論文のアプローチを説明します。実際に書いてもらって気になる点を指摘しました。なかなか面白い事例が出てきて、基本の3点さえ押さえれば良い事例報告になりそうでした。

解説

まず、前回の振り返りを兼ねてパラグラフライティングを説明しました(サンプル1)。各段落の先頭だけを読むだけで全体の論理展開がわかるようになっています。ただし最初の1段落目は2行目に趣旨があります。

これは興味を引くように「ツールやプロセスが重要」ということをアジャイルソフトウェア開発宣言を用いて逆説的に説明しているからです。また、最初の段落の最後が「つなぎ」になっていることも説明しました。

ワークショップ

採録された(普通レベルの)サンプル2を示して、各自の事例の「はじめに」を書いてもらいました。

事例を5行の箇条書きで書いてくるように課題を出していました。これはサンプル1の最初の1行に相当するものですが、それを2段落ごとにまとめて、問題設定、事例の内容、結論で1段落ずつになるように書いてもらいました。

実際に書いたものをみんなで読みながらコメントしました。コメントの多くは以下の基本的なものでした。

1.問題設定はやったことの裏返し、関係ないことは書かない
2.問題設定は広い内容から狭い具体的な内容に狭めていく
3.評価に合わせて書く。具体的すぎない一般的問題として説明すると汎用性が上がる。評価者が興味を持つようにする。

特に3番目は仕事でも重要なところで、お客様に合わせた提案でないとうまくいかないですね。このように論文を書くことは、実際の仕事にもつながる学びがあって面白いです。

次回は残りの本文を書きます。「全体を示してから詳細を書く」というパラグラフライティングの構造が入れ子になっていることを説明するつもりです。

 

このエントリーをはてなブックマークに追加

 

論文研修会(座学 本編)

この記事は SRA Advent Calendar 2019 9日目の記事です。

前回(論文研修会(導入編)- 論理的思考のすすめ -)に続き、論文の書き方を情報伝達あるいは論理的思考の観点で説明しました。
大まかな構造を理解してもらえたかと思います。

 

 

同じスライドを以前はシンポジウム参加の勧めとして書いていました(社会人のためのシンポジウム発表入門 リーン論文作法

次回はいよいよワークショップです。事例報告の「はじめに」を書き始めてもらいます(16日目の記事に続く)。

 

このエントリーをはてなブックマークに追加

論文研修会(導入編)- 論理的思考のすすめ -

この記事は SRA Advent Calendar 2019 2日目の記事です。

私の所属する関西事業部では、社内研修会というものを実施しています。個人的には、勉強会のようなものはオープンに行う方が、新しい技術を身につけられてよいし、社内を知ることができると思っています(社内勉強会より社外の勉強会)。しかし、社内でないと話しにくい内容もあるもので、今回行う論文の書き方などがそれで、論文と言いながら事例報告の概要を書くのですが、外に出せるネタがあるとは限らないので、社員だけが知ることのできる事例をもとに書き方を学び、それを通じて論理的思考を学ぶ。なんていうのは社内だからできることです。

論文というのは技術情報を伝達する方法の一つです。古くからソフトウェア開発では「コミュニケーション」が問題とされることが多くありました。しかし、この「コミュニケーション」には2つの側面があって、一つは情報伝達、もう一つが人間関係に起因する協力的な関係が気づけるかどうかだと思います。

このうち情報伝達のトラブルは、論理的思考力を身に着けることで大きく改善します。スライド中にある

  • いつのまにか話が長くなって 打ち合わせがなかなか終らない。
  • お客様や上司に理解してもらえず 意見が通らない。
  • 話を直接聞いているのに勘違いする。

などは、論文作成を通じて論理的思考力が身についていれば、多くの混乱を避けることができるでし
ょう。

参加者は社外発表をきたされている人や、昇格に向けて一皮むけてほしい人たちでした。内容はそれなりに伝わったようで、納得したり、耳が痛かったりしたようです。

スライドの説明のあと、以前日科技連でお話しした論文の書き方を説明しました(9日目の記事に続く)。

 

このエントリーをはてなブックマークに追加

 

スクリプト言語入門 - シェル芸のすすめ - 第2回クラウド勉強会

かつて「社内勉強会より社外の勉強会」という記事を書きました。この中にも書いているように社内勉強会にも利点があります。

社外ではあまり受けられない内容を、実際の業務経験を踏まえつつ、必要なメンバーに説明するには社内勉強会も良い方法だと思います。

今回はbashを中心にスクリプト言語の基本を説明しました。

このエントリーをはてなブックマークに追加


Node-RED: joinノードでタイムアウト処理

Node-REDアドベントカレンダーからの転載です(SRA Advent Calendar 2018からもリンクしています)。

はじめに

Node-REDで通信をする際のタイムアウト処理は、ユーザディレクトリ(~/.node-red)のsetting.jsで変更することができます。例えば、httpリクエストのタイムアウトは、httpRequestTimeoutで変更できます。

しかし、全体の処理時間に制限がある場合など、呼び出し先などによって変更したい場合は対応できません。オーソドックスな方法はファンクションノードで頑張ることかもしれませんが、それではデバッグノードで簡単にデバッグするというNode-REDらしい開発ができません。そこで、標準ノードであるjoinノードを使って、呼び出しの際のタイムアウトを処理する方法を考えてみました。

joinノード

joinノードはsplitノードと組み合わされることが多く、配列などをsplitノードで分割し、それぞれを非同期に処理した後にjoinノードでまとめるという使い方をされます。実はjoinノードは単体でも利用可能で、複数のmsgオブジェクトをタイムアウト時間内にまとめて出力することができます。これを利用するわけです。

具体的には、httpリクエストの直前でmsgオブジェクトをリクエスト処理用とタイムアウト処理用に作成して利用します。joinノードでは、まとめる単位ごとに共通のidが必要で、これにはmsg._msgidを使っています。また、総数のcount、それぞれのmsgオブジェクトを識別するindexが必要です。

joinノードでは結合対象のプロパティ以外には破壊的ですので、結合対象のプロパティに保存しておきたいデータをコピーしておきます。

フロー

実際のフローが下記になります。テスト用サーバーがあるので複雑に見えますが、主要な処理は上部の7つほどのノードだけです。

Timeout_flow

ポイントは、joinの前に必要なプロパティをセットすることです。また、タイムアウトの際にはチェック用のメッセージが流れた後でhttpのレスポンスが返ってきますのでこれを捨てる必要があることです。

上部のcatchノードはタイムアウトの際に例外が発生するのでつけていますが、この辺はお好みで変更してください。

注意点

更新処理の場合、クライアント側でタイムアウトしてもサーバで処理が行われる可能性がありますので注意してください。

コード
元記事の下のほうになるコードをインポート(読み込み)して使ってください。

このエントリーをはてなブックマークに追加


大切なことはスタートレックから学んだ(総集編)

SRAアドベントカレンダーからのまとめです。

エンジニアの誇り

スタートレックとは宇宙大作戦から始まるSFテレビドラマシリーズです(wikipediaU.S.S. Kyushu)。複数の番組があり、制作された時代によって背景にあるテーマ(価値観)が異なっていて様々な刺激を感じます。

バブル崩壊後に公開されたスタートレック:ヴォイジャーは、バブル期のイケイケどんどんから新たな歩みを一歩ずつ進めていこうとする言葉がありました。

「栄光を築くのは戦士かもしれないけど、社会を築くのはエンジニアよ」

         スタートレック:ヴォイジャーの トレス中尉の言葉

戦士のところを企業戦士と読み替えてみてください。企業において営業や経営層は、売り上げに責任を持つことから、評価が高いかもしれませんが、実際にシステムを開発するのはエンジニアです。

利用者に喜ばれるシステムを作ることで信頼を勝ち取り、企業活動を通じて社会に貢献することで、その存続を担うのはエンジニアの仕事です。

開発が遅れたり、トラブルが生じる方が会社の利益になることもあるでしょうけど、「社会を築く」という誇りがより良いシステムの開発に我々を向かわせるのだと思います。

新しい技術への挑戦

多くの刺激を受けたのは、バブル期の「新スタートレック」というシリーズです。科学技術の発展でお金があれば何でもできるような社会風土の中で、人間や家庭に対して問いかける場面が多くあります。

「生まれつきの親なんて一人もいませんよ。みんな苦労しながら学ぶんです。」

            by カウンセラートロイ@新スタートレック4-4

もっと早く聞きたかった言葉です。うまくいかないと、何かにつけて自分はダメだ、向いていないと思ってしまいがちです。しかし、全知全能なのは神様だけで、人間は完ぺきではありません。うまくいかなければ、勉強すればよいのです。

技術者は、新しい技術に常に立ち向かわなければなりません。経験のある環境でもバージョンアップでトラブルに合うこともあるでしょう。

常に学ぶことを忘れない。エンジニアに求められていることです。

プロジェクト

スタートレックのすべてのシリーズに男女間の話が出てきます。坂本龍馬が世の中の情勢を男女間の話に例えたように、プロジェクトを男女間の話に例えると学びも得ることができます。

「あんな恋は二度と無い」
「そうよ」
「意外なセリフ」
「また恋はする。でも同じ恋は二度とないわ。いつもちがうの」
「恋って難しいね」
「そういうものよ」

                  新スタートレックより

恋をプロジェクトに置き換えてみてください。プロジェクトは常に新しい何かを作る仕事ですから、同じプロジェクトは2度とありません。だから、いつも難しいのでしょう。

理念の大切さ

スタートレックは未知の宇宙を航海するドラマです。未知の文明に遭遇した際に影響を与えてしまわないことが、重要な理念になっています。

そのほかにも惑星連邦憲法があって、裁判を行う際には重要な役目を果たします。しかし、未来においても裁判で不条理な主張をする人間がいます。そこで、ピカードが言った一言。

「憲法の基本理念を勝手に覆す事はできない」

           ピカード@新スタートレック シーズン4 第21話

アジャイル開発が話題になりだした頃、クレド(信条)が話題になりました。会社や組織が同じ方向を向くためには必要なものです。

SRAにもクレドのようなものがありますが、聞く機会も少ないので暗記している人はあまりいないでしょう。とはいっても、その中に「プロフェッショナル集団である」という言葉があることだけは、多くの人が知っています。そのことが技術志向の会社であることにつながっています。

もちろん、SRAにもそうではないと思う人はいるでしょうが、その理念は勝手に覆すことはできないのです。

組織の考え方

スタートレックは宇宙ステーションが舞台のDS9を除いて、戦闘能力を持つ宇宙船のお話です。登場人物はピラミッド構造の組織に属し、上長の命令は絶対です。

しかし、惑星連邦の理念に反する場合や緊急事態では、命令に反することも行われます。今回は、そんな場面でのピカード艦長の言葉を紹介しましょう。

「私は命令に従っただけです」という言葉でどれだけほと多くの過ちが正当化されてきたと思う。自分の考えを持たず、ただ命令に従うだけの士官なら連邦には要らない。

                ジャン・リュック・ピカード@新スタートレック

このような上長の懐の深さが、組織を健全に保つのだと思います。

SRAでも上長に反論するような気骨のある人間を喜ぶ人が少なからずいて、オープンで風通しの良い環境を保っているのだと思います。気骨のある人は、ぜひSRAにお越しください。

このエントリーをはてなブックマークに追加

Node-REDで世界が変わる!

SRA Advent Calendar 2018 3日目の記事の複製です。)

ソフトウェアの世界は時間をかけながらではありますが、昔に比べると大きく変化しました。

その大きな要因は、ビジネス環境の変化が激しくなったことです。激しい変化に合わせてサービスを早く提供しなければならなくなりました。サービスの実装も変化に柔軟に対応するできるように、より小さな単位で開発する一方で、それらを組み合わせてより大きなシステムが構築されるようになりました。また、組み合わせる対象も、実行環境や共通部品などは一から開発するのではなく、オープンソースやクラウドなどいわゆる「有りもの」を利用するようになりました。

Node-REDはこのように変化したソフトウェアの世界に適した特徴を持つ開発環境です。Node-REDを使えば新しいサービスで、新しい世界を築くことができます。ソフトウェア技術者にとって、それはかけがえのない喜びです。

サービスを早く提供する

ビジネスのスピードが速くなるにつれて、サービスを早く提供することに対する要求は日ごとに増してきました。

特に、近年のシステムは、

  • UI/UXのように使わないと良し悪しがわからない
  • 複数のモジュールが関連するので、作らないと実現可能性や問題点がわからない
  • クラウドやネットワークなど、運用しないと費用がわからない

といったことが多く、ビジネスに負けないためにはより早くサービスを提供する必要があります。

システムを早く提供するには、いくつかの方法がとられてきました。最初に行われたのは、高機能な言語やライブラリを用意することです。プログラムの記述を少なくして、実装時間を減らしたのです。

次に行われたのは自動化です。古くはmakeコマンドから始まるこの流れは、ビルドやデプロイ、テストの自動化に発展しました。そして、実装後の時間を短縮しました。

そしてインクリメンタルな開発が最後に行われました。システムが複雑になるにつれ、上流の工数はどんどん増え、サービス開始まで時間がかかるようになりましたが、実際に動かすと問題が生じて手戻りの生じることもありました。

そこで、小さな単位で実装を繰り返して、リリースを早めるようになりました。これは、仕様に対する問題を随時解決して大きな失敗を防ぐ、いわゆる「早めに小さく失敗する」ことにもなりました。

Node-REDにはこのようにサービスを早く提供することを可能にする仕組みがあります。

より小さく、より大きく

ビジネス環境の変化が速くなると、サービスを提供した後も柔軟に対応できるとともに、サービスを継続的に利用できることが求められるようになりました。

そこで、従来のようにモノリシックな1つのシステムではなく、小さな機能ごとに実装して組み合わせることで、システム全体を止めることなく、バージョンアップや保守できる構成がとられるようになりました。

そのような仕組みを実現するには、融通の利かないソフトウェアを中心に周辺のソフトウェアで調整する方法では難しく、それぞれのソフトウェアが柔軟であることが求められます。また、小規模システムでも動作すること、様々な機能を容易に組み合わせられることが必要です。

Node-REDには以下のような特徴があるので、小さなソフトウェアを組み合わせて柔軟なシステムを作ることができます。

有りものをうまく利用する

上にあげたような対策をとっていても、すべてを1から作っていたのでは開発規模が大きくなってしまいます。サービスを早く提供するには、オープンソースやクラウドなどいわゆる「有りもの」を利用して、効率よくシステムを構築する必要があります。

Node-REDには、モジュールやソースの交換が容易が容易な仕組みがあり、すでに多くのオープンソースのノード(モジュール)やフロー(プログラム)が流通しています。

おわりに

このようにソフトウェアの世界の変化に対応できる仕組みや環境が、Node-REDにはそろっています。その大きな要因であるビジネスの激しい変化に合わせて、サービスを早く提供することができるでしょう。

しかし、プロトタイプと同じように早く開発できるだけでは、品質の高いソフトウェアを開発することはできません。ある程度大きなソフトウェアを開発するには、きちんと設計をしないとうまくいきません(Node-REDで品質の高いソフトウェアを開発する

Node-REDは(1)ノードに処理を表す名前(日本語可)をつければ手順を理解しやすくなりますし、最近のバージョンではグローバルなどコンテキストデータの構造や値を参照できますし(Version 0.19 released)、通信インタフェースを使って仕様の確認が可能です。

このようなNode-REDの特徴を生かしながら設計と確認を繰り返せば、大規模なソフトウェアの開発も可能でしょう(プロのためのNode-RED再入門)。

今までにない世界を作って、多くの人に幸せにすることはエンジニアの特権で、こんなに楽しいことはありません。あなたもNode-REDを使って、ぜひ新しい世界を切り開いてください。

このエントリーをはてなブックマークに追加


«デブサミ関西でNode-REDとペンギンと勇気の話をしました #devsumiB