  |
はてなキーワード:カラムとは
https://www.businessinsider.jp/article/2506-hoshinoresort-agoda-booking-trouble/
Agodaの悪質転売が話題だが、この裏にはもうひとつの悪者が存在する。
自分は都内のホテルでマネージャーをしていて、ブクマカよりはこの話題に明るいと思う。
もちろんいろんな人にこの構図を知ってほしい気持ちは大いにあるが、これから話すことにはかなり恨み節が混ざると思う。それぐらいAgodaはホテル業関係者から嫌われている。
Agodaは他OTAと同様に、ホテルと契約することで、ホテルは空室をAgodaに卸し、Agodaは集客手数料をホテルから受け取る。これが基本的なAgodaの商売だ。
Agodaがその他のOTAと異なるところは、ほかの旅行会社の在庫を自社サイトに掲載しているところ。IT業の知り合い曰くこれはメタサーチという商売に近いらしい。
たとえば国内大手OTAであるじゃらんネットや楽天トラベルとAgodaは提携していて、それらの空室がAgodaの検索結果として表示されている。
ただしこれはホテル側が「海外プラン販売」的なものに同意してチェックボックスにチェックを入れているから。だからまともな料金・キャンセルポリシー・内容でしか予約は成立しない。
おそらくこの予約経路でトラブルになるケースは皆無だろう。
予約が成立した際、ホテル側からは「予約経路：じゃらん」と見え、備考欄には「じゃらんネットAgoda海外プランで販売」的な文言が入る。
空室確保にトラブルがないのはもちろんのこと、ホテル側も「Agoda→じゃらん→ホテル」の流れであることを明確に認識できるので、お客様対応でコミュニケーションが行き違うこともない。 ※コメント指摘ありがとう！修正しますた
問題はここからで、Agodaはその他の有象無象の提携先(以下サプライヤーと呼ぶ)とも契約していて、それらのサプライヤーの空室を自社サイトの検索結果に掲載している。
おそらく星野リゾートや東横インが遭遇しているトラブルは、ここに絡んだものではないかと推測する。
あるユーザーがAgodaで空室を検索すると、気になっていたホテルの中でも圧倒的に安いプラン・部屋タイプが販売されている。
当然一番安い価格で予約手続きをするが、実際にはこれはAgodaでの予約成立ではない。先述の例のように、『予約経路：Agoda』としてホテルに通知されるわけではない。
ホテル側が受け取る情報においては、「予約経路：Expedia AffiliateNetwork」として通知される。
ここで突然Expediaの名前が出たことに疑問を感じる人もいるかもしれない。言わずもがな海外系有名OTAで、Hotels.comと運営会社を同じくする。
余談だが、Hotels.comの予約はすべて「予約経路：Expedia」として通知されるので、もしかしたらこの辺りのミスコミュニケーションは経験したことがある人がいるかも。
話は戻し、ExpediaAffiliateNetworkがなんなのかを説明したい。
OTA商売というのは、空室を掲載するホテルと個別に契約する必要があるし、それを掲載するプラットフォームも整備しなくちゃいけないからとてもコストがかかる商売だ。
Expedia AffiliateNetworkとは、そこまでリソースを注ぎ込めないホテル予約サイトに対して、Expediaの予約エンジンを使わせてあげるよっていう仕組み。
ぱっと思いつくところだと、カンタス航空の予約エンジンなんかはこれ。
航空会社は航空券とホテルを抱き合わせにする、いわゆるパッケージ予約の需要があるので、航空券は自社から卸して、抱き合わせのホテルはExpediaのシステムに乗っかる。
Agodaも先述の楽天トラベルやじゃらんネットのような提携を当然Expedia AffiliateNetworkとしている。
(あんまりないが)Expediaで他社より安い価格を掲載しているホテルなんかの空室・料金は、これによってAgodaの掲載に集約される。ユーザーは数あるOTAの中から一番リーズナブルな値段で予約ができる。
もしくはホテルが登録した販売価格が各OTA横並びであったとしても、自社取り分の販売手数料分をいくらか自腹切ることで安い値段をAgodaに掲載すれば、より優位に自社在庫へと誘導できる。
ここにExpedia AffiliateNetworkを利用している旅行会社(あえてOTAとは呼ばない)にも有象無象がいて、その有象無象旅行会社がAgodaに空室を掲載するという構図が爆誕する。
ユーザーから見たときに予約が「Agoda→旅行会社→Expedia AffiliateNetwork」の順で空室が確保される、なんてのはまだ良いほうだ。
この「旅行会社」が有象無象すぎて、「Agoda→旅行会社A→旅行会社B→旅行会社C→Expedia AffiliateNetwork」なんてことになる。
冒頭の記事中にもある「何かあったら自分が使った旅行会社に聞いてくれ」とホテル側は言わざるを得ないのはここに理由があって、ホテル側からしたらExpedia AffiliateNetworkの予約でしかないので、ユーザーが「Agodaでどうこう」と言おうが知らん話なのだ。
実際、Expedia AffiliateNetworkのポリシーでもホテル向けには「何かあったらユーザーから使用した旅行会社に問い合わせるように。ホテルからうちに何か言われても一切対応できへんで」と言われている。
最近は都市部のホテルのインバウンド率が高くなったのもあって、今まで表に出てこなかったトラブルが顕在化していると言えると思う。ちなみに俺のとこのホテルは単価高いのもあるけど95%がインバウンド。
中華系サプライヤーを許容するExpedia AffiliateNetworkももちろん悪いんだけど、そういう構図があってもなお「うちのやったことじゃないから」というスタンスで有象無象から卸された空室を掲載し続けるAgodaがほんまにカッスだなと個人的には思う。
ExpediaはExpediaで、「我々もAffiliateNetworkの提携先には注意を払ってる。なにか不穏なことがあればレポートしてくれれば対応します」という、どいつもこいつも他人のせいってスタンスなんだよね。
我々のホテルには「スタンダードツインルーム・23平米」と記載された予約通知が来て、その通りに部屋を確保している。
お客様がチェックインし入室すると、「55平米の部屋で予約したはず」と言われる。いやそんなはずはない、とExpedia管理画面で予約情報を確認すると間違いなく23平米のツイン。
お客様の予約画面を見せてもらうと、Agodaの予約成立画面だし「Premium Twin Room/55m2」なんて書いてあるわけ。
結局ExpediaやAgodaのサポートに散々ヤカった結果、お客様は今確保された部屋で納得し、後の返金はAgodaが面倒見てくれるという。
いわく「Agodaに掲載されていた部屋情報のマッピングが本来のものとは異なっていた」らしい。
まともに英訳・突き合わせできない中華系サプライヤーがExpedia AffiliateNetworkの空室を自社在庫として登録、それをお客様がAgodaで予約したという構図だった。
OTA商売というものはまったく同じ商品を多数の他者が扱っている以上、「他者より安く販売する」しか勝ち筋がない。
Expediaの営業担当(マーケティングマネージャー爆笑)なんかが「Booking.comさんで掲載されている料金がうちより安いんですけどどうなってんの？」なんてメールを送ってくるのは日常茶飯事だ。
それどころか、「他社よりも安い値段を付けていないと検索結果の表示順位が下がる」なんてアルゴリズムが存在してて、それはもうホテル業の人間の間ではこのゲームのルールとして常識になっている。
このアルゴリズムは海外系OTAに顕著で、楽天トラベルやじゃらんnetはせいぜい「空室数たくさん登録してくれるとオススメ順で有利になります」ぐらいのマイルドなもんだ。
楽天もリクルートも個人的には嫌いだけど、随分な優良企業に思えてくる。
今イケてるホテルはどこもOTAからの脱却を図ろうとしていると聞く。
業界の噂で聞いた話だが、今もっともイケてる宿泊特化型ホテルである大和ハウス系列のMIMARUでは、自社サイトでの予約が半分以上らしい。
もうOTAの今までの「他社よりうちに安く出してくださいよぉ～～」の営業スタイルでは商売として限界があると思うし、我々ホテル業としてもいたずらに単価が下がるだけなので別の形で商売の価値を見つけてほしいところ。
とはいえOTAなくしてホテルが成立しないのも事実なので、今回の話が大いに燃えて膿をガンガン出してもらえればと思う限り。
東横インと星野リゾートの発信は、常にへりくだらなければならない我々ホテル業に「そんなの客の俺が知ったことか」では済まない、「ニュースで話題の通りこういうことあるんで」と胸を張って堂々とするきっかけをくれたとも言え、個人的にとても感謝している。
細かく書こうと思えば無限に書けるけど、多すぎるからこのへんで。何か質問あれば追記します。
以下追記
たくさん読んでくれてありがとう～仕事しながら合間で楽しくコメント読ませていただきました。
いつもありがたいと思ってますよー。初めての方なのに自社サイトでわざわざ予約してくれるの見ると、こちらとしても嬉しくなるし、良い部屋にアサインしたりしてる。メンバーにもそうするように指導してる。
これは一定の効果はあると思うんだけど、100%ではないから注意が必要。
連絡時点で部屋が確保されていることは確かに確認できるものの、めちゃくちゃなサプライヤーのやることなので直前でキャンセル通知が来るとかもあり得る。
あるOTAで事前決済で予約した場合、即座に決済とはならず、期日までに支払い手続きをしないと自動でキャンセルされるなんて仕組みがある。間に入っているサプライヤーが入金処理をお漏らしして、当日にはキャンセル済みになっているなんてことは十分にあり得る。
都内の築浅でモダンなビジュアルのホテルはたぶん今どこもこんなもんですよ。
インバウンド客は日本のホテルのことはほとんど知らない状態でOTAで検索するので、見た目がかっこいいホテルを選ぶのです。
ヤカラムーブをする、転じて強くコンプレーンを言うって意味合いでナチュラルに使ってた。
Agodaの夜間窓口は英語対応のみだったりするので、強く状況をアピールしないとゴリゴリの香港訛りのオペレーターにあしらわれたりするのです。
施設サポートの体制も手厚くて誠実なので、個人的には結構気に入っている。営業担当(マーケティングマネージャー)も常に有用な情報をシェアしてくれるし、戦略面でも親身に相談に乗ってくれて安売り以外の提案をきちんとしてくれる。
後発かつ中華系という先入観を打破しようと一生懸命なのが伝わってくる。管理画面の日本語表示がおかしな中華フォントだったり片言表現で使い物にならないのだけ直してほしい。
余談だけど、営業担当に商談のとき見せてもらった彼らのシステムのアナリティクス画面では「中国の台湾」「中国の香港」と表現されててちょっと感動した。わあマジでこういうのあるんだって。
Permalink |記事への反応(15) | 23:32
システムとか、Webサービスとか規模が大きくなると、決定的に抽象思考が必要で、中でも高度な「複数層の抽象レベルを扱う能力」が必須なので、具象思考しかできない「プログラマ」が出世してその辺りをいじり出すと、詰む。
マイクロマネジメント的にでかいシステムを扱うから、うまくいくわけがない。
なんかわからんけど、これをやれと言われてやってきて、やれてきた。
それの積み上げ。
新しく「××しなけりゃいけない」となったら、今時は便利で、ググったりAI使ったりすれば、HowToが並ぶ。
背後にある体系的な思考法とか、歴史的経緯とか、密接に関係する概念とか、全部すっ飛ばして、HowToだけ集める。
すると、全てがチグハグになる。
一個一個、ミクロに見ると、その場その場はそれっぽく見える。
ちゃんとやれてるように見える。
でも全体を俯瞰すると、背景にあるはずの何層にも渡った網の目のような抽象構造が存在しない。
DDDはこの「何層にも渡った網の目のような抽象構造」のための方法論の一つだって理解しないと、多分正しく適用できない。
画面に対する必要十分な実装とだけ考えると、画面に引っ張られまくる。
が、そこで扱われているデータは、ドメインレベルの抽象度のあるコンセプト(オブジェクト)であり、それにまつわる操作や属性を並べておけば、画面はそれの1断面を切り出しただけ、ってのがわかる。本体のコンセプトがちゃんと捉えられていれば、画面の常識の範囲内での変更は、大した影響はない。せいぜいが属性を増やす(そのあたり、DBの1カラムにしないで、Jsonにぶち込んでおけば、テーブルの変更すら不要な)程度の変動しか起こらない。
そして、それが変更容易性につながっているし、Jsonの1要素が増えるだけなので、処理の根幹は変わってないから、余分なテストは不要、ということだ。
そういう背景とかを知らんでDDD、特にこの「ドメイン」を「業務ドメイン」とか勘違いしているアホウには、到底辿り着けない境地だよね w
と、多分、今の日本のエンジニア業界の致命的な欠陥を指摘してみた。
あー、ちなみに、最近、AI、AIと言われるようになったけど、抽象化しないで具象レベルでAIを投入して多量のソースを生み出したら、まず間違いなく管理不能に陥るからな w
ちなみに
JSで０インデックスがヘダーのストリングのアレイのアレイからなるテーブルのカラムを別アレイのカラムインフォオブジェクトのディスプレイナンバーに合わせて並び替えて名前をnameからdisplayNameの値に入れ替えるコード
だと
想定される入力
['id', 'name', 'age'], // ヘッダー
['1', 'Alice', '30'],
['2', 'Bob', '25'],
];
const columnInfo = [
{name: 'name', displayName: '名前', displayNumber: 0 },
{name: 'age', displayName: '年齢', displayNumber: 1 },
{name: 'id', displayName: 'ID', displayNumber: 2 }
];
[
['Alice', '30', '1'],
['Bob', '25', '2']
]
function reorderAndRenameTable(table, columnInfo) {
constnameToIndex = header.reduce((acc,name,idx) => {
return acc;
}, {});
const sortedColumns = [...columnInfo].sort((a, b) => a.displayNumber - b.displayNumber);
// 新しいヘッダーを displayName に置き換え
const newHeader = sortedColumns.map(col => col.displayName);
// 各行の値も同じ順で並び替える
const newBody =body.map(row => {
return sortedColumns.map(col => row[nameToIndex[col.name]]);
});
return [newHeader, ...newBody];
}
ここまで数秒なのでまあこれくらいだと書くよりは早い
ReactとMUIつかって選択式のリストからサブミットボタンでどのAPIにポストするUIとか
JSで０インデックスがヘダーのストリングのアレイのアレイからなるテーブルのカラムを別アレイのカラムインフォオブジェクトのディスプレイナンバーに合わせて並び替えて名前をnameからdisplayNameの値に入れ替えるとか
JavaでパーレントIDのあるフラットなJSONのアレイをchildren listに入れ込んでツリー構造につくりかえるとか
そういうのはサクッと出るので書くのだるい時よくやってるけどこれくらいじゃダメでもっと細かく指定してる
ディストリビューテッドロックのコード書いてとかレベルの高いのざっくり頼むとどのライブラリだあのライブラリだとか言ってきてうだうだやった挙句結局できてないとかなる
コンパクトな増田が動かなくなったことと関係しているのだろうか。最近見ていなかったから放置しているけれど、あれ使う人は自分でパッケージ作り直すくらいはできそうな気もする。どちらにせよあれ無しで閲覧するのは不可能そうだ。
特定ワードで追っている人もいるが、RSS ってまだあったっけ。
新着が完全に機能していないので、趣味の一部が欠落してしまった。非公開ブクマを新着に載せる理由が無い（スパムが湧いて不便以前に、秘匿性が高い情報だし組み合わせれば誰がブクマしているか特定できる）けれど、そんなに難しいことなのだろうか。難しいなら公開のみのカウントカラムを持つとか、いっそのこと users にカウントしないようにするとかさ。カウントされなくても別に誰も困らないよね。
大して伸びない単なる日記が読みたい。
（追記）
あざます。素でも見れるならファーストさんに頼らず探そうかなと思ったけれど、頼っているのは「望むものが見られる」ことよりも「望まないものを見ないで済む」からなのだなと思いました。いつもありがとう。素、つらい。
「新着」は完全に用語を間違えていて、スマホからだと「検索」でanond.hatelabo.jp を検索した時の結果が非公開ブクマのものばかりで見ることができない、機能していないという意味でした。
はてブの機能としての「新着」は 3 users 以上の新着タブに出るやつですな。それはもう見なくなって長いので意識から外れていた。
非公開しかないブクマは検索結果に出さないで欲しい。セルクマやスパムじゃなくても、非公開の元々の意味からしたら出て欲しくないだろうに。
スマホでしか見なくなるとやりようがなくなって頼り切りだったけれど、休日くらいはPC でカスタムCSS とAutoPagerize でがんばろうかな。AutoPagerize って共同DB がうまく機能しなくて死んでなかったっけ。Stylus ってサプライチェーンでマルウェアになってなかったっけ。その辺りも調べてみるね。
個人的にはPC で閲覧している時はスルー力が強く働くが、スマホだとそれが弱まる、見るものは見たいものであって欲しいという気持ちが強まる気がする。
まあ色々工夫の仕方はありそうだけれど、それはそれとしてはてブの検索は非公開のみを対象から外して欲しいな、という気持ちは変わらず。頼む
上から順番に
フレームワークはRails、インフラはAWSECS、チケットには納期を定めず、コミュニケーションは非同期……不動産SaaSのマルチプロダクト展開のため全てに筋を通すスタートアップ「Facilo」の流儀 ←タイアップ広告
エンジニアにとって唯一無二の挑戦環境がある──プラットフォーマーとして新たな成長フェーズに進むRAKSULグループの技術組織 ←タイアップ広告
休みは多く、成果も多く。リクルートのエンジニアに学ぶ「働き方とパフォーマンスを結びつけるエッセンス」 ←タイアップ広告
ミドルエンジニアの「基礎体力」を養いたい。リクルートグループのニジボックスが研修プログラムに込めた熱き思い ←タイアップ広告
ここが面白いよ、リクルートのデータ組織。ユーザーの“背中を押す”ようなレコメンドの設計手法に、ばんくしさんが迫る！ ←タイアップ広告
【必読】エンジニアの「具体と抽象」を往復する学びのヒント！定番フロントエンド技術から資格・数学・英語・ビジネスまで、新たな学びはUdemyの講座から！ ←タイアップ広告
2024年「はてなブックマーク年間ランキング」トップ100 ←独自記事
印刷物の「縦の列」を指すようになり、
この増田では、コラムの語源と起源を軸に、その社会的役割と現代における展開を考察する。
コラムの語源は、古代ローマ建築を支えた石柱「columna」に由来する。
紙面の縦方向の区画を「column」と呼ぶ慣習を生み出した。
日本で「コラム」が外来語として定着したのは明治期以降とされる。
1874年創刊の『郵便報知新聞』が初めて縦組みの短評欄を導入し、
当初は「雑報」と呼ばれていたが、
興味深いことに、
戦前の新聞では「円柱」の原義を意識した「柱記事」という表現も併用されていたが、
戦後GHQの指導で横組みが普及する過程で「コラム」が優勢となった。
1751年3月11日、
イギリスの『ロンドン・アドバイザリー・リテラリー・ガゼット』が紙面右端の縦長スペースに批評記事を連載開始した。
これが「コラム」と呼ばれる契機となり、
当時の記事は縦12cm×横4cmのスペースに収められ、
この形式が人気を博し、
1777年には初の有料コラムニストが登場するまでに発展した。
年間人気コラムランキングが出版されるほど社会的影響力を持った。
朝日新聞「天声人語」の執筆陣には芥川賞作家の井上靖や開高健ら文学者が名を連ねた。
この時期の特徴は、
800字前後の制約の中で比喩と時事批評を融合させる文体の確立にある。
インターネットの普及により、
コラム文体の最大の特徴は、文字数制約（新聞で400-800字、ウェブで1500字前後）の中で最大限の表現効果を追求することにある。
この制約が比喩の多用を促し、「経済の体温計」（日経新聞）のような定型表現を生み出した。
「具体例（30%）→データ提示（25%）→比喩（20%）→結論（25%）」
①擬人法（「円が踊る」）、
2000年代以降は、
といった読者参加型の手法が増加している。
特にYahoo!ニュースのコラムでは、
本文冒頭に読者アンケートを組み込む「インタラクティブ型」が2018年から導入されている。
公式報道では扱えない市井の声を拾い上げる機能を果たしてきた。
実際に地方自治体の政策変更につながった事例が複数報告されている。
近年では、毎日新聞「発言」欄が東日本大震災後の被災地ルポを継続的に掲載し、
コラムは教養主義から大衆文化への橋渡し役としても重要な役割を担ってきた。
2010年代には、
産経新聞「産経抄」が日本の伝統工芸職人を紹介するシリーズを展開、
2023年、
朝日新聞社はAIコラム生成システム「COLUMN-BOT」を試験導入し、
感情分析アルゴリズムを組み込んだ「共感型AI」の開発が進められている。
一方で、
2024年の読売文学賞では初めてAI生成作品がノミネートされる事態が発生した。
読者の閲覧履歴に基づくパーソナライズド・コラムが一般化している。
ユーザーの位置情報・検索履歴・心拍数データ（ウェアラブル端末連動）を分析し、
これに伴い、
職能の変容が進んでいる。
その形態は変化し続けているが、
今後の課題は、
AIとの協働の中でいかに人間らしい洞察を深化させられるかにある。
次世代の「知の柱」としてどのような発展を遂げるか、
Immersive Translateっていう翻訳ツールというかブラウザ拡張機能が便利すぎてヤバい
自分が知ってる限りC++, Rust,Java,JavaScript,Python で日本語識別子使えるんだから
プロダクト開発するときの一番最初のラフな設計を共有したときに
みたいに言ってきて、かなり反対したんだけど
そのせいでDBのテーブル名からカラム名まで全部日本語の名前が付いてるし
それに合わせてオブジェクトやAPIの機能名まで全部日本語で設計
実装するときに全て英語にする必要があって英語名の付け方で揉めるし
そもそも日本語的には良くても英語にするのが難しい（もしくは凄い長くなる）みたいなのもあってスケジュールは大幅に遅延
課題が出てきたときもシーケンス図とかE-R図とか全部日本語で作られてるのでソースを見てから図を見ても理解に時間がかかる
バグ修正でカラム追加やAPI追加するときにもいちいち日本語名と英語名を付けないといけなくて滅茶苦茶めんどくさい
似たような名前の取り違えとかも起きてバグが増えてプチ炎上してやってられん
マジで日本のITが遅れてる原因は日本語問題なんじゃないのかな
海外でも英語ネイティブじゃない国はあるけど設計段階は英語使うし母国語を使うとしてもコメントとかにするのに
・(類似製品の)好きなものの記事に行って嫌いなものの苦言を言う
それが嫌いなら開かず無視したらええねん…ひたすら腐してるのはなんなん…
あなたが望む実現しない要件を何度も挙げて最低条件って言うのは客観的に見て結構恥ずかしくないですか？他のみんなは大多数が興味があって覗いて、少数は内容を批判的に論じるんだけどxlc さんのは内容関係ないよね…？
超バズったからやってきた。とかならわかるんだけど公開ブクマ1桁以内でこういうの言っちゃったりしてるのは当たり屋じゃないっすかね…
なぜコーディングにVSCodeを使うのか。 私がVSCodeを選んだ理由
xlc 2024-03-13
全く心が動かない。私的には80カラム固定のペインが2つ開きっぱなしの状態が維持できて複数のプロジェクトが同時に開けるのが最低条件。
Atom の作者達が作った Rust 製エディタ Zed (OSS) -Qiita
xlc 2024-02-25
VS Codeが嫌すぎてAtomを使い続けているので同じ使い勝手なら移行を考えるかも。私的には80カラム固定のペインが2つ開きっぱなしの状態が維持できて複数のプロジェクトが同時に開けるのが最低条件。
保守・理解しやすいコードを書きたい！ 〜VSCode拡張機能で循環的複雑度と戦う〜 -Qiita
xlc 2024-02-23
Atomの開発が終了しVSCodeをインストールした2023年は全くコードを書かない一年となった。それぐらい使いにくい。というか使う気にならんのだがみんなよく使ってるね。今年Atomに戻したらプログラミングを再開できた。
VS Codeの新機能がすごく便利！ ツリービューのスティッキースクロール機能をオンにすると格段に使いやすくなります
xlc 2024-02-15
昨年ほとんどプログラムを書かなかったのはVS Codeにさわりたくなかったから。とうとう諦めてAtomに戻してプログラミングの習慣を取り戻しました。後継エディタにもがんばってほしい。
xlc 2023-02-02
私はこれhttps://www.amazon.co.jp/dp/4798067881 を書くのにこれhttps://kobalab.net/liulian/ を使いました。
VScodeの設定（setting.json）まとめ【2023年1月更新】
xlc 2023-01-02
VScodeがあまりにも使いにくいので未だにAtomを使ってる。
GitHub製コードエディター「Atom」の最終版が公開 ～8年間の開発に終止符／12月15日をもってリポジトリはアーカイブ
xlc 2022-11-22
VS Codeを起動してみたが、そっと閉じ、使えるうちはAtomを使い続けようと決意した。
SunsettingAtom | TheGitHubBlog
xlc 2022-06-09
まじか。毎日使ってるのに。VS Codeに乗り換えんとならんのか。やだなあ。
Permalink |記事への反応(11) | 11:39
hotentryを閲覧していたところ、過去に山本一郎が書いたゲーム関連の記事を見て、私が経験した不快な出来事を思い出した。
その記事はhttps://web.archive.org/web/20121118031411/http://kirik.tea-nifty.com/diary/2012/11/post-722c.html
私は当時、記事に言及されているゲームを開発した会社に勤めていた。
ゲーム自体はいわゆるガワ変えであり、元のゲームのソースコードにアクセスすることができた。
記事には以下のように書かれているが
一番の問題は、ガチャで「有料ガチャを回しても出ない時間帯が設定することができ、実際にそのように設定されている」ことが明らかになってしまったことです。
これは大きな間違いであり、実際そのように見えたのはバナーの表示制御用カラムであってガチャ出現の制御フラグではない。（カラム名にgachaが含まれるなど邪推される内容ではあった）
このことは2chなどで話題になったものであるが、私はソースコードを確認し、そういった不正な設定はないことを当時確認した。
