無料ブログはココログ

One fact in one placeとチケット駆動開発 - Software Processes are Software, Too -

プロセスプログラミングを提唱したオスターワイル(Leon J. Osterweil)氏のことば

  “Software Processes are Software, Too”
 (ソフトウェアプロセスもソフトウェアである)

をヒントに、開発とマネージメントの共通点として、今回は「One fact in one place」と「チケット駆動開発」を考えてみます。開発者からマネージメントをするようになった方には経験を生かした管理を、管理をされている方には技術的な裏付けを知る機会になれば幸いです。

One fact in one place

データベースの正規化で使われる言葉です。ほかのデータから算出できる推移従属のデータを除いて、データを1か所に限定することです。同じデータは1か所にしかないので、常に一貫性のあるデータ集合を求められるようにします。他のテーブルと関連付ける場合もデータベースの機能を使えば、矛盾の生じない構造を実現しつつ多くの情報を管理することができます。

チケット駆動開発

チケットで障害やタスクを管理するRedmineTracなどを用いて、情報共有しつつ開発を進めていく方法です。これらのツールはITS(Issue Tracking System) あるいじはチケットシステムと呼ばれ、チケットを介して議論やステータスの管理ができます。プロジェクトの様々な情報をこのチケットに紐づけて管理すれば、最新の状況をチーム内で共有できます。

チケット駆動開発をうまく実践するには、チケットで情報を一元管理することです。ITS本来の使い方である障害や課題だけでなくタスクもチケットで管理し、バージョン管理ツールやWikiの情報もチケットと関連付けます。こうすることでプロジェクトの様々な情報をチケットと紐づけて管理できます。

何らかの理由で表計算ツールなど他の形式にする場合も、チケットから生成すれば情報の一貫性が保てます。とはいっても情報の粒度や目的などで自動生成できない時もあるでしょう。そのような場合も一から作成するのでなく、チケットの情報を確認しながら作成する、関連するチケット番号を記載するなどで、情報間の矛盾を減らし、正確で詳しい資料を作ることができるでしょう。

このような考え方はチケット駆動開発だけではありません。開発ドキュメントは工程間で抜け漏れなくトレースできないといけませんし、お客様への説明も一貫性がないといけません。アジャイル開発のストーリーカードとタスクカードの関係も同じでしょう。チケットシステムを利用しなくても、情報を小さな単位で整理して矛盾が生じないようにしましょう。

この記事はSRAアドベントカレンダーでも公開しています。

マルチスレッド処理と進捗管理・配員・作業分割/割り当て- Software Processes are Software, Too -

プロセスプログラミングを提唱したオスターワイル(Leon J. Osterweil)氏のことば

 “Software Processes are Software, Too
 (ソフトウェアプロセスもソフトウェアである)

をヒントに、開発とマネージメントの共通点として、今回は「カプセル化」と「組織パターン」を考えてみます。開発者からマネージメントをするようになった方には経験を生かした管理を、管理をされている方には技術的な裏付けを知る機会になれば幸いです

マルチスレッド処理

複雑な問題を短時間で処理する方法の一つです。複数のスレッドを用いて並列処理すれば効率的です。シングルスレッドの処理をマルチスレッドで処理する場合、以下のような順になるでしょう。

  1. 並列処理の準備
  2. スレッド開始処理
  3. スレッドの主処理
  4. スレッド終了処理
  5. 並列処理の後処理

これらはマルチスレッドを考慮して設計します。うまく設計できればスレッド数に応じて効率化されますが、うまく設計できないで主処理以外のオーバーヘッドが多い場合はスレッドが増えても効率化できません。特にすべてのスレッドの完了を待つ場合は最も遅い処理に全体が引きずられるでしょう。

進捗管理・配員・作業分割/割り当て

並列処理の簡単な例は進捗管理です。リーダーが各メンバーから順にヒアリングするには多くの時間が必要ですが、メンバーそれぞれが進捗を報告すれば短時間で終わるでしょう。しかし、各メンバーがバラバラな形式で好きなタイミングで報告するなら、内容の把握や確認でかえって時間がかかるかもしれません。手分けする準備として情報共有の仕組みを用意しておけば、メンバーの処理が標準化でき、その管理や集約も容易になるでしょう。

配員の場合はさらに工夫が必要です。進捗や成果物の共有環境を用意するのはもちろんのこと、メンバーが独立に同程度の品質を保てるようにします。具体的には横展開できるように先行して部分開発してサンプルを用意します。サンプルは成果物だけでなく、部分開発を踏まえたルールや手順などを用意して、サンプルをたたき台に作業を横展開できるようにします。

作業の分割にも工夫が必要です。作業量を平準化しやすいように時間のかかる作業は細かな作業に分割します。また、マイルストーンに合わせないといけない作業とそれ以外を分けておき、予定通りに進まないときに作業の空きがないように工夫します。

