Apache+PHP on Mac でWordPress

かな〜り久しぶり。で、備忘録。

Mac Miniを諸々の理由から購入したので、諸々遊ぼうかと。で、表題の通りのことをやりたい。

まずは、Apache。これは既にMacに入ってる。なので、これを起動するだけ。

sudo apachectl start

DocumentRootは標準で

/Library/WebServer/Documents

設定関連は

/etc/apache2/

で、次にPHP。以前はPHPは標準でMacに入っていたが、これが無くなったので、Homebrewから入れる。さらにPHPを導入するまでは以下を参照。

https://qiita.com/ynack/items/ab150213f23f11a03cbc

ちなみに、途中のPHPのパス設定は、HomebreでのPHPインストール最後に表記される内容で2コマンド実施を提案されるので、それを実施することでOK。

次にMySQL。これもHomebrew経由。

brew install mysql

任意のユーザー作って、許可与えて、DB作っては特に変わらない。

で、任意のフォルダにwordpress展開して、DocumentRootを指定して完了。

ちなみに、Apacheのユーザーは「_www」グループは「_www」となっている。なので、こいつらの所有にしてやらんとめんどい。

以上。

JasperReportでのStyle適用

JasperReportをEclipse上でエディター使って編集していたら、Styleを設定できて、且つ、Condition Styleってのが使えることを知ったので使ってみようとしたら、どハマりした。。。

まず、例としてTextFieldで考えると、プロパティの適用順はStyle→個別の順で設定され、後勝ちのようだ。そのため、各個別のTextFieldで例えば背景色などが設定されていると、Style指定していても、個別設定側が優先される。

このとき、GUIでプロパティ設定していると、どうやら罫線などのいくつかのプロパティは「未設定のように見えて未設定になっていない」場合がある。GUI上では未設定(灰色で文字表示)とされていても、ソースを見ると、例えば罫線などは「0px」になっているだけで、設定としては残っている。これがややこしくしている原因になっている。

そのため、ソースで直接該当のプロパティを消すなどして対応する必要があり、特に誤って設定してしまった場合などは注意が必要となる。

というわけで、ここ1週間くらい悩んだことが解決したので、覚書。。。

JasperReportにおける行の拡張

Javaの帳票出力で、JasperReportを使用し始めている。10年前には聞いたことなかったけど、今は結構スタンダードのようだ。

で、このJasperReportではEclipseでテンプレートをイメージ編集できるのだけど(この辺については別途纏めよう。。。)、そのとき、各フィールドの自動拡張がどのように設定できるのかが、分からなくて、路頭に迷った。。。

結果として、該当の「TextField」ー「プロパティー」ー「テキスト・フィールド」ー「Text Adjust」で「StretchHeight」を選択することで縦に延びる。さらに、「外観」において「Streatch Type」を設定しておくことで、他のTextFieldに追随して外観を延ばすことができる。この「外観」と「テキスト・フィールド」の設定の関係性で、Band内の様子が変わるので、諸々試すといい。

というわけで、取り急ぎ、備忘録でした。

XCode PlaygroundでのRealmSwiftの動作がおかしい???

Realmのテストとして、Playgroundで諸々書いていたら、プロパティにDate型が有るときに正常にaddやcreateできなかった。

何が原因か分からず2日ほど悩んだ。。。元々FundationのJSONSerializerで得られたものを入力しようとして、出来ずに悩んで、この問題にぶち当たった。

結果、わかったのは、通常のプロジェクト内では正常に動作したということ。ちなみに、Data型では普通に出来た。

参照元

バグではないのかもしれないが、RealmのテストはPlaygroundでやらない方がいいなぁと思った。

XCode13でのColor Literalはどこに?

XCodeの使い勝手の良い部分として、自分が重宝しているColor Literal。

こんなやつです。色を指定する時にコード内でイメージ化されているのはほんとに嬉しい。

ただ、XCode13になって、なんだか上手く指定できなくなっていました。そこで調べたところ、どうもXCode13での不具合のよう。そして、その解決策はStackoverflowに載ってました。

How to use Image Literal in Xcode 13

う〜ん、さすが。

C#でのSSLによるサービス(SOAP)通信とクライアント認証

いやぁ、かなりのご無沙汰。1年以上書いてないとは。。w

書くネタについては溢れんばかりにあるけれど、書くのが面倒で書いてない。。。つくづくこういう行為があっていないのだなぁと思います。

さて、タイトルにあるようにC#でSSL通信のSOAPを利用しようとしたら、めっちゃ躓いたので、備忘録。

まず、クライアント認証について。

クライアント認証は、ものすごく簡単に説明すると、リバースプロキシによる実サービスへのディスパッチ時に証明書による認証を要するもの、って認識です。間違っていたらすんません。

で、公開されているサービスをクライアント認証に対応させるために、どうやったら良いのかが分からず、最終的にはMicrosoftの有償チケット使ってしまった。。。(実際にはネット上に情報は溢れていたんだけど。。。)さらに、自分の用途では、通常のHTTPでのサービスとリバースプロキシ経由HTTPSでのサービスを切り替える必要があったので、さらに難解(当者比)になってしまった。

基本的にクライアント認証は、Windowsの証明書に組み込まれたものを利用する。まずはこの証明書を取得することが必要となる。取得するには、下記のコードを準備する。元ネタはここ

       public static X509Certificate2 GetCertificateFromStore(string certSubjectName)
        {
            X509Store store = new X509Store(StoreLocation.CurrentUser);
            try
            {
                store.Open(OpenFlags.ReadOnly);

                X509Certificate2Collection certCollection = store.Certificates;
                X509Certificate2Collection currentCerts = certCollection.Find(X509FindType.FindByTimeValid, DateTime.Now, false);
                X509Certificate2Collection signingCert = currentCerts.Find(X509FindType.FindBySubjectDistinguishedName, certSubjectName, false);

                if (signingCert.Count == 0)
                    return null;

                return signingCert[0];
            }
            finally
            {
                store.Close();
            }
        }

