iDeCoを考察する

年末年始は投資について調べていた。

prelude.hatenablog.jp

iDeCoの考察をしたので整理をしたい。

iDeCoとは

iDeCoとは「個人型確定拠出年金」のこと。詳しくは公式サイトがあるのでそちらをあたると良い。温かみのあるドメインだ。

www.ideco-koushiki.jp

ざっと調べるとiDeCoには下記の特徴がある。

  • 積み立てたお金を投資に回せる
  • 元本含めて原則60歳まで引き下ろせない
  • 投資の運用益は課税されない
  • 積み立てたお金は所得から控除される
  • 本人の状況次第で毎月の積立金額の上限が変わる

これらのことは少し調べればわかるため、これ以上の説明は省略する。

リスク

1番のリスクは流動性リスクである。これが最大のデメリットでありリスクであると言っていい。もし30歳から始めた場合、60歳になるまでの30年間は引き下ろせなくなる。

また、将来を楽にするために現在持っているお金を積み立てるわけなので、60歳までキャッシュフローは悪化する。
さらに、運用益は課税されないとあるが受取時には課税される。受取方法によって計算が変わるがとにかく課税される。

加えて、iDeCoであろうがファンドに投資する以上は信託報酬が発生する。この信託報酬は大きな額ではないが、iDeCoだからといって無視されるわけではないということは、いざ徴収されて驚かないためにも知っておきたい。

リターン

一方で、銀行口座への貯金と異なりファンドへ投資を行うためそこには運用益が発生する。楽天証券iDeCo対象商品であるたわらノーロード日経225を見ると直近5年間の年率リターンの平均は9.46%である。

さらに、iDeCoには所得控除がある。iDeCoのリスクとしてキャッシュフローの悪化を挙げたが、所得控除による節税のインパクトも考慮しなければフェアではない。

例えば、年収500万円の会社員が毎月2.3万円を積み立てたとする。その場合、500万円から2.3万円✕12ヶ月の27.6万円を差し引いた472.4万円が課税対象となる。詳しくは後述するが、この場合の節税効果は年間およそ8.8万円である。

つまり、キャッシュフローの悪化は27.6万円ではなく、そこから8.8万円を差し引いた18.8万円である(厳密には控除額は年収が確定してから決定するため、iDeCoを利用した翌年以降に適用できる論理である)。

シミュレーション

iDeCoによるリスクとリターンの整理はできた。ここでは具体的な数字を当てはめ、30歳から60歳まで積み立てた会社員をシミュレートする。また、節税効果を投資の配当と捉えてその効果を考えてみる。

設定

  • 勤務先に企業年金がなく、企業型確定拠出年金に加入していない(つまり毎月の積立上限は2.3万円)
  • 毎月2.3万円を積み立てる
    • 簡略化のため年間27.6万円の一括投資とする
  • 30歳現在の年収は400万円、60歳時に1,000万円とする
  • 年収は線形に増加し、年20万円増加するものとする
  • 同じ年収でも人によって手取りの金額は変わるため、簡略化のため下記のサイトから得られた情報をもとに計算を行う

www.musashi-corporation.com

投資としてのiDeCo

設定の通り、毎月2.3万円を30年間積み立てたとする。その合計は828万円である。この全てが投資になるため運用益が発生する。
先ほどのたわらノーロード日経225の年率9.46%に今後30年の不確実性を考慮して0.7を掛けた年率6.6%で計算を行った。30年間の投資額828万円は6.6%の複利により2,426万円になった。 f:id:TakumiKaribe:20210106190201p:plain

節税としてのiDeCo

続いてiDeCoの節税効果について考える。
節税の計算のために手取率を計算し控除後の節税効果を確認する。その後に投資観点でのメリットについて見る。

手取率

先ほどの手取り早見表にある年収の額面と手取りから、手取率の関数を得る。
スプレッドシートで今回の設定範囲である400万円から1,000万円についての手取率をグラフにするとこのようになる。

近似ではあるが手取率は下記の関数であるとわかる。

