「システムプロ」を含む日記 RSS

はてなキーワード: システムプロとは

2023-08-22

anond:20230822105817

理論的にも間違ってるぞ

意識しないように努力しても意識出来ない領域生存生殖に関するシステムプロセスは動いているはずだから渇望やストレスが溜まり続ける

まり原因はなくならない

知性があろうと関係ない

いや、人間肥大化した脳に様々な問題解決するためのサブプロセスがいくつも走っている状態、つまりたくさん知性があるからこそ葛藤が産まれ苦しむんだ

2023-04-10

anond:20230410150010

便乗するけど、プログラマプログラマでも、組み込み系という手もあるやで。

そっちは地味だけど、慢性的技術者足りてない。

自分経験積むのが難しい前提だから、そんなに経験無くてもやる気さえあればいける。

マイコン工作キットみたいなのを買ってきて一個作ってみるよろし。

Webシステムプログラマに対するメリットとしては、生産技術系も含めていけば、地方部でも安定して仕事があるってことこちゃね。

2022-09-11

GoやRustをただのWebアプリケーションに使って言語の良し悪しを語るな

Goシステムプログラミング向けだし、RustはOSなんかを作るような低レイヤ向けに作られた言語だよね

それにも関わらず、わざわざWebアプリケーションAPI開発なんかに引っ張ってきて、

使いにくいだの微妙言語だの言ってる人って結構な数いると思うんだけど、どういうことなの?

用途が違うんだから当たり前じゃん?

そもそもなんでわざわざGoとかRustでWebアプリケーションつくるの?アホなの?

2022-08-27

センスの無い未経験年収300万強のプログラマとして就職して必要だったこ

学歴がよくなくて、就職が困難だったので中小 SIer で働いていた。 (プライム案件を取ってこれる分マシらしい)

レキサルティレクサプロデパスのお世話になって続けてたけど、結局は薬でどうにかできず、辞めてしまった。

参考程度だけど、未経験の人が 300万 をもらうために、どのようなスキル必要かを、まとめておく。

ちなみにどれくらいプログラムが書けなかったかというと、競技プログラミング努力しても AtCoder黄色になれず青色のままってくらい。

AtCoder でいう、初心者から抜け出せないという、要するにセンスがないということなのだけど、そういう人も居そうなので、参考までに。

要するに

経験プログラマに対して、これだけ要求されるのだから、未経験の人は覚悟するようにという指針を提供したいので書いた。

入社時に覚悟しておかなければならない事

誓約書

基本的に、損害を与えた場合には、それを作業者補填するという誓約書を結ぶ。

要するに、捨て駒として扱って、失敗したら賠償しろ、という事になる。

このことを認識して、失敗しないように振舞ないと、連帯保証人含めて迷惑をかける事になる。

要するに、低賃金で未経験プログラマ案件にノーリスクで送りこんで、稼ぐための手段です。

必要だったスキル

ディレクション

基本的に PL (夢想家) → PM (御用聞き) → プログラマ という環境なので、プログラマ自分ディレクションして意思決定する必要がある。

例えば、下請け場合は、PM の御用聞きの結果の WBS に合わせないと、顧客から DM瑕疵担保責任がどうとか言われる。

社内開発の場合は、PL の方から直接、長時間の叱責を受けなくてはならない。

そういう不幸を防ぐためにも自分ディレクションして、PM の決めた実態を反映していない WBS に合わせて作業するスキル要求される。

基本的に手戻りは個人の過失になってしまうため、手戻りしないように考え抜いて意思決定をする、というのが重要になる。

これこそ、ガクチカと呼ばれる、頑張れますというスキルなので、学生時代に頑張っておけばよかったなぁ。

デザイン

こう見せたい、こう表現したい、という事を伝えるには、必然的デザイン知識必要になる。

創造思考デザインは切っても切り離せない概念で、デザインとは創造なのだから、当たり前である

ソフトウェアアーキテクチャも、ソフトウェア設計も、コーディングデザインと言えるかもしれない。

言語技術 (言語能力)

顧客と 1:1 で話す事が DM でもボイチャでも突発的に発生するので、いつ、いかなる時でも論理武装していなければならない。

まぁ、顧客であったり PL であったりはキレるのが仕事なので、それに対して理路整然と説明する必要がある。

なんとなく、では納得しないし、すぐ損害賠償請求とかそういう話にいくので、答えられないと持ち帰りますお茶を濁して、エマージェンシーになる。

後述する設計能力においても、課題を把握するための言語技術(言語能力)は重要ファクターだと思う。

ソフトウェア設計

C/C++システムプログラムフレームワーク基本的に無いので、自分概念を整理して、どのような変更、拡張があるかを考えて設計する必要がある。

この能力が弱いと、手戻りが発生しやすくなり、瑕疵担保責任を問われることになる。

読んだ本の中だと、ボブおじさんの本が、やっぱりしっくりくるなという個人的な感想がある。

ネットワークプログラム (C)

UDP で送ってくるデータを受けて 24/365 で停止しない WebAPI への繋ぎ込みという簡単作業があって、振られた。

リークしてはいけないという事で malloc禁止で、グローバル変数を利用するという変なルールがあった。

Rust で書けばいいんじゃないかなと思ったけど、Rust 書くのもシンドイし、C/C++ で、しんどくて読みづらいコードを書いた。

あとで保守する人が大変そうだけど、そういうルールを決めたのは PL だしね。

システムプログラム (C++)

なんか、特殊PCI Expressカードからベンダーが用意している SDKデータ引っこ抜いて Web API へつなぎ込む部分をやった。

データの中の特殊信号を取りたかったらしい。

一応、SDK の使い方をパラ見して 1 日で作ったので、別に負担じゃなかったけど、素人やらせるんなとは思った。

Webバックエンド (Express/Fastify + PostgreSQL)

当たり前だが、DB 作って RestAPI を生やすのは現代プログラマにとって自然にできなければならない。

なので、新規開発のサブモジュールバックエンドを任せられた。

