blog.s.kbachaun.com

日本国憲法(試案)

 

ということで雑に作ってみた。適当に作っただけなので不具合などがあっても責任は負いかねます。

 

文字数を著しくオーバーしているので、追記部分に本文を記載することとなりました。ご了承ください。

続きを読む

• 2019/05/05 23:03
• コメント(0)

8月ハイライト

ずいぶんと遅くなりましたが8月ハイライトを公開します。

社会の動き

Windows 10 1607正式公開

Windows 10 Version 1607が正式公開された。様々な新機能があるが、主に以下の新機能について検証していた。

• Hyper-Vの仮想TPM機能が分離ユーザーモードに関係なく利用可能に
• CerdUIPromptForWindowsCerdentialsのUIが変更

 

犬山線の運転見合わせに伴い庄内通止の列車が登場

犬山線が運転見合わせとなり、その影響で犬山方面行きの列車を待つ乗客が増え、上小田井駅、および庄内緑地公園駅の両駅で降車が困難な状況となった。これにより、上小田井方面行きの列車が庄内通止となった。

 

個人的な動き

今月は特になかった感じがする。

 

• 2016/09/25 23:31
• コメント(0)

Windows 10でストアが起動しなくなったときに行うこと

Windows 10で突然ストア(Windows Store)が起動しなくなることがある。その際、以下の対処を行うことで再度ストアを利用できるようになる。

復旧手順

通常は以下の手順のうち、ストアの再インストールまでで復旧する。ただし、まれにストアの再インストールだけでは復旧しないこともある。その場合は、順次次の手順を実行していく必要がある。

ストアのキャッシュのクリア

まずは、ストアのキャッシュをクリアする。スタートメニューまたはスタート画面で"wsreset"と入力し、wsresetを実行する。

エラーメッセージ等が表示されなければ、そのままストアを起動する。エラーメッセージが表示される場合や、依然としてストアが起動しない場合は、次の手順へ進む。

ストアの再インストール

キャッシュクリア時に問題が発生する場合、ほとんどの場合は、ストアのインストール情報が壊れることによって問題が発生している。そのため、ストアを再インストールすれば問題は解決する。手順を以下に示す。

まず、スタートメニューまたはスタート画面で"PowerShell"と入力し、PowerShellを起動する。

次に、PowerShellで以下のコマンドを実行する。

Get-AppXPackage |Where-Object {$_.InstallLocation -like "*WindowsStore*"} | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"}

これでストアが再インストールされた。

ストアが起動できれば復旧はここで完了である。起動できない場合は次へ進む。

フレームワークの再インストール

まれに、フレームワークのインストール情報が壊れることによって、ストア等が起動できなくなることがある。その場合は、フレームワークを再インストールする必要がある。再インストールの手順を以下に示す。

まずは、ストアの再インストールを行ったコマンドプロンプト(PowerShell)で、以下のコマンドを実行する。

Get-AppXPackage |Where-Object {$_.IsFramework -eq $true} | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"}

処理にはしばらく時間がかかるが、完了するまで待機する。完了後、ストアを起動する。フレームワークのインストール情報が壊れただけの場合は、通常はこれで復旧する。これで復旧しない場合は、以下の手順を実行する。

スタート画面またはスタートメニューで"PowerShell"を検索し、PowerShellを右クリックして[管理者として実行]を行う。この際、右クリックしてもメニューが開かない場合は[アプリ]を選択した後でPowerShellを右クリック統すればメニューが表示される。

次に、以下のコマンドを実行する。

Get-AppXPackage -AllUsers |Where-Object {$_.IsFramework -eq $true} | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"}

同様に時間がかかるが、完了まで待機する。完了後、ストアを起動する。

この手順でも復旧しない場合は、次へ進む。

システムアプリの再インストール

システムアプリが破損することによってストアが利用できなくなることもある。その場合は、以下の手順で復旧させる。

管理者権限のPowerShell([フレームワークの再インストール]の後半で利用したもの)で、以下のコマンドを実行する。

