今日は、Windowsのレンタルサーバ探しの備忘録です。

Windowsのレンタルサーバは運営している会社が少なくて、選択肢が少ないです。
現在仕事はもっぱら Windows azure を利用していますが、ホームページは以前に作ったホームページをそのまま使いたいし、メールも使いたいし、Wordpressも使いたいし、写真とかのコンテンツも起きないなどの要件もあって、windows azure では高くついてしまうのでパスしようかと。

そこで、サクッとググるとwindows azure 以外に3つの会社が出てきました。

■1stレンタルサーバー　「WINDOWS共用レンタルサーバー」
■WILL@NET　「共用サーバー」
■ウィンサーバー　「共用サーバー」
※後は海外のサーバを利用するという手も有りますが、ちょっと敷居が高そうなので今回はパスしようと思っています。

Windowsレンタルサーバーへの要件は、以下が使えることです。
１）ASP.NET
２）SQL Server
３）マルチドメイン
４）サブドメイン
５）共有SSLもしくはそれに代わるもの

後は、Wordpressも使えたらなお良いってところでしょうか。
Wordpressに関しては、すぐに重たくなるようなら別途他で安いLinuxベースのサーバを借りようと思ってます。

で。まとめてみると。（※2016/12/15日現在）

値段相応な気がします。
1stレンタルサーバーのドメイン数が少ないのと料金が高いのがネックですが、1stレンタルサーバーが一番妥当な気がします。
尚、使い勝手等は調べていません。例えば、「独自ドメインSSL証明書が無料」となっていますが、本当に無料なのか？簡単に設定できるのか？など。
使ってみて初めて分かることも多いので。
1stレンタルサーバーのお試しプランの申し込みですが、失敗した雰囲気のメッセ－ジが表示されましたが、登録できていたようです。この手の申し込みは慣れているのでが、判りづらかったです。

追記（2016/12/19）
1stレンタルサーバーを利用していて、突然ログインができなくなり、運営に連絡すると変更したパスワードが初期化されて、「これで入れなかったら連絡ください」と返信が・・・
次に、MSSQLのデータベースを作ったときに、myLittleAdminでログインしようとして、アドレスが解決できずにエラーになりログインできず。運営にサーバのアドレスを照会するとDNS管理を外部で行っている場合は、サポート対象外ですと2日後に連絡あり。
FAQには「弊社サーバーへ接続するには、DNSサーバーへの登録作業が必要となりますが、
ドメイン名の管理は他社となるため、お客様自身にて弊社指定DNSサーバーへ変更作業を
行っていただく必要がございます。」と有るだけで、サーバのアドレスを教えて貰えないとは思って居なかったため、作業中断状態。
次に、MySQLのデータベースを作ったときにphpAdminでパーミッションエラーでログインできず、運営に連絡すると、いつの間にかできるようになっていた。

DNSについては手間は掛かるけれど設定で済む問題なので、「まぁ、良いか」とも思ったけれど、1stレンタルサーバーの評判で見た通り、サポートが雑なので不安になります。
数日間移行を進めて来ましたが、WILL@NETに変更しようかと。
WILL@NETのネックはDBの容量が安いコースだと100Mしかないことです。
まぁ、本格運用には使わないので大丈夫だとは思うんだけどね～。

追記（2016/12/28）
WILL@NETに変更しようかと思いましたが、今度は独自SSLを行いたい場合、費用が掛かってしまいます。悩ましい。。。
最近は、Let’s Encrypt (レッツ・エンクリプト)という証明書が使え、無料で入手可能です。
Let’s Encryptに関してはまた別の機会に備忘録しますが、私は自分が使っているDNSの管理会社から「※Let’s Encrypt SSL証明書は90日ごとに更新が必要となります。」という制約付きですが、簡単に入手できます。
尚、Let’s Encryptのルート証明書はIdenTrustのものが用いられており、幅広いプラットフォームに対応していますが、ガラケーなど一部の端末は対応していないのでその点だけ注意です。

で、WILL@NETにするかどうかも有るのですが、以前から興味は有ったものの、敷居が高かった海外サーバの調査をしてみようと思います。
全部英語だし、問い合わせも英語っていうところが非常に心配ですが、とりあえず使い勝手と応答性のチェックを実施します。もし、良かったらそのまま契約するかも。

