fv17の日記

Webエンジニアの備忘用ブログです。主にWeb界隈の技術に関して書いています。

Ruby - なぜmapとかcollectとか、エイリアスが沢山あるのか?

ズバリの記事を発見

map と collect、reduce と inject ―― 名前の違いに見る発想の違い

Rubyで「なぜこうなっているのか?」は多くの場合、LispSmallTalk、あとPerl起源が多い気がする。
逆にJavaは世に出た時期がほぼ同じで影響を受けてないから、全然違う感が強い。

まつもとさんも「気分で使い分けてる」と当時のインタビューで発言しているので、まぁ気が向いたら。

Git - 【stashコマンド】変更分を一時避難し、コミットせずに別ブランチへ移動する

作業中にコミットせずに別ブランチへ移動しなければならなくなった場合の操作方法。
stashは、隠しておくの意味。

一時避難

git stash

名前を付けて保存

git stash save "your message"

untrackedファイルも含めて退避

git stash -u

一覧確認

git stash list

元に戻す(適応)

addされていないファイルのみ元に戻す

git stash apply stash@{N} # Nには適応したいスタッシュの番号

addされていたファイルも元に戻す

git stash apply --index

削除

git stash drop stash@{N}

全削除

git stash clear

応用

スタッシュを適用し、適用したスタッシュを削除する

git stash pop stash@{N}

Git - リモートの最新情報をローカルに反映する(fetchとpull)

リモート(GIthubなど)から最新情報を取得し、それをローカルに反映させるには2つの方法がある。一つがfetchでもう一つがpull。

fetch

fetchはリモートリポジトリからローカルリポジトリに最新情報を取得する。
この時、ワークツリー(ローカルで実装しているファイルが置いてあるところ)は更新されない。

git fetch <リモートリポジトリの名称>
git fetch origin

ワークツリーに反映させたい場合はmergeコマンド
下記はmasterブランチを最新にしたい場合で、originのあとにスラッシュが必要

git merge <リモートリポジトリ名称>/<ブランチ名称>
git merge origin/master

pull

pullはリモートリポジトリからローカルリポジトリに最新情報を取得した上で、ワークツリーにもその情報を反映する。つまり、fetchしてmergeするのを一括で実行してくれる。

git pull <リモートリポジトリ名称> <ブランチ名称>
git pull origin master

pullする時の注意点

pullの挙動は、現在自分がいるローカルのブランチに指定したリポートリポジトリをmergeしようとするため、git pullする前には必ずローカルのブランチを適切なものに変更しておくこと。

AWSで無料枠利用なのに毎月4$弱課金されていた件

Elastic IPで毎月4$課金されてた

何も使ってないのに課金された!と叫んでいたら、これを思い出しました。
togetter.com

明細にここ数ヶ月、毎月300~400円前後 Amazon Web Serviceの記載があったが、遂に対応。

思ったこと

そーいえば昔ZOZ●で買い物した時も、気づいたら意味不明な会員にされてて課金されてた思い出。
あーあと、学生時代に某銀行で使える上限をメッチャ低くしてて、気づかないうちにリボッ^ー^という罠も...

つか、預金に数十万あるのに上限10万にしてて15万円使ったら、5万円分はリボ払いになるって...(金額はあくまで例)

この「よく分からんけど気づかないうちに課金されて、メリットを1ミリも享受していない」状況を生み出すのは、自サービスでは絶対しないようにしようと誓う。姑息でタチが悪いなーって印象が強すぎるのよね...

まぁぶっちゃけ月数百円ぐらいどうでもいいレベルで、小さいこととやかく言ってんじゃねーよという。
そして情弱乙と言われたらグーの音も出ない。

ちなみにリボ払いは海外旅行言った時にオーバーしてて数千円の損害。
学生極貧時代だったのでぶち切れて速攻で銀行を変えたというしょーもない話も思い出した。

数千、数万は勉強代ですよ(キリッ。

【心の声】ちきしょー、300円あれば缶コーヒー3本買えたわ^^

【オブジェクト指向】単一責任の原則について理解を深める

単一責任の原則(SRP)についての理解を深めてくれる良記事。
SRPに違反しているコードを徐々に改良していく丁寧な解説で非常に分かりやすい。

medium.com

記事を紹介する背景

Sandi Metz氏の「オブジェクト指向設計実践ガイド」を数週読了。
しかし、SOLID原則に関する具体例が弱く、腑に落ちない部分が多々あった。

なかなか良記事が見つからず骨が折れたが、上記の記事に巡り会うことができた。

単一責任の原則を生み出したUncle Bobの投稿記事

なお、SRPの考え方を世に出した、Uncle Bobことマーティン氏のブログ記事は下記。

https://blog.cleancoder.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html