y = -1.34 / 100000000 * x + 0.847

f:id:TakumiKaribe:20210105230125p:plain

節税効果

手取率の関数がわかったので、年収がわかれば手取がわかるようになった。
この関数を使ってiDeCo利用時の節税効果を確認する。

グラフを見ると年収が高くなるにつれ節税効果が大きくなっている。それは年収に応じて税率が高くなるため年収が高いほど課税対象額の減少による節税効果が大きくなるからだ。
今回の設定上では節税金額の合計は約281万円だった。

f:id:TakumiKaribe:20210108201335p:plain

ちなみに、投資額合計の828万円から281万円を差し引いた547万円を投資した資産で保証できれば元本100%となる。
ただ、元本100%とはいえ30年間の流動性リスクを受け入れ、かつキャッシュフローを毎月2.3万円分圧迫したことは変わらない。むしろリスクのみを受け入れたことになるため、あまりよろしくはない。

利率

iDeCoでどの程度の金額が節税されるのかイメージできた。では、この金額は投資の観点ではどうなのだろうか。

グラフを見ると合計投資額が増えるに従って、利率が小さくなっている。iDeCoは所得控除であり合計の投資額に関係ないからだ。

f:id:TakumiKaribe:20210106190609p:plain

受取

受け取り方法には年金として一定額を受け取る方法と一括で受け取る方法がある。それぞれ控除があり計算方法が異なる。

年金で受け取る場合

数年に渡り受け取る場合は、年金として受け取ることになる。年収から年金控除を行いそこから所得税を差し引く。ここでは年金は想定していないため、iDeCoのみで計算を行うことにする。
年金控除による課税対象の減少は一定率ではなく、130万円以上410万円未満は75%が課税対象になるなど固定の年収の範囲によって課税率が決まる。課税率を掛けた後に年金控除を差し引くのだが、それも同様に年収がどの範囲に収まるかによって決まる。国税庁のサイトが非常にわかりやすいためこれ以上の説明は下記を参照されたい。

www.nta.go.jp

また、所得税についても課税対象額がどの範囲に収まるかによって税率が決まる。これまた国税庁のサイトが非常にわかりやすい。

www.nta.go.jp

なぜこの税率について細かに調べる必要があったのかと言うと、年金として受け取る場合は、5~20年の間で受取期間を選ぶことができる。つまり、年収を自分で決めることができるため、税率をコントロールできるのだ。

今回のシミュレーションの金額の場合で、受取を5~20年間に変化させた時の税率の変化を表にしてみた。

2,426万円を受取年数で割り年収を得る。それに控除を適用し所得税を差し引く。これが年間の「手取り」である。
興味深いのはグラフの形である。固定の範囲で年金控除や所得税の税率が変化するからだ。20年間の受取と13年間の受取の税率は大きく違わないことがわかる。

f:id:TakumiKaribe:20210108221318p:plain

5年間で受け取る場合は344万円の税金を支払うのに対し、20年間で受け取る場合は61万円である。税率を考慮した受取戦略の必要性がよくわかる。

一括で受け取る場合

一括で受け取る場合のことを「一時金」と言う。iDeCoを一時金で受け取る場合は退職金とみなされる。退職金には退職所得控除という控除があり計算方法がある。
こちらも国税庁のサイトが非常にわかりやすいため、ここでの解説は省く。

www.nta.go.jp

今回のシミュレーションだと30年間の積立で退職金の合計は2,426万円である。課税対象額の計算式に数字を当てはめると下記のようになる。

(退職金 - ( 800 + 70 ( 勤続年数 - 20 ))) / 2
↓ 具体的に数字を当てはめると
(2426 - ( 800 + 70 ( 30 - 20 ))) / 2

これを計算すると課税対象額は463万円になる。これに税率20%を掛けて427,500円を控除として差し引くと、徴収される税金は498,500円だとわかる。

一時金で受け取る場合は、2,426万円から498,500円を引いた約2,376万円になる。

所感

iDeCoの所得控除は正しいのか?

