MAとチビキノコ
〜ハッカソンに参加するようになってこんなものも作れるようになった！〜
この記事について
この記事は MashupAwards Advend Calender 2017 の 9日目の記事です。
qiita.com
はじめに
ちびキノコとは
ちび × マッシュ＆ルーム
ちび
「ちび」とは、ネコの名前であり、
私のハンドルネームやアカウントです。
※ chibi はほとんど取れないので chibi929 が主です。
※ chibi929 も取れない場合があるんですけどね。。。
マッシュ＆ルーム
http://mashandroom.org
想像せよ！頭にキノコが生えるまで
一億総キノコ
つまり
キノコに耳と手とヒゲを生やしてネコ化です。
MA とちびキノコ
初参戦は 2016 年の MIZUHO.HACK
この時は、
ペッパー触れない！サーバーサイド触れない！クラウド触れない！IoTできない！
何も出来ません。Android アプリがメインです！
そんな感じです。
その後
- NTTドコモ×TBS TV HACK DAY
- 特大ペッパソン2016
- ペッパソン2017東の陣
と参加し、
気付けば、初めて触ったクラウドは AWS ではなく Bluemix という。
Watson 君楽しい！
そして、こんなものも作れるようになった！
Youtube
www.youtube.com
www.youtube.com
Qiita
ちなみにドラゴンボールシリーズ
負債と共には生きたくない
これに参加しました！！
すごく勉強になる良いイベントでした。
執筆が遅くなりましたが、引っ越し後まだインターネットが繋がっていないんです。
という言い訳です。
負債とは
- 読むのが辛い/時間がかかる
- 修正するのが辛い/危ない
過去の自分を含めて全てを疑え
こんな時は負債を背負っているはず
- そんな複雑なわけがない
- 1分以上読んでもわからないわけがない
- 一連の処理で行ったり来たり繰り替えすわけがない
負債返済の下準備のタイミング
- 調査やリファクタをしたとき
- 変更を入れるとき
負債の種類を見極める
- 負債の払い戻し: 返済するべき負債
- 負債の転換: ベストではないけどベターに返済
- 利息のみ支払う: コードと共に生きる
なぜ負債を返済する必要があるのか、返済することで何が変わるのか
まとめ
負債があるのは何故か??
- 時間的な制約、実装者の技術力の限界。など色々ある。
- ポジティブに考えると「自分たちの技術力が高いので負債と感じる」
- 「負債vs人」ではなく「負債vsチーム」とする
負債は少しずつ日々返済していくもの
- 貯まってしまった負債は現実世界同様、すぐに返すことはできない。
- 負債を返済する時間がないなら不吉な匂いのするコードにコメントを入れる。
- コメントを入れる仲間(連帯保証人)を増やす
文化を作ろう
- 「低品質のコードを書くのが悪い」のではなく「低品質のコードをマージする文化が悪い」
- 技術的負債を混入しない環境・文化作りが大事。
- 自分がメンテできないコードは Approve するな！
実装よりもリファクタが大変
- 技術的負債を返済するときは、とにかく幅広い知識が必要。
- 遅くなれば遅くなるほど、依存関係が増えるため依存モジュールへの知識も必要であり、
- 後でリファクタしようとすると死ぬことになる。
Qiitaのお話を聞いてキータ
これに参加させていただきました！
なんとも今更感な記事。。。 忙しくて家でPC開く時間が全然なかったんです。。。
貴重なQiita誕生秘話！！
当初は、3名ほどの開発メンバーで、 時間も合わないのでオンラインでアイデア出し、 そして、合宿のような形で原型作り、 そして、またオンラインで作業。という形だったそうだ。
しかも、途中でサービスの方向性を変更しているとのこと。 Q/Aサービスから情報共有サービスへ。
あの使いやすいMarkdown形式も最初から導入されていたわけではなく、 リリース後にユーザーからの要望でプレーンテキストからMarkdown形式へ変更されたとのこと。 確かにプレーンテキストではとても辛い・・・
投稿してもらわないと始まらない！
Qiitaは情報共有サービスとして、記事を投稿してもらわないと始まらない。 そこで、Kobitoなどの投稿のための機能作りを開始。 プロトタイプを試してもらって、フィードバックを貰う。 リリース後のUI変更はあまりできないので、UIの検討・テストは入念に行う。
UIの大規模変更は、大抵の場合は文句しか言われない。だから検討・テストは入念に。 慣れてるものから変わってしまえば最初は使いづらいからだろう・・・。
個人的には「いいね」機能が出来たときに若干使いづらさを覚えた。 今まであった「ストック」機能が小さく残ったので、ストックが逆に使いづらくなってしまった。 とはいえ、人によっては元々Pocket等に入れていてストックをしてない人も多いと思う。
ガイドライン
色々あったガイドライン。 これは、開発者の思想や想いが伝わりきっていなかったとのこと。 「プログラミング」という言葉の定義が曖昧なのも問題があるとは思うが・・・
実際、当初ガイドラインに記載がなかっただけで、 「プログラミング知識を共有しよう。」などQiitaには至るところに書いてある。 思想としてはプログラミングの記事を書いて欲しかったそうな。
個人的にはいわゆるプログラミングの記事だけでなくて、 IT技術系の記事ならなんでも良いと思うんですけどね・・・。
「いいね」と「編集リクエスト」
恐らくこれには開発者の想いが詰まっている。 「ストック」はどちらかというと「後で見る」。後で見るためのストックではなくて、 とにかく良い記事に対して「いいね」を気軽に付けて記事を評価したい。 そんなところから「いいね」が誕生。
:+1: ができれば :-1: は？という話になる。
しかし、Qiitaには「編集リクエスト」という機能が存在する。
つまり、良くなかった記事が「投稿者の編集」もしくは「利用者の編集リクエスト」によって良い記事に変わるかもしれない。
だから :-1: は用意していないのだ。
ブログの記事は、執筆者が責任を持って内容を最新化しない限りは古いままだが、 Qiitaは編集リクエストによって、古い記事を新しいものへと変えることができる。 記事をみんなで育てていくのがQiita。
まとめ
yaotti さん、takoratta さん のお話を聞けてよかったです。 中の人の想いが伝わる良い会でした。 開発者の想いを利用者に伝えるのは大変ですね・・・。
私もQiitaを活用させていただいておりますが、最近も編集リクエストをいただきました。 「こっちのタグのほうがフォロー数多いですよ！」という編集リクエストでしたが、 どんなに小さくても編集リクエストをもらえるととても嬉しいですね。 むしろ小さい方がマージしやすくて良いかも！と思っています。
自分でも何回か編集リクエストを出したことがありますが、 ただ、編集リクエストをいただいた方へはマージという形でしかお礼ができないのが若干寂しく感じてます。 もうちょっとだけ編集リクエストを活発的に活用して行こうと思います！
