「システムコール」を含む日記 RSS

はてなキーワード: システムコールとは

2019-07-13

MastodonGab論争〜燃え上がるMast〜

前回のエントリ

anond:20190706150428

大騒ぎとなったMastの振る舞い

MastodonはAGPLで開発されており、AGPLに則れば誰しもが自由に参入し使用することができるということは前回のエントリ言及させてもらった。

まりコレはMastodon接続するいわゆるクライアントアプリケーション作成する自由も認められていることとなる。

そのMastodonクライアントアプリケーションの1つとしてiOS向けに提供されている「Mast」という実装存在する。

Mast - App Store

https://apps.apple.com/jp/app/mast/id1437429129

MastはiOSでは比較的高品質Mastodonクライアントアプリケーションとして知られ、多くのMastodonユーザから支持されている。

App Store上では¥600で提供されている有償ソフトウェアだが、ソースコードGPLv3ライセンスの元にGitHubで公開されているので誰しもがMastを自由使用することができるというフリーソフトウェア運動の一環として非常に好ましい姿勢であると見られてきた。

ShihabM/Mast - GitHub

https://github.com/ShihabM/Mast

GNU代表格に自由を重んじるフリーソフトウェア運動へ関わるFLOSSなユーザはMastには¥600を支払う価値があるとし、景気よく¥600を支払ってMastを利用した。

GitHubからソースコードをcloneし、Xcodeプロジェクト作成コンパイルビルドiOS端末実機で動かすなんてことは¥600支払った(女性かも知れないが)彼らのスキルからすると簡単すぎる手順であり、何なら自動化すらできるだろう。

スタバMacbookを用いて1回ドヤリングするよりも彼らはMastの理念に感銘しMastに¥600を支払うことへ価値見出したのだ。

そんなMastの製作者Shihab MehboobはGab問題で揺れるMastodon創始者Eugen Rochkoの提言賛同しMastへ禁じ手たるアップデートをしてしまった。

Mastを購入したユーザ同意せずMastを起動するたびにMastodonサーバへ対してユーザに無断でGabドメインブロックするシステムコール送信するアップデートを施したである

これには2つの問題がある。

  1. アップデート以前にMastを購入したユーザはMastの振る舞いへ対して同意していない
  2. Mastからシステムコール送信であるMastodonサーバはShihab Mehboobの所有物ではない

まりどういうことか?と言えばMastは¥600で購入するマルウェアと化したのだ。

百歩譲ればMastがスタンドアロン機能としてGabとの通信不可能になるアップデートを施すのならまだ擁護のしようはある。

しかし、今回のMastのアップデートは無断でMastodonサーバGabドメインブロックするシステムコール送信してしまっているのだ。他人サーバを無断で操作してしまっているのだ。

このMastの振る舞いは情報技術者へ問えば100人100人とも「マルウェア的振る舞いであることは疑いようがない」と言うだろう。

しかも¥600支払っているのである別に¥600が惜しいわけではない。フリーソフトウェア運動としてShihab Mehboobの生活の足しになればと思って多くの者は¥600を支払ったのである

¥600支払ったユーザへ対して明確すぎるShihab Mehboobの背信行為が今回大炎上しているというわけだ。

これは自由vs自由の論争である

勘違いしてならないのは、この件は別に北米極右が集うとされるGab擁護するためフリーソフトウェア運動標榜する者たちが声を荒げているわけではないということだ。

GNU宣言を読めば理解できるように、フリーソフトウェア運動コンピュータ制御権は個別ユーザへ対して帰属するべきということを一貫して主張しているだけなのである

Gabブロック個別ユーザ価値観で決定されるべきであって、AGPLを冠するMastodon創始者Eugen RochkoやGPLを冠するMastの製作者Shihab Mehboobが強制すべきではないと主張しているのだ。

Eugen RochkoやShihab Mehboobが歩もうとしているのは疑いようもなく言論統制への道であり、それはリベラリズムが憎む道でありGabが歩んでいる道でもある。

からこそ今回のMastのアップデートは許されるべきではないとされ、Eugen RochkoやShihab Mehboobはフリーソフトウェア運動標榜する者たちから反論が起きている。

これが今現在最も先進であるとされる分散SNSが抱えている問題現在進捗である

2018-10-12

プログラミング本質カプセル化ブラックボックス

コンピュータマシン語命令文もデータも数値で表す。これは今も昔も同じ。

数値だけでは人間管理しづらいので命令文を mov や add のようなわかり易い単語に置き換えたのがアセンブラ

(わかりづらい数字人間理解やす英単語に置き換えた)

アセンブラも規模が大きくなると人間には管理しずらくなる。

そのため人間言語により近い高水言語が生まれた。

if や for などで制御をわかりやすくした。