計算していて気になることがあった。本来であればキャッシュフローに影響を与えるような"配当"は投資額に対して利率を掛けたものである。しかし、iDeCoの場合は所得控除である。そのため、年収が高い人の方が積み立てた金額に関係なく配当が大きくなっている。本来は、年収が低い人の方が流動性リスクを取っているはずであり、より多くの配当をもらって然るべきなのだが、そうはなっていなかった。
もちろん所得控除を配当と捉えたこと自体が誤っている可能性はある。きちんと金融工学を使ったわけではない。だが、毎月2.3万円を支払う余力のある高所得者の節税効果が大きくなる一方で、流動性リスクを受け入れづらい低所得者ほど節税効果を期待できないというのは非常に世知辛い。
累進課税を行い高所得者ほど税金を高くするのであれば、節税に関する制度は所得が小さくなるほどその効果が大きくなるようにしても良かったのではないだろうか。高所得者であっても運用益が非課税になるのであれば、市場にお金を回してくれることは十分期待できたのではないだろうか。

受取の戦略

これは一括だろうと思う。受け取ったらさっさとETFなどに全額投資し、複利で膨らませながら数年に渡り切り崩す。どういった生活をしたいかによるが、これなら切り崩す割合を調整して税金が高くなりすぎないようコントロールできる上に資産も増えるはずだ。リスクを嫌うならETFではなくETNなどにしても良いと思う。

やるか、やらないか

おそらく下記の事項を意思決定時に考慮すべきだろう。

  • 流動性リスクとキャッシュフローの悪化を受け入れることができる財務状態であるか
  • 他の投資商品と比較して運用益が節税効果を上回るかどうか
    • 828万円を積み立てずとも支払えるのであれば、他の投資商品に回してしまえば運用益が節税効果を上回るだろう

つまり、投資にバンバンお金をつぎ込めるほどではないがある程度の資金力がある高所得者にメリットが最大化する。あとは生活と相談といったところだろう。

リスクゼロというリスク

投資一般に言えることであるが、意思決定の基準は「どこを目標に、どの程度のリスクまで受け入れることが可能なのか」ということである。とにかく多くリターンが欲しいというものではない。
iDeCoは運用益の非課税だけでなく所得控除も発生するため、比較的リスクの小さい仕組みであると言える。ただ60歳まで引き下ろせない流動性リスクをどう捉えるかである。リスクの捉え方・付き合い方をハッキリさせることが非常に重要になるだろう。
この点について、iDeCoを含めた少額投資を行わないというリスク判断はある意味リスクでもある。リスクゼロというのはリターンもゼロなわけだが、それだけではなく資本主義社会においては期待損失が大きい。

数字

計算シート f:id:TakumiKaribe:20210111210214p:plain f:id:TakumiKaribe:20210111210241p:plain

参考

金融工学入門 第2版

金融工学入門 第2版

投資の勉強をした

背景

漠然と将来の不安があって投資を検討したというわけではなく、コロナを機に実家に戻って経済的に楽になったので、資産を銀行口座に眠らせておくより投資して増やしたいなと思い調べ始めた。
実際に給料から毎月いくら何年続けるとどうなるのか、というシミュレーション(皮算用)をしていたら楽しくなってしまった。生活の固定費を不労所得でまかないたいという欲がドバドバ出てきた。(いま実家だから固定費なんてほぼないけどな!!)

投資商品

証券会社のサイトを見るとそこには色んな商品があるが、調べるまでよくわかってなかった。投資と言うと株と債券と金くらいしか知らなかった。

www.rakuten-sec.co.jp

ちなみに自分が知っていた"株"というのは"現物取引"と言うらしい。他にもよくわからない商品があったので調べた。

REITというのは「Real Estate Investment Trust」の略で不動産の投資商品。
ETFは「Exchange Traded Fund」の略で上場投資信託という意味。通常の投資信託との違いは商品が市場に上場しているためリアルタイムに売買ができたりするっぽい。他にも違いがあるけれど、あまりよくわかっていない。ETFは投信の上位互換だという解釈で自分の中では落ち着いている。
他には上場予定株を購入できるIPOや借金してレバレッジを高める悪名高いFXなど。

