よく使うGitのコマンド

Gitはよく使っているのですが使いこなすのは結構大変ですよね。

いつも使っている初心者向けのコマンドをまとめておきます！

まずはGit bash をダウンロードしよう

gitforwindows.org

これでWindosでもbashが使えるようになるよ！ そしてgitコマンドも打てるようになります。

初期設定しよう

名前とEmailを設定しよう。 これを設定しないとエラーになると思われ。

$ git config --global user.name "user name"
$ git config --global user.email "email@email"

エンコードとeditorの設定 git config --global core.editor 'vim -c "set fenc=utf-8"'

リポジトリをダウンロードしよう

自分のGithub上のリポジトリをお持ちの方は、下記のコマンドでリポジトリをローカルにcloneしましょう。 ローカルにブランチが作成されるはずです。

$  git clone `url`

master branchから開発用のブランチをチェックアウトしよう。

なんかテスト用のプログラムが欲しいのでNode.jsをインストールしている自分がいます。 あんなに家でITはやらないって言ったのに！

''' MINGW64 /tmp/test (master) $ git checkout -b new_develop_function Switched to a new branch 'new_develop_function '''

 /tmp/test (new_develop_function)
$ git branch
  master
* new_develop_function

これで自分の開発用のブランチの完成です。

変更したファイルをcommitする

statusコマンドを叩くとこのような感じで変更ファイルが出力されます。 sample-appのtest.txtが変更されている状態です。

$ git status
On branch new_develop_function
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   test.txt

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        sample-app/

no changes added to commit (use "git add" and/or "git commit -a")

次に中身の確認は必ずやりましょう。 diffコマンドを叩くと差分がローカルに出力されます。 問題がないか確認しましょう - は削除、 + は追加ですね。

$ git diff
diff --git a/test.txt b/test.txt
index e69de29..8405060 100644
--- a/test.txt
+++ b/test.txt
@@ -0,0 +1,2 @@
+
+test

次はadd コマンドです。これはgit内でindexに追加され、stage環境に登録された 状態になります。 先にcheckoutしていますが、この状態でcheckout -bを使ってもOKです。

$ git add test.txt
$ git status
        modified:   test.txt

ではコミットしていきましょう。 コミットコメントはわかりやすいものにしておくと助かるはずです。

git commit -m "fix diff"
[new_develop_function 724bbc5] fix diff

変更したファイルをcommitする

これでpushするとgithubにあなたのブランチが送信されます。

git push origin -u new_develop_function

-u, --set-upstream
           For every branch that is up to date or successfully pushed, add
           upstream (tracking) reference, used by argument-less git-pull(1)
           and other commands. For more information, see branch.<name>.merge
           in git-config(1).

-u optionをつけておくとあなたのリポジトリがセットされて次回からgit push だけでpushができるようになります。

githubを確認してみる

これでローカルのディレクトリが反映されている。

これでguthubにコードが送信されたのがわかりますね！ ではその画面の new pull request を押してみましょう。

pull requestを作ってmergeしてみよう！

プルリクエスト作成画面

こんな感じでmasterブランチにマージするためのプルリクエスト作成画面が表示されました。 マージするブランチを間違えないことと、プルリクエストの名前は後から見直すので 注意して付けてください。

create pull request ボタンを押下でOKです。

では最後にマージして終わりたいと思います。

merge pull request ボタンを押してマージしたあとに、delete branchで不要なブランチを消しましょう。

まとめるのって意外と大変でした。

いつも参照させてもらってる技術ブログを書いている方には感謝しかありませんね。

以上です！

Http Status Codeについてよく見るやつをまとめてみた

こんばんわ。ぽん太です。

よく見るHTTP Status Codeをまとめてみようと思い投稿します。

Status Code全部

超いっぱいありますね。100番台とかアプリ開発で使ったことないです。 200系、400系、500系はよく見ますね。

よく見るやつから行ってみましょう。

あんまり200以外は、帰ってくるとヒヤッとするものが多いですね。

200 OK

殆どの成功レスポンスではこれを応答しましょう。 エラーなく処理が完了した場合、200 OKを応答しましょう。

204 No Content

リクエストを受理して成功したが応答するBODYがない場合はこれをたまに 応答することがあります。

200 OKでBody無しでもいいんじゃないかなと思うんですが。

