2023-03-27

Gather.townで謎解き迷路型エンジニア交流会を実施しました！

はじめに
Gather.townとは？
Hajimari内でのGather
謎解き+迷路で交流を深める
- 工夫した点
- イベント風景
おわりに
採用情報
付録

はじめに

Hajimari PROPARTNER事業部所属の上山です！

先日社内のエンジニアメンバーにて、Gather.townの使い方をもっと知ってほしい！という気持ちがありGatherを使用した迷路 + 謎解きイベントを実施いたしました。

今回はそのエンジニア交流会についてご紹介いたします！

最後に付録として謎解きや、今回交流会での企画メモを載せています。Gather.townを使われていてイベント企画に迷った際はお使いください！

Gather.townとは？

www.gather.town

2Dメタバースオンラインオフィスツールです。

ZoomやGoogle Meet・Discordと言ったオンライン通話ツールとは一線を画しており、実際に自分のアバターを動かしつつ気軽に相手に話かけることができます。

Gather.townでは「手をふる」機能だったり、「ベルを鳴らす」機能であったり、リモート接続していてもある程度プライベート空間が保たれるように設計されています。

2/21からGather.townの無料枠が同時接続最大10人に縮小されたため、Hajimari社内では課金し利用を続けています。

Hajimari内でのGather

tech.hajimari.inc

以前投稿した記事の6Fオフィスに加えて、2022年12月のHajimariリアルオフィスの増床と共にHajimari社内のGatherオフィスも7F, 9Fが増床されています！

最初は現実とGatherのオフィスで位置関係を同じにするといった小さなこだわりを持っていたのですが、しだいに人数規模とマップサイズを考慮しつつ、コミュニケーションをしやすいデザインを考えた結果、現実のオフィスとはリンクしない形に落ち着きました。

Hajimari社内の各事業部メンバーが同時に接続している空間であったり、金曜日昼にはオープン雑談会が行われたり、金曜日夜には夜な夜なBarが開催されています。

また、各々が自分のデスクが設定されており、作業する際はデスクに籠もりっきりになる人もいます。

Gather.townを有効利用することによって、リモートワークにおいても常時接続をすることによって、まるで同じ空間にいるような感覚で仕事をすすめられています！

謎解き+迷路で交流を深める

今回はGather.townを通して、謎解きと迷路を組み合わせた催しを行いました！

企画段階の時点で、迷路を作る手間が大変だったり、限られた時間の中で解ける謎解きを考えるのが大変でした・・・！

謎解き問題については弊社謎解きエンジニアである植本さんにお願いをし、作成していただきました。

流れとしては以下のように進めました。

エントランスで全員集まり、絨毯ごとに分かれてチーム分け
チームが決まったら、チームごとに迷路へ入る
迷路の中では謎解き問題が複数置かれているので、解きつつ迷路を進む
一番早く迷路を脱出できたチームが優勝！

想像以上に早く謎を解いてしまうチームがいたり、謎を解かずに問題の雰囲気から直感で解くメンバーがいたり・・・かなり荒れた謎解き交流会となりました！！

工夫した点

謎をすべて解かなくてもゴールはできる
最初に難しい謎を置いておくことで解けたら「乗り物」を使えるアドバンテージがある
行き止まりがあるが、基本的に最低限解く必要のある謎がある

イベント風景

開催中にスクリーンショットを撮るのを忘れてしまったため、自分一人だけですが、このようなエントランスでチーム分けを行いました。

迷路はファンタジーっぽさもありながら、スラム感も出して「ちょっと変わった雰囲気」を出しました。

おわりに

Gather.townは工夫しだいで交流会にも大きな幅が持たせられるということが分かりました。

それに加えて、どのように設計するかでGather.townの機能を「遊びながら」理解してくれるかが決まりますし、使う側も「遊びながら」機能を覚えられたほうが健全だと思っています！

今回はマップの作成方法といった内容は詳しく記載しませんが、気になった方はぜひ前回の記事を参照してみてください！

今後もHajimariではGather.townを使ったリモートワーク下でもオフラインオフィスと変わらない関係を築ける取り組み・交流会の実施を企画しています！

リモートワークでもオフラインオフィスと変わらない「繋がり」を持つことで、地域創生へのアプローチを行っていきたいと思っています。

採用情報

株式会社Hajimariでは、自社開発・受託開発を行なっており、一緒に開発を行なっていただけるエンジニア募集しています！

長野拠点の立ち上げメンバーも大募集しています！

みなさまとお会いできるのを心からお待ちしております！

付録

今回使用した謎（一部）

今回、謎解きエンジニアの植本くんから謎解きをこの記事に使って良いという許可を得たため、ぜひこちらでみなさんも解いてみてはいかがでしょうか。

※答えは一番最後に記載されています。

今回のGatherイベント設計時のメモ

## 目的

主目的としては、Gatherの正式導入にあたりGather上での操作に慣れてもらう意図がある。副次的に交流も深める

## 概要

Gatherで迷路を作り、色々操作に慣れながらゴールを目指す。

## 使用想定機能

- 基本移動・Follow機能
- 物を置く
- Xキーでインタラクトする
    - パスワード付きドアを開ける
    - 乗り物に乗る
    - ペットを連れて行く

## 設計

### Must

- 最初にエントランスを用意し、そこでチーム分けを行う
    - チームに別れたあと、『勇者』を一人決めてもらい、フォロー機能を使ってもらう
- 謎解きを道中に置き、Password付きドアに答えを入れるスタイルにする
- 全体的に反復させる設計にし、乗り物を用意する
    - スタート地点に謎解きを置いておく
- ポケモンのジムみたいにポータルでポンポン飛ぶ形式にする
- みんなでデコるエリア

### Better

- プロフィール機能を使って謎を組み込めるとBetter
- ゴールでは色みんなで話せるスペースを用意する
- 麻雀卓を用意して、イベント後出来るようにしておく

## 開催時の注意点

- 不正防止用の権限削除とグローバルビルドのオフ

謎の答え

上から

時間（hour）
思春期
あたま

です。解けましたか？

2023-02-13

開発合宿を行いました!

株式会社HajimariのTUKURUS事業部では、2022年の12月15日と16日の2日間にかけて開発合宿を行いました。