作業の割り当てにも工夫が必要です。作業者の得意な作業を割り当てれば一見、効率的ですが、作業には偏りがあるので、作業量がバラツキが出て手が空いてしまったり、誰かが体調を壊すとプロジェクト全体が止まってしまうことになります。このようなことを防ぐには、教育的な視点で作業を割り当てたり、処理の実装とテストで担当者を分ける、ペア/モブプログラミング(作業)などを長期的な視点で取り入れると良いでしょう。

この記事はSRAアドベントカレンダーでも公開しています。

 

カプセル化と組織パターン - Software Processes are Software, Too -

プロセスプログラミングを提唱したオスターワイル(Leon J. Osterweil)氏のことば

 “Software Processes are Software, Too”
 (ソフトウェアプロセスもソフトウェアである)

をヒントに、開発とマネージメントの共通点として、今回は「カプセル化」と「組織パターン」を考えてみます。開発者からマネージメントをするようになった方には経験を生かした管理を、管理をされている方には技術的な裏付けを知る機会になれば幸いです

カプセル化

カプセル化(リンク先はwikipedia)は情報隠蔽の手法で、オブジェクト指向にも取り入れられています。カプセル化することで外部には必要な情報のみが公開され、内部のデータや処理は守られます。オブジェクト指向において、外部からはメソッドを介してのみ情報を得ることができます。

オブジェクト間で連携するには、呼び出しとデータストア共有の2つの方法があります。呼び出しは責務を果たしてくれるオブジェクトのインタフェースを定めてその参照を知って知っていることで、オブジェクトに対して定められた方法で呼び出すことで、オブジェクト間で連携できます。データストア共有ではデータベースのようなデータストアを介する方法です。データ構造をあらかじめ決めておいて、オブジェクト間でデータの参照や更新を行います。

組織パターン

組織パターンは,開発チームをどう編成すればいいのかをパターンとして整理したものです。組織パターンはアジャイル開発のひとつであるスクラム開発にも取り入れられていて、プロダクトオーナーとスクラムマスターは、それぞれ門番、防火壁に相当します。チームへのインタフェースを限定し、外部からチームを守ります。チームをカプセル化するわけです。アジャイル開発に限らず、チームを外部から守り、必要な情報を提供できれば、チームは外部のストレスを受けないで開発に集中できます。また依頼すべき役割を担うチームを知り、適切な方法でアクセスすることでチーム間の連携ができます。

データストアによる情報共有はその方法によってメリット・デメリットがあります。

  • タスクカード:壁やホワイトボードに張り出すことでチームの状況を見える化します。無意識に目に入るので常にゴールを共有できます。その反面、色分けなどで工夫しないと管理や検索が難しいので電子化されることも増えています。
  • チケット:RedmineやGitHUBなどのチケット(イシュー)を使ってタスクを管理します。優先順序などそのままでは扱いにくいので、タスクカード風のUIをもつJIRAやプラグインが使われることもあります。
  • 資料:チーム内で資料を共有します。いつでも再確認ができる反面、資料の質がコミュニケーションの質になります。
  • ミーティング:もっともアナログな情報共有です。音声による情報共有はニュアンスなど情報量鵜が多いので、チケットや資料などの共有と併せて実施されます。人数や時間によって工数がかかります。

システム開発と同じように、どのようにチーム間あるいはチーム内で連携するかで、成否が決まります。ウォータフォールや味あるなど既存のプロセスを利用するとある程度の品質は得られますが、そのプロセスのメリット・デメリットを把握していないと効率的な開発は行えないでしょう。

この記事はSRAアドベントカレンダーでも公開しています。

Greedy algorithmと2割8割の法則 - Software Processes are Software, Too -

プロセスプログラミングを提唱したオスターワイル(Leon J. Osterweil)氏のことば
 “Software Processes are Software, Too”
 (ソフトウェアプロセスもソフトウェアである)
をヒントに、開発とマネージメントの共通点として、今回は「Greedy algorith」と「2割8割の法則」を考えてみます。開発者からマネージメントをするようになった方には経験を生かした管理を、管理をされている方には技術的な裏付けを知る機会になれば幸いです。

 

greedy algorithm

世の中には簡単な問題と難しい問題があり、例えば並べ替えするときに単純に2重ループするとデータ数Nが増えるとその2乗(N^2)ほど時間がかかりますが、処理を工夫して木構造にデータを並べておけばその木の高さ(logN)で処理が済みます(実装者のための計算量のはなし - O(logN)などをわかり易く説明しました -)。

これに対してナップザックにいろいろな大きさの荷物を入れるような問題は、NP困難と呼ばれる難しい問題です。すべての組み合わせを確認しないと隙間を最も少なくできないからです。そこで Greedy algorithmという手法がとられます。これは隙間の少ない(価値のある)大きなものから貪欲に詰めていく方法です。最適ではないですが、ほどほどにうまく詰める方法です。

