文系(文化系?)SEの時事日記

C++のプログラミング

久しぶりにC++でコーディングしているので、まじめに勉強しようかなと
原典（Stroustrapの本←スペル間違っているかも。読むのもつらい）を手に取ったのですが、
すぐに挫折してしまいました。

C++を本で学ぶのは難しいですね。読んでられない。
K&Rくらいのサイズなら読めるのですが、あれは無理だわ。
まあ、他の人もどうせ同じだからよいのですが。
C++はBetter Cで使えればいいのかなと思います。
というわけでCの知識+Javaチックなオブジェクト設計で書き進める予定。

C++って「必要なときに使えそうな機能を見つけてそれを使う」というくらいの
考え方でないといきなりはきついのではないかと思いました
（原典にも書いてあったし←これくらいしか覚えていない(^^;)本棚の肥やしですね(^^;)

SEの仕事（その５）

今仕事でC++でサーバを作るような仕事をしています。

久しぶりのC++なので楽しんでいるのですが、これって経営的にはどうなんだろう？
製作コストとメンテナンスコストがJavaの方が安いんじゃないかな？
C++で作ると確かに早い（場合が多い？）、外部のモジュールに頼らないので
全部メンテナンスできる、うまく作ると簡潔なシステムになる、
といったメリットがあることはわかるのですが。
(Javaのフレームワークで作ったシステムの将来のメンテナンスってどうするんだろ？）


でも、技術者として考えるとC++でサーバ構築は面白いですよ。
（つまってくると泣きたくなることは目に見えているのですが）
TCPレベルのローレベルなところの実装をしていくことになるので
そのプロトコルがどういう風に通信するのかということが非常に良くわかりますね。
前にC++(コンパイラがしょぼいのでC with classes)でCGIをやったことがあるのですが、
そのときもJavaでコーディングしていると見えないところがわかったので
非常によい経験になりました(アップロードの処理とか大変ですよね）。

技術者としてはいろいろと触ってみることが大事だし、
基礎的な部分を勉強できることはラッキーなのでがんばろうかなと思っています。

ＳＥの仕事（その４）

長々と駄文を書いているこのシリーズの４番目は
３）システムを作る仕事
ですね。
これがたぶん一番普通にイメージしやすいと思います。
コンピュータ（または自分はしたことないけど端末）の前に座って
ぱちぱちプログラミングするという仕事です。
これはプログラマとも言われています（というかプログラマです）。
自分はこの仕事が好きですね。
無心にパンチすればよくてモノができて動くので単純に楽しいと思います。
もっともうまく動かない場合は地獄で決まった時間内にちゃんと動くように
しなければならないのでそのプレッシャーは半端じゃないことになります。
入力されたデータと出力されたデータの予想と現実の違いを埋める作業（デバック）が
地獄あわけです。これさえなければ気楽な作業なはずなのですが。
このプログラマという職業は時代に取り残されやすいという性格があると思います。
ドッグイヤーで進んでいる世界なのでどんどん技術が変わっていきます。
それにあわせて自分を変えていけないと使えないプログラマになってしまうわけです。
かといって流ればかりおって本質を押さえないといつも技術の流れに流されることになってしまいます。
バランスが難しいなといつも思います（ＳＥの仕事全般でバランスが大事なのだと思いますが）。
今だとはやりはJava+Linux+XMLあたりだと思いますが（自分の周りだけかな？）、
やっぱりＣもある程度使えるべきだし、Emacs程度でもLISPもさわっておくとよいですよね。
この世界も本当にいろいろな人がいて古い人とアセンブラの話とかすると面白かったりします。
技術って変わっていくモノですね。

SEの仕事（その３）

せっかくの連休中なのですが、仕事の話題を書いてしまう私。
サラリーマンって(^^;)前回の続きから書きます。
それはよしとして、
２）システムの内容を定義する仕事　ですが、
これは典型的なSEの仕事だと思います。
あるシステムを構築するために必要な要件を調べてその要件を設定して、
お客にその内容を説明、説得することと、
プログラマにそれを作らせるという仕事です。
大きな案件だと下請さんに仕事を割り振って監督するようなことも
含まれます。
ここは大きく提案の側の人が行う場合とプログラマの側の人が行う場合と
あると思います。どちらから行っても良いのだと思いますが、
どちらからもたたかれる可能性があるポジションなので難しいのかなと思います。
この要件の定義の段階でシステムの質がだいたい決まってしまいますね。
ここで無理すると徹夜案件（デスマーチ）になってしまうこともあります
（自分はそういう案件は逃げますが）
システムの実装についてもわかっていなければならないし、
経営や営業についてもわからなければわからなければならないしで難しいですね。
なかには丸投げの人もいるのでしょうが(^^;)
システムの内容定義の仕事はだいたいこんな感じでしょうか。

SEの仕事（その２）

独断と偏見に基づく「SEの仕事」ですが、前回に続いて説明して行きます。
１）システムの提案をするという仕事ですね。
これは前回も書いたように営業と近かったりするのですが、それだけで終わらなかったりもします。
公共系（官公庁など）の場合だと政策提言に近いような仕事もあったりします。
お役人さんたちと一緒に政策を考えたりするようなこともあるわけですね。
通信行政を行う場合にはベンダーとかいわれるところの人がその部会の委員をしていたりします。
そこまでいかなくても企業の経営コンサルに近いようなことをするようなSEはたくさんいます。
というわけでSE=コンピュータに詳しい人というのは必ずしもあたっていなかったりします。
自分も文系の人なのでそっちの方の仕事をせいと言われているのですが、
自分の場合はコンピュータが好きなのでそっちの仕事をさぼってはプログラミングばかりしています。
出世できるのか自分(^^;)
ハッカーになってしまえば違うと思うのですが、世間では提案系の方が出世していると考えられているのではないでしょうか。
というわけでシステム的な観点からいろいろと提案するというのもSEの仕事の一つだと思います。
→次回に続く