ソフトウェア

2020/11/21

マインドマップをFreeplaneに乗り換えた

マインドマップFreeMindからFreeplaneに乗り換えた。

Japanese - Freeplane - free mind mapping and knowledge management software

FreeMind Ver0.9が使いやすくなっている: プログラマの思索

FreeMindの応用的な使い方: プログラマの思索

【再考】GanttProjectとFreeMindとJude: プログラマの思索

FreePaneの方がGUIが充実していて、VerUpの頻度も多い。
アイコンも多いので、自由に発想しやすい。

僕にとって、マインドマップはなくてはならないツール。
アウトラインプロセッサの代わりに、アイデアを発散して構造化する時に使っている。
こういうツールがないと、文章は書きにくいと感じる。

最近感じるのは、知的労働者にとって、PC上のアプリの操作の慣れ次第で生産性が大きく違うこと。
道具が思考を促進する。
思考と道具は表裏一体。

この考え方は、モデリングツールでも同じ。
また、IntelliJのようなプログラミング開発ツールでも同じ。

この辺りで考えたことも記録しておく。

| | コメント (0)

2020/07/07

ソフトウェアの政治的影響力とは何だろうか

今年になって、台湾の天才IT大臣の記事をチラホラ見かける。
ソフトウェアの政治的影響力を上手に使いこなしているな、と感じたのでメモ。
ラフなメモ書き。

【参考1】
「マジで胸アツ」台湾の天才IT大臣、東京都の新型コロナ対策サイトの修正に自ら参加し話題に

(2) akipiiさんはTwitterを使っています 「時代の変化は速いよね。「マジで胸アツ」台湾の天才IT大臣、東京都の新型コロナ対策サイトの修正に自ら参加し話題に https://t.co/drVTKoZz74」 / Twitter

新型コロナ“神対応”連発で支持率爆上げの台湾 IQ180の38歳天才大臣の対策に世界が注目 (1/4) 〈dot.〉|AERA dot. (アエラドット)

新型コロナ“神対応”連発で支持率爆上げの台湾 IQ180の38歳天才大臣の対策に世界が注目 (2/4) 〈dot.〉|AERA dot. (アエラドット)

新型コロナ“神対応”連発で支持率爆上げの台湾 IQ180の38歳天才大臣の対策に世界が注目 (3/4) 〈dot.〉|AERA dot. (アエラドット)

(引用開始)
タン氏にインタビューした経験がある前出の近藤さんは、こう話す。
「両親の職業がジャーナリストということもあり、彼女は『情報』が人々にどのような影響を与えるかをとても理解しています。
また、現役の閣僚でありながらも特定の政治的立場に立つのではなく、むしろ意見の対立をIT技術で可視化して、解決につなげることを考えている。
入閣した時に『公僕の中の公僕になる』と宣言したとおり、特定団体の利益のために動くのではなく、テクノロジーを駆使して台湾の人々と行政院をつなぐ“パイプ”になっています」
(引用終了)

akipiiさんはTwitterを使っています 「ITによる可視化で政治的対立を消化させる道具にする発想が素晴らしいと思った。Redmineにも通じる。「むしろ意見の対立をIT技術で可視化して、解決につなげることを考えている」新型コロナ“神対応”連発で支持率爆上げの台湾IQ180の38歳天才大臣の対策に世界が注目 AERA dot. https://t.co/GORTP5vWb4」 / Twitter

【参考2】
台湾の天才IT担当大臣オードリー・タンに訊く、新型コロナウイルスの先にある未来の国家とは - Engadget 日本版

akipiiさんはTwitterを使っています 「ソフトウェアの政治力を良く知り尽くして活躍されてる事例。参考になる。” 台湾の天才IT担当大臣オードリー・タンに訊く https://t.co/zxSe7tNwVZ」 / Twitter

こーじさんはTwitterを使っています 「>その一方でパニック買いなど、噂による行動は防ぐ必要があります。そこに対しては、インフォデミック(≒情報の氾濫)より面白いユーモアを発信するという対策に取り組みました。 これ凄い面白い取り組みだな」 / Twitter

akipiiさんはTwitterを使っています 「@saba1024 台湾のIT担当大臣は、人々がシステムやSNSを使うと、どんな行動に走るのか、それを遠くまで見通して意思決定している点が凄いです。ソフトウェアの開発力だけでなく、その政治的影響力、行動経済学の知見、社会心理学の知見を知り尽くしてる、そんな気がします」 / Twitter

こーじさんはTwitterを使っています 「@akipii まさに仰るとおりですね! 時代が人を作るのか、人が時代を作るのかというのはよく言われる話題では有りますが、この方は間違いなくこの時代に必要とされる方ですね。」 / Twitter

台湾の天才IT担当大臣の振る舞いをツイッター上で眺める限り、ソフトウェアの調達方法や影響力の行使の仕方をよく理解しているな、と思う。
たとえば、コロナ感染症サイトへのプルリク、マスク在庫サイトの構築方法、記者会見をすべてオンライン化などがすぐに思い浮かぶ。

彼女のやり方で参考になる点はいくつかある。
1つ目は、ソフトウェアの開発はベンダー委託ではなく、オープンソース開発者のコミュニティを使って、アジャイルに開発していること。
公的なソフトウェアの開発は、官公庁の内部調整やベンダーへの委託によるリスク回避など、数多くの組織的な壁がボトルネックになりがちだ。
しかし、本来、公的なソフトウェアは国民全てがその利益を享受できるものだし、その重要性は高いのだから、いち早くリリースして、漸進的にVerUpしながら開発していくべきだ。
しかも、ソフトウェアは請負契約で作ったら終わりではなく、SaaSと同じく、運用しながらどんどん改善していく開発スタイルなので、ベンダーへの一括委託は元々なじまない。
現在のソフトウェア開発の技術革新の場所は、ベンダーではなく、オープンソースコミュニティに移っているのだから、彼らの力を利用して、国民すべての利益にかなうようなソフトウェアを作るべきだろう。
彼女の言動や行動した結果を見ると、ソフトウェア開発の特徴をよく理解しているように思える。

