メルカリで初めて出品・発送してみた
とりあえず現金出品とかで話題の「メルカリ」を利用してみない手は無いと思ってやってみた。
1. メルカリに登録
やっぱりFacebook登録は必須ですね
フリマサービスってことでヤフオクからの登録者も多いだろうからYahooIdでの登録もカバーしてるあたりは流石だと思います
特に登録する情報を細かく入力しなくても完了しちゃうので楽だなと
2.出品
やっぱりかんたんですね
写真撮って、任意の説明入力して、入力フォームに合わせてポチポチしてくだけ
「カテゴリー」は何で認識してるかわからないけど自動で出て来るし
「商品の状態」「配送情報」なんかは直感的に指定できるし
「販売利益」が手数料込みで表示されるし「販売価格」はなんとなく適正価格がわかるし
これはわかりやすい
ITリテラシーが低くても問題ない、これは流行る
3.発送
今回は「らくらくメルカリ配送」を利用しました
出品者は情報入力必須で受け取り側は匿名で問題がない
ファミマでQRコード読み込みして梱包した商品をレジでシール貼りやら言われるがままにやってると勝手に配送登録完了
送料は配送完了後に利益から天引きされるので、なんて気楽
まとめ
やっぱりコンシューマ向けのサービスは「わかりやすく」「直感的に」「気楽に」が一般的には大事なんだって改めて感じました
ひとまず評価集めるまでいろいろ出品してみようかなって思う
jsでわかりづらいevent.curretTargetとevent.target
なんか時々event.curretTargetが取れなくてevent.targetが取れるってことがある。
そもそもどんな違いがあるかわからないからちょっと備忘録的にまとめる。
イベントが発火した要素の取得の仕方
以下のような感じでイベントリスナにイベントを詰めるだろう。
このイベントが発火するとオブジェクト(俗に言うMouseEvent)が渡されるが、そのPropertyにcurrentTargetとtargetがあってややこい
event.currentTargetとevent.target
currentTarget:イベントリスナがバインドされてる要素
target:イベントが発生した要素
つまりイベントを乗っけたところと発生したところ
event.currentTargetがなくてevent.targetがあるケース
以下のようなコードを書いてたのだが
なぜかfunchogeでe.currentTargetはあるがfuncfuuではnullになった…。
なんで???
…いろいろ調査したけど伝搬させる方法がわからない。
続報があれば追記します。。。
MVCの勘違う所
MVCには各々役割がある!MとかVとかCそれぞれに
この各々の役割が意外と勘違いされがち(偉い人からの受け売り)
アプリケーションを「プレゼンテーション層」と「ドメイン層」に分離する
それぞれのレイヤーはこんな考え方になってると思う
プレゼンテーション層
- 画面表示部分
- UIロジック
ドメイン層
違う!!!!
プレゼンテーション層
- プレゼンテーションPFの都合が関係ある部分
ドメイン層
- プレゼンテーションPFの都合が関係ない部分
これが正しい
どのアプリケーションの種類にもそのアプリケーション特有の機能がある
- Webアプリケーション → HTTP周り、レンダリング機能周り
- クライアントアプリケーション → 画面オブジェクト周り
Webアプリケーションは、HttpContext・サーバーコントロール(ASP.NET WebForms)・Razor(ASP.NET MVC)などなど
クライアントアプリケーションは、Windowフォームコントロール(WinForms)、XAML(WPF)などなど
プレゼンテーションプラットホームとは、そのアプリケーション特有の機能を実装する部分
そのアプリケーション特有の知識を必要とする部分
そのアプリケーション特有のライブラリに依存する部分
[.NETアプリケーションの場合]
- System.Web、System.Web.*、Microsoft.AspNet.*、OWIN、 Microsoft.Owin、 Microsoft.Owin.*、 etc…
- System.Window、System.Xaml、etc…
ここで改めてドメイン層についてまとめる
アプリケーション特有の機能とは関係のない部分
- Webアプリケーション → HTTPやレンダリング機能とは関係ない部分
- クライアントアプリケーション → 画面オブジェクトに関係ない部分
アプリケーション特有の機能以外の実装部分をドメイン層にまとめる
- そのアプリケーション特有の知識を必要としない部分
- そのアプリケーション特有のライブラリに依存しない部分
ここでMVCをそれぞれ「プレゼンテーション層」と「ドメイン層」に分離する
Model
プレゼンテーションPFの処理系はViewとControllerなので必然的に「ドメイン層」
ビジネスロジックとデータアクセスも含まれるて大きすぎるからその分離は必須…
View
レンダリング機能なので「プレゼンテーション層」
Controller
ViewでカバーできないプレゼンテーションPFの処理を行うので「プレゼンテーション層」
ViewとModelの橋渡し
決定順序的にはView・Controller・Modelですね
ドメインモデルだから問題解決層と勘違いされがちだけど
実はプレゼンテーションPFの概念を入れるか入れないかという判断でPDSは成り立っているというお話でした。
プロトタイプが無いと戦争が起きる
極論だ。しかし、戦争は無くても宗教論争は起きる。