だが、ORM の癖を把握したり、発行されるクエリ確認したりするのは、疲れる。 SQL を直書きするのはシンドイ。

結局 SQL を直書きすることにしたけど、あまりいい決断ではなかったと思っている。

それ以外は フレームワーク に乗ってしまっていいので、書き捨てる分には楽だった。

最近だと、TypeScriptPrisma 使うのが、型安全でよさそうだなと思っている。

Nest.js個人的には好み。

Linux操作 (EC2 とか)

デプロイEC2 直でやったり ECS にしたりとしていたので、ベアメタル知識必要になった。

要するに systemd のいじり方とか、死活監視の仕方とか。

個人的には、クラウド嫌いなので、ベアメタルの方が安心できる。

Bind権威DNS管理して、postfix絶対止めてはいけないメールサーバ管理するとかもあったけど、出来て当然ではある事だし。

Webフロントエンド (React/Vue)

会社Webアプリ案件を取ってきたので突っ込まれた。

経験プログラマでも、月単価 100 万以上で顧客請求してるんだから会社はそりゃ儲けるだろうと思った。

会社が一人前の経験N年のプログラマといったら、その通りに振舞う必要がある。顧客責任はないのだから

当たり前だが、WebディレクションWebデザインWebプログラミング, Webマークアップ は、全て作業者であるプログラマ仕事になる。

個人的には、これが分かれている理由が良く分からないけど、分けたい人がいるんだろう。

デザインで、CSSフレームワークを使うと、その色が出るという事で、全部 CSS手書きしていた。

tailwind が出た現在では使っていればよかったなと思う。

結局、全く分からない中、手探りでデザインし、コードを書いて、顧客に 1 日 5 ~ 10リリースするという行為をした。

顧客大手企業だったので、自社のエンジニアならもっと出来る、と叱責されまくったけど、だったら自社でやればいいじゃんと思った。

一応、今でもサービスは生きていて、ユニークユーザ数は上がっているらしい。

そして、焼き付け刃だったので、 WAI-ARIA を知らず、アクセシビリティへの配慮が足りない事が問題になってしまった。

これはなんとか保守対応ねじ込めたのでトラブルにならなかったけど、瑕疵担保責任と綱渡りだなと思った。

CI/CD 構築 (Azure Pipelines)

当たり前だが、リリースサイクルを短くしないと顧客はキレてしまうので、CI/CD を整えないといけない。

今は Github Actions とかあるけど、昔は無くて Bitrise が高いからみたいな理由Azure Pipelines で CI/CD フローを構築した。

もう Multi Stage Pipeline になってるだろうけど、Release Pipeline が GUI からしか設定できないのが辛みだった。

IaC (Terraform)

当然だが、デプロイするためには IaC を整える必要がある。

これを知らずに、コンソールポチポチしていたので、 IaC 出来てない事がバレた時に色々怒られてしまった。

今は CDK とか便利なものが出来てるんだなぁ。

自動テスト

本来テスト自動テストを整えて、質保証をしてバグを減らさなければならない。

だが、テストを書くという手間を払えなかったので、人力テストしかできなかった。

一応、リグレッションテストを人力でやりまくったので、バグ発見曲線が結合テストでの IF 不一致しかない、という結果にはなったけど

自動化できれば費用必要じゃなかったから、怠慢だと、責められてしまった。

同じような未経験の人へ

経験でも誓約書を盾に、振られた事全部を出来なくてはならない慣習があるので、プログラマはそんなに良い職業じゃないよ。

甘い考えで、プログラマになろうと思っているのなら、考え直した方がいいです。

2022-08-11

プログラミング言語の紹介

初心者Pythonから始めましょう。やりたいことはPythonでだいたいできます世界で一番人気の言語資産豊富にあります低学歴素人がなんと言おうとPythonです。Pythonを覚えるのです。簡単なので1日あれば覚えられるでしょう。

次にSQL勉強しましょう。SQLは3日くらいあれば中級者になれるでしょう。現代データベースはだいたいSQLかそれのパチモンが備わっていますSQLができると仕事の幅が広がるでしょう。

そしてJavaScript勉強しておきましょう。Webブラウザは全部JavaScriptが動きますJavaScript勉強することでWebページで遊ぶことができるようになりますスクレイピングなどの理解も深まりますJavaScriptは便利です。

さて、ここまで来たら仕事必要プログラミングは身についているので次に進む必要は無いです。コンピュータ気持ち理解するためにはC言語をかじってみるのもいいでしょう。大企業で働きたいならJava必須です。型に興味を持ったらOCamlHaskellに手を出してみても良いでしょう。システムプログラミングをしたいならGoやRustも良いです。Goバカみたいに簡単ですがRustは初心者向きではないです。

2021-06-09

職業訓練校でITエンジニアを目指す

増田に住まうITに自信ニキ、相談に乗ってほしい。

要約すると、37歳無能正社員の俺が、職業訓練校に通って未経験IT系に転職できるか、という相談

 もしくはビルメンを目指す方がベターかどうか。

俺はクソ弊社の無賃残業にブチ切れてる無能・一応正社員アラフォー男性年収300万強

 転職活動するも泣かず飛ばず

それ以前にプログラミングの独学勉強を始めるも、

 HTMLCSSJavaScriptPHPの初歩をドットインストールで習い、自分Wordpressをイジった程度で、壁にぶち当たり中。

ならばと方針転換、転職活動中に危険物乙種4類(ガソリン等を扱う初歩的な資格)を取ったので、

 シナジーありそうな電気工事士、ボイラー技士などの資格を取って活かせるビルメンナン方面での転職を考える。

  求人情報で、職業訓練校の講座を受けることで実務経験に近い扱いを得られるケースを知り、職業訓練校の説明会に行く。

職業訓練校の説明を受けた際に、ITエンジニアを目指す講座の存在を知り、その内容に魅力を感じて再び方針転換。

 訓練校の担当者さんいわく、講座を受けることは可能だが、技能習得後の年齢の壁は確かに存在すると忠告を受ける。

  (ビルメンは年齢問わず需要がある、とも)

皆さんにお聞きしたい。

