思いやりでキャリアもアップ?

岩瀬大輔さんの入社一年目の教科書を読んだ。
 
全体を通したメッセージは相手の立場に立った行動と発言が大事だということ。
 
学生時代のような自分だけで完結する勉強であれば誰かを意識したインプットを必要とする機会はほとんどないが、仕事をする上での情報収集なり、勉強であれば常に相手を意識したアウトプット前提のインプットをするべき。
なぜならこのアウトプットによって周りの人の役に立てるし、何よりもそのこと自体が自分のためにもなるから。
 
この大前提があった上で、本書では3つの原則が述べられていた。
頼まれたことは必ずやりきる、50点でもいいから早く提出する、つまらない仕事はないの3つ。
 
といった上記の具合に世間の社会人の間では当たり前と言われているようなものばかりな印象(大学生目線)。
その後に述べられる50の項目も目新しいものがたくさんあるという印象ではなかった。
 
しかし、実際に全て完璧にやっている人はほとんどいないのではないかというような内容だった。
 
 
この本を読み終わって高校の部活の先生に言われた言葉を思い出した。
「当たり前のことを当たり前にやる。当たり前にやり続けるとそれに伴って当たり前の基準が上がっていく。そうなると同じ練習をやっていても結果が変わってくる。」
 
多くの人が当たり前だと言われているようなことを愚直にこなせる人がどんどん自分の中の当たり前の基準をあげるから周囲の人の期待値以上の成果を残せる。その結果周りの評価が上がったり、価値を生み出すことができるのかな。
 
 
この本によく似たトピックをちょうど昨日の大学の授業で習った。
 
専門スキルとコンピテンシーについて。
 
今、僕はエンジニアリングを勉強しているがこのような専門スキルは他の人に代替え可能しやすく、陳腐化もしやすい。現に技術発展が速かったり、起業の新陳代謝の高いIT分野に関しては他の業界に比べ、その要素が多いように感じる。
専門スキルに対する能力がコンピテンシー。これは高い業績に結び付く行動や思考の個人的な特性のこと。専門スキルに対して身につけるのに時間がかかる上、繰り返し発揮しなければならない一方、他の人とは違う普遍的な力のこと。
 
専門スキルを磨くことも大事だが、一緒に働きたいと思われることこそ社会人、いや自立した大人として生きていくために最も必要な要素の一つなのではないかと感じた。
つまり人間的な魅力を磨くことも仕事をする上で重要だということ。
本書ではそれをわかりやすく一言でまとめられていた。
 
 
「キャリアアップは人磨き」
 
 
ついつい「あ、なるほど!」といってしまった笑
 
 
 
このように、この本ではキャリアを通して自分の人間性を磨ける具体的な方法と考え方が随所に散りばめられている。
僕は大学3年生でこの本を読めてとても幸運なことだが、社会人になっても振り返って読める本なのではないかと思う。
人間的魅力は磨いても磨いても磨ききれないから。
 
 
巻末に紹介されていた男の作法という本が気になった。
今度はこれを読んで、ダンディな大人の男を目指そうっと笑

初めてのrubyでruby入門した

以前にruby on railsチュートリアルを一度やったが、rubyに関しての知識はほぼほぼゼロの中やってみた。チュートリアル自体はとても親切でアプリケーションができていく流れをうまく解説してくれてとても為になった。

 

しかし、再現しろと言われたら到底できないという。

 

そんな中で取り組んだ初めてのRuby

 

めっちゃわかりやすい!

PHPに関してはドットインストールやprogateでやったことがあるが、rubyはやったことがなかった。

Rubyという言語に関してわかりやすく解説してくれてる。

 

ruby on railsチュートリアルを見ていて不思議に思ったのがいろいろなところに::(コロン1つとかコロン1つとか)出てきて意味がわからなかった。

途中でシンボルに関する解説が多少あった気がするがそれでも疑問点は残った。コロン2つ登場することに対しての解説はもはや見当たらなかった気がする。

 

そのモヤモヤがこの本で取れた。

 

ちなみに、こちらのブログのrubyのスコープ演算子に関する解説がとてもわかりやすかったです

http://melborne.github.io/2013/09/24/rubys-scope/

 

 

もっとうまくRubyを使いこなして自分でサービスを作ってみたいと思える一冊でした。

 

 

 

 

 

 

 

チーム開発

