A description of the rainy season of Japan

I made a presentation slide and a composition for my English training.
It introduce about the Japanese rainy season.

www.slideshare.net

The Japanese rainy season is called “Tsu-yu”. In Kanji (the Chinese character), 梅雨. It means "plum rain".

Why is the rainy season called “Tsu-yu”?
Generally, Japanese rainy season starts the beginning of June and ends the middle of July. In this season, plums are ripening. So, we call the rainy season “Plum Rain”.

The rainy season is caused by the collision of a cold wind from the north and a warm wind from the south. Under the front of this collision, the weather is unstable.

It doesn't rain every day during Tsuyu, but we will have various kinds of rain such as light rain, heavy rain, intense downpours and sometimes rainstorms.

In this season, it tends to be very humid. We must take care of mold. And we can't hang the laundry outside. So, many Japanese people dislike this season.

However, we know that the rain that is brought by Tsuyu is very important for having a harvest.

We have some traditional culture to enjoy Tsuyu. For example, some of the traditional architecture such as wooden temples are designed to look more attractive in the rain.
Also, we can enjoy seeing beautiful hydrangeas during the Tsuyu season. It comes in many colors, blue, white, pink and purple. 

There is a Japanese tradition of making dolls with white cloth and hanging them outside of the window. It’s called "Teru Teru Bouzu”.
“Teru Teru Bouzu” literally means "Shine Shine Monk”. People think that Teru Teru Bouzu keep the rain away and bring sunny weather.

At the end of Tsuyu, we can see beautiful fireflies in the night at rivers, rice fields or parks.

I talked about Java community events at JJUG CCC Spring 2018

Last month, I talked about a Java community for first time attendees at JJUG CCC 2018 Spring.

JJUG CCC is a Java community conference organized by Japan Java User Group (Usually, the group is called JJUG).

This is the presentation slide of my session but it is only in Japanese.

www.slideshare.net

I explained why the community activities are important for Java. And I recommended that if they want to increase their knowledge of Java, they should join in our community activities.

In addition, I talked about my experiences with some international Java conferences.

The Oracle Code One (the original name is JavaOne) is the most important Java conference organized by Oracle. The first time I participated in the JavaOne conference was 13 years ago. At that time, I didn't speak English well. However, I was still very much enjoyed the experience.

I remember that John Gage, a startup member of Sun Microsystems, said "Don't be shy!" on the stage of the keynote session. It was an important rule of the JavaOne conference. A lot of Java developer come from all over the world. It is a golden opportunity to discuss, share some know-how, communicate and make friends.

His saying "Don't be shy!" echoes still in my mind.

Last year, I participated in the JBCNConf 2017. It is annual Java community conference in Barcelona, Spain. I was the only one Japanese attendee. I tried to communicate with other participants in my broken English. It required courage. However, John Gage's words whispered in my ear: "Don't be shy!".

About 10 months later, I got a message from a developer who lives in London. We had met in Barcelona. He said that he was comming to Japan to have a session at the JJUG CCC. He remembered JJUG because I introduced him to it. I succeeded in making a friend.

I also introduced JOnsen. JOnsen is an unconference of Java in Japan. There were about 30 participants. Half were Japanese, Half were foreigners. So, the common language was English.

However, an organizer said "JOnsen is the most relaxed unconference". In fact, we were so relaxed. We discussed about not only Java technology but also culture, diversity, education and community. In addition, we also enjoyed some leisure activities such as hiking, drinking and karaoke.

About JOnsen, there is a good entry written by Matthew Gilliard.

Matthew Gilliard's blog || JOnsen 2018

At the end of my session, I called on all attendees to participate in these international conferences. Of course, English is important. But it is just a tool. The most important thing is the mind. We must accross borders and share our knowledge around the world.

英語コミュニティ「en-jp meetup」第12回 参加した話

初心者に優しい英語コミュニティこと「en-jp meetup」の第12回に参加した話です。
en-jp meetup #12 - 2018/04/05(Thu) | en-jp (東京都, 日本) | Meetup

en-jp meetupは、英語を勉強している人のためのミートアップです。自己紹介やLT、懇親会まで含めてすべて英語縛り。ただし、相手の英語や発表内容の評論は禁止で、とにかく積極的に英語を喋ってみようというのが趣旨。なんの問題もなく英語を使いこなしている上級者もいれば、まったく英語には自信がない初心者もいて、ワイワイ英語で話をしている楽しい集まりです。