以下の内容を職業訓練校で習得することで、転職に繋がる技術は身につくだろうか。

カリキュラムは要約すると以下の通り

基本情報技術者資格習得

WEBアプリ作成HTML

C言語習得

Java

電子回路理論・測定(ハードウェア

リアルタイムOSRTOS)を使用したマイコン制御システム作成

組込みシステムプログラミングによる機器作動

MySQLデータベース保守

Linuxの基礎

 以上の内容で、ソフトウェアハードウェア両方の知識を身に着け、サーバサイドエンジニアIoTエンジニアを目指すというもの

また、JavaScriptは独学での学習を続け、趣味に関するサイトWordpress作成し充実させるという目標はそれとは別に進めていくつもり。

 訓練校でプログラム言語を体系立てて学べれば、自己学習の進展にも繋がればと思っている。

ちなみに、ビルメン仕事内容や安定性に興味はあるものの、

 睡眠障害持ちのため(夜勤場合でも家で睡眠できれば問題はないが、ビルメン基本的職場に泊まるシフトがある場合が多い)

  そこがネックになるのではという危惧はある。

ビルメンサイドの意見も、もし伺えるのであればありがたい。

 ビルメン系の資格クレーン車等の資格を合わせて、清掃工場などの管理系も考えてはいるのだが…

  これ以上は本題がとっ散らかるのでこれくらいにさせていただく。

(以上の内容には、諸事情のため一部フェイクが含まれています。ご了承いただきたいと思います)

2021-03-01

anond:20210228210606

みずほ銀行は、3つの銀行悪魔合体して生まれ銀行で、当初から「3つの銀行システムを温存したままやりましょう」ということになっていた。

で、なんでこの話になったのかと言うと、結局「どの銀行アーキテクチャベースに新アーキテクチャを構築するか」という話し合いが決着を見いだせなかったからだ。

大前健一はこのことを大批判していて「こんな事やってうまく行かないなていうことはシステム屋でなくてもわかる、いわんや大銀行頭取をや」と結構激しい論調だった。

当然うまく行かなかったが、一度走り出したシステムは通常は直せない。特に今は銀行だけで判断することができず、金融庁に話を通さなくてはならないし、金融庁が一度Goを出した金港堂郷プロジェクトが間違ってましたとかは金融庁絶対同意も納得もしない。そんな顔に泥を塗られるようなことを許すわけがない。

なので、「システム老朽化に伴い、新アーキテクチャシステムを更改します」としか言いようがなかった。

これで金融庁は納得する。やった、新システムが作れる!

だが、表面化はしないが今でもこの力学は働いたままだ。統合システムがどうにかできたようだが、人の気持ちは全く統合できていない。

第一勧業銀行

富士銀行

日本興業銀行

この3つの銀行怨霊のようなものは今も社風(行風?)にしっかりと溶け込んでいて、それぞれの銀行縄張り争いは今も続いている。

例えば、こんなかんじだ。

第一勧業銀行派閥システムプロジェクトを始めるので、協力をお願いしたい」

富士銀行派閥と、旧日本銀行派閥「知りません、そっちでやってください」

第一勧業銀行派閥「いやそちらのシステムにあるこの情報とあの情報必要なんですが」

富士銀行派閥と、旧日本銀行派閥「そんなにどうしてもほしいなら上を通してもらえますか?」

それぞれの派閥の「上」の派閥は?当然同じ派閥だ。

部長級の話し合いでどのような内容の話をしているかなんか誰も知らないが、どの派閥も「どうせ無理だろうな・・・」と思いつつ部長相談して「やっぱり派閥の壁には勝てなかったよ・・・」という茶番を誰も困らないように飾って終わる。

ここは邪推しか無いが、こんな感じだろう。

K部長「こういうのが下から上がってたんだけど、こういう議事録でいい?答えキマってるっしょ?」

F部長「あー、それ下から聞いてたわ。派閥の壁とか破ろうとするやつなんて評価下げとけばいいよ」

N部長「それな、とりま議事録できたら判子押すから持ってきて、答えなんか決まってんのにマジ茶番、受けるわー」

大事なのは「みんな一生懸命話し合ったけど、ソリューションにたどり着けませんでした」という議事録だ。

というようなことを全く関係ないオレが書いているので、単なる怪文書だと思ってくれればいいよ。

2020-12-31

anond:20201231132046

FirefoxとかMicrosoftがRustに切り替えてく動向なんですけど、システムプログラムの界隈だとメモリ管理をより厳格・安全にこなせる言語で作れるならその方が好ましい

2020-07-30

クラウド時代によわよわインフラエンジニアはどんな貢献ができるか?

Infra Study Meetup #4 "インフラの面白い技術とこれから"」というオンラインイベントで以下のような質問した者です。(以下のツイートは別の方が書いてくれたものです)

Q:これからますますクラウドが拡がっていく時代に、つよつよでないインフラエンジニアがどんな貢献ができると思いますでしょうか?

A:つよつよな人とそうでない人の壁を作らない方がいい。1つでいいので強みを身につければ壁がなくなるのでチャレンジするのが良い

https://twitter.com/inomasosan/status/1288437558804766721

まず、回答して頂いたのに失礼で申し訳ないのですが、今となっては、これをつよつよの人に質問してもしょうがない気もしてます

ひとまずは、正直にオブラートに包まず「よわいやつに貢献できることなどないです。不要です。」と言われなくてよかったです。

では何故質問したのかと言うと、つよつよな人が登壇するイベントで、よわよわな人のクラウドに対する気持ち質問として少し書いてみたかったのです。

なんというか、隣にイオンができた八百屋気持ちを(実際の八百屋さんの気持ちは分からないけど)。

それはともかく、本題。ツイッター上で反応してくれた方々への回答(?)です。

そもそもつよつよという言い方が大嫌いだ。つよいとかよわいとかじゃないでしょう。なんで力自慢してるの?

https://twitter.com/youchan/status/1288439352620531712

力自慢というより、市場が力あるものしか必要としないんじゃないか、と感じてるんです。