2つ目は、情報を発信すると人々がどのように影響を受けて、どんな行動に移るのか、という事を彼女はよく考えて理解しているように思えることだ。
「現役の閣僚でありながらも特定の政治的立場に立つのではなく、むしろ意見の対立をIT技術で可視化して、解決につなげることを考えている」という記事の言葉から想像すると、行動経済学の知見をよく知っているのではないか、と思う。

実際、コロナ感染が流行している時期にマスクの情報を何の仕掛けもなく公表するとどうなるのか?
本来マスクが必要な人に情報を知らせるにはどうすればよいのか?

皆が混乱している時に、その情報をIT技術で見える化することで、真実を共有し、そこから各人のあるべき行動を促す。
IT技術は本来、そういう問題解決に使うべきものであるはずだ。

そして、単に、マスク在庫のシステムをアジャイルに作るだけではない。
彼女や他の大臣が率先して、その規範を示していることも大事だ。

「例えば、支給マスクの色がランダムで、ピンクが当たった男子生徒が登校拒否になっているという声が届きましたが、その翌日には閣僚の男性陣によるピンクマスク着用のキャンペーンが始まりました。」という記事の通り、大臣自らが率先して見せれば、他の人も自然にその行動変容を受け入れてくれる。

「組織文化は組織のトップが作り出すもの。組織のトップはもっと汗をかくべき」と、とある先生から組織論の授業で習った。
僕が理解するには、人がたくさん集まっても、単なる集団であり、何かの目的を成し遂げるための組織にはなりえない。
トップがリーダーシップを発揮して、共通目的を語り、メンバーの貢献意欲を引き出し、コミュニケーションを活性化して初めて、集団は組織に変わり、人々の行動を変容させる。
また、社会や組織の中にいる人達は、社会的地位が低かったり、経済力がなかったり、政治力がないために、他の力の強い人達の影響を受けやすい面がある。
だからこそ、規範となるべき人があるべき姿や目的を語ることで、人々の意欲を引き出し、人々の行動を変容させる。
つまり、社会に流通する価値観や規範は、そのトップのリーダーシップから生まれるものだ。

そして、昨今の環境では、SNSを使えば、簡単に周知させやすい。
人の気持ちを盛り上げて、意欲を引き出すような言動をリツイートさせることで、人々に行動を変えさせる事が以前よりも格段に簡単に、かつ、その影響力が大きくなった。
その分、この使い方も難しい。
行動経済学が考えているように、人は合理的な存在ではなく、時代や環境に依存したバイアスを持って価値判断を下し、経済効果を生み出す。
そういう考え方を利用する方法もあるだろう。

| | コメント (0)

2020/06/11

DevOpsがアジャイル開発を促進する

今となっては古い2015年の記事を読んで、もう時代は変わったのだという認識をメモ。

クラウド専業SIerは従来のSIerとどこが違うのか? 夏サミ2015 - Publickey

社内サーバゼロ、フリーアドレス、メールをやめてSlack。クラウド専業SIerが模索するクラウド時代の働き方 夏サミ2015 - Publickey

クラウド専業SIerが語る、クラウド時代のエンジニアに必要な3つのスキル 夏サミ2015 - Publickey

技術のトレンドとしては、いかに作らずに、既にあるサービスやオープンソース、クラウドを組合せてローンチできるか。
プロジェクト管理のトレンドとしては、優秀な人員の調達能力やリソース配分能力よりも、クラウドの技術やサービスを知り尽くす技術者が少人数で速くローンチできるか。

AWSサービスも少しずつ勉強しているが、毎年数多くの新サービスがどんどん出てくるので、それらを組み合わせるとどんなメリットが出てくるのか、を研究していく必要がある。
枯れた技術を優先して流用して開発するスタイルはもう古い。

オープンソースとクラウドが当たり前の時代では、開発もインフラ構築も1人の開発者が対応できるし、よりアジャイルに開発できる。
技術がプロセスや組織をどんどん変化させていく。
昔に、こうあるべきだ、という理想のプロセスや組織論は、今はもう現実になっていて、いかにそれを使うか、さらなる未来はあるのか、という思考に向かっている。

| | コメント (0)

2020/06/09

AzureクラウドデザインパターンとAWSクラウドデザインパターンのリンク

AzureクラウドデザインパターンとAWSクラウドデザインパターンのリンクがあったのでメモ。

【参考】
AWS-CloudDesignPattern

Azure-CloudDesignPattern

デザイン パターンから見た AWS と Azure | Microsoft Virtual Academy ? 専門家が提供する e ラーニング コース ? | Channel 9

クラウドごとの違いはどこにあるのか?
AWSとAzureは、本質的にどこが違うのか? どこに気をつければいいのか?
AWSは細かい部分までエンジニアがパラメータを微調整する必要があるイメージだが、Azureはどうなのか?


| | コメント (0)

2020/05/08

Ruby技術者認定試験の感想

Ruby技術者認定試験Silver・Goldに合格したので感想をメモ。
Ruby初級者なので、間違っていたら後で直す。

【参考】
Ruby技術者認定試験

Ruby技術者認定試験のGoldに受かったので感想 - 模索中

Ruby技術者認定試験(Silver && Gold)合格体験記 | Avintonジャパン株式会社

ruby gold 2.1 - Qiita

Ruby技術者認定試験のGoldに受かったので感想 - 模索中

新人プログラマがRuby技術者認定試験(Gold 2.1)に1ヶ月半以内で合格する勉強法 - IT女子ブログ

Ruby初心者だけどRuby Association Certified Ruby Programmer Silverを取得した! - suusan2号の戯れ

Ruby技術者認定試験 Goldを受験しました - ZENET Tech Blog

【1】Ruby技術者認定試験Silver・Goldは、とても良い試験だったと思う。

Rubyの文法やライブラリを一通り知っておく為に勉強せざるを得ない環境にできること、そして、初級者はSilver、中級者はGold、というように、レベルも上手く設定されているからだ。
特にGoldは、メタプログラミングの知識や経験がないと合格は難しい。
Ruby経験者、Rails経験者であっても、一夜漬けでは合格できないだろうと思う。