複数の処理をひとまとめで扱うサブルーチン関数プロシージャ・ファンクション

いったものができた。

(処理の流れをわかりやすくした、構造化、カプセル化

複数データをひとまとめで扱うレコード型や構造体生まれた。

カプセル化

コードデータをまとめて扱うクラスができた。

カプセル化抽象化

アプリケーションからOS機能を呼ぶシステムコールAPIが生まれ

ブラックボックス化)

複数クラスコードデータをひとまとめにするにモジュールができた。

カプセル化

プログラムを外部から操作するRPC、CORBA、SOAPRMIができた。

リモートから操作ブラックボック化)

WebAPIアーキテクチャーを超えての疎結合が進む

さらなるブラックボックス化)

IaaS / SaaS / PaaS を使いネット上のサービスにつないでシステムを構築する。サーバ管理不要に。

ブラックボックス化)

CIツールサーバ数台〜数百台を1人で扱えるようになった

操作の簡略化)

DockerWEB/DB/KVSなどをまとめてコマンド1つで扱えるようになった。

カプセル化抽象化

プログラミングとはわかりづらいマシン語人間にわかやすくするのが本質

カプセル化ブラックボックス化・操作の簡略化は正義

2018-03-26

https://anond.hatelabo.jp/20180201132629

カトラークラスのエンジニアが数十人、数十年かけて磨き上げた Linux カーネルにかなうわけねーだろ。

もはやFreeBSD人手不足で、Meltdown, Spectre にも満足に対応できない有様。

カーネルがごちゃごちゃしてたのは v3 初期までで、その後、徹底的な抽象化・#ifdefによる機能の分離化、CPU依存排除をしたおかげで、configオプションを最小化したら恐ろしいまでに小さいサイズカーネルになる上に、オレオレCPUへの移植もそれほど大変でなくなった。LLVMSSAなどの技術をBPFが取り込んだおかげで、カーネル内のモニタリングも perf関係からの置き換えの目処がたったら、そのあたりの余計なコードも削ぎ落とせる夢がある。

おかげでconfigオプションが数千にもなってしまったが、ディストリビューション多様化してくれたお陰で、自分用途に合わせたカーネル選択に困ることもあまりない。WindowsMacでも Linux システムコールラッパがほぼ完全に動くようになり、「Write Once, Run Anywhere」をVMを介さないで実現する POSIX以来の夢がいま正に実現しようとしている。

結論FreeBSDは死んだ。

2016-03-31

bash on Ubuntu on Windows面白い

発表があったんで、情報探してみるといろいろ面白いな。


checksumが全く同じUbuntuバイナリがそのままWindowsで動く

Linux用のシステムコールリアルタイムWindowsシステムコールに変換してるらしい。

apt-getも使えるからubuntu用のユーザーモード内で完結するプログラムはほぼすべて動くっぽい。

ubuntuの人も「10000を超えるUbuntuパッケージapt-getインストールできる」って言ってるみたい。

Cドライブが/mnt/cとかにマウントされてるのはFUSE使ってるのかな?


powershell要らなくなる?

bash on windowsは現状ユーザースペースしかないので、むしろ.netライブラリ触ってシステムも弄れる

powershell比較ちゃうpowershellの便利さを際立たせるだけにしかならんと思う。

でも、.net CoreLinux移植するのもがんばってるみたいだから、将来的にはどっちも似たようなこと

出来るようになると思う。

Linuxでもコマンド結果がテキストじゃなくてオブジェクトで返ってくるようになると夢が広がるよね。

メタデータ拾うのにいちいち別のコマンドで取り直す必要なくなるって結構便利だから

その利便性をいろんな人が体験して欲しい。

でもこの辺はWindowsUNIX界隈の文化の違いみたいなもんだから、どっちが良い悪いって話じゃなくて

どっちが自分に合うか、って話だね。


コレ何のために作ったんだろう?

現状Web系の開発者が、基本的ツールWindows親和性の低さが原因でWindowsではなくMacを選択していることが

B2Bをメインに据えているMicrosoft的には脅威だったんだと思う。

エンドユーザー市場Googleの焼き討ちのおかげで金にならなくなったか

ビジネスユーザー獲得をがんばってるのに、そのなかで勢いある市場Windows拒否反応示してるのを改善したいんだろう。

今のMS基本的な行動指針って「たくさんのビジネス顧客を抱えるためにネガティブイメージを極力取り除く」って感じだよね。

2015-01-29

初めてじゃなかったCの思い出

今やプログラミングといえば、Webなどで使われるような高水スクリプト言語中心のアプリケーションプログラミングが主流だ。

そんなこともあり、もはや以前の低レベル言語によるシステムプログラミングの苦労など、タダの昔話である

