日々雑感的な日記

思ったこと考えたことを書いていく。IT系の話題が多くできればいいな

Kotllinでウェブアップ開発で思ったこと

概要

Kotlinでウェブアプリケーションを作るきっかけがあったのでそのことについて感想を書く。

背景

開発を始める私の状態は以下のようだった。
・JavaおよびJava EEについて学習中でSpringは学習したことがないし、業務としてJavaは縁がなかった。
・GlassFishは何回か勉強で触っていたがあまり印象がよくなく、あまり触らなかったがWildFlyの方が開発が進んでいるという印象を持っていた。
・Kotlinについては触ったことがなかったが、Javaより書きやすい言語であるというイメージがあった
またプロジェクトとしては小規模なものであり、納期もそれに準じたもので試すというより完成を目標にしていた。

目標と期待

目標としてはIDEはKotlinを作ったJetBrains社のIntelliJ IDEA Community Edtion 2019を使い、ウェブアプリケーションのフレームワークはJava EE7でウェブアプリコンテナはJava EE 7対応のWildFlyで稼働することにした。
期待としては書きやすいKotlinを高機能なIDEAの組み合わせで生産性の向上があった。
また、さらにJava EEのフレームワークを組み合わせさらに軽いWildFlyで運用することで高速の開発が可能であると見込んでいた。

経緯

そして開発に取り掛かった。
開発機ではまだIDEAは未インストールだったのでさっそくインストールし、WildFlyもインストールした。
インストールが終わったらすぐに開発に取り掛かったのだが、ほどなくして何度も原因不明のエラーに悩まされることになった。
結論から言えばKotlinはCDIとの相性が悪く、この記事の通り
Kotlin で始める JavaEE 7 〜 JPA + CDI + JSF 〜
https://blog1.mammb.com/entry/2015/05/17/150230
多くのクラスは
public open class Hoge {
open var bar
}
とデフォルトではなく冗長な修飾子を付け加えなければならなかった。
また何かエラーが起きたときにはKotlinの問題なのかJava EEの問題なのかWildFlyの問題なのかの切り分けきず、組み合わせによって高速性を狙ったのにそれどころかそれぞれの学習コストがかかりむしろ時間がかかる状態になった。
また学習が足りないことから進捗状況が分からないようになってしまった。
そこで途中からフレームワークは使わずServlet/JSP出の開発に切り替えたのだが、それまでのコードが無駄になってしまい、また切り替えた方がいいかどうかの判断で多くの時間を費やしてしまった。

結果

切り替え後は開発は進んだし進捗も見えるようになったが設定された納期内で完了はできなかった。
おそらく初めからServlet/JSPでの開発であれば完了できていたと思う。

感想

以下の経験で思ったことは、
・Kotlinは型推論やGetter/Setterの補完などコードが短く書きやすい
・JavaからKotlinの学習コストはそれなりにかかる
・Kotlinはテキストエディタでも書けるが当然IDEAとの相性がいいのでそれで書く方が断然よい
・ただし、事情によってEclipseなど他のIDEを使わなければならない場合はKotlinは避けた方が良いかもしれない
・Sevlet/JSPをKotlinで書くのはJavaで書くよりもやりやすい。というよりJavaはきつい
・Kotlinは少なくともJava EEとの相性がよくない

まとめ

いくつかの前提条件が付くがKotlinでウェブアプリケーションを開発するという選択肢はありだろう。
ただし前提条件は意識する必要がありそれは、
・サーバーサイドのフレームワークは使わない
・Servlet/JSPなのでプロジェクトは小規模な物に限る
・IDEAを使う
であり、これらを同時に満たす必要があるだろう。

Kotllinでウェブアップ開発で思ったこと

# 概要
Kotlinでウェブアプリケーションを作るきっかけがあったのでそのことについて感想を書く。

# 背景
開発を始める私の状態は以下のようだった。
・JavaおよびJava EEについて学習中でSpringは学習したことがないし、業務としてJavaは縁がなかった。
・GlassFishは何回か勉強で触っていたがあまり印象がよくなく、あまり触らなかったがWildFlyの方が開発が進んでいるという印象を持っていた。
・Kotlinについては触ったことがなかったが、Javaより書きやすい言語であるというイメージがあった
またプロジェクトとしては小規模なものであり、納期もそれに準じたもので試すというより完成を目標にしていた。