【2】試験対策は、Ruby技術者認定試験にあるオンラインの模擬試験を100点が取れるまで解くこと、推奨の書籍3冊を読み込むことだった。

オンラインの模擬試験はたぶん、Ruby実務経験があっても試験慣れてしていないと取りこぼすかな、と思う。
間違えた問題は、ミスした原因を分析して、理解できていないのか、分かっているのに勘違いしたのか、でふるい分けて、Webや書籍で調べて納得するまで腹落ちさせることが大事。

【3】お勧めの書籍は5冊ある。
「Ruby公式資格教科書 Ruby技術者認定試験 Silver/Gold対応」
「メタプログラミングRuby第2版」
「Rubyのしくみ Ruby Under a Microscope」
「改訂2版 Ruby逆引きハンドブック」
「Effective Ruby」

【3-1】「Ruby公式資格教科書 Ruby技術者認定試験 Silver/Gold対応」に記載の模擬試験は必ず解いておくべき。本試験でも割と同じ問題が出るときもある。

【3-2】「メタプログラミングRuby第2版」はとても良かった。
Rubyにあって、Javaにはない特徴がメタプログラミングにあると思う。
Rubyの面白さはここにあると思う。
Javaの経験に引きずられていたので、サンプルを写経してようやく、ダック・タイピングのイメージがつかめてきた。

たとえば、io.print という処理では、ioはFileオブジェクトかもしれないしIOオブジェクトかもしれないし、printはインスタンスメソッドではなくインスタンス変数かもしれない。
つまり、的確にオブジェクトを定義すれば、ポリモルフィズムが背後で上手く動作して、たった一つの表現で複数パターンの処理を実現できる。
さらに、Rubyは読みやすさを重視しているので、処理がそのまま英文であるかのように読める。
特に、内部DSLをRubyで表現する時はそうだ。

「メタプログラミングRuby第2版」の良かった点は2つある。
まず、Railsの仕組みを紹介してくれていること。

たとえば、ActiveRecord::Baseでは、インスタンスメソッドが300個以上、クラスメソッドが500個以上も含まれている巨大なクラスだ。
著者が言う通り、Javaプログラマならば、こんな設計は狂っている、スパゲティコードだ、と最初は思うだろう。
しかし、むしろRailsでは読みやすく変更しやすい設計になっているのだ。
つまり、著者の言う通り、設計技法は絶対的なものではなく、設計技法は使用言語によって変わる。

その他に、ActiveSupport::Concernは進化的設計から生まれたし、alias_method_chainは廃止されてprependが使われる設計に変わった。
つまり、最初は問題解決のためのシンプルなコードを書いて、その後、ゴーストメソッド多用に対するパフォーマンス改善やalias_method_chain多用に対するスパゲティコード対策などのために、どんどんフレームワーク設計そのものを変えていった。
すなわち、Rubyのやり方は、最初から正しい設計を行うよりも、後から機能改善やパフォーマンスを改善していく進化的設計、つまりアジャイル開発がとても向いている。
その理由は、Rubyが徹底したオブジェクト指向言語でありメタプログラミングしやすい特徴を持つので、とても柔軟性の高い言語だからだろう。

【3-3】「メタプログラミングRuby第2版」の付録「よくあるイディオム」は、Ruby初級者が暗記すべきテクニックと思う。
参照したいので、イディオムを載せておく。

O’Reilly Japan - メタプログラミングRuby 第2版

アラウンドエイリアス(Around Alias)
ブランクスレート(Blank Slate)
クラス拡張(Class Extension)
クラスインスタンス変数(Class Instance Variable)
クラスマクロ(Class Macro)
クリーンルーム(Clean Room)
コードプロセッサ(Code Processor)
コンテキスト探査機(Context Probe)
あとで評価(Deferred Evaluation)
動的ディスパッチ(Dynamic Dispatch)
動的メソッド(Dynamic Method)
動的プロキシ(Dynamic Proxy)
フラットスコープ(Flat Scope)
ゴーストメソッド(Ghost Method)
フックメソッド(Hook Method)
カーネルメソッド(Kernel Method)
遅延インスタンス変数(Lazy Instance Variable)
ミミックメソッド(Mimic Method)
モンキーパッチ(Monkeypatch)
ネームスペース(Namespace)
nilガード(Nil Guard)
オブジェクト拡張(Object Extension)
オープンクラス(Open Class)
Prependラッパー(Prepended Wrapper)
Refinements(Refinements)
Refinementsラッパー(Refinements Wrapper)
サンドボックス(Sandbox)
スコープゲート(Scope Gate)
自己yield(Self Yield)
共有スコープ(Shared Scope)
特異メソッド(Singleton Method)
コード文字列(String of Code)
SymbolのProc変換(Symbol To Proc)

メタプログラミングRubyの感想: プログラマの思索

【3-4】「改訂2版 Ruby逆引きハンドブック」は、Rubyのライブラリを一通り説明してくれているので、APIを調べたい時に便利。

特に、RubyでもJavaでも、どんなプログラミング言語でも、配列Array、連想配列Hash、文字Stringのメソッドは最低限必ず覚えておくべき。
なぜなら、配列やハッシュ、文字を自由自在に操れないと、自分がやりたいことを実現する手間が多くなりすぎて、イライラするから。
もちろん、それ以外にもファイル処理、Web操作、クラス設計なども必要。

Java経験者から見ると、RubyはArrayやHashのライブラリが非常に多いし、便利な使い方が多いように思う。
Rubyはブロックが使いやすいので、ArrayやHashの各要素に何らかの処理を一括操作したい時に、1つのメソッドで1行で書ける場合が多い。
VBやJavaならば数行もまどろっこしく書いてしまう部分が簡単に書けるのは素晴らしい。
但し、たとえば、mapとcollect、selectとfind_all、injectとreduce、findとdetectなどのように、異音同義語が多い点は注意。

