蚊帳の中の日記

ゆるく生きてます

2019.10.7~10.13

最後に書いた週記が9月上旬で全然書いてなかった。

正直9月は仕事で大きめのタスクをずっと持っていて、それ以外ほとんどやってなかったし、帰ったらモンハンやるくらい。仕事をして家でモンハンという全然代り映えのないループを繰り返す1ヶ月だったから書くことが特になかったし、まぁ良しとします。

とりあえず再開。

10.7 mon

  • 開発体制が変わって、まだ時間立ってないので少しタスクの進め方に不慣れな場面が出てしまったけど、久しぶりに違うタスクに取り組めたのでリフレッシュになった
  • モンハンワールドでやっとこさ導きの地に入れた。
  • 太刀や大剣使ってたけど、ランスの良さを知ってしまった。ガードカウンターからクラッチクローできるやつがいい。
  • reactをなんとなく触りたくて、react tutorialをやってる

10.8 tue

10.9 wed

  • 複利って偉大
  • レガシーコードからの脱却を中盤くらいまで読む
  • 導きの地、めんどくさい

10.10 thu

  • なんかめっちゃ頭が痛かった
  • 新卒の子が、ちゃんと疑問に思ったことを調べたり、聞いたりして、自分も見習わなきゃなって思った
  • レガシーコードからの脱却を引き続き読んでる。結構聞いたことあるようなノウハウも書いてあったので飛ばし飛ばし読んだ

10.11 fri

  • 台風がヤバそう
  • 3連休は実家に帰ることにした
  • レガシーコードからの脱却を読み終えた(一部飛ばし飛ばし読んだから、多分本棚において都度見返すと思う。レガシーなサービスを生み出さないための原則とプラクティスが乗っていて、すぐ近くにおいて毎日見返したい内容だった。どっかで読んだメモを書こうかな。)
  • react tutorialを終えて、他のサンプルコードや公式Docの説明などを読んで勉強

10.12 Sat

  • ごろ寝
  • react色々学んだ
  • reduxとかも一緒に勉強しようと思ったけど、公式にも「まずreactをちゃんと勉強することをおすすめします!」って書いてあるし、一旦忘れる。
  • 結構、複雑なアプリ色々作れそうで、ここに認めてる。

10.13 Sun

  • 実践typescriptで読み飛ばしていたreactの章を読んでみた
  • kindle unlimitedに加入してみた
  • チェンソーマン4巻を読んだ

最近、reactとかvueとか、rubyで意外と身になってなかった所とか、色々インプットできた気がしてて、近いうちにアウトプットしていこうと思う。

2019.08.26~09.01

夏休み入ったら、早速2週分くらいサボってしまった。再開。

 


月曜日
  • 今日は1日中頭が痛かった
  • また衝撃の人事発表
  • とあるエラーログを調査。cronのことをちょっと知れた
  • とあるセキュリティ対応done
  • 実践TypeScriptを電子で買った。第1章を読み終えた。

 

typescriptでもっと遊びたいけど題材が思い浮かばないな…。

 


火曜日
  • なんか熱っぽかったので休んだ。1日中寝て過ごす
  • チェンソーマン3巻を読み終える

 

運動しないとあかんな〜

 


水曜日
  • もうすぐ増税だね、それ関連のことをやった
  • 今日、それしかやってない
  • 実践typescriptの2章を読んだ

 

木曜日
  • 昨日の続き。地味な作業だけど神経使うから疲れた
  • お問い合わせ対応(なんか久しぶりにやった気がする)
  • 会計周りのコードをリーディング
  • 実践typescriptの3章の途中まで読み進め
  • ts-nodeってやつでREPLからTSを直接コンパイルして結果を出力してくれるから勉強にはもってこいだった。

 

金曜日
  • また続き
  • QAエンジニアの偉大さをまた痛感した

 

土曜日

  • 昼過ぎまで爆睡
  • 実践typescriptの4章まで読み終える
  • 吉祥寺でご飯!コナン談議でなんか白熱した笑

 