Get-AppXPackage -AllUsers  |Where-Object {$_.InstallLocation -like "*SystemApps*"} | Foreach  {Add-AppxPackage -DisableDevelopmentMode -Register  "$($_.InstallLocation)\AppXManifest.xml"} 

処理にしばらく時間がかかるが、待機する。完了したら、ストアを実行してみる。

これで復旧しない場合は、システムファイルが壊れている可能性があるため、次へ進む。

システムファイルの修復

管理者権限で以下のコマンドを実行する(フレームワークの再インストールの後半で利用したコマンド画面でも実行可能)。

dism /online /cleanup-image /restorehealth

sfc /scannow

上記コマンドを実行することで、システムファイルの破損が確認され、修復される。この処理が完了するまで環境にもよるが数時間かかることもある。

完了後、再度ストアを実行する。実行できない場合は、再インストールの手順をもう1度実行し、確認してみる。

万が一、システムファイルが修復できない、あるいは修復後もストアが利用できない場合は、Windowsの再インストールが必要となる。

参考文献

Windows 10 のスタート メニュー、Microsoft Edge 、設定、通知などが応答しない場合の対処法 (http://answers.microsoft.com/ja-jp/windows/wiki/windows_10-update/windows-10/5a606106-5820-4a86-a31e-b94d91364e10)

 

• 2016/04/09 09:14
• コメント(3)

イオン新瑞橋のお支払いセルフレジの動作

2016年3月24日から、イオン新瑞橋店でお支払いセルフレジが稼働開始した。その動作について簡単にまとめる。

設置状況

イオン新瑞橋で導入されたとき、当初従来型の有人レジだったレーンの大半がお支払いセルフレジに変更された。従来型の有人レジは2レーンのみ残っている。従来より設置されていたフルセルフレジ(10レーン)はそのまま残っている。なお、従来の有人レジは15レーン程度あったと記憶している。

なお、お支払いセルフレジは、スキャン端末1台につき支払い端末2台の構成となっており、スキャン端末から支払い端末へデータ送信する仕様となっている。

客層等を考慮した結果、大半をお支払いセルフレジに移行したとしても支障がないと判断したためこのような大胆な変更が可能であったと推測される。

動作の概要

お支払いセルフレジでは、通常期(感謝デー等カード提示のみで受けられる会員割引がない場合)は以下の流れで精算する。

1. 店員が商品を登録し、支払い端末へデータ送信する
2. データを送信された支払い端末(店員から案内がある)へ移動する。
3. オーナーズカードの有無が確認されるので、画面に沿って回答する
4. オーナーズカードを持っている場合は画面の案内に沿ってカードを入れる
5. 支払い方法を選択する。ここでは[現金]・[クレジット]・[WAON]・[その他電子マネー]から選択可能となっている。[その他電子マネー]を選択すれば交通系IC、iD、QUICPayの支払いも可能となっている。イオンギフトカードについてはどのように操作するかは不明(フルセルフでは専用のボタンがあったが、支払い端末ではボタンがなかったようにも記憶している。見落としているだけかもしれないが)。
6. 支払い操作を行う。
7. レシートを受け取り、清算完了となる。

感謝デーの動作は未確認であるが、おそらく最初のオーナーズカードの有無の確認画面が割引対象カードの有無の確認画面になると考えられる。また、WAONやイオンカードiDでの割引を指定した場合は支払い方法が固定となるため自動的に支払処理へ移ると考えられる。20160402追記:3月の感謝デーにおいては通常機と同じ動作となっていた。近日中に改善を示唆する発言があったため今後改修されると考えられる。20160409追記:3月の感謝デー時は感謝デー割引はイオンカード等の提示の場合は目視確認で適用(感謝デーボタンを使用)させていた。WAONについては自動適用なので一般レジと同じ扱いとなっている。イオンカードiDは未確認だがおそらくWAONと同様と考えられる。

なお、スキャン端末にはICカードR/Wおよび磁気カードR/Wは搭載されていないため、カードの読み取りが必要なオーナーズ特典や感謝デー特典等はすべて支払い端末での処理となる。おそらく旧ダイエー店舗(イオンリテールストア店舗)にお支払いセルフレジが挿入された際は、ハートポイントカードも同様の対応となると考えられる。

このようなときはどうするか

電子マネーの残高不足の場合

WAONの残高不足の場合は、残高不足画面で不足分を現金で支払うか、全額をほかの方法で支払うか、あるいはその場でチャージして支払うかを選択できる。お支払いセルフレジの支払い端末においては、残高不足の場合にその場でチャージができるようになっている。なお、チャージ額は1000円から10000円まで、1000円単位で指定できる。

チャージを指定した場合は、チャージ後レシートが発行され、そのまま支払処理へ移行する。

WAON以外の残高不足の場合にチャージができるかは未確認である。

各種商品券やギフト券(紙タイプ)を利用する場合

係員対応となる。スキャン端末での登録は行わず、支払い端末のアシストモードで係員が商品券等の登録を行う仕組みとなっている。各種クーポン券の取り扱いも同様である。20160402追記:クーポン券はスキャン端末で登録する運用に切り替わっている。

仕組み上はスキャン端末での登録が可能であり、スキャン端末で登録する運用の店舗も存在するが、イオン新瑞橋においては支払い関係はすべて支払い端末での処理となっている。

 

• 2016/03/26 09:54
• コメント(0)

道路標識における休日の解釈について

一部の道路標識に、以下のような表記がある。

土曜・日曜・休日を除く

日曜・休日を除く

ここで、土曜・日曜は見た通りカレンダー上の曜日であり、対象とする日付は明確である(曜日については疑問が生じる部分もあるが、これは別途考察する)。

しかし、休日について、日本国においては休日に関する法律や規定が複数あり、また、事業者等によっても休日が異なるため、明確に決定できない部分がある。休日はどこで定められているのかについて記載していく。

• 2015/12/30 16:09
• コメント(2)

コンビニ自販機で電子マネーが使えない理由

近年、コンビニ自販機と呼ばれる、コンビニのブランドを付した自動販売機が増えてきている。また、それ以外であっても、パンや菓子などを販売する自販機が室内を中心に多くある。

しかし、これらの自販機で、電子マネーに対応している機種は皆無である。なぜ電子マネーに対応しないのか。単に事業者側の都合なのか、あるいは構造上対応できないのか。これらについてみていく。

コンビニ自販機の販売方法

まず、コンビニ自販機はどのように販売しているのかについてみていく。

多くのコンビニ自販機は、前面がガラスになっており、販売商品が外から見えるようになっている。販売商品は、スパイラル状の金具に挟まれているか、またはベルトの上に乗せられている。これにより、利用者は購入する商品の現物を確認することができる。また、売り切れの際は商品自体が存在しなくなる。

購入方法だが、まず、利用者は商品を選ぶ。次に、お金を入れる。この時、まれにお金が入らない場合があるが、その際に販売中ランプが消えていれば自販機は利用できない。お金を入れた後、商品に付けられている番号を自販機のテンキーで入力する。入力後に、購入ボタンを押せば、自販機が商品を搬出する動作を行う。この動作は利用者も確認することができる。搬出が完了した後、商品とおつりを取り出す。なお、まれに商品を選んでも搬出動作を行わない場合がある。この時は、投入金が不足しているか、または商品が販売できない状態(賞味期限切れや、売り切れなど)となっている。お金が足りないようであれば追加し、足りているのに購入できない場合はほかの商品を選ぶか、キャンセルする。

このように、利用方法自体は一般の飲料自販機と変わらないが、商品の選び方が通常の自販機とは異なる。また、目視で売り切れかどうかは判別できるが、機械がそれを認識しているかは購入してみるまでわからないといった点も異なる(一般の飲料自販機は、売り切れであれば[売り切れ]ランプが商品ボタンに点灯(通常は常時点灯だが、まれにお金を入れるまで点灯しない自販機もある。これについての詳細は略)するため、機械が売り切れであると認識しているかは容易にわかる)。

商品が出ない場合はどうなるか

一般の飲料自販機は、信頼性が高い仕組みを使っているため、商品が出ないなどの販売トラブルは非常に少ない。筆者においても、過去に1度大量の商品が出たところを目撃したことがある以外、商品が出ないなどといったトラブルを目撃したことはない(コインづまりや紙幣づまりなどは何回が経験しているが)。しかし、コンビニ自販機は、その構造上商品が出ないトラブルが一般の飲料自販機に比べて発生しやすい。これは、形状がおおむね一定である飲料に比べて、コンビニ自販機で扱う商品は形状が一定ではない(袋状の商品もある)という点がある。また、搬出機構の違いもトラブルが起きやすい要因である(詳細についてはここでは略)。

また、コンビニ自販機においては、誤って売り切れの商品を選択(先述のように、売り切れかは目視で確認はできるが、機械が認識していない場合に誤って選択した場合は売り切れであってもそのまま販売動作をしてしまう)してしまうなど、人為的な販売トラブルも起こりうる。

これらの販売トラブルが起こった際、商品代金が課金されてしまうと、利用者は損失を被る。また、場合によっては利用者が自販機の設置事業者(自販機オペレータや、自販機が設置されている施設の受付など)に返金を要求することもある。返金が要求された場合は、自販機の設置事業者は返金を行うため自販機の設置場所に出向いて自販機の状態を確認し、利用者へ返金する。場合によっては状況の確認に向かうまでの間自販機を利用できないように利用者などに対して"中止"などの張り紙を貼るよう要求することもある。このように、1度販売トラブルが起こり利用者に損失が出るような事態になると、自販機事業者は多大な負担がかかることが想定される。

そのため、最近のコンビニ自販機においては、商品が正しく搬出されたかをセンサーで識別し、万が一正しく搬出されていないこと(商品が出てきたことが認識されないなど)が確認された場合は、商品代金を課金しない(返金する)などの対応が行われる。また、該当カラムに対して、補充(前面扉の開閉などで補充と認識されることが多い)が行われるまでの間、販売を停止するといった処置が行われることもある。これにより、自販機業者は返金対応に追われることなく、本来の業務(補充など)に専念することができる。

電子マネーでの自販機の利用方法

ここで、電子マネー(ICカード形の電子マネー)で自販機の商品を購入する場合についてみてみる。

現金で購入する場合は、先述したように、先に現金を投入してから、商品を選択する。これは、ほとんどの自販機において共通する事項である。

対して、電子マネーで購入する場合は、先に商品を選択してから、電子マネーを読み取らせる。これは、課金額が商品を選択するまで決定できないこと、および課金額を動的に変更するのが困難である(電子マネーを読み取らせた段階で電子マネー内の残高を書き換える必要があるため。多くの場合残高等は電子マネーの媒体内にも記録されているので、動的に変更するには電子マネー媒体を変更が生じる可能性のある間常時読み書き可能な状態にする必要がある)ことが理由である。また、電子マネーからの引き落としは、電子マネーを読み取らせたときに行われる。なお、電子マネーを先に読み取らせると残高が表示されるが、その後に商品を選択しても再度電子マネーを読み取らせない限り購入はできない。

このように、現金は返却が容易であることなどから、先に投入させる(これによりお金が足りているかの確認もできる)が、電子マネーの場合は先述の通り動的な変更が困難なので後で読み取らせる(残高の確認と課金を同時に行う)ことになっている。

なぜ、電子マネーが使えないのか

コンビニ自販機で電子マネーが使用できないのはなぜか。この答えは、先述した課金方式にある。

コンビニ自販機の場合、投入金が足りていることを確認して、販売動作を行う。その後、商品が出たことを確認してから課金を行う。これは、先述したように商品が出ないというトラブル回避のために行っているものである。

では、電子マネーで同様の販売動作はできるのか。先述のように、大半の電子マネーは、ユーザーがIC読み取り機にタッチし、ICカード内に書きこまれている残高を減らすことによって課金を行っている。ここで、上記のようなコンビニ自販機の販売動作を行う場合、商品を選択してから商品が出る、あるいは商品詰まりや空売りなどを検知して売り切れ動作を行うまでの間、電子マネーの媒体との通信を継続していなければならない。もし、商品が出る前に電子マネーとの通信が何らかの理由で途絶えてしまった場合、商品は落ちてきたにもかかわらず課金はされないといった状態になってしまう。

逆に、商品を選んだ時点で課金した場合、その後商品が出てこないなどの事態になると返金をする必要がある。この時、電子マネーの仕様によっては無駄な履歴が残る場合や、そもそも現金でしか返金できない場合がある。後者の場合、意図的に売り切れカラムを購入することで電子マネー残高を現金化できるといった問題にもなりうる。

以上のことから、コンビニ自販機における、商品が出てこなかった際の返金処理に難点があるため、電子マネーの導入が進まないといった現状がある。もし、問題点を克服(売り切れ時に返金できる、あるいは絶対に商品が詰まらないようにし、売り切れも選択前に検知できるようにするか、あるいは販売動作後に購入キャンセルをした際、商品を元の位置に戻して販売が再度できるようになる)できるようになれば、電子マネーの導入が進むと考えられる。

追伸

8か月近くもの間下書き状態(これを描いている時点でのタイムスタンプが2013/10/10 08:49となっている)だった記事をようやく公開にしました。もともとはとあるコンビニ自販機の登場を受けて書き始めた記事ですが、その自販機はなぜかコンビニの名前を外していたりします。ちなみに、アイスクリーム自販機や一部の飲料自販機など、コンビニ自販機(パンや菓子などを販売する自販機)以外でもこれと同じような販売機構となっているものもあります。

 

 

 

 

 

• 2014/06/06 22:48
• コメント(0)

名古屋市からのエリアメールでnullが表示された問題

インターネット上に掲載されたニュース記事によると、担当者は件名と本文の情報をきちんと入力して送信したとしている。しかし、実際にはnull nullに置き換わって送信されている。なぜnullが複数あるのか、なぜnullになったのか。

そもそもnullが2つある理由

おそらく、件名と本文にパートが分かれていて、それが両方ともnullとなっていたと考えられる。実際のメールではすべて本文であるように見えるが、実際は1行目は件名として機能している。

また、末尾の'(名古屋市)'の表示はnullに置き換わっていないが、これはキャリア側で付与される文面であるため、配信システムの影響を受けない。そのため、nullに置き換わらないと考えられる。

 

なぜnullになったか

おそらくエリアメール(緊急速報メール)は以下の仕組みになっていると考えられる。

[発信用端末]-[各キャリアへのゲートウェイ]-[各キャリアのサーバー]-[各キャリアの基地局・制御装置])[端末]

