さむブログ

学生エンジニアのポートフォリオ

安心しろ、峰打ちだ(技術書典爆死)

先日10月8日に池袋サンシャインシティで技術書典5が開催されました。
サークル参加、一般参加された皆さんお疲れ様でした。

タイトルにある通りですが、サークル参加して爆死しました。 結果から言うと200部刷って50部弱しか売れていません。ダンボールが一つも空にならなかったサークル代表です。
買ってくれた皆さん本当にありがとうございました。皆さんのお陰でまだ生きていけます!

さて、初参加爆死を華麗に決めていった私ですが、どのように爆死したのかを記していこうと思います。
「私も爆死しました〜」って方がいればこれを見て安心してください。

被チェック数の2倍は売れるから!安心しろ(嘘)

f:id:sam8:20181011223341p:plain

私のサークルの被チェック数は最終的には120まで伸びていました。
被チェック数の2倍は売れる神話に基づくと240部売れて完売。やったー!となるはずなのに爆死、これは如何に?

まず、サークルチェック数はブースに来ようとしてくれている人の数です。安心してはいけません。
確かにブースに120人くらいは来てくれてた気がします。それだけ、試し読みからの直帰率が高くて凹みましたが。

神は死んだ!

ここはどこ?私は誰?

あれIonicとDjangoの本を出すはずなのになぜ私はReact島にいるんだ?
あ、そっか申し込みの時はReactJSに関して書くつもりでジャンルをReactにしてたんだった。

ってことがあり、
Django島でもIonic島でもない場所にいるお陰で、その界隈の人たちとあまりお話ができませんでした。
技術書典一番の楽しみを棒に振っていくスタイル。

会場の端っこは寒いぞ

冷房が効きすぎて寒かったって言う話ではありません。
私は【う-08】に配置されたのですが、そこは前が広場であまり賑やかにならない位置でした。
カ行のブースをみると人がひしめき合って賑やかなのに、こっちはあっけらかんとして静かでした。 私のサークルの前を通っている人たちは、既に技術書ハントを大体終えてあとはブラブラするだけって人が多かった気がします。
会場の真ん中はアド、端っこはディスアド。

f:id:sam8:20181011225047p:plain

隣人氏大人気サークルにて

私のブースの隣には「りあクト!」の@oukayuka さんと
ネコミミでもわかるこれからのWebサイト構築」の@polyxxさんがいました。

@oukayukaさんは、上下巻合わせて600部ほど売れてたらしくimpressから商業化の声がかかっていました。
@polyxxさんは僕が初めて行った技術書典3から参加しているフロントエンドの人で、表紙のデザインが可愛いんですよね。

技術書典はコミケとは違い列形成はうまくできていません。
結果的に人気サークルの隣になると言うことは、列がはみ出て自分のサークルの前を埋めてしまうということになります。
これは誰が悪いと言うわけでは無いのですが、終始@oukayukaさんの列が溢れがちだったので私のサークルは隠れがち。
人気サークルの特権なのかもしれませんね。

コミュ障発動!

今回の技術書典5に出たことで、いろんな人との繋がりを得ることができました。
日本で唯一Ionicの本を出版している榊原(@rdlabo)さん。twitterでの宣伝本当にありがとうございました。
また、今回もう一つのIonic本を出していたサークルのシン(@Sinack_jp)さん。これからもよろしくお願いします。

他にもお隣のブースの人たちや他の興味のあるブースの人たちと話せば良かったのですが、コミュ障を発動してしまいました。
すごく勿体なかったと後悔しているので、修行して出直して来ます。

反省点いきます

技術書典の準備を舐めると痛い目に遭う。

これに尽きます。

私のサークルは、全ての準備が直前でした。執筆も実質入稿前の1週間で終わらせ、ブースのセッティングも家で試さずに行きました。
結果的に、ページ数の配分ミスって書きたいこと書けない
名刺を当日忘れる
デザインに時間を書けず確認していない

と言う舐めたことをしてしました。
次の技術書典はもっと強くなって帰ってきます。
と言うより、既に次の技術書典の構想を考え始めています。
成長していくスタイル。

まとめ

