「名前空間」を含む日記 RSS

はてなキーワード: 名前空間とは

2024-04-04

プログラム関数名やら変数名やらで頭文字1文字はやめて…

最近配属されたプロジェクト

開発中のソースを見ると、長い名前単語を1文字だけとって並べる習慣があるようだ

…それで分かるの自分だけだろ…

せめて一般的な略し方か調べて定義にするとか、もう少し細かく設計するとか、名前空間使うとかしてくれ…

まあ、誰もその発想に至らないから今の状況になるんだろうけど…

長期運用で人が流動しないプロジェクト弊害だな…

2024-03-02

anond:20240302043100

Excel作法というか極意は知らないフリだろJK

他人のことは放っておけ

たまに自然発生するExcel先生適当やらせときゃいい

作業頑張った感が出る中間ファイル生成させるとかやって、空いた時間勉強するんやぞ

ExcelVBAの後にどうせだから他のVBAもやっとくかと遊んでたら、OutlookVBA名前空間出会って衝撃的だった

会社から365移行するとか言われたんでOfficeScript触って連想配列かいう素晴らしいもの出会った

GraphAPI使って、メールも含めて仕事してるフリが出来るようになってだいぶ満足感出てきた

さぁ次は何しようかなー

2023-11-17

インターフェースを利用して名前空間ごとに処理を分ける

うーんマンダム

ここまで5年かかった

2023-10-05

anond:20231005235315

gitというシステムコミッターに日本人がいるんだけど、その人が書いたコードリーナス・トーバルズ逆鱗に触れて

「俺がかみさんに怒られるのはこんなクソコードレビュー時間割いたせいだ」と逆ギレされた事件がある

その時ちょうどレビューの議題だったのが名前空間で、aliasとかいうprefixやめろカスOS関係ないやろとリーナス中指画像送り付けた(NVIDIA, fxxk youとはまた別の中指事件)

[] その36

エイリアスって言葉今日知ったんじゃまだまだ青二才だな Linuxも使ったことないんか」

linux義務教育で学ぶべきだよね」

Linuxを知らない奴は義務教育からやり直した方がいい」

「いや名前空間概念linux無関係だが。」

2022-09-07

anond:20220907182507

問題は、生まれから幾度となくやってる9 - 3を未だに暗記できてない事なんだ。

やっぱなんか暗記できる方法ちゃんと考えるべきかもなぁ。

覚え方の名前空間が九九と被りそう。

2022-06-23

anond:20220623210948

常にグローバル名前空間に居て、常に正式フルネーム連呼とか非常にめんどくさいので

コンテキストに応じてスコープを切り替えることをしてきたわけだ

その結果、「おい、あれ」って奥さんに言うと「私の名前はおいじゃないし、あれと言われてもわからん」と答えが返ってくるようになりました

2020-12-20

プライベートメソッドテストすべきか

「すべきでない」というのがたぶん多数派

テストすべきでない理由としてだいたい次の理由があげられる。

プライベートメソッド関数テストする必要は無いと考えていますプライベートメソッドは、実装の詳細であるからです。

多くの場合、そのクラスパブリックメソッド経由でプライベートメソッドテストも同時に行えます

プライベートメソッドのテストは書かないもの? - t-wadaのブログ

ほとんどの場合プライベート メソッドテストする必要はありません。 プライベート メソッド実装の詳細です。

プライベート メソッドがある場合は、パブリック メソッドを見つけて、そのメソッドに対してテスト記述します。

単体テストを記述するためのベスト プラクティス - .NET | Microsoft Docs

プライベートメソッドテストするな」と強く主張されるのは、ケント・ベックの影響もあるかもしれない。

例えばtwitterで、パブリックメソッドにだけテストを書き、テスト必要なほどプライベートメソッドが複雑ならそれを別のオブジェクトに切り出す必要があると発言している(twitter/kentbeck)ように、プライベートメソッドテストに強く反対している。

またベックの書いたSUnit(xUnitの源流にあたる)には「ひとつテストひとつオブジェクトで表し、それによってテスト独立性を高める」というアイディアが使われている(そのアイディアを実現するためにとても複雑な設計をしている Simple Smalltalk Testing: With Patterns)。テスト自身ひとつオブジェクトとして独立しているなら、テスト対象となるオブジェクトプライベートメソッドテストできないのは当然のことになる。

しかし「プライベートメソッドテストがしたい(したくなることがある)」と感じる人も相当数いる。

