どぶどぶエンジニア備忘録

アプリケーションエンジニア3年生です!働いて得た知見や読んでためになった本の紹介をします。

業務でよく使うコマンドの紹介

コマンド紹介

業務で頻繁に使用しているLinuxコマンドなどを紹介したいと思います。 MacまたはLinuxOSを使用している人が対象になります。

ファイル検索

find <ディレクトリ> -name <パターンマッチ>

例:hoge.txtの所在が全く分からないとき

sudo find / -name *hoge.txt*

sudo権限があるという前提ではありますが、ルートディレクト/を指定しつつパターンマッチにワイルドカードを使うことで全ディレクトリを対象に検索することができます。

テキスト処理

結果のフィルタ

catやlsコマンドなど、結果から特定の文字列を含むものを抽出したいときに便利です。

cat <ファイル> | grep <文字列>
ls <ファイル> | grep <文字列>

-vオプションをつけることで特定の文字列を含まないようにすることもできます。

cat <ファイル> | grep -v <文字列>

特定のデバッグログを抽出したいときに便利です。

JSONを整形して見やすくする

JSON(JavaScript Object Notation)とはJavaScriptのオブジェクト記法によるデータフォーマットです。 メジャーなデータフォーマットでバックエンドのAPIなどでよく使われています。 下記はJSONによるデータフォーマットの例ですが、データ量が増えると当然複雑になりやすいです。

{"hoge":{"huga": "test"}, "hogehuga": ["test", "example"]}

ターミナル上でファイルやcurlの結果などからJSONを読み込む際に上記の様な一列だと見づらいのでpython -m json.toolコマンドをパイプラインで繋げることで見やすくすることができます。 このコマンドの利点としてはMacLinuxに標準でpython2がインストールされているためすぐに使えるという点です。

cat <JSONファイル> | python -m json.tool
curl -X GET http://example.com/example.json | python -m json.tool
{
    "hoge": {
        "huga": "test"
    }, 
    "hogehuga": [
        "test",
        "example"
    ]
}

logファイルをリアルタイムで見る

動作確認などでlogファイルの出力をリアルタイムに確認したい場合lessコマンドを使うと便利です。 Ctrl+cを押すと通常のlessコマンドと同様のモードに戻ることができ、大文字Fを入力すると再度入力待ち状態にすることができます。

less +F <ログファイル>

ssh_exchange_identification でリモートに接続できない問題の原因と対処

みなさんはsshコマンドを使ってサーバに接続しようとした際にssh_exchange_identification: connection closed by remote hostというエラーが表示された経験はないでしょうか。

今回はそのエラーが発生する大まかな原因とそれ毎の対処方法について述べていきたいと思います。
以下、接続元となるPCないしはサーバをローカル、sshで接続したい先のサーバのことをリモートと呼びます。

 

ssh_exchange_identificationとは何か

接続先が存在しない、またはセキュリティ違反によってリモートに接続できない場合に発生するエラーです。このエラーが発生しうる原因と対処について述べていきたいと思います。

 

ssh_exchange_identification: connection closed by remote hostの原因

リモートの情報が変更されてしまった場合

以下の様なメッセージが表示されている場合、リモートの情報とローカルに記録されたknown_hostsファイルの情報が異なっている可能性があります

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

known_hostsファイルとは何か

known_hostsファイルにはfingerprintと呼ばれる情報が記録されており、過去接続したことのあるサーバのIPアドレス、公開鍵、鍵の暗号方式が記録されています。

sshの際には単にリモートのホスト名だけではなく、これらの情報と合わせて識別を行っており、名前の通り指紋の役割として働いています。

何らかの理由により、fingerprintが異なる場合 REMOTE HOST IDENTIFICATION HAS CHANGED! というエラーが出るというわけです。

fingerprintが古い場合の対処

known_hostsに記録されたfingerprintが変わってしまう原因としては、サーバが再起動したことによってDHCPによりIPアドレスが変わったり、OS再インストールによって公開鍵が変わったりと様々です。

リモートの情報が変更された理由に心当たりがある場合は以下の2つの方法で対処が可能です。
原因に心当たりがない場合はなりすましの可能性があるので注意が必要です。

known_hostsに記録されたfingerprintを削除する

リモートが更新された原因に心当たりがあるなら直接fingerprintを削除してしまって問題ありません。

vim ~/.ssh/known_hosts

以下のsedコマンドを使って削除することも可能です

sed -i '/リモートのホスト名/d' ~/.ssh/known_hosts
警告を無視する

-o 'StrictHostKeyChecking no'オプションをつけることで無視することができます。shellやpythonなどのスクリプトから接続している際にはかなり有用ではありますが、万が一なりすましの場合セキュリティ上のリスクはあるので注意が必要です。

ssh -o 'StrictHostKeyChecking no' リモートのホスト名


リモートからアクセスが禁止されている場合

以上fingerprintが変更されている場合について説明いたしました。そのほかにもsshd(ローカルからのssh接続を受け持つデーモン)やdenyHostsというセキュリティツールで禁止されている可能性もあります。
接続先の/etc/hosts.denyにローカルのIPアドレスがないか確認が必要です。

vim /etc/hosts.deny
# denyhostsの場合
systemctl restart denyhosts # sshdの場合
systemctl restart sshd

まとめ

今回はssh_exchange_identification: connection closed by remote hostのエラーとその原因・対処について紹介いたしました。

 

エラーの原因と対処

  • リモートのfingerprintが変わったため:fingerprintを削除する
  • リモートから拒絶されているため:リモートサーバの接続設定を見直す

 

本の要約サイトflierを使ってみた感想

今回は息抜きとして本の要約サイトflier使った感想を述べたいと思います。

 

flierはビジネス書や教養書の要約を読むことができるサブスクリプション方式のサービスです。

コースは3種類あり、無料コースと有料コース2種になります。

  • 無料コース                  無料で読める要約のみ閲覧可能
  • シルバープラン           500円 一月に有料要約が5冊
  • ゴールドプラン           2000円 無制限に読める

www.flierinc.com

使おうと思ったきっかけ

単純にインプットの量を増やしたいと思い使ってみました。

自分は技術書に限らずビジネス書なども勉強のために読むことがあるんですが、なかなかインプット量を増やせずにいました。

  • 良著として知られているような本しか読まない
  • 技術書よりも優先順位が低い
  • そもそもの読書量が少ない

知らない概念に出会えたらいいな~セレンディピティが得られると良いな~ぐらいの温度感です。

使ってみた感想

1か月ほどゴールドプランを利用してみましたが、1か月キリよく使って十分満足かなと感じました。

セレンディピティを得たいぐらいのモチベーションだとメリットがデメリットやコストを上回ることはないかな~という結論に至りました。

メリット
  • 10-15分で読み終えられる
  • 取り扱っている書籍数が多く範囲も広い

メリットとしては、喧伝されている通り10-15分ぐらいで1冊読み終えることができる点と、取り扱っている本の豊富さにあると感じました。

flierで読める本は約2000冊ほどだそうです。使ってみた印象としては、名著とされているものは大抵あるかなと感じました。思考の整理学やOKRの本やHARD THINGSなど、自分が好きな本(笑)はカバーしてくれていて安心しました。

一方で、自分があまり手に取らないような芸能人のエッセイや社会現象を使って説明しているような教養書なども充実していました。普段手に取らない本を、時間・金銭面でローコストで読めるというのは強みとしては十分じゃないでしょうか。

デメリット
  • 要約者によって品質に差がある
  • 本一冊につき要約者が一人
  • プランの料金が高め

要約者によって品質の差があるように感じました。読みやすい人はすらすら読めますが、そうでない人の場合は読みづらく尚且つ頭に入りづらいとさえ感じました。

2点目ですが、本一冊につき要約者が一人なのは少し不満に感じました。読み手のバイアスを考慮すると、2人はいると嬉しいなと感じました。せっかく要約者のプロフィールも書かれているわけですから、要約者のバックボーンも加味しつつ要約文の取捨選択や比較ができると面白そうに感じます。

3点目の”プランの料金が高め”ですが、これは単にセレンディピティぐらいの目的を満たすにはちょっと高いなと感じました・・・。

とはいえ、読みたい本が明確なユーザにとっても2000円はちょっと高いんじゃないかなと感じます。速読派で尚且つ選り好みしない読書家に適したサービスかもしれません。

 

まとめ

  • 本要約サービスflierを紹介
  • 2000冊のビジネス書・教養書の要約を読むことができる
  • 無料コースと有料コース2種の3つのプランがある
  • 本は流行りから名著まで網羅されている印象
  • 要約者によって品質に差があり
  • 速読派で本を選り好みしない人に向いてそうという印象

新卒エンジニアにお勧めしたい本 5選

今回はエンジニアになりたての方に向けて本を紹介していきたいと思います。

情報系の大学やオンライン学習コースで勉強してきたけど会社での開発を知らない、ギャップが気になる、という方を対象とした記事になります。

自分の仕事場での経験や観察上、組織論やコミュニケーション関係の課題のほうが比重としては大きく、かつ学生時代はなかなか意識できない部分が大きいかなと思いました。なので、以下の5冊を紹介したいと思います。

ストレングスファインダー

まず紹介したいのはこちらの『さあ、才能に目覚めよう』という本です。これは”本”というよりは”自己診断ツール”になります。同封されているシリアルコードを使うことでWebサイトで自分の強みを診断することができます。

 

思考力・人間関係力・影響力・実行力の4つのカテゴリから成る34の資質のうち、強みの資質上位5つを知ることができます。

新卒エンジニアにオススメしたい点

仕事をしていくうえで自分が何に優れていて、何に取り組むのが苦手なのかを知っておくだけで働きやすくなります。

自分の場合は学習欲が最下位で、必要性のないものを学ぶことが苦手だそうです・・・。必要に応じて、トップダウンに学んでいこうと決意しました。

Team for geek

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

 

2冊目は『Team for geek』です。

内容としては、チームが円滑に仕事を進める上で必要な考え方や、習慣づけるべきことについて書かれています。具体的には、”メンバーは互いにHRT謙虚・尊敬・信頼の気持ちで接しましょう”といったものが書かれています。

 

新卒エンジニアにオススメしたい点

誰か一人が知っていればいい内容というよりは、メンバー各々が意識しなければ成り立ちにくいということもあるので2冊目にこの本を挙げたいと思います。

ロジカル・シンキング

ロジカル・シンキング Best solution

ロジカル・シンキング Best solution

 

3冊目に紹介したいのはこちらの『ロジカル・シンキング』という本です。

物事を正確に相手に伝えたり、抜け漏れなく考えるために必要な観点とそのテクニックについてまとめられた本です。

新卒エンジニアにオススメしたい点

チームとして働く以上、仕事の説明を聞いて行動に移すために”考える”・疑問や成果を”伝える”といったことは必須になります。

書かれていることは然も当たり前のように思いますが、相手のレイヤや専門が違うだけでコミュニケーションがグッと難しくなります。相手の立場になってコミュニケーションを行うことの重要さについて説いているこの本を特にオススメしたいです。

エンジニアリング組織論への招待

4冊目に紹介したいのは『エンジニアリング組織論への招待』です。開発現場を取り巻く不確実性についてと、それをどう軽減していくかがテーマの本です。

端的に言うと、チームが健全に開発を進めていくうえで障害となりうるものが何か、どう対処していかなくてはならないかについて書かれた本になります。

新卒エンジニアにオススメしたい点

読んだ雑感としては、テーマが”不確実性”と抽象的なこともあってか、開発における問題を多角的に捉えている本だなと感じました。また、他の組織論の本などをかなり引用している印象を受け、この一冊で完結しているように思います。

最初に挙げた3冊の学びなおしや補完という意味合いも込めて4冊目に挙げたいと思います。

ユーザーストーリーマッピング

ユーザーストーリーマッピング

ユーザーストーリーマッピング

  • 作者:Jeff Patton
  • 発売日: 2015/07/25
  • メディア: 単行本(ソフトカバー)
 

5冊目は『ユーザーストーリーマッピング』です。この本はアジャイル開発現場で起こりやすい問題、そしてその解決のための糸口について書かれています。

読者の主な対象はアジャイル開発を行っているPM/PO(プロダクトマネージャ/プロダクトオーナー)ではありますが、メンバーレベルでも課題となりうる事柄についてまとめられているという点と、1個上の立場のビューポイントを先んじて学んでおくと良いという点からオススメしたいです。

本の内容としては、アジャイル開発のサイクルを回していくうえで直面しやすい問題についてと、目的を見失わないためのフレームワークであるユーザーストーリーマッピングの実践方法について書かれています。

新卒エンジニアにオススメしたい点

この本で挙げられているような問題に陥っていることにそもそも気づかず、事態が悪化してから気づくことは多々あります。なので、まずは現象として知っておくメリットは大きいかなと思い挙げました。

 

まとめ

今回は新卒エンジニアに向けて組織論やコミュニケーションに関わる5冊ほど本を紹介しました。

- ストレングスファインダー

- Team for geek

- ロジカル・シンキング

- エンジニアリング組織論への招待

- ユーザーストーリーマッピング

 

次回は、Javaエンジニアや分散システムエンジニアに向けた本紹介をしたいと思います!

コンウェイの法則とはなにか

コンウェイの法則(Conway's law)についてご存知でしょうか。

 

システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう

 

といったもので、大抵はネガティブな意味合いで引用されています。

引用している本を2冊ほど紹介しつつ、実体験とその本質について話していきたいなと思います。

 モノリスからマイクロサービスへ

モノリスからマイクロサービスへ ―モノリスを進化させる実践移行ガイド

モノリスからマイクロサービスへ ―モノリスを進化させる実践移行ガイド

  • 作者:Sam Newman
  • 発売日: 2020/12/26
  • メディア: 単行本(ソフトカバー)
 

この本では、3層構造のアーキテクチャのようなサイロ化を促しやすいという説明に用いられていました。

FEチーム、BEチーム、DBチームと組織上分かれてしまっていると、機能追加などのコンポーネントをまたぐ変更をすぐに提供できないというデメリットがあります。

柔軟さの欠けるアーキテクチャを生み出しかねないということの説明のために、割と言葉通りの意味で使われている印象でした。

 

 エンジニアリング組織論への招待

この本では少しブレークダウンした紹介がされていて、コンウェイの法則の本質は”コミュニケーションコスト”である、と書かれていました。

コミュニケーションコストの低いところから開発が進みやすいので、結果としてシステムのアーキテクチャにも大きく影響を与える、というのがこの本での主張でした。

 

両者の違い

前者はシステムアーキテクチャ設計に関わる本で、後者は組織論の本であるため、結果”引き起こされる現象”がなんなのか、”どう対処”しなくてはいけないのかの説明が違いました。

ただ、引き起こされる原因については一緒で、コミュニケーションコストこそが本質なのだと思います。

 

コンウェイの法則”の実体験

組織構造について

自分のチームではマイクロサービスと呼べるほどの単位ではありませんが、依存するPFは同じ部ないしはチームに集約されているのでコミュニケーションコストは小さいのかなと思います。

なので、機能追加やDB側の変更も特に苦ではなく『モノリスからマイクロサービスへ』に挙げられるような課題はクリアしていると思っています。

チームを機能単位で集約しようという試みは”逆コンウェイの法則”と呼ばれ知られている通りで、何よりも先に実践すべきことなのかもしれません。

 

コミュニケーションについて

では組織構造だけを変えれば解決かというと、自分としては少し疑問に感じます。

自分のチームでは昨今のコロナの状況もあり、リモートワークが主体になりました。

結果としてチームメンバー間の意思疎通が取りづらくなり、コミュニケーションせずとも進められるところを先に取り組んでしまった結果、手戻りが発生したり責務が不明瞭になってしまった経験があります。

なので、個人的には『エンジニア組織論への招待』での抽象度の高い表現がしっくりくると感じていて、単に組織構造だけを変更するのではなく、コミュニケーションを行う単位や節度にも目を向けてあげる必要があるように思いました。

 

まとめ

- コンウェイの法則

  - システム設計の構造は組織構造に影響されやすい

- 逆コンウェイの法則

  - システム設計のために組織を作る

- 法則の本質はコミュニケーションコスト

 

Hello world!

自己紹介

はじめまして、hichewといいます。

大学・大学院ではHCIの研究を行っていました。

現在は就職し分散システムの開発運用を行っています。

 

書きたいこと

  • 業務上役に立った技術書の紹介
  • 開発で使っているツールやTipsの紹介

基本的にはエンジニアリング関係の話題についてで、実体験を交えながら書いていきたいなと思います。

折角得た気づきもすぐに忘れてしまいがちなので・・・どちらかというと本人の備忘録的な使い方になりそうです。

息抜き程度にエンジニアリングと直接関係はない事柄も紹介できたらなと思っています!