私はETFをメインに購入する予定なのでここからはETFを中心にわかったことを整理する。

ファンド

お金を集めて運用して利益を分配している業者をファンド(投資信託)と呼ぶ。証券会社はファンドの作った商品を販売しているという形らしい。
ファンドには商品の取引時に発生する「取引手数料」と運用手数料としての「信託報酬」というものがある。前者は名前の通り取引都度、後者は資産に対して決まった年率で定期的に支払う。 これらの「取引手数料」や「信託報酬」はファンドの規模が大きくなると安くなる傾向がある。なぜかというと運用額が桁違いに大きいため手数料が安くても全く問題にならないのである。むしろ「取引手数料」や「信託報酬」が高いところは小規模なファンドであったり社員を養うための企業体力がないところが多いらしい。

大手ファンド

ちなみに2020/11/30での東証一部の時価総額合計は661兆円であるため、これらのファンドを合わせるとは東証一部3つ分を運用していることになる。すごい。

様々なインデックス

ETF投資信託には下記のような指標に従って投資を行うことで、その指標に沿った結果になることを期待するような商品もある。 ただそのインデックスが何のことを言っているのかよくわからなかったので調べた。

東証1部上場銘柄のうち、代表的な225銘柄をもとに計算している。

東証1部上場銘柄のうち、全銘柄をもとに計算している。

  • S&P500(えすぴーごひゃく)

ニューヨーク証券取引所NASDAQに上場している銘柄から代表的な500銘柄の株価をもとに計算している。選定基準は時価総額

  • ダウ平均

ニューヨーク証券取引所NASDAQに上場している銘柄から代表的な30銘柄の株価をもとに計算している。選定基準は株価の平均。

投資戦略

ざっと調べて投資商品の得体が知れたので、私にとっての投資というものを考えたい。5,000兆円を作る必要があるわけではなく、固定費を楽にしつつ将来的に困らない額の資産を作りたいというのが目的である。投資には各人の目的やリスク感度にあった戦略を練る必要があるだろう。

時間軸でアセットアロケーションを調整する

度重なるが、固定費を不労所得によって楽にしたいというのがある。そのため当面は高配当株の比率を高めにした投資をしていく予定である。目標は毎月5万円の配当を得ること。(年率5%だとすると1,500万円)
ちなみに株と債券の比率は「株:債券 = 100 - 年齢:年齢」が良いと言われる。債権はリスクが低いので年齢が高くなるに従い購入比率を高めようということだそうだ。しかし、初めからこの比率に固執せず、固定費が楽になったと感じてから債券を買い足そうかなと考えている。

高配当株ETFによるキャッシュフローの改善

ただ資産価値が高まりやすい銘柄を購入しても現実のキャッシュフローには全く影響がない。むしろ毎月の生活は投資した分だけ苦しくなる。
他の商品も検討したが素人がキャッシュフロー改善をするための投資で手堅く勝つには高配当ETFが良いという結論になった。
獲得したい配当額の目標も定まっているので、それを達成してからポートフォリオを組み替えても全く遅くないかなと思っている。

買いたい銘柄

購入予定の銘柄はState StreetのSPYDとBlackRockのHDVである。これらは高配当株ETFとして投資対象が選定されており、かつ選定企業の業界が互いに補完しているため、どちらも買っておけばリスク分散になる。
iDeCoやつみたてNISAでは上記の銘柄は購入できず決められた投資信託から購入することになる。私はiDeCoでは世界株、つみたてNISAではS&P500のETFを購入しようかなと思っている。
理由としては、世界株は米国以外の国にも投資するため、よりリスク分散が可能な商品である。なので、60歳まで引き下ろせないという流動性リスクを抱えるiDeCoとの相性の良さを感じたからだ。
一方、つみたてNISAは米国株を買う予定だ。その理由は、米国株は安定して高い水準の成長率を誇っており、国内株を買うよりは為替リスクを負ってでも米国株を買った方が良いと思ったからである。

