けけずんセルフハッキング

エンジニアっぽい雰囲気を醸しだしているかのようなブログです!

「Startup Weekend Okinawa Vol.7」に参加して

先日、Startup Weekend Okinawa Vol.7に参加してきました。 以下はSW概要から当日までの様子の箇条書き。

Startup Weekendについて

概要

  • あたらしいなにかをつくりだす「スタートアップ体験イベント」
  • アイディアをカタチにするための方法論を学び、スタートアップをリアルに経験することができる

流れ

  • 1日目の夜、みんながアイディアを発表するピッチから始まる
  • ハスラーハッカー・デザイナーでチームを組み、日曜午後までにUXに沿った必要最小限のビジネスモデル(MVP)を一気に作り上げる

役割

  • ハスラー:マネジメントと顧客開発
  • ハッカー:機能の開発
  • デザイナー:使いやすいデザイン

SW1日目

懇親会とファシリテータ挨拶

  • ご飯を食べながら色々な人と話す
    • 美味しく頂きました
  • ファシリテータのTakutoさんによる挨拶
  • トークが上手い、参考にする
    • 話す速度
    • 話す内容、笑いを取る所
    • 間の取り方
    • 目線など

1分ピッチと話し合い・投票

  • 参加者各自がそれぞれ自分のアイディアを発表
    • 面白そうなアイディアがいくつもあった
    • 沖縄の問題について真面目に考えてるんだなと感心させられるのもあった
  • 発表されたアイディアを多数決で数個に絞る
    • 残念ながら私のアイディアはボツに(一票は入ってたはず...!)
      • 話を聞きに来てくれた方々、ありがとう(´;ω;`)

チーム作り

  • 1分ピッチで発表して且つ投票で生き残ったアイディアごとにチーム分け
  • 最初は「物忘れ防止 + IoT」なチームに参加しようと思っていたが、急遽変更
  • 「自分の所有する服を他人がコーディネイト」なチーム「Pocket Stylist」に参加
    • 圧倒的女子率
    • 女の子にお願いされたら断れませんよ
    • ハッカー視点で見て実装するのが面白そうだったから、というのも参加した理由の一つ(後付ではないよ!)
    • 役割別内訳(合計8名)

話し合いと1日目の終わり

  • チームに分かれての話し合い
  • 自己紹介、得意分野、今回の役割など決定
  • アイディアについて具体的に話を詰めていく
    • 問題点、解決策などの洗い出し
    • アイディアの中身について、メンバー皆が考えているコトがちぐはぐだったりした
      • 方向性を固め、メンバー間の認識のズレが極力ないようにする
    • ↑を話し合いたかったが1日目は時間がないということで、後日に行うこととに

SW2日目

2日目開始!

  • 1日目夜に行う予定だったチームでの話し合いの続きから
    • アイディアの中身を固める
    • 機能についての詳細を決める
    • 今回実装する機能について、更に詳細を決める
      • モデル図作成
      • DB設計
        • 今回は中身を実装することはなかったので使わず...
        • SW終了してから継続して開発する際に使われることを願う(゚∀゚)
  • ハスラー陣は外にアンケート調査を実施
    • あしびなー近辺まで行って街頭アンケートを行ったとのこと
    • 本当にありがとう
  • ハッカー陣は億の部屋に篭ってモクモクと作業を開始

昼食

  • スポンサー「上間弁当天ぷら店」さんのお弁当
    • 唐揚げが美味しかった記憶
    • ごちそうさまでした
  • しかし飯食いながらの作業はキーボードによろしくないな

コーチングタイム

  • SW参加者へのフィードバック・アドバイスを担当されるコーチの方々によるコーチン
  • 起業経験をしてきた方々のアドバイスは的確、かなり参考になった
  • 開発作業に没頭していた為、途中までコーチングタイムというものを忘れて作業していた
    • 聞き逃してしまったのが勿体無い!
    • 重きを置く所を間違えていたなと反省(作業などは二の次にすべき)

夕食

  • 「上間弁当天ぷら店」の弁当だった気がするが、何を食べたか覚えてない
  • 揚げ物が連続していたのは薄っすら覚えている
  • いや、美味しかったですから!ごちそうさまです!

2日目の終わり

  • ハスラー陣は街頭アンケートから無事帰宅
    • アンケート実施対象はなんと80人、すごい
    • 集めてきたデータからユーザが何を求めているのかが分かった
      • 作成するサービスが提供する機能と、ユーザが求めているモノのギャップが色々あるのね
  • ハッカー陣はある程度の開発が完了
    • 開発初期は環境構築に手間取っていたが、あのサボさんのお知恵を貸して頂きなんとか乗り切る
    • SW最終日の発表の際にデモで見せる機能については実装した
      • 実装と環境について
        • AWSのEC2 + RDS
        • PHP + Laravel
      • 実装した機能
        • ログイン機能
        • マイページ
        • ユーザ間チャット機能
  • 2日目はなんとか乗り切った感、メンバーみんな頑張った

SW3日目

3日目開始

  • 開発は終わったのでとりあえず一安心...というわけにはいかなかった
  • 発表用スライドの作成とPV撮影を実施
    • 私ともう一人のハッカーがスライド作成を担当
    • 他はPV撮影
      • 可愛いは正義だった
  • スライドを作成していて気づいたが、収益化モデルを具体的に考えてなかった。それについて急遽話し合うことに
    • 先にこれらについて話し合うべきだったのではないかと思った
    • 見込み客数の計算、サービス内の収益となる部分の洗い出しなど行い、そこから大体の収益を計算
      • ありえない額になってしまった
      • 見込み客数を明らかに見誤ってる感じがする
      • もう時間もないということで、どうにか帳尻を合わせたがしかし...

昼食

  • 「上間弁当天ぷら店」の弁当という話を聞いたが、手をつける時間がなかった
    • 作業に夢中になるとお腹が空いているのを忘れてしまうね
  • 「上間弁当天ぷら店」さん3日間ごちそうさまでした

プレゼン練習

  • そんな時間はほぼ取れなかった
  • 収益化モデルの計算に時間使いすぎたな
    • 時間使いすぎた割にまともに算出できなかったのが悲しい
  • プレゼン練習の時間の都合上、一人で発表するのは如何なものかと思い複数人で分担することに
    • szkさんとrmちゃんありがとう!

最終プレゼン

  • 各グループのプレゼンを実施
    • 1分ピッチでアイディアの種として提案されたものが、この3日感でここまで成長したのを考えると凄いと思う
    • Webアプリケーションとして実装してきてるグループや、既にスポンサーを見つけているグループなどもあった
  • オーガナイザからアイディアに対する質問・コメント
    • 批判するだけかと思っていたが、そうではなかった
    • 厳しい目線で評価してもらい、結構丁寧に助言などしていた
  • チーム「Pocket Stylist」のプレゼン
    • 私はサブスピーカーとして壇上に立った
    • メインスピーカーの方が話を上手くまとめてくれていたので助かった
      • メインスピーカーを担当してくれた方が、場馴れしているのがなんとなく伝わった
    • オーガナイザからの質疑応答については四苦八苦
      • チーム内で固まっていない部分をチクチク突いてくる

3日目終了!!

  • 最終プレゼン後はパーティ!
  • オードブルを食べつつ、お酒を飲んで今回の成果について色んな人と語り合う
    • 3日間であまり話せなかった人とも話せて良かった
    • 県内外の人問わず、得られる情報が新鮮だった

チームメンバ + αで飲み会

  • パーティ終了後にチームメンバ + 他チーム女性数名 + 火星人と飲み会を実施
  • SWイベント中には話せなかったコトなど話せて楽しかった

Startup Weekend Okinawa Vol.7 感想

Startup Weekendは今回が初参加となりますが、非常に有意義だったの一言に尽きます。

昔から「あれやりたいなー、これやりたいなー」とアイディアを考えたり思いついたりすることはあったのですが、これを具体的に実現する手順や考え方など全く知らず、頭の中だけで終わってしまうことが多々ありました。 しかし今回のStartup Weekendで、問題提起・解決策考案からビジネスモデル・収益化モデルの考案などを行うことにより、自分で考えたアイディアを実現するための流れを学ぶことが出来たと思っています。

また、本イベントでチームを組んでの作業は非常に楽しかったです。 普段の職場では与えられた作業を受動的にこなす人ばかりで、自ら進んで何かを行うという人は限られていました。 しかし今回は全くの逆で、メンバー全員が提案した問題に対する課題意識を持ち、能動的に且つ前向きに取り組んでいく様子が見られました。 自己組織化されるだけで作業の質がこんなにも変わるのだなと実感しました。

今回は3日という短い期間にアイディアを実現する方法を学びました。 Startup Weekendは終わってしまいましたが、今回メンバー全員で進めたこのプロジェクトが終わったわけではありません。 Startup Weekendで学んだことを無駄にしないように、今後も目標や期間を定めて継続的にアイディアの実現に向けて動いていきたいと考えています(というか動いています)。

Startup Weekendを主催・運営してくれた皆さま、コーチの皆さま、そしてチームメンバーの皆、3日間本当にありがとうございました!

参考

「Hardening 1010 Cash Flow」に参加して

[Hardening] 「Hardening 1010 Cash Flow」に参加して

Hardening 1010 Cash Flowに参加してきました。 箇条書きで流れをば。

Hardeningについて

概要

  • チームごとに販売サイトを運営してその売上を競う
  • その間、各チームのシステムに対して運営側から攻撃が行われる
  • 攻撃をさばきつつ、システムを継続して運営して売上向上を目指す

チーム構成について

  • 1チーム6人
  • 参加者90名のスキルに応じてチームを構成する
  • 申し込みの段階で行うスキルチェックを基に行う
  • 事務対応要員、セキュリティエンジニア要員、マネジメント要員(リーダー)など

販売サイトについて

  • 顧客がアクセスするためのサイト
  • 商品を仕入れるためのサイト
  • 商品を管理するためのサイト
  • (販売サイトではないが)外部に向けて情報を流すサイト

Hardening事前準備

チームミーティング

  • テキストベースのやり取りはSlackを使用
    • Hardening当日の記録などもSlackを使用した
  • ビデオ会議はZoomを使用
    • 会議回数は3回ほど

スキルチェック

  • スキルチェックシートを記入してメンバーのスキルを把握
    • 前回Hardening参加メンバーが使用したというものを流用

各種情報共有

  • Googleスプレッドシートで管理
  • メンバー内の前回Hardening参加者によるHardeningについての説明
    • Slackやビデオ会議時に軽く説明してもらった
    • 前回使用した資料などをメンバーに公開してもらった
  • 沖縄県内の前回Hardening参加者による勉強会などもあった

競技開始直後に実施することリスト

  • 競技開始直後に行う設定などを列挙し、コマンドまで明確に記述
    • 競技開始直後にこの手順に沿って行うことでスムーズに進めることを想定していた
  • スキルチェックシートを参考に担当を割り当て(自主的に選んでたりもした)

用意したスクリプト

Hardening前日

  • 競技環境についての資料が運営から配布される
  • 居酒屋にて打ち合わせ兼懇親会
    • 初めてチームメンバーが直接顔を合わせる
    • 皆で配布された資料に目を通す
      • 構成に対してFWポリシを決定するなど
  • 疲れが残らないよう10時半頃に居酒屋で解散

Hardening当日

競技開始前

  • 会場入口前に予定時刻より少し早めにチームメンバーが集合
  • 会場が開くまでロビーのベンチでダラダラと過ごす
    • チームによっては競技環境についての資料を読んでいるところもあった
  • 予定時刻になると受付からチーム名が呼ばれる
    • メンバーの確認
    • ネームプレートの配布
    • 懇親会費の支払い(リーダーにまとめて預けていたもの)

競技開始直後

  • 実際に競技環境を前にして様々なトラブルが続出
    • 踏み台サーバのUbuntuにログインできない
    • メールが受信できない
    • 販売サイトにアクセスできない
    • ネットワークが重すぎる
      • 上記の問題については時間が経つと解決していた。運営の設定ミスなどもあるらしい
  • 「競技開始直後にすることリスト」通りに作業を行おうとしたが、合間合間に色々と問題が起きてスムーズに事が進まなかった
    • 予め用意されているユーザのパスワード変更だけは徹底して行った
  • FWにポリシーを適用
    • 攻撃らしい攻撃は減ったが、クローラが入ってくるポートも制限していたらしく、売上が低迷
    • 再度ポリシーを修正して適用、売上の増加を確認した
  • 各種スクリプトの設置
    • 競技環境のデータベースの種類がpostgresqlだったため、mysqlバックアップスクリプトは使えず
    • ファイルバックアップ、サービス監視、ファイル改ざん検知スクリプトはいくつかのサーバに導入 -全てのサーバに設置する時間がなかったため、主要なサーバ(Web、DBサーバなど)にのみ設置した

競技中

  • 何もないときはログを眺めていた
    • 実は攻撃や問題に気付いてないだけの可能性もあった(実際どうなのか分からん)
  • マネジメント要員(リーダー)は常に在庫チェックなど行っていた
    • 途中で、商品を購入していないのに在庫を増やせるというバグらしきもの気づいたらしいが、あまり触らないようにしていたらしい
      • 競技終了後には、バグを利用して在庫不正追加を行ったチームについては最終的な売上から減額する措置を行った
  • 攻撃、問題が発覚したときは焦って頭が真っ白になる
    • 自分が何をするのか、何ができるのか分からなくなる
    • とりあえずログを見て何が起こっているか把握する必要があった
    • 連絡報告相談大事
  • 昼食時間はなし、各自合間の時間を活用して昼食を済ませる
    • キャプテンカンガルーのハンバーガー!
      • かなり美味でした
  • 美味しそうなコーヒーとお菓子の誘惑
    • ぶっちゃけ競技そっちのけで飲み食いしたかった気持ちがなきにしもあらず
    • まぁ取りに行く暇なんてない

競技後

  • 全てから解放された気持ちになる
  • やりきっていないがやりきった気持ちになる
  • 競技終了直前のカウントダウンは会場全体が一体感に包まれる

感想

今回初めてのHardening参加となりました。 競技前のミーティングでは話についていくので精一杯で、自分から何かを提案するということはあまりなかった気がします。 また、競技中も自分が何をやっていいか分からず、ひたすら雑務(パスワード変更とかパラメータ変更とか)をこなしていた感じがします。うーん、あまり力になれてない感。

今回の競技を通して、自分の力のなさがハッキリと分かりました。 知ってるけど、やり方は分からないみたいな。ペーパードライバー的な。 机上の勉強だけじゃなく、手も動かさないと身につかないなと感じました。

次回のHardeningに参加できるのであれば、それまでに自分が出来ることを一つでも身につけるよう頑張ります。

eps形式のファイルをpdf形式に

ps2pdfを使う

変換にはps2pdfコマンドを使用するらしい。

$ ps2pdf [input file] [output file]

これでpdf形式に変換出来るが,キャンバスサイズの大きいepsイメージだと画像が切れてしまう。

しかも用紙の形式(a4かな?)になるから謎の余白が出来てしまう。

これを回避するために,epsファイルのBounding Boxに合わせてファイル生成するオプションを加えるのだとか。

$ ps2pdf -dEPSCrop [input file] [output file]

これで元のeps形式のイメージがpdf形式になって綺麗に出力される。

追記

pstopdfコマンドというのもあるらしく,これを使うとBounding Boxのサイズそのままで出力されるらしい。

試しに使ってみたが,綺麗に出力されていた。

しかし,変換後ファイルサイズが大きすぎる...。

情報工学レクチャーシリーズ:アルゴリズムとデータ構造 第三章「データの探索」

探索

  • 多くのデータの中から目的のデータを見つけること

線形探索法(Linear search)

  • 配列の先頭から順番に探索を行う
  • 平均時間計算量は

二分木探索法

  • 配列の中身がソートされていることが前提条件
  • 配列の真ん中の値(mid)が目的の値(x)と一致しているか調べる。一致しているのなら出力して処理終了
  • mid < xなら探索する範囲を配列の後半部分に、mid > xなら探索する範囲を配列の前半部分にし、再度処理1を行う
  • 処理1, 2を繰り返し行った結果、探索する範囲の配列長が1以下になったら配列の中にxは存在していないので、処理終了
  • 平均時間計算量はO(log(n))

ハッシュ法

データの格納方法

  • ハッシュ関数を用いて目的のデータの格納場所を決定する
  • ハッシュ化した値が重複した場合は、ハッシュ化した値に1を加えた場所に格納するなどの処理を行う

データの探索

  • データの格納方法同様、ハッシュ関数を用いて目的のデータの探索場所を決定する
  • 探索場所に目的の値がない場合はハッシュ化した値に1を加えるなどの処理を行い、再度探索を行う
  • 最良時間計算量はO(1)、最悪時間計算量はO(n)
  • データの個数がn個、配列長がmのとき、平均時間計算量はO(m/(m-n))、基本的にはO(1)になる

情報工学レクチャーシリーズ:アルゴリズムとデータ構造 第三章「アルゴリズムにおける基本概念」

  • ”グラフと呼ばれる数学的抽象概念の特殊系” ← 難しいな
  • 木はノード(接点)とそれらを結ぶエッジ(辺)から構成される
  • ノードにはルート(根)と呼ばれる木の起点が一つだけ存在する
  • 子を持たないノードを リーフ(葉) と呼ぶ
  • リーフ以外のノードを内部節点と呼ぶ

k分木

  • 木の中のどのノードも子をk個以下しか持たないとき、その木を k分木 と呼ぶ
  • 全てのリーフのレベルが同じで、かつ全ての内部節点にk個の子を持つ場合、この木を 完全k分木 と呼ぶ

完全2分木

  • レベルがkの節点数は2^(k)
  • 高さをhとすると、リーフの数は2^(h-1)
  • リーフの数をmとすると1+log(m)
  • 高さをhとすると、ノードの数は2^(h)-1
  • ノードの数をnとするとlog(n+1)

再帰

Ruby on Rails の routing で使う match について

Rails4のルーティングの記述やら挙動がいまいちよくわからなかったので、ちょっと調べてみた。

ルーティングとは

  • config/routes.rbに記述する

  • URLから「どのコントローラー」の「どのアクション」に「どういうパラメータ」を与えて処理を実行するかを定義する

シンプルな例

「/tests/17 に HTTP GET すると、TestsController の hoge アクションを id=17 のパラメータで実行する」という設定。

# config/routes.rb
match "/tests/:id" => "tests#hoge", as: "tests", via: "get"

こっちは「/tests/17 に HTTP POST すると、TestsController の hoge アクションを id=17 のパラメータで実行する」という設定。

# config/routes.rb
match "/tests/:id" => "tests#show", as: "tests", via: "post"

上記のシンプル版

こっちが簡単で分かりやすい。

# config/routes.rb
get "/tests/:id" => "tests#show", as: "tests"
post "/tests/:id" => "tests#show", as: "tests"

Rails3の時のルーティング

:viaで HTTP METHOD を指定しなくてもデフォルトで HTTP GET になってたらしい。

# config/routes.rb
match "/tests/:id" => "tests#show", as: "tests"

なお、Rails4では指定してあげないと以下のようなエラーが出る。

You should not use the `match` method in your router without specifying an HTTP method.
If you want to expose your action to both GET and POST, add `via: [:get, :post]` option.
If you want to expose your action to GET, use `get` in the router:
  Instead of: match "controller#action"
  Do: get "controller#action"

情報工学レクチャーシリーズ:アルゴリズムとデータ構造 第二章「アルゴリズムの基本データ構造」

配列

  • メモリ上に連続した領域を確保する
  • データの追加・削除は先頭から走査する必要があるのでO(n)
  • 書き込み、読み込み共に O(1)
  • 配列は宣言時の長さから変更が出来ない = いわゆる静的配列

連結リスト

  • メモリ上に連続して領域を確保するわけではなく、必要に応じて確保する
  • {データ、次のレコードを指すポインタ}という構造の構造体と、リストの先頭を指すポインタから構成される
  • リスト先頭に対するデータの追加、削除はO(1)
  • 連結リスト内の要素の探索は時間がかかる
  • リストの構造上、使用するメモリ領域は配列よりも大きくなる

スタック

  • LIFO(Last In First Out)
  • 後から入れたものが先に出て行く構造
  • pushでデータの追加、popでデータの取り出しを行う
  • push, pop のどちらもO(1)

キュー

  • FIFO(First In First Out)
  • 先に入れた奴が先に出て行く構造
  • enqueueでデータの追加、dequeueでデータの取り出しを行う
  • enqueue, dequeueのどちらもO(1)