それから、windows azure との正確な比較等も行っていませんが、windows azure で独自ドメインを使用しようとすると貧弱なCPUパワーの割に料金が安いわけでもないので、やはり比較するに当たらないと思っています。
業務で利用するるならwindows azure でしょうが、今回は単なるホームページなので、格安にすませることにしました。

とりあえず、Windows レンタルサーバ探しの備忘録でした。

jQueryとは

jQueryとは、メジャーなJavaScriptライブラリです。
JavaScriptはWebブラウザ上でいろいろなことが処理できるプログラミング言語ですが、JavaScriptを使って１からプログラムを書くと面倒なこととか専門家でないと難しいところを、jQueryがライブラリを提供してくれて比較的簡単にしてくれます。
なお、jQuery自身もJavaScriptで記述されています。

jQueryのJavaScriptを簡単に扱えるようにしてくれる特徴とは

◆複雑な処理をシンプルに記述できるようにしている
JavaScriptはWebブラウザ上で処理を行いますが、ご存知の通りWebブラウザにはいくつもの種類があり、各々でできたりできなかったりして、同じ処理をするにしてもWebブラウザに合わせてカスタマイズする必要がある場合もでき、複雑で面倒なことが起きます。
jQueryではその複雑で面倒な部分をライブラリ内で吸収しているので、異なるWebブラウザでも同じメソッドを使うことで同じような処理を行ってくれます。

◆CSSセレクタを使うことができる
CSSはWebブラウザに画面表示をどのようにするかを指示するための言語です。
CSSセレクタはHTMLの要素を複数選択し、処理を指示することができます。
CSSセレクタは、本来はJavaScriptとは異なるものですから、使用できなかった（し辛かった）のですが、jQueryではCSSセレクタを簡単に選択し操作できるようにしました。そしてCSSと同じように複数選択できるようになり、同じように短い記述でまとめて処理が書けるようになりました。

その他、jQueryの利用者が多いことからネットで検索すれば情報がたくさん出てきますし、プラグインも簡単に手に入ります。開発環境もVisual Studioでサポートされていたり、Webブラウザ上のデバッグもできたりします。

また、日々jQuery自身の更新もされており、jQuery自身がより良いものになっていっています。

ASP.NET VB GridViewのヘッダーに行を追加する際に新たなことが分かったので、追加でシステム開発備忘録します。

以前にASP.NET VB GridViewのヘッダーに行を追加するという記事をシステム開発備忘録しました。
その際に、PostBackでおかしくなる旨の記述もしていたのですが、今回の修正で治るかもしれません。

前回の追加コーディングは。以下の通りです。

Private Sub GridView1_RowDataBound(sender As Object, e As GridViewRowEventArgs) Handles GridView1.RowDataBound
 
If e.Row.RowType = DataControlRowType.Header Then
  Dim row As GridViewRow = New GridViewRow(-1, -1, DataControlRowType.Header, DataControlRowState.Normal)
  For i As Integer = 0 To 11
    Dim cell1 As TableCell = New TableCell()
    cell1.Text = i.tostring + "月"
    row.Cells.Add(cell1)
  Next
  row.RowType = DataControlRowType.Header
  Me.GridView1.Controls(0).Controls.AddAt(1, row)
endif

今回、GridViewにtheadタグ、tbodyタグを追加したいと思い以下のコーディングを追加しました。

Private Sub GridView1_RowCreated(sender As Object, e As GridViewRowEventArgs) Handles GridView1.RowCreated

  Select Case (e.Row.RowType)
    Case DataControlRowType.Header
      e.Row.TableSection = TableRowSection.TableHeader  'theadを出力
    Case DataControlRowType.DataRow
      e.Row.TableSection = TableRowSection.TableBody    'tbodyを出力
    Case DataControlRowType.Footer
      e.Row.TableSection = TableRowSection.TableFooter  'tfootを出力
  End Select
End Sub

このコーディングを追加した結果、上で追加したレコードはTheadに入らずに、Tbodyに入っていました。
環境が異なるので今回は検証をしていませんので、あくまでも推測ですが、先回のPostBack時の不具合はこのことが原因と考えられます。
適切にthead部に入ってヘッダー行と認識されて居れば、PostBack時の処理で通常のレコードと見なされることは無いのではないかと思います。

