もぎの部屋

個人の感想を書くLife&Techブログです。

技術メモ『Play Framework:外部jarの読み込み方』

概要

最近仕事でPlay Frameworkというものを使うようになりました。
Javaの改修なのでEclipseを使っています。
今回はサードパーティー製のjarライブラリを使おうと思ったのでビルドパスに追加したのですが、うまく読み込めずハマったのでメモ。

事象

外部jarの読み込ませ方として、Eclipseのプロジェクト-ビルドパスの構成からjarを選択すれば、そのライブラリは使える認識でした。
今回も外部jarにビルドパスを通したので、Eclipse上でそのライブラリをインポートすることができ、特にエラーは出ませんでした。ところが"sbt compile"をすると

パッケージhogehogeは存在しません

.classpathファイルにもちゃんとjarは追加されているし、謎でした。

解決策

Play Frameworkはbuild.sbtにそのライブラリ情報を書かないといけないことがわかりました。
libraryDependenciesという項目があるので、ここにjarを追記していきます。
例えば、google apiならこんな感じ

libraryDependencies ++= Seq(
  jdbc,
  cache,
  "com.google.apis" % "google-api-services-plus" % "v1-rev557-1.25.0"
)   

この記述方法は、こちらのサイトで検索できます。
Maven Repository: Search/Browse/Explore
ライブラリを検索してバージョンを選択すると、sbt用の書き方が見れるので、そいつをコピペすればオッケー。
この後にコンパイルしたら無事通りました。

他にも外部ライブラリはたくさん読み込んでいるんだけど、build.sbtに記述してあるのはそのうちの数個だけだった。そのへんの分け方はどうなっているんだろう?
あと、そもそもMavenがなんなのかよくわかってないから調べよーっと。

技術メモ『Python:venvを用いた仮想環境構築』

概要

プロジェクトの独立性を担保するために、Pythonの仮想環境を作る。
venv以外にもvirtualenvやpyvenvといったものがあるようだが、今回はvenvを利用。
venvはPython3.3から追加された標準モジュールである。 pyvenvは現在非推奨。

※参考 28.3. venv — 仮想環境の作成 — Python 3.6.5 ドキュメント

venv環境の作成

$ python3 -m venv [ディレクトリ名]

venv環境の有効化

$ source [ディレクトリ名]/bin/activate

もしくは

$ . [ディレクトリ名]/bin/activate

これを実行することで、ターミナル表記の先頭にディレクトリ名が表示される。

(ディレクトリ名) $ 

venv環境の無効化

$ deactivate

デスクトップ環境のご紹介

これは完全に趣味の世界なのですが、最近デスクトップ周りを整備したのでご紹介します。
f:id:mrmomoca:20180831212452j:plain:w500

PC:MacBooc Air

好きです。

マウス:Magic Mouse 2

Apple純正のやつ。タッチパッドと同じ操作を行えるところがよい。

キーボード:バッファローMac対応やつ

キーボードもMac純正にしようか迷ったけど、結構高いしなぁと思ってバッファローの有線タイプにしちゃいました。僕はキーストロークが浅いやつが好きなのですが、このキーボードは浅くて打ちやすい。なんならもっと浅く作って欲しかったな。MacBookAirの浅さがベストなのよ。
あとテンキー、個人的には不要なんだけど、矢印キーとかpageup,downキーとかは独立して合って欲しいのよね。でもそういうタイプはなかったのでテンキー付きで我慢。

ディスプレイ:HP 24fw

HPで結構しっかりしているやつなんだけど、セールやってて相当安く買えた。やっぱり開発とかするのにMacBookの画面だけじゃ厳しいのよね。マルチウィンドウは正義。

まとめ

かなーりしっくりきている。
Macの白をベースにしたかったので、キーボードもディスプレイも黒くないやつにしました。
快適な環境が整ったので、一層勉強に勤しみたいと思います。