そう感じる人にとってはむしろここからが本題で、

問題になる。

テストファーストで開発するなら手を動かしながら軽い気持ちで書きたい。

例えそのクラスがprivateメソッド依存関係があっても。

コンストラクタインジェクションされたクラスのprivate メソッドでもテストファーストしたい - Qiita

privateなルーチンの自動テストは面倒だ。実際にコーディングするとき最初publicにしておいてテストしてうまく動いていそうならprivateにするのだけど、この「いそう」がくせ者。いっそのことすべてpublicにしたくなる。

私は元々メソッドはprivateにしない主義なのでメソッド場合問題ないのだけれど、ファイル内の「関数」が問題になる。和了計算だと和了形判定とか符計算とか和了役判定とか単体でテストしたい内部関数が山ほどある。(twitter/koba0367)

private メソッドテストすべきか問題原則論だけだと袋小路に入りがちだから、private メソッドテストしたくなる具体的な場面について議論したほうがいいと思う。

自分レビューでよく見る例としては、複数の public メソッドの重複部分を private メソッド抽出した結果、濃い private メソッドと薄い public メソッドが一対多関係になる場合が挙げられる。設計としては間違っていないし、わざわざ public メソッド経由でテストする意義があるかというと微妙。(twitter/ts7i)

きれいなインターフェースを作ろうとすればするほどpublicメソッドじゃない部分に複雑性を追いやることになり、壊れた時に手戻りが大きすぎると思ったら、プライベートバックドア開けてでもテスト書くようにしてます (twitter/mizchi)

しかプライベートメソッドに対するテストを書こうとすると大概リフレクションなどで可視性の制限をすり抜けるとかメソッド可視性を変更するといった回りくどさやコストの導入が必要になるので、じゃあプライベートに対するテストはそうしたコストに見合うのかが問題になる。

伊藤さんの答えは「原則書かないほうがいいという大前提のうえで、どうしてもというときは、"これはテストのためにpublic"にしているというコメントの上でpublicにする」だった。

自分は「テスタビリティのためにメソッドをpublicにする」っていう"実プログラム挙動を変えること"の方が、「privateなメソッドテストコードのみsendで叩く」よりも怖いって思ってることに気がついた。(twitter/highwide)


メソッドプライベートパブリックかという話とそれをテストするかどうかは別問題だろという意見もある。

単体テストホワイトボックステストだとするなら、publicかprivateかでテストの有無が変わるのは明らかにおかしいだろ。ややこしいロジックはprivateに隠蔽すべきだが、そこがテストできないなんて。 (twitter/kmaebashi)

private メソッドテストするかどうか? まず最初に言っておきたいのは public/private は抽象設計問題であって、テストすべきかどうかとは当然無関係だろうということ。(twitter/qeigoi)

特定言語の貧弱な機能思考制限を受けて誤った結論を出している典型的な例。

"テストを書くべき"と"上位層から可視性"は直交する概念

https://b.hatena.ne.jp/entry/4684049296462116226/comment/megumin1

テスト粒度メソッドアクセス権は独立したものなので、「プライベートメソッドテストすべきか否か」という切り方自体ナンセンスではあるのだが、現実問題としてはアクセス権がテストに影響するので難しい。(twitter/AoiMoe)

private メソッドテストはすべきかどうかというより、「できるべき」であって、それができないというのも、ある種、言語機能テストインピーダンスミスマッチと言えるのではないだろうか、と思っている。(twitter/aetos382)


プライベートメソッドテストがしやす言語での意見

RustやGoではプライベートメソッドに対するテスト簡単にできる。

そのためかプライベートメソッドテストすることに対して拒否反応があまりないようだ。

Rustのテストファイル内とtests/以下の2箇所に書ける。

テストには開発用のホワイトボックステスト仕様確認用のブラックボックステストがあり、前者をファイル内に、後者をtests/に書けば良い。

例えば度々議論になるプライベート関数テストについてはもちろんホワイトボックステスト。(twitter/blackenedgold)

Rustではプライベートに対して何の手間もなくテストが書ける。

概念的にはプライベートに対するテストは外部コードではなく内部コードの一部として見るべきなのだろう。

Rust入門を兼ねてプロジェクト・オイラーの問題を解く - 再帰の反復blog

Rustでprivateなメソッドテストを書きたいなら、そのメソッドのすぐ隣に書けば内部アクセスになるから普通に書けるよ、ってのは目からウロコだった。できるだけ近いところにテストを書こうっていう文化と相まって最高。(twitter/kuy)