開発合宿をすることになった経緯

私たちTUKURUS事業部は、普段、受託開発やクライアント様の開発チームに業務委託として参画させていただき、開発の支援を行なっております。また、去年の3月に長野県で開発拠点を立ち上げ、徐々に長野から働くメンバーも増えています。

note.com

そのため、普段同じプロジェクトで働いていないメンバーやフルリモートで働いているメンバーとのコミュニケーション不足が課題になっていました。そこで、開発合宿を通してメンバー間の交流を深めるとともに、普段交流のないメンバーとの開発により新たな知見を得てもらいたいという目的で開発合宿を行うことにしました。

合宿の様子

開発合宿では普段は別のプロジェクトの人同士でチームを組み、与えられたテーマに沿ってアプリを開発しました。今回のテーマは「会社内の業務改善につながるアプリ」でした。slackの分報で流れてしまうナレッジを貯めるアプリや、会社内で気軽に質問ができるようなアプリなど、普段の業務をしていては開発ができないようなアプリが誕生しました。

合宿を終えて

合宿を終え、参加したメンバーに合宿に関するアンケートを行いました。アンケートの結果から、当初の目的としていたメンバー同士の新たな交流を生むことができたり、新たなアプリ開発の機会が得られて良かったという声があがりました。また、次回も参加したいという声も多く、実施して良かったと思います。しかし、テーマに対して開発の時間が足りないという声も多かったため、次回実施する時は、時間割に関して工夫をしていきたいと思います。

最後に

今回はTUKURUS事業部初の開発合宿でしたが、普段オンラインで働いている人と顔を合わせながら開発をしたり、ご飯を食べる良い機会になりました。今後もこのような取り組みを続けていきたいと思っています!

株式会社Hajimariでは、自社開発・受託開発を行なっており、一緒に開発を行なっていただけるエンジニア募集しています！

長野拠点の立ち上げメンバーも大募集しています！

みなさまとお会いできるのを心からお待ちしております！

2023-01-16

Webブラウザレンダリングの仕組み【DOM・DOMツリーって何？】

こんにちは！

株式会社Hajimariでエンジニアインターンをしている溝口と申します！

今回はブラウザレンダリングの仕組みについて書いていきます！

この内容にしようと思ったのは最近、ブラウザ描画周りの知識不足が原因で開発に詰まったことがきっかけです。

これまでずっと理解が曖昧な状態で開発していて、調べることを後回しにしていました。

今回の失敗を機に、曖昧だった部分をしっかり理解しておこうと思い、ブラウザレンダリングについて記事を書くことにしました！

レンダリングの流れ

早速ですがブラウザレンダリングについて、説明をしていきます！

この記事では、レンダリングとはブラウザがデータを受け取ってから、表示するまでの一連の動作のことを指します。 ※加えて今回、DOMツリー構築までのHTML Parseなどについては記事が長くなるため省略します。

以下がレンダリングの全体像です。

DOM構築
CSSOM tree構築
JavaScriptの実行
レンダーツリー構築
レイアウト
ペインティング

自分は初めて全体像を見た時何一つ理解できてませんでした。

1つずつ見ていきましょう。

DOMツリー構築

ブラウザを表示するために最初に行われるのがDOMツリー構築です。

※HTMLはサーバから送られた状態では表示形式に変換されていないため、DOMツリー構築までにいくつかの工程があるのですが、今回はDOMツリー構築までの流れの説明は省きます。

DOMツリーとは

DOMツリーとはこのようなHTMLを表示するためのデータ構造です。

そもそもDOMとは何でしょうか？

Document Object Modelの略で、HTMLやXMLをJavascriptなどで外部操作できるインタフェースを定義したものです。

つまりDOMというのはあくまで実体の無いインターフェイス定義のことで、DOMを元にしてDOMツリーというオブジェクトが作られていくんですね。

DOMに基づいて、各ノードがツリー状に作られていきます。

親要素がbody、子要素がdiv4つ、孫がp2つずつの場合、このような形になりますね。

この時に階層が深ければ深いほど読み込みに時間がかかります。

つまり、マークアップをシンプルに書く方が読み込み速度が上がります。

CSSOMツリーの構築

DOMツリーの構築中にCSSファイルやCSSの記述が合った場合、CSSOMツリーというものが構築されます。

DOMツリーと同じツリー状のデータ構造になっています。

CSSOMツリーに書かれた内容が、スタイルとして適用されていきます。

このCSSOMツリーが作られる際にCSSの読み込みを行うのですが、CSSの読み込みのルールが少し複雑になっているので、簡単に説明します。

CSSの読み込みのルールを理解するためには、まず詳細度という概念を理解する必要があります。

※詳細度を重みと表現しているドキュメントもありますが基本的な意味は同じです。

詳細度というのはセレクタの詳細度と言えます。

CSSは、同じ要素に対して複数のセレクタを使っている場合、詳細度の高いセレクタが優先されます。

詳細度が高いとはどういうことか、具体例を見ていきましょう。

こちらをご覧ください。

下のh1要素に対して以下のCSSが書かれています。h1要素の文字は何色になるでしょうか？

<div>
    <h1 class="title"> ...
</div>

div h1 {
    color: green; 
}

.title { 
    color: white; 
}
h1 { 
    color: red; 
}

h1 { 
    color: blue; 
}

正解はdiv h1です。文字はgreenのため緑になります。

h1よりも.titleよりも、div h1の方がセレクタが詳細になっています。そのため、このセレクタが優先されます。

クラスセレクタ: クラス名でCSSを指定例：.title、.containerなど
要素セレクタ: 要素名でCSSを指定例：h1、spanなど

クラスセレクタと要素セレクタではクラスセレクタの方が優先度は高いのですが、詳細度のある方が優先されるためdiv h1が優先されます。

この詳細度が詳しいセレクタが優先される概念はカスケードと言われます。

ちなみに、CSSは「Cascading Style Sheets」の略です。(自分はCSSのCがカスケードを意味することを初めて知りました。笑)

カスケードは英語で「滝のように落とす」という意味で、CSSが詳細度の低いものから詳細度の高いものを読み込んでいく特徴を表しています。

