ツナワタリマイライフ

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

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を実践し、社内に広げていきます。

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

はてなブログの投稿予告tweetをするスクリプトを書いた

#はじめに はてなブログを書いているひとで、投稿予約を利用して同じ時間に投稿するひとも多いと思う。(根拠はない)

そうすると明日、明後日にどんな記事が投稿されるか予告のツイートをしたくなる。

今回ははてなブログAPItwitterAPIを利用し、Pythonで投稿するスクリプトを書いた。

github.com

このスクリプトをcronから蹴ってあげれば、好きな曜日、日時に投稿予告ツイートをすることができる。

TwitterAPIを利用するまで

開発者用ページにいって、4つのキーを取得する必要があります。

apps.twitter.com

twitter_tokens.pyに定義される4つのキーを入力してください。

ここでは詳細を省きます。電話番号認証が必須でした。

はてなAPIを使うためには

BASIC認証 でいけます。設定→詳細設定→AtomPubにルートエンドポイントとAPIキーが書かれています。

hatena_auth.pyに記入してください。これではてなブログへの投稿や記事の取得ができます。

hatena_notice.py

メインのプログラムです。83step。もっと短くできたかもしれませんね。軽く解説します。

def get_drafts():
    drafts = []
    global URL
    
    for i in range(REPEAT):
        res = session.get(URL,auth=(USER,APIKEY))
        soup = BeautifulSoup(res.text, "html.parser")
        URL = soup.find("link", rel="next").get('href')

        article = soup.find("feed").find_all("entry")
        for art in article:
            isdraft = art.find("app:control").find("app:draft").text
            if isdraft == 'yes':
                title = art.find("title").text
                updated = art.find("updated").text
                draft=[title,updated]
                drafts.append(draft)
    return drafts

記事の中からdraft状態のものを取得します。実際にはてなAPIを投げている部分もここです。REPEAT変数で指定された回数、nextページに繰り返し取得します。だいたい10ページもとれば、よほどストックがあるひとじゃない限り大丈夫だと思います。

取得したXMLをbeautiful soupを使って欲しいところをとっています。下書きかどうかをisdraftで判定して、下書きのもののtitleとupdatedを取得して返却する関数です。

def get_reserve(drafts):
    reserve = []
    now = datetime.datetime.now()

    for draft in drafts:
        date = datetime.datetime.strptime(draft[1],"%Y-%m-%dT%H:%M:%S+09:00")
        if now < date:
            #convert string to datetime
            draft[1] = date
            reserve.append(draft)
    return reserve

次に下書きの記事の中から、更新予約をしているもの、すなわちupdateが今より未来の日付のものを抽出します。datetimeとstrignの変換をここで学びました。ここではstringのtitleと、日付はdatetimeで返しています。

def tweet_extract(reserve):
    text = "update notice:"
    for art in reserve:
        date = art[1].strftime('%m/%d')
        
        if len(text) + len(art[0]) > 140:
            break
        text += "%s:%s" % (date,art[0])
    return text

最後につぶやくための文字列を作成しています。140文字以上になってはいけないので、足しあわせた結果が140文字を超える場合は加算せずloopから抜けます。

def tweet(text):
    URL = 'https://api.twitter.com/1.1/statuses/update.json'

    payload = {'status': text}
    req = twitter.post(URL, params = payload)

    return req.status_code

ここは単にツイートしているところですね。楽です。

tweepyというライブラリもあるようですが、今回はOAuth認証部分だけライブラリを用いて、requestモジュールで投稿しています。

おわりに

Pythonを最近は意識的に触っています。だいぶ慣れてきました。テストコードはモックの作り方がわかってないのではてなAPIを実行する部分やツイートする部分がかけていません。

一応誰でも使えるよう汎用的にして(個別の設定値は外出しにして)必要なライブラリを書いてgithubに公開できたので以前より進歩です!(以前はシェルとrubyのゴミみたいなスクリプト書いてた)

Beatifulsoupやtwitter-apiははやく使いこなせるようになってスクレイピングで遊びたいな。

消極性ハック、シャイハックしよう!「消極性デザイン宣言」を読んだ

はじめに

シャイハックという言葉はご存知だろうか。

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

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

