たばりばりスタイル

たばりばりスタイル

バリバリバリ⚡︎

RDP接続ではWindows端末に繋いだカードリーダーで署名できずe-Tax/eLTaxの中間申告でハマった

ひとりで経理頑張ってるマンです。

半年前に初めての決算を終え、法人初年度を乗り越えました。 そして2期目に突入し、一通り経験した経理業務には余裕を持って取り組んでいました。だが、そこに「予定納税」というお初の子がやってきました。初年度には居なかったじゃん。*1

焦ってやり方を調べたのですが、普段使っている経理系のクラウドサービスでは対応していないようで、e-Tax, eLTax を使って納税することにしました。やり方もググれば出てきて、本当インターネット最高!

読みながら進めていくうちに Windows PC でしか使えないネイティブソフトが必要なことに気付きます。仕方なく動画の wmv 変換用に買った miniPC を立ち上げて RDP で作業を進めることにしました。

操作に手こずりながらも送信データの署名部分 *2 まで持ってこれたのですが、ここから先がうまくいかず。。。
カードリーダーとマイナンバーカードで署名しようとするが、どうやってもうまくいかず。ドライバの問題かなと思って調べていましたが、どうやら RDP だとカードリーダー読み込みができないようでした。

mini PC だからドライバ周りが特殊なのかも〜、DVD レコーダーは動くからカードリーダー自体の故障なのでは〜、と勘所が悪く変に時間をかけてしまいました。。。

その後 mini PC に直接ログインするとあっさり署名できました。。。。涙

来年同じところでハマらないように残しておきます。*3

*1:当たり前っちゃ当たり前

*2:送信の直前の作業

*3:無料相談で話を聞いた税理士さんには納税の紙が届くのでそれ払うだけでe-Tax/eLTaxでの申告は不要と聞いた覚えもありますが、裏どりできていないのでそこは来年また調べます

(雑メモ)Railsで参考にした命名のソース

RailsRuby

値オブジェクト名

メソッド名

バリデーションメソッド名
レコード全体のステートに関連するエラーの場合 record.errors[:base]
特定の属性に関するエラーの場合 record.errors[:some_field]
コールバックメソッド名
  • set_xxx
  • remove_xxxx
  • 認証チェック系
    • ref:
      • authenticate_user! : Devise gem
      • require_login : Sorcery gem

GitHub CLIを使ってGitHub ActionsのWorkflowを検証ブランチで試す

repository 内に検証ブランチを作成し、検証に必要なコードや下記のような workflow 定義 yml を配置する
  • workflow 定義 yml で actions/checkout を利用して、検証ブランチを指定
  • 任意のタイミングで実行できるようにトリガーに workflow_dispatch も設定
# 定義例
...
on:
  workflow_dispatch:
  ...

jobs:
  xxxx:
    ...
    steps:
      - uses: actions/checkout@v3
         with:
           ref: <検証ブランチ>

      - name: my job 1
         run: |
           ....
実行する際は GitHub CLI を利用して、下記のようなコマンドで workflow を実行する

GitHub CLI | Take GitHub to the command line

$ gh workflow run [<workflow-id> | <workflow 名>] --ref 検証ブランチ

これで Workflow を検証ブランチで試せます。

この方法で、手元でコードや yml を修正し、検証ブランチへ push。手元でそのまま gh workflow run を実行するような流れで検証しています。

おわり

GitHub Actions に限らずですが、CI・CD 周りの検証には骨が折れます。。。

今回、workflow 内で checkout の設定をしておらず、GitHub CLI では 検証ブランチ に向けて試していて、yml は検証用なのにそれ以外が本流のままだったとうっかりミスで数時間を潰してしまったので、備忘録的に書いてみました。

ActionController::Renderers.add で render_xxx メソッドを撃退