詳細度の他にもCSSには継承という概念が読み込みの優先度にも関わっているのですが、今回は割愛します。継承についてはこちら。 https://developer.mozilla.org/ja/docs/Learn/CSS/Building_blocks/Cascade_and_inheritance#%E7%B6%99%E6%89%BF%E3%82%92%E7%90%86%E8%A7%A3%E3%81%99%E3%82%8B

JavaScriptの実行

DOMツリーの構築中にJSファイルやJSの記述が合った場合、その場でJSが実行されます。

この時JSの実行が終わるまでDOMツリーの構築はJSの処理が終了するまで中断されます。

つまりCSSと同じようにJSの処理が重ければその分画面表示が遅くなるということですね。

レンダーツリー構築

DOMツリーとCSSOMツリーが作成されると、DOMツリーとCSSOMツリーを１つのツリーにまとめます。

そうして作られるのがレンダーツリーです。

レンダーツリーは画面に表示されるノードのみが作成されます。display: noneの付いてるHTML要素やheadタグなどは含まれないという点に注意です。

レイアウト

レンダーツリーが作成されたら、viewport内に各ノードのサイズや位置を計算して決めていきます。

position: absolute;　 width: 33%；などの計算を行います。

ペイント

レイアウトが済んだレンダーツリーをピクセルに変換して、ブラウザ画面に結果を描画します。

まとめ

以上がブラウザ画面の描画の流れになります。

①DOM構築
②CSSOM tree構築(DOM構築に含まれる)
③JavaScriptの実行(DOM構築に含まれる)
④レンダーツリー構築
⑤レイアウト
⑥ペインティング

普段何気なく使っている裏側の処理を知ることの大切さを今回感じました。サイトのパフォーマンス改善をするためにはブラウザの裏側の処理を理解することは必須です。

それに今回記事を書く中で、HTMLやCSSの書き方が表示速度に直接影響することを知りました。どう動いているのか？どう表示されているのか？と言った仕組みへの理解は良いコードを書くために欠かせない要素だと思います。

今回調べたのはブラウザ描画の流れの中の一部分についてなので、更に詳しく調べて全体像をまとめた記事を後日出そうと思います。

拙い文章にも関わらず、ご精読ありがとうございました！

株式会社Hajimariでは、Laravelをメイン言語として自社開発・受託開発を行なっており、
一緒に開発を行なっていただけるエンジニア募集しています！長野拠点の立ち上げメンバーも大募集しています！

興味のある方は以下の記事をぜひご覧ください！
みなさまとお会いできるのを心からお待ちしております！

www.wantedly.com www.wantedly.com www.wantedly.com www.wantedly.com

2022-11-16

『Gather.Town』でリアルオフィスを再現して明日からリモート出社する方法

■Gather.Townとは
■Gather.Townの背景と前景についての前提知識
■必要なツールとソース
- Tiled
- gathertown/mapmaking
Step.0 自社オフィスの見取図を手に入れる
Step.1 MapmakingをCloneする
Step2. テンプレートをベースに作っていく
- 基本機能説明
Step3. 不要なものを消していく
Step4. 作りたいものを作っていく
Extra Step1. 影を付ける
Extra Step2. 背景を設定する
Step5. 画像を出力しGatherに設定
Step6. Tile Effectを設定する
Step7. 細かな効果設定をする
■おわりに
■参考資料

こんにちは！

実は9月から株式会社Hajimariに入社していた上山です。

インターネットでは 「やむ」 という芸名でやらせていただいております🙏

ITプロパートナーズ事業部にてスクラムマスター兼開発という立ち位置で、チームが幸せに働けるように日々研鑽しています！

メインはZennで書いています😉

zenn.dev

QiitaはQiita Organizationのために使っています😭

qiita.com

twitter.com

Hajimariでは、

現在リモートワーク・オフィス出社をその日の予定に合わせて決めることのできる

「365日リモートワークOK制度」を取り入れており、

各メンバーが生産性高く働ける方法を考えて仕事をしております。

（詳しくは↓を見ていただければと思います。）

hajimari.inc

リモートワークを取り入れるにあって大事なのは、

やはりコミュニケーションの取り方なのではないかと思っております。

対面とは違い、気軽にコミュニケーションが取れないようでは

リモートワークの利点も十分に活かしきれなくなってしまいます。

そこで、今回はリモートワークでも社内のコミュニケーションを活発化させる為に

Gather.Townを使ってリアルオフィスを再現してみました！

Gather.Townを使うにあたり

「何か特別な技術が必要なんでしょ？」

と思われる方もいらっしゃると思います。

しかし、今回必要なのは根気です。

何時間も少しずつポチポチする根気さえあれば、誰でも実現可能になるように記事を執筆させていただきました。

ぜひ読まれた方は、ご自分の根気で自社のリアルオフィスを再現し

「社長！Gather.Townでオフィス再現したんで、明日からフルリモートでいいっすか！！！！？」

と提案してみてくださいww👍

■Gather.Townとは

www.gather.town

もう新進気鋭と言われないくらい、定番のオンラインビデオツールになりました。

ご存知でない方にヒトコトで簡単に説明しますと、「昔のドラクエ気分でオンライン通話できる」 ツールになります。

「Google Meetでもよくない？」と思われる方もいらっしゃると思いますが、 「実際に、その場にいる」 オフィス感を出すのであればGather.Townのほうが優位です。

朝出社して、自分の席で仕事して、退社時に接続を切る。実際の出社退社のような感覚も味わえるため、一体感通してはオススメです。

「リモートでずっと繋げっぱなしとかヤバ・・・」 と思われたそこの方、Gatherにはプライベートスペース機能があり、「常に繋ぎっぱなし」という状態ではありません。

詳しい説明はここでは省きますが要は 「リモート下でも、一緒に仕事をしている雰囲気」 を作るためのツールです。

■Gather.Townの背景と前景についての前提知識

support.gather.town

まず、前景と背景の概念のざっとした説明をします。

以下の画像のように

背景はキャラクターの下にくるもの
前景はキャラクターと背景の上にくるもの

になります。これを踏まえて前景・背景を分けて作っていく必要があります。

Gather.Townの前景・背景共に設定できる画像は以下の条件です。

3200 x 3200 ピクセル以下
最大ファイルサイズ3MB

