[AWS]EC2インスタンスにPuTTYでSSHログインしようとして、「Disconnected: No supported authentication methods available」、「Server refused our key 」というエラー発生時の対処法

AWS

タイトルが長くなってしまったが、削れないのでこれで。

症状

いつものようにPuTTYでEC2インスタンスにログインしようとしたところ、以下のエラーが発生して入れなくなった。

Disconnected: No supported authentication methods available (server sent: publickey,gssapi-keyex,gssapi-with-mic)

PuTTY側の画面は以下の通り f:id:alek3:20190218110928p:plain

対処法

公式に書いてあったのでその通りに実行したら直った。 aws.amazon.com

手順7は、ENTER YOUR PUBLIC KEY HERE ... のところを書き換えれば他はそのままでOK

根本原因

わかっていない。上記公式サイトで挙げられているもののうちのどれかが該当しそうな気はするが・・・

教訓

検索するエラーメッセージを変えてみるのも一手。

PuTTY側のエラーメッセージで検索しても有効な対処法は見つからなかったが、コンソールのエラーメッセージ「server refused our key」で検索したらすぐに対処法の書いてあるページが見つかった。

ipaファイルをアーカイブしようとして「No signing certificate “iOS Development” found」エラーがでたときの対処法

XCode XCode

いつものようにXCodeでipaファイルを作成しようと思ったらエラーが発生しました。

少し前はできていました。すなわち開発者証明書および秘密鍵は準備できています。

慌てずエラーを見ると以下のような文章でした。

No "iOS Development" signing certificate matching team ID with a private key was found.  
（中略）  
Code Signing Error: Code signing is required for product type 'Application' in SDK 'iOS 11.4

認証ができていないっぽいので、XCodeでの設定画面を見ます。

general > signingのところです。

すると、エラーっぽくなっていました。（スクショはとりそびれました）

設定を完了すると以下のようになります。

f:id:alek3:20190216231613p:plain

参考

dev.classmethod.jp

出てきたけどこんなに高度なのは必要ありませんでした。

読了：『ファクトフルネス』

書評

最近読書のペースが早くなっているような気がしていてうれしいです。

今回は『ファクトフルネス』です。

ファクトフルネスの大まかなルール

「ファクトフルネス」はなにかというと、事実に基づいて物事を判断する態度であり、それを妨げる自らの本能に自覚的であることです。

まずは要約として、「ファクトフルネスの大まかなルール」を以下に挙げます。

  • 分断本能を抑えるには…
    • 大半の人がどこにいるかを探そう
  • ネガティブ本能を抑えるには…
    • 悪いニュースのほうが広まりやすいと覚えておこう
  • 直線本能を抑えるには…
    • 直線もいつかは曲がることを知ろう
  • 恐怖本能を抑えるには…
    • リスクを計算しよう
  • 課題視本能を抑えるには…
    • 数字を比較しよう
  • パターン化本能を抑えるには…
    • 分類を疑おう
  • 宿命本能を抑えるには…
    • ゆっくりとした変化でも変化していることを心に留めよう
  • 単純化本能を抑えるには
    • ひとつの知識がすべてに応用できないことを覚えておこう
  • 犯人探し本能を抑えるには…
    • 誰かを責めても解決しないと肝に銘じよう
  • 焦り本能を抑えるには…
    • 小さな一歩を重ねよう

これだけでも、なんとなく人間には厄介な本能がいくつもありそうだなと感じられると思います。

それぞれの詳細について興味を持ったなら、本書で確認することをおすすめします。

以降は考えたことをつらつら書きます。

事実を集める大変さ

私はTwitterをしょっちゅう閲覧しています。私が見るTLでは、様々なニュースや意見が発せられ、リツイートされています。

本書では、それらの情報は分断や恐怖を煽り、ネガティブすぎるため、実際の統計データ、すなわちファクトにあたることが重要だと述べられています。

しかし、いざ実際はどうなっているのかを自分で調べようと思うと、なかなか重い腰が上がらないということに気づきました。特別に興味を持ったトピック以外、能動的に調べることはなかなかないんじゃないかと思っています。

