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

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) 
共通テーマ:パソコン・インターネット

SwiftをUbuntuでやる。 [プログラミング]

以下は
Ubuntu 16.04
Swift version 3.1.1
でお送りします。んがくく(古い)

インストールの大体はダウンロードサイトのページの事を大体やってある。
https://swift.org/download/#using-downloads

SwiftがOSSになって、Ubuntu上の開発環境が提供されたわけだが、Linux上での開発が良く分からない。というか、基本GUIアプリを作るためのSwiftをLinuxのコマンドラインアプリを作るための使い方とかはあんまり見ない。まぁMacがあるのにわざわざUbuntu上でやることもないのだが、なんとなく天邪鬼な自分としてはせっかくのOSSだからOSSらしく使いたい。

そもそもOSS版で使えるのは標準ライブラリとかなんだろうけど、その範囲がいまいち良く分からなかった。MacのSwiftはGUIを主眼において開発されているから、全体としてそこをどうするかの話になってきてしまう。でも、OSSなSwiftの使うところはそこじゃない。というか、そこの部分は作られてないはず。

http://quesera2.hatenablog.jp/entry/2015/12/05/163855

一年以上前の記事だけど興味深いことが書かれている。実際に実現しているところもあるのかなぁ。細かくは分からん。

Swiftの通常版とオープンソース版の違いについて、という直球な題の記事もあった。

http://qiita.com/glayash/items/a4b1b1ffef97e649395b

一言で言うなら

Foundation
libdispatch
XCTest

ということなんだろうけど、そもそもFoundationというのがどこまでなのかが分かっていない。一つ前のリンクにあるように標準ライブラリを含んだ形でFoundationがあるようだ。

実際のAppleのリファレンス的にはどこのURLに当たるのかだけれども

https://developer.apple.com/reference/swift

ここはどうにも機能的にまとまっているわけでもなく、ただのんべんだらりとアルファベット順に書かれているだけですね。

https://developer.apple.com/reference/foundation

とここにクラス群がまとまっていますが、print文はどこに属すの~という感じで、クラスのメソッドじゃない標準のものに関しては、別途挙げていかないといけないのかなと思いつつ、SwiftはGUI部分以外はほとんど何も分かっていないなと言うことが判明。いや、そんなんでOSSなSwift扱えるんか、と。

それとやたらとNSという接頭辞がObject-Cの時代を思い出させる。Swift3.0からはそれを取ろうとしているみたいだけど、正直中途半端間は否めない。

としりごんでいても仕方ないので、実際にコンパイルして動くものを作ってみようと思う。ただ単にURLを与えると、ダウンロードしてくるプログラムを作ってみる。

まず引数からURLを取ってくるところから。GUI用の言語をCUIで使うにはまずそこからだよね。

import Foundation

//print(C_ARGV)
//print(Process.arguments)
//print(Process.argv[1])
print(CommandLine.arguments)


やっと出てきた。何だよこの情報のぶれ方はw。というか、Swiftのライブラリの命名方法がやたら変わりすぎていて、いつのバージョンで効く情報なのかさえも非常に分かりづらい。

実はimport Foundationしなくても動いた。これが暗黙にFoundationをインポートするのか、なくても標準ライブラリとして装備されているのかは分からない。そもそもFoundationと標準ライブラリの境が分からんし。

NSURLはimport Foundationしないと知らないと言われた。普通に使うには基本的にFoundationをインポートしないといけないらしい。まぁ細かいパッケージをちまちまインポートするよりかずっとマシだけれども。いまだにNS何とかと書かないといけないのは新しくSwift3に移った余波としては言語に型名を近づけるのは、主要な場所以外は限定的なのかなぁ。

ダウンロードはNSURLConnectionがDeprecatedになって、NSURLSessionになったとiOS関係の記事には書いてあるのだけれども、どっちもGUIアプリ用のイベントを前提にしたものだから、普通にコマンドラインで単純に実行するには不必要と言うか、要らない機能も含まれている気がする。ソケットを生で使う程度の低レベルのものがないのかなぁと。

ともあれ非同期的な書き方をしなければいいわけで、Deprecatedになっていようが動けばとりあえず良しとする。というか、どこまで動いてくれるのかがわかっていない状態なので、別にHTTPを特に試したいわけじゃない。

NSURLConnectionがDeprecatedになったと書いてあったが、正確には多くの関数がDeprecatedになって、同期通信は出来なくなっていた。

https://developer.apple.com/reference/foundation/nsurlconnection

デリゲートとかやらないといけないのかな。面倒くさいな。URL取ってくるだけなんだけど。もっとシンプルなクラスとかないのかな。


色々なものを参考にしたんだけど、Linuxで直で動くソースが見つからないので切り張りして何とかコンパイルできるぐらいには持っていってみる。

import Foundation

print(CommandLine.arguments)
let myUrl = URL(string: CommandLine.arguments[1])!
let req = URLRequest.init(url: myUrl)
let config = URLSessionConfiguration.default

let session = URLSession(configuration: config)
let task = URLSession.shared.dataTask(with: myUrl) { data, response, error in
  do{
    try data!.write(to: URL(string: "./text.txt")!, options: NSData.WritingOptions.atomic)
  }catch{
  }
}
task.resume()


上手く動くかどうかは知らんが、コンパイルは通ったのでその点では問題ないだろう。NSのプリフィックスは軒並みコンパイラに怒られた。まぁ使わなくていいならそれでいい。

まずLLVMか何かのエラーが出るので、実行環境の./usr/libを$LD_LIBRARY_PATHに入れる。/etc/ld.conf.dの中のファイルをいじってもいいと思う。

コンパイル後動作させると、色々共有ライブラリがないといわれているみたいで、参照先がないよと言われる。

find .|grep \\.so |xargs -i% cp % .

./usr/libにパスは通っているものの、それ以下のディレクトリには通っていないので、あるもの全部を無理やりコピーしてくる。スタティックリンク用のファイルはいらないはず。

共有ライブラリを移動させた後も、libcurl.so.4がないというので入っているパッケージを入れる。

sudo apt install libcurl3

やっと動いたと思ったら、こんなメッセージが

fatal error: shared is not yet implemented: file Foundation/NSURLSession/NSURLSession.swift, line 200
Illegal instruction (core dumped)

sharedっての、インプリされてないってよw。というか、ソケット使いたいだけなので、低レベルな関数を提供してください。それかXcodeレベルに上げてください…。色々やり方はあるみたいなんだけど、簡単にしようとして逆に八方ふさがりになっている気がする。

もう少しまともになっていると思っていたんだけど、Ubuntuの開発具合はこんなもんなんだな。というか、テキストソースに互換性がないって事なのかな。あ~Macの方はObjective-Cのライブラリをはさんでいるから、直接のインプリはObj-Cって事なのかもね。なもんで、Linux版のインプリはSwiftで全部なされてないと。

Ubuntu版の中身の進捗はあまりよろしくないと言えるでしょう。時間と共に解消はされるけれども、正直何かを作るに足る状態にはなっていないのは間違いないです。だって普通にネットワークのメソッドも使えない状態なんですよ。FoundationはSwiftで書かれているって言うことは、それに近いことを自分でも出来そうな気がしますよね。Core FoundationはC言語で書かれていて、それをSwiftで呼んでいるっぽいのを読んだ気がするので、そこまでしないとまともに使えないのかもしれない。

でも、そこまでしてまで使いたい言語なのかと言うと微妙だ。楽ができるから使うとか、iOSも開発できるから使うとか、そういうカジュアルめいたものだと思っていたんだけど、どうやらそうではない感じである。やはり商業ベースのものをOSSにするというのは、それなりにハードルが高いんだなと思わざるを得ない。

あ~やっぱり本格的に手を入れようとするとCoreFoundationを使わないといけないらしい。

https://developer.apple.com/documentation/corefoundation

でも、Swiftで直接関数を提供しているみたいなので、そこいらはC言語との兼ね合いを考えなくてもいいので楽できるのかもしれない。とはいえ、そこいらへんの情報はAppleからしか出ていなくて、サンプルソースとかあんまり出ていなさそうな気がする。コピペ厨房な自分としては、全部自力でインプリするのはめんどいなぁと思うわけで。

ただ、自分でライブラリを書こうとするとCFなんちゃらの関数は使っていかないとダメだろうなという事はなんとなく分かる。ただFoundationを無視するのは結構汎用性も落ちるし、車輪の再発明になりかねない状態だったりはする。


それにソケットのところを見ると

https://developer.apple.com/documentation/corefoundation/cfsocket-rg7

#include <sys/socket.h>
とかしていて、かなりSwift使っている感が薄くなる。

ちょっとどうしようか迷っている。Swiftで書く意味があるのか、というのが一番の問題点ではある。そもそも先ほどのコンパイルだけ通したものが、Xcodeで動くのかなというのを確かめたほうがいい気がしてきた。

そして、そもそもSwiftがiOSやMacOSのGUIアプリを念頭に置いた言語であり、Foundationもそれに沿ったものであることを心に留めておかないといけない。

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

アプリ機能の拡張とか。 [プログラミング]

So-netブログが勝手に自動保存するようになった。Gmailのエディタみたいだけど、テンポラリで保存するだけで実際の記事に保存するわけじゃないっぽい。機能的には強化されてはいるもののあまり使い勝手がいいものじゃない気がした。テンポラリだからずっと前の下書きが残っていたりして、保存していない既存の記事を差し置いて復活してしまうみたいで、これではやり方によっては自分が書き足した記事が消えかねない。

一度保存してしまうと自動保存はされなくなるみたいで、なんでこんな中途半端な機能を付けるのかなぁと思ってしまう。正直、自分たちが使ってから機能をローンチしているとは思えないのだが。機能というのは間違いなく動けばいいってものではなく、そもそもの設計がきちんとしていないと便利でもなんでもないわけだ。

確かにきちんと動くというのは、プログラミングの原則から大事だとは思う。だけど、使えない機能は使わなくなるし、アラートされても無視されて最後にはうっとうしくなる。なかなか難しいとは思うけど、ツールやアプリの利用なんて部分的なものなんだよね。全部使いこなしているなんて言う人は、プログラムに使われているとしか思えないのだけれど、必要なタスクを少ない手間でやり遂げるのが一番なんじゃなかろうか。


さて、GolangもSwiftも開発環境をLXCで整えたわけだけれど、結局何を作ろうかなぁ。最近の多くが車輪の再発明にならざるを得ないから、フレームワークを使ってサービスを立ち上げるってのが今どきなんだろうなぁ。

Golangではそこそこいろんなものが作られているから、Swiftでなんかコマンドラインベースのアプリかライブラリを書きたい気がしている。それならばviでしこしこ仕事中にでも開発できるし。しかし、SwiftはOSSになる前は盛り上がっていたけれど、今はそうでもない感じがするんだがどうなんだろう。MacとかiOSの開発ではメジャーになっているのだろうけど、OSSの方はあまり芳しくない気もしなくはない。あれだけOSSにしろという要望があったのに開けてみるとこんなもんか。というか、現状はそれほど知らないんだけどね。aptのリポジトリに登録されていない時点でOSSとしては未熟と言っていいと思うんだがどうだろうか。

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

Swiftをコンパイルしてみる。 [プログラミング]

https://swift.org/download/#using-downloads

Ubuntuは解凍してそこにパスを張って使うように薦めているけれど、なんかきちんとインストールディレクトリに入っていないと気持ち悪い。というか、こういう任意の場所で解凍しただけで動くものなんだ。Linuxの深いところを分かっていないので、ディレクトリの位置とか深く考えたことがない。

なんとなく一からコンパイルしたくなった。ただ気持ちの問題。というか、今ならコンテナもあるし、時間もあるしというところで。それにしてもググると他のSwiftが出てくるな。具合の悪いことに開発関係にもあったりするので、apt searchしても他のものが引っかかってくる。一瞬勘違いしそうになったじゃないかw。

https://github.com/apple/swift

ここにガッツリUbuntu用のインストール方法が出ている。最近はOSSだとみんなギフハブだな(ってもうAskaネタはいいってw)。シャブ患者はさておき、インストールしてみた。何気にUbuntu16.04はビルド通ってねぇって書いてあったりする。大丈夫なのかw?

かなり時間がかかりそうなので、途中でコンパイルを止めて、tmuxを入れて続行。LXCコンテナ内だとtmuxを動かすのに17.04用のdebファイルを入れない今のところLTSでは使えないのは前に書いたとおりで、入れ方を自分のブログを見た。まぁインストールはコピペで。にしても長い作業はtmuxとかでやっていないと色々と不安だ。

コンパイル作業を見ているとC++のソースファイルが多いみたい。SwiftはObjective-Cで書かれているわけじゃないのね。その割にはObj-Cとの互換性とかはあるみたいだけど、いちいちインターフェイスを揃えてあげないといけなくなるよなぁ。そこいらの言語の違いはWindowsで面倒だった覚えがある。でもLLVMで作られているからいくらか面倒が少なくなってはいるのかな。

案の定、コンパイルは通っているようなのですがテストが通っていないようで、インストールはされませんでした。そもそも16.10はコンパイルが通るけど、16.04ではコンパイルが通らないとか依存性の問題がバリバリ出とるとしか思えんのだが。まぁそもそもがMacのOSX上で依存性関係無しに作られていたのだろうから、すぐにUbuntuに依存性をクリアして移植と言うのは難しい話なのだろう。そもそも自分たちのXcode環境のバージョンを気にするだけで精一杯とかそのレベルであってもおかしくない。


しょうがないから16.04でビルド済みのtar玉を持ってきて解答してそこにパスを通した。まぁこれが普通なんだろうな。でも、swiftcでコンパイルした時に問題が出た。たった一行のhello worldも出力できなかったのだった。コンパイルは出来ているみたいなのだが、実行時にリンクするライブラリがないみたいで、実行環境は入れているのだが、バージョンがあっていないらしい。このコンパイラを作っている環境では問題ないのかもしれないが、普通にapt update && apt upgradeしている環境では足りないらしい。

またまたしょうがないから16.10でビルドすることにした。というか特に開発とかではLTS以外を使う気にはならないんだよなぁ。色々面倒くさい。

Testing Time: 1133.37s
Expected Passes : 2753
Expected Failures : 81
Unsupported Tests : 787
-- check-swift-linux-x86_64 finished --
--- Finished tests for swift ---

最後に出てきて、swiftコマンドを打つもインストールはされていなかった。失敗?と思いきや、テストしているんだからバイナリ自体はできているんじゃないかと思って
find . -name swiftc
とやってみると、案の定/build/Ninja-RelWithDebInfoAssert/swift-linux-x86_64/bin に出てきた。テストが失敗したのか、もともとやらないのかはわからないが、インストールまではしてくれていない。まぁコンパイル・ビルドが./configure&&make&&make installじゃない時点で気づけよという話なのかもしれないが、そこはOSS的なお作法とは違うところから来たものだから仕方ないのかもしれない。

とりあえず、print("Hello, Swift.")という中身を書いたtest.swiftを作って、./swiftc test.swiftをしたら無事コンパイルができて、./testでHello, Swift.が出てきました。そりゃ地元でコンパイルした開発環境だもんなぁ、当たり前か。たぶん16.04でもできていたので、環境を消してしまったけどもう一回16.04のコンテナでコンパイルしたものを、ディレクトリを見つけて動かして見たい。というかLTS以外の短い運命のOSでは開発などはしたくないんだヨォ。


あれ〜作られたバイナリを始めにやって見たんだけど、16.04LTSでもきちんと動くね。コンパイルをする環境を作ってから、始めから用意されたバイナリなtar玉を使おうとしたから、実行環境に問題が起こっていたんだね。どちらにしてもバイナリファイルを入れる.debファイルを作れたら作りたいなと思ったり。それにはバイナリはできているので、make installの記述ができれば大丈夫なのかなと思いつつ、makeファイルなんてしばらく書いてねぇよと独りごちる。

dpkg-buildpackageを使えばできるみたいなので、ちょっとお勉強して.debファイルを作ってみようかなぁ。なんかこのまま解凍してパスを通すってのはあまり綺麗じゃない感じがするんだけれど、そこまでの労力に見合った効果があればいいのだけれど。でも、依存性とか気にしなくて良くなったりするから、きちんとできればいいのかもね。というか、debファイルってディストリビューションのバージョンの依存性とかどうやって解消してんだろう。aptで吸収してそうだな。.debファイルがどのくらいの威力を持っているのかわかってないな。

って16.04でコンパイルするんじゃなかったのかよw。まぁ動く状況ならどんな方法でもいい。

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

リアルで偉そうなことを言えないから、ネットで横柄になるんだろうな。 [プログラミング]

Golangで構造体のスライスのポインタについて、調べていたときの事。
構造体のスライスと言う点で二つが絡んできて面倒なのだが、良く使うパターンであることは確かだろう。構造体を単体で扱うことの方が少ない気がするし。でもそういうサンプルは少なかったりする。んで、下記で根本的に解決はした。

http://qiita.com/ruiu/items/e60aa707e16f8f6dccd8

ここを読んでわかったのは、単純な構造体はコピー渡しだけど、スライスは参照渡しになるんだねということなんだが、技術文章でこういう風に何でこんなこともわからないんだ、みたいな言い方が良くある。

私の言うことは正しいから、良くありがちなことをけなしても良いのである、みたいな知っているものの驕りを感じるんですよね。特に技術者関係に多いんだわ、昔から。初心者を平気でタコ呼ばわりする風習があって、そういうやつに限って他のことを大して知らないタコツボに入り込んでしまっていることも多い。

なんで、私は正しいことを知っていて周りは間違っている、みたいな言い方しか出来ないのか理解できない。言い方があるだろうと思うんだけど、往々にして社会不適応な人間がコンピュータ技術者に多いのは予想が付くところだ。少なくとも営業の仕事など振れない。

でも、まとまった情報として、
文字列、インターフェイス、チャネル、マップ、スライス
が始めっから参照形式の変数だ、と書いてあるというのは有用だ。本家のリファレンスに明示的にまとまっていないから、みんなが勘違いする可能性が出てきているという事だ。

ただ何度も言うように、「Goでxxxのポインタを取っているプログラムはだいたい全部間違っている」みたいに自己顕示欲プンプンな題名からわかるように、糾弾するような言い方は頭が悪い。頭が悪いと言う言葉は悪いが、知識があるが頭の良い言い回しではない、ということだ。しかし、ちょっとだけ知っていることが多いだけでどうしてこうも高慢な言い回しになるのか訳がわからない。ポインタの使い方が間違っていることがほとんどなので気をつけて、程度の表現にとどめられないこと自体がヒューマンスキルが足りていないと自分で喧伝しているようなものだ。

GoでC言語を知らずにやっていたら、あえてはまらないであろう軽微な罠なので、それほど実害があるわけでもない意味のないポインタのポインタみたいなものに目くじらを立てる意味もないと思うのだが。まぁ確かに可読性は下がるよ。でも、著しく実行速度が落ちるわけでもないから、ポインタを使えなくて問題が出るよりか随分ましな気はするんだけど。

まぁ僕としては知ることが出来てありがたかったんだけど、教えてもらっておいて文句言うな、と言う人もいると思うんだけど、世の中には表現の仕方が残念な人がこうも多いのかと言うことで。

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

.bash_historyでRuby on Rails5インストール作業をプレイバック。 [プログラミング]

LXCにUbuntu16.04入れて、適当に一般ユーザー作る。そこから。


sudo apt install ruby
ruby -v


2.3とか結構新しいバージョンが入ってる。ver.2に入るころはかなり手を抜いていたのにね。面倒くさいからrbenvとか使わない。

gem -v


あ~rubygem一緒に入るっぽい。
これで一気にRailsが入ると思ったらどっこい。

sudo gem install rails

エラーが出た。

sudo apt install ruby-dev build-essential

まだ足りないらしくググって見る。nokogiriが悪いっぽいが。

sudo gem install nokogiri


コンパイルできないとか何とか

sudo apt install zlib1g-dev


Ubuntuのリポジトリサーバが死んでいるらしくファイルを取ってこれない。UbuntuのAPTサーバはたまに死んでいて、一日経つと復活していたりする。気長に待てないよなぁ。

仕方がないから他のものを入れる。

sudo apt install postgresql
sudo apt install elinks


elinksにおいてはずっと前に使ったっきりだから、Railsの動作確認に使えるかどうか良く分かってない。というか、まだRails入ってないから確かめようがない。

インストール作業ばっかりなんだから、わざわざ一般ユーザーでsudoする必要なかったなぁ。まぁ今度から環境設定のときは、コンテナのルートユーザーまんまで作業しよう。

あ~凡ミス。
sudo apt update && sudo apt upgrade

忘れてた。Ubuntuのメンテナさん疑ってごめんw。

すんなり通る。
sudo apt install zlib1g-dev


でもrailsは同じエラーを出していてもう一回build-essentialを入れたらコンパイルし始めた。なんでgcc入らんかったんやろ。

rails new hoge


上手くいくと思ったら、sudoの実行時にコケる。
sudo: no tty present and no askpass program specified

~/.bashrcに
alias sudo='sudo -S'
してあるから大丈夫だと思ったのに、他のスクリプト内だと有効じゃないみたい。なんか良く分からないな。LXCコンテナは色々と面倒。wettyだからnode.jsの設定でssh -tとか何とかしたほうが良さそうだ。
http://fishrimper.blogspot.jp/2012/09/ssh-sudo.html

shopt -s expand_aliases


やったけど上手くいかず。

http://qiita.com/narumi_/items/77002a12d62585da1fbe

やっぱり根本からやらんとあかんらしい。


でも問題となるところが違っていた。
まず、家に帰ってssh -t -t でつなぐようにWettyを設定してみたがダメでした。

/etc/sudoer に書いてみてもダメでした。
もしやと思い、家なので直でsshをつないでrails newを行っても
sudo: no tty present and no askpass program specified
が同じように出るので、sudoでrails newを動かしたらすんなり入って、前記のエラーが出なくなった。あんまりsudoで動かしたくないのだが仕方ない(メッセージで管理者権限で動かすなみたいなのが出てくるし)。


その後は、Sqlite関係のエラーが出るので、

sudo apt install sqlite3 libsqlite3-dev


あたりを入れたと思う。再度rails newで最後まで通る。
rails sで動かそうとするととexecjsあたりのエラーが出るので

sudo apt install nodejs


で解決。これで動くと思った。何か忘れている気もするが大体こんなもの。


LXCを抜けてホストOSに戻ってきたら、PostgreSQLが動いてた。ps axで普通に確認できた。コンテナでインストールされているものがデーモンとして動いてるのっていいのかな。ためしにコンテナを止めてみる。あ、Postgresも止まった。なんか良く分からないけど、コンテナで動いていてもホストOS側で見えるらしい。普通のプロセスは見えないのが普通だと思うけど、デーモンだからなのかもしれない。でも、なんか気持ち悪いな。コンテナでメモリ仕切っている意味ってあるのかな。

にしても、LXCコンテナの中でtmux使えないのな。どこかでUbuntu17.04を入れるとできるよ、みたいなことを書かれていた気がするが、debファイルででも入れられないものか。ちょっとしたところで、LXCで問題が出たりしていることも少なくないかも、気づいてないだけで。


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

golangでwget -rで取りにくい画像を取りにいくものを作ったり [プログラミング]

wget -rでそのサイトを網羅的に引っこ抜く方法はほうぼうで出ていると思います。Windows10ではBash on Windowsですぐにwgetを叩けるようになっているので、サイトをもぎ取ってくるには楽チンな方法だったりします。実際、私もいろいろな方法でエロ画像をとってきたわけですが、取れないものも出てくるわけです。取れないわけじゃないんだけど、wgetでやるのは面倒なパターン。

wget -rで基本有効なのは同じサイトのHTMLや画像などになります。だからwww.hogehoge.comとかあった場合、wgetで再帰的にディレクトリを辿れても、画像がpic.hogehoge.comとかにあった場合、何も指定してあげなかったら取れないわけです。-Hオプションで他のドメインも許してあげて、-Dでその範囲のサーバを指定してあげるみたいにできるとは思いますが、pic1.hogehoge.com, pic2.hogehoge.comとか出てきたら面倒で、大体は網羅的に取れません(いきなりpic7.hogehoge.comとかでてくるかもしれないから)。

そんなわけで、ドメインが違ってもその画像だけ取ってくるものをGolangで作ってみました。とはいえ、参考のサイトのを取れただけで、みんな取れるようになったわけじゃないので、とりあえずはURLを放り込んでaタグでリンクされている画像については取れるものもあるという程度です。同じドメインにある画像も取れるようにしたかったんだけど、それはwgetでやってもらうことにして、違うドメインに貼ってあるリンクだけでも取れるようにしました。

package main

import (
    "github.com/PuerkitoBio/goquery"
    "fmt"
    "os"
    "path"
    "net/http"
    "io/ioutil"
    "strings"
    "net/url"
    "strconv"
)

func abspath(rpath string, urlstr string)(string){
  if(rpath[0] == '/'){
    u, _ := url.Parse(urlstr)
    return u.Scheme + "://" + u.Host + rpath
  }else if(strings.Contains(rpath, "http://")||strings.Contains(rpath, "https://")) {
    return rpath
  }else{
    dir, _ := path.Split(urlstr)
    return path.Join(dir, urlstr)
  }
}

func getfile( url string, dir string) {
  resp, _ := http.Get(url)
  defer resp.Body.Close()

  byteArray, _ := ioutil.ReadAll(resp.Body)
  ioutil.WriteFile("./" + dir + "/" + path.Base(url), byteArray, os.ModePerm)
}

func makedir()(string) {
    i := 0
    for ; i<10000; i++{
      _, err := os.Stat("./" + strconv.Itoa(i))
      if err == nil {
        continue
      }else{
        os.Mkdir(strconv.Itoa(i), 0777)
        break
      }
    }
    fmt.Println("mkdir:" + strconv.Itoa(i))
    return strconv.Itoa(i)
}

func main() {
    geturl := os.Args[1]
    fmt.Println(geturl)
    doc, err := goquery.NewDocument(geturl)
    if err != nil {
      fmt.Print("url scarapping failed")
      return
    }
    dirnum := makedir()
    doc.Find("a").Each(func(_ int, s *goquery.Selection) {
        dir, _ := s.Attr("href")
        if (strings.Contains(dir, ".jpg")||strings.Contains(dir,".png")||strings.Contains(dir,".gif")){
          fmt.Println(dir)
          absurl := abspath(dir, geturl)
          fmt.Println("absolute: " +absurl)
          getfile(absurl, dirnum)
        }
    })
}


もちろん適当に実験しながらだったんで、再帰的には動きません。あしからず。あとエラー処理もまともにしていません。コンパイルが通るか通らないかだけで、インデントや変数の名前とかも適当です。

使い方は$GOPATHを適当に設定して
go get github.com/PuerkitoBio/goquery
してあげて、上のソースをコンパイルするかgo runするかします。
引数に取りたいページのURLを取ってあげるだけでいいはずです。

実際動かすと、同ディレクトリに0から順番にフォルダができるので、そこに画像が格納されます。同じディレクトリでもよかったんだけど、1.jpg, 2.jpg…とかのぶち当たりそうな名前を処理するのが面倒だったので、ディレクトリを作ってそこに入れました。本人が使っての感想ですが、ちまちま取りに行かなくて済むのは楽です。ただ再帰的には動いてくれないので、サイト全部とかは無理です。本当はそこまでやりたいのだけれども、いろいろ処理を加えないといけないので、wget -rで取りにくいとわかっているところだけを取れるようにしました。

goqueryで楽できたけど、もう少し改良の余地はあるなぁと思いつつ、今回は終わり。

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

久しぶりにRuby on Railsをやってみようと思ったのだけれど [プログラミング]

仕事で使うかもしれないということで、久しぶりにRuby on Railsをやってみようと思った。だけど、仕事場でWettyを使ってできないことに気づいた。すでに443番ポートをWettyで使ってしまっているからである。前に言った様にKDDIのおいたルータがヘボすぎて80番ポートを開けられない。不正アクセスが多すぎて、80番ポートを開けておくとルーターがフリーズしてしまうからだった。

そんなわけで、Webを使うRuby on Railsを使うことができないのでした。へ〜別にWebrickを3000番ポートとかで動かしているサンプルも多いから、それでいいじゃんと言う人もいるかもしれません。でも、会社のファイヤーウォールというか、プロキシが80番ポートと443番ポートの通信以外を通してくれないみたいなのです。通信の内容はどうあれ、接続先が80番とかじゃないとダメっぽい。試してないけどFTPとかは通るかもしれないけど、プロトコルの内容で止めている可能性もある。少なくともSSHは通らない。それが標準のポート番号なのか、プロトコルの内容なのかはわからない。

どっちにしてもWettyでHTTPSサーバを使ってしまっているので、使えるポートがなくて動作が見られなかったりする。遠隔でWeb以外につなぐ方法がないので、基本Webの開発はできなかったりする。今考えたんだけど、コマンドラインで動くWebブラウザをlocalhostで動かせばいいのではないかと思った。そういや、昔wgetとかSSHクライアントが良くわかってなくって、elinksとかを使った覚えがあった。当時はわけのわからないまま使っていたので、正直実用になる程使えたかどうかはわからないけれども、LynxとかLinksとかよりかは使いやすかった気はする。その当時は依存性の解決とか面倒だった気がする。そのくらい昔の話です。

よく考えるとRuby on Railsで実現できるレベルのGUIって、Elinksあたりでも再現できるんじゃなかろうかと思ったりした。というわけで、LXCでコンテナ作って、Ruby入れて、Rails入れて、PostgreSQL入れて、Elinks入れてやってみようと思う。正直、仕事中にそれをやっている余裕は今ないのだけれど、Wetty経由でもできなくはないかな。

最近はRailsの最新バージョンっていくらぐらいなんだろう。僕がガチでやっていた頃はver.3あたりだったのだけれど。

http://rubyonrails.org/
2017年3月20日でバージョン5.1.0rcって書いてある。僕が知っている頃から、内容が結構変わってそうだ。基本的なところは違わないんだろうけど。

チュートリアルの日本語版は無料で公開されていますね。英語で読むよりか吸収速度が違うので日本語の方がいいよね。
https://railstutorial.jp/

こんど環境を作ってみて簡単なものを作ってみようと思う。


これとか読むにつけ、Railsは手間を惜しむだけのものなのかなぁと

http://blog.sumyapp.com/2013/07/no-recommend-rails/
http://ledsun.hatenablog.com/entry/2013/07/24/112644

初心者にはわかりにくい、ということなんだけど、そういう論法はコンピュータにはありがちなんだよね。十分なブラックボックス化がされていないとか、デスクトップLinuxもそうだし。ちょっと問題が起こると必ずコマンドラインから修正しないといけなくなる。そしてわかっている多くの人はそれで乗り切ってしまう。だからWebを使いたいとか、Officeを使いたいだけの人にとってはあまりにも難解すぎる。正直、ファイラでGUIで辿っていける所を、cdでズンドコ進むと言うこと自体意味がわからないのもわからなくはないわけで。

RailsやるぐらいならPHPやれよというのはわからなくはないことだよね。実際素のPHPですむぐらいの規模が普通なんだろうし。Railsの問題はSQLをわからなくてもDBを使えちゃうってことなんだろうね。そこが便利な所なんだろうけど、結局得られたデータをお手軽に解析する場合は、SQLを叩くのが一番楽なんだよね。ExcelやAccessに落とすのも手だとは思うけど、ダンプするにもSQLを経ないといけないだろうし、やっぱりRubyもDBも手についていない状態で学ぶのは危険だと言えなくはない。

でも、自動車に例えると、エンジンの技術的な所を知らなくたって乗れるし、知らなくてはならないのは交通法規の方だったりする。エンジンなどが壊れた時には、整備工場に渡せばいいのだけれど、Railsというかそういうフレームワークに手を入れるのに、整備工場にあたる場所はないので自分でやるしかない。

それを言ったらそもそもRubyができているのはC言語だから、ソースから見ないといけないかと言われるとそうではないわけで、実際ソースを見ている人はRubyを使っている人としては少数派だろう。まぁありがたくそう言う人達の恩恵に預かっているわけだけれども、Railsになると自分で解決しないといけない部分も多くなると言うことなんだろう。あまりに簡単に雛形が作れてしまうところに問題があるんだろうけど、それはそれで便利でいいねでいいと思うんだけどね。苦労するときはいつか苦労するんだろうし。ただ、面倒がどちらが多いのかと言われると、基礎から自分で作ったほうがいいと言う論法もあると言う話で。

結局、どこまで作り付けのものを使うのか、と言うところであろうと思う。ものすごい専用の機械を使って、楽に高度なものを作るか、原始的なツールで手作業で作っていくか、というところでしょう。コンピュータで変わらない技術はないけれども、どれだけ潰しのきく技術を使うかというのは選択眼としては必要なものだろう。結局、必要な要件を無理のない技術で作っていくのが大事だってことなんでしょう。まぁそこいらの選択肢を選ぶのは難しいことだとは思うけど、RailsがFATで変わりやすすぎるのは困ったことですね。

PHPを使って素で作っていくことを考えると、困難が待ち構えていてもRailsを使おうと思う。どうせ内部でしか使わないシステムだろうから、バージョンが上がっても追随する必要もないし。ただ、できる人が少ないと改修とか面倒そうだな。自分がずっとそこにいられればいいのだけれど、基本的SEにそういうことは望めないし。

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

基礎からやらないGo言語で、画像URLスクレイピング(失敗したけど続行) [プログラミング]

基礎ができていないのになんとなくGo言語を書いてみようコーナー。wgetが思うさま動いてくれないので、Golangのライブラリの機能を借りてやってみようという感じのもの。wgetをapt source wgetで取ってきて、html-parse.cを読もうとしたら長くてうんざりしたのでやめました。手直しするよりいちから違う言語でスクラッチしたほうが早い。

最終的にはページにある画像をみんな取ってくるという、どうにもけしからん目的。wgetで非常にとりにくいパターンがあるんだよね。wgetは再帰的にサイトを探ることが出来るんだけど、画像が別サイトにあったりすると採るのが非常に面倒になる。出来ないことはないんだけど、上手くいかないサイトのほうが多い。


Golangにはhtmlの標準パッケージがある。良く分からん。とりあえず、画像のURLをスクレイピングするHTMLファイルを取得したい。んでファイルに保存は出来た。
package main
import (
  "fmt"
  "net/http"
  "io/ioutil"
  "os"
)

func main() {
  url := "http://google.com"
  resp, _ := http.Get(url)
  defer resp.Body.Close()
 
  byteArray, _ := ioutil.ReadAll(resp.Body)
  fmt.Println(string(byteArray))
  ioutil.WriteFile("./test.txt", byteArray, os.ModePerm)
}

必ずしも保存する必要はないけれども、このファイルを解析すればいいわけだ。htmlパッケージを使えるのかな。あんまり探して見てないけど。


スクレイピングするのにはもっと簡単な方法があって、既存のパッケージにお任せで。
http://qiita.com/ryurock/items/b0466ad144f5e0555a95
を少し変えればimg src="ごにょごにょ"
がすぐに取れる
package main
import (
    "github.com/PuerkitoBio/goquery"
    "fmt"
    "os"
)
func main() {
    fmt.Println(os.Args[1])
    doc, err := goquery.NewDocument(os.Args[1])
    if err != nil {
        fmt.Print("url scarapping failed")
    }
    doc.Find("img").Each(func(_ int, s *goquery.Selection) {
          url, _ := s.Attr("src")
          fmt.Println(url)
    })
}


引数にURLを与えると出てくるのは出てくるのだが、きょうびimgで表示させているパターンってのは少ないらしい。何だよそれw。そんなんでブラウザから表示されている画像を指定してあげるような方法じゃないと、ソースから解析してとかかなり面倒な感じ。


ということで、他の言語でも単体での画像クローリングはやめました。それって画像だけに限ってだけどブラウザ作るのと大して変わらんやんという事なので。ちょっと視点を変えてFirefoxのプラグインとして作ってみる。どうせURLとる時にブラウザ使うわけだし。

でも、一ページでaタグで別ドメインに張ってあるような画像のページはわりと楽にできそうなので、後で少し考えてみる。まぁ二つのサンプルファイルをつなげればできそうな感じだが、テキストファイルしかまだ保存していないので画像のバイナリを扱えれば問題ないだろう。それにgoで作っているからWindowsでもOKだろうし、Bash on Windowsで動かしてもいいわけで。wget -rのような再帰的動作をさせられれば、気軽にエロ画像を得られるわけで。というか、手動でやれば済むことをいちいちコードにしたがる馬鹿がここにおるw

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

WettyでつないでLXCで環境作ってどうしよう。 [プログラミング]

久しぶりにUbuntuでLXCを使っている。結構色々忘れてしまっているのだが、逐一覚えているようなものでもないので、自分のブログの覚書を見ればいいのだけれど、結局ググって最初からやり直しな感じ。

wetty経由で操作しているのだが、マウスオペレーションでコピペできないなと思っていたら、Ctrl+C, Ctrl+Vが使えたりしたので楽ができている。マウスでのコピペを出来るように実装しようかと思っちゃったよ。実際、xterm.jsを使った簡単な実装を見てしまったので、間違ってそっちのほうに行っちゃわなくてよかった。

UbuntuにUbuntuコンテナを使うと言うつまらない使い方なのだが、やはり使い慣れたディストロを使うのが面倒がなくていい。どうせ使い捨てなんだから、LTSとか守りに入っていないで最新バージョンを使えばいいのだけれども、なぜか踏み込めないヘタレ根性なのでした。

そうそう
lxc exec container-name /bin/bash
で入るんだったっけかな。
/bin/bashはbashのみでも可能な模様。

んで、16.04を入れたんだけど.2が入っていて最新でほとんどapt update && apt upgradeしないで済んだ。前は一番最初にガッツリ入れられた気がしたんだけど、リポジトリが最新になっているみたい。CanonicalもLXCに本腰になってきたというわけだ。


Python3を入れようと専用のコンテナを作ろうとしたのだけれど、デフォルトの環境に入っていました。Pythonも出世したものです。前はLLとしてRubyとどっこいどっこいだったけど、Googleが使い出して、機械学習でやたら使われるようになってから一気にメインストリームに上り詰めちゃった感じです。それにしてもPython2系がのさばっていたので、3系統に一本化できそうで良い傾向。

んで特にバージョンを気にするわけでもないので、Pythonはそのままでいいことにしました。Python2.xじゃないからいいやと言うくらいのもので。Pythonで何かをしたいと言うわけでもない気はするのだけれど、一応はディープラーニングで使えればいいなと思ってはいる。pyenvとか入れないで済んじゃったし、後はしこしこ勉強するだけだよね。



これはWettyじゃなくてLXCの問題かもしれないけど、コンテナを作ってユーザーを作ってsudoの設定をして使おうとしたら怒られた。
sudo: no tty present and no askpass program specified

結局、.bashrcに
alias sudo='sudo -S'
として設定して避けたのだが、sshのコマンドで逃げてもいいんだよね。pty.spawnのところのパラメーター設定を直すのが筋なんじゃないかと思ったり。


Pythonで勉強しようとは思っているけれども、Webがwettyで443ポートをふさがれているので、基本使えないんだよね。80番ががっつり空いてるやん、と言われればそうなんだけど、KDDIが配布しているルーターが非常に貧弱で、80番ポートを開けておくと数週間でルーターがハングする。あまりに受付する接続が多いのでフリーズしてしまうらしい。

というか、KDDIもそんな貧弱なルーターよこすなよな。KDDIがIP電話付けたいだけがために、しょっぼいルーターを使う事を強いられてるわけで。まぁ普通の人は意図的に80番ポートなんて開けないけど、営業の人がルーターを変えたい場合は応相談だって言っていたな、口から出まかせかもしれないけど。

80番ポートのアクセスログを見たことがない人は知らないかもしれないが、やたらと色々なところからアクセスが来る。他のポートにも不正なアクセスがあるわけだが、80番ポートはずば抜けて多い。一番開いている可能性が高いのか、脆弱性の高いアプリが待ち受けていることが多いのか、前に見た時は多かった覚えがある。それに比較すると443ポートは元々セキュアな通信をするという意図があるので、そこいらの意識的な高さがクラックを遠ざけているのかもしれない。ともあれ、そのほとんどはボットなどのアクセスだろうから、基本的なところを押さえておけば大丈夫。基本的に特定の脆弱性を狙っているから、穴のある機器やアプリを使っていない限りは大体大丈夫なはずなんだが。大丈夫なことを願うw。少なくともリポジトリからとれるソフトを使っている限りは最新にしておけば問題ないでしょう。


さてPython3で何しよう。Web以外ってことだけでかなり限られてくるよなぁ。今は機械学習とかPythonで流行っているけど、それだけのマシンパワーがなかったりするサーバだし。とりあえずPythonの文法を学びたいけど、何か目的がないと学びにくいのも確か。x16のスロットにGeForce入れてPythonでCUDAとかもいいな。ディープラーニングもやらずじまいだし。

そういやGolangもやってない。結構突っ込んでやろうと思っていたんだけど、いつもと同じフェイドアウトでグダグダである。でも、Go言語だったら別にWeb関係じゃなくてもやることありそうな気がするね。というか、コンパイルして速度を出したい目的とか、いろんなプラットフォームに持っていきたい場合とか使えるんだよなぁ。具体的に何やりたいか思いつかないけど。Go言語でGPGPUとかできるんかな。Pythonでできるんだからできそうな気もするけど、実際はどうなんだろう。CUDA自体が対応していた気もするが忘れた。GPGPUは面倒過ぎて見放したし。

ん~今見てきたらMini-ITXのサーバのマザーボードにはx16のスロットがなかった。x2だかx4のしかなかった。同じMini-ITXのマシンにはx16スロットが一つあるんだけど、それだと今の省電力マシンでのサーバ運用ができなくなってしまう。x16スロット使用となるとそれなりに電力消費も大きくなるし、電源も普通のATX電源を使わないといけなくなる。そうなると安定運用もできなくなる。

デスクトップ電源よりACアダプタでの給電の方が安定しているみたいなんだよね。その代わり、出力は半減以下になるわけだけど。ずっとスリープ状態でデスクトップを運用していてやっとデスクトップ電源の脆弱さが分かった。Pixivのインフラ担当の人が言っていた気がするんだけど、一番電源が壊れやすいというのは連続運用という点では間違っていない。ちょこちょこ立ち上げなおすパソコンだとHDDのクラッシュの方が目立つんだろうけど、電源は休ませないとすぐヘタるっぽい。ACアダプタも電解コンデンサとか使ってるのになぁ。なんでか分からんがそこのところは仕事も勉強もしていないので知識的に闇の部分です。


というわけでGPGPUはできない。既存のプログラムの高速化とかは無理だな。お手軽にできることって結構掘りつくされていて、自分が入り込む余地ってないのかもしれないなって思ったり。何か楽しい事ってないかなぁ。本当にゴリゴリやるなら開発環境自体に参加するとかあるのだが、それは自分には荷が重すぎる。ともあれ、LinuxでCUIのみでできることって個人的に興味を引く分野から遠いんだよね。基本、WindowsのGUIのアプリを作りたいと思って入ったクチだから、正直Linuxのツールが何とかとかあまり得意ではない。ツールを外から使うならさんざんっぱらやったから普通の人程度にはできるけど、C言語で一からスクラッチしたとかautoconfを使うようなことをしたことがあまりないんだよね。仕事でもとりあえずmakeファイルで自分のところで動けばいい的な事しかなかったし。

まぁぼちぼち気になるところをやっていければと思う。まずは久しぶりにC言語回り。Go言語にLLVMあたりかな。あとWindows系の技術を持っていきたい。まぁ大体大規模か必要じゃないもの以外は軒並み移植されてたりするから気にする必要はないのかもしれないけど。

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