この本、人間の中の"消極性"に着目し、なぜ消極性になるのか、その不安はどこから来るのか。そしてその消極性をどうハックするのか、デザイン(仕組み)でカバーできないのか?積極性と消極性の悲しいギャップを説明しつつ、それをデザインで埋める方向を模索する、というのが大筋です。

著者は消極性研究会。いいな。おれも入りたい。

www.sigshy.org

シャイ子とレイ子の設定も乗ってるw 小野ほりでいさんの文章じゃないんですね。

消極性研究ができるゼミが載ってる。僕最近気づいたんですけど文系分野の学問のほうが好きですわ。。。

さて本書は著者5人、5章に分かれているので、1章ずつ振り返りと感想を述べていきます。

「やめて」とあなたに言えなくて 1対1もしくは1対少数のコミュニケーション [栗原一貫]

まず最初に人間を大きく3種類に分類します。

  • 「社会」が好きな人
  • 「人」が好きな人
  • 「自分」が好きな人

僕は「人」が好きだと思ったんですが、栗原さんの定義によると、コミュニケーション意識は人数が多いほど下がってしまう傾向があるので「社会」派のようです。とはいえ、これは完全に排他ではないことは注意されていますし、僕も「人」派の側面をあると思います。

「人」派に分類される、複数人でのコミュニケーションが苦手なひとに対して、技術で解決する様々な発明が紹介されます。

声の大きい「積極派」をできるだけ楽に黙らせる「スピーチジャマー」

イグノーベル賞インタビューLaugh and Think【第3回】おしゃべりな人を黙らせる! スピーチジャマーの発明:津田塾大・栗原氏 | 製造業エンジニアのためのモノづくり情報サイト「Tech Note」

タイトルにある通り、この章の主題は「やめて」とあなたに言えないひとに、いかに心理的ハードルや、相手に激怒される可能性を徹底的に下げつつも、「やめて」というメッセージを伝えるための発明を紹介してくれます。

実用的なところまで達成するかということよりも、消極性心理に徹底的に向き合ってデザインしている部分が見事で、それぞれのエッセンスは必ず別の場面で役に立つはずです。

「モノ」のデザインを通して、消極性のひとが積極性のひとにメッセージを伝える方法を模索する章ですね。

考えすぎを考えすぎよう 人が集まるイベントなどにおけるコミュニケーション [西田健志]

次は「積極性勢」(ウェーイ族と揶揄していますが)が消極性勢に「大丈夫大丈夫!みんな楽しめるゲームがあるから!」と恐怖のジェスチャーゲームを用意していて消極性勢は絶望する、両者の心理的ギャップに着目することを発端に、学会でのコミュニケーションを促進するツールを作っています。

学会でのコミュニケーションにおいても、「あの人と話したい」という気持ちはあれど、それを直接伝えるのは憚られる。かと言ってシステムで「誰と隣になりたいですか?」と入力させたとしても、会がはじまってしまえばそう希望したことが相手に伝わってしまい無意味。

そこで「誰と誰が隣になってほしいか?」(自分も他人も入力可能)とすることで、自分の希望が他者にバレることなく、消極性のひとが積極的に思いをぶつけることができるシステムを実現しています。これはまさに消極性をハックしてると言える顕著な例かと思います。

シャイなひとをどうにかして奥底の積極性を出させるか、そんなシャイハックは勉強会といった金銭的対価のない自主的参加の場で特に役に立つように思いました。

共創の輪は「自分勝手」で広がる 複数人でのコラボレーション [濱崎雅弘]

旧来、コミュニケーション・コラボレーションには物理的・地理的制約があり、外交力のある「積極性勢」に圧倒的有利だった。しかしインターネットの登場でいつでも誰でもどこでもコラボレーションが可能になり、それはニコニコ動画初音ミクを周辺に巻き起こったコラボレーション文化に現れている。

もともとコラボレーションといえば調整が必須であり、これは消極性勢にとっては距離を置きたくなる内容だが、ニコニコ界隈では横に広がるN字創作によって、相手へリスペクトとリファーをしつつ、別のクリエイティビティでコラボレーションすることで広がったという考察がされている。(歌ってみたに対して踊ってみた、など)

