ナラベルサービスβ版 開発ブログ

ナラベルサービスに関する情報発信

データベースと画像処理

開発中のシステムには,いくつか画像を取り扱う仕組みがある。書影は基本的に,openBDかAmazonを参照しているので,DBへのアクセスはない。

関係してくるのは,ユーザー登録系の画像であるが,おもなケースは2つ。1つはユーザー自身を示す画像。これはユーザー登録時にファイルアップロードから登録できる。もう1つは,配架イメージを撮影した画像。これはテーマごとに登録できる。この2つの画像の処理をDB登録とするか,ファイルベースの処理にするか,かなり迷った。

Grailsでの画像の取り扱いは,ユーザーからのアップロードをあまり考慮していない。そこはあくまでも開発者の考えに任せているというコンセプトが窺える。無制限に増える可能性があるデータの処理をフレームワーク側で対応することは無理がある。

どうしても考慮が必要だったのは,サーバリソースである。ミニマムスタートであることからメモリもCPUも貧弱になる,さらにサーバへの不要なリクエストやDBへの無駄なアクセスは可能な限り避けたいところである。また,サーバ移行の手間を極力避けたい思惑もあった。このよな要件で,結局はDB登録することにした。アップロードされた画像ファイルは,文字列へ変換してDB登録。ページ内表示は,<img src="...." />にDB登録文字列を設定。デメリットとしては文字列変換することにより容量が2割ほど増えてしまったことである。しかし,画面遷移を伴う処理でも,改めて画像データを

取り出す必要がなく(DBアクセスなし)レスポンスへの悪影響はさけられると思われる。サーバ側のメモリがやや心配であるが,当面はこの仕様で様子見である。

 できれば画像は扱いたくないのが本心であるが,利用者視点ではあったほうがよいとアドバイスを受けた。他人の視点は大事であり,感謝したい。

 

#20180406 追記

結局,画像のDB登録は断念した。調べていくうちに,コントロールしながらGrailsの機能を使って画像登録できる仕組みを構築できた。テーマに付属する展示イメージの写真を複数枚つかってスライドショー的な機能を実装したいと考えている最中に,結局DB登録をやめた。Grailsにもファイルアップロードに必要な機能は十分にあった。GrailsというかSpringかもしれないが。

 

#20180413 追記

利用者からuploadされた画像ファイルをサーバに保存する仕組みを作っていたのだが,公式Documentを見ながら作成したのにはまってしまった。送られ来た画像ファイルは

Springのクラスをつかって,ハンドリングするのだが,Jettyを使っている場合,

ファイルの保存先指定ディレクトリに自動的に不要なパス(/tmp)が追加されて

しまう。どうやらこれはJettyの実装の問題らしいが,判明するまでにかなり時間がかかってしまった。回避策はDocumentのやり方をやめて,JavaのPathクラスを使って保存すればOK.思わぬところに落とし穴はあるようである。

ウォーターフォールとアジャイルと働き方改革

すでに開発SEとしてはかなり前に引退しているが,時々昔のことを思い出すことがある。私は小規模システムの開発・運用担当者であったので,現役時代には,ウォーターフォールとかアジャイルとかなど気にしたことはなかった。現場のニーズに合わせてシステム開発し,提供してきた。ある案件では,一緒に開発するメンバーもいたが,基本的には一人SEであった。

そこで,今になって思い返すと,あの時の手法はアジャイル的ではなかったかと。

現場のユーザーのぼんやりとしたニーズに対して,必要となる機能を大まかに構成化し,モックアップ的に動かして,意見をもらう。リトライしながらこのステップを機能ごとに繰り返しながらシステム構築を進めていく。確かに言葉にするとアジャイル的である。だが現役の時には,まったく意識したことがなかった。経験則的に,しっかりと筋道を立てて開発するよりは,柔軟性を重視して身軽に開発する方がよいシステムが生み出されると知っていたのだろう。今思えば,かなり無理な働き方をしていた気もするが,あの経験は私の土台になっているのだろうか。

 さて,話は変わって働き方改革である。日本の労働市場における流動性の問題は予てから指摘されているものであり,今でもそれは変わりがない。仕組み良し悪しの問題ではなく,結果が思わしくなければ当然,その仕組みは評価されない。そこで働き方改革である。職能給から職務給へ,同一労働同一賃金。これはソフトウェア開発においては,ウォーターフォールからアジャイルの転換に類似していないだろうか。欧米ではシステム開発アジャイルが主流となっており,さまざまなツールやフレームワークアジャイル的なアプローチができるものばかり。しかし,日本はいまだにウォーターフォール型開発が多くの案件を占めているという。これも流動性の問題と同じように,結果がその仕組みを評価するというシンプルなルールに乗っ取れば,この変化が日本にやってくるのは当然の帰結である。モノづくりの中から満足感を得たいというモチベーションが組織の変化をリードしたのではなく,政治的な取り組みから半強制的に変化が作り出されていることにちょっとした躊躇いはあるが,変化は概ね長期的スパンになるほど好ましい結果を生んでいると評価されるので,これからどのように変化に対応していくか見守りたい。SEを引退したと言えども組織の一員であることは変わらないので,個人的にもうまく新しい流れにフィットしていかなければならない。

 モノづくりへの情熱は,どこからくるのか,それを知りたいといつも思ってる。

2018年始動

 2018年が始まった。この記録を残し始めてから2年が経過した。当初の予定では,2017年中にはサービスインであったが,まだ開発中である。これは本業が多忙であることが最大の理由であるが,新たな年を迎え,自分のモチベーションが低下していないことを確認できた。自分自身では,必ずサービスインまで持っていける自信がある。

 さて,そうは言っても休日の個人開発である。ニーズがあるかどうかもわからないところにサービスを展開する訳で,上手く役に立てるようなシステムになるかどうかはまだ未知数である。システム開発フェーズから運用フェーズに移行したら,それはまた開発とは別の楽しさがある。利用してもらえる嬉しさ。それは開発SEとして何物にも代えがたいものではないだろうか。

 

 技術的には,運用時におけるインフラ的な課題が一つあげられる。前の記事でも取り上げたDockerについても,すでにK8sが主流となると言われ始めている。この辺りについていく必要はおそらくシステム規模的にもないと思うが,純粋に技術的な興味としてもう少し深堀したいところではある。すでにAmazonとの連携部分はほぼ実装できてうるが,openBDをどのように活用するかが悩ましい。ここは考えどころか。図書館サービスとして考えた場合にはopenBD一択なのであるが,利用者視点からはAmazonが優位なのかと思う。この辺りは割り切りの問題であろうか。

 開発環境は,変わらずGrailsである。日本でのマイナー感は相変わらずであるが,流石に新しい環境に移行することは考えられない。フロントエンド開発的なアプローチもあるのかもしれないが,まずは枯れてくれないと手がだせないというのが本音だ。

 

 資金が流れない=ニーズがないWebサービスは,淘汰されるのはしかたのないことであるが,ニッチなところは結局営業ベースというよりは,個人的なサービスが隙間を埋めていくことになる。それは個人の楽しみ=利用者の利便性のイコールバランスの成立がカギであることは当然である。作っても使ってもらえない,作ったけど過度な期待を受けてしまうとなっては,微妙なバランスは保てない。いろいろ考えることはあるが,まずは動かしてみる,そういったシンプルさが,実は日々の鬱屈感の払拭には最も効果があるのかもしれない。

今年も仕事があり,開発ができることに感謝し,日々を過ごしていきたい。

 

サーバ監視を考える

久しぶりに時間ができたので,気になったことを2日続けて書き残してく。

サーバ監視は,現役時代はほぼ自力だった。ベンダーがサーバの死活監視ツール

だけは仕込んでくれたが,サービスレベル。プロセスレベルはフィールドSEが現場でスクリプトを書くレベル。でもこれで十分だった。牧歌的な時代でもある。

 

さて,現在のデファクトでは,サービスは様々なツールを使って自動監視,自動運転が基本らしい。いろいろと記事を読むが,まだピンとこない。Zabbix は名前だけ聞いたことあり。だが使ってみたいとはあまり思わなかった。導入するならこちら。

Mackerel サーバ監視[実践]入門

Mackerel サーバ監視[実践]入門

 

はてなのサービスとのこと。開発・運用サーバはIDCFクラウドの予定であるが,追加料金で使える。これは便利そうだ。

だが実際は,どのようにサービス用の環境を設計するかによって死活監視も変わってくるはずなので,まずはDockerから始めなければならないのは分かっている。

最近,本業が落ち着いてきたので作業できる時間が 増えてきたが,昔のような集中力がなく,ソースにフォーカスできる時間があまりない。集中力がきれて,調べものを初めてしまったり,突然死活監視を考えてみたり。これも休日開発の楽しみと思って,あまりカリカリしないようにしている。

qiita.com

このあたりとか,

speakerdeck.com

このあたりで少し勉強。ちなみにZabbixは

 

Zabbix統合監視「実践」入門 ~障害通知、傾向分析、可視化による省力運用 (Software Design plusシリーズ)
 

 これで少し概要をつかんでみた。

 

またサービスもできていないのにサーバ監視でもないが,忘れないうちに。

 

 

 

Dockerを考える

 まだ開発中ではあるが,Dockerを調べ始めた。

Docker実戦活用ガイド

Docker実戦活用ガイド

 

 開発環境は,PCで基本VmwareUbuntuを仮想で起動して行っていた。しかし作業を継続していると,徐々に環境のずれやリソースの問題が気になるようになってきた。現役時代は,まだ仮想化技術も出始めで,Dockerはまだリリースされていない。

 

いろいろと記事を読みながら,Dockerのメリット・デメリットも大分理解できてきたので,手を動かしてみたいと思う。個人開発・サービスには常に環境とコストの問題が付きまとうが,サービスリリースの時にもDokcerを使って運用できれば,コスト圧縮にもつながるように思える。

ただし,ただDockerを使うだけではダメで,CoreOSやAtomic Hostのようなコンテナ専用OSの利用も含めて考えていく必要があるであろう。

 

このあたりも,併せて動かしていきたい。時間がないのが最大の課題であるが,新しい技術はやはり楽しいものだ。コンテナを中心にデプロイ関係や管理関係ももう少し調査・実践したいと思う。

 

 

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との生存競争に向き合う中,図書館はどこへ向かうのだろうか,興味は尽きない。だがきっと,すべて良い方向に向かっていくと信じている。