まだプログラマーですが何か?

プログラマーネタとアスリートネタ中心。たまに作成したウェブサービス関連の話も http://twitter.com/dotnsf

2016年04月

CentOS に Go 言語環境を導入します。以下は CentOS 6.x の 64bit 版を前提とします。


Go 言語のインストールは yum ではなく、直接バイナリをダウンロードして展開するだけです(この例では /usr/local/go/ 以下に Go 1.4 をインストールしています):
# cd /usr/local/src
# wget https://storage.googleapis.com/golang/go1.4.linux-amd64.tar.gz
# tar -C /usr/local -xzf go1.4.linux-amd64.tar.gz

環境変数 GOPATH を設定し、また PATH を通してコマンドラインから直接利用できるように設定します:
# vi ~/.bashrc

(以下の2行を追加して保存)
export GOPATH=/usr/local/go/
export PATH=$PATH:/usr/local/go/bin

ここまでの準備ができたらログインし直して、go コマンドを実行して動作確認します(青字のような出力になれば成功です):
# go version
go version go1.4 linux/amd64

試しに Hello World 的なアプリを書いて実行してみましょう。以下の内容のテキストファイルを hello.go という名前で作成して保存します:
package main

import "fmt"

func main(){
  fmt.Printf( "Hello, World\n" )
}

そして実行して動作を確認します:
# go run hello.go
Hello World

動きました!


ついでに HTTP サーバーを作ってみます。今度は以下の内容を http1.go という名前で作成します。8080 番ポートのルートパス(/)で待ち受けるような内容にしています。また GET の param パラメータの値を取り出して出力するようにしています:
package main

import(
  "fmt"
  "html"
  "net/http"
)

func HelloServer( w http.ResponseWriter, req *http.Request ){
  title := html.EscapeString( req.URL.Path[1:] )
  param := req.FormValue( "param" )
  output := `
<html>
<head>
<title>` + title + `</title>
</head>
<body>
<h1>HTTP のテスト</h1>
<h2>get</h2>
param=` + html.EscapeString(param) + `</br>
</body>
</html>
`
  fmt.Fprintf( w, "%s", output )
}

func main(){
  http.HandleFunc( "/", HelloServer )
  http.ListenAndServe( ":8080", nil )
}

そして実行します:
# go run http1.go


ウェブブラウザで、この Go を実行中のマシンの 8080 番ポートのルートパス(/)にアクセスします。またこの時に param パラメータを付けて実行すると、そのパラメータ内容が表示されることを確認します:
2016042601


CentOS 上で Go 言語が実行でき、HTTP サーバーを作れることも確認できました。

読売新聞社様主催のジャイアンツハッカソン、4月27日に決勝に残ったチームによる最終審査が行われました:
http://www.giants.jp/G/gnews/news_3910572.html

2016042801



ITを通じてファンと球団との距離を縮め、試合観戦などをより楽しむことができるようなアイデアを広く募集し、アイデアを詰め、短期間で開発し、その出来栄えや実用性、ビジネス性を競い合う、というコンテストでした。数多くの独創的なアイデアや製品が生まれましたが、その中でもコミュニケーションツールを活用して選手をより身近に感じてもらうサービスを発表した "TEAM PAAK" チームが最優秀賞に輝きました。TEAM PAAK の皆様、おめでとうございます。また同ハッカソンに参加された多くの皆様、データ提供や審査などに参加頂いた協賛企業の皆様、大変お疲れ様でした。

同ハッカソンではアイデアを実現するためのお手伝いとして、データスタジアム様や読売巨人軍様から各種データ(試合/打席/投球/選手のデータや画像、球団グッズの売上記録など)を提供いただき、ハッカソン内で利用させていただきました。日本アイ・ビー・エムはサムライインキュベート様と共同で同データをアプリケーションから利用できるよう、各種データを API 化し、クラウドサービス(SoftLayer & Bluemix)と合わせて参加チームに提供しました。この「各種データの API 化」という部分のお手伝いをしたこともあり、この部分を少し掘り下げて紹介させていただきます。

簡単にいうと、データを提供する側の都合と、データを活用したい側の都合をあわせるための場を提供させていただきました。試合の記録データは本来有料で企業に提供されているもので、このハッカソンでの利用に限り、参加チームへは無料で提供いただきました。画像データや売上記録については、これら自体は売りものではありませんが、権利関係などで本来は公開されていないものを含めて提供いただきました。データを使う側からすると、これらのデータを丸ごと(例えばファイルごと)入手できると嬉しいかもしれませんが、上記のような事情からそういった形での提供は望まれていないものでした。 ではどのようにこれらのデータを提供するか、というのが我々の課題でした。