そこに来て、実際は齧った程度の分際で、性懲りもなくそんな昔話を書いてみる。


今も昔も、基本的に難しい仕事無茶振りから始まるものだ。

少なくとも10年位前に自分が手がけた(押し付けられた)仕事はそうだった。

大学で初めて触ったC言語しかポインタからないで止まっているような奴に、電文の再配信プログラムを任せたのだから


客は「遅延が絶対許されないシステムなのでJavaとかPerlとかはやめてねー」とにこやかな笑顔かつ笑ってない目で注文してきた。

そうなるとC/C++くらいしか事実上選択肢がない。

このうちC++は、Java経験がある自分からしても仕様が膨大かつ複雑すぎて、とても手に負えないと感じ、必然的にCで書くことに。

勿論Cの言語仕様がKR本一冊で収まるほどコンパクトであっても、それが簡単であることを全く意味していないというのを開発早々に思い知らされたのだが。

あ、Cと言えば電文提供側の機関が受信用のスケルトンプログラムを一応は用意してくれていたが、どう見ても電文受信中に接続が切れた時のことを考慮していない内容で、全く参考にならなかった。

その時点で相当ヤバいである


コード書きにおいては、例え一人屋台の俺ルールであろうが、コーディング規約のようなもの絶対必要である

その時のルールは「gccオプションに"-Wall"を入れた状態で、Warningゼロになること」にしてみたが、その途端、日付変更線をまたがない限り退社できない生活が始まった。

というかオブジェクトを使えないだけでも地味に辛いのに、更にCの言語仕様コンパクトである以上に原始的と言っていい代物で(だからWarningは基本無視できないのだ)、しか言語仕様以外の環境依存要素が山積していると来たもんだ。

そんな言語システムコールだらけのコードかつ複数ファイルディスクリプタの同時監視(即ち非同期でノンブロッキング)しかマルチプロセスシグナルもあるよ!とか、お客さんは俺を殺す気か、そもそも完成させる気無いだろとか、今だったら思う(当時はそう思う余裕もなかった)。

仕方なく最初のKRに加えて「UNIXネットワークプログラミング」をわざわざ東京に出かけてまで買って読み漁った。

後にも先にも、古今東西の名著と呼ばれるような本を、泣きながら読んだのはこの時だけだったりする。

そこまで凄い良書なのになんで絶版になったんだか。


いかし、それでも「子供を殺しても死なない」、かなり前の処理での領域破壊のせいで突然プログラムが止まっちゃうなどなど、やればやるほど問題が出る。

シグナルを受信し、仕様のとおりに処理するのがこんなに難しいのか!と途方に暮れたこともあった。

そして途方に暮れても解決の手段になるような便利なツールもなければライブラリもない。

結局、「ある程度正しく動いたら、あとは出来た所まで」で勘弁してもらってようやく開放されたが、今でも当時の自分仕事ぶりには全く満足していない。

無駄に頑張ったというか、頑張っただけの仕事であり、折角低レベル実装というCの本領発揮分野の案件でありながら、スレッドmalloc()、可変長引数は遂に習得できなかった。

こういうプログラムって、どうやったら正しく動かせるんだろ。


このような経験を経て、後年、Cやシステムプログラミングを指してギークな人々が

Cはとても高効率ですし、マシンリソースもドカ食いしません。残念ながら、Cがそれだけの効率性を実現するには、あなた自身が低レベルリソース管理(たとえばメモリ管理)を手作業でやってあげなくてはならないのです。それだけ低レベルコードがあると、複雑でバグも起こりやすいし、デバッグですさまじい時間をとられることになります今日マシンはずいぶん強力になっているので、これは通常は悪いトレードオフです――マシン時間を少し非効率に使っても、あなた時間をずっと効率的に使う言語を使うほうが賢明でしょう。

本物のプログラマアプリケーションプログラムなど書かず、まっさら金属板にゼロから書き込んでいく。アプリケーションプログラミングなど、システムプログラミングのできない弱虫のすることだ。

と言っていたことは正真正銘の事実であると痛感した。

あと、あれほど苦手だったポインタについても、「ポインタ理解できないと永久にC初心者」というのを嫌でも理解した。

あれはギターのFコードやSEALsのヘルウィークみたいなもので「習得できなかった者にとってはキャリアの終わりを意味するが、習得できた者にとっては始まりですらない」ものなのだ


・・・で、これだけで終わってしまうと本当にタダの黒歴史だが、これには少しだけ嬉しい後日談がある。

それから数年後、やはり電文転送系のシステムで、かつて自分がCのソロプレイでこなしていた規模の数万倍はあると思しき超大型案件助っ人の「兵卒」として参加したのだが、そこはインプラとアプリでチームが分かれており、アプリ側だった自分

