[仕事]Tomcatの管理ユーザ

　何度か書いていますが、【SAStruts+S2JDBC】開発でTomcatを使っています。

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

　ふとTomcat上の(Webアプリの)ステータスを見たくて「Web Application Manager」にログインしようとして…
「はて、Tomcatの管理ユーザなんだったっけ？」
　…と忘れて、調べるのにちょっと時間を使ったのもメモしておきます。

　Tomcatのインストールフォルダにあるconfフォルダに「tomcat-users.xml」があります。
　そこに…

<user name="admin" password="admin" roles="admin,manager" />

　…とあるのが、ユーザとパスワードです。

※参考：Javaの道

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

　普段の開発スタイルではTomcatの起動/停止くらいしかせず、それはEclipse上でできます。

　Web Application Managerを使う必要など、たまにしかないことを、メモっておくことで、いざという時にリズムを崩さずにタスクを続けれるものだと思います。

[仕事]SAStrutsのvalidateの呼び出し

　【SAStruts+S2JDBC】で開発していますが、そのvalidateで「ほぉ〜」を思う挙動があったのでメモしておきます。

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

　Executeアノテーションのvalidateプロパティに設定するメソッドが、Formクラス、Actionクラスの双方にあった場合、『Formクラスのメソッドのみ』が実行されます。

　そして、Formクラス→Actionクラスの順に検索されるため、Actionクラスに書いていても(Formクラスに同名のメソッドを書いていることを忘れていて)「あれ？呼び出されない？？」なんて状況になります。

◆Actionクラスのサンプル

@Execute(validate = "validateXxx", input = "error.jsp")
public String sampleX() {
//処理
}
//こっちは実行されない。
public ActionMessages validateXxx() {
ActionMessages errors = new ActionMessages();
//処理
return errors;
}

◆Formクラスのサンプル

//こっちが実行される。
public ActionMessages validateXxx() {
ActionMessages errors = new ActionMessages();
return errors;
}

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

　異なるクラスでも同名のメソッドがあった場合など、Eclipseは気を利かせて、警告メッセージを表示してくれます。
　が、この場合では、(なんせJava的には関連のないクラスですから)何も表示されません。

　なので「validateを実行したくてActionクラスに実装したけど、どうも実行されないよ〜」な場合、Formクラスに同名のメソッドが無いか確認してみてください。

jsp保存時エラー

　ここ数ヶ月は【SAStruts+S2JDBC】の組み合わせでWebアプリを開発しています。

　SAStrutsやS2JDBCの特徴やメリットなどは、また後日として、その作業中…jspの修正でちょっとはまったのでメモっておきます。

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

※Eclipseを使っていました。

　リファクタリング中、それまで各jspに記述していた内容をincludeで呼び出すように別ファイルにしました。

　で、リファクタリングを完了して、「さて保存…」としたところ画像のようなエラーが表示されました。

「保管の問題
　保管を完了できませんでした。
　理由：一部の文字は"ISO-8859-1"文字エンコードを〜」

　んん〜？？と思ってググってみると以下のようなエントリが見つかり、すぐに解決しました。
「EclipseでJSPを保存しようとしたら、エラーが発生」

　何のことはなく…

<%@ page contentType="text/html; charset=UTF-8" pageEncoding="UTF-8" %>

　…を付けてJSPエンコードを指定してあげると何事もなく、できました。

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

　
　最初は、ファイルのエンコードかな？と思ってEclipseの設定を見ていましたが、これには気付きませんでした。
　というわけでメモです。

　ちなみにテキストエディタで開いても上記の状態(JSPエンコードがない状態)だと文字化けしてコンパイルされてしまいますので、注意です。

継続的な受付窓口って必要

※この記事は新しいブログに移行しました。

移行先は【継続的な受付窓口って必要 – サウスポーなエンジニアの独り言】です。

[仕事]3ヶ月を振り返って

　今の部門に異動してきて3ヶ月が過ぎました。

　部門毎にミッションがありますし、部門内でもチームやプロジェクトによって役割が違っていますが、ふとこの3ヶ月とそれまでを比べて、起動しているアプリの違いなんかを感じたので書いてみます。

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

