もうすでに、公式のイベントレポートが上がっているのですが、私も参加してきたので書き残しておきたいと思います。
皆さんSlideshareで公開されているようですが、私はGDGのオーガナイザーですから、Google Presentationを使って資料を作っています。その資料は以下のURLから参照して下さい。
https://docs.google.com/presentation/d/1nDTrzQ5etYb_7F2GhumY2pNO3KsRWp9TpTjd00g1Dtc/edit?usp=sharing
今回は依頼を受けた時に、私の前に何人か発表するということがわかっていましたので、初心者向けというわけにもいかないだろうなと思ったので、Golang Cafeで1年間いろんなことをやって来ましたので、自分でも整理するためにGolang Cafeで特に議論することがあった部分について紹介しようと思っていました。
が、12月にリリース予定のGo1.4についての話題が出てきて、すでにrc版になっていましたので、ここは早く1.4の内容について紹介するのがいいだろうと思って、半分はこれまでの内容で、半分を1.4の内容にすることにしました。（実際には思いつかなかった（≒思い出せなかった）ということもあるのですが…）
Go.1.4の内容に関してはBlogに書いていませんが、Golang Cafe #55でやった内容をそのまま資料にしています。やっぱり一番衝撃的だったのは、Androidの正式サポートでしょうか。言語仕様からして合わないだろうと思っていたのですが、しっかり入れてきました。動きも申し分なく動いていますし、良さそうに見えます。
後は、ドキュメントがどれくらいでてくるか。ということと、NDKの仕様が変わらないことを祈っています。
（当日の発表前にオリジナルのデモを作ろうと頑張っていたのですが、ちょっと間に合いませんでした。私のNDKのノウハウの不足と時間不足でした。）
今日のGoConの情報で思い出したけど、何らかの書き込み時にWrite()、Flush()、Close()の順番で呼び出すけど、Close()でエラーのチェックをしないと困る時があるというのは入れておくべきだったと思いました。
実は、実装によっては、パッケージ内部で以前発生したエラーをずっと持っていて、Close()を呼び出したタイミングでエラーを返すという場合があるので、必ずClose()はチェックするようにしましょう。というものです。
そうだったなと思い出すけど、なかなか実践できていないというのが現状かなと思いました。
貴重な経験を頂きましてありがとうございました。また、何かのタイミングでGDG京都のイベントに参加できれば、その時はよろしくお願いします。
2014年11月30日日曜日
2014年11月16日日曜日
Golang Cafe #54を開催しました。
Golang Cafe #54を開催しました。今回は、Go1.4 Release Notesを読み進めました。
今回、読み進めた所は、以下の点です。
個人的に読み進めた部分をおさらいしたような流れになってしまいましたが、再度読み返してみて、わりといろんな所が変更になっていると思います。
For-range loopsの変更はブランク演算子（"_")を書かなくても良くなった点が変更になっています。
次に、ポインタのポインタのメソッドを呼ぶ事が1.3以前では呼び出せていたものが、コンパイルエラーになります。
参考コード（Go Playgroundなので、1.4に置き換わるまでは動作します。）
http://play.golang.org/p/JTHWyVJ3V-（こちらは1.4でもビルドが通る）
http://play.golang.org/p/k-GxLYJOPO（こちらは1.4からコンパイルエラー）
以前のGolang Cafeでも話題になったように、ポインタをあまり使わないのであれば特に影響はありません。
Go1.4からのAndroidのサポートが増える件については、Qiitaの記事を見て動作確認をしてみてください。
いろいろ変更になっていますが、1.3以前までの互換性のガイドラインに変更はありません。（実際、1.0系/1.1系を使っているという方は、あまりいないかもしれませんが…アップデートを忘れている事例を除いて…）
他に増えたのが、
内部パッケージ（Internal Package）でパッケージのディレクトリ内に"internal"というディレクトリを作ると、同一パッケージ外から参照する事ができないパッケージを作ることができるようになります。
それから、Canonical Import Paths（標準的なインポートパス）ということで、package文の末尾にコメントを記入することで、ローカルのディレクトリ構成が正しい（≒go getしたものが正式である）時でないとコンパイルエラーにすることができるようになりました。
リポジトリもいろんなものがあるので、リポジトリを移設することも考えられるかもしれません。そういう時に古いリポジトリを参照しているといつまでも最新バージョンに置き換えられないことになるので、強制的にアップデートさせるのにいいかもしれません。
ただし、go get -uとかして、最新のコードが取得されていないとダメですが…。
Goの公式パッケージのリポジトリがGoogle Codeからgolang.orgに変更されます。
来年の6月1日から正式移行のようです。
go generateコマンド（実際には、コメントに書かれたコマンドを起動するだけのもの）が追加されました。最初は「ライブラリ作者には便利」とだけ認識していましたが、ビルド時に実行したいコマンドを書いておくことで、任意のコマンドを実行する事ができます。（大体はソースコードの自動生成で利用されることと思いますが…）
以前は、windows.goとか、amd64.goというファイル名でwindows専用だったり、64bit専用のソースコードとしてコンパイルされていましたが、これからはそれができなくなります。
あとは、テストコードを書く時に、これまでだと、全てのテストにsetupの処理と、teardownの処理を書かなくてはいけませんでしたが、Go1.4でTestMain()が追加になったので、全てのテストに共通した準備と後処理を書く事が可能になりました。Go本体だと、テスト後にメモリリークが発生しているかどうかのチェックを行うという使い方がされていました。
次回（これからですが）は、Goで大量データを処理するコードを書いて実行する。
ということをテーマに進めて行く予定です。
今回、読み進めた所は、以下の点です。
- Changes to the language
- For-range loops
- Method calls on **T
- Changes to the supported operating systems and architectures
- Android
- Changes to the compatibility guidelines
- Changes to the implementations and tools
- Internal packages
- Canonical import paths
- Import paths for the subrepositories
- The go generate subcommand
- Change to file name handling
- Changes to package source layout
- Performance
- Changes to the standard library
- Major changes to the library
- syscall
- Minor changes to the library
- Testing周りを中心に見ました。
個人的に読み進めた部分をおさらいしたような流れになってしまいましたが、再度読み返してみて、わりといろんな所が変更になっていると思います。
For-range loopsの変更はブランク演算子（"_")を書かなくても良くなった点が変更になっています。
次に、ポインタのポインタのメソッドを呼ぶ事が1.3以前では呼び出せていたものが、コンパイルエラーになります。
参考コード（Go Playgroundなので、1.4に置き換わるまでは動作します。）
http://play.golang.org/p/JTHWyVJ3V-（こちらは1.4でもビルドが通る）
http://play.golang.org/p/k-GxLYJOPO（こちらは1.4からコンパイルエラー）
以前のGolang Cafeでも話題になったように、ポインタをあまり使わないのであれば特に影響はありません。
Go1.4からのAndroidのサポートが増える件については、Qiitaの記事を見て動作確認をしてみてください。
いろいろ変更になっていますが、1.3以前までの互換性のガイドラインに変更はありません。（実際、1.0系/1.1系を使っているという方は、あまりいないかもしれませんが…アップデートを忘れている事例を除いて…）
他に増えたのが、
内部パッケージ（Internal Package）でパッケージのディレクトリ内に"internal"というディレクトリを作ると、同一パッケージ外から参照する事ができないパッケージを作ることができるようになります。
それから、Canonical Import Paths（標準的なインポートパス）ということで、package文の末尾にコメントを記入することで、ローカルのディレクトリ構成が正しい（≒go getしたものが正式である）時でないとコンパイルエラーにすることができるようになりました。
リポジトリもいろんなものがあるので、リポジトリを移設することも考えられるかもしれません。そういう時に古いリポジトリを参照しているといつまでも最新バージョンに置き換えられないことになるので、強制的にアップデートさせるのにいいかもしれません。
ただし、go get -uとかして、最新のコードが取得されていないとダメですが…。
Goの公式パッケージのリポジトリがGoogle Codeからgolang.orgに変更されます。
来年の6月1日から正式移行のようです。
go generateコマンド（実際には、コメントに書かれたコマンドを起動するだけのもの）が追加されました。最初は「ライブラリ作者には便利」とだけ認識していましたが、ビルド時に実行したいコマンドを書いておくことで、任意のコマンドを実行する事ができます。（大体はソースコードの自動生成で利用されることと思いますが…）
以前は、windows.goとか、amd64.goというファイル名でwindows専用だったり、64bit専用のソースコードとしてコンパイルされていましたが、これからはそれができなくなります。
あとは、テストコードを書く時に、これまでだと、全てのテストにsetupの処理と、teardownの処理を書かなくてはいけませんでしたが、Go1.4でTestMain()が追加になったので、全てのテストに共通した準備と後処理を書く事が可能になりました。Go本体だと、テスト後にメモリリークが発生しているかどうかのチェックを行うという使い方がされていました。
次回（これからですが）は、Goで大量データを処理するコードを書いて実行する。
ということをテーマに進めて行く予定です。
2014年11月9日日曜日
Golang Cafe #53を開催しました。
Golang Cafe #53を開催しました。
今回は前回に引き続き、isucon4の予選問題に挑戦しました。Golang Cafeということで、GoのWebアプリケーションを置き換えたりしながら速度アップを図っていきました。
最初の状態のスコアは以下のようになりました。
successがリクエストをして正しい結果が返ってきた回数で、failが間違った結果が返ってきた回数です。実際には最後のScoreの値で競っていくようです。
このisuconのアプリケーションはmartiniが使われていたので、gorillaに書き換えてみました。
Golang Cafeの最中では、エラーが取れなかったのですが、その後すぐに原因が分かったのでエラーを修正した結果です。Scoreが31上がりました。やっぱりreflectionを使うとスピードがどうしても遅くなるようです。
次に、Golang Cafe #50の時に教えてもらった、gojiに書き換えてみました。
更に、スコアが34上がりました。gojiは軽量フレームワークなので処理スピードが早いようです。
ここまでのソースコードはgithubにpushしてありますので興味があればどうぞ。
ソースコードをそれぞれで修正したかったので、branchを分けています。
masterは何もしていない状態なので修正後のものが見たい時は、branchを切り替えて下さい。
Goのフレームワークを変えるだけでもかなり差が出ることがわかりましたが、Sessionの保存にgorilla/sessionを使っているので、データがCookieに全て保存されて通信されてしまっているのでその辺りも修正すればもう少しスピードアップが見込めそうな気がしています。（ローカルでのテストなので通信コストは低いけど…）
次回は、リリース間近のGo1.4のRelease Noteを読み進める予定です。
今回は前回に引き続き、isucon4の予選問題に挑戦しました。Golang Cafeということで、GoのWebアプリケーションを置き換えたりしながら速度アップを図っていきました。
最初の状態のスコアは以下のようになりました。
$ ./benchmarker b 18:12:29 type:info message:!!! DEBUG MODE !!! DEBUGE MODE !!! 18:12:29 type:info message:launch benchmarker 18:12:29 type:warning message:Result not sent to server because API key is not set 18:12:29 type:info message:init environment 18:12:34 type:info message:run benchmark workload: 1 18:13:34 type:info message:finish benchmark workload: 1 18:13:39 type:info message:check banned ips and locked users report 18:14:04 type:report count:banned ips value:4 18:14:04 type:report count:locked users value:2568 18:14:04 type:info message:Result not sent to server because API key is not set 18:14:04 type:score success:6620 fail:0 score:1430
successがリクエストをして正しい結果が返ってきた回数で、failが間違った結果が返ってきた回数です。実際には最後のScoreの値で競っていくようです。
このisuconのアプリケーションはmartiniが使われていたので、gorillaに書き換えてみました。
$ ./benchmarker b 22:40:23 type:info message:!!! DEBUG MODE !!! DEBUGE MODE !!! 22:40:23 type:info message:launch benchmarker 22:40:23 type:warning message:Result not sent to server because API key is not set 22:40:23 type:info message:init environment 22:40:29 type:info message:run benchmark workload: 1 22:41:29 type:info message:finish benchmark workload: 1 22:41:34 type:info message:check banned ips and locked users report 22:41:59 type:report count:banned ips value:4 22:41:59 type:report count:locked users value:2569 22:41:59 type:info message:Result not sent to server because API key is not set 22:41:59 type:score success:6760 fail:0 score:1461
Golang Cafeの最中では、エラーが取れなかったのですが、その後すぐに原因が分かったのでエラーを修正した結果です。Scoreが31上がりました。やっぱりreflectionを使うとスピードがどうしても遅くなるようです。
次に、Golang Cafe #50の時に教えてもらった、gojiに書き換えてみました。
$ ./benchmarker b 23:18:46 type:info message:!!! DEBUG MODE !!! DEBUGE MODE !!! 23:18:46 type:info message:launch benchmarker 23:18:46 type:warning message:Result not sent to server because API key is not set 23:18:46 type:info message:init environment 23:18:53 type:info message:run benchmark workload: 1 23:19:53 type:info message:finish benchmark workload: 1 23:19:58 type:info message:check banned ips and locked users report 23:20:23 type:report count:banned ips value:6 23:20:23 type:report count:locked users value:2567 23:20:23 type:info message:Result not sent to server because API key is not set 23:20:23 type:score success:6920 fail:0 score:1495
更に、スコアが34上がりました。gojiは軽量フレームワークなので処理スピードが早いようです。
ここまでのソースコードはgithubにpushしてありますので興味があればどうぞ。
ソースコードをそれぞれで修正したかったので、branchを分けています。
masterは何もしていない状態なので修正後のものが見たい時は、branchを切り替えて下さい。
Goのフレームワークを変えるだけでもかなり差が出ることがわかりましたが、Sessionの保存にgorilla/sessionを使っているので、データがCookieに全て保存されて通信されてしまっているのでその辺りも修正すればもう少しスピードアップが見込めそうな気がしています。（ローカルでのテストなので通信コストは低いけど…）
次回は、リリース間近のGo1.4のRelease Noteを読み進める予定です。
2014年11月2日日曜日
Golang Cafe #52を開催しました。
Golang Cafe #52を開催しました。
今回は、isuconという「与えられたサーバとそこで動作するWebアプリケーションを高速化してアクセス数を競うイベント」の予選問題でGolangが使われたという情報を聞いたので、実際に挑戦してみようという主旨で開催しました。
本来はAMIというAWSで動作するイメージを使ってAWSにデプロイして競うようなのですが、「課金前提」ということで、GCEに…というのもやめまして、ローカルにデプロイしようと頑張ってみました。
最初、「Dockerを使おう」ということで、
$ docker pull mysql
としたのですが、これが大失敗。関連する全てのコンテナをダウンロードし始めて、1時間待ってもダウンロードが終了しなかったので（Wimax回線の調子が悪かった…？）ローカルのhomebrewを使ったインストールに切り替えました。
$ brew update
$ brew install mysql
これで、mysqlがインストールできたので、早速ログインしてバージョンを確認します。
$ mysql.server start
インストールが完了したので、次にinit.shを動かしました。
すると、"MySQL server has gone away"というメモリ不足で発生するエラーに悩まされました。
drupalのblogに設定の記載例があったのでそれを元に、my.cnfを修正しました。
ただし、table_cacheという設定はないようで、そのままコピペしても改善しませんでした。実際に編集する時はtable_cacheの行は書かないようにしましょう。
これでinit.shを実行した所、今度は、
ということになったので、いろいろ試行錯誤した結果、+0900という記載がダメなようなので
$ sed -e s/\+0900//g dummy_log2.sql
として、+0900の記述を消してから登録しました。homebrewでインストールした時のtimezoneがJSTになっていたので、これをUTCに変えてやればそんなことをしなくても良さそうな気がしてきました。が、本来の主旨と違う気がしたのでそこまで検証していません。
次に、Webサーバの起動ですが、Goの場合は、アプリケーションにhttpサーバの機能があるので、go buildして、起動するだけです。
$ cd webapp/go
$ ./build.sh
$ ./golang-webapp
これで、http://localhost:8080に接続すると「いすこん銀行」が表示されるはずです。
次に、ベンチマーク用コマンドもGoで書かれていますので、go buildすればいいのですが、makefileが用意されているので、それに従ってコンパイルします。
中身を見ると、標準でAWSにリクエストを飛ばすようになっているので、
$ cd benchmarker
$ make debug
として、コンパイルします。すると、localhostに対するリクエストになります。
ですが、そのままだと、http://localhostへのリクエストになり、goのwebappにリクエストが送信されないので、main.goの81行目付近を書き換えます。
これでビルドしなおせばローカルホストに対するリクエストが送信されるようになり、スコアも表示されるようになります。
ということで、今回はGoに関する内容ができなかったので、次回（今日、これから）に持ち越しとなります。
今回は、isuconという「与えられたサーバとそこで動作するWebアプリケーションを高速化してアクセス数を競うイベント」の予選問題でGolangが使われたという情報を聞いたので、実際に挑戦してみようという主旨で開催しました。
本来はAMIというAWSで動作するイメージを使ってAWSにデプロイして競うようなのですが、「課金前提」ということで、GCEに…というのもやめまして、ローカルにデプロイしようと頑張ってみました。
最初、「Dockerを使おう」ということで、
$ docker pull mysql
としたのですが、これが大失敗。関連する全てのコンテナをダウンロードし始めて、1時間待ってもダウンロードが終了しなかったので（Wimax回線の調子が悪かった…？）ローカルのhomebrewを使ったインストールに切り替えました。
$ brew update
$ brew install mysql
これで、mysqlがインストールできたので、早速ログインしてバージョンを確認します。
$ mysql.server start
mysql> select version(); +-----------+ | version() | +-----------+ | 5.6.20 | +-----------+ 1 row in set (0.03 sec)
インストールが完了したので、次にinit.shを動かしました。
すると、"MySQL server has gone away"というメモリ不足で発生するエラーに悩まされました。
drupalのblogに設定の記載例があったのでそれを元に、my.cnfを修正しました。
ただし、table_cacheという設定はないようで、そのままコピペしても改善しませんでした。実際に編集する時はtable_cacheの行は書かないようにしましょう。
[mysqld] # Remove leading # and set to the amount of RAM for the most important data # cache in MySQL. Start at 70% of total RAM for dedicated server, else 10%. # innodb_buffer_pool_size = 128M # Remove leading # to turn on a very important data integrity option: logging # changes to the binary log between backups. # log_bin # These are commonly set, remove the # and set as required. # basedir = ..... # datadir = ..... # port = ..... # server_id = ..... # socket = ..... skip-external-locking key_buffer = 384M max_allowed_packet = 64M sort_buffer_size = 2M read_buffer_size = 2M read_rnd_buffer_size = 64M myisam_sort_buffer_size = 64M thread_cache_size = 8 query_cache_size = 32M max_allowed_packet = 32M # Remove leading # to set options mainly useful for reporting servers. # The server defaults are faster for transactions and fast SELECTs. # Adjust sizes as needed, experiment to find the optimal values. # join_buffer_size = 128M # sort_buffer_size = 2M # read_rnd_buffer_size = 2M sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES
これでinit.shを実行した所、今度は、
MySQL 5.6.20に日付が入らない。"Incorrect datetime value"とか言いやがる。 初期データが突っ込めないな…。 #gdgchugoku #golangcafe
— Takashi Yokoyama (@ttyokoyama) October 26, 2014
ということになったので、いろいろ試行錯誤した結果、+0900という記載がダメなようなので
$ sed -e s/\+0900//g dummy_log2.sql
として、+0900の記述を消してから登録しました。homebrewでインストールした時のtimezoneがJSTになっていたので、これをUTCに変えてやればそんなことをしなくても良さそうな気がしてきました。が、本来の主旨と違う気がしたのでそこまで検証していません。
次に、Webサーバの起動ですが、Goの場合は、アプリケーションにhttpサーバの機能があるので、go buildして、起動するだけです。
$ cd webapp/go
$ ./build.sh
$ ./golang-webapp
これで、http://localhost:8080に接続すると「いすこん銀行」が表示されるはずです。
次に、ベンチマーク用コマンドもGoで書かれていますので、go buildすればいいのですが、makefileが用意されているので、それに従ってコンパイルします。
中身を見ると、標準でAWSにリクエストを飛ばすようになっているので、
$ cd benchmarker
$ make debug
として、コンパイルします。すると、localhostに対するリクエストになります。
ですが、そのままだと、http://localhostへのリクエストになり、goのwebappにリクエストが送信されないので、main.goの81行目付近を書き換えます。
cli.StringFlag{
Name: "host",
Value: "localhost:8080",
Usage: "Bench Endpoint host",
EnvVar: "ISUCON4_BENCH_HOST",
},
これでビルドしなおせばローカルホストに対するリクエストが送信されるようになり、スコアも表示されるようになります。
ということで、今回はGoに関する内容ができなかったので、次回（今日、これから）に持ち越しとなります。
2014年10月26日日曜日
Golang Cafe #51を開催しました。
Golang Cafe #51を開催しました。今回は結城浩さんの書籍「増補改訂版 Java言語で学ぶデザインパターン入門 マルチスレッド編」のThread-Per-MessageパターンをGoで書くとどうなるか？というお題に挑戦しました。
Thread-Per-Messageパターンがどういうものかというと、「これやっといてね」とメインスレッドが要求を出します。この要求ごとにスレッドが生成され、ワーカースレッドがそれぞれを処理して終了するというものです。
今回はワーカスレッドの代わりに、Goroutineを生成して、終了をChannelで待つという、以前と余り変わらないコードになりました。（Javaの場合は、ワーカースレッドが動いているとプロセスが終了しないが、Goの場合はmain()が終了するとプロセスが終了してしまうので、終了待ちをする必要がある）
作成したのは以下のコードです。結局、Javaを力づくで翻訳した以前のコードとあまりかわらない結果になってしまいました。
問題点は、「Goroutineの終了」をどうやって待つか。と言うところが、今回のポイントになりました。実際のところは、Channelを戻り値で受け取り、for文で全てを受信待ちする（今回のパターン）か、selectを使った待ち方をすることになると思いますが、今回のように全てが終わったらその時点で終了。なら、for文で良いのかな？と考えてたりします。
ちゃんとした（正規のサービスで使う）プログラムの場合は、タイムアウトとか、close()させることもあると思いますからselect文を使うパターンの方が多いのかもしれません。
その他に、私も初めて気がついたのですが、syncパッケージにtype Poolというのが存在していました。そこで少し試しにコードを書いてみました。
sync.Poolは、複数のGoroutineからアクセスされても安全に取得できるように作られていて、GCの影響が少なくなるようになっているようです。
（確かにソースコードを見ると、unsafeが使われているようなので、GCの影響が少なくなるのかも？）
実際にGet()してみたところ、なんとなくですが、順番の保証はされていないような感じがします。（runtime.GOMAXPROCS()を呼びださなくても、順番が正しく動いていない気もする…）
ですが、順番が気にならないのであれば、sync.Poolを使うほうが排他制御を考えなくても良い分使いやすいかもしれません。（グローバル変数を同期して…。的なコードを書かなくても良くなる。ただし、それが悪いとは言っていませんのでご注意を。）
次回、（今日）はisuconの過去問題に挑戦してみます。私はAmazonのクラウド環境を使ったことがないので、そこからかな…。
Thread-Per-Messageパターンがどういうものかというと、「これやっといてね」とメインスレッドが要求を出します。この要求ごとにスレッドが生成され、ワーカースレッドがそれぞれを処理して終了するというものです。
今回はワーカスレッドの代わりに、Goroutineを生成して、終了をChannelで待つという、以前と余り変わらないコードになりました。（Javaの場合は、ワーカースレッドが動いているとプロセスが終了しないが、Goの場合はmain()が終了するとプロセスが終了してしまうので、終了待ちをする必要がある）
作成したのは以下のコードです。結局、Javaを力づくで翻訳した以前のコードとあまりかわらない結果になってしまいました。
問題点は、「Goroutineの終了」をどうやって待つか。と言うところが、今回のポイントになりました。実際のところは、Channelを戻り値で受け取り、for文で全てを受信待ちする（今回のパターン）か、selectを使った待ち方をすることになると思いますが、今回のように全てが終わったらその時点で終了。なら、for文で良いのかな？と考えてたりします。
ちゃんとした（正規のサービスで使う）プログラムの場合は、タイムアウトとか、close()させることもあると思いますからselect文を使うパターンの方が多いのかもしれません。
その他に、私も初めて気がついたのですが、syncパッケージにtype Poolというのが存在していました。そこで少し試しにコードを書いてみました。
sync.Poolは、複数のGoroutineからアクセスされても安全に取得できるように作られていて、GCの影響が少なくなるようになっているようです。
（確かにソースコードを見ると、unsafeが使われているようなので、GCの影響が少なくなるのかも？）
実際にGet()してみたところ、なんとなくですが、順番の保証はされていないような感じがします。（runtime.GOMAXPROCS()を呼びださなくても、順番が正しく動いていない気もする…）
ですが、順番が気にならないのであれば、sync.Poolを使うほうが排他制御を考えなくても良い分使いやすいかもしれません。（グローバル変数を同期して…。的なコードを書かなくても良くなる。ただし、それが悪いとは言っていませんのでご注意を。）
次回、（今日）はisuconの過去問題に挑戦してみます。私はAmazonのクラウド環境を使ったことがないので、そこからかな…。
2014年10月22日水曜日
「Javaプログラマーなら習得しておきたい Java SE 8 実践プログラミング」を読みました。
Blogを書くのが遅くなってしまいましたが、「Javaプログラマーなら習得しておきたい Java SE 8 実践プログラミング」（http://www.amazon.co.jp/dp/4844336673）を読みました。
目次は以下の構成です。
目次は以下の構成です。
- 第1章 ラムダ式とは
- 第2章 ストリームAPIの使い方
- 第3章 ラムダ式を使ったプログラミング
- 第4章 JavaFXによるGUIプログラミング
- 第5章 日付と時刻の新たなAPI
- 第6章 並行処理の機能強化
- 第7章 Nashorn JavaScriptエンジンの活用
- 第8章 その他のJava 8機能を理解する
- 第9章 Java 7の機能を復習する
私はJava 5が出たあたりで、Javaをほとんど書かなくなってから、AndroidのプログラミングでJava 6のコードを書いているという状態でした。従って、Java 7の内容とか、Java 8の事は殆どわかりません。（以前、Java 8のハンズオンイベントに参加したので、Stream APIとラムダ式は教えて頂いたことがある。）
実は、今回縁あってImpress Japanさんから献本を頂きまして、本書を読むことができました。ありがとうございました。書籍を読む時間が取りづらいのと、貸してほしいとお願いされたこともあって、私は5章まで読んで、以降は流し読みになっていますが、私の印象を書いておきたいと思います。
読む前の印象としては、柴田さんの翻訳本の文章は「日本人には読みづらい」という印象がありました。Goフレーズブックとかが、わりと頭が痛くなる文章だった気がします。
ですが、本書に関しては、わかりやすい文章になっていると思います。
しかし、コード例や、説明がJava 6、Java 7の書き方をしっかり理解していないと、内容を理解するのが難しいと感じました。従って、Java 7の内容がわかっていないのであれば、一度9章を読んでからの方が良いのかもしれません。
（初心者の方は、恐らく途中で挫折してしまうと思いますので、最初の書籍に選択するのはおすすめしません）
ラムダ式の所は、型の記述を省略できるようになっているのですが、引数の型が見てわかるようであれば良いのですが、書籍の例のラムダ式のコードを見てもすぐに型が分からないこともあったので、ある程度、Javaのクラスの事が分かっている方がいいかもしれません。（もしくは、ドキュメントを見ながら読み進める必要があるかもしれません）
本書には（私はまだ取り組んでいませんが）練習問題が用意されていて、練習問題に取り組むことで、理解を深めることができるようになっています。ですから、よくわからなかった所は、練習問題でもう一度、内容を整理して理解するということが可能になっています。
書籍は260ページ程度で、比較的薄い本ですから読み終わるまでに時間はかからないと思います。
今のところ、Java 8の内容全体を見渡せる書籍は本書のみだと思いますので、全体を見渡したい方はお手に取って見てください。
2014年10月13日月曜日
Golang Cafe #50を開催しました。
Golang Cafe #50を開催しました。今回は、開催地を東京のGoogleオフィスに設定して開催をしました。
今回はGolang Cafe #50での内容ではなく、準備段階などの話に重点をおこうと思います。
Golang Cafe #50を開催するにあたって、Golang Cafe #30の開催時から、+Yoshifumi YAMAGUCHIさんと連絡を取って、「Golang Cafeの開催が50回になったら、オフィスを貸して欲しい＋α」とお願いをしました。
すると、簡単にOKが出たので、+Ryuji Iwataさんと、+Takanobu Haginoさんと私の3人でGoogleのオフィスでGolang Cafeをしようという計画が開始されました。
この段階で、他にもGolang Cafeに参加して頂いた方はいらっしゃいましたが、この時点で30回も続くと思っていなかったので、少なくとも、25回以上は参加しているであろう、2人に絞りました。（この時点で他に10回を超える方はいなかった）
ということで、そこから開催を重ねていったわけですが、このGolang Cafe #50のテーマとして、「私のネタに付き合って頂いた方へのお返し」というのを（勝手に、誰にも言わず）掲げて、可能な限り要望に答えられるように進めていったつもりです。2人には今後のGDG中国のGoのコンテンツを支えていただけるようなので（笑）非常に感謝しております。
次に、東京での開催ということで、正直最初の計画段階ではネタで募集して3人で適当にオフィスでやろうか。と話をしていたと思うのですが、だんだんと希望は膨らんでしまって、「東京のGopherと交流を図ろう」ということになりました。
しかし、「規模が大きいものはGoConがある」ので、規模は大きくしない。というもので。
ただ、普段通り募集をかけると、恐らく一瞬で満員御礼＋多数のキャンセルによる悲劇が待っているだろうというのが、簡単に想像できたので、Golang Cafe #50に関しては、「非公開＋技術者のつながり」で募集をかけようということになりました。
また、西日本のGopherは、今回は私がお誘いするつもりがありませんでした。（理由は交通費の問題と、西日本在住であればすぐに会えるので東京に来ていただく必要がなかった。敢えてお呼びしませんでしたが、悪意はありません。）が、+Yasutaka Kawamotoさんだけは、特別に、+Ryuji Iwataさんの強い要望があったので、（Iwataさんは、なぜか自分から呼ばなかった）私からお誘いしました。
昔、少しだけやっていた、Golang Office HourというHangoutのイベントのことなど、覚えて頂いたようで、ちょっとうれしかったです。+Takuya UedaさんもGolang Office Hourのことを覚えていて、「戦友」だと思いました。
東京のGo言語を使っている方と直接連絡が取れる方というのが非常に少なかったので、こればかりは、+Yoshifumi YAMAGUCHIさんに頼ろうということで、告知等をお願いしました。
そこで、よく考えると、東京にはGDG中国のスタッフ+Shingo Ishimuraさんがいるということに気がついたので、彼を巻き込み、総勢18名の参加者になりました。
後は、直前に風邪をひいたりして、活動がしっかりできませんでしたが、なんとか本番にこぎつけた。という流れです。
本当に、東京でのサポートをして頂いた +Yoshifumi YAMAGUCHIさん、+Shingo Ishimuraさんには助けられました。ありがとうございました。
そして、無茶ぶりにもかかわらず参加していただいた、参加者のみなさんもありがとうございました。いい勉強になりました。楽しかった！
本番のことにも少し触れると、「Golang Cafeの主催者はTakashi Yokoyamaさんです！」と言いながら、自分が主催者であるかのように、突撃してGolang Cafe #50の時に、「Golang Cafeとは」という説明をし始めたり、Rob Pike氏に人の名前を入れてメールを送り、「何かメッセージをくれ」と言って、メッセージを頂いたりと暴れまくってくれた+Ryuji Iwataさんは非常に楽しそうでした。（普段は、私がGoDEとして持ち上げているのでプラスマイナスゼロですかね）セッションを2つもやった挙句に、本番のルール説明は私に投げるという、新しい勉強会のスタイルを教えてくれました（笑）
最終的に2人には満足して頂いたかどうかはわかりませんが、非常に楽しい1日でした。
100%の要望に答えることは不可能だと「再」認識したので、お2人の反応に期待することにします。
Golang Cafeという「毎週みっちり」というのを1年間続けてみた結果ですが、3人はGolangのことは大体わかるようになったのかな？と感じています。ですが、40回台には、テーマ設定が難しい時もありました。（大体見ても、新発見することが少なくなってしまう）それは、成長したからなのでしょうが、連続の開催回数で理想的なのは30回ぐらいまでなのかな？と個人的に思っています。
それから、最初は「個人的にコードを書く時間」という設定で開催をした（zusaarの募集はネタ）のですが、結局それが許される環境には、現時点ではなかったようで、こんなに大きなものになってしまったというのは驚きがあったのと、誤算だったのとでいろいろ発見がありました。それで、Go言語というものが広まるようになるのなら、「まあいいや」ということかなとも思います。
「Golang Cafeの今後」についても少しずつ考えていますので、また次回の#51で話をしようかと思っています。
次回のGolang Cafe #51ですが、台風19号の影響により危険だと判断しましたので、来週（10/19）に順延することにしました。zusaarは満員御礼なのですが、キャンセルをしっかり行っておいて下さい。
今回はGolang Cafe #50での内容ではなく、準備段階などの話に重点をおこうと思います。
Golang Cafe #50を開催するにあたって、Golang Cafe #30の開催時から、+Yoshifumi YAMAGUCHIさんと連絡を取って、「Golang Cafeの開催が50回になったら、オフィスを貸して欲しい＋α」とお願いをしました。
すると、簡単にOKが出たので、+Ryuji Iwataさんと、+Takanobu Haginoさんと私の3人でGoogleのオフィスでGolang Cafeをしようという計画が開始されました。
この段階で、他にもGolang Cafeに参加して頂いた方はいらっしゃいましたが、この時点で30回も続くと思っていなかったので、少なくとも、25回以上は参加しているであろう、2人に絞りました。（この時点で他に10回を超える方はいなかった）
ということで、そこから開催を重ねていったわけですが、このGolang Cafe #50のテーマとして、「私のネタに付き合って頂いた方へのお返し」というのを（勝手に、誰にも言わず）掲げて、可能な限り要望に答えられるように進めていったつもりです。2人には今後のGDG中国のGoのコンテンツを支えていただけるようなので（笑）非常に感謝しております。
次に、東京での開催ということで、正直最初の計画段階ではネタで募集して3人で適当にオフィスでやろうか。と話をしていたと思うのですが、だんだんと希望は膨らんでしまって、「東京のGopherと交流を図ろう」ということになりました。
しかし、「規模が大きいものはGoConがある」ので、規模は大きくしない。というもので。
ただ、普段通り募集をかけると、恐らく一瞬で満員御礼＋多数のキャンセルによる悲劇が待っているだろうというのが、簡単に想像できたので、Golang Cafe #50に関しては、「非公開＋技術者のつながり」で募集をかけようということになりました。
また、西日本のGopherは、今回は私がお誘いするつもりがありませんでした。（理由は交通費の問題と、西日本在住であればすぐに会えるので東京に来ていただく必要がなかった。敢えてお呼びしませんでしたが、悪意はありません。）が、+Yasutaka Kawamotoさんだけは、特別に、+Ryuji Iwataさんの強い要望があったので、（Iwataさんは、なぜか自分から呼ばなかった）私からお誘いしました。
昔、少しだけやっていた、Golang Office HourというHangoutのイベントのことなど、覚えて頂いたようで、ちょっとうれしかったです。+Takuya UedaさんもGolang Office Hourのことを覚えていて、「戦友」だと思いました。
東京のGo言語を使っている方と直接連絡が取れる方というのが非常に少なかったので、こればかりは、+Yoshifumi YAMAGUCHIさんに頼ろうということで、告知等をお願いしました。
そこで、よく考えると、東京にはGDG中国のスタッフ+Shingo Ishimuraさんがいるということに気がついたので、彼を巻き込み、総勢18名の参加者になりました。
後は、直前に風邪をひいたりして、活動がしっかりできませんでしたが、なんとか本番にこぎつけた。という流れです。
本当に、東京でのサポートをして頂いた +Yoshifumi YAMAGUCHIさん、+Shingo Ishimuraさんには助けられました。ありがとうございました。
そして、無茶ぶりにもかかわらず参加していただいた、参加者のみなさんもありがとうございました。いい勉強になりました。楽しかった！
本番のことにも少し触れると、「Golang Cafeの主催者はTakashi Yokoyamaさんです！」と言いながら、自分が主催者であるかのように、突撃してGolang Cafe #50の時に、「Golang Cafeとは」という説明をし始めたり、Rob Pike氏に人の名前を入れてメールを送り、「何かメッセージをくれ」と言って、メッセージを頂いたりと暴れまくってくれた+Ryuji Iwataさんは非常に楽しそうでした。（普段は、私がGoDEとして持ち上げているのでプラスマイナスゼロですかね）セッションを2つもやった挙句に、本番のルール説明は私に投げるという、新しい勉強会のスタイルを教えてくれました（笑）
最終的に2人には満足して頂いたかどうかはわかりませんが、非常に楽しい1日でした。
100%の要望に答えることは不可能だと「再」認識したので、お2人の反応に期待することにします。
Golang Cafeという「毎週みっちり」というのを1年間続けてみた結果ですが、3人はGolangのことは大体わかるようになったのかな？と感じています。ですが、40回台には、テーマ設定が難しい時もありました。（大体見ても、新発見することが少なくなってしまう）それは、成長したからなのでしょうが、連続の開催回数で理想的なのは30回ぐらいまでなのかな？と個人的に思っています。
それから、最初は「個人的にコードを書く時間」という設定で開催をした（zusaarの募集はネタ）のですが、結局それが許される環境には、現時点ではなかったようで、こんなに大きなものになってしまったというのは驚きがあったのと、誤算だったのとでいろいろ発見がありました。それで、Go言語というものが広まるようになるのなら、「まあいいや」ということかなとも思います。
「Golang Cafeの今後」についても少しずつ考えていますので、また次回の#51で話をしようかと思っています。
次回のGolang Cafe #51ですが、台風19号の影響により危険だと判断しましたので、来週（10/19）に順延することにしました。zusaarは満員御礼なのですが、キャンセルをしっかり行っておいて下さい。
登録:
投稿 (Atom)