開発でLinuxを使うのだが、始めてなので何を勉強すれば良いのかわからない、というソフトウェアエンジニアも多いことだろう。
そんな方々におすすめなのが、LPI-JAPANが公開しているLinux標準教科書だ。
無料とは思えないほど、内容が充実している。
一通り読めば、開発用のLinxuマシンを一人で管理できるようになるだろう。
実際、この教科書を使って勉強した3年目のソフトウェアエンジニアは、半年たった今では、RedhatマシンとSolarisマシンを管理できるようになっている。
★WOZ★
| 固定リンク
| コメント (0)
| トラックバック (0)
Enterprise ArchitectというUMLモデリングツールがある。
このツールは、UMLエディタとして使いやすいだけではなく、UMLモデルから実装言語（C、C++、C#、Java、Pythonその他多数）のソースコードを生成する機能や、実装言語のソースコードからUMLモデルを生成する機能（リバースエンジニアリング機能）が充実している。
とりわけ、リバースエンジニアリング機能は優れもので、ソースコードからクラス図を自動生成できるのはもちろん、ソフトウェアの動きを記録して、シーケンス図を自動生成することもできる。
このシーケンス図の自動生成機能は、ソフトウェアの動きが設計通りかどうかを、プログラマと設計者が検証するのに効果的だ。
また、リバースエンジニアリング機能で生成したクラス図やシーケンス図を設計書に反映させることにより、設計書の作成コストを大幅に削減できるとともに、設計書とソースコードの同期という難しい課題を解決することもできる。
しかも、一本数万円と、この種のソフトウェアとしては非常に安価なため、開発チームでまとめ買いすることも容易だ。
なお、Enterprise Architectは日本ではスパークシステムズが販売している。また入門書も出版されており、学習も容易だ。
★WOZ★
 |
 |
UMLモデリングツール Enterprise Architect 入門
著者：河野岳史/杉本美弥子 |
 |
UMLモデリングツールEnterprise Architect入門 |
| 固定リンク
| コメント (0)
| トラックバック (0)
新卒ソフトウェアエンジニアが知っておきたい、ソフトウェア工学の原則に「D.R.Y原則」と「OCP」がある。
D.R.Yとは、”Don't repeat yourself"の略で、「同じことを繰り返すな」という意味だ。
一方のOCPとは、"Open Closed Principle"の略で、「拡張に対しては開いていて、修正に対しては閉じていなければならない」という意味だ。
これらは近い関係にあり、D.R.Y原則に従って設計すれば、OCPを守りやすくなり、D.R.Y原則に従わなければ、OCPを守りにくい。
以前、Pythonを使ってこれらを説明したことがあるのだが、その時、ソフトウェア開発を2年間経験した3年目のエンジニアから、「D.R.Y原則なんて当たり前だと思う。それに従わないソースコードなんて最初から書きません。ただ、機能の拡張にともなう修正がある場合は難しそうなので、最初から拡張を見越した設計にするべきかな」という的を得た回答をいただいた。
その通りです。素晴らしい。
ところで、D.R.Y原則とOCPは、ソフトウェアの設計やプログラミングだけでなく、エクセルを使ったデータ整理やハードウェア設計にも適用できるはずだ。
時間を見つけて、この辺りのことも考えてみたいと思う。
★WOZ★
| 固定リンク
| コメント (0)
| トラックバック (0)
最近、ソフトウェアエンジニアの育て方について、何人かの人と話をする機会があった。
ある開発プロセス・アセスメントの専門家は、師弟制度が良いという。
実際、大学であれ企業であれ、研究所は師弟制度が徹底しているところが多い。
研究所では、研究テーマ自体が、先輩から後輩に引き継がれていくので、知識や技術の伝承がやりやすく、教育が自然とできてしまう。
問題は研究所以外にいる圧倒的多数のソフトウェアエンジニアだ。
そのアセスメントの専門家が言うには、ろくな教育もないまま、OJT（On-the-Job Training）と称して、単に人足として開発に投入し、若いソフトウェアエンジニア達を消費している企業が多いという。
彼は、そんなことをしていたら、米国並にソフトウェアエンジニアの地位を向上させるどころか、それを職業にしようとする人がいなくなってしまう、と嘆いていた。
かといって、企業が急に変わるとも思えないので、手の届く範囲で、少しずつ次の世代を育てていくしかないように思う。そうすれば、次の次の世代では、日本でもソフトウェアエンジニアに対する見方が変わっているかもしれない。
★WOZ★
| 固定リンク
| コメント (0)
| トラックバック (0)
ソフトウェアテストには、開発と同じかそれ以上のコストがかかるので、その自動化は開発マネージャにとって魅力的なアイデアだ。
しかし、テストを自動化する上で陥ってはいけない罠をCraigは次のように定義している。
（「知識ゼロから学ぶソフトウェアテスト」196ページより）
少し抽象的な定義ではあるが、一度でも自分で自動化に挑戦すると、これらの定義は受け入れやすいと思う。
そして、自動化に向くテストと向かないテストがあるということも考慮する必要がある。例えばスモークテストは自動化に向くが、リグレッションテストは向かないという。
実際、去年試みたテストの自動化では、GUIを含むソフトウェアについて、スモークテスト（ビルドが成功したことを検証するテスト）はとても有効だった。
しかし、全てのテストケースを自動化しようとすると、自動化コードのメンテナンスのコストが増大してしまい、自動化によるコスト削減効果が現象する、ということを経験した。
このように、罠に陥りがちなテストの自動化ではあるが、うまく使えば効果は大きい。来年も積極的に取り組んでいこうと思う。
★WOZ★
 |
|
知識ゼロから学ぶ ソフトウェアテスト
著者：高橋 寿一 |
 |
