Corne Cherry、Mint60に続いてLily58 Proを作りました。
最近毎週末キーボード作ってる気がする。
ひとまず、自分の求める理想のキーボード環境になったように思います。
3個目だから楽勝かと思いきや、表裏逆につけてしまってハンダをとるのに苦戦したり、やっぱりギリギリでした。
ネットではクリア軸がずっと売り切れてたんですが、実店舗ではあったので買いに行ってよかったです。
プログラミングスクールのフィヨルドブートキャンプの提出物のレビューでよく指摘するシリーズ。
可読性の面
可読性（他の人が読んだ時のわかりやすさ）の面から言うと、initialize（初期化）と言える処理のみ書くべきです。
そのクラスがインスタンスになっているとき、そのインスタンスが備えているべき変数の状態などを設定しておくべきです。
newしただけなのに初期化とは言えないことをやっているとそのクラスを使った人はビックリするし、勘違いから事故が起きやすくなる。
機能の面
機能の面から言うと、大抵は受け取った引数からメンバ変数を設定する程度をするのが一般的です。
例えば、newしただけで何か文字を出力してたりすると、そのクラスをテストする時に困る。拡張するときも困る。
printer = Printer.new # ここで画面に何か出ちゃう
assert printer.ready?
自作キーボードにハマってしまって今度は普通のキー配置＋5段のmint60を作りました。
前回作ったCorne Cherryも苦労してなんとかできた感じでしたが2回目だからもう大丈夫だろうと思いきやギリギリでした。
好きなキー配置によってスタビライザーをつける箇所が違うんですが、無駄に多くつけてた状態でほとんどスイッチをはんだ付けしてしまい、危うく詰みそうでした。
なんとか隙間からニッパーでスタビライザーを破壊して取り出したのでなんとか完成。
Corne Cherryは超軽いクリア軸だったので今度は茶軸を試してみました。
やはりクリア軸に慣れたせいか、茶軸はすごく力がいるように感じます。キー配置は数字の段があるとやはり便利。他は右手親指にエンターキーさえ割り振れれば違和感なく使える感じ。
家ではWindowsのゲームPCのキーボードとして使っていこうと思います。
三連休の初日に@takkanmさん主催による自作キーボードの入門のイベントに夫婦で行ってきました。
秋葉原の自作キーボード専門店遊舎工房に行ってキットを買って @takkanmさんや@emorimaさんなどの経験者の方に教わりつつ自作キーボードを作っちゃおうというイベントです。
みなさん（ほとんど@takkanmさん）の作品（と@katsyoshiさん）。
永和さんのオフィスで自作キーボードの種類やスイッチ、キーキャップの説明をしてもらい、みんなで遊舎工房へ。
10人以上いる参加者が全員一度には入れない広さですが、専門店だけあって謎の部品がたくさん売ってました。様々なスイッチが試せて、それがタブレットにつながっていて、押したスイッチの説明と値段がわかる仕組みは便利でした。
僕らが「どのキーキャップがいいかしら？」とちんたらしている横で店員さんに、
「青軸60個ください」
と素早く買い物を済ませる@emorimaさんの玄人感がハンパなかったです。
秋葉原でお昼を済ませたあとは永和さんのオフィスに戻りひたすら半田付け。
初めての人はキー4つの入門に最適なmeishi2 キットを作り、他の人もそれぞれ自分の買ったキットを組み立てていました。
僕もmeishiを先日組み立てたのでCorne Cherryという40%分離型のキーボードにチャレンジしました。
いいゾ～コレ
ものづくり系職種で手先の器用な妻はAttack25というテンキーのキットを詰まらず作り上げていましたが、僕の方は結局三連休をフルに使って最終日の深夜にやっと完成するというありさま。
かなり疲れましたが、何度も動かなくてハマったので完成した時の嬉しさもひとしお😭
1週間程使っていますがクリア軸の軽さと親指での操作の気持ちよさにハマっています。
それもこれも楽しい入門イベントのおかげ。@takkanmさんありがとうございます！
妻はキーキャップを自作し始めているし、僕も早くも次のキーボードを作りたくでウズウズしています。
超楽しかったのでまたキーボードイベントやりたいですね！
これまたフィヨルドブートキャンプで何度も説明しているのでまとめておきます。
getterとsetter
一般的なGetterとSetterについてはこちら：
3.5 GetterとSetter : Javaのオブジェクト指向入門
titleというメンバ変数があった場合、getter, setterを実現するためにget_title set_titleというメソッドを作らなきゃいけないのは冗長。
rubyではアクセサというが、メンバ変数と同名のメソッドができる機能がある。
attr_accessor :title
c#やswiftなどでもプロパティという仕組みで同様のことができる。
public string Title { get; set;}
クラス名、メンバ変数名、メソッド名の原則
- クラス名：名詞
- メンバ変数名：名詞
- メソッド名：動詞
変数の動詞化
見方を変えると、titleにget_titleというメソッドをあてがうというのは変数をメソッド化（＝動詞化）するために無理やりgetを付けていることになる。
メンバ変数のように振る舞うメソッド
rubyではメソッドを呼び出すとき必ずしも()を付ける必要がない。
foo() # カッコあり
foo # カッコなし
これにより、本来動詞であるべきメソッドを名詞にして、カッコなしで呼び出すとメンバ変数であるかのようにみえる。
article = Article.new
article.title # メンバ変数が呼べているように見える
rubyはこれを利用してアクセサを実現している。（c#やswiftでは専用の構文を用意している）
attr_accessor :title
def title
@title
end
def title=(title)
@title = title
end
↑この2つは同じ。
アクセサの考えを自分のプログラムに活用する
これは自分のプログラムにも活用できる。
メソッド名が名詞であって、そういうメンバ変数のアクセサとして動いているように”見えれば”問題ないメソッドになる。
def age
today - birthday
end
user = User.new
user.age # そういうメンバ変数にみえる
実際にはそんなメンバ変数はなく、メソッドがメンバ変数のフリをしているだけだ。クラスを使う人からみれば同じように振る舞うのであれば問題ない。
複雑な処理を整理したいとき、これを使ってなるべくそのクラスのメンバ変数に見える名詞メソッドの形にしてみよう。
たくさんのメンバ変数（に見える名詞メソッド）を扱う少数のメソッドという形になると全体が把握しやすくなる。
何故ならメンバ変数よりメソッドの方が入力・出力・副作用を考えなければ行けないので複雑だから。
メソッド名の原則を外れていてるコードを見たとき
他人のrubyコードを見たとき「メソッドなのに動詞じゃない」と思ったときはこのテクニックが使われてないか考えてみよう。そして自分のコードにも取り入れるとわかりやすいコードになるかもしれない。
宣伝
Rails Girls Tokyo 12thにコーチ件スポンサーとして行ってきました。
今回コーチ応募のがしてたんですが、当日コーチに欠員が出たということで@lime1024さんに
「来い」
と言われて行ってきました。（表現は違います）
スポンサーとしてノベルティやチラシを置くんですが、直前で、
「そういえばブートキャンプが有料化してから初めてだから内容直さないと」
と気づきました。
@y_komacoさんが１日で急いで修正してくれて、良い紙買ってきてコンビニ印刷してくれて非常に助かりました。
スポンサートークの資料は下記に公開しておきます。
ワークショップと各種トークは今回も良い話・良い雰囲気でしたね。オーガナイザーの@lime1024 さんの涙腺崩壊など微笑ましい場面もありつつ、とても楽しかったです。
このエントリーを勝手にまとめました。あまりにも無駄な情報が多く、イライラしたのでやった。
まとめ
株式会社アキュートリリーという有名なエステの会社が給料三ヶ月未払い。健康保険と雇用保険が給料から天引きされているが加入してない。
productionのデータでのみ発生するバグを調査するときなど。
$ dropdb foo_development
$ heroku pg:pull postgresql-foobarbuz-1234 foo_development -a foo
フィヨルドブートキャンプで、オブジェクト指向プログラミングが難しいと感じている人が多いようなので、そこに至るまでの流れを正確さは度外視してざっくりお伝えします。
昔
1 # xxxまでfile読み込みの処理
2 # ...
3 # ...
4 # ...
5 # ...
6
7 goto 1 # read処理の行番号
8
9 goto 101 # write処理の行番号
10
11 goto 201 # delete処理の行番号
同じ処理を呼び出すにはそれが書いてある行へジャンプする命令を呼んでた。
関数の時代
同じ処理をまとめて名前つけて呼び出せたらいいよね。（終わったら自動で戻ってくる）
def file_read(filepath)
# ...
end
def file_write(filepath, data)
# ...
end
def file_delete(filepath)
# ...
end
filepath = "foo.txt"
text = file_read(filepath)
filepath = "bar.txt"
data = "ham egg spam"
file_write(filepath, data)
filepath = "buz.txt"
file_delete(filepath)
「めっちゃ便利！」
モジュールの時代
困ってること1
関数ってめっちゃ便利なんだけど、たくさん増えるとごちゃごちゃになるのよね。イケてるプログラマーは似ている用途の関数を一つのファイルにまとめて呼び出してるけど、みんなそうすればいいのに。
関数時代のイケてるプログラマーのプログラム。
# file.rb
def file_read(filepath)
# ...
end
def file_write(filepath, data)
# ...
end
def file_delete(filepath)
# ...
end
require "file"
filepath = "foo.txt"
text = file_read(filepath)
filepath = "bar.txt"
data = "ham egg spam"
file_write(filepath, data)
filepath = "buz.txt"
file_delete(filepath)
困ってること2
同じ用途の関数をまとめたのはいいけど、必ずセットで使う変数があるんだよね。イケてるプログラマーは変数のprefixを揃えたり、コメントに書いたりしてるけど、みんなそうすればいいのに。
関数時代のイケてるプログラマーのプログラム。
# file.rb
# file_xxx系の関数と一緒につかってネ！
file_path = ""
def file_read(file_path)
# ...
end
def file_write(file_path, data)
# ...
end
def file_delete(file_path)
# ...
end
require "file"
file_path = "foo.txt"
text = file_read(filepath)
file_path = "bar.txt"
data = "ham egg spam"
file_write(filepath, data)
file_path = "buz.txt"
file_delete(filepath)
モジュールの導入
このfile.rbみたいなやつのことみんなモジュールって呼んでるね。モジュラーアプローチとかモジュールプログラミングと呼ぶらしい。
それがやりやすいように言語でもモジュールをサポートしよう！（Modular, Modular-2）
モジュール構文のサポート
# file.rb
Module File
name = ""
def read()
# ...
end
def write(data)
# ...
end
def delete()
# ...
end
end
require "file"
File.path = "foo.txt"
text = File.read()
File.path = "bar.txt"
data = "ham egg spam"
File.write(data)
File.path = "buz.txt"
File.delete()
同じ用途の関数が集まってるってわかるし、変数もそれらと一緒に使うってわかりやすい！嬉しい！
「めっちゃ便利！」
クラスの時代
困っていること
Fileモジュールは便利なんだけど、fileがたくさんあるときに変数の管理が大変なんだよね。
require "file"
paths = ["apple.txt", "orange.txt", "grape.txt"]
paths.each do |path|
File.path = path
puts File.read()
end
これ、それぞれのモジュール（変数）を別個のものとして持ち歩けたら便利なのになあ。
files = [File, File, File]
こういう感じにできたら似た処理をする変数と関数一式を持ち歩けて便利なのになあ。
クラス・オブジェクトの導入
クラスを雛形として書いて、newするとそれぞれ別個のものとして持ち歩けるよ！（Simula, C++）
# file
Class File
@name = ""
def initialize(name)
@name = name
end
def read()
# ...
end
def write(data)
# ...
end
def delete()
# ...
end
end
require "file"
paths = ["apple.txt", "orange.txt", "grape.txt"]
files = []
paths.each do |path|
files << File.new(path)
end
puts files # => [#<File:apple.txt>, <File:orange.txt> #<File:grape.txt>]
「めっちゃ便利！」
宣伝
フィヨルドブートキャンプでいつも話すのでここに書いておきます。
入りたい会社が無い
勉強を始めたばかりで、
「プログラマーとしてどういう会社に入りたい？」
と聞かれても特に無くて当然だと思う。
会社のホームページや求人サイトに書かれるパブリックな情報は良いことしか書いてないし、将来性とか言われてもピンとこない。
せいぜい「ブラックじゃない会社が良い」「給料の高い会社が良い」とか。
おすすめの探し方
おすすめの探し方はプログラミング関係のイベントに色々行って、どこかのコミュニティに属してみることです。（プログラマ自身が主催してるところがいい）
コミュニティに属すると「こういうプログラマーになりたい」とか「この人と一緒に働けたらいいな」とか「この評判のいい会社で働きたい」など、自然と自分の中に好き嫌いができてきます。
普通の社会人は自社の悪口を社外で言わないものらしいですが、（僕を含めて）現場のプログラマーはイベントや懇親会で普通に悪いところも話しがちです😭
悪いところを含めて色んな会社のリアルな情報が聞けるので、コミュニティ内での会社の評判というのは概ね現実に即しているという印象です。
イベントに行く前に
そもそもある程度プログラミングの知識が無いとイベントに行っても話される意味がさっぱりでクッソつまらないのでいきなり行くのはおすすめしません。
rubyやrailsを噛り始めたぐらいで行き始めるのがおすすめ。
イベントの探し方
イベントの探し方はrubyだったら近所の地域rubyコミュニティを探してみるか、connpassで自分の使ってる技術で検索してみると良いと思います。