301 Moved Permanently

サイトが恒久的に移動した場合、移動前のHTTPサーバーではこれを応答しましょう。 そしてヘッダのLocationにURLを入れておくと、ブラウザは自動的にリダイレクトするようになります。

302 Moved Temporarily

一時的なリダイレクトの必要がある場合はこちらを応答しましょう。 301とはブラウザのキャッシュ動作などに差があるはずですね。 要求を受け付けたけど、別のサイトにリダイレクトさせたいときなどにこれを利用していたり。

400 Bad Request

リクエストが不正である場合はこれを返しましょう。 リクエストのフォーマットチェックなどでひっかっかたらこれを応答します。

多分それ以外にも、プログラムでチェックして不正な結果となったことが検出された場合、これを応答するのがよいでしょう。

401 Unauthorized

これは認証に失敗した場合に応答しましょう。 Basic認証などに失敗するとこれが応答されますね。

403 Forbidden

認可されていないリソースに、アクセスされた場合に応答しましょう。 例えば読み込み権限があるが、書き込み権限がない場合などにこれを応答するのが適切でしょう。

404 Not Found

アクセスしたURLにこちらの配置したリソースがない場合に、Webサーバが自動的に応答してくれると思います。404が応答されたらそのURLには何もありません。

405 Method Not Allowed

Apacheのhttpd.cofなどでMethodの禁止設定をしていたMethodでアクセスした場合にこれが応答されると思います。 昔はGETとPOST以外禁止していたような。

500 Internal Server Error

個人的に一番見たくない奴です。内部処理が失敗していますね。 CGIとして動作しているPHPなどが意図せぬエラーになっていたりするとこれが応答されます。

原因を調査して、何とかしないといけない奴です。

502 Bad Gateway

あんまり見ることはないのですが、FireWallとかロードバランサーとかネットワーク機器を 疑いますね。

503 Service Unavailable

サービス利用不可。サービスが一時的に過負荷やメンテナンスで使用不可能の状態です。 負荷であれば、一時対処でapacheを再起動してみたり恒久的にはサーバーを拡張するとか負荷を軽減するとかでしょうね。プログラムの処理が重くて動かない場合は、CPUが100%に張り付いて500が応答される気がするので、WebサーバーのMaxClientWokerが足りていない気がします。

各サーバーのCPUに余裕がある場合は、MaxClientWokerをもっと大きな値にしてみましょう。

504 Gateway Timeout

これもネットワーク機器が死んでいることを疑います。

まとめ

いっぱいありすぎて正直全部を使いこなすのは無理でしょうね。 でも、たまに確認しておかないといつの間にかベストプラクティスが更新されて自分の知識が古くなっていることが あるので基本に忠実に行きましょう！

マイクロサービスとモノリシックなサービス

こんにちわ。ぽん太です。

今日はマイクロサービスとモノリシックなサービスについて触れていきたいと思います。

サービス指向アーキテクチャとかその時代ごとに流行りがありますね。 SI出身の私は、あまりその時の流行り物を導入することを推奨していません。

同じシステムを10年以上運用することを考えると、流行り廃りのないものを導入してもらうほうが、ずっとサポートが受けられたり、使っているライブラリのメンテナンスも継続されてパッチが当てられたりと長年使うには良いと思うからです。

流行り廃りがあってその中で、これからの主流になるなと思うものを取り入れていくのは良いことだと思います。

そういった観点で、今回は解説してみたいと思います。 ※入門用であり、参考程度にお願いします！

モノリシックなサービスとは

うーん。まさにモノリス。 これらの機能が、1つのインスタンスの中で動作し、お互いに密結合で動作しあう。

メリットを考えるとこんな感じかな。 　・通信のコストがなく、コンピューターリソースが適正であればマイクロサービスと比較したら早い。

　・お互いの機能が参照しあえる

　・機能間でデータも簡単にやり取りできる。

　・同一サーバー内で動くので、旧来のインフラで動かせる。

　・開発のプロジェクト（Git)の単位も1個でOK

　・開発チームも1チームとかモノリシックな感じで運用できる。

　・複数のサーバーやコンテナが不要

