仕様, 設計が 甘くて 禿げた

f:id:gashoo:20171201153719j:plain


はじめに

Gashoo inc. Engineer の しゅん(@shunn_93) | Twitterです~


GASHOO Inc. Advent Calendar 2017年12月18日 を飾ります。

前回引き続き 自身の1年の振り返りとともに

過去に 機能提案 → 実装 まで 行っていて , いろいろ 食い違っていたり, 自分の設計などが 甘くて, ハゲたときの お話です。

それから、今後 ハゲたくないという思いから , Gashooで 提案の際に 最低限 守っていることを お伝えできればなと思います。



2017年7月 ~ 9月


7月   他の言語を勉強する
      VPSを借りてみる
      マネジメント能力を求められるが ないことに気づく
      新機能実装にあたり 無我夢中にキーボードを叩く

どちらかというと, これまで 自分がマネジメントされていたので、
誰かを マネジメントするということが できなさすぎて、自分 全然できないなと思う。

8月   仕様,設計の重要性を痛感
      自身の成長を感じれない
      プロジェクトマネージメントをしてもらう

7月に ひたすら書いてたコードを全てやり直すことになり, ハゲる。

原因は, 仕様, 設計などなどの甘さ 設計に 時間をもっと割くべきだ という思考になる。

9月   同じ界隈のエンジニアを知り比べられている対象を知る
      レビュー会という定期ミーティングが行われるようになる
      PMがいているだけで, だいぶと助かるということを知る

なんだかんだ この時期で 8 - 9ヶ月間 エンジニアをやっていて、
すごい だとか 褒められたりしていたのですが、
自分ができるなんて 思ったことなかったのですが、
比較されている対象を知って ざっくりというと「あぁぁ」 となった。笑





提案の際に 最低限 守っていること

Gashooのように 少人数の組織で行っているからこそ、
こういう問題はしっかり気をつけたほうがいいと思います。

例えば,

ある日

提案者 ) こういう機能が欲しい!!!作って!!

実装者 ) よっしゃ作ろう!!!

...

...

...

実装者 ) よっしゃ できたで!!!

提案者 ) おぉ ええやん!! あ、ここの機能 こうできる??

実装者 ) えっ、あっ、は、はい。できるんですけど...



fin...





ってな感じの 悲しい結末になった経験が幾度とあります。

で、なにを していれば こういった フワフワした機能実装提案を
今の僕達で 防げるのか...と考えました。



考えた結果,

「 その機能に対して, 5W1Hをしっかりと言えるようにする 」
5W1H(ごだぶりゅーいちえいち)とは - コトバンク

これだけで 良いと思いました。



エンジニアじゃない人だと, あそこの処理をこうして、ここの処理でこのリクエストを...とか考えれないので、

「いつ（When）、どこで（Where）、だれが（Who）、なにを（What）、なぜ（Why）、どのように（How）」

これを 考えるだけで、提案する人も作る人も 幸せになります。

恐らく これくらいだと 誰でも できるはずです。

これがないと、「ほんまかぁぁ~~」となって 提案の提案です。



' ブレイン・ストーミングブレインストーミングとは - コトバンク ' のようなディスカッションの場では, バンバン 言いまくって良いかもしれませんが、ガチで提案するのなら, きちんと考えるべきであり, どうにかして作る方向にもっていくと思います。

そういった提案, 要望を伝えられてから, どう実現するのか, DBはどうするだとか, 正規化や マイクロなどなど の話は エンジニアの役割だと思っています。



5W1H提案を推奨する理由

いいね 機能を作って!!! と言われた場合 アナタはどう思い, なにをイメージしますか??



Twitter の いいね のような機能で いいねしたら 自分が いいね したツイートのリストが見れて... とイメージするのか

Facebook の いいね のような機能を イメージするのか, それとも Instagramのような いいね を イメージするのか...

人によって 様々だと思います。

こういった 共通認識の ズレを 最低限 解消できるのが 5W1H である。



例えば Gashooに いいね 機能を 実装するとしたら、(既にありますが...)

Gashooで (When)

作品の詳細画面で (Where)

ユーザーさんが (Who)

その作品に対して いいね できる。 (What)

なぜなら、いいね されたら嬉しいし, いい作品には 良いと 伝えたいから(Why)

作品詳細画面で 作品を見終わった後に, いいね というボタンがあって押すだけで完了するようにする (How)

正直 これだけでもよい..w

こういう提案の始まり方をすれば、最低限の 情報を 共有してスタートなので、 次のステップにも 行きやすい。

いいねボタンの場所はどうする? デザインはどうする? いいね したあとは どうする? された側は? いいね したら、自分いいねした一覧って必要かな? ...etc

といったように どんどん 出て来る。


となると, 設計の イメージも 湧いてきたりする。



せっかく , 案を 出したのに, せっかく , 実装したのに , 使われなくなったり , なくなるのは 悲しいので 両者幸せになるためには、基本的なことではあるが、5W1H で 提案しましょう~~。