TeamGeekを読んだ。
 
他のエンジニア本とは一味違った内容となっていた。
 
人間が人間に対してシステムを作るので人間に対して優しい労働環境を作ること、人間に優しいサービスを作る上で必要なことをどうすれば作れるかといった内容が優しい文章で書かれていた。
HRTの原則はチームで開発するときだけでなく、日常生活をしていく上で意識をすれば、より良い人間関係を構築できるきっかけになると思う。
エンジニアの人は人付き合いまでも合理的に考えられるのかと思い、よりエンジニアに対して魅力的に感じた。
 
ここまで相手にも自分にも理想的な人間関係を作ろうとできて、学習意欲も高く、ある程度収入も保証されている人たちなのに、なぜモテる職業第1位にランクインしていないのか不思議に思ったのも事実。
 
 
 
一人で作業すると失敗するリスクが高くなる。
より良いチームで生産的な開発、取り組みをすることが成功の大きな要因となることから、いいチームをいかに作っていくのかは重要な問題。
ここで重要となって来るのがHRTの原則。謙虚Humility 尊敬Respect 信頼Trustの三つ。
プロジェクトを進める過程で相手に批判をしなければならない場面があるはず。
そんな時に尊敬の念を持って謙虚に相手に指摘すればお互いに気分を害せずに仕事に取り組める。
 
またチームの方向性を保つのも重要になるのでミッションステートメントやコミュニケーションも重要。
ただし、コミュニケーションに関しては単なるミーティングを大人数で重ねるより、意思決定権のある数人で会議し、それを文書化したものをシェアするというようなものの方が効率的である。
 
マネージャーとして人と接するときは人を管理しようとするのではなく、サポートし、方向性を指し示すという要素を持つといい。
また、チームにとって有害だと感じる人の振る舞いがあったら、それを指摘する際にもHRTの原則が重要となる。
チームの一員として働く上で重要なことが責任の範囲を広げることとリスクをとること。そして小さく約束して大きく届けることも大事。これはユーザーに新しいプロダクトを届ける際にも言えることで、googleは新機能を予告なしにリリースするのでデスマーチをすることなくユーザーに嬉しい驚きを与えられる。
ソフトウェアはトースター。
ユーザーも人間なのでユーザーに集中すれば他のことは後からついて来ると言ったgoogleのモットーがあるように機能に対してこだわりを見せるだけでなく、第一印象をよくしたり、ユーザーの指摘の真意を見抜くことがサービスを広める上で重要。
 

サービス設計の基礎

webを支える技術という本を読みました。
 
普段使っているwebに関して知らない知識がたくさんあった。
使っているけど知らないことがこんなにあるなんて。それほどWebというものが便利ということなのかもしれない。
 
例えるなら自動車を運転することはできるけど、自動車の仕組みは知らないみたいな。
 
だから、この本ではwebで使われているものの仕組みが学べる。
そして、最後の章ではwebサービスを作るときに必要となるwebの設計の知識が述べられている。
以前にデータベース設計に関する本を読んだが、いろいろなところで設計してからサービスは作られるのだと感じた。
実際の現場ではネットなどで、ホワイトボードにポストイットをたくさん貼って会議してたりする画像を見たことがあるがあのような会議でペルソナ設定、データベース設計、サービス設計が行われていくのではないかと思う。
とにかく
 
 
web…webサイト、UI(ルーター、テレビ、プリンタ)、WEB API
webはHTTPというプロトコル(約束事)の元、URIでリンクを介して、HTMLが表示されるという関係で構成されている。
インターネットでこれだけWebが広がったのは以前の閉じたネットワークを構成していたRPCに比べ、必要最低限のリンク機能が簡単かつ拡張性の富んでいたから、多くの人に使われることになったから。
また、RESTというアーキテクチャスタイル、Ajaxという技術によるUIの向上によりWebがより広まった。
RESTの重要な概念としてリソース(URI)がある。リンクをたどるだけでサイトに到達できる簡単さが魅力。
URIとURLはほぼ同義語。URIは誰からでも簡単にアクセスできるように、言語に依存せず、実装依存のパスを使わず、そのページを表すわかりやすい名詞を用いる。
 
HTTPはTCP/IP(ネットワークプロトコル)をベースに作られている。
アプリケーション層
クライアント側でリクエストをサーバー側に送り、レスポンスするという仕組み。
ステートレスなので、必要な情報はクライアント側に含まれていてシンプルな反面、送信するデータ量はステートフルに比べ多くなる。
 
