Windows Server 2012 R2 DataCenter Server Core to Full installation

※Dドライブにインストールに使ったISOがマウントされている状態。

Microsoft Windows [Version 6.2.8400]
(c) 2012 Microsoft Corporation. All rights reserved.

::Windows イメージ ファイル (WIM) をマウントするフォルダーを作成
C:\>mkdir C:\mountdir

::どのパッケージをマウント対象にするか確認
C:\>Dism /get-wiminfo /wimfile:D:\sources\install.wim

展開イメージのサービスと管理ツール
バージョン: 6.2.8400.0

イメージの詳細: D:\sources\install.wim

インデックス: 1
名前: Windows Server 8 Beta SERVERSTANDARDCORE
説明: Windows Server 8 Beta SERVERSTANDARDCORE
サイズ: 7,259,493,836 バイト

インデックス: 2
名前: Windows Server 8 Beta SERVERSTANDARD
説明: Windows Server 8 Beta SERVERSTANDARD
サイズ: 12,039,421,772 バイト

インデックス: 3
名前: Windows Server 8 Beta SERVERDATACENTERCORE
説明: Windows Server 8 Beta SERVERDATACENTERCORE
サイズ: 7,251,396,783 バイト

インデックス: 4
名前: Windows Server 8 Beta SERVERDATACENTER
説明: Windows Server 8 Beta SERVERDATACENTER
サイズ: 12,034,891,404 バイト

操作は正常に完了しました。

::今回は SERVERSTANDARD を対象としたいので、index に 2 をセット
D:\>dism /mount-wim /wimfile:D:\sources\install.wim /index:2 /mountdir:C:\mountdir /readonly

展開イメージのサービスと管理ツール
バージョン: 6.2.8400.0

イメージをマウントしています
[==========================100.0%==========================]
操作は正常に完了しました。

::PowerShellを起動して先程のソースから WindowsFeature をインストールし再起動
C:\>powershell
Windows PowerShell
Copyright (C) 2012 Microsoft Corporation. All rights reserved.

PS C:\> Install-WindowsFeature Server-Gui-Mgmt-Infra,Server-Gui-Shell –Restart –Source C:\mountdir\windows\winsxs
補足: Full Installation to Server core)
D:\>powershell
Windows PowerShell
Copyright (C) 2012 Microsoft Corporation. All rights reserved.
PS D:\> Uninstall-WindowsFeature Server-Gui-Mgmt-Infra -restart

Azureクラウドで構築された仮想マシンに「ping」する方法

本文書はAzure上で仮想マシンを構築した後、RDP以外の方法でアクセスできるかどうかを確認するたびに使う「ping」する方法をご説明しています。内容は次の3つのセッションに含まれています。
・Azureの規則
pingの欠点
pspingについて

Azureの規則

Azureにおいて、ICMPプロトコールはAzure Load Balancerに許可されていないため、Azure VMの外から伝統のpingコマンドで「ping」することができません。かつ、Azure VMから外のインターネットロケーションにもpingできません。

Pingの欠点

windows pingコマンドはICMPプロトコールを使っています。当然ながら、Azure上のVMにpingすることができません。

PsPingについて

PsPingはping機能、TCP ping機能、latency and bandwidth評価機能を実現していたコマンドラインベースのツールです。
詳細の情報はここに載せています。
https://technet.microsoft.com/en-us/sysinternals/jj729731.aspx

サンプル

D:\>psping yokohama.cloudapp.net:80
(サンプルだから、アクセス情報は変更済み)

PsPing v2.01 – PsPing – ping, latency, bandwidth measurement utility
Copyright (C) 2012-2014 Mark Russinovich
Sysinternals – http://www.sysinternals.com

TCP connect to 23.102.76.115:80:
5 iterations (warmup 1) connecting test:
Connecting to 23.102.76.115:80 (warmup): 8.82ms
Connecting to 23.102.76.115:80: 10.13ms
Connecting to 23.102.76.115:80: 10.54ms
Connecting to 23.102.76.115:80: 10.85ms
Connecting to 23.102.76.115:80: 12.61ms

