Spring Bootで手軽にデータを管理したいので、よくSQLiteを使う。
その際に、ロックの概念でかなり迷ったので、書いておく
手軽に使えるように、オートコミットが有効らしい。
Oracleとか、MySQLとかでセッション管理やっていると、癖でBEGIN/COMMITやってしまう。
そうすると、"database is locked"が発生する。
自分は、面倒くせぇから、SQLiteでオートコミットしないように設定して回避している。
実運用を考えると、オートコミットとかは邪魔な気がしてならない。
SQLiteで大規模なデータ管理はしないと思うが、そういう動きをすることは理解しておく必要がある。
SQLiteは、かなり使い勝手のいいDBだと思うので、ここらへんの細かい動きは、理解しておきたい。
これからのIoT時代に必要になものだと、個人的には感じている。
かなり短いけど、ここまで。
参考になったサイト上げておく
Atsushi's Homepage ` SQLite ‚ðŽg‚Á‚Ä‚Ý‚é
ただの不満のはけ口と、ちょっとした思ったことを書いているだけです。
事実と異なる可能性もなくもない。
読む場合は、気楽な気持ちで読んで下さい。
技術的な要素はなく、あとで振り返るようのメモなので、目的が違う人は直に別ページを探すことをおススメします。マジで！
とある商流関係のシステムで、センターシステムの刷新プロジェクトに参加。
刷新なので、既存のソースを載せ替えるのがメインの仕事。
自分はJavaの開発要員としてアサイン。
参加している企業が手動しているわけではなく、支援の形。
主導している企業は他にある。
そこで、主導している企業からいろいろ酷い目にあった。 恨み・辛みを忘れないために残す。
主導側のレビューレベルが低すぎた。
本当にこの企業の支援でプロジェクトは成功するのか心配になった。
主導企業がどんな事しているのか気になって調べたら、ホームページでは誇張された実績と、「安心のプロジェクト管理を〜」みたいな記述があった。見積もりも正確にやれますみたいなことが書いてあり、みんなで総ツッコミ状態だった。
案の定、上手く行きませんよね。。。
プロジェクトは、御破算になるようでした。。。
めでたし、めでたし。。(めでたいのだろうか？)
プロジェクトでやってはいけないアンチパターンを学べた。
技術力重要。差がありすぎると、会議をしても考えが伝わらない。
全体影響を考えないのは、システム開発失格。
過度な自動化はダメ。きちんと影響範囲と副作用を意識して、自動化する。
横文字を多用するやつを信じてはいけない。
結婚指輪以外の指輪を、いっぱいつけている人は、能力的に低い。
コンポーネントの部品化は、APIを利用したWEBシステムと合わない。
コンポーネントが画面固有になることが多いので、標準化できずに破綻しやすい。
進捗管理できないやつは、たいてい問題があっても報告しない。
ムカついても、陰口を叩いてはいけない。
自分の人間性を疑われる。
陰口を叩く場合、蔑称をつけるのがいい。
そうすれば、なんのことを言っているのか、外部の人はわからないし、伝わるのは一部の内部の人間のみ。
こんな嬉しい事はない。罵倒しまくりだぜ！！
主導企業に対する怒りが強い！
潰れて欲しいとすら思ったことがある。
最後の方の社員旅行行っているって知ったときは、行きか帰りで事故らないかなぁ〜と本気で思った。
たぶん、一生忘れない。
末代までたたってやる！！
「DOSでファイルの一覧取得したいんですけど、どうすればできますか？」みたいな質問を受けた。
「PowerShellならできるで！」って返したけど、即作れなかったので、メモ。
ちなみに、エセ関西弁で喋ってはいない。
なんか知らんけど、軽いノリの文章を書くと、不思議とエセ関西弁が出て来る。
業務のフォルダ構成を乗せるわけにはいかんので、とりあえずテスト用の環境を作った。
テストのフォルダ構成は、以下。
test
│ e.bat
│ f.txt
│ test.txt
│
└─sub
a.txt
b.java
c.java
d.bat
PowerShellの紹介だが、treeコマンドで出したのはご愛嬌。。。
下記コマンドを実行。
今回は、".txt"のファイルのみ抽出。
Get-ChildItem ./ -Recurse | Where-Object{$_.Name -like "*.txt"} | Select-Object Name
すると、結果は以下の通り。
Name ---- f.txt test.txt a.txt
Get-ChildItemで、ファイルの一覧を取得。
-Recurseでサブディレクトリも取得させる。
あとは、パイプラインで繋げて、Where-Objectで必要なものだけ抽出、Select-Objectで必要な要素を出力している。
DOSだと、面倒な繰り返し処理を書かなければいけないが、PowerShellなら簡単に実装できる。
JavaのStreamAPIを使う感覚に近い。
基本的には、何かオブジェクトを作る→データの加工→出力処理 を書けば見やすい。
なるべく簡潔に実装することが重要だと思う。
最初、DOSに慣れているせいか、とっつきにくさを感じるかもしれない。
ただ、基本的な文法を覚えてしまうと、あまり苦にならないので、Windows7以降を使っているなら、なるはやで覚えたほうがいいと思う。
よくCSVファイルの中身を見たいときにPowerShellを使って見たりする。
意外と簡単にできる。
本当は、Pythonとか使いたいけど、現場のセキュリティレベルが高すぎて使えないのが現状。
この現場とはもう直ぐさよならなので、次の現場に期待したい。
| 項目 | 内容 |
|---|---|
| 日時 | 2016年 12月 3日 (土) 10:00 ～ 20:00 (開場 9:30) |
| 場所 | ベルサール新宿グランド5F（東京都新宿区西新宿8-17-1 住友不動産新宿グランドタワー 5F ベルサール新宿グランドコンファレンスセンター |
| 参加費 | 無料 |
GitHub - jjug-ccc/slides-articles-2016fall: JJUG CCC 2016 Fallの発表資料およびブログ記事まとめ
基調講演だし、とりあえず聞いとこう的な感じで拝聴。
朝、２度寝したため、途中から聞いた。
資料公開されたら、内容は目を通しておきたい。
トレンドは、イノベーションから生まれる。
イノベーションを追いかければ、自ずとトレンドを追いかける様になる。
個人的に思うのは、日本は企業のリスクと難しさがあって、イノベーションが起こりにくいのではないかと思う。
海外事情を知らないので、正解なのか不明だが。。。
海外事情に詳しい人脈が欲しいところ。
ぼっち歴の長い俺には、かなり難しい課題。
「イノベーションのジレンマ」って本が話題に出ていた。
トレンドを踏まえての予見した発表をする。
全然知らなかった。会社を騙して参加費をむしり取ろうかな？
トレンドは、明日から使えるわけではない
いずれ一般化する。
「コモディティ化」って単語は、ちょっと意識高い系といわれそうなので、なるべく使わない。
構成要素を取り出して、それを学ぶのが重要
自分のニーズを把握して、イノベーションが一般化した時に取り入れやすくする。
ガードナー社を知れたのが収穫。
あとは、トレンドは全部把握する必要はないなと思った。
自分が欲しているものとトレンドがマッチするなら、深く探求しておく必要があると感じた。
結局は、アンテナの張り方だと思いました。
近くの中華料理店で食事 四川麻婆豆腐定食をいただいた。 辛味が足りないかな。 もっと激辛でもよかったハズ。
本当は慎さんのセッション見るつもりだったが、「初心者は〜」の下りを見て、このセッションを見ることに。
自分が上級者だと自覚するには、まだまだだからね！
初心者向けだけあって、既知の内容が主だった。
Springが管理しているインスタンス制御の仕組み
Bean → 豆、Java豆から来ているということを初めて知った。そういえば、最初にJavaやったときにBeanの意味がわからなかった
こういうハック系みたいな感じなのは、面白いことが多いので参加。
TLS暗号化 json形式で連携 SDKはいらないのだが、やりたいことを実現扠せやすくするために作成
LINEのサーバーサイドはJava
社内の独自文化で醸成されているので、プルリクを欲している様子
LINE BOT AWARDS グランプリなら1000万円！！！！
実装内容を見ていたが、相当練習したように見える。 気になったのが、設定して値を返すような仕組みがイマイチに感じた。 returnでメッセージに出したいものを表示する仕組みが提供されていて、そこら辺は流石だと思う。 なんちゃってシステム開発は、returnを使わせないところがあるからな。
タイトルにつられてしまった。。。 こういう感じの遊び心がある感じは、好きだ。 実際に、怒り新党はよく見ている番組なので参加。 内容見て、不満だったらJunit5の方に流れる
はい、僕です。。。
やらないようにしているけど、それをやるのは難しい。
ムカつく奴がいるのなら、その人のバグを見つけて、その人を責め立てる策が、超有効。
２度と開発現場に来ないくらいに責め立てる。
犯人探しは、自分が犯人というミステリー殺人みたいなことが起きそうなので、 なるべくやらないようにしたいけど、責任が来ないように退路を作っておく。
やる人は、責任が来ない範囲に立っている人なんだろうね。 俺は恨み・辛みを覚えておくほうなので、絶対に倍返しするための策略を立てる。
犯人、適切な判断を下せるやつが犯人の可能性？？
使えないのはツールではなく、お前だ！という結論。
投稿した人は、使えないなら別な手段をすればいい。
上長が、技術に疎いけど、地位だけ高いのが駄目だと思う。
やっぱり、技術部門が居ると思う。
そして、そこは地位と依存関係がない感じがベストだと思う。
猫を処分すればいいんじゃないかな？
集中したいなら、他人に監視されるとか、期限ギリギリまで何もしない。
営業はユーザではないよね？
あと、営業がユーザのニーズを完全に把握しているとは思えないんだよね。
営業は肉食動物、エンジニアは草食動物ってのが、上手い例えだ。
もう、分かり合えないのだ。
この対立は、第三者が隠れているような意見が面白かった。
たぶん、管理職か経営層が、問題なんだろうな。
無理じゃないかな。
完全に納得できる定量評価は難しい。
会社への貢献度で見るしか無い。この人がやめられたら困る順に評価が高ければいいんじゃない。
あとは、どのくらい能力向上を果たしたかだろう。
目標設定の話があった。
達成可能な目標を立てて、達成して評価を上げさせる人が居るみたいな話があった。
自分も評価する立場になったから思ったこと。
自分が求めているレベルと評価する人のレベルの差だね。
求めているレベルに達してなかったら、評価を下げるし、求めているレベル以上で、こちらが教えられることが多かったら、評価をあげる。
あとは、管理職が評価する人の能力を知っていれば、自ずと全体を把握できるはずだ。
第三者を入れればいいんじゃないかな？
本人に直接いったり、誰かが集まった場で発言させるのは、正直無理があるで！
「発言で空気が冷める人がいる」ってのは、俺のことかな？
よく発言すると、時間が止まったみたいな感じになる。
スタンド使いになったのかもしれない。
スタンド名は「ザ・ワールド」に違いない！Wryyyyyyyyyyy!!!!!
会議で言わないのは、責任が伴うからだ。
レッテル貼りが会議では起こるからな。参加者が多ければ、より強力なレッテル貼りになる。
「バカだと思われたくないから、発言しないことが多い」という意見には納得。
俺も思う。
羞耻心は、仕事をする上で、とても邪魔になる。
どうやって捨てるかが大事だね。
バカという衣を被れる技術がいるんだろう。
やり過ぎると、ウザくなるから適度な感じできっちりやる場面と、バカを装う場面を使い分ける必要がある。
他社との問い合わせ窓口をやることが多くなってきたが、その役割をする際は、自分がバカの衣を被る技術が必須だと感じた。
自分が疎い技術に関して聞く場合は、なおさらだ。
アドリブが必須なセッションだったな。。。
無言事故が結構あった。
もしかして、俺の「ザ・ワールド」が能力を発揮したのか？
パネルが意外としっかり作ってあったのに驚いた。
発注したのかな？本物の番組並のクオリティだった。
意見を募ることが多かった。
たぶん、ツイッターとか活用すれば、意見が集めやすい気がする。
いろんな人がいる前での発言は、結構勇気がいる。
世間体を気にする日本人では、セッションの質問時間で質問するのは難しい。
聴衆参加型も同様だ。
次のJJUG Springでもやるらしい。
そういえば、思ったけど、Javaの話が一切出てこなかったな。
別の技術とは関係ないブログで、マツコ＆有吉の怒り新党の番組の感想を書いているので、興味ある人はそちらに。
山本裕介さんだから、とりあえず聞いてみた。
人がいっぱい。
同姓同名が有名人でいっぱいいることは、知っていたみたい。
王道なし
英語を使う環境に身をおくことが大切
あとは、楽しんで触れられることが重要
英語だけではないが、やっぱり環境が与える影響はデカイ。
どういう環境に身を置くかが大事だね
超満員で、一番戦闘で座って見る羽目に。。。
Javaの補助ツールとしてJVM言語を使うことがたまにあるので、現状を知りたくて拝聴
後方互換があるからこそJVMが成り立つ 破壊的変更が少ないから、JVM言語が成立する
Pythonは2→3が問題だよね。。。
つまり、プログラミングだけ変えて、ビルド・デプロイは変えなくてもいい。
60くらい。論文だと100とか言われていることもあり、実態は誰もつかめていない。
1996年くらいからある。
JSR223から、他言語との親和性が進む。
JSR292から、動的言語のサポートが充実してきた。
Colojure
Frege, Kotlin
独特な雰囲気の人だな。。。
JVM言語の世代の話をされると、ガンダムを連想してしまう。
そろそろ、真面目にキャリアパスを考える年齢になってきたので、とりあえず拝聴。
やりたいことができなかったから転職がほとんどだった。
全員、危機感を感じたから転職が多い。
俺は、エクセル嫌いなので、やりたくない。
マネージャになっても開発ができないわけではない。
それは、怠けているだけである。
技術とマネジメントは、相反しないという意見があった。
昇格するための試験は、無いところもあるのか。
マネジメントって人のマネジメントね。。
他にやることが増えるため、やりたいことができないが、登壇者の主な意見だった。
フリーランスでいることは、デメリットもある。
開発以外の作業が増えたり、仕事がなくなるという恐怖もある。
あとは、システムのコアな箇所が触らせてもらえないなどもあり得る。
起業するなら、自分にあったやり方が見つからなかったときかも。上司とやり取りが面倒くさいなら、あり？
個人的には、こだわらなくてもいい気がする。
Javaが普及しすぎて、抜け出せない感覚がある。
登壇者の主な意見は、こだわる気はないようだ。
Javaへの愛着や思い入れが深い。
庄司さんの意見がすごかった。
というより、常人にはできないと思うのだが。。。。
異常者なのかも知れない。
今回は、体調不良ではなかったので、真面目に参加。
何人かに話しかけられた。
初めての経験。普段だったら、話しかけられる前に気配を察して逃げるもんね。
そして、今回一番良かったことは、ひしだまさんと話せたこと。
いつもの俺なら、絶対に話しかけないね。
ぼっちフィールドを展開して、近づくものすべて傷つけるような雰囲気を出しているもの。
聞いた内容は、ブログ運営について。
自分も１年位ブログをやっているが、１０ヶ月くらいで週１の更新がマチマチになってしまった。
どのタイミングで更新しているのか聞いたら、業務で問題があったときに調べた結果(ネタ)をメールで送ってストックしているらしい。
そして、早いうちにそれをブログに上げているようだ。
最近は更新が止まってしまっているようなことを言っていたが、物事を知りすぎてしまった結果なような気がする。
そして、無理にネタ探しはしないほうがいいそうだ。
それをやるとキツイだけで、長続きしないから、問題は業務で見つけて書くのが一般的だそうだ。
そして、業務で見つけた問題点をメールで送ってブログに上げることが習慣化しているようなことを言っていた。
これが長続きしている要因なのだろうな。
今の現場は、セキュリティ的にキツイので、メモ書きする習慣をつけて、それをどうやってブログに上げるか、 うまいやり方を考える必要があると感じた。
誰かに話しかけることは一生ないだろうと思ったけど、その殻を破ったのは大きい。
毎回思うのだが、JJUGなりでセッションやりたいとは思うけど、なかなかできない。
踏ん切りをつける儀式がいるのかも知れない。
英語でほとんど問題ないのだが、環境面の問題が出た時に、英語だと単語の意味が分からなく、解読できないことがある。
それに対処するために日本語化しようという思いに駆られた。
下記サイトからダウンロードする。 注意点として、pleiades本体ではなく、プラグインのみをダウンロードすること。
なぜ、pleiadesかというと、SpringToolSuite(以下、STS)は、eclipseの派生IDEであるため。
よって、eclipseの日本語化プラグインがそのまま使える。
この記事を見てたら、説明不要だろう。。。
パス。
解凍してできた「features」「plugins」フォルダを、STS.exeがあるフォルダにコピペする。
別にしなくてもいいが、パスの指定が面倒になるので、統一する。
STS.iniの最後に、「-javaagent:plugins/jp.sourceforge.mergedoc.pleiades/pleiades.jar」を追記する。
STSが起動したらpleiadesを読み込んで展開してくれる。
先頭行に持っていくとアウト。
STSの起動引数として認識されるため。
STS起動時のJava引数として認識させたいので、要注意。
指定が終わったら、STSを起動する。
さすれば、日本語で起動されるはず。
現場でJavaアプリ開発しているが、変なルールがたまにある。
聞いても「こうしてください」としか言われず、腹が立ってしょうがない。
とりあえず、ブログに書いて発散しようぜ！が主な目的である。
もう、意味がわかりません。
ルールを守ることを強いられている状態。
エラーチェックして処理を処理を終わらせたいのだが、できない状態。
後続の処理をしないために、判定分を書かなければいけない始末。。。
例外を発生させないことを強制した場合、メソッド分割することができず、モンスターメソッドになると思うのだが、相手が理解してくれない。
個人的に、「例外設計上手くできてないから、例外を発生させちゃダメって方針作ったろ」って気がしてならない。
今まで開発してきた現場で、例外を発生させてはならない現場を見たのは、ここだけだった。
日本の企業は多いのだろうか？
DBに引っ張られて、ローマ字を使うことを強いられている。
そうした場合のデメリットは、名称が無茶苦茶長くなる。
ただの変数名で20文字位上になることが多い。
本当にローマ字を許容するのか、ルール作りをする人はよく考えたほうがいい。
文字が多くなければ、それだけタイピング量が増え、改行もやりにくなって画面が見にくくなり、積み重なった手間が生産性を著しく落とすと思うんだよね。
課題の一覧がない。
ありえないと思うが、実際にあるんだぜ！
おかげで、問題がどれだけ残っているのか、何がネックになっているのか、毎回報告しなければいけない始末。。。
管理職になる人は、よくよく考えるべきだ。
いちいち日報で報告は、個人の時間を削って、最終的にコストが増えるだけだ。
毎回思うのだが、メーリングリストを使っても、メールのタイトルにプレフィックスつけないのは何で？
タイトルで振り分けしないのだが、メーリングリスト使うと暗黙的にプレフィックスは決まる。
人によっては、タイトルでフィルタリングしているやつもいて、メーリングリストにメールを流すときにプレフィックスを忘れるとひどい目に合う。
もう、メーリングリスト作ったら、プレフィックスの指定は必須にしてよ！
じゃないと共有漏れが起こりやすいんだから！
データ保持用に、DtoとかDaoとか使うことは多々あると思う。
場合によっては、もう一個、２階層目のデータ保持用のクラスが欲しくなる。
しかし、禁止にされる。
クラスが増殖するのを辞めたい気持ちはわかるが、ツリー構造のデータを単一クラスで表現するには無理があるで！
しかも、データ保持方法がMapしか許さないってなったら最悪。
デバックしづらいだけでなく、不要なデータを持っていることがあり、メモリ圧迫の原因を作りやすい。
自動化って言葉に耳を貸しちゃダメ！！
騙されないで、相手の思うツボよ！！
自動化って言って、なんでもやってくれるわけではない。
自動化するための前準備が必要な事があり、それが作業ネックになることがある。
しかも、自動化ってのは認識齟齬が生まれやすい。
それを逆手にとる営業がいるから困ったもんだ。
支援や発注した側にとっては、自動化されているから即効でできると思っていてもできない。
本当に腹立たしい。
自動化という甘い罠には本当に気をつけるべきだ。
一般化してないツールを強要してくる。
OSSになっているものを独自で拡張して、それを強要してくる。
汎用性がまるでなく、浅はかな考えの実装が多いこと多いこと。
ドキュメントもないため、使う側がかなり困惑する。
使ってわからないことがあると、問い合わせをするのだが、返事が遅い。
遅延が発生しても、「うちらに問題ないですよ」みたいな雰囲気を醸し出しているから、余計に腹立たしい。
一発、腹パンかましてやろうかと思うことが、何度もある。
だいたい自己主張が強く、独善的なやつが多い気がする。
仕事する上で、こいつがトップに立つと、上手くいかない事が多い。
なぜなら、実力が伴っていないから。
そして、自分が絶対だと思い込んでいるので、説得させるのが辛い。
横文字を使いたくはないが、コミュニケーションボトルネックになる人は、たいてい指輪をつけている。
処理が遅くなるからダメと言ってきている。
本当にそうだろうか？
検証方法が間違っている可能性が十分にある。
並列処理するところを見誤っている可能性はないのだろうか？
個人的に検証したことがあるが、きちんと中間処理を行っていれば、Streamの方が高速化されるはずだが。。。
「Stream使っちゃダメ」って言っている人たちの頭の中を見てみたい。
継承を機能を複製するための機能だと思っている節がある。
複製するのではなく、機能を汎化してから、汎化したものを継承すべきだと思うのだが、間違っているのだろうか？
何度か継承を機能の複製として使っている現場を何度か見たことがあるが、大抵炎上するのがいつものパターンになっている。
呼び出し元に戻り値を返さないんだぜ。。。
いや、返しているんだけど、returnとかで返してない。
データクラスを別領域で持っていて、そいつを使って呼び出し元と呼び出し先のデータのやり取りをする。
ありえないだろ。。。
おそらく、ＦＷでリフレクション使っているんだろうけど、可読性が著しく悪い。
ソースを追う際に、いちいちソースファイルを探さないと行けないんだぜ。
eclipseなら参照先を開けばいいけど、それができない。
生産性を著しく落とす。
本当に、何がしたいのだろうね、このＦＷは。
考えたやつは、死ねばいいのに。
意味あるのだろうか？
引数は、もうメソッド固有だろ？
使いまわす可能性がゼロで、拡張したい場合、インタフェースも変える必要がある。
ただの手間でしかない。
クラス設計が正しくできているか疑いたくなる。
クラス設計したやつは、死ねばいいのに。
JavaScript使っちゃダメって言うんだぜ。。。
どうやって画面の要件をみたせっちゅうねん！！！
その現場で、ほとんどの画面はJavaScriptの実装が必要だったとさ。
死ねばいいのに。
このルールの意味が、ホンマにわけわからん。
JavaScriptでレベルが均等化できないのはわかるが、それはレビューでとれや！って言いたくなる。
ヘンテコルールを作ったせいで、開発を一時止めて聞く必要がある。
こんなルールを考えたやつは死ねばいいのに。
支援で開発に参加していたけど、仕様が確定してないのに設計かえるように強要してくるんだぜ。。。
そうしてにっちもさっちも行かなくなり、俺が責められる。
仕様変更が確定してもいないのに、命令出すんじゃねぇ！
死ねばいいのに。
Redmineでタスク管理しているのだが、共通処理の作成依頼を申請したら、申請が通ってクローズ。。。
意味がわからない。
その共通処理が完成して、完成しましたの連絡をもらって初めてクローズだと思うのだが。。。
なんでそういう運用なのだろうか？
どうやって完成したことを伝えるのか、疑問でならない。
実は完成しているけど、伝えていませんがあったら、袋叩きにしてやる！！
Redmineを使ったことがない会社なんだろうね。
死ねばいいのに。
開発者としてアサインされたはずなのだが、いつの間にやら外部の会社との問い合わせ窓口に。。。
俺よりも地位が高い人が誰もやらず、俺にお鉢が回ってきた。
なんで誰もやらないの？
その地位にいて、恥ずかしくないの？
積極的に動いた奴が、最終的に責任の重いタスクをやるハメになる。
しかも、そのタスクはスルーしておくと他者の遅延になるため、優先度が自分のタスクよりも高い。
ただ、こなす能力があれば、チャンスでもある。
こなせていないので、ピンチなのが腹立たしいが。
こんな状況に追い込んだやつら、死ねばいいのに。
ただの入れ物クラスなのに、Setter/Getterを作ってないとダメ！みたいなことを言う。
ただの入れ物クラスなにに、そんなものは必要なのだろうか？
なんでも変数はGetter/Setterでとることがオブジェクト思考だとでも思っているのだろうか？
役割が明確なクラスに無駄なメソッドを追加すれば、タイピングが遅くなる上に、コード量だけあるシステムができる。
コード量が多いシステムが立派だとは思えない。
適切な設計をして、適切なコーディングを行えば、コード量は減るはずだと思う。
話が脱線したが、なんでもかんでもGetter/Setter使えと共用するアーキの人は、物事がきちんと見えているのだろうか？
とりあえず、お決まりだから作ってといっているなら、死ねばいいのに。
もう、ただの愚痴になってしまった。。。
今の現場に対する不満が強い。
本当にシステム開発会社なのだろうか？
疑いたくなる。
自分が、今働いている会社は、大企業で正論を述べれば意見が通るけど、仕事を依頼してきた大元に対する不満が多い。
本当にシステム開発会社なのか疑いたくなる。
最後は、締めくくりに「死ねばいいのに」が常套句になってしまったな。
反応がよければ、もっと書こうかと思う。
末端のエンジニアの悲痛な叫びと疑問を、世間様に投げかけたい。
Javaエンジニアであるが、金銭面の問題、業務都合で行けないので参加。
一番大きな問題は金銭面かな。
あと、派遣で働いているので、どうしてもスケジュール調整が難しいのがある。
そして、英語がよく分からんのがネックだ。。。
一番聞きたいのは、JavaSE！一番良く使うからな！
https://jjug.doorkeeper.jp/events/52639
| 時間 | 内容 |
|---|---|
| 13:00-13:30 | 開場、受付 |
| 13:30-13:50 | 開会挨拶、JavaOne 2016 Keynote紹介 by 伊藤 敬さん (日本オラクル) |
| 13:50-14:40 | Java SE フィードバック by 久保田 祐史さん (@sugarlife) |
| 14:40-14:55 | 休憩 |
| 14:55-16:15 | Java EE フィードバック by Java Champion 寺田 佳央さん (@yoshioterada) |
| 16:15-16:30 | 休憩 |
| 16:30-17:00 | JJUG鈴木会長によるJavaOne 2016総括 by 鈴木雄介 (@yusuke_arclamp) |
| 17:00-17:45 | Duke's Choice Award 受賞記念 HeapStats講演 by 末永 恭正さん (@YaSuenag) |
今年は９月開催 Javaチャンピオンサミット 全体的にクラウド・マイクロサービスが多かったらしい。 JavaSEについての新しい話は、なし 目玉と言えるものは、Java + Dockerの話があったくらい JavaEEのロードマップ JavaEE8 2017年 JavaEE9 2018年 →やっとリリースサイクルが早くなったか。いままで遅すぎると心の中で思っていた。 Springに差をつけられすぎているので、改善の傾向があることは喜ばしいことではあるね。
キーノートは、スター・ウォーズのパロディ 日本で同じことやる場合は、人ではなく、アニメになるのではないかと思う。 たぶん、ガンダムかポケモンだな。
www.slideshare.net
2015年から変更がいっぱいある。
英語のドキュメントを参照すること。
日本語だと情報が古い可能性がある。
教育だけでなく開発でも使える。
外部から操作するなどが、主な利用用途。
Project Valhara
簡単に言うと、型と仲良くなることが目的のプロジェクト。
データをシンプルに扱えるようにするのが目的
Project Panama
CPUを使い切るプロジェクト。
CPUを社畜化しようぜ！ってことですね。
自分が社畜化するのは嫌だけど、他人がなるのは気分がいい！
削除される機能がいくつかあるので、利用ツールがライブラリの影響を受けないかチェックする必要がある。
Java8での非推奨・削除済みオプションは、起動できなくなるので、注意する。
javaの起動は、３世代前まで保証される。
Appletは、セキュリティ問題が多いので、廃止の方向へ。
Appletは、学生時代に学んだ。時代の流れを感じる。
非推奨のものが削除されているので、要確認すること。
GCのデフォルトは、ParallelGC→G1GCに変わるので意識しておく。
CMSGCは、非推奨化される。
Win32ClientVM→廃止
JavaDB→廃止
使うなら、MySQLやSQLite、PostgreSQLかな？
Propertyファイル→UTF-8が利用可能に。
寺田劇場。
JavaEEに不信感を持っている人が多い。
自分もその一人。
そのため、JavaEE Guardianが結成された。
その単語を聞いて、ゲート・ガーディアンを思い出した。
あの迷宮兄弟が使っていた、雷魔神・水魔神・風魔神が合体したやつ。
最後、MS製品の宣伝があった。
MSの宣伝のしすぎで、画面が映らなくなる天罰があった。
www.slideshare.net
ME, FX → キーノートはなかったが、活動は活発
JavaSEに進展はなし。
(この話を聞いて、いくつかの分野は別ベンダーが主管しても良いのでは？と感じた。)
(OracleがJavaをリードするには、Javaが超大すぎる気がする。)
(MEは、Googleに、FXはMicroSoftにとか。)
(Googleは、Androidで功績があるので、MEを主観するでも良い気がする。)
標準化の動きが鈍くなっている。
独自の進化で生き残ったものを標準化していく流れになる？
DevOps、Cloud、Microservices、Reactive
長くなったテストサイクルを短くするための議論が多かった。
サーバーレスへの感心が高まっている。
いいのは当たり前になっている。
どう管理するかに焦点があたり始めた。
データ共有・テスト戦略・疎結合が課題
細かくしすぎて、何が原因か分からない状態をミステリー殺人に例えていた。
(たぶん、犯人は家政婦が知っている。ハズ！)
なにか話していたが、あんまり記憶にない
日曜は情報処理試験、平日は、日が変わるまで仕事。
記事を各暇がなかったことが悔やまれる。
帰ったら速攻書くべきだった。
今後を考えると、Oracle以外のベンダーが旗振りに参加しても良い気がする。
先延ばしになっているJava9に、ちょっと不信感がある。
出る前に、OJCP8 Goldを取りたい。