素人考えゆえの漠然とした不安

このあたりプロはどう考えるんだろう。投資する本人が資産をどの程度作りたいのかという目標やリスク感度によって変わるところであるので、色んな人の話を聞いてみたいなと思った。
ただ、流されるよりは自分で調べて銘柄選定までできたので、まずは上々かなとも思っている。変なものを掴まされないようにしたい。

いつから

これだけ書いておいてまだ1円も買っていない。年末年始に調べて証券口座の開設申請などを行っていたためiDeCoは早くて3月から、つみたてNISAは今月からできるのかな?
偉そうなことを書き綴るよりまずは身銭を切りたいところである。

楽天経済圏

ちなみに、証券口座は楽天証券で作成した。楽天の銀行口座と証券口座を紐付けておくと銀行口座の金利が上がるなどといった優遇がある。さらに楽天カードも作ってエポスカードから移行した。
楽天証券ではポイントを投資資金として利用できるため、ポイントが溜まって使いみちに困ることはない。Amazonの方が楽天市場より好みなのだが、甘んじて受け入れてポイ活に努めようと思う。

参考

www.rakuten-sec.co.jp

Amazonでいくつか本を買って読んでみたが、現代の資産形成における投資の答えはインデックスっぽい。アクティブ運用は厳しいから指標に従ったパッシブ運用しか勝たん、とのこと。

雑談

相場の上昇・強気のトレンドのことをBull、相場の下落・弱気のトレンドのことをBearと呼ぶらしい。また、ビジネス用語ではあるが稼ぎ頭をCash Cowと言う。そしてなんと今年は丑年だ。ここから導き出される結論は今年に限り上限いっぱいキャッシングした上で資産全額投資すると5,000兆儲かるということである。なるほどなぁ。

Go言語でgit操作してGitHubにPRを出す

背景・モチベーション

社内ツールにos.Execを多用しているGoのツールがあり非常に厳しい感情になってしまったので、Goできちんと作るならどうなるのかを試してみたい。ツールの具体的な機能としては、ファイルをいじってcommit、pushしてGitHubにPRを出すものだ。
ちなみにGoでgit操作だったりGitHubAPIを提供するライブラリの存在は知っているけれど使ったことはなかった。今回のモチベーションはこれらのライブラリの使い勝手を知っておきたいという理由の方がツールの調教欲よりも大きかったりする。

アプローチ

同じようなことを実現する際にはいくつかの手段があると思う。

  • gitを使いつつPR作成だけは何かツールを使う。
  • GitHubの公式cliを使う。 github.com
  • cli使わず自作しちゃう。(今回はこれ)

今回は自作を前提としているため比較はしない。

作ったもの

github.com ツールというよりはライブラリを使ってみた程度のものなのでこれだけでは動かない。もし実装まで見るとしても参考程度でお願いしたい。

使ったもの

READMEにも書いているけれど下記のライブラリを使用している。 github.com github.com

特徴

特徴らしい特徴はないけれど、gitとGitHubへの操作ができる。(それはそう)
認証方法はアクセストークンとBasic認証+ワンタイムパスワードも実装している。 configのinsteadOfの操作がgo-gitの最新バージョンには含まれていないので、masterの最新バージョンをgo getしている。

感想

ドキュメントがわかりやすい

非常に使いやすかった。godoc読めばある程度操作がイメージできるようになっていて、go-githubに至ってはREADMEが非常にわかりやすかった。

gitわからん

しかし、開発中はgitの内部の知識がなくてgo-gitの動作確認に手こずることが多かった。
go-gitは.git配下を読むため、.git配下にどういうファイルがありそこに何が書かれているのかある程度知っている必要があった。.git/HEADに現在のブランチ名が入っていたり、.git/refs配下にブランチ名やタグ名のファイルがありその中にハッシュが書かれてることは今回初めて知った。ここは動かすために調べてた程度なので誤認しているかもしれない。

sshわからん

