「delete」を含む日記

■anond:20250926171439

deleteしてないからなんか違う問題っぽいんだ

Permalink | 記事への反応(0) | 17:32

ツイートシェア

■anond:20250926171427

newはしてるdeleteはしてない今if(pointer == nullptr)以下略って色んなとこに挿入してデバッグしてる😢

Permalink | 記事への反応(1) | 17:31

ツイートシェア

■anond:20250926170845

ちゃんとnewしたのかどうかと、直後にdeleteしてないかどうか気になる

Permalink | 記事への反応(1) | 17:14

ツイートシェア

■anond:20250913213049

delete hell 増田

Permalink | 記事への反応(0) | 21:32

ツイートシェア

■anond:20250904054611

・「凍結・解凍」は日本ではLHAが使ってた（確かっぽい）

確かに使ってた。使ってはいるけど解凍を使ってるのは自己解凍のところだけで、e,xオプションのところでは「ファイルを取り出す」表記。凍結表記もaオプションのところだけ。

(LHAになる前のバージョンだけど)LHarcソースコード内の日本語版の使い方

char use[] =

"LHarc version 1.13c Copyright(c) H.Yoshizaki（吉崎栄泰）, 1988-89.\n"

"============================================================= 1989 - 5 - 21 ===\n"

" <<< 高圧縮書庫管理プログラム >>>\n"

"===============================================================================\n"

" 使用法：LHarc [<命令>] [{/|-}{<スイッチ>[-|+|2|<オプション>]}...] <書庫名>\n"

" [<ドライブ名>:|<基準ディレクトリ名>\\] [<パス名> ...]\n"

"-------------------------------------------------------------------------------\n"

" 《命令》\n"

" a: 書庫にファイルを追加 u: 書庫にファイルを追加（日時照合付）\n"

" f: 書庫のファイルを更新 m: 書庫にファイルを移動（日時照合付）\n"

" d: 書庫内のファイルの削除 e,x: 書庫からファイルを取り出す\n"

" p: 書庫内のファイルの閲覧 l,v: 書庫の一覧表示\n"

" s: 自己解凍書庫の作成 t: 書庫内のファイルの CRC チェック\n"

" 《スイッチ》\n"

" r: 再帰的収集を行う w: ワークディレクトリの指定\n"

" x: ディレクトリ名を有効にする m: 問い合わせを行わない\n"

" p: 名前の比較を厳密に行う c: 日時照合を行わない\n"

" a: 全属性を凍結の対象とする v: 他のユーティリティでファイルを閲覧\n"

" n: 経過表示をしない k: 自動実行のキーワードの設定\n"

" t: 書庫の時刻を最新のファイルに\n"

"===============================================================================\n"

" 転載・再配布などは自由です。 Nifty-Serve PFF00253\n"

" （詳しくは使用の手引をご覧ください。） ASCII-pcs pcs02846";

英語版の使い方

char use[] =

"LHarc version 1.13c Copyright (c) Haruyasu Yoshizaki, 1988-89.\n"

"================================================================ 05/21/89 ===\n"

" <<< High-Performance File-Compression Program >>>\n"

"===============================================================================\n"

"usage: LHarc [<command>] [{{/|-}{<switch>[-|+|2|<option>]}}...] <archive_name>\n"

" [{<drive_name>:}|{<home_directory_name>\\}] [<path_name> ...]\n"

"-------------------------------------------------------------------------------\n"

" <command>\n"

" a: Add files to archive u: Update files to archive\n"

" f: Freshen files in archive m: Move new files into archive\n"

" d: Delete files from archive e,x: EXtract files from archive\n"

" p: disPlay files in archive l,v: View List of files in archive\n"

" s: make a Self-extracting archive t: Test integrity of archive\n"

" <switch>\n"

" r: Recursively collect files w: assign Work directory\n"

" x: allow eXtended file names m: no Message for query\n"

" p: distinguish full Path names c: skip time-stamp Check\n"

" a: allow any Attributes of files v: View files by another utility\n"

" n: display No indicator k: Key word for AUTOLARC.BAT\n"

" t: archive's Time-stamp option\n"

"===============================================================================\n"

" You may copy or distribute without any donation to me. Nifty-Serve PFF00253\n"

" (See the User's Manual for detailed descriptions.) ASCII-pcs pcs02846";