以上🙇



余談

前回の古川のアドベントカレンダー
見積もりは, あくまでも見積もり - GASHOO BLOG



過去のGASHOO Inc. アドベントカレンダーの記事はこちら
adventar.org

多様化するデザインという領域の中で、僕に不足していたもの(ヾﾉ･∀･`)ﾅｲﾅｲ

f:id:gashoo:20171216180633p:plain

はじめに

※この記事は、GASHOO Inc. Advent Calendar 2017 12月16日(土)の記事です。

こんにちは、株式会社ガシューのCDO、白石です。🐶🐶

3回目となる僕の更新は、株式会社ガシューの中でwebサービスをデザインするという業務において、恐らく求められていたであろうこと、できなかったことを反省し、来年に活かそうという内容です。

デザインに携わる皆様には「こういう勉強法あるよ」だとかご教授いただけると幸いです。もちろんそうでない皆様もお待ちしています。

ていうか、普段何してるの❗️❓

株式会社ガシューは設立から1年ちょっとと、まだまだ駆け出しの会社です。なので１人に求められる業務の種類も多岐に渡ります。僕はというと、サービスのビジュアルデザインはもちろん、サービスに実装する機能の吟味(これは全員で行います)、HTML/CSSなどのマークアップ、簡単な計測(Analytics)、その他クライアントワークとそれに応じて発生する業務全般などが主です。

さて、下記が今年チャレンジしきれなかった事々です。

💭経営層に携わるデザイナーとして、組織・戦略をデザインの視点から考える💭

これは、できなかったというか、今のところ必要がなかったというと言い訳なのですが、現在のフェーズでは、代表松江を暴れさせることが大事だと思っていました。彼の描く世界観が、フォローしてくれている人々に浸透すれば成功だと考えていました。幸い、彼はセルフプロモーションに長けていたので、デザイン視点からのフォローはほぼ必要なく、自身でファンを増やしていったように思います。

そして、現在の少数体制では代表の意見は反映されやすく、組織のモチベーション管理も彼が行っていたので、組織をデザインするのは次のフェーズなのかなと考えています。

タイトルとは反してこれは上手くいっていたかなと考えることなのですが、抽象レイヤーのビジョンを具体レイヤーの作業まで翻訳して伝えることは上手くいっていたかなと考えます。浅く広くしか取り柄がなくても組織の接着剤になりうるのだと考えます。

🚀どうすれば、より伝わるのか🚀

ここは単純に経験が不足しているなと感じました。昔から整理は苦手ではないですが、整理だけではサービスは成立しないのだと感じました。サービス内に存在する膨大な情報量をどう伝達すればいいのか、どのようなビジュアルに訴求するパワーがあるか、どのような道具に生活を構成する要素としての透明性があるのか、など、考えなければいけない項目はかなり多く、結果として及第点に至ったものは少なかったかなという印象です。

💻モダンで深い技術的内容を理解する💻

前述の通り、慢性的に人が不足しています。僕もキャリアスタートはwebデザインだったので、より高度なフロントエンド技術などは持ち合わせていませんでした。よって、ここは非同期で処理できたらユーザビリティが向上するのにな、みたいな割とパッと目に着くところに着手できなかったりともどかしい部分はありました。

👊🏼Macを叩き割って外に出る👊🏼

端的に言えば、クリエイタの声を聞き、行動を見ることが不足していたなと感じます。サービスのデザインを改修する前に、本来色々と試したいことがありました。ここは今からでも遅くないので、頑張って取り組んでいこうと思います。

あと、外部からのインプットも不足していました。読書からの知識は定期的に得ていましたが、いかんせん新しい業態の知識はイベントやセミナーに顔を出さねば得れません。来年は実行したいと思います。

反省ばかりになりましたが、来年こそやるぞ、と思っていることがたくさんあります。

ここで来年の僕に呪いをかけておきます。

  • jsめっちゃ触れるマンになる
  • 社内用デザイン関連ドキュメントを作る
  • 社内勉強会したい
  • ユーザージャーニーを見直す
  • 行動経済学・認知心理学・記号論・文化人類学・数学 勉強しる
  • ブログとか定期更新したい(希望)

今回はここまでです。最後まで読んでいただきありがとうございました｡･ﾟ･(ﾉ∀`)･ﾟ･｡

白石のアドベントカレンダー2017、最終回は12月21日予定です。🐶

余談

白石のTwitterアカウント
興味を持っていただけましたら、どうぞ。

twitter.com

過去の白石のアドベントカレンダー gashoo.hatenablog.com

gashoo.hatenablog.com

過去のGASHOO Inc. アドベントカレンダーの記事はこちら adventar.org

体験を「愛」で語るのは無駄

「愛とは？」と問われて具体的に答えられますか。喜び・悲し・幸せ・苦し…これら全てを「愛」と呼び、ソレは具体性のない心理的な物だと僕は考えます。人に「愛」を伝える行為は多々ありますが、「愛」を人に認識してもらうのはとても難しい事です。そこで僕なりに「愛」の伝え方...というのを考えてみました。

