ソフトウェア開発」カテゴリーアーカイブ

Slides from Silverlight for Business Applications Webcast

SilverLightをビジネス用途で使用するのに
現状のできることや、なんなりをよくまとめてあった
WebCastがあったので紹介

irritatedVowel.com
http://community.irritatedvowel.com/blogs/pete_browns_blog/archive/2008/03/20/Slides-from-Silverlight-for-Business-Applications-Webcast.aspx

これを見ると、Hosting環境としてはIISだけじゃなくて
Apatchでもいけるのかな~
クライアント側にダウンロードして起動するものだから
たぶん行けるんだろうとは思っていたけど、確証がなかった。

今度やってみようかな

意外と難関!? Oracle Migration Workbench

AccessからOracleへのデータ移行

先輩から引き継いだAccessで作られたツールが、ちょっと性能的な限界を迎えたので社内のOracleサーバーにデータを移行しようと思った。調べてみるとOracleがAccessからのMigration用のツールを提供しているのでとても簡単

意外と簡単!? Oracle Migration WorkbenchによるMS-Access→Oracle移行
http://otndnld.oracle.co.jp/easy/access/shift_manual/index.html

だと思ったら、実はものすごくめんどくさかったのでメモ。

不思議なツール構成

AccessからOracleに移行するには上記の手順に従うと大きく2つのステップが必要となる。

  1. Accessの情報を吸い出す
  2. 吸い出した情報を使ってOracleへ移行

ツールとしては、Accessで作られたExporterと呼ばれるエクスポートツールと、MigrationWorkbenchと呼ばれるデータをインポートするためのツールを使うのだが…。なぜかExporterは表の情報をXMLファイルにエクスポートするのみ(正確にはデータをDATファイルに落とすこともできるのだが、是術した手順では使用しない。使いづらいのか?)。実際にデータを移行するのはMigrationWorkbenchがAccessに直接アクセスして移行しているようだ。表の情報を別に出力している理由が分からない。

なんとか情報を吸い出して、Migrationを実行しようとするが、ここでも注意が必要だ。
WorkbenchがサポートしているMigrationは、ユーザーやテーブルスペースが固定されてしまっている。スキーマ情報を出力したXMLファイルを修正することで変更をすることができるには出来るのだが、ユーザー名=テーブルスペース名という制限がついてしまう。
つまり、Migrationを実行するには専用の環境を用意する必要があるという事だ。

移行する時の注意点

Oracleと違ってAccessは結構なんでもありの世界になっている。テーブル設計がある程度の常識を持って作られていれば特に問題はないのかもしれないが、中途半端に”ユーザーに分かりやすく”を目指しているととても色々と出来てしまう。

  • 禁止文字の使用
    • Oracleではテーブル名やフィールド名に使う事が出来る文字列に制限がある。ところがAccessには制限が無い(もしくは緩い)ために、ここで齟齬が生じる。Workbenchではこれを自動変換して対応を使用とするのだが、これがどうもイマイチ中途半端のように見受けられる。
  • テーブルの長さが20まで
    • Oracleのテーブル名やフィールド名のサイズ長は30バイトのはずなのだが、Migrationツールで情報を吸い出すと20バイトまでしか取り扱ってくれずに切れてしまう。半角カナは2バイトとしてカウントされてしまうようだ。多くの場合は問題ないかもしれないが、フィールド名が「かえる用のフィールド1」「かえる用のフィールド2」なんてつけ方をすると途中で切れてしまって、フィールド名重複のエラーが出る

しかも、Office2007でやってみたらうまくいかなかった。うまくいかなかった原因がOfficeにあるのか設定にあるのか。このあたりは定かではないのだが、あれこれと制約や制限。出来ない事が多すぎて結局今回はOracleへの移行にWorkbenchを使用するのをあきらめ、自分で移行用のプログラムを書いてしまうことにした。

前々からそうなのだが、Oracleはあまりにもユーザーインターフェースがずさんなように感じる。パッチをあてるにしろインストールにしろ、あまりにもひどい場合が多い。
DBの性能がいいことに胡坐をかいてしまっているのではないだろうかと思ってしまう。何とかしてほしいものだ

JINS PCのその後

JINS PCを利用し始めてから2ヶ月が経ちました。

JINS PCを試してみています
http://d.hatena.ne.jp/krote/20120305/1330896902

だいぶ慣れては来ましたが、まだ気にならないという訳ではない状態です。
ちょっと疲れが溜まってくると、メガネをかけている事が疲れを倍増させているような感じがして
メガネをかけるのをやめてしまったりもします。

元々、ドライアイ等に悩んでいた訳ではない私。
つけないならつけないで問題は無いのでそのまま過ごしてしまったりもします。

いいのか悪いのか。
どうも、これが目にいいという事を実感出来ないのはメガネをかけるモチベーション(?)に欠けます。
本来は疲れている時にこそ目をいたわる意味でかけるべきなのでは?とも思うんですけどね。

何とも、何とも。

Silverlight検定

Silverlight検定なるものを「Programmable Life」さんが作成していたので挑戦してみた

Silverlight 基礎知識検定 (Programmable Life)
http://d.hatena.ne.jp/coma2n/20080623/1214229546

Silverlight 基礎知識検定
http://kentei.cc/k/11346

結果は何とか合格でしたが、簡易Webサーバーの○○っていうのは知りませんでした。。。まだまだ勉強不足ですね

あー。。。最近プログラムできてないなぁ。。。。
管理・マネジメント関連の仕事ばっかりです。いや、それはそれで面白いのですが。。。

それにしてもこの「けんてーごっこ」って仕組みは面白いですね。簡単そうだし、ちょっとしたクイズだとかに使えそう。もう少し画面サイズが大きいといいのだけど、大きければ大きいだけ背景だとか気を使わないといけないことが多くなるからまぁいいのかな。何か遊んでみようかな?

Macで戸惑っていること

使い始めてまだ3日ほどしかたっていない+使っているのは一日2時間ほどなので、やはりまだまだ慣れません。

とりあえず、現時点で「うーん」って思っていることを備忘録代わりに書いてみることにします。

ショートカットキーの違い

Windowsでは主に編集操作を行うときにはCtrlキーを利用しています。
コピー時にはCtrl+cであったり、ペースト時にはCtrl+vですね。
Macではこれらの操作にはCtrlキーではなくCommandキーを使うことになるようです。
また、ブラウザ等で最新情報に更新するときにはWindowsではF5キーを利用することが多いのですが、Macでは「Command+r」を使うようです。

また、完全に習慣として染み付いてしまっているのが漢字と英数の切り替えです。ホームポジションに近い位置にあるにもかかわらず、習慣としてApple純正のキーボードには存在しない「半角/カナ」キーを押そうとして「1」が押されてしまいます。。。。

こればっかりは覚えていくしかないのでしょうが、慣れないうちはちょっと面倒ですね。
ふむぅ

ペイント

ブログに利用する画像を、これまではペイントを利用して加工していました。GIMPとか立ち上があるの遅いし。
ただ、Macでこの役割を担っているのがなんなのかがよくわかっていません。
そもそも最初からはインストールされていなくて、GIMPなり何なりをダウンロードしてこないといけないのかな~?

これに関しては、それほどの緊急性がないことからまだ細かくは調べていない。
いいのないかな

そもそも触りきっていないので、これからも戸惑うことは数多く出てくるだろう。
実際のところの戸惑いはここに書き尽くせるものではない。戸惑いというか、なんというか。

やっぱり「知らない」ってことは大変だね。
週末に少しでも経験値をつめるようにしていきたいものです

ちょっと遊んでみた

チュートリアルも8つあるうちの6つが終了。一番最後のチュートリアルはWPFでのものなので実質的には残るはテンプレートに関する一つのみ。と言う事で、今までのサンプルで少し遊ぼうとした。下はリストのタイトル列を2段組みにしてみた

f:id:krote:20080331003238j:image

と、見てみるとエラーを引き起こしているじゃないか。

f:id:krote:20080331003235j:image

なにやらGifファイルが見つからないみたいなエラー。よく見ると、リストのうちの一つのサムネイルが表示されてない。

どうやらすべての抽出結果にサムネイルが付いているわけではないのか、サムネイルがSilverLightで表現できない形なのか。そういう事に起因しているエラーのようだ。サンプルを見返してみると、ちゃっかりLINQの所に以下の記述が追加されていた

where story.Element("thumbnail") != null && !story.Element("thumbnail").Attribute("src").Value.EndsWith(".gif")

これでOK。ちなみに、さらにいじって、ユーザ名を表示させてみた。

f:id:krote:20080331003232j:image

Listの内容をグリッドにし、1行目にさらにグリッドを追加して1行目は2列。2行目は1列のような表を作ってみた。xamlを使った表現は、なれると結構いろいろなことができることがわかる。比較的簡単に。SilverLightでは機能が少ない分動作に困ることはあるかもしれないけど、WPFでできることの多くはそのうち追加されるかもしれない。それを考えるととても楽しみである。

今月のDBマガジンが面白かった

今月のDBマガジン、特集が2つとも個人的にはヒットして面白かった

DB Magazine (マガジン) 2008年 09月号 [雑誌]

DB Magazine (マガジン) 2008年 09月号 [雑誌]

特集1 リッチクライアント技術最前線
特集2 失敗しないOracleRAC構築ノウハウ
特集3 Python開発フレームワーク

●リッチクライアント最前線
ここでは「Ajax」、「WPF」、「AIR」に対して実際にWebサービスと組み合わせたサンプルを手ほどき。Silverlightに関しては照会のみで終わっていますが、WPF自体にも興味があったのでこのサンプルはとてもうれしい。ちょっとかじってみようかしら。DBマガジン、やるじゃないか

●失敗しないOracleRAC
OracleRAC・・・。すでに失敗したことがあります。可用性という意味では非常に効果があるのはわかっているのですが、この構築。全然すんなりと行ってくれませんでした。実際にはハード側の問題等もあいまってセットアップが全然進まなかった苦い思い出があります。

今回の記事では、OracleRACを構築する上での注意点だけでなく、実際に運用フェーズに入った場合の問題点早期発見のために、何に気をつけて考えていかないといけないのか。このあたりにも踏み込んで話がされています。個人的にはハードに対する考察だけでなく、OSに対する設定だとかに関しても言及してほしかったところ。このあたりは広げようと思えばどこまでも広がる話なのかもしれないのでしょうがないところか。

Pythonに関しては・・・すいません。ほとんど知りませんでした。。。どちらかというと今から勉強するくらいならPowerShell勉強したいと思っています。

プログラマの技術尺度

まずはこちらを

技術者・SE・プログラマ面接時の技術的な質問事項(無精で短気で傲慢なプログラマ)
http://68user.blog27.fc2.com/blog-entry-41.html

プログラマー面接時の技術的な質問事項(アプレッソ版) (小野和俊のブログ)
http://blog.livedoor.jp/lalha/archives/50254634.html

キャー。やめてよして聞かないでボロが出るから。
あ、すでにボロ丸出しでしたね。すいません。

ってわけで、まともに教育を受けていないで実戦に投入された私としてはとても耳が痛い話ばかりです。いや、正確に言うと就職してからしばらくの間真面目に取り組んでいなかったことも…と、できていない理由をあれこれ述べることはできるけど、ここはわかっちゃいたけど自分の実力のなさを再認識してこれからを考えなければいけません。

課題がわかるか

両者ともに共通しているのは、WEB関連の技術が中心になっているように見えることだ。特に”無精で~”の方はそう。両者共通して.NETのかけらすら出てこないのはやはりそれぞれの会社で行っている業務がそうなんだろう。
なので言語に関する事はこの際割愛して考える。その上で、残された問いに対しての分野。特に共通して考えられていることに関しては一つの技術評価の尺度として考えられる。私自身のレベルアップはもちろんのこと、周りを巻き込むことでOJTを充実させていくことができればと考えた。
自社に閉じこもってしまうと、、、、これは中小のソフトウェア開発会社では多くあり得るのでは?と思う事なんだけど、自社で必要な内容だけで手いっぱいになってしまう可能性が高い。特に、既存アプリケーションに対しての保守や拡張を繰り返すような開発を行っていると特にその色は強くなる。
そういう意味では様々な案件ごとに技術選定を行うような受託開発を行うところは状況が異なるのかもしれない。ソフトウェア開発の多くはISVではなく受託による開発らしいので、私の考える理論は通じない可能性が高い。

では何を?

読んでみると、”無精で~”の内容はかなり細かい。いろいろなことを聞いているけど、たとえば遺伝的アルゴリズムなんて使ってるのかな?色々と疑問がわいてくる。色々な手法を使っているというよりも、技術知識全般に関してその人が何に興味を持ってこれまで従事してきたかをみたいのだろうとは思うけど。。。
ふむ。
共通点を~~って見ようとしたがそもそも共通点があまりない。言語に関係なく考えるのであれば小野氏側の内容を参考に考えていくのがいいように思える。
特にデザインパターンに関しては何となく既存のソースから読んで知っている部分はあるんだけど、ちゃんと学んだわけじゃない。というわけでまずはデザインパターンに関して勉強していこうと思う。
さてはて。どう勉強していこうか。

ソフトウェアアーキテクトが知るべき97のこと

O’REILLYから出ている「ソフトウェアアーキテクトが知るべき97のこと」を読んだ

ソフトウェアアーキテクトが知るべき97のこと
オライリージャパン
売り上げランキング: 747

珍しくAmazonが新刊を速攻で届けてくれた。つまり、予約があまりされなかったということだろう。技術書なんてそんなものだ…。

本書は、読んで字のごとくソフトウェアアーキテクトが知っておかなければいけないことや、何に注力していかないといけないのか?ということに関して数々の人がその考えを述べている。
本全体としてまとまっているというわけではなく、どちらかというと「あなたはどう思いますか?」って感じの質問に対しての解答集のようなものだ。

ちなみに、日本語訳は無いが原文はこちらにある

97 Things Every Software Architect Should Know – The Book
http://97-things.near-time.net/wiki/97-things-every-software-architect-should-know-the-book

日本語版である本書は、上記97の内容以外に日本人アーキテクトによる追加の内容11本を含んでいる

何を知るべきなのか

実際には、それぞれの立場や会社の性質。従事しているプロジェクトの内容やチーム編成によっても立ち位置は変わってくると思うので、「おー!そうだよね!!」って思うこともあれば「ふーん」と思うこともあった。
ただ、まとまっていないといっても、考えることというのは比較的似通っていて、言っていることはある程度のカテゴリに分けられている

  1. 技術を正しく把握・使うことの重要性
  2. コミュニケーションの重要性
  3. ビジネスを考えることの重要性

とってもざっくばらんに分けるとこんな感じじゃないかな?
たぶん、この人たちにとっては”ソフトウェアや技術に対する知識を持っているのは当たり前”で、プラスして何が重要かということが言いたいんだろう。技術ばっかりの頭でっかちになってはだめですよって。本書でたびたび出てくるところの「象牙の塔」ですね

  • 象牙の塔 http://ja.wikipedia.org/wiki/%E8%B1%A1%E7%89%99(Wikipedia:象牙)
    • 現実からかけ離れた夢想の世界。学者が閉じこもる研究室の比喩。ミヒャエル・エンデの『はてしない物語』にも登場する

面白いと思い、やはり悩ましいのはコミュニケーションだろう。

そんなときに必要なのは、昔から定評のあるテクノロジーです。実際、そのテクノロジーは、人類の歴史で最も重要な技術上のイノベーションです。何だと思いますか。それは話し合いです(P.6 Mark Ramm)

ソフトウェアアーキテクトをビジネスとデベロッパーの間に置くとなると、やはりこのスキルは必須になるだろう。これはプロジェクトをチームとして、会社として成功に導くためには間違いなく必要なことだ。
その割に、これにかかるコストだとか労力というものは軽視されがちで、結果としてプロジェクトはとん挫したりする。
また、もうひとつ。重要なコミュニケーションがある

ソフトウェア・アーキテクトは、どのプラットフォームの仕事をしているかにかかわらず、相互のコミュニケーションを円滑にするための手段を持たなければなりません。その手段の1つが、アーキテクチャー/デザインパターンによるコミュニケーションです。(P.84 Mark Richards)

そう。同じプラットフォーム、同じ言語で開発を行ったとしても別のチームのプログラマがすぐに他のチームで活躍できるとは限らない。仕様書が情報を知るための重要なリソースになることもあるが、プログラマであればまずソースを見ることが多いのではないか?その時に内容を理解したり、プログラムの意図や流れというものを理解するのにこれらデザインパターンというのは間違いなく威力を発揮する。
逆を言えば、本来であればデザインパターンを適用すると効果的な場面において適用されていないとすると、不必要な誤解を招く可能性まであるということだ。

私自身は、デザインパターンに対して習熟しているとはまだまだ言えない。
一人の技術者としてのコミュニケーションがとれるよう、勉強していかなければいけないと痛感することになった。

SilverLight2の情報更新

SilverLightはMicrosoftが提供するRIA技術として現在バージョン1.0がリリースされている
2.0が先日めでたくβ1のリリースを迎えたわけだが
まだまだ日本語の情報は少ない。

仕事ではちょっと使えるかどうかはわからないが個人的には気になる技術なので
少しずつ独学になってしまうだろうが勉強していきたいと考えている。
注目の技術ってやつだ

そんなわけで狭い範囲ながらも多少のアンテナを張っていたのだが
「Dan Wahlin’s WebLog」が更新されていた

Dan Wahlin’s WebLog
My SilverLight Articles
http://weblogs.asp.net/dwahlin/archive/2008/03/12/my-latest-silverlight-articles.aspx

SiverLightでのアニメーション作製においての導入部分といったところだろうか。
記事が追加されていた

Silverlight XAML Primer 11: Getting Started with Animations
http://visualstudiomagazine.com/columns/article.aspx?editorialsid=2530

記事のど真ん中にIBMのバナーがあったのだが、当然のようにFlashで作成されていた。
SilverLightのアニメーションの記事なのに~って思ったが現在のWebバナーの常識を考えればしょうがないか。

SilverLightを勉強する上で参考になるBlogとしてScottさんのブログがある

ScottGu’s Blog
First Look at Using Expression Blend with Silverlight 2
http://weblogs.asp.net/scottgu/archive/2008/02/28/first-look-at-using-expression-blend-with-silverlight-2.aspx

このあたりの情報を参考に勉強していかないといけないなぁ