2012年7月30日月曜日

Jenkinsハッカソンに参加してきました。

私がヴィムである。

そろそろこのネタ飽きてきましたね。

ビーサンとボロボロのジーンズで…


熱いオッサンのできるビジネスマンの溢れる街

溜池山王で開催された

Jenkinsハッカソンに行ってきました。


内容はプラグインを作ってみること


川口さんやJenkinsのコミッターの皆さんと一緒の部屋で、

Jenkinsプラグインを作成するという

非常に濃ゆいハッカソンでした。


具体的な手順などは


ここを参照して下さい。

僕は二度三度と同じ事をやらないと覚えられないくらい

残念な頭の持ち主なので、

Hello World的なプラグインを2回ほどつくりました。

プラグインのUI(jellyファイル)とhudson.tasks.Builder

あたりはなんとか理解できた気がします。


作りたいもの


本当はFxJsJUnit用のプラグインを作りたいと思っています。

で、そんな話をしたら、参加していたインド出身のエンジニアの方に

興味を持っていただきました。

嬉しいですね!

8月のオレオレタスク早めに終わらせて、

FxJsJUnit作りを早めようかな!







2012年7月29日日曜日

Jenkinsカンファレンス2012に行ってきたよ

私がヴィムである。

あじ~、だりぃと言う猛暑の中、

Jenkinsカンファレンス2012を聴講しに行って来ましたよ。

え、おい!


会場に到着して、前の方の席に言った途端、

いんだれさんに声かけられました。

「みけ、手伝って!」

というわけで、そのまま拉致られて

即席スタッフになりました。


その結果


JenkinsのTシャツもらいました。


ありがとうございます。


印象


参加申込みは1,000人を超えているようでした。

実際は少ないと思いますが…。

凄いですね。

というわけで、Jenkinsに対する関心が高いことがよくわかりました。


セッション?


まあ、スポンサーセッション担当ということで、

スポンサーセッションをずっと聞いていました。

とはいえ、スタッフなので全体がうまく流れることのほうが

気がかりで、とても話を聞いているような状態ではなかったのですが…


内容としてはプロジェクトやチームに

Jenkinsをどのように適用していくか?

という話題が多かったと思います。


懇親会


行きませんでした(´・ω・`)


結論


JenkinsはContinuous Integration/Delivery の

デファクトスタンダードツールとしての地位を

獲得していますね。


というわけで、明日はもう少し詳細を知るべく、

ハッカソンに参加してきます(`・ω・´)





2012年7月28日土曜日

7月成果

ワ・タ・シがヴィムであーる。

暑いですね。

早いもので人間、じゃない会社員をやめてから、

もう4ヶ月過ぎちゃいました。

7月のまとめ


成果は大して上がっていないかも…

  • Fx-Js-JUnitの公開 : あと少し…orz
  • Gradle - gitignore-plugin : 公開
  • JavaFX勉強会でのLT : 目標達成
  • Gradleトーキョー開催 : 目標達成
  • ソートアルゴリズムの車輪の再発明 : 下記のアルゴリズムを復習
    • バブルソート
    • 選択ソート
    • 挿入ソート
    • マージソート
    • クイックソート
    • ヒープソート
  • ちょっとだけErlangの勉強

所感


Gradle

Gradleに関してはカスタムプラグインの作り方が分かったので、

まあ、よしとします。

mavenセントラルリポジトリーへの公開は9月の課題ですかね。

Fx-Js-JUnit

Fx-Js-JUnitはあと少しで皆さんにお使いいただけるレベルに

なるんですが、残りあと少しというところがきついんですよね。

きついんで、サボっております。

これも9月かな…

あと、このフレームワークの課題として、

テストが複数起動できないという弱点があるので、

テストランナーレベルでの実装が必要かと

考えています。

これはGradleやJenkinsでのプラグインで解決する方向で、

9月以降やりたいと思います。

ちなみにこれにWebサーバーやJavaEEサーバーも

載せたいと思っているので、

それらを含めて9月以降ですかね。

岡山の年末忘年会くらいにはお披露目できるかも。

その前にお金が亡くならなければいいですが…

アルゴリズム

ソートとかは単に『アルゴリズムを学ぼう』を読んで

JavaScriptで写経して、qunitでテストするという感じです。

アルゴリズムは、情報処理技術者試験での勉強中に

