読者です 読者をやめる 読者になる 読者になる

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

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

悪癖と反省と改善

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

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

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

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

domain classとvalidate

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

 そうやっていると自分の手のクセというか過去のソースの引きづりがおのずと見えてくる。20年以上大なり小なりの開発をやっていると現役では気づかないが悪い癖があちらこちらで見つけられる。その一つは,デフォルト機能よりも自分が過去に書いたクラスや関数を多用してしまうこと。タイトな開発スケジュールだとどうしても安定感のある自作クラスに頼りがちだったことは否めない。引退したいまであれば,それがどれだけ無駄なことか良くわかる。今になって反省することたびたび。

 で,その一つがgrailsのdomain class validateである。どうしてもエラー処理は煩雑になりがちで,発生したエラーをどうやって画面に結び付けていくかは悩ましいところである。そこで発生したエラーを画面に伝えるための処理を独自に書いてしまっていた。このクラスは,かなり昔から使っていたもので,現役を引退したあともこまごまとメンテナンスしながら使っていた。だが,いま考えれば,可能な限りデフォルトの機能で要件充足させて,どうしても不可能な部分のみ自作とすべきであった。上記の例だと,画面への受け渡しの部分だけは,独自にcontroller側で処理し,データのvalidate

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が魅せられる新たな技術が必要だ。サービスと技術は両輪である。これは引退して改めて実感したこと。現役時代も分かっていたはずなのだが。

twitterアカウントとの連携による認証

今回のシステムでは,独自認証は基本はなし。twittergoogle+アカウントでの認証処理とする。

まずは,twitter認証。twitter4jがライブラリとしてあるので,これを利用。調べた感じでは,枯れていてよさそう。

 

認証+tweetだけなので,あまり複雑なことはしない。手順としては,

 

 1 twitterで作成したサービス(URL)と登録

 2必要なキー等を取得

 3サービスでの実装

 4テスト

 

ぐらいな感じでOK。詳しくは,本家サイトを確認

Twitter4J - A Java library for the Twitter API

認証周りはgitにあるサンプルを写経すれば,ほぼ動く

GitHub - yusuke/sign-in-with-twitter

 

ポイントは,callback関数での処理。どの項目をtwitterから返されたオブジェクト

から取得して,処理をするのか。項目取得のメソッドはJavaDocで確認できる。

 

今回は,ID(数字だけ)とScreenNameを取得。これはDBに登録する。

一方,tweetに必要なaccessTokenはDB登録しない。セッション間だけで

保存する仕様とする。万が一,DBがクラックされた場合のことを考えて。

できるだけ,サーバに保持するデータを少なくして,軽く動かして,漏えいリスク

を回避したい。

 

実装自体は,小一時間でできる。サービスの登録なども簡単。テストできるまでは

おおよそ1時間半程度か。

 

ただし,twitterは今後の先行きがちょっと不安。仕様変更のキャッチアップも

ちょっと億劫だが,そこはいろんなこととトレードオフなので。

今回のサービスはtwitterとの連携が一つのポイント。ターゲットである図書館や

図書館員はtwitterで告知などを行っていることがほとんどなので,そのあたりを

今回のサービスで内包できれば,利用者取り込みに効果があるかと思われる。

 

次は,google+での連携予定。facebookは連携なし。LINEは連携できるのだろうか。

普段,全くLINEを使わないので,見当もつかない。このあたりが,現役引退SEの

気楽なところだろうか。