知識ゼロから学ぶソフトウェアテスト |
| 固定リンク
| コメント (0)
| トラックバック (0)
「ソフトウェア開発リーダのリスク管理」で、去年、新卒エンジニア5人を教育する機会があったことを書いた。そして、そのうちの1人は、大学でソフトウェア工学を学んでおり、今では、まだ2年目だというのに、ソフトウェア開発チームの要としてチームを引っ張っていると書いた。
あとの4人が、今どうしているかについても書いておかなければなるまい。
まず、そのうちの2人（A君とB君）とは、その後、半年ほど一緒に仕事をした。A君は荒削りだが、プログラミングの勘がよく、動くソフトウェアを速く確実に作るのに貢献してくれた。今もさらに技を磨いていることだろう。
B君はプログラミングは最後まで苦手だったのだが、そのぶん分析力にすぐれ、特殊なドメインの要求分析で、素晴らしい成果を残してくれた。とくに、長い間、暗黙知でしかなかった設計ノウハウを、明確な仕様として文書化してくれた功績は、お金に変えられない価値を組織にもたらしてくれた。今は一人前のプロジェクトマネージャを目指して精進していると聞く。
この2人がいなければ、始めて体験するシステム領域で、しかも超短納期の案件を、スケジュール通りに大きなバグを出さず、やり遂げることはできなかっただろう。
あとの2人（C君とD君）とは、残念ながら一緒に仕事をする機会はなかったのだが、今も設計とプログラミングを担当しており、所属する組織の仕事を順調にこなしていると聞く。
結局のところ彼ら5人は、僕の期待以上に成長してくれた。
これからの彼らのソフトウェアエンジニアとしての未来が、輝かしいものであらんことを切に願う。
★WOZ★
| 固定リンク
| コメント (0)
| トラックバック (0)
「4日で学ぶモデル検査 初級編」の後、「SPINモデル検査」を読み、SPINの理論的な背景と動作の仕組み、およびSPINを現実の問題に適用する場合のケーススタディを学んだ。
この時点で、「4日で学ぶモデル検査 初級編」を始めて読んだ時のブログを読み返してみると、モデル検査を誤って理解していたことがわかる。
まず、モデル検査用の言語を、実装用の言語と同じようにみていた。次のように書いている。
//当時の記述１ ここから
SPINの場合、専用言語はPromelaなのだが、
・Promelaのコードから実装言語のコードを自動生成
・実装言語のコードからPromelaのコードを自動生成
することができれば、システム設計レベルでかなり使えるツールだと思う。
//ここまで
次に、設計時にすることが増える、あるいは、違う質の設計をしなければならないことが、導入を妨げるのではないかと漠然と感じていたようだ。
//当時の記述２ ここから
ただ、きちんと検証をするには、システム設計レベルで、モデルと検査項目の仕様を、Promelaなどのプログラミング言語で書く必要があるので、従来の、ワードやエクセルで設計文書を作るという、そういう設計スタイルに慣れている人には、受け入れにくいだろうな、とも思う。
//ここまで
今の理解では、まず言語については、モデル検査が対象とするのは、システムのある特徴を抽象化したモデルであるので、そのモデルを表現しやすいものであれば良いということだ。
SPINは、チャネルで通信する並行プロセスについて、到達性、進行性、線形時相論理を検証するツールであるので、それらを過不足なく表現できる言語であれば良い。それがPromelaというわけだ。そして、それはあくまでもシステムのある特徴を抽象化したものであるので、そのまま実装言語に変換したり、あるいは実装言語からPromelaに変換できる性質のものではない。
次に、設計で行う作業についてだが、SPINで行うモデル検査は、本来、設計時に行うべきことであり、それをやっていないことがバグにつながっているのだと理解した。つまり、システムのある特徴を抽象化したモデルを使って、設計が正しいことを検証する作業は、必要な作業なのだ。この作業は、現在でもUMLのモデルをレビューすることにより不完全であるが行っている。それをレビューではなくモデル検査という数学的手法で行おうというのだ。素晴らしい。
また一歩、モダンなソフトウェア開発に近づいたと感じている。
★WOZ★
| 固定リンク
| コメント (0)
| トラックバック (0)
友達のソフトウェアエンジニアは、開発で一緒になった人に、「銀の弾丸」、「デザインパターン」、「リファクタリング」、「DRY原則」などといった、ソフトウェア開発の重要なキーワードを織り交ぜて話しかけてみて、それに対する反応をみることで、その人の実力値を測るそうだ。
それらは、ソフトウェア業界に入ってくるならば、当然知っているべきものなので、それらを知っているか知らないかで、その人との付き合いかたを変えるのだという。
なるほど、これも一つのリスク管理だ。
開発リーダとして自分のチームの実力を早急に把握しなければならない、彼ならではの方法だと感心する。
ところで、これらのキーワードは、その内容はもちろんのこと、既にソフトウェア開発に関わっている人々の間でも、実はあまり知られていない。新卒エンジニアなら尚更だ。
去年、新卒エンジニア5人を教育する機会があったので、「デザインパターン」「リファクタリング」「DRY原則」あたりの説明をしたのだが、大学でソフトウェア工学を学んだ１人をのぞき、知っているものはいなかった。
その彼は今、まだ2年目だというのに、ソフトウェア開発チームの要としてチームを引っ張っている。ちょうど新卒エンジニアの20％だ。こんなところでも、パレートの法則と符合するものだ。
★WOZ★
| 固定リンク
| コメント (0)
| トラックバック (0)
以下は、UbuntuからSambaサーバ（io-data製のLANDISKなどのNAS）を使う場合の方法だ。
Ubuntu9.04と9.10にはsmbfsが標準で入っていないので、Sambaサーバのディレクトリをマウントする場合には、下のコマンドを実行して、smbfsをインストールする必要がある。
sudo apt-get install smbfs
その後、/mnt にマウントポイントにするディレクトリ（下の場合はlandisk）を作り、下のようなコマンドを実行する。この例では、Sambaサーバの/public/ ディレクトリを、ローカルマシンの/mnt/landiskにマウントしようとしている。
sudo mount -t cifs //サーバのIPアドレス/public /mnt/landisk -o lfs,codepage=cp932,iocharset=utf8,uid=ユーザ名,guest
これでSambaサーバのディレクトリをマウントできる。
★WOZ★
| 固定リンク
| コメント (0)
| トラックバック (0)
このところ、ソフトウェアの品質が以前より強く求められるようになった。
昔からハードウェアをやってきて、いまは組織で偉くなっている人がとくにそう言うことが多いように思う。
だが、そんなこと、いまさら言われなくてもわかってます。
偉そうに品質品質っていうなら、君たちハードウェア関係者は、開発プロセスを守っているのかい？
計画も立ててないし、構成管理もしてないし、進捗管理も、品質管理も、なんにもやってないんじゃないの？
知ってるよ。やってないのを。
で、きちんとやれと言われたら、やってないのを棚にあげて、ぐだぐだ言い訳をして、挙句の果てには、「改善するやりがいがあるからいいんじゃない？」とかわけの分からないことを言い出す始末だ。
「やりがいがあっていい」？
ものは言いようだが、子供の遊びや趣味で製品を作っているのではないのだから、組織としてもっときちんとするべきだろう？
お金もらってるんでしょ？
開発プロセスくらい守れよ。
と考えながら、他人に言う前に、ソフトウェアもきちんと品質確保はしないといけないなぁと考えるクリスマスでした。
★WOZ★
 |
|
CMMI基本と実践-プロジェクトが変わるプロセス改善のすべて
著者：アクセンチュア |
 |
