ナカザンドットネット

それって私の感想ですよね

Code SchoolのAngularJS入門がとても良かった

Ionicを勉強する機会があったので、基礎学習として元になっているAngularJSについても勉強してみました。

色々探してみて、最終的に公式サイトのメニューからたどり着いたのがCode Schoolのチュートリアルです。

www.codeschool.com

Code Schoolを利用したのは今回が初めてでしたが、動画レクチャーとハンズオンを交互に行うスタイルはインプットとアウトプットのイテレーションを素早く回せてよいですね。

また、授業の内容も上手に組み立てられていたように思います。一歩ずつ丁寧に説明してくれるので、頭の中にブラックボックスを作らずに理解を積み重ねていくことができました。特にありがたかった点は、一度たりとも$scopeが登場しなかったところです。

$scopeは使わなければならないのか?

続きを読む

珈琲倶楽部のホームページ戦略どうなってんだと思ったお話

普段からデスクワークが多い方々の中には、コーヒーを一日中飲んでいるような方を多く見かけます。私は睡眠に影響しやすいので1日数杯といったところですが、まあコーヒーは好きな方です。

さて、新潟市で生活していると「珈琲倶楽部」という喫茶店をよく見かけます。 会社の近くには笹口店があってときどき足を運んでいますし、ギークハウス新潟の近くには石山店がありました。

フランチャイズ展開で店舗数を伸ばしているらしいというのは風の噂で聞いていたので、職場の場所が変わったり家を引っ越したりした時には、近所にも店舗がないか探してみたくなりますよね。そんなときに役立つのが「店舗一覧」のようなページを持ったホームページでしょう。きっとホームページを探せば、近場の店舗も見つかるはずです。

しかし、それが難しい状況になっているのです。

okwave.jp

実は、前述の笹口店や石山店のリンクを見てみると、Webへの情報公開の方法がバラバラなんですね。

どうやらこの珈琲倶楽部、本部のようなところでホームページを取りまとめるようなことはせず、広報周りを各店舗に丸投げしているようなのです。独自性を尊んでいるのでしょうけれども、探す方からすると検索性が悪すぎです。単純に比べられるものでもないですが、おとぎや珈琲店あたりは見やすいのになあと感じてしまいます。

いい機会なので、現状を調べてみました。新潟でWeb製作している方は提案のいいネタになると思うので、なんとかしてくれると珈琲好きとして嬉しいです。

続きを読む

Code for Niigata 真夏のハッカソンに参加してきたよ #c4ngt

Code for Niigataのイベントがあったので参加してきました。

