リブショカ(図書館書架)β版

リブショカ(図書館書架)に関する情報発信

grails3.2.Xのアプリケーションをjettyへdeploy

久しぶりの技術関係,かなり手間取ったので備忘録的メモ。

 

現在開発中のWebアプリはApache+TomcatからJettyへとコンテナを変更する予定である。

これまでJettyは未経験。実装するサーバがミニマムであることから,リソースを節約

できる点を評価してJettyを選択した。Jettyのインストール自体はBinaryをDownload

して適当なディレクトリに配置するだけなので,割愛。

 

Webアプリの基礎ができた段階で,grails prod warでDeploy用warファイルを作って

tomcat7で稼働を確認していたが,jettyにデプロイする前に現状のwarをTomcat7で試すことにした。

 まずはOracle8へバージョンアップ。これはJettyがJava8だったため。これが

問題の始まり。grailsにはopenJDK7を使っていたので,grailsもTomcat7もOracle8に

たことによって,開発環境とDeploy環境で大きさ差ができた。これによってtomcat7

へのDeployでエラーがでるようになる。この部分については,Grailsのドキュメントで

回避策が書いてあったので,対応を施す。具体的には,build.graidleを修正

2 Getting Started 3.3.0

 

これでtomcat7でのDeployができたので,次はJettyへ.しかし,Deployはうまくいった

ように見えるが,実際はWebアプリとしてではなく,単に静的コンテンツとして

認識されているようである。最初に疑ったのは,Web.xml。grails3からはweb.xml

作成しないようになったので,これが原因かと考えた。Jettyのドキュメントには,

web.xmlは必須となっていたので,さらにこれが原因かと思えたが,よく考えれば

grailsのドキュメントには,grailsから生成されるwarはほとんどのサーブレット

コンテナでDeployできるとなってるのだから,そこを疑うのは間違っている。このあたりのカンが鈍ってしまうのは,現役リタイアなのでしかたがないかと思う。

結局,原因は複数であった。

 

 1)grails3.2.0ではwarの生成時にバグがあり,grails3.2.1へ更新する必要があった。

 2)grails3.2.9へ更新したが(SDK),これだけではbuild.gradleは更新されないので,ダミーのプロジェクトを作って,そこからbuild.gradleをコピーして,必要部分を追記した。

 3)スタートアップ用の組み込みコンテナがtomcatだったので,これをjettyに変更した。(build.gradle)

//*** stop  tomcat 
//compile "org.springframework.boot:spring-boot-starter-tomcat"

//*** add jetty 
compile "org.springframework.boot:spring-boot-starter-jetty"

 

    4)logback.groovy実行用のjarが不足するので,build.gradleに追加

         runtime 'org.codehaus.groovy:groovy-all:2.4.10'

 

これでどうにかDeployできた。1)まで行きつくのが早かったが,その先でこまった。2)については,てっきりGrailsの更新によって自動的にbuild.gradleも更新されるのかと思い込んでしまったのがいけなかった。

jettyについてもメモ。じつはjettyがいちばん曲者だった。

jettyそのものは,/usr/local/jettyに配置したが,ドキュメントでは,jetty稼働は別のディレクトリで行えとなっている。そのために,jetty_homeを設定するようだ。

で,実際にjetty.homeを設定してユーザーディレクトリから起動したのだが,

Webアプリを認識しない。/usr/local/jetty/bin/jetty.shを/etc/init.d/jettyにコピーして

これを実行するとダメ,しかし,/usr/local/jetty/bin/jetty.shで起動するとちゃんとWebアプリを認識する。これがよくわからない。現在も調査中。設定ファイルは.jettyrcとして起動するユーザーのホームディレクトリに配置して,ちゃんと環境変数等も設定できているので,問題ないと思われる。配布バイナリにはいっているstart.iniもちゃんと実行環境にコピーしているが,なぜか/usr/init.d/jettyではうまくWebアプリを認識できない。ここの部分の切り分けができずに,grailsに原因を求めたことから,無駄に遠回りした。

 