CMMI基本と実践 |
| 固定リンク
| コメント (0)
| トラックバック (0)
ソフトウェアは工業製品ではなく、芸術作品だ。
だから、品質よりも作品性を重視したい。
そもそも、ソフトウェア開発で工業といえるのは、CDーROMやDVDーROMに焼くところだけでしょう？
と、こんな話をすると、そんな考えはけしからん、工業製品としての品質を確保しろ！という意見が必ずある。とくにハードウェアをやってきた人にそういう人が多いように思う。
しかし、”よりも”と言っているだけで、もちろん品質保証は必要だ。
誤字脱字だらけの小説とか、映像が乱れまくる映画、あるいはパーツがぽろっととれてしまう彫刻などは論外だ。
しかし、それら芸術作品に品質だけをもとめるのはお門違いだろう。
ソフトウェアも同じだ。
品質を保証しつつ、人を感動させる芸術性を織り込む。
それがソフトウェア開発の創造性であり、醍醐味だと思う。
そして、その創造性を支援するために、品質を保証するためのソフトウェア開発プロセスがあるのだと思う。
★WOZ★
| 固定リンク
| コメント (0)
| トラックバック (0)
Goではコレクションを処理するのにforとrangeを使う。
例えば、配列[1, 2, 3, 4, 5]の和を求めるコードは次のように書く。
//コードここから
package main
var col =[...]int {1, 2, 3, 4, 5}
func main() {
sum := 0;
for _, value := range col {
sum += value
}
println(sum)
}
//ここまで
ちなみに、同じ処理をPythonなら次のように書く。
Pythonのコレクション処理に慣れていれば、Goのコレクション処理に違和感はないだろう。
//コードここから
col = [1, 2, 3, 4, 5]
sum = 0
for i in col:
sum += i
print sum
//ここまで
★WOZ★
| 固定リンク
| コメント (0)
| トラックバック (0)
コレクションの処理をするとき、Pythonではリスト内包表現を使うが、Rubyではブロックを使う。
例えば、コレクションcolの各要素を10倍した新しいコレクションを作るとき、Pythonなら次のように書く。
col = [1, 2, 3, 4, 5]
[x * 10 for x in col]
Rubyなら次のように書く。
col = [1, 2, 3, 4, 5]
col.collect{|x| x * 10}
両方とも、コレクションcolの各要素をxに代入して、x*10を評価した結果を新しいコレクションにする、という意味だ。
違うのは、Pythonが右から左に読む文法で、Rubyが左から右に読む文法だということだ。両方の式を比べると、"x * 10"と"col"の順番が逆になっている。
Pythonに慣れているとRubyの文法には違和感があるのだが、使い始めるとすぐ慣れるようにも思う。それにRubyのブロックは面白い文法だ。
それにしても、PythonとRubyのこの順序の違いは、英語と日本語の違いに源があるのかもしれない。
★WOZ★
| 固定リンク
| コメント (0)
| トラックバック (0)
エクセルブックにはVBAマクロが含まれる場合がある。
そのようなエクセルブックの拡張子は"xlsm"だ。
Pythonで、そんなエクセルブックを開いてマクロを実行できる。
まず、win32com.clientをインポートする。
import win32com
from win32com.client import *
次に、エクセルを起動する。
app = win32com.client.Dispatch("Excel.Application")
app.Visible = False
次に、エクセルブックtest1.xlsmを開く。このエクセルブックに、Macro1というマクロがあるとする。
book = app.Workbooks.Open("c:\\work\\test1.xlsm")
ここでマクロを動かすには次のように書く。
app.run("test1.xlsm!Macro1")
これでマクロが動く。
その後、ファイルを保存し、
book.SaveAs("c:\\work\\test2.xlsm")
エクセルファイルを閉じる。
book.Close()
最後に、エクセルを終了する。
app.Quit()
このように、Pythonで、マクロを含むエクセルブックのテストをすることができる。
★WOZ★
| 固定リンク
| コメント (0)
| トラックバック (0)
モダンな開発手法を導入していない開発チームでは、進捗管理、構成管理、テスト管理が、個人の力量まかせになっているという話をよく聞く。
そういう組織では新しい手法を提案したところで、採用される可能性は低いし、仮に採用されたところで、提案者が何から何まで他の人の面倒を見るハメになるのが目に見えている。
例えば、構成管理のやり方がわからないから、どんなディレクトリ構成にするか、ファイル名は何にするか決めてくれ、とかね。
人は、長い間ずっとやってきたやり方を捨ててまで、新しいやり方を取り入れることは、なかなかできないものだ。それらしい「できない理由」をつけるのだが、実のところ、面倒くさいのでやらない。
そんな人々を相手に、馬鹿らしいので提案なんて止めておこう。
そして、自分だけこっそり、便利なツールを使って楽をしよう。Redmineも、Subversionも、TestLinkも、Windowsに対応しているので、ツールを動かすのにLinuxマシンは必要ではない。いつも使っているWindowsマシンで十分だ。
これらのツールを使えば、仕事は本当に楽になる。昔ながらの古い手法で無駄に遅くまで残っている人々を尻目に、さっさと定時で帰ってしまおう。
そんなふうに考えている新しい世代のエンジニアは結構いる。
古い世代のエンジニアの考えに染まらないように気をつけながら、彼らが去っていくのを静かに待とう。
★WOZ★
| 固定リンク
| コメント (0)
| トラックバック (0)
12月20日のブログでは、次のようなコードを書いた。
type Sequence []int
func (s Sequence) String() string {
sort.Sort(s);
str := "[";
for i, elem := range s {
if i > 0 {
str += " "
}
str += fmt.Sprint(elem)
}
return str + "]"
}
しかし、実はSequence型を[]int型に変換すると、このメソッドを簡潔に書くことができる。（コード１参照）
func (s Sequence) String() string {
sort.Sort(s);
return fmt.Sprint([]int(s))
}
さらに、ソートする前にSequence型をsort.IntArray型に変換すると、sort.IntArray型が、
を実装しているので、Sequence型はそれらのインタフェースを実装する必要もなくなり、コードが簡単になる。（コード２参照）
func (s Sequence) String() string {
sort.IntArray(s).Sort();
return fmt.Sprint([]int(s))
}
★WOZ★
//コード１ここから
package main
import (
"sort";
"fmt"
)
type Sequence []int
func (s Sequence) Len() int {
return len(s)
}
func (s Sequence) Less(i, j int) bool {
return s[i] < s[j]
}
func (s Sequence) Swap(i, j int) {
s[i], s[j] = s[j], s[i]
}
func (s Sequence) String() string {
sort.Sort(s);
return fmt.Sprint([]int(s))
}
func main() {
var seq Sequence = &[...]int{5, 2, 1, 3, 4};
str := seq.String();
println(str);
}
//ここまで
//コード２ここから
package main
import (
"sort";
"fmt"
)
type Sequence []int
func (s Sequence) String() string {
sort.IntArray(s).Sort();
return fmt.Sprint([]int(s))
}
func main() {
var seq Sequence = &[...]int{5, 2, 1, 3, 4};
str := seq.String();
println(str);
}
//ここまで
| 固定リンク
| コメント (0)
| トラックバック (0)
「知識ゼロから学ぶソフトウェアテスト」という本がある。
この本の９ー２節に、自動化に向くテストと自動化に向かないテストの分類が、次のように書かれている。
自動化に向くテスト：
自動化に向かないテスト：
また、自動化が有効なのは、自動化コードのメンテナンスコストがかからない場合だとも書かれている。
なるほど、と思う。
実は去年、WindowsのUIオートメーションを使って、GUIの自動テストを試みた。対象は結合テストからシステムテストまでだったのだが、GUIの設計変更がある度に自動化コードのメンテナンスが必要だった。このため、一度作ればそれで終わりというわけにはいかなかった。
また、この本のコラムに、自動化コードを作る過程でバグは修正できてしまうので、自動化そのものにそれほどの意味はないとの記述があるが、実際の経験から、この意見にも同意する。
実に示唆に富む良い本だった。
とはいうものの、テストの自動化を考えることは、最初からテストを考慮した設計を行うことにもつながり、結果的にソフトウェアが綺麗な構造になる可能性が高いとも言える。
もう一度、去年試みたことをよく分析してみたいと思う。
★WOZ★
|
|
知識ゼロから学ぶ ソフトウェアテスト
著者：高橋 寿一 |
|
知識ゼロから学ぶソフトウェアテスト |
| 固定リンク
| コメント (0)
| トラックバック (0)
RedmineやTracなどのプロジェクト管理ツールを使い、それらのツールにチケットとして登録した作業を、一つ一つ終わらせていくことにより、開発プロジェクトを進めていく手法を、チケット駆動開発という。
この手法を使うと、
について、開発チーム内で情報を共有できる。
また、開発担当者にとっては、マネージャに報告する手間が省けるし、マネージャにとっては、開発チームの状況がリアルタイムに見渡せるというメリットがある。
ソフトウェア開発に限らず、チーム開発を行う場合には、とても有効な手法だ。
★WOZ★
参考リンク：
| 固定リンク
| コメント (0)
| トラックバック (0)
Go言語の型（type）は複数のインタフェースを実装することができる。
例えば、int型の要素をソートしてから出力するコレクション型を考える。
type Sequence []int
まず、このSequence型は、コレクションの要素をsortパッケージの機能でソートするために、sort.Interfaceを実装しなければならない。
func (s Sequence) Len() int {
return len(s)
}
func (s Sequence) Less(i, j int) bool {
return s[i] < s[j]
}
func (s Sequence) Swap(i, j int) {
s[i], s[j] = s[j], s[i]
}
次に、出力用のStringメソッドを実装する。これはSequence型に固有のインタフェースだ。
func (s Sequence) String() string {
sort.Sort(s);
str := "[";
for i, elem := range s {
if i > 0 {
str += " "
}
str += fmt.Sprint(elem)
}
return str + "]"
}
このように、sort.Interfaceの３つのメソッド
と、独自のメソッド
とを実装することにより、コレクションの要素をソートしてから出力するSequence型を作ることができた。
（Effective Goより抜粋）
★WOZ★
//コードここから
package main
import (
"sort";
"fmt"
)
type Sequence []int
func (s Sequence) Len() int {
return len(s)
}
func (s Sequence) Less(i, j int) bool {
return s[i] < s[j]
}
func (s Sequence) Swap(i, j int) {
s[i], s[j] = s[j], s[i]
}
func (s Sequence) String() string {
sort.Sort(s);
str := "[";
for i, elem := range s {
if i > 0 {
str += " "
}
str += fmt.Sprint(elem)
}
return str + "]"
}
func main() {
var seq Sequence = &[...]int{5, 2, 1, 3, 4};
str := seq.String();
println(str);
}
//ここまで
| 固定リンク
| コメント (0)
| トラックバック (0)
もし、あなたがソフトウェアの開発マネージャで、
ソフトウェアの開発経験が0年の新卒エンジニア数人とともに、
納期3ヶ月の新規開発をしなければならないとしたら、 どうすればいいだろう？
プログラミング言語は重要だ。
そして開発管理も重要だ。
そしてさらに、テスト管理も重要だ。
テストの仕様や進捗管理を、ワードやエクセルで行っていて、煩わしい作業が多かったり、テスト手順漏れや手順誤り、進捗管理ミスなどの間違いを起こした、あるいは起こしかけたことはないだろうか？
もしそうなら、TestLinkを使ってみよう。
TestLinkは、テスト計画、テスト仕様、テスト手順、テスト進捗、テスト評価を管理するためのWebアプリケーションだ。
TestLinkを使うと、次のメリットがある。
まず、テスト担当者にとっては、テストケースの粒度や詳細度について、他のテスト担当者との差異を小さくし易くなる。
次に、テストマネージャにとっては、テストの進捗状況の管理に関する仕事量を劇的に減らせる。
さらに、TestLinkを、TracやRedmineなどのプロジェクト管理ツールと連携させることにより、テストだけでなく開発プロジェクト全体のマネジメントを、さらに効率よく簡単に行うことができる。
TestLinkには、日本語の情報サイトもあるので参照していただきたい。
★WOZ★
| 固定リンク
| コメント (0)
| トラックバック (0)
ソフトウェア開発チームが、
その他もろもろの情報を共有するには、Wikiが最適だ。
Webアプリケーションなので、ブラウザさえあればどこからでも読み書きできるし、他人が書いた記事の間違いに気づけば、修正することもできるので、情報は常にアップデートされている。
ソフトウェア開発チームにとって情報の陳腐化は忌避だ。
それを防ぐために、Wikiは最適なツールだ。
僕がソフトウェア開発チームに導入したのは、MoinMoinというwikiアプリケーションだ。
MoinMoinはPythonで書かれていて、oracleやmysqlといったデータベースソフトウェアを必要としないので、とても手軽に導入できた。
日本語の文献がないのが欠点なのだが、Wikipediaにも載っているので、それほどマイナーということもないのだろう。
ネットを探せば、MoinMoinを紹介している日本語のサイトもある。英語が嫌いでない方は是非、挑戦してみてほしい。
★WOZ★
| 固定リンク
| コメント (0)
| トラックバック (0)
Pythonにはデコレータ構文というものがある。
これは、クラス、関数、メソッドをデコレートする構文だ。
デコレータは、既存の関数やメソッドに修正を加えずに、ログ機能を織り込みたい場合などに効果的に使える機能だ。
前回は、関数fooに、呼ばれた時に関数名を出力するログ機能をつけてみたが、今回はさらに、呼ばれた時の関数名と引数を出力するログ機能をつけてみる。
def Pre(f):
def _(*arg):
print f.func_name + " is called. arg= " + str(arg)
f(*arg)
return _
@Pre
def foo(n, s):
print "Foo:" + s*n
関数fooを次のように実行すると、
foo(2, "hello ")
下のように表示する。
foo is called. arg= (2, 'hello ')
Foo:hello hello
このように、デコレータを使うと関数に簡単にログ機能を追加できる。
★WOZ★
 |