Rustみたいに単体テストは同ファイルに書ければいいのに

assertionチックにprivateメソッドのすぐ下にテスト書きたい

ドキュメントにもなるし (twitter/takaya_tim)

Rust のようにユニットテストプロダクションに混ぜる方式はおれもいいと思ってて、テストプロダクションを分離することで private 関数テストができない問題があるけど(テストしたければクラスを分けよ/メソッドを公開せよ/テスト必要なし、に分かれるよね)、そもそもこの議論不要になるよね (twitter/nunulk)


go言語だとプライベートメソッドテスト普通にやりますね。(twitter/mattn_jp)

昨日「private method の単体テストは書くか否か」という話題がちょいとあったのだが、わしは当然書く感じの昨今を送ってきたもんで何で書かんのやくらいに思ってたんだけど、Go だと private なやつのテストが書きやすいってのがデカそう。(twitter/pankona)

golangのテスト書いてたけど、テストプログラム名前空間(パッケージ)が、対象プログラムと一緒で、そのためプライベートメソッドでもテストできるの良い感じ (twitter/74th)

Goテストコードテスト対象と同じパッケージにすればエクスポートしてない関数でもなんでもテストコードから参照できるんだけど、これってプライベートメソッドテストすべきか議論するよりテスト書けと言われているようで好き。(twitter/plan9user)

プライベートメソッドテストするか?」とは別にドキュメントソースコードと同じファイルに書いていい(文芸プログラミング)なら、単体テストテスト対象と同じファイルに書いてもいいのでは?」というのも論点になるかもしれない。

2020-11-06

コード共通化するな

プログラミングできる気になった自称中級者は、ソースコード共通パターンが現れると決まって、その処理を関数などに共通化したがる。

しかに、そうすることでソースコードは短くなるし、一見して保守性が上がったような気になるのだが、それは間違った作法から止めろ。

かいこと言っても伝わらない自称プログラマが読んでることを想定して、先に結論簡単に書いておく。

お前は絶対コード共通化するな。

共通化してはいけない理由

なぜコード共通化するのがいけないのか。理由簡単だ。要するに、コードが似ているのは単なる偶然であって、それらは別の処理だからだ。

別の処理だから共通化するのはおかしいし、もし共通化した処理の一方のみ仕様が変わった場合、その修正は他方にも影響してしまう。つまり保守性が下がっている。

たとえば、同じプロジェクトの中に、10%の消費税を加える処理と、10%の金利を加える処理があったとする。この2つの処理はともに元の金額を1.1倍する処理であり、全く同じ処理であるが、共通化してはいけない。

これらを共通化してしまうと、たとえば金利が8%に変更になったとき金利計算の処理だけではなく、消費税計算している箇所すべてを変更しなければならなくなる。

実際のアプリケーションでやりがちなのは複数の処理の「事前処理」「事後処理」などを1つの関数にして、呼び出し毎に細かい挙動引数制御するようなパターンだ。

これは結局、改修を重ねる度に「事前処理」「事後処理」の内容が使用箇所によって全く異なるものとなり、それに対応するために

といった悲惨設計に陥る。

他にも、GUIアプリユーザーの応答を待つDialogクラスなんてものを作って、使用箇所ごとにメッセージボタンに割り当てる処理などを切り替えることがある。

これも間違いなく、プログラムが成長するにつれて破綻する。たとえば、ある場所ダイアログは、表示するメッセージテキスト形式のみではなくなり、脇に画像を表示するかどうかのフラグコンストラクタに渡したり、Dialog継承させて表組みを表示するTableDialogサブクラスを作ったりすることになる。ボタンが「OK」と「キャンセル」の2種類の場合じゃなくなって、表示するボタンの数をコンストラクタに渡したり、ボタンに割り当てる処理をリスト形式で渡したりし出す。

こうして、最初は良い設計に見えたDialogクラスはどんどん複雑になる。こうなった原因は明らかで、本来は異なるもの共通化したからだ。おかしな色気を出さずに、素直に別々に実装しておけばよかったのである

処理に名前をつけろ

プログラミングをする上で「コード共通化する」なんてことは意識しなくていい。それよりもプログラマがすべきことは、処理に適切な名前をつけることだ。そのプログラムにおいて「単なる変数操作」を超えた意味のある処理には名前をつけろ。そして、同じ意味の処理なら同じ関数を使うし、違う処理なら違う関数を使う。それだけだ。コード共通化できるかどうかなんて全く関係ない。

