ソフトウェア開発者の日常

こだわりなく書きたいことを書いていきます。

1週間の振り返り(2016/11/19〜2016/11/25)

仕事 週次

東京駅で購入した駅弁です。
f:id:AJYA:20161125235359p:plain
バランスよくいろいろなものを食べられるので選びましたが、ご飯をもう少し食べたかったです。

  • 2016/11/19(土)
    インフルエンザ予防接種を受けました。
    抗体ができるまで約2週間かかるらしいので、それまでに流行して欲しくないと思っていましたが、流行したようです。

http://www3.nhk.or.jp/news/html/20161125/k10010783971000.htmlwww3.nhk.or.jp

  • 2016/11/20(日)
    子どもと公園に行きました。
    雨の日の翌日で曇っていたので、遊具が乾いていないかもと思いましたが、充分乾いていました。
    子どもは元気よく、以前は苦手かと思っていた遊具でも遊んでいました。
  • 2016/11/21(月)
    お客さんからの連絡で大トラブルが発覚しました。
    こちらが対処できることはなく、状況をまとめて原因を報告する書面を作成することしかできませんでした。

ajya.hatenablog.jp

  • 2016/11/22(火)
    前日発覚したトラブルの報告のために、お客さんを訪問しました。
    予想された最悪の結果にはならない状況になっていたのが幸いでした。
  • 2016/11/23(水)
    強い風が吹く中、草むしりをしていました。
    昨年までは、この時期こんなに伸びていたっけ？生えていたっけ？と思うくらい伸びていたり生えていたりしました。
    根っこから抜きたくても、伸びすぎていて抜けない草が何本もありました。
  • 2016/11/24(木)
    Oracleを新しいサーバーにインストールして環境の構築をしました。
    思っているのと実際やってみるのでは随分違って、勉強になりました。

ajya.hatenablog.jp
ajya.hatenablog.jp

  • 2016/11/25(金)
    データの移行プログラムの設計書について、データの移行先からコメントがありました。
    内部構造の表現についてまでコメントがあり、なぜそこまでコメントをされなければいけないのか、全くわかりません。
    受け取るデータについてのコメントがあるなら理解ができます。
    お客さんの承認が必要というのは理解していますが、データの移行先のチェックで横槍が入るとどんどんスケジュールが遅れるだけです。

ajya.hatenablog.jp


11月22日の朝の地震は、iPhoneが少し離れたところにあり、テレビを見てもいなかったので、iPhoneになにの通知が連続で来ているんだろうと少ししてから見て気がつきました。
津波警報が出ていることも知り、NHKを見て東日本大震災のときの気持ちを少し思い出しました。
www.buzzfeed.com

ちょっとした手間をかけないから、結果として正しくない結果になる

仕事

少しの手間をかけなかったために、望んでいない結果になることは多々あります。

管理ページを確認しない

設定変更作業をした際に、正しく変更できたか確認をしなくてはなりません。
正しく変更できないと、重大なトラブルが発生します。

正しく変更できたか、確認する方法はあります。
自社のシステムには、登録に失敗するデータの記録が残りませんが、他社のシステムに連動していて、他社のシステムには失敗しても記録が残ります。
ワザと失敗するデータを登録して、他社のシステムの管理ページから処理結果を確認すると、失敗したという記録が確認できます。
記録には、どのような設定で他社のシステムに処理を要求したのかも確認できます。
管理ページの確認は目視になりますが、設定の間違いがないことを確認できます。

時間にして長くても10分かかりません。
この作業を行わなくて、重大なトラブルが発生しました。

差分がないことを確認しない

システムが送信するメールの文面の修正依頼がありました。
修正後の文面は、メールに書かれていました。

修正後のメール文面を確認しようと、システムが送信したメールと、依頼された修正後のメールの文面をWinMergeで比較しました。
WinMerge 日本語版


比較すると、2箇所違いがあります。

ほんの2～3分で出来ることです。
この作業を行わないで、修正したのでチェックをお願いされました。
ツールを使って抜けがないようにチェックするように指示しました。


複数人でチェックを実施して、ミスを防ぐことも重要です。
その前に、できることは行って、ミスがないことを次の人に確認してもらうという心構えが、さらに重要と考えています。

Oracle 11g環境構築で悩んだこと3点

Oracle

先日こちらの記事を書きました。
ajya.hatenablog.jp

この記事では触れませんでしたが、Oracle 11g環境構築で3点悩みました。

1点目：キャラクタセットを変更すべきかわからない

2.データベースの作成
先ほどと同じPDFの14～32ページを参考にして作成しました。
リスナーの構成は、画面で行ってファイルを作成してから、過不足ないかテキストエディタで開いて確認して、修正の必要があればバックアップをとったうえでテキストエディタで直した方が手っ取り早いと思います。
23ページのデータベース識別情報は、グローバル・データベース名とSIDは、同じにしました。入力例ではドメイン名を付けていますが、付けなくても大丈夫です。
28ページのセキュリティ設定は、エディションが違うからなのか、表示されませんでした。

Oracle 11gの環境構築 - ソフトウェア開発者の日常

参考にしたPDFの27ページの初期化パラメータに、キャラクタ・セットがあります。
既存環境がどのように設定されたかわからなかったので、キャラクタセット名／文字コードの確認方法を調べたら、以下のクエリでわかりました。

SELECT PARAMETER, VALUE
  FROM NLS_DATABASE_PARAMETERS
 WHERE PARAMETER IN ('NLS_CHARACTERSET', 'NLS_NCHAR_CHARACTERSET');

NLS_CHARACTERSETがJA16SJISTILDE、NLS_NCHAR_CHARACTERSETがAL16UTF16でした。
この値は初期値と同じだったので、変更をしないでインストールを続けました。

2点目：データベースに接続できない

3.クライアントからの接続の設定
こちらのページの「クライアントの接続情報の設定を行おう」を参考にして設定しました。
テストでは、ログインするユーザーをsystemに変更して試しました。

Oracle 11gの環境構築 - ソフトウェア開発者の日常

データベースができたので、データベース名と同一のユーザー名、途中で入力したパスワードを用いてユーザーができているのかな？と思っていました。
当然接続できません。
Enterprise Managerにログインして、ユーザーを見たところ、データベース名と同一のユーザー名のユーザーが存在しないので、改めて作成が必要だと理解しました。

f:id:AJYA:20161124151549j:plain
photo credit: stevegarfield Oracle Plane via photopin (license)

3点目：文字化けが解消されない

当初は、

6.システム環境変数の設定
システム環境変数に、変数名 NLS_LANG、変数値 Japanese_Japan.AL32UTF8を追加して、サーバー毎再起動しました。

Oracle 11gの環境構築 - ソフトウェア開発者の日常

を行っていませんでした。

こちらを先に行って、Webシステムからデータを参照すると、文字化けしていました。

7.データベースのエクスポート／インポート
expでデータベースをダンプして、impでデータベースをインポートしました。

Oracle 11gの環境構築 - ソフトウェア開発者の日常

システム環境変数の設定を行って、コマンドプロンプトを開きなおして、データベースのインポートを行っても、文字化けは解消しませんでした。

一度再起動してみようと、OS毎再起動をしたら文字化けは解消されました。
Oracleが起動済みの状態で、システム環境変数の設定を行っても、動的には反映されないということを理解しました。
このような設定をしないで済むように、初期の構築時にいろいろ試せばいのかもしれません。
今回は既存環境の移行なので、既存と同じとしています。