Rails / OSS パッチ会を2018年2月26日(月)に開催します。
この会をひとことでいうと、日頃のお仕事で使っている Rails をはじめとする OSS への upstream にパッチを送る会です。
会には Ruby と Rails のコミッターである顧問の a_matsuda もいますので、例えば Rails に送るパッチのネタがあるけれど、パッチを送るに適しているかの判断やパッチを送る流れが悩ましいときなど a_matsuda に相談して足がかりにするなどできます。
開催時間は 17:00-19:00 となりますがご都合のあう方はぜひご参加下さい。特に募集ページなど設けませんので、興味のある方は永和システムマネジメントの神田オフィスまでお越し下さい。
http://agile.esm.co.jp/about/office.html#nav
Rails 5.2 が master からブランチアウトされて、Rails 6.0 の開発がはじまったところなので、そのあたりのネタでワイワイやりたい人なんかもお気軽にどうぞ。
はじめまして。2017年度入社の@hisasです。
2018/01/24に永和システムマネジメント東京支社にてアジャイル事業部 年始のご挨拶の会を開催しました。
今年も年始のご挨拶ということで、2018年度カレンダーの配布と、
各月を担当した弊社社員による熱いLTが行われました。
当日のTwitterのハッシュタグは #oblove_calendar です。
以下に公開されているスライドを紹介します。
www.slideshare.net
今年は技術寄りな内容のLTが多く、これ後で試してみたいなと思うものばかりでした。
中でも新卒で同期の@swamp09 の発表は、彼自身が毎日コードを書くことを実践しているということで刺激を受けました。
また、個人的には学生時代お世話になった@machidaと@komagataがお越しになっていたので、発表する前は成長した姿を見せられるか緊張しましたが、楽しく話すことができました。
会場へお越しくださった皆様、ありがとうございました。
今年もよろしくお願いいたします。
明けましておめでとうございます。新年最初の仕事は昨年の勤怠入力でした。
さて、2017/12/25 に Ruby2.5 がリリースされましたね。今日は、今私がやっているプロジェクトの Ruby を 2.5 にした時に行ったことを書きます。 リリース前のプロジェクトのため、Ruby2.5 対応のゴールは、アプリが起動し、テストがパスすることとしました。
私のプロジェクトでは、開発環境から本番(リリース前なので稼働はしていませんが)まで Docker を使っています。
まずは、https://hub.docker.com/_/ruby/ に 2.5.0-alpine が来ているのを確認後、Dockerfile を書き換えビルドしました。また開発環境には BUNDLE_PATH と node_modules に別途マウントした Volume を指定していたため、この Volume をクリアする必要がありました。これは、使っている gem や npm のライブラリにネイティブライブラリのものを使用していたためです。
アプリの起動までには、一箇所修正が必要でした。それは、devise 4.3.0 を使用していたのですが、そのバージョンだと Ruby2.5 の syntax change を踏んでいました。そのため、修正されたバージョンである 4.4.0 にアップデートすることで起動が可能となりました。
テストでも一箇所修正する点がありました。concern したモジュールのテストをモデル側でする際に、description に以下のような書き方をしている箇所がありました。
module Authenticable end class User include Authenticable end describe User::Authenticable do end
この User::Authenticable と書かれているところで、NameError が発生するようになりました。
これは Ruby2.5 でトップレベルの定数探索が削除された ことによる影響でした。
なので、ここは User::Authenticable を 'User::Authenticable' のように文字列にすることで回避しました。
私のプロジェクトは、まだ規模も小さいため、これぐらいの修正で対応が完了しました。
これにより、pp を require せずに使えたり、Hash#tranform_keys や Hash#slice を使えたり色々便利な機能を ActiveSupport なしで書けるようになって便利になりました。
また、3 倍早くなったと噂のブロックパラメーターや do ... end に rescue などが使えるようになるのも楽しみです。
それでは、良い一年を。
すっかり年の瀬となりました。来年の準備はおすみでしょうか？
アジャイル事業部では昨年に引き続いてオブラブカレンダーを作成いたしました。今回も各月ごとに個性的なテーマを盛り込んでいます。
そして今回も事業部の年始のご挨拶を兼ねまして、お年賀としてカレンダーをお渡しする会を開催することとなりました。
各月のテーマに沿った内容をメンバが LT で語ります。 また簡単な軽食とお飲物を用意しておりますので、ご来場いただき LT と食事をひとときお楽しみいただけたらと思います。
開催は年明けの1月24日(水)の夜です。
ご参加を希望される方は申し込みページからご登録をお願いたします。
年始としてはいささか遅い時期となってしまいますが、皆様のご来場をお待ちしています。
新卒氏ズのひとりのスワンプ氏とランチを食べながら、「るりま」のサンプルコードプロジェクトでの活動の話を聞いていたりした。
その際に「るりま」を元にしたものを Ruby-Doc にフィードバックするにはどうしたらという話があったのでその事例を紹介する。
以下は以前に Module#constants について「るりま」と Ruby-doc 両方にフィードバックした際の PR となる。この時はまず Ruby-Doc に送ってから「るりま」に送っていたが話としては類似したものだと捉えている。
こんにちは、富山在住の kunitoo です。
リモート勤務はじめましたにもありますが、昨年12月20日から出身地である富山県に引っ越し、リモート勤務という体制で働き始めました。 約10ヶ月間リモート勤務を行なった感想は、スムーズにリモート勤務に移行でき、 日々の業務も問題なく進めていけたと感じています。
リモート勤務を実施する中で、事前にやってよかったことや工夫してみてよかったことについてまとめました。
リモート勤務をこれから始める人や、既に実施している人の参考になればと思います。
弊社にはリモート勤務が始まる以前から在宅勤務制度があり、富山に引っ越す以前から私自身も週に1、2回程度、在宅勤務を行っていました。 多くの人が在宅勤務を行っていたので、在宅勤務のメンバーがいるという状況に慣れていたため、突然私だけが出社しなくなり業務に大きく影響出るということが発生しなかったように感じます。
リモート勤務に移るタイミングでプロジェクトを移るということはありませんでした。 チームメンバーが変わらないので、コミュニケーションの面で変化が抑えることができ、リモートだから上手くいかないのか、リモートじゃなくても難しい問題なのかを切り分けることができたのではないかと思います。 うまく伝わらないなーと思ったときに、出社している時にはどのように伝えていたかというのもヒントにできました。
朝会や会議、ペアプロなどでビデオチャットを利用しているのですが、その際に重要になるのが音声品質です。 とくにマイクの性能がよくないと気付かない間に、相手に聞こえなかったり、不快な思いをさせてしまいます。 しゃべっている側は音声品質が悪いことに気付きづらいので、気を使う必要があると感じました。 また、マイクスピーカーを利用することで、スピーカーの音をマイクが拾ったり、イヤホンをしなくても長時間会話できるため、私は気に入っています。
今回はプロジェクト専用として東京側に複数人の声が拾える ヤマハ YVC-300 を購入し、富山には ヤマハ PJP-10UR を購入しました。
Idobata でメンションがあったときにすぐに反応できるように、私はスマートウォッチ(Pebble Time Round)を利用して、仕事中に必要そうな通知だけに絞り込むことで、すぐに気付けるよう工夫しました。 これによって、となりの席にいるような、「今ちょっといい?」というような会話のスタートが切り易くなり、常時ビデオチャットを繋がなくてもよい環境が作れています。 常時ビデオチャットを繋がないことで、会話のないときの作業に集中できたり、会話するときにメリハリが生れるといった効果があったと感じています。
最近ではプロジェクトで利用する appear.in のルームを決めているため、"@kunitoo appear.in?" といったメンションが来たタイミングでスムーズにビデオチャットをスタートすることができています。
事業部の会議や勉強会などにリモートから参加する際に、なにで繋ぐかというのを Idobata でやりとりするところからスタートしていることがありました。
現在は関連する Idobata のルームの Description に接続先 URL を記載し、時間になったらその URL にアクセスするという運用を行っています。
これによって私だけでなく、在宅勤務の人も会議に参加し易い環境になったと思います。
今回引っ越しするにあたって(家族の同意を得て)仕事部屋が確保できる間取りのアパートを選びました。
リビングから仕事部屋に移動する際に「いってきます」といい、リビングに入る際に「ただいま」と言うようにしました。
これは、自分の仕事モードへのスイッチのつもりで始めましたが、妻にも影響があり、仕事中は集中できるように気を使ってもらえているようです。
私の場合はリモート勤務に移行するにあたり、大きな変化がないようにしたこともあり、仕事には大きな影響はありませんでした。 できるだけ変化を抑えつつ、コミュニケーションツールに気を使えば、リモートワークのハードルは下っているように思います。
少しでもリモート勤務を行う人の参考になれば幸いです。
7/6（木）～7（金）に事業部メンバーで合宿に行ってきました。 アジャイル事業部では毎年1～2回、合宿を計画してメンバーが参加します。 過去には「チームビルディング」や「自分たちが大切にしていることを探す」などのテーマでも実施しました。 ここ数回は、「（主に業務で使用しない）技術で遊ぼう」ということで、「IoTハッカソン」や「日々の生活を便利に」をテーマにプログラミングや電子工作にチャレンジしています。
今回は以下のコンテンツで一泊二日を過ごしました。
今回の会場は、桐花園という神奈川県のキャンプ場でした。 （http://tokaen.jp/） 私たちの合宿では初使用でした。本当に普通のキャンプ場なのですが、センター棟と呼ばれる建物は合宿所のような作りで、広い作業場所兼宴会場となった和室は使い勝手が良かったです。開発合宿先を探している方には候補のひとつとしていただければと思います。
オフラインリアルタイムどう書く（以下「どう書く」）は、与えられたお題に対して1時間かけて解くイベントで、パブリックな場所では 横浜へなちょこプログラミング勉強会 | Doorkeeper で開催されています。 アジャイル事業部では、このイベントに会場提供をしていたり、社内勉強会として開催したりしています。 今回の問題は、「6×6のマスを、指示された通りに移動して、移動した終点の文字を出力する」というお題でした。（当日のお題はこちら 第37期合宿 どう書く 問題 · GitHub ）
若いメンバーがどんどん解答していく中、普段あまりコードを書いていない僕も必死でプログラミングしたものの、時間切れでした。 みんなが解答を出した後は、それぞれが自分の考え方や書いたコードを発表して、「あー、そんなやり方があったかー」と悔しい思いをしたり、「これはもっとうまくやれるはず」と上から目線になってみたり、楽しい時間を過ごしました。
8月から新しい期が始まるのに合わせて、できたてホヤホヤの事業部計画書をみんなで読みました。なかなか普段は意識しない計画書の内容について、ああだこうだと意見を交わす貴重な時間でした。
1日目の夕食は、バーベキュー。火を起こして、用意してもらった肉や野菜、焼きそばを焼いて、みんなで食べました。お酒を飲みながらということもあり、いろいろな場所で話が盛り上がっていました。
2日目は朝からモブプログラミング。2グループに分かれて、与えられたお題に沿ったソフトウェアを作ります。普段仕事で使っているRubyや、使える人が多いJavaを禁止して、あまり使ったことがない言語から選択します。さらには普段よく使うHerokuや、AWSなどは使用しないというルールで開始しました。 1チームはScala、もう1チームはPythonを選択しました。そして両チームともインフラはほぼ初挑戦の人が多かったGCPを選択。
両チームとも苦戦しながらも、みんなでシンタックスを調べたり推測したりしつつ、少しずつものが出来上がっていく過程を楽しみました。個人的にはPythonはまったく書いたことがなかったのですが、ドキュメントを調べながら初挑戦の言語で動作させていくことを楽しめました。また、「この人はこういう状況にハマった時にこういう試し方をして確認するんだなー」等、同僚の行動を見ることができたのも面白い体験でした。
