メルカリで初めて出品・発送してみた

とりあえず現金出品とかで話題の「メルカリ」を利用してみない手は無いと思ってやってみた。

 

1. メルカリに登録

やっぱりFacebook登録は必須ですね

フリマサービスってことでヤフオクからの登録者も多いだろうからYahooIdでの登録もカバーしてるあたりは流石だと思います

特に登録する情報を細かく入力しなくても完了しちゃうので楽だなと

2.出品

やっぱりかんたんですね

写真撮って、任意の説明入力して、入力フォームに合わせてポチポチしてくだけ

「カテゴリー」は何で認識してるかわからないけど自動で出て来るし

「商品の状態」「配送情報」なんかは直感的に指定できるし

「販売利益」が手数料込みで表示されるし「販売価格」はなんとなく適正価格がわかるし

これはわかりやすい

ITリテラシーが低くても問題ない、これは流行る

3.発送

今回は「らくらくメルカリ配送」を利用しました

出品者は情報入力必須で受け取り側は匿名で問題がない

ファミマでQRコード読み込みして梱包した商品をレジでシール貼りやら言われるがままにやってると勝手に配送登録完了

送料は配送完了後に利益から天引きされるので、なんて気楽

 

まとめ

やっぱりコンシューマ向けのサービスは「わかりやすく」「直感的に」「気楽に」が一般的には大事なんだって改めて感じました

ひとまず評価集めるまでいろいろ出品してみようかなって思う

jsでわかりづらいevent.curretTargetとevent.target

なんか時々event.curretTargetが取れなくてevent.targetが取れるってことがある。

そもそもどんな違いがあるかわからないからちょっと備忘録的にまとめる。

イベントが発火した要素の取得の仕方

以下のような感じでイベントリスナにイベントを詰めるだろう。

このイベントが発火するとオブジェクト(俗に言うMouseEvent)が渡されるが、そのPropertyにcurrentTargetとtargetがあってややこい

element.addEventListener(event, function(e) {}, false);
$(selector).on(event, function(e) {});

event.currentTargetとevent.target

currentTarget:イベントリスナがバインドされてる要素

target:イベントが発生した要素

つまりイベントを乗っけたところと発生したところ

event.currentTargetがなくてevent.targetがあるケース

以下のようなコードを書いてたのだが

element.addEventListener('click', (e: MouseEvent) => {
   funchoge(e).then(() => funcfuu(e));
});

なぜかfunchogeでe.currentTargetはあるがfuncfuuではnullになった…。

なんで？？？

 

…いろいろ調査したけど伝搬させる方法がわからない。

続報があれば追記します。。。

MVCの勘違う所

MVCには各々役割がある！MとかVとかCそれぞれに

この各々の役割が意外と勘違いされがち（偉い人からの受け売り）

 

f:id:kichion0526:20160628103913p:plain

MVCを語る上で欠かせないPDSという考え方

アプリケーションを「プレゼンテーション層」と「ドメイン層」に分離する

それぞれのレイヤーはこんな考え方になってると思う

プレゼンテーション層

  • 画面表示部分
  • UIロジック

ドメイン層

 

違う！！！！

 

プレゼンテーション層

  • プレゼンテーションPFの都合が関係ある部分

ドメイン層

  • プレゼンテーションPFの都合が関係ない部分

 

これが正しい

 

f:id:kichion0526:20160628104513p:plain

どのアプリケーションの種類にもそのアプリケーション特有の機能がある

  • Webアプリケーション　→　HTTP周り、レンダリング機能周り
  • クライアントアプリケーション　→　画面オブジェクト周り

Webアプリケーションは、HttpContext・サーバーコントロール(ASP.NET WebForms)・Razor(ASP.NET MVC)などなど

クライアントアプリケーションは、Windowフォームコントロール(WinForms)、XAML(WPF)などなど

 

プレゼンテーションプラットホームとは、そのアプリケーション特有の機能を実装する部分

そのアプリケーション特有の知識を必要とする部分
そのアプリケーション特有のライブラリに依存する部分

[.NETアプリケーションの場合]

ここで改めてドメイン層についてまとめる

 

f:id:kichion0526:20160628110215p:plain

アプリケーション特有の機能とは関係のない部分

  • Webアプリケーション　→　HTTPやレンダリング機能とは関係ない部分
  • クライアントアプリケーション　→　画面オブジェクトに関係ない部分

アプリケーション特有の機能以外の実装部分をドメイン層にまとめる

  • そのアプリケーション特有の知識を必要としない部分
  • そのアプリケーション特有のライブラリに依存しない部分

 

f:id:kichion0526:20160628110442p:plain

ここでMVCをそれぞれ「プレゼンテーション層」と「ドメイン層」に分離する

Model

プレゼンテーションPFの処理系はViewとControllerなので必然的に「ドメイン層」

ビジネスロジックとデータアクセスも含まれるて大きすぎるからその分離は必須…

View

レンダリング機能なので「プレゼンテーション層」

Controller

ViewでカバーできないプレゼンテーションPFの処理を行うので「プレゼンテーション層」

ViewとModelの橋渡し

 

決定順序的にはView・Controller・Modelですね

 

 

ドメインモデルだから問題解決層と勘違いされがちだけど

実はプレゼンテーションPFの概念を入れるか入れないかという判断でPDSは成り立っているというお話でした。

プロトタイプが無いと戦争が起きる

プロダクト エンジニア プロトタイプ

極論だ。しかし、戦争は無くても宗教論争は起きる。

 
『ボタンの配置はこうすべきだ』『レイアウト的にもっと画像は大きく』
起こりうる議論は紙の上で宗教化する。
 
終いにはディレクターの決をメンバーが待ち、決まったことに納得がいかなくとも製品になるまで過ちを正せない…
そんな戦死覚悟のプロダクトを出さないために『プロトタイプ』を作る！
 
〜より良いプロトタイプのために〜
 
ペーパープロトタイプ、ないしデザイナーが下ろしてくれるワイヤーフレームで満足してはいけない。時代はより便利になっている。
いろいろなツールが出てきて、何を使えば…いいのかわからん。
 
アジャイルにしろ、小さいプロダクトをサイクルさせることは
今、必須になっているのだろう。
 
そんなことを2年前の自分に言い聞かせたかった。