転売屋とそれを囲む者たち

この頃の日本は、すごくモラルが下がった。 特に、インターネットの普及によるグローバル化と共に、低いモラルが広がっている。

一番は、転売屋の普及だ。沢山の方々が、困っているし、これ対する批判のコラムも多い。

が、

しかし、これに対して、お店は、メーカーは、サイトは、そして、政府は、決定打を打てずにいる。

そして、転売屋に対して、せどりと名前を変えてクリーンなイメージにする風潮すらある。

サイト側は、何してる?

特に、言いたいのがサイト側の対応だ。

抽選による購入券の獲得・・・ これ、効果あったのかな、転売屋は、簡単に、対処していません?

Amazonさん、どうにかしようとしてます?むしろ、転売屋に寄り添って儲けてません?

そもそも、中古品、新古品、新品を全く同じサイトから購入できるのおかしくないです?せめて、「新古品、中古品をお探しならこちら」みたいにするのが、真摯な感じかと思います。

以前は、売り手すら、わからなかった状態でした。少し改善したようですが、まだ、消費者が困っていることを理解していないですよね。

こうなってくると、間違って転売屋のものを購入させるような感じが、するんですよねぇ。

もう一点

「あなたが購入されたもの売りませんか?」って、時々、サジェストしてきますが、これって、あなたもAmazonと一緒に、転売屋やりませんかって聞こえるんですが、どうでしょう?

メーカーさんは、どうなの?

今一番困っているのは、Nintendo Switch本体(ライトではないやーつ)

Nintendo Switchって、1家に1台の据え置き機というものから1人に1台を目指すものだったはず。 Nintendo Switch本体は、販売されてから3年半、経っていますが、未だに、普及していません。

はっきりいいます、全く足りていない。

転売屋と、なにかやってません?消費者からすると、ずーっと、こんな枯渇状態だとそう感じずにはいられません。これ、コロナのせいだけではないですよね?

バージョンを新しくしてプレミアム感(電池の持ちを良くする、4kに対応する)を出すと転売屋のいい鴨ですよ。

今の生産量を3倍以上にしないと、任天堂のブランドが今後も落ちていきますよぅ。

せどりと称して、イメージを良くしようとしている輩たち

副業をおすすめする雑誌、何冊か確認しましたが、僕が見た限り、全部、以下のような状況でした。

副業として薦めているのが、せどり(つまり転売屋)ですね。

イメージを良くしようと、名前を変えてます、さらに、副業の一番目にお薦めしているのが、この転売屋なんです。

さらに、各サイトが転売屋を抑制している内容と、それに対する対応策まで書かれています。例えば、Amazonでは、同じ住所で別のアカウントを作成できないようにしているので、「1丁目28番地」を「1-28」みたいな方法を提案していました。

情けないですね。

政府は、なにをした?

  • 法律のとあるサイト

https://kobutsukyoka.jp/law/2020-revision-law/

このサイトも、どちらかというと転売屋よりな感じですね。 どうやって法の網をかいくぐるのかをコメントしています。

  • 消費者センター

http://www.kokusen.go.jp/soudan_topics/data/internetrltd.html http://www.kokusen.go.jp/news/data/n-20190606_1.html

あぁ、情報集めてるだけなんですね。

https://www.caa.go.jp/policies/policy/consumer_policy/information/notice/efforts_004.html

さんざんマスコミに言われてからですが、マスクは、禁止できましたね、パチパチパチ・・・

Nintendo Switchや、PS5も禁止できるんじゃないんですか?

法律に強いわけではないので、素人な提案になりますが、以下みたいな法律作れないですかね。

「販売して3年未満のものは、古物商品とさせない」

「抽選で購入販売しているものは、古物商品とさせない」

「古物商品として認可できない商品登録」を作る

自由市場ってなんだ

そもそも、転売屋を撲滅できないのって、骨董品を売買する自由市場のためなんですよね?

であれば、転売屋の餌食になっている、現在の市場は、自由市場になっていないと思うんですよねぇ

Swiftにおける、JSONパージ時、スネークケースで渡されて面倒な対処方法

1.はじめに

2.バージョン

  • Xcode12
  • Swift 5.0
  • GitHubなし(そのままコピペで使えるよ)

3.キャメルケースで受信した時

APIで受信したときに、APIフォーマットがキャメルケースであった場合。 簡単に言うと、そのまんま使えた場合。

import Foundation

struct Response: Codable {
    /// 名前
    let firstName: String
    /// 名字
    let lastName: String
}

/// 受信データ
var json = """
{
"firstName": "山田",
"lastName": "太郎"
}
"""

let data = json.data(using: .utf8)!

/// デコード処理
let model = try! JSONDecoder().decode(Response.self, from: data)

print(model)

4.JSONDecoderのパラメータには、スネークケースで受信する方法がある

let jsonDecoder = JSONDecoder()
jsonDecoder.keyDecodingStrategy = .convertFromSnakeCase

上記でエンコードする。 ただ、これだけだと自動的に使えないので、受信する構造体に、CodingKeyを派生させたenumを切っておく。以下みたいな感じ

struct Response: Codable {
    /// 名前 [first_name]
    let firstName: String
    /// 名字 [last_name]
    let lastName: String

    private enum CodingKeys: String, CodingKey {
        case firstName
        case lastName
    }
}

5.まとめると

以下にような実装で、自動的に、APIがスネークケースで返信してきても、コード側としてはキャメルケースの構造体で使用可能となる。あーら便利 (知っていれば、大した話しでないのだけれどねぇ)

import Foundation

struct Response: Codable {
    /// 名前 [first_name]
    let firstName: String
    /// 名字 [last_name]
    let lastName: String

    private enum CodingKeys: String, CodingKey {
        case firstName
        case lastName
    }
}

/// 受信データ
var json = """
{
"first_name": "山田",
"last_name": "太郎"
}
"""

let data = json.data(using: .utf8)!

/// デコード処理
let jsonDecoder = JSONDecoder()
jsonDecoder.keyDecodingStrategy = .convertFromSnakeCase
let model = try! jsonDecoder.decode(Response.self, from: data)

print(model)

おしまい