{{tag>project 終了}}

====== FF管理アプリ ======

やるかやらないか迷う。こんなことやってても意味があるのか？と。
サクッと作って、公開できればいい思う。とりあえず完成できれば。

気をつけないといけないのは、どんな環境でも使えるように標準化することだ。一店専用になってはいけない。

===== 開発記 =====

==== 時刻計算 ====
  td = datetime.timedelta(weeks=1, hours=20)
  now = datetime.datetime.now()

  td + now
  -> 1週20時間後で計算できる。

==== グラフ ====
https://developers.google.com/chart/interactive/docs/gallery/timeline

タイムラインを使用。
ほかにもたくさんあって、カンタンで、…スゴい。

==== GET ====
URLでパラメータを渡す方法。

  from django.urls import reverse
  from urllib.parse import urlencode

  # hoge_viewからhuga_viewにリダイレクトするときにパラメータを付与する
  def hoge_view(request):
    ...
    # リダイレクト先のパスを取得する
    redirect_url = reverse('app:huga_view')
    # パラメータのdictをurlencodeする。複数のパラメータを含めることも可能
    parameters = urlencode({'param1': 'this_is_param1', 'param2': 123})
    # URLにパラメータを付与する
    url = f'{redirect_url}?{parameters}'
    return redirect(url)
  def huga_view(request):
    param1 = request.GET.get('param1') # param1の値を取得
    param2 = request.GET.get('param2') # param2の値を取得
    ...
    return render(...)
==== jQuery ====
**jQueryはheadに置くだけじゃ使えない！！！！！
**
上記のようにjQueryを利用しますが、headにおくとうまく作動しません。それはまだ「body」の内容を読んでいなうちには実行できないためです。

そのために、「.ready」という関数を使います。

関数を使ったソースは以下の通りです。HTMLファイルとは別に「sample.js」というファイルを用意してHTMLファイルから読み込みましょう。

  $(document).ready(function(){
    $("#sample").css("color","#d9534f");
  });

==== 固定サイドバー ====

SAT的な右側の操作バーを作るときに、固定サイドバーがよさげだが、単にsticky-topでは上のstickyと重なってうまくいかなかった。

  .sticky {
    position: -webkit-sticky;
    position: sticky;
    top: 10px;
  }
を<div class="col-lg-2">の中の要素に配置する。
col-lg-2自体はfixできず、中の要素を固定していく形になる。

これによって、横の位置を揃えたうえで固定できる。

====submitボタンの複製 =====

同じボタンを作りたい。

  <form id="hoge" action="">
　  <label for="">formタグ外のボタンからテキストを送信したい。</label>
  　<input type="text">
  </form>
  <div>
　  <button type="submit" form="hoge">submit</button>
  </div>

buttonにformのidを指定することで、form外から送信できる。

==== グラフの伸長 ====

        var paddingHeight = 50;

        // the natural height of all rows combined
        var rowHeight = dataTable.getNumberOfRows() * 41;
        console.log(rowHeight)

        // set the total chart height
        var chartHeight = rowHeight + paddingHeight;
        console.log(chartHeight)

				var options = {
        	height: chartHeight,
          // hAxis: {
          //    format: 'dd.MM.yyyy HH:MM'
          // },
          hAxis: {
            format: 'M/d/yy',
            gridlines: {count: 15}
        }

        };

完全なるコピペ。
※ページ位置が保持できなくなることが判明

==== パラメータがないときに対応する方法 ====
?sort=nameなどがないときにエラーにならないためには
    if 'sort' in request.GET:
        cookings = Cooking.objects.order_by('-'+request.GET['sort']).all()[:100]
    else:
        cookings = Cooking.objects.order_by('-id').all()[:100]
in を使う。

===== 企画書 =====

==== 導入 ====


==== 現状分析 ====

