投稿

2020の投稿を表示しています

Inkscape on macOS Big Sur

イメージ
迂闊にも macOS Big Sur にアップデートしてしまって、元からインストールしていた MacPorts 版 Inkscape が使えなくなっていることに気付いた。改めてインストールし直そうとしたが…… sudo port install inkscape poppler のビルドエラー しかし、poppler のビルドの失敗で先に進めなくなった。結構、アチコチで報告されている現象のようだ。 poppler のエラーについては、 #61901 poppler 20.12.1: Failed to build (macOS 11.1 Big Sur) の報告がドンピシャで、正解に辿り着けた。 sudo port -f uninstall cctools sudo port -v install cctools +xcode cctools のデフォルトでのインストールの仕方に問題があるらしく、一旦アンインストールして、+xcode オプションを付けてインストールし直せばよい。これで poppler のビルドが通るので、inkscape のインストールがその先に進み、インストールできた。 ただし、注意点があり、従来のように inkscape コマンドから X11 が自動で立ち上がらないので、先に手動で X11 を立ち上げた状態で inkscape コマンドを実行する必要がある。

GIMP on macOS Big Sur

イメージ
迂闊にも macOS Big Sur にアップデートしてしまって、元からインストールしていた GIMP が重くて使い物にならないことに気付いた( GIMP 公式 でも認識されている問題)。改めて最新版をダウンロードしてきてインストールしても改善せず。 そこで代わりに MacPorts 版の GIMP をインストールしようと思いついた。 sudo port install gimp poppler のビルドエラー しかし、poppler のビルドの失敗で先に進めなくなった。結構、アチコチで報告されている現象のようだ。 poppler のエラーについては、 #61901 poppler 20.12.1: Failed to build (macOS 11.1 Big Sur) の報告がドンピシャで、正解に辿り着けた。 sudo port -f uninstall cctools sudo port -v install cctools +xcode cctools のデフォルトでのインストールの仕方に問題があるらしく、一旦アンインストールして、+xcode オプションを付けてインストールし直せばよい。これで poppler のビルドが通るので、GIMP のインストールがその先に進むようになる、 MacPorts 版だからなのかはわからないが、これは X11 アプリとして動く。そのため、macOS の UI との連携性はイマイチで、フォルダー(Documents / Downloads / Desktop が駄目。Pictures なら ok)を開いたりすることができない。一応、画像ファイルから開くアプリを選んで GIMP を立ち上げることはできるが、一旦立ち上がった GIMP からファイルを開くことができないので、2 枚目以降の画像をレイヤーで開いて合わせて利用するようなことができない。究極的には、公式版の Big Sur 対応の改善を待つしかない。

Model-ViewModel-View の最近のイメージ

イメージ
以前にも MVVM について 記事にしたことがあった が、最近のイメージについて整理してみる。 基本的には、Model-ViewModel-View の 3 段構成である点については前の記事の通りなのだが、それぞれの部分において、抽象的ではなくより具体的な性質の違いが見えてきた。絵にすると次のような感じ: Model Model 部分はミキサーに材料を入れてジュースにするようなイメージで、最終的にひとつの結果の出力に到る。Perl や Python 等で手続志向のコンソールプログラミングをする時のようなイメージ。Web スクレイピング等で、データを加工するその複雑な処理過程をプログラミングすることになるが、時間の流れとしては一方向で、またデータオブジェクトも、成果物としては一つである(ミキサーの絵のように、入力される側の要素は、複数でも構わない)。 流れ的には一直線であるが、データの加工工程そのものに重要性がある。 ViewModel ViewModel 部分は時間の流れ的には一方向ではあるものの、Model に生じた更新を伝播させて複数の View 用の LiveData オブジェクトに帰着させる流れを定義する。ここでは伝播が分岐したりし、さらに、オブジェクト同士の依存関係から、前後関係に留意しなければならないので、Model 部分よりは安易ではない。 例えば、View 側にさらすための LiveData オブジェクトが、あるリストとインデックスとそこからリストとインデックスに依存して取り出す一つの要素だったとする。何も考えずにバラバラにそれぞれを LiveData として定義しただけだと、インデックスが最後尾にあった場合に、リストが伸び縮みすると、要素を取り出す時に IndexOutOfBound エラーを引き起してしまう。そのため、まずはリストを更新し、インデックスが新しいリストのサイズに対して問題ないかをチェックして必要な場合は修正し、それからリストとインデックスに従って要素を取り出すという順序になるようにコードを記述する必要がある。つまり、1) リスト 2) インデックス 3) 取り出す要素 という 3 者の先後は必ず守らなければならないものであることがわかる。 View ViewModel で非同期的な部分は吸収できてい