その答が API 化して、参加チーム毎の利用状況を管理しながら提供するという方法でした。この点についてもう少し詳しく説明します。

まずは「API 化」です。API とは Application Platform Interface の略で、ここでは「ウェブを通じて実行できる関数」という意味で使っています。少しわかりやすく説明すると、例えば「○○年□月△日、巨人戦の1回表。最初の打者の第×球目の結果は?」のような条件を与えて問い合わせをすると、「ピッチャーは●●、打者は■■、0対0、ノーアウトランナーなし、カウント 0-1、外角のスライダーで空振りストライク」のような結果が返ってくる仕組みを REST API と呼ばれる手法で用意しました。

これらのデータそのものはデータスタジアム様や読売巨人軍様から提供いただいているものです。1球毎、1打席ごと、1試合ごとなど、粒度の異なるデータを1年ちょっと全試合分提供いただきましたが、そのデータファイルそのものが流出するリスクは回避したい(つまりデータファイルは参加者に渡したくない)という事情がありました。そのため、上記のような問い合わせ条件にあうデータを取得できるような仕組みをウェブ API として(IBM Cloud を通じて)提供させていただきました。


ではそのようなウェブ API の仕組みをどのようにして短期間で(2日程度で)用意したのか? この答は実は以外とシンプルで、以下の3つの仕組みを組み合わせただけでした:
(0) 提供いただいたデータを全てリレーショナルデータベースに格納
(1) StrongLoop LoopBack を使ってデータベースを丸ごと API 化し、ウェブを通じて読み書き更新削除検索といった REST API を自動生成
(2) API Management サービスを使って (1) で作った API のうち、検索(問い合わせ)の API だけをハッカソン参加者に公開


2016042801


まず準備段階 (0) として、提供いただいたデータはいわゆる「ファイル(オフィスファイル、画像ファイル、テキストファイル混在)」でした。このままでは利用や配布/提供が難しかったため、一旦リレーショナルデータベースなどに全データをロードしました。今回は IBM の SoftLayer クラウドのサーバーを使い、その中にデータベースエンジンを導入して、全データをまとめてロードしました(要するにデータベース化しました)。 技術的にはこれでこのデータベースに適宜アクセスできるような仕組みを用意すれば外部から検索したりできる、のですが、上述の理由からデータベース丸ごとでの提供をするわけにはいかない、という背景がありました。

次にこのデータベースを API 化しました(1)。IBM Bluemix でも提供されている StrongLoop LoopBack サーバーを使うと、各種データベースを指定するだけでその中身を読み書き更新するような REST API を自動生成してくれます。

また自動生成された API には削除したり更新したりできるものもありますが、今回のハッカソンではあくまで参照(問い合わせ) API だけを公開したい、という事情がありました(2)。作成した API をわざわざ無効にする、という方法もありますが、今回はこれも IBM Bluemix から提供されている API Management 機能を使って、実際には問い合わせの API だけを公開し、かつ利用状況も合わせてモニタリングできるような方法にしました。


なお、今回の API 生成で使ったこのような (0) (必要であれば)DB を準備、(1) API 化、(2) API を限定公開して監視 という3ステップについては、以前にこちらのブログエントリで詳しい手順を紹介しています。詳しい手順などはこちらを参照してください:
Bluemix だけで REST API を作成/公開/管理する


「API を用意する」と聞くと、ちと面倒そうな印象を受けるかもしれませんが、IBM Bluemix や SoftLayer 、そして これらから提供されている各種サービスを効率よく使うことで、面倒な作業を簡略化し、目的の API を(仕様書に相当するドキュメントごと)作って公開して管理する、といったことが簡単に実現できてしまいます。 もちろんデータベースの操作に慣れた方からすると、直接データベースを扱えた方が効率は良かったかもしれませんが、様々な事情を考慮した結果の1つの実現の形として、今回はこのような提供形態とさせていただきました。今回のジャイアンツハッカソンの成功を受け、「このやり方がある程度は正しかったのではないか」と思っています。もちろんまだ改良・改善の余地はあると思いますが、「データを取りまとめて API を提供する」という役割については一定レベルで果たせたのではないかと考えています。 そしてその作業は、上記のように(IBM クラウドを使うことで)結構簡単に実現できるものだと思っています。