配列ポインタ構造しか使わないで済むなんて、なんて楽な仕事なんだ!」と左うちわのんびり過ごし、しかも高評価をいただいて帰ってこれた。

実は今までの案件で一番幸福感が最高だったのは内緒である

2014-03-18

システムプログラミングは未だに難しいのだろうか

サーバサイドの通信プログラムなど、OSシステムコール使いまくり系の、所謂システムプログラミングのうち、電話の交換器とか緊急地震速報のように、処理速度と信頼性が求められる仕様ソフトウェアは、未だにUNIX系(というか実質Linux)にC/C++になってしまうのだろうか。

速さの問題でJavaPerlダメとなると、未だにシステムプログラミングはアプリケーションプログラミングよりも高難易度というイメージがある。


かくいう自分場合C言語学生時代の授業でポインタ挫折して以来、仕事画像処理プログラム実装でちょっと使ったけど結局よく分からない状態で、急病でリタイヤした人の仕事(C言語で少しだけ作った通信プログラムの引き継ぎ・納品)をムチャ振りされ、泣く泣く取り組んだ経験が半ばトラウマ化している。

だってC言語やっててポインタが分からないとか本当にド素人レベル初心者が、socket()のノンブロッキングにpipe()にsignal()にselect()無限ループで複数のファイル記述子の監視を非同期通信でfork()もあるよという世界に放り込まれたのだ(当時のLinuxカーネルはpselect()がシステムコール実装されてなかったというオマケ付き)。

K&Rと「UNIXネットワークプログラミング」片手に涙も枯れた状態で帯状疱疹作りながら挑み、最後はどうにかこうにか元請けが引き取ってくれたけど、共有メモリマルチスレッドハイレベル過ぎて手が出なかったのが悔やまれる。

これがC++(当時未経験)なら、Javaで体得したオブジェクト指向で複雑な仕様もかなり楽に出来るかと思ったけど、いざ始まってみたらC言語Linuxシステムコールを使いこなすだけで精一杯で、C++は今でも未経験と。

あとmalloc()やfree()とかも全く活用できなかった。懸案だったポインタ構造体は嫌でも覚えたけど。

というか休日遊んでいて、突然それまで分からなかった部分が理解できたのはいいが、次の瞬間「やべ!あのまま本番動かしたら洒落にならん!」という展開になり、休日こっそり会社に忍び込んで必死ソース直したこともあったっけ。

あれからもう10年近く経つ。


・・・という経験をしているので、いつかまたシステムプログラミングの仕事が振られた時のことを考えて、一応PGで飯食ってる仕事人として、何か準備しておきたいと思っているのだが、できればもう少し楽になる技術フレームワークが生み出されていると嬉しいんだけどなーという感じ。

2011-08-30

http://anond.hatelabo.jp/20110830014810

起業家タレント何が悪い?それで資金を引っ張り、製品のアピールが出きるなら結構じゃないか

エンジニアとか全く詳しくない俺でも

タレント業(ツイッターブログでうざくいろんなとこでしゃばって「企業家ぶる」こと)や

SEO的な手段にばかり邁進して

作るものゴミ、てか作る能力ゼロだろ、みたいな奴は見かける。

はてな界隈ならあの江ゴミさんとかね。

タレントだろうが何だろうが、起業しない奴よりしてる奴の方がよっぽど頑張ってると思うよ?

こういう土壌が堀江を潰したし、アイデアとパワーだけは有る若い連中の意欲を潰してるんだよ。

根本的に作る能力が無い人ほどこういう繰言が好きだけど

アイデアとパワーがある若い連中」はそういうアホみたいな「頑張ってる」っていう評価や保護は必要としてないと思うんだ。

根本的に作る能力が無い、タレント業の連中ほど、「頑張ってる」っていう駄サイクル的な評価と保護を好むし欲する。

あいつらはずるい、口先だけだ、適当にやって真面目にコツコツやってる連中を出し抜いてズルしてるなんてなぜわかる?

出し抜きはしない。

能力ない奴がどれだけ口先で目立っても、良質なサービス作って世にはばかることは無いから。

ただ彼等無能と彼等を保護したがる君のようなバカが世に何を生み出すかと言うと

大量のクズサービスと、それを目立たせようとするスパムSEO行為

まりネット世間にゴミ問題を生み出す。

あれか?ビルゲイツNTコーディングも全部やらなきゃいけないのか?

ジョブスはiOSシステムコールまで把握してなきゃいけないのか?

ゲイツジョブスぐらい才能ある人がやってるなら何もいわねーよwww

人並み以下の才能の奴に限ってタレント業が好きじゃん。

ゴミ撒き散らさないでおとなしくしててくれ。

http://anond.hatelabo.jp/20110830014810

