5にストラップを付けて使う。一部私用で使ってみる。手を滑らせるようにして使えば5インチ端末も使い易い。6にストラップを付けて同じように使う。Watchが出ればiPhoneなんて体の何処かにつけておけばw。6の解像度がフルHDに上がって5インチになれば。plusをスルーすべきかも。ジャンパラ等で売っている中古plusも大分安くなってきたな。買おうかなという訳で目的達成について、自分でも整理できてない。要求の獲得は難しいな。6を買ってよかったが未だどうか悩んでいる。Tumblr広告を非表示にするコメントを書くもっと読む2014-11-24iPhone6とアルミフレーム購入検討〜要求獲得の難しさ。iPhone6をまだ買っていない。理由はアルミフレームが出揃っていないからだ。幾つ出ているがネットで眺めてもいいか悪いかわからない(以前買って失敗したし)。店に出向いて眺めると質感がいいか、かっこいいか?悪いかがある程度わかる。実物に付けられているわけではないので、本当にかっこいいかどうかが分からない。ストラップ穴がない場合、付けられるかどうかが分からない。したフレームを見つけるのは難しい。自由度の高いアプリではなおさらだ。UI設計になるだろう。17:02iPhone6とアルミフレーム購入検討〜要求獲得の難しさ。Tumblr広告を非表示にするコメントを書くもっと読む2014-11-22Swiftにみるモデル駆動開発の将来UMLツールや一頃流行った?MDAという技術にモデルからコードを自動生成というのがある。効率云々はともかく、オブジェクト指向開発に習熟していくと、クラス構成とコーディングを自由に行き来したくなってくる。上記のモデル駆動ツールであるが、結局は流行らなかった。理由は色々あると思う。大規模開発を想定して敷居が高い、値段が高い、オブジェクト指向技術を使いこなせるプログラマーがいない、操作性が悪い等等。私自身はプログラミング言語がそれを全面支援していない事。開発環境もなんか堅苦しく、遊び心が足らなかった事というのが原因だと思う。話は展開するが、こういう点でAppleがSwiftを打ち出したのは何か意図があってと思うし、そういう意味で期待もしている。解析が用意な静的言語を採用したのはそういう意味からだろう。Playgroundの発展系でコーディングするとクラス図が自動的に表示されるとか、オブジェクト図を表現するようなデバッガが出てくる事を期待している。アップルと合併前のNeXTSTEPでは当時では画期的なモデリングツールやGUIビルダーを世に広めて、その後のRADプログラミングのトレンドを作ったわけだし。Tumblr広告を非表示にするコメントを書くもっと読む2014-11-22オブジェクト指向のデータ構造的意味論。オブジェクト指向(というか抽象データプログラミング。言い方はしないのでオブジェクト指向)はクラス(ネーティブ型もここではクラス)を秩序を保ってまとめ上げて新しいクラスを作り上げるにすぎない。それらがいろいろ再帰的に合成されて、基盤ライブラリ、UIフレームワーク、モデル、サービス、UIコントローラー、ビュー、アプリと合成されて、ある種の複合データ構造を形成していく。会社組織のよう巨大化していく。いうわけでオブジェクト指向設計とは複合的なデータ構造を作る作業であり、ドメインモデルや問題領域の基本的な秩序を与え、アーキテクチャは駆動環境の基本的な秩序を与える。したがって、データ構造の一部に手を入れると意識を保って作業しなければ、オブジェクト間の連携は壊れ、シスエムは崩壊する。19:42オブジェクト指向のデータ構造的意味論。Tumblr広告を非表示にするコメントを書くもっと読む2014-11-16スモールオブジェクトプログラミングについて〜クラスはより小さくするはじめにSmalltalkerのケントベックやThoughtWorksの中の人が暗に提唱し、最近いろんな識者がネットや本で語っている*1*2、バリューオブジェクト、小さな部品、小さなクラス、小粒クラス、粒度の小さいクラス、スモールオブジェクトプログラミングと言われている、ストイックなまでに小さくしたクラスを使った開発手法について長所/短所を補足、記述しました。部分的な問題に分解できる。割り込みに強い(仕事中の電話から、数ヵ月毎の保守まで)。要求仕様を表現しやすい。フレームワークと違って、作ったクラスを他のプロジェクトに再利用しやすい。モデリング作業〜コーディング作業の行き来がしやすい。オブジェクト間の関連やメッセージパッシングを検討する作業にすり替わる。クラス間の依存が減る?ソースコードが簡素になる。オブジェクト指向に慣れた人にとっては読みやすい。いうかこの実現方法以外にありえない。処理のコーディングレイアウト、コメントとかどうでもよくなる。そんなものやっている暇があれば即クラスに分割を検討。仕様書からコードが自動生成できる?クラスがする仕事が明確になる。急に質問されてもパッと答えれるぐらいに。クラスの不変性を表現しやすい。同様にクラスの状態が減ってわかりやすくなる。XPライクなアジャイル開発に強い(1時間置きに客やPMが話しかけて、ちょこまか小さい方針がかわったり、要求仕様を探るためのライブコーディングするような場合)。短所O/Rマッパとの相性が悪い。必要(=オブジェクト指向分析/設計能力)。クラス分割するにはオブジェクト設計へのかなりな習熟が必要(クラスの命名やメソッドも同様)。ソースコードが自然とオブジェクト間のメッセージパッシング表現する事になるので、オブジェクト指向に慣れていない人にとってはソースが読みづらい?パフォーマンスやメモリ使用に影響与える?スモールオブジェクトプログラミングを禁止されると退職を考えてしまうw。Tumblr広告を非表示にするコメントを書くもっと読む2014-11-15条件分岐とメッセージパッシングの差異について。移譲型制御についての考察の続きオブジェクト指向プログラミングはオブジェクト間の通信によって世界が構築される。上から降ってくる仕事は、小さなタスクに分割されてどんどん包含されているオブジェクトに移譲される。If文の使用はオブジェクト指向プログラミングで良くないとされている。現実にはif文はそれなりに使われている。純粋型オブジェクト言語の代表であるSmalltalkでさえも*1。オブジェクトにとってifとは何かという問いに対しては、私なりの現時点の回答は以下の通り。オブジェクトの判断(意思決定)(実作業系)下に位置するオブジェクトが行うアルゴリズム(業務)前者については、管理する以上、意思決定は避けらない。良い上司と部下の関係と同様に重要な部分だけ判断するにとどめるのが望ましいだろう。ソース可読性とクラスの再利用の観点から。後者については、下位のオブジェクトについては、どうしても手続き的プログラミングにならざる得ないという事だろう。考えれば見れば当たり前で、下位のオブジェクトが関わるのはバリューオブジェクト、つまり意志を持たないオブジェクトと関わるようになってくるからだと思う。11:44条件分岐とメッセージパッシングの差異について。Tumblr広告を非表示にするコメントを書くもっと読む2014-11-12クラス、パブリックメソッドのコメントを書く基準について調べた。いろんなOSSを調べた結果です。・アプリの場合はクラス記述ぐらいしか書かない。使い方の自由度が限定されているので。・世に公開された汎用的なフレームワークはコメントをきっちり書く。使い方の自由度が高いし、公開されているメソッドが多い、内部状態は複雑だったりするし、後でドキュメント生成して参照したりするので。・アプリ内でのみ使用するフレームワークについては場合による。多く使われるクラスはコメントを書かかれる傾向がある。コメントを書く書かない基準について、頭の中が整理できたかな。23:54クラス、パブリックメソッドのコメントを書く基準について調べた。ソフトウェア設計と音楽を中心に書きます。6を買ってよかったが未だどうか悩んでいる。iPhone6とアルミフレーム購入検討〜要求獲得の難しさ。Swiftにみるモデル駆動開発の将来オブジェクト指向のデータ構造的意味論。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。