TCP connect statistics for 23.102.76.115:80:
  Sent = 4, Received = 4, Lost = 0 (0% loss),
  Minimum = 10.13ms, Maximum = 12.61ms, Average = 11.03ms

Azureクラウド上のVMで、netstat -anコマンドを実行すると、すべての「Local Address」、「Foreign Address」のポートが表示されます。そこの「Foreign Address」からの[IP]:[port]をPsPingすることができます。(環境によるアクセスできる場合もあります)

IE上でFlash Playerクラッシュ問題:Error #2046

IEで突然Adobe Flash Playerを表示するページで 表示されるはずの場所にError #2046と言う表示が出て 動かなくなって困った時に行った対処法について説明します。

対処法:

1.IE(他のブラウザも同様)の閲覧履歴を消去
2.Flash Playerのキャッシュを刷新

IE(他のブラウザも同様)の閲覧履歴を消去
ルート:IE→インターネットオプション→全般→閲覧履歴→【削除】

Flash Playerのキャッシュを刷新
・次のFlash Playerの設定画面に移動
http://www.macromedia.com/support/documentation/en
/flashplayer/help/settings_manager03.html
・画面上に表示している「共通のFlashコンポーネントを格納して、ダウンロード回数を削除します。」チェックボックスを先にオフしてから、再びオンにする
image

・IEを再起動

ここ方法で、問題を直さないと、Flash Playerの問題ではなく、IEとOSの問題の方が可能性として高いです。

会社で使われるテスト用語

機能テストって何かしら

  • ブラックボックステスト
  • アプリケーションを実際に操作してテストする
  • 受け入れテストとも言う

テストの種類

  • RAT
  • FAST
  • TOFT
  • FET
  • 境界条件テスト
  • 探索型テスト

RAT (Release Acceptance Test) リリース時受け入れテスト

スモークテストとも言う。

アプリケーションがとりあえず動作、機能テスト可能な状態にあるかどうかを確認するテスト。 なので実は機能テストではない。

アプリケーションを起動できるか、文法エラーで動かないところはないか、動作に必要なリソース(データベース等)に接続できているか、といったレベル。

FAST (Functional Acceptance Simple Test) 受け入れ時簡易機能テスト

広く浅い範囲を対象とした最低限の機能テスト。 軽量なので一回のテストにかかるコストが少なく、素早く実行できる。

対象は以下のとおり。

  • リンク
  • UIコントロール(入力、ナビゲーション)の挙動
  • 追加、削除、更新などのデータ変更テスト
  • ログイン、ログアウトなどのその他主要機能

すでにテスト環境で完全なテストを通っているものを他の環境(本番環境や開発環境など)へリリースした際に行ったりする種類のテスト。

TOFT (Task-Oriented Functional Test) タスク指向機能テスト

プログラムの機能を確認するいわゆる正常系のテスト。

ユーザがタスクを完了できるかどうか、実行される各タスクの完全性を確認する

  • 様々なデータの入力に対してデータ出力が常に適切であるかどうかをチェック
  • 他の関連する機能と組み合わせた場合の完全性

網羅性が要求される。

FET (Force-Error Test) 強制エラーテスト

いわゆる異常系のテスト。

エラーを意図的に発生させ、エラー処理が正しく機能しているかどうかをテストする。 エラーによってアプリケーションが不安定になったり、データが破損することがないことを確認する。

  • エラーを意図的に発生させる
  • エラー検出の確認
  • エラー処理の確認(エラーから復帰できるか、データ等に異常は発生してないか)
  • エラー通知の確認(エラーメッセージが表示されたか、内容は適切か)
  • エラーによるそのほかの障害が発生していないか探す(エラー処理に抜けがないか等)

境界条件テスト

TOFTやFETの延長線上にあるテスト。 テストに用いる各変数の境界値をテストする。

等価クラスから境界値を分析してテスト変数を絞る。

テスト変数を絞ることはリスクだが、リソース節約のメリットの方がはるかに大きい。

等価クラス