別にシステムコールまで理解してる必要は無いが、「for文ってなんですか(^q^)」みたいな奴が

IT長者におれはなる!!」みたいなことほざいてるのが問題ってことじゃね?

http://anond.hatelabo.jp/20110824130137

いい物作ってれば売れる。

真面目にものを作る奴が偉い、いい加減この手の無骨で愚鈍ものづくり礼賛主義な老害どもにはうんざりだ。

これを読んでる奴の大半、日本人の大半は物作ってるわけじゃない。

作る奴が特別偉いわけじゃないんだよ。クソが!

作ったものドレスアップして、地道に売って歩いて世に知らしめて初めて利益を生むしみんなが使うんだよ。

起業家タレント何が悪い?それで資金を引っ張り、製品のアピールが出きるなら結構じゃないか

幾ら良いもの作ったってアピールできなきゃダメなんだよ、誰も使わないんだよ。

からあれは俺の方が最初に作ったとか言ったって負け惜しみなんだよ。

タレントだろうが何だろうが、起業しない奴よりしてる奴の方がよっぽど頑張ってると思うよ?

こういう土壌が堀江を潰したし、アイデアとパワーだけは有る若い連中の意欲を潰してるんだよ。

あいつらはずるい、口先だけだ、適当にやって真面目にコツコツやってる連中を出し抜いてズルしてるなんてなぜわかる?

ちゃらちゃらしてたって資金繰りの苦労や誰にも負けない野望、数知れない程の挫折があったりするんじゃないか

あれか?ビルゲイツNTコーディングも全部やらなきゃいけないのか?

ジョブスはiOSシステムコールまで把握してなきゃいけないのか?

違うだろ?適材適所があるんだよ。職人なんかクソ喰らえだ。

2010-07-26

linuxプロセスファイルディスクリプタを送る方法

linuxではファイルディスクリプタを使い、例えばソケットやファイルの操作などを行います。その際、あるディスクリプタを他のプロセスに送りたいことがあるかもしれません。ここではその方法を解説します。

方法

  1. ディスクリプタ送受信用のソケットを、それぞれのプロセス作成
  2. ソケットの補助データ(後述)を送るための、msghdr構造体を用意
  3. 実際に送信し、別プロセス側で受信する
1, ディスクリプタ送受信用のソケットを、それぞれのプロセス作成

ディスクリプタを別プロセスに送信するためには、送受信用のソケットを作成する必要があります。この場合は特に、unix domainのUDPソケットを作成する必要があります。

unix socketとはネットワークを介さずに使えるソケットインターフェースです。接続アドレスファイル名で指定されます。このためソケットを作った後はそのファイル作成されます。ただし、送受信データはそのファイルではなくカーネル内のメモリに保存されます。

ソケットはsocketシステムコールにより作成します。その際、第一引数にAF_LOCALを、第二引数にSOCK_DGRAMを指定することで所望のソケットを得ることができます。なお、受信側ソケットの場合は、bindにより受信アドレスを設定する必要があります。

#define UNIX_SOCKET_PATH "/tmp/socket2010"

int make_socket(int is_receiver)
{
    // create the unix domain udp socket.
    int sock = socket(AF_LOCAL, SOCK_DGRAM, 0);

    if (is_receiver) {
        struct sockaddr_un addr; // include sys/un.h

        unlink(UNIX_SOCKET_PATH);

        memset(&addr, 0, sizeof(addr));
        addr.sun_family = AF_LOCAL;
        strcpy(addr.sun_path, UNIX_SOCKET_PATH);
        bind(sock, (struct sockaddr *)&addr, sizeof(addr));
    }

    return sock;
}

2009-09-29

多分、同じ悩みを持つ人は多いと思う

プログラマ。5月から仕事が無くて、自宅待機。

いろいろ引き伸ばしていたけど、とうとう明日から無職

失業保険来年6月まで出る。そして一応貯蓄もある。

景気が回復したら今の会社で雇ってくれる約束もある。

俺は、無理に就職しないのが得策だと考えた。

つまり、今は「景気回復まで我慢する」という方針。

景気回復まで何とか食いつないで、景気回復したら何とかなるだろう、と考えている。

だけど、冷静に考えてみる。

一度失業して、間をあけると、かなり就職しにくい。

そして、今の会社景気回復まで持つかどうか、判らない。

ひょっとしたら、このまま景気回復まで我慢っていう選択肢ダメなんじゃないだろうか。

ただ、今無理に就職しても、精神と体を壊しそうに見える。

今働いてる友人達を見ても、ハードすぎる。

この年齢になるまでプログラマだけやってきた。プログラマっていうのはアレもコレもコンピュータに関わる事は大体全部出来ないといけない。