|
Python: Pocket Reference (Python in Your Pocket)
著者：Mark Lutz |
 |
|
初めてのPython 第3版
著者：Mark Lutz |
 |
初めてのPython第3版 |
| 固定リンク
| コメント (0)
| トラックバック (0)
Pythonにはデコレータ構文というものがある。
これは、クラス、関数、メソッドをデコレートする構文だ。
デコレータは、既存の関数やメソッドに修正を加えずに、ログ機能を織り込みたい場合などに効果的に使える機能だ。
例えば、関数fooに、呼ばれた時に関数名を出力するログ機能をつけるには、次のように書く。
def Pre(f):
def _():
print f.func_name + " is called."
f()
return _
@Pre
def foo():
print "Foo"
関数foo()を実行すると、次のように出力する。
foo is called.
Foo
★WOZ★
|
|
Python: Pocket Reference (Python in Your Pocket)
著者：Mark Lutz |
|
|
初めてのPython 第3版
著者：Mark Lutz |
|
初めてのPython第3版 |
| 固定リンク
| コメント (0)
| トラックバック (0)
もし、あなたがソフトウェアの開発マネージャで、
ソフトウェアの開発経験が0年の新卒エンジニア数人とともに、
納期3ヶ月の新規開発をしなければならないとしたら、
どうすればいいだろう？
プログラミング言語は重要だ。
そして開発管理も重要だ。
さらに、開発チームのコミュニケーションも重要だ。
開発チームのコミュニケーションのために、朝会を開こう。
朝会では、開発チームのメンバーが開発管理ツールに登録しているチケットの内容を確認しよう。チケットには、
という情報が登録されている。
朝会の場で解決できるものは、すぐ解決しよう。
解決できないものは、担当者を決めたり、検討する計画を立てよう。
朝会は、開発チームが情報を共有し、リスクを早期に発見し、問題を機敏に解決するための絶好の機会だ。
★WOZ★
| 固定リンク
| コメント (0)
| トラックバック (0)
モダンなソフトウェア開発チームは、よく朝会をやります。
朝会というのは、 朝の9時前後に、チームの誰かの席の辺りに集まって、立ったまま、
そんな軽い感じのミーティングです。
この朝会では、結論は出しません。
それはまた、別の会議で適切なメンバーを集めて決めます。
そして決まったことは翌日の朝会でその他のメンバーにも知らせます。
もちろん、急ぐ場合はメール等で告知することもあります。
朝会は、だいたい10分から15分で終わります。
★WOZ★
| 固定リンク
| コメント (0)
| トラックバック (0)
もし、あなたがソフトウェアの開発マネージャで、
ソフトウェアの開発経験が0年の新卒エンジニア数人とともに、
納期3ヶ月の新規開発をしなければならないとしたら、
どうすればいいだろう？
プログラミング言語は重要だ。
そして開発管理も重要だ。
開発管理にはRedmineやTracなどのプロジェクト管理ツールを使うと良い。
これらのツールには、
という情報をチケットとして登録することができる。それらのチケットを一つ一つ片付けていくことにより、開発プロジェクトが進んでいくというわけだ。
プロジェクト管理ツールが使えるようになったら、難しいことは考えず、とりあえず、どんどんチケットに登録していこう。チケットには、「検討項目」「バグ」 「調査」「リスク」とったタグがつけられるので、チケットの内容を示すタグをつけておくと、後で整理するときに便利だ。
また、RedmineもTracもWebアプリケーションなので、開発チームのメンバーが登録したチケットは、ブラウザさえ使えれば、誰でも、どこからでも見ることができる。まさに情報の共有と見える化だ。
もちろん、開発チームのメンバーが本当のことを申告するのが前提だが、経験から言えるのは、こういうツールを導入して、情報の共有と見える化は当たり前という雰囲気にしてしまうと、メンバーは進んでチケットを登録し始めるということだ。
もっとも開発メンバーは、新卒だとか、2年目だとか、ある程度若いほうが、そういうツールを使う文化に早く馴染むのは間違いないだろう。
★WOZ★
| 固定リンク
| コメント (0)
| トラックバック (0)
Pythonにはデコレータ構文というものがある。
これは、クラス、関数、メソッドをデコレートする構文だ。
今、
def foo():
print "Foo"
という関数があるとする。
この関数を実行すると、
Foo
と表示する。
さて、
に、必ず何か処理をさせたいのだが、その関数自体を修正したくはない、というのはよくあることだ。
こんな時に、デコレータ構文が役にたつ。
今、関数fooの前に事前処理（preprocess）をさせたい場合には、次のように書く。
def Pre(f):
def _():
print "Pre Process"
f()
return _
@Pre
def foo():
print "Foo"
関数fooを実行すると、
Pre Process
Foo
と表示される。
同様に、関数fooの後に、事後処理（postprocess）を実行させたい場合には、次のように書く。
def Post(f):
def _():
f()
print "Post Process"
return _
@Post
def foo():
print "Foo"
また、関数fooを事前処理と事後処理ではさみたい場合には、次のように書く。
def PreAndPost(f):
def _():
print "Pre Process"
f()
print "Post Process"
return _
@PreAndPost
def foo():
print "Foo"
このようにデコレータは、既存の関数やメソッドに修正を加えずに、ログ機能を織り込みたい場合などに効果的に使える機能だ。
★WOZ★
| 固定リンク
| コメント (0)
| トラックバック (0)
Go言語は、syncパッケージに含まれるロックデータ型sync.Mutexを使って簡単にgoroutine間の同期をとることができる。
それは、あるsync.Mutex型の変数lに対して、n回目のl.Unlock()は、必ずm回目のl.Lockが終わる前に起こる、というルールがあるためである。（ただし、n ≦ m）
例えば、下のコードでは、関数fの中のl.Unlock()は、関数mainの中の2回目のl.Lock()が終わる前に終わるので、”hello, world"が表示されることが保証される。
channelを使う同期と同様に、sync.Mutexを使う同期も、他の言語と比べて簡単かつ安全に書くことができる。
★WOZ★
//コードここから
package main
import (
"sync"
)
var l sync.Mutex
var a string
func f() {
a = "hello, world";
l.Unlock();
}
func main() {
l.Lock();
go f();
l.Lock();
println (a);
}
//ここまで
| 固定リンク
| コメント (0)
| トラックバック (0)
Pythonは、リスト内包式（list comprehension expressions）を使ってリストを生成することができる。
しかし、生成したリストの要素の最初のほうだけを使って、後は使わない場合があるプログラムを考えると、一度に全て計算してしまうのは無駄だ。計算コストとメモリ領域の無駄がある。
できれば、必要になった時に、必要な分だけ計算したい。
こういう計算方法を遅延評価と言うが、Pythonには遅延評価を行う仕組みが用意されている。ジェネレータ式（generator expressions)がそれだ。
ジェネレータ式はこう書く。
>>> squares = (x ** 2 for x in range(5))
ジェネレータ式が生成するリスト要素は、イテレータ（上の場合はsquares)のnextメソッドが呼ばれる度に計算される。
>>> squares.next()
0
>>> squares.next()
1
このように、ジェネレータ式を使うことで、計算コストとメモリ領域の無駄をなくすことができる。
Pythonにはさらに、内部にループを持つ関数をジェネレータ化する仕組みが用意されている。yield文がそれだ。
次のように使う。
>>> def generateSquares(N):
... for i in range(N):
... yield i ** 2
...
>>> G = generateSquares(5)
>>> list(G)
[0, 1, 4, 9, 16]
ここでGはイテレータなので、次のようにも使える。
>>> G = generateSquares(5)
>>> G.next()
0
>>> G.next()
1
>>> G.next()
4
>>> G.next()
9
>>> G.next()
16
このようにyield文でジェネレータ化した関数は、yield文を実行した後で関数の状態を保存して一時停止し、次のイテレーション（next()が呼ばれた時）で、関数を前の状態に戻して、yield文の次から処理を再開する。
yieldを使う、この遅延評価の仕組みは、PythonのシミュレーションライブラリであるSimPyにおいて、モデルを記述するのに使われている。
★WOZ★
|
|
Python: Pocket Reference (Python in Your Pocket)
著者：Mark Lutz |
|
|
初めてのPython 第3版
著者：Mark Lutz |
|
初めてのPython第3版 |
| 固定リンク
| コメント (1)
| トラックバック (0)
先日、岐阜の裁判所勤務で、九州出身の裁判官が、「デンシンボウ」という言葉がわからなかったために、被告の発言を問いただした一件が、ニュースになっていた。
デンシンボウ？
(・ω・`)？？
漢字では「電信棒」と書く。
電信柱あるいは電柱のことだ。
(・ω・`)？？？
そんなもん、わかりません。
岐阜出身の友達に裏をとったところ、
「いいますよ〜」
だそうだ。
昔から、方言とか訛りというのは、人々の興味をひくもののようで、
松本清張の「砂の器」では、方言が事件の謎をとく鍵になっている。
また近年では、 探偵ナイトスクープの伝説的調査「全国アホ・バカ分布図」はあまりにも有名だ。
音声認識が、本当に自然なユーザインタフェースになるには、こういう方言とか訛りを扱えるようにならないといけないのだろう。
★WOZ★
 |
