rss latest ja

2024 年版開発時のエディタ周りの環境設定(Neovim, tmuxなど)まとめ

Mon, 21 Oct 2024 00:00:00 GMT

最近コーディングの配信を行ったりしているのですが、結構 Vim に関してコメントを頂くことが多く、ちょっと今自分の状況を振り返ってみると

設定したのが昔すぎてうまく説明できない
Neovim を使っているが、Vim Script でそのまま設定してたので、lua で設定したい
そろそろ古くなっているプラグインや知らないけど便利なプラグインがあるかもしれない

などなどがあったのでこの度 Neovim の設定を lua に移行しつつ使用プラグインの見直しを行いました。プラスで自分の環境周りも整理したかったので備忘がてら記事にまとめてみました。

エディタ周りの環境

Mac
モニタ2台(Display Menu)
tmux
Alacritty
Neovim

エディタ周りの環境は上記のようになっています。

PC周り

開発には長年 Mac を使用していて、モニタ2台で開発していることが多いです。モニタの解像度変更ようにはDisplay Menu というアプリを使っています。 (大きい方のモニタでコードを書いて、小さい方のモニタでブラウザを開いていることが多いです)

ターミナルアプリケーション

またターミナルアプリケーションは Alacritty を使用しています。ターミナルは可能な限りサクサク動いて欲しいので早いという評判の Alacritty を使っています。今の所そんなに不満はないのですが、kitty が良いというのもちょこちょこ聞くのでいずれ試してみたいところです。ターミナルアプリは真剣に比較していないので暫定的なものです。

Tmux 周りの設定や使い方

tmux はターミナルの分割を行うために使用しています。 tmux を使いこなしているとは言い難いのですが、自分が一番重宝している機能はこれかなという感じです。

tmux を知ったのは結構遅かったと思うのですが、Inkdrop 作者の Takuya さんの動画がきっかけでtmuxを使い始めて動画の説明と同じようにtmuxを使っています。コマンドベースで最初に開く window の枚数や配置・サイズを指定できるので一瞬で自分の好みのレイアウトを立ち上げられるのが便利です。

作業時のウィンドウのレイアウト

自分は多くの場合、この画像のような上1枚、下4枚のレイアウトで作業しています。下4枚はターミナル用の window で、上が Neovim 用 Window です。下4枚では左2枚が大体フロントとバック用のサーバをたちあげてログを流す画面になっています。右2枚はスペアで簡単なコマンドを試したり別ディレクトリのものを触りたくなったりした時に使います。

多くの場合はエディタ開きっぱなしなのですが、たまにPCを立ち上げ直したあとなどは用意したスクリプトを叩いて必ずこのウィンドウの状況を再現するようにしています。 (tmux のセッションを永続化することも可能なのようなのでそれでやるのも良いと思います。)

#!/bin/bash
set -e

tmux split-window -v -l 30%
tmux split-window -h -l 50%
tmux split-window -h -l 50%
tmux select-pane -L
tmux select-pane -L
tmux split-window -h -l 50%
tmux select-pane -U

tmux のセッションを開いた後にこれを打てばウィンドウ再現できるかと思います。

キーバインド

後にも説明しますが、ペーンの移動は Vim の中での移動とtmux 内での移動の両方があるのでそれぞれキーバインドが衝突しないように設定を行っています。 tmux.conf の中の設定でいうと下記のように設定しています。

bind -n C-h select-pane -L
bind -n C-j select-pane -D
bind -n C-k select-pane -U
bind -n C-l select-pane -R

キーバインド	操作
Ctrl + h	左のPaneに移動
Ctrl + j	下のPaneに移動
Ctrl + k	上のPaneに移動
Ctrl + l	右のPaneに移動

Vim 内での移動は Space + hjkl で行うので、ターミナル内での移動は Ctrl + hjkl で行うようにしています。

Neovim の基本設定

さて、続いては Neovim の設定についてです。こちらはリポジトリで公開しているので、興味がある方はご確認ください。

version-1/nvimconf

ディレクトリ構成

ディレクトリ構成は下記のようになっています。

├── README.md              
├── init.lua               # 最初に読み込まれる設定ファイル
├── install.sh             # LSP など依存しているライブラリのインストールをまとめたスクリプト
├── lazy-lock.json         # lazy のロックファイル
└── lua                    # 設定ファイルを分割して書いているディレクトリ
    ├── base.lua           # 基本の設定
    ├── config
    │   └── lazy.lua       # lazy の設定
    ├── keymaps.lua        # プラグインに依存しないキーバインドの設定
    └── plugins            # lazy で読み込むプラグインの設定
        ├── cmp.lua        # cmp 補完プラグインの設定
        ├── formatter.lua  # formatter の設定
        ├── lsp.lua        # lspconfig の設定
        ├── lualine.lua    # lualine の設定
        ├── plugins.lua    # その他設定なしで読み込めるプラグインをまとめたもの
        ├── tree.lua       # nvim-tree の設定
        ├── treesitter.lua # treesitter の設定
        └── whichkey.lua   # whichkey の設定

Neovim では、init.lua に設定を書いておくと Neovim 起動時に設定を読み込んでくれるのでここに様々な設定やプラグインの読み込みを書いています。とはいえ、全部の設定を一つのファイルにかくと見通しがわかりにくくなるので、上記の表のように設定を分割しています。

基本設定(base.lua)

元々の Neovim 組み込みの設定は base.lua に記述しています。

-- https://neovim.io/doc/user/quickref.html#option-list
vim.o.encoding = 'utf-8'
vim.o.number = true
vim.o.smartindent = true
vim.o.clipboard = "unnamedplus"
vim.o.list = true
vim.o.expandtab = true
vim.o.tabstop = 2
vim.o.shiftwidth = 2
vim.o.wrap = false
vim.o.termguicolors = true
vim.o.wildmenu = true
vim.o.ruler = true
vim.o.smartcase = true
vim.o.showmatch = true

vim.g.mapleader = ' '  -- Leader に Space を割り当てる
vim.g.maplocalleader = "\\"

コメントにもありますが、Neovim の設定項目は https://neovim.io/doc/user/quickref.html#option-list ここを見ると書いてあります。

Leader について

一応言及しておくべきは Leader と言って Vim を操作する際にキーバインドの先頭につけるキーをSpaceに割り当てています。これはVim の操作をする上で最重要なキーバインドになるので、自分の使いやすいリーダーに割り当てられると良いと思います。自分は、Vimを使い始めた当初にMedium でSpaceが使いやすいと言っている記事(記事の所在は忘れました・・・)を見つけたのでそれ以来 Space を使っています。

今回記事を書くのとVim周りの設定をluaに移行するにあたり色々な人の vimconfig をみているのですが割と Space に Leaeder を設定している方が多そうです。参考にした Nvchad も Space に Leader を設定しているので、割と一般的な設定にも思えます。

基本のキーバインド(keymaps.lua)

プラグインによらないキーバインドは keymaps.lua に記述しています。 Vim上でのウィンドウの移動や分割、ターミナルの開閉などのキーバインドをここに書いています。ここでと書いているものが先ほどの base.lua で設定した Space になります。

luaへの移行前は、コメントの ON/OFF をプラグインでやっていましたが、Neovimではデフォルトで gcc と入力すれば使えるのが分かったのでキーバインドを変えて使っています。自分は Ctrl + -(ハイフン) でコメントアウトができるようにしています。

自分はコードを書いている際に頻繁に window 分割したり移動を行うので、Space + jklh でウィンドウの移動、Space+s or Space + v でウィンドウ分割をしています。

local map = vim.api.nvim_set_keymap
-- move window
map('n', '<Leader>j', '<C-w>j', { noremap = true, silent = true })
map('n', '<Leader>k', '<C-w>k', { noremap = true, silent = true })
map('n', '<Leader>l', '<C-w>l', { noremap = true, silent = true })
map('n', '<Leader>h', '<C-w>h', { noremap = true, silent = true })

-- split window
map('n', '<Leader>s', ':<C-u>sp\n', { noremap = true })
map('n', '<Leader>v', ':<C-u>vs\n', { noremap = true })

-- close window
map('n', '<Leader>w', ':<C-u>w\n', { noremap = true })
map('n', '<Leader>q', ':<C-u>q\n', { noremap = true })
map('n', '<Leader>wq', ':<C-u>wq\n', { noremap = true })

-- open terminal
map('n', '<Leader>tt', ':terminal\n', { noremap = true })

map('i', '<C-k>', '<Up>', {})
map('i', '<C-j>', '<Down>', {})
map('i', '<C-h>', '<Left>', {})
map('i', '<C-l>', '<Right>', {})

-- show diagnostics
map('n', '<Leader>d', ':lua vim.diagnostic.open_float()<CR>', { noremap = true })

-- rebind embeded command
map('n', '<C-_>', 'gcc', { noremap = false })
map('v', '<C-_>', 'gc', { noremap = false })