デメリット 　・密結合なので、1つを止めるのには全部を止める必要がある。 　・機能間でデータの参照をモジュールの独立性を考えておかないとぐちゃぐちゃに。 　・ソースコードが肥大化。 　・開発チームも大きくなるとみんなで1つのGitプロジェクトにマージするのが大変。

基本的によく使っているサービスはこれが多いんじゃないかなと思います。

データベースとWebやバッチなどをある程度分離して、負荷のかかる個所をスケールアップかスケールアウトしていけば、 データベースの限界までスケールしていきますしね。

分散コンピューティングという観点で見ると並列処理化できるところと出来ないところがあるのでそこがネックになってしまうかも。

マイクロサービス

これまた複雑。機能単位などで独立したサービスを開発する。 そしてサービス間の連携は、同期であればHTTPを、非同期であればAMQPなどのプロトコルを利用して、 通信し合うことで処理を実行していきます。

見るからに複雑化するんですよね。全体が。 その代わり作る単位を考えれば1つ1つは、簡単になるしその単位で運用していけるメリットがありそうですね。

メリットを考える

・1つ1つが独立して動作するので、1つが落ちても依存関係のない機能は動き続けることができる。

・うまく機能を維持すれば、1つ1つのサービスではシンプルにできそう。

・ソースコードも1つのまとまりが小さくて簡単になりそう。

・各機能の単位で、拡張できるので、細かくスケールアウトが設定していける。

・非同期のプロトコルなどをうまく使えば、必ずしも遅いわけではなさそう。

デメリット ・通信が発生するのでその分モノリシックなサービスよりコストがかかる。

・お互いを参照するにはインターフェイスを作って通信しないと見れない。

・複数の機能が独立して動作するので、クラスターが必要になる。k8sとか。

・開発プロジェクトの単位は当然、サービス単位ですよね。

・サービスのまとまりを維持しようとすると、サービスがどんどん増えそう。

・開発チームを複数作るほうが効率が良さそうだが、コミュニケーションが大変そう。

マイクロサービスはもちろん利点もいっぱいあるのですが、マイクロサービスゆえの難しさ、課題が発生すると思っています。 実はモノリスでよかったのに。となった時に、利点が消えてしまう可能性も。 (自分で言ってて保守的だなぁ)

特に受託開発などでは結構厄介になりそうな気がして、挑戦できる環境でいと採用する気が起こらないですね。 心配なのは障害が起きたときの原因特定や、ログの調査が通信ログを追っていくのが大変そうに見えます。

不具合起きて迷宮入りでもまあいいよいいよ、と言ってくれる環境なら積極的に使ってみたいかも。

クラスターなどの導入を考えるので、一時の流行りで数年後にサポートが切れたら・・・とか。 そういうことを先立って考えてしまうのは良くない癖でしょうか？ 自信をもってユーザーに勧められないとどうも提案しずらいです。

まとめ

これは私がマイクロサービスを運用しているチームをみて感じたことなので、参考程度に読んでいただくのがいいかなと思います。 下記に書いているのは、一般的な分散コンピューティングのメリットデメリットのようです。

` 高信頼 故障部分以外は稼動可能 ` 
`  安価 グロッシュの法則（コンピュータの能力 ∝ コスト2）が破れ、ハードウェアとソフトウェアのコストが逆転。`

` レスリー・ランポートは、「分散システムは、そんな障害があるとは思ってもみなかった障害によって利用不能になるシステムである」と述べている `  
` 分散システムにおけるトラブルシューティングや診断はますます困難になりつつある。問題の原因を突き止めようとすれば、遠隔ノードへの接続が必要であり、ノード間の通信内容を調べる必要がある。 ` 
` 分散環境に適さない計算の種類も多い。特に通信量が多くなるものや同期が必要なものは適さない。`

ご自身で採用される場合は、一時の流行りなのかそれともこれからの主流なのか。

作ろうとしているものは、どの構成が向いていてどれが向いていないのかなどをよく吟味して採用すべきだと思います。 古いとか新しいとかはあまり関係なくて、最適なものというものを探してそれを導入していくという努力をしていくことが大切だと私は思うのです。

発注頂いたお客様であったり、自社の社内向けであったとしても、自分のチームと利用者にどんなメリットが与えられるかという観点で、 最適解を探していきましょう。

以上。ぽん太でした。

HTTPメソッドの基礎を覚えよう

こんにちわ。ぽん太です。