どの値を入力しても結果が同じように処理される。それらの値は等価クラスとしてひとまとめにできる。

  • 数の範囲(2桁の数字 10-99 など)
  • グループ(日付、時刻、国名など)
  • 不正な入力(半角数字のみ許可のところに半角英字、記号、全角文字など)
  • 等価な動作環境(同じバージョンのOSの別々のマシン)

境界値

等価クラスから別の等価クラスへ移行する境界 境界値付近ではエラーが起こりやすいので、

  • 許容される入力値と許容されない入力値の境界
  • サポートされるシステム要件とサポートされないシステム要件の境界

ひとつの境界値からは多くとも最大9のテストケースが得られる。

  • 有効値の範囲
  • 有効値の最小
  • 有効値の最小+1
  • 有効値の最小-1
  • 有効値の最小-α(確実に有効値より小さい)
  • 有効値の最大
  • 有効値の最大+1
  • 有効値の最大-1
  • 有効値の最大+α(確実に有効値より大きい)

他に文字列の等価クラスや小数点や前ゼロのついた数字のような特別なクラスなどが存在する。 ひとつのフィールドの値に関して等価クラスがたくさんあれば境界値もそれだけ増える。

境界値を使ったテストケースの作成

  • 等価クラスを見つける
  • 境界を見つける
  • 有効な入力に対する出力結果を予想する
  • 不正な入力に対するエラー処理を予想する
  • テストケース一覧の作成

探索型テスト

アプリケーションを操作して未知のバグを見つけ出すためのテスト。 学習、計画、実行を同時に行う。

どのテストを使うか

  • 継続的インテグレーションにともなう完全なテスト -> TOFT, FET, 境界条件テスト
  • テスト済みアプリケーションのリリース時 -> FAST
  • リリース前の積極的なデバッグ作業 -> 探索型

機能テストの自動化

なんでもかんでも自動化すればいいってもんでもない。

  • 自動化にはしっかりとした計画が必要
  • 自動化の前にテスト容易性を強化したほうがよい
  • ダメな自動化は無駄
  • 自動テストが複雑すぎるとテスト自体にバグが
  • でもやっぱ好き
  • 複数人で作る場合は命名規約などのガイドラインがあったほうがよい

作成コストと保守コスト

  • アプリケーションの規模が大きくなるほど作成コストがかさむ
  • アプリケーション更新のプロセスに組み込まないとすぐに陳腐化する
  • つまり保守コストもかかる
  • 保守コストがアプリケーションの開発速度に影響する
  • UI変更で全滅したりする

保守性の高いテスト

  • ちょっとした文言変更くらいには影響されない
  • 他のテストの変更に影響されない

機能テストを減らす工夫

  • ユニットテストにまかせる
    • モデルのバリデーションテストなど
  • フレームワークを利用する
    • フレームワークが面倒見てくれる部分のテストは割愛
    • テストを書きやすいフレームワークもある Railsとか

テストライブラリ構築上の注意

  • 複雑すぎる処理はそれ自体にバグが埋まる可能性
  • 整理しておかないと同じようなものがいくつも作られて混乱の元に

テスト容易性

可視性

  • ソースコード
  • ログ出力
  • デバッグ出力

エラーの原因がすぐに追跡できること。わかること。

操作性

  • エラーシミュレーション
  • 診断コマンド
  • テスト用API

エラーの状態を再現しやすいこと。

自動テストの対象としてGUIがいいかテスト用APIがいいかは意見が分かれる。 SeleniumはGUI

Outlook启动提示:mapi无法加载信息服务msncon.dll

1.找到Outlook的安装目录,如我的是:

C:\Program Files (x86)\Microsoft Office\Office14,找到此目录下的outlook.exe文件

2.然后打开CMD窗口,将outlook.exe拖动到cmd窗口中,如下图所示,系统会自动添加绝对路径

image

3.再其后添加 /importprf   .\.prf参数,如下图:

C:\Program Files (x86)\Microsoft Office\Office14\OUTLOOK.EXE /importprf .\.prf

image