|
砂の器〈下〉 (新潮文庫)
著者：松本 清張 |
 |
|
砂の器〈上〉 (新潮文庫)
著者：松本 清張 |
 |
|
全国アホ・バカ分布考―はるかなる言葉の旅路 (新潮文庫)
著者：松本 修 |
 |
砂の器（上巻）改版 |
 |
砂の器（下巻）改版 |
 |
全国アホ・バカ分布考 |
| 固定リンク
| コメント (0)
| トラックバック (0)
リスト内包式（list comprehension expressions）は、次のように書く。
>>> [x **2 for x in range(5)]
この式を実効すると、次のリストが得られる。
>>>[0, 1, 4, 9, 16]
リストの要素を計算するコストが大きくなく、またリストの要素が少ないなら、一度に全て計算してしまっても実質的な問題はない。
しかし、リストの要素の計算に必要なコストが大きかったり、リストの要素数が多かったりする場合には問題になる。
例えば、生成したリストの要素の最初のほうだけを使って、後は使わない場合があるプログラムを考えると、一度に全て計算してしまうのは無駄だ。計算コストとメモリ領域の無駄がある。
できれば、必要になった時に、必要な分だけ計算したい。
こういう計算方法を遅延評価と言うが、Pythonには遅延評価を行う仕組みが用意されている。ジェネレータ式（generator expressions)がそれだ。
ジェネレータ式はこう書く。
>>> squares = (x ** 2 for x in range(5))
リスト内包式との違いは、'['と']'で囲むか、'('と')'で囲むかだ。
ジェネレータ式が生成するリスト要素は、イテレータ（上の場合はsquares)のnextメソッドが呼ばれる度に計算される。
>>> squares.next()
0
>>> squares.next()
1
このように、ジェネレータ式を使うことで、計算コストとメモリ領域の無駄をなくすことができる。
なお、今回のコードは、”Python Pocket Reference 4th Edition”から引用した。
★WOZ★
 |
|
Python: Pocket Reference (Python in Your Pocket)
著者：Mark Lutz |
 |
|
初めてのPython 第3版
著者：Mark Lutz |
 |
初めてのPython第3版
販売元：楽天ブックス |
| 固定リンク
| コメント (0)
| トラックバック (0)
このブログにコメントを寄せていただいた方のブログを訪問した。
という気づきがあり、大変勉強になった。
”気づき”といえば、先日、久しぶりに友達とご飯を食べた時に、その友達が”気づきドリブンのススメ”という言葉で、新しいことや、知らなかったことに気づくことの重要性を力説していたのを思い出す。
”ドリブン”は、テストドリブン（テスト駆動、test driven）やイベントドリブン（event driven）のドリブンだ。
友達の定義によると、「気づくことにより、新しいものを生み出す力が産まれる」ということらしい。
いろいろなことに興味をもち、少しでもたくさんのことに気づいていきたいと思う。
★WOZ★
| 固定リンク
| コメント (0)
| トラックバック (0)
音声認識は実は力技だ。
リアルタイムで、精度の高い認識結果を出すためには、
できるだけ大きな音素辞書、
できるだけ大きな語彙辞書、
できるだけ大きな文法、
を、できるだけ短時間で処理することが必要になる。
それに、それらの辞書の元になる音声データや言語データを、
できるだけ大量に集めて、辞書化する作業も必要だ。
Googleは検索技術で、大量のデータを高速に、
並行処理する技術を蓄積しており、
またコールセンターに集められる大量の音声データや言語データを、
コツコツと集めていたのだろう。
あるいはそれらのデータとノウハウを持つ会社を買ったのかもしれない。
いずれにせよ、音声認識を実用化する準備を着々と進めていた、と見ることもできる。次は、音声認識と同じやり方で、基礎研究を実用化できる可能性がある画像や動画認識だと思う。
実際、Googleはストリートビューを開発するために、画像や映像データを集めている。
★WOZ★
 |
|
人と対話するコンピュータを創っています 音声認識の最前線
著者：古井 貞熙 |
 |
|
フリーソフトでつくる音声認識システム - パターン認識・機械学習の初歩から対話システムまで
著者：荒木 雅弘 |
 |
