ツナワタリマイライフ

日常ネタから技術ネタ、音楽ネタまで何でも書きます。

javascriptでファイルリストに書かれているファイルを動的に読み込む

はじめに

音楽を作っているソロプロジェクトのHPを作っています。

とけてなくなる

AWSのS3上において、https対応、circleCIで自動アップロード対応等やりました。

  • レガシーな静的webサイトを一新!軽量cssフレームワークSkelton導入
  • レガシーな静的Webサイトを一新!その② 独自ドメインを使ってAWS S3に静的Webサイト公開
  • レガシーな静的Webサイトを一新!その③ CircleCIとGithub連携でDevOps!
  • レガシーな静的Webサイトを一新!その④ AWS CloudFrontとCertificate Managerでhttps対応する
  • レガシーな静的Webサイトを一新!その⑤ httpsサイトで承認されてないscriptの警告が出てしまう
  • なお、私は本業サーバサイドなのでhtml/javascriptの知識は皆無であり、本質的な解決方法ではないことも、ナンセンスなこともたくさんしているかと思いますが、趣味のHPでなんとかやりたいことをやるために奮闘した記録となっていますので温かい目で見守ってください。

    informationの更新問題

    更新情報を記載するinformationですが私の要望は以下。

    • 更新日ごとにinfo/170101(日付).htmlを追加する
    • index.htmlからinfoフォルダ以下のディレクトリを自動で読み込んで表示する
    • index.htmlでは最新3記事のみ表示する
    • read moreのlinkから全部のinformationをinfoフォルダ以下のディレクトリから自動で読みこんで表示する

    これをやる前の状況は

    • loadするファイルパスがベタ書き
    • 表示部分も記事の分だけベタ書き

    となっており、更新をするたびにindex.htmlに追記するという地獄のような状況になってました。記事数が3,4のうちはいいにしても、早めに対策を打たないといけない。

    こういうことは一気にしてはいけないので、1つずつゆっくり問題を解決していきました。

    記事の読み込みと表示をloopとinnerHTMLを使う

    まずベタ書きの部分をせめて繰り返し可能にします。

    rails(ruby)でいうところのerbみたいにhtmlで書きたかったわけです。これはjqueryのloopを使いました。

    load infomation iterative · takeshe12/toketenakunaru@61fe64f · GitHub

    jqueryで外部htmlファイルをloadする部分

    var num = ["161203","161204","161231","170110","170122","170125"];
    jQuery.each(num,function() {
      var path = 'info/'+ this + '.html';
      $("#" + this).load(path);
    });
    

    表示部分はinnerHTMLを使いました。

    var hoge = ""
    var id = ["170125","170122","170110","161231","161204","161203"];
    $.each(id,function(i,value){
      hoge += "<section class='sec'><div id=\'" + value + "\'</div></section>";
    });
    var elem = document.getElementById("infomation");
    elem.innerHTML = hoge
    

    $(“#” + 170101).load(info/170101)とloadしたら、

    でloadした部分が表示されます。

    今回はinnerHTMLを使ってinformationというidがついた部分にtagを打ち込んでいます。

    昔はdocument.writeというものもあったみたいですが、HTML5では非推奨だそう。

    innerHTMLで注意すべき店はタグ内の要素はシングルクォートでくくらないといけないってことですね。タグ自体をダブルクォートでくくっているので。ところでこのコード閉じカッコがないな。。。なんで動いたんだ。

    参考

    HTML要素の中身を変えるinnerHTML | JavaScript入門編

    filelistが書かれている別ファイルからloadするpathを読み込む

    loadだpathだややこしい説明になってすみません。

    今回やりたかった、infoフォルダ以下の内容を動的に読み込むって、そもそもwebサーバ内のフォルダを除く行為なわけで、クライアントで動くjavascriptでできるわけもないんですね。

    代替案として以下のようなfilelistを用意します。

    • info/filelist
    170101
    170103
    170121

    javascriptでこのファイルを改行で区切って読み込み、配列として取得。あとはその配列を上の例でloopして表示とloadを行います。

    load file list from external file · takeshe12/toketenakunaru@a7053eb · GitHub

    ファイルリストを出すためにゴミシェルも書きました。

    // get early 3 file from info file list.
    var arr = [];
    $.ajax({
      url: 'infolist',
      async:false, //wait to finish ajax connection
      success: function(data){
        arr = data.split(/\r\n|\r|\n/);
        arr.pop(); //delete end value
        var infotag = ""
        $.each(arr,function(i,value){
          infotag += "<section class='sec'><div id=\'" + value + "\'></div></section>";
        });
        var elem = document.getElementById("infomation");
        elem.innerHTML = infotag
      }
    

    ここで謎にajaxを使っています。ちなみにajaxのことは何も知りません。(笑)

    確か非同期通信を実現するためのjavascriptを使った実装の1つ、ですかね。

    今回localhostのfilelistを取得して、取得に成功したら(success)、そのdataを改行でsplitし、arrayに代入。そのあとその値をtagに打ち込んでinnerHTMLとして更新しています。

    ajaxのキモが非同期なわけですが、ここではあえてasync falseとして同期処理としています。同期処理の場合、まだレスポンスが返ってきていないのでタグ生成時にはvalueがundefinedとなってしまいました。そのためasync falseとすることで解決しましたが、良いやりかたではない気もします。

    ちなみにここのarr変数はグローバル変数にしているのでpathをloadするほうでもそのまま使えました。javascriptの変数スコープについては以前勉強したので知っていて、むやみにグローバル変数にするのはよくないのは知っていますが今回はこのまま。

    read moreですべてのinformationを表示

    もっと良いやり方があるとは思ってますが、今回はinformaton.htmlを別ページを作成し、このページ用に全informationのfilelistを作成し、同じ方法で実現しました。全部読み込んでおいて、最初は3つだけ表示、linkをクリックしたら残りも表示、とjavascriptを使えばできるとは思いますが、まずは実現ということで今回は雑な方法で。重複コードができてしまうのでメンテナンス性はさがることからいずれ対処したいです。

    circleCIでfilelist生成を自動化

    さて、今回はfilelistにしたがってinformationを読み込んでいますが、そのfilelistの生成はシェルスクリプトであり、情報を追加するたびにこのシェルを叩いてから、ファイルリストを含めてコミットする必要があります。このひと手間はイケてない。

    exec getfile.sh · takeshe12/toketenakunaru@36a21d0 · GitHub

    circleCIでのbuildの前にこのシェルを叩かせればいいんじゃない?と安易に実行したところ、できました。まぁ、できるよね。gitからcheckoutして、シェル叩いて、それをS3と同期してるわけなので。

    このブログを書くに伴ってゴミシェルをちょっと書き直しました。

    結果的に行数増えとるわ。

    refactor script · takeshe12/toketenakunaru@f8d02c2 · GitHub

    おわりに

    趣味の音楽+仕事のプログラミングということで、楽しいですね。インフラまわりもAWSで整えられたので満足度高いです。肝心のコンテンツ更新も少しずつやっていきます。

    わかる!ドメイン駆動設計を読んでみた。

    はじめに

    なれる!SEみたいですね。あ、新刊出てる、読まないと。

    入社してからインフラよりのソフトウェア(Rails)担当からじわりとオープンソースクラウド基盤開発へ移りつつ、今はインフラの自動化(DevOps、Infrastructure as a Code、Continuous Integration、Continuous Delivery)あたりをやっています。

    ちょくちょくアプリ作りは片手間でやりつつ、あんまりがっつり業務アプリを作る経験はないのですが、この前勉強会でお会いした方が「今これ読んでるんですよー分厚いし難しいんですけどねー」とおっしゃっていて、そろそろ読まないとなーと感じているところ。

    エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

    エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

    とはいえこの分厚さ、とても読み通せる気がしない。

    まずは概要だけ押さえておくかということで以下を読んでみた。

    techbooster.booth.pm

    内容のボリュームに対して1000円は高い。。。と思いつつ、自分の興味が向いたときにその領域の第一のインプットはしておいたほうがいいな、と思い、読んでみました。

    わかる!ドメイン駆動設計

    Androidアプリ開発担当となった主人公が対話形式で、具体的な冷蔵庫の賞味期限管理アプリケーション構築という例を通してドメイン駆動設計を解説していく物語です。

    本書にも書かれてありますが、当然この本だけでドメイン駆動設計が押さえられるわけでもなく、おそらく表面のほんの少しを撫でた程度だと思います。

    ただ、ソフトウェア開発における「そのソフトウェアは何のために作るのか?」という根本的な疑問に答えるための大事な概念だと思います。世の中、作ったはいいけど使いづらかったり、本当にやりたいことはできなかったり、時間が経つにつれて使い物にならなくなるソフトウェアは多い。

    学習でもなんでもそうですけど、考え方ってどんどん抽象化されていきますよね。ソフトウェア設計もそう。単純な処理をするメソッドから、設計手法、設計思想、言語思想。。。こういったなかなか言葉にしづらいけど有用な概念を自分の中に落とし込むというのは非常に重要だと思います。

    今回読んだ内容だとユビキタス言語、そのドメイン内での共通言語を定義する、しかもそれはドキュメント化してはならないというのは非常に重要だと思いました。名前やコードのモデル名が実態とそぐわない例がどれほどあるか。。。

    おわりに

    本家に加えて、実践本もありますが、先に本家を読んだ方が良さそうですね。今年中に読めるといいな。。。

    エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

    エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

    実践ドメイン駆動設計 (Object Oriented SELECTION)

    実践ドメイン駆動設計 (Object Oriented SELECTION)

    2017年1月の目標

    はじめに

    毎月目標を立てることを年間目標にあげた。

    take-she12.hatenablog.com

    いや本当ごめんなさいこのブログ更新されるの18日だけど?1月の半分すぎてるけど?初月からなしはまずいでしょね、

    言い訳すると目標自体はもう数日前から考えてたんですいろいろバタバタしてたんですーーーー書かせてください書きます。

    1月の目標

    いくつかカテゴリごとにあげてみます。やりながら数は調整していければと。今月は思いついただけ。きっと月末焦ることになるんだろうな。

    楽曲制作

    • とけてなくなる、消えて くなるベース録音して公開
    • こりーセッション曲、1曲自自パート録音完
    • 千秋さんコラボ曲、ベース、ドラム、キーボード、ガイドボーカルいれて公開
    • なのは、月の光に歌うよ 作詞作曲完

    今年は他者への提供含め、作曲の年。自分自身歌ったり演奏したりするよりは作曲のほうにスキル振っていこうと思っています。各プロジェクト全力で、ここは厳しくやっていきたい。守りたい。

    英語

    • site reliability engeenear 1. Introduction読んでブログ書く
    • Grammer in use Unit10〜20
    • amazon english 5作品

    英語に少しずつ触れる時間増やさないといけないですね。

    ソフトウェア

    rubyマンだったんですが最近はpython機械学習についてはゼロからはじめるディープラーニングはやってみたいな。これもpythonですけど。

    読書

    積ん読かつkindleの可能性もありますが、物理的積ん読と、kidle的積ん読はどちらも読む。どうも最近読む時間取れてないなあ

    健康

    • 30days plank完了
    • run 月50km

    腹筋とジョギング、あんまりがっつりやるつもりはないですが、最低限やっとかないと太りすぎるので

    おわりに

    ちょっと駆け足ですが明文化して振り返るためのエントリーということでご容赦いただきたい。

    自分にあった場所はどこか?「諦める力」を読んだ

    はじめに

    読んだ。

    去年は目標がどうとか、ソフトウェア挫折とか、自分の技術は何かとか、そういうことを一生懸命考えた1年でした。

    take-she12.hatenablog.com

    take-she12.hatenablog.com

    「やりたかったけどやらないと決めたこと」「やれなかったけどやっばり(どうしても)やりたいこと」をハッキリさせると良いかもと思った

    と同期とのslackでこぼしたところ、「諦める力」が参考になるかもね、と教えてもらいました。

    諦める力

    諦める力 〈勝てないのは努力が足りないからじゃない〉 感想 為末 大 - 読書メーター

    諦めることは決してネガティヴではなく、より良い道を選ぶ、選択でしかない。本書の主張はここに集約されており、前半部分で十分書かれている。著者のエッセイ集。諦めること、目標達成できないこと、つらく考えてしまいがちだけど、(全力で努力した上で)届かないなと悟るなら諦めて、自分が楽に勝てる場所探し続けたほうがいいよというのは真理だと思う。

    3年やってイマイチ効果でないんなら向いてないので他の場所を探したほうがいい、という話もある。

    上で引用しているエッセンシャル思考の記事でも書いているが、任天堂の岩田社長が「好きなことよりも得意なことを探すといい」という話もある。

    www.4gamer.net

    岩田社長もおっしゃるように、得意なことは「手間のわりにまわりがありがたがってくれること」である。そして直前に語られている、アウトプットされるものの質はそのひとが日頃考えていることに左右される、という発言も興味深い。これは「好き」の話だ。

    何を諦めるか?いつ諦めるか?どう諦めるか?

    take-she12.hatenablog.com

    気が多い人間だから、やりたいことだけはたくさんある。ただ、それが達成できなくても必要以上に落ち込まないこと、そして潔く諦める(諦めることは悪いことではない)こと。そしてやりたいこと、目標としたいことは日々変わるのて、定期的にアップデートすることが大切だと気づけたことが去年の収穫だと思ってます。

    ただやっぱり難しいのは「一生懸命時間をかけてやってきたこと」を諦めることなんだと思います。サンクコストの話もあるしね。

    「一生懸命やってきたことを諦めること」は「自分が得意なことを見つけること」と同じぐらい難しいし、前者がなければ後者にはたどり着けないんでしょう。

    だから、一生懸命やる→あってなければ諦める→別のことを一生懸命やる をまわしていつか出会えたらいいな、ということで、自己実現銀の弾丸は(当然)ないですよね。

    おわりに

    大切なのは「努力した上で」諦めるのは悪いことじゃないよ、ということ。努力もせずに諦めることだけを繰り返してはならないということは肝に銘じておきたい。

    2017年の目標

    はじめに

    2016年の目標振り返りは実施済み。

    take-she12.hatenablog.com

    3つ達成しました。

    1. 引っ越し[達成]
    2. 年に4回登山する[未達成、3回]
    3. 会社外で1円収入を得る[未達成]
    4. aikoのカブトムシをピアノで弾く[未達成]
    5. ビールを飲まない[達成] 6.体脂肪率15%[未達成]
    6. 簿記3級[未達成]
    7. CDをリリース[未達成]
    8. 小学校時代の先生に会いに行く[達成]
    9. 本を100冊読む[未達成、75冊]

    うち、7の簿記は諦めます。3は方法を変えます。その他は継続です。

    1. 10曲作詞作曲する

    音楽としては作曲方向にスキル振っていこうと思ったので、アウトプットのチャネル問わず、10曲作詞作曲します。月1以下なので十分達成可能だと思います。

    努力目標としては形にして公開とします。

    2. CDを出す

    とけてなくなるで1枚、ベースでやってるバンドで1枚出せそうです。

    3. ミュージックビデオを作る

    やり方も何もわかってませんが、2の目標が実現したらどうせならやりたいですね。

    4. 100万貯金

    急に目標高すぎじゃない?大丈夫?今年からようやく財形貯蓄をはじめるので、それを含めた金額とします。仮に月4万財形で引いたとして48万。残り52万はボーナスなり自分の意思で貯めるってことね。。。

    5. 毎月目標を立てて振り返りをする

    すごい、目標に目標を立てることがある!あたらしい!年間目標って期間が長くて立てるのも難しいんですね。向いてるのは結果が数字ででる貯金とか、ビールやめるとかですね。

    6. 英語の本を5冊読む

    内容問わず、です。もちろん読んだ結果のアウトプットは現在も習慣化してるので同様に行います。とりあえずSite Reliability Engineering: How Google Runs Production Systemsは買ったまんま読めてないので読まないと。

    7. 英語教材終わらせる

    せっかく買ったけど途中で終わっちゃったので年間目標に昇格です。6,7含め、英語に注力する年になりそうな予感がしてます。

    Grammar in Use Intermediate Student's Book with Answers and CD-ROM: Self-study Reference and Practice for Students of North American English (Book & CD Rom)

    Grammar in Use Intermediate Student's Book with Answers and CD-ROM: Self-study Reference and Practice for Students of North American English (Book & CD Rom)

    8. 読書100冊

    変わらず目指していきます。が、まぁあくまで指標なのであまり重要ではないです。

    9. 酒を1ヶ月飲まない月を1回作る

    酒をやめたら体調がどう変化するか興味があるのでどこかでやります。

    10. 人間ドック受ける

    日数は2日とか短期間かもしれませんが、28歳になるので、受けておきます。

    30までの目標へのアプローチ

    1. 母をスペインに連れて行く お金さえあればどうにでもなるのでまずは今年貯めてみます。

    2. 47都道府県制覇 残りは 秋田/福島/新潟/福井/長野/三重/徳島/愛媛の8件。2016年は5件行きました。順調。3月に徳島愛媛に行きます。

    3. ピアノで弾き語り 進歩と言っていいかわかりませんがキーボード買いました。(笑)

    4. 本を出す 出したいけど出す内容がまったくないんですよね。アウトプットはブログでいくらでもしてるんですが、本みたいなまとまった量のアウトプットというと自主制作だとしてもなかなか。それぐらいの内容を見つけるっていうのも密かな目標にしようかな

    5. 会社外で1円"利益"を出す これは目標にするのはやめようかなと思います。

    カレー?

    カレーについては別途目標をたてています。以下のブログで近々公開されるかと。

    curryengineer.hatenablog.com

    おわりに

    目標、達成できないと凹んだりしてましたけど、この対談で目標達成しなくても振り返ればいいんだよーってことがわかったので気楽にやります。

    take-she12.hatenablog.com

    自分の関心って日々リアルタイムに移り変わるので、今回は毎月目標をたててやるってのが重要です。1月分どうしようね!近いうちに書きます!

    2016年は75冊読みました。振り返りとオススメ本。

    はじめに

    100冊目指してましたけど届きませんでしたね。去年は66冊なので+9冊。

    読書メーターがようやくリニューアルしましたね。

    elk.bookmeter.com

    10冊ぐらい印象的だった本をあげてみようと思います。

    ぼくたちに、もうモノは必要ない。 - 断捨離からミニマリストへ -

    ぼくたちに、もうモノは必要ない。 - 断捨離からミニマリストへ -

    断捨離系ブームの火つけですかね。断捨離の本という"モノ"を買うんかいって気分になりますが(電子版があればそちらをどうぞ)今回引越しに伴ってモノを大量に捨てました。そのあともこれ以上はモノを増やさないよう心がけています。今はもうあらゆるものを持たない時代というのは間違いないですね。

    とはいえデジタルデータのバックアップにはお気をつけください。

    断片的なものの社会学

    断片的なものの社会学

    これね、とっても面白かったんだけど、言語化できていませんでした。(ブログに下書きのまま残ってる)もう1回読もうかな。社会学と断片的っていう一見矛盾(?)したものを考察して、何を言っているのか、何を伝えているのか、ぼんやりしていてわからないんだけど、何かが届いて、何かが動くんですよ、あー言語化できない!気になる人は読んでみてください。

    イノセント

    イノセント

    唯一新刊が出るたびハードカバーで買う作家、島本理生の新作。島本さん特有の危うい女性、クソみたいな男、スリリングな展開、酒と旅。イノセントって何がイノセントなの?って思いましたね。

    何が「イノセント」だったのだろう。そう問う物語だった。神がいても、いなくても、許すのも、幸せになるのも、自分なんだと思えた。スリリングな展開、相変わらずの弱さと隙を持つ主人公、性欲が先行する男と、島本作品の特徴的な人物たちだったが、恋愛や出産よりも、「生きる」こと、「幸せ」とは、を考えてしまう小説だった。

    私の名前は、高城剛。住所不定、職業不明

    私の名前は、高城剛。住所不定、職業不明

    この本をきっかけに高城剛にハマりましたね。ふむふむほうほう、自分ができる人になれるような気がしてくるので即効性があります。(笑)QA方式でサクサク読めるのでさくっと自己啓発したい方にオススメ。もちろん内容も素晴らしいですよ。

    すべて真夜中の恋人たち、というタイトルに負けない内容。

    「雰囲気が好き」なんて何も言っていない感想をもらしたくなるほど、真夜中の景色とこぼれ落ちる感情の波が恐ろしくマッチしていた。登場するすべてに無駄がなく、どの話もこの作品を構成するのに必要なものばかり。聖と冬子の会話もコントラストが効いていて面白かったし、登場人物の価値観まで見えるのが面白かった。個人的には水野くんの考え方が重要で、彼の「自分で選ぶこと。与えられたものを捨てること」という考えが好きで、冬子には持っていないものだったんだろう。言葉を落とすこと、大切だと思った。

    作曲少女~平凡な私が14日間で曲を作れるようになった話~

    作曲少女~平凡な私が14日間で曲を作れるようになった話~

    「理論書などGo to Hellなのです!」の名前の通り、このラノベはすごいです。すぐに作曲できるようになるとは言わないまでも、作曲が身近に感じられるんじゃないでしょうか。僕も作曲経験はあれど、耳コピは苦手で、この本を読んで同じ方法で耳コピをしたら以前より楽にできるようになりました。作曲初心者の友人に勧めましたけど絶賛。オススメ。

    文庫化されていたのではじめて村上春樹を読みました。昔読んだことあったかもしれないけど忘れた。別の作品も読もうと思えた短編集。

    まえがきでも述べられてる通り、女のいない男たちというテーマのコンセプトアルバムであり、緩く関連が見られる。ドライブ・マイ・カーの、演じて、また、戻るが、同じ場所に戻らないということ、イエスタデイの関西弁と、器用な女、独立器官の、自分が何者かを見つめゼロになろうとした医師。この3つが好きだった。シェエラザードの語る話には確かにひきこまれたが前提となる設定がよくわからないし、木野の登場人物も個性的でバーの静かな雰囲気が良いがオチが不明瞭だし、最後の表題作についてはほぼ全てがよくわからない。

    たとえる技術

    たとえる技術

    個人的ベスト。たとえることにここまで考えたことなかった。読書って今まで知っていたし触れていたんだけど、それに新しく名前をつけたり、それについてとことん考えて新しい視点が自分の中に増えることが楽しみだなぁと思う。

    take-she12.hatenablog.com

    歯はみがいてはいけない (講談社+α新書)

    歯はみがいてはいけない (講談社+α新書)

    最近歯医者に行きだしてから読み出した本。読むのが遅かった。歯に関してはnot too late、飲んで歯を磨かずに寝る自殺行為はみなさんやめましょうね。。。しかしデンタルフロスを奥歯に使うのが難しい。

    消極性デザイン宣言 ―消極的な人よ、声を上げよ。……いや、上げなくてよい。

    消極性デザイン宣言 ―消極的な人よ、声を上げよ。……いや、上げなくてよい。

    個人的ベスト、その2。これも同じ「消極性なひとをどうやって表に出すか、引き出すか」については一度悩んだことがあったテーマなので、まさかそこに着目して研究している団体があるなんて!という驚きがありました。

    take-she12.hatenablog.com

    おわりに

    来年は冊数というよりは、ジャンル別にバランスよく集計してみようかなと思いました。どうも小説が少なくなっちゃうな。

    しかし読書メーター2016年に読んだ本は何冊!とズバっと出して欲しいなぁ。

    ちょっと小説をもっと多く読みたいな。今年は6冊しか読んでない。。。ジャンル別の集計も簡単にできるようになればいいな。

    「レガシーソフトウェア改善ガイド」を読んだ

    はじめに

    読みました。

    レガシーソフトウェア改善ガイド

    レガシーソフトウェア改善ガイド

    似たシリーズにレガシーコード改善ガイドがありますが、こちらはコードレベルのリファクタリングが中心のような気がします。(ちゃんと読んでない。)

    レガシーコード改善ガイド (Object Oriented SELECTION)

    レガシーコード改善ガイド (Object Oriented SELECTION)

    なぜ読もうと思ったかというと、今CI専任のプロジェクトにいます。

    部内の製品を見てみると、テストコードは「かつて少し書かれた」残骸が残っていて全然機能していない「レガシーコード」が多い。

    そしてレガシーコード・ソフトウェアの改善まではミッションではないにしろ、古いコードにテストコードを書く・書かせるというアプローチはしたいと思っています。そのときにレガシーコードをどう立ち上げますか、どう改善しますかというベストプラクティスがあればそのついでに改善提案もできるかもしれない、という興味で手に取りました。

    この本の良いところは特にCD(Continuous Deployment)に関しても最新技術(Vagrant、Ansible)を使うと言及しているところが良いですね。

    では中身を簡単にさらっていきましょう。

    第1部 はじめに

    ここではレガシーソフトウェアの定義を確認するとともに、そのために必要なスタート地点である、データ収集というアプローチが大切という話が書かれています。

    本書の前提知識の部分ですね。

    レガシーコードの定義部分、テストがない、ドキュメントがない、引き継がれまくってる、テストしにくい、環境構築が難しい、などなど「あるある」と感じることが多いのではないでしょうか。

    そして最も改善のための高い壁、触れてはいけない、精神的な「恐れ」との立ち向かい方についてが第2章です。特に基盤周り、ツールを使いこなしてあらゆる計測可能な情報を収集するとか、ツールを整えるとか、jenkinsを使ってチームのコミュニケーションハブを作るとかの、準備運動が書かれてます。

    第2部 コードベース改良のためのリファクタリング

    ここではリファクタリング・リアーキテクティング・ビッグリライトの3段階を説明します。

    大きな主張としては絶対に新規作り直しはするな、ということでしょうね。

    手がつけられないコードだとしても、「とりあえず動いて」いて、かつ「書き直してきた歴史」があるわけで、今はそれを見えないけど、かつてのバグを超えてきたコードであることは間違いなく、気づかず同じバグを踏んでしまう可能性があります。どんなに時間がかかっても少しずつ手直しするしかない。銀の弾丸はないとはいろんな場所で言われてますもんね。

    また、リファクタリングは経営層から承認がおりづらいことについても言及しています。まずは秘密の20%プロジェクトとしてやってしまって、そのあと承認をとるほうが良いですね。組織の承認をもらって正式な仕事にすることを進めています。

    コメントアウトはまっさきに削除して良いとか、今通ってないコードはいらないとか、どこを削っていくかの指針を示しています。

    また、ユニットテストは大切だが、しばしば無意味なものになることについても慎重に述べています。リファクタリングしてしまえばそのテストは無駄になるかもしれず、またリファクタリングをしないとテストがかけない場合も往々にしてある。さらに、unittestのカバレッジにも敏感になりすぎる必要はない(完璧である必要がない)ということも述べています。

    ただ、カバレッジが100%じゃないけど、品質はokですって上長に説明してokもらえるか自信が持てないなと思いました。これ、さらに外側のE2Eテストも自動化しておいて、そちらで基本機能は全てokが出ており、カバレッジ100%にするためにunittestを書くのは無意味かつコストが見合わない、っていう見解になるのかな。

    リグレッションを防ぐためにあらゆる層。。。UnitTest、ComponentTest、UIのテスト。。。で自動テストする必要があるっていうことですね。

    ちなみにリアーキテクティングはモノシリックなアプリケーションをマイクロサービスの考えで機能ごとに分割することですね。

    これにももちろんメリットデメリットあって、分離すればコンポーネント(チーム)ごとに、内部の実装を変更できる、つまりインターフェイスさえ変更がなければ問題ないので他チームと同意する必要がないことがメリットとしてあります。反面インターフェイスの変更がコストになったり、結合テストの難易度があがることがありました。

    第3部 リファクタリングの先へ -プロジェクトのワークフローと基盤を改善する-

    これまでのリファクタリングやテストの精神的な部分、組織的な部分、メリットデメリットは各所で語られてきました。

    最後はワークフローの自動化の大切さについて実例に伴って書かれており、これも「わかる。。。」と思いました。

    テスト環境を作る時、「ここのwikiに書いてあるからそれ見ながらやって(ただし情報が古く誰がいつ更新したのかわからない)」みたいな話よくありませんか?

    それが全て自動化されて、ここを押せばすぐに環境ができるから仕事(本当にやりたいデバッグや開発)に取り組める世界を作ることに努めなさい、そのためにはあらゆるものを自動化しなさい、という内容です。手順書殺せの僕としてはとても同意。。。

    そうやって自動化した上で、簡潔なREADMEをバージョン管理に残しておきなさいという話。

    これ、OSSの時代である今時、デプロイ自動化なんて当たり前のように感じますけど、残念ながら社内ではまだまだです。遅れながらも実践して広めていきたいと思います。

    おわりに

    「そんなことできれば誰も苦労しない」だけどそこらに転がってレガシーコード。もう生まないということが大切だとわかっていても、生まれてしまったものを嘆いても仕方がない。

    この世にあるレガシーコードを改善する方法を体系的にまとめた本書には、改善のためにどう取り組めばいいかというエッセンスが詰まっています。

    「あらゆるものを自動化」して、それを組織に広めていくことが自分にできる第一歩だと思っているので、2017年の最初の3ヶ月、仕事で取り組んでいき、テスト・CI・CDを実践し、社内に広げていきます。

    レガシーコードを目の前にして、なんとかしたいけど、巨大な壁に何をしていいかわからない、というひとにはおすすめです!