それを思うと、日々ファクト（統計）を作っている人たち*1、それを分析している専門家には頭が下がります。

マスコミに期待しすぎてはいけない

日本各地や世界で何が起きているかを知らせてくれるのがマスコミです。テレビやSNSを見れば何が起きているのか大まかに掴むことができます。

私のTLではしばしばマスコミが批判されています。例えば、偏っているとか、犯人探しをしているとか、恐怖を煽っているとか、専門家から見るとトンチンカンなことを言っているとかですね。

本書では、マスコミは売れなければならないため、ネガティブな、インパクトのある、すなわち本能に訴える個別事象を取り上げがちになってしまうと指摘しています。

これはそのとおりだと思っていて、マスコミは情報の一つで、専門家の意見や、統計データを参照するとより正確な姿に近づけると思っています。

先程のマスコミへの批判はもっともですが、批判しても自分が気持ちいいだけでマスコミはすぐにそこまで大きく変わっていかないと思います。

本能に気づくための本書

本書では、ファクトフルネスでない10の本能があるから抑えていこうね、という内容になっています。

私が思うに、大事なのは本能で感じ取ったあとに、本書の内容を生かしてその判断や行動を修正していくことです。

ファクトフルネスとはなにかという知識があれば、事実を見誤らせる本能に気づきやすくなるでしょう。

例えは悪いかもしれませんが、ナンパの手順を知っていればそれに引っかかりにくくなることと同じです。

*1:最近の統計偽装には失望していますが……。

ブログを毎週書くコミュニティに参加して3ヶ月が経った #write_blog_every_week

週1回技術ブログを書こうという、#write_blog_every_week というコミュニティに参加して3ヶ月が経った。今日はその振り返りをしようと思う。

どんなコミュニティ？

主な活動はslackで行われいて、現在30人ほどが参加している。

ブログ記事を投稿するとslackに連携される。

サボっているとチームから追い出されてしまうというルールがある。

中心メンバーのよしたくさん作のサイトはこちら↓ write-blog-every-week.netlify.com

加入のきっかけ

私が加入したのは、コミュニティができて2ヶ月近くたってからだ。私自身も、その少し前から週1でブログを書く習慣を続けていた。何人かで一緒に始めていたのだが、いかんせん人数が少なすぎるという問題があった。

このままではいつ挫折するかわからない。そのような問題意識の中、毎週ブログを書いているこのコミュニティの存在を思い出した。自分を変えるには環境を変えるのが大事だ。知り合いもほとんどいなかったが飛び込んでみることにした。

実績

3ヶ月間、引き続き毎週ブログを書き続けている。はてなブログは継続期間を知らせてくれるが、30週間継続しているようだ。

良かったところ

  • 技術情報が入ってくる。 30人くらいが毎週ブログを書いているためいろいろなテーマの技術情報が入ってくる。細かいところまでは分からずとも、キーワードを頭の中にストックできる。

  • 読者数が増えた。 10人が19人になった。

  • 読書のペースが上がった。 1月だけで書籍レビューを3つ書いた。*1

課題

私個人の課題・改善点を挙げる。

  • 他の人のブログ記事を読んでいない。

一番課題だと感じていること。せっかくコミュニティに所属しているのだから、私なりにフィードバックしてメンバーのモチベーションになれたらと思っている。

また、「○○さんはこういう事柄に強い・関心がある」といったことをもう少し頭に入れておきたい。

  • 質を上げたい。

なんとなく、もっと質の高い記事を書きたいと思っているが、何をもって質を上げたと言えるかどうかもよくわかっていない状態である。

  • アクセスが伸びない。

月500PVくらい。最近は見ていない。

その他

昨日もくもく会に参加した。末広町のとらLabでの開催だった。駅近であり、ちょうどいい広さで非常に快適だった。10人前後でイベント開くなら有力な選択肢になると思う。

参加者の皆さまが買ってくださったお菓子をありがたくいただくだけの存在と化していた。次回があれば私も何か買っていきます。*2

*1:タブレットを買って電子書籍を読むようになったせいかも

