人生で初めて1ヶ月続いた日記の感想
10月はじめから日記を始めた。 今日はその日記について。
きっかけ
春から家から一歩も出ず変化のない日が続くことが多く、次第に時間感覚が失われていき、一昨日にやったことと2週間前にやったことの区別がつかなくなるくらいまで達したことに気づいたのがきっかけ。
これはまずいと思い、自分が食べたもの、やったこと、行った場所、感じたことを記録することにした。 日記を書くことで自分のやったことを振り返られるようにして、家にいても一日一日の変化を感じようと思った。
内容
一日目の一部を抜粋すると次のような内容だった。
| 朝食 | 卵かけご飯、インスタント味噌汁 |
| 昼食 | 和風パスタ |
| 夕食 | 惣菜の寿司と豚の生姜焼き? 春菊のおひたし ご飯 |
日々誰にも合わず家からも出ない日が続くので、何かを残したい気持ちになり、日記をはじめてみる。 過去に日記を続けられたことはないのだが、今回こそ。強制ではないけどなるべく毎日、内容の濃さよりも継続することを大事にしていきたい。
今日は日曜日で、10時前くらいに起きた。
午前中はだらだらブラウジングして、午後は memo.basd4g.net のデザインを調整したり、favicon をつけたり、Hugoの設定を変えたり。 あとずっと放置していた大学の研究倫理eラーニングとやらをやった。Webサーバのレスポンスが遅くて離脱しそうになった。
卒業研究の準備を進める日にしようと思っていたのだけど、これに取り組んだのは結局夜になってから。 数日前に教授に頂いた資料を読みながらテーマを考える。明日はゼミと面談があるので、どんな内容を面談で話すかざっくり決めておいた。
義務感で何かをやるのは苦手で、卒業研究も自分の興味が一定あるのに「やらねば」と思うほど手が出なくなる。悪い癖だ。 やり始めてしまえば多少は手を動かして進むので、「辞めてもいいから5分だけやろう」みたいな自分へのルールを課していかないとだめだな。
これを書いている時間は既に10/05 1:32だが、寝る前までは10/04カウントとする。今後も寝る前までは日付を超えても前日扱いで日記を書いていこう。
こんな感じでその日食べたものと日記を書いた時間は毎日書いて、あとは自由に書いていた。
実家に住んでいるので母の作った料理を食べることが多いが、いざ毎日何を食べたかを記録しようとすると結構考える。 出てきたものをなんと表記するか、素材はなにか、味付けはなにか、見た目と自分の味覚で判断してから聞いて答え合わせをするのが日課になった。
日記を書いていた時間はいつも寝る前だった。
結果
日記を始めた日から昨日まで2020/10/04 - 2020/11/30 までの 58日間で集計したら以下のようになった。
- 書いた合計日数: 45日 (58日中)
- 連続して書いた日数: 41日 (10/04-11/13)
- 最も長かった文字数: 1943文字 (10/08)
- 最も短かった文字数: 100文字 (11/26)
- 一日の平均文字数: 692文字 (31181文字/45日)
11月中旬までは毎日書いていて、それ以降はあまり書いていない。 (正確にはあとからその日のことを振り返って書いている日が数日ある。) 量は書かなくてもいいから毎日続ける当初の目論見は一ヶ月以上続いたし、一日の分量もわりと書いていた。 明らかに日記を書くのがちょっと楽しかったのだろう。自分への義務感でこの数字にはならない。
よかったこと
- 時間を有効に使えた感触を味わえる
- 自分の感情を文章で言語化する練習
- (毎食メモしていたので)自分で作る食事の献立の参考になる
- (起床/就寝時間をメモしていたので) 生活リズムの可視化
- (寝る前に書く習慣ができていたので) 寝落ちではなく自分の意志でベッドに入るようになった
- 就寝前の内服薬を忘れずに飲むことができた
- 継続することの実績
当初の狙い通り、毎日を振り返ることで「気づいたら一日/一週間/一ヶ月が終わっていた」と時間を無駄にした感を感じることがなくなった。 これは結構大きな成果で、意識してみると何もやっていないようで何かをこなしていたりしているし、逆に本当に何もやっていない日も自覚できる。
それまでの感覚だけでなんとなくダラダラしていると罪悪感を感じて微妙な気持ちになるのとは違って、何もしていないから日記に多少書けるようになにかやろうと思えたり、最近活動的だったし今日はダラダラするか、と心の整理がつくことが増えた、気がする。
改善したいこと
- 夜型の生活リズムを改善できなかった
- スマホから書く手段を用意していなかったので書くのが億劫になることがあった
- すべて非公開を前提としていた記事
- 見返しづらいフォーマット
- さらに長い期間続ける
まず１つ目は生活リズム。日記を書いたら寝る、という習慣がついていたのでそれを利用して早く日記を書いて早く寝るようにすべきだった。
次に公開について。 毎日書くとプライベートな内容が多くなること、公開する文章を書くのはハードルが上がることから非公開前提で書いていたけれど、日記を続けているうちにTwitter上で毎日公開するログを書いている人を数人観測した。 すごいなぁ。公開前提で書くのもありだったかもしれない。
あとは日記のフォーマットについて。 Webアプリを作って見返せるようにしていたけど、見通しがあまり良くなかった。 1000字くらいある記事が並んでいると、ぱっと見で何をしたかを振り返れないので、箇条書きの項や目次欄をつくるなどの見返しやすいフォーマットでかけるようなテンプレートを用意すればよかった。 当初予想していたよりも長めの文章を書いていた日がそこそこあったのも一因。
最後に
(ブログではない、純粋な)日記を書いてみる試みは総じて良かった。 自分の行動に自覚的になれるし、案外楽しい。
夏休みの1行日記なんかはまとめて書くタイプだったし、今まで継続的に日記を書けたことはなかったが、やってみると思ったより続いて(一ヶ月だが)自分で驚いた。
他人に公開しないものは今回の日記の続きとして、特に公開して問題ないものはブログとして、一日の記録を気軽に書く感じで無理なく続けていきたい。
はてなブログに乗り換えた
昨年に作ったブログの公開場所をはてなブログに変え、名前も「やんまーのブログ」と改名した。
以前は Firebase Hosting 上に、 Nuxt.js の Generate モードで生成した HTML ファイルを公開していた。
移行するにあたって次のことを行った。
1. gimonfu による記事管理
はてなブログは Markdown で記事を作成でき、これが乗り換える後押しになった。
Markdown の記事は、以前のブログでも GitHub 上で記事を管理していたので、今回も同じことを行いたいと思っていた。
そこではてなブログの CLI を作り、GitHub上のリポジトリと同期するようにした。
はてなブログはAPIを公開しており、これを使って Markdown ファイルをアップロード、ダウンロードしている。
はてなブログの CLI には、既に blogsync というソフトウェアがある。
当初はこのソフトウェアを使おうと思っていたのだが、新規記事投稿の部分が自分の思うように行かず、APIを触っているうちに、全部作ったほうがいいのでは？という気持ちになり CLI が出来上がってしまった。
blogsync と gimonfu はどちらも1記事につき、1ファイルで、ファイル先頭に YAML Front matter といわれる YAML 形式の記事情報を含む。 またURLの構造が記事ファイルのディレクトリ構造となる点も同じだ。
一方で、記事の投稿に関しては異なる点がある。
blogsync では、記事本文のみを標準入力で CLI に渡すが、 gimonfu では、対象ディレクトリ内にある新しいファイルを新規記事として認識し投稿する。
こうすると、CIを組み合わせれば、新規投稿時にも CLI を直接触らずに運用できる。
現にこのブログも、新規投稿時にファイルを追加して GitHub に push すれば、自動的にはてなブログも更新されるようにしてある。 (逆にはてなブログが更新されたらGitHub にも反映されるワークフローも設定している。)
gimonfu の使い方の詳細は README に譲るが、このブログのワークフローと同じものを GitHub Actions に指定すれば、記事管理がとても捗ると思うので是非活用して欲しい。 (なお、ワークフローの設定記事をQiitaに投稿した)
2. Zeit now を使った旧ドメインの転送処理
旧ドメインの記事を公開していた URL は全て、express.js を使って、今の記事に 301 リダイレクトするように設定した。(設定した内容)
Now を初めて使ったが、とても簡単にアプリケーションを公開できるので、さくっと作ったときなどに活用していきたい。
というわけで、これからはてなブログで更新していきます。 よろしくお願いします。
VirtualBoxでUSB機器を認識させる
前提
VirtualBoxは、ホストマシンにつながったUSB機器をゲストOSで利用できる。 また、ホスト側でドライバを用意しなくても、ゲストOS側でドライバを導入すれば利用できる。
ただし、以下の手順を踏んでUSBデバイスを有効化する必要がある。
ここでは、USBシリアル変換ケーブルを使ったシリアル通信機器を認識させることを目的として作業する。
- ホストOS: macOS Mojave 10.14.6
- VirtualBox: 6.0.14 r133895 (Qt5.6.3)
- ゲストOS: bento/ubuntu-18.04
作業
1. Extension Packの導入
(2020/03/24追記: homebrew caskにて導入できることを確認しました。$ brew cask install virtualbox-extension-pack)
Download VirtualBoxからOracle VM VirtualBox Extension Packをダウンロードする。
最新版は、VirtualBox x.x.x Oracle VM VirtualBox Extension Packの1行下のAll supported platformsがリンクになっている。 バージョンは自分のPCにインストールされているVirtualBoxに合わせること。 違うバージョンのものはインストールに失敗する。
VirtualBox6.0のDownloadページやVirtualBox5.2のDownloadページから、各バージョンのExtension Packがダウンロードできる。 今回は6.0.14用のExtension Packをダウンロードした。
ダウンロードしたファイルをダブルクリックすると、VirtualBoxのウィンドウが立ち上がりインストールが始まる。
2. USBデバイスフィルターに機器を追加
Oracle VM VirtualBoxマネージャーを開き、目的のVMにカーソルを合わせて右クリック -> 設定 を開く。
ポート -> USB を開く
USBコントローラを有効化にチェックを入れる。
USBデバイスフィルター -> 右横の+アイコンをクリック -> 目的のデバイスを選択する。
3. VMを起動(再起動)する
Javascriptにおける、forとforEachの比較
知人に質問された内容への回答を兼ねて、Javascriptにおける繰り返し文の記法を振り返る。
この記事では、同じ結果を出力する繰り返し文を、次の２つの文法で記述し比較する。 - for文 - forEach()メソッド
他の記法には言及しない。
配列の要素を出力する
for文と同様に、forEach()メソッドも繰り返し処理をすることができる。
しかし記述方法は異なり、forEach()は配列のメソッドである。 引数にはコールバック関数(今回はitemを引数とするアロー関数)を渡す。
渡されたコールバック関数を配列の各要素に対し実行することで、繰り返し処理が実現できる。
// for文で要素を羅列
const items = [ "hello", 32, true ];
for( let i=0; i< items.length; i++ ){
console.log( items[i] );
}
// forEach()メソッドで要素を羅列
const items = [ "hello", 32, true ];
items.forEach( item => {
console.log(item);
});
上記２つの実行結果は一致し、以下を出力する。
hello 32 true
配列の添字と配列の要素を出力する
forEach()メソッドにわたすコールバック関数で、配列の要素だけでなく添字も受け取る方法を示す。
const items = [ "hello", 32, true ];
for( let i=0; i<items.length; i++ ){
console.log(`${i} : ${items[i]}`);
}
const items = [ "hello", 32, true ];
items.forEach( (item, index) => {
console.log(`${index} : ${item}`);
})
上記２つの実行結果は一致し、以下を出力する。
0 : hello 1 : 32 2 : true
上記のように、forEach()メソッドに渡すコールバック関数の、第一引数は配列の要素、第二引数は配列の添字を受け取るようになっている。
補足: console.log内で定義している文字列はテンプレートリテラルを利用し、変数の値を埋め込んだ文字列をつくっている。
まとめ
for文もforEach()メソッドも繰り返し処理を表記できるが、forEach()メソッドのほうが簡潔に表記できるので、ES6が認められる環境であれば、forEach()メソッドを使うのが好ましい。
ちなみに、forEach()メソッドだけでなく、filter()メソッドやfind()メソッド、map()メソッド等が使える場合は、こちらのほうが更に簡潔に書けるため好ましい。
その他、for...in文やfor...of文もあるが、ここでは言及しない。
参照
ソースコードをおいてあるgistリポジトリ: https://gist.github.com/basd4g/546dd9e378f93f6c24b8c8abab6fe187
mixi git challenge 12に参加した
2019/10/26、株式会社ミクシィの主催する mixi git challenge #12 に参加した。
株式会社ミクシイ
皆さんご存知、SNSのmixiやモンストを提供しているインターネット企業。 「コミュニケーション」を軸に様々な事業を展開している。
mixi git challenge
株式会社ミクシィが主催する、学生向けのgitを使ったコンテスト。 当日出会った人と2人でチームを組み、gitに関する問題を解く。
3時間半ほどの競技時間の中で、問題を起こしたリポジトリの数々が提供され、それを調査、復旧する。 問題を解くと難易度に応じたポイントを獲得でき、時間内に最も多くポイントを獲得することを競う。
2015年から開催しているようで、今回で第12回であった。
当日の流れ
午前中は
- git challenge チュートリアル
- ミクシィ社員さんからのLT2本(gitクライアントのTigについて)(社内のモバイルチームでのCI/CD活用)
だった。
お昼を挟んで競技開始。競技内容は公開できないが、過去問題が公開されているのでどんなことをするのかは以下が参考になる。
難易度ごとの問題を簡単なものから解いていった。チームメンバーと一緒に考えたり、分担したりを適宜組み合わせて進めた。
前半はそこそこのペースで進めたものの、競技後半は得点が伸びず勝利することは出来なかった。
3.5-4時間ほどの競技時間の後、解説、gitに関するクイズ、そして懇親会が行われた。 疲れたあとのご飯は美味しい(小並感)。
参加しての感想
gitはとても奥が深い。 今までgitの一部分しか使っていなかったことを痛感した。沢山の学びを得ることが出来たので、これからもっとgitを知ろうと思う。
ちなみに、翌日自分のリポジトリで、git challengeで学んだコマンドを用いてdangling commitを復旧しなければならない事態が訪れた。早速バリューが出ている。(自分が悪い)
学び
(問題の公開を避けるため詳細は省くが、)問題からgitを使った様々なトラブルの対処や便利な使い方を知ることが出来た。
Pro Gitという書籍の翻訳版が無料で公開されており、gitについての理解が深まると思うので、これから参加する方は是非参考にしてほしい。
参考
他参加者のブログ
TypeScriptでprivate methodを外部から呼ぶ
題名通りの話。
TypeScriptにてprivate methodを単体テストするとき、直接呼べないので困ることがある。 private methodを外部から呼べないのは正しいふるまいだが、テストプログラム側からも呼べないのは不便だ。裏技的ではあるが、TypeScriptの制限を回避して呼ぶ方法があるので紹介する。
前提 TypeScriptのprivate
JavaScript(ES6~)では、class記法が使える。
TypeScriptではclass記法で書かれたmethodにprivate修飾子をつけることが出来る。
private修飾子をつけると、同じクラス内からしかmethodを呼べない。
具体的な記法は下の例を参照のこと。
解決策
TypeScriptのprivate修飾子によるアクセス制限を回避する方法は2つある。
hogeClass.privateMethod()だと呼べないときを例に取ると
1. brackets記法
hogeClass['privateMethod']()と呼ぶ。
2. クラスをanyでキャストする
;(hogeClass as any).privateMethod()と呼ぶ。
前文との間に;を入れないとエラーを出すので注意。
例
// TypeScript v3.5.3
class HogeClass {
private privateMethod (): void {
console.log("private method")
}
public publicMethod ():void {
console.log('public method')
//呼べる
this.privateMethod()
}
}
const hogeClass = new HogeClass()
// 呼べる
hogeClass.publicMethod()
// 呼べない コンパイルエラー
// hogeClass.privateMethod()
// 呼べる
hogeClass['privateMethod']()
// 呼べる セミコロンが必要
;(hogeClass as any).publicMethod()
注意
TypeScriptの制限をすり抜けるということは、methodが存在するかどうか評価されないので、typoしたり存在しないmethodを呼ぶ危険性がある。
テストで使うのは仕方ないかもしれないけれど、基本はあまり使うべきではなさそう。
感想
anyでキャストして呼べるのはまだいいとして、brackets記法で呼べてしまうのは裏技感がすごい。 最近TypeScriptに入門したが、型があるのはありがたいといっても、意外と実行時にこのような抜けがあると感じてしまうことがあったり。
まぁjsやからな。
参考
GMOペパボのインターンシップに参加した
GMOペパボ株式会社(以下ペパボと表記させていただく) 福岡オフィスの2019年 夏インターンシップに参加した。
2019/8/21から2019/8/30の平日8日間、ムームードメインチームのフロントエンドエンジニアとして開発させていただいたので、その記録である。
↑オフィスの入口。
インターンシップ最終日にパートナーさん1の前で成果発表会をしたのだが、話しきれなかった部分もあるのでそれを消化する意味もある。 長文失礼したい。
ペパボとムームードメイン
ペパボとは
GMOペパボ株式会社は東京・福岡・鹿児島にオフィスを構えるGMOグループの企業の一つ。「インターネットで可能性をつなげる、ひろげる」をミッションに、インターネットで個人の表現活動をする人を支援するサービスを展開している。 レンタルサーバー「ロリポップ」、ハンドメイドマーケット「minne」等のサービスがある。
丁度インターンシップ期間中に企業紹介動画2が公開された。( 別verもある。)
ちなみに私はインターンシップでDiscover New Something3した。
福岡オフィスではホスティング系サービスの開発を行っていて、今回はその中のムームードメインチームに参加させていただいた。
ムームードメインとは
ムームードメインとは、インターネットの独自ドメイン取得サービスとしてペパボの中でも古くから続いているサービスの一つ。私も利用している。
インターンシップでしたこと
Nuxt.jsで作られているページへの機能追加を行った。
ドメインの価格一覧ページに価格によるソート機能を追加した。 ドメイン一覧表のヘッダ箇所にボタンが追加され、昇順・降順ソートが出来るようになった。
価格一覧のドメインを新規取得、更新、移管の価格順に並び替えることができるようになりました。ご予算に合ったドメインを見つけやすくなります。https://t.co/QL670SQXx0 pic.twitter.com/wLcWnas2Cm
— ムームードメイン (@muumuu_domain) September 5, 2019
他のインターン参加者は次のようなことをやっていたようだ。各々のスキルに合わせて、チームに配属され実際の業務に加わる形式でインターンシップが進む。
学んだこと - 技術の話
コードリーディング
今回のインターンシップでは新たなページの追加ではなく既存ページへの機能追加を行ったことから、既に完成しているドメインの価格を表示するロジックに手を加えることになった。 既存の実装の意図を汲みながら、他ページへの影響を与えないよう設計することに注意した。
コードを呼んでロジックとデータの流れを追うことは、経験が少なかったので新鮮だった。コードを読むのは面白かったが、実装の意図を汲むのは結構難しかった。似たような機能を持つOSSライブラリも見てみたりしながら設計を固めた。
↑かの有名なお言葉。
実際に動いているサービス
サービスの規模感、エンジニアや関わる人の人数、サーバーの構成や使用されている技術スタックを知れた。1つのサービスを俯瞰して、どのように動いているのかを学べたのは貴重な経験である。
またデザイナーさんとの分業の仕方やディレクターさんとの仕様の確認など、チームとしてサービスを支えている姿をみることができ、インターンシップの中で経験することもできた。
issueとPullRequest
恥ずかしながらチーム開発を今夏まで経験してこなかったので、GitHubのissueとPullreqを使う機会がなかった。 ソフトウェアの実装に関する相談やまとめ、記録としても非常に有用で期間中たくさんお世話になった。
コードレビューは学ぶことがとても多く、これからの私のコードにたくさん取り入れていきたい。(既に恩恵を享受している。)
PullRequestを出す際に参考にしたいのがこちら↓。私が出したプルリクがこれにどこまで沿えていたかはおいておいて(笑)、自戒の念としても今後の参考のためにも残しておく。 特に私のようなプルリク歴の浅い方にお勧めしたい。
参照元: ぼくのかんがえたさいきょうのPullRequest
テスト
個人で開発しているとテストを書くという発想に至らず、今までテストを書いてこなかった。そのため、今回のインターンシップでテストを書いたのもとても良い経験だった。 Vueコンポーネントを自在に手のひらで転がせるよう、転がれ転がれと念じながら過ごした(嘘)。
テストを書くといいことが沢山ある。他人のためになるだけでなく、既存の実装や構造を振り返るいい機会にもなるし、自分がのちに実装するときに恩恵(正しい動作を保証できる4)を享受できる(した)。
感じたこと - ペパボの話
ペパボは次の「わたしたちが大切にしている3つのこと」を掲げている。
- みんなと仲良くすること
- ファンを増やすこと
- アウトプットすること
パートナー皆さんにこれが浸透していて、日々実践されているのを感じた。
みんなと仲良くすること
まずパートナーさんが優しい。インターン生に対してだけでなく、職種やチームの壁を超えてそれぞれが仲が良い、(いい距離感だ)と感じた。 インターンシップ期間中、私をインターン生と知らないパートナーさんが声をかけてくださってお話したり、社内のシニアエンジニアの方に実装について聞いたり、いろんなパートナーさんと接する機会があったがどの方も親切だった。
↑サポーターのづっきーさんに助けられている姿。づっきーさんにも沢山仲良くしていただいた。そして沢山助けけていただいた。
ファンを増やすこと
会社やサービスを好きな人が多い。(観測範囲において。) しかし会社に魅力があるだけでなく、パートナーさんにファンになってしまうような惹きつける力がある。これこそ「ファンを増やすこと」を実践されている姿だと感じた。
↑インターン生が貰えるsuzuri5のキャラクター「スリスリくん」のぬいぐるみ。非売品でパートナーさんも簡単には手に入れられないらしい。
アウトプットすること
開発でGitHub Enterpriseを利用しており、issueやPullreqもアウトプットの形だと思う。 そこに過去の経緯が残されていることで、今回も開発の資料としてとても参考になった。
その他インターンシップ中に紹介された参考資料がパートナーさんが社外に公開したスライドであったことや(先程のさいきょうのPullReqもその一つ)、パートナーの方が登壇する技術イベントに参加させていただいたこと等、アウトプットされているのを肌に感じた。
LT経験の浅い私のためにLTの機会を増やして頂き、インターンシップ期間中に合わせて3回発表をした。issueもPullreqも書いたし、私もパートナーさんを見習ってもっとアウトプットしていきたい。
感じたこと - 福岡の話
人生初の九州上陸だったが、福岡は住みやすそうな街だった。
コンパクトシティ
空港から街が近い、というよりも街に空港があるので移動が楽。(成田空港、お前のことだぞ。6)
食べ物が美味しい
ペパボの福岡インターンシップで、日報にご飯が美味かったと書かれるのはあるあるらしい。もちろん私も書いた。 一つ一つ紹介しているとそれだけで記事になってしまうので、写真でまとめて振り返る。
帰りに空港でお土産をみて、明太子とごまさばを食べそびれたことに気づいた。
まとめ
上述の通り、技術を学ぶことと会社を知ることの2側面ともに得るものが多かった。
実は応募前は私の技術力が通用するのか不安だった。しかし、ペパボの皆さんに本当に優しく丁寧にフォローしていただいて、インターンシップ期間内に機能をリリースできた。
また同じ期間に他チームへ配属されていたインターン生にもよい刺激を受けた。特に私が新しい技術分野に触れていくモチベーションに繋がった。同年代の強い人すごい、みんなすごい(小並感)。
次は冬にも同様の就業型インターンシップを予定しているそうなので、この業界を考えてる人にぜひ勧めたい。
おわりに
インターンシップ中に関わらせていただいたた皆さんにとてもお世話になりました。
特にサポーターのづっきーさんには技術面で沢山サポートしていただきました。初日緊張してパスワードを永遠にtypoしていたのが懐かしいです。
本当にありがとうございました。
↑パートナーさんと我々インターン生。最高の夏。