4.回车。重新打开Outlook,重新配置即可。

C言語のコーディング規約による保守性の向上

1. はじめに

ソフトウェア開発の性質上、一度開発したシステムは、何度も機能アップが繰り返される傾向が強く、高い保守性が必要となります。とりわけ、複数人が関わるような大規模な開発では、各個人がバラバラにプログラミングしていたのでは、ソースコードの均質化が図れずに結果として保守性を保つことは容易ではありません。
高い保守性を保つためには

(1) 読みやすい
(2) わかりやすい
(3) 統一されている

ソースコードであることが非常に重要と考えます。読み難く、統一されていないコードでは、プログラムの解析ミスが起こりやすく、バグを発生させてしまう恐れがあり、非常に危険です。
そのため、安全性を高めるためにもプロジェクト毎にコーディング規約を規定し、統一されていることが必要となってきます。
今回は、ある組み込みソフトウェア開発で使用したコーディング規約の一例を紹介したいと思います。

2. コーディング規約とは?

システムの保守性を高めるためには、実装工程(開発工程)で保守性の高いコードを作成する必要があります。
保守性の高いコードとは?

(1) 可読性に優れており、読みやすい
(2) 変数などのネーミングが適切である
(3) ロジックがシンプルである
(4) 無駄なコードの重複が無い
(5) インターフェースが直感的である

こうした条件を満たすコードを作成するためには、なんらかの「品質基準」に従ってプログラミングする必要があります。このソースコードの品質基準が「コーディング規約」です。

3. ファイル・ファンクション ヘッダに関する規約

ファイルや関数に何も説明がないと、どのような目的で、どのような処理をしているのか、一目ではわかりません。
下記例のようなヘッダ(説明)を付けることで、ここでどのような処理をしているのかをイメージしやすく、可読性を高めることが期待できます。

(1) ファイルヘッダの例
//--------------------------------------------------------------------------------
//      ファイル名      :       APPMT.C
//      概要            :       Application (Multi Task)  startup
//      詳細            :       アプリケーション (マルチタスク) スタートアップ
//                                      main task を起動する
//      履歴            :       2006/06/07      UserName                新規作成
//--------------------------------------------------------------------------------   
(2) 関数ヘッダの例
//----------------------------------------------------------------------------
// 関数名       :main
// 概要         :
// 戻り値       :なし
// 引数         :int argc
//              説明    
// 引数         :char *argv[]
//              説明    
// 引数         :char *envp[]
//              説明    
// 作成         :2006/06/07    UserName
//----------------------------------------------------------------------------
void main(int argc, char *argv[], char *envp[])  
4. ソースコメントに関する規約
(1) コメントスタイル

メンテナンスの必要に駆られて解析をおこなう場合、ソースコードを解析するのにキーワード検索は有効です。しかし、コメントのスタイルがバラバラだと、検索キーワードを複数回指定しなければならない場合があり、非常に面倒です。また、検索漏れが起こる場合も考えられ、保守性を下げる要因となりえます。

そのため、下記のように、スタイルを決めておくと良いと思います。

  1. 数字・英字は半角
  2. 漢字・ひらがな・カタカナは全角
  3. 全角スペースは使用しない
(2) 判断文にはコメントをつける

コードには判断文(if,for,while,case)が多く含まれています。

この判断文にコメントをつけるだけで処理内容が一目でわかるようになります。

ソースコードの可読性を向上させるのは、コードのスタイルを統一することだけではありません。コードの中に的確でかつ、わかりやすいコメントを記述することも可読性の向上に大きくつながります。

5. ソースコードに関する規約
(1) 変数名はハンガリアン記法を使用する

変数名のみでもある程度の情報を得やすくするために一般的なネーミング規約の一つであるハンガリアン記法と記憶子を組み合わせて変数名を命名します。

ハンガリアン記法とは、変数の名前に型などの情報を縮めて付加する方法のことです。

プレフィックス2_プレフィックス1+変数名

(変数名の最初の1文字は大文字)

例)

static unsigned char s_byTestFlg;

//スタティックなunsigned char

