Job on ashitaka blog

AWSのアカウントは分けると安心

Sun, 31 Jul 2022 07:37:52 +0900

自分がAWSを触ったのは、大学院時代に友達と簡単なWebサービスをデプロイするときに使ったのが初めてでした。1通り基本的なことを学ぶために、udemyの教材を使って基本的なリソースをマネジメントコンソールから作って削除していました。

そういった個人的な開発をする中ではなかなかAWSアカウントを複数作ることはなく、1つのAWSアカウントの中にサーバーやデータベースを作ることが多いです。

しかし、現職に入社してIDaaS経由でAWSの権限をもらったときに大量のアカウントが表示されていてびっくりしました。今ではとても理に適った管理方法だなと思うので、その感想をつらつら書きます。

参考

AWSのマルチアカウント戦略ってなに？なぜ必要？【社内勉強会スライド】

https://dev.classmethod.jp/articles/why-aws-multi-accounts/

メリット

権限が分離されている安心感がすごい

現職ではサービスの環境をDevelopment、Staging、Productionの3種類にわけていて、アプリケーションをEKSで動かしています。

1つのAWSアカウント内でこれをやろうとすると、環境ごとのVPC、IAM Role、EKSクラスタを作ったりする必要があり、ちゃんと分離できているのかが不安になります。

しかし、環境ごとにAWSアカウントを作成するとこんな感じになります。

お互いが絶対に干渉しないので、内部の設定ミスによる事故を防いだり、外部からの攻撃の影響範囲を制限することにつながります。

工夫が必要な点

初期に必要なAWSリソースをCloudFormationで作成

Terraformを使って各AWSアカウントのリソースを管理したいところですが、初期の状態ではTerraformを実行するためのIAM Roleもないわけです。それをアカウントごとに作成するのは大変なので、CloudFormationを使って最低限必要なリソースを全てのアカウントに対して作成します。

AWS Organizationを使ってAWSアカウントをOrganization Unit単位でグルーピングしておけば、より細かいリソース作成が可能になります。

Transit Gatewayを使ってAWSアカウントをまたがった通信を行う

各サービスにおいてEKSクラスタを共有させたいが、DBやStorageは別アカウントで持たせたいということもあると思います。実現する方法の1つとして、Transit Gatewayを用いる方法が挙げられます。

この記事をとても参考にさせてもらいました🙏

Transit Gatewayを利用してVPC間で通信してみた

https://dev.classmethod.jp/articles/transit-gateway-vpc/

まとめ

現職でプロダクトの開発に携わりながら、こういったインフラを扱うSREのタスクもやらせてもらっていて、学んだことを残していこうと思います💪

Goのエラーハンドリングが好き

Sat, 16 Jul 2022 00:40:42 +0900

Goとの出会い

自分がGoを触り始めたきっかけは、大学院1回生の時に研究室の先輩と一緒に出たISUCONでした。パフォーマンスの観点でGoがめっちゃいいらしいからGoで出ようってなって、Go Tourなんかで勉強してました。

当時なんでもGithubにpushしたい病だったので、よーわからんリポジトリもありました。

https://github.com/adshidtadka/go_tour

エラーハンドリングがめんどくさい

そもそもプログラミングをちゃんと始めたのが大学4回生のDonutsでのアルバイトで、経験が浅いなんちゃてプログラマーでした。つまり、エラーハンドリングなんてかったるいと思っているわけです。

そんなマインドでGoのコードを読むと、どんな関数もerrorを返してくることにびっくりします。

こんな感じで何か関数を呼び出すとすかさずerrorが帰ってくるので、いちいちエラーハンドリングを書くのがめんどくさく握りつぶしたいという思いに駆られることが幾度となくありました。

type Result struct{}

func doSomething(code string) (*Result, error) {
	if code == "ok" {
		return &Result{}, nil
	}
	return nil, errors.New("エラーだよ")
}

func main() {
	_, err := doSomething("error")
	if err != nil {
		// エラーハンドリングをいちいち書かされる
	}
}

他の言語の多くにはtry-catchの仕組みがあるので、こっちのが絶対便利とか思っていました。


type Result = {};

const doSomething = (code: string): Result => {
  if (code === "ok") {
    return {};
  }
  throw new Error("エラーだよ");
};

const main = () => {
  try {
    const result = doSomething();
  } catch (e) {
    // ここ1箇所でまとめてエラーハンドリングできる
  }
};

やっぱりエラーハンドリングしたい