8/1-8/2に「真夏のハッカソン!」( #C4NGT )を開催します!! | Code for Niigata

前夜に突発的に参加を決めたため 家庭の都合により、2日間構成の1日目のみの参加となりました。しかも、

出入り自由ですので、ご都合の良い時間のみの参加でも全く問題ありません

と書いてあったので、完全に鵜呑みにして、13時から18時までという中途半端な時間だけいた感じでした。(自分が一番半端かと思ったら、夕方に1時間だけいた @ パイセンのほうが半端だったのでちょっと安心した)

色々と雑多に感想を書いていこうと思います。

会場について

f:id:Nkzn:20150802000042p:plain

http://tsubamesanjo-style.jp/

今回のイベントは、昨年の秋にオープンした、燕三条トライクというシェアスペース(コワーキングスペース?)で行なわれました。知りあいづてに存在は知っていたのですが、行くのは今回が初めてです。

感想としては、めっちゃ雰囲気のいい古民家でした。*1

*1:元商店らしいので、古「民家」ではないのだけれども

続きを読む

Icepickにノスタルジックな変更が入りました

ポエムです。

皆さん、Icepickをご存知でしょうか。ActivityやFragmentに書いたプロパティをSavedInstanceStateで保存/復元する責務だけを持つ、アンチAndroidAnnotations界隈では人気のあるAndroid向けライブラリですね。

このIcepickに、下記のコミットが行われました。

github.com

さよなら、@Icicle。

分かる人には分かる、寂しい変更です。この記事ではAndroid界の老害たちに向けて、昔を懐かしむ話をしたいと思います。

続きを読む

読み書きソロバンから、読み書きコンピュータへ

BBCさんの取り組みがあまりにもアツくて、ちょっと気持ちが盛り上がってしまったので、今回は珍しく、かなりポエミーな内容を書きたいと思います。

読み書きソロバンの時代から、読み書きコンピュータの時代へ。

英国BBC、ミニ基板コンピュータ『Micro Bit』100万台を無償配布。中1生全員にコーディング教育 - Engadget Japanese

全ての人がコンピュータを自在に操れる数十年後の世界に向けての取り組みが、どんどん増えてきています。

Scratch - Imagine, Program, Share

Kano - Make a Computer

こういった取り組みへのコメントを見ていると、「普通の人がコンピュータを覚える必要なんて無い」と言った意見を見かけます。これは、昔の下流階級の人々が「普通の人が文字を覚える必要なんて無い」と言っていたのと同じことだと、私は思ってます。

手紙を書くにも、文字の読み書きができる人を探してきて、お願いするなりお金を払わなければいけなかった時代。現代の、プログラミングができる人、できない人の関係と似ていますね。

プログラマーは職を失うのか

(私はプログラマーなので、ここから先の話はプログラミングに寄ります。コンピュータの広大な分野の中から一部分だけをピックアップすることをお許し下さい。)

こんな話をすると、「普通の人がプログラミングできるようになったら、プログラマーが職を失うじゃないか」という話が出てきますが、そうです、一般の人々が最低限作れるような、メモ書きレベルのプロダクトしか生み出せないプログラマーは職を失います。代筆を生業としていた人々も、同じく職を失っていったのでしょう (要出典) から、自然な流れです。

では、文章を書くプロの仕事はなくなったのでしょうか。そうではないのです。 作家、記者、詩人、作詞者、脚本家。現代でも、文章を書くことを生業にする人たちは、確かに残っているのです。

プロであるということ

プログラミングによってものを作る職業は、きっと無くなりません。

ですが、おそらく、他人に頼まれたものをそのまま作る、という仕事は、少しずつ少しずつ、なくなっていくのでしょう。だって、ちょっとしたものならば、世間一般の(私達の子の世代や孫の世代の)人々は、自分で作れてしまうのですから。現在でも、Excelを上手に扱える人々は家計簿ソフトなどを買うことなく、家計簿を電子的に作成・集計できている*1ことを考えると、その片鱗は少しずつ現れているとも言えます。(Excelの式を書く作業は紛れも無くプログラミングです)

基板となる技術が一般に普及した後にも、生業としてお金を稼ぐことができるのは、その技術を「上手く」使って、他人にとって価値のあるものを生み出せる人です。私は、そう思っています。

識字率の上昇に伴い職を失っていった人がきっといたように、識コンピュータ率の上昇によって、職を失う人々が出てきます。でもきっと、その後にプロの仕事として残ったものが、プログラミングの、エンジニアリングの、本質的な価値なのではないでしょうか。

10年後なのか50年後なのか分かりませんが、そんな時代がいつかやってきます。

その時に向けて、エンジニアとしての自分の価値を、見直し続けていけたらいいなと、そんな風に思うのです。

どっとはらい。

反省会

タイトルはソロバンとコンピュータの対比みたいになってたのに、実際には識字率にしか注目していなかったことに書き終わってから気がついた。まあ寺子屋教育が日本にもたらしたもの的なニュアンスでなんとか。

*1:もちろん、クラウドにアップロードしたりといった付加価値の点では、市販のものに分があります

勉強会の発表下書きにQiitaを使うスタイル

第40回勉強会(2015/02/21) - 長岡 IT開発者 勉強会(NDS)

第40回 長岡IT開発者勉強会に参加した皆様、お疲れ様でした。初心者Dayという名前ながら知見にあふれた良いイベントだったと思います。

さて、私は「Android再入門 〜Eclipseのことは忘れろ〜」と銘打ち、Android初心者向けにネット情報の取捨選択を行うにあたって考慮してほしいことを発表しました。

また、今回は講演内容をQiitaに下書きして、勉強会と同時に公開するという初めての試みも行いました。

Android再入門 〜Eclipseのことは忘れろ〜 #nds40 - Qiita

1週間で400ストックという凄いペースで伸びていて、承認欲求が大幅に満たされつつもビクビクしている日々です。

この記事では、今回試みたことを簡単に紹介したいと思います。

公開までの流れ

  1. 初期構想
    • Android Studio便利だよ!
      →でも情報が氾濫してるね
      →初心者向けに1度整理しよう
    • Eclipseへのdisはうっかり紛れ込んだだけで本筋ではないのです
  2. 全体構想
    • 概要(見出しレベル)をMarkdownでゴリゴリ書く
  3. 原稿作成
    • ↑に肉付けしつつ、Qiita向けの技術記事として当たり障りなさそうな体裁の文章をKobitoで書く
  4. スライド作成
    • 「原稿の内容を喋っている時に背景として表示されていてくれると嬉しいスライド」という観点でスライドを作成する
  5. 勉強会中にQiitaに原稿を公開
  6. 勉強会でセッションを発表
  7. 発表しましたレポとともにスライドを公開(本記事)

この順でやってみて、全体的には良かったと思っていますが、もちろんデメリットもありました。それぞれ紹介します。

悪かったこと

二度手間

単純に数だけ見れば資料を2本仕上げたことになるので、作業量としてはただスライドを作るよりも少し重くなりました。とはいえ、倍という程ではなかったと思います。

分量が測りづらかった

スライドだけを作っている分には、枚数を見ながら「1枚○分ずつは喋れるな」のような算段ができたのですが、Qiita向けの原稿を書く体で作っていると、実際に喋るときの分量が想像しづらく、作りすぎてしまいました。(実際に、15分枠だったセッションを30分枠に変更してもらうことになりました)

良かったこと

テーマの深堀りができる

技術記事として成り立つものにしようというスタート地点で原稿を書き始めると、スライドにキーワードを書き連ねていくよりも具体的に発表テーマについて検討することができます。また、スライドに比べて1つの見出しに書ける一連の情報を大きくできるため、情報に深みを持たせることができました。

細かい話題まで入った資料を公開できる

勉強会の後にSlideShareSpeaker Deckに資料を公開して、当日会場にいた人やいなかった人が見れるようにすることは一般的になってきています。公開を前提にしてスライドを作成する講演者も多いのではないでしょうか。

資料の公開自体はありがたいのですが、少し困ったことが起こります。喋る内容を概ね再現した資料を作成しなければならなくなるのです。講演者が読みながら喋るための「原稿としてのスライド」は、聴き手が読むことに集中してしまい、肝心の口頭の話を聞けなくなってしまう危険性を帯びています。

私の感覚では、講演スライドには2種類あります。

  • 資料としてのスライド
    • 後日読む分には、情報量も多く発表内容が伝わってくるいい資料になる
    • 会場にいると文字を追うのと話を聞くのが同時進行になって大変
    • MSの講演でよく見かける
  • 背景としてのスライド
    • その時喋っている内容を象徴するキーワードだけが載っているスライド
    • 聞き手が読む文字が最小限になり、話を聞いてもらいやすくなる
    • ジョブズ的なアレ

この2つのどちらを採用するかは、現場での読みやすさと公開時の資料としての価値を天秤にかけることになり、非常に悩ましいところでした。

ですが、今回のように「資料としての内容はQiitaに投稿する」と最初から決めてしまっていれば、迷う必要はありません。スライドだけなら冗長すぎて書けなかったような余談も含め、話題をガンガン深めていくことができます。

深めすぎた結果、喋れない分量になったらどうするって? そうなったらスライドを作るときに推敲して、省ける項目を原稿から省いてしまえばよいのです。

スライドがすっきりする

前述のとおり、「資料としてのスライド」を作る必要性が薄くなったので、「背景としてのスライド」に寄せられるようになりました。

文章量は極力抑えてみたところ、これまでのイベントでの講演に比べて、聞き手の目が僕に向いている時間がとても長かったように思います。ただ、当の僕が練習不足で、別途カンペを見ながらでないと喋れない状態だったので、聞き手のほうを見ながら喋ったりができなかったのが悔やまれます。

スライド作りにはそこまで時間がかからない

原稿にある内容を表現すればいいという性格上、新しくネタを考える時間は取られませんし、文章量も原稿に比べればかなり少ないです。そのため、原稿+スライドでかかる時間は、中身を悩みながらスライドだけを作る場合の1.5倍程度の時間でできるのではと思います。

まとめ

Kobitoで重厚な原稿を書いて、軽いスライドで発表して、Qiitaに公開する。このサイクルで、公開スライドが抱えていたジレンマが少し解消されそうです。

スライドだけを作ると話題が中途半端になってしまうような感覚を持っている方は、是非このスタイルを試してもらえればと思います。

宣伝

ウォーターセル株式会社では、農業分野でのITツールの開発・改善に一緒に取り組んでくれるAndroidエンジニアを募集しています。

農業IT分野がどんなものなのか話を聞いてみたいレベルでも結構ですので、興味のある方は@まで空リプを飛ばすなり何なりして、コンタクトを取っていただければと幸いです。

スティーブ・ジョブズ 驚異のプレゼン

スティーブ・ジョブズ 驚異のプレゼン

java.text.DecimalFormatの四捨五入が失敗するバグ

この記事はQiitaからの転載です。


Javaで「小数第N位以下を四捨五入したい」「ある桁はゼロ埋めしたいけど、あとは桁があるときだけ表示したい」などなど、数値を文字列で表現したい場合には、 java.text.DecimalFormat を使うのが便利ですね。

今回はこのDecimalFormatで四捨五入が失敗するバグを見つけたので紹介します。

環境

$ java -version
java version "1.8.0_25"
Java(TM) SE Runtime Environment (build 1.8.0_25-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)
  • OS: OS X Yosemite 10.10.1
  • JDK: Oracle JDK 1.8 u25

現象

// Java8DecimalFormat.java
import java.text.DecimalFormat;
import java.math.RoundingMode;

class Java8DecimalFormat {
    public static void main(String[] args) {
        final DecimalFormat df = new DecimalFormat("0.##");
        df.setRoundingMode(RoundingMode.HALF_UP);

        String hoge = df.format(10.145);
        System.out.println(hoge); // 10.14

        String fuga = df.format(13.555);
        System.out.println(fuga); // 13.55
    }
}

四捨五入を期待して RoundingMode.HALF_UP を指定しているにもかかわらず、挙動としては切り捨てになってしまっています。

実際バグらしい

[#JDK-8062013] DecimalFormat / rounding / HALF_UP - Java Bug System

OpenJDKのバグトラッカーに同様の報告が上がっていました。ver1.8.0u20にも同様のバグがあったので、それなりに前に混入したバグなのかもしれませんね。

テストコードの処理系をJDK1.7からJDK1.8に切り替えた途端にいくつかのテストが通らなくなり、原因を色々探した結果がこれでした。さて、どうしたものか。。。

追記: 1/15 12:40

問題切り分けのために、他のパターンでも実験してみました。

Java7環境

// jdk1.7.0_21
String hoge = df.format(10.145);
System.out.println(hoge); // 10.15

String fuga = df.format(13.555);
System.out.println(fuga); // 13.56

JDK1.7.0u21環境での実行結果です。期待した結果が出ています。

Java8環境別バージョン

10.145 は 10.1449(以下略)という内部数値だったはず

コメント欄で上記のご意見をいただいたので、もう一桁加えてみました。

// jdk1.8.0_25
String hoge = df.format(10.1451);
System.out.println(hoge); // 10.15

String fuga = df.format(13.5551);
System.out.println(fuga); // 13.56

期待した結果が出ました。

おまけ:Java8環境でバイナリ的に綺麗になるように

丸め誤差の問題であれば、バイナリ的に綺麗になる $2^{-3}=0.125$ を処理する分には問題が起きないはずですね。

// jdk1.8.0_25
String piyo = df.format(0.125);
System.out.println(piyo); // 0.13

期待した結果が出ました。

まとめ

というわけで、古き良き浮動小数点の丸め誤差問題でした。

「java.text.DecimalFormatの四捨五入が切り捨てになるバグ」というタイトルで公開しましたが、実際には切り捨てではなく「丸め誤差で5が4扱いになってしまう」という現象でしたので、少しタイトルを変えました。