https://www.amazon.co.jp/gp/product/B07Q1KJT58/ref=ppx_yo_dt_b_d_asin_title_o00?ie=UTF8&psc=1
- 出産は大怪我のようなもの
- 出産が大変なのは一瞬で乗り越えれば楽になると思い込んでいたが、それはかなり違う
- 最低でも産後２週間は、ママが授乳以外は何もしないでもいいくらいの体制を作れるのが理想
- 出産はマラソンを走った程の消耗
【第2章】産後のママのリアル[環境変化2]
この辺りはかなり認識がズレていた。出産後はすぐに体調が戻ると思っていたが現実は全然違っていて、子宮、筋肉、骨盤など大きなダメージがある。半年かけてゆっくりと戻っていく。物理的に無理をさせない、あまり動かせない、負担をかけないようにする。
チケットクラスのテストコードのサンプル
Test Code
function testTotalTicketsInitialization() {
$ticketSystem = new Ticket(10);
assertSame($ticketSystem->getTotalTickets(), 10, "Total tickets initialization");
}
function testRemainingTicketsInitialization() {
$ticketSystem = new Ticket(10);
assertSame($ticketSystem->getRemainingTickets(), 10, "Remaining tickets initialization");
}
function testTicketInstance() {
$ticketSystem = new Ticket(10);
assertInstanceOf($ticketSystem, 'Ticket', "Ticket instance check");
}
function testBuyTicketSuccess() {
$ticketSystem = new Ticket(10);
assertSame($ticketSystem->buyTicket(), true, "Buy ticket success");
}
function testRemainingTicketsAfterPurchase() {
$ticketSystem = new Ticket(10);
$ticketSystem->buyTicket();
assertSame($ticketSystem->getRemainingTickets(), 9, "Remaining tickets after purchase");
}
function testBuyTicketAtMaxCapacity() {
$ticketSystem = new Ticket(10);
for ($i = 0; $i < 9; $i++) {
$ticketSystem->buyTicket();
}
assertSame($ticketSystem->buyTicket(), true, "Buy ticket success at max capacity");
}
function testRemainingTicketsAfterMaxCapacityPurchase() {
$ticketSystem = new Ticket(10);
for ($i = 0; $i < 10; $i++) {
$ticketSystem->buyTicket();
}
assertSame($ticketSystem->getRemainingTickets(), 0, "Remaining tickets after max capacity purchase");
}
function testBuyTicketWhenSoldOut() {
$ticketSystem = new Ticket(10);
for ($i = 0; $i < 10; $i++) {
$ticketSystem->buyTicket();
}
assertSame($ticketSystem->buyTicket(), false, "Buy ticket failure when sold out");
}
function testRemainingTicketsAfterSoldOut() {
$ticketSystem = new Ticket(10);
for ($i = 0; $i < 10; $i++) {
$ticketSystem->buyTicket();
}
$ticketSystem->buyTicket();
assertSame($ticketSystem->getRemainingTickets(), 0, "Remaining tickets after sold out");
}
PHPerKaigiにday0より参加している。 App RunnerやFargate×Laravelなど興味深い話が聞けて面白い。 あと性能測定みたいな話もday1で３つのセッションがあってどこも表示速度とかUXみたいな部分への対応が課題なのかなと思った。 何より、ああいう場で発表をする人がすごいと思うし、自分の未熟さみたいなことを感じる。頑張ろうと思う。
以前、EC2とCICDでLaravelアプリのCICDを整えたが、自分が作っているsakuraのパッケージシステムもCICDを整えたかった（今まではサーバにsshしてgit pull origin master..）CICDが整ってないと積極的に改修できないので開発のネガティブファクターになる。 特にstagingとproduction環境で分けてデプロイする必要があり、環境に応じて条件分岐するyamlファイルを作成した。 なお、お金がもったいないのでレンタルサーバにstagingとproductionを乗せてる極弱サーバ環境です。 参考までにこれ deploy.yaml
いちばん手こずったのはGithub上でyamlファイルをいじってもデプロイ時にはそのyamlファイルは読まない。yamlファイルもローカル上で改修して、add,commit,pushして走らせる必要がありますので気をつけましょう。Github上で直接変更するのはダメです、絶対。（これに２、３時間ハマりました＝
複数名で開発しているとmasterが変わることがある。常に最新masterを読み込んだ上で作業ブランチで開発したい。
% git checkout master
% git pull origin master
% git checkout 作業中ブランチ名
% git rebase master
masterを反映するのであればHead（current branch側）を消す方針でいいと思う
git add 修正したファイル
git rebase --continue
この後、ファイルが開く。とりあえずwqで抜けていいが、場合によってはコメント入れないとダメかも。冒頭にfixなどのテキストを入れるとかでいいと思う。
これで作業ブランチに最新のmasterを反映できた。
t_wadaさんのpodcastを聞いてTDDをやる意義がわかったので書いておこうと思う。 TDDは最初のうちは工数がかかる、これは間違いない。過去にテストコードを書いていたときもあるが、アサーションの書き方に詰まったりして苦戦した記憶がある。特に受託開発だと納期や工数、またどうしても工数が増えるので、その分コストが発生するので、発注者のテストコードへの理解も重要など、いくつかの壁がある。 ただ、やはり設計のしやすさ、柔軟な設計変更を可能にする、などメリットが大きい。個人的には設計をガチガチに固めてしまいがちなので設計に時間がかかる。漏れがないけれど応用が効かないなどのデメリットもある。 ものは考え方次第で設計する時間を削ってテストコードを書く時間にすればいいのではないか、と思うようになった。設計はいずれ変わるのだから、それを前提にして設計段階でテストコードを書く。これがとても大事だと思う。いずれ変わる設計をガチガチに固めても意味がないので設計時間をテストコードを書く時間にあてれば工数も膨れ上がらずに柔軟なコードが書けるのではないのではないか？と思う。
ローカルの変更を取り消したい時はgit checkout . ただ、これだと変更は戻せるけど新規ファイルは削除できない。
新規ファイルを取り消したい時はgit clean -df .
addを取り消したい時はgit reset HEAD .
pushを取り消したい時はgit revert [<commit>]を実行後にgit pushする。いわゆるREVERT