大学3年、社会人2年の時を経て考え方が変わりました。関数たちに対して思うことはエラーを勝手にthrowせずにちゃんと返して欲しいと思うようになりました。

その理由の一例がこちらです。最近プロダクトを開発する中で、不具合調査に時間がかかった例でもあります。

type Result = {};

const doSomething = (code: string): Result => {
  if (code === "ok") {
    return {};
  }
  throw new Error("エラーだよ");
};

const main = () => {
  try {
    const result = doSomething();
    const result2 = doSomething(); // こいつが呼ばれるかどうかわからない
  } catch (e) {

  }
};

try句のコードは全て呼ばれるわけではないのです。勝手にジャンプしてcatch句にいく可能性を考えてコーディングする必要があります。try句には長い処理を書かない方が無難でしょう。

React Hooksに対するテストを書いていきたい

Sat, 09 Jul 2022 02:30:50 +0900

ご無沙汰しております。会社のプロダクトチームの新しいメンバーの方がGoのLT会に出ておられて、自分もそういった個人での活動をしたくなった次第です。

React Hooksとは

以下の公式ドキュメントが詳しいです。

https://ja.reactjs.org/docs/hooks-intro.html

前職ではAngularで開発を行なっていたのですが、コンポーネントを定義するためにクラスを定義していて、意図しないタイミングでインスタンス変数が書き換わっているみたいなことがザラにありました。

Hookがない時代のReactも触ったことがあったのですが、同じようにクラスを定義してごにょごにょしなければいけないイメージがあって、現職でReactを触り始めるまではAngularもReactもさして変わらんでしょ、と思っていました。

結論、ReactのHookによりReactがとても気に入りました。関数でコンポーネントを定義できるので理解しやすく挙動も予想しやすいですし、カスタムHookを定義することでコンポーネントのロジックの部分だけを簡単に再利用することができます。

なぜHookに対してテストを書くの?

Hookはコンポーネントのロジックを司る部分であるため、テストが書きやすく実行も早いからです。

Hookだけでなく、コンポーネントに対してももちろんテストを書くことができます。以下のレシピ集においても、DOMどんな要素が描画されているのかをテストする方法が示されています。

https://ja.reactjs.org/docs/testing-recipes.html

しかし、DOMに対するテストは書きにくいです。評価する部分を書く際にcontainer.querySelector("strong").textContent みたいな感じで要素にアクセスする必要があるのですが、DOM構造を知っていないと書けません。要素があるかないかではなくDOM構造をテストしたいのであれば、テストを書くのではなくStorybookなんかを使って見た目を確認する方が本質的です。

また、DOMに対するテストは実行に時間がかかります。DOMの描画自体に時間がかかるというのもありますし、依存しているコンポーネントもビルドしなければならないという原因もあります。

前職ではDOMに対するテストがビルド時間短縮のボトルネックになっていて、JasmineからJestに移行することでいくらか速くならないかみたいなことを試行錯誤していました。

そこで、Hookに対してテストを書くわけです。HookにはDOM構造の概念がなく、stateに対して評価が書けます。DOMを描画する処理もなく、他のHookに依存しているみたいなことも少ないです。

どうやって書くの?

以下のドキュメントにある書き方を拝借させていただきます。

https://react-hooks-testing-library.com/usage/basic-hooks

こんな感じのカスタムHookがあれば、

import { useState, useCallback } from 'react'

export default function useCounter(initialValue = 0) {
  const [count, setCount] = useState(initialValue)
  const increment = useCallback(() => setCount((x) => x + 1), [])
  return { count, increment }
}

こんな感じでテストがかけます。

import { renderHook, act } from '@testing-library/react-hooks'
import useCounter from './useCounter'

test('should increment counter from custom initial value', () => {
  const { result } = renderHook(() => useCounter(9000))

  act(() => {
    result.current.increment()
  })

  expect(result.current.count).toBe(9001)
})

よくないですか?? 評価対象がHookの返り値としてreturnされるので、result.current.count みたいにさくっとアクセスできちゃいます。Hook内で作ったCallbackを呼び出したい時も、結局Hookの返り値としてreturnされるので、result.current.increment() みたいにさくっと呼び出せちゃいます。

エンジニアの仕事をなるべくわかりやすく書いてみる

Tue, 22 Mar 2022 06:46:02 +0900

自分は2018年から2020年3月まで大学院で2年間情報学を勉強・研究してエンジニアリングに触れ、2020年4月からはヤフー株式会社で新卒として企業でのエンジニアリングを学びました。2021年5月から株式会社グラファーに転職して、今現在”スマート申請”という製品のエンジニアとして働いています。

