Month: July 2015

Swift:まずい!ブログのソースコードを削除。

と気がいついたときは遅いでした。

Dropboxのファイルを削除してしまいました。当面、ブログからはソースコードにアクセスできません。MS WordやExel / PDF等の個々のファイルは全部復旧しましたが、ソースコードは時間をかけてゴミ箱から復元するか、この際、全部削除してしまい、最終的なものだけをライブラリに入れるか、決めたいと思います。

ひとつだけやってみましたが、ソースコードの場合、.xcodeprojが復旧できないようですね。いずれにしても、少し数が多すぎて複雑になるので、ミスが発生する可能性もあり、これはやめることにします。

そうなると、ローカルディスクの同じフォルダ名を上書きする方法で対応した方がいいかどうか?

結論

  • これまでブログ中でリンクしたソースコードをすべてgive upする。
  • ソースコードは目次のソースコードに集約する。
  • Dropboxに新たにブログ用のソースコードフォルダと一般ファイル用のフォルダを作成し、今後はこれらから目次のソースコードにリンクをとる。
  • 既存のDropboxフォルダはそのままにし、今後は更新しない。
  • 万が一、過去のソースコードを参照したい場合、残っているフォルダ名からローカルのソースコードを探すようにする。
  • ちょっと惜しいと思われるのは、Dropbox関係のアクセスの履歴としてのソースコード。あのときはいろいろ難しかったが、多分、配列をちゃんと定義できれば、そうでもなかったのかもしれない気がする。ただし、やってみないとその考えが正しいかどうか不明。
  • ライブラリの更新は、もう少し落ち着いてからやる。できるだけ早く。

Swift:浮動小数点⇄文字列変換

整数への変換は.toInt。浮動小数点は.toFloatがあればと思いました。

  • なるほど、NSStringを使うのですね。

var wChar:String = “3.415”
var wFloart:Floart = (wChar as NSString).floatValue

  • と思っていたら、一通りではないのですね。

var wFloart:Floart = NSString(string:wChar).floatValue

  • そう言えば、以前、浮動小数点を文字列に直すとき、こんな書き方にXcodeが書き直したことを思い出しました。

wValue  += String(stringInterpolationSegment: wItem as! Float)

  • うーむ?サンプルプログラムを作って実行してみました。

1. wChar=3.415を浮動小数点に直すと、(wChar as NSString).floatValue=3.415
2. wChar=3.415を浮動小数点に直すと、NSString(string: wChar).floatValue=3.415
3. wChar=678を浮動小数点に直すと、NSString(string: wChar).floatValue=678.0
4. wChar=123を整数に直すとき、wChar.toInt()!=123
5. wChar.toInt()はwChar=123.45のとき、nilです。
6. 678を整数に直すと、Int(wFloat)=678
7. 123.45をDoubleに直すと、(wChar as NSString).doubleValue=123.45

サンプルプログラム

var wChar:String = “3.415”
var wFloat:Float = (wChar as NSString).floatValue
println(__LINE__,”1. wChar=\(wChar)を浮動小数点に直すと、(wChar as NSString).floatValue=\(wFloat)”)

wFloat = NSString(string: wChar).floatValue
println(__LINE__,”2. wChar=\(wChar)を浮動小数点に直すと、NSString(string: wChar).floatValue=\(wFloat)”)

wChar = “678”
wFloat = NSString(string: wChar).floatValue
println(__LINE__,”3. wChar=\(wChar)を浮動小数点に直すと、NSString(string: wChar).floatValue=\(wFloat)”)

wChar = “123”
var wInt:Int = wChar.toInt()!
println(__LINE__,”4. wChar=\(wChar)を整数に直すとき、wChar.toInt()!=\(wInt) “)

wChar = “123.45”
if wChar.toInt() == nil { //要注意?Floatに変換後、Intに直すべきか。
  println(__LINE__,”5. wChar.toInt()はwChar=\(wChar)のとき、nilです。”)
}

wInt    = Int(wFloat)
println(__LINE__,”6. \(wInt)を整数に直すと、Int(wFloat)=\(wInt)”)

wChar = “123.45”
var wDouble:Double = (wChar as NSString).doubleValue
println(__LINE__,”7. \(wChar)をDoubleに直すと、(wChar as NSString).doubleValue=\(wDouble)”)

参照:

String、Int、Doubleの型変換をそれぞれまとめてみた。
浮動小数点⇔文字列の変換
GitHub

Swift:整数と浮動小数点の見分け方

この方法でいいかどうはわかりませんが、・・・。

Anyobjectを文字列、整数、配列にそれぞれキャスティングする方法は先日書いた通りですが、この中で不十分だったのが整数。