「どうやって設定するの？」という点ですが、公式の方でドキュメントを準備してくれているため、参照してみてください。

support.gather.town

ざっくり伝えると、下部メニューバーにあるBuild Toolから

Edit in Mapmakerに移動するとドキュメントと同じマップ編集画面に進めると思います。

■必要なツールとソース

Tiled

www.mapeditor.org

実際に前景・背景画像になるマップを作成していくツールはTiledになります。

基本的にはこのツールを使って制作を進めていきます。

gathertown/mapmaking

github.com

実はGather.Townの公式から既存のマップテンプレートやマップオブジェクトをGithub上で公開されています。

基本的にはこのアセットを使って積み木のように積んでいく作業をしていきます。

Step.0 自社オフィスの見取図を手に入れる

場合によっては一番難しい問題です。会社の見取図やそれに準ずるものを持っていそうな人に聞いて手に入れる必要があります。

もしかしたら、ない場合もあります。（その場合は残念ながら根気度が高くなります）

この工程をちゃんとこなせるかどうかで制作コストが段違いで変わってきます。

ぜひ手に入れられるように全力で努力をしてください🙏

Step.1 MapmakingをCloneする

ここで技術ブログ要素を出しておきます。

git clone git@github.com:gathertown/mapmaking.git

クローンしてきます。めちゃめちゃ容量が大きいので注意してください！！

「Gitの使い方わからないよ＞＜」という方にもZIPでダウンロードする方法を一応載せておきます。

Step2. テンプレートをベースに作っていく

mapmaking/maps/templates/Office Modern(Skyscraper)/Office Modern12.tmxを今回はベースに作成していきます。

新しく作ってもいいのですが、アセットのimport関係がちょっと面倒なのでテンプレートを変えるほうが楽で良いです。

テンプレート自体を残しておきたいという方は同じディレクトリ下に複製して名前を変えて編集していきましょう！

基本機能説明

基本的にタイルセットからGather側で用意されているタイルを使用していきます。

凄腕デザイナーとかであれば自分でタイルセットなども自作出来るのですが・・・私はそうではないので、既製品をポチポチ積み木していきます。

ここらへんのツールを主に使います

スタンプ(Bキー)
- 右クリックで範囲選択、その後範囲選択したものをスタンプとして押せます
消しゴム(Eキー)
- 右クリックで範囲選択消去

ここの部分のツールは基礎です。覚えておきましょう👀

Command + Sで保存です。これを忘れてしまうととてつもなく取り返しのつかない失敗を引き起こす可能性があるので注意してください。

また、レイヤーの概念も重要です。前の章で書いた通り、上にあればあるほど前面に来ます。

Step3. 不要なものを消していく

レイヤーから装飾となる影などを削除していきます。

そうするとテンプレートからはtopperとTile Layer1というものだけになり、topperが前景部分、Tile Layer1が背景部分となります。

もちろん多彩な表現をするためにはここからレイヤーを増やしたりするのですが、基本的な根幹部分はこの2つになります。

そしたらこの2つのレイヤーの中にある不必要なものもすべて消してしまいましょう！

見取図など手に入れる事ができた人はぜひ下地として使ってしまいましょう。

その際に、まずはbaseというレイヤーを最下層に作成し、そこに下地を置いておくことをオススメします。

【タイルセット】の場所に画像をドラッグ&ドロップした後に、こちらの設定で取り込んでしまいましょう。

注意点として、ちょっと画像が小さいかも・・・と思っても拡大する方法が物理的に画像サイズを大きくするしかありません。

他に良いやり方を知っている方がいらっしゃったらぜひ教えていただければなと・・・😭

そして下地として画像を読み込んだ姿は下のようになります。

Step4. 作りたいものを作っていく

ツールの使い方を理解しつつ、少しずつ積み上げていってください・・・。

注意してほしいのは、コーディングと同じでいきなり細部にこだわらないことです。

息切れして挫折する可能性が高くなります。少しずつ、少しずつ積み上げていきましょう。

タイルセットは以下を主に使うと思います。

Gather Decoration Exteriorが装飾品
floors_3_simple_S20C-5が床タイル
toppersが天井素材
walltextureが壁素材
WindowsObjectsが窓素材
Gather Shadows 1.xが影素材

そして、地道に積み上げられたオフィスはこちらになります。

基本的に家具類はGatherに取り込んでから設置するので壁と床設置がメインになります。

レイヤーの説明ですが

object
- 柱などの前景に含めたいオブジェクトを入れています。
wall objects
- 窓などの壁の上に置きたいものを配置しています。
over topper
- 各部屋の区切りとしての黒い細線の部分で使われています。
topper
- 壁が主にここで配置されています。ここまで前景で主力する想定です。
background topper
- 壁の下部に当たる部分がここで配置しています。
- ここから背景に含まれる想定です。
- この分け方をしないと、壁の下にキャラの頭の一部が入ってしまい、微妙に違和感を感じてしまいます。
- （これ以降の画像ではbackground topperレイヤーは存在していないのですが、テスト段階で気づき手戻りして増やしました）
back objects
- 椅子をここで配置しています。
back objects2
- 椅子が2マス使うケースがあり、隣同士で設置したかったためレイヤーを分けています。
carpet
- カーペットや壇上などの「床の上に設置したいもの」をここに置いています。
floor
- 床です。
base
- 下書き・ガイド線として使った画像のレイヤーです。後で消します。

Extra Step1. 影を付ける

shadowレイヤーを一番上（前面）に作成し影を配置していきましょう。

タイルセットはGather Shadows 1.xです。

影を付けると急に重厚感が出てきました（そんなに変わったように見えませんが・・・）

階段部分は影で上か下に行くかを判別できるようになるので、結構重要な要素かもしれません。

Extra Step2. 背景を設定する

今のままではなんとも言えない悲しさがあります。そうです。背景がないからです。

しかし、背景まで一から作っていくとしたら制作が何十倍にも膨らんでしまいます。

その上、背景は基本的に見るだけで行けないもの・・・。コストに対するリターンもそれほど大きくありません。

なのでここではGatherで使われている背景を使っていきます。

mapmaking/large splash art/に入っている画像をタイルセットとしてインポートし、使っていきます。