Railsで開発している際、コントローラー内で render_xxx のような独自メソッドをよく見かけます。特に API を構築する際に、render_api や render_json などのレスポンス構成を共通化するために、render json: の処理をラップしたコードをよく目にします。

以下のようなコードです。実際には内部で別のプライベートメソッドを呼び出すなど、複雑な実装が含まれていることもあります。

# api を返すときはこのメソッドを使う ← よく見るコメント
def render_api(object, status: 200)
  render json: {
    data: object,
    status: status
  }
end

# 利用部分
render_api(record, status: 200)

# json レスポンス
# {"data":{"id":1,"created_at":xxx,"updated_at":xxx,"name":"john"},"status":200}

しかしこのアプローチには何か違和感があります。特には複数のプライベートも重ねて実行されることもあり、無駄に application_controller のようなベースコントローラにつらつらと書かれていることも多く、見てて気持ちいい実装ではありませんでした。
常に同じ形式で使用するのであれば、render api: xxx のようなシンタックスがよりスマートであると感じるのではと。

ActionController::Renderers.add による改善

この違和感を解消するための方法として、 ActionController::Renderers.add で renderer を追加するやり方があります。
これを導入することで、render hoge: xxx のような記述でレスポンスを返すことができるようになります。

# config/initializers/add_controller_renderer.rb

ActionController::Renderers.add :api do |object, options|
  json_response = {
    data: object,
    status: options[:status] || 200
  }
  render json: json_response, status: json_response[:status]
end

上記のコードを追加するだけで、以下のようにレスポンスを生成できます。

# コントローラ内で下記のように利用可能
render api: record, status: 200

# json レスポンス
# {"data":{"id":1,"created_at":xxx,"updated_at":xxx,"name":"john"},"status":200}

個人的にはこっちの方がより Rails チックでスマートな記述に感じます。 このアプローチを取ることで、独自のレンダリングメソッドをコントラーラ内部につらつらと追加する必要もなくなります。

api のレスポンスの他にも react 描画用の html などのテンプレ形式で返す際にも便利なのでおすすめです。

初心者の自分用にPhotoshop、Premiere Proの忘れたくない操作方法についての備忘録

最近、あるイベントのムービー作成のために AdobePhotoshop、Premiere Pro を使い始めました。二週間くらい夜な夜な触って簡単な操作ができるようになったので、忘れたくない操作方法について残しておきたいと思います。

Photoshop

顔やスタイルを補正したい

邪魔なオブジェクトを塗りつぶしたい

  • 単純にそれっぽく塗りつぶすだけなら、選択範囲を決めてからメニューの「編集」から「塗りつぶし」を選択する
  • プロンプト文を入れて塗りつぶし部分の処理を行いたいなら、選択範囲を決めてから右クリックから「ジェネレーティブ塗りつぶし」を選択する
    • 例えば、蝶ネクタイを選択して白から黒に変えたり、花の種類を変えたりみたいなことができる ※ 精度はまあまあ
    • Beta 版だけの機能なので Adobe の管理ツール Creative Cloud の「ベータ版アプリ」から Beta 版を DL する必要がある

CapCut - 動画編集アプリ のスタイルにあるような 3d zoom のような動きをしたい

  • 【Photoshop】ズームしながら背景が動くアニメーションgifの作成方法│チャプターエイト を参考にしつつ、ビデオタイムラインを作成して、動画で保存してあげる
    • 被写体レイヤー、背景レイヤーに分けて右クリックからスマートオブジェクトに変換と飛ばすとビデオラインで変形が使えないので注意する
  • 個人的なコツとして背景レイヤーはぼかしつつ、スタートをズーム状態からゴールで原寸サイズに戻す、被写体は大きくズームはせず縦横の移動だけにするとそれっぽくなる気がした
    • ぼかしはメニューの「フィルター」から利用できる

Premiere Pro

動画からオーディオを外したい

不要なオーディオは外して削除しとかないと他のオーディオとバッティングしたりとごちゃつく

動画を分割したい

  • 分割したい対象箇所にカーソルを合わせ Command + K でカット

共有用に動画作成に使った素材の収集したい

TODO:: #### 動画の最後に暗転させたい - 「エフェクト」->「」 #### 動画の速度を速くしたい、遅くしたい、逆再生したい - 動画を右クリック「」

感想

形から入りたくてAdobe 製品を使ってみたのですが、絶賛大苦戦中です。こだわりを入れやすいですが、時間と労力がかかります。気楽にやりたいなら、ポチポチでその辺を一瞬で対応できる CapCut - 動画編集アプリ がおすすめかなと思いました。

プログラム書いていると綺麗な状態をキープしつつ書き、最終的に整頓するみたいな流れになると思います。動画編集の場合はそれが難しく、完成に近づいてどんどん汚くなる (ごちゃごちゃする) のが仕方ない感じで苦手だと思いました。*1
よし、このオブジェクト? 同士はグループ化してこういう命名にしよう!あれグループにしたら個別オブジェクトだけに効かせたい動きができないじゃん!まとめたいけど分けて。。。
よし、関連オブジェクトでレイヤーまとめるぞ!あれ、好みのアニメーションにするには多段レイヤーにしなきゃじゃん!メイン動画のレイヤーと混ぜるか。。。
みたいな。。。

*1:まあ一度切りの利用で保守なんて存在しないし...

なるべく削ぎ落としたい時の rails new

$ bundle exec rails new . --minimal --database mysql --skip-asset-pipeline --skip-test

ためす

とりあえず docker で ruby の環境に入る

$ docker run -it --rm ruby:latest /bin/bash

docker> mkdir myapp
docker> cd myapp/
docker> bundle init
docker> bundle add rails

rails new する

$ bundle exec rails new . --minimal --database mysql --skip-asset-pipeline --skip-test

構成

$ tree . -L 1
.
├── Gemfile
├── Gemfile.lock
├── README.md
├── Rakefile
├── app
├── bin
├── config
├── config.ru
├── db
├── lib
├── log
├── public
├── tmp
└── vendor

app 配下

$ tree app/ -L 1
app/
├── assets
├── controllers
├── helpers
├── models
└── views

ここから app/assets や app/helpers を消すと MVC (Model View Controller) 以外のディレクトリが app 配下から排除することもできる

chatgptを使ったプロダクトにほんの少し関われた話

現在参画中の現場で、chatgpt を使った新規プロダクト開発に関わる機会があったので感想を残しておこうと思います。 普段は別でメインのプロダクト開発に取り組んでいますが、今回はリリースまでの一時的な助っ人として開発に参加することになりました。

このプロダクトは比較的小規模なサービスで、SPA + サーバレスなバックエンドの構成が採用されました。 実装メンバーはメインエンジニアと僕の2人で、サービスの構想からリリースまでかなりタイトなスケジュールでの開発が求められました。 僕はフロントエンドの開発を担当したのですが、明日までに検証環境で動かせるようなベース部分を作って PR を立ててほしいみたいなスピーディな感じでした。

僕の実装は主にフロントエンドだったため、chatgpt API の呼び出しやプロンプトの調整などには直接さわることはありませんでした。ただ、コードレビューや検証には参加したため、その実装のイメージを掴むことができました。API の結果をバックエンドで整形して返すので、出力もいい感じになるようなプロンプトする必要があったりだとか...、どうしても突拍子もない結果を返す可能性があるため、その辺の制御をどうするかとか...

今回の開発に関わってから、chatgpt によって実現できる対話性がある ? UX についてすごく可能性を感じれた良い経験になりました。新しいことしているといった高揚感もあり良かったです。

現場では他にも chatgpt を使ったプロダクトの開発案が進んでいるようで、そのスピーディさに驚いています。普段さわるメインのプロダクトにも導入が検討されているようで楽しみです。