何でも屋エンジニアのブログ

ソフトウェア関連技術、コミュニティ、日々の雑貨

はてなブログに戻ってきた

Mediumやnoteに興味があり試してきたけど、はてなブログが一番使いやすいなと思ったので戻ってきた。

Mediumはアプリでの書き味は良かったのだけどURLが記事タイトルである点、noteはcode snippetの貼りやすさが気になってしまっていた。

元々はてなブログへの不満は特になくて最初に設定したURLを変えたいくらいだったので、有料プランに切り替えドメインも独自ドメインに変えた。アウトプット増やさないとと思っているので、色々整えていく。

noteやMediumで書いた記事のリンクを貼っておく。

Step-to-Rails-Expert.rbやコミュニティ関連

note.com

medium.com

medium.com

medium.com

その他

note.com

Change makerとはというお話 - ebi - Medium

Step-to-Rails-Expert.rb第28回の開催レポ & スタッフの増員について

3/18（月）にStep-to-Rails-Expert.rb第28回を株式会社Speeeさんで開催しました。

step-to-rails-expert-rb.connpass.com

今回私は母の体調が優れないため参加できず、スタッフのtwo_sannさんに開催をお願いしました。そして、有志でだいそんさんにも手伝って頂き、無事開催することが出来ました。 

会場提供のSpeeeさん、two_sannとだいそんさんのお二人は急な変更等に対応して頂きありがとうございました。

これからの体制について

今までは私とtwo_sannでやっていたのですが、スタッフの人数が手薄に感じるときがありました。2人しかいないので、1人が来られないともう1人だけで開催しなければならず、大きい集まりではないものの少々大変でした。他にも、新しい試みをしたいなと思ったとき、現状の開催を継続するだけで余力がなく、考えるだけで行動に移せないときも同様でした(運用業務で手一杯で新規開発できない感じ)。特に、新しい試みを出来ないことに関しては歯痒く感じていました。

ずっと感じていた上述した課題に加え、ここ最近母の体調が優れず私が度々欠席する可能性があるという現状を踏まえ、前回お手伝いして頂いただいそんさんにスタッフになって頂けないかお願いしご了承頂けました。

それに合わせて、初回からスタッフとして参加して頂いてるtwo_sannさんには共同主催者という立場で改めて運営を一緒にして頂くことお願いし了承頂けました。

だいそんさんにスタッフをお願いした理由として、継続的にStep-to-Rails-Expert.rbに参加して頂いていること、その中で色々お願いできる人柄であることが分かっていることに加え、だいそんさんは継続的にStep-to-Rails-Expert.rbに参加する中で、私の目から見てもどんどんスキルアップされており、このコミュニティのコンセプトにピッタリだったことがあります。

改めて共同主催者のtwo_sannさん、新スタッフのだいそんさんよろしくおねがいします！！

staffチャンネルでお願いしたときの様子（通勤途中で焦ってたので日本語がぎこちない） staffをお願いする流れの画像

運営する上で感じていたより本質的な課題について

スタッフが手薄という課題を解決するために新たにスタッフを増やしたのは前述の通りですが、それ以外にも課題として感じていたことがありました。

私自身、このコミュニティを2年以上運用してきて開催当時の自分からは考えられないくらい成長していると自負しています。それは良いことですが、コミュニティの運営を考えると私が最初に中級者と考えたレベル感でコミュニティが運営できてるのか、ずっと疑問に感じていました。以前に比べて、初級者よりの質問や議論が少なくなったと感じることが多くなったのです。

もちろん、回によって参加者が違うという理由でそれぞれの回の雰囲気が異なるというのはとても良いことだと考えています。そして実際、中級者とこのコミュニティが呼んでいる様々なレベル感で多様なバックグラウンドを持つ人に参加して頂き、色々学び教えひいてはコミュニティを盛り上がって行ってもらいたいという気持ちがあります。

同様に、この課題の原因が、比較的みなさん継続的に参加してくださっているのでそういう議論をしつくして次のステップに進んでいるからという理由であれば、これは嬉しいことです。