*2:飲み物は持参してくるので意外と需要が小さそうだった

『アジャイルサムライ』はアジャイルの第1歩

書評

『アジャイルサムライ』を読了したのでレビューを書きます。

入門書としての3つの特色

アジャイルサムライは特に入門書と知っていて読んだわけではないのですが、アジャイル関連の入門書籍としてぴったりな理由が3つあります。

  • 過不足ない分量
  • カジュアルな語り口
    • 「マスター・センセイと熱心な弟子」という謎のコーナーがある
  • たくさんのわかりやすい図

ちなみに私が一番好きなのは荒ぶる四天王*1の図です。

毎週価値を届けよ

海外の書籍にありがちなのは、同じ主張を何度も繰り返すということです。『アジャイルサムライ』も例に漏れず、あることの重要性を繰り返しています。

それは、見出しに挙げたとおり、「毎週お客さんに価値を届けること」です。

実際、やろうとしたら大変

上記「毎週お客さんに価値を届ける」にはいくつか必要なことがありますが、特に私の印象に残ったのは、「成果責任を果たす」ことです。具体的には以下のことをやる必要があると述べられています。

  • 君は、仕事の質に責任を持たなきゃならない。
  • 君は、スケジュールを守らなきゃならない。
  • 君は、お客さんの期待をマネジメントしなきゃならない。
  • 君は、身銭を切るかのような覚悟でお客さんの資金を扱わなきゃならない。

文章にすると当たり前なような気がしますが、実際やろうとすると結構な覚悟が要りそうな印象があります。

『カイゼン・ジャーニー』を読んだときも思ったのですが、読み物としては楽しくても、実際にやろうとなるとめちゃくちゃ大変だ……という感想を持ちました。

疑問……お客さんはだれ？

本書は非常に読みやすいですが、わからなかったところもあります。

例えば、本書では、建設会社で使うシステムの例が多く使われていました。この場合は、誰がお客さんかわかりやすいと思います。

一方、パッケージ製品など、お客さんがたくさんいる場合、本書でいう開発に参加する「お客さん」は誰なのか、ちょっとよくわかりませんでした。おそらく、それを売っていくであろう事業部なのだろうなとは思いましたが。

アプリケーション開発への参加を促すべき「お客さん」が誰かは、もう少し掘り下げられていても良かったなと思いました。*2

まとめ

現在私はアプリケーションの開発に従事していますが、その進め方を客観的に見つめ直す上で、本書は非常に役立ちました。

2011年に日本語訳の初版が発売されましたが、あまり古さを感じませんでした。

プロジェクトにより状況は様々でしょうが、どんな人でも面白く読めると思います。

最後に目次を挙げて終わりとします。

目次

※目次は以下のサイトを参照しました。

『アジャイルサムライ』の書影と主な目次が出てこないから自分で貼るよ - 角谷HTML化計画(2011-07-02)

*1:時間、予算、品質、スコープ

*2:プロジェクトにおいてお客さんが誰かというのはプロジェクト参加者が認識を揃えるべき重要事項です。

JavaScriptのthisでハマった。

JavaScript

JavaScriptのthisよくわからんわという内容です。

問題概要・解決策

以下のようなdataを持つVueファイルを作成したとします。

data(){
    return{
        // 適当な要素
        hogeArray: [1, 2, 3],
        fuga: 1,
    }
}

以下のようなmethodは、意図通りに動作しません。TypeError: Cannot read property 'fuga' of undefined というエラーが出ると思います。

piyo() {
    let filteredArray = this.hogeArray.filter(function (value) {
        // 1だけをfilterする。→ここでエラー
        return value === this.fuga;
    });
    this.hogeArray = filteredArray;
}

正しくは、以下のように書く必要があります。

piyo() {
    const fugaValue =this.fuga;

    let filteredArray = this.hogeArray.filter(function (value) {
        // 1だけをfilterする。
        return value === fugaValue;
    });
    this.hogeArray = filteredArray;
}

thisは難しいということを初めて知った瞬間であります。 定義をちゃんと読んでみたいと思います。

thisの定義とは