https://www.vector.co.jp/soft/dl/dos/util/se002340.html から

Permalink | 記事への反応(1) | 15:26

ツイートシェア

■anond:20250813160621

ON DELETE CASCADE

Permalink | 記事への反応(0) | 16:12

ツイートシェア

■anond:20250813160401

ON DELETE CASCADE

Permalink | 記事への反応(1) | 16:06

ツイートシェア

■anond:20250813160316

一番右の上から3番目のテーブルをDeleteするのに一番左の一番上まで繋がってるのが見えると思うが

一個Joinすればいいという問題ではないし別にJoinでなくても他の方法でやってもいいわけだが

素人でも簡単にできるというならじゃあその場合の例を君が例えばあげてみてくれ

Permalink | 記事への反応(0) | 16:05

ツイートシェア

■anond:20250813160119

一番右の上から3番目のテーブルをDeleteするのに一番左の一番上まで繋がってるのが見えると思うが

一個Joinすればいいという問題ではないし別にJoinでなくても他の方法でやってもいいわけだが

素人でも簡単にできるというならじゃあその場合の例を君が例えばあげてみてくれ

Permalink | 記事への反応(2) | 16:04

ツイートシェア

■anond:20250813155336

＞外部キー制約があるとむしろ工数膨らむ面が目立つんじゃない？

どういうふうに工数膨らむん？

保守の際にSQLが複雑になって素人ではできなくなる＝人的コストがかさむとか

外部キーによってSQLそのものが複雑になるってどういうこと？

外部キーがあればJoinが発生するし関係が複雑になれば素人ではかけないようなのも出てくる

「外部キーがあればJoinが発生する」これが全然意味が分からない

その外部キーって「外部キー制約」のことよね？

JOINが発生するかしないかなんて関係ないよね？

いやいうまでもなくFKあって他のテーブルに関連のレコードあったら親だけDeleteできないやろ

ってのはまとめると

外部キー制約があると工数が膨らむ

工数が膨らむとは具体的に言うと

外部キー制約があると親レコードだけDELETEできなくなるため、子レコードを削除する処理を書く必要があることだ(このことを「外部キーがあればJoinが発生する」と表現した)

ってこと？

Permalink | 記事への反応(0) | 16:00

ツイートシェア

■anond:20250813155536

DELETE

FROM child c

WHERE c.parent_id = 123;

でいいじゃん

Permalink | 記事への反応(1) | 15:57

ツイートシェア

■anond:20250813155138

DELETE c

FROM child c

JOIN parent p ON c.parent_id = p.id

WHERE p.id = 123;

Permalink | 記事への反応(1) | 15:55

ツイートシェア

■anond:20250813155138

いやいうまでもなくFKあって他のテーブルに関連のレコードあったら親だけDeleteできないやろ

Permalink | 記事への反応(1) | 15:53

ツイートシェア

■anond:20250813140842

横だけど

アプリでの参照整合性チェックどうする？

毎回毎回 SELECTしてチェックしてるの？

これはビジネスロジック次第

ORMなので子・親データがどうかとかの単純なチェックはそのレイヤーでやられてて

それ以外に複雑なビジネスロジック上のチェックが相当ある

削除するときどうするの？

物理削除せず論理削除だけでやるとか？

親を物理削除したとき子の削除はどうする？

うちはビジネスデータは物理削除しない

RESTだけどDELETEのエンドポイントはかなり限られてる

親子は通常ORM

不整合なデータの検出は？

定期的にデータの整合性を監査するバッチを実行してる？

金融系ではないし規模も小さいのでDB上コード上で設計的にキャッチするようにして見逃されたのは仕方がないという方針

ただしデータ取る時に不正なものがあれば無視せずわざと不正終了するようにしてるので割とすぐユーザーから問題が上がるようになってる

移行したシステムでレガシーのデータの整合性にまったく自信がないし

Permalink | 記事への反応(1) | 15:00

ツイートシェア

■ホットエントリから増田が減ってはてブのドメインの比率はどう変わったか 2025年6月

増田は更に減ったが今月はTogetter、Posfieも減った。

減った分はリストのトップ10に入っているようなサイトによって埋め合わせされたようだ。

2025年6月 全274ドメイン

anond:20250604232414

Permalink | 記事への反応(2) | 20:45

ツイートシェア

■生成AIを利用したプログラミング初級者向けの温故知新な提案