Material Slider 試用

イメージ
いつの間にやら、Material コンポーネントに Slider が追加されていた。以前は、Material デザインの公式サイトにコンセプトとしてのみ掲げられていて、実装が存在しておらず、結局 GitHub で適当なサードパーティライブラリーを探してきて利用するしかなかったが、今や Google 純正の Slider があるのなら、これを使うに越したことはないと思う。早速、使い勝手を見るために、10 分そこらでサンプルを作って試してみた。 サンプルアプリ build.gradle (:app) には依存関係として implementation 'com.google.android.material:material:1.2.1' を記述している。 値の実体としては 0 ~ 1.0f で受け取っており、TextView にはその値をそのまま反映している。吹き出しに表示されるラベルは値をそのまま使用せず、LabelFormatter で値を変換して 0 ~ 100 のインデックスとして表示している。 MainActivity.Java package com.scaredeer.materialslider; import android.os.Bundle; import android.widget.Button; import android.widget.TextView; import androidx.appcompat.app.AppCompatActivity; import com.google.android.material.slider.Slider; public class MainActivity extends AppCompatActivity { private TextView textView; private static final int MAX_INDEX = 100; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.lay

LiveData の observer 側の onChanged() がトリガーされるタイミング

source に対する setValue() がトリガーとなる 漠然とサンプルを参考にして LiveData を使い始めてきたので、複数の LiveData の処理がされるタイミングの前後関係が意図した通りにならずに困ってしまった。 MediatorLiveData や Transformations.map / Transformations.switchMap では lambda 表現で onChanged() を定義するが、この onChanged() の処理が、監視先の source の変更よりも先になってしまう現象が発生し、頭を抱えてしまった。 実際のところ、MediatorLiveData や Transformations.* で潜在的に行っていることにおいて、MutableLiveData が使われており、本来的に、source の変更が observer 側に伝えられるタイミングは、setValue() / postValue() であると明記されている。 いずれの場合でも、setValue() または postValue() を呼び出すことによってオブザーバーがトリガーされ、UI が更新されます。 公式ガイド「 LiveData オブジェクトを更新する 」 つまり、Transformations.* では source 側 onChanged() の末尾に隠蔽されているので曖昧に理解してしまっていたが、MediatorLiveData の onChanged() の場合はその中で source 自身が setValue() / postValue() された直後に、observer 側の onChanged() が実行されることになる。そのため、source 側が MediatorLiveData の場合に、必ずしも source 側の変更が先にならないといった現象が発生していたのである。「source が先、observer が後」ではなく、「source の setValue() / postValue() が先、observer の onChanged() が後」というのが正確だったわけである。 active でないと observe 自体が有効にならない もう一つハマったのが、source が更新されてい

LiveData と MutableLiveData の使い分け

イメージ
observe 関係の場合は、できるだけ ViewModel と View(Activity 含む)の関係を疎にして、一方通行の関係がいいと思う。つまり、ViewModel 内部では MutableLiveData 扱いのデータを LiveData にして外側、つまり View 側に対してさらす形である。 private MutableLiveData<T> mData; public LiveData<T> getData() { return mData; } 一方、user action を ViewModel に入力する場合はどうするのがいいか? この場合は、user action の影響を受ける LiveData は、View/Activity からの入力で変化することが当然であるから、上の observe の場合のように MutableLiveData を getter で隠蔽することは冗長である。なので、public な MutableLiveData を getter を介さずに直接さらしてしまえばいいと思う。 public MutableLiveData<T> mData; そうして、当該 MutableLiveData に関する処理を、無理矢理 ViewModel に置かずに、素直に、View/Activity 内で処理を記述するのが、 実は 適切だと思う。 というのも、user action によって処理を分けたいのは、View/Activity 側の都合であって、ViewModel 側の場合ではないケースが考えられるからである。通常、user action を受け付けるのは、Activity が active すなわち、onResume から onPause の間のライフサイクルにおいてである。なので、その間のみ処理を行って、それ以外のタイミングでは処理を停止しているような形にするのが望ましい。そうなると、それらの処理の主となるコードは、Activity 側の各ライフサイクルに応じたメソッドに配置して、処理の結果変更を受ける変数のみ、MutableLiveData として ViewModel 内に所属させておくのがストレートなコード表現になるわけである。 サンプ

QNAP NAS の RAID 1 ミラーディスクの追加エラー

イメージ
QNAP の NAS(2 ドライブ)を RAID 1(ミラーリング)で運用している。HDD は WD Red 6TB × 2。この NAS が夏の停電時に、古い方のドライブ 1 の HDD でエラーが発生し、ドライブ 2 のみの片肺運転となっていた。 QNAP の GUI 上で操作しても状況が変化しないので、一旦、ドライブ 1 を取り外し、外付け HDD ケースに入れ、Windows PC に接続し、パーティションを全て削除して、単一パーティションを作り、NTFS で完全フォーマットをし直した(完全フォーマットなので丸一日を要した)。Windows 上で S.M.A.R.T. 情報を見る限り、問題は発生していないようである。 QNAP に HDD を戻したが、個別情報でドライブ 1 はステータス「準備完了」、S.M.A.R.T. 情報「良好」となっているものの、論理ボリューム(RAID 1 のミラーリングディスク)としては追加されずに、エラー(Add drive 1 to the volume failed)となった。 HDD を再度 Windows PC に戻して、Windows 上で パーティションを削除してパーティションが存在しない状態にしてから 、QNAP に HDD を戻した。すると今回は、ミラーリングに追加され、フォーマット処理が無事開始した。 QNAP でミラーリング(フォーマット処理含む)が終了後、S.M.A.R.T. の完全テストも行ったが、何のエラーも検出されなかった。元のエラーは何だったのだろうと思うが、多分、QNAP の OS が馬鹿だっただけだろう。 以上、QNAP に HDD を追加する・し直す場合には、追加する HDD はパーティションを削除した状態で追加しなければならないという話. 余談 1:WD Red WD Red シリーズ は元々は CMR 方式だったのだが、後に RAID に不向きな SMR に変更されてしまった( 参考 )。単に Red だからと安易に信用せず、CMR 方式の型番であることを確認して購入した方がよい。 WD 公式ブログのリスト によると、2TB 〜 6TB の EFAX が SMR なので、買ってはいけない型番。一方、8TB 〜 14TB の EFAX

SKK for Android とポケモンキーボード

イメージ
SKK Android で SKK と言えば、 SKK for Android (3.4) APK をインストール後、 設定 > システム > 言語と入力 > 仮想キーボード > +キーボードを管理 で、SKK for Android を仮想キーボードに追加する。追加した SKK for Android をタップすると、SKK for Android 用の設定画面に入ることができる(この中で最初に、辞書ファイル解凍の実行が必要)。ここで句読点のタイプを「。、」にしておく。 Nintendo Wireless Keyboard (Bluetooth) ペアリング時は Fn を押しながら電源を入れればよい。Gboard のキー配列では「日本語 109A 配列」で ok。 これだけでも SKK の動作に支障はないが、Control キーは多用するので、Caps Lock を Control にしておくのが望ましい。 KCM リマップ (106/109ハードウェアキーボード配列変更 (+親指Ctrl) [日本語配列])をインストールして、日本語 [Caps]→[Ctrl] の設定を使った。

このパスワードは以前データ漏洩で検出されたことがあり、強力なパスワードに変更する必要があります

イメージ
Mac の Safari でパスワードを記憶したサイトにログインしようとしたら、「このパスワードは以前データ漏洩で検出されたことがあり、強力なパスワードに変更する必要があります」というポップアップメッセージが表示された: 最近になってから初めて経験したが、調べてみるとこれは macOS Big Sur からの新機能らしい。 自分はパスワードについては怠惰で、同じパスワードを使い回ししていたので、ちょっと危機を感じている。 Safari の環境設定のパスワード 他のパスワードやサイトはどうなのかというのが気になったが、ポップアップが表示されてから逐一行動するのもどうかと思った。ちょっといじっていて、「Safari の環境設定のパスワード一覧」に、このデータ漏洩についての警告も表示されているのに気付いたので、これで一目瞭然、対策をとるべきパスワードとサイトがわかる。 デフォルトで有効(✅)になっていたが、「既知の漏洩データによって侵害されたパスワードを検出」がポイントのようだ。

Static Singleton vs. Application Subclass

シングルトンは自前の Static Singleton を実装すべきか、Application サブクラスを使うべきか? Application のサブクラスを Singleton 的な目的で使うことはよくある話だが、実際に Static Singleton を使うのか、(Static Singleton の一種である)Application サブクラスを使うのかには、議論の余地があるようだ。 StackOverFlow の議論: Singletons vs. Application Context in Android? によると、Static Singleton 派と Application サブクラス派に分かれていて、両派ともほぼ対等な支持を得ている。 しかし、公式リファレンスには以下のようにある: ★ Note: There is normally no need to subclass Application. In most situations, static singletons can provide the same functionality in a more modular way. If your singleton needs a global context (for example to register broadcast receivers), include Context.getApplicationContext() as a Context argument when invoking your singleton's getInstance() method. この記述を見る限り、どちらかというと、Singleton 的なことをしたいのであれば、単に Static Singleton を使う方がお勧めのようだ。global context を使いたいのであれば、Context.getApplicationContext() で得た Context オブジェクトを Singleton の getInstance() で引数として渡せば用が足るとしている。「Singleton 的なもので、さらに処理の中にグローバルコンテキストを扱うものが含まれるから Application を使う必要がある」と考

EULA ダイアログ用モジュール

アプリのインストール後の初期画面で、ライセンス条項(EULA: End User License Agreement)を表示して、承認を求めるダイアログ(DialogFragment)をライブラリーモジュールとして実装してみた。 基本は DialogFragment なので、下端の Yes/No のボタンに関する挙動と、ダイアログに表示するライセンス条項に関するコーディングが主となっている。 Activity への組み込み方 MainActivity の onCreate 内の処理のかなり初期の段階で @Override protected void onCreate(Bundle savedInstanceState) { (...) EulaDialogFragment.checkLicense(this); (...) } という感じで使う。最新バージョンのライセンスが未受諾であれば、DialogeFragment が実体化される。 また、MainActivity 側では、イベントリスナー(後述)を実装することで、拒絶された場合にアプリを終了する等の挙動を組み込むことができる。 public class MainActivity extends AppCompatActivity implements EulaDialogFragment.Listener { (...) @Override public void onDialogPositiveClick(DialogFragment dialog, long eulaVersion) { Bundle params = new Bundle(); params.putLong("EULA", eulaVersion); params.putBoolean("accepted", true); firebaseAnalytics.logEvent("Installation", params); } @Override public void onDialogNe

UML クラス図

クラス クラス名 + メンバー名: 型 ~ メンバー名: 型 - メンバー名: 型 # メンバー名: 型 + メソッド名(引数: 型): 型 ~ メソッド名(引数: 型): 型 - メソッド名(引数: 型): 型 # メソッド名(引数: 型): 型 スコープは +: public; ~: package; -: private; #: protected スタティック変数/メソッドを示す場合はアンダーラインで修飾する。 インスタンス同士の関係 Dependency(依存) independent <- - - - - - - - - - dependent どちらが「依存する側(dependent / client)」で、どちらが「依存される側(independent / server)」なのかを表す。依存する側から依存される側に向かう破線矢印。 Association(関連) label independent <------------------- dependent     1                 1,* 実線で結ばれ、関係名を付す場合には、線の中央の上にテキストを記す。また、多重度(multiplicity)を表す場合には、各ノードの付け根に m..n といった形式で範囲を示す。 さらに、関連性に方向性がある場合には、双方向(bi-directional)か片方向(uni-directional)かによって、矢印で示すことができる。また、自分で自分を参照するような反射的(reflexive)な関連の記述も可能である。 Aggregation(集約) bag ◇------------------- item 集約は関連の中でも特殊なケースで、has-a で表される全体←部分の関係のこと。ただし、合体(Composition)と違って、部分側は全体のライフサイクルに依存せず、独立して存在する。ショッピングバッグに入った色々な野菜のようなもの。 白抜きの菱形で集約先を示す。 Composition(合体) puzzle ◆------------------- piece 合体も関連の中でも特殊なケースで、has-a で表される全体←部分の関係のこと。ただし、集約(Ag

四聖諦

馬場紀寿『 上座部仏教の思想形成──ブッダからブッダゴーサへ 』によると、「説一切有部や正量部といった諸部派が四諦観察を中心とした修行体系を構築した」としているが、これは語弊のある表現ではないかと思う。というのも、「元々初期仏教には存在しなかった修行体系を、部派時代に新たに作り出した」かのような誤解を生むかもしれないからだ。もちろん、修行体系の詳細にいたるまでの全体的な体系は、各部派がそれぞれ生み出しているわけだが、四聖諦を仏教修行の最も基礎的な枠組みとして中心に据えることは、四聖諦が経典のあちこちで説かれていることからも、部派以前のブッダ在世当時から仏教修行者の間で綿々と実践されていたはずである。 ところが、ゴータマブッダが、菩提樹において、「何を」悟ったのか、という悟りの目的物に関する話題において、初転法輪経などでは明らかにそれが「四聖諦」であることは動かしようのないことなのだが、四聖諦では何ら神秘性がないことから、意味不可解な「縁起」こそがブッダの悟りの目的物であるとする説が生じ、やがて四聖諦を押し退けて縁起に究極の重要性を持たせようとする数百年の活動によって、仏教に歪みを蓄積させることになった。 また、四聖諦の「滅諦」が「単なる苦の抑止」ではなく、「涅槃」を意味することになったため、四聖諦の意味することが本来の意味とは別のものとなってしまい、矛盾を生じることになってしまった。その涅槃へと到達するための鍵・パスポートとなる概念として縁起が神秘性を持って語られるようになった。 そのようにして、(本当はこちらがブッダの悟りの目的物であったはずの)四聖諦が正常に機能しなくなり、一方で縁起がブッダの悟りの目的物であるという思想が一般的となってしまった時代に、上座部大寺派にブッダゴーサが登場する。彼は正常に機能しない四聖諦についての問題を解消すべく、縁起が(縁起も)ブッダの悟りの目的物であるという説に基いて、依然として四聖諦がブッダの悟りの目的物であるという説と併存していた状態からさらに進んで、むしろ縁起こそがブッダの悟りの目的であるという説の方を強調して、四聖諦がブッダの悟りであるという説の方をフェードアウトさせたのである。 ここで一つ忘れてはならないのが、ブッダゴーサの仕事は、本来あくまでも上座部大寺派「内部」でのものだったという点である。馬場の論文に

馬場紀寿『上座部仏教の思想形成──ブッダからブッダゴーサへ』

イメージ
最近、個人的な経験がきっかけで四聖諦について考えていて、ある一つの発見があった。そしてふと、(中身がすっかりすり代わって実質的に別物と化してしまった大乗仏教はそもそも論外としても)現存する仏教の中で最も原始仏教寄りである上座部仏教(テーラワーダ)にしても、より古い時代の仏教とは違っている部分があり、元々は四聖諦そのものが修行内容だったというような話があったのを思い出した。東大の学者で馬場という名前だけが記憶に残っていたので、早速調べて、馬場紀寿『 上座部仏教の思想形成──ブッダからブッダゴーサへ 』であることがわかり、再度、手に取って読み直してみた。 上座部の系譜 この部分の話はこの本の主題そのものではないのだが、上座部仏教の系譜について知らない人にとっては簡潔に良くまとまっている(流石は東大出身の人だけはある)文章なので、一読の価値はあると思う。 したがって、上座部仏教の〈独自性〉と〈同一性〉の両者は、五世紀前半、スリランカの上座部大寺派へ集約される。上座部仏教が他の仏教とは異なる固有の性格を帯びて、その〈原型〉を形成したのは、5 世紀前半の上座部大寺派においてなのである。そこで 5 世紀前半の上座部大寺派が果たした歴史的役割を検討するために、上座部仏教の歴史を概観した上で、上座部仏教がその〈原型〉を形成した時代・場所・人物を改めて特定し、そこに研究の焦点を絞ることにしたい。 スリランカには、紀元前 3 世紀頃にインドから仏教が渡り、アヌダーダプラの都に大寺(Mahāvihāra)が建てられた。紀元前 1 世紀頃には、同じアヌラーダプラに無畏山寺(Abhayagirivihāra)が建てられ、その後、祇多林寺(Jetavanavihāra)が建てられた。これら 3 派はいずれも「上座部」の系統だったが、大乗仏教に対する態度は、大寺派とその他 2 派ではまったく異なっていた。 大寺では、紀元前後から三蔵に対する註釈が作成されるなど、思想活動が続けられていたと考えられるが、5 世紀初頭にブッダゴーサ(Buddhaghosa)という学僧が登場し、これらの古資料を踏まえて、上座部大寺派の教学を体系化した。現存資料を見る限り、「上座部」や「大寺」の伝統を掲げて作品を著し、思想を体系化したのは、ブッダゴーサがはじめてであって、彼以前に遡ることはできない。ブ

Nexus 6P のファームウェアのダウングレード 8.1.0 → 7.1.2

既に時代遅れ機種になっている Nexus 6P だが、昨日、適当に野良 APK をインストールしたら、何となく怪しい挙動を見せたので、ファームウェアのファクトリーリセットのついでに、最終バージョンの 8.1.0 から 7.1.2 にダウングレードした。 ダウングレードであろうが、アップグレードであろうが、任意に選んだファームウェアを焼くだけなので、基本的な手順は同じである。 ファームウェアの焼き方 公式ページ( Flashing instructions )に基本的な情報は揃っている。 基本的には、該当ファームウェアをダウンロードすると、ファームウェアを焼くためのスクリプト(flash-all.sh)が含まれているので、それを実行すればいい。ただし、このスクリプトが前提としている fastboot コマンドが実行可能な状態を整えておく必要がある。 また、セキュリティのために、ファームウェアの書き込みロックがかかっている場合は、書き込み作業の間は解除しておく必要がある。 Nexus6P を fastboot モードにする fastboot コマンドの準備(Mac 側) ファームウェア書き込みのロック解除 以上の 3 点を除いて、USB ケーブルで Mac と接続し、Mac 側で公式ページからダウンロードした Nexus 6P 用の 7.1.2 のファームウェアファイル(👉 N2G48C, Aug 2017 )の中の flash-all.sh を実行するだけのシンプルな作業である。 Nexus6P を fastboot モードにする fastboot モードは、fastboot コマンドと同じく Android SDK Platform-Tools(後述)に含まれている adb コマンドを使う('adb reboot bootloader' コマンドを実行)か、Nexus6P を操作してボリューム下げボタンを押し続けながら電源ボタンを押し続けて起動することで、fastboot モードに入ることができる。 fastboot コマンドの準備(Mac 側) fastboot コマンドは Android SDK Platform-Tools に含まれるものなので、Android アプリ開発用の Androids

uWSGI on OpenWrt

以下の内容は OpenWrt 19.x の時点でのやや古いものであり当面の間は残しておくが、最近の 23.05 に基いた新しい文書 を別途作成したので、通常は新しい方を参照して欲しい。 OpenWrt ルーターに Django を導入したいと思ったので、それにあたってはその下準備として、アプリケーションサーバーを整えておく必要がある。Python 系のアプリケーションサーバーとしては uWSGI が定番のようなので、まずここでは uWSGI 環境の構築について一通り行いたいと思う。 luci-ssl-nginx OpenWrt では luci-ssl-nginx というパッケージがあり、これを導入するとデフォルトの uHTTPd 環境の LuCI に代えて、NGINX(かつ SSL)環境の LuCI が動くようになる。この環境において、Lua プログラムである LuCI に NGINX が CGI としてリレーするために、uWSGI が使われている。この場合は、uWSGI はあくまでも CGI を扱うためのアプリケーションサーバーの一種として使われているだけで、Python 固有の WSGI サーバーとして使われているわけではないが、それでも NGINX ⇔ uWSGI 間のプロトコルは uwsgi プロトコルが使われている点は特筆すべき点だろう(NGINX は uwsgi プロトコルにネイティブ対応している)。 NGINX が uwsgi プロトコルを使うということは、設定ファイル中で uwsgi_* プレフィックスを使った設定が行え、uwsgi_pass でソケットを通じて uWSGI にリレーできることを意味している。 例えば、OpenWrt の luci-ssl-nginx を入れた状態では uWSGI 関連の設定は次のようになっている。 /etc/nginx/luci_uwsgi.conf(/etc/nginx/nginx.conf からインクルードされている) location /cgi-bin/luci { index index.html; include uwsgi_params; uwsgi_param SERVER_ADDR $server_addr; uwsgi_modifier1 9; uw

ASCII の IPv6 の記事

とりあえずのブックマーク なぜいま、あらためて「IPv6」を学ばなければならないのか IPv6で使うアドレスは、IPv4とどこが同じでどこが違うのか Webサーバーの設定を変更して「IPv6対応サイト」にする【前編】 Webサーバーの設定を変更して「IPv6対応サイト」にする【後編】

NGINX を Drupal 用に設定する

とりあえず Drupal のインストールは成功した が、処理時間の設定を除き、特に Drupal 用の設定を何も行っていないので、現状では少々問題が残っている。この記事ではより細かい設定を行って行こうと思う。 NGINX 公式の Drupal 用設定例 👉 NGINX 公式の Drupal 用設定例 server { server_name example.com; root /var/www/drupal8; ## <-- Your only path reference. location = /favicon.ico { log_not_found off; access_log off; } location = /robots.txt { allow all; log_not_found off; access_log off; } # Very rarely should these ever be accessed outside of your lan location ~* \.(txt|log)$ { allow 192.168.0.0/16; deny all; } location ~ \..*/.*\.php$ { return 403; } location ~ ^/sites/.*/private/ { return 403; } # Block access to scripts in site files directory location ~ ^/sites/[^/]+/files/.*\.php$ { deny all; } # Allow "Well-Known URIs" as per RFC 5785 location ~* ^/.well-known/ { allow all; } # Block access to "hi