いくつか参考文献を挙げます。

場所 thisの参照先
トップレベル（関数の外） グローバルオブジェクト
関数 グローバルオブジェクト（Strictモードではundefined）
call／applyメソッド 引数で指定されたオブジェクト
イベントリスナー イベントの発生元
コンストラクター 生成したインスタンス
メソッド 呼び出し元のオブジェクト（＝レシーバーオブジェクト）

Qiitaの記事が私にとっては一番わかりやすいです。

エラーとなったものは、関数パターンで、thisはグローバルオブジェクトを指していると思います。 正常なものは、thisは呼び出し元のVueオブジェクトを指していると思います。ふと冷静になるとなんでthisでいい感じに各プロパティが指せるんだという感想になりますが、ちょっと今回はおいておきます。

今回は解決方法が楽だったので助かりました。

追記

ドンピシャな記事を教えていただきました。

tadaken3.hatenablog.jp

読了『ライフ・シフト』

書評

各所で話題になっていたので読みました。

大事そうだなと思ったところをまとめます。

人生100年時代になる

表紙にあるように、人間の平均寿命は伸び続けているので、1991年生まれの私は100年いきてもおかしくないという状況にあります。

その場合、65歳でリタイアしようとすると、所得の何パーセントを貯蓄に回さなければいけないかという問題がありますが、かなり現実離れした値になってしまいます。*1

じゃあどうすんねんという話ですが、基本的には労働期間を伸ばすことになります。しかし、ひたすら働き続けると、自分の知識が古くなっていくので所得は下がっていく。それを避けるために、自己投資（リ・クリエーション）が大事だと述べられています。

感想ですが、所得が下がっていくかどうかはどのような仕事をしているかによる気がします。大事なのは、スキル向上にもならず、あまり価値のない経験しか積めていけないような仕事に就き続けないよう気を付けることだと思います。

無形資産の定義

現金や住宅などの有形資産との対比で、作中では無形資産が定義されています、以下の3つに分類されています。

  • 生産性資産
    • 仕事で成功し、所得を増やすのに役立つもの
    • スキルや知識など
  • 活力資産
    • 肉体的・精神的な健康と幸福
    • 健康・友人関係・パートナーや家族との関係など
  • 変身資産
    • 人生で大きな変化を遂げるために必要な資産
    • 自分について知っていること、多様性に富んだ人的ネットワークなど

作中では、これら無形資産についての話が多いです。

新しい人的ネットワークがキャリアを変える

人生を変えると言い換えてもいいかもしれません。

以下の一節は、僕に刺さりました。

しかも、意外なことに、人々は新しい職に関する情報を親しい友だちから聞くことはあまりない。そのような有益な情報は、たいてい友人の友人など、それほど緊密な関係にない知人から寄せられる。

まず、そういうチャンスがそれほど親しくない人からやってくるという心構えを持てました。さらに、チャンスがよく知らない人からやってくるとすると、それを受けるか否かを考えるのはかなり重い判断になります。なので、それを受ける以前から、どのような職だったらチャレンジしたいかという市場調査・自己分析が必要だと思います。

とはいえ未来は大変

作中を通しての雰囲気は、「100年人生を悲観する必要はないけどそこそこ頑張んないと大変だよ」という感じです。例えば、お金を稼ぐためにハードワークする時期が必要とも言っていますし、自分がどのような人間であるか、どうありたいかというアイデンティティにも向き合う必要があるとも言っています。

とりわけ、私にとっては後者が難題です。私自身アイデンティティ形成が容易な「3ステージ人生*2」を送ると信じて疑わなかったのですが、ここ5年程度でそれが難しいと分かって以降も再適合できてないような感覚があります。

おまけ

作中では何度か、「年に1回の2週間～5週間の休暇だけでは活力資産が損なわれてしまうよ」という記述がありましたが、私は会社員になってから2週間以上の休みはとったことないな……となりました。

*1:ちゃんと計算していませんが、10％や20％では済まない。実家暮らしだとギリギリ可能

*2:大学を出て、会社員として40年ほどを過ごし、引退して余生を過ごすモデル