フリーソフトでつくる音声認識システム
販売元：楽天ブックス |
| 固定リンク
| コメント (0)
| トラックバック (0)
もし、あなたがソフトウェアの開発マネージャで、
ソフトウェアの開発経験が0年の新卒エンジニア数人とともに、
納期3ヶ月の新規開発をしなければならないとしたら、
どうすればいいだろう？
プログラミング言語は重要だ。
それとともに、開発チームが、
を管理することも、ソフトウェア開発を成功に導く重要な要素だ。
そんな開発管理には、プロジェクト管理ツールを使おう。
最近使ってみて、好評だったがRedmineだ。
このツールはRubyで書かれていて、使い勝手はマイクロソフトのプロジェクトに似ている。Pythonで書かれているTracと 比べたのだが、「Redmineの画面が、ソフトウェア開発の初心者にとって、ぱっと見てわかりやすい」、「Rubyのほうが日本では有名」ということ で、Redmineを選んだ。最初は一つの開発チーム向けに導入したのだが、他のチームも真似をして使い始めて、あっという間に普及してしまった。
プロジェクト管理ツールを使うと、開発の見通しが本当によくなる。
是非使ってみてほしい。
★WOZ★
 |
|
Redmine -もっと手軽にプロジェクト管理!
著者：倉貫 義人,栗栖 義臣,並河 祐貴,前田 直樹 |
 |
|
入門Redmine Linux/Windows対応
著者：前田 剛 |
 |
Redmineーもっと手軽にプロジェクト管理！
販売元：楽天ブックス |
 |
入門Redmine
販売元：楽天ブックス |
| 固定リンク
| コメント (0)
| トラックバック (0)
他のプログラミング言語に比べて、Pythonが便利だと思える機能の一つに、「リスト内包式」がある。原語は"list comprehension expressions"だ。
リスト内包式は、あるリストから別のリストを生成する式だ。
例えば、リスト[0, 1, 2, 3, 4]の各要素を2乗した新しいリストを作る場合は、次のように書けば良い。
[x**2 for x in [0, 1, 2, 3, 4]]
ここで、[0, 1, 2, 3, 4]の部分はrange(5)で生成できるので、この式は、
[x**2 for x in range(5)]
と書ける。結果はどちらも、
[0, 1, 4, 9, 16]
だ。
新たなリストを生成するときに、条件をつけることもできる。例えば、リスト[0, 1, 2, 3, 4]の中の偶数だけ取り出して、新たなリストを作る場合は次のように書く。
[x for x in range(5) if x % 2 == 0]
結果は、
[0, 2, 4]
だ。
また、ネストしたforを使うこともできて、
[y for x in range(3) for y in range(3)]
という式も書ける。
これは少し分かり辛いが、
res = []
for x in range(3):
for y in range(3):
res.append(y)
と書いたのと同じだ。見比べてみてほしい。
結果は、
[0, 1, 2, 0, 1, 2, 0, 1, 2]
となる。
このようなリスト処理はPythonが得意とする分野だ。
今回のコードは、”Python Pocket Reference 4th Edition”から引用した。
★WOZ★
|
|
Python: Pocket Reference (Python in Your Pocket)
著者：Mark Lutz |
|
|
初めてのPython 第3版
著者：Mark Lutz |
| 固定リンク
| コメント (0)
| トラックバック (0)
もし、あなたがソフトウェアの開発マネージャで、
ソフトウェアの開発経験が0年の新卒エンジニア数人とともに、
納期3ヶ月の新規開発をしなければならないとしたら、
どうすればいいだろう？
その案件がLinuxなら、成功は難しいかもしれない。
しかし、案件がWindowsなら、やり終える可能性はある。
開発言語にはC#を選ぼう。
C#は、VisualStudioと.NETとの組み合わせで、高い生産性を実現することができる。単体テストもNUnitというフリーソフトウェアを使えるし、少し手間を加えれば、GUIの自動テストもできてしまう。
正直、マイクロソフトの言語にはそれほど期待していなかったが、C#の人を選ばないところは気に入っている。
★WOZ★
![[完全版] 究極のC#プログラミング ~新スタイルによる実践的コーディング](http://ecx.images-amazon.com/images/I/41fMnxla7-L._SL160_.jpg "[完全版] 究極のC#プログラミング ~新スタイルによる実践的コーディング") |
|
[完全版] 究極のC#プログラミング ~新スタイルによる実践的コーディング
著者：川俣 晶 |
 |
究極のC＃プログラミング
販売元：楽天ブックス |
| 固定リンク
| コメント (1)
| トラックバック (0)
iPhoneでGoogleの音声認識を試してみて気づくのは、音声認識を自然なユーザ・インタフェースにするために、様々な工夫がされていることだ。
すぐわかるのは、音声認識処理の開始時期を、iPhoneの位置と姿勢の変化、とタッチパネルと顔との距離によって判断しているらしいところだ。
音声認識ソフトウェアは限られた文法と語彙しか扱えないため、この範囲に認識すべき音声波形があるということを、音声認識ソフトウェアに教えてやる必要がある。
例えばカーナビなどは運転者にスイッチを押させることによって、認識範囲の開始位置を教え、音声入力がなくなってから500ミリ秒たっても新たな音声入力がない場合に、認識範囲の終了位置を教える、という方法がよく採用されている。
iPhoneの場合には、上に書いた位置と姿勢の変化、タッチパネルと顔との距離、をキーにして、認識範囲の開始位置をソフトウェアに教えているようだ。
認識範囲の終了位置の検出は従来のカーナビなどの方式と同じだ。
音声認識のデバイスを特定のケータイ電話に限定することで、口とマイクの距離を一定に保つこともできるし、マイクの特性も同一にできるので、音声認識エンジン自体の精度も向上する。
音声認識エンジンの性能だけに頼らず、それをサポートする様々な工夫をすることで、自然なユーザインタフェースを実現している。
★WOZ★
|
|
フリーソフトでつくる音声認識システム - パターン認識・機械学習の初歩から対話システムまで
著者：荒木 雅弘 |
|
|
人と対話するコンピュータを創っています 音声認識の最前線
著者：古井 貞熙 |
 |
|
IT Text 音声認識システム
著者：鹿野 清宏,河原 達也,山本 幹雄,伊藤 克亘,武田 一哉 |
| 固定リンク
| コメント (0)
| トラックバック (0)
Googleケータイでは、ケータイに住所を喋ると、Googleマップがその近所の地図を表示する。目的地を喋ると、道案内までしてくれる。
本当のパーソナルコンピュータがいよいよ登場か！と予感させる。
ところで、何故、Googleケータイは、そんな「話せばわかる」ことができるのかと、疑問に思う人も多いだろう。
そんな好奇心いっぱいの方々には、音声認識研究の大御所である古井先生による入門書が良いと思う。
わかりやすいので、初めての人でも読み通せるはずだ。
★WOZ★
|
|
人と対話するコンピュータを創っています 音声認識の最前線
著者：古井 貞熙 |
| 固定リンク
| コメント (0)
| トラックバック (0)
Go言語のchannelを使うと、ある処理をバックグランドで起動しておいて、その処理が完了するのを、起動元が待ち合わせるという処理が、簡単に書ける。
channelにはSenderとReceiverがあり、またchannelにはバッファありとバッファなしがある。
バッファなしのchannelの場合、Receiverは受信データが来るまで、つまりSenderがデータ送信を完了するまで、処理を先に進めずに待っている。
下のコードは、そのchannelの機能とgoroutineを使って書いた、バックグランドでソート処理を起動し、そのソート処理が終わるのを起動元が待ち合わせるサンプルプログラムだ。
Go言語はこのような並行処理を実に簡単に安全に書ける。
★WOZ★
//コードここから
package main
import (
"fmt";
"sort"
)
func sortTest(s []int) {
c := make(chan int);
go func() {
sort.SortInts(s);
c <- 0;
}();
<-c;
}
func main() {
s := make([]int, 10);
a := [...]int{1, 5, 4, 2, 3};
s = &a;
sortTest(s);
for i := 0; i < len(s); i++ {
fmt.Println(s[i])
}
}
//ここまで
| 固定リンク
| コメント (0)
| トラックバック (0)
今年はAR（Augmented Reality, 拡張現実）がブレイクしました。
バーチャルリアリティと言われていたころは、なかなか普及しなかったのですが、何十年もかけて、ようやくここまで来たか！と、昔を知っているものにとっては感動ものです。
それから、先日Googleが音声認識を実用化したニュースが大々的に発表されましたが、音声認識もやはり何十年もかけて、ようやく、、、という技術です。
さすがにGoogleは、音声認識の強みと弱みを知っており、うまく応用するものだ、と感心しています。
音声認識では、音素辞書と語彙辞書を使います。
ごく簡単に説明すると、
音素辞書というのは、’あ’、’い’、’う’、’え’、’お’の母音と’k’、’s’、、、’w’といった子音の音を収録した辞書です。
語彙辞書というのは、”東京都”、”大阪府”、”愛知県”、、、という認識したい語彙を収録した語彙です。
これらの辞書を使って、マイクから入力する音声にどの語彙が含まれているのかを調べるのが音声認識です。
この技術では、マイクから入力される音声の特徴に、音声辞書の特徴が合っていることと、
マイクから入力される語彙が、語彙辞書に含まれることが、認識性能をあげるポイントです。
他にも、認識アルゴリズムの高速化や効率化など、いろいろと難しいことがあり、いろいろな会社が実用化を試みましたが、うまくいきませんでした。
この分野の大御所である古井先生の新刊は、この音声認識についてわかりやすく解説している入門書です。
★WOZ★
|
|
人と対話するコンピュータを創っています 音声認識の最前線
著者：古井 貞熙 |
| 固定リンク
| コメント (0)
| トラックバック (0)
本格的なクラウドの活用や音声認識の実用化で勢いづくGoogleのAndroidだが、本書は、そのAndroid用のアプリケーションの仕組みと作り方を解説している入門書だ。
現時点でのAndroid用アプリケーション開発言語であるJavaのソースコードを追いかけながら、開発環境、動作の基本的な仕組み、ネットワーク、カメラ、GPS、地磁気センサーなどのデバイスの利用方法を説明している。
実際にAndroid用アプリケーションを開発したい人はもちろん、読み物としても十分に楽しめる一冊だ。
★WOZ★
 |
|
Google Androidアプリケーション開発入門 画面作成からデバイス制御まで――基本機能の全容
著者：木南 英夫 |
 |
Google Androidアプリケーション開発入門
販売元：楽天ブックス |
| 固定リンク
| コメント (0)
| トラックバック (0)
Go言語は、「埋め込み（Embedding)」機能により「実装の継承」を行うことができる。これは、追加したい機能をもつ型から、その機能を借りてくることができる機能だ。
12月8日の「Go言語の実装と継承」では、下のようにObj型にLogger型を埋め込むことにより、
という説明をした。
type Obj struct {
*Logger;
}
この例では、Obj型にはLogger型の変数へのポインタを埋め込んでいるが、Logger型への変数を埋め込むこともできる(コード１）。
type Obj struct {
Logger;
}
ところで、LoggerのLogメソッドはオーバーライドできるので、Logger型から借りた機能を拡張することもできる（コード２）。
★WOZ★
//コード１ ここから
package main
import "fmt"
type Logger struct { }
func (logger *Logger) Log(s string) { fmt.Println(s) }
type Obj struct {
Logger;
}
func main() {
obj := new(Obj);
obj.Log("starting...");
}
//ここまで
//コード２ ここから
package main
import "fmt"
type Logger struct { }
func (logger *Logger) Log(s string) { fmt.Println(s) }
type Obj struct {
Logger;
}
func (obj Obj) Log(s string) {
obj.Logger.Log("LOG: " + s)
}
func main() {
obj := new(Obj);
obj.Log("starting...");
}
//ここまで
| 固定リンク
| コメント (0)
| トラックバック (0)
最近、まわりの人と話していて、よく話題に上るのは、「そういえば、開発プロセスっていうのは、大学でも教えてもらわないし、会社でも教えてもらわないなぁ」ということだ。
で、それに続く話題は、「仕事に使わないプログラミング技術や言語を知らないのは良いとして、開発プロセスぐらい知らんと、仕事にならんだろう～」ということだったりする。
 |
|
CMMI基本と実践-プロジェクトが変わるプロセス改善のすべて
著者：アクセンチュア |
 |
CMMI基本と実践
販売元：楽天ブックス |
| 固定リンク
| コメント (0)
| トラックバック (0)
C++のようなクラス継承がある言語なら、あるクラスに機能を追加したいときに、クラス継承を使うかもしれない。
一方、Go言語にはクラス継承はないのだが、「埋め込み（Embedding)」機能により「実装の継承」を行うことができる。これは、追加したい機能をもつ型から、その機能を借りてくることができる機能だ。
例えば、下のようにObj型にLogger型を埋め込むことにより、Logger型のメソッドがObj型のメソッドになる。
しかし、そのメソッドが呼ばれた時に、そのレシーバとなるのは、Obj型の変数ではなく、Logger型の変数だ。
type Obj struct {
*Logger;
}
継承には、クラス間の関係が複雑になるという問題があるので、以前からあまり好きではなかった。例えばAdapterパターンでも、継承ではなく移譲をよく使っている。
このため、Goがクラス継承ではなく、埋め込みによって実装の継承を行うのは、とても気に入っている点だ。
下のコードは、Obj型にLogger型のLogメソッドを追加している。
★WOZ★
//コードここから
package main
import "fmt"
type Logger struct { }
func (logger *Logger) Log(s string) { fmt.Println(s) }
type Obj struct {
*Logger;
}
func newObj(logger *Logger) *Obj {
return &Obj{logger}
}
func main() {
logger := new(Logger);
obj := newObj(logger);
obj.Log("starting...");
}
//ここまで
| 固定リンク
| コメント (0)
| トラックバック (0)
AND、OR、NOT、NAND、NOR、XORが組み合わせ回路。
こいつらは状態を記憶することができません。
組み合わせ回路を組み合わせて、
状態を記憶できるようにした回路が、順序回路。
順序回路にはフリップフロップやカウンタがある。
こんな小さな回路がたくさん集まって、コンピュータができています。
デジタル回路のことなんて、ほとんど忘れかけていましたが、
たまには思い出すのも良いものです。
★WOZ★
 |