軽くやっただけだったので、結構面白いです。

この本はオススメですね。



Erlang

JGGUG総会およびワークショップで

並列計算フレームワークJCSPが取り上げられたことや、

Fx-Js-JUnitでマルチスレッドの勉強をしたこともあり、

並列計算というのが気になっています。

というわけで、もとから並列計算に特化した言語である

Erlangをやり始めています。

本当にやり始めなので、


で勉強する程度です。

まあ、これは教養の話なので、一日20分程度ずつやっていきます。

総括


全般的に見ると、今月の興味は次のとおりだったと思います。

  • 並列処理
  • JavaScript/Erlang等型付けの弱い言語

どちらも最近花形と呼ばれる分野ですね。

一般的な社畜プログラマーとしては関わりは

ない分野ですが、

今後のユーザー・エクスペリエンス向上に

欠かせない分野だと思っています。


8月は


夏ですので、特別強化月間として、

いまさらですがObjective-Cをやります。


ちょっとした仕事がiPhoneでの開発が入っていたりして、

仕事が取れないという場面が最近よくあるので、

Objective-Cをやって幅を広げようと思います。



2012年7月27日金曜日

夏サミ行ってきましたよ。

ワ・タ・シ・がヴィムだ!

夏といえば…


夏サミですよ!

ということで、『Developers [Enterprise] Summit 2012』

行ってきました。


結論


Yammerとかchatterを使って業務システムを構築しているところは、

今のところアーリーアダプターのようなので、

ソーシャルな業務システムを取り込めば、

ビジネスで先手を打てるかもしれません。

という感じで押していました。


自分的には…


まあ、逐次ツイートなので、そのままなんですが、










優秀な人材を求めている会社は、

自分のところのソースを公開して、

エンジニアに興味を持ってもらう。

一方、エンジニアは自分のコードを公開して、

積極的に発信して世間にアピールする。

そういうオープンな(言い換えると自ら発信していく)姿勢が

今後生き残るために、求められるのかなと思います。


因縁の場所


実は会場ですがそのビルですが、

前の前に務めていた会社で一時期そこに勤務していました。


前の前の会社はいわゆるSIerであり、

そこで僕は出来損ないの社畜だったわけで、

そんな僕が今こうして無職で自由な身で

先端を行く人達の話を聞けるとは、

社畜だった頃には想像がつかなかったとおもいます。


gdgd


一つ前のエントリーと関連するかもしれませんが…


エンジニアを名乗るには、その主たる商品である

お客様であるユーザーや企業に買ってもらえるために

自らを磨いていかないと厳しいですよね。

それはマルクスの『資本論』にも書いてあることですね。


一方買う側の心理学は投下資本の回収をメインに書いてあって、

そのあたりに対する皮肉を色々と書いてあったりします。


今回の夏サミの結果を以って、もう一度『資本論』を読み直したら、

再発見ができそうです。


終わり


ConfluenceのTシャツを着ていたので、

大沢さんにお声がけいただきました。

ありがとうございます。

今度、AtlassianのTシャツください!



社畜再生産の仕組み

こんにちわ。

ヴィムです。

おや、めずらしい


いろふさんと意見がたまたまのたまがたま、一致しました。








言外にあるもの


僕はこれらの言葉の外にあるものを

社畜を社畜たらしめていると思っています。

それは、事前に立てたスケジュールが絶対であるという

強迫観念です。


スケジュールが遅れるのはなんで?


新人さんはスキルもどのくらいあるか分かり得ないので、

与えられたスケジュールを守れるかどうかというのは、

事前にもわからないし、やってみてもわからない。

それは、スケジュールを立てた人にとっても同じです。

また、タスクによってはスキルのある人でもスケジュール遅れることあると思います。


スケジュールの遅延は何が原因となって発生するかなんて、

神でもない限りわからないことが多いです。

スケジュールの組み立て方が適当だったとか、

思っていたよりも機能が複雑だったとかかんとか。

僕のように気分のムラッ気が多い人だと、

自分の精神状態までもがスケジュールの遅れに

関わってきます。


ただし、たてたスケジュールが絶対であるという考えがあると、

(特に新人さんは)タスクを遂行する自分に非を求めてしまいがちです。


その判断には、スケジュールから遅れていることによる

パニックな状態からもあるかもしれません。


遅延を回復する