整数か浮動小数点か見分ける必要があり、これは整数部分を引き算し、小数点以下だけを切り出して0でないなら浮動小数点とすることにしました。結果、この方法で問題がないことがわかりました。

また、配列はfor inで抽出したものをvalueとして利用すればいいです。ただし、これは配列が想定内のときに限られるはずで、そうでない場合、NSArrayで展開して何らかのシンタクスチェックをする必要があるかもしれません。

徒然:生きる理由、その目的?

長く生きていると、たまに「なぜ生きているのか?なんのために生きているか?」考えることがあります。

ポール・ゴーギャンは、「我々はどこから来たのか 。我々は何者か。 我々はどこへ行くのか。Where Do We Come From? What Are We? Where Are We Going?」という題のを描きました。自分の存在理由と目的を知りたいという願望は、いつの時代にも共通した、きっと避けて通れないテーマなのでしょうね。

多くの場合、明確な答えがない質問は忘れがちですし、そうすることは、どこまでも続く堂々巡りに潰れてしまうよりか、理にかなっています。何日か、何ヶ月か、場合によっては何年も忘却したまま生きてしまうのはあり得ることです。テーマ(命題)に対して答えが明確でないので、ついつい横に置いてそのままになってしまうのは、仕方ありません。

年を取り老い先が短くなってしまうと、そうしたつまらないことをあれこれ考えたり、思い出したりします。

振り返ってみると、結局、17歳の頃に思い浮かべたものと実際の人生は全く違ったものになってしまいました。こんなはずではなかったというよりか、想像さえしないものになってしまったのです。良し悪しの判断は自分にはできませんが、何事にも夢中になって向かって行ったのは、きっとそれが楽しかったからでしょう。何回か、もうそれ以上ついていけない思いがしてきて、投げたこともありましたが、それは保身とか保全という意味で良いことだった気がします。

今は先が閉ざされていることが感覚的にかなり明瞭に理解できます。そして、自分にできそうなことの限界もおのずから浮かび上がります。それだけに、ひとは何かするために生まれてきたのでも、何か理由があって生きているのでもないような気がしてなりません。個々の成功や失敗はとても小さな事象で、それ自体には、たいして意味や価値はなく、生きるエネルギーとは関係ないように思われます。

Swift:設計ミス

配列のデータ構造の持ち方を変更しました。

そもそもという話をすると、配列に定義してあるキーワードと一致したとき、そのvalueによって個々の変換が必要なとき、3次元配列にするとreadのアクセスは問題ないのですが、writeのアクセスが発生する場合、処理が面倒になるので、変換テーブルだけを別の配列で定義していました。

しかし、これだとやたらとif文によって判別する処理が出てくるため、行数も増え煩雑になってしまいます。それで、処理の種類は、①変換しない、②プログラムによる変換、③変換テーブルによる変換、④キー不一致で変換しないの4種類らしいということはわかっていたので、3次元配列(NSArray)に変更し、処理の種類を入れ込むことにしました。