はじめに

ここで言う「プログラミング初級者」とはプログラミングの記述が上から下へ向かって順番に処理されること、条件分岐やループという概念があることを理解しており、RPGゲームが作れる「RPGツクール(現RPG Maker)」や学童向けプログラミング環境「Scratch」、「ナビつき! つくってわかる はじめてゲームプログラミング(ナビつく)」、ADVゲームが作れる「吉里吉里(もしくは吉里吉里2)」、過去にBASICやC、HSP、Javascriptあたりでプログラミングへ挑戦し挫折したなどなど、ある程度の「プログラマブルなロジック」構築の経験がある者を指します。

前日談(初級者は読まなくて良いです)

ある時、筆者はふと思いました。「生成AIはなんだかんだで膨大なテキスト情報を処理している事がキモだよなぁ」とありきたりなことを。

そして、同時にプログラミング初級者の弱点として「現在記述されているコードの管理においてテキストと実際の処理フローが脳内で一致しない」「プログラミング言語ごとに定められているルールや関数予約語の把握が困難」なのが問題とも考えました。

前述したプログラミング初級者の弱点の考え自体は車輪の再発明であり、「Scratch」や、より高度な「UML」が既に存在しており、特筆すべきことは何もありません。

しかし、「Scratch」や「UML」、なんなら「RPGツクール」や「吉里吉里」などに無い点として、現代では自然言語処理が大幅に向上した生成AIが実用の域にまで到達しつつあるのが従来とは異なる点でした。

つまり、自然言語を混ぜ込みやすいテキストベースの言語、かつ、処理を記述するとフローが視覚的に理解しやすい言語、可能であれば情報量が多くて一部の界隈で広く使われている言語があればプログラミング初級者も気軽にプログラミングできるのではないか？と発想しました。

そこで前述の条件を満たす1つの言語へ目を付けました。

本題

コンピュータ(コンパイラやインタプリタなどソフトウェアを含む)が解することができる言語にはプログラミング言語以外にも様々あり、今回取り上げるのは「データ記述言語」と呼ばれるものです。

データ記述言語の中でもグラフ作成へ特化しており、特にフローチャート作成で真価を発揮する「DOT言語」というものがあります。

早速ですが、実際に手を動かしてみましょう。ちなみにDOT言語はGraphviz OnlineというWebツールがあるため別途に何かしらをインストールして環境構築する必要はありません。便利な世の中ですね。

上記のGraphviz Onlineを開くと、既に左側のDOT言語で記述された内容が、右側で作図されています。DOT言語はこのような図を作図するためのデータ記述言語です。

一旦、左側の記述をCtrl+Aで全選択をしDeleteなどで全削除し、下記の内容をコピペしてみましょう。

digraph graphname {

    A -> B;

}

一瞬で○に囲まれたAとBが繋がった図が作成されました。

DOT言語の詳細な使い方は様々なWebサイトやブログ記事、Qiitaなどへ譲るとして、A - > Bの見た目から発想の転換をしてみると処理Aから処理Bという流れに見えませんか？

DOT言語は生成AIを利用する上で有利なテキストベースでありながらグラフを作成できるのがキモであり、例えばこのA -> BがA「Webページを開いたら」 → B「Hello, Worldと表示する」という風にできるのであれば処理のフローが可視化されており本当に素晴らしいことです。

Hello, worldを表示してみる

ここでプログラミングの有識者は「DOT言語をUMLなどに見立てて処理を記述するのは良いが、プログラミング初心者は求めた結果を出力するロジックやアルゴリズムを発想する知見や経験値が圧倒的に足りていないのが問題ではないか？」と至極真っ当かつ反論の余地がない問題点の指摘をすると思いますが、そこで活きるのが生成AIです。

生成AIは初級者プログラマ個人のロジックやアルゴリズムの作成能力へ無関係にロジックやアルゴリズムを生成できる(可能性が少なくともある)ので、処理のフローをDOT言語で記述することにより処理フローから初級者プログラマが求めるプログラムを生成AIへ推論させ生成させるというのが狙いです。実際に試してみましょう。

digraph graphname {

    A[
        label = "Webページを表示する"
    ];

    B[
        label = "Webページを表示したらHello, worldとテキストを表示する"
    ];

    A -> B;

}

