2016年5月23日月曜日

JJUG CCC 2016sでボランティアスタッフとかしてきた

JJUG CCC 2016 Springがあったので、ボランティアスタッフと「AB-7 若者にJavaの好きなところ嫌いなところきいてみた」でパネルディスカッションのようなことしてきました。

前日日付変わるギリギリまで渋谷で飲んでいたので午前中はぐったりしてるんじゃないかと心配でしたが、仕事内容もそこまで無かったので良かったです。

ボランティアスタッフとしてやった事としては

  1. ロビーでの会場案内
  2. 部屋の片付け
  3. タイムキーパー
の3つぐらいでした。
ロビーでの会場案内はエレベーター前で立ってこっちですよーと書いた紙を持ってるだけ。丁度Raspberry Pi with javaの話があったタイミングでセッションで自分がしゃべろうとしてるネタと被ってないかと内心ヒヤヒヤして話聞きたかったタイミングでしたが、まぁ結果として問題なかったです・ω・
これは会場のルールなのか張り紙が出来ないからやってたそうですが、正直必要だったのかちょっと疑問。
午後からは役目自体がなくなったっぽかったです。会場の立て看板とか貸してくれたらいいのになー。
ただ、立ってて面白かったのが別の会場であった会議か何かの帰りの人に声をかけられて色々と定年後のお話を聞かせてもらったこと。立ってるだけで暇だったので凄く面白く感じた。