これが仕事じゃなくて趣味なだけであれば、力自慢というか力比べというか、そういうのいらないんですけどね。

自分がつよつよでないという考えは、目線として上を向いている証拠なので前向きにとらえていい気がする。

https://twitter.com/msy78/status/1288438690176364545

謙遜して、とかそんな感じじゃなく、メッシプレーを見た後、みたいな感じなんです。

絶対に届かない、けど、食べるためにはサッカーを続けるしかない、他にできることが思いつかない、という後ろ向きな感じなんです。

「壁を作らない」 これ以上は自分が手を出してはいけない、とか勝手に壁を作らない、っていうのはいい話だな。 エンジニアである以上、教育されてないからわかりません、という人はいらないと思う。

https://twitter.com/10key3/status/1288437791580229636

教育されてないからわかりません」とはちょっと違いますけど、全く勉強してないわけでもないんです。業務クラウド使ってないのに AWS資格取ったり。

ただ、プールを満たすくらいの水が必要なのに、コップで水汲みしてるような気分。

それやってどれほど意味があるの、という感じなんです。

正直上ばっか見てもキリがないし、なんでもできる人ってあんまりいないので、何か一つある程度の期間触ってみれば、少なくともその触ったものについては上の何割かに来るので、一つ一つそういうものを増やすさらに掘り下げるかでは。インフラの人増えないから割とすぐですよw

https://twitter.com/yu_s_1985/status/1288437741827395584

「上の何割か」に行けるんですかね・・・

そこそこレベルだと、クラウドマネージドサービス使った方が良いでしょう、になってしまいそうで。

AI仕事を奪われる、は実感湧かないですけど、クラウドには仕事奪われてる感じがしてます

あと、最後の「インフラの人増えない」は、本当にありそうですよね。

高いレベルインフラエンジニアしか要らない、となってしまったら、裾野が増えない気がします。

要は、つよつよじゃないって言葉は逃げにも使えちゃうと思うのです。この質問された方がそうだとは思わないですが(悩まれてる時点で頑張りたいって思われてると思います

https://twitter.com/_inductor_/status/1288437447735406594

「この質問された方がそうだとは思わないですが」って、注意書きを入れてくれているのが優しいなぁ、と思いました。

弱気発言している人に対して「なに甘いこと言ってんの?」っていうのは簡単だと思うのです。

ただ、本当に弱っている人に更に攻撃加えてしま可能性にまで頭が回る、心を配れるのは素晴らしいですね。見習いたいです。

あと、「つよつよエンジニアとは違うから」などと言って何もしない人もいるんでしょうね。

あるいは、多少は勉強しているんだろうけど、自分から見たら努力が足りない、そういう人が、つよつよエンジニアからは見えるんでしょうね。

もし自分がつよつよエンジニアだったとしたら、そういう人に強く当たらずにいられるのだろうか。

「つよつよな人との間に壁を作らない」というのは、言う側の動機はわかるんだけど、言われる側の「自分がよわよわだと思っている人」から強者理論しか聞こえない気がしている。多分、求められてるのは修行メニューというか、もっと具体的な方法論なんじゃないかな。

https://twitter.com/y_taka_23/status/1288438588145729538

この人は、いわゆる つよつよエンジニアという印象なんですけど、よわよわの人の気持ちを考えての発言ができるの、すごいですね。

ツイッター見てたら「私もよわよわなので気持ちわかります」という人より「甘ったれたこと言ってるな」的な発言する人ばかりだったので、気持ちが救われました。

(今回の質問同意(?)した人が20人近くいたので、そういう人たちを救うためにも、強い言葉ツイートしている人だけじゃないことを世間に伝えたかったのが、この記事を書いた動機です。届くかどうかわからないけど)

で、そうなんですよ、具体的な方法論が知りたいんです。欲を言えば、現実的可能なやつで。

このツイートに連なって書かれている「システムプログラミング」は現実的には私にはちょっとハードル高過ぎそうですけど、まずは「Go ならわかるシステムプログラミング」を読んでみますGoからないですけど。



以上、最後まで付き合ってくださってありがとうございました。

これ書いてて思ったのですが、この質問した人(つまり自分)が「新人レベルの若人」と思っている人がほとんどだったと思います。実際はアラフォーおっさんです。

その情報があったら、また違ったツイートになってたのかもしれませんね。

あと、弱気発言が多いですけど、実際には、感覚的には、まだまだ十分必要とされてそうなので、そこまで深刻な気持ちじゃないです。ただ、10年後とかは怖い。

2020-04-03

anond:20200403150108

なんで理系システムプログラミングと思ってるんだろう…

例えば最もコロナ知識あるであろう感染症医のうちシステムプログラミングできる人なんて殆どいないと思うが…

anond:20200403075307

コロナシステムプログラミング関係なくね?

何でIT系の人ってIT世界の中心だと思ってるんだろう。

コロナで見えたブコメ民度.



挑戦を応援するなり、批判する代わりに良かった部分は褒めたりしましょうよ。山本五十六から何を学びましたか

追記

意見封じじゃなくて「まずは落ち着いて、あなたが出来る努力しましょうよ」という意図です。口先だけの人間になりたくないでしょ?次の世代の子供たちにそんな背中見せたくないでしょ?仲良くしましょうよ。


あと本当は増田ブコメ意味ないとは思ってないよ。日本死ねムーブメントの発端だからね。

2020-02-06

実装担当設計含む、音質設計別)

スーモ値4.6 (自分が音質を設計したわけではない、システムプログラムのみ)

ほこれないけど、ささやかな実績

2017-09-30

C言語最初に学ぶべきではないが最初に学ぶことのメリット

私は今とある大学の4年生です.

本格的にプログラミングを始めとしてコンピュータ科学を学び始めたのは大学入学してからです.

今では幸運なことにインターン都内ベンチャー企業golangpython, scalaを用いた大規模なシステム構築に携わっています.

給料日本大学生にしては破格といえるのではないでしょうか. それも大学で真面目に勉強したお陰であると胸を張って言えます.

