開発合宿で「おんやど恵」に行ってきた
プライベートで開発合宿を行い、合宿場所探しにかなり悩んだので、他の方に参考になれば良いと思いブログを書くことにしました。 (あと今回はモニターとして参加なのでw)
上記画像は合宿中に撮った唯一の画像ですw
開発合宿場所探し
開発合宿をやろう！と年末ぐらいから会社の同僚達と話していました。
そこで合宿を行う上で考えた内容がこちらです。
wi-fiがあり、開発できるくらい回線がしっかりしている(必須)
会社とは関係なく、プライベートの少人数なのでお金がそこまでかからない
都内からアクセスしやすい
温泉があるところ！！！
この要件を満たすところを探すのが結構大変でしたw 最初は東京ドームの近くにあるラクーアにしようと思ったのですが、wi-fiがあるか分からないし、寝る場所の確保などが難しそうな為、即却下でしたw
そこで色々と検索した結果、今回紹介するおんやど恵さんが、開発合宿プランを出しているのを発見しました。
HPに説明があるのですが、場所は熱海の湯河原で温泉があります。
値段もリーズナブルでプロジェクターや外部ディスプレイ、電源タップがあるだけではなく、息抜きにコーヒーを飲んだり、卓球やボードゲームもできるようなので、即予約しましたw
ちなみに値段は朝食、昼食つきで1人1万円〜になるようです。(時期やプランで変動あり)
いざ、開発合宿へ
移動
予約も無事に済み、開発合宿当日になり都内から出発です。
交通の案内にもあるのですが、都内からだと新幹線こだまで約1時間、そして熱海駅から湯河原まで在来線で1駅だけ移動して、バスで約10分の移動でした。
都内からだと合計で1時間30分ほどの移動で済みました。
開発
到着し、開発を行う場所に案内して頂いたのですが、かなり大きな広間でした。
HPの説明によると大体20人くらいまでいけるそうです。
(写真はHPから引用)
実際に開発を行ってみると、wi-fiは問題なく使用できますし、貸し出し(2台で2,000円)の外部ディスプレイはかなり画質も良く、騒音もなく静かなので、ストレスフリーで開発を行うことができました。 ちなみに13時〜翌日のお昼12時まで開発をすることができます。(客室のチェックアウトは午前11時)
その他
その他にもご飯、露天風呂、客室の設備など満足度の高いもでした！
あと卓球ができるので、開発して疲れたリフレッシュにもなり、かなり白熱した闘いになりましたww
(写真はHPから引用)
まとめ
今回の開発合宿は個人的に初めてだったのですが、かなりよい旅館設備のおかげでとても満足でした。
おんやど恵さんの対応もかなり丁寧でした。
ありがとうございました。
また来たいと思います。
開発合宿やりたい人一緒にやりましょーう!!
東京に転職してきて1年が経った
3月1日に無事東京に転職してきて、1年が経ちました🎉
退職エントリーや転職エントリーが多いこの時期ですが、転職したあとのエントリーは中々見ないので、書いてみようかなーと思います。
転職に至った経緯や、転職前は何をしていたのかは以前の記事を見てもらえばわかります。
tf6533.hateblo.jp
仕事の変化
転職してまず変わったことは、HTMLとCSSがメインだったのがJavaScriptをメインに仕事をするようになったことです。
入社した当初は、ReactはもちろんES2015+がさっぱり分かりませんでした。
「アロー関数わからねぇ」とか「mapってよくわからねぇ」とかをずっと考えてましたw
そんな入社当初の自分ですが、1年も経てば案外なんとかなるもので、現在はやっとJavaScriptを少し理解し、業務で活かせるようになってきました。
もう1つ大きく変わったことは、多くの人と接する機会が多くなったことです。
転職前はベンチャー企業の少人数組織だったので、2日もあれば社員全員と話せるようにはなってましたが、転職した今は組織が巨大で、1年経った現在でも初めて話す人が多く、ほぼ毎週「はじめまして」と言ってるような気がします。
私生活の変化
東京に来てからというもの勉強会によく行くようになりました。
東京に来る前は、勉強会なんて数ヶ月に一度行きたいものがあれば、良い方だったのですが、東京は毎月2~3個は行きたい勉強会があって幸せです。
最近は参加するだけではなく、どうせ参加するなら登壇しないと勿体ないと感じて、積極的に登壇しています。
あとは、普段の業務に少し慣れることができて来たので、副業を始めたのも1つの変化だと思います。 副業をすることで、業務では使ってない知識を身につけられたり、業務でやってることを深掘りすることができてメリットばかりだな〜と感じます。
まとめ
東京にきて1年間あっと言う間でした。
最初の1年間は慣れることに精一杯だったと感じるので、これからはもっと楽しめるようになれたらなーと思います。
テスト駆動開発「第1部 多国通貨 10章~13章」を読んだまとめ
現在友人達とテスト駆動開発の本を輪読しているので、自分の担当した「第1部 多国通貨 10章~13章」の内容をアウトプットとしてブログにまとめる。
おさらい
いきなり10章~13章の内容をまとめても訳がわからないとおもうので、まずはこれまでの章についてざっくりおさらいする。
「第1部 多国通貨」の内容はある多国通貨についてJavaで実装する際に、必要な機能をTDD手法で実装していくことになる。
本の中ではJavaの実コードを参照しつつ、TDDについて触れているのですが、今回の私がおさらいする内容は、主にTDDについての考え方についてになる。
Javaの実コードを見たい方は書籍を買うと良いだろう。
TODOリストを作る(1章参照)
TODOリストを作ればやるべきことを忘れずに目の前のことに集中できる。
書くべきテストを思いついた時にその都度TODOリストに追記する。
TDDのサイクル(2章参照)
1.小さいテストを1つ書く。
2.すべてのテストを実行し、1つ失敗することを確認する。
3.小さい変更を行う。
4.再びテストを実行し、すべて成功することを確認する。
5リファクタリングを行い、重複を除去する。
TDDの目指すべきところは動作する綺麗なコード
TDDで大事なのは細かいステップを踏むのではなく、 細かいステップを踏み続けれるようになること。
1~3のフェーズは速度(似たコードのコピペなども可)を重視して、通過する。
しかし、それは5のフェーズを行わなければ罪である。
TDDの3つの戦略(2〜3章参照)
仮実装
コードでまずベタ書きの値を使い、実装を進めるに従って、徐々に変数に置き換えていく。明白な実装
すぐに頭の中の実装をコードに移す。三角測量
リファクタリングの前にテストを書く(5章〜6章参照)
テストが十分に書かれていないコードに対してTDDを行うことも考えられる。
この場合は、あればよかったテストを書いてからリファクタリングを行う。もし、テストを書かずにリファクタリングを行えば、コードはリファクタリングの過程で壊れてしまう。
不安だと思った内容はテストに書く(7章参照)
頭の中にある不安はTODOに追記して、テストコードにする。
このテストコードに対して、テストを通す目的だけの実装をする、完璧な実装はそのあとに考えることにする。
歩幅を調整する(8章参照)
実装をする際に大きな変更を加える前に、それを小さな手順にして小さく実装することを検討する。
TDDを行う際にはこのように、歩幅の調整が必要であり、大きな変更をすることに不安を感じれば、小さな変更に分割し、小さな変更に窮屈さを感じれば大きくするといった感じで、微調整を繰り返す。
ちなみに 正しい歩幅は未来永劫存在 しないらしい。
本題
おさらいが終わったので、本題の10章~13について解説していきます。
10章 テストに聞いてみる
コードをリファクタリングしているときに「ここの部分は必要なさそうだけど消しても問題ないのか？」という場面があると思う。
この場合、テストを実装していればどのような変化を加えても、変更後にテストを実行すれば動作するかどうかの結果をコンピュータが即座に教えてくれる。
もしテストがなければ、リファクタリングに慎重になり、検討に時間がかかってしまう。
1つのテストが失敗しているときに、新たにテストを加えたり、プロダクトコードを変更することは危ないことなので、この場合は1度テストが失敗した原因まで戻り、新たにテストを加えて実装を修正し、再び今回テストが失敗した内容に戻るのが良い。
11章 不要になったら消す
2つの重複があった関数やクラスを1つにまとめると、不要な関数やクラスができる。
同時に不要な関数やクラスを参照してるテストコードもできる、不要な実装に対してのテストは 過剰なテスト ということになるので、削除してしまう。
12章 設計とメタファー
この章で「メタファー」という言葉が多く登場するのだが、意味がよくわからなかったので、wikipediaを参照しました。要は比喩のようなものらしい。
新たに大きなテストを書いて実装をする前に、小さなテストに分割し作成し、その小さなテストが通るようなメタファーについて深く考える。
新たなメタファーが思いついたらそのテストが通るところまでは、素早く実装し、リファクタリングができる準備をする。
13章 実装を導くテスト
この章では寿命の短いとわかっているテストをあえて書いている。
内部の実装に関するテストは寿命が短いがこのテストを通すことで、リファクタリングを自信持って進めることができるということなのだと思う。
あとは書いたテストを通るようにして、リファクタリングを加えるといった内容だった。 しかし、この章でのリファクタリングではテストは通っているものの重複している部分が残っているので、TODOに追加した項目は残すようにしている。
感想
この本の中ではTDDについてJavaのコードを用いながら解説しているが、Javaを知らない人でもTDDについては学べそうだと感じた。
まだ本の中では3分の1程度の内容なので、更に読み進めて続きを後日あげようと思う。
まだ理解が浅いのでもし間違っている点ありましたら教えてください🙇
地方にいるからこそ勉強会の主催・登壇をすることに意味がある
この記事は登壇者 Advent Calendar 2017の14日目の記事です。
ちなみに私の25歳の誕生日ですw
今回は、地方で勉強会がない、登壇することに勇気がないと思っている方に私の経験を踏まえて、地方にいるからこそ勉強会の主催・登壇をすることに意味があるのだということをお伝えしたいと思います。
地方にはあまり勉強会がない
私は現在東京でエンジニアをやっていますが、去年までは広島のエンジニアでした。 (転職した理由などはこちら)
地方でエンジニアをやっていて一番辛かったことは、地方には 勉強会が全くないことでした。
3ヵ月に1回くらいしか参加したいと思える勉強会がなく、東京では1ヵ月の間に何度も魅力的な勉強会があるのが現実です。
そもそもそんなに勉強会に参加しなくてもいいのではないかと思われる方もいるかもしれませんが、フロントエンドエンジニアとして勉強会で得られる情報はとても大切なものだと思っている私にとっては、とても辛いことでした。
ないなら勉強会を自分で開けばいい
私は勉強会がないなら自分で開いて、そこで地方のフロントエンドが好きな人を集めて、情報交換をしようと思い、当時は登壇すらしたことなかったのですが、勉強会を開きました。
当時人気？だったAngular1系のハンズオンを開催したのですが、募集した際にたまたまAngular Japane User Groupの方にも声をかけて頂き、広島では珍しい勉強会を開くことができ、 同じ県の方以外にも他県の方まで足を運んでいただける会になりました。
勉強会を開いたら声をかけて頂くことが増えた
地方なので世間はとても狭く、一度フロントエンドの勉強会を開いたことでフロントエンドの人として多くの方に認識して頂きました。
認識をして頂いたおかげで、勉強会の登壇のお誘いを頂くことが増えました。
そしてお誘い頂いた勉強会で登壇することで、更に声をかけて頂いたり、お仕事のお話を頂くこともあり、かなりの自己ブランディングにもなりました。
東京に来た今でも、当時勉強会でお話した方と広島で勉強会を共同開催したり、かなり大きなセミナー登壇のお話を受けることもあります。
これは地方で登壇していたからこそだと思っています。
なぜ地方で勉強会の主催・登壇をすることに意味があるのか
東京に来て思うのですが、一度勉強会をしたり、少し登壇することで強く名前を覚えてもらえることは地方ならではのことだと感じます。
なぜなら冒頭にも述べた通り、東京では多くの勉強会があり、勉強会があるのが当たり前な状況なので、登壇している人が多くいて、大きな企業や注目度の高い勉強会でないと、埋もれてしまいます。
ですが、私の経験をお話したとおり地方では行動すればすぐにお仕事に繋げたり、自己ブランディングができると思います。
最後に
現在地方に在住していて、くすぶっている方がいましたら勉強会を開いてみてください。 あなたにとってメリットがあるだけではなく、開催した勉強会をきっかけに周りが盛り上がっていくこともあると思います。 また、勉強会を主催するのはハードルが高いと思っている方は、まずはLT(ライトニングトーク)から始めることで、必ずあなたにとって良いことがあると思います。
JavaScriptを学ぶ上で知っておくべき基礎的な知識
今回はこちらのアドベントカレンダーの11日目の記事です。
今年1年を振り返ってみるとJavaScriptを入門する方に教えることが多くありました。
その際に、「JavaScriptの情報が多すぎてなにがなんだかわからない」という言葉を何度か頂き、その都度教えていたJavaScriptを学ぶ上で知っておくべき基礎的な知識を今回はまとめようと思います。
JavaScriptの言語仕様について
JavaScriptは1つの言語として成り立っていますが、その中核となる仕様はECMAScriptというものになります。
例えばES 2015などと記載のあるものは、2015年に策定されたECMAScriptのメジャーバージョンであるECMAScript 2015を指しています。
このECMAScriptの仕様を策定するグループとしてTC39 Processという委員会があります。
この委員会では仕様を策定するのに決められたプロセスが存在し、このプロセスの検討が進むにつれて、stageが上がっていき、4段階目になると正式にECMAScriptの機能として取り込まれます。
stageについてはこちらを参照すると良いです。
現在使用可能かの状況を知りたい時はこちら
ECMAScript 6 compatibility table
tc39についてはGitHubで情報が参照できるので、見てるのも面白いです。
ブラウザについて知る
現在ブラウザは様々存在していますが、それぞれのブラウザにはJavaScriptを処理しているJavaScriptエンジンというものが存在しています。
各ブラウザに搭載されているJavaScriptエンジンは下記になります。
中身まで詳しく知らなくても、この存在を知っていると各ブラウザで挙動が違う理由がわかったりするので、JavaScriptを学ぶ上では非常に重要なことになります。
おまけ
JavaScriptの時代の変化についていくには、基礎的な知識としては上記2点を押さえておけば良いかなと思います。
もちろん使っているフレームワークやライブラリによって知らなければいけないことは増えますが、そちらは人それぞれということで。
ここからはJavaScriptを学ぶときに知っておいたらいいかな〜と思う程度の情報です。
検索方法
JavaScriptを学ぶ上で検索することが何度もあると思います。
しかし、年々状況が変化しているにも関わらず、古い情報を参照して実装していまい、プルリクエストを提出して、怒られたことがある人は少なくないと思います。
私の場合は検索する際に期間指定でフィルタリングすることで、まずは最新の情報を常に参照しています。
具体的な設定はこのようにしています。
基本的に1年以内に設定していれば良いかなと思います。
最後に
これからJavaScriptを学ばれる人はまだまだたくさんいらっしゃると思いますが、基礎的な情報を抑えることで、流れの速いと言われるフロントエンド界隈にもついていくことができるかなと思いますので、今回の記事の内容について知らなかった方は参考にしてください〜。