また、sshを使ったremoteリポジトリへのpushでは、引数のPushOptionというstructに認証情報を設定する必要があったが、認証情報であるAuthMethodというinterfaceをどう満たしてあげれば良いかわからなかった。
最終的にはgodocや実装を見てNewPublicKeysFromFile という関数で秘密鍵のファイルからAuthMethodを満たした公開鍵情報を作成できることがわかったのが、そこにたどり着くまでに苦戦してしまった。
具体的には、本来は秘密鍵を食わせるべきところで公開鍵を渡してしまっていた。また、id_rsa.pubを渡した際にpem形式にしろと言われたのでid_rsa.pubをpem形式にするための方法を調べたりしていた。id_rsa.pubをpemファイル形式にする方法は調べたらわかったので一応貼っておく。

gist.github.com

モチベーションの整理大事

今回は使えるツールを作ろうとせずにライブラリを触ってみたいというモチベーションだったので設計に拘ったりせず淡々と開発と検証をできた。モチベーションの整理って大事。開発・検証時間はおよそ3時間強くらいだった。簡単な検証って言いつつ若干時間使いすぎた気もする。
作ってみてCIでGoに依存した処理をしているならこういったツールの使い所が多少はあるかもしれないなと思いかけたけど、やっぱりシェルで十分だ なと改めて思った。

雑談

年始に↓を観たけどウォール街の欲望が詰まっていてすごい良かった。

ウルフ・オブ・ウォールストリート [DVD]

ウルフ・オブ・ウォールストリート [DVD]

  • 発売日: 2014/11/26
  • メディア: DVD

【iOS】ファイルのソート方法

XCodeでの開発でファイルのソートをしていますか?

XCodeのProjectファイルはファイルの順序を記憶しているため、ファイルを少し動かしただけでもgitの差分が生まれてしまいます。 複数人で開発していると ファイルの順序によるgit差分 が含まれたPRをたまに見かけますよね。

そのような どうでも良い差分に脳のリソースを使わない ためにも、 ファイルの順序を一意に決定 しておく必要があります。 そして、それは非常に簡単に行なうことができます。

ソートプログラム

ファイルのソートプログラムは野良ツールがいくつかありますが、今回は Apple純正のソートプログラム を紹介しようと思います。 github.com

これはWebKitディレクトリ内のとあるファイルです。リンク先に飛べばわかるのですが、 sort-Xcode-project-file というファイルがあります。 perlが読めないので処理内容はいまいちわからないのですが、ファイルの冒頭に次のコメントがあります。

Script to sort "children" and "files" sections in Xcode project.pbxproj files

これは、まさしく求めていたものですね。

実行方法

このファイルのみ取得し実行するため、下記のようなスクリプトを書きます。

#!/bin/zsh

curl https://raw.githubusercontent.com/WebKit/webkit/master/Tools/Scripts/sort-Xcode-project-file > sort-Xcode-project-file
perl sort-Xcode-project-file <path/to/your/app.xcodeproj>

(ファイル数に依存するとは思いますが)実行時間は短いので上記のスクリプトをBuild Phasesに追加してしまっても良いかもしれません。

生産性に大きな寄与とならないですが、労力かけずにディレクトリの治安が良くなるのでぜひ導入してみてください。

死んだブランチをslackに通知するツールを作った

ブランチ同士で依存が複雑な開発を乗り越えた後ってブランチの消し忘れが案外多かったりしますよね。しかも、消し忘れたとしても実害はない上に、消そうと思えばすぐに消せることも相まって後回しにしてしまうことも多いです。(自分はそう)

 

しかし、消し忘れたブランチが積もるとCUIだろうがGUIだろうがブランチを探す時に見づらくなります。また、似たような名前の開発ブランチを不用意に消してしまうリスクをわざわざ抱えておく必要は全くありません。

 

そこで、開発が停止した死んだブランチをslackに通知するツールを作りました。

github.com

 

実装

複雑なことはしていません。Gitのコマンドを叩いて整形した結果をslackに送っているだけです。