このエントリの続きです:
レッドハットの開発者向けサブスクリプション(無料)を使ってみた


上記エントリで、レッドハット社が開発者向けに無料で提供を開始した RHEL 7.2 の導入方法を紹介しました。普通に導入して使うまでであれば、この方法で問題なくできるはずです。

が、この状態から新しいツールを yum でインストールしようとして躓きました。ライセンスを購入して利用しているわけではないので、標準のレポジトリを使うことができず、結局 yum の利用ができないのです:
2016042701


というわけで、インストール時に使ったメディア DVD(iso)を使って yum のリポジトリを作り、そこから yum でツールを導入できるようにしてみます。


まずはインストールメディアを RHEL システム内にマウントします。DVD で所有している場合はトレイに入れるだけで自動的にマウントしてくれるはずです。iso ファイルで所有している場合は、以下のコマンドを使ってマウントします(この例では /root/rhel-server-7.2-x86_64-dvd.iso ファイルを /mnt/iso にマウントします):
# mount -t iso9660 -o loop /root/rhel-server-7.2-x86_64-dvd.iso /mnt/iso

次に /etc/yum.repos.d/localdvd.repo ファイルを以下の内容で新規に作成します。マウントした iso(または DVD)をリポジトリとするための記述になってます:
[localdvd]
name=RHEL 7.2 x86_64 DVD
baseurl=file:///mnt/iso/
enabled=1
gpgcheck=0
gpgkey=file:///mnt/iso/RPM-GPG-KEY-redhat-release

そしてリポジトリリストを更新します:
# yum repolist all

これで DVD(iso) の中にあるパッケージファイルが yum で導入できるようになりました。普通に yum install コマンドなどが使えるようになっている、はず:
# yum install screen


IBM Bluemix 上の Node.js ランタイムアプリを効率的にデバッグしたり、コンソール画面にアクセスする方法を紹介します。

まずは Bluemix 上にデバッグ&コンソールアクセスの対象とする Node.js のランタイムアプリケーションを作成します:
2016042401


ここではアプリ名を dotnsf-nodejs-debug と設定したと仮定して以下を続けます。実際の名前に置き換えて読み替えてください:
2016042402


Bluemix 上のランタイムアプリをデバッグおよびコンソールアクセスするには、このランタイムの環境変数を設定します。ユーザー定義環境変数を1つ追加します:
2016042403


環境変数名は BLUEMIX_APP_MGMT_ENABLE 、その値に devconsole+shell+inspector を指定して保存します。ちなみに devconsole を追加することで(この後にアクセスする)管理用ポータル画面が有効になります。そこから呼ぶためのシェル(shell)とデバッガ(inspector)の両方を有効に指定しています。シェルだけが必要であれば inspector は指定しなくても構いません:
2016042404


そしてランタイムを再ステージングすると、管理ポータルが有効になります:
2016042405

管理ポータルにアクセスする前に一度アプリケーションの挙動を確認しておきます。ランタイムが稼働中であることを確認し、また少し多めにメモリを割り振っておきます(図では 512MB)。そしてランタイムの URL にアクセスします:
2016042507


Node.js の標準ランタイムでは "Hi there" というメッセージが単純に表示されます。これが初期状態の画面ということを確認しておきましょう(後で直接書きなおして変更します):
2016042407



再ステージング完了後、ブラウザで以下の URL にアクセスします:
(元のランタイムの URL)/bluemix-debug/manage/


Basic 認証のダイアログが表示されるので、自分の Bluemix ID とパスワードを指定します:
2016042501


正しく認証が行われると、管理ポータルの画面が表示されます。ここからシェルやデバッガーにアクセスできます。では最初にシェルにアクセスしてみましょう。"Open Shell" と書かれたボタンをクリックします:
2016042502


すると新しいタブが開き、bash が起動したシェルが動いているはずです(動いていない場合は "+NEW WINDOW" と書かれたボタンをクリックして開きます):
2016042503


この画面は bash のシェル画面なので普通に標準コマンドが動きます。例えば "ls" 入力すると、カレントディレクトリのファイル一覧が表示されます:
2016042504


では試しにこの場でファイルを編集してみましょう。コマンドラインで以下のように指定して、vi で public/index.html ファイルを開きます:
$ vi public/index.html