日曜日
  • モンハンワールドでベヒーモスが強すぎる
  • 久しぶりに秋葉原に行って、有名らしいレトロゲームショップに行ってきた。久しぶりにゲームキューブやった。楽しい〜。
  • LPICをまだ受けようと思ってたのだけど、まだ全然勉強始めてなかったので計画を立てた

 

来週はもうちょっと体を動かすことしたいな。

2019.08.05~08.11

8/5

  • 衝撃の人事発表
  • intellijとcacherの連携が良かった
  • スプリントタスクのプルリクを修正完了
  • ペアプロというかペア調査みたいな感じのことをした
  • 社内ツールでバグが出て、graphql周りのエラーだと判明。色々調査。初めてGraphQL周りを触ったかも
  • rebuild聞きながら帰る

8/6

  • レビュー
  • とある移行作業の検証を行う。デバック楽しい
  • 1on1して下半期目指すべき事が少し明確になった。やるぞ。
  • プルリクで色々議論した。問題を整理しきらないで実装を進めると、実装が分かりづらくなるので気をつけないと。でも議論楽しかった。

8/7

  • 諸々レビュー
  • PRの修正
  • とある移行作業の検証作業の続き。昨日で終わらなかったし、また問題点を見つけた。うーむ、難しい。こういう時Rspecが充実しているとデバックがやりやすいな〜と感じた
  • BigQueryのTIMESTAMPって、タイムゾーンの表記に少し癖があった。嘘だった。
  • BIさんに聞いたけど、最近のデータサイエンス周りのトレンドはTDからBigQueryに移っているらしい。ふーん。

8/8

  • とある移行作業の検証作業がやっと終わった!
  • ちょっと急ぎ案件が出てみんなで対応
  • 目標設定を一通り書き終えた
  • 夏休み明けに来る新卒くんの最初のメンターみたいなのを務めることに。務まるかな。。。頑張ろう。
  • とある機能の仕様についてAndroidエンジニアと会議

8/9

  • 夏休み前の最終日
  • 夏休み明けにメンターやることになったので、色々準備する

8/10

  • 実家に帰って老犬を愛でる
  • 明日中国に飛ぶので色々準備する

8/11

  • 中国初上陸!

これ、中国のホテルで書いてるんだけど、初日にして日本帰りたくなってきたw

2019.07.29~08.04

7/29
  • とあるライブラリのアップデートが完了。アップデート業ってめんどくさいイメージあるけど、意外とライブラリコードなど見れて面白かったりする。やっと出せて良かった。
  • とある移行作業の見積もり(これに時間かかってめっちゃ疲れた。でも、具体化出来ていなかったところを洗い出せたし、チームメンバーと色々話せて良かった)。
  • 移行作業系のPRレビューを諸々

 

7/30
  • 体調不良で午後から出社
  • いろんなPRレビュー
  • 移行作業の今後の進め方について、他職種の人と会議祭り。午後まるまる施策主導者の方や開発Dや開発メンバーに共有するのが大変だった。苦手な作業だけどやらないとダメなやつ。
  • ログ関連のバグを修正

 

7/31
  • 昨日の会議の続き。マジで会議しかしてない。今日、殆ど会議だった。人と喋るの慣れてないから疲れる。
  • 昨日のログ関連のバグを再度修正。
  • web+db pressのrails6の特集読んだけど、新しいコンポーネント群に今までよりどう嬉しいのか?…さらに疑問が湧いてしまった。

 

8/1
  • 日直担当
  • いろいろ問い合わせや雑作業
  • 会議後に、もろもろの関係各所に確認作業

 

8/2
  • 別で行われた作業のミスがあり、対応で午前中からリリース
  • 今日も日直担当。問い合わせや雑多作業を、諸々行う。
  • nginxの知識をつける機会があった。それに合わせてスプリントタスクの開発修正

 