この例を受け、内向的な消極的なひとたちの知をいかに集団で引っ張り出すかの一般化にも挑戦しています。各自が各自にとって1番全力を出しやすい状況としては、各々がまったく違うものを担当し、そこにできるだけ調整が必要ないという環境がある。この環境をいかにデザインするかがシャイハックで重要かと思います。

コラボレーションが必要な場面は普段の仕事でもたくさんありますよね。僕は以前技術勉強会を主催したときにこのあたりをとことん考え抜いた経験があるので内容に強く惹かれました。「あいつはすげーやつ、あいつもすげーやつ、みんなでやればめっちゃすげーことができる」でもそれぞれのあいつは「自分からそこまでやる気にはならない」現状があるわけで。そこを環境でハックできればいいなぁ。

スキル向上に消極的なユーザのためのゲームシステム [簗瀬洋平]

ここからは消極性のハックの中でも「モチベーションのハック」ここまでは「コミュニケーションのハックでした。」

常に自分が神プレイしていると錯覚できるゲームを開発し、いかにゲームに対するモチベーションをハックできるかを検証し、モチベーションはコントロールできること、そしてモチベーションはコントロールされうることを示しています。

この章と次の章で重要なことは、モチベーションが低いことは悪いことではない、ということですよね。モチベーションが低いことは自分自身の「気力」がない、精神性に訴えかけるのはあまりにマッチョな考え、そうじゃない、うちなるモチベーションをいかに自然に引き出すか、それをデザインで解決しようよって考えはとても同意します。

みんなで楽しく、楽にやる気を出す、そんなデザインを考えていきたいですね。

モチベーションのインタラクションデザイン [渡邉恵太]

こちらも「モノ」のデザインには消極性の観点が重要であるということを解いています。

掃除機って、使うときのことを考えがちですが、実は使ってないときのことが重要でないですか?使ってないときに「使おうとしやすさ」=アプローチャビリティが必要であり、それに付随してすぐに出しやすいためのリビングに置いておいても気にならない「美しさ」というのも価値になりつつある。

いかに「ついでに」「自然に」「生活に融ける」ように使われるようにデザインするためには、人間の奥底の消極性に注目するしか答えはありません。

自分自身のモチベーションをコントロールするときに、部屋のものをどう配置するか?ということは誰しも考えるテーマですよね。自分の中の「めんどくさい」をハックし、どうやったらやるようになるか?を考えていきたい。

私は消極的?積極的?

外交(コミュニケーション)的な観点で言えば僕は積極性の人間に分類されると思います。とはいえその力が発揮できるのも6人程度までの集団ぐらいまでで、ある閾値を超える、もしくは自分より積極的なひとがいれば黙ってしまうし、誰もいなければ自分が積極的になろうとする、この性質は確実に「消極性」の人間の考えなんですねw わかりづらいですが、本書を読めばその意味がわかると思います。

そんなある面では積極的だが、実は消極的な私も、消極的なひとのことをわかりたいと思っています。消極的と積極的を結べるひとであり、言葉を使い、仕組みをデザインできる人間でありたい。消極性に、僕も着目していきます。

おわりに

自分自身、普段生活していて消極的なひとは多いと思っています。仕事でも、「君はそんなにすごいのになんでみんなにアピールしないんだい?」と思うことが多々あります。逆にできる人ほど「もっと組織のために共有してくれ」とも思っています。(このあたりは今着目しているチームビルディングに関係する部分です)そしてこういう問題に必要な手段としてシャイハックがあったことを学べたのは大きいです。

消極的なあなたも、「なんでそんなに消極的なの?」と思うひとと仕事をしている積極的なあなたも、ぜひ読んでみてください。人間の消極性にハックすることが、消極性へのユニバーサルデザインがいかにこれからの社会で必要で大切かがわかると思います。

レガシーな静的Webサイトを一新!その⑤ httpsサイトで承認されてないscriptの警告が出てしまう

はじめに

12月頭に、趣味の音楽プロジェクトのページをFC2からAWS-S3へ移行。独自ドメインを取得し、CircleCIと連携させました。

take-she12.hatenablog.com

take-she12.hatenablog.com

take-she12.hatenablog.com

さらにhttps対応したのですが。。。