言葉や行動。ひとつひとつに意味が無くても、理由は必ずあります。

突然ですが「愛」で語るの辞めにしませんか。

生きる環境に応じて人が覚える「愛」は違います。僕が想う「愛」とあなたが想う「愛」は違うはずです。「愛」の実感が全くない人も居ます。どういう状況で「愛」を覚えたのか、感じたのかは、人それぞれ必ず違います。似ても似つかないのです。

「愛」ベースでコミニュケーション取るの辞めませんか。

無駄とは言いませんが、具体的にどういった「愛」なのかよくわかりません。そこに愛があるのか、ないのか。それが伝わっているのか。きっと、この文章にも「愛」があってもなくても、受け取り方次第です。きっとこの文章に「愛」があると僕が言っても、「愛」があるという事が伝わったとしても「愛」の自体を感じる事はできないと思います。

「愛」の段階
f:id:gashoo:20171213193709p:plain

「愛」の周りには必ずいくつもの感情があります。そして人が持ついくつもの感情と感情が交わり「愛」が産まれます。正確には、この感情から「愛」に至るまでにいくつもの否定と理解があると思います。

f:id:gashoo:20171214103555p:plain

例えば、「愛」を感じる前に幸せという感情がありました。その幸せという感情を得るきっかけが必ずあります。それがアクション(行動)です。あらゆる行動が感情に繋がり、それがきっかけで「愛」になります。行動や言葉には必ず理由があります。行動動機に意識が無く、いわゆる「理由はない」状態でも必ず理由はあります。

f:id:gashoo:20171214103649p:plain

「愛」←「感情」←「行動」と来て、行動の前に必ず有る物がシチュエーション(状況)です。人は様々な環境下で育ちます。環境と言うと大小様々多く上げることができますが、国「政治・法律」自然「空気」家族「生活」などから、授業中・仕事中。もっと生々しく、〇〇という状況で〇〇している最中など。そのような状況において、人と人が行動し干渉し感情を持ち、そこから発展する事で「愛」になります。

人に「愛」の存在を実感させるには

人に「愛」の存在を実感させるには「シチュエーション」「行動」「感情」が必要で、突然「愛」がある。なんて伝えても、人によって体感した「愛」は違うのでよくわかりません。

人に「愛」を伝える時には

「愛」を伝えるためには「シチュエーション」から入り「行動」を伝え「感情」を共有した上で「愛」を伝えてください。

行動や言葉には必ず理由があります。行動動機に意識が無く、いわゆる「理由はない」状態でも必ず理由はあります。

その際、「シチュエーション」「行動」「感情」事細かく、伝えてください。言葉ひとつで伝える「愛」が大きく変わります。

もっと感情的で良いんじゃないですか。

理由とか論理とか大事です。わかります。それでも、もっと感情的に動いても良いんじゃないでしょうか。感情的に動いてこそ人間じゃないんでしょうか。AIが進化して来た今、人間の価値は高くなっています。人間らしさを持ったAIでもそれはAIです。人間という生き物である以上。人間らしく。人と人との間にある行動や言葉、その中の感情にもっとフォーカスを向けて人を意識する事が大事だと僕は想います。

以下、僕のエピソード

僕には大切な人が沢山います。普段、お世話になっている家族・友達・恋人・先生・師匠・先輩・仲間。相手がどう思ってるとかよくわかりません。20歳という年齢に達する度、毎年小さな後悔を重ねてきました。そして20歳になり、これまでに多くの「愛」を教えて頂いて生きてきた実感を得ました。本当はもっと前から知っていたのかもしれません。例え、喧嘩しても、そこには「愛」がありますし。嫌われても「愛」がありました。 僕はプロダクトを開発する際、人を物凄く誰よりも意識しています。僕が見る未来に「誰も傷付かない世界」があります。言葉通りです。それは喧嘩をするな・怪我をするな。とかそういう話しではありません。人と人との間、プロダクトとユーザーの間に必ず「愛」があって欲しいのです。ビットコインとかAIだとか、新しい物には触れてください。触れて、利用して「愛」を作って下さい。僕は人間らしく行きます。そして、人が求めている物が「時間」なのか「お金」なのかわかりませんが、そこには必ず「愛」があります。僕は、サービスを作ります。WEBだとかアプリだとかデジタルとかアナログ関係なく、人と人との間に「愛」を作る。僕のポリシーです。そんなサービスを作ります。

以上。

PS

皆さん、歯磨きはしましょう。 １週間程前から、歯が痛くなり下顎が開きません。歯医者に行き治療してもらったら、口内の神経がやられているようで治療や痛み止めなど3つの薬を服用していますが、日中痛みに耐えれず作業ができません。夜も痛み止めが効かず寝れません。歯磨きはしましょう。

あ、鼻血でてきた。

とぅいったー