超絶雑ですがこんな感じにまとめました。さっきよりは雰囲気がよくなった（と信じたい）です。

Step5. 画像を出力しGatherに設定

前景出力と背景出力の2ステップを行います。

まずは前景から。前景としたいレイヤーだけを表示させほかは非表示にします。

そうしたら、上部メニューバーから

ファイル > 画像でエクスポートを選択し、以下のようなウィンドウで「表示レイヤーのみを含める」をチェックします。

そしてエクスポートです。これにて前景画像の出力が完了しました。

同様に背景画像の出力も行ってください。

いよいよ取り込みです。

前提知識の章で取り上げた操作方法からマップ編集画面へ移動し、背景画像のインポートと前景画像のインポートを行ってください。

そうすると上手く取り込めます。

Step6. Tile Effectを設定する

今のままだと自由に壁を貫通できたり、行けてほしくない場所に行けてしまいます。

なので、ここからは当たり判定を付けてちゃんと行けないように制限を付けていきます。

Tile Effectのタブから Impassableを選択し、行けてほしくない場所に設定していってください。

そしてObjectsから家具を配置していってください。

ある程度置き終えるとそれなりに形になってきます。いい雰囲気ですね！！

Step7. 細かな効果設定をする

会議室で空間を区切れたり、席の近くでしか声が聞こえないようにしたりなど、様々な設定ができます。

そしてできた完成品がこちらです！

概ねいい出来ではないでしょうか🤔

前景画像を意識しつつ制作したことにより、柱の後ろにも隠れられるようになりました。

前景画像設定のおかげで、天井の梁も表現されているように見えます。

前景と背景をきちんと意識しながら作ることがGather.townのマップを作る上で重要なことが分かりますね。

これを意識しないと手戻りが結構発生してしまうので、精神衛生上あまり良くないです😭

■おわりに

Gather.townのマップをカスタムすることで、よりチームの結束力を高めることができます。

コロナ禍でリモート業務が普及した今、昔の「リアルオフィス」を再現することで今一度盛り上がり、関係性の質を高めてもいいのかもしれません。

ハイブリッド勤務を採用している企業では、リアルオフィスの席と座っている人がリンクしているだけで、もし自分がリアル出社した際に「誰が」「どこに」座っているかが分かります。

新卒の方で、なかなかオフィスに来れない方に一体感を感じてもらうためにも良いのでしょうか？

Gather.townでリモートで希薄になってしまった社員間のやりとりが少しでも活発になれば嬉しい気持ちです。

■参考資料

2dgames.jp

dev.classmethod.jp

興味のある方は以下の記事をぜひご覧ください！
みなさまとお会いできるのを心からお待ちしております！

www.wantedly.com www.wantedly.com www.wantedly.com www.wantedly.com

2022-09-28

【新人エンジニア】MVCモデルの進化版！？　ADRが使いやすかったお話

Laravel 新卒エンジニア

こんにちは！
7月からインターン生として株式会社Hajimariに入社した、難波　慧人です。

現在は、TUKURÜS事業部で受託開発の業務を行っています！今行っている案件では、サブスクリプション型動画配信サイトの、新規機能開発・運用保守を担当しています！

開発言語に関しては、バックエンドはPHP（laravelフレームワーク）を用いており、アーキテクチャはADR（Action Domain Responder）を採用しています。

案件にジョインした当初、MVC アーキテクチャしか知らない私でしたが、ADRの有用性が少しずつ理解できてきました！

そこで今回は、MVC アーキテクチャと、ADR アーキテクチャの違いについてご紹介したいと思います！！

また、各項目にサンプルコード（ユーザーの一覧、詳細機能）を示していきます！！

■MVC（Model View Controller）とは？？

引用元（ https://white-t007.com/tech/it%E5%9F%BA%E7%A4%8E/mvc/ ）

ユーザーインターフェイスを持つアプリケーションを、モデル（Model）、ビュー（View）、コントローラー（Controller）の3つの責務に分割して、実装していく手法です。

qiita.com

モデル（Model）

モデルとは、アプリケーションの中で、ビジネスロジック、データベースとのアクセスを担っています。例えば、計算、データ取得、データ管理などが挙げられます。

Laravelフレームワークでは、Eloquent ORMと呼ばれる、モデルとデータベースの紐付けを行う機能があります。
Eloquent ORMにより、アプリケーションとデータベース間のデータのやりとりをより円滑にすることができます！！ readouble.com

サンプルコード

Models/User.php

class User extends Model
{
    /**
     * usersテーブルから全てのユーザーを取得
     * 
     * @return Collection
     */
    public function fetchAllUsers(): Collection
    {
        return User::all();
    }

    /**
     * usersテーブルから指定ユーザーを取得
     * 
     * @return ?User
     */
    public function fetchUser($userId): ?User
    {
        return User::where('id', $userId)->first();
    }
}

ビュー（View）

ビューとは、webサイト上のレイアウトを作成する役割を持っています。主にHTMLで記述されます。また、ビューから生成されたレイアウトはアプリケーションとユーザーのインターフェイスになっています。

ユーザーはこのweb上のレイアウトを通して、アプリケーションにリクエストを送信、アプリケーションからのレスポンスを閲覧することができます。

コントローラー（Controller）

コントローラーとは、ユーザーからのリクエストに応じて、モデルとビューの制御を担う部分です。実際のユーザーインターフェイスはこのコントローラーになります。アプリケーションとユーザー間のやり取りは全てここを経由します。

ユーザーがwebサイト上で商品一覧をみたい時を例にします。ユーザーから「商品一覧がみたい」というリクエストが来たら、モデルに商品データを取得するように依頼します。次に取得データをビューに渡し、ビューが作成したレイアウトを、webサイト上に表示しています。これによって、ユーザーがweb上で、商品一覧を閲覧することができます。

サンプルコード

Controllers/UserController.php

class UserController extends Controller
{
    /**
     * ユーザー一覧
     *
     * @return \Illuminate\View\View
     */
    public function index(): View
    {
        // Userクラス（モデル）のインスタンス作成
        $userModel = new User();
        // Userクラス（モデル）のメソッドを使って、ユーザーを取得
        $users = $userModel->fetchAllUsers();

        return view('users.index', ['users' => $users]);
    }

