So-net無料ブログ作成
検索選択

Twitterまとめ投稿 2017/06/16 [Twitter]


コメント(0) 

Golangまたやっか。 [プログラミング]

SwiftをUbuntuに入れて動かしてみたんだけど、正直まだまだだという事が分かった。Deprecatedな関数が多いのにもかかわらず、まだ実装されていないものもあったりで、どこまでSwiftでできないのかが分からなかった。そもそものライブラリの性質がコマンドライン用にできていないので、Foundationを扱うのも面倒な面が多かったりする。それとXcodeみたいにSwift3になって名前が変わったものをサジェストしてくれないので、自分で調べないといけないのもお手軽に書けない理由になっているのだろう。

OSSのSwiftは待ちかなぁと思うにつけ、やっぱりGolangとかはお手軽に書けていいなぁと思ったりしている。Swiftみたいに動的スクリプト言語みたいにかっこよく書けないけれども、C/C++言語から始めた自分としては何となく安心できる言語ではある。C言語的な万能さはないけれども、C/C++の罠が極力抑えられているのがいい。というか、オブジェクト指向は使うのはいいが、ライブラリ側に近いところを作り出すと一気に面倒になる。知らなくてはいけないことが多くなるし、気を付けるところもべらぼうに増える。


車輪の再発明となるが、Golangでhttpdを作ってみたい。busyboxぐらいのシンプルさのhttpdがいい。そこからHTTP/2の実装まで手を伸ばしたい。でもまずは普通のWebサーバ。Golangは標準ライブラリにすらいろいろ材料は揃っているから、割とシンプルに書けそう。あとgoroutineを有効に使ってみたい気持ちもある。なんかそういう基本のところをやってみたくなったんだよね。今まではいかにフレームワークを使うかとかだったけど、一般的なプロトコルを実装したくなった。

通信制御系のプログラミングはしていたこともあるけれども、正直全体像が分かるほど触らせてもらえなかった。仕様書ありきの世界でもあったわけなので、正直細かいことを考えたことはなかったりした。きちんと自分がすべきタスクを果たして次に渡せばよいだけだったので、全体の動きとかはまた別の話になっていた。それにしても携帯に限っては、すでに初めのころからハードウェアで実装されて、チップを配置するなりSoCに組み込むなりするだけの世界になっているのだろうから、ソフトウェアで処理して電話の通常通信処理で電池が持たないなんてことはないんだろうね。自分が3G携帯を作っていた頃でもGSMはワンチップ化されていたっぽいしなぁ。少なくとも基地局役の機器がトランシーバー並みの大きさになっていた時は、GSMの基地局側の処理もハードウェア処理されていたんだろう。

正直ハードウェア処理というのがよく分からない。ソフトウェアほど融通が利かないという事ぐらいしかわかっていない。FPGAとかそういう世界は同僚がやっているという話は聞いたことがある程度しか知らない。プログラマブルなハードウェアというのがどういう仕組みで動くのかが想像できない。やはりCPUにメモリを積んでメモリ上にロードするという処理しかしないソフトウェア技術者としては、VHDLとかでプログラミングする世界とは違う別物として考えていた。今VHDLのソースを興味本位で見たら、ネストの深い分岐処理が多いんだなくらいで、思ったほど回路回路していない感じだった。

ソフトウェア処理している部分を、ハードウェアに落とし込むときってどうやっているんだろうなとちょっと気になったり。通信制御系だとC言語とかの奔放な書き方ができる分の冗長さがなくなってやりやすいかもしれないなと思ったりはする。何でもできるからバグができるという側面がC言語には多分にあるから、今のコンパイル言語はバグが出ないようにわりと縛りがきつくなっている。それで書きやすいかどうかはまた別の話だと思うけど。


そんなわけで、おじさんの老後の楽しみとして(笑)、Webサーバぐらいはちょうどいいボリューム感なのかもなぁと思っていたり。仕事だといちからスクラッチする事ってまずないし、かといってシステムや言語に近いところをえぐるようなことも割とあったりするから、妙な知識ばっかり蓄積する。要するにつぶしの利かない仕事が多かったというわけだ。だから仕事をセミリタイアするまでは、DBとかあんまり扱ったことがなかったりして世界の違いに戸惑ったりもした。いや、パッケージでDBを利用していたりしていたんだが、SQLそのものを発行したりするところじゃなくて、Windowsのインターフェイス部分を扱ったり、別システムとのやり取りをしたりとか、そういう雑多な周りのこまごまとしたところをよくやっていた気がする。

これがDBそのものを作るとかになると、非常に敷居が高くなってしまうのだが、通信だとそこまで専門的な知識が必要ではない。英語だけれどRFCというアクセスしやすい資料も存在することだし。他のマイナーなプロトコルのサーバ実装とかもいいかなとは思ったけれども、正直へこたれそうで比較もできないと進んでいる感がないというか、実装後の検証もしんどくなるなぁとか思ってしまう。Webサーバだったら手元のブラウザですぐに確認できる。HTTPという訳が分かっているつもりのプロトコルでも訳の分からないところとか、実際どうやっているのかわかっていないところとか、実装しないとわからないところを知ってみたいという思いがある。単に手軽なおもちゃが欲しいという気持ちがあるわけで、別にそれがプロダクトになってほしいとかそういう気持ちはほとんどない。そもそも、世の中にhttpdなんてメジャーなものがたくさんあるわけで、それを自分で作れたら面白いなと感じるだけです。

とにかく語ってないで作れや、というのが世の常だと思うので、誰でも実装できそうなところから始めます。というかviとかあんま慣れてないんだが。しかし、環境からしてviかemacsでインプリするしかないんだよな。どっちにしても特殊なキーバインドなのは否めない。やっぱりWindows上で開発していたのが長かったから、そういうのにはあまり固執していないからなぁ。お手軽な方法に逃げてしまうのが人間の性というものだ。

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

Twitterまとめ投稿 2017/06/15 [Twitter]


コメント(0) 

H.265のハードウェアエンコってどんなんだ。 [ハードウェア]

H.264からひとつ番号が上がったH.265。Appleがサポートすると言っていました。どこまでサポートするんだか分からないけど、とりあえず時代はそっち方面に向かっているようです。

前にH.264をGPGPUで動かそうとしたんですが、条件分岐が多すぎてGPU向きの演算ではありませんでした。その時もIntelではCPUでQSVをやっていて、少なくともH.264でもエンコードはCPU向きではないということは分かっていました。それでもスレッドをフル回転させれば出来ないこともなかったわけで、並行処理が出来ればそこそこ何とかなる程度でした。

ともあれ、多少融通は利かなくてもハードウェアで処理した方がいいということだったと思います。QSVはOSSで使えると言う話を聞いていなかったので、ライセンスとかあるんだろうなと思っていました。少なくともWindowsでしか情報が提供されていない感じを受けました。実際、商用製品しかなかったし(今はフリーのはあるけれどもお)。

最近はGPUにもH.264とか265のハードウェアエンコーダーがGPUにも搭載されているらしく、NVIDIAはNVENCという名前で導入したみたい。

http://nico-lab.net/nvidia_gpu_encoder/

WindowsとLinuxということで、プロプライエタリなものになるかもしれないけどLinuxが使えることで開発の幅が広がっている。まぁGPGPUでもAMDよりかLinuxゴリゴリな開発環境を提供していたから当然なのかもしれない。

Maxwell (2nd Gen)というチップを使っているとH.265/HEVCを使えるらしいが、とりあえずGPUの新しいものを金をケチらずに買えば使えそう。というかGPUの型番も分からんけど、コードネームはもっと分からん。やっぱりGPUにハードウェアエンコーダを載せるという事は、普通にGPGPUしにくいって事もあるんだろうね。もはやCPUに任せられんと。

Intel QSVはSkylakeでHEVC対応していたらしい。
https://en.wikipedia.org/wiki/Intel_Quick_Sync_Video

AMDはRadeon RX 480でHEVCに対応しているらしい。
http://www.itmedia.co.jp/pcuser/articles/1606/29/news155.html

VCEというらしいが、GPGPUの頃のLinuxの塩対応が思い出される。なんか開発環境が古くて対応しているのを見つけることができなかった。NVIDIAに比べてこのアクセスのしにくさは何なんだ…。RyzenにNVIDIA積んでハードウェアエンコしようかなぁ。なんかAMDのGPUは使いたくない気がしている。嫌でもMacで使わせられるしね。

http://rigaya34589.blog135.fc2.com/blog-entry-297.html

随分前の記事だけど、AMD APP SDKに開発環境は入っているらしい。実際やっていないのでまた聞きで済まんがいつもブログなんてこんなもんだ。とりあえずGPU買ってこないとやるにやれん。

とりあえず、HandbrakeでQSVを使えるという事なので、HEVCを使えるCore iでマシンを組んで、お金に余裕ができたらNVIDIAのそこそこ良いカードを買う、と。でも、ハードウェアエンコだから高いものを買っても品質や速さはあんまり変わらないのかもしれない。

あとHandbrakeを改造して、nvencで使えるようにするとか。もう誰かがやってそうな感じですが。前にGPGPUの組み込みを失敗したので、その失敗が生かせるかなぁと思いつつ。

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

Twitterまとめ投稿 2017/06/14 [Twitter]


コメント(0) 

sitemap.xmlの簡単なスクレイピング [Linux]

Bash on WindowsでCreators Updateを入れずに16.04にしようと、do-release-upgradeをしたけど途中で落ちたw。というか、落とすなら初めから入れておくなよと思ってしまうのだけれど…。そんなわけでCreators Updateが本採用されるまでは新しいLTSなAPTを使えませんね。

wget -rでやたら時間がかかるので、Sitemap.xmlを加工して効率的にやりたいなと思ったわけで。こんな事が通じるのはレアケースなんだけど、Sitemap.xmlに出てくるURLを加工して独立したページを取得した方が速いのかなと。というかwgetでも辿り着けるんだけど、随分と時間がかかってしまっていたので、途中で止めました。だってスリープとかしていたにしても2日間ずっと落としていたのにまだ終わらなかったんですよ。まぁwgetは一つのスレッドでしか動いていないと思うので、ダウンロードも単一ファイルしか落とせないだろうし、ある程度の遅さは自動的に走らせてほっとくことによって楽する方向で。

そんなわけでスクレイピングを行いたいと思います。XMLのスクレイピングならちょっと前にやったGolangのgoqueryとかでいいじゃねぇかと言われればそうです。別に他のものに手を出す必要はないのですが、awkを使ってみたい気持ちは前々からあって、結果的にできていなかった状態だったのでした。そんなわけで、テキスト加工ならAWKでしょという事に相成りました。

でも、正直awkがどういう加工に特化しているのか全然知らなかったりします。ましてやスクレイピングに使えるかどうかというのがよく分かっていない。awkでスクレイピングを探していたら結局xmllintというツールを別に使う事になりそうだとわかりました。でもBash on Windowsには入っていなかった。

$xmllint
プログラム 'xmllint' はまだインストールされていません。 次のように入力することでインストールできます:
sudo apt-get install libxml2-utils

入れないとダメかぁ。あんまり使わないツールとか入れたくないんだよなぁ。本物のUnuntu Serverには入っていたのでそっちでやることにする。xpathの書き方はよく分からないけど、階層順に//の後に/でタグを並べればいいらしい。XMLの階層はHTMLほどめちゃくちゃじゃないから

たぶん下のようなコマンドで
xmllint --xpath "//urlset/url/loc" Sitemap.xml

<loc>http://www.ほげほげ.com/a.html</loc>
みたいなのがずらずらと取れる。ただエラーもたくさん吐き出されていた。でも、ファイルにリダイレクトしてあげたので気にしない。データを取れたんだけど、区切り文字を入れていないのでたくさん取れても単独で取れない。面倒なのでエディタの機能で</loc><loc>を改行で置換した。

後の加工も同じような置換作業でコマンドを加工した。本当はLinuxのコマンドで加工したところだけど、考えるのが面倒なので挿入するコマンドのパラメーターに注力した。やっぱAWKとかsedとか本気でかじっとくかなぁ。まだまだ知らないことは多い。面倒くさくてやっていないことも多い。

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

Twitterまとめ投稿 2017/06/13 [Twitter]


コメント(0) 

Twitterまとめ投稿 2017/06/12 [Twitter]


コメント(0) 

Ubuntu16.04デスクトップDVDが立ち上がらなくなった。 [Linux]

14.04LTSから16.04LTSへのアップグレードが見事に失敗し、DebianでUbuntu16.04のISOを取って来て焼いた。そこからブートしたのだが、なぜか途中で電源が落ちる。意味がわからない。ずっと立ち上がったままとかならまだしも、諦めて電源切るなよw。

何が悪いのかなぁと思って、CPUが16bitじゃないよな、いくら古いとはいえと危惧したが、問題なくx86_64の表示があった。そのOSが動いているから問題ない。DVDの焼け具合が悪いのかなと思い、Macでブートしたら問題なくデスクトップ画面まで行った。何だよそれ。今までXPやらDebianやらUbuntuやらを散々入れて来たマシンで動かないとか意味わからないんだが。

何が悪いのかわからないので、他のISOディスクでブートしてみる。他の昔焼いたCDとかDVDとかでは問題なくブートしている。何だろう。Ubuntu16.04.2のディスクがおかしいのか? どちらにしても相性は良くないようである。というか最近デスクトップのUbuntuはずっと入れていないので、状況がよくわからない。そういやいつ頃か64bitに変わってやっと当然の対応がされるとか思っていたのは覚えている。でも、その時もインストールしなかった気がする。

たくさんあるHDDを取ったり、マザーボードとは別に付けてあるイーサネットカードを外してみたりして動くかなぁと思っていたのですが、結果は変わらず。ただ単にDesktop用のDVDの素養が悪いだけじゃないかと思いだしてきた。ハードウェアが悪いとか古いとかいう問題じゃない気がするよ。ほんとこういうデグレードは頭にくるなぁ。GUIっぽい画面になっているからどこで止まっているかも見当がつかないし。

そういや日本語Remixという邪道なものがあった気がするなぁ。それでブートできれば問題ないのだが、いちいち落として来るの面倒だなぁ。正直、前入れた時に変なメッセージがブートの度に出て来てウザかったから、二度と使うものかと思ったのですが、デスクトップ用途なら日本語入力とかすんなりできた方がいいし、入れてみるのも悪いことじゃないのかもしれない。でも、同じようにブートしない確率高いなぁ。だって基本的なところはみんなおんなじでしょ。ブートしてからが勝負なディストロだろうから、ブートする前はやっぱりダメなんじゃないかな。

結局日本語版を落とした。DebianでもTorrentデフォルトで使えるんだね。Transmissionっていうアプリがあってちょっと驚き。なんかDVD-RWこんなに焼くのも久しぶり。以前はLinuxを物理サーバに入れるために、CD-Rとかはブートディスク用によく焼いてましたが、仮想環境が整ってきたためにISOファイルをそのまま使って終わりということがほとんどでした。今となってはISOファイル自体も使わず、コンテナを使ったりしていて時代の流れを感じさせます。

それにしてもDVD-RWは2倍速しか出ないのって遅いなぁ。RW系のメディアって焼くの遅いんだよなぁ。CD-RWとか高速規格が出てすごく嬉しかった思い出がある。何回もかけるだけじゃなくて、耐久性も色素よりかはいいらしいのは良いことだ。と書いているうちに終わると思っていたが、まだ終わらない。時間が過ぎてディスプレイの電源も落ちる始末。Torrentでネットワークから落としてくるよりか遅いんじゃない? というか、ネットワークも無駄に動画とか扱うようになって余裕が出てきたというか、世界のどこかの途中で引っかかるということが少なくなってきた。

さて焼けたら日本語RemixDVDでブートしてみる。あぁそうだ、DVDにはファイナライズという処理が必要だったんだったっけ。あぁ感じが同じだからまたすっこけそうだなぁ。なんか前より長いことDVDが動いている気がする。を!大丈夫そう。デスクトップ画面まで行った。音まで出たw。やっぱ同じ16.04でもデグレしてるんだな。友好的なコミュニティーなら英語で報告しに行くけど、Ubuntuは使わせてもらってるだけなんで無視。というか自分たちで気付け馬鹿者。Debianからかすめ取っているのを最大限に感謝する意向を示さない限りはそういう献身的な行為はしない。使えるから使ってやっている。大体の人間はそんなもんだろう。

さて、たくさんあるパーティションの中から選んで、インストールした。日本語のローカライズはそこそこきちんとしている。アホな外国人が翻訳機をかけたような日本語ではない。さてUbuntuのデスクトップはどう変わっているのだろう。正直そんなに期待していないが、とりあえずFirefoxが使えれば問題ない。DebianもIceなんとかじゃなくて、Firefoxになっていたし権利関係というかライセンス関係の問題はクリアしているのね。FirefoxだけどFirefoxにあらずってのはどうにも使いにくいし、バージョンとしても無駄な手間がかかっているぶん古くなってしまう傾向にあったしねぇ。とりあえず、Chromeなんてネトゲーにしか使ってないですよ。あんな寄せ集めのブラウザなんてできれば使いたくないし、Googleにはすでに極度に依存しすぎている気がするし、これ以上べったりは嫌だ。

サードパーティのソフトをインストールを付けたので途中でハングした。インストールの時に選ぶのをやめたらインストールが最後まで終了した。問題なくインストールできたみたいだけど、放っておいて画面が消えた後にレジュームしなくなっていた。元々そんなことがあった気もしたが、マウス動かしても、キーボード叩いても、電源ボタン押しても、画面が戻らず消えたまんま。なんでかよく分からんけど、そういう状態になっている。やっぱりUbuntuはサーバとして使うのが一番だな。Desktopは気を遣うところがたくさんありすぎて、OSS的なサポートでは限界があるのではないだろうか。しかも、どういうところで動くかハードがバリエーションありすぎるし、それをサポートするベンダも多いわけではないだろう。GPUなどはプロプライエタリなドライバとかでGPL的には問題になっていたと思う。

入れたはいいが使わないかもなぁ。デスクトップの使い勝手が上がってUbuntuは名を上げたけど、正直ある時から進歩を止めてしまったような気がする。そして我が道を行って散々叩かれたUnityとかあったけど、次のLTS18.04ではGNOMEに戻るらしい。

http://archlinux-blogger.blogspot.jp/2017/04/ubuntuunitygnome.html

何でもいいから使いやすくて今後も発展できるような状態になってほしいものである。ともあれ、LinuxはコマンドラインなOSとしては一部GUI商用OSよりも安定しているぐらいだけど、GUIを加えるとその安定感が逆転する。やっぱり資本がかかっているかどうかは、集約的な作業が必要かどうかという面にかかっている。散開的な開発モデルでは何ともならない部分もあろうかと思う。基本的にGUIなOSは何が何でもGUIで解決できるようにしないといけないという縛りが強いので、できなければCUIで的な逃げは作りにくいからユーザーフレンドリーにならざるを得ない。というか、昔のようにオタクだけが触っていた時代に戻ることは許されないし、そもそもGUIのパソコンだって既に使いにくい人間も多くなってきているのだ。

そういう意味からLinuxはAndroid並みにラッピングしてあげないと使い物にならないのかもしれない。使いこなすのにベンダー試験が必要なくらいではダメなのは当然の話だ。昔はコンピュータとプログラミングが近い関係にあったのだけれど、圧倒的にアプリを使うだけの人間が増えた今、デスクトップOSというのはLinuxとしてはどうなのかと思ってしまう。Chrome OSも事実上は失敗したと言えるだろうし、実際Androidに吸収されるみたいな話を読んだ気がした。そういう意味ではパソコンをOSSでやる意味というのは、スマホが主戦場になった今、それほど重要じゃない気もする。スマホにサービスを与えているのも、GUIが必要じゃないサーバが大半なのだろうし、実際コンテナでGUI環境も確保しようという話にはなってはいないと思う。

タダのデスクトップなOSとしては面倒が多すぎるので、今まで普及することはなかったし、これからもないだろう。タブレットOSが端末として発展することはあるのだろうが、それはLinuxがカーネルですよというだけで、ユーザーランドが云々という話でもディストロがどうとかいう話でもない。こう見るとGUIなOSが割と大変な思いをして作られていることが感じられる。正直、ハイスペックなプログラマがGUIに苦心し続けるという事は考えずらい話でもある。そんな手先の事を考えるくらいだったら、自分のEmacs環境を充実させるという人の方が玄人の方には多いでしょうしね。

しかし、最近Emacsを使っている人というのをとんと見かけなくなった。そういう仕事場ではないのは確かなのだが、それにしても使っている人ってそんなに多いのかなぁと勘ぐってしまう。やっぱりカスタマイズをかけてなんぼの商品ってのは、個人的に先鋭化され過ぎてしまって、周りに広がりを見せないというのが問題なのだろう。それに他の環境行ったら一気にできなくなることが多くなってしまうし、どこにでも入っているviを使おうという気になるのが普通なのかなと思う。だからviかemacsかという宗教戦争があったのは過去の話で、結局emacs使える人はつぶしが利くようにviもある程度使えるんでしょ、という事になっちゃってると思う。どっちがいいとかそういう話もできなくはないだろうけど、そもそもプロダクトとして比べるものなのかどうかという時点から怪しい。だってスクリーンエディタという切り分けでしか合っていないわけでしょ。

ただ黙々とEmacsを使える環境にいられる事自体が恵まれているのかもしれないなと思う。大体、常駐先企業に入るとおいそれと自分の環境を持ち込める状態にあるところは少ないんだろうし。vi以前にWinSCPみたいなツールを使って、Windowsのエディタを使っているよという人の方が多いんだろうね。最初に仕事に入った時も秀丸エディタが活躍していたし、今でもWindowsやMacのエディタで編集している人も多いんだろうと思われる。viにしてもEmacsにしても、操作が直感的ではないし、習得するのに幾分時間を取る。GUIなエディタだったら酔っぱらっていても操作できそうなものだ。UNIX的なエディタでは酔っぱらって作業はできないw。

何にしてもつぶしが利く方法で不都合なく操作できればいいんじゃないというのが結論なのだろう。だから何使っても迷惑をかけないレベルで作業できていれば誰も文句を言う必要はない。ただ、無駄な縛りを効かせられる人間や環境はどこにでもあるもので、その場所によって常識は変わってくる。自分が良くできると思っている人間ほど、自分の持っている常識は間違いないと思っているが、そんなものは不確かなもので庇護の下にしか存在しえないものだと自覚した方がいい。ふんぞり返っている人間ほど、できない時オロオロして環境のせいにしがちだし。

まぁGUIだろうとCUIだろうと、面白いものが作れればいいなと思うわけで。それをタイピングで生み出すことのできるプログラマという職業を面白く思う。一時期、GUIでみんなプログラミングできるみたいな妄想をしていたことがあったが、そこまで作り上げるのに誰がコーディングするのという話になってくる。ある程度は作ってやらないといけないし、個別的な話になると手で書いちゃった方が速い場合だって多いだろう。


どうでもいいが今入れたUbuntu16.04LTSは18.04LTSまでの命だろうな。すぐには代えないだろうけど、GNOMEに戻るんならそっちの方がいいだろうし。CanonicalもスマホのOSを新規に開拓すればよかったのかもしれない。無駄にパソコンから移行させようとしたから失敗したに違いない。まぁ僕としてはAPTのリポジトリをきちんと維持運営してくれれば問題ない。Bash on Windowsもあることだし。

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

Twitterまとめ投稿 2017/06/11 [Twitter]


コメント(0)