「ビジネスロジック」を含む日記 RSS

はてなキーワード: ビジネスロジックとは

2021-09-19

anond:20210919092616

複数ファイルに分割し、汎用的な処理だけをまとめたもの

ビジネスロジックの根幹部分を分けてゆく。

シンプルリファクタリング継続して改善してゆこう。

2021-08-20

anond:20210819215813

モダン技術トピックを極めたいって言ってても、日本人エンジニアの99%はアメリカヨーロッパ中国提唱実装された技術ユーザーとして流行を追ってるにすぎないんだからバリューはあまりないよ

英語もろくに読み書きできないエンジニアは、ビジネスロジックへの対応力で勝負するしかないだろうに

食っていければいいレベルの人を見下しているようだけど、あまり違わないことを自覚したほうがいい

2021-08-19

エンジニアが集まらない、育たない

モダン技術トピックは扱っていないが、ビジネスロジックの複雑なシステムを扱っている会社にいる。

技術を極めたいという優秀な開発者は辞めるし、

食っていければいいレベル能力の低い開発者も複雑なシステムを扱えなくて辞めていく。

会社金も出してくれないし、もう集まりようがない。

2021-08-01

素直に『わかりません』と言ってくれるプログラミングスクール出身エンジニア

最近案件自分メインで担当することが増えた。

自分仕事としては案件進めているうちに出てくる課題とか機能追加とかバグ修正とかを設計してIssueとして作って他の人に振ったり自分作業に当たったりと色々なんだけど、

最近とあるプログラミングスクール出身の同僚エンジニア(最近同じ部署になった)が自分案件アサインされた。



先日その同僚エンジニアとあるIssueを初めて振った。

内容としてはとあるテーブル特定カラムバリデーション処理が漏れいるから追加してもらって、なおかつユニットテスト修正する、というもの。まあ簡単な奴。

Issueを振ってからしばらくすると同僚エンジニアから質問が来た。

ユニットテスト実装方法がわかりません。」

「ん?」と思った。いや別に特殊ことなんて何もないIssueだし似たようなテストケースリポジトリ上に山程あるしどうにでもなるじゃんって。

まあ特に考えず1個のテストケースを例として自分で作ってみて、「残りは○○の場合とXXの場合と△△の場合テストケース網羅してください」みたいな返信をした。

しばらくするとまた質問が来た。「△△の場合テストケース実装方法がわかりません。」

いやいや、そんなん頭使ってどうにかこうにか考えろよって。案件特有ビジネスロジックのことを聞かれるならわかるけどこんなレベル対応どの企業のどの案件で振られても同じことやるだけやん。

この質問してるのが未経験入社1ヶ月目の新入社員なら自分笑顔で答えるけどこのエンジニアは俺よりキャリアが長いらしい。

その同僚エンジニアはわからないことがあるととにかく素直に「わかりません」と言ってくれる人だった。

成果物についても指摘事項があまりにも多く、自分(というかその人以外)がやったら10分くらいで終わる対応に数時間以上かけて説明して修正してもらうという感じになった。何のための仕事をしているのかよくわからくなっていた。


自分ITエンジニアが「わかりません」という言葉を使うのは例えばどうしても再現性がなくてログにも何も残ってない謎の不具合とか、コンパイラインタプリタレベル不具合で現時点で解消方法がどこにも載ってない奴とか、そういうマジで「参りました」的な状況だけかと思ってた。

こんな公式ドキュメントデバッグツールだけでどうにでもなる状況で「わかりません」を使う人に遭遇するのは初めてだった。



その人はとにかく「わかりません」が多い。

レビューの指摘の意味がわからない、指摘内容はわかっても修正方法がわからない、影響反映を洗い出してほしいと言ったら影響範囲の洗い出し方がわからないと言われる。何ならわかるのか教えてほしいくらいだった。

うっすら評判悪いのは知ってたけど実際に仕事してみると尋常じゃないほど酷かった。

こっちもいろいろ対策を考えた。

Issue振るときソース上に「↓ここの○○をXXになるよう修正してください」とコメントを書いてから仕事を振るようにする、「わかりません」が来そうな部分は先手で予想して回答を載せる。

でもダメだ。こちらの対策なんてものともしないように全てを掻い潜ってくる。

もはやその人に仕事を振るのは「この作業担当してくれたら助かる」ではなく「この作業であれば流石に”わかる”だろう、そして単純作業の量が多いからしばらくは邪魔されないだろう」という感じにできる限り疑問点が少なく時間がかかる作業で”遠ざける”のが目的になっていた。

最低でもあと1年くらいは人事はこの状況らしい。。。

こういう状況ってどう扱うのがいいんだろうなぁ。

2021-04-26

anond:20210425022947

以下はあくま個人解釈から異論は認める

ドメイン駆動設計ってあくま設計手法っていうかビジネスロジックモデリングまでが本分だから

システムドメイン領域)にビジネスドメインで履いていた土足のまま踏み入ってはいけない

ビジネス理屈を一対一でシステムに持ち込むのはナンセンス

※補足追記:基本設計したら詳細設計するけども、そこでビジネスロジックシステムロジック翻訳するからコードレベルでは一対一にはならないということ

概念次元が違うのだから現実漫画理屈を持ち込むなっていうレベルの話(ビジネス漫画レベルという意味ではない)

モデリングによって現行のビジネス問題を洗い出し、それを課題として解決仕事を楽に)するのがシステム

それも一回で終わりじゃなくてシステム化したビジネスを再びドメインモデル化して分析課題システム解決ってサイクルを回していかなくちゃいけない

 

システム側も細かいこと言えば領域が分かれてるからそれぞれの領域に合わせて駆動方法は変えなきゃうまく回らない。

データレイク周りならデータ駆動型の方が適しているし、逆にアプリケーション側でビジネスUX無視してデータ主体で走るのは阿呆所業だし、

馬鹿の一つ覚えで〇〇駆動設計だの開発だの一本槍でパワープレイするやつが多すぎなんだよ! 適材適所って理解しろよ!

ちゃんと各分野のスペシャリストを雇って意思決定層に組み込んだ方が結果的時間や金なんかのコストが少なくなるよって話が通じないよね

2021-02-10

依存性逆転の法則理解した気がする

抽象依存するってことなんだよね。発想が抽象的でむずかしい。

以下に示すbeforeコード欠点は、IOに関係する部分とビジネスロジック(誇張)が密結合していることで、このメソッドを変更する理由複数存在している点である。(単一責任原則違反)

変更理由は、IOにnullが入ってくることを考慮するとか、暗号化アルゴリズムを変更するあたりがぱっと浮かんだ。

afterのコードは、readerwriter引数から受け取れるようになっていて、インターフェース依存するようになって、単一責任原則を守るようになった。

```

# before

def encrypt

while char = readChar do

writeChar(trunslate(char))

end

end

# after

def enctypt(reader, writer)

while char = reader.read do

writer.write(trunslate(cahr))

end

end

```

まとめ

インターフェース依存していこうな。

2020-12-24

善悪を超えて

Smoozという国産ブラウザアプリサービスを終了して、私はなんだか無性にイライラしてしまった。

WEBセキュリティを専門としないので関連記事ざっと見た感じだと、

といった感じが主とした批判理由で、批判記事が書かれた数日後、アスツール社は利用規約を変えるでもなく、サービスの一時停止でもなく、サービスを終了させた。

私のイライラの原因に、登場人物は4人いる。

Smoozを開発したアスツール社、

批判記事を書いたreliphone、

mala氏、

そしてお前ら

reliphoneへ

最初あなた記事を読んだとき、私は「こんな中華アプリみたいな情報ぶっこ抜きブラウザアプリを作るなんて、なんて腐った連中なんだ」と思いました。あなた情報小出しに勝負する様は見ていて気持ちよく、私が明るくないセキュリティに詳しいこともあって、あなた正義の見方に見えたのです。

しかし、Smoozがサービスを終了させたと聞いて、私の態度は一変しました。もしアスツール社がmala氏の言うような"面の皮が厚い連中"であったなら、最初に取る一手は利用規約を変更して、なんだかんだ理由をつけてサービスを続けるだろうと思ったからです。しかしそうではなかった。

スツール社は、アプリ使用者に「セキュリティ問題が起きたので使わないでください」というポップアップを表示する機能実装させ、ストアから削除し、サービスを終了させました。

もしかして邪悪情報売買事業者は、存在しなかったのではないでしょうか?

なぜあなたセキュリティに詳しいにもかかわらず、IPAに報告もせず(してたらごめんね)、アスツール社に報告をせず、初手でブログで開示という方法をとったのでしょう?

それはセキュリティ界隈のキャリアアップ方法が、既存サービス脆弱性を見つけて、それを指摘しSNSブログでバズらせて名を上げるという戦国時代のそれだからでしょうか?(心あたり多すぎですね?)

それとも情報セキュリティマネジメント試験には、「問:脆弱性発見した場合、これ以上被害がでないために何をすべきか」「答:SNSブログでバズらせてサービスを停止させる」という問題が出題されているのでしょうか?

不思議なことに、私の怒りはアスツールから一変、あなたに向けられることになりました。

malaさんへ

私は、このmalaさんという方が「アスツール社に脆弱性報告をしている」というのを見て、正直感しました。

なぜならセキュリティ界隈の人間戦国時代武将なので、脆弱性を見つけるや否や、スクショをとって「ここがまずい」「ここがやばい」とSNSに連投したり、なんの権限もないコールセンターとのやりとりをブログでバズらせる人ばかりだと思っていたからです。

しかし考えてもみれば、まじめに脆弱性報告をする人は目立たないのです。私はteraailでこまめに回答を書いている徳丸某氏活動には目を向けないくせに、声のでかい戦国武将活動ばかり目を向けて、セキュリティ界隈はクソだと思っていたことを恥ずかしく思いました。

しかmalaさんの以下の文言を見て、私はそれどこらではなくなりました。

似たような要件仕様が上がってきたら、多くの開発者が同じようなことをやるだろう。 上から目線評論家気取りでこれは酷いなどとのたまうばかり、火事場を外から眺めて他人事自分のことは棚に上げ、 人のふり見て我が振り直しもしない、お前もお前もお前も、漫然とインターネットをしている醜い卑しい下賤の生き物ばかり。なんとかしてくれ。

私はかつて「時間と金」を理由に、数年後に爆発する時限爆弾を見て見ぬ振りをして開発をしたことを思い出しました。そして爆発の火中に巻き込まれるのを恐れて転職しました。

そうです。私は自身仕事ぶりには棚を上げるくせに、はてなブックマークであがってきたインシデントには人一倍敏感な棚上げクソ野郎だったのです。しかmalaさん、毅然インターネットをするには人生は短すぎて、人類繁栄しすぎていますインターネットビジネスチャンスの宝庫で、殆ど人類の関心事は他者を出し抜きそのチャンスを掴むことにあります。当然、注力すべきはビジネスロジックで、セキュリティ二の次になりますあなた記事ブクマして偉そうなこと書いてる技術的に聡明な人とは違って、私のような凡人は、 あなたの書かれている脆弱性手法意味をまったく理解できていないし、関係ない話ですが機械可読性に配慮して文章を紡ぐという必要性すらも感じていません。ただ1週間の残った2日でどう人生を輝かせるかで価値が決まる人生を歩いているのです。

あなた文章を読んで、自分自身にも怒りが沸いてきました。真にクソなのは、棚上げ転職逃亡クソ野郎自分自身だったからです。確かに私はインターネットも、人生も、漫然と惰性で生きている。しかしだからといって、どうすればいいのか。ビジネス意思決定権は自分以外にあり、私にできることといったら、せいぜいが静観を決め込むぐらいだ。

残念だったのが、あなたが reliphoneに暴言を吐いたことです。セキュリティ界隈には強い言葉反論をしずらくし周りを萎縮させる重鎮が鎮座していると思っていましたが、あなたもそれになっていることです。漫然とインターネットをしない先がそれなら、蛇の道ですね。

スツール社へ

まず、私がアスツール社を知ったのは、はてブにSmoozの記事があがってからでした。

そこで私は「なんて非道アプリだ。許しておけぬ」と思い、代表取締役名前検索し、クソ野郎の顔と名前を覚えたぞ、しししと、汚い笑みを浮かべました。

その数日後、Smoozがサービス終了したとアナウンスがあり、私は驚きました。それと同時に、貴社の情報ぶっこ抜きアプリが、果たして本当に悪意によってなされたものかと考えを改め始めました。

貴社のやりたかたことは、広告収益をあげたかったので、そのために記事からキーワードを引き抜いてユーザに合った広告を出したかっただけなのでしょう。すべてのユーザがハナから有料ユーザになってくれればこんなビジネスモデルにする必要はなかったのかもしれないが、そんなことは起こりうるはずもないので、無料ユーザからは本文テキストをぶっこ抜いて、DOMをいじって広告を挿入する。これはいいアイデアだと思ったのでしょう。

今では私も同意します。これは完全にいいアイデアだ。

私も中小零細企業で働いたことのある身。凡人の自分が考えたアイデアなんて世の中にはたくさんあって、思いついたアイデアはどれもこれも上司リジェクトされる、特許で押さえられていた、法律的にアウト寄りのグレー、なんてのはありふれた話だ。会社員歴十何年の人間が、赤字部署で一度も利益を上げたことがなく嫌気が差しついには退社し増田に入り浸る、というくらいありふれた話だ。

から、多少の通信の秘密暴露がなんだというのでしょう。これは開き直ったギャグでもなんでもなく、真面目にそう思います

そうでもしないと大企業に勝てないし、潰される。あらゆることは大企業占拠している。中小ベンチャー企業にとって、それをかいくぐったビジネスモデルは死活問題だ。たとえそれが法の穴でも……タックスヘイブンで何兆もの税金を現地に還元していない大企業脱法行為に比べれば、可愛いものじゃないか

私は、設立2016年資本金1億の凡百弱小スタートアップ企業である貴社を応援したくなった。

ふてぶてしくサービスを続けてほしかった。私は クソ野郎なので、そのときはもちろん 貴社 を批判をしているだろうが、SmoozはかつてのLINEのように批判されながら成長する余地があったのではないか、という気がしました。

貴社のような弱小凡百無名スタートアップ企業セキュリティ人材を雇うのは難しいでしょう。優秀なセキュリティ人材も、 貴社を目にも止めなかったでしょう。もしかしたら、国内ブラウザの開発という、一種エンジニアの憧れを源泉にビジネススタートアップにした時点で、そのフロントエンドの複雑広大なドメイン知識キャッチアップしきれるはずもなく、セキュリティ二の次にするスタートアップ企業である貴社は必敗が約束されていた……と考えるほど、私は人の夢を悲観的に捉えてたくないのですが、やはり生き残るには、批判を跳ね返す強靭なメンタル必要なのでしょう。たとえ瑕疵が貴社にあったとしても。 "面の皮を厚く"せねば生き残れないなら。

それとも貴社は、本当は邪悪情報売買事業者で、さっさとトンズラこいたのか?

「さっさとトンズラ」なんて簡単に言ってくれる。そうですよね?

お前らへ

どっかの誰かに「漫然とインターネットをしている」とキレられたお前らへ。

はてブに聡慧たるコメントを残している皆様におかれましては、Smoozとかいう弱小ブラウザが、他ブラウザであるSafariChrome、諸Microsoft製品、その他製品諸々と比較していかevilであるかをご存知でしょう。

どんなページを見ているかがアスツール社に筒抜けであるのは嫌ですが、どんなページどころか年齢、性別検索履歴、趣味嗜好、各サービスアカウントパスワード大企業たるGAFAM様には筒抜けでも一向に構わない、という理由けがあなたの中にあるということです。アスツール批判していてLINEやってる人はいないですよね?それとも最近LINEクリーンイメージからもう大丈夫、と自分を納得させましたか

ところでChromeパスワード管理機能はすごくて、どの端末で開いても、Chrome自身アカウントログインすればその機能が使える。つまりパスワードサーバ管理されているというわけです。たとえ同期パスフレーズデフォルト有効ではなくても、Googleグローバルビッグカンパニーでnot evilなので、情報を売るなんてセコい商売をするわけがないとハナから信頼されているからこそ許される行為なのです。

Google閲覧履歴を少しずつわからないように販売している 」という発想に私たちがならないのは、Googleはそんなことしなくても事業成功しているからなのですが、「実はその心理的死角をついて」「裏をかいて」という発想すらもならないのは、やはり単純にGoogleビッグすぎるからでしょう。一方、弱小貧弱キングボンビーである中小零細企業は、少しでも怪しい所があれば、単純な知識技術不足 というよりも (弱小企業ゆえにこっちのほうがありえそうな話だとしても)、「あたりまえのように」悪意を疑われてしまます

結局、Google邪悪情報売買事業者ではなく、アスツール社は邪悪情報売買事業者で"ありうる"、という判断あなた脳内で線引きされるのは、単にアスツール社が弱小凡百零細の聞いたこと無い企業であり信頼が足りない、ということ以外に理由はなく、Googleがやっている「検索履歴やキーワードから適切な広告を表示している」というのが想像以上にドラスティックで大規模にもかかわらずグローバルスタンダードになっているので、それに比較して アスツール社が「本文をぶっこぬいて送信しているから怪しい」というのは、「やり方がせこくて本流ではなく、マナーがなっていない」程度のものしかないわけです。つまり私はマナー講師が嫌いなので、マナー講師たるお前らに腹が立っているわけです。

許せないやつはどいつだ

四者四様、いや自分を含めたら五者五様に怒りが沸いてくる。これは理不尽な、行き場のない怒りだ。大企業不祥事書類送検だが弱小企業社長懲役刑になるような理不尽さを見たときの怒り、自身の棚上げ癖と、過去爆弾を思い出したこと、それを指摘されたように感じた羞恥に似た怒り。界隈のキャリアアップ方法が、受け入れがたいにも関わらず常識になっていることへの怒り、自己矛盾、考えがまとまらない怒り……私には世界がわからない。ビジネス成功したためしがない。セキュリティもわからないし、なんなら上手な人間関係もわからない。アスツール社が邪悪かどうかの真実もわからない。ただ開発者気持ちはわかる。あの頃、やばいね、ああやばいねと隣の同僚と話していた頃を思い出す。今、Smoozの開発者の席に、私がいるような気がして、それを考えると、全ての善悪を超えて、みんな許してやってくれんかね、と思うけれど、そういうわけにはいかないだろ、とイライラが一向に収まらないんだ。

2020-11-03

anond:20201030201448

できない奴は何度言っても、データバリデーションや集計処理とDBへの登録処理を同じメソッドに書いてくるし、Viewビジネスロジックを埋め込もうとする

2020-10-22

プログラマーは何でもできる問題

DDDだとか、クリーンアーキテクチャだとか、まぁいろいろ言うんだけど、ぶっ壊そうと思えばいくらでもぶっ壊せる。

問題なのは意図的にぶっ壊していない場合

「んー、このビジネスロジックDBからあのデータ必要だなぁ・・・せや!ここでDBアクセスしたろ!SELECTだけやしへーきへーき!俺天才テストコード?なにそれ美味しいの?コミットッターンプッシュッターン」

みたいなのをどうやって止めるのか。

anond:20201022005749

よし、お前の熱い気持ちしかと受け止めた。バズるのは時間帯が悪かったと思うので、次に投稿するときには夜ご飯ぐらいがいいよ。それでは添削してやろう。

継承はだめ、という主張はわかるぜ。継承ネストが深くなるとメンテナンス性が落ちるし、習い初めのバカ勝手クラスを使うからな。これは同意する。

そう、昨今の業務では継承とか使わない方が良い。何故か?フレームワーク上でビジネスロジック記載する時代からだろ?でもな、そのフレームワーク自体テンプレートパターンといったパターンが満載で、アスペクト指向を介してログ排出しているのよね。まぁ、素人継承を使わせるのはキチガイ刃物なのは事実だが、今という時代フレームワーク刃物ラップできている時代だと思えば、悪くないと思うよ。うん。

リスコフの置換原則は、継承したメソッド上下で型の変化を無くせ、というだけだろ?それは、ちょっと能力検定には弱いよね?SOLIDの原則について調べてみよう。

無闇矢鱈に継承を使うな、というのは正しい。だけど、禁止する程ではないと思う。

2020-10-08

ブロックチェーンとは何か。

ブロックチェーン暗号通貨、Web3.0、Dweb というのはここ数年、そしてこれからバズワードであるようだ。

ここ一週間ぐらいだろうか。マイナンバーブロックチェーンを導入しようとしている事業に関して色々な議論が発生しているようである。例によって議論に向かない Twitter 上で発生している。というか何が議論の中心になっているのかイマイチよく分からない。ただ雑然と荒れているという感覚がある。

私は技術歴史文化といった面からブロックチェーン暗号通貨に対して知識がなく、学び始めたのはここ一ヶ月と言ってもいいだろう。学ぶ、といっても転がっている日本語一般的メディア記事を気が向いたときに読み散らかすぐらいである。真に技術的なことは何一つ分からない。暗号通貨Bitcoin とEthereum しか知らないし所持しているのはたまたま貰った僅かな ETH しかない。金銭的に貧しい多摩川に転がっている石くらいどこにでもいる17歳JKである。と逃げの文言を置いておく。

発端

議論の発端はここらへんからだろうか。

加納裕三 (Yuzo Kano)(@YuzoKano

囲み取材で数十秒話したこと記事になっているので、正確に伝わって無さそうです。

マイナンバーカードをいずれカード不要にしてスマホインストールできるようにしたい

・(ただ法改正必要)

・その前にそもそも、普及のためマイナンバーカードの発行総数を増やす必要がある

という趣旨かと。

https://twitter.com/YuzoKano/status/1312245723048550401

加納氏のこの時期のタイムラインから現在に向けて遡れば様々な第三者感想や疑問を得ることができるだろう。これらに纏めて答えているのが以下の記事である

ブロックチェーンの優位性①疎結合加納裕三/Yuzo Kano

https://blog.blockchain.bitflyer.com/n/n4b45329e308c

ブロックチェーンの優位性②改ざん耐性|加納裕三/Yuzo Kano

ttps://blog.blockchain.bitflyer.com/n/naa0126a024d5

加納氏とは一体何者なのかは以下を参照。

東京大学大学院工学研究科修了。ゴールドマン・サックス証券会社入社し、エンジニアとして決済システムの開発、その後デリバティブ転換社債トレーディング業務従事

2014年1月株式会社bitFlyerを共同創業し、2019年5月株式会社bitFlyer BlockchainCEO就任

bitFlyer創業以降、法改正に関する提言自主規制ルール策定等に尽力し、仮想通貨交換業業界の発展に貢献。

日本ブロックチェーン協会代表理事ISO / TC307国内審議委員会委員、官民データ活用推進基本計画実行委員会委員

2018年G7雇用イノベーション大臣会合2019年V20 VASPサミットに出席。

ttps://finsum.jp/ja/2019/speakers/recQMoKK5nD9yb8Ht/profile/

ブロックチェーン定義

ブロックチェーンを語るうえで何が重要かというと、その言葉定義である議論に参加している人が同じ言葉を使っているのに、各人の言葉に対する定義が異なっていると、言葉理解できるが内容が理解できないといった状況に陥ってしまう。このことは実生活でも頻繁に起こっているように思えるが、Twitter という短文が好まれプラットフォームでは著しくないがしろにされ不毛な議論を生む原因になっている。

加納氏が代表JBA日本ブロックチェーン協会)に依ると、ブロックチェーン定義は以下の内容である

ブロックチェーン定義

1)「ビザンチン障害を含む不特定多数ノードを用い、時間の経過とともにその時点の合意が覆る確率が0へ収束するプロトコル、またはその実装ブロックチェーンと呼ぶ。」

2)「電子署名ハッシュポインタ使用改竄検出が容易なデータ構造を持ち、且つ、当該データネットワーク上に分散する多数のノードに保持させることで、高可用性及びデータ同一性等を実現する技術を広義のブロックチェーンと呼ぶ。」

定義策定アプローチ

まず、Satoshi Nakamoto論文およびその実装であるビットコインブロックチェーンオリジナルブロックチェーン(以下「オリジナル」)として強く意識しています

狭義のブロックチェーン(定義1)は、オリジナル意識し、それが備える本質的で不可分な特徴を捉え、言語化しました。

広義のブロックチェーン(定義2)は、昨今〜今後の技術の展開を鑑み、オリジナルが備える特徴であっても、別の実装方式や別の目的への展開などにおいて、置換や変化が行われていく広がりを許容しながらも、特徴を捉えられるよう、言語化しました。

http://jba-web.jp/archives/2011003blockchain_definition

総務省のページも見つけたが JBA定義するものを基礎としている。

ttps://www.soumu.go.jp/johotsusintokei/whitepaper/ja/h30/html/nd133310.html

私が疑問と漠然としたモヤモヤ感を抱くのは、最近一般層で使われているブロックチェーン定義には「信頼できる第三者不要である」という点が抜け落ちているように思われることだ。非中央集権SNS暮らし脱中央集権を推進したい私にはこの点が"ブロックチェーン"の一番重要な点であると思うが、JBA第一定義にはこの点が記載されている。不特定多数へのインセンティブによって不特定多数による合意形成している。これによって「信頼できる第三者不要である」は満たされている。

では ISO定義を見てみる。

blockchain (3.6)

distributed ledger with confirmed blocks organized in an append-only, sequential chain using cryptographic links

Note: Blockchains are designed to be tamper resistant and to create final, definitive and immutable ledger records.

distributed ledger (3.22)

ledger that is shared across a set of DLT nodes and synchronized between the DLT nodes using a consensus mechanism

Note: A distributed ledger is designed to be tamper resistant, append-only and immutable containing confirmed and validated transactions.

https://www.iso.org/obp/ui/#iso:std:iso:22739

ISO定義によれば、ブロックチェーンは、暗号化リンク使用した一連の鎖で、追記のみで構成された確認済みブロックからなる分散台帳を指す。改ざんに強く、最終的で確定的で不変の台帳記録を作成するように設計されている。分散台帳は、一連の DTL(分散台帳技術ノードで共有され、合意メカニズム使用して DTL ノード間で同期される台帳である確認された有効トランザクションを含む全てが、改ざん耐性、追記のみの不変性を持つように設計されている。

比較

さて、加納氏の投稿やその他の加納氏に批判的/賛同的な人たちの反応を見ても、彼らの言っている内容がブロックチェーン定義を満たすものなのかいまいち分からなかった。

加納裕三 (Yuzo Kano)(@YuzoKano

ビザンチン耐性(BFT)

改ざん耐性

・高可用性(単一障害店の排除

アドレス(~=公開鍵)による疎結合の容易さ

エンタープライズ間でのデータ共有の容易さ

私はブロックチェーンの主な利点はこの5つ(ただし5つにだけではない)だと考えています。これをここでは5大利点と呼びます

なおかつ、この5大利点を概ね満たしているものブロックチェーンと呼んでいます(ただしブロックチェーンと呼んでいるものは、すべてこの定義だとは言ってない。かつ、ブロックチェーンの厳密な定義はこれではない。)

https://twitter.com/YuzoKano/status/1313247738503426048

ttps://twitter.com/YuzoKano/status/1313248174430019584

なぜ前提として厳密な定義加納氏の言葉説明せずに、勝手加納氏が定義した内容を”ブロックチェーンである”と語っているのか理解に苦しむが、加納氏の説明したい"プライベートブロックチェーン"を ISO定義を基に判断すると、


"パブリックブロックチェーン"で考えると


加納氏の上記の2つの投稿からは、"プライベートブロックチェーン"と"パブリックブロックチェーン"のどちらを指しているのか不鮮明ではあるが、note記事では"プライベートブロックチェーン"を想定している、と明記されており、議論の発端となったマイナンバーブロックチェーンに関しても"プライベートブロックチェーン"を指していると思われる。5大利点を満たす"プライベートブロックチェーン"は存在しないのでは…。

面白い記事

3つ面白い記事をみつけた。

"一方で、誤解と批判を恐れずに書けば、ブロックチェーンBitcoin論文に端を発するものであるとするならば、いわゆるプラベートブロックチェーンやコンソーシアムブロックチェーンと呼ばれているものは、ブロックチェーンと呼ぶのをやめて、「タイムスタンプ2.0」のような別の言葉を使うことも考えてはどうだろうか。それは、これらの技術が、リンクトークンタイムスタンプデータ構造の上に、決められたノードによる合意アルゴリズムを加え、記録した情報に対するビジネスロジックに応じた情報処理を加えたものであるからだ。根っこの技術は、同じHaberらによるタイムスタンプを元にしているものの、ブロックチェーンの発端となったBitcoin論文が目指した「信頼できる第三者機関を不要にする」という方向とは別の方向の進化をしているもので、その別の2つの方向のものを同一の枠で扱うことには無理があり、理解や発展を考える上で両方にとって弊害がある。"

タイムスタンプの再発見と「いわゆるブロックチェーン

https://link.medium.com/TgeOXv8Dlab

DLTブロックチェーン、DAGの違い

https://link.medium.com/4pz5oNlHpab

ビットコインじゃなくて、ブロックチェーンに興味がある」という人に教えたい「ブロックチェーン」の語源の話

https://www.coindeskjapan.com/10953/

これらの記事を読むと、そもそもブロックチェーンと呼ばれるものにおいてパブリックではないものは、なんびとも信用しない状況において根本的に非改ざん性を保障することができないのではないかと感じる。"パブリックブロックチェーン"こそがブロックチェーンであり、他のものブロックチェーンから発展してきた技術を使ったブロックチェーン定義を満たさな分散台帳なのではないか

終わりに

加納氏に関して覚えておきたいことは、彼は bitFlyerCEO であり bitFlyermiyabi という"コンソーシアム・プライベートブロックチェーン"を開発しているという点だ。当然行政に対して彼がブロックチェーン推しているのはこれを売り込むためなのであろう。これが厳密にブロックチェーンなのかは置いておいて、このプロダクト自体は素晴らしい取り組みだと私は感じる。デジタル化によって今までの煩雑手続き簡単になる可能性は大いにあるし、公的文書の保存にも役にたつ。黒塗り秘匿文書を撲滅しろ

ただ、ブロックチェーンをただの空虚バズワードとして扱うのではなく、厳密な定義の上で使うのは大事なことだ。今回の件は、果たして全てにおいて加納氏が良くない、と言えるのだろうか。言葉というのは多数が使うことによって定義が決まる。時代が変われば定義が変わってしまうこともある。ブロックチェーンという言葉を便利な魔法言葉にしてしまったのは誰だろう。本質を見極めない我々だ。AI 搭載!!といたるところで見る言葉だが、何をもって AI と呼んでいるのか不思議になる。実際のところ今まで"システム"と呼んでいたものなのに。日々の中で言葉をしっかりと見つめ直すのは大事だ。

編集後記

この記事は、そもそもブロックチェーンとは何か、という個人的な疑問をまとめたものであり、加納氏を批判する意図は無かったわけで、最後の締めはやんわりとしたかった。だが、加納氏は立場的には日本ブロックチェーン協会会長で、言葉定義する立場である言葉定義した側がこの有様というのは遺憾である日本行政デジタル化の推進は頑張って欲しい。

URL を貼りすぎたせいなのか投稿できなかったので一部表記を削った。

2020-10-01

機能の利用可・不可を、画面上でグレーアウトしたりして頑張って制御するのは

かなり無駄な事なんじゃないかと思えてきた。

よほど「間違えて使ったらガチヤバい」ような機能はともかく、そうでもないものは、だいたい利用可にしときゃいい。

そんで一旦ビジネスロジックでチェックして「この機能、一応規定では利用不可だけど、本当に使う?」と警告を出したらいいんじゃないの。

メリットとしては、まずUI要素の実装は楽になるはず。

ユーザ毎の画面が違ったりしないので、サポートも楽になるはず。

ビジネスロジックで利用不可と判定した根拠ログに残しやすいし、ユーザからの問い合わせにも答えやすくなる。

と思ったけど、メリットなんて微々たるもんかなあ。

というか下手な実装にすると逆に手数が増えるか・・・

2020-09-30

ビジネスロジックをストアドにするのはメリットもある、という意見もあるが

俺はやっぱりストアド嫌いだ。

デバッグもままならない。

ログ出力機能限界があるから、何かが起きた時に、何が起きたのか追いにくい。

アプリサーバCPU冗長化しててスカスカだが、DBサーバ冗長化しにくいしCPUパンパン

デメリットのやばさがガチ。俺これはいいアイデアとは思えないな・・・

2020-04-02

Golangの良さがわからない

言語仕様シンプル以外のメリットあるか?

貧弱な抽象化サポートのせいでビジネスロジック記述に集中したくても、プログラム制御がどうしても入ってくる。

2019-08-07

anond:20190807204928

フロントって何で議論ビジネス視点価値が薄い事に、延々と貴重なリソース突っ込むの?他にやることないんじゃないかと思うけどどう思う?

例えばバックならカネに絡むビジネスロジックやらインフラやら無限事業収益に直結するようなタスクがある。

フロント暇してるならバックおいで。今すんげぇ儲かるよ。あとAI周りはカネだけじゃなくてやりがいもあって、めちゃくちゃ面白いよ!

2018-08-08

IT華やかなこのご時世に、プログラム言語覚えさせて子どもの手に職??

ロジカル思考態度は大いに役立つと思う。

が、もともと言語まわりは盛衰激しいし、AIに解析させて蓄積した定型句組みあわさせれば、どころか、すでにクラウド上などでプログラムレスビジネスロジック組めるし、これから食っていけないだろ。今でさえ世界4位の移民大国なのに、経団連により移民大幅解禁されるし、あと3〜5年でもしたら、消化試合以外の求人は激減しそうだな。

消防厨房でも、アプリ上梓しているらしいものね。

2018-01-23

https://qiita.com/klriutsa/items/8d7381f437c225c64a5f

Rails界隈よく知らないが、ビジネスロジックオブジェクトの責務ってのに分解するのは、平均レベルエンジニアには難しいと感じるよ。

ModelDBテーブル対応する、複数Modelが絡む処理は業務名前を冠したServiceにまとめるってのが、迷うこと無く整理できて、担当者が変わっても一貫性を維持できる丁度いいところだと思ったんだけどなあ。

俺のいる組織レベルが低いせいだって言われると、返す言葉も無いけどね。

2017-10-07

アメリカでは個人事業主の「民間軍事会社」が無数に存在する

変な話だが早い話、傭兵ってやつだな

アホのネトウヨや訳知り顔のミリオタ日本ではまるで軍事技術は超高度な専門職から一般人が片手間で身に着けられるはずがないとかたわけたこと抜かしているが(チキンホークの分際で徴兵制の話になるとその理屈で逃げるからしかないわけだが)

かに自衛隊普通科でも、前期教育が三か月、後期教育が三か月だ、しかしこれは破格と言っていいくらい訓練に時間をかけている

世界最強のアメリカ海兵隊は、前期後期を合わせても3か月ギリギリあるかないかくらいの訓練期間だ、アメリカ陸軍医者とかパイロットを除いて歩兵に絞れば全部合わせても3か月だ。

訓練内容をさらに絞って、ネトウヨや、学校職場テロリストが占拠してやっつける妄想してるみたいなイキリオタクの陰キャが血眼にして知りたそうな個人戦技だけを絞ってみても、銃の分解手入れ、安全な取り扱い、撃ち方や構え方、付属の機材や武器使用法、タコつぼ掘り、格闘の型を軽くして、あとは銃剣格闘手榴弾の使い方と投げ方、野戦戦術、室内での戦術(手榴弾放り込んでクリアリングしながら撃つだけ!)応急処置といったもので、あとは腕立て腹筋ランニング、といった具合だ、ハッキリ言ってプログラマーやSEの方が覚える内容が高度で多いというレベルなんだな(軍隊のものを悪くいっているわけではありません、あしからず

さてここで思ったこと、今の日本はもはや雇用慣行から商習慣が崩壊寸前のグダグダブラック化が超加速してるわけだが、アメリカのこういうった「個人事業主傭兵」のようなビジネスロジックモデルを輸入して広まったらどうなるだろうか?

まあ、一億総テロリスト時代の幕開けやで~、ヘタすりゃ1970年台のイタリアみたいになるかもな

そうならないように自民党警視庁ははよ今よりももっとネトウヨを育成して、アホ軍事理論叫ばせてそんなことがネットで語れないほどに涵養させた方がええでんがなまんがな

まあ、この不景気どころか国が傾いてるご時世に、のんきにネトウヨやってくれる底辺なんてそうそう見つからない時代になってきてんだろうけどな

2017-08-26

https://anond.hatelabo.jp/20170826215152

紹介料というか「派遣会社あなたを失うことで今後収益を上げることができなくなることに対する補償金」だね

違法だったはずだけどな、まあクソビジネスロジック的には妥当性のある迷惑料だ

それ自体あなたには関係のないことだからそこで起こるのは筋違いではなかろうか

給与社風業務その他待遇に不満なら正社員は蹴ってもいいかと思うけど、年齢スキル鑑みて後悔のないようにね

2017-05-21

外注を使えない会社はいずれ滅びる

IT系コンサルをしてて思うのが、今自分たちでやらなきゃいけない事が何か?を見失ってる会社がすごい多いこと

半分愚痴だけど書いておく

俺たちでもできる事だから外注しないという思考停止

いや、だからこそ外注しましょうよ

Windowsサーバグループポリシー設定とかVLAN設定とかアカウント発行業務サーバメンテナンスパッチetc..

これあんた達が本当にやりたかったことなの?運用会社なら良いかもしれないけど開発会社だよね?

いざとなれば自分たちでできる=ベンダーコントロールやす仕事からこそアウトソースしましょうよ?

それプロパーやらせてなんか知見溜まります?まあ得るものゼロとは言えないかもしれないですが開発より優先させるんですか?

社内システムの事だから外注させるとセキュリティ心配

これよく聞くんですが、正社員から信用できて、フリーランスから信用できないってのはどういう根拠なんすかね?

最終的には人です。会社でも肩書でもなく信頼できる人を探しましょうよ

正社員じゃなくても良いじゃないですか?というか経験上できる人は一人会社フリーランスの方が多いですよ昨今

その癖開発で難しいところは外注する矛盾

そんなコア業務をなんで外注ちゃうんですか?開発会社ですよね?それでお金貰ってるんですよね?

そのビジネスロジック実装把握してないとリリース対応も大変ですよ?

Ruby On Rails得意なメンバー居なくてしょうがなく。。。じゃないでしょ!トレーニングさせましょうよ

手順さえ知ってればできるような運用業務忙殺されてて、勉強する時間が取れないって本当頭おかしいですよ

開発会社なら開発に集中してください

要するにこれです

開発に集中してください

安易に「俺たちでもできるから」、「なんとなく外注するとセキュリティ的に心配から」という理由開発者雑務に費やさないで、開発させてください

開発に必要勉強をさせてください

もう100回以上こんなこと言ってるけど、年配経営者には馬耳東風なんだよな・・・

2017-04-21

プログラム日本語で書けばいい気がするけど(追記した)

定期的に思うんだけどプログラムで無理な英語にせず日本語にすればいいのにって思う。

実践はしていない)

日本語で書ける言語使うんじゃなくて変数名や関数名がUnicode対応日本語書けるもの

日本語でいいと思う理由は主に2つ

○画面に表示する時

フレームワーク言語にもよるけど表示するとき英語名前から日本語名前に変換して表示って手間があるものがある。

最近見かけた例だと.NETプロパティ属性に表示名書いて表示するときに取り出していた。

最初から日本語だとそのまま表示でいいことが多くて一段手間が省ける

英語がわけわからん

まず自分英語化するとき

いい単語が出てこないとか、しょっちゅう

慣れが必要だし慣れてもなんかコレジャナイ感とかで苦戦する。

次に他の人の英語化したのを見る時。

その人の英語力にもよるけど、動詞名詞が変に混ざっていたり、sがついてたりなかったり、そもそもchildsみたいな謎の語があったり。

そこそこできる人同士でも、「私はニュアンス的にこっちの単語」「僕はこの単語のほうがいいと思う」とかある。

相手の書いたところがわかりづらいのはもちろんだけど、プログラム的に同じ意味なのにクラス関数によって呼び方違うと辛い。

かといって全員に日本語英語対応を先に渡しておいて統一しようというのは大変すぎる。

日本語だと仕様の時点で日本語で書いてるからまぁおかしなことにはそうならないはず)

そういうわけで日本語で書けば色々解決するのにって思う。

----

次にデメリット

軽く調べた感じ主にこの2つな感じ。

IME」「英語圏のものへの対応

IME

半角全角を打つのってめんどい

と思うけど、実際チャットやこういう文章書いてて英語が出るときに割りと頻繁に押してる。

ほぼ無意識でやってて意外と苦じゃない。

短いとF10変換で半角にすることもあるけど、キーボードタイプカウンタとか入れてみると半角全角キーはけっこう上位にいた。

それに、なんだかんだコメント日本語で書くことが多くて、他の人と作るのならこまめにコメント書いてる。

そうなると全角半角の切り替えは普段からあるもので、あんまり気にするほどじゃない気がした。

最近じゃIDEエディタの補完が優秀だし、日本語にするにしても「最初はjから始める」とかルール入れておけば「j」って打ってあとはスコープにあるいくつかの候補から選ぶだけで全角にしなくていいかもしれない。

英語圏への対応

githubで公開したりとかライブラリ再利用してもらうとき日本語じゃ使ってもらえない。ってことみたい。

私が日本語にすればいいじゃないって思ってるのは、ビジネスロジックというかそのアプリケーション固有名詞みたいなところ。

「足し算」って関数名は 「add」 でいいと思うし、配列のそれぞれは element とか item とかそういう一般的英単語でいいと思う。

具体例がいいづらいけど、業務システムで表示する金額名前とか、日本語独特なものとか、一般的単語じゃなさそうなの。

こういうのを日本語にしたいってわけなので、ライブラリ的な共通なところは英語で良いかgithubで公開する範囲英語のものでいいと思う。

ただ、最近はやってるマストドンとか、ライブラリ的なものじゃなくアプリケーション自体githubで公開する場合はできない気がする。

でも、海外対象にしてるものだと日本語特有なせいでわかりづらい英語になる苦労とか少なそうだしそういうのだと英語いいんじゃないかな。

----

長くなったけど、まとめると、

業務システム固有名詞とか日本語特有ものとか無理に英語化してよくわからないことになってり、見づらくなるくらいなら日本語使えばいいんじゃないかな

ということ。

まあ思ってる割には実践してないので、やってる人がいたら良かった・悪かったとか聞きたいなと思ったのが書いた理由

追記


帰ってきたらすごいブクマついてた。

色々意見あってとりあえず感謝

絶対自分でやってから言えよ」みたいな意見来るだろうと思って今日の空き時間日本語行ける言語調べたり軽く日本語使ってコード書いてみたので、そのあたりと目についたコメに答えてみる。

まず、思いの外日本プログラミング言語上げてる人がいたので、うまく伝わってなかったぽい。

具体例上げずにサッと書いたらからかな。

あと自分もわりとするけどタイトルだけ見て中身見ずにコメントしてた人もいるだろうなー。

日本語で書ける言語使うんじゃなくて変数名や関数名がUnicode対応日本語書けるもの

これが、などしこやひまわりや、BF系のmisaやら北斗のあれやらうにゃーとか色々な「構文など最初から日本語を前提とした言語」ではないってこと言ってた。

---

日本語かえる言語

最近の主要な言語ならだいたい Unicode 対応でしょと思って環境があった言語を試した結果はこうだった。

JavaScript/Python/PHP/Scala/Kotlin/C#/Go/Swift

これらは日本語変数作れた。

rust と Lua は無理だった。

rust は確か前に、変数名が ascii 文字だけなことに日本以外のどこかの国からUnicode対応にしてって多くの要望あったみたいな記事があったし将来的に対応するんじゃないかなって思ってる。

実際に今どんな状態かは知らない。

その記事コメントとかでみたけど、日本語以外は割りと自国言葉を使ってたりするっぽいね

(正確なデータはないか信憑性はあるとはいえないけど)

VBA を上げてる人がいたけど、私はそこまでのはみたことない。(幸せ者っぽいな)

稀にエクセルマクロいじるときに使い方ググってて出て来る、解説してるページで関数名が日本語なのをたまに見るくらい。

パット見なんか気持ち悪い感はあるけど、読んだときのわかりやすさはけっこう大きい。

---

○使ってみて

大規模案件に使ってみてこその問題もあるだろうけど、簡単スクリプト程度のを日本語にしてみて気づいたこと。

割といける。

全角半角キーPHP の $ より楽。

PHP言語変数は全部$からはじめないといけない欠陥言語

まあ変数のみのgrepのしやすさや予約語キーワード変数名に使えるからメリットもある。

だが、$って打ちづらい。

Shift+4ってすごいつらい。

に比べて全角半角キーってちょい遠いけどそこまで苦痛じゃない。

ふだんから多用してるキーなわけだし。

ただPHP日本語の組み合わせは相性悪い。

$は半角でその後に日本語から手間が多すぎる。

それ以外の言語だと、IMEのおかげでかなり楽。

GoogleIMEだけど、多少のタイプミスは補完で修正してくれるし、予測変換が優秀だし。

IDEいから補完機能のない軽いエディタで書くようなときなら、IMEのおかげで英語変数名で書くより速度は早いと思う。

---

少し前に知人から言われた日本語デメリットを思い出したのでそれも触れとく。

仕様変更言葉変わったとき日本語だと全部書き換えないといけないよ。英語だと別にそのままでいいし。」

英語からない人が、英語言葉とみなさずただの記号として考えてるから、っていうような発言

仕様変わって変数名まで変えるのは面倒なのはわかるけど、あとからコード読む人が英語で見て意味不明になる。

英語日本語対応コメントに書いたとしても、全然意味の違う英語があるのは混乱でしかない。

こういう考えの人がいたら本当にやめてほしい。

---

あとは気になったコメントについて書いてく。

表記ゆれとか方言とか言い回しなどについては、全部日本語にするとあるだろうけど、私が想定してるのは直感的に英語にならないような固有名詞とか。

DBの項目名日本語っていうのは私の思ってるのと近い。

年金の例も○○年金というのがいろいろあって、全部英語だと嫌になってくるしよくわかる。

こういうのを日本語にしたい。

なので年金額を取得する関数で「年金額を取得する」「年金額を取得」「年金額を取り出す」とかの表記を迷うんじゃなくて「get年金額」でいいと思う。

こういう単語だけだと表記はそれなりに揃うと思う。

特にDBにある項目だと仕様とかで先に言葉が決まってることが多いだろうし。

---

見た目について。

見た目が残念とか見づらいというのは同意

ただそれ以上に読んだときのわかりやすさが大きいと思う。

見た目が悪いというのも全部英語っていう前提があるからで1ヶ月も日本語コード見ればなれるんじゃない?って思う。

---

へとヘ

これはありそうな問題

ただ、IDEを使う前提なら未使用変数エラーとか、選択したときに色が変わってないとか、割と気づけると思う。

lとIとかアルファベットでもあるけど、IDEや高機能エディタ使うと困ることはほぼなくなった。

---

ローマ字

私が日本語にしたいような固有名詞ローマ字化してるプロジェクトにであったことはある。

やすい語は見やすいけど、見づらい語は圧倒的に見づらい。

それにローマ字のほうが「ん」でnは1つか2つかや、ヘボンorローマ?という日本語より表記が揃わない問題ある。

特にローマ字場合自分キーボードで打つ方じゃないと書きづらいのでそろえてもらうのに抵抗がある。

---

ラバゴス化・日本が遅れる

海外向けとか海外の人と一緒に作る系なものって最初から英語で困らない単語ばかりだと思う。

そういうのは対象外

今回いいたいのは、元から日本しか対応してないような業務システムなど。

そういったところの固有名詞日本語になったからって、困ることはないはず。

もともとガラバゴスなわけだし。

日本しか使われないもの海外向けにするにしてもフルスクラッチで作り直すことになるようなもの

こういうのは日本語化いいんじゃないかと思う。

---

テスト

テストだと日本語が使ってる人多いのかな?ブコメスタートップだし。

とりあえずはテストから使い始めてみようと思う。

---

長くなったけど参考になる意見もいろいろあって助かった。

2016-10-17

http://anond.hatelabo.jp/20161017164515

ビジネスロジックModelに、とかサービス層に、とか言われて、困る感じか

1画面1機能ならViewとControllerで十分なんだよね

同じ機能複数画面で提供しようとすると、Controllerに処理書くスタイルだとコードが重複だらけになるんだよね

それを共通化しようってしたときに、ソフトウェアアーキテクチャとかが出てくるんだよね

教科書としては「エンタープライズ アプリケーションアーキテクチャパターン」とかあるけど、難しいし、理解してない人のほうが多いし、人によって言ってること変わるんだよね

2016-03-27

http://anond.hatelabo.jp/20160327184113

逆に聞くけど、

「きっちりビジネスロジック分離したまともな設計

を細部まで指定してプログラマに渡すの?

それ、自分で書いたほうが速くない?

なんのために設計書くの?

http://anond.hatelabo.jp/20160327184113

そんじゃあ、中身がコピペ祭りになるか、きっちりビジネスロジック分離したまともな設計になるかはプログラマ任せって感じ?

そうだよ。

コードレビューはするの?

基本はプログラマコーダー?)同士でやってもらってる。


前提として、発注する自分コードかけるっていうのが自制心をかけているような気はする。

だけど基本は人同士のやりとりなので、お互いを信頼してあまり口出しはしないようにしている。

その最低限のラインを、自分の中で下記で縛ってる

それ以外なら、コーダーがやりやす環境がいいのは間違いないし、

しろ自分がこれじゃパフォーマンス悪そうだ、設計が難しそうだ、っていうときコーダーに聞くから

ログイン ユーザー登録
ようこそ ゲスト さん