「改訂2版 Ruby逆引きハンドブック」は今も愛用している。

Ruby初心者が間違いそうなこと: プログラマの思索

SmalltalkとLispから来たメソッドmap と collect、reduce と inject: プログラマの思索

【3-5】「Effective Ruby」はRubyらしい書き方の解説本。
最初はRubyらしい書き方が分からず、VBやJavaみたいな書き方になってしまっていた。
その原因は、Rubyのライブラリを幅広く深く知っていないこともあったが、Ruby独特の考え方や書き方が分かっていなかったからと思う。

僕は、下記が参考になった。

項目1 Rubyは何を真と考えているかを正確に理解しよう
項目2 オブジェクトを扱うときにはnilかもしれないということを忘れないようにしよう
項目6 Rubyが継承階層をどのように組み立てるかを頭に入れよう
項目12 さまざまな等値の違いを理解しよう
項目15 クラス変数よりもクラスインスタンス変数を使うようにしよう
項目18 要素が含まれているかどうかの処理を効率よく行うために集合を使うことを検討しよう
項目19 reduceを使ってコレクションを畳み込む方法を身に付けよう
項目24 リソースはブロックとensureで管理しよう
項目28 モジュール、クラスフックを使いこなそう
項目29 クラスフックからはsuperを呼び出そう
項目30 method_missingではなくdefine_methodを使うようにしよう
項目31 evalのさまざまなバリアントの間の違いを把握しよう
項目32 モンキーパッチの代わりとなるものを検討しよう
項目33 エイリアスチェイニングで書き換えたメソッドを呼び出そう
項目34 Procの項数の違いに対応できるようにすることを検討しよう
項目35 モジュールのprependを使うときには慎重に考えよう
項目47 ループ内ではオブジェクトリテラルを避けよう

全てのイディオムを掲載しておく。

Effective Ruby(長尾高弘 arton PeterJ.Jones)|翔泳社の本

第1章 Rubyに身体を慣らす
項目1 Rubyは何を真と考えているかを正確に理解しよう
項目2 オブジェクトを扱うときにはnilかもしれないということを忘れないようにしよう
項目3 Rubyの暗号めいたPerl風機能を避けよう
項目4 定数がミュータブルなことに注意しよう
項目5 実行時の警告に注意しよう

第2章 クラス、オブジェクト、モジュール
項目6 Rubyが継承階層をどのように組み立てるかを頭に入れよう
項目7 superのふるまいがひと通りではないことに注意しよう
項目8 サブクラスを初期化するときにはsuperを呼び出そう
項目9 Rubyの最悪に紛らわしい構文に注意しよう
項目10 構造化データの表現にはHashではなくStructを使おう
項目11 モジュールにコードをネストして名前空間を作ろう
項目12 さまざまな等値の違いを理解しよう
項目13 ""<=>""とComparableモジュールで比較を実装しよう
項目14 protectedメソッドを使ってプライベートな状態を共有しよう
項目15 クラス変数よりもクラスインスタンス変数を使うようにしよう

第3章 コレクション
項目16 コレクションを書き換える前に引数として渡すコレクションのコピーを作っておこう
項目17 nil、スカラーオブジェクトを配列に変換するには、Arrayメソッドを使おう
項目18 要素が含まれているかどうかの処理を効率よく行うために集合を使うことを検討しよう
項目19 reduceを使ってコレクションを畳み込む方法を身に付けよう
項目20 ハッシュのデフォルト値を利用することを検討しよう
項目21 コレクションクラスからの継承よりも委譲を使うようにしよう。

第4章 例外
項目22 raiseにはただの文字列ではなくカスタム例外を渡そう
項目23 できる限りもっとも対象の狭い例外を処理するようにしよう
項目24 リソースはブロックとensureで管理しよう
項目25 ensure節は最後まで実行して抜けるように作ろう
項目26 retryでは回数の上限を設け、頻度を変化させ、オーディットトレイルを残そう
項目27 スコープから飛び出したいときにはraiseではなくthrowを使おう

第5章 メタプログラミング
項目28 モジュール、クラスフックを使いこなそう
項目29 クラスフックからはsuperを呼び出そう
項目30 method_missingではなくdefine_methodを使うようにしよう
項目31 evalのさまざまなバリアントの間の違いを把握しよう
項目32 モンキーパッチの代わりとなるものを検討しよう
項目33 エイリアスチェイニングで書き換えたメソッドを呼び出そう
項目34 Procの項数の違いに対応できるようにすることを検討しよう
項目35 モジュールのprependを使うときには慎重に考えよう

第6章 テスト
項目36 MiniTest単体テストに慣れよう
項目37 MiniTest仕様テストに慣れよう
項目38 モックオブジェクトで決定論をシミュレートしよう
項目39 効果的なテストを追求しよう

第7章 ツールとライブラリ
項目40 Rubyドキュメントの扱い方を覚えよう
項目41 irbの高度な機能を使えるようになろう
項目42 Bundlerでgemの依存関係を管理しよう
項目43 依存gemのバージョンの上限を指定しよう

第8章 メモリ管理とパフォーマンス
項目44 Rubyのガベージコレクタの動作に慣れよう
項目45 Finalizerでリソースリークを防ぐセーフティネットを作ろう
項目46 Rubyプロファイリングツールを使おう
項目47 ループ内ではオブジェクトリテラルを避けよう
項目48 コストの高い計算をメモ化することを検討しよう

Effective Rubyを読んだので感想を書いてく - WEB SALADの記事も参考になる。

【3-6】「Rubyのしくみ Ruby Under a Microscope」はRubyのインタプリタYARVの仕組みを解説しているディープな本。
普通はこの本のレベルまで理解する必要はないと思うけれど、僕はRubyの定数探索のアルゴリズムと特異メソッドがどうしても腹落ちできなかったが、この本で何となくイメージできた。

たとえば、Rubyのメソッド探索は継承チェーン上に1本でたどる一方、定数探索は最初にレキシカルスコープで検索してから次に継承チェーンをたどる。
よって、定数検索の方がやや複雑だし、ソースを上から読み込むので、そんな挙動になるのかという発見もあった。