1.gitのコマンドを叩く

長く放置されているブランチを探す必要があったので、リモートブランチを全て取得し、そのブランチひとつひとつについて最終コミットを見ていくことにしました。

f:id:TakumiKaribe:20191103160049p:plain

コマンドの叩いている下の処理では改行で分割したり空白を削除したりHEADブランチを除いたりしています。これでブランチの配列を得られました。

続いて、取得したブランチ名を使ってコミットログを確認します。

f:id:TakumiKaribe:20191103163121p:plain

ログのフォーマットを指定してJSON形式にしています。lexerを作ってtoken列を作り、それをパースしているものを見かけましたが、さすがに面倒くさいですしGo製のgitのライブラリを作っているわけではないので、いじりやすいJSONで良しとしました。

2.logの整形を行う

JSON形式で吐き出させたログをdecodeした後、最終コミッターをkeyとしたmapに構造を作り変えました。こうしておくと通知した際に当事者意識が湧くのでは?という意図からです。GitHubの表記とslackの表記が一致している場合はメンションをつけてしまうのもアリかもしれません。

また、今回の目的は「古いブランチを通知すること」なので、最終コミットが2週間より短い場合は通知対象から除外しました。

f:id:TakumiKaribe:20191103164122p:plain

 

3.Slack通知用の形式にまとめる

slackへのメッセージの表示の仕様は下記のリンクに記載されています。

api.slack.com

そのため、続いてはこのAttachmentにデータを変換します。変換とはいえ実装は単純なのでAttachmentの構造体の定義だけ示します。

※例は上記のリンク先にあるので、他の表示形式が見たい場合は飛んで確認してみてください

f:id:TakumiKaribe:20191103165535p:plain

4.WebhookでSlackに通知する

あとはAttachmentをbodyに突っ込んでpostするだけです。

f:id:TakumiKaribe:20191103165915p:plain

Attachment以外にもユーザー名やアイコンも変更することができます。

※リクエスト先はwebhookを有効にする時にslackが生成してくれるので、それを使います。 

結果

最終コミットから2週間以上のブランチが列挙されています。

この一覧の上部には最終コミッターの名前が入るようになっています。

f:id:TakumiKaribe:20191103170816p:plain

ちなみに、通知を流し見してしまう人のために、ブランチを古い順にソートしています。これで「◯◯日も放置されていたのか...。さすがに消さないとなぁ。」というお気持ちになってもらえれば嬉しいです。

まとめ

久々にGoを書いたので文法を忘れているところがいくつかありました。ただ、シンプルな言語なだけあって、思い出してしまえば手は簡単に動くのでそこまで悩まず作れました。

また、データ構造の整形時にGoroutineを使ってみたのですが、配列やMapに追加する際にロックを入れるせいなのか速くならなかったので断念しました。

f:id:TakumiKaribe:20191103171620p:plain

※10,000件のログ(ブランチ)に対して処理を行っています

 

まだまだ課題として、突貫で作ったのでロジックや命名、責務の分け方は雑ですし、POST先のURLも現在は空文字です。(コミットしていないですがローカルでは値があります)

本当は2週間おきにGitHub Actionsで定期実行する予定でしたが、面倒くさくて取り掛かっていません。。。

このあたりは時間を作ってさっさと改善してしまいたいですね。

 

Golangっぽくない実装や改善できそうな箇所や拡張できそうな機能についてアイデアがありましたら、ぜひコメントorPRを出してもらえればと思います。

【Rust】CircleCIでgrcovを回してREADMEにカバレッジを表示する方法

テスト書いていますか?

 Rustのテストは、公式チュートリアルにもありますがとても簡単に導入できます。 

doc.rust-jp.rs

テストが簡単なのであれば、それを自動化したくなりますよね。

テストが自動化されたら、それを可視化したくなりますよね。

 

今回は、Mozillaが開発を進めているRust製カバレッジ計測ツールであるgrcovを使った自動テストを行い、さらにREADMEにバッジを貼る方法をご紹介します。

続きを読む