|
CPUの創りかた
著者：渡波 郁 |
| 固定リンク
| コメント (0)
| トラックバック (0)
普段からパソコンは使いこなせていて、ワードやエクセルも仕事や学校で使っているんだけど、プログラミングとなると敷居が高いなぁ、と感じている人はわりといるのではないだろうか。
そんな人におすすめなのが、PythonやVBAだ。
とくにVBAは、エクセルを持っている人なら、追加で何かをインストールしなくても使える。それでいてプログラミングの雰囲気を感じることができる。
例えば、A１セルの文字列をシート名にするなら、
ActiveSheet.Name = Range("A1").Value
と書く。
選択シートの右側にシートを挿入するなら、
Sheets.Add After:=ActiveSheet
と書く。
「選択しているセルの値を、そのシートの名前にする」関数を作るには、
Sub シート名を選択セルの文字に()
ActiveSheet.Name =ActiveCell.Value
End Sub
と書く。これがVBAのプログラムだ。それをマイクロソフトは「VBAマクロ」と呼んでいる。
こんなマクロを追加していくと、エクセルファイルを、表データを書き込むだけのファイルから、表データを処理して新しい情報を産み出すソフトウェアにすることができる。
もしまだマクロを書いたことがないなら、ぜひ始めてみてほしい。プログラミングの楽しさが実感できるはずだ。
★WOZ★
 |