店内で調理し、販売する場合、販売期間は数時間と短く、管理する必要がある。これらは紙によって管理されている。しかし、紙での管理には、いくつかの問題が存在し、コンピュータでの操作に置き換えるとメリットが大きい。

  * チェックのしづらさ。→時間ロス、廃棄漏れ
  * 過去データの参照しづらさ。各自の勘によって作成は行われている。属人化が進みやすい。
  * 表の作成コスト。手書きでカラムを毎日書いている。
  * 項目が足りなくなる。((特にファミチキ))
  * 見通しの立てづらさ。常に時間をずらして廃棄リスクを減らさなければならないが、手動では難しい。

==== 企画内容 ====

従来の入力をブラウザ上で行うことで、各タスクの効率化を図る。各店舗用に作るのではなく、汎用的なものを作成する。各自でカスタマイズするようにする。導入等についてもよくドキュメントを用意する。

基本無料で運営し、広告料でペイする。

==== 目標 ====

一日でだいだい200回くらいはリロードすると予想。FF＋常温＋肉まん作成だけで150、廃棄で100？くらい。
店舗運営上広告が出たらちょっとマズいので、そこは有料版にしてもいいのだが、そうすると責任が出てきて困る。


==== 費用 ====
無料。

むしろ、最初のテストにはリスクや導入コストがあるため、お金を払ってもいいくらいだ。
==== 手段 ====

==== 必要な部品 ====

  * 登録画面(セレクトボックス)→品名、個数、調理時刻
  * 店頭状況一覧→修正＋削除
  * 寿命表…廃棄時間のサイクルをグラフィカルに表示する。
  * 廃棄個数入力画面
  * 削除画面
  * 管理画面
  * 広告
  * 各ジャンルごとの表示(FF、常、肉まん、おでん)。これもカスタマイズ可能にする。
  * ログイン表示
  * 実績確認(過去の記録を閲覧)

==== 応用 ====

要するにインとアウトの管理であるから、店舗運営に必要なほかのことにも用いることができる。

たとえば
  * 用度品管理
  * 肉まんの調理状況(店員側、客側)
販売するわけでないから、ストコンから補足できないもの。従業員が現数を管理し発注していかなければならないが、漏れがあることがあり、多大な影響を与える。WEBアプリで行うことで、少なくなってきたら担当者にメール送信、などを行うことができる。似たような機能なので、大きなコストなく追加することでき、利便性も高まるだろう。

==== 状況 ====

各コンビニはシステムのすべてを本部に頼っていて、業務を改善する手段を持たない。

==== スケジュール ====

  * 12月…テストページ、個別ページ作成。
  * 1月…汎用化、完成。

==== 導入障壁 ====

結局のところ使うのは人間であり、従業員への教育・説得が必要である。それが障壁だ。

世代によってIT機器への馴染みやすさは異なるため、一気に導入する決断をすることが難しい。さらに労働者側が年齢が上だったりするため強く出れない。また、20人ほどいるバイトが一同に会することはなく、教育コストは高い。

今回の場合、IT導入自体は賛成的だったが、年配者や20人ほどの店員への教育への懸念が問題となって見送られた。
最後にそこが問題ですね、と確認をとった。

ボトムアップだ。考えてみれば、何かを変えるアイデアが自分にあるなら、ボトムアップしかない。少数の上より、多数の下だ。
実際につかうのは下だしな。

導入自体のマニュアルもぜひ作っておく必要がある。

結局のところ、最初は上だろう。それで一応許可をもらってから、下を説得にかかる。下は下で、上の言うことだから仕方ないと思ってたりするので、一応許可を得ていることは重要だ。

==== デザイン上の工夫 ====

デザイン上の工夫。とりあえず、ファミマのSATのデザインを参考にして、右側に操作パネルを設け、それだけで操作できるようにする。タブレットを持たずに操作するときに、真ん中や左側だと非常に操作しずらい。

普通に家で操作するときの万全の体勢ではないので、手の動きをできるだけ少なくするように考えないといけない。一般的なPC向けウェブサイトではなく、素早くタッチできるようなものだ。