ネットワークの知識は社内LANパケットキャプチャしたら大体全部の信号意味が判る程度、サーバの設定も試験内容にあわせて変えなきゃいけないから大体やってる。ApacheHTTP-proxysendmailという一般的なところから、RADIUS、ITStage、SIPサーバもやった。ドキュメントを素早く大量に正確に作らないといけないのでワードエクセルパワーポイントVISIOも使いこなしてる、事務のお姉ちゃんより断然詳しい。Oracleだってやった。パズルみたいなSQLを読み解いて、問題解析して、またパズルみたいにSQLを組み立てて、みたいな日常を何ヶ月も過ごした。Linuxも必要があってカーネル改造した経験があるというかカーネル改造だけでここ数年食ってた。Windowsだってやった。VBVC++もやった。インストーラVisualStudioデベロッパで作って、InstallSheildで作って、でも仕様を満たさない&顧客が納得しないのでVC++スクラッチした。SIP電話開発した。SIPなら大概わかる。UNIXミドルウェア作りまくったのでシステムコールはかなり深くやった。ちなみにvi派。UNIXなら絶対viが使えるから。シェルだってABCTやった。Aシェルやったのは1回きりだけど。

ここまでやってても、でも、仕事は無いんだよ。

プログラマとして有能になるべく、頑張ってきたのに、プログラマ仕事そのものが無くなったんだよ、世の中から。

何しようかなぁ。サラリーマンっぽくない技術職がいいなぁ。

2009-02-24

http://anond.hatelabo.jp/20090223224553

結局、なにがしたいか、なにが学びたいか、だろうな。

元増田も大元増田も、とりあえず言語を学んだ。てにをは挨拶は分かった状態。それでどうするのか、とりあえず小説を書くのか、言語学を学んでみるか、ラノベ研究してみるのか。

SICPだと、プログラミングとは何ぞや?とメタ言語学的になるのかな。あと、アルゴリズムとか、より抽象的、数学的な方向へ向かうのか。

ブックマークコメントに多いのは、とりあえず作れってやつ。しかし、現状で作りたいものがあるなら、もう作っているはずで、特にないから困っているのだろう。

ジャンル的にはWebアプリGUIアプリか。あと、サーバソフトウェアもある。

Webアプリだと、HTTPとかブラウザ側と、CGIとかapacheサーバ側とのインターフェースを知る必要がある。他にもデータベースマネージャーSQLに手を出すとか、railsとかフレームワークに手を出すか。

GUIアプリだと、ライブラリフレームワークOSとのインターフェースを知る必要がある。データベースを使っても良いし、ネットワークに手をだすならSOCKETとか。WindowsならWindowsの、XならKDEとかgnomeとかの作法があるし。

GUIアプリでもだけど、サーバソフトウェアならネットワークプロトコルの他に、スレッドだとかある。

これらも、一から自分で始めてみるか、既存の、例えば自分が使ってるOSSに機能追加してみるとか。

あと、アセンブラって出てたけど、コンピューターの実際的な構造とか、OS内部、ドライバの作りなんかへ進む手もある。

元増田は標準ライブラリを使ったプログラミングフレームワークの内部構造を把握すればよいんじゃないかな。

というわけで、よりフロントエンドライブラリフレームワークの方向か、バックエンドシステムコールOSへ向かうか、

より抽象的なアルゴリズムとか情報理論の方向か、実際的なネットワークデータベースなどの周辺要素へ向かうか、

どういう方向に興味があるのか分からない事には。

2008-07-24

http://anond.hatelabo.jp/20080724035950

プログラマーお仕事

あたし・・・実は・・・プログラマーなんだ。

ずっと、黙ってて、ごめん。・・・隠してて、ごめん。

でも、どうしても言えなかったの。

あたしがプログラマーだって知ったら、きっとみんな離れていっちゃうって思って。こわくて。

わかってる。わかってるよ。

プログラマー初級シスアドを通った人だけがなることができる、カスタマープロフィットに関わるシリアスビジネスだって。

でもね・・。

でもね、全然ちがうんだよ。

あたし、みんなが思ってるようなキレイなものじゃないんだよ。

あたしは汚れている。

あたしのキーボードは、汚れているんだよ。

プログラマーになったとき、すごく嬉しかった。知り合いのハッカーになったような気でいたの。

あたし馬鹿だから、お客様ビジネスを作るんだ!なんて、本気で思ってた。

でもね、全然違ったんだよ。

元請から言い渡された Sヨ の詳細設計仕様書は全く別のものだった。

お客様ビジネスを、まるでビル・ゲイツのように平等に助けるようなものじゃなかった。

あたしたちプログラマーに課せられた任務、・・・・それは、デバッグ だった。

生きるべき仕様と、それ以外のバグのふるいわけ。