しかし、一口にエンジニアといってもやってていることはバラバラで、エンジニア同士であっても何してるかは見えてこないのに、ましてやエンジニアでない人は本当に何してるか想像もつかないと思います。

そこで、なるべくエンジニアでない人でもわかるように自分が毎日どんな仕事をしているか説明してみようと思います。

ちなみにスマート申請って何

オンラインで行政手続きが完結できるようにする製品です。一般的なwebフォームに必要な情報を入力して送信するだけで申請が完結します。

ざっくり何してるの

基本的にはユーザーがかかえている課題に対して、課題を解決する方法を提供することが自分の仕事です。こんなもの作って欲しいみたいな設計書が上司から渡されて、スケジュールに間に合うようにそれ通りになんか作っているわけではないです。

最初にすること

まず、ユーザーがどんな課題を持っているのかを特定します。

過去に自分が取り組んだ内容を噛み砕いたものが、”申請者に必要な入力項目だけ表示してほしい”というものでした。

しかし、”必要な入力項目だけ表示してほしい”というのは機能要望であって、課題ではありません。

“なぜ必要な入力項目だけ表示したいのか?”という問いから、”項目いっぱいあったら読むのに負担がかかるから”のように課題の形に変換し、”なぜいっぱいあったら負担がかかるのか?”のように課題をどんどん深掘っていきます。

その過程で、エンジニアの自分がユーザーにインタビューすることもありますし、ユーザーに近いビジネスのメンバーとディスカッションすることもあります。

結論、”必要かどうか判断する認知コストがかかる”というのが課題と判断しました。

課題の深掘り

課題を深堀りして特定できれば、それが解決できる方法を考えて、その課題を解決できるような機能要求に落とし込んでいきます。

先程の”必要かどうか判断する認知コストがかかる”の課題に対する要求としては、”不必要な入力項目は隠せるようにすること”のような形になります。

この機能要求で課題が解決されるかを確認します。

必要かどうかの判断を申請フォームが行って不必要なものを隠してくれたら、認知コストの課題は解決されそうですね。

いざ開発

要求を洗い出して要求を満たすことで課題が解決できると確認できたら、実際に開発を行って行きます。ここからがエンジニア以外の方に説明するのが難しいのですが。。。

エクセルで関数を使ったことがある方ならば、”SUMというエクセルの関数を使って、複数のセルの合計する”という要求を満たすことができると思います。

SUMの使用例

そんな感じで、”JavaScriptというプログラミング言語を使って、その項目が不必要であれば隠す”という要求を満たします。

エクセルだと最終的に式が出来上がりますが、プログラミングだと最終的にソースコードが出来上がります。

開発できたことをテストで証明

まだまだやることはたくさんあります。次にテストを書きます。

エクセルでsumを使って合計を計算するときも、ちゃんと合計が計算されるようになっているか確かめるために、セルにいろんな数字を入力すると思います。

300から100に変更

合計が800から600に変わる

同じことをエンジニアも行います。フォームにいろんな入力をしてみて、不必要と判断される場合にちゃんと隠れるのを確認します。

しかし、エンジニアはここで飽き足らずこれが自動的に確かめられるようにします。それがテストコードと呼ばれるものです。

テストコードを作ってそのコードを実行すると、必要な項目は表示されるし不必要な項目は表示されないことが自動的に確かめられます。ソースコードがちゃんと動く証明書がテストコードです。

ソースコードを組み合わせる

手元のPCで作って正しく動くことが確かめられても、ユーザーの課題は解決されません。ユーザーの方が触る申請フォームにこの機能を取り入れねばなりません。

パワポを複数人で編集したことがある人はわかると思うのですが、最新版だと思って自分の編集を取り入れてみたら、実は古いバージョンで、他の人の変更が反映されてなかった！みたいなことがあると思います。

エンジニアも複数人でソースコードを編集するのでこれが起こることは必死です。

そこでエンジニアはgitというバージョン管理ツールを使って、間違って古いバージョンが入らないようにします。

いざユーザーの手に

最後にユーザーに手が届くところにソースコードを持っていきます。

サーバーと言ってどんなふうに解釈されるか想像もつかないのですが、みなさんがスマートフォンでアクセスする先には必ずサーバーがあります。ここにアクセスしてもらってユーザーは申請フォームを見ることができます。

ですので、そのサーバーにあったソースコードを最新版のソースコードに入れ替えてあげることでやっとユーザーに機能が届きました🎉

ユーザーに機能を届けることを私たちはリリースと呼びます。