8/3
  • 疲れが溜まってたし、外は暑いので、家でダラダラしてた
  • もうすぐアイスボーン発売するか、適当なクエストでリハビリしたけど、ヤバイ

 

8/4
  • 夏休み中の旅行の計画を練りまくる

 

総括感想

先週、今週と慣れないことして疲れた。次の週はもっと開発する事に集中できる時間が欲しい。

あと体力の衰えを感じてて、なんか運動しないと。

2019.07.22~28

毎日色々なことを経験しているはずなのだけど、暫く経つと自分が何をしていたのか思い出せなくて「自分は一体何をやっていたのだろう?」とよくわからない謎の喪失感を感じるときが最近よくあった。

何もやってないということはなくて、単純に色々なことを経験して思い出せないだけな気がしているので、せっかくブログもあるんだし、週記を今日から残していこうかなと思う。*1

今日は記念すべき1回目(さて、いつまで続くかな)


7/22(月)

  • インフラ関連のアカウントの整理
  • とある機能のABテストを実施するので、その処理の実装
  • ライブラリアップデート作業

7/23(火)

  • ログ基盤PJについて色々詳しい対応方法を調査
  • PRレビュー(結構重いのがあった)
  • チームの振り返り会

7/24(水)

  • いろんなPRレビュー
  • リリース作業(途中でエラーが出て、ちょっとハマった)
  • 見積もり作業

毎度思うけど、この見積もりをどこまで細かくやるべきかいつも迷う。他のところとかどうやってうまいことやってるのかな。。。

7/25(木)

  • いろんなPRレビュー
  • とある画像関連の施策で、実装上の仕様や懸念点を洗い出し
    • 割といままで触ったことがないJS周りのコードをデバックしながら既存仕様を再確認する作業だったので楽しかった
  • とある施策のスケジュールを調整
  • 自分の新しい目標の設定

目標設定、まだ迷っている...。

7/26(金)

  • 昼ぐらいに出社
  • ○ベン
  • お問い合わせ対応
  • とある画像関連の施策について、開発Dと話し合い
  • 開発主担当をしたツールの仕様について、改善点を提案されたので会議
  • 他の人の開発環境がバグったのでデバック

7/27(土)

  • OSS Gateにビギナーとして参加しました!
  • マインクラフト PS4ブックオフで買ったらドハマリした

7/28(日)

  • 昼ぐらいまで爆睡
  • イクラ
  • ニトリ珪藻土マットを買った(これ最高。うちの風呂場のQOL(?)が1UPした)。

総括感想

開発時間を捻出が課題と思った一週間


こんな感じかな。 仕事の内容は詳しく書けないので、抽象化してる。 継続していってみようっと。

*1:日記だと毎日書くのがだるいし、3日坊主確実だったので週記にすることにした。

OSSの門を叩いた土曜日

OSS Gateという体験ワークショップに初参加したのだけど、楽しくて、あっという間に時間が過ぎてしまった

oss-gate.doorkeeper.jp

参加のきっかけ

以前からOSS開発に興味はあったのだけど、正直何から始めればいいのかわからなかった。
普段からOSS開発している人の話を聞いたりすると、「とりあえずプルリク投げてみればいいじゃん」と言われるのだけど、その「とりあえず」がわからない。何かお作法はあるのか?英語がいいのか日本語がいいのか?どういった観点で、どういった粒度のプルリクを送ればいいのか?...色々な疑問や不安はあった。
そんな時、今年のRubyKaigiに参加した際にOSS Gateのことが紹介されていて、興味を持った。同僚の先輩も参加経験があり、話を聞いてみると「めちゃくちゃいいイベントだよ」と教えてくれたので、思い切って申し込んでみたのがきっかけ。

OSS Gateの概要

参加者は、ビギナー、サポータ、サポートメンターの3種類に別れている。*1
文字通り、ビギナーは僕のような初心者で、初心者をサポータが助けてくれる。サポータが困ったら、より知識があるサポートメンターの人が助けてくれて、更に知見が広がるような仕組みになっている(この仕組みは非常に良かった)。

