西脇.rb&神戸.rb と Tokushima.rb を週末はしごしてきた
地方エンジニアのインプット機会の不足がどうこう言われたりしていますが、気合と少しのお金があれば増やす事もできます。（いや、できればお金はもっと抑えたい。。）
愛媛の勉強会には何度かお邪魔していましたが、今回初めて四国を飛び出して行ってきました。
西脇.rb&神戸.rb Rubyistのための英語勉強会 ～英語の読み書きスキルを高めて開発に活かそう～
nishiwaki-koberb.doorkeeper.jp
最近、英語に関しては公私ともに課題感を感じていたので「これは！」と思い参加しました。大事なことなので最初に書きますが、 めちゃめちゃ良かったです！
内容
メモもちょこちょこ取っていたのですが、最初から議事録取る人の指名があり、当日中には全ての資料系も公開されるという運営すごすぎ事案があったので、僕のメモ要らないなという事でリンクだけ貼らせていただきます。
当日のタイムテーブルも割りと決まっていたり、アイスブレイクあったりですごいなぁーと感心しきりでありました。自分でやる時も参考にしたい。いや、ゆるいのも大好きなんですけどね。
感想
プログラマの英語勉強方法
ほとんど議事録と被りますので、特に頭に残った部分だけ。
「まずは Listening！そして Speaking ! あとカタカナはダメ！」 ということらしい。
これは全部関連があって、聞くのが大事、でも発声できない音は聞けないから声に出すのも大事、そしてそれはカタカナで発音を覚えないための事でもある。
カタカナはホントにダメってのが面白くて、日本語の 50 音は「ん」以外は母音で終わるのだけど、英語の発音記号は子音で終わることが多い。つまり、そもそもカタカナで表すのは不可能ということ。（これ全然分かってなかった。）
加えて、有声子音と無声子音（喉が震えるか震えないか）が分かると、複数形の発音が「ス」か「ズ」かは考えなくても分かるようになると。（喉が震えるならズの方が言いやすい）
英英辞書の使い方 も面白くて、「知ってる単語を調べることに使う」のが大事らしい。和英で調べると意味が出てくるだけだけど、英英辞書だと、その単語のもつニュアンスが分かるのでイメージでも覚えられる。後、例文が平易なものが多いので、単語がパッと分からない時に、知っている単語で説明するための練習にもなるとか。
ここで、Ruby で for でダラダラ書くのが初心者、map 等でスッキリ書くのがわかってる人みたいな感じで英語でも、伝わるけど長ったらしい文章を書く人と、スッキリ書ける人の差が出るらしい。でも、ダラダラした文章でもまずは伝わる事が大事だから、そういう文章も書けるようになるのが大事なんだなと。
それから 自動翻訳はまだお前らには早過ぎる問題 ですね。。やりがちですが。 たまに海外のWeb サービスから自動翻訳っぽいメールが来たりするけど、自分たちも自動翻訳使うと同じようになってる可能性が高いと。最低そこの見分けがつくようになってから使うぐらいがちょうどいい的な心の痛む話しでした。
で、最近はスペルチェッカーツールが優秀だから、まずは分かる範囲で自分で作文してみて、チェックさせることにチャレンジしてみてはというのも、なるほどなーと思った。
命名やコミットログを書くプロセス
後半の実践編は、実際のアプリケーションの issue を解決する事をお題に、その中で発生する命名を問題にして回答する形でした。
英語での命名ももちろん面白かったのですが、ちょっとした名前付けも本当に各チーム、各メンバーがいろんな意見を持っていて、そのメソッドが持つべき意味みたいのもしっかり考えてる人が多くて感心しました。 コードレビューは一般的になりましたが、なかなかそこまで行くための思考プロセスって可視化されないし、お仕事の中でもそこまでやらないので、勉強になったし楽しかった。
もろもろ
県外勢の辛みで、懇親会はゆっくりできなかったのですが、いろいろお話させてもらって「来てよかった！」と心から思える勉強会でした。運営の皆さんの努力はもちろんなのですが、参加者の方もフレンドリーな雰囲気ですごく違和感なく入っていけました。
「子供できたら動けない」という話しばかり聞いたので、自分も再来月からはどうなるのかなぁと思いつつ、またタイミング見つけて参加したいなと思います！
第十三回 Tokushima.rb
案の定前日の疲れが抜けず朝寝坊しての参戦となりました＞＜
たくさん発表があった！
いつもはもくもく会風なのですが、今回は結構みなさんの LT 風の発表が聞けました！もくもくしてる最中に「ちょっとこんなネタが、、」でその人のパソコンに集まれるのはいいなーと思いました。
一本目は私が前日のイベントで聞いた英語勉強法のネタをまとめたものを軽く発表。みんなそんな得意じゃないと言いつつ、実際 Weblio の語彙数テストも普通だったのですが、「洋書とか読み進めるよー」と英語をあんまり怖がっていないのが印象的でした。そういうマインドすごい大事ですね！
二本目は @ka_ さんの ElixirとPhoenixの紹介 でした！ちょっと Elixir 速すぎじゃないかという驚き。しかももう実戦投入してるとこあるのかよと。
三本目は @sunny4381 さんから、とくしまOSS普及協議会と一緒にやっている Ruby講座の次回版資料をひと足お先に見せてもらいました。 初心者向け（？）なんだと思いますが、capybara と Selenium 使って、しかも vagrant で立ち上げたサーバーに対して End2End テストを書くという、密度の高い資料でした。さすがに 30 分の講義じゃ無理じゃないか！
四本目は再び @ka_ さんから rubicure_fuzzy_match を通した、fuzzy_match のご紹介！全然知らなかったライブラリだったのですが、使えそうな予感が。そして、ka_ さんは「カジュアルに gem を作る」ことに開眼したらしい。gem を作る動機になる課題を発見できるぐらいコードを書いてるということにただただ感服でございます。
将来に向けた取り組みのお話
tokushima.rb ファウンダーの野原さんから、次の徳島で行われる OSC を皮切りに、県外の学生やエンジニアも来てくれるようなジャンルを縛らないテックイベントを定期的に開催したいという構想が語られました。まだこれからな部分も多いようですが、わくわくしますね。（里帰り出産の関係で立ち上げ時期に徳島に居られないのが残念ですが）
次回の tokushima.rb (9/27) でも詳細のお話あるそうなので、興味が有る方は参加されてはいかがでしょうか！
神山.rb 第二回を開催します！
最後は宣伝で。
来る 9/21(月) のシルバーウィークまっただ中に一年ぶりの神山.rb を開催します。
今回は前回の予告（？）通り、負の成分多めのリモートワーク話しも挟もうと思い、リモートワークでも有名な HeartRails さんから数名の方が参加してくれる予定です。
（西脇.rb&神戸.rb の方も来てくれないかなぁなどと妄想しておりますが、まあいかんせん徳島遠い。。遠すぎるよ。。）
もしも遠方から来られる方は、私の自宅に泊まっていただくこともできますので（借りてる家は結構大きいので）、お気軽って訳にもいかないと思いますが、参加登録時にメッセージを書いていただければなと思います。懇親会は美味しいオーガニックワインのお店を予約しておりますので、是非そこまで居ていただければなぁと思います。（無料ではありませんが）
神山町わたしたちの「まち・ひと・しごと」を考える集いに参加してきた
神山町役場 | わたしたちの「まち・ひと・しごと」を考える集い
7/25 に私が住んでいる徳島県神山町で開催されたフォーラムに参加してきたので、感想がてらメモを。
セッション1: 「地域の未来を変える高校の可能性」
進行役の西村さんの導入部分
今日は島根海士町の豊田庄吾さんのお話を聞く
海士町は10年前から I ターンが増加、人口推移は減少がストップ その中でも隠岐島前高校は生徒数が 2009 年から増加傾向。2学級に増えた。
海士町も十分貧しい。その貧しさが光になればという時間。
「まち・ひと・しごと総合戦略」の説明
ここで、神山町が今取り組んでいる「まち・ひと・しごと総合戦略」の話し。
2020 年度までの目標・基本的方向・具体的な施策を本年度中に検討・策定する。
これまでのよくあるパターンだったコンサルタントに丸投げしたり、大学の偉い先生に任せたり、行政主導でやるのではなく、地域の人たちで未来を作ろう的な企画のようだ。
一次締め切り 10 月。（もう出してるところもあるとか。）
総合計画とは異なり、網羅性は求められていない。
この辺の話しなのかな
「人口減少」と「仕事づくり」の２つに関して、どういう目標を地域として持ちますか？という投げかけらしい。
神山では「子育て」「働き盛」の２つの世代で 30 名程の working group を作って進めているようだ。
地域の未来
学校が無いと、子育て世代が住めなくなる。
一方国は、学校の統廃合の基準を厳しくした。。。。文科省レベルでは地方に人がいられない状況にしていっている。
神山でも今まさにそのテーマだろう。
学校のあり方は地域の未来にどうつながるのか？
経営視点で見れば、縮小は仕方ないと思う。でも、だからこそ、（無くなるも含めた）選択権を地方に委ねたのだろうか？と思ったり。
ここから豊田さんにバトンタッチ
「地域の未来を変える高校の可能性」
神山のすごい話しをたくさん聞いていて、来るのが怖かったらしい。。 一瞬だけど神山で「この風景は次の世代に残したい」と思ってくれたらしい。
成功はしてないし、今でももがいている。すごく必死。今でも海士町は挑戦事例。
魅力化構想 から 新魅力化構想
高校だけでなく、地域も含めた永久の魅力化のため
問題意識と地域の課題
経歴: Recruit -> ウィルシード（企業向けの人材育成）
問題意識: 自立した人材、社会で必要とされる人材育成の不足
-> 学歴偏重の勘違い人材が多くなってきた
-> 中高のうちから教育していければ
新しい問題意識: 自立した地域とは？この地域は存続するのか？
-> 財政難
-> 後継者不足
教育の課題
隠岐島前高校が統廃合の危機
島根は１学年21名切るのが３年続くと廃校。そして 28 名まで減った。
海士町からは本土の高校に通うのは無理。つまり学生がいなくなる。船だと３時間半かかるので下宿必須。仕送り代も当然辛い。
学費もしんどくなるので、子供が高校出るところで、親世代も一緒に本土に移住ケースが出てくる。
子供・その親世代がいなくなり、文化の継承も辛い。
当時の学校の状況: 図書館入れない。物理の先生いないので学べない。
県教育委員会は？
-> つぶす基準は作るけど、活性化策は作らない。（経済的にも統廃合を推進したい）
-> 県管轄なのに自治体から口を出したので嫌な目で見られた
元々は「存続プロジェクト」という名前だったが、それは「存続しない」場所と言っているようなもので、そんな所にいかせたくないですよね。
-> 魅力がある学校にいかせたいよね。それは地域も同じでそういう地域に移住したいはず。
-> よって「魅力化プロジェクト」という名前にした。
当時の不良学生が今の親世代。彼らは自分達の学校にいかせたくないと思っている。
-> 寮が 4/56 で800万赤字
地方での高校説明会もしたが、（たぶん怪しく見られて）説明会会場に集まる人もゼロだった。。
やったこと
魅力化の会を作った（エラい人も入れて）
数値目標を作った - 島前地域からの入学率増加 - 地域外からの入学数増加
下部組織でワーキンググループを作りビジョン策定。
進学塾を作り、学校と組ませて学力を上げる。
-> でもこれだけだと後発感は否めない。
-> 新たにまちづくりコースを高校に作った。今で言う地方創世リーダーを育成する。
どんな人が必要か？
-> 地域で新たな生業・継業を作り出せる人
-> 仕事が無いから帰れないではなく、仕事を作りに帰ってくる
島には何もないけど、、、
-> 人口減少・高齢化・財政難の最前線、課題だらけ。ここで学べば未来を拓く力になる。
-> 「機会・想い・仲間」がある
そういう想いに共感してくれる親から子供を預けてくれる人が出てきた。
人が人を呼ぶ循環が生まれてきている
足りない学習部分は skype とか使ってる
夢ゼミ: 塾の中でやっている
-> 自分と違う考えの人間を受け入れて話しができる力
-> 例えば農業の人に来てもらって、みんなでどうやったら変えられるかを考える。
-> 「リアルな体験」を重視したゼミ形式の授業。
-> Skype でいろんな人とつなげる。
-> 天才畜産少年が現れた。慶応SFCで研究中。
「自分がやりたい x 地域軸での縁」を考える。
建物も「継承」したいので、新校舎も築100年の古民家をリノベーション。
僻地の若者に生じやすい傾向
- 価値観の同質化
- 関係性の固定化
- 刺激や競争の（忘れた。。）
全国からある意味の脱藩生を募集。
今では新入生の５割が島外から入学（ついには海外からも）
これまでは、統一価値基準で（経済・教育）において東京に追いつけ追い越せだった
-> もう外に出す教育はいらないのでは？（結果過疎を招いたよね？）
東京は素晴らしい、じゃあ田舎はダメなんだろうか？
産業だけでなく、教育もブランド化できるのではないだろうか？
学校が人気になったが島民は余裕で受かるので、教育移住が始まった。
「S ターン」をしたいという子の出現。一度島外から島に高校に入学し縁を作った後に県外で学び、また島に帰って仕事をする。
<<休憩挟んで後半>>
これからの学校に必要なこと
高校の役割の再定義
-> 学力を身に付ける事？？ -> これは手段でしかない。
-> 目的は地域の担い手を作る
出口を押さえる
-> 島で言えば、島の最高教育機関が高校（つまり出口）
-> 小中でふるさと教育をしたのに、高校で急に点数の世界に追い落とされてしまう。。
-> よって、高校で地域に戻る選択肢をきっちり提示したい
グローカル教育
-> 高度成長と侍読可能という２つの切り口
-> 持続可能は田舎にこそある
-> 片方ではなく、両方の目線を持てるようにする。（ローカルの方だけ持てという事ではない）
- 地域エンゲージメント
- グローカルセンス
- 志（利己と利他の両方の中で使命感や覚悟を伴うもの）
- 学習力（自分だけでなく、チームや組織で学び続ける。素直・謙虚）
- 社会力
（他にもあったけどメモれず。。）
現実を直視する
-> 都会でも起業は難しいのに、田舎でどうするの？
-> コーホート図で現実を見るのは辛いけど、、
郷土愛を育てる
-> 将来地域と関わりたいと思ってくれる人材を育成する
-> 戻ってくるだけが選択しではない。あくまで郷土に関わってくれるだけでいい。
-> 祭りの時に帰ってくるだけでもいいのだと思う
-> 自然体験、地域の人・歴史との関わり
-> 順番的には、「まず好きになってもらう」「次に厳しい現実を診てもらう」がいいかもしれない
-> 外の人間が地域のいいところを言ってあげればいいよ（または関わる）
画一化された統廃合の基準からSSS, SMSへ
-> super small school, super magnet school（小さくても魅力のある学校、IT や地域の人に協力を得ながら）
まちづくりとの接続
コーディネーターの必要性
-> 両者の言語を理解できる人が必要。現場と熱い人が一緒になるとぶつかってしまう
-> 対立構造を作らない三方良しとかんがえられる人。コミュニケーション、巻き込む力。（一人ではなく、チームでその要件が満たされればいい）
「志を果たして帰る」から「志を果たしに還る」ひとづくりへ
僕は会社に関係を作ってもらったんだなぁ。
川の音を聞いて寝れる。確かに最初はいいなと思った気がする。
「僻地に魅力が無い」は大人の見方、都合だろう。その目を子供に押し付けるべきではないよね。
パネル「神山の地方創生にむけて」
教育資源
豊田さん: 「僕が住んでたらいろいろやりたい」ぐらい神山にはいろいろ揃ってるように見える
人、挑戦出来る環境、まちづくりを学べる学校を作れば、ほっといても外から来るのではないか？
メンバーも揃ってる。
ハードルの高さ
大南さん:
まちづくりをテーマにした学校を作るのはすぐにできるだろう。
-> 人材もいるし、実際、神山塾もあった。
-> しかし今神山に住んでいる人は、そのテーマの学校でいいと思っているか？
-> 大学に行かせたいと思ってる人もいるのでは？
-> じゃあ、どういう方向に学校を向けていきますか？
-> 何のための学校？まちづくり？大学に行かせたい？
西村さん：今の子供は私達の知らない仕事に付いているだろう
-> 入試はどうかわっていくだろう。学力だろうか。求められる人材像は？
-> 大都市と田舎で働く人材層が近づいていくのでは？
-> 入試も変わっていくのではないだろうか？
-> 海士町の地域想像コースをやってみて、どういう人材が現れるかはわからないのでは？
-> 海士町すらも、最初は「勉強を教えてくれ」「いい大学にいかせてくれ」だった。
私立化する気はなかった？
豊田さん:
公教育をよくする事にこだわりたかった。
-> 私立はお金を払えばいくらでもいい先生よんでやれる
-> お金がなくても同じように素晴らしい教育を
公立校を変えるには？
仕組みを壊して作り変えるのか？
豊田さん:
壊すよりも結果を出す事に執念は燃やしていた。
-> 公教育の方が地域の人の協力を得やすい。地域の未来を考えるには必要。
名古屋のエリート教育学校の話し（経済界が威信をかけて）
-> 外交官は作れても、地域の担い手は作れない
宮崎の中高一貫校（宮崎が威信をかけて）
-> エリート校を山奥に作っただけで、その村の人は 240 人中 6 人しかいない。。
-> その地域の未来の担い手は少ない
今は県立をやめようかと思ってる
-> 県立は管理職の権限を県がもっていてうざい
-> なので、市町村立か国立にできないか？
-> 島根大学と共同でやろうとしてる
その他には、海士町は町長のパワーで国からの資金も入っていてサステナブルではないのでは？ という質問も出ていました。これに関しては実際課題だということらしい。
最後は町長の話で締め。
所感とか
ちょうど神山では、中学校の統廃合が決まって、ついに中学校が１つになることが決まった矢先だったので、（もちろんそれを狙っての人選でもあったののだろうけど）タイムリーで考えやすいお題だったと思う。
一学年何人を割ったら廃校になるとか、全然しらない事だったし、神山では昔から中学校ぐらいからは下宿したり寮に入ったりが普通だったと聞いて、自分が住んでいた場所は恵まれていたのだなぁとしみじみ。（高校も自転車で行けるレベルだった）
既に自分が住んでいる場所から一番近い小学校は廃校になっているので、自分の子供が小学校に入る時には、車かスクールバス（があれば）を使うしかない。確かに子供の教育とかを考えれば、「じゃあ、子供が小学校に入るタイミングで、町に移住しよう」となるのはごくごく自然な発想な気がする。
結構そういう意味では、神山は過疎のステージがだいぶ進みきっている感じがしなくも無い。
で、じゃあ、どうしますかってお題ではあったので、興味深いテーマだった。
求められる人材と、そのための教育に力を入れること
パネルの神山に関する話の中で「まちづくりのための教育機関」としての学校を作ればみたいな話が出ていた。教育ではなく、仕事に目を向けても地方というか田舎で仕事をするためには、ある程度ユニークな事であったりニッチな事であったりが有利なのだと思う。（どれぐらいの範囲でユニークなのかはさておき。）
じゃあ、教育も「そこでしか学べない」とか「未来の日本の最前線で学べる」とかは、「決してマジョリティではないけど、確かに存在する層」に向けてはいいメッセージだし、海士町のように地域外から生徒が集まる可能性だってあると思う。
すごく個人的には、人の流動性がある地域でもいいとは思う。一生定住が人口増の絶対解では無いと思うし、教育を受けさせたい間だけ、家族ごと移住してくれるだけでもいいのではと思ったりもする。逆に言えば、代わりに、神山で生まれているが都会の大学に出て行く人はまあ止められないし、停める理由も無いよなぁと。
海士町はそこで「高校という出口をおさえる」みたいな取り組みまで見通していて、「地域の担い手」が残ること、戻ってくれることまで含んでいるというのは面白いなぁと思う。
そして、いろいろとロジカルな内容も出てくる中で最後が「郷土愛」「ふるさと教育」に行き着いていくというのも、また１つ興味深い内容だった。
ふるさと教育って何？
町長も「ふるさと教育が大事」と言っていたが、、一体それは何なのだと。
島根県：ふるさと教育とは（トップ / 子育て・教育 / 教育・学習 / 生涯学習・社会教育 / ふるさと教育推進事業）
- 地域
- 地域住民のふるさとへの理解促進
- 地域を支える次世代の育成
- 学校
- ふるさとへの愛着や誇りの醸成
- 地域に貢献しようとする意欲の喚起
島根県からの引用は上記。実際どんな事をやっているのかは、徳島の上勝がけっこうレポートをあげてくれている。
低学年のうちは、見学や、野菜やカカシを作ったりという感じだが、高学年になるにつれて、実際にふるさとをどうしていくかというのを考えていく事もやっていくらしい。なるほどー、って、たぶん自分もやっているんだろうけど全く記憶に無いです。。
実際私が小さかった頃は、学力全ての時代でしたし、私も進学校に進んで大学に行くしか無いと思っていたので、ふるさと教育なんかなんにも残らなかったのかもしれません。
今回の話にもあったように、今後必要になる人材が変わっていったり、地域の担い手の重要性が高まるに連れて、教育も変わっていき、こういうふるさと教育のあり方、やり方も変わっていくのかなぁと。まあ、この辺は定量化ができなから難しいですよねぇ、、実際私も東京に出て初めて「徳島良かったんだなぁ」と気づいたりしたし、やっぱり人それぞれに志向性は違うし。
それでも、例えば自分が住んでいた地域への愛着があるかって言ったら違うんだよなぁと思ったりで、ますます「効果的なふるさと教育」へのイメージが沸かなかったであった。
自分と神山町とのポジションに関して
この集いは地元の人もたくさん来ていて、ポイントポイントでディスカッションの時間があったりもしたのですが、正直あまりこのテーマで話せる事はありませんでした。。（なんか、世間話しかしなかった。）
神山で教育を受けた事があるわけでもなく、まだ自分の子供を教育に送り出すのは先というのもあり、このテーマへの危機感がまだ足りていないのだろうなと思います。
加えて言えば、まだ「町としての神山」と捉えられてはいないのだなと。まだどこか、東京のアパートに住んでいる時と同じような感覚が残っているのだろうなと思いつつ、少しずつ変わっていければと思ったりしました。
第十二回Tokushima.rb（一周年記念）に参加してきた
第十二回Tokushima.rb（一周年記念） | Facebook
5, 6 月と予定が合わずいけていなかったので4 月以来の参加でした。
Rails5 をぼちぼち見始める
とっかかりとして、Action Cable と Turbolinks 3 あたりから見ていく事にしました。（別 gem になっていて見やすかったのもありますがが）
その場に居た人と少し話した内容としては、こういう JavaScript が絡む部分はどうするのが正解なのかなぁという所でした。 AngularJS や React.js の話題は尽きませんし、ES6 の話も出てきたものの Sprockets との絡みは依然としてあって、でも Rails としては Turbolinks の更新をしてきた訳で、スタンダードはどこに落ち着くんだろうなぁと。（なんか提示されるの待ちでいまいちですね。。tokushima.rb の方は Node.js で JavaScript / CSS はビルドして載せるような方法も取ったことあるみたいです。SCSS のSourcemap 周りで困ったことがあったとか。）
elixir ことはじめ
ka さんのススメで elixir 入門を少しやってみました。といってもインストールと Getting Start を進められるところまでみたいな感じでした。
確かに Ruby ぽい感じでかけて、例えば String のメソッドあたりを眺めても、意識されてるのがすごくよく分かる感じです。
まだ少ししか見れてない中で個人的に「お」となったのは、size と length メソッドが実装内容で使い分けられてる部分と and/or と &&/|| operator の違いとかでした。operator は結構多くて、まだ全然見切れてない。。
後は、パターンマッチの使い方が最初は「？？」状態でした 。以下の記事でなんとか理解。
所感
触ってみようかなと思ったのは ka さんが紹介してくれた以下の記事が発端でした。
個人ならともかくお仕事でやってると、技術選定してる時間とか、上司を説得する時間とか無いので、何でも Rails でとなってしまうのですが、ちゃんと使い分けられる部分は使い分けないとなーというところでしょうか。（そのためにも、日頃からいろいろ試さないとなぁ。）
その中でも、elixir は取っ付き易くて良さそうに思いました。（なんて軽い感想なんだ。。）
a_matsuda さん登場
Ruby/Rails コミッタの松田明さんが午後から参戦してくださいました。
なんかどこまでオフレコなのか全然分からない深い内容も入ってたので、全部は書けないのですが、
- Asakura.rb のなりたちの話
- 去年の rebuildfm でお話されてたような Seattle.rb の話とか
- 1.8.5 あたりからの Ruby のリリースに関する話
- 世界各地の RubyConf の話とRubyKaigi の話
- US/EU/JP の RubyConf の成り立ちとか現在の話とか
- MountainWest RubyConf 2015: MountainWest RubyConf 2015 から始まったRegional RubyConf の話とか
- Ruby on Ales 2015 の立ち上げの話とか、朝 9 時から飲み始めるカンファレンスの話とかｗ
- 最近の RubyConf とか RailsConf は技術ネタ少なすぎでは、、とか。（でも RubyKaigi はいっぱいだよ、とか！）
- RubyKaigi, regional ruby 会議, asakusa.rb の話とか
- 最近はカンファレンス運営はめんどうな事も多いとか。。
と、松田さんからしか聞けないような超濃い話をしてくれたかと思えば、そこからは、最近の各地のカンファレンスでトークされた内容をスライドを高速にめくりながら再演してくれたり！これはすごいありがたかったし、スライド眺めるだけでは分からなかった事がたくさん分かった！
特に、template engine の話と、Cookpad の話はめちゃ勉強になりました！
松田さんには久しぶりにお会いしたのですが、ホントとても素敵な人だなぁと改めて感動したのでした。
貴重な場を作ってくださった Tokushima.rb の皆様、本当にありがとうございました！！
掘りごたつワークのススメ
いつもはログハウスみたいな部屋にこもってバランスボールに座って仕事してるのだけど、工事で部屋を追われた関係で掘りごたつで仕事してたら思いの外良かったのでオススメしてみる。
とはいえ、スタンディング以上に DIY が大変そう。。。
机の感じ
古いコタツなので、ディスプレイ（22インチぐらい？）とキーボード置くとほぼ机の半分以上が埋まる。正直東京時代のデスクより横幅は狭い。。
でも、ティッシュとか、本とかは適当に周りに放置できるので机自体はすっきりするかもしれない。
引きの画
割りと風が通る部屋なので自宅から風鈴とか持ってきて置いてみた。
オフィスのこの棟には自分しか居ないので、Apple Music の適当な playlist を一日中イヤホン無しで流してるのだが、たまに鳴る風鈴は悪くない。
メリット
いつでも仰向けで寝れる
実際寝る事はあまり無いと言っておくが、背伸びついでに座椅子の背もたれを倒すとそのまま寝転がれるのはかなりリラックスできる。これは、通常の机とチェアでは不可能なので結構なメリットだと思う。
足の裏が床に着く
足が長くないのと、普段使っている机の高さが変えられないので、いつも床に足の裏がつかない。自分の体質かもしれないが、長時間座っていると太ももの裏が痛くなったり、足がだるくなったりする。
掘りごたつは昔の人用なのか足が簡単に床につくので気持ち疲れが少ない気がする。コタツの中にクッションを置くと足置きにもなって伸ばす事もできる。
ホワイトボードが使いやすい
脳内メモリが少ないせいかプログラミングしてるとすぐに落書きしたくなるのでホワイトボードはよく使うのだけど、掘りごたつだと座ってる場所が要は通常の床なので、ホワイトボードを広い床に置いてそのまま書くことができる。
いつもの机とチェアだと、どうしても机を片してホワイトボードを置くか、小さいホワイトボードを用意したりするか、はたまた違う部屋で地べたに座ってやるかになるのでめんどいのだが、その点が劇的に改善される。
デメリット
座椅子
まあ、会社支給のチェアやバランスボールに比べるとやはり腰への負担はある。けれど先ほどの足の裏を接地できるのと相殺されているのか、そこまでデメリットと感じなかった。
正直普通のコタツで仕事したりすると、1 時間ももたないので、足の裏が接地できるのは全然違うと思う。
終わりに
プログラマのような長時間座っているような職種は、やはり椅子やそれに変わるスタンディングやバランスボールが必要だなと思っていたけど、意外にも古い家にある掘りごたつがフィットしたという発見。
まあ、とりあえず長時間働かないのが一番なので、それをオススメします。（自分はできてないけど。。）
スタンディングは
まだ一日中できないですけどこちらも悪く無いです。足の接地面をどうするかがまだ課題ですけど、身体が自由に動くので楽。
私はこいつを使ってますが、まあまあ安定するのでオススメです。
AASM を使ってみた。主に Callback。
STATESMAN を使ってみたかったのだけど、使いたかったシーンが state を持ったテーブル１つだったので、ちょっと STATESMAN だと冗長だったので断念。
AASM
The Ruby Toolbox - State Machines
state machine カテゴリでは 2 位で、今でも開発は行われているようなので良さそうに見える。
日本語の解説記事も発見。
使ってみる
対象
ActiveRecord Enum を使って status というカラムを列挙型として使っているモデルがあるとします。
class Task < ActiveRecord::Base enum status: {opened: 0, assigned: 1, rejected: 2, finished: 3} end
このステータスは、それぞれ遷移する順序があるという場合です。
state の設定
https://github.com/aasm/aasm#activerecord-enums
AASM は標準で ActiveRecord Enum を上手く扱えます。ポイントは column: enum名 と指定するところです。今回は enum が integer のカラムなので enum: true というオプションを省略できる。
class Task < ActiveRecord::Base include AASM enum status: {opened: 0, assigned: 1, rejected: 2, finished: 3} aasm column: :status do state :opened, initial: true state :assigned state :rejected state :finished end end
event と transition の指定
class Task < ActiveRecord::Base include AASM enum status: {opened: 0, assigned: 1, rejected: 2, finished: 3} aasm column: :status do state :opened, initial: true state :assigned state :rejected state :finished event :assign do transitions from: :opened, to: :assigned end event :reject do transitions from: %i(opened assigned), to: :rejected end event :finish do transitions from: :assigned, to: :finished end end end
ここは特に説明不要ですかね。
Callback を指定してみる
https://github.com/aasm/aasm#callbacks
以下の順序と関連を押さえておけばなんとなく大丈夫かと。
begin event before event guards transition guards old_state before_exit old_state exit transition after new_state before_enter new_state enter ...update state... event success # if persist successful old_state after_exit new_state after_enter event after rescue event error end
aasm/callbacks_spec.rb at master · aasm/aasm · GitHub
Callback のテストを見ると、順序、設定場所、渡ってくる引数がわかりやすい。
class Task < ActiveRecord::Base include AASM enum status: {opened: 0, assigned: 1, rejected: 2, finished: 3} aasm column: :status do state :opened, initial: true state :assigned state :rejected, after_enter: :after_enter_rejected state :finished, after_enter: :after_enter_finished event :assign do transitions from: :opened, to: :assigned do after do |user| self.user = user self.assigned_at = Time.zone.now end end end event :reject do transitions from: %i(opened assigned), to: :rejected end event :finish do transitions from: :assigned, to: :finished end end def after_enter_rejected # reject 時の処理 end def after_enter_finished # finish 時の処理 end end
今回の特殊な点として、assign 時に一緒にアサインされたユーザーと、アサイン時刻を記録したかったので、transition に対する after callback を指定した。
transition after callback は名前は after だが、status の値の更新前に実行されるので、結果的に UPDATE 文が１つにできる。もちろん、status の更新が不可能な状態ならば実行されない。
task = Task.create task.opened? # => true task.assign!(current_user) task.assigned? # => true task.user # => current_user # ダメな場合 task.update(status: 3, user_id: nil) task.may_assign? # => false task.assign!(current_user) # => AASM::InvalidTransition task.user # => nil
Transaction 使えばもっとキレイにかけるのかなぁ。 https://github.com/aasm/aasm#transaction-support
結局もう一度 save するのか。
aasm/validator.rb at 44a17aa5357d60e20cbd1a5da4a27063e113ffa2 · aasm/aasm · GitHub
#
今回は Guards に関しては利用用途が無かったのだが、いろいろできそうなのでまた調べたい。
Auto Layout を設定する時に使いそうな Xcode の画面のメモ
慣れない IDE は、慣れるまでが大変ですね。。いろいろ高機能になっているせいか、6 年前に Eclipse から Visual Studio に移った時よりもしんどさを感じる。。
とりあえず使いそうな部分だけ
- イシューナビゲータで問題があるか確認できる
- Dock でエラーの詳細を確認できる
- Canvas エリアの下でサイズクラスと制約に関する設定ができる
- サイズインスペクター内で制約の閲覧と設定ができる
きっと他にもある。。
Align, Pin, Resolve Auto Layout Issue
Auto Layout 関連はだいたいここから設定できる。Editor メニューからもできる。
制約を直接編集
サイズインスペクターからでなくても編集できる
Dock 内でエラーを確認
赤いボタンを押したら一気に解決してくれたりする
サイズクラスを指定する場合に使う
まだ良くわかりません
#
こういうのに疲れるとコードで指定するようになるんですかね。。
Ruby でもメソッドをブロックの代わりに渡したい
C# でコードを書いていると以下のようなコードを R# がよく薦めてきます。（久しぶりに C# 書いたけど、これで合ってるかな。。）
// 前提
var list = new[] {1, 2, 3, 4};
private int Method(int) {
// なんか処理して int を返す
}
// before
list.Select(x => Method(x));
// after
list.Select(Method);
ここで使ってる Select は IEnumerable のメソッドですが、引数は System.Func<TSource, TResult> の delegate となっています。
after のようにできるのは、その delegate とシグネチャが一致しているメソッドであれば同じように扱えるという仕様を利用しています。
Ruby の Symbol#to_proc
Ruby は Symbol#to_proc があるので配列の各要素のメソッドを以下のように呼び出せます。
list = [1, 2, 3, 4] list.map(&:to_s) # 単に数値を文字に変えるだけですが、int の to_s メソッドを呼び出している。 => ["1", "2", "3", "4"]
これは Ruby を使い出してすごい便利と思った機能だったのですが、一方で C# のようにメソッドを渡せないのかなぁと思ってました。
def double(num) num * 2 end list.map {|num| double(num) } # これを list.map(double) ぐらいで書きたい
Method は to_proc できるらしい
Object#method で Method のオブジェクトにできるので
double_method = method(:double) => #<Method: Object#double> double_method.to_proc => #<Proc:0x007fb79abcf0d0 (lambda)> list.map(&double_method) # or list.map(&method(:double))
ちょっと冗長に見えるけど、少しだけ C# の書き方に近い感じになって嬉しい。でも method を呼び出すのは、ちょっと微妙っちゃ微妙ですよね。。