    /**
     * ユーザー詳細
     *
     * @param  int  $userId
     * 
     * @return \Illuminate\View\View
     */
    public function show(int $userId): View
    {
        // Userクラス（モデル）のインスタンス作成
        $userModel = new User();
        // Userクラス（モデル）のメソッドを使って、ユーザーを取得
        $user = $userModel->fetchUser($userId);

        // 対象ユーザーが存在しなかったら、404ページを返す
        if(is_null($user)) {
            abort(404); 
        } else {
            return view('users.show', ['user' => $user]);
        }
    }
}

MVCの問題点

コントローラーの肥大化
コントローラーは基本的に、ユーザーインターフェイスとしてアプリケーションの入出力のみを担う責務ですが、コントローラーにビジネスロジックやデーターベースのやり取りを記述される場合があります。
モデルの肥大化
モデルとは、ビジネスロジック・データベースアクセスを書く場所である。しかし、アプリケーションの規模が大きくなると、ビジネスロジック・データベースアクセスも必然的に増えていき、結果モデルは肥大化していきます。。。

ADRの導入

以上の問題点を踏まえ、MVCの改良版でもあるADR（Action Domain Responder）を導入しています！！

■ADR（Action Domain Responder）とは？？

上記のMVCモデルの改良版として、Paul M. Jonesによって提案されたソフトウェアアーキテクチャパターンです。

引用元：（ https://en.wikipedia.org/wiki/Action%E2%80%93domain%E2%80%93responder ）

ADRでは、アクション（Action）、ドメイン（Domain）、レスポンダー（Responder）の3つの責務に分割して、実装していく手法です！

ADR:wikipedia

アクション（Action）

ユーザーからのHTTPリクエストを受け取り、ドメインの処理結果をレスポンダーに渡す役割です。MVCでいうコントローラー的な位置付けです。全てのHTTPリクエストはここで処理されます。
HTTPリクエストとは

サンプルコード

Actions/User/UserIndexAction.php

class UserIndexAction extends Controller
{
    /**
     * Instance of the Responder property.
     *
     * @var UserRepository
     * @var UserIndexResponder
     */
    protected $userRepository;
    protected $userIndexResponder;

    /**
     * Instantiate the class.
     *
     * @param UserRepository $userRepository
     * @param UserIndexResponder $userIndexResponder
     */
    public function __construct(
        UserRepository $userRepository,
        UserIndexResponder $userIndexResponder
    )
    {
        $this->userRepository = $userRepository;
        $this->responder = $userIndexResponder;
    }

    /**
     * Invoke our action, handle domain, respond.
     *
     *
     * @return View
     */
    public function __invoke(): View
    {
        $users = $this->userRepository->fetchAllUsers();

        return $this->responder->response($users);
    }
}

Actions/User/UserShowAction.php

class UserShowAction extends Controller
{
    /**
     * Instance of the Responder property.
     *
     * @var UserRepository
     * @var UserShowResponder
     */
    protected $userRepository;
    protected $userShowResponder;

    /**
     * Instantiate the class.
     *
     * @param UserRepository $userRepository
     * @param UserShowResponder $userShowResponder
     */
    public function __construct(
        UserRepository $userRepository,
        UserShowResponder $userShowResponder
    )
    {
        $this->userRepository = $userRepository;
        $this->responder = $userShowResponder;
    }

    /**
     * Invoke our action, handle domain, respond.
     * 
     * @param Request $request
     * 
     * @return View
     */
    public function __invoke(Request $request): View
    {
        $user = $this->userRepository->fetchUser($request->user_id);
        
        return $this->responder->response($user);
    }
}

ドメイン（Domain）

アクションから受け取った依頼をもとに、ビジネスロジック、データベースアクセスを担当する役割です。MVCでいうモデル的な位置付けです。
ビジネスロジックとは

今回は、Domainをさらにサービス（Service）、リポジトリ（Repository）、モデル（Model）に分けています。

サービス（Service）
主にアプリケーションビジネスルールを記述する。
（アプリケーションビジネスルール = システムであるがゆえに発生するビジネスルール）
例）データに対する複合処理、データ加工など
リポジトリ（Repository）
データベースとのインターフェイスとして使用。
例）データベースアクセスのみ（加工はサービスの責務）
モデル（Model）
主にエンタープライズビジネスルールを記述する。
（エンタープライズビジネスルール = アプリケーション都合でないビジネスルール）
例）野球　勝敗：点数が多い方が勝ち　時間：9回で終了　試合人数：各チーム9人ずつ
サンプルコード　（今回はビジネスロジックがない為、リポジトリのみ）

Domain/User/UserRepository.php

class UserRepository
{
    /**
     * usersテーブルから全てのユーザーを取得
     * 
     * @return Collection
     */
    public function fetchAllUsers(): Collection
    {
        return User::all();
    }

    /**
     * usersテーブルから指定ユーザーを取得
     *
     * @param int  $userId
     *
     * @return ?User
     */
    public function fetchUser($userId): ?User
    {
        return User::where('id', $userId)->first();
    }
}

レスポンダー（Responder）

ドメインの処理結果を受け取り、HTTPレスポンスを作成、処理を担当します。MVC モデルのビューとは異なり、httpステータスの変更、クッキー操作も行います。

サンプルコード

Responders/User/UserIndexResponder.php

class UserIndexResponder
{
    protected $view;

    public function __construct(ViewFactory $view)
    {
        $this->view = $view;
    }

    /**
     * 単体動画の表示
     *
     * @param Collection $users
     * 
     * @return View
     */
    public function response(Collection $users): View
    {
        return $this->view->make(
            'users.index',
            compact('users')
        );
    }
}

Responders/User/UserShowResponder.php

class UserShowResponder
{
    protected $view;

    public function __construct(ViewFactory $view)
    {
        $this->view = $view;
    }

    /**
     * 単体動画の表示
     *
     * @param ?User $user
     * 
     * @return View
     */
    public function response(User $user): View
    {
        if (is_null($user)) {
            return \App::abort(404);
        } else
        {
            return $this->view->make(
                'users.index',
                compact('users')
            );
        }
    }
}

MVCからの改善点