HTTPメソッド
リソースの...
GET 取得
POST 作成、追加
PUT 更新、作成
DELETE 削除
HEAD ヘッダ情報取得
OPTIONS メソッドの取得
べき等性…何回操作しても同じ処理
安全性...リソースの状態を変化させない
POSTはべき等でも安全でもない。だからクレジットカードの支払いとかをネットでする時にボタンを2回押さないでくださいって出る!
 
1...処理中
2...成功
3...リダイレクト
4...クライアントエラー
5…サーバーエラー
 
HTTPヘッダの仕様は電子メールメッセージの仕様と似ている。
日時、文字エンコーディング、メディアタイプなどの情報があり、HTMLのheadタグみたいだなと感じた。
basic認証…ユーザー名とパスワード
digest認証...パスワードを暗号化するのでbasic認証より安全。
 
キャッシュ…ローカルストレージに蓄積されるデータ、その手法。
 
XML木構造。HTMLよりシンプルな構造
HTMLはヘッダにメタ情報、ボディに内容
メタデータをHTML内に埋め込めるのはmicroformatsという技術があるおかげ。
HTTP、URL、リンクによりWebが成り立つのでリンク構成は重要
JSONXMLより軽量なjavascript記法のデータフォーマット
不特定多数のドメインのサーバーにアクセスすることをクロスドメイン通信
JSONPの機能により、この不都合が解消されるためAjaxには必須。
 
AtomRSSフィードなどに使われている技術でXMLフォーマット。基本的なメタデータを持っている。
エントリリソース->メンバリソース->コレクションリソースの順に粒度が高くなる
 
コレクションリソースがいわゆるフィード
Atomでデータフォーマットを作り、AtomPubというプロトコルにより基本的なメタデータのリソースをCRUDする。
 
リソース設計…webサービス、web apiの外部設計。どちらも同じように考える。
 
リソース指向アーキテクチャ
1、webサービスで提供するデータを特定
2、データをリソース分け
3、リソースにURIで名前付け
4、クライアントに提供するリソースの表現を設計
5、リンクとフォームを利用してリソース同士を結びつける
6、イベントの標準的なコースを検討
7、エラーについて検討
 
1、2の段階で何にリソスとして名前を与えるのか判断しづらい場合があるのでそれに対する他の手法が存在する。
ER図を用いる関係モデル...データの持つ階層構造、トップレベルリソースの存在
オブジェクト指向モデル...トップレベルリソースの導出はできない。詳細な情報を含む(関係モデル比)
情報アーキテクチャからの導出...リソース指向アーキテクチャのデメリットを補完できるがこれだけではwebサービス設計は完了しない。

エラー対処続き

deploybotのエラー対処の続き
まず、deploybotからさくらのレンタルサーバーFTPでファイル転送するのでPORTは20(ftp-data)または21(ftp)。
実際にファイル転送してみるとdeploybotではエラーが出るもののPORT21の場合はログイン履歴にログが残されている。
なのでPORTは21で良さげかな。
 
deploybotでファイル転送できない時にサポートページがあったのでこれを見た。
check permissions on your ~/.ssh/authorized_keys fileとある。
 
さくらのauthorized_keys?
 
さくらのレンタルサーバーに対してSSHの設定は一切していなかった。
そこで以下の記事を参考にSSH接続を試みる。
上記の操作はうまくできた。
ただ、最後に ssh sakuraとする部分で
 Could not resolve hostname sakura: nodename nor servname provided, or not known
と表示されたが、以下のコマンドでログインすることに成功。
 
$ ssh -p 22 アカウント名@初期ドメイン
 
 
無事、さくらのレンタルサーバーSSH接続が完了し、deploybotでtry againしてみると、またエラー。
今度はさくらのサーバーコントローラパネルからアクセスログの設定>エラーログでエラーログを見ると、
 
[error] [client 106.184.21.117] Directory index forbidden by Options directive: /home/hogehoge/www/
 
と書いてある。
 
Directory index forbidden by Options directiveがわからなかったので調べてみるとindex.htmlとかindex.phpがないですよというエラーらしい。実際にアップロードしたいフォルダにはindex.phpが含まれているので他の原因があり、それが.htaccess
Options -Indexes
Options +Indexesにするといいらしい。
 