参加者はIT関係の人が多いですが、LTも含めてテーマの縛りは特になし。私は、前回はねぶた祭りを紹介するLTをやりました。
今回は、仕事でときどき海外(おもにポルトガル)に行っていることについて、どういう経緯でそうなったのかを話させてもらいました。基本的には、以前CLEM (Creators Learning English Meetup)でLTしたものの再演ですが、今回はすべて英語でチャレンジしました。

ポルトガルの話をするのはCLEMも含めて3度目なので、英語でも一応なんとか形にはなったかなとう感じ。

私のスライドは最初に日本語で組み立ててから英語に直すのだけど、それに対して懇親会で、最初から英語で作った方がいいよというアドバイスをもらいました。これはまさにその通りだとわかっていながら、実践には至っていないことです。まだ日本語ベースでないと全体の構成が頭にイメージできないというのが大きな理由です。

スライド作るときって、まず喋りたい内容をばーっと頭に浮かべて、その中から必要なものを取捨選択しながらストーリーを作るので、最初から英語縛りが入っちゃうとイメージを広げる作業そのものが英語力に引っ張られて制限されちゃう。圧倒的なボキャブラリの足りなさが一番の問題だとは思うのだけど。日本語→英語に変換する段階でも、情報量は半分以下に落ちてしまうので、もう少し伝えたいことを直接的に表現できるようになりたいです。

帰り道、渋谷駅の改札で立ち止まっていた外国人観光客の4人組がいたので(自動改札の切符の取り扱いで迷っていたっぽい)、声をかけて、品川に行きたいってことだったのでそのまま一緒に電車に乗りました。イスラエルから来たということだったので、妻が去年行ってすごく良かったと言ってたよーという話をしました。

品川駅別れた直後、今度はスマホ見ながら迷っている外国人がいたので声をかけたら、茅ヶ崎に行きたいということだったので一緒に東海道線に乗りました。ブラジルから来てレストランで働いてるというので、去年サンパウロ行ったよー、お肉がすごく美味しくて感激した、という話をしました。

以前よりは躊躇せずに話しかけられるようになっているので、少しは進歩しているかな。

青森ねぶた祭、全面VR化へ

青森市が、毎年8月に開催している青森ねぶた祭を2020年までに全面VR化する計画を発表しました。

青森ねぶた祭は毎年8月2日から7日の6日間に渡って開催されます。日本最大の夏祭りとも言われ昔から高い人気を集めていますが、それでも近年は観光客の伸び悩みや、踊り手である跳人(はねと)の減少などといった課題を抱えていました。

大型ねぶたを出陣する参加・運行費用の高騰も問題になっています。大型ねぶたの参加団体は22団体ありますが、その参加費用は、ねぶたの制作費も含めて2千万円以上とも言われています。最近では白熱電球の製造停止から、LED電球なども使われるようになり、団体の運営費を圧迫する一因にもなっていました。

そこで青森市では、運営費を抑えつつ、多くの人々に青森ねぶたを体感してもらえるように、祭りそのものを全面的にVR化することを決定したとのことです。企画を提案したA氏は、青森ねぶた祭のVR化について次のように語りました。
「VR化すれば、世界のどこにいても青森ねぶた祭の迫力を味わってもらえる。VRゴーグルを着けることで、遠隔で跳人として参加することもできる。東京オリンピックに向けて、外国人観光客への周知も進めていきたい」

VRねぶたのイメージ
f:id:zinbe:20180401100515j:plain

跳人のVR参加イメージ
f:id:zinbe:20180401100427p:plain

また、青森ねぶた祭とルーツを同じくする弘前市弘前ねぷた祭では、「青森がVRなら弘前プロジェクションマッピングだ」と、対抗して近代化を進める意気込みを見せています。人形型のねぶたを使用する青森ねぶた祭に対して、弘前ねぷた祭で使用するのは扇型の灯篭に絵を描いた扇ねぷたプロジェクションマッピングとの相性は良さそうです。

AndroidにおけるJava API使用の何がフェアユースではなかったのか

昨日の話の続きです。
nebuta.hatenablog.jp

Google翻訳に頼りながら判決文を眺めてみました。素人だし英語苦手なのでいろいろ誤解してるかもしれませんが、そのときはすみません。判決文の全文は以下に公開されています。
http://www.cafc.uscourts.gov/sites/default/files/opinions-orders/17-1118.Opinion.3-26-2018.1.PDF