久しぶりに開発関係の作業だった。うまくいかずにかなり四苦八苦したが,終わってみればやはり楽しかったと思い返す。もう少し,まとまった時間がとれるとよいのだが。

 

本業の都合もあり,なかなか進捗しないのが悩みの種である。

 

 

 

Amazonとカーリルと書誌情報

カーリルから以下のアナウンスがあった

サービスに関する重要なお知らせ – カーリルのブログ

 

これまでメインで使っていたAmazonの書誌DBからオープンな書誌DBへの移行を随時行っていくとのこと。当面は,Amazonアソシエイト契約の解除はないとのことだが,どこかで書誌DBのスイッチは避けられなかったと思う。先手を打って,

openBD | 書誌情報・書影を自由にを始めていたのは素晴らしい。前の記事にも書いたが,このような活動にはエールを送りたい,かつ微力でも力になれればと思う。

 

最近は本業が多忙のため,すっかり開発ペースが落ちてしまっているが,そろそろAmazonAPIに手を付けようとしていたところなので,実装を少し変更しようかと考えている。書誌情報を取得できるリソースを複数利用できるようにして,可変機能として実装するように仕様変更の予定。

 

さて,自由に利用できる書誌関連DBが動き始めるのは非常に素晴らしい。しかし一方で,本当にAmazon並みの情報量が確保できるかについては,懐疑的な部分もある。

 多くの人々が,Amazonが提供する情報量をデファクトとして認識しているように見えるが,これは何も書籍に特化したものではない。すべての商品について言えるのではないか。Amazonの情報量がデファクトとなっているのであれば,どこのサイトであれ,情報量が少なければ利用者は自ずとAmazonサイトへ移動して不足している情報を補おうとする。書籍でいえば,例えば書影,目次,コメントなど。多くの図書館目録検索ではこれらの情報は非常に少ない。それゆえ,Amazonで資料を探す→図書館検索で所蔵を確認する,の流れになることは多いであろうが,カーリルを使えば検索コストは大幅に省かれる。ゆえに,カーリルとAmazonの関係性の変化は,図書館とAmazonとの関係性の変化でもある。

 

 カーリルという素晴らしい仕組みを前にして,図書館の役割を再定義する必要はないのだろうか。図書館とAmazonは直接的には触れ合わない,お互いに向き合わない関係性なのだと思う。橋渡しとしてカーリルがある,そう考える図書館員も多いのではないか。多くの書店がAmazonとの生存競争に向き合う中,図書館はどこへ向かうのだろうか,興味は尽きない。だがきっと,すべて良い方向に向かっていくと信じている。

 

悪癖と反省と改善

例年恒例の春先のバタバタ中でも,小刻みにソースを書いていた。進捗はわずかであるが,開発を継続できているのでよしとしている。PGに費やせる時間はごくわずかなので,おのずとソースを眺めて,一行も書かずに,これまでのステップを復習することだけで終わる日も多々ある。

 そうやっていると自分の手のクセというか悪癖というかいろいろと見えてくる。20年以上大なり小なりの開発をやっている中で,現役時代は無意識に逃げていたであろうものだ。その一つは,デフォルト機能よりも自分が過去に書いたクラスや関数を多用してしまうこと。タイトな開発スケジュールだとどうしても稼働実績のある自作クラスに頼りがちだったことは否めない。引退した今であればこそでもある。

 domain class での処理が一例。本来であれば,domain classのmethodを使い,エラーをださせて処理すべきであるが,エラー処理を簡略化するためもあり,domain classを利用する前に,登録用の前処理をしてdomain classが想定されるエラー以外を吐き出さないようにしてしまっていた。だがこれは間違っている。特に自作クラスで処理していたのは,domain classと登録用データのbindの箇所。型変換やarrayなどの部分はアノテーション等を使わずに,登録前に自前のクラスで処理していた。ここは改善ポイント。

 このようにデフォルトよりも自作クラス優先は,フレームワークへのアプローチをミスしていることが根本的な問題点だと思う。本当に基礎的な部分でり,時間があればもう一度このあたりを勉強し直したいと思う。昔は何でも自分で作る=車輪の再作成的な文化が充満していた。これはこれで意義はあったので,そのクセが今になっても抜け切れていない。反省と改善。引退してしまった今だからこそわかる悪癖。それもこれまでのPGとしてのキャリアの一部であることは確かではある。