タイムキーパーは10分前と5分前に登壇者に紙を見せて時間をお知らせする役目でしたが、担当したセッションの登壇者の方々はよく訓練された発表者のようで11分前に時計を見る、6分前に時計を見る、とかなり正確な体内時計を持っていらっしゃるようで、ほとんど必要とされてませんでした(´ . .̫ . `)


AB-7のセッションではJavaの嫌いな話をしてくれと言われましたが、普段から全くと言ってJavaを使っていない人間だったのでちょっと困りましたが、組込っぽいエンジニアとしての目線で何故Javaを最近使ってないのかっていう話をしました。 資料
まさか、JavaのカンファレンスでJava嫌いな話をすることになるとは予想してませんでしたw
次は複数人のセッションでなく、LTなりセッションなりで話せるようになりたいですが、如何せんJavaを使わないので別の機会になりそうです。

また次回CCCがあればボランティアスタッフなりもう少し責任のあるスタッフをやりたいかなーと思いました。



#以下アフィリエイト用の広告です

-->

2016年3月27日日曜日

Thinkpad X1 Carbon 2016を買った

Thinkpad X1 Carbon 2016を買ったので今後いろいろとレビューしておこうと思う。


構成

買ったのはこんな感じの構成です。色つけたところが標準から変えたところ。
WiGig対応が欲しかったのでどうしてもWQHDのディスプレイにせざるを得なかった。

プロセッサーインテル Core i7-6500U プロセッサー (2.50GHz, 4MB)
初期導入OSWindows 10 Home 64bit
導入OS言語Windows 10 Home 64bit - 日本語版
ディスプレイ14.0型WQHD液晶 (2560x1440 IPS)
メモリー8GB LPDDR3 1866MHz (オンボード)
グラフィックスインテル HD グラフィックス 520
キーボード英語キーボード (バックライト付)
指紋センサー内蔵指紋センサー
内蔵 カメラカメラ(HD 720p対応)あり 、マイクロフォンあり
セキュリティーチップTPMあり
ハード・ディスク・ドライブ256GB ソリッドステートドライブ SATA (OPAL対応)
ポインティングデバイスThinkPadクリックパッド
バッテリー4セル リチウムイオンバッテリー (52Wh)
電源アダプター65W スリムACアダプター
ワイヤレスインテル Tri-Band Wireless-AC 18260(2x2、WiGigおよびvPro対応) + Bluetooth 4.1
WiGig Selection対応
WiGig DockWiGig ドック
Onelink+ アダプターHDMI-VGA変換アダプター
標準保証1年間 引き取り修理

買った理由

これまで使ってきたMac Book Pro Retina(2012 Mid)ですが、メモリ16GBにしてあり、家に置いて使うPCとしては未だ文句のでないスペックです。
CPUは2.3GHzの下のスペックですが、ほぼ文句なしです。メモリもてんこ盛りにしておいたのでChromeでタブを開きまくっておきながら、メモリ8GBを仮想マシンに割り当てても快適です。
まだMacが必要となる場面や家で高解像度、広い画面が必要となるような場面ではしばらく使い続けるでしょう。

でも、このMBPr、重いんです。カタログスペック2.02Kg。アクエリの2Lペットボトルをいつも持ち運ぶ気にはなれず、関東へ戻ってきてから行く機会が一気に増えた勉強会にはXperia Z4 Tabletにキーボードつけて行ってました。ただ、流石に画面がちょっと小さいのと、暇な時に開発もガッツリとやりたいなーと思い新しいPCを買うことにしました。

ちなみに、Xperia Z4 TabletでもCloud 9などのクラウド型の開発環境を使えばRubyとかの開発できます。SIM入れれば単体でいつでもどこでも開発可能!


ThinkPadにした理由

トラックポイント最高。ホームポジションから手を離さないでいろいろと作業ができるのが最高。
ThinkPadのBluetoothの英字キーボードを仕事で使っているのですが、アイソレーションタイプしか使ったことがないニワカなのでX220みたいな7段配列じゃなくてもOKでした。

X260とT460sと悩んだ

X1CとX260でかなり悩みました。
サイズ感、拡張性、どれをとってもX260が最高です。ただ、どうしても解像度が低いのが気になったのと、購入時にWiGig対応がなかったので仕方がなく候補から除外。
あとT460s。こいつは拡張性のあるX1Cのような存在。メモリが後付で増やせれたりSSDを交換できたりする。しかもGPUまで載ってる。

しかし、当初の予定の軽さ再優先、画面の広さを取りX1Cを買いました。

届いてみて

キーボードの打ち心地は最高です。トラックポイントもいい。Windows10も言われているほどクソでもなく調教のしがいのあるOSだなと。
ただ、Macと比べてテキストエディタでEmacsキーバインドでのカーソル移動ができなかったり、フォントが汚かったりと微妙な点も何点かありました。

最大のX1Cとして(というか高解像度)の欠点が、DPIを100%にするとめっちゃ文字が小さい。かと言って見やすい150%にするとフルHDよりも解像度が低くなるという問題が。
WiGigが不要でフォントが小さいと困るという人はフルHDにしたほうが確実に良いです。

高解像度が微妙だったので、X260がWiGig対応したらフルHDじゃなくてもいいのかもしれない。



#以下アフィリエイト用の広告です

-->

2016年3月26日土曜日

世界のビールと音楽を組み合わせてデータ分析を行うイベントに参加してきた


世界のビールと音楽の組み合わせをデータ分析で最適化!


ビール好きでデータ分析を始めてみたい私には最高のイベントがあったので前日に主催者のuzuramの宮本さんとFacebookでやり取りして参加してきました。

このイベント、音楽を聞きながらビールを飲んで、どの音楽と、どのビールが合うかを参加者が主観で決めていき最後に解析をかけて

「この音楽には、このビールが合うという人が多いです」

と言ったようなレコメンドができるようになろうというイベントでした。
最高か。ビールたくさん飲めて、データ分析の入門まで教えてもらえるとか最高か。

すこし残念だったのが他のイベントと被っていたのか直前キャンセルが多数あり参加者が講師含めて6名となってしまったこと。ただ、おかげでビール堪能できました。おつまみ買っていけばよかった。

講師の方は DATUM STUDIO株式会社 の中原さん。花粉症が辛いらしくティッシュが手放せない様子でした笑

ビール


今回のメイン。。。じゃなくて、解析対象となるビール。たくさんありました。
世界のビールと銘打ったイベントだけあって世界一周をしてました。(南極大陸はなかったので5大陸制覇ならず)
以下今回のビール説明と私の感想です。ビールの説明はイベントページからの転載です。

ネグラモデロ

産地:メキシコ  特徴:ダークモルト、ホップのバランスのとれた風味と繊細な香りを持つミュンヘンスタイルビール(ダークラガー)。メキシコで第1位、アメリカの輸入ビール市場で第2位のダークビールブランドで、クリーミーな泡と明るい黒褐色の液体が特徴。特別な食事や特別な瞬間を演出するのに最適なビール。

自分としてはこんな印象でした。
  • すこし甘めな印象(バーバーバーよりは甘くない)
  • 少し香ばしい香りがする

バーバーバー

産地:ベトナム  特徴:キレが良く、スッキリ爽やかな味わいは日本人の味覚にあったビールです。昨今のベトナムブームによるベトナムレストランの急増で、国内でも躍進しています。サイゴン社はベトナム最大手のビールメーカーで、製法技術はフランスからの影響を受けています。

自分としてはこんな印象でした。
  • ビール?って思うくらい甘い(比較的温度が高めだったからか?)
  • ホップ感は全く無い

フラーズ ゴールデンプライド

産地:イギリス  特徴:フラーズが誇るプレミアムストロングエール。深い琥珀色で優しい苦味と穏やかなホップの風味に芳醇な麦芽の味わいを持ち、甘いオレンジオイル、トーストしたパンを思い起こさせ、甘味と苦味がこの濃厚なビールにバランス与えます。

自分としてはこんな印象でした。
  • かなり濃い
  • 黒ビールっぽい
  • 一気に飲むと日本酒に近いアルコール感
  • 後味に残るアルコールの感じが日本酒に近いものがある

ベジエールレタス 瓶

産地:日本  静岡県: 特徴:産直団体(株)野菜くらぶのトレーサビリティーのしっかりしたレタスをふんだんに使い世界でも珍しい飲み物を仕上げました。食事に合い、フルーティーで爽やかな仕上がりが楽しめます♪
本物に徹底してこだわりました!だから、原材料も麦芽・ホップ・レタスのみ。 しっかりと酵母が効いた深い味わいでありながら、フィニッシュにレタスの爽やかさが駆け抜けます。 食前酒でも食中酒としても、楽しく豊かな時間を提供します。 野菜くらぶのレタスは、適地適作、産地リレー、契約栽培契約販売を基本に、群馬・静岡・青森・岡山の産地と技術を共有し、全国をリレーすることで一年通して安定的に出荷しています。 “VEGEALE LETTUCE”でも、“野菜くらぶブランド”のフレッシュなレタスを使用しています。
自分としてはこんな印象でした。
  • 泡、香りがすごいレタス感がある
    • 青臭いような嫌な感じではなく、さわやかな感じ
  • 他のビールと比べると軽い感じ
  • クラフトビールだけども大手のビールと同じような飲みやすさ(製法の問題?)
  • すごい日本人が好きな味

パウラーナー ヘーフェ ヴァイスビア

産地:ドイツ  特徴:50%以上の小麦を使用し、瓶詰め後も瓶の中で二次発酵します。白く濁ったやや濃い黄白色にクリーミーな泡立ち。バナナ、クローブ、パンの香りがあります。レモンのような柑橘系のさわやかな酸味とやさしい酵母の甘味とのバランスが素晴らしいビールです。
自分としてはこんな印象でした。
  • 軽めの味
  • 甘くもない
  • 香りも強くなく程よい
  • 泡がすごいフルーティーな味わいでバナナっぽい感じ

バドバー ビール 瓶

産地:チェコ   特徴:チェコの最高級ホップ、モルト、地下300mの良質の水により造られたバドバービールは、700年の伝統を誇ります。麦やホップが主張しつつも調和の取れた味わいで、後にバドワイザーのモデルともなった純粋ビールです。
自分としてはこんな印象でした。

  • 軽い。さすがバドワイザーのモデルとなったビール
  • すごい飲みやすいからはじめの一本に最適

音楽

音楽もまた古今東西いろいろでした。個人的にはEDMの曲がヒット。以前別のイベントで聞いたことあったけども曲名がわからなかったのが、このイベントで曲名がわかった!しかもAmazon Prime Musicにもあり大助かり。
会場では何故四季の夏なんだ?と疑問が出てました。なんでも参加予定だった方からのリクエストだったそうなのですが、何故夏なんだろう。。。もうすぐ春なのに笑

  • JPOP: 世界に一つだけの花
  • 洋楽: Oasis What ever
  • EDM: Timmy Trumpet - Freaks
  • クラシック: ビバルディ 四季夏
  • JAZZ: Take Five
  • 演歌: 津軽海峡冬景色

飲みながら音楽を聞いて、参加者からは積極的なデータ分析についての質問が飛んだりとワイワイできました。少人数の勉強会は参加するまでの敷居が高いですが参加さえしてしまえば講師の方とも距離感近いので良いですね。


そんなこんなで一応イベントの趣旨であるデータ分析を行うために音楽とあうビールをスプレッドシートへ入力していきました。一通りできたらCSVでダウンロードして入門編が始まりました。

Rとは?

Wikipediaによると

オープンソース・フリーソフトウェアの統計解析向けのプログラミング言語及びその開発実行環境である。

統計解析向けに作られているプログラミング言語だそうです。イベントの講師の方に質問してみたところ、よく解析に使われるPythonとか、Matlabと比較して見ても統計解析向けに作られているライブラリが多くあり簡単に使うことができるそうです。ただ、汎用的なプログラミング言語としては少し使いにくいところもあるそうです。


アソシエーション分析

集合論、包含関係
アマゾンのおすすめみたいな機能を実現するための分析
Supportでソートして、Confidenceで考察

頭に入れておいたほうがいい概念

支持度(suport)

  • 商品Xと商品Yが一緒に買われている頻度がどのくらいの規模で発生しているかを確認する指標
  • 調べたいケース/全ケース
  • まず一番最初に見るべき指標
  • 発生頻度でソートして頻度が少ないケースは無視したほうがよい

確信度(Confidence)

  • 一緒に買われやすいかを表現
  • XとYに方向性
  • Xを買った人がYをよく買っていればおすすめできる
  • 包含関係でおすすめは変わってくる
  • ベン図

リフト(Lift)

  • Lift = (Xを買う人がYを買う確率) / 全体の中でYが買われる確率
  • 何もしなくても商品Yをどれくらいの人が買っているかという確率に対して、商品Xを買った人でYも買う人がどれくらいいるかを確率(Confidence)を比較する指標

実装

実装はRStudio上で行いました。最終的なコードはGistにあげておきました。
中原さんがすごい丁寧に説明していただけるのですごいスムーズに実装でき、ビールも飲みながらでも実装が終わらせれました。
ただ、唯一の問題が前半戦でしこたまビールを飲んでいるので途中でかなりトイレに行きたくなってしまいました。お酒の入る勉強会はトイレ休憩を頻繁に入れたほうが良さそうです。

RStudioがすごい便利でMatlabと似たような統合環境だなといった印象。

コンソールでデータを表示



すごくエクセルです。


棒グラフで出現頻度を表した。


データの相関関係を図で表した

などなどがめっちゃ簡単に実装できました。アソシエーション分析のパッケージもPythonにあったので、そちらも試してみないと一概に言えないですがここまで簡単に表現が色々できるのであればもっと凝った分析や分析結果からモデルのストーリー建てなどのもっと重要な事に時間がかけれるようになりそうです。データ分析すげぇ!!楽しい!!

今回の考察としてはレタスビールとオアシスの曲がすごく相性が良さそうだというのが参加者としての共通認識だったようです。(人数少なかったしはじめに飲んだビール、はじめにかかっていた曲という事もありそうですが)


まとめ

個人的に感じたこととしてはデータ分析を見える化するまではツールで簡単にできましたが、そこからストーリーを組み立てていくということ、見える化された情報から何が起きているのかを意味付けするということが大変なのだと感じました。実際相関図をみてレタスとオアシスは相性良さそうというのは素人目でもぱっとわかりましたがそれ以上のことは正直わかりにくかったです。でも講師の中原さんはポンポンとストーリーを出していたのでやはり見えている世界がまた違ったようです。
こういう所がノウハウであったり強みになっていくのだと感じました。

ただ、分析しなくても分かった事があって、世界中のビールは美味しいということでした。
いや、もう少しデータの母数を増やしたいので、ぜひ次回の開催をお願いしたいです。


#以下アフィリエイト用の広告です

-->

2016年2月29日月曜日

JOT DASHをAmazonタイムセールで買った


【日本正規代理店品】Adonit Jot Dash ペン先1.9mm 高精度スタイラスペン iOS / Android OS 対応 チャコール ADJDC

AmazonのタイムセールでAdonit Jot Dashがちょっとだけ安くなってたので買ってみた。
もともとタブレットで裏紙代わりにメモを色々と書きたかったので丁度良いタイミングだった。

せっかくなので家にある色々な端末で書き味を試してみた

結果

iPad最高。普通の紙よりは書き味は劣るけども十分に実用になる。
ペン先も細くボールペンで書いているみたいな感じになる。
買って正解だったと思います。無駄な紙が減らせれるのでゴミ捨てが楽になりそう

それでは細かい内容です。

Jot Dashの評価

DASH!!

名前の通り書き出すのにダッシュで書けます。充電スタンドとペンが磁石でピタっとくっつくのですが、取り外して頭のボタンを1回ノックすればもうすぐに書けます。たまにノックするの忘れてそのまま書き出してしまい「アレ?」となることがあるくらいすぐに書けます。

ペン先

ただ、ペン先が固い+1ミリほど浮いてるので書いているとカチャカチャ音がします。静かな職場でカリカリ書いていると目立つかもしれないレベルです。
少しペンを寝かせて書くと静かに書けるようです。

書き味

ボールペンみたいです。だいぶ固めです。端末の画面が汚れていると書いた軌跡が見えるようになります。ペン先が浮いている分柔らかい書き味になるかと思ったのですがただ音を出しているような気がします・・・

それでは端末ごとの比較してみましょう。

比較端末

  • iPad mini(第1世代)
  • Xperia Z4 tablet
  • Xperia Z5
  • Nexus 5
  • KATANA 02
Jot Dash自体はガス工事のおじさんとかがカチャカチャ音を立てて使っているようなペン先の感じ。

アプリは以下の当たりで試してみました。
  • metamoji note lite
  • Onenote

iPad mini

世代としては初代なのでもう3〜4年くらい前の端末です。表面に保護シートあり。



metamojiでザクっとアルファベットを書いてみたらかなり精度良い。期待以上です。
字が汚いのでアレなんですが、ガタガタしない。Mとか自分の筆跡通りです。Sのカーブもキレイに出ています。

Xperia Z4 tablet

こいつはキーボード付きでいつも持ち歩いている愛用機です。表面に保護シートは無しです。


こちらもざっくりとアルファベットをmetamojiで書いてみました。しかし、細かい部分がガタガタになって正直残念な感じ。Sとかガタガタになってしまいましたし、QとかQじゃない感じに。。。
ただコレ、アプリというかスクリーン自体の性能っぽいです。試しにonenoteで書いてみました。


やっぱりダメっぽいです。Sとか悲惨。
アプリのダメだしですが、onenoteめっちゃ手書き使い難いです。消そうと思うと消しゴムツールで線を1本ずつ消す必要があります。UnDoもどこからやればいいのかサッパリ分からないです。

Xperia Z5

新しい端末なので少し期待。保護シートナシです。
スマホ画面なので少しメモには小さいので微妙ですが試しに書いてみました。


うーん。微妙です。Z4 tabletとそんなに変わらない書き味です。画面もタブレットと比べて小さいのでメモとしてはあまり期待は出来ないです。

Nexus 5

5Xじゃないです。初代です。保護シートアリです。


Z5よりも微妙な精度になってしましました。もう常用はしていない端末なのでオマケ程度です。

KATANA 02

Windows 10 mobileです。密かにお気に入りな端末です。Windows 10 mobileのアプリ開発のためにWindows 10のPCが欲しくなってます。
Windows 10 mobileなのでonenoteで書いてみましょう


アレ?


アレアレ?Onenoteじゃ手書き出来ない??
ストアにはインクを追加できるみたいなこと書いてあるのに?

仕方ないのでEvernote

Evernoteお前もかー!!!


ちくしょー!期待のmetamojiもストアにねぇじゃねか!!

ということでWindows 10 mobileでの手書きは諦めました。
何でも出来そうで、何もできないWindows 10 mobileかわいいなー。もー。

まとめ

結果にも書きましたがiPad最高です。手書き精度は頭1つ抜き出てます。Apple Pencil使うともっと精度いいのでしょうね。ただ、OSレベルでの文章などの共有がAndroidと比べるとまだイマイチな印象。IMEとかね。


iPad miniがWi-Fi版なのですぐにPCに共有したいとなった時に面倒だったので、とりあえずの運用としてはXperia Z4 tabletでできるだけ拡大して図を書きつつ、文字はキーボード入力でいってみようと思います。


#以下アフィリエイト用の広告です

-->

2015年11月27日金曜日

アジャイルジャパン・プレイベント企画「アジャイル初心者向けセミナー」

概要

  • 日時:2015年11月27日(金) 13:00~19:30
  • 場所:NECソリューションイノベータ

アジャイルジャパンのイベントが合ったので行ってきた。
その際のメモ。


初心者向け講義

13:00~15:00

  • 発表者:豆蔵 中佐藤麻記子

セミナーの背景

今回は春先にあるアジャイルジャパンのプレイベント
アジャイルジャパンは2016/5/31を予定

宿題

http://www.scrumguides.org/download.html
→Japaneseを選ぶ

アジャイルとは?

  • アジャイルソフトウェア開発宣言
    • 提唱者ごとにアジャイルの手法が様々あるので何が正解かというのが無い
    • XP
    • scrum
    • それぞれで用語も少しずつ違う

今回は情報が少ないXPベースで話をする

エクストリーム・プログラミング

以下のアジャイルプラクティスを最初に取り入れた手法

  • TDD
  • リファクタリング
  • CI
  • 顧客同席
  • ペアプログラミング

4+1の価値を実現するプラクティス
コミュニケーション、フィードバック、シンプリシティ、勇気+リスペクト

アジャイルプラクティスメトロマップ

http://guide.agilealliance.org/subway.html

アジャイルプラクティスの用語集
なんとなくの見方

  • グレーの線が基礎
  • ピンクがXPでよく使われるプラクティス
  • あとは左から右にざーっと見る

これで停車駅を決める⇒今回使うプラクティスみたいなのを決めると分かりやすそう

イテレーション

scrumではスプリントと言う
1週間から3ヶ月(3ヶ月は長すぎると思う)
要件分析から実装・テストまですべての開発を行う
イテレーションの終わりにはリリースできる動くなにかを用意する

会議体

  • 計画会議(スプリントプランニング)
  • レビュー会議(スプリントレビュー)
    • 作ったもののレビュー
  • レトロスペクティブ(ふりかえり)
    • チームのプロセスのレビュー
  • 日次スタンドアップミーティング(デイリースクラム)

ストーリー

ストーリーリスト(プロダクトバックログ)

  • 要件リストのこと
  • カード形式にしておいて優先度順で上から並べる

アジャイルで最低限使われるプラクティスは上記の3つ

アジャイルが継続できない

  • なぜアジャイルなのか?
    • 現状のプロセスに問題があるのでアジャイルを実施することになったはず
  • 価値にたち戻って考える

ウォーターフォール

  • input -> process -> output
  • WFが正しく動くには
    • 入力が正しいこと
    • 途中に落とし穴が無いこと
    • 設定されたゴールが正しいこと
    • 階層化されたプロセスにおいて100%正しくIPOが繋がっていること

アジャイルにたいする誤解

ウォーターフォールできっちりできる事であればアジャイルよりも絶対に効率がよい

アジャイルは少しずつ進んでは会議でチェックする

  • 作るものと作り方を進みながら変えていく
  • 変えてはいけ無いことを決める
  • インセプションデッキ(プロジェクト憲章)

継続的~~

WFと違ってすべて継続的
「アジャイルな計画と見積もり作り」

  • 計画を立て続ける
  • 要件定義をし続ける
  • 設計をし続ける
  • 実装をし続ける
  • テストをし続ける
  • プロセスを変更し続ける

価値にたち戻る

なんのためにやるのか??

  • コミュニケーション、フィードバック、シンプリシティ、勇気のどれかの価値を高めることができるか?
    • プラクティスが実現できない場合も価値にたち戻る

コミュニケーション

ソフトウェア開発で一番重要なのはコミュニケーション

  • 重要なのであればコミュニケーションをとりやすくするためになにをしているのか?
  • コミュニケーションの齟齬を防ぐ方法

フィードバック

  • 進捗
  • CI
  • TDD

シンプリシティ

よりシンプル、コストのかからないものを選ぶ

  • コミュニケーションの取り方
  • フィードバック
  • 設計

勇気

アクションを起こすための勇気/勇気を持てる仕組み

  • 悪い情報が外に出てこなければフィードバックサイクルは回らない
  • 嘘の無いコミュニケーション
  • 現実を受け止める
    • 受け入れてあげないと真実が出てこない

リスペクト

なぜ価値が4+1なのか?

  • 4の価値はプラクティスで実現される
  • 1の価値はプラクティスで実現できない
    • ベースとなること
  • 目指すゴールにたいするリスペクト
    • 完成したら世の中への影響があるんだ!というようなパッション

事例紹介

「事例聞きたい」病
↓ 対処療法で事例を聞かせると・・・
「でもうちの会社では」病

  • 世の中に全く同じチーム、同じ会社なんてものは無い
    • どこかの成功例を持ってきてもうまくいくわけが無い
    • 銀の弾丸は無い

アジャイルジャパン2016 テーマ

“あなたとつくるアジャイル”


今時のスマホゲーム開発事例、アジャイルテスト添え

15:10~15:40

グリー株式会社 Quality Assurance部
西脇春名氏 @haruna_nishi

資料

聞きたい内容

  • アジャイルテストの話が聞きたい
  • デメリットは?

今時のスマホゲーム開発

昔はビックバンテストやってた

  • 初期段階ではスクラムを採用
  • テスト期間が短い
  • 市場トレンドが変わりやすい
  • カジュアルからハードなゲームまで様々なニーズ

アジャイルテストについて

リリースサイクルの中で各サイクルの ストーリー に対するテスト。システムテストや受け入れテストに近いフェーズなので単体テストとかではない。

グリーの場合

  • 本開発が決まった時点で担当がチームにはいる
  • 毎日探索的テストを実施(仕様の理解・実行をその場で行う)
    • 不具合があれば修正
  • リリース前には従来と同様にマニュアルテストを実施する
    • ここで社内標準の品質保証を行う
  • 開発後期になるとメンバーが増えてアジャイルが消滅することもある
    • それでも探索的テストは続ける
  • 品質の底上げに繋がっている

アジャイルテストのメリット

  • 手戻りの最小化
  • 常にアプリを動作させられる環境を作っておくことができる
  • 実機とエミュレータの差分やパフォーマンスが早期でわかる

手戻り最小化

  • いつの変更でエンバグしたかがわかる
  • 品質保証をする最終フェーズでのテスト時まで重大な不具合を見つからないことがなくなる
  • 品質は製品に組み込むものという意識がチームに形成される

常にアプリを動作させられる環境を作っておくことができる

  • 毎日動作できる状態を維持することを意識させることがチームにできる
  • 継続的デプロイ

実機とエミュレータの差分やパフォーマンスが早期でわかる

  • エミュレータでの操作性と実機での操作性の違いがわかる

QA

  • ビジネス的な価値のあるまとまりは?

    • 機能単位
  • デメリット

    • 工数がかかる
    • やる人によってテストのクオリティに差がでる
  • 自動化は?

    • 自動化は特にしていない
    • ゲームは難しい
    • 画面遷移系はできそう
  • 探索的テストは誰がやってるのか?

    • チームごとで違う
    • 仕様を考える人、品質担当、PM的な人
  • どこのタイミングでやってるのか?
    • 朝と夜
  • なにか基準があるのか?
    • 品質担当が決める
    • 品質担当以外は仕様が満たされているかだけをチェック
    • 1時間ぐらい
    • チュートリアルは全部やる
    • チュートリアルには無い機能も大きな機能には実施している

雑感

  • 品質保証は探索的テストだけでは無理そう
  • 従来の品質保証としてのテストフェーズは必要となりそう

KPTが出なかったチームを自己組織化に近づけたふりかえり改善事例

15:50~16:20

yahoo株式会社 パーソナルカンパニー メール本部
川鯉光起氏

聞きたい内容

  • KPTの話を聞きたい

問題発生

  • 毎スプリント計画どうりに終わらない
  • ふりかえりで意見がでない

ふりかえり改善

沈黙

問題
- 発言が出ない
- 改善案が出なくて改善ができないのでふりかえりをやめようとか言い出す
- KPTが出ないとふりかえりができない

対策
- 大切なのは相手の環境や対場を理解すること。
- 批判や提案は後回し

チームを観察して、チームが困っているであろうことを探しだす
- チームに響く内容の問題を提案する方がよい

世の中一般のやり方を積極的にシェアしていく

結果
 ふりかえりの時間に例示をして話すハードルを下げた
 チームにTryを提案するハードルを下げる

費用対効果のよいものからやろう

問題が大量に出るようになってしまい、ふりかえりの時間が非常に長くなった

原因
 問題が大量
 それぞれに改善案を考えるので時間がかかる

対策
 問題と改善案を同時に考えるのを辞める
 みんなで問題の優先順位をつける

結果
 チームが費用対効果の高い問題から解決するようになった

表面的な問題の解決

問題
 毎回同じような問題が起きる

原因
 根本的な解決をしないで表面的な問題のみを解決してる
 同じことを繰り返す

対策
 問題の深堀
  どうして起きたのか?
 問題の整理
  カテゴリ分け
  抽象化

結果
 チームで根本的な原因を見つけられるようになった

自分ではどうにもならない問題

問題
 根本的な原因がチーム外にある
 偉い人がきめたこと

原因
 なにもできないと思ってる

対策
 ボトルネックをスコープの内にする提案
 無理だと思うことの対策を考える提案

結果
 チームが問題解決を考える前向きなマインドになった

まとめ

相手の立場を理解する
うまくいかないコンテキスト探しは大変
事前に仕入れて解決案をストックしておく

QA

  • 注目した観察点

    • チャット内でのネガティブな話
    • 残業
    • スクラムでの理想とされるチームとの差分
  • 毎スプリント計画通りに終わらない

    • 大きな粒度でみつもりをしていたのを細かな粒度でみつもるようにしたら改善した
  • 例示をあげてハードルを下げるの具体例

    • 具体的な見つけた案を恐る恐る言ってみる
    • ○○さんが残業続いてるけども大丈夫なんすかねー?みたいな
  • スクラムマスターがガリガリと改善をしてくモチベーション

    • 社内の憧れている先輩
    • 改善すると社内のすごい先輩が誉めてくれる
  • ふりかえりで工夫したことはなにかあるか?

    • 今回の発表内容を実施した
    • お菓子を食べながら
    • 空気がよくなるようにした
    • ケーキ買って食べながらやった

雑感

  • スクラムマスターを月ごとに交代は面白い試み。自分たちでも取り入れれそう
  • 相手の立場を理解する。チームを観察するってのは大切

アジャイル開発標準化という立場からのアプローチ

16:30~17:00

SBS株式会社
小林信氏

資料公開予定

聞きたい内容

  • 標準化について聞きたい

掴み

よいものを作り上げたい
 それを体現できるのがアジャイル

標準化という仕事

標準化チームがプロセスをつくって開発チームが使う
策定のためにステップを踏んだ

  1. 叩き台としてプロセス策定
  2. 試行錯誤
  3. プロセス改善
  4. 実開発

プロセス策定

  • スクラムとXPをベースにした
  • 実施する会議体、参加者、やり方を定義
  • 企業文化・体制の取り込み
  • 自動テスト環境、使用ツールの提示

施行開発

定義したプロセスで開発実施
スクラムマスターとして参加
失敗した

たどり着いた自分の答え

  • チームメンバが消極的で各イベントでの動きが鈍かった
    • 各々がチームに対して働きかけ、自己組織化する

自己組織化
 コントロールの分散化
 変化する環境へ継続的な対応

 サーバント型のチーム
  リーダー メンバーが自発的に働けるようにサポートする
  メンバー やりたい気持ちで行動する
       言われる前に行動する
       工夫しようとする

アジャイル開発をするにはチームのメンバーを長期的かつ継続的な教育が不可欠
 アジャイル開発者は幅広いスキルが必要

ウォーターフォールでもできる。アジャイルんい繋げる日々のと陸い

野望を持った旗振り役が必要
どうしてそれが必要なのか考える
助けてくれたら「ありがとう」を伝えよう

取り入れたプラクティス
 デイリーミーティング
 ふりかえり
 プランニングポーカー

デイリーミーティング
 アイスブレイク

ふりかえり
 実施タイミング:各工程の1本目が終わったとき

プランニングポーカー
 WFだとリスク高い

アドバイス

「利用者にとって価値のあるシステムを作り上げる」という原理原則を意識する

アジャイルソフトウェア開発の12の原則
リーン7つの原則

メンターを作る

 ホスピタリティ理論
 TOC(制約理論)
 SECIモデル

アペンディックス

QA

標準化は必要なのか?
 大きな枠組みとしての標準化は必要だけども、標準外のことをやることも大切
 標準化はレール。アジャイルは復車線。

ユーザー企業の期待値は何?
 ユーザー企業の期待値はアジャイル開発という言葉が一人歩きしてたので統一見解を作りたかった

チームへの意識付け
 意識付けが手抜きになっていたので失敗した
  言われたからやっている感がぬぐえなかった

タスクの定義を網羅的にする方法
 オブジェクト指向の考え方ができないと網羅的にあげるのは無理
  タスク分割するには基礎的な技術力が必要
 テスト自動化


組込製品開発組織でのアジャイル実践への道のり

17:10~17:40

DADベースのアジャイル開発プロセスの構築と実践
株式会社東芝 インダストリアルICTソリューション社
IoTテクノロジーセンター プロセス・品質技術開発部
石井裕志氏

聞きたい内容

  • 組み込みでの事例が聞きたい

東芝での事例

リリースサイクルの向上が求められる
モノを作ってみないと良し悪しがわからないプロダクトが増えている

導入障壁

組織として守らなければならない文化・制度
 品質保証の体系
 事業戦略
 既存資産の活用

複雑な利害関係
 それぞれの関係者を説得するのが難しい

CSM(認定スクラムマスター)

導入事例

プロセス構築
試行プロジェクトへの教育
プロジェクトでの試行
ふりかえり

背景
 組み込み製品のSWとそれを用いたシステム製品
 現在クラウドや携帯端末との連携が求められる

課題
 初期段階で要求を固めるのが難しい
 設計フェーズ以降の着手が遅れがち
 協力会社からアジャイル開発が求められた

目的
 設計、コーディングの着手遅れを減らす
 テストに時間をかける

プロセス構築

既存の品質保証体系とアジャイルのプロセスが合わないことが判明
DAT(Disciplined Agile Delivery)
 アジャイルをスケールアップするためのフレームワーク
 3つのフェーズを定義
 初期計画のフェーズが充実

方向付け
 プロジェクトがアジャイルで実施できるのか判断
  アジャイルでやる目的があるか?
  前提条件を満たすか?
  プロジェクト特性をもとにしたアジャイル開発適合性評価手法
 プロジェクトの計画立案
構築
移行
 従来の品質保証体系

プロセス構築の方法

プロセスの検討WGの開催
 隔週で半年
 参加者:設計、品質保証、支援メンバ(アジャイル)

教育フェーズ

参加者:プロジェクト関係者全員
目的:アジャイル・スクラムベースの仕事の進め方を理解する
体験演習5時間

アンケート結果
 ふりかえりに期待
 課題の早期発見
 スプリントレビューで適宜確認できる
 工数が増えないか心配
 変更要求の押し付け
 追加要求の増加

プロジェクトでの試行

捲土重来
成果物の受け入れ可否判断
マイルストーンレビュー
 プロセスがちゃんと回っているかのレビュー

スプリントレビュー

デモ・単体テストの結果確認
ふりかえり結果の共有
結構時間がかかった
 3~4時間かかった
 仕様確認とかもやってた

バージョンアップチャート

プロダクトバックログを適宜調整

審査会

上長がでてくる
バックログ、バージョンアップチャートを使った

ふりかえり

進捗確認がやりやすかった

プロダクトバックログの粒度が難しい
出張等で連絡がつかないとスケジュールが遅れる

進捗確認に効果があると感じた
要求の管理はしやすいが、初期の粒度に基準がほしい
スプリント期間中の品質可視化ができた

雑感

教育フェーズをきちんと利用できるかが勝負になりそう


ふりかえり

17:45~18:00

2015年11月25日水曜日

SphinxCon JP 2015

SphinxCon JP 2015に行ってきたので気になったとこのメモ

http://sphinxjp.connpass.com/event/22024/

基調講演

RE:VIEWはSphinxよりも紙への出力に向いているらしい。
何が違うんだろうか?
→Twitterで組版が楽らしいとの情報 by ひつじさん

Sphinxで電子書籍を書こうと色々やってみた

@momijiame 初音ミクのアイコンの人

Kindle Direct Publishing

  • html
  • ePub(ほぼ択一)
  • txt
  • pdf(日本語未対応)

sphinxの日本語本は少ないらしい

includeディレクティブ

  • toctreeとおんなじように使い分けれるらしい
  • rst拡張子だとエラーになって読めない

code-blockディレクティブ

  • 実行できないからダメ
  • literalincludeディレクティブだとスニペットとか読み込めるからGood

gulpタスク

  • 自動的にビルドしてくれるツールかな
  • sphinx autobuildがある

Sphinxでmarkdownを使う

source_parsersという機能

  • ソースごとにパーサを切り替える機能

conf.pyのsource_suffixを変更する

拡張子で判別するからファイル混合でtoctreeに書ける

  • markdownで書ききれない箇所をreStで書く

commonMarkdown仕様しか使えないからまだ表現力が足りない

  • 注釈とか入れれない [1] ほげほげ とか

(タイトル拾えなかった)

ソフトウェアデザインの今月号にデザインツールとの連携があるらしい

APIドキュメント

JSON Schema

  • だるい
  • 人間が書くもんじゃない

API Blueprint

  • Web API Language
  • Markdown based
  • 色々なものに変換できる
    • HTML
    • mock API
  • Openフォーマット
  • 見た目きれい
  • 共有するには使いやすそう

aglio

  • 変換ツール
  • 一部のシンタックスに未対応

拡張性が微妙(使えない)

  • シーケンス
  • システムの全体像

sphinxcontrib-blueprint

  • コンセプトバージョン…
  • apiblueprintディレクティブが用意されてる
    • markdownを呼び出す

2014年12月21日日曜日

Android Wearの設定アプリを探す

[AOSP](
https://android.googlesource.com/platform/packages/apps/Settings/+/android-wear-5.0.0_r1)のコードの中にあるSettingsを読んでみたけどもres/values-ja/string.xmlに「ウォッチフェイス」の文字列が無かったりと、Wear用の設定部分っぽいのが無かったので、どこか他に有るんじゃないかと思い探してみた。

logcatでパッケージ名のあたりを付ける

logcatを見ながら設定アプリを起動してみる。
そうすると下のログが出てきたので、パッケージ名はなんとなく分かった。

com.google.android.apps.wearable.settings/com.google.android.clockwork.settings.SettingsActivity

I/ActivityManager﹕ START u0 {act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10000000 cmp=com.google.android.apps.wearable.settings/com.google.android.clockwork.settings.SettingsActivity} from uid 10023 on display 0
1

ちなみに、Handheld(Xperia Z1)で設定アプリを起動した時のログは以下

I/ActivityManager﹕ START u0 {act=android.settings.SETTINGS flg=0x10000000 cmp=com.android.settings/.Settings} from pid 1360

wearとhandheldでパッケージ名が違います。
wearは com. google .android
handheldは com.android

なのでソースはなんか違う所に有るようです。
道理でAOSPに無いわけだ。

Android Wear側のアプリが動いていない状態でデータ同期

http://developer.android.com/samples/DataLayer/index.html

DataLayerのイベントを受け取るには、イベントのリスナを実装したActivityか、WearableListenerServiceを継承したServiceを作ればOK。

リスナを実装したActivityだとActivityが死んだらデータ同期が出来ないので、Handheld側で設定した値をWear側に送るとかがいい感じに出来ない。

WearableListenerServiceを継承したServiceを使うとうまくいく。

2014年12月18日木曜日

Android WearでBluetooth接続でのADBが認証できなくなった

Android Wearを初期化したらWear側のADBを有効化+Bluetooth経由のデバッグを有効化しても繋がらなくなる現象に悩んだのでメモ

症状

普段は以下のコマンドでhandheld側のアプリでホストとターゲットが接続中となる。

$ adb forward tcp:4444 localabstract:/adb-hub
$ adb connect localhost:4444

しかし、Wearを初期化したらあとでは、”adb devices”で確認すると以下な感じになった。(**は環境によって違う)

$ adb devices
List of devices attached
***********     device
localhost:4444  unauthorized

原因

初回接続時にはhandheld側に

「Wearのデバッグを許可しますか?」

といったタイトルのRSAキーのフィンガープリントを登録するダイアログが出ているハズなのだが、初期化前の段階で

「このパソコンからのUSBデバッグを常に許可する」

にチェックを入れてしまっていると、前の情報を覚えているようで全く許可出来る雰囲気が無い。なので、この情報を消してやる必要がある。

復活の呪文

自分は以下の手順で復活出来た。

  1. Android WearのBluetooth経由でのデバッグをOFF
  2. Android Wearの電源を切る
  3. 設定→アプリ→すべて→Google Play開発者サービス→データを全て消去
  4. 念のため、handheld側のAndroid wearアプリを削除→再インストール
  5. Android Wearを再起動
  6. handheldとwearを再接続
  7. 認証画面が来て(゚д゚)ウマー

2014年6月23日月曜日

ケイデンス&スピードセンサーとハートレートセンサーを買った

ロードバイク初めて数ヶ月経つんですが、ローラ台を買って練習をやってたんですが、はじめにつけたスピードセンサーが前輪用で固定ローラー台だと、スピードが分からなかったので、ついでにと、ケイデンスとハートレート(心拍数)が計測したかったのでAmazonさんでぽちっとしました。
せっかくなのでBluetoothでスマホで見れるようにしようかなと考えその辺を選定基準にして探してみました。

はじめは以下のセットで買おうかと思ったのですが、如何せん高い。合計で約1万5千円。ローラ台やらなんやらにすでにつぎ込んでいるので高い。
そこで、ちょっと調べてみたら、以下のセットを発見。
合計で約8千円。上のセットの半額。これはいい。


スマホ側のアプリはRuntastic Road Bikeにした。これはFacebookとの連携ができるので、走った結果とか投稿できるっぽいので自己満だけども、アピールできてよい。

実際に、取り付けて見た感じでは、ケイデンス&スピードセンサーは予備の結束バンドが入っていたりと親切。ただ、ちょっと作りがチープな感じ。外箱は英語やらロシア語、中国語と色々書かれていたけども、マニュアルは日本語だけだった。ささっと10分ほどで取り付け出来る。

ハートレートの方はスイッチもLEDも何も無いので動いているのか全くわからん。実際にスマホ側で拾ってみるまでなーんもわからん。

ロードに取り付けた後にXperia Z1で接続してみようとして気がついたんだけども、Z1はBluetooth SMART(BLE)に対応してないんですよね。
まったくセンサーたちを検知してくれません。仕方がないので、iPhone4sで使うことにします。

iPhone4sのロードバイクへの取り付けは以下のバックを使いました。

Roswheel ロスホイール フレームバッグ 自転車 サイクリング イヤホンホール付 トップチューブバッグ スマートフォン収納可能 スマホ 全3色【Orange-Store】 (ブルー, L) 

こいつがなかなか曲者で、座っている時はいいんですが、ダンシングすると左右に揺れで太ももに当たる。エネループとか突っ込んでおけるので便利なサイズなのですが、ちょっとこれは頂けない。これは買い替えフラグが立っている状態です。
おそらくローラ台に乗っているときは気にならないので、実際に走る時だけ別にするなどの方法を取ろうかなと。

実際に乗ってきた結果がこちら
見事に貧脚っぷりが露呈しております。
もうちょっとこれで遊んでみようかなーと行った感じです。

#以下アフィリエイト用の広告です

-->

2014年4月30日水曜日

Markdonwでbloggerを書く

bloggerのエディタが微妙なのと、Markdonw信者になりつつあるので、その辺環境を揃えてみようかなと。
あと、連休が暇なので、暇つぶし。

chromeアプリで書く方法

とりあえず、chromeアプリで書いてみる方法。StackEditを使う方法。簡単。
ただ、エディタのキーバインドがVimに出来ないので困る。
あと、右上の欄でタイトルを書くんだけど、日本語変換後のエンターで編集確定しちゃうのがちょっとアレ。

http://tizio1976.blogspot.jp/2013/11/chrome-stackedit-markdown-blogger.html

vimで書く方法

やっぱり、vimでしょ。ということで探してみる。

http://rcmdnk.github.io/blog/2013/11/17/computer-vim/
http://blog.mah-lab.com/2011/01/16/vimblogger/

下のリンクがやりたいことが書かれているっぽい。

2013年11月10日日曜日

【解説】センス無い俺がAndroidのホーム画面をアレンジした結果【画像つき】


中学の成績で5段階評価で2をもらうような俺でもいい感じのホーム画面作れたと思うので、まとめてみます。
ホーム画面のアレンジをしたきっかけとしては、メインの携帯をiPhoneからXperia Z1に変えたので、せっかくなので画面を弄くり倒してみようかなと。

途中にも使用したアプリ等のリンクを置いていますが、最後にまとめてリンクを貼っておきます。

壁紙

壁紙はここのをダウンロードし、黒板の中身をGIMPでちゃちゃちゃっと消して使っています。


ホームランチャー

ホームランチャーはApexのフリー版を使用。Novaとも迷ったんですが、Apexは無料で余白の設定やジェスチャーの設定が出来たので、採用しました。
設定は以下の感じ








アイコン

アイコンはHolo Dark Minimalを使用。
ホーム画面にアプリを置いたら、アプリのアイコンを長押しすると以下のような画面が出てくるので、編集を押します。


そしたら、アプリの設定が出るので、アイコンをタップし「アイコンパックから選ぶ」を選びます


そうすると、インストールされているアイコンパックが一覧で表示されるので今回はHolo Dark Minimalを選びます。実は同じ名前で暗い色と明るい色のセットが別々で配布されているので、今回はアイコンが暗い色のセット(中身のアイコンは明るい色)を使用します。


そうすると、たくさんのアイコンが一覧表示されるので、イメージとあったアイコンを選びます。選んだら、元のアプリの設定画面に戻るので、OKを押せば設定完了です。


こんな感じにアイコンを差し替えていき、黒板にあう感じに配置しました。

ウィジェット

お天気ウィジェットはEye in Sky Weatherとを使用しました。
インストールすると4つのウィジェットが使えるのですが、「Eye in Sky Cities」を今回は配置。
設定は以下の感じに



おそらく配置すると、Apexのホーム画面の配置が縦8横8になっているので縮小して表示されてしまいます。

そしたら、ウィジェットを長押しして、リサイズを選択します。


で、横に引き伸ばすと綺麗に表示されます。

これで完成です!


最後に

いい感じに気に入ったホーム画面が作れました。
まだアイコンの色が微妙に文字よりも明るかったり、ウィジェットで表示している情報が少ないような気もしていますので、追々直していこうかなと。

以下に今回使用したアプリ等をまとめておきます。




#以下アフィリエイト用の広告です

-->

2013年8月15日木曜日

node.jsでsocket.io使った時のDebug情報をコンソールに出力しないようにする方法

node.jsでsocket.io使った時にdebug情報がやたらと出てくるので、
出力を止める方法を調べたメモ

こんな感じのコードを
var io = require('socket.io');
var sio = io.listen(httpServer);
こうするだけ。
var io = require('socket.io');
var sio = io.listen(httpServer, {log: false});

#以下アフィリエイト用の広告です

-->

2013年8月12日月曜日

beaglebone+ubuntuでnodeの環境準備メモ

メモ書き
クロス環境を用意するのめんどくさいから全部bone上で操作

コンパイル環境を入れる
sudo apt-get update
sudo apt-get install -y gcc g++ make


node.jsのビルド、インストール、必要そうなライブラリのインストール
mkdir node
cd node
wget http://nodejs.org/dist/v0.10.15/node-v0.10.15.tar.gz
tar xf node-v0.10.15.tar.gz
cd node-v0.10.15
./configure --without-snapshot
make clean all
sudo make install
sudo npm install -g node-dev express

--without-snapshotつけないとセグメンテーションフォルトで落ちる。

#以下アフィリエイト用の広告です

-->

2013年8月1日木曜日

BeagleBoneでsudo



今更ながらですが、BeagleBoneで遊んでます

sudoが使えなくて面倒だったので、Angstromeのopkgで入れようとしたらなんかnot foundって怒られたのでソースから入れた

$ wget http://ftp.sudo.ws/sudo/dist/sudo-1.8.4p4.tar.gz
$ tar xvf sudo-1.8.4p4.tar.gz
$ cd sudo-1.8.4p4
$ ./configure
$ make
$ su
# make install

とりあえず、これでsudoが使えること確認できたのでよしです。 #以下アフィリエイト用の広告です

-->

2013年7月30日火曜日

BeagleBoneでmjpeg-streamerを使う その1

まだ使えていません。
とりあえず、ビルドが通ってmjpeg-streamerが起動するところまでは行ったが、
カメラの映像がブラウザに表示出来ていない。


# opkg install libjpeg-dev imagemagick

diff --git a/Makefile b/Makefile
index 5f32cda..c159222 100644
--- a/Makefile
+++ b/Makefile
@@ -9,8 +9,8 @@

 CC = gcc

-CFLAGS += -O2 -DLINUX -D_GNU_SOURCE -Wall
-#CFLAGS += -O2 -DDEBUG -DLINUX -D_GNU_SOURCE -Wall
+#CFLAGS += -O2 -DLINUX -D_GNU_SOURCE -Wall
+CFLAGS += -O2 -DDEBUG -DLINUX -D_GNU_SOURCE -Wall
 LFLAGS += -lpthread -ldl

 APP_BINARY=mjpg_streamer
diff --git a/plugins/input_gspcav1/spcav4l.h b/plugins/input_gspcav1/spcav4l.h
index 2754ae2..a139b6b 100755
--- a/plugins/input_gspcav1/spcav4l.h
+++ b/plugins/input_gspcav1/spcav4l.h
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -42,6 +43,8 @@
 #include 
 #include 

+#define BASE_VIDIOCPRIVATE BASE_VIDIOC_PRIVATE
+
 /* V4L1 extension API */
 #define VIDEO_PALETTE_JPEG  21
 /* in case default setting */
diff --git a/plugins/input_uvc/v4l2uvc.h b/plugins/input_uvc/v4l2uvc.h
index 2c2868b..e0334f0 100644
--- a/plugins/input_uvc/v4l2uvc.h
+++ b/plugins/input_uvc/v4l2uvc.h
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 

 #include "uvcvideo.h"

#以下アフィリエイト用の広告です

-->

opkgでエラーが出たので対処した

症状
 * parse_from_stream_nomalloc: Missing new line character at end of file!
が出てよくわからん。

結論
nameserverの設定がされていなかった

直し方
/etc/resolve.confにnaveserverを追加する

#以下アフィリエイト用の広告です

-->

2013年6月30日日曜日

iPad 3rd、iPad mini、Nexus7、iPhoneでKindleの比較をしてみた



iPad miniがひょんな事で手に入ったので、ちょっとKindleの見た目がどうかを比較してみました。

表紙

左から、iPad 3rd、iPad mini、Nexus 7、上がiPhone 4Sです。
全部画面輝度を最高にしてます。
絵だとどれも代わり映えはあまりしないかなって感じです。見た目的にはiPad達は背景が白い感じに見えるのですが、Nexus 7は少し黄色味がかった感じ。ただ、Nexus 7だけ見てるのであれば気にならないかな。

白黒のコマ
iPad 3rdとiPad miniで明るさに差が有るように見えるけども、視野角のせいです。
色温度はほとんど同じ。やっぱりNexus 7は少し黄色味がかった感じ。
意外にもiPad 3rdがRetinaなせいなのか、文字がぼんやりして見える。引き伸ばした感じになってるので、元画像の解像度がそこまで高くないのかも。


KindleはiOSでもAndroidでも同期がとれるので、すごく便利と思ったけども、
そもそも本の種類が少なすぎて読みたい本が無いってのが現状。
しばらくは、進撃の巨人と攻殻機動隊ARISEだけになりそうな予感。
個人的には電子書籍端末として使うならNexus 7≧iPad mini>iPad 3rdかなと。
Nexus 7は一番横幅が狭いので、持ちやすい。カバー付けなくてもすべり止めなボディってのもGood。ただ、色が少し黄色味がかって居るのと、画面の非表示エリア(操作ボタン)が気になるかな。それらが気にならないのであれば値段的に見ても電子書籍用に新しく買うならAndroid端末がいいのかも。

#以下アフィリエイト用の広告です

-->

2013年5月19日日曜日

USBに入れたUbuntu 13.04が遅かったのでちょっと対策してみた

安物のUSBだったのが、問題なのかファイルアクセスするとちょくちょく固まってしまうので、ファイルアクセス時間を記録しないようにするのと、Ramdiskを使うように設定を買えた。 あと、chromeのキャッシュもramdisk上に置くように設定変更

 /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
#                
# / was on /dev/sdb5 during installation
UUID=ed0ac91c-c17f-4cd7-a9bb-ebdb735b1496 /               ext4    errors=remount-ro,noatime 0       1
# /dos was on /dev/sdb2 during installation
UUID=B371-17EE  /dos            vfat    utf8,umask=007,gid=46 0       1
/dev/sr0        /media/floppy0  auto    rw,user,noauto,exec,utf8 0       0
tmpfs /tmp tmpfs defaults 0 0

,noatimeがアクセス時間の記録を無効化するオプションで、tmpfsの行がramdiskを作ってくれるオプション。ramdiskのサイズは物理メモリの半分が自動で割り当てられるらしい

次に、chromeのキャッシュの設定

 ~/.xprofile
export XDG_CACHE_HOME="/tmp/.${USER}/cache"
[[ ! 0d "${XDG_CACHE_HOME}" ]] && install -dm0700 "${XDG_CACHE_HOME}"


小手先だけな対策だけども、とりあえず効果はありそうな感じがしてるので、しばらくはこれでいってみる

#以下アフィリエイト用の広告です

-->

2013年4月27日土曜日

Djangoでデータベースの位置を相対パスにする

備忘録

Djangoのチュートリアルを参考にデータベースの設定をしようと思ったら、チュートリアルには絶対パスで指定しろと書かれている。
でも、デフォルト状態のデータベースをバージョン管理したかったので相対パスにする方法を調べた



/settings.pyの初めの方を以下の様に編集(DB名は好きな名前)
from os import path
basepath = path.dirname(__file__)

DATABASE_NAME = path.join(basepath, 'DB名')

DEBUG = True
TEMPLATE_DEBUG = DEBUG

ADMINS = (
    # ('Your Name', 'your_email@example.com'),
)

MANAGERS = ADMINS

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3', # Add 'postgresql_psycopg2', 'mysql', 'sqlite3' or 'oracle'.
        'NAME': DATABASE_NAME,                      # Or path to database file if using sqlite3.
        # The following settings are not used with sqlite3:
        'USER': '',
        'PASSWORD': '',
        'HOST': '',                      # Empty for localhost through domain sockets or '127.0.0.1' for localhost through TCP.
        'PORT': '',                      # Set to empty string for default.
    }
}


#以下アフィリエイト用の広告です

-->