日々雑感的な日記

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

人材流動化と東京

NewsPicksを読んでいたら、ふと次の記事が目に入った。

newspicks.com

NPらしいコメントが並ぶが、その中で解雇規制を撤廃すればいいというコメントが気になった。そうすると人材流動化が起きるのだとか。確かにそうなるのかもしれないが、それで解決なんてするだろうか?だから、それを意識してこうコメントした。

無能な大企業の経営者を従業員が自由に解雇できるようになったらよくなるんじゃないかなよーしらんけど。

 安易な思いつきだが、しばらくしてから改めて考えてみたら、意外といいんじゃないかという気がしている。

真の人材の流動化

真の○○なんて、なんでも突き通せる矛となんでも防げる盾のごとく、言葉にはできてもこの世には存在しないものだ。けど、あえて「真の人材の流動化」を考えてみると、本当に足りない人材ははっきり言えば有能な経営陣だ。従業員が経営陣をいつでも自由に解雇できる仕組みがあればそれはあっという間に解決する。もちろん今でも株主がそういうことができるわけだが、それは今では経営陣の流動化ということでは意味がない。株主の本音は目先の金になるかどうかなのだから。

東京

そしてそういえば、と思ったのが東京だ。非生産的で非効率的な都市の象徴。そこで東京税を作ったらどうだろうかと思う。東京にいるだけで毎年一人あたり10万円の人頭税を徴収すれば、あっという間に財政と東京の一極集中が解決する。人材流動化も活発になるだろう。すぐにやると混乱が起きるだけなので10年後に実施する、と決めれば財政はすぐには効果はないが、とりあえず地方の活性化にはつながるだろう。

終わりに

今の日本に足りないのは何だろう?それは「真の」効率化だ。だが今のメディアとネットにあふれているのは無能でも資産があれば安泰な、今はやりの言葉でいえば「上級国民」のための効率化だ。でも彼らのための効率化なんていったい何の意味があるのだろう。

今求められているのは、単純で明快な、こうすればいいだろ、というアイデアではないだろうか。

もしも会社を起ち上げられたらまず韓国人を雇う

ふとある記事を目にした。

 

韓国の若者、日本で就職目指す「夢かなえたい」

https://headlines.yahoo.co.jp/hl?a=20190519-00050136-yom-bus_all

 

記事の内容よりもそこに並ぶコメントが気を引いた。

国籍だけで人格のすべてを判断する人たち。

これを見ていて思った。

もし会社を起ち上げることができたら、まず韓国人を雇うことを優先課題にしたい。そなぜなら達成できたら、大きなメリットがある、と。

状況

まず状況を整理しよう。今の韓日関係は最悪の時を迎えているなどという声もある。でも一方で、以前の記事でも触れたが訪日韓国人は急増している。そして、就職を日本にしていると考えている若者は多い。これはどういうことなのか?

例えばレーダー照射問題。日本と韓国という国では意見が対立しているように見える。が、それは表面上の国と国の問題だ。では一般人はどうなのか?

少なくとも韓国国民の間では韓国より日本の方が信頼できる国だという認識でほぼ固まっているといっていいだろう。

なぜかというと、旅行や就職で日本に来る若者がいるということは、その若者たちにも親など親族がいて、その親や祖父母も日本に行くことに反対していないということだ。

これは表面上では分かりづらいが、韓国という国への信頼をもっとも失っているのは韓国国民自身なのだ。そんな中、政治と意見の違いはあるだろうが、いわゆる「反日」な人が一体どれだけいるのだろう。

逆に

そして、韓国人を採用し、そしてそれを公表することでとても大きなメリットがある。

まとめよう。

・人材募集時、差別主義者がよってこない

・取引時、差別主義者がよってこない

・顧客開拓時、差別主義者がよってこない

・逆に差別主義者の存在を懸念する会社がよってくる

これらは今後のビジネスを考えるうえでとても大きなメリットになる。特に今後大きな存在となるインバウンド業界との繋がりが期待できる。私が作りたいのはIT企業だが、今後はインバウンド業界との結びつきも重要な課題になるかもしれない。そういったことを考えれば、合理的な方法であるといえる。

最近のことについて整理

ここ最近の4月はプログラミングが進んだ。きっかけは
github.com
を作ったことだった。もともとはJSONの検証を目的にしたプロジェクトだったが、途中からCSVも含めるものになった。
その途上でDOM APIを簡単に高機能に扱えるコードをまとめたJAXP Helperというプロジェクトも作ったが、これはもともとあった
github.com
に統合した。