そして、それを見守ること。

ねぇ知ってた?

この世界には、あるんだよ。こんな日本のど真ん中にね、平然と、あるの。

どうなっても大丈夫バグっていうのが。

プログラマーはね、それを見守るの。

プログラマー六本木ヒルズホリエモンで、勝ち組特権階級の象徴だからね、

そこにあるだけで、まるでビジネスが行われているかのような錯覚を起こさせる。

あたしの仕事は、そうやって、平等にビジネスが行われているかのように見せる暗幕みたいなものだったの。

ソフトウェアなんて、全然、救えなかったよ。

救う義務も権利も、この任務にはなかったの。

例え、その仕様がどうすれば助かるか、明確に解っていたとしても、

あたしたちは元請の命令が無いかぎり、何一つのコーディングもできない。

苦しいとサポート電話をかけ続けるクレーマーがいても、

あたしたちにはパッチ仕様変更も与えることはできないの。

ただ、ただ、走って火消し屋を呼びに行くだけ。そして伝えるだけ。

でもね、この国の「火消し屋」は非常に貴重な存在

火消し屋は稀有な存在

夜なんかになれば、一つのフロアにどこからともなく現われるの。

たくさんのプログラマーたちが、一人の火消し屋に群がっていた。

先生、コアを吐いている人がいます!」

先生、表領域が苦しい人がいます!」

先生サニタイズが弱い人がいます!」

先生デッドロックでもがいてる人がいます!」

懸命にプログラマーたちが叫んでた。

でも火消し屋は一人。

私も声を荒げて「苦しい言い訳をするプログラマーがいます!」って叫んだの。

でも、ここでもふるいわけが始まる。

人員レベル、難度、納期。そんなものが現象と一緒くた になって命令が言い渡される。

「とりあえずスタックトレースを」

と言ったきり、火消し屋は朝までチームのもとに来れなかったの(お客さんのところに言い訳に行った)。

その日、10秒ごとに Mantis の履歴が増えた。

「苦しい、苦しい、まだ苦しい」

「もう少しだけ待ってください、今火消し屋、来ますから・・」

何度も火消し屋のもとに走ったけど・・・。

火消し屋は、今にも心臓の止まりそうなお客さんと仕様と納期の折衝にあたっていた。

あたしは火消し屋に背中側から叫んだ。

「null チェックを入れても、まだぬるぽみたいなんです!」

「ガッ!」

コメントアウトの行数を上げた。でも駄目だった。QA からの質問は止まない。

そのバグだけじゃない。