let trArrayCGI:NSArray  = [  
 [“Int”,  “😄”, “ColorModel”,  “色空間”, “”, [ ]],
 [“Int”,  “😄”, “PixelWidth”,   “画像横幅(ピクセル)”, “”, [ ]],
 [“Int”,  “😄”, “PixelHeight”,  “画像高さ(ピクセル)”, “”, [ ]],  
 [“Int”,  “😄”, “Orientation”,  “画像方向”, “”, [  
    [“1”, “1: Horizontal (Normal)”, “1: 水平 (ノーマル)”],  
    [“2”, “2: Mirror Horizontal”,    “2: 左右反転”]

これは基本設計レベルの大きな方針変更であり、修正に2日間を要しました。しかし、休み休み慎重にやったので、ほとんど問題なく動きました。ライン数が減り、プログラムが単純化できました。

それでも、まだ腑に落ちない問題は、入力辞書を読み込み、キーを.keyで取り出したあと、.valueの取り出しのとき、データ型がAnyobject相当で不明であることにより型変換エラーが起こさないで取り出す方法がわからないことでした。文字列か数値または浮動小数点か、配列のいずれかなのですが、それを知る方法がわからなかったのです。もちろんworkaroundとして”\(wItem.value)”のような表現で文字列化できていたので、決定的なクリティカルイッシューではないのですが、何となく嫌な感じでした。

しかし、これは意外と単純で、たとえば配列かどうかはif (pInDic[cm.rcKey] as? NSArray) == nil(pInDic辞書の中のcm.rcKeyのvalueはnilか)のように聞き、nilでないなら配列、nilなら文字列か数値とすればいいことがわかりました。

 if wItem.value as? String != nil {
   cm.rcValue  = wItem.value as! String
} else  if (pInDic[cm.rcKey] as? NSArray) == nil {  
   cm.rcValue  = String(wItem.value as! Int)

前述した通り、この処理は、元々、“\(wItem.value)”のような表現で文字列に変換していたものです。これが真っ当な方法かどうかわからなかったので、Anyobjectの型を知る方法がないか、ずっと考えていた次第です。

徒然:Apple Musicの音質?

視聴して2週間が経過しました。どうなのでしょうね?

iPod Touch/iPadとMacbook Airでトライアルしました。現時点での結論(というか設定)は、無料期間が終わったら解約です。大きな理由は、次の通り。

  • CDから落とした320kbpsと比べてApple Musicの256kbpsは音質が落ちる。
  • Apple Storeで購入した256kbpsと比べても、Apple Musicの256kbpsは音質の劣化があるのではないか?
  • よくよく考えてみると、Apple Musicをオフラインで聴けるようにした場合、同じであるべきなので、勘違いかな。

家では、AirMac〜アンプ経由にして、それなりのちゃんとしたオーディオシステム環境で聴きました。外では、オフラインで聴けるようにしたiPod Touch/Shure535イヤホン。Apple Musicはどちらも音がキンキンしているような気がします。「気がする」だけならいいのですが、本当のところはどうなのでしょうか。

「通信の最適化」の影響を受けているのでしょうか?同じ256kbpsで違いが出るとしたら、少し不思議な気がします。どこかでパケットロスでも起きているのかなあ・・・。ストリーミングならそういう可能性もあるでしょうが、オフラインの場合、どう理解すればいいのでしょう。

だいぶ残念。

Swift:力仕事

辞書の翻訳とバリューの変換を進めています。

現在、次の辞書に英語・日本語の両方の対応をすませました。

  • Exif
  • ExifAux
  • GPS
  • IPTC
  • TIFF
  • JFIF
  • Canon
  • Nikon

pictとgifは辞書・変換テーブルは用意しましたが、ニーズが少し違うような気もするので対応しないかもしれません。検証もだいぶすみました。多分、もうだいじょうぶかな、という感じです。

ExifはJEITAの仕様が公開されているので、それを参照しました。購入すると15,000円。日本語版と英語版があります。30,000円の支出は大きいので、ネットで探しました。

何点か、この訳でいいのかと疑わしいものがあります。

今週中には、ディベロッパー契約をしてPhotosと地図の実装に着手したいものです。

徒然:学級崩壊

Exif情報の変換を順次進めています。その一方で、学級崩壊とはこういうことを意味しているのだろうなあ、と思ったりしています。

国会議員は採決拒否をしても賃金カットはないのでしょう?とてもいい身分です。これは身分保障の見本みたいなものです。

衆院平和安全法制特別委員会で「強行採決反対!!」「安部政治を許さない」「自民党感じ悪いよね」などのプラカードを掲げて大声を出している姿は、学級崩壊を思い出させました。それが仮に戦術的に正しかったとしても、野党で過半数を確保できないから採決拒否するというのでは、反対票を投じる活動をしなかったという一点が賛成の側に与したのと同じとみなされても言い訳ができません。また、審議内容と関係のないことをTV放映を見込んで主張しているようでは、日本の政治は半世紀前と似たり寄ったりです。

民主党は自分たちが政治不信を作り出したことを忘れて、こうした場所を利用して、次の選挙の準備しているのでしょうか?そうならとても不真面目です。そうでなくてもなんでも反対の結果に対して無力あるいは無責任な政党と思われても、仕方ありません。

ちゃんと自民党政権に反対できないことが野党の問題です。学級崩壊をさせているのはだれか?自分たちだと再認識しなければ、自民党政権に対してきちんとした対抗策が打てないのでしょうね。国会議員が国会で「強行採決反対!!」「安部政治を許さない」「自民党感じ悪いよね」などのプラカードを掲げているようでは世も末です。

もう少しちゃんとした野党がいないと日本も世の末!!やれやれ。

(追記)東京新聞のコラムニスト長谷川幸洋氏は、プラカードを掲げて反対する様子を三文芝居と揶揄しています。長谷川幸洋氏がどんな方が存じ上げませんが、本気で反対するつもりならみんなして国会議員辞職して抵抗するべきだというのは、もっともな気がします。

プラカードを掲げるぐらいなら、議員辞職せよ
国民を裏切ったのは政府ではなくお粗末な野党だ(長谷川幸洋氏)