# 目標と期待
目標としてはIDEはKotlinを作ったJetBrains社のIntelliJ IDEA Community Edtion 2019を使い、ウェブアプリケーションのフレームワークはJava EE7でウェブアプリコンテナはJava EE 7対応のWildFlyで稼働することにした。
期待としては書きやすいKotlinを高機能なIDEAの組み合わせで生産性の向上があった。
また、さらにJava EEのフレームワークを組み合わせさらに軽いWildFlyで運用することで高速の開発が可能であると見込んでいた。

# 経緯
そして開発に取り掛かった。
開発機ではまだIDEAは未インストールだったのでさっそくインストールし、WildFlyもインストールした。
インストールが終わったらすぐに開発に取り掛かったのだが、ほどなくして何度も原因不明のエラーに悩まされることになった。
結論から言えばKotlinはCDIとの相性が悪く、この記事の通り
Kotlin で始める JavaEE 7 〜 JPA + CDI + JSF 〜
https://blog1.mammb.com/entry/2015/05/17/150230
多くのクラスは
public open class Hoge {
open var bar
}
とデフォルトではなく冗長な修飾子を付け加えなければならなかった。
また何かエラーが起きたときにはKotlinの問題なのかJava EEの問題なのかWildFlyの問題なのかの切り分けきず、組み合わせによって高速性を狙ったのにそれどころかそれぞれの学習コストがかかりむしろ時間がかかる状態になった。
また学習が足りないことから進捗状況が分からないようになってしまった。
そこで途中からフレームワークは使わずServlet/JSP出の開発に切り替えたのだが、それまでのコードが無駄になってしまい、また切り替えた方がいいかどうかの判断で多くの時間を費やしてしまった。

# 結果
切り替え後は開発は進んだし進捗も見えるようになったが設定された納期内で完了はできなかった。
おそらく初めからServlet/JSPでの開発であれば完了できていたと思う。

# 感想
以下の経験で思ったことは、
・Kotlinは型推論やGetter/Setterの補完などコードが短く書きやすい
・JavaからKotlinの学習コストはそれなりにかかる
・Kotlinはテキストエディタでも書けるが当然IDEAとの相性がいいのでそれで書く方が断然よい
・ただし、事情によってEclipseなど他のIDEを使わなければならない場合はKotlinは避けた方が良いかもしれない
・Sevlet/JSPをKotlinで書くのはJavaで書くよりもやりやすい。というよりJavaはきつい
・Kotlinは少なくともJava EEとの相性がよくない

# まとめ
いくつかの前提条件が付くがKotlinでウェブアプリケーションを開発するという選択肢はありだろう。
ただし前提条件は意識する必要がありそれは、
・サーバーサイドのフレームワークは使わない
・Servlet/JSPなのでプロジェクトは小規模な物に限る
・IDEAを使う
であり、これらを同時に満たす必要があるだろう。

機帆船

皆さんは機帆船というものをご存知でだろうか。
機帆船とは内燃機関と帆を同時に持つ船のことであり、日本で有名なのはペリー来航時の黒船だろうか。
ここからわかる通り100年以上前にはすでにありしばらく使われていた時期もあった。
しかし、今はほぼ内燃機関オンリーの船が主流となっている。

ところが実はこれが昔のものではなく未来技術として復活するかもしれない、という話がある。
キーワードは「硬翼帆」だ。

硬翼帆とは現代の飛行機がもつような翼を応用した帆のことで、昔の帆船のような布の帆に比べて流体力学的に洗練されている。
これと内燃機関を組み合わせた最新式の機帆船の開発が行われているのだが、実は日本がこの分野をリードしている。

www.mol.co.jp

日本から最新科学による機帆船の復活がなされる日も近いのではないだろうか。

徴税請負人

徴税請負人制度について考えている。徴税請負人と言えば弱いものから税金をむしり取る悪人のイメージがあるかもしれないが、工夫次第ではいいものになるかもしれない。しかし、徴税請負人制度が徴収した税の一部を請負人の収益にできるものだとするなら、一人から徴収する税金に応じて利益率を変える累進性を持たせればどうだろう。
例えば次の羅列だったらどうなるか。

  • 10万円以下の徴収なら0%で固定1000円を国からもらう
  • 100万円なら5%で5万円
  • 1000万円なら10%で100万円
  • 1億円以上なら20%で2000万円

これなら請負人はより収益が高い人から税金を徴収するようになる。この場合は当然に請負人の収益も徴収対象になる。
現状の徴収は公務員が行っているが効率的とはいいがたい。いわゆる民営化の考えを導入してもいいかもしれない。そしてこの請負人は法人、しかも株式会社でもなれるとしたらどうだろう。
また税金を払うときは払う個人の努力が要るが、この手間もついでに請け負ってくれるとしたら時間が減っていいかもしれない。

