無料ブログはココログ

メールやチャットでも役立つテクニック

「開発現場で役立つ論文の書き方のお話」の前半を社内向けにした際のおまけです。
似たようなテクニックはこれ以外にも色々あると思います。整理できていない内容を口頭で説明する場合は「とりあえず最後まで聞いてもらえますか?」という方法もありますね。


 







論理的に考え伝える – SEA関西「開発現場で役立つ論文の書き方のお話」 -

論理的ということは論理的な構造を持つということで、人に伝えるということは物事を論理的に整理して、伝わる構造あてはめるということだ。ソフトウェア開発現場において、伝わらない事で生じるトラブルは少なくない。それは説明の順序であったり、端的に表現できないからだったりする。私が社内外で論文の書き方を説明しているのは、論文にはトラブルを未然に防ぐ「論理的に考え伝える」構造が含まれているからである。
論理的な構造に整理する方法は数多くあり階層的に表現するものから、目的に応じて記法を変えるTOCfE http://sakaba.cocolog-nifty.com/sakaba/toctocfe/index.html のようなものもある。しかし、ソフトウェアと同じように大きな情報を扱うには、構造化プログラミングのように1種類の構造だけでなく、クラスや関数のようにある程度の塊でさらに構造を持つ必要がある。論文においては論理的な構造を実現する方法として、パラグラフライティングが用いられる。
パラグラフライティングは「各まとまりの先頭には最も重要な文を置き, それ以後にはその文の補足説明のための文を置く」(パラグラフライティングの作法 -書き手にもメリットのある文配置ルール-)というもので、主に要旨+詳細で段落(パラグラフ)を構成する。YES/NOをはっきりさせる英語文化を感じさせる構造である(日本の小学校では起承転結が教えられるが、これでは最後まで聞かないと結論がわからない。いかにも日本語的だ)。
パラグラフライティングの良いところは、初めに伝えたいことの方向性を示しているので、内容をミスリードしないことだ。パラグラフライティングで書かれた文章は、要旨がなくても各段落の1行目だけを読むことで概要を把握することができる。逆に文章を書くときは、各段落に書くべきことを1行ずつ書いておいて、それを膨らませば良い。
初めに伝えたいことの方向性を示というのはミスリードを防ぐ良い方法で、これは開発現場でも大いに役立つものなので、今回の講演(第74回 SEA関西プロセス分科会 「開発現場で役立つ論文の書き方のお話」)をおこなった。論文で採用されているIMRADという技術文書の構造がこのような構造を持つだけでなく、わかりやすい論文は各章の段落もこのような構造を持っており、論文の書き方を説明することで、開発現場でも役立つと考えたからだ。

追記: 今回の分科会はソフトウェアシンポジウムの投稿者を増やす目的で開催されました。


 

[Windows10]コア限定で古いソフトを動かす- Wave SplitterでLPのCD化 –

はじまり

昔からある便利そうなソフト(Wave Splitter 1.02)を新しいPCLenovo Yoga Slim 750i 82A100GSJP)にインストールしたら動かない機能がある。これは互換モードだ!と互換モードで動かしても改善しない。大体は動いて部分再生はできるのに、普通の再生や録音ができない。

仕方がないので、録音をHDREcorderで行うと、ファイル分割の処理に使っていた。しかし、慣れてくると結構高機能なことがわかり、これで録音と再生ができればとても便利だということに気づいて、再検討することにした。

コアの限定

調べていると、昔は複数コアがなかったので、コアを限定すると動く場合があることを知った。そういえばスレッドを使っていると書かれていたので、メモリ共有しているならそれが原因で動かないのではないかと考えた。

CPUの限定はアフィニティ・マスクと言われ、いろいろな設定方法があるようだ。Windows Vista以降はStartコマンドでも指定可能で、ショートカットで指定すると良さそうだ。早速、Wave Splitterのショートカットのリンク先の先頭に「C:\Windows\System32\cmd.exe /c start "" /affinity 1 」と挿入した(最後の11つ目ではなく使うCPUを示す値の0ビット目が1という意味。実質同じだが)。

「動いた!再生できる!録音できる!」

