So-net無料ブログ作成
  • ブログをはじめる
  • ログイン
プログラミング ブログトップ
前の10件 | -

ブログネタがない、ので暗号化を少し [プログラミング]

何かしていればなにがしか書くことはあるのだが、暑くて何もしてなくて書くことがない。まぁそろそろiPhoneの新製品が出るだろうし、MacBookかMacBook Airの新製品が出るだろうから、もう少しするとネタにも困らなくなるんだろうけど、それも何か他力本願な気がする。

今、暗号のAESを簡単に調べてソースとかねーかなと見てみたりしているのだが、あんまり有望そうなソフトもないっぽい。ECBという一番簡単にクラックできるものを実装しているものが多いような気がする。それを使うならオレオレ暗号化の方がいくらかまともかもしれないと思うのだけれども。

そもそも3DESとかどんなもんかとか分かっていないのに、AESも何もあるもんかいという事もあろうかとは思うのだが、今更使ってないDESのアルゴリズムを理解するのも面倒なのでやらない。というか、基本的に暗号化ってコンピューターになっちゃうと鍵と暗号化されるデータのXORがほとんどなんだろうと思っちゃうんだけどね。

鍵データの適用が分かってしまわないように、いい感じにどうシャッフルするかとかそういう事なんだろうけど、実装の面倒くささはいいにしても、暗号化復号化のコストは重要なところなんだろう。あまり重すぎる処理というのもどこでも使えるようにはならないからね。処理の重さと処理速度は案外大事だろう。

AESにはいくつかモードがあって、基本的な処理は同じかと思うが、最終的に違う暗号化くらいにやっていることが違うっぽい。

・ECB (Electronic CodeBook mode)
・CBC (Cipher Block Chaining mode)
・CFB (Cipher FeedBack mode)
・OFB (Output FeedBack mode)
・CTR (CounTeR mode)

とあるらしい。これは本で読んだ。

暗号技術入門 第3版

暗号技術入門 第3版

  • 作者: 結城 浩
  • 出版社/メーカー: SBクリエイティブ
  • 発売日: 2015/08/26
  • メディア: 単行本



暗号技術入門 第3版 秘密の国のアリス

暗号技術入門 第3版 秘密の国のアリス

  • 出版社/メーカー: SBクリエイティブ
  • 発売日: 2015/08/25
  • メディア: Kindle版


推奨されるのはCBCモードかCTRモードらしい。その他は何らかの脆弱性があるっぽい。でも最悪ECBモードを使わなければいい程度だろうと思われる。

ともあれ、ECBモードは基本だと思うので、習作的に実装してみたいとは思っている。それとCBCとCTRを実装すればいいかな。暇があったら3DESとかエニグマとか半分シャレでインプリしてみようかと思ったり。まぁ先ずはAESということで。AESが終わったらRSAに行くのだろうけど、RSAはデカい素数が必要だろうから実装しても暗号強度が云々というのは分からないかもしれない。まぁ小さい素数でも復号できれば実装を確かめるには問題ないだろうが。


こういうものは本家に情報を求めるのが一番なんだな。

https://csrc.nist.gov/projects/cryptographic-standards-and-guidelines/archived-crypto-projects/aes-development

というか、最近一次情報をぶんどってきてアフィリエイトに役立てるだけのような奴が多くて困る。まぁ人の事言えんけど、単なる再録みたいなのはやりたくはない。
あ、本家にC言語のリファレンスコードがありやんの。

https://csrc.nist.gov/CSRC/media/Projects/Cryptographic-Standards-and-Guidelines/documents/aes-development/rijndael-unix-refc.tar

これをコンパイルしてGolangの実装に役立てたい。最初はC言語でやろうと思っていたのだけれど、本家でやってたんじゃ意味ないし。とりあえず今度は上のコードレビューをしてみようかなと思ったり。なんか本気になってきたぞ。職業にはもう何にも関係なくなってしまったがなw。

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

これからは、暗号化と音声操作をやろうと思う。 [プログラミング]

プログラミングをしばらくやっていない。というか、プライベートが充実していない。リア充とかじゃなくて趣味的に動けていないという事だ。全く動けていないわけではないが、暇な時間を本を読んだりしかしていない。アニメも見るが停滞しがちだ。

とりあえず趣味としては生産的な事をしていない。一番生産的なところと直結するのがプログラミングだったりするのだが、基本的にコンピュータは情報取入れ端末としてしか使えていない。まぁ普通の人が使う使い方だ。ものを作り出すよりか消費する方が容易い。ただそれが面白いかどうかはまた別問題で、面白いからと言って楽か楽でないかは気分によっても違う。

ちょっと前はGolangでWebサーバを作ろうみたいな話をしていたのだが、なんだか面倒になって止めてしまった。HTTP/2の仕様も考えないといけなくなったし。他にもちょっとしたツールも作っていたのだが、WSLがなんかうまく動かないみたいで頓挫してしまった。普通にLinuxを使えばいいのだけれど、それも面倒になって止めてしまった。サーバをずっと立ち上げっぱなしにしておくのは夏の間は辛い。

そんなわけで手元でプログラミングすることをあきらめてしまったのだが、あまりにも退屈で生産的ではないので、前にやろうと思っていた暗号化と音声操作をやろうと思っている。暗号化はAESとRSAを主に、音声操作はWindowsでできるところで、という具合に。とりあえず手を動かして実際に動かすところと、ソースと理論のかけ橋にするところをやってみたい。案外、よく使うけど作った人に任せがちなところを自分でやってみたいというのは変わっていない。


ところで新しいMacBook Proが出たのだが、そこそこマイナーチェンジで良くなっているようだ。実際に使っている話も出てきていて、値段以外は良しという事になっているらしい。というか、それまで結構問題が散見されていてそれが解決しそうな感じではあるのかな。ただ、安くても20万円越えなので4コア8スレッドになるとはいえ、ちょっと踏み切れそうにない感じ。Kaby Lake Refreshで安いの出してくんないかな~。

とはいえ、今のタイミングでMacBook Airを買うというのもちょっと気が引けるし、お手軽な値段でノートを買いたい気持ちはある。それとプログラミングをするという点で、MacだとUNIXのお作法で簡単に作れるしね。そこはWSLとも仮想化とも別サーバーとも違う。

最近、Appleも自分もちょっとMacを見放し気味だったけど、ちょっと欲しくなってきた。今持っているMacがへぼ過ぎるので、買い替えないとはいけないと思ってはいるんだけども、正直Armへの乗り換え路線も控えていることだしなぁ。オリンピックあたりには出るんだろうけども。

にしても13inch MacBook ProはKaby Lake Refreshじゃなくて、モバイル用のCoffee Lakeらしい。6コアな15インチのはCoffee Lakeだと分かっていたけど、これじゃ第八世代Core iって本当にわけわからんラインナップになっとるな。Coffee Lakeは消費電力が多すぎてモバイルには向かないと言われていたんだけど、そこのところはパスしたんだな。

モバイルCoffee LakeはMeltdownとかSpectre対策はしてあるんだろうか。そのわりにはベンチマークは悪くないみたいだけどな。だから今回はやってなさそうな気がするな。MacBookは値段のわりにアレなので、MacBook Airが刷新されればいいのにと思っている。USB Type-Aポート付けたままで、いろいろアップグレードを付けつつ、Touch Bar周りは全く付けない方向で。そうじゃないと安くならないもんな。

膝の上か寝転んで安いMacを使いたい。ただそれだけかもしれない。

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

プログラミング言語のインデントの話 [プログラミング]

今、C++のソースを扱っていて、インデントの仕方がTabだったりスペースだったりと統一感がなくてイライラしますw。基本4タブなので、大抵のエディタでは問題ないのですが、何というかいつの日も気持ち悪さをはらんでしまうインデント問題。Tabの持つ便利さが問題を起こしている気もします。

インデントにはスペース文字
2個分
4個分
8個分
が主だと思います。その他は変態野郎という事でw。8個なんてデカいインデント誰が打つんだ、というWindowsなプログラマもいるかもしれませんが、Linuxでデフォルトなエディタやビュアーであるviやlessでは普通はTabがスペース8個分で表示されるはずです。

4タブが主流になったのは、WindowsのIDEやエディタがそうだったからだと思います。まぁ普通に字下げの単位として四文字というのはちょうどいい長さであるというのもあると思う。2タブだとTabを使う意味があまりないし、8タブだとやっぱり普通に使うには長すぎる。

LLなどのスクリプト言語だとスペース二つ分のインデントも多い。というか、JavaScriptで初めてそういうのを見たような気がする。2タブも悪くないと思う。何にしてもTab文字を使わず、スペースですぐに入力できるというのが良いと思う。ただインデントとして見やすいかどうかというのは微妙な話だ。

何にしてもTab文字とスペース文字を混ぜてインデントしないでほしい。色々気持ち悪い。

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

NVENCをC言語のソースに組み入れたい [プログラミング]

NVENCを既存のC言語のソースに入れ込みたいと考えているのですが、SDKのソースがC++で書かれていて容易にC言語のものには組み込めないようです。C++のソースにC言語の関数を取り入れるのは難しくはないけど、逆はちょっと面倒くさい。APIの関数はC言語っぽいんだけどな。

最終的にはC++で処理を書いて、extern "C"で処理の入り口を書くという事になるのでしょう。正直、キメラっぽくて気持ち悪い状態なわけですが、そうしないとVideo Codec SDK側のソースをC言語で書かないといけないのだろうと思われます。具体的にはNvHWEncoder.cpp、dynlink_nvcuvid.cpp、dynlink_cuda.cppなどC++の記述があるところで、これをC言語に書き換えれば問題ないのかもしれませんが、SDKの中身が変わった時にソースのコピペで対応することができなくなってしまいます。自分が書いた側の対応も必要でしょうが、いちいち両方とも手を入れないといけないのはしんどすぎます。

そんなわけでVideo Codec SDK側のソースには手を入れないことにしました。一番手間のかからない方法でかつ確実性のある方法でやろうと。でも、C言語のバイナリにC++のバイナリを組み合わせて動作させるのは気持ち悪い気はします。その前にCUDA用にnvccでコンパイルしたバイナリをC言語のソースに混在させていたので、それと大した違いはないのかなと思って我慢します。

移植のために意気込んで色々準備していましたが、CプログラミングではなくC++とMakefileの扱いになってしまいますね。特殊な使い方をしていないもののC++はあんまりやりたくないんだよなぁ。Objective-Cよりかやだ。

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

インタプリタの言語がなぜコンパイルできないのかを知りたい。 [プログラミング]

どこぞでRubyと似たCrystalという言語が、コンパイル言語でメモリの消費も少なく実行も速いとされていた。まぁコンパイル言語にほぼ通底する特徴なわけで。

http://ja.crystal-lang.org/
https://crystal-lang.org/

しかし、根本的にLL言語のようなインタプリタな言語がなぜコンパイルできないのか、という事が分かっていない。コンパイル言語をインタプリタで実行することはできるが、その逆は大体できない。何が引っかかっているんだろう。

よく静的とか動的とか言われてますが、コンパイルしないことによって融通が利くように作られているのはわかります。コンパイルする事によって動作が固まってしまう事を含めて静的というのだろうけど、具体的な部分がどういうところなのかが分かっていない。JITなる動作環境がいろいろな言語には用意されているようだけれども、どこいらまでJust In Timeにネイティブ動作させているのかがよく分からない。

そもそもJavaとかコンパイラなのかインタプリタなのか分からん言語もあるし。一応使う前にコンパイルをするけれども、JVMというインタプリタ用のバイトコードなわけでしょ? 謳い文句ばかり覚えているので内容が伴っていない。


Crystal は Ruby とよく似たプログラミング言語ですが、ネイティブコードにコンパイルされ、Ruby よりずっと効率的に動作するものを目指しています。一方で、そのために Ruby が持っている動的な機能についてはいくらか制限されています。


とCrystalの翻訳ページには書かれているのだけれど、それが実際に何なのか差分らしき記述が見つからない。そこが知りたいところなのにね。


ここでの互換性&移植性のテストを見ているとかなり厳しい模様で。

https://qiita.com/5t111111/items/2d7133ef8dfac2e53f25

まぁこの時よりは少しは進捗があっただろうから、いい方向に進んでいるといいのだけれど。

ただ一方で、Ruby という動的型付けを最大限に活かしたプログラミング言語に対しては、どれだけ表面を似せたとしても、そこに静的型チェックが入ることによる変化は非常に大きくて、設計やコーディングスタイルに深く影響します。それがこの記事で書いているような非互換性につながっています。


「動的型付け」と「静的型チェック」という言葉が重要そう。Rubyに関して動的型付けが言語仕様にどれだけ影響しているか、という事になるんだろうけど、そこをコンパイルが通り抜けられないという事なんだろうね。Rubyはそこそこ使っていたけれど、どこが動的型付けの部分だなんて意識して使っていたはずもないので、改めてそこは見返してみないといけない。


初めてのRubyという結構古い本をひっくり返して、動的型付けの例を探してみた。

初めてのRuby

初めてのRuby

  • 作者: Yugui
  • 出版社/メーカー: オライリージャパン
  • 発売日: 2008/06/26
  • メディア: 大型本



#ユーザーの入力が1ならBarから、それ以外はBazから派生する
class foo < (user_input == "1" ? Bar : Baz)
  #処理
end

実際にCrystalで実行したわけじゃないけど、実行に詰まりそうなコードである。

確かに実行されるまでクラスの継承関係が決まらないなんて、静的型チェックというプロセスにおいて辛すぎると言わざるを得ないだろう。もしかしたら動くかもしれないけど、他にも動的に解釈される部分は多そうなので詰みになること間違いなしだろう。


なので、インタプリタでやっている言語はそれなりの意味があってそうしているわけで、もしそうじゃなければ実行速度も大きさもコンパクトになっているコンパイラ言語にしているって話ですよね。別にCrystalの素養が悪いと言っているわけじゃないけど、標準ライブラリから別物と考えた方がよさそうです。そもそも無理を押してコンパイルできるようにしているんです。

そういや、仕事でC言語のソースを見て動作してくれという依頼があって、それまでコンパイルしてDLLにして読み込んでいたのだけれど、それをアプリ側で何とかしろと言われて白目をむいたことがある。結局、C言語のインタプリタを作るんですか?と詰め寄って止めさせたのだけれど、C言語のインタプリタがOSSであった気がしたので無理すればできなくはなかったのかもしれないと思ったりしている。

https://root.cern.ch/cint

パースとかしてくれるにしても、やっぱしんどそうだな。まぁそういう仕事もないわけだけれども。

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

ソースコードに触れていない昨今 [プログラミング]

プログラミングを全然していないという話。仕事でもプライベートでも全然コーディングしていないのでプログラマー失格なのだが、色々整っていてあえてプログラミングする必要がない。ソースコードをコンパイルする事さえ、最近のバイナリリポジトリのおかげで導入の時にコンパイル環境を整えることなく済んでいる。まぁコンパイル環境さえaptでお手軽に入れられるから、Linux周りはかなり楽になったものだ。

ともあれ、何かを作るという気には特になれず、仕事でも要求されないとなると面倒くさいプログラミングはやらない方向になっていってしまうのは仕方ない。それに常時接続で誰かがどこかでほしいものを作っている可能性も高いので、探してそれを使った方が早いというのもある。ともあれ、それが都合よく動く確約はないわけで、それをいじったりすることはプログラミングができないとOSSであろうと参加できない。

昔はOSSというとGNUが総本山という感じはしていたけれども、今はかなり分散している感はある。GPLが大きく世界を動かしたという功績はあるだろうけど、GPLの過激さが商用づかいでは敬遠される傾向にあったりするもんね。ただソースコードをオープンにするというムーブメント自体は誰にも喜ばしい事だったのには違いない。今はプログラミングをしない人でも、OSSを使ったサービスを使っていないという人は少ないだろうし。


最近やったプログラミング言語って、GolangとSwiftぐらいでどちらも食い散らかした程度で終わっている感じなんだよね。Golangは言語仕様がコンパクトでいいんだけど、正直物足りなさを感じないこともない。ただ何か本を買ってまでしなくても大体の事はWeb情報でも大丈夫なのは楽だ。簡単なツールを作ったりするのはいいんだけど、持続的に何かを作る気にはあまりならないかな。

SwiftはOSSになった時に飛びついたんだけど、OSSのSwiftのライブラリの開発が特にされていなかったので、GUIを前提とするライブラリのまんま使えと言われても無理があった。今はどうか知らないんだけど、正直CUI前提で作れない言語なんてOSSとして使えないも同然だろう。少なくとも使いやすくラップされている低レベルな機能をライブラリとして外出しにしないと全く使えない。

自分がプログラミングを始めたVisual C++だってMFCしか使えないわけじゃなく、きちんとC++のコンパイラとして使えたわけだし、Swiftはそもそもの生まれの不幸もある気がする。元々OSSになんてしないとAppleは最初は言い張っていたし、他のOSSのプロジェクトにしても残念な結果に終わっている。AppleにOSSを任せておくとろくな事にならないというのはもはや定番と言っていいのかもしれない。


とりあえず、プログラミングで何かしたい気持ちになっていない。歳をとって興味が失せたといわれればその通りなのかもしれないが、大体のものが揃っているというのもやらない口実になってしまっている。SwiftでiPhoneのアプリを作るというのもいいと思うんだが、正直タダで入れられるようになっても新しく何か作りたい気持ちにならない。

やっぱりプログラミングというのは、若い時の興味とかそういうのが押し上げている面が大きいのではないかと思う。SE35歳説というのがあったが、興味がない人が仕事上でやるにしたら35歳がやれてせいぜいだという敷居になっているという事なんだろう。それ以降は、体力的に続くかどうかというのと、新しい事が頭の中に入りにくいという事実があり、仕事としてやれていくにはかなり特殊な範囲を担当せざるを得ないのだろう。

色々知ってしまうと、あれはこれでできちゃうよね~というのがあけすけに見えてしまったりして、実際にやらないのに満足してしまうところがある。それはそれで現実的な時間の配分として有効ではあるのだが、プログラミング的に楽しい生活なのかと言われるとそうではない。

そもそもがWindows上で自分でGUIアプリを作りたいというところから始まったのではあるのだが、それもCUIのツールのGUIラッパーを作りたいという目的であった。でも最近は基本的にロジック的にはラッパーされる側の動作を書いていることが多い。というか、GUIはGUIで作れる時点でもうプログラミングというより、UIの設計かデザインと変わらんのよね。それはそれで楽しい部分もあるし、使う方としては楽になったりはしているのだけれども、今となってはCUIの方がテキストで実行状況を保存しておけるしいいじゃん、という方に偏ってはいる。

今できる事と言えばやっぱりシステム周りの事なんじゃないかと思った。正直、そこまで知識が足りているとは言えないが、初心者に教える程度の知識はある。少なくともググってすぐ出てくるような内容では物足りないのもあるかもしれない。でも今更C言語のソースは見たくないなぁというのが率直な意見だったりするのだが、基盤となるところは基本的にC言語でできているのは仕方のない話だから、改めてデバドラのソースを見てみるとかするかもしれない。

[試して理解]Linuxのしくみ ~実験と図解で学ぶOSとハードウェアの基礎知識

[試して理解]Linuxのしくみ ~実験と図解で学ぶOSとハードウェアの基礎知識

  • 作者: 武内 覚
  • 出版社/メーカー: 技術評論社
  • 発売日: 2018/02/23
  • メディア: 単行本(ソフトカバー)


前にも買うと言っていた本を買う予定。買う買う詐欺みたいで嫌なのだが、読む時間が取れそうなので買いますよ、たぶん。久しぶりに仮想環境無しのLinuxマシンで試してみたいと思っています。知りたいけど自分で深掘りできない分は他の人に掘ってもらうのは楽でいいです。基本的にシステム周りってのは与えられているものだから、普段使っていてもなかなか内部がどうなっているか分かっていないことも多いし。


にしてもSurface3の音は悪すぎるな。ぱりぱりとノイズが入りまくりで、ごみがたくさん載ったレコードを再生しているか、昔の悪いサウンドカードを使っているみたいだ。アナログ出力にするときにパソコンのノイズが乗ってしまうようで、スピーカーが悪いというものでもなさそう。ところでAppleはスピーカーを作るのがへたくそで外注もあまり気合を入れていないことが多いみたいだ。iPhone付属のイヤフォンにしてもiPhone6になるまでは使う気になれなかったし、初期のMacBook Proにしても安い昔のCULVノート以下の音質だった。

Bluetoothのヘッドフォン経由だとノイズは全く乗らない。イヤフォンジャック経由だとノイズが乗る。という事はやっぱりアナログ回路に問題ありという事なんだろうな。きちんとシールドしていないとかそういう初歩的なところかもしれない。まぁアナログ的なところは初歩的なところも分からないのだけれけど、MSもそこまで手を回せないレベルなのだろう。所詮ソフトウェアの会社なんだよな。


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

Java AppletとFlashとHTML5のJavaScript [プログラミング]

昔、Javaが流行りだした頃、Java Appletというのがあった。今でもあるのだろうが、非常に特定の目的でしか動いていないと思う。Appletを使う手始めとして、アニメーションを扱ったりしていたのだが、フレームバッファを使わないとちかちかしたり、色々と面倒であった。その後、Flashが台頭するわけだが、アニメーションを作ることを考えたら格段の手間の差があった。

Flashで楽ができていたのが、iOSで拒否され、Androidでも拒否され、脆弱性で破壊され、Adobeも止めざるを得なくなった。HTML5が代替することになっていたのだが、実行速度はともあれ作成のハードルは高くなった。まぁGUIでやっていたものをコーディングでやらなきゃならなくなったのだから、Java Appletの時代に戻っちゃったようなものである。

ただ、Javaは起動させるのに少々重いのは変わっていないと思うので、昔ほどじゃないにしても最初の一発目はきついのは変わっていないだろう。コンパイルされているとはいえ、ネイティブコードに翻訳されているわけでもないし。それを考えるとインタプリタで頑張っているJavaScriptは速度を出すのに苦労しているんだろうなと思ったり。

でも、正直プログラミング言語としてちょっと気持ち悪い。基本C言語系というか、名前通りにJavaに似ていなくもないけれど、オブジェクト指向のやり方とか特徴的だしね。ヘッダファイルはないけれども、ファイルの依存関係は入れ子にできないとか、やっぱり大規模なものには向いていないとかいろいろ制限はある。ライブラリはコンパイルされないからコンパクトにするために可読性が落ちるのもちょっと厳しい。

FlashでもActive Scriptというものがあったと思うんだけど、それは極力使っていなかった気はする。それで実現させても読める人が少ないし、手直しするのにスキルが必要になってくるからだろう。だから、GUIでGUIを作れるというのは非常に画期的ではあったわけだ。Active ScriptもJavaScriptもECMAScriptだったと思う。そういった意味では、FlashからHTML5への移行は容易に見えるが、マイグレーションは難航していそうなので、実際Active Scriptで作っていたのは少数であったという事なのだろう。

JavaScriptは結構何でもできるけど、それをするには低レベルすぎるのかもしれない。ここでの低レベルはできることが少ないという意味じゃなく、高度な事をするのにかなり構築していかなければならないという意味だ。実際、色々なライブラリが存在していて、手間はかなり省けてはいるものの、そこはコンピューター言語なのである程度のスキルがないと扱えないのは当然の話だろう。Flashみたいにあんちょこを見てお手軽にできるほど気楽ではない。

何はなくともワンストップで扱えるソリューションが望まれる。テクニックで何とかというより、誰でも扱える製作ツールが必要だ。わりと一つの事をするのにもライブラリはたくさんあるし、やり方は決まっているわけではない。だから、ある程度やれることは制限して安易に使えるツールが必要なのだろうと思われる。あとで手を入れられる形でコードを生成させられれば、やりたい奴はいくらでも手を入れればいい。

GUIでやれないと生産性が上がらない。まずはそこからやれるようになってほしい。現状ではHTML5はあまりにハードルが高いし非生産的だ。多くの人がHTMLのタグとCSSを学ぶくらいで止まってしまいかねない。凝ったものはいくらでも作ろうと思えば作れるが、単純なものを作るだけでも結構しんどい。

商用のアプリケーションでFlashを代替できるようなものはあるのだろうか。HTML5自体は色々できるから製品でも方針がブレてしまいそうだよな。ただ今はスマホとかパソコンとは表示面積が大きく異なるので、そこいらの対応も面倒そうだよね。実際、単純なサイトでもサイズに対しては苦労して作ってそうだし。

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

ググると大抵のものが出てくるから [プログラミング]

ブログで書くことなんかなくない?と思ったりもするが、惰性で続けています。まぁ継続は力なりという事でw。あまり泣き言は書かなかったのだが、それでもぽろぽろ出てしまうわな。

最近、開発関係の事を書いていないので張り合いがないというか、仕事とも直結していないので時間が取れないというか。仕事の合間に暇な時間はあったのだが、あからさまにブログネタを書いているのも何なので、そこのところは自重してはいる。

何というか、色々な技術があっという間に広まるので、自分で地道に積み上げて何かを作るってことがしにくくなってはいる。欲しいと思うものは、自分が考え付く程度であれば誰かが作っていたりする。更に何かのライブラリやツールを使うにしても、ググれば結構解決法が出てきてしまうので、ここで書くべき事なんてなかったりするのであった。

今のプログラミング言語とか外部ライブラリを取り込みやすくなっているし、標準ライブラリが充実しているので色々なものが結構簡単に書くことができたりするんだよね。わりとよく使っているGolangにしてもRubyにしても、簡易Webサーバは簡単に書けるし、本当に本気で何かを実装する気が無くなってくるというか。まぁそもそもそれだけの根気もスキルも恵まれていないので、簡単にでもできるだけうれしいというものですが。

RubyのDRYじゃないけれども、同じことを繰り返すのってだるいよね。そういう意味では楽になってはいるのだろうけど、労力は減っても一向にスキルが上がっていない感じはするよね。ある程度の繰り返しってのは必要なのかなと思うし、色々なものをラップされたものを表面だけ使っていると本来知っているはずの事を学習できなかったりするわけで。

もう仕事でガチにプログラミングする事ってあるのかな。色々暇もなくなってサンデープログラマーでさえなくなってしまった。お金をかけずにプログラミングできる環境が整っているのに何もしないのはもったいない気はする。

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

もちっとテクニカルな記事を書きたいのだけれど [プログラミング]

最近、コンピューターの技術的なところから外れているために、ここで書くことも軟弱で自分としてもうれしくない。プログラミングもきっちりやりたいのだけれど、食い散らかして終わりなところがある。まぁGolangにしてもSwiftにしても中途半端なところはありますよ。やっぱりできないことがあるとできるところまでやりたいという気持ちはある。でも、ある程度のところまでやってしまうと、もういいかなとモチベーションも下がってしまうものなのだ。


飽きっぽい性格は本とかもそうなんだよね。勝手最後まで読み切ってしまうならいいけど、買ってから間が空いて積読してしまったり、途中で飽きて読まなかったり、往々にして中途半端。そういうのが許せない人もいると思うけど、自分と同じような人も結構いると思う。積読は一般に良くありがちだろうし。

アニメとかもBD-R焼き職人になっている感じですが、その場で見ないものは大体見ないんだよね。でも、ARIAみたいに取っておいて後からどっぷりつかるパターンもあるので、Blu-rayのパッケージを買う事を考えると網羅的に録っておかなきゃとか思ってしまう。ある意味かなりダメ人間な感じだなぁ。手段が目的になってしまうというありがちだが恥ずかしい行為だ。まぁそれ自体はよくあることなんだが、あまりにも建設的ではないので厳しい。


コンピュータ関係に戻るけど、なんか興味のあるトピックがない感じ。NVENCは途中とん挫しているし、Golangでのwgetもどきは途中で放り出してしまっている。流行りでDeep Learningをやろうとしたが、Pythonを学ばないといけないので面倒になって止めている。Firefoxのアドオンを作ろうかと思ったけど、なんだかんだで面倒でやっていない。それにFirefoxのバージョンが上がって新しいアドオンに移行しないといけないみたいだから、やり方も変わってくると思うし、そもそもやりたいことってそんなにない。

とりあえず今は必要に駆られて作ったりすることがない、というのが一番ネタがない原因になっているのではないかと思う。仕事も時間勝負になってきているし、開発環境ってのが確保できなくなっている。でもWindows10になればUbuntu上で色々できるわけで、ソフトウェア的なところはネイティブな環境と遜色ないものができるのだろう。


何か金になって趣味的に満たせるものってないのかなぁ。まぁないだろうし、あっても中途半端ではダメなんだろうなぁ。

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

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) 
共通テーマ:パソコン・インターネット
前の10件 | - プログラミング ブログトップ