そこで今回の結果を踏まえ、もう少し突っ込んで調べた結果、
TableSection
なるプロパティが有ることがわかりました。
TableSectionプロパティは、Table コントロールに配置されている TableRow オブジェクトの場所を取得または設定するのに使用されます。
使用できるテーブルの位置については、以下の通りです。

TableSectionプロパティを設定する箇所は適当で良いと思いますが、私は直線に入れました。

row.TableSection = System.Web.UI.WebControls.TableRowSection.TableHeader
Me.GridView1.Controls(0).Controls.AddAt(1, row)

TableSection プロパティをTableHeaderに設定してヘッダーレコードを追加すると、正常にthead部に入ってくれました。

以上、ASP.NET VB GridViewのヘッダーに行を追加する（修正版）のシステム開発備忘録でした。

javascriptやjqueryを利用して、テーブルのヘッダーを固定させる時に、少し嵌ったのでシステム開発備忘録として残しておきます。

経緯はGrid_Viewのヘッダーを固定するプログラムをjqueryで書きました。
Grid_Viewのヘッダーは段組みがされて居て、その中にtableを使用している少し複雑なヘッダーでした。

丸っとコピーして使用しようとしたのですが、どうしてもズレてしまいます。
Grid_Viewのヘッダーをコピーを幾度か繰り返すプログラムを書いたところ、1回目と2回目でthのwidthに差が出ていることがわかりました。

これが何を意味するのか、良く分かりません。
一通り読込んだ後で、何らかの調整が入り差が出ているのかなぁ？程度で。。。
$(document).readyイベントでプログラムを書いていますので、DOMツリーの構築が終わった時点で実行されます。
DOMツリーの構築とは、ページ内容の解析とレンダリングが終わったと言うことらしいです。
では、レンダリングとは。。。

まずは、読み込んだHTMLを解析してDOMツリーを生成します。
構築と生成の違いも今一つわりませんが。。。要素を作ったと思って良いのかな？

次に、読み込んだCSSを解析してCSSの構造体を生成します。

更に、DOMツリーとCSSの構造体から画面表示に必要なレンダーツリー（Render Tree）を構築します。

その後、レンダーツリーが持つ各DOM要素の位置を決定します。レイアウトって言って良いのかな？

最後に、レイアウトに基づいて描画されます。

先ほど、$(document).readyイベントは「DOMツリーの構築が終わった時点で実行されます」と呪文のような言葉を知ってるだけで、DOMツリーの構築を良く知りません。
ググってみると次のようなことが書いてあるページも。。。『そこで利用するのがreadyイベントです。ポイントはページ全体（画像などを含む）の読込ではなく、ページ構成（DOM要素）を読み込んだ時点で処理するため、ページを表示する前に様々な準備ができる点です。』
と言うことは、DOMツリーの構築は『ページを表示する前に様々な準備ができる点』と有るように、レイアウトを行う前までのような。。。

だとすると、GridViewはtable-layoutをautoにしているため、読込み後に調整が入ったんだろうと思って居ましたがそれで良いのかも。
ただ実際のブラウザがどのように調整をしているかを知らないため、良く分からないのですが、、、

で、差が出るのを読込み後に調整が入ったんだろうと思いつつ、なぜズレるかわからないまま、調整をしながらデバッグしていたところ、Grid_Viewのcellpaddingが‐1に設定されているを発見しました。
実際、このGridViewのcellpaddingを0にしたところ、差がかなりなくなりました。
若干の誤差は出ているものの、妥協できる程度の差でした。

javascriptやjqueryを利用して、GridViewのヘッダーを固定させる時は、コピー先のテーブルとGridViewのcellpaddingが合致しているかをチェックしてみる価値は有るような気がします。
cellpaddingを‐1にすると、cellpaddingが追加されず、cellpaddingを0にするとcellpadding=0がテーブルタグに追加されます。

以上、javascriptやjqueryを利用して、テーブルのヘッダーを固定させる時に、少し嵌ったシステム開発備忘録でした。