そして、大きな動きとしてはJPAを中心としたプロジェクトを進めるようにしたことだ。
github.com
は、もともとORMとしてはJPAだったり他のだったり安定しなかったが、JPAで決めて、
本格的にJPAの学習に乗り出した。
他のプロジェクトにもJPAは応用できることに気づいたからだ。例えばブラウザつくりに挑戦しようとしているが、
github.com
これにもJPAを利用している。
また、作りたいと考えている会社のシステムもJPAで行くつもりだ。
そのうちJPAを学ぶための参考になるようなサンプルコードも公開したい。

そして今後のことだが、少し立ち止まってプロジェクトの整理をしたい。
いろいろ作ってはいるがちょっと煩雑な作業が増えてきたので把握しやすい環境を作りたい。

JPA2と組み込みDerbyで楽々RDB作りができるかもしれない

最近はプログラミングがサクサク進んでいる。そこで得た知見を少しだけまとめたい。

Java EEあるいはJakarta EE

最近はRDBにアクセスするORMツールとしてJPA2を使ってみている。継問とかあとは作ろうとしている会社のRDBJava EEあるいはJakarta EEのものでアクセスしたい気持ちがあったからだ。というのも、もともとサーバーサイドのフレームワークではJava EEを使っていて、巷で流行っているSpringにはほとんど関心がなかった。というかそもそも仕事でJavaを使ったことがないので、色々なフレームワークに触れる機会がなかったのだが、趣味で作る場合は慣れているJava EEを使う場合が多かった。なので、このまま慣れているもので行こうとしている。

ただ、Java EEあるいはJakarta EEはとても大きな仕様で、一つ一つのプロダクトの集合なのだが、そのどれをとっても奥深く容易に理解できるようなものではなかったし、JPAもそうそう理解できていたわけではなかった。

だが、色々とどうすればいいかを試行錯誤しているうちにJPAをどう使えばいいかのコツがつかめてきた。

JPAは便利

はっきりいってJPAは便利だ。顔といってもいいJPQLもSQLに慣れている人からは癖があるだろうし私も苦戦していたが、だんだんやり慣れてくるととても使い勝手のいい問い合わせ言語であると思えるようになった。

直にRDBにアクセスしないことによる結果はひとそれぞれ良し悪しがあるだろうが、私にはとてもいい仕様だと思う。それにRDBの設計がとてもうまくいく手ごたえがある。

開発環境の工夫

そして、そう思える要因として開発環境の工夫があった。容易なテストができないか模索していたらApache Derbyの組み込み型のRDBがとても便利で、JPAでの開発ととても相性がいいことに気づいたのだ。普通テストでRDBにアクセスする場合は苦労することが多いが、これならとても楽にJPAの学習および実験とRDBの設計ができる。

そして、IDEとしてはEclipse Java EE IDE for Web Developersを使っている。これもとてもJPAと相性がいい。そういえば、Java EEもといJakarta EEは今はEclipse Foundationのプロダクトなった。今後のことを考えれば、Eclipseを使うならJPAJPAを使うならEclipseという流れになるのではないだろうか。

そのうちQiitaに

いま、継問と作りたい会社用にJPAを使っているが、サンプルをGitHubにあげたいと思っている。こうするととても簡単にしかもうまくいく、という手本を共有したいし、またいまだに記事を書いていないQiitaに書くネタができたと思うので、ちょっとやってみたい。

JAXPを簡単に扱うコードを書いてみた

xSchemaを作っている際、JAXPを簡単に扱えるコードを思いついたので、まとめてGitHubに上げてみた。

https://github.com/inomoto-hironobu/jaxp-helper

今のところはラムダを使ってDOM APIを簡潔に扱えるようにするコードが中心になる。というか、SAXをラムダを使ってうまく扱う方法が思いつけてない。

とにかくにも、今の時点でもDOM APIをかなりうまく扱えるコードになっているので、今後に期待してもらいたい。

Stream APIでFizzBuzzに挑戦したらなんだこれは

StreamAPIの勉強のため色々やり方を探していたら、ふとこの記事が目に入った。

forやifで書くアレをStream APIで書く - Java EE 事始め!

ここで文字列結合をしているコードがあったので、コメントでそのことを指摘してみた。
ただ、それだけではあれなので、自分なりに作ってみた。
それがこれだ。