だがショートカットのアイコンがcmd.exeで黒くて気持ち悪い。そこで所とカットのアイコンの変更で、Wave SplitterexeにあるCDのアイコンを使うことにした。これで完璧!

LPのCD化

そもそもやりたかったのはLPレコードのCD化だ。ソニーのレコードプレーヤAMAZON)のUSB出力を録音してCD化しようとしたのである。mp3の音も悪くないがやはりCDの方が音が良い。AACも検討したが、いずれ不満が出ると思ってCDにすることにした。

CD化の基本手順は簡単、きれいな音で再生して、録音して、CDを焼く。しかし、それぞれノウハウがある。

  1. きれいな音で再生

レコードにプチプチ音は付きものですが、スプレーして、クリーナーで拭いて、再生する。を繰り返すとかなり減ります。傷は治せませんが、接着剤の塊のようなものはしつこくスプレーしてクリーナーでこするととれました。内袋を変えた方が良いようですが、そこまではしていません(あまり聞かなくなるので)。

  1. 録音

Wave Splitterで録音します。パラメータを調整しながらAuto Splitします。大体曲数と同じになったら、トラックを結合したり分割して本来のトラックに分割します。曲間が短い場合は、手作業でうまく分割できないので、そのトラックだけパラメータを調整しながら再度Auto Splitするとよいようです。無音部分のカットがデフォルトですが、フェード・イン/アウトがあるのでチェックを外しています。

よくある波形を見ながらの編集ではないので手順は増えますが、やり直しが簡単なのでとても快適です。ノイズ除去などはできませんが、音を聞きながらの編集がお手軽で気に入っています。

  1. CDを焼く

Media Playerで音楽用CD-Rを使います。Media Playerにはで音楽用CD-Rを使います。Media Playerには書き込み設定(整理→オプション)でドライブに合わせて低速にしました。Musicフォルダ直下にファイルを置いてCD-Rに書き込んで、ファイルを削除しては「C:\Users\(ユーザー名)\AppData\Local\Microsoft\Media Player\」の中の「*.wmdb」ファイルを全て削除しています(注:Media Playerを普段は使わないのでライブラリの登録をすべて消しています)。

音楽用CD-Rを使うのは、音楽用は上納金が入っていて著作者にお金が入るようになっているからです。データ用と値段が変わらないのが不思議ですし、引退した人や亡くなった方にお金が入らないかもしれませんが気持ちの問題です。

おわりに:テレワークの考慮不足

もともと圧縮せずにCDでやめようと思ったのは、テレワークなので持ち出すことを考えなくてよいことも理由の一つだ。さて、色々とCDに焼いてから気が付いたのだが、NASに置いておけばPCFolder Player)やスマホ(課金済みのOPlayer)で直接再生してやれば良かった。なんだ。。CDはバックアップにもなるのでまあ良いか。。


アイデアをシームレスに実装する - 考える道具としてのNode-RED -

はじめに

 Node-REDが手になじんでしまうと手放せなくなります。Node-REDの開発はもちろんのこと、過去の経緯でほかの言語で開発する際にも設計の確認で使うこともあります。なぜ、こんなに手になじんで、ちょこちょこっと始められるのか考えてみました。

シームレス

 ソフトウェア開発でシームレスという言葉を最初に聞いたのは、オブジェクト指向分析が話題になった時でした。

 1980年代に話題になった構造化分析/設計では、データフロー図で分析したモデルをプログラムの構造図にする際に、中心となる処理を引っ張り上げて機能モジュール間に無理やり上下関係を持たせるなどしていました。工程間でモデルが異なることで分析(What)と設計(How)で溝ができ、あと戻りが難しい開発方法でした。

 オブジェクト指向分析は、分析と設計で同じモデルを用いることで、分析と設計がシームレスに移行できるという点が売りの一つでした。オブジェクト指向設計は実装への移行も容易でした。安定したクラス構造が見つかれば、全行程の作業をシームレスにできました。

 「データは機能より安定している」という意見もあるようですが、作業のきっかけとしてはすぐれているもののデータだけを考えていてもなかなかアイデアはまとまりません。システムにはどのような機能が必要で、どんな順序で処理するか、その中でデータはどのように扱われるか、それらを総合的に考えなければ、イメージを固めて、実現可能性を確認することはできません。

