「malloc」を含む日記 
はてなキーワード: mallocとは
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 を直書きすることにしたけど、あまりいい決断ではなかったと思っている。
それ以外は フレームワーク に乗ってしまっていいので、書き捨てる分には楽だった。
最近だと、TypeScript で Prisma 使うのが、型安全でよさそうだなと思っている。
Linux の操作 (EC2 とか)
デプロイを EC2 直でやったり ECS にしたりとしていたので、ベアメタルの知識が必要になった。
要するに systemd のいじり方とか、死活監視の仕方とか。
個人的には、クラウド嫌いなので、ベアメタルの方が安心できる。
Bind で権威DNS を管理して、postfix で絶対止めてはいけないメールサーバを管理するとかもあったけど、出来て当然ではある事だし。
Webフロントエンド (React/Vue)
未経験プログラマでも、月単価 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 出来てない事がバレた時に色々怒られてしまった。
自動テスト
本来はテストも自動テストを整えて、質保証をしてバグを減らさなければならない。
だが、テストを書くという手間を払えなかったので、人力テストしかできなかった。
一応、リグレッションテストを人力でやりまくったので、バグ発見曲線が結合テストでの IF 不一致しかない、という結果にはなったけど
自動化できれば費用が必要じゃなかったから、怠慢だと、責められてしまった。
同じような未経験の人へ
未経験でも誓約書を盾に、振られた事全部を出来なくてはならない慣習があるので、プログラマはそんなに良い職業じゃないよ。
甘い考えで、プログラマになろうと思っているのなら、考え直した方がいいです。
2021-02-11
■続々：４５歳多重派遣プログラマの退職エントリ
匿名で自分のログを世の中に浮遊させ、そして拾って頂けるのは楽しかったです。
長く続けるとバカなので何処かで絶対にボロが出る。なのに書きたくなってしまった。
再投稿です。きちんと上がらなかったように見えたので、消してしまって、もうええかと思ってしまったのだけど、
見たかったというコメントを見て、少し修正して上げることにしました。こんな駄文にありがとう。
https://anond.hatelabo.jp/20210130001953
https://anond.hatelabo.jp/20210131035752
これらの続きです。
====
前回のエントリでずっと4GBのメモリとともに作業していたと書いたが4GB以下が正しい。
最初の現場は128MBだった。あと、盾を鉾と書いていた。この誤字脱字と誤用の多さで私のプログラマとしての質の低さもなんとなく察して頂けるだろう。
◯結婚した話◯
何故か結婚の話が書かれていないという書き込みが幾つかあったので結婚の話から。
30歳を越えてから趣味が充実していた事もあって周囲には煩く言われるものの、結婚を考える事はあまりなかったし、結婚の分岐に入ることが必ずしも幸福につながる選択肢とは限らないと考えていた。
この考えは今も変わらないが私は運良く幸福につながるほうへ入ったようだ。すまんな。
何せ30歳を越えてからは同じ趣味のおっさんの友人たちと焼き鳥屋であーだこーだいいながら企画を練り、イベントを立てたりするのが楽しくて仕方がなかった。
20代があまりにも労働をしすぎた。22歳から28歳までの6年間、年俸制なので一円も残業代が出ないのに月300時間勤務を2年半はやったと思う。最初のうちはISDN接続のテレホタイムでのネトゲが自分のゴールデンタイムであり、息抜きの時間だった。
時代が今なら渋谷凛か風野灯織に貢いでいたことだろう。長い労働時間は人生の搾取だ。
嫁は異業種の人で、友人のボカロPのファンだった。彼のライブに通ううちに顔なじみになり、少しだけ会話をするようになった。
ある時行ったライブが月曜夜の開催ということもあって若い人が多く、ライブハウスの中でスーツを着た客が私と嫁しか居なかったので思い切って「今日はスーツ、我々だけですね」と話しかけ、そこから色々な話をしたのを覚えている。いやらしい。
ボカロPのライブでの出会い、つまり私が結婚出来たのは初音ミクさんのおかげだ。
30歳になったあたりからようやくIT業界に過残業を何とかしようという機運がやってきた事、そして定時で上がる精神的な胆力がついた事で音楽を作る時間的精神的な余裕が出来、人との交流が生まれ、ライブに行く機会が出来たから私のような人間でも結婚出来たのかもしれない。しらんけど。
国勢調査によると35歳を過ぎてから結婚した男性は約3%らしい。私は一生分の運をこれで使った。（正しくは6.8%だと何処かの教授が言っていたが）
自分が居た現場の雑感だと、同じシステム開発現場でも大手SI や 大手SI子会社のほうが結婚している人が多かったように思う。多重派遣はやはり収入面で結婚に対してネガティブな意見を聞くことも少なくは無かった。
若い頃は親にも親戚にも「そろそろ結婚も考えないといけないだろうから派遣社員辞めないとね」と言われたことを思い出した。SESの増田は一度は言われたことがあるだろう。
世間一般的には技術職というイメージよりも派遣社員というメージが強く、収入面も相まって世の中の反応厳しい。
普通の一般派遣と請負の派遣の人が混在している現場が多いと思うが、前者は1人でも派遣が出来、上位会社の現場のリーダーが直接指示をすることが出来るので最近はその方が多いように思う。
ところが、一般の派遣会社として登録するには資本金が多くないとダメで、派遣法が改正されたあたりで資本金が少ない会社は請負の道を選ぶしかない。
そうすると複数人で現場に行き、自社のリーダーに仕事の指示をされる形になる。ただ、コレは守られていない現場が多い。
さらに、大手や大手子会社と取引を直接行うのにも資本金の大きさ・設立してから何年等の条件があったりもする。
資本が少ない会社は資本金の多い「別な会社を迂回して」契約する。そこに多重派遣ができる仕組みの1つがある。上位請負の営業が◯◯社経由しろという場合、利権・癒着の場合もあるのだろう。
新人の時、パワハラの教育担当に私が毎日何度も怒鳴られているのが流石にプロジェクト内で目に余るようになったらしく、私はドキュメント整理という新たな仕事を貰う事になる。
炎上プロジェクトの為、全く作られて無かったクラス図をソース等からRational Roseで自動生成し、体裁を整えて他の設計書も含め印刷をした。同じものを2部作るのだが、何故か同一性保持という理由で一部はコピーで制作。分厚いバインダーに綴じた。
印刷とコピーで休憩もせず毎日終電の生活をしていた時、PMに「広島の二番バッターみたいだなおまえ」と言われたのを覚えている。コツコツやるけど面白みがない人間だと言われたのだ。
要領の悪い私に休憩のタイミングなんて解らなかった。ましてやパワハラマンに使えないと毎日散々どやされ続けた後なので尚更である。
その経験から私は同じプロジェクトに居る若手に「そろそろ1回休んだら？」「いつまで働いているの？増田がそろそろ帰れって言ったって言ってもいいよ」となるべく声をかけるようにしていた。モテそう（モテなかった）
この時、たまたま席が空いているという理由で隣に座っていた方が、のちに難易度が高い事で有名な銀行統合の現場の某SIのトップになっていた。プロジェクトの雰囲気は良くなかったが、いつもにこやかで私のような末端にも優しかったのを覚えている。出来る人は余裕がある。
印刷業務が終わった後、入社してからずっとテストだけをやらされていた1年上の先輩のアベさんと、とうとうプログラムの修行に出してもらえる事になった。
新規開発のプロジェクトである。プログラムも一杯書けてラッキーなのではと思っていたのだが、自社の人間はアベさんと私だけで、あとは上位会社のPMと、更なる下請けで構成されていた。
現場のリーダーも下請けの人で、この人が私とアベさんの教育係という事になった。
自社の営業が初日に来て「この子達よろしくね」とリーダーに伝えた所、「任せてください！」と良い返事をしていたが、自社営業が居なくなった翌日から面白いくらい態度が一変することになる。
何を聞いても露骨な悪態をつき教えてくれず、技術的な質問も一切受け付けない。
流石にアベさんと自社の営業に伝えたのだが、翌日朝私のところにやってきて「チクったな」「自社の人間でも無いお前らに教える余裕はない」と言われてしまうだけで特に事態の改善はされなかった。パワハラ上司の次はこれだ。駅のホームドアは大事なので全駅に付けて欲しい。
救われたのはインターネットが使える現場だった事だ。とはいえ、なんせソースレビューも私とアベさんで互に行うので、技術的な進歩がまるで無い。
ある時、私が書いたプログラムがメモリを使いすぎてフリーズするようになり、問題になってしまった。他にも技術的に問題のあるプログラムを書いてしまった事が続いたのと、リーダーに対してハッキリとモノを言うことも災いし、PMの判断で半年でプロジェクトを出ることになってしまった。
もっとうまく立ち回る事も出来たように思う。しかし、若造は人生の経験値が足りなかった。
多重派遣の大きな問題として、現場ガチャにより環境が大きく変わるというのがあるだろう。2~3年も我慢すれば大抵の場合次の現場に行けるのかもしれないが、短い人生の2～3年は少ない数字ではない。
請負ではなく一般派遣扱いで来る技術者の中には新人なのに１人で派遣されてくる人も多い。そんなのは新人教育とは言えないと思うのだが、どこの会社の募集要項にも新人教育はバッチリと書いてある。
その「新人教育」とやらの実態というのは大抵の場合、外部で行われる初心者研修と、自社の営業が「この子よろしくね」と現場に伝える程度の事でしかない。
社会人としての新生活での不安、技術的な不安、誰が教えてくれるのかも解らない不安、定時になっても誰も帰らない・帰って良いとも言われない、作ったものの品質の不安、数多くの不安を抱えて過ごさなければならない。ちゃんと相談出来る人も現場に居ないのである。
技術的な所は勿論、精神的なケアも必要な時期だと思うのだが、このような体験を20代前半でしないといけないのはどうも無駄な苦労をしているようにしか私には思えない。
ただ、新人が伸びる為に必要なのは「経験者によるソースレビューによる指摘」が必要不可欠だと私は思う。レビューを先輩・上司が行い、新人が書いたコードの信頼性の担保が出来ないと、余計なバグを生み、可読性・メンテナンス性も落ちるだろう。
なによりバグを出してリーダー・PM・顧客に「こいつ大丈夫か？」と思われるストレスの大きさと自信喪失感は長く忘れられない。
余談だが、最初の教育担当のパワハラ先輩とはその後別な現場で一緒になった。しかも彼は会社の倒産後、上位請の会社に転職していたので私に仕事を振る立場として現れたのだ。全く知らなかったので顔を見た時は「ヤバい現場に来た」と焦ったのだが、「あの時は俺の頭がどうかしていた。申し訳ない」とまず謝られてしまった。驚くほど柔和な性格になっていて棘が全て抜け落ちていた。その後一緒のプロジェクトの間はたまに昼飯を一緒に行くまでになった。
約1年一緒に働いたが一度もドヤられる事は無かった。許せるか許せないかは別として、パワハラをするほうにも何かしらの事情や背景があるのだなと一つ学んだ。
社会人1年目の忘年会はゲイのショーパブの観劇だった。そこでアベさんはダウンタウン浜田の高校（全寮制男子校）の同級生というママに唇を「むちゅーーー！！」と音が聞こえるような熱烈な口づけをされ、人生のファーストキスを奪われていた。私は隣でただ震えるしかなかった。
知人もなく上京してきた為、他の社員と交流する帰社日をそこそこ楽しみにしていた私は怒りのあまり社内報に若気の至りで”ボロクソ”に書いた所、社長の目にとまり、翌年から忘年会の幹事を任されることになってしまった。なにせショーパブの観劇は社長の要望だったのだ。
そして、普通の居酒屋で特に弾まない会話をして終了をする忘年会を2年繰り返した。
自社の忘年会を面倒に思うベテラン社員は多く、各現場に電話で来てくださいねと念を押して来て貰ったのに参加者が全然楽しそうではないのだ。
普段それぞれが別の現場に居る人なのでそれほど同僚感も無く、特に仲も良い訳でもないので会話が弾まないためだ。良かれと思って2時間半飲み放題にしたが、本当に盛り上がらない。
「なるほど、これで会話をしなくて良いイベント（且つ社長の趣味）がブッキングされたのか・・・」と理解した。
その経験があり、”自社”に缶ビール等の各種アルコール・ノンアルコール飲料とテイクアウトの料理を用意し、16時開始、17時から随時帰りたい人は帰る。という方式に変えた所、立食（椅子も勿論ある）で仲の良い人の所に居て彼らとだけ話すことも出来るし、色々な人と交流することも可能になった。時間が短いために会話のネタに困ら無い事も功を奏し、思った以上に盛り上がる事が出来た。
子供が出来た今ようやく思うに至ったが、子育て世代も延長保育やパートナーにお願いすることもなく早めに帰れて良かったはず。殆どは17時から続々と退社していたが、以前は無かった有志の二次会組もいくつかあったようだ。参加者にも総務部長にも「毎年これで良いね」と言われ、ほっとしたのを覚えている。
何が正解かは解らないが、業務時間内で終わる自社での短い時間の立ち飲み（椅子席あり）は好評だったので、幹事をやらされがちなSES増田は参考になれば良いなと思う。
基盤まわりの仕事をしていた時、あまりにもプロジェクトでメモリの初期化漏れが頻発して問題となり、プロジェクトのお偉いさんが捻り出したアイデアが「”物理”メモリ全部を定期的に端から終端まで0で埋める」というものだった。
そしてそれをどう実現するか？という会議に呼ばれたのだ。
指を使い「物理メモリを”端から””端まで”全部、プログラムが動かない時間に定期的に一回ゼロで埋めればいいじゃない？」との説明があった。
これは良いアイデアだとご満悦の上役と、違和感を覚えない他のベテランの参加者達。
「まず、仮にこれが実現出来たとして、サーバーが立ち上がった時点でOSやミドルがメモリを利用していますが、どうしますか？OSもミドルも当然落ちます。」
「メモリですが、皆さんが普段変数宣言やmallocで受け取っているメモリの番地ですが、全て仮想メモリのアドレスなのはご存知ですか？」
「我々のような庶民は直接物理メモリアドレスに仕組み上アクセス出来ません」
「物理メモリにアクセスするにはカーネルのプログラミングが必要になります」
「メモリにはユーザープログラミングで触れる事が出来る層と、カーネル層という仕切り、さらに仮想メモリ・物理メモリという仕切りがある為に、堅牢性を保持している云々」
ここまで伝えても皆ピンときていない。文章にすればまだ解るが所為オタクの早口の説明なので当然、私の話術にも大いに問題はある。
もしかして自分が間違っているのか？このままだと私がこの対応をやらされる羽目になる。
私は交渉事でうまく立ち回れる技を持っては居なかった。なので、最後の手段に出た。
「だからこんな方法は絶っっ対 実現できないんですよ！！！」と突然のブチギレ。いや、出来るのかもしれんけど。
一同ポカーン。突然のメガンテを使った私に皆パルプンテ状態になり、
「増田がココまで言うのなら出来ないんだろう」という事になった。
正直、高い技術も必要ない汎用的なシステムの開発現場のなんてこんなものだ。AWSもGitHubも触ったことのない私があえていおう。
最初のエントリーに業務時間内に勉強させろと書いたが、目的が無ければおそらく時間があっても、「私は完全に仕事をしています」という顔をしながらviで青空文庫やアマチュアの小説を読んでいた時間の方が長かったのではないかと思う。
2019-01-11
■[増田統計]2019年1月10日木曜日の増田
| 時間 | 記事数 | 文字数 | 文字数平均 | 文字数中央値 |
|---|---|---|---|---|
| 00 | 109 | 15759 | 144.6 | 58 |
| 01 | 107 | 13787 | 128.9 | 58 |
| 02 | 80 | 7245 | 90.6 | 52.5 |
| 03 | 20 | 2172 | 108.6 | 53.5 |
| 04 | 22 | 2822 | 128.3 | 66.5 |
| 05 | 14 | 2632 | 188.0 | 65 |
| 06 | 39 | 3429 | 87.9 | 57 |
| 07 | 46 | 2937 | 63.8 | 31 |
| 08 | 60 | 6654 | 110.9 | 53 |
| 09 | 101 | 5836 | 57.8 | 39 |
| 10 | 82 | 7224 | 88.1 | 49 |
| 11 | 158 | 12599 | 79.7 | 48 |
| 12 | 134 | 15668 | 116.9 | 37 |
| 13 | 167 | 27641 | 165.5 | 74 |
| 14 | 209 | 18384 | 88.0 | 50 |
| 15 | 195 | 15361 | 78.8 | 41 |
| 16 | 179 | 15653 | 87.4 | 44 |
| 17 | 224 | 16911 | 75.5 | 52.5 |
| 18 | 201 | 18314 | 91.1 | 53 |
| 19 | 152 | 12001 | 79.0 | 44 |
| 20 | 153 | 13851 | 90.5 | 40 |
| 21 | 120 | 11844 | 98.7 | 41 |
| 22 | 134 | 16047 | 119.8 | 59.5 |
| 23 | 206 | 28704 | 139.3 | 42.5 |
| 1日 | 2912 | 293475 | 100.8 | 48 |
頻出名詞 ()内の数字は単語が含まれる記事数
人(324), 自分(202), 女性(176), 女(166), 男(153), 差別(143), 話(136), 今(127), トランス(108), 増田(106), 問題(99), 人間(85), 意味(81), あと(79), 前(76), 普通(75), 日本(74), 男性(72), ロリコン(71), 必要(69), 理由(68), 感じ(67), 気(64), 好き(62), 弱者(62), KKO(61), 社会(61), 子供(59), ー(59), 世界(56), LGBT(55), 主張(54), 他人(51), 理解(51), 金(51), 気持ち(50), 言葉(50), 相手(50), 仕事(49), 権利(48), 湯(47), 存在(47), 結局(46), 他(45), 全部(44), 関係(44), 別(42), 支配(42), 自然(42), 無理(41), 最近(41), 人権(40), 体(40), じゃなくて(39), フェミ(39), 昔(39), 時代(38), 犯罪(37), しない(37), 頭(37), トイレ(36), しよう(35), 目(35), 場合(35), 日本人(34), 全て(34), 性(34), ワイ(34), 絶対(33), レベル(32), 元号(32), 手(32), ネット(32), 議論(32), 人生(32), 東京(31), 事実(31), 記事(31), 名前(31), 会社(31), 時間(31), 批判(30), 本人(30), 今日(30), 方法(30), おっさん(30), 性的(30), レイプ(30), 現実(30), 差別主義(30), 意見(29), 可能性(29), 逆(29), 当たり前(29), 排除(29), 男湯(29), セックス(29), 内容(28), 場所(28), 判断(28), 時点(28)
頻出固有名詞 ()内の数字は単語が含まれる記事数
増田(106), 日本(74), KKO(61), LGBT(55), じゃなくて(39), フェミ(39), ワイ(34), 東京(31), 差別主義(30), 男湯(29), 可能性(29), 被害者(24), 中国(24), 平成(23), トランスジェンダー(21), 犯罪者(21), キモ(19), 更衣室(19), 元増田(18), twitter(18), わからん(18), マジで(18), ツイッター(17), 論理的(15), 普通に(15), シス(15), 盗撮(15), マイノリティ(15), 韓国(15), w(15), アメリカ(15), いない(14), 新元号(14), なんだろう(14), MtF(14), 異性愛(14), Twitter(13), 社会的(13), ブコメ(13), 笑(13), リアル(12), OK(11), 自分たち(11), hatena(11), ポリコレ(11), ツイート(11), 何度(11), 知らんけど(10), ブログ(10), 表現の自由(10), ブクマ(10), キチガイ(10), 江戸時代(10), なのか(10), 迷惑行為(10), お気持ち(9), 何回(9), 北海道(9), フォロワー(9), 加害者(9), 10年(9), 性犯罪者(9), 女に(9), SNS(9), 前澤(9), A(9), ドラえもん(9), ちんこ(9), 基本的(9), 個人的(8), ZOZO(8), ヘイト(8), 精神的(8), ニート(8), 男性器(8), 女性専用車両(8), キモカネ(8), 女性差別(8), 1人(8), どんだけ(8), 障害者(8), なんの(8), ありません(8), アプリ(8), 分からん(8), レーダー照射(7), いいんじゃない(7), 100万円(7), 反差別(7), 性犯罪(7), 京都(7), Apple(7), 化学調味料(7), 最終的(7), はてブ(7), IT(7), クライアント(7), 小児性愛(7), malloc(7), 外国人(7), タトゥー(7), 肉体的(7), トラバ(7), ガチ(7), 人権侵害(7), イケメン(7), 一年(7), 価値観(7), ？？？(7), 男性差別(7), ネトウヨ(7), 恐怖感(7)
本日の注目単語 ()内の数字は単語が含まれる記事数
ぱもうめちゃくちゃ(6), malloc(7), 男湯(29), 春菊(5), NGT(6), 湯に(13), 内海(7), トランス(108), 結婚年齢(4), タイ米(4), MtF(24), 湯(47), トランスジェンダー(21), 元号(32), 根源(16), ロリコン(71), 盗撮(15), 銭湯(15), 特権(15), 迷惑行為(10), 性交(13), 弱者(62), バーチャル(12), 支配(42), 同性愛(22), 差別主義(30), 児童(15), KKO(61), 恐怖(26), LGBT(55), レイプ(30), 自然(42), 施設(17)
頻出トラックバック先(簡易)
■トランス女性への根源的恐怖感はスルーされていいわけ？ /20190110110456(47), ■ガチで新元号を予想する /20190110134005(24), ■ツイッターのせいで高校からの友達が死んだ /20190109004202(20), ■数学で「公式を覚える」という言葉に抵抗がある /20190110142434(17), ■anond：20190107214043 /20190109211637(12), ■(追記有)某プラモデルメーカーの転職面接を受け /20190110003736(12), ■〇〇トースト /20190110093444(8), ■三大「社会に出る前に学校で教えてほしかったこと」 /20190110112133(7), ■anond：20190109004202 /20190109165130(7), ■艦これのアニメ2期やるっていうけど /20190109002808(6), ■極端な話、プログラムってifとloopだけだよな /20190110163744(6), ■デザイナーの尊厳を傷つけず「クソUIですよ」って伝えるのにはどうすればいいの？ /20190110171053(6), ■anond：20190110003942 /20190110004038(6), ■最近ジェンダー系の話題をよく見るけど /20190110151449(6), (タイトル不明) /20190110000033(6), ■LGBT問題の根本は「性欲」 /20190110135642(6), ■セックスレスだから別居したいけどあなたとはセックスできないっておい /20190109162531(5), (タイトル不明) /20190110154853(5), ■人生を狂わせたいじめっ子が芸能人になってた /20190110083410(5), ■この２０５号室ってどっから入るの・・・？ /20190109081746(5), ■アラサーくらいの女の人と会話をすると消耗する /20190110231610(5), ■バーチャルさんはみている、つまりこれは /20190110012757(5), ■雨は止まないし、夜も明けない。 /20190110015151(5)
増田合計ブックマーク数 ()内の数字は1日の増減
5932940(2288)
2019-01-10
2018-10-17
2015-01-29
■初めてじゃなかったCの思い出
今やプログラミングといえば、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のソロプレイでこなしていた規模の数万倍はあると思しき超大型案件に助っ人の「兵卒」として参加したのだが、そこはインプラとアプリでチームが分かれており、アプリ側だった自分は
「配列とポインタと構造体しか使わないで済むなんて、なんて楽な仕事なんだ！」と左うちわでのんびり過ごし、しかも高評価をいただいて帰ってこれた。
2014-05-20
■malloc関数を覚えた
必然、manalloc関数を必要とする。引数にはアナル拡張する直径mmを指定する。戻り値はアナル拡張によって得られた快楽指数「ヘゲナ」を返す。「ヘゲナ」はfloatの拡張であり、doubleの性奴隷である。decimalとは竿兄弟である。reanalloc関数も必要であろう。というのも、アナル拡張は必ずしも1度ではない、否、むしろリピーターが多いのではないか？おれはそう思っていて、やはりreanallocは需要がある。引数は2つ必要だ。拡張対象のアナルへのポインタ（どちらも表記は*だし実にちょうど良いと考える。C言語の創始者もそれを想定していたのではないか・・・？と思うほど、実に調和の取れていて、不気味に符合するのだ。閑話休題。2つ目の引数は再拡張するためのサイズを示す。ここではsize_tが型になる。tとは勿論ちんぽのことで、直径cmを意味する。しかし考えてみると、各種アナルを開放するfree関数は実に意味深だ。何から開放するのだろうか？ちんぽだろう。おれは、そう考えている。C言語は楽しいぞ。
2014-03-18
■システムプログラミングは未だに難しいのだろうか
サーバサイドの通信プログラムなど、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で飯食ってる仕事人として、何か準備しておきたいと思っているのだが、できればもう少し楽になる技術やフレームワークが生み出されていると嬉しいんだけどなーという感じ。
2012-06-15
■http://anond.hatelabo.jp/20120614121920
ポインタ、参照（リファレンス）、束縛（バインディング）、それぞれ似てるけど同様に語ると混乱の元ではないかと。
ポインタはメモリアドレスに型情報をくっつけたもの。加減算できる点が特徴で、それはメモリアドレスの概念由来だろう。
変数というメモリ上の記憶域を指すフィジカルに近い概念で、配列の運用（*p++で回すとか）、引数の参照渡し（コピー抑止、複数戻り値の実現）、メモリそのものの管理（malloc）あたりで、基本手作業による最適化のための仕組みという側面が近いと思う。
perlだと、変数はやっぱり記憶域ではあるけれど概念として一段抽象化されていて、メモリという連続した領域じゃなく独立した領域の集合となっているから、リファレンスの加減算はなし。
また、配列も単なるメモリの並びからより抽象化してリストもできたから、配列運用や複数戻り値もリストがあるのでリファレンスに頼ることはなくなる。
ただ、オブジェクトの概念があって、オブジェクトをオブジェクトとして入れる変数は用意せずリファレンスとすることで、文法上の変数の型を増やさない、コピー時のコンストラクタの問題を回避するなどのほか、オブジェクトの概念を援用して無名関数や無名変数、ファイルハンドルなども変数＝引数として扱えるようにした。
で、pythonはもう一段推し進めて、今までの数値や文字、配列もオブジェクトとみなし、変数はすべてオブジェクトを指し示すもので、記憶域は変数としてあるのではなくオブジェクトとしてあり、変数にリファレンスという特別なものがあるのではなくなり、変数は記憶域をもっていて値が代入されるものではなく、既にあるオブジェクトに変数名という名前（ラベル）を付けて束縛する行為とされる。
見方を変えると変数はすべてにおいてリファレンスで、代入とは値そのものの代入でなく値へのリファレンスの代入で、引数も参照渡しであるが、引数に代入したところでリファレンスが変わるだけで元の値が変わるわけではなく、しかし他の演算などでは自動的にデリファレンスされており、単純な数値や文字列など、自身を変更する機構を持たない（できない）ものにとっては実質的に今までとの違いはないに等しい。隠ぺいといえば隠ぺいか。
java, javascript, rubyもおおむねこの考え方でよかったと思う。
ただ、phpは若干両者が混じったところがあって微妙なところがある。
参考
2011-11-07
■
2010/05/16 23:40
こんにちは。昨日会った者です（これで特定するには情報不足だけど、まあわかるよね）。
で「幅優先探索でやる」という方針自体はいいと思うし、データ構造の作り方も基本は押さえていると思います（斜め読みしかしてませんが）。
ただ、コーディングの発想が「C で作る」という大方針から見て、少しちぐはぐな印象も受けます。データ構造の設計や操作の部分、汎用のライブラリを作ろうというのならあれでもいいと思うのですが、わざわざ汎用のライブラリを使わずに自分で専用の道具を一から作ろうというのなら、問題の性質を考慮して能率良くやることが大事です。
ところが、ここに載っているコードを見ると、見かけが C らしくなく、C++ や Java の劣化版のような印象を受けます。記法（マクロを大文字化しない、ルーチン名を大文字で始めるなど）だけの問題ではなく、データ構造の設計思想が「C で書く」という方針と矛盾しているように見えます。
もう少し具体的に言うと、そもそも C というのは現在 Web 系の世界などで流行のスクリプト言語類とは逆で、汎用言語でありながら低レベル（ハードウェアに近い）処理が簡単にできることに特色があります。つまり、組み込みを想定してプラットフォーム非依存のコードを書いたり、ハードウェアの特性を考慮して低レベルな最適化をやりたいというときに適しています。
そこでこの問題ですが、これを C でやるということは、処理速度や使用メモリ量の最適化が要求される状況、つまり迷路の大きさが途方もなく大きいような状況を想定すべきです。もっと言ってしまえばこの問題、たとえば画像処理などで似たような発想が要求されることがあります。このため、どうすれば時間のかかる処理を切りつめることができるかを考えてやらねばなりません。
このプログラムの場合、時間のかかる処理の代表格である malloc() が大量に使われています。これはいかにもまずいです。このような大量データを処理する場合の定石は、あらかじめ必要なだけメモリを確保しておいて、自分で割り当てることです。具体的には、必要と想定される量だけメモリを配列の形でどかっと確保しておいて、配列のインデックスをポインタ代わりに使います。そして、足りなくなったら倍々のような感じでメモリを realloc() してやればよいのです。
なお、そのような観点で言って、木の各節点の子の数は高々 4 （スタート地点が内点でないとすれば 3）であることを使っていることはよいと思います。ここで「子のリスト」とかを作ってしまっていたらこれはもうアホもいいところですから（容量の節約にすらなりません）。
そんな感じでしょうか。
とにかく、この手の問題は、アルゴリズムさえわかっていれば可読性もヘッタクレもないので、「短く書く」というような表層的なことよりも、何が求められているのかをよく考えて、柔軟に設計思想を考えることが大事だと思います。
2010/05/17 13:54
Oさんですね。専門的なコメントありがとうございます！cで書くと言いつつObjective-Cっぽい発想で書いていました。マクロの命名もその影響で、関数はImage Magickなどに似た命名規則になっている気がします。mallocを使いすぎると時間がかかるということは全然意識していませんでした。今度作るときはメモリ管理を自前で用意する発想を取り入れてみたいです。参考になるコメントありがとうございました！