ここで、発信用端末・各キャリアへのゲートウェイは、名古屋市(あるいは市の委託を受けた業者)の管理で、それ以降のサーバー等は各キャリアごとに管理(キャリアごとに準備)されているものとする。

今回のnull騒動は、特定キャリアのみで発生したわけではなく、すべてのキャリア(docomo,au,Softbank)で発生している問題である(Twiiterなどの画像を参考)。また、調べた限りにおいては、配信システムは各キャリアごとに用意されている。つまり、各キャリアで発生した問題ではないと考えるのが自然である。

次に、件名や本文が空白の状態で送信した場合についてを考える。本来は、本文などが空白で送信しようとした場合、送信前のチェック処理でエラーとして認識し、送信処理は実行されないようにするのが自然である。このようなチェックはコードにしてわずか1-3行程度で実現できる。すなわち、件名や本文を入力せずに送信できる仕様になっている仕様は考えづらく、仮にそのような仕様の場合はシステムに問題があると結論付けるべきであると考えられる。

また、仮に空白で送信できたとしても、それがnullに置き換わる理由が見当たらない。空白であっても文字列として認識できれば、nullとはならずに空白として送信されるはずである。ただし、この点については暗黙の型変換や、送信フォーマットなどの仕様(空文字列とnullが区別できないフォーマットなど)もあるので、一概には言えない。