前提

ソフトウェアのAPI著作権法の保護対象になるということは、2015年6月に最高裁判決が出ているので、残念なことですがこれはもう確定していました(正確には、2014年5月に控訴審判決が出て、Google最高裁に上告。翌6月に上告が棄却されて確定した)。

今回の争点は、「GoogleAndroidにおいてJava APIを無断流用したことがフェアユースにあたるか否か」です。米国の著作権法上は、フェアユースであれば著作権の侵害には当たりません。そこでフェアユースだとした地裁の判断に対して、Oracleが不服を申し立てたのがこの控訴審です。

4つの争点

フェアユースか否かの判断材料として、今回は以下の4つ要素がおもな争点として取り上げられています(各要素については後述)。

  • Factor 1: the purpose and character of the use, including whether such use is of a commercial nature or is for nonprofit educational purposes
  • Factor 2: the nature of the copyrighted work
  • Factor 3: the amount and substantiality of the portion used in relation to the copyrighted work as a whole
  • Factor 4: the effect of the use upon the potential market for or value of the copyrighted work

この4つのうち、Factor 1と4については"フェアユースではない"方向に、Factor 2については"フェアユースである"方向にそれぞれ有利で、Factor 3については中立的であると判断されています。

On this record, factors one and four weigh heavily against a finding of fair use, while factor two weighs in favor of such a finding and factor three is, at best, neutral. Weighing these factors together, we conclude that Google’s use of the declaring code and SSO of the 37 API packages was not fair as a matter of law.

(p.54)

ただし、Factor 2については"フェアユースバランシング全体に対してそれほど重要ではない"とも記されています。

The Ninth Circuit has recognized, however, that this second factor “typically has not been terribly significant in the overall fair use balancing."

(p.44)

これらを総合的に判断して、AndroidJava API使用については"フェアユースではない"という結論に至ったとのことです。

Factor 1: The Purpose and Character of the Use

簡単に言えば、AndroidJava APIを使っていることが商業的な性質が強いか否か、ということです。Oracleは、GoogleAndroidで莫大な利益を上げているから商業的だと主張していて、GoogleAndroidオープンソースだしGoogleの利益は検索エンジンによるものだからAndroid自体は非商業的だと反論しています。これに対して控訴裁では、商業的か否かはその利益が金銭的であるかどうかや、直接的に得られるものであるかどうかに依存しないので、Androidは商業的であると結論付けています。

それからもうひとつの大きな論点として、"transformative"であるか否かということも挙げられています。transformativeという用語をうまく解釈できなかったのですが、どうやら新しい価値を与えるような使用方法かどうかということのようです。Oracleは、Googleは単にAPIをコピーしただけだからtransformativeではないと主張していて、Googleスマートフォンという新しいプラットフォームを作ることが目的だったと反論しています。

地裁ではGoogleの"transformativeである"という主張は認められて重く評価されたようですが、控訴審にあたっては逆にGoogleの主張が退けられました。根拠としては、スマートフォンといえども同じAPIを同じ目的で使っていることに変わりはないことなどが挙げられています。

この控訴審にあたってOracleは、数千行のOracleJavaコードがAndroidでそのまま使われているという証拠を提出していて、これも地裁の判断を覆す大きな材料になったようです。

Factor 2: Nature of the Copyrighted Work

APIを設計という行為が創造的なものであるかどうか、という争点です。まず、コンピュータソフトウェア自体は、著作権法で保護されるべき対象という前提はすでに確立されています。そして、APIパッケージの宣言コードとSSO(Structure Sequence Organization)が著作権法の保護対象だということはすでに結論が出ています。

その一方で、APIの宣言とSSOの創造性というのは”最小限のもの”であり、APIというのは創造的な側面だけでなく機能的な側面も重要であることから、これを使用することはフェアユースであるというのがGoogle側の主張です。地裁ではこの主張が認められ、控訴審でも肯定的に判断されました。しかし前述のように、それ自体が全体に対してあまり重要ではないとされています。

Factor 3: Amount and Substantiality of the Portion Used

元の著作物の量的および質的な価値はどれくらいのものか、という争点です。これについては、開発者の負担を軽減するために、既存のAPIを流用するという行為がAndroidプラットフォームを作るにあたって重要であったことはGoogleも認めています。