爆死という結果に終わりましたが、社会経験の無い私が自分の書いた本を売るという経験をできたことはすごい大きな財産になりました。
もっといろんな人とお話すれば良かったという後悔はありますが、まだ精進が足りないということで頑張ります。
次回作はしっかりとアプリを作るお話を書いて、100部以上売ります(宣言)。
リサーチとデザインしっかりしますね。

技術書典5で出す本の紹介

この度2018/10/08に池袋サンシャインシティで開催される「技術書典5」にサークルとして参加できることになりました。

サークル名は【黒塗りのビール】で、大学の友人と共同で1冊作っています。
内容は

の2つに関するものです。
執筆者は2人とも、執筆活動は初めてなのでググりながら奮闘中です。 さて、少しだけ本の中身について触れておこうと思います。

第1部 : Ionic

この部ではIonic3系の本当に優しい説明をしています。
page, component, directive, pipeといったIonicを構成するパーツの、「説明」「作り方」「独自パーツの作り方」を順に説明しています。
IonicはAngularベースなのでAngularの多くの資産を使えるのはいいのですが、実例やIonic独自の日本語ドキュメントが少なく開発者は初めのうちは電子の海をさまようことになるでしょう。
Ionicに関する本もほとんど出版されていないですし.....
Ionicは公式ドキュメント(英語)にほとんど全てのことは書いてありますが、Angularを知っているという前提なので初心者にはきついです。
僕はAngularを知らずに、いきなりIonicに飛び込んでしまいました。
ググってググってググりまくって知識を溜めて、それを本にしました。
これからIonic始めたいという方は、ぜひIonicのリファレンスとして使ってください!

第2部 : Django

第2部を担当しますzushiです。
この部ではPythonのWeb開発フレームワークとして有名なDjangoについて書いていきます。
今回の執筆にあたって、ちょうど勉強を始めていたDjangoについて書く事に決めました。Pythonほとんど触ったことないよ、という方でも理解できるようにすごく丁寧に書いています。
日本ではRuby on Railsが人気で少し陰に隠れているDjango、そのせいか参考書は厚くて高いものか、何かのついでに書かれているものばかり。技術書典で手にとってもらった人に少しでも興味を持って頂いて、Djangoの世界に飛び込んでもらえたらと思います。
環境構築から、Djangoの特徴的なアーキテクチャの説明を交えつつ、基本的なWebページの表示が出来る用に説明していきます。
初心者向けの内容なので既に知っている方には物足りないかもしれませんが、読んでいただいて「ここはこうだよ。」とダメだししていただけたら嬉しいです。
少しでも興味を持っている方は是非この機会にお手にとっていただき、Django開発者の1歩を踏み出してください!

1ヶ月でバイトをやめた話

3月後半から4月の約1ヶ月あるIT系の会社でアルバイトをしていました。
ただ、途中でいろいろ察して辞めました。
その時オフィスで何が起こっていたか、それを時系列順で書いていこうと思います。 まだ、現場でそこまで働いたことがないので甘ったれた行動のように映るかもしれないので先に謝っておきます。

アルバイト入社前(面接編)

Web関連の仕事ができる企業をWantedlyなどを利用して検索。
見学に行ってみないとわからないことも多いと思ってとりあえずある会社に行ってみることに。
その会社はゲーム、Webなど幅広くやってる会社と書いてあったので、いろいろなことを学べると思っていました。

いざスキルシートと履歴書を持ってオフィスに行くと、ホテルの一室のような場所で数人が作業しているオフィスに通されました。
面接で聞かれたことは「Unityできる?」くらいですぐ明日からでも来て欲しいと言われました。
その時は速採用がうれしくて見逃してましたが、社員さんは目を合わせてくれず、Web系の仕事がしたいのにUnityのことしか聞かれなかったことをよく考えておくべきでした。

アルバイト入社後(1日目編)

アルバイト入社1日目に作業環境を教えてもらいました。

  • OS : mac
  • バージョン管理 : SourceTree + gitlab
  • ツール : Unity2017
  • 連絡 : chatwork + slack