プログラミングの有識者はこの時点で「なるほど、自然言語の記述をそのままDOT言語に入れ込んでしまうのか」と気付いたのではないかと思います。

このDOT言語をGoogle Gemini 2.5 Flashへ「下記のデータ記述言語のDOT言語で記述された処理フローをJavascript言語へ変換をしWebページ上へ「Hello,world」を表示したいので変換をお願いします。」と命令すると以下のコードが生成されました。

<!DOCTYPE html>
<html lang="ja">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Hello World Page</title>
</head>
<body>
    <div id="output"></div>

    <script>
        // Webページが表示されたら（DOMが完全に読み込まれたら）実行される
        document.addEventListener('DOMContentLoaded', function() {
            // "Webページを表示する" ステップは、このHTMLファイル自体が表示されることで達成されます。

            // "Webページを表示したらHello, worldとテキストを表示する" ステップ
            const outputDiv = document.getElementById('output');
            outputDiv.textContent = 'Hello, world';
        });
    </script>

</body>
</html>

フローを記述する利点は、ロジックやアルゴリズムを発想する知見や経験値が足りなくとも、フローのステップが明確に分かれているので生成AIが処理を切り分けて推論してくれることであり、そしてプログラミング初心者自身がフローチャートを視覚で確認できるので「Aを処理したらBを処理する」と切り分けて考えやすいことです。

また、求めている結果ではなく誤った結果が生成されても、A - > B - > Cとフローを細分化していくことで生成AIの推論精度を高めていくことができるのも利点です。

応用編

より生成AIへ精度の高い推論をしてもらうために補足情報を付加するのも有用です。

digraph graphname {

    A[
        label = "Webページを表示する"
    ];

    B[
        label = "Webページを表示したらHello, worldとテキストを表示する",
        comment = "Webページが完全に読み込まれるまで待機"
    ];

    A -> B;

}

labelの記述内容もcommentの記述内容も生成AIが推論のための情報として利用するので誤った結果が生成されてもA - > B - > Cとフローを細分化しなくとも良い場合があります。

DOT言語を知るプログラミング有識者が「DOT言語の仕様を考えれば確かにそうだが、その発想はなかった」と言っていただけるであろうDOT言語コード例だとこういう記述方法もアリです。

digraph 増田コード {

    最初の処理[
        label = "Webページを表示する"
    ];

    次の処理[
        label = "Webページを表示したらHello, worldとテキストを表示する",
        comment = "Webページが完全に読み込まれるまで待機"
    ];

    最初の処理 -> 次の処理;

}

ノードの名称へ自然言語を採用することにより、例えばゲームプログラミング時に「キャラクターがジャンプする」という読んだそのままな処理のためのノード、というか一般的に言うオブジェクトを作成することが可能で、後は->で繋げて処理をさせられます。

ちなみに別のノードを作成する際に「"キャラクターがジャンプする"から継承する」の様なことをcommentなどへ記述しておくと生成AIが推論して継承します。なんならcommentなどへ「キャラクター画像にimage.gifを使用」などと記述しておくとファイルの読み込みもします。

更にDOT言語にはカスタム要素という仕様が存在しており、DOT言語の仕様で定められた予約語以外も使用が可能です。

digraph 増田コード {

    最初の処理[
        label = "Webページを表示する"
    ];

    次の処理[
        label = "Webページを表示したらHello, worldとテキストを表示する",
        comment = "Webページが完全に読み込まれるまで待機",
        font_style = "フォントを太字のボールド体、色を赤(#FF0000)とする"
    ];

    最初の処理 -> 次の処理;

}

生成AIはカスタム要素の名称からも推論を発揮し、上記の場合であればフォントスタイルを指定していると推論をするので生成AIの推論精度を高める補足情報として機能します。

つまりこれはカスタム要素の名称として"Action"などの名称を採用すると"動作"として推論をし、"decision"ならば"条件分岐"ですし、"input"ならば"入力"ですし、"loop"ならば"繰り返し"ですし、"Type"ならば"種別"です。

より詳細に process[type="Action"] などのノードを作成してどんどん生成AIの推論精度を高めていくことが可能であり、そろそろ察してきているかと思いますが 処理[種別="動作"] と自然言語で記述しても機能します。

プログラミング有識者は更に「プログラム言語自体の予約語、例えばJavascriptを生成する事を前提にlengthを名称にすると配列を使おうとするのか？」と疑問に感じるでしょうがお察しの通りで生成AIは配列を使おうとするので、敢えて使いたいプログラム言語の機能や外部ライブラリなどがある場合は補足情報として機能する形で記述しておくと生成AIは推論へ利用します(まぁそこまで知識ある方なら該当のプログラム言語使ったほうが手っ取り早いと思いますが)。

おわりに

以上をもって「生成AIを利用したプログラミング初級者向けの温故知新な提案」を終えたいと思います。

色々とツッコミどころには筆者自身が気付いていて。例えば「結局はDOT言語の仕様を覚えないといけないのでは？」とか「プログラミング初級者に任せると生成前のソースであるDOT言語コードがスパゲッティになりそうだよな」とか「面倒くせぇから普通にプログラミング覚えろや」とか理解してますし至極真っ当かつ反論の余地がないと思ってます。

今回の提案のプログラミング有識者向けの本質は「生成AIへ向いた中間言語の発掘」であり、「DOT言語ならそこそこ普及してるしプログラミング初級者でも扱えるんじゃね？」と業務中に発想したものを書き留め公開いたしました。

何かプログラミング有識者の皆さんからより良い発想があれば参考にしたいと考えていますのでよろしくお願いいたします。以上。

Permalink | 記事への反応(36) | 19:36

ツイートシェア

■anond:20250703124739

そっかー

元請けの若手が手順書にないSQLのDelete文を何故か連打してたんだけどそれでも下請けが悪いのかー

そっかー

じゃあしかたないかー

そっかー

誤解があるようだから補足しておくと、一応契約の形式上元請け下請けと言ってるが立場は対等なんだなこれが

奴隷根性染み付いた増田の民にはわからん感覚かもしれないがそういう世界もあるんだよ

思い込みが激しいと損するぞ

Permalink | 記事への反応(2) | 12:53

ツイートシェア

■ホットエントリから増田が減ってはてブのドメインの比率はどう変わったか 2025年5月

増田が減った分だけTogetterが増えていた。Posfieも増えている。

他に上位では毎日新聞が大きく減らし、その代わりなのか朝日新聞が少し増えている。

2025年5月 全312ドメイン

anond:20250306214706

Permalink | 記事への反応(1) | 23:24

ツイートシェア

■Ｃ＋＋便利そうな機能

プログラミング言語のＣ＋＋に暫く離れていたが便利そうな機能が出来ていたんですね。

自分が調べても色々理解しきれていないのでここの紹介で間違いがあったらすみません。

std::variant(C++17以上)

異なるクラスを代入して保持するものであり、例えばunionのような機能を実現できるらしい。

クラスが大きくなると使わない変数も出てくるかもしれない。

例えばゲームで武器と鎧が同じクラスの場合、

武器として使う場合は攻撃力変数は必要でも守備力変数は必要なく、

鎧として使う場合は守備力変数は必要でも攻撃力変数は必要ない場合らしい。

このような使わない変数を隠蔽しバグを作ってしまうことを回避できるらしい

std::optional(C++17以上)

任意の値と無効値を保持できるらしい。

例えば、boolで実装する場合は、関数戻り値をboolで成功か失敗かを返し、欲しい値を関数の引数のポインタに返す・・というプログラミングになると思う。

std::optionalでは戻り値として欲しい値と失敗かどうかを一緒に返せるらしい。

std::unique_ptr(C++11以上)

メモリの動的確保だが自分でdeleteしなくて良いのでメモリ解放忘れを防いでくれる。

スマートポインタは前からあったが現在の推奨はstd::unique_ptr

(C++20以上と記載していましたがC++11とのご指摘を受けたため修正しました。すみませんでした。)

enum class(C++11以上)

列挙クラス

列挙型だが従来の列挙型と異なり変数名が外部と衝突しない

nodiscard(C++17以上)

nodiscard属性が付いている関数は戻り値の受け取りが必須となる。

他、auto(型推論)、for each

ちなみにstd::optional＜std::string＞ obj;のように＜＞内に書かれているのは昔からあったテンプレート機能のようです。

Permalink | 記事への反応(1) | 09:03

ツイートシェア

■

delete演算子だけなんかおかしい

javascript系列の中で書き方違いすぎて、お前それは嘘だろって言いながら毎回書いてる

Permalink | 記事への反応(0) | 12:12

ツイートシェア

■anond:20250322220222

id を手動でコピーしてくるのが面倒だったから、削除ボタンが画面に出るようにした

押すと即削除

const rkm = "(トークン的なもの)"
const user = "(ユーザ名)"

const delmasda = (id) =>
    fetch(`https://anond.hatelabo.jp/${user}/edit`, {
        "headers": {
            "content-type": "application/x-www-form-urlencoded",
        },
        "referrer": "https://anond.hatelabo.jp/",
        "referrerPolicy": "origin",
        "body": new URLSearchParams({
            "rkm": rkm,
            "mode": "confirm",
            "id": id,
            "delete": "削除する"
        }).toString(),
        "method": "POST",
    })

for (const sec of document.querySelectorAll(".section")) {
    const id = sec.querySelector("a").href.match(/\/(\d{14})/)[1]
    const delbtn = document.createElement("button")
    delbtn.textContent = "削除"
    delbtn.onclick = async () => {
        await delmasda(id)
        sec.remove()
    }
    sec.querySelector(".edit").after(delbtn)
}

Permalink | 記事への反応(0) | 22:21

ツイートシェア

■

増田の削除をひとつひとつ詳細画面開いてするのが面倒だからまとめて消すスクリプトやで

const rkm = "(トークン的なもの)"
const ids = ["(削除する増田ID)"]
const user = "(ユーザー名)"

for (const id of ids)
    fetch(`https://anond.hatelabo.jp/${user}/edit`, {
        "headers": {
            "content-type": "application/x-www-form-urlencoded",
        },
        "referrer": "https://anond.hatelabo.jp/",
        "referrerPolicy": "origin",
        "body": new URLSearchParams({
            "rkm": rkm,
            "mode": "confirm",
            "id": id,
            "delete": "削除する"
        }).toString(),
        "method": "POST",
    })

Permalink | 記事への反応(2) | 22:02

ツイートシェア

■神々のトライフォース

まだ、幼稚園や小学1年生の頃の話

ゼルダの伝説を買ってもらったけど、幼い自分には難しくてなかなか先に進めなかった

そんな時、友達のお兄ちゃんが一気に進めてくれてラスボスの直前までたどり着いた

自分でやったわけではないが、友達に自慢し、大切なセーブデータだという話を学校していた

そんな時、別の友達が「セーブデータをもうひとつ作る方法があるからやってあげる」とうちに来てくれることになった

ただその頃はまだアルファベットの読めない子供、「たしかこれを選ぶとできる」と彼が二択で選んだのはDELETEだった

彼がCOPYを選んでいれば…と、数十年経ってもあの頃の思い出は消えない

Permalink | 記事への反応(0) | 02:00

ツイートシェア

■Togetterのドメイン分割ではてブのドメインの比率は変わったか 2025年2月

ホットエントリのシェアNo.1サイトであるTogetterがドメインをTOGETTER.COMとPOSFIE.COMに分割してどうなったか気になったので久しぶりに集計。

POSFIE.COM側の比率が大幅に低い。

2サイト足し合わせると先月以前のTogetterのホットエントリ入り回数とだいたい一緒。1月は290回(270+20)、12月は293回、11月は250回、10月は288回。

2025年2月 全271ドメイン

anond:20240905235215

Permalink | 記事への反応(1) | 21:47

ツイートシェア

■英語圏至上主義人種が嫌い。

英語文化で、作品に対して『究極の尊さを表現した褒め言葉』として"I HATE THIS(直訳：これ嫌い)(意訳：しゅき)、"DELETE THIS(直訳：消してくれ)(意訳：尊死)というコメをすることがあるそうです。しかし、リプや引用RTでそれを見た英語非ネイティブが誤解してしまうことが散見される.

言葉通りに受け止めて作品を消したり鍵掛けたりする絵師様を見かけて心を傷めたツイ主が注意喚起してくださってます。なので、こういう言葉遣いはやめましょうねという方向に動くとは思いますが、もしもそういうリプや引用RTをされた場合「気に入ってもらえたんだな」と思ってほしいです。

という一連の話。

今やネットでいくらでも英語⇒日本語翻訳できるんだからカタコトでも日本語で感想くらい書けよ。

日本人は海外の作家さんに感想書くとき日本語でスラングなんか織り交ぜた事書かねーぞ。

Permalink | 記事への反応(4) | 14:45

ツイートシェア