大学の方の卒業研究では組み込み系のセキュリティに関して研究しています. 正直テーマ選びに失敗したなと思っているので大学院にいったらシステムプログラミング系の方にシフトしようと思っています.

無駄話が過ぎました. 表題に関して話しましょう.

私が大学の授業で初めて習ったプログラミング言語C言語でした. 理由教授に聞くと, 並行して座学で教えるコンピュータ科学系の専門授業全般と結びつけやすいからだそうです.

最近TwitterQiita, StackOverflowなどでは「初学者最初に学ぶべきプログラミング言語はなに?」という質問に対して, JavaScriptPythonから入るのがベストだと言う人を沢山見かけます.

私自身こういった意見には賛成です.

JavaScriptブラウザというものが有る限り20年は消えなさそうですし, Python機械学習を始め, Webシステムでも使え, 非常にクレバー言語です.

javaオススメだと思います. 30億?ものデバイスで動く言語ですしドキュメント豊富です. 色々な分野にも応用が効くでしょう.

さて, そんな中でC言語という悪い評判しか聞かない, でもやたら色々なところで使われているらしい言語最初に学ぶメリットとは一体なんなのでしょう.

一つ, 私が思いついたのはコンピュータと仲良くなれる.

というのもC言語アセンブリ機械語に比べれば, 人間にわかやすく, かつコンピュータ側にも近いという顔をもちます.

真面目にプログラミングしようとするとどうしてもそのコンピュータの仕組み(主にメモリ) について学ぶ必要が出てきます. これらの知識現代の開発に置いて役立つ分野比較的限られると思います.

しかし, それらは思わぬバグ特定意図していない動作改善に役立つことがあるかもしれません(実際に私もいくつか出会いました)

二つ目は他の言語を学ぶ時のハードルが非常に低くなる. これはどの言語を学んでも同じだとは思います.

そして, 他の言語の高級な機能に思わず涙ぐみながら感謝すること間違いなしでしょう(javaのsplitとか他の言語にもあるHashとか)

ただ, 私はC言語構造体やポインタのお陰でオブジェクト指向プログラム言語を低レイヤ実装的な面と概念的な面ですんなりと理解することができました.

そしてよく挫折ポイントとなるポインタ(ダジャレじゃないですよ?). これもメモリの住所だと考えればそれほど難しくはないのです.

メモリ管理を適切に設計した時あなたプログラムボルト並みに早く走ってくれるかもしれません.

他の言語では味わえないやりがいがあるのもこの言語の魅力でしょう.

書いているとこれぐらいしか思いつきませんでした.

それでもコンソールに初めて Hello World! が出力された時の感動はやはり忘れられません.

昨今, 高機能言語が沢山ありますが, あなたプログラミング生活ささやかアクセントとしてC言語を学び直してみてはいかがでしょうか?

きっと今使っている言語普段言わない感謝言葉を述べること間違いなしです.

それではこんな駄文に付き合っていただきありがとうございました.

一刻も早く世界からC言語が消えることを祈っています.

2017-01-22

ownership とシステムプログラミングその他に関する怪文書

この会話ログフィクションであり、実在人物地名団体とは一切関係ありません。

坂木

わろた

Rust vs. Go に対する @tanakh さんの発言まとめ

https://togetter.com/li/1072495

坂木

自分理解できないもの意味がないと思いこみたがるタイプの人だということがよく分かったので原文を読まずに済んだ。ありがたいまとめだ。

安原

NTPsec が,ownership を理解していない開発者たちの声が大きくなるようなコミュニティによって開発されているということが分かって大変有意義でした(こなみかん

宮森

今までCで開発してきたプロジェクトを移すなら極端な話ownershipを理解しなくても良いわけで、悪くないのではと思う。

宮森

……が、理解できないものに対して、理解を試みず~すべきだ~と設計しろ、っちゅう人が作るソフトとはちょっと関わりたくないと思う。

安原

いや,私は C で開発してきたプロジェクトであるならばなおさら ownership を理解していないといけないと思います. ownership に理解を示さなコミュニティが関わってきた一定規模以上の C によるプロジェクト……私の第一感は「こわ…近寄らんとこ…」です.

宮森

いや、Cで開発してきた人たちって、ownershipを自前でコントロールできると思っている(思い込んでいる)人たちですんで……こわちかは同意

安原

いや,私は C で開発してきた人たちの多くは,そもそも ownership の概念を獲得していないのではないか危惧しています.元々,私はもっと楽観的で,多くの C プログラマは ownership の概念を獲得していると思っていました.

宮森

あ、それはそうだと思います概念を獲得していない

リソース人間管理をすれば適切に管理できる、という思想の下に皆さん書いていらっしゃるので……。

安原

OpenSSL騒動の時,関数の途中で return したことによるリソース漏れ揶揄したことがありますOpenSSL のようなインターネットの基盤を支えるオープンソースプロジェクトにおいてさえ, ownership の概念を獲得していれば脊髄反射で気づくであろうバグが随所に見られたことには本当に絶望しました.

安原

ああ,はい人間を信頼しすぎているというのはいかにもありそうですね.

藤堂

C++er の方がその辺もっときちんとしているように見える

安原

しろ C++ によって ownership という概念が明確になり,その重要性が認知されるようになったのではないでしょうか? これについては,私は歴史的なことが分からないので真偽のほどは何とも言えませんが.

宮森

シニア開発者しかC++/Rustが受けないと思うの、まさにその点だと思っていて、人類を信頼したがために足どころか頭を吹き飛ばす経験を積んでいないからだろうなー、とか。

宮森

OSとかシステム系のプログラマの人々、基本的リソース人間が適切に管理するし管理できると考えている人が多い印象([検閲削除]社時経験)。言語側で安全を確保したい、的な話をしても相容れなかった記憶が。

坂木

[検閲削除] のコードには、間違って自分の足どころか頭を撃ち抜いてしまった偉大な先人たちの知恵が詰まっていて、開発していてとても勉強になります。なお [検閲削除] は頭がなくなっていることに気づかずゾンビとして生きている模様。

今井

自分が知っている C 「しか」書けない職業プログラマ基本的地雷だなぁ...。

今井

リソースどうこう以前に、そもそもちゃんと構造化されてるコードが書けるかも怪しい(個人の感想です。見識にバイアスがかかっている可能性があります)

安原

うーん,数値計算系のチームやコミュニティも ownership の概念の獲得,重要性の理解,その管理自動化することへの理解,これらを期待するのは難しいだろうなあ…….そもそも高度なリソース管理必要になる場面少ないし…….

坂木

コード品質が強く求められるプロジェクトとそうでもないプロジェクトがあるからなあ。クライアントサイドソフトウェアは割と品質が求められる気がする。

安原

OS 実装とかシステムプログラミングって,クライアントに直接接しないだけで,その上にクライアントサイドソフトウェアが載るわけで,コード品質が強く求められると思うのですがそれは…….まあ, API とかで切り離されているので,そこだけしっかりしていれば,という話はあるか.

宮森

そこはコードレビューテスト等でカバーっちゅう。まぁ確かにコードには実際assertが入りまくったりするわけですが。

坂木

品質が強く求められるからといって品質が高いわけではないのが問題ですね

今井

あとは、デモが作れればいい、的なのも同じかなぁ。

宮森

メモリ管理、freeせずに終了してOSに全て回収させれば管理しなくて良い。

宮森

メモリ管理コンパイル時に全て静的なサイズで確保すれば管理しなくて良い。(FORTRAN77並の感想)

安原

OSGC してくれる論, TPO をわきまえているならば普通にありですよね(TPO をわきまえているならば!).

今井

まー、 offline で動くバッチ、的なのはそこまでメモリ管理とか / パフォーマンスとかにもシビアにならなくていいし(最悪オーダーがほどほどならよい、的な)、そいう文化にいると、雰囲気にのまれる人が多い、というのはまぁわかる。

坂木

私は基本その文化で過ごしてきたので現在進行形でわりかし困ってますね……

今井

あれ、そうなんです? 私がかかわった人のなかでは、コード見ててもむしろカッチリしてるほうだと思ってたのですが...。

(つまり、ここから坂木さんのハードルめっちゃ高いという帰結が...)

宮森

いろいろ言っていますがワタクシ、そういう管理必要プログラムは全く書けなくなりましたので今書くと死にますプログラム顧客大事データが)