コード内の「X509FindType.FindBySubjectDistinguishedName」は色々種類があるのだけれど、証明書内のどの項目で探すのかによって変更する。staticかどうかは、まぁ、好み。これによって得られたクライアント証明書をこの後の設定で利用する。

次に、VisualStudioのサービス参照追加でサービス用のProxy Classを作成した場合、以下のように証明書を添付する。

service.ClientCredentials.ClientCertificate.Certificate = cert;

「service」はProxy Classのインスタンス、「cert」は上記で取得したX509Certificate2。これにより、クライアント認証はOK。

で、通常のSSLで公開されているサービスであれば、証明書はちゃんとしたものであるので、サービス参照追加で作成が(多分)可能なんだけど、今回はテスト環境なのでオレオレ証明書。そうなるとサービス参照追加でSSL/TLSの確率ができねぇ!って言われて、ちゃんと作成できない。証明書を登録しても、SANを追加してもダメ。。。

なので、まずはサービスの実体を使ってProxy Classを作成する。その上で、app.configに追加されたEndpointをリバースプロキシのURLに変更。これにより、SSLの通信になって、且つ、クライアント認証もできるはず。。。と思ったら、出来なかった。。。。エラーとして、以下のようなものがでる。

System.ArgumentException: '指定された URI 形式 'https' は無効です。有効な URI は 'http' です。
パラメーター名:via'

で、諸々調べたら、app.configのBinding情報に以下の追加が必要だった。(これ調べるのに時間掛かった。。。orz)

<binding name="HogeSoap11Binding">
    <security mode="Transport">
        <message clientCredentialType="Certificate" algorithmSuite="Default"/>
        <transport clientCredentialType="Certificate" proxyCredentialType="Basic" />
    </security>
</binding>

追加する部分は<security>の部分だけど、この中身についてはSSLの実装内容によって変わるみたい。(未検証)で、この項目はコードからも追加できる。

var binding = (System.ServiceModel.BasicHttpBinding)SessionValues.users.ChannelFactory.Endpoint.Bindingbinding.Security.Mode = BasicHttpSecurityMode.Transport;
binding.Security.Message.ClientCredentialType = BasicHttpMessageCredentialType.Certificate;
binding.Security.Message.AlgorithmSuite = System.ServiceModel.Security.SecurityAlgorithmSuite.Default;
binding.Security.Transport.ClientCredentialType = HttpClientCredentialType.Certificate;
binding.Security.Transport.ProxyCredentialType = HttpProxyCredentialType.Basic;

これにより、SSLでの通信ができて、クライアント認証もできることになる。

さらに、HTTPとHTTPSを切り替える、というか、コード内でEndpointのURLを変更するには、下記のコードでできる。

Hoge.HogePortTypeClient("HogeHttpSoap11Endpoint", new EndpointAddress("https://hogehogte.com/~~~"));

これにより、任意のURLにEndpointを切り替えられる。

ふぅ〜久しぶりに長文を書いた。足りない部分もあるけれど、備忘録としては十分。ではでは〜。

VisualStudioのApp.configの自動切り替え

また書かなくなってしまう。。。いかん。。。

というわけで備忘録。

C#のプロジェクトにおいてClickOnceなり、そのままインストーラーで使うなり、App.configにそこそこの情報が記載されますが、これは大概DebugとReleaseのビルドで内容が変わるかと思います。

そんなときは、このExtensionが良い。というかWeb.configだとやってくれるのに、なんでデスクトップアプリだとやってくれないのだろう。。。orz

Configuration Transform

ただ、このページにある通りにした場合、VS2017だとエラーが起きてしまった。で、色々調べたら、Q&Aに記載があった下記方法で回避できた。

・該当のプロジェクトファイル(.csprj)をテキストエディタで開く
・<AppConfigWithTargetPath Remove=”app.config” /> の記載を <AppConfigWithTargetPath Remove=”@(AppConfigWithTargetPath)”/> に変更

これだけです。

で、肝心の切替は、上記ページに従い、Debug用とRelease用のConfigを生成して、変更する部分のみをそれぞれに記載するだけ。これで切り替えてくれる。ありがたい。

ではでは。

さて、ダイエット、、、、

せねばいけないなと、、、。

運動も必要だけど、食事の見直しが重要らしい。まぁ、当たり前か。。。なので、食事をできるだけアップしていこうかと。まずは、昼飯かな。見直すべきは。

とりあえず、昨日の朝と昼を。

んー、昼ご飯ご不健康だなぁ😅

中華なCNCのGRBLのバージョンアップ

まったく更新していないけど、備忘録で投稿。

結局、CNCは完成しました。(今度経過を書かないと。。。)

で、このCNCはArduino+CNCシールドなのだが、ArduinoでCNCを制御しようとするとGRBLというフリーのソフトを使うことになる。(いや、自分で実装すれば関係無いけど。。)このGRBLが古かったので、新しいバージョンにアップデートしました。。。そしたら、1方向にしか移動しないし、スピンドルの動きはおかしいし、ってな状況になってしまいました。。。

で、諸々調べて見たら、下記ページを見つけました。

https://github.com/zlakomanoff/grbl-cnc-2417

このページに従って、ピン設定を変更してみたところ、正常に動作するようになりました。。。

某掲示板では、「無駄なアップデートはしない」ってのが鉄則のようです。勉強になりました。しかし、、、ドライバーの不調かも、と疑って買ってしまったステッピングモータードライバー、、、どうしようw