PHPカンファレンスで当日スタッフしてきました
2019年12月01日（日）、大田区産業プラザ PiOで開催されたPHPカンファレンスに参加してきました。今回のテーマは、「BEYOND.*」で、今年で20年目になります。
また、大規模なカンファレンスはこれで2回目の参加になります。
前日準備
当日スタッフの有志が集まってカンファレンスの前日には会場の設営などを行いました。なかでも一番骨が折れる作業はチラシの袋詰めでした。蟹工船なんて呼ばれていました。
トートバッグ箱詰め、頭こんがらがりながら詰めました！！1500個！！！
— Haruki Tazoe@RC390 (@jdkfx) 2019年11月30日
#phpcon pic.twitter.com/qBi4U3ZuCQ
当日スタッフとして
今回のPHPカンファレンスでは、初めてになりますが、当日スタッフとして参加させていただきました。前々からTwitterにて、当日スタッフの募集を呼びかけていたのでやってみようと思い、参加することにしました。
当日スタッフとしての仕事は、今回は技術評論者さんにPHPカンファレンスの登壇内容の様子をレポートする係になりました。
事前に決められたセッションの内容を聴きながらメモし、技術評論者さんに寄稿するという形で行われます。
この係はわりと自由がきくので、事前に見たいセッションのレポート担当になっておけば見たいセッションは見れますし、自分が担当していないセッションの時間帯は他の面白そうなセッションを聞くこともできます。
ただし、カンファレンス後にレポートとして聞いた内容をまとめて清書する必要があるので、決して楽ではないと思います。
聞いたセッション
PHPの今とこれから2019
PHPの過去とこれからどうなっていくか、現段階でのPHPの普及率、そして直近でリリースされたPHP7.4の改善点や、変更点を事細かく解説されておられました。
MVCにおける「モデル」とはなにか
このセッションではドメインモデル、メンタルモデル、パーソナルコンピュータという三つの観点からMVCとはなんなのかという話につながっていきます。
* ドメインモデルは情報システムがもつモデル。社会的システムとして個人を束縛する。
* メンタルモデルは個人が世界に抱く内面的なモデル。メンタルモデルを形成するためには良い道具が必要、特にコンピュータにあってはユーザーイリュージョンが重要。
* パーソナルコンピュータは社会と個人の関係を変えようとした。自分の力でシステムを書き換えられることが重要だった。そのためにはコンピュータの言語を個人が理解できなければならない。（noteより引用）
また、この発表資料はnoteにも上がっておりますので共有しておきます。
知見のない技術スタックをプロダクション導入するエンジニアの導入戦略
こちらのセッションでは、BASEが実際にプロダクトを作る中で出会した知見のない技術をどう業務で使えるようになるかというお話でした。
技術選定の際に新しい技術を取り入れようとするのは様々な不安があります。その不安をどう解消するか、そしてその不安にどう立ち向かうか、セッションの中で話されました。
その学びのサイクルとしては情報収集や体験といった「具体」、抽象化・モデル化・パターンの発見といった「抽象」、実践や検証といった「応用」のサイクルを回していくことだと話されました。 「多くを学び、すぐに反映すること」、これが個人的に大事なことだったなと感じています。
PHPを学ぶということ
このセッションでは、初心者向けにPHPという言語を学ぶことについてわかりやすく、そして丁寧に説明されておられました。
どのようなロードマップでPHPを学ぶのか、そしてそれに付随するエンジニアリングの知識はどこからインプットすればいいのか大変参考になるセッションだったと思います。
最近、フレームワークに頼りきりの僕ですが、ちゃんとPHP自体を学んでより一層PHPへの知見を深めていきたいと思っています。
最後に
当日スタッフとしていろいろな方と交流をもつこともできましたし、セッションを聞いていろいろな知見を得ることもできました。
なかなかこんなにでかいカンファレンスに参加することが滅多にないのでいい経験になったと思っています。
来年の予定も決まっており、もし行けるようでしたら、参加したいなと思っています。
LINE DEV DAY 2019に参加してきました
最初に
11月20日(水)-21日(木)にグランドニッコー東京台場で開催された「LINE DEVELOPER DAY 2019」に参加してきました。
参加の経緯としては、「LINE DEVELOPER DAY 2019 学生向け参加支援制度」に当選し、交通費などの支援をいただけることになったからです。
普段からLINEを使っている上で、どんな技術が使用されているかなど興味はありましたが、なかなか触れる機会がないためこれはチャンスだと思い、支援制度に応募した次第です。
1日目
1日目は夜行で東京入りし、直で会場に向かいました。東京テレポート駅から無料のシャトルバスがでており、活用させていただきました。
さて、本題のセッションですが、以下で印象に残ったセッションについて語っていこうと思っています。
Inside of Blog; 〜15年熟成されたサービスの光と影、カオスとレガシーへの挑戦〜
こちらのセッションではLINEが運営する2つのブログサービス「Livedoorブログ」と「LINEブログ」の裏話がされていました。
Livedoorブログでは、実は、750個以上のサーバーを使っていることや、550個以上のデータベーステーブルが存在すること、43500個以上のファイルを扱っていること、そして、4100000行ものコードの量が15年という月日で蓄積されていることを説明されました。
そんな年月をかけたからこそのサービスのサーバーを移転する際に起こった出来事がとても大変そうなことばかりでした。
ケースとしては、ドキュメント自体がないということ、テストが存在しないこと、DNSレコードの77%が必要のないものであったことなどが挙げられます。
そして一番厄介そうだったのが、MySQLのバージョンが一番古い4.0を使っていたということです。これはサービスからテーブルAと同じ構造のテーブルBを作り、Alter tableして対策されたそうですが、テーブルの量が増えることにより、負荷が余計にかかってしまったそうです。
LINEブログについてですが、実はLINEブログはLivedoorブログからフォークされて作られているそうで、レガシーだったものを全て半年で書き換えていったそうです。ここには想像もできないような大変な作業が組み込まれているのだと思います。
これらを踏まえて、今現在運営しているサービスが15年後どうなるのか想像して書く必要があると登壇者は述べられました。たとえば、ドキュメントの整理をすることや、ソースコードのレビュー、リファクタリングなど、小さなことからでもいいので将来を見据えた開発を心がける必要があるなということをとても実感させられました。
LINE NEWSの記事配信を支える技術
こちらのセッションでは、LINE NEWSの記事配信を支える技術について聞くことができました。
現在、LINE NEWSはどれくらいの方々に利用されているのかというと、月間6800万のアクティブユーザーと、月間120億のPVだそうです。
LINE NEWSではパーソナライズされたレコメンドシステムを実装しています。これは機械学習と手動での操作で行われているそうで、タブTOPのおすすめ記事は手動、他の2つの画面は機械学習によるものだそうです。
スマートフォンからのリクエストに対し、レコメンド用のRedisからWEBサーバーにフェッチ、記事のキャッシュからデータをMySQLから呼び出しているそうで、毎時間、約1億人分のレコメンドのインポートを実現させているそうです。（書いている内容が間違っていたらすみません。）
またそのためのインポーターは、ファイルのダウンロード→ファイルデータのパース→Redisに保存といった流れを20スレッドで非同期・並列で実行し実現させているそうです。
発表の中では、セントラルドグマと呼ばれるLINE独自に開発されているリポジトリシステムの紹介がありました。jsonやyamlなどの設定ファイルを管理できるシステムでファイルの更新があると最新の情報をクライアント側に保持することができるシステムのようです。
2日目
2日目は主にハンズオンのセッションを体験しました。
他のセッションではLINEのセッションよりゲストで登壇されておられる方のセッションを聞いていました。
LINE Pay ハンズオン - あなたのBotにLINE Pay決済機能を追加してみよう
公開して良い資料なのかよくわからないので、ここでは公開しませんが、BotにLINE Payの決済機能を追加してみるというハンズオンの内容でした。
そこまで難しい内容でもなく、誰でも簡単にBotにLINE Payの決済機能を作ることができるのだなと実感しました。
こちらがそのハンズオンで作成したものになります。
出来たあああ！！
— Haruki Tazoe@RC390 (@jdkfx) 2019年11月21日
#linedevday pic.twitter.com/E06HRWiwEv
最後に
とてもいい機会を与えてくださったLINEさんに感謝しています。
セッションを聞いていると、自身の技術力のなさも余計に感じられ、速くもっと成長しなければならないような、そんな焦燥感をずっと抱いていました。
今回聞いた内容、学んだ内容はこれからの糧にして、自身の技術力向上を測っていきたいと思っています。
オブジェクト指向でなぜつくるのかを読みました
感想
オブジェクト指向について初心者にもわかりやすく解説している本だと思いました。序盤のオブジェクト指向とはどのようなものなのか解説する章では食いついて読み込んでしまいましたが、中盤のオブジェクト指向を使った応用技術が記されている章ではなかなか読みにくく自分には難しい内容だったなと感じています。
気づき
Java言語で学ぶデザインパターンの感想でも書いた通り、オブジェクト指向を意識したコーディングをしている方にとってはこの本は良本なんじゃないかなと思います。僕はやはりどちらかというと形から入ってしまうタイプの人間なのでオブジェクト指向を理解してから実際に書いてみようとするような人間です。実際にオブジェクト指向を意識したコーディングというものをしたことがあまりないため（もしかすると意図せず書いている可能性もあるが…）、オブジェクト指向を意識することから始めようと思いました。
UMLやXPについて
UMLがオブジェクト指向から派生して作られているものだとはここで初めて知ることができました。UML自体を書くこともなかなかないのですが、普段からUMLを書くことを意識して活動していきたいと思います。
XPという単語も基本情報で知りましたが、実際にどんな歴史があってどんなものだったのかということを知ることができました。昔ではペアプログラミングなんて考えられなかったみたいですね…。感慨深いものです。
これからについて
これからについて、というわけですが、やはり自分が気が付いてこれから気を付けていかねば、と思ったのは先にも述べた「オブジェクト指向を意識すること」だと思います。こんな便利で、かつ、再利用性の高い技術を本で読んだだけで無駄にせず、実際に手を動かして自分のものにしていきたいなと思います。が、しかし、どうしても形から入っていってしまう人間なため、もう少し「オブジェクト指向」とはなんなのか、ということについて深堀していきたいと思います。
またほかの「オブジェクト指向」について語られている良本を見つけ次第読んでみたいです。
Java言語で学ぶデザインパターン入門読みました
本について感想
GoFのデザインパターンを初心者にもわかりやすく紹介されておられる本でした。
しかし、個人的には「学んだデザインパターンを業務や個人開発で実践してみないとどんなところでどんなパターンが適しているか、もしくは必要となってくるのかわからない」、という考えのまま最初から最後まで読んでしまったため自身の経験の中で実践できるかはわからないといった感想を持ちました。
また、普段からオブジェクト指向を意識したコーディングを行っていないことについても気づかされ、これからのコーディングにはオブジェクト指向の概念を意識したコードを書いていきたいと思っています。
オブジェクト指向を意識しているプログラマ初心者ならこの本を読んで「ああ、とても勉強になったな…」と思うはずですが、そうではない僕からするとこの本がすべてのプログラミング初心者にまでお勧めされる理由が全く理解できませんでした。
写経について
僕にとっては意味がないと思いました。前述したとおり、普段からオブジェクト指向を意識してコーディングを行っているわけでもなく、単に「コードを書いている」というだけの感覚の方には写経してまでデザインパターンを勉強することはお勧めはしないと思います。その前にまずオブジェクト指向についてちゃんと知っておく必要があるかなと思っています。
「こんなパターンがあるんだな…動かして実際に挙動を確かめてみたい！！」という方には付録のCDにあるサンプルプログラムを利用するほうが遥かに時間的に効率のよい勉強法だと思います。
パターンについて
以下、学んだパターンについてまとめてみたので記しておきます。
また写経したコードはこちらに置いてあります。
デザインパターンに慣れる
Iteratorパターン
- 何らかの集合体があったとき、それを順番に指し示していき、全体をスキャンしていく処理を行うためのもの。
- 具体的なクラスだけでプログラミングするのではなく、抽象クラスやインターフェースを使ってプログラミングする
Adapterパターン
- インターフェース（API）が異なっている2つの間に入って、そのずれを埋めるためのもの
- 既存のクラスに一皮かぶせて必要とするクラスを作ることで、必要となるメソッド群を素早く作ることができる
サブクラスにまかせる
Template Methodパターン
- スーパークラスでの処理の骨組みを規定し、サブクラスで処理の内容を具体化するもの
- スーパークラスでの記述が多→サブクラスの記述は楽だが自由度減
- スーパークラスでの記述が少→サブクラスの記述は大変で個々のサブクラスのコードの記述が重複するかもしれない
Factory Methodパターン
- Template Methodパターンをインスタンス生成の場面に適応させたもの
- newによるインスタンスの生成を、インスタンス生成のためのメソッド呼び出しに代えることで、具体的なクラス名による束縛からスーパークラスを解放する
インスタンスをつくる
Singletonパターン
- 指定したクラスのインスタンスが絶対に一個しか存在しないことを保証するパターン
- インスタンスの数に制限を課す＝前提になる条件を増やす
- 複数のインスタンスを作成するとそれらが相互に影響しあってバグを生み出す可能性もある
Prototypeパターン
- クラスからインスタンスを作成するのではなく、インスタンスから別のインスタンスを作成するパターン
- 種類が多すぎてクラスにまとめられない場合、クラスからのインスタンス生成が難しい場合、フレームワークと生成するインスタンスを分けたい場合に使うことができる
Builderパターン
- 段階を踏んで、構造をもったインスタンスをくみ上げていくパターン
Abstract Factoryパターン
- 部品の具体的な実装には注目せず、インターフェースに注目し、そのインターフェースだけをつかって、部品を組み立てpプロダクトにまとめるもの
- 具体的な工場を追加するのは簡単だが、新たな部品を追加するのは困難である
分けて考える
Bridgeパターン
- 「機能クラスの階層」と「実装クラスの階層」を橋渡しする役割を持つ
- クラス階層が複雑になることを防ぐために「機能クラスの階層」と「実装クラスの階層」を分けてしまうのがいい
- 機能追加の際に、実装のクラス階層を全く修正する必要がなく、「すべての実装で」利用可能
Strategyパターン
- アルゴリズムを容易に切り替えることができる
- 委譲というゆるやかな結びつきを使っているので、アルゴリズムを容易に切り替えが可能になっている
同一視
Compositeパターン
- 容器と中身を同一視し、（入れ子になった構造）再帰的な構造を作るパターン
- 容器と中身を同一視するパターンだが、複数と単数の同一視と呼ぶこともできる。複数個のものを集めて、それをあたかも一つのものであるかのように取り扱う
Decoratorパターン
- オブジェクトに対して、どんどんデコレーションをほどこしていくようなパターン
- 包まれるものを変更することなく、機能の追加を行うことができる
構造を渡り歩く
Visitorパターン
- データ構造と処理を分離し、データ構造を渡り歩く「訪問者」を表すクラスを用意しそのクラスに処理をまかせる
- 処理とデータ構造を分離させることで部品としての独立性を高めている
Chain of Responsibilityパターン
- 要求を処理するインスタンスを鎖状に並べて置き、要求を処理できるかどうかを順番にチェックしていく「たらいまわし」のパターン
- 「仕事の振り分け」ができるので個々の仕事に集中できる
- 状況の変化に応じて動的に連鎖の形態を変えることもできる
シンプルにする
Facadeパターン
- 大きなプログラムを処理する際に関係するクラスを適切に制御する必要があり、その処理を行うための「窓口」を用意しておくほうがいい。その「窓口」をFacadeパターンという
Mediatorパターン
- 多数のオブジェクトの間の調整を行わなければならないときに利用されるパターン
状態を管理する
Observerパターン
- 観察対象の状態が変化すると、観察者に対して通知される。このパターンは、状態変化に応じた処理を記述する際に有効である。
- Model、View、Controllerの中のModelとViewの関係はObserverパターンの役割と対応している
Mementoパターン
- このパターンを利用すると、プログラムに対してundo（やり直し）、redo（再実行）、history（作業履歴の作成）、snapshot（現在状態の保存）などを行うことができる
Stateパターン
- システムの各状態を個別のクラスで表現するパターン
- 状態遷移は、状態を表しているクラスのインスタンスを切り替えることで表現される
無駄を無くす
Flyweightパターン
- メモリの消費を少なくするためにインスタンスを共有させるパターン
- 共有しているインスタンスを変更すると、複数個所に変更が及ぶ。なので、共有されるべき本来備わっている情報と、共有させてはいけない外からやってきた情報を意識して区別する必要がある。
Proxyパターン
- 「本人」と「代理人」のオブジェクトを作り、忙しくて仕事ができない本人オブジェクトの代わりに、代理人オブジェクトが仕事を代理でやってくれるパターン
- 例として、HTTPプロキシはHTTPサーバとHTTPクライアントの間に入って、WEBページのキャッシングを行うソフトウェアのこと
クラスで表現する
Commandパターン
- 「命令」をオブジェクトとして表現し、履歴をとったり再実行を行ったりすることができるパターン
Interpreterパターン
- 書かれたコードを解釈・実行するもので、この通訳プログラムのことをインタプリタと呼ぶ
引用
「WEB TOUCH MEETING」Under 29 SPECIALに参加してきました＆登壇してきました
タイトルの通り、今回「WEB TOUCH MEETING」Under 29 SPECIALというイベントで登壇してきました。
29歳以下の方々が広島でどのような活動をしておられるのかということを一人ずつ語られておられとても楽しいイベントとなりました。
基本自分の発表をメインにまとめていこうと思っているんですが、とても楽しく発表できたなと思っています。
以外にもLTっぽくなってしまいほかの発表者と比べるとあまり面白みとか、技術についてとか全然語れなかったのがちょっと悔しいです。
最初は意外と緊張していたものの、発表中笑ってくださる方々がいたり、うなづいてくださる方がいたりとで、緊張もほぐれいい感じに発表できたなと思いました。
実はこういった場に参加して発表するのは初めてなのでどうやっていいかとか全然わからず、スライドもお手伝いさせていただいてる会社の方に見てもらって、直したらいい点などいろいろと教えてもらい本番に臨みました。
その成果もあり、「面白かったです」などの声もいただくことができたので超満足しています。
そのあとの懇親会のなかでLaravelを勉強できる場がないな…ということになり、Laravelを広島でもっと盛り上げるためのコミュニティーとか作りました！
ってな感じで初参加で初登壇の「WEB TOUCH MEETING」Under 29 SPECIALはとても楽しかったです。
運営の方々、登壇者の方々、またまた足を運んでくださった参加者の皆様、本当にお疲れ様でした！！
（駆け出しの学生ですが）PHPカンファレンス福岡2019 に参加してきました
2019/06/29(土) 、福岡ファッションビルで開催された「PHPカンファレンス福岡 2019」に参加してきました。
僕はPHPerとしてはまだまだ駆け出しなのですが、単にこういった大きな勉強会に参加してみたいなという気持ちで今回のカンファレンスに行くことにしました。
結果としては、興味のあることから、難しくて頭がパンクしそうになることまで盛りだくさんで、終始、「うひょおお、すげえええ勉強になるううう！！」という感じでした。
学生枠で参加したのですが、会場には学生さんが少ないように思え、少しでもお話しできたらいいなと思っていたのに、少し残念でした…。
拝見した内容
僕の記憶と、持っていってたノートに書いてある内容を基に、まとめていきたいと思います。
PHPerの採用面接で僕らは何をつたえあうべきか #phpconfuk
今後、僕にはまだまだ先の話となるかもしれませんが、PHPerとして社会に出る際、面接でどんなことを面接というコミュニケーションを通して伝えあうのか、ということについての発表でした。
印象に残ったのが、「採用面接とは、《なにを大事にしているか》を交換し合う場所」ということです。面接側は、自分自身が望むことについて、給与や待遇といった基本的なことから、自分がどういう人間であるか（自ら進んで問題解決に取り組むのが好きか、それとも誰かが喜ぶのが好きか…など）といった性格面などを共有し、採用側は、この会社が大事にしていることと採用される側が合うかどうか判断することで、自分も会社さん側も気持ちの良い採用をすることができるのだなと感じました。
採用面接ではないのですが、学生が応募する企業の長期インターンのエントリーなどにもつながる話だなと思います。
3ヶ月で20万行を消すためにやったこと
メルカリさんのAPIって実はPHPで書かれていたらしく、最初聞いたときは「ほへええ、まじか～～！！」という感じでした。まだまだ駆け出しの自分にはコード読むのがものすごく大変そうだなという印象を受けました。
コードを削除するメリットとして挙げられるのが、
- コードの複雑さの低下
- システムの高速化
ということで、今回は、これに沿い不要なAPIを削除していったというお話でした。
すでにリリースされているプロダクトのコードをいじることはこれまでになかったので、もしこれから自分のプロダクトでも、もしくはお仕事で頼まれたプロダクトでもコードを削除するような仕事が回ってきた際には、聞いたお話を基にやれたらいいなと思っています。
子育てとスキルアップを両立するエンジニアの生存戦略
個人的に、パパさんエンジニアかっけええ！！！といった印象を受けた発表でした。「将来はこの人みたいなパパさんになりて～！！」とか一人で思っていました。
内容もとても面白くて、すごくタメになることばかりでした。
子育てのみならず、学生にとっても勉強時間がとれないときもよくあったので（現在は休学中で時間がたっぷり）、朝を効率よく活用できるようにしたいなと思いました。
インプットとアウトプットの話では、移動時間などを効率よく使い、集合知の活用や、記事の執筆などを心がけていきたいなと思いました。
Webサービスの成長を止めずに リファクタリングする技術 / web-refactoring
今回のカンファレンスで個人的に一番勉強になった話でした。
上でも記述したのですが、僕はまだリリースされているプロダクトのコードを書き換えることや削除したりしたことがまったくなく、これからそういった仕事をまかされたとしても八方塞がりになってしまうだろうなと思っています。
詳しくは資料にたくさん書いてあるのでここでは書く必要がないと思いますが、リファクタリングする際、どうやってやっていけばいいか、事細かに説明されており、これからの自分の成長を手助けしてくれる発表だと思いました。
PHPでURLルーティングを自作する
PHPでURLルーティングの自作をしたお話でした。タイトルでとても気になっていたので、絶対に聞きたいなと思っていました。
内容もとても面白く、自分でも自作のルーティングを作ってみたいなと思ってしまいました。
PHPの知識よりかはデータ構造とアルゴリズムが結構絡んでくるのかなと感じましたが、実際のところどうなのかはよくわかりません…💦
競技プログラミングなどにも興味があるので、こういったアルゴリズムの考え方を自分ももっと勉強したいなと思います。
ユニットテストの現場の問題を原則に立ち返って考える
テスト大事ですね…。でも僕まだテストといえるテストを全くしたことがないんです…。
いつも手でポチポチフォームを打って…といった感じで、この発表を聞いていて、これからはちゃんとしたテストをしなきゃなと実感しました…。
今はまったくテストのことがわからないので、何とも言えませんが、これからテストをちゃんとしていくぞ！！って時に「ぺチコンでテストの話聞いてたよね…」と振り返ることができたら（今の段階では）それで充分かなと思います。
テストについてほかの資料もあるらしいので拝見してみようと思います。
Laravel でやってみるクリーンアーキテクチャ
クリーンアーキテクチャの話もあまり詳しくは知らないのですが、単語とかよく見かける程度には知っていたので、聞いてみたいなと思い聞くことにしました。
なんとなくわかるとこと、自分ここよく知らないんだな、と思うような、わからない部分もありましたが、コアとなる「《重要なもの（＝ビジネスルール）》を《些細なもの（データベース・UI・フレームワークなど）》に依存させない」という考え方はしっかりと持ち帰ろうと思いました。
Laravelに依存した開発ばかりを行っているので、自分でパッケージを作成し、開発するという経験も自分の力になるんではないかなと思っています。もしできるならパッケージから開発してみたいなとも思っています。
JAMstackアーキテクチャを用いたモダンWebサイト開発
JAMstackという技術を使った開発についてのお話でした。
JAMstackという言葉自体初めて聞いたため、どんなものなんだろうと聞いていたのですが、JAMstackすごいですね、コレ。
実際にJAMstackの技術が使われているFusic tech blogを拝見したのですが、描画がめちゃくちゃ早くて、阿部寛さんのサイトよりも早いんじゃないかなと…。（わかんないんですけど…。）
比較用に貼っておく
JAMstackにはいろいろと便利な点が多数あり、これから流行りそうな感じはあるかなと個人的に感じました。今後、JAMstackを使ったブログやポートフォリオなどを作成してみようと思います。
PHPの関数実行とその計測
タイトルから面白そうだと思い聞いていたのですが、さすが上級者向けだけあって途中からついていけなくなってしまいました。
どう書いていいのかわからず、感想が言えなくて申し訳ないのですが、もう少し詳しくなってから見ると何かわかることがあるんじゃないかなと思います。
今回はついていくだけで精いっぱいだったのですが、発表内容の記事版も出ているのでそちらも含めあとで要復習かなと思います。
LT発表
交通の都合上、途中で帰らなくてはいけなくて全部の発表を聞くことができなかったのですが、LT聞いててめちゃくちゃ面白かったです。今回からコメンテータ制度が入ったらしく、それもまた面白くてもう、最＆高でした。
いつかは俺もあの場に立ってみてえな、そんなことを思わせてくださった発表者の皆さん、お疲れさまでした！
まとめ
初めての参加だったのですが、とても楽しく、そして、とても勉強になりました。
自分の力が及ばずついていけなくなることも多々ありましたが、そのついていけなかった悔しさをバネにしてこれからの開発・勉強に必死に取り組んでいきたいと思いました。
学生枠ということで無料で参加させていただいたことにとても感謝しています。
学生さんとお話しすることができなかったことや、他の参加者の方々とお話しすることがあんまりできなかったこと、懇親会に参加できなかったことが、やはり残念だったのですが、次回はたくさんの方とお話ができるように頑張りたいと思います。
最後にこれだけは自戒として、次回のために（激寒）書いておこうと思うのですが、「夜行バスで行こうとするな、次の日死ぬぞ」ということです。グロッキー状態でカンファレンスを聞いていたため帰ってから体壊してしまい「うえ～～」という感じになっています。次回はちゃんと前日入りするか、新幹線を使うか、したいと思います。
それでは。
広島エンジニアハッカソンに参加してきました
2019/06/15(土) 〜 2019/06/16(日)の二日間、イノベーション・ハブ・ひろしまCampsで開催された「広島エンジニアハッカソン Vol.1」に参加してきました。
エンジニアによるエンジニアのためのハッカソンをやりたい！というテーマのもと、チーム毎にこんな課題を解決するサービスがあればいいよね、こんな面白いものがあればいいよねという観点でサービスを二日間かけて開発しました。
僕はハッカソン自体は参加したこともなく、今回が初めてのハッカソン参加となり、普段は個人で開発しているのでチームでの開発も初めてでした。
チームの成果物
今回、僕らのチームは「カジュアルな勉強会マッチングサービス」というテーマで「atsumaru」というサービスを作りました。実際に動くものはこちら。
解決したい課題、サービスを使ってこうなればいいなという点を挙げると、
・イベント・勉強会に参加したいけど気軽にいけない人→仕事終わり・放課後に気軽に参加できる
・もっと簡単にイベントを行いたい人→簡単に人の集まるイベントを開催できる
・こんなイベント・勉強会がほしいという人→参加したい勉強会がたくさんある
と言った感じです。
自分の場合の話ですが、広島に住んでて、なかなか自分の参加したいと思うイベント・勉強会が少なく、知識の共有とかができる範囲が少ないなと思っていました。
こんな感じで、ゆる〜く勉強会・イベントを開催してどんどん技術を共有していければいいなあというイメージで使いたいサービスだと個人的には思ってます。
楽しかったこと
サービスを作るにあたってどういう機能を実装するか、どういうUI、UXにすればいいかみたいなことを話すのはワクワクしてとても楽しかったです。
結果的に実現しない機能もいくつかありましたが、チームでの開発ということもあり、終始色んな方と話しながら開発に挑めたし、いろいろとアドバイスをもらったりして自分の勉強にもなったなぁと感じてます。
悩んだことなど
今回、自分の知らない言語を使って開発をやっていたため、コードを理解することが難しくてどうすればいいか悩んでましたが、途中から自分が使える言語でマイクロサービス的な感覚でサービスに必要な機能を開発してました。自分の知ってる分野以外でも調べれば使える、もしくは、コピペで動かせるようにはなっておいたほうがいいかなと個人的に思いました。
ほかのチームの成果物
他のチームの成果物は以下のようになってます。
・お好み焼き専門のデリバリーサービス「OkonomiEats」
「あのお店のお好み焼きが食べたいけど忙しくて行けない！」というときに簡単にお好み焼きのデリバリーができるという広島らしいサービスだなあと思いました。
・野球観戦には欠かせないサービス「オレ的野球解説」
詳しい人からその試合の見どころをリアルタイムで教えてもらえるサービスで、その人の試合に対するアツさをグラフで表示して、その人自身の試合に対する盛り上がり度を表示してくれます。これまた広島らしいサービスだなあと思いました。今回の優勝チームでした。
・ウェアラブル端末で土砂災害が起こりそうな地域から身を守るサービス
木が多すぎる土砂災害の危険性も高まるので、それを抑えるために適度に木を間伐しなければならないというときに、専用の端末を身に着けて山の中を歩くと山の情報がわかるようになるというポケモンGOみたいなサービスでした。
・ゆるく集まって勉強するためのプラットフォーム「ゆる会募集サイト」
僕らのチームと結構似ていたのですが、こちらは広島の学生の多いでエリアを指定し、教えたい人と教わりたいひとがうまくマッチできる勉強会募集サイトになってます。学生目線でつくられていて自分としてもこういうのがあったらいいなあと思いました。
最後に
二日間、とてもたのしく開発できたと思いました。技術的に至らぬ点も多々ありましたが、「もっと強くなりたい」という気持ちがこれからの自分のモチベーションとなり、自分の技術力をどんどん高めてくれるのかなと（もしくは高めていってほしいなと…）思ってます。
二日間、お疲れさまでした！