安原

しかし,システムプログラミング界隈に「人間リソースを適切に管理できる」という悪しき信仰がはびこっているの,何か構造的な原因があったりするのかなあ?

宮森

システム系、基本的に生のハードウェアが透けて見える言語を使う必要があって、そのために選択肢がCしかなくて、手段が限られているからこそ信仰が発生した、という認識

宮森

実際、Linuxカーネルとか、規模からすれば驚異的に少ない数のバグで動いているので、信仰心が生まれ気持ちも分かる。

宮森

他の言語OS書くっていうのも研究レベルではあるけど、実用になっているのは見たこと無いですねぇ……。

坂木

Linux カーネル、一体どうやったらあの規模のコードクオリティコントロール出来るのか本当に不思議

安原

Linux カーネルのアレは,属人性依拠しすぎていて全然スケールしないのでは…….

坂木

Linux カーネル属人性高そうではあるけどそれでも実際に十分スケールしているからなあ…… ヤバいレビュアーごろごろしているのかな

宮森

属人性依拠しさえすればできるので十分な数の開発者がいれば問題になりません(キリッ

安原

私も [検閲削除] のコミュニティを見てましたから,各々必要ドメインにおける圧倒的なタレント性を持った人たちが1ヶ所に集結して奇跡アンサンブルを奏でうる場合がありうるのは理解しているんですが,本当にただの奇跡しかないと思っています

宮森

つーても機械エンジニアリング町工場職人芸を必要であれば使うように、属人性を求めるのも一個の正しい戦略だと思うんですよね。

宮森

なおその対極がみずh(省略されました

安原

Linux カーネルにおけるスケール云々は, Linux カーネルコミュニティ自体におけるスケーラビティではなくて,(システムプログラミングコミュニティ全体(他のプロジェクト)へスケールするかどうかを言ったつもりでした.

坂木

まあ人外を集めるという手法一般にはスケールしないですからね……

宮森

C系がシステム系で優先されるの、ツールを変えるとツール独特の罠があるので、罠が全て分かっているツールを使う、っつうのもあるな。

安原

システム系、基本的に生のハードウェアが透けて見える言語を使う必要があって、そのために選択肢がCしかなくて、手段が限られているからこそ信仰が発生した、という認識

これが原因だとすると,やはり Rust だ……Rust しかない…….ツール周りとか,まだまだ未整備な部分たくさんあるけれど……そこをクリアすれば…….

坂木

Rust は 1.0 が出る直前くらいにちょっと触ってイテレータが作れなくて敗北したっきりだな。

坂木

イテレータっていうか Java でいう Scanner を作ろうとしたんだっけ。サードパーティライブラリも探してみたけどその頃は I/O 周りの API が unstable でビルドが軒並み壊れていたりしたな……

藤堂

1.0 以前のことは忘れましょう (本当に unstable)

安原

Rust,型でエラーを弾くだけではなくて質の低いプログラマまでも弾く印象.

坂木

一般に型の強い言語は質の低いプログラマを弾きますね(Haskell などを思い浮かべながら)

安原

「Rust 経験者」という条件でプログラマ募集して,それで入ってきた人材に C を書かせればよいのでは!(ピコーン!

藤堂

犯罪ですよそれは

安原

はい

藤堂

haskell 経験者を集めて php 書かせようとした会社がどこかにあったような (ヘイトけがたまる)

安原

まさにそれをイメージしていました.

宮森

どういう顛末になったか詳しく知りたいw

藤堂

うーん、それ以降の話は知らず

今井

Rust そして誰もいなくなった、にならないかが一番心配だったりする

安原

それな

宮森

もしかして、NTPsecの人がRustでミニサーバーを起こすのにすら苦労していたの、普段からバグありのコード生産しているからなのでは、という気がしてきた……。

(この辺で一同寝落ち

2016-12-06

astahでシーケンス図書いてるときマウスカーソル勝手メッセージの矢印になるのがうざい

ツールシステムプロティダイアグラムエディタドローサジェスト有効にする のチェックOFF

astahでシーケンス図書いてるとき関数名の候補が出てきて勝手にそっちが優先されるのがうざい

ツールシステムプロティダイアグラムエディタコンテンツアシスト有効にする のチェックOFF

あーずっとうざかったけど設定解除方法全然わからんかったけどようやくわかってすっきり

2015-11-12

参考訳:拡散したJavaシリアル化の脆弱性についてApache Commons声明

原文:https://blogs.apache.org/foundation/entry/apache_commons_statement_to_widespread

原題Apache Commons statement to widespread Java object de-serialisation vulnerability

翻訳日:2015年11月12日(午後にタイトル日本語しました)

----

2015年11月1日 火曜日

Apache CommonsJavaオブジェクトのデシリアライゼーション脆弱性に関するステートメント

著者:Bernd Eckenfels(コミッター), Gary Gregory(Apache Commons副責任者)

AppSecCali2015 でGabriel Lawrence (@gebl) と Chris Frohoff (@frohoff) によって発表された "Marshalling Pickles - how deserializing objects will ruin your day" は、信頼されないソースからシリアル化されたオブジェクトを受け取るときセキュリティ問題をいくつか明らかにしました。主な発見は、Java オブジェクトシリアライゼーション(訳注:seriarization/シリアル化/直列化=ネットワークで送受信できるようにメモリ上のオブジェクトデータバイト列で吐き出すこと。シリアル化されたJava オブジェクトRMIなどのリモート通信プロトコル使用される。)を使用する際に任意Java関数の実行や操作されたバイトコードの挿入さえもを行う方法説明です。

Frohoff氏のツールである ysoserial を使って、Foxglove Security社のStephen Breen (@breenmachine) 氏はWebSphereJBossJenkinsWebLogic、OpenNMSといった様々な製品調査し、(http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/) に各々の様々な攻撃シナリオ記述しています

両者の調査活動は、開発者Javaオブジェクトシリアライゼーションに信頼を置きすぎていることを示しています認証前のシリアル化されていないオブジェクトにも。

Javaにおけるオブジェクトのデシリアライゼーション(訳注:de-serialization/非直列化=ソフトウェアで扱うことができるように、送受信されたデータを元に戻すこと)が行われるとき、大抵は想定された型にキャストされ、それによって、Javaの厳しい型のシステムが、得られた有効オブジェクトツリーだけを保証しています

不幸にも、型のチェックが起こるまでの間に既にプラットホームコードが生成されて、重要ロジックは実行されてしまっています。そのため、最終的な型がチェックされる前に、開発者コントロールを離れた多くのコードが様々なオブジェクトの readObject() メソッドを通じて実行されてしまます脆弱性のあるアプリケーションクラスパスから得られるクラスの readObject() メソッドを組み合わせることで、攻撃者は(ローカルOSコマンドを実行するRuntime.exec()の呼び出しを含めて)機能を実行することができます

これに対する最も良い防御は、信頼されていないピア通信相手)とは複雑なシリアルプロトコルを使うことを避けることです。ホワイトリストアプローチ http://www.ibm.com/developerworks/library/se-lookahead/実装するように resolveClass をオーバーライドするカスタム版の ObjectInputStream を使うと、影響を制限することができますしかしながら、これは常にできることではなく、フレームワークアプリケーションサーバがエンドポイント提供しているような時にはできません。簡単な修正方法がなく、アプリケーションクライアントサーバプロトコルアーキテクチャを再検討する必要があるため、これはかなり悪いニュースです。

これらのかなり不幸な状況において、エクスプロイトのサンプルが見つかっています。Frohoff氏は、 Groovy ランタイムSpringフレームワークApache Commons コレクションからクラスを組み合わせるサンプルのペイロードに gadget chains (ガジェット・チェーン)を見つけています(訳注:provided)。これはこの脆弱性エクスプロイトのためにより多くのクラスを組み合わせられることは完全に確実なことで、しかし、これらは今日攻撃者が簡単に得られるチェーンです。

(Twitter画像)https://blogs.apache.org/foundation/mediaresource/ce15e57e-94a4-4d7b-914c-8eb8f026659c

この脆弱性のために利用される(訳注:blamed)ことができない確かな機能実装するクラスができ、安全性が信用できないコンテキストにおけるシリアル化を利用されないようにするような既知のケースの修正ができたとしても、少なくとも分かったケースだけでも継続的修正していくことが要求されますモグラ叩きゲームを始めるだけであるかも知れませんが。実際にはこれは、オリジナルチームが Apache Commons チームに警告が必要だと考えていない理由で、それゆえに比較的、活動開始が遅れました。

Apache Commons チームは InvokerTransformer クラスのでデシリアライゼーションを無効化することによって commons-collection の 3.2 と 4.0 のブランチにおける問題対処するために、チケット COLLECTION-580(http://svn.apache.org/viewvc/commons/proper/collections/branches/COLLECTIONS_3_2_X/src/java/org/apache/commons/collections/functors/InvokerTransformer.java?r1=1713136&r2=1713307&pathrev=1713307&diff_format=h) を使っています議論されているやるべきことのアイテムは、変化させる仕組み毎(per-transformer basis)に、プログラマティックに有効にするような機能提供するかどうかです。

これには前例がありますOracle と OpenJDK JRE の一部であったり、バイトコードを挿入して実行することを許したりする com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl クラスで、セキュリティマネージャー定義されているとデシリアライゼーションを拒否します。

これはシステムプロパティ jdk.xml.enableTemplatesImplDeserialization=true とすることで無効にできますApache Commons Collection は、本来よりもこの実行モデルは一般化していないため、セキュリティマネージャー存在独立したこの機能無効化することを計画しています

しかしながら、明確化のために述べておくと、この便利な"ガジェット"は、唯一知られている方法でもなければ、特に未知のものでもありません。そのため、インストールされたものを強化されたバージョンApache Commons Collection に置き換えることが、アプリケーションをこの脆弱性に対抗できるようにするわけではありません。

このブログポストレビューのために Gabriel Lawrence に感謝したいと思います

Apache Commons Collection は、Java コレクションフレームワークに加えて追加のコレクションクラス提供する Java ライブラリです。InvokerTransformerコレクションにあるオブジェクトを(特にリフレクション呼び出しを通じてメソッドを呼び出すことで)変換するために使うことができる Transformer ファンクションインターフェース実装の一つです。

一般のSallyによる2015年11月10日午前10字15分にポスト | コメント[1]

コメント

OracleWeblogicセキュリティアラートを発行しています

http://www.oracle.com/technetwork/topics/security/alert-cve-2015-4852-2763333.html?evite=WWSU12091612MPP001

提供されている回避策は、T3プロトコルへのアクセス(とリバースプロキシーにおけるT3メソッドフィルタリング)です。

2015-11-06

学生時代は自宅にLinuxしかなかったので

実験結果を解析するプログラムをCで書き、解析結果をgnuplotグラフ化し、グラフを貼り付けたレポートTeX作成するのを、全てemacsだけで行うという、今思うと労力だけは修行僧並みの苦行をこなしていた。

結局、このスタイル修士論文書き逃げするまで続くことになる(論文の図表は当然のごとくtgif)。

「役に立つけど、死ぬほど使いにくい」とはどういうことかを身を以て経験した感じである


しかし、この修行もどきが原点になったおかげか、今流行Web系の諸々の技術は、さほど難しいと思わなかったり。

また、就職後に経験したオブジェクト指向システムプログラミングも難しいっちゃ難しかったが、なんとか投げ出さずに仕事をこなせたのは上述の経験が肥やしになったからかも。

一方で、同じ頃に知ったRDBの、その恐ろしく合理的で分かりやす思想に感動したり、ここ数年コーディングで小技的に使うMapとReduceをコンピュータ科学の素晴らしい成果だと本気で思えたりしたのも、出発点のハードルがやたら高かった故な気がしている。


しかし、それを踏まえても、あいつらの使いにくさはどうにかならなかったのか。

「役に立つのがそれしかないから泣く泣く使う」なんて、経験しないで済むならそのほうがいいに決まっている。自分が怪我の功名的な肥やしにできたのも結果論しかないし。

てか今時の学生は、こういう作業に何を使っているんだろう。

できれば、自分が当時使っていたツールが全て駆逐されていることを願うばかりである

2015-04-10

最近システムソフトウェア開発のトレンドが分からない

10年位前、上位のサイトから電文を受け取り下位のサイトに再配信するプログラムを、Linux上にC言語実装する仕事を引き受け、死ぬ思いで片付けた。

その時にお世話になったのが「UNIXネットワークプログラミング」という本。

この本、POSIX準拠OS(要するにLinuxなどのUNIX系OS)におけるシステムプログラミングのノウハウに関しては名著、いやバイブルと言っていい。


しかし、である

この本は今や絶版なのだ

名著が絶版になる理由は色々あるだろうが、この本に限って言えばもはやそういう時代じゃない、そういう低レベル実装トレンドじゃないということなのだろう。


でも、そしたら「決して遅延が許されない再配信プログラム」は、一体何をどう使って作るんだ?

JavaPerl?全くイメージが湧かない。

プロセス間通信やスレッド制御、更にはシグナルも使い、それらが高速で動作しないといけない(いやスレッドは難しすぎて結局使わなかったけど)システムで、そんなオーバーヘッドが高い言語は使えないと思うのだが。

それらを解決できる気の利いたライブラリフレームワークもなさそうだし。

なので、同じ理由PythonRubyダメだろう。

そうなると、メジャーどころの言語は軒並み使えないじゃん。

或いは回線スイッチを高性能にして、サーバリソースも上げられるだけ上げるというように、インフラ側の強化で解決しちゃうとか?

それとも、そもそもそんな仕事がもはや存在しないってこと?

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で飯食ってる仕事人として、何か準備しておきたいと思っているのだが、できればもう少し楽になる技術フレームワークが生み出されていると嬉しいんだけどなーという感じ。

2013-02-06

もしプログラミング初心者新人に基礎教育を施すなら

オープン系のデスクトップアプリ開発、Webプログラミングシステムプログラミングを仕事にする人向けとして考えてみた。

学習環境Ubuntu Linuxで、デスクトップ上のターミナルか、WindowsからTeraTermsshログインして行うことを想定。

なので前提知識としてLinuxabcくらいは教えておくとして、もし来年度やるならこんなもんかな。

結構分量多めだけど、これでも基礎の基礎に絞った感じ。


  1. Pythonで学ぶ手続き型プログラミング
  2. Javaで学ぶオブジェクト指向
  3. C言語で学ぶメモリの仕組み(主に配列ポインタ構造体関連)
  4. Perlで学ぶ文字列処理(正規表現ハッシュCGIを含む)

おまけ:Pythonで学ぶ関数型プログラミング


なお、上述のカリキュラムでやらない言語(VBjavascriptC++Objective-CC#PHPRubyなど)やWebフレームワーク(DjangoRuby on Railsなど)は、全てこれらの応用で覚えられると思うので、基礎教育終了後に各現場にてOJTで習得してもらう。

IDEも使わないけど、はじめの一歩で軽量エディタ+コマンドラインをやり込んでいれば正直どうにでもなるので省略。

あと最後がおまけ扱いな上にLISPで学ばないのは、要するに「リストすげー!超すげー!!」という感動を胸に今後も頑張ってもらうのが狙いなので(だって現状使う機会殆ど無いし)、最初にやって一番手に馴染んでいるツールで、理解のコアになる部分にサクッと触れて欲しいということ。


ちなみに来年度、自分教育係になる可能性は今のところ無い。

 
ログイン ユーザー登録
ようこそ ゲスト さん