コントローラーの肥大化
MVCのコントローラーでは、ユーザーインターフェイスとして、全てのリクエスト、レスポンスを処理していました。
しかし、ADRではリクエストをアクション、レスポンスをレスポンダーといったように、責務を分けることで改善されています。
また、ADRでは、1アクションに対し1クラスしか作成しません。これにより、1つのコントローラーにメソッドが集中することを避けれます！！
モデルの肥大化
MVCのモデルでは、全てのビジネスロジックの責務を担当していましたが、サービス（Service）、リポジトリ（Repository）、モデル（Model）という責務に細分化することで、モデルの肥大化を防ぎます。
保守性、可読性の向上
実際、コードリーディングを行う際に、処理の流れが明確なので追いやすいです。
また、データーベースアクセスが一目でわかる、追いたい処理を探す時にもファイル特定がしやすい（サービス層の処理ならDomain配下のserviceファイルを探せばいい）などの利点がありました！

■まとめ

以上が、MVCとADRの違いでした！！

最初は、「ADRってなんぞや？？」と戸惑いましたが、

MVCをある程度理解していれば、ADRのキャッチアップもやりやすいと思います！

是非ともADR（Action Domain Responder）を導入してみてはいかがでしょうか？

Fatなコントローラー、モデル内で、無限スクロールする開発生活から解放されるはずです。。。

興味のある方は以下の記事をぜひご覧ください！
みなさまとお会いできるのを心からお待ちしております！

www.wantedly.com www.wantedly.com www.wantedly.com www.wantedly.com

2022-09-21

エンジニア交流会やってみた！！

新卒エンジニアエンジニア交流会

こんにちは！

2022年5月から株式会社Hajimariでエンジニアをしています、植本です。現在は、TUKURÜS事業部で主に受託開発の業務を行っています。

今回は先日行った、弊社の23卒内定者を含めた全エンジニアでの「エンジニア交流会」について書いていきます！

というのも、、、

他事業部の社員と話すことがあんまりない
（内定者から）オンラインだと距離感が掴めなくて気軽に話せる人は実は少ない・・・

という声を聞いていました…！

リモ―トワークが普及しつつある今、会社によって社員同士の交流の頻度が減っているところもあると思います。

確かにこれじゃ何かあっても殆ど話したことない人に気軽には相談しにくいですよね…。（そりゃそう）

ということで（？）

エンジニア交流会を開催したので、その様子を一挙大公開します！！！

※社員同士の交流は最低限でいい、という方もいると思います。その考え方も尊重しているので、今回の交流会は「強制」ではなく「自由参加」です！

※でも、都合が合わない方以外はほぼ全員参加してくれました、本当にありがとうございます（歓喜）

さてさて前置きが長くなりましたが、、、

株式会社Hajimariのエンジニア組織がどんな雰囲気か知りたい！

弊社エンジニアのリアルな様子が知りたい！

弊社の個や組織へのこだわり/想いが知りたい！

こんなことが気になる方は是非読んでみてください！！

※今回の記事は技術的なことは書いてありませんのでご了承ください、、、

Hajimariの社員ってどんな人がいる？
なぜエンジニア交流会を行ったのか
エンジニア交流会の内容
終わりに ~弊社が大切にしている自己理解と他者理解、組織理解~

Hajimariの社員ってどんな人がいる？

そもそも弊社やその社員についてどのような印象でしょうか。

自分と仲間の決断と行動、その結果を受け入れて前に進んでいくことのできる人ばかりです！本当に人の良さは声を大にできるのですが、、、

ここで語っても中々イメージ湧かないと思うので最近の記事を紹介しておきますね！（是非覗いてみてください！）

www.wantedly.com

なぜエンジニア交流会を行ったのか

嗚呼、また前置きが長くなってしまったorz

端的に言うと、、、

新しいメンバーも増えてきたので、自己理解と相互理解を深めて自分の目指すべき方向性を再確認してもらうため

にエンジニア交流会を開催することにしました！

弊社は2015年設立のベンチャー企業で、社員数は127名（2022年9月時点）です。新卒採用では23卒を26人採用しておりどんどん大きくなっている会社になります。長野拠点も今年度から本格的に活動をしています！

note.com

そしてエンジニアという括りでいうと、社員数は32人、そのうち23卒内定者9人、インターン生は4人です。

こういった背景を踏まえると、今回の交流会は

長野拠点/リモートワークで、物理的に普段話せない仲間との交流の場になる点
全国にいる23卒内定者に、弊社のエンジニア組織や雰囲気を感じてもらえる点

で大きな意義があるものだと思います！

と言っても、会社全体として危機感が募った結果、交流会をしなきゃ！となったわけではありませんでした。

急激に人数が増えたことでコミュニケーションが疎になりつつあることを感じていて、「一回交流の場をあったら良いね」という話から、「じゃ、エンジニア交流会やろっか！」と自然にスタートしました！

自分と仲間の「自立」に向き合える環境を創ることも弊社が大切にしていることなのです。

エンジニア交流会の内容

今回のエンジニア交流会はオンライン開催、3部構成でした！！

一致するまで終われまテン

wevox value card

Will語り会

1. 一致するまで終われまテン

1つ目の終われまテンは、zoomを使ったアイスブレイクです！準備の段階では、オンラインだし初対面の人同士もいるしでやや心配していました。。。

でもゲーム後には打ち解けた様子でメインルームへ帰ってきてくれました！ゲームの様子と伴に各ルームで珍回答があったようなので、一部晒しておきます！知らない観光名所で勉強になりました。

「川」のつく名字で、まず西川が出てくるのか・・・

2. wevox value card

2つ目からは、自分と仲間の価値観や大切にしていることを相互理解をする催しです！

wevox.io

このゲームも今回の趣旨にぴったりのもので、ゲーム中「そんなこと思ってたんだ！」とか「あ〜、どれも捨てがたいいい」などの声が終始続いていましたようです！

終わったあとに少し雑談（いつの間にか人以外が紛れ込んでいました・・・）

3. Will語り会

場も温まってきて、自分の価値観も言語化できたところで、最後の催しです！

できるだけ①事業部が異なる、②年代が異なるを意識してペアを作り、1on1形式でWill語り会をしました。

自分のWillとそのきっかけ

Hajimariに入社(内定承諾)した理由

