やるかやらないか迷う。こんなことやってても意味があるのか？と。 サクッと作って、公開できればいい思う。とりあえず完成できれば。
気をつけないといけないのは、どんな環境でも使えるように標準化することだ。一店専用になってはいけない。
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？くらい。 店舗運営上広告が出たらちょっとマズいので、そこは有料版にしてもいいのだが、そうすると責任が出てきて困る。
無料。
むしろ、最初のテストにはリスクや導入コストがあるため、お金を払ってもいいくらいだ。
要するにインとアウトの管理であるから、店舗運営に必要なほかのことにも用いることができる。
たとえば
販売するわけでないから、ストコンから補足できないもの。従業員が現数を管理し発注していかなければならないが、漏れがあることがあり、多大な影響を与える。WEBアプリで行うことで、少なくなってきたら担当者にメール送信、などを行うことができる。似たような機能なので、大きなコストなく追加することでき、利便性も高まるだろう。
各コンビニはシステムのすべてを本部に頼っていて、業務を改善する手段を持たない。
結局のところ使うのは人間であり、従業員への教育・説得が必要である。それが障壁だ。
世代によってIT機器への馴染みやすさは異なるため、一気に導入する決断をすることが難しい。さらに労働者側が年齢が上だったりするため強く出れない。また、20人ほどいるバイトが一同に会することはなく、教育コストは高い。
今回の場合、IT導入自体は賛成的だったが、年配者や20人ほどの店員への教育への懸念が問題となって見送られた。 最後にそこが問題ですね、と確認をとった。
ボトムアップだ。考えてみれば、何かを変えるアイデアが自分にあるなら、ボトムアップしかない。少数の上より、多数の下だ。 実際につかうのは下だしな。
導入自体のマニュアルもぜひ作っておく必要がある。
結局のところ、最初は上だろう。それで一応許可をもらってから、下を説得にかかる。下は下で、上の言うことだから仕方ないと思ってたりするので、一応許可を得ていることは重要だ。
デザイン上の工夫。とりあえず、ファミマのSATのデザインを参考にして、右側に操作パネルを設け、それだけで操作できるようにする。タブレットを持たずに操作するときに、真ん中や左側だと非常に操作しずらい。
普通に家で操作するときの万全の体勢ではないので、手の動きをできるだけ少なくするように考えないといけない。一般的なPC向けウェブサイトではなく、素早くタッチできるようなものだ。