しかし、残念ながら、その原因は主催者の私の興味関心が自身や環境の変化に応じて、チーム開発の改善やマネジメント、開発手法に関して言えばWebアプリの設計ではなくより細かい分野に変化してきているのが原因のように思えます。コミュニティは生き物なので、中の人の変化に応じて変わっていくのは当然で歓迎できますが、悪い意味での固定化を私は望んでいません。 この状況を打破したく、だいそんさんにスタッフに加わってもらい、two_sannに共同主催者となって頂きました。

とは言え、積極的に何かをして！と思ってるわけではなく、この体制に変えるだけで少しずつ状況は改善していくかなと考えています。なのでスタッフのお二人は引き続きやっていきましょう。

そして、参加したことあるけどなんか違うなと思い以降参加されてない方や、今まで参加されたことのない方も、是非ご参加頂き、コミュニティを盛り上げて頂きたいのでご参加宜しくお願い致します！

会の様子

次回予定日

4月15日（月）の予定です！RubyKaigi前ですが、是非お気軽にご参加下さい。

RubyMineをメンバーに布教している

最近、RubyMineを布教している。それに伴い決済や事業部のライセンス購入の諸々を整えている。何でこのように思ったのか、以下に書いていこうと思う。

私の所属するwebチームでは、今年からスプリントタスクの多くをペアプロで実施するという試みをしている。その中でメンバーの手元を見る機会が多くなり、エディタの設定や使い方について、もう少し改善の余地あるのではと感じた。具体的には補完/jump/linterの機能である。

個人的な考えでは不慣れな言語を触るとき、補完/jump/linter周りはまず整えるのが大事だと思っているので、最初に優先度を上げて環境整備するけど、あまりその効果を実感したことがない人に、忙しい中優先度を上げて対応してもらうのは呼びかけるだけでは難しいのかなぁと感じた。 

同時に、そのような実感を持ったことがない人はおそらくエディタを自分の仕事のやり方に応じてカスタマイズした経験が少ないはずなので、補完/jump/linterに限らずある言語を使う際、エディタとしてどんな機能が自分に必要なのかを実感してもらう機会が必要なのかもしれないという考えに至った。

 

そこで、この機会を持ってもらうためにRubyMineをメンバーに使ってもらおうと考え呼びかけた。RubyMineならデフォルトで開発に必要な諸々の機能が入っているし、カスタマイズの必要性はありつつも他のエディタに比べてはるかに少ないので、先述の課題を克服しやすい。「休日にやりなよ」という呼びかけを行うのは、（個人の時間の使い方としては自由だが）組織としての解決策になっていないし「業務時間使ってやって良いよ」という呼びかけをしても忙しくて難しい（優先度を上げる気にならない/そもそも時間ない）というケースが考えられる。
 

webチームには転職して初めてRuby/RoRを使うメンバーもいたり、研修の終わった新卒のメンバーがjoinしたりであまりRuby歴が長くないメンバーが所属しているが、良い設定やオススメ機能などを共有したりフォローできてなかったので反省した。今回使い始めたメンバーで、引用TweetのようなモブRubyMineとかして便利な使い方や設定をみんなで共有して欲しいなと思っている（そして私にも教えて欲しい）。

 

 

こんなことを考えて動いているときに P山 (@pyama86) | Twitter さんの以下の記事を見て、ふむふむって思った。

 

known-unknowからknown-knownになるためには機会が必要だし、同様にunknown-unknownから脱出できる機会も必要で、そういう土壌を整えるのも仕事だなと合点した。

   

 

 

Consul DNSとDnsmasqについて調べたメモ

Dnsmasqは.consulへのDnsへの問い合わせ（port 53）をConsul DNS（127.0.0.1#8600)に問い合わせるために使っている。

通常、DnsはUDPポートの53を使うが、rootアクセスを必要とする。consulを特権ユーザーで動さずに使うために、適切にクエリをconsulにフォワーディングする。 https://www.consul.io/docs/guides/forwarding.html

より詳しくは、

consul は DNS形式でノード情報を提供しますが、この時のアクセスポートが 8600番なのでそのままでは DNS リゾルバが行えません。 dnsmasq を利用することで、マシンローカル(127.0.0.1)のリクエストを別ポートにプロキシすることができるので、それで consul の DNS を利用できるようになりますがマシン 1台内で閉じています。