今やっている業務内容や今後やってみたいことについて

過去〜未来の時間軸で自分の価値観や想いを語ってもらいました！アンケートの結果では一番評価が高く、むしろ時間が足りなかったという声が多かったです！

飲みに行くことが決まったメンバーもいたとか笑

（因みに話に夢中になって写真撮るの忘れてしまいました泣）

終わりに ~弊社が大切にしている自己理解と他者理解、組織理解~

終わった後に、アンケートを見ながら運営陣で振り返りをしました！

「終始笑顔が溢れていた空間だった」「内定者が打ち解けた様子で嬉しかった」「交流なので、いろんな他事業の人と話せるコンテンツでも良かったかもしれない」などなど色んな意見をいただきました！！

ただ、アンケート上で良い評価をもらえましたが鵜呑みにするべきではありません。今回参加できなかった人との間に溝が生まれてないか、参加はしていたけど消極的だった人はいなかったか。それに、交流会などのコミュニケーションの場は1回行えば大丈夫というものではありません。かと言って1回1回が長時間となると負担が大きくなるのでそれもまた良くはないように思えます。

反省点や考えることは尽きませんが、、、

こういうたくさんの言葉をいただけただけでも、やって良かったなと素直に感じます！

まだまだ組織には課題が山のようにあります（汗）が、交流会を通して気付けたこと/良くなったこともあります！

それらに対して今後どうするか、続・エンジニア交流会をするのか、、、勉強会をやってみるのか、、、もくもく会をするのか、、、

まぁとにかく色んなことをやってみるので今後の記事に乞うご期待ください！！

こんな感じで（急にまとめに入る）

以上、Hajimariのエンジニア交流会のお話でした〜！

株式会社Hajimariでは、一緒に働く仲間を募集しています！
長野拠点の立ち上げメンバーも大募集しています！

興味のある方は以下の記事をぜひご覧ください！
そして気軽にお話しましょう！！　
みなさまとお会いできるのを心からお待ちしております！

www.wantedly.com www.wantedly.com www.wantedly.com

2022-09-12

【Raycast】心地の良いPCライフを送るためのランチャーアプリ

Raycast ランチャー効率化

【Raycast】心地の良いPCライフを送るためのランチャーアプリ

こんにちは！
6月から23卒内定者インターン生として株式会社Hajimariに入社した、江端凌です。

普段は、TUKURÜS事業部で受託開発の業務に携わっています。

今回は普段の業務を効率化するためにインストールしたランチャーアプリであるRaycastが便利すぎたので、この場を借りてご紹介したいと思います。

ランチャーアプリとは

ランチャーアプリとは、ショートカットなどの簡単操作でファイルやフォルダーの呼び出し、起動などが行えるアプリです。

Macをお持ちの方は、⌘ + spaceキーで既存のランチャーアプリである「Spotlight」が使えます。実際に、このSpotlightにアプリケーションの名前入力すると起動してくれます。

support.apple.com

もちろん、検索したいキーワードを入力するとGoogle Chromeで検索結果を表示してくれますし、PCを使う上で痒いところに手が届くアプリなのです。

Raycastをインストールする

では、RaycastがどのようにSpotlightより優れているのかを紹介する前に、実際に使いながら実感してもらうためにインストール方法から説明していきます。

まずはRaycastのサイトに飛んで、「Download for Mac」を押下してください。

www.raycast.com

ダウンロードが開始され、完了するとRaycast.dmgがダウンロードディレクトリ配下に入っています。

クリックして開くと以下のような画面になっていると思うので、

Raycastのインストール画面

左側のRaycastのアイコンをドラッグして、右側のApplicationsディレクトリにドロップします。これでMacのLaunchpadなどからRaycastを探せるようになります。

Raycastを起動したら以下のような表示になります（初回起動は確認事項があるので、全て右下のボタンをクリックでOKです）。

Raycastの初期画面

Raycastのここがすごい

個人的にRaycastがすごいと思う箇所は、その万能さです。

例として、コピーした履歴を表示させる「Clipy」という有名なアプリがありますが、似たようなことがRaycastの「Clipboard History」という機能でも可能です。
もちろん「Clipy」とは使い勝手も違うので、この場でどちらが便利だよというわけではありませんが、よく使われるアプリの機能も包括的にサポートしているという点がRaycastの大きなメリットです。

Raycastの基本機能

ではどのように「Clipboard History」を利用するかご紹介していきます。

まずはoption + spaceキーでRaycastを起動して、検索窓に「Clipboard History」と入力します。

ClipboardHistory

すると、一番上に「Clipboard History」が表示されているので、選択してください。
そうするとコピー履歴が表示されます。

ただ、呼び出すのが面倒ですよね。 Raycastにはわざわざoption + spaceキーで起動して、検索欄で検索をかけなくても良い方法がありますが、それは後述します。

前述した通り、Raycastのすごいところはその万能さです。
Raycastは「Clipboard History」以外に、多くの機能を備えています。

Window Management

WindowManagement

「Window Management」は、ウインドウサイズを自在に操作できる機能です。
主に左右に画面分割するときに重宝します。

Snippets

「Create Snippet」、「Search Snippet」、「Import Snippet」はスニペットを作成、検索できる機能です。
スニペットに登録した内容は、「Keyword」を入力したら呼び出せます。

Quit All Applications

QuitAllApplications

全アプリケーションを落とせます。
PCを使い続けていると、いろんなアプリを開きまくって負荷もかけまくっちゃいがち。
このコマンドで定期的にアプリを落としてあげましょう。

ショートカット

では、そんな便利なコマンドたちをショートカットで呼び出せるようにしていきましょう。

Raycastには「Hotkey」と呼ばれる機能があり、これを使うことでRaycastの機能をショートカットに登録できます。

例として、僕はshift + control + Hに「Clipboard History」登録しています。

登録の方法としては、

option + spaceキーでRaycastを起動。
⌘ + ,（カンマ）で設定画面を表示。
Extensions から、「Clipboard History」を検索。
「Clipboard History」のHotkeyの欄をクリックして、画像のように「Recording...」と表示されたら、登録したいキーを押してください。
一度option + spaceキーでRaycastを閉じて、登録したショートカットで「Clipboard History」が起動したら成功です。