HTTPメソッドについて、今まではGETとPOST位を使いまわして、 どうにかやっていたのですが、最近は時代遅れというかAPIのURLを作るにも、 RESTの設計思想に従って作っていくのが流行りだと思います。

うーん、この辺に関してはGETとPOSTでいいじゃんと、今でも思っている節があるのですが、 知らないで脱線するのと知っていて脱線するのとでは雲泥の差。

何も知らない中年エンジニアになりたくないので、ここにまとめて行くよ！

今現在35歳なんですが、まだまだ技術系の話題に付き合っていきたい。 というかこのITエンジニアなのに、技術系がわからないなら潔く引退したいと思っています。

なのでこの年齢からが頑張りどころ。時間があるときにどんどん新しいことを覚えていきましょう。

HTTPメソッドの種類について

GET : データを参照したいときに使う。CRUDのR。冪等性が求められる。 HEAD : HTTPヘッダーのみを返却する。チェック用。 POST : データを新規登録したいときに使う。CRUDのC。冪等性は求められない。 OPTIONS : HTTPサーバーがどのHTTPメソッドを許容しているか調べる。攻撃の可能性があるので、閉じることができる。 PUT : データを更新したいときに使う。CRUDのCとU。冪等性は求められない。 DELETE : データを削除したいときに使う。BODYは使わない。冪等性は求められる。 TRACE : サーバーが受けとったリクエストをそのまま応答する。セキュリティの観点から閉じられることが多い。 PATCH : 新しいメソッドですね。HTTP1.2からの対応で一部更新用です。

この中で主に使われるのはこれらの、メソッドで冪等性と副作用は下記の表のようになります。

OPTIONSはSPAを作ると、異なるドメインに対してブラウザがpreflight-requestを投げ込んで、アクセス可能かをチェックする機能があります。

Google APIの仕様を見てみる。

---

Gmailのラベル操作API

POST / userId /labels ラベルを作成する。

DELETE / userId /labels/ id ラベルを即座に削除する。

GET / userId/labels/ id 特定のラベルを取得する。

GET / userId /labels ユーザーのすべてのラベルを取得する。

PATCH / userId /labels/ id 特定のラベルを更新する。

PUT / userId /labels/ id ユーザーの特定のラベルを更新する。

---

くっ、わかりやすいじゃないかGoogleAPI。 これをGETとPOSTだけで作ると、結構わかりずらくなりそう。 業務系システムでサーバーサイドレンダリングのシステムであれば基本GETとPOST以外は意識しないで済みますが、 APIの集合体を作ってSPAやネイティブアプリに提供するとなるとこのほうが良さそうに見えてしまいました。

どんどん知識は更新されているし、過去の失敗を生かして新しい知識がどんどん出てくるので、 ベストプラクティスを採用しないこともあえての選択肢としてはあると思うし全然否定しませんが、 やっぱり覚えておいて逸脱するのと、知らないのとではわけが違いますね。

だいたい、困った時はGoogleのAPIを参考にしていこうと思います。

今日は以上です！

このブログについて

こんばんわ、ぽん太です。

はじめに

このブログは自分の持っている、ITの知識や経験をここに記載して、皆さんとの共有を図ること。

ITエンジニアとして、他のエンジニアの人や一般の人にソフトウェアの重要性を理解してもらったり重要性を認識してもらったり、 興味を持ってもらいたいという考えで始めたいと思っています。

私は、日本ではSEと呼ばれる立ち位置で働いていた経験が長く、いわゆるなんちゃってエンジニアなのですが、 もともとエンジニア職をあえて、選んだだけあってやっぱり技術系の話は好きですね。

日本のSE職は海外と違って全部入りの仕事なので薄く広い知識が売りですねｗ

自分の知識や経験をそのものを紹介していきます。

もうこの仕事を初めて13年になります。

経験してきた技術はこんな感じです。

言語 : Java, PHP , Python, JavaScript, TypeScript(フロントエンドは苦手) 
データベース :  Oracle, MySql, Postgres
Webサーバ : apache 
AWS: Lambda, EC2, APIGateway, S3, Cognito, CloudWatch...
その他 : Hadoop

最近はいつも利用者が数十万人～1千万人くらいまでのWebサービスに関わっていることが 多いですね。

