競技プログラミング
実は去年の年末から少し競技プログラミングを再開しました。
一応初めてではなくて、学生の頃にちょこっと(ほぼ遊び感覚で)やっていましたが、
PyCon Japan 2015の講演で競技プログラミングに関しての発表がありまして、
久々に興味が出てきた次第です。
ちなみに、昔はTopCoderとかしか知らなかったのですが、
たくさんあるんですね。。
www.slideshare.net
しかしいきなり突撃するのもあれなので、、
また、久々ということもあり普段と違った言語で、
アルゴリズムとデータ構造の復習をかねてはじめようと思いました。
言語は、Pythonです。いつもC++ばかりですのでLLを採用。
まったくの初めてではないですが、それほどがりがり書いた経験もありませんので、
機械学習とかちょこっとやるくらいしか使わないので、言語の勉強もかねてです。
また、アルゴリズムとデータ構造の復習は、実際に手を動かして書くことが一番だと思います。
そこで、下記サイトを利用しています。
AIZU ONLINE JUDGE: Programming Challenge
国内のサービスで、様々なプログラミングの問題が掲載されています。
この中の「Introduction」-「Introduction to algorithm and data structures」
がちょうど自分の目的に合っています。
このカテゴリはアルゴリズムとデータ構造にちなんだ課題が集められています。
ソートから、連結リスト、再帰処理などを利用して解く問題が収録されており、
練習にちょうどいいです。
まだ初めてちょっとですが、週末など時間があるときにちょこちょこ進めています。
ExcelからDBのレコードを参照・更新したい
早速ですが、タイトルのようなことなんてあるのか？と言われるかもですが、
たまにあるのですよ。
どちらかと言うと、
元々Excelで管理していたものをDBへ突っ込みたいとかが多いのですが。
普通にDBに接続して、Insert文つくって流しましょうというのはそうなんですが、
度々やっていると一発でExcelシートの内容をDBのテーブルに突っ込めるアドオンがあれば
効率いいなという思考に行き着きまして。
なければ隙間時間に作成しようかなとも思ったのですが、
既にあるのですね。本当に素晴らしい世の中ですね。
詳細はマニュアルがしっかり整備されていますのでそちらを参照のこと。
便利だ。。
ExcelDBTool - エクセルでデータ作成、DB接続、データ取得更新
また、同サイトで紹介されている「ExcelDevTool」も大変便利です。
データの生成から、比較、テンプレートの作成等々ありがたいです。
今まで、Excelの便利アドオンとしては、RelaxToolしか知りませんでしたが、
「ExcelDevTool」も試してみようと思います。
RelaxTools Addin for Excel 2007/2010/2013/2016 | Excelを便利にする250以上の機能を体系化したアドインはこちらです。
なんだかんだExcelを利用している方は多いと思いますので、参考に。
WSUSサーバのメンテナンス(管理コンソールに繋がらない等)
以前、WSUSのクリーンアップについて記事を書いたのですが、
そのほかにもWSUSというとちょこちょこ不思議な動作をすることがあります。
たまにですが、WSUSの管理コンソールに接続不可能という現象が発生することがあるのですが、
それらの自称に対して、MSのWSUSチームのBlogにてコメントが公開されていましたので。
自分が体験したのは、上記Blogでいうところのケース2.「たまに接続ができない」になるのですが
下記で解決することが多いとのこと。
・インデックス再構築
→確かに、パッチが増えてくると遅くなるんですよね。。パッチの選定にとてつもない時間が。。
・WSUSサーバのクリーンアップ
→容量問題でもそうですが、不要なパッチは処理時間増を招きますからね。
前回記事にしたのはここですね。
WSUSサーバのクリーンアップ - Infrastructure Engineer`s Notes
・WSUS管理コンソールのキャッシュ削除
→これは知りませんでした。効果はちょっとあるかもくらいみたいですが。
・不要な更新プログラムは「拒否」にする
→これはWSUSの運用上非常に大事かと。
パッチは積み上げていくので、どんどん必要なパッチの選定に要する時間が増加していきます。
・WsusPoolのメモリ引き上げ
→なるほど。利用できる容量を増やそうと。
ここまでやったことはないですが、ありかもですね。
・SQLサーバの最小メモリ・最大メモリの設定値を変更
→上記と同様の考えですね。
これも試したことはないですね。
簡単ですがＭＳサポートチームのノウハウだそうです。
こういうの大事ですよね。
ソフトウェア開発時の見積もりに関して
少し今回はインフラぽくない話を。
普段機会がないのですが、ソフトウェア開発における見積もり技法に関して
触れる機会があったので、その際の情報をまとめておく。
普段サーバ構築等しかしないので、実はとても新鮮という。。。だめだとは思いますが。
■見積もり技法
■類似法
過去の類似Ｐｒｊを参考にして見積もる方法。
ちゃんと類似のＰｒｊを参考にすれば、実績と見積もりの差が乖離はしにくい。
ただし、客観性が乏しい。
■積み上げ法
開発しなければならない成果物の構成要素を洗い出し、
それぞれの作成に必要な工数を積み上げる方法。
ソースコードの行数や、各工程の工数を足してくのがこれに該当。
■パラメトリックス法
必要工数を目的変数として、入力値に開発規模や特性をいれることで
数式的に算出する方法。
例としてSLIMとか。
今回は、定番である積み上げ法に関して。
■LOC(Lines of Code)
開発モジュールのステップ数を算出
一人当たりの生産性ステップ数/月で割り算してコスト・必要人数を算出。
ただしソースコードのカウントの仕方（コメント、ヘッダ含めるか）とかは事前に
どのようにカウントするか決めること。
また、人によりステップ数のカウントの仕方はことなると思うので、
そのあたりの統一も難しい。
当然、要件が未確定の段階ではソースコードの行数など正確にだすのは難しいので、
見積もり制度としても低くなることがよくある。
ＬＯＣ法はこのあたりがあいまいなので、規模尺度法の要件を満たしていない。
※規模尺度法・・・ＩＳＯがソフトウエアの規模の測定尺度のために策定
参考にソフトウエアの生産性は、1MMで1000ステップ前後と言われているとかどうとか。
参考：
http://monoist.atmarkit.co.jp/mn/articles/1108/23/news003.html
http://monoist.atmarkit.co.jp/mn/articles/1109/14/news011.html
■FP法
ＦＰ（ファンクションポイント）・・・仕様をベースにして、言語や設計方式に依存せず、
開発対象となるシステムの機能規模をＦＰという単位で計測する。
ＦＰはデータ要素をもとに計算するので、内部のロジックの複雑性は考慮していない。
なので数値計算プログラムなどには不向きでビジネス系のシステム向け。
また、ＦＰ法には複数の種類がある。
■IFPUG法
これが全部入りのフルバージョン。
システムの扱うデータ、入出力データ、参照データすべてが計算対象
■ＦＰ概算法
ＩＦＰＵＧの簡略版。
■ＦＰ試算法
最も簡易版。概算の見積もりの時はこの手法が利用される。
以下、ＦＰ試算法の計算方法をざっくりメモする。
ＦＰとはデータの種類・数から開発規模を推定している。
よって、対象システムのデータとファイルを決めれば見積もりが可能。
アルゴリズムとかは一切関係ない。
流れは下記の通り。
内部ファイルの数をカウントして、x35
外部インターフェースファイルの数をカウントして、x15
上記2つを合計したものが総ＦＰ数となる。
総ＦＰ数から使用する言語のステップ数に換算が可能。
参考：
http://monoist.atmarkit.co.jp/mn/articles/1110/13/news007.html
http://monoist.atmarkit.co.jp/mn/articles/1111/16/news008.html
■最後に
IPAがSEC BOOKSとして、事業成果をまとめています。
その中に、ソフトウェア開発データ白書というのがあるのですが、
様々なＰｒｊとの見積もり等、実績が載っているので参考にしてみるのがいいかと。
PythonでWMIの内部を覗く
Windowsといえば、ブラックボックスだのと言われることも多いかと思いますが、
その中でもとりわけ見えてこない項目としてWMIがあります。
なにせMS最大の秘密とも言われるようですので。
WMI(Windows Management Instrumention)の詳細な説明は下記のサイトに譲りますが、
WBEMのMS実装版で、Windowsの管理情報にアクセスして情報を取得したり
変更することが可能なインターフェイスを提供してくれます。
Windows Management Instrumentation (WMI) の概要
WMI スクリプト入門 : 第 1 部
突き詰めると、WMIを通してWindowsの様々な情報を取得することが可能であり、
管理者としてはお世話になることもあるかと思います。
ですが、WMIでどのような情報を取得できるのか？
というところが漠然としていたので、
Pythonで覗いてみましたというのが今回のお題です。
具体的に今回やったことは、
PythonからWMIを叩いて取得したオブジェクトの中身を見ることで、
どのような情報を取得できるのかを確認したところまでです。
Pythonには様々なモジュールがありますが、下記を利用しています。
下記のようにコマンドを発行することで、WMIインターフェイスへの入り口を作れます。
import wmi c = wmi.WMI()
この「c」の中にWMIの情報が詰まっているのですが、
それを覗くのにPythonのinspectモジュールを利用してみました。
これは、モジュール内のクラスの一覧などを出力してくれるモジュールです。
これにより「c」の内部を覗いてみます。
inspectモジュールを使って、モジュール内のクラス一覧を得る - Mattari Diary
import inspect inspect.getmembers(c)
記載しませんが、大量に出力されます。
_classesの部分が、我々としては大事です。
どのclassの値を参照すれば、我々が望んでいる情報を取得できるかが決まりますので。
例えば、「Win32_Service」というclassがあるかと思います。
このclassからどんな情報が取れるのかと気になったら、
更にこのclassの内部を検索してやればよいのです。
inspect.getmembers(c.win32_service)
こうやっていけば、どの情報を取得できそうかあたりがつけられるかと思います。
このレイヤーまで掘れば、変数名からどのような情報が得られそうかというのが想像できます。
参考:
WMI Fun !! 〜 WMI (Windows Management Instrumentation) に興味がある方・システム管理者必見！ 〜
https://msdn.microsoft.com/en-us/library/windows/desktop/aa394582(v=vs.85).aspx
この本が気になる。WMIというとあんまり情報がなく。。
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)