問い

 新しいシステムのアイデアが思い浮かんだとき、あなたはどんなメモを書くでしょうか?

よくある答え

 スマホがあって、サーバーがあって、対象データを保存して、他のユーザや機器が参照するそんなイメージでしょうか。スマホからサーバーへ認証情報を送ると、現在の状態が示されて、スマホのUIで入力した情報がサーバに送られる。業務フロー、シーケンス図、ユースケース図、ユーザーストーリ、そんな感じの記法で書きませんか?

 さて、実現可能性を確認したいので少し実装を考えだすと、データを洗い出してクラスを考え出すのでしょうか。全体のイメージができているならそれも可能でしょう。でも新しい業務なら画面遷移も考えたいのでペーパープロトタイピングで画面遷移を考えて、これが抜けていたとか、この情報が最初にいる、などと間違いに気づいて、データ構造が徐々に安定していくでしょう。

 このように、業務フローやシーケンス図から開発が始まり、システムへの理解が段階的に進みます。

Node-REDなら

 業務フローやシーケンス図を描き始めたタイミングで実装を始められます。

「いやいや、そんなことはないでしょう」そう思われるのも無理はありません。しかし、簡単にできてしまいます。

 スマホから呼び出されるAPIをひとまず作成してグローバルデータを返すようにします。これにはhttp inノードとhttp responseノード、データの取り出しにチェンジノードがあれば良いので3ノードでできます。グローバルには何か入れておかないといけないのでJSONで設定したデータを起動時にセットします。起動時のタイミングをインジェクトノートで出力し、テンプレートノードにJSONで設定、チェンジノードでグローバルに入れるようにします。これでサーバ側の実装は終わりです。合計6ノードでできてしまいます。

 画面遷移を確認する場合は、簡単にWeb画面が作成できるDashboardを使ってスマホのテスト画面が作れます。一覧の画面を作ると、意外な勘違いがが見つかったりします。

データ構造は後から考えても良い

 上の問いへの別解で、型のゆるい言語、あるいは抽象度の高いクラスを使っていきなり実装を始めるという方もおられるでしょう。機能間のインタフェースを明確にしないことで、処理に集中できます。
Node-REDはノードと呼ばれるモジュールの入出力はmsgオブジェクトに統一されています。まずはmsgがどのような順で、どのように流れるかを考えることができます。実装を進めていく中で不足する属性があれば、上流のどこかで準備します。どこで準備するかを考えることが、どのように処理するかを考えることになります。

 もちろん、わかっているデータ構造はあらかじめ実装して構いませんし、プログラムが大きくなるなら早めにデータ構造を考える方が良いでしょう。できたつもりで進めていって、問題が出てくれば追加すればよいのです。

データストレージも後から考える

 とはいえ、データベースなどのデータストレージはよく考えないといけないので、アイデアを確認する際の障壁になりがちです。まずは別にサーバーを立てないことで、容易に始めることができます。

 もっとも簡単な方法がグローバル変数もしくは(タブ内で参照可能な)フロー変数の利用です。javascriptのオブジェクトを保存できますので、属性名で疑似ハッシュとして用いることができます。使ってはいけない属性名があることと、メモリの消費に注意すれば便利に用いることができます。グローバル変数やフロー変数はコンテキストデータのメニューから参照や削除ができますので、意外と便利です。

 少し複雑な検索もしたいのであれば、SQLiteやNeDBが簡単です。RDBやドキュメントDBのようなことができますので、ひとまず動かして考えるのには便利です。ある程度システムの全貌が見えてきて複雑な検索やサーバー間でデータ共有を検討する際にサーバーを立てると良いでしょう。

どこまでシームレスに使えるか

 とりあえず動くようになってから仕様を徐々に固めます。機能拡張やDBなどストレージの確保をすると、徐々に本格的なシステムになるでしょう。Node-REDは実運用で使われている例も多いので、品質保証をすれば、そのまま本番に使うことも可能でしょう。ただし、Node-RED単体では冗長化やアプリ間のデータ共有の仕組みはないので、外付けする必要があります。

 あとは開発規模の問題です。Node-REDは高機能なモジュール(ノード)が多いので、あまり大きくならないかもしれません。しかし、アイデアを整理する際のデータ構造を元に始めると、処理の都合で似て非なる属性がどんどん増えることがあります。これは危険な兆候です。「どうだっけ」と少しでも不安に感じたら、データ構造を見直してください(プロのためのNode-RED再入門)。