プロジェクト管理においても最適な計画を立てることは簡単ではありません。そこで、大事な作業や後回しにすると問題になる作業から実行あるいは計画すると、ほどほどに良い計画を作ることができます。アジャイル開発のやり方はまさにこのような方法です。計画駆動な開発ならこの方法でできた計画をたたき台に、より最適な計画を作成することができるでしょう。

#初期のスクラムガイドは優先順序だけで実行時順序を決めていたので、リスクの考慮が乏しいものでしたが、その後見直されたようですね。

閑話休題。プロジェクトの実行や計画には様々な要素があって簡単ではありません。まずはどの作業が価値があるか、すなわち重要あるいは後回しにできないかをまずは見極めてそれに基づいて計画しましょう。

もちろん、そもそものソフト性能にも利用できます。ソフトウェアの処理データが増えることで処理が遅くなるような場合に、網羅的で単純な繰り返し処理になっていないか、調査してみてください。

 

2割8割の法則

網羅的に実施しない場合に重要なものから実施するとどのような効果があるのでしょう。2割8割の法則はパレートの法則とも呼ばれ、度数順に要素を並べるパレート図を描くと、一般に上位2割が8割を占めているという法則です。

この法則に基づくと、アプリケーションの価値のある2割の機能を実現するだけで8割の価値があり、残りの8割の機能はあまり価値がないということになります。アジャイル開発では価値のあるものから開発し、随時リリースすることで価値の少ない8割の開発よりもリリース後の外界の変化に対応することを選んでいると考えられます。

2割8割の法則は障害の対応や改善において用いられています。分析して障害の量や質が問題になる上位2割の障害対策を行えば、より効果が得られるでしょう。

 

プロジェクトを進化させる

プロジェクトは日々変化します。プロジェクトもそのままではうまくいかず、常に変え続けないといけません。ソフトウェア開発ではリソースが潤沢ではない場合が多いので、孫氏の兵法に示されるようにパワーを分散せずにポイントを絞って攻めるとうまくいくでしょう。

グリーディアルゴリズムや2割8割の法則も同じようにポイントを絞る方法で、大事なことを見極め、優先順位をつけるという特徴があります。これらを生かせば、プロジェクトを変え続けてより効果的に進化させることができるでしょう。

参考:
[#agileto2012] 『チェンジ!』の考え方 ~マネしやんと!~

「任せて、任せず」「魚を与えるのではなく"釣り"を教えよ」

松下幸之助氏の言葉です。
パナソニック新社長が「過去」を研究し続ける真意 停滞続く巨艦が松下時代から失ったものは何か
http://a.msn.com/01/ja-jp/AAMFYBp?ocid=st

この記事によると

「仕事は部下に任せていても、経営者は常に事業を見て、必要なときには指示をする。事細かに指示せず、自主責任を求める」

とあります。事細かに指導していては成長しない。任せるべきは任せ、ここぞというときに「過ちすな。心して降りよ。」と高名の木登りのように指示をするのでしょう。

この「任せて、任せず」は結構難しいと思います。前提として以下の3つがあります。

  • 任せられる人であること:わかっていない人には任せられません
  • 任せた人の弱点を知っていること:どのような失敗をしそうか知らないと事細かに言ってしまいそうです
  • 任せた作業のポイントがわかっていること:どのような作業かわかっていないことを丸投げしてはここぞという指示ができません

これらを満たすには、教育(育てること)がポイントだと思います。実現可能性が検討できているなら、たぶん3番目はできているのでしょうから、任せたい人を任せられる人に育てることでしょう。育てる中で2番目はわかると思います。

では、育てるにはどうすれば良いかというと、思い浮かぶのは「魚を与えるのではなく釣り方を教えよ」です。答えを教えるのでなく、答えを導く方法を教えることです。

それで良いと思っていたのですが、検索してみると

 ”魚を与えるのではなく釣り方を教えよ”じゃダメだと思う。 
https://toksato.hatenablog.com/entry/2010/03/24/123936

という記事にあたりました。「楽しさや意義という土台から、テクニックまで。『釣りとはなんぞや』を教えることが、大切」とのこと。ソフトウェア開発のいろいろな技術だけでなく、そもそも会社がどう成り立っていて周りから何を期待されているか、自分の人生においてソフトウェア開発をなぜするのか、輝いている先輩の原動力は何か、これらがわかっていないとこなすことだけになり、やがて仕事が辛くなるでしょう。

人生について教えることはむずかしいですが、モノづくりの楽しさや、人の役に立つ喜びを感じてもらうことが、任せられる人への第一歩かなぁ。などと思いました。

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

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


 







論理的に考え伝える – 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.おわりに

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

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

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