Factor 4: Effect Upon the Potential Market

AndroidOracleが本来持っていたはずの潜在的な市場での価値をどの程度損ねたのか、という争点です。これは、フェアユースの「元の作品の市場性を著しく損なうことがないようなコピーに限定される」という考え方を反映したものだそうです。

Googleは、Oracleがデバイスメーカーではないことや、まだスマートフォン市場を開拓していなかったことなどを挙げて、AndroidOracleの市場を奪ったことはないと主張しており、地裁もそれを認めていました。しかし控訴審では、スマートフォンOracleの"潜在的な"市場であったことは疑いがなく、デバイスメーカーでないことも(自分で作らなくてもライセンス供与などの方法があるので)意味のない主張だという結論が出されました。

結局、APIはコピーしちゃダメなの?

これらの争点のうち、Factor 1/3/4については"Androidの場合"という前提での話であって、別のケースであれば違った判断がくだされる可能性もあるでしょう。要は、フェアユースと言い切るにはGoogleが儲けすぎていて、Oracleが進出して儲けられる可能性を奪ってるよね、という話です。Oracleの主張が認められた形ですね。

一方でFactor 2は、APIの宣言コードとSSOは(著作権法で保護されるべき)創造性を持っているけど、機能的側面も強いからフェアユース性もある、ということを認めています。ただし、それはフェアユースであるか否かを判断する他の要素に強い影響を与えるものではない、ということです。

もともとフェアユースかどうかは個別の事案で判断される性質のものなので、今回の判決だけですべてのケースが決まるというわけではありません。特に今回は、商業活動であるかや、潜在的な市場価値にどれだけ影響を与えたかということが決め手になっているので、この点が非常に大きな意味を持っていると思います。

AndroidによるJava APIの使用は著作権侵害に該当するという判決

詳しくないので間違いがあったらすみません。

控訴裁判所が、Java APIの使用に関するOracleGoogleの争いに新しい決定を下したようです。Oracleによる「GoogleAndroidによるJava APIの使用はフェアユースには当たらず、同社の著作権を侵害している」という主張を認め、地方裁判所に損害賠償の裁判を差し戻すという判決が出されました。
Oracle wins appeal against Google in copyright case – TechCrunch

今回の判決

判決文は以下にあります。
http://www.cafc.uscourts.gov/sites/default/files/opinions-orders/17-1118.Opinion.3-26-2018.1.PDF

最後のConclusionに次のように書かれています。

For the foregoing reasons, we conclude that Google’s use of the 37 Java API packages was not fair as a matter
of law. We therefore reverse the district court’s decisions denying Oracle’s motions for JMOL and remand for a trial on damages. The district court may determine the appropriate vehicle for consideration of infringement allegations regarding additional uses of Android. We dismiss Google’s cross-appeal.

私たちは、Googleの37のJava APIパッケージの使用は、法律上のフェアユースではないと結論づける。したがって、JMOLに関するオラクルの申し立てを棄却した地方裁判所の決定を取り消し、損害賠償の裁判を差し戻す。(後略)

言葉通り、フェアユースではないということは著作権侵害にあたるということなので、最初の損害賠償請求の裁判に戻すよ、ということです。

これまでの経緯

OracleGoogleの争いに関するこれまでの経緯は、2016年7月のJJUGナイトセミナーの様子をレポートした次の記事に詳しくまとめられています。
Google対OracleのJava API訴訟。歴史的経緯とIT業界への影響を考える(その1)。JJUGナイトセミナー - Publickey

重要な部分のみ抜粋すると、

  1. GoogleによるJava使用は特許侵害ではないという判決がでる(2012年5月)
  2. API著作権法で保護されるという判決がでる(2015年6月)
  3. GoogleAndroidにおけるJava API使用はフェアユースにあたるという評決がでる(2016年6月)

最初の2つは、すでに判決が出てしまっているので確定事項です。また、2のAPI著作権法で保護されるというのはJava APIに限定されたものではないので、非常に広範囲に影響するということで大きな話題になりました。

API著作権があるとしても、Androidにおける使用はフェアユースだから著作権法の保護の対象にはならないよ、としたのが3つ目の評決です。判決文のJMOL(Judgment as a Matter Of Law)というのがこの判断のことを指しています。