NeoVim のプラグイン周り(plugins/*.lua)

プラグインの設定は plugins ディレクトリ以下に分割して書いていて、個別に設定が必要ないものは plugins/plugins.lua に書きそうでないものは専用のファイルを作って管理しています。

パッケージマネージャ

lazy repo

プラグインの読み込みは lazy を使っています。lazy を設定すると plugins 配下のファイルを読み込んで plugin をセットアップしてくれます。

補完・シンタックスチェック

nvim-lspconfig repo

設定 plugins/lsp.lua

補完やジャンプ、定義の確認、シンタックスチェックにLSP必要なので言語別にサーバを設定できるプラグインです。

nvim-cmp repo

設定 plugins/cmp.lua

補完プラグインです。LSP と連携して補完を行うことができます。

nvim-treesitter repo

設定 plugins/treesitter.lua

シンタックスハイライトやシンタックスチェックを行うために入れています。構文解析のためのツールである treesitter と nvim-treesitter を良い感じに繋げるプラグインという理解です。 (ちょっと使い始めて日が浅いので雑な説明になっていますすみません）

普段使う言語の Parser だけ使うように設定しています。

copilot.vim repo

設定 plugins/plugins.lua

言わずもがな Github Copilot のVim用プラグインです。これでだいぶ補完が効く様になるのですが、そこまで使い方深堀できていないのでまた時間のある時に使い方を調べてみたいです。

ファイルエクスプローラ

nvim-tree repo

設定 plugins/nvim-tree.lua

ファイルエクスプローラ用のプラグインです。ほぼ一般的なエディタについてるファイルエクスプローラと同様に使えます。元々はNerdTree を使っていたのですが、lua 移行にともなって移行しました。 nvim-web-deviconsもインストールすれば他のIDEと同等の見た目になり、ファイルの情報もみやすくなるのでおすすめです。

エクスプローラの開閉は Space + e で行うようにしています。こういったプラグインのコマンドを実装するためのキーバインド設定は keymaps.lua でやらずここでやっています。

keys = {
  { "<leader>e", "<cmd>NvimTreeToggle<cr>", desc = "TreeToggle" },
},

デフォルトのキーバインドでは、Enter でファイルを開くときにいちいちどの Pane で開くか聞かれるのが嫌だったのでマッピングを変えています。

  vim.keymap.set("n", "<CR>", api.node.open.no_window_picker, opts "Open: No Window Picker")
  vim.keymap.set("n", "O", api.node.open.edit, opts "Open")

検索

ファジーファインダー telescope

設定 plugins/plugins.lua

高機能なファジーファインダープラグインです。ファイル検索や文字列でインクリメンタルサーチができます。正直エディタにこれがないと辛いですよね。CUIベースのエディタとは思えないくらいリッチなUIを持っているので非常に便利です。

キーバインドは下記の様な形で頻繁に使うのですぐに使える様にしています。

キーバインド	操作
Space + p	ファイル検索
Space + g	文字列検索

フォーマッタ

フォーマッタ conform.nvim

設定 plugins/formatter.lua

フォーマッタプラグインです。他のプラグインなどと同様にファイル保存時に自動でフォーマットをかけることができます。フォーマッタは言語ごとに設定可能で自分は、gofmt, goimports, prettierd 等々を設定しています。こちらもフォーマットをかける際のキーバインドはconform用の設定ファイルで書いています。

コードを書きながら手動でフォーマットをかけるのを好むので手動のフォーマトコマンドを設定しています。 conform では若干設定が必要なので下記の Recipe に従ってコマンドを作ってそれを呼び出す形で使っています。

Format command

見た目系

ステータスバー lualine

設定 plugins/lualine.lua

ステータスラインをカスタマイズするプラグインです。ステータスライン変えるだけでもかなりこなれた感じになるので試してみてみると良いと思います。前は設定が悪かったのかステータスライン系のプラグインを入れると重くなってしまっていたので、自前で設定していましたが lualine は問題なさそうです。

カラープレビュー nvim-colorizer

設定 plugins/plugins.lua

カラーコードをプレビューしてくれるプラグインです。CSSを書く際にかなり便利です。カラーコードの上に乗っかる形でプレビューされるのですが、自分的にはカラーコードの横に色を表示させたい（文字色などによって見辛くなるので)というのは多少あります。

プラグインの自作にもトライしたいので、時間がある時に作ってみたいなーなんて思っています。

その他

キーバインドヘルプ which-key

設定 plugins/whichkey.lua

キーバインドのヘルプを表示してくれるプラグインです。自分で設定したキーバインドがわからなくなった時に便利なのでおすすめです。また自分で設定したキーバインドが効いているかも確認できて非常に便利です。移行の際に知ったプラグインですが嬉しい発見の一つでした。

囲み文字編集 nvim-surround

設定 plugins/plugins.lua

こちらは移行の際の調べ物で見つけたプラグインです。動画で紹介しているものを見つけて便利そうなので入れてみました。まだ使えこなせてはいないのですが、Vim で囲み文字を追加する際に便利そうなので使ってみようと思います。

nvim-surround | 5 Neovim Plugins To Improve Your Productivity

ds" の様に入力するだけでワード周りのダブルクォーテーションを削除できたり、丸括弧、波括弧、角括弧なども少ないキーストロークで入力が行えるので非常に便利そうです。

まとめ

今回 lua に移行したのですが、その過程で Neovim をはじめとしたドキュメントを読み漁りました。自分が知らないプラグインやNeovimの機能が結構あることに気づいたので、やはり定期的に設定を見直すのは必要な様です。

neovim 内で :terminal とするとターミナルが開くのですが、これを使うとターミナルとエディタ間の移動がいらなくなるので、もしかしたら tmux も使わなくて済むのかもしれないです。今のところは慣れているtmux+neovimで運用していますが、意外とneovim だけでやっていけるのかもしれません。 (tmuxには他の機能もあるのと、vim内のターミナルの操作がどの程度使いやすいかがあるのですぐに移行はできなそう）

いずれにせよ、ここに書いたのは現時点での環境ですぐに変わることはないと思いますが徐々に変わっていくことになるかと思うので今回の様な変更があればまた記事を書きたいと思います。また、もう少し普段 vim を使わない方向けにも記事を書いてみたいと思うので、今回の作業を違った角度から記事にもできればなと思っています。

Ruby のmethods メソッドをJavaScript で実装する

Mon, 29 Jul 2024 00:00:00 GMT

突然ですが、ruby のmethos メソッドって便利ですよね。コードを書いているときにそのオブジェクトで呼ぶことができるすべてのメソッドやプロパティを羅列してくれて検索までできるので、デバッグの時に重宝しています。

それとはまた別に、Rails などフレームワーク独自のメソッドを調べるときにも有効なのでコードリーディングやライブラリの理解の手助けにもなります。正規のルートではドキュメントを読んだり、ソースコードを参照するのがよいですが、そこまで深入りする必要のないライブラリや記憶があやふやなメソッド名を調べる時にはかなり役立ってくれます。

Ruby のmethods メソッドとは

ということで簡単にRuby のmethods メソッドを簡単に紹介すると下記のようになります。

Object#method

Returns a list of the names of public and protected methods of obj. This will include all the methods accessible in obj’s ancestors. If the optional parameter is false, it returns an array of obj’s public and protected singleton methods, the array will not include methods in modules included in obj.

要はレシーバーからアクセス可能なプロパティやメソッドをArrayオブジェクトで返却してくれるものです。

このメソッドはオブジェクトの始祖であるObject クラスで実装されているので Object クラスを継承したすべてのクラスで使用することができます。

サンプルコード

class Hoge
  attr_accessor :fuga

  def bar
    puts ''
  end
end

puts Hoge.new.methods     // => [:bar, :fuga=, :fuga, :hash, :singleton_class, :dup, ...]
puts Hoge.new.grep /fuga/ // => [:fuga=, :fuga]

例のように Array オブジェクトが返ってくるので grep メソッドでメソッドの一覧を検索することも可能で非常に便利です。

ということで、これと同じことが JS でできないか考えてやってみました。

実装

下記が実際のコードです。

クラス名はなんでも良いのですが、一旦 PropertyFinder と命名しています。

class PropertyFinder {
    constructor(receiver) {
      this.receiver = receiver
    }

    grep(regexp, options = {}) {
      let res = []
      if (typeof regexp === 'string') {
        return this.find((name) => name.includes(regexp))
      }
      if (regexp instanceof RegExp) {
        return this.find((name) => regexp.test(name))
      }
      return []
    }

    toString() {
      return this.find(() => true)
    }

    find(detect) {
      const list = Object.getOwnPropertyNames(this.receiver).filter(it => detect(it))
      if (!this.receiver.__proto__) {
        return list
      }
      const ancestors = new PropertyFinder(this.receiver.__proto__).find(detect)
      return [...list, ...ancestors]
    }
}

コードの解説はあとにして一旦使い方から

クラスが定義できたら下記のようにして、Object クラスのプロパティに関数を差し込みます。

Object.prototype.methods = function () {
    return new PropertyFinder(this)
}

これをすることで Object クラスを継承するクラスのインスタンスで methods メソッドを使用できるようになります。ただ、こちらに関しては後に注意を書くのでそちらにご留意の上、自己責任でお使いください。

下記がその実行例です。


class Hoge {
  fuga() {
    console.log('fuga')
  }
}

console.log(new Object().methods().toString()) // => ['constructor', 'constructor', '__defineGetter__', '__defineSetter__', 'hasOwnProperty' ...]
console.log([].methods().toString())           // => ['length', 'length', 'constructor', 'at', 'concat', ...]
console.log(new Hoge().methods().grep(/fuga/)  // => ['fuga']

使用上の注意

こちらのコードはプロダクションのコードで採用するには、おすすめされないコードになっています。

上位のクラスにプロパティを追加するモンキーパッチというアンチパターンで、将来的な JS 側の仕様変更の際にトラブルになる可能性があります。用法・用量を守ってご使用ください。

参考: The cons of monkey patching

コードの解説

コードの解説に移っていきます。

PropertyFinder のメソッドとして一番重要なメソッドは find メソッドになります。このメソッドが与えられたオブジェクトのプロトタイプチェーンを遡り実行可能なプロパティを検索し、リストとして返却してくれます。

あとのtoString, grep はそれを使うだけのメソッドなので特に解説は行いません。

プロトタイプチェーン

プロトタイプチェーンは聞きなれない方もいるかもしれませんが、 Object クラスから脈々と受け継がれてきたプロパティの遺伝子です。

継承とプロトタイプチェーン| MDN

詳しい話は、MDNのドキュメントに譲りますが、実は、JavaScript の継承という仕組みがプロトタイプチェーンによって支えられています。

普段意識はしないですが、なにかしらのプロパティを参照する際には

レシーバー自身にそのプロパティがあるか？
親クラスのインスタンスにそのプロパティがあるか？
1. の親クラスのインスタンスにぷろぱてぃがあるか？

というように先祖を遡りながらプロパティを検索し、ヒットすればそれを返却するというしくみになっています。

find メソッドでやっていること

上記をふまえて、その仕組み自体を PropertyFinder に実装すると参照できるプロパティのリストが得られます。

こちらがその実装で親のプロパティを参照するには、__proto__ プロパティを参照すればよいので下記のように、__proto__ を再帰的に探索してリストを得ています。

    find(detect) {
      const list = Object.getOwnPropertyNames(this.receiver).filter(it => detect(it))
      if (!this.receiver.__proto__) {
        return list
      }
      const ancestors = new PropertyFinder(this.receiver.__proto__).find(detect)
      return [...list, ...ancestors]
    }

これで、PropertyFinder の解説は以上です。

まとめ

これでコード等々や試してみたことの説明は終わりになります。

今回は実験的というかお遊びみたいなものなのですが、多少知識が必要なものなどもあったので参考にしたり応用してみていただけるとうれしいです。

2022年。ふりかえり

Sat, 31 Dec 2022 00:00:00 GMT

日本では一足お先に年越してしまっているみたいですね。去年は振り返り書いてなかったみたいですね。今年は簡単に振り返ります。

本業

Influitiveでやっていることの振り返りです。（フルタイムの仕事を本業と読んでます。）

あと数ヶ月で勤続2年
チームの中ではすでに中堅くらいの長さ
技術スタック的には変わらず JavaScript, Ruby, Go のバックエンド寄り。
入社して数ヶ月からはじまった Go + GraphQL のバックエンドのプロジェクトがようやくプロダクトで使われ始めている。
新規モジュールみたいなのが多くなかったので、割とフロントエンドの結合周りの修正多め
週休2.5日制の開始

3月から働き始めたので、来年3月で2年というです。

仕事自体は昨年のプロジェクトの引き続き続けていたのですが、新規のものは割と落ち着いてきたのでエンドポイントのインタフェースを作る、Rubyで書かれたモジュールをGoでゴリっと書き直すみたいなのは多分なかったです。ただ、まあプロジェクト終盤になるにつれて詳細を詰める必要があったので最初にざっくり作っていた頃に比べて違った難しさありました。あとは本丸がRailsなのでそちらの修正に狩り出されていた期間もあったりしていたので、2,3週間Ruby書いてGo戻ってみたいなのを割と繰り返してました。一昨年は、プルリクに複数日とか1週間かかるのもあった気もするのですが今年は小さい単位でポンポン出してた感じでした。

昨年は、職位が上がったりしたのですが今年はそういったことも特になく据え置きという感じです。ただ、ワークもサポートしてもらえて LMIA も無事通過したので本当に職場には感謝しかないです。パフォーマンスレビューでも継続的にアウトプットできてるのでindiviualコントリビューターとしては評価されている気はするのですが、それ以外のところがまだまだなのでそれ以外が改善されればまた昇進できそうです。どうしても昨年よりはましになったとはいえ、英語のコミュニケーションがネックになっているのでなんとかしたいないうところではあります。メンバーの入れ替わりは思ってたより早く結構馴染みのメンバーが抜けてしまったりしていてるので、2年も経たずに勤続年数で言う中堅くらいになっていてるのでまぁそろそろ存在感出していきたいところです。

会社としては、ほとんどのメンバーがリモートで週休2.5日制みたいなものを導入していて月に二回月曜日が会社の休みになります。背景としては、ビックテックみたいに高給はやはりどうしても払えないのでそういったところでリクルーティングに差別化しようとのことみたいです。これは多分カナダの中でも割と珍しく就活していたときに似たような制度にしている会社は一社あったくらいです。個人的にある程度ユーザがついて安定してきている会社では週5日一つの会社で働くよりは週4日にして他の会社のプロジェクトなり個人の活動したりした方が個人としても会社としてもメリットなのでこちらには大いに賛成ですし、単純に休みが多いので嬉しい制度です。日本での働き方に関してもかなり議論されていますが、北米圏での働き方のスタンダードも結構変遷があるみたいなのでリモートワーク以外にもこういう週5日労働みたいな所も色々な考え方ができるようになると良いのかなと思います。

まとめとしてそろそろもう2年も経つので個人のアウトプットとしては内外である程度の信頼はしてもらえるようになったかと思うので、よりチーム・全体レベルの貢献を増やしていけると良いなと考えています。そのためには既存システムの理解度、メンバーとの連携、英語諸々やっていくこと多いので引き続き頑張っていきたいです。

副業

今年は、引き続き頼まれているアプリの開発・保守とMENTA、Techpitの執筆の方やってました。

アプリ開発では、Objective C + Java のアプリを React Native でリプレイスしたアプリが安定してきた
AWS周りのサービスを整理したら、月の利用額が半分ほどになった
MENTAの方では、受講者は割と落ち着き気味
昨年同様、数名程度エンジニアとして就職された方(カナダ企業も含め）をサポートできた
過去にMENTA経由で就職された方から生徒さんを紹介頂けた
一昨年リリースしたTechpitの教材も年間通してご利用頂けたよう

副業はこれまで同様色々なことができました。開発、執筆、メンタリングと色々な種類の仕事ができて満足です。

アプリの開発の方では、React Native + Rails(ちょっとGo) みたいなスタックでできているのでこちらでは本業とはまた違う学びを得ることができました。昨年アプリを Objective C と Java でできた古いネィティブアプリを React Native に置き換えましたそちらのリプレイスがだいぶ落ち着き安定してきて、今年はインフラ部分の方でも作業を行えて、結果的にAWSの月額料金を半分にできました。長くメンテできていないシステムだったので、インスタンスタイプを最新にしたり、 S3の不要なファイルを消したり、オートスケールを正しく設定して必要な時にだけ必要なインスタンスが立ち上がるように設定しました。インフラ専門の方からすると割と通常のことかもしれないのですが、インフラ専任の方がいないシステムでは割とできていないことのような気もするのでまずはそこを正常化した形です。個人的には、AWSのインスタンスタイプを新しくするだけで割と料金が減るのを知りました。割と周知のことかもしれないのですが、個人的にこの作業で学んだことでした。

MENTAでも引き続き学習者さんをサポートさせて頂きました。昨年に比べると受講者数も落ち着きましたが、今年はカナダにいる方などから相談をもらえることが多かったような気もしており個人的に嬉しかったです。実際に未経験でカナダの企業に就職された方もいたりしてそれは本当に嬉しかったです。また、以前受講していた方から生徒さんをおすすめして頂けたこともありました。おすすめして頂けたこと自体嬉しかったのですが、以前教えていた生徒さんが現場でバリバリ活躍してステップアップしている近況が聞けたのも同時に嬉しかったです。こういったことがあるので長く続けると言うのも大事なのかなと最近では思えてきましたし、2023年も引き続き続けていきたいと思っています。

MENTA上で関わった生徒さんもすでに200人弱にのぼり（単発の生徒さんも含む）色々な学習者さんをみている中で

公式のドキュメントが読める
エラーメッセージが読めて正しい手順でデバッグができる

と言うのがやっぱり一番大事だなと言うのを日々感じています。「HTML/CSSがー、JSがー、Reactがー」などに囚われがちですが、公式のドキュメントを読める知識・経験量とそれを正しく実行できているか確認できる「エラー解析・デバッキング」の力が自走できる一人前のエンジニアになるには本当に必要だと実感しています。メンタリングでもこれをどうすれば効率よく教える（メンティーさんができるようになる）にはどうすれば良いか考えながら教材を作ったりメンタリングをしています。来年はこれを念頭においたコンテンツなども作っていきたいですね。

また、昨年 Techpit さんで出させていただいたHooks API のオンライン教材ですが、一昨年リリースですがまだボチボチ利用されているようでした。今年は新しい教材を執筆していたのですが、諸々の事情であまり時間が取れず年末の休暇などを利用してコツコツ執筆を進めています。来年上半期のどこかで出せれば良いなと思っているのでまた時期がきたら記事書ければと思います。

相変わらず色々な副業していきますが、 2023年も引き続き頑張っていきたいと思います。副業では本業でできないことが色々できるので楽しみながら色々なことにチャレンジできればと思っています。

プライベート

今年は一年通してよく遊んだと言うかお金使った一年だった気がします。

コロナに関する国家間の移動がかなり緩和したので、その反動で色々と旅行にいきました。といっても、アメリカ二回の日本二回の二国だけですが、、

シアトルには、大谷の観戦に一回、PLL (アメリカのラクロスのプロリーグ）の試合の観戦にいきました。大谷は 3 回くらいスタジアムで見ているのですが、相変わらず見にいきたくなる選手なので見に行けて良かったです。特に、今回は友達含めてそれなりの人数でワイワイ見れたのが良かったです。また、ずっと見たかったアメリカのプロラクロスリーグの試合を見に行けたのも良かったです。学生の頃から見ていた選手を生でみれた感動もデカかったですし、PLLのインフルエンサー的な RJ を間近で見れたのも嬉しかったです。普段 Youtube で見てる人なんで生 RJ は割と感動しました。来年は自重しようかなという思っているのですが、またシーズンがくるとどこか行こうかなーとなるかもしれないですね。

その他で言うと、まぁもっぱら家で過ごすことが多いのですが最近家でゲームする時間が明らかに増えました。カナダ来る前のフリーランス期、カナダ就活期に働き過ぎたのかその反動で仕事終わりにゲームすることが多く、もっぱらApexなどをして過ごしています。

ゲーム自体は全然良いのですが、必然的にずーっと椅子に座り続けることになってしまうのでうまく運動する時間などもも設けたいところです。特に、日本で受けた健康診断の結果があまりよくなかったので（日々の飲酒が完全に数値に出てます。）これらも含めてちょっと2023年は生活習慣見直したいです。

総括

早いものでカナダ生活も3年たち、2023年にはかねての目標だったカナダ永住権も視野に入ってきます。今年一年は、あまり目標を定めずに流れるように過ごしたのですが、2023年はもう少しキッチリラインなど決めながらやっていきたいなと考えています。永住権にも仕事でのキャリアアップにも必要な英語力の強化や多少落ち着きつつある副業の新しい展開など何か変化のある一年にしていきたいなと思っています。2022年お世話になった方々ありがとうございました。2023年もよろしくお願いします。

プログラミング学習のスケジューリングについて

Tue, 21 Dec 2021 00:00:00 GMT

こんにちは、初めましてJiroです。

こちらはMENTAのアドベントカレンダーの記事です。

カナダでJS/Ruby/Goあたりのスタックを使いながらフルスタックエンジニアをしています。 MENTAは 2020年3月のちょうどコロナが流行り初めてきた頃にはじめて、これまで100人以上のメンティーさんに相談を頂いています。

みっちり学習プランというHTML/CSSからJSの基礎、Reactを学習してエンジニアとしてエントリーレベルの実力をつけるコースをメインに提供し、フロントエンドの技術を学びたい方の日々の業務でのつまずきポイントをチャットベースで解決したり、オリジナルアプリの開発の相談サポートなどを行っています。

よかったらこちらにプランが乗っていますので興味がある方はこちらご確認ください。

MENTA 提供プラン一覧

嬉しいことに、サポートさせて頂いた方でも業界未経験からエンジニアとして見事にキャリアをスタートさせている方々もいらっしゃるのですが、一方で学習が思い通りにうまく進まない、途中で挫折してしまうといった方もいるのでこの記事ではそこの違いといったところをある程度言語化できたらなということでプログラミング学習のスケジューリングについてをメインのトピックに書きはじめています。

なぜプログラミング学習で挫折するのか？

プログラミングを難しくしている要因

ここはまぁ割とよく話されているかと思うのですが、前提を合わせるためにも簡単に触れていきます。

ざっくりまとめるとプログラミング学習を難しくしている要因はこの辺りにあるのかなと思っています。

必要な知識量の膨大さ
非エンジニアリングにはない独特の概念・文化への適応の難しさ
膨大な知識量をカバーするための計画と実行の難しさ

いくつか要因は上げましたが、本当にゼロから始めた場合極論1週間とかそこらで修得できる物でもなく、エントリーレベルのエンジニアになるまでに必要な知識量の大さが1番の要因になっており、その知識量をなんとかするためのソフトウエアエンジニアの文化への慣れとか長期に及ぶ勉強期間をどう管理していくかみたいな問題が付随してやってくるという形です。

エンジニアになるために必要な知識

知識が膨大だみたいな話をしていても具体性がないので、じゃあ例えばどの辺りのことを理解しておく必要があるの？となるとおもうのですが、僕がMENTAで教えているフロントエンドのコースでは、

ITの基礎・・・webの仕組み、ハードウェアの仕組み、ネットワークなど
HTML/CSS・・・数ページの静的なwebページが作れるくらい
JavaScript・・基礎的な文法などなど、フォームバリデーションなどなど
サーバーサイド・・node.js,ruby, pythonなど何でも良いのでCRUDができるweb APIがつくれる。
Linux・・コマンドライン操作、linuxのファイルシステム、ディレクトリ構造などについて
バージョン管理・・git の使い方、ブランチ運用

あたりの知識をベースに、+α Reactなどのフロントエンドフレームワークを使えるようになると良いというようなことを案内させてもらっています。

みてわかるようにそれぞれ1項目を倒すだけでも結構時間が必要になるのとそれぞれの知識は繋がっているようで、各項目ごと違った癖があったりで日々勉強をしているメンティーさんを見ると本当に頑張ってるなと感じます。

解決策: スケージューリングにこだわる

ここまでエンジニアになるためには膨大な量3ヶ月〜半年くらいは少なくともしっかり計画たててコツコツ勉強しないといけなく、一筋縄にはいかないことがわかったと思います。で、ここからが本題なのですが、日々メンティーさんの勉強の様子だったり、相談を受けた時に「計画段階で結構失敗しているなぁ」という印象を受けることがあります。

僕自身最初のメンタリングでは、学習の計画について聞くことがあるんですが、計画を聞くとだいたい6ヶ月後を目処に転職したいみたいな時期感は出てくるのですが、その目標を達成するために「自分がどうなっていれば良いのか？どういう知識を得ていればよいのか？」みたいな所の解像度粗いというのがよくあります。

転職までの期間が6ヶ月だとするとインプット重視の基礎を整えられる時間は、ポートフォリオの作成期間や面接を受ける期間でだいたい最初の3か月くらいかと思うのですが、その中で上のような知識を網羅しようとなるとかなり忙しいですし本当に土日返上+平日は勉強しないと間に合わなかったりするはずです。なんですが、ここがあまり明確に意識できておらず1日に十分な勉強時間が確保できておらずどんどんスケジュールが後ろに倒れていってしまい、いつしか熱も冷めてしまい・・となりがちです。

と言った形でここまでが問題提起です。少なくない数の学習者さんがここのスケジューリングを改善すれうばもっとよくなる気がしたので今一度計画を見直すキッカケになればと思います。

勉強の計画の立て方

スケジューリングの大切さを語ったところで、ざっくり下記がそのステップになります。

転職する時期を決める
面接で聞かれる内容、アピールする内容をイメージする
ポートフォリオで作るものを決める(求人を参考にする)
テーマ毎の粒度で中期の勉強計画をたてる
1日に必要な勉強時間・勉強内容をきめる
1日単位・週単位で振り返りを行い計画を修正する。(時期が迫ったら機能をドロップする短期で補える方法を模索する)

面接でアピールする内容を先に決めておく、1日に必要な勉強時間・勉強内容をきめる あたりがポイントかと思っていますが、目標を明確にししてそれを1日の具体的なアクションに落とし込む、適宜進捗を見ながら軌道修正を行うあたりが大切になってきます。

1. 転職する時期を決める

言葉通りですが、全くのゼロから始めるのであれば少なくとも6ヶ月くらいのタイムスパンは必要かと思います。3ヶ月とかなると元々やってなかったりするとかなりキツイとは思うので、半年程度が妥当なラインかと思います。

2. 面接でアピールする内容を決める

転職を考えている方は、面接で話す内容を学習開始段階から考えておけると良いでしょう。

転職活動を始める時の前の期間はプログラミング自体の勉強やポートフォリオ作成などを行う準備期間になると思いますが、ここで何をやっておく必要があるのか？ということを明確にするためにも面接でアピールする内容を決めておけると良いでしょう。

面接で語る内容を具現化したものがポートフォリオで、そのポートフォリを作るための知識を日々の学習で身につける。

という考え方が根幹になります。

アピールと言っても100人に1人しか出来ないみたいな事をアピールする必要はなく、各社選考の基準は違うかと思いますがだいたい「webアプリのバックエンドからフロントエンドをざっくり作った経験があり仕組みを理解しているまたは入社後にキャッチアップできる」という部分を納得させられる程度のアピールができれば良いのであまり難しく考える必要はないです。あとは自分の中で目指したいエンジニア像みたいな物があればそれがアピール出来るようにその要素を自分のポートフォリオに盛り込めると良いでしょう。

このアピールする内容を決めるというのは限られた期間で「何をする必要があり、何をやらないのか」を決める所がゴールです。裏を返すと、面接で語る必要のないことはあまりやる必要がないです。（将来的に現場で必要な可能性もありますが、短期的に効率よく成長するためにはいち早く現場の経験を詰めることが第一と考えているので、面接時点で不要な知識は一旦据え置きます）

3. ポートフォリオで作るものを決める

ポートフォリオを作る時に考えるべきことは

面接あるいは書類選考でアピールするための機能が揃っているか？
必要な技術スタックを網羅しているか？
選考に足る複雑度のあるアプリであるか？

あたりです。

1. については自分がデザインとフロントエンドに興味があるならUIの実装にこだわってみる。フロントに加えてサーバも出来るようになってフルスタックに働きたいなどあれば、サーバサイド側で定時実行のバッチ処理を実装して組み込むなどのようにエンジニアとしての色が分かるように成果物を考える。

2. については自分が志望している業界・会社の技術スタックに合わない技術を使っているまたは不十分だったりするとそもそも面接にも進めなかったりするので自分が作ろうとしているポートフォリオにどのように技術スタックを取り込むかという形になるかと思います。必要なスタッフの確認は適宜wantedly,greenなどなど海外ならLinkedinなどなどIT系企業の求人が載っているサイトを見ると結構キーワードでリストアップされているのでいくつか求人をみて頻出な技術スタックを盛り込むようにすると良いです。

3. については、やはりtodoアプリでページ遷移なしのポートフォリオを持っていってもプログラミング経験はあるのはわかりますが、その人が現場のシステムを理解してプロジェクトにフィットできるかどうかのイメージは湧かないので、バック・フロントがあってawsやherokuなどにホストされていて、

よくあるwebサービスの

ログイン機能
ユーザーページ
サービスの根幹を実現する機能(CRUD+αを実装したもの)

あたりは実装されている必要があると思います。

またポートフォリオを考える時に

ポートフォリオのサービスを説明する文章
使用する技術スタック
簡単な機能がわかるワイヤーフレーム(Figmaなどのツールを使ってもよいし、手書きでも可)

あたりをざっくり書き出してみると頭で考えるよりはよりクリアにイメージできるでしょう。学習を始めるまでにここをやっておくと学ぶべき内容もクリアになるので良いかと思います。

4. テーマ毎の粒度で中期の勉強計画をたてる

上記で作成するポートフォリオを決めて、使用する技術スタックがわかったらあとはそれらを一つずつ学んでいければ良いでしょう。何をどれくらい勉強すれば良いかを調べるのはなかなか難しいですが、HTML/CSS、Reactみたいな粒度だったりすると何を学べば良いのかわからなかったりするので、 Reactだったら、

Reactの概要
ステートとProps
クラスコンポーネントと関数コンポーネント
hooks API(useState, useCallback, useEffect)
パフォーマンス最適化
useRefなどのそのほかのHooks

などなある程度トピックを書き出してそれぞれを勉強してみる形が良いでしょう。勉強する際にも何を学ぶのか？を明確にしておかないと何をして良いかわからなくてモチベーションが下がってしまうので、学ぶ内容をできるだけ細分化できると良いです。

ある程度細分化ができたらそれぞれの項目にかける時間を書き出してみてまとめて、それぞれに必要そうな勉強時間を割り出しましょう。

ここで実際の学習を進める時に気をつけるのは、ドキュメントを読むなどインプット自体はあまり時間をかけ過ぎなくてよくて「こういった項目がなんとなくあるんだな」という形であとで検索できたり戻ってきて読み直したりする程度で大丈夫です。最終的な業務を考えた時は「手を動かして作れる」ようになっていることが目標なのでしっかり普段からコードを書いて、アプリを作る過程に体を慣していけると良いでしょう。

6ヶ月くらいでフロントエンドで転職を考えているのであれば 3ヶ月のうちに

学習内容	期間
HTML/CSS	1週間
JSの勉強	1週間
Reactの勉強	1週間
Reactを使った簡単なアプリ作成	1週間
React, Reduxを使った簡単なアプリ作成	1週間
React+Redux+API通信を使った簡単なアプリ作成	1週間
Linuxの学習（コマンドラインやディレクトリ構造など）	1週間
MySQLなどのデータベースの学習	1週間
ブログのCRUDをできるようなWeb APIを MySQL+Express.js で作成	1週間
自前Web APIとReactを統合したアプリ実装	1週間

計 10週間

のような形で計画を立てられると良いでしょう。それぞれの項目の中には先程のステップで細分化した内容を順番に勉強していくような形です。また〜の学習、勉強のようなアプリ作成と書いていないような項目でもそれぞれなんらかのアウトプットを出すようにすると良いです。

HTML/CSSの学習であれば一つサイトの１ページを模写してみる、色の着いた四角い要素をよくあるサイトレイアウトに並べてみる、
Reactなら自分で設計をして◯×ゲームを実装してみる

のように自分の練習として、お題を考えて実装してみると学習効率が上がると思います。 Udemyのチュートリアルのようなものでも最初は良いのですが、自分で設計して実装した方が力は着くので、チュートリアル→自作アプリの順番で練習すると良いでしょう。

上の例では10週間で3ヶ月未満で書いていますが、おそらく学習しているうちに必要な要素が出てきたり想定外のこともあるのである程度バッファをとってスケジュールを引きます。

そのほか基本情報技術者試験に出てくるような情報処理的な知識も補完しながら進む必要があるので、適宜勉強の合間や移動時間などの隙間時間を見つけて学習できると良いでしょう。

5. 1日に必要な勉強時間・勉強内容をきめる

ここまでブレイクダウンできたらあとは1日に必要な勉強時間と1日のうちのどの時間帯に勉強するか、勉強内容を決めます。

勉強する中でも

テキストを読むだけですむもの
コードを書いて動かす必要があるもの

の二種類に分かれるので、読むだけで済み机に向かっていなくてもできるものは隙間時間に行うようにしたり勉強に疲れてゴロゴロするときになんとなく眺める。みたいな形で効率よく勉強できるように工夫しましょう。同じテキストの同じ文を繰り返し参照するようにすると記憶に残りやすいので、テキストやドキュメント記事は繰り返し読むのがおすすめです。

プログラミング学習は長い道のりですが、やはり一日の積み重ねが将来的な地力に繋がるのと時間が飽くと内容を忘れてしまい効率が悪いので机に向かわなくても勉強できる方法を確立して忙しい日でも勉強できると良いです。

また、6ヶ月などの遠い目標を達成するのに大まかな目標しかないと具体的なアクションが取れないので、

1日何時間程度勉強するのか？
何を勉強するのか？
どのように勉強をするのか？

というのを明確にして勉強できると達成感を感じながら学習を進められるので結果も違ってくると思います。

6. 1日単位・週単位で振り返りを行い計画を修正する

1日単位でのアクションプランが練れたら、簡単にで良いので定期的に計画の振り返りを行って計画を修正するようにしましょう。意外とReactのアプリ作成に時間が必要になったらその分他のスケジュールなどが後ろ倒しになるので、それの影響をみて「全体を終わらせる必要があるのに、一つのトピックに止まり過ぎていないか？」などなるべく長期的な視点にたって勉強のし過ぎや勉強のペースを考えて修正を行っていきましょう。

ここでの注意点は、細かい4.で決めたような中長期のスケージュールは動かしても良いのですが、6ヶ月で転職などのような 大きなスケジュールはなるべく変えない ことです。全体のスケジュールを伸ばしすぎると勉強が苦しくなってしまって挫折したりするので大きなスケジュールは変えずに「勉強する内容を少し削る」「ポートフォリオにつける機能を減らす」などして計画を調整できると良いです。

スケジュールを伸ばしに伸ばして打席に立てなくなると、自分に足りていない要素を見つけたり課題に気づいたりという機会が極端に減ってしまうので、計画後半の方で発生した遅延はやることを減らすことで対処しながらあとは対外的な面接などを通して自分の弱点を補いながら転職に繋げていくという方針が時間効率が良いです。

スケジューリングのまとめ

ここまででスケジューリングの方法は一通り説明できました。

転職する時期を決める
面接で聞かれる内容、アピールする内容をイメージする
ポートフォリオで作るものを決める(求人を参考にする)
テーマ毎の粒度で中期の勉強計画をたてる
1日に必要な勉強時間・勉強内容をきめる
1日単位・週単位で振り返りを行い計画を修正する。(時期が迫ったら機能をドロップする短期で補える方法を模索する)

繰り返しにはなりますが、1日1日のアクションプランと振り返り、面接でアピールする内容から逆算したポートフォリオを作るというのがおすすめですので、参考にしていただけると嬉しいです。ここまででスケジューリングの話は終わりですが、つぎに計画を立てる時や学習中の注意点みたいなものをまとめて終わりにします。

学習計画を立てる時・学習期間のNG集

スケジューリングの考え方は流れで説明しましたが、個人的に思う学習の効率を下げている習慣をまとめたので書いておきます。こちらに着いては賛否あるものもあるかもしれませんが一意見として気に留めておいて頂けると良いかと思います。

学習する内容・目的が不明瞭

上の説明でも、何回か書きましたが学習の目的を絞って学習するのがモチベーション維持の観点でも非常に大切です。「今日はHTML/CSSの学習をしよう！」みたいな粒度だと甘いので「Flexboxを使ったレイアウトの方法を勉強しよう」などなど明確に行動を起こせる目的をもった上で学習を進めると進捗の確認がしやすかったり何がわかっていて何がわかっていないかなどが明確になります。

これを意識づけできていると自分が理解していないトピックが明確になってくるので時間があるときにどこを補えば良いのかというのがわかってきて、隙間時間での勉強やりやすくなるはずです。また各技術書なども目的を持って読む必要があり、せっかく買ったんだからと先頭から後ろまで順番に学習する必要はないです。30分などの短時間で読み終えられる技術書なんてほとんどないので、自分が本当に知りたかった情報に辿り着くまでに息切れしてしまいます。

必ず技術書やドキュメントを読み進める前には目次を見て気になるところから読むようにしましょう。また新しい内容は繰り返し触れるのが記憶にも残りやすいので、一つの本の同じ箇所を繰り返し読むようにするとさらに良いです。特に技術形のドキュメントを最初読むことに苦労する方が多いですが、別に一回で理解する必要もないので繰り返し気が向いた時に訪れて目を通すようにしましょう。

勉強時間を確保するための工夫が十分でない

日々メンタリングをしていると業務が忙しくて・・・という形で立ち止まっている方をしばしばお見かけします。

今やっている仕事が大事なのはわかりますが、自分のキャリアを考えて勉強しているのであれば、優先的に時間を確保すべきで、仕事が忙しいというのはあまり理由にならないのかと思います。なにも残業した後でもしっかり勉強しろみたいな筋肉質な話をしているのではなく、

忙しくない部署に移動できないか交渉してみる
忙しくない会社に転職する
残業はしないと割り切って勉強の時間を確保する

みたいな形でキャリアの優先度を第一に考えて勉強の時間を確保した方が良いかと思います。

どこかで壺に大きい石からものを詰めていく話を聞いたことがある方もいるかと思いますが、やはり人間1日に集中できる時間は決まっているのでそれが本業で全て一杯になってしまうのは避けるべきです。(本業は適当で良いとは言っておらず、転職のための勉強が第一なのでそれに従って周りの環境を整えようという話です。) その他にも、隙間時間で勉強するテーマをメモしておいて、移動時間にググって理解する。などなど工夫を行うことで少しづつでも勉強の時間を確保できるかと思うので優先度などを考えながらうまく時間を融通できるようにしましょう。

ポートフォリオの完成に執着する

学習の後の方でポートフォリオの完成に執着してしまって就活が疎かになってしまう方がいるので気をつけましょう。コアな機能ができていないなどであればそれは終わらせる必要がありますが、実態として使えるようになっているのであればあまり完成に執着せずに先に企業に面談にいくなど対外的なフィードバックをもらえる機会を優先しましょう。

自分として納得できるところまで作り込みたいのはわかりますが、それよりも先にREADME.mdやレジュメなどの情報を充実された方が時間効率がよかったりします。現場で得られる経験の方が独学で得られる経験よりはるかに大きいのであまり完成に執着せず目標達成のためにより良い選択肢を選び取れると良いでしょう。

慣れた方法を続ける結果効率の悪い方法で学習を続けてしまう

学習とは慣れた方法を捨ててより良い効率の良い方法を身につけるということでもあるので、より効率の良い方法を探し続けて改善を入れられるようにしましょう。マウス操作が多かったり、コマンドラインでtabでの補完、↑での履歴を使用する。エディタの分割を使う、ファイルの全検索を使ってコードリーディングの効率を高める、ショートカットを覚えるなど初心者の方ができる工夫というのは数がしれないのでこれを日々身につける癖をつけましょう。

学習した内容を書いて覚える/ノートにまとめる

受験のときの学習の癖なのか、学習内容を書いて覚えたりノートに手書きでまとめたりする方がいますが、個人的にはこちらあまりおすすめできません。そもそもネット上の情報だったり書籍というのはそういった作業をしないで良いように情報をまとめたり検索性能を高めたりしているので、学習者の方がまとめるより質が高くてよくまとまっているものがネット上にあるはずです。

何かわからなかったら自分のノートをみるなどするよりは少しでも多くググってサイトの記事を読んで効率的に情報収集できるようにすると良いでしょう。ノートに情報をまとめるよりは、その情報に素早くアクセスできるようにリンク集を作っておくと良いと思います。僕は個人のSlackスペースを作ってそこにペタペタリンクを貼るようにしています。

ノートをまとめるにしてもPCのツールを使ってまとめるようにした方がPCスキル自体の練習にもなるしGithubのリポジトリを使ってまとめたりすればGithubの使い方にも慣れるので、業界でよく使われるツールを調べて積極的に使うと良いでしょう。

情報収集の習慣をつけない

再三言及はしているのですが、プログラミングのための知識は膨大なのでなるべく技術的な情報のアンテナはしっかり立てておくようにしましょう。経験者と未経験者ではこれらの知識量に圧倒的な差があるので日常的な情報収集の癖をつけられると良いです。実際に触ったことはないけど聞いたことのある項目を増やせると業界の全体像も掴みやすくなるのでTwitter, Qiita, Zennなど技術的な情報を得られるサイトから常に情報収集を心がけられると良いです。

コードを動かさない、コマンドを叩かない

いくら概要を理解していてもコマンドを思い通りに動かせない、コードを動かせないうちにはエンジニアへの就職は難しいでしょう。

これを解消するためには、実際に

コードを動かす
思い通りに動かない
原因を特定する
修正する

というサイクルを高速で回せるように練習する必要があるので、実際にコード・コマンドを動かす癖はつけられると良いでしょう。英会話を上達させたいのに、実際に英語を話すことなく文法ばかり学習しても英会話は上達しないようにプログラミングをも同じなので、なるべく遠回りせずにダイレクトに学習を進められると良いでしょう。

「なぜか動かない」など原因特定が甘い・疎かにしてしまう

初学者のうちは経験が少なくて難しいのですが、デバッグ（原因特定・修正）の能力というのはコーディングの早さに直結してくるので、ちゃんとエラーメッセージを読んで理解したり、プリントデバッグを使って問題の起きている箇所を特定したりして独力でデバッグを行えるように意識して練習しましょう。

ここができないといつまでも経験者に聞かないと実装が進まないのでプリントデバッグやステップ実行・エラーメッセージの読み方などを学んで実行・原因特定・修正のサイクルを高速に回せるようになりましょう。

あとがき

以上、ここまでプログラミング学習の計画の立て方をつらつらと説明しました。

メンタリングを行う中で結構就職までの計画の話をしたりするのですが、日々の学習に追われて全体の計画とか目標を見失ってしまっているなー、もったいないなーというのを感じたので、今回こちら思い切って書かせていただきました。

個人的に中長期定期な計画を立てる時にはまず目標から逆算してマクロな計画を作った上で、また別口でミクロな視点から実際に必要な時間をつみあげて両者を突き合わせて調整するというのが一番精度が高いのかななんて思っています。

ここではマクロが6ヶ月の全体計画でミクロが一日の中で何をどれだけ勉強するのか？というところになります。メンティーさんの話を聞いているとこのどちらかの見積もりが甘かったりなかったりするのでこれが両方できるだけでも、うまくモチベーションを保ちながら勉強を進めていけるのかなと思っています。やはり一日単位で目標がなかったりするとどうしても日々の忙しさに追われてなぁなぁになってしまったりするので学習を始める前にしっかりと計画を立てることをおすすめしています。

また、全体の計画を聞いてみるとバッファがほとんどなかったりするものもあるので、なるべく前倒しで終えられるようにできると良いと思います。マイクロソフトの元開発者で起業家の中島智さんの「なぜあなたの仕事は終わらないのか？」という著書にロケットスタート時間術という仕事術が紹介されています。もしも、10日で仕上げるタスクであれば、2割に当たる2日間で8割終わらせるつもりで取り掛かり、この2割の段階で、全体の6割以上終わっていなければ、スケジュール変更を検討する。というようなものです。

ここまで徹底する必要があるかはわかりませんが、締め切り当日にゴールを設定すると不測の事態や新しく見つかったタスクに対応できないので十分なバッファを持たせて計画を立てる必要はあるでしょう。プログラミング学習でも仕事の繁忙と重なった、体調を崩した、予想よりも理解に時間がかかった環境構築に詰まったなどは十分にありうるのでこれを念頭に計画を立てましょう。

プログラミング学習は新たにチャレンジすることも多いので、不確実性が高く簡単ではないタスクになると思いますが、こういったところを抑えながらコツコツと積み重ねていけることができれば必ず達成できるものかとも思います。

ぜひ、これから学習を始める方々、学習中の方などに参考にしていただけると嬉しいです。ありがとうございました。

Go言語でのデータ操作+構造体、関数のチートシート

Sun, 18 Apr 2021 00:00:00 GMT

個人的にプログラミング言語を学ぶ時には、それぞれのデータ形式の操作方法 + クラス、関数などの文法をおさえておくと、何かしらのアプリケーションを書き始める時に役立つと思っています。

と言った所でGo言語でそれらの情報をまとめてみました。

どのプログラミング言語にも大体、文字列、数値、配列、マップのようなデータ型が存在するので、それらについてプログラムを書く上でよく使う書き方を勉強していくと効率が良いです。さらに、プラスアルファでクラスや関数などの文法もおさえて置けるとよいです。

そして、それぞれのデータ形式のCRUDの方法を意識しながら学習して行けるとうまく整理して学習できるかと思います。

CREATE (初期化方法)
UPDATE (置換、部分文字列の取り出し、インクリメントなど)
READ (要素の列挙、型変換など)
DELETE (キーの削除、要素の削除など)

というわけで数値から順番にみていきます。

数値

数値、文字列間の変換は頻出も頻出ですが、桁数指定、0埋めなども結構使うのでそれらをまとめました。

文字列への変換

str := strconv.Itoa(123)
fmt.Println(str)
// => "123"

文字コードからStringへの変換

a := string(rune(65))
b := string(rune(66))
c := string(rune(67))
fmt.Println(a, b, c)
// => A B C

小数点の切り上げ

fmt.Print(math.Ceil(1.1), math.Ceil(1.9))
// => 2 2

小数点の切り捨て

fmt.Print(math.Floor(1.1), math.Floor(1.9))
// => 1 1

小数点の四捨五入

fmt.Print(math.Round(1.1), math.Round(1.9))
// => 1 2

累乗

fmt.Print(math.Pow(2, 1), math.Pow(2, 2), math.Pow(2, 3))
// => 2 4 8

0埋め

str := fmt.Sprintf("%05d", 123)
fmt.Print(str)
// => 00123

桁数指定切り上げ/切り捨て/四捨五入

// 2桁で切り上げ/切り捨て/四捨五入
x := 12.3456
fmt.Println(math.Floor(x*100)/100, math.Round(x*100)/100, math.Ceil(x*100)/100)
// => 12.34 12.35 12.35

String/Byte

おそらくコードを書いていて最も使うデータ型である string ですが、小文字大文字変換、文字列の切り出し、配列への変換などがあるのでそれらを中止にまとめました。

Stringから文字コード

fmt.Println(rune("A"[0])) // 65
fmt.Println(rune("B"[0])) // 66
fmt.Println(rune("C"[0])) // 67

StringからByte配列

fuga := []byte("ABC")
fmt.Println(fuga)
// => 65 66 67

部分文字列の取得

fuga := "ABC"
firstChar := string(fuga[0])
fmt.Printf("type: %T, value: %s\n", firstChar, firstChar)
partial := fuga[0:2]
fmt.Printf("type: %T, value: %s\n", partial, partial)
// => type: string, value: A
//    type: string, value: AB

小文字に変換

str := "ABC"
fmt.Printf(strings.ToLower(str))
// => "abc"

大文字に変換

str := "abc"
fmt.Printf(strings.ToUpper(str))
// => "ABC"

スライスに変換

str := "apple,banana,pineapple"
split := strings.Split(str, ",")
fmt.Printf("type: %T, value: %s", split, split)
// => type: []string, value: [apple banana pineapple]

リピート

str := strings.Repeat("abc", 3)
fmt.Println(str)
// => abcabcabc

スライス・配列

スライスというデータ型がgoの特徴的な型だとは思いますが、RubyやJavaScriptから来た物からすると、filterやmapに相当するものが組み込みであるのか気になって調べたのですが、どうやらないらしくそこはちょっと欲しいなという気持ちになりました。こういった所もGoらしいと思いながら色々と調べてまとめています。

配列の初期化

var arr1[3] string
arr1[0] = "Apple"
arr1[1] = "Google"
arr1[2] = "Facebook"
fmt.Printf("type: %T, value: %v \n", arr1, arr1) // type: [3]string, value: [Apple Google Facebook] 

arr2 := [3]int{1, 2, 3}
arr3 := [...]bool{true, false}

fmt.Printf("type: %T, value: %v \n", arr2, arr2) // type: [3]int, value: [1 2 3] 
fmt.Printf("type: %T, value: %v \n", arr3, arr3) // type: [2]bool, value: [true false]

スライスの初期化

s1 := []int{}
s2 := []int{1, 2, 3}
s3 := []string{"a", "b", "c"}
fmt.Printf("type: %T, value: %v \n", s1, s1) // => type: []int, value: [] 
fmt.Printf("type: %T, value: %v \n", s2, s2) // => type: []int, value: [1 2 3] 
fmt.Printf("type: %T, value: %v \n", s3, s3) // => type: []string, value: [a b c]

要素数でループ

s1 := []int{1, 2, 3}
for i, v := range s1 {
	fmt.Println(i, v)
}
// => 0 1
//    1 2
//    2 3

Find

func Find(list []string, target string) (string, int) {
	for i, v := range list {
		if v == target {
			return v, i
		}
	}
	return "", -1
}

res, i := Find([]string{"a", "b", "c"}, "c")
if i == -1 {
	fmt.Printf("%s is missing in the list", "c")
}
fmt.Println(res, i)
// => c 2

Sample

list := []int{1, 2, 3}
index := rand.Intn(len(list))
fmt.Println(list[index])

ソート

文字列や数値のソートであればサクッと書けるのですが、構造体やmapをソートするには、インターフェースの実装が必要そうなのでまた別の機会に書きます。

i := []int{3, 1, 4}
sort.Sort(sort.IntSlice(i))
fmt.Println(i) // [1 3 4]

s := []string{"def", "aaa", "abc"}
sort.Strings(s)
fmt.Println(s) // [aaa abc def]

部分を取り出し

hoge := []int{1, 2, 3, 4, 5, 6}
first := 1
last := 3
fmt.Println(hoge[3:5], hoge[first:last])
// => [4 5] [2 3]

結合

a1 := []int{1, 2, 3}
a2 := []int{4, 5, 6}
a3 := append(a1, a2...)
fmt.Println(a3)
// => [1 2 3 4 5 6]

Join

str := strings.Join([]string{"a", "b", "c"}, ",")
fmt.Println(str)

map

初期化

m := make(map[string]int) 
fmt.Println("type: %T, value: %v", m)
// => type: map[string]int, value: map[] 

m2 := map[string]int{
	A: 1,
	B: 2,
	C: 3
}
fmt.Println("type: %T, value: %v", m2)
// => mtype: map[string]int, value: map[A:1 B:2 C:3] 2

Key/Value でループ

m := map[string]int{
		"A": 1,
		"B": 2,
		"C": 3,
}
for k, v := range m {
	fmt.Printf("key: %s, value: %d \n", k, v)
}
// => key: A, value: 1 
//    key: B, value: 2 
//    key: C, value: 3

要素の削除

m := map[string]int{
		"A": 1,
		"B": 2,
		"C": 3,
}

delete(m, "A")
delete(m, "B")

fmt.Printf("key: %V, value: %v \n", m, m)
// => key: C, value: 3

要素があるか

m := map[string]int{
	"A": 1,
	"B": 2,
	"C": 3,
}
var hasAKey bool
if _, ok := m["A"]; ok {
	hasAKey = true
}

var hasDKey bool
if _, ok := m["D"]; ok {
	hasDKey = true
}
fmt.Println(hasAKey, hasDKey)
// => true false

日付

初期化

t := time.Date(2001, 5, 20, 23, 59, 59, 0, time.UTC)

現在日付

t := time.Now()
fmt.Println(
	t,            // 2009-11-10 23:00:00 +0000 UTC m=+0.000000001
	t.Year(),     // 2009
	t.Month(),    // November
	t.Day(),      // 10
	t.Hour(),     // 23
	t.Minute(),   // 0
	t.Second(),   // 0
	t.Weekday(),  // Tuesday
)

比較

past := time.Now().Add(-time.Second)
now := time.Now()

if past.After(now) {
	fmt.Println("Past is after now")
}

if past.Before(now) {
	fmt.Println("Past is before now")
}

if now.Before(now) {
	fmt.Println("Now is before now")
}

if now.After(now) {
	fmt.Println("Now is after now")
}
// => Past is before now.

加減

date := time.Date(2021, 4, 1, 8, 0, 0, 0, time.UTC)
fmt.Println(date) // 2021-04-01 08:00:00 +0000 UTC

t1 := date.Add(time.Duration(5) * time.Second)
fmt.Println(t1)   // 2021-04-01 08:00:05 +0000 UTC
t2 := date.Add(time.Duration(5) * time.Hour)
fmt.Println(t2)   // 2021-04-01 13:00:00 +0000 UTC

t3 := date.Add(-time.Duration(5) * time.Second)
fmt.Println(t3)   // 2021-04-01 07:59:55 +0000 UTC
t4 := date.Add(-time.Duration(5) * time.Hour)
fmt.Println(t4)   // 2021-04-01 03:00:00 +0000 UTC

フォーマット

https://qiita.com/ruiu/items/5936b4c3bd6eb487c182

date := time.Date(2021, 4, 1, 8, 0, 0, 0, time.UTC)
const layout = "2006-01-02 15:04:05 Mon"
fmt.Println(date.Format(layout)) // 2021-04-01 08:00:00 Mon

パース

str := "Apr 1 12:34:56 JST 2021"
layout := "Jan 2 15:04:05 MST 2006"
t, _ := time.Parse(layout, str)
fmt.Println(t) // 2021-04-01 12:34:56 +0000 JST

Unix Timeへ変換

t := time.Date(1970, 1, 1, 0, 0, 0, 0, time.UTC)
fmt.Println(t.Unix())          // 0
fmt.Println(time.Now().Unix()) // 1257894000

Unix Timeから日付オブジェクトに変換

t := time.Unix(1234567890, 0)
fmt.Println(t) // 2009-02-13 23:31:30 +0000 UTC

構造体

初期化

type Obj struct {
	ID int
	Name string
}

// 宣言された構造体を初期化
fmt.Println(Obj{1, "Taro"})
fmt.Println(Obj{ID: 1, Name: "Taro"})

// newで初期化
fmt.Println(new(Obj))

// 無名構造体
fmt.Println(struct {
	ID   int
	Name string
}{1, "Taro"})

メソッド宣言

type A struct {
	data string
}

type B struct {
	data string
}

// 値メソッド
func (o A) setValue(value string) {
	o.data = value
}

func (o A) Value() string {
	return o.data
}

// ポインタメソッド
func (o *B) setValue(value string) {
	o.data = value
}

func (o *B) Value() string {
	return o.data
}

a := A{
	data: "Hoge",
}

b := B{
	data: "Hoge",
}

fmt.Println(a.Value())
fmt.Println(b.Value())

a.setValue("Fuga")
b.setValue("Fuga")

// ポインタメソッドの方だけdataの値が書き換わる
fmt.Println(a.Value())
fmt.Println(b.Value())
// => Hoge
//    Hoge
//    Hoge
//    Fuga

関数　

GOの特徴としては、複数返り値や名前付き返り値などがユニークな所ですが、引数のデフォルト値を設定するような構文は今の所ないようです。

初期化


// 引数なし
func Hello() {
	fmt.Println("Hello")
}

// 引数あり
func Hey(msg string) {
	fmt.Printf("Hey, %s \n", msg)
}

// 複数返り値
func Divide(a int, b int) (int, error) {
	if b == 0 {
		return 0, fmt.Errorf("Zero divided")
	}
	return a / b, nil
}

// 名前付き返り値
func MaxMin(list []int) (max int, min int) {
        if len(list) == 0 {
		return max, min
        }
        max = list[0]
        min = list[0]
	for _, item := range list {
		if max < item {
			max = item
		}
		if min > item {
			min = item
		}
	}
	return max, min
}

Hello()                               // Hello
Hey("boy")                            // Hey, boy

res1, err1 := Divide(4, 2)
fmt.Println(res1, err1)               // 2 <nil>
res2, err2 := Divide(4, 0)
fmt.Println(res2, err2)               // 0 Zero divied

fmt.Println(MaxMin([]int{1, 2, 3}))   // 3 1

可変長引数

func sum(nums ...int) (total int) {
	for _, num := range nums {
		total += num
	}
	return
}

fmt.Println(sum(1, 2, 3, 4, 5))
// => 15

無名関数

hello := func(name string) { fmt.Printf("Hello, %s", name) }
hello("there")
// => "Hello, there"

即時関数

(func(name string) { fmt.Printf("Hello, %s", name) })("there")
// => "Hello, there"

高階関数

func add(a int) func(int) int {
	return func(b int) int {
		return a + b
	}
}

fmt.Println(add(1)(2)) // => 3

func add(a int) func(int) int {
	return func(b int) int {
		return a + b
	}
}

fmt.Println(add(1)(2)) // => 3

CodeSandboxでキーリピーティングができない問題の対処法

Sun, 18 Apr 2021 00:00:00 GMT

普段、フロントエンドのコードを書くのにCodeSandboxを使っていますが、ちょっとした問題があったので、この記事ではその解決方法をご紹介します。

問題: CodeSandboxのVimキーバインドでキーリピートが効かない

私は普段コードを書くときにvimを使っているので、ご多分にもれず、CodeSandboxでもvimのキーバインドを使っています。

Vimのキーバインドを設定すると、キーリピーティングが効かなくなり、jキーを押してもカーソルが下に移動せず、キーを連打しないと移動しなくなってしまい、非常に困っていました。

解決策

ターミナルで下記コマンドを実行してください。

defaults write -g ApplePressAndHoldEnabled -bool false

現在のCodeSandboxはVSCodeの設定を継承しているようで、VSCodeでVim Keybindingを使いたい場合、ターミナルでMacの設定を変更する必要があるのですが、CodeSandboxではターミナルを使う条件が限定されているようで、それができません。

VSCodeの設定はこちらに書いてあります。

Macには、キーを押したときの動作をアプリケーションごとに設定する仕組みがあるようですが、キーリピートを有効にするには、この設定ApplePressAndHoldEnabledを無効にする必要があります。

VSCodeでは、ローカルターミナルでコマンドを実行することで、この設定を無効にすることができるのですが、CodeSandboxでは同じことができなかったので、一度、グローバル設定のApplePressAndHoldEnabledをオフにしています。（反映にはコンピュータの再起動が必要です。）

何か問題があれば元に戻せばいいので、ワークアラウンドとしてグローバル設定をオフにしました。

defaults write -g ApplePressAndHoldEnabled -bool true

Chromeを対象に範囲を限定して設定してみてもうまくいかなかったので、過不足なく動くようにするにはう少し追加の設定が必要なのかと思います。

いざとなれば戻せるのであまり問題にならないと思っていますが、グローバルな設定を変更することになりますので、注意して使用していただければと思います。

ブログをリニューアルするついでにGatsby3に上げたので振り返り

Fri, 16 Apr 2021 00:00:00 GMT

ここしばらく就活をしていてバタバタしていたのですが、無事オファーを頂き仕事も開始して落ち着いて来たので、そろそろ2年ほど前に改築したブログをまたリニューアルしたいということでブログをリニューアルしました。

なので、そのあたりをまとめて書いておこうかと思います。

リニューアルの経緯

デザインの変更がメインでスタック的にはほとんどNetlify+Gatsbyで変わりはないのですが、しばらく放置していたライブリ郡が古くなり、アップデートして欲しそうな目でこっちを見ていたのでアップデートをしようということになりました。

ちょうど　GatsbyConf にリアルタイムで参加できて、Gatsby3.0 のリリースを見ていたのもあってちょうど良いかなということで、Gatsby3.0 へのアップデート + リデザインを行っていきました。

デザインについては、

宣伝したい物があるのでバナーみたいな物をつけたい
ポートフォリオ的な位置付けでもあるので、もうちょっと印象に残るデザインが良い
自分でも記事を検索することがあるので検索つけたい
モバイルのPageSpeedInsightの評価があまりよくないので改善したい

などなどの個人的な不満があったのでこれらを元に新しいデザインを決めていきました。

ちなみに以前はこういった形でした。

自分のブログはこれで大体4代目くらいになります。初代はWordpressで作っていたのですが、ページ読み込みの重さや改めてPHPを書く辛さなどなどから2年ほど前に一年発起し、Wordpress => Gatsbyのリプレイスを行いました。その後にカナダでの就活を見越してリデザインしたのが上の画像の頃でこれが3代目です。

WordpressブログをGatsby+Netlifyでリプレースした話。

そして、今回が4代目になるといった形です。色々と話を煤前に全体の構成も書いておくとイメージつきやすいかと思うのでそちらか書いてきます。

全体の構成

Netlifyに移行した時からこちらのような構成だったので構成自体には特に変わりはありません。

ざっくりとした図ではあるのですが、Gatsbyで作成したサイトをNetlifyでホストしているというよくある構成になっています。

Gatsbyはビルド時に gatsby-image や gatsby-image-plugin などを使っていると画像の加工処理が入ってしまって重いので画像は、実際に公開用の環境にデプロイを行うときだけビルドするようにしており、ローカルで yarn start などで開発を行うときは直接URLで画像をとるようにして、 Gatsbyの画像処理系のコンポーネントは介さないようにしています。

サイトとしてそれぞれの記事(全部で100本くらい）にサムネイルが設定されておりそれらを処理するので、それらの画像を処理してから開発用のサーバを立てるというのが 1, 2 分程度かかるのでローカルでは画像の処理を行わないようにして、開発体験があまり毀損されないようにしています。 2代目へのリニューアルをした時に決定したことなので、Gatsby3 でこのあたりは改善されているのかもしれません。今回はリニューアルが主眼な作業だったのでそちらはひとまず置いておいて上記に書いたような環境で開発を進めています。

あとは、2代目のリニューアル当初はNetlifyの前にCloudflareを噛ませていたりしたのですが、当時はCloudflareの所で通信に失敗してサイトに不通になるみたいなのが、少なくない頻度であったのと設定周り色々と面倒なのでNetlifyに直接通信するようにして静的ファイルについてのみCloudflareを噛ませるようにしました。

ちなみに、ブログ中でも記事中の画像など完璧にGatsbyで処理しきれない物があるのでそれらは、直接Cloudflareの画像にアクセスするように設定しています。

そのほか、図にはないですが記事の人気順をとるためにGoogle AnalyticsからPVを取得したり、今回追加されたAlgoriaなども使用しています。

やったこと

下記がリニューアルに当たってやったことです。

技術的な変更点

Gatsby3へのアップデート
TypeScript化
Algoriaの導入

UI的な変更点

全体的なレイアウトやコンセプトなど
検索モーダルの追加
モバイルトップの表示改善
コンソールを使った記事フィルタ
記事中の目次追加

以降ではこれらについて一つずつまとめを書いていきます。

技術的な変更点

Gatsby3へのアップデート

上にも少し書きましたが、元々Gatsby2.xで作られていたのでGatsby本体をアップデートしました。元々 2.24.60 だった物を 3.1.2 に上げてそのほかバージョンが古くなっていたライブラリも一緒にアップデートしました。

最新のバージョン出ないライブラリがほとんどだったので、　｀ncu` を使って雑にアップデートをして動作確認してOKという形でした。

raineorshine/npm-check-updates

% ncu

   ╭──────────────────────────────────────────────╮
   │                                              │
   │      Update available 11.1.1 → 11.3.0        │
   │   Run npm i -g npm-check-updates to update   │
   │                                              │
   ╰──────────────────────────────────────────────╯

Checking /Users/admin/Projects/Private/blog/package.json
[====================] 45/45 100%

 algoliasearch                              ^4.8.6  →   ^4.9.0     
 i18next                                   ^19.9.2  →  ^20.2.1     
 react                                     ^17.0.1  →  ^17.0.2     
 react-dom                                 ^17.0.1  →  ^17.0.2     
 @emotion/styled                           ^11.1.5  →  ^11.3.0     
 @types/react-helmet                        ^6.1.0  →   ^6.1.1     
 babel-preset-gatsby                        ^1.0.0  →   ^1.3.0     
 gatsby                                     ^3.1.2  →   ^3.3.0     
 gatsby-plugin-algolia                     ^0.17.0  →  ^0.19.0     
 gatsby-plugin-canonical-urls               ^3.0.0  →   ^3.3.0     
 gatsby-plugin-emotion                      ^6.1.0  →   ^6.3.0     
 gatsby-plugin-feed                         ^3.0.0  →   ^3.3.0     
 gatsby-plugin-google-analytics             ^3.0.0  →   ^3.3.0     
 gatsby-plugin-image                        ^1.0.1  →   ^1.3.0     
 gatsby-plugin-netlify                      ^3.0.0  →   ^3.3.0     
 gatsby-plugin-react-helmet                 ^4.0.0  →   ^4.3.0     
 gatsby-plugin-sharp                        ^3.0.1  →   ^3.3.0     
 gatsby-plugin-sitemap                      ^3.0.0  →   ^3.3.0     
 gatsby-plugin-twitter                      ^3.0.0  →   ^3.3.0     
 gatsby-plugin-webpack-bundle-analyser-v2  ^1.1.21  →  ^1.1.22     
 gatsby-remark-autolink-headers             ^3.1.0  →   ^4.0.0     
 gatsby-remark-copy-linked-files            ^3.0.0  →   ^4.0.0     
 gatsby-remark-images                       ^4.0.0  →   ^5.0.0     
 gatsby-remark-prismjs                      ^4.0.0  →   ^5.0.0     
 gatsby-source-filesystem                   ^3.0.0  →   ^3.3.0     
 gatsby-transformer-remark                  ^3.0.0  →   ^4.0.0     
 gatsby-transformer-sharp                   ^3.0.0  →   ^3.3.0     
 googleapis                                ^67.1.1  →  ^71.0.0     
 typescript                                 ^4.2.3  →   ^4.2.4     

Run ncu -u to upgrade package.json

こういう形で ncu コマンドを叩くと package.json のライブラリの差分を表示してくれて、全部を一気にアップデートしたいときは ncu -u とするとライブラリを自動でアップデートしてくれます。出力結果は実際にリニューアルが終わった後に叩いた物なのですでにアップデートずみになります。

３月頃にアップデートしたばかりなのに今でも結構差分ありますね。。コンソールで叩くと実施は色付きで表示されるのでもう少し見易いかと思います。

ちょっと調べると yarn upgrade 系のコマンドでも同様のことができるようなのでyarnを使っていればあえてnpm-check-updatesをインストールしてみたいな形でなくても良いのかもしれません。

yarn upgrade --latest で問答無用で最新バージョンにアップデート（https://classic.yarnpkg.com/en/docs/cli/upgrade/)

yarn upgrade-interactive で対話的にライブラリの更新を確認しながらアップデートというのができるようです。(https://classic.yarnpkg.com/en/docs/cli/upgrade-interactive/)

https://www.gatsbyjs.com/blog/gatsby-v3/

Gatsby3 の変更点ですがこちらの記事によると

ローカルでの開発スピードが 80% 改善
ビルド時間の改善
Web Vital, Lighthouse などのスコア向上
gatsby-plugin-image のリリース

あたりが変更点です。

ちょっとまだ試せていないのですが、開発中のビルドを行う時に差分でページのビルドや画像の加工をしてくれるようになったらしいので開発体験がずいぶん改善されたようです。構成のパートで言及した開発中の画像加工重い問題がこれのおかげで解消されているのかもしれません。

また、記事によると Faster build times on any service とあるのでビルド時間も短縮されているようです。これまで Gatsby Cloud のみで動いていていたインクリメンタルビルドがサービスを選ばずに動くようになったようです。記事をみる限り、ページごとに差分でのビルドを行っているのでそれがビルド時間の短縮につながっている様です。

ビルド時にAlgoriaへのインデックスの登録などを行うように変更したりしていたので、リニューアル前よりビルド時間が伸びていてあまり実感できていなかったり、他に集中するために開発時のビルドの高速化具合が未確認などというちょっとあれな感じですが、デザインリニューアルをメインに対応したのでひとまずはこれらの確認ペンディングということにしています。

ただ、個人的にこれら変更点を記事で見た限りだとアップデートをしたくなる変更点が多いのかなという感想を持ちました。

TypeScript化

TypesScript全盛な時代になったので、ご多分にもれず自身のブログもTS化しようということでTS化を進めていきました。

Gatsbyだとフロント部分は結構簡単にTS化できるので、地道にJSファイルをTSに書き換えていく作業を行いました。 TSの方はそこまで厳しい設定にはしておらずだんだんと厳しくして行けば良いのかなというくらいのスタンスで、補完が効くなどの理由でTSを使うようにしました。

問題は、ページ生成する側の gatsby-node.js の部分をどうするかという所なのですが、こちらについては ts-node でTS化すると割と手軽にできるので、gatsby-node.js に以下のように書いてそれ以降読み込むファイルをTSファイルにしています。

require('ts-node').register({
  compilerOptions: {
    module: 'commonjs',
    target: 'esnext',
    esModuleInterop: true,
    resolveJsonModule: true,
  }
})

const path = require('path')
const gatsbyNode = require('./gatsby-node/index')
exports.createPages = gatsbyNode.createPages

exports.onCreateNode = gatsbyNode.onCreateNode
exports.onCreateWebpackConfig = ({
  stage,
  rules,
  loaders,
  plugins,
  actions
}) => {
  actions.setWebpackConfig({
    resolve: {
      fallback: {
        fs: false
      },
...

Gatsbyも 2.x 系の頃から File System Route がサポートされているのでそこでのリファクタも考えたのですが、そこまでいくとまた大変そうだったのでそちらは使わず、createPageを実行する関数を分割してページ構成に合わせて gatsby-node ディレクトリ配下にファイルを配置するようにしました。まだリファクタの余地ありそうですがここにはあまり時間使わずTS化する部分だけを行いました。

Algoriaの導入

サイトに記事が100本以上あるので、検索のために Algoria を導入しました。 Gatsby の場合は、 gatsby-plugin-algolia を使うと結構手軽に実装できるのでオススメです。サイト内検索ができるようになったので、過去記事も漁りやすくなっているかと思いますので試してみてください。自分でも過去記事を漁る時があるので導入してみて自分自身も結構満足しています。　

ちゃんとしたプロダクトに入れるとなると細かいチューニングなどなど必要かとは思うのですが、個人ブログのタイトル、記事、カテゴリなどからの全文検索であればざっくり必要なデータをインデックスに入れて引っ張ってこれます。

詳細な導入方法はこちらの記事が良いと思います。

https://www.gatsbyjs.com/docs/adding-search-with-algolia/

簡単な流れを書いておくと

gatsby-plugin-aloglia をインストール
Algoriaのアカウントを作成、API KEYやトークンを取得
gatsby-confing.js に設定
ビルド時に全体の記事のインデックス登録が走る。
インデックス登録された物からデータを取得する場合は、algoriasearch をインストールして使用する。

という形です。インクリメンタルサーチを実装したい場合は、 react-instantsearch-dom を使ってやったりすると良いそうなのですが、とりあえずそこの部分は自前で実装しても良さそうだったので今回は使わないようにしておきました。

細かい UI 部分は後の部分で触れるのですが、インクリメンタルサーチを実装してみたりしたので、その部分は個人的に勉強になりました。リクエスト部分をスロットルしてリクエストが飛びすぎないように調整していたりします。

  const onChange = useCallback(
    async (text: string) => {
      setQuery(text)
      if (text.length < 1) {
        return
      }
      const res = await search(text)

      setResult(res)
    },
    [setResult]
  )

  const onChangeThrottled = useMemo(() => throttle(onChange, 1500), [onChange])

  return (
    <div css={styles.container}>
      <SearchField
        initialFocus
        containerStyle={styles.field}
        onChange={onChangeThrottled}
      />
      <ul css={styles.list}>
      ...

実際のスロットリングを行う関数はlodashの物を使っています。これまでReact でこういった機能を書くことがなかったのでこの機会に実装できてよかったですね。

UI的な変更点

全体的なレイアウトやコンセプトなど

前回のリニューアルのときは、ざっくりレイアウトだけを決めてあとはコーディングしながらデザインを考えるという割とズボラな実装の仕方をしていたのですが、今回はちゃんと Figma でデザインを起こす所からやりました。

最近、Figma がブラウザで手軽にデザインを書き起こせるので非常に重宝しています。使いこなせているまでは行かないと思うのですが、Figmaでいくつかのサイトをデザインしたので幾分慣れてきたと思います。今回のリニューアルに際しては、一度軽くデザイン作ってみたのですがあまり納得いく物にならなかったので作り直しを行いました。

先に書いたようなデザインとコーディングを並行でやるズボラなやり方だと結構実装の手間が勝ってしまってデザインがおざなりになってしまうので、予めデザインをしっかり起こしてからコーディングできると良いのかなと思いました。（当たり前ですが・・今までサボっておりできていなかったので）

リデザインに関しては、

宣伝したい物があるのでバナーみたいな物をつけたい
ポートフォリオ的な位置付けでもあるので、もうちょっと印象に残るデザインが良い
上に書いたバナーみたいな物を追加したい

みたいな要求（欲求？）があったのでそれを元にレイアウトなどは決めていきました。

また、印象にのこるサイトがよかったので紫（これはReactのイメージカラーから持ってきました。。）を基調に最近ボチボチトレンドなどと言われている Glassmorphism ポイ透け感を入れたサイトにしました。実際に動画などに上がっているGlassmorphismのデザインはもっと派手ですが、記事を読むサイトに置いてあまり派手すぎるとそれはそれで疲れるかなということで抑えめにしています。

デザインは、全然体系的に勉強はしていなので趣味レベルではあるのですが、ちょっと気づいた時にお気に入りのサイトをストックして観察したり、Youtube のデザイン系のYoutuberの動画をみたりして少しづつ知見をためてきたので以前のデザインよりはましになったのかなと思っています。

モバイルの時のUI改善

モバイルでの Page Speed Insight のスコアが悪かったのでその辺りも改善できるように工夫したりし、モバイルの記事の一覧はできるだけシンプルにしてサムネイルなどは表示しないようにしました。これは自分でもモバイルで色々な技術系記事をみるのですが、サムネイルがクリックの決め手になることが少ないのでまぁ特になくても影響ないとい判断でサムネイルは表示しないシンプルな画面にしました。

結果的に元々黄色スコアだったものが緑まで改善されたのと、だいぶ見やすくなったというのがあるのでやってみて成功でした。

検索モーダルの追加

検索を追加したのは上で書きましたが、検索モーダルは二箇所に設置するようにしました。ヘッダーの検索アイコンと各記事の下に検索フォームを設置して、サイトに訪れたタイミング、記事を読み終えて他の記事もみてみたいとなった時などに利用できるように二つの箇所に設置しました。

実際にどれくらい検索されるのかとかは測定してみるのも良いかなと思うので、どこかのタイミングで測定してみたいです。（使われてなくても少なくとも自分は使う気がする）

記事への目次の追加

記事中で記事の全体が把握できるように目次を仕込みました。Gatsbyでは gatsby-remark-autolink-headers を使うとマークダウンから生成された見出しにリンクを自動で付与できるのでそれを使って目次を実装しています。

それぞれの記事のデータの見出しは gatsby-transformer-remark でパースした結果に含まれているのでその結果と上記で生成される id属性を結びつける形で実行できます。お好みでスムーズスクロールにしたり、目次を追従するようにして出来上がりという形です。

目次の表示の形としてモバイルだと今目次が表示できていないので、そこは要改善という形です。モバイルでは目次を最初の見出し前に出すような形で表示するよう考えていますが、記事によっては全く見出しのない記事もあるので「どうしたものか」というのはありますが、とにかくどこか時間を見つけて実装できればと思っています。

コンソールを模した記事フィルタ

前述のように印象に残るようなサイトがよかったので、記事のフィルタとしてコンソールを模した物を配置しています。こちらはまだまだ作り込み必要な気がしているのですが、とりあえず、

新着記事
人気記事準
ピックアップ記事
カテゴリ
タグ

という形で記事を絞り込めるようになっています。

本当のところは、ls, pwd, cd 的な物を実装したかったのですが、ひとまず時間かかりそうなのでリリースを優先してそのまま出しています。

今のところカテゴリ、タグ周りが結構整理されない形でタギングされているような感じもあるのでここらも合わせて整理していきたいです。

振り返り

トータルで結構な作業量にはなったのですが、Figmaからしっかりデザインを起こして実装・リリースまでできたのである程度納得いく形で終えることができました。サイト内検索をつけて利便性向上していたりもするので満足です。モバイル用の目次の実装やコンソール部分の実装、Gatsby3で改善された画像のビルド部分を踏まえた開発環境の最適化など積み残しはいくらかありますが、記事追加と合わせて少しづつ作業進めて頂ければと思います。

ここまで読んで頂いた方には、ブログの実装で使っているプラグイン等々の情報などが役に立てば良いかなと思います。

では。

トロントの会社でフルタイムのFull Stack Developerとして働き始めました。

Thu, 15 Apr 2021 00:00:00 GMT

タイトルの通りそのままなのですが、昨年10月頃から進めていたカナダでの就活が実を結び晴れて3月中旬よりトロントの会社で働きはじめました。

簡単に自己紹介すると、元々事業会社でエンジニアとして働いたり、フリーランスやったりをしていたのですが一昨年の10月にバンクーバーに移住してきたものです。

今年2月末頃にFull Stack Developerのポジションでオファーを頂き、無事3月からチームにジョインして働きはじめました。住まいはバンクーバーなので、とりあえず自宅からリモートで働いています。

これからやること

上にも書いたようにFull Stack Developerというポジションでオファーをもらい基本 React, Ruby on Rails のスタックをメインに仕事をしていくことになります。直近はバックエンドのタスクが多そうです。

Goを使っているプロジェクトもあるようなので、Goあたりも触れると面白いと思っています。またプロダクト自体結構なユーザがいるので、その辺りのインフラ部分やプロジェクトの進め方などなどちょうど北米の開発の仕方などなどを体験してみたかった自分には最適な職場です。

個人的には、ここの所フロントエンド側への関心が強く、サーバ側の知識のキャッチアップがおざなりになっていたりしているのを自覚しているのでこれを機に、Docker、k8s周りGraphQL、Goなどなどのあたりを何か作りながら知識深めたいなと思っている所です。また、サーバ側をやるにあたって基礎となるローレベルの知識など言語やライブラリによらない知識も増強できると良いなと思っています。

就活の話

5ヶ月間就活をしていたのですが非常に長かったです。当初は1, 2ヶ月くらいで決まるかと思っていたのがそうはいかずずるずると時間がたってしまいました。最終的には、会社のカルチャーや技術力、待遇等々の面で納得できる会社からオファーを貰えたので本当に良かったと思っています。

覚えている範囲でざっくり30, 40社程度アプライをして3つほど最終面接まで行って1社からオファーを頂いたという形です。

企業を探して自分に応募するというよりは、LikedinやIndeedなどでリクルーターから連絡をもらった会社を受けるというのがメインでした。リクルーター経由だとレジュメだけ渡して面接まで進めることが多いので、場数を踏むことができ英語圏での面接に慣れる事ができたので良かったと思います。

就活については、機会があればどこかでもう少し詳細にまとめて記事にするかもしれません。

働き始めてみて

働きはじめて、まだまだ二週間なのでなんとも言えないところもあるかと思いますが、ひとまずの所感をまとめておきたいと思います。

英語について

ニ週間やってみてですが、まぁやはりこちらが一番苦労する部分なのかなぁと思う所です。一対一でのコミュニケーションはまぁなんとかなるのがやはり複数人のミーティングというところでは中々大変で、今話されているトピックを見失うこともしばしばです。おそらく、ずれた発言をしていたり発言すべきタイミングで上手く乗れなかったりという感じでかなりぎこちない感じになっているかと思います。

そのほか、やはり英語で情報をインプットした場合の理解力や定着力が日本語の10分の1くらいなのでちょっとしたことにも時間がかかるので中々辛いです。

英語圏で働くにはあまり文句も言っていられないのですが、まぁ現状こう言った悩みにもある程度長い時間かけて辛抱強く付き合っていかないといけないのかなと思っています。

英語を使っている時の違和感とかフラストレーションはプログラミングをやっている時に似ているなぁと思っており、人によるのかもしれないですが結構プログラミング初めて最初の二、三年は「なんか上手く行かない・・」という思いをずっと抱えながらプログラミングと付き合っていました。今でもやはり、「なんか思ったのが作れない」「どうやって作るんだろ？」という違和感を抱えながら日々試行錯誤をしているのですが、二、三年前よりは確実に技術力がついているので、英語もそれと同じなのかと思っています。

英語もきっとこういう形で長い目でみながら試行錯誤を繰り返して向上できると良いなと思っているのですが、せっかく英語圏で働けるのであれば限りなく同じレベルで議論をしたりコミュニケーションを取ったりできるようになりたいすね。それに向けてゴールをブレイクダウンしながら、うまく英語力+コミュニケーション力を鍛えていければと思っています。

時差について

家はバンクーバーで職場は反対側のトロントということで時差が3時間あります。言わずもがなでリモートで働いていはいるのですが、トロントの方が時間が早いので、向こうの時間に合わせて7時に起きて仕事を初めています。

早くに仕事を始めると早く仕事が終わるので良い面もあるのですが、まぁやはり時差は辛いですね。仕事も慣れてくるともう少し柔軟に働けるかとは思うのですが、今は変則的な勤務スタイルになっています。

カナダでもコロナでやはりリモートワークは一気に加速したようで、就活をしていても本当にいろいろなタイムゾーン、国の人たちと面接をしました。社内にもトロント以外のタイムゾーンで働く人も多いので、この時差問題についても徐々にベストプラクティスみたいなものが出てくると良いですね。

時空をいじったりはできないので、コミュニケーションの取り方やツールで解決していくことにはなると思うのですが個人的にも色々模索できると良いと思います。

今日本、トロント、バンクーバーの3つのタイムゾーンを管理して生活しているのですがアプリのカレンダー機能が手放せません。Macのカレンダーには複数のタイムゾーンで予定を入れて管理しているので重宝しています。

リモートでのオンボーディング

また、今回初の完全リモートでのオンボーディングとなりました。

リモートでのオンボーディングは受け入れ側とジョインする側共に難しいプロセスだとは思いますが、今のところスムーズに進んでいるかと思います。

これまであまりオンボーディングのプロセスなどは意識して来なかったのですが、今の会社では最初の二週間くらいで色々な部署の人とのミーティングがセッティングされていてそれを順にこなしていきます。これをすると、とりあえず顔見知りになれたり、丁寧に業務の内容を説明をしてもらったり雑談したりできるのでだいぶ会社のイメージを掴む助けになります。もちろん、そんなちょっとで全てを理解することはできないのですが入社して右も左も分からず、社内の誰とも直接会ったことがないの人にはだいぶ助けになりそうです。

全体的な所

という形で全く勝手の違うことばかりなのですが、ある意味こう言った環境を求めてわざわざカナダ移住してきたので大体はウェルカムです。周りの人を見ていて、それが正解なのかはわからないのですが、あぁこういう進め方をするのねと言う形で感心していて日々学びばかりです。

上に書いたような違和感を一つずつ解消していくのも快感だったりするので、気長にできると良いかと思っています。

まとめ

仕事が始まってから書こう、書こうと思っていたのですがようやく書けました。とりあえず、報告みたいな記事になってしまいましたが、思ったことをダラダラ書いてるとずっーと終わらなそうなのでここらで切ります。

カナダでの働き方や就活の仕方、生活、ぼんやり考えていることなどはまだまだあって記事にできそうなのでどこかのタイミングでまた書けたらと思います。

では。

2020年の振り返り

Wed, 10 Mar 2021 00:00:00 GMT

時が過ぎるのも早いものでもう2021年2月に差し掛かっています。もういく日もしたら3月という形でぼーっとしているとすぐに時間過ぎていきそうです。バンクーバーは徐々に雨の日も減り出して春が近づいている？ような気がしています。

毎年自身のブログで年ごとの振り返りをしているのですが、今年は就活をしていたりドタバタしていたのでしばらくこちらの振り返りをかけずにいました。

「振り返りたいなー」という気はあったのですが、時間が取れずにいたのでこのふとした時にでも振り返っておこうと思います。

2018, 2019年の記事もあるのでもしよかったらみてみてください。

まぁこのあとはとつとつとふり返りをしていくのですが2020年はご多分にもれずお家時間が長かったので直接的な刺激が少なかった一年だなぁなんて思っていたのですが、いざ振り返ると人生初のことばかりでそれはそれで充実した一年だったのかなと思います。

といった形で前振りはここまでで振り返りをしていこうと思います。

2020年バンクーバー留学コロナ直撃

2019年の振り返りにも書いていますが、2019年秋ごろよりバンクーバーに留学して現地のカレッジに通っています。二年で卒業できる仕組みになっており前一年は授業を受けて単位をとる、後一年は自分で就職先を見つけて一定の時間働いて卒業のような形になっています。

今はその前一年が終わって後にも書きますが、今後の就労先を見つけるために就活をしています。

コロナが本格的に警戒されはじめたのが去年三月頃で、平日は毎日通学していた学校がリモートに切り替わり、定期的に参加していた言語交換のミートアップ、ラクロスの練習などなどが中止になりもろに影響を受けました。

個人的には、幸いにもリモートの仕事がメインだったので仕事がなくなるなどのことはなかったのですが、家にいる時間が極端に増加し、運動量が目に見えて低下し、無事体重もキャリアハイを記録することができました。

飲食店でみんなで集まったりはできなくなりましたが、幸いにもバンクーバは夏はハイキング等々のアウトドアアクティビティ、冬はスノーボードができて非常に充実しているので適度にストレス発散できました。

また、ステイホーム期間には気づくと人と話す期間が激減して、1週間一度も人と話をしなかったなんてこともありそうですが、MENTAでサービスを提供させて頂いていたおかげでメンタリングの合間の雑談等々でずいぶんリフレッシュができた気がしています。

MENTAでフロントエンドエンジニアを目指す方向けのコースをはじめました

兼ねてからフリーランスとして二年程度、エンジニアとしてトータル五年ほどのキャリアがあったのでそこから得たノウハウなどを還元できないかということで2020年の3月頃からMENTAでフロントエンドエンジニアを目指すサービスを提供開始しました。

MENTAで提供しているフロントエンド向けのコース

図らずも、第一波のステイホームの期間と被ったことなどもあり、多くの方に契約頂き半年程度でMENTA内のランキングで全体の上位1%程度のメンターに送られる金バッチメンターとして認定いただけました。

2020年には常時20~30人ほど契約者様がいるような形で運営をさせて頂き、MENTAのランキングというような外見の実績以外にも、学習をお手伝いさせて頂いた生徒さんの中から実際に未経験から企業への就職を決めた方や課題を進めていく中でどんどんとレベルアップしていく方を目の当たりにして、自身の知見をシェアして役に立てた実感があり実にやりがいのある経験をさせて頂きました。

また、生徒さんが全国に散らばっていたので生徒さんの地域ならではの話を聞けたりしてこちらも良い経験になりました。

いろいろな地域のメンティーさんと話す中で首都圏とそれ以外でやはり結構な技術的な格差があるんだなというのにも気付きました。

技術力の高い企業は首都圏に集中し、その中でコミュニティが形成され知見が共有されていくので必然的にそこに入れない地域とそこにすむ技術者の人はかなり積極的に情報に対してアプローチしないと追い付いていけないのでは？というところが非常に気になりました。

リモートワークが促進されてこういう隔絶が平準化されると良いなとは思うのと、あとで話す技術アドバイザ的な形でこういった構造を少しでも改善できる取り組みが今後できると良いなと思いました。

2021年も引き続きMENTAは続けていく予定ですので、興味のある方は上のリンクからご連絡頂ければと思います。

HTML/CSS, JS ~ Reactを通しで学べるコースをご用意してお待ちしております。

Techpitさんから「スネークゲーム 🐍 を作って学ぶ React Hooks API での状態管理」という教材をリリースさせて頂きました

React Hooksに関する教材を執筆・リリースしました

タイトルの通り、React Hooks APIに関する記事の執筆をさせて頂きました。詳細はこちらの記事を参照頂ければと思いますが、個人のブログ記事をみてくださったTechpitの担当の方から連絡を頂き執筆の機会を頂きました。リリース後大ヒット！という訳でもないのですが、コンスタントに購入頂いたりTechpit Unlimited という学び放題のプランでもお活用頂いているようで嬉しい限りです。教材の詳細などなどは上記リンク参照ください。

バンクーバーでの就活をはじめました

2020年の秋頃から当初のカナダ移住の目的であった現地での就活をはじめました。現在進行形で就活をしているので結果が出ればまた改めて記事をかければと思います。

フリーランスを退職します。カナダ行きます。 | So Far, So Tech

今のところはやはり日本の就活とは勝手も違い、使う言語も違えば慣習も違うので、不慣れなカバーレターやレジュメを書いたり、周りの人を頼りながら手探りで進めています。

計画では、10月頃から就活を初めて3ヶ月程度で終えられれば・・と思ったのですが、そうはうまくいかず最終まで進めたものがあったりもしたのですが就活は2021年に持ち越しとなりました。

結果が出ればまた改めて記事を書きたいと思います。

技術的な話

技術的なところでいうと今年は下記のようなところが印象に残っています。

英語圏に住んで英語力が伸びてインプットできる範囲が広がった
データ＆アルゴリズムの授業を経て、データ＆アルゴリズムの基礎を踏まえたコードが書けるようになった
技術アドバイザーの仕事依頼があり、フロント周りのアドバイザーを始めた
面接対策+MENTAでのメンタリングで知識が深まった

まず最初に、英語については「まぁそうだよな」という感じなのですがこちらに一年住んで英語力が向上したのでYoutubeの動画や英語記事、OSSリポジトリなどなどから獲得できる情報が増えインプット元の幅が増えたのでこれまでと違ったアウトプットが出せるような気がしています。

次に、2020年は主に学校でプログラミングの学習をしていたのですがそこで改めてデータ＆アルゴリズムの授業を受けました。これまで独学でWebエンジニアになってそこまでデータ&アルゴリズムの学習をやった訳ではないので授業で復習をしましたが、これが結構ためになり普段書いているコードの計算量やデータ構造などへ意識が向くようになり以前よりより良いコードが書けるようになりました。

フロントエンドだとあまり関係ないと思われるようなこともあるかもしれませんが、DOM自体がツリー構造でツリー構造を扱うには再帰が扱えるとコードを簡潔に書ける。スタック・キューなどの構造を理解しているとエディタ上での編集履歴の管理の実装に役立つなどなどが見えてきて、そこまで難しいことはやらなくて良いから、スタック・キュー、ツリー、再帰などなどの主要なトピックと典型問題の回答みたいな物は抑えておけると実務で同じようなデータ構造のパターンに出くわした時にサクッと簡潔な実装ができるようになりそうです。また、LeetCodeなどの問題を解く中で、実際の面接を想定して30分以内に解ききる、全てのテストケースに一発で通過するようにコードを書くというようなのも良いトレーニングになりました。頭に浮かんだロジックをバグなく実装できるというのは、実装スピードに直結するので「これは良い練習だな」という感想を持ちました。

三つ目に、MENTAでの繋がりで実際の企業さんからフロントエンド周りのアドバイザを依頼されて初めてアドバイザというポジションで仕事をさせて頂きました。「自分がコードを書けるようになる」というのと「チームメンバーがより良いコードを書けるようになる」という大きな違いがあります。こ違いがアドバイザを行う上で結構大変なのですがやはり、一人で書けるコード量には限界があるので「強いエンジニアを最短で増殖させることができるエンジニア」はプロジェクトの生産性を無限に高められるのでそこを目指して試行錯誤しています。

最後に、就活対策として想定質問に回答したり、メンタリングでメンティーさんからの質問に回答する中で自分自身に関しても知識の幅を広げることができました。「学んだことを説明するのが一番効率の良い学習法」とはよく言われますが、メンタリングを通して概念を説明する時に自分の理解が追いついてないと説明ができないので教材の準備などを通して自分自身のスキルアップにも役立ちました。もちろん「教える」立場なのでそこがメインの目標ではダメですが副産物として新たな発見があったのでここに書いておきます。そのほかにも、就活対策として「JavaScript interview questions」のような感じでググるというのも面接対策としてだけでなく、スキルアップにも聞きました。Interview Questionsでググると自分が知らない知識のチェックにもあるので弱点を把握できてそこを重点的に学習すると結構効率的にターゲットの分野の知識を得られることに気付きました。例えば、新しいプログラミング言語を学ぶ時なんかにある程度できたなというところで Interview Questions でググってみて自分の実力を把握するなんていうのもアリなのかなと思っています。

という形で順番に印象的だった内容を書いてきましたが、1 以外はほとんど想定していなかったので良い発見ができてラッキーという感じです。積極的に何か新しいことを始めると、また新たな発見があり次に繋がっていくのを書いていて非常に強く感じました。

まとめ

2020年の総括としては、2019年にバンクーバー移住を決めて、2020年は新たな職場が決まるまで色々と落ち着かせる年になるかなとは思ったのですが、思ったよりも新たに始めることができたものが多く、そういう意味では良い年になったかなと思っています。

コロナでリアルなミートアップに参加できなくなってしまったり、色々なことが制限されたところもあったかとは思いますが、新たに得たものもあり良い一年だったと思っています。

2021年はバンクーバーでの就職先での活躍はもちろんのこと、英語力の強化、個人開発の継続あたりをテーマにやっていければと思っています。遅くなりましたが、今年一年よろしくお願いします。

では。

mp3ファイル分割サービス Egg Cutter ベータ版をリリースしました。

Thu, 25 Feb 2021 00:00:00 GMT

I'm so excited to announce that I released Egg Cutter Beta version, which split an mp3 file easily. ~と言う形で英語版のアナウンスをかけるくらい流暢であれば良かったのですが、そうでもないので通常通りにお知らせします。

2月9日に Egg Cutter のベータ版をリリースしました。

書きました #EggCutter

音声分割サービス Egg Cutter ベータ版をリリースしました。｜version1 @version1_2017 #note https://t.co/cA2eS8kJhm
— Jiro@Vancouver (@version1_2017) February 20, 2021

ベータ版なので今のところ特に登録不要・無料で公開しています。

サービスとしては、mp3ファイルをインストール不要でWeb上で分割できるようなサービスになっています。本格的なファイルの分割などは、各デスクトップなどに譲るとして、英語の音声CDの分割など手軽な音声編集に使用できるサービスになっているかなと思っていますので、ぜひ使ってみてください。

ゆくゆくは有料化したいなーと思っていますが、今のところは機能も少なく小さく始めたばかりなのでページに行けばすぐに使い始められます。

https://egg-cutter.net/

Egg Cutterを作った経緯

僕のことをほとんど知らない人が大半かと思うので、簡単に自己紹介しておくとここ二年ほどは日本の仕事をフリーランスでこなしつつ、カナダのバンクーバーに移住してこちらで働けないか色々と画策しているものです。

と言うことでご多分にもれずバンクーバーでは英語を使い、いざ働こうものであれば英語は切っても切り離せないものになっています。英語でコミュニケーションをとるには当然ボキャブラリが必要で、「オレプログラムウゴカスオマエゲンシジンナル」みたいなボキャブラリだと生きては行けますが他人の考えに触れたり、バンクーバーにいるバックグラウンド多様な人の話を聞いたりと言うことが出来ない訳です。

そんな背景でボキャブラリの増強に課題感を持っていたので、どういう方法が良いのかを考えていると以前師事した英語の師匠的な人もYoutube上にいるYoutuberも「音から入る」と言うことを重要視しているようです。

単語を覚える際も「音を覚える」のと本に書かれた「文字を覚える」のでは大きな差があり、音のみで情景がイメージ出来ないと実際の会話のスピードについていけません。

正しい発音ではないのはわかっているのですが、以前一緒に働いていた人がpythonのことを「パイトン」と発音していて、自分は何を行っているのが分からず「白湯（パイタン）スープ」が一瞬頭をよぎりました。

白湯スープが頭を通り過ぎる瞬間はごくわずかでしたが、会話ではこの一瞬が命取りで母語の言葉ではうまく取り繕えたりするかもしれないのですが、第二言語となると致命傷です。

という訳で単語は音声を通して覚えるのが良いと言う考えのもと音声付きの単語帳を多用しているのですが、多くの単語帳CDは10~20単語ほどの音声を一つのファイルにまとめていることが多いです。

と言う訳で、10~20ほどの単語をまとめて聴きながらそれぞれの単語を覚えるのですが、正直その中でも定着度にかなりの差が出てきます。以前聞いたことがある単語やフレーズはすぐに覚えられますし、そうでない全く新しい物はなかなか覚えられません。英語を効率的に学ぶ方法としては、「新規」の単語を集中的に潰していくことが大事になるのですが、10, 20セットになっているCDではそれが出来ません。

ということでそれらの音声を分割して単語、フレーズごとに分割して「覚えたフレーズ」はプレイリストから消していくと言う手法が一番効率の良い学習方法になります。

なのですが、僕の検索した限りだと同様のサービスはデスクトップアプリとして作られているのでよく知らないアプリをインストールしないと行けない。Adobeなどの製品を使えば分割できるけど、有料だし起動も遅いしでなんか億劫といった問題があり、こちらのEgg Cutterを作ればと言う考えに至りました。

前置きが長くなりましたが、 Egg Cutter は「mp3ファイルを手軽に分割できるサービス」です。今のところ当初の僕が欲しいツールと言う発想の語学学習者向けの色が強いですが、その他の用途などありましたら連絡いただけると嬉しいです。

Egg Cutter と言う名前について

自分のキャリア上プログラマとしてフルスタックエンジニアと言う形で割と「器用貧乏」なキャリアを積んできました。

エンジニア業にかかわらずいろいろなことに興味があるので一つを極めるというよりは広ーく知っていると言うような表現が近いのかななんて思っており、常日頃あの「ゆでたまご」を均等に切り抜くことに特化した形状や、そのほかに特化することなく、「ゆでたまご」を切り抜くための窪みまで備えた尖ったあの「たまごを切る奴」に憧れ、そんなキャリアを気づくことを夢見ていました。

と言うことはないのですが、子供の頃からなんか気になるあの「たまごを切る奴」が今回つくったサービスに近いのでEgg Cutterと言う名前にしました。Egg Slicer と言う呼び名もあるようなのですが、Egg Cutterの方がなんかしっくりきたのでそちらを採用しました。

Egg Cutter と言うサービス自体が音声を聴きながら分割箇所を決めて、そのままの分割ポイントでざっくりと分割できるので、あの「たまごを切る奴」みたいな切れ味を楽しんでもらえると嬉しいです。

最後に

ユーザさんの声を元に機能を足したりもしていきたので、「これがあると嬉しい」みたいなのがあればTwitterやサイトのお問い合わせから連絡いただけると嬉しいです。感想を #EggCutter のタグで呟いていただくだけでも嬉しいです！

今のところボキャビルのためのサービスですが、他にも色々と使い道がありそうな気もしているのでこういうのに使えそうというのがあれば教えてもらえると嬉しいです。

まだ、使ったことのない方は一度手元にあるmp3ファイルでその切れ味を試してみてもらえると嬉しいです！

https://egg-cutter.net/

では。

rss latest ja

2024 年版 開発時のエディタ周りの環境設定(Neovim, tmuxなど)まとめ

エディタ周りの環境

PC周り

ターミナルアプリケーション

Tmux 周りの設定や使い方

作業時のウィンドウのレイアウト

キーバインド

Neovim の基本設定

ディレクトリ構成

基本設定(base.lua)

Leader について

基本のキーバインド(keymaps.lua)

NeoVim のプラグイン周り(plugins/*.lua)

パッケージマネージャ

lazy repo

補完・シンタックスチェック

nvim-lspconfig repo

nvim-cmp repo

nvim-treesitter repo

copilot.vim repo

ファイルエクスプローラ

nvim-tree repo

検索

ファジーファインダー telescope

フォーマッタ

フォーマッタ conform.nvim

見た目系

ステータスバー lualine

カラープレビュー nvim-colorizer

その他

キーバインドヘルプ which-key

囲み文字編集 nvim-surround

まとめ

Ruby のmethods メソッドをJavaScript で実装する

Ruby のmethods メソッドとは

実装

使用上の注意

コードの解説

プロトタイプチェーン

find メソッドでやっていること

まとめ

2022年。ふりかえり

本業

副業

プライベート

総括

プログラミング学習のスケジューリングについて

なぜプログラミング学習で挫折するのか？

プログラミングを難しくしている要因

エンジニアになるために必要な知識

解決策: スケージューリングにこだわる

勉強の計画の立て方

1. 転職する時期を決める

2. 面接でアピールする内容を決める

3. ポートフォリオで作るものを決める

4. テーマ毎の粒度で中期の勉強計画をたてる

5. 1日に必要な勉強時間・勉強内容をきめる

6. 1日単位・週単位で振り返りを行い計画を修正する

スケジューリングのまとめ

学習計画を立てる時・学習期間のNG集

学習する内容・目的が不明瞭

勉強時間を確保するための工夫が十分でない

ポートフォリオの完成に執着する

慣れた方法を続ける結果効率の悪い方法で学習を続けてしまう

学習した内容を書いて覚える/ノートにまとめる

情報収集の習慣をつけない

コードを動かさない、コマンドを叩かない

「なぜか動かない」など原因特定が甘い・疎かにしてしまう

あとがき

Go言語でのデータ操作+構造体、関数のチートシート

数値

文字列への変換

文字コードからStringへの変換

小数点の切り上げ

小数点の切り捨て

小数点の四捨五入

累乗

0埋め

桁数指定切り上げ/切り捨て/四捨五入

2024 年版開発時のエディタ周りの環境設定(Neovim, tmuxなど)まとめ

関数　