🥞🍭🍫かわゆた🍣🍖🍡 (@_kwyt) | Twitter

見積もりは, あくまでも見積もり

f:id:gashoo:20171201153719j:plain

序文

⚠ 僕自身の偏りな意見が多く見られるかもしれません
⚠ 当時の僕の気持ちなど 忘れたくないので 記しているってのもあります..


はじめに

Gashoo inc. Engineer の しゅん(@shunn_93) | Twitterです~


GASHOO Inc. Advent Calendar 2017年12月13日 を飾ります。
今回は 前回引き続き 自身の1年の振り返りとともに, 非エンジニアの方に なにかを説明するときの 僕のスタンスを ざっと書いていこうかと思います。



2017年4月 ~ 6月


4月

すっごい なんとかリリースする
社外のエンジニアと初めて話す
分からないことが多すぎ
タスクをgithubで簡易管理を試験的に行う

とある日、Gashooに共感してくれて応援してくれている 社外のエンジニアの方と話す機会ができて、僕に指名が入って、話す前は すっごい罵倒されるかと思った。

今でも思い出します。コードを ちょっと書けるようになった 2-3ヶ月そこらの ペーペー なのに、なぜ??僕!?! え、、、((((；ﾟДﾟ)))) みたいな....笑

でも、しっかり名指しした理由や、話す場を設けた理由などを冒頭に丁寧に話してくれて,

僕の思っていた 話したいとは 違っていて, 安心した記憶。。。 内容は , これは こう構成した方が...とか, ○○は, こうあるべきで, 責務はしっかり別けるべき 等の話をしてくれたのだが、

正直 当時の僕は 2割も 理解出来ていなかったと思う。(すみません...🙇)

でも、その指導のおかげ様で, 僕はまだまだで, 自身はクソなんだと思えたきっかけでもあります。(今でもよく クソだなって思います。)

大切なのは、自分はクソなんだなと思うこと...☺



5月

既存修正 && 新機能 に追われてた
エンジニアリソースが ほぼ僕だけになる(レビュアーの先輩はいた)
Gashoo以外での 先輩エンジニアと 初めて 共同開発みたいなのをする
コードの書き方や, 癖などの違いに困惑した

学ぶ時間もなくて、やるしかなくて、わからないことがあったら、その都度 調べて.学んで...と行っていた。 やっていって、必ず詰まるから、その都度、どう解決しようか考えていたので、 見積もりとか ろくに取れなかったし、でも, いつまでに できるの?って聞かれるし。。。笑

ココこう出来へん? とか 言われても、「ぶっちゃけ、それ僕もわからん...orz」って感じ(笑) イメージできても、知っている知識でしかできなかったので、ベストプラクティスじゃないし.....って感じ...
でも、やらなあかんし....orz みたいな。



6月

再度, 超基礎部分は、理解したつもりになる
それの影響もあってか少しだけ 心の余裕も生まれる
エンジニアが1人増える

前回の記事で言ったように 自分なりに理解して、実装して、分からないことを調べているうちに(4-5月にそればかりしていたから), 大体のことは できるようになった気でいて、困ることが少なくなって..... 今思うと, 自分の中に 少し余裕が生まれだした時期でもあったかもしれません。 あと、プロダクトの既存の修正箇所も落ち着いてきた影響もあるかもしれない。





見積もりは あくまでも 見積もり



この時期で よくあった会話が いつまでに この機能できる? といった 見積もり の話かなと思う。


今となっては, ⚠ある程度の 工程, 実装見積もりは できるようにはなったのだが, この時期は ほぼできなかったと言っても過言ではない。


技術的な理由(言い訳)も, 知識的な理由(言い訳)も 言おうと思えば 言えるが,

非エンジニアの方にも 理解してもらおうと思えば, 日常生活に置き換えると感覚的に わかりやすいかなと思う。



見積もりは, 感覚的にいうと, 結婚いつできるの?

って聞かれてる感じ... (あくまでも例えです) 笑

結婚するには、軽く考えただけでも、

彼女, 金銭, 指輪, 理解, 承認... が必要で

1つ 1つ エンジニアリング的に当てはめることができる。(と思って書く..w)



例えば, 彼女。

彼女は 結婚という機能を実装するにあたって, 必要不可欠な 付随する機能とか(?w)。

まず、彼女がいなければ, 結婚は できないし, 結婚するには, 彼女が必要だし。って感じで, なにか 大きめの機能を開発にする際は, 他にも 付随してくる機能があったりすることが多々ある。

ここで 言いたいことは, 彼女いつできるの? って聞かれたら、

明日できるよ~ (チャラ男 == スーパーエンジニア) という人もいれば、

ん~, わからない...けど、○○までには~ って いう人もいると思う。

なかには............. ってね。

つまり、

彼女にできそうな人がいる, 彼女の作り方を知っている == 実装したことがある, 知見がある

って感じ。



金銭

結婚には、金銭も大事。

例えば,