変数関数クラス名前空間等が再利用のための機構だという先入観は一旦捨てろ。それらの真の意義は、「関心の分離」にある。つまり実装隠蔽し、その意図抽象するために存在する。たまに勘違いしてる奴がいるが、別に1回しか使われない関数とか、1行しかない関数はあってもいい。というか、この原則にしたがって設計すると、ほとんどの関数(or メソッド)は数行になる。

上の消費税の例で言えば、「消費税を加える」「金利を加える」処理は、明らかに単なる算術演算以上の意味のある操作から関数化する。そして、それぞれの実装は当初の仕様では奇しくも全く同じになる。消費税を加える箇所では前者の関数を呼ぶし、金利を加える箇所では後者関数を呼ぶ。

これはこう言い換えることもできる。消費税を加える関数を変更するのは、消費税計算処理が変わったときのみであり、金利を加える関数を変更するのは、金利計算処理が変わったときのみである。つまり、すべての関数は、それを変更する理由がただ1つになるように設計しろということだ。

こういうアプローチプログラムを書くと、ソースコードはあたかもそのアプリケーションドメイン特化言語で書かれたかのような見た目になる。

また、一つ一つの関数は小さく、理解やすく、テストデバッグも容易になる。そして、結果として再利用もしやすくなるし、プログラムの変更も容易になる。

2019-09-24

今日Container Runtime Meetupという勉強会に参加させていただいたのだが、KubernetesにContainerに詳しい第一人者による神々の集いに目がくらみそうになった。

ここにいる人たちを除いたら、日本でどなたがContainerに詳しいといえるのかわからない感じの人たちが一堂に揃っている。技術書典で池袋ジュンク堂GitHubのissueで名前を見たことがある人たちがいる。

Organizerにいらしゃったので来るかもしれないと期待していたgVisorの中の人たちがいないのが寂しいくらい。

そんな人たちによる登壇者の話がrunc runから始まったのはまだいい。予告があったり、自分は途中でinit処理にわけわからなくなった下地があったので。少なくともその後について腑に落ちたのだ。

だが、そこからいきなりnsexec.cに行ったのは突き放された感じがしてひたすらうなづくしかなかった。

Kushwahaさん。goのimportで定義されることにより本文が呼ばれる前にプリ実行されるCライブラリ名前空間を作成している、そのライブラリの処理の解説が行われた。

https://github.com/opencontainers/runc/blob/master/libcontainer/nsenter/nsexec.c

もうここで、unshare?unshare what?という気持ちになって、あー空のnamespaceを作成できるコマンドかと腑に落ちる暇もなくSudaさん。

ライブラリ実装と呼び出し方法について実際に処理を書いた人が、直直にケースごとのnamespace()の使い方の解説をするのだ。

こんなの後にも先にも一生聞けないだろう。聞き逃すまいと望んだが、MountNSの話は正直セキュリティ懸念があるのね、だから実装=サポート積極的にされてないということしかからなかった。

ファイルディレクトリ一つ一つのアクセス権限付与プロセスIDごと振り返る必要があって、それを高速にできるfsがsysfsという認識であってるのだろうか...自分でも何を言っているのかメモを見返しても呪文しか読めない。

その後もsd_notifyをruncから呼んでいることに端を発したコンテナ起動待ち処理をどう実装するかという議論やら、某ベンダーさんによるruncをガチ運用している環境下でftraceを使ったデバッグの実演やらもうこの夜ここでしか聞けないような話ばかりで。

祭りが終わった後、ほとんどの人が帰らずに、会場となった台所みたいな食卓を囲んでフリートークを交わしていた。

Cloud Controller Managerを自社内向けに実装する話の相談をしていたり、先ほどの登壇者が同じPCの画面を前に肩を並べてruncのソースコードリーディングを始めたり好き勝手にしてる。

それは正直自分みたいに浅い知識を持った人には、RHTechExchangeで聞いた英語雑談よりも遥かに遠い世界だった。

同じ日本語なのに正直何言っているのか本気でわからなくて。地味に悔しかった。

2019-09-10

anond:20190910174449

名前空間は、名前の衝突を防止するためにある。

一人で全部作ってるとき必要性低い。

大きいシステムを作るときは、他人提供するコードを組み込む場合がある。