たとえば、Rubyのオブジェクトの特異メソッドやクラス本体のクラスメソッドは、特異クラスという別のクラスに存在する。
よって、特異メソッドやクラスメソッドが存在する場所は別のクラス、特異クラスにあるので、特異クラス系列の継承ツリーが別途存在する。

なお、「メタプログラミングRuby第2版」にも特異クラスの絵が掲載されていて詳しく説明してくれているのだが、通常のクラス系列の継承ツリーと、特異クラス系列の継承ツリーを混ぜ込んだ絵で記載しているので、僕には分かりづらかった。
一方、「Rubyのしくみ Ruby Under a Microscope」では、メモリ上にRubyのオブジェクトがどのように配置されるのか、絵が書かれているので、僕には理解しやすかった。

結局、プログラミング言語を理解するには、メモリ上に変数やオブジェクト、配列、ハッシュがどのように配置されるのか、を自分の頭でイメージできなければならないから。

下記の章がお勧めと思う。
Rubyがメモリ上にどのように展開してくれているのかをイメージしやすくなる。

第5章 オブジェクトとクラス
第6章 メソッド探索と定数探索
第8章 Lisp から借用したアイデア
第9章 メタプログラミング

Rubyの定数のお話 | media.growth-and.com

Rubyの定数探索の個人的な謎に迫る - Qiita

「Rubyのしくみ」を読んだ後のRubyの感想: プログラマの思索

【4】Rubyを実際に実務に使う場合は、事実上、Railsをマスターすべきだと思うので、Redmineのソース解読もしながらちょっとずつやっている。

Javaや.NETのWebシステムの開発経験からRailsを見ると、Web開発でまどろっこしい共通処理やWeb特有の処理をRubyのメタプログラミングで上手く隠蔽して、コーディングルールを強制することで数行で書けるようにしている部分はすごいな、と改めて思う。

僕がRailsですごいなと思う点は、特に、JavaScriptとの相性が良い点だ。
Railsが生まれた当初から、prototype.jsやJQueryとの連携はスムーズだったし、JavaScriptを駆使することでWebのUIを豊かにしてくれた。
最近のRailsは、JSライブラリの発展とともに、VueやReactとも親和性が高い。
つまり、クライアントサイドのUI改善も取り込めるので、JavaやPHPなどの他の言語よりもRailsの優位性は高いような気がする。

【5】Rubyを勉強している時の僕の脳みそは、錆びついた機械時計に油を挿しながら、回転させようとしている感覚だった。
こういうことをRubyで実現したいんだ、要件や設計は分かっているのになぜすぐに書けないのか、という苛立ちを感じながらRubyのライブラリを覚えて、動きに慣れようとしていた。

「プログラミングのできる羊とできない山羊を区別する方法」の記事のリンク: プログラマの思索にある「プログラミングができない羊」みたいな地点から登っている感じだった。

でも、初めてのプログラミング言語を習得するには、どんな手順を踏めば良いのか、どういう点に注意すれば習得速度を上げられるか、という感覚はつかめてきた。
今は次のプログラミング言語としてPythonを習得しようとしているが、Rubyの習得経験や、RubyとPythonは考え方が似ているメリットもあって、割と楽に習得できそうな感じ。

結局、プログラミング言語が分かったという感覚になるには、自分の脳みそがコンパイラになりきって、メモリ上に変数やクラスがどのようにロードされて値が変わっていくのか、イメージできる必要がある。

こんな経験は誰でも知っているのだろうが、20代の若い年齢なら簡単であっても、40・50代と年齢を取るごとに、新しいプログラミング言語の習得はどんどん難しくなる。
しかも、プログラミング言語の隆盛は10年おきに移り変わるから、そのたびに以前の言語を捨てながら新しい言語に慣れていかないといけない。
たとえば、FortranやCobolからC/C++/VB、そしてJavaやC#、さらにRubyやPHP、そしてPythonやR、へどんどん変わってきている。
JavaもKotlinで書くのが普通になってきているようだし。

そんな事を考えると、アジャイル開発は常識だ: プログラマの思索にも書いた通りだったのを思い出す。

(引用開始)
ソフトウェア業界の特徴の一つは、一度高い能力が得られてもそれを完全にやり直さねばならない点がある。
Cobolで一流であったとしても、JavaやC#のプログラミングは一流とは限らない。むしろ、オブジェクト指向の概念を知らない可能性も高く、オブジェクト指向の初心者かもしれない。
Javaを知っていても、RubyやiPhoneやAndroidアプリは初心者かもしれない。
様々な言語を学び、共通部分があったとしても、技術の変化によって常に立場は悪くなり、完全に分かったという状態にはならない。
また一から勉強して成長しなければならない。
(引用終了)

最終的には何かアプリが作れればいいな、と思っている。

| | コメント (0)

2020/04/30

PyCharmやVSCodeでjupyter notebookを使用する方法

Pythonの開発環境では、Pycharmが使いやすい。
デバッグやリファクタリング、色やキー操作の細かな設定が優れている。

しかし、PycharmのCommunity版では、ipynbファイルは素のJsonファイルで表示されてしまって使いにくい。
調べてみたら、下記のやり方で、Pycharmからjupyter notebookを起動してブラウザ上で表示できるようになる。

PyCharmでjupyter notebookを使用する方法(Windows10) - Qiita

一方、VSCodeでjupyter notebookを使用するには、Pythonエクステンションを入れるだけ。
ブラウザ上のでjupyter notebookではなく、VSCode上でipynbファイルが自動変換されて表示されるので便利。

VS Code でPython,Jupyter を動かす - Qiita

jupyter notebookを使いたい場合、PycharmCommunityよりもVSCodeが手に馴染んでいい感じ。

| | コメント (0)

2020/04/29

「ゼロから作るDeep Learning」を読み始める

「ゼロから作るDeep Learning」を読み始めた。
一気に7章まで読んだ。
理論とPythonの実コードを行ったり来たりする説明がとても素晴らしい。
思いつきをメモ。