openBD 始動と基盤APIの選択

openBDのキックオフが先日あった。都合により参加できなかったがかなり熱があるものだったようだ。それは十分理解できる。現役時代に望んでいたサービスが鼓動を始めた。嬉しい限りだ。

openBD | 書誌情報・書影を自由に

 

さて,現在開発中のWebサービスで基盤データサービスとして候補に挙げていたのは,AmazonAPIとPortaである。どちらか一方ではなく,AmazonAPIをプライマリ,Portaをセカンダリというイメージだった。やはり書影データを使えること,アフェリエイトがあることが大きい。書籍に係る広告報酬はデータを登録してくれた利用者のためのもので,このサイトの運営維持費の捻出は,google系の広告を予定している。

さて,openBDであるが,期待は高まるが,調査しなければいけない部分もありそうだ。今回のサービスは,

 1)図書館員の業務補助ツール

 2)利用者サービス

の2つの目的としているが,どこまで取得したデータを加工して渡せるかについては,特に確認の必要があるだろう。また収録範囲や収録項目についても調査が必要だ。

 

キックオフでは,API開発を担当したカーリル社の方が,データ流通としてのXMLはダメ的な発言があったそうだが,これは同意。たしかに,XMLは素晴らしいしなんでもできる。一方,非エンジニアや図書館員にとっては,あまりにも難解すぎて利用する気すら起きなくなってしまっている。書誌データ構造は確かに複雑であるが,XMLで記述できるからといって際限なく複雑化するのではなく,2次利用しやすいという視点からある程度制限的な記述であることが望まれると考えていた。その点,JSONはいい制限加減なのである。データハンドリングもよい。

本題に戻るが,思想的な部分ではopenBD一択である。今回開発するWebサービスが少しでもopenBDの普及に役立てれば本望だ。だが一方でAmazonAPIで提供されるデータ量や質の問題を無視するわけにもいかない。どのデータソースを使っているかは,利用者にとってはどうでもよいことであろう。

もう少し,調査・検討してみるが,openBDをプライマリ,セカンダリをAmazonAPIとするのが第一か。また,調査してみるとカーリルAPIが素晴らしい。図書館として利用者登録してもらった場合には,なんとかカーリルAPIを使って,入力の手間を減らせればと思う。

なによりopenBDの登場により,さらに本と読者がつながることになるのは素晴らしい。図書館はこの流れに取り残されてはいけない。

 

openBDへの賛辞とエールを込めて。

 

2017年始動

すでに1月も半ばであるが,ようやく開発を再開できた。本業につられて開発がたびたび遅延するのは,いたしかたない。ブランクが長くて,頭の中に残しておいた工程やアイデアが消えてしまったので,もう一度やり直しである。

 

何事もない新たな1年の始まりであるが,今年は必ずこのサービスを公開させると決めている。本業とサブ,相乗効果を得られればベストだ。

 

休暇中は,これまで溜めていた技術系のブログを読んだり,サービス構想を考えたりして過ごした。現役時代はそんなことをできる余裕がなかった。

だが,引退したからこそ雑多なことから解放されて開発だけに集中できるのでこれは,良い環境ともいえる。

 

今年もないもないことが一番である一年であってほしいと切に思う。

年末

この記事を読んで、考えるところがあった。

 

qiita.com

20数年前、この業界に入っての最初の関門がEmacsコンパイルであった。

当時使っていたメイン開発サーバは、Solaris1.X系だったが、Xのコンパイル

数時間、Emacsコンパイルでも数時間必要だった。makeして結果が出るまで、