文系SEとしてIT業界に入り、派遣→SIer→Web系企業と転職を3回しているので業界内の 企業のジャンルもある程度、知っています。

どんな仕事なの？とか、この技術はなんなの？とか言ったことを紹介できればと思います。

自分の知見をもって世の中のベストプラクティスを紹介していきます。

ベストプラクティス この言葉今はやっていますよね。

最善の手法 という訳でいいでしょうか。

APIのURLの付け方とか、10年前はそんな感じではなかったんですけどね。 ありがたい限りです。沢山のエンジニアたちが、日々努力している結果ですね。

SIerでスクラッチ開発デスマーチをしていた頃は、そんな言葉さえ知りませんでした。 今ではAWSを中心とした開発がIT業界を席巻しており、単純なプログラムの知識だけでは太刀打ちできない 世の中になりつつあるということが言えると思います。

例えば、AWS Lambdaで開発すると沢山のアンチパターン(良くない手本)があり、ペストプラクティスがありますね。

Lambdaで開発する時はVPCを設定するとコールドスタートが遅くなるとか、LambdaでVPC接続して、RDSを見ようとしたときは、 バースト負荷時にコネクションプールができなくてコネクションが枯渇して落ちます。

言語で言うと、LinkedListと配列の構造的な違いとか。

こういった手法というものを理解して、実行していくことがこれからのエンジニアでは非常に重要であるということに気が付きました（遅い

自分の勉強の意味もかねてここで紹介していきたいと思います。

IT業界やエンジニアのことを紹介していきます。

これからエンジニアになりたい人とか、エンジニアの友人や彼氏の仕事が知りたいなんて言う人向けに普段何をやっているか 紹介していきます！

なんか、動かなくて空を見上げていたり頭を抱えていることが大半ですが。

そんな感じでスタートしていきたいと思います！

お問い合わせはこちら

プライバシーポリシー

個人情報の利用目的 当ブログでは、メールでのお問い合わせ、メールマガジンへの登録などの際に、名前（ハンドルネーム）、メールアドレス等の個人情報をご登録いただく場合がございます。 これらの個人情報は質問に対する回答や必要な情報を電子メールなどをでご連絡する場合に利用させていただくものであり、個人情報をご提供いただく際の目的以外では利用いたしません。 個人情報の第三者への開示 当サイトでは、個人情報は適切に管理し、以下に該当する場合を除いて第三者に開示することはありません。 ・本人のご了解がある場合 ・法令等への協力のため、開示が必要となる場合 個人情報の開示、訂正、追加、削除、利用停止 ご本人からの個人データの開示、訂正、追加、削除、利用停止のご希望の場合には、ご本人であることを確認させていただいた上、速やかに対応させていただきます。 アクセス解析ツールについて 当サイトでは、Googleによるアクセス解析ツール「Googleアナリティクス」を利用しています。 このGoogleアナリティクスはトラフィックデータの収集のためにCookieを使用しています。このトラフィックデータは匿名で収集されており、個人を特定するものではありません。この機能はCookieを無効にすることで収集を拒否することが出来ますので、お使いのブラウザの設定をご確認ください。この規約に関して、詳しくはここをクリックしてください。 広告の配信について [自分のサイトの名前]は、Amazon.co.jpを宣伝しリンクすることによってサイトが紹介料を獲得できる手段を提供することを目的に設定されたアフィリエイトプログラムである、Amazonアソシエイト・プログラムの参加者です。

第三者がコンテンツおよび宣伝を提供し、訪問者から直接情報を収集し、訪問者のブラウザにクッキーを設定したりこれを認識したりする場合があります。 免責事項 当サイトからリンクやバナーなどによって他のサイトに移動された場合、移動先サイトで提供される情報、サービス等について一切の責任を負いません。 当サイトのコンテンツ・情報につきまして、可能な限り正確な情報を掲載するよう努めておりますが、誤情報が入り込んだり、情報が古くなっていることもございます。 当サイトに掲載された内容によって生じた損害等の一切の責任を負いかねますのでご了承ください。 プライバシーポリシーの変更について 当サイトは、個人情報に関して適用される日本の法令を遵守するとともに、本ポリシーの内容を適宜見直しその改善に努めます。 修正された最新のプライバシーポリシーは常に本ページにて開示されます。