『まんがでわかるLinux シス管系女子』読書メモ

まんがでわかるLinux シス管系女子 / Piro 著

f:id:mrmomoca:20180821234720p:plain:w300

シス管女子との出会い

ほんの数週間前はLinuxなんて触ったことがなかったのですが、転職してからバリバリ使うようになってしまいました。当初知っているコマンドは「ls」とか「mkdir」くらい。Linuxで何ができるねん?GUIベースでよくね?って感じでした。
当然使い方もわからず、何かコマンドを打つにしてもその度ネットで調べていたのですが、本格的に勉強しようと思いLinuCを取ることを決意。ひとまずLinuxの参考書と問題集を書いました。
これとは別に、友人にLinuxでオススメの本を聞いたところ、この「シス管系女子」を教えてもらい、せっかくなので読んでみることに。

感想

僕も大野さんみたいな先輩が欲しいです!って感想は一旦置いておき…
ある目標(例えば、logファイルからある文字列が含まれている行を取得するみたいな)があり、それを実現するための手段を詳しく、キャラクターの会話ベースで教えてくれるので、飽きる事なく楽しく知識を得られる点がいいと思いました。
個人的には全くのLinux初心者よりも、Linuxの参考書とかをさらっと読んだ後にこの本を読むのがいいんじゃないのかと。参考書を読んだ時に陥りがちな「知識は入ったけど、実際にどういう場面に使えるんだ?」っていう現象のアンサーになり得る本だと感じました。grepの例とかわかりやすかったですねー。
逆に初めて知るような内容については、?になる部分もありました。この辺りは私の知識不足ですね。参考書と合わせて理解を深めます。
時間がある時に2と3も読んでみたい。

ところで、LPI-JapanがLPICなんかやってらんねぇ宣言出しましたね。

