SphinxでWord(docx)文書を出力してみた
自分はあまり、Office製品が好きではありません。
(Office365契約しているけど。。。)
便利なのですよ。便利なのだけど、お節介が過ぎるところがあるので。MSのOffice製品は。
そこで今回は依然から気になっていたSphinxを使ってみることにしました。
特に、Sphinxからdocxを吐き出せないかと試していたのですが、はまりポイントがあったのでご紹介。
環境は以下の通り。
・Python 2.7 (32bit)
・Sphinx 1.3.5
・sphinx-docxbuilder(コミット 83a8d13 2012-06-05)
haraisao / sphinx-docxbuilder — Bitbucket
Sphinxでdocxを出力する際に利用するモジュールは、
「sphinx-docxbuilder」というものを利用しているのですが、
見ての通り、更新日が4年前になります。
自分の環境では、コンパイル中にエラーが出力されました。
tree = inline_all_toctrees(self, set(), master, tree, darkgreen) TypeError: inline_all_toctrees() takes exactly 6 arguments (5 given)
明らかに関数の型がおかしいとのことで、
ちょっと調べてみると、Sphinxが提供している
「inline_all_toctrees」関数の型が変更されているのが原因に見えます。
取り急ぎ、下記のように変更すればコンパイルは通ります。
sphinx-docbuilder/builder.py 60行目
・Before
tree = inline_all_toctrees(self, set(), master, tree, darkgreen)
・After
tree = inline_all_toctrees(self, set(), master, tree, darkgreen, [])
参考:
futurismo.biz
【Office365】Office365を試す(ディレクトリ同期で同期される属性値)
最近、Office365を契約してみました。
というのも下記のアドベンドカレンダーの様々な記事を見ることで興味が湧いたこと、
個人でもビジネスプランを契約できるということで試して見ようと思い。
Office365を普通に利用するだけなら契約するだけで終わりですが、
エンジニアとしてはただ利用するだけでは楽しくありません。
せっかくビジネスプランを個人でも契約できるので、
エンタープライズ向けの機能も試してみたくなります。
ということで、ローカルADとのディレクトリ同期です。
ADとOffice365のディレクトリ同期ですが、
様々なサイト・blogで構築手順等も紹介されています。
が、古い情報もあったり情報が錯綜している部分もある気がします。
ひと昔前ですと、Dirsyncどうディレクトリ同期ツールを利用していましたが、
昨年にAzure AD Connectがリリースされており、今後はこのツールが基本となるかと思います。
MSが公開している自習書も2012年のもので、Dirsyncが前提になっています。
ですので、2016年2月時点で自分が構築した際の流れを一度まとめてみようと思います。
(構築手順まとめは、後日upします。。)
今回の記事は、ディレクトリ同期で同期される属性値に関してです。
Office365ではどのような属性値を同期しているのかなというのがセキュリティ的にも気になりました。
一応、下記サイトに公開されているみたいで、
「UserPrincipalName」、「mail」などそうだよねというものも含め結構あります。
https://support.microsoft.com/ja-jp/kb/2256198
ページ下記にも記載がありますが、下記情報を保持するユーザオブジェクトは同期されないみたいです。
パッと見る限り、ADのシステム系ユーザなど明らかに不要そうなものは除外してくれているようですね。
mailNickName が "SystemMailbox{" で始まる
「mailNickName が "CAS_" で始まる」 および mailNickName が "{" を含む」
「sAMAccountName が "CAS_" で始まる」 および 「sAMAccountName に "}" が含まれる」
sAMAccountName が "SUPPORT_388945a0"
sAMAccountName が "MSOL_AD_Sync"
sAMAccountName が存在しない
isCriticalSystemObject が存在する
msExchRecipientTypeDetails == (0x1000 OR 0x2000 OR 0x4000 OR 0x400000 OR 0x800000 OR 0x1000000 OR 0x20000000)
各ブラウザ(IE,Google Chrome,Firefox)でのCookie確認・編集の方法
今回は、各種ブラウザでのCookieの内容確認の方法、編集の方法をまとめておく。
■IE
■方法1:デフォルトの機能でCookieデータをエクスポート・インポート
IEにはデフォルトでCookieの内容をエクスポート・インポートする機能がある。
「Alt+F」でファイルメニューを表示後、「インポートおよびエクスポート」を選択すればよい。
対象に「Cookies」を選択すれば、テキストファイルとして内容を取得可能。
また、変更したテキストファイルを同様にインポートも可能。
■方法2:専用のアプリケーションを利用
専用のアプリケーションを利用して、IEのCookieを確認できる。
おすすめは、「IECookiesView」。起動して確認と編集が簡単に可能。
www.nirsoft.net
■Google Chrome
■方法1:拡張機能「Edit This Cookie」を利用
この拡張機能を入れれば、訪問中のサイトのCookieを表示・編集可能
chrome.google.com
■方法2:Cookieファイルを直接参照
Firefoxでもだが、CookieファイルをSQLite形式で保存している。
よって、SQLiteのDBを操作できるアプリケーションから参照可能。
自分は、下記を利用している。
SQLite Studio
SQLiteStudio
参考:SQLiteの開発ツール
SQLiteの開発ツール - 流れ着いたら。。。
■Firefox
■方法1:アドオン「Firebug」を利用
非常に有名なアドオン「Firebug」でもCookieを参照可能
addons.mozilla.org
■方法2:Cookieファイルを直接参照
これはGoogle Chromeと同様。
セキュリティが強化されたWindows FW 「接続セキュリティの規則」について
WindwosのFW機能の内、接続セキュリティの規則に関して簡単なメモ。
WindowsのFW機能は、たくさんあってわかりずらい。
WindwosのFW(正確には、セキュリティが強化されたWindows FW)には
「接続セキュリティの規則」というものが存在する。
通常FWとは、その機器上で単体で稼働して、
届いた通信に対してポート指定、パケットの内容などで通信許可の判断を下す。
※セキュリティが強化されたWindows FWでは「受信規則」、「送信規則」に当たる
「接続セキュリティの規則」は少し異なり、通信相手と、自分自身それぞれで
相応の許可設定が入っている必要がある。
本機能は、通信開始前にお互いのPCを認証して、IPsecで暗号化した通信を行うことができる。
「接続セキュリティの規則」では、規則の種類が下記4つから選択できる。
・分類 ・・・ドメイン参加のコンピュータのみ接続可能
・認証の除外・・・指定したPCを認証対象から除外
・サーバ間 ・・・指定したPC間の接続を認証
・トンネル ・・・外部ネットワークを介する、PC間の接続を認証
・カスタム ・・・カスタムの規則を作成可能
参考:
接続セキュリティの規則の作成
そんなにたくさんあるFWの規則だが、どのような順番で適用されるのかに関しては、
TecNetに記載があった。
【未確定】フラッシュドライブ利用時のフォーマット形式はexFatにすべき?
WindowsでUSBメモリや、SDカードを利用する際のフォーマットに関して。
既定では「exFat」になっているはず。
調べてみると、いろいろ記事がある通りUSBメモリに向いているのはexFatみたい。
特に、速度がNTFSと比較するといいらしいのだけれども、
実際に試してみるとそれほどの有意な差はなかった。
ドライバも最新なはずだしなー。
USBメモリーを高速書き込みフォーマットに変換(exFATに変換)
USBメモリのフォーマットと速度 | いまと違うところへ
利用したメモリは、Team社製の「TFXC128UHS01TG」というモデル。
余談だけど、TSUKUMOで4,600円くらいで128GBを購入できた。
これをSurface Pro3のmicroSDカードスロットに刺して利用している。
今回はこの1モデルだけの検証になるが、下記のようにNTFSのほうが若干良いくらい。
他にも機会があれば試してみようかな。
■NTFS
Windowsの高速スタートアップ(ハイブリッドブート)に関して
Surface Pro3を使っていて感じるのは非常に起動が早いということ。
元々利用していたMacbook Airも起動がはやかったけれどそれ以上に早いかもしれないと感じている。
SSDの恩恵もあるのでしょうが、ほかにも秘密がありそうだなと思って調べてみたらありました。
Windows8以降に搭載されている技術で、高速スタートアップというものみたいです。
どういうものかというと、
単純ではあるが前回のシャットダウン時にOSの情報を一部分保存しておき、
次回起動時にはその情報をロードして処理の短縮をしているとのこと。
もう少し細かくいうと、Windowsが起動する際にはまずOSのカーネルをロードする。
その次に、デバイスドライバをロードするんですが、
この情報を前回のシャットダウン時に保存しておくとのこと。
要は一番時間のかかるであろう、デバイス周りの処理をスキップしてしまうという方法で短縮している。
確かに、頻繁にHWの構成が変更されるわけではないし理に適っているかもしれない。
当然、HW構成が変更した際には通常の起動処理をしないといけないけど。
では、どのようにしたら通常の起動になるのか?という話だが、
高速スタートアップを無効にするか、再起動を実施すれば通常の起動処理になるようです。
自分が利用しているSurface Pro3はデフォルトだと高速スタートアップが有効。
その状態で「シャットダウン」で停止させると、ドライバ情報を書き出して停止、
次回起動時に、書き出した情報をロードして高速スタートアップが動作する。
一方で、「再起動」の場合はドライバ情報を書き出さず、通常の起動処理で立ち上がるようです。
普段そんなに「再起動」なんてしないから、知らずに「シャットダウン」運用をしていたら
ある時から不安定に、、なんてことが起きるかもしれない。
(特にデバイスの追加とか削除があった場合)
ちなみに、高速スタートアップの有効化・無効化は
「電源オプション」>「システム設定」から変更可能。
最後に、デバイス情報を保存しておくという処理に関してだが、
Cドライブ配下にある、hiberfil.sysがそのファイルらしい。(不可視ファイル)
どこかで聞いたことある気がすると思ったら、
このファイル「休止状態」でシステムを停止する際に情報を保存するファイルじゃん。
参考URL:
Windows10の高速スタートアップって何?速いけど危ない?無効にする方法は? | ligamap
ハイバネーション(hiberfil.sys)を無効にする・削除する]
pagefile.sysとhiberfil.sysの解説ページ
InstantGO(旧Connected Standby)について
半年前に4年間共にしたMacbook Airが調子が悪くなったのでSurface Pro3を購入。
モバイルPCはもっぱらMacだったので、新鮮な感じです。
実際のところ、非常に便利でWindows10で快適に利用できています。
で、モバイル機器はほぼMacだったのでWindowsをモバイル環境で利用するにあたり
いろいろと発見があるわけです。
例えばWindowsには「スリープ」、「休止状態」というのが元々あったかと思います。
※Windows8以降では「休止状態」はデフォルトでは表示されないらしい。
また、「休止状態」が利用できる端末かどうかというのもあるらしい。
Tips:電源オプションをcmdからいじるには、powercfg.exeを利用する
www.atmarkit.co.jp
そして、「スリープ」の挙動も変わってきているらしい。
現在InstantGOと呼ばれているが、
「従来のスリープ」は完全にOSデータをメモリに保存して停止していたのに対し、
InstantGOが有効状態の「スリープ」は、ネットワーク機能は有効のままになるらしい。
いわゆるスマホのアプリケーションみたいに、
アプリケーションが通信を行い機能を提供できるようにという配慮から生まれた技術とのこと。
InstantGOに対応していない端末の「スリープ」はいわゆる「従来のスリープ」と同様になる。
InstantGOに対応しているかの確認方法は下記で可能。
「powercfg /a」を実行して、
「スタンバイ (S0 低電力アイドル) ネットワークに接続されています」
と出力されれば対応している端末と判断できる。
C:\Windows\System32>powercfg /a 以下のスリープ状態がこのシステムで利用可能です: スタンバイ (S0 低電力アイドル) ネットワークに接続されています 休止状態 高速スタートアップ 以下のスリープ状態はこのシステムでは利用できません: スタンバイ (S1) システム ファームウェアはこのスタンバイ状態をサポートしていません。 S0 低消費電力アイドルがサポートされている場合、このスタンバイ状態は無効です。 スタンバイ (S2) システム ファームウェアはこのスタンバイ状態をサポートしていません。 S0 低消費電力アイドルがサポートされている場合、このスタンバイ状態は無効です。 スタンバイ (S3) システム ファームウェアはこのスタンバイ状態をサポートしていません。 S0 低消費電力アイドルがサポートされている場合、このスタンバイ状態は無効です。 ハイブリッド スリープ スタンバイ (S3) は使用できません。
参考URL:
Microsoft Surface の電源状態
Windows 8 & 8.1はダメOSなのか - 第2回 | マイナビニュース
Windows TIPS:Windows 8/8.1で休止状態設定を有効にする - @IT