MacBook Pro 2014 midを買う?
きっかけ
- MacBook Pro 15inch 2011 early が亡くなられた
うちの子もこの病にかかったっぽい。 / “ディスプレイ表示が乱れる。(MacBook Pro early 2011) | Apple サポートコミュニティ” http://t.co/1TfEsebSIs
— atotto (@atotto) 2014, 7月 26
- そしたらちょっと新しいMacBook Proがリリースされた!
おや / 他2コメント http://t.co/0sW5990CSm “アップル、MacBook Pro Retinaを価格据え置きでCPU底上げ、メモリ倍増 ~非Retinaモデルは値下げ - PC Watch” http://t.co/Ub3RV9nOj7
— atotto (@atotto) 2014, 7月 29
なんのお告げか。
RetinaなMacBook Proを買うにあたっての懸念点
- 非光沢ディスプレイを選択できない
- 自分でパーツの交換ができない(ストレージやメモリなど)
- キーボードのストロークが薄っぺらい
などが気になってる。
MacBook Airの13inch買うならPro 13inchかなと思う。厚さも重さもそんなに変わらないし。 Airを買うなら11inchってことになるけど、ディスプレイの比率が横長なのが引っかかるのでパス。もしうわさの12inch MacBook Airが出たら欲しい!けど、まだなので出たときに考えることにする。
だけどそもそも。
いまのマシンをお金をかけずに延命できれば一番いいんだけど…。
そして自分でなんとかするには、ロジックボードを焼き直せばなおせるかもしれないらしいw / “MacBook Proがゾンビ化。オーブンで焼いたら復活し、7ヶ月以上も動作してる” http://t.co/WX7L7Fy2Ia
— atotto (@atotto) 2014, 7月 26
と。ひとまずメモ。
■
golangのテンプレート(例えば text/template)では、FuncMapを使うことで好きな関数を実行できます。ので練習がてら簡単な計算機を作ってみます:
package example_test import ( "bytes" "fmt" "log" "text/template" ) func ExampleTemplateCalculator() { funcMap := template.FuncMap{ "add": func(a, b int) int { return a + b }, "sub": func(a, b int) int { return a - b }, "mul": func(a, b int) int { return a * b }, "div": func(a, b int) int { return a / b }, } var buf bytes.Buffer tp := template.Must(template.New("calculator").Funcs(funcMap).Parse("{{mul (div (sub 3 (add 1 4)) 2) -10}}")) err := tp.Execute(&buf, nil) if err != nil { log.Fatal(err) } fmt.Println(buf.String()) // Output: // 10 }
playgroundはこちら: http://play.golang.org/p/iYlS-L4qQZ
読んだ: Lean UX
先日、読書会で読んできました。
Lean UX ―リーン思考によるユーザエクスペリエンス・デザイン (THE LEAN SERIES)
- 作者: ジェフ・ゴーセルフ,ジョシュ・セイデン,エリック・リース,坂田一倫(監訳),児島修
- 出版社/メーカー: オライリージャパン
- 発売日: 2014/01/22
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (2件) を見る
この本をざっくりと説明すると、UIデザイナ+エンジニア達がアジャイル開発をリーン・スタートアップの要領でプロダクト開発をすすめるために必要なこと・やることをおおまかにまとめた本、です。 Lean UXというタイトルからするとユーザーエクスペリエンスをリーンを通じてどうデザインするか、ということを想像するかもしれませんが、UXのtipsなどはなく、純粋にリーンの話です。
以下、感想:
すでにリーンスタートアップの本やアジャイルやUIに関する本を読んでいることもあり、すんなりと読めたように思います。
薄い本ですので、具体的な例が少なく、実践するにはおそらく情報が足りません。別途:
- Running Lean ―実践リーンスタートアップ (THE LEAN SERIES)
- About Face 3 インタラクションデザインの極意
- インタフェースデザインの心理学 ―ウェブやアプリに新たな視点をもたらす100の指針
- アジャイルサムライ――達人開発者への道
などを読むことをオススメします。
本文には、突然MVPやペルソナの話が出てきますので、そのあたりの知識を前提にしているようにも感じました。全体で150ページほどですので、どんな開発スタイルでどう顧客と向きあってプロダクトデザインを進めればよいのかということを知るには丁度良い本だと思います。
組織化された開発では、UIを設計する人、UIのデザインをする人、UIを実装する人、、などがレイヤー分けされていたりします。そういった退屈な開発を壊すために、この本の内容を実践できればいいと思います。
Running Lean ―実践リーンスタートアップ (THE LEAN SERIES)
- 作者: アッシュ・マウリャ,渡辺千賀,エリック・リース,角征典
- 出版社/メーカー: オライリージャパン
- 発売日: 2012/12/21
- メディア: 単行本(ソフトカバー)
- 購入: 3人 クリック: 14回
- この商品を含むブログ (18件) を見る
- 作者: Alan Cooper,Robert Reimann,David Cronin,長尾高弘
- 出版社/メーカー: アスキー・メディアワークス
- 発売日: 2008/07/22
- メディア: 大型本
- 購入: 9人 クリック: 208回
- この商品を含むブログ (26件) を見る
インタフェースデザインの心理学 ―ウェブやアプリに新たな視点をもたらす100の指針
- 作者: Susan Weinschenk,武舎広幸,武舎るみ,阿部和也
- 出版社/メーカー: オライリージャパン
- 発売日: 2012/07/14
- メディア: 大型本
- 購入: 36人 クリック: 751回
- この商品を含むブログ (28件) を見る
- 作者: Jonathan Rasmusson
- 出版社/メーカー: オーム社
- 発売日: 2014/06/25
- メディア: Kindle版
- この商品を含むブログ (1件) を見る
gotypeコマンドでgolangのastの結果を視覚化する
qiitaより転載
GolangのASTを可視化するツールを作った でastのステキな可視化がされていて出番は少ないかもしれませんが、gotypeコマンドでもastの結果を可視化できます。
これは何?
Go言語のソースコードを解析する際の補助的なツールです。 astパッケージを使う際のデバッグなどに役に立つと思います。
インストール
導入は:
$ go get code.google.com/p/go.tools/cmd/gotype
でok。
簡単な使い方:
例えば:
package main import ( "fmt" ) func main() { fmt.Println("Hello, 世界") }
を入れてみると以下のようになります:
$ gotype -ast main.go 0 *ast.File { 1 . Package: main.go:1:1 2 . Name: *ast.Ident { 3 . . NamePos: main.go:1:9 4 . . Name: "main" 5 . } 6 . Decls: []ast.Decl (len = 2) { 7 . . 0: *ast.GenDecl { 8 . . . TokPos: main.go:3:1 9 . . . Tok: import 10 . . . Lparen: main.go:3:8 11 . . . Specs: []ast.Spec (len = 1) { 12 . . . . 0: *ast.ImportSpec { 13 . . . . . Path: *ast.BasicLit { 14 . . . . . . ValuePos: main.go:4:2 15 . . . . . . Kind: STRING 16 . . . . . . Value: "\"fmt\"" 17 . . . . . } 18 . . . . . EndPos: - 19 . . . . } 20 . . . } 21 . . . Rparen: main.go:5:1 22 . . } 23 . . 1: *ast.FuncDecl { 24 . . . Name: *ast.Ident { 25 . . . . NamePos: main.go:7:6 26 . . . . Name: "main" 27 . . . . Obj: *ast.Object { 28 . . . . . Kind: func 29 . . . . . Name: "main" 30 . . . . . Decl: *(obj @ 23) 31 . . . . } 32 . . . } 33 . . . Type: *ast.FuncType { 34 . . . . Func: main.go:7:1 35 . . . . Params: *ast.FieldList { 36 . . . . . Opening: main.go:7:10 37 . . . . . Closing: main.go:7:11 38 . . . . } 39 . . . } 40 . . . Body: *ast.BlockStmt { 41 . . . . Lbrace: main.go:7:13 42 . . . . List: []ast.Stmt (len = 1) { 43 . . . . . 0: *ast.ExprStmt { 44 . . . . . . X: *ast.CallExpr { 45 . . . . . . . Fun: *ast.SelectorExpr { 46 . . . . . . . . X: *ast.Ident { 47 . . . . . . . . . NamePos: main.go:8:2 48 . . . . . . . . . Name: "fmt" 49 . . . . . . . . } 50 . . . . . . . . Sel: *ast.Ident { 51 . . . . . . . . . NamePos: main.go:8:6 52 . . . . . . . . . Name: "Println" 53 . . . . . . . . } 54 . . . . . . . } 55 . . . . . . . Lparen: main.go:8:13 56 . . . . . . . Args: []ast.Expr (len = 1) { 57 . . . . . . . . 0: *ast.BasicLit { 58 . . . . . . . . . ValuePos: main.go:8:14 59 . . . . . . . . . Kind: STRING 60 . . . . . . . . . Value: "\"Hello, 世界\"" 61 . . . . . . . . } 62 . . . . . . . } 63 . . . . . . . Ellipsis: - 64 . . . . . . . Rparen: main.go:8:29 65 . . . . . . } 66 . . . . . } 67 . . . . } 68 . . . . Rbrace: main.go:9:1 69 . . . } 70 . . } 71 . } 72 . Scope: *ast.Scope { 73 . . Objects: map[string]*ast.Object (len = 1) { 74 . . . "main": *(obj @ 27) 75 . . } 76 . } 77 . Imports: []*ast.ImportSpec (len = 1) { 78 . . 0: *(obj @ 12) 79 . } 80 . Unresolved: []*ast.Ident (len = 1) { 81 . . 0: *(obj @ 46) 82 . } 83 }
-comment
を合わせて入れればコメント行も解析します。
godocはこちら gotype
Book「APIデザインの極意」
APIデザインの極意 を、この本の訳者の @yoshiki_shibata さんがレビューを募集していたので応募してみました。
インプレスジャパン様よりAPIデザインの極意届きました。ありがとうございます! @yoshiki_shibata http://t.co/JGWLaQlFkO
— atotto (@atotto) 2014, 5月 17
手にとって中身をパラパラとみてみると、文字がぎっしり。本はEffective Javaより多少分厚いくらいですが、中の情報量がもの凄いです。このレビューを出すのが遅くなってしまった理由でもあります。
中には、APIをデザインする上で、何を考え、どうしておくべきか、どうしてこうするべきか、するとどうなるのか、なにに失敗したのかがしっかりと書かれています。コードはそれほど多くありません(最後は除く)が、Javaの知識があると背景をつかみやすいと思います。説明はNetBeansの開発経験などを元にした内容で書かれていますが、他に適用できる話が多いです。全てを読むには根気が要ると思いますので、何人か集めて読書会をするのもいいと思います。
簡単に中を紹介すると、第2部では、Effective Javaに続くような話があり、Effective Javaを読んだ方は是非読んでおくことをおすすめします。 第3部では、はじめの13章で軽く息抜きをしてから、APIを公開、維持する際の話がメインになります。APIは公開以前と公開以降では全く異なる性質を持つようになります。
以下、気になった所のメモを少し:
- 無知な利用が成功するためには、 APIがライブラリの本質的な真意をきちんと反映していることが重要。2章より。
- APIは自己文書化されている必要があり、つまりドキュメントが無くても使えるようにしておく必要がある。2章より。
- APIは公開するものが少ないほどよい。ユースケースに確信が持てないときは公開しない。5章より。
- 単一のAPIで構成されるライブラリはほとんどない。APIが対象としている複数の目的と複数のグループが存在する。ユーザの必要性に合わせてAPIを構成すべし。8章より。
- テスト容易性を考えずにフレームワークを作成することは、開発者を不快にさせる。9章より。
- API設計に問題がなく期待通りうまく運用されていれば「何も」起きない。「何もない」ことが大きな成功であることを示すことは難しい。14章より。
昨今APIをめぐるこんなトラブルもあり、今後のAPI設計の方向性が心配ですが、良いインターフェースの定義は広く使われるようになって欲しいですね。日本語で読めるようになったこの本でAPI設計に関する先人の知恵を読んでおくことをおすすめします!
- 原著:Practical API Design: Confessions of a Java Framework Architect
- 柴田さんのblog :柴田さん翻訳ありがとうございます!
APIデザインの極意 Java/NetBeansアーキテクト探究ノート
- 作者: Jaroslav Tulach,柴田芳樹
- 出版社/メーカー: インプレスジャパン
- 発売日: 2014/05/23
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (1件) を見る
EFFECTIVE JAVA 第2版 (The Java Series)
- 作者: Joshua Bloch,柴田芳樹
- 出版社/メーカー: 丸善出版
- 発売日: 2014/03/11
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (4件) を見る
Apple's SSL/TLS bugの件 #golang
golangだとそもそも括弧強要されるし、gofmtでインデントが強制されるのでわりとすぐに気づくのかもと思ったのでメモ。
そもそもエラーになる:
package main import "fmt" func main() { var err error = nil if err != nil goto fail goto fail fmt.Println("Hello, playground") fail: fmt.Println("Hello, fail") }
http://play.golang.org/p/lcgZDh-ji4
修正&gofmtでこうなる:
package main import "fmt" func main() { var err error = nil if err != nil { goto fail } goto fail fmt.Println("Hello, playground") fail: fmt.Println("Hello, fail") }
http://play.golang.org/p/hinPttq13L
気づくかな。
goto文をつかうこと自体は悪く無いと思う。
リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)
- 作者: Dustin Boswell,Trevor Foucher,須藤功平,角征典
- 出版社/メーカー: オライリージャパン
- 発売日: 2012/06/23
- メディア: 単行本(ソフトカバー)
- 購入: 68人 クリック: 1,802回
- この商品を含むブログ (111件) を見る
- 作者: スティーブマコネル,Steve McConnell,クイープ
- 出版社/メーカー: 日経BP社
- 発売日: 2005/03/26
- メディア: 単行本
- 購入: 44人 クリック: 1,166回
- この商品を含むブログ (284件) を見る
- 作者: スティーブマコネル,Steve McConnell,クイープ
- 出版社/メーカー: 日経BP社
- 発売日: 2005/03/26
- メディア: 単行本
- 購入: 16人 クリック: 193回
- この商品を含むブログ (160件) を見る
デブサミ2014へ行ってきた #devsumi
devsumi 2014
デブサミ2014を見てきたのでメモ。 公式のまとめはこちら: デブサミ2014 講演関連資料まとめ
【13-A-1】クラウドがもたらした多様な破壊と創造(新野淳一/玉川憲/佐俣奈緒子/仲暁子/長谷川秀樹/三村真宗/吉田浩一郎/大石良)
クラウド:
- すぐ、リソース無限、安い、どこでも、自由。
- 個人の成長の場になってる(サーバ、ネットワーク、仮想化、ストレージ、CI、Agile、コミュニティ、勉強会、etc) 会社内だけで最新の知識を得るのはムズカシイ
流行りの言葉:
- DevOps
- ビッグデータ
印象に残ったモノ:
感想:
10年後も大衆の身の回りにあるもの・ことはなんだろう。
Coineyの市場の調査が徹底的になされていて素直に感心してしまった(当たり前なのだろうけど。)。
【13-A-5】成功と失敗の狭間に横たわる2つのマネジメント(中村洋〔DevLOVE関西〕)
slide: http://www.slideshare.net/YohNakamura/developerssummit2014yohhatu
2つのマネジメント:
期待マネジメント
- 話しあう
- 相手に期待していることは?
- 相手から期待されていることは?
- お互いの期待を表明して擦り合わせる
モチベーションマネジメント
- モチベーション:乱高下がある
- 自分で管理する
- 調子を上げるスイッチはなにか
- 共感できてるか
- サーバントリーダーシップ
- 成功体験を増やす
【13-D-6】快適さはWebサービスの生命線!Webアプリのパフォーマンスを最高にするために心がけること(新村信〔アカマイ・テクノロジーズ〕)
- akamaiでインターネットトラフィックの15〜30%を仕切っている
- 2013のトラフィックの最大瞬間風速は21.6Tbps
- コンテンツの転送に時間がかかるとユーザをロストする
- Twitter Bootstrapなどにみるレスポンシブ・ウェブデザインでは、必要以上のコンテンツをクライアントへ送信している
- 各サーバのコンテンツは細々としたチューニングをしていない(する余裕が無い)
- コンテンツの転送をアカマイサーバで高速化するしくみ:
- HTMLを先読みし、コンテンツを先にキャッシュしてクライアントへ送りつける
- 架空のサイトをつくり、クライアントにそこのコンテンツを取りに行かせる(クライアントの同時コネクション数を増やすため)
- 動的に画像の品質を変更する
- 都内、日本国内で使うネットワークはそんなに遅くない
感想:
高速化のしくみは自分が予想していたより派手なやり方をしていて、これって開発している時に予期せぬ動きをしてハマってしまうのではないかと思ってしまった。自分の知識が足りないからそう思うだけで、おそらくそんなことはないのだろう。
【14-A-1】Webの現在過去未来(竹迫良範〔サイボウズ・ラボ〕/和田裕介/宮川達彦)
- IDのネームスペースの問題
- 同じアカウントを他のサービスでも利用したい
- e-mailの失効問題
- e-mail以外での本人確認手段が必要
- OpenID
- プロトコルはしっかり残っていて、知らず知らずのうちにバックグラウンドで使われていることが多い
- Oauth
- IdentificationとAuthorize
- MobileWeb
- Webからネイティブへの流れ
- はじめはネイティブ(iOSなど)の開発者が少なかったからWebだった
- 今はネイティブのメリットを活かせる
- ユーザもネイティブアプリの方を使うみたい
- Webだからできないということもない
- Amazon、iOS
- ユーザがお金を払うしくみ、土壌がある
- 電子書籍
- メールマガジン
- メールにお金を払うのは日本独特
- メールはユニバーサルに使える
- 多くの人が使える
- 夜間飛行にみるあたらしいメールマガジンもでている
- Podcast
- その他
感想:
インターネット上のID(アカウント)はIDなのにIDじゃないっていうのはずっと気になっているけど、なかなかむずかしい問題。 モバイルについては、1、2年前まではHTML5の登場でネイティブよりWebアプリだって言われていたような気がするが、ここでの話はネイティブアプリが有利だよという話で、今となってはなるほどそうかという感じだった。
電子書籍は、せっかくデータで提供できるのに更新しにくいとかそういう話があって残念な感じがしてた。話の中にでてきたgithubから出版までのパイプラインがしっかりできれば個人出版も生きやすくなりそう。
Rebuild.fm Podcastの中の人、宮川さん(@miyagawa)を生で見ることができたので満足です。
【14-C-4】DeNAにおけるゲーム以外の新規事業の立ち上げ方(沖津貴智〔ディー・エヌ・エー〕)
- Scrum
- はじめは忠実に(アナログで)
- 各自が考えて行動できるように
- 開発に対して庶務的なサポータがいる
- 短い単位(日)でのプランニング、振り返り
- リーン
- 検証
- 使う機能、使わない機能の判断
- 全員が各リポジトリを共有している
- 非エンジニアでもgithub&PullRequest
- 対象機種のカバー率よりスピード感
感想:
非エンジニア(デザイナ)もプルリクできるのはすてき。
【14-C-5】モーションセンサーの現状と2014年の予測(中村薫〔Natural Software〕)
slide: http://www.slideshare.net/kaorun55/devicelove
- 3D・モーションセンサ
- 超音波、空気砲で何も無いところに触感を得る
- RICOH THETA + Oculus Riftで場の提供
感想:
THETAとLeapMotionは持ってて遊んではいるけどもなかなか時間を投資できてない今日このごろ。 空気砲を使って感覚を与えるというアイディアは素直におもしろいと感じた。
【14-D-5】iOSアプリケーションの継続的デリバリー~エンタープライズ品質のiOSアプリケーションを目指して~(梅原直樹〔リコー〕)
slide: http://www.slideshare.net/numeha/ios-31199969
となりのセッションを見に行ったので、こちらは後日スライドを拝見させていただきました。
- 価値あるソフトウェアを早く継続的にデリバリーし、お客様を満足させなくてはならない
- プロジェクト開始時にリリースまでのパイプラインを作る
- リリースのリズムを作る
感想:
うちのチームでもこんなふうにできたらいいなぁと。しないとね。
【14-B-6】ソフトウェア工学からコンピューターサイエンスへ - 今後のシステムアーキテクチャーに必要な技術的切り口とその裏側(萩原正義〔日本マイクロソフト〕)
slide: http://www.slideshare.net/MasayoshiHagiwara/dev-summit20140214
感想:
ソフトウェア工学は社会人になってから重要視するようになったが、コンピュータサイエンスもちゃんとやっていかないと生き残れそうにないな、と。
全体
雪でどうなることかと思いましたが、時間の短縮のおかげで最後まで参加できてよかったです。
タイトルと内容があってない講演がちらほらあったように思いました。
デブサミ関係者の方、ありがとうございました。