詳細は ここ
3回目の確定申告も無事完了！さよなら確定申告！
去年の 6 月に 2 年 3 ヶ月やっていた個人事業を畳んだので、最後の確定申告をしてきました。毎年 3 月は確定申告の感想書いていたので寂しい。個人事業主 1 年目の確定申告におどおどしていた自分が懐かしいぜ
今回は 3 回目の確定申告になるので慣れたものでした。結局、有名な会計ソフトを契約、クレジットカードや口座を連携し、毎月の帳簿付を欠かさず行って、各所から届いた書類 (特に支払い系) をしっかりと整理しておくだけで、確定申告の作業は簡単なものだと思いました。用語などで困ったら YouTube で調べたり、必要書類が探せない場合は各所に電話で相談したりすれば良いです。今年初めて確定申告を経験する友人が数名いるのでそれだけ伝えてます。
過去に現場で出会ったフリーランスエンジニアの方で年間 20 万円くらい支払って帳簿付から確定申告までを外注している個人事業主もいましたが、会計ソフトの最小プランを使えば月額 1000 円程度で完結し、外注用のコミュニケーションも発生しないので自分でやるほうが楽ちんだと思います。エアプですが...
今は法人化して決算を控えておどおどしていますが、個人事業のように慣れればなんてことないとなればいいのですが。。。
今年は特に振り返ることもないくらい一瞬で確定申告終わっちゃいました。2月中に全て終わったのは初かも。まあでも去年は確定申告期限の締切直前で e-tax システム側のエラーあったと思うので、ほんと早いにこした事ないと思う。
以上です。
RailsでAPIのバリデーションエラーレスポンスに使いやすそうなjsonを作る
ActiveModel::Errors クラスの to_hash のメソッドで引数を true にすることで良い感じに作ることができそうでした。あなた引数渡せるのね！
account = Account.new(email: "invalid", password: "") # 無効な値を入れる account.valid? account.errors.to_hash # 引数なし # => {:email=>["は不正な値です"], :password=>["を入力してください"]} account.errors.to_hash(true) # 引数あり # => {:email=>["メールアドレスは不正な値です"], :password=>["パスワードを入力してください"]}
これを良い感じに hash に詰めて返すだけで
render status: 422, json: { message: '不正な入力値です', errors: account.errors.to_hash(true) }
このようなフロントでもそのまま扱いやすいレスポンスを作れます。Rails 便利ぃ〜
{ "message": "不正な入力値です。", "errors": { "email": ["メールアドレスは不正な値です"], "password": ["パスワードを入力してください"] } }
create! や save! などで例外を発生させるような実装にする場合は rescue_form で共通処理を入れてもよさそうです。
class Api::ExamplesController < ApplicationController rescue_from ActiveRecord::RecordInvalid, with: :respond_with_record_invalid_exception def create Account.create! account_params # xxx end private def account_params # xxx end def respond_with_record_invalid_exception(exception) if exception.record.blank? render status: 400, json: { message: '不正なリクエストです' } end render status: 422, json: { message: '不正な入力値です', errors: exception.record.errors.to_hash(true) } end end
単純にフォームの input とマッチする key で各エラー内容を返してあげると、フロントでごにょごにょせずに使いまわせるので個人的にはこの返し方いいなと思っています。もちろんフロントの要件が複雑化したり、サーバでの共通文言以外で返す必要があるケースは多いのですが、単純な構成のレスポンスで問題ないケースでは使っていきたいと思いました。*1
さいごに
Rails は本当に便利すぎる。。こんな実装欲しいなと思った時は Ruby on Rails API を読んでみるとかなりの確率でメソッドが用意されています。たまに気になったクラスの部分を見てみるだけで、知らない便利メソッドに出会えたり、今回のようなオプション的な機能を知れたり楽しいです。他にも Rails っぽい命名なんかを調べるのにもいいかもしれません。こういう動詞使われているかな、用意されている処理の命名と意味がバッティングしてしまわないかなとかとか。。。
*1:個人開発とか...
typoマスターに送るspell checkerのすゝめ
僕はある時期 typo の量産機になっていて、レビューをすり抜けた typo コードたちを無事 (?) 本流にマージさせていました。その typo たちをふとした瞬間に見つけることになるのですが、その時は何とも言えない恥ずかしい気持ちになります。関連のコードを修正するタイミングで fix typo のさりげなコミットを入れることもしばしば。
よくあるのは一字抜けで、例えば registration を registraion としてしまう系のミス。。。こんなん 👀 では気付けない。。。
そこで入れたのがエディタの spell checker。VSCode だと streetsidesoftware.code-spell-checker を導入
なぜかこれまではその手の checker に抵抗があったのですが、実際に入れてみると使い勝手は最高で、typo を生み出すことは無くなり、レビュワー時は typo 発見マシンと化してます。一部の略字 (conf, req, usr etc) は引っかかることも少なく快適です！
これからは tpyo 絶対通さないマン、 fix typo 辞めるマンとしてチームで活躍していきたいです。
以上です。
2022年の振り返り。
今年も無事生き残れたので、振り返りを書いていきます。
2022 年の振り返り
どんなことをやっていたのか
引き続きフリーランスやってた
去年から引き続き BOTech、GovTech のサービスを提供するミドルベンチャーさんとお仕事しています。今月で 1 年半の付き合いとなり、これまでの案件で一番長く契約しています。
税制度の改正などに伴う、新規サービスや新規機能の開発などで初期設計や開発チームのリード的なポジションも経験させてもらいつつ、単価もあげてもらったり、良い雰囲気で契約を続けられています。
もともと開発しているサービスに纏わるドメイン知識に興味があったため、その分野の勉強にもなるので楽しめています。特にバックオフィス関連業務に伴う行政の一部の制度に詳しくなれたりと、法人設立したばかりの僕にとってはありがたい環境です。これまで参画していた案件では一般常識に近いような浅めのドメイン知識を扱うことが多かったので、いまのように士業が関わるような専門性の高い知識と隣り合わせで働けるのは良いモチベーションにつながっています。
技術面は、普通に Rails, React を使った開発をメインです。たまに Node.js や C#、Golang のコードを読んだり、書いたりすることもあります。規模的には各レイヤで分業が進んでいてもおかしくない環境ですが、コードを書くエンジニアは全てソフトウェアエンジニアというロールになり、フロント、バックエンド、インフラのコードを垣根なく見れるので、個人的には嬉しい環境です。
ただ、ガッツリインフラを触る場面はなくなりました。インフラ系からキャリアをスタートした身として寂しい気持ちもありますが、コードを書く方が楽しいので今のところ問題ないです。
ひとり法人をつくった
税金周りのお話や、今後の展望を考えたときに個人事業を会社化しておきたいと思い、ささっと作っちゃいました。
かなり勢い駆動な会社設立だったので、後で手続き多くて後悔みたいなこともありましたが、今は楽しめていると思います。初年度は勉強も兼ね、士業をなるべく使わないで経営してみたいと思い、絶賛年末調整や法人申告について調べている最中です。色々と時間は奪われますが、これも経験だと思い、楽しみながらやってます。
今後の会社の方針についても良く考える時間があり、業務委託を続けるのか、受託やるのか、自社プロダクト作るか、ひとりで続けるか、人を雇うのか、色々選択肢はあるのでこの辺も早めに決めていきたいです。
病気になった
秋頃に皮膚疾患の病気になり、かなり苦しい時期がありました。常に頭部にひどい神経痛があり、強めの鎮痛剤がないと日常生活ができない状況でした。早期治療のおかげで今は症状が治りましたが、ひどい時は二度とベットから起き上がれないのではと不安に思うくらいでした。ストレスや抵抗力の低下が原因の病のようで、より一層健康には気をつけないとなと思いました。
来年の抱負
設立した会社に関する抱負はまだ方針を固めれていないので考え中です。
ここ数年は、転職、独立(開業)、直契約一本化、法人化、と毎年何かしらのアクションを起こしてきましたが、この先にやりたいことが決めれずに行き詰まっているところです。現状維持しかしないなら、法人成りではなくてマイクロ法人でよかったわけですし、設立費用が安く済む合同会社にした方がお得だったと思います。この迷ったときに株式会社として法人成りを選んだのは、自社をひとつの IT 企業として大きくしたいと思う情熱がそこにあったからでした。ただ、会社を大きくするには誰かを雇う・誰かと協力する必要があり、これまで僕一人がやればよかったところから次の段階へ一歩踏み出すことになりそうです。まずこの辺を深く考え、何を今やるべきなのかを具体的に決めていきたいです。
個人の抱負としては、チームのマネジメントができるようになりたいです。今年はチームでリード的なポジションで立ち回っていましたが、自身のマネジメント力の低さを痛感する場面がいくつかありました。重いタスクをメンバーに振れない、自分のタスクに集中しすぎてメンバーの進捗管理が疎かになるなど。無事リリースはできたのですが、もう少し上手くやれただろうという部分が多くありました。来年もしばらくは同じようなポジションを任せてもらえそうなので、色々と考えて動いていきたいと思います。例えば、なるべく重いタスクを細分化して、他メンバーへ任せ、なるべく自分の手が空くタイミングを作るなど。。試してみたいです。
来年も頑張ります〜
以上
「100話で心折れるスタートアップ」を読んだ
界隈 (?) で話題になっていた Twitter 連載マンガが電子書籍としてまとめられていたので、読んでみました。
4 コマ漫画形式の本で、タイトル通り 100 話で心が折れるスタートアップの話なのですが、内容がすごくリアルな感じで面白く、テンポも良くて読みやすく、好みの話でした。
絵柄はかわいらしくポップな雰囲気ですが、内容はかなりリアルな感じがします。界隈の雰囲気を知れた気分です。
実際にスタートアップを起こす、または働くことになった場合に読み物としてどこまで参考にしていいものか判断できませんでしたが、ピボットの流れ、市場調査、資金調達、メンバー集め、に関しての漠然なイメージ感を持てて楽しめました。
スタートアップ、もし自分が実際に当事者になると胃がキリキリして毎晩眠れなくなりそうと思う反面、スリルがあって楽しそうだなと憧れも湧きました。 僕は今年で社会人 6 年目、仕事に慣れ始め、結婚もして、生活基盤が安定してきた "今" から全振りでこういったチャレンジへは踏み出せませんが、小さい時間からチャレンジしてみたいなと思いました。
RailsでControllerに標準のCRUDなアクション以外生やしたくない
ここでいう標準な CRUD とは下記のアクション群 (scaffold で生成されるアクション)
- index
- show
- new
- edit
- create
- update
- destroy
標準のCRUDなアクション以外生やし始めると、徐々にコントローラがカオス化する気がしませんか？
生やしたい派の意見としては共通ロジックをコントローラで使いまわせる、ルーティングからコードの配置がわかりやすい (?)、などなど
でも生やした結果、最終的にコントローラがカオス化してるケースを何件も見てきました。。。 (アクションが数十個、全体で数百行に成長したコントローラ。。。
個人的には、よくある検索用の search や完了ページ的な finish (complite) みたいなアクションでさえ別コントローラに切り出すでよくないかと思ってしまう。それくらい強いルールがあったほうが秩序が保たれるんじゃないかと。。。
実際のイメージですが、Tweet (つぶやき) 用のコントローラを用意したい場合で考えてみます。
class TweetsController # GET /tweets def index # 一覧ページ end # GET /tweets/new def new # 投稿ページ end # POST /tweets def create # 投稿処理 end # GET /tweets/search def search # 検索用ページ end # GET /tweets/finish def finish # 投稿完了用ページ end end
このコントローラを
class TweetsController # GET /tweets def index # 一覧ページ end # GET /tweets/new def new # 投稿ページ end # POST /tweets def create # 投稿処理 end end class Tweet::SearchesController # GET /tweet/search def show # show なのは単一ルーティングで表現を想定しているため end end class Tweet::FinishesController # GET /tweet/finish or /tweets/:id/finish def show # show なのは単一ルーティングで表現を想定しているため end end # routes.rb Rails.application.routes.draw do resources :tweets, only: [:index, :new, :create] do scope module: :tweet do resource :finish, only: :show end end namespace :tweet do resource :search, only: :show end end
このような形で実装する。 上記 routes.rb の記述で作成されるルーティングは下記。
| Helper | Path | Controller#Action |
|---|---|---|
| tweet_finish_path | GET /tweets/:tweet_id/finish(.:format) | tweet/finishes#show |
| tweets_path | GET /tweets(.:format) | tweets#index |
| POST /tweets(.:format) | tweets#create | |
| new_tweet_path | GET /tweets/new(.:format) | tweets#new |
| tweet_search_path | GET /tweet/search(.:format) | tweet/searches#show |
こういう感じで routes.rb で resource(s) ベースでコントローラを作ることをルール化すれば、標準 CRUD なアクションのみ対応でき、実装に統一感もでます。標準 CRUD なアクションのみになるので、7 つ以上のルーティングをひとつのコントローラで制御することがなくなり、シンプルになると思います。
また、コントローラを分割することで、分割されたコントローラ間で利用したい共通ロジックが出てくる場合もあると思います。そうなると、外 (例えば Concern など) に切り出す必要がでるため、コントローラのコード量が減りさらに薄くなります。
外に切り出しやコントローラの分割でファイル数自体は増えるでしょうが、ルーティングの生成されるパスからファイルも推測しやすいですし、大きな問題ではないと思います。
正直コントローラは薄ければ薄いほど嬉しいと思っていて、アクションが数十個、全体で数百行あるようなコントローラは読んでられません。ただでさえ Fat 化させやすいレイヤーだと思うので、個人的には厳しいルールで縛ってなるべく全体の見通しがよくしたいなと思っています。
Rubocop でそういう cop は現時点で存在しないようなので、時間があるときにカスタム cop を作れたらいいなと思っています。
以上です。