機能のリリース≠課題の解決

課題が解決されるように機能要求を考えて開発はしたのですが、実際に機能をリリースすることで課題が必ず解決されるとは限りません。実際にリリースした機能を使ってもらったユーザーの課題が解決されることを確認するまでがエンジニアの仕事です。課題が解決されていなければ、なぜ解決されていないかさらなる深掘りを行って、製品で解決できるものでれば改善を行いつづけます。

まとめ

自分も大学院に入るまではエンジニアリングの仕事が実際何をするのか全く分かっていなかったのですが、4年たってやっと1人前のエンジニアとして働けるようになってきたと感じています。

製品を作るエンジニアリングはこのような仕事かなと思うのですが、それ以外にもやらなければいけないことはたくさんあって、詳しくなった時に紹介できるような記事を書こうと思います!

2021年4月をもって転職する話

Thu, 01 Apr 2021 17:22:23 +0900

会社を評価するものではなく, 自分がどういう状況なのかを説明するためのものです。

マネジメントコンソールの開発

2020年4月から入社して研修が終わった後, 6月中旬から社内ツール開発のチームに配属されました。

社内ツールと言っても100以上のツールがあります。しかし, 各ツールのチームがそれぞれにUIを開発するため, サービスを開発するエンジニアは使いたいツールに辿り着くことが難しく, また横断的に使えないことが問題でした。

そこで, 社内のあらゆるツールを簡単に横断的に使えるUIを提供するのが我々のチームのミッションです。大袈裟に言ってみればAWSマネジメントコンソールの社内版を作るようなもので, 非常にやりがいのあるプロジェクトです。

幅広いスキルの獲得

このチームでの開発を通して非常に多くのスキルを身につけることができました。

Angular + TypescriptでのUI開発
Node + Express + TypescriptでのAPI開発
Nginxを使ったProxyの設定
ChefやKubernetesを使った構成管理
Open IDを使った認証周りの設計
スクラムやLeanでの開発
Unit, Integration, E2Eテストの作成
システム監視の設定
デザインシステムを使ったWD

こんなにも多くの技術スタックに触れるのは本当に幸運だと思います。

Gov-techへの興味

いま思い返せば, 自分はWebサービスによって便利になることに目がありませんでした。高校のころは, リリース当初のLINEを使って夏休みの課題を共有したり, iPod touchを使って漫画を読むのにDropboxを活用していました。他にも, 自分たちの代の文化祭のソーラン動画をYoutubeにアップロードしたりもしていて, 毎年再生回数を稼がせていただいております。

そんな性だからこそ, 行政サービスが不便なことに対して不満を抱いてしまいます…マイナンバーカードが発行された当時, このカードでいろんな手続きが簡単にできるようになる未来にわくわくしていたのですが, 生憎コロナ禍での給付金の手続きすら電子署名の失効によりできませんでした。

前回のブログでエストニアに関する本をいくつか挙げました。日本がエストニアのように個人情報を安全にかつ使いやすい形で管理して, 民間企業がそれを活かせる様になって欲しいと思っています。

偶然の出逢い

ここから前々回のブログの続きになります。

threeで出会った方がVCで働いておられたのでGov-tech領域の会社がないか聞いたところ, あるスタートアップ企業を紹介していただきました。

総務省で働いている先輩がいたので, 先輩にその会社のことを聞いてみたところ, タイミングよくその会社の方とお会いする機会に同席させていただきました。

その方にいろんなお話を伺っていくうちに仕事に魅力を感じて, 副業として働かせてもらえないかとお願いしたところ, 面接を経てインターンという形でお仕事をさせていただくことになりました。

転職を決心

インターンを終えてオファーをいただきたくさんの方と相談させていただいた結果, 4月末をもって今の会社を退職し, 5月から新しい会社で働くことに決めました。

今の会社はエンジニアを大事にする会社ですし, 最近盛り上がっていますし, 働き方も柔軟で, プロダクトも好きで, 楽しいチームだったので正直かなり迷いました。新卒1年目でまだまだ修行するつもりだったという思いもありました。

いろんな要素を比較検討しましたが, 最終的に自分がやりたいことかつ自分がやったほうがいいことという基準で判断しました。

関わってくださった方へ

今回の転職するにあたってたくさんの人にお世話になりました。

swiftの画像キャッシュライブラリ

Sat, 11 May 2019 06:13:48 +0900

iOSアプリケーションにて画像を表示する際, URLから非同期でデータを取得してUIImage化するという処理がなされていて, それを簡単に書けるライブラリを紹介する. ここでは, 以下の2つのサイトを参考にした.