自分の作ったコードと、他人が作ったコード名前空間が別ならば、それぞれに同じクラス名の

Printer

クラスがあったとしても、どっちかを削除したりせずに共存できる

2019-05-19

[][][]

PHP 名前空間 - Google 検索 https://www.google.com/search?q=PHP+%E5%90%8D%E5%89%8D%E7%A9%BA%E9%96%93

PHP: 名前空間 - Manual https://www.php.net/manual/ja/language.namespaces.php

名前空間とは何でしょう?

広義の「名前空間」とは、項目をカプセル化するもののことです。

これは多くの場面で見られる抽象概念です。

たとえば、たいていの OSディレクトリファイルグループします。

この場合ディレクトリがその中のファイル名前空間として機能しています

具体的に言うと、foo.txt というファイルは /home/greg と /home/other の両方に存在することが可能ですが、それらふたつの foo.txt を同じディレクトリに配置することはできません。

さらに、/home/greg ディレクトリの外から foo.txtアクセスするには、ディレクトリ名をファイル名の前につけて /home/greg/foo.txt としなければなりません。

プログラミング世界における名前空間も、この延長線上にあります

PHP超入門】名前空間(namespace・use)について - Qiita https://qiita.com/7968/items/1e5c61128fa495358c1f

空間が違えば、同じ関数名を定義して使うことができます

名前空間という仕組みは、PHP5.3.0で導入されました。

名前空間定義するには、namespaceキーワードの後に任意空間名を記述します。

名前空間定義する構文

namespace 名前空間名;

2018-12-14

C#Classについて知ってる人教えてほしい

VisualStudioローカル動作するアプリを作ろうと思ってるんだけど

本当に初歩的なことかもしれないことが分からない。

class」というやつについてだ。

XXXXX.csというファイル内にそいつは居るんだが、

そいつの中には複数classさんが存在してもいいのか?SAVACLASSとLOADCLASS存在しても良いのか?

namespaceって何だよ。名前空間意味分からん


public class Person
{
    public string name { get; set; }
    public int age { get; set; }
}
public class Office
{
    public string name;
    public ObservableCollection<Person> persons;
}


private Office office;
private void init()
{
    office = new Office();
    office.name = "オフィス";
    office.persons = new ObservableCollection<Person>();
    office.persons.Add(new Person { name = "001", age = 11 });
    office.persons.Add(new Person { name = "002", age = 22 });
    office.persons.Add(new Person { name = "003", age = 33 });
}

上記って全て同じCLASSファイルに置いていいの?

OFFICEという属性にはPARSONというものが集まってて、そのPARSONの情報にはNAMEAGEがありますよ!というのは分かるんだけど

1から書けといわれたらちょっとからなくなる……

シリアライズも、デシリアライズも、「圧縮解凍」みたいなイメージしかないし

うーん。難しい。

クラスって何なんだ。VBA風に説明できる人いない?(VBAでもClassは使わずにFunctionとSUBだけ使い回してた)

2018-10-21

プログラミング論理的思考の訓練

プログラミングを教えててよく分かるのは、ちゃん論理的思考が出来ているかどうかを計る道具として非常に有用だということ

口先だけで乗り切ってきた人はプログラミングを教えてもちゃん理解してくれない

知識化するときに表面上だけを理解することに慣れきってしまっていて

試験とか面接突破できるんだけど実際のところ分かってない

からプログラミングを教えて新しい物を作らせようとすると全然作れない

からあるソースを少し触る、とかもできない

例えば

def hoge(a, b):
    c = a + b
    return c

def gaga(a, b):
    print("Hello ", a, b)

っていうソースがあったとして、gagaっていうメソッドhoge演算結果が表示されるように変更してみよう、っていうことをさせると

def gaga(a, b):
    print("Hello ", a, b, c)

って答える。

もちろんスコープとか名前空間とか、そもそもそれが生まれてきた経緯とかメソッド意味とかはちゃんと教えてるんだけど

それでも理解してくれない

この問題に関して正解を教えると、この問題は解けるようになるが、しばらくすると似たようなミスを連発する

一方で論理的思考が出来る子は全然分野違いから来てる子でもそんな間違いはしない

頭の中を整理して理解しているからなのか、とんでもない間違いはほぼない

入試とか面接だと両者の区別は付かないし、下手したら普段業務でも顕在化しなかったりするんだけど

しばらく一緒に仕事をしたりすると

「あ、なんかそもそもを分かってない」