結婚(結婚生活)を実現するにあたって, 最低限生活できるくらいは お金が必要。

それを, エンジニアリング的にいうと、開発リソースかな.

彼女はいるし、結婚したいけど、まって 現実的に無理じゃない?ってなるイメージ。

開発リソースは, エンジニア足らんくない とか, あれもこれも 言語も学ばないといけないし、みたいな状況。



指輪は

開発したいものに対しての, 物理的なモノになるかな...(良い例えが浮かばなかったw)

いざ, コードを書く!! ってなっても PCなければ 厳しいし,
iOSで アプリ作りたいってなれば Macやiphoneのデバイス等必要だし。。。みたいな。

(すっごいがんばれば, できなくないところが 指輪かなと思った...w)



で, 次は 理解

理解は, 彼女に対しての理解 って感じ。
つまり、彼女のことを知らないのに 結婚はよくないよね。みたいなこと。

エンジニアリング的に, どういうことかというと、 書いたコードを最低限でも 理解していないのに、んで, どうするの? ということ。

つまり、何度も言っていることになるかもしれませんが、 理解してから、書くことをしっかりした方が良いと思うし、そうしないと よくない結婚生活が待っているということ。



最後に 承認

結婚には 両親の承認であったり、もちろん ご相手さんの承認も必要だと思います。

エンジニアリング的にいうと, コードレビュー的な感じw(複数人開発等に限る)

Approve, 許可(承認)がおりなかったら、マージできないし, リリースもできない(結婚できない)。

だから、承認を貰えるよう, なにを改善すれば尋ねるし(コードレビューや、コメント, コミュニケーション), 頑張るし(コードを修正) ってイメージをもってもらえたら。ｗ



さいごに

とりあえず、見積もりは, あくまでも見積もり ということを
コードを書かない人にも 感覚的に 理解してほしいなぁぁ と思い 書いてみました。w

エンジニアリングの知識のない人に対して
どういう理由で遅れていて, ここがこうなれば、完成でとか 話しても,
まず 相手に エンジニアリングの知識などがなければ ほぼ伝わらないので、

こういう 感じで 噛み砕いてフランクに 話してみることを 僕はしています。

ご飯いつできる? とかだと, いつくらい ってのが わかるように
簡単な 機能などの場合は そのような感覚です。

調味料 切れてもうたっ!!　とかと同様に, 実装中に なにかで つまずくこともありますが...w

伝わりにくかったら, すみません🙇
僕らの会社規模感, スピード感 での 話ばかりなので 諸説あります。




余談

過去のGASHOO Inc. アドベントカレンダーの記事はこちら adventar.org

デザイナーがfishとzshを使ってみた（＾ω＾）ﾍﾟﾛﾍﾟﾛ

f:id:gashoo:20171212013038p:plain

この記事はGASHOO Inc. Advent Calendar 2017 12月12日(火)の投稿です。

こんにちは、株式会社ガシューのCDO白石です🐶

今回は、PCを動かしているシェルと呼ばれるものにも色々な種類があるので、それぞれ使ってみて良かったところをシェアしようという試みです。(僕はMacを使うので、Macを使用する前提です)

シェルって何ぞ？

シェル (英語: shell) はオペレーティングシステム (OS) のユーザーのためにインタフェースを提供するソフトウェアであり、カーネルのサービスへのアクセスを提供する。

「シェル」フリー百科事典 ウィキペディア日本語版

いわゆる黒い画面です。普段、ファイルやフォルダの作成・削除などを行っているfinderなどの視覚ツールをGUIというのに対し、ターミナルなど、コマンドを打ち込んでファイルの操作などを行うものをCUIといいます。どちらにせよ、それらの操作はシェルというものを介して行われます。Macでは、お使いのマシンにログインするとbash🏀 と呼ばれるシェルが走ります。今回はこのbash🏀 をfish🐟 やzsh💻 に変更して、どういう恩恵があるか確認していきます。

黒い画面、怖い((((；ﾟДﾟ))))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ

f:id:gashoo:20171212013213p:plain

白くしてみました。これでもう怖くありませんね😊😊😊

🐟 fishを使ってみる

インストール

Homebrew🍺 が入っていれば、簡単にインストールできます。 Homebrewのインストールはこちら

// brewコマンドで、fishのインストール
$ brew install fish
// バージョンの確認。2017年12月時点では2.6.0
$ fish -v

デフォルトのシェルに設定

// fishがどこにあるか調べる( /usr/local/bin/fish と出るはず)
$ which fish

// /etc/shellsを編集。パスワードを聞かれるのでログインパスワードを入力
$ sudo vi /etc/shells

// ログインシェルをfishにするためにフルパスで入力する。
// 開いたファイルの一番下の行に下記を入力
/usr/local/bin/fish
    
// デフォルトのシェルをfishに変更
$ chsh -s /usr/local/bin/fish

ここでexit ターミナルを再起動！💥