その後、Oracle地方裁判所に対して新たな審理を求めましたが、2016年9月に棄却されています。これが「JMOLに関するオラクルの申し立てを棄却した地方裁判所の決定」というやつです。そのあたりの経緯やOracleの主張については、下記の記事で解説されています。

オラクル、グーグルによるJava APIの使用めぐり上訴 - ZDNet Japan

今回の控訴裁判所の判決では、"フェアユースに当たる"とした判断そのものが覆されたわけです。なぜ覆されたのかは判決文に書いてあるようですが、難しそうなので読んでいません。誰か読んで教えてください。

追記:
判決文をもう少しちゃんと眺めてみたので、こちらも参考にしてください。
AndroidにおけるJava API使用の何がフェアユースではなかったのか - 我らねぶた馬鹿

今回の判決はあくまでもOracleGoogleの個別事案

勘違いしやすいので注意しなければいけないのは、「API著作権法で保護される」というのは、今回の判決に関係なく2015年にすでに確定してしまっています。

そしてその後にOracleGoogleが争っていたのは、「AndroidにおけるJava APIフェアユースにあたるか否か」という個別の事案であって、この裁判の判決が、世の中にあるそれ以外のすべてのAPIに適用されるというわけではありません。

今後どうなるか

気になるのは今後Androidがどうなるかということですが、これからまた損害賠償請求裁判をやり直すわけなので、すぐにどうこうなってしまうということはないかと思います。ただ、次にGoogleがどう出るかには注目しておいた方がよさそうです。長期的には、GoogleJavaを見限るという極端な展開も含めて、いろんな可能性がまた復活しちゃったなあという感じですね。

JJUG ナイトセミナー 「Java SE 10 / JDK10リリース特集」に参加した話

3月26日(月)に開催されたJJUGナイトセミナー「Java SE 10 / JDK10リリース特集」に参加してきました。タイトル通り、先日リリースされたJava 10の新機能などについて特集する会で、参加者240人枠の予約がすぐに埋まり、さらにキャンセル待ち200人以上という盛況ぶりでした。やはりみんな関心があるんですね。
【東京】JJUG ナイトセミナー 「Java SE 10 / JDK10リリース特集」 3/26(月)開催 - 日本Javaユーザーグループ/Japan Java User Group | Doorkeeper

どうでもいい話だけど、Java 10と書けばいいのか、JDK 10と書けばいいのか、はたまたJava SE 10と書けばいいのか未だに戸惑いますね。

新しいリリースモデルのおさらい

まずはオラクルの伊藤敬さん(@itakash)から、新しくなったJDKのリリースモデルに関するおさらいから。

もういろんなところで言及されているように、OSS版であるOpenJDKについては、年2回6ヶ月毎(3月と9月)のメジャーリリース、3ヶ月毎(1、4、7、10月)のパッチリリースというサイクルになります。原則として各バージョンでリリース期間は重複しないので、次のバージョンが出たらそれまでのバージョンは非サポートになりますが、3年毎にLTS(Long Term Support)版が出ます。直近のLTSは次のJDK 11です。

Oracle JDKは、次のJDK 11以降で新しいリリースモデルが適用されて、以降は有償版のみの提供となります。リリース間隔は3年ごとで、サポート期間はそれぞれ8年間。OpenJDKと同様に3ヶ月毎に(1、4、7、10月)パッチリリースが行われます。なお従来Oracle JDKの有償版にのみ提供されていた機能については、段階を踏んでOpenJDKに移行されるので、Oracle JDKとOpenJDKは同等の内容になります。

これまで無償版のOracle JDKを使っていたユーザは、Oracle JDKを有償サポートで使うか、OpenJDKに移行するかという選択を迫られています。非LTSなOracle JDK 8のサポート期限が2019年1月(個人利用の場合は2020年12月)なので、猶予はそれほどありません。
Oracle Java SE サポート・ロードマップ

ただし、これまでのOracle JDKも無償版に関してはOpen JDKと同等のものだったので、この機会にOpenJDKに移行してしまってもそれほど大きな問題にはならないと思っています。その場合、常に最新機能に追随して6ヶ月毎にアップデートを頑張るか、LTSで3年毎にアップデートするかという選択になりますね。
それよりも問題は、Java 8からJava 9にかけては多くの非互換性が含まれているので、Oracle JDK 8のサポート期限である2019年1月までに移行を完了させられるかということに尽きますね。これから始めるプロジェクトに関しては、Java 9以降(現実的にはJava 11)をターゲットにする想定した方がいいと思います。