スケジュールの遅延への対応は、いろいろとあるかもしれません。

  • 残業して作業時間を確保して対応する。
  • スケジュールを変更する。
  • 作業効率が上がるような改善をする。
  • 無駄な作業をやらない。
  • 作業員を増やす。


それぞれに一長一短があると思いますが、

ここでは主に(1)について考えます。。


この方法は作業時間が増やせます。


しかし、経営者的には残業手当分のが負担増えますし、

メンバー的には作業のパフォーマンスに影響があります。

若いうちは大丈夫かもしれませんが、

僕のようなオッサンになると確実にパフォーマンスが下がります。

若くても、残業時間帯の作業効率も日中の疲労の蓄積もあり、

けっこう、効率が悪かったりします。


作業パフォーマンスが下がるというデメリットを考慮した上で

残業してもよいかどうかの判断を上長に確認するべきであると思います。


思考停止…言外にあるもう一つのもの




人によっては異なると思いますが、

残業をすることによる時間の確保というのは

IT業界の中では特に考えもなく採用することもあってか、

わりと寛大な態度だったりします。


思考停止ですね。


自分が通ってきた道なので、新人にも通らせたい。

よくありがちな先人思想です。


そして、その考えを押し付けられる人も、

長い教育の間で先人の考えに従えという教えの下に

生きてきたわけで、疑う余地も無いですね。


だから双方とも残業をするということに対して

思考停止しているとおもいます。


余談ですが、僕は社畜だった頃は積極的に残業して、

残業代が欲しかった人です。