// 現在のログインシェルを表示する
// /usr/local/bin/fish となっていれば成功！
$ echo $SHELL

色々設定したいので、設定管理のフレームワークのoh-my-fishをインストールしてみます。

fishermanというのもあって、こっちのほうがよさそうなんですが、色々あって今回はoh-my-fishを使います。fishermanもまた今度試してみます。

// curlを使ってoh-my-fishのインストール
$ curl -L https://github.com/bpinto/oh-my-fish/raw/master/tools/install.fish | fish

使ってみる😤

f:id:gashoo:20171212013646p:plain

インストール後、こんな感じになりました。カッコイイ！😂
現在のGitブランチをデフォルトで表示してくれているのも良いですね。

まだまだ全ての機能は使えてないんですが、コード補完が優秀な印象です。よく使うコマンドはfishが覚えてくれるので、上記のような長いGitのブランチを行き来する場合もめんどくさくありません。迷ったらTabキーを押せば候補を出してくれるのでとりあえず押しとけば次の行動を空気読んで出してくれます。💨💨

テーマを変更したい場合、コマンドラインで

$ fish_config

と入力すれば、ブラウザで設定ファイルを変更することができます。このへんがデザイナーにも優しそうです。✨

💻 zshを使ってみる

Macの場合、はじめからzshは入ってるみたいなんですが、新しいのを使いたいんで、今回もhomebrew🍺でzshをインストールしてみます。

インストール

// homebrewでzsh, zsh-autosuggestions, zsh-completionsをインストール
$ brew install zsh zsh-autosuggestions zsh-completions
    
// インストールできているかバージョンを確認。2017年12月現在では5.4.2でした。
$ zsh --version
    
// zshの場所の確認(/usr/local/bin/zshと出るはず)
$ which zsh
    
// /etc/shellsを編集。パスワードを聞かれるのでログインパスワードを入力
// 一番下の行に/usr/local/bin/zshを入力
$ sudo vi /etc/shells
    
// シェルをzshに切り替え
$ chsh -s /usr/local/bin/zsh

そして再起動！💥

zshでもプラグインマネージャーをインストールします。
色々なプラグインマネージャーがあるみたいなんですが、zplug🌸がオススメらしいので使ってみます。

$ brew install zplug

で、~/.zshrcに以下を入力します。
3行目では、試しにzplugを使ってzsh-syntax-highlightingをインストールしています。

source ~/.zplug/init.zsh
     
zplug "zsh-users/zsh-syntax-highlighting", defer:2
     
if ! zplug check --verbose; then
    printf "インストールしますか？[y/N]: "
    if read -q; then
        echo; zplug install
    fi
fi
     
zplug load

その後、以下を実行します。

$ source ~/.zshrc

使ってみる😤

f:id:gashoo:20171212013826p:plain

fishに比べるとシンプルですね。(対して何もいれてないので)

時間の都合上、zshの超多機能な恩恵を受けられるほどカスタマイズはできませんでしたが、調べれば調べるほど沢山の情報が出て来るので、これがzshを使う理由になるんじゃないでしょうか😤

ただ、情報が多すぎてどれが自分に対しての最適解なのかという取捨選択が難しいので、そういう意味で玄人向けなのかなと思いました。

総括

それぞれを簡単に触ってみた感じ、それぞれのメリットはこんな感じです😊

🐟 fish

  • コード補完が強力
  • めんどくさい設定が要らない、インストール後すぐに実用的な設定を持っている
  • ビジュアルがかわいい

💻 zsh

  • 超多機能、調べれば便利なTipsが多く存在する
  • プラグインもめちゃくちゃ多い
  • 玄人感出る

デザイナーの皆さんにおすすめしたいのは、
個人的には🐟 fish 🐟ですね🎉

  1. 便利な機能をサクッと使えて、

  2. 設定をインブラウザで変更が可能、

  3. プラグインも視覚的におしゃれなものがある、

などデザイナーには嬉しい機能が多い印象でした。