　それまでいた部門ではプロジェクトの特性、現在の工程にもよりますが、多かったのは、提案書、要件定義書を作るためのPowerPoint、設計書やテストケースに関連するExcel、それらの資料用にスナップショットを撮るためのキャプチャツールが、割と多かったように思います。
　開発工程ではEclipseなどのIDEも起動していましたが、それ工程以外では、主にソース確認のために使うことはあってもコーディングをガッツリするために使うことはあまりありませんでした。

　一方、今、私が所属するチームのミッションや自分の役割は技術的な調査、検討や割とガッツリしたコーディングだったりします。

　なので、起動しているアプリもコーディング用にEclipse、データ確認用のDBツール(ObjectBrowserやosqledit)、ソース比較などに使うWinMerge、ログファイル用のtailなどです。
　後はJava開発なのでJavaAPIドキュメントや使っているフレームワーク…SAStruts、S2JDBC…のドキュメント系です。
＃サーバはWindowsなのですが、Linuxだったらここにtelnetなども入ってきます。

　おそらくこの3ヶ月でPowerPointを開いた回数は数えれる程かと思います。

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

　これまでは、PowerPointをいじりなら(＝提案書の中身を考えながら)、Excelでそれまでの設計書を確認したりして、作業単位を越えた(うまく言えませんが)、マルチタスク状態が多かったと思います。
＃これはこれで自分の性格に向いているので、それほど苦ではありません。

　今は、良い意味である作業に集中して取り組めるので、それはそれでおもしろいなぁと感じています。
　そして、割り込みを入ってそれを処理した後のトップスピード(=集中している状態)に戻すまでの大変さ…よく15分以上かかると言われています…も久しぶり体感しています。

メンテナンス作業で感じたこと

※この記事は新しいブログに移行しました。

移行先は【メンテナンス作業で感じたこと – サウスポーなエンジニアの独り言】です。

社内システムは自分で作りましょうよ。

※この記事は新しいブログに移行しました。

移行先は【社内システムは自分で作りましょうよ – サウスポーなエンジニアの独り言】です。

発表資料に対する責任

※この記事は新しいブログに移行しました。

移行先は【発表資料に対する責任 – サウスポーなエンジニアの独り言】です。

[仕事]OracleXEのポート変更方法

　以前のPJでOraceXEを使ったのですが、その時に調べた「ポート変更方法」の備忘録です。

＃この時は、本番環境ではOracle10gR2を使うことになっていましたが、そのライセンス購入手続きの待ち時間がもったいなく、また技術調査をしたいこともあって使いました。

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

　OraceXEのデフォルトポートである8080は、TomcatなどのJava開発においてよく使われるポートでもあります。

　Tomcatはそれぞれのローカル環境にもあるので、そちらは変えたくないと思い、調べました。
　以下のコマンドでOKです。

exec dbms_xdb.sethttpport(8081)

　後は、スタートメニューにある「データベースのホームページに移動」…管理画面…のポートもそれに合わせて修正します。

　ちなみにインストール時にすでにTomcatが起動しているなどして、8080ポートが使われていると、「どのポートにする？」て聞いてくると思います。

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

　最後に、OraceXEは10gベースですが、10gにはR1、R2などの後継バージョンもあります。

　ですので、全く一緒かと言われると限りません。
　そのため、例えば「Oracle9iからOracle10gR2へDB移行があるけど、10gR2が来るまでに同じ10gだからOraceXEで確認しておこう」とした場合などには注意が必要かと思います。

ドキュメントを書くために気をつけていること

※この記事は新しいブログに移行しました。

移行先は【ドキュメントを書くために気をつけていること – サウスポーなエンジニアの独り言】です。

ワークフローシステムが意味がない時

※この記事は新しいブログに移行しました。

移行先は【ワークフローシステムが意味がない時 – サウスポーなエンジニアの独り言】です。

近くの〜より遠くの〜