IntStream.rangeClosed(1, 40)
	.filter(val -> {
		if(val % 15 == 0) {
			System.out.print("FizzBuzz");
			System.out.print(",");
			return false;
		}
		return true;
	}).filter(val -> {
		if(val % 5 == 0) {
			System.out.print("Buzz");
			System.out.print(",");
			return false;
		}
		return true;
	}).filter(val -> {
		if(val % 3 == 0) {
			System.out.print("Fizz");
			System.out.print(",");
			return false;
		}
		return true;
	}).filter(val -> {
		System.out.print(val);
		System.out.print(",");
		return false;
	}).count();

な、な、な、なんだこれは―

なんというか、もう…。
いや、やり方としてはこれが正しいはずだと思うのだけど…。
はあ。

世界を変えるコードを創った、かもしれない

先日も書いた通り、JSONスキーマXMLで表現するということにチャレンジししてみたのだが、思いのほかうまくいった。これはそれを処理するJavaコードと一緒にGitHubにあげている。

github.com

この中のsrc/main/resources/xjsonschema/にスキーマXML Schemaを置いている。

ただ、問題としてはどの程度の表現力を持たせるかということで、どの方向性に行くかで悩んでいた。シンプルさを重要視するか、多機能性を追求するか。

両方創る

この答えは、2つ作るということで解決した。つまりシンプル・イズ・ベストなスキーマと、多機能性を重要視するスキーマの両方を同時に開発していくことにしたのだ。とりあえず多機能性バージョンはTypea、タイピーと名づけ、シンプルバージョンはTypeb、タイペブと名づけた。

これによって唯一絶対の真理を追究するというおおよそ人間で成しえないことをすることは避けられた。そして、これによってとてもいいことが起きた。

シンプルさを考慮したスキーマ、タイペブが完成したのだ。というのも、シンプルであるがゆえにこれ以上付け加える要素がないので、これで開発終了となった。

タイペブは世界を変えるかもしれない

そしてこのタイペブだが、実用性は十分にある。まずはnpmで使われるpackage.jsonがあるとする。とりあえずこんな感じで。

{
  "name": "hoge",
  "version": "0.0.0",
  "description": "JSON用のスキーマのサンプル",
  "main": "src/js/main.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "http": "http-server",
    "build": "node src/js/main"
  },
  "repository": {
    "type": "git",
    "url": "https://hoge.com"
  },
  "author": "ほげ",
  "license": "MIT",
  "bugs": {
    "url": "https://hoge.com"
  },
  "homepage": "https://hoge.com",
  "devDependencies": {
    "typescript": "^2.2.1"
  },
  "dependencies": {
    "@types/jquery": "^3.2.1",
    "babel": "^6.23.0",
    "babel-cli": "^6.24.1",
    "eslint": "^3.15.0",
    "jsdom": "^11.1.0",
    "vue": "~2.1.10",
    "vue-router": "2.4.0"
  }
}

そしてこれのスキーマをタイペブで表現する場合はどうなるかというと、こうなる。

<?xml version="1.0" encoding="UTF-8"?>
<json-schema name="npm.package" xmlns="https://www.json.org/typeb">
	<string name="name" />
	<string name="version" />
	<string name="description" />
	<string name="main" />
	<typed-object name="scripts" type="string"/>
	<object name="repository">
		<string name="type" />
		<string name="url" />
	</object>
	<string name="author" />
	<string name="license" />
	<object name="bugs">
		<string name="url" />
	</object>
	<typed-object name="devDependencies" type="string"/>
	<typed-object name="dependencies" type="string"/>
</json-schema>

実際のpackage.jsonはもっといろいろ要素があるのだろうけど、それを表現するのはそれほど難しくはないだろう。そして、package.json以外の、世界にあまたあるJSONスキーマとしてはほとんどの場合タイペブで事足りるのではないだろうか。現在開発されているJSON Schemaはパッと見た限り複雑になりそうなので、それに比べれば一般的には書きづらいとされるXMLでもこれならほとんどのITエンジニアならスラスラと書けるだろう。

後は検証するプログラミングコード

この単純さはスキーマを表現するプログラミングコードを作りやすいという面でもメリットは大きい。実際試しにJavaで書いてみたのだけれど苦も無く書けた。もっともプログラムコードの書き方が特殊だしあとで大きく変える可能性はある。しかし、なんにせよコードを書きやすいというところは変わらないはずだ。
そして、後は検証するコードを書きたいのだが、ここで苦労が大きそうだし、一人でやっていくのは難しい。これは世界を変えるコードであるという絶対の自信があるが、協力者が必要だ。