vimでファイル内容を書き換えてみると
それまでforbiddenだったのがパスが現れた。なんか自分がしたかったことと違った。
これも違ったので戻す。
 
全然デプロイできん。何がいけないんだろうか。。。

gitのチュートリアル

git のチュートリアルを読んだ。

基本的な概要は掴めたかと思うが、いかんせんgit initとかgit commitといった基本的な部分しか知らなかったのでまだまだ使ってイメージを膨らませてみないとわからないといったところ。(git stashの使いどころとか)

図のイラストがところどころあったので、わかりやすかった。

 

以下、勉強した内容のメモ

gitのバージョン管理を開始するためのsubdirectoryを作成。

同じディレクトリでコマンドを打っても、上書きされず、新規に作られる。
git init

git cloneとの違い
git cloneはgit initしてリモートからそれをコピーする。

commitできない、編集できないディレクトリ。(storage facilityなど)。
pushとpullだけできるディレクトリ。
git init --bare <directory>

ex) ssh <user>@<host> cd path/above/repo git init --bare my-project.git

git initしてtemplate_directoryからファイルをdirectoryにコピーする。
git init <directory> --template=<template_directory>


git initのオプション
warningほどの重要なアラートだけ表示
--QUIET
bareレポジトリ作成
--BARE
テンプレートディレクトリからコピー
--TEMPLATE=<TEMPLATEDIRECTORY>
.gitファイルを他のフォルダへ移動したい
--SEPARATE-GIT-DIR=<GIT DIR>
レポジトリのアクセス権を設定
--SHARED[=(FALSE|TRUE|UMASK|GROUP|ALL|WORLD|EVERYBODY|0XXX)]

ex)git init --bare /path/to/repo.git
git init /new/repo/path --template=/absolute/path/to/template \


すでに存在しているリポジトリをコピーする
git clone

ex)git clone ssh://john@example.com/path/to/my-project.git
cd my-project
# Start working on the project
ローカルのrepoにtagのファイルだけをコピー
git clone -branch <tag> <repo>

git cloneのオプション
clone元の指定したブランチの内容をclone
-branch
ex)git clone -branch new_feature git://remoterepository.git

pushとpullはされるディレクトリのclone。
git clone --bare

--bareの要素プラスrefの内容もコピー。
git clone --mirror

gitのURL
ssh ssh://[user@]host.xz[:port]/path/to/repo.git/
git git://host.xz[:port]/path/to/repo.git/
http http[s]://host.xz[:port]/path/to/repo.git/

gitの情報設定
git config

--local
--global
--system
の順に設定範囲が広くなる。何もつけなければ--localと同じ範囲。

git config --global user.email "your_email@example.com"

mergeする際に衝突しないかチェックするためのツール
git config --global merge.tool kdiff3

ショートカットキー作成
git config --global alias.ci commit

変更をworking directoryからstaging areaへ追加する。変更はcommitの段階で記録される。
git add

staging areaの内容を記録する。
git commit
メッセージ付き
git commit -m 'メッセージ'
全てをコミット
git commit -a

ファイルを一時的に隠す
git stash
メッセージ付きでstash
git stash save "add style to our site"
stashのリストを見る
git stash list
stashの一部を削除
git stash drop stash@{1}

gitの管理に含まないファイル
.gitignore

git statusとgit logでレポジトリの状態を見る
git statusはworking directoryとstaged areaでどうなっているかの状態
git logはcommitされた記録を調べる

バージョンを元に戻したり、ブランチを変更
git checkout
masterブランチに変更
git checkout master
指定されたコミットまで戻る
git checkout <commit>
ex) git logでcommitされた内容を見て、先頭にあるIDで
git checkout a1e8fb5のように指定

commitを打ち消すような逆のcommitをする
git revert
変更を取り消すメソッドの似たものにgit resetがあるがこちらはオリジナルのコピーは作れない。

追跡されていないファイルの削除
git clean

直前のcommitを修正する。commitしてすぐaddした後に小さな変更なので直前のコミットにまとめたい時など。
git commit --amend
コミットメッセージなし
git commit --amend --no-edit

ブランチをmasterブランチなどに結合する。直線系のhistoryになるが、history自体も変更されるのでpublic historyでは使わない。
git rebase

過去のあらゆるcommit履歴を参照できる
git reflog

他のリポジトリとの接続の作成、内容確認、削除を行う
リモート接続の一覧をURLと一緒に表示
git remote -v
リモートリポジトリに対して新規接続
git remote add <name> <url>
ex) origin に加えて他の開発者のリポジトリへの接続を作成
git remote add john http://dev.example.com/john.git

リモートレポジトリからローカルレポジトリにブランチをインポート。リモートブランチとして保存。
git fetch
ローカルリポジトリを中央リポジトリのmasterと同期
git fetch origin

中央リポジトリのmasterのcommit状況を調べる
git log --oneline master..origin/master
masterにブランチを移動し、mergeすれば中央リポジトリとの同期が完了
git checkout master
git merge origin/master

git fetch + git merge ローカルリポジトリを中央リポジトリに同期する簡単な方法。
git pull
他の人の作業を全て終えた後の状態から同期する。
git pull --rebase origin

git fetchの反対で、ブランチをリモートリポジトリにエクスポート。ローカルな作業を中央レポジトリに公開する時に使われる。


プルリクエスト...他の開発者に自分のブランチをプルするようリクエスト。
他の開発者と作業する時にはまずフォークする際に自分の作業ブランチを作成し、それをオリジンにpushする


中央管理型ワークフロー...
誰かが中央レポジトリを作成し、全員が中央レポジトリをクローンする。
それぞれがプッシュする際には必ず中央レポジトリの変更をプルしてから出ないと競合が生まれるのでプル必須。

フィーチャーブランチワークフロー...
全てのfeatureブランチを別々に。
masterブランチに変更を加えずに、featureを他の開発者と共有。

gitflowワークフロー...
masterで公式バージョン。developで開発されたもののmerge。
releaseでリリースできるものをdevelopから分岐。hotfixで緊急のメンテナンス。
featureで新機能の開発。

forkワークフロー...
開発者が公式リポジトリをフォークしそれをクローン。
ローカルでそれぞれ開発し、featureを公開すると一人がそれらを統合。
それを開発者はプルしていくという流れ。

綺麗なコードって?

リーダブルコードを読んだ。
 
プログラミングをする上で綺麗、汚いということはネット上の情報を通してみてもよくあるけど、実際に素人目線でいうと何が汚いか綺麗かの区別ってわかりづらい。見た目で整列されていたり、段落分けされていたら理解しやすいけど場合によってはわかりやすい構造にすればパフォーマンス自体も上がることは一石二鳥だなと感じた。
これからプログラミングの学習を進めていく上でこれらのtipsを意識して使っていきたい。
 
以下、学んだアウトプット。
 
理解されやすいコードは一緒に作業する人のためだけでなく、将来の自分のためにもなる。名前に関しては、自分の意図が正しく理解され、簡潔なもの。
 
そのためにコードを書く際には関連した内容をブロック化し、段落と整列で読みやすくする。これは見た目だけでなくコードの構造も改善することもある。
また、誰にでも分かりやすいようにコードを書き、コメントを書くことが重要。
 
コメントをする際には読み手のことを考えて読み手の立場に立ったコメントをしたり、不必要なコメントは避ける。場合によっては自分の考えや注意点などを書き添えると分かりやすくなる。
 
説明変数は大きなコードを理解する上でキーとなって来るので積極的に活用すべき。
ド・モルガンの法則は条件分岐で有効な考え方だが、do/while文、三項演算子、gotoを使うとコードが読みにくくなる(代替え案を推奨)。
 
変数を作成する際には、スコープを縮めて変数の内容がどこに書いてあるのか分かりやすくすると良い(ex. Javascriptだとvarで宣言して変数を定義しないとグローバルスコープになって分かりづらくなる)。
1次変数や中間変数のような邪魔なものは削除。
 
コードを書いていく際にプロジェクトの固有のソースから汎用的に使えるコードを見つけると再利用が可能になり、便利。たくさん作るとそれだけ手間が減るが、やりすぎは逆にコードを見づらくする。
 
コードは一つずつタスクを行なっていくので読みにくいコードがあれば、その部分のタスクを全て列挙し、分割する。問題の分割はコーディングにおいて有効である。
コードは小さくまとめると良い。
 
テストコードを読みやすくするために、小さなテストコードを複数記述したり、名前は長さよりも分かりやすさ重視にしたりする。
テストしやすいようにコードを設計するのも手。