進め方としては、難易度などは関係なく、ビギナーが何かOSSを一つ決めて、それを題材にOSSを実際に動かしてみることから始まる。そして、何かフィードバックができる観点を見つけたら、実際にPRを送ってみるという感じ。フィードバックを送るまでの間に実際どういった作業をしたのかは、OSS Gateのリポジトリがあり、そこにissueを立てて作業内容を逐一記録していく。

僕の記録は👇

github.com

会の途中で、2回ほど振り返りをする時間があり、その時間は自分を担当してくれたサポータ以外のサポータからアドバイスを貰う時間もある。

PRは、何かOSSのバグを見つけてきてPR送るような難易度が高いことからやるわけではなく、READMEの説明が足りないとか、ドキュメントのリンクが切れているなどの比較的小さな問題に対してフィードバックするのでも全く構わない。

参加前は「何かバグを見つけてPRを送るくらいまでやるのかな?大丈夫かな?自分に出来るかな」と少し不安だったけど、意外と敷居が低くて取り組みやすいフィードバックから見つけていくことも出来るので、やりやすかった。

あと、色々なサポータのアドバイスや知見を共有してもらえる時間が用意されているのは、有意義で最高と思った

個人的な観点で、会に参加して良かったなと思った事

  • OSSにPRを投げる初歩を学べた。そして実際にPRも送れた!
  • 何かバグを見つけてPRを送らなきゃ!と身構えなくても、ドキュメントの間違いやちょっとしたtypo修正だけでも色々PRチャンスがあることに気づけた
  • OSSによって文化やフィードバックの仕方に違いはあるので、READMEや他の人のPR、issueを見ることも参考になることを知れた。
  • OSSの開発者に、自分の送ったPRの意図がわかる説明を吟味することが重要だということを知れた。*2
  • コミット、ブランチ名、PRの説明。これらに、より神経を使うことが必要であることを知れた。
  • 英語の文法を気にしすぎるよりも、まずはエイヤッ!とPR投げてみる気持ちが大事(少し拙い英語でも開発者は理解してくれる事が比較的多いらしく、理解できなければ聞いてくるはず)。

自分が題材に上げたのは GitHub - fluent/fluent-logger-ruby: A structured logger for Fluentd (Ruby) 。最近業務で触る機会があったので、せっかくだから取り上げてみた。そして、PRを投げることにも成功。マージしてもらえるかな。ドキドキ。

github.com

実際、OSSをイチから触り始めると、意外とREADMEに説明がなくて詰まったりすることがあり「〜の説明があったのほうがOSSの利用者に親切なのでは?」という場面が多かった。
僕の場合、「どうすればよりわかりやすいドキュメントになるか?」という議論がサポータさんとの間で白熱して、結果的にプログラムにフィードバックするのではなく、ドキュメントのちょっとした更新のPRになった。意外とこういった比較的敷居が低そうな観点のPRチャンスもあるのだなとということを知れたのでは、個人的にとても新鮮だった。

PRを投げる前には、該当のOSSに何か作法はないか(issueテンプレなどあるか?他の人はどうやってPRを送っているか?)を調べたりしたが、大きい規模のOSSなどはissueテンプレなどが事細かに用意されてる一方で、自分が選んだOSSは特に何もなくてPRにissueのリンクが雑に貼られているだけになっており、ものによって雰囲気がぜんぜん違うのは、比べて見ていて面白かった。

あとは英語力。「英語の文法を気にしすぎるよりも、まずはエイヤッ!とPR投げてみるのが大事だよ!」とアドバイスもらった。確かに!と思いつつ、もっと英語をスラスラ書けると更に楽しいだろうな〜。

OSSの門を潜った実感のある1日だった

実は、会に参加する前に題材に上げたOSSのバグを踏んでいたので、それを今日の課題にしようと思っていたのだけど、会の直前に修正PRが出てマージされてるのを見つけてしまい、「やばい、今日の題材、どうしよう、、、」と焦ったりもした。
しかし、実際は簡単なところからOSSに取り組む作業を教えてもらったので、とても有意義な時間を過ごせた。仮に何もOSSに取り組む当てがなくても、イチから教えてくれるので、そういった方でも参加する価値がある会だと思う。

非常に楽しかったです。ありがとうございました。もう少し個人でOSSに取り組んでみて、そのうちサポータとして再参加してみたいなと思っております。

*1:OSS Gateは、以前ビギナーで参加した人は、任意で次の回の時にサポータとして参加することが可能。つまり、ビギナーを経験して慣れきたら、サポータとして再参加し、また新たなビギナーを助け、OSSコミュニティの和を広げていく事ができるような仕組みになっている(良い仕組みだ)。ただ、このサポータも最初はどうやってビギナーを助ければいいのか困る時がある。この時にサポータを援助してくれるのがサポートメンターという役割の人。比較的普段からOSSに参加してる強い人達がいるみたい。

*2:例えば、実際の作業・期待した結果・実際の結果という観点で説明を書くと流れが理解しやすくわかりやすかったりする

lpic 101 - level 1に合格したけど、実務で使えそうな知識をまとめてみる【コマンド探索編】

これで第3段。

コマンドを探したい時に、whichを使ってコマンドの絶対パスが調べたり、$PATHに含まれてるかどうか確かめたりすると思うが、他にも似たようなコマンドがあって自分の中の整理の意味でもまとめようと思う。

とあるコマンドやファイルを探したい!という時に覚えておくと便利そう。

which

指定したコマンドが格納されている絶対パスを表示する。

重要なのは、検索するディレクトリは、環境変数PATHに設定されているパスになる。つまり、環境変数PATHに設定されていないと見つけられない。とあるコマンドをインストールしたけど、パスが通ってなくてコマンドを打ってもCommand not foundになってしまうので、

export PATH="$PATH:/usr/local/bin"

した経験はあるはず。上のように$PATHに追加すれば、whichの検索対象になるというわけ。

whereis

whichと同じくコマンドが格納されているパスを表示するが、こちらは環境変数PATHを検索対象とせず、コマンドが格納されている標準的なディレクトリから検索してくれる環境変数PATH以外で探したい場合に便利。

コマンドをインストールしたはずなのにwhichで見つけられない!という時に、このコマンドで見つけられることがあったりする。*1

locate

今回、コマンド探索編というタイトルで記事を書いているので、このコマンドをこの記事で紹介するのは違う気がするけど、一応コマンド探索は出来るので紹介してみる。

コマンドに限らず、指定した検索パターンにマッチしたファイルなどもすべて表示してくれる。
ただちょっと難点があり、検索をするのにデータベースを構築する必要。そのデータベースを元にfindなどよりも高速な検索を行ってくれる。
もう一つ難点があって、そのデータベースは定期的に更新処理をしないといけないこと。まあ使う機会は殆ど無いコマンドだと思う*2

whatis

manコマンドで表示されるコマンド名と、省略された説明1行が表示される。

$ whatis ruby
erb(1)                   - Ruby Templating
irb(1)                   - Interactive Ruby Shell
ri(1)                    - Ruby API reference front end
ruby(1)                  - Interpreted object-oriented scripting language

検索対象はlocateと同じ感じでwhatisデータベースと呼ばれるデータベースファイルがあり、makewhatisまたはmandbで更新することが可能。これもデータベースの管理が面倒だし、whereisで見つけて、manで表示で事足りるので、余り使う機会はない気がしている。ただ、データベースを用意すれば検索は普通よりも早いらしい。

ちなみに、whatisman -fと同じ

*1:ちなみにバイナリファイルやマニュアル、ソースファイルが置かれている場所をオプションをつけて調べることも可能。

*2:じゃあ、なんで紹介したんだよ!!!

続きを読む