タバコを吸ったり、コーヒーを飲んだりして時間をつぶしていた。当然、

その時にも、make logは見ていたたが、ただ止まらないことを祈っていた。

 

そんな時間が過ぎて、本格的にコードを書き始めるとEmacsとの付き合いは

親密になる。完全に使いこなしていたかはかなり怪しいが、Emacsがなければ

まったくコードを書く気にはなれなかった。小さな職場の小さな開発部隊には、

当時出始めた統合開発環境すら導入には至らずに、ひたすらEmacsでの

コード書きに専念した。現役中にStratusで3つのWebServiceをリリースして

いるが、すべてEmacsだけで開発した。これは、当時の職場が複数人で開発

できるほどの予算も規模も人員もなく、最小コストで必要な機能をすべて

そろえなければいけない環境にあったからというのが最大の理由である。

 

そのEmacsが存続の危機に立たされている。現在開発中のサービスも、当然、Emacsを使って開発中である。Serverを立ち上げたときも、最初に入れたパッケージだった。

Emacsは素晴らしい。凡人にはその素晴らしさが理解できないほど素晴らしい。そしてその開発にコミットしている開発者は、ある意味、別世界の人たちである。私のような平凡な開発者が近づけない存在。31年も続くツールをメンテナンスし続けている。

 

で、結局、休暇中にEmacsからAtomへ移行した。思い切って20年間使い続けていた開発環境を捨てた。それはおそらく、Emacsの本当の素晴らしさを理解できなかったからできたことであろう。

これからもEmacsは素晴らしさを増しつづけて平凡なSEを引き付けていくだろう。同じように、Emacsを使い続ける平凡なSEにはEmacsは手に負えない魔法のようなものだ。

 

Atomへと移行したのは機能的な要求に基づくものではない。Emacsでの開発で何の問題もなかった。Emacsの開発が停止するなど疑いもしていない。面白そうだからちょっと、触ってみようなというのが第一の理由。引退した自分に、そんな感覚が残っていることに少し自分でも驚いている。

 

結局、モノ作りは楽しいってことのようだ。それは平凡でも天才でも変わりないと信じたい。

サービスと技術,フロントとサーバ

 引退したとはいっても,やはり新しい技術は気になるし,試してみたい。現役の始まりは,汎用機だったが,すぐにクラサバがやってきて,気が付いてみればサーバ系の開発SEになっていた。最初はperl,そのあとにいろいろ試して,現役最後はstrutsがメインだった。その後,grailsに手を出し始めて,現在に至る。現役時代には,フロントサイドでの開発は,齧りもせず,なめる程度だった。jQueryを使い始めて,すぐに引退。

 最近は,フロントでの開発話がよく取り上げられているようだ。正直,全くイメージが湧かない。現役時代,IEjavascriptに散々な目にあわされた旧世代としては,仕方がないのではないか。でも,もしフロントサイドで開発できたら楽しいだろうな,いろんなアイデアが出せるだろうなとも思う。

 

 それでも,使ってみようかとはならない。現役では許されないことも引退してしまうと許せてしまうのが,良いこと。自分を甘やかせるということか。結局,フロントでもサーバーでも,ユーザーにとっては劇的に何かが変わるわけではないのであれば新しい技術だからといってコストをかける必要性がない。

 これは将来性・継続性もないということとイコールかもしれないが,サービスとして継続していければ,技術的革新性・適切性の問題はどうにでもなるでしょう,と安穏と構えてしまうのも,引退したSEの気楽さゆえに違いない。

 

 願わくば,今回開発するサービスが軌道に乗り,サービスサイドからの必要性により新たな技術を求め,そして見ず知らずの若いSEが同一目的の更に優れたサービスを開発する,となって欲しい。

 

 サービスが生き続けるためには,世代を越えなければいけないし,そのためには若いSEが魅せられる新たな技術が必要だ。サービスと技術は両輪である。これは引退して改めて実感したこと。現役時代も分かっていたはずなのだが。