IPv4サブネットマスクとネットワークアドレスとグローバルキャストアドレス
私が理解した順にかきかき
IPアドレス
ネットワーク部（どこの～）とホスト部（だれ～）から成り立つ
どこからどこまでがネットワーク部か、の考え方に２つあり
- クラスフルアドレス
- 第１オクテットのビット数のパタンでネットワーク部とホスト部を分解したもの
| アドレスクラス | 第１オクテットの値 | ネットワーク部 |
|---|---|---|
| Aクラス | 1～127 | 8ビット |
| Bクラス | 128～191 | 16ビット |
| Cクラス | 192～223 | 24ビット |
※224以降はマルチキャスト用
アドレスクラスの境界は２進数にするとよくわかるよ
| 1 | 0000 0001 |
| 127 | 0111 1111 |
| 128 | 1000 0000 |
| 191 | 1011 1111 |
| 192 | 1100 0000 |
| 223 | 1101 1111 |
| 224 | 1110 0000 |
※よく見る /28 とかの書き方をプレフィックス表記と呼ぶ。そして、以下はそれで書く
100.22.33.1/28 の場合
0110 0100 0001 0110 0010 0001 0000 0001 // 100.22.33.1を2進数に 1111 1111 1111 1111 1111 1111 1111 0000 // /28の正体
1の部分がネットワーク部、0の部分がホスト部
ホスト部がすべて0のものがネットワークアドレスに使用され、ホスト部がすべて1のものがグローバルキャストアドレスに使用される
100.22.33.0がネットワークアドレスで、100.22.33.15がグローバルキャストアドレス
ホストで割り当てられるのは、100.22.33.1～100.22.33.14ということですたい
このアドレスを正規表現で表したいんじゃ
100\.22\.33\.([[1-9]|1[0-4])
SVNからGitへ乗り換えてほしい話
スケジュールって大切という話 / 線の引かれてない作業にチョット待ってくださーい
他PJが落ち着いてきたので、中規模（３～５か月）を途中から任され、
設計のためにざっくりプロトを作ってよ～と前日に言われ、
お客様と確認を始めた今日この頃。
今どんなフェーズですか、どこまで進んでますか、どんな話ししてきましたか、というのは自分から聞かないと教えてくれない、引継ぎはスパルタスタイルなので、毎度のこと根掘り葉掘り聞きまくっており
そんな時にふと、後輩ディレクターに設計フェーズっていつまで・・・？と尋ねたところ、ドンスルーされた。
おい、マテ、エンドのない仕事は先輩との飲み会だけで十分だ！！
そんなわけで、改めて納期とかスケジュールが大切な理由を自分でもメモ残し。
エンジニアとかプログラマに限らず、ですが、ひとまずはエンジニア視点で。。
あなたはスケジュールは大切と思いますか？
ワタシハ大切ダト思ッテイマス。
なんで大切とかってのは、大して教えられず、小中高大学と提出物の期限とかテストまでの期間とか、受験までの期間とか、卒業までとか、何かしら期限を設けられてきて生きてきた我々。
仕事で期限があるから、教育に期限があるのか、カリキュラムが1年単位で決まってるから、それに合わせて期限があるのか、命という期限から、ありとあらゆる期限が決まったのか。。
チョット、よくわからないので、期限の起源の話はすっ飛ばして、エンジニアとして思うスケジュールの大切さ理由をツラネル。
スケジュールが決まってないとエンドがない
いつまでにリリースします。がないと、それまでの作業は全部ここまでにやろうねというエンドがない。
これがものすごく恐ろしい。
youtube見てて、時間表示とか進捗バーが時間経過ごとに変動（主に増）してたら「え？いつ寝よう」ってならないですか？
満足したら、次行けばいいじゃない、って言うアントワネットもいると思いますが、
ゴールがないのにどこがおもしろさのピークかわかるのか？本当にこの後は特に面白くないのか？次の用事の価値と天秤にかけるのが難しい。
※もちろん、意志の強い人は自分で時間決めて動けると思うけどね。うん、それがもはやスケジュールだよね。
あとですね、我々が働くには常に人件費がかかるので、時間をかける = 費用が掛かる わけですね。
time is moneyですね。
うん、スケジュール大切だなぁ。
余談：最近はやりのlivehouseもエンドがないとtwitterでつぶやいているエンジニアがいた。プライベートでもエンド求ム人は多いかもね。
エンドがなければ私がサボる
これは私が悪いのでしょうか。いいえ、誰でも。
もし、夏休みの宿題、いつでもいいから出してね！だったら、みんなやりますか？（私はやる側の人間だよ）
夏休み明け一発目の授業で提出だから、前日に数多の人間は鼻血出してやりますよね。
勿論、早く終わらせることもできますが、そのあとはしっかりサボるでしょう。
明日絶対決めないといけない、わけでないなら、毎日まぁこれくらいでいいか、ってなります。・・よね。
エンドがなければお客サマーもサボる
仮にワタシがサボらず、必死のパッチで作業する人間だったとします。
でも、お客さんの意識としては「まだ、間に合いますよね」の状態なので、ときに永遠ループの仕様変更に陥ります。
みんなより良いものを作りたい、その一心なので仕様変更が決して悪いわけじゃない。
お金も払っているので、コストに見合った、むしろコスト以上のもの作りたいと思いますよね。（システム開発で動くお金ってすんごいの）
でも、だからと言って、やっぱり戻しましょう、やっぱり追加してください、みたいな何回も何回も同じことの繰り返しは無駄ですよね。
スケジュールのなさは、みんなの判断の甘さにもつながります。
今ここ仮決めで、後で本決めしよう。（４回目）
「ループしていいのは、ハルヒだけ。」
まあ、普通のお客サマーなら、これいつ終わるんですか？って聞いてくるでしょうけど。
上の例ってB to Bっぽいけど、B to CでもC to Cでもいつまでもジェムのバグ直らんかったり、障害直らんかったら不満勃発ですよね。課金できねぇよ！って
スケジュールないのは誰も幸せにならない
ゆえに個人的にそう思う。
まあ、お仕事の上では基本スケジュールはあるものなので、上みたいなのは本当に極端な話です。（※過剰な演出あり）
前の会社では自社開発で僕だけが開発してたので期限とかなかったんですよ～とか言ってた同僚もいましたが、弊社には納期があるので苦労されたようで半年でいなくなってしまいました。
スケジュールがない仕事をして、みんながスケジュール守れなくなるわけじゃないですが、そんなこともありますよね、ってことです。
結論、何が言いたいかって、私が任されたのは設計フェーズではなく、要件定義からで、見積もりもお願いします、って話だったってこと。言ってよ！設計お願いしますって、適当なこと言わないでよ！
スケジュールも大切ですが、作業の引継ぎもちゃんとしましょう。
PHPカンファレンス[ゼロベースから Laravel を用いたAPI 実装オートメーション]凄すぎる
PHPカンファレンスでめもりーさん凄すぎたので、この気持ち忘れないためにメモ
↓↓聞いたお話はコチラ
Next up: 2020/12/12 12:40 Track4 / ゼロベースから Laravel を用いた API 実装オートメーション / めもり〜 @m3m0r7 https://t.co/eyxno4HnvF
— PHPカンファレンス2020 (@phpcon) 2020年12月12日
何がすごいか
課題解決の力がすごすぎる
冒頭では自分たちのサービスのやばさを、笑ってくださいね～といわれるが、、
きっとみんな「あ、このシステムやべぇわ」って思ったはず。。
- SaaS使っていて、１画面開くのが５秒（Webサービスでは致命的・・・）
- 前任者がハンドルされたjavascriptだけ置いて行った
- 元のソースコードがない
いや、わらえる（わらえない）、、けど、こういうの変えるのって楽しいんだろなという感想とともに、システムの課題解決の話ね。。
と思っていたら、開発方法・考え方もすごかった（タイトルに書いてあるんだけど、見逃していたワタシ）
システムの課題解決は当たり前、どうやってやるか
API実装オートメーションが本当にすごかった
API定義書からAPI、全文検索エンジンのマッピング（Erasticsearch）、正常・異常テスト、テスト用シードデータを生成する
今の仕事でもドキュメント、自動テストの導入はかなり後回しになっている。
これまでの秘伝のタレ化したシステム（各々が自由にコーディングしている、テストを意識していないコード）でテスト導入コストが高くて、みんな後ろ向き・・・ってところで
はじめっから、そのコストを削減する仕組みを考えるって本当に大切ですごいなと思った。。。
あとから導入ってやっぱりハードル高いし、気のせいか私の周りのおじさんは「わからないから」って理由で嫌がる涙
人が足りない中でテストも楽に導入する、実装がめんどくさいところは全部自動化しちゃう（検索や検索条件の自動生成とか）
文字で見る以上に、仕事で実際にやるのはすごいことだと思っている
その先につながる採用
この対応で、システムの課題を解決したことよりも、エンジニア採用に成功している事実が私の中で一番のポイントだと思っている。
冒頭だけ見ていたら、明らかに闇を感じる職場・・・笑
スタートアップは立ち上がり直ぐは給与も出せないし、優秀なエンジニアの獲得は大変で、盛り上がってきたところで辞めてしまう人もいてしまう。。
そんな中で、こんなモダンな環境に作り替えたことがすごくて、開発環境は求職者の魅力の一つにつながるのは間違いない
働く人もテストコード書く会社と、書かない会社、オートメーションしている会社、していない会社で、同じくらいいいなって思ってたら、どっち選ぶよ、って感じ。（技術を受け入れてくれる社風ならどっちでもいいのかもだけど）
システムの改善が、エンジニア採用を成功させるうえで一番のキーになるって強く思った。（少なくとも、私はめもりーさんすげぇ、この人と働いてみたい。とか、こんな実装オートメーション化している会社面白い、より深く見てみたいと思う）
自分も務めている間に、そんな魅力的な会社にできるように尽力したい。
VSCodeのLiveShareを使ってペアプログラミングをしてみた
今回は、実践編。。
仕事でやった内容なので、詳細な構築内容は残せないがどんなメンバでどんな風にやってみて、どういった課題が見えたか。。をメモ。
メンバ
- エンジニア歴10年以上大ベテラン
- エンジニア歴5年の中堅（ワタシ）
ワタシたちのペアプロルール
実施時間
午前２時間、午後２時間（あいだお昼休憩をはさむ）
（最初から最後まで、ペアプロで実装したいが試験的な試みのため…お察しください）
目標
サーバサイドの実装を完了させる。
スイッチサイクル
zoomが無料版で40分で切れてしまうため、40分実装→20分休憩のサイクルでスイッチする。
そのほか
ちょっと亜流だが、課題が見つかったら各々が課題解決にコード見たり、原因調査をする。
普通はナビゲータがドライバーに指示しながら二人で同じもの見ながら解決していくものだと思う。。
が、二人とも年数があり仕様理解もある程度あった、かつ、リモートでLiveShare使って二人ともPC触ってコード見れる状態だった、ということで各々調査ができる環境だったので、、そんな感じで
やってみた感想
構築時間の短縮
初めてのペアプロだったが、爆速で実装ができ実際は３時間で終了した。
もっとかかると見積もっていたが、ここの見積もりがそもそも甘かったかもしれないね。。と大ベテランからご指摘もらう！
そういう見積周りのFBもらえるのも、あまりないので嬉しい。
でも、結果的に見積よりも二人分の工数を足しても超えることはなく、個人的によきと思う。
事前準備の不足
LiveShareの使い方がわからず、各々が調査するときに画面が共有されて困ることが多々あった。
多分、共有の解除か相手の追従解除ができるっぽいけど、そのあたりの事前確認ができていなかった。
亜流？ペアプロ
メンバのスキルによって、ナビゲータがべったりドライバーに指示するスタイルとある程度自由にやるスタイルで分けてやるのはありだなと思った。
序盤は、ペアプロってこういうもんだってものにとらわれていたので、何か問題発生した際のナビ役の大ベテランの無言の圧に「ワタシには無理だ」と思う瞬間もあった。
が、最後の方にはそのスタイルにも慣れて、結果的に新しい発見があった。（各々で調査した方が効率がいい、とか、そういうスタイルもありってこと）
人を選ぶ
（自分がすごいってわけじゃないけど）他のエンジニアのペアでうまくできる絵が思い浮かばない。
今時エンジニアはコミュニケーション能力が高いけど、少なくともグループ内の他のエンジニアのカップリングは難しそうと思った。
- 大ベテランの無言の圧に、新人は気圧されそう、お互い無言で大ベテランがドライバーのターンだけ構築が進みそう。。
- 仕様理解が追い付いていないと、大ベテランについていけなさそう、ここ見ろよ、っていうの一からいうの？ってなりそう。。
- 実力ない人同士だと、一ミリも進まなさそう、お互いどうしよっかってなりそう。。
こういう取り組みに前向きなチームは、こんなことアリエナイデショって思うんだろうな、、
が、結構こういう課題を抱えているチームもあると思う。
ということで、大ベテランの重い腰を動かせたのは個人的に◎
Gitの基礎の基礎を学んだのでそれをアウトプット④ ～ブランチとマージ（時々リベース）
今回もGitの基礎の基礎をクイズ形式でアウトプット
コマンドとかではなくて、中ってどうなっているの？がメイン。
ブランチって何？
ブランチはコミットファイルを指しているポインタ。
ブランチの中身を見ると、ただのハッシュIDが記載されている。
このハッシュIDの正体がコミットファイル名。（.git/配下見てみるといろいろわかる）
HEADって何？
ワークツリーでブランチを指しているポインタ。
どのブランチを指しているの？ってのが書かれている。
ブランチの切り替え（master -> feature）
$ git checkout feature
ブランチを新規作成して、切り替え（master -> feature2）
$ git checkout -b feature2
マージって何？
二つのコミットファイルを統合する処理。
FastForword、AutoMerge、Conflictの３種類があって、基本はAutoMergeなので下に示すはAutoMerge。
masterにfeatureをマージ
$ git merge feature
普通のコミットと違って、マージコミットは二つのコミット情報を持つ。
マージとリベースって何が違うの？
リベース（rebase）はbaseをreする（＝親コミットを書き換える）んだよ。
masterにリベース
$ git rebase master
この後、masterにfeatureをマージすれば、マージと同じような結果になる。
ただ履歴や内部的には異なっており、コミット３は消えてしまう。
また、マージもAutoMergeではなく、FastForwordになってしまう。（※ポインタがfeatureが指しているコミットファイルに変わるだけなので、マージコミットが残らない。。）
ちなみに設定次第で、FastForwordされないようにはできる！！
VSCodeのLiveShareを使ってペアプログラミングをしてみる
ペアプロするための準備にちょっと触ったので、メモ。。
実践でまた気になることあれば、別でメモ予定。。
vscodeのliveshareとは
Visual Studio Live Share | Visual Studio - Visual Studio
コロナ禍でおじさんエンジニアとペアプロ・モブプロするチャンスに持って来いの拡張機能。
スイッチの時に、ドライバがコミットして、ナビゲータがローカルを最新化して…
というのもよいが、もっとシームレスにできそうということで使ってみた。
共有の仕方（共有する側）
必要なもの→Microsoftアカウント or GitHubアカウント
shareを選択（今回は、共有される側にも触ってほしいのでRead/Writeを選択）
Microsoftアカウント or GitHubアカウントでSign in
Openを選択
More infoを選択
Collaboration session URLが発行されるので、共有したい人にしかるべき方法で共有する。
※URLの共有は信頼できる人に、と一応いろんなところに書かれている。
共有後、ゲストがアクセスしてきたら、承認でＯＫ！
終わるときは、下部のサインインしているアカウント名をクリックして「Stop Collaboration session」選択する。
アクセスの仕方（共有される側）
必要なもの→Microsoftアカウント or GitHubアカウント
覗くだけ（Read-Only）なら、アカウントなしでもＯＫ！
Joinを選択
共有されたURLを入力
Microsoftアカウント or GitHubアカウントでSign in
承認されたらＯＫ！
出ていくときは、Leaveってのがどこかにあるはずなので、それを選択する。（チョット忘れました）
とても簡単ネ！
気になるセキュリティのあれこれ
セキュリティ-Visual Studio Live Share - Visual Studio Live Share | Microsoft Docs
日本語はわかりにくいので、原文ママが一番よさそう。。
接続や認証について、暗号化しているとか、キー遣ってますよ、ってことが書かれている。
個人的には、以下の設定はしている。
サインインしているユーザーに対してゲスト承認を要求する
ファイルアクセスと可視性の制御