take-she12.hatenablog.com

おぉん??

f:id:take_she12:20161227145019p:plain:w500

証明書は正しいが。。。

f:id:take_she12:20161227145122p:plain:w500

最初にサイトに行くとjava scriptが動かず、ヘッダとフッタが読み込まれませんでした。

f:id:take_she12:20161227145156p:plain:w500

1つのwarningがjquerygoogleのCDNに取りに行っているのですが、このプロトコルがhttpなのがよくないようです。

https通信下でjavascriptが動かない場合の対処法

修正しましたが、local環境ではhttps接続できないこと、AWS CloudFrontのキャッシュが24h効いているのですぐに確認できないのが難点。

remove http protocol for google CDN · takeshe12/toketenakunaru@204b3b1 · GitHub

もう1件、何やらエラーが。

Uncaught DOMException: Failed to read the 'contentDocument' property from 'HTMLIFrameElement': Blocked a frame with origin "https://toketenakunaru.com" from accessing a cross-origin frame.
    at reflexIF (chrome-extension://oingodpdjohhkelnginmkagmkbplgema/content.js:1:8293)
    at reLoad (chrome-extension://oingodpdjohhkelnginmkagmkbplgema/content.js:1:7378)
    at WeblioExtensions.OnLoadHandler (chrome-extension://oingodpdjohhkelnginmkagmkbplgema/content.js:1:1605)

調べましたが、chrome特有のエラーのようです。safariで確認してみましたが、safariだとjava scriptを動かすこともできず、開発メニューを出してもエラー内容を確認する方法がわからず。

その後

とりあえず無事java scriptが読み込まれ、メニューが表示されるようになりました。上の例外は消えてませんが。。。

f:id:take_she12:20161227231115p:plain:w500

おわりに

ただのread onlyサイトにここまでしてhttps対応した意味があったかどうかは置いておいて、無料で簡単にhttpsサイトが作れるんですね。AWSすごい。

これからもhtmlまわり経験ないけど頑張って触っていきますっていうのと、肝心のコンテンツ(楽曲制作)を頑張ります。。。

レガシーな静的Webサイトを一新!その④ AWS CloudFrontとCertificate Managerでhttps対応する

はじめに

12月頭に、趣味の音楽プロジェクトのページをFC2からAWS-S3へ移行。独自ドメインを取得し、CircleCIと連携させました。

take-she12.hatenablog.com

take-she12.hatenablog.com

take-she12.hatenablog.com

googlehttps対応してないサイトはページランク下げる*1と言っているので、https対応します。もちろん、勉強のためです。

SEO(ランキング上位にするために)SSL証明書を導入するって流れもなんだかなぁという気もするし、別に静的サイトでREAD Onlyなサイトを暗号化したところで、という気もしますが、世界のデフォルトはhttpsに向かおうとしているので流れに乗っておきます。

ちなみに各所でめちゃくちゃ苦戦しました

CloudFront

AWS CloudFrontはクラウドのフロントに位置して、redirectやページキャッシュの面倒を見てくれるいいヤツです。コンテンツ配信高速化のためにあれやこれややってくれるみたいです。

今回はhttpからhttpsのリダイレクトや、ページキャッシュのため(キャッシュしてくれるとS3の利用料金も下がるわけですね)に導入したいと思います。

CloudFrontページへGO

f:id:take_she12:20161226155342p:plain:w500

WebでGetStarted

f:id:take_she12:20161226155345p:plain:w500

ドメインはS3のバケットから選択

f:id:take_she12:20161226155348p:plain:w500

Redirect Backet Accessをyesに、Identifyも新規に作成、commentにdomain名を入れ、access policyをupdate

f:id:take_she12:20161226155352p:plain:w500

Redirect http to httpsを選択

f:id:take_she12:20161226155355p:plain:w500

あとはデフォルトのまま。cacheのTTLは24hのようですね。

f:id:take_she12:20161226155404p:plain:w500

distributionがprogressからdeployedになるまで15分ほど待ちましょう。

f:id:take_she12:20161226160625p:plain

idをクリックして表示されるdomainにアクセスしてもaccess denyとでます。

このドメイン名でアクセスできるはずなんですガー。。。とりあえず先に進みます。

参考:AWS再入門 Amazon CloudFront編 | Developers.IO

Route53

次にcloud front経由でS3のパケットにアクセスさせてやるため、Aレコードを変更します。

これまではhttp://toketenakunaru.com → S3のドメイン だったんですが、このS3のドメインをcloud frontのドメイン名に変更してあげます。

そうするとhttps://toketenakunaru.comにアクセスできた。なぜかよくわからない。

ただ、証明書がcloudfrontのものなので証明書エラーはでます。

f:id:take_she12:20161226182320p:plain:w500

SNSとSES

さて、Certificate Managerで証明書を取得するためには自分のドメインのメールアドレスで受信できなければなりません。

無料の証明書とはいえ、メールアドレスで認証するのですね。

まず、プッシュ通知サービスのSESの設定です。ここで、リージョンはバージニア北部にしておくのを推奨します。北オレゴンだとMXレコードが登録されなかったんですよね。。。

CreateTopicを選択

f:id:take_she12:20161226182558p:plain

適当なtopi nameをいれます

f:id:take_she12:20161226182616p:plain

転送したいメールアドレスをいれます。

ちなみに後からこれはリージョンを変更して作り直しました。。。

f:id:take_she12:20161226182626p:plain

SESでドメイン作成

f:id:take_she12:20161226182947p:plain

TXTレコード、CNAMEレコード、MXレコードが生成されるので、Use route 53を選択すればきれいにroute 53に登録してもらえます。

そのあとはメールを受信したときのruleを設定。

Emeil Receiving→rule sets→create new rule sets

f:id:take_she12:20161226183218p:plain:w500

メールで認証します。

f:id:take_she12:20161226183224p:plain:w500

新しくアクションを作ります。先ほど作ったSNSのものを指定。

f:id:take_she12:20161226183231p:plain:w500

適当なルール名とデフォルトのルールでokです。

f:id:take_she12:20161226183244p:plain:w500

admin@<your-domein>へメールを送信してみてください。json形式でくるのでわけがわからないと思いますが、とりあえず届けばokです。

参考:無償SSLのCertificate Manager、S3、Cloud Frontで、独自ドメインの静的HTTPSサイトを作る - Qiita

Certificate Manager

さてついに証明書発行です。ここは一番簡単です。

証明書にドメイン名を追加。

f:id:take_she12:20161226183638p:plain:w500

リクエストの送信。このとき以下のアドレスに送られるようです。SESでの転送設定はこのアドレスである必要があります。

admin@、administrator@、hostmaster@、webmaster@、および postmaster@

参考:よくある質問 - AWS Certificate Manager(簡単に SSL/TLS 証明書を作成、管理、配置) | AWS

f:id:take_she12:20161226183644p:plain:w500

ちなみにメールが死ぬほど読みづらいんですが、approvで検索ひっかけてください。そのあとhttp:..ではじまるリンクがあります。¥r¥nandの前までをコピペして承認用アドレスに飛んでください。

f:id:take_she12:20161226183659p:plain:w500

完了すると以下の表示になります。

f:id:take_she12:20161226183714p:plain:w500

再度CloudFront

domainの編集でcustom SSL certificationを選択。certificate managerで作ったものが選択可能になっています。

f:id:take_she12:20161226183717p:plain:w500

ただ少し時間がかかるようで、しばらくはcloudfrontの証明書が表示されます。

おわりに

静的webサイトをAWS S3で公開し、cloud frontを使うことで24時間キャッシュ&無料のSSL証明書を利用してhttps化を実現しました。AWSすごい!

AWSサービス同士は連携がシームレスでとても良いですね。

ちなみにCDP(Cloud Design Pattern)だとCache Distributionパターンなんですね。

http://aws.clouddesignpattern.org/index.php/CDP:Cache_Distributionパターン

参考: [ACM] AWS Certificate Manager 無料のサーバ証明書でCloudFrontをHTTPS化してみた | Developers.IO Amazon S3でSSL対応の静的ウェブサイトを公開する | マジメナラボ - majimena Inc. S3+CloudFront+ACM(AWS Certificate Manager)でHTTPS静的サイトを作ってみた - Qiita

*1:過剰表現