vi 内で適当にファイルを編集して保存します。以下の例では "Hi there" と書かれていた部分を "Hello there" に書き換えています:
2016042505


こうして改めてランタイムにアクセスすると、画面内の表示が書き換わっていることが分かります。再デプロイや再ステージングなしにファイルを書き換えることができました:
2016042506


もう1つのデバッガの方も試してみましょう(こちらは FireFox ではなく Chrome 限定で使える機能です)。Chrome ブラウザで管理ポータルを開き、"Open Debugger" と書かれたボタン部分をクリックします:
2016042501

するとデバッガっぽい画面が表示されます。ここで JavaScript にブレークポイントを指定したり、変数の値を確認したりすることができるようになります:
2016042502


ブレークポイント設定は JavaScript コードの一部をマウスでクリックします。これでブレークポイントが設定できました:
2016042503


開発ポータルの画面で、該当アプリをサスペンドします:
2016042505


サスペンド後にデバッグ画面を見るとデバッグモードになっています。下図赤枠の部分をクリックして、デバッグモードで起動します:
2016042506


すると指定したブレークポイントまで実行されてコードが止まります。画面右ペインを見ると、この時点での変数とその値が一覧で表示されているはずです。この例では appEnv 変数を取得する行にブレークポイントを設置しているので、止まったこの時点ではまだ appEnv 変数は undefined と表示されています。下図赤枠部分(さっきの隣のボタン)をクリックして、一行だけ実行してみましょう:
2016042507


一行先に進み、appEnv 変数が設定され、その中身を確認することができるようになりました:
2016042508



以上、簡単にですが、Bluemix 上の Node.js ランタイムでシェルコンソールを使ったり、デバッガを使ったりする方法を紹介しました。詳しくはこちらのドキュメントも参照ください:
https://console.ng.bluemix.net/docs/manageapps/app_mng.html#app_management


東芝 dynabook N29 を1週間の出張に持って行って使ってみた感想をまとめます。

最大の特徴は 8.9 インチという画面サイズを実現した小型化を実現した上でのフルキーボードモデルであるということ。そしてこのキーボードがデタッチャブルとなっていて、画面部分だけを取り外して Windows 10 タブレットとしても使える、ということです:


この N29 は自分にとってのメインで利用する機種ではなく、購入後もあまりまとめて利用する機会がありませんでした。このたび1週間ほどの出張に出かける機会があったので、そこに N29 を持ち込んで使う、という目的で使ってみました。

余談ですが、この N29 はネットの一部では「Libretto の再来」と呼ばれています。Libretto を初代の 20 モデルから使い続けていた自分としてはこの評判から気になっていたモデルでした。


最初にカタログ上のスペックをまとめておきます。詳細はこちらを参照していただくとして、ざっとこんな感じ:
CPUインテル Atom Z3735 1.33GHz 4コア 4スレッド
メモリ2GB
ディスプレイ8.9 インチ 1920x1200 タッチパネル対応
キーボード65 キー + マルチタッチ対応クリックパッド
ストレージ64 GBフラッシュメモリ(空きは約 49GB)
ネットワークインターフェース無線LAN, Bluetooth
SD カードMicroSD x 1
(キーボード接続時に SD x 1)
外部インターフェースヘッドセット端子 x 1
MicroUSB x 1(充電用)
HDMI(micro) x 1
(キーボード接続時に USB x 1)
バッテリー駆動時間約6時間(キーボード接続時だと約 12 時間)
外形寸法(mm)235 x 161 x 9.8
(キーボード接続時だと 235 x 170.6 x 19.9)
重量479g(キーボード接続時だと 989 g)
OSWindows 10 Home 32bit
付属アプリMicrosoft Office Mobile
筆ぐるめ22
ウィルスバスタークラウド90日間、等


また、自分のこの N29 の使い方ですが、ほぼ 100% キーボードを接続した状態で使います。主目的はウェブとプログラミング、そして SSH などコマンドラインを使ったサーバー管理といった所。要はタブレットとしてキーボードを外して使う、というのは、ごくたまに「自慢する時」だけです。なので、Windows 10 もタブレットモードを無効にして使っています。その利用方法を前提として以下を記載します。