https://qiita.com/rerofumi/items/237c971ed100db6385d2

とのこと。

設定としては、ドキュメントにある通り、

# /etc/resolv.conf
nameserver 127.0.0.1
# /etc/dnsmasq.d/10-consul
server=/consul/127.0.0.1#8600

とすれば良い。これでdns問い合わせを自身の8600番ポートへフォワーディングできる。

基本として/etc/hostsになければresolve.confに記載されている順でnameserverに問い合わせる(strict-orderがtrueなら）ので、このような設定でフォワーディングできる。

ところで、address=の設定値でIPアドレスを直打ちでき、設定されたルール、curl -s localhost:8500/v1/catalog/nodesとかしてゴニョゴニョしてaddressの値に設定すると、nodeの入れ替えが少ないもの（例えば検証環境とか）に関してはdns問い合わせを行わないことも可能。 manページの--address=の項を参照。/etc/dnsmasq.d/に設定ファイルを置く。

他の参考 https://www.infiniteloop.co.jp/blog/2015/04/how_to_use_dnsmasq/ https://server.etutsplus.com/dnsmasq-setup-internal-dns-with-resolver-cache/ https://wiki.archlinux.jp/index.php/Dnsmasq http://www.thekelleys.org.uk/dnsmasq/doc.html

ところで、DNSと関係ないけどleader election時、3台のserverが存在するケースでleaderが落ちserversの台数が2台になった場合はどうなるんだろう。 あと、同様にleaderが落ちて4台になってしまった場合もどうなるんだろう（raftについて調べてないのでこのようなケースに対応できるか知らない）。

ドメインごとにgit configのusernameとemail設定できるツールを作った

flex-git-configという${ghq_root}/$domain/ 配下のgitconfigを設定するツールを作りました。

github.com

動機

先日仕事で開発環境が壊れて直しているときに、ディレクトリを削除してセットアップし直した際にgit config --local user.nameをやり忘れGHEではなくGithubのアカウントが紐付いてしまいました。その時は1ディレクトリだったので手でgit configを打ったのですが、emailとusernameはGHEの特定のドメインのみ該当する仕事で使用するemailで設定したい場合が多く、まとめて設定するツールが欲しいなと思い書きました。

その他

実行方法は

$ flex-git-config -u YOUR_USERNAME -e YOUR_EMAIL -d "github.com"

です。

内部ではghqを使って-dオプションで渡されたドメインにマッチするディレクトリを取得し、git config --localを呼んでいる簡単なものになります。

勉強中のGoを書きたい欲が強かったので、他に同様のツールがあるか等特に調べずに勢いで書きました。まだテストもなくローカルで動くか確認したのみなので、テストとCI追加してソースもキレイにしていきたいです。

楽しかった。

ペアプロをやるにあたって先に読んでおいて欲しいこと

最近特定の一人とペアプロがすることが多かったのですが、また別の人とペアプロをやる機会ができたので、ペアプロをする前に読んでおいて欲しいことをまとめておきます。 主に物理的な準備と、心構えについて書きました（経験に基づくものなので、網羅的な一般的な話は本を読んで頂くのが良いです）。

取り掛かる前に

目標or時間を決めましょう

リファクタリングの場合は特に時間を決める必要性が高いです。リファクタリング他にも直したいところが出てきてしまいがちで、永遠と時間を取ってしまい疲れてしまいます。新規開発の場合は、目標に対しての進捗が比較的分かりやすいですが、それでも上限の時間を決めておくに越したことはありません。

飲み物・食料を用意しておきましょう

思った以上に体力と喉を使います。体調を壊さないようにやりましょう。

進めている最中

休憩を取りましょう

60 ~ 90分くらいで休憩の声掛けを気づいた方がするようにしましょう。ただし、それより早く休憩したい場合は、お互い気にせず休憩したいです！って言いましょう。

  • トイレ休憩
  • のどかわいた
  • お腹すいた
  • さすがに疲れた...

などなど、理由はなんでも良いのでキツくなったら休憩をはさみましょう。二人が協力して進めているので、二人の力が最大限発揮されるような環境を作りましょう。

コミュニケーションをしっかり取りましょう

なんか上手く進んでいないな？と思ったら、進捗が悪くても一旦進める手をとめて原因を考えてみましょう。相手も同じように考えているかもしれないし、感じた違和感がより良い時間にするためのヒントである可能性もあります。遠慮しないで意見を言いましょう。

終わった後

最後に必ずふりかえりをしましょう
  • 新たなメンバー同士で行う初回は、進捗が出ないことも多いです。コミュニケーションのとり方を学び、お互いの理解度を把握し、適切な進め方をふりかえりの場で考えましょう。
  • ProblemとTry出すことで気をつけるべきことが明確になり、気持ちが楽になります。
    • うまくいかないまま原因を究明せずに終わると、お互いがお互いに対し責任を求めたり、ペアプロ自体が辛くなってきてしまいます。
    • 反省点・悪いところが出てくる場合、なるべく仕組みで解決するようにしましょう。
  • せっかくお互い学べるチャンスなので楽しく進めましょう！
  • めっちゃうまくいってる場合、楽しい気分で終われているはずなので褒めあってもっと楽しく終わりましょう。

Step-to-Rails-Expert.rb第19回の開催レポとこれからの企画について

5/21（月）にStep-to-Rails-Expert.rb第19回を株式会社Speeeさんで開催しました。

step-to-rails-expert-rb.connpass.com

流れ

今回はもくもく会でした。

当日の流れは

  • 自己紹介
  • 会の概要説明
  • もくもく
  • 懇親会

という形で進めました。

会の様子

参加者のあっきーさんがすごく丁寧にブログに書いてくださっているので、そちらのリンクを貼あります。

akinov.hatenablog.com

Step-to-Rails-Expert.rbのこれからについて

今回も@sinsokuさんからアドバイスを頂き、色々考えた結果企画を一旦もくもく会ベースに変更しようと考えております。具体的には、会の企画に柔軟性をもたせ、必要に応じてレビューをしたり作業をしたり話したりできる場として進めていきたいと考えています。

この変更をする私個人の理由としては

  • なるべくコードを書く時間が欲しい
  • レビューされる必要のある仕様を追加するコードを書きたいというより、Railsの新機能やRails外のことも色々試してみたい&話したいという欲求の方が強くなってきた
  • 進行管理が大変

会全体の課題としては

  • レビューの仕方や指摘事項としては学べた

  • 何か機能を実装するより、Railsの新機能を試したりするベースアプリとしての使用も増えてきて、そのような人たちにはレビューすることでのメリットが生まれにくくなっている。少なくとも、定期的に行うのではなく需要が発生したときにそのような企画にするorもくもく会の中で有志がレビューするような形の方が、柔軟で良いのではないか

  • レビューにすると変更分の多くに目を通すことになるが、聞きたいこと・興味のあることは変更分の全てではないはず

  • 時間が足りなく、駆け足になってしまう

  • 初回の人は指摘内容が同じになってきてしまう

というものになっています。会が進むにつれて、例えばRailsをアップグレードする作業なども行う必要がありますが、これは（特に小規模のアプリの場合）企画としてレビューする必要性が薄いと感じています。同様に、ActiveStorageを試している方が参加者にいますが、レビュー時はレビュワーがこんな使い方があるのか、と知る場になっていて、これは別にレビューを行わなくとも進めることができるのではないか、という思いがあります。

ただし、レビューに向けて作業をしてくださっている方もいるかと思うので、移行期間として、次回やその次の回は主催者&スタッフと参加者で興味ある方レビューを行うこととします。それ以降は、一旦全体の差分を見てレビューを行うことはしない予定でおります。

しかしながら、上述の通り「柔軟性をもたせ」た運営をしていくので、必要に応じてレビューを行うような企画にしたり、以前のように議論形式の企画にしたり、目的に応じて参加者にも楽しんで頂ける会にしていきます。引き続きご参加いただければ幸いです。

次回について

次回は6月18日（月）に株式会社Speeeさんにて開催します。気軽にご参加ください。 移行期間のため希望者がいらっしゃればレビューしますので、レビュー希望の方もご参加ください！