はてなキーワード: システムプロとは
学歴がよくなくて、就職が困難だったので中小 SIer で働いていた。 (プライム案件を取ってこれる分マシらしい)
レキサルティ、レクサプロ、デパスのお世話になって続けてたけど、結局は薬でどうにかできず、辞めてしまった。
参考程度だけど、未経験の人が 300万 をもらうために、どのようなスキルが必要かを、まとめておく。
ちなみにどれくらいプログラムが書けなかったかというと、競技プログラミングで努力しても AtCoder の黄色になれず青色のままってくらい。
AtCoder でいう、初心者から抜け出せないという、要するにセンスがないということなのだけど、そういう人も居そうなので、参考までに。
未経験のプログラマに対して、これだけ要求されるのだから、未経験の人は覚悟するようにという指針を提供したいので書いた。
基本的に、損害を与えた場合には、それを作業者が補填するという誓約書を結ぶ。
要するに、捨て駒として扱って、失敗したら賠償しろ、という事になる。
このことを認識して、失敗しないように振舞ないと、連帯保証人含めて迷惑をかける事になる。
要するに、低賃金で未経験プログラマを案件にノーリスクで送りこんで、稼ぐための手段です。
基本的に PL (夢想家) → PM (御用聞き) → プログラマ という環境なので、プログラマが自分でディレクションして意思決定する必要がある。
例えば、下請けの場合は、PM の御用聞きの結果の WBS に合わせないと、顧客から DM で 瑕疵担保責任がどうとか言われる。
社内開発の場合は、PL の方から直接、長時間の叱責を受けなくてはならない。
そういう不幸を防ぐためにも、自分でディレクションして、PM の決めた実態を反映していない WBS に合わせて作業するスキルが要求される。
基本的に手戻りは個人の過失になってしまうため、手戻りしないように考え抜いて意思決定をする、というのが重要になる。
これこそ、ガクチカと呼ばれる、頑張れますというスキルなので、学生時代に頑張っておけばよかったなぁ。
こう見せたい、こう表現したい、という事を伝えるには、必然的にデザインの知識が必要になる。
創造的思考とデザインは切っても切り離せない概念で、デザインとは創造なのだから、当たり前である。
ソフトウェアアーキテクチャも、ソフトウェア設計も、コーディングもデザインと言えるかもしれない。
顧客と 1:1 で話す事が DM でもボイチャでも突発的に発生するので、いつ、いかなる時でも論理武装していなければならない。
まぁ、顧客であったり PL であったりはキレるのが仕事なので、それに対して理路整然と説明する必要がある。
なんとなく、では納得しないし、すぐ損害賠償請求とかそういう話にいくので、答えられないと持ち帰りますとお茶を濁して、エマージェンシーになる。
後述する設計能力においても、課題を把握するための言語技術(言語化能力)は重要なファクターだと思う。
C/C++ のシステムプログラムはフレームワークが基本的に無いので、自分で概念を整理して、どのような変更、拡張があるかを考えて設計する必要がある。
この能力が弱いと、手戻りが発生しやすくなり、瑕疵担保責任を問われることになる。
読んだ本の中だと、ボブおじさんの本が、やっぱりしっくりくるなという個人的な感想がある。
UDP で送ってくるデータを受けて 24/365 で停止しない WebAPI への繋ぎ込みという簡単な作業があって、振られた。
リークしてはいけないという事で malloc は禁止で、グローバル変数を利用するという変なルールがあった。
Rust で書けばいいんじゃないかなと思ったけど、Rust 書くのもシンドイし、C/C++ で、しんどくて読みづらいコードを書いた。
あとで保守する人が大変そうだけど、そういうルールを決めたのは PL だしね。
なんか、特殊な PCI Express のカードからベンダーが用意している SDK でデータ引っこ抜いて Web API へつなぎ込む部分をやった。
一応、SDK の使い方をパラ見して 1 日で作ったので、別に負担じゃなかったけど、素人にやらせるんなとは思った。
当たり前だが、DB 作って RestAPI を生やすのは現代のプログラマにとって自然にできなければならない。
なので、新規開発のサブモジュールのバックエンドを任せられた。
だが、ORM の癖を把握したり、発行されるクエリを確認したりするのは、疲れる。 SQL を直書きするのはシンドイ。
結局 SQL を直書きすることにしたけど、あまりいい決断ではなかったと思っている。
それ以外は フレームワーク に乗ってしまっていいので、書き捨てる分には楽だった。
最近だと、TypeScript で Prisma 使うのが、型安全でよさそうだなと思っている。
デプロイを EC2 直でやったり ECS にしたりとしていたので、ベアメタルの知識が必要になった。
要するに systemd のいじり方とか、死活監視の仕方とか。
個人的には、クラウド嫌いなので、ベアメタルの方が安心できる。
Bind で権威DNS を管理して、postfix で絶対止めてはいけないメールサーバを管理するとかもあったけど、出来て当然ではある事だし。
未経験プログラマでも、月単価 100 万以上で顧客に請求してるんだから、会社はそりゃ儲けるだろうと思った。
会社が一人前の経験N年のプログラマといったら、その通りに振舞う必要がある。顧客に責任はないのだから。
当たり前だが、Webディレクション、Webデザイン、Webプログラミング, Webマークアップ は、全て作業者であるプログラマの仕事になる。
個人的には、これが分かれている理由が良く分からないけど、分けたい人がいるんだろう。
デザインで、CSSフレームワークを使うと、その色が出るという事で、全部 CSS は手書きしていた。
tailwind が出た現在では使っていればよかったなと思う。
結局、全く分からない中、手探りでデザインし、コードを書いて、顧客に 1 日 5 ~ 10 回リリースするという行為をした。
顧客は大手企業だったので、自社のエンジニアならもっと出来る、と叱責されまくったけど、だったら自社でやればいいじゃんと思った。
一応、今でもサービスは生きていて、ユニークユーザ数は上がっているらしい。
そして、焼き付け刃だったので、 WAI-ARIA を知らず、アクセシビリティへの配慮が足りない事が問題になってしまった。
これはなんとか保守対応にねじ込めたのでトラブルにならなかったけど、瑕疵担保責任と綱渡りだなと思った。
当たり前だが、リリースサイクルを短くしないと顧客はキレてしまうので、CI/CD を整えないといけない。
今は Github Actions とかあるけど、昔は無くて Bitrise が高いからみたいな理由で Azure Pipelines で CI/CD フローを構築した。
もう Multi Stage Pipeline になってるだろうけど、Release Pipeline が GUI からしか設定できないのが辛みだった。
当然だが、デプロイするためには IaC を整える必要がある。
これを知らずに、コンソールでポチポチしていたので、 IaC 出来てない事がバレた時に色々怒られてしまった。
本来はテストも自動テストを整えて、質保証をしてバグを減らさなければならない。
だが、テストを書くという手間を払えなかったので、人力テストしかできなかった。
一応、リグレッションテストを人力でやりまくったので、バグ発見曲線が結合テストでの IF 不一致しかない、という結果にはなったけど
自動化できれば費用が必要じゃなかったから、怠慢だと、責められてしまった。
未経験でも誓約書を盾に、振られた事全部を出来なくてはならない慣習があるので、プログラマはそんなに良い職業じゃないよ。
甘い考えで、プログラマになろうと思っているのなら、考え直した方がいいです。
初心者はPythonから始めましょう。やりたいことはPythonでだいたいできます。世界で一番人気の言語で資産も豊富にあります。低学歴の素人がなんと言おうとPythonです。Pythonを覚えるのです。簡単なので1日あれば覚えられるでしょう。
次にSQLを勉強しましょう。SQLは3日くらいあれば中級者になれるでしょう。現代のデータベースはだいたいSQLかそれのパチモンが備わっています。SQLができると仕事の幅が広がるでしょう。
そしてJavaScriptは勉強しておきましょう。Webブラウザは全部JavaScriptが動きます。JavaScriptを勉強することでWebページで遊ぶことができるようになります。スクレイピングなどの理解も深まります。JavaScriptは便利です。
さて、ここまで来たら仕事に必要なプログラミングは身についているので次に進む必要は無いです。コンピュータの気持ちを理解するためにはC言語をかじってみるのもいいでしょう。大企業で働きたいならJavaは必須です。型に興味を持ったらOCamlやHaskellに手を出してみても良いでしょう。システムプログラミングをしたいならGoやRustも良いです。Goはバカみたいに簡単ですがRustは初心者向きではないです。
要約すると、37歳無能正社員の俺が、職業訓練校に通って未経験のIT系に転職できるか、という相談。
俺はクソ弊社の無賃残業にブチ切れてる無能・一応正社員のアラフォー男性・年収300万強
HTML・CSS・JavaScript・PHPの初歩をドットインストールで習い、自分のWordpressをイジった程度で、壁にぶち当たり中。
ならばと方針転換、転職活動中に危険物乙種4類(ガソリン等を扱う初歩的な資格)を取ったので、
シナジーありそうな電気工事士、ボイラー技士などの資格を取って活かせるビルメンテナンス方面での転職を考える。
求人情報で、職業訓練校の講座を受けることで実務経験に近い扱いを得られるケースを知り、職業訓練校の説明会に行く。
職業訓練校の説明を受けた際に、ITエンジニアを目指す講座の存在を知り、その内容に魅力を感じて再び方針転換。
訓練校の担当者さんいわく、講座を受けることは可能だが、技能習得後の年齢の壁は確かに存在すると忠告を受ける。
皆さんにお聞きしたい。
以下の内容を職業訓練校で習得することで、転職に繋がる技術は身につくだろうか。
カリキュラムは要約すると以下の通り
・Java
・リアルタイムOS(RTOS)を使用したマイコン制御システムの作成
・Linuxの基礎
以上の内容で、ソフトウェアとハードウェア両方の知識を身に着け、サーバサイドエンジニアやIoTエンジニアを目指すというもの。
また、JavaScriptは独学での学習を続け、趣味に関するサイトをWordpressで作成し充実させるという目標はそれとは別に進めていくつもり。
訓練校でプログラム言語を体系立てて学べれば、自己学習の進展にも繋がればと思っている。
睡眠障害持ちのため(夜勤の場合でも家で睡眠できれば問題はないが、ビルメンは基本的に職場に泊まるシフトがある場合が多い)
そこがネックになるのではという危惧はある。
ビルメン系の資格+クレーン車等の資格を合わせて、清掃工場などの管理系も考えてはいるのだが…
これ以上は本題がとっ散らかるのでこれくらいにさせていただく。
みずほ銀行は、3つの銀行が悪魔合体して生まれた銀行で、当初から「3つの銀行のシステムを温存したままやりましょう」ということになっていた。
で、なんでこの話になったのかと言うと、結局「どの銀行のアーキテクチャをベースに新アーキテクチャを構築するか」という話し合いが決着を見いだせなかったからだ。
大前健一はこのことを大批判していて「こんな事やってうまく行かないなていうことはシステム屋でなくてもわかる、いわんや大銀行の頭取をや」と結構激しい論調だった。
当然うまく行かなかったが、一度走り出したシステムは通常は直せない。特に今は銀行だけで判断することができず、金融庁に話を通さなくてはならないし、金融庁が一度Goを出した金港堂郷プロジェクトが間違ってましたとかは金融庁は絶対に同意も納得もしない。そんな顔に泥を塗られるようなことを許すわけがない。
なので、「システムの老朽化に伴い、新アーキテクチャでシステムを更改します」としか言いようがなかった。
だが、表面化はしないが今でもこの力学は働いたままだ。統合システムがどうにかできたようだが、人の気持ちは全く統合できていない。
この3つの銀行の怨霊のようなものは今も社風(行風?)にしっかりと溶け込んでいて、それぞれの銀行の縄張り争いは今も続いている。
例えば、こんなかんじだ。
旧第一勧業銀行系派閥「システムプロジェクトを始めるので、協力をお願いしたい」
旧富士銀行派閥と、旧日本銀行派閥「知りません、そっちでやってください」
旧第一勧業銀行系派閥「いやそちらのシステムにあるこの情報とあの情報が必要なんですが」
旧富士銀行派閥と、旧日本銀行派閥「そんなにどうしてもほしいなら上を通してもらえますか?」
部長級の話し合いでどのような内容の話をしているかなんか誰も知らないが、どの派閥も「どうせ無理だろうな・・・」と思いつつ部長に相談して「やっぱり派閥の壁には勝てなかったよ・・・」という茶番を誰も困らないように飾って終わる。
K部長「こういうのが下から上がってたんだけど、こういう議事録でいい?答えキマってるっしょ?」
F部長「あー、それ下から聞いてたわ。派閥の壁とか破ろうとするやつなんて評価下げとけばいいよ」
N部長「それな、とりま議事録できたら判子押すから持ってきて、答えなんか決まってんのにマジ茶番、受けるわー」
「Infra Study Meetup #4 "インフラの面白い技術とこれから"」というオンラインイベントで以下のような質問した者です。(以下のツイートは別の方が書いてくれたものです)
Q:これからますますクラウドが拡がっていく時代に、つよつよでないインフラエンジニアがどんな貢献ができると思いますでしょうか?
A:つよつよな人とそうでない人の壁を作らない方がいい。1つでいいので強みを身につければ壁がなくなるのでチャレンジするのが良い
まず、回答して頂いたのに失礼で申し訳ないのですが、今となっては、これをつよつよの人に質問してもしょうがない気もしてます。
ひとまずは、正直にオブラートに包まず「よわいやつに貢献できることなどないです。不要です。」と言われなくてよかったです。
では何故質問したのかと言うと、つよつよな人が登壇するイベントで、よわよわな人のクラウドに対する気持ちを質問として少し書いてみたかったのです。
なんというか、隣にイオンができた八百屋の気持ちを(実際の八百屋さんの気持ちは分からないけど)。
それはともかく、本題。ツイッター上で反応してくれた方々への回答(?)です。
そもそもつよつよという言い方が大嫌いだ。つよいとかよわいとかじゃないでしょう。なんで力自慢してるの?
力自慢というより、市場が力あるものしか必要としないんじゃないか、と感じてるんです。
これが仕事じゃなくて趣味なだけであれば、力自慢というか力比べというか、そういうのいらないんですけどね。
謙遜して、とかそんな感じじゃなく、メッシのプレーを見た後、みたいな感じなんです。
絶対に届かない、けど、食べるためにはサッカーを続けるしかない、他にできることが思いつかない、という後ろ向きな感じなんです。
「壁を作らない」 これ以上は自分が手を出してはいけない、とか勝手に壁を作らない、っていうのはいい話だな。 エンジニアである以上、教育されてないからわかりません、という人はいらないと思う。
「教育されてないからわかりません」とはちょっと違いますけど、全く勉強してないわけでもないんです。業務でクラウド使ってないのに AWS の資格取ったり。
ただ、プールを満たすくらいの水が必要なのに、コップで水汲みしてるような気分。
それやってどれほど意味があるの、という感じなんです。
正直上ばっか見てもキリがないし、なんでもできる人ってあんまりいないので、何か一つある程度の期間触ってみれば、少なくともその触ったものについては上の何割かに来るので、一つ一つそういうものを増やすかさらに掘り下げるかでは。インフラの人増えないから割とすぐですよw
「上の何割か」に行けるんですかね・・・。
そこそこレベルだと、クラウドのマネージドサービス使った方が良いでしょう、になってしまいそうで。
AI に仕事を奪われる、は実感湧かないですけど、クラウドには仕事奪われてる感じがしてます。
あと、最後の「インフラの人増えない」は、本当にありそうですよね。
高いレベルのインフラエンジニアしか要らない、となってしまったら、裾野が増えない気がします。
要は、つよつよじゃないって言葉は逃げにも使えちゃうと思うのです。この質問された方がそうだとは思わないですが(悩まれてる時点で頑張りたいって思われてると思いますし
「この質問された方がそうだとは思わないですが」って、注意書きを入れてくれているのが優しいなぁ、と思いました。
弱気な発言している人に対して「なに甘いこと言ってんの?」っていうのは簡単だと思うのです。
ただ、本当に弱っている人に更に攻撃加えてしまう可能性にまで頭が回る、心を配れるのは素晴らしいですね。見習いたいです。
あと、「つよつよエンジニアとは違うから」などと言って何もしない人もいるんでしょうね。
あるいは、多少は勉強しているんだろうけど、自分から見たら努力が足りない、そういう人が、つよつよエンジニアからは見えるんでしょうね。
もし自分がつよつよエンジニアだったとしたら、そういう人に強く当たらずにいられるのだろうか。
「つよつよな人との間に壁を作らない」というのは、言う側の動機はわかるんだけど、言われる側の「自分がよわよわだと思っている人」からは強者の理論にしか聞こえない気がしている。多分、求められてるのは修行メニューというか、もっと具体的な方法論なんじゃないかな。
この人は、いわゆる つよつよエンジニアという印象なんですけど、よわよわの人の気持ちを考えての発言ができるの、すごいですね。
ツイッター見てたら「私もよわよわなので気持ちわかります」という人より「甘ったれたこと言ってるな」的な発言する人ばかりだったので、気持ちが救われました。
(今回の質問に同意(?)した人が20人近くいたので、そういう人たちを救うためにも、強い言葉でツイートしている人だけじゃないことを世間に伝えたかったのが、この記事を書いた動機です。届くかどうかわからないけど)
で、そうなんですよ、具体的な方法論が知りたいんです。欲を言えば、現実的に可能なやつで。
このツイートに連なって書かれている「システムプログラミング」は現実的には私にはちょっとハードル高過ぎそうですけど、まずは「Go ならわかるシステムプログラミング」を読んでみます。Go わからないですけど。
これ書いてて思ったのですが、この質問した人(つまり自分)が「新人レベルの若人」と思っている人がほとんどだったと思います。実際はアラフォーのおっさんです。
その情報があったら、また違ったツイートになってたのかもしれませんね。
あと、弱気な発言が多いですけど、実際には、感覚的には、まだまだ十分必要とされてそうなので、そこまで深刻な気持ちじゃないです。ただ、10年後とかは怖い。
挑戦を応援するなり、批判する代わりに良かった部分は褒めたりしましょうよ。山本五十六から何を学びましたか?
※追記
意見封じじゃなくて「まずは落ち着いて、あなたが出来る努力をしましょうよ」という意図です。口先だけの人間になりたくないでしょ?次の世代の子供たちにそんな背中見せたくないでしょ?仲良くしましょうよ。
本格的にプログラミングを始めとしてコンピュータ科学を学び始めたのは大学に入学してからです.
今では幸運なことにインターンで都内のベンチャー企業でgolangやpython, scalaを用いた大規模なシステム構築に携わっています.
お給料も日本の大学生にしては破格といえるのではないでしょうか. それも大学で真面目に勉強したお陰であると胸を張って言えます.
大学の方の卒業研究では組み込み系のセキュリティに関して研究しています. 正直テーマ選びに失敗したなと思っているので大学院にいったらシステムプログラミング系の方にシフトしようと思っています.
私が大学の授業で初めて習ったプログラミング言語はC言語でした. 理由を教授に聞くと, 並行して座学で教えるコンピュータ科学系の専門授業全般と結びつけやすいからだそうです.
最近のTwitterやQiita, StackOverflowなどでは「初学者が最初に学ぶべきプログラミング言語はなに?」という質問に対して, JavaScriptやPythonから入るのがベストだと言う人を沢山見かけます.
JavaScriptはブラウザというものが有る限り20年は消えなさそうですし, Pythonは機械学習を始め, Webシステムでも使え, 非常にクレバーな言語です.
javaもオススメだと思います. 30億?ものデバイスで動く言語ですしドキュメントも豊富です. 色々な分野にも応用が効くでしょう.
さて, そんな中でC言語という悪い評判しか聞かない, でもやたら色々なところで使われているらしい言語を最初に学ぶメリットとは一体なんなのでしょう.
一つ, 私が思いついたのはコンピュータと仲良くなれる.
というのもC言語はアセンブリや機械語に比べれば, 人間にわかりやすく, かつコンピュータ側にも近いという顔をもちます.
真面目にプログラミングしようとするとどうしてもそのコンピュータの仕組み(主にメモリ) について学ぶ必要が出てきます. これらの知識が現代の開発に置いて役立つ分野比較的限られると思います.
しかし, それらは思わぬバグの特定や意図していない動作の改善に役立つことがあるかもしれません(実際に私もいくつか出会いました)
二つ目は他の言語を学ぶ時のハードルが非常に低くなる. これはどの言語を学んでも同じだとは思います.
そして, 他の言語の高級な機能に思わず涙ぐみながら感謝すること間違いなしでしょう(javaのsplitとか他の言語にもあるHashとか)
ただ, 私はC言語の構造体やポインタのお陰でオブジェクト指向プログラム言語を低レイヤな実装的な面と概念的な面ですんなりと理解することができました.
そしてよく挫折ポイントとなるポインタ(ダジャレじゃないですよ?). これもメモリの住所だと考えればそれほど難しくはないのです.
メモリの管理を適切に設計した時あなたのプログラムはボルト並みに早く走ってくれるかもしれません.
他の言語では味わえないやりがいがあるのもこの言語の魅力でしょう.
書いているとこれぐらいしか思いつきませんでした.
それでもコンソールに初めて Hello World! が出力された時の感動はやはり忘れられません.
昨今, 高機能な言語が沢山ありますが, あなたのプログラミング生活にささやかなアクセントとしてC言語を学び直してみてはいかがでしょうか?
きっと今使っている言語に普段言わない感謝の言葉を述べること間違いなしです.
この会話ログはフィクションであり、実在の人物・地名・団体とは一切関係ありません。
坂木
わろた
坂木
自分が理解できないものを意味がないと思いこみたがるタイプの人だということがよく分かったので原文を読まずに済んだ。ありがたいまとめだ。
安原
NTPsec が,ownership を理解していない開発者たちの声が大きくなるようなコミュニティによって開発されているということが分かって大変有意義でした(こなみかん
宮森
今までCで開発してきたプロジェクトを移すなら極端な話ownershipを理解しなくても良いわけで、悪くないのではと思う。
宮森
……が、理解できないものに対して、理解を試みず~すべきだ~と設計しろ、っちゅう人が作るソフトとはちょっと関わりたくないと思う。
安原
いや,私は C で開発してきたプロジェクトであるならばなおさら ownership を理解していないといけないと思います. ownership に理解を示さないコミュニティが関わってきた一定規模以上の C によるプロジェクト……私の第一感は「こわ…近寄らんとこ…」です.
宮森
いや、Cで開発してきた人たちって、ownershipを自前でコントロールできると思っている(思い込んでいる)人たちですんで……こわちかは同意。
安原
いや,私は C で開発してきた人たちの多くは,そもそも ownership の概念を獲得していないのではないかと危惧しています.元々,私はもっと楽観的で,多くの C プログラマは ownership の概念を獲得していると思っていました.
宮森
安原
OpenSSL の騒動の時,関数の途中で return したことによるリソース漏れを揶揄したことがあります. OpenSSL のようなインターネットの基盤を支えるオープンソースプロジェクトにおいてさえ, ownership の概念を獲得していれば脊髄反射で気づくであろうバグが随所に見られたことには本当に絶望しました.
安原
藤堂
安原
むしろ C++ によって ownership という概念が明確になり,その重要性が認知されるようになったのではないでしょうか? これについては,私は歴史的なことが分からないので真偽のほどは何とも言えませんが.
宮森
シニアな開発者にしかC++/Rustが受けないと思うの、まさにその点だと思っていて、人類を信頼したがために足どころか頭を吹き飛ばす経験を積んでいないからだろうなー、とか。
宮森
OSとかシステム系のプログラマの人々、基本的にリソースは人間が適切に管理するし管理できると考えている人が多い印象([検閲削除]社時経験)。言語側で安全を確保したい、的な話をしても相容れなかった記憶が。
坂木
[検閲削除] のコードには、間違って自分の足どころか頭を撃ち抜いてしまった偉大な先人たちの知恵が詰まっていて、開発していてとても勉強になります。なお [検閲削除] は頭がなくなっていることに気づかずゾンビとして生きている模様。
今井
今井
リソースどうこう以前に、そもそもちゃんと構造化されてるコードが書けるかも怪しい(個人の感想です。見識にバイアスがかかっている可能性があります)
安原
うーん,数値計算系のチームやコミュニティも ownership の概念の獲得,重要性の理解,その管理を自動化することへの理解,これらを期待するのは難しいだろうなあ…….そもそも高度なリソース管理が必要になる場面少ないし…….
坂木
コードの品質が強く求められるプロジェクトとそうでもないプロジェクトがあるからなあ。クライアントサイドソフトウェアは割と品質が求められる気がする。
安原
OS 実装とかシステムプログラミングって,クライアントに直接接しないだけで,その上にクライアントサイドソフトウェアが載るわけで,コードの品質が強く求められると思うのですがそれは…….まあ, API とかで切り離されているので,そこだけしっかりしていれば,という話はあるか.
宮森
坂木
今井
あとは、デモが作れればいい、的なのも同じかなぁ。
宮森
宮森
安原
今井
まー、 offline で動くバッチ、的なのはそこまでメモリ管理とか / パフォーマンスとかにもシビアにならなくていいし(最悪オーダーがほどほどならよい、的な)、そいう文化にいると、雰囲気にのまれる人が多い、というのはまぁわかる。
坂木
今井
宮森
いろいろ言っていますがワタクシ、そういう管理が必要なプログラムは全く書けなくなりましたので今書くと死にます(プログラムと顧客の大事なデータが)
安原
しかし,システムプログラミング界隈に「人間はリソースを適切に管理できる」という悪しき信仰がはびこっているの,何か構造的な原因があったりするのかなあ?
宮森
システム系、基本的に生のハードウェアが透けて見える言語を使う必要があって、そのために選択肢がCしかなくて、手段が限られているからこそ信仰が発生した、という認識
宮森
宮森
坂木
Linux カーネル、一体どうやったらあの規模のコードをクオリティコントロール出来るのか本当に不思議
安原
坂木
Linux カーネル、属人性高そうではあるけどそれでも実際に十分スケールしているからなあ…… ヤバい系レビュアーがごろごろしているのかな
宮森
安原
私も [検閲削除] のコミュニティを見てましたから,各々必要なドメインにおける圧倒的なタレント性を持った人たちが1ヶ所に集結して奇跡のアンサンブルを奏でうる場合がありうるのは理解しているんですが,本当にただの奇跡でしかないと思っています.
宮森
つーても機械エンジニアリングで町工場の職人芸を必要であれば使うように、属人性を求めるのも一個の正しい戦略だと思うんですよね。
宮森
なおその対極がみずh(省略されました
安原
Linux カーネルにおけるスケール云々は, Linux カーネルのコミュニティ自体におけるスケーラビリティではなくて,(システム)プログラミングコミュニティ全体(他のプロジェクト)へスケールするかどうかを言ったつもりでした.
坂木
宮森
C系がシステム系で優先されるの、ツールを変えるとツール独特の罠があるので、罠が全て分かっているツールを使う、っつうのもあるな。
安原
> システム系、基本的に生のハードウェアが透けて見える言語を使う必要があって、そのために選択肢がCしかなくて、手段が限られているからこそ信仰が発生した、という認識
これが原因だとすると,やはり Rust だ……Rust しかない…….ツール周りとか,まだまだ未整備な部分たくさんあるけれど……そこをクリアすれば…….
坂木
坂木
イテレータっていうか Java でいう Scanner を作ろうとしたんだっけ。サードパーティライブラリも探してみたけどその頃は I/O 周りの API が unstable でビルドが軒並み壊れていたりしたな……
藤堂
1.0 以前のことは忘れましょう (本当に unstable)
安原
坂木
安原
「Rust 経験者」という条件でプログラマを募集して,それで入ってきた人材に C を書かせればよいのでは!(ピコーン!
藤堂
犯罪ですよそれは
安原
はい.
藤堂
安原
まさにそれをイメージしていました.
宮森
藤堂
うーん、それ以降の話は知らず
今井
Rust そして誰もいなくなった、にならないかが一番心配だったりする
安原
それな
宮森
もしかして、NTPsecの人がRustでミニサーバーを起こすのにすら苦労していたの、普段からバグありのコードを生産しているからなのでは、という気がしてきた……。
(この辺で一同寝落ち)
原文:https://blogs.apache.org/foundation/entry/apache_commons_statement_to_widespread
原題:Apache Commons statement to widespread Java object de-serialisation vulnerability
翻訳日:2015年11月12日(午後にタイトルを日本語にしました)
----
Apache CommonsのJavaオブジェクトのデシリアライゼーション脆弱性に関するステートメント
著者: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) 氏はWebSphereやJBoss、Jenkins、WebLogic、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]
コメント:
実験結果を解析するプログラムをCで書き、解析結果をgnuplotでグラフ化し、グラフを貼り付けたレポートをTeXで作成するのを、全てemacsだけで行うという、今思うと労力だけは修行僧並みの苦行をこなしていた。
結局、このスタイルは修士論文を書き逃げするまで続くことになる(論文の図表は当然のごとくtgif)。
「役に立つけど、死ぬほど使いにくい」とはどういうことかを身を以て経験した感じである。
しかし、この修行もどきが原点になったおかげか、今流行のWeb系の諸々の技術は、さほど難しいと思わなかったり。
また、就職後に経験したオブジェクト指向もシステムプログラミングも難しいっちゃ難しかったが、なんとか投げ出さずに仕事をこなせたのは上述の経験が肥やしになったからかも。
一方で、同じ頃に知ったRDBの、その恐ろしく合理的で分かりやすい思想に感動したり、ここ数年コーディングで小技的に使うMapとReduceをコンピュータ科学の素晴らしい成果だと本気で思えたりしたのも、出発点のハードルがやたら高かった故な気がしている。
しかし、それを踏まえても、あいつらの使いにくさはどうにかならなかったのか。
「役に立つのがそれしかないから泣く泣く使う」なんて、経験しないで済むならそのほうがいいに決まっている。自分が怪我の功名的な肥やしにできたのも結果論でしかないし。
てか今時の学生は、こういう作業に何を使っているんだろう。
10年位前、上位のサイトから電文を受け取り下位のサイトに再配信するプログラムを、Linux上にC言語で実装する仕事を引き受け、死ぬ思いで片付けた。
その時にお世話になったのが「UNIXネットワークプログラミング」という本。
この本、POSIX準拠のOS(要するにLinuxなどのUNIX系OS)におけるシステムプログラミングのノウハウに関しては名著、いやバイブルと言っていい。
名著が絶版になる理由は色々あるだろうが、この本に限って言えばもはやそういう時代じゃない、そういう低レベルの実装はトレンドじゃないということなのだろう。
でも、そしたら「決して遅延が許されない再配信プログラム」は、一体何をどう使って作るんだ?
プロセス間通信やスレッド制御、更にはシグナルも使い、それらが高速で動作しないといけない(いやスレッドは難しすぎて結局使わなかったけど)システムで、そんなオーバーヘッドが高い言語は使えないと思うのだが。
それらを解決できる気の利いたライブラリやフレームワークもなさそうだし。
或いは回線とスイッチを高性能にして、サーバリソースも上げられるだけ上げるというように、インフラ側の強化で解決しちゃうとか?
今やプログラミングといえば、Webなどで使われるような高水準スクリプト系言語中心のアプリケーションプログラミングが主流だ。
そんなこともあり、もはや以前の低レベル言語によるシステムプログラミングの苦労など、タダの昔話である。
そこに来て、実際は齧った程度の分際で、性懲りもなくそんな昔話を書いてみる。
少なくとも10年位前に自分が手がけた(押し付けられた)仕事はそうだった。
大学で初めて触ったC言語しかもポインタ分からないで止まっているような奴に、電文の再配信プログラムを任せたのだから。
客は「遅延が絶対許されないシステムなのでJavaとかPerlとかはやめてねー」とにこやかな笑顔かつ笑ってない目で注文してきた。
このうちC++は、Java経験がある自分からしても仕様が膨大かつ複雑すぎて、とても手に負えないと感じ、必然的にCで書くことに。
勿論Cの言語仕様がKR本一冊で収まるほどコンパクトであっても、それが簡単であることを全く意味していないというのを開発早々に思い知らされたのだが。
あ、Cと言えば電文提供側の機関が受信用のスケルトンプログラムを一応は用意してくれていたが、どう見ても電文受信中に接続が切れた時のことを考慮していない内容で、全く参考にならなかった。
コード書きにおいては、例え一人屋台の俺ルールであろうが、コーディング規約のようなものは絶対に必要である。
その時のルールは「gccのオプションに"-Wall"を入れた状態で、Warningゼロになること」にしてみたが、その途端、日付変更線をまたがない限り退社できない生活が始まった。
というかオブジェクトを使えないだけでも地味に辛いのに、更にCの言語仕様はコンパクトである以上に原始的と言っていい代物で(だからWarningは基本無視できないのだ)、しかも言語仕様以外の環境依存要素が山積していると来たもんだ。
そんな言語でシステムコールだらけのコードかつ複数のファイルディスクリプタの同時監視(即ち非同期でノンブロッキング)しかもマルチプロセスでシグナルもあるよ!とか、お客さんは俺を殺す気か、そもそも完成させる気無いだろとか、今だったら思う(当時はそう思う余裕もなかった)。
仕方なく最初のKRに加えて「UNIXネットワークプログラミング」をわざわざ東京に出かけてまで買って読み漁った。
後にも先にも、古今東西の名著と呼ばれるような本を、泣きながら読んだのはこの時だけだったりする。
そこまで凄い良書なのになんで絶版になったんだか。
いかし、それでも「子供を殺しても死なない」、かなり前の処理での領域破壊のせいで突然プログラムが止まっちゃうなどなど、やればやるほど問題が出る。
シグナルを受信し、仕様のとおりに処理するのがこんなに難しいのか!と途方に暮れたこともあった。
そして途方に暮れても解決の手段になるような便利なツールもなければライブラリもない。
結局、「ある程度正しく動いたら、あとは出来た所まで」で勘弁してもらってようやく開放されたが、今でも当時の自分の仕事ぶりには全く満足していない。
無駄に頑張ったというか、頑張っただけの仕事であり、折角低レベル実装というCの本領発揮分野の案件でありながら、スレッド、malloc()、可変長引数は遂に習得できなかった。
こういうプログラムって、どうやったら正しく動かせるんだろ。
このような経験を経て、後年、Cやシステムプログラミングを指してギークな人々が
Cはとても高効率ですし、マシンのリソースもドカ食いしません。残念ながら、Cがそれだけの効率性を実現するには、あなた自身が低レベルのリソース管理(たとえばメモリ管理)を手作業でやってあげなくてはならないのです。それだけ低レベルコードがあると、複雑でバグも起こりやすいし、デバッグですさまじい時間をとられることになります。今日のマシンはずいぶん強力になっているので、これは通常は悪いトレードオフです――マシンの時間を少し非効率に使っても、あなたの時間をずっと効率的に使う言語を使うほうが賢明でしょう。
本物のプログラマはアプリケーションプログラムなど書かず、まっさらな金属板にゼロから書き込んでいく。アプリケーションプログラミングなど、システムプログラミングのできない弱虫のすることだ。
あと、あれほど苦手だったポインタについても、「ポインタが理解できないと永久にC初心者」というのを嫌でも理解した。
あれはギターのFコードやSEALsのヘルウィークみたいなもので「習得できなかった者にとってはキャリアの終わりを意味するが、習得できた者にとっては始まりですらない」ものなのだ。
・・・で、これだけで終わってしまうと本当にタダの黒歴史だが、これには少しだけ嬉しい後日談がある。
それから数年後、やはり電文転送系のシステムで、かつて自分がCのソロプレイでこなしていた規模の数万倍はあると思しき超大型案件に助っ人の「兵卒」として参加したのだが、そこはインプラとアプリでチームが分かれており、アプリ側だった自分は
「配列とポインタと構造体しか使わないで済むなんて、なんて楽な仕事なんだ!」と左うちわでのんびり過ごし、しかも高評価をいただいて帰ってこれた。
サーバサイドの通信プログラムなど、OSのシステムコール使いまくり系の、所謂システムプログラミングのうち、電話の交換器とか緊急地震速報のように、処理速度と信頼性が求められる仕様のソフトウェアは、未だにUNIX系(というか実質Linux)にC/C++になってしまうのだろうか。
速さの問題でJavaやPerlがダメとなると、未だにシステムプログラミングはアプリケーションプログラミングよりも高難易度というイメージがある。
かくいう自分の場合、C言語は学生時代の授業でポインタに挫折して以来、仕事で画像処理のプログラム実装でちょっと使ったけど結局よく分からない状態で、急病でリタイヤした人の仕事(C言語で少しだけ作った通信プログラムの引き継ぎ・納品)をムチャ振りされ、泣く泣く取り組んだ経験が半ばトラウマ化している。
だってC言語やっててポインタが分からないとか本当にド素人レベルの初心者が、socket()のノンブロッキングにpipe()にsignal()にselect()無限ループで複数のファイル記述子の監視を非同期通信でfork()もあるよという世界に放り込まれたのだ(当時のLinuxカーネルはpselect()がシステムコール実装されてなかったというオマケ付き)。
K&Rと「UNIXネットワークプログラミング」片手に涙も枯れた状態で帯状疱疹作りながら挑み、最後はどうにかこうにか元請けが引き取ってくれたけど、共有メモリやマルチスレッドはハイレベル過ぎて手が出なかったのが悔やまれる。
これがC++(当時未経験)なら、Javaで体得したオブジェクト指向で複雑な仕様もかなり楽に出来るかと思ったけど、いざ始まってみたらC言語とLinuxのシステムコールを使いこなすだけで精一杯で、C++は今でも未経験と。
あとmalloc()やfree()とかも全く活用できなかった。懸案だったポインタと構造体は嫌でも覚えたけど。
というか休日遊んでいて、突然それまで分からなかった部分が理解できたのはいいが、次の瞬間「やべ!あのまま本番動かしたら洒落にならん!」という展開になり、休日こっそり会社に忍び込んで必死にソース直したこともあったっけ。
・・・という経験をしているので、いつかまたシステムプログラミングの仕事が振られた時のことを考えて、一応PGで飯食ってる仕事人として、何か準備しておきたいと思っているのだが、できればもう少し楽になる技術やフレームワークが生み出されていると嬉しいんだけどなーという感じ。
オープン系のデスクトップアプリ開発、Webプログラミング、システムプログラミングを仕事にする人向けとして考えてみた。
学習環境はUbuntu Linuxで、デスクトップ上のターミナルか、WindowsからTeraTermでsshログインして行うことを想定。
なので前提知識としてLinuxのabcくらいは教えておくとして、もし来年度やるならこんなもんかな。
結構分量多めだけど、これでも基礎の基礎に絞った感じ。
おまけ:Pythonで学ぶ関数型プログラミング
なお、上述のカリキュラムでやらない言語(VB、javascript、C++、Objective-C、C#、PHP、Rubyなど)やWebフレームワーク(Django、Ruby on Railsなど)は、全てこれらの応用で覚えられると思うので、基礎教育終了後に各現場にてOJTで習得してもらう。
IDEも使わないけど、はじめの一歩で軽量エディタ+コマンドラインをやり込んでいれば正直どうにでもなるので省略。
あと最後がおまけ扱いな上にLISPで学ばないのは、要するに「リストすげー!超すげー!!」という感動を胸に今後も頑張ってもらうのが狙いなので(だって現状使う機会殆ど無いし)、最初にやって一番手に馴染んでいるツールで、理解のコアになる部分にサクッと触れて欲しいということ。