結論を最初に書くと「外付けマウスを併用すると結構使える。マウスなしだと使いにくい」です。8.9 インチという A6 に近いサイズを実現するためキーボード配列が特殊になっています。例えばですが右 SHIFT はありません(SHIFT キーは左のみ)。あと基本は日本語キーボード配列なのですが、 \ など一部のキーの配置が一般的なものとは異なっていて、ブラインドタッチに慣れた人でもたまに間違えると思います。小型化を優先した結果だと思いますが、必ずしも打ちやすいキーボードではありませんでした(まあ、でも慣れの範囲だと思う)。 そしてそれ以上に使いにくかったのがキーボード付属のクリックパッドです。右と左の判断が甘いのか、右クリックのつもりで使っても左クリックと判断されることが(今でも)結構な頻度であります。マルチタッチに対応しているのでスクロール(二本指で上下)などは簡単に行えますが、どちらかというと使いにくいインターフェースでした。ここはキーボード部分にある USB ポートを使って外付けマウスを付けた方がいいと思いました。なお画面は 8.9 インチですが、解像度は 1920x1200 と(このサイズを考えれば)かなり高めです。また1つ上の N40 モデルにすることで一回り大きなキーボードを手に入れることもできます。

そしてストレージは 64 GB のフラッシュメモリです。起動速度を意識しての eMMC だと思いますが、この中に色々保存するのは無理があるので、自分は 64GB の MicroSD カードを挿入して、データはそちらに置くようにしました。128 GB あれば、あとはクラウドストレージを併用してなんとか使える、という印象です。

N29 は基本スペックが上記のようにあまり高くないので、重めのアプリを入れて使うことには向かないと思っています。自分は普段はアプリケーション開発用に Eclipse を使うのですが、これはかなり苦しいアプリです。逆に Chrome やテキストエディタにはほぼ支障ありません。ただメモリが少ないせいか、Chrome でタブを開きすぎると、タブを切り替える度に再読み込みが発生し、スムーズなタブ切り替えが出来るわけではない、という印象を持ちました。


N29 の形状ですが、クラムシェルを閉じるとバッテリー部分が本体から飛び出す形になります。実はこれが結構便利な仕様でした:
n29_1


この飛び出した部分は、クラムシェルを開いた時にキーボードを押し上げる形になり、キーボードに自然な傾斜が生まれます。つまり「画面を開くと少し傾いて打ちやすくなる」のでした。これは目からウロコの、なかなか面白いトリックです。実際これで腕が疲れにくくなり、結構楽に使えました:
n29_2


そして特筆すべきと思ったのがバッテリーの持ちです。キーボードを併用することで事実上2つのバッテリーを使うことになっている、という背景もあると思いますが、かなり持つという印象でした。カタログスペック上では 12 時間ということですが、本当に(連続で)そのくらい持つのではないかというくらいの減り方でした。ストレージがメモリオンリーなのと、重いアプリを初めから諦めて使っていなかったということも関係あるかもしれません。でもかなり優秀なバッテリー消費という印象でした。


(オマケ)
少しだけ余談を。モバイル PC やタブレットを使う上で、「Bluetooth の外付けキーボードを使う」ことについて触れておきたいです。自分の考えは外付けキーボードを根本から否定するつもりはないのですが、「できれば使いたくない」派です。理由は2つ。

まずモバイル PC やタブレットは機動性を重視しています。要は「持ち歩きやすさ」も要素の1つだと思っています。一方でデベロッパーやサーバー管理者にとっては(プログラミングや SSH などで)キーボード操作は避けて通れません。そういった中で外付けキーボードを別途持ち歩く必要がある、というのは自分にとっては好ましくありません。

もう1つの理由は外付けキーボードのバッテリーを意識する必要がある点です。ただでさえスマホが個人用/会社用と複数台あって、そこにモバイル PC もあって、複数マシンのバッテリーを意識していないといけないのに、更に外付けキーボードのバッテリーも管理下に加える、というのは避けたいのでした。

これらの理由から、自分はモバイル PC に Bluetooth キーボードは「避けて通れるなら避けたい」のでした。その点では今回紹介した N29 や、Microsoft Surface は評価を高く考えています。また同じ理由でマウスも Bluetooth ではなく有線の USB マウスを持ち歩くようにしています。
(オマケ終わり)


というわけで、自分のようにテキストエディタや SSH で、比較的キーボードを多用する使い方の人にとっては N29 はマウスを併用することでそれなりに使いやすいモバイルノート PC という印象です。逆に画像編集やオフィスアプリ利用などだと(標準アプリが貧弱ということもあって)ちょっと不便に感じるかもしれません:

 

このページのトップヘ