貯金5M溜まったのにな…(遠い目


残業すると税金が高くなる


まあ、僕はそんなわけで新人の時たくさん残業をしてお金をためたのですが、

税金が大量にかかって、二年目は生活が辛かったです。

で、それをカバーするために残業してというような生活をしてしまいました。


残業というのは一度始めると、

辞められなくなるんですね。

一度残業して(手取りでない)給与が高くなると、

手取り給与を確保するために残業するという悪循環になってしまいます。




勉強


…ブログ記事書くの面倒になってきた…(´・ω・`)






2012年7月26日木曜日

正しくないプロテインの飲み方

こんにちわ。

ヴィムです。

神が舞い降りてきた


ふとネタを思いついたので、

ブログ書いています。

正しくないプロテインの飲み方


みなさんはプロテインを飲んだことありますか?

僕は高校時代にほぼ毎日飲んでいて、

まずくて泣きそうだったので、

その後大学時代に教えてもらった飲み方を試したら、

まずいと感じず飲めたので、紹介します。

この飲み方が正しいか正しくないかと言ったら、

多分正しくないです。

でも、胃の中に入れば同じです。

飲み方


1.プロテインの粉を口に入れます。


2.水を口に入れます。


3.一緒に飲み込みます。


4. 1.〜3.を3回繰り返します。

ほら飲めた!

2012年7月22日日曜日

TDD in Actionに参加してきた

涼しいですね。体調が悪くて死にそうです。

みけです。

JavaScriptで参加してきた


最近はJavaとかGroovyは毎日やっているので、

たまには違うものをやりたかったので、

JavaScript + qunitでの参加となりました。


ペアプロ


ペアを組んでやりましょうということで、

@tomy_kairaさんと組んでやりました。

トミー君はemacs的な人で、僕はWebStormなので、githubを介してTDDしてました。

僕はここ二日間の調子が悪くて、頭がどっか行っていたので、

「あー、いいねー…あー、うー」という感じでしたので、

トミー君の頭の回転には脱帽という感じです。


成果物


途中までできました。

github上にあるので、まあ見てみて下さい。

mike-neck/Tdd-In-Action


qunit


今回使ったのはqunitですが、

まだ使い始めたばっかりだったので、

うまく使いこなせていない感が半端無かったです。

ここで、実現できている機能とかは、Fx-Js-JUnitでは最低限実現したいところではあります。


Erlang


後半のほうでgdgdな時間が発生していたので、

一人でErlangの勉強していました。

こっちは大した成果はありません…

2012年7月18日水曜日

Gradle カスタムプラグイン作ってみた

あ゛ぢ゛い゛

みけです。

某java-jaのイベントにて




ということが話題に上がったので、

そういえば作っていないな(白目

って、ことで、いつも面倒な.gitignoreファイルを

Gradleのプラグインから類推して作り出す

プラグインを作ろうと思った。


参考サイト


参考サイトといえば、@bluepapa32さんのブログがとにかく秀逸!

プロパティファイルを native2ascii するためのプラグインを作ってみた

Gradle のカスタムプラグインを JAR ファイルで公開する方法

これと後は、gradle-gae-pluginのgithubを参考にしました。


build.gradle


build.gradleはこんな感じ。




coreというモジュールのdependencyに、gradleApi()とあります。

こいつが、カスタムプラグインを作る時のミソです。


プラグインの本体はcore/src/main/groovy/og/mikeneck/gradle/git/GitIgnorePlugin.groovyというファイルになります。



このコードのproject.task('git-ignore')という部分によって、

タスクgit-ignoreというタスクが作成されます。

あと、プラグインの名前ですが、core/src/main/resources/META-INF/gradle-plugins/gitignore.propertiesというファイルの

ファイル名でプラグイン名が決定されます。

この場合だと、
apply plugin : 'gitignore'

で、利用することができます。


勉強会


まあ、このあたりのことは明日(2012/07/19)の勉強会にて話します。


目標


大したプラグインではありませんが、

Sonatype OSS Maven Repositoryに載せたいと思います。


2012年7月15日日曜日

JavaScriptでStringを拡張した

暑い。

みけです。

JavaScript面白いよ


JavaScriptの面白いところは、メタプログラミングができるところ、

インスタンス後にもメソッド拡張ができるあたりです。

詳しい話は下記の本に譲りますが、そういうところが好きです。




というわけで、


JavaScriptのStringにメソッドを拡張してみました。

拡張したメソッドはeachメソッドで、

最近のモダンな言語なら大抵持っている語彙と同じで、

文字列の中の一つ一つの要素にクロージャー(関数)を適用する

というものです。



実行結果がこれ。



ういやつです、JavaScript。



2012年7月10日火曜日

その設計は適切ですか?

大分、咳が収まりつつあります。

みけです。

今週はネガティブになってしまう週(二週間を周期とする気分の波があります)なので、

ネガティブなことをいろいろと書き殴りたい気分ではあるんですが、

思ったことを少しだけ書きます。


共通化関数


まあ、ツイッターで結構出回っているので、

皆さんすでに読まれているかと思います。

日々常々 - 誤った共通化

あのKBNという変数名、嫌ですね。

なんとかならないかと思います。


まあ、そんなことを言っている当の私も数年前はKBNであったし、

エクセル方眼氏をこよなく愛していたわけですが…

指摘されているような過ちを平気でやっていたのですが…


最近だと同じような状況だと、

次のような設計・実装にすることが多いです。


public class Printer {
    private java.io.Writer writer;

    public void setWriter (java.io.Writer writer) {
        this.writer = writer;
    }

    public void writetGreeting (Language language) {
        writer.write (language.getGreeting());
    }
}

public interface Language {
    public String getGreeting();
}

public enum AncientLanguages implements Language {
    LATIN {
        @Override public String getGreeting () { return "Lorem"; }
    },
    GREEK {
        @Override public String getGreeting () { return "Γεια σας"; }
    }

    @Override public String getGreeting();
}

public class LanguageService {
    public void writeGreeting (Writer writer, String language) throws IllegalArgumentException {
        Printer printer = new Printer();
        printer.setWriter(writer);

        Language lang = AncientLanguages.valueOf (AncientLanguages.class, language);
        printer.writeGreeting (lang);
    }
}

enumを一つの状態を表すので、それに何かをさせるのがあるべき姿かと

考えています。なので、enumにメソッドを実装させることが多いです。



設計の適切度の指針としてテストを利用する


上記の例で言えば、比較的テストは簡単に書けます。

public class PrinterTest {
    @Test public void testGreeting {
        StringWriter writer = new StringWriter ("test-");

        Printer printer = new Printer ();
        printer.setWriter(writer);

        Language language = new MockLanguage ();
        printer.writeGreeting(language);

        assertThat(writer.toString(), is("test-hoge");
    }

    private class MockLanguage implements Language {
        @Override public String getGreeting () { return "hoge"; }
    }
}

こんな感じで、モッククラスを二つ準備するだけで、テストが書けます。
  • WriterStringWriter
  • LanguageMockLanguage


しかし、このPrinterクラスが依存するクラスが多かった場合、どうなるでしょうか?

おそらくテストコードは読みづらいものになっていたと思います。

例えば、こんな感じ。




モックするクラスが多いクラスというのは、

一つのクラスでいろんなことをやろうとしているクラスです。

つまり、責務分割がしっかりなされていない設計になっているといえます。


クラスに保持するフィールドは三つ以下にする


これは『プロダクティブプログラマー』に書いてあった

内容です。(間違えているかもしれません)


もし、フィールドがそれ以上増えるようでしたら、

そのクラスの責務が多すぎるようなので、

再設計を検討して下さい。


以下、参考書籍。





読んだことありませんし、持っていませんが…


読みづらいテストコードの元例の書いてあった本。
ちなみにモックの数が多い場合は、責務が大きくなっているので再分割することを検討して下さいとも書いてあった…

2012年7月8日日曜日

GroovyのmetaClass.defineでインターフェースメソッドをオーバーロードしたいんだけど

寒いですね。このままだとかき氷屋が倒産してしまいますね。

かき氷屋が倒産する→シロップメーカーが倒産する→サトウキビ売れなくなる→沖縄の人困る

いやですね。

みけです。

メソッドをオーバーロードしたいなぁ


グルービー語をやっている人は常々こういう欲求に駆られてしまい、

いつの間にかメソッドをオーバーロードしていることがあります。

たとえば、Integerを単純に表示するだけでは面白く無いので、

toStringメソッドにClosure<&Stringgt;を引数で取るようにして、

出力を変えてみたいと思ってしまいます。

Javaでやると、こいつは大変で、Integerの持っていた計算性を失って、

拡張するという覚悟を取らなければなりませんが、Groovyでは、

Integerの可算性を損なわずに拡張できます。






並行処理プログラミング


まあ、さっきのはどうでもいいんですよ。

事の本質は並行処理プログラミングの話です。

昨日のCSPモデルをjava.util.concurrentを使って模してみた

プログラムを普通に書いてみました。

ちなみに仕様としては

  • 0~9のランダムの数値をスレッド間で送受信する
  • 0が二回連続して送信されると終了する
  • 送受信が終了すると、これまで送受信された数値の合計が返される

といったものです。




…長いですね。

で、嫌なところは、17行目などにあるnew Callable<Integer> @Override Integer call()

といったあたりですね。

非常にまどろっこしいです。

なので、本当はこう書きたいんです。



ExecutorServiceのメソッドsubmitが引数にクロージャーを取れるように

すれば、なんと7行もコードが短くなるんです。

まあ、Java8になれば、おkなんですがね。



グルービスト


Java8まで待てないということもあるので、

そういう場合のグルービストはこんなことをやるのです。



さて、拡張したExecutorServiceを読んでみるとこうなります。




あれ、値が…


値が戻って来ませんね…

とつぶやいているうちにふもさんからアドバイスもらいました。





なるほど、メソッド名がかぶっているとだめなのか…

あれ、でも、さっきのIntegerの場合だとどうしておkなの?

うーんと悩んでいると、えいやさんからこんなアドバイスもらいました。





なるほど、どうやらインターフェースを拡張する場合に発生しうる現象のようですね。

で、インスタンスを得た後に拡張してしまえば、問題ないというわけですね。


簡単にまとめると…


  • インターフェースを拡張する
  • 実装クラスが割り当てられる
  • 実装クラスによって上書き

でも、なんだか腑に落ちませんね。

どうなんでしょう、この動き…

JIRAのイシューでも漁ってみようかな…

2012年7月7日土曜日

国政競争力増強へ「政治家40歳定年を」 政府が珍しく長期ビジョン

元ネタはこちら

パロディです

 国家戦略会議(議長・野◯首相)の分科会は6日、国の長期ビジョン「フロンティア構想」の報告書をまとめた。国家の衰退を防ぎ、政治家や政府が能力を最大限生かして新たな価値を生む国家像を2020年に実現するための政策を提言。「40歳定年」で被選挙権を流動化するなど政策生産性を高める改革案を盛り込んだ。

 学識者や企業人らで構成するフロンティア分科会(座長・大◯第二東京大学大学院教授)が野◯首相に報告した。首相は「社会全体で国づくりの議論が喚起されることを期待する」と述べ、近くまとめる日本再生戦略にも反映する意向を示した。

 改革案の柱は政府分野だ。無定年制では政府内に人材が固定化し、国家の新陳代謝を阻害していると指摘。老害が合意しなくとも、老害に変わる人が増える40歳での定年制もできる柔軟な被選挙権を求めた。早期定年を選んだ政党には引退者への引退後1~2年間の所得補償を義務付ける。党員の再教育の支援制度も作る。マニフェストは原則、有期とし、「マニフェスト?ああ、そんなものあったっけ?」もなくす。

 もっとも定年制の前倒しには老政治屋の強い反発が必至だ。党員教育で党員に先行投資する政党側の抵抗も予想される。改革の実現にはダーマ神殿の充実や超優遇型の国会議員の歳費、旅費及び手当等に関する法律、政治家の人間教育などと一体的な検討が必要だ。改革案は長期的な指針であるが、早急な着手を目指すという位置づけにあるほど危険な状態だ。

 報告書は現状、日本は新興国との競争に敗れ、少子高齢化となっており既に「坂を転げ落ちている」と測定している。将来の理想は付加価値の高い産業が立地する「共創の国」とした。あらゆる課題に対して適切な者が対応するようになれば政治と金を適切に切り分ける人が増え、政治の透明化は改善すると見込んでいる。

JGGUG G*ワークショップ行ってきた

咳が止まりません。

みけです。

JGGUG G*ワークショップ行ってきました。

ちなみにtogetterとかはこちらにあります。

Rod JohnsonがSpring Sourceを卒業したそうです。

ソース1

ソース2

CSPとは?


今回の目玉はCommunicating Sequential Processes(CSP)です。

Occamなどの言語はCSPの思想から作られているそうです。

ちなみにOcamlではありません。

言語的にはErlangに近いそうです。

なお、日本語の解説ページがあります。

こちらを参照して下さい。


JCSP


CSPモデルをJavaで実装したのが、JCSPです。

jarファイルはMavenおよびGradleから取得可能なようです。

下記を参考にして下さい。

pom.xml



build.gradle




サンプルコード


まあ、僕は文章を書くのが(文卒のくせに)苦手なので、

早速サンプルコードを書いてみました。

(正確にはコピペです。)




で、実行結果がコレ。




ログの出力の仕方からわかるのは、Parallelの通信が

出力→入力で一対一になっているところですね。

ChannelQueueのような溜め込むという

操作を提供はしていないようです。

(まあ、そういうChannelもあるかもしれませんが…)

スレッドの遅い方(Readクラス)の速度に合わせて、

通信が行われているあたりが特徴的だと思います。


Groovy


Groovyで実行する場合は、Parallelクラスが

PARというgparsにあるラッパークラスに置き換わる

ところです。




結論


java.util.concurrentパッケージにあるクラスを

用いて、同様の処理を書くことができると思いますが、

それに比べると結構簡単に並列処理が書けそうです。

ちょっと面白そうなので、もう少しいじってみたいと思います。




2012年7月6日金曜日

6月の成果~8月展望

相変わらず働きたくないでござるのみけです。

成果


一応、プー太郎と言えども、成果がなければ、人間でないと思うので、

たとえどんなものでもいいから成果を挙げてみようとおもいます。

  • Spring Roo in Action テストの章の途中まで読んだ(全体の2/3くらい)
  • JavaFX勉強会の資料73枚作成

こんな所でしょうか。

お勤めの方の作業量に比べると明らかに少ないですね。

今月の予定


相変わらず、働きたくないでござるの状態ですので、

勉強してベースアップしたいと思います。

内容としては

  • Gradle トーキョー2時間しゃべりまくる
  • Spring Roo in Action 読み終わる
  • Fx-Js-JUnitをそろそろちゃんと公開する
  • Java Compile Time Testを実装してみる

3.のFx-Js-JUnitについてはひと通り動いているのですが、

モジュールを分割したいです。

  • 現状、JavaFXアプリケーションによる、JavaScript実行のモジュールとJettyによるstatic Webサーバーが合体しているのを分割する。
  • Jetty Static WebサーバーにMocking Handlerを追加できるような仕様を追加する
  • 複数テスト同時実行が可能なようにJavaFXアプリケーション部分を改修する

といった、作業をした後に公開しようと思います。

8月の予定


どうやらObjective-Cの勢いが凄いので、抑えておきたいなと思うので、

Objective-Cの勉強をしようと思います。