So-net無料ブログ作成
プログラミング ブログトップ
前の10件 | -

ChatBotはプログラミング初心者向けだといっていたけれど [プログラミング]

Watson Conversationを使っていてバグとか不具合が多すぎて辟易する。日本語の紹介ページもUIが前のバージョンのものだったりして、中身的には大きな変わりはないのだろうけど、GUIでプログラミングするとなると見た目が変わると結構クリティカルな感じ。IBMダイナミックにものを変えすぎ。

DialogのNodeを作るのはいいが、部分的に機能が動かなかったりして、ロジックミスかなと思っていたら、Nodeを作り直すとすんなり動いたりする。立ち上げなおしてみると直ったりもするので、Webアプリってのも面倒なものだなと思う。単なるIBMが悪いだけなのかも。自分は試行錯誤して動かすほうなので、挙動が一貫していないと非常にやりにくい。GUIだとConversation自体がデバッグしにくいのだろうが、それにしても問題が多すぎる。同じことをしてもいい時とダメな時があるのは開発環境としてはすごく痛い。

問題が起こるのに大きく寄与しているのは、動作している時に変更をアプライしても動いてしまうことだろう。挙動を変更したのを確認するのにはいいのだが、正直それがきちんとストアされて実行されるのかが見えないため、右側に出てくるデバッグ環境をお守り程度に立ち上げなおしたりクリアしたりするのが関の山だったりする。基本、勝手に保存したり、実行に移す時にアプライしたりしてくれているので、お手軽といえばお手軽なのだが、正直他の環境で慣れたものとしては気持ちが悪い。インタプリタだってファイルを保存する過程はあるからね。

確かにGUIでプログラムロジックを組めるという点に於いて、初心者向きというのはわかる。挙動もすぐに確認できるし、自分が設定したintentsやentitiesがすぐにサジェストされるのは連携づけるのに非常に楽で、一見お気楽にプログラミングできるように見える。

簡単にプログラミングできますよ、みたいなことをよく書かれているんですが、従来のテキストをゴリゴリ書くプログラミングとは違ってGUIで操作できます。そこまではいいですが、一度変数なんかを使おうとするとJSONのテキストをゴリゴリいじらないといけなくなります。GUIで簡単にロジックが組めるだけに、プログラミングに必須な変数(Contextとか言ったかな?)を使うだけで一気に敷居が高くなる気がしています。実際、他のノンプログラマーの人に引き継ぐのを考えて変数は使うのをやめました。

あと、AIだなんだと言っていますが、ボットの作り自体は人工無脳と大した違いはないですよ。何を受け取って何を返すかってのが、流れとしてGUIで組んで記述するだけで、大枠としては人工知能は機能していません。まぁBotですからねぇ。んで、AIが使われている部分ってのは、人間が受け答えた文を判別するところぐらいです。少しぐらいの表記の揺れなら大丈夫ってところに持って行けるだけでもすごいと思いますけどね。

ただそこの表記の揺れもある程度人間が例を挙げていってあげて、Intentsに登録する形になっているんですね。簡易的な学習はそこでされるんですが、そこは自動でやってくれるというのには程遠いです。とはいえ、ディープラーニングだって適切な学習素材がないと判別率とか上がらないわけですし、そこらへんは人間の意図が関わって学習させた方がむしろいいのでしょう。ユーザーに任せてほっとくと口が悪いボットができてしまいかねないですし。

流れに沿って調べるくらいなら、FAQを検索した方が早いという人もほとんどなんでしょうが、量が多かったり初歩的な質問だったり、普段質問しにくいことだったりする場合には、ボットも悪くはないのかもしれません。FAQ探すのめんどいし、ページ一枚にたくさん貼られていると文字検索でヒットはしやすくても、全体から探すという手間自体は目視でやっているとしんどいし。かといって、細かくカテゴリ分けされていると検索がほとんど効かないというのもあるんでしょうけどね。

というわけで、エセAIというか似非人工知能のチャットボットですが、つまらない(とオペレーターが思う)質問を自動でしてくれる機械は、大規模に質問された項目が蓄積されている場合は、非常に楽に移行できそうだなという気はしています。自然言語の理解というところについては、擬似的にとはいえ大体のケースに合うように作ることもできますし、どこかで方言でさえバリエーションに入れられると書かれているところもありました。まぁそこの方言にもよるんでしょうけども、対面回答式の人間の答えのバリエーションの広さを考えると、そこだけ人工知能を使っていたとしても悪いものではないのかもなと思えてきました。

ただ、Webページでのパンくずリストを作らなきゃならないほどのカテゴリのネストがあると、自由に質問できなくなる傾向にあるので、ある程度質問を絞りつつも質問をフラットに受け入れる必要があります。そこは面倒ですね。でも、一般のテレフォンオペレーターにしても、初めにカテゴリの選択で数を選んだりするので、そこのところは一度区切ってあげた方がいいのかもしれません。ただ人間だとそこで間違えて選択しても別の部署に回してくれたりはするんでしょうから、そういう機能まで分岐させた後に入れようとするとしんどい気はします。だったら最初から全部質問をフラットに受け入れてしまえという話になってくるんだと思います。

いちいち人に聞くまでもないことかもしれないけど、ちょっと確認はしておきたいなという事項には効くかな。実際テレオペの人は半分はそういう確認の電話の対応なんだろうし、逆にめっちゃ難しくてマイナーな事象を挙げられても困るわけで。ただボットの作りによってはイライラしかねないなとは思う。それは人によってだろうけど、あまりに離れた答えとか質問の単語がそもそも登録されてないとか、作りが粗雑だとFAQ以下の存在となりかねないよな。


Watson CoversationというかNode-REDの仕様かなんか知らないけど、JUMPというのはgoto文を彷彿とさせてちょっと嫌な感じがしました。そもそもボット程度のロジックでスパゲティプログラミングになる恐れは少ないのだろうけど、やっぱりgoto分は使うなと言われてきた世代としては気持ち悪い。例外処理は許せてもJUMP TOとかは許容しがたいなと。

ともあれ構造的に任意に飛ばす方法ってのは作りにくいから仕方ないのかもね。自分たちでJump toを使うタイミングを抑制して計画的に使うのがいいと思います。そうじゃないと色んなところに飛んで保守性が悪くなる。まぁ仕組み的にはそこまで複雑になることはないなと思ってたりもする。そこまでネストが深いチャットボットなんて使いたくないなw。

コメント(0) 
共通テーマ:パソコン・インターネット

MSのOSSの歩み寄りがちょっと気持ち悪い [プログラミング]

GitHubへの貢献(?)が一番多いというベンダがマイクロソフトらしい。自前でコードリポジトリを立てていたらしいがCodePlexはおしまいという事らしい。

http://www.atmarkit.co.jp/ait/articles/1707/18/news003.html

MSの事だからWindowsとOSSのブリッジ部分ぐらいなんじゃと思っていたけれども、それは今は昔みたいだ。とはいえ、自社の.NETのCore部分だとかオレオレ的なものが多いのは当然な事だったりする。そのうちWindowsまでOSSにしてしまうんじゃないかという勢いだけど、それはないだろうなぁ。あっても盛り上がるのは最初の時だけで、色々制限が出てきてウンザリして去ってしまうのだ。AppleのDarwinしかり、SunのOpenSolarisしかりである。