トイレに連れて行ってください(コンプライアンス的な意味で」

「基板が焼けたから替えてください」

「エスタロンを飲ませてください」

「ブートが走らないんですが」

「眠れません」

デバッガを走らせる。

忙しさにコードが荒くなる。

残業時間が 400 越えたプログラマーエレベーターに乗って外に出て行こうとする。

遠くのフロアで、缶コーヒータバコの売り切れ音が聞こえる。

必死にあたしもふるい分けた。

今、一番検収ハネられる危険があるバグから、一番仕様満たしてないバグから、手を差し伸べなきゃ。

「いつになったら納品されるんだ!」と言われても。

「単価高い」と言われても。

私は頭を下げたり、ちょっと言い争ったりもしながら、

バグが、バグが、バグが」と言う人のとこに走ったよ。

家から家族が消えていた。離婚届をかいていた。

あたしはカーネルだ!と思った。

一刻を争うバグ対。火消し屋に聞いてる時間は無かったの。

あたしは火消し屋の指示を待たずにロジック検査をした。差分プログラミングの extends だった。

急いで火消し屋に連絡した。

「差分プログラミングの extends です。継承元のコードいじっていいですか?!」

「いや、コードを見ないとわからない、ただこっちの処置があるから、10分後に行く」

コードは胸を掻きむしるようスパゲッティしていた。

「待てません!リリースします!」

あたしは火消し屋の指示無くパッチコミットした。バグの症状はスッと納まった。

それは駄目なことだったけど、一人のバグを救ったことに、あたしは浮かれてたの。

貧相な正義感をぶら下げて、意気揚々と自席に戻ってきたの。

自席の・・・・

自席のモニターの一台の波形が、フラットになってた。

あたしは急いでスタックトレースに飛んだよ。

でも、亡くなってた。

ログを吐けないプロセスさんだった。

システムコールも呼べない人だった。

あたしは、その日、目の前の苦しいバグに夢中で、ps なんか見てなかった。

それでもね、・・・あたし、まだ、プログラマーなんだよ・・。

火消し屋は QA に「いつ何があってもおかしくない COBOLer の書かれたコードでしたから・・」と時間稼ぎの工作をしていた。

QA のテスターは「ありがとうございました」と額に青筋を浮かべてバグレポートに「仕様です」と書いて取り下げた。

そして、あたしにも「プログラマーさん、ありがとね」と言ったの。

大好きな、ソフトウェアだった。

このシステムが立ち上がる頃から知っていて、αリリースから知っていて。

「自分は寂しがり屋だから、最期は dankogai に手を握ってもらいながらホッテントリ入りしたい」と言っていた。

あたしが新人の頃から知っていて、viカーソル移動が苦手だったのも知っていて、

Xenix はわしが育てた」が口癖だった。

「まぁ、・・・歳だったし、運用中にも止められないって言ってたからなー」

と火消し屋があたしの背中ごしに言った。

あたしは GC モニターの記録を見てたの。

その記録には、波形が Full GC 後もヒープ使用量が右肩上がりとなりメリリークするさまがしっかりと記録されていた。

高負荷だから死んだんじゃない、そこにはメモリリークで死んでくプロセスがあった。

でも、そんなこと全部まるめこんで、kill んじゃって仕方ないっていうプロセスが、そこにはあったんだ。

似たようなことはざらにあった。

何人ものプログラマーが、自社ビルの屋上の端から零れていったよ。

でも、あたし・・・プログラマーなんだ。

誰も、辞めろって言わないの。

火消し屋は鉄火場にブチ込まれただけだから、言わない。

顧客は実情がわからないから、言わない。

プログラマー同士は実情がわかってるから、言わない。

IPA はきっと、全部知ってて、それ込みで「それが10年は泥のように働けということだ」と言うかもしれないけど。

いや、言わないか。IPA は、何も言わない。きっと。

救えたかもしれないバグを、プログラマーは一番わかってる。見えてしまう。

PM の指示が適してないのも、判断が遅いのも、仕様変更履歴がのってないのも、全部わかってる。

それでも「あの時!」と、自分の行動と判断を何度も振りかえる。

その向こうにはいつも「あのとき、こうしておけば」が、くっきりと見える。

でも、救えなかった責任も、見過ごした責任プログラマーには問われない。

プログラマー仕事は、責任を負うことじゃないから。

プログラマーって・・ほんと、なんなんだろうね・・・。

プログラマーなんて、なんの仕様検討も許されていないのに、

パッチ一粒すら出せないのに、

設計一つ指示できないのに、

テストパターンに関わることなんて、一つも独立してできないのに、

テスト部門が持たされてるのはプログラマーコールだけなんだよ。

どんなに辛くてもプログラマーしか呼べないなんて。

そしてあたしたちは色んなものを抱えて、バグの前に立つ。

火消し屋が来ること、来れないこと、

できるデバッグがあること、ないこと、

SIer未来、残された時間

色んなことを知りながら、本当の意味世界を変えられるコーディング力もないままに、

さも救いのギークが舞い降りたかのような顔で。

IT ギョーカイが崩壊していく。

全然止められない速度で。

その日○製作所の城で、あたしは見てるんだ。

沈んでいく汎用機の命を。

それがね、2008年プログラマーお仕事



----------------

不謹慎かつ日本語崩壊でサーセンwwww

医療な人とコンピュータな人ってネット上見てる限りにおいては親近感抱いてるっぽいよね。

2007-02-06

UN*Xの好きな彼氏について

同い年で学生彼氏が今年UN*Xオタクだということが発覚しました。

相手は「抜けるんだよ、これはコンピュータ勉強をしているんだ、内容がおもしろくてしてるだけ」

と理解の苦しむ返答でばれてからまるで隠すつもりはないようです。

私はこの意味がわかりません。

ちなみに彼氏は「DragonflyBSD」などの数個のOSを使用をしていると公言し、UN*Xの歴史の話の中で「え、○○(←髭眼鏡の人の名前)ぐらい知っとけよ」といいます;

そしてお気に入りのファイルシステムもあるらしく、語ってきます;

私は彼女として見られているのか不安です。

このOSはどんな方が使用しているのでしょうか。

普通男性が利用するOSなのでしょうか。

私は興味がないので彼の話を流していますが、よくシステムコールの内容を聞かされ正直いやです。

でも彼氏趣味を干渉するのはどうかと思うので表にはだしていません。

話があっちこっちいってごめんなさい。

男の方はだれでもUN*Xを利用するものなのでしょうか。

彼氏は普段は普通のかっこうの高校生で、Windowsも使っています。

Shareでの割れ物あさりもうまく、流行祭りはくわしいです。

デーモンフィギアペンギングッズを集めるといったことではなく、カーネルハックをするのが好きで当分飽きる様子はありません;

彼女としてどのような行動をとれば一番いいのでしょうか。

よろしくお願いします。

 
アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん