Jellyfish brain

大阪のフリーランスエンジニアの雑記

コーディング以外のシニアエンジニアに必要なスキルのリスト

コーディング以外のシニアエンジニアに必要なスキルのリスト シニア、スタッフ、そしてその先まで、さまざまなレベルに対応。

この記事の和訳 skamille.medium.com

  1. 会議を運営する方法。会議で最も多く話す人になることと会議を運営することは別物である。
  2. デザインドキュメントの書き方、フィードバックの受け方、適切な期間内に解決に導く方法。
  3. 技術的なアドバイスを必要としている新卒のチームメイト、中途採用のエンジニア、新任のマネージャーを指導する方法。
  4. バカにしたりせずに、よくわからない技術的な話をしたがるシニアマネージャーを満足させる方法。
  5. 理解していないことを率直に認めるのが恥ずかしい上級者に、技術的概念を説明する方法。
  6. 他のチームに自分のソリューションを使うように説得する方法。
  7. 他のエンジニアに何かをしてもらうために、感謝の気持ちを込めて助けを求める方法。
  8. プロジェクトのメンバーを管理していなくても、プロジェクトをリードする方法。
  9. 他のエンジニアに脅威を感じさせることなく、自分のアイデアを聞いてもらう方法。
  10. 脅威を感じずに他のエンジニアのアイデアを聞く方法。
  11. 他のことをするために、あなたが素晴らしいものに仕上げたプロジェクトを手放す方法。
  12. 自分が本当に大切にしていること(運用、正しさ、テスト、コード品質、パフォーマンス、シンプルさなど)を、他のエンジニアに教える方法。
  13. プロジェクトの状況をステークホルダーにどのように伝えるか。
  14. 些細な技術プロジェクトに投資する必要があることを経営陣に納得させる方法。
  15. ソフトウェアを構築しながら、その過程で付加価値を提供する方法。
  16. プロジェクトの提案書を作成し、それを社会に広め、実行するための賛同を得る方法。
  17. 人が耳を傾けるようになるために、自分の話を繰り返す方法。
  18. 戦う相手を選ぶ方法。
  19. 誰かが昇進するのを手助けする方法。
  20. 実際に起こっていることについての情報を得る方法(噂話やネットワークの作り方)。
  21. 誰かが持ってきてくれるのを待つのではなく、自分で面白い仕事を見つける方法。
  22. 相手に恥ずかしい思いをさせずに、自分もしくは相手が間違っていると伝える方法。
  23. ネガティブなフィードバックを潔く受け止める方法。

GCPについて(IAM, Resource Manager, Cloud API)

GCPについて

概要

Google Cloud Platform(GCP)は、Googleクラウド上で提供するサービス群の総称。Gmail, Youtube, Google map などのサービスレイヤーを支えるインフラレイヤーにあたる。

代表的なサービス

参考資料 : https://cloud.google.com/products?hl=ja コンピューティング、DB、ストレージとWeb開発に必要な機能を横断的に提供している。   Cloud IAM について

参考資料 : https://cloud.google.com/iam?hl=ja https://cloud.google.com/iam/docs/overview?hl=ja Cloud Identity and Access Management(IAM) 誰(ID)がどのリソースに対してどのようなアクセス権(ロール)を持つかを定義することにより、アクセス制御を管理する。つまり、特定のリソースに対してのアクションの実行を、承認されたユーザのみに許可する事ができる。 GCP Console, gcloud コマンド とGUI, CUI どちらからも管理可能。 細やかなロール管理可能。

参考画像 f:id:Nen_lin:20200529101928p:plain

単語、概念

メンバー:リソースへのアクセスが許可されている Google アカウント、サービス アカウント(アプリまたは仮想マシン)、Google グループ、G Suite または Cloud Identity ドメインの事。ユーザー、サービス アカウントまたは Google グループに関連付けられているメールアドレス、あるいは G Suite または Cloud Identity ドメインドメイン名がメンバーの ID になる。

ロール:ロールは権限のコレクション(纏めてbindされているイメージ)の事。権限によって、リソースに対して許可されるオペレーションが決まる。メンバーにロールを付与すると、そのロールに含まれるすべての権限が付与される。※ロール : 権限 = 1 : N (1 対 多)

ポリシー:Cloud IAM ポリシーは、1 つ以上のメンバーを 1 つのロールにバインドする。リソースに対してどのようなアクセス権(ロール)を誰(メンバー)に許可するのかを定義する場合、ポリシーを作成して、そのポリシーをリソースに接続する。

Cloud IAMは、RBAC(Role-Based-Access-Control)の概念のもと提供されるサービス。 RBACはMACDACの中間の概念。 MAC(強制アクセス制御) : 唯一のルール定義者がアクセス制御を決定する。 DAC(任意アクセス制御) : 一般ユーザが自由にリソースへのアクセス制御を行える。 Resource(リソース) : k8s クラスタVMインスタンス、Cloud strage バケット、プロジェクト、組織、フォルダなど広義に渡る...

Cloud Resource Manager について

参考資料 : https://cloud.google.com/resource-manager?hl=ja 組織、プロジェクトなどのリソースをグループ化して階層的にまとめる事が出来る。(GCPのコンソール画面 -> リソースの管理 で組織が持つプロジェクト、フォルダが表示される。) プロジェクトの管理、トラッキングが可能。

単語、概念  

Google Cloud API について 参考資料 : https://cloud.google.com/apis?hl=ja Google Cloud プロダクトにアクセスして、 GoogleAPIを使用できるAPI群サービス。 mirap-office では、Compute Engine API, Cloud SQL Admin API, IAM API など使っている。 料金体系はリクエスト毎とか、画像毎とかあるので公式リファレンスを参考にする。 単語、概念  

AWSと比較して

参考資料 : https://cloud.google.com/docs/compare/aws?hl=ja [IMO] プロダクトの名称は異なるが、どちらもWeb開発に横断的に必要な機能を提供しているので、AWSについてある程度知識がある人がGCPの知らないプロダクトに触り出す場合、概要を知りたい場合は ”GCP Firebase AWS ” とかで検索してみると良いのでは。

エンジニアの技術書は高い

Webエンジニアの皆さん 「技術書」って高いですよね...。

会社に属していたら会社の経費で買えたり、先輩から借りることもできるかもしれませんが、僕のようにエンジニアの友達がいない駆け出しフリーランスエンジニアだとそうも行きません。 ですので、ツテ0のエンジニアが技術書購入に至るまでのチェックポイント、様々な方法のメリット、デメリットを整理したので書いておきます。

  • 近所の図書館や、大学で読む

メリット:無料(これは強い)

デメリット:図書館が遠い場合がある(大阪なら西長堀の中央図書館が技術書の品揃えが良い。(遠い)) 行く気力が必要、その時間で勉強した方がマシ。 予約されていて、借りられない場合がある。 大学などは、外部の人間は借りられない場合がある。

技術書は自宅で、PCがある環境で読むのが1番良いと思います。

メリット:新品、その日から読める、職場の近くの本屋とかで昼休み、帰宅時に購入できる。

デメリット:高い。

  • メルカリで購入

メリット:少し安い。

デメリット:Verが古い場合がある、中古、欲しい本が無い場合がある。

  • Webで調べる

メリット:無料(ちょっと技術の概要を知りたいくらいならOK。)

デメリット:体系的に纏まっていない。正しくない事が書かれている場合がある。

  • 技術書の目的

技術概要を把握して、仕事で対等に会話出来るようにする事。 (信頼度UP -> 案件継続の可能性を上げる, 知的好奇心を満たす。) 詰まりPointを減らして、業務遂行スピードを上げる。(時給のUP)

  • 所感

技術書に関して、所有欲は少し敵だと思います。買って満足して読まなければ意味がありません。 そして技術書は高い買い物なのです。 その技術の分野のプロになりたい、しっかり把握したい場合はケチらずに購入するべき。 お金が無い学生さんは、金が無い事は仕方が無いので、工夫です。(図書館にリクエスト, 友人と折半, メルカリ)

僕の場合は、ガッツリ知りたい分野に関しては お金をケチらず潔く本屋で購入すべきですね!!!!!(経費で落とすといえどもあまりお金使いたくない)

  • Webの横断的な知識を持つために必要な本。

(e.g. Docker, Webサーバー, DB, Network...)

RBAC(ロールベースアクセス制御)について

  • 概要

組織内では、個人に対して様々な職務権限(役割:Role)が生まれる。 職務権限に沿って権限(Permission)を割り当て、 その権限に沿って個人のシステムの操作の許可をする仕組み。

  • メリット

ユーザ個人に対して1つずつ権限を付与するのではなく、複数の権限を一纏めにした ロールをユーザに付与する仕組みなので、アクセス管理の単純化が図れる。 会社など組織だとユーザの組織異動の際に効率的な対応が可能になる。 (新入社員に1個ずつ権限付与するよりもロール1つ付ける方が良い) 権限の管理が厳重になるので、秘密情報の漏洩など、事故が起きにくい。

  • デメリット

特に無いのでは...。

  • 注意点

GCP, Oracle Solaris, Azure 等多くのサービスで使われている概念だが、それぞれのサービスで名称が違ったりするので注意。

  • 参考サイト

エンタープライズロール管理解説書(第1章) 役割に基づくアクセス制御 (概要) - Oracle Solaris の管理: セキュリティーサービス

エンジニアの目標の立て方について

2020年やることリスト記事直近3ヶ月間の人生を振り返る会をやった

他の方の記事だが、上記の記事ではやりたい事リストとか、今年の目標とかがすごく纏まっている。 こういったエンジニアの方用のテンプレートになりそうなものって 今まであまりみたことが無かったので非常に参考になる。 特に投資とか、エンジニアリング以外の箇所も被っているところが多いので何だか読むだけでも楽しい。

前々から思っていたのだが、エンジニアで生活に困窮している人間を見たことがない。 ここで言う困窮とは、文化的な生活が保護されておらず、家賃滞納、明日の食物にも困っているレベルの人。 必ず、皆一定以上の水準の暮らしを行っている。 それどころか、上記の記事のように投資に興味があったり、次なる資格の取得や新たな成果物への創作意欲を持った 社会的に前向きなマインドを持った人間が多いと思う。どちらが幸福であるかは意見が分かれるところであろうが お金や何らかの志を持っていない人より、持っている人の方が心に余裕が出来ることは火を見るより明らかである。

GithubでCloneが出来なかった時の対処法

新たに参画したプロジェクトがBitbucketとかではなく、Githubを使ってソースの管理を行なっていました。その際Git Cloneしようとすると下記のErrorが...

 

エラー: remote: Repository not found. fatal: repository 'https://github.com/hogehoge/repository.git/' not found

 

・ 解決した方法

↓のBlogに答えがありました。

https://yoshiyoshifujii.hatenablog.com/entry/2014/08/12/230144

 

 僕のハマりポイントは、前職で作成していたSSHキーが ~/.ssh ディレクトリに既に存在していて、Sorcetree がそのキーを読みに行っていたからみたいです。

 

今回は新しくSSHキーを作成してそれをGithubに登録して事なきを得ましたが、

他にもユーザ名、PWを指定してCloneしたりとか(HTTPSリポジトリ をCloneする場合)

このErrorは複数原因、解決方法があるっぽいですね。

例:https://qiita.com/ponsuke0531/items/4fe191b7bed03342cff2

 

自分の状況に照らし合わせて1つずつ確認していきましょう。