|
エクセルマクロ事典 (日経BPパソコンベストムック)
著者：日経PC21 |
| 固定リンク
| コメント (0)
| トラックバック (0)
Go言語では、goroutineと呼ぶ軽量のコルーチンを簡便に生成できる。
そして、goroutine間の同期にはchannelを使うことができる。
goroutineの生成は簡単で、例えば関数fをgoroutine化するには、
go f()
と書く。
channelを作るには、
var c = make(chan int)
と書く。
channelにデータを送るには、
c <- 0
と書く。
channelからデータを取り出すには、
<-c
と書く。
バッファを持たないチャンネルの場合、送信が完了する前に必ず受信が起こるというルールがあり、このルールをgoroutine間の同期に使うことができる。
例えば、下記のソースコードでは、"hello, world"と表示されることが保証されている。今、このソースコードからチャンネルに関するコードを除くと、２つのgoroutine間の同期の仕組みがなくなるため、"hello, world"と表示されることが保証されなくなる。
★WOZ★
//コード ここから
package main
import "fmt"
var c = make(chan int)
var a string
func f() {
a = "hello, world";
<-c;
}
func main() {
go f();
c <- 0;
fmt.Printf("%s\n", a);
}
//ここまで
| 固定リンク
| コメント (0)
| トラックバック (0)
Goで配列のソートを試してみた。
手順は以下の通りだ。
Pythonと比べると一手間多い。
★WOZ★
//コードここから
package main
import (
"fmt";
"sort"
)
func main() {
s := make([]int, 10);
a := [...]int{1, 5, 4, 2, 3};
s = &a;
sort.SortInts(s);
for i:=0; i < len(s); i++ {
fmt.Println(s[i])
}
}
//ここまで
| 固定リンク
| コメント (0)
| トラックバック (0)
Go言語では、goroutineと呼ぶ軽量のコルーチンを簡便に生成できる。
そして、goroutine間の同期にはchannelを使うことができる。
channelにはバッファありとバッファなしの二種類があり、バッファなしのchannelを使ったgoroutineの同期については以前書いた。今回はバッファありのchannelを使ったgoroutineの同期について書く。
goroutineの生成は簡単で、例えば関数fをgoroutine化するには、
go f()
と書く。
バッファありのchannelを作るには、
var c = make(chan int, 10)
と書く。
channelにデータを送るには、
c <- 0
と書く。
channelからデータを取り出すには、
<-c
と書く。
バッファありのチャンネルの場合、受信が完了する前に必ず送信が起こるというルールがあり、このルールをgoroutine間の同期に使うことができる。
例えば、下記のソースコードでは、"hello, world"と表示されることが保証されている。今、このソースコードからチャンネルに関するコードを除くと、２つのgoroutine間の同期の仕組み がなくなるため、"hello, world"と表示されることが保証されなくなる。
★WOZ★
//コード ここから
package main
import "fmt"
var c = make(chan int, 10)
var a string
func f() {
a = "hello, world";
c <- 0;
}
func main() {
go f();
<- c;
fmt.Printf("%s\n", a);
}
//ここまで
| 固定リンク
| コメント (0)
| トラックバック (0)
Go言語で書き、Python2.6で書き直したカウンタのコードを、さらにPython3.1で書き直してみる。
まずGo言語と比べると、Pythonは型を宣言する必要がないので、
cnt0 = counter(0);
と書くと、初期値が0のカウンタが作られ、
cnt10 = counter(10)
と書くと、初期値が10のカウンタが作られる。
そして、
cnt0カウンタは呼び出される度に、1, 2, 3, , , とカウントアップし、
cnt10カウンタは呼び出される度に、11, 12, 13, , ,とカウントアップする。
さて、Python2.6では内側の関数から外側のローカル変数を書き換えることができないので、クロージャを書くときには、変数ではなくリストを使った。
しかしPython3.0からは、nonlocal文を使うことで内側の関数から外側のローカル変数を書き換えられる。このため、Python3.xではGoと同様のクロージャの書き方ができる。
最後に、Python3.0ではprintが文ではなく関数なので、
print cnt0()
ではなく、
print (cnt0())
と書く。
下のコードはPython3.1用だ。
★WOZ★
//コードここから
def counter(n):
i = n
def func():
nonlocal i
i += 1
return i
return func
if __name__ == '__main__':
cnt0 = counter(0)
cnt10 = counter(10)
print (cnt0())
print (cnt0())
print (cnt10())
print (cnt10())
print (cnt0())
print (cnt0())
//ここまで
| 固定リンク
| コメント (0)
| トラックバック (0)
昨日のGoのコードをPythonで書き直してみる。
Pythonは型を宣言する必要がないので、
cnt0 = counter(0);
と書くと、初期値が0のカウンタが作られ、
cnt10 = counter(10)
と書くと、初期値が10のカウンタが作られる。
cnt0カウンタは呼び出される度に、1, 2, 3, , , とカウントアップし、
cnt10カウンタは呼び出される度に、11, 12, 13, , ,とカウントアップする。
Python2.6では内側の関数から外側のローカル変数を書き換えることができないので、クロージャを書くときには、変数ではなくリストを使う。これはGoにはない制限だ。
しかしPython3.0からは、nonlocal文を使うことで内側の関数から外側のローカル変数を書き換えられる。このため、Python3.xではGoと同様のクロージャの書き方ができる。
下のコードはPython2.6用だ。
★WOZ★
//コードここから
def counter(n):
i = [n]
def func():
i[0] += 1
return i[0]
return func
if __name__ == '__main__':
cnt0 = counter(0)
cnt10 = counter(10)
print cnt0()
print cnt0()
print cnt10()
print cnt10()
print cnt0()
print cnt0()
//ここまで
| 固定リンク
| コメント (0)
| トラックバック (0)
昨日のコードを、生成するカウンタ関数の初期値を、呼出側が設定できるように修正した。つまり、
var cnt0 func() int = counter(0);
と書くと、初期値が0のカウンタが作られ、
var cnt10 func() int = counter(10)
と書くと、初期値が10のカウンタが作られる。
cnt0カウンタは呼び出される度に、1, 2, 3, , , とカウントアップし、
cnt10カウンタは呼び出される度に、11, 12, 13, , ,とカウントアップする。
★WOZ★
//コードここから
package main
import "fmt"
func counter(n int) (func() int) {
var i = n;
return func() int { i += 1; return i }
}
func main() {
var cnt0 func() int = counter(0);
var cnt10 func() int = counter(10);
fmt.Printf("%d\n", cnt0());
fmt.Printf("%d\n", cnt0());
fmt.Printf("%d\n", cnt10());
fmt.Printf("%d\n", cnt10());
fmt.Printf("%d\n", cnt0());
fmt.Printf("%d\n", cnt0());
fmt.Printf("%d\n", cnt10());
fmt.Printf("%d\n", cnt10());
}
//ここまで
| 固定リンク
| コメント (0)
| トラックバック (0)
Go言語ではクロージャを使える。
カウンタを生成するcounter関数のローカル変数iを、
無名関数（これがカウンタだ）が環境として参照する、
というコードを作ってみた。
Pythonに慣れていると、型がうるさく感じるが、
すぐ慣れて気持ちよく書ける。
★WOZ★
//コードここから
package main
import "fmt"
func counter() (func() int) {
var i = 0;
return func() int { i += 1; return i }
}
func main() {
var cnt func() int = counter();
fmt.Printf("%d\n", cnt());
fmt.Printf("%d\n", cnt());
fmt.Printf("%d\n", cnt());
}
//ここまで
| 固定リンク
| コメント (0)
| トラックバック (0)
ソフトウェア開発を混乱させる原因はたくさんあるが、よくあるものの一つが構成管理をしないことだ。
構成管理をしない人々は、もちろん構成監査もベースライン管理もしない。
これは、つまり自分が何をどこまで作ったのかを把握していないことと同じだ。
そんな人々に、なぜ構成管理をしないのかと問うと、きまって同じ答えが帰ってくる。
「それは自分たちの仕事ではない」
耳を疑うような答えだが、実際、彼らはそう信じている。
そして、案の定、バグがいつまで経ってもなくならないとか、テストができないとか、一度治ったバグがまた出てくるとか、そんな構成管理ミスに起因する問題が次々と起こり、ソフトウェア開発はどんどん混乱していくことになる。
果たしてどうすれば、彼らを救うことはできるのだろうか？
残念ながら、その答えは持ち合わせていないが、これからソフトウェア業界に入っていこうとする若い人達には、是非、構成管理を勉強してほしい。
そうすれば、ソフトウェア開発をストレスが多くて辛いことばかりにした旧世代のエンジニア達が去った後で、きっと本来のクリエイティブなソフトウェア開発に一歩近づけるに違いない。
★WOZ★
 |
Subversion実践入門第2版
販売元：楽天ブックス |
 |
実用Subversion
販売元：楽天ブックス |
| 固定リンク
| コメント (0)
| トラックバック (0)
| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
|---|---|---|---|---|---|---|
| 1 | 2 | |||||
| 3 | 4 | 5 | 6 | 7 | 8 | 9 |
| 10 | 11 | 12 | 13 | 14 | 15 | 16 |
| 17 | 18 | 19 | 20 | 21 | 22 | 23 |
| 24 | 25 | 26 | 27 | 28 | 29 | 30 |
最近のコメント