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

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

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は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できず、中の要素を固定していく形になる。

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

同じボタンを作りたい。

<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向けウェブサイトではなく、素早くタッチできるようなものだ。