JDK 10の追加機能の解説

続いて、David Buckさん(@DavidBuckJP‏)によるJDK 10に追加された新機能の解説。あとから資料が公開されるので細かい話は両略しまし(公開されたらリンクを追加します)。あと、Qiitaのきしださんの記事もよくまとまっていて分かりやすいです。

Java 10新機能まとめ - Qiita

Buckさんの話の大部分は、JEP 286のローカル変数型推論についての話でした。いわゆる、Java版の「var」です。JDK 10以降では、変数の宣言時にvarを指定することで明示的に型を指定しなくてもよくなりました。これはあくまでもイニシャライザの型から自動的に静的型が推測されるだけなので、動的型とは全く違います。型を書かなくてもいいというだけで、内部的には型があります。

varが導入されたことで、Javaのコーディングスタイルは大きく変わる可能性があります。ということで、OpenJDKプロジェクトからvarを使う場合のスタイルガイドが公開されています。Buckさんの解説もこのスタイルガイドを元にしたものです。「Oracle Blogs 日本語のまとめ」に日本語訳があります。

Oracle Blogs 日本語のまとめ: [Java] Style Guidelines for Local Variable Type Inference in Java

ここでもっとも重要なのは、"varはコードの可読性を上げるために使う"ということだと思います。タイプ量を減らすといった目的ではなく、あくまでもコードをシンプルにして読みやすくするために使うということです。明示的な型宣言が無いとコードが読みにくくなりそうですが、実際にはコードを読めば何の型かはすぐに理解できるので問題なく、逆に可読性が上がるという結論が多くの言語で出ているそうです。面白いですね。

Java 10でぼくたちの生活はどうかわるのか

最後に、久保田祐史さん(@sugarlife)ときしだなおきさん(@kis)によるセッション。おもに、新機能や互換性などの情報をどう追っていったらいいかという話や、Java 10に移行する上ので注意点などに関する話。これも資料が公開されるそうなので、細かい話は省略します。

Java 10以降におけるアップデートの手順は

  1. (既存プログラムを)再コンパイルせずに新しいJava環境で動かしてみる
  2. 非対応ライブラリや非推奨APIを洗い出す
  3. 非対応/非推奨部分を代替手段に置き換える

という感じにするのがいいそうです。非対応ライブラリの洗い出しには、jdepsやjdeprscanなどのツールを使います。jdepsはライブラリの依存関係を調べるツールで、deprscanは非推奨なAPIが使われている場合に、それを検出するツールです。

個人的に気になって質問したのは、新バージョンの検証をどれくらいのタイミングで初めていくのがいいかということです。これまではリリースサイクルがゆっくりだったので、JCPが固まって参照実装が出たくらいから検証を始めて、リリース後ある程度こなれてから対応というスパンでも十分でした。新しいリリースサイクルだとあまりのんびりしている時間はなさそうなので、これがどう変わるかということです。

LTSを移行ターゲットにしつつ、その間にリリースされたバージョンを順番に検証していくという形が現実的でしょうか。OpenJDKのリポジトリを追えばリリース前にも検証を進めることは可能だけど、そのサイクルを追うのはさすがにしんどいので、LTS以外は正式リリースを追う形でもいいんじゃないか、というのがきしださんの見解。私も同意です。

また久保田さんは、「まずは Java8 → Java9 を乗り越えること。それさえ乗り越えられれば、その後のバージョン間の差分(新機能とか非互換性とか)はそれほど大きくないので、あまり怖くないはず」とおっしゃっていました。

あと「創るJavaはいつ出るか?」という質問の意図について書こうと思ったけど、長くなったので別の機会にします。

Java Day Tokyo 2018に関するアナウンス

伊藤さんから、Java Day Tokyo 2018関するアナウンスがありました。Java Day Tokyo 2018は5月17日(木)開催。基調講演に、なんとMark Rainhold氏の来日が決まったそうです。これが昨日の一番の驚き。参加登録サイトは近日中に公開予定とのこと。

JJUG CCC 2018 Springに関するアナウンス

JJUGより、 JJUG CCC 2018 Springに関するアナウンスがありました。JJUG CCC 2018は5月26日(土)開催。今月末までCall for Paperを募集中なので、ネタを持っている人は怖がらずに応募して欲しいとのことです。
JJUG CCC 2018 Spring