【参考】
ゼロから作るDeep Learningのメモまとめ - Qiita

ゼロから作るDeep Learningで素人がつまずいたことメモ: まとめ - Qiita

以前から、機械学習やら深層学習に関する本は斜め読みで乱読してきた。
また、統計検定やQC検定の資格勉強を通じて、実際に使う統計理論と、メーカーによる品質管理の事例のイメージは分かっていた。
だから、理論の部分はだいたいイメージできていた。
でも肝心のソースが今まで分からなかったので、ブラックボックスみたいなイメージだった。

PythonもNumpy・Pandas・MatPlotlibもある程度慣れたおかげで、Pythonのソースコードを読みながら、なるほど、こんなアルゴリズムで作っているのか、割とベタベタにプログラムを書いているんだな、とか、色々気づきがあった。
Githubのソースコードを実際に動かした後で、本の文章の行間に書かれている内容を想像するのが楽しい。

oreilly-japan/deep-learning-from-scratch: 『ゼロから作る Deep Learning』(O'Reilly Japan, 2016)

Githubのソースを動かす時は、下記を参考にした。

Jenga 妄想の大気開放  オライリーの『ゼロから作るDeep Learning」でMNISTデータセットが読み込み出来ない件(Windows10上で動作するeclipseにて)

まだまだ分かってないけれど、いくつか気づきはある。

0か1を返す関数の引数にNumpyデータを渡した時、そのままでは計算できないが、Numpyのトリックを当てはめて解決する。つまり、np.arrayの要素に不等号演算を渡し、np.int型を返すようにする。
この部分は上手いなと思った。

パーセプトロンの合成は行列の積と同値なので、Numpyライブラリが有効に使える。
よって、行列の成分が膨大な個数であっても演算の個数自体はそれほど増えるわけではない。

実際のPythonの計算式では、かなり大きな数同士で四則演算する場合にオーバーフローの問題が出やすいとか
無限大に近い数値が出てしまう時がある。
そこで、あるMax値を付与したり、微小値を式に付与したりする場合がある。

ディープラーニングのような学習プログラムは、学習効率をいかに上げるか、という観点で損失関数をバロメーターにしてその精度を評価する。
これは丁度、小中高校生の学習でも、少ない学習時間でいかに暗記できたり、理解できるか、という観点にもつながる。
つまり、コンピュータの学習も人間の学習も、そのアルゴリズムは同じように思える。
多分そのように思える理由は、深層学習がそもそも人間の脳をパーセプトロンで表現してコンピュータ上でシミュレーションできるようにしたのだから、トートロジーなのかもしれない。

教師あり学習は、今のようなビッグデータと言われる時代では、非常に有効なのだろう。
SaaSで自動的に収集できるログデータ、電気自動車や家電製品から集まるデータなど、現代ではビジネスの副産物としていくらでもデータを集められるので、そのデータを使えば、いくらでも機械学習や深層学習エンジンに食わせることはできる。

強化学習の考え方を深層学習エンジンで実装するアイデアは面白いと思った。
強化学習はエージェントに報酬を与えることで、試行錯誤させながら学習させて賢くさせる。

この考え方は、組織人事理論にある「期待理論」の考え方に似ている。
期待理論では、動機付けの強さは「報酬への期待x報酬への魅力」「期待x誘意性」で決まると考える。
よって、期待理論を実際の組織に当てはめた場合、利益分配制度のような変動給与制、業績連動制度、成果主義人事制度を構築することで、社員の動機を誘発し、誘導させる。
なお、昨今の人事制度構築でも期待理論は非常に有効な考え方と言われている。

つまり、強化学習の考え方は、従来の組織人事理論の期待理論の考え方を適用し、実際にPythonプログラムで実装したに過ぎないように思える。
この考え方を発展させれば、機械学習や深層学習の学習効率を上げたいと研究したいならば、組織人事の理論を片っ端からPythonで実装して、比較すればいいだろう。

もう少し理解できたらまとめてみる。


| | コメント (0)

2020/04/24

教育における読み書きというアナログの重要性の記事のリンク

教育における読み書きというアナログの重要性の記事をリンク。
オンライン教育に関する主張のないラフなメモ書き。

【参考】
「ノートが取れない」中学生。日本の子どもたちの読解力はなぜ落ちたのか。新井紀子さんインタビュー | Business Insider Japan

読解力不足をどうとらえるか~新井紀子さんの答えをまとめる~: 風にふかれて

一人に一台、タブレットPCを配りますか?(その2) | ICT for Development .JP

オンライン授業でもアナログ感あるデザインで「考えること」を促す|Yoshikazu TATENO | たってー|note

【1】2020年4月時点では、日本の小中高学校はほとんどが休校状態なので、ほとんどの子供は勉強すらしていないだろう。
自ら目標を立てて、自ら題材を探して知識やスキルを身に着けていく、という作業は、大人でも難しいのだから、ましてや普通の子供ができるようには思えない。
そもそも、それができる子供であれば、学校という仕組みがなくても、自立していけるだろう。
とはいえ、昨今ではそういう能力が早い段階から期待されているけれど。

しかも、学校だけでなく対面の学習塾も閉まっているので、オフラインで先生から教えを請うこともできない。
公立図書館、大規模書店も閉まっているので、紙の書籍すら手に入らない。
結局、オンライン教育に頼るしかないけれど、色んな理由でおそらく日本の環境では敷居が高いのだろうと思う。
PCやWifi環境というIT基盤だけでなく、子供の適正に見合った教育方法とか、色々試行錯誤する問題があるだろうと推測する。

響いた言葉を引用しておく。

【2】「読む」「書く」はプログラミング同様に不自然な行為
(引用開始)
4 新井さんの著書を読むと、むしろ読解力を上げるには、板書をするなど「書く」行為をさせること、つまり「昭和的」な教育の方が効果が上がった実例が書かれています。ICT教育を進めて、読解力が上がるとは思えないのですが、どうでしょうか?

①「書く」行為は、そもそも人間にとって不自然な動作であると認識してほしい。「読む」「書く」はプログラミング同様に不自然な行為ですから、その時代と環境と要請に従って、カリキュラムを構築して確実に身に付けなければならない。
②けれども、私たち大人は、自分が子供だった時代に、読み書きを「自然に」身に付けた思い込んでいます。ですから、自分たちの子供の世代も、放っておけば、「それくらい」はできるだろうと信じています。でも、自転車もただ乗れるようになるわけではないのと同じように、字を書くというのは相当に集中力とトレーニングが必要なのです。
(引用終了)

「「読む」「書く」はプログラミング同様に不自然な行為」という指摘は同意する。
学習や勉強は割とアナログ作業が多い、という気はしていたから。
だから、アナログ作業であるがゆえに、それに適した訓練は必要だろう。

ただし、学習は割とアナログ作業が多いという現状は2つの側面があると考える。
学習という作業は、読む・聞く・書く・話す、など五感を使った動作が多いので、身体で覚えるべき部分が多いという点。
一方、日本では高校入試や大学入試がペーパーテストなので、問題を読んで答案に書く、という試験そのものに対応した技術が必要である、という点。

読む・聞く・書く・話すを使った学習を訓練する時、前者と後者のどちらに比重をおく方が効果的なのか、という疑問はある。
個人的には、後者のペーパーテストの為の訓練は不要と思うが、結果的にそれに適合しすぎた人達を生んでいる事象も多いのだろう。

また、プログラミングも不自然な行為、という指摘は同様に思う。
新しいプログラミング言語を覚えて習得していく時、今までとは違った頭の使い方を要求させられる。
AWSやアジャイル開発など新しい技術を習得していく時も同様。

周囲を見ていても、プログラミングの習得が早い人とそうでない人には、雲泥の差があると実感する。
「プログラミングのできる羊とできない山羊を区別する方法」の記事のリンク: プログラマの思索の通り、プログラミング能力は、読み書き以上に、その人の向き不向きが現れやすいのかな、と思う。
プログラマの能力や生産性は10~100倍以上の差が出る、という点は、そういう所に原因があるのかもしれない。

【3】タブレット教育、アクティブ・ラーニングは高度な能力を必要とする

(引用開始)
6 一人一台タブレット政策。小学校からのタブレット導入については、どうでしょうか。

①これは、もう終わりだな、と。特に小学生は絶対タブレットは良くないと私は確信しています。
②先進的に導入した私立学校や家庭で既に弊害が出ています。小学校からタブレットドリルで学ぶと、紙や長文にはもう戻れないのです。意外なことですけど、検索すら自分ではできない生徒が出てくる。学びが常に“消費的”になるのでしょう。けれども、大学や社会で求められる学びは“生産的”な学びなので、タブレットドリルで育った子は立ち直れないほど挫折してしまう。
③タブレット導入で今まで7時間かかっていた授業が2時間で終わり、残りは深く考える授業に当てるというような授業は、麹町中学校のようなある意味「特殊な環境」の学校だけでできることだと思います。それが本当に地方でもできるのかも検証せずに、タブレットという言葉が一人歩きしています。
④しかもローマ字入力ができるのは、小学校5,6年生なので、それまでキーボードは使えません。その間、一体何をやるのでしょう。
(引用終了)

(引用開始)
②日本の公教育以外で格差をなくす平和的な方法はないと思っています。
ちなみに、アクティブ・ラーニングは格差を広げてしまいます。それは戦後最初のアメリカ主導の学習指導要領である、ディーイ式の「生活単元学習」の失敗で明らかになっています。
③小学生のうちは比較的ワイワイやっていますが、中学生になると、出来る子が言ったことに他の子は追随します。だから、授業を全てディスカッションでやることは、現場を見ていない人の寝言に過ぎない。
(引用終了)

昨今流行しているタブレット教育、アクティブ・ラーニング教育を批判する理由が参考になる。
著者の方はおそらく、現場経験が豊富で、数多くの失敗事例も見ているのだろう。

現状では感染症の流行が終わらない限り、オフライン教育は無理でオンライン教育にシフトせざるを得ないだろう。
しかし、そういう指摘の元で、今後のオンライン教育を考えると、子供の成熟度に見合ったオンライン教育の方法を見つけないと、教育を受けられなかった世代や就職できなかった世代を大量に生み出してしまう事になる。
今後、試行錯誤しながらオンライン教育の可能性を探っているしかないのだろう。

残念なことに、日本では、教育現場が最もIT技術が遅れた場所であり、知識だけでなく環境も揃っていないので、数多くのハードルが高いのかもしれない。

【3】オンライン教育の手法は、実は、以前からMOOCなど反転教育の概念で知られていた。
具体的には、自宅でオンラインで講義を受けた後、学校で対面で先生に質疑応答して疑問点を解決していく、というやり方。

サルマン・カーン「ビデオによる教育の再発明」 - YouTube

『世界はひとつの教室』技術、教育、そして世界は動く - HONZ

教育学は人工知能の研究者によるデータ主導で置き換えられつつある: プログラマの思索

知的誠実さの大切さ~Moodleが持つ教育のイノベーションの可能性: プログラマの思索

サルマン・カーンのYoutubeの説明を見た時に、講義の動画配信、子どもたちのテスト結果の採点・集計・分析・フィードバック・理解度確認などのシステム基盤などITを駆使しながらも、「技術を使って、本来の教育をヒューマナイズする(humaizeする)」という彼の言葉がすごく引っかかった。
IT技術を使うことで人的関係を効率化させて、人的介入を減らすのではなく、逆に、コミュニケーションや対面のやり取りの密度や濃度を上げていくのだ、という意見が半常識的に感じたからだ。

おそらく、こういう取り組みも現場で試行錯誤しながら、時間をかけてあるべき姿を探っていくしかないのだろう。

| | コメント (0)

2020/04/23

MLOps(機械学習基盤)のリンク

MLOps(機械学習基盤)の記事が面白かったのでメモ。

【参考】
機械学習システムの設計パターンを公開します。 - Mercari Engineering Blog

mercari/ml-system-design-pattern: System design patterns for machine learning

ゆるふわMLOps入門 - Re:ゼロから始めるML生活

機械学習システムにおける「技術的負債」とその回避策 - Qiita

“Hidden Technical Debt in Machine Learning Systems”

記事を読んで理解したことは、機械学習はアルゴリズムが重要なだけではなく、そのシステムを支える開発基盤の構築に膨大な工数がかかること。
データ収集・分析だけでなく、データや分析結果の構成管理、サーバー・システム監視なども含まれるので、開発もインフラ基盤も両方とも詳しくないと、システムの全体像を把握することすら難しいだろう。
一昔前の業務システム開発よりも、はるかに難易度は高いと思う。

ゆるふわMLOps入門 - Re:ゼロから始めるML生活に紹介されている先進企業の事例が参考になる。
Google、Facebook、Netflix、Airbnb、Uber くらいの大企業であれば、自前で構築して、その基盤を他企業や一般利用者にも使わせることで、サブスクリプションサービスによる売上、エコシステムの拡大を狙っているわけだ。
この辺りの技術も探してみる。


| | コメント (0)

2020/03/01

AWSクラウドデザインパターンの感想~RDP(Redmine Design Pattarn)の構想

「AWSクラウドデザインパターン」を読み直した。
以下、AWS初心者によるラフなメモ書き。

【参考】
AWS-CloudDesignPattern

【1】「AWSクラウドデザインパターン」本を買ったのは、2013年のデブサミの時だった。
玉川さんにサインを書いてもらった。
「Work hard, Have fun, Make history!」と。

あの頃はまだCDP(クラウドデザインパターン)理解しきれてなかった。
AWSに触れて、ようやくCDPの威力を理解することはできた。
ただし、CDPに記載されたAWSサービスは2012年頃の内容なので、Lambdaなどが含まれていないから、そういう最新のサービスで置き換えられる部分はいくつかある。

振り返ると、2010年代前半にCDP本が出たからこそ、AWSが日本に普及し始めたのだと思う。
CDPは、システムのアーキテクチャ設計、インフラ設計において、AWSのサービスや機能をどの場面で適用するとどんな効果が得られるのか、を明確に示唆してくれる。
クラウドによる設計や実装を試行錯誤していた頃に、CDPを用いることで、より良いクラウドによるアーキテクチャ設計が実現可能になったためだ。
また、アーキテクト同士で、クラウドによるアーキテクチャ設計について、共通の言葉を使って議論できるようになった。
そういうメリットがCDPにはあった。

CDPの形式はGOFのデザインパターンに似ている。
CDPの形式はもっとシンプルだ。
解決したい課題、クラウドでの解決、AWSによる実装、利点、注意点、その他の関連パターン、という項目で必要最低限に絞り込まれている。
CDPというカタログを読んでいくと、どのユースケースでは、どんなパターンを用いるとどんな利点があるのか、クラウドでの解決方針に沿ってAWSはどんなサービスや機能を提供してくれているのか、が理解しやすくなる。
実際に、オンプレのインフラ構築や運用で苦しんできた経験のある人ほど、AWSによる実装方法で、なるほど、と気づく場面が多いはずだ。

イントロの部分もすごく惹かれた。
AWS普及に心血を注ぐ3人が、ある居酒屋にて、クラウドを語る上で共通言語となるデザインパンターンのようなものが必要である、という議論が白熱し、その場で40種類以上のクラウドデザインパターン(CDP)の種をノートに書き出した、とある。
この文に触れて、クラウドの導入でつまずいているプロジェクトがあって苦労したり、オンプレの設計思想に囚われすぎてAWSの良さを活用しきれていない場面で歯ぎしりしたりしたのではないか、と勝手に想像した。
そういう経験を元に、CDPが生み出されたのだろう。

【2】そんなことを考えているうちに、Redmineデザインパターン(RDP)みたいなものが作れないだろうか、と想像したりした。
Redmineの導入・運用も既に10年以上の蓄積があり、必要な運用ノウハウはネット上にたくさん語られているし、運用で必要なロール(組織上の役割)もいくつか語られている。
しかし、そういうノウハウはバラバラに散らばっているに過ぎない。
それらを一つの体系として、暗黙知となっているものを形式知化することには意義があるはず。
なぜなら、まだ困っている人も多いだろうし、経験者が議論する時の共通言語はまだ暗黙知になっている部分が多いからだ。

僕も以前、チケット駆動開発のパターン集みたいなものを編み出そうと考えていた。
そのパターンの根底は、アジャイル開発にチケット駆動開発を適用するにはどんな考え方が必要なのか、があった。
でも、それから5年以上たち、今は情報システム部門の人達が一般ユーザに使ってもらう運用基盤に変化したので、異なるパターン集が必要になっていると思う。

今僕のアイデアとしては、パターンに4つほどのレイヤで階層化して詳細化できないか、と考えている。
イメージは、ユースケース層>マネジメント・ロール層>アプリ・機能層>ソース・実装層。
たとえば、ユースケース層では、課題管理・ソフトウェア開発・サポートデスクなどの実際の利用シーンでカテゴライズする。
マネジメント・ロール層では、Redmine職人・Redmineエバンジェリスト・Redmine警察のようなロール、PMxTMマトリクスのような組織への導入方法。
アプリ・機能層では、Redmineの各機能のベストプラクティス。たとえば、チケットのワークフロー、JAXAが生み出したカスタムフィールドやプロジェクトのOR・AND条件など。
ソース・実装層では、ViewCustomizeプラグインによる課題解決、プラグインやカスタマイズによる課題解決など。

このようにパターンをレイヤ化して区別することで、パターンの粒度を区別できること、初心者や経験者が会話できる共通言語を提供できること、というメリットがあると思う。
僕が以前考えていたパターンはアジャイル開発への適用に特化しすぎていたので、2020年現在の実情に合わせたデザインパターンを作れたらいいなあ、と考えた。


| | コメント (0)

より以前の記事一覧