ベイズの公式

ベイズの公式

2015年3月20日金曜日

Swift学習、第一段階は終了

Swift練習問題を完了

Objective-Cで自作したフレームワークを一つと、サンプルアプリを2つ Swiftでの書きなおし作業が終わった。これで大概のSwiftの言語機能を使ってみたことになると思う。おおよそ下記の要素について理解できた。(文法の暗記はしてないが、マニュアルみれば即対応できるレベル)


  • class とstruct
  • イニシャライザ、デイニシャライザ
  • 型推論
  • var と let
  • optional変数、メソッド
  • プロパティ、計算プロパティ
  • subscript
  • Array, Dictionary
  • protocol
  • generics, typealias
  • enum の特徴
  • switch 文とレンジ表現
  • dynamicType, Class.self
  • 例外がないこと
  • @objc
  • 無名関数、closure
  • extension
  • Equatable, Comparable
  • Xcode6 の cocoa framework 作成機能
  • 名前空間

Swiftの印象

トータルな印象は良い。これからは原則Swiftで開発しようと思う。
基本的なコーディングの気分はJavaに近く、Javaの欠点を上手く取り去って、C++的な気持ちよさや最近のLL言語っぽい簡潔さが取り入れられていると感じた。

例外機構は今後取り入れられるのだろうか?いらない気もするけど。

2015年3月7日土曜日

Swift とトップダウン勉強法

訳あって Swift プログラミングを勉強しはじめた。

Swift は Apple が昨年発表した新しいプログラミング言語である。型推論や関数型プログラミング、言語標準に組み込まれたコンテナや辞書の導入など、最新のプログラミング言語の進化潮流を取り入れた言語である。

勉強法はいつものとおりトップダウン式である。既に出来上がっている知識体系を学ぶときは、これが一番速い習得方法だ。教科書と問題集を用意したら、教科書の目次だけを頭にいれ、いきなり問題集にとりかかる。これがトップダウン式。

プログラミング言語のトップダウン式勉強の場合は、教科書=言語仕様書、問題集=実際のプログラム題材となる。

Swiftの場合も、Appleの言語仕様書は目次をざっと目に通す程度で留めておき、とにかく以前Objective-Cで書いたコードを移植してみている所である。

コード題材は自分の慣れ親しんだ定番を作っておくとよい。私の尊敬する先輩の方々は、こうした題材を用意している人が多かった。新しい言語や新しいOSに出会ったら、かならずその題材をそこで実装してみるのである。それが最も速く、かつ実感を伴って新しいものを理解できるからである。

例えば、ある先輩はいつもテキストエディタを作っていた。また、別の先輩はいつも自作の小型言語のインタプリタを書いていた。つまり、新しい環境で使う自分の仕事道具を自分で作るのである。これは素晴らしい方法だ。勉強にもなり、実用ツールが手に入るという一石二鳥。しかも、カッコイイw。

2015年2月19日木曜日

スライド:データ中心時代を生き抜くエンジニアに知ってほしい10?のこと

昨日、豆蔵グループの仲間、フォスターネットさんが主催のセミナーで講演しました。
講演資料を貼っておきます。


恥ずかしいことに、終了時間を勘違いして、最後まで話せなかったという・・・
でも、終わってから何人かの方に『面白かった』と言っていただけたので良かったです。

宇宙船の話からマーケティングの話につなげるところがハイライト。ここは結構悩んで内容を作りました。

2015年2月11日水曜日

ドキュメントに関する記事を寄稿しました(2)

こちらに連載記事の2回目を公開していただいた。

おかげさまで、SNSなどでの言及やブックマークしていただいた数も多く、
たくさんの人に読んでいただけているようだ。ありがとうございます。

はっきり言って、これは驚きだ。仕様書の書き方という『地味な』
テーマの記事にこれだけ関心を持っている人が多いとは。
やはりこういった事で悩んでいる人も多いのだろうか。
少しでも読者の役にたてば嬉しいのだが。

もともと他の方(Joel氏)が作ったものを多少リメイクしただけの記事なので、
私としては申し訳ない気持ちもあるが、ともかく役に立つ情報が広まることは
悪いことではないので、良しとしよう。

オープンストリームの関係各位、ITmediaの皆様ご協力ありがとうございます。

2015年1月21日水曜日

ipython 環境を作成

 個人的課題として、自宅、オフィス、いろいろな出張先などから、いつも同じに使えるデータ解析環境が欲しいと思っていた。ノートPCでも良いかなと思ったが、いろいろなデータを持ち運ぶのはリスクもある。最近、当社のO君に触発されて ipython が面白いなと感じていた所だったので、物は試し、AWS上に環境を構築してみた。手順は以下の通り。

ipython (with notebook) をAWS EC2/AMI Linux 上にインストールする手順

 ipython notebook は、ipythonの目玉機能の一つで、自らWebサーバとなり、ブラウザ上からの python コード作成・実行や可視化が可能となる機能だ。クラウド上に環境を作っておけば、ブラウザでどこからでもアクセスして作業できる。コード補完機能なども強力なのでなかなか便利である。しばらく使って評価してみたい。

ipython notebook のスクリーンショット

2014年12月18日木曜日

ドキュメントに関する記事を寄稿しました

もう少し頻繁にブログを更新したいと思いつつ、なかなか上手くいかないものだ。
FacebookやTwitterがあるので、小ネタはそっちに吸い取られるのが大きい。

さて本題。
会社のお仕事でWeb媒体に連載記事を書くことになった。
与えられたお題は『プロジェクト成功確率向上の近道とは?』とうもの。
これは結構難しいというか、自分としては綺麗に答をだせないテーマなので、
いろいろ悩みつつ決めた内容のものである。そのあたり、汲み取りつつ読んでいただけるとありがたい。

ドキュメントは最強のコミュニケーションツールである

タイトルがやや大げさである点は認識している。
ただし、書いた内容は嘘偽りのない自分の本音である。
ある程度のレベルを突破すれば、もはや技術は成功とはあまり関係がなくなってくる。
というか、いくら高いプログラミング技術などがあっても解決できない問題にぶちあたる。それがコミュニケーション問題である。合意形成問題といっても良い。

ソフトウェアのような複雑な構成物について、イメージや感覚、ましてや『あ・うん』の呼吸などでコミュニケーションしようとするのは間違いだと思う。キチンと言葉に定着して、お互いに確認することが必要なのである。

未来のいつかに、現在のようなドキュメントが必要なくなる時が来るだろうか。
一つの可能性は、脳にセンサーを取り付けて、考えた概念を直接取り出せるようにすることだ。これなら、自然言語という貧弱なメディアで概念をシリアライズしながらアウトプットする必要もなくなる。

ただし、考えている途中で邪念が湧いたらどうしよう?