担当者が意図的に'null'を送信した可能性もあるが、先述の記事では2つの情報をきちんと手で入力して送信したとしている。また、その後の訂正においても'配信エラー'と記してある。したがって、そのような可能性は非常に低い。仮に、これが原因であった場合、担当者は不正な電文を送信したとして、懲戒処分を受けることになり、またその旨が公になると考えられる。

つまり、件名や本文に誤った内容が入力されたとは考えづらく、原因はゲートウェイのサーバー、あるいは発信用端末とゲートウェイとの間の通信路、あるいは端末のソフトウェアの障害であると考えられる。例えば、端末からゲートウェイに電文を送信する際、件名と本文のデータが完全に欠落した(欠落の原因はここでは問わないが、例えばソフトウェアの問題や、通信路の問題などが考えられる)と考える。その場合、ゲートウェイは件名と本文のデータがないことから、データがない=nullと解釈し、各キャリアへ'null'と文字列に変換した電文を送信したと考えることができる。また、ゲートウェイの問題であった場合、例えばデータを処理する段階で何らかの不具合があり、結果としてnullが送出されてしまったとも考えられる。件名は選択式で、本文は件名の選択によって手入力の場合と定型フォーマットがある仕様の場合、件名の選択が定義されていない値となったため、件名がnullとなり、本文についても動作が定義されていないことから値が設定されず、結果的にnullとなったと考えることもできる。しかし、件名が未定義であることにより発生した問題の場合、通常は端末、あるいはゲートウェイサーバー側でチェックされ、送信処理を行わずにエラーとすると考えられることから、データの欠落の問題である、あるいはデータの欠落の問題と件名が未定義であることにより発生した問題が合わさった(件名が未定義値だが、異常な範囲ではないのでチェックを通してしまった)と考えるのが自然である。

