ソフトウェア

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)

2020/02/01

技術力を持ったリーダーが不可欠な時代について

kawagutiさんのBlogの記事を読んで、すごく良い記事と思ったのでリンクしておく。
ラフなメモ。

【参考】
3月にDavid Bernstein さんの 認定スクラムデベロッパー研修を行います - kawaguti’s diary

(引用開始)
開発技術を学ぶ機会の少ない日本
スクラムはやってみたけど、継続してプロダクトのリリースができていない。最初は良かったけどコードベースが大きくなって遅くなってきた。
おそらく課題は開発技術にあります。スクラムをやったとしても、開発技術を学ぶことができていなければ、高速にゴミをす生み出してしまいかねません。開発チームは継続してソースコードをメンテナンスできるように、技を磨き、アーキテクチャを手直ししていく必要があります。
実際に長く日本のソフトウェア業界にいる人間からみると、ソフトウェア開発技術自体を学ぶ機会が少ないと感じます。
プロジェクトマネジメントや、製品企画については学ぶ機会がだいぶ増えてきたのですが、一方で足元の開発技術は、ツールの紹介ばかりで、本質を学ぶ機会があまりありません。
昨年、アジャイル開発に携わる大小いくつかの北米の企業を訪問してきましたが、どの企業も技術や、技術の伝承、学ぶ時間をとることを重視していました。
(中略)
米Microsoft に行かれた牛尾剛さんから聞いて驚いたのは、いま北米・欧州の企業では、マネジメント層も多くがソフトウェア開発の本質を理解している、ということです。
「はげちゃびんがいない」という刺激的な言葉を使っていますが、実際に牛尾さん自身も自分がはげちゃびんであると感じて渡米したそうです。
私たち日本人は、もっともっと技術力を高める投資を、やっていく必要があるのだと強く感じました。
(引用終了)

はげちゃびんとは「はげた頭を茶瓶に見たてたこと」。
つまり、40~50代の禿げたおっさんで最新のソフトウェア開発技術を理解していないおじさんのことを皮肉っぽく指しているのだろう。

デジタルフォーメーションなるバズワードが最近流行っているが、その言葉は多分、一般企業の経営者もソフトウェア開発の本質を知るべきなのに知っていないでしょ、という裏のニュアンスも含まれているように思える。


| | コメント (0)

2019/06/25

ディープラーニングと知能の本質は「画像」ではないかという記事のリンク

ディープラーニングと知能の本質は「画像」ではないか、という記事がとても面白かったのでリンクしておく。

【参考】
いつでもLOUPE:「黒魔術とディープラーニング―科学からの卒業」

ディープラーニングと知能の本質は「画像」なのか?|人工知能はどのようにして「名人」を超えるのか?|山本一成|cakes(ケイクス)

人工知能は生命と同じく「目」を手に入れ、爆発的に進化する――AI研究の第一人者・松尾教授が語る企業と消費者のコミュニケーション変革 - ITmedia NEWS

【感想】
人が情報を入出力するモノは、言葉・音・画像の3つ。
ディープラーニングは画像認識が得意なので、言葉・音も画像データに変換できれば、人が認識できる情報は全てディープラーニングで一括処理できる。
そして、その方が言葉・音の解析の精度も高くなる、というストーリー。

「AI(ディープラーニング)が人間の手を借りず、画像や映像に写っているものを認識できるようになる」。
すると、画像認識こそが知能の本質ではないか、という仮説が成り立つ。

では、なぜ、画像認識が知能と密接に関係するのか?
実は、生物進化の歴史の大事件である「カンブリア紀の大爆発」の事象と似ているのではないか、という上記の記事の指摘が非常に面白かった。

アンドリュー・パーカー氏の「眼の誕生」は僕も以前一度読んだことがある。
読んだ時は、たかが眼球という一つの機能がそれほど重要なモノとは思えなかったので、あまり感動がなかった。

「眼の誕生」;アンドリュー・パーカー著 読書感想 - 不確定な世界

しかし、ディープラーニングが画像認識に非常に強く、自ら特徴量を抽出して学習していける仕組みを持っていることを考えると、カンブリア紀に眼の誕生が生物進化に大きな影響をもたらした事件と非常に似ているように思える。
たかが画像認識と思っていたけれど、言葉も音声も画像データに一度変換できるならば、全てディープラーニングの対象となり、認識の精度を上げることができる。

一方、人間の脳みそは、言葉や数字などの抽象的機能をつかさどる左脳、画像などの直感的な機能をつかさどる右脳を持つ。
絵描きの能力が高い人は右脳が優れている、という本「脳の右側で描け」を読んだことがあったけれど、実は、右脳の解明がAIやディープラーニングの研究と密接に絡んでいるのかも、という妄想も持った。

【脳の右側で描け】を実践!! デッサンが上手くなる2つのコツ - PETART

脳の右側で描け ? らくがきエルゴノミックス

| | コメント (0)

より以前の記事一覧