LPIC取り扱い停止に関するお知らせ(https://lpicj.org/201808.html)

まぁこだわり無いんでLPICでもLinuCでもどっちでもいいんですが。
ちゃんとした資格なので運営も頑張っていただきたい。

『実践Javaコーディング作法』読書メモ

実践Javaコーディング作法 / 森崎雅稔 著

f:id:mrmomoca:20180812162149j:plain:w300
2014年に発刊されたJavaのコーディング作法について説明している本です。
SIerで2年ちょい働き、最近Web系に転職したばっかりだけど、恥ずかしながら今までちゃんとした開発経験ってないんですよ。
Javaに触れる機会って多かったけど、実装したのってなんだかんだ言って社会人1年目にやった研修くらいな気がする。
今の会社ではJavaもゴリゴリ使うので、これを読んで記法などについて勉強しました。
この本に記載の内容もあくまで一例として捉えた上で、私の疑問や気づきなどを書いていきたいと思います。

気になった点

単語の単数形と複数形で区別しない

複数形と単数形で区別することは紛らわしいため、避けた方がいいと。 例えば、

  • salesOrderDetail
  • salesOrderDetails

は同時に使わない方がいいと述べています。 これについては少し疑問で、例えば複数の伝票をまとめた配列を複数形、そのうちの一件を扱うときは単数形で宣言するのはいいんじゃないのかなぁと思います。直感的にもわかりやすい書き方だと思うので。

thisを使ってフィールドの隠蔽を回避する方法は推奨されない

フィールドの変数名と、引数で受け取る変数名の衝突を回避する方法として、引数名の先頭に冠詞「a」や「an」をつけると一目で引数であることがわかるため、可読性が高いと言えるとのこと。thisは自動生成の機構を単純化するために利用されているのであって、積極的な使用は推奨されない。
これも疑問。thisってめっちゃわかりやすくない?フィールド変数を使っているよって一目でわかると思うんだけど。逆にaとかanの方がわかりづらい…

クラスのtoStringメソッドを装備する

業務アプリケーションの要となるクラスに対して、publicなtoString()メソッドを標準的に実装する習慣を持ちなさいとのこと。これのメリットとしては、System.out.println(object)と書くだけで、いつでもその中身をプリントできることらしい。
ログや例外で、オブジェクトの情報を簡単に出力できるようにしたいってことだと思う。 意識したことなかったなぁ。toStringって、数値とかを単純に文字列変換するときに利用するイメージだった。

感想

コーディング規約って当然現場によって違うと思うけど、大体はこれに従うといいのかなぁって感じ。日常的に読むって言うよりは、プロジェクトが始まる前の規約作成の段階で熟読するべき本なんでしょうね。
私の前の職場のコーディング規約なんてガバガバだったから、結構参考になりました。
内容的に???ってなる部分も多かったけど(Stream APIとか循環的複雑度)その辺はおいおい調べていきます。

『UNIXという考え方』読書メモ

UNIXという考え方 / Mike Gancarz著・芳尾 桂 監訳

f:id:mrmomoca:20180806235351j:plain:w300
私は大学が情報科だったくせに、UNIXLINUXわからないマン。
ターミナルでlsしてcdしてmkdirして〜くらいの知識しかないのです。
この辺りの知識をつけたいなぁと社長に相談したところ、この本を勧められたので読んでみました。
UNIXにおける考え方を9つの定理とし、それぞれの定理について解説をしていく内容です。

UNIXの考え方 9つの定理

【定理1】Small is Beautiful(小さいものは美しい)
【定理2】1つのプログラムには1つのことをうまくやらせる
【定理3】できるだけ早く試作を作成する
【定理4】効率より移植性
【定理5】数値データはASCIIフラットファイルに保存する
【定理6】ソフトウェアの梃子を有効に活用する
【定理7】シェルスクリプトを使うことで梃子の効果と移植性を高める
【定理8】過度の対話的インタフェースを避ける
【定理9】全てのプログラムをフィルタにする

響いた内容

目的に関わる本質的な作業は小さい

単純にファイルをコピーするとき、ユーザにコピー元ファイルを尋ね、元ファイルの存在チェックをし、コピー先ファイル名を入力し、同名ファイルが存在する場合上書きするか尋ね・・・と、手順を書くと結構な量になる。しかし、コピーをするという作業をごく一部で、ほとんどの作業はコピーとは本質的に関係がない。
ファイルのコピーのみを実現する場合、必然的にプログラムは小さくなる。ファイル名入力や存在チェックは、また別の小さなプログラムから呼べば良い。
作業の目標ごとにプログラムを分けるイメージかな。

しのびよる多機能主義

クリエイティブさが新機能や新しいオプションをつけてしまう場合がある。この拡張は役に立つものもあるが、本当にそのコードが必要なのかは意識するべき。
実際の現場でも、こうした方が使い勝手いいな〜とか思ったりするけど、それがお客さんにとって本当に必要かどうかは考えなきゃいけないよね。

ソフトウェア開発に終わりはなく、リリースがあるだけ

これはなんと言うか、単純にセリフにドキッとした。ソフトウェア開発の面白さでもあり、恐ろしさでもある。

90%の解を目指す

100%の解を実現することは困難だが、一番難しい10%を無視して良いのであれば世界中のほとんどの問題はすぐに解決できるという考え。
UNIXの思想はこれに基づいていて、90%のニーズを満たし、残り10%はユーザにまかせるんだって。これが成功の一因。 そもそもソフトウェアに100%って無理だよね〜。求めてる機能は人によって違うし、システムが止まることだってあるじゃない。
大体最近の日本人は100%を求めすぎでしょ。この考えで過ごせば優しい世界。寛容になろうぜ。

感想

技術書ではなく、あくまでUNIXの成り立ちや思想について記載されている。
UNIXの知識がほぼない状態で読んだが、思想としては現在の設計と似ているところは多いなぁという印象。 何か大きな発見がある本ではなかったけど、UNIXの入りの本としては良いのではないでしょうか。