ここで、なぜnullのチェックを抜けてしまったのかの疑問がある。この疑問への回答は非常に容易である。単純に''(空文字列)とは比較していたが、null値との比較はされていなかった点(多くの場合、''==nullはfalseとなる)、および、文字列に変換する処理で'null'とされてしまったことにより、キャリア側でのチェックもすり抜けてしまった(多くの場合キャリア側でも本文が空白かのチェックがあると考えられるが、このチェックは空白文字などであった場合にのみ機能し、何らかの文字列が入っている場合は(たとえ'null'であっても)チェックは通ってしまう)と考えることができる。あるいは、文字列に変換した後に空白チェックを行う仕様だった(この場合、文字列に変換した時点で'null'となるため、'null'==''はfalseとなり、またempty('null')などnull値も確認できる空白チェック法であってもfalseとなる)と考えることもできる。つまり、いずれの場合もシステムに欠陥があったため、最後のチェックもすり抜けてしまい、nullとだけ記されたエリアメールが送信されてしまったと考えることができる。

では、なぜ処理の時点で電文がnullとなってしまったのか、また、なぜこのメールだけnullが送出されてしまったのか。この問題のヒントとなるのが、朝日新聞の記事(http://www.asahi.com/national/update/0905/NGY201309050003.html)に記載されている、"約２０分後に別のパソコンで送信すると、本来の内容で配信された。"の文面である。このことから、nullが送出されたときに使用していたPC(あるいはそのPCとゲートウェイ間の伝送路)に障害があるか、あるいは、nullが送出されたときに限り、伝送路もしくはゲートウェイに障害が発生したかのいずれかであると考えられる。ここで、今回のnull送出の前に送信された緊急速報メールは正常に送信されていることから、もし、PC(あるいはそのPCに搭載されたソフトウェア)に障害があった場合、そのPCは今回のnull送出の前には使用しておらず、今回のnull送出時に初めて使用した(あるいはnull送出時に初めて不具合が発生する条件(例えば、市内全域を指定した場合に限り不具合が発生するなど)を満たした)と考えないとPCの障害は想定しづらい。そのことから、nullが送出されたときに限りゲートウェイ等に障害が発生したか、あるいはnullを送出するときに障害発生条件を満たしてしまったかのいずれかであると考えられえる。

いずれにせよ、送出システムに問題があることは明らかなので、今後はこのような事態のないよう、早急にシステムの修正を行ってほしい。

参考まで、docomoのエリアメール送信ツールはWebインターフェースを利用しているようだ(参考: http://t.co/Pr3IzNF7 )。しかし、各キャリアに同時に配信する必要があることから、現在は専用のツールを使用している可能性が高い。

参考文献

緊急速報「エリアメール」で誤表示　名古屋市

http://www.chunichi.co.jp/s/article/2013090490225832.html

名古屋市、豪雨情報メール誤配信　意味不明の文面

http://www.asahi.com/national/update/0905/NGY201309050003.html

 

• 2013/09/05 12:31
• コメント(0)

ソーシャルネットワークの正しい使い方

最近、ソーシャルネットワーキングサービス(SNS)が普及している。SNSは、正しく使えば非常に便利なものであるが、間違った使い方をしてしまうと、社会から悪評価を受けるなど、重大な不利益を被る。ここでは、SNSで問題となる事例を見ながら、正しい使い方についてみていく。

この記事を読むにあたっての注意事項

この記事では、SNSの使い方について解説しているが、ここに書いてあることがすべてではないといった点に注意する必要がある。ここに書いていないことであっても、問題となる事例は多数ある。また、ここに書いてあることであっても、実際にはそれほど問題とならない場合もある。ここに書いてあることは、あくまでも参考程度にしてほしい。

この投稿の続きは現在表示できません。詳細は、個別ページでお確かめください。

詳細を表示

• 2013/06/16 21:51
• コメント(0)

前文機能の追加

このBlogに、前文機能を追加した。といっても、管理者以外にはあまり意味がない記事だが。

機能としては、一定箇所までは、すべてのユーザーが閲覧できるようにし、それ以降の部分はログインユーザーや特定ユーザーのみ閲覧できるようにするという機能である。

この機能を使用すれば、冒頭部分は無料で閲覧できるが、それ以降は有料プランに加入しないと閲覧できないといったことも可能となる。

この投稿の続きは現在表示できません。詳細は、個別ページでお確かめください。

詳細を表示

• 2013/06/15 17:56
• お知らせ
• コメント(0)

今後のblog.s.kbachaun.comの方針について

2013年1月ごろに、以下の宣言をしたのを覚えている方も多いと思います。

このBlogは最低月1回は更新する。もちろん、それ以上の更新も可能な限り行う。

しかし、残念ながら、現時点において、この宣言が守られていません。理由は、以下の通りです。

• 多忙によるもの。
• ここに書く内容がないことによるもの。

残念ながら、この2つの状況が改善されることは、今後もおそらくないと考えられます。特に2番目は深刻な問題で、一般への公開ができない内容(公開すると問題となる情報(例としては、秘密保持契約またはそれに準ずる情報とともに提示されたものなど)が含まれる内容など)が数多く存在する、一応ノージャンルで作成したが、結局ジャンルにとらわれてしまっている(過去ログを見ればわかるが、なぜかWindows 8系が多い)などがあります。後者の問題は作者自身の問題でもあることは認識しておりますが、前者の問題については、こちらではどうしようもない部分もあると思います。

つきましては、今後の更新は、当面不定期とさせてください。また、今後は登録ユーザー限定の記事が増えることが予想されます。当サイトにアカウントを保有していないユーザーは、お早目にアカウントを作成することをお勧めします。メールアドレスも不要で、2分以内に作成が完了します。

• 2013/06/10 22:04
• お知らせ
• コメント(0)