おわりに

 Node-REDの手になじむ感じを整理してみました。他にもいろいろ特徴があるので、ぜひ使いこなしてください。

イマドキのレコードプレーヤー SONY PS-LX310BT

半年前に買ったこのプレーヤが、テレワークで役立っているのでご紹介します。

このレコードプレーヤーを買ったきっかけは、昔ファンだったアイドルの曲を聞きたくなったからです。レコードをCDに変換してくれるサービスは色々あるようですが、それなりの枚数があるので安いプレーヤを買ってみようかと思い立ったからです。

1万円ぐらいから再生とMP3に変換する機能のあるプレーヤはあるのですが、評価があまり良くなかったです。そこで、少し上のクラスを見ていると、このプレーヤは、Bluetooth対応でUSB出力端子もあり、上のクラスには負けるもののそれなりに音が良さそう なので選びました。

1.イマドキの機能
1-1 PHONOアンプ搭載
いきなりLINE出力が出ています。むかしはPHONOアンプが高いからと安いプリメインアンプを挟んでいたので、あまり良い音で聞けなかったものです。このプレーヤなら出力をPC用スピーカにつなぐだけでステレオになります。
私はBOSE Companion2 Series IIをつないで聞いています。(現行機種と違って)ピン入力なので直接つなぐだけでとて良い音で聞けてます。

1-2 Bluetooth対応
SBC/APT-X対応です。スピーカーがなくてもAPT-X対応のイヤホンがあれば、それなりに良い音で聞けます。最近は完全ワイヤレスブームで、対応イヤホンが一時的に減っているようですが、私はSONY MDR-EX31BNで聞いていました。
スピーカーの方が気楽で良い音だったり、枚数の多いアルバムはリッピングしたものの方が扱いが楽だったりしますので、イヤホンのアダプタをスピーカにつないでいることの方が多いです。

1-3 USB出力端子搭載
買うまでは謎でしたが、PCにつなぐとUSBオーディオとして認識してくれます。対応しているものなら標準の録音ソフトでも何でもよくて、取り合えずバックアップのつもりで午後のこ~だの最高品質で録音しました。これがなかなか良い音なのですがiTunesでは再生できないので、iPhoneのOPlayer Lite(無償期限切れで広告がうざいので購入済)で再生しています。
OPlayer Liteは画面ロック中も再生できて悪くないのですがプロセスが終了すると忘れたり、すべての曲の再生位置を覚えていたりするので、良く聞く曲は少し品質を落として再度録音して、mp3DirectCutで無音部で曲を切り出しました。
標準で録音するとレベルが低いので、録音時だけ高出力設定にしています。

2.使ってみて
2-1 音が良い
むかしCDが出たころにレコードの方が音が良いという人がいて??だったのですが、スプレーとクリーナーでプチプチ音を消せば、良い音源のレコードはとても良い音で聞くことができます。

2-2 ポモドーロテクニック風に
ポモドーロテクニックは25分ごとに休みますが、レコードの片面が大体20-24分ぐらいなので、音のなっている間に集中するようにして、音がなくなれば休憩すると良い感じで仕事が進みます。

2-3 ブックオフ万歳!
まるで文庫本のようにアルバムもシングルも100円とか200円で売られています。
有名なモノが多く、欲しかったのに我慢したモノがまとめ買いできてしまいます。中には細かな傷のあるものや少し反ったものもありますが、概ね良品でした。

3.おわりに

買って良かったです。
むかし聞いていた曲が、昔より良い音で、扱いやすく聞けてとても幸せです。しかもメジャーな曲は安価に、手に入れにくいものは中古販売で手に入れることができます。
ポモドーロテクニックで作業を効率化したり、ひと時の息抜きにするなど、テレワークにもお勧めです。

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

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

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日目の記事に続く)。

 

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

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