無料ブログはココログ

イマドキのレコードプレーヤー 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日目の記事に続く)。

 

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

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

この記事は 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で世界が変わる!