int nWork;

//ローカルなint

プレフィックス1

データ型

c

char

by

BYTE(unsigned char)

u

UINT(unsigned int)

n

int

b

BOOL(int)

w

WORD(unsigned short)

l

long

dw

DWORD(unsigned long)

s

文字列

sz

ASCIIZ文字列

p

ポインタ

lp

long(far)ポインタ

np

nearポインタ

プレフィックス2

記憶子

g

extern

s

static

c

const

なし

ローカル

(2) タブは4文字

インデントがバラバラだと、読み難いコードになってしまいます。

読み難いコードはバグの元です。

そのため、インデントはハードタブで4文字と規定しています。

(3) ネストレベルは5階層まで

if文やfor文でネストが深くなると、処理が複雑で、解読が非常に困難になってしまいます。そのため、ネストレベルを5階層までと規定しています。

例)
if(a == 0)                      //ネストなし
{
    if(b == 1)                  //ネスト1
    {
        if(c == 2)              //ネスト2
        {
            if(d == 3)          //ネスト3
            {
                if(e == 4)      //ネスト4
                {
                    a = 1;      //ネスト5
                }
            }
        }
    }
}

とは言っても、処理が複雑になったり、判断条件が増えると、ネストレベルは深くなってしまいます。その対策として、次の方法が考えられます。

returnで返す

判定文の後に処理をする必要が無い場合には、returnで返すことにより、ネストが深くなることを防ぐことが出来ます。

例)

if(a != 0)

{

return;

}

関数化する

一定のまとまりのある処理を関数化して、その関数を呼ぶことでも、ネストが深くなることを防ぐことが出来ます。

(4) 定数は大文字を使う

定数に小文字を使うと、変数なのか、定数なのか、見ただけではわかりません。一目で定数とわかるように、定数の場合は小文字を禁止し、大文字を使うように規定しています。

例)
#define MAX_COUNTER     10              →OK
#define Max_Counter     10              →NG(小文字は使用禁止)
6. おわりに

いかがでしたか?

自分の開発したシステムであっても、長時間経過すると、どのような処理をしているのか、忘れてしまいがちです。「3日前に書いたコードは他人のコードと同じ」ということも言われています。このような場合、わかり易く、読みやすいコードは、確実に効率よく、正確に解析をすることが出来ます。

ほんの一例を紹介させていただきましたが、C言語でソフトの作成を始める方にも参考にしていただければ幸いです。

破解VS2008 Team Suite90天试用版

Win7下VS2008进入维护模式不能显示升级输入框,无法升级到正式版~~~!!!

以前没有在Win7下装VS2008,由于在XP下使用VS2008习惯了,想在Win7下也倒腾下,自信满满的装完30天的试用版,非正式版怎么看都很别扭,以前XP下升级正式版的方法:

全部安装完毕之后,在开始>设置>控制面版>添加或删除程序>卸载vs.net2008>出现卸载界面>点击Next>输入下面的CD-key ->出现成功画面即可完美将试用版升级成为正式版。 VS2008正式版序列号CDKEY:PYHYP-WXB3B-B2CCM-V9DX9-VDY8T 。 然而在Windows7下安装时却总是不出现输入注册码的地方!

傻眼了,以为是自己自定义安装的,为此重装了好几遍();搜索了一下,解决方法如下:

安装此补丁PatchVS2008.rar

成功升级!!!

PS:注意要使用Administrator账号登陆系统执行补丁哦!(Windows 7系统出于安全考虑,将系统超级管理员帐户(Administrator)隐藏了,不允许“普通用户”使用。很多时候特别是安装一些应用软件时,由于兼容的问题,普通权限的用户无法正常安装,需要启用超级管理员帐户,然后可以在超级管理员账户安装,在标准用户下正常使用。。
如果你也想启用超级管理员帐户,可以按如下的步骤操作:右键单击“计算机”→“管理”,双击“本地用户和组”→“用户”,在右边列出的帐号中右键单击“Administrator”→“属性”,在弹出的界面中取消勾选的“帐号已禁用”。)