今回はここまでです。最後まで読んでいただきありがとうございました｡･ﾟ･(ﾉ∀`)･ﾟ･｡
白石のアドベントカレンダー2017、次回は12月19日予定です。🐶

明日は弊社エンジニアしゅんちゃんの「見積もりは、あくまでも見積もり」です。乞うご期待！

余談

白石のTwitterアカウント
興味を持っていただけましたら、どうぞ。

twitter.com

過去の白石のアドベントカレンダー gashoo.hatenablog.com

過去のGASHOO Inc. アドベントカレンダーの記事はこちら adventar.org

僕がエンジニアにならなかったたった１つの理由

こんばんは、しょーきです。

twitter.com

タイトルの通り、以下につらつらと書いていこうと思う。
僕がエンジニアにならなかった理由はいくつかあるが一番はじめに言える事はエンジニアは僕の中で手段だと考えている。

自分が成し遂げたい事に対しての手段にデザイン、エンジニアリング等があったり、建築もその１つでした。僕が大学時代は建築学科を専攻していてその中でCGモデリングなどが一番好きだった。

そこからパースの書き出しやPhotoshopを使ったレタッチ等、Illustratorを用いてプレゼン資料の制作。 僕が達成したい事は「幸せのおすそ分け」ができる世の中にする事である自分が幸せな状態を維持しつつかつ世の中の幸せな瞬間がいかに多く増やせるか。そこがあった。 それまでの過程は全て手段としての認識があった。

だからデザインもUI/UXもプログラミングもCGも多少はかじったりしていた。

ただ僕がかじっていた理由は基本的にそれらを用いて何ができるかを知ることだった。

自分が本当に達成したい事はなんだろうか？

自分でプロダクトを開発する事が目的？違うはずだ。

それらを通して実現したい事はなんだ？

それを追求していった結果、エンジニアの道には進まなかった。





Gashooには素晴らしいエンジニア、デザイナー、ディレクター、マネジメントが集まっている

僕はそこの代表としてしなければいけない事はその手段を用いてチームとして動いてくれるメンバーがいかに活動しやすい環境作りができるかを念頭に常に動いている。

僕の大学時代の友人でありガシューのチームメイトでもある舜ちゃんというメンバーがいる。 彼は僕のやりたい事、実現したい世界に対して、共感を持ってくれてその上でエンジニアという道を選択して今も開発にコミットしてくれている。 僕は彼がいなかったら自分でエンジニア業務を担わないといけなかっただろう。



僕の大学時代の先輩でもあり、ガシューのチームメイトでもある白石くんというメンバーがいる。彼も古川と同じで僕には持っていない、突出したデザイン知識、技術を持っている。 更にはエンジニアリングの知識も備えている。彼が一緒に仕事をしていなかったら自分でデザインを更に深く学んでプロダクトを開発しなければならなかっただろう。



他にもげんやさん、もりさん、たくちゃん、ソルト、ゆーた、等様々なメンバーがそれぞれのプロフェッショナル領域で活躍してくれていて本当にお世話になっている。


僕はプロフェッショナルにはなれないがそれぞれの領域のプロがいるおかげで自分の達成したい世界観を着々と進める事ができている。


ここで言いたい事はチームで動いていく上で必要な事はそのチームがいかに機能してメンバーが最大のパフォーマンスを出せる環境を作れるかどうかを考える上で参考にしてほしいという事だ。





大学時代も含めて僕は様々な人達に恵まれ、自分のやりたい事かつ、それらを求めている人たちを探す事をひたむきに続けてきた。 それはお互いにとってwin-winな関係性を作るという事が周りにまわって自分の幸せ、他者の幸せになってかえってきて、ついには世の中を幸せに包み込んでくれると信じているからである。


この事を言い続けていた時に僕の友人から「幸せのおすそ分け」という言葉をいただき、僕は幸せのおすそ分けが出来る世の中にしたいと発信するようになった。


タイトルに関しては正直、あまり関係がない。 エンジニアという文字を使ったのも特に意味はない。 そこの部分がデザイナー、でもディレクターでも営業でもなんでもいい。 何者かになりたいのではなく、自分が考えている世界観や目的を達成するためにはなにかにならなければいけないわけではない。
僕自身はそうやってずっと生きてきた。そしてこれからもそうやって生きていくだろう。









全ては手段である。

そしてその手段が目的化していると本当に自分のやりたい事は見えてこない。

ブラウザ越しにお花見しよう！

GASHOO Inc. Advent Calendar 2017土曜日担当、9日目を飾ります、t-kusakabeです。 先日ハッカソンにて、HanamiとWebRCTを触る機会があったのでその時したことをまとめて見ようと思います。 ということでWebRTCを使ってお花見です。

Hanami

以前のAdvent Calendarでも簡単に紹介したのですが、HanamiはRubyのFWです。 GashooでHanamiを採用したのもこの時に触ったのがきっかけでした。

WebRTC

WevRTCとはブラウザ間でビデオや音声などのデータをやりとりできるようにしてくれるくんです。 「appear.in」などはWebRTCを使って事例としてよく取り上げられているような気がします。

実際に動かして見る

※本来であればFWなどを使う必要はないのですが、この時僕がただHanamiを使いたかったのとHanamiを使ってWebRTCを動作させるのに若干詰まったところがあったためあえてHanamiを使っています。 今回作るのはビデオ通話です。

hanami new

まずはスケルトンを作成します。

hanami new プロジェクト名(今回はhanami_web_rtcとしました)

この状態で

bundle exec hanami server

と、するとサーバーが起動します。 localhost:2300 にアクセスすると、Hanamiのデフォルトページが確認できると思います。

topページの用意

ひとまずtopページだけ作成しておきます。 HanamiはほとんどのコマンドがRoRと類似しているのでRoR経験者はわかりやすいかもです。

bundle exec hanami g action web tops#index

これでcontroller以下にindex.rbが生成されます。

apps/web/controllers
└── tops
    └── index.rb

Hanamiではaction毎にclassが存在するのでfat controllerになりにくい感があると思います。 これで localhost:2300/tops にアクセスすることができるようになると思います。

template

actionを作成することができたので、次はtemplateを作ります。 Hanamiはtemplate以下にerbを書いていきます。

apps/web/templates
├── application.html.erb
└── tops
    └── index.html.erb

index.html.erbにvideoタグを設置していきます。

<div class="pure-g">
  <!-- video area -->
  <div class="pure-u-2-3" id="video-container">
    <video id="their-video" autoplay></video>
    <video id="my-video" muted="true" autoplay></video>

    <video id="video" autoplay muted></video>
    <video id="others-video" autoplay></video>
  </div>

  <!-- steps -->
  <div class="pure-u-1-3">
    <h2>skyway video chat</h2>

    <p>your id: <span id="my-id">...</span></p>
    <p>share this id with others so they can call you.</p>
    <h3>make a call</h3>
    <form id="make-call" class="pure-form">
      <input type="text" placeholder="call user id..." id="callto-id">
      <button href="#" class="pure-button pure-button-success" type="submit">call</button>
    </form>
    <form id="end-call" class="pure-form">
      <p>currently in call with <span id="their-id">...</span></p>
      <button href="#" class="pure-button pure-button-success" type="submit">end call</button
    </form>
  </div>
</div>

PeerJS

今回はWebRTCを使うのにPeerJSを使用します。 普通にWebRTCを使うだけならPeerJSと他のビルドインサーバーがあれば実装できるのですが、今回はHanamiを使いますw

こちらのページ より、まずはAPIのkeyを生成します。 Sign Upして、鍵を発行してください。

PeerJSを使ってビデオ通話するためのscriptを書く。

PeerJSを使ってビデオ通話するためのscriptを書いていきます。 上記で作成したAPIkeyも用意しておいてください。

apps/web/assets/javascripts
└── script.js

上記のように新しくfileを作ります。

console.log('start webRTC!')

navigator.getUserMedia = navigator.getUserMedia || navigator.webkitGetUserMedia || navigator.mozGetUserMedia;

var peer = new Peer({key: 'PeerJSのAPIkey'});
 
peer.on('open', function(){
    console.log('connect')
    $('#my-id').text(peer.id);
});


var myStream;
$(function(){
  navigator.getUserMedia({audio: true, video: true}, function(stream){
    myStream = stream;
    $('#video').prop('src', URL.createObjectURL(stream));
  }, function(){});
});

function callTo(peerId){
  var call = peer.call(peerId, myStream)

  call.on('stream', function(othersStream){
    $('#others-video').prop('src', URL.createObjectURL(othersStream))
  })
}

peer.on('call', function(call){
  call.answer(myStream);
  call.on('stream', function(othersStream){
    $('#others-video').prop('src', URL.createObjectURL(othersStream));
  });
});

APIkeyを適切に設定してください。

HanamiにPeerJSを読み込ませる

まずは上記で作成したscript.jsを読み込ませます。

apps/web/templates
├── application.html.erb
└── tops
    └── index.html.erb

template以下のapplication.html.erbにscriptを追加します。

<!DOCTYPE html>
<html>
  <head>
    <title>Web</title>
    <%= favicon %>
  </head>
  <body>
    <%= yield %>
    <%= javascript src="script.js" %>
  </body>
</html>

script.jsではPeerJSを使用しているためPeerJSを読み込ませます。 今回はCDNですることにします。 が、ここに一番手間取りました。。。

<html>
  <head>
    <title>Web</title>
    <%= favicon %>
  </head>
  <body>
    <%= yield %>
    <%= javascript src="https://code.jquery.com/jquery-3.2.1.min.js" %>
    <%= javascript src="https://cdn.webrtc.ecl.ntt.com/skyway-latest.js" %>
    <%= javascript src="http://cdn.peerjs.com/0.3/peer.min.js" %>
    <%= javascript src="script.js" %>
  </body>
</html>

と、すれば動作すると思ったのですが、なぜかCDNが読み込まれませんでした。。。 どうやらセキュリティ的にCDNを使うには一手間いるようです。 今回は以下の方法をとりました。(他に適切な方法があればご教授ください。。。)

apps/web/application.rbに以下を追記します。

security.content_security_policy "https://skyway.io/dist/0.3/peer.js;"
security.content_security_policy "https://skyway.io/dist/multiparty.min.js;"
security.content_security_policy "https://cdn.peerjs.com/0.3/peer.min.js;"

どうやら使用するものをあらかじめ明示しておく必要があるみたいです。 ひとまずこの方法で動作することが確認できました。

これで localhost:2300/tops にアクセスします。

完成！

どうでしょうか？ ひとまずこれでビデオ機能が実装できました！ IDで繋げることもできるのでいろいろ試してみてください。

まとめ

今回はビデオ機能だけでしたがチャット等も実装することができるので是非是非試してみてください！

今回作ったもの