　組織…会社全体や部門などの風土によっては、色々な経緯、要因によってあまり情報連携ができていないことがあります。
＃もちろん良くないことではありますが…。

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

　「情報連携」と言っても、堅苦しい内容でなく、単純なレベルで「どんなPJがあって、誰と誰がそれを担当しているのか？」や、またちょっとしたノウハウやTipsの教え合い(共有)的なものです。

　そういうレベルのものでも、(チーム内ではまだしも)チームが違えば、「え、そのノウハウ、聞いてくれれば…」ということが多々あります。

　そういう状況を見聞きするたびに、「もったいない」「残念な」気持ちになります。

　一方、社内SNSでは(個人的には)そういうノウハウやTipsというのは、得やすい状況かと思います。
　携わっているPJ、タスクに直接関係のないこともありますが、それでもいつか役に立つレベルの内容が多いように感じます。

　それに何か困ったことがあっても「ちょっとこういうことで困っているのですが〜」と社内SNSで書き込むと、会ったこともない方からも情報を得ることができて、それで解決できたり、糸口となることも多々あります。

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

　中には、社内SNSでやり取りしている間に親しくなり、(会ったことがないにも関わらず)実際に初対面の時には、昔から知っているような感覚もありました。

　こういう体験を何度かしていると「情報共有の文化が乏しい」所とはますます情報共有が疎遠になり、そうでない所とはますます情報共有ができていき、その状況の差がますます広がるなぁと思い、やっぱり残念な気持ちになりました。
＃同時に「なんとかせな！」という気持ちにもなります。

新しいチームリーダーのことを社内SNSで知った。

※この記事は新しいブログに移行しました。

移行先は【新しいチームリーダーのことを社内SNSで知った – サウスポーなエンジニアの独り言】です。

自分憲法

※この記事は新しいブログに移行しました。

移行先は【自分憲法 – サウスポーなエンジニアの独り言】です。

生産性の低さを嘆くよりも…

※この記事は新しいブログに移行しました。

移行先は【生産性の低さを嘆くよりも… – サウスポーなエンジニアの独り言】です。

資料の作り方で迷いました。

　数ヶ月前、お客様先常駐で要件定義、基本設計工程のタスクをこなしていました頃の話です。

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

　その時作っていた資料はシステムの基本設計のコンセプトを決める2ページ程度のちょっとした資料でした。

　何を迷っていたかというと、Excelで作るか、PowerPointで作るか…という点で迷いました。
＃そこはパワポで資料を作るのが多い文化のようでした。

　お客様のエンドユーザ…ITには詳しくない…の合意を取りやすくするために、多少でも工数をかけて、(そのお客様に好まれる)パワポでキレイに仕上げるか？

　それとも、(詳細な部分が抜け落ちやすいパワポでなく)後工程で、設計者や開発メンバーが役立つようExcelでキチッと仕様書的に書くかです。

　もう1つ迷った要因としては、「自分がこの説明をしない」点でした。
＃お客様がさらにその先のエンドユーザに説明する段取りでした。

　自分で説明するのであれば、いったんはExcelで書いて、説明時にホワイトボードなりを使い、具体例を書く等して、それなりの効果を生む出すことができるようにします。
　結果としてパワポで書くよりも工数を削減でき、かつ、設計者にとって有効な資料が残ると思います。
＃また、資料の説明を聞くだけでは「分かったつもり」になりがちなのを少しでも防止できると思います。

　しかし、前述したように、説明者がお客様(エンドユーザとは別の意味で気を使う)なので、「意図が正しく伝わるか？」「仕様を深い部分でエンドユーザに理解してもらって、合意してもらえるのか？」が未知数で、不安でした。

　結局は、自分が資料を作るのが速いExcel＋説明してくれるお客様に説明のポイント…「ここはこの方向で合意を取ってきてください」「ここは説明だけでは難しいので具体例をその場で…」…を伝えることにしました。
＃説明するお客様からすると「お客様(ここではエンドユーザ)に受けが良いパワポで作ってくれよ」て感じなのかもしれませんが(苦笑)。

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

　契約関係、組織構成上など要因はいろいろあるでしょうが、関係者が複数いると、資料の作り方1つにも気を使わないといけないなぁと思いました。
＃よくあるパターンで資料が一人歩きして、作成者の意図とは全く違った伝わり方をしていることもありますので。

社内SNSを使っての情報共有

　社内SNSについて何度かこのブログでも書いています。

◆[雑多]社内SNSにエントリが書けない
◆[仕事]社内SNSを使っていて…

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

　この手の社内SNSに課題の1つが【継続/安定して新規ユーザがブログを書いて情報発信や活性化ができるか？】ということだと思います。

　少数の同じ人ばかりが書いていると…

(話題などが)内輪化する。
　↓
新しい人がエントリを書くことに対してハードルを上げてしまう。
　↓
結果、同じ人のエントリばかりになる。

　…という悪循環になると思います。

　私の所属会社では、社内SNSに社外環境から(基本的に)アクセスできず、そのため、ブログを書く、他の人のブログにコメントするなどを会社ですることになります。

　その時に出てくる課題(というか問題？)が、【業務時間内外に、ちょっとした息抜きに、それをするのがしづらい雰囲気にある】ことです。
＃もちろん部門やグループにもよります。

　個人的には、業務時間内でも、ちょっと気分転換にタバコ部屋で一服する、コンビニに行くのとそう変わらないと思いますが、なかなか気軽に…という人は少ないようです。

　話は変わって、(現場ではない)上の方からは…

「情報共有や社内活性化のために社内SNSをもっと活用して行こう」

　…という声が時々聞こえてきます。

　それ自体は良いことだと思いますが、前述した雰囲気自体を変えない限り、それは進んでいかないと思います。

　なぜそういう雰囲気になるのかなぁと考えてみると、1つに部門やグループ長が社内SNSを使っていないことがあると思います。
＃最終ログイン日時が「半年以上ログインなし」とかありますし(苦笑)。

　「上司が書かないのに自分が書く(利用する)わけにはいかない…」なんて声もけっこうあったりします。

　そういう「えらい」人達には(書かない/書けない理由はそれぞれと思いますが)、まずは無理矢理にでも毎日(またはそれに近い感じで)何らかの形で社内SNSに書いてもらう仕掛けなんてどうだろう？と思います。

　一例ですが、毎日、(気軽に)1行で返事を書けるようなお題を上げて、それに対して、上長なりがまずはコメントします。
　それに対してメンバーが好きなようにコメントしていくというものです。

　イメージとして…

お題：「今日朝ご飯はなに食べましたか？」
部長：「ご飯と味噌汁と鮭です。」
メンバー1：バナナ2本です。
メンバー2：食べてません！！
メンバー3：私はパン派です…ちなみに朝シャワーを浴びる派です。
　部長：「朝のシャワーってやっぱり頭すっきりする？」
　　メンバー3：「むっちゃすっきしますよ」

　…のような感じです。

＃社外常駐でなかなか社内SNSにアクセスできない課題は、また別の課題として考えます。

　こんなことが「有効な情報共有」になるか？と言われればならないと思います。が、まずは使ってもらわないことにはその一歩も始まらないです。

　また、これをきっかけとして(メンバー間も上長とメンバーも)お互いのこと…例えば、得意分野や仕事への姿勢など…を知っていけば、それも情報共有の1つの形となるのと思います。

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

　短期的な費用対効果が出ないかもしれませんが、情報共有や組織のパフォーマンスなどは…
「これやったから明日から変わるよね」
　…というものではなく、それなりの時間が経った後(中期的)に振り返った時に…
「そう言えば、最近情報共有ちゃんとできているよね」
　…になるようなものだと思います。

＃それが当たり前になると意識すらしないと思いますが。

[仕事]備忘録：CSSハック

　数ヶ月前の話ですが、備忘録として書いておきます。

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

　その日の調査タスクでWebのデザインについて調べていました。

　で、彷徨っているうちに「WebデザイナのためのHTMLチューニング入門（最終回）-便利なライブラリや動画に潜むWebデザインの3つの罠」に辿り着きました。

　そこにある「ライブラリを使わない場合は、CSSハックで」の箇所を読んで「なんでこの記述で切り分けられるんだろう？」とその理由を調べていき、以下の対IE用のCSSのテクニックのサイトが見つかりました。
　これがこのエントリの備忘録です。

--------------------------
（恐らく）最も簡単な、対IE用CSSハック術
IE5.xとIE6互換モードがidやclass名の大文字小文字を区別しない件を利用する
--------------------------
＃javascriptでやるならお決まりの「userAgentを見て〜」というやつです。

　ただ、仕様の穴(どっちかと言うと不具合？)を利用しているので、後に、このCSSを見たらと適切なコメントが無いと分からないなぁと思いました。

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

　以下、長い余談です。

　当時、社内(の標準で定められている)PCにはIE7は入っていませんでしたし「インストールしてください」というのもなかったです。
＃むしろ(いくつかの社内システムが対応していないので)「インストールは自己責任で」的な感じでした。あ、今も同じですが…。

　そんなもんなので、各自お気に入りのブラウザ…Firefox、Sleipnir、Safariなんかを入れているわけです。

　それ自体は問題ないのですが、【IE対応を謳っているWebシステム】の開発の動作確認でFirefox(※要は対応を謳っている以外のブラウザ)を使って行い…

確認したリーダー：「なんかこのレイアウトが少しずれているように見えるんだけど〜」
作ったメンバー：「こちらで見ると問題ないっすよ。(自分のFirefoxで確認しながら)」

　…と答えていた若手(1、2年目だったかなぁ)を見たことがありました(もちろんビシッとツッコミが入っていました)。

＃慌てている時なんか、ついつい自分がどのブラウザで確認すべきか忘れてしまうのは分かるんですけどねぇ…

自分の仕事を説明できますか？

※この記事は新しいブログに移行しました。

移行先は【自分の仕事を説明できますか？ – サウスポーなエンジニアの独り言】です。

[仕事]このブログが見れるようになりました。

　所属会社では「フィルタリングソフト」なるものが導入されています。

　社内からアダルトサイトやゲーム系のWebサイトなど、明らかに仕事と無関係と思われるWebサイトの閲覧をブロックし、表示させないものです。

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

　このフィルタリングする対象が明かにNGなWebサイトなら良いのですが、ブログ(「はてな」はOK)や「教えて！goo」など掲示板系も、ほとんどがNGでした。

＃このブログもブロックされていました。
＃まぁ…ほとんどがソフトバレーのことなので、ブロックされても仕方ないのですが(苦笑)。

　プロジェクト中には技術調査的なタスクもあります。

　プロジェクトで使おうと想定している製品/ツールの評価/評判を調べたり、プログラミングで「これどう書いたらいいのん？」というもの、またテストフェーズで発生した不可解なバグを調べたりと…。

　ツールの発売元ベンダーのWebサイトに掲載されていることもありますが、多くは色々なWebサイトを見渡して行き、答え(またはヒントになる断片的な内容)に辿り着くことになります。

　そして残念なことに、そういう情報はたいがいブロックされて見ることのできないWebサイトにあったります。

　よくあるシーン…

Googleで調べる。
　↓
検索結果(最初の数行)を見て「お！行けそうやん！！」
　↓(クリック)
「ブロックされていますので、閲覧できません！！」画面が無情にも表示
　↓
はぁ〜(溜息)

　…というものです。

　で、どうするかと言うと、URLを控えておいて家で調べて、その結果をまた会社のメールに転送して…という非効率なことをしていました。

　そんな状態でしたが、数週間前にそのフィルタリングソフトをバージョンアップしたらしく、フィルタリングルールが全面的に見直されました。

　結果、ほとんどのブログや「教えて！goo」等も見れるようになりました。
＃このブログも社内から見れるようになりました。

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

　以前では1日1回は出くわしていた「ブロックされていますので、閲覧できません！！」画面は、ほとんど出くわさず、調査タスクに対するストレスはグッと解消されました。