ともあれ以前言ったようにパソコンが仕事の道具と化して、開発者が使うものになっていくことから考えると、MSのOSS戦略は理にかなったものとなっています。思えばBash on WindowsもLinuxと親和性を高めるために必要な技術で、中途半端にPythonが使えますよとかやっているよりか、仮想化をしなくてもLinuxが使えますよという風に人を呼び込んだ方がいいと思ったんだろう。何にしろ、WindowsにOSSをローカライズするのが面倒なんだろう。元がアップデートしたらそれに合わせてWindows用のパッチを当てるとかいたちごっこもいいところだ。

それと外向きのサーバのWebアプリでMSのソフトを使うってのは自殺行為に近いんじゃないだろうか。他のOSSにしても脆弱性はたくさん見つかるわけだけども、IISを好んで今も使っているっていうのはあまりないんじゃなかろうか。あれだけ問題起こしたもんね。企業で内向きに作るとして脆弱性はあまり考えなくて良いにしても、IE6あたりの非互換性も嫌な思いをした人も多いだろう。あえてASP.NET、IIS、IEの組み合わせで作りたいと思う人も少なくなったと思う。今はOSSもお手軽に使えるようになったので、わざわざWindows上で動かそうという気にならないんじゃなかろうか。

そのわりにはSQL Serverとか人気があるんだよな。というか、Oracle嫌いでサポートは欲しいユーザー企業の受け皿になっている気がするんだよね。調子に乗ってSQLServerをLinuxでサポートするとかやってた気がする。無理やりよくやるなぁとは思うけれども、需要があると見込んだからには頑張って売るんだろうな。どうでもいいけどSQL Serverという名前も直球すぎて他のRDBも大抵はSQLなSeverじゃねぇのという状態ではあったりする。

AzureでOSSを動かすとか言っていろいろやっているみたいなんだけど、実際どこまで本気で使われているんだろうかと不安に駆られてしまう。別に不安になる必要はないんだけど、騙くらかされてAzureでOSSとかコンテナとかやっちゃうユーザー企業が出てきそうでならないんだよね。

Office365を無理やり使わされたユーザー企業に居たことがあるんだけど、新機能を無理やり導入させられていたもんな。メリットはないわけじゃないんだけど、普通はそういう運用はしたくないなぁということをやっていた。そのうち、運用でもうちっとマシになりそうな気はしたが、そこまで強く引っ張ってくれるベンダーじゃなかったし、いい実験場にされていた感じ。というか、もう事務作業なんて枯れていていい時期なのに、イノベーションとか何とかそそのかされてやっちゃったんだろうな。

バージョン管理のサーバをやめてGitHubにしてください、って言っちゃう企業にOfficeの新しく使える機能なんて自ら作れるわけがない。新しくExcel関数を増やして過去との非互換性を作るのが関の山だ。まぁMSなんて誰かが作ってくれた市場を押しつぶして占有することしか能がない会社だから、こんどはOSSだとぐらいしか思えないんだよね。まぁOSSにしてもMSに全てやられるほど懐が浅いわけじゃないし、どう頑張ってもMSにはたどり着けない場所に行ってしまっているわけで。

ただクライアントOSとしてのWindowsは悪くはないと思うよ。Windows10のゴリ押しには辟易したけれど、お手軽にパソコンを使えるという点においては、Linuxの出る幕ではない。よくDesktop Linuxで古いマシンも使えるなんて初心者に向けてやっていたけれど、何か問題が起きてもきちんとフィックスしてくれるわけでもないしね。多くは自分でやれで終わり。そんなもの多くの人が使うはずがない。確かにWebアプリも増えて、Firefoxが入っていればWindowsやMacと同等のことができる。でも、それ以上でもそれ以下でもないんだよね。昔よりか改善した程度。少しずつ良くなってきているとは思うけど、Windowsでさえ手こずる人間がいる中で、普及するかといえば見ての通りで。まぁトラブルがなければLibreOfficeもあるし使えないことはない。


MacもiPhoneやiPadの台頭でシェアを伸ばしてきているらしいけど、教育現場ではChromebookとかに食われてトントンな感じじゃなかろうか。日本の教育現場はどうなんだろうか知らんが。もはやMacBook Airが出てきた時のような飛び付き方はしない。実際、食指が動く製品はないし。少なくともmacOS方面では期待はしていない。というか一時期iOS以外は完全に見放していたからなぁ。Mac miniとかMac Proとか死に体の状態の製品があるわけだし。

まぁ伸び代としてmacOSには見込みがない上に、iOS用アプリ製造機の様相を呈してきているわけだしなぁ。UNIX的なCUIのところも、Win10のBash on Windowsであまり目立つ良い点ではなくなってしまっているし。最近やっとAPFSが本格導入されるぐらいで、良い話があるわけではない。クリエイティブ系が良いなんて話はとうの昔に去ってしまったしねぇ。悪いわけじゃないけど、良い話もない。特にハードウェア的にいい話が全くない。それはWindowsも似たり寄ったりだけれども、ほぼアーキテクチャが同じになってしまったのだから仕方あるまい。

Intelのノート用の低TDPのCPUが4コアまで増えたのはいいことかな。最近のMacはうすうす傾向だし、使えるCPUが速くなる。またCPUの対応がほったらかしにならなければいいのだけれど…。MSの話で言えばXamarinかな。興味も仕事もないからあんまり知らないのだけれど、クロスプラットホームというのはかなり難しい話ではあるよね。Webブラウザなんかはよく成り立っているなと思うんだけれど、パクリパクられしているうちにデスクトップOSは均一化してしまったのかもしれない。

そういやGolangなんかはクラスプラットフォームを前提に作られていた。クロスコンパイルも普通にできるし、初めからそういう仕掛けを作っている言語っていうのも今時なのかもしれない。というか、あまりプラットフォームに縛られていると普及に足かせとなりかねないしね。とはいえ、その実力はワーム作りぐらいにしか役に立っていなさそうだ。

MSにしてもWindowsだけに軸足を埋めているわけにはいかないらしく、危機感を持ってOSSに進出しているのだろう。AppleもSwiftを渋々OSSにしたわけだし。そのわりには、主要部分が普通に使えるぐらいにしか整備はしてくれていない模様でした。あんなにいろんなところが工事中だったらOSSとして使えないよ。Goと共にコンパイル言語の新二大巨頭になって欲しいのに。結局、SwiftはiOS開発用として終わってしまうのだろうか。あんなにOSSにしてくれと騒いだ割には外部コミュニティが活発に活動しているという感じではないし。まだC#のMonoの方が物になっている。実際Xamarinに発展したわけだし、Swiftもそのくらいには頑張って欲しいところです。

ただApple系のOSSはMacPortsを見るにつけ腐っていると言わざるを得ませんでした。ガンガン不具合報告が上がってきているのに解決済みと言うばかりで、問題があるから言っているのにわけがわからない状態でした。まぁHomeBrewがあったからいいものの、MacPortsって元Apple社関係の人がやってたんでしょ? あれはいただけなかった。あんなものコミュニティでも何でもないでしょ。使う人のレベルが低かったにしてもあそこまで酷くはならないんじゃないかな。

Open Darwinもあったんですか的にポシャってるし。結局、商業的な会社がOSSに中途半端に手を出すとそういうことになるってことですよね。MSはガチできている気はするのですが、どこかで踏み込めないんじゃないかと思っています。そもそもGPLとか商用とは水と油のようなものだし。実際、GPL汚染とまで言われてしまっている。GPLの効力をわからずに使っちゃったからいけないんだけどね。Ciscoとか散々痛い目にあったんだろうと思うのだけれど。でも、その程度で揺らぐようなちゃちな会社じゃないよね。どこに行ってもガンガンに使われているし。


ただIron Python頃のMSとは違うOSSへのアプローチをしているなという感じはする。それがMSにとって最良のことなのかどうかはわからないけど、技術者にとってはOSSへの選択肢が広がることはいいことなんじゃなかろうか。ちょっとしたツールを使うためだけでもBash on Windowsを使ってみるというだけでも、全体のリテラシーを上げる一助になろうものだ。というか、いちいちLinuxも使えない学生を一から鍛えるとか面倒くさすぎる。

わざわざLinuxを仮想環境でインストールする手間をかけたくない人でもお手軽にできる環境というのは今時は必要じゃないかと思うのだ。また前世紀終了時頃のLinuxインストールブームを起こすことなんてできないし、無理強いしてやるものでもなかろうと。ただ単にaptでHTTPDを入れて立ち上げてアクセスするだけでも、初めの頃は俺ってすげえ感は味わえると思うんだよね。スマホで足りてくる世の中では、パソコンで開発しようとする割合も減ってくるだろうし。Webは誰かが提供してくれるものだけじゃなくて、自分で作り出せるものなんだと自分の手で早めに確信して欲しい。


コメント(0) 
共通テーマ:パソコン・インターネット

Golangの分からないところ。 [プログラミング]

Golang tourより
https://go-tour-jp.appspot.com/moretypes/16

package main

import "fmt"
import "math"

var pow = []int{1, 2, 4, 8, 16, 32, 64, 128}

func main() {
    for i, v := range pow {
        fmt.Print(math.Exp2(float64(i)))
        fmt.Print(2 ** i)
//        fmt.Print(2 ** float64(i))
        fmt.Printf(" 2**%d = %d\n", i, v)
    }
}

fmt.Print(2 ** i)
でやると

invalid indirect of i (type int)
というエラーが出てしまう。そもそも**演算子が機能していないのではないかと思ってしまう。

float64にキャストしてもダメだし、書き方自体存在する意味があるのか。
そもそも**演算子がないのかも。なかった…。まぁC言語にもないしな、演算子では。
しかし、Golangの動作側としては何を意図していると仮定されているのだろうか。
そもそもない演算子だから、そこでエラーを出して欲しいんだけど。



package main

import "fmt"

func main() {
	pow := make([]int, 10)
	for i := range pow {
		pow[i] = 1 << uint(i) // == 2**i
	}
	for _, value := range pow {
		fmt.Printf("%d\n", value)
	}
	fmt.Print(pow)
}


あぁ2の累乗だったらシフト演算で足りるか…。


別の話。Goで再帰関数を使ってたらしばらくしたら破綻した。Webをクロールして二日間ぐらいだったから、そりゃスタックも尽きるよというところで。
別にスタックオーバーフローの実験をしたわけではありません。
コード的に面倒なので手を抜いただけですw。


こんなん出ました。ahrefというのが再帰した関数です。こうやって落ちる。

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x40 pc=0x627afc]
                                                              
goroutine 1 [running]:                                        
main.getfile(0xc4274aa900, 0x60, 0xc4204b2900, 0x16)          
        /home/hogehoge/rwget.go:66 +0x4c                      
main.ahref(0xc426354000, 0x36fd6, 0x3b2aa, 0xc420120f50, 0x6e)
        /home/hogehoge/rwget.go:118 +0x469                    
main.ahref(0xc426354000, 0x36fce, 0x3b2aa, 0xc4205dcc00, 0x38)
        /home/hogehoge/rwget.go:130 +0x8a5                    
main.ahref(0xc426354000, 0x36fcd, 0x3b2aa, 0xc4205dc980, 0x40)
        /home/hogehoge/rwget.go:130 +0x8a5                    
main.ahref(0xc426354000, 0x36fcc, 0x3b2aa, 0xc4205dc800, 0x3e)
        /home/hogehoge/rwget.go:130 +0x8a5                    
main.ahref(0xc426354000, 0x36fca, 0x3b2aa, 0xc4205dc740, 0x3f)
        /home/hogehoge/rwget.go:130 +0x8a5                    
main.ahref(0xc426354000, 0x36fc8, 0x3b2aa, 0xc4205dc680, 0x3b)
        /home/hogehoge/rwget.go:130 +0x8a5                    
main.ahref(0xc426354000, 0x36fc7, 0x3b2aa, 0xc4202b05f0, 0x4a)
        /home/hogehoge/rwget.go:130 +0x8a5                    
main.ahref(0xc426354000, 0x36fc3, 0x3b2aa, 0xc4205dc180, 0x39)
        /home/hogehoge/rwget.go:130 +0x8a5                    
main.ahref(0xc426354000, 0x36fc2, 0x3b2aa, 0xc4205cc1c0, 0x36)
        /home/hogehoge/rwget.go:130 +0x8a5                    
main.ahref(0xc426354000, 0x36fc1, 0x3b2aa, 0xc420ca23c0, 0x4f)
        /home/hogehoge/rwget.go:130 +0x8a5                    
main.ahref(0xc426354000, 0x36fbf, 0x3b2aa, 0xc4201e4460, 0x67)
        /home/hogehoge/rwget.go:130 +0x8a5                    
main.ahref(0xc426354000, 0x36fbd, 0x3b2aa, 0xc420138690, 0x46)
        /home/hogehoge/rwget.go:130 +0x8a5                    
main.ahref(0xc426354000, 0x36fbc, 0x3b2aa, 0xc420c77650, 0x67)

以下続く。


そもそもGoは再帰関数が得意ではないという話です。
http://ymotongpoo.hatenablog.com/entry/2015/02/23/165341
何回も動作させたい時には関数内で再帰させずに、ループとかで一回関数を終わらせてまた動作させるなり制御しましょうねということなんだろう。

まぁ別に再帰を使わなくていいところで面倒がってやったので、帰り値で戻して再度パラメーターに入れればいいだけの話だったりするわけですが、思いのほか再帰が使いにくいということに気づきました。小さい遅いではメリットないですよね。

今回のサイズとかは良く分からんのだけれど1200回以上再帰した所で死んでいる模様。
どのくらいの大きさのものをどれくらい積めるのかは良くわかんないんだけど、戻るポインタの値だけを記憶していたとしてもやっぱ1000以上は多いのか。Goルーチンをポコポコ作れるようにスタックは小さめに作ってあるらしいが一般的にスタックってどうやってどれだけ確保されてるんだろうね。Golangのメモリ操作がどうなっているかいまいち分かっていない。

最後にいっぺんにログを吐くように作ってあるのだけれど、途中で止まってるので中途半端なものすらない状態だったり。でも、いちいちログに一行ずつ書くのもパフォーマンス的にはなぁ。ファイルを開けっ放しでちまちま書き込むのも、開けたり閉じたりするのも嫌な感じなんだけど。Goのファイルの操作を調べて、ちょっと考えてみよう。


Goのチュートリアルの問題ってググると正解が結構出てくるのね。というか、あまり初心者向けの問題じゃない気がするんだけど、他の言語を知っている人にとってはGolangを知るにはいい機会なのかもしれないけど、ちょっと深掘りしないとわからない問題が多くて困る。なのでチートして終わりにしておく。

タグ:Golang
コメント(0) 
共通テーマ:パソコン・インターネット

CSRFを今更ながらお勉強 [プログラミング]

いまいち分からなかったんだけど分かるまで読んでわかった。CSIRTの話でCSRFの話が出てきて、XSSとかはなんとなくしっとるけどCSRFは良く分かっていなかったなと思い出し、ググって理解した。まぁ今はCSRFもサイトが対応して出来ないようにはなっているのだろう。

そういや、猫に証拠をつけて結局見つかってしまった犯罪者がいたが、あれはCSRFを使って第三者に掲示板に書かせたんじゃなかったっけかな。そいつがつかまって終わったのだけれど、悪いのは誤認逮捕した警察と、CSRFの脆弱性を作っていたサイトの運営者じゃないかと思う。その後、警察とサイトの運営者を相手取って訴訟したって話は聞かないけれど、アメリカだったら確実に金を取りにいく事象だと思ったりする。

https://ja.wikipedia.org/wiki/%E3%83%91%E3%82%BD%E3%82%B3%E3%83%B3%E9%81%A0%E9%9A%94%E6%93%8D%E4%BD%9C%E4%BA%8B%E4%BB%B6

ん~CSRFというよりワームの感染だな。C#で書いてあって書けないとかいっていて、書けましたと自白したんだけど、出来合いのものなど使って実際コーディングしたのは少しだろうから、書けませんというのもあながち嘘ではないのかもしれない。まぁ一からスクラッチは出来ません、という意味の書けませんですが。

CSRFが可能だったサイト以外はワームの仕業ということになろうが、IPアドレスだけを頼りにしていた安易な捜査はあからさまにIT音痴を露呈させたといえるだろう。そういう意味では、警察を相手取って訴訟ということも出来なくはないだろうが、他の冤罪も無罪になっても実質的に泣き寝入りになっていることからも、官憲にたてついても無駄だと言われているのも同じだ。完全に冤罪をなくすことは出来なくても断罪できないというのは、冤罪を許す温床になっている。

ITをイット呼ばわりした森元総理だが、オリンピックでサイバー犯罪を危惧しているようなことを言っていた。元総理は中身を分かっての発言ではないことは容易にわかるが、実際サイバー攻撃でかく乱されることは創造に難くない。にしてもCSRFで意図しないで加害者になるのは勘弁して欲しいものである。わけわからんURLが張ってあるスパムメールとかたくさんあるもんなぁ。


話はCSIRTに戻りますが、CSIRTを構築しないといけない友達がいて、色々ググってみたものの明確なノウハウとかは出てこない感じでした。まぁセキュリティインシデントをどう管理して報告するかという話なんだけれども、まぁ攻撃に対する対策ってのも面倒くさいよねというところで。

https://www.jpcert.or.jp/

・フィッシングサイト
・Webサイト改ざん
・マルウエアサイト
・スキャン
・DoS/DDoS
・制御システム関連
・標的型攻撃

の報告が主になるようだけど、スキャンの話だとアクセスログを見るしかないよなとか、フィッシングサイトとかマルウェアサイトとかは通報するしかないよなとか、色々考えましたが実際に何使うんだか良く分からないので適当にうっちゃって終わりにしました。

プログラマ的に面白いなと思ったのは、
https://www.jpcert.or.jp/research/materials.html
こういう情報ってわりと少ないんだよね。あるのかもしれないけど、バッドノウハウとして累積されたものがあるかといえば、そんなになかったりしたり。

世の中、動きゃいいって節があるから、テクニカルの更に先にあるセキュアなところってのはおざなりにされる。実際MSやAdobeの例があるしね。Oracleでもいいけど、長くソフトウェア業界に君臨していれば何かしらあるわけで。

結局、一番多いのが文字列のバッファオーバーフローかよというオチだったりするわけですが、C言語なんて長々と使っているからプリミティブなプログラマ任せの方法しか取れないんだよね。まぁWebシステムをガチでC言語だけで組むということはないにしても、C言語で作られたツールを使うことはあるわけで、セキュアな脅威は言語レベルで存在してしまうという状態ではあります。

まぁC言語は組み込みから使える言語だから、自分で全部制御してどうにかする文化があるといえばあるんだけど、そろそろパソコンサーバのツールはスクラッチするものはC言語以外で書いたほうがいいんじゃないかと思うんだけどね。そこまでメモリの消費量を気にしたり、メモリを細かくいじったりすることってのも正直なくなってきているとは思うんだけども。

正直、文字列の長さなんていちいち文字数を気にしていられっか、と。大抵の言語はstring型があるので、標準ライブラリに問題がない限りはそこが脆弱性につながることはないと思われ。あったとしても一気にふさがれるので他の言語で気にしないといけないことってのは少ないかもですね。

ここでNTBSという言葉が出てきたんだけど、Null-Terminated Byte Stringの略でした。別にこんな言い方しなくてもC言語の文字列と言えばいいだけの話だと思う。まぁ\0で終わるよという話です。そのヌル文字で翻弄されるわけですが面倒ですね。

結局、強制的に文字列の配列の最後にヌル文字を入れるとか、そもそも
用意したバッファより大きいものはコピーしないとか、ヌル文字のために
文字列を一文字引いた長さにするとか、そういう対策になるらしい。
まぁいちいちチェックするのは面倒くさいよね。


C#やったんだけどWPFってすごいメモリ食うんだね。まぁGUIはそこそこメモリ食いなのは仕方がないけど、スケルトンのプロジェクト実行するだけでも100MB弱メモリを消費していた。昔はそれほどメモリを消費していなかった気がするんだけどなぁ。.NETはみんなこんなんだろうか。

コメント(0) 
共通テーマ:パソコン・インターネット

最近停滞中。C#今頃やって見た [プログラミング]

というか、半年ぐらい停滞中なんですけどね。まぁやることがないというか、ないことはないがおおっぴらに出来ないというか。とりあえず、昼間の眠気はどうにかならないかなと思うのだけれど、慢性の病気の薬の副作用なので止めるわけにもいかず、カフェインで眠気止めをしているのはしているのだけれど、根本的な解決になっていないのであった。やっぱ何もすることがないと眠くなるよねぇ。

お盆休みに甥が来て土日がドラゴンボールの対戦で結構削られた。接待ゲームなので程よく負けないといけなくてちょっと面倒。あまりに気を抜きすぎってのもどうかと思うし、なるべく接戦に持っていこうとしているのだが、甥はあんまり気にしていない模様で勝てればいいという感じ。まぁまだ小学生低学年だもんなぁ。

友達がC#をやろうとか何とか言う話になって、色々調べたんだけど結局VB6のツールが動かなくなったり新規開発するときにはどうするんだということになったらしい。というか、まだVB6の実行ファイル動くねんなw。まぁWin32APIも現役だと思うので、動くのも当然なのかもしれないけど、作り直すのも労力がかかるので動かなくなるまで放っておきたい気持ちも分かる。

とりあえず、Visual Studio 2017を入れているがそこそこ時間がかかる。まぁ昔から開発環境のインストールは時間がかかるものと相場が決まっている。Eclipseみたいにディレクトリをぽいと置けば済むというものでもないし、最近のEclipseは普通にインストーラで入れるのは常道か。

やっぱりプログラミングは開発環境を入れて実際に動かして何ぼなので、友達の仕事とはいえやってみないことにはあまり無責任なことは言えない。ただでさえ環境が違ってこっちでは動くのに、他では動かないということは頻繁に起こることだし、実際に動作を確かめるってのは大切な作業ではある。テストしなくたって動けばそれで足りるんだし、最低限の確認事項ではあるわな。

最近のWindowsアプリといえば.NETがデフォルトでしょうけど、UWPっていう更に広い範囲で使えるものを作れるものが出てきた。スマホでも使えますよというものなので、正直あまり期待してはいないのだが、色々なところで使うのに作り直さなくていいのは助かる。助かるが、そういう用途があるかというとまた別で、汎用性があった方がいいな程度のものであったりする。

UWPはタッチインターフェイス優先だろうから、あまり凝ったものは作りにくいだろうなとは思う。マウスと指のオペレーションは根本的に違うからねぇ。一本化できるというだけでありがたいと思うべきなんだろうけど、それが嫌だったら今までのスタイルを貫き通せばいいというだけなんでしょうけど、貫き通す.NETの資産はないしねぇ。多くの業務アプリはWebインターフェイスになっていたりするのだろうし。

更に進んだところに、.NET Coreみたいなのがあるらしい。互換性を高められそうだけれど、やっぱり基礎的な部分にとどまりそうな予感。やっぱりGUIとかが絡んでくるととたんに互換性や移植性は落ちるのが常ですし。というか、MonoだとかCoreだとかちょっと一般的にある単純すぎる名前で分かりにくい気はする。

Windows10同士はいいにしても、もうクローズに向かっているWindows7とかは気にされていないんだろうな。まぁそれも使いたい場合は前の方法によるしかないというか、そもそもUWPの範囲に入っていないんだろうな、詳しくは知らないけど。Windows7が終わる前にWindows10は安定するだろうか。ダメかもしれないけどUWPをWindows7でやってみようと思う。まぁ本番でアプリをぶち込むわけじゃないからいいや。


これを書いたり色々なことをしているうちにもう少しでVisual Studioが入りそうです。昔はCDとかのメディアで入れていたものですが、最近はみんなネット経由で帯域を贅沢に使っていますね。というか、光学メディアでリリースするよりか手間もメリットもあるんで、無料でもリリースできるようになっているんでしょうね。今でもOSインストールメディアで、そこそこでかいファイルをダウンロードしないといけなかったりするけど、それでも最低限のファイルで後は後でこまごまダウンロードというケースがほとんどだと思います。

昔はインストール中は保障しかねるので作業しないでねといわれていましたが、最近はそういう話は聞かない。作業をしてもいいよって言うダイアログが出た時代もあったけど、メニーコアが普通になった今としてはインストール中に作業を止めること自体が少ないかもね。昔は休む口実になっていたんだけど、今は少し遅くなるくらいで作業は並行してできるので厳しい世の中になりましたw。

まぁインストール作業自体、コンパイルでもしない限りはシングルスレッドで動くものだろうから、他で影響を受けるのはストレージがバンバン使われて遅く感じるくらいでしょう。メモリが潤沢であれば、少々書き込み読み込みが発生したところで、SSDであれば気にならないでしょうね。どんどん休む口実がなくなって、手を動かす時間が増えて考える時間が減っている気がするんだけどどうだろう。立ち止まって考えるってのはプログラマには結構大事だと思うんだけどな。休む言い訳としか聞こえないだろうけど。


公式サイトのチュートリアルを見てダラダラやってみている。VB6と大きく変わってはいないところもあるだろうなとは思っていたが、基本的なところはすべて変わっていたといっていいのかもしれない。C#でやったのだけれどXAMLとCSファイルが紐づいているとか、CSファイルの名前を変えるだけでXAMLのなかみをコーディングしないといけないとか、初期の部分でかなりだるい感じで、VB6の方が楽だったと感じる部分も多かったりしました。

大まかなインターフェイスは似ていて、設計図のダイアログのボタンをダブルクリックすると、コーディング部分に飛ぶとかは基本的に同じで、良くも悪くも変わっていません。そういうところまでは変えていないけれど、内部的なところは全然変わっている感じ。

まぁVB6自体が前世紀の遺物なわけで、時間がかなり経っている時点で変わっていて当然なのですが、.NETだからといってわけの分からないほどには変わっていないのではないかと思いました。VB6にあたるWin32APIぐらいの深さを探ると面倒も出てきそうですが、基本的に既存のAPIは.NETのツリー上に存在するんでしょうし、前できたことはできるというのが普通だと思ってはいます。無くても何らかの代替案はあるんでしょうし、Deprecatedになっていたとしても何とかはなるんでしょう。

やってはみたものの特に与えられた御題があるわけでもないので、暇をつぶすだけで本人的には実害がないです。友達の会社で問題になるかもという爆弾なだけで、VB6アプリがWindowsプラットフォーム上で動き続ける限り問題ありません。というか問題があっても自分には関係ないのでお気軽に検証してみただけです。

その前にVB6だからVB.NETにすべきかとか、マイグレーションツールは上手く動くものなのかとか、色々考えることがあったのだけれど、一般的な傾向でC#でやるのがいいのだろうという方向にはなっています。人的リソースが少ないのであまりマンパワーをかけたり冒険ができないところなので、なるべく移行における被害が出ないようにしないといけないわけです。まぁ作った人がずっといるとは限らないからねぇ。いなくなっても他に保守する人がいればいいけど、そういうわけでもないしなぁ。マイグレーションってのはどこに行っても頭の痛い問題だったりします。

ただVB6のサポートが終わると言われてから、10年近くは経っていると思うので、案外ずっと使い続けられそうかもなと思ったりもします。ほとんどが64bitOSになった今でもWin32がなくなるわけでもないですし、代替となるプラットフォームがいつまでも磐石とはいえないですしね。まぁあっさりきられるテクノロジーもあるわけですが、メジャーなところだと文句が出まくるので、何とか延命される運命にはあるようです。現在のWindows10でもランタイムがあって動くようですが、どこまで延命されることか…。

ただ、あまりに延命されるとほぼ作り直しという面倒が待っているので、いい加減のところで舵を切ってもらわないと結局みんなが困るという状態になるんだろうなと思ったりします。IE6あたりでの切り替えの問題のように、それだけでもインパクトがあったので相当ソフトランディングさせないと厳しいとは思いますがね。

コメント(0) 
共通テーマ:パソコン・インターネット

あんまり進捗がないHandbrakeでのNVENC組み込み [プログラミング]

NVENCのNvEncoderをHandbrakeに組み込めばお気楽に使えるんじゃないかと思って色々やっているんですが、なかなかうまくいかず。まぁそんなもんだよなぁ。でも、先行でQSVが実装されているので、それを利用すれば良い感じ。結構色々流用できそうな様子。というわけで、色々パクって色々コピペで済ませたいw。

EVNECは生のYUVを変換しているのだけれど、Handbrakeは生のYUVファイルは変換できなかった。できたとしたら、もうそのまま突っ込んでMP4コンテナに乗せるだけなんだけどな。とりあえずHandbrake側のYUVの変換部分と、NVENCの擦り合わせはある程度行わないといけないみたい。まぁ大体はYUV420ベースの扱いが多いので、色々何とかなるだろう。

そもそもNvEncoderでh.265に変換できるんだけど、MP4コンテナに載せない生の状態のH.265なので、MP4BOXで変換できるかどうかを調べておきたい。MP4Box -add test hoge.mp4でエラーが出た。

[MPEG-2 TS] TS Packet 968 does not start with sync marker
[Importer] Unknown input file type for "test"

とか出てくるんだけど、返還前のファイルの拡張子を.hevcにリネームしたら問題なくmp4ファイルを出力できた。
MP4Box -h format
でなんとなくつかめた。

基本bitstreamは一般的なものらしい。最悪、MP4Boxからソースを持ってくればストリームからmp4を生成することはできそうだ。まぁQSVと全く同じストリームの形式だとしたらそのままパクれて楽できるんだけど。

とりあえず、NvEncoderをデバッグで発動して、パラメータの中身を確かめておきたい。まぁ大体はソースでわかるんだけど、実際のものを見たほうが確実だし、新しい発見もあるかもしれないからね。

でも、デバッグができない。前はEclipseでステップ実行とか出来たんだけどな。Handbrakeのソースあたりでもできたはずだった。perspectiveにもファイルが出てきているのに、ファイルの行をダブルクリックしてもBraek Pointを張れず(張れているみたいだけど有効じゃない)、コンソールに

No source file named ファイル名


と出てきてしまう。これには大前提を忘れていてg++に-gオプションを入れないといけないらしい。
http://futurismo.biz/archives/1211

NvEncoderのサンプルファイルのMakefileでは
# Debug build flags
ifeq ($(dbg),1)
      CCFLAGS   += -g
      TARGET    := debug
else
      TARGET    := release
endif

とあるので、Eclipseのプロジェクトのプロパティのところの「C/C++ Build」の「Build command」に
make dbg=1

でブレークが張れるようになる。とにかく-gオプションを入れれば、Ecilpseではデバッグできるようになる。というか、そもそもgdbを使うんだから、デバッグ情報を入れなきゃならないのは当然だったのでした。というか、サンプルなんだからデバッグオプションぐらい張っておいても良さそうなもんなのにね。handbrakeの時は自分で-gオプションつけたのかな。まぁ解決したから先に進むだけだ。

コメント(0) 
共通テーマ:パソコン・インターネット

コンピュータ言語食い散らかし3 Ruby [プログラミング]

最近はそんなにやってないけど思い入れが大きい言語Ruby。

Rubyはかなり思い入れのある言語です。その割には空で書けるほどやっていないですね。大体のライブラリは使えるのですが、ほとんどRailsに使われていた時間が多いです。そのため、一般的なプログラミング能力が高まっているとは言えません。

ともあれ、本だけはたくさん持っているのでそこそこは読みました。関連でまつもとゆきひろさんの著作もちらほら読みました。やっぱり日本人が作った言語という切り口から入ったので、原作者の存在は大きいです。以前、何かの宗教活動をなされていたらしいですが、図らずとも自分で書いた経典の方が有名になっちゃったパターンになりますね。

日本人が作ったということで、英語偏重になっているプログラミングの世界としては学びやすいというところがあって、英語を曲りなりに読めてしまう自分としては時間が短縮し、オライリーとかの翻訳本を読まなくていいところは、ダイレクトに入ってくる部分は多かったです。他の人が曲解している部分が入りづらいとか、自分で英語を読む時に誤解してしまう面が少ないのは素直にありがたかったです。


しばらくするとRailsブームが来て世界的な言語になりましたが、正直Rubyを使っているというよりRuby on Railsのスケルトンの使い方を学んでいる感じがしました。今でも中身がどうなっているか細かいところまで理解はしていません。

そもそもSQLなどを使わず、ある程度名前の付け方などを固定して楽するというライブラリだと思っているので、逆に中身を全部知っていこうとする行為は、Rails本体を開発するのでもない限りはあまり重要で必要ではないのかなと思ったりしています。知っているには越したことはないけれど、それをするんだったらもっと簡単なフレームワークでSQLを自分で発行するようなものを作ってみたほうがいいと思ったり。


正直、Pythonに差をつけられた感はあります。Googleで採用された時には、どうせPaaSで使えるだけだと思っていましたが、近年の人工知能ブームでLLどころかプログラミング言語全体の中でも重要というか良く使われる言語となっているようです。実際、デフォルトでディストリビューションにインストールされていたし、ユーザーランドで使うツールがあれば実行環境も入れないと話にならないわけです。

自分が始めたころにはLLとしてPythonとはどっこいどっこいではありましたが、科学技術系の計算などでCUDAが使えるようなところから、機械学習で非常にもてはやされているところです。そういう用途としてはRubyがいいという話は聞きませんし、今後もそういうこともないでしょう。とはいえ、名目上の上限がない大きな数を扱えるとか、数を扱うのに適していないわけではないのでしょうが、動作速度が云々言うような処理には一向に向いていない傾向は、LL言語らしい傾向なのでしょう。基本DBのフロントエンドというか。

買った本はRailsものが多いのですが、面白かったのは人工無脳、Web検索エンジン、などがあります。一番多いのが逆引きのHow To的なものですね。実際使うにあたってググらなくてもまとまっている本があると楽という安直な理由ですw。Rubyの逆引き物は結構いっぱいあるのでググって見てください。頻繁に使う人は楽できると思います。

恋するプログラム―Rubyでつくる人工無脳 (プレミアムブックス版)

恋するプログラム―Rubyでつくる人工無脳 (プレミアムブックス版)

  • 作者: 秋山 智俊
  • 出版社/メーカー: マイナビ出版
  • 発売日: 2016/11/28
  • メディア: 単行本



恋するプログラム―Rubyでつくる人工無脳 (Mynavi Advanced Library)

恋するプログラム―Rubyでつくる人工無脳 (Mynavi Advanced Library)

  • 出版社/メーカー: マイナビ出版
  • 発売日: 2014/12/04
  • メディア: Kindle版



Rubyでつくる検索エンジン

Rubyでつくる検索エンジン

  • 作者: 星澤 隆
  • 出版社/メーカー: 毎日コミュニケーションズ
  • 発売日: 2009/05/26
  • メディア: 単行本(ソフトカバー)



ただServerSpecとかChefがRubyで書かれていて、そういう設定系のツールがRubyで操れるというところはいいなと思っています。内部DSL関係はRubyが浸透させたと思いますし、他のものはどうか知りませんが書きやすい気はします。まぁこれは書き慣れているというだけかもしれませんが、そこまで活躍してくれてないのも実情だったりしました。DRYとかもRubyでの啓蒙が大きいでしょうが、自分はI Repeat Myselfな人間なので改めないといけないなとは思っていますが、コピペの癖は抜けず…。capistranoとかもRubyだったな確か、あんま使ってないけど。


Pythonと違ってバージョン間非互換が少なくていいなと思っていましたが、Pythonも大方Ver.3に移行してきているので、それ自体はそんなに問題とならなくなってきているのでしょう。書き換えはコミュニティ全体が盛り上がっていれば誰かがやってくれることが多いですしね。使われないコードはなくなるだけですが、自分が依存していると悲しい運命になったりします。

後ろ向きな互換性の解消のコーディングは、新しい機能追加と共にやってモチベーションを上げたりするのですが、最近なかなかしんどくてコーディング自体あんまりしていません。大体のことはみんな誰かがやっていたりするので、そこをチョコチョコつまんで事を済ませてしまうことも多いです。まぁ外向きのシステムでない限りは、 rbenvとかで塩漬けすればいいんですけどね。

何かRubyで書きたくなるモチベーションが上がるトピックないかなぁ。

コメント(0) 
共通テーマ:パソコン・インターネット

コンピューター言語食い散らかし2 Swift [プログラミング]

ネタがないので最近やってるコンピュータ言語で考えていることとか状況。


・Swift

OSSになったAppleが作った言語。はじめはOSSにする気はさらさらなかったらしいけど、周りからの多くの要望によってOSSにせざるを得なくなった。当時は結構揉めた気はしたが、OSSになったからと言って大して盛り上がっていない気がします。Swift3になってMacでの開発も落ち着きつつありますが、どうにも以前との互換性がなくなった分、前のソースがそのまま使えないというのは学ぶのにしんどかったりします。

SwiftがOSSになったのはいいものの、Swift自体がGUIを前提に作られたもので、コマンドライン用のライブラリがきちんと整備されていない。あるにはあるのだけれど、Core Foundationとしてかなりベアな形でしか存在していない。その上、GUI部分がOSS版には用意されていないところが発展途上なところだった。少なくともCore FoundationからのFoundationがスタブ(?)的にありはするけど実装はされていない状態では使いようがない。

今も大して変わっていないとは思うけど、恐らくは言語仕様を実現させるぐらいが関の山なのではなかろうか。OSSとして成立させるためには、他の言語と同じようにコンソールで動く標準ライブラリを充実させる必要があるだろう。そうじゃないと他の言語同様に使えない。とりあえず動きますよ的なポーズで終わってしまう可能性がある。

言語使用的には強制的にエラーチェックをしないといけないとか、バグの出にくい体制にはなっているものの、面倒くさがって避けてしまったらたいした違いはなかったりする。ただどうせ回りくどいんだったらチェックしてしまおうという気にもならなくもない。

よく考えたらこの言語で特徴的なのはこのOptionalの部分ぐらいのものかなと感じる。他にはLLにはあってもコンパイル言語にはあまりなかったところとかが新しいくらいで、既存の言語にはあるものを全部乗せした感じではある。型推論、クロージャ、ジェネリクスなどは他の言語にもある。全部そろっているかどうかは別だけど、コンパイル言語としてはないものはない感じではある。

ただ他の先進の言語を詳しく知っているわけではないから、現行の言語としては大体あるものはある的な確度しかないんだけどねw。ともあれ、こういう風にきちんと建て増しっぽくない状態で提供されるというのはいいことだろう。


建て増しで思い出したが、前のObjective-CはC言語にクラス部分を建て増していた。そのため切り分けはできていたものの異物感というのは避けられなかった。少なくとも関数とクラスのメソッドの書き方が違うというだけで、言語としての一体感を欠いていたと言わざるを得ない。C++もそうだがC言語からの建て増し感があって、ライブラリを使うための言語になってしまう側面があった気がする。実際、新しい分野や基本的分野で提供されるライブラリはベタな関数だったりするわけで、クラスによって組み上げられているものはそこそこその分野が練れてきている証拠だったりする。

建て増しという言葉がネガティブなら、C言語にクラス機能を付加するラッパーともいえるだろう。C言語自体は各環境が各々持っているアセンブラの違いを吸収するためのラッパー(それ自体ほとんどC言語のみで構成されているかもしれないが)であり、SwiftはObjective-CをLL的に使うラッパーであるとも言えるだろう。Apple的に言えば、Foundationなどを中途半端で古めなObjective-Cから置換するためのもので、これもC言語と同じように完全に置き換えをするものになっているのだろう。

そして後から出てきた言語なので、取ってつけたような異物感はあまりない。そういう意味では先進的というより現代的なコンパイル言語になっている。LLではRubyやPythonのようにいくつか現代的に整った言語は存在するけれども、コンパイル言語ではそんなに多いとは思えなかった。そういう意味でSwiftは格好の的になっていて、OSSとしてリリースさせろとあんだけ要望があったのも、現行でそういうコンパイル言語がほとんどなかったからだろうと思われる。

Linuxにしてもカーネル部分からユーザーランドまでC言語でいいやん的な雰囲気が流れているのは間違いないし、たまにPerlやPythonで書かれているものがあって、バージョン依存があって面倒だなとかいう次元だったと思う。そういう意味ではまともに最近の常識で書けるコンパイル言語というのは、割と貴重なのではないかと思う。それとメモリ処理的に問題となりやすいガベージコレクションを使わないというのも、実行サイズがコンパクトになるという点においては、コンパイルされているという点と同様に重要な点になっているだろう。


正直、OSSは先に言ったようにまだまだです。言語仕様は固まってきているとは思うけれども、使っている人も使われている例もAppleに偏っているのが実情でしょう。Linuxのカーネルに対するディストリビューションと一緒で、言語仕様だけでは使えないので、周辺のライブラリの実装がカギになってくるのでしょうね。

次はあんまりやっていないけどRuby。LLはあんまり好きになれなかったんだけど、これが契機でやるようになりました。

コメント(0) 
共通テーマ:パソコン・インターネット

コンピューター言語食い散らかし1 Golang [プログラミング]

最近使ったコンピューター言語をなんとなくダラダラ思う。

・Go

スクリプト言語全盛の中で出てきたコンパイル言語。正直LL言語を使っていてコンパイルして速く動かしたいなと思う事がよくあった。それとLLは動作環境を整えないと動かないことも面倒くささが募ったりするし、バージョンの差も気になるところであった。Golangを使ってみて改めてコンパイル言語がいいなぁと思うところがあった。

思ったよりか改善著しい感じで良い。その上、言語仕様が途中で変わったりはほとんどしていないから、あのバージョンのソースが新しいバージョンで動かないとかはあんまりない気がする。バージョンの非互換性というのはどうしても言語が盛り上がれば盛り上がるほど起こってくるものだけれど、最初から標準ライブラリには必要十分なものが揃っていたし、安心して使えるという感じ。

内部的なパフォーマンスもかなり改善しているみたいで、GCとかはかなり著しく改善しているのをどこかで見た。そういう改善ってのは地味に難しいとは思うんだけど、やはりGoogleが作った言語というだけあって半端ない感じはする。正直Googleの言語かよと思っていたのだけれど、一部C言語の代替としてコンパイラ言語としては素養が良すぎる。標準ライブラリはそこそこ癖があるというか、C言語っぽくはないものの、C言語っぽく書ける上に安全で罠にはまらず書けるのはいいのかもしれない。

標準ライブラリ以外のものを使う時もGOPATHのところに突っ込む仕様になっているので、一回やってしまえば日常的に使えるのだろうし、そこのところは面倒なパッケージ管理とかはそんなにない。自分で作ったりするときはどうなのかはわからないけど、そこまでのスキルがあれば問題ないレベルだろう。まぁやれるか面倒かどうかは別の話なんだけど。

OSの中身を書くとか、既存のソースをいじるのであればC言語を始めに学んでもいいと思うんだけど、つまらない細かいしきたりとか仕様とかを考えなくても良い分、GolangをC言語よりか先に学んでもいいんじゃないかと思ったりするんだけど。というかC言語は縛りが少なすぎて、自分で律していかないとダメな面があるので、初心者向けな感じはしないんだよね。言語仕様自体が覚えることが少ない点では、初めての言語として入りやすいのだけれど、訳がわからず動いちゃってる状態が多すぎるし、それ自体がバグになっているケースが多い。それと何をするにも標準ライブラリ以外のもののしきたりを知らないといけないから、環境によって知らなくてはならないことも多くてしんどいとか。

ただでさえ初心者だったらコンパイルが通って動くまで行くのがしんどいのに、実際の動かすロジックに集中させてくれと思う。そういう意味ではGoはそこそこストレスが少ないし、適当にWebからソースを持ってきても動くことが多いので、さくっとオレオレツールを作るのには適している。最近は全部盛りな言語が多い中、覚えることが少ないのは利点なんじゃなかろうか。オブジェクト指向でできることを少しは取り込んでいるし、覚えることが多すぎて使わないものが多すぎるよりかずっとマシだ。というか、C++とか巨大すぎて普通の書き方をしていても、これなんだったっけみたいな事が起こりやすい上に、そんなの知らないという個人の認識の差が大きすぎるのが問題になったりしていた。更に明らかに使い方を間違えている既存のソースを直すのかどうかとか面倒な話になってくることもある。

Golangは最近の動向を掴んで作られているから、初期に言われていたように昔の言語のまんまじゃないですよ。確かにカッコのインデントの位置を強制させるのとかは気持ち悪いけど、まぁ慣れですよね。何にしてもC言語後継のコンパイル言語が出てきてくれてありがたいことは確かだ。まぁC言語はC言語で特定用途で残り続けるとは思うけど。プアな組み込みとか使わざるを得ないしね。


続けてSwiftとRubyを書きたいと思います。

コメント(0) 
共通テーマ:パソコン・インターネット

Nvidia Video Codec SDK7.1のNvTranscoderをいじる [プログラミング]

NVENCのお勉強の一環として、NvTranscoderをいじっている。元はH.264をH.264とかHEVCに変換するものなんだけど、実はmpeg2も大した改変もなくHEVCとかに変換できた。たぶんNVDECがサポートしているコーデックならみな対応しているんじゃないかなと思う。対応しているんだけど、入力時にH.264しか入れないようになっているので、そこを取り去ってさえすればそのまますんなりトランスエンコードされる。

具体的にはVideoDecoder.cppの114行目

if (oFormat.codec != cudaVideoCodec_H264 && oFormat.codec != cudaVideoCodec_HEVC) {
fprintf(stderr, "The sample only supports H264/HEVC input video!\n");
exit(-1);
}
というところをコメントアウトするだけでいい。ここでいらないチェックをしているから、途中で止まる。少なくとも付属しているplush1_720p_10s.m2vをHEVCにエンコードできたようだ。ただ、今までと同じようにmp4のコンテナに乗っている状態ではないので、そこは別途インプリしないといけない。とりあえずHandbrakeからソースを取ってきて組み入れてみようと思う。

ん〜mpegは結構画像が荒れるな。ブロックノイズどころの話じゃない感じ。VLCとかは細かいブレをチューニングして作られていることが分かる。VOBファイルは途中でエラーが出る。まぁそうだろうね。どちらにしてもMP4化は必須なのでやらないと。

MUX部分だけHandbrakeから持ってこようとしたけど、他のヘッダや何かがかなり入り組んでいて、それだけ抽出するわけには行かなかった。関数だけ引き出すことはできるのだろうけど、それでもHandbrake由来の型が沢山あると思うので、簡単に移植できそうにない。これはHandbrakeにTranscodeのソースを持ち込む方が楽できるかなと思ったり。それにはTranscode側の訳のわかってないところを読み込まないと。もうちっと粘度が低いと思っていたけど、Handbrake自体がかなり色々なものを取り込んでいる上に全体的にはモノリシックな構造になっている。

ってかモノシリックだと今まで思っていた。モノリシックね。lithic自体が岩石関係の言葉でmonoがついているから一枚岩的な意味らしい。日本語の読みやすさで日本語英語ができることって多いよな。シミュレーションがシュミレーションとか、あまりによくありがち。雰囲気をふいんきと読んだりするのも同じだろうなぁ。あまりに頻発するので訂正する気にもならない。まぁ意味が相手に正確に伝わればいいとは思うけど気になる人は気になるだろうな。

そんなわけでmp4boxとか組み入れるなり、外から使うなりしてちょっとやってみたい。その前にHandbrakeに突入しちゃうかもなぁ。cppファイルをそのまま使ってextern"C"して使うか、スクラッチしてC言語のNvEncで始まるAPIを素で使うか、どっちが早くて確実かなぁ。内容をはっきりと理解しなくていいのは.cppファイルのまま渡す方法なんだろうけど、それだと何だかわからないが動く状態になりかねないし、それはそれでいいかなと思う自分がいたりする。目的はHandbrakeを理解することじゃなく、NVENCを使うことなので。しかし、Handbrake久しぶりだな。ちょっとソースが懐かしいとともにQSV関係のソースが加わっていたりする。」

コメント(0) 
共通テーマ:パソコン・インターネット
前の10件 | - プログラミング ブログトップ