【お約束】 投稿内容は個人の見解であり、所属する（していた）組織の公式見解ではありません。
名前：uyamazak（昔いた会社で上司が開発用Linuxサーバーのユーザー名に「yuyamazaki」が長いので勝手に作ってくれた。読み方わからないけどウヤマザク）
高校あたりからWEBサイトをやったり趣味の延長でWEB系を仕事にした感じの人間。
2020年1月から株式会社シニアジョブにジョイン。
2021/1現在、まだ開発者は３人、これからの会社なのでビジネス貢献しつつ、きれいな設計をしたい
アズールレーン@竹敷でモバイルのUI、UX研究中（初嫁ジャベリン）
フレンド＆大艦隊メンバー募集してます ID:939524678 @竹敷
GitHub: https://github.com/uyamazak/
これまでの主なプロジェクト
続きを読む2020/1/14よりシニアジョブに入ったのでほぼ1年。ざっと振り返り。
GitHubを仕事で使えるようになったので草もたくさん生やせました。
1ヶ月のときに書いたのはこれ。
uyamazak.hatenablog.com
その後のトピック的には
まだオフィスで稼働してて換気の目安になってます。
uyamazak.hatenablog.com
ソースコード
GitHub - uyamazak/co2signals: Co2 Sensor System. Raspberry Pi + MH-Z19B + Firebase
社長いわく営業の労働時間短縮にはこれが一番効いたらしい（後日詳細が？）
uyamazak.hatenablog.com
まだ一部ですが、導入できました。超早いし超便利なのに超安いのなんなの。WITH文とかWindow関数とか使ったのも初めてだったかも。
SEO対策も兼ねて、エラー潰したり、高速化のために不要なnpmパッケージ消したり（moment.jsとかmoment.jsとか）いろいろやりました。
その他いろいろ社内システムの自動化まわりを結構やった気がする。
とくに給与計算とか源泉徴収とか、ただでさえややこしいのに、設計とかコードがひどい所を見ることとなり、精神的つらみがありました。
勤怠とか給与はいいのがたくさんあるので、はやく外部API連携したい・・・。
健康診断でLDLコレステロールや中性脂肪が高めなこともあり、ランチで野菜を取ろうと決意。
会社近場でいろいろ試したけどサイゼリヤが最強っぽいと思い、出社日は必ずサイゼリヤで食べることに決定。
あと新型コロナの影響もあり、広めで感染対策ちゃんとしてそうというのもポイント。
800円程度を上限として、いろいろ試したけど、コールスローサラダがつくランチセット各種（500円）と柔らか青豆の温サラダ(200円)か、ほうれん草ソテー（200円）と組み合わせがずっと食べられそう。
今日はエビとブロッコリーのオーロラソース500円と、柔らか青豆の温サラダ200円。ブロッコリーとトマトが載ってるけど思ったより量が少なかった。やっぱランチセット500円のサラダ強い#サイゼリヤ野菜ランチ研究 pic.twitter.com/yNFO91SQnX
— uyamazak - 🐦 (@uyamazak) 2020年10月12日
でもこれを見てからオリーブオイルをたっぷりかけるようになりました。
今では無事オリーブオイル中毒となり、野菜よりもオリーブオイルを求めてサイゼリヤに通ってます。
健康漫画「サイゼリヤに一週間通って血液をサラサラにしてきた話（全３ページ）」#俺は健康にふりまわされている pic.twitter.com/sRv5jTMKOB
— 宮川サトシ＠1月7日『ワンオペJOKER』連載開始 (@bitchhime) 2020年10月14日
緊急事態宣言終わって出社したらまた行きたい。
友人と話して勢いでやった。ブラウザで動画作れる時代になったんだなぁと。
だいぶTypeScriptにも慣れてきたので、ずっと温めてるキャラクター駆動開発を進めたい。Vue3かReactでかなぁ。
あとやっぱり趣味を仕事にしてる影響もあり器用貧乏なので、なにか強い軸みたいなものがほしいなぁと漠然と思っていたり。
新型コロナ中は自粛してるけど、やっぱサウナ行きたい。
BigQueryでGROUP BYした項目を文字列結合したいとき、レガシーSQLでは`GROUP_CONCAT`を使ってました。
標準SQLにはなく、検索しても見つけづらかったのでメモ。
STRING_AGGが使えます。
STRING_AGG([DISTINCT] expression [, delimiter] [ORDER BY key [{ASC|DESC}] [, ... ]] [LIMIT n])
[OVER (...)]
標準 SQL の式、関数、演算子 | BigQuery | Google Cloud
DISTINCTで重複除けるし、ORDER BYもここでできちゃうので、ID順とかで結合したいときこれだけでできてしまって超便利
こんなデータの場合、
WITH testData AS ( SELECT 1 AS id, '赤身' as type, 'ブリ' AS name UNION ALL SELECT 2, '赤身', 'いわし' UNION ALL SELECT 3, '赤身', 'アジ' UNION ALL SELECT 4, '赤身', 'マグロ' UNION ALL SELECT 5, '赤身', 'カツオ' UNION ALL SELECT 6, '白身', 'タイ' UNION ALL SELECT 7, '赤身', 'サバ' UNION ALL SELECT 8, '白身', 'タラ' UNION ALL SELECT 9, '白身', 'フグ' UNION ALL SELECT 10, '白身', 'サケ' UNION ALL SELECT 11, '白身', 'サケ' ) SELECT * FROM testData;
| 1 | 赤身 | ブリ |
| 2 | 赤身 | いわし |
| 3 | 赤身 | アジ |
| 4 | 赤身 | マグロ |
| 5 | 赤身 | カツオ |
| 6 | 白身 | タイ |
| 7 | 赤身 | サバ |
| 8 | 白身 | タラ |
| 9 | 白身 | フグ |
| 10 | 白身 | サケ |
| 11 | 白身 | サケ |
SELECT type, STRING_AGG(name) FROM testData GROUP BY type ;
で
| 1 | 赤身 | ブリ,いわし,アジ,マグロ,カツオ,サバ |
| 2 | 白身 | タイ,タラ,フグ,サケ,サケ |
サケが重複してるのでDISTINCTつけると
SELECT type, STRING_AGG(DISTINCT name) FROM testData GROUP BY type ;
| 1 | 赤身 | ブリ,いわし,アジ,マグロ,カツオ,サバ |
| 2 | 白身 | タイ,タラ,フグ,サケ |
サケ消える。
DISTINCTとODER BYを同時に使うときは同じ項目でしかできない
SELECT type, STRING_AGG(DISTINCT name ORDER BY name asc ) FROM testData GROUP BY type ;
| 1 | 赤身 | いわし,アジ,カツオ,サバ,ブリ,マグロ |
| 2 | 白身 | サケ,タイ,タラ,フグ |
区切り文字の指定はちょっと癖がある感じ
SELECT type, STRING_AGG(DISTINCT name , 'と' ORDER BY name asc) FROM testData GROUP BY type ;
| 1 | 赤身 | いわしとアジとカツオとサバとブリとマグロ |
| 2 | 白身 | サケとタイとタラとフグ |
あと今回はウィンドウ使ってないけどOVERで指定したり、LIMITも書けるので大抵のことはできそう。
Google Cloud Platform 実践 ビッグデータ分析基盤開発ストーリーで学ぶGoogle BigQuery
業務で年末調整処理の一部、源泉徴収の給与所得控除後の給与等の計算を実装したけど
いろいろつらかったことをメモする。主に行政資料への不満。
従業員として出すだけでも面倒な年末調整ですが、もちろんその背後で行われている処理はもっと面倒です。
資料だけでこんだけ数も有り、
一括ダウンロードするとPDFで30MB超え。
でも今回、業務で必要だったのは下記の1枚だけでした。
Ⅵ 電子計算機等による年末調整
https://www.nta.go.jp/publication/pamph/gensen/nencho2020/pdf/82-83.pdf
でも、この一つだけでも結構ストレスフルでした。
桁数が多いので、手打ちは避けたいのでコピペすると思うんですが、こうなります。全角です。
１，６１８，９９９円まで
電子計算機で全角数字使うのかと・・・。
コピペしたあとVSCodeの拡張で半角に変換して使いました・・・。
ここもコピペしたいのですが、コピペすると
こうなります。行ごとに整形しなおす必要があります。
１円から ５５１，０００ 〃 １，６１９，０００ 〃 １，６２０，０００ 〃 １，６２２，０００ 〃 １，６２４，０００ 〃 １，６２８，０００ 〃 １，８００，０００ 〃 ３，６００，０００ 〃 ６，６００，０００ 〃 ８，５００，０００ 〃 ５５０，９９９円まで １，６１８，９９９ 〃 １，６１９，９９９ 〃 １，６２１，９９９ 〃 １，６２３，９９９ 〃 １，６２７，９９９ 〃 １，７９９，９９９ 〃 ３，５９９，９９９ 〃 ６，５９９，９９９ 〃 ８，４９９，９９９ 〃 ２０，０００，０００ 〃 ０円 Ａ－５５０，０００円 Ａ×６０％＋９７，６００円 Ａ×６０％＋９８，０００円 Ａ×６０％＋９８，８００円 Ａ×６０％＋９９，６００円 Ａ×６０％＋１００，０００円 Ａ×７０％－８０，０００円 Ａ×８０％－４４０，０００円 Ａ×９０％－１，１００，００
推測ですが、エクセルでこの3カラムをつくり、行を使わずセル内部で改行してる作ってると思われます。
先日出た改善案どおりに作ってくれればこんな面倒なことしなくて済んだのに・・・。
お役所「Excel」の改善案が公開 ～あかんヤツ→ええヤツの例がわかりやすく、一般市民にも結構参考になる - やじうまの杜 - 窓の杜
来年この資料が直ってなかったらしかるべきところに届け出たいと思います。
まあ法律でそうなってるんでしょうが、
１，６１８，９９９円から１，６２３，９９９円の狭い範囲だけ、
なんでこんな処理が必要なんでしょうか。もっとシンプルにしようって人は誰もいなかったんでしょうか。
さすがに実装して動かすと、あーこの表↓みたいな段階的な数字にしてるのかーって何となく分かったけど初見はつらい。
1000円未満切り捨てみたいのは会計でよくみるし、全部それでいいじゃんって思ってしまう・・・。
https://www.nta.go.jp/publication/pamph/gensen/nencho2020/pdf/84-92.pdf
こんなネ申エクセルを元にしたPDF資料じゃなくて、プログラミング言語のサンプルコード置いといてくれよ！
と思ったので今回PHPで書いたコードを雑にTypeScript化、変数名に日本語を試してみたかったのもあり、Gistに置いておきました。
日本語でもVSCodeも問題なくnodeでも普通に動いた。
こういう国特有の法律用語って絶対正確な英語にはできないので、日本語のままが楽ちんだなぁと思うけど、いろいろ問題もあるので実際の現場では使えることはなさそう。
問題起きてももちろん責任は取れません。
tscして自分のPCのnode(v14.14.0)で実行するとこんなの風に出ました。
給与所得控除後の給与等の金額 { '給与': 551000, '給与所得控除後の給与等の金額': 1000 }
給与所得控除後の給与等の金額 { '給与': 1872000, '給与所得控除後の給与等の金額': 1230400 }
給与所得控除後の給与等の金額 { '給与': 2612001, '給与所得控除後の給与等の金額': 1748400 }
給与所得控除後の給与等の金額 { '給与': 4272000, '給与所得控除後の給与等の金額': 2977600 }
給与所得控除後の給与等の金額 { '給与': 9800000, '給与所得控除後の給与等の金額': 7850000 }
給与所得控除後の給与等の金額 { '給与': 20000000, '給与所得控除後の給与等の金額': 18050000 }ちなみに来年には外部のサービスと連携してるつもりなので、こういうコードはもう二度と書かない予定です。
経理の皆様、こういうソフト作ってる皆様お疲れさまです。
プログラミングTypeScript ―スケールするJavaScriptアプリケーション開発