iOSアプリを作るときのおすすめ構成

Swiftの有名画像キャッシュライブラリを比較してみた

3種類のライブラリ

今回3つのライブラリに着目した.

Nuke
Kingfisher
AlamofireImage

結論として, Nukeが一番流行ってて処理速度も早かった. 処理速度に関しては以下のチュートリアルを使って, 3つのライブラリ全て使ってみた.

Nuke Tutorial for iOS: Getting Started

他のライブラリに関しては, KingfisherがObject-Cの時代のSDWebImageの流れを組んでいてドキュメントが多いのと, AlamofireImageは画像描画のアニメーションが豊富な点がいいのかなと思いました。

感想

普段ライブラリなんかはググって適当に使ってしまうが, こうして比較検討することはあとの変更コストをなくすために大事な作業だと思った.

Ruby on Railsでの多対多の関連付け

Fri, 12 Apr 2019 17:31:43 +0900

背景

自分は現在院生2回生で, 4回生のころから京都のゲーム・Web会社で働いている. 今も細々と続けている中で, Ruby on Railsに触れる機会があったのでその知見を貯めておく.

今回は多対多の関連付けと, その使い方を紹介する.

データ構造

このアプリケーションには, userとgroupの定義があって, userは複数のgroupに所属することができて, groupは複数のuserを持つ. よって中間テーブルを用いて多対多の関連付けを定義する.

schema.rb


ActiveRecord::Schema.define(version: 20_190_219_052_352) do
  create_table "group_users", options: "ENGINE=InnoDB DEFAULT CHARSET=utf8", force: :cascade do |t|
    t.bigint "user_id", null: false
    t.bigint "group_id", null: false
    t.index ["group_id"], name: "index_group_users_on_group_id"
    t.index %w[user_id group_id], name: "index_group_users_on_user_id_and_group_id"
    t.index ["user_id"], name: "index_group_users_on_user_id"
  end
  create_table "groups", options: "ENGINE=InnoDB DEFAULT CHARSET=utf8", force: :cascade do |t|
    t.string "name", null: false
    t.integer "status", default: 1, null: false
  end
  create_table "users", options: "ENGINE=InnoDB DEFAULT CHARSET=utf8", force: :cascade do |t|
    t.string "name", null: false
  end
end

テーブル名をgroup_usersにして中間テーブルを作る. このテーブルをもとにgroupからuser, userからgroupを参照する. ここでindexが3つ貼られているが, 以下のようにして簡単に貼ることができる.

create_group_users.rb


class CreateGroupUsers < ActiveRecord::Migration[5.2]
  def change
    create_table :group_users do |t|
      t.references :user, null: false, foreign_key: true
      t.references :group, null: false, foreign_key: true
      t.timestamps
    end
    add_index :group_users, %i[user_id group_id]
  end
end

Ruby on Railsでオシャレな処理を書く

Fri, 12 Apr 2019 10:00:45 +0900

背景

また, Ruby on Railsは型が決まった書き方があるので, 少ない行数に多くの情報を詰め込むことができて, 書き終わった後の見通しがとてもいいと思う. そんなオシャレな書き方を少し紹介したい.

使用するデータのスキーマとモデル

今回紹介するのは, SNSアプリのAPIの中身の一部である.

以下に, 端末の情報を持つdeviceテーブルと, ユーザーの情報をもつuserテーブルを定義する.

schema.rb


ActiveRecord::Schema.define(version: 20_190_219_052_352) do
  create_table "devices", options: "ENGINE=InnoDB DEFAULT CHARSET=utf8", force: :cascade do |t|
    t.bigint "user_id"
    t.string "uuid"
    t.integer "user_agent"
  end
  create_table "users", options: "ENGINE=InnoDB DEFAULT CHARSET=utf8", force: :cascade do |t|
    t.string "email", null: false
    t.string "password_digest", null: false
  end
end
```ruby

`user`と`device`の関係は1対多であり, `belongs_to`と`has_many`で関連付けされている. 以下にそれぞれもモデルを示す.

user.rb

```ruby

class User < ApplicationRecord
  has_many :devices, dependent: :nullify
end

Device.rb


class Device < ApplicationRecord
  belongs_to :user, optional: true
  # deviceとuser_idを紐づける
  def update_user_id(user)
    user.devices << self
  end
  def shape_response
    { uuid: uuid }
  end
end

オシャレな文法たち

上記データ構造をもとにおしゃれな文法たちを紹介する.