また、そこでなぜかWeb系の仕事ができると思っていたのにゲームの方の仕事をするよう言われました。
現在取り組んでいるゲームの案件の進捗が芳しくないかららしいです。
その案件の内容は、既に他社がリリースしているアプリのアップデート+改修作業でした。
1日目はどんなアプリなのかの簡単な説明と環境構築で終わりました。
まだこの時は綿密な計画の元タスク表通りに作業が進んでいくだろう、という会社への幻想を抱いて安心していました。

作業開始(2日目編)

2日目は作業内容の説明を受ける予定でした。 僕が少なくとも欲しかったのは

  • ゲーム画面の遷移図
  • チームのコーディング規約
  • クラスごとの役割が簡単にでも説明されているクラス図orコメント
  • gitlabをチームでどう使っているのか
  • 作業内容のドキュメント
  • etc

【ゲーム画面の遷移図】
改修前の遷移図はあるものの、回収後の目標の遷移図は存在せず先輩も把握していない模様。
先輩曰く、「依頼元が作ってないんだからこっちは悪くないって言える」
いや、わかんなかったら聞いて作るなりしろよ( `ー´)ノ
これが後に「依頼元との認識の齟齬」を作り出しました。

【チームのコーディング規約】
ありませんでした( ;∀;)
Camel case も Pascal caseもバラバラ。
ラムダ式がたくさん使われているのに、チームのほとんどの人が理解できていない。
助けて…

【クラスごとの役割が簡単にでも説明されているクラス図orコメント】
まず、コメントはほとんどありませんでした。
また、機能ごとにパッケージ化等全くされておらず各クラス間が相互に参照しあっていた。
結果として、あるクラスの一部を変えると他の数十個の関係あるのか無いのか分からないクラスがエラー。
ほぼ全ての変数がpublicで宣言されているのを見たときはゾッとしました。
あっ、もちろんクラス図等の説明は全くありませんでした。

【gitlabをチームでどう使っているのか】
プルリクを出す際にどういった情報を記述すればいいか。
TODOやFIXMEやドキュメンテーションコメントでの説明でいいのか。
それに対する答えは
先輩「とりあえずできたらマージしといて」
僕「えっ、そうしたらgitをチームで使ってる意味あんまり無くないですか」
先輩「いいから、いい感じにやっといて」
僕「はい……(涙)」

【作業内容のドキュメント】
もうお察しだと思いますが、「あれをいい感じに直しといて」「あの機能をいい感じに追加しておいて」しか言われません。
仕様書のようなものは作らないのですか、と言うと笑いながら「今どきの開発でそんなの作るところないよww」
いやいや、作るでしょ。適当じゃねーか!

作業開始(3日目~1週間編)

2日目にいろいろ絶望しましたが、3日目になるともう作業が割り振られました。
先輩「このバグを直して」
僕「現状どの部分に問題が出ているかわかりますか?」
先輩「分からないけど、うまく動かないから直して」
僕「この問題が起きてるデータはどこにパッケージングされていますか?」
先輩「とりあえず、ブレークポイントはって試してみて」
僕「はい……(涙)」

そこからの僕はひたすらアクティビティ図を書きまくりました。
自分の作業内容とは関係ないところまで含めて、ゲーム全体の流れを掴むためにほぼすべてのコードを読んで。
1週間進捗はほとんど上げられませんでしたが、最初に僕が欲しかった情報はほぼすべて集めることができました。
その間に先輩が状況を悪化させているとは知らずに…。

作業中盤(2週間目~3週間目編)

ここにきて僕も全体の流れを理解できたこともあって進捗をあげられるようになってきました。
久しぶりにdevelopブランチをプルしてみたら大変なことになっていました。
なんと、プルリクが一度もされずに先輩たちは皆自分のブランチをdevelopにマージしまくっていたのです。
なんで皆作業しているのに全く進捗(プルリク)出さないんだろうと思っていたら…。
案の上、どのコミットに遡っていってもエラー残っているし、大量にグローバル変数や存在意義のないクラスが増えていました。
ある先輩にコードやgitの使い方のことで軽くそのことを指摘すると、
「俺は本来プランナーだからそういうのは向いてないんだよね。これがこの会社のやり方だよ」
と言われ察しました。
ここからは自分の進捗だけ挙げて、それにかかわらない部分については無視しようと決めました。

作業終盤(3週間目~最終日まで編)

ぼくは既に自分の中でゲームの流れやクラスの役割を確認していたので、かなりの進捗をあげられるようになっていました。
この時にはデバッグリストを依頼元が作成してそれを消化する段階に入っていました。
先輩たちは自分で作った大量のフラグや不吉なにおいのする関数や変数に悩まされて作業が止まったり、それによる体調不良で欠席したりしていました。
一方僕は1日当たり先輩たちの2~3倍のタスクを消化していました。
そして僕が担当できるタスクが無くなって先輩の作業を手伝おうとしたとき、それを嫌がった先輩からすごいことを言われました。

private int Method() {
    // メソッドの内容
}

private int Method()
{
    // メソッドの内容
}

に変えろと言われたのです。今更。
彼曰く、「君の書き方は好きじゃない」そうです。
これには僕も頭が痛くなってきたので、とうとう社長に個人チャットで辞める意思を伝えました。

最終日(社長と面談編)

社長1対1で僕が思っていたことを話しました。上に書いたこと以外にもたくさん。
改善するように体制を変えてみるとは言っていましたが、その後リリースされたゲームの評価を見る限り改善はされていないようです。
バグが残ったまま、起動すらできず、かなり重くなったゲームがリリースされていました。
今後どうなるんでしょうね。

振り返ってみて

僕が1ヶ月働いた会社はまずい点がいくつもありました。

  • 働いた時間を自己申告できる(正社員、アルバイト問わず)
  • ずっと仕事の文句を言っている
  • いない人の文句を言って相対的に自己の評価を上げようとしてる
  • よく休む or 遅刻する人が多い
  • 人と話すのが苦手だから話さないorごまかす人が多い
  • オフィス内のメンバーの交流を図らない
  • 優先順位のつけ方が間違っている
  • オフィスが途中から臭くなった
  • 試しもせずにダメだと思い込む
  • 人の話を聞かない

逆に学んだことは

  • リーダブルコーディングの重要性
  • 人間関係が仕事に与える効果
  • リーダーの役割
  • 作業環境の充実度の仕事への影響

良くも悪くも、いろいろ経験できた密度の濃い1ヶ月でした(心労)

React x AtomicDesignでのフォルダ構成

バイト先でもReactでの案件が多いから学習するぞいっ(-ω-)/
って時に壁にぶち当たった。

フォルダ構成ってどうすればいいの?

調べてみると、'AtomicDesig' というデザインの考え方がありそれに従ったフォルダ構成があるらしい。

AtomicDesignとは?

すごくわかりやすくまとめてくださってたので参照↓

簡単に言うと
「ボタン」や「入力エリア」、「見出し」などの
これ以上分割できない、それ単体では機能しないもの(ここ重要)が
Atoms(原子)

Atomを組み合わせてできる、「検索ボックス」などが
Molecules(分子)

AtomとMoleculeを組み合わせてできる、「ヘッダー」や「フッダー」が
Organisms(生体)

Organismsを組み合わせてできる、「コンテンツが流し込まれる前のページ」が
Templates(テンプレート)

Templatesにコンテンツが流し込まれた、いわゆるTemplatesのインスタンス
Pages(ページ)

なるほど、わかりやすい!

フォルダ構成の例

標準

root  
└ src  
  ├ index.js  
  ├ container  
  │ ├ header.js  
  │ └ footer.js  
  └ presentational  
    ├ atoms  
    │ ├ button.js  
    │ └ checkbox.js  
    └ molecules  
      ├ serchbox.js  
      └ sharebutton.js  

containerがラッパー、presentationalが表示部品という構成が分かりやすいですね( ..)φメモメモ

複数ページの場合

root
└ src
  ├ index.js
  ├ container
  │ ├ organisms
  │ │ ├ header.js
  │ │ └ footer.js
  │ └ templates
  │   ├ top.js
  │   └ 404.js
  └ presentational
    ├ atoms
    │ ├ button.js
    │ └ checkbox.js
    └ molecules
      ├ serchbox.js
      └ sharebutton.js

templatesにページのひな型が入っていて、どのorganismsの組み合わせをエントリーポイントに渡すか?
という構造が分かりやすいですね( ..)φメモメモ

より複雑なアプリケーションの場合

root
└ src
  ├ index.js
  ├ components
  │ ├ container
  │ │ ├ organisms
  │ │ │ ├ header.js
  │ │ │ └ footer.js
  │ │ └ templates
  │ │   ├ top.js
  │ │   └ 404.js
  │ └ presentational
  │   ├ atoms
  │   │ ├ button.js
  │   │ └ checkbox.js
  │   └ molecules
  │     ├ serchbox.js
  │     └ sharebutton.js
  └ modules
    ├ benri.js
    └ methods.js

UIの描画とは別に独立した処理(API接続)などがある場合moduleとして分けることで、 使う際にインポートして使う方法があるのかぁ( ..)φメモメモ

AWS(EC2)にSSHでアクセスできない

そろそろAWSに挑戦するぞー。ということでチュートリアルに沿って進めてみた。

  • アカウント作成
  • インスタンス作成
  • セキュリティグループ設定 までは問題なく進んだ。

でも、「SSHで接続」がどうしてもできない( ;∀;)

2日調べて分かった原因と解決法を書いていく。

原因

大学のプロキシサーバではデフォルトのSSH通信用のポート22は使えないようになってました(汗)

それどころか外に対する接続はほぼすべてカットされてました(汗)

とりあえず、22番・80番・443番試してみたけどだめだった。

セキュリティ厳しすぎませんかねぇ

解決法

  • 大学とは関係ない通信網を使う(大学内でのデフォルトのイーサネットを使わない)
  • 一度家からインスタンスにアクセスして接続のポート番号とセキュリティグループを変更する(/etc/ssh/sshd_config)

まとめ

  • サーバにアクセスする時は、その場で使う通信が指定のポートを開放しているか確認する
  • 22, 80, 443番ポート試してダメだったら組織内の通信で許可されていない可能性大(大学はダメっぽい)
  • Windowsの人は認証にPuttyよりTeratermを使ったほうが楽

「積んでクレ」プライバシーポリシー

Takahiro Wakano
Engineer in Tokyo

ゲーム「積んでクレ」について

個人情報の利用目的

当ゲームは、ご利用者様からご提供いただきました個人情報を、ご利用者様からの各種お問い合わせに対する回答・連絡に必要な範囲でのみ利用いたします。 上記目的の範囲を超えてご利用者様の個人情報を利用する必要が生じた場合は、ご利用者様にその目的を連絡いたします。新たな目的にご同意頂けない場合には、利用いたしません。

個人情報の第三者への開示

当ゲームでは、個人情報は適切に管理し、以下に該当する場合を除いて第三者に開示することはありません。

  • 本人のご了解がある場合

  • 法令等への協力のため、開示が必要となる場合

個人情報の開示、訂正、追加、削除、利用停止

ご本人からの個人データの開示、訂正、追加、削除、利用停止のご希望の場合には、ご本人であることを確認させていただいた上、速やかに対応させていただきます。

免責事項

当ゲームからリンクやバナーなどによって他のサイトに移動された場合、移動先サイトで提供される情報、サービス等について一切の責任を負いません。

当ゲームのコンテンツ・情報につきまして、可能な限り正確な情報を掲載するよう努めておりますが、誤情報が入り込んだり、情報が古くなっていることもございます。

当ゲームに掲載された内容によって生じた損害等の一切の責任を負いかねますのでご了承ください。

プライバシーポリシーの変更について

当ゲームは、個人情報に関して適用される日本の法令を遵守するとともに、本ポリシーの内容を適宜見直しその改善に努めます。

修正された最新のプライバシーポリシーは常に本ページにて開示されます。

EdgeCollider2DとPolygonColldier2D

Unityで2Dゲームの当たり判定を取るときに、いつもPolygonColldier2D使ってたから気づかなかったけど、

EdgeCollider2D同士は衝突しない

answers.unity3d.com

PolygonColldier2D同士はちゃんと衝突するから安心。