っていう子はプログラミングができない

プログラミングで何かを作らせるっていうのはそういう人間を見分けるテストとしてすごく有用だと思うし、重宝してる

2018-05-06

ゴッド・オブ・ウォー』(2018)ではC++Luaを使っている?

PlayStation JapanYouTube動画「『 ゴッド・オブ・ウォー』 究極のアクションアドベンチャー創造3 アトレウスができあがるまで」

https://youtu.be/vxUbSuKRs5c?t=1m4s

の1:04あたりでは

const char* stance
const dc::tAIStance
if (!pStance ||
    return luaL_error(L, "Stance %s

RequestQueue* pActiveRequest = L
AISwitchStanceRequest* request = pAc
request->SetStance(pAI, pStance);
return 0;

というコードの断片が映る.(ただ,上から分かる通り,ほとんどの行は途中までしか映っていない.)

コードにあるluaL_errorはLuaのC APIにある関数である.pStanceがnullptrだった場合などに,この関数を呼ぶのだろう.

また,コードには名前空間を示す"::"があるので,CではなくC++が使われているようだ.

2017-12-15

暗号通貨のことをクリプトって略さないで欲しい

暗号通貨 = クリプトカレンシー → クリプト って省略しているのだろうけど違和感しか無い

名前空間汚染される

あとクリプトエンジニアとか暗号エンジニアとか名乗っているくせに暗号通貨運用自慢ばかりなのは見ていて悲しくなる

暗号(通貨)系エンジニア名乗るなら暗号通貨の開発にも参加してくれ

2017-09-29

退職転職エントリを書くためにID取る奴何なの?

はてなブログ退職転職エントリを書くためだけにID取得する奴,何なの?

最近余計に目立つ様になった.何してる人かも分からない.社名も不明,Twitter使っている事も書いてあるのにアカウント情報不明.署名付き匿名ブログを書くためのサービス勘違いしているのか誰かの創作なのか分からいから社名かSNSアカウントの紐づけくらいしておいてくれ.

出来ないならID名前空間無駄になったり本当にその名前が欲しい人が悲しむから増田に書いてくれ頼む.

2017-04-22

spaceを空間と訳すのは明らかにオーバーキル

namespaceが名前空間というのが気になったんだけどね。

でも他になにか良い呼び方いかなあ。

2016-01-01

Vimプラグインを作るならグローバル変数名を意識しよう

グローバル変数を使う場合変数名の先頭に名前空間をつけよう。

ありきたりな名前を付けると他のプラグインに影響する可能性があるからだ。

ダメ変数名の付け方

let g:age = 20

良い変数名の付け方

let g:namespace#age = 20

名前空間区切りは#でなくてもPHPのPSRで定義されているように_を使っても良いだろう

後は互換性を維持できるよう、よく考えて名前を決めること。

プラグイン利用者は頻繁な仕様変更を望まないからである

jedi.vimやsyntasticなどの著名なプラグインはしっかりとした変数名をつけているので参考になるだろう

2015-11-04

xulhtml 名前空間を使うとvboxが効かなくなる

縦に並ばない。

こんなのばっかでホント、くたびれる...括弧ひとつ足りないだけでエラーも吐かずに黙っているだけでさ、こういうのが1つ起きれば見つけるのに30分くらい無駄になるんだぜ。まともなIDEつくってくれっての。やはり VS は最高だな。

2014-10-11

アプリ屋がRailsを初めて触ってみて感じた事

Qiitaに書こうかと思ったけど、言いたいことも言えない、こんな世の中じゃ。

発想が古臭い

モバイルファーストAPIファースト文脈ハイブリッドWebをやってきた目からすると、サーバーサイドでHTMLを生成してページ遷移させるなどという90年代調のクラシカルな発想を基本に据えるフレームワークはとても斬新に思えました。HTMLゴリゴリ生成するなんてよほど特殊最適化をしようとするのでなければそもそも発想として出てこないです。それでいてDSLメタプログラミング等のテクニカル技法宝石のように鏤められている様はまるでエジプト時代骨董品を見るかのような趣がありました。turbolinkなどは、かつて表計算ソフトに出しゃばっていたイルカを思い起こさせる味があります。かつて慣れ親しんできたSPAが星のように遠い存在になりました。

モデルMVC

Web界隈の人々がモデルだとかアクティブレコードだとか"MVC"だとかを非常に具象的に話す様を見るにつけ、お前らどんだけPofEAA読み込んでるんだよと畏怖していた時期が僕にもありましたが、どうやら彼等はRailsクラスディレクトリという特定実装について話していただけだったようです。Modelという概念もこれだけ肥大化してしまったら、オリジナル概念で彼等と会話するのは諦めるべきかなと思いましたし、Railsの"MVC"をアンクォートして語るのはもはや害悪であるとすら感じました。

レールから外れる辛さ

Rails界隈の人がよく「Rails流儀」や「正しい"MVC"」というのを口角泡を飛ばし議論しているのを目にするのですが、おそらく外に広がる不条理で火傷を負って快適なRails世界に引き篭もった結果としての一種のストックホルム症候群なのだなと思いました。いまやAjaxとかWebsocketとかWebRTCとかを組み込もうとする至極真っ当な方法論がとてつもない高難度に見えてきます。設定よりも規約、というのも一つの方向性だと思いますが、ドメインサービスレイヤ名前空間を構築しようとしたりコードジェネレーションしようとしたりしただけで地獄のようなCircular Dependency罰を受けてしまったので、自分がとても間違った事をしているような気がしてしまいました。とはいえConcernsに特別名前役割を与えられても正直しんどいので、皆が皆libゴミを放り込んでいく様子にも納得がいきました。

レイヤ?何それおいしいの

RailsAPIサーバーとして使おうとするとまずビューが無くなってMとCだけになりますが、いわゆる"MVC"の文脈で育ったエンジニアがなぜ息を吸うようにFat ControllerやFat Modelを作ってしまうのかという事が良く分かりました。多くのRailsリファクタ手法と称されているものクラスを書くファイルを分割する事以上のものでは無いように思えたので、Rails使いを大きめなAPIサーバー案件に回すときセットポジションDDD青本を投げつける必要が有るなと思いました。

TDDやれんのか

ビューとコントローラを結合させた場合結合テストはCapybaraとかのBDDマークアップサイドとの干渉を恐れながら強い気持ちでメンテしていくしか無いのかなと思いました。おそらく脳に電極を埋め込んでいるか緑色のランプを見るだけでハイになれる特殊な人にしか生き抜けない闇が垣間見えました。コントローラを薄くしてサービスレイヤを挟めばその辺りもうまくいけそうな気がしましたが、ビューからヘルパーモデルがいくらでも透けて見えてしまうという状況では裏側の完全性に自信を持つ事は難しそうでした。

分業とか出来るんだろうか

ビューがRubyを叩いて永続化レイヤと直接コミュニケーション出来るというのはとても生産性が高いのだろうとは思いましたが、こうして出来たパーシャルやら何やらをデザイナーとどうやって共有するかを考えると頭痛が痛くなりました。おそらく適当に切り出して綺麗な空間をassets以下に構築した上でpublicにRPCのような窓口を備えたゴミを量産していくのかなと思いましたが、もっと綺麗な方法はあるのかもしれません。でもきっとRails案件に関われるデザイナーRubyバリバリ書けるに違いないはずなので、ここが問題になる事は無いのだろうなと思いました。

RESTとかきついです

RESTはとても美しいパラダイムではありますが、そもそもHTTPがさほど美しくないので歪んだ空間には目を背けるか勝手解釈を与える事で人は初めてRESTfulを名乗る事が出来るのだと思いますGETbodyを(公式には)持たないという事について美しい説明を与える事は出来ないでしょう。サーチAPIはどうしますか。ステータスコード足りなくないですか。401エラーはどうしますか。そしてRESTあくまリソース抽象化する美しい概念なので、アクション副作用については貧弱です。動詞が足りないですし、一般動詞に狭義の意味を与えてドキュメントするのは二度手間しか見えません。PUTには冪等性があるべきみたいなこだわりは家の猫にでも説教してればいいと思います。というわけで、REST的な設計拝借することはよしとしても、「○○はRESTでは無い故云々~」みたいな注文はやめて頂きたいものです。

そんなに嫌なら他に行けば

とか言わないで欲しいです。こういう時にセットでPHPをディスって悦に浸るのは知る限りRubiestとPythonistaと中学生だけです。それにこれはあくまサーバーサイド初心者感想なので、想像するにこれ系のFWは多かれ少なかれ似たような不満を抱えるものなのかなと思います。というわけで、おそらくこれから選択肢がある限りはRailsを使い続けると思います

だってRuby楽しいんだもの

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