  |
はてなキーワード: クローとは
(差分 | 履歴) . . 憤怒の天使アクローマ/Akroma, Angel of Fury; 20:29 . . (-42) . . 219.100.86.153 (トーク) (ほらカルトだろ。「事件」では全くないものを「事件」と言い続ける事に固執にする。勘違い、プレイミスをやっておいて「本来は勝っていた」と言いはり「事件」と言う表現にする。)
(差分 | 履歴) . . 憤怒の天使アクローマ/Akroma, Angel of Fury; 20:23 . . (+39) . . 133.200.139.65 (トーク) (219.100.86.153（トーク）による第339034版を取り消し)
(差分 | 履歴) . . 憤怒の天使アクローマ/Akroma, Angel of Fury; 19:56 . . (-39) . . 219.100.86.153 (トーク) (カードの効果を忘れる、勘違いするなどで負けた試合を「本来なら勝っていた」「事件」と言うのは小室修のカルト信者すぎる表現)
久し振りに何か始まってやがる
一応、Xの利用規約を貼っておくが、利用規約には違反している。法律については専門家ではないので分からないが日本だと「不正アクセス防止法」に該当しそうな気がする。
ユーザーは、当社より本サービスへのアクセスとその利用について許諾を得ることの対価として、当社ならびにその第三者プロバイダーおよびパートナーが、本サービス上に広告を掲載すること、またはコンテンツもしくは本サービスから得られる情報（その提供者がユーザーであるか他者であるかを問わず）の表示に関連した広告を掲載することに同意するものとします。ユーザーはまた、たとえば当社のサービスの妨害や当社が提供するインターフェースおよび手順以外の方法を使った当社のサービスへのアクセスにより、当社のサービスの不正利用をしないことにも同意するものとします。ユーザーは、適用される法令が明示的に許容する範囲のみを除き、本サービスの一部としてユーザーに提供されるソフトウェアの技術的制限を回避したり、ソフトウェアのリバースエンジニアリング、逆コンパイル、逆アセンブルをしたりしてはなりません。ユーザーは、本サービスへのアクセスまたはその使用中に、次のいずれも行ってはなりません。（i）本サービス、当社のコンピュータシステム、または当社のプロバイダーのテクニカルデリバリーシステムの非公開部分へのアクセス、不正な改ざんもしくは使用、（ii）システムもしくはネットワークの脆弱性の探索、スキャンもしくはテスト、またはセキュリティもしくは認証方法の侵害もしくは回避、（iii）当社から提供される（かつ該当する利用条件に従う場合にのみ提供される）、当社の現在利用可能な公開インターフェース以外の方法（自動プログラムか否かを問わない）での、本サービスへのアクセスもしくはその探索またはアクセスもしくは探索の試み（ただし、当社との個別契約で特に許可されている場合は除く）（注: 本サービスへのクローリングは、robots.txtファイルの定めによる場合は認められていますが、当社による事前の同意がないまま本サービスのスクレイピングをすることは明示的に禁止されています）、（iv）電子メールもしくは投稿でのTCP/IPパケットヘッダーまたはヘッダー情報の一部の偽造、または方法の如何を問わず、改ざんされた情報、詐欺的情報もしくは情報源を偽装した情報を送る目的での本サービスの利用、または（v）いずれかのユーザー、ホストもしくはネットワークのアクセスの妨害、または遮断（もしくはその試み）（本サービスへのウィルスの送信、オーバーロード、フラッディング、スパミング、メールの大量送信、あるいは本サービスを妨害したり過度な負荷を与えたりする方法でコンテンツの作成をスクリプトすることを含みますが、これらに限定されません）。当社はさらに、（i）適用されるすべての法令、規則、法的手続や政府の要請へ対応し、（ii）本規約を実施し（規約違反の疑いがある場合の調査を含みます）、（iii）不正利用、セキュリティもしくは技術的な問題を検知、防止もしくはその対処をし、（iv）ユーザーからのサポート要請に対応し、または（v）Twitterやそのユーザーおよび社会全体の権利、財産もしくは安全を保護するために、当社が必要であると合理的に判断する一切の情報について、アクセス、閲覧、保存、および公開する権利を留保します。当社は、当社のプライバシーポリシーの定めによる場合を除き、個人識別情報を第三者に開示することはありません。
Apple製品に何らかの形で関わっているのならAppleの動向が気になるのは当然だと思うし、日本にいて見える景色は元増田に書かれたように考えるのも無理ないよなと思う。
しかし、既に沢山ブコメなどで指摘があるように、日本での単価が上がってるのは主に国策の円安の影響であり、Apple自体が同じ商品の価格を劇的に上げている、というわけではない。
もちろん元増田の懸念通り、ラインナップとしてProやPro Maxといったより高単価の商品は出しているが、そっちが主力になりつつあるのは「より多くの客がそっちを望むから」であり、その需要にAppleが答えているだけだ。いくらAppleがリリースしても需要のない商品はminiのように消えるのだから。悲しいことに。
客が高単価を望み、それにAppleが答えている限り
は今のような状況は続くだろうし、客単価を上げないことが正解とも限らない。
確保できるときに利益を確保して不測の事態に備えることが重要だ。
HTCやLGは幅広いラインナップで顧客に訴えたにもかかわらず、それが出来ずに撤退の道を選択したのだから。
Appleがずっと成長し続けるなんて盲信するのはバカのやることだが、Vision Proを見る限りは当面は大丈夫そうと感じた。
一向にXR市場のうだつが上がらない状況で無理にXR全振りの低価格デバイスなんかを出してきていたら自滅の始まりだった可能性は非常に高いが、
XR対応はあくまでおまけで、軽いワークロード処理や既存Macの拡張ディスプレイ路線を明確にした物好き向けの高価格デバイスだったのは
まだAppleという企業の鼻が鈍っていないことの証左だと思う。
Appleは儲けている。
いろんな方面からやっかまれて国から商売の具体策に文句付けられるレベルで儲けている。
国からの余計な横やりで商売が瓦解するリスクはまだ健在だが、Apple自身のヘマで商売が傾くときはゆっくり傾く可能性が高いとみている。
しかしながら、そうであるからといってAppleに依存していればいいというモノでもないので、リスクは適切に考慮して対策しておく必要がある。
Dockerは、開発から運用まで一貫した環境を提供することで、開発者の作業負担を減らすという大きな利点があります。また、仮想マシンと比較してリソースの使用効率が高いため、エコとも言えます。
ただし、確かにDockerには一定のオーバーヘッドが存在します。これは、DockerがゲストOSを持たずに、ホストOSのカーネルを共有して動作するためです。それにより、アプリケーションの実行に必要なリソースが追加で必要になり、パフォーマンスに影響を及ぼす場合があります。
また、Dockerを利用する際の設定や構成によってもパフォーマンスは大きく変わります。例えば、Dockerのネットワーキングやストレージの設定、またホストOSとの互換性など、考慮すべき要素は多数存在します。
あなたの現在の状況について具体的に述べると、FESSのクローリングが重いという問題は、Dockerのオーバーヘッドだけが原因ではない可能性があります。Dockerコンテナ内のFESSやJVMの設定、ホストマシンのリソース割り当て、ネットワークやストレージの設定など、様々な要因が絡んでいるかもしれません。
また、Dockerのログ出力が多いと感じる場合も、実際のところはFESSやDockerの設定によるものかもしれません。ログの出力レベルを調整することで、必要な情報だけを出力するように設定することも可能です。
しかし、これらの設定を調整するためには一定の知識と経験が必要で、それがなければ素直にネイティブ環境での構築が良い選択かもしれません。結局のところ、どの方法が最善かは具体的な要件や状況によります。
このような状況に直面した際には、パフォーマンスの問題を具体的に分析し、適切な解決策を見つけるためにパフォーマンスモニタリングやロギングツールを使用することをお勧めします。それにより、問題の原因を特定し、適切な対策を講じることが可能になります。
たとえば、Dockerが高いCPU使用率を示している場合、それはコンテナ内のアプリケーション（この場合はFESS）が高いリソースを消費している可能性があります。その場合、アプリケーションの設定や実行パラメータを調整することで改善できるかもしれません。
また、Dockerコンテナのリソース制限を調整することも検討できます。Dockerは、コンテナに割り当てるCPUやメモリの量を制限する機能を提供しています。これにより、他のプロセスに影響を与えることなく、特定のコンテナのリソース使用量を管理することが可能です。
さらに、Dockerのボリュームやネットワーク設定が適切であるかを確認することも重要です。不適切な設定はパフォーマンスに悪影響を及ぼす可能性があります。たとえば、ファイルI/Oのパフォーマンスは、ホストOSとコンテナ間でデータを共有する方法に大きく依存します。そのため、適切なボリュームの設定や、パフォーマンスを向上させるための最適化オプションが適用されていることを確認することが重要です。
最後に、Docker自体のアップデートもパフォーマンス改善に寄与する場合があります。最新のDockerエンジンには、パフォーマンスを改善するための修正や改善が含まれていることがあります。
これらの要素を考慮に入れ、Dockerのパフォーマンスを最適化する方法を探すことができます。ただし、これらすべてを試してもパフォーマンスが改善しない場合や、必要な知識や時間が不足している場合は、Dockerを使用しないネイティブな環境での構築が最善の選択であるかもしれません。
そりゃそうなんだろうけども。そんなに？
追記：FESSをOSに直接インストールするのに参考にしたというよりコピペさせてもらったのは以下の記事
https://qiita.com/hyoshiaki/items/598127fe30b94bd82b6e
半年前に辞めてしまった前任者から存在すら知らされていない客先のメールアカウントが必要になった。
無いならないであきらめてもらえるんだが、僕は優しいのでファイルサーバに無いかくらいは確認しようと思ったが
なので昔うっすら使ったことのあるFESSで全文検索しよう、多分txtかxlsだろう。
とウェブサイトで構築方法を見ると今はDockerで動かすのが良いらしい。何がいいか知らんが。
ドキュメントに従いインストールし、なんとかクローリングまで実行できたが、重い。重すぎる。
サブフォルダ無しで100ファイルくらいのフォルダでも2，3日回しても終わってない。
CPU使用率が50%超えてるんだよ！ってログが出まくっている。そのログ出力無駄じゃない？
使えないかー、とググってみるとDockerではなく素で構築する方法を有志の方が書かれているのを発見。
それに従い構築。するとサブフォルダ5階層くらいのフォルダが3分くらいで終了。
ログにCPUがーっていうのも出てないわけではないが、明らかに少ない。なんだこれ。
Dockerは構築楽らしいしVMよりエコだっていうのは聞いたことあるんですが、
素のOSに入れるよりはどうしてもオーバーヘッドあるんですかね、というのが今回の教訓でありました。
