rss all

言わずもがな 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

高機能なファジーファインダープラグインです。ファイル検索や文字列でインクリメンタルサーチができます。正直エディタにこれがないと辛いですよね。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

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

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

その他

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

設定 plugins/whichkey.lua

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

囲み文字編集 nvim-surround

nvim-surround | 5 Neovim Plugins To Improve Your Productivity

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

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

まとめ

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

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

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

Implementing Ruby's methods Method in JavaScript

Mon, 29 Jul 2024 00:00:00 GMT

Suddenly, isn't Ruby's methods method handy? When writing code, it lists all the methods and properties available for an object and allows you to search through them, which is very useful for debugging.

Besides that, it is also effective for checking methods specific to frameworks like Rails, aiding in code reading and understanding libraries. While it's good practice to refer to official documentation or source code, the methods method is quite helpful for libraries where you don’t need to dive deeply or when you have vague memories of method names.

Ruby's `methods` Method

To briefly introduce Ruby's methods method, it looks like this:

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.

In other words, it returns an array object of the properties and methods accessible from the receiver.

This method is implemented in the Object class, which is the ancestor of all classes that inherit from Object, so it can be used in any class inheriting from Object.

Sample Code

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]

As shown in the example, it returns an Array object, so you can also search through the list of methods using the grep method, which is very convenient.

So, I thought about whether this could be done in JS and gave it a try.

Implementation

Below is the actual code.

The class name can be anything, but I’m naming it PropertyFinder for now.

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]
    }
}

I’ll explain the code later, but let’s start with how to use it.

Once the class is defined, you can add a method to the Object class's properties as follows:

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

By doing this, you can use the methods method on instances of classes inheriting from Object. However, please be aware of the caution note below and use this at your own risk.

Here are some example executions:


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']

Safety Introduction

**This code is not recommended for use in production environments **

Adding properties to higher-level classes through monkey-patching is an anti-pattern and could lead to problems with future changes in JS specifications. Use it with caution and at your own risk.

Reference : The cons of monkey patching

Code Explanation

Now, let's move on to explaining the code.

The most important method in PropertyFinder is the find method. This method traverses the prototype chain of the given object, searches for accessible properties, and returns them as a list.

The toString and grep methods simply use find, so they don't need further explanation.

Prototype Chain

The prototype chain might be unfamiliar to some, but it’s the inheritance of properties from the Object class.

Inheritance and the prototype chain | MDN

The details are covered in the MDN documentation, but JavaScript's inheritance mechanism is supported by the prototype chain.

Although it's not always obvious, when referring to some property, the process involves:

Checking if the receiver itself has the property.
Checking if the parent class instance has the property.
Checking if the property exists in the parent class’s instance's parent class.

This process continues up the chain until a match is found, which is then returned.

What the `find` Method Does

Given the above, the find method in PropertyFinder implements this mechanism, allowing you to get a list of properties by recursively exploring __proto__.

Here's the implementation that achieves this by exploring __proto__ recursively to get the list:

    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]
    }

That concludes the explanation of PropertyFinder.

Wrap up

That wraps up the explanation of the code and what I’ve tried.

This was more of an experimental or playful exercise, but since it involved some knowledge and techniques, I hope you find it useful or inspiring for your own applications.

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

How to fix the problem of not working key repeating in CodeSandbox's Vim key binding.

Sun, 18 Apr 2021 00:00:00 GMT

I usually use CodeSandbox to write some front-end code, but I had a small problem with it, so this article is about how to fix it.

Problem: Not working key repeating in CodeSandbox's Vim key binding

I usually use vim when writing code, so as you might expect, I use vim key bindings on CodeSandbox as well.

When I set up Vim key bindings, key repeating stopped working, and even if I held down the j key, the cursor didn't move down, and I had to hit the key repeatedly to move it, which was very annoying.

How to fix

Run command in your termnal.

defaults write -g ApplePressAndHoldEnabled -bool false

It seems that the current CodeSandbox inherits the settings of VSCode, and when I want to use Vim Keybinding in VSCode, I need to change the Mac settings in the terminal, but I can't do that in CodeSandbox because the conditions for using the terminal seem to be limited.

Setting for VSCode is written in here

It seems that Mac has a mechanism to set the behavior of each application when a key is held, but in order to enable key repetition, I need to disable this setting ApplePressAndHoldEnabled.

In VSCode, I was able to disable the setting by running command in local terminal but I couldn't do the same thing in CodeSandbox so I turned off the global setting of ApplePressAndHoldEnabled once. (It is necesary to reboot your computer to apply the setting)

If there is any problem, you can turn it back on, so I have turned off the global setting as a workaround.

defaults write -g ApplePressAndHoldEnabled -bool true

I tried setting it up to target Chrome and it didn't work, so I guess I need a bit more additional settings to limit the scope.

This may not seem like much of a problem, but I hope you will be able to use it with caution since you will be changing the global settings.

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/

では。

Techpit さんから React Hooks に関する教材を執筆・リリースしました

Sat, 14 Nov 2020 00:00:00 GMT

突然ですがReact Hooks APIをゲームを作りながら学べる教材をTechpitさんより

「スネークゲーム🐍を作って学ぶ React Hooks API での状態管理」

をリリースさせて頂きました。

スネークゲーム 🐍 を作って学ぶ React Hooks API での状態管理

Techpitさんはサービスを作りながら学べるプログラミング学習教材をオンラインで販売している会社さんです。

この度、4月末頃から自身が運営しているブログ経由で連絡を頂き執筆させて頂けることとなりました。

他のフリーランスの仕事や学校の宿題などの合間を見ながらせこせこと作業し11月10日（火）に無事リリースができました。

教材執筆のきっかけ

執筆のきっかけはTechpitさん側から声かけを頂いたところが一番大きかったのですが、普段からMENTAなどのサービスでプログラミングについて教えていたりするところもあるので常日頃から自分の知識や経験を提供することで価値を提供できる機会があれば進んで参加したいと思っていたのでお話を頂いた時に「面白そう」ということで執筆を開始させて頂きました。

[ HTML/CSS, JavaScript, React, Redux ] フロントエンドエンジニアとして実務レベルの実力を身につけたい方をサポートします。 | MENTA

題材を「React Hooks API」「スネークゲーム」とさせて頂いたところについてはTechpitさんの担当者さんと相談しながら決めていったのですが、元ネタはこちらの記事で二年ほど前にReactの学習がてら面白そうだったのでスネークゲームを作って公開していました。

この記事の中にもあるようにちょうど海外のデベロッパーさんが実装しているのを見て面白そうで作って見たところ、自分でも実装していて案の定面白かったので記事にしてみたという流れです。

そこから月日がたちHooks APIも出始めてクラスコンポーネントで書かれたそのスネークゲームはすっかり古くなってしまい「そろそろアップデートしたいなぁ」とぼんやり考えていました。

そんなことを考えた矢先、教材執筆のお誘いがあったのでそこで「React Hooks API」と「スネークゲーム」というところが繋がり担当さんに提案をしてこれまでゲームのようなものを作った例がほとんどないということだったので作ると決めました。

教材を執筆してみて

教材はまだReactに追加されてから日の浅い（徐々に浸透していきてる感じもありますが）Hooks APIを解説するような教材になります。

下記のような懐かしのスネークゲームを作りながらHooks APIの使い方を学んでいきます。

一口にHooks APIといっても useState のようなステート（状態）を扱うフックから、useContextのようにステートをより広いスコープで扱うフックやuseEffectなどレンダリング間の副作用を扱うようなフックまで色々ありますが、この教材では

useState
useEffect
useCallback
useMemo

など普段よく使うフックを主に解説しています。

スネークがぬるぬる動いた瞬間の感動も捨てがたいものかとは思いますが、それと同時にスネークを動かすにはl小刻みにステートを変化させて、再レンダリングを起こしということをやるのでReactを理解する上で重要なステートとレンダリングについて学べる教材になっているかと思います。

わかりづらい部分にはイラストも入れて説明を加えたり、なるべく読者の方が理解しやすいように作っているつもりです。購入者の方が実際にどういったフィードバックをくれるかはドキドキなのですが、幸い教材リリース後に Techpitさんの社内で「わかりやすい」という評価も頂けたよなのでひとまずホッとしています。

肝心の執筆についてですが、当初一二ヶ月で終わるだろうと完全に舐め切っていました。

チュートリアルのコードと記事の文章の整合性を保ちながら書き進めたり、複雑な概念をテキストで説明することやそれをイラストで図示してあげたりという作業が思いのほか発生して、かなり大変でした。

普段自分で技術に関する文章を書く際はブログの記事を書くことが多いので、始めた当初はそれとあまり遠からずで慣れたものかと思っていました。

が、普段書く文章はある程度事前知識をもった人を想定して書いていたので今回はある程度広い範囲のレベルの人をカバーしながら文章を書いていくというのに苦労しました。

ここまで、とつとつと苦労ばかり書いていますがこれは決してわるいことでなく勉強になったと思っています。普段自分の書いた文章を自分で校閲して公開することはあっても人にレビューされながら商品として作り上げるというなことはなかったので非常に良い経験になったかと思います。

今後のブログや教材執筆の時にも役立つ経験かと思ったので本当にやってよかったと思っています。

最後に

この記事はお知らせが主体なのであまり長く書くつもりもないので、ここらで終わりにしようかと思います。

初の教材執筆とリリースということと、教材執筆がなかなか歯応えがあったので今のところ達成感に浸っていますが、もうすでに5~10本ほど教材を購入頂いているようです。購入して頂いた方ありがとうございます。

もし、教材を無事終えましたら各種SNSやブログ、サイトのレビューなどで感想を頂けると嬉しいです。Techpitさんの教材はUdemyなどと違いテキストベースのチュートリアルなので、フィードバックを受けて教材をブラッシュアップできたりなどできるので感想頂けると嬉しいです。

最後にまた繰り返しにはなりますが、興味ある方は是非下記リンクから教材の詳細ご確認お願いします。

スネークゲーム 🐍 を作って学ぶ React Hooks API での状態管理

では。

バンクーバーに来て三ヶ月たったので振り返り

Sat, 01 Feb 2020 00:00:00 GMT

最近このブログでは振り返ってばかりなのですが、前回のは年の振り返りだったので今回はバンクーバーに来てから3ヶ月たったのでとりあえずの振り返りを書いて行こうかなと思っています。

まだまだ何もかもも中途半端で何かできたことがあるわけでもないのですが、一つの区切りと今後の成長のための分析もかねて色々とまとめていこうかと思います。

バンクーバーの三ヶ月でやっていたこと

10月末にバンクーバーに来て1月もあっという間に終了し、3ヶ月の月日が経ちましたがその間にやっていたことをまとめると

ESLのクラスに二ヶ月通っていた
英語力のベンチマークとして初のIELTSを受験
年始からWebデベロップメントのコースを受講
フリーランスとして日本で受けていた仕事を時差に振り回されながらもなんとか継続
個人で開発しているデスクトップアプリをベータ版公開
初めてのqiitaアドベントカレンダー参加
バンクーバーでの家探し、一ヶ月で家を探して引越し
現地でのカナディアンラクロスを堪能

といった感じになります。

ぱっと見これらを見るとまぁ大体プログラミング、英語、バンクーバー生活的なテーマで区切れるのでそれぞれに分けて書いていきます。

英語について

渡航後に出会った英語勉強におすすめのYouToubeチャンネル

英語に関しては渡航後すぐにESLに通い始めて二ヶ月ほど年末までESLに通っていました。

授業の内容はそのクラスの英語のレベルによるのですが、僕のクラスではまぁテキストを主に使って文法事項とかとかを英語で説明されてテストしてみたいな流れで進んでいきました。

これだけ聞くといわゆる日本の英語のクラスと同じであまり意味ないじゃんという感じですが、合間合間にグループでのディスカッションやスピーチを自撮りするみたいなワークがありまぁ割と強制的に英語を話す環境におかれました。慣れの問題もあるとは思うのですが、個人的にはこの二ヶ月でだいぶ英語はましになったかなと思います。これまでオンライン英会話等で英語で会話することはあっても集団で会話したり雑談したりみたいな経験が少なかったのでそういった意味でも良い経験になったかなと思います。

とはいえ、英語の授業中は8割が話を聞いている感じなのでまぁ自習も欠かせないなと思い最初二ヶ月ほどはオンラインの英会話と組み合わせてなるべく英語を話せる時間をつくるように時間をさくのと、Youtubeで英語の勉強法的なものを隙間時間に見まくりなるほどこうやって勉強するのねみたいなを調べて実践したりていました。

色々動画をみた結果以下の三つの方のチャンネルが個人的にためになるな、と思いここで言っていることを日々意識しながら勉強しています。

ニック先生の英会話
英語が聞き取れるようになる　７つのポイント（Part 1）
Yumi's English Boot Camp
英語学習者必見！－永遠の中級者から抜け出すための３つの方法
英語発音専門ドクターDイングリッシュ
流暢な英語発音になる一番のコツは声を止めないこと

よく言われるのは英語で英語を覚えた方がよいなんて言われるので、英語ネイティブが教えている英語のチャンネルなんかも見たりしたのですが英語の勉強法に関しては日本語にフォーカスしている人の方が日本語と英語の違いを前提にはなしてくれるのですんなり腹落ちしやすい感じがしました。

ここに載せた三つの方のチャンネルは結構おすすめなのでもしよかったらチェックしてみてください。

初めてのIELTS受験

また、最近三ヶ月たったあとの英語力チェックの一貫としてIELTSを受けてきました。準備不足感は否めなかったですがまぁ最初のなのでこんなもんかなという感じです。今月中旬には結果がでるようなので楽しみです。

バンクーバーでうけると受験料が高いので、日本にいる方は日本で受けておいた方がよいかと思います。普通に300ドルとかして結構高いです。受験料高いのはネックですが試験みたいな英語のの力を定量的にはかれるものがないとちゃんと勉強しないのでまた三ヶ月後にIELTS受験しようと思います。なので次の受験は5月です。

肝心の英語力ですが個人的にはここ三ヶ月の伸びは満足していますが、これから就活して、英語で仕事したり、英語でストレスなく友達と話をしたり、英語の記事をスイスイ読めたりというレベルにはほど遠いので引き続きこの調子で英語力を強化できると良いと思います。

プログラミングについて

個人開発について

プログラミングについては引き続き日本といた頃と変わらず仕事でもプライベートでも好きでコードを書いているのですが、友達に勧められて、12月にqiitaのアドベントカレンダーに初めて参加してみました。

その時の記事はこちらです。

公開当初は結構な人が読んでくれたみたいで来年もまたやってみたいなと思います。

この記事でも書いたのですが、今は個人で開発しているデスクトップアプリをベータ版として公開しています。英語の勉強と仕事と就活で忙しいのですが、こっちの方も併せて進めていきたいななんて思っています。

アルゴリズムの勉強の必要性

年始から始まったwebデベロップメントのコースの方はと言えばまぁ授業の内容はだいたいわかるので内職をしたりしているのですが、こっちではやっぱりアルゴリズムの部分がかなり重要になるようなので重点的に勉強していく必要はありそうです。

先生にそこらへんのことを質問しみると **「こっちのある程度の規模の会社になると自分たちでライブラリを持っているのでそれを理解したり、新たに自分たちのライブラリを作れないと困る。なのでアルゴリズムの勉強が必要」**という話を聞いてハラ落ちしました。

こちらの企業でもスタートアップではなるべく早くプロダクトを作ったり機能を追加したりするのが重要なので、既存のライブラリを問題なく使えるのが大事で面接でもコード面接というよりもペアプログラミングで模擬的な機能を実装してもらうみたいな形をとっているそうです。

この話は今のところバンクーバーにきて一番印象的なことですが、これまであまりやってこなかったアルゴリズムについて重点的に強化する必要あがりそうです。

まぁ就活のためというのもそうなのですが、自分が今後書くコードやコードレビューのために役にも立ちそうなのでこれからしっかり勉強していきたいなと思います。

バンクーバー生活について

雑感

バンクーバー生活については結構満足しています。冬場ほとんど雨で天気が悪いのとバンクーバーの家賃が高いのが気に入らないですがそれ以外はおおむね満足しています。

スノボーをしたいと思えば小一時間でスキー場までもいけるし、自分が学生の時にやっていたラクロスも十分に楽しめて自分の好きなものが揃っていて今のところ全然不満がないです。長く住んでるとマンネリ化してきて文句言いたくなったりするのかもしれませんが、まぁ今のところ自分の好きなことができているので満足です。

バンクーバー到着当初は、ホームステイをしていたのですが幸運なことに一ヶ月で物件を決めて無事引っ越すことができました。人によってはホームステイ先がすごくよくて急いで引っ越す必要もないというひとがいるようなのですが自分はそうではなかったので、早めに動いてなる早で物件を探して引越し先を決めました。

物件探しは物件のオーナーや不動産会社の喋る英語がわからなくて辛い思いもしましたが、まぁそこはメールで詳細は確認したりしてなんとか乗り切りました。カナダに行ってすぐになんの苦労もなくコミュニケーションをとるのはまぁ多くの人には不可能なのでとりあえずアポイントメントだけ入れてなんとかやり切るようにしていけばとりあえず物事は進むのかなと思います。

ラクロスについて

またまた、こっちにきて学生の頃やっていたラクロスですがバンクーバーに来る当初は**「プレイできるチャンスがあればやりたいな」くらいでバンクーバーにきたのですが縁あってこっちでガッツリラクロスしている友達に出会えたので, 実際にステジアムに行ってプロラクロスリーグの NNLも観戦しますし、実際に自分でもプレイしてバンクーバーでのラクロスを堪能しています。ラクロス自体も十分に面白いのでそれだけで満足なのですが、こういった趣味があるとなかなか接点のもてないネイティブのカナディアンとも接点ももてる**ので何か自分が一つ好きな趣味があったりするのであればそれを通じてバンクーバーで色々な人と繋がるというのはかなり有効な手段なのかもしれないですね。

まとめ

以上、これまでのバンクーバーでの三ヶ月を振り返ってみました。

三ヶ月ごとにできれば振り返りたいですがまぁ特に書くこともなければ書かないかもしれません。というか書けるように刺激的なインプットがあるような行動を心がけたいですね。

まとまりのない文章だったのでとくに綺麗なまとめもできないので、興味ある部分だけ読んでいただけると嬉しいです。

では。

2019年。フリーランス二年目の振り返り

Wed, 01 Jan 2020 00:00:00 GMT

大晦日は家で今やってる個人開発のプロジェクトのコードと闘う、我ながらエンジニアの鑑みたいな過ごし方をしていたのですが、ひとまず無事年明けを迎えることができました。昨年はお世話になりました。本年もよろしくお願いします。

今年は日本からバンクーバーに拠点を移した大きな転換の年となりましたが、カナダ移住というトピックからすると昨年は準備の年だったので、年が明けてようやく本番といった感じです。まぁあまり気負わず粛々とことを進めて行ければよいなぁなんて考えております。

去年も一つの区切りとして、振り返りを書いていたので今年も書いていこうかなと思います。

2018年の振り返りを受けた雑感

昨年の振り返りの記事はこちらになります。

2018年。フリーランス一年やってみての振り返り。

売上のはなし

記事では売上に言及していますが、多分年間を通した売上は今年と同じくらいなのかなという感じです。クライアントワークでは裁量が増えて単価があがったのですが、年始はあまり稼働していなかったのとカナダ移住で稼働が減ったのが要因でだいたい同じくらいでクローズという感じですね。

フリーランスとして気になる単価ですが、一昨年の最初の単価に比べて二倍以上になっているので自分をほめてあげたいです。エンジニアとしてはそれなりの単価を頂いているので、それに見合ったパフォーマンスをできるように引き続き精進していきたいです。

技術のはなし

フロントのはなし

今年は春先から、React Nativeでのフルスクラッチのアプリ開発からリリースまでを経験できたので、その中での知見が溜まってよかったです。 2018年もReact Nativeの開発はあったのですが、エンジニアとしてのポジションが高くなかったのとすでにリリース済みのプロダクトだったのでデプロイ周りやライブラリ選択、アーキテクチャ設計みたいなところができて良い経験になりました。

サーバのはなし

Railsも引き続き触っており、今年はRailsの新たな魅力を発見できた気がします。定期的に死んだと言われたり、他言語からきたひとから「設定より規約」という思想の暗黙的なコードに慣れないと言われたりするRailsですが、デファクトスタンダートの安定やORM, テストライブラリ、フィクスチャ、シードなど質を保ちながら高速に開発する環境が揃っているので一度入り込んでしまうとかなりストレスレスに開発ができます。

個人プロジェクトでGoを書いてみたり、Expressを触ったりすることもあるのですが、テスト環境の構築・設計等々の作業が都度発生するので、ゼロからプロダクトを作ってテストコードある状態で改善のサイクルに乗せるまでがRailsに比べて相当大変な気がします。

アーキテクチャ自体もシンプルなMVCでテストの環境も整っているので、お作法を守りながら開発していけば初心者の入りのWAFとしては結構良いのかななんて思っています。

話は変わって、Goについてですが、久しぶりに静的型付け言語を使っているのでRubyやJavaScriptとはまた違った思想があって、それらを知るのがまた面白いです。Goの学びと平行で個人開発を進めているので若干ブレーキになっている感はいなめないのですが、まぁ学びへの投資として今は辛抱強くやっていこうかなと思っています。

2020年のテーマのはなし

2020年はそろそろ言語的な専門でなく技術分野としての専門性を伸ばしていきたいなぁなんて思っています。今まではサーバのコードも書くし、フロントのコードも書くという感じでやらしてもらっていたのですが、経験的にそこまで多くのトラフィックを捌くコードを変えていたりしていたわけではないのでフロントを強めるのが良いのかなぁなんて思っていたのですが、色々と考えるとDevOpsあたりが自分にあっているのかなという結論に至りました。

今年の仕事でCircleCIを使ってデプロイの自動化を行ったりしたのですが、デプロイの仕組みが開発チームのワークフローやリリースまでの仕組みや製品の質を決める部分が多くビジネスとの接点が大きく、開発者へのインパクトも大きいなと感じました。

エンジニアとして、開発を請け負っているからには、要求された製品の質を担保しながら素早いサイクルで製品を作っていくのが仕事だと思っているので、個人的な課題感とマッチするかなと思います。

ということで、2020年はDevOpsあたりのところを重点的にやっていきたいです。

とは言っていますが、デザインの部分だったりUI・UXの部分も好きなのでそっちもやっていきたく迷う部分もあるんで、シナジーはないかもしれないですが、

「フロントの部分を全体的に強化しつつ、サーバ・インフラの部分はDevOpsを中心にやっていく」

というのがイマイチ腑に落ちないですが、2020年の自分のテーマになるかと思っています。フロントの部分のテーマの解像度を上げていく必要性は感じていますがこれは2020年通してやっていきます。

2019年の個人的ニュース

カナダに移住しました

経緯はこの記事にも書いたのですが、フリーランス業(エンジニアとしての)の飽和と将来的な成長等々を念頭にカナダ(バンクーバー)移住を決めました。

フリーランスを退職します。カナダ行きます。

カナダでの直近の目標はざっくり言うとカナダ現地就職となるのですが、

英語圏のエンジニアと議論したり、関係性を作れる英語力の獲得
英語圏での仕事の実績
バンクーバースタートアップの文化や仕事の仕方を体感する

あたりが今回の移住の目的になっいてます。

これらの経験を通して**「世界的なフィールドで戦える能力を育てる」**というのが裏テーマになっています。こうやって書くと格好付けてるように聞こえますが端的に言うと「これだけネットが発達して誰とでも仕事できたり友達になれたりするのに、日本でしか生活したことないのもったいなくない？」という素朴な疑問が元になってます。

そうはいっても、「日本は治安・サービスも良くて住みやすいし、日本語通じるしなんでわざわざ？」という人もいるかもしれませんが、これは単純な自分の興味なのでそこを体験してみたいなと考えてます。

すでに海外で生活されてる方からするとなんでわざわざ住みづらい所にリスクを負って来るのかわからないかもしれませんが、日本でしか生活したことない人の中にはこういう考えの人もいるよってわかってもらえれば良いかと思います。

こっちでの暮らしぶりとか感じたことも記事にできると思うので、おりをみて投稿していければなと思います。

個人開発のアプリをベータリリースしました

念願の個人開発アプリをベータリリースしました。

PaPyrus

優れたメモアプリは数あれどマークダウンでちょろっとかける裏紙のような気軽なメモアプリが欲しかったのでつくりました。

機能も限られていて全然まだまだなのですが、一応体裁は整えています。学校行ったり、仕事したり、勉強したりでなかなか進められていないのですが、こないだちょっと見に行ってみると1人だけユーザさんが登録してくれていたので、ちょっと感動しました。

使ってもらえてるかはわからないのですが、これから改善を重ねればそれなりに使ってもらえるのではという自信があるのでなんとか時間を捻出して正式リリースまで持っていきたいです。

今年はせっかくアプリを作ったので、個人開発アドベントカレンダーにも記事を書いてみたのですが、公開当日は100PVくらいまでいったので、書いてみるもんだなぁと感じたと同時にもうちょっと回遊させたり等々色々準備できたなという反省もあります。

デザイン実務経験ゼロのエンジニアが個人サービスでのアイコンの作り方を考える

来年はもっと色々なアドベントカレンダー書いたら楽しそうだなぁなんて思ってます。

月間のPVが最高で6000PVを記録しました

この記事を書いていても、カナダ移住とか、個人開発とかとかのトピックで書けることはたくさんあることに気づきましたが、今年は、一応節目としてブログの**月間PVが6000を超えました。**最高瞬間風速なので平均は5000弱でしたが、昨年に比べて1.5倍ほどPVを伸ばすことができました。

1万PVいきたいなと思っているので、今年もちょこちょこ更新しきたいと思います。

まとめ

ということで、色々と書きましたが2020年もやりたいことがたくさんある年になりそうです。

本編ではあまり書きませんでしたが、就職活動と英語の語学力アップは結構切実な問題としてあります笑。就職先のリストアップとか業界の情報収集等々やることたくさんある気がするのですが、まぁそれらはこれからやるとして、最近自分の頭にあることを棚卸ししておきました。

今年もまぁ色々とあると思うので都度記事にしていきたいと思います。本年もよろしくお願いします！

では。

How do you design icon in your private project?

Fri, 06 Dec 2019 00:00:00 GMT

Recently, I released my private project application for beta version.

I have been working as web developer for 5 years in some companies and I am web developer. However, I will not talk about programming in this article but how to design icon in your private project.

I am going to write about programing in other articles someday.

Introduction

Self Introduction

As I said, I am web developer not designer. I mainly use Rails and React. At the beginning of my web developer carrer, I started to work as server side developer and generally I get interested in front end technology and React. Finally, I also use React Native these days.

Besides, actually I am developing an memo application. The name is "Papyrus".

PaPyrus

It is released as beta version.

I already have released my some applications until now, but I couldn't make my application's logos be cool. I don't know why. I could never design it as I expected.

However, finally, I could finish the karma, thanks to my designer friend. I have a confident of the current icon for my application. (I will show you the icon below) I ask him how I should desing apllication's logo and he gave me some advices. I can't say that if you follow this process, you can definetly create cool icon though, you'll come to be able to do better by the process I organized.

What's Papyrus?

Papyrus is memo application which run on Mac OS and it is implemented by Electron.

There are some memo application in the world, but it usually has a feature to organize your notes.

It's overspec for me because I'm lazy. Those memo apps are better way to write down but I 'm too lazy to handle it.

I usually use such applications' draft for my blog but I needed a memo application like flyer on purpose of writing down my idea or command temporally.

That is why I created Papyrus. Beta version is released now and that is developing. If you download and use it, I'm going to feel happy. Besides, giving me feedback is going to make me be happy.

Applications such as Inkdrop, Boostnote and Evernote are too great,

Jet down your Todo list
Memoize your command it's hard to remember
Draft message you are sending
Copy a part of logs

These are Papyrus's usecase. It is going to fit these kind of short-lifespan memo.

Papyrus's Icon

Without further ado, I will talk about icon. I designed and implemented in PaPyrus by myself and of course, I designed icon as well.

This is the icon:

How do you think about this icon?

I have ever run some private web services though, my icons I designed before were too ugly to show others. Compared to them, this is cooler and This one is the best icon I have ever made. Besides, I got to sort of understand how to design an icon for application so I decided to verbalize.

How to make icon in your private project

For making PaPyrus icon, I wanted to make cool log match with application designe so I need some advice from designer and I asked a designer I know about it.

I summarized the advices and tips I googled as follows:

Select an basic object associating with application
Sketch object
Abstract the sketch
Give the abstact sketch the finishing touch

Select an basic object associating with application

This idea is from result I googled and I did trial and error though. First of all, You get to choose a basic object assocating with your application.

This time, PaPyrus has a image of paper literaly so I decided the object is "paper".

Evernote log is an elephant and it has a part fliping page on upper left of it. Thus, Evernote's logo associate with "elephant" + "paper". That of Apple is "apple" and Sketch applies something like "diamond" for its symbol.

In this way, you have to pick up an object for your project at first. It is intersting to select multiple objects as Evernote do ( "elephant" + "paper"). However, it is harder for beginner or developer who are not familier with designing logo to do that.

Anyway, if you want to choose more than two motif, I recommend you sketch each motif and combine with them in post process.

Sketch the object

This is most impressive advice I recieved from the designer. He said

"Don't open Illustlator at first. Sketch first."

As he said, I have made not good icon by starting from using Illustlator...

Then, I thought I started from sketching, but I have never doing since I was high school student. However, You can't tell unless you try. I tried to draw my hand.

I have no idea about sketching so I sketched while I watching a vide on YouToube.

However, at that time, An idea come up with in my mind.

" How can I make good icon through this process???"

I asked him to give me some advices about that with such a anxiety. And then, He said the purpose of sketching is "polishing observing skill"

Certainly, you can't draw in detail while you are sketching if you originally recognize those differences. (You can't illustlate well, if you copy an incorrect image with a paper.)

After I understand this point, I did trace some icons and sketching in order to understand how cool icon is drawn.

How about? I rolled the paper because I wanted to express the texture of paper. Now, it seems like harder for a paper, but this goal is not to sketch it well so it's OK. For me, this sketch was enough and I maked icon base on this sketch.

Besides, Following is too terrible sketch to continue..

What is this? This is like spring roll. I was not going to draw it! Anyway, let's enjoy the process with failure.

Abstract the sketch

Next, you abstract the sketch you drew and it approaching to icon. Until this, I sketch it with Procreate so I keep on illustrating with it.

First, this is a first idea.

This image is colored but I recommend you draw only outline of then abstracted icon with lines and add colors to it after that. I emphasized the looks rolling up the paper while I was abstracting.

I thought icon was getting better, but it was a little bit too artisitc. That was why I gave it finishing touch by using Papyrus's imaging color.

Give the abstact sketch the finishing touch

If you can make icon you are satisfied, you can skip this process. However, I needed to organize it with Illustlator.

This is final version.

I wanted to compated between some sort of version so I made difference patterns' icons. Finally, I picked up upper left one. I liked black one though, it's far from application theme so I didn't choose.

Done!

When you finished, export your favourite icon. As for now, I show you icons of before and after.

Final version was daramaticaly changed from the original version I sketched thouhgh, you would be able to clear your image about icon if you sketched before that.

Wrap Up

This is way I din't write about programming at all though, I'm glad if this article help your project and process of designing icon.

Papyrus is implemented by some interesting technologies such as React, TypeScript, Electron, Go and GraphQL. So, I'm going to write arrticles on the theme of them some time.

Thank you!

デザイン実務経験ゼロのエンジニアが個人開発でのアイコンの作り方を考える

Fri, 06 Dec 2019 00:00:00 GMT

こちらは個人開発 Advent Calendar 2019の16日目の投稿になります。

個人開発とのことで技術的なところを書く方がほとんどかと思うので私の方では、個人サービスを作る時のアイコンの作り方について書いて行きます。

はじめに

自己紹介

私自身デザイナーの経験があったりするわけではなく、最初はRailsから始まり、徐々にReactも触るようになり、結果的にフルスタックっぽい形でサーバからフロント、React Nativeなどを触りながらフリーランスとしてお仕事させて頂いています。

またその傍ら

PaPyrus

という個人アプリを開発しています。

こちらのアプリを作るまでにもいくつか自分でサービスを作って公開してみたことがあるのですが、やっぱり機能の実装に手が回らないのと、そもそもデザインの基礎的なところがかけていたりして、どうもいい感じのイケてるアイコンを作ることができませんでした。

ただ、今回のサービスは個人的に知り合いのデザイナーさんのアドバイスを元に「いい感じのアイコンができた！」という手応えがあったので、アイコンを作るまでのプロセスについてまとめていこうと思います。この手順さえ守れば誰でも思い通りのアイコンが作れる！というものではないですが、他で個人開発をされる方の参考になればという形です。

PaPyrusについて

現在開発中のPaPyrusはElectronで開発されたMac上で動作する(今のところMacでしか動作確認できていません）マークダウンメモアプリです。

メモアプリというと「ノートを整理」する機能がついているものが普通かと思うのですが、ズボラな私は

「ノートを書くのは良いもののノートが整理できない」

という問題に頭を抱えていました。

ブログの下書きのようなものはEvernoteやInkdrop, Boostnoteなどなど世にある優秀なメモアプリで十分対応できるのですが、

その日のタスクリストを書き連ねる
長いコマンドをコピペしてのこしておく
メッセージの下書き
ログの一部をコピペ

などなど、寿命の短いメモをこれらのメモアプリに残すとたちまちゴミノートが溜まっていってしまうので、これらのメモアプリとは別に自分には、

「落書きをしたりアイデアをまとめる裏紙」

みたいなアプリが必要でした。

これに一番近いアプリがMacのstickiesで、しばらくこれをつかっていたのですがstickiesはマークダウンが使えないので、

「ちょっと機能を足したアプリが欲しい・・・」

ということでstickiesにマークダウンを足した付箋型メモアプリを作りました。

ベータ版を公開中で会員登録をして頂ければアプリをダウンロードして使って頂けます。まだまだ改善の余地の多いアプリですが、興味あれば触っていただけると嬉しいです。

PaPyrusのアイコン

前をきはこれぐらいにして、早速アイコンの話に移ります。 PaPyrusはデザインも実装も自分でやっているのですが、もちろんアイコンも自分がデザインしました。そんなPaPyrusのアイコンはこちらです。

どうですかね？

これまでに数件個人サービスのようなものを作ってみたことがあるのですが、アイコンがどうしてもみていられないほどダサくなってしまっていました。そんな中で、今回のPaPyrusのアイコンは個人的にベストな出来だったのと、「アイコンってこうやって作るのね」みたいな部分がぼんやり見えたので、ここで言語化しておくことにしました。

個人サービスのアイコンの作り方

今回はPaPyrusのアイコンを作るにあたり、アプリのデザインに見合ったカッコいいロゴを作りたいということで、知り合いのデザイナーさんにアイコンの作り方を相談しました。そのアドバイス+一部ググった内容+をまとめると下記のような手順になります。

アイコンの元になる対象物を決める
対象物をスケッチ
スケッチを抽象化
抽象化したスケッチをもとに清書

アイコンの元になる対象物を決める

これはほぼ、ググった内容と試行錯誤の結果から考えついたものですが、まずはじめにサービスの元となるイメージから対象となる物を決めます。

今回のPaPyrusは、名前の通り「ペーパー（紙）」のイメージがあったのでアイコンにする対象物は、

「紙」

にしました。

Evernoteのロゴはゾウさんのイメージがありますが、左上の部分に紙をめくったようなパーツがあるので「象+紙」をロゴにしていますし、 Appleは実直に「りんご」を書いていますし、Sketchはなんでかわからないですが、「ダイアモンドっぽいもの」を書いていますね。 Slackのロゴは何をイメージして書かれているのかわからないですが今のアイコンは花っぽいですし、初期の頃は「シャープ」を抽象化しているようにみえます。

このようにして最初の工程はどういった物体を元にアイコンを作るのかと決めるというものです。 Evertnoteのように、「象+紙」みたいにモチーフを複数決めて組み合わせるのも面白そうですが、慣れないうちは一つにきめてやるのがよいでしょう。いずれにせよ、モチーフを二つ以上にする場合は、後の工程でひとつずつ物体をスケッチするとそれぞれを組み合わせる時にアイディアのイメージがつきやすいように思います。

対象物をスケッチ

ここが前述のデザイナーさんに聞いて一番驚い部分なのですが、デザイナーさん曰く

「アイコンを作るときはイラレとかを先に開くのではなく、まずスケッチからですね」

そういえば確かに、これまではアイコンを作るためにいきなりイラレで書いて細部が書ききれずイマイチなものになっていた。。

スケッチなんて、高校の時の美術の時間にやった時以来くらいなので何から初めてよいのかわからなかったのですが、ものは試しようなのでとりあえず、スケッチってどんなものだっけという感じで定番の手のスケッチを書いてみました。

スケッチのやり方なんてわからないので文明の利器に頼って、Youtubeでスケッチのやり方をみたりしながらスケッチしてみました。

しかし、この手のスケッチを終えてみたところで疑問がわきます。

「これで良いアイコンができるのか？」

そんな不安を抱えながら、また別の機会にデザイナーさんにスケッチのやり方や意識する点を聞いてみたのですが、

スケッチを行う目的は観察力を磨くためらしいです。

なるほど手をスケッチしている時も、手がどういう形なのか光の当たり方がどういう感じなのかということのを感じとれないとどうもうまく書くことができません。(物体を紙に写している時のイメージが間違っていたら、そりゃうまくかけないですよね。)

このことがわかってから、そもそもイケてるアイコンがどうやって書かれているかを理解するため、アイコンをトレースしてみたり、スケッチしてみたりしました。

ある程度経験値が溜まったところでいよいよ前工程で選んだ「紙」を書いてみようといことで書いてみました。

どうでしょう？紙感を出すためにちょっと巻いてみました。今見ると紙にしては、ちょっと固そうですが、今回はうまくスケッチすることが目的ではないのでまぁいいでしょう。自分なりに合格点だったのでこれをもとに次工程で抽象化させてアイコンを作っていきます。

ちなみに、最初に紙を書いた時に自分の下手さに辟易して途中でやめてしまったものがこちらです。

なんですかねこれ笑。紙感より春巻き感の方が強く出てしまっています。まぁこんな感じで失敗もしつつ、工程を楽しんでやれると良いかと思います。笑

スケッチを抽象化

次の工程では先ほどのスケッチを抽象化して、アイコンに近づけていきます。これまでのスケッチはiPadアプリのProcreateを使って書いていたので、引き続きProcreateで作業していきます。

最初の案がこちらです。

これは色ついてしまっているのですが、最初は線だけ書く感じで抽象化されたものを書いてその後に必要な色を足していきました。抽象化する時には巻いている感じを強くデフォルメして書いていきました。

これでアイコンのイメージはだいぶかたまってきたのですが、色の感じがアーティスティックすぎたので、 Papyrusのイメージカラーを使ってまとめていきました。

ここまでで大分イメージついてきたのですが、線がずれていたりするので微修正はイラレでやっていくことにしました。

清書

前段階できっちりアイコンとして使えるものができてしまえばそのままで良いのですが、僕の場合はイラレで清書しました。

これが最終的に清書したものです。

色々な色で試してみたかったので、何パターンか用意して最終的に一番しっくりする左上のものをアイコンに採用するよう決めました。

黒も個人的には渋くて好きなのですが、ちょっとアプリのイメージとかけ離れているこちらの採用は見送りました。

完成

清書がおわったら気に入ったアイコンを書き出して完了です。最後にスケッチしたものと最終版を並べて載せておきます。

スケッチしたものと最終的なアイコンのところで大分イメージが変わっていますが、元のスケッチをやっておくと抽象化やデフォルメをする時のアイデアの土台や出発地点が明確になるので一度試してみていただけると良いと思います。

逆に日頃落書きしたりしてある程度日常のものをささっとかけてしまう人は事前にスケッチしたりする必要もないのかもしれません。

さいごに

というわけで、プログラミング的要素ゼロの内容になりましたが、この記事が個人開発の手助けになれれば嬉しいです。

PaPyrus自体、React、TypeScript、Electron、Go、GraphQLを使っていて技術的なトピックでも記事がかけそうな技術を使っているので、そちらについてもおいおい記事がかければなと思います。

では。

フリーランスを退職します。カナダ行きます。

Sat, 26 Oct 2019 00:00:00 GMT

フリーランスを退職します。というタイトルで書き出し始めましたが、知っての通りフリーランスに退職はありません。

一つの区切りとして、退職エントリみたいなものを書いてみたかったのですが、どこかの会社に属しているわけもなく退職もできないのでこういった形で無理やり退職エントリっぽい感じで書いてみることとしました。

で、何するの？

一言でいうと、カナダでの転職を目指してしばらくカナダで生活します。当面はカナダの学生として勉強しながら、就職先を探します。

冒頭フリーランスやめますと書きましたが、実際のところでいうと学生ビザでもある程度の仕事はできるので日本の仕事をある程度行いつつ学生として学校にも通うなんて感じです。

なんで？カナダ？

そろそろ30歳がみえてきてこれからどうしようかなぁって考えた場合にまぁ一度しかない人生ずっーと日本で生活して、仕事してというのがどうも勿体無く感じたというのがありなんとなく海外で働いてみたいな。っていうのがあったのと

やっぱりエンジニアとして英語ができるというメリットがでかいと思ったので、英語圏の企業に就職してガッツリ英語でのコミュニケーション力を磨いたり、むこうの仕事の進め方みたいなのを体感として知りたいなと思ったからです。

カナダじゃなきゃダメというわけではないのですが、英語圏のエンジニアがどういう仕事をしているかというのが知りたかったので、そんなかでビザのとりやすさとか前例があるとかとかでカナダに決めました。

今回のカナダ渡航がうまくいけば、そのあとアメリカやドイツなどなど他の面白そうな国で働くという選択肢や日本とカナダ半々での生活などなど選択肢ができて広がりそうだったので、日本で単価や売上の上げ下げに執心しながら長くフリーランスとして働くよりは色々と面白い事ができそうだと思い決断しました。

これまでのこと

このブログは2年くらい(正確なところはあまりわからない)運営してきて、一定程度読んでくれる人も増えてきましたがまぁ多くは初めて訪れる方が大半かと思います。

そういった方のためにちょっとした紹介をしておくともともと文系の四年生大学を出て体育会とかやってたのですが、急にプログラミングに興味を持ちSIerを経てWebエンジニアとなり、フリーランスとなりという感じでやってきました。

一社目でのSIerでは、プログラミングがしたかったのにご多聞に漏れずエクセルメインのお仕事だったので、すきをみてはVBAでマクロ組んだり、なんとかJavaでのパッケージの開発プロジェクトに入り込んだりしていたのですが、海外で働くのがその会社でできる一番楽しそうなことだったので、一年目から希望を出し続けていたら二年目で実現しそうになりました。

が、インドネシア駐在のプレ期間に社長に「お前の希望でいかせてやるんだからごちゃごちゃ言うな」的な事を言われ愛想を、つかして退職し、

二社目では、Webエンジニアとして就職できた事業会社では、元々いたエンジニアが全て辞めており、ビジネス側の人に「このシステムどうやって使うんですかー？」と自分のメンテナンスするシステムの使い方を聞き回りながらなんとか仕事を回していました。

事業会社で働かれれいたエンジニアの方ならわかってくれるとは思うのですが、もともとITじゃない会社のエンジニアをやっているとシステムの修正依頼の進め方がめちゃくちゃだったり、エンジニアにPCのセットアップ頼んだりとかよくわからない雑務までエンジニアチームで吸収する感じで仕事が多く効率もよくないので毎日遅くまで残業して、だいたい残業80時間くらいやっているのが日常的に続いていました。

技術自体もレガシーでちょっとこのままやっているとヤバイなというのは感じながら仕事をしているとふと、

「年収400万ちょいで働いてるってことは自分の人生の価値が400万ってこと？」

ということに疑問を抱き働き方や年収を選べるフリーランスになることをきめました。

幸運にも友人のエージェントの紹介で入り込めた最初の現場が良く、最近のトレンドにのった開発というものに触れ、フリーランスとしても直接仕事が取れるようになり、だんだんと短歌も上がりこんな感じでリモートしながら働けるようになりました。

20代を振り返って

まだまだ20代ではあるのですが、もう30歳もすぐそこなので20代についてぼーっと考えることが増えてきているのですが、20代をひとことで言うと

「生活に対する日本社会の一般通念からの脱却」

をしてたのかなぁ。なんて思います。

時代は変わったといえど、まだまだやっぱり日本には

仕事に大切なのは我慢
職場は当たり前のように通勤電車に揺られてやったことさたどり着くオフィス
この職種でこの年代だといくらくらいの年収が相場
貯金が大事
長期休みはお盆か、正月
働く時間は9時〜17時、週5日勤務

という色々な枠があります。

フリーランスは学生の頃からなりたいと思っていた(さっきはふと思いついたかのように書きましたがぼんやりと学生の頃から憧れてました）のですが、フリーランスにはこういったしがらみから解放されていて仕事、仕事場、働く時間、報酬、住む地域などが自由なイメージがあり、ここに惹かれて、これらのしがらみから自由になるために必死こいて色々と行動してきたのかなぁと思ってます。

当然フリーランスなので、能力が低かったり、十分な価値を発揮できてないと会社員以上に不自由になることはあり得るのかもしれませんが、フリーランスの方が良くも悪くもチャンスがあるというのが適当かと思います。

そうして頑張ってきた結果、今今の短期的な評価でいうと、仕事自体は自分の好きなプログラミング・Web開発を仕事にできてますし、仕事場は基本リモート(だいたい家でやってるけど)、仕事の時間も自由、報酬もありがたいことに会社員時代の倍以上という結果で良い20代を過ごせたと思ってます。

さらなる自由へ

ということでひたすら自由を追い求めてきた僕なのですが、まだまだ不自由なこともたくさんあります。

金銭的な不自由でいうとやはりまだまだ単価×稼働時間＝収入の式から抜け出せず、一定程度の時間拘束されるので行動が制限されます。

さらに、言語的な不自由も常日頃感じており、フリーランスが自由といっても小さな島国の中だけで

英語で書かれた情報を日本語に訳された情報を元に行動して(英語のドキュメントと読みますが理解スピードが速いのは圧倒的に日本語)
読み手が多いはずの英語でブログを書いてない
国内の中にしかコネクションがない

といった所に不満があります。

その他まだまだしがらみはありますが今回のカナダ渡航ではこの言語的(地理的)障壁を自分からなくすことができればさらに自由になれるのかなと思ってます。

そのために、カナダでは現地の企業に所属して英語でコミュニケーションをとり、日本で行っていたのと同レベル以上の仕事ができればここがクリアになるんじゃないかと思って今回の決断に踏み切りました。

フリーランスエンジニアとして感じた閉塞感

ここまでだと割とポジティブな事しか話してない感じがあるので、リアルな話としてフリーランスとして2年程度やってきて、閉塞感やけん怠感を感じていたのも事実なのでそこについても触れておきます。

フリーランスを二年やって感じた負の部分はまとめるとこれら三つになります。

フリーランスの立場が弱い
普通に仕事があれば、ボラティリティの少ない安定した日々
将来的な市場価値の停滞の可能性

立場が弱い

普通に仕事している分にはあまり不満はないし、職場内での説得力の持たせ方みたいなものは個人でなんとかする範囲だと思うので良いのですが、フリーランスとなるとやっぱり商流の下の方に位置せざるをえず、普通に仕事をしていると「そもそも何をつくるのか？」みたいな部分にあまり影響を与えることができません。

自分のいない会議で決まってしまうことをなんとか覆そうとかなると結構な労力が必要で、自分の納得のいくもの（チームにとって良いアウトプット）を作り込めるかというとやっぱり難しかったりします。ちゃんとサービスを作り込みたいなら、長期間現場にいてとなると思うのですが、そうすると「正社員でよくない？」となります。

仕事面での立場の弱さもありますが客観的に見て、フリーランスを一企業としてみると売り上げよくて1000万円程度の超零細企業です。

フリーランスが自由であるのは、その労働形態的に自由という側面もある一方、膨大な企業があるなかでほうっておいてもそこまで問題ない規模の企業だからほっておかれているという側面もある気がしており、

契約先の経営状況が悪くなったり、業界全体として開発費が削減された場合に削減の対象となるのは業務委託で契約している人たちにるかと思うので総合的に立場が弱いなというのはフリーランスやりながら常に考えてはいました。

ボラティリティの少ない安定した日々

なにも乱降下の激しいジェットコースターのような日々を送りたいわけではないのですが、今のエンジニア市場だと需要がかなりあるので一定程度のスキルがあって現場常駐も気にならなければ普通に会社員以上の収入で技術書やサーバ代は経費計上という感じでそこそこ良い暮らしはできてしまいます。

納品ベースの契約をしていたりするとこれからは外れそうですが、月の稼働ベースで契約をしていると本当に会社員と変わらない感じで安定した日々を送ることができます。

あとにも書きますが、やっぱりゆったり過ごして変化もないと劇的なスキルの変化もないので、年をとるにつれて収入が停滞・低下したり、仕事がとれなくなってくるリスクがでかそうで、自分としては何かしなきゃという焦りはありました。

将来的な市場価値の停滞の可能性

世間的なながれもあいまって今後フリーランスが増えていくなかで、自分をどう差別化するか考えると今の感じで普通に開発を続けていてもあまり良い未来は見えそうにありませんでした。

エンジニアの需要は今後常にあり続けそうですが、5年、10年先の日本経済の停滞等々のリスクを考えた時にこのままの仕事を続けていて大丈夫かなという不安が常にありました。今は幸い20代でバリバリ働けるので良いのですが、自分が30代、40代になった時には当然労働力的魅力は落ちるので「はて、どうしたものか？」というのはありました。

こうやって書くとこれからフリーランスを目指す人にを脅かすようになってしまうかもしれませんが、短期的な3年程度であればこれらのデメリットはあまり気にならないのでやりたい人はどんどんフリーランスに挑戦してみれば良いと思っています。

ただ、**「会社員時代の何倍の収入！」「自由な働き方！」**みたいなのに気を取られすぎて長期的な視点を失うと３０、４０代で苦しいかなというのが自分の見立てなのでそれを踏まえてフリーランスに挑戦してみると良いと思います。

色々書きましたがしばらくカナダで生活します。

ということで、更なる自由とフリーランスとしての閉塞感打破のために暫くカナダで生活します。

カナダで学校に通いながら、仕事を探すので肩書きは学生ですが空いた時間でこれまで通りフリーランスの仕事もします。

「フリーランス辞めてないじゃん」と言われればその通りなのですが一つの区切りとして、2年のフリーランス生活を終えてさらにステップアップしたいということで今回の記事を書きました。

フリーランスの次のステップとして

起業する
会社員に戻る
専門性を尖らせる
組織化する

等々あるかと思いますがこのどれも自分としてはイマイチな選択だったので、20代当初からあった海外で働くという目標に一旦コミットするということにします。

この目標は達成した後の拡張性も高そうだし、過程も山あり谷ありで楽しめそうなのでひとまず1,2年スパンでの目標達成を目処にやれることをやっていきたいなと思います。個人的には今まではサラリーマンよりのフリーランスだったので、フリーランスはフリーランスでもさらに上のステージに立てるようなフリーランスになっていきたいなと思っています。

まとめ

カナダに行く途中の機内で記事を書き上げましたが、結構な分量になりました。

色々と書きましたが結局のところ面白そうだからとりあえずやってみるという所がまぁ大半かなという所です。

収入の話とか、仕事の話とか色々ありますがまぁ一度の人生日本だけで終わるのもったいないよねという所があるのでとりあえずチャレンジしてみます。

この記事も書きっぱなしは良くないので、定期的な進捗報告やお得な情報等々書いていければと思います。

では。

Request Specでデフォルトのヘッダーを設定する

Sun, 06 Oct 2019 00:00:00 GMT

私がRailsを始めた頃は、rspecでのコントローラのテストをそのまま書くのが普通ですが、最近だとコントローラのテストはリクエストスペックが主流のようです。

そんなことを気にしながらリクエストスペックの設定を進めていると「あれ、これリクエストのたびに、認証情報などのヘッダ書かないといけないのか？」と思って調べてみたところ、ちょうど良い方法がわかったのでここにまとめておきます。

Request Specのデフォルトのヘッダーを定義する

ヘッダをデフォルトで設定するには、requst spec内で呼び出せる、 get, post, patch, put, deleteなどのメソッドをラップしてあげることでspecのファイルごとに毎回ヘッダを付与する処理を書かなくて済むようにすることができます。

RAILS API

reqest specの各HTTPメソッドに対応したメソッドはそれぞれ第二引数でheaderを設定することができます。

get '/users/', params: params, header: header

なので、このheader部分にラップした関数でデフォルトのヘッダーを付与して楽しちゃおうというのが今回のやり方です。

Request Helper(HTTPメソッドのラッパ）を用意

まずspec/support配下に下記のようなファイルを用意します。

spec/support/request_spec_helper.rb

module RequestSpecHelper
  %i[get post patch put delete head].each do |name|
    define_method(name) do |path, params: {}, headers: {}|
      super(path, params: params&.to_json, headers: default_request_headers&.merge(headers))
    end
  end
end

define_methodを使ってメタプロしているのでちょっとわかりづらいですが、実直に書いていくと下記のようになります。

module RequestSpecHelper
  def get(path, params: {}, headers: {})
    super(path, params: params&.to_json, headers: default_request_headers&.merge(headers))
  end

  def post(path, params: {}, headers: {})
    super(path, params: params&.to_json, headers: default_request_headers&.merge(headers))
  end

  def patch(path, params: {}, headers: {})
    super(path, params: params&.to_json, headers: default_request_headers&.merge(headers))
  end

  def put(path, params: {}, headers: {})
    super(path, params: params&.to_json, headers: default_request_headers&.merge(headers))
  end

  def delete(path, params: {}, headers: {})
    super(path, params: params&.to_json, headers: default_request_headers&.merge(headers))
  end

  def head(path, params: {}, headers: {})
    super(path, params: params&.to_json, headers: default_request_headers&.merge(headers))
  end
end

ここでのsuperはもともとのActionDispatch::Integration::RequestHelpersクラスのそれぞれのメソッドをさしています。コードをよく見るとそれぞれでdefault_request_headersという変数が呼ばれているかと思うのですが、ここにletなどであらかじめデフォルトの引数を設定しておけばspecファイルの中では

post '/path/to/endpoint', params: params

という感じで、認証に使うようなヘッダなど毎回使うものを定義せずにspecを書くことができるようになります。

このファイルが用意できたらあとは、ファイルを読み込んであげれば良いので、 spec/rails_helper.rbに

RSpec.configure do |config|
   ~~~
  config.include RequestSpecHelper, type: :request
   ~~~
end

という形でrequest specの時だけ同ファイルを読み込むようにしてあげると上のメソッドが使えるようになります。

かなり手短にすませましたが、controller specからrequest specに移行するのに必要と思われる手順なのでまとめておきました。

How to write Circle CI Config 2.1 from basic to advance

Tue, 24 Sep 2019 00:00:00 GMT

Recently, I didn't have a chance to write a lot of config in Cicle CI so far, but I had a chance to touch it at work. That is why I would like to share what I learned there.

I heard that you can use Github Actions nowadays. It's better to compare and contrast these things to see which one is best for your project. However, Circle CI already was used and I didn't have any complain about it so I deceided to use it.

In this case, we had an automated test environment in the current project, but we didn't have an automated deployment environment It seems like the deployment procedure is pretty much dependent on the person in charge. To improve it, we've stareted to automate deployments to make the procedure anyone can use.

Documentation.

First of all, better material to learn Circle CI is the official documentation, which is pretty well written. I used that as a reference to automate the deployment process this time.

Configure CircleCI

I mean, if you read the documents carefully, you may not have to read much of this article here. LOL! However, anyway , I'll try to summarize the documentation and explain it in a way that makes it easier to understand.

What I'll be explaining is the 2.1 version of config, which is different from 2.0.

The 2.1 version of config is different from 2.0, for example you can use "Command", "Executor" and so on.

Summary of concepts to keep in mind in Circle CI

First of all, I will talk outline of Circle CI. Circle CI can write CI configuration in .circleci/config.yml from the project's root directory, and define the processes to be executed in CI.

Job and Workflow.

In the following, we will explain the concepts necessary to define the process, but as a brief explanation, there is a basic unit of the process called Job, which is We'll take that in turn and define a single Workflow.

Some of you may not understand what a Workflow is, but it is the flow of the entire process as translated.

In CI,

Run the test code.
make sure it passes the test and deploy

Workflow is this flow of 1 and 2.

In the real world, it would be more complicated because it is necessary to test and deploy the source of the API server, test and deploy the source of the front end, and so on. But the basic concept is the same.

In this example, the

Testing of the API server
Deploying the API server
Test the frontend
Deploying the frontend code

The workflow consists of four jobs (1), and the order in which these jobs are executed is the workflow.

If you write this in a simple yaml, it looks like the following.こめ

This is not the correct format, so please follow the official documentation.

The following is an example of a simple yaml file.

version: 2.1
jobs:
  - api-test
      name: 'Test the API server'
  - api-deploy:
      name: 'Deploy the API server'
  - front-test:
      name: 'Test the frontend'
  - front-deploy:
      name: 'Deploy the frontend'
workflow:
  - test-and-deploy:
      jobs:
        - api-test
        - front-test
        - api-deploy
            requires:
              - api-test
        - front-deploy
            requires:
              - api-deploy
              - api-front

In the workflow section, there is a section called "requires". You need to write the job. In short, you need to write the dependent tasks for the job.

If you don't write the job requires, CirecleCI will execute the job without paying attention to the order of the tasks, so you need to write the requires in It's also possible that it will be deployed (depending on the number of parallelism). (Depending on the number of parallels)

In this way, Workflow is a high-level concept for Job and if you understand thes small/large relationship of some concepts, you can learn how to set up the configuration more easily.

Steps.

Now that we have the definition down, let's look at the details further.

Job consists of Steps and we describe the actual process in Job in the config file. In Steps, you can execute shell commands and just describe the process in these steps.

jobs:
  - api-test:
      name: 'Test the API server'
      steps:
        - checkout
        - run:
          name: 'Install a library'
          command: /var/spool
            command: | bundle install
        - run:
          name: 'Run a test'
          command: | | bundle exec rspec
            bundle exec rspec

I'll leave the details to the official documentation, but you can use the When clause to control things like executing a command if the previous command fails and there are also commands for checking out of the repository.

The actual execution of the commands is mainly done with the run command, but you can specify a working directory or define environment variables that are valid only in run clause.

Command(available since 2.1)

Command is one of the features from 2.1 and it makes you be able to commonize Steps with Command. For example, in many cases, you may want to activate the cache because it is redundant to install a package for every test.

In order to do so.

Check if the cache exists
Install the package (use the cache if you have it).
Overwrite the cache with the latest state.

but it's too tedious to copy and paste this process for each job, so we'll define this process as a Command and reuse it.

commands:
  package-install:
    description: 'Package installation with cache'
    steps:
      - restore-cache
        keys:
          - v1-hoge-server-{{ checksum: 'Gemfile.lock }}
          - v1-hoge-server
      - run
        name: 'bundle install'
        command: bundle install vender/bundle
      - save-cache
        key:
          - v1-hoge-server-{{ checksum: 'Gemfile.lock }}
          - v1-hoge-server
        paths:
          - vender/bundle

If you write the package installation commands in advance, you don't need to write a process, just call the command, and you can make a DRY configuration.

In addition, you can also pass parameters to this command in the form of parameters to make it easier to create reusable commands.

Executors (available since 2.1)

Executors are for reusing your environment; you can create a docker image and use it in your environment.

Orbs(available since 2.1)

The word "orbs" may be unfamiliar to you, but in essence it is a library. Once you write configuration as "orbs" of the Commands and Jobs I've introduced and publish the "orbs", you can use it in other projects, or more specifically, in all projects that use CircleCI.

https://circleci.com/orbs/registry/

The registry is for Orbs, so check the Orbs you can use.

As far as I can see, there are some orbs such as Slack's orbs, so it seems to be easy to implement notifications by using them. It's easy to install a specific version of Ruby, Node and so on to CircleCI.

Concepts Summary

To summarize what I've been explaining so far

Workflow
Jobs.
Steps.
Commands
Executors.
Orbs.

If you understand those things, you can start to use CircleCI for now. And the relationship between each of them is

Workflow > Jobs > Steps with a relationship (dependency) like this Commands are common jobs, Orbs are common public jobs across projects, and Executors seems to be better understood as common execution environment.

More in-depth.

The description so far should be enough to get you started with CirecleCI, but I was a little curious to get started. A somewhat in-depth summary of the content is as follows.

Using Cache.

CircleCI allows you to specify a directory and save it as a cache. It resolves the problem of installing packages envery build.

dependency cache

You can specify the key and path for caching by using save_cache in Steps in Job. You can use it all the time.

Control on a per-branch basis.

You can use branches to control which branches run Workflow and Job.

With this, you can do things like "if merged into develop, deploy after the tests are finished". You can also register a regular expression whitelist so you can control which feature branch to run tests on

Use SSH.

You may need to do SSH with Ansible, Capistrano, your own scripts, etc., but you will need to use CirecleCI You can use SSH to log in to the remote server by registering the private key to

The private key can be registered in the console. However, if you need to use the private key in your job, you need to add a commanod add_ssh_keys with the key's fingerprint to use the key.

Default Environment Variables.

Here are the predefined environment variables.

Predefined Environment Variables

The user who created the pull request.
Current job name.
The branch name of the current build.

and other build metainformation are defined as environment variables.

Scope of Environment Variables.

Environment variables can be used by defining environment variables in the environments of Workflow, Job, and Executor. The scope of the variable depends on the location where the variable is defined;

If you define them in the job, they are valid in the job; if you define them in the Executor, they are valid in the execution environment.

Validation of the Config file

If you are not used to it, you may not be able to follow the syntax of the Config file at first. If you install CircleCI's CLI beforehand, you can validate your config file in your local env.

To avoid unnecessary pushes to the repositories, it is recommended to push the config file after the validation.

Installation Instructions

Here's the command for validation.

circleci config validate

Summary

How do you think of the concept of CircleCI?

I made the config while referring to the document repeatedly in actual work, but the document is written more carefully and so helpful. In addition, the original config (befor I worked in) was 2.0, but Commands and Executor came to be able to use, and it became quite comfortable because a lot of processes can be commonized. Thanks to this, I was able to automate the deployment of my project.

I will use other features I didn't use this time like "orbs".

基本から応用までCircle CIのConfig 2.1の書き方まとめ

Tue, 24 Sep 2019 00:00:00 GMT

最近Cicle CIを触る機会があり、これまであまりガッツリconfig書き込んだりする機会がなかったのですが、仕事でちょと触れる機会がありましたので、そこで学んだことをまとめて共有していこうかと思います。

Github Actionsなんかも最近は使えるようになっているそうで、そこらへんともちゃんと比較して自分のプロジェクトにどっちがあっているのかというのを比較検討した方が良いかとは思ったのですが、すでにCircle CI を使って現状にすごく不満があるとかではないのと自分自身あまりAPIとフロントがちゃんとあるプロジェクトでCI構築したことがなかったので、まぁまずはメジャーな CircleCIを使っていこうというのを決めました。

今回は、自動テストの環境が現プロジェクトにはあったのですが、自動デプロイの環境が整備されておらず結構デプロイ手順が担当者に依存している感じなので、その改善のために自動デプロイを導入してまぁ誰でもデプロイできるような環境を作ろうかという経緯でCircleCIを使ったデプロイの自動化をはじめました。

ドキュメント

CircleCIを使うにあたってまずは公式のドキュメントが結構ちゃんと書かれているので、そちらを参考にしてデプロイの自動化を進めていきました。

CircleCIを設定する

というかこちらのドキュメントをしっかり読めば、こっちの記事はあまり読まなくても良いかもしれません。笑とはいえ、この後読まれないのも悲しいのでドキュメントをまとめてわかりやすくなるように説明していこうと思います。

今回説明するのはconfigのバージョン2.1で2.0とは異なるので注意してください。

2.1だとCommandやExecutorなどの定義が使えるようになり処理の共通化がより簡単にできるようになっています。

Circle CIで押さえておきたい概念まとめ

まずCirce CIはプロジェクトのルートディレクトリから.circleci/config.ymlにCIの設定を書くことで、 CIで実行する処理を定義していきます。

JobとWorkflow

以下でその処理を定義する際に必要な概念を説明しておきますが、先にざっくり説明をするとJobという処理の基本単位があり、それを順番にして一つの**Workflow(ワークフロー)**を定義していきます。

**Workflow(ワークフロー)**というのがパッとわからない人もいるかと思いますが、まぁ訳した通り作業全体の流というに形になります。 CIだと

テストコードを実行
1.にパスすることを確認してデプロイ

という流れが一般的ですがこの1と2の流れがWorkflowです。

実際の現場では、APIサーバのソースをテスト・デプロイ、フロントのソースをテスト・デプロイする必要があるなど少し複雑になりますが基本の考え方は変わりません。

この例だと、

APIサーバのテスト
APIサーバのデプロイ
フロントのテスト
フロントのデプロイ

の４つのJobから構成され、これらをどういう順番で実行するかというのがWorkflowです。

これを簡易的なyamlで書くと以下のようなイメージです。

※正しい形式ではないので、実際には公式ドキュメントにならって記述してください。

version: 2.1
jobs:
  - api-test:
      name: 'APIサーバのテスト'
  - api-deploy:
      name: 'APIサーバのデプロイ'
  - front-test:
      name: 'フロントのテスト'
  - front-deploy:
      name: 'フロントのデプロイ'
workflow:
  - test-and-deploy:
      jobs:
        - api-test
        - front-test
        - api-deploy
            requires:
              - api-test
        - front-deploy
            requires:
              - api-deploy
              - api-front

workflowのところにrequiresというのがありますが、ここにはjobを実行する前に終わらしておきたい Jobを書いておきます。要はそのJobの依存タスクを書いておく必要があります。これを書いておかないとCirecleCIは順番を気にせずじゃんじゃか実行してしまうのでテストが終わる前にデプロイされてしまうなんてこともありえます。（並列数にもよりますが）

WorkflowはJobの上位の概念として覚えておければ良いかと思います。

Steps

次に、この定義を押さえた上でさらに細かい部分を見ていくとJobはStepsから構成されStepsでは、 Jobの中で実際行う処理を記述していきます。 Stepsの中では、シェルコマンドが実行できここにひたすら、処理を記述していきます。

jobs:
  - api-test:
      name: 'APIサーバのテスト'
      steps:
        - checkout
        - run:
          name: 'ライブラリのインストール'
          command: |
            bundle install
        - run:
          name: 'テストの実行'
          command: |
            bundle exec rspec

詳しくは公式のドキュメントに譲りますが、When句で前のコマンドが失敗したらコマンドを実行するなどの制御ができたり、リポジトリからのチェックアウトなどを行うコマンドも用意されています。

実際のコマンドの実行には主にrunコマンドを使いますが、runでは作業ディレクトリを指定したりそのコマンドの中だけで有効な環境変数を定義したりすることができます。

Command(2.1から使用可)

Commandは2.1からの昨日ですが、Commandを活用することでStepsを共通化することができます。例えば多くの場合、毎回テストのたびにパッケージをインストールするのは冗長なのでキャッシュを効かせたくなるかと思いますが、そのためには、

キャッシュが存在するかチェック
パッケージをインストール（キャッシュがあればそれを使う）
最新の状態でキャッシュを上書き

ということをすると思うのですが、この処理を各ジョブで毎回コピペして書くのはかったるいので、ここの処理だけCommandとして定義して再利用します。

commands:
  package-install:
    description: 'キャッシュを使ったパッケージインストール'
    steps:
      - restore-cache
        keys:
          - v1-hoge-server-{{ checksum: 'Gemfile.lock }}
          - v1-hoge-server
      - run
        name: 'bundle install'
        command: bundle install vender/bundle
      - save-cache
        key:
          - v1-hoge-server-{{ checksum: 'Gemfile.lock }}
          - v1-hoge-server
        paths:
          - vender/bundle

こうやってあらかじめパッケージインストールのコマンドを書いておけばデプロイ前とテスト前にイチイチこの処理を書く必要なく、コマンドを呼び出すだけで事足りるようになり、DRYなconfigができあがります。

parametersという形で引数もこのコマンドに渡せるのでパラメータも使うとより再利用可能なコマンドが作り易くなるかと思います。

Executors(2.1から使用可)

Executorsは環境を再利用するためのものです。dockerのイメージを環境を作ってそれを使い回すことができます。

Orbs(2.1から使用可)

Orbsというワードは聞きなれないかもしれませんが、要はライブラリです。ここまでに紹介したCommandsやJobsはプロジェクト内での共通化ができましたが、Orbsは一度使って公開すると他のプロジェクト、もっと言うとCircleCIを使う全プロジェクトで使うことができます。

https://circleci.com/orbs/registry/

こちらがOrbsのレジストリになるので使えるOrbsを見ておくと良いかと思います。

僕が見た限りではSlackのorbsなどがあったので、それを使うと通知とかが手軽に実装できそうだなという感じでした。その他、Ruby, Nodeなどのorbsなどもあったので、CircleCIに指定のバージョンの言語をインストールするなんていうのも手軽できそうです。

概念まとめ

ここまでで説明してきたものをまとめておくと

Workflow
Jobs
Steps
Commands
Executors
Orbs

あたりを理解しておけばとりあえずCircleCIを始められそうです。またそれぞれの関係が

Workflow > Jobs > Steps という感じの関係（依存関係）で CommandsはJobを共通化するもの、Orbsはプロジェクトを横断するパブリックなJobの共通化、 Executorsは実行環境の共通化と言う感じで理解しておくのが良さそうです。

さらに踏み込んだ内容

CirecleCIを使い始めるにはこれまでの説明で足りそうですが、僕が始めるにあたってちょっと気になり、多少踏み込んだ内容をまとめておくと以下のようになります。

キャッシュを使う

CircleCIでは、ディレクトリを指定してキャッシュとして保存しておけるので、一回のビルドで毎回パッケージをインストールしないといけないという問題を解消することができます。

依存関係のキャッシュ

Job内Stepsで使えるsave_cacheを使うとキャッシュ時のキーとパスを指定して、キャッシュ、restore_cacheでキャッシュを使い回すことができます。

ブランチごとに制御する

branchesを使うとWorkflow, Jobを実行するブランチを制御することができます。

これで「developにマージされたら、テスト終了後にデプロイを走らせる」といったことが可能になります。また、正規表現でのホワイトリストの登録もできるのでfeatureブランチにはテストを実行するといった制御も可能です。

SSHを使用する

Ansible, Capistrano, 自作のスクリプトなどでSSHをする必要がある場合がありますが、あらかじめCirecleCI に秘密鍵を登録しておくことでSSHを利用してリモートサーバにログインさせることが可能です。

秘密鍵の登録はコンソール画面からできますが、鍵を登録された後にそれをJob内で使用する必要がある場合は add_ssh_keysでfingerprintを指定して使用する鍵を登録する必要があります。

デフォルトの環境変数

定義済み環境変数はこちらです。

定義済み環境変数

プルリクエストを作成したユーザ名
現在のジョブ名称
現在ビルドしているブランチ名

などなどビルドのメタ情報が環境変数として定義されています。

環境変数のスコープ

環境変数はWorkflow, Job, Executor内のenvironmentsで環境変数を定義して使うことができます。変数のスコープはそれぞれ定義した場所により、Jobで定義すればそのJob内、Executorで定義すればその実行環境内で有効です。

その他、シェルコマンドやステップ内でも環境変数を設定できますがこちらもそれぞれのスコープのみで有効です。

Configファイルのバリデーション

最初のうちなれないとConfigファイルのシンタックスに添えずエラーになることがあるかと思いますが、あらかじめCircleCIのCLIをインストールしておくとローカルでconfigファイルの検証ができます。

これの検証を通ったらpushするようにするとリポジトリに無駄にプッシュするのを避けることができます。

インストール手順

検証のコマンドはこちらです。

circleci config validate

まとめ

ここまでざーっとCircleCIの概念や導入の際に気になる点をまとめてみましたがいかがでしょうか？

実作業ではドキュメントを繰り返し参照しながらConfigを作りましたが、日本語のドキュメントが結構丁寧に書かれているので意外とすんなり入り込めると思います。また、元のconfigが2.0だったのですが、CommandsとExecutorが使えるようになり、かなりの処理を共通化できるので結構快適になりました。おかげで現場のデプロイをサクッと自動化できました。Orbsあたりはまだ使えていなかったので、今後のCIのエンハンスとしてすきをみて使っていきたいなと思います。

では

引っ越しの荷物をまとめながら考えた読んでためになった技術書&その他本のリスト

Sun, 22 Sep 2019 00:00:00 GMT

どうも、最近サボリ気味だったブログの更新も週次でやっていきたいなんて考えていますが、こうしてまた記事を書いているのでなんとか継続できそうな予感がしています。

このところちょっとした用事で引っ越しをすることになったので荷物をまとめていました。荷物というと家電からPCの周辺機器などなどあるのですが、その中でもやはり本がそれなりの割合を締めてくるので整理するわけで、読みたいときにパッと手に取りたい本とそうでない本を仕分けてみるのですが、手に取りたい本の多いこと笑。

今改めてそれぞれの本を見てみると「あぁこれ良い本だよなぁ」という本が数冊あったのでそれらをまとめて紹介したいと思います。

良い本はやっぱりネットで取り上げられていることも多くかぶる面もありそうですが、とりあえず一斉に紹介できればと思っています。

早速本の紹介

技術の本

プロを目指す人のためのRuby入門言語仕様からテスト駆動開発・デバッグ技法まで

Rubyの入門書ですが、タイトルの通りRubyの言語仕様（トップレベルオブジェクト継承関係など）からデバッグ技法について丁寧に説明されています。

初心者の方が一読してRubyを理解するのにも良いですし、中級者があれここの仕様どうなってたっけ？みたいなリファレンスとして使うにも良です。私自身仕事でRubyを使うことも多いのですが、あまり使っていない部分が頭から抜け落ちていたりするのでその都度この本を参照して再度思い出したりしています。

今のRubyを取り巻く環境的にRubyを触る＝Railsを触るということだと思うのですが、普段遣いではほとんどRailsを触ることが多いかと思いますが、 Rubyを触る人は最低でもこちらのような網羅的な知識の書かれた本を持っておいて繰り返し参照するとRubyおよびRailsでかけるコードの幅が広がります。

また、このように情報量の多い本では一回読んだだけでは全て使えるようにならないので繰り返し本に目を通すのが良いです。日々の仕事やプログラミングで蓄積された経験がこの本を読むことで「なるほどこういうことができるのか！次使ってみよう」というようなアクションありきのインプットができるので記憶の定着と実用性の高いインプットができると思います。

Rubyを書いていると「Rubyを書いていると思ったらRailsを書いている」状態になってしまう (Railsを使わないコードで、Railsでしか使えないメソッドを呼び出ししてハマるなど）こともあるのでRailsガイドやネットの情報に止まらず、このような"Ruby"の本を一冊持っておくと「RubyでできることとRailsでできること」を理解してコードをかけるようになるかと思います。

Ruby on Rails 5 アプリケーションプログラミング

先に説明したのはRubyの本ですがこちらはRailsの本になります。Railsでできることが一通り書かれているのでパッと全体に目を通して気になる部分をさらに読み進める。ちょっと暇な時に繰り返し目を通すというような使い方ができるとRailsの習熟に役立てることができると思います。

RailsはTwitterではちらほらオワコンだみたいな意見も見受けられますが、個人的な意見としてはフルスタックフレームワークとしてここまでライブラリの環境が整備されていて、Railsのルールに沿ってプログラミングをしていけばこれほど素早くシステムを作り上げられるフレームワークは少ないと思うので、まだまだ勉強する価値があるかなと思います。

Rails自体はすでにバージョン6.0がリリースされていますが、一部カバーできていない部分あるかと思いますが基本的な部分はカバーできているはずなのでこちらを買っておいても損ではないです。（同シリーズの6.0があればそちらが良いかも）

キタミ式イラストIT塾基本情報技術者平成31/01年 (情報処理技術者試験)

意外かもしれませんがIPAが認定している資格の基本情報技術者の参考書になります。

ネットだと資格は割とディスられる傾向になりますが、資格試験の参考書はよくまとまっていてわかりやすく網羅的に解説しているものも多いので資格取らずとも本を買うというのは全然ありです。

こちらの本は初心者向けで、これまでIT業界にいなかったけどプログラミングの勉強を始めたいなんて人におすすめです。例え話や図を入れながらわかりやすく解説してくれています。

プログラミングとなるとRailsやReactなどプログラミング言語自体アプリケーションの層の話題になることが多いですが、初心者のうちにつまずくのは一般的あまり語られないコンピュータの構造(CPUって？メモリって？コンピュータってそもそもどうやって動くのなど）の話やネットワークの部分なのでこういったIT知識を網羅的に紹介した本があると心強いかと思います。

すでにエンジニアとして働いている人も新人に教える時にどうやって説明しようかな？という時の参考にのぞいたり、基礎的すぎて人にききづらいときにこっそり参照してみると良いと思います。

Java言語で学ぶデザインパターン入門

こちらは中級者向けという感じですが、エンジニアとして仕事するのであれば持っておきたい本の一つだと個人的には思っています。割と有名な本ですが一応説明しとくと、GoF(詳しくはググってください）の23のオブジェクト指向プログラミングにおける設計のパターンを一つずつ解説している本になります。

23個すべてを頭に入れておくのは結構しんどいので完コピせよとは思いませんが、Singleton, Facade, Strategy, Factory, Observer, Template Method, Composition, Decolatorなどなど有名どころはおさえておくとどの言語を書く時にも役立ちます。

またこれらの知識が公式ドキュメントで暗黙的な前提知識として語られていることもあるので、これらを知っていないとドキュメントを読むのが辛くか理解が浅くなってしまうというリスクを回避するためにも要点はおさえておきたい所です。

またデザインパターン自体がオブジェクト指向の良い例を集め具体例の集合体みたいなものなのでオブジェクト指向を具体例から理解するのにちょうど良いリファレンスだと思います。自身もこれを読み進めることで「あ、良く設計されたコードってこういうことを言うのね」みたいなを実感できました。

本自体が分厚く一気に倒すのは結構骨が折れるので、今日はSingletonを倒そう、明日はStrategyを倒そうみたいな感じで一つずつ倒すようにしていったら日常で遭遇するものはだいたい実際に活用する時には調べながらやるけど、頭にインデックスを作れているくらいにはなったかなという感じです。

プリンシプルオブプログラミング3年目までに身につけたい一生役立つ101の原理原則

こちらはプログラミングにおける設計思想や理論についてひたすら紹介されている本です。タイトルの通り3年目までに身に付けたい内容がブワッと書かれている感じですね。抽象的な内容が多いのである程度実務経験がないと実践は難しいのですが、日々コードを書く際に気をつけたことが良いリストがつめこまれています。

また、業界で良く使われる専門用語集のようでもあり、この本を読んでおくと技術的なブログを読むと時の文脈を理解しながら読めるようになるので一度は目を通して置けると良いかと重ます。

ボーイスカウトの原則、技術的負債、割れた窓の法則、車輪の再発明、DRY、関心の分離などなどが紹介されていますがこれらの単語で良く知らない言葉がある方は購入して一読されるのをおすすめします。

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック

こちらもプログラミングをする上でのお作法的な話にはなりますがリーダブルコードの方がプリンシプルオブプログラミングよりは、命名の大切さやインデントを揃えるネストを避ける、コードを小さく保つなどの”読みやすい”コードをかくための方法が紹介されています。

プリンシプルオブプログラミングが設計などの話に関しても踏み込んでいるに対して、こちらは適切な命名を元にコードを共通化し、一度に一つのことを行うモジュールをつなげてコードを読みやすくするという部分に焦点を絞ってまとめてあります。

コメントに関する考え方や命名の大事さなどが説かれているので一度は目を通しておくと良いでしょう。

関数型プログラミングの基礎 JavaScriptを使って学ぶ

RubyやPHPなどのバックエンドのコードを書いているとあまり必要ないのかもしれませんが（多くはオブジェクト指向にのっとった形で開発するので）、フロントのコードを変えてくると関数型プログラミングの考え方が役に立ちます。ReactやVueなどのライブラリではコンポーネント(関数）にデータを与えると必要なコンポーネントが描画され、データが変わると見た目やテキストが変わり、同じデータを与えたら全く同じ結果になるというのが基本の考え方になっています。

変数をイミュータブルに保ったり、高階関数の考え方はJavaScriptを使う上で必要不可欠なのでフロントをやりたい方は一度関数型プログラミングの基礎に触れておくと良いかと思います。

こちらの本は割と身近な関数型言語であるJavaScript（ここら辺は色々な意見ありそうですが）を使って関数型プログラミングとはなんぞやということを解説してくれています。

実践Vim　思考のスピードで編集しよう！

私の普段遣いのエディタはVimで様々なプラグインを入れていて快適にテキストの編集ができるようにはしているのですが、こちらの本では Vimのデフォルトの機能を最大限り活用するための様々なTipsが紹介されています。

例えば、vimにはビジュアルモードと挿入モードという二つのモードを行き来しながら編集を行なっていくのですがvimではc -> i -> w というたった3つのキーを連続で押すことで単語レベルで文字列を削除した後に挿入モードに移れ(書き換えが楽）たり、ヴィジュアルモードでドットを押すと前の操作を繰り返すことができるのでこれを使って操作を自動化したり、マクロという機能を使って操作を記録して作業を自動化できるといったことがリストになって紹介されています。

VimmerやこれからVimmerになろうとしている方にオススメの一冊です。

SQLアンチパターン

名前の通りSQLにおけるアンチパターンを紹介している本です。ある程度の規模のシステムを設計してて、納期が近かったりするとうっかりこちらの本にあるようなパターンを作り込んでしまっている場合があるのですが、定期的にこちらの目次を見て自分の関わっているシステムがアンチパターンに陥ってないかどうかを確認したい所です。

まずはアンチパターンにどのようなものがあるかを知っておかないと防げるものも防げないのでこちらの本で一度確認させれると良いかと思います。

その他

持っている本が技術書ばかりですが、他にもよかった本がいくつかあるので紹介させていただきます。

音声ダウンロード付】実践IELTS英単語3500

単語帳です。近々IELTSを受ける予定なのでこちらを購入して、まだ完全に覚えてはいないのですが、音声付きというのが良いです。単語を覚えるときには音と一緒に覚えた方が記憶に残りやすいし、会話で単語を聞いた時のイメージの湧き方が違うので単語帳はいつも音声付きのものを使うようにしています。

反省させると犯罪者になります

なかなかショッキングなタイトルなのですが、受刑者と長く関わった経験から問題行動→即反省を求めるような風潮に警鐘をならすような本になっています。

本の中では、犯罪などの問題行動を起こした後に沸き起こる感情がまず最初に反省であるべきということが不自然で、人はまず問題行動の後に「誰々に迷惑をかけてしまい申し訳ない」と思うより「あぁなんあんなことしたんだろう・・・」「あいつのせいで・・・」など反省とは別の後悔や他人を責める感情が自然であるということが指摘されています。

本冒頭では、筆者自身が接触事故を起こした際の感情を例に上記のことを説明していますが、自分が対物の事故をおこしてしまった時も「同乗者に申し訳ない・・・」という感情より「なんであそこに石があるのに気づけなかったんだろう・・」などなど「こんなところで事故るなんてついてないなどなど」割と自己本位なことを考えていた記憶が蘇り、実感として確かにそうかもしれないと思わされました。

こちらの本は、タイトルのショッキングさや一般的にあまり言われていない話でもうちょっと知りたいと思って買った本なのですが、読んでみるともう少し生々しい話や実例なども交えて説明していたりして読んでいて非常に気づきがありました。

刑務所での話が主になりますが人の本質的なところを語っているようで面白いので興味のある人は一度読んでみると良いかと思います。

なぜあなたの仕事は終わらないのか

こちらは最近チラチラネットの動画でお顔を拝見する中島聡さんの本です。仕事術の本として読んでいてい面白いのですが、中島聡さんのマイクロソフト時代のエピソードの話などがあって面白いです。

本書でメインで語られている「ロケットスタート仕事術」ですが、これには結構同意していてエンジニアって頼まれた仕事だけやっていると本当に発注元が必要と思う機能を実装するだけの仕事に終始してしまったり、システムの見積もり自体が難しいのでプログダクトの価値にクリティカルなもの以外は一定程度のバッファをとって納品するのがベストだと思っているのですが、これがまさにそれを体現する仕事術で全面的に賛成したい仕事の進め方でした。

エンジニア界隈だと業務時間外に勉強しないといけないのか！みたいな話がありますが、個人レベルでは要は業務時間外に勉強しなくて済むような仕組みを作るか、キャリアアップを諦めて少ない遺産を取り潰しながら仕事するかという選択な問題な気がしています。

業務時間外に勉強したくないのであれば時間内に勉強できるような仕組みを作れば良いだけで、この「ロケットスタート仕事術」はそれのヒントになるのかなと思っています。ロケットスタート仕事術では、見積もり期間の前半で全力でものを仕上げて後半は仕様の追加等なければ流すという内容なので、そこで勉強したい人は後半の空いている時間で勉強すれば良いということです。

ちょっと色々書きましたが、仕事術としても当時のMSの状況を知る上でも面白いのでおすすめです。

中島聡さんのブログ自体もなかなか読み応えがあるのでおすすめです。

Life is beautiful

自分の時間を取り戻そう―――ゆとりも成功も手に入れられるたった1つの考え方

こちらはちきりんさんの有名な本です。

個人的にちきりんさんの本が本質をついているのに簡単な表現を使いながらわかりやすく言いたいことをまとめているのに驚いていて、いくつか本を購入しているのですが、こちらは正社員時代に読んでなるほどと思った本になります。

まず生産性という考え方をしっかり説明するところから、実際に4人のモデルケースを示しながらそれぞれのケースで仕事を効率化して生産性を高めて「自分の時間」をいかに増やしていくかということを示す本になります。

個人的にこの本で面白いと思ったのは、男性サラリーマンや共働きの女性などの一般的に家事や長時間労働に悩まされていそうな層以外に起業家をモデルケースに取り上げている点になります。

一般的に長時間労働が問題視される男女問はず忙しい社会であるというのは理解されているのですが、起業家などは「好きでやっているんでしょ」とか「仕事とプライベート関係ないんでしょ」といった雰囲気のある層にも「自分の時間を取り戻そう」という提案をしているところが面白いと思いました。

個人的に起業してある程度組織ができてくると自分が作ったはずなのにその組織に縛られてしまうみたいなことはまぁまぁあると思っていてそれで悩んでいる人も一定程度いると思うのですが、そこをモデルケース組み込んで提案しているのは新鮮でした。

こちらの本を読むとそもそも「生産性ってなんだっけ？」というところから考えることができるのでおすすめです。

マーケット感覚を身につけよう---「これから何が売れるのか?」わかる人になる5つの方法

こちらはフリーランスになってからと、なる直前になるほどと思った本です。

マーケット感覚とは

商品やサービスが売買されている現場の、リアルな状況を想像できる能力
顧客が、市場で価値を取引す場面を、直感的に思い浮かべられる能力

とのことなのですが、フリーランスともなるとやっぱりお客さんがどういったことをメリットと感じて契約してくれるのかというところを考えないとダメだよねと思っているのですが、エンジニアのフリーランスだと間にエージェントが入ってくれたりしてなんとなくやれちゃう風潮はあると思います。

そんなかで、エージェント抜いて仕事取りたいだとか、単価あげたいという風に思った時にここら辺の感覚は大事になってくると思います。エンジニアはシステム開発のお手伝いをすることでそのフィーをもらうことで価値の交換をしているのですが、単純な技術力だけだとお客さん側自体がエンジニアでないことも多く区別がつかず報酬が平準化してしまいます。

エンジニアとしてベースの技術力を高めることは必要不可欠ではあるのですが、技術力だけが単価に直結すると考えるのは少し視野が狭いかとも思うので、フリーランスとして生活するのであれば自分がフリーランスとしてどのような価値を提供していてるのか？または他に提供できる価値はあるか？という視点で日々の仕事を見返せると良いかと思います。

この本はその考えるキッカケになるかと思うので手にとってみると良いかと思います。

Illustrator しっかり入門増補改訂第２版【CC完全対応】［Mac & Windows 対応］

タイトル通りIllustlatorの入門書です。ネット上には断片的な情報や動画などはあるのですがとりあえず基本的なところを総ざらいするのであれば本が一番良いかなと思い購入しました。

自分でアプリ作ったりブログを作ったりしているとロゴ作ったりサムネイル作ったりをIllustlatorでやるので、もっとちゃんと知れると便利だなということでネットでデザイナーさんが進めているものを購入しました。

先に紹介したRailsの本のように機能が一通り紹介されているので、それとどうように網羅的にツールの機能を把握するのと使うところをつまみ読みする用途で使っています。

UI デザイナーのための Sketch 入門＆実践ガイド

こちらもIllustlatorの同じ目的で購入した本です。やっぱりSketchは使われているだけでワイヤーフレーム的な複数画面をデザインする時はシンボルなどの機能があって便利なので、Illustratorと合わせてこちらの本を購入しました。

番外編

ブックタワー

NASってなに | バッファロー - Buffalo

これは番外編ですが、本からちょっと引いて本棚の紹介です。

先にも本は繰り返し読むというようなことをかいておいたのでできるだけ取り出しやすい位置に本を置いておきたいのですが、そのまま机においておくとどこかちらかった感じになってしまい見栄えがあまりよくないです。

が、このブックタワーだと暇な時にちょっと本をとったり、積み上げたりするのがかなり気軽にできます。

本棚にしまうのも億劫な人にはこちらのブックタワーを使われることおすすめしておきます。

まとめ

というわけで引っ越しを間近に控えた中で読んでよかった本をリストにまとめてみました。一部本棚という番外編もまとめてみましたが、気になるものがあったらぜひ購入してみてください。

NAS(ネットワークHDD)を使って"KonMari"してMackbook Proの容量を30GB近くあけた話

Mon, 09 Sep 2019 00:00:00 GMT

最近こんな記事を見つけて英語圏ではこんまりは動詞なんだなぁと感慨深かったのですが、(ちょっと古いですがFacebookするみたいな感じですかね)

ときめかない社員はレイオフされちゃうのか😭 https://t.co/Mhiffc4uMG
— version1 (@version1_2017) September 9, 2019

そういえば最近NASを使ってMacBookの容量をこんまりしたら随分と快適になったなぁというのがあったのでその話を記事にまとめてみます。

NASって

IT業界にいても意外とNASという言葉を知らない人も多いのかなぁと思うのですがネットワークHDDのことです。外付けのHDDはUSBで繋いでデータ通信しますが、それを無線でやるやつです。

NASがあると家のWiFi環境下でデータ通信ができるので、家の中にいればスマートフォンやPCと連携した様々な便利な使い方ができたりします。

MacBookProの容量256GBは限界？

今使っているMacBookProの容量は256GBなのですが、すでに対策前の空き容量が10GB程度しかありません。。

残り10GBならまだ意外と使えるかと思いきやXcodeのアップデートに容量が足りないと言われるし、Slack,Docker,Node,Chromeなんかを同時に立ち上げた日にはメモリが、足りずにスワップファイルをガンガン吐き出して気づいた時には空き容量が2GBしかないなんてことが頻発してました。

やはり256GBでは限界かと思っていた矢先仕事柄データが吹っ飛んだりすると業務にかなり支障が出るのでバックアップをとっておこうと思ってあったNASがあるのを思い出し、 NASを使ってこんまりしてみたところなんと30GB近く削減し、だいぶ余裕をもって作業ができるようになりました。

MacBookを新たに買い換えて512GBのSSDなどにすると20万弱かかってしまうところを新たなNASの購入(あとで紹介しますが1万円程度)だけで済ませられたのでかなり得した気分になりました。

NASを使ってMacBookの容量削減

NASとかいう難しい単語が出てくると何やら難しいことをしてそうですが、要は外付けのHDDにPCの重いファイルを追いやったということです。

NASはこちらのバッファローのNASです。

BUFFALO NAS スマホ/タブレット/PC対応ネットワークHDD 2TB LS210D0201G

1万円するのでちょっとためらうかもしれませんが、これ一つ家に置いておけばPCのバックアップやスマホのバックアップなどをこのHDDに保存しておけますし、常に使うわけではない容量の大きいファイルをこちらにうつしておけばlaptopの容量も削減できます。

僕は2TBのものを買いましたが、記事を買いている時にみてみると1TBも2TBも全然値段かわらないみたいです。バックアップファイルのことを考えると1TBだとちょっと不安なので2TBを購入しました。

MacBook ProからNASに移動する対象のファイル

今回PCの容量を開ける時にMacbookから移動したファイルは

スマホのバックアップファイル（10GB弱)
iTunesの音声ファイル(20GB程度）

です。スマホのバックアップファイルはまぁなるほどという感じだとおもうのですが、 iTunesの音声ファイルが特におすすめです。音声ファイルというとちょっと無機質な感じですが昔から秘伝のタレのようにつくりあげられた好きなミュージシャンの曲のリストたちです。

音楽って普段聞かないけど、なぜか急に無性に聞きたくなるときとか気分を変えて昔のアルバムかけてみたりとかする時がありなかなか消せなかったりします。長年積み上げていくと本当にバカにならないくらいかさばります。

ファイルを移動する前は、**「聞きたい時に毎回HDDから吸い上げて聞くのちょっと怠いな」**と思っていたのですが、調べてみるとiTunesのミュージックの保存先は自分で設定できるし、PCをNASに接続しておけばNASのディレクトリをマウント（PCのディレクトリのように扱えるようにする）できるので、PCを立ち上げてNASの中にある曲を直接聞くなんてことができます。

iTunesでNASにある曲を聞くための設定方法

手順としては

PCにあるファイルをNASの特定のフォルダに移動
iTunesの曲のリストを削除
iTunesで音声ファイルの保存先の設定で1.のフォルダを指定
iTunesのメニューからライブラリに追加でNASに移したファイルを指定して読み込み

となります。

2.の部分で曲のリストを削除するときは、iTunesのライブラリから削除するのであってファイル自体を消すわけではないので注意してください。 iTunesから右クリック削除で最初に「本当に消しますか？」と着替えてyes、次に「パソコンからファイルを消しますか？」と聞かれるのでここでNoを選べば iTunesのライブラリから削除するだけですみます。

またPCとNASの接続方法やマウント方法は各端末のマニュアルにしたがって頂ければと思います。

1. NASの特定のフォルダに移動

こちらはタイトル通り、iTunesのフォルダに保存されているファイルをNASの特定のフォルダに移動します。サイズがでかい場合は何回かステップを分けて移動すると良いかと思います。

iTunesの音楽ファイルは「Finder > Music > iTunes > iTunes Media > Music」配下にアーティストごと置いてあるので Music配下のフォルダを階層ごとNASのディレクトリに移動します。

2. iTunesの曲のリストを削除

音声ファイルを再読み込みをするのに一旦iTunesのライブラリから曲を削除します。この時に先に書いたようにファイルごと削除してしまわないように気をつけてください。

当初iTunesの音声ファイルの保存先を移動したらいい感じに読み込んでくれるのかなと思ったのですが、保存先を変更した後に曲を再生するとファイルが見つかりませんとなってうまく行かなかったので、保存先を変更する前に一度ファイルをライブラリから削除しておくと良いと思います。

3. iTunesの保存先を変更

iTunesの保存先の変更はiTunesからできます。「iTunes メニュー > 環境設定 > 詳細 > フォルダの場所「変更...」」から変更できます。

4. NASに移動したファイルの読み込み

「iTunes メニュー > ファイル > ライブラリに追加」からNASに移動したファイルを指定してNASのファイルを読み込みます。

以上、ここまでの手順でiTunesの音声ファイルをNASに移動してPCの容量を空けながら、お気に入りの音楽を聞くことができるようになります。

まとめ

今回は、iTunesの音声ファイルを移動する方法でのNASの活用方法を紹介しましたが、まだまだNASを活用して容量をあけることがで来そうな気がします。

ストレージは本当に容量を大きくすれば大きくしただけスペースを埋めてしまうので本当に際限ないです。特にストレージがSSDとかになると結構コストもかかってくるのでHDDとうまく使い分けてコスパよく運用できると良さそうです。

PCの中でもよく使うファイルと時々使うファイルが分かれるので、そこをうまく切り分けて使用頻度の少ないものはNASに移すということができると良さそうですね。

では。

Oculus Quest + Immersed VRでVR空間でプログラミング

Tue, 27 Aug 2019 00:00:00 GMT

前回の記事で紹介したようにOculus Questを購入したわけなのですが、購入の動機に「VR空間でプログラミングできるか試したい！」というのがありました。

VR空間でのプログラミングをする時の考えうるメリットは、

ディスプレイなしで大画面を映し出してコードがかける
自分の好きな仮想オフィスで空間の雰囲気を楽しみながらコードをかける
アバターなどを使って、仮想オフィスを実現できる？

あたりかと思っているのですが、どうでしょうか？

ディスプレイなしで大画面を映し出せるなんて、自分の家の省スペースにもなるし、旅先でちょっとコード書きたいなという時とかにゴーグルつけてプログラミングできたら最高ですよね（外出先などでやるのは多少勇気が必要ではありますが・・）

今回はOculus Quest + 最近無料トライアルが開始されたImmersed VRで仮想デスクトップ環境を楽しんでみます。

MacではVirtual Desktopが使えない・・・

Oculusを手に入れた後に、よっしゃVR空間でプログラミングしようと思って、ちょっと調べてみるとなにやらVirtual DesktopというアプリでPCにログインして、その画面をVR空間に映し出せるそうなのですが、なんとこれMacには対応していないようで嬉々としてVirtual Desktopに期待していた自分はかなり落ち込みました。 (実はまちがって購入してしまいました・・・）

なんとかMacでも自分のPCをVRの大画面に写し込んで作業ができないのか、大画面のディスプレイを使う代わりにVRゴーグルで代替できないかというのを調べてみるとなんと、 RedditのでなにやらImmersedというアプリが人生を変えたみたいな大げさな書き込みを発見したのでImmersedというワードで調べてみました。

https://immersedvr.com/

Immersed自体はアメリカのベンチャーらしいのですが、会社のページに飛んでみると実際にImmersedを使用している映像が動画で公開されています。動画をみてみるとなにやらVR空間にブラウザやエディタのスクリーンが映し出されていておぉぉぉ！まさにこれぞ求めていたものという感じです。

さらに今なら14日間の無料トライアルがあるそうなので、試してみました。

Immersedを試してみる

セットアップの仕方やインストールの仕方など細々した話はあると思いますが、まずこの動画をみてもらえるとImmersedをよりリアルにわかってもらえるかと思います。

動画を見てもらえばわかる通り、アプリを起動すると自分が仮想オフィスにいるような状態でスタートし、目の前にメニュー画面が表示されて仮想オフィスの設定やらなにやらができるようになっています。

仮想オフィスの設定

ここで、強調しておきたい一つ目が仮想オフィスの部屋や背景をメニュー画面から変更をすることができます。

こんな感じで雲の上で作業しても良いし

こんな感じで緑豊かな草原のど真ん中で作業しても良いし、宇宙船のような中で作業するもよしです。

背景自体はメニュー画面からかなり手軽に変えられるので、ちょっと気分変えたいなとおもったら変えたりできるのでPCのデスクトップのような感じの気軽さで変更できてしまいます。

最初メニュー画面を操作をしていて、メニュー画面をクリックして背景を変えようと思ったのですが、何回クリックしても変わらないみたいな現象があり、「全然使えないじゃん」と思ったのですが、どうやらメニュー画面の裏にキーボードがあるとうまく反応してくれないらしくメニュー画面をいじるときはソフトウェアキーボードをしまうかメニュー画面の裏にこないようにずらすなどしてあげると良さそうです。

Eliteプランで最大5つまで伸縮自在のスクリーンを表示可能

ほかにも標準でホワイトボードが使えるようなサブ機能もあるのですが、なんといっても一番大事なPCスクリーンをVR空間に映し出す部分に関してはかなり融通がきくようになっています。

４つある料金プランのうちのトライアルで体験できるEliteプランの場合、最大5つまでの仮想スクリーンを立ち上げることができます。動画ですと三つまでしか表示してないですが、プランに応じて複数枚のスクリーンを写しだすことができます。

また、それぞれのスクリーンは伸縮自在の遠近も変更できます。メインの画面は前側に写して、サブの画面は後ろにおいやるとかも全然できます。

画面のサイズは自分にあった程よいサイズを選択することができそうで、若干文字が見づらいなどがある場合は解像度の調整を加えてちょうど良いバランスを見つけてあげると良さそうです。

キーボードはそのままPCのキーボードを使用できる

これは当たり前かもしれませんが、一応断っておくとPCのスクリーンはVR空間に映し出されますが実際の操作は Macのキーボードやトラックパッドで操作できます。外付けのキーボードを使っている方はそのまま外付けのキーボードを使うことができます。

VR空間上にはソフトウェアキーボードが映し出されますが、物理キーボードがそのまま使えて、jキーを押せばソフトウェアキーボードの jキーが光るという感じでキーボードの対応はしています。普段キーボードで入力をする際にあまり手元を見ている感覚はないのですが、実際にゴーグルをかぶった状態でタイプしろと言われると結構ミスるようになります。（というか、慣れないと全然ダメ）

物理キーボードで入力できるのでわざわざソフトウェアキーボード表示させる必要ないとも思ったのですが、意外とソフトウェアキーボードがないと自分がどこを打ってミスっているのかわからないので、ソフトウェアキーボードは画面のチラ見できる位置に置いておくと良いのかもしれません。

Immersed社のサイトを見てもQuestへのキーボードの直接接続にも対応すると書いてあったりするので、もしかしたらいつか自分の物理キーボードを VR空間常に表示できてほとんどリアルと変わらずにタイプできる日がやってくるのかもしれません。

とまぁ一旦ここまでで紹介は終わりにし後回しにしていたインストールの手順などを簡単に説明してきたいと思います。

セットアップ

早速、セットアップの説明を進めていくとOculus QuestでImmersedを使う場合はこちらから無料トライアルを開始できます。

https://immersedvr.com/quest

フォームにメールを打ち込んで送信を行うとメールが届きます。無料トライアルではEliteプランを楽しめるそうで Eliteプランだと5つのヴァーチャルスクリーンやオフラインモードなどなどが楽しめるそうです。Eliteプランの料金は月額だと9.99ドルで利用可能だそうです。 (だいたい 1 Netflix くらいですかね)

料金表をみるとEliteプランの下のProプランと料金が一緒なのは期間限定なんでしょうか？？ちょっとわからずですがとりあえずトライアルを試してみましょう。

Oculusへアプリをインストール

早速先ほどの招待画面からメールアドレスを入力して送信するとImmersedから招待コードへのリンク付きのメールが送られてきます。

招待コードをOculusの設定画面から入力するとOculusにアプリをインストールすることができます。

Macに画面共有用のエージェントアプリをインストール

Oculus側にアプリがインストールできたら、今度はMac側にAgentアプリをインストールします。（アプリはメールで送られるリンク先からダウンロードできます。）

ダウンロードのあとPCの再起動などが必要ですが、アプリの画面の指示にしたがってインストールを行なっていきます。

エージェントアプリを立ち上げつつ、OculusでImmersedを立ち上げ

Mac側のエージェントアプリがインストールできたら、あとはそのアプリを立ち上げたままOculus側でImmersedを立ち上げて、メニュー画面でConnectというボタンを押すだけです。

ここまですごく簡単にではありますが、インストール方法を書きましたが、まぁそこまで難しいこともないと思います。メールやメールで送られてくるリンクなどにしたがって設定していけばすんなりセットアップできるかと思います。

Immersedは実運用に耐えるのか？

ちょっとセットアップと紹介の順序がバラバラになってしまいあれなのですが、最後はちょっとImmersedを触ってみて実際にImmersedを使って仕事したり、趣味のコードを書いたりできるのか？というところをまとめて置こうかと思います。

結論としては、 実導入にはまだちょっと早いかなというのが今回使ってみた感想です。

ただ、実際問題として引越しのたびに巨大な物理ディスプレイを箱に詰めて運んだり、購入したりとかってやっぱり相当面倒ですし、自宅に何枚ものディスプレイを設置してなんかしていると相当場所とるしお金もかかるのでかなり、こういったVR空間のオフィスみたいなものには期待しています。

Immersedには他のユーザとのコラボレート機能もあるようなので機会があったら試してみたいのですが、VR上のオフィスを実際に運用できると通勤の手間などなくなってよくて憧れますよね。

その他、使ってみて気になる点としては、やっぱりキーボードのところでなれの問題もあるかとは思うのですが、ゴーグルつけながらのキーボードになれずタイプミスがかなり起きてしまいます。物理キーボードをVR空間に表示できるとかなりここは改善できそうな気がするのですがどうなんでしょう？（VRの開発については無知なので完全に雰囲気で書いてます）

また、入力時のラグがやはり若干あるかと思っていて普通のPCになれているとちょっとストレスに感じるかもしれません。またちょこちょこポインタが動かなくなったり、クリックできなくなったりというのがあるのでこれも含めてまだちょっと早いというジャッジでした。

そのほかデバイスの問題もあり、Questの場合、充電満タンからでも2, 3時間程度しか充電がもたなかったりするのでそういった障害もありそうです。ゴーグルが重い問題は、最初は感じましたがその他ゲームなどやるうちにだんだん慣れてきて意外と気にならないのかなという感じです。

ImmersedのCEOのブログでVRで作業しているなどなど書いてあったのでやろうと思えればできるっぽいです。

Working in VR 8+ hrs/day

まとめ

というわけで、今回はVR空間での作業空間をつくるツールとしてImmersedを紹介してみました。

先にも書きましたように、実際に使えるか？といわれるとハッキリとyesとは答えられませんが、思ったよりはリアルと変わらずにプログラミングしたり、記事を書いたりできそうです。

今回は個人での利用に絞って記事をかきましたが、Immersedは部屋を作って人を招待したりもできる他ユーザとのコラボレートの機能もあるようなので、機会があれば試してみたいですね。試したらまた記事書くかもしれません。

では。

Oculus Quest (オキュラスクエスト) 2019 単体型VRヘッドセット
スマホPC不要 (64GB) [並行輸入品]

VRゴーグルのOculus Quest(クエスト)が届いたのでその感想

Sat, 24 Aug 2019 00:00:00 GMT

Oculus Questとは？

Oqulus Questとは今年6月にOculus社から発売されたスタンドアローン型(PCと繋がなくてすむ)のVRゴーグルです。

Oculusから出ているゴーグルには他にもRift, Goなどなどの製品がありQuestはその新作です。

カンファレンス等々でVRゴーグルは試したことはあるのですが(そのゴーグルがなんだったかは覚えていない。。)、手元にあるだけで自分で開発して遊んだりできるので今回思い切って購入してみました。

Oculus Questの購入・設定

QuestはOculus社の公式サイトから購入できますが、Amazonでも買えるようです。

Oculus Quest (オキュラスクエスト) 2019 単体型VRヘッドセット
スマホPC不要 (64GB) [並行輸入品]

ただ結局Amazonですと在庫がなかったりとか、表示が分かりづらく違ったものを買ってしまったり、正規の値段より高く買ってしまうのが嫌だったので今回は公式サイトから購入しました。 (これを書いている段階でAmazonと公式の値段を比べてみると公式の方が安そうですね。）

公式サイトから購入フローを完了させると、メールでトラッキングのリンクが送られてくるので、それで発送日時が分かります。

今回は注文してから1週間程度で届きました。ここらへんにかかる時間はやっぱりAmazonの方が早いのかもしれません。

というわけで、

無事クエストさんが届きました。

箱のふたをあけるとこんな感じ

でして、同梱物は

ゴーグル
メガネ用のスペーサ
コントローラ二個 + 電池
充電ケーブル
説明書

のようになっています。普段自身がメガネをかけているのでメガネをかけながらでもゴーグルをつけて楽しめるかちょっと不安でしたが、メガネ用のスペーサも一緒に入っておりメガネをつけて遊ぶ人はこのスペーサを取り付けてメガネをつけながらでもVRの世界を楽しむことができます。

セットアップは、携帯にアプリをインストールして行いますが難しいことはありませんでした。アプリをインストール後簡単な設定をしてゴーグルをWifiに繋いで、ちょっと設定をするとすぎにQuestのチュートリアルを始めることができました。

最初にゴーグルをつけてみるとわかるんですが、やっぱり没入感が半端ないです。クエストを遊ぶ前に VRの空間上に動き回れるエリアを設定できるのですが、コントローラで部屋の中の安全なエリアのラインを書くとそのまま仮想の壁が浮き上がってきて遊ぶ前からバーチャルな壁が見えてテンションが上がります。

いきなりお目当のゲームを購入して遊ぶのでもよかったのですが、部屋の一室にいるだけなんですがゴーグルをつけてるとホームのスペース（webでいうトップ画面、メニュー画面てきなところ）が広すぎて立派なインテリアとかがあるのでそれを見渡すだけでも十分楽しめました。

また、コントローラをいじりながらどんなゲームがあるのかなぁとかをみているとデモのゲームがあったのでそれで遊びがてらVR空間になれるというのをやっていきました。デフォルトで遊べるのはデモのゲームとブラウザでしたがデモでも何回もやっても楽しい感じでついついデモで遊びすぎました。

あとで紹介するCreedやBeet Saberなどがデモで遊べるのでOculus Questを購入したら最初遊んでみると良いかと思います。

Oculus Questで充電できない

デモでも楽しめるくらいのOculus Questですが、その楽しい時間もつかの間、開封したままの十分じゃない充電状態から夢中になって遊んでいると、画面には充電が20%を切った表示が出てしばらくすると電池が切れて電源が切れてしまいました。

「今日はこれくらいにしてやるか・・・」という感じでその日は、正規の充電コードにつないで寝ました。

次の日また、VR空間を楽しみにゴーグルをつけて見てみるとなんと夜一杯充電したにも関わらず、

電池残量が5%ということで全然充電できていませんでした。。

Questはデフォルトでゴーグルをかぶるとセンサーが反応して電源がつくのですがなんかそれが悪さしてあまり電源が消費されちゃったのかなと思いながら、我慢してまた半日ゴーグルを充電しました。

半日経ったあと再度充電を確認すると今度は電池残量20%・・・現代社会では体感したことのないくらいの充電速度で「最新のゲーム機ってやっぱこういうもんなの・・」と考えながら長い時間かけて進めたスーパーファミコンのRPGのデータが平気で吹っ飛ぶ理不尽さが頭をよぎりました。

まだチュートリアルとデモ程度してか遊んでないゴーグルでこんだけしか遊べないという危機感からネットの情報を漁ってみると

Oculusのゴーグルは43度以上になると充電されない仕様となっている
ゴーグルの置き方に気をつけないとセンサーが作動して電源が入ってしまう
バッテリーが新しいと充電が遅い？？

などなどの情報がでてきました。 ※ネットの情報で真偽は不明なので参考にする際は十分注意してください

ということでこれらの情報を頭におきつつ色々と気をつけて充電をしてみますが、一時間充電しても充電が1, 2%しか増えないという危機的な情報でした。そろそろちゃんと公式に問い合わせをしようと重い腰をあげようとしたのですが、ふと正規のコードが悪いのではとおもったので別のコード（普通にどこにでもあるUSB => USB Type-Cのコード）で充電するとみるみるうちに充電が溜まっていきます。

ということで、なんと正規品のコードが原因で充電がたまらなかったようです。。初期不良なのかなんなのかわからないのですがわざわざ問い合わせてもらってコードを交換してもらう必要もなさそうだしまぁいいかということで今は普通にそこらへんのコードで充電しています。

なにはともあれ、初期不良とかでゴーグルごと交換されてしばらく遊べないとかは避けられたのでひとまずほっとしました。

Oculus Questで遊んでみた感想

と、そんなこんなでなんとかクエストで無事遊べるようになったわけなのですが、レビューらしいことも書いていなかったので、感想を書いてみます。

やはりスタンドアローン型ということで、実際に立ち上がってあるいたり、VR空間上の物を掴めたり、自分の動きがVR空間にリアルタイムで反映されてというところで相当な没入感を味わうことができます。

実際に歩くとなるとそもそも部屋の中でそんなスペースがとれるわけではないので、腕を振ることで移動を代替はしていますが、自分の動きと空間内のキャラクタの動きが連動していて自分がVR空間の一員であることを十分に感じることができます。

バッテリーに関しては満タンまで充電して、2、3時間遊べるという感じでゲームに熱中しているとちょっと足りないかなと思うこともあるのですが、 Beat Saberなどのようなガンガン体を動かすゲームだと結構体力的にも消費されるのでまぁちょうど良いかなと感じる部分もあるかと思います。

ここからは自分が遊んだゲームを順番に紹介していきます。

Beat Saber

Beat Saberは、Questを買ったら遊ぶべきゲームタイトル！みたいなやつにはほとんど入っています。というか、最初からデモからインストールされているので、プレイする人は多くいるんじゃないかと思います。

ゲーム自体は、ライトセーバーを両手に持ってリズムに合わせながら、流れてくる赤や青のボックスをひたすら叩き斬るリズムゲームです。これまでにヒットしたリズムゲームは太鼓の達人やダンレボなどなどありますが、このBeat Saberは実際にボックスが自分に流れてくるので、プレイに没頭すると本当に現実世界でライトセイバーを操り、ボックスを切っている感覚に没入できます。

また、ボックスを切った時の音やアニメーションがとてもよく、爽快感を味わうことができます。（個人的には二本のライトセーバーを合わせた時のジーーという感じでコントローラも合わせて振動する感じがすきです）

実際にプレイしている感じはこんな感じです。

Creed Rise To Glory

こちらはロッキーの続編映画「クリードチャンプをつぐ男」を元にしたボクシングゲームです。パンチはもちろん、スウェーなどの動きもQuestの6DoFの機能を最大限に生かして再現したゲームになっています。

リングにいる相手選手やバトルの映像はかなり迫力があり、

画像のようなヤバイ肉体の人が目の前にいたらゾッとするななんて思わせるほど臨場感がありました。

VRなので、もちろん会場の様子やレフェリーなど360度あたりを見回すことができて迫力の映像を体験することができます。ゲーム自体は、操作方法がイマイチよくわからずやりこんではいないのですが、相手を倒した時の爽快感がやっぱりいいですね。

僕は熱中しすぎて拳を壁にぶつけてしまい痛い思いをしたりもしたので、プレイする際は十分気をつけると良いかと思います。

まとめ

というわけで、プレイした感想やOculus充電できない問題に遭遇した問題などなどを紹介させていただきました。

Go など他のVRゴーグルに触れたことがないので、それらの比較などはできないのですがVR初心者として予想以上に没入感がすごく、わかっていても360度の映像を体験するとついつい感動してしまいました。

VRゴーグルではまだゲーム用途での使い方しかしていないので、ほかに動画をみたりとか、ゴーグル使ってプログラミングしてみたりなどなど色んな使い方をためしてみたいですね。ゲーム方面だといまいまアクション系しかためしていないので、他のパズル系のゲームとかも楽しめるとよいかもしれません。

VRゴーグルの面白い使い方がみつかったらまたここで紹介するかもしれないです。

では。

Create React+TypeScript+ES6 template for Electron

Sun, 14 Jul 2019 00:00:00 GMT

It's been a while since I've posted.

I have a feeling that a lot of things are going to change these days, and I'm going to have to deal with that. I haven't been able to update this page, but I hope I can update this page periodically as well.

I've been using electron for my personal project, so I'll write about that. I thought it would be fun to make apps on the desktop a long time ago, so I tried to use electron a little bit so I started to use it since then.

I was writing in Vallila js then so naturally, I want to use React in it this time.

Once I install React into the project, I started to fell like writing code in TypeScript, so I tried with create-react-app. However, the fact that the main process does not support import statements is becoming more and more worrisome.

When the app is small, I can ignore the fact that the main process is responsible for the old way of writing style, but I've been able to use the electron API to tweak window and The amount of code that you have to do is gradually increasing as you go through all of this, and it's getting harder and harder. Plus, you have to use the same constants between both processes. Thus, I would have to write the code in the old way like export, modules or something like that.

In order to solve this problem, I made a template repository for React + TypeScript + ES6 for Electron.

Here is repository. Check it out.

You can easily start Electron with React + TypeScript + ES6 (if you are familiar with it) which you are used to in your projects.

Main Process and Renderer Process.

If you don't know Electron in depth, you won't know what Main Process and Renderer Process are. The main process, which exists only one process per application, is the one that starts up first when you run Electron.

On the other hand, render process is fired up for each window , and one application has multiple renderer processes.

The main process, as the name suggests, can handle ready and all-window-close ready, executes callbacks, creates new windows (renderer process), and so on. You can also handle each renderer process by operating on a specific window.

Example Code for Main Process (Entry Point)

The following is the entry point for the repository I mentioned earlier, which creates an instance of BrowserWindow (starts the renderer process) at the time of launching the app, and exits the app itself when all the windows are closed. This is the kind of process I've written.

When you create a more complex app, you need to add process like closing window or change the menu depending on input in render process.

import { app, BrowserWindow } from 'electron'

const onReady = async () => {
  win: BrowserWindow | null
  win = new BrowserWindow();
  win.loadURL('http://localhost:8080');

  // Open the Chromium Dev tool.
  win.webContents.openDevTools();

  win.on('closed', function() {
    win = null;
  });

}
app.once('ready', onReady)
app.on('window-all-closed', () => { app.quit() })

Example Code for Renderer Process (Entry Point)

On the other hand, you can think of Electron's renderer process as the front page of a web service, and most of the web development know-how can be directly transferred here, and React runs on the renderer process.

import React from 'react'
import styled from 'styled-components'
import { GlobalStyle } from 'styles/Index'

const Container = styled.div`
  max-width: 200px;
  height: 100%;
  width: 100%;
  margin: auto;
  display: flex;
  align-items: center;
}
`

const Title = styled.h2`
  text-align: center;
`

const Description = styled.p`
  text-align: center;
`

function App() {
  return (
    <Container>
      <GlobalStyle />
      <div>
        <Title>Hello World! </Title> <Title>Hello World!
        <Description>This is a sample of ES6 + TypeScript + React for Electron.</Description
      </div>.
    </Container>
  )
}

export default App

As you can see here, you can write code almost the same way as you can run React on the web: if you want to use Redux or Hooks in your project, you can do in same way.

IPC (The communitation style between two processes)

By now, you may understand the difference between the main process and the renderer process, but as a matter of course, when you actually develop, the communication (state synchronization) between the main process and the renderer process. In the case of Electron, this is accomplished by IPC. It is basically done by registering a listener in the main process and waiting for the renderer process to send messages to the listener.

To borrow an example from official

Main Process.

const { ipcMain } = require('electron')
ipcMain.on('asynchronous-message', (event, arg) => {
  console.log(arg) // prints "ping"
  event.reply('asynchronous-reply', 'pong')
})

Renderer Process.

const { ipcRenderer } = require('electron')

ipcRenderer.send('asynchronous-message', 'ping')
ipcRenderer.on('asynchronous-reply', (event, arg) => {
  console.log(arg) // prints "pong"
})

As shown in the above example, the main process registers a listener named "asynchronous-message " in the main process and sends a request from the renderer process at any given time.

So, in summary, the main process will be the parent process of the app, and the parent-child communication will be done using the IPC communication method

Let's get back to the main topic.

** When we make a complex application, the main process that manages the renderer process is going to be quite large and complicated, isn't it? **

** It's hard not to be able to share constants and other things between the renderer and the main process. **

This was my big concern about Electron app. That is wahy I have explained about the main process and the renderer process in the hope that you will understand what I mean.

So, in order to solve this problem, I created a template for both the main process and the renderer process that can be applied to ES6 (especially import).

Configure Webpack to call the main process with the ES6 syntax

From now on, I will focus on how to convert Electron to ES6.

First of all, the renderer process is really easier, such as importing, reacting and installing TypeScript.

As I wrote earlier, the renderer process can take over the know-how of web development almost as it is, so you can do something like create-react-app, and then you will be able to do it by googling. You can build an ES6 + React + TypeScript environment in just a few minutes, just by imitating the way you would find the article.

But for the main process, there are not so many articles about it, and you have to dive into the webpack world by yourself to configure it and use ES6 syntax. (It's very useful for writing react-script and renderer processes, but I ejected it because it's black-boxed and seems to be hard to configure).

The result is the repository I mentioned earlier.

The key part of webpack configuration is to output entry points of main process and renderer process separately.

The code for the main process is put together under src/main and the renderer process code is put together under src/renderer beforehand. The following is the configuration.


module.exports = (env = {}) => {
  return [
    {
      name: 'main',
      ... .defaultConf(env),
      entry: path.resolve(__dirname, '... /src/main'),
      output: {
        path: path.resolve(__dirname, '... /public'),
        filename: 'main.js'
      },
      target: 'electron-main'
    },
    {
      // for renderer
      name: 'renderer',
      ... .defaultConf(env),
      entry: path.resolve(__dirname, '... /src/renderer'),
      output: {
        path: path.resolve(__dirname, '... /public'),
        filename: 'renderer.js'
      },
      target: 'web',
    }
  ]
}

With this configuration, the renderer process code is rendered as public/renderer.js and the main process code is rendered as public/main.js. In this way, Electron can be converted to ES6 by bundling the renderer process and the main process code separately.

It is also convenient to use webpack-dev-server to distribute the renderer process. In the repository, we deliver code from http://loalhost:8080 and can hot-reload it if we change the code during development.

Here are the commands for developing in the repository (scripts in package.json)

"scripts": {
  "start": "yarn build:main && electron ." ,
  "start:inspect": "yarn build:main && electron --inspect=5858 ." ,
  "start:inspect-brk": "yarn build:main && electron --inspect-brk=5858 ." ,
  "develop": "webpack-dev-server --host 0.0.0.0 --hot --config config config/webpack.config.js --config-name renderer",
  "build:main": "webpack --config config config/webpack.config.js --config-name main"
},

When you develop Electron, you need to set up a server of the renderer process (webpack-dev-server) with the yarn develop command. In parallel, it starts the main process as yarn start in a separate window (as you can see, it builds and starts electron based on the built files.) The main process is launched as yarn start (as you can see, once built, it launches electron from the built files) in a separate window.

In this development environment, the webpack-dev-server automatically hot-loads the code and reloads it for the renderer process only if you fix it a little bit. The main process code needs to be restarted by yarn start after you modify the code.

Ideally, it would be nice to be able to hot reload the main process code as well, but I'll give you the repository at this point. (If you want to hot reload it, use nodemon.)

Summary

So, I wrote a story about how I set up the environment to be able to develop in ES6 syntax and TypeScript for both the main process and the renderer process.

I like javascript, but it's a bit troublesome to set up this kind of environment. If you don't care about ES6, you may not need such a setting. It's important to be stress-free while developing because those troublesome setting affects my motivation to write the code.

It is fun and refreshing to see the application I made working on the desktop, but there is no best practices for Electron system design (as long as I know) like the web. It's not easy. It seems to be good to make the main process as the server side of the web (or rather, as an API), . But it runs on the same place so it's hard to think about the design because you can share the model and so on. (I'd like to know if there are best practices somewhere...)

However, once the JS environment is set up like this one, you can write code comfortably afterwards, so if you are annoyed with building an environment, I hope you can use it while referring to this repository or forking it.

ElectronでReact+TypeScript+ES6開発環境を整えてみた

Sun, 14 Jul 2019 00:00:00 GMT

久しぶりの投稿です。ここのところ色々と変化が起きそうな予感しておりその対応でこちらを更新できずにいるのですが、できればこちらも定期的に更新できれば良いかなと思っております。

ここのところ個人の開発でelectronを触るのでそこらへんを書こうと思います。すっごい昔にデスクトップでもアプリ作れたら楽しいよねというのりでちょっとElectronを触ってみてはいたのですが、 electronはその時以来になります。

今みるとこの記事2017年とかに書いてるんですね。二年前とかなのでそこまで昔ではないのかもしれませんが、個人的にはこの間に正社員からフリーランスへの転身を経て生活スタイルがだいぶ変わったので、すっごい昔に感じます。

この頃はReactも触っていなかったので生jsで書いていたと思うのですが、今回久しぶりにelectronで何かアプリ作ろうかなと触ってみたら当然のごとくReact入れたいね。ってなりました。

React入れるとTypeScript入れたいねってなって、create-react-appと少々の設定でTypeScriptを入れてみたりしました。ここまではなんのこともないのですが、だんだんとメインプロセス周りがimport文でかけないことが気になってきます。

アプリが小さいうちは、メインプロセスが古い書き方担っているのに目をつむることもできるのですが、electronのAPIを使ってwindowをいじったり、もろもろをしているとだんだんとコード量も増えてきて辛くなってきます。さらには、レンダラープロセスとメインプロセスで共通の定数を使わないといけないとなるとexport.modulesとか古い書き方で書いてあげないと共通で使えないなどの問題が出てきます。

そこで今回は、React + TypeScript + ES6 で動かすElectron用テンプレートリポジトリみたいなものを作りました。

jestなどは入れていないですが、普段プロジェクトで慣れているReact + TypeScript + ES6(慣れている人はですが）で気軽にElectronを始めることができます。

メインプロセスとレンダラープロセス

Electronを深く知らない方は、メインプロセスとレンダラープロセスというのが何かわからないと思うのですが、アプリケーションに対して一つだけ存在するプロセスでElectronを起動した時に最初に起動するのがメインプロセスです。

対して、ウィンドウごとに立ち上がるプロセスはレンダラープロセスと呼ばれ、こちらはアプリケーションに対して複数存在するプロセスです。

メインプロセスはその名のごとく、readyイベントやall-window-closeイベントなどを拾ってコールバックを実行したり、新しいウィンドウ（レンダラープロセス）を作成したり、特定のウィンドウに対して操作を行うなど各レンダラープロセスを取り仕切ることができます。

メインプロセスのコード例(エントリーポイント)

下記は先ほど紹介したリポジトリのエントリーポイントですが、アプリの起動するタイミングでBrowserWindowのインスタンスを生成し（レンダラープロセスを起動）、全てのウィンドウが閉じられたらアプリ自体を終了する。というような処理を書いています。

より複雑なアプリを作るとレンダラープロセスでの入力を受けて新しいウィンドウを作るといった処理も必要になるので、メニューを変更したり、ウィンドウを閉じたりメインプロセスでしかできない処理はこちらに書くことになります。

import { app, BrowserWindow } from 'electron'

const onReady = async () => {
  let win: BrowserWindow | null
  win = new BrowserWindow();
  win.loadURL('http://localhost:8080');

  // ChromiumのDevツールを開く
  win.webContents.openDevTools();

  win.on('closed', function() {
    win = null;
  });

}
app.once('ready', onReady)
app.on('window-all-closed', () => { app.quit() })

レンダラープロセスのコード例(エントリーポイント)

一方ElectronのレンダラープロセスはほぼWebサービスのフロント画面と考えてもらえればよく、Web開発のノウハウのほとんどがそのままこちらに転用でき、Reactもレンダラープロセス上で動きます。

import React from 'react'
import styled from 'styled-components'
import { GlobalStyle } from 'styles/Index'

const Container = styled.div`
  max-width: 200px;
  height: 100%;
  width: 100%;
  margin: auto;
  display: flex;
  align-items: center;
}
`

const Title = styled.h2`
  text-align: center;
`

const Description = styled.p`
  text-align: center;
`

function App() {
  return (
    <Container>
      <GlobalStyle />
      <div>
        <Title>Hello World!!</Title>
        <Description>This is a sample of ES6 + TypeScript + React for Electron.</Description>
      </div>
    </Container>
  )
}

export default App

こちらを見てわかるようにwebでReactを動かすのとほとんど変わりなくコードを書いていくことができます。Reduxを入れたければ、webと同じようにRedux入れれば良いし、Hooksで書きたければHooks で書くも良しということでここではWeb開発のノウハウがそのまま使えます。

IPC通信

ここまでで、なんとなくメインプロセスとレンダラープロセスの違いはわかってきたかと思うのですが、実際に開発を行なっていると当然のごとくこのメインプロセスとレンダラプロセスの通信（状態の同期）が必要になってきます。Electronの場合これをIPC通信という方法で実現しているのですが、基本的にメインプロセス側でリスナーを登録して待ち構えて、レンダラープロセスで任意のタイミングでリスナーに対してリクエストを送るという形になります。

公式から例を借りてくると

メインプロセス

const { ipcMain } = require('electron')
ipcMain.on('asynchronous-message', (event, arg) => {
  console.log(arg) // prints "ping"
  event.reply('asynchronous-reply', 'pong')
})

レンダラプロセス

const { ipcRenderer } = require('electron')

ipcRenderer.send('asynchronous-message', 'ping')
ipcRenderer.on('asynchronous-reply', (event, arg) => {
  console.log(arg) // prints "pong"
})

のように、メインプロセスで**"asynchronous-message"**というリスナーを登録して、任意のタイミングでレンダラープロセスからリクエストを送る形になります。

というわけでここまでで、ざっくりまとめると、メインプロセスはアプリの親プロセスとしてレンダラープロセスをまとめて、親子の通信はIPC通信という方法を使ってデータの同期(通信）を行うというところまで説明できたかと思います。

ここまでだと完全にElectronのアーキテクチャの話になってしまって脇道にそれているのですが、本題に話を戻すと、それなりに複雑なアプリケーションを作るとなると「レンダラープロセスを取り仕切るメインプロセスのコードって大きくなるよね」そこがrequireとかで書かれていてレンダラープロセスとかと違う書き方で実装するとなると **「レンダラーとメインで共通で使う定数とか共有できなくて辛いよね。」**というのをわかってほしくてここまで長々とメインプロセスとレンダラープロセスについて説明してきました。

ということで、今回はこの問題を解決するべくメインプロセスもレンダラープロセスもES6(特にimport)でかけるテンプレートを作ってみました。

メインプロセスをES6構文でかけるようにWebpackを設定

前振りが長くなりましたが、ここからはElectronをどうやってES6化して書くかということにフォーカスして説明していきます。

まずはじめにレンダラープロセスの方はimport文かけるようにしたり、reactのインストール、TypeScriptのインストールとかは本当に簡単です。

先ほど書いたようにレンダラープロセスはweb開発のノウハウをほぼそのまま引き継げるのでcreate-react-appとかして、Google先生で検索した上位の記事の見よう見まねでものの数分でES6 + React + TypeScriptの環境を構築することができます。

しかし、肝心のメインプロセスの方は、そういった記事も少なく、自らwebpackの世界に乗り出し設定を行いES6の構文を使えるようにしていかなければなりません。 (react-scriptとかレンダラープロセス書く分にはとても便利なのですが、ブラックボックス化されていて設定しんどそうなのでejectしました。）

結果完成したのが先ほども載せたこちらのリポジトリです。

https://github.com/version-1/gin-gorm-sample

Electron + React + TS + ES6(メインプロセスも含め)　の構成で何かアプリ作りたいのであれば割と始めやすいリポジトリになっているかと思います。 JavaScriptのプロジェクトであればだいたい使うであろうlodashやmomentあたりのユーティリティライブラリも入れておきました。(styled-componentも個人的な趣味ですが入れてます)

webpackの設定の肝の部分はメインプロセスとレンダラープロセスのjsを別々に吐き出すことです。

あらかじめメインプロセスのコードはsrc/main配下にまとめておいて、レンダラープロセスのコードはsrc/renderer配下にまとめておきます。その状態でwebpackを設定すると下記のような設定になります。


module.exports = (env = {}) => {
  return [
    {
      name: 'main',
      ...defaultConf(env),
      entry: path.resolve(__dirname, '../src/main'),
      output: {
        path: path.resolve(__dirname, '../public'),
        filename: 'main.js'
      },
      target: 'electron-main'
    },
    {
      // for renderer
      name: 'renderer',
      ...defaultConf(env),
      entry: path.resolve(__dirname, '../src/renderer'),
      output: {
        path: path.resolve(__dirname, '../public'),
        filename: 'renderer.js'
      },
      target: 'web',
    }
  ]
}

この設定だとレンダラープロセスのコードはpublic/renderer.js、メインプロセスのコードはpublic/main.jsとして吐き出されます。 Electronではこのようにレンダラープロセスとメインプロセスのコードを別々にバンドルすることでES6化することができます。

また、レンダラープロセス側はwebpack-dev-serverで配信する形にすると開発の時も便利です。リポジトリでは、http://loalhost:8080 からコードを配信して、開発中にコードを変更したらホットリロードができる構成にしています。

こちらがこのリポジトリで開発する時のコマンドになるのですが（package.jsonのscripts)

"scripts": {
  "start": "yarn build:main && electron .",
  "start:inspect": "yarn build:main && electron --inspect=5858 .",
  "start:inspect-brk": "yarn build:main && electron --inspect-brk=5858 .",
  "develop": "webpack-dev-server --host 0.0.0.0 --hot --config config/webpack.config.js --config-name renderer",
  "build:main": "webpack --config config/webpack.config.js --config-name main"
},

自身がElectronの開発を行う際には、yarn developでレンダラープロセスのサーバ(webpack-dev-server)を立ち上げ、それと並行して別ウィンドウでyarn start(見てわかるように一旦ビルドしてビルドされたファイルをもとにelectronを起動しています。)としてメインプロセスを立ち上げています。

この開発環境はレンダラープロセスに限っては、コードをちょっと直しただけで自動でwebpack-dev-serverがホットリロードで再読み込みしてくれるのですが、メインプロセス側のコードはコードを修正したらyarn startで再度サーバを立ち上げ直す必要があります。

理想をいうとメインプロセス側についてもホットリロードできると良いですが一旦ここまででレポジトリをあげておきます。 (ホットリロードしたい方はnodemonなどを使って頂ければ実現できるかと思います）

まとめ

というわけで、メインプロセスもレンダラープロセスもES6のシンタックスかつTypeScriptで開発が行えるように環境を整えた話を書きました。

javascriptは割と好きなのですが、こういった環境設定が多少面倒くさいですね。。ES6とかこだわらなければそこまで設定もいらないかもしれないのですが、DXというか開発をしている時の気持ち良さ（というよりストレスレスであることが大事そう）ってやっぱりコードを書く時のモチベーションとかに影響するのでついついこだわってしまいますね。

最近個人でElectronのアプリをつくっていて、自分で作ったアプリがデスクトップで動くのは新鮮で楽しいのですが、ElectronはWebみたいに決まった設計の形みたいなのがなく逐一考えながら実装していかないといけないので、なかなか大変ですね。メインプロセスをWebでいうサーバサイド（というか一APIとして）作っていくのが良さそうなのですが、同じプラットフォームで動くのでモデルを共有できるとかもなるので、設計考えるのが大変です。（どこかにベストプラクティスがあれば知りたい・・）

ただ、JSは今回のように一旦環境を揃えられるとあとは快適にコードを書いていけることが多いので、環境構築めんどくさいという方はこのリポジトリを参考にしたりフォークしたりしながら使って頂ければと思います。

では。

Tried to Create Crud API Gin+Gorm+GraphQL(gqlgen)

Sat, 15 Jun 2019 00:00:00 GMT

I have been studying after coming Reiwa era. Now, I tried to develop web API with Go and GraphQL.

My Repository. gin-gorm-gqlgen-sample I usually develop backend with Ruby on Rails so I'm not famillier with golang and it takes long time to create this repository...

I will explain about entire flow. Next, I will talk about stack point I was working in.

Technolodies I used

Followings are technolodies I used this time,

Docker
Dep (package manager)
Gin (WAF)
Gorm (ORM)
gqlgen (GraphQL Library)

Gin

Gin is one of the Go language WAF. It have got the most star on github in go lang WAF(as far as I know).

Gorm

Gorm is Go Lang ORM. According to web articles, its interface is like Rails's ActiveRecord. I am familliar with Rails so I choose this library.

Dep

Dep is pacakge manager. I need to "go get" to install some libraries but it seems like disturbing my Dockerfile. So I used dep

gqlgen

gqlgen is GraphQL server library. There are some graphql libraries for golang such as graphql-go/graphql. But I selected gqlgen becuase I really like a point of generating code after I defined schema.

99designs/gqlgen

If you use gqlgen, you can proceed your development with following procedure.

Define Schema
Write logic about query in resolvers

In this process, you can focus on writing logic and you don't need to write boring code because gqlgen genearate code based on your schema.

Entire Flow

The gqlgen sample in the document is baout Todo List. If you will read "Getting Start", you start it easily. But, I need to do something when you use it with Gorm or you develop CRUD. So, I will explain those way, So, I will explain those way.

Install gqlgen with dep

You can install gqlgen by "go get" but if you use dep, you have to prepare wrapper scripts to generate boilerplate.

scripts/gqlgen.go

package main

import "github.com/99designs/gqlgen/cmd"

func main() {
	cmd.Execute()
}

If you do this,

$go run scripts/gqlgen.go init

you will be able to execute it like this. When you finished to write scripts, make files you need on gqlgen.

$go run scripts/gqlgen.go init

Gqlgen will generate followings files.

gqlgen.yml ・・・ Configure file. you write the configure fo generated code.
genereated.go ・・・ When you define schema and execute scripts, this file will be generatted. Must not edit manually because it is generated.
models_gen.go ・・・ This file is also generated from schema. Must not edit manually because it is generated.
resolver.go ・・・ This is generated if you yet to create this name file.
server/server.go ・・・ Entrypoint.

When you generate code, excecute following command and install pacakges.

dep ensure

Create Entry Point for Gin

I have to prepare entry point for gin if you want to use gin. prepare two endpoints.( for playground and main)

import (
  "github.com/99designs/gqlgen/handler"
  "github.com/gin-gonic/gin"
)

// Defining the Graphql handler
func graphqlHandler() gin.HandlerFunc {
  h := handler.GraphQL(NewExecutableSchema(Config{Resolvers: &Resolver{}}))

  return func(c *gin.Context) {
    h.ServeHTTP(c.Writer, c.Request)
  }
}

// Defining the Playground handler
func playgroundHandler() gin.HandlerFunc {
  h := handler.Playground("GraphQL", "/query")

  return func(c *gin.Context) {
    h.ServeHTTP(c.Writer, c.Request)
  }
}

func main() {
  // Setting up Gin
  r := gin.Default()
  r.POST("/query", graphqlHandler())
  r.GET("/", playgroundHandler())
    r.Run()
}

Prepare Gorm Model

Next, I will define model which are used on schema definition. I put it on internal/models according to go language standard layout.

// user.go
package models

import (
	"time"
)

type User struct {
	ID        int
	Name      string
	Todos     []Todo
	CreatedAt time.Time
	UpdatedAt time.Time
}

// todo.go
package models

import (
	"time"
)

type Todo struct {
	ID        int
	Text      string
	Done      bool
	UserID    int
	User      User
	CreatedAt time.Time
	UpdatedAt time.Time
}

Certainly I think it is preferd to wirte it with embed (please refer to Gorm documents) but errors occur when I excecuted. I wrote all attributes..(I would like to know better way..)

// todo.go
package models

import (
	"time"
)

type Todo struct {
  gorm.Model
	Text      string
	Done      bool
	UserID    int
	User      User
}

If you finish to define your model, you have to wirte mapping of model in gqlgen.yml. Followings is definition in this case.

models:
  Todo:
    model: gin_graphql/internal/models.Todo
  User:
    model: gin_graphql/internal/models.User

Define Schema

What I introduced until now is to prepare to develop in schema drriven, I'll to write the code and logic for api from now.

type Todo {
  id:   Int!
  text: String!
  done: Boolean!
  userID: Int!
  user: User!
  createdAt: Time!
  updatedAt: Time!
}

type User {
  id: Int!
  name: String!
  createdAt: Time!
  updatedAt: Time!
}

type Query {
  todos: [Todo!]!
  users: [User!]!
  todo(input: FetchTodo): Todo!
}

input NewTodo {
  text: String!
  userId: Int!
}

input EditTodo {
  id: Int!
  text: String!
}

input NewUser {
  name: String!
}

input FetchTodo {
  id: Int!
}

type Mutation {
  createTodo(input: NewTodo!): Todo!
  updateTodo(input: EditTodo!): Todo!
  deleteTodo(input: Int!): Todo!
  createUser(input: NewUser!): User!
}

scalar Time

Above is schema.graphql to realize CRUD. You have to use graphql syntax to write this. Processes to change resouce is wrriten in Mutations and Processes to read it is wrriten in Query. And Types you need is also defined in schema.graphql.

Until now, you got reday to generate code and you start to edit resolver.In resolver, IO is defined by schema.graphql and it is generated automatically. So you focus on writing logic between input and output.

Implemntaion Resolver

In resolver, write code to get data from database or create some records. You have to know that resolver is not overwritten when it is already exist.

Following is resolver I wrote. I can't explain all because it is about gorm and bored for us.


type Resolver struct {
}

func (r *Resolver) Mutation() MutationResolver {
	return &mutationResolver{r}
}
func (r *Resolver) Query() QueryResolver {
	return &queryResolver{r}
}

type mutationResolver struct{ *Resolver }

func (r *mutationResolver) CreateUser(ctx context.Context, input NewUser) (*models.User, error) {
	user := models.User{
		Name: input.Name,
	}
	db.Create(&user)
	return &user, nil
}

func (r *mutationResolver) CreateTodo(ctx context.Context, input NewTodo) (*models.Todo, error) {
	todo := models.Todo{
		Text:   input.Text,
		UserID: input.UserID,
		Done:   false,
	}
	db.Create(&todo)
	return &todo, nil
}

func (r *mutationResolver) UpdateTodo(ctx context.Context, input EditTodo) (*models.Todo, error) {
	todo := models.Todo{ID: input.ID}
	db.First(&todo)
	todo.Text = input.Text
	db.Model(&models.Todo{}).Update(&todo)

	return &todo, nil
}

func (r *mutationResolver) DeleteTodo(ctx context.Context, input int) (*models.Todo, error) {
	todo := models.Todo{
		ID: input,
	}
	db.First(&todo)
	db.Delete(&todo)
	return &todo, nil
}

type queryResolver struct{ *Resolver }

func (r *queryResolver) Todo(ctx context.Context, input *FetchTodo) (*models.Todo, error) {
	var todo models.Todo
	db.Preload("User").First(&todo, input.ID)
	return &todo, nil
}

func (r *queryResolver) Todos(ctx context.Context) ([]models.Todo, error) {
	var todos []models.Todo
	db.Preload("User").Find(&todos)
	fmt.Println(todos[0].User)
	return todos, nil
}

func (r *queryResolver) Users(ctx context.Context) ([]models.User, error) {
	var users []models.User
	db.Find(&users)
	return users, nil
}

Run

Finally, you can run your code if you finish process I introduced. The entrypoint of the repositry I prepared is cmd/app/main.go so you can run following command.

ENV=development go run cmd/app/main.go

We should pass env in this command because I implemented it to load configuration by env. When you success to run the server, you can try it on http://localhost:8080.

Stack Points

Next, I will write about points I stacked while I was building.

How can I define type of Time like CreatedAt and Updated?

Schema Types are only 5.

ID
Int
Float
String
Boolean

So we have to define types we need such as Date.

When I create this sample, I'm stack here but I found gqlgen provide Time Type so I can use it.

You only do like this as above schema definition.

scalar Time

After you declare the type, the type is mapped to Go Embeded tim.Time Type. Gqlgen support Map, Upload and Any type so if you want to use their type, only declare it with scalar declaration.

Error Occured in Gorm Model while I generate code.

This problem is not resolved. I got away with it by workaround though.. I defined a model with gorm embed type but error occured during generation...

type User {
  gorm.Model
  name
}

I got away with writing all attributes but it is not good. If anyone know better way, I would like to teach me.

Get association model while I get list

This is about not GraphQL but Gorm. I often get list which include associated model so I tried it in this sample, too. That is simpler than I expeceted. All you need is to add fields to struct.

type Todo {
  id:   Int!
  text: String!
  done: Boolean!
  userID: Int!
  user: User!
  createdAt: Time!
  updatedAt: Time!
}

For example, when you define Todo model, you can do that by adding userId and user fields to Todo model.

db.Preload("User").Find(&todo, input.ID)

And add this line to resolver.

You already write preload clasue so you already solved N+1 problem. This is sql when I execute.You can make sure that users query is preloaded.

(/app/src/gin_graphql/resolver.go:65)
[2019-05-14 15:27:07]  [0.90ms]  SELECT * FROM `todos`  WHERE (`todos`.`id` = 2) ORDER BY `todos`.`id` ASC LIMIT 1
[1 rows affected or returned ]

(/app/src/gin_graphql/resolver.go:65)
[2019-05-14 15:27:07]  [2.65ms]  SELECT * FROM `users`  WHERE (`id` IN (1)) ORDER BY `users`.`id` ASC
[1 rows affected or returned ]

Wrrap Up

I tryied to build hot stacks of Web API and Graphql.

I currently feel the limit of REST API while I develop system with it so I feel stronger the good points of graphql. In REST API, When I create new endpoint, I have to write code to request that endpoint in client-side.

In GraphQL, if you define schema once, you can fetch necessary resouce anytime. When I develop api in REST, I think how I don't depned on frontend but I often need to change code of server-side code when the front is changed.

I think such problems will be solved by GraphQL (many people say so though..) Certainly, I learn it deeply and I would know that drawbacks and I can never know that now but I can feel that potential.

If you are familiar with REST or are sick of creating Web API, try GraphQL

Thank you,

6月の土曜日に3人と英語面接したエンジニアの話

Mon, 10 Jun 2019 00:00:00 GMT

しばらく更新が途絶えていましたが、久しぶりの投稿です。

ここのところ仕事が忙しくなったり、ポートフォリオサイト作っていたり、当サイトの英語対応を進めていたりしてなかなか更新が出来ていませんでした。

繁忙期というのはうまく分散できなくて何故かまとめてハードなタスクが降ってくるものですが、今回はその中の一つで結構ヘビーな6月の土曜日に英語で３人と立て続けに面談をするというイベント？に参加してきました。

自身英語での面接は初めてでチャレンジグだった上に中々無い経験で楽しめたので、記事にまとめておきます。

面談に至った経緯

実のところここ最近フリーランスに飽き始め、飽き始めたというと語弊があるのですが1年ちょっとフリーランスをやって収入面でもタスク面でもだいぶ安定してきて「このまま普通にやってたらあと10年くらい普通よりちょっと高めの収入を維持しながらやってけるんじゃね」

とほのかに思うと同時に自分の成長の鈍化を感じ始め「そういえば最近、全然バリュー出てないヤバい！とか全然わからない笑。全然できない笑。みたいな窮地に立たされてないなー」

というのに気づきました。

できれば半年前くらいの自分ショボwくらいの感じで過去の自分を恥じれるくらいなにかしらレベルアップし続けるのが理想なので、いまいち満足できない日々が続いていました。

そんな悶々としている中であるリクルーターさんから某外資企業がエンジニアを探してるので面談しませんか？というお誘いがLinkedinであり、

その企業名が以前から知っていて少し興味があったので、じゃあ話を聞いてみるかということでとりあえずリクルーターさんと面談することとなりました。

リクルーターさんとの面談は例によって自分の経歴の説明とやりたいことの説明、リクルーターさんからの企業の説明等々を行いました。

その話の中でその某企業さんが6月の土曜日に1日使って、３人の人と面談をして採用するかどうかを決める。しかも面接は全部英語。英語での面接、さらにプログラミングのアルゴリズムの話をしたりしないといけないという

「ちょっとどういうこと？！」

な内容なのですが、話を聞く限りインターナショナルなチームでグロース段階の面白そうな環境にあるということで、不安ではありましたがチャレンジしてみることにしました。

はじめての英語レジュメ作成

ということでその企業さんにアプライすることとなったのですが、「やべ、英語の面接の準備しなきゃ」なんて面接に進めるかもわからないのに面接のことを考えている私をよそにリクルーターさんからの「それでは後ほど英語のレジュメを送って頂けますか？」という先制パンチがありました。

英語でのレジュメ作成なんてやったことなかったのですが、ネットで色々調べながら見よう見まねでなんとかレジュメを完成させ、「はじめてのレジュメなんですけどこんな感じでいいんですかね？」と恐る恐るリクルーターさんにメールでレジュメを提出すると

「ありがとうございます！それではこちら先方にお送りしますね！」というはじめてのレジュメをスルーしたビジネスライク？な返信が返ってきました笑。(まぁそんな細々修正してもしょうがないしね。。)

その後なんかレジュメだけだと物足りないし、フリーランスとしてもポートフォリオとかあると便利だしなーなんて考えてポートフォリオサイトをちゃちゃっと作って後追いで提出しました。

レジュメとポートフォリオを提出してからしばらくしても連絡がなかったのでダメだったのかなー。なんて考えながらいたのですが、次の週の後半くらいに返信があり、どうやら書類ベースでは選考を通過したそうで無事6月の土曜日に一気に三人と英語でテクニカルな面談をするという鬼畜な催し(慣れてる人にはどうってことないんだろうけど。。)に招かれました。

いざ面接

面接に招待されてから当日まで4日間くらいしかないというまたまた鬼畜なスケジュールでろくな準備もできないまま面接当日を迎えました。

面接は朝の10時からで3人と面談と聞いていたので、だいたい3時間、4時間程度かなと思っていたのですが会場に到着すると10人ほど他の候補者もいたのでなるほど結構な長丁場になりそうだなと感じました。

案の定スケジュールは押していて、一人目の面談が終わったのが13時過ぎという感じでだいぶ長い待ち時間がありました。

待ち時間の間に面接官の方に簡単なwebテストとを受けてと言われ、言われた通りと開いてみると所要時間45分で回答するというそれなりに精神ポイントを削られるテストを受けました。詳細なテスト内容は流石に書けないのですが、フロントエンド向けのテストで色々な概念に関するメリット・デメリットを挙げてそれについて説明したり等々でした。

全部英語で回答も英語なので結構体力が削られたのですがなんとか時間内に全て回答してwebテストを終了させました。

テストを受け終わった後、最初の面接に案内される間に人事の方から「テストの結果良かったよ！」と言われたので自分で割と不十分なところも感じていたのですがまぁ結果は良かったようです。

1人目との面接

というわけで、無事Webテストを終わらせ一人目の方との面談があったのですが面談は個室のような場所に通されるでもなく、割と開けたスペースに案内されそこで面接官の方と面談しました。

面接官と書くと堅苦しいですが、お互いカジュアルな格好でコワーキングスペースでMackbook片手にという感じだったのでいわゆる面接いうほど堅苦しくはないです。

面接自体は全てがテクニカルな質問で、これまで受けてきた面接でのなんで志望したの？とか人となりを聞くような質問は皆無でした。

質問されたのはJavaScriptやReact等々の仕様などなど。

回答自体は全て完答出来たかというとそうでもないのですがまぁ出来は悪くないかなという印象でした。英語での会話も結構文法がズタボロで何度か聞き返したりもしましたが、最低限のコミュニケーションはとれたかなと思っています。

テクニカルな質問が終わるとこちらからの質問タイムがあったのですが、面接官がエンジニアなので普段どういう開発をしてるんですかー？やどういう働き方をしてますかー？等々実際の開発の雰囲気を聞く質問をしました。

話を聞く限り面接官はWebの質問をバリバリしてきたのですが、話を聞く限り実はネイティブエンジニアだそう笑。ただ、React Nativeを使っているのでJavaScritはわかるようでした。 (expoつかっていないそうなので、大変そうだなーなんて考えつつ）

2人目の面接

2回目の面接は前述した通りスケジュールが押して、1回目の面接が終わったのが13時過ぎだったのでお昼休憩を挟んで14時半から面接をしました。 (余談ですがお昼休みはスマホがお亡くなりになりかけていたので充電器探しと電源の使えるカフェ探しに奔走していました。）

面接内容は基本的なアルゴリズムに関する問題を聞かれて、それを紙に書いて回答するといった内容でした。

基本的なアルゴリズムと言った割には結果が壊滅的で、面接官のインド系訛りが強く、英語聞き取れない、、問題理解できない、、そもそもアルゴリズムへの理解が甘く問題解けないという感じで散々でした。

データ構造とアルゴリズムは元々苦手意識があり、今まで避けてきた部分があったのですが、今回の試験結果を見る限りちょっとちゃんと勉強しないとダメですね。。twitter等々でも議論されてましたが、やっぱり基本的なCSの知識がエンジニアの根幹を支えるスキルになるので基本的な所はやっぱりちゃんとやっておきたい所です。

面接は散々でしたが面接官のエンジニアの方は親切で自分の英語スキルに合わせてゆっくり話しをしたり問題の説明を例を出しながら説明したり丁寧で凄い好印象でした。

最後の面接

最後の面接は、エンジニアチームのマネージャーとの一対一の面談です。

マネージャーというとちょっと権威がある感じかと思うんですがマネージャーさんも物腰柔らかで、自分の辿々しい英語に耳を傾けてくれました。

面接ではこれまで関わってきたシステムについての説明をしたり、会社に興味を持った理由などなどを話しました。

聞かれた事が結構サーバー、インフラ寄りでどうやってトラフィック捌くかとかの話になってちょっとこれまでそこまでトラフィックが問題でインフラエンジニアのいないチームで働く機会が少なく、雲行き怪しげではあったのですが、マネージャーさんの人柄もあってか面接自体は終始良い雰囲気ではあったのかなと思ってます(というかそうであってほしい。)

まとめ・総括

ということで無事3人との面談も終えて帰宅の途についたのですが、やっぱり英語スキルが低いせいで十分に説明できてない感は否めませんでした。

なんていうか頭でわかってるんだけど英語で表現できないもどかしさが常にあって内心「グァー」ってなりながら英語で会話してました。

全然関係ないんですけど、新しいプログラミング言語を学び始めて 頭では処理の方法がわかってる、あるいは慣れ親しんだ言語ではわかるんだけど、この言語での書き方がわからない！！ っいうときのフラストレーションに非常に似てますね。最近自分がGoを書いている時の感じに似ています。

話を戻すと、2人目の面接官にも「もし君がジョインするなら英語の勉強必要ダネ。」とも言われたので本当に英語はネックになりそうです。

そんな感じの未熟な英語スキルではあったのですが、個人的には思ったよりやれたかな感は多少ありました。(まあ初めてだし笑、あまり自分を責めてもしょうがないし)

技術的にわかることはやっぱり英語でも端的に説明してあいてにも解ってもらえるのですが、技術的にわからない、不安な部分はやっぱり説明の精度が下がります。日本語でも同じだと思うのでこればかりはしょうがないですが、技術力＋語学力の底上げは永遠の課題として着実に伸ばしていきたいですね。

面談の結果はまだ出ていないので不明ですが、あまり時間待たずに分かるはずなので結果わかればまたこちらに書くかもしれません。受かってたら結構嬉しいのですが、まぁ落ちてても一つ経験できたし英語面接の練習とか技術的なところの課題とか発見できたし良いかなという感じです。(こうして記事にもなってますし)

手応え的にはちょっとわからないですし、企業さん側がどれくらいの採用基準なのかなっていうのに寄るのかなと思っています。やっぱりエンジニアは足りてないらしくて、人は欲しそうですがそのレベルに自分が達していたかどうか正直わかりません。まぁコード書きながら、寝ながら待ちます。

という感じでただただ自分の体験を共有しただけではありますがここまでで締めさせていただきます。

では。

Gin+Gorm+GraphQL(gqlgen)でCRUDできるAPIをつくってみた

Mon, 13 May 2019 00:00:00 GMT

元号ももう令和に代わり粛々とGoの勉強を続けているのですが、今回はGOとGraphQLを使って CRUDできるAPIを作ってみました。

gin-gorm-gqlgen-sample そもそもGOに慣れていなかったり各種ライブラリの情報が少なかったりで結構時間かかりましたが、なんとかそれらしきものができたのでリポジトリを共有しておきます。

前回の記事でも、最初にながれを説明して詰まったところを最後にまとめて終わりという形だったので今回も同じ形でいければななんて思っています。

サンプルを作るにあたり色々と情報を漁ったのですがGormとgqlgenを組み合わせの情報が少なく苦労したのでそこらへんの情報ものせていければ。

使用技術

今回GraphQLサーバ構築に使った大きな部分の技術をまとめると

Docker
Dep (パッケージ管理)
Gin (Webフレームーク)
Gorm (ORM)
gqlgen (GraphQLサーバライブラリ)

となります。gqlgen以外は前回の記事とほぼ一緒なのでかぶっているやつは説明しません。

gqlgen

gqlgenはgraphQLのサーバライブラリです。goのgraphQLサーバ用のライブラリはgraphql-go/graphql などもあるのですが、スキーマドリブンで開発が進められそうな99designs/gqlgenを使ってみました。

graphql-goの方はinterface{}が大量にでてきて、せっかくの型情報が有効に使えず微妙なので使うのはやめておきました。 gqlgenを使うと

schemaを定義
resolverにクエリに対するロジックを定義

という順序で開発を進められresolverの実装に集中できるので、最初の慣れは必要ですが慣れてくると軽快に実装を進められそうな感触はうけました。

実装の流れ

gqlgenのサンプルにあるのは、TodoリストでGetting Startを見ればするっと始めることができるのですが、そこから一歩進んでGormと一緒に使ったり、CRUDしたりするとなるとまた一工夫必要なので簡単な流れを書いていきます。

gqlgenをdepでインストール

depを使わなければ普通にgo getすれば良いのですが、dep使う場合はschemaからボイラープレートを吐き出すためのラッパースクリプトを用意する必要があります。

scripts/gqlgen.go

package main

import "github.com/99designs/gqlgen/cmd"

func main() {
	cmd.Execute()
}

これを作っておくと、

$go run scripts/gqlgen.go init

という感じでgqlgenのコマンドを実行できるようになります。ラッパースクリプトができたら下記のコマンドgqlgenでの開発に必要なファイルを準備します。

$go run scripts/gqlgen.go init

initが完了すると、gqlgenのファイルが作成されるのですがそれぞれのファイルを簡単に説明すると

gqlgen.yml ・・・ gqlの設定ファイル。生成されるコードの設定を書いていきます。
genereated.go ・・・ schemaを定義してスクリプトを叩くと生成されるファイル。スクリプトで生成されるので手動で編集するのはダメ。
models_gen.go ・・・ schema定義から生成されるモデル群が定義されたファイル。スクリプトで生成されるので手動で編集するのはダメ。
resolver.go ・・・こちらはresolver.goというファイルがなければ自動で生成される。
server/server.go ・・・サーバーのエントリーポイント

となります。

コードの生成ができたら念の為

dep ensure

して依存パッケージがインストールされているか確認します。

Gin用のエントリーポイントを用意

gqlgenでコードを生成するとサーバーのエントリポイントまで用意してくれるのですが、 gqlgenが用意してくれるserver.goだとginを使わないので、ginで動くように書き換えていきます。

コードはこちらのドキュメントのコピペですが、playground用のエンドポイントと本チャンのエンドポイント二つを用意します。

import (
  "github.com/99designs/gqlgen/handler"
  "github.com/gin-gonic/gin"
)

// Defining the Graphql handler
func graphqlHandler() gin.HandlerFunc {
  h := handler.GraphQL(NewExecutableSchema(Config{Resolvers: &Resolver{}}))

  return func(c *gin.Context) {
    h.ServeHTTP(c.Writer, c.Request)
  }
}

// Defining the Playground handler
func playgroundHandler() gin.HandlerFunc {
  h := handler.Playground("GraphQL", "/query")

  return func(c *gin.Context) {
    h.ServeHTTP(c.Writer, c.Request)
  }
}

func main() {
  // Setting up Gin
  r := gin.Default()
  r.POST("/query", graphqlHandler())
  r.GET("/", playgroundHandler())
    r.Run()
}

Gormのモデルの用意

ここまででエントリポイントが用意できたので、お次はスキーマ定義で使うモデルを定義していきます。ファイルの配置はGoのスタンダードレイアウトにそって配置しているのでモデルはinternal/models配下に配置をしていきます。

// user.go
package models

import (
	"time"
)

type User struct {
	ID        int
	Name      string
	Todos     []Todo
	CreatedAt time.Time
	UpdatedAt time.Time
}

// todo.go
package models

import (
	"time"
)

type Todo struct {
	ID        int
	Text      string
	Done      bool
	UserID    int
	User      User
	CreatedAt time.Time
	UpdatedAt time.Time
}

ここではモデルを構造体で定義しているのですが、Gormのドキュメントを見ればわかる通りモデル定義に埋め込みを使って書く方がスマートかと思うのですが、この書き方だとコードを生成する時のコマンドでエラーがでてしまうので、一旦モデルのフィールドをベタ書きしています。 (コードとかちゃんと読んだら打開策はあるのかも）

// todo.go
package models

import (
	"time"
)

type Todo struct {
  gorm.Model
	Text      string
	Done      bool
	UserID    int
	User      User
}

このように、自前のモデルを定義できたらgqlgenではgqlgen.ymlにモデルのマッピングを設定する必要があります。今回の例ではモデルは下記のような設定になるのでgqlgen.ymlに以下を追記します。

models:
  Todo:
    model: gin_graphql/internal/models.Todo
  User:
    model: gin_graphql/internal/models.User

schemaを定義

ここまではスキーマ駆動で開発するまでの準備だったのですが、ここでAPIとして必要な機能をスキーマとし定義していきます。

type Todo {
  id:   Int!
  text: String!
  done: Boolean!
  userID: Int!
  user: User!
  createdAt: Time!
  updatedAt: Time!
}

type User {
  id: Int!
  name: String!
  createdAt: Time!
  updatedAt: Time!
}

type Query {
  todos: [Todo!]!
  users: [User!]!
  todo(input: FetchTodo): Todo!
}

input NewTodo {
  text: String!
  userId: Int!
}

input EditTodo {
  id: Int!
  text: String!
}

input NewUser {
  name: String!
}

input FetchTodo {
  id: Int!
}

type Mutation {
  createTodo(input: NewTodo!): Todo!
  updateTodo(input: EditTodo!): Todo!
  deleteTodo(input: Int!): Todo!
  createUser(input: NewUser!): User!
}

scalar Time

今回のCRUDを実装するためのschema.graphqlがこちらです。基本的な文法はgraphqlのスキーマの文法にそった形で定義をしていくのですが、全体の見方としてリソースに変更を加えるスキーマはMutationの構造体にそれ以外の参照系の処理はQuery に書いていきます。そしてそれぞのれメソッドで必要な型（User, Todo, NewUser)を別で定義していくという形です。

これが出来上がると、先ほどのgqlgenコマンドを使ってコードを生成してresolverの実装に移ることができるようになります。 resolverではスキーマであらかじめインプットとアウトプットを決めていて、その通りにコードを生成しているのであとはその間のロジックとを実装するだけということになります。

resolverの実装

というわけでスキーマの定義がおわったのでいよいよresolverの実装に入ってきます。resolverでは、クライアントからのリクエストに応じて DBからデータを取得してくる、レコードを作成する等々を行なっていきます。

gqlgenにおける注意点としては、resolver.goはすでに存在する場合コード生成のコマンドを実行しても上書きされずそのままという点です。 (逆にスキーマ変えてresolverが全部もとの状態に戻ってしまうのは当たり前に辛いのですが）

というわけでCRUDするresolverは下に貼っておきます。ひとつずつ説明するのもやぼったいのでざっくり説明をするとさきほどschema.graphqlで定義したメソッド群が resolverに実装されていれば良いので、mutaionはmutationResolver、queryはqueryResolverのメソッドとしてひとつひとつずつ実装を進めていけば完了です。


type Resolver struct {
}

func (r *Resolver) Mutation() MutationResolver {
	return &mutationResolver{r}
}
func (r *Resolver) Query() QueryResolver {
	return &queryResolver{r}
}

type mutationResolver struct{ *Resolver }

func (r *mutationResolver) CreateUser(ctx context.Context, input NewUser) (*models.User, error) {
	user := models.User{
		Name: input.Name,
	}
	db.Create(&user)
	return &user, nil
}

func (r *mutationResolver) CreateTodo(ctx context.Context, input NewTodo) (*models.Todo, error) {
	todo := models.Todo{
		Text:   input.Text,
		UserID: input.UserID,
		Done:   false,
	}
	db.Create(&todo)
	return &todo, nil
}

func (r *mutationResolver) UpdateTodo(ctx context.Context, input EditTodo) (*models.Todo, error) {
	todo := models.Todo{ID: input.ID}
	db.First(&todo)
	todo.Text = input.Text
	db.Model(&models.Todo{}).Update(&todo)

	return &todo, nil
}

func (r *mutationResolver) DeleteTodo(ctx context.Context, input int) (*models.Todo, error) {
	todo := models.Todo{
		ID: input,
	}
	db.First(&todo)
	db.Delete(&todo)
	return &todo, nil
}

type queryResolver struct{ *Resolver }

func (r *queryResolver) Todo(ctx context.Context, input *FetchTodo) (*models.Todo, error) {
	var todo models.Todo
	db.Preload("User").First(&todo, input.ID)
	return &todo, nil
}

func (r *queryResolver) Todos(ctx context.Context) ([]models.Todo, error) {
	var todos []models.Todo
	db.Preload("User").Find(&todos)
	fmt.Println(todos[0].User)
	return todos, nil
}

func (r *queryResolver) Users(ctx context.Context) ([]models.User, error) {
	var users []models.User
	db.Find(&users)
	return users, nil
}

起動

resolverの実装までできたらあとは起動するだけなので、go runをしていきます。今回用意したリポジトリでは、エントリーポイントをcmd/app/main.goとしており、環境変数を与えて設定ファイルを読むようにしているのでENVもあたえつつ下記コマンドを実行します。

ENV=development go run cmd/app/main.go

起動するとサーバーのログが流れ始めると思うのですが、同時に localhost:8080にアクセスするとplaygroundでクエリを試すことができます。

詰まったところ

流れの部分はさらっと書きましたが、今回の構築にあたり結構いろんなところで詰まったのでそこについてまとめておきます。

CreatedAtやUpdatedAtなどの日付の型ってどうやってスキーマ定義するの？

Schemaの型というのは、

ID
Int
Float
String
Boolean

しかデフォルトで設定されていないので、日時などのデータは別で定義しておく必要があります。私がサンプルを作るときはここにつまずいて色々とドキュメントを漁っていたのですが、gqlgenがデフォルトで提供しているTime型というのがあるのでそれを使えば問題ありませんでした。

上にのせたスキーマ定義にも書いたようにgqlgenで定義された型を使用するには

scalar Time

とします。

この宣言をした後にスキーマでその型を使うとGo組み込みのtime.Time型にマッピングしてくれます。 gqlgenではTime以外にもMap, Upload, Anyなどに対応しているのでそれぞれの型が必要な時は上のように scalar宣言でスキーマで使える型を追加して頂ければ良いと思います。

Gormを埋め込みしたモデルでジェネレートしようとするとこける

これは解決していなくてワークアラウンドでしのいだのですが、下記のようにモデルをgormの埋め込みで定義するとジェネレートしようとした時にこけます。

type User {
  gorm.Model
  name
}

一旦は上の方のモデル定義にあるように全てのフィールドをベタで書いてしのいだのですが、なんだかイマイチです。 gormとgqlgenを一緒に使うのに結構ハマったのですがGo詳しい人だと秒で解決できる問題ないんですかね・・・ちょっとわからないので勉強します。

リストを取得した時にアソシエーションのモデルも取得する

これはGraphQLというより、Gormの話なのですがリストをAPIから取得する時に同時に関連したモデルも取ってきたいというこ結構ありますよね。ということで今回のサンプルでもTodoのリストを取得しつつ、Todoを作成したユーザの情報もとりたいなということでgqlgen+gorm（ほとんどgormの話ですが）で書くとどうなるのかというのをやってみました。

ちょっとめんどくさそうでしたが、思ったより結構シンプルにかけました。構造体にそれ用のフィールドを用意するだけです。

type Todo {
  id:   Int!
  text: String!
  done: Boolean!
  userID: Int!
  user: User!
  createdAt: Time!
  updatedAt: Time!
}

Todoのモデルを例にとると、userIDとuserというフィールドを用意してあげるだけで、関連したモデルを取ってくるのに困りません。あとは、resolver内で

db.Preload("User").Find(&todo, input.ID)

という形で読んであげれば、関連したモデルもろともバシッと取ってきてくれます。リストを取得する時に気になるのはN+1問題ですが、SQLのログをみても

(/app/src/gin_graphql/resolver.go:65)
[2019-05-14 15:27:07]  [0.90ms]  SELECT * FROM `todos`  WHERE (`todos`.`id` = 2) ORDER BY `todos`.`id` ASC LIMIT 1
[1 rows affected or returned ]

(/app/src/gin_graphql/resolver.go:65)
[2019-05-14 15:27:07]  [2.65ms]  SELECT * FROM `users`  WHERE (`id` IN (1)) ORDER BY `users`.`id` ASC
[1 rows affected or returned ]

という形でPreloadしてくれています。（当たり前といえば当たり前なのですが）ネットで記事をあさっているとgqlを触っているとN+1がーという話をよくみたのですが、Preloadしとけば問題なさそうなんですがどうなんですかね？gormを使ってないからなんでしょうか？ちょっとわからないので課題として頭の片隅においておきます。

まとめ

というわけで、最近のWeb APIにありがちなスタック+GraphQLでサーバーを構築してみました。最近やっぱりRESTで案件をやっていると限界を感じてきているのでGraphQLやっぱり良いなという感じです。。

今更感は否めないですが、GraphQLはだいぶ便利そうです。RESTだとフロントに依存してはダメとわかりつつもWeb作った後にアプリも作ろうみたいになるとどうしてもAPI側の改修って必要になりますよね。

そりゃ別のもの作るので、実装当初に予期していないことが起こるのはある程度しょうがないのですが、その都度またエンドポイントを作りなおしてということをやっていくのでなんだかいたたまれない気持ちになってくることも多いです。もともとWebでつくっていたものをアプリで作ろうとなって全く既存APIの改修が必要なかったら素敵ですよね。

GraphQLの場合は、スキーマでリソースを定義しておけばクライアント側で必要な情報だけとってくるということができるので、

新しくエンドポイントを作るときのどれくらいの情報を返しておけば良いのか？ということや将来どれくらいエンドポイントがチャンキーになりそうかという未来予測を立てたりする必要がなさそうでとっても便利なものに見えます。

もちろん、このサンプルに比べてより複雑で大規模なAPIを構築した時にどうなるのか？というところはやってみないとわらかないところではあるのですが今回のつくってみたでは、GraphQLの可能性を大いに感じました。

日々の業務でREST脳になっている方は、休日や平日夜にGraphQLを試してみると新しい発見が面白いと思います。

では。

Docker, Gin, Gorm, DepでCRUDできるAPI作成

Thu, 02 May 2019 00:00:00 GMT

このような記事を書きつつGOを学習中なのですが、今回はWebAPIでCRUDでも作ってみるかということで手順や詰まったところをまとめていきます。

使用する技術

Docker

ローカルのPCを汚すのが嫌なのでDockerを使っていきます。MySQLも使うのでdocker-composeで作っていきます。

Gin

Go言語のフレームワークの一つで、Go言語フレームワークでも一番スターが多いそうなのでAPI実装のために Ginを使ってみました。プロダクトの実装ではフルスタックフレームワークの方が嬉しい面もあるのでbeeogo にも惹かれましたが、まずはシンプルなフレームワークから使ってコード書く量を増やしましょうということで Ginを採用しました。

Gorm(MySQL)

Go言語のORM（オーアールマッパー）です。RailsライクなインターフェースだそうなのでRailsのActiveRecordに親しんでいたものとしていくつかORMあるそうですがgormを採用しました。

Dep

Goのパッケージ管理ツールです。単純にパッケージ管理が必要なのと、Dockerで環境を構築する時に"go get"で Dockerfileが荒らされるのが嫌だったので、アプリ内でしか使わないものはdepコマンドで管理するようにします。

早速つくっていく

コンテナの準備

まずはDockerのイメージの作成からやっていきます。Dockerfileを晒すとこういう感じです。最終的なリポジトリはこちらです。

FROM golang:latest
ENV ROOTDIR /app
ENV WORKDIR /app/src/gin-sample
ENV GOPATH $ROOTDIR
ENV GOBIN $ROOTDIR/bin
WORKDIR $WORKDIR
VOLUME $ROOTDIR
ADD . $ROOTDIR

RUN apt-get update && \
    apt-get -y install mysql-client && \
    echo "export PATH=$PATH:$GOBIN" > /root/.bashrc

CMD ["go", "run", "cmd/app/main.go"]

やっているのは各種環境変数の設定とMySQLクライアントのインストールとGOBINをパスに含めたりする部分です。 docker-composeはこういう形です。

version: '3'
services:
  app:
    build: .
    ports:
      - "8080:8080"
    security_opt:
      - seccomp:unconfined
    depends_on:
      - db
  db:
    image: mysql:5.7.19
    environment:
       - MYSQL_ROOT_PASSWORD=password
    ports:
      - "3306:3306"
    volumes:
      - ./data/mysql:/var/lib/mysql:cached

このままだとdepがインストールできていないので作成したコンテナでgo getしてビルドされたdepファイルを作成します。

docker-compose run -v $PWD:/app -p 8080:8080 app bash
go get -u github.com/golang/dep/cmd/dep

ここまでコンテナ内でdepコマンドが使えるようになるのでコンテナ内でさらに

dep ensure

とすることで依存パッケージのビルドが完了します。

コーディング

最初src/[パッケージ名]下のディレクトリの配置をどうするか悩んだのですがスタンダードなGo Projectのレイアウトがあるそうなので今回はそれに則ってみました。

https://github.com/golang-standards/project-layout

cmd/ 配下に実際に実装するコマンドのmain.goを配置しました。今回はDBからデータを取得などなども実装していくのではじめに簡易マイグレーションコマンドを実装しました。

としています。

// cmd/migrate/main.go
package main

import (
  "gin-sample/internal/models"
  "gin-sample/pkg"
)

func main() {
  db := pkg.Connect("development")
  defer db.Close()

  db.AutoMigrate(&models.Product{})
  db.Create(&models.Product{Code: "L1212", Price: 1000})
  db.Create(&models.Product{Code: "ABABA", Price: 2000})
  db.Create(&models.Product{Code: "CDCDC", Price: 3000})
}

ここでは単純にDBとの接続を行い、productデーブルを作成後に実データ投入という感じです。マイグレーションといいつつデータも投入していますね。DB接続の部分は実際のWebAPIの方でも使うのでパッケージに切り出しています。

そして次は実際のWeb API部分です。

// cmd/app/main.go

package main

import (
  "gin-sample/internal/models"
  "gin-sample/pkg"
  "github.com/gin-gonic/gin"
  "net/http"
  "strconv"
)

func main() {
  r := gin.Default()
  db := pkg.Connect("development")
  defer db.Close()
  db.LogMode(true)

  r.GET("/products", func(c *gin.Context) {
    var products []models.Product
    db.Find(&products)
    c.JSON(200, products)
  })

  r.GET("/products/:id", func(c *gin.Context) {
    id := c.Param("id")
    var product models.Product
    db.First(&product, id)
    c.JSON(200, product)
  })

  r.POST("/products", func(c *gin.Context) {
    product := models.Product{}
    err := c.Bind(&product)
    if err != nil {
      c.String(http.StatusBadRequest, "Request is failed: "+err.Error())
      return
    }
    db.NewRecord(&product)
    res := db.Create(&product)
    if res.Error != nil {
      c.JSON(402, res.Error)
    } else {
      c.JSON(200, nil)
    }
  })

  r.PUT("/products/:id", func(c *gin.Context) {
    id, _ := strconv.Atoi(c.Param("id"))
    product := models.Product{}
    db.First(&product, id)

    params := models.Product{}
    err := c.Bind(&params)
    if err != nil {
      c.String(http.StatusBadRequest, "Request is failed: "+err.Error())
      return
    }
    db.Model(&product).Updates(params)
    c.JSON(200, product)
  })

  r.DELETE("/products/:id", func(c *gin.Context) {
    id, _ := strconv.Atoi(c.Param("id"))
    db.Where("ID = ?", id).Delete(&models.Product{})
    c.JSON(200, nil)
  })
  r.Run() // listen and serve on 0.0.0.0:8080
}

実際はコントローラに切り出した方がお行儀が良さそうですが、一旦フラットに書き下しています。実装のながれをざっくり説明するとさらっとおわってしまうので詰まったところ等々を書いていきます。

詰まったところ・工夫したところ

delveの導入

何かプログラミングを始める時の開発効率をあげる方法としてデバッガに慣れ親しむのは大事だと思うのですが、今回Goのデバッガとしてdelveを入れてみました。

使い方としては、dlvコマンドでアプリを起動した後にプロンプトが表示されるのでそこでブレークポイントを設定して、設定が終わったらcontinueとするとブレークポイントまで処理が進むので、ポイントで処理が止まったらそこで変数の中身みたり、変数書き換えたりできるという感じです。

使用感はrubyのbyebugなどと似ているのですが最初にブレークポイントをコマンドで設定するのが少々面倒に感じました。 byebugなどだとコード書き換えることにはなるのですが、ファイルに直接ブレークポイントを書き込む感じになるのですのがdelve だとこのファイルのこの行みたいに指定しないといけないので直感的でなくちょっと手間です。（何か良い方法があれば知りたい）

あと、byebugだとステップ実行しているところで任意のコードを実行できるのですが、delveだとできないんですかね？？少し調べてもちょっとわからなかったので一旦保留にしています。

インストール自体は簡単で、depと同様にコンテナ内でgo getして使います。

一点注意点として、dockerの設定でセキリティオプションを設定しないとうまく起動してくれないということです。 docker-composeで"seccop:unconfined"を設定していないと下のようなエラーが出てきて使えないです。

could not launch process: fork/exec [...]: operation not permitted

わすれずにdocker-composeのオプション指定をしておきましょう。

設定ファイルの外出し

DBに接続する時に、ベタ書きでDBの設定をしても良かったのですが、実プロダクトだとそんなことはしないだろうということで設定ファイルを外だしにする方法を調べて、実装しました。

// pkg/config.go
package configs

import (
  "github.com/BurntSushi/toml"
)

type Config struct {
  Database Database
}

type Database struct {
  User     string `toml:"user"`
  Password string `toml:"password"`
  Address  string `toml:"address"`
  Name     string `toml:"name"`
}

func GetConfig(env string) Config {
  var config Config
  _, err := toml.DecodeFile("configs/"+env+".toml", &config)
  if err != nil {
    panic(err)
  }

  return config
}

大したことはしていないのですが、このモジュールで、tomlファイルを読み込んでパースした内容を構造体にバインドする感じです。

設定の呼び出し元はこんな感じ、

// pkg/database.go
package pkg

import (
  "github.com/go-sql-driver/mysql"
  "github.com/jinzhu/gorm"
)

func Connect(env string) *gorm.DB {
  dbConf := GetConfig(env).Database
  mysqlConf := mysql.Config{
    User:                 dbConf.User,
    Passwd:               dbConf.Password,
    Net:                  dbConf.Address,
    DBName:               dbConf.Name,
    AllowNativePasswords: true,
    ParseTime:            true,
  }

  dsn := mysqlConf.FormatDSN()
  db, err := gorm.Open("mysql", dsn)
  if err != nil {
    panic(err.Error())
  }

  return db
}

SQLログを画面に出力

開発中はリクエストのログもそうですがどのようなSQLが発行されているか知りたいですよね。 gormの場合はDBの接続を作った段階で下記の一文を入れれば発行されているSQLが見えるようになります。

db.LogMode(true)

まとめ

当初はGraphQLとか使ってCRUDやりたいなと思っていたのですがGinいれたりGormいれたりdep入れたりしていたら意外と時間かかったので一旦ここでセーブしておきます。次回はGraphQLサーバやりたいですね。あとMongoとかも使いたい。

では。

React Navigationでのnavigateをpropsを介さずに行う

Sat, 27 Apr 2019 00:00:00 GMT

Rect Nativeでルートを管理するのによくReact Navigationを使うのですが、普通にReact Navigationをインストールすると画面コンポーネントにバインドされたnavigationインスタンスを使って遷移を行う感じになると思うのですが、 APIの成功・不成功をもとに画面を遷移させたりなどなど画面以外の場所でnavigationさせたい時ってありますよね。

今回はそんな時用のTipsです。参考はこちらです。

Navigating without the navigation prop

さっそくやってみる

全体の仕組みとしては、topレベルのコンポーネントがnavigateインスタンスへの参照を持っているのでその参照を適当なモジュールに保持して適宜それを呼び出して使うという形です。 navigation

具体的なコードとしては、以下のような形でrefsを使ってnavigationへの参照が渡せるので、

import { createStackNavigator, createAppContainer } from 'react-navigation';
import NavigationService from './NavigationService';

const TopLevelNavigator = createStackNavigator({ /* ... */ })

const AppContainer = createAppContainer(TopLevelNavigator);

export default class App extends React.Component {
  render() {
    return (
      <AppContainer
        ref={navigatorRef => {
          NavigationService.setTopLevelNavigator(navigatorRef);
        }}
      />
    );
  }
}

NavigationServiceというその参照を保持するモジュールを用意してAppContainerでその参照をセットするという形です。

実際には、以下のようなモジュールを用意します。

// NavigationService.js

import { NavigationActions } from 'react-navigation';

let _navigator;

function setTopLevelNavigator(navigatorRef) {
  _navigator = navigatorRef;
}

function navigate(routeName, params) {
  _navigator.dispatch(
    NavigationActions.navigate({
      routeName,
      params,
    })
  );
}

export default {
  navigate,
  setTopLevelNavigator,
};

コードをみてわかるようにsetTopLevelNavigatorでnavigateへの参照を保存して、 navigateさせたい時は、NavigationService.navigate(routeName, params)で画面遷移させることができる。という具合です。

下は、サインインが成功したらマイページに遷移させるというコードの例ですね。

import NavigationService from './NavigationService'

export const signInAsyncFunciton = async ({ email, password }) => (dispatch) => {
  const acitons = { signIn, signInSuccess, signInError } = actions
  try {
    dispatch(signIn())
    const { data } = await api.fetchHoge({ email, password })
    if (data) {
      // SignIn Success
      dispatch(signInSuccess(data))
      NavigationService.navigate('Mypage')
    }
  } catch (error) {
    dispatch(signInError(error))
  }
}

※コードはイメージです。

まとめ

というわけで、navigationをprops経由しないで行う方法でした。

これを使うと好きなところで画面を操作できるので、自由といえば自由なのですが、あまり乱用するとどこで、画面を操作してわからなくなるので乱用は禁物ですね。ただログイン後遷移させたい時やリソースを削除した後に、詳細画面から一覧画面に遷移させたい。などあると思うので使いどころ見極めてできると良いとですね。

では。

ミートアップにスノボとラクロス観戦。5泊7日のバンクーバ旅行まとめ

Mon, 22 Apr 2019 00:00:00 GMT

4月中旬にリフレッシュなどをかねて(GWは高いので）バンクーバーに行ってきたので、旅行のまとめをしておこうかなと思います。

仕事が結構家にこもりがちな仕事なので、定期的に海外なりどこか旅行にいきたいなとは思っていて今回もそれの一つではありました。また、最近北米、東南アジア等々でエンジニアとして働いている日本人の話も聞いたりしてきたので、どんなところなのかなというのも気になってバンクーバーに行ってみました。

旅行中にしたこと

今回は5泊7日の滞在でしたが、その間の主なアトラクションは

ウィスラーでのスノボード
バンクーバーでのミートアップ参加
バンクーバーでのラクロス観戦

でした。

流れとしては前半3日半はウィスラーでそのあとバンクーバーに移動という感じでした。ハイライトでいうとこの三つがハイライトなのですが、他にも色々あったので総括というかあったことをつらつら書いていきます。

旅行の準備はお早めに

今回旅行の計画を始めたのが二ヶ月前くらいなのですが、飛行機調べたりチケット取ったりとかいうのをサボっていて ズルズルと航空券を取らずにたら普通に二万円くらい航空券が値上がりしていました。

航空券って、計画しっかり立てて時間決めて、値段と航空会社と相談してという感じで結構時間かかるんですよね。取る便間違えたりすると旅行の計画が台無しになるしで結構集中力がいるし普段の仕事は毛色の違う作業なのでずーっと後回しにしていたんですよね。

そんなこんなで日付が迫って航空券とってちょっと高くなった中で、今度スノボのためのリフト券を取ろうと思ったらどうやらリフト券も滑る日の14日前だと値段が安いらしくここでも無駄に高いチケットを買うハメになってしまいました。

面倒臭いのはしょうがないのですが、旅行のチケットは計画が確定した時点で早めに取った方が良いです。わかってはいるんですがこれがなかなかムズカシイ。

後に書くのですが治安の情報とかも大事なのでまず地球の歩き方などでしっかり情報収集してから宿決めて、航空券とってとしたいですね。

地球の歩き方カナダ西部 2018~2019

ホテル代はケチらない

アジアとかだと結構ホテル代安くて、あまり気にならないのですが北米地域とかだとホテルが結構高いです。バンクーバーだと普通に1泊1万円超えていきます。（複数人でいくとやすかったりはするのですが）

そんなこんなで今回は一人旅だったので、安いホテルにしようという安易な感じで5000円くらいのホテルを選んだのですが、そこがまあ結構辛かったです。建物が古く床が軋むし、隣の部屋の物音がガンガン聞こえてくるし暖房が調節できないしで快適とは言えませんでした。

ここまでだったら安いホテルだからで住むのですが、問題はホテルの周りで地球の歩き方にも行っちゃダメって書いてあるようなところで、ホテルに着いてから周りが怪しいと思ってネット検索してみるとスラム街が近いらしく浮浪者やドラッグの売人とかが結構いる地域の模様。

ホテル裏の公園は、ホームレスのテントで半分以上埋まっていて極力付近を歩かないようにバスで移動していてもそこの地区から乗ってくる人たちだけ明らかに様子がおかしい。ミートアップに参加して帰りが遅くなった時のホテルまでの道のりが恐怖すぎたので本当に困りました。

(ミートアップでホテルの場所を話したら軽く引かれてた笑）

設備が悪いだけなら我慢もできるのですが、ホテル周りの治安が悪いと夜もあまり遅くに帰れないので本当に旅行の自由度が制限されます。一人旅とか男だけだからいいやとかで安易に安宿を選ぶと痛い目にあいますね。。

今度からホテルは慎重に選ぶようにします。

バンクーバーではUberが使えない

以前カリフォルニアや台湾を旅行した時は、Uberが本当に便利だったのでそのノリでバンクーバーに乗り込んだのですがなんとバンクーバーでは今のところ、 Uberが使えないようです。。

現地に到着して気づいたのですが、バンクーバー市内はバスが結構便利でこのような

パスモのようなコンパスカードと呼ばれるカードにクレカでお金をチャージしておけば料金などを気にせず乗ることができます。詳しいバスの乗り方や料金などはググってもらえればわかると思うのですが、Googleマップをみると最寄りのバス停に何分あとにバスが来るやバスの現在位置などがわかるので本当に便利でした。

コンパスカードはスカイトレインという電車の駅でお金をデポジットして手に入れることができるので初めてバンクーバーに行く時は最初に駅でコンパスカードを手に入れておくと便利かと思います。

ウィスラー最高

ウィスラーは、ホテルも文句なしレストランやスーパーなどなども充実していて本当に過ごしやすかったです。

4日間(3日半）いましたが、夜も飲み物が欲しくなったり小腹がすいたらスーパーに行けばいいし、モーニングは適当にカフェ探せばいいし、夕食のレストランも至るところにあるし節約したければ材料買ってきてホテルで調理すればいいしとういう感じで本当に過ごしやすかったです。

スノボの方は一日目は雪で二日目は晴れ、一日目は視界が悪い時間帯もありましたがトータルで満足に滑れました。長いコースはスキー向けという感じですが、パークもあるし文句のつけようがありませんでした。コースが広すぎるのでスノボをした二日間ではブラッコム山まではいけませんがでしたが、また今度行く機会があればぜひそっちもチャレンジしたいです。

今年は4月にしては雪が残っている方らしく、人もそこまで多くなく自由に楽しめました。現地のガイドさん曰く12月の中旬くらいがリフト券も安いし、雪も良いので狙い目らしいです。 4月のちょっとあったかくなった時期(麓は一桁代上に行くとマイナスという天気でしたが）に行くのも良いですが今度いくなら12月がよいかもしれません。

海鮮おいしかった

ウィスラーでもバンクーバーでも海鮮系の食事を楽しみました。どちらの街も海がそばなので海鮮系のレストランは結構多いみたいです。

ウィスラーでは、到着初日に地球の歩き方で見つけたお店に行ってみました。席につくと目の前に鉄板があって目の前で焼き物を焼いてくれるのですが、シェフが様々なパフォーマンスもしてくれるので味以外にも楽しみがあります。

Teppan Village Japanese Steakhouse

パフォーマンス中の写真

ロブスターとステーキ

日系なので半分くらいが日本人の店員さんとシェフなので、英語が苦手だったりする人でも楽しめます。今回はたまたまシェフが日本人だったので、おしゃべりしながらご飯食べてました。

バンクーバーではラクロス観戦の前に時間があったのでオイスターバーに行ってきました。

Fanny Bay Oyster Bar & Shellfish Market

こんな感じで生牡蠣が楽しめます。フィッシュ＆チップスとワインで最高でした。店内もおしゃれで店員さんも親切でした。

旅行の計画にミートアップを挟むのオススメ

今回初めて、旅行中に現地のミートアップに参加しましたが結構楽しめました。（後半英語での会話に疲れてガス欠気味でしたが）

ミートアップ自体はアプリかこのサイトから気軽に探せるので飛行機の待ち時間などに探してみて申し込んでみると良いと思います。当然ミートアップに来ている人たちは現地で働いている or 学生なので、同じ感じで会話するのは難しいのかもしれませんが、色々な人がいて話を聞いているだけでも面白いです。

旅行中ちょっと時間空きそうだなとあったら参加してみても良いかもしれません。特に一人旅の時なんかはぼっち飯しなくてすむのでオススメです。

ボックスラクロス観戦おすすめ

カナダではボックスラクロスと言って、日本やアメリカでポピュラーなラクロスとはちょっと違うホッケーのコートを使った室内のラクロスが盛んなのですが、 **バンクーバーではボックスラクロスの観戦ができます。**チケットの買い方などなど詳細はまた別で記事にしようかなとは思うのですが、ボックスラクロス自体スピード感があるし、タイムアウトやクォーターの間のゲームとかレクなど観客を飽きさせない仕組みが色々あるので一試合通して楽しめます。

ラクロスは一応カナダの国技なのですが、ポピュラーとは言い難く観客席も空席が目立ちます。盛り上がりにかけると言えばそうなのですが、人が少ない分自由に席移動できたり席を広々とれたりして快適に観戦できます。

まとめ

総括というか印象に残ったことをつらつらと書いてみました。カナダってどんな場所なのかなというのがあったので、今回旅行していたのですが、アメリカほど入国審査などなど厳しくなく全体的にゆとりがあるような印象をうけました。

治安も悪そうな場所は少なそうですし、日本人も多いので住むには結構良いんじゃないかなという印象でした。（個人的にはラクロス観戦もスノボもできるので趣味が合う）ただ物価は結構高いので、そのあたりの住みづらさはあるのかもしれません。

まぁ色々と書きましたが現地のミートアップに出てスポーツ観戦して、スノボしてという感じで充実した旅行になりました。準備不足なところだったり予想外なところもちょこちょこありましたが、まぁそれも含めて楽しめたかと思います。

では。

バンクーバー旅行で現地ミートアップに参加してきた話

Fri, 19 Apr 2019 00:00:00 GMT

先日バンクーバーで飛び入りで現地のミートアップに参加してきたので感想などをまとめてみたいと思います。旅行でスタンプラリーみたいに観光地を回るのも良いのですが、個人的には現地の人と話しをしたり、現地で働いてる人の話などなど聞いてみたいなぁというのがあったので飛び入りではありますがミートアップに参加してみました。

ミートアップとは？

エンジニアとかだと馴染みのある人も多いのですが、要は交流会です。

エンジニアのミートアップだとプログラミング言語縛りでミートアップをしたりするのですが、ミートアップには何かしらの共通点があれば良いので、Railsミートアップ、PHPミートアップなどだけでなく、ヨガミートアップ、英語学習者ミートアップなどなど様々なジャンルのミートアップが存在します。

ミートアップには言葉通りの最寄りで開かれているミートアップを探すのには色々な方法があるのですが、今回は名前の通りミートアップという名前のアプリを使ってバンクーバーで開かれているミートアップに参加してきました。

何をするかが自分をつくる | Meetup

ICC Vancouverミートアップに参加

ということで今回は、空港に向かう途中でミートアップのアプリで見つけたミートアップに参加してきました。ミートアップのリンクはこちらです。 ICC Vancouver

開催場所は、バンクーバーダウンタウンのQuantum Cafeという場所で夕方から2時間程度開かれてました。カフェなので最初に自分の好きな飲み物を注文してあとは、来た人から順々にテーブルについていきます。

私がついたころは人がまばらで、全く人がいないテーブルに座るのも気がひけるので2, 3人程度が座っているテーブルで好きに話始めました。

ミートアップの感想などは後でまとめますが、今回参加したミートアップの流れとしては最初普通にカフェでおしゃべりして、そのあと有志でご飯会に移行という形でした。参加者は想定していたより結構多く、30人程度はいたんじゃないかと思います。国籍も様々で、普通に日本人の方もいればカナダの人、韓国、フィリピン、チェコ、メキシコなどなど現地に住んでる色々な方と話すことができました。

なんでミートアップに参加したの？

旅行っていうと観光地巡りしたりとかって言うイメージがあるのでなんでわざわざミートアップなんか参加したの？と言うところわ掘り下げると一つは単純に一人旅でそこまで回りたい観光地がなかったからって言うのはあると思います。

旅行の目的としては、ラクロス観戦とウィスラーでのスノボがメインだったので、ほかの時間で何しようかなと考えた時に何かしらのイベントに参加したら楽しいんじゃないかと考えてミートアップのアプリでイベントを探してちょうど良いのがあったのでそれに参加しました。

もう一つの理由に英語力の強化というのがあって、普段オンラインの英会話などを使って極力英語を話す時間を作っているのですがリアルでの会話とレッスンの会話にはそれぞれ使う語彙やどうやって先生以外の人とコミュニケーションを取るかという部分が気になったので旅行先で積極的に英語を使う機会を作ってみました。

ミートアップに参加してみた感想

ここからは実際に参加してどうだったかというものを書いていくのですが、書いていたら英語でのコミュニケーションと言うところに焦点を絞った感想が多くでてきました。

リアルな場でのフリーテーマな会話が意外とできたかも

オンラインで英会話したり、昔仕事でオフショア的な事をしていたのでその時などなど英語を使って初対面の人達とフリーテーマで話すというのはほとんどなかったので会場に到着するまでに相当緊張しました。みんなペラペラで、話について行けなかったらどうしようとかいう不安はあったのですが、意外と話もできてリラックスして会話できました。

初めてのことだと、やる前は必要以上に心配したり、不安になったりしますがやはりやってみると案外大したことないなんてことは良くありますね。今回のイベント参加は心理的ハードルを取り除くという目的が結構大きかったので、コミュニケーションスキルなどなどまだまだ不足する部分は多いですが、この目的は達成できたのかなと思います。この調子で日本に戻っても英語のミートアップ行けそうな気がしてきました。

ネイティブの英語は早くて理解できない

非ネイティブの多いテーブルでの会話は8割方理解できのですが、ネイティブというか会話に慣れてる人たちのグループでのトークは速すぎてちょっと全然ついて行けませんでした。。

非ネイティブかネイティブみたいに喋れる人達のグループに入るかは結構運ゲー的な要素もあるのですが、偶然そういったネイティブくらい話せそうな人達のグループに入ると全くついて行けませんでした。。ネイティブの人たちのグループの会話にはいると普段草サッカーしている人がバルサのパス回しに参加したみない感じで全然ボールについていけません。

こんな速さで英語処理しないと行けないなんて、、とちょっと気持ちが折れそうになりましたが、会話の速さを体感できたので実感としてさらに上のレベルを知れたのはよかったかなと思います。

会話の集中力がもたない

個人的にそもそも大勢の飲み会とかがあまり好きでなく、3,4人くらいで話すのが好きなので会の形式が合ってないのは否めませんでしたが、やはり2時間くらい喋ってご飯行っても喋ってとなるとだんだん集中力が切れてきます。

単純に自分のボキャブラリーが貧弱だったり、英語で会話するのに必要な集中力が切れてくるので後半になるにつれてどんどん会話が頭に入らなくなってきます。まぁこれは英語のスキルを上げてあまり神経をすり減らさずに話せたり、聞き取れたりしていく他ない気がしてます。。

リアルな英会話の場は勉強になる。

1対1の会話かつ先生と生徒と言う環境だとやっぱり生徒はお客さんで先生もちゃんと話を、聞いてくれるのですが、ミートアップなどだととそういうのがないのでやっぱりコミュニケーションを取るところの厳しさが学べて勉強になる気がしています。また周りが自分より英語ができる場合その人の言い回しとか相づちとかを盗めたり、自分の表現で相手がどういう反応をするかなどなど体験できて非常に効率よくインプットができます。

1対1で集中的にレッスンするのも良いのですが、こういった複数人で会話したりリアルな場所で話すという機会を今後増やしてきたいなと思いました。

まとめ

以上、バンクーバーでのミートアップに参加した話をまとめてみました。

とりとめのないまとめにはなったかもしれないのですが、 旅行先でのミートアップ参加とかどうでしょう？というのとリアルな英会話の場所を作ると英語の勉強捗りそうだよ という話でした。

旅行先で余った時間の使い道に困っている、英語が伸び悩んでいるなんて人にはミートアップ参加オススメしたいです。

では。

ウィスラーでスノボを楽しむための準備。バス、リフト券、レンタル予約。

Sun, 14 Apr 2019 00:00:00 GMT

最近カナダのウィスラーに行ってスノボーをしてきました。ウィスラーに行くため航空券をとったり、バスの予約したり、リフト券とったりレンタルの予約したりと結構やることが多かったのでウィスラーでスノーボードを楽しむために必要な準備をまとめておきます。

カナダに行くのが初めてという方はこちらの記事も参考にしてみてください。

ウィスラーとは？

ウィスラーは、カナダはバンクーバーからバスで2,3時間ほどかけて行くことのできる街です。

ウィスラーのスキー場は**バンクーバーオリンピックの会場にもなっており、世界有数のスキーリゾートとして知られています。**スキー場はブラッコム山、ウィスラー山の二つを滑れ、どちらの山もさ標高2000m以上でコース数200以上、最長滑走距離11kmと圧倒的なスケール感を持っています。

中腹くらいから一番下までスノボーで降りると気圧差で割と耳が変な感じになります。標高差が1,600mほどあるのでこの現状も頷けます

ウィスラー・ブラッコム(Wikipedia)

スキーリゾートなので、山の麓のリフト乗り場にはホテルやレストラン、ショップ、スーバーなどの施設がそろい大変すごしやすい環境ができています。

行き方・所要時間

ウィスラーは、バンクーバーもしくはバンクーバー国際空港からシャトルバスが出ているので、あらかじめバスを予約しておけばシャトルバスでウィスラーまで行くことができます。

私の場合は、こちらのサイトからバスの予約ができるのでJapanadaの申し込みフォームからチケットを予約したい旨を伝えて、バスのチケットを予約しました。

バンクーバー国際空港からの直行バスご予約　-JAPANADA Enterprises Inc.-

申し込みフォームに指定の内容を入力し、送信すると後日メールで予約が完了した旨が伝えられます。細かい説明は上のリンク先を参照してい頂ければと思いますが、予約が完了するとPDFでチケットが送られてくるので当日それを持って空港のスカイリンク（現地のバス運営の会社）の受け付けで手続きをして、指定のバスでバスを待つ形になります。

申し込みの際の注意点としては、空港到着からバス出発の時間の間隔というところです。

初めての空港で不慣れで迷ったり、フライトが遅延したりという形でバスの出発時間に間に合わない場合があるのでバスの出発時刻は空港への到着時刻から十分余裕をもった時間を選ぶようにしましょう。

私の場合は、9時半に空港に到着しする便にのったので12時頃に空港を出発するバスを選びました。

荷物の受け取りや入国審査などなどあるのでなんだかなんだスカイリンクの受付についたのでが10時半頃という感じでした。手続きが終わってバス出発までは一時間ほどあったので空港にあったTim Horton(ティムホートン）（カナダに全土に展開しているファーストフードチェーンでドーナッツが有名らしいです。）で朝食がてら時間をつぶしていました。

リンク先には申し込みの方法やバスの時刻表・料金など結構細かく説明がかかれているのでバス予約を検討している方はこちらを参照していただけると良いと思います。

リフト券予約

リフト券予約はこちらのサイトから購入することができます。

Whistler Blackcomb.com

私がリフト券を取る時は日本でリフト券買う感覚で、いつ買っても値段一緒でしょと思ったのですが予想外に早めに購入した方がリフト券が安く済むそうです。

私の場合はシーズン終盤の4月の平日ということでリフト券を取るのに苦労はしなかったのですが、人の多い時期では、人数制限などがありリフト券があってもスキー場に入れないということがあるそうです。

ウィスラーでのスキー、スノボーを検討する人は航空券などと同じタイミングで早めに予約をしておくことをおすすめします。

ネットでのリフト券の購入方法は、チケットの枚数と日付を選んで、その後に何日分のリフト券を購入するか決めて、支払い情報を入れて購入という形になります。

ウィスラーでは1週間などの単位で滑りに来る人もいるらしく、中日で1日休みを入れたいという方のために特定の期間の中で5日分滑れるという形で自分で滑る日を決めてチケットを買うことができます。

チケットはカナダ国内かつチケット購入が14日前の場合は郵送されてくるそうですが、それ以外の場合は購入後にメールで送られてくるチケットを持ってリフト券売り場まで引き換えに行きます。

リフト券の引き換えはウィスラー山に上がるゴンドラ乗り場の隣にあります。メールで送られてきたチケットとパスポートを見せるとリフト券と交換してもらえます。

リフト券ICカードのようなもので、リフトに乗るときに機械にかざすだけでリフトに乗ることができます。日本の一部のスキー場のようにわざわざ係員に見せる必要がなく便利です。

さらにこのカードは滑り終わった後にカードを取っておくと後日またウィスラーに来る時はこのカードにリフト券をチャージする形で使う事ができます。

これをする事でネット上でリフト券をチャージして、以降わざわざリフト券を交換する列に並ばなくて済むようになります。

このカードを一度手に入れた場合は後のために大切にとっておきましょう。

レンタル予約

スキー、スノーボードはこちらからレンタル予約できます。

RentSkis.com

予約の流れとしては、

サイトでレンタルする日、レンタルする装備、レンタルする店舗、装備のサイズを選択
メールにて予約完了の旨が届く
当日2.の明細をもって指定した店舗に行く

という形になります。

スキー、スノボを2日以上借りる場合は、ホテルに保管してもらえるので都度レンタル屋さんに返却する必要はありません。最終日に返却しに行きましょう。

多くの店舗がリフトが動き出す前の8時から営業しているので、朝レンタルしてそのまま朝一のリフトに乗ることができます。(混み具合によりますが)

店舗でレンタルする際は、板の長さやバインディングの設定の角度など聞かれるのであらかじめ考えておきましょう。

板の長さは身長を入れると自動で出てくるので特に拘りがなければそれでお願いして、バインディングの設定もこだわりがなければノーマルなセッティングをお願いしましょう。

日本で使っている板の角度などがあらかじめわかっているのであれば確認するのも良いと思います。

航空券・ホテルを予約する

最後は航空券の予約です。航空券の予約は他の旅行となんら変わりません、都内に住んでいる方なら成田か羽田から、他地域の方は近くの空港からバンクーバーへの航空券を購入しましょう。

私は普段エクスペディアで航空券とホテルをまとめて購入するのですが、最近バンクーバーへの旅行の券を買おうとした時は実際の確定ページに行くとエラーが出てしまって予約ができないという状態に陥りました。

エクスペディアだとスムーズに行けば良いのですがサポートの窓口が日本人でなかったりでサポートに少し不安が残ります。

結局のところエアトリというサイトでホテルと航空券まとめて購入したのですが、こちらのサイトであれば日本のサイトなので安心感があります。

海外のサイトで航空券を買うのが不安・・・という方はこちらのサイトを試してみると良いと思います。

まとめ

以上ウィスラーでスノボを楽しむために必要な準備をまとめてみました。

航空券
ホテル
リフト券
レンタル(任意)

ウィスラーでスキー・スノーボードを楽しむには大まかにこれらの事前予約が必要です。リフト券やレンタルなど現地で行うことも可能ですがオンラインで事前に予約した方が割引も効くのでそちらを選択することをオススメします。

航空券、ホテルに加えてリフト券もなるべく早めに予約した方が安く済むので旅行の計画が決まったらまとめて予約してしまいましょう。

先に紹介したエアトリでは、ホテル・航空券をまとめて予約すると割引で旅費を安く済ませる事ができます。是非活用してみてください。

では。

初のカナダ旅行に行く前の個人的な趣味も入ったチェックリスト

Fri, 12 Apr 2019 00:00:00 GMT

どうもエンジニア兼旅ブロガーのversion1です。

旅ブロガーとフリーランスのエンジニアというと突然肩書きがキラキラし始めますが、なんてことはない普段は普通に都内で開発の仕事をしています。

最近ブログのテーマがフリーランスと技術的なこととちょっと変化球でトラベル系という感じで固まりつつあるので、一旦旅ブロガーと名乗ってみました。

今回カナダに行く事になったのでカナダに行く前の準備としてカナダに行く前に用意しておくものをまとめてみます。

書類系

パスポート

言わずもがな海外旅行では必須のパスポートです。

航空券販売サイトなどでは必ず、有効期限と残ページ数の確認を促されますが、今一度パスポート確認をしましょう。

eTA

アメリカに入国する場合はESTAという渡航前の事前申請が必要ですがカナダの場合はeTAという電子申請が必要なので必ず申し込みましょう。

所定のサイトに飛んだ後は、個人情報やパスポートの情報を入力して終わりです。

特に問題なければすぐに審査を通過してメールが届くのですが、時間がかかる場合もあるので念のため前もって申請を行うようにしましょう。

またこのeTAの申請は一度申請が通れば再びカナダに入国する際の申請は不要なのですが、eTAがパスポートに紐付いてるので、パスポートを再発行したり更新を行った場合にはeTAの申請が必要なようです。

またカナダですと、トランジットでアメリカを経由することがあるのですが、アメリカを経由する際にもESTAの申請が必要だそうでこれまでにESTAの申請を行っていない人は注意してください。

航空券

これがないと話にならないのですが、忘れずにもっていくよう注意しましょう。

航空券を印刷して持っていくと便名やフライトの時間など確認できるのでプリントアウトして当日持っていきましょう。

携帯に時間などメモしたりWebページをブックマークしておいたりでも良いのですが、携帯の充電が切れたり、失くしたりしてしまった時に困るのでプリントアウトをオススメします。パスポート, eTA, 航空券とお金があれば他のものを忘れても最悪カナダには行けるので忘れないように家をでる前に確認しましょう。

航空券はすでに購入済みかもしれませんが、今回の旅行ではエアトリを利用しました。

これまではExpediaを利用したりしていたのですが、謎のエラーに見舞われ予約ができなかったのでエアトリを使って航空券を予約しました。

航空券の選びやすさはExpediaの方が選びやすくて好きでしたが、謎のエラーに見舞われたり、何か予想外のことがおきたり、問い合わせをしたりという時に窓口が日本だととても安心できるのでエアトリの方が良さそうです。サイト内のアテンドも丁寧でExpediaに比べて安心して航空券を購入することができました。

海外旅行保険

クレジットカードに付帯する保険があるからいいやという方も多いかと思うのですが、クレジットカードの付帯保険は適用範囲や補償額が少ないので注意が必要です。

海外で万が一事故に見舞われて入院したり、山中で怪我をしてヘリで運ばれたりと言った事故に会うと目を覆いたくなるような額が請求されます。

海外旅行保険自体も5000円程度で加入できるので事故の際の請求に耐えられる余裕のある方以外は加入されることをオススメします。

電化製品系

モバイルWiFi

カナダですとWiFiが使える場所はホテルやカフェなど多くあると思いますが、念のためにも持ち運びできるWiFiがあると便利です。

WiFiの受け取り、返却は当日空港でできるのであらかじめネットで予約を行い当日受け取りカウンターで受け取り、帰り際に返却Boxに返却という感じで負担なくWiFiをレンタルできます。

多くの会社で申し込みの際に空港の受け取り場所、返却場所を指定するするのですが間違ったターミナルを指定してしまうと無駄に遠くまで取りに行かなければならないので、事前に出発ターミナル、到着ターミナルを調べて申し込みましょう。

私が旅行に行く際はよくグローバルWiFiを利用しています。こちらのバナーから申し込みを行うとレンタル量を5%OFFでご利用いただけますので、興味のある方はこちらからお願いします。

モバイルバッテリー

ただでさえ不慣れな土地なのに、普段頼りにしているスマホ様の充電が切れてしまったり、楽しみにしていた観光スポットで電池が切れて写真が取れないというのでは元も子もありません。

旅行前に充電満タンにして一番信頼できるモバイルバッテリーを持って行きましょう。

コンセント

コンセントのプラグの形状は海外旅行前にチェックしておきたい項目の一つです。

カナダは日本のコンセントと同じタイプなので、日本で使用しているコンセントがそのまま使えます。変換プラグなどは不要です。

アプリ

Uber

Uber Eatsなどもありだいぶ浸透してきた感じがあるのですが、まだまだ知らない人も居るので紹介しておきます。

アメリカ発のタクシー配車アプリで、カナダでも使用できます。普通のタクシーよりも安くて、自分の現在地にUberドライバーを呼び寄せて目的地まで連れて行ってもらえます。

クレジットカードを登録しておけばカードで決済できますし、あらかじめ目的地をマップで指定するのでわざわざ口頭で目的地を説明する必要がありません。

英語などでのコミュニケーションが苦手な人は是非活用されると良いと思います。

※バンクーバーなどのブリティッシュコロンビア州では、**2019年4月現在Uberのサービスが州から認められておらず、バンクーバー含むブリティッシュコロンビア内ではUberが使用できないようです。**バンクーバーではタクシーの利便性がそれほど高くなく、その代わりにバスが比較的便利かつ安価なのでそちらを利用している方が多いようです。機会があればそちらについてもまとめますがネットで検索すると結構ちゃんとした記事に行き着くのでそちらを参照頂ければと思います。

Skypeクレジット

Skypeはテレビ会議やテレビ通話などで知っているか方も多いと思うのですが、Skypeクレジットを使うとSkypeの連絡先でなく通常の携帯や固定電話に電話をかけることができます。

あらかじめクレジットカードからチャージをしておいて通話時間に応じてそのチャージ分から料金が支払われます。

現地で使える携帯電話などをレンタルしなくても国内で使っている自身の携帯から電話をかけることができるので重宝します。 (昨年空港でクレカを失くした際の電話で使用しました。。助かりました)

衣類系

スリッパ or サンダル

パスポート、航空券などと比べると地味ですがあると便利なのがスリッパorサンダルです。

ホテルの部屋では基本土足で上がるのですがシャワーを浴びた後などにわざわざ靴下とか履きたくないですよね。 そんな時にサンダルとかスリッパがあると便利です。意外と忘れがちなので備忘を兼ねてメモしておきます。

ハンガー

こちらも忘れがちなのでメモです。ホテル内で簡単に洗濯して、干したり濡れたり服を乾かしたりでなんだかんだ必要になる場面は多いです。

まとめ

カナダ旅行に行く前のチェックリストいかがだったでしょうか？

一般的な医薬品持って行きましょうとかとか、航空券販売サイトや航空会社のサイトにあるような網羅性はないかもしれないのですが、ポイントを絞ってまとめてみました。

パスポート、eTA、航空券など重要なもの以外は割と個人的な趣味の部分もあるので参考程度に読んで頂ければと思います。

では。

4月なので新社会人に向けてフリーランスがファーストキャリアを振り返ってみた

Thu, 11 Apr 2019 00:00:00 GMT

フリーランスをしていると年度のまたぎはあまり気にならず、新年度という感じもしないのですが、桜見たり花粉症が辛くなったりで春を感じできたので、ちょっと初心に帰ろうと社会人一年目の頃を振り返ってみました。

4月から新入社員として働き始めて葛藤があったりすると思いますが、その方たちへの参考にでもなればなと思っております。

新卒三年目の会社で社員として初の赴任を実現→撃沈

今でこそフリーランスのエンジニアとしてこうしてブログ書いてますが、会社員時代はインドネシアに海外赴任したことがあります。 (脈絡ないなほんと笑）

厳密には海外赴任といっても赴任のプレ期間に社長に激怒され、結局赴任自体は実現せず、その会社でやる事無くなったのでそのまま退職と言う感じだったのですが、

新卒一年目からインドネシア行きたい！って言い続けて、2年半で社員として初めての海外赴任を実現させたので個人的にちょっと自信を持っています。 (社長が激怒した時も多分ちゃんと謝れば今頃インドネシアに居た気がしてます。)

会社としては中小のSIer、ビジネスモデル的にはエンジニアを派遣してそのフィーが売り上げみたいなよくある中小SIerのモデルなんですが、その会社にはたまたま上海だったり、ジャカルタに支社がありそこのリソースを使ってオフショアしたり、現地の日経企業の受託などをやっていました。

その中で私はご多聞にもれず、エクセルエンジニアでテストのエビデンスを切り貼りしたり、調整のための資料作ったりでいわゆるエンジニア的な仕事はほとんどなくコードを書くといえばたまにくるシェルスクリプトの改修や暇な時間でマクロ組んだりといったWeb系企業のそれとは似て非なるものでした。

今思うと社会人一年目から三年目は本当に世間知らずでこうすればよかったなぁ、あれやっておいてよかったなぁなんてところがたくさんあるのですが、それらについて勝手に振り返って行きます。

今振り返ってどうだったか

そんなこんなで赴任一歩手前で社長に激怒されて日本に帰ってきて即日退職願いを提出してから2年経つのですが、冒頭にも書いたように自分のファーストキャリアを振り返って参考にしてもらうのが今回の目的なので、実際何が良くて何が悪かったのかみたいな所をまとめてみたいと思います。

良かったこと

自分からやりたいことを発信すると道が拓ける

100〜200人くらいの会社でもちゃんとやりたい事を言い続ければ道ができるとわかったのは一定程度の収穫ではありました。

当時社員の中で海外赴任を希望する人自体少なく、社員から海外支社に転勤すると言う人は皆無でした。

そんな中でもちゃんと行きたいと言い続けるとそれなりの席は用意されるのだなというのを体験として知れたのは収穫だったのかなと思います。

インドネシアに行って現地の人と仕事して視野が広がった。

社長に激怒される前のプレ期間に現地の事務所で現地の人達と働く機会があったのですが、向こうの人は17時になるとピュッと帰るし、金曜日のお昼には礼拝に行っちゃうし、現地の人でも礼拝に行かない人が居て「あれ、どうしたの？」って聞くとキリスト教だから関係なかったりするして日本とは違う働き方とか生活習慣を体験できて面白かったです。

インドネシアは女の人の方が真面目に働いて、男の人は結構ルーズだったりするし、みんな陽気だしなどなど、ずっと日本で仕事してると気づかない事があったなーと思ってます。

良くなかったこと

まずは三年と言わず、合ってないと思ったらすぐに方向転換すれば良かった

ここまで読むと凄い海外行きたい勢な感じが出ているかも知れないのですが、実の所どっちかというと私はWeb系自社サービス行きたい勢で1社目の会社は未経験でエンジニアとしてやれるから入った会社だったので会社自体は金融系SIerで自分のやりたい仕事と異なる会社でした。

当時はとりあえず三年というカルマに縛られていたので、社内でやれる一番面白そうなチャレンジが海外赴任という選択肢でした。 (というかインドネシア行きたいだけならそういう会社探して転職してます。)

今思うと最初の会社も早めに見切りつけて、Web系の技術、開発プロセスを使って仕事できる環境に身を置けば良かったなとも思っております。

ベンチャー界隈だと20台前半とかでも全然すごい技術持ってる人もいるのでそういう人に会うたびに「もっと早くこの業界にいれば、、、」と思って後悔しております。

これから社会人一年目とかで働いている方の中にもそろそろ違和感を感じ始めている人もいるかと思うのですが、個人的にはその違和感を大事にしてほしいなぁなんて思います。

会社に居て感じる違和感って結構別の会社、別の環境に身を移すことで解消されたりするので違和感感じたら早めに検知して違和感と向き合えると良いのかななんて思います。

半年あれば転職なり、留学なり、大体の方向性を変えられるので合わないつまらない仕事で時間を無駄にするのは避けられると良いのかなと思います。

制度ができていない海外赴任は苦しい

社長に激怒された件の発端はこれだったのですが、海外赴任の制度ができていない会社で海外赴任するのは待遇面で結構しんどいです。

自分としては会社の給与テーブルとして皆と同じ仕事していたら大した額にはならないことに薄々気づいたので海外赴任というコースを作ってなんかやかんや給料をあげるという魂胆があったのですがそれは見事に撃沈されました。

商社やプラント系などここら辺の待遇面がしっかりしていて海外赴任期間中は給料が倍になったりとかするのですが、中小の社員で海外赴任している人がほとんどないケースとかだとまぁまぁ苦しいです。

私の会社は渡航の際の手当もなく、当初家賃は会社持ちという話だったのに赴任が近づくと自費でみたいな感じで国内で働くのと全く変わらない待遇という感じだったので結構きつかったです。

当時これが不満で役員とやり取りをしていたらそれを見た社長が激怒して「お前が行きたいって言ったのに何様」的な話になってしまったのですが、こういう話は割とあるあるだそうで前例が少ない所に行ったりするとまぁトラブルはつきもののようです。

海外赴任の前例が少なく、これから海外赴任を控えるという方には十分注意して頂ければと思います。

とりあえず三年というカルマについて

振り返りのところで少し触れましたが、ファーストキャリアではなぜだかとりあえず三年みたいな縛りが存在します。私が新卒のころはある程度この教義を信じてはいたのですが今振り返ると全くもって意味のない話に思います。

振り返りにもあったようにこういった言説に囚われた結果、海外赴任といういつかやりたいことではあるんだけど本質的ではなかったり人生の優先度から考えると低い事項にとらわれるということを書いたのですが、とりあえず三年という考え方だけによって考えると現状の枠組みでしか考えられなくなってしまうので、新卒一年目で今後のキャリアを考えるときにはあまり参考にする必要のない言説です。

新卒三ヶ月でやめるなんてとか、一年も経たずにやめるなんてというのを周りから言われることもあるかもしれないのですが自分の行きたい方向が定まっているのであれば全然問題はないです。今のところ企業はどこでも人手不足なので、第二新卒でもやる気と熱意とそのための行動が伴っていれば採用してもらえるはずです。現状やりたいことや現状の環境に不満があるのであればとりあえず三年とか行ってないで早めに自分にどういった環境での仕事があっているのかというのは考えた方が良いです。

とりあえず三年みたいな現状の環境に縛られて、その中での最大値を目指すような働き方はのちのち後悔します。新人のうちはできないことも多いですが、できるようになれること(選択肢）も沢山あるのでそれも踏まえて考えてもらえればと思います。

まとめ

振り返りをした結果、とりあえず三年とか今ある環境で！みたいなのがよくないよねという結論に至ったのですがいかがでしょうか？

社会人になると人から目標を持てというような圧力が高まりやすいところですが現状の環境の中でのゴールではなく人生レベルで自分のゴールについて考えれれると良いのかなと思いました。

こんな偉そうに書いていますが自分自身もこれからどうするか？どうしたいか？みたいなところは一番の課題なのでこういったところをアウトプットして整理しつつまとめながら考えて行ければなと思っています。ここに書いたことが参考にでもなれば嬉しいです。

では。

難解な本、分厚い本の読み方。本を三段階に分けてよむ。

Sat, 30 Mar 2019 00:00:00 GMT

最近ではブログから、本からほんとうに世の中には情報が増えましたがそれらを全て消化するのには到底不可能に思えます。

そのなかでも著名人の読書についてのインタビューなどを読むと月100冊読んでます。などという人もいて卒倒しそうになるのですがよくよく調べてみるとこういった人は普通の人たちと読み方が違うようでこういう形で読んでみると本から自分にとって重要な情報を効率よく吸収できるのかなというところがなんとなくわかってきたので今のうちにまとめておきます。

私の読書事情

自分の読書量は読書家と呼ばれる人に比べると全然少ないですが、一般の人よりは本を読む方だと思っていて月3 ~ 5冊程度は読むのかなと思っています。エンジニアという仕事上技術書を結構読まないといけないんですが、そこまで綺麗に本を消化できているかというとそうでもなく、Amazonでポチッとしてから見事に積ん読されていることもしばしばです。

興味があるので流行りのビジネス書なども買って読むのですが、それらはやっぱり読みやすく書かれていて読者が飽きないような仕掛けがあったり文字数が少なかったりしてパーっと1,2時間くらいで読めてしまうのですが技術書とかビジネス書のなかでももう少しアカデミックなやつはやっぱりそこまでスムーズに読み切ることができません。

ものによってはしっかり腰を入れて読み切ることができるのですが体力がもたず読めても月1冊とか、すごい遅いペースになってしまいます。技術書なんかはあらゆる人がオススメの本を紹介していて、分野も多岐にわたるし、次から次に本がでてくるので全然消化できていないです。

またまた分厚い本をよんだところで何を得たかというのが釈然としなかったりすることもあるので、どうしたら効率よく情報を吸収できるのかというのが最近の課題になっています。

本は三段階に分けて読むべし

最近だと、「これ読まなきゃな」という本の一つにエリック・エヴァンスのドメイン駆動設計という本があるのですが、これがまた分厚く内容も難解で一度読み始めて挫折した本でした。

ところが最近、分厚い本には真っ向から勝負してはいけないということがわかってきて、どうやら三段階くらいに分けて読めば良いのではということがわかってきてエリックエバンス本も倒しにかかり始めたのでその方法を紹介したいと思います。

その三段階というのが、

概要を知る
気になるところを読み返す
繰り返し読む

という感じになります。技術書や専門書、アカデミックな専門書などは真正面から最初から最後まで読み切ろうとすると結構体力がいります。

無理やり読みきったところでなかなか頭に入っていなかったりということが多いので、読書の段階を三回くらいにわけて目的を持って読みすすめられると良いと思います。

1. 概要を知る

まず最初の読書では全体像を知るために、目次から本を読んでいきます。

本の最初の方には大抵目次があるので当たり前かもしれないのですが、目次をパラパラ見ながら自分がすでに知っていることかそうでないか？興味ある分野かない部分かということを分類していきます。

そのあと実際に読み進めるのですがあまり立ち止まらずに太字など目に入る部分を頭に入れながら読み進め全体のロジックなどを把握していきます。ここではそこまで深く読み進める必要はなくキーワードなどを拾いつつ、ふとした時にまた読み直したいと思ったら戻ってこれる程度で良いのでスピード重視で本を読み進めます。

ここでは、全体像の把握と目次を見てつけた辺りとの差異を把握しながら

「ここ良い事書いてあったから読みたい！」

というところを見つけることに注力します。ここの作業では本の厚さにもよりますが30分から60分ほどを目安に終わらせると良いと思います。

2. 気になるところを読み返す

1の段階でまた読みたい、もっと深く理解したいというところがない場合はここをやらなくても良いのですが、1の段階でこれがある場合はちょっと時間を置くか別日に読み直します。 1と続けてやれれば良いのですが、私の場合集中力が続かず、字を目で追っているだけで頭には入ってないような状態になるので、仕切り直して頭がフレッシュな時に読み直します。

ここはそこまで工夫する必要なく一回目で分からなかったところやもっと理解したいところなどまた読みたい、知りたいと思った所を読み返すだけです。

ピンポイントで読むのも良いし、また目次に戻って全体像を把握してから読むのでも大丈夫です。

3. 繰り返し読む

2.まである程度読んでいれば本の内容は結構頭に入っているのですが、本は繰り返し読むのが大事です。

単純に書いてある内容を忘れるということもあるのですが、本を1、2回読んだだけだと自分の先入観があって新しい情報が入ってこなかったりします。 なので、本の内容を忘れかけたころにもう一度本を読んでみると新しい発見があったりします。良い本は読み返すたびに新しい発見があるので繰り返し読むことをおすすめします。

本は全部読まなくても良い、目的を絞って本を読む

ここまで読書のフェーズを三段階くらいにわけるという話をしてきましたが、この読書法の本質的なところは本を全部読まなくても良いということに気づくというところだと思います。

小説などの物語は全部読むことで楽しむということが目的ですが、そのほかの本というのは何か自分の悩みだったりを解決するアイデアや新しい知識の獲得を目的に本を読むので、自分に役に立たないところは無理して読む必要はないわけです。

分厚い本を目の前にすると「この本を読もう！」とついつい読み切ることに意識が向いてしまいがちなので、そうではなく**「この本からどういう情報をえるのか？」というところや本を読むための動機を意識しながら読む**ということが大切です。

世の中にはたくさんの本がありますが、私たちの時間も限られているのでいかに効率よく情報を収集するのかというのは引き続き伸ばしていきたいですね。

では。

一フリーランスエンジニアがフリーランス白書2019をよんでみた。考察とまとめ。

Tue, 26 Mar 2019 00:00:00 GMT

「一般社団法人プロフェッショナル＆パラレルキャリア・フリーランス協会」から毎年発行されているフリーランス白書2019年版をよんでみたのでまとめとその感想をかいていきたいと思います。

タイトルに一フリーランスがといれたので簡単に自己紹介をしておくと、私自身フリーランスのエンジニアをしておりスタートアップやベンチャー企業中心に開発のお手伝いをさせて頂いています。フリーランス歴はまだ一年ちょっとと短いですが他人ごとではなく、世の中のフリーランスの動向を知っておくためにもフリーランス白書を通して読んでみました。

フリーランス協会って何をしているの？

フリーランス協会は、2017年に設立されたフリーランスの支援団体です。メルマガ・SNSでの情報発信やイベント・セミナーの開催や有料会員の特典となる「フリーランス向けベネッフィットプラン」などを提供、「誰もが自律的なキャリアを気づける世の中へ」というビジョンを掲げ、現状テーマ別に9つのプロジェクトを通してフリーランスを支援しているようです。

その9つのプロジェクトの一つが今回の白書・調査プロジェクトでそのアウトプットして発表されたものがフリーランス白書であるようです。フリーランスというテーマに絞った調査は数が少ないはずで、一フリーランスとして世の中の動向を知れるというのはだいぶ有難いです。

フリーランス白書2019のまとめ

リンクはこちらです。

フリーランス白書2019

©一般社団法人プロフェッショナル＆パラレルキャリア・フリーランス協会「フリーランス白書2019」

フリーランスのワークエンゲージメント

様々な記事でも強調されているように、2019版ではワーキングエンゲージメント（仕事に対する熱意）に関する記述が強調されています。

これは日本が「熱意溢れる社員」の割合が6%で調査した139カ国中132位と最下位クラスだったことを念頭に置いたもので、フリーランスの熱意の平均が欧米諸国のそれに近しい値を記録したということが白書の中で強調されています。

厳密には日本が132位という低いランクを記録した調査で使用された「熱意」の概念と微妙にことなる部分はあるそうなのですが、それにしても正社員とフリーランスを比較した時に顕著な「熱意」の違いがみられたことは今回の調査の発見だったようです。

日本人のワークエンゲージメントの平均が2.8~2.9前後で今回の調査における会社員の平均値は2.40だそうで、それに比べてフリーランスのエンゲージメントは4.0と欧米諸国にひけを取らない数字であったようです。

引用: https://hp3.jp/wp-content/uploads/2018/05/08JSUC.pdf

フリーランスの課題について

白書は前半部分で正社員とフリーランスに関する比較を行なっていましたが、後半部分ではフリーランスの課題についても触れています。

引用: フリーランス白書 2019

それぞれ大きく分けて

契約トラブルなどの最低報酬などのビジネストラブル・ビジネスリスク
健康保険
出産・育児・介護などのセーフティーネット（休暇や所得保証）

などが挙げられており、調査の結果「フリーランスや副業をするといった新しい働き方を日本で選択しやすくするためには、何が必要だと思いますか？」という設問に対する回答としては2. 3.などのライフリスクに関する項目多くあがり白書ではその対策として働き方改革の一貫としての社会保障制度の見直しが挙げられていました。

白書ではそこからさらに突っ込んで、「自己責任論」についても触れられておりこの論調がフリーランスの一番根深い課題だと論じていました。

感想・考察

フリーランスの分類

フリーランス白書をちゃんと読む機会がはじめてだったので、月の平均稼働時間にでフリーランスを分類するやり方が「そんな風にわけるのね」という感じで新鮮でした。

白書によると以下の分類にされるらしく

月の平均稼働時間が60時間未満	すきまワーカー
月の平均稼働時間が60時間以上140時間未満	時短ワーカー
月の平均稼働時間が140時間以上200時間未満	フルタイムワーカー
月の平均稼働時間が200時間以上	ハードワーカー

ここに自分を当てはめると時期によっては140時間を下回ることもあるし、200時間を超えることもあるのでだいたい「フルタイムワーカー」となるんですかね。ただ、こうしてブログを書いている時間とか、コード書いている時間とかいれると「ハードワーカー」かなというかんじですね。

フリーランス白書を読むとどういう仕事をしている人が年収が高いとかそこらへんをざっくり知ることができるので、これからフリーランスになるあるいは現状フリーランスという方は一度みてみると良いかもしれません。あくまでも平均をとっているのでそこに乗っかる必要はないと思うのですが、世間的に自分がどういう所にあるのかというのはみてみるとよいかもしれません。

エンゲージメントについて

まとめにも書きましたが、白書ではフリーランスの方が仕事の熱意が高いという結果が出たということでたようです。個人的な感想としては「まぁそうだよなぁ」という感じです。結果が出たあとの感想なので調査の結果が出たことに意味があるのはわかっていますが、結果を聞いた素直な反応としては想定内という感じです。

エンゲージメント自体は、**「活力」「熱意」「没頭」**の3要素からなるそうですが、今回の調査では「キャリア自律」「専門性コミットメント」をその要因として比較調査したそうですが、会社員としているとどうしても組織の都合で担当業務が決まりがちなのでこれらの値がフリーランスに比べて低いのはある程度予想がつくのかなと思います。

会社員だと「この仕事やりたいです！」とは言えますが組織の都合上「この仕事はやりません」とは言いづらいですよね。フリーランスの場合は単純に断ったり、営業をかける先を見極めてある程度自分のやりたくない仕事は避けるということができるので、この数値に差はつきそうですよね。

もっと言うとフリーランスでキャリア的に自律していなくて専門性コミットメントが低いという状態があまり想像できないです。

白書によると、キャリア自律とは、組織に依存せずに、能動的に自分の意志で自律的にキャリアを形成すること、専門性コミットメントとは、自らの専門性に関する意識で個人における専門性の領域が明確で、高めるための計画があり努力を惜しまないだそうです。

現状会社員はキャリア自律と専門性コミットメントを求められずに働ける場所というメリットを持ちつつ存在している働き方なので、こういう結果が出るのはある程度頷けますし、先に書いた組織の都合によるキャリア形成を否とする人がフリーランスになる側面があるので殊更驚くことではないのかなと思います。（このメリットをフルに享受している人もいるし、会社員と言う安定した立場を利用して専門性を高めているので一概には言えませんが）

ただ、熱意と生産性は必ず関係してくるはずなので、低い生産性が問題になっている現段階ではフリーランスという働き方を広げていくにあたっての説得力のある根拠にはなるのかなとは思いました。

会社員とフリーランスの意識の差について

引用: フリーランス白書 2019

調査の一部でフリーランスと会社員のスキルに対する意識比較に関する図があるのですが、個人的に以下のような記事を書いている手前なかなか面白い結果でした。

上図は「現在の働き方を続ける/成功させる上で重要だと思うもの」についての回答結果だが、「自分を売る力」は50ポイント近く正社員とフリーランスで差があり、顧客/市場のニーズの把握力は30ポイント以上差があり、逆に会社員が今後重要なスキルが「忍耐力」という結果だったようです。

正社員という働き方を続ける上で重要だと思うものは？

→忍耐力が必要

→この先も我慢し続けるなんていやだ

→現状を変えよう！

なら良いのですが、これがこれからも同じ働き方を続ける前提でこれからはずっと我慢 だと思っちゃっているのであればそれはちょっと悲しいですね。

結果、フリーランスの方は、上のような記事を読むまでもなく**「自分を売る力」や「顧客/市場ニーズの把握力」は必要だと回答し、会社員は「忍耐力」「前向きな姿勢」**が一番必要なスキルだと考えているようです。個人的にはセルフブランディングや市場ニーズの把握などの「マーケット感覚」は働き方問はず必要なものであるとは思っているのですが、残念ながら会社員は前向きに忍耐を続けていれば現在の働き方を続けられる/成功できるというように考えているようです。

企業側からみたフリーランスの活用について

白書では企業側からのフリーランス活用法についても書いてありますが、

「企業側は契約期間や稼働ボリュームなどの条件面からフリーランスを探しがちだが、解決したい課題とゴールイメージからフリーランスを探した方がいい」

というアドバイスが印象に残りました。続けて、エンジニアの場合は使用言語や経験年数を問うよりも「このプロジェクトの課題を解決できる人」という方向で探すことをオススメする」ということも書かれており、「フリーでエンジニアになるとどういう言語を専門で扱って・・・」みたいな考えに偏りがち だがそもそも「自分が何ができて何の課題を解決できるのか？」ということが意識できないとダメだし、現状それがないのであれば何を身につければ課題解決のスキルが身につくのかということも意識しないといけないと思いました。

自己責任論について

引用: フリーランス白書 2019

白書では、フリーランスの自己責任論について問題提起されていましたが画像にもあるように、独立、起業にはそれを選択する人の割合が少ないからか本人が好きで自由を選んだんだから、自由とのトレードオフでリスクはないとダメだよねという考え方が定着しています。

ところが白書では誰もがフリーランスを選択できる社会の方がこれから**「人生100年時代」「一億総活躍」**などのキーワードと照らしても良いよねということが書かれていて「なるほどなー」と思いました。

私自身も読む前まではどちらかというとフリーランスは社会保障も会社員より手薄なので、ある程度の覚悟を持って働くべきという考えをもっている自己責任的な考え方でしたが、白書を読んでみるとたしかに一人一人にあった働き方を選べる社会の方が良いし、そこで無理に自己責任論を持ち出して進歩を止める必要もないなと考えるようになりました。

自己責任論は、フリーランスも含め生活保護などさまざまな社会問題で持ち出されがちですが、自己責任論的な考え方は思考を硬直させて住みやすい社会をつくるのには結構邪魔になるものなんだという気づきがありました。

まとめ

白書をみてみて色々な気づきがありましたが、個人的には自己責任論のところが一番大きな気づきだったように思いました。 「だれか他人が失敗して大変な目にあっている」→「自己責任でしょ」 というロジックは発展性がないので自然とこういう思考になってしまうというのはあまりよくない癖なのかなと思いました。

もちろん本当に自己責任なケースもあるのかもしれないですが、もう少し視野を広くもって考えてみると意外とそうではないということがあるような気がしました。

他にも、白書自体フリーランスの実態を調査した結果が載っているので、今の所フリーランスってどういう感じなのかなというのを知るためにもフリーランスの方は一度白書を読んでみると良いと思います。

フリーランスをやっているとフリーランスの仲間内での情報は入ってきますが、こういった全体的な情報も貴重かと思うのでオススメさせていただきます。

では。

GatsbyサイトでGoogle Analyticsのトラッキングをする

Fri, 22 Mar 2019 00:00:00 GMT

ちょうど今年1月に下記のような記事を書いてから2ヶ月がたち、私のGatsby運用暦もそろそろ3ヶ月ほどにもなろうかというところです。

そんなこんなでブログを初めてGoogle Analyticsを自分のサイトにいれているとページごとPV とかが見れて、へぇーこの記事こんな読まれているんだーとかとかがわかるのですが人間よく深いものでもっと自分のサイトに訪れた人の行動が知りたいとなってきます。

そんな経緯で自分のサイトにGoogle Analyticsのトラッキングをしてみようということになったので、そこらへんについてまとめてみます。

自分のサイトにanalytics.jsを設置する。

ここらへんはすでに自分のサイトにGoogle Analyticsを導入している人は、設置済みだと思うのですがトラッキングにはGoogleAnalyticsのスクリプトを読み込む必要があるのでこれは必須の作業になります。

普通にWordpressやその他のプラットフォームで運用している方はそのプラットフォームに準じた方法をとってもらえれば良いのですが、Gatsbyの場合はこのプラグインを使ってanalyticsを読み込むことができます。

gatsby-plugin-google-analytics

細かいいれ方はサイトを参照して頂ければとは思うのですが、簡単に説明すると

npm install --save gatsby-plugin-google-analytics

yarn add gatsby-plugin-google-analytics

といういつもの感じでライブラリを追加して、gatsby-config.jsを編集して設定してきます。プラグインの導入はトラッキングIDの設定が必要なので下記のように設定します。

{
  resolve: `gatsby-plugin-google-analytics`,
  options: {
    trackingId: [ Tracking ID ],
  },
},

注意点としてはyarn run developのように開発用の環境ではanalytics.jsは読み込まれず、ビルドするとanalytics.jsが読み込まれるのでその点は間違ってはまらないように注意してください。

Trackingイベントの仕込み方

今回はクリックイベントに絞って紹介しますが、analytics.jsを使ってあるボタンやリンクが押された場合に、

ga('send', 'event', {
  eventAction: 'click',
  eventCategory: 'some category',
  eventLabel: 'some label'
});

このようなスクリプトを実行させることで、ユーザがクリックしたということをAnalyticsに通知して、あとあとAnalyticsのコンソールからいつ、どのページでそのクリックイベントが発生したのか？ということが確認できるようになります。

ここで問題になるのは、このイベントの送信をどのようにサイト内に設置していくかというところです。 ECサイトのようにパーツを使いまわして、設置できるような場合であればそのコンポーネントに上のスクリプトを設置しておけば良いのですが、ブログなどだといちいちそのパーツを持ってこないといけないので結構手間になりますし、記事内のある箇所が押されたかどうかをみたいのに、都度上のスクリプトを埋め込むようなことはやりたくありません。

そこで、イベントの送信を効率良くサイトに設置するためにはaddEventListnerとHTMLのクラスを使ってサイト上であるクラスに対してイベント送信のイベントを設定してユーザがその要素をクリックしたら関数を実行させるようにします。

具体的なコードは以下で、下記コードをサイトのそれぞれのページで読み込ませるようにすれば準備完了です。


// イベントを登録する用の関数
const eventRegister = ({ga, location}) => (
  selector,
  event
) => {
  document.body.querySelectorAll(selector).forEach((ele, index) => {
    ele.addEventListener(event, () => {
      const id = ele.id || 'elements-' + String(index + 1)
      const label = location.href + '#' + id;
      const eventCategory = selector.replace(/^\./, '').replace(/^#/, '')

      eventTracker(ga, ele, event, eventCategory, label);
    });
  });
};

// イベントを送信する部分
const eventTracker = (ga, ele, eventAction, eventCategory, eventLabel) => {
  const object = {
    eventAction,
    eventCategory,
    eventLabel,
  };
  ga('send', 'event', object);
};

const batchEventRegister = ({ga, location}, selectors, event) =>
  selectors.forEach(selector => eventRegister({ga, location})(selector, event))

// トラッキングするセレクタ群
const selectors = [
  'tracking-element-1',
  'tracking-element-2',
  'tracking-element-3',
  'tracking-element-4',
]

batchEventRegister(window, selectors, 'click')

これが設置できたら、あとは記事を書いていくと時にここのスクリプトで指定したセレクタをクリックイベントを検知したいに付与して、要素がクリックされるのを待つだけです。

トラッキングする箇所全てにイベント送信のコードを埋め込むのはさすがにほねが折れるので、こういった方法でトラッキングを楽にできるとよいかと思います。

まとめ

以上、今回の話はGatsbyに限定されず様々なサイトで使えるテクニックだとは思いますが、Gatsbyのサイトで試したのでタイトルもそのようにしてみました。

本文ではかかなかったですが、クリックイベントと同時にSlackへの通知も飛ばすようにしておくと、自分の携帯に通知が入るようになるのでおすすめです。頻繁にイベントが発生するとちょっと煩わしくなりますがレアなイベントをトラッキングしておくと通知が来ただけで幸せな気持ちになれるのでおすすめです。

では。

Go言語で数独（ナンプレ）を解くコードを書いてみた

Mon, 11 Mar 2019 00:00:00 GMT

改めてアルゴリズムを勉強したり、英語のリソースを漁ってみるとかなりシンプルな解法があったのでそちらを紹介します。コードはこちらです。ざっくり100行くらいでほとんどの数独の問題が解けるはずです。

https://github.com/version-1/go-numpre

再帰を使って実装しているのですが、再帰を使うと本当信じられないほど短いコードで実装できますね。実装にあたってはこちらの動画を参考にしました。

Python Sudoku Solver - Computerphile

↓↓↓ 以下元の古い記事

最近Goの勉強をしており（とはいえ割とマイペースではありますが）これらの記事をあげたりしているのですが、

これらの記事にほとんどといっていいほどコードを書いていなかったので今回は実際にコードを書いてみました。タイトルは若干盛っている部分もあるのですが、今回書いたコードでは初級レベルの数独の問題だったら解けるコードです。

数独にはある決まった解き方でマスに入る数字を限定して解いていくのですが、数独もある程度のレベルになると数字が限定できなくなり別の解き方で数独をとく必要がでてきます。なので、今回は数独のルールにのっとって数字を限定して解く解法で答えをだせる問題を解くコードになります。

もっと難しい問題を解けるプログラムを組みたい場合は、こちらの記事を参考にされると良いと思います。（気が向けばこちらのコードも書いてみたい）

数独のアルゴリズムを考える

数独（ナンプレ）とは？

ナンプレとは9 * 9 マスのマスにあるいくつかの数字があらかじめ埋められており、ルールにしたがって数字を埋めていき最終的にルール通りにマスを埋めていくパズルです。

数独のルールというのは、大きく3つで

縦1列に1から9までの数字がひとつずつ入る。
横1列に1から9までの数字がひとつずつ入る。
9 * 9 のマスを9つに分割した3 * 3のマスにも1から9までの数字がひとつずつ入る。

というようになっています。

はじめは下の画像のようになっており

全部時終わると以下のようになります。

そして、こちらが実際に数独を解いている様子。

今回はこのようにコードをGo言語で書いたのでそれの解説をしていきます。

数独をGo言語で解く意義

Go言語で解く意義ですが、特に意味はありません。単に私自身勉強中だからです。

個人的に採用している勉強法として新しい言語を学ぶ時は、

文法事項に目を通す
簡単なアプリケーションを作ってみる

というような順序で普段から勉強しているのでGo言語の教材として数独を解くコードを書いています。プログラミング初心者の時から基本的にこうして勉強しているのですが、この本の勉強方法を参考にしているところもあるかもしれません。

SOFT SKILLS ソフトウェア開発者の人生マニュアル

プログラミングは理論でわかっていても実際どのような挙動になるかわかっていたり、こういうロジックを書く場合はこういう書き方をするというのが瞬時にでてくるようにならないと実際にコードをかけるようにならないので2.の段階では最初に作りたいものがあって、それを作るために必要なものを調べていくという流れで勉強を進めていきます。

その過程で初めて知ったことは予想と違った動きをした場合は、それを記憶にとどめて徐々に言語に慣れていくというスタンスをとっています。

少々本筋とはずれた話題になりましたが、次からは本題に戻り実際のコードの解説になります。

コードの解説

色々と前置きありましたが、ここからコードの説明をしておきます。リポジトリは以下に置いておきます。

https://github.com/version-1/go-numpre

コードは以下です、意外と200行行かないですみました。特にファイルを分割せずだらっと長く書くスタイルで書いています。

(始めたばかりでまずい書き方しているところもあるかもしれないのですが、ひとまずこれくらいで気づいたら改善していきます。)

package main

import (
  "flag"
  "fmt"
  "strconv"
  "strings"
)

type Result struct {
  N         int
  X         int
  Y         int
  Ok        bool
  Value     int
  Candidate []int
  Empty     int
  Field     [][]int
}

func main() {
  const size = 9
  const maxTry = 1000
  flag.Parse()
  numStr := flag.Arg(0)
  field := load(numStr, size)

  fmt.Println("")
  fmt.Println("[START]")
  empty := counting(field, size)
  result := Result{Field: field}
  printResult(result, size, false)
  n := 0
  for empty > 0 || n < maxTry {
    for i := 0; i < size; i++ {
      for j := 0; j < size; j++ {
        n++
        cursorValue := field[i][j]
        if cursorValue == 0 {
          candidate := buildCandidate(size)
          value, ok, filteredCandidate := filter(field, j, i, size, candidate)
          if ok {
            field[i][j] = value
            empty--
          }
          result = Result{N: n, X: j, Y: i, Ok: ok, Value: value, Candidate: filteredCandidate, Empty: empty, Field: field}
          printResult(result, size, true)
        }
      }
    }
  }

  if empty == 0 {
    fmt.Println("[END]")
  } else {
    fmt.Println("[FAILED]")
  }
  printResult(result, size, false)

}

func load(numStr string, size int) [][]int {
  field := [][]int{}
  for i := 0; i < size; i++ {
    start := i * size
    end := start + size
    array := []int{}
    row := numStr[start:end]
    for _, v := range strings.Split(row, "") {
      value, _ := strconv.Atoi(v)
      array = append(array, value)
    }
    field = append(field, array)
  }

  return field
}

func printResult(r Result, size int, header bool) {
  if header {
    fmt.Println("")
    fmt.Println("n :", r.N)
    fmt.Println("(x, y) :", r.X+1, r.Y+1)
    fmt.Println("ok :", r.Ok)
    fmt.Println("value :", r.Value)
    fmt.Println("empty :", r.Empty)
    fmt.Println("candidate :", r.Candidate)
  }
  for i := 0; i < size; i++ {
    fmt.Println(r.Field[i])
  }
}

func counting(field [][]int, size int) int {
  n := 0
  for i := 0; i < size; i++ {
    for j := 0; j < size; j++ {
      if field[i][j] == 0 {
        n++
      }
    }
  }
  return n
}

func buildCandidate(size int) []int {
  candidate := []int{}
  for i := 0; i < size; i++ {
    candidate = append(candidate, i+1)
  }
  return candidate
}

func filter(field [][]int, x int, y int, size int, candidate []int) (int, bool, []int) {
  _candidate := make([]int, len(candidate))
  copy(_candidate, candidate)
  funcs := []func([][]int, int, int, int, []int) []int{filterVertical, filterHorizontal, filterBox}
  for _, cb := range funcs {
    _candidate = cb(field, x, y, size, _candidate)
    if len(_candidate) == 1 {
      return _candidate[0], true, _candidate
    }
  }

  return 0, false, _candidate
}

func filterVertical(field [][]int, x int, y int, size int, candidate []int) []int {
  _candidate := make([]int, len(candidate))
  copy(_candidate, candidate)
  for i := 0; i < size; i++ {
    value := field[i][x]
    if y != i && value != 0 {
      _candidate = remove(_candidate, value)
    }
  }
  return _candidate
}

func filterHorizontal(field [][]int, x int, y int, size int, candidate []int) []int {
  _candidate := make([]int, len(candidate))
  copy(_candidate, candidate)
  for i := 0; i < size; i++ {
    if x != i && field[y][i] != 0 {
      _candidate = remove(_candidate, field[y][i])
    }
  }
  return _candidate
}

処理の流れ

処理の流れは、

コマンドライン引数より問題の読み込み
最初のマスの状態を表示
1マス目（[x = 0, y = 0], [x = 1, y = 0], [x = 2, y = 0] ...)から順にマスの値を取得
3が空の値(0)だったら、ルールを使って候補をフィルタリング
4.の結果候補が一つに決まったらマスに数字を入れる。
処理後のマスの状態を表示
空の値がなくなるまで3~6を繰り返す。
最終的な状態を表示して終了。

となります。goの処理はmain関数から始まるので処理の流れはmain関数にべたっと書いています。

下記インラインで上の処理をコードに合わせてコメントに書いています。

func main() {
  const size = 9
  const maxTry = 1000
  flag.Parse()
  numStr := flag.Arg(0)
  // 1. コマンド引数から問題を読み込み
  field := load(numStr, size)

  // 2. 最初の状態を表示
  fmt.Println("")
  fmt.Println("[START]")
  empty := counting(field, size)
  result := Result{Field: field}
  printResult(result, size, false)
  n := 0
  // 8. 空の値がなくなるまでループ（無限ループ対策として、試行回数が1000回を超えたら失敗としてループを抜ける）
  for empty > 0 || n < maxTry {
    for i := 0; i < size; i++ {
      for j := 0; j < size; j++ {
        n++
        // 3. 左上のマスから順番に値を取得
        cursorValue := field[i][j]
        if cursorValue == 0 {
          candidate := buildCandidate(size)
          // 4. ルールを適用して値を取得
          value, ok, filteredCandidate := filter(field, j, i, size, candidate)
          // 5. 候補が絞れたらマスに結果を反映
          if ok {
            field[i][j] = value
            empty--
          }
          // 6. 処理結果を表示
          result = Result{N: n, X: j, Y: i, Ok: ok, Value: value, Candidate: filteredCandidate, Empty: empty, Field: field}
          printResult(result, size, true)
        }
      }
    }
  }

  // 8. 処理結果を表示
  if empty == 0 {
    fmt.Println("[END]")
  } else {
    fmt.Println("[FAILED]")
  }
  printResult(result, size, false)

}

候補の絞り込みについて解説

前の項目では全体の処理の流れを説明することがメインだったのであまり詳しく説明しなかったのですが、この数独を解くキモの所の回答の候補を絞り込む部分をサッと説明してしまったのでここではもう少し詳しく説明していければと思います。

先に説明した通り数独には縦、横と3 * 3のマスにそれぞれ1から9までの数字が入るというルールを盛ってそれぞれの81マスに入る数値を絞り込んでいきます。

今回のコードでは

縦のルール(filterVartical関数)
横のルール(filterHorizontal関数)
3*3のマスのルール(filterBox関数)

を適用して候補を絞り込み最終的に取りうる値が1つになったら二つ目の返り値でtrueを返すような仕組みにしてます。

今回のコードではそれぞれのルールで適用する関数に切り分けたので、それぞれの関数を順番に候補（1から9の数字の配列）に適用していって、最終的に配列の長さが１になったらマスを埋めるという方法をとっています。

幾分Goに不慣れなので関数の配列を作るのにちょっとハマりましたが、おかげで当初の

func filter(field [][]int, x int, y int, size int, candidate []int) (int, bool, []int) {
  _candidate := make([]int, len(candidate))
  copy(_candidate, candidate)
  _candidate = filterVartical(field, x, y, size, _candidate)
  if len(_candidate) == 1 {
    return _candidate[0], true, _candidate
  }
  _candidate = filterHorizontal(field, x, y, size, _candidate)
  if len(_candidate) == 1 {
    return _candidate[0], true, _candidate
  }
  _candidate = filterBox(field, x, y, size, _candidate)
  if len(_candidate) == 1 {
    return _candidate[0], true, _candidate
  }

  return 0, false, _candidate
}

のような重複の多い残念なコードよりは幾分ましになりました。

あらかじめそれぞれの関数のコードのインターフェースを揃えておいたので、数独のルールを適用する部分が割とすっきり書くことができました。それぞれの関数の中身はコードを見ればわかるとは思うのですが、ループを回して

縦、横、3*3の中を走査
0以外の数値かつ今カーソルのあるマスでない場合はマスの値で候補から除外する

ということをやっています。

ここまでで、数独のルールによる絞りこみと全体の処理の流れを説明しましたがいかがでしたでしょうか？ステップ数もそこまでなく、解説する必要があるのはここくらいな気がしたので若干説明のバランスの悪さはいなめないですが、説明はここまでとします。

まとめ

以上、「Go言語で数独を解くコード」を書いてみたでした。

現状では、簡単な問題しか解けませんが、簡単な問題でもこのプログラムさんは一瞬で回答を導きだしてくれます。

Go言語の勉強のためにコードを書いてみましたが、数独をコードで書くと配列だったりスライス、文字列操作などの処理を書くことが多く、それらの文法に馴染めたのではないかと思います。

先を見るとGoでWebAPI作るくらいのところまでやりたいのですが、まだ構造体とかインターフェース、パッケージとインポートなどの挙動を確かめられていないので、このプログラムを強化しつつ色々と学んでいきたいと思います。

では。

Gatsbyでエイリアスを切って相対パス地獄から抜け出す方法

Thu, 07 Mar 2019 00:00:00 GMT

Gatsbyでインストールして普通にコード書き始めるとimport文などが相対パスだらけになって「なんだかなぁ」っていう気持ちになりますよね。

相対パスでそのままコードを書いていると、下みたいな「結局どこ？」みたいなパスの書き方になりがちです。

import Hoge from '../../../../hoge'

ディレクトリの階層構造が浅いうちは救いもあるのですが、徐々にネストが深くなるにつれて闇が深まっていきます。そんなときにエイリアスを切って、importをスッキリできると嬉しいですよね。

そう、こんな風に

import Hoge from 'path/to/hoge'

単純に相対パスが理解しづらいというデメリットもあるのですが、エイリアスを切って絶対パスのような形でアクセスするようにしておくと、ファイルを移動させたり階層構造をかえる場合にいちいちパスを変更しなくて済むので極力絶対パスでimportしていきたいです。

Webpackを使ってエイリアスを設定

gatsbyはwebpackを使用しているのでwebpackのエイリアスの機能を使うことができます。

https://webpack.js.org/configuration/resolve/#resolvealias

これをGatsbyに設定してあげればエイリアスからのパスでimportができるようになります。

Gatsbyではwebpackの設定を行うためのcallbackが用意されており、onCreateWebpackConfigというコールバックをgatsby-node.jsに書いてあげればwebpackの設定をいじることができます。

https://www.gatsbyjs.org/docs/add-custom-webpack-config/

これをつかってエイリアスを設定するには以下のようにします。

gatsby-node.js

exports.onCreateWebpackConfig = ({stage, rules, loaders, plugins, actions}) => {
  actions.setWebpackConfig({
    resolve: {
      alias: {
        config: path.resolve(__dirname, 'config'),
        assets: path.resolve(__dirname, 'src/assets'),
        components: path.resolve(__dirname, 'src/components'),
        lib: path.resolve(__dirname, 'src/lib'),
        pages: path.resolve(__dirname, 'src/pages'),
        templates: path.resolve(__dirname, 'src/templates'),
        locales: path.resolve(__dirname, 'src/locales'),
      },
    },
  });
};

これで相対パス地獄から無事抜け出すことができます。

react-nativeではこれやろうとして結構ハマったのですが、webpackが入ってると簡単にきできますね。上のコード貼るだけで相対パスから脱出できるのでぜひためしてみてください。

フリーランスには「マーケット感覚」が必要だと思う

Sat, 02 Mar 2019 00:00:00 GMT

マーケット感覚を身につけよう---「これから何が売れるのか?」わかる人になる5つの方法

こちらはちきりんさん著の**「マーケット感覚を身につけよう」**です。これからの自分のキャリアを考える時の基本の考え方にを教えていただいた本で今回この記事を書くにあたって再び読み返してみました。

久しぶりに読んでいて、マーケット感覚というのが漠然と「フリーランスってスキル高いだけじゃだめだなぁ」と考えていたこものへの答えをもらえた気がしました。

本書ではマーケット感覚とは何で？なぜそれが必要なのかという理由とその鍛え方までがわかりやすい形でまとめられているので、一度手に取ってみることをおススメします。

マーケット感覚とは？

マーケット感覚とは「価値を認識する力」で世の中で出回っているサービスや自分が提供しているサービスの「価値」を認識できる感覚のことです。

「あるサービスがだれにどのような形で価値を提供しているのか？」

ということをより解像度高く認識できる人というのはマーケットの感覚を備えている人ということになります。

マーケット感覚 = 「顧客が市場で取引を行う場面を直感的に想像できる能力」

「マーケット感覚」は**「商品サービスが売買されている現場のリアルな状況を想像できる力」や「顧客が市場で取引を行う場面を直感的に想像できる能力」**ともいうことができます。

それは顧客が何を求めて商品を買っているのかを正しく理解するには現場のリアルな状況を想像できる必要があるからです。

例えば、「北海道でカニを食べたい」ので北海道に旅行に行くという人がいたとするとこの人には必ずしも旅行で直接北海道に行ってまでカニを食べる必要があるとはかぎりません。ネットが発展した現代ではネットでちょっと検索をすれば通販サイトで産地直送の北海道のカニが見つかるかもしれません。

この例を航空会社からみてみると顧客を通販サイトに取られてしまったという見方をすることができます。航空会社の競合というとまず真っ先に同業他社が思い浮かぶと思うのですが、この**「商品サービスが売買されている現場のリアルな状況を想像できる力」** をもっていれば航空会社の競合は同業他社や同じ移動という価値を提供している鉄道会社だけではなく状況によってはネット通販会社も競合になりうるということが理解できます。

なぜフリーランスにはこのマーケット感覚が必要なのか？

マーケット感覚を持っているとこのように業界全体を別の角度から捉えることができるようになります。さらにマーケット感覚を鍛えると市場で取引される価値につていの深い理解が身についてくるので**「自分で価値を創出して売る」**ことができるようになります。

フリーランスや個人事業主は会社の社長でないとはいえ、一事業者なので単純なスキル以外にもスキルを「どういう人が欲しているのか？」「どういうスキルが欲されているのか？」あるいは「どういうサービスが市場で不足しているのか」ということを正しく理解する必要があります。

自分をどこで売るべきか、自分が高く売れる市場はどれなのか。「一生懸命頑張る！」前に、どの市場で頑張るべきなのかという市場の選択にこそ、マーケット感覚を働かせる必要があるのです。

引用: マーケット感覚を身につけよう---「これから何が売れるのか?」わかる人になる5つの方法
第3章マーケット感覚で変わる世の中の見え方成功の鍵は市場の選択

例えば、私が行なっている企業様の開発のサポートの仕事では、「エンジニアリングのスキルをもたないか人材が不足している」企業様に対して「エンジニアリングスキル（あるいはシステムを作る）」という価値を提供して仕事をしています。

今後フリーランスという働き方も一般化し、フリーランスエージェント会社の力や世間的な雰囲気の流れで市場にフリーランスエンジニアのの数が増えると思うのですが、「その中で自分がどういう価値を発揮できるのか？」ということは常に考えていく必要があると思います。

自分独自の提供価値を考える上でマーケット感覚は非常に重要でお客様の価値の取引の状況をリアルに思い描いて「自分のできること」と「お客様あるいは市場の欲すること」を一致させたサービスを提供していく必要があります。

例えば自分にエンジニアの知り合いが多くて知り合いの稼働を確保できるのであれば、エンジニアが不足している困っている企業にまとめて人的リソースを提供することができますし、デザインができればUIにこだわったシステムを作りたい企業様に「UIデザイン+エンジニアリング」という価値が提供できます。自分のスキルが何でそれをどのお客様が必要としているのかということは常に考え続ける必要があります。

フリーランスになると闇雲にスキルを伸ばせばよいという考え方に陥りがちなことも多いですが、フリーランスである以上 **「そのスキルはいくらで売れるのか？」**ということは常に意識しながらスキルを伸ばしていく必要があるでしょう。

こういった点からマーケット感覚は「自分は現状どういう価値を発揮して、今後どういう価値を発揮するために行動するのか？」を考える上での大きな指針になり、フリーランスにはとても必要な価値だと思っています。

マーケット感覚の鍛え方

で、マーケット感覚ってどうやって身に付けるの？という話ですが、「マーケット感覚を鍛えよう」の章では 5つの方法が紹介されています。

プライシング能力を身につける。
インセンティブシステムを理解する。
市場に評価される方法を学ぶ。
失敗と成功の関係を理解する。
市場性の高い環境に身をおく。

それぞれ全てを説明することはできないので、詳しい部分は書籍に譲りますが自身の経験としてアジアで仕事したり、旅行したりした経験から物の価値は一つではないという理解できたいことは大きかったなと思っています。

インドネシアなどのアジアの国にいくとあるタクシーでは1000円で行ってくれるのに、他のタクシーでは3000円かかる（例です。）というように日本ののように一つ一つのものに綺麗に値札がつけられているということがほとんどありません。

アジアでは、ローカル価格というように現地人に売る価格と観光客に売る価格をわけているお店が多いです。彼らはどうやら現地人としては珍しくもなんともないものを観光客は面白いと感じて買ってくれるので購入に際して要求する価格が違うようです。

相手によってその商品にどれくらい価値を見出すかというのは一律ではないので、これは当たり前といえば当たり前なのですが、高度に市場化された製品の多い日本に暮らしているとあまり実感できないのかもしれません。

このように個人的な経験から 「一つの物に対する値段は一つでないこと」 「商品に対してどれくらい価値を感じるかは人それぞれなので自分の価値基準をもつこと」

ということを理解しておくことはマーケット感覚を高めるのに必要そうな要素だと思っています。本書では相場というものが他社の判断結果ということを言っていて、相場に頼る人ほど自分独自の価値判断基準をもたない人の典型というようなことを書いています。

フリーランスも自分で値つけをしていかないといけない立場ですから相場に流されず自分の基準で仕事をして価値を発揮していくことが大事そうです。

まとめ

ここまでマーケット感覚とはなにか？なぜフリーランスにマーケット感覚が必要か？どう鍛えればよいのか？ということをまとめましたが、詳しくは書籍をご覧になるのが良いです。

フリーランスは事業者という市場性の高い環境に身を置かざるを得ない環境にあることからマーケット感覚を身につける必要は言わずもがなではるのですが、今後フリーランス人口の拡大とともに「自分をどう売るのか？」ということは考えないといけないテーマ+自分への戒めとしてこちらの記事をまとめさせていただきました。

フリーランスをやっていてなんとなく「単純にスキルが高いだけじゃダメだよなぁ」と考えていたときに「マーケット感覚」という概念を認識できたことで意識する対象が明確になったので今回本を読み返してみてよかったなぁと思いました。

良い本は何回か読み返すと新しい発見がありますね。

では。

JSXに&&やif、三項演算子、mapなどの制御構文を書くのをやめる方法 jsx-control-statements

Thu, 28 Feb 2019 00:00:00 GMT

突然ですがReactを書いているとJSX上に&&を書いたりmapを書いたりif書いたりという感じでJavaScriptの構文が出現しますよね。 コードで書いてみるとこういう感じです。

export default class IFStatementsInJSX extends React.Component {
  render () {
    const { isTrue } = this.props
    return (
      <div>
        { isTrue && <SomeComponent/> }
        <div>
          {
            list.map(item => {
              <ListItem item={item} />
            })
          }
        </div>
      </div>
    )
  }
}

&&やif文での分岐が一つだったりとかであればいいんですけど、三項演算子使っていたりとかネストしていたりすると途端に非常に読みづらいコードになります。

なんとかこれを防げないかと考えていたのですが、jsx-control-statementsという babelのプラグインを使うと上記のような構文がJSXチックにかけるようなのでそちらを紹介したいと思います。

jsx-control-statements

リポジトリはこちらです。

jsx-control-statements

jsx-control-statementsはbanbelのプラグインなのですが、babelの設定をするだけで以下の形でif文をjsxライクで書くことができます。

<If condition={ true }>
  <span>IfBlock</span>
</If>

// mapの代わり
<For each="item" of={ this.props.items }>
  <span key={ item.id }>{ item.title }</span>
</For>

babelの設定自体もconfigにpluginの記述を追加するだけです。

npm install --save-dev babel-plugin-jsx-control-statements

{
  ...
  "plugins": ["jsx-control-statements"]
}

もし、babel pluginでtransform-react-inline-elementsを使用している場合は、transform-react-inline-elementより前にjsx-contorl-statementsを記載する必要がある点は注意が必要です。

Ifタグ、Forタグ以外にもChooseタグというCase文をかけるようなものもあるのでぜひ試してみると良いと思います。

Ifタグ、ForタグはBabelでトランスパイルされるのでimportしたりrequireする必要がないのですが、lintには引っかかる可能性があります。ただ、jsx-control-statements用のeslint pluginもあるのでそちらを利用すれば問題ないようです。

eslint-plugin-jsx-control-statements

まとめ

以上、jsx-control-statementsでJSXから制御構文を追い出す方法について書いてみました。

jsxがこのような制御構文を用意してないのはjsxの責務外だからなんですかね？今度時間があるときに調べてみようかと思います。では。

Go言語の文法を勉強して印象にのこったところまとめ。その4。

Tue, 26 Feb 2019 00:00:00 GMT

Go の文法のまとめをちょこちょことしてみましたが、今回で一通りはまとめ終わりそうです。当たり前のことではあるんですが、これをまとめた所で言語を書けるようにはならないですね。こないだ Go の雰囲気をざっくり感じ取れたと思ったのでいざ Go を書いてみようと思ったのですが、全然ダメでしたね。

書こうとした瞬間に手が止まって「あれ、手が動かない」ってなりました。普段書き慣れている Ruby や JavaScript は色々な関数も知っているし、文法も頭に入っているので 8 割スラスラ 2 割ネットで調べてみたいな感じで書けるのですが Go は慣れてないので一瞬で手が止まりました。Go の基礎の本を読んだ後いざ書こうと PC に向かってみましたが全然ダメです笑。

プログラミングは理論と実践が大事なのでやっぱり活字を読むのと実際にコードを両立していかないとダメですね。

オススメの本

今回もこちらの本を参考にまとめていきます。記事を途中で書いていて気づいたのですが本で使用している go のバージョンが 1.4 とちょっと古いので微妙に挙動が違うかもしれません。。

こちらの本を使って勉強した後は公式のドキュメントなどみながら現バージョンとの違いもおさえておく必要がありそうです。

改訂 2 版基礎からわかる Go 言語

文法のまとめ

並列処理

go はゴルーチンと呼ばれる。並列処理を、簡易的に実装する機構を持っています。Go 言語では go 文を使用して関数をゴルーチンとして呼び出すか通常の関数として呼び出すかを区別します。

go 文の書式は

go 関数呼び出し

とするだけです。

呼び出し側からみたゴルーチンの通常の関数呼び出しと違う点は、ゴルーチンとして実行された関数の終了を待たないことです。

メイン関数内で、ゴルーチンを実行した場合ゴルーチンが終わるより先にメイン関数の処理が終わってしまうと、プログラム自体がゴルーチンを待たずに終了してしまうので注意が必要です。

チャネル

ゴルーチンは非同期的に処理され、戻り値を受け取れないため、処理結果が必要な場合は後で説明するチャネルを使用します。

チャネルはゴルーチン間の通信に使われます。チャネルの書式は送信専用、受信専用の書式がありそれぞれ chan キーワードと矢印キーワードで送受信の制限を記述します。

chan
chan <-
<- chan

チャネルはスライスおよびマップと同じく参照型の一種であり、他の参照型と同様に値を悪性するには「make」組み込み関数を使用します。

make(chan 要素型, キャパシティ)
make(chan 要素型)

チャネルへの値の送受信は<-演算子を使用します。

チャネル <- 送信する値 // 送信
<- チャネル            // 受信

使用しなくなったチャネルは close 組み込み関数でクローズします。クローズ済みのチャネルに値を受信することはできず、クローズ済みのチャネルから受信しようとすると、クローズ直前までに送信されていたチャネルでバッファリングされている値がなくなるまで受信できます。

チャネルがクローズされたかどうか知りたい場合は受信操作から返される 2 番目の返り値が false であればクローズ済みと判断することができます。

close(チャネル)

これらをまとめたサンプルのコードが以下です。

package main

func main() {
  channel := make(chan int) // チャネルの作成
  go func(s chan <- int) {
    for i:= 0; i < 5; i++ {
      s <- i // チャネルの送信
    }
    close(s) // チャネルのクローズ
  }(channel)

  for {
    value, ok := <- channel // チャネルの受信

    if !ok {
      // チャネルがクローズされていた場合
      break
    }

    fmt.Println(value)
  }
}

チャネルを利用した同期

チャネルは受信時にバッファリングが空（どの値も送信されていない状態）では、処理をロックする性質があるのでこれを利用してゴルーチン間で同期的な処理を実現することができます。

この性質を利用したコードが以下で、以下のコードではゴルーチンを3つだけ起動した後にチャネルの受信処理を置いてゴルーチンが同期的に処理されるような実装を行なっています。

package main

import (
  "fmt"
  "math/rand"
  "time"
)

const goroutines = 3

func main() {
  c := make(chan int)

  for i := 0; i < goroutines; i++ {
    go func(s chan<- int, i int) {
      time.Sleep(time.Duration(rand.Int63n(10)) * time.Second)
      fmt.Println("処理完了", i)

      s <- 0
    }(c, i)
  }

  for i := 0; i< goroutines; i++ {
    // ゴルーチンから値が送信されていない場合に値が送信されるまで待機
    <-c
  }
  fmt.Println("すべて完了")
}

値の共用

ゴルーチン間で値を共用するときもグローバル変数などを用いることなく、「チャネル」を使用するのが一般的です。

今日変数の代わりとなる値をチャネルで引回すことによって、複数の「ゴルーチン」で値に同時にアクセスをしてしまうことを防ぎます。


package main

import (
  "fmt"
  "os"
)

const goroutines = 10

func main() {
  counter := make(chan int, 1)

  for i := 0;i < goroutines; i++ {
    go func(counter chan int) {
      // チャネルから値を取り出す
      value := <-counter
      value++
      fmt.Println("counter:", value)

      if value == goroutines {
        os.Exit(0)
      }

      // 更新した値をチャネルに戻す
      counter <- value
    }(counter)
  }

  counter <- 0

  for {}
}

select 文

select 文を使うと複数のチャネルに対して同時に送受信を行うことができます。select 文は switch 文と似ており case 節も一緒に書いていきます。 select 文は case 節に指定したチャネルのうちどれかが通信可能になるまで待機し、どれかが通信可能になると実際に通信を行なった後 case 節内の処理を実行します。

select {
  case 通信式:
    // case節内の通信式が実行された後にされる処理
  case 通信式:
    // case節内の通信式が実行された後にされる処理
  default:
    // それ以外
}

select文を使ったサンプルコードは以下になります。

package main
import (
  "fmt"
  "os"
)

func main() {
   ch1 := make(chan int)
   ch2 := make(chan string)

   go func() {
     for i := 0; i< 10; i++ {
       select {
         case ch1 <- 0:
            fmt.Println("ch1")
         case ch2 <- "test":
            fmt.Println("ch2")
       }
     }

     os.Exit(0)
   }()

   for {
     select {
       case val := <-ch1:
         fmt.Println("receive from ch1", val)
       case text := <-ch2:
         fmt.Println("receive from ch2", text)
     }
   }
}

select文の注意点として、selext文ではfallthrough文を使用することができず、select文内に実行可能なcase節が複数ある場合はランダムに実行（なぜ？？）される点が注意です。

まとめ

以上でゴルーチンのまとめ終わりです。上から順番に実行されるコードであると理解は容易なのですが、JavaScriptのPromise, async/awaitしかりゴルーチンしかりでこれらはちょっと頭使わないと理解が難しいですね。

こういったコードはひたすらコードにふれて慣れていくしかないですね。 Goの文法のまとめも終わったのでそろそろコードを書き始めます。

では。

Gitのフックを使ってGatsbyブログ記事の更新日時が自動で更新されるようにした話

Sun, 24 Feb 2019 00:00:00 GMT

先月くらいにこのブログをWordpressからGatsbyでリプレイスしたのですが、やっぱりWordpressもよくできていて、一度投稿された記事を後から編集した時に更新日時が自動で更新されるて便利なんですよね。 WordpressはDBを使っているから当たり前といえば当たり前なのですが、更新日時の更新漏れとかを防ぐいみでのこの仕組みが欲しいななんて考えていました。

これがベストかと言われるとちょっとわからないのですが、gitのフックを使ってやるのがいいんじゃないかなと考えて仕組みを作ってみたのでその手順をまとめておきます。

Gitのフック

Gitのフックを知らない方のために説明しておくと、Gitではクライアント側ではコミットの前やコミットの後、サーバー側ではプッシュされる前や後にスクリプトを実行することができます。

これを応用するとコミットする時にlintなどの静的解析ツールを使ってチェックを行なったり、prettierなどのコード整形ツールを使ってリポジトリのコードをテストしたりすることができます。

詳しくはこちらのドキュメントをみていただけるとよくわかると思います。

Git フック

今回は、この仕組みを利用してコミットする前にスクリプトを実行して記事の更新日時を自動で更新してくれる仕組みを作っていきます。

おおまかな流れの説明

今回は**「コミットされる記事 = 更新される記事」**という前提のもと、Gitフックの中でもpre-commitというhookを使って実装していきます。

pre-commitだと名前の通りファイルがコミットされる時点でスクリプトを実行できるのでコミットが走る前のタイミングでコミットされる記事の一覧を取得し、その一覧の更新日時をアップデートする感じで実装していきます。

おおまかな処理の流れをまとめると

記事をコミット
gitのpre-commitフックを使って更新される記事の一覧を取得
スクリプトを使って更新日時を更新
1.と3.の変更をコミットして終了

という形になります。以降実際の実装を説明していきます。

実装

pre-commitフックを仕掛ける

おおまかな流れを決めたところでまずpre-commitのフックの設定をしていきます。

Gitのフックはgitリポジトリの.git/hooksディレクトリにフックの名前のスクリプトをおくことでフックを仕掛けることができます。今回の場合は

.git/hooks/pre-commit

というファイルをおいておくとpre-commitファイルがコミット前に実行される形になります。ちなみに.gitディレクトリ配下だとリポジトリでソース管理できないので私の場合は.git/hooksをルートディレクトリのhooksディレクトリのシンボリックリンクにしています。

rm -rf .git/hooks      # 既存のhooksディレクトリを削除
mkdir hooks            # リポジトリ管理用のディレクトリを作成
ln ../hooks .git/hooks # ルートのhooksディレクトリへのシンボリックリンク作成

touch hooks/pre-commit     # pre-commitファイルを作成
chmod 755 hooks/pre-commit # 実行権限を付与

これでpre-commitのフックを仕掛けると同時にフックのスクリプトをリポジトリ管理できます。

pre-commitでの処理を実装

pre-commitのスクリプトでやることですが、先ほど説明した通り

コミットされる記事の一覧を取得
更新日時のの二点です。

今回は1. はgitのコマンド、2.はjsのスクリプトで実装しました。2.は慣れている人だとシェル芸とかでできてしまうのかもしれないですが、ちょっと時間かかりそうだったので既存のスクリプトをちょっと変えてタイムスタンプを更新するスクリプトを書きました。

pre-commitのファイルの中身は以下のようになります。

#!/bin/bash

PATTERN=index.md

# コミットされる記事の取得
DIFF=$(git diff --name-only --cached | grep $PATTERN )

# タイムスタンプ更新用のコマンド
UPDATE_TIMESTAMP="node ./scripts/updatedAt/index.js $DIFF"

$UPDATE_TIMESTAMP
if [[ $? -eq 0 ]]
then
  # タイムスタンプを更新した文のファイルを追加
  git add $DIFF
fi

gitコマンドとgrepコマンドを組み合わせてコミットされる記事は取得できるので1.の部分は

git diff --name-only --cached | grep [記事ファイルをフィルタする条件]

のような形で取得しています。

あとはそこで取得した一覧を引数に与えるとタイムスタンプを更新してくれるスクリプトを実行して、そこでの変更分をaddしています。

タイムスタンプを更新するスクリプトを実装

pre-commitの仕込みも終わりタイムスタンプ更新対象のファイルも取得できるようになったのであとは肝心のタイムスタンプ更新スクリプトの実装を残すだけです。

ここでは一応参考までにjsのコードを置いておきますが、シェル芸でやろうがrubyスクリプトを使おうが一向に構いません。タイムスタンプさえ更新できていればOKです。

const path = require('path');
const fs = require('fs');
const moment = require('moment');

const alertForRequired = (key, value) => {
  if (!value || value.length === 0) {
    console.error(`[ERROR] ${key} is required`);
    process.exit(1);
  }
};

const update = (lines) => {
  const timestamp = moment().format('YYYY-MM-DD HH:mm:ss')
  const matcher = /^updatedAt:.*$/
  const data = lines.map(line => {
    if (line.match(matcher)) {
      return `updatedAt: ${timestamp}`
    }
    return line
  })
  return data.join("\n")
}

const { argv } = process
const paths = argv.slice(2, argv.length)
alertForRequired('path', paths)

const list = paths.map(path => {
  console.log('update timestamp:', path)
  const tmp = path + '.tmp'
  const content = fs.readFileSync(path, "utf8");
  const lines = content.split("\n")
  const data = update(lines)
  fs.writeFileSync(tmp, data);
  fs.copyFileSync(tmp, path)
  fs.unlinkSync(tmp)
});

コード自体は単純で引数でわたされたファイルを順番に処理していってマッチャーに引っかかるものがあれば現在日時で更新するというだけです。繰り返しにはなりますが、ここは本当にタイムスタンプが更新できれば良いので各自早い安い方法を採用頂ければという感じです。

実行してみる

一応念の為実行ログを貼っておくと以下のようになります。

$ git commit -m "some fix"
update timestamp: src/pages/posts/2017/12/20171225_report/index.md
[master 89922c8] some fix
 2 files changed, 4 insertions(+), 2 deletions(-)

タイムスタンプ更新スクリプト内でタイムスタンプの更新されたファイルを標準出力するようにしているので、無事タイムスタンプが更新されていることがわかります。これでタイムスタンプ自動更新の作成は終わりです。

まとめ

実運用はまだなのでどれくらい使えるとかデメリットに気づけていない部分あるかもしれませんが現段で良いと思うものを一旦まとめました。

ちなみに、あえてタイムスタンプを更新したくない場合は

git commit --no-verify

とするとフックを回避することができるので、タイムスタンプを更新せずに記事をコミットすることができます。

以上です！では。

Go言語の文法を勉強して印象にのこったところまとめ。その3。

Mon, 18 Feb 2019 00:00:00 GMT

前回、前々回とgoの文法をまとめています。今回はその3です。

今回は

配列
エラーハンドリング

です。

勉強に使用した本

参考にした本は例によってこちらの本です。感想などは以前の記事に書いたので割愛します。

改訂2版基礎からわかる Go言語

早速文法のまとめを見ていきましょう。

文法のまとめ

配列、スライス、マップ

配列

配列は他の言語の配列とあまり変わらずGo言語の配列は動的ではなく、初期化時に配列の長さが決まるようで、動的配列として使いたい場合はスライスを使うのでGO言語で配列を使う機会は少ないようです。

とはいえ文法は知っておいたほうがよいので下記に初期化の方法などは載せておきます。

// 配列型の宣言
var array [1] byte
var array2 [5]*int
var array3 [8][3]int64
var array4 [2]struct{ x, y int ]

// 配列の初期化

array1 := [5]float32{} // 長さ5の配列。各要素はゼロ値で初期化される。

array2 := [6]int{1, 2, 3, 4} // 長さ６の配列。要素の不足分はゼロ値で初期化される。

array3 := [...]string{"One", "Two", "Three"} // ...を記述すると要素数が長さとしてしようされる。

スライス

スライスは動的配列として使われるので、rubyやjavascriptの配列をイメージしている人は配列ではなくスライスを使うと覚えておくとよいみたいです。とはいえスライスは参照型と呼ばれ実体は配列を参照しているようです。配列そのままを関数にわたしたりすると配列の値すべてが複製されてしまい効率が悪いですが、スライスのような参照型を受け渡しすると参照情報のみがコピーされるのでデータが少なくすむという利点があります。

スライス式

配列からスライスを作成する、もしくはスライスから新たにスライスを作成するには「スライス式」を使用します。スライス式は「[]」内に作成するスライスに含める要素の範囲を「:」で区切って記述します。

作成元の配列orスライス[下減値:上限値]
作成元の配列orスライス[下減値:上限値:キャパシティ]

キャパシティとはスライスから新たにスライスを作る場合に指定できる上限値の最大値で、スライスからスライスを作成する時は、スライスの長さを超え、キャパシティの値までスライスできます。

また、文字列をスライスすることも可能で文字列をスライスすることで文字列を切り出すことができます。

var x sring = "abcde"[1:4]
// => "bcd"という文字列がxに格納される

スライスの初期化

配列をそのまま使うよりもスライスを使った方がスライスが可変長な分扱いやすいのですが、わざわざスライスとして使用するために配列を作るのは手間なのでGo言語ではmake組み込み関数が用意されています。

make(スライス型, 長さ, キャパシティ)
make(スライス型, 長さ)

// 長さ10, キャパシティ20のスライスを作成
s1 := make([]int, 10, 20)

次にスライスの作成と初期化を同時に行う場合は、スライスリテラルを利用します。

s := []int{1, 2, 3, 4}

マップ

マップは他の言語でもあるようにキーと値の集合です。「辞書」や「連想配列」とも言われます。マップ型はスライスと同じく参照型の一種で参照型の値を作成する場合はmake組み込み関数を使用します。

make(map[キーの型] 要素型, キャパシティの初期値)
make(map[キーの型] 要素型)

キャパシティはマップに格納可能な要素数ですがここで指定する値はあくまでも初期値でキャパシティは必要に応じて自動で拡張されます。キャパシティの初期値は省略可能です。

マップの参照は配列と同様に添字を渡して参照するのですが

capitals := make(map[string] string)
capitals["日本"] = "東京"
capitals["アメリカ"] = "ワシントンDC"
capitals["中国"] = "北京"

また、マップは二つ目の戻り値でキーが存在するかを確認することができます。

capital, ok := capitals["イギリス"]
if ok {
  fmt.Println("登録済み", capital)
} else {
  fmt.Println("未登録", capital)
}

マップのキーとして使用できる値

マップのキーとして使用できる型は「関数型」「マップ型」「スライス型」以外で、比較演算子「==」「!=」が実装されている必要があります。

マップの初期化

マップを作成と同時に初期化する場合は、マップリテラルを使用します。

capitals := map[string] string{
  "日本": "東京",
  "アメリカ": "ワシントンD.C",
  "中国": "北京"
}

エラーハンドリング

戻り値によるエラーハンドリング

GOでは戻り値に複数の値を返すことができますが、これをエラーハンドリングにも利用することができます。

Go言語の標準関すは処理結果とともに「errorインターフェース型」の値をエラー情報として返します。errorインターフェースは特定のパッケージ内で宣言されているものではなく、Go言語に組み込まれている型で、Errorメソッドを呼び出すことでエラーの詳細情報を取得することができます。

file, err := os.Open("text.txt")
if err != nil {
  // エラーの詳細情報を出力
  fmt.Println(err.Error())
  os.Exit(1)
}

パニックとリカバリ

関数内でエラーが　発生し、その処理が致命的なエラーでただちに処理を中断させたい、もしくはリカバリが必要な時だけハンドリングしたいという場合には、 panic組み込み関数を呼び出して「パニック」という状態を発生させます。ある関数内で「pnaic」を呼び出すと、その関数の実行は中断さ、順次呼び出し元をさかのぼり、最後にプログラム自体が終了します。 (この時defer文によって遅延していされた関数は実行されるそうです。)

さらに、recover組み込み関数を呼ぶとパニック状態を中断させることができるのですが、recoverは遅延実行された関数内でしか使えないようです。

そのため、以下のようなコードでパニック状態を中断させることができます。

func f1(p bool) {
  defer func() {
    fmt.Println("defer start")
    err := recover() // リカバリ
    if err != nil {
      fmt.Println("catch panic:", err)
    }
    fmt.Println("defer end")
  }

  panic("panic!!!!!!!!!!")
}

// 実行結果
defer start
catch panic: panic!!!!!!!!!!
defer end

まとめ

ここまで配列・スライス・マップ、エラーハンドリングについてまとめてみました。 Goルーチンのまとめが残っているのですが、それなりのボリュームになりそうなので、記事を分けます。このシリーズは次回で完結しそうです。では。

Summary of fixing errors when migrationg webpack2 to webpack4

Sun, 17 Feb 2019 00:00:00 GMT

I happened to have a chance to upgrade from webpack2 to webpack4 in a project using vue, so I had to use Here's a summary of the errors I've encountered when upgrading webpack and their solutions.

Impression after migrating webpack

The first impressions are that the version of package.json was rewritten before the work started, and then the I thought that I could make it if I did npm install and solved some errors, but it was not so easy.

Because the version of babel-loader was not usable with webpack4 in 6 series, I upgraded it to 8(latest version) skipping version 7. Then, I also had to change the version of babel to 7. Finally that's not a light task.

The other package versions such as file-loader and vue-loader didn't match with the 4 series, so I also needed to update them.

The first thing we did in the migration.

When upgrading, basically, you need to update the version of webpack to 4 first and then I was planning to just keep resolving the errors until the build was successful. It's not very efficient, so I went to the official document first.

Here is something like an explanation of how to migrate from webpack3 -> webpack4. You can find it here: https://webpack.js.org/migrate/4/

The basic policy is to kill errors as they are encountered, but I've already destroyed what I can find in the documentation.

add mode option

In webpack4, you can set the mode options, and if you build in production mode, you can uglify. For more information on how to set it up and how it behaves differently, the following link will help you.

https://webpack.js.org/concepts/mode/

The mode options can be specified with the -m option at the time of webpack's execution, or config it like following code.

module.exports = (env, argv) => {

  if (argv.mode === 'development') {
    config.devtool = 'source-map';
  }

  if (argv.mode === 'production') {
    //... }
  }

  return config;
};

webpack-cli setup

Since webpack4 has cli as webpack-cli, so I've also installed it.

I also installed it.

npm install -D webpack-cli

Remove Unnecessary Plug-ins

The following four plugins are the default for production mode in v4.

* NoEmitOnErrorsPlugin
* ModuleConcatenationPlugin
* DefinePlugin
* UglifyJsPlugn

This is the development mode default

* NamedModulesPlugin

The next two are deprecated and removed

* NoErrorsPlugin
* NewWatchingPlugin

So, if this plugin is included in your project's webpack.config.js, you should remove it.

Errors that appeared after the upgrade and their countermeasures.

As I wrote earlier, read the migration instructions and remove what I could destroy first so next I needed to fight against the unknown errors.

Cannot read property 'fileLoader' of undefined

It seems that the version of file-loader was simply too old. It was throwing up an error per leaflet.

https://github.com/tcoopman/image-webpack-loader/issues/153

npm install file-loader@[latest version]

TypeError: Cannot read property 'stylus' of undefined

https://github.com/shama/stylus-loader/issues/189 https://github.com/shama/stylus-loader/pull/190/files

A minor version of the stylus-loader had become an error with only 1 small version. It's solved by updating to 3.0.2.

Parse error in dynamic import.

When I built it, there was a parse error in the dynamic import. The project uses this preset-stage-2. It was already migrated it while following document, but it didn't work.

https://github.com/babel/babel/blob/master/packages/babel-preset-stage-2/README.md

Here's the solution, and it's in the

https://github.com/webpack/webpack/issues/8656

There are some posts that say it worked when I downgraded to wepback 4.28. It seems like last resolution, and if you read on as if there's a better way, webpack relies on acorn@^6.05 It seems to need to be installed.

Furthermore, the webpack relies on acorn, acorn-dynamic-import and I needed to dedupe like this

npm dedupe

It seemed to be an error because each one did not reference the same version.

https://github.com/webpack/webpack/issues/8656#issuecomment-456010969 ...

For now.

npm install -D acorn@^6.0.6
npm dedupe

Then it worked.

Cannot read property 'vue' of undefined

https://github.com/vuejs/vue-loader/issues/1177

Upgraded this because more than vue-loader@14.2.2 is required to webapck 4.

Cannot read property 'context' of undefined

Now they want me to update the css-loader

https://stackoverflow.com/questions/50418896/webpack-4-css-modules-typeerror-cannot-read-property-context-of-undefined

The answer says that ^0.28.11 is fine, but if you can build it with no problems, then the newer version is better, so I upgraded to 1.xx.

WARNING erupts on build.

No parser and no filepath given, using 'babel' the parser now but this will throw an error in the future. inferred.

I started to see this kind of WARNING spewing out during the build, so I looked it up and this is what I found

https://github.com/rails/webpacker/issues/1734 ...

I was told to give it to vue-loader v15. Though I couldn't get rid of the feeling that "I just updated it to 14 just now". However, there was no way so I upgraded to a new version.

Click here to see how to upgrade.

https://vue-loader.vuejs.org/migrating.html#notable-breaking-changes

In my project, this is how I add plug-ins and

// webpack.config.js
const VueLoaderPlugin = require('vue-loader/lib/plugin')

module.exports = {
  // ...
  plugins: [
    new VueLoaderPlugin()
  ]
}

I did the pug and css settings as described in the documentation and I was able to build it with no problems.

Summary

I have introduced the errors and its solutions in the upgrade to webpack4. I wrote a quick note about giving it to v15, but I was usually stuck in it for a couple of hours.

The whole time I assumed that "I can't parse the pug!" However, it took me a while to realize that I hadn't been able to load the stylus, which was a horrible mistake. I wasted a lot of time.

When the version up is skipped, it becomes hard to skip it after. If other libraries are not supported, or it will need version-up like domino. It's not easy. If you focus on only development, version up and maintenance of the environment will be neglected. If you can create a team or system to be able to upgrade immediately when one person notices, it would be better to manage the project in a peaceful way.

Well then. Thank you for reading.

webpack2からwebpack4バージョンアップで出たエラーとその解決法まとめ

Sun, 17 Feb 2019 00:00:00 GMT

今回たまたまvueを使ったプロジェクトでwebpack2からwebpack4からバージョンをあげる機会があったので webpackをバージョンアップする際に出たエラーとその解決策をまとめてみます。

webpackをあげてみて

最初に感想を書いておくと作業着手前は、package.jsonのバージョンを書き換えてぺろっと npm installしていくつかエラー解消したらいけるかなと思っていたんですがそんなに甘くなかったですね。

babel-loaderのバージョンが6系ではwebpack4で使えなかったのでbabel-loaderを勢い余って v8系にしたらbabelのバージョンも7にしなきゃいけないなってなってwebpack&babelのバージョンアップをおこなったのでまあまあな仕事になりました。

他にもfile-loaderやvue-loaderなどのバージョンも4系と合わなかったのでそれらもガバッとバージョンアップして見事な芋づる式バージョンアップとなりました。

移行にあたってまずやったこと

バージョンアップにあたっては基本的に先にwebpackのバージョンを4にあげてあとはビルドが成功するまでひたすらエラーを解消していくスタイルで計画していたのですが、まぁそれだと効率の悪さは否めないので先におとなしく公式のドキュメントを参照しました。

ここにwebpack3 -> webpack4の移行手順の説明みたいなものがあります。 https://webpack.js.org/migrate/4/

基本方針としては遭遇したエラーを順番に倒していく方式なのですがここのドキュメントでわかることはあらかじめ潰しておきました。

modeオプションの付加

webpack4ではモードオプションを設定できて、productionモードでビルドするとデフォルトで uglifyなどをやってくれるそうです。詳しい設定の仕方や挙動の違いはこちらを参照するのが良いと思います。

https://webpack.js.org/concepts/mode/

モードオプションはwebpack実行時に-mオプションでモードをを指定できたり、こういう感じで書くことでwebpackのmodeごとに振る舞いをかき分けたりすることができるそうです。

module.exports = (env, argv) => {

  if (argv.mode === 'development') {
    config.devtool = 'source-map';
  }

  if (argv.mode === 'production') {
    //...
  }

  return config;
};

webpack-cliのセットアップ

webpack4からcliがwebpack-cliとして別パッケージにくくり出されたそうなので webpack-cliもインストールしておきました。

npm install -D webpack-cli

不要なプラグインの削除

以下の4つのプラグインはproductionモードのデフォルト

* NoEmitOnErrorsPlugin
* ModuleConcatenationPlugin
* DefinePlugin
* UglifyJsPlugn

これはdevelopmentモードのデフォルト

* NamedModulesPlugin

次の二つはdeprecated and removed

* NoErrorsPlugin
* NewWatchingPlugin

なので、こららのプラグインがプロジェクトのwebpack.config.jsに含まれる場合は削除します。

バージョンアップ後に出たエラーとその対策

先に書いたように移行手順を読んで先に潰せるものは潰しておいて、あとは未知のエラーと戦っていく作業でした。

Cannot read property 'fileLoader' of undefined

単純にfile-loaderのバージョンが古かったようです。 leafletあたりからエラー吐かれていました。

https://github.com/tcoopman/image-webpack-loader/issues/153

npm install file-loader@[最新バージョン]

TypeError: Cannot read property ‘stylus’ of undefined

https://github.com/shama/stylus-loader/issues/189 https://github.com/shama/stylus-loader/pull/190/files

stylus-loaderのマイナーバージョンが1小さいだけでエラーになっていました。。これもバージョンアップで回避です。3.0.2にあげたら解消しました。

dynamic importでパースエラー

ビルドしたところdynamic importしているところでパースエラーとなっていました。プロジェクトではこのpreset-stage-2を使っていて移行のために下記ドキュメントの通り設定を行なっていたので大丈夫なはずなのですが、それでもだめでした。

https://github.com/babel/babel/blob/master/packages/babel-preset-stage-2/README.md

解決策はここにあって、

https://github.com/webpack/webpack/issues/8656

wepback4.28にダウングレードしたら動いたという書き込みもあるのですがそれは最終手段で他に良い方法があればという感じで読み進めるとwebpackがacorn@^6.05に依存しているようなのでインストールが必要なようでした。

さらに, webpackがacorn, acorn-dynamic-importに依存しており

npm dedupe

をしないとそれぞれ同じバージョンのものを参照しないのでエラーとなっているようでした。

https://github.com/webpack/webpack/issues/8656#issuecomment-456010969

とりあえず、

npm install -D acorn@^6.0.6
npm dedupe

したら動くようになりました。

Cannot read property 'vue' of undefined

https://github.com/vuejs/vue-loader/issues/1177

webpack4系はvue-loader@14.2.2 以上じゃないとだめだそうなのでこちらもバージョンアップ

Cannot read property 'context' of undefined

今度はcss-loaderをアップデートせよとのこと

https://stackoverflow.com/questions/50418896/webpack-4-css-modules-typeerror-cannot-read-property-context-of-undefined

回答では ^0.28.11で良いと書いていますが問題なくビルドできればバージョン新しい方がよいので 1系を入れました。

ビルド時にwarningが噴出

No parser and no filepath given, using 'babel' the parser now but this will throw an error in the future. Please specify a parser or a filepath so one can be inferred.

ビルド時にこんなwarningが噴出されはじめたので調べるとこんなのが出てきたので

https://github.com/rails/webpacker/issues/1734

vue-loader v15にあげよとのこと。「えっさっき14にあげたばかり」との気持ちはぬぐいきれませんでしたがしかたなくバージョンアップ。

バージョンアップの手順はこちら

https://vue-loader.vuejs.org/migrating.html#notable-breaking-changes

僕のプロジェクトでは、こうやってプラグインを足すのと

// webpack.config.js
const VueLoaderPlugin = require('vue-loader/lib/plugin')

module.exports = {
  // ...
  plugins: [
    new VueLoaderPlugin()
  ]
}

pugとcssの設定をドキュメントの通りにやったら問題なくビルドできるようになりました。

まとめ

以上webpack4へのバージョンアップで出たエラーとその解決策を紹介しました。vue-loaderを v15にあげるるのはさらっと書きましたが普通に二、三時間くらいはまりました。ずっと「pugがパースできない！！！」と思い込んでいたのですがよくよくみるとstylusが読み込めていなかったというしょうもないミスに気づくのに時間がかかりだいぶ無駄な時間を消費しました。

バージョンアップさぼっているとさぼっているだけやっぱり大変になりますね。他のライブラリが対応していないとか芋づる式バージョンアップになるとなかなかしんどいです。開発に一生懸命になるとバージョンアップとか環境整備とかがおざなりになって負債になるので、複数人が気付いた時にこまめにバージョンアップするっていうようにした方が平和なプロジェクト運営できそうなきがしますね。

では。

Go言語の文法を勉強して印象にのこったところまとめ。その2。

Thu, 14 Feb 2019 00:00:00 GMT

前回の記事でGo言語の変数宣言やメソッド宣言などの部分を紹介しましたが、今回はその後半で...としようと思ったのですが、以外と量が多かったので今回は下記二つに絞ってまとめていきます。

構造体
インターフェース

前回の記事はこちらです。

勉強に使用した本

文法の勉強に使用した本は前回と一緒のこちらです。

改訂2版基礎からわかる Go言語

前回も書きましたが、これ一冊でバランスよくGoの文法がまとめられているので一回通しでよんだ後に、簡単なコマンドベースのコードを書きつつ不明なところを再度読み直せば結構かけるようになる気がします。

文法のまとめ

ということで早速、構造体、インターフェースなど前回さわれなかったところをまとめていきます。

構造体

構造体はCやVBAを触った時にちょっと触ったので親しみがありますが、はるか昔すぎてなんのことやらわかりません。 rubyのハッシュのようなものかなと思っているのですが、構造体とはフィールドの集合でそれぞれに型があるものなのだそうです。

まぁ型のあるハッシュとざっくり理解しています。どうやら構造体にもスコープの概念が適用されフィールドの先頭1文字目を大文字にするとフィールドが外部に公開され外部パッケージからでもアクセスできるようになっているようです。

構造体の書式は

struct {
	// フィールド宣言
}

で、構造体に名前をつける場合は、

type MyData struct {
	a string
	b bye
}

のようにtypeキーワードを用いて名前をつけていきます。

特殊なフィールド

また、構造体にはいくつか特殊なフィールドを宣言することができて、そのひとつにブランクフィールドがあります。メモリ領域には確保が必要だけどフィールドにアクセスすることはないということを明示的に示すために使用するそうです。通常構造体のフィールドは一意の名前をつける必要がありますが、ブランクフィールドの場合は一つの構造体に複数定義することが可能です。


struct {
  b1 byte
  _ byte // ブランクフィールド
  b2 [5]byte
  _ byte // ブランクフィールド
}

ブランクフィールドはちょっと使いどころがわからないです。本の後ろの方に逆引き的なサンプルがのっているのでもしかしたらそこで確認できるかもしれません。

構造体には、他にも匿名フィールドと呼ばれるフィールドも宣言可能でフィールド名を指定せずに型名だけでフィールドを宣言できます。

struct {
  int  // フィールド名はint
  uinit64  // フィールド名はuint64
  *byte  // フィールド名はbyte
}

構造体の初期化

構造体の初期化の方法は3通りあり

構造体宣言後に書くフィールドに個別に値を代入して初期化
構造体リテラルを使うのと同時にフィールド名と値をペアで与えて初期化
構造体リテラルを使うのと同時フィールドの宣言順に値を記述して初期化

1.は説明する必要ないと思いますが、1の方法以外に2,3の初期化方法があり、

2.のフィールド名と値をペアで与えて初期化するには次のようにします。

type Person struct {
	name string
	age int
}

func main() {
  // フィールド名と値のペア
  p2 := Person{age: 31, name: "Tom"}
  // 宣言順に値を渡す
  p3 := Person{"Jane", 42}
}

type Person struct {
  name string
  age int
}

func main() {
  // フィールド名と値のペア
  p2 := Person{age: 31, name: "Tom"}
  // 宣言順に値を渡す
  p3 := Person{"Jane", 42}
}

ここの文を読み進めていて構造体初期化が複数行にわたった時の記法ちょっと気持ち悪いなと思いました。構造体の初期化で複数行にわたる場合は最後の } をフィールドと同じ行にかかないといけないようです。

// こうやって書かないとコンパイルエラーになる。。気持ち悪い
Person{
	age: 31,
	name: "Tom"}

ただ、さらに本を読み進めると最後にカンマをつければコンパイルエラーにならないそうでスッキリしました。

// これならスッキリ
Person{
	age: 31,
	name: "Tom",
}

インターフェース

インターフェースはわかるかたも多いかもしれませんが、「振る舞い」を規定する関数みたいなものです。中身のロジックを持たずに外面だけを定義します。インターフェースではロジックを書かないので関数の名前とパラメータ（引数）・戻り値だけを定義します。


interface {
  関数名（パラメータリスト） 戻り値の型
  関数名（パラメータリスト） 戻り値の型
}

// type宣言を使って名前をつけて定義する場合
type インターフェース型名 interface {
  関数名（パラメータリスト） 戻り値の型
  関数名（パラメータリスト） 戻り値の型
}

予備知識として関数を一つしかもたないインターフェースの場合インターフェース名は「関数名 + er」とするのが習わしらしいです。例をそえておきます。

type Reader interface {
  Read(p []byte) (n int, err error)
}

自動的に実装されるインターフェース

Goのインターフェースは自動的に実装されるそうで、「インターフェース」と「それを実装した型」との関係性を明示的に書く必要がないそうです。

Javaとかだと

public class Sample implements [インターフェース]  {

}

というように型に対してどのインターフェースを実装するかを明示的に書く必要があるのですが、 Goではこれが必要なく既存の方に後付けでインターフェースを実装することができるようです。

空インターフェース

interface {}

空インターフェースとは、「インターフェースに実装すべき関数がない」 => 「すべての型が空インターフェースを実装している」ということになるので空インターフェースにはどんな値も代入可能です。なんでもできます。

型変換について

Go言語では型アサーションという機能がありレシーバーの後ろに「.」と丸括弧で変換先を記述することで型変換を行ったり、型変換可能かどうかを確認することができます。

// 空インターフェースの変数の値をstring型に変換

var i interface{} = "test"
var s string = i.(string)

型アサーションが可能かどうかを調べたいだけの時は、型アサーションから返ってくる二番目の論理値を使います。型アサーションから二番目の値を取得する場合は、型変換できなくても失敗しないので型変換可能かどうかをチェックできます。


var s string = "test"
s2, ok := s.(interface {
  dummy()
})

fmt.Println(s2, ok)

型switch文

switch 値.(type) {
  case 型1:
    // type が型1の時ここが実行される。
  case 型2:
    // type が型2の時ここが実行される。
  default:
    // type が上以外の型の場合
}

型switch文です！ついに来ました！個人的にこれだいぶ便利そうな感じするのですが実際どうなのでしょうか？

型switch文は単純に型ごとに処理を分けられるのですが、その結果を変数に代入することもできるので変数の型を気にしない実装ができそうな気がしています。多用して簡単に分岐作っちゃうのもよくないとは思うのですがどうしてもという時に役たちそうです。

コードも書いていない状態でフライング気味ですが、ぜひ使ってみたい機能の一つです。

まとめ

当初記事二本でまとめ切ろうと思いましたが、無理でした。もう一、二本で完結させたいです。

文法をまとめている間にどんどん時はすぎていくので早くコード書けという話なのですが、まだ書けていないのでとりあえず記事にしておきます。文法をなんとなくさらったらコマンドベースで動くものでも作ってみると良さそうですね。最終的にはGoのWebフレームワーク使ってAPI開発などできればというところですね。

ペースはゆったりですがじわじわ進めていければ。

リモートワークするエンジニアがデスク周りを充実させるために購入したものまとめ

Mon, 04 Feb 2019 00:00:00 GMT

私はフリーランスのエンジニアとして、昨年から家で仕事することが増えクライアントさんの元で仕事をするとき以外はほとんど自宅の机でPC作業したり、コード書いたりしています。

（というか別に休日もPCの前にいることが多いです。）

そういうわけでデスクで過ごす時間が生活のほとんどなのでそこで使うPCデスク、椅子、ディスプレイ等々充実させたい気持ちが強く昨年からぼちぼち一年くらいかけてデスク周りを充実させていってます。デスク周り改善プロジェクトで割とものがそろってきたのでここらへんで一旦購入したものレビュー感想というのをまとめておこうかなと思います。

L字型デスク

選べる4カラーワークデスク L字型 3段サイドチェスト約W120×D145×H73.5

見ての通りL字型デスクです。昔からL字デスクというか広い作業スペースへの憧れがあったので一旦手が出せる範囲のやつを買ってみました。

作業スペースがでかくなったので割と快適なんですが、ちょっと無駄に場所とる感はありますね。一時避難の書類や書籍はデスクのサイズを満たすまで膨張するので別にこんなにでかいのいらねぇんじゃないかなとは買って思いました笑。机自体は割と大きめで場所取ってるのですが、机下のスペースが使えて机下にちっちゃい本棚とか置けるのでそこはまぁいいかなという感じです。

机上デスク | NEARPOW 【改良版】折りたたみ式ノートパソコンスタンド

NEARPOW 【改良版】折りたたみ式ノートパソコンスタンドベッドテーブル 4つ組み立て方両・右・左利き対応ローテーブル机上台

最近長時間座っているからか、肩が凝ったり腰が痛かったりでこの先ずっとエンジニアをやるにあたってすぐに限界が見えそうだったのでスタンディング作業を導入することにしました。スタンディングをするには電動昇降式のデスクが便利そうですが、L字デスクへの憧れがあったので

L字デスク+机上デスク

という構成でスタンディングデスクを構築するようにしました。正直このデザインはあまり気に入ってないのですが、机上デスクとしては十分でソファと併用したりすると寝ながら作業できたりするので汎用性が高く機能面では結構満足しました。折りたたみ式なので使わないときはコンパクトにして机の下とかにしまって置けます。

ディスプレイ | Acer 4K モニターディスプレイ ET322QKAbmiipx 31.5インチ/HDR

Acer 4K モニターディスプレイ ET322QKAbmiipx 31.5インチ/HDR Ready対応/VA/4K/16:9/4ms/DisplayPort ・HDMI

31.5インチなのでそれなりに大きめです。デスクの奥行きがないとちょっと近すぎちゃうかなぁというのもあったのですが、普段作業する時にはサイズに関わらず、ディスプレイ１つで作業するのが定着しているのである程度しっかりしたサイズのディスプレイを選びました。

あまり使う機会なさそうなんですが、HDMIの端子が二つあり画面を２つに分割してそれぞれの映像を表示する機能があるっぽいです。テレビチューナーにつなげれば4K放送も見れるので、テレビみながら出演者の情報を調べたりできるみたいです。

モニターアーム | エルゴトロン LX デスクマウントモニターアーム長身ポール 45-295-026

エルゴトロン LX デスクマウントモニターアーム長身ポール 45-295-026

モニターアームはエレゴトロンです。amazonで購入して取り付けてみましたがやはり作りがしっかりしてて32インチのディスプレイでもなんなく空間に固定できます。電動の昇降式スタンディングデスクは諦めたので、モニターアームと机上デスクを駆使してスタンディング作業を実現しています。恥ずかしながら取り付けの際、ネジを締めるとアームの固定力が上がるのを知らずディスプレイを取り付けてスタンディングの位置までモニターを上がると自然と落ちてきてしまう現象にテンションだだ下がりしてましたがしっかりとネジを締めれば、32インチのディスプレイでも難なく固定されます。

トラックパッド | Apple Magic Trackpad 2 MJ2R2J/A

Apple Magic Trackpad 2 MJ2R2J/A

純正のやつです。家にいる時はMacbookを閉じて作業したい+トラックパッドないと生きていけない体になっているので購入しました。Macbookのトラックパッドよりクリック時のストロークが深いきがしていて（気のせい？）押し込むと結構気持ちいいです。

キーボード | PFU Happy Hacking Keyboard Professional BT 英語配列/白 PD-KB600W

PFU Happy Hacking Keyboard Professional BT 英語配列/白 PD-KB600W

キーボードはHHKBのbluetooth対応モデルです。ワイヤレスが良くてこれを選んだんですが、現状電池を買ったり捨てるのが面倒でUSBで繋ぎながら使ってます。Bluetoothの必要ないですね。

周りだと黒の無刻印・英字配列が人気な気がするのですが色は白の、刻印有りを選びました。デスク周りが割と黒が多いので中和のためっていうのと白は白でかわいさがあるので、白にしてみました。

Macbookスタンド | Twelve South BookArc アルミニウム for MacBook v2

【日本正規代理店品】Twelve South BookArc アルミニウム for MacBook v2 クラムシェルモード用 MacBookスタンド TWS-ST-000037

Apple Storeで売っているやつです。先にもかいたように家では基本MacBookを閉じて使うので購入しました。単純に縦置きすると省スペースになって机が広く使えます。

Amazon Echo | Echo Dot 第3世代 (Newモデル) - スマートスピーカー with Alexa、チャコール

Echo Dot 第3世代 (Newモデル) - スマートスピーカー with Alexa、チャコール

こちらは引っ越し祝いに頂いたスマートスピーカーです。スマートスピーカー対応の照明とかと合わせれば「アレクサ、電気消して」で電気を消せるそうです。照明もechoも家にあるのでこれは試せるのですが、設定するタイミングを逃し続けて今に至るので、echoは料理やインスタントを作る時の高性能タイマーとして活躍してます。声でタイマーセットできるのが地味に便利なので他のものも声で操作できると便利なんだろうなぁと類推してます。

ポモドーロタイマー

かわいいキッチンタイマー　トマトタイマー　1~60分 360度

Amazonが出している高性能タイマーに機能面で劣るものの、レトロなビジュアルと真っ黒なデスクのアクセントとして役立っています。

冬用スリッパ

もこもこ冬用スリッパルームシューズ室内メンズレディースふわふわ洗える 4カラー

別にデスク関係ないんですけど、冬場は足元ひえるし靴下履くと洗濯もの増えるんでこれ履きながら作業してます。スリッパを裸足で履いてるとそれなりに蒸れるので、二足買って交互に使い回すと良さげです。洗濯もネットに入れて洗濯機に投げるだけで良くて結構楽です。履き心地は馴染む前はちょっと硬いかなぁという感じなんですがら、馴染んでくると割とリラックスして履けてもふもふしてあったかいです。

パームレスト・リストレスト

サンワサプライキーボード用低反発リストレスト(ブラック) 手首疲労軽減ウレタン素材 TOK-MU3NBK

サンワサプライ低反発リストレストミニ(ブラック) TOK-MU2NBK

昔手首を痛めたことがあり、長時間キーボード叩いていると手首が痛くなってくるので購入しました。ちっちゃいほうをトラックパッド用、長い方をキーボード用にして使ってます。手首がまっすぐない状態でキーボードが叩けると一番痛くならないので、こいつらを間に挟むことで手首の角度を調節できます。

まとめ

と、こんな感じで一年くらいかけてぼちぼちものを集めてきました。モニターアームと机上デスクでのスタンディングパターンは汎用性高く結構気に入っています。

当初L字デスクを壁にくっつけてつかっていたのですがモニターアーム導入同時に壁にくっつけられなくなったので思い切ってデスクが部屋の真ん中に向くようにしてみたところモニターアームの柔軟性を最大限にいかせるレイアウトになりました。スピーカーの裏側とかコードとかが丸見えになるというデメリットはあるのですが、モニターアームをがっつり動かしてソファ側にディスプレイを向けるとソファに座りながらNetflixとかAmazon Prime Videoを観れるようになりました。

この中できになるものがあればぜひチェックしてみてください。では。

Go言語の文法を勉強して印象にのこったところまとめ。

Mon, 21 Jan 2019 00:00:00 GMT

今年はGo言語を新たにはじめてみたいなということで、とりあえず文法をなめるために一冊本を買って勉強しました。

そのまとめとしてGoの文法をまとめていきたいと思います。ただ単に全ての文法事項をリスト的にまとめてもおもしろくないので個人的に感じたGoはこういうところが特徴的なのね。というコメントをを書きつつまとめていければと思います。

勉強に使用した本

とりあえず入門としてGoの文法をさらいたかったので、こちらの本を選択しました。

改訂2版基礎からわかる Go言語

まだ一周読んだだけですが、これ一冊でバランスよくGoの文法がまとめられているので一回通しでよんだ後に、簡単なコマンドベースのコードを書きつつ不明なところを再度読み直せば結構かけるようになる気がします。

Go言語(golang)について

ここらへんはすでに知っている人も多いのかもしれませんが一応まとめておくと、 Go言語は、Googleが2009年に公開したプログラミング言語で、まだ公開されてから 10年弱といったところのようです。この記事を書いている時点で最新版のバージョンは1.11 です。

Goの特徴としては、シンプルな構文でコンパイルが速い、並列処理をサポートしている点にあります。C言語のようなインクルードファイルを採用しなかったのでCに比べてコンパイルが格段に速いそうで、並列処理に関しては、ゴルーチンと呼ばれる実行単位で複数の処理を同時かつ効率的に実行することができます。

他にも、継承がなかったりメソッドが複数の値を返却できたりと様々な特徴があるようです。

まだ本を読んだだけで実際のコードは書いていないのですが、 Javaとかみたいなもっさりしたコードを書く必要はなさそうで、行末のセミコロンを省略できたり if文の丸括弧がいらなかったりで読んでるだけでもシンプルに書けそうだなーという感じでした。

文法のまとめ

ここからは実際にGo言語の文法に触れていきますが、特徴をリスト化して書くのでなく個人的に印象に残ったところを書いています。さーっと読むとGoってこんな感じなのねというのが雰囲気で伝われば良いのかなと思っています。

ちゃんと学びたいのであればリファレンスをみるなり本を買ったりして勉強した方がよいので流し読みで雰囲気を感じとって頂ければ

コンパイルと実行

Go言語の実行は

go run hello.go

と書け、go runとするとコンパイルと実行を一発でやってくれるそうです。 Java, Cとかだとコンパイルと実行はは完全に別でやるので地味に便利です。

コンパイルだけしたい場合は、

go build hello.go

として実行したくなった場合はそのまま、ビルドされたファイルを叩くだけです。

基本的な文法

Hello Worldを出力するプログラムは以下になります。

package main

import "fmt"

func main() {
  fmt.Println("Hello World")
}

Go言語のソースファイルは必ずpackage文から始まり, mainパッケージのmain関数がファイル実行時に最初に呼び出されます。

見てわかるように行末のセミコロンが不要です。Go言語ではセミコロンを書かなくてよくなったことで、


func main()
{
  fmt.Println('Hello World')
}

このような関数定義の開始の{ を行頭にする書き方ができなくなっているようです。（正確には誤って解釈されるかコンパイルエラーになっているそう）

型について

Go言語にはクラスという概念が存在しません。クラスはなく型しかありません。値の型を他の型へ変換することをGoでは「変換」(キャストとは言わない？）というそうで結構型チェックが厳しく、明示的に変換を使用しないと整数同士の型であっても代入、比較できないようです。

変数について

もっとも基本的な変数の宣言方法は

var 変数名 型 = 初期値

ですが、初期値を与えた時は型を省略して記述でき

var i = 123

さらにvarキーワードも:=を使用することで省略できます。

i := 123

:=はなにか特別な演算子のようにもみえ最初にGoのコードを見た時には「？」となりましたが、、変数宣言時の記述量減らせて便利ですね。

定数の宣言にはconstを使います。

const c = 123

さらには、Goには「iota」列挙子なるものが存在するらしくiotaを使うと連番が簡潔に書けちゃいます。

const (
  ZERO = iota
  ONE = iota
  TWO = iota
)

こうすると、

定数ZEROには0の値、定数ONEには1、定数TWOには2が代入されて自動的に連番を作れるそうです。定数に割り振る数字を変えたいなどの場合に間に新しい定数をさしこむだけで変更できるので連番の定数を使うときなどは使えそうですね。

男性、女性の連番の数字の定数にその他を0の値で追加したいという時にサクッと追加できますね。 (普通に書くとMALE, FEMALEの値を繰り上げて書き直さないといけない)

const (
  MALE = iota   // 0
  FEMALE = iota // 1
)

const (
  OTHER = iota  // 0
  MALE = iota   // 1
  FEMALE = iota // 2
)

繰り返し処理について

Go言語にも他の言語と同様にFor文が用意されていますが、 GoのFor文はかっこがいりません。

for i :=0; i < 5; i++ {
  fmt.Println(i)
}

また、Goにはwhile文がなく、多言語ののwhile文にあたる処理は for文で書きます。

for i < 5 {
  fmt.Println(i)
  i++
}


// 無限ループはこちら
for {

}

rubyのeach文、jsのforEach、Javaの拡張for文？のような構文はrange式を使用して書いていきます。

arr := [...]int{0, 1, 2, 3, 4}
for i := range arr {
  fmt.Println(i)
}

条件分岐

何回か書いていますが、Go言語では条件文に丸括弧がいりません。そのためif文はこのような形になっています。

if i % 2 == 0 {
  fmt.Println(i, "は偶数")
} else {
  fmt.Println(i, "は奇数")
}

switch文は

switch i {
  case 0:
    fmt.Println("0")
  case 1, 2:
    fmt.Println("1 or 2")
  default:
    fmt.Println("other")
}

のように書けますが、多言語の場合case式の終わりにbreak文をつけないと他のケースでも条件が一致していれば処理が継続されてしまいますがGo言語の場合はデフォルトでbreakされるようになっており、breakしたくない場合はfallthrough文をつける必要があるようです。

(自分で書いていてbreak書かなかったことがあまりないので記述量が減って嬉しそう)

ポインタ

Go言語ではポイントが使用できます。変数が存在するメモリ上の場所をアドレスといい、そのアドレスを格納できるのがポインタです。

単純な変数のアドレスを取得したい場合には,「&」を使い

fmt.Println("iのアドレス", &i)

のようにします。ポインタを格納したい変数には、*をつけて型宣言を行います。

var ptr *int

使い方はほぼ、C言語と同じはず（あまり自信がない）なのですが、唯一ポインタの演算だけ不正なメモリアクセスのリスクを回避するために許可されていないようです。

関数

関数について

Go言語は複数の値を関数で返せるので、複数の値を返す場合には一旦オブジェクトに詰め込んでオブジェクト自体を返すなどの必要があるのですが Go言語ではそれがなくなるようです。

まず単純な関数の宣言を見てみてると

/* func 関数名(パラメータリスト）戻り値の型 {
 *  return 戻り値
 * }
 */
func plus (a int, b int) int {
 return a + b
}

このような形で、多値を返す場合はカンマで区切って値を返却します。

func calc(a int, b int) (int, int, int, float32) {
  return a + b, a - b, a * b, float32(a) / float32(b)
}

こうやって見ると、受け取り側の受け取り方が気になりますが受け取り側も同じようにカンマ区切りで受け取りことができます。

add, sub, mul, div := calc(1, 2)

戻り値には名前をつけることもでき、

func calc(a int, b int) (add int, sub int, mul int, div float32) {
  // あらかじめ宣言した変数に値を代入
  add = a + b
  sub = a - b
  mul = a * b
  div = float32(a) / float32(b)

  // return文を呼び出せば多値がかえる
  return
}

このようにすることでreturn文で返す値を書きつらねなくても多値を返すことができます。

メソッドについて

Go言語では型にメソッドをもたせることができるらしく、 funcキーワードとメソッド名のまdに「レシーバ」を記述することでメソッドがどの型に所属するのか決めることができます。

※レシーバとして使用する型はメソッドと同じパッケージ内で宣言されている必要があります。

type myType init

func (value myType) println() {
  fmt.Println(value)
}

func main() {
  var z myType = 1234

  z.println()
}

さらにメソッド値なる概念があるらしく、

type myType int

func (value *myType) add(increment myType) myType {
  *value += increment
  return *value
}

func main() {
  var i myType

  // 変数i に対し、addメソッドを呼び出し、3を加算
  // => 3が出力される。
  fmt.printLn(i.add(3))

  // メソッド値を取得。このメソッド値の型は「func(myType) myType」
  methodValue := i.add

  // メソッド値に対し、メソッドを呼び出し、再度3を加算
  // => 4が出力される。
  fmt.println(methodValue(3))
}

メソッドを自体を変数に代入して、レシーバなしで変数からメソッドを呼び出せるようです。 JavaScriptでも変数にfunctionを詰め込めるのでそれと同じと理解してます。

関数の遅延実行

defer文を使うと関数の遅延実行が可能で、defer文を使うと関数の戻り値を使うことはできませんが、呼び出し元の関数が終了したときに呼び出されます。

これは、リソースの解放などに便利でファイルのオープンを例にとると以下のようなコードになります。

package main

import "os"

func main() {
  file.err := os.OpenFile("test.txt", os.O_WRONLYlos.0_CREATE, 0666)

  // オープンに失敗したときは終了
  if err != nil {
    os.Exit(1)
  }

  defer file.Close()

  file.WriteString("あいうえお")
}

例では、defer文を使ってファイルのクローズが遅延実行されるようにしてあります。 defer文がひとつの関数に複数ある場合は、呼び出し元が終了したあと宣言された順番に実行されるようです。

まとめ

長くなったので一旦ここで区切りとします。次回は構造体、インタフェース、配列・スライス・マップ、エラーハンドリング、並列処理などなどです。

この前半パートではやっぱり関数の戻り値として多値を返せるというのが印象的でした。記事にも書いたように他のプログラム言語だとわざわざオブジェクトにつけたりしていたので、それがなくなりすっきりとした関数が書けそうです。（まだ書いていないけど）

他はiota文が地味に便利そうなのと、記事で触れるのわすれたのですがswitch文は普通の値のswitchの他に型switchなるものがあるそうなのでこっちもちょっと使ってみてみたいです。

React Nativeでのルート管理ライブラリReact Navigationの使い方を整理。

Sat, 19 Jan 2019 00:00:00 GMT

これまで仕事でReact Navigationを使う機会はあったのですが、この度再度ReactNavigationをインストールから実際に使うところまでを経験できたので改めて使い方を整理します。

インストール

元はこちら

https://reactnavigation.org/docs/en/getting-started.html

インストールは現状最新版の3系を入れていきます。

まずはadd, expoは使っていないのでreact-native-getsture-handlerも合わせてインストールします。

yarn add react-navigation
yarn add react-native-gesture-handler
react-native link react-native-gesture-handler

iOSはこれで終わりですが、Android用には別でMainActivity.java に必要なコードを足していきます。

package com.reactnavigation.example;

import com.facebook.react.ReactActivity;
+ import com.facebook.react.ReactActivityDelegate;
+ import com.facebook.react.ReactRootView;
+ import com.swmansion.gesturehandler.react.RNGestureHandlerEnabledRootView;

public class MainActivity extends ReactActivity {

  @Override
  protected String getMainComponentName() {
    return "Example";
  }

+  @Override
+  protected ReactActivityDelegate createReactActivityDelegate() {
+    return new ReactActivityDelegate(this, getMainComponentName()) {
+      @Override
+      protected ReactRootView createRootView() {
+       return new RNGestureHandlerEnabledRootView(MainActivity.this);
+      }
+    };
+  }
}

これでひとまずはインストール完了です。

使い方

React NavigationではcreateStackNavigatorというメソッドでルーティングを定義するのが基本の使い方です。

StackNavigatorでルーティングを定義するまえに親玉のコンポーネントをcreateAppContainerを使って作っていきます。

const AppContainer = createAppContainer(AppNavigator);

export default class App extends React.Component {
  render() {
    return <AppContainer />;
  }
}

const AppNavigator = createStackNavigator({
  Home: HomeScreen
});

createAppContainerにはcreateStackNavigatorで作成したコンポーネントを渡し、アプリ起動後最初に呼ばれるAppコンポーネントでは、createAppContainerで作成した AppContainerのみを返却するようにします。

これでHomeScreenコンポーネントの内容がアプリ起動時に表示されます。

Stack Navigatorの基本的な使い方

Stack Navigator(Webで言うところのルート定義のようなもの)は、ルート名をキーにしたオブジェクトを引数に渡すことで定義を行なっていきます。

先ほどのHomeという根本のコンポーネント以外定義していないところに新たなルーティングを足すには、以下のようにしていきます。


const AppNavigator = createStackNavigator({
  Home: HomeScreen,
+  Details: DetailsScreen
});

ここではDetailsScreenというコンポーネントをDetailsというルーティングとして追加しています。例ではルーティングの書き方として一番簡易的なものですが、より詳細に定義したい場合はルーティングのバリュー部分をオブジェクトで以下のように渡してあげるとより細かな設定が可能です。

const AppNavigator = createStackNavigator({
  Home: HomeScreen,
  Details: {
    screen: DetailsScreen,
    naviagtionOptions: {
    	title: '詳細'
    }
  }
});

screenキーでルーティングで使用するコンポーネントを指定して、navigationOptionsでタイトルなどの細かな指定をすることができます。 navigationOptionsの細かい設定はこちらに書いてあります。

https://reactnavigation.org/docs/en/stack-navigator.html#navigationoptions-for-screens-inside-of-the-navigator

createStackNavigatorは第二引数でStackNavigatorのオプションを渡すことができます。第二引数では、遷移時のスクリーンをモーダルで出すのかや、ヘッダーのタイプ、遷移時のコールバックを定義できます。

画面の移動

遷移を行うには、StackNavigatorで指定されたコンポーネント（さきほどのHomeScreenやDetailScreen)は自動的にnavigationという stateがバインドされるので、それを使って画面遷移を行なっていきます。

先ほどの例のDetailsに遷移したい場合の構文は以下です。

this.props.navigation.navigate('Details')

propsで渡されたnavigationのnavigateメソッドにルーティングのキーを渡して画面を遷移させます。

import React from 'react';
import { StyleSheet, View } from 'react-native';
import { Text, Button } from 'react-native-elements';

export default class Home extends React.Component {
  render() {
    return (
      <View>
      	<Button
      	title="Got to Details"
      	onPress={() => this.props.navigation.navigate('Details')}
      	/>
      </View>
    );
  }
}

React Navigationで特に考えずに画面を遷移するとデフォルトでヘッダに戻るボタンが付いてきますが、意識的に画面を前の画面に戻したい場合は、

this.props.navigation.goBack()

goBackには引数を渡さずに実行すると今のルートを消して前の画面にもどるのですが、引数としてRouteを渡すと特定のRouteの一個前の画面に戻れるようで、

スクリーンA スクリーンB スクリーンC スクリーンD ← 現在地

というスクリーンがすでにスタックされており、今Dの画面を開いているが、Aに戻りたいという場合は goBack('スクリーンB')とするとD, C, Bをポップ（スタックから取り除いて）AのRouteにたどり着けるようです。

またはこの例だとStackの一番先頭のスタックに戻れれば良いのでpopToTopというAPIを使うという代替手段もあるようです。

navigation propsには画面を遷移させたり、パラメータを渡したりするAPIを備えているので詳細な使い方はこちらを参照すると良いと思います。

https://reactnavigation.org/docs/en/navigation-prop.html

遷移時のパラメータの受け渡し

Webのルーティングではurlに乗せて、リソースのIDなどを画面間で受け渡しできますがReact Navigationではparamsを通して受け渡しを行います。遷移時のパラメータはnavigateメソッドの第二引数で定義ができ、

this.props.navigation.navigate('Details', { id: 1234 })

このようにDetails画面にidというパラメータを引き渡すことができます。実際にこのパラメータを受け取る場合はgetParamを使います。

const id = this.props.navigation.getParam('id')

遷移時のパラメータはnavigatio.stateに保持されているので直接アクセスすれば値を取得することもできるのですが、パラメータが全く設定されていない場合にnull落ちするので getParamを利用してパラメータを取得することが推奨されています。


# OK
const id = this.props.navigation.getParam('id')

# NG paramsが設定されていない場合にnull落ちする
const id = this.props.navigation.state.params.id

ヘッダーのカスタマイズ

先にも少し書きましたが、createStackNavigatiorのオプションでヘッダーのカスタマイズを行うことができます。 React Navigationはデフォルトで戻るボタンをヘッダにつけてくれたりしますが、そもそもいらないという時や戻る部分の文言やアイコンを変えたいという場合にはnavigationOptionsを使ってヘッダの要素をカスタマイズできます。

https://reactnavigation.org/docs/en/stack-navigator.html#navigationoptions-for-screens-inside-of-the-navigator

タブバー

アプリなどだとこのgifのようなタブバーを設置することがあると思うのですが、それもReactNavigationを使って実現可能です。

タブバーを使う場合はcreateBottomTabNavigatorを使用して以下のように書くことができます。

const HomeStack = createStackNavigator(
  {
    Home,
    Details,
  },
  {
    initialRouteName: 'Home',
    navigationOptions: {
      tabBarIcon: <Icon name="home" />,
    },
  }
);

const MypageStack = createStackNavigator(
  {
    Mypage,
    Details,
  },
  {
    initialRouteName: 'Mypage',
    navigationOptions: {
      tabBarIcon: <Icon name="person" />,
    },
  }
);


const postLoginNavigator = createBottomTabNavigator({
  Home: HomeStack,
  Mypage: MypageStack,
});

createBottomTabNavigatorを使用しているのはコードの一番下部分なのですが、あらかじめStackNavigatorでそれぞれのTabでのルーティングを定義しておいてそれぞれを createBottomTabNavigatorに渡してタブを実現しています。

タブにはアイコンを設置するのが一般的かとは思いますが、アイコンはnavigationOptionsで設定をしています。

さらに例のGifでは、ログイン前と後でタブを出しわけしているのでログイン画面のルーティングを付け足したStackNavigatorを追加しています。


const postLoginNavigator = createBottomTabNavigator({
  Home: HomeStack,
  Mypage: MypageStack,
});

+ const AppNavigator = createStackNavigator({
+   Login,
+   PostLogin: postLoginNavigator
+ },{
+   mode: 'modal',
+   headerMode: 'none',
+   initialRouteName: 'Login'
+ })

ここではheaderModeやmodeオプションを付与していますが、headerModeをnoneにしないとログインした後の画面でヘッダーが二つになって（StackNavigatorがネストしているので）しまうのでヘッダは出さないようにしています。またログイン時にしたから浮き出るようなアニメーションになっているのも modeがmodal指定になっているからでStackNavigatorではこれらの制御も行うことができます。

以下App.jsの部分だけですが、Gifに使ったコードを載せておきます。

import React from 'react';
import { StyleSheet, Text, View, Button } from 'react-native';
import {
  createStackNavigator,
  createAppContainer,
  createBottomTabNavigator,
} from 'react-navigation';
import { Icon } from 'react-native-elements';
import DetailsScreen from './src/screens/DetailsScreen';
import HomeScreen from './src/screens/HomeScreen';
import MypageScreen from './src/screens/MypageScreen';
import LoginScreen from './src/screens/LoginScreen';

const Home = {
  screen: HomeScreen,
  navigationOptions: ({ navigation }) => {
    return {
      title: 'ホーム',
    };
  },
};

const Details = {
  screen: DetailsScreen,
  navigationOptions: ({ navigation }) => {
    return {
      title: '詳細',
    };
  },
};

const Mypage = {
  screen: MypageScreen,
  navigationOptions: ({ navigation }) => {
    return {
      title: 'マイページ',
    };
  },
};

const Login = {
  screen: LoginScreen,
  navigationOptions: ({ navigation }) => {
    return {
      title: 'ログイン',
    };
  },
}

const HomeStack = createStackNavigator(
  {
    Home,
    Details,
  },
  {
    initialRouteName: 'Home',
    navigationOptions: {
      tabBarIcon: <Icon name="home" />,
    },
  }
);

const MypageStack = createStackNavigator(
  {
    Mypage,
    Details,
  },
  {
    initialRouteName: 'Mypage',
    navigationOptions: {
      tabBarIcon: <Icon name="person" />,
    },
  }
);


const postLoginNavigator = createBottomTabNavigator({
  Home: HomeStack,
  Mypage: MypageStack,
});

const AppNavigator = createStackNavigator({
  Login,
  PostLogin: postLoginNavigator
},{
  mode: 'modal',
  headerMode: 'none',
  initialRouteName: 'Login'
})

const AppContainer = createAppContainer(AppNavigator);

export default class App extends React.Component {
  render() {
    return (
        <AppContainer />
    );
  }
}

まとめ

Stack Navigatorの基本的な挙動についてざっくりまとめてみました。 naviagteの時の細かい挙動などまとめきれていないところは結構ありそうですが、適宜追記するか、別の記事などで紹介できれば良いかなと思っています。

英語のリファレンス読むのも慣れてきたのですが、まだまだ日本語リソースの方が吸収効率がよいのでかんたんでも日本語のドキュメントあるとありがたいです。

英語力上げてこういう差がなくなればいいんですけど単純に結構コストかかりそうなので、 RN界隈も日本語ソース増えるとよいですね。

では。

2018年。フリーランス一年やってみての振り返り。

Wed, 16 Jan 2019 00:00:00 GMT

新年はじまってしばらく経ってますが、一昨年末頃にフリーランス始めてざっくり一年が過ぎたので、少し振り返りをやってみます。

なんでフリーランスになったの？

フリーランスは就職活動の時期からぼんやりやってみたいなと思ってました。

フリーランスになりたいとは思ってましたが、その肩書きに執着があるわけでなく9時17時で言われた業務をこなす人生を過ごすよりは、自分の頭使いながら分野問わず挑戦したりダラダラしたりできた方が楽しそうだなと思ったからです。

そんな中一昨年末に会社を辞める決意をして次何しようかなと考えたところ、また次会社選んでも二、三年で辞めるならフリーランスとかちょっと色の変わったことやろうかなと考えて独立しました。

もうちょっと経験積んでかやった方がみたいな所も言われましたが、フリーランスはフリーランスでフリーランス特有のスキルみたいなものがあるから早めに経験した方が得では？（フリーランスはフリーランスで値付けだったり、営業の仕方だったり、帳簿つけたりなどなどは特有のスキルかもしれません）と考えて独立しました。

今のところ思い通りにならない部分もありますが、平準化すると順調で苦境という苦境もないのでこの頃考えたことは間違いではなかったようです。

ふりかえり

フリーランスにも色々な面があるので、それぞれの面でふりかえってみました。

お金のはなし

増えました。まぁ会社員時代に比べると全然違いますね。

税金とか年金とか保険料とかもろもろ入れるとどうなの？という話はありますが、単純に自分の興味あることに経費としてお金使えて、その分の経験できるのでメリデメあるよねと考えてます。

短期的にみて金銭的、時間的な余裕ができてその余剰を自分のサービス作ったりとか、海外旅行行ったりとか、カンファレンス行ったりとかに使えるのでそこも含めてフリーランスになるかは考えないといけないんじゃないですかね？と思っています。

技術的なはなし

ReactもVueもやったことのない状態から、Rails一本でフリーランスとして独立して Rails, Vue, React, React Nativeなどの案件をこなして技術の幅と深さが広がった一年でした。

週6日で働いていた時が一番力が伸びた気がしていて、単純に週6日でRailsとReactのコードを書いていたのでそれだけでだいぶ技術力をつけられたんじゃないかと思っています。

React, React Native, Expressあたりの仕事を行うにあたって英語のドキュメントを読みながら作業することが多かったのですが、こういうところで英語の勉強しておいてよかったなと感じました。英語をよんで技術を習得する力があると、ドキュメントの少ない技術も抵抗なく入れられるのでエンジニア×英語はほんと大事ですね。とはいえ自分の英語力も大したことないので、技術力とあわせて伸ばしていきたいです。

人とのつながり的なはなし

フリーランスになってフリーランスの知り合いが増えました。

これは考えてみれば当たり前なのかもしれませんが、フリーランスや個人事業主ですと名乗ることで、昔の知り合いから連絡もらえたり、同じような人と繋がれたりしたのでフリーランス始めたての頃には考えていない嬉しい誤算でした。

気のせいか、会社員時代より知り合いも増え、知り合いも前向きで主体的にそれぞれの目標にむかって行動をしようという人が増えた気がします。「今後こうようことしていこうと思うんだよね」などなど未来志向の会話が増えた気がしています。

この先やりたいこと

一年通して、まだまだ未熟ではありますが技術的な成長や金銭面での充実やなど順調なスタートが切れた一年でした。フリーランスとしてはまずまずのスタートを切れて、ある程度落ちついてきたので、これを基盤にさらなる技術的成長を図ったり、新しいことはじめたりしたいななんて思ってます。

昨年の初めにこんなことをかいていたのですが、まぁ半分くらいできたかなぁという感じですね。

2018年やること・やらないことリスト -

残念ながらエンジニアとして以外に収益月10万円なんて書いていますが、これは結構ダメでしたね。個人で作ったサイトでぽちぽち1万円程度の売り上げが立つことはありますが安定性にかけるので、この目標も引き続き継続してやっていきたいです。

リンクの記事に書いたRails+Reactで固めてやっていくというのもできましたし、1年間生き延びるのもできました。

昨年の目標完遂とはなりませんでしたが、まぁ最低限はできたのでOKとして2019年新たに計画練り直してやっていきます。

2019年は英語力の強化とエンジアリング事業（準委任の仕事）以外で価値を出すことなどをテーマにやっていきます。英語力の強化のところでいうと2,3ヶ月ほど海外で仕事したり、英語で記事書いたりなんかもしていきたいです。

昨年は一年の目標みたいな感じのざっくりとした計画だったので、今期はもう少し3ヶ月スパンくらいのモチベーションがたもている目標を立てて活動してきたいです。

まとめ

フリーランスという働き方にたいしては賛否両論あると思いますが、ひとつのモデルケースとして今後もこういった記事をあげられればななんて思っています。

フリーランスにはやっぱり向き不向きがあると思っていて「自分で考えて実行できる人」でないとやっぱり難しいのかななんて思いました。

今エンジニアでそれなりに経験のある人だと、それなりの案件の受注はできて普通に仕事をこなしていれば普通かそれよりいい暮らしができると思うのですが、それに甘んじると社員ほどお金のかからない労働力として企業に使われるだけになってしまうので個人としてなんらかの色を出していきたいという人はぜひとも挑戦してみれば良いんじゃないでしょうか。

では。

ReactNativeで位置情報を取得する。

Mon, 14 Jan 2019 00:00:00 GMT

iOSからだとcorelocationというAPIを使って位置情報を取得できるのですが、React Nativeの場合はGeolocationというブラウザなどで位置情報を取得するAPIを使って位置情報を取得できるようです。

現在地を取得するための設定

設定方法はここにあります。

https://facebook.github.io/react-native/docs/geolocation

Geolocationを使うにはいくつか設定を行う必要があるのですが、 expoだと使えず、xcodeやandroid sdkでビルドしないとGeolocationは使えないようです。

iOSの場合

iOSの場合は、Info.plistに新たなキーを追加する必要があります。

アプリ起動中のみ位置情報を取得するには、 NSLocationWhenInUseUsageDescription バックグランドでも位置情報を取得したい場合は NSLocationAlwaysUsageDescriptionをさらに追加します。

キーの追加はXcodeから可能で、./ios下のXXXX.xcodeprojを開いて 'Capabilites'tabから設定できます。

画像だとPrivacy - Location When In Use Usage DescriptionとPrivacy - Location Always Usage Descriptionというのがそれです。

Androidの場合

Androidの場合は、AndroidManifest.xmlを編集して

<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />

を追加すればよいです。さらにAndroid API 23以降を使用する場合はを利用して権限の確認を行わないといけないそうです。

位置情報を取得するコード

上の設定が終わったら以下のコードで現在位置を取得できます。 Androidなどの場合は権限チェックしたりする必要がありますが、一旦iOS用ということで以下のようなコードになっています。

export default class App extends React.Component {
  constructor(props) {
    super(props);
    this.state = {
      location: null,
      error: null
    };
  }

  async componentDidMount() {
    const location = await this.getCurrentPos().catch(error => {
      this.setState({ error })
    });
    this.setState({ location });
  }

  getCurrentPos(timeout = 5000) {
    return new Promise((resolve, reject) => {
      navigator.geolocation.getCurrentPosition(resolve, reject, {
        timeout,
        enableHighAccuracy: true,
      });
    });
  }

  render() {
    const { location, error } = this.state;
    return (
      <View style={styles.container}>
        {!location && !error && <Text> fetching data... </Text>}
        {location &&
          Object.keys(location.coords).map(key => {
            return (
              <Text key={key}>
                {key} : {location.coords[key]}{' '}
              </Text>
            );
          })}
        {error &&
          Object.keys(error).map(key => {
            return (
              <Text key={key}>
                {key} : {error[key]}
              </Text>
            );
          })}
      </View>
    );
  }
}

エミューレータで試すとエミュレータで設定された現在地が返ってくるようです。実機でも試しましたが、試すときにiPhoneの設定で位置情報の許可をする必要があります。

位置情報の許可は「設定」->「プライバシー」->「位置情報サービス」から設定できます。

取得される位置情報オブジェクトについて

位置情報はgetCurrentPositionのコールバックで取得されますが、そこで取得されるオブジェクトはcoordsというキーを持っていますが、そのcooridsに位置情報が入ってきます。

coordisは表のようなデータを返します。

key	description
latitude	緯度
longitude	経度
altitude	高度
accuracy	取得された緯度、経度の正確性
altitudeAccuracy	高度の正確性
heading	方向。北を0として時計回りに360までの値が返却される
speed	速度。秒速何m移動しているかを表す

accuracy, altitudeAccuracyあたりがピントこないのですが、それぞれの誤差の範囲をmで表してくれるようです。

もっと詳しく知りたい方はこちらのGeolocationAPIのドキュメントから確認できます。

https://w3c.github.io/geolocation-api/#coordinates\_interface

まとめ

これで一通りRNでの現在地取得方法はまとめられたかと思います。

RNでの現在地取得を調べるためにネットサーフィンをしていたら

https://github.com/facebook/react-native/issues/671

We have geolocation support from CoreLocation (check out GeolocationExample.js), but not beacon support.

こんなissueを見つけました。CorelocationもGeolocation使っているんですかね？

わからない。

GatsbyおよびReactでのAdsense設置方法。

Sun, 13 Jan 2019 00:00:00 GMT

当サイトではアドセンスを設置していたのですが、 Wordpressからの移行に際してReactでアドセンスを設置することになったので、 Reactでのアドセンスの設置方法をまとめておきます。

Gatsbyの場合、記事外はReactコンポーネントで表現できますが、記事内はマークダウンなのでレンダリング時(ビルド時)にadsenseを埋め込む形にしています。

記事外の設置

記事外に設置する場合は、もともとのアドセンスのコードが以下だとすると

<script async src="//pagead2.googlesyndication.com/pagead/js/adsbygoogle.js"></script>
<!-- レスポンシブ広告2 -->
<ins class="adsbygoogle"
     style="display:block"
     data-ad-client="XXXX"
     data-ad-slot="XXXX"
     data-ad-format="auto"
     data-full-width-responsive="true"></ins>
<script>
(adsbygoogle = window.adsbygoogle || []).push({});
</script>

adsbygoogle.jsは他のレイアウトテンプレート内で読み込んでおくとして、最終的には以下のように、

<scrip>
(adsbygoogle = window.adsbygoogle || []).push({});
</script>

このscriptタグの部分とinsタグの部分を分割して、 (htmlタグはjsxに変換しています。）

class Adsense extends React.Component {
  componentDidMount() {
    if (window) (window.adsbygoogle = window.adsbygoogle || []).push({});
  }
  render() {
    return <div>{this.props.component}</div>;
  }
}

const Rectangle = () => {
  return (
    <ins
      className="adsbygoogle"
      style={{display: 'inline-block', width: '300px', height: '250px'}}
      data-ad-client="XXXX"
      data-ad-slot="XXXX"
    />
  );
};

const AdsenseRectangle = () => <Adsense component={<Rectangle/>}/>

export default AdsenseRectangle

のようにします。

Gatsbyでは、ビルド時にwindowが空でビルドされるので、 componentDidmount内で叩くのが望ましいです。

 (window.adsbygoogle = window.adsbygoogle || []).push({})

またAdsense広告も種類(AMP広告だったり、記事内広告だったり) があるのですがwindowの部分は変わらないのでそれぞれ中身だけ変えられるようにAdsenseという名前の親コンポーネントを作り、そこに中身をpropsとして与えるように作っています。

記事内の設置

記事内の設置はGatsby内部だとMarkdownがhtmlに変換されてコンポーネントに渡されてくるので、 htmlを書き換える形で実現しています。

記事内のMarkdownに特定のセレクタをもったdiv要素を仕込んでおき、そこにadsenseのタグを挿入する感じでアドセンスを設置しています。

コードで書くと以下のような形です。

const parser = typeof DOMParser !== 'undefined' && new DOMParser();

export const insertAdsense = ad => html => {
  if (!parser) return html;
  const dom = parser.parseFromString(html, 'text/html');
  const eles = [].slice.call(dom.querySelectorAll('.adsense'));
  if (eles) {
    eles.map(ele => (ele.innerHTML = ad));
  }
  return dom.body.innerHTML;
};

記事の中身を表示するコンポーネントで

insertAdsense([アドセンスのコード])(html)

のように呼び出してあげるとコードが挿入された形のhtmlが返却されます。

コードの中身は、先ほどあげたアドセンスのコードのadsbygoogle.jsの部分を抜いたものを渡します。こちらもAMP広告かどうかなど中身が変わるのでアドセンスのコードを外から渡す形にしています。

まとめ

これらを自分で実装した時は、windowの部分やDOMParserの部分でつまずきました。 develop環境では特にこれらを考慮しなくても動くのですが、実際にビルドしようとした時にこけます。

windowとかDOMParserが使えるかどうかはwebpackのビルドモードに関係しているっぽいです。

https://webpack.js.org/concepts/targets/

Nodejsでmkdir -pをする。再帰的にディレクトリを作成する。

Sat, 12 Jan 2019 00:00:00 GMT

Node.jsでmkdir -pをしたかったのですが、Node10系からでないとmkdir, mkdirSyncなどのディレクトリ作成メソッドのrecrusiveオプションが使えません。

https://nodejs.org/docs/latest-v10.x/api/fs.html#fs\_fs\_mkdirsync\_path\_options

Node8系などで、パスを与えると存在しないディレクトリも含めてズバッとディレクトリを掘ってくれるコードを残しておきます。

const fs = require('fs');
const mkdirSyncRecrusive = postPath => {
  postPath.split('/').reduce((acc, item) => {
    const path = item ? [acc, item].join('/') : '';
    if (path && !fs.existsSync(path)) {
      fs.mkdirSync(path);
    }
    return path;
  }, '');
};

mkdirSyncRecrusive('/dir/you/want/to/make')

Gatsbyビルドでprismjsのsyntax hilightが効かなかった話

Fri, 11 Jan 2019 00:00:00 GMT

最近、当サイトをGatsby+Netlifyでリプレースしたのですが、

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

もともとのWordpressから記事を移行しもろもろレイアウト変えたりの実装を終えていざNetlifyにデプロイしてみたところ、なぜかPrismjsのSyntaxHilightが聞いていない状態に気づき絶望しました。

原因はpurgecssという使っていないcssをビルド時に取り除いてくれるプラグインが原因でした。

わかってみるとなんてことのないものなのですが、手元ではハイライトされているのに、デプロイするとハイライトが効かないという非常に気持ち悪い挙動だったので同じように困る人がいないように記事にまとめます。

Purgecssとは？

https://www.purgecss.com://www.purgecss.com/

Purgecssとは、使っていない不要なCSSを取り除いてくれるライブラリです。 webpackのプラグインとしてかませて、ビルド時にcssを軽くしてくれます。

今回は、gatsbyのプラグインとして利用しており最初からインストールされていたので「なんかあるなー」とは思っていましたが、prismjsシンタックスハイライトが効かない問題が表面化するまでは特に気に止めていませんでした。

https://www.gatsbyjs.org/packages/gatsby-plugin-purgecss/

プラグイン時の設定で開発時でもpurgecssを動かすかどうか決められるのですが、デフォルトではビルド時しか動かないので、ビルドするまで気づかなかったという感じです。

原因特定の経緯

prismjsがビルド時に効かない問題の事象ときてはdevelop時は普通に動くけどbuild時には動かないという所だったので、それぞれの条件でどういう所に差異があるのかなとか考えながら色々と見ていると、 gatsby-config内にpurgecssといういかにもcssをいじっているそうな奴がいたのでコメントアウトしてビルドすると見事にシンタックスハイライトが効くようになりました。

原因が判明した後にビルドの出力をみてみると、こんな感じで結果を出力してくれてました。（purgeしたら75%もサイズが小さくなってますね。）

さらに良く調べてGatsbyのプラグインのページでドキュメントを確認すると、 purgeした結果を出力できるようです。

gatsby-configでprintRejected、printAllをtrueにすると取り除かれたcssを確認できます。

gatsby-config.js

{
  resolve: `gatsby-plugin-purgecss`,
  options: {
    printRejected: true,
    printAll: true
  }
}

この設定で再度ビルドすろと、 cssフレームワークとしてmaterializeを入れているのでそこらへんの使用していないセレクタ達がバスバスpurgeされていて、見事にprismjsもパージされていました。

Prismjsを取り除かないように設定

原因がわかったのでPrismjsが取り除かれないように設定します。 ignoreオプションが用意されているのでそこにprismjsを加えて完了です。

{
  resolve: `gatsby-plugin-purgecss`,
  options: {
    printRejected: true,
    printAll: true,
+    ignore: ['node_modules/prismjs/']

  }
}

Selectorベースで取り除かないように設定

ライブララリベースだとprismjsがごっそりpurgeされていたのですが、自分で書いたcssでもいくつか取り除かれてしまっているのがあったので、 whitelistにセレクタのパターンを書いてこちらも取り除かれないようにしました。

{
  resolve: `gatsby-plugin-purgecss`,
  options: {
    printRejected: true,
    printAll: true,
    ignore: ['node_modules/prismjs/'],
    whitelistPatternsChildren: [/^post/, /^sns-buttons/]
  }
}

詳しいオプションの設定はこちらで確認いただければと思います。 https://www.gatsbyjs.org/packages/gatsby-plugin-purgecss/

まとめ

以上、Prismjsがビルドした時に効かなかった話でした。

取り込んでいるプラグインくらい把握しておけという話ではあるので、Gatsby使っているところでのつまずきぽいんだったのでまとめておきます。

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

Thu, 10 Jan 2019 00:00:00 GMT

久しぶりの投稿ですが、新年始めての投稿になります。しばらく投稿が滞りましたが、これには深い理由がありまして、みてわかるようにこのブログSo Far, So Techを12月から年始にかけてせこせこと Gatsby+Netlifyでリプレース作業をしていました。

結果的に1ヵ月ほど仕事の合間にせこせこ作業して今回無事リプレースを終えることができました。 Wordpressのブログよりまだまだ機能は少ないですが、今後も必要そうな機能をたしていこうかななんて思っております。

Wordpressからの移行作業では紆余曲折いろいろなことがありましたので、なんで機能豊富なWordpressをやめてGatsbyでサイトを作ろうと思ったのか、移行で苦労した部分などをまとめます。

なぜWordpressをやめたか、なぜGatsby+Netlifyを選択したのか？

まず、なんでWordpressをやめたのかというところですが大きく分けてここらへんになると思います。

Wordpressのコードと向き合う勇気がもてなかった。
CSS書くのがつらい。
コードがgit管理できない。コードミスると一発でサイトが動かなくなる。
もっとカジュアルに記事をかきたい。(Markdownなど)

一応箇条書きにしましたが、Wordpressをやめたかった理由は

「Wordpressのコードと向き合う勇気が持てなかった」

という一言につきると思います。

Wordpress導入当初は、ブログを書くために導入コストの低いWordpressを選択しましたが、ブログを続けているうちにだんだんとWordpressがつらくなってきました。

普段の開発の仕事はPHPを書いているわけでもないし、Wordpressを使って仕事しているわけでもないのでWordpressと悪戦苦闘しながら現在の標準になっているような開発の仕方を取り入れていくことに全くもってメリットを感じませんでした。

cssを書くにも、コードを修正する、ソースを管理するにもなんにしても Wordpress独自の手法をインプットしつつこのサイトに適用していくといく作業が非常に苦痛に感じられました。

その点、GatsbyはReact+Graphqlで静的サイトを構築できもちろん普段使い慣れた npmパッケージも利用できるので自分の技術スタックとの親和性や興味の観点からでもピッタリでした。

記事をコードとして編集して、コミットしてmasterにプッシュすれば記事が公開されるというのが普段の開発と同じようにできるので、仕事しながら記事を書く上で抵抗なく使えます。

まぁ色々と理由はあるのですが、単純にGatsby使うとReactでコード書きながら自分のサイトを思い通りに構築できるので、移行作業そのものが楽しかったですし、今後もストレス少なくサイトのメンテを行えそうです。

リプレースにあたってやったこと

Wordpressからgatsbyに移行するにあたってやったことを載せておきます。 Wordpressはやはり機能豊富でgatsbyで一から全部作っていくのはなかなか骨がおれましたが、だいたいどのサイトでも以下の作業は必要かなという感じです。

AMP対応は結構大変だったので、ここは個人の判断でリプレース前に対応するか、リプレース後に対応するかというところは決めれば良いのではないでしょうか。

記事の移行
画像の移動
Wordpressの機能の再現
AMP対応

記事の移行

WordpressはAPI機能があるのでそれを使えば、Wordpressで記事を書いてGatsby 側でAPIを叩いて記事を生成するということができそうなのですがWordpressとの関係をなるべく切って行きたかったので、既存の記事をSQLでcsvとして出力してスクリプトを書いてmarkdownに変換してきました。

スクリプトは慣れているrubyで書きました。 https://github.com/version-1/blog/blob/master/scripts/wp2md/index.rb (一度変換したあとは使っていないのであまり綺麗ではないです。）

gatsbyではマークダウンのヘッダに記事のタイトルやテンプレートの情報を書き込むのでcsvから必要な情報を抜き出し、ヘッダに書き込み、記事部分はそのままcsvのものを突っ込むようなスクリプトです。

wordpressで記事は基本的にhtmlで書かれますが、markdownがhtmlのタグも許容しているので記事部分はそのままコピーしています。

ただescapeされているhtmlを元に戻す作業など地味だけど大変な作業もありました。

画像の移動

画像の移動はとりあえず、手元から配信する感じにすればいいやーという甘い考えで取り組みました。画像はwordpressの物をそのままコピーしてきてもよかったのですが、どの記事でどの画像を使っているのかが一発でわかると楽なので、

[ 記事ディレクトリ ] +- index.md
                     |- image1.png
                     |- image2.png

のような形で保存されるように工夫したりしました。

こちらもスクリプト書いて対応しました。 https://github.com/version-1/blog/tree/master/scripts/fetchImages

ただ、手元に画像を保存してgatsby-imageで画像を読み込む感じにしたところ開発中でも都度画像がblobに変換されるのでビルド時間がのびて開発中とてもストレスフルな状態になったので、画像は外部に置く感じにしてs3 + cloudflareで配信するようにしました。 (手元に画像はあったので階層構造そのままs3にアップロードしました。)

Wordpress機能の再現

自分で実装するとわかるのですが、WordpressおよびWordpressテーマ、プラグインには豊富な機能があり、自分で実装するとそのありがたみがわかってきます。AMPなどもそうですが、ありがたみを感じながら、Wordpressとの縁を断つべく感謝の移行作業の一覧はこちらです。

レイアウトの変更
ページネーション
sns ボタン
GA
Adsense
ogp
rss
404ページの作成

これら全部が全部自前で実装したわけではなく、プラグインを導入したりしたものがほとんどなのですが、wordpressで実装されていた機能を洗い出し取捨選択して実装していく一連の作業がそれなりに骨が折れました。

Adsenseの埋め込みなどは、記事外部には自由にreactコンポーネントで実現できるのですが記事内(マークダウン内）にどうやってAdsenseをはめ込むかなどは考えて実装しました。

Gatsbyという記事を採用する以上ここの大変さはある程度しょうがないですが、リプレースにむけて本当に必要な機能を絞り込んで実装していくのが大切かなと思います。実際現状関連記事の表示や月別アーカイブ、タグ機能、検索などなど機能が不足しているのでおって実装していく形です。

AMP対応

これが4つの中で一番大変でした。単純な記事のAMP化もあるのですがvideoタグやiframeなどなどそれぞれのタグが必要だったりadsense, gaなども個別で対応必要だったりして大変でした。

当初はプラグインがあるので「これで行けんじゃね？？」と思っていたのですが、プラグインが思うように動かず自分で実装しました。 (jsdomがうまく動かずとりあえずissueだけあげときました。)

自分で実装してnetlifyにあげた時にこれだけのAMPエラーが見えた時はさすがに心が折れかけました。

gatsbyでのAMP対応は大変だった分学びも多かった気がするので別途記事にするかもしれません。

Gatsby導入をオススメする人の特徴

今回Gatsby+Netlifyでブログをリプレースしましたが、やっぱり自分の興味ある技術を使って開発をしていくと多少大変でも面白みがありました。

そんな中で、実際にGatsby導入をおすすめする人の特徴をまとめるとこういう感じになります。

Wordpress辞めたい
ブログも普段の開発同様の運用にしたい
Reactが使える（使えるようになりたい）
英語のドキュメントが読める

ここまで色々と書きましたがGatsbyで実際にブログを構築していくにはそれなりの技術力が必要だと感じています。日本語の情報はやはり少ないですし英語のドキュメントを読みながら試行錯誤していく必要があります。

ただ、Gatsby+Netlifyのような構成でブログを構築すればほぼお金がかからず (ドメイン代くらい）にすむのでレンタルサーバ+Wordpressよりは安くすみそうですし、 Reactを初めしたWebフロント力をつけていくことができます。

Wordpressやめたいんだけどなんか良いCMSライブラリないかなぁなんて人にはオススメです。

まとめ

今回のリプレースは大変でしたが、Graphql使ったりnetlify使ったり、Reactのコード書いたりで楽しみながら作業させてもらいました。

AMP対応などなどそれぞれの知見は記事にできればなと考えておりますので折を見て投稿していきます。

では。

フリーランスエンジニアが初めに選ぶオススメのフリーランスエージェント3選。

Mon, 03 Dec 2018 00:00:00 GMT

フリーランスになる時の手っ取り早い方法がエージェントに案件を紹介してもらい、案件に参画することですが、

「エージェントってどこが良いの？」

「それぞれどんな所に違いがあるの？」

という疑問があると思うので、自分なりにここらへんが良いのではというエージェントをいくつか選びました。

「エージェントをつかうメリット・デメリットは？」

「そもそもフリーランスって良いの？」

みたいなところは、一旦置いておいて（下の方でそれぞれ書いています）オススメのエージェントを紹介します。

エージェントを利用するメリット・デメリット

タイトルの都合上先にオススメのエージェントさんを紹介させて頂きましたが、ここからはエージェントを利用するメリット・デメリットを書かせて頂ければと思います。

エージェントを利用するメリット

不慣れな契約や案件探しをサポートしてもらえる

ここは散々言われている部分ではあると思いますが、フリーランスなりたてのころは相場観がわからなかったり案件の進め方がわからなかったりするので業界経験の長いコンサルタントに色々と聞いてフリーランスについての知識を深めることができます。（需要の多いプログラミング言語や現場のレベル感など）

また、多くの方がこれまでエンジニアとしての社会人経験がメインの人が多いと思いますので契約の仕方などに不慣れな人が多いと思います。エージェントを使うと契約書の作成や現場との調整をお願いできるのでエンジニアとしての自分の作業に集中することができます。

エージェントの方とは定期的に連絡をとることになるので今の現場の状況やこうしたいというのを伝えておくと、契約の切れ目などに「次どうしますか？」「ここの現場である程度経験をつめたので次の現場ではもうちょっと単価よくなりますよ。」などのアドバイスをもらえたりします。

組織体制の整った案件が見つかる

これは完全に肌感ですが、エージェントさんを通すと一定のスクリーニングが効いているのかある程度組織体制ができた会社に出会える気がします。

もちろん、大企業レベルまで分業がされているわけではなくあくまでもスタートアップやベンチャーの企業さんが中心になるのですが、ベンチャー・スタートアップでもエンジニア・マーケ・営業などそれぞれのチームは小さいですが部署間の分業をしっかり図っており、組織としてのパフォーマンスが最大化されるような組織づくりをしようという意図が感じられる企業さんが多いです。（人手不足などの問題もやはりあり理想とはいえない部分も多くありますが）

こういったそれぞれの社員が集中しやすい環境の現場に入れるとエンジニアは安心して自分の技術力と向き合いながら開発できるので、こういう現場に出会えると幸せなのかなと思います。

エージェントを利用するデメリット

仲介手数料（マージン）の分収入が下がる

これもよく言われることですが、エージェントさんを挟む場合と挟まない場合では単純に企業さんとフリーランスの間にエージェントさんが入る形になるので、企業から支払われる報酬の一部がエージェントの取り分になります。

そのため、直契約の場合とくらべ相対的にフリーランスへの報酬は少なくなります。

働き方の柔軟性がさがる。

エージェントさんを使った場合、会社員時代に比べれば圧倒的に働き方の柔軟性が出る可能性は高いですが、直契約に比べるとまだまだ働き方の柔軟性は低いです。

エージェントさんを利用すると基本は週5日の常駐案件が基本ですし、それなりのスキルがないとリモートワークの案件を獲得するのはなかなか難しいです。

一方直契約の場合はクライアントさんとの関係性でだいぶ柔軟な働き方ができるので（現実として、リモートの仕事や週3日程度の仕事していますし界隈でそういう話も聞きます。）

フリーランスならエージェント使うべき？

エージェントを使うか使わないかという所に関する私の意見では、

エージェント使う場合と使わない場合でメリデメあるのでそこ理解しながら使い分けましょうね。

というところが最終的なところです。

ある程度のフリーランス歴が長いと業界でのつながりができていたりして、知り合いに案件聞きながらという形でも回せるのですが駆け出しフリーランスや現在会社員の方はそういったつながり少ないので、エージェントを使ってさっと案件に参画して実績なり経験なりつながりなりを作ってしまった方が良いと思われます。

一方、エージェントしか案件獲得できない状態だと多くの人が希望するであろうリモートワークや週3日などの案件を実現するのが難しくなるので、個人レベルで案件獲得できるスキルを磨くことも大切です。

なので、エージェントを使うか？というところに対してはケースバイケースというあやふやな答えしかできないのですが、

これからフリーランスを始める方にはエージェントを利用して案件獲得するのがオススメ

というのは行っておきたいと思います。「フリーランスになろうかな〜。どうしようかな〜」と悩んでいる方は多いと思いますが、どれか一つエージェントさんに登録してしまえば色々な話もきけるので、考える前にまず行動という形でぜひ一度エージェントさんの話を聞いてみるとよいでしょう。

ぶっちゃけフリーランスって良いの？

ここまで、これからフリーランスになるならエージェントさん使いましょうというところやエージェントと直契約のメリ・デメみたいなところをお話しましたが、こちらを読まれている方からすると「フリーランスって実際どう？」というところも気になるのではないでしょうか？

幸いなことにフリーランスになって今までのところ年収も増えて働き方も柔軟になってReact,Vueなどの割と新しい技術を使いながら仕事ができているので本当にフリーランスになってよかったと思っています。

なので、これからフリーランスになるか悩んでいる人は一回やってみればと思っています。

ただ、ここ一年くらいフリーランスとして働いてみるとやっぱり、「エンジニアとして何歳くらいまでコード書いて仕事できるかなぁ」という不安は常に付きまといます。

コードがかけることはそれだけで十分素晴らしい専門性で価値のあることだとは思っているのですが、40歳になって人並みにコードかけるだけとなるとちょっと厳しいかなという感じもありますし個人的に人生色々なことに挑戦してみたいという志向がある私にとっては少しものたりない部分も感じます。

なので、フリーランスエンジニアという部分をベースに今後もう少し自分の幅を広げられる活動ができると良いのかなというのも考えています。

フリーランスという働き方は本当になにするにも自由なので、何もしないでただ目の前の案件をこなすということもできるのですがそれだとフリーランスである意味をあまり感じないです。

なのでフリーランスエンジニアとしてやりつつも自分のサービスも作りたい！や空き時間を利用して飲食店やってみたいなどなどフリーランスという働き方を生かして複数の物事にチャレンジできる人はぜひやってみると良いと思います。

また、↑このようにエネルギッシュに振る舞えるかわからないけど、やってみたいという人は一度フリーランスになってみてから考えるということでも良いと思います。周りでもフリーランスになった後にやっぱちがうとなって会社員に戻る方もいるのでそういうキャリアも全然ありだなと思います。

フリーランスという状況を楽しめて行動できる方にはぜひともオススメですし、色々悩んでいるけどやっぱりフリーランスになりたい！という方には一度フリーランスになって考えることをオススメししておきます。

まとめ

先の項目にもかきましたがフリーランスという働き方を楽しめる人にはフリーランスおすすめです。「そんなのなってみないとわからないよ！」というのも確かにそうだなと思います。実際私も「やってみたいし、なってみないとわからないことも多いから」というのがフリーランスになった動機でした。

これからフリーランスになる方にはエージェントを利用して生活の基盤を固めた上でフリーランスをスタートさせるのがオススメですので上にかいたようなことを参考にしながらスタートを切って頂ければと思います。

では。

フリーランスエンジニアなるには？ソフトランディング戦略でいってみよう

Mon, 26 Nov 2018 00:00:00 GMT

どうも、フリーランスのエンジニアをしております。version-1です。

そろそろフリーランスになって一年が立とうとしているので、フリーランスのなり方みたいなところを書いてみたいと思います。

フリーランスのなり方みたいなところはネット上にたくさんの記事が乗っていますが、リアルな世界で割と「フリーランスってどうやってなるんですか？どうやって仕事とってるんですか？」のような質問されることが多いので改めてまとめておこうかなとおもいました。

一応簡単に経歴を説明するとSIer二年半ののちに、事業会社の社内エンジニアを経て昨年独立して、現在はRails, React/Vueなどの技術をメインに自社サービスを開発している会社様のお仕事を手伝わせていただいているような形になっています。

幸いなことに、フリーランス一年目から収入的には安定し、月ごとの売り上げが乱高下することなく徐々に上がってきていて、フリーランスのスタートととしてはまずまずの成果があげられたのかなと思っているので、自分がフリーランスとして安定的に仕事をとれるまでどういう意識で取り組んでいたかを書いていきたいと思います。

ソフトランディング（やわらかな着地）戦略とは？

これはタイトルに書いて「？？？」となった人もいるかとおもうのですが、勝手にわかりやすいように名前をつけました。

これは特段特別なことはなく、

フリーランスの最初のうちは、エージェントなどを使って常駐型の案件を獲得して正社員の時とあまり変わらない状態ではじめよう

というとことです。

要は「フリーランスになる！」とかいって思いっきり覚悟決めて、今までリモートとか全然やったことがないのにリモートの案件しか探さない。エージェントに仲介手数料とられるのがいやだから最初から不慣れな直契約を獲得のために動く。などのフリーランスっぽい感じをいきなり目指さないということです。

フリーランスになる方はやはり自由な働き方や高単価を求めていることが多いと思いますが、いきなりそこを目指すよりは徐々にそこに近づいていくというのが現実的で精神的に負担が少ない戦略なのかなと思っています。

実際私自身もフリーランスになる前に、知り合いのエージェントさんに相談してこれくらいの経歴であればフリーランスでもいけますよ。と言われたのでそこから常駐の案件に参画して、10ヶ月くらいかけてフルリモートにシフトしていきました。

正直なところ、常駐型のフリーランスのエンジニアになると正社員と変わるのは単価とかくらいなのでフリーランスになってからも正社員の時と同じような形ではたらけてあまり変化はないです。

ここに安住してしまうのはよくないですが、フリーランスになって最初はやはり不慣れなことも多いので劇的に環境を帰るのではなくこういった周りのサポートを受けやすいような形でソフトランディングしていけば良いのではないでしょうか？

エージェントを使用するか？知り合いつたいか？

フリーランスエンジニアになる文脈でエージェントに紹介してもらうのか、知り合いに紹介してもらうのかといった話はありますが、個人的にもともとベンチャー、スタートアップでバリバリ仕事していてい知り合いがたくさんいるとかでなければエージェントを利用してスタートをするのが得策です。

エージェントさんを利用すると企業側から支払われる一定の割合がエージェントさんの取り分となるわけで、相対的に直契約に比べて個人事業主側の取り分が少なくなりがちです。ここはデメリットに思われる方も多いの方思うのですが、やはりある程度しっかりしたエージェントさんに紹介してもらえる企業というのはビジネスなどトータルでみてしっかりしている企業さんをチョイスして紹介してもらえるので十分にエージェントさんを利用する価値はあります。

特にフリーランス始めたての頃というのは、フリーランス同士のつながりみたいなのも少ないことが多いので最初の案件でしっかりした企業さんのプロジェクトに参画して繋がりを作れると良いのではないでしょうか？私もフリーランスとして最初に受けた案件は常駐の仕事でしたが、現場には同じようなフリーランスの方もいてそこで知り合いになれたり、企業の中のエンジニアと知り合えたりというのができて大変よかったです。

知り合いつてでフリーランスを始めるのも良いのですが、自分の知り合いで成長段階の企業である程度社員もいて体制が整っている、最新の技術をキャッチアップしているという人と知り合いであることは少ないので、そういった会社とのコネクションを持っているエージェントに頼るというのは全くおかしいことではありません。

参画案件の成長性って関係あるの？

こういう話をしていると

「業務委託でちゃんと支払いだけもらえれば、企業の成長とかはスコープ外だ」

ということを言われる方もいるかとは思うのですが（個人的にはあまり同意できない意見です）、やはり組織としてある程度成熟しているか成長している会社でないとエンジニアとしての普段の業務にも支障がでてきます。

やはりエンジニアですと自分の作った機能は使ってもらいたいですし、使われるかどうかわからない機能は実装したくないと思うのですが、マーケティング体制などが弱く感覚で機能を実装するやりがいを感じられないような所にいると徐々に開発へのモチベーションが下がってきたりすることも往々にあります。

また、ある程度小さな会社だと多めにみる部分はありますが、社員の出入りの激しい現場では開発へのノイズも多いです。

個人的な肌感ではあるのですが、エージェントさんから紹介される企業はやはり売り上げや成長性などもしっかりあり組織としても強い印象があるのでフリーランスの始めのほうにそういった会社さんで働かれるのをオススメします。

正社員の転職でもある程度名の知れた企業につとめていた人が転職の時に有利になるのと同様にフリーランスでも前の現場の実績が評価されるのである程度しっかりした会社の案件に参画するというのは後のフリーランス人生を考えても有利に働きます。

常駐型案件に入ったあとは？

ここまでの戦略を実践して、常駐型案件に入った後の話ですが最初の案件で徐々にリズムが掴めてきたらだんだんと自分のやりたい方に近づけるためのアクションをとれると良いのでしょうか？

私の場合は、働く際の場所への依存を一回取り払いたかったのと単価をあげたかったので常駐案件は週4日程度に抑えて並行で案件を探して、見つけた週二の案件を同時に並行して行いました。この週二の案件はリモートだったのですが、エージェントさんの案件ではまだまだリモートができるかつ週二、三日でOKな案件はまだまだ少ないのでフルリモートを目指される方は常駐の案件をベースに個人で（エージェントを使わずに）リモートの案件を探されると良いです。

リモートの案件の獲得のために使える手段としてはは、twitter、ブログ、各種勉強会やミートアップ、同じ現場の人の知り合い、前の職場の同僚などではないでしょうか？

私の場合はこのブログでの案件を獲得した実績もあり、そこまで多くに読まれるブログでもないのですが一定数スカウトのメールみたいなものは届くのでブログの更新というのは割とオススメの方法です。

ここでは、リモート案件獲得についてしかいていないですが他にもエンジニア以外の仕事をやりたい！などなど色々な方向性はあるのである程度フリーランスに慣れてきた所でつぎのアクションをとり徐々に目標に近づけていくという戦略をとってみるのをオススメします。

まとめ

ここまでソフトランディング戦略という勝手に名付けた方法について説明しましたが、いかがだったでしょうか？

簡単にまとめると

エージェントを利用して常駐型案件獲得
並行して別案件を探す
自分の目指したい方向性をめざしてアクションをとる。(リモート案件や高単価案件など）

となります。難しいことはないです。ただたソフトランディングしていきましょうということです。

また、書いてみて気づいたのですが、これはここまでに僕がとった戦略を説明しただけで必勝法でもなんでもなくある意味ポジショントークです笑。

とはいえ、一年という短い期間ですがここまで大きなストレスやブラック化することなく続けられている一定の成果が期待される方法ですので一つのモデルケースとして記憶にとどめておいて頂ければと思います。

フルリモートエンジニアになったので、これまでの経緯をまとめてみた。

Sun, 14 Oct 2018 00:00:00 GMT

この度10月からフルリモートエンジニアになったので、振り返りがてらフルリモートのエンジニアになるためにやったことをまとめました。

フルリモートというのは、フリーランスのエンジニア（業務委託のエンジニア）の仕事というと常駐型（お客様先のオフィスに行ってそこで仕事をする）とリモート型（家でお仕事）に別れるのですが、このリモート型の案件だけを持っている状態を個人的にフルリモートと呼ばせて頂いています。

フルリモートになるためにやったこと

「フルリモート」という働き方が自分の中で現状そこまで優先順位が高くなかった（単価などの方が気になっていました。。）のですが、移動せずに仕事ができるのであればそれが理想の環境でもあるので少し嬉しくラッキーという感じです。

これやれば絶対リモート案件とれる！みたいなのではないですが僕が実際に行ったことでフルリモートになるに当たってプラスに働いことをあげてみます。

ブログを書く

これは予想外だったのですが、ブログ経由でお仕事の依頼を受けることがありました。単発の仕事もありますし、継続的なものもあります。このブログ自体そこまでPVも多くないので見ているひとは見ているのだなと感じました。ブログ経由でコンタクトをとってくるような会社さんだと柔軟な考え方をされる方が多いので比較的働き方も自由なのではないでしょうか？

以前、どこかの記事でブログにTipsの様なものを書くのも大事だけど、仕事への考え方とか大事にしているものが見える記事も載っけておくとオファーも出しやすいよというのを見たことがります。その人が考えていること、関心ごとがみえるブログだとそういう仕事のオファーもきやすいのかなと思いました。（ちなみに、僕の場合はオファーした会社が使っていた技術で検索上位に来ていたから連絡がきたらしいです。。）

スタートアップなど比較的若い会社とお仕事をする

スタートアップなど比較的若い会社ではリモート勤務のメリットを理解している場合が多く交渉によってリモートにできたり、そもそも常駐しているひとがあまりいないなんてことも多くあります。

僕自身小さいチームで仕事をする方が好きで、スタートアップの雰囲気なども好きなのでそういう案件の話が来ることが多いのですがフリーランス自体働き方みたいな部分は本当にクライアントさんに左右されるので、自分にあった働き方ができる会社というのがどういうものかというのはなるべく明確に持っていると良いです。

フリーランスになったことを公言する

FacebookでもTwitterでもInstagramでもなんでも良いのですが身近なつながりのある人たちに対してフリーランスになったことを伝えるのは意外と大事です。各種SNSだと前に一緒に仕事をしていた人と繋がっていることも多いのでそういった場で自分がフリーランスであることをしっかり書いて共有しておくと、エンジニア必要な知り合いが連絡してきて頂けたり、仕事を紹介してもらえたりします。

エンジニアは供給不足なんてのもよく言われますが、本当にちょっとした知り合いから連絡もらえることも多いので、フリーランスの方々はこう行ったところも意識して発信できるとよいかもしれません。

フルリモートになって実際のところどう？

フルリモートになって、やはり通勤がないぶん朝の隙間時間にブログ書けたり、コード書けたり、勉強ができるのでやっぱり快適だなという感じです。

ただ仕事ベースで考えるとずっーーーと家にいて仕事しているというのはやはり辛そうです。人と話さなくなるというのもそうかもしれませんが、現場にいないとプロジェクトの進み具合や温度感が雑談などを通して入ってこないのでやはりコミュニケーションの部分で限界を感じつつあります。

週に二、三回も出勤する必要はなさそうですが、二週に一二回は出勤してチームのメンバーと雑談したり打ち合わせしたりをするっていうのを意識的にやっていかないと仕事を進めるのに支障をきたしそうな気配を感じております。

ここらへん私自身もリモートの経験はまだまだなのでどうやるのが良いのかわからないのですが、仕事をしていきつつベストプラクティスを見つけていければなという感じです。

まとめ

今回はフルリモートエンジニアになったので、節目としてこういう形でまとめさせていただきましたが「フルリモート最高！！」みたいな感じではないです。リモートも常駐もやはりそれぞれ一長一短あるのでそれぞれを組み合わせつつうまくワークする仕組みを模索できればなとおもっています。

では。

これやっておけば・・・とならないために。アメリカに行く前の準備まとめ

Fri, 21 Sep 2018 00:00:00 GMT

この度一週間ほど、アメリカ旅行にいってきたのでアメリカに初めて行く方のためにアメリカ旅行のための準備をまとめておきます。

アメリカは今回二回目、海外旅行自体もすでに数回こなしているので今回は大丈夫！かと思いきや同行者の準備も含めて万全の準備というのはなかなかなか難しいです。

次回旅行する際にぬかりない旅行をするためにもここに記事として残しておきます。

パスポート

これは言わずもがな、国外に出るのであればパスポートは必須です。また海外で飲酒する際やカジノ、クラブなどに入場する際にID(身分証明書）の提示を求められることも多いので海外旅行時は常に携帯しておきたいもののひとつです。

申請の豊富おは住民登録をしている都道府県のパスポート申請窓口での申請になります。

詳しい方法はここでは書かないので下記外務省のリンクを参考にしていただけるとよいかと思います。 https://www.mofa.go.jp/mofaj/toko/passport/pass_2.html

申請してから取得までは長くても10日間ほどでできるようですが、各種住民票や戸籍謄本などの準備も必要なので90~60日前くらいからは動きだして、余裕を持って準備を進めていきたいですね。後述するESTA申請もあるので早めの準備を心がけたいです。

航空券

こちらも言わずもがなですが、アメリカ渡航のためのチケットです。候補としては、JAL,ANAやDelta,American、他アジア系航空会社などありますがアジア系の会社だと香港でトランジットして移動に20時間以上かかるなんてチケットもあるので価格と相談しつつも最適なチケットを予約しましょう。

JAL,ANAは日本の会社ということもあり機内食もおいしく、サービスが行き届いてますがその分高いです。American,DeltaなどはJAL,ANAなどに比べればお手頃ですが、機内食がおいしくないなどのデメリットがあります。この選択は人によって異なるのでお財布と相談して決めていきましょう。

ちなみに、アメリカに渡航する場合は、日本発の往路が9時間程度、アメリカ発の復路が10,11時間程度です。

ESTA申請

今回の旅行では完全に忘れてました。。

ESTA申請。アメリカ渡航時にはパスポートの他に渡航のための手続きが必要です。

このESTA申請（ビザ免除プログラム)ですが、米国国土安全保障省（DHS）により2009年1月12日から義務化された制度で短期商用・観光目的（90日以下）の目的で旅行するすべてのビザ免除プログラム渡航者は、米国行きの航空機や船に搭乗する前にオンラインでESTA渡航認証を受けなければなりません。

旅行前にちゃんと地球の歩き方などを読んでいればESTA申請が必要なことがわかるのですが、意外としられていない制度なのでアメリカ渡航の前にしっかり確認しておきたいところです。

ESTAというなんかアルファベットで難しそうな雰囲気をかもしだしていますが、手続きは意外と簡単でこちらのリンクから https://esta.cbp.dhs.gov/esta/application.html?execution=e1s1

案内にしたがって手続きを行えば数分で手続き完了できます。航空券のようにeチケットを空港に持って行くなどの手順は必要なく、オンラインで申請したあとは入国時に審査官がシステムでチェックしてくれるので申請をおこなって審査が完了していれば問題ありません。

審査は旅行出発日の72時間前までに済ませておく必要がありますが、スムーズに行くと一瞬で申請から審査完了までが終わるので、当日空港にわすれていたことに気づいて申請して間に合うこともあるようです。そうは言っても、早めに審査を終えておくことにこしたことはないので、審査に時間がかからない事実を踏まえつつも余裕をもって申請しておきましょう。

モバイルWiFiなど現地通信機器

アメリカ国内では多くの建物にWiFi設備がありますが、WiFiに時間制限があったりして完璧とはいえない感じです。また、アメリカ国内での移動ではUberが使えると便利なので室外でもネットが使えると便利です。

海外用の携帯レンタルサービスなどもありますが、僕は海外でも使い慣れた携帯を使いたいので、モバイルWifi+マイ携帯という組み合わせを採用しています。

Uberのインストール・登録

Uberはアメリカで広く利用されている配車サービスです。Uberのアプリに搭載された地図上で目的地を指定して、自分がいまいる現在地に車を呼んで目的地まで運んでもらうことができます。

これは最初のアメリカ渡航の時に後悔したのですが、Uberのインストールは日本国内にいるうちにやっておきたいです。

Uberのインストール・登録にはSMS（電話番号をつかったメッセージサービス）での認証があるのですが海外にいるときにSMSを受け取れないことがあるので日本国内で先に自分のアカウントを登録できるとよいでしょう。

Uberでは、先に目的地を地図（グーグルマップのような地図）で指定して料金を確認したあとに配車できるので「運転手が道にまよった」「道が渋滞していて、通常より時間が増えて料金が高くなった」などの心配をすることがなくなります。英語で目的地を伝えるのが不安なひとも地図上で目的地を指定できるので心配いりません。

さらには、料金の割り勘機能なども存在するので友達との海外旅行での支払いも楽チンです。

また、一般的にタクシーより料金が安いのもUberを使う魅力の一つです。アメリカを旅行する際にはぜひUberを使いこなして、効率的に移動できるようになりましょう。

Skypeクレジットの準備

海外でのデータ通信はモバイルWifiで問題なしですが、現地で現地の番号に電話かけないといけないということもままあります。

そんなときはSkypeクレジットがおすすめです。Skypeのアプリを携帯にインストールしてクレジットカードを登録しておけばアプリ上にチャージ可能です。

Skypeにクレジットカードで必要な分をチャージをしておけば、あとはそのチャージ分を使って通常の電話をかけることができます。

現地の旅行会社に電話する。カード盗難・紛失時の電話など電話を利用する機会も一定程度あるので旅行前に準備しておきましょう。（チャージなどは現地でもできるので、現地からでも問題ないです。）

充電器・コンセント（アダプタの形は変わらないので心配無用）

海外旅行の際に心配な電源の確保ですが、アメリカのコンセントは日本のコンセントと変わらない形状なので変換用のアダプタなどを改めて購入する必要はありません。

少し注意が必要なのが電圧で日本が100Vなのに対して、アメリカは120Vあるいは200Vです。最近の家電では100-240Vなど幅広い電圧に対応しているので問題になることは少ない（MacBookやiPhoneなども幅広い電圧に対応している）のですが、念のため日本から持って行く家電の対応電圧は確認しておきましょう。

現地通貨（ドル）・クレジットカード

現地通貨はドルですが、アメリカではほとんどの場合でクレジットカードで決済できてしまうので現金としてのドルは少額で問題ありません。滞在期間などによりますが一週間の滞在でも200ドルほどあればだいたい事足りるのではないでしょうか？

アメリカには多額の現金を持ち込む必要はありませんが、クレジットカードを持って行くのは忘れないようにしましょう。

海外旅行保険

海外では、盗難やスリ、交通事故などのトラブルに巻き込まれることもありますので海外旅行保険に加入しておくことをおすすめします。

海外旅行保険に個別で加入するのも良いですが、楽天カードなどですと羽田空港へ向かうまでのシャトルバスの交通費、航空券の費用などでカードを使って決済をしていた場合に保険が適用されます。クレジットカードに付帯する保険の場合、わざわざ保険に申し込まなくても保険が適用される条件さえ満たせば万が一の自体に備えることができるので、海外旅行保険の準備はクレカで行うのがおすすめです。

(番外編）地球の歩き方

これは番外編ですが、地球の歩き方もおすすめです。空港の本屋さんなどでも購入できるので旅のおともに一冊用意しておくとよいでしょう。観光スポットなどの紹介はもちろん旅行に際しての準備や現地の文化、治安など幅広い情報を網羅しています。年ごとの情報も充実していて、ラスベガスの地球の歩き方ではカジノを観光スポットとして紹介するだけではなく、実際の遊び方・ルールなども載っていて道中の移動やホテルなどでさっとよんでおくだけでも非常にためになります。

まとめ

アメリカ投稿前の準備をまとめてみましたがいかがでしたでしょうか？パスポート海外旅行保険、Wifiなどはどの国に旅行する際にも必要な一般的なものですが、Uberなどはアメリカに行くのであれば日本にいる際にインストールしてから渡航したいです。

Skypeクレジットで一般電話の番号に電話をかけられるというのも意外と知られていない情報なので、これを機にチェックできると良いでしょう。

旅行に合わせて仕事の休みもうまく調整して、チケットの手配もしてと準備して迎えた旅行でパスポートを忘れてスケジュールが大幅変更やESTA申請を忘れて入国できなかったなどは避けたいですよね。

こちらに書かれている情報が参考になって楽しい旅行の実現に役立てれば嬉しいです。

では。

Rubyでデザインパターン。Strategyパターン。Design Pattern in Ruby

Sun, 02 Sep 2018 00:00:00 GMT

Ruby でデザインパターン今回は Strategy パターンです。

デザインパターンはオブジェクト指向のエッセンスが詰まったものなので本を読み進めしつつ、ここにまとめてしっかりと理解していきたいです。

アルゴリズムを分離するStrategyパターン

早速Strategy パターンのコードはこちらです。

class Report
  attr_reader :title, :text
  attr_accessor :formatter

  def initialize(formatter)
    @title = 'Monthly Report'
    @text  = ['Things are going', 'really, really well.']
    @formatter = formatter
  end

  def output_report()
    @formatter.output_report(self)
  end
end

class HTMLFormatter
  def output_report(context)
        puts('<html>')
    puts('  <head>')
    puts("    <title>#{context.title}</title>")
    puts('  </head>')
    puts('  <body>')
    context.text.each do |line|
      puts("    <p>#{line}</p>")
    end
    puts('  </body>')
    puts('</html>')
  end
end

class TextFormatter
  def output_report(context)
    puts("****** #{context.title} ******")
    context.text.each do |line|
      puts(line)
    end
  end
end

いきなりポンと見せられてもわからないので個別に切り出して説明していきます。

アルゴリズムをサブクラスに委譲

こちらの記事でTemplateMethod パターンを紹介しましたが、

Ruby でデザインパターン。Template Method パターン。Design Pattern in Ruby

TemplateMethod パターンでは、名前の通りスーパークラスのテンプレートメソッドでどういう処理をどういった順序で行うというのを規定して、個別の処理はサブクラスでメソッドをオーバーライドして利用するというものでした。

この TemplateMethod パターンは処理の順序などのロジックを親クラスにもっているので、肝心の処理の順序が変更されてしまうと親クラス、子クラス全てのモジュールに影響を与えてしまいます。

そういった問題点を解決しているのがStrategy パターンで Strategy パターンでは実際のロジックをストラテジーのクラスに委譲してしまいます。

class Report
  attr_reader :title, :text
  attr_accessor :formatter

  def initialize(formatter)
    @title = 'Monthly Report'
    @text  = ['Things are going', 'really, really well.']
    @formatter = formatter
  end

  def output_report()
    @formatter.output_report(self)
  end
end

TemplateMethod パターンではこの output_report に title を出力するメソッド、body を出力するメソッドなど必要な処理を手続き的に書いていましたが、Strategy パターンではこれらのロジックを全て formatter として与えられたインスタンスの output_report に委譲します。

Strategy パターンでは、実際のロジックを全てストラテジークラスに委譲しているので動的に実行するロジックを切り替えるということも可能です。

report = Report.new(HTMLFormatter.new)
report.output_report

report.formatter = TextFormatter.new
report.output_report

また Strategy パターンではロジックとデータを分離していて、Report クラスの例でいうと title や text などのデータは親クラス（Context クラスといったりします）が保持し、実際のロジックを実行する部分で自分自身をデータとして渡します。

対象のコードは下記の部分で

 def output_report()
    @formatter.output_report(self)
 end

@formatter に注入されたクラスのメソッドに対して self で自分自身を引き渡しています。さらに storategy 側では受け取っとた context からデータを取得し、実際のレポート主力時に出力を行なっています。

class TextFormatter
  def output_report(context)
    puts("****** #{context.title} ******")
    context.text.each do |line|
      puts(line)
    end
  end
end

Rubyの特徴を生かしたlambdaでお手軽Strategyパターン

ここまでですと一般的な Strategy パターンとあまり代わりありませんが、 Design Patterns in Ruby (Adobe Reader) (Addison-Wesley Professional Ruby Series) では、Ruby の Proc オブジェクトを使った簡単な Strategy パターンの実装も紹介してありました。

本では Quick-and-Dirty Strategies と書かれていましたが、Javascript などでも似たような考え方ができて覚えておいて損しない考え方かなと思いました。

Ruby では lambda という記法を使うことでブロックをオブジェクト化して変数につめて使うことができます。下がその例ですが、

sayHello = lambda { puts 'hoge' } sayHello.call
hoge
 => nil

lamda を使うと Proc オブジェクトが生成され格納したブロックを実行する場合は、 call を利用します。

これを使って Strategy パターンを組む場合は、さきほどの Report クラスを以下のようにします。

class Report
  def initialize(&formatter)
    @title = 'Monthly Report'
    @text = ['Things are going', 'really, really well.']
    @formatter = formatter
  end

  def output_report
    @formatter.call(self)
  end
end

あとは次のように lamda で strategy を実装して渡してあげれば簡易 strategy パターンのできあがりです。

HTML_FORMATTER = lambd do |context|
  # HTMLFormatter#output_reportの処理を書く
end

report = Report.new(HTML_FORMATTER)
report.output_report

この書き方だとクラスを使わないのでかなり簡潔にかけそうですが、まああまり多用は避けたいですね。

まとめ

今回は Strategy パターンを紹介しましたが、Strategy パターンは委譲をベースとしたデザインパターンで Template Method パターンよりは、親クラスへの依存度を下げた形で実装を行うことができます。

こうやって書くと Strategy パターンの方が優れているような書き方になってしまっていますが、それぞれのパターンには向き不向きあるのでそれぞれの良いところと悪いところをわかった上で使い分けできるとよさそうですね。

また、Ruby の lambda を使った書き方も紹介しましたがこういう選択肢もあるよという感じで覚えておくとどこかで役にたつかもしれないですね。

では。

Rubyでデザインパターン。Template Methodパターン。Design Pattern in Ruby

Fri, 31 Aug 2018 00:00:00 GMT

Rubyでのデザインパターン

デザインパターンといえば、こちらの本

増補改訂版 Java 言語で学ぶデザインパターン入門

が有名で大変ためになる本ですが、これらのデザインパターンを ruby で書こうとするとどうなるのかというのでこちら購入して読んでみました。

Design Patterns in Ruby (Addison-Wesley Professional Ruby Series) (英語)

はい、英語です。日本語版もあるのですが、6000 円ほどで結構高かったり英語の技術書を読破するという今年の目標もあったので、こちらを選びました。

TemplateMethodパターン

早速デザインパターンの紹介にうつります。第一回目は TemplateMethod パターンです。

class Report
  def initialize
    @title = 'Monthly Report'
    @text = ['THings are going', 'really, really well']
  end

  def output_report
    output_start
    output_head
    output_body_start
    output_body
    output_body_end
    oputput_end
  end

  def output_body
    @text.each do |line|
      output_line(line)
    end
  end

  def output_start
  end

  def output_head
    output_line(@title)
  end

  def output_line(line)
    raise  'Called abstract method: output_line'
  end

  def output_body_end
  end

  def output_end
  end
end

先にコードをのせてしまいましたが、Template Method パターンではこのような抽象クラスを定義して、この Report クラスのようなクラスを継承した具象クラスでメソッドをオーバーライドして実装していきます。

このデザインパターンのミソはこのコードでいうとouput_reportメソッドになります。このメソッド内で実行する処理の順番などを定義して、そこに定義された分割されたメソッドの実際の挙動はサブクラスで定義していくというような実装になります。

サブクラスでは、サブクラスでそのサブクラス特有の処理だけ実装すればよくなる(output_report のようなメソッドは共通処理なので抽象クラスに実装しておくだけですむ)ので、全体としてコードの重複をさけて記述量を減らすことができます。

Template Methodで適用する例

先ほど紹介したデザインパターンの例を引用しますが、ある日月次のレポートとして HTML でのレポートを作成する必要がありそれを実装することになった場合を考えます。

class Report
  def initialize
   title = 'Monthly Report'
   @text = [ 'Things are going', 'really, really well.' ]
  end

  def output_report
    puts('<html>')
    puts('  <heade>')
    puts('    <title>#{@title}</title>')
    puts('  </head>')
    puts('  <body>')
    @text.eah do |line|
      puts('    <p>#{line}</p>')
    end
    puts('   </body>')
    puts('</html>')
  end

end

HTML を出力するだけなので、このよな実装をしたとします。しかし、後からテキスト形式でも出してほしいといったときにこまってしまいます。

ここで付け焼き刃的な実装をするとこんな感じになってしまいます。

class Report
  def initialize
    @title = 'Monthly Report'
    @text = ['Things are going', 'really, really well']
  end

  def output_report(format)
    if format == :plain
      puts('*** #{@title{} ***')
    elsif format == :html
      puts('<html>')
      puts('  <heade>')
      puts('    <title>#{@title}</title>')
      puts('  </head>')
      puts('  <body>')
    else
      raise "Unknown format: #{format}"
    end

    @text.eah do |line|
    if format == :plain
        puts('    <p>#{line}</p>')
      else
        puts('    <p>#{line}</p>')
      end
    end
    puts('   </body>')
    puts('</html>')
  end
end

うーん、動きはしそうですが、if 文が多くてなかなか読みづらいですね。しかも、こんどは別の csv 形式で出力してほしいとなった場合にまた if 文が増えて辛くなりそうな気しかしないです。

こういうときに Template Method パターンで実装をすると、一番最初に紹介した Report クラスを継承する形で HTMLReport クラスと TextReport クラスを実装するとだいぶ楽になります。

HTMLReport.rb

class HTMLReport < Report
  def output_start
    puts('<html>')
  end

  def output_head
    puts('  <head>')
    puts("    <title>#{@title}</title>")
    puts('  </head>')
  end

  def output_body_start
    puts('<body>')
  end

  def output_line(line)
    puts("  <p>#{line}</p>")
  end

  def output_body_end
    puts('</body>')
  end

  def output_end
    puts('</html>')
  end
end

TextReport

class TextReport < Report

  def output_head
    puts("*** #{@title} ***")
    puts
  end

  def output_line(line)
    puts(line)
  end

end

このようにそれぞれの出力フォーマットを Report クラスのサブクラスとして切り出すことによってすっきりとしたコードになりました。

これらのクラスを使う場合は、出力したいフォーマットにあわせて

# HTML出力する場合
HTMLReport.new.output_report

# Text出力する場合
TextReport.new.output_report

まとめ

ここまでで、TemplateMethod パターンの紹介は以上です。デザインパターンはなかなか覚えるのに時間かかかるのですが、実装前の段階でデザインパターンを知っているか知らないかで実装の簡潔さや変更の容易さがかわってきて知っていると本当に便利です。

最初にもちょっと触れましたが、TemplateMethod パターンの肝は抽象クラスのそれぞれのメソッドを呼び出す親メソッド（Report クラスの output_report メソッド）とサブクラスでの実装を強制するメソッド です。

親メソッドというかテンプレートメソッドがどういう順番で個別のメソッドを呼び出すかというのを定義して、それに合わせてサブクラスでメソッドをオーバライドしていくので当然このテンプレートメソッドがクラス設計の重要な部分になってきます。設計時にはどういうパターンが今後の変更などを加味してどういうメソッドにするのかというのを決めていきましょう。

また、Report クラスでは output_line ではメソッド内で例外をなげるように実装することで子クラスでオーバーライドされない場合にはエラーで処理を止めるように実装しています。一方その他のメソッドはデフォルトで返却する値（もしくは何もしない）を決めているのでサブクラスで固有の処理がない場合はそのまま Report クラスのメソッドを実行するようにして、コードの重複を減らしています。

この大きくわけて二つのテンプレートメソッドと、オーバライド必須のメソッドを覚えておけばわりとするっと実装できるのが TemplateMethod パターンです。

ぜひ実務や個人開発でも TemplateMethod パターンが適用できないかどうか考えて実装してきれいなコード書いていきましょう。

ReactのComponent, PureComponent, SFCComponentのレンダリングの挙動の違いをまとめてみる。

Thu, 23 Aug 2018 00:00:00 GMT

「Componentはどういう時に再レンダリングされるんですか？」

Reactで開発している方はもちろん、「propsやstateが変更された時だよ！」と自信をもって答えられるかもしれません。

が、

「ネストした時はどうなるんですか？」

「PureComponentやSFCとかってレンダリングの挙動が変わるんですか？どう変わるんですか？」

みたいなところにちゃんと答えられる自信がなかったのでそれぞれのコンポーネントの違いをまとめてみました。

各コンポーネントの違い

Component

class HelloComopnent extends Component {
  render() {
   return <div><h1>Hello World</h1></div>
}

言わずと知れたReactのComponentクラスです。

チュートリアルでも使っているように特に意識しなければ、このクラスを継承する形でコンポーネントを定義します。

Component classにはライフサイクルメソッドなるものが実装されており、コンポーネントのマウント時から、アンマウント時、propsが変化した場合などにフックを仕込むことができます。

he Component Lifecycle

PureComponent

class HelloComopnent extends PureComponent {
  render() {
   return <div><h1>Hello World</h1></div>
}

Reactのv15.3から追加されたコンポーネントで基本的な部分はComponentと変わらずライフサイクルメソッドが使えます。

Componentとの大きな違いは、デフォルトでshouldComponentUpdateが実装されている所です。

shouldComponentUpdateはライフサイクルメソッドの一つでReactコンポーネントを再レンダリングするかどうかをtrue/falseで返すことで再レンダリングを制御できます。(trueを返した場合だけ再レンダリングされます。)

繰り返しにはなりますがPureComponentはshouldComponentUpdateがデフォルトで実装されているので自身のコンポーネントのpropsに変更がなければ再レンダリングが走らないようになっています。

SFC(Stateless Functional Component)

const HelloComopnent = (props) => {
   return <div><h1>Hello World</h1></div>
}

SFCはステートレスの名前の通り、内部に状態を持ちません。

関数としてのコンポーネントなので、同じpropsからはつねに同じdomがレンダーされることが保証されています。

表示に特化したPlesentationalなコンポーネントとして用いられいることが多く、ライフサイクルメソッドが使えません(渡されたpropsを表示するだけとなので必要ないと言えばそうなのですが)

デモでそれぞれの違いを確認

説明のためにデモを作ってみました。

デモ

実際にデモを見てもらうとわかるのですが、親のコンポーネントがあってそのなかにそれぞれ並列でComponent,PureComponent,SFCが存在するような構造になります。

ソースはこちらです。 version-1/react-rendering-sample

紫のボタンがcounterをインクリメントしてくれるボタンで、それぞれの色のボタンがそれぞれのflgをトグルしてくれるボタンです。

stateは全て親コンポーネントをラップするAppComponentが保持しています。

紫のボタンをクリックするとタブがcounterがインクリメントされます。その他の色のボタンを押すと対応したコンポーネント内に表示されているflgの値が切り替わります。

また、それぞれのコンポーネントのrenderメソッド内にconsole.logを仕込んであるのでコンポーネントが再レンダリングされるタイミングでコンソールにログが表示されるようになっています。（以下で色々と説明していきますが、実際にデベロッパーツール開いて自分で試した方がわかりやすいです。）

これらを前提に実際のコンポーネントの挙動を見ていきます。

親コンポーネントから渡されたpropsが変化した場合

先ほども説明したように、紫のボタンを押すとcounterの値がインクリメントされるので親コンポーネントのpropsが変化し、再レンダリングされます。続いてそのpropsが渡されている子のコンポーネントも連鎖して再レンダリングが走ります。

親コンポーネントから渡されていないpropsが変化した場合

親コンポーネントからpropsが渡されていない（自身のpropsが変化しない）ケースを試したいので、それぞれのボタンを押下して各コンポーネントがレンダリングされるかどうかを調べます。

結果は次の表の通りになり、

	緑ボタン押下	黄ボタン押下	赤ボタン押下
Component（緑）	レンダリングされる	レンダリングされる	レンダリングされる
Pure Component（黄）	レンダリングされない	レンダリングされる	レンダリングされる
SFC（赤）	レンダリングされる	レンダリングされる	レンダリングされる

PureComponent以外は親の状態（props) が変化すると自身の状態が変化していないのにもかかわらず再レンダリングされてしまうことがわかります。

無駄なレンダリングを避けるためのPureComponent

実際にデモを動かしてみて、無駄なレンダリング（自身の状態が変わっていないのに再描画すること）によるオーバヘットを防ぐにはPureComponentを極力使っていった方が良いということがわかりました。

もちろん、ComponentでもshouldComponentUpdateを愚直に実装すれば同じことができるのですが、まあPureComponentで良いですよね。またSFCの場合は、recomposeなどのライブラリを使えばPureComponentチックなSFCもかけるみたいです。

「現状そんなに複雑で大きいコンポーネントってないから別にPureComponentじゃなくても」というのもあるかと思うのですが、個人的な意見としてシステムは寿命が長くなるほど大きく複雑に変化しておくのでいまのうちから少しずつPureComponentで実装しておくと後が楽なのかなと思っています。

PureComponentを使わない方が良い場合

どうやら、shouldComponentUpdateの計算コストも少なくないらしく、頻繁にpropsが変化するようなコンポーネントでは、毎回レンダリングするかどうかの計算を行わないといけないのでそういったコンポーネントにはComponentを使って無条件に再レンダリングさせるのが良いようです。

PureComopnent最高！という感じで全てのコンポーネントを置き換えると逆に遅くなったというのもありますので一応ここは念頭においておく必要があるのではないでしょうか？

まとめ

PureComponentはデフォルトでshoulComponentUpdateが実装されており、自身のpropsが変化していなければ再レンダリングしないという判断を自動でしてくれる。
親が再レンダリングされるとComponentもSFCも再レンダリングされ自身のpropsが変わっていないのにレンダリングされるという無駄が生じる。
PureComponentは頻繁に自身のpropsが書き換わるようなコンポーネントでは使わない方がよい

このように3つまとめてみましたが、今回の観点で比べるとPureComponentが特徴的な動作をするのでこのようなPureComponentが主役のまとめになりました。

レンダリングの挙動が言葉で説明されてもいまいちピンとこなかったのでデモを作って公開してみました。実際にさわってみると自分でも結構わかりやすいなと感じたのでぜひ触ってみてください。

Android React Nativationでキーボードと一緒にタブバーも上がってしまう問題の対策

Tue, 21 Aug 2018 00:00:00 GMT

ReactNativeで開発をする際ルーティングの為にReactNavigationを使っている方が多いかと思うのですが、

そのReactNavigationのタブバーを何も気にせず使っているとキーボードが出てきたときに（Android限定）タブバーも一緒に押し上げて残念な感じになってしまうというのがあったので、その解決方法を記しておきます。

KeyBoardのイベントを検知して、TabBarを非表示にする。

解決策としては、KeyBoardが表示されると同時にタブバーを非表示にしてやるだけです。

ただ、TabBarを直接非表示にしたりするAPIは提供されていないので、自前でTabBarをラップした形のコンポーネントを実装してその中で表示・非表示を切り替えます。

以下がWrapperComponentです。

import React from 'react'
import { Keyboard } from 'react-native'
import { TabBarBottom } from 'react-navigation'

class TabBarComponent extends React.PureComponent {

  constructor(props) {
    super(props)

     this.state = {
      isVisible: true
    }
    this.keyboardWillShow = this.keyboardWillShow.bind(this)
    this.keyboardWillHide = this.keyboardWillHide.bind(this)
  }

  componentWillMount() {
    this.keyboardEventLisetners = [
    Keyboard.addListener('keyboardDidShow', this.keyboardWillShow)
 Keyboard.addListener('keyboardDidHide', this.keyboardWillHide)
 ]
  }

  componentWillUnmount() {
    this.keyboardEventLisetners.forEach( listener => listener.remove())
  }

  keyboardWillShow = () => {
    this.setState({
      isVisible: false
    })
  }

  keyboardWillHide = () => {
    this.setState({
      isVisible: true
    })
  }

  render() {
    if( !this.state.isVisible ) {
      return
    }
    return
  }
}

export default TabBarComponent

これができたら、TabNavigatorの第二引数で自前のラッパーコンポーネントを指定して完了です。

import TabBarComponent from './TabBarComponent.js'

export default TabNavigator({
...
}, {
    initialRouteName: '...',
    tabBarComponent: TabBarComponent,
  })

iosではキーボードがタブバーを押し上げるという感じにはならないので、イベントの登録をAndroid限定にしてあげるとより硬い実装にはなるかと思いますが、そちらはお好みでという感じです。

まとめ

React Nativeはまだまだ発展途上で想定外の動きをしたりOSごとの動作の違いがあったりしてなかなかつらみがありますが、プロジェクトとして動的でなかなか面白いですね。

この記事の問題をネットで調べてみるとAndroidのmanifest.xmlを書き換えれば動くよみたいななのがあったのですが、タブバーのためにアプリ全体の設定を書き換えるのはいかがなものかということでこちらの対策をアップしました。

では。

TDDとかBDDとかあるけど、個人的に感じているテストコードを書く7つの理由

Mon, 16 Jul 2018 00:00:00 GMT

テストコードといえば、テストコードが必要か必要でないかというのはちょいちょい議論になるものではありますが、個人的には正しい開発を行う上では必ず必要になってくるものだと思っています。

唐突に自分の意見を書いてみましたが、

「じゃあなんで、テストコードを書くの？？？」

と聞かれるといくつかのメリットをあげることはできると思いますが、テストコードのない現場の忙しい開発者たちを相手にテストコード導入のメリットをあげて説得できるかというところにあまり自信が持てなかったのでテストコードを書くメリットを自分なりに整理してみました。

当たり前だけどプログラムがちゃんと動いているかを効率的にチェックできる

これは、まあ当たり前というかこれが達成されていなかったらテストコードのある意味がないですよね。

ただ現在のシステムで、作った後に手を加えないシステムというのはほぼないわけで、日々訪れる仕様変更や機能改善のためになんどもコードが書き換えられていきます。また、コードというのは保守期間やシステムの年齢に対して増大して行く傾向にあるので、最初は少人数でも品質を担保できていたコードがどんどん大きく複雑になり管理が難しくなってきます。

そんななかで、GUIベースでの統合的なテストとはいわずともモジュールレベルで仕様通り動作しているかどうかをきっちり担保できていると日々の開発を進める上で大変心強いです。

サーバーから意図しないレスポンスが返ってくるのでみてみたところ、既存のバグでそれの調査と修正で予定した多くの工数をとられて、当初の見積もりをオーバーするとかいうのって本当にイライラしますよね。既存のコードが正しく動いていること（完璧にというのはなかな難しいですが）を担保できていない中での開発というのは非常にストレスがたまりますよね。

日々の開発を行なっている上で既存のバグが三つも四つも見つかるような現場ではテストコードの導入をオススメします。

デプロイ作業が自動化できる

これはシステムの品質というより作業工数の効率化観点ですが、テストコードである程度のカバレッジがないと自動デプロイって怖くてできないですよ。

静的型付けの言語とかであればよいですが、rubyやphpなど実際に動かしてみるまで構文エラーとかをすくえない言語では、本番でundefinedエラーなどのしょうもないエラーが起きてしまうのは嫌ですよね。テストコードで8割程度のカバレッジをもっておけば、デプロイの前に自動でテストが回るようにしてテストを通過した場合だけデプロイするという形でしょうもないエラーの多くを防ぐことができます。

テストがない状態でもデプロイの自動化はできますが、ちょっと怖くてできないですよね。。テストコードのないプロジェクトはこのように開発の運用にも影響を与えるので、きっちりテストを書く習慣をつけておきたいです。

バージョンアップが楽になる

テストコードがあるとバージョンアップが楽になります。バージョンアップする前には前バージョンとの変更点を確認して、修正してという流れになると思いますが、漏れとか怖いのでひとつずつ確認していきますよね。

そんな時にテストコードがあると完璧とはいかないまでも、人の打鍵では確認しづらい細かい部分までコードがバージョンアップの影響を受けていないか確認することができます。

まだ生まれたばかりのライブラリとかを使っていると結構バージョンアップの頻度が高く追従するのが難しかったりしますよね。かといって、古くなってしまったシステムをメンテナンスするのも嫌ですし、、、

テストコードを日頃から書いておくとバージョンアップする際には必ずテストコードのありがたみを感じることができるので、必ず報われることを信じながらテストコードを書いていきましょう。

エンジニアとして一定の評価をされる

フリーランスの面接でも割ともともとの現場のカバレッジを聞かれたりしたのですが、外からのみられ方としてテストコードがかける人なのか、テストコードを書く意義をわかっているかどうかというのはみられているように思います。

知り合いのフリーランスの方でも現場に入る前にそのプロジェクトのコードカバレッジがどれくらいか聞くそうです。テストコードのない現場だと、こっち直したらあっちが壊れてとかいうなかなか辛い状態での開発になるのでそういうのを警戒してあらかじめ開発環境が整っている環境かどうかというのは働く先での評価の基準になるようです。

転職の面接の際にも前職ではCIを導入していて、マスタマージと共に自動デプロイが走っていましたとかいうと「ちゃんとした現場で開発してきているな」という評価にはなると思います。

「テストコード０の現場からカバレッジを8割にしてCI環境を整備しました！」というほどでなくても、一エンジニアとしてテストコードをかける、書いた経験があるというのは非常に大事なことのように思います。

コードがきれいになる

テストコードを書いてみるとわかるのですが、コードにはテストの書きやすいコードと書きにくいコードが存在します。当然テストコードを書きやすいコードの方が好ましいわけですが、テストコードの書きにくいコードというのはだいたい一つのクラスやメソッド多くのことをやりすぎているコードです。

一つのメソッドであまりに多くのことをやろうとすると、人間の理解力を超越してコードを読むのが難しくなりますし、他のクラスへの依存も高まったり、重複の多いコードになりがちです。

これを防ぐために、テストの書きやすいコードを意識しながらコードを書くことができると単一責務を守った綺麗なコードができあがります。

テストの書きやすいコードというのが、自分でテストコードを書いていないと感覚がわかりづらいので、普段テストコードの書いていない人は今すぐにでもテストコードを書く習慣をつけられると良いと思います。

リファクタしやすくなり、コードの質を保つ好循環が生まれる

テストコードがあることによって既存のコードに手を入れてもテストコードがしっかり書いてあれば、自分では気づけない部分でテストがこけてくれて「あ、こっちも直さないといけないのか」となるので、リファクタ作業をするときも安心して作業をすすめることができます。

システム開発を進めているとどうしても納期に追われたりしてコードが汚くなっていきがちなのですが、テストコードがあるとリファクタへの心理的ハードルが下がるので、機能改修のついでのファクタなどができるようになってきて自然とシステム全体でのコードの質が保たれます。

ひとつずつテストコードを書いて行くの決して簡単な作業ではありませんが、ある程度カバレッジがあがってると上記のような好循環が作れるので、ぜひともテストコードの導入をオススメします。

自分の書いたコードを見直す時間が作れる

これは最近感じたのですが、テストコードを書く時というのは、プロダクトのコードをみながらコードを書いて行くので、自分の書いたコードをレビューしているよう状態になります。

自分で書いたコードって時間を置いてみると

「なんで、こんな酷いコードかいているんだろう？？」

と思うことありますよね。普段自分で仕事をしていて自分のコードを見直すことって意外となくて3ヶ月後とか半年後に同じ箇所に戻ってきて過去の自分の書いたコードで自己嫌悪に陥ったりするのですが、テストコードを書くことによってこれが短いスパンでできるようになります。

短いスパンで自分の過ちに気付けるので、次からコードを書く時にそこを気にしながら書くことができます。

これは自分がまだ未熟だからかもしれないのですが、コードって一発できれいなコードをかけるということが少なくて、一つの機能改善の中でも一度書いたものに納得がいかず再度書き直すなんてこともよくあります。

個人的には最初に書いたコードってどこか無駄があるので、それをまた書き直していくことでシンプルで無駄のないコードができあがると思っているので、書き直せば書き直すほど無駄のない筋肉質なシステムができあがるとも思っています。

なので、ひとつの開発の中で、

一旦動く形でコードを書いてみる
無駄な部分をリファクタする
テストコードを書きながら再度コードの見直し
納品物としてテストコードときれいに整頓されたシンプルなコードができる

みたいな順序を踏めると良いのではないでしょうか？（できる人は、1,2をまとめて一回でできてしまうのかもしれません。。というかテスト書きながらしっかり開発しているので全部一気にできるんですかね？？）

まとめ

以上私の考えるテストコードを書くメリットのまとめでした。

当たり前かもしれないが、コードの挙動を効率的に確認することができる
デプロイ作業が自動化できる
バージョンアップが楽になる
エンジニアとして評価される
コードが綺麗になる
リファクタしやすくなり、コードの質を保つ好循環が生まれる
自分のかいたコードを見直す時間がつくれる

まとめてみると、テストコードは現場的にデプロイの自動化で工数の削減ができたり、コードの質を担保できたりというチームよりなメリットもありますが、きれいなコードをかけるようになるとか自分の書いたコードを見直す時間が作れる、エンジニアとして評価されるなど個人的なメリットもあります。

テストコードに関しては、TDDだったら〜とかBDDだったら〜とか色々あるのかもしれませんが現時点個人的に感じているテストコードのメリットをまとめてみました。

OmniAuthで認証後のコールバックにパラメータを渡す方法

Sun, 01 Jul 2018 00:00:00 GMT

FacebookログインやGoogleログインを実装する際によくお世話になるOmniauthですが、Webサービスに採用していると、認証完了後にある特定の処理をしたいということがまあまああります。

そんな時は、認証前のURLに任意のパラメータを渡して、コールバックでそのパラメータを元に処理をわけたいということがありますよね。これができない場合は、sessionに値を保持してやったりするのですが、sessionを乱用すると、一見意味のわからないキーが乱立するので、極力Oauth認証後の処理であればこういった仕組みを利用していきたいです。

調べてみたところ,omniauthに任意の値を渡すことが可能のようで、認証先（例えばgoogle）に飛ばす際のURLにパラメータを付与すると認証後にそのパラメータを取得できるようです。

= link_to 'Link' , user_oauth2_omniauth_authorize_path({flg: 1})

として飛ばすと、

def callback
　　params = request.env['omniauth.params']
　　if params['flg'].present?
　　　　// フラグのある時の処理
　　else
　　　　// フラグのない時の処理
　　end
end

というように処理をわけることができます。

決済の処理など外部に一度リクエストを飛ばして、リダイレクトしてもらう場合にもレスポンスに任意の値が設定できるのでomniauthも似た感じですね。

細かいですが、こういうことを知っておけると無駄な処理を書かなくてすむのでメモしておきます。

Reactでスネークゲームを作ってみた-解説編環境構築-

Fri, 29 Jun 2018 00:00:00 GMT

インストール

ひとまず Reactの環境をつくっていきます。

reactの環境構築は手間を省いて、create react appで1コマンドで仕上げます。 (cliをグローバルにインストールする必要があるので2コマンドかも)

コマンドのインストール

npm install -g create-react-app

アプリの雛形作成

create-react-app snake-game

オブジェクトの操作などで便利なのでついでに、lodashも入れておきます。

yarn add lodash

これで環境構築は終了です。

ディレクトリ構成

最終的なディレクトリ構成は以下のようになります。

ディレクトリ構成

|--public
|  |--assets
|--src
|  |--components
|  |--styles

cssはsassで書いています。最近ピュアcssに耐えられない体になってきているのでさらっと入れちゃっています。

※cssの解説はあまり詳しく説明しないので、面倒な方はmasterのcssをダウンロードしてつかったり、コピペすると良いと思います。sassをそのまま使いたい方はnode-sassを入れましょう。

yarn add node-sass

github pagesについて

今回デモを公開していますが、github pagesというパッケージを入れるとgithub上での公開がかなり簡単になります。ちょっとしたReactアプリのデモをWebで動かしたいとかだとかなり便利です。

まとめ

今回は環境構築だけなのであまり面白くありませんがら次回から実際にコードの解説をしていきます。

Reactでスネークゲーム作ってみた。

Wed, 27 Jun 2018 00:00:00 GMT

ある日youtubeで面白い動画を探してたら、こんな動画に出会いました。

https://m.youtube.com/watch?v=AaGK-fj-BAM

動画自体はp5.jsというフレームワークを使って15分以内でスネークゲームを作ってみるというものです。

本当に15分で作れるの？？とか思って見ていると案の定ラスト５分とかで、スネークが逆走した時にちっちゃくなっちゃったりして、バグ見つけてわちゃわちゃしています。

その様が締め切り前にバグとか、考慮漏れが見つかってドタバタする僕含めて多くのエンジニアの境遇に似てるなぁと思いながら楽しく見ていました。

スネークゲーム作りました

とまあ、話を元に戻しますが、自分でスネークゲームを作ってみるのも面白いかもしれないと思い実際にスネークゲームを作ってみました。

実装に要したのは20時間くらいですかね？あるいはもうちょっとかかったかもしれませんが、ゲームとして動くには10時間くらいで、スマホでも使えるようにレスポンシブにしたり、デバッグしたりでプラス10時間くらいで作りました。

自分で遊んでみても結構面白いので、我ながら良くできたなぁなんて思ってます。 (まぁ、元のゲームのアイデアが面白いからかとは思います、、、)

スネークゲームのルール

スネークゲームを知らない人もいるかと思うので、ざっくりルールを説明すると

登場人物

へび(スネーク)
えさ(フード)

ルール

へびはえさを食べると成長して長くなる。
長くなった自分に衝突したらゲームオーバー
ゲームオーバーにならず、どこまで長さを伸ばせるか。

ルールはシンプルでいかに自分にぶつからずに、自分を成長させていけるかというゲームです。簡単ですね。

ざっくり作り方を説明

詳細な解説は、気が向いたらやろうと思うのですが、大まかに作りを説明すると

フィールドは固定幅と高さのdiv要素を並べて表現。
へび、えさ、フィールド(一つのdiv)にhtmlのclassを割り当て
Reactで一定の間隔ごとにレンダリングを行いへびが動いているように見せる。
へびの移動は、divの隣の要素をへびの色に変化させた後にへびの長さの分だけへびのdiv要素を残し他を元のフィールドclassに戻して表現する。

という感じですかね。この説明でわかる人と分からない人がいるとは思うのですが、今回はこれくらいの粗さの説明にしておきます。

ソースコードは、ここに置いてありますので気になる方はコード見てもらったり、スターを押して頂けると嬉しいです。

https://github.com/version-1/react-snake-game

まとめ | 新しい技術を勉強するには暇つぶしにでも何か作ってみると身につく

以前に読んだSOFT SKILLS　ソフトウェア開発者の人生マニュアルという本では、基礎を一通り学んだらその技術を使って一通り遊んでみるという時間を作ると新しい技術を習得する効率がよくなるというようなことが書いてありました。

それに習ってというか、単純に理解することとできることというのは違うものなので新しく学んでみたことは実践するのが一番記憶にものこるし、そのあと役に立ちやすいです。実際にやってみて「あれ、こういう場合どうするんだ？」とあらたな疑問が湧く場合もあるので、実践の過程でさらに理解が深まります。

Reactもチュートリアルがあってそれをやるだけでも基礎の理解はできますが、全く指示がないままなにか作れと言われるとなかなかできないですよね。ただ、レールが敷かれていないなかで自分で試行錯誤しながらプログラムを書いていくというのが一番力がつくのでぜひともチャレンジしたいところです。（力が足りなすぎて、迷子になる場合もありますが、、そういう時は期間をおいて再チャレンジしてみたり最初のハードルを下げてみたりしてみると良いです。）

今回は本当に作りましたという報告だけで、コード0ですが、暇つぶしに作ったゲームが割と面白かったので自慢してみました。

今はちょっと解説書こうかなという気になってますが、どうなるかはわかりません。

では。

Railsの便利メソッドをlodashでやると

Mon, 11 Jun 2018 00:00:00 GMT

日常的にRailsでサーバ側を書いていても、ふとした時にjs書かないといけない時ってありますよね。そのほかにも、これまでサーバ側でRuby書いてきたけど、せっかくだからフロント側も勉強したいなみたいな形で Jsを触り始めることもあるかと思います。

jsもES6以降で便利なメソッドも増えたみたいですが、仕事で使ってみるとついついlodashとかライブラリを使いたくなってしまいます。そんなこんなで、Railsのメソッドをlodashでやるには？みたいなところをまとめてみました。

slice

railsのsliceはハッシュから必要なキーだけを取得して返却してくれます。これがActiveRecordのオブジェクトにも使えたりして便利なので、Jsでも同じことがやりたい！！となると思います。

rails

fruit = { apple: 'red', banana: 'yellow', cucumuber: 'green'}
fruit.slice(:apple, :banana)
#  {:apple=>"red", :banana=>"yellow"}

lodash

const fruit = { apple: 'red', banana: 'yellow', cucumuber: 'green'}
_.pick(fruit, ['apple', 'banana'])
// { apple: 'red', banana: 'yellow' }

except

exceptはsliceの逆で、ハッシュのキーから不要なものを取り除いてくれます。

rails

fruit = { apple: 'red', banana: 'yellow', cucumuber: 'green'}
fruit.except(:apple, :banana)
# {:cucumuber=>"green"}

lodash

const fruit = { apple: 'red', banana: 'yellow', cucumuber: 'green'}
_.omit(fruit, ['apple', 'banana'])
// { cucumuber: 'green' }

Pluck

pluckは配列のハッシュから、指定したキーの配列で返却してくれます。lodashでは、0.4以降pluckは廃止されmapで代用できるようです。

rails

array = [
 { id: 1, name: 'John', age: 19 },
 { id: 2, name: 'Mary', age: 30 },
 { id: 3, name: 'Smith', age: 25 }
]
array.pluck(:name)
# ["John", "Mary", "Smith"]

lodash

array = [
 { id: 1, name: 'John', age: 19 },
 { id: 2, name: 'Mary', age: 30 },
 { id: 3, name: 'Smith', age: 25 }
]

array.pluck(:name)
_.map(array, 'name')
// ["John", "Mary", "Smith"]

配列の引き算（差集合）

これはRails(Active Support) というよりはRubyですが、

Ruby(Rails)

 [1, 2, 3] - [1, 3]
# [2]

loadash

_.diffrence([1,2,3], [1,3])
// [2]

Compact

compactはnilであるハッシュのキーを取り除いたハッシュを返却します。微妙にい意味合いは違いますが、lodashでもfalseyなkeyをオブジェクトから取り除いてくれます。

Rails(Ruby)

fruit = { apple: 'red', banana: nil, cucumuber: 'green'}
fruit.compact
# {:apple=>"red", :cucumuber=>"green"}

lodash

fruit = { apple: 'red', banana: null, cucumuber: 'green'}
_.omitBy(fruit, _.isNull)
// { apple: 'red', cucumuber: 'green' }

ほかにもありそうですが一旦ここまでで

ちょっとほかにもありそうですが、今思いつくのはここまでですので、一旦ここで区切らせて頂きます。今思いましたが、ほかにもtapなどなどjsで再現したい関数というのはいくつかあるので続編もできれば書きたいと思っています。

では、今回は一旦ここまでで

Dockerで使い捨てできるMysqlコンテナを構築

Mon, 30 Apr 2018 00:00:00 GMT

自分のローカル環境で、複数のMySQL使わないといけない時ってありますよね？

仕事ではちょっと古めのバージョンを使ってるけど、プライベートの開発では最新の使いたいなどなど

そんな時はDockerを使って使い捨てのMy SQL環境を構築しましょう。

Dockerを使えば、起動時に必要なデータベース、ユーザーを作成してくれるので一度環境さえ作ってしまえば、使い捨てのデータベースを作成したり、捨てたりを結構カジュアルにできます。

Dockerの公式イメージを取得

Dockerの基本はこちらにまとめているので、Dockerの基本的な操作がわからない方はこちらを参照ください。 DockerでRails + Nginx + Postgresの環境を構築する。その①

また、Dockerのインストールがまだの人はこちらでインストールしましょう。

今回は、My SQL環境の構築にMy SQLの公式イメージを使っていきます。

公式イメージを使うとコンテナ作成時に環境変数を与えてあげるだけで、必要なデータベースとユーザーを作成することができます。

先ずははDockerコマンドで公式イメージを取得してきましょう。

docker pull mysql

このコマンドでmysqlの最新のバージョンを取得することができます。

バージョンを指定して取得したい場合は、

docker pull mysql:5.6

のようにします。

Dockerコンテナの作成

イメージが取得できたら、コンテナを作成していきます。

docker run --name mydb -e MYSQL_ROOT_PASSWORD -p 3309:3306 -d mysql

docker runでコンテナを作成していきます。

引数の説明をすると

--name	コンテナの名前を指定
-e	コンテナ起動時の環境変数を指定
-p	ポートフォワーディングの指定
-d	デーモン起動

mysql 使用するイメージを指定。5.6を使う場合はmysql:5.6とする。

ポイントはいくつかありますが、繰り返し書いたように-e オプションでコンテナ起動時の環境変数を指定できるので、起動時のROOTユーザーのパスワードを設定しています。

指定できる環境変数はいくつかあって、

MYSQL_USER	起動時に作成されるユーザー名
MYSQL_PASSWORD	起動時に作成されるユーザーのパスワード
MYSQL_ROOT_PASSWORD	起動時のrootユーザーのパスワード
MYSQL_DATABASE	起動時に作成されるデータベース名

のようになります。

また、 dockerでは-pオプションでポートフォワーディングの指定ができ、上のように 3309:3306 とするとホスト上の3309番のポートをコンテナ上の3306番ポートに、流し込んでくれます。

起動したMySQLコンテナに接続する

ここが今回の記事の肝になってきますが、 dockerにあまり慣れていない人は立ち上げたDBコンテナに接続する時のIPアドレスは？？？どうやって接続するの？？？となりがちです。

結論から先に書くと、IPアドレスは127.0.0.1です。

これを聞くと、ローカルに既にあるmysqlのホストも127.0.0.1なんだけど。。。

となると思いますが安心してください。 dockerに繋げるときは別のポートで繋ぎましょう。

これを念頭においているので、上のコンテナ作成時は3309番がコンテナの3306番に割り当てられるように指定しています。

この3309番というのはポートが空いてさえいればなんでも良いのですが上で3309:3306として指定しているので、今回MySQLに接続する際はこの3309番を使用します。

mysql -u root -p -h 127.0.0.1 -P 3309

でデータベースに接続できます。

独自のユーザー、データベースが作成されたコンテナを作成

上では、rootユーザーでコンテナを使う形になっていますがそんなのは嫌なのでちゃんと独自のユーザーとDBを使いましょう。

便宜的に独自のデータベース名をmydbとするとコンテナ作成のコマンドは以下になります。

docker run --name mydb \
-e MYSQL_ROOT_PASSWORD=password \
-e MYSQL_USER=mydb \
-e MYSQL_PASSWORD=mydb \
-e MYSQL_DATABASE=mydb \
-p 3309:3306 \
mysql

これで独自のユーザーを持ったコンテナを作成できます。接続する際のコマンドは

mysql -u mydb -p -h 127.0.0.1 -P 3309 mydb

です。

データベース起動時に初期化処理を差し込む

mysqlの公式イメージでは、/docker-entrypoint-initdb.d にスクリプトやSQLを配置するとコンテナ起動時に実行してくれます。

コンテナ作成時にデータベース内のテーブルもいっしょに作成してほしい！ダンプを取り込んで欲しい！という場合はローカルにそれらのファイルを配置しコンテナ作成時にそのディレクトリを/docker-entrypoint-initdb.dにマウントしてあげます。

ホストのディレクトリをコンテナのディレクトリにマウントするには、-vオプションを指定します。 (ホストのディレクトリは絶対パスでの指定が必要です。）

例を書くと、

mkdir init-scripts
touch init-scripts/init.sql

として init.sqlの中身を

create table ~略~

として次のコマンドでコンテナを作成します

docker run --name mydb \
-e MYSQL_ROOT_PASSWORD=password \
-e MYSQL_USER=mydb \
-e MYSQL_PASSWORD=mydb \
-e MYSQL_DATABASE=mydb \
-v $( pwd )/init-scripts:/docker-entrypoint-initdb.d \
-p 3309:3306 \
-d mysql

これでコンテナ起動時に必要なデータベースを流し込みことができます。

ここまでで記事タイトルの目的は達成していますが以下にはトラブルシューティングを書いておきます。

初期化スクリプトがエラーになりコンテナが立ち上がらない時

初期化のスクリプトでエラーになった場合はコンテナが立ち上がらないので、-dオプションを取ってログを見ながらデバッグしましょう。

立ち上がったコンテナを削除したい

```bash docker rm [コンテナ名] で削除できます ```

-fオプションをつけるとコンテナが起動している状態でも問答無用で削除できます。

同じ名前のコンテナを２つ起動することはできないので既にあるコンテナが邪魔な場合は消してしまいましょう。

mysqlが文字化けする

mysqlのデータが文字化けする場合は、mysqlの設定が原因なので、起動時にmysqlのオプションで文字コードをutf8に指定してあげましょう。

docker run --name mydb \
-e MYSQL_ROOT_PASSWORD=password \
-e MYSQL_USER=mydb \
-e MYSQL_PASSWORD=mydb \
-e MYSQL_DATABASE=mydb \
-v $( pwd )/init-scripts:inithogehoge \
-p 3309:3306 \
-d mysql --character-set-server=utf8 --collation-server=utf8_unicode_ci

まとめ | 自分が使用しているスクリプトを晒す

こうやって使い捨てのDBが構築できるようになるとカジュアルにデータベース捨てられるので、データも綺麗な状態を保てるし、ローカルも汚さないで複数のデータベース入れられるしでとっても捗りますね。

ちょっと難点として気軽にdb構築できる割にコマンドが長くて煩雑なので僕はスクリプトにして、再利用しています。

今回はそのスクリプトを晒して終わりにしたいと思います。基本は上にまとめたコマンドと同じですが、コンテナの落とし上げを繰り返すと同じコンテナ名が被って起動できないので、既に同じコンテナがある場合は削除するか訪ねてくれるようにしています。

もしつかえそうだったらコピペして使って頂ければ

INIT=$(pwd)"/init/ddl.sql"
CONTAINER_NAME=mydb

if [[ $( docker ps -a | grep "${CONTAINER_NAME}" ) ]]
then
  echo  ${CONTAINER_NAME}" is already started..."
  echo  "remove container? (y/n) ------->"
  read ANS
  if [[ $ANS == [yY] ]]
  then
    docker rm -f ${CONTAINER_NAME}
  else
    exit 1
  fi
fi

if [[ ! -r ${INIT} ]]
then
  echo "not found ${INIT}"
  exit 1
fi

docker run \
  --name ${CONTAINER_NAME} \
  -e MYSQL_DATABASE=${CONTAINER_NAME} \
  -e MYSQL_USER=${CONTAINER_NAME} \
  -e MYSQL_PASSWORD=${CONTAINER_NAME} \
  -e MYSQL_ROOT_PASSWORD=${CONTAINER_NAME} \
  -v ${INIT}:/docker-entrypoint-initdb.d \
  -p 3309:3306 \
  -d mysql:5.6 --character-set-server=utf8 --collation-server=utf8_unicode_ci

ReactNativeで電話番号フォームを実装する

Sun, 25 Mar 2018 00:00:00 GMT

電話番号形式で入力する際のフォームを実装

ReactNativeで入力フォームを使う時って、TextInputを使いますよね。ただこのTextInputさんは、汎用的につくられているので電話番号の入力フォームとしては少し使いづらい印象があります。

そこで割と簡単に電話番号形式入力フォームがコンポーネントとしてあらかじめ定義されていると嬉しいなと思い、実際につくってみました。

機能としては、まだまだで入力に対して電話番号をハイフン区切りにして表示してくれるだけですが、なんとなくそれっぽくなるように作りました。

ぜひ、コピペして使ってみてください。

TelephoneInputを実装

ポイントは、insertDelimiterメソッドですね。入力に対してつねに所定の位置にハイフンが挿入されるように作っています。

あとはそれぞれ電話番号の桁数やスタイル、キーボードの種類などをpropsに定義しています。

TelephoneInput.js

import React, { Component } from 'react';
import { Platform, StyleSheet, Text, View, TextInput } from 'react-native';

TELEPOHNE_LENGTH = 13; // 番号の桁数
DELIMITER_INDEX = [3, 7]; // ハイフンを入れる位置

export class TelephoneInput extends Component {
  constructor(props) {
    super(props);
  }

  insertDelimiter(text) {
    let text_without_delimiter = text.replace(/-/g, '');
    let index = 0;
    let result = text_without_delimiter;
    DELIMITER_INDEX.forEach(function(value, index) {
      if (text_without_delimiter.length >= value) {
        const insertIndex = value + index;
        result = `${result.slice(0, insertIndex)}-${result.slice(
          insertIndex,
          insertIndex + result.length
        )}`;
        index++;
      }
    });
    return result;
  }
  render() {
    return (
      <TextInput
        autoFocus={true}
        keyboardType={'phone-pad'}
        value={this.props.value}
        placeholder="000-0000-0000"
        maxLength={TELEPOHNE_LENGTH}
        style={this.props.style}
        onChangeText={text => {
          this.props.updateAction(this.insertDelimiter(text));
        }}
      />
    );
  }
}

実際に使って見る

上での説明は最小限度にとどめましたが、コンポーネントを定義するところで得られるメリットは上の実装を意識せずにつかえることです。

実際に使ってみて、それを確かめてみましょう。

App.js

import React, { Component } from 'react';
import { StyleSheet, Text, View, Button } from 'react-native';

import { TelephoneInput } from './../components/TelephoneInput';

type Props = {};
export default class App extends React.Component<Props> {
  constructor(props) {
    super(props);
    this.state = { telephoneNumber: null };
  }
  render() {
    return (
      <View style={{ flex: 1, alignItems: 'center', justifyContent: 'center' }}>
        <Text>Input Your Telephone Number</Text>
        <TelephoneInput
          value={this.state.telephoneNumber}
          style={{
            fontSize: 35,
            fontWeight: 'bold',
            padding: 30
          }}
          updateAction={number => {this.setState({ telephoneNumber: number });}}
        />
        <Button
          raised
          title="Submit"
          onPress={() => {
            const number = this.state.telephoneNumber;
            if (number) {
              alert(`下記の番号が入力されています。\n${number}`);
            } else {
              alert('番号を入力してください。');
            }
          }}
        />
      </View>
    );
  }
}

TelephoneInputコンポーネントを定義したことで、ハイフンを挿入するといったロジックがかかれなくなったので、コンポーネントを利用する側からはコードがスッキリ見えるようになりました。他の画面で電話番号を入力するフォームを作る必要ができたときもこのコンポーネントをつかえますね。

<TelephoneInput
  value={this.state.telephoneNumber}
  style={{
    fontSize: 35,
    fontWeight: 'bold',
    padding: 30
  }}
  updateAction={number => {this.setState({ telephoneNumber: number });}}
/>

また、updateActionで（名前があまりよくないかもしれない）ステートも更新できるようにしているので、コンポーネントの呼び出し側でも入力された値がわかるようになっています。

親コンポーネントでボタンを押すと電話番号の値を表示するように今回はコードを書いていますが、見事に親コンポーネントで値がとれています。

これができるば入力された電話番号をサーバーに送信して保存ということもできてフォームとしても使えますね。

まとめ

defaultPropsでデフォルトの値を決める。
TextInputの各propsに対応する。
電話番号の桁数やデリミタを入れる位置を外側から設定できるようにする。
バリデーションをかけられるようにする。

などなど課題はありますが、ひとまず動くようなコンポーネントが作成できましたので、記録しておきます。以上のような課題が解消できたら追記するかもしれません。

では

フリーランスは相対取引が自由に働ける道？

Thu, 22 Mar 2018 00:00:00 GMT

久しぶりの更新になりました。できるだけ週一回ほど活動報告のような形で更新したかったのですが、結果的に2,3週間ほど時間があいてしまいました。

今まで活動報告として週1くらいで更新していましたが、活動報告を書いていても所感の部分の方が書いていて楽しいし、自分の思考の結果のアウトプットにもなるのでコラムとして投稿していくことにしました。

相対取引と市場取引について

今回はこんなテーマでいきます。タイトル自体は難しそうですが、なんてことはないです。

市場取引とは、字面通り市場で行われるよりオープンな取引で、相対取引（あいたいとりひき）とはいわゆる「コネ」とか「知り合いの紹介」とかのよりクローズドな関係での取引になります。

この言葉は、ちきりんさんのマーケット感覚を身につけよう---「これから何が売れるのか?」わかる人になる5つの方法で語られていて、これにインスパイアされています。

このマーケット感覚を身につけようでは、就活市場を例にとってこの二つの取引の違いを示しています。以前は学校の先輩が就職しているからそのコネで企業に就職するような「相対取引」で多くの人たちが就職していましたが、インターネットの登場に伴いリクナビ、マイナビなど大手就職情報サイトが出現し「コネ」のない大企業にもリーチできるようになり、就職活動のほとんどが市場取引により行われるようになったとされています。

この就活市場の相対取引から市場取引への変化は、様々な分野で同様の現象がおきており、クラウドワークスは自分の得意分野を生かしたいフリーランスとアウトソーシングをしたい企業をマッチングさせ、メルカリは中古でも良いから特定の商品が欲しい人と使わなくなった商品を売りにだしたい人をマッチングさせ、従来であればオープンな場所で取引されることのなかった品物を市場で取引できるようにしました。

マーケット感覚を身につけよう---「これから何が売れるのか?」わかる人になる5つの方法には、インターネットであらゆるものが市場取引になった結果、「何が売れるのか」「何が価値あるものか」という見極める能力が大事ですよというようなことが書かれていますが、今回私はこの相対取引と市場取引という考え方が大変面白いなとおもいました。

市場取引と相対取引の違い

市場取引と相対取引の違いはそのオープン性だと考えています。市場では、誰もがそれぞれのモノの価格を一覧で確認できるので一物一価が原則ですが、相対取引では個人間での取引になるのでそうはなりません。

一物一価というのは、タクシーの初乗りの料金が東京駅で乗っても、渋谷駅でのっても変わらないというように、一つのモノに足して、一つの値段しかつかないということです。転職市場でも同年齢、同経験の人であれば市場での価値はだいたい一つにきまりますよね。

生まれてからずーっと日本にいるとこの一物一価は割と当たり前に感じますが、東南アジアなんかを旅行してみると意外に一つのモノに複数の値段がつくことが多くあります。

さきほどは都内でのタクシーの初乗り運賃を例にとりましたが、インドネシアなんかだと乗せてもらうタクシーの運転手によって値段が違うなんてことはしょっちゅうあります。お土産を買おうとして露天で買い物したりする時はモノに値札が付いてないので、値段を聞いて交渉をしてということも多いです。

このインドネシアでの運賃が運転手によって値段が違うというのは、取引の種別が市場取引ではなく、相対取引だからです。タクシーがメーターで管理されたり「このモノの値段がいくらの価値があるか」という情報が広く行きとどいているとだいたい価格は一つに収束していきますが、メーターのない運転手や、値札のついていないモノを売っている出店の定員にお金を払うときは、交渉する相手によって値段が違います。

このように相対取引と市場取引の値段の決まり方をみていくと、市場取引では市場の参加者が考える価格の平均が価格となり、相対取引では取引相手と自分の間での価格が取引の価格になります。つまり市場取引は多数の価格の平均値、相対取引では二者間で合意が取れる価格がそれぞれの取引での価格となります。

エンジニアへの需要増加でフリーランス市場が高度に市場化！？

こうやって思考を進めているとふとフリーランスの市場はどうなんだろう？と考え始めます。昨今フリーランスのエージェントサービスも多く出現して、エンジニアも供給不足などと言われて以前にもましてフリーランスとして働き始めることが楽になっているように思います。

フリーランスエージェントさん方は業界に根ざした広いネットワークを使って、案件を獲得したいエンジニアに案件を提供しますし、エンジニアの供給不足や働き方改革などの世間の煽りにのりエージェントは今後も増えていくでしょう。ただ、このままフリーランスとしての働き方が一般化してくると世の中にある案件とフリーランスとして働きたいエンジニアが市場に出揃ってきて、「これぐらいのスキルだったらいくら」という相場が固まってくるのではなんて考えています。

そうなるとフリーランスの案件紹介サービスもリクナビやマイナビのフリーランス版のような均一的な求人になり、フリーランスだけど常駐が必須のような正社員よりは契約の自由度はあるけど、フリーランスの中では不自由というような求人も増えてくるでしょう。

このような状況になると「自由な働き方をしたいからフリーランスになったけど、お客様先で働いているし、働く時間も9時-17時でなんか違う・・」という人がそれなりにでてきそうです。

フリーランス界隈では、エージェントを挟むとマージンが取られるからクライアントとの直接契約が良いという話がありますが、直接契約メリットはなにも金銭的なところだけではありません。直接契約だと働く場所や働く時間、週の稼働時間なども自由に決められます。（交渉次第では勤務時間を午後からとか常にリモートワークなどの条件も選択できるでしょう）

エージェント側だって、リモートワークの案件や週2,3日の案件をまとめて紹介することもできるのでは？という反論もありそうですが、エージェントも複数のクライアントやフリーランスを相手にしている以上、リソースの問題である程度パッケージのような形でクライアントと交渉するほかないのではないでしょうか？

このように、フリーランス市場もほとんどがオープンな形で労働力が取引されるようになるとやはりフリーランスが今後も自由に働いていくには相対取引を大事にしていかないといけないよね。という結論になります。

どのように相対取引の場を作り出すのか？

ここまで、フリーランスがより一般的になって市場でのオープンな取引が増えてくるとその分自由度が減るので、相対（あいたい）取引的なクライアントとの直接契約がより自由度の高い働き方ができるでは？ということを書いてきましたが

じゃあどうやって、相対取引の機会をつくるのか？

という話になりますよね。

これが面白いところでネットは市場での取引を進めましたが、同時に相対取引の場も同時に提供したのではなんて思っています。

TwitterやFacebook、ブログでは、今でも結構ゆるい形で人を募集をしていたり、ブログやTwitterでの発言・プロフィールをもとに仕事の依頼をしたり、SNS経由で転職したりなんていう形で興味のある個人や団体になんのつながりもなくてもコンタクトが取れるようになりました。

ここまで話をしてある程度わかるとは思うのですが、平たくいうとブログ書いたり、つぶやいたり、SNSで発信して仕事の依頼を受けよう。ということです。ほかにも、自分の興味ある情報を呟いている人がエンジニア不足で困っていたら、「仕事やりましょうか？」なんて声をかえてみるのもいいんではないでしょうか？

リアルも良いですが、個人としてはWeb上の方が多くの人にリーチできるのでそちらに力いれていきたいです。とはいえ、リアルはリアルでWebに流れない情報が落ちているので、自分のクライアントになりそうな人がいそうな場所にいくというのはぜんぜんありですね。

まとめ

ここまでのまとめです。

エージェントはエージェントで均一的な案件が集まる。
マッチングプラットフォーム以外で相対取引（あいたいとりひき）のクライアントに接触できる仕組みをつくる。
相対取引（あいたいとりひき）を狙うフィールドはWeb上が多くの人にリーチできるのでよさそうだけどリアルのつながりもぜんぜんあり

色々と書きましたが、ここらへんがポイントではないでしょうか？この記事で言いたいことは、フリーランスになるには、エージェントさんなどの動きが活発になってきて需要もあるから割と難しくないけど、そういう志向のエンジニアが市場に出揃ってきて相場もかたまりつつあるから、理想の働き方や年収を実現するには、圧倒的に高度なスキルか一工夫必要だよということです。

私がこうしてブログを書いているのもこれによるところが多いですね。ネットに投稿していくことが資産になるとおもっているので、偉そうに語りましたが自分の戒めにもまとめてみました。

最後まで読んで頂きありがとうございました。

Rails5.1すでに存在するカラムをmigrationでnot nullにする

Thu, 01 Mar 2018 00:00:00 GMT

change_column_nullを使う

すでに存在するカラムをマイグレーションでnullにするには、change_column_nullを使います。

class ChangeLikeCountToPost < ActiveRecord::Migration[5.1]
  def change
    change_column_null :posts, :like_count, null: false, 0
  end
end

change_column_nullはDBの定義をnull:オプションで指定した定義に変更するまえに、値がnullのものを第4引数にupdateしたのちにDB定義を変更してくれます。

def change_column_null(table_name, column_name, null, default = nil) #:nodoc:
  unless null || default.nil?
    execute("UPDATE #{quote_table_name(table_name)} SET #{quote_column_name(column_name)}=#{quote(default)} WHERE #{quote_column_name(column_name)} IS NULL")
  end

  change_column table_name, column_name, nil, null: null
end

change_columnでもDBの定義は変更できますが、このメソッドは問答無用でDBの定義を変更しにいくので、「値がNullのカラムにNotNull制約をつけることはできません」となって怒られます。

change_column_nullはDBのデフォルト値も変更してくれるわけではない

下のコードをみると、NotNull制約をつけるついでにDBのデフォルト値も設定してくれそうに見えますが、

change_column_null :posts, :like_count, null: false, 0

実際は、そこまでやってくれません。第四引数の0はnullの値を置き換える値を指定するだけでデフォルト値を指定しているわけではないことに注意しなければいけません。

そのため、NotNull制約をつけるついでにデフォルト値も設定する場合は、以下のようにする必要があります。

class ChangeLikeCountToPost < ActiveRecord::Migration[5.1]
  def change
    change_column_null :posts, :like_count, null: false, 0
    change_column :posts, :like_count, :integer, default: 0
  end
end

私がフリーランスになった理由

Fri, 23 Feb 2018 00:00:00 GMT

2017年の11月にフリーランスのエンジニアとして独立して晴れてフリーランスの道を進み初めて、現在これを書いている2020年1月現在二年が経過しました。

フリーのエンジニアとして働いている中で色々な方々にお会いすることがあるのですが、その中で「なんでフリーランスになったの？」と聞かれることが何回かあったので記事として改めてまとめてみたいと思います。

フリーランスへの憧れ

フリーランスになった理由として、色々な理由をこねることはできると思うのですが、僕に関していうとまぁフリーランスになった理由は、単純なフリーランスとしての憧れです。そこに特に深い理由はなく、**「やってみたかったから」**です。

幸運なことにWebエンジニアの需要はかなり高く、フリーランスで仕事なくなっても最悪転職活動して会社員に戻れば良いやという感じで思えたので、「やりたいならやってみよう」ということでフリーランスとして働きはじめました。

フリーランスというと、仕事ができて、高収入、自分の好きな時間に仕事ができてというようなキラキラしたイメージがあるかと思うのですが、僕自身もこのライフスタイルに学生時代から憧れていて、目の前になんか届きそうなチャンスがあったのでフリーランスとして働き始めたと言う形になります。

実際に働き初めてみると本当に人によりけりで、フリーランスとして働いているけど実質的にはほとんど会社勤めと変わらないような働き方をしている人もいるし、海外でリモートワークもしているし様々です。

フリーランスとして、二年働きましたが、フリーランスだから高収入、フリーランスだから自分の仕事ができるということは特にないです。フリーランスは文字通りフリーなので、会社に属しているしがらみから取り払われて選択の自由が与えられるだけで、自らリスクを侵して選択していかない人は、結構不自由だなぁと感じることも多いです。

**「フリーランスのキラキライメージにのせられるな！」**みたいな話もよくあると思うのですが、年齢が十分に若くある程度の経験と実力不足を努力で補える自身のある人はどんどんフリーランスやっていけば良いと思います。

他の文系職種とかだと話は違うかと思うのですが、Webエンジニアに関していうと今の時代では、ミスってもまた会社員として勤め直すことは十分可能なので人生の経験を詰める方、自分のやりたいワークスタイルを選択できれば良いのではと思います。

会社員時代に感じていた不満

フリーランスになるにあたり、フリーランスへの憧れがまず第一の理由としてあげられるのですが、それに付随して会社員時代に感じた不満みたいんものもフリーランスとなるきっかけになったのでそれについても書いていきます。

貴重な人生の時間を犠牲にしても年数百万程度しか稼げない

これはある事業会社でエンジニアとして働いていた時に感じたのですが、その会社は結構残業が多く月200時間を超えて働くのが割と頻繁にありました。これだけ働くとやっぱり平日はほとんど会社のことで全ての時間をとられてしまいいくら勉強をしたり、趣味の時間にしたりしようとしてもその時間と体力が残っていませんでした。

会社の仕事が自分の趣味とか興味と８割方あっていたりすればそれでも幸せに働いたりはできるのかもしれませんが、私の場合そうではなかったので、

「これって週5日を会社に捧げているってことだよなぁ」「それだけ人生の時間を捧げているのに当時で400万円程度これから頑張っても500万円って」

なんてことを考え初めていました。価値というのは、取引する相手によって変わるのでなんとも言えないですが、この状況をシンプルに捉えると自分の人生を400~500万円で売って生計を立てているということになります。保険料を会社が負担してるから実質はもっと高値で売っているのかもしれませんが、それでも差額は年100万円程度でしょう。

自分の人生はおそらく誰と取引したとしても自分と取引した時に価値が最大になるかと思うので、多くの場合少なく感じるとは思うのですが、それにしても**「自分の人生の価値低すぎでは？」**と思うようになり、自分で価格を設定できて、取引の相手を選べるフリーランスは良いのではと考えるようになりました。

同じような失敗を繰り返したくないので環境を変えたかった

フリーランスなる前にすでに、自分は二社会社を経験しているのですが、**次また自分が良いと思う会社に転職してもまた二、三年たったら別の会社を探しているだろう。**という思いがぬぐいきれなかったので環境を変えて、フリーランスという働き方を選択しました。

働き方の自由度が低い

エンジニアとして、多くの現場を経験することは様々な環境での技術の応用力がつくので生産性の向上につながると思っているのですが、会社員として週5日で働いていると他のプロジェクトを経験できないので自身のキャリアの成長としてはあまりよろしくないかなという感じがしていました。

フリーランスになると複数の現場の掛け持ちや短期、中期で色々なプロジェクトを経験できるので短期間で引き出しを増やすことが可能です。

まとめ | 実際フリーランスになってどうだったか？

結果論にはなりますが、2017年に独立する前に散々なやんだあげく、フリーランスと言うキャリアを選択できたのは本当によかったと思います。会社の中にいると知らないだれかが稼いで聞いてくれるので、外の状況に関心がなかったっり、情報が入ってこなかったりしがちなのですが、フリーランスとして働き初めて、経営者の人や同じフリーランスの人などと接する機会が増えて、働く時の考え方に幅が出てきたような気がしています。

一方でフリーランスとして働いていく中でやっぱりフリーランスとしての立場の弱さなど限界を感じる部分も多くあります。プロジェクトに参加して、自分の意見を通そうと思った時にやっぱり社内の人間ではないので決断ができず、アドバイスや意見を伝えることしかできないところに歯がゆさを感じる部分も多いです。（社外の人間であるということで適度な距離感を気づけるという利点もあるのですが）

フリーランスというのはまぁ実態のないものです。フリーランスは名前の通り形のない仕事なので、自分が思うフリーランス像を作るのにどういう行動をすれば良いのか等々を計画しながらやっていくものなので各々のフリーランスの形があるのではないのでしょうか。

リモートワークがしたいなら、リモートワークができる仕事をどうすれば獲得できるのか？
収入をあげたいなら、どういうことをすれば単価が上がるのか？

あたりを考えながら、自分のスタイルを作っていけるのが理想のフリーランスなのかなぁなんて思います。

では。

polymophicなテーブルを経由して、has_many thourghする。

Wed, 14 Feb 2018 00:00:00 GMT

Railsのアソシエーションで、中間テーブルを経由して一個飛ばしでインスタンスを取得できるhas_many~through便利ですよね。ところが、この中間テーブルがpolymophicだった場合に、どうやって対象を取得すれば良いのかということに悩みました。

解決策は、結論からいうと、下の例でいうとモデルにはこういう形で定義して、そのままuser.post_commentsのような形でできます。

has_many :post_comments, through: :comments, :source => :commentable,:source_type => 'Post'
has_many :blog_comments, through: :comments :source => :commentable,:source_type => 'Blog'

図やコードを交えて解説

これだけではなんのことかよくわからないかもしれないので、上の結論のコードの全容を明かすと以下のようになります。

以下のモデルは、複数のユーザがブログを作り、各々ポストを投げていくという世界を想定したモデル群です。

class User < ActiveRecord::Base
  has_many :blogs
  has_many :posts
  has_many :comments
  has_many :post_comments, through: :comments, :source => :commentable,:source_type => 'Post'
  has_many :blog_comments, through: :comments :source => :commentable,:source_type => 'Blog'
end

class Blog < ActiveRecord::Base
  has_many :comments, as: :commentable
end

class Post < ActiveRecord::Base
  has_many :comments, as: :commentable
end

class Comment < ActiveRecord::Base
  belongs_to :commentables, polymophic: true
end

コードを見てみると、確かにいつものようにhas_manyで「Userが行った投稿を取ってくる」ことや「Userが持っているブログを取得する」ということは簡単にできます。ただ、「ユーザーがコメントした投稿」や「ユーザーがコメントしたブログ」についてはどうやって取得しようか少し迷うところがあると思います。

特に、ここでは、中間テーブルの役割をはたすCommentがポリモーフィック関連なのでなおさらです。

railsのポリモーフィック関連では、~~able_idと~~able_typeというカラムで関連が定義されますが、上のコードを例にとるとhas_many :commentsだけでは、「ユーザーがコメントした投稿」と「ユーザーがコメントしたブログ」の両方ともが取得されてきてしまいます。愚直にやるのであれば、commentable_typeを条件にSQLを発行してとやればできなくはないですが、それは苦しいです。。

そこで、この解決策では、:sourceオプションと:source_typeオプションを使って、ポリモーフィック関連の先のテーブルを指定してあげることで「ユーザーがコメントした投稿」と「ユーザーがコメントしたブログ」を簡単に取得できるようにしています。

polymophicなテーブルを経由して、has_many thourghする場合は、sourceオプションでポリモーフィック関連の名前を指定して、source_typeで中間テーブルの先のクラスを指定してシンプルにデータをとってきましょう。

AssetPipelineなしでRailsのモデルのデータをReactで取得する方法

Wed, 31 Jan 2018 00:00:00 GMT

サーバ側はRailsでフロント側はReactみたいな構成でシステム開発していることってまあまああると思うのですが、

RailsとReactは全く別の機構なのでその間でどういう形でデータのやりとりをしていますでしょうか？

SPAなどでは問答無用でAPIで初期状態も含めてデータを取得してくるようなことをやってくるとは思うのですが、そこまでかっちりReactを使っている訳ではなく、初期状態はRailsでレンダリングして、残りのユーザからの入力などによるViewの変更はReactでみたいなことありますよね。

ただ、AssetPipelineなどを使って入ればrails-reactというgemを使って自動（あまり意識せずに）データを受け渡しできるのですが、そうではない場合にどのようにデータをやりとりするか以下にまとめます。

JavaScriptでDOMをパース

上に書いた内容でRails-Reactでデータの受け渡しをする場合は、基本的な考え方としてモデルの内容を一旦json形式に変換して、DOMにレンダリングします。

その処理自体を自分で書いても良いのですがさすがに辛いので、楽して上にも書いたrails-reactのReactComponentヘルパーを使います。このヘルパーの引数にKeyとモデルなどのデータを私てあげるとそれをjson形式に変換してレンダリングしてくれます。

(例)

<div data-react-class="Settings"
data-react-props='{"settings":[{"id":72,"user_id":1,
"space_id":"space-a",
"api_key":"hogehoge"},' >

実際のモデルだともっと行数が多いのですが、例では簡略化しています。

DOMへのモデルのレンダリングができたらあとはそれをページが描画されたタイミングなどでパースするだけです。

function getSettings(selector: string){
  const node = document.querySelector(`div[data-react-class=${selector}]`)
  const json = JSON.parse(node.getAttribute('data-react-props'))
  return json
}

こんな感じのメソッドを定義してあげて使い回せばjavascript側でも無事Railsのモデルのデータを取得ができます。

RailsとJavaScriptを確実に分けて開発したい！asset pipelineは使わないという主義の人はこうやって見ると良いかもしれません。

Rails+Devise+LetterOpenerでシードを行う際に、メールがタブで開かれないようにする

Wed, 17 Jan 2018 00:00:00 GMT

letter opener便利ですよね。

ryanb/letter_opener

letter openerは、開発しているアプリケーションからメールが飛んだときに、メールを送信する代わりに、送信するメールをタブで開いてくれます。

が、

今回Rails + Devise + Letter Openerを使った場合に、ユーザのアカウント作成時のメールのタブがポコポコでてくるようになってしまったのでその対策を共有します。

やろうとしたこと

今回はテストデータとして、rake db:seedでユーザを10人くらい自動で生成するようなスクリプトを組みました。

開発中にDBを綺麗にしたいときに、

rake:db:reset && rake db:seed

のようにカジュアルに実行できるようにしたいです。

db/seeds.rb

User.delete_all
10.times do |idx|
  User.create(
    name: "user_#{idx + 1}",
    password: 'password',
    email: "user_#{idx + 1}@example.com",
    age: 25
  )
end

(これはサンプルで実際はFactoryBotを使ったりしています)

この方法だと、確かにユーザは10人作れるのですが実際にシードを走らせてみるとユーザ作成時にdeviseが確認のEmailを飛ばすので、それに呼応したletter openerがポコポコと丁寧に10人分のメールをポコポコとタブで開いてくれます。

さすがに、毎回シードを走らすたびに10個もタブが開くのはいただけないので少し調べてみました。

解決方法

解決方法は割と簡単で以下のように設定を足して

ActionMailer::Base.perform_deliveries = false

シード内でメールが飛ばないようにするだけで解決できます。

db/seeds.rb

# LetterOpnerでメールが開かれないようにする
ActionMailer::Base.perform_deliveries = false

User.delete_all
10.times do |idx|
  User.create(
    name: "user_#{idx + 1}",
    password: 'password',
    email: "user_#{idx + 1}@example.com",
    age: 25
  )
end

rubyのEnumerableクラスの抽出メソッドまとめ、map、find、reject、select

Fri, 12 Jan 2018 00:00:00 GMT

RubyのEnumerableがごっちゃになっているのと、便利なメソッドが多いので、まとめてみます。

例に使用しているrubyのversionは2.4.1です。

map

mapはブロックの結果をまとめた配列を返してくれます。 collectというメソッドもありますが、mapはcollectのエイリアスなので挙動は同じです。

mapの方が短いのでmapを使いがちです。

下の例では仮想通貨の頭文字の配列の中で、'B'という文字列が含まれるかを判断して返しています。

2.4.1 :003 >   coins = [ 'BTC', 'ETH', 'XRP', 'NEM']
 => ["BTC", "ETH", "XRP", "NEM"]
2.4.1 :004 >
2.4.1 :004 >   coins.map{ |coin| coin.include?('B')}
 => [true, false, false, false]

Hashの場合は、key と valueを分割できます。 keyを取り出したり、valueを取り出すにはこうします。

2.4.1 :027 >   coins_hash = { btc: 'Bitcoin', eth: 'Ethereum', xrp: 'Ripple', nem: 'XEM' }
 => {:btc=>"Bitcoin", :eth=>"Ethereum", :xrp=>"Ripple", :nem=>"XEM"}

2.4.1 :032 >   coins_hash.map{ | key, value | value }
 => ["Bitcoin", "Ethereum", "Ripple", "XEM"]
2.4.1 :032 >   coins_hash.map{ | key, value | key }
 =>[:btc, :eth, :xrp, :nem]

find ( detect ) | 最初に条件に一致したものを返却

findは配列やハッシュの個別のオブジェクトの中で最初に真になったものを返却してくれます。 detectというメソッドもありfindの別名になります。

2.4.1 :090 >   coins.find{ |c| c.include?('X') }
 => "XRP"

ハッシュの場合

2.4.1 :084 $gt; coins_hash.find{ | key , value | key.to_s.include?('x') }
 => [:xrp, "Ripple"]

select | 条件に一致したものを配列で取得

selectはブロックが真を返したものを配列で返却してくれます。 findメソッドは最初に一致したものを返却してくれますが、selectは真のものすべてを返却してくれます。

2.4.1 :095 >   coins.select{ |c| c.include?('T') }
 => ["BTC", "ETH"]

ハッシュの場合

2.4.1 :117 > coins_hash.select{ |coin| coin.to_s.include?('t') }
 => {:btc=>"Bitcoin", :eth=>"Ethereum"}

reject | 条件に一致しないものを配列で取得

rejectはselectの反対で偽のものを抽出して配列にしてくれます。

2.4.1 :118 > coins.reject{ |c| c.include?('T') }
 => ["XRP", "NEM"]

ハッシュの場合

2.4.1 :121 > coins_hash.reject{ |coin| coin.to_s.include?('t') }
 => {:xrp=>"Ripple", :nem=>"XEM"}

2018年やること・やらないことリスト -

Mon, 01 Jan 2018 00:00:00 GMT

活動報告2回目になります。

週4日で働いてる現場も無事仕事納めをし、安心して年を越せそうです。今月は無事契約を更新できたので引き続き同じ現場で働かせて頂きます。

振り返りを行う目的(復習）

目的も一度だけでは忘れてしまいがちなので、復習します。（復習はしつつも、適宜改善はしていきたいです。）

目的は以下の通りです。2018年も引き続きこれでやっていきます。（まだ2回目ですが）

・自分の活動状況を公開してフリーランスの生活を可視化する。（普通に生活しています。生きています。というのをお伝えする。）・良いことがあったらドヤする。・一年スパン、三ヶ月スパンでの目標の確認及び達成度合いの確認

新年の抱負

やること

・フリーランスとして1年間生き延びる。

これは一番の目標ですかね。念願のフリーランスにはなったものの、なるだけなら誰でもなれるのでしっかり収入を維持しつつまずは一年フリーランスとしてサバイブするということです。

・エンジニアとして特定の分野の技術を固める。

エンジニアの勉強すべきことってやっぱり多くて、勉強の時間は十分に取らないといけないのですが、やっぱり習得できる範囲というのは限られています。あれもこれもとならず自分のフィールドを決めてそこのフィールドでのレベルアップを図っていきたいです。今はRailsからフロントにかけてのところでReactについてもっと知識をつけて行ければと思います。

・より多くより、「より少なくより良く」

フリーランスは自由度が高く基本何をやってもいいんですけど、それで色々やってみたけどやっただけで終わってしまったというのでは身にならないので、ある程度注力する分野を決めてそこを掘っていきたいです。限られた資源を分散することなく効果的に集中していきたいです。

これは読書にも言えることで、たくさんの本を読むというよりはこれは良いと思った本を繰り返し読むという本の読み方に変えていきたいです。最近では、Amazonでポチッとするとすぐに本を買えてしまうのであれこれ読んでしまいがちなのですが、本の内容を忘れてしまっていたりするので一冊の本を通して理解できるまで繰り返し読むということをしていきたいです。

・活動報告を1年間継続する。

この一年ブログを書き続けてなんとか100記事達成できました。短期間で集中してというのも良いのですが継続することがその分野での深みや差別化になると思うので大きなインパクトはなくとも細く長く続けていきたいななんて思っています。

あとは、来年書き続けた記事を振り返ったりしたら、あの時こんなこと考えていたのねなんてことがわかったりして面白そうだからです。

・英語のドキュメントを読破する。

StackOverFlowくらいの英語なら読めるのですが、ドキュメントなどちょっと長めの文章になると体力が持たないです。。あとは一文一文の意味はわかるのですが文全体としての伝えたいことやサマリがパッと読みながら作れないので、英語のドキュメントを読むのが苦手で日本語のドキュメントに逃げがちです。

2018年はこいつを倒せるように、どれだけ時間かかっても良いので英語のドキュメントと向き合っていきたいです。

・収益性アップ。目指せ月10万円。

現状収入の口が少ないので、収入の口を二つ以上にしていきたいです。それの第一の矢としてこれと並行してサイトを作成したいのですが、そこで月10万円でもいいので収益を出していきたいです。

やらないこと

・興味・関心のままに多くに手を出さない。

これは日常の雑多なことに気を取られずにやるべきこと・重要なことに集中しようという戒めですね。やりたいと思ったらすぐにはじめず一旦、時間を設けてそのアイデアを練る時間を作る。他のタスクと比較して重要だと思ったら、何かを捨ててそのプロジェクトを始めるというプロセスをしっかり回していきたいです。

やろうとするとタスクは無限に増えていくので、どんどん雑多なことに時間を奪われてしまいがちです。これを意識して取捨選択して、リソースを効率よく使えるようになりたいです。

・部屋を散らかったままにしない。

やりたい作業があるとついつい周りの環境を整えずにやり始めてしまう癖があるのですが、部屋が散らかっていると集中力が保てません。仕事部屋の整頓もしていきます。

・働きすぎない、定期的に何もしない日を作る。

やるべきことをやらないといけないというのはありますが、年中無休でずっと働き続けるためにフリーランスになった訳ではないので、意識的に栄養補給の時間を設けます。意識的に仕事と関係ないことをするかあるいは何もしない時間を作る。これはどんなに忙しくてもやっていきたいです。

まとめ

全然関係ないですが、大晦日のAbemaTVの朝青龍の企画は、10年ほど前の大晦日のK-1のワクワク感を感じました（後半3人だけ）。

インターネットでこれだけ面白いコンテンツが見れるようになってきてるので、本当すごいなと思いました。テレビのコンテンツ自体が飽和気味（客観的に飽和しているかは知りません、個人的に面白いテレビが減ってきたなという意味です。）Abemaさんにはこのような面白い企画をどんどんやって行って欲しいなと思っています。

大晦日になんとなく見てみた番組で時代の変化が見れて嬉しかったです。今年は仮想通貨もありますし、こういった変化にもアンテナ張りながら、満足した一年が過ごせればなと思っています。

今年もよろしくお願いいたします。

Udemyでクーポンを利用して、気になるコースをお得に利用する方法

Mon, 01 Jan 2018 00:00:00 GMT

今回はUdemyで気になるコースをお得に利用する方法を紹介します。

その方法とは講師の発行するクーポンやクーポンコードを利用して通常の価格よりもお得に講座を受講できる方法です。

クーポンの見つけ方

クーポンは講師の方から発行されたり、Udemyから発行されたりするそうです。（Udemyのリンクは踏むリンクによってコースの値段が違うことがたまにありますがそれもクーポンの一種かもしれません）

今回は、講師から発行されたクーポンの見つけ方のみの紹介ですが、

それは

講師のFacebookやTwitterのアカウントをさがしてクーポンの告知を行なっていないか確認する

という方法です。

実際に、フルスタックエンジニアの講座を提供しているUdemy講師の井上博樹さんはご自身のFacebookのページで自身の講座をUdemyの最低価格で受講できるURLを公開しています。

https://www.facebook.com/hiroki.inoue.102

Udemyのクーポンって？

クーポンとはご存知の通り、割引された商品を購入するためのチケットですが、Udemyのクーポンとは、URLで提供される場合とクーポンコードというパスワードのようなランダムな文字列として発行されるようです。

URLで提供される場合は、その提供されたURLをクリックして他の講座と同じようにコースを購入すれば良いです。

逆にクーポンコードの場合は、

このようにコースの購入の下に「クーポンをお持ちですか？」という表示があるのでそこをクリックして入力という手続きになるようです。

なんでクーポンを発行するの？？

このようにお得にコースを受講できるUdemyのクーポンですが、なぜ講師の方々はクーポンを発行するのでしょうか？

理由としては、

コースにまだ受講者が少ない段階でのユーザ獲得のため
クーポン経由の購入の場合講師の報酬が大きくなるため

です。

コースにまだ受講者が少ない段階でのユーザ獲得のため

コース開始当初はあたりまですが、受講者が少なくユーザの反応もわかりづらいため割引をしてでもコースを受講してもらい感想を聞きたいというのがあるようです。

そのため講師は最初にコースを作った段階でクーポンを発行することが多いので、自分の勉強したいテーマを多く開講している講師のFacebookやTwitterをフォローして置くと新しい講座が割引して受講できるチャンスも上がるかもしれません。

クーポン経由の購入の場合講師の報酬が大きくなるため

講師が開講したコースが購入されるとそのうち何%かが手数料でUdemyの報酬になる、残りが講師の報酬となりますが、クーポン経由での購入の場合にはこの割合が変わります。

通常での購入が売り上げの33%が講師の報酬になるのに対して、クーポンでの購入の場合は、97%が講師の報酬になるそうです。

クーポンは割引になるので元の値段があまり高くないというのもあると思いますが、このような事情から講師も積極的にクーポンを発行しているようです。

気になるコースを見てみる

これまであまり自分が受講した講座の講師の方や、気になる講座の講師を気にしていないのでしたらぜひチェックして見ることをオススメします。

気になる講師のFacebookページなどを訪れてみると、意外とクーポンでお得に受講できるかもしれません。

世界最大級のオンライン学習サイトUdemy

コースを受けてみた感想はこちらにのっけているので、興味があればどうぞ => Udemy でデザインのコースを受けてみた感想。Udemyで勉強するメリットまとめ

SMACSSでデモサイトのコード書いてみた

Sat, 16 Dec 2017 00:00:00 GMT

前回の記事では、SMACSSの電子書籍をまとめてみました。 CSSスタイルガイドのSMACSSを勉強してみたまとめ

今回は、書籍を読むだけでは理解が深まらないので実際にSMACSSを意識しながらコーディングしてみました。

ランディングページを作ってみる

今回は、題材としてランディングページのコーディングをしてみました。

ランディングページとは、LPと呼ばれたりもするので、広告や検索から訪れるユーザが最初にみるページのことです。

人間関係でも第一印象が大事と言われるように、商品とユーザが初めて出会う場所ですのでサイトのユーザに与える印象の大事な部分を担っています。

今回はSMACSSを意識しながら書いてみて、悩んだところや、よかったところ、SMACCSでは表現しにくいところを知るための題材ですので、それほどユーザに与える印象とかビジネスライクな部分はあまり意識していないです。

というか、私普段からバリバリcss書いていててcssでは誰にも負けません!!

という感じではないので私のコードはあくまでも私のコードで、これを参考にすれば大丈夫!!みたいな絶対的なものでなく、コーディングしてみましたーというようなのものなのでご了承ください。

その点踏まえて、仕上げたページはこちらになります。

おぉ・・・

まぁありがちですね。サイトは自分が開発してみたいなぁと思っている個人のタスク管理ツールをイメージして作りました。

レイアウトはシングルカラムレイアウトのよく見るランディングページという感じですね。

ログインボタンやサインアップのボタンを押すとフォームが表示されたりするようにはしていますが、完全なるデモページなので、それ以上は進めません。

ご了承ください。

デモページのリンクはこちらです。 GitHubPagesで後悔しているので実際のデモがご覧いただけます。

https://version-1.github.io/smacss-sample/example/default/

ソースはgithubにあげておきました。 https://github.com/version-1/smacss-sample

SMACSSしてみて気づいたこと

境界線の引き方が難しい
moduleのソースが大きくなりがち
jsをどれくらい使うかでコードが変わりそう

境界線の引き方が難しい

これは単に慣れ次第でもう少し切り分けができるようになるかなとも思うのですが、他のcssの設計手法と同じように線引きが難しいと感じました。

何がレイアウトで何がモジュールなのかというのはやはりコーディングをしていて悩みました。

カルーセルやアコーディオンなど明らかにわかりやすいのは良いのですが、ヘッダーやフッターはどこまでレイアウトのカテゴリで書くべきなのかというのは悩みました。

SMACSSを提唱している原本でもそこまで明確に線引きをしている訳ではないので、あくまでもセマンティック性の維持と保守性という目的から考えたベストエフォートを取っていくしかないのではないでしょうか。

結果的にはレイアウトは最低限の大枠に留めて、ヘッダーやフッターの中のスタイルのほとんどは、モジュールで定義しました。

モジュールのソースが大きなくなりがち

LPをコーディングした結果以下のような構成になりました。

みてわかるようにSMACSSのカテゴリでシンプルに分類しています。モジュールが全体の80%くらいになりそうですね。。

もう少し大きいシステムになると管理画面とユーザの画面でスタイルを分けたりする必要があるので、管理者、ユーザ、共通、のような形で分けて各セクションごとにベース、レイアウト、モジュール・・・のように分けてしまう方法もありかもしれません。

今回に関してはLPのみのコーディングでしたので、入れ子にせずフラットに分割しました。

スクショみてもわかるようにレイアウトは大まかなところ、モジュールは細かいところというような形で分担してしまったので、モジュールのコードが占める割合が大きくなっています。

大きくなること自体が悪いわけではないのですが、大きい分その中に冗長なコードが含まれているのではという懸念もあるので、ちょと不安になりました。

コードを書いていると

「これ、ステートじゃないよな」

「レイアウトでもないしな」

「じゃあモジュールか」

という感じで多くのコードがモジュールに流れつきましたね。

まぁここは割合の問題というよりは、あくまでもセマンティックで重複のないコードを目指す上での問題なのでそれらを鑑みて「どうすれば一見で理解できて、整理されたコードになるのか」というのを考えながらリファクタして答えを見つけていいかないといけません。

jsをどれくらい使うかでコードが変わりそう

今回一応JQueryも使っているのですが、本格的にJQueryでクラスを当てたり外したりということはせず、いくつかのアニメーションを極力cssで実現できるようにしました。

modalに関しては、modal-cssを使ったので、jsをほとんど自分で書くことはなく、カルーセルでもslick.jsでslickの関数呼び出し、アコーディオンでのクラスの割り当てに簡単にjs使うくらいでした。

JQueryをもっとバリバリ書いていくとよりステートコードが増えていきそうです。

ランディングページだけなのであまりJS書かなくて済んでいますが、もう少しページが増えて大規模になってくるとJQueryも必要になってきそうなので、実際の現場ではもう少し、ステートのコードの割合は増えそうな気がしています。

工夫したこと

簡単に今回自分なりに工夫したことを書くと以下になります。

テーマの層が有効に使えるようにした。
アコーディオンやボーダーのアニメーションなどが極力HTMLに依存しないようにした。

テーマの層が有効に使えるようにした

SMACSSの原本によるとテーマの層はプロジェクトによって存在しない場合があるそうですが、テーマはサイトの見た目の変更をユーザに委ねる場合などで使われるようです。

ようは、見た目の変更をユーザの好みに合わせてできるようにしますよということです。

今回上のディレクトリ構造の写真によると_variable.scssというファイルと、theme/_default.scssというファイルがあります。

これが何をやっているかというと、 _variable.scssでサイトで使う色やフォント、フォントのサイズなどを変数を使って定義しています。

さらに今回は、_variable.scssでは主に、ユーザがいじれないような変数を定義して、theme下のファイルで代表的な色をユーザの好みに合わせて色を変更できるようにしました。

スクショだと、theme下に4つのファイルがありますが、それぞれサイトの色を変更できるテーマファイルになっていて読み込むファイルを変更することで、サイト内で使われる色を変更できます。

下記の例では、default.scssを読み込んでいます。

@import 'theme/default';
// @import 'theme/theme1';
// @import 'theme/theme2';
// @import 'theme/theme3';



/* bg-color{{{ */
$primary-bg-color: map-get($color-map,site-base-white-color);
$secondary-bg-color: map-get($color-map,site-quaternary-color);
・
・
< 略 >

それぞれの例は、下記URLで確認できます。

モジュールのアニメーションがHTMLに依存しないようにした

アコーディオンを今回自前で実装しました。がアコーディオンのアニメーションをこのページ二箇所で使えるように実装しました。

一つはFAQのコーナーで、一つは画面幅が狭い時のメニューです。

どちらも、隠れていたオブジェクトが表示される際にアコーディオンが開くのをイメージした形で実装されています。

また、hover（マウスオーバー）した際に発火する下線のアニメーションもhtmlにクラスを追加するだけで、アニメーションが実現できるようにしました。

これらに関してどのアニメーションも要素タグを使っていないので、HTMLと疎結合な形でCSSを実装することができました。

まとめ

ここまで色々とまとめましたが、正直まだSMACSSはわからないです。。

SMACSSは意識しつつもOOCSSも意識して構造と見た目は分離した方がいいのかやこれは本当にモジュールとして定義していいのか

などなど疑問はつきません。

まぁどのスタイルガイドを採用するにせよ、セマンティックで変更に強い重複のない設計が求められるとは思うのですが、これは最初に実装してみた後に徐々に変更を加えてみると

「このコード変更するときにやたらコード書くな」

みたいな違和感を感じてコードのよくない部分に気づける気がしています。

実装完了した時は完璧に実装できているように見えるけど、実際に拡張してみたりのちの変更に対応してみるといかに最初の設計の弱い部分が見えてくるのでしょう。

今回紹介したコードも暫定的なものなので、これらを差し引いてみて頂けると嬉しいです。今回は設計の話がメインでしたが、SMACSSで書いてみるに当たって新たに学んだコンポーネントのつくり方なども紹介して行ければと思います!!

では

CSSスタイルガイドのSMACSSを勉強してみたまとめ

Sun, 10 Dec 2017 00:00:00 GMT

SMACSSって知ってますか？

css初心者レベルからぬけだしたいのであれは知っておいていた方がいいcss設計に関する知識です。

私もこないだまでは名前しか知らない程度だったの他人のことを言える立場ではないのですが、これを勉強すればcssをさらに深くしれるなと思い勉強してみました。

参考にしたサイト

今回は公式サイトのドキュメントをダウンロードして読み込みました。

130ページ程度の電子書籍で(無料です)短いのでぜひ読んでみることをオススメします。

https://smacss.com/ja

本の流れとしては、最初にそれぞれのレイヤーのルールを紹介した後に、テンプレートエンジンやSASSなどのプリプロセッサ、パフォーマンスなどSMACSSに関連したトピックについて記載されています。

本自体は元々英語で書かれているもののようなのですが、訳が若干読みづらいかもしれません。何はともあれ、しっかりと理解したい方は一度読んでみてみると良いと思います。

SMACSSの概要

SMACSSは、CSS設計の際に用いるアーキテクチャのルールやパターンの事です。規約がものすごい厳密という訳でもなさそうですのでスタイルガイドと言ってしまって良いと思います。

CSS設計に関するアーキテクチャとしては他にも OOCSS, BEM などがありSMACSSもその一つになります。

このアーキテクチャの目指すところは

よりセマンティックで、拡張性が高く変更に強い CSSです。

この場合の変更に強いとは

HTMLへの依存性が低く、HTMLの変更がCSSに影響を与えない

ようなことを言います。

セマンティックであるとは、見た目や振る舞いではなく、目的や意図がわかるということです。

それを実現する方法がSMACSSとして提唱されているのですが、基本的な思想として

CSSの役割を

ベース
レイアウト
モジュール
ステート(状態)
テーマ

の5つのカテゴリに分けて管理します。

名前でなんとなく想像はつくと思いますが、簡単に説明すると

ベース

bodyタグやhtmlタグなどデフォルトでのスタイル定義。サイトの背景食や文字サイズ、フォントスタイルなども含みます。

レイアウト

名前の通りレイアウトを定義する層です。ただし、ボタンや吹き出し、カルーセルなどの部品はここでは定義しません。

モジュール

ボタン、カルーセル、アコーディオンなどアプリケーションの中の部品を定義します。

ステート

モジュールやレイアウトの状態を定義しています。表示・非表示やアコーディオンが畳んだ状態か開いた状態かなどの部分です。

テーマ

これは常に必須のレイヤーではないそうなのですが、デザインの表層の部分が定義されます。サイト全体の色やフォントをデフォルトのものと切り替えるというような用途に使われるようです。

となります。

これらのカテゴリは、 CSSを書く際にどこのカテゴリのコードを書くか意識する事で、複雑な絡み合ったコードを避けるためにあります。カテゴリをはっきりと分けることで、コードを共通化させシンプルでメンテナンスしやすいコードが実現できます。本では、それぞれのルールに対して細かな解説があるのでまとめてみました。

ベース

スタイル例:

body, form {
    margin: 0;
    padding: 0;
}

a {
    color: #039;
}

a:hover {
    color: #03F;
}

対象:

bodyタグ、htmlタグ、aタグ、h1タグ..

命名規則:

要素セレクタでのスタイル

説明:

ベースのカテゴリではクラスセレクタやIDセレクタを使わず、要素セレクタでそれぞれの要素のデフォルトの状態を定義します。ベーススタイルには見出しのサイズ、デフォルトリンクスタイル、デフォルトフォントスタイルそしてbodyの背景が含まれます。

要は、bodyタグ、aタグ、h1タグ、h2タグなどのデフォルトのスタイルを定義する部分になります。他のカテゴリでは、html構造への依存を避けるため極力要素セレクタ（ h2指定で直接スタイル）でスタイルを定義したりしないのですが、ベースは例外です。

それぞれの要素のデフォルトのスタイルを定義する必要があるので要素セレクタにスタイルを指定します。

リセットCSSやnormalize CSSはこの層になりますが、本ではリセットCSSは積極的に使用しましょうと言う感じではありませんでした。リセットCSSは一度デフォルトのスタイルを解除して、再度スタイルを定義し直すことになるので読み込むコードが増えますと言うところが懸念点としてあるようです。

レイアウト

スタイル例:

#header, #article, #footer {
    width: 960px;
    margin: auto;
}

#article {
    border: solid #CCC;
    border-width: 1px 0 0;
}

対象:

ヘッダー、フッター、サイドバーなどページを分割する要素

命名規則:

原則IDセレクタ一つでスタイル、クラスセレクタの場合はl-やlayout-のようなprefix（接頭辞）をつける。

説明:

名前の通りレイアウトを定めるカテゴリで、一ページをどのようなセクションに分割するかという部分について定義されます。

ヘッダーやフッターなどの主要なレイアウトはIDタグで定義されることが多いが、それはページ内で本当に繰り返し使用されないことを確認した上でそうすべきで、繰り返される場合はクラスセレクタでスタイルが良いとされています。

これについては、伝統的にそうされてきたかのような記述があるのですがイマイチIDセレクタで指定する必要性があまりわからないですね。。何か深い理由があるのでしょうか。主要なレイアウトとして目立たせる為にIDセレクタとしてスタイルすると言うのはまあわかる気もしますが。

また、基本的にはレイアウトは一つのセレクタで定義されますが、ユーザの権限ごとにレイアウトを変えたいなどの場合もあるのでそう言う場合は下のような複数セレクタでスタイルすることあります。

.l-admin #header { hoge: foo }

命名規則として他のカテゴリと区別する為に、クラスセレクタで指定する場合は先頭にl-やlayout-のようにレイアウトのスタイルであることをわかりやすくする規則があります。

モジュール

スタイル例:

.carousel  > h2 {
    padding: 5px;
}

.carousel  span {
    padding: 5px;
}

対象:

カルーセル、アコーディオンなどなど

命名規則:

IDや要素セレクタを避け、クラスセレクタのみを利用。モジュール内の要素は子・子孫セレクタで指定。

説明:

モジュールはカルセール、アコーディオンなどのスタイルを行うカテゴリです。

命名規則にあるように要素セレクタは極力避ける必要があります。h1,h2など見出しタグはセマンティック性が一定程度あるので、（タグをみただけで見出しなんだなと言う意図がわかる）良いですが、divやspanなど一見して意図がわかりづらいものはクラスセレクタを使ってその意図を補足してやるのが良いです。

<div class="item-list">
     <div class="item">Scissors</div>
     <div class="item">Hammer</div>
     <div class="item">Ruler</div>
</div>

クラスセレクタを使うとスタイルの意図がわかりやすくセマンティック性が保たれるので、クラスセレクタの利用が推奨されています。

また、サブクラスのモジュールを定義する際に場所による制約をスタイルするのは避ける必要があります。

これはあらかじめデフォルトのボタンをスタイルした後に、サイドバーに少しスタイルの違うボタンを設置する場合に、

.pod {
    width: 100%;
}
.pod input[type=text] {
    width: 50%;
}
#sidebar .pod input[type=text] {
    width: 100%;
}

のようにサイドバー内のボタンとして指定するのではなく、

.pod {
    width: 100%;
}
.pod input[type=text] {
    width: 50%;
}
.pod-constrained input[type=text] {
    width: 100%;
}

このようにスタイルして、htmlの要素には

class="btn btn-constrained"

のように指定します。

sidebarのような指定の仕方でも一見問題ないように思えますが、この後にサイドバーやそれ以外にも配置可能ななモジュールを作る場合にベースのpodのスタイルと、サイドバー内のスタイル両方のスタイルを上書きしないといけなくなってしまいます。

レイアウトなどの親要素に依存するモジュールを作成する場合は注意が必要です。場所に依存する（サイドバーの中ののような）スタイルすることを極力されるのが良さそうです。

ステート

スタイル例:

.is-hidden{
    display:none;
}

対象:

モジュール等の状態の指定。表示・非表示。メニューが開いているか閉じているか。

命名規則:

1つのクラスセレクタのみ。
特定のモジュールについてのみ適用される状態であればモジュール名を含める。
利用に注意しながら!importantの利用可

ステートはモジュールの状態を示し、表示・非表示などをスタイルする。

サブモジュールと役割上の類似点があり、混乱を招きがちだが、

1. 状態スタイルはレイアウトやモジュールに割り当てることができ
2. 状態スタイルはJavaScriptに依存するという意味を持つ

といった違いがあります。

2つめがわかりやすくサブモジュールクラスは、htmlがレンダリングされた際に描画されているもので、ステートはユーザのアクションや経過時間などに応じてクラスが付加されたり削除されたりするものです。

テーマ

スタイル例:

.theme-border {
    border-color: purple;
}

.theme-background {
    background: linear-gradient( ... );
}

対象:

テーマでは色やアプリケーションやサイトが持つルック&フィールを定義

命名規則:

テーマの規模によりtheme-などのprefixをつける。

テーマではアプリケーションが持っている他のカテゴリで定義されたデフォルトのボーダーの色などを上書きする。

想定される用途としてユーザー側にいくつかのテーマを決めさせてサイトの雰囲気をユーザ好みにカスタマイズできるようにする場合などがあります。

まとめ

今回は、簡単なカテゴリのルールだけまとめました。電子書籍の中には他の項目についての記載もありますが、まとめるのも大変ですし読み切るのも大変なので紹介はここまでとさせて頂きます。

冒頭でも書きましたが、130ページ程度の本なので自身でも読んでみると良いかと思います。

状態の変更について
適応性の深度
セレクタパフォーマンス

らへんの部分は結構参考になると思います。

本は読むだけでは意味がないのでお次は、実際にSMACSSを意識しながら簡単なページをコーディングしてみたいですね。ちゃんとできたらその様子もアップしたいです。

では

疲れ目・肩こりエンジニアの三種の神器。机上ラック、アイマスク、ブルーライトカットメガネ

Fri, 08 Dec 2017 00:00:00 GMT

エンジニアを悩ます疲れ目・肩こり

エンジニアって本当にずっとPCと向き合ってますよね。エンジニアにとってはPCを使いこなす必要があり、翼くんのようにPCと友達になる必要があります。

友達なんだから長いこと一緒にいないとダメですよね。そうはいっても、本当に集中して何時間もPC画面に向かいっぱなしだと本当に目が疲れて肩もこりますよね。私もちょっと忙しくなって残業したり、家でもプログラミングしたりしている途端に画面が目にしみるようになってきます。

エンジニアの方々でなくても、仕事では必ずPCを見るし、移動中はスマートフォンで記事を読んだり本を読んだり漫画を読んだり。

ジョブスがiPhoneを発表して以来、インターネットに接続する機会も増えましたが、液晶ディスプレイをみている時間も急激に伸びました。仕事にも私生活にも欠かせないPCやスマートフォン、あと何十年働くと考えていても目は大切にしたいですよね。

今回はそんなデジタル社会で快適に暮らすための疲れ目対策必需品を紹介させて頂きます。

正しい姿勢で疲れ目緩和 | 机上ラック

最初に紹介するのが机上ラックです。

これがあると正しい姿勢が身につきますし、ラックの下にちょっとした物を置けるので机が綺麗になります。私も最近これを購入して自宅の机に導入したのですが、ラックの下にちょっとした小物を置けたりして机が綺麗になって本当に導入してみてよかったです。

机上ラックの一番のメリットはディスプレイの位置が座って、背筋を伸ばした時にちょうど良い位置にくることです。

PCの位置が低いとつい屈むような姿勢になり、猫背になって姿勢が悪くなりがちです。そんな時に机上ラックがあると背筋を伸ばしたままPCにむかえます。

PCに向かう姿勢として15度程度下をむくのが良いそうなのですが、ラックがあればPCの高さを保てるのでこの姿勢が取りやすいです。

私としては今の所下に貼った物で満足しています。タイトルに高さ調節可能と書いてありますが、基本的には高くすることができるのみで、低くしたりすることはできません。もっとちゃんと自分にあった高さにしたいというのであれば、モニターアームを購入された方が良いかもしれません。

Fitueyes 机上台モニター台キーボード収納幅600mm 高さ調整可能な透明な DT106006GC

posted with カエレバ

Fitueyes

BESTEK PC モニターアーム液晶ディスプレイアームクランプ式水平多関節 17-27インチ対応 BTSS01BK

楽天市場

7net

posted with カエレバ

BESTEK

楽天市場

7net

疲れ目対策定番 | ブルーライトカットメガネ

お次は、ブルーライトカットメガネです。ブルーライトカットのメガネはエンジニア業というか社会人になってからずっと使っています。寝ているからブルーライトを浴びてるかというような生活をしているので、これは今や私の生活必需品となっています。

PC作業を行なっていると当たり前ですが、目を酷使します。ただ、PCを使わないという選択をすることもできないので、少しでも目の負担を和らげられるように、PCを使うときは常にこのメガネを使用するようにしています。

普通のメガネを使っている、視力は悪くないのでメガネはしていないという方はぜひ目を大切にしてブルーライトカットメガネを使って欲しいです。

ブルーライトカットメガネの有名どころですとJINsPCが有名でしたが、今は新たにデザインされたJINsScreenというモデルがあるそうです。

今更ですが、本当に便利になりましたよね。JINsにはオンラインショップがあって今やメガネもオンラインで購入できてしまうようです。

「度付きのメガネでも変えるの？」という疑問もあると思いますが、度付きの購入方法にはいくつか方法があり

過去にJINSで購入したメガネの保証書を知らせる
使っているメガネを郵送して同じ度数で作ってもらう
眼科やJINSの店舗で度数情報を作る

となるようです。詳細は下記バナーから進んでいただけるとご覧になれるかと思います。

お値段も5000円からあるそうで、最近本当にメガネ安くなりましたね。ちょっと前は二万円とかかかっていたような。。

「ブルーライトカットってあの色付きメガネでしょ・・・」

ときになる点はあるのかもしれませんが、JinsScreenでは従来のものよりより自然に肌に馴染むような色に改善されており、効果そのままで見た目が気にならない工夫もされているようです。

興味のある方はバナーからサイトに進んで見てみてください。

5分でリラックス | ホットアイマスク

最後にオススメするのはホットアイマスクです。

あずきのチカラ目もと用

posted with カエレバ

桐灰化学