『改訂第3版 すらすらと手が動くようになる SQL書き方ドリル』をやっています
これは 積読本 Advent Calendar 2017 の23日目です。
こんばんは、める（@c5meru）です。
今回積読本ということで、選んだ本は表題の通り、
『改訂第3版 すらすらと手が動くようになる SQL書き方ドリル』
という本です。
まず最初に、お詫びをさせてください。
この本、まだ全部おわってません…ごめんなさい(´・ω・｀)
必ずや今年中に全部おわらせるぞ！という宣言とともに、途中までではありますが、取り組んでみた感想などなど、書いてみようと思います。
なんでSQLをやろうと思ったの？
会社でいろいろ教えていただいている@mikedaさんがインフラのほうに詳しい方で、クエリのパフォーマンスの話がよく出るので、チンプンカンプンじゃダメだな、と思った次第です。
あとはまあ、HTML、CSS、JavaScript、PHP、Rubyとやってきて、これといって特化したものがないのが悩みなのですが、ちょっと前に、Rubyをコアスキルにしたいな、と思うきっかけになる出来事がありまして、サーバーサイドをやっていくならSQL文は押さえておきたいな、と思いました。
どんな本なの？
SQL文のケースごとに小さな章がたくさんあって、それぞれ、例題→解説→練習問題、という順番で進んでいきます。
練習問題はSQL文の穴埋めからフリーテキストまで5問あり、高校数学の教科書・参考書みたいな感覚で、ノートを用意し、手で書いて覚えられるようになっています。
なんで積読になっちゃったの？
例題の解説で小さく備考として書かれていた要素がしれっと練習問題に出てきて、比較的序盤なのに分からないことが積み上がって、先に進むのがしんどくなってしまったためです。
あとは、ペンとノートを用意して作業環境を整えるのが（普段やってない分）意外とハードル高かったというのもあります。笑
やってみてどうだった？
アドベントカレンダーを書くにあたり、「備考もすみずみまで読む」「作業環境を整える」というハードルを乗り越え、章をいくつか進めてみました。
積読本になっている間、お仕事で集計のために何度かSQL文を（見よう見まねで）書いたこともあり、はじめからある程度わかる状態で始められたのはとても良かったです。
当たり前ですが「わかるようになると楽しい」というやつです。なので、なにもわからない初心者だとキツイ本だったのかも？
章の分け方はとても細かいので、チョットデキルくらいの人がケーススタディ的にやるのに向いてると思います。
自分は受験勉強を楽しんでたタイプだったので、ペンとノートで書いていくのは、それなりに楽しいです。普段やらなくなっちゃったから余計に。笑
逆に、ペンとノートで何かやるのが苦手な人には、向かないかもしれません。まあ、付録で学習用ソフトもついているので、そっちでやるといいのかも。
まとめ
そういうことで、本の紹介をさせていただきました。
わが家にはまだまだ積読本がたくさんあるので、年末年始も利用して、ガンガン読んでいこうと思います。
闇に飲まれてしまったときは、もっと深い闇に飲まれればよかった
これは Dark - Developers at Real Kommunity Advent Calendar 2017 の22日目です。
ただのポエムになってしまったので、そういうのが苦手な人は、ブラウザバックしてください。
Darkのコミュニティは、今年からになります、める（@c5meru）と申します。
家が近所なメンバーが多かったことと、旦那である＠polidogの知り合いが多かったこともあり、すんなり馴染むことができて、いつもお世話になっております。
去年の今ごろは「年が近い友達がほしい」と、よく嘆いていました。
現在は、近い年齢のDarkメンバーに囲まれて、毎日Slackで楽しく話しながら毎日を過ごしています。とてもありがたいことです。
実は、社会人になってからの数年間、年の近い人達が本当に苦手で、恐怖で、たまりませんでした。
そのあたりのことを、上手く書けるかわからないけれど、書いてみようと思います。
自分が東京へやってきたのは、大学2年生の7月でした。
東京に引っ越せば、サークルのみんなともっと仲良くなれるかもしれない。もっとサークルのために力になれるかもしれない。
そう思って、有り金のほとんどと奨学金を駆使して、わたしは東京へやってきました。
でも、残念ながら、その希望が叶うことはありませんでした。
サークルのメンバーとのあいだにあったのは、金銭感覚の違いとか、根回しなどの政治力とか。そういうものが絡んだ、どうにも出来ない理由でした。たぶん、場違いなところだったんだと思います。
掛け持ちしていた別のサークルのメンバーや、学科の友人とは仲良く楽しくやれました。
しかし先述のサークルの規模はとても大きくて、人数も、コミットした時間も、そっちのほうが圧倒的でした。だからなんだか、それからずっと、トラウマになってしまったのです。
幸いなことに卒業後すぐ、同じ大学が母体の音楽団体に身を寄せることができました。
10〜20歳ほど年上の方が多い団体で、そこではみなさんとてもやさしくて、人に対する根本的なトラウマは大分癒されました。
ただしそこには当時、年の近いメンバーはほとんどいませんでした。
トラウマが癒された自分は、ヤケクソで新卒入社した生保レディをやめてIT業界に飛び込みました。
そこでは年の近い人、年下、年上、まったく関係なく、たくさんの人が業界のために活き活きと働いていました。
そんなIT業界に慣れてきた頃に見つけたのが、Darkのもくもく会でした。
最初は年の近いメンバーたちにおっかなびっくりで、いまでもデスマス調が抜けないこともありますが、みんなに優しくしてもらって、毎日楽しく過ごしています。
なにはともあれ、優しく迎え入れてくれて、ほんとうに感謝しています。
主宰のarata 氏、そして、我々夫婦の出会ったgotanda.jsの主宰であるhoto氏を始め、メンバーのみなさまには改めてお礼を述べたいと思います。ありがとうございます。
不束者ですが、今後ともどうぞよろしくお願いします。
フルリモート旦那のすゝめ 〜あれから1年〜
これは 妻・夫を #愛してる ITエンジニア Advent Calendar 2017 の11日目です。
今年も参加してみました。める（@c5meru）です。旦那は @polidog です。
昨年は新婚だったので以下のような記事を書きまして、大きな反響をいただき、ありがとうございました。
今年は「あれから1年」ということで、もうちょっとみなさんがフルリモートの配偶者との暮らしをイメージしやすいように書こうと思います。
フルリモートがひとつの働き方として、より一般的になりますよう...
もくじ
- フルリモートって？
- わが家のフルリモート旦那
- デメリット（わが家の場合）
- メリット（わが家の場合）
- フルリモート旦那のすゝめ
フルリモートって？
フルでリモートワークなことです（雑）。
リモートワークについては以下をご参照ください。
わが家のフルリモート旦那
わが家のフルリモート旦那は、いまのところ、コワーキングスペースなどをもたず、在宅で仕事をしています。
週1日、数時間、打ち合わせのために出社しています。この打ち合わせをのぞき、勤務時間の指定やコアタイムなどはありません。
業務委託やフリーランスだったり、自分の会社だったりするのではなく、いまは、いち正社員として勤務しています。
ちなみに自分は、きっかり9時〜18時出社で、最近の悩みは早起きがつらいことです。
フルリモート旦那のデメリット（わが家の場合）
普通はメリットから書くものだと思いますが、そうなると良いシメ方が思いつかないので、先にデメリットを書きます。笑
「いつどこで仕事をしてもいい」となると、自分だったら全く仕事しなくなりそうだなーと思うのですが、旦那さんはそういうこともなく、しっかり仕事しているようで、本当にすごいと思います。
ただし、お仕事のピークタイムがPM21:00〜AM3:00くらい、なのです。なんだか大学生のレポート課題のようですが、本当にそうなんです。
夜中のほうが集中できることがあるのは確かですが、毎日となるとどうなんだろう、、でも、本人曰く、この時間帯がベストなんだとか。
ということでデメリットは、おおむねこのタイムゾーンの違いに由来します。
だいたい自分がゴミ捨て担当になる
ゴミ捨ては基本、朝8:00ですからね...自分が寝坊しようものなら、ほぼ次回に持ち越しです。
生活時間帯が真逆になると寝顔しか見ない
「寝顔しか見ない」というレベルになることはあんまりないですが、どっちかが疲れてて、寝坊したり、早めの就寝をしたりすると、そうなることがあります。
まあでもこれはフルリモートに限らず、シフト勤務の配偶者さまなら、あるのかな。
特に理由もなく働きたくなくなる
相手のお仕事タイムに自分が熟睡しているので、相手が仕事しているのを見ることが少ないためか、
「自分は満員電車で朝9時に出社して、規定の時間頑張ってるのに、のんびりマイペースで働く旦那さんに比べてお給料少なすぎ...なんか、何やってるんだろう...」
みたいな無力感に襲われてしまうことがあって、働きたくなくなることがあります。
そうはいっても専業主婦になりたいとは思っていないし、お仕事がんばりたいと思っているので、もちろん働きますよ。笑
時間＝バリューではないことは言うまでもないですし、旦那さんは自分よりも、はるかにすごいエンジニアだからこそ、のんびり働いても十分なバリューが出せるんですよね。だからそうやって悩むのは不毛なんです。たぶん。
フルリモート旦那のメリット（わが家の場合）
どの項目もやっぱり、自分にはない「場所と時間の自由」があることに、関係していますね。
今年の初出社に財布を忘れて、会社から初詣に出かけるまでの間に、届けてもらったことがあります...ありがたやありがたや...。
お洗濯や、ごはんの準備がされている
これは去年も取り上げましたねｗ
旦那さんは、お洗濯が外干しじゃないとイヤみたいなので、きっちりやってくれます。すごい。
ごはんは、自分が作るの苦手なので、、、とても助かっています(´；ω；｀)
宅配便が無限に受け取れる
宅配ボックスでいいじゃん、という話ですが、一人暮らしのときにとても悩まされたので、感動しています！！！ わーい！！！
一緒にいられる時間がたぶん長い
デメリットで「生活時間帯が真逆になると寝顔しか見ない」と書いたので、一見矛盾しているように感じると思います。
しかしおそらく、エンジニア以外の職種で頑張っている男性は、けっこう帰宅も遅かったり、付き合いで飲みに出かけてしまったり、、ということが多いのではないでしょうか？
奥さんがごはんを作って待っていても、急な飲み会で深夜帰りだったり、ブラック企業で終電帰りが続いたり。。そんな結婚生活を送っている知人の話を聞くと、自分は本当に恵まれているんだなー、と思います。
フルリモート旦那のすゝめ
ということで、今年はフルリモート旦那のデメリットとメリットに分けて、お伝えさせていただきました。
フルリモート旦那は「場所と時間の自由」があるので、いろいろ融通がきいて、おすすめです。
また子供が生まれたりとかしたら、いろいろ変わるんだろうな。
おっと、そういえばここまで、「愛してる」要素がありませんね。笑
新婚ホヤホヤの去年と違って、お互いいろいろ分かってきて、だからこそ、改めて言葉にするのは難しいような「居心地の良さ」のようなものを感じはじめています。
けれど旦那さんの、エンジニアとしての優秀さに嫉妬してしまって、頑張ってる旦那さんを素直に認められないことがあったり、自分自身、子供ができる前にあれもこれも…と生き急いでしまって、あまりゆっくり一緒にいられなかったりすることもあって、本当に申し訳なく思っています。
いろいろ迷惑をかけてしまうことも多々あるとは思いますが、愛してる旦那さんは、帰る場所であり、頼れる先であることは間違いありません。
こんな妻ではありますが、引き続きどうぞ、よろしくお願いいたします。
polidogへ感謝と愛を込めて。
Rails Developers Meetup 特別編 に行って、「あの」伊藤さんとお話をさせていただいた
Rubyを使っている人が調べ物をすると必ず出会うであろう、伊藤淳一（@jnchito ）さんの著書「プロを目指す人のためのRuby入門」出版イベントに行ってきました。
著書はこちら
動機は単純で、物理の伊藤さんがひと目見たかったからです。
自分は伊藤さんの記事と、その視点がとても好きで、そこには以下のような理由があります。
- 文系出身エンジニアだから（自分も文系出身なので）
- 元バンドマンだから（自分も音楽漬けだったことがあるので）
- フルリモートだから（旦那がフルリモートなので）
- 読む人、相手の気持ちを考えているから
- そこに裏付けられた分かりやすさがあるから
などなど。
今日の話で出ていたものもありますが、過去の記事でも取り上げられていたことがあります。
↓文系エンジニアのくだり↓
↓読む人の気持ちを考えるくだり↓
そんな感じで、Qiitaやブログをちょいちょい追っかけていたため、
「おお、本物が見られるのか」という軽いノリで参加してみたのでした。
（リファクタリングコンテストは、前日の深夜2時まで粘って記念参加したけど、全然歯が立たなかった...）
いざ会場に着くと、自分はミーハーなので登壇位置の目の前に陣取りました。笑
乾杯してビール飲んで、ピザ食べて、質問タイムがあって、その後は「分かりやすい技術記事を書くために」「技術書を読む価値」などについての、伊藤さんのありがたい講演がありました。そのあたりはきっと、他の参加者の方が詳しく書いてくださるかな、と思います。
そして、講演の後は「リファクタリングコンテスト」でした。
お題は以下のリポジトリです。
挙手制で、PRの内容を「タケシくん」に語りかけるように説明してください。とのこと。
自分もPR出してみたのですが、他の参加者のPRを見るとあまりにも圧倒的すぎて、挙手は控えていました。
数人「タケシくん」への説明を終えたところで、突然、司会の平野さん（@yoshi_hirano）が、なぜ今回このような形にしたかというと...というお話を始めました。
「もともとは、8月のイベントでやったように、伊藤さんにコードレビューをやってもらおうと思っていました。」
↓8月のイベントはこんな感じだったようです↓
「ところが伊藤さんが、『コードレビューを受けるのがつらくなったときは』という記事を読んで、参加者の方々にコードレビューをしてみてもらいたい、ということで、今回このような形で、みなさんがコードレビューをするという設定になりました」
えっ、ちょっと待って、それ自分の記事では...と思っていたら、
「その記事を書いた、めるさんがここにいらっしゃるということで」
なぜか立ってマイクを持つことになり、伊藤さんと数分間、対談させていただきました。
伊藤さんからも、
「東京に来たら、めるさんと話をしようと思っていました」
とおっしゃっていただけて、控えめに言っても、夢のようでした。
実は、こんな風にツイートしてくださっていたのは存じていて、
僕の記事と同僚の @mah_lab のスライドが載ってた。この記事についてのコメントは・・・うう、ツイッターじゃ収まらない💧
— Junichi Ito (伊藤淳一) (@jnchito) 2017年11月11日
コードレビューを受けるのがつらくなったときは - めるノート https://t.co/EJY0FQISN5
それについて直前の質問タイムで挙手したらちょうど時間切れだった、という偶然がありました。ネタバレしなくてよかったｗ
自分が座っていた位置も関係者席っぽい感じだったのでアレですが、帰り道で話しかけてくださった参加者の方々から、
「あの流れ、前もって言われてたんですよね？」
と何度か言われたのですが、いや、もちろん、まったく言われてませんでした！！！笑
思いがけず、きっと一生忘れないんじゃないか、という機会をいただけて、本当に本当に嬉しかったです。
伊藤さん、平野さん、本当にありがとうございました！
あー、一緒に写真撮ってもらえばよかったな、でもRubyを書いていれば、きっとまた会えるかな。
なんて思いながら、忘れないために書いておきます。
コードレビューを受けるのがつらくなったときは
そういうときがよくあります。
コードレビューがある会社は今が初めてだけど、きっとこれから先もコードレビューがある限りは、なくならない気持ちなんだと思います。
だから、そんなときに振り返れるようなものを残しておきます。
「コードレビュー つらい」でググってみると、はてな匿名ダイアリーのこんな記事が見つかりました。
さすがに、ここまでヒドいケースを経験したことはないし異常だと思ったけれど、以下のくだりは自分の胸にすごく刺さりました。
私はプログラマに向いていないんじゃないかと思う。よいプロダクトを作る上で強い言葉を交えた議論が必要不可欠ならば、それに強いストレスを感じてしまう私はプログラマとして適正がないのでは？
刺さったのですが、それでも自分はここでやっていかなくちゃならないと思っているので、つらくなったときにいつでも読み返せるよう、見つけた記事・資料をまとめておきます。
www.slideshare.net
ソニックガーデンの方です。
7つの秘訣は、
- レビューの観点を明確にすること
- 我が身に返ることを恐れずに指摘すること
- 何故悪いコードなのかを論理的に説明すること
- 良いコードについて共通認識を持つこと
- 小さい単位でレビューを繰り返すこと
- 指摘は素直な気持ちで受け入れること
- 指摘は人格否定でないことを理解すること
レビューを受ける立場として、6と7は「あっ、そうだよな」と自身の未熟さに気づいたところがありました。
一方で、1や4のような、共通認識とか、前提としての観点っていうのもあまり明確でないことがあるので、それは自分からある程度提示したり、問題提起したりで改善できそうです。
ペパボの方で、新卒のメンバーに向けてお話されたそう。「コードレビューのやり方」な話です。
勉強会などでよくペパボの方を見かけますが、ほんと、いい会社なんだなあ、という感じがします。
印象に残ったところだけ、かいつまんでしまいますが、
（主に新卒など駆け出しのエンジニアが）コードレビューをやる上で大切なのは、コードを読んで理解することだそうで、
- なんでこうなっているのか？を考えながらコードを読む
- わからないところがあると悩む
- 10分悩んだら自分ではわからないと判断して聞く
この「なんで・悩む・聞く」を繰り返すとできるようになる、とのことでした。
あとはコードレビューは「伝え方が9割」ということで
- 理由を書く
- 褒める
- 提案する
- 提案にも理由を書く
- コードで示す
ただし、このへんは上級者じゃないと難しいかも？だけど、LGTM画像、絵文字、顔文字で「めでたく」盛り上げることはできるよね、という感じでシメられていました。
ここからは自分の感想になりますが、コードレビューはとてもデリケートだから、レビュアーはいろんなこと意識しないといけないなって思いました。
指摘されたとき、レビューイ側は「じゃあどうすればいいの！」ってなっちゃうとき、ありますもんね。
LGTM画像については、以下の記事でも「叩かれすぎて凹む問題」で取り上げられていました。
http://ogihara-ryo.herokuapp.com/blogs/1
あとは、まあ、やっぱり「悩んだら聞く」ことが大事だなと。
自分もレビュアー側のとき、さっぱり分からずチンプンカンプンだったらレビューイに聞くようにしてます。当たり前ですがｗ
レビュアー側が「聞く」ことは初心者じゃなくても大事だということで、以下の記事でも取り上げられていました。
そして、レビューイ側も「聞く」ことが大事だと、以下の記事で取り上げられていました。
レビューイ側としても「悩んだら聞く」こと、痛いほど、わかっているんですよね。。。
ちょっとしたCSSの設計とか、エラーハンドリングとか、書く前に相談すれば間違いないんですよね。
この記事で良いなって思ったのは「修正対応の有無はハッキリと」のところです。
MUST・THINK・INFO・TRIVIALなど、修正対応の必要性がわかると、自分がレビューイだったら嬉しいなーと思いました！今度やってみよっと。
よーし、いろいろ見てたら楽しくなってきたぞ。
わかるわかる！と読んでいたら、存じている方の2年前の記事でした。
すごい人だなぁ、と思っていたので、誰もが最初はそうなんだな、とも思えて、元気が出ました。笑
変数やクラス名について批判されるのもなんだかセンスがないと言われているようで辛い。
これもあるある！な感じで、こういうものこそ、具体的な提案とその理由がほしいですよね。
この記事くらいちゃんと説明してくれないと、エラーが出たりパフォーマンスに関わる問題じゃないので、センスとか才能の問題なのかな？ってなっちゃって、違うと分かっていても、自分を否定されたような気持ちになっちゃいますよね。
ということで、いくつか記事や資料を挙げてきました。
コードレビューがつらくなっちゃうときは誰しもあるけれど、だからこそ、自分が担当するレビューイにはそんな思いをさせないよう、つらさを胸に刻みながら、精一杯相手のことを思ってレビューしよう、という感じでしょうか。
将来、後輩ができたときには「わかりやすくてやさしいから、あのひとにレビューされたい」って思われたらいいなあ。うん。
船の中で飛行機を間近に見ながらPHPの話ができるイベントを開催しました
嘘は言ってないぞ。嘘は。
お越しいただいたみなさま、本当に本当にありがとうございました。
あの場で初めてお会いした方々も含めて、またみなさまとゆっくりお話できたらな、と思います。
本日で、望月姓としては1歳、わたくし個人としては26歳を迎えました。
去年はいろいろ目標をたてましたが、これからの1年はその延長線上で、ゆっくり目の前のことに取り組めたらな、と思います。
どうぞ、よろしくお願いします。
以下、今日でラストにするので許してくださいw
誕生日の10/12が数日後に迫っているので、ほしいものリストを晒します😊https://t.co/vnt4tQpPHR
— める (@c5meru) 2017年10月8日
Rails × Webpackerで、CoffeeScriptをES2015にリプレースしました
表題のとおりです。
詳しいスライドはこちら
もっと詳しいブログはこちら
最初にサービス側を置き換えて、そのあと管理画面をやったのですが、だいぶ慣れてきました。
とはいえ、スライドの方にも書いたんですが、やっぱり詳しい方がいないと辛いです。
エラーを見るたびに追い詰められる気持ちになります...(´；ω；｀)
この週末が終わればもうちょっと時間に余裕ができると思うので、ちゃんと勉強します！
よかったら以下、ポチってください😊
誕生日の10/12が数日後に迫っているので、ほしいものリストを晒します😊https://t.co/vnt4tQpPHR
— める (@c5meru) 2017年10月8日
一週間のうち4日がエンジニアのイベントでした
10/9に一大イベントを控えていたにもかかわらず、その前週のスケジュールがすごいことになっていました。
まあ、文化祭（？）シーズンだし、しかたない。
HTML5 Confernce 2017打ち上げ
HTML5 Confernce 2017のボランティアスタッフだったので、公式スタッフの方、スピーカーの方、スポンサーの方なども参加する打ち上げに行ってきました。
ぼっち参加だったので、とても不安だったのですが、いろいろな方に声をかけていただいて、たくさん名刺交換もさせていただきました。
お話したみなさま、ありがとうございました。
お話する人の中には、業務でWebの開発をしていなかったり、そもそもエンジニアじゃなかったりする方もいらっしゃって、それでも独学でReact/Reduxやっていたり、当日LTされていたりなどなど、アグレッシブに活動されていて、ほんとうにすごいな、と思いました。脱帽。
毎回バイタリティあふれる方々に出会えるので、来年もボランティアスタッフやりたいなぁ。
PHP Conference 2017
前職ではほんのちょっとPHP（Wordpress, cakePHP, fuelPHP, Laravel, ECCUBE）をやっていたのですが、最近はほぼ触っていません。
今回は勉強というよりは、知っている方々の活躍を見に行った感じになります。笑
スライドと喋りのバランス、スライドのデザインや図の使い方など、慣れている方の発表はとても勉強になりました。
完全にスプラトゥーンのプロだと思っていた知り合いが、お仕事でもプロだということが分かって、いやぁ、天は二物を与えるのだなぁ、と思いました。
かねてより行ってみたいと思っていたイベントだったし、来年は時期的に難しそうなので、行けてよかったです。
全体的に、HTML5カンファレンスよりラフな雰囲気だったかな。LTも自由な感じだったし。筋肉とか、ライザップとか。
タイミングが合う年があれば、LTやってみたいかも？
Gotanda.js #9
今回の会場は、自分が初めて Gotanda.js に参加したときの会場でした。
自分が初めて Gotanda.js に参加した
ということは、自分の人生を大きく変えた場所でもあったりします。まあ、それはおいといて。笑
初めて Gotanda.js に参加したときは、登壇者が話していることが全く分からなくてショックで、でもなんとなく Gotanda.js の雰囲気が好きになったので、懇親会も残ってみました。
そのときに話しかけてくださった方々とは、今も仲良くさせてもらっています。いやはや、ありがとうございます。
あれから1年ちょっと、ほぼ独学ではありますが、自分なりに最近のフロントエンドを勉強してみて、話している内容がだいぶ分かるようになったことが、とても嬉しかったです。
いざ業務とかでやろうとすると、相変わらず実力不足を感じますが、最初に比べたら大きな進歩だな、と思いました(｀・ω・´)笑
Vue.js meetup #5
先述の通り1年ちょっと前から、最近のフロントエンドを知りたいと思っていて、でも身近なところに手がかりがまったくなくて、勉強会に出たり、情報収集をしたりして自分でちょっとずつ書いてみたりしていました。
そのときはReactが流行っていた頃だったのですが、どうもとっつきづらくて困っていたころに、Vue.jsの2系リリースがあったのを覚えています。
それで試しにやってみたら、日本語ドキュメントも充実してるし、とっつきやすそうだし、Single file component すげー！ってなったのでした。
あと、日本のVue.jsを担っている、@kazupon さんを始めとする方々がすごく優しい。これとっても重要です。
（ほんとうは技術や翻訳でも貢献できたらいいのですが、それはもうちょっとあとの話だとして笑）、今すぐなにか貢献できることはないだろうか？と思ったところに、スタッフの募集がかかったので、参加してみたのでした。
前々回は一般枠で参加した Vue.js meetup でしたが、今回はVue.js日本ユーザーグループのスタッフとして参加しました。
特に大きなトラブルもなく、自身も楽しみながら参加することができました。よかったです。
こちらでお話したみなさまも、ありがとうございました。
ということで、ざっと感想をまとめて書きました。
すごく楽しい一週間でした。
よかったら以下、ポチってください😊
誕生日の10/12が数日後に迫っているので、ほしいものリストを晒します😊https://t.co/vnt4tQpPHR
— める (@c5meru) 2017年10月8日
iPhone6Sのまま、SoftbankからIIJmioに切り替えました
携帯代がすごいことになっていたので、今月から切り替えました。
今回は手順だけ、ご紹介します。 流れとしてはこんな感じ。
- ソフトバンクメールが使えなくなるので対策しておく
- 「音声通話パックみおふぉん」を購入
- SIMロックを解除しておく
- Softbankに電話してMNPの予約番号をもらう
- IIJmioのページから申し込みをする
- MNP開通の電話をする
- SIMカードを入れ替えて設定をする
では、ひとつずつ見ていきましょう。
1. ソフトバンクメールが使えなくなるので対策しておく
ソフトバンクメールで連絡をとっている人は、gmailなどの他のアドレスに切り替えてもらいます。
また、ソフトバンクメールで登録をしているツールがあれば変更しておきます。
2. 「音声通話パックみおふぉん」を購入
先に買っておくと申込みがスムーズなので、買っておきます。
Amazonからだと安く買える＋割引がつきます。
3. SIMロックを解除しておく
店頭にいくと有料（3,000円）ですが、My Softbank から手続きをすると無料です。
あとはSIMを入れ替えるだけ、というところまでやっておきます。
4. Softbankに電話してMNPの予約番号をもらう
こちらに電話します。
引き止めるためか、いろいろ言われますが、ひととおりスルーします。
後ほど詳細を確認しますが、このときに、解約するために必要な金額の確認がされると思います。
電話を切ったあとしばらくすると、ショートメールで予約番号が送られてきます。
5. IIJmioのページから申し込みをする
「パッケージをお持ちの方」、「MNPの予約番号をお持ちの方」、という選択肢を選ぶようにしてください。
手続きには、身分証明書の写真データが必要です。
2〜3日で、登録した住所に新しいSIMカードが届きます。
6. MNP開通の電話をする
新しいSIMカードと一緒に、MNP開通をするための電話番号が書いた紙も同封されているので、そこに電話します。
すべて自動音声ですが、9:00〜19:00の受付なので、注意しましょう。
7. SIMカードを入れ替えて設定をする
Wifiがあるところで設定すると、とても楽です。
新しいSIMカードと一緒に、プロファイル設定用のQRコードが届きます。
SIMカードを入れ替えて、開通完了のメールが届いたら、QRコードからプロファイルをインストールします。
以上で手続きは完了です。
解約するのに必要なお金
Softbankを解約するときに、主に注意するべきなのが、
です。
マイソフトバンクから確認できると思うので前もって確認しておくと良いと思います。
自分は更新月でもないし、割賦金もちょっと残っていたので、最終引き落とし日に22,250円+既存の料金をとられます。。。
とはいえ、これまで携帯代がめちゃくちゃ高かった（12,000〜14,000円くらい...）ので、2〜3ヶ月くらいで元がとれる感じになるので、エイヤ！でやっちゃいました。
ちなみに、IIJmioのプランは、音声通話パックのライトスタートプラン（2,220円〜）です。
IIJmioのほうでは初期費用で＋3,000円が初月にかかります。
まとめ
今までau、Softbank、と移ってきましたが、今回は、スキマ時間でポチポチっと手続きを進められるスピード感に感動しました。
プラン変更も手元でできちゃうんだそうです。すごい。電車でアニメ見たくなったら、一時的にプランあげたりするのもいいかも。
もちろん金額についても言うことなしです。
先月あたりから固定費を2万円くらい削っているので、ちょっとラクになるかな、と思います。
家計簿の付け方も前と変えてみたので、節約＆貯金、がんばります！
Rails のフロントエンドについて社内勉強会をした
あまりフロントエンドに詳しい人がいなかったので、自分がたどたどしい資料をつくりました。
流れとしては、
だったのですが、時間が思ったよりなさそうだったし、みんな知ってるかなって思ったので
1. npm, yarn, webpack, browserifyの説明
を端折って進めたのですが、やっぱりあとから戻ることになりました。笑
前提の説明、大事ですもんね…(´・ω・｀)
そのなかで、いちばん困ったのが、
「WebpackとSprocketsってどう違うの？」
という質問でした。
試しにちゃちゃっと調べてみたのですが、あまり細かく比較している情報が見つけられませんでした。。
Sprockets捨てたいのはわかったから、もっと詳しく〜！という感じでした。
Webpackだと、コンパイルできる言語の範囲が広がる感じなんですかねぇ。
なんか、いい情報があったら教えてください。
これは企業のプロジェクトなら当たり前だと思うんですが、Sprockets捨てたい、CoffeeScript捨てたい、というのはモチベーションとしてはいい一方、正当な理由にはできないので、そういう感情だけで動かないようにしたいな、と思っています。
