【読書】情熱プログラマー ソフトウェア開発者の幸せな生き方 Chad Fowler著

f:id:munqu:20180430005213j:plain 

http://chadfowler.com/

 

目次

▼イントロダクション

 この本は自分のキャリアにおいて充足感と幸福感を得るためのものである。充足感と幸福感は偶然に得られるわけではない。

 たいていの人は他人の計画にばかり従っている。自分自身を差別化したいなら、まず立ち止まって自分のキャリアを見つめることだ。君は他人のではなく自分の計画に従う必要がある。

 

▼市場を選ぶ

 1.先んずるか、やられるか

 2.需要と供給

  技術スキルに対する現在の需要は?

 3.コーディングはもう武器にならない

  ビジネスの分野にも目を向けてみよう

 4.一番の下手くそでいよう

 5.自分の知性に投資しよう

  新しいプログラム言語を学ぼう

 6.親の言うことを聞くな

 7.万能選手になろう

  学ぶべきトピックを見つけ実践する

 8.スペシャリストになろう

  深く追求してみる

 9.自分の人生を他人任せにするな

 10.愛せよ、さもなくば捨てよ

  情熱を持てる仕事を探す

  日々のやる気を記録する

▼製品に投資する

 11.魚の釣り方を学ぶ

  「なぜ」「どうして」を考える

   完全に理解していない事柄について掘り下げて理解する

 12.ビジネスの仕組みを学ぶ

 13.師匠を探す

  尊敬する人の特長を10個あげて自分がそれぞれ何点か点数をつけてみる

 14.師匠になる

 15.一に練習、二に練習

  練習用のサイトを探してみる

 16.プロセスを大切にする

  ソフトウェア開発の方法論を学ぶ、短所と長所を考える

 17.巨人の肩の上で

  他の人のコードを読んで自分の力を思い知る

 18.自動化によって仕事を確保する

  モデル駆動型アーキテクチャについて学ぶ

▼実行に移す

 19.今すぐに

  いつかやろうと長い間放置されているタスクはないか?

 20.読心術

  ユーザやマネージャからの要求は?

 21.デイリーヒット

  いつも我慢している些細な問題を書き留める

 22.誰のために働いているのか思い出す

  マネージャの考えるチームの目標を知る

 23.今の職務を全力で

 24.今日どれだけうまく仕事ができるか?

  見える化する

 25.自分にどれだけの価値があるか?

  自分が給与に見合った働きをしているかどうか?

 26.バケツ一杯の水の中の小石ひとつ

  自分に依存している作業があれば書き留めておく

 27.保守作業の真価を知る

 28. 八時間燃焼

  定時に帰るのを想定して定時内みっちり働く

 29.失敗する方法を学ぶ

  間違いは起きた後の対処が大切

 30.できないことは「できない」とはっきり言う

 31.あわてるな

  パニック日記をつける

 32.言って、成して、示す

マーケティング

  マネージャや雇用主が自分の能力を見抜いているなんてことはない

  能力を売り込む(存在を知ってもらう、難題を解決できることを知ってもらう)

 33.視点が変われば認識も異なる

 34.アドベンチャーツアーガイド

 35.オレ、作文的なの得意っすよ

  開発の日誌をつける

  タイピングを磨く

 36.そこに居ること

  メールでのコミュニケーションを控える

  あまり話していないメンバーとの交流を図る

 37.スーツ語

  エレベータスピーチを考えておく

 38.世界を変えよう

 39.業界で名前を売ろう

  ブログを書く

 40.自分のブランドを築こう

 41.自分のコードをリリースしよう

 42.目立つこと

 43.コネを作る

  自分の好きなソフトウェアの作者に感謝のメールを送ってみる

▼研鑽を怠らない

 44.既に時代遅れである

  週に1度2時間程度は最新の技術について調査し実際に試してみる

 45.君は既に職を失っている

  他の役割のつもりで自分の仕事を進めてみる

 46.終わりのない道

  結果にばかり注目せずプロセスの質を高める

  さっさと終わらせようとするのではなく、その作業に注目してみる

 47.自分のロードマップを作る

  これまでのキャリアを振り返る

 48.市場に気を配る

  技術系ニュースに目を通しておく

 49.鏡の中の太った男

 50.南インドのサル捕獲トラップ

 51.ウォーターフォール式のキャリア計画

 52.昨日よりよく

  実行したい困難な改善または複雑な改善のリスト

 53.独立する

▼楽しもう

 

 

 

 

成長目標2018

1)

センスのいい画面が作れるようになったら楽しい

 デザインについて学ぶ

 HTML,CSS,JSなどのフロントエンド技術を学ぶ

 

2)

自分でウェブシステムをつくってサーバにデプロイできたら楽しい

 Spring Boot もっと覚える

 AWSかどこかにあげてみる

 

3)

問題をばしばし解決出来たら楽しい

 インフラとかも手を出してみる

 機械学習とかも目を向けてみる

 いろいろ自動化とかしてみる

 

4)

最終的になんでもできるようになったら最高に楽しい

 年収1,000万プレイヤー

 業界のトッププレイヤー

 

0)

現在地

 経験不足

 フットワークが軽くない

 手が遅い

 優柔不断

 

向かうべき方向

 こつこつ

 わくわく

 どんどん

 

夢中になる、没頭する

 

Mac で Windows

support.apple.com

Boot CampMacWindows を入れて作業しているがキーボードが違うのでいろいろ不便

 

 

<文字変換>

pc-karuma.net

ユーザ定義で

ひらがなにIMEオン

無変換にIMEオフ

を割り当てる

 

 

<F1~F12>

fn を押しながら

 

 

<delete/BackSpace>

detete(→を消す) fn + delete

BackSpace(←を消す) delete

 

<タッチパット(右クリック)>

pc-karuma.netデフォルトで2本指でトラックパッドをタップ

 

<スクロール>

2本指で↓にスクロールしたければ↓に

 

 

<その他>

appredmi.hateblo.jp

品質について改めて整理②

品質を高めるために行うことは


予防 

検知


1.まずいかにして不具合を入れないようにするかを考え(標準化)

2.次に不具合を入れないための対策がちゃんと機能しているかチェックしながら(レビュー)

3.成果物が出来たら本番稼動前までに不具合を可能な限り見つけては解消し(テスト)

4.本番稼動後はシステムが問題なく動いているかのチェックを日々行う(監視)



以下それぞれについて簡単にまとめ



1.

標準化の目的は成果物に作業した人による個人差が出ないようにすることで、作業の進め方(手順書の作成やツールの導入)や成果物(ドキュメントやソース)の中身についてルールを設ける。



2.

レビューの確認内容は検証(前工程と現工程の成果物の整合性)と妥当性の確認(ユーザの要求通りかの確認)で、目的はユーザの承認を得ることと不具合をいち早く検出することで手法は様々である。

特に会議体の場合、何のためのレビューかをはっきりさせないと、参加者の時間を無駄に奪うだけなので、何のためのレビューかをまずはっきりさせてから行う


アドホックレビュー

目の前の課題について周りのメンバーと非公式に相談する


ペアプログラミング

厳密にはアジャイルの開発手法だが、2人で1つのプログラムに取り組むことで、レビューで得られるような効果が得られる。技術や知識に差がある2人で行うなど


ピアデスクチェック

成果物の作成者とレビュアーの2人で完結する


ピアレビュー

解釈や定義は様々あるが、同じ得意分野の同僚によるレビューの意味で使われることが多い


パスアラウンド

成果物を回覧して多人数でレビュー。会議を設定して集まるより、各々のレビュアーが各自内容チェックすることが多い


チームレビュー

作業のキリの良いところで集まり、情報共有などを目的に行う。内容は教育や欠陥の発見など目的に応じて臨機応変に決める


ウォークスルー

成果物を作成した人が会議に参加した人に説明をして意見を求めたり、問題点をあげ、解決策を出してもらったりする


インスペクション

会議体で作成者、進行役、記録係、レビュー役を決め、各立場の参加者が集まり、成果物が標準化されているか?顧客の要望を満たしているか?前工程の成果物と矛盾がないか?などを正式に確認する



3.

テストの目的は欠陥の発見!手法はテストケースの作成方法、テストの実施方法それぞれで数多く存在する。


同値分割法

仕様から同じフローで同じ結果となる入力をリストアップして、出力を確認。正常系と異常系それぞれ考える


境界値分割法

同値分割法で分けた入力出力から結果が変わる境界となる値の上下のケースでテストを行う


異常値特異値分割法

仕様の点から特別なフロー対応が必要なケースのテストを行う


制御フローカバレッジ

主にツールを使って各フローを通る確認


データオブジェクトカバレッジ

プログラム中のオブジェクトの各状態(初期,参照中,削除後など)で正しい動作する確認


論理組み合わせテスト

複数入力パターンの組み合わせを考えてテスト。デシジョンテーブルなどを利用


状態遷移系テスト

有効な状態遷移、異常な状態遷移が正しく行われる確認。状態遷移図などを利用


その他

タイミングテスト

並行処理テスト

非機能要件のテスト

サンプリングテスト

探針テスト

統計的テスト

経験によるランダムテスト


尻切れトンボになってしまったが以上。


4.

監視は日々の業務が正しく行われていることを保守担当者がチェックシートなどにより確認したりと異常時に関係者にアラートが飛ぶように事前に設定しておく両面から確認


参考サイト

https://www.ipa.go.jp/files/000005144.pdf






























Spring frameworkの基礎

Javaフレームワークの主流の1つSpring framework


DI (依存性の注入)

AOP (アスペクト指向)


などが大きな特徴。


■DI (依存性の注入)で実現できることは


1画面表示,画面遷移を行う部品

2業務処理を行う部品

3データベースの読み書きを行う部品


を分けて管理


*それぞれの独立性を高めて、例えば2の業務処理の仕様を変えたいときに2だけ直して2だけテストすれば大丈夫、このとき3はmockと呼ばれるスタブのようなダミーの部品を利用する

EJBみたいなコンポーネント化して連携するより1と2、2と3をどうやって連携するかの仕組みをあまり考えなくてよい

*Singleton(オブジェクトが1つしか作られない)なので、同じ部品を同時に別のとこからも呼ばれたらどうしよう?とか心配しなくてよい


とかが便利なところ


interfaceクラスと実装クラスを作って、お互いの実装クラスは見えないようにすることで独立性を高める



AOP (アスペクト指向)で実現できることは


Javaオブジェクト指向では役割の塊ごとにオブジェクトという単位で分割してまとめるが、各機能を横断して共通して付与しなければいけない役割がどうしても残ってしまい、分割してまとめることが不十分

各機能を横断して付与したい役割を外出ししたのがアスペクト指向


*決まったとこでログに書き込む

*利用者の権限によるアクセス制御

トランザクション管理の標準化

*例外処理の標準化


などが主な例


これを実現するための方法が


アドバイス(外出しした横断して共通の処理をする部品)

ポイントカット(各機能でアドバイスを呼ぶ所)


を実装すること

Spring frameworkでは主にアノテーション(@〜をクラスやメソッドの前に記述)でこれを実現



Spring frameworkが備えている機能


DIやAOPを実現するだけなら他のフレームワークでも可能

Spring frameworkで用意されている機能はDIやAOPだけでなく他にもたくさんの機能が用意されている


IDE

  Spring Tool Suite(STS)

RAD

  Spring Roo

Starter

  Spring Boot

Web

  Spring Data Rest

  Spring Mobile

  Spring WebFlow

  Spring MVC

Security

  Spring Security OAuth

  Spring Secrity

Big Data

  Spring XD

  Spring Hadoop

Data Access

  Spring Data MongoDB

  Spring Data JPA

Batch

  Spring Batch

Enterprise Integration

  Spring Integration

Sosial

  Spring Social Github

  Spring Social Facebook

  Spring Social Twitter

Core

  Spring DI

  Spring AOP

  Spring TX

...


■Spring  Bootで簡単にSpring framework


開発者は各フレームワークの各機能を組み合わせてシステム開発を行っていたが、部品の選定や環境の設定などで開発者にはそれなりの知識が要求された

Spring Bootではあらかじめ一通りの機能が標準で盛り込まれており、面倒な準備をせず簡単に動くシステムを作れる

コンパイル、ビルド、デプロイというステップを踏まずに手軽に開発環境で動作の確認ができるのも利点