人体の運動から効率的にエネルギーに変換する器具

私は長らく人体の運動をどうすれば効率的に電気エネルギーに変換できるかに関心を持っていた。例えば自転車で人間のエネルギーから電気エネルギーに変換することはよく知られていることだ。夜間のライトをつけるのは人体のエネルギーを利用していることは自転車に乗る人には日常のことだ。

ただしそれは足のみの負担で実現しているので体全体を使っているわけではなくエネルギーの取り出し量はそれほどでもない。

例えば舟を漕ぐ動作ならより体全体を使っているので量は大きいがまだ効率が悪い気がしていた。

そこでベンチに座っている老人が杖を使って起ちあがる動作をヒントにより取り出し量が大きい装置を考えてみた。

f:id:inmthrnb:20200608213729j:plain

人体と器具

縮み動作と伸び動作を交互に繰り返し、補助的に重りを使う。足、背筋、腹筋などまんべんなく使うことができると思う。またここでは腕の動作は省略しているが腕も重要な要素となる。

これは一人用の器具だが、2人用にすることもできるし往復運動から回転エネルギーにすることは可能だ。

これを発展させて具体的なアイデアにして特許をとれればいいなと考えている。

 

飛行船

飛行船、それはロマン。

それはかつて栄えていた飛行物体であり今はほとんど目にする機会はない。

しかしそれはずっとなのだろうか。

私はこれからは飛行船の時代が来ると信じて疑わない。

基礎知識

まずは飛行船の基礎知識を整理しよう。

通常身の回りにある空気の密度は1.2g/c㎥だ。1㎥では1.2kgとなる。

ちなみに水素は同じ条件下なら1㎥で0.09kgとなる。

もし仮に体積1㎥の水素の風船があるなら浮力は1.1kg程度だ。

10m×10m×10m=1000㎥であれば1100kg、つまり1.1t。これが20個連なっていれば20tもの浮力を持つ。

Wikipediaによるとツェッペリン飛行船のLZ127は全長236m、体積105000㎥であり、単純計算で105tの浮力を持つ。

速さ

そして速さ。

飛行船は一般的に飛行機よりも遅いといわれているが、これは遅くても飛べるから遅くしているに過ぎない。硬式飛行船の場合、亜音速であればいくらでも早くすることができる。

逆に飛行機はたとえ無駄であっても揚力のために速く飛ばなくてはならない。

大きさ

飛行船の欠点としてはその大きさがある。硬式飛行船の場合大きければ大きいほど浮力に比べて空気抵抗が小さくなるので有利となるが、格納に苦労することになる。

経済性

飛行船は有用なものにするためにはどうしても大きくしなければならず、一隻あたりの費用がどうしても高価になる。また、浮力用物質が水素化ヘリウムかの2択になってしまうことが経済的なことのみならず問題を引き起こす。

将来

しかし、飛行船特有の機能によって飛行機では補えない存在となるだろう。というのも飛行船の最大の特徴である、浮く、という機能はどうしても代えがたいものだからだ。例えばヘリコプターは垂直移動ができるがとてもエネルギーがいる。とても不効率なのだ。

そこは飛行船は得意分野であり、ある地点でずっと居続けるということができる。これは科学的な学術調査にとても役に立つ。

問題

このようにとても有用なのだが、今現在はヘリウムが浮力用に使われているが価格が高騰しているし水素に比べ若干重い。なので水素を使うのが一番いいのだろうけど水素は爆発するイメージがあり危険だと思われている。実際ヘリウムに比べて危険性はあるだろうけれどそれは工夫次第でどうにでもなるのではないだろうか。

終わりに

といろいろと書いてみたがやはり飛行船はロマンだ。何より静かなところがいい。もし私がお金持ちだったら飛行船の開発をするのだけれど。

OSSコンサルタント

現在のITシステム開発におい無償のOSSの製品を使うことは当たり前になっている。
例えばJavaでの開発を考えるとOpenJDKがOSSであり、Apache Software Foundationの製品がOSSの代表として知られている。
しかしながら、OSSは製品によって違いはあるが多くは自己責任での使用が求められ、使用方法や注意点、バグ情報などが必ずしも充実しているとは限らない。
また、OSSは巨大なソースコードを持つ場合もあり小さな企業でも大きな企業でもその内部だけで把握することは容易ではない。
そこで、OSSを利用する開発において助言とサポートを行う専門の人物または組織があればその溝を埋めることができるはずだ。

というわけで、副業としてOSSのコンサルタントとして収入を得る方法を考えてみたりしているのだが、需要はあるだろうか。