  |
はてなキーワード: ソースコードとは
マージソートで書いておいたら
ここはヒープソートの方が高速でした！
って書き換えられて
いや、マージソート別なところで使うから試験目的もあって先行的に書いてあるんだけど
などなど
ソースコードは複雑だから関数単位なら中身かえていいという事もない場合もある。
それは会社ごとに違う、すこしづつすこしづつ新人をチームにならしていく
これをリードイン
小から中規模だと1年ぐらいは見る。
だめではないんだけど、やりかたが会社ごとに違う。
○ご飯
朝食：豆乳、昼食：ポークイチャップ定食、夕食：焼きそば（玉ねぎ）、お好み焼き（こっちは買ってきた）、ビール
○調子
お仕事は引き続き新人さんにソースコードの書き方を教える仕事。
有給だけど、出張の準備に使う予定なので、あまり遊びはできないかも。
ちょっと怖くて泣きそうになってる、なんでこんな辛い思いしなきゃいけないんだろ。
○ポケマス
ラジオ聴きながら周回。大修練をようやくクリアできるようになったので、ジムリーダーのメモ目当てに頑張ってた。
ししょうこうりんのデイリー分を消化。
たまにいるけど、あっ、こいつ頭悪いな。と思う
彼らはプログラミング言語を書くほどスキルがアップすると信じており、
こういうタイプはある程度いったところで成長が止まる
仕事でプログラミングをする上では、アクロバティックなプログラミングテクニックなどほぼ不要であり、
大抵は平々凡々、素直に考えれば誰でもこう作るというロジックの構築能力が求められる
人と差が付くのは、プログラミング能力とは、他人が読んでもわかりやすい可読性である
コメントや資料を残さないエンジニアは、先天的に可読性に関する感受性が欠落しており、
向いてない仕事を続けられるとお互い不幸であるからさっさと転職するべきだと思う
しかもこの手のタイプは手だけはやたらと動くので、ゴミコードを量産してプロジェクト全体を汚染する可能性が非常に高い
もはや悪性のガンと言っても過言ではあるまい
一刻も早く切除しなければ宿主を死に至らしめることだろう
○ご飯
朝食：豆乳、昼食：すけそう鱈と野菜の黒酢あん定食、夕食：納豆汁（納豆、小松菜、玉ねぎ）
○調子
明日もなのでがんばろ。
勝ち上がり乱闘を、ファルコ、マルス、ルキナ、子供リンク、ガノンドロフをクリア。
○ポケマス
ラジオ聴きながら周回してた。大修練を周回するのがいいんだろうけど、まだちょっと難しいな。電気タイプの子が欲しいけど、ちょうどメインクエストの次のキャラがハウなので、アローラライチュウをもらって育てるか。
ししょうこうりんをプレイ。
ワンパンで攻略できるわりに、デイリー要素だけでも30分以上かかるな……
この人、コラボとかでも外に出る主人公的なポジションなわりに、デッキの特性が玄人っぽくて難しいな。
フェアリーという1マナ1/1のクリーチャーを手札に増やす特性なんだけど、このフェアリーを増やすカードと、増えたフェアリーを使うカードのバランスをどう組めばいいのか難しい。
今日Container Runtime Meetupという勉強会に参加させていただいたのだが、KubernetesにContainerに詳しい第一人者による神々の集いに目がくらみそうになった。
ここにいる人たちを除いたら、日本でどなたがContainerに詳しいといえるのかわからない感じの人たちが一堂に揃っている。技術書典で池袋ジュンク堂でGitHubのissueで名前を見たことがある人たちがいる。
Organizerにいらしゃったので来るかもしれないと期待していたgVisorの中の人たちがいないのが寂しいくらい。
そんな人たちによる登壇者の話がrunc runのから始まったのはまだいい。予告があったり、自分は途中でinit処理にわけわからなくなった下地があったので。少なくともその後について腑に落ちたのだ。
だが、そこからいきなりnsexec.cに行ったのは突き放された感じがしてひたすらうなづくしかなかった。
Kushwahaさん。goのimportで定義されることにより本文が呼ばれる前にプリ実行されるCライブラリで名前空間を作成している、そのライブラリの処理の解説が行われた。
https://github.com/opencontainers/runc/blob/master/libcontainer/nsenter/nsexec.c
もうここで、unshare?unshare what?という気持ちになって、あー空のnamespaceを作成できるコマンドかと腑に落ちる暇もなくSudaさん。
ライブラリの実装と呼び出し方法について実際に処理を書いた人が、直直にケースごとのnamespace()の使い方の解説をするのだ。
こんなの後にも先にも一生聞けないだろう。聞き逃すまいと望んだが、MountNSの話は正直セキュリティ懸念があるのね、だから実装=サポートも積極的にされてないということしかわからなかった。
ファイル、ディレクトリ一つ一つのアクセス権限の付与をプロセスIDごと振り返る必要があって、それを高速にできるfsがsysfsという認識であってるのだろうか...自分でも何を言っているのかメモを見返しても呪文にしか読めない。
その後もsd_notifyをruncから呼んでいることに端を発したコンテナ起動待ち処理をどう実装するかという議論やら、某ベンダーさんによるruncをガチ運用している環境下でftraceを使ったデバッグの実演やらもうこの夜ここでしか聞けないような話ばかりで。
祭りが終わった後、ほとんどの人が帰らずに、会場となった台所みたいな食卓を囲んでフリートークを交わしていた。
Cloud Controller Managerを自社内向けに実装する話の相談をしていたり、先ほどの登壇者が同じPCの画面を前に肩を並べてruncのソースコードリーディングを始めたり好き勝手にしてる。
それは正直自分みたいに浅い知識を持った人には、RHTechExchangeで聞いた英語の雑談よりも遥かに遠い世界だった。
勤めている会社の組込みソフトウェア開発で、matlab simulinkを使ってモデルベース開発をしているメンバがいる。
simulinkでは、scratchやレゴのmindstormのようにブロック図を書くと、ソースコードが自動生成される。
それを聞いたとき、直接ソースコードいじれないなら細かい調整が利かなさそうという印象と、プログラミングしないエンジニアってろくなもんじゃなさそうという印象を持った。
そこから気になってモデルベース開発を調べてみると、ブロック図でシステムを作り込むので設計者の意図が他メンバに共有されるハードルが低かったり、システムに問題が発生したらブロック図つまり上流工程で修正させるので場当たり的なコード修正による時限爆弾のようなバグが増えにくかったり、確かに感心するようなメリットがあることもわかった。
場当たり的なコード修正が後々の大きな問題となってプロジェクトの工数を食いつぶす経験がある諸兄は多いと思う。
モデルベース開発みたいな、設計成果物を与えればあとはAIがプログラミングしてくれる未来はすぐそこまで来てるのかもしれない。
それはそれで面白そうだと思う反面、いままで培ったプログラミングスキルが不要になるのは寂しいなと老害のような気持ちも湧いてくる。
ディレクターサイドが大きいタスクを嫌がる工数が足りないと騒ぐ
リファクタしようにも軽微な改善を積まれまくって開発ができない
イベントを行うもイベントが終わるたびに燃え尽き症候群でエンジニアがやめていく
開発の経営陣は古いシステムをどうしようという話に一切口を出さず新しいシステム・機械学習に夢中
クローズするサービスを残し続ける、保守しなければ無料じゃねーんだよ
DBパンパン、使われていないテーブル多数あるけど怖いので消せない
CTO直下のチームは飽き性で色々なフレームワークを開発し運用チームに渡しまくるせいでもうぐっちゃぐちゃ
マイクロサービスを無理やりしたせいでバージョン違い、ミドルウェアの違いなどで更にカオス
DDDとか会社で誰も回せないし正常に導入できていないのに、推し続ける謎行為（俺たちは勘でDDDをやっている）
主要なサービスと新規事業サービスを乱立するのは良いが、損益点をはっきりさせて撤退する勇気を持つ
オンプレはもう限界だよ、オンプレでもいいけどサーバー構築を1h以内にやってくれ頼む
大規模なリファクタリングを行うために経営陣は今の現場の限界に気づいてくれ、株価見ろよ利益率悪いのが丸わかりだろ・・・
自分たちは弱いことを認めて改善をしていけばいい、全員やめろとは言わないけどもっと運用チームの一番下と経営陣がしゃべる時間を作って生の声を聞いてくれ
エンジニアをイベントごとに巻き込むな、全部任意イベントにしてくれ
エンジニアと営業を同じ制度・ワークフローで処理するのは限界ってことに気づいて
会社のお金の使い方見直しません？その社内イベント本当に必要ですか？
重複したソースコードをまとめてしまえば管理が楽と言うのが一番の目的ですよ。
ざっくり言うと、
（シミュレーションゲームだと思ってもらってもいい）
凝って作ったので１時間かかりました。
次に、それ以外の学年を作ります。
同じクオリティで作りたいので、あなたは残りの学年分の５時間かけてまた作らなければいけません。
しかも、成長が早いので、６年生の机は１年生の机の２倍はないといけません。
同じ「教室」なのにめんどくさいですよね？
それなら、１年生の教室の設計書を元にして（クラスにして）を使って、
学年ごとに教室の設計書をコピーした（インスタンスを作った）方が早いですよね？
そして、６年生の教室の設計書（インスタンス）だけ、机のサイズを大きくしたりした方が効率的ですよね？
教室を作った後に、教室にクーラーを設置してほしいと言われました。
一個一個それぞれ設計書を作っていたら、それぞれ直さないといけませんよね？
学年毎の設計書（インスタンス）も連動するので、クーラーが勝手に設置されます。
ものすごい楽ですよね？
っていうのを、プログラムに起こす事で我々はお金を得ているので、
そこは先生に書いてもらってみてください。
昨今流行りのNTTの退職エントリの大半において、NTTの評価は
・福利厚生は良い
・人も良い
・待遇も悪くはない
・的外れなセキュリティ対策にガチガチに縛られていて作業効率最悪
という感じなのだが、まさにその通りなので、退職する気はないが、現役社員として実例を示しておく。
私が所属する組織では、ここ数年で情報セキュリティインシデントが多発している。
具体的には、取引先のベンダーA社の情報が、B社に開示されてしまうという情報漏洩だ。
その大半が、弊社の独自システム（以降「システムX」と呼ぶ）上、あるいはその周辺で発生している。
システムXは、弊社と多種多様なジャンルのベンダーが仕様書やソースコード、バグ票やQAコメントのやりとりなどを行うためのプラットフォームなのだが、その歴史は古く、運用開始は2000年代前半。
運用当初から現在に至るまで無秩序な機能の追加や他システムとの統合を繰り返した結果、その全貌を知るものは最早いないのではないかという複雑怪奇なシステムとなっている。
それゆえに情報管理・権限管理の仕組みは非常に難解で、「どうぞヒューマンエラーを引き起こしてください」と言わんばかりの罠が方々に散りばめられている。
「A社宛の起票のつもりだったが、なぜか権限設定に不備があり、B社も閲覧可能になっている」といった具合だ。
さらにシステムXへのユーザアカウント追加／削除や権限設定は、これまた極めて複雑かつ前時代的なエクセルフォーマットに記入してメールで申請しなければならず、この申請方法に起因したヒューマンエラーによる情報漏洩も後を絶たない。
日本語の読み書きとITパスポートレベルの知識があれば、わが組織で発生している情報セキュリティインシデントの癌はシステムXだということがわかるはずだ。
システムXの問題点を洗い出し、別のシステムでの代用を考えるのが筋道であろう。
現に、開発プロジェクト単位でシステムXを使わずにbacklogやJIRAといった権限の管理が容易かつ確実に行えるシステムへの移管が進んでいる。
問題。情報セキュリティインシデントの多発に伴い、社長や直属役員からお叱りを受けた組織長が取った対応策は何か。
もちろん本日記のタイトルからお察しの通り的外れなのだが、その度合いがヤバい。心して聞いてほしい。
・メールやシステム（システムX以外も含む）で社外に添付ファイルを送信する際は、課長職以上の管理職から送ることとする。
・具体的には、係長以下の社員が添付ファイルの所在および送信方法の下書き（メールやチケット）をメールで管理職に送り、管理職が先方に送信する。
・・・え？
システムXが糞過ぎてヒューマンエラー多発してるだけなのに、全てのファイル送信を管理職が送ることで何か解決するの？
というかメール／JIRA／backlog／Redmine etc・・・で日に何十も何百もファイル送信が行われるのに、全部管理職を経由させるの？
ログファイル1件、スクリーンショット1枚送るのに課長にメールで依頼して、対応を待たなきゃいけないの？
働き方改革だ、業務効率化だと言っていたのはどこの誰でしたっけ？
もうね、怒りを通り越して笑いがこみ上げてきたよ。
この対策（笑）が意味を成さないこと、むしろ無駄に人手をかければ更にヒューマンエラーが発生する確率が上がることくらい、ちょっと賢い小学生でも理解できる。
気づいてる管理職も大勢いるはずなのに、誰も異論を唱えず、淡々と部下に"ルール"として周知する。
多くの部下を抱え、毎日大量のファイル送信が必要な管理職は、ノートPCを持ち帰り、帰宅後だろうと年休中だろうと遠隔でファイル送信の対応に追われている。
わが組織に「ボトルネック生成によるヒューマンエラー促進法」が施行されて数日後、めでたく情報セキュリティインシデントが発生した。
具体的な内容と原因については知らされていないが、推して知るべしといったところ。
いっそのこと、ファイルは全部組織長が送信したらどうっすかね？むしろ、社長にしますか？いや、それでも危ないから、全部手渡しにしましょうか？（鼻ホジ）
