Linuxは、開発環境が40年前と同レベル
間違ってもらっては困るのは、それはコマンドライン・メインなのが主因ではないということ。 本当の一因は、本来手書きでも簡単な Makefile の作成をわざわざ難しくしてしま う autotools を権威に流されたのか多くのプロジェクトが使ってしまっている事にある。 高々 Makefile 1つ作るためにも以下のような工程を踏まなければならない。 本来、典型的には、ソースファイルである *.c, *.cxx, *.cpp を指定するだけ でも自動生成する事が出来るはずなのに、ツール類が馬鹿だからそうなってない。 なのに、「Linuxはプログラマーには便利」などと嘘情報が流れるから、普及しない。 しかも、カレントディレクトリのスクリプトの実行に「./configure」などと「./」 の指定が必要なのも馬鹿丸出し。ファイル名に大文字小文字の区別がされているのも馬鹿。 ファイルのコピーもdosなら、「copy *.c /xxx/aaa 」で済むことが $ find . -name '*.c' | xargs -n 1 -i cp -p {} /xxx/aaa などとしなくてはならず長すぎ、馬鹿ですか? しかも、'*.c'の部分が、*.c と書かれている 説明が溢れているがそれだとbashが展開してしまうのでたまたま上手く行く事はあっても、 実際には正しくない。また、mountしないとディスクが認識出来ないのも初代PC-8001の レベル。PC-8801で自動マウントできるようになったのに(いつの時代(苦笑))。まずは、 不便さを認めるなければ、改善すらままならないのにそれすら全否定。正直に便利と思って るなら井の中の蛙で馬鹿で無知なだけだ。そして、僅か1点でも間違いがあれば全てが間違って いるように全否定してしまうLinux信奉者の愚かさもアホとしか言いようがない。 >>1 01. (Makefile.amの作成) # 手作業 02. $ autoscan 03. [configure.scan生成] # 自動 04. $ cp configure.scan configure.ac 05. (configure.acの修正) # 手作業 06. $ aclocal 07. $ automake -a 08. [Makefile.in生成] # 自動 09. $ autoheader 10. [config.h.in生成] # 自動 11. $ autoconf 12. [configure生成] # 自動 13. $ ./configure実行 14. [Makefile生成] # 自動 馬鹿だから簡単に各方法を見出せず、ただただ、大量のツールを開発し、 時間をかけ苦労して使っている。そして大量の時間と膨大なHDD容量と、 ネット容量を使いまくって、それしかやる事が無い無能連中がOSS開発で よってたかって、なんとか表面的には動くバグだらけの使えないツール類を 作りまくって出来上がった集大成が Linuxだ。 いまだにビルドが遅いんだよな しかもカーネルをビルドできるだけでドヤ顔できるほどの難易度 コーディング中にリアルタイムでエラーが指摘される時代に何やってんだとは思う ちゃんと動くんならいいじゃないか。 他のOSでは macOS High Sierra はちょい品質が…なのだし。 WindowsやiOSやmacOSのビルドは違うとでも思っているのだろうか… LinuxだとVimとそれぞれの言語に応じたデバッガーだな macOsだと糞Xcode 40年前の技術に後れをとる大企業マイクロソフトはどんだけ機能不全なんだよw 補助ツールのやってることが場当たりの対応でしかないから、 新しく作るものも場当たりの対応に合うように作ることになる切なさがある そして今は逆に、みんな好き勝手にビルドツールを作る時代になって、それはそれで面倒くさいことに >>1 > ファイルのコピーもdosなら、「copy *.c /xxx/aaa 」で済むことが できないんだっけ? DOSはコマンドラインの長さ制限が厳しすぎて*のファイル名展開したら Linuxでcp *.c /xxx/aaaするより限界低そうだけどどうなんだろうな CUI で開発できるので、うれしい。 よく知らないGUIのOSだと、モヤモヤする。 >>11 DOSのcommand.comはワイルドカードを展開しない仕様だったからコマンドラインの 文字数制限の壁にかからなかった。一方、Linuxは、普段は cp *.c /xxx/aaa で行け ても全てのファイル名の合計文字数が長くなればその制限に引っかかる。だから 結局、findを使わざるを得なくなることがある。そしてファイル数が多いときにもエラーを 絶対に起こさないためには最初からfindを使わざるを得ないと思う。じゃあなんのために、 bashのワイルドカード展開はあるかって話になるかも。 CUIはどこいっても似たようなもんだからな GUIは文化の壁が厚すぎる OS違ったら当然のこと、業界によっても常識が変わるからな ワイルドカードの展開は余計なお世話だと言いたいのかな。それなら抑止するオプションもあるのだが。 「この仕様はどんなメリットがあるの?」とか「DOS のこれは Linux ではどうやるの?」とかなら助けてやれるかもしれないのだが。 面倒でもあるが細かい所まで手を入れる事できるからまし。vsでビルドで謎エラーとか cmakeが主流になりつつあるだろ 誰も知らんのか autotoolsとCMake、正直どっちもつらみがある CMakeなら.slnファイルも作れるという強みはあるが… しかし>>1 はいろいろと誤認や知識不足がみられるな PATHに.入れればconfigureで実行できるようになるがセキュアでないので 推奨されない 今時のGUI環境ならPnPでディスクは勝手にマウントされる wildcardの展開をshellまかせにするかコマンド側がよろしくやってくれるのかは 一長一短あるだろう Visual Studioがいい環境なのは認めるよ。VSCodeはその域に達してないし >>21 >PATHに.入れればconfigureで実行できるようになるがセキュアでないので >推奨されない それでバランスしてしまったのがUnix文化の困ったところなんだ。 DOSだと、暗黙のうちに「.」が検索パスに入っていることが前提だからそれを 前提にした文化が形成されたので、その状態でも十分に「セキュア」になった。 その結果、./を付けなくてもカレント・ディレクトリのEXEやBATファイルを実行できる という超便利な環境となった。ところが、Unixだと古い文化を引きずったまま 直ることが無かったので不便なままとなった。その結果、今後Wineが究極まで 達してもLinuxがWindowsの代わりにはなりえないかも知れない。 >>21 >今時のGUI環境ならPnPでディスクは勝手にマウントされる Ubuntuだけど、 1. /etc/fstab に光学ドライブを書いておくと、Login前に待機状態になってしまう。 2. Login後、メディアを入れてからNautilusでドライブをクリックすると認識はできる。 3. しかし、メディアを交換したときにトラブルが生じやすい。例えば、Wineだ。 4. HDDですら、Nautilusでドライブをクリックせずに、いきなり端末を使った場合には マウントされてない。 5. おまけをいうと、FAT32のような単純なドライブですら、Linuxではext3とはpermissionなど で非互換がおきまくって、正しく動作出来ない。たとえば、そのドライブでは、ソースからは 上手くmakeが出来ず、どこかで不具合が生じてしまう。だから、ext3ドライブにソースを 全コピーしないといけなくなる。 >>21 >wildcardの展開をshellまかせにするかコマンド側がよろしくやってくれるのかは >一長一短あるだろう 現実に良く使うコマンドがとても長くなってしまっているのだから、結果的にはLinuxの 方が使いにくい。 >>21 >Visual Studioがいい環境なのは認めるよ。 この書き方だと、プログラムの経験が浅い人にはVisual Studio だけが例外的に 「いい環境」なだけだと思われてしまう。 ところが、実際にはそうではなく、TurboC++, WatcomC++なども、十分に便利だった。 コマンドラインでも、gccやgnu make などとくらべて、だいぶ便利だったんだ。 はっきりいえば、gccやmakeやLinux文化は洗練されておらず、頭が悪いんだ。 makeは特別に良いとは言わないけど別に悪くもない それより最近は言語に特化したビルドツールが多いから色々覚えなきゃいけないのが面倒 >>27 基本的には、make自身の問題よりも書き方やそれ以外の変なツールが標準になっていることの問題 が大きい。しかし、gnu toolsは、余計なメッセージだけを消す事が出来ないことが多いのが クソなんだ。消そうと思うと全てのメッセージが消えたりして、使い物にならない。turbo c++ や watcom c++ , msc++, vc++のツール類は、どれもそんな初歩的な不具合は無かった。 すごいな。いろんな意味で。現状に不満があるのは理解できたけど、不満を解消するために何をしたの? それが責任者不在の問題点。こっちは部外者なのに責任を負わそうとする。 昔は、好きでやってる開発者に世界中のユーザーが支援して品質を高めていくオープンソースやフリーソフトに、 仕事で嫌々やってる商用ソフトがかなうわけないと思ってたけど、そうでもなかったな。 やっぱり仕事で真剣にやってる人たちにはかなわないんだな。 TURBO Cのコマンドラインは使ったことないな。IDEは便利だったけど。 ただ当時のレベルだったらemacsのmake+ctags環境も十分匹敵する レベルだったと思うが。あの頃にリファクタリング機能とかなかっただろう。 jetbeansの名前も出てるけど、Eclipse, Anjuta, KDevelopみたいな IDEもある中でそういうのを出して比較しないのはちょっとフェアじゃ ないんじゃないか。 まあそれらと比較してもIntelliSenseに及ばないんだけど。 >>22 出自が1マシンを複数ユーザーで使うことが前提の環境だったので 悪意あるユーザーの想定が必要だった。というかWindosが今の状態で 十分セキュアとは思えないんだけど。悪意あるユーザに勝手にファイル 置かれて実行されるリスクは下がっちゃいないのでは。 >>23 fstabを書いた例と書かない例を混ぜて文句いうのはちょっと感心しない。 FAT32はそもそもろくなメタデータおけなくてPOSIX的なファイルの扱い にマッチしないのでそりゃしょうがないよとしかいえない。 全コピーしなくてもloopback filesystem置く手段はある。Windowsでも 似たようなこと(vhdファイル作ってマウント)しないとFAT32領域に まともにアプリがインストールできない事態起きるし。 >>24 そこはもう慣れの問題で自分は「クソ、勝手に処理しやがって」と 思うことの方が多いし味方の別れるところだと思う。個人的にはそんなに 頻繁に使うならエイリアスかスクリプトにでもしたら、と思う。 >>34 >全コピーしなくてもloopback filesystem置く手段はある。 こういうのを聞いて、イザやってみても別のところで不具合が起きて時間の無駄になった 経験が沢山ある。 >>34 >FAT32はそもそもろくなメタデータおけなくてPOSIX的なファイルの扱い >にマッチしないのでそりゃしょうがないよとしかいえない。 数学的にはFAT32であってもext3の模倣もする事が出来る。 あなたは数学は苦手ですか? 苦手なら、数学とプログラムと UnixとWindowsとExt3とFAT32の全てに詳しい者に聞いてみるといい。 自分にはそれをするための方法が頭の中で分かる。そういうツールや ドライバが既にあるという意味ではない。作ろうと思えば作れるという 意味。そして、自分にはその義務はない。 なんでコンパイラと統合環境比べてるの? 統合環境でVSが良いのは認めるけどLinuxだってEclipseやJetbrainはあるし WindowsってただVSが良いというだけじゃん 未だにまともなパッケージ管理もないしシェルは使えないし開発する環境としては最悪だよ VisualStudioが便利な言語って限られるし 開発環境全般で言えばWindowsだけじゃ不足なのでWSLが持て囃されたりしてるし 万能なものはないからいいとこ取りで使っていればいいだけだ MS-DOS を使っていた時代は、UNIX を使っている人たちが羨ましくて仕方なかったな。本当に何から何まで羨ましかった。 だから、Linux よりも DOS がいいというのはなかなか興味深い見解だと思ったのだが……どうやらお呼びじゃなさそうだ。 >>40 そりゃ、DOSはLinuxのサブセットみたいに普通思い勝ち。でも実際はむしろMSが 進化させたんじゃないかと、今では思ってる。実際MS製Unixは売れずにDOS だけが売れたし。 >>37 コマンドライン・コンパイラを比較してもやはり、TurboC++, WatcomC++などとくらべて gnu tools は使いにくいと思ってるし、上でもそう書いてる。 autotoolsはマルチプラットフォームを前提としたものだからTurboとかとは目的が違う 別のOSでも同様の手順でいいという使い勝手はTurboCとかじゃ実現できないわけで結局使い易いとかは主観でしかないしどれだけ自分に都合が良いかというだけのこと >>43 色々な嘘によって、ミュンヘン市は損害を追ったのに、Linuxサイドは「技術的な問題じゃない」 という一点張り。スラドではこの態度に対し、「なんと言う言い訳」と言われてた。 使いやすいとか使いにくいは慣れの問題だし 最初に手をそめた環境がその人の一生の好みを決めるところがある 自分の好みを言っても主観以外のなにものでもない >>46 LibreOfficeの開発者もそんな事言ってた・・・。 >>44 ただ、そんなことしなくても(30年前に比べれば)言語やOSで色々と統一化や 標準化もあったりしたせいか、それらのツールのやり方が本末転倒で意味不明 な存在になってり。 今は、そもそも出来ない場合にはそんなツール使っても出来ないし、出来る 場合には使わなくても出来る。存在意義がどれくらい果たしてあるのか。 出来るかどうかってのは使う人間の能力によるところが大きいから出来なかったとしても仕方がない >>50 今は、「マルチプラットフォーム」での非互換部分を自動的に修正してくれるかどうかの話 やで。 そのソフトウェアがそのOSに対応してるのなら自動的に追従するようになってるだろ 想定されたOSでそれが出来ないということなら問題は人間側に(以下略 スレタイだけでの反応なんだけれど、 16年前に書いたソース群を、今日makeする事ができた。 これ、本当に凄い事だと思う。1回覚えた事や環境がずっと使えるって幸せ。 >>1 読むと、autoconfは確かに面倒なの同意。 良書がなかったしね。訳本も酷かった。本当に酷かった。 そもそもポータビリティに気を付けてソースを書きなさい。 後は、色んな環境でもmakeできるようにしてあげるよって思想だった記憶。 お陰でvine2.1.5時代に作った物が今でもmakeできた。 ただ、思い出して修正できるまでに10日かかった。 当時も日本人開発のソフトには導入が不完全で、バグレポート送ったりしてたわ。 えっ!? http://www.jaist.ac.jp/ ~kiyoshiy/memo/autoconf.html >autoconf/automakeのバージョンを少し上げただけで、 それまでに作成した >configure.inに対してautoconf/automakeを実行すると エラーや警告を生じる >ようになる場合が多々あります。 むやみに最新バージョンをインストールし >ないほうがよいようです。 >以降の記述でも、autoconf/automakeのバージョンによってはエラーや警告 >が発生する場合があります。 どっちの関数があるかないかによって、自分のコードにこんなの書かされる。 片方の環境しかなければ、もう片方のテストはしないってことだよね。 #ifdef HAVE_GETCWD getcwd(pathname, sizeof(pathname)); #else # ifdef HAVE_GETWD getwd(pathname); # endif #endif このようなコードを何回も書くのは駄目コードだ。なぜなら、1文字でも間違って いればバグるのに、テストも出来ないから。 例えば、マクロ名を間違って、 #ifdef HAVE_GETCVD #ifdef _HAVE_GETCWD #ifdef HAVE_GET_CWD #ifdef HAVE_GTECWD #ifdef HAVE_GETCW などと書いてしまったらどうなるか。このようなミスは、ヒューマンエラーなので、 頭の良さや経験や能力に関わらず、誰にでも起こりうる(なのに、エラーになら ない。)。 また、それとは別に、例えば、その環境では getcwd(pathname, sizeof(pathname)); の部分をコンパイラがパースすらしない場合、 getcwd(pathname. sizeof(pathname)); getcwd(pathname, sizeof(pathname)): getcwd(pathname, sizoef(pathname)): getcwd(pathname, sizeof(pathnmae)); などの書き間違いがあったらどうなるか。 , . ; : の間違いがあるが良く見ないと分からない。 これならまだコンパイル・エラーになるだけなので まだ良くて、一度もテストしないなら、コンパイルは通るのに、 実行段階で結果だけがおかしくなることもありうる。その場合は もっとたちが悪い。 >>58 頭の言いプログラマなら、別の方法を探す。 馬鹿だからその「解」が見つからない。 >>59 プリプロセッサに代わる頭の良いやり方を是非開発して >>60 1つの方法としては、新規に共通(互換)ライブラリを作れば良い。 上の例だと最も単純には、 1. getcwd(pathname, sizeof(pathname)); 2. getwd(pathname); の「1」の方はアプリ・プログラムでは使わずに、必ず2を使うようにする。 そして2が存在しない環境向けには、 xxx getwd(zzz *pathname) // zzz は恐らく char { ・・ aaa = getcwd(pathname, 最大パス文字数); ・・・ } のような感じのライブラリ関数を提供してしまう。こうしてしまえば、 autotool なんてアプリをビルドする際には全く使わなくて良くなる。 長いパス名が使える環境向けには、「最大パス文字数」を動的に可変に する方法も有り得る。そうするには工夫が必要だが不可能なことではない。 そのやり方は無造作にやるとシンボル名が衝突してコンパイルやリンクエラーになりますが 動作の切り分けはどうやってするのですか? >>62 シンボル名の「衝突」と言っても色々な場合があり、一概には言えないが、 新しい共通ライブラリ関数は、例えば cmn_getwd() のように先頭に 「cmn_」を付けてしまって、アプリは、「cmn_xxx」の 方だけを使うようにすれば、衝突の心配が1つ消える。 >>63 名前変更した共通ライブラリをビルドするときはどう回避するの? >>64 それは色々なやり方があるが、2つだけ書いておく: 1. そのライブラリのソースだけは、プラットフォームごとに場合分けしてしまう。 2. 何らかのツールで、関数ごとに使えるかどうかチェックし、1,0のフラグを マクロに設定するヘッダフィルを作成し、そのマクロで#ifdefで場合分けする。 どちらの方法でも、ライブラリだけを誰かが集中的に徹底的にテストとバグ取りして、 ライブラリを作る人だけは、全プラットフォームでテストを徹底的にしさえすれば、 >>56-57 のような危険が生じる可能性を限りなく0に近づけられる。 >>65 本質的にプリプロセッサの問題を解決しておらず 欠陥品を頑張ってなんとかするというのは頭の良い解決策とは 余り言わないと思いますが。 >>66 だったら、プリプロセッサを改良すれば良いよ。 >>67 具体的に改良点も挙げずに言われても無意味ですし プリプロセッサが改良できるならあなたが最初に上げた問題点も解決するのでは? >>68 >プリプロセッサが改良できるならあなたが最初に上げた問題点も解決するのでは? いや、それだけだと「>>57 」の前半の問題は解決するが、後半の問題は残る。 >>65 の方法を使えば、両方の問題を解決できる。モジュール別テストは強力だから。 >>68 >具体的に改良点も挙げずに言われても無意味ですし >>57 の前半の問題を根本的に解決したければ、gccの前処理(プリプロセス)部分 に独自の前処理指令を追加すれば良い。 ただ、そこまでしなくても、>>65 の方法のようにすれば、モジュール別テストの効果で 非常に安定なプログラムを作り得る。 共通ライブラリのビルド時にシンボル名の衝突回避をプラットフォーム毎に判別する 方法が具体的に何も提示されてないのですが。 >>71 一応、何度も「衝突回避」と書いてあるけど、「関数が定義されているか どうかによる場合分け」みたいなことだよね。 その部分だけは、何らかのツールを使えばよい。最も単純な物でよければ、シェル スクリプトでもいける。コンパイラ処理系によって違ってくるが、使うライブラリ 全てについて、ライブラリアンやリンカなどでexport symbolの一覧を出して、 関数名(シンボル名)が出力されるかを調べれば良い。それは、 librarian -list_exports xxx.lib | grep シンボル名 が1文字以上の何かを出力すれば真、何も出力しなければ偽、という 様な論理で良い。それをシェルスクリプトに書けば良い。 >>72 判定結果をどうやってソースコードに反映させるのですか? あなたが今提案したようなことをautoconfがやっているということは 目をつむっておきますが。 というか既存のビルドシステムや共通ライブラリの実装に精通してないどころか Cでまともにプログラム書いた経験があるように見えないのですがね。 いや、実際に上司などからも、滅多にいない最高レベルのプログラマだと評されていたの でそれはない。 っていうか、ビル・ゲイツが今時のできるプログラマは間違いなくMacを使ってるとか 言ってたけど、俺はMac使ってないからよく知らないけど、Ubuntuなら何でもパッケージ揃ってるじゃん・・w Macもネットとか見て大体想像つくけど、Ubuntuの方が上だろ・・? Windowsの時の糞めんどくせえ環境変数の設定とか全然しなくていいからUbuntu大好き Windows98の頃なんて、VC買ってやってみたけど、インテリセンスの出てくるのが糞遅くて ワロタよw Javaも最初のAutoexec.batにパス記載するのも、順番違うとコンパイルや実行できねえし・・w 今のWindowsは良くしらんけども。 >>36 その昔umsdosってのがあってだな…実際ext2っぽいメタデータをVFAみたいに VOLに詰め込む実装もあったんだよ。もうメンテされてないけど。 むしろ現代では逆にf2fsなんていうものでFATを模倣するような挙動を androidでやってる。 1がアホなのはわかったw 昔は文字数制限がシビアでそれに引っかかった時に対処するのに四苦八苦してfindだとかいろいろ組み合わせただけだぞ WebAssembly を試そうと、Ubuntu に emscription をインストールしようとしたら、 64bit OS用にしか precompiled 版がない。 どこが開発者に使いやすいものか。 ソースからインストールしようとすると、clangまでソースからビルドさせようとしやがる。 500MB位DLを強要されそうになった。 もっとも、バイト数も表示されないので、推定だが。このバイト数も表示されない、というのも LinuxのCLIパッケージ・マネージャーによくある問題点だ。Windowsだと、zipファイルのDL サイズは速い段階で分かるが、Linuxだとスクリプトによっては最後まで分からないことが ある。今回も「その分からないタイプの」スクリプトだった。 アメリカは高速回線でどうでも良いのかも知れんが、こっちはたまったもんじゃない。 単に zip ファイルにまとめてしまえばいいだけなのに、何のために apt-get や apt があるのかも分からない。 アホですか。 しょうがないのでWin7でやったら、上手くいった。 せっかくLinuxでやろうと思ったのに。 いつもこんな感じになっちまう。残念。。。 自称神童のアホですかおじさんは Linux では幸せになれないと思うよ。Linux のことなど忘れなさい。 ちゅうか、この調子だと数十年たってもLinuxへの移行は進まなさそう。 GoogleのChromeOSや、デスクトップ用のなんとかOSがなんとかしてくる かも知れんが。 >>90 そうやって、色々な人が離れて行くんだろうよ、今までも、これからも。 というか、もはやボランティアの力だけではどうにもならん気もする、 DesktopでのLinuxは。やはりGoogleか。 Linuxまで最新OSの真似するなんてなんと生意気な。 自分たちの立ち位置が認識できてない。何一つマトモニなものが ないというのに。 初心者がLinuxとストレスフリーで生きる為の6か条 1.Winをリプレース出来るなどど考えるのはやめましょう。共用しましょう。 2. 印刷はあきらめましょう。 3. Wifiの使用はあきらめましょう。 4. 音楽・動画・画像の編集/制作はあきらめましょう。 5. Nvidia製品の使用は控えましょう。 6. 教本を買いましょう。Linux界に限ってはググレカスは遠回りです。 7. Ubuntuを我慢して使い続けましょう。 Emacsが死んでVimが生き残るとは訳のわからん世界だな どっちも死んで環境刷新すりゃいいのに どっかの教育機関が、学生に紹介して洗脳したんじゃない。 初めて触ったエディタがvimになっちゃって。Macとかも東大が洗脳してる。 酷いもんだ。 いまどきコマンド形式のエディタなんて効率の悪いものにしがみつかなきゃならんのはLinuxぐらいだからなぁ。 これめっちゃ使いやすいよ Download Visual Studio Code - Mac, Linux, Windows https://code.visualstudio.com/download 犬厨が棍棒持って恐竜追い回している間に MSはロケット打ち上げて火星までいっちゃった感じ >>101 前、使ってみたら、拡張のための機能ばかり豊富だけど、それも非常に複雑で 「簡単なことを複雑にする」タイプの設計だと思った。IDEとしても使いやすくも なかった印象がある。 >>102 それな Eclipseを改造して○○専用Eclispeみたいなのが量産されていて、 プラグインを入れることでいろんなことに対応できるEclipseじゃなくて いろんなEclipseを作ることができる、Eclipseツクールみたいになってて 一体いくつのEclispeをインストールするのか?って思った Eclipseはintelijの登場で不要になったわ Eclipseも出てきたころは、絶賛されまくっていたが、自分で確認した人が少 なかった。それで各自で試してみたところ、言われている評価とは違っていた。 intelij も同じ道をたどるのではないか。 intelijはAndroid stidioとしても使われまくってるけどな 人間も生殖の仕方が何千年前からたいして変わっていないのは問題ではないのか? >>107 オナニーの仕方なら相当進化したで? A10ピストンSA、4万高いなぁ、どうしようかなぁ 俺はネコビーン派。 テキストエディタの代わりにも使うぐらい。 起動おそくて立ち上げっぱなしだからってのもあるけど 今のLinuxのメインユーザーは開発どころか何も作り出さずしょーもないSNS眺めてるスマホ層だからな 開発環境なんていらんだろ AGK無料試用版の配布開始(リンク先にWindows、Mac、Linux版のファイルが直接置いてある) AppGameKit - Free Trial Version https://www.appgamekit.com/trial 無料試用版 AppGameKit無料トライアル版は、AppGameKitの主要な領域すべてにアクセスできるため、 完全に評価することができます。完全版の有料版には、次の主要機能が含まれています。 ・ Android、iOS、HTML5にプロジェクトをエクスポートする ・ アプリをデバイスに直接ブロードキャストする ・ コンパイルされたプロジェクトからウォーターマークを削除する >>96 洗脳したわけじゃなくて、作業性を追求したら自ずとvimになるんじゃないの? viが使える環境が多い ⇔ viは使えるようにした方がいいという奴が多い この相乗効果でemacsと差が付いた Linuxはたいていviコマンドがあるから最低限の使い方は知ってた方が良いのは確か。 でもvi(vim)はメインで使うべきものじゃ無い。 文字を書き捨てるだけなら良いけど、所詮はラインエディタだ。 Windows でも GVIM 使ってる。 もちろん、IDE があればそのエディタ使ってるけど。 エディタは、多くの人は、本格的なプログラミングのために使ってるわけではなく、 設定ファイルやスクリプトファイルの簡単な修正程度に使っているのかもしれない。 だから、使用者の数で言えばvimが多くても、ちゃんとしたプログラムに使ってい るとは限らない。 >>107 出産後にすぐ死ぬ確率は劇的に減ってるはず 生殖についても人工妊娠、中絶や栄養状態がよくなったことによる妊娠しやすさの向上もある さらには男女の出会いの多様化で近親が減り、例えば過去にはほぼ例がなかった国際結婚が増えて強靭な種となっている >>116 >エディタは、多くの人は、本格的なプログラミングのために使ってるわけではなく、 これはその通りやけど >設定ファイルやスクリプトファイルの簡単な修正程度に使っているのかもしれない。 これだって少数派やろ いまどき設定ファイルなんか直書きする人がどんだけおるんや 「設定ファイルを勝手に書き換えないでください」と注意書きしてあるソフトのほうが多いくらいや テキストエディタの使い途の最大多数は文章執筆やろ いや、Linuxの世界では設定ファイルは テキストエディタで修正するんや XMLって何がうれしいんだ? Markdown は適当に使うが。 設定ファイルのXML方式はやり方を間違えたからな。 そもそもXMLというだけではタグの種類は定義されておらず タグと属性を使ってデータを表現しますっていう縛りにすぎない。 例えばOpenOfficeとかはXMLをベースにした ODFというフォーマットを採用している。 このフォーマットに相当するものが設定ファイルになかった 標準化せずに各アプリがそれぞれ独自のフォーマットを作成してしまった。 そのせいでXMLを使いながらも、汎用の設定変更アプリが出現することはなかった >>120 なぜGUIが流行らないの? 親切なフリーソフト作者が作ってくれそうなもんなのに なかなかそういうのないよね >>123 XML ってそういうものじゃないの? タグの種類定義なんかしたら XML 違うだろ。 偏見かもだけれどXMLとか文系的で凄く面倒くさい。 定義ってよりもルール作りで出来てるイメージ。 独自フォーマットは、一応は過去の流儀を踏襲してたりしてるのは順応できるかなだな。 クラスの内容をそのまま書き出すのとかすごい便利だけどな。 エディタでいじることが前提になってるから面倒に思うんじゃないの? メタフォーマットであることを理解してない>>123 >>128 「クラスの内容をそのまま書き出す」というのは、何を使えば出来るの? 変に規格化された煩雑なXMLより、ドキュメント付きのJSONのほうが楽な気はする。 >>128 の「クラスの内容をそのまま書き出す」はXML形式でオブジェクトを吐き出すことを言ってるんじゃないか? 文章作成はtexでいいよw GUIの設定画面はないわけじゃないよね? apt-get upgradeしてたらたまにGUIの設定画面出てくるし >>130 .NET のシリアライズの話なんだけど、知らないならいいよ。 「GUIの方がユーザーフレンドリー!」とか勘違いしちゃってる人は、メールもお絵描きで作ってるの? お前はマウスとキーボードの使い分けもできないのか? >>135 Linux はこういう基地外が多いのがなあ…… >>137 内容に反論出来ない奴はWindows触って欲しくないなあ・・・ テキスト入力とCUIの区別がつかない無知無能なLinux信者が存在するらしいw あ、Linux信者じゃ珍しくないか、そういう無知無能は。 >>26 開発環境が遅れた元凶だな。 能書きと思想だけ一丁前に垂れて、OSすらまともに作れない無能なFSFというカルト団体がリヌス・トーバルスの批判しかしないから遅れたんだよ。 LinuxではなくGNU/Linux? 何を偉そうに言ってんのかw どっちでも良いだろ。 OSを作れないカルト団体が巨額な寄付いや御布施で成り立っている思想も見た目もメタボ野郎の集まりに過ぎん。 あと、GPLv3だな。 40年前に「とりあえず動く」になった状態から、誰も弄れないってことじゃんw このスレ、一時期プログラム板やLinux板でやたらとGPLを批判してた(仕事がなくなるのが気に食わないらしい) 奴と同一人物のような気がするな。口調や改行の仕方が似てる気がする。 【オープンソース】Linuxの思想【GPL】 http://mao.5ch.net/test/read.cgi/linux/1413704137/ ↑のスレのID赤めの奴ね。 こんな記事が出たのがもう10年以上前か 結局立て直せず衰退していったな GPL3で対立が深まるオープンソースコミュニティー--協調か分裂か - CNET Japan https://japan.cnet.com/article/20270448/ 「公平性の観点からはGPL3はもはやその機能を果たしていない。その内容はまったく扇動的であり、 FSFの過激な方針にしか寄与しない。GPL2は多くの個人に受け入れられ、 一度説明すれば多くの企業からも支持を得られる優れたバランスを持っていたが、 GPL3にはそれがない」--Linus Torvalds、Linuxファウンダー まわりからチヤホヤされたいんだろ、メタボのおっさんが。 僕の知り合いの知り合いができた副業情報ドットコム 関心がある人だけ見てください。 グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』 C4U3V emacsもかなり使いにくいのに偉そうな事言ってた。 新人のころの上司がvi信者で最初の1年プログラムは全てviで書かされた。今考えるとイジメだよな。その後、windowsプログラミングでVC使ったとき、死ぬほど感激した。 GUIで直感的、makeも書かなくて良い、MFCでクラスも揃ってる、作業効率が果てしなく違った。 まあ、viのほうがキーボード叩くから仕事してるように見えるって利点ばある。 viのいいところは環境気にせずにssh越しにテキスト編集できるところだから新人に教えるの間違ってないけど、(いざというときに使える。) その上司はやりすぎ。 vimにプラグインで補完機能とか入れてるけど、ideの方がいろいろ捗るのかな? 普段vim使ってても面白半分でviインストールして使ってみると軽く死ねる ideは開発環境をサーバーを汚さずに整えられるし、インストールも楽だし、使い方も楽なところかな。 でも勉強にはならないかもね。>>155 僕はnvim使ってるけど、最近のディストリはviコマンドがvimになってない? archとかはもちろん素のviなんだけどさ。 viコマンドがvimになってたらそれは只のvimだろ freeBSDはただのviだったような、、それか、そもそも入ってないんだっけ? autotoolsは確かにしんどい。 今だに使ってるソースツリーは塩漬けされてるだけの感はあるな。 LLVMはconfigureからcmakeに完全移行してたっけな。 cmakeのが階層化できる分、見る領域を絞れるから楽かな。 新しいビルドツールでもリンクの段階だけ数ギガバイトのメモリを必要する類の ものはなんとかして欲しいな。 【ツイッター】小学2年生の道徳教科書 ポンタ君の「ご褒美がなくても仕事を続けたい」が物議 ブラック企業を肯定することにならないか★3 https://asahi.5ch.net/test/read.cgi/newsplus/1527658126/ ポンタくんがご褒美を貰わないでお仕事をするおかげで ご褒美をもらってお仕事をしている他の動物さんたちは批判されるようになりました ポンタくんはご褒美がなくても働いているのにお前たちはずるいぞ! だって、被災地で空き巣に入って十分儲かったから、安いご褒美なんていらない! 被災地でまた仕事しながら物色したい とポンタ君 【道徳の教科書】 ストールマン君は、 「プログラミングは楽しいんだから無償でやればいい。」 と言いましたとさ。仕事とはお金のためにやるわけではないのですね。 105名無しさん@1周年2018/05/30(水) 15:07:11.46ID:Y6aUHfuN0 >最後に、「だって、」以下にご褒美をもらわなくても仕事を続ける理由について、授業中に児童らに書いてもらう内容になっている。 ご褒美を貰うべき理由を書いたら0点で より社畜的な理由を書くほど高い点数なんだろうな この国の道徳教育は狂ってる 117名無しさん@1周年2018/05/30(水) 15:10:52.11ID:9/ern7d+0>>157 無償で働きたいというのは構わんけど、ポンタくんは何で生計を立てているんだろう? 資産や不労所得があるのならいいけど。 人間は何も食べなくてもありがとうを食べれば生きていけるんです byワタミ 51名無しさん@1周年2018/05/30(水) 11:38:11.31ID:1aWoC9+D0>>74 >>19 たしか、だっての理由がみんなの喜ぶ心が生きがいだからって言うのが 正しい答えだって言っていた 奉仕の心らしいが コレ、二人ぶっ殺したワタミも全くおんなじこと言ってるんだよな 無料ウェアをただで使ってるだけのお前らが心配してるのが滑稽だな だったらたまには寄付してやれよ linux使いならお前にも、ないなら作れのDIY精神が根底にあるだろ! 目の前のキーボードとgccは何のためにあると思ってんだ! >>168 gccの存在理由: ストールマンの売名行為 亀レスだけどカーネルのビルドなんてめっちゃ簡単だろ 難易度☆一つレベル あんなんビルドじゃなくてコンパイルだね Apacheやphp,perl,pythonのビルドと同じレベルだよ ちな、gccのビルドが☆2つ、pen4で10時間くらいかかるqtやVirtualBoxのビルドが☆3つ もっと☆彡多いのもある そりゃわかってれば簡単だろうよ。 そこまでの努力はすごいと思うけどさ。 そういうところがあるから潰しは効く。 パッケージ管理をsnappyに置き換えるらしいけどあまり流行ってない。 移行したのかと思ったらまたdebに戻すとか言ってるのもある。 >>123 XML云々以前に設定ファイルの構造なんか元々ばらばらだろ お? 今頃レスがw >>177 だから設定ファイルの構造を仕様化すればよかったという話ですよ? 極論を言えば、設定ファイルなんぞ入れ子構造なし。 リスト形式だけでも十分なんですよ 例 <xml> <input type="text" name="name1"> <input type="text" name="name2"> <input type="text" name="name3"> <input type="text" name="name4"> </xml> 分かりやすくHTMLっぽくしましたがね ここを出発点に項目が多くなれば見づらくなるので グループ化、階層化するための<fieldset>のようなものが必要 複数の選択項目から選べるよう<select> <option> のようなものが必要 数値入力、日付入力、などの機能が必要 そうやって設定を行うためのフォームのようなタグを定義していって あとはCSSとJavaScriptのサポートでも行えば、 設定ファイル自体が、設定UIとしての機能を持ち、 汎用の設定ツールで設定可能なものができていたんですよ。 つまりわざわざ設定画面を作り込む必要がない プロトタイプのような簡易なもので十分な段階では、本当に手軽に作ることができ、 作り込もうと思った段階で使いやすい設定画面に少しづつ変えていくことができたわけです。 アホな妄想垂れ流すヒマがあったら スレタイ読んでくれ >>179 レスが付いたから、レスしただけ 妄想自体はアホではない。 >>181 XMLで出し入れするのはいくらでもあるよ。 でもXMLっていうのは、通常そのまま使うものじゃない 例えばSVGのようにタグを作って使うもの。 アプリごとに独自のタグ作って、それで 使いやすいものができるわけがない。 XMLによる設定ファイルは確実にやり方を間違った ぼくのかんがえたさいきょうの設定ファイルの規格でも発表したらよかろあ >>183 考える前に既存の仕様を探したほうが良い。 すでに最強であることは保証済み 最初に思いつくのはHTMLのフォームだね あれはデータをポストするものだが、 ファイルに保存すれば設定ファイルとしても使える リナックスのディストリみたいに こっちの方がもっと最強! が量産されるだけ >>185 Linuxのみ普及していないというならまだしも 他でも使われていないようなものが使われてないから [Linuxは、開発環境が40年前と同レベル]である と言われても頭おかしいとしか言いようがないよな >>187 その一連のレスは、そういう内容ではないんだが、頭大丈夫か? >>183-187 設定ファイルの仕様化?標準化?とりあえずxmlなんかでやるぐらいならjsonでやってくれって感じ。 設定ファイルのスタンダードいくつか出てきてるけど、xmlなんぞ持ち出してくるとは少しきついな。 html手打ちさせるアプリケーションってなんだよwwww >>189 > 設定ファイルの仕様化?標準化?とりあえずxmlなんかでやるぐらいならjsonでやってくれって感じ。 jsonでやっても複雑になるだけだぞ JSONはデータのみをやり取りする方法。メタ情報的なものが少ないからデータ通信には適してるが 手書きは面倒だし(例 コメントが書けない)手書きするならYAMLのほうがまだまし。 今の設定ファイルにはメタ情報が含まれていない。ここで言うメタ情報というのは ある設定値が取れる範囲などの情報が書かれていないということ 例えば、sambaのmap to guestという項目は「Never」「Bad User」「Bad Password」の いずれかの値を入れることができるが、そのことが設定ファイルには書かれていない (コメントとして書かれている場合があるかもしれないぐらい) これがHTMLであれば、<select>を使って<option>で選択可能項目を明示できる 言っておくが、このHTML風XMLの設定ファイルをユーザーがテキストエディタで直接変更することは考えていない そんなことをすると<select>とか<option>とか書いてもそれ以外の値に設定できてしまうだろ ブラウザライクな設定ツールから設定する。バイナリ形式の設定ファイルがユーザーが直接変更できないのと同様 設定変更には設定ツールを用いる。HTML風XMLの設定ファイルは開発者が作成するもの > 設定ファイルのスタンダードいくつか出てきてるけど、xmlなんぞ持ち出してくるとは少しきついな。 > html手打ちさせるアプリケーションってなんだよwwww これは手打ちを不要にするための方法。 設定ファイルのフォーマットが標準化されることで、ブラウザライクな汎用の 設定ファイル編集ツールを作ることが可能になる。 HTMLのフォームだって設定を変えるのに手打ちしてるわけじゃないだろ? HTMLを元に作ったUIで設定を変更している。 >>191 勉強し直せ。xmlでやるぐらいならjsonでいいってことを言っただけでjsonも好ましくない。 ただ、リスト構造でいいならjsonの連想配列で十分。yaml以外のスタンダードもある。 とりあえず、なにも知らない人、文章力読解力のない人の妄想ってことが十分わかったのでもう絡んでこないで。 > 勉強し直せ。xmlでやるぐらいならjsonでいいってことを言っただけでjsonも好ましくない。 いやだから、XMLはOKだけどJSONはNGって場合もあるんだよ。 例えばOfficeのフォーマットなんかJSONじゃまず無理だろ 違いはXMLにはデータのメタ情報が追加できるってこと。 JSONは名前と値だけしかない。これが問題になる有名な例が日付型 JSONで書くとこのような感じになるが、このdateが文字列か日付なのかを区別することができない { "now": "2013-09-16T22:32:36Z" } それに対してXMLだと以下のようにメタ情報を追加できる。 <value name="now" type="date">2013-09-16T22:32:36Z</value> もちろんJSONでも、値を入れるときは特別なハッシュ構造とすること なんて独自のルールを追加すりゃできるが、それはデータの持ち方を工夫するということであって フォーマット自体の表現力が足りないためのワークアラウンドに過ぎない データ通信は今現在の仕様として、この項目は日付型として扱うみたいにしちゃえるけど 永続的なデータとして残しておくようなものには適していない XMLで値の範囲を制限したいなどはスキーマ使えばできるだろ 実際やってるかどうかは置いといて規格はある 確かにあるね。昔はDTD、今(?)はXML Schemaかな あれは設定ファイルのフォーマットのチェックには使えると思う 複雑らしいけど でも設定ファイル(兼入力フォーム)のXMLファイルには適してないと思う 何故かと言うとUIを作るための情報としては不足してるから 例えば、HTMLの<select>は意味的には<input type="radio">と同等なんだ また<select multiple>は<input type="checkbox">と同等 前者は複数の選択項目のうちから一つを選ぶもの 後者は複数の選択項目のうちから複数を選ぶもの なぜ同じものが2つ用意されているかと言うと、インターフェースを意識しているからだろう <select>は画面に選んでいるものだけが表示される。 <input type="radio">は選択されてないものも含めて表示される。 どのようにレンダリングされるかはブラウザが決めることだが、 期待するレンダリングがそのタグに含まれてる これが単なる入力チェックならどちらも同じになるだろうね なのでXML Schemaはフォーマットの検証として使うことはできるが フォームの代替にはならない 設定ファイルの標準化と文章コーディングを同一視してる時点で厳しい。 xmlはマークアップ言語でjsonはデータ記述言語なんでそもそもが違う。 一般的には設定ファイルには最小限の変数だけがあればいい。 なんだ?ものすごくエスパーしたけど、詰まるところは 設定ファイルのフォーマットを標準化すれば設定ファイル編集アプリなるものが一個で済むでしょってだけの話か? そしてそれをブラウザでアクセスさせるのか? それから設定ファイルをテキストエディタで直接編集する場合の 問題点の一つとして多言語対応が難しいっていうのがある コメントによる説明はおそらく英語だろう見ながら変更がしづらい。 結局の所、エンドユーザーの使い勝手を考えると 設定ツールの存在は必須と言える。 >>196 > なんだ?ものすごくエスパーしたけど、詰まるところは > 設定ファイルのフォーマットを標準化すれば設定ファイル編集アプリなるものが一個で済むでしょってだけの話か? そのとおり。正確に言えば開発者の負担が減る 開発の初期段階は簡単なフォームを用意するだけでいいし、 アプリごとに独自の設定ツールを開発する負担が無くなるのは大きなメリット 初心者でも簡単に変更できるし、多言語対応などもできる > そしてそれをブラウザでアクセスさせるのか? ブラウザは開いているHTMLファイル自体を変更できないのでだめだが ブラウザベースで作ればJavaScriptやCSSも使えるのでいいだろう。 今でもブラウザで設定が可能なものはあるが、それはたいてい ウェブサーバー機能を持っているものに限られるだろう ウェブサーバーを必要とせず、ブラウザベースだが開いているHTMLファイル(の項目)しか 変更できず、セキュリティのために外部サイトの接続もできないようにしたものが良いだろう >>196 > xmlはマークアップ言語でjsonはデータ記述言語なんでそもそもが違う。 そう。だからなんでjsonなんてものを持ってきたのか理解ができない >>196 > 一般的には設定ファイルには最小限の変数だけがあればいい。 理屈的にはそのとおりだが、実際の設定ファイルを見ると 最小限の変数以外のものがたくさんある。 その多くは、ユーザーのために設定の変更をサポートするための 説明だったり、設定値の候補だったりする 現実には設定ファイルには最小限の変数だけでは だめだということがよく表されている jsonが設定ファイルのアプリなんかいっぱいある。 今、xmlが廃れて、jsonがやや使われ始めてるのは可読性の問題。 つまり、GUIで制御できるならテキストベースの設定ファイルは必要ないし、 テキストベースの設定ファイルは必要最小限の変数で見やすいのが求められてる。 xmlは書きにくい読みにくい。htmlも直接書かないのが流行ってる。 つまり知らないから変な提案する。 やっぱり理解してないw jsonが設定ファイルのアプリが一体どれだけあるっていうんだか あったところで、そういうアプリはどうせオリジナルの設定ツール使って設定だろ? そういうのをいちいち作らないといけないのが大変だという話をしてるのに 大変な実例を持ってこられても意味がない GUIで設定できるHTMLがテキストベースである理由もわかってないのだろう XMLが読み書きしにくいって、お前はテキストエディタも使えないのかw XMLベースのものなんていくらでもあるSVGもそうだし Office形式もXMLベース。XAMLもそうだし、 apt-file search .xml とでも実行してみろ。122732ファイルもでてきた。 apt-file search ".xml" | cut -f1 -d: | uniq | wc -l 3444のパッケージで使われている。たいしてjsonは2149パッケージだ。 おかしいなwjsonの方が使われてるじゃないかw それにXMLじゃなかったら独自形式ばっかりだろ あと反論の仕方も幼稚だ。いまXMLじゃないからが理由であって 俺の話に何一つ言及できていない。するだけの知能がない。 訂正 3444のパッケージで使われている。たいしてjsonは2149パッケージだ。 おかしいなw。jsonの方が少ないじゃないかw > jsonは2149パッケージだ。 せいぜいXMLの1割ぐらいかと思ってたけど6割越えてるのか HTMLのなんとかというタグはこう使うなんてのは 別でそういうお約束を与えてるだけなのに自然に決まるみたいな発想はどこから湧いてくるんだろう この下らないスレのやり取りでも新しい発見があった それは既存のテキスト形式の独自形式の設定ファイル それは、テキストエディタが設定ツールで 設定ファイル自体はUIとみなせるということ 設定ファイルには設置値だけではなく、コメントという形で どういう項目であるかが書かれていて、ユーザーは その説明を見て設定を変更する 新しいもなにも*nixは昔からコンソールでテキストコンフィグをいじるんだろ。 だからなにも知らないって言われるんじゃねーかwww >>207 やっぱり理解してないw 上の方で馬鹿がいっていただろ? 設定ファイルは単に値さえ入っていればいいって。 現実として設定ファイルに人間が読むための文章が 入っていることの意味を理解してない 設定ファイルは単なる設定値があるだけのものではなくて インターフェースになってるって話をしてる そしてそのインターフェースを強化するための XML設定ファイルの話をしてる >>205 自然に決まらないならoptionがどういうUIを持つか実装依存で何の意味があるのやら 何の意味があるのやらと言われても、ブラウザがそうじゃん iPhoneの<select> & <option> 見たことある? PC版とぜんぜん違うよ。ドラムロールと呼ばれるUIになってる 見た目は違う(実装依存)だが機能は同じ 物事を抽象化して考えられないのかな? >>213 selectが選択肢から選ぶというのはどこから湧いてくるわけ? >>214 質問の意図がさっぱりわからない 話の流れとしては、設定ファイルがXMLのものはたいてい XMLを間違った方向に使ってしまってメリットが失われている これが話の発端 間違っているというのならどういう使い方が正しいのか? と聞かれたのでHTML(のフォーム)を参考にすれば良いと言った そのHTMLのselectがどういうものかはw3cとかが決めてるだろ もちろん参考でしかないのでXML設定ファイルを同じように する必要はないが、他のXMLベースのフォーマットと同じように 誰かが決めるだけの話しだろ それで、その質問は何が言いたいのだ? 俺はXMLベースの正しい使い方はどういったものであるべきかを説明しているだけなんだが? selectの細かい仕様とか誰が決めるのかとかどうでもいいよ。 そこはXML設定ファイルがどうあるべきかの話にとって本質的な部分ではない 要するに誰かがオレオレ仕様決めるだけか 何の意味があるのやら 要するに マークアップ良いじゃん。使いたい。メタデータあるし。 マークアップを解釈できるソフトで設定ファイルを管理しよう。 これを標準化しよう。ってことだろ。 こんなゆるい、どこまでも意味ない標準もないし、マークアップ縛りってだけの意味のない制限。 理解してほしい文章書くなら後出しジャンケンやめて、標準化したい仕様を書かないとなんにも伝わらん。 実装出すと、仕様出す、コンセプト出すが酔い順番で コンセプトが誰にも理解してもらえない時点でどうでもいい話だな >>216 何の意味って、最初に言ったとおり、 世の中はXMLの使い方を間違ったよなーって話をしてるだけ >>217 標準化しようじゃなくて 世の中はXMLの使い方を間違ったよなーって話をしてるだけ >>218 仕様を書く必要はないよ 世の中はXMLの使い方を間違ったよなーって話をしてるだけ >>219 世の中はXMLの使い方を間違ったよなーって話をしてるだけ お前が間違ってると主張する意味がわからんし オレオレ正しい正しい使い方もわからん >>221 テキストエディタでXMLの設定ファイルを編集しても面倒なだけだから かといってXMLの設定ファイルを持ってるアプリが設定ツールが あるかといえば無いだろう?設定ツールも作るのは大変だからね キーとバリューの使い方を間違えたんだよ。 たいていXML設定ファイルはこんな感じになってる https://help.adobe.com/ja_JP/air/build/WSEC63CD64-C52C-41ef-82FD-94E6B540A5FA.html <configuration xmlns="http://ns.adobe.com/air/framework/update/configuration/1.0" ;> <url>http://example.com/updates/update.xml< ;/url> <delay>1</delay> <defaultUI> <dialog name="checkForUpdate" visible="false" /> <dialog name="downloadUpdate" visible="false" /> <dialog name="downloadProgress" visible="false" /> </defaultUI> </configuration> こんなの独自のタグばっかりあるんじゃ汎用のツールで扱えるわけがない まあガリレオ並みの人物なら死後にでもやっぱり世間が間違ってた、あいつは凄い!ってなるやろハナホジー 今までと同じようにHTMLのタグを拝借して こういうふうに書くと汎用のツールで対応できる(実際ブラウザが出来てるわけだし) <form> <input type="text" name="url" value="http://example.com/updates/update.xml" ;> <input type="number" name="delay" value="1"> <fieldset name="defaultUI"> <input type="checkbox" name="checkForUpdate"> <input type="checkbox" name="downloadUpdate"> <input type="checkbox" name="downloadProgress"> </fieldset> </form> そして開発の初期段階は最初は簡単なフォームでいいし、 のちのち見栄えを整えたくなったらCSSなどを使えばいい。 だから最初からそう言ってる。 XML設定ファイルは、アプリが個々に要素を定義するんじゃなくて 共通の仕様を作るべきだったと そうすれば設定ツールは汎用のものを別に開発できて、 全てのXML設定ファイルをそのツールで設定でき 開発者も独自の設定ツールを作ることがなくて楽になってたんだよ。 GUI大嫌いって開発者でも、XML設定ファイルにするだけで テキストエディタでも設定できるし、設定ツールでも設定できるようになってた さらに作り込めば使いやすいUIを作れるし、多言語化もできてた だから間違った方向に進んだよなーって思ってるわけだよ。 特定目的設定XMLで表現できない項目が出てきたらどうすんだ >>227 > 特定目的設定XMLで表現できない項目が出てきたらどうすんだ 結論を先にいうとそういうのはないと思ってる 設定のしやすさは別として(後述するがこれは解決できる問題) どんな設定であっても、キーとバリューのリストで設定できる 例えば、Firefoxのabout:config の例 設定名: devtools.performance.timeline.hidden-markers 型: 文字列 値: ["Composite","CompositeForwardTransaction"] (JSON文字列かな?) このような単純なキーとバリューのリストで保存されている。 これを見る限り、型としては最低限、文字列、整数値、真偽値 があれば必要十分なのだろう まあJSON文字列とか卑怯な物使ってるからねw もう少し便利にするならば、レジストリを参考して「複数行文字列」「変数展開が可能な文字列」や キーバリューのリスト型みたいなものがあるといいだろう で、開発の初期段階であれば、どんなに複雑な項目であっても 最悪JSON形式の文字列でテキストエディタで保存すればOKということ。 JSON設定ファイルなんてものがあるんだから、それぐらい苦じゃないだろう?w でも、設定のしやすさの問題が残っている。エンドユーザーにとってはJSON文字列で設定するのは大変。 そこで出てくるのが・・・というかもったいぶって言うほどのことではなくウェブが すでにその問題を解決してる。CSSとJavaScriptでインターフェースを作ればいい。 そしてその値をフォームにマッピングする(例えばJSON形式で保存) 当然外部CSSとJavaScriptを使うため、設定ファイル自体はシンプルな状態を保つことができるし、 テキストエディタで編集したい人はそのまま編集できる。 それでいて設定ファイルをシームレスにユーザーインターフェースへとつなげることができる。 ウェブ技術の応用だからUIを作れる人は多いだろうし、なによりUIの作り込みは後からやれるから開発者の負担も減る 何でも設定できる汎用フォーマットに何でも設定できる汎用GUIという ありとあらゆる機能を詰め込んだ膨大な仕様、実装を要求してることに気が付かないのか >>229 ぜんぜん? だって>>224 を見てよ。 タグは使い方を変えただけ。本質的には今の使い方と変わらない 今までと同じようにテストエディタで編集できる それに加えて汎用の設定ツールの開発が可能になる。 設定ツールの仕様がブラウザ並みに大変になる思うかもしれないが、 CSSやJavaScriptはオプショナルに過ぎない。搭載は必須ではない。 ネスケ4とかガラケーやテキストブラウザレベルのものがあれば 設定ツールとして機能する。膨大でもなんでもない。 どうせ今だって複雑な項目をテキストエディタで編集してるんだろ? ならそこだけ諦めて <textarea>で編集すればいいだけだよ。 そして将来高機能な設定ツールが登場すれば、CSSとJavaScriptで リッチなUIが使えるようになるし、それがでるまでは テキストエディタやテキストブラウザ等で設定できる そして設定ツールは汎用なので独立して開発できる。 なにかアプリを作ったときエンドユーザーが簡単に使えるようにと アプリ開発者がオリジナルの設定ツールを作る必要はないわけだ。 重要なのは、テキストエディタで編集するのなら、 今のXML設定ファイルとほぼ同じ使い勝手でありながら、 将来的に拡張していけるということ、 今よりも悪くなっているところがなにもない 相当頭悪そうでまともにプログラム書いたこと無さそうなのがわかるので なんか実装見せてくれたら誰か相手してくれると思うよ 一言悪口を言わないと気がすまないようだなw 何かわからなかったら言えば説明するし、 わかったなら、そのことについてコメントしろよ。 なんで書いてあることをいつも見なかったことにして悪口だけ言うんだ? お前の言うことには中身がない。 頭悪そうに見えるのはお前の方だよ あなた人の指摘が理解できないでトンチンカンな持論くりかえすだけだからね だからこれ以上なにか言いたきゃ実装出せば 一連のXML、HTML君の言い分をまとめれば矛盾だらけだけど、矛盾を指摘するのがだるいから意味のあることだけまとめるね。 ・マークアップ言語を使って設定アプリを作れる。xmlは間違った進化してるけど、それはxmlの仕様を変えれば問題ない。 ってことだ。マークアップも一応プログラミング言語だからPC上でできることは何でもできる。っていうだけのことでしょ。 つまりおまえの言ってる標準は言語を使えばアプリを作れるってPCの誰でも知ってる標準にXMLと設定アプリを加えただけなんだが、 それ以上になにかあるのか?っていうこと。 >>123 から始まってるxml君の言いたいことはよくわからんが、 メタ情報の標準化はxmlに限らずオントロジーの作法を知らないからxmlの仕様がーとなるんだろ。 メタ情報を標準化しなくてもオントロジーを定義してrdfの仕様に沿えばメタ情報の解釈はできるんだけど知ってるのかな。 膨大なアプリじゃないと言い切るならどんなブラウザでもそのくらいはできるし大丈夫だよね。 >>236 お前がわかってないじゃんw XMLは何の略か知ってる? eXtensible Markup Languag 日本語にすると「拡張可能なマークアップ言語」 「拡張されたマークアップ言語」ではないんだよ。 拡張可能が意味する所は、拡張して使いましょうってこと。 XMLの仕様を変える?XMLの仕様のどこが問題なんだ? ODFなど様々なXMLベースの仕様が作れるほど拡張可能な素晴らしいマークアップ言語だろ ただ世の中XMLを間違った拡張をした独自の設定ファイル形式が多いってだけ それはXMLの仕様や進化とは関係ない。そもそもXMLの仕様はシンプルではずっと前から 安定していて、仕様を変える必要性もないほど柔軟で拡張可能に作られている 俺はXMLの仕様自体には文句をつけていない。アプリ独自の拡張方法に文句をつけてる 俺が言ってる意味ちゃんと理解できてる?XMLがどういうものかもわかってないでしょ? 君どうも知識が浅いよ。具体的じゃなくてどうとでも取れるようなことしか言ってない。 > マークアップも一応プログラミング言語だから ぜんぜん違う。チューリング完全であることはプログラミング言語に要求されることの一つだが、 マークアップ言語はチューリング完全ではない そういうポロッと素人レベルのことを漏らすから、知識浅いとわかる > PC上でできることは何でもできる。っていうだけのことでしょ。 そんな意味のないことは一言も言ってない。お前が理解してない証拠。 (俺が言ってることを理解出来ないが)きっと誰でもわかるようなことを言ってる違いないと お前が思って、誰でもわかるようなことを言ってる例として出しただけでしょ? >>237 何が言いたいの? 俺はXMLベースの設定ファイルの多くが間違った拡張をしてると言ってるだけ? で、お前は?オントロジー? XMLベースじゃなくても、頑張ればなんでもできるって 一般的な話をしてるだけ? 俺はそんな話はしてないよね。 変な所にはてながついちゃったw 俺はXMLベースの設定ファイルの多くが間違った拡張をしてると言ってるだけ 俺は今の現実を批判してるのであって、 お前みたいに存在しないものを作るなんて話はしてない 架空の世界の話はしてないんだよ > 膨大なアプリじゃないと言い切るならどんなブラウザでもそのくらいはできるし大丈夫だよね。 XMLベースならテキストエディタで変更できるんでー 大丈夫ですよーw 現実にはお前の理想とする設定ツール実装は存在しないんだろ? それは架空の話と言うんだよ だからテキストエディタで設定できるって(笑) 何度も言わせんなや ぼくのかんがえたさいきょうの設定はテキストエディタで何でも設定できるんだー!って何が凄い発想なのか >>240 >俺はXMLベースの設定ファイルの多くが間違った拡張をしてると言ってるだけ ここにみんなが突っ込んでるんじゃなくて(間違った拡張も主観的な主張だけど。)、 >XML設定ファイルは、アプリが個々に要素を定義するんじゃなくて >共通の仕様を作るべきだったと それは作りたい人が作ればよろしい。みんな使わないと思うが。 自由に拡張できるといい、他人の拡張を間違っているといい、しまいには共通の仕様を作れと言う。 文脈に矛盾が生じてるのに気がついていない。 ぼくのかんがえたさいきょうの汎用設定用XMLスキーマを策定すれば素晴らしい未来が訪れる、 ということらしいがスキーマの汎用性を高めれば仕様も実装も爆発し 制限すれば不便になりさいきょうでは無くなりそうだ。 ぼくちんの妄想の中ではいい感じに出来上がってるらしいのでサンプル実装はよ >>246 それの何処が矛盾してるんだ? ・XMLは拡張可能なマークアップ言語 ・いろんな人が拡張してるが、アプリ独自の設定ファイルは 間違った拡張をされている ・設定ファイル用のXML拡張の仕様を作れ やっぱり何も間違ってないな。 お前がXMLを理解してないから、矛盾に見えるんだろう? >>248 アプリ独自の設定ファイルがxmlで独自拡張が間違っている例を上げてください。 そしてそれがどのように間違っているかを示してください。 もしかしてスキーマを作ることを「XMLの拡張」なのかね >>252 それがわかるならオントロジーもrdfも理解しても良さそうなんだが。 >>250 XMLの拡張の意味も知らないで突っかかってきてるのかよw XMLの言葉の意味の通り 「eXtensible Markup Language」 「拡張可能なマークアップ言語」 XMLの拡張とは何を意味しているかは、 XMLの意味を調べればわかる(すでにこのスレに書いた) 俺が書いたことが信用出来ないならググれ、と言おうと思ったが、 仮にググったら、良い説明があったので以下を読め http://www.atmarkit.co.jp/aig/01xml/xml.html ↑にはどういう勘違いがあるかも書いてあるから、 XMLが本当はどういうものかがわかるぞw >>254 具体的に拡張するとは何を定義するか説明できるの? >>257 それ俺が質問してるんだわ XMLは何の略か知ってる? eXtensible Markup Languag 日本語にすると「拡張可能なマークアップ言語」 「拡張されたマークアップ言語」ではないんだよ。 おれがXMLとはなにか知ってる?と聞いてるのに 聞き返してるのは知らないってことなんかね? いつものことだがこういう輩は自分で説明すると (どこがも言わずに)それは違う。やっぱりわかってないって いうだけで逃げるので、ソースを出すことにしてる https://support.office.com/ja-jp/article/%E5%88%9D%E3%82%81%E3%81%A6%E3%81%AE-xml-a87d234d-4c2e-4409-9cbc-45e4eb857d44 XML タグを利用することで、自分が見ているデータの種類がはっきりわかります。 たとえば、それが猫に関するデータであることがわかります。猫の名前や年齢などを簡単に見つけられます。 ほとんどすべてのデータ構造を定義するタグを作成できることから、XML は "extensible (拡張可能)" と呼ばれています。 というか、調べればわかることをわざわざ書かせるのは 揚げ足取り目的だってわかってるからさぁ http://park18.wakwak.com/ ~little-box/xml_basic/1-002.htm >>238 なんかを見るとODFが「XMLの拡張」の例だとおもいこんでるようだけどあってるのかな? ODFを展開して出てくるXMLそれぞれが XMLを拡張(独自タグを定義したもの)になってる で、揚げ足取りは?w >>253 メタフォーマットであるXMLのフォーマットを決める、スキーマを定義する、ことにすぎないことを XMLの拡張なるものと思い込んでいて ぼくのかんがえたさいきょうの設定ファイルに適したオレオレスキーマを定義することを設定向けXML拡張と呼んでるらしい。 スキーマを定めることでフォーマットが固定されるのに 「拡張」という言葉を使うことでなんでも自在な機能が持てると 妄想も拡張しているようだ。 ? メタフォーマットであるXMLのフォーマットを決める、スキーマを定義する、ことにすぎないことを XMLの拡張というんですよ? なんだろう?最もすごいものじゃないと拡張と言っちゃいけないとでも思ってたの? へんだなぁ。俺じゃなくて XML(eXtensible Markup Language)という名前をつけた人に 言うべきことでしょう? XMLは拡張可能なマークアップ言語ですよ? なんでも自在な機能がもてるとか誰が言ったんですかねぇ。 俺「XMLとは拡張可能なマークアップ言語です」 馬鹿「拡張といったな?」 俺「言ったけど?」 馬鹿「ぼくのかんがえたさいきょうの設定ファイルってことだな?」 俺「(そんなことなにもいってないけど?)」 馬鹿「スキーマを定義することにすぎないことをXMLの拡張なるものと思い込んでるな?」 俺「(そのとおりだろ?) 馬鹿「XMLの拡張というものは・・・・そのとおりだ」 俺「(思い込んみは間違いだ!って言うんじゃないのかよ?)」 馬鹿「拡張という言葉を使うと自在な機能を持ってると思ってるな?」 俺「(何言い出してるんだろうこいつ?)」 馬鹿「妄想も拡張しているようだ。」 俺「(それ言い出したの全部お前じゃん) あー、>>267 が言いたいことがわかったわw XMLを拡張して作るXMLベースの設定ファイルのスキーマ 今のアプリの設定ファイルが間違ってると言ったろ? >>267 はその間違ったXMLベースの設定ファイルに 基づいて発言してる。 つまり>>267 は、アプリケーション固有のスキーマを作る話をしてるから スキーマを定義すると、アプリケーションを機能追加(拡張?)できなくなると言ってる。 あほやな。いや、大部分のXMLベースの設定ファイルは アプリケーション固有のスキーマを作ってるから、 >>267 も含めてみんな間違ってるなーっていうことか 汎用のXML設定ファイルっていうのは(どういうものかは上に書いたので探せ) アプリケーション固有ではなく、スキーマを定めたところで、 アプリケーションの機能追加を妨げるものじゃない 固定するのは設定ファイルのスキーマだけ そのスキーマにはアプリケーション固有のスキーマ定義はないから アプリケーションは自由に「拡張」できる。 だいたいHTMLを参考にしてる点で気づかんかな? HTMLなんかスキーマが定められてフォーマットが固定されてるのに いろんなサイトやウェブサービスが作れるだろと 自在な機能を持つ能力は無いが任意のアプリ固有の機能追加できる アプリ固有のスキーマは無いので好き勝手定義できるけど汎用の設定ツールを作成して設定できる この短い中でこんな滅茶苦茶なこと言う奴も珍しいなあ >>273 えとさぁ、お前、設定ファイルの話とアプリの機能をごっちゃにするの止めたら? 馬鹿らしい。 設定ファイルの形式なんて、レジストリとか見れば、固定でいいってわかるだろ。 固定っていうのは(最低限)キーとバリューの組み合わせが保存できればいいってこと どうせお前は馬鹿だから、キーの名前を固定にするのと ごっちゃにしてるんだろうけどなw ともかく、HTMLのフォームが、inputとselectとtextareaとグループ分け程度の 少ないスキーマ定義で、実際にいろんなウェブサービスに 対応できてるんだから、現実を受け入れようね? どうも齟齬があるなあと思ったら「設定を記録するのに必要なスキーマの」機能の話を アプリの機能と勝手に思い込んでるわけね オレオレさいきょうキーバリューだかなんだかしらないXMLを作成したいって話か?そんな低レベルの話? オレオレ設定XMLじゃ困る人は切り捨てりゃいいなら楽だよなあ キーバリューの話しかできないならなんでこいつはXMLにこだわってるのか謎 また>>220 をコピペすればいい? >>216 何の意味って、最初に言ったとおり、 世の中はXMLの使い方を間違ったよなーって話をしてるだけ >>217 標準化しようじゃなくて 世の中はXMLの使い方を間違ったよなーって話をしてるだけ >>218 仕様を書く必要はないよ 世の中はXMLの使い方を間違ったよなーって話をしてるだけ >>219 世の中はXMLの使い方を間違ったよなーって話をしてるだけ >>275 俺は最初から、設定を記録するのに必要なスキーマの話しかしてない 世の中のアプリは、アプリ固有のオレオレスキーマを作成して 単に編集しにくいだけで、XMLを使用する意味をなくしてしまってる。 世の中はXMLの使い方を間違ったよなーって話をしてるだけ キーバリューならCSVで十分だ運動すれば? あと多彩なWebサービスの話はinputとかフォームに関係ない部分だから わかってないことは使わない方がいいぞ(あとHTMLはXMLじゃないのはいいのだろうか) そして馬鹿は極端だから、 「固定っていうのは(最低限)キーとバリューの組み合わせが保存できればいいってこと」 と書いていても、(最低限)の部分を もうすっかり忘れているwww >>279 設定を記録するXMLと他のデータを記録するXMLを混合できるXMLなんて誰も話してないと思うがね ところで設定ファイルの設計ミスした具体的アプリ名とかないの? >>280 CSVだったら入力インターフェースが作れない 設定の値しか書いてないから、設定が取りうる値などがわからない 例えば、sambaのmap to guestという項目は「Never」「Bad User」「Bad Password」の いずれかの値を入れることができるが、そのことが設定ファイルには書かれていない (コメントとして書かれている場合があるかもしれないぐらい) 設定ファイルでありながらHTMLのフォームと同じような スキーマを採用することで、設定ツールを作ることが可能になる あー、何度言えば良いんだろうw スキーマにはアプリ固有のものは含まれないから、 HTMLが、まさにHTMLがそうしているように、 汎用の設定ツールで設定が可能になる。 アプリ開発者は単に設定ファイルにHTMLフォームライクな XMLを拡張して作った汎用のXML設定ファイルを採用するだけ アプリ開発者は設定ツールを作ること無く、 初心者は汎用の設定ツールを使って設定できるようになる。 何度言えば理解しますかね? >>283 >>216 何の意味って、最初に言ったとおり、 世の中はXMLの使い方を間違ったよなーって話をしてるだけ >>217 標準化しようじゃなくて 世の中はXMLの使い方を間違ったよなーって話をしてるだけ >>218 仕様を書く必要はないよ 世の中はXMLの使い方を間違ったよなーって話をしてるだけ 今の設定ファイルはコメントで、設定方法が書かれているが、 まあこれがまさにテキストエディタ用のインターフェースなわけだが 設定値のみ書かれていればいいならコメントは要らない コメントはまさにテキストエディタで編集する人が 読むためのもの でも設定ファイルのコメントは英語でしか書かれていない。翻訳の仕組みがないからだ。 あるとすれば設定ファイルにずらーっと何カ国後もコメント書くぐらいだなw こういう問題も、まともなXML設定ファイルを作れば多言語対応も可能になるだろう HTMLがブラウザが設定入力インターフェイスだというなら ExcelはCSVの入力インターフェイスだと主張できるなあ しかもHTMLは選択肢がつくれる HTMLがブラウザが設定入力インターフェイスだというなら ExcelはCSVの入力インターフェイスだと主張できるなあ しかもHTMLは選択肢がつくれると言ってんのはデータはどこに入れるの? そしてお前のさいき HTMLがブラウザが設定入力インターフェイスだというなら ExcelはCSVの入力インターフェイスだと主張できるなあ しかもHTMLは選択肢がつくれると言ってんのはデータはどこに入れるの? そしてお前のさいきょうXMLで表現できない設定記述機能要望(アプリの機能じゃねえぞ)はどうするの? 例えば、sambaのmap to guestという項目は「Never」「Bad User」「Bad Password」の いずれかの値を入れることができるが、そのことが設定ファイルには書かれていない いやコメントでこう書かれているかもしれない # ○○をするための項目です(という英語) # 「Never」「Bad User」「Bad Password」のいずれかの値を入れられます。 # デフォルトは「Never」です。 map to guest=Never というものが書いてあってもここから設定ツールは作れない CSV形式でも設定ツールは作れない。 HTMLのフォームライクなXML設定ファイルにすれば設定ツールを作れる <label for="map-to-guest" >"○○をするための項目です(という英語)</label> <select id="map-to-guest" name="map to guest"> <option selected default>Never</option> <option>Bad User</option> <option>Bad Password</option> </select> この中には設定値、設定の候補、デフォルト値が含まれている。 今までどおりテキストエディタで編集もできる > そしてお前のさいきょうXMLで表現できない設定記述機能要望(アプリの機能じゃねえぞ)はどうするの? ない >>289 CSVだったら入力インターフェイスが作れないという文章どこに行った >>294 あ、その事(笑) ExcelでCSV編集しても、値しか入れられないだろ。 取りうる値なんかわからない >>293 えっ?世の中数百万以上のアプリがあってこれからも生み出されるのになんで無いって言えるの? >>296 アプリの機能じゃねえぞ どんなアプリが増えようが、設定はすべて キーとバリューだけで表現できる (便利だと思うならその他の形式をいくつか増やしてもいいが) ほんとなぁ、設定の値の話をしてるのに 結局、ID:3OE6BV46 自身が、アプリの種類が増えたらどうするの? なんて言ってるんだもんなぁw アプリの機能を気にしてるのはお前じゃん >>292 それどこかのアホが <option selected default>ほげ</option> とか書くのどーやって防ぐの? >>297 アプリが未来永劫設定項目の記録表現としてさいきょうの設定XMLでは 不十分だと言うとこは無いとどうやって証明したのですか? >>299 え?テキストエディタを使った場合の話? アプリ独自にテキスト形式で、map to guestをmap to guestoooooと書くのを防ぐ方法あるんですか? CSV形式で、以下同文 テキストエディタを使っている以上不可能でしょw そんなの当たり前。 だから設定ツールが重要になるわけですが? でもアプリ独自のテキスト形式やcsv形式だと、その設定ツールを アプリごとに作らなければいけない あぁ、無駄無駄。時間の無駄 HTMLのフォームライクなXML設定ファイルなら、 その設定ツールで間違った値を設定することはありませんね。 そして汎用で使えるから、アプリ開発者の負担が減りますね。 今のXMLはアプリ固有のスキーマになって、汎用の設定ツールなんか 作れないから、世の中はXMLの使い方を間違ったよなーって話をしてるだけ 設定記述機能の話しかしてねえのに アプリ本体機能と勘違いしてる馬鹿がいるんだと 必死で藁人形打つのやめろよなあ >>300 バイナリデータを含む全てのデータは、 エンコードすることで、テキスト文字列で表現可能だから (必ずしもそうしろと言ってるわけじゃない) >>302 それお前なw アプリがどんな機能を持ってようが 設定は(最低限)キーとバリューの組み合わせが保存できれば十分 >>304 証明どころか実装がある。 Base64はどんなバイナリデータであっても テキスト文字列に変換できる >>305 設定表現にはキーバリューで必要十分なのか他に表現が必要なのか 他に必要なら必要十分な範囲は決められるのか 決められないのか適当に逃げ回るなよ >>307 頭が悪いなw バイナリデータをテキスト文字列に変換できるのなら、 お前が不安に思ってる、どんな表現であっても 単一のテキスト文字列に変換できるってことだよ >>306 お前のさいきょう設定XMLで全てのアプリの設定記述要望を満たす 証明はあるのかと聞いたんだよ 誰かがバイナリのアスキー表現の話してるんだよ。答えられないのわかるけどさ。 JSONなんか、文字列、数値、真偽値、配列、連想配列 たったこれだけのもので、どんな複雑なものでも表現できるからな。 一体何が表現不可能だと思ってるのか わけがわからない >>309 やっぱりさ、お前 まーた、アプリ固有のスキーマの話してるだろw アプリ固有のものなんて無いんだから、 どんなアプリのものだって対応可能 いい加減アプリの機能と設定をごっちゃにするの止めたら? >>310 質問はお前のさいきょう設定XMLで全てのアプリの 設定記述機能を満たす証明はあるのか?です 関係ない話に逃げるのはやめましょう >>311 そういう勘違いしてる人に仕立て上げたい気持ちはわかる(笑) >>312 なんで実装があるのに証明にこだわってるの? Base64でエンコードすれば、どんな設定だって 文字列で保存できるじゃん >>314 テキストファイルとテキストエディタがあればどんな設定でも記述できるという主張かね? 元の証明はできないということだね。理解できてなさそだけど。 >>313 だって>>312 でまた「全ての」アプリの設定記述を満たすものがあるのかとか言ってるじゃん つまり「一部の」アプリ設定記述を満たすものはあるって 納得してるんでしょ? そして「一部」に含まれない、もっと別の高度なアプリの機能の 設定記述を満たすものはあるのかー!!!って アプリの機能を気にしてるじゃんw >>315 > テキストファイルとテキストエディタがあればどんな設定でも記述できるという主張かね? そりゃそうだろうね 使いやすいかどうかは別として 最初からそう言ってるんだが。 どんな設定だろうが、テキストに変換できる以上 テキストエディタで編集は可能。 ただし便利なインターフェースを作るためには 設定値だけでは無理。 メタ情報が必要。XML設定ファイルであれば そういうメタ情報を入れることはたやすいが、 世の中間違って使い方をして、独自のXML設定ファイルばっかり作るから 汎用の設定ツールを作ることができない 今日はあと一時間切ったぞ。 100レスまであと45もあるじゃないか >>228 ですでに書いたこと(わざとなのか知らんが、すでに答えたことを繰り返されるのは面倒だ) > 特定目的設定XMLで表現できない項目が出てきたらどうすんだ 結論を先にいうとそういうのはないと思ってる 設定のしやすさは別として(後述するがこれは解決できる問題) どんな設定であっても、キーとバリューのリストで設定できる 例えば、Firefoxのabout:config の例 設定名: devtools.performance.timeline.hidden-markers 型: 文字列 値: ["Composite","CompositeForwardTransaction"] (JSON文字列かな?) このような単純なキーとバリューのリストで保存されている。 これを見る限り、型としては最低限、文字列、整数値、真偽値 があれば必要十分なのだろう まあJSON文字列とか卑怯な物使ってるからねw もう少し便利にするならば、レジストリを参考して「複数行文字列」「変数展開が可能な文字列」や キーバリューのリスト型みたいなものがあるといいだろう で、開発の初期段階であれば、どんなに複雑な項目であっても 最悪JSON形式の文字列でテキストエディタで保存すればOKということ。 JSON設定ファイルなんてものがあるんだから、それぐらい苦じゃないだろう?w でも、設定のしやすさの問題が残っている。エンドユーザーにとってはJSON文字列で設定するのは大変。 そこで出てくるのが・・・というかもったいぶって言うほどのことではなくウェブが すでにその問題を解決してる。CSSとJavaScriptでインターフェースを作ればいい。 そしてその値をフォームにマッピングする(例えばJSON形式で保存) 当然外部CSSとJavaScriptを使うため、設定ファイル自体はシンプルな状態を保つことができるし、 テキストエディタで編集したい人はそのまま編集できる。 それでいて設定ファイルをシームレスにユーザーインターフェースへとつなげることができる。 ウェブ技術の応用だからUIを作れる人は多いだろうし、なによりUIの作り込みは後からやれるから開発者の負担も減る 俺は面倒だから、基本的にIDを見てないんだが、 みてみたら同じやつじゃんw なんで繰り返しおんなじ質問するのかね? 言い方を変えてもいいな どんな荒唐無稽な設定データを想像してるのか知らんが、 テキスト形式の設定ファイルでは設定できないデータが あるというのなら諦めればいいだけだろう。 バイナリデータでさえBase64で保存できるというのに それがどんなものが設定ファイルに書けないのか、 俺にはわからんが、それは諦めるという方向でいい。 で、諦めなければならないもの例をあげてくれ。 俺には全く思いつかない。まあ無いんだろう。 そういや今はCSSファイル(当然テキスト形式)に 画像データをBase64エンコードして入れられることを思い出した。 おとなしくなったようなので、続き(?)を 汎用のXML設定ファイル形式(おれのかんがえたさいきょうってやつw)は、 HTMLのフォームを参考にすれば良いと言ったが、欠点もある そこはHTMLフォームを厳守しろっとは言ってないので変えればいいだけだが、 リストやハッシュデータの扱いが難しい。もちろんできないわけじゃない。 PHPやRubyはフォームの名前を工夫することでリストやハッシュを表現している 例えばこんな感じだ <form> 名前:<input type="text" name="personal[name]"> 住所:<input type="text" name="personal[address]"> 電話:<input type="text" name="personal[telephone]"> </form> これで少なくともJSONなみの表現力は得られるわけだがやっぱりダサいと思う <form> <fieldset name="personal"> 名前:<input type="text" name="name"> 住所:<input type="text" name="address"> 電話:<input type="text" name="telephone"> </fieldset> </form> こんな感じで直感的な仕様にしたほうが良いだろうな >>267 こんなひどいストローマン久しぶりに見たわwww 「xmlの拡張」の文節はどうとでも解釈できるのに最終的にスキーマを新しく作るってことを「xmlの拡張」と呼ぶらしいぞwwww 普通、「xml(の言語仕様)の拡張」と受け取るよな。 で、間違ったxml使ったアプリの例はいつ出してくれんだろう。 具体的なアプリ名はスレのどこにもなさそうだけど。 ていうか、文章能力なさすぎだろ、間違ったxmlって同じ属性が2つ書かれてるとかぐらいしか思いつかないけど、なにを指してるんだろ。 あとjsonの例は、xmlが文章以外にもデータ記述子として使われることもあるので、設定ファイルに置いてjsonと比較されるのはなんの不思議でもない。 設定ファイルに直接コメント書きたいらしいが、ドキュメント書いてくれればなんの問題もない。 一つのファイルに書くことがそんなに重要ならテキストファイルの中にjson書いて、jsonだけ受け取れば十分だろ。 >>323 まあ全体的に ID:3OE6BV46 は何を言ってるのかよくわからんよ。 わかってないからいろいろごっちゃにして勘違いしてるんだろうさ。 XMLの拡張、なにがいいたかったんだろうね 俺は、XMLは eXtensible Markup Language(拡張可能なマークアップ言語)の 略だと言っただけなんだよね。だからこの文脈では名前に入ってる「拡張可能」の 意味で解釈してもらわないと XMLを拡張してXML 2.0を作るとか言う話じゃなくて そもそもがXMLは拡張可能なマークアップ言語として作られたものなんだよって 話をしてるだけなんだが、基本がわかってないからいつもずれてしまって話が通じない。 XMLは言語を記述するための言語とも言われてるね ってかお前か、いつものキチガイw まーた、わざとらしい間違いしてくるし、 俺が、XMLの間違った使い方といったら、 お前は、XMLの文法ミスのことなんだって まーた間違えるし、本当に話が通じない 説明済みのことを何度も聞いてくる > で、間違ったxml使ったアプリの例はいつ出してくれんだろう。 間違ってないXMLベースの設定ファイルを使ってるアプリなんて存在しないよ。 > 設定ファイルに直接コメント書きたいらしいが、 はい、また。そんなこと言ってない。 > ドキュメント書いてくれればなんの問題もない。 ドキュメントは設定ツールとして生かせない > 一つのファイルに書くことがそんなに重要なら はい、また、そんな事も言ってない > テキストファイルの中にjson書いて、jsonだけ受け取れば十分だろ。 jsonでは機能不足だってすでに説明済み ほんとなーずーっとXMLベースの汎用的なXMLスキーマを作って、 設定ツールで設定するという話をしてるだろうに一体いつになったら 嘘吐くのやめてくれるんだろう? 俺が言ったことにして、話を混乱させてる こいつの設定XMLでできないことは無いと断言しながら できないことがあったら諦めろとかどんな神経したら書けるんだろうな バイナリバイナリってバリューの話だけでデータ構造の話は出てこないのか(笑) >>327 敵味方の二元論しか受け取れないのやばいけど、レスの内容が理解できてないから勘違いするんだ。 ちゃんと読めよ。 >>330 > こいつの設定XMLでできないことは無いと断言しながら > できないことがあったら諦めろとかどんな神経したら書けるんだろうな また、嘘書いてる。 そんなことは一言も言ってません。 もし本当にできないことがあるというのなら諦めるよ? だからできないことがあるというのなら、言ってみろ まああるわけないけどね、って書いてるんだ。 >>328 >XMLの間違った使い方 >>248 >アプリ独自の設定ファイルは間違った拡張をされている 表記ゆれが紛らわしいんだが、これらは同じ意味か?文法ミス以外で言語で間違うってなに? それは主観的な間違いなんじゃないの?間違いと感じただけ? >>331 > バイナリバイナリってバリューの話だけでデータ構造の話は出てこないのか(笑) それも>>322 で書いた。 いくら俺がいないすきを狙って、嘘をついても、 こうやってばれるんだからいみないよ? >>334 ほんとお前に日本語の読解力がないのなw 道具の間違った使い方だっていってんだろう 設定ファイルをXMLにする意味がないから、間違った使い方 >>336 「XMLの間違った使い方」って書いてたのを「道具の間違った使い方」って書いてたことにするのか? XMLは物理的な道具じゃないからXMLをなにかの道具に例えたんだな。さあ、教えてくれ、XMLはなんの道具なんだい? ちなみに「道具の間違った使い方」の文節は初めて出てきたよ。びっくりだよ。 >>337 このレスは君のレスかい? >>919 >HTML風XMLの設定ファイルは開発者が作成するもの 君はXMLを設定ファイルにするのは諦めたってことかい? アプリの設定ファイルをXMLにされるのはおかしいと思ってたから伝わっているならそれが何よりだよ。 お前らが熱い討論してる間、俺は洪水の電柱が危険だということを知ったから、お前らにも教えといてやるよ https://gfycat.com/gifs/detail/unacceptableangryfossa お前らも有事には気をつけろよ >>338 道具と言われて、物理的なもの限定って思うのか・・・ Officeソフトは道具じゃないんですねーw ほんと日本語のレベルであやしいや >>339 > >HTML風XMLの設定ファイルは開発者が作成するもの > 君はXMLを設定ファイルにするのは諦めたってことかい? HTML風XMLは、XMLだろ・・・ 和風ハンバーグはハンバーグじゃないっていう理論か? 日本語のレベルで(ry あれでもおかしいぞ〜。 >設定ファイルをXMLにする意味がないから、間違った使い方 って意味なら >間違った拡張 の拡張の意味が浮いちゃうな〜。拡張はxmlの<拡張可能な>から取ってきたんじゃなかったんだっけ? 表記ゆれが激しくて、それぞれが突っ込まれると微妙に違うことを言ってるから矛盾してきちゃったな〜。 単純に >アプリ独自の設定ファイルは間違った拡張をされている >設定ファイルをXMLにする意味がないから、間違った使い方 が同じ意味だと思っているなら文章能力も読解力もないって言われて当然。 普通になにを言ってるかなぞ。せめて訂正とかしてほしい。 >>340 > アプリの設定ファイルをXMLにされるのはおかしいと思ってたから伝わっているならそれが何よりだよ。 別にアプリの設定ファイルがXMLでも問題ない。 ただXMLにするメリットがない使い方ばっかりされてる 他の形式に比べて冗長なのは言うまでもなくわかってること その冗長さを上回るメリットを見つけていない 汎用的なXML設定ファイルのスキーマ (HTML風のXML、どういうものかは上の方に具体的に何回も書いた) を作れば、XML設定ファイルは大きなメリットを得られる 具体的には、汎用の設定ツールで設定可能になる。 アプリ開発者がわざわざ手間ひまかけて設定ツールを作る必要がなくなる。 アプリ開発者はXML設定ファイルを選ぶだけで恩恵が得られる ユーザーも難解な設定ファイルをテキストエディタで間違えないように 修正する必要がなくなる。GUIから簡単に設定できるようになる 作り込めば、より便利なインターフェースを作ることもできる それでいながら、初期段階はテキストエディタで簡単に修正することもできる もう何度同じことを言っただろうか? xmlくんはなにが言いたいのやらさっぱりわからん。 >>343 officeは文章作成のための道具だろ? xmlはなんの道具だよ? >>344 だから「拡張可能」の拡張だって何度も言ってるだろ そして、お前は自分でXMLをベースとして新しいタグを作ることが 拡張だって理解したはずだよな? > ODFなど様々なXMLベースの仕様が作れるほど拡張可能な素晴らしいマークアップ言語だろ > ただ世の中XMLを間違った拡張をした独自の設定ファイル形式が多いってだけ ↑ 世の中のアプリは独自でタグを作りまくってるから、それが間違った拡張だと 最初からずーっと書いてある。 >>346 > xmlはなんの道具だよ? マークアップ言語を作るための道具 拡張可能という意味を持つXMLが可能な 拡張を行って独自のタグ(スキーマ)を作るための道具 いいか!みんな!!xmlくんは「間違い」ってことを >別にアプリの設定ファイルがXMLでも問題ない。ただXMLにするメリットがない使い方ばっかりされてる と表現し直した! >設定ファイルをXMLにする意味がないから、間違った使い方 >アプリ独自の設定ファイルは間違った拡張をされている >設定ファイルをXMLにする意味がないから、間違った使い方 と散々意味不明な言い分で「間違った」と言っておきながら「メリットがない」と変更した。 これが典型的なストローマン論法だ。「間違った」と「メリットがない」が内を平気で混同する主観的な主張を繰り返してるだけだ。 これ以上価値のないレスをするな。 こいつはXMLはタグでデータ構造を作るってだけで、 タグの種類は定義されてないってことも知らないんじゃないだろうか? みんなXMLを使ってなにかのデータ構造を作るときは XMLを拡張して使ってるんですよ? >>350 ん? 確かにより適切な意味に変更したが? 違う意味に変更したわけじゃないから問題ないだろ なに重箱の隅ばかりついてるんだよw その行為に意味はないぞ。 > と散々意味不明な言い分で「間違った」と言っておきながら「メリットがない」と変更した。 メリットが無いから間違った使い方だって書いたろ? やっぱり日本語の時点でおかしいんだよな。 権力のある人が他人の作ったアプリの構造の「メリットがない」と「間違った」を言い間違えたら訴訟レベルだな。 >>352 >>353 その理論は流石にゴリ押しできないぞ。素直に訂正といえばいいのにw >>348 さっぱりわかんないぞ。officeはアプリでツールで道具だけど、XMLは言語だろ。XMLはXMLのための道具なのか? なんで「メリットがない」と「間違った使い方」をごっちゃにしてるんだろう? 根拠と結論の関係なんだが? まあここでネタバレすると ID:rkXy/Ofn がやってるのは議論じゃない 俺への攻撃だ。 この指摘だけでも、読む価値がないとわかるだろう? XMLが文章のための道具とかXMLがデータ交換のための道具とかXMLがフィードのための道具って言うならわかるけど、 XMLはマークアップ言語のための道具ですか、理解に苦しむわ。 >>355 > XMLはXMLのための道具なのか? はい、もう10回目ぐらいかな? そんな事は言っていない XMLは言語を作るための言語 http://www.atmarkit.co.jp/ait/articles/0012/23/news002.html > XMLを用いて新しい言語を作る場合 http://www.atmarkit.co.jp/ait/articles/0005/22/news009.html > XMLはメタ言語である。メタ言語とは、言語を記述するための言語という意味である。 http://park18.wakwak.com/ ~little-box/xml_basic/1-002.htm > XMLは、"何をどう表現するか自由に定義できることから、"住所録用のXML"、"Webページ用のXML"、 > "論文用のXML"といったように、新しい言語を作ることができます。 https://www.milk-island.net/document/xml/kihon/b1/ > XMLとは言語を作るための言語。 >>357 お前が理解できてないだけだよw >>358 を読んで反省したら? >>356 攻撃じゃない。アホだからからかってやろうとも思ってるけど、 さんざん「間違い」って言ってきたやり取りを、いきなり「メリットがない」に変えたら、今までのやり取りの意味がなくなる。 もっと言えば、「メリットがない」ってことを「間違い」って書いてたらそりゃ意味が通じるわけがないでしょってこと。受けての問題じゃない、発信側の問題。 https://www.ibm.com/support/knowledgecenter/ja/ssw_i5_54/rzakl/rzaklintro.htm > XML を使えば、名前、肩書き、住所、郵便番号などのように特定の必要に応じた方法で > 情報を記述する一連の規則やタグを含む独自のマークアップ言語を作ることができます。 http://www.techscore.com/tech/XML/Basic/Basic1/1_1.html/ > ひとつめの特徴は、SGMLが「言語を作る言語」、メタ言語と呼ばれるものであることです。 > SGMLそのものは、言語ではありません。SGMLにより、ユーザの環境に合わせた”フォーマット”を > 作成することができます。 > HTMLはSGMLにより作成された、代表的な言語です。 http://www.techscore.com/tech/XML/Basic/Basic1/1_1-2.html/ > XMLはインターネットの標準としてW3C(*1)より勧告されたメタ言語です。SGMLをよりシンプルに、 > 利用しやすく発展させたものが、XMLです。XMLは、SGMLの2つの特徴 (「メタ言語、マークアップ言語)で > あることを受け継いたため、インターネット上でのデータ交換に非常に適した技術であるといわれています。 >>360 > さんざん「間違い」って言ってきたやり取りを、いきなり「メリットがない」に変えたら、今までのやり取りの意味がなくなる。 だから、メリットが無いから間違いだって言ってる。 間違いを撤回などしてない 正しくは「XMLにするメリットが無い」から「XMLの間違った使い方」 だと言ってる。 こいつは中途半端に文章をぶった切って 違う意味にしようとするからな。用心のため 「メリットが無いから間違い」この命題は間違ってるだろ。論理性のかけらもないだろ? クソめんどくさい。 もう寝るからxmlについて重大な誤解をしてるxmlくんに忠告だけど、 xmlスキーマは名前空間を定義しないとタグが重複するから定義するだけで、重複がない独自タグをアプリ内で使うのは自由。 独自タグを使っただけで間違いとは言えない。独自タグを使うメリットはアプリ独自の解釈ができるからでこれも間違い。 主張は間違ってる。 ちなみに名前空間の設定だけでは他のアプリが解釈できるわけじゃないから、スキーマに加えてオントロジーを定義する。 これでやっと独自タグが他のアプリからも読める。(アプリがオントロジーとスキーマを参照して機能を割り当てることによって。) でも設定ファイルは特定のアプリから読むだけだから不要。 話の発端の設定ファイルを編集する汎用ソフトはめんどくさいし不要。 誰一人、設定ファイルのためだけにxmlスキーマもオントロジーの定義もしない。そのほうが面倒くさいからだ。 >>365 > 独自タグを使っただけで間違いとは言えない XMLの文法的に正しいか間違っているかの話なんかしてない 設定ファイルにアプリ独自のタグを量産するのは XMLの間違った「使い方」だって言ってるの 使い方の話 やっぱりまた日本が通じない >>365-366 は意味不明なことを言ってるから誰も理解できないと思う だから代わりに俺が言ってることをまとめよう。 今のアプリでよく行われてるようにXMLを独自で拡張して オレオレタグを作るというやり方は間違ったXMLの使い方 なぜならそんなことをしてもメリットがなにもないからだ。 XMLを拡張して汎用的な新しい言語を作れば、 汎用の(例えばGUIの)設定ツールを作ることができる そうすれば、ユーザーは設定が簡単になるし、アプリ開発者はいちいち自分のアプリのために 設定ツールを作らなくてすむし、それでいて今までどおりテキストエディタで編集も可能 >>222 と >>224 に、今の間違った使い方と、あるべき使い方の例を書いておいた >>292 にも別のパターンを書いた。 >>228 ではどんなデータでもこれで扱えるという話、そしてUIの作り方を書いた。 >>322 ではリスト構造、ハッシュ構造を作る方法を書いた 222の間違った使い方では、アプリごとに独自のタグを作るから、どうしても汎用の設定ツールが作れない せいぜいXMLエディタというXMLの形で編集するツールが作れるぐらいだ。それは何も使いやすくない 224の例からは、アプリごとの独自のタグはない事、独自のタグの名前がname属性になっていることが読み取れるだろう 292の例では何が選択可能で、今どんな値が設定されていて、デフォルトの値が何かが 設置ファイルにかかれており、それを汎用の設定ツールから読み取ることができる 独自のタグを作っていたらこんな事はできない。 なにか意見を言うのなら、ここまで具体的に書いてほしいものだ とりあえず掲示板の使い方間違えるのやめてほしいな。 >>369 良い皮肉だ。 やつなら、掲示板に文法ミスでもあるんですかーとかいいそうw 書き込めるならどんな使い方でも、正しい使い方ですってな。 xmlくんは自分への皮肉を他人への皮肉だと受け取った模様。 まあXMLくんは抽象論ばかりじゃ嫌になるだろうから具体論として とりあえずsmb.conf、DNSゾーンファイル 、cron、bashrcぐらいを さいきょうの設定XMLで書き直してどれぐらい便利かアピールしてくれよ 他にもミスしやすいシリアル値を自動入力できるようになる cronだと日本人には分かりづらい日時の並び順を 分かりやすくすることができる barshrcは設定ファイルでなくスクリプト。引っ掛けかな?w まあスクリプトでもtextariaを使うことはできるし シンタックスハイライトぐらいやれるだろう XMLを見せて欲しいと書いたんですよ? UIじゃない。 smbも一項目じゃなくてそれなりに動きそうなもの示してくださいよ。 >>378 引っ掛け問題のつもりはないですがどんなソフトの設定ファイルてもかけると豪語してるのだから bashrcが書けないとは思えないので設定XMLのサンプルよろしく。 >>381 <textarea> ここに好きなbashrcのコードを書け </textarea> >>377 であればこんな感じかな <table> <tr><th>ホスト名</th><th>タイプ</th>・・・</tr> <tr> <td><input type="input" name="hostname1"></td> <td><select name="type1"><option>A</option><option>MX</option></td> ・・・ </tr> <tr> <td><input type="input" name="hostname2"></td> <td><select name="type2"><option>A</option><option>MX</option></td> ・・・ </tr> </table> ただこれには問題がある。それは<option>の部分が重複しているということ これはHTML5のdatalistを参考にしてselectで使用すれば一応解決できる <datalist id="types"> <option>A</option> <option>MX</option> </datalist> <table> <tr><th>ホスト名</th><th>タイプ</th>・・・</tr> <tr> <td><input type="input" name="hostname1" /></td> <td><select name="type1" list="types" /></td> ・・・ </tr> <tr> <td><input type="input" name="hostname2" /></td> <td><select name="type2" list="types" /></td> ・・・ </tr> </table> ただまだ冗長さは感じる。やはり配列型が必要だろうか inputのtype、いっその事タグにしたほうが良いかもしれない HTML5でも大して数があるわけじゃないし というか間違ってたなw type="input" じゃなくて type="text" だ ついでに値も入れてみる。ここもHTMLとは違う方法にする <datalist id="types"> <option>A</option> <option>MX</option> </datalist> <table> <tr><th>ホスト名</th><th>タイプ</th>・・・</tr> <tr> <td><text name="hostname1">www.example.com</text></td> <td><select name="type1" list="types">A</select></td> ・・・ </tr> <tr> <td><text name="hostname2">mx.example.com</text></td> <td><select name="type2" list="types">MX</select></td> ・・・ </tr> </table> >>382 久しぶりにこんなひどいウンコードみたwwwww <datalist id="types"> <option>A</option> <option>MX</option> </datalist> <table name="records"> <thead><tr><th>ホスト名</th><th>タイプ</th>・・・</tr></thead> <tr> <td><text name="hostname">www.example.com</text></td> <td><select name="type" list="types">A</select></td> ・・・ </tr> <tr> <td><text name="hostname">mx.example.com</text></td> <td><select name="type" list="types">MX</select></td> ・・・ </tr> </table> 配列型を考えてみた、table要素だとtbody(省略可能)以下のtrが自動的に配列となる) データとして取り出すと、以下のように見える records:[ { hostname: 'www.example.com', type: 'A' }, { hostname: 'mx.example.com', type: 'MX' }, ] >>386 bashrcの中身見たことある? こんなコードだよ。設定じゃない。 そんなこともわからないレベルなんだろうなーとしか思わんさw # System-wide .bashrc file for interactive bash(1) shells. if [ ! -e "$HOME/.sudo_as_admin_successful" ] && [ ! -e "$HOME/.hushlogin" ] ; then case " $(groups) " in *\ admin\ *|*\ sudo\ *) if [ -x /usr/bin/sudo ]; then cat <<-EOF To run a command as administrator (user "root"), use "sudo <command>". See "man sudo_root" for details. EOF fi esac fi >>388 textareaの中にbashのコードがあるとどうやったら解釈できるの? UIとして考えると、レコードの追加、削除も必要になる。 それは属性として書けばいいだろう。 削除は単に属性つければ削除ボタン追加できるが 追加の場合は、どんな内容を追加するのかを書かないといけない コレはHTMLのtemplateを参考にするとしよう <datalist id="types"> <option>A</option> <option>MX</option> </datalist> <table name="records" deletable="true" appendable="record"> <thead><tr><th>ホスト名</th><th>タイプ</th>・・・</tr></thead> <tr> <td><text name="hostname">www.example.com</text></td> <td><select name="type" list="types">A</select></td> ・・・ </tr> <tr> <td><text name="hostname">mx.example.com</text></td> <td><select name="type" list="types">MX</select></td> ・・・ </tr> </table> <template id="record"> <td><text name="hostname"></text></td> <td><select name="type" list="types"></select></td> ・・・ </template> >>389 質問の意味がよくわからんがシンタックスハイライトの話かな? <textarea lang="bash"> bashのコード </textarea> とすればいいだろう。 もちろんこれは設定ファイルであって、bashrcとして実行可能にするには 設定からコードを生成しなくてはいけない。 でもそれは別のツールの話 一応>>390 でXMLとしてはDNSのレコードを編集することは可能になるが ちょっと冗長だから、テーブルの項目名が同じ場合専用の簡易版を作っても良いかもしれない 追加する場合のテンプレートはデフォルト空でよければ不要 <datalist id="types"> <option>A</option> <option>MX</option> </datalist> <tablelist name="records" deletable="true" appendable="true"> <thead> <tr> <th type="text" name="hostname">ホスト名</th> <th type="select" name="type" list="types">タイプ</th> ・・・ </tr> </thead> <tr> <td>www.example.com</td> <td>A</td> ・・・ </tr> <tr> <td>mx.example.com</td> <td>MX</td> ・・・ </tr> </tablelist> まあいまざっくりと考えながら書いてるんで 穴とかあると思うけど結構面白いな。 XML設定ファイルでありながら、汎用の設定ツールの たたき台のたたき台ぐらいにはなりそうw 今ひらめいたけど、>>392 のレコードを追加可能にする仕様 テーブルの最後に追加するか、途中に追加できるのか?は 設定ファイルに書く必要はない それは設定ツールの実装に任せればよい。 間に追加してもいいし、最初や最後にしか追加できなくても良い ツールによっては、レコードを絞り込むフィルタ機能や並び替え機能も つけてもいいだろう。 所詮、テキストである設定ファイルの項目を 増減したり並び替えたりするだけだから問題は起きないだろうし。 本質的には設定ツールはテキストファイルの内容を (使いやすく)書き換えるだけに過ぎないしね >>391 UIの話してんの?htmlでホームページ作れるよってこと? >>395 設定ファイルの話。 設定ファイルをXML形式にする・・・というのは それなりに行われているが、単に冗長になっただけで テキストエディタで編集しづらく、大したメリットがない。 だけどそれはXMLの使い方を間違えているからの話。 (他の形式に比べて)冗長なのはXMLである以上どうしようもないが、 メリットを出すことはできる。 それが汎用のXML設定ファイル形式(XMLを拡張してスキーマを定義する) HTMLを参考にしてXML設定ファイルはタグが定義されているため 汎用の設定ツールを作ることが可能になる。 アプリの作者は単にその汎用のXML設定ファイル形式を採用するだけで 設定ツールの作成は他に任せることができる。 汎用の設定ツールはユーザーフレンドリーなツールで 例えば選択項目であれば選択候補を表示したり、 もちろん実装次第だが、ウェブサイトで見たことがあるような設定画面を 設定ファイルから作り出すことができる。多言語対応なども可能 ブラウザで表示したHTMLファイルのフォームの値を変更して、 そのまま元のHTMLに保存できるような感じ そのような高度な設定ツールを使うことが可能な、 汎用のXML設定ファイル形式を作る・・・というふうに 世の中がなっていたら良かったのにという話 つまり、世の中はXMLの使い方を間違ったよなーって話をしてるだけ >>396 単にホームページを作ってカスタムしたい設定ファイルをDLできるようにすれば良いんじゃね? なんでも表現できる君なんだから 欲しいと思う人は各々スキーマなりスクリプトなり勝手にこしらえればいいんじゃね って事じゃないかな もう <textarea> ここに〇〇の設定ファイルを書け </textarea> でいいんじゃね? スーパーGUI設定ツールにハイライトや補完他色々して貰えばOK >>400 必死にならなくていいよw お前のアイデアはクソ 汎用XML設定ファイルの足元も及ばない 汎用設定XMLを使って専用GUIも使うと言ってるのに何が不満なんだろ そりゃGUIからの設定がしづらいからだろ? HTMLのフォームに似た要素ががある汎用XML設定ファイルなら 設定しやすいGUIが作れる。 GUIだったらどんなものでも満足するんだろ? みたいな考え方じゃないんだよ 汎用XML設定ファイル専用GUIをもっと高機能にすれば解決ですね! 開発頑張ってください! いや全然よくわかんないんだけど、 >ブラウザで表示したHTMLファイルのフォームの値を変更して、 >そのまま元のHTMLに保存できるような感じ これはjavascriptでhtml生成して保存とかでいいんじゃ。。<textarea>で何でもかけるとか言い出したらもうタグの意味さえないけど。 >>405 > これはjavascriptでhtml生成して保存とかでいいんじゃ。。 変更したいのはフォームの値だけなのに、面倒くさいだけじゃん > <textarea>で何でもかけるとか言い出したらもうタグの意味さえないけど。 それは設定ファイルの話をしてるのに、 実行可能コードをどうやって設定ファイルに含めるのか?とか 言い出したやつへの皮肉だな >>404 GUI(設定ツール)の開発とXMLスキーマの定義は別々に考えよう >>406 えwxml君の言うとおり、フォームの値を入れるだけだろもちろん。 ブラウザにそんな機能ないからjavascriptで足してやればいいじゃん。それともブラウザを一から開発するのか? >>408 開発する必要があるのは設定ツールだよ ブラウザ技術を応用する。さすがにブラウザそのものは機能が多すぎる そしてその設定ツールを作る前段階のXMLの使い方の話をしている。 汎用のXML設定ファイル(XMLをベースに拡張して独自のタグを定義したもの)は 設定ツールがなくてもテキストエディタで修正できる。だから設定ツールの存在は必須ではない 設定ツールの存在は必須ではないが、XMLをテキストエディタで修正するのは面倒 設定ツールがあれば設定は楽になるが、今のいろんなアプリの設定ファイル(XMLを使ったもの)は 独自のタグを定義しているため、アプリ専用の設定ツールを作る必要がある。つまり開発コストが高い だから設定ツールはなくXMLファイルをテキストエディタで修正するにとどまっている もし汎用のXML設定ファイル(XMLをベースに拡張して独自のタグを定義したもの)があれば そんな状況は変わっていただろう。今頃はどんなアプリでも同じ設定ツールを使って 初心者でも簡単に設定できていた つまり、世の中はXMLの使い方を間違ったよなーって話をしてるだけ さて、無理やり軌道変更しようとしていたようだが、 世の中はXMLの使い方を間違ったよなーって話に 軌道修正できましたかね?w 突っ込まれるとややこしくなりそうな問題から逃げ回るのを軌道修正というのか ん? >>220 のときから書いてあるように 「世の中はXMLの使い方を間違ったよなーって話をしてるだけ」に 戻しただけですが? 何度言っても理解しないで、 俺にツール作れとか言い出すからね ちゃんと言っておかないと 単純な話なんだけど、世界中で使われてるxmlの応用例を間違ってると言って自分が考える正しい使い方を披露しても、スタンダードの方が効率的で合理的だと思われるのは自然。 設定ツール無しでこんな複雑なXMLを手で編集しろと言われても メリット無いだろ 設定ツールが無いとまともに扱えないようなXMLをテキストエディタでも大丈夫と 設定ツールの話を避けられても ODFはLibraOffice使わずともviで書けますと言うようなもんだ >>414 思うとかじゃなくて、ちゃんと理由をいいなよw それじゃ素人の意見じゃん >>415 > 設定ツール無しでこんな複雑なXMLを手で編集しろと言われても > メリット無いだろ だって手で(テキストエディタ)で修正するのは、開発者や技術者のために そういうことも可能ってだけだから。普段は設定ツールで設定すれば良いんだよ 開発が進んで育てれば、設定ツール用のUIが追加されていくが、開発の初期段階とか 設定ツールのことは考えないって決めれば、設定項目を羅列するだけでも良い 例えば上の方で「設定ツールでユーザーが候補から選べるように<select>を使用する」と言って 以下のようなタグを書いたが、 <select name="item" value="a"> <option>a</option> <option>b</option> </select> 開発の初期段階とか設定ツールのことは考えないのであれば、以下のように書いてもいいわけだ <input name="item" value="a"> どちらも設定内容としては同じ。これは複雑なXMLではない。 複雑なXMLになるのは設定ツールのためにそうするのであって、 それなら設定ツールでやれるようになるわけだよ >>416 あまりにもクソコード過ぎて素人でも説得力ないってわかるって言いたいだけだよ。 selectにしろ、inputにしろ、それがどの設定における値なのかわからないってことぐらいわかるだろ。 開発者でもツールが無けりゃこんなもの扱う気なくすわ まあだからxmlは今人気がないわけで。 xmlはあくまで文章なんで、officeに使われてるのもそれが理由だろ。昔はバイナリだったが。 こんなXMLはひどいと言われたらツールの支援があると逃げ ツールの話になるとXMLの使い方の話だと逃げ 立場を変えるなあと思ったら ついにはXMLの悪口言い出したか >>418 > selectにしろ、inputにしろ、それがどの設定における値なのかわからないってことぐらいわかるだろ。 いや、名前で見分けろよw <select name="url"> とかでわかるだろw >>421 同じことを繰り返すな >>396 ですでにまとめてる 設定ファイルの話。 設定ファイルをXML形式にする・・・というのは それなりに行われているが、単に冗長になっただけで テキストエディタで編集しづらく、大したメリットがない。 だけどそれはXMLの使い方を間違えているからの話。 (他の形式に比べて)冗長なのはXMLである以上どうしようもないが、 メリットを出すことはできる。 それが汎用のXML設定ファイル形式(XMLを拡張してスキーマを定義する) HTMLを参考にしてXML設定ファイルはタグが定義されているため 汎用の設定ツールを作ることが可能になる。 アプリの作者は単にその汎用のXML設定ファイル形式を採用するだけで 設定ツールの作成は他に任せることができる。 汎用の設定ツールはユーザーフレンドリーなツールで 例えば選択項目であれば選択候補を表示したり、 もちろん実装次第だが、ウェブサイトで見たことがあるような設定画面を 設定ファイルから作り出すことができる。多言語対応なども可能 ブラウザで表示したHTMLファイルのフォームの値を変更して、 そのまま元のHTMLに保存できるような感じ そのような高度な設定ツールを使うことが可能な、 汎用のXML設定ファイル形式を作る・・・というふうに 世の中がなっていたら良かったのにという話 つまり、世の中はXMLの使い方を間違ったよなーって話をしてるだけ 本人は何も考えてないだろうけど この設定記述XMLには 設定値の保存のみではなく、 構造の定義やスキーマ他メタ情報、 データ型、バリデーションの記述、 UIやフォームのインターフェイス作成、 オブジェクトマッピングの定義など(まだまだあるかも)の機能や規格が必要で 規格書が電話帳のようになり実装可能だとしてもフットプリントは巨大になるのは間違い無いな そりゃ規格なんだからある程度の量にはなるが、 基本はXMLなのでXMLとしての仕様は不要 タグ一覧があれば十分だろ 少なくともHTMLの仕様よりは大きくならない > 設定ファイルをXML形式にする・・・というのは > --- (中略) --- > 汎用の設定ツールを作ることが可能になる。 ここまでは、まあ分かるが > アプリの作者は単にその汎用のXML設定ファイル形式を採用するだけで > 設定ツールの作成は他に任せることができる。 これが分からん。 現状のwel-formedなだけのXMLでも可能でしょ? 設定ツールやスキーマなど必要なものの作成は他に任せりゃいいだけで アプリの作者は今のまま何の負担もない。 なぜ作者にとって本来不要な手間のかかる俺ルールを押し付けるのか意味が分からない。 一ユーザーの立場からするとそんなつまらんものに時間を割くぐらいなら 他の事をやるなり体を休めてくれとか思うな >>426 > 現状のwel-formedなだけのXMLでも可能でしょ? > 設定ツールやスキーマなど必要なものの作成は他に任せりゃいいだけで > アプリの作者は今のまま何の負担もない。 それだとアプリごとに設定ツールを開発しなければいけなくなる。 今度は設定ツールを開発する側の負担が大きい(だから設定ツールは作られない) > なぜ作者にとって本来不要な手間のかかる俺ルールを押し付けるのか意味が分からない。 必要最低限の使い方でいいなら使用するタグは<input>タグだけで成り立つよ <input>タグのname属性が設定項目名になる。 今はほとんどが設定項目の名前をタグにしてるが、 それをname属性に変えるだけなんだよ。 アプリ作者の手間にはならない。 そしてHTMLライクなXML設定ファイルだから、プログラマじゃない人でも手伝える。 アプリ開発者がアプリ本体を開発間に、他の人が使いやすい設定ファイルを 作ってくれることも期待できる。 > それだとアプリごとに設定ツールを開発しなければいけなくなる。 そうならないような設定ツールを作るなり スキーマなりスクリプトなどで扱える形なり 工夫すればいいだけじゃないの > 今度は設定ツールを開発する側の負担が大きい(だから設定ツールは作られない) ようするに設定ツールの作者個人のスキルが足りなかったり手間を掛けたくないから 全てのアプリ作者に無駄な作業を強いるって事ね > 今はほとんどが設定項目の名前をタグにしてるが、 > それをname属性に変えるだけなんだよ。 そんな程度なら相互の変換スクリプトでも噛ませばいいだけの話 > アプリ作者の手間にはならない。 ゼロじゃなければ意味ないよ > そしてHTMLライクなXML設定ファイルだから、プログラマじゃない人でも手伝える。 プログラム側でやってる全てのチェックをスキーマなりに落とし込む作業だからコードが読めないと無理では > そうならないような設定ツールを作るなり だからツールを作れるようにするために、汎用のXML設定ファイル というのを作るべきだってって言ってるんだが? 現状、どんなアプリの設定ファイルも設定できるツールないでしょ 現実に不可能だったという実例があるのに、そうならないように〜とか言っても意味ない > 全てのアプリ作者に無駄な作業を強いるって事ね 無駄じゃない。アプリの作者は自分でXMLの設定ファイルを考える必要がない 設定ツールを作る必要がない。というメリットが有る。 > ゼロじゃなければ意味ないよ 言葉遊びかな?ゼロじゃなければ意味がないというなら、 自分で独自形式を考えるのも時間がかかるからゼロじゃないってことになるね。 最初から汎用のXML設定ファイルを使うなら、 そこから別に物に変える必要がないのでゼロとも言えるw > プログラム側でやってる全てのチェックをスキーマなりに落とし込む作業だからコードが読めないと無理では プログラム側でやってるというなら、それに任せればいいだけだろ。 だからこの処理に相当するものはスキーマ(タグの定義)に入れる必要はない。 設定側でチェックをする必要はない。っていうかスキーマで設定値までチェックするとか勘違いしてるな?w スキーマにそんなものを入れるなんて言ってない。せいぜいどんなタグがあるかとその親子関係ぐらいだ スキーマで設定値のチェックまでやっていたら、設定ファイルごとにいろいろ作らなきゃいけなくなるだろ(頭が硬いぞw) HTMLの<input>タグの値だってスキーマで値のチェックまでやってないだろ。 まあこれは具体例を言わないと理解できないだろうから説明すると ある設定項目は、A、CNAME、AAAA、MX、という文字列のいずれかの値を設定できますってことなら そのチェックをプログラム側でやってるはずなので、設定ファイルにそんなものは不要。 設定ファイルの内容はこれ。現在設定されている値はAで、A、CNAME、AAAA、MXのいずれかを選択できる事がわかる <select name="type" value="A"> <option>A</option><option>CNAME</option><option>AAAA</option><option>MX</option> </select> 繰り返すが「いずれかを選択できる事がわかる」と言ったんだ。この値以外を設定したときのチェックまでするとは言っていない。 だってそうだろう?テキストエディタで変更すればなんでも設定できるんだから、 そんなものを設定ファイルに入れることなんてできやしない。 これは、コメントを発展させたものと考えれば良いんだよ # type: Select one of A, CNAME, AAAA, MX type=A ほら、typeにはBでもCでも好きなものを入れられてしまう。だから値のチェックはプログラム側でやることだしやってるはずだ。 そして英語がわかればどんな内容を設定できるかはわかるが、コメントから設定ツールのインターフェースは作れない しかし設定ファイル自体がXMLであれば、それを読み取って設定ツールのインターフェースとすることができる。 汎用のXML設定ファイルというのは、テキストエディタで変更可能という特徴も残しながら、 ユーザーに設定しやすいインターフェースを提供する設定ツールを作れるようにするのが目的 XML文化の汚点の一つだよな。 なんでもXMLでやろうとしてしまったことだな。 XMLはデータだけを扱っていればいいのに そのデータが正しいかどうかの検証もXMLでやりましょうとか XMLはデータだけを扱っていればいいのに、 別の形式にデータを変換する処理もXMLでやりましょう(XSLTのこと)とか 俺はXMLSchemaやそれ相当のものを使うとは一言も言ってないよ。 面倒だから使わないと言い切ってもいいやw 現状使わないでやってきてるんだから。 >>425 タグ一覧だけ作って…って馬鹿だろ 何指摘されているのか意味わかってないんだろ? 口だけの無能と言うのがますますバレますなあ あるアプリケーションの特有値は出来ないだろ。 例えばゲーム中に登場するキャラクターの変数とかどうすんだ? 全部nameにつめこむのか?もはやそれは独自タグと変わんないぞ。 nameの名前空間にカカロットとかベジータまで定義すんのかw >>429 > だからツールを作れるようにするために、汎用のXML設定ファイル > というのを作るべきだってって言ってるんだが? 繰り返しになるけど ようするに設定ツールの作者個人のスキルが足りなかったり手間を掛けたくないから 全てのアプリ作者に無駄な作業を強いるって事ね > 現状、どんなアプリの設定ファイルも設定できるツールないでしょ > 現実に不可能だったという実例があるのに、そうならないように〜とか言っても意味ない 存在しないから不可能だと決めつけるのは短絡的だよ、需要がないからだとか面倒だからとか他にも理由は考えられる > > 全てのアプリ作者に無駄な作業を強いるって事ね > 無駄じゃない。アプリの作者は自分でXMLの設定ファイルを考える必要がない 多くのアプリの作者は手近なシリアライザの書き出しがXMLというだけで気にしちゃいないと思うぞ > 設定ツールを作る必要がない。というメリットが有る。 元々設定ツールは必須じゃないし 設定弄るのなんてほとんど最初だけだから テキストエディタでの編集しやすさってのはさほど重要じゃない > 言葉遊びかな?ゼロじゃなければ意味がないというなら、> 自分で独自形式を考えるのも時間がかかるからゼロじゃないってことになるね。 XMLの使い方を間違った世の中を正す よりは XMLの使い方を間違った世の中に対応する ほうがよほどマシ と言えば分かるかな どんなに素晴らしいものであろうが、使い方を間違っていると因縁つけ続けようが 他人は思い通りに動いてくれないからね > プログラム側でやってるというなら、それに任せればいいだけだろ。 > 設定側でチェックをする必要はない。っていうかスキーマで設定値までチェックするとか勘違いしてるな?w 静的チェック可能ならメリットあるかと思って賛同したけど 素通りとなるとenumなどの設定が安全簡単になりますよってなぐらいで魅力は薄れるね >>430 > そして英語がわかればどんな内容を設定できるかはわかるが、コメントから設定ツールのインターフェースは作れない # type: Select one of A, CNAME, AAAA, MX type=A を <select name="type" value="A"> <option>A</option><option>CNAME</option><option>AAAA</option><option>MX</option> </select> と解釈すればいいだけの話だと思うけど >>431 > 俺はXMLSchemaやそれ相当のものを使うとは一言も言ってないよ。 >>426 は >>423 (ID:29LJB/lv) に向けた書き込みで > 423 名前:login:Penguin [sage]: 2018/09/16(日) 17:54:48.62 ID:29LJB/lv (5) > 設定ファイルをXML形式にする・・・というのは > それなりに行われているが、単に冗長になっただけで > テキストエディタで編集しづらく、大したメリットがない。 > だけどそれはXMLの使い方を間違えているからの話。 > (他の形式に比べて)冗長なのはXMLである以上どうしようもないが、 > メリットを出すことはできる。 > それが汎用のXML設定ファイル形式(XMLを拡張してスキーマを定義する) > HTMLを参考にしてXML設定ファイルはタグが定義されているため > 汎用の設定ツールを作ることが可能になる。 つまり 設定ファイルをXML形式にする・・・というのは 大したメリットがない。 メリットを出すことは スキーマを定義する とはっきり書いてあるぞ。 もし 427(ID:4205k3sJ) ≠ 423(ID:29LJB/lv) だとするなら なぜアナタが回答してきたのか疑問 >>432 なにか言い返せってw ほんと何も言えないくせにとりあえずなにか言い返そうとするよな >>434 > ようするに設定ツールの作者個人のスキルが足りなかったり手間を掛けたくないから > 全てのアプリ作者に無駄な作業を強いるって事ね 意味がわからん。その理屈で言えば、素人はプログラミングできないから プログラミングを勉強するのは、無駄な作業であるということになるぞ? プログラミングできるなら、そのスキルは当然ありますよね? > 存在しないから不可能だと決めつけるのは短絡的だよ、需要がないからだとか面倒だからとか他にも理由は考えられる だから「面倒」ってことだよ。ずーっといってるじゃん。 アプリごとに設定ツールを作るのは面倒。だから作られないと。 でも汎用のXML設定ファイルというのがあれば、アプリごとに設定ツールを作らなくてよくなる > 多くのアプリの作者は手近なシリアライザの書き出しがXMLというだけで気にしちゃいないと思うぞ はい、だからそれも同じで、単なるXMLのシリアライザではなく、 汎用のXML設定ファイル用のシリアライザを使えば気にしなくて良くなりますよね? アプリ作者の手間なんて殆どないよ。最低限<input>を覚えるだけですむ。(普通はそれ以上のことを知ってる) > 静的チェック可能ならメリットあるかと思って賛同したけど > 素通りとなるとenumなどの設定が安全簡単になりますよってなぐらいで魅力は薄れるね えとさぁ、もう少し柔軟な思考持ったほうが良いよw 「設定側でチェックをする必要はない」と言ったんだよ? プログラム側で今チェックしてるでしょ?愚直に値の範囲チェックとかしてさ それをプログラミングしてる側がXMLSchemaを使ってやるのは構わないよ 必要がないと言っただけで、やってはダメなんて言ってない。 理解すべきことは、設定ファイルを書く側は、チェック内容まで書く必要はないってこと 役目をしっかり分けて考えよう。 ・汎用のXML設定ファイル・・・アプリの設定値は仕様に含めない(含められない)。ただしタグの種類や親子関係は仕様として定義する ・設定ツール・・・汎用のXML設定ファイルを元に設定変更のユーザーインターフェースを提供する ・アプリ作者・・・読み書きは専用のシリアライザを使うだけ。読み取った設定値のチェック(やり方は自由)を行う。 >>436 XMLSchemaってなにか知ってる? 仕様として考えたスキーマを XMLで記述するための言語の名前がXMLSchema https://ja.wikipedia.org/wiki/XML_Schema > XML Schema(XMLスキーマ)は、XML文書の論理的構造を定義する為に > 開発されたスキーマ言語の一つ。現在、W3Cが開発・標準化にあたっている スキーマ = スキーマ(笑) スキーマ言語 = スキーマを記述する言語 この2つをごっちゃにしてはダメ 同wikipedia > しかし、複数の業界有力企業が仕様の策定に参加して、各社の思惑が絡み合い、 > あまりに多くの機能を取り込んだ為に、標準化は難航し、複雑な仕様となってしまっている。 複雑な仕様のものを使う必要はない 汎用のXML設定ファイルのスキーマは必要 汎用のXML設定ファイルにアプリ固有の情報(設定値の範囲などの)は 含まれない(というか汎用なんだから含められない) だけど それを利用したアプリ固有のXML設定ファイルのスキーマは必要ない アプリごとにスキーマの定義はしなくて良いんだよ そんな無駄で面倒な作業、誰がやるんだw (必要ないと言っただけで、やったらダメとは言ってない) 理想的な世の中 アプリ作者「設定ファイルの形式どうしよう? ini?JSON?YAML?XML?アプリ独自形式?」 アプリ作者「汎用のXML設定ファイル形式というのがあるのか? よし使って設定ファイルを書き出してみよう」 <?xml version="1.0" encoding="UTF-8" ?> <configurations> <input name="foo" value="1"> <input name="bar" value="item1"> <input name="baz" value="true"> </configurations> アプリ作者「ほうほう。これが汎用のXML設定ファイル形式というやつか シンプルで使い方も簡単だが、なにが便利なのかな?」 設定ツール作者「我々が開発した設定ツールでGUIで設定できますぜ」 アプリ作者「単にインプットボックスで変更できるだけではないのかな?」 設定ファイル利用者「設定ファイル改良してみました。使いやすいインターフェースになります!」 <?xml version="1.0" encoding="UTF-8" ?> <configurations> <input name="foo" type="number" min="0" max="100" value="1"> <select name="bar" value="item1><option>item1</option><option>item2<option></select> <input name="baz" type="checkbox" checked="true"> </configurations> アプリ作者「いいね!」 お前さんこんなギャグセンスがあるとは思わなかったぞ 目指せIT系漫談家 425 login:Penguin sage 2018/09/16(日) 20:03:57.41 ID:29LJB/lv そりゃ規格なんだからある程度の量にはなるが、 基本はXMLなのでXMLとしての仕様は不要 タグ一覧があれば十分だろ 少なくともHTMLの仕様よりは大きくならない いやいや、xmlの仕様は不要で、htmlの仕様よりは大きくならないタグ一覧 が理解できる人がいたら教えてくれ。本人以外でな。俺は意味がわからん。 >>433 は見逃してたわw 433が何を言ってるのかよくわからない アプリの設定と(セーブ?)データをごっちゃにしてるようにしか見えないな。 ゲームは特殊で基本的に、アプリ(つまりゲームない)で設定変更するものだから 例えに使うと分かりづらくなるからやめたほうが良い そうだな。ユーザーがアプリの動きを変更させるためのもので、 ユーザが作成したいデータではないものってことでいいかな? >>444 > いやいや、xmlの仕様は不要で、htmlの仕様よりは大きくならないタグ一覧 > が理解できる人がいたら教えてくれ。本人以外でな。俺は意味がわからん。 XMLの仕様はW3Cが作ってるんだから、わざわざ作る必要はない。 作る必要があるのは、汎用のXML設定ファイルの仕様 https://ja.wikipedia.org/wiki/Extensible_Markup_Language > XML の仕様は、World Wide Web Consortium (W3C) により策定・勧告されている。 必死に設定XMLの機能、使いやすさ、展望を語るたびに >>425 が光り輝くのであった そもそも、xmlは独自タグ多くて、読みにくいし書きにくいからめんどくさいわ。 っていう共通認識から始まってるのに、xmlの運用を変えれば便利になるよっていう意味わかんない蛇足をつけるからややこしくなるんだ。 >htmlの仕様よりは大きくならないタグ一覧 ってなんだよwブラウザよりは小さいアプリで足りるってことかよw 世界中でまともに使えるhtmlエンジンは2~3ぐらいしかないんだぞ。 ほんといい加減にしてくれ、知識をつけてから話に参加してくれ > そもそも、xmlは独自タグ多くて、 XMLにタグは定義されてない。一つもない。タグが定義されてるのは XMLを拡張して作ったXMLベースの言語でタグが多いかどうかは、その言語によるだろ これぐらいの知識もない状態でからんでくるから、わざわざ説明しなきゃいかん > >htmlの仕様よりは大きくならないタグ一覧 > ってなんだよwブラウザよりは小さいアプリで足りるってことかよw > 世界中でまともに使えるhtmlエンジンは2~3ぐらいしかないんだぞ。 まずな。引用してる部分がおかしいから。 「htmlの仕様よりは大きくならないタグ一覧」は俺が言った言葉じゃない 俺が言ったのは>>425 だ > そりゃ規格なんだからある程度の量にはなるが、 > 基本はXMLなのでXMLとしての仕様は不要 > タグ一覧があれば十分だろ > 少なくともHTMLの仕様よりは大きくならない >>424 が不要なものまでごてごてに付け加えて、あーたいへんだーって言ってるから 「汎用のXML設定ファイル」の仕様はタグ一覧程度で十分だって言ってんだよ UIとかフォームのインターフェースとか仕様に要らねぇよ。 汎用のXML設定ファイルの仕様なんだから。 設定ツールをどう実装するかは、設定ツールに任せればいいこと んで、なんだ?汎用のXML設定ファイルの話をしてるのに、 お前は、それに対応した設定ツール(HTMLエンジン)の話してんのか 話にならない。設定ツールの実装をどうしろとか何も言ってねぇから 小さなツールも大きなツールも、大きさは設定ツール次第だろ lynxやw3mといった小さなブラウザだってあるし、そもそもHTMLエンジンである必要もない 425 login:Penguin sage 2018/09/16(日) 20:03:57.41 ID:29LJB/lv そりゃ規格なんだからある程度の量にはなるが、 基本はXMLなのでXMLとしての仕様は不要 タグ一覧があれば十分だろ 少なくともHTMLの仕様よりは大きくならない 大きさと行数はイコールというわけじゃないが大体の目安にはなるな https://www.openhub.net/p/chrome 23,701,168 lines of code https://www.openhub.net/p/firefox 36,890,150 lines of code https://www.openhub.net/p/w3m 172,152 lines of code https://www.openhub.net/p/lynx 209,536 lines of code >>451 設定ツールでどんな機能・利便性・使い勝手が実現できるかが肝心なとこじゃねえの? そこ実装依存とか逃げまわる所じゃないだろ(笑) htmlエンジン使わないならタグのGUIにおける解釈はどうすんの?設定ツール作る人に投げるの? はい、案の定、俺の意見を曲解されたので>>220 をコピペしておきますね。 >>216 何の意味って、最初に言ったとおり、 世の中はXMLの使い方を間違ったよなーって話をしてるだけ >>217 標準化しようじゃなくて 世の中はXMLの使い方を間違ったよなーって話をしてるだけ >>218 仕様を書く必要はないよ 世の中はXMLの使い方を間違ったよなーって話をしてるだけ >>219 世の中はXMLの使い方を間違ったよなーって話をしてるだけ だからxmlで設定書くのはやめて他のツール使えって話で終わりだと思うんだけど。 >>458 はい、案の定XMLの正しい(爆)の使い方の話に切り替えましたねー。 では設定ツールという概念はNGワードにしましょう。 ただのテキストエディタしか使わない状況で 設定XMLのメリットを解説してくれませんかね。 ていうか、ずっとリブレオフィスの例とか引っ張り出してきてて文章としてのxmlと設定ファイルのxmlをごっちゃにされも困るんだけど。 普通にアプリケーションの設計を考えた時に、guiのアプリで、設定ツールだけ別の汎用ツール使ってくださいってことでしょ。 使う側も開発する側もめんどくさいよ。どうせアプリのGUIを作るんだから、ついでに作ったほうが楽だよ。 ユーザーフレンドリーでもないし。 >>459 世の中のアプリで汎用の設定ツールで設定できるものありますか? 汎用の設定ツール = テキストエディタとか言わんでしょうね?w 設定ファイルに書いてあるコメント(英語)を読んで長ったらしくて見づらい 設定ファイルをテキストエディタで編集するのは初心者には大変なんですよ。 GUIの設定ツールが必要です。そのGUI設定ツールを アプリ開発者が作る手間を省く方法がありますか? 面倒だから、GUIの設定ツールはなかなか作られないそれが現実ですよ。 汎用のXML設定ファイルという形式が作られれば、その問題が解決するわけです。 アプリごとに異なる形式の設定ファイルでは不可能ですからね >>460 > はい、案の定XMLの正しい(爆)の使い方の話に切り替えましたねー。 いや、お前がすり替えていたんだろ? > では設定ツールという概念はNGワードにしましょう。 ははw 言われて困る言葉は封殺しようということですかw 何度でも言いますよwww > ただのテキストエディタしか使わない状況で > 設定XMLのメリットを解説してくれませんかね。 汎用の設定ツールで設定できるようにするために、汎用のXML設定ファイルが必要なのです。 ただのテキストエディタしか使わない状況なんてありません。そんなのお前の中の世界の話でしかありません 汎用のXML設定ファイルのメリットは、汎用の設定ツールを作ることが可能になり、そのツールを使えるので アプリ作者は何も作らなくても設定がGUIで可能になることです。そうなると開発者とユーザーの両方にメリットがあります。 正しくXMLを使えていたら、今頃はそうなっていたのに、 世の中はXMLの使い方を間違ったよなーって話をしてるだけ >>462 > どうせアプリのGUIを作るんだから、ついでに作ったほうが楽だよ。 開発者には設定ツールの開発ではなく もっと本質的な機能の開発をしてもらうか、 休ませてあげましょう。 それともあんたが作るの?w ユーザー「設定ツールはアプリ開発者が作れよ。どうせGUI版も作るんだろ?その方が開発者も楽だろ?」 開発者「うるせーぞクソユーザー。GUI版なんていらねー、楽だと思うならお前が作れや」 お前さあ 「設定ツールがどういう実装になるか知ったことじゃない 実装どころかどんな機能になるのか機能が実現できるかオレに聞くな 正しい設定XMLの使い方を教えてやる」 という態度取っておいて 「設定ツールが設定XMLがあるから素晴らしいのだ」 って面白い奴だな。 > 「設定ツールが設定XMLがあるから素晴らしいのだ」 違う。 汎用の設定ツールを作れるようになるから 汎用のXML設定ファイルは素晴らしいのだ と言ってる お前さぁ、どうも自分の思い込みで勝手に俺の像を作って そいつを叩いてるだけだよな? >>464 俺は作る側の人間だから自分のアプリではつくる。 設定ツールってよくわからんが、設定するための画面はアプリのメニューに合ったほうが良いじゃん。 > 設定するための画面はアプリのメニューに合ったほうが良いじゃん。 良いと思いますよ? 汎用の設定ツールがあれば、アプリのメニューから それを呼び出すだけいいですね。 簡単です。 >>469 読解力ゼロか。設定ツールなるものと設定するための画面と言葉を変えてるだろ、同一のものを指してるんじゃないんだよ。 >>470 はぁ? アプリ埋込み型の設定ツール(ライブラリ)を使えばいいでしょう? 今の時代、スマホのゲームの画面からお知らせを開いたら アプリ埋め込みのwebkitライブラリからHTMLを表示している なんて普通に行われてるんですが >>471 スマホアプリの話ししてるならスレチもいいとこだから帰れ。 後出しジャンケンすんな。ただのストローマンかよ。 >>472 お前本当に頭が固すぎるな スマホアプリは例であって、どんなアプリでも応用できる話だろ 汎用のXML設定ファイルというものが作るというふうに世の中が進んでいたら、 今頃はライブラリとして、汎用のXML設定ファイルを設定できる ダイアログを表示する機能も実現できていただろうなって話だ。 アプリ開発者はAPI一つ呼ぶだけで、設定画面が完成してしまう。 もちろん開発初期は、<input>並べただけだからろくな見た目ではないが それでも使える。後々作り込めばいいし、プログラマじゃない人でも手伝うことができる。 それこそデザイナーに頼んでかっこよくて使いやすい設定画面を作ってもらえばいいし その間にアプリの開発者は本質的な機能の実装に取り掛かれる >>473 そうか、つまりwebkitライブラリ的なライブラリが設定ツールに必要でそれがほとんど、htmlエンジンだって気がついてくれたかな? ていうか、webkitライブラリの中身はHTMLエンジンなんだけど。 だいたいなー 「画面はアプリのメニューに合ったほうが」っていうのが GUIアプリのことしか考えられてない点で視野が狭いんだよな。 CLIコマンドやサーバーアプリの設定とかもあんだろと >>474 > htmlエンジンだって気がついてくれたかな? HTMLじゃないので、 「汎用のXML設定ファイル」エンジンなw ほんとなんでこういう基本的な 理解がないんだろう。 見た目似てれば全部同じものなんですかー?w あー、くっそ頭悪いわこいつ。相手する必要さえないわ。 日本語うまく書けないし、たとえ話を事実のように書くし、誰も理解できんだろ。 相手にしてくせに(笑) 相手にしてるくせに、相手する必要ないってわざわざ言うのは、 相手する必要があるのに、相手を言い負かせられない言い訳だろw 有言実行、相手する必要ないと言ったならこれから先レスをするな そうすりゃお前は自分の言葉を曲げず、俺も逃げたと皆に思われるから満足だ。 お前はレスするな。それが俺の命令。俺の命令にお前は従うしかないのだ >>396 でまとめたことの再掲 設定ファイルの話。 設定ファイルをXML形式にする・・・というのは それなりに行われているが、単に冗長になっただけで テキストエディタで編集しづらく、大したメリットがない。 だけどそれはXMLの使い方を間違えているからの話。 (他の形式に比べて)冗長なのはXMLである以上どうしようもないが、 メリットを出すことはできる。 それが汎用のXML設定ファイル形式(XMLを拡張してスキーマを定義する) HTMLを参考にしてXML設定ファイルはタグが定義されているため 汎用の設定ツールを作ることが可能になる。 アプリの作者は単にその汎用のXML設定ファイル形式を採用するだけで 設定ツールの作成は他に任せることができる。 汎用の設定ツールはユーザーフレンドリーなツールで 例えば選択項目であれば選択候補を表示したり、 もちろん実装次第だが、ウェブサイトで見たことがあるような設定画面を 設定ファイルから作り出すことができる。多言語対応なども可能 ブラウザで表示したHTMLファイルのフォームの値を変更して、 そのまま元のHTMLに保存できるような感じ そのような高度な設定ツールを使うことが可能な、 汎用のXML設定ファイル形式を作る・・・というふうに 世の中がなっていたら良かったのにという話 つまり、世の中はXMLの使い方を間違ったよなーって話をしてるだけ 最初の書き込み(>>123 ) 我ながら言ってることが一貫してるわw 設定ファイルのXML方式はやり方を間違えたからな。 そもそもXMLというだけではタグの種類は定義されておらず タグと属性を使ってデータを表現しますっていう縛りにすぎない。 例えばOpenOfficeとかはXMLをベースにした ODFというフォーマットを採用している。 このフォーマットに相当するものが設定ファイルになかった 標準化せずに各アプリがそれぞれ独自のフォーマットを作成してしまった。 そのせいでXMLを使いながらも、汎用の設定変更アプリが出現することはなかった >>467 汎用設定ツールとやらをどうやって作るとか 何を実装すべきかとかどういう動作をすべきかは知ったことではないんだよな(笑) 結局これでは設定ツールがどんな代物になるのかわかる人いないだろ(笑) 425 login:Penguin sage 2018/09/16(日) 20:03:57.41 ID:29LJB/lv そりゃ規格なんだからある程度の量にはなるが、 基本はXMLなのでXMLとしての仕様は不要 タグ一覧があれば十分だろ 少なくともHTMLの仕様よりは大きくならない このように汎用のXML設定ファイルの話をしているのに 何が何でも設定ツールの話にすり替えようとしている人に 騙されないようにしましょう。 注意喚起でした。 「汎用の設定ツールを作れるようになるから 汎用のXML設定ファイルは素晴らしいのだ」 でも設定ツールの具体的な話はお断りです。 設定ツールが設定ファイルをどう扱うかうか怪しいのに アプリが設定ファイル読み込んでちゃんと設定値の利用できるんだろうか > もちろん開発初期は、<input>並べただけだからろくな見た目ではないが > それでも使える。後々作り込めばいいし、プログラマじゃない人でも手伝うことができる。 enum Items {item1,item2,item3}; class Configurations { int foo; Items bar; bool baz; } Configurations configurations; なら <configurations type="Configurations"> <foo type="int">1</foo> <bar type="Items">item1</bar> <baz type="bool">true</baz> </configurations> なら助かるけど <configurations> <foo>1</foo> <bar>item1</bar> <baz>true</baz> </configurations> でもまったく問題ないな もちろん初期は、全てtype="string"として扱うだけだが それでも使える。後々type="bool"なりtype="Items"なりスキーマなどで定義すりゃいいし、プログラマじゃない人でも手伝うことができる アプリ作者は何もしなくていい 設定ツールの作者にとっても bool,int,Itemsなどをどう扱うかは設定ツールの作者が好きにしたらいい もちろん開発初期は、すべて<input>並べただけだからろくな見た目ではないが それでも使える。後々Itemsをセレクトボックスで選べるようにしたりboolをcheckboxなり好き勝手に作り込めばいい >>486 > 設定ツールが設定ファイルをどう扱うかうか怪しいのに > アプリが設定ファイル読み込んでちゃんと設定値の利用できるんだろうか まさかと思うけど、設定ツールで設定したら、設定ファイルが 壊れちゃったとかそういう事考えてる? それってテキストエディタで 編集したらファイルが壊れたみたいなことと同じこと言ってるよ 設定ツールは何もデータを変更せずに保存すれば設定ファイルは何も変更しない 設定ツールが変更できるのは<input>とか<select>とか設定値として使用する要素だけ さすがにこれぐらいは決めるよ。決めるっていうかガイドラインだね。 アプリが設定値として利用するのは<input>とか<select>とか設定値として使用する要素だけ これらの要素の名前を値を利用する。DOMの構造は設定値としては不要な情報なので無視する。 だから構造をガラッとかえても、名前と値が同じならアプリからは同じ設定に見える >>487 「なら助かるけど」も「でも全く問題ない」も両方とも問題がある。 設定の名前(つまりfoo, bar, baz)をタグにするから 汎用の設定ツールで扱うことができないんだよ だって、<foo>、<bar>、<baz>をどういうタイプとして扱うかなんてわからないでしょ その使い方が間違ってると言ってるわけ。 でもやっぱりそういう使い方をするもんだって思い込んじゃってるんだよね・・・ 発想が凝り固まってるのはどうしようもないんかねw じゃあどうすんの?って話なんだろうけど、すでに上の方でも書いてるけどこんな感じね <configurations type="Configurations"> <label>foo: <input name="foo" type="int" value="1" /></label> <label>Items: <input name="bar" type="Items" value="item1" /></label> <label>baz: <input name="baz" type="bool" value="true" /></label> </configurations> そうすりゃ設定ツールは、fooという未知のタグをどう表示すりゃいいんだ?なんて悩むことはなく あ、はいはい、inputタグね。これはユーザーの入力項目ですね。intですね。なら数値フィールドですね。 数値以外は入れられないようにしますよ。なんなら上下ボタンで値の増減もしますよ。 みたいに理解できる。 ちなみに上の例にはわざと<label>を追加してる。なぜかというと設定ファイルにあるタグはすべてが 入力項目とは限らないからだ。既存の設定ファイルでもコメントでどんな値を入力すればいいかなどの説明が書いてあるだろ? すべてのタグを入力項目として扱えない。どうせそのことが抜け落ちてるんだろうからさ >>489 >>490 色々できることが増えてきたけど 何ができるとか何をして良いとか何をしてはいけないとか どうやって決めるんだろう 425 login:Penguin sage 2018/09/16(日) 20:03:57.41 ID:29LJB/lv そりゃ規格なんだからある程度の量にはなるが、 基本はXMLなのでXMLとしての仕様は不要 タグ一覧があれば十分だろ 少なくともHTMLの仕様よりは大きくならない >>491 > 色々できることが増えてきたけど > 何ができるとか何をして良いとか何をしてはいけないとか > どうやって決めるんだろう 誰かが決めれば? 俺は、世の中はXMLの使い方を間違ったよなーって話をしてるだけ >>220 より >>216 何の意味って、最初に言ったとおり、 世の中はXMLの使い方を間違ったよなーって話をしてるだけ >>217 標準化しようじゃなくて 世の中はXMLの使い方を間違ったよなーって話をしてるだけ >>218 仕様を書く必要はないよ 世の中はXMLの使い方を間違ったよなーって話をしてるだけ >>219 世の中はXMLの使い方を間違ったよなーって話をしてるだけ あと、何度もコピペしてるけど そりゃ規格なんだからある程度の量にはなるが、 基本はXMLなのでXMLとしての仕様は不要 タグ一覧があれば十分だろ 少なくともHTMLの仕様よりは大きくならない HTMLの仕様は巨大で複雑。タグが省略できるなど XMLに反してるのでそこまで決めなければならなかったし HTML5では間違ったHTMLであってもすべてのブラウザで 同じように表示できるように不正なHTMLの解釈の方法まで定義された 汎用の設定ツールはXMLベースなので、そんなことは不要 XMLをベースにしてますの一言で、拡張部分(つまりタグ一覧)さえ決めれば良くなる >>492 誰かが決めればってそれは規格を作成して決めなきゃいけない問題であるとの認識なのか 丸投げ逃亡宣言かどっち? >>494 お前が技術的なメリットデメリットの話から、実現が大変かどうかの話に すり替えようとしてるのには気づいているからさw 俺からすりゃ、大変だから何? 大変というのは俺が言ってる 世の中はXMLの使い方を間違ったなーという話への反論には なってないでしょの一言で終わりだから 丸投げ逃亡宣言(笑)とか、結局技術的な話をしたいんじゃなくて 俺を論破(笑)したいだけなのモロバレだし だから技術的な話から揚げ足取りできる方向にすり替えたいんだろうな 規格の制定が必要だと認識してるのかどうか答えられないの? 独自タグに溢れてるから間違いって主張は間違ってるじゃん 何度でも聞くけど >>492 誰かが決めればってのは ・設定ツール作成や利用アプリの為に規格作成が必要 ・規格なんか決めなくて実装者が好き勝手決めて思う通りやれば良い ・自分でも 何言ってるのか意味が 何度でも聞くけど >>492 誰かが決めればってのは ・設定ツール作成や利用アプリの為に規格作成が必要 ・規格なんか決めなくて実装者が好き勝手決めれば良い ・自分でも何言ってるのか意味がわからない どれ? だから決めるべきことがあれば、誰かが決めろって 俺は最初からずーっと 世の中はXMLの使い方を間違ったよなーって話をしてるだけ >>493 XHTMLは「XMLを拡張して」作ったけどタグ一覧で済んでたかな ひょっとして >>123 から始まってたのか? 今気付いた。 さすがにちょっと可哀想になってきたよ。 近くに君と会話できる人はいないのかい? >>501 誰が何を決める想定なんだよ 決めるべき所は決めるじゃトートロジーだろ >>502 > XHTMLは「XMLを拡張して」作ったけどタグ一覧で済んでたかな XHTMLの話はしてない >>503 数ヶ月あけてレス (>>177 ) が来たからね。 話を再開しただけ > 近くに君と会話できる人はいないのかい? それが技術的な話と何か関係ある? もっというと、それは反論ではないよ。 >>504 > 誰が何を決める想定なんだよ だからそんなの想定する必要がないってw 俺は最初からずーっと 世の中はXMLの使い方を間違ったよなーって話をしてるだけ ほんとなぁ「XMLの使い方を間違った」という意見に対しての 技術的な反論してくれればいいのに、大変だろう?とか誰がやるんだよ?とか 無関係な話にすり替えて揚げ足撮ろうとしてるのミエミエだからw 仕事でも「解決すべき問題の認識」と「どうやって解決すべきか」は 分けて考えないといけない。 でないと、以下のようなシナリオが起きる 上司「なにか問題はありますか?」 部下「○○という問題があります?」 上司「誰が問題点を解決するんだ?そのコストがいくらかかる思ってるんだ? お前責任取れるのか?その答えがでてないなら議題に上げるな」 こうやって問題があるのになかったことにされる。 優秀だが嫌味な部下「まず問題があるか無いかを決定する話をしましょう。 問題があることに異論はないわけですよね。では問題があるということは決定します。 そして、あなたは問題があると認識した上で誰が解決するのかとコストが不明という別の理由で 問題がなかったことにするのですか?おかしいですね。問題があることは決定したはずです。」 ミスったw 上司「なにか問題はありますか?」 部下「○○という問題があります」 部下が、聞いてどうするんだってなw 仕様をどう決めて何を実装すべきか言えないのに 今のソフトは間違ってる(笑) >>505 XHTMLはタグ一覧ではすまなかったのかな? 設定XMLはタグ一覧で済む理由あるのかなあ(爆) 世間のXMLの使い方は間違ってて設定XMLの先生が間違ってない理由は何さ(大爆笑) >>509 根本的なところがずれてない? http://jtdan.com/spec/ の中から XHTML 1.0 拡張可能ハイパーテキスト・マークアップ言語 (第二版) http://msugai.fc2web.com/web/W3C/xhtml1SE/Cover.html XHTMLの仕様書ってこんだけだよ? 意外と少ないでしょ。 誰かが電話帳ぐらいになるはずだとか言ってたけど。そんな量はない。 見ての通りHTMLとの互換性の話が含まれるから、XHTMLは量が多めだけど、 それでもこの程度、XML設定ファイルはこれよりも少ないってのは明らかだろうね もしかしてA4用紙で3枚を超えたら多いとか思ってない? >>510 > 世間のXMLの使い方は間違ってて設定XMLの先生が間違ってない理由は何さ(大爆笑) 間違ってるという(俺の)意見がある その俺の意見に対して間違っているという意見がない >>512 いや色々突っ込まれてることにお前が認識してないだけだろ >>511 https://www.w3.org/TR/2002/REC-xhtml1-20020801/ 原典だせないの? これはタグの一覧に見えるのか? お前のリファレンスのHTML4の差分という文章は? >>512 お前の設定XML(笑)に賛同してくれる物好きいないから却下でいいんじゃないの(笑) 都合の悪い質問は無視して難癖できるとこだけ明後日の妄想続ける(爆) >>505 間違ってるなら正しい使い方示せばいいのに 誰かが決めるべき所は決める(笑) >>505 今のXMLが間違ってる以外の ぼくのかんがえたさいきょうの設定XMLだの 設定ツールが作れるだのは思えの意見じゃ無いの? 何度も言ってるけど、xmlは異なるアプリ間やxmlを共有(feed利用)しない限り、 名前空間を定義(スキーマ)せずに使っても間違いとは言えない。 文法の誤りとかじゃなくて、設定ファイルなんかの特定のアプリ内で使うようなxmlに独自タグが入っててもいいだろ。 そもそも設定ファイルにxml使ってるようなアプリはエディタで編集されるのを想定してないからxml使ってるようなもん。 普通に使ってたら設定ファイルすらみない。 linux使っててbash書いたり、yml編集したり、config.jsonをエディタで編集してもxmlはguiで編集するのが多かった。 独自タグがあってもうまく隠されてて不都合が起きることはまずない。 だからxml君の主張は的外れだな。世間のxmlの使い方は間違ってない。 だいたい世間が使うときはFeedぐらいだしな。 お前らのXMLの使い方は間違ってる! 正しい使いかはこれだ(ボコボコに叩かれる) いやーオレのXMLの使い方は間違ってるに誰も反論してないこれはオレの大勝利 こういうことですかね fooの型ってなんだよ ← 分かる boolだよ boolって言ってもいろいろあるだろ ← 分かる true/falseの大文字小文字区別なし、[Tr][Rr][Uu][Ee]だね radioboxか?checkboxか?selectboxか?何で扱えばいいんだ? ← 分からない 好きにしろよ… 間違ってる使い方(>>487 )と正しい使い方の例 >>487 「なら助かるけど」も「でも全く問題ない」も両方とも問題がある。 設定の名前(つまりfoo, bar, baz)をタグにするから 汎用の設定ツールで扱うことができないんだよ だって、<foo>、<bar>、<baz>をどういうタイプとして扱うかなんてわからないでしょ その使い方が間違ってると言ってるわけ。 でもやっぱりそういう使い方をするもんだって思い込んじゃってるんだよね・・・ 発想が凝り固まってるのはどうしようもないんかねw じゃあどうすんの?って話なんだろうけど、すでに上の方でも書いてるけどこんな感じね <configurations type="Configurations"> <label>foo: <input name="foo" type="int" value="1" /></label> <label>Items: <input name="bar" type="Items" value="item1" /></label> <label>baz: <input name="baz" type="bool" value="true" /></label> </configurations> そうすりゃ設定ツールは、fooという未知のタグをどう表示すりゃいいんだ?なんて悩むことはなく あ、はいはい、inputタグね。これはユーザーの入力項目ですね。intですね。なら数値フィールドですね。 数値以外は入れられないようにしますよ。なんなら上下ボタンで値の増減もしますよ。 みたいに理解できる。 ちなみに上の例にはわざと<label>を追加してる。なぜかというと設定ファイルにあるタグはすべてが 入力項目とは限らないからだ。既存の設定ファイルでもコメントでどんな値を入力すればいいかなどの説明が書いてあるだろ? すべてのタグを入力項目として扱えない。どうせそのことが抜け落ちてるんだろうからさ >>521 > fooの型ってなんだよ ← 分かる > boolだよ > boolって言ってもいろいろあるだろ ← 分かる > true/falseの大文字小文字区別なし、[Tr][Rr][Uu][Ee]だね > radioboxか?checkboxか?selectboxか?何で扱えばいいんだ? ← 分からない > 好きにしろよ… それなw 型だけじゃどう表示すればいい変わらないよね ということで>>522 は間違っていたので訂正 Itemsはなんのアイテムかわからないので文字列の配列としてる <configurations type="Configurations"> <label>foo: <input name="foo" type="number" value="1" /></label> <label>Items: <select name="bar" type="Items" multiple="true" value="item1,item2" /> <option>item1</option> <option>item2</option> <option>item3</option> <option>item4</option> </select> </label> <label>baz: <input name="baz" type="checkbox" value="true" /></label> </configurations> 全然話違うけど設定ファイルをスクリプトにするのってどう思う? メリットもあればデメリットもある。いちいち騒ぐほどのことじゃない。 >>524 ドキュメントついててわかりやすかったらなんでも良いと思うよ。 >>527 誰に感化されているのか、本人なのか知らないが、 ドキュメントはあくまでドキュメント。インストール方法からアプリについて必要なことを書くべき。設定ファイルを含む。設定ファイルに書いてあるコメントだけで設定しようと言うやつはものぐさなだけ。 そもそも設定が必要なアプリもインストールと対して変わらないが。 >>528 そもそも設定ファイルにコメントっているの? >>531 「開発者が」か やっぱりそこに開発者とユーザーの温度差を感じるんだよな ドキュメントは読まなくても使えるようにするのが良いソフトなわけで ドキュメントとついてるからOKだろって発想が このスレに合わせて言うのなら思考回路が40年前と同じレベルw 設定はデフォルトで不満だったり、変更する必要がある時に変更するので、設定ファイルを編集する時点でドキュメントを読む必要がある。 これを読んだことがなく設定を変更するにはブログや本等の二次情報に頼るか、GUIの機能を使う。 設定ファイルのコメントが読まれる状況は本人か、ハードユーザーになるのでそれ向け。 一般に普及してるのはWindowsなのでドキュメント文化が根付いていないのは仕方ないと思うが、Linuxを使うのであれば、一次情報のドキュメントを読むべき。 Windowsはドキュメントが不十分すぎてoffice使うのも教室通ったり、本屋で本買ったりするだろ。 ドキュメントがるソフトであれば、それが不要になるてこと。それがオープンソース。 これは最大の強みだから昔と同じでいい。 Windowsだからドキュメント文化がないんじゃなくて 家電でもスマホでもゲームでも自動車でも同じでしょ? ドキュメント読まないと使えないから仕方なくドキュメント読むんやで >>535 お前がドキュメント読まないで使ってるソフト ブラウザとか5ちゃんねるブラウザとか ほとんどのスマホアプリとか >>534 マジレスするとWindowsの方がドキュメントは充実してる >>537 ブラウザもスマホアプリも専ブラも始めに使い方を調べるだろ、もしくは小学校で学ぶ。パソコンが普及したときはクリックってなに?から始まったんだぞ。 直感的に使えるということであれば、他のアプリを真似て作ってるだけ。 家電の話でも使ったことないやつは洗濯もできないやついるだろ。ママに教わらないとできない。 ママが近くにいないときは取説を読め。 >>539 でもドキュメント読んだことないでしょ? 教室通ったり、本屋で本買ったりして使えるようになるんだから >>540 全部のドキュメントを読むということはない。設定ファイルをいじるようなときにだけドキュメントを読むって話。拡大解釈してないか? >>541 その読むべき項目が、設定ファイルの設定項目の上に 書いてあれば、便利じゃないですか? 俺が >ドキュメントついててわかりやすかったらなんでも良いと思うよ。 って書いたのは、コメントでもなんでも文章で説明されてればってことなんで、単語に引っ張られてミスリードしないでくれ。 設定ファイルからコメントが取り除かれてる場合はハードユーザー以外はいじらないでくれって暗に示してる時もあるから絶対コメントがあったほうが良いって話じゃない。 開発環境が云々ってスレでドキュメントがあるアプリが良いって意見はそんなに不自然ではないと思うがな。 自分がしたい話題にのみ焦点を当てて他人のレスを曲解するのは良くないぞ。 設定する項目の上に、説明が書いていれば便利だけど 英語だったら便利さ半減なんだよな。読めない人が大半だし。 だからLinuxではみんな技術書を買って使い方を勉強するんだろう LinuxはMacやWindowsと違って対象ユーザーが一般向けじゃないからな。 一般も別に使ってもいいけど、いじりたければ自己責任の世界だから。 ubuntuなんかは企業が入って開発者とユーザーの間に入っていろいろやってくれてるけど、無料じゃ限界があるだろ。 >>522 >>523 あるタグならこう動作するこの属性はこう取り扱うなど記述してるけど その取り決めは誰がするの? 例えばにはtype=intとあったときにintというのは整数型で実装すると判断する根拠はどこにあるのかな? >>551 取り決めを誰がするのかどうかの話は 技術的な話と何の関係があるの? 例えばJavaScriptのブラウザの新しいAPIの仕様の話をしているときに 取り決めは誰がするの?と言い出すことに何の意味があるの? >>552 > 例えばにはtype=intとあったときにintというのは整数型で実装すると判断する根拠はどこにあるのかな? あ、それは間違いでしたって>>523 で訂正したよ。 type=intはデータ型に過ぎなくて、データ型の情報では どういうインターフェースで入力するかは決定できない。 古き良き、テキストボックスで入力するかもしれないし HTML5の数値専用のテキストボックス(数値増減の▲▼つき)かもしれないし スライダーを使うかもしれない。なので汎用のXML設定ファイルには データ型を記述することはない。 要するに「整数型で実装するという判断はすべきでない」が正解なんだわ なぜならそもそも不要だからね。XMLでない設定ファイルだって、 log_level=[ここ] が整数型で実装するか文字型なのかって判断は必要ないでしょ? 今やってないのに、汎用のXML設定ファイルにした途端、必要になるなんておかしい。 >>554 では質問を変えて。 実装者が実装する参考資料として事前に取り決めつまり仕様書は必要なの? >>555 それだとintとかいてあったらカレンダーが表示される 実装するのは禁止されてないと読めるけど? >>557 だからintなんて書かないって言っただろ お前が訂正するまで話は進めない >>558 type=numberならOKなのか? >>559 numberは変数の型じゃないからな inputタグ(テキストボックス)を使いnumber(数値)を扱うための インターフェースを使用しろって明示してあるんだから カレンダーを使うやつなんていないだろう >>556 はこの話題の対象外です。 まあもちろん腐った実装がカレンダーを表示した所で おかしな設定をしてしまうってだけ 汎用のXML設定ファイルじゃない場合を想像してみりゃわかる log_level="2018-09-27" こう書いてしまっただけのこと あとはプログラム側で今までどおりエラーがでるだろう いや関係あるだろ。 何の前提知識もない実装者が これを見て <label>foo: <input name="foo" type="number" value="1" /> numberが数値を意味するとか テキストボックスでもよいスライダーでもよい カレンダーはだめだという判断を下せる根拠はどこからくるの? >>562 腐った実装という言葉を使うけど客観的に腐ってるか正しいか どうやって判断するの? >>563 え?なに?仕様書を作る必要があるって話をしてるの? 作ればいいだけじゃん。 >>565 それはずっと言ってるHTMLより小さいと想定する仕様書に全部含まれると考えている? <input name="foo" type="number" value="1" /> inputはユーザーが入力する項目を示します。 type属性は入力する値の種類を意味します。 設置ツールは適切なインターフェースを使用してください 終わり。たったこれだけw >>567 値の種類とは?何種類あるの?勝手に増やしていいの? 適切なとは?何が適切でないとどうやって判断するの? 疑問一杯で仕様書とか読んだことも無さそうにしか見えないけど? >>567 このレベルが仕様だと思ってるようでは話が通じないわけだ >>556 お前は何が言いたいんだ? HTMLはXMLベースではないのだから「XMLの仕様に準拠します」と書くことができない。 だからXML相当の仕様に加え、XMLには不要なHTML独自の仕様がたくさん含まれてる 例えばタグを省略したときのルールや、不正なタグ場合の解釈の仕方などだ 汎用のXML設定ファイルには、XMLの仕様を含める必要がない ただ一言「XMLの仕様に準拠しますと」書けばいい 汎用のXML設定ファイルの仕様だけあればいい だからどう考えても、 HTMLの仕様の量 > 汎用のXML設定ファイルの仕様の量(XMLの仕様は含まない) になるのは明白なんだが >>568 だから、仕様を作るだけですよね? >>569 何が足りないのか、言ってみたら? その量がHTMLの仕様の量を超えるまで待ってるよw >>567 アプリの作者からすると<foo>1</foo>で事足りる 設定ツールの作者からしても input + number という無駄情報より type="int" という型情報 のほうが正確というかそのものなのでありがたいな >>572 そういうこというと汎用設定ツールが作れないだのXMLの使い方が間違ってるだの馬鹿にされて 破綻してる設定XML構想聞かされるぞ つか未だにgconfだのdconfだのが一度も出てこないことに驚き >>574 それはずっと思ってた。 XMLおじさんによる比較とかダメ出しとかねーのか? >>572 > 設定ツールの作者からしても > input + number という無駄情報より > type="int" という型情報 > のほうが正確というかそのものなのでありがたいな type=intとあったときにintというのはスライダーで実装すると判断する根拠はどこにあるのかな? >>574 gconfやdconfは値を編集することはできるが、 どういった値(型ではないぞ。値の範囲や文字列の候補だ)が設定可能か?の情報や どういうインターフェースで設定するのか?という情報が抜けてるので、 使いやすいツールにはできない >>576 numberと書けばスライダーが出てくる理由がわからん numberと書けばスライダーが出てくるなんて言ってないぞ? 話を整理しようか? 1. type="int" という型情報じゃスライダーと数値用テキストボックスの どちらを出せばいいかわからない このことから型情報ではダメであると理解できたはずだ。 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ で、numberと書けばスライダーが出てくるかどうかだったな HTMLを参考にしてると言っただろう? http://www.htmq.com/html5/input.shtml 2. type="number" だと数値用のテキストボックス(相当のもの) type="range" だとスライダー(相当のもの)が表示される typeに書いているのは変数の型ではないことが理解できたかな? >>579 例えばnumberで出てくる数値入力ボックスは 要求が整数か浮動小数点か区別できるの? >>580 まずさ、君が理解しないといけないことは XMLではない設定ファイルにデータの型情報を 書いてるものなんか無いって事実だよ。 そう。いらない。整数化浮動小数点数か区別する必要がない。 inifileに [VM] MemoryGB=1 とかあった時、MemoryGBが整数か浮動小数点数か区別できるの? 区別できないし区別する必要がないよね。 数値どころか文字だって書くことができる >>581 テキストボックスがぼーんとあって何を入れるかわからないのに何が便利なの? 彼の目的は >>220 に書かれている。すべて、そのための妄想だ。 妄想だということを本人も >>180 で認めている。 まあ、それが彼のやりたいことだというなら仕方ないじゃないか。 >>582 > テキストボックスがぼーんとあって何を入れるかわからないのに何が便利なの? はい。情報が型しかないとそうなりますよね。 だから型の情報はいらなくて、 「何を入れるか分かる情報」が必要なんですよ >>576 アプリの作者からしたら スライダーだろうがテキストエディタだろうが関係ないんだから関与する必要がない ツール作者やその利用者が好きにしたらいいだけ >inputはユーザーが入力する項目を示します。 >type属性は入力する値の種類を意味します。 >設置ツールは適切なインターフェースを使用してください という軟着陸なアイデアは無意味なので無視するとして アプリ作者の独断で エディット、スピン、スライダー、ダイヤル… 数有るコントロールの種別の中から一つを決めたとしても そのチョイスを万人が受け入れるはずがないし そのチョイス自体負担だし選び直しでリビルドとかやってられない それなら int型です、UIはご自由に と投げたほうがいい そもそも int型です という情報すらも必要ない それが必要だという人が勝手に調べりゃいいだけ >>585 型情報とは違う「何を入れるかわかる情報」の具体例は何? >>587 > アプリの作者からしたら > スライダーだろうがテキストエディタだろうが関係ないんだから関与する必要がない > ツール作者やその利用者が好きにしたらいいだけ そう。だから利用者が好きにできるように 汎用のXML設定ファイルがある。 設定ファイルの情報をもとに設定画面を組み立てるから、 設定ファイルを書き換えて使いやすい設定画面を作ることができる まさに、ツール作者やその利用者が好きにできるということを実現している アプリの作者からしたら、どのインターフェースでも設定された値を取得できる。 ツール作者やその利用者が好きに使いやすいインターフェースを作ることができる >>588 数値だったら、その範囲等。0〜100とか 文字列だったら、その文字列長さや、正規表現パターンなど 選択項目だったら、設定可能な値、例えばredやblueといった色の名前など ある設定項目αについ設定ツールAが1から100のスライダーで表示したとき 設定ツールBでも同様に1から100のスライダーが出てくると ユーザは期待して良いのか(y/n)? >>591 NO。ただしどのツールでも設定できる [VM] MemoryGB=1 結局の所↑の1の部分を入力するだけだから スライダーが出てこないでテキストボックスがでてきても なんてことはない。普通に入力して設定できる。 では設定項目αは整数値で1-100と設定した場合 設定ツールから1000と入力しようとしたら何らかのエラーが ユーザに通知されるものと期待して良い(yn) >>593 聞いてばかりいないで、少しは自分で考えてみたら? まずXMLではないよくあるテキストファイルの 設定ファイルのことを考えてみようか? 不正な値も含めどんな値でも書くことができる その不正な値が書かれた設定ファイルをアプリケーションが 読み込めば普通はエラーを出すだろう。 いいか、汎用のXML設定ファイルの話はまだしてないぞ。 信頼できるチェックはアプリケーション側で行われているこれは大前提である で、ここからが汎用のXML設定ファイルの話 設定ファイルに書かれた範囲などは、使いやすくするためのガイドに過ぎない どうせXMLファイルをテキストエディタで開いて書き換えれば好きな値にできる。 不正に値にされた所で、大前提である信頼できるチェックはアプリケーション側で行われてるから問題ない で、何らかのエラーが出るかって? 設定ツールの実装次第 まあ普通はエラーを通知するようにするだろうね 実際HTML5もそうなってる。対応してるブラウザであればエラーを通知するが 対応してないブラウザではエラーを通知しないし、スライダーの指定をしても 対応してなくてテキストボックスが表示される。でも信頼できるチェックは サーバー側で行われてるから問題ない もうね。ここらへんHTMLの世界ですでに通った道なの。 一旦HTML5を勉強したほうが良いよ? 基本的な質問をしてるってことがわかってない。 要するに設定項目の値の範囲の制限などを指定したとしても 設定ツールによる入力の挙動は実装依存だと。 さて「何を入れるかわかる情報」とし0〜100の数値を挙げているが このようなものはどれだけ記述できるのか? 事前に何があると知らない限り設定XML記述者も設定ツール作成者も困るだろう。 ・0から100の整数 ・0から1の浮動小数点(閉区間もあれば半開区間もある) ・32ビット長ただし16進記法 ・任意長整数 ・素数 ・42の倍数のみ 等々数値だけでもいくらでもやりたいことは考えられるがこれらは 何でも記述できるのか 数種だけ用意されててあとはあきらめろということなのか? >>594 HTMLのフォームの値チェックはサーバサイドがJavaScriptの話に なってHTMLやXMLの範疇を超えてるがどういう話になるんだこれ もはや、汎用設定ツールでも何でも無くて、 汎用GUI作成ツールになりつつあるな。ブラウザより大きくなる。 >>595 だからHTML5を勉強しろって >>596 フォームの値チェックなんか、 フォームコントロールの属性でできるだろ HTML5の勉強しろって >>597 また何の根拠もなくブラウザより大きくなる(笑)か 何が大きくなるのー?w ブラウザがどれだけ大きいかしらないのー?w >>598 HTML5で素数だけ入力可とかできるの? お前は設定ファイルで素数だけ設定したことあるのか? そんなマイナーケースまで対応しようとか考えるから 仕様がぶくぶく太っていくんだぞw xmlはhtmlじゃないと言ったり、htmlを参考にしたり、なにがなんやら。 xmlのタグをguiのパーツに対応させるコーディングだけでも大変なのになんかのツールキットでも使うつもりなのか 設定ツールのvalidationが実装依存は相当まずくね? ツールで値を入力したときエラーがでなくても 値が妥当なのかエラー処理が手抜きなのかユーザーにはわからない ことになるけどそれ何もチェックしないより悪いな 不正な値を設定したらアプリがエラーを出す、確かに正しいが そんなぶっちゃけやるならリッチなUIとかもういらないだろ dconfは設定できる値のリストとか正しくない値を設定しようとするとエラー返すとか普通に出来てるんだよなぁ しかもなぜxmlじゃなくて独自のバイナリフォーマットなのかってのも、DEの起動時みたいに一遍に色んなアプリケーション起動して大量の設定をロードしてってなるとxmlのgconfだとパフォーマンス的に良くないってんでそうなってるわけだが そういう現実的な部分をすっ飛ばして実際に作ってすらねぇ妄想でドヤってちゃ話になんねぇわ >>601 素数を設定するなんてかなりマイナーな話だと思うけど マイナーだからと逃げたら汎用性の謳い文句がすたるぞ >>608 この設定XMLとツールで汎用とはどういう話? >>602 > xmlはhtmlじゃないと言ったり、 XMLはHTMLじゃない。当たり前 > htmlを参考にしたり、なにがなんやら。 著名な論文を参考にして、書いた自分のレポートは 著名な論文になるとでも思ってるのか? > xmlのタグをguiのパーツに対応させるコーディングだけでも大変なのになんかのツールキットでも使うつもりなのか 汎用のXML設定ファイルの話とは関係ない話ですね。 >>603 > 設定ツールのvalidationが実装依存は相当まずくね? 全然まずくない。何度も大前提と書いた アプリケーション側のチェックは行われてる。 何度も大前提と言わないと理解できないのか? >>604 > 不正な値を設定したらアプリがエラーを出す、確かに正しいが > そんなぶっちゃけやるならリッチなUIとかもういらないだろ アプリがエラーを出すことと、 設定ファイルを簡単に編集できることに何の関係が? >>605 > dconfは設定できる値のリストとか正しくない値を設定しようとするとエラー返すとか普通に出来てるんだよなぁ 画像見せて ぱっと検索した限りでは、単なる名前と値の羅列しかないですね。 これみてエンドユーザーに設定させろと? 無理でしょ。各アプリが丁寧に作った設定画面と どれだけ差があると思ってるのさw >>613 何度も言わないと本当に理解できんのなw 大前提としてアプリケーション側でチェックしてあるんだから、 設定を読み込ませれば、エラー出るっていってんの >>612 前提としてツールの実装によっては 滅茶苦茶な値を設定してもスルーされるという話を無視するなよ 簡単に編集出来ても滅茶苦茶な値で喜ぶユーザーいるのか? >>609 > この設定XMLとツールで汎用とはどういう話? 汎用のXML設定ファイルの、汎用とは別のアプリでも同じXMLスキーマを利用できること (いっとくが利用できるのはスキーマだけだぞw) >>615 アプリで読み込ませるまで滅茶苦茶な値入れても気づかない ツールが何が嬉しいの? >>616 > 前提としてツールの実装によっては > 滅茶苦茶な値を設定してもスルーされるという話を無視するなよ 現状だって、テキストエディタで編集したら メチャクチャな値を設定してもスルーして保存できるじゃん。 アプリケーションに読み込ませたらエラー出るっていってんの >>619 設定ツール使っても何も便利にも改善もされてないけど何か意味あるの? >>618 > アプリで読み込ませるまで滅茶苦茶な値入れても気づかない > ツールが何が嬉しいの? ユーザーが簡単に設定変更ができること メチャクチャな値を入れたらアプリでエラーが出る メチャクチャな値を入れられない所はエラーが出ない >>620 > 設定ツール使っても何も便利にも改善もされてないけど何か意味あるの? ユーザーが簡単に設定できるようになるので意味がある。 君の話だと設定項目のウィジェットかどう実装されるかは決まってない バリデーションもやらなくてもいいしエラーが出るかもわからない。 えーとテキストエディタに比べて嬉しさどこにあるの? >>621 滅茶苦茶な値を入れるのを防ぐ保証ないのに 滅茶苦茶な値を入れるのどうやって防ぐの? >>623 汎用のXML設定ファイルとして仕様が共通化されてるので 設定ツールを含めさまざまなツールやライブラリを作って 共通で利用することができること またそれらのツールやライブラリを使ってユーザーも開発者も 便利で楽ができること >>624 テキストエディタで設定ファイルを編集することを考えればわかる。 設定ファイルの編集は可能だが、アプリケーションでチェックが行われる >>625 ツール作ってもツールが何できるかわからないし 期待していたことが期待外れも余裕であるんだろ? 役立たずのツールが作れて何かメリットだって? >>625 いよいよ壊れたレコードのように同じことを繰り返すしか能が無くなってきたな 40年経ってもwindowsレジストリの素晴らしさが理解できないのか。 >>624 結局作る側はユーザーが手で弄ったりする事も考慮して自分でも値のバリデーションをしないといけないもんな なんつーか本当にものを知らないガキの妄想だよな 汎用ツールの特徴は ・開発者が楽できる(汎用ツールの仕様に合わせて開発すべき) ・ユーザーフレンドリー(直感的?アプリの仕様に関係なく設定はブラウザに似たインターフェース) ・設定ファイルがguiコーディングも兼ねる。(設定ファイルでインターフェースを描画し、値を変更したものを保存する) これだけでもクソ仕様だとわかる。 >>630 これずっと思ってたわ この人設定と設定の設定の区別がついてないような感じよね 引用忘れた > ・設定ファイルがguiコーディングも兼ねる。(設定ファイルでインターフェースを描画し、値を変更したものを保存する) テキストファイル書いて設定させるなんて昭和末期か平成初期には通用したけど、いまじゃデメリット多くて古くさいってバレバレの手法だよねw >>634 設定が多段のツリー構造になったことで柔軟に構成できる(限度はあるけどフラットなテキストファイルより使い勝手は良い) パス、キーが判ってれば値の取得と更新はOSにリクエストするだけで済む。 独自ライブラリでR/Wしなくて良いしOSのバージョンが変わってもアプリには影響ない(APIが互換性保つかぎりはw デメリットとしては「設定を保存するエリアにコメントを書けない」ってのがあるね。 レジストリがテキストより編集しやすいかは習熟度によると思うぞ。慣れたらテキストのほうが見通しが良いし、わかりやすい。 レジストリとかgconfとかって機能してない項目が大量にあるのはなんでなん? >>631 > この人設定と設定の設定の区別がついてないような感じよね わかった上であえてそうしてるんやで。 なぜなら、設定ファイルをテキストエディタで 修正したいという層が一定数いるから テキストエディタで修正しないんだったら 設定ファイルにコメント機能なんていらん。 コメントはまさに、設定ファイルにUIが含まれてるってことなんだよ それみてどんな値を入れるか判断しているわけだから 設定値と設定UIを作り出すタグを分離すれば、 今度はテキストエディタで修正したい人が使いづらくなる UIがどう表示されるか規定されないし 個々のフォームがどういう挙動するかも不明で 使いやすいのかというか実用になるかもわからんけどな > UIがどう表示されるか規定されないし HTMLだってそうだよ。 そもそもどう表示されるかはデバイスによって異なる PCで使いやすいUIがスマホでも使いやすいわけじゃない なんでこうすでに通り過ぎた歴史の話ばかりするだろうか? 現実を否定しているところから始まってる妄想だから現実離れしてて現実的じゃないのは当然やろうな。 こうだったら良かったのにというボヤキなんだろうが、ボヤキにしても無知を晒してるだけだからな。 アイデアとしてはわかるんだよね。 東芝が昔実験的に作ってた。 XMLスタイルシート的なアイデアは大昔から存在するんだが、実用的なものを構築するのはなかなか難しいと思う。 HTMLが規定されてない、という部分を都合よく拡大解釈するし 不味いところは逃げ回るし >>642 なんで現実にある問題点と解決策を言ったら、現実離れになるの? その理屈だと、効率が悪いと指摘するだけで 効率が悪いのが現実なんだ。現実離れしたことをいうな!ってことになるけど? >>644 拡大解釈だろうがそうでなかろうが、 どちらにしろその解釈に反論できないんでしょ? 少なくともUIの意味論的な話で共通理解が無いと実際に実装は無理。 その規約決定を放棄してお前の頭の中でだけそんなのわかるだろでは話にならない >>648 > 少なくともUIの意味論的な話で共通理解が無いと実際に実装は無理。 何が言いたいんだかさっぱりわからん。 HTMLの仕様とか見たこと無いのかな? UIをどうしろとか書いてないよ W3Cは戦場なので、力あるものが勝つし、勝ったものが正しいとは限らない。 裁判と同じだよ。 エンジニアなのに教祖への愛がすべてなのが、ウェブの未熟さを表してるんだよ。 >>645 現実にある問題点はconfig.xmlに独自タグが多いってだけのこと?他にある? ウェブ業界には勉強会と称して毎週ミサがあるだろ。 お互いに啓蒙しあい信仰心を深める。 最後にみんなで歌を歌って解散。 まさにイカ臭い新興宗教じゃないか。 二言目にはHTMLガーであるがこいつが想像してることは JavaScript・CSS・サーバサイドその他HTTP技術が関わっていのに XMLの話だけで設定ツールへのその部分の押し込み方が全く不明 >>650 >>648 の言いたいことがわからないのは読解能力がないから。お前の妄想をなんとか理解しようとしてるみんなは表現力が乏しい文章に根気よく付き合ってるから。 実際それっぽいのはweb技術に寄生したらelectronですぐ作れるけど、今度はアプリケーション側がhtmlスクレイピング並みに頑張らねばならなくなる。どこに得があるんだって話だよ。 そしてすぐ作れるものを誰も作ってないってことは、もう言わなくてもわかるだろ。 本当に役に立つならすぐ作っちゃえよ。それで飯くっていけるぞ。 Windows 使ってないからレジストリについてググってみた。 Windows を使わない理由が増えた。いや、今更だが…… アホやろ 移植性が段違いじゃんか それに世界中に使ってる人がいるってことも 無視しとるやんけ、自分が無能なだけや 正直、C89以前のCなんか読めたものじゃないし、 かといってC++11以降の機能使いまくったソースも読めたものじゃない。 >>637 嘘だよ。初心者に優しいのは、テキスト編集だよ。 英語が苦手なだけでしょ。 マウントなんて、大分前からクリックするだけやんけ それよりディスクの故障チェックもできないとか、そっちのほうが怖いよ >>633 へー、今はむしろナウいんだけどな 取っとけるし 見通しがよいかどうかはシステムのサイズによる。複雑になれば階層構造のレジストリのほうがいいに決まってる。 基本的な型は用意されてるし、細かくセキュリティも設定できるし、読み書き用のAPIも用意されてる。 OS起動時に必ずバックアップを取ってから起動してくれるのもメリット。 なんでもviで作業したいというのが諸悪の根源。開発環境が50年前とい言われても仕方がない。 >>665 英語苦手じゃないけど、ちょっと言ってる意味がわからん。とりあえず、レジストリはめんどくさいぞ。 レジストリより環境変数のほうが使いやすいよな!!! って人は少ないだろう。 みかんとしいたけだったらみかんのほうが美味しいよな 何も足す必要がないということは究極を極めているということであろうか。 xmlの優位性はテキストだということだけれども、実際テキストエディタでxmlを閲覧すると醜悪そのものだよね。 >>4 Windowsのビルドって、どれぐらいかかるか知ってる? >>669 そういう意味なんだけどね テキスト編集の方が楽だけど、設定ファイルの雛型に 書いてある説明が英語なのは、日本人にとって辛いかなと 慣れればなんてことないけど。 ちなみに勘違いしてるみたいだけど autotools 作ったのはGnuではないよ。 自動的にMakefile作るシェルスクリプトが回覧されていく うちに、みんなで改良加えて、なんとなく出来上がったのを Gnuが採用しただけだよ。移植性を重視してたからね。 別に好きな奴使えばいいんだよ。気に入るのが無ければ 自分で作ればいい。それが自由であることの尊さなんだから。 autotools使うのは、それだけ多くのライブラリに依存 しているからで、その分のコードを書く手間を 省けるのだから、大したことでは無いね。移植性も 高まるし。でも、それが必要ないなら、別にMakefile添付でも 全然問題ないし、そういうプロジェクトも少なくない。 他のビルドツール利用でも良いし。なんか 勘違いしてない?これらはあらかじめ与えられてるん じゃなくて、享受するものだよ。嫌なら自分でやるんだ。 近所の落ち葉をかたずけるのと同じさ。君のために 誰かのためにやるんだよ。そう思うなら、自分で どうにかするんだよ。 良いこと言うね、全くそのとおりだわ 読んでねーけど INIのように書式とデータ構造とAPIが共通化されてるテキストベースの多層構造の設定を保持するメカニズムがあればよいんだよ、Linuxに。 ハイ論破厨ってたまに5chで見るけどいつも論破できてないよな。同一人物? 「ハイ論破」はダサいという風潮はとうにご存知だが必要不可欠な機能 C/C++やPerlのセミコロンみたいなもの 私たち日本人の、日本国憲法を改正しましょう。 『憲法改正國民投票法』、でググってみてください。 平 和は、勝ち取るものです。拡散も含め、お願い致します。 >>684 あなたは、日本人じゃない気がする。 日本人なら絶対しない「ご存知」「機能」の使い方してるから。 へー、LinuxにはJSON読み書きする「共通化されたAPI」ってあるのかぁ。 知らなかったな。 Cで使おうと持ったらインクルードファイルは何をしてして、どんな関数呼べばいいんだろう? 定番のunistd.hかな? JSONってそんないいもんじゃないよね、コメント書けないのは致命的 jsonが爆発的に普及したきっかけはバイナリ保存はしたくないけど、オブジェクトをそのまま保存したいって需要だから 設定に使うとしても開発者よりなんだよな。linuxは開発者フレンドリーだから開発者マインド無いときついってのは理解できるけども。 階層が深くないならiniが見やすくていい 階層が深いならyamlだし、記述性ならxmlだし、どれも一長一短あるけど、テキストエディタで開く設定ファイルならiniは使いやすい 複数行コメントを書けて、日本語も問題ない、Ruby が良い =begin 複数行 コメント =end Windows界はいろんな産業ロボットを使ってモノを生産しているのに Linux界はいまだに手作りでモノを生産しているようなもんだからね。 >>1 Unix は世界最古のOSらしいので、最初は良かれと思って決めたものが、 使ってみると使いにくかった、ということはあるかもしれない。 一例として、 $ コマンド名 パラメータ >a などとして、リダイレクトするとき、stdout と stderr が分かれている のも、現実的には不便。 $ . スクリプト名 と先頭にピリオドをつけないと環境変数がスクリプトによって設定できない のも不便。 どちらも、DOS では修正されていた。DOS の方が後発だから。 資本制企業はいかに人件費を削って量産するかを常に考えている。 少ないプログラマでより多くをと。 ところがオープンソースの世界はコーディングすること自体が楽しい って人々の集いだからな。効率化へのインセンティブが小さい。 >>697 別の環境変数で処理したいなら別の端末を開けば良いわけだから、 スクリプト内での設定を反映しないという仕様は、今となっては アリガタ迷惑だと思う。 ただ、行儀の悪いわけの分からんスパゲッティーで解読するのも 時間の無駄なスクリプトも多いが。 >>697 stdout と stderr と時系列的に合わせて出力しないと、解読しにくい 場合があるので、結局、2つの出力を合成したいことが多く、 1&>2 a だったか、覚えていられないような変な記号を書かなくてはならない。 あと、tee コマンドも覚えにくい。 というか何もかも覚えられない 脳が退化しているのか? &> a と、 1>&2 a の両方の書き方があったり、export が必要あったり無かったり、 そんなアホみたいなものは、むしろ高級な脳であるほど覚えられない。 高級な脳は、共通原理や一般法則だけを覚えようとし、単純で無意味な情報は 削除される傾向があるから。 >>1 なんという愚かなOSなんだろう。 DOSと同じことがこんなに長くなる : [DOS] $ コマンド名 >a [Linux] $ コマンド名 1>a 2>&1 >>703 > [DOS] > $ コマンド名 >a ↑間違い > [Linux] > $ コマンド名 1>a 2>&1 ↑1は不要 正しくはこうだよ [DOS] $ コマンド名 >a 2>&1 [Linux] $ コマンド名 >a 2>&1 参考 http://tooljp.com/windows/doc/stdout-stderr/stdout-stderr.html > (4)標準出力と標準エラー出力を同じファイルにリダイレクト > mycmd.exe > stdout-stderr.txt 2>&1 >>705 DOS に関しては、そもそも原則として多くのツールが、stderr を使わない流儀 だったので、stdout だけをリダイレクトすれば十分だったんだ。 だから、その意味で、 [DOS] $ コマンド名 >a は間違ってない。 要は、トータルの使い勝手で考えた場合だから。 ほらほら、間違いを指摘されて、 焦ってきてるぜwww つまり、DOSコマンドは設計に沿わないアプリが多かったということかな? >>709 いや違う。 最初からそれを前提にしていたので間違ってない。 あなたは、DOSの事知らないからそんなこと言ってるのでは。 >>710 いや、むしろ、stderr を滅多に使わないのがDOSの流儀だった。 少なくとも、コンパイラのエラー表示は100%、stdout に出ていたし、 その他のフリーソフトなんかの表示もほぼ、そうだった。 使いにくくなるだけなのに、stderr を使っているソフトが多いのは、Unix系の プログラマには、実は真の意味では頭の悪いのがいっぱい混じっているから ではないか。 明言していない前提 他社を憶測で知らないもの扱い ごく主観的な流儀 主観的な使いにくさでOSの草分け的な開発者を無能扱い これだけでまともに取り合う気がなくなる。 元々、stdoutとstderrが分れているのには理由がある。 理由もなしに分けたりしないという想像力があれば憶測でモノを言うと恥ずかしいことぐらいわかりそうなもんだが。 標準出力がUIを兼ねていたのでユーザーへのメッセージがerrで塗りつぶされるのが良くないし、 出力結果を次のコマンドに渡すときなどにerrメッセージが混ざると困るし、 コマンドが入力待ちの状態の時、errなんか出たらなにで止まってるのかわからないからな。 当時は無視するしか無いerrもあって切り分けるしかなかった。 例えば標準出力をファイルを書き込んでる最中にエラーを出力するにはstderrに出すべきだろ。 それを使いにくくなるとは。。。 >>715 コンパイラの出力をパイプで渡していくのは時代遅れだと思う。 今は、ファイルに書いて渡せば良い。 >>714 古い時代とはまた違った、今の時代に合った CUI の流儀がある。 Unix好きの人には、古いものを維持し続けようとする人が多すぎるのか、 または、古いソースを使いまわし続けすぎているためか、古い流儀のまま になっているために効率が下がっている。 >>716 ファイルに書いて渡すと遅くなる ディスクが遅いとかいう話じゃなくて 並列処理ができなくなるという話 >>719 実際のコンパイルは、a1.c, a2.c, a3.c, ・・・ などを別のCPUコアに渡して、 マルチコアでコンパイルするので、既にCPUコアが完全に使用しきられている。 なので、それ以上、コアに空きが無いので、パイプを使っても並列度が 上がることはほぼ無い。 一方、いったんファイルに書いてもファイル・バッファにキャッシュされ、 実際のディスクへの書き込みは、全く行われないか、または、ずっと後 になってから行われ、コンパイル作業中にはRAM上でデータの受け渡し が行われるためディスクの遅さは全く関係しないと言っても過言ではない。 >>720 パイプを使っている今はね。 ファイルを作ると遅くなるって言ってるの 今のやり方が最適なの。だからCPUコアを使い切れている >>721 パイプを使っても、0.000001% 位しか速度差が出ないのに、 gccなどのコマンドラインはめちゃくちゃ使いにくくなる。 コンパイラのエラーメッセージは標準出力に出て問題ないだろ。*nix系でも出るぞ。何いってんだこいつ。 パイプを使わないと動画をリアルタイムにエンコード出来ない >>725 別にパイプを使うなとは言ってない。 そういうケースでは使っていい。 どうやら時代遅れなのはお前の頭だと気づいたようだなw 違うな。 古いものと新しいものを逆さに捕らえる人がいて困る。 そもそもstderrの使い方知らなかっただけじゃないの? >>729 そんなことない。 stderr が有っても敢えて使っていなかった DOS の選択は賢いと思ってる。 >>1 gcc や clang も、include path の設定が無視されることがある。 複雑に複数の言語処理系がインストールされている場合に、 include path が勝手に「コマンドPATHから推定して」 決められて しまい、それを修正したいために、環境変数などを設定しても 優先順位がおかしくて、なかなか修正されないことがある。 しかも、その状況を確認するには、-v オプションを付けて 出てくる長いメッセージを解読しなくてはならない。 また実は、バイナリになってしまってからは修正すること が難しいパス設定が存在することもある。 その場合は、ソースから make する際に、./configure のパラメータで決められてしまっている。 つまり、バイナリレベルでは、動作が変えられるように 出来ていない欠陥品が多い。 $ prog1 | prog2 | prog3 > job1.out $ # で済むところを $ prog1 > tmp1 $ prog2 < tmp1 > tmp2 $ prog3 < tmp2 > job1.out $ rm tmp1 tmp2 $ # ってやるのか? >>732 最初のようなパイプでつなぐような表記を、コマンドラインから打つこと自体、問題なんだよ。 むしろ、ファイル名を指定して、少しずつ進んでいくほうが賢い。コマンドラインからだと。 型のあるプログラムだとコンパイラがエラーを出してくれる確率も高いが、 コマンドラインからだと、わずかな間違いが重大な問題に発展しやすい。 それに、どうせ、打ち間違える確率が高いので、何度も試すことになり、最初から 実行し直しになることが多い。 $apt-cyg show | grep -i nantoka や $コマンド名 | less みたいなことやら無くちゃならない頻度が高すぎ。長すぎて馬鹿だ。 こんな設計思想、ダメだ。 正直期待してなかったけど、初めてまともな返答をしてくれたね。 君は自分が世界の中心ではないということを理解すべきだ。 君のために存在するものなど何もない。 それでも適切な方法で助けを求めることはできるはずだ。 〇〇をうまく使えないという理由で〇〇の作者の頭が悪いなどというなら 誰も助けてくれないし君にとって良いことなど何も起こらない。 まあ、それはそれとして、シェルのヒストリ機能や行編集機能は使ってる? ターミナルエミュレータの copy&paste は? これらを使ってもまだ大変だと感じるなら Emacs なんかが助けになるかもしれない。 You! Visual Studio codeをinstallしチャイナyo! #ifdef なんかも設定に応じて認識して、ちゃんとコードの色に反映してくれるからねえ。 バランスが取れておらず、かつ、統一感もない。 それが Linux。 また、安さ以外に売りが無いのに最新のハードと最高の通信環境を要求する。 最新のハードを要求する前に、最新のハードのドライバを用意したまえ。 WINE もバイナリは新しい Linuxを要求するのに、Emulator としては、 64BIT Windows はサポートしていなかったりする。 つまり、新しいハードでしか動かないのに、古いOSしかエミュレートできない。 訳分からん。 あたらしいプログラムはPowerShelも対応するようにして 徐々に移行していったらええのに 貼れと言われた気がした 【田】Windows10のダメな点 ・個人情報を勝手にネットに垂れ流す ・診断データと使用状況データをMicrosoftに送信する機能をレジストリでオフにしてもなお8時間で4000回、93つの異なるIPのMicrosoftサーバへデータが送信されている ・エロファイルを持っている場合はそれも全て晒される ・間違ってロリファイルを持っていた場合はネットに繋いでいるだけで警察が来る ・死ぬほどUIがダサく異様に使いづらい ・ダサい上に抑揚のないフラットデザインのため、どのウィンドゥが手前で奥なのかわからない ・かつてあった多くの機能の半分以上をカットし、使わない機能をてんこ盛りにしたデブOS ・起動が超遅い。見かけ上早く起動したように見えるだけでほとんどのソフトを読み込んでいない ・スリープ復帰速度はほとんど変わらず ・ファイル圧縮・解凍速度も遅いまま。フリーウェアの圧縮・解凍ツール使ったほうが200%以上高速化する ・ファイルコピー速度が壊滅的に遅い。フリーウェアの高速コピーツール使ったほうが400%は速い ・メモリ使用量が馬鹿みたいに多い。初期は少なく見えるが使えば使うほど多くなる ・タブレットでも動くように設計されているが、利便性もデザインもiPadの足元にも及ばないゴミ ・標準ブラウザにEdgeとかいうゴミを採用。機能が少なすぎる上におそろしく遅くて使い物にならない ・無料のセキュリティソフトと称する重いウィルスソフトが多数憑依している ・仮想デスクトップと称するゴミを搭載。フリーウェアの仮想デスクトップソフトの半分の利便性もない。 ・Win8で削除したスタートボタンを恥を忍んで復活させた ・しかしスタートメニューにまつたくいらんメトロや宣伝がゴチャゴチャついて無駄に肥大化、邪魔。機能性がない ・非アクティブウィンドウもスクロール可とかいう、昔からできるような機能を大げさに宣伝 ・タッチパネルとして使いやすいUIとして喧伝しているが、デスクトップPCで画面の汚れるタッチ操作を行うのはよほどの馬鹿だけ ・ダサくて見づらいゴミフォント「游書体」がデフォルト設定 ・ほとんど反応しないゴミ丸出しの音声認識アシスタントCortana搭載。画面に向かって話しかけているぼっち野郎の姿はバカそのものw リダイレクトやら、 パスに文句言ってる人がいるが、 OS の問題じゃなくてシェルの仕様の話だろ シェルを変えればいいだけ パスの書式だけならそれで何とかなるけど、構造だけはどうにもならない事がある \\PC名\共有名\〜 みたいな表記はCreateFileとかに直接投げてそのまんま動く位、 ファイルシステムの構造とそれを実現する為の実装に密接してっかんな VSCodeが出たから、 「やっと、やっと、まともなIDEがLinuxでも使えるようになった! MSがやってくれた! ありがとうMS!」 ってことなんだろうね。 IDEを使ってるのではなく使われてるレベルなんだろーな 別に自分の好きなようにやりゃいいだけだろ Linuxの開発環境はVSCodeが出る前は vi使え! とか大声でいうやつがマジで居たぐらいに貧弱だったな。 環境改善に尽力してるMicrosoft様々だわ。 >>749 Kateでイイじゃん VSCodeだと、テレメとってくるから VSCodium入れてっけど Kateばっか使ってる >>751 VSCodiumの作者が、そう言ってて わざわざ毒なしのVSCode提供してくれてるから フィードバック提供しないって 設定すればイイだけなのかもしれんけど デフォルトでOnになってるし Officeもそうだけど、そういのばっかり 熱心にやってきて なにシレット仕込まれるか分かんないから VSCodium入れてる >>752 マジか。 MSは中国並みに情報収集熱心だな。 中国は国策でやってるわけだが、アメリカもなんぞ法律でもあって情報集めろってやってんのか? >>753 なんなんだろうね ほんと ヨーロッパだと、そいうのわりと敏感で 問題になってるみたいだけど 開発環境云々もUbuntu Japanese Teamによる志賀慶一氏のライセンス違反認定が取り消されないのも、 全部無能な鍋田コピペのせい。 鍋田コピペが悪い。 >>754 ね 国によってフィードバックのデフォルトに変化があったりするのかね GCC使ってる時点で性能をスポイルしてるからね。 40年前と同じで問題ないのさw VSCの中の人じゃないが、テレメがあるとしても基本的にはどの機能がどれだけ使われてる とか、デバッグ情報とかそんなんじゃないかな。"ユーザーエクスペリエンスの向上"のため。 そういうのも集められるのはイヤ、と言われるとアレだけど。 たまにハックしたバージョン入れててそれがクラッシュして、そういうユーザーに限って SNS等にキレた書き込みをしたりw そういうのもクラッシュトレースを見れれば安心w 今時のOSって、いろんなことを登録するじゃん。あれとかね... ま、あからさまに個人情報を集めたりしてそれがバレると今時大変なことになるからなあ。 cmakeとか、masonとかninjaとか良く分からん >>751 VCですらMSアカウント必須になって久しいのにテレメトリ無いとは思えんな コマンドラインのコンパイラさえMSアカウント無いと使えないよ read.cgi ver 07.4.6 2024/03/23 Walang Kapalit ★ | Donguri System Team 5ちゃんねる