「オーバーヘッド」を含む日記 RSS

はてなキーワード: オーバーヘッドとは

2021-11-12

TypeScriptバリバリ使ってると説明されたので体験入社したけど

TypeScriptスペシャリストでない俺が見ても型定義は本当に局所的でAnyばっかりだわstrictFunctionTypesがfalseだわts-ignoreばっかだわでTypeScriptの型チェックをまともに使ってなかった。

言語仕様のうちメインの機能を使ってない時点でバリバリ使っているという印象ではなかったしただトランスパイルオーバーヘッド増やしてるだけのようにしか感じなかったのでとても不誠実だなって思った。

私たちTypeScriptを使って堅牢設計を構築してまーす」みたいな文言があったら警戒しておくに越したことはないなって感じ。

2021-10-27

アンドロイドJavaなのがね...

ここ10年でさらレガシーなっちゃった

まあ今ではKotlinフレームワーク使うから生でJava触ることはあんまないんだろうけど、

VMがある分のオーバーヘッド永遠にiPhoneに勝てないんだよね。

もともといろいろなハードウェアに載せたいという趣旨Java採用したんだろうけど、

実際はARM一強になっちゃったし、たまにx86アプリ動かそうとすると動かなかったりで、

結局アーキテクチャに合わせたチューニング必要という、中途半端な状況になってる。

まあ後知恵諸葛亮なんですけどね。

2021-09-25

オブジェクト指向はすでに粒度時代にあっていない」を読んで

記事

@kis (id:nowokay) さんの以下の記事についてです。

https://nowokay.hatenablog.com/entry/2021/09/25/042831

ブコメにもあるようにちょっと内容が雑というかわかりにくいせいで賛否両論になってしまっていて、もしかしたら近いうちにアンサー記事が出るかもしれませんが、自分自身理解を助けるためにも言わんとしていることを推測しつつ、自分認識もまとめておこうと思い書くことにしました。明らかに誤読してそうな箇所があれば、指摘してください。

前提

まずは前提を書いておかないと論点がぼやけると思うのでいちおう。

自分バックグラウンドは以下:

その他の前提:


本文およびブコメを読んで思ったこ

2000年代に入って関数型プログラミングが脚光を浴び始めたのは、コンピュータ資源が潤沢になりパフォーマンスをそれほど気にしなくってよくなったことが大きな理由ではないか、という認識があります

関数型プログラミング言語の内部実装を読んだことがないので推測ですが、データを不変にするということはその都度メモリ領域を新たに割り当てることになり、そのオーバーヘッドプログラムパフォーマンスに影響を与えるので、パフォーマンス要件がをシビア場合、どうしてもメモリ割り当てや計算効率を考えるとミュータブルにせざるをえないと思います。が、ウェブアプリケーションに限っていえば、データベースアクセスネットワークアクセスレイテンシが大きいので、そうした相対的に細かいオーバーヘッド無視しても(大抵の場合は)問題にならなくなった、というのが「時代」の流れなんだという認識です。

いっぽうで別の観点もあって、REST API や FaaS が一般化して、関数単位で処理を分割し、アプリケーション外部に配置することが当たり前になってきた現状があり、マイクロサービスのようにアプリケーション自体モジュールの一単位として考えると、アプリケーション内部のモジュール同士でも関数ベースでやりとりする形になっても不自然ではないと考えられます

記事にもありますが、RPC派生実装?)として生まれJava の CORBA や MicrosoftDCOM みたいな振る舞い付きのオブジェクトコンポーネント)を共有しようという世界観は廃れ、REST API のような単一の振る舞い(エンドポイント)とそれにひもづく JSON のようなデータ構造のみを受け渡すやり方が一般的になったアプリケーション通信の潮流と、計算資源が潤沢になって再度脚光を浴びた関数型プログラミングが、レイヤーの違いを飛び越えてひとつになろうとしているのではないか、と。

まり、元記事に書かれている「時代に合ってない」というのは、「データ構造と振る舞いが一体となったオブジェクト」のような「なにか」は、そうした背景があるために、どこにも存在する必要がなくなってきているのではないか、と解釈しました。

なので、以下のコメントちょっと論点がずれてると思いました。

はあ?「再利用する方法としてはWeb APIが主流」って、その中身をオブジェクト指向設計することは、全く矛盾しません。 部品化の単位は、慣習や柵などで大きく変わりますオブジェクト指向とはほぼ無関係です。

https://b.hatena.ne.jp/entry/4708813645995359202/comment/suikyojin

なんでサービスとして外とやり取りする話とサービスの内部設計の話をごっちゃにしてんだ。なんか理解度が怪しくない

https://b.hatena.ne.jp/entry/4708813645995359202/comment/ssssschang

しかに、アプリケーション単位アプリケーション内部のモジュール単位とでその表現形式を合わせる必要はないんですが、元記事の言わんとしていることはこの一文に端的に表れていると思います

ソフトウェア記述をまとめるという視点では主にステートレス関数を分類できれば充分で、データと振る舞いをまとめたオブジェクトというのは大きすぎる、システムを分割して管理やすくするという視点ではオブジェクトというのはライフサイクルリソース管理視点が足りず小さすぎる、ということで、オブジェクト指向粒度でのソフトウェア管理は出番がなくなっているのではないか、と思います

個人的にわからなかったのは以下の部分です。

オブジェクト指向でなぜつくるのか」という本がありますが、「え、いまどきオブジェクト指向でつくらなくない?」っていつも思います。内容的には、もうほとんどはオブジェクト指向関係ないソフトウェア工学の紹介になっていますね。

当該書籍は読んだので後半はまぁわかるんですが、前半は「え、いまでもオブジェクト指向でつくるのが主流じゃないの?」って思ってしまますオブジェクト指向定義が「データ構造と振る舞いが一体となったオブジェクトの集まりとしてソフトウェア組織化すること」なのであれば)。

おわりに

Joe Armstrong が "Why OO Sucks" を書いたのが2000年とのことなのですが、そろそろこうした議論収束に向かってほしいと個人的には思います(とっくに収束していると感じている方もいらっしゃるでしょうけど)。

https://gist.github.com/posaunehm/4087971

2021-08-16

【未経験から1ヶ月で】現役エンジニアが教える最良のプログラミング勉強法

プログラマーに憧れる皆さん!こんばんは。

自分文系から」「未経験から」と諦めていませんか?大丈夫です!プログラミングセンス不要です。正しい手順で学べば、文系や未経験でも、誰でも一流のプログラマとして活躍することができます

今日は、未経験から最短でWeb企業就職するための勉強法をご紹介します!

オススメ方法

もっとオススメ方法は、顕正会セミナーに参加することです。

顕正会は、日本で最大のエンジニアコミュニティであり、非常に良質なテキストを用いて、プログラミング初心者向けのセミナーをしていることで有名です。顕正会に入ることで、未経験からでも一流エンジニアノウハウを学ぶことができます

また、意外と知られていませんが、日本エンジニアの8割は顕正会出身です。実はあのひろゆきビル・ゲイツ顕正会出身です。ですので、顕正会ネットワークを介して就職先を斡旋してくれたりしますし、自分顕正会員だと、面接時にも非常に有利になります

顕正会セミナーは、インターネットからも応募することができますし、秋葉原などで声をかけられることもありますので、誰でも簡単に参加できます。会員もフレンドリーな方ばかりですので、是非、お気軽に応募してみて下さい!無料体験もできますよ。

準備

プログラミング勉強を始める前に、まず、必要ものを準備しましょう。必ず必要ものと、できればあると良いものは以下の通りです。

必ず必要もの

まず、プログラムを書いて実行するためにパソコン必須です。

可能な限りスペックの高いものを買いましょう。2021年現在であれば、CPUは18コア、36スレッドRAMは128GBくらいはあると良いでしょう。ストレージSSDであれば1TBもあれば十分です。

OSは、Windowsで開発するならWindowsが、Macで開発するならMac必要です。よく分からなければMacを買っておく方が良いでしょう。基本的MacにできてWindowsにできないことはありません。

インターネットは、この記事を見ている人は既に持っているでしょう。ただし、モバイル回線で見ている人は、自宅に有線のインターネット環境を用意した方が良いです。

顕正会に入会すれば、上記スペックPC無料で貸し出ししてくれます。また、法人向けの専用線無料で取付工事を行ってくれる上に、通信費を全て負担してくれます

できればあると良いもの

まず、他の会員と連絡を取るために、SNSアカウントを持っていると良いでしょう。

最近は完全にPC上での学習もできますが、やはり、勉強の基本は紙のノートに直接書くことです。医学的にも、手指の動きと脳の記憶回路が関連していることは証明されており、手を動かすことで効率的ものを覚えることができます

Kindleなどの電子書籍リーダーは持っておいた方が良いです。紙の本は時代遅れです。いやしくもITプロを目指そうという人間が、このような最先端デバイスを使っていないのは恥だと思うべきです。紙の本を買わないことは、環境を守ることにも繋がります現金も持つのはやめましょう。

自宅での学習

せっかくセミナーに参加しても、受身聴くだけでは、プログラミング習得することは難しいです。ここでは、自宅でどのような勉強をすればよいのか、ご紹介します。

教科書写経する

まずは、教科書参考書写経することから始めましょう。教科書参考書の本文を一字一句正確に書き写すのです。

よく、「写経理屈を学べないからだめだ」と批判されますが、まずは正しい「型」を体に覚え込ませるのが先です。野球水泳などでも、細かい理屈よりも先にフォームを固めるのと同じです。書き写している内に理屈自然と身に付きます

また、写経メリットは「飛ばし読み」を防げるところです。一字一句正確に写経をすれば、細かい部分を「分かったつもり」になって飛ばししまうことを防げます。たとえば、比較演算子の等号は=ではなくて、==です。プログラミングはこういうところに注意して学ばなければいけません。

ソースコードフローチャートUML)に変換する

教科書サンプルコードノートに書き写したら、それを今度は自力フローチャートUML)に変換してみましょう。そうすることで、自分が本当にそのコード理解しているのか、確かめることができます

フローチャートUMLが素早く正確に描けることは、プログラマーとして働く上で非常に重要スキルです。それらはソフトウェア設計の基礎となりますし、ソースコードを読めない営業顧客にとっては貴重な資料となるからです。プロエンジニアは、COBOLソースコード10万行を1週間でフローチャートにして、Excel転載することができます

ここで一つ注意すべきことがありますフローチャートを描くときは、必ず専用の定規を用いて描いて下さい。フリーハンドで描いたもの業務ではフローチャートとは認められません。これはまともな企業就職すれば研修などで必ず習うことですから、今の内に覚えておきましょう。

Excel勉強する

エンジニアを目指すのであれば、プログラミングだけではなく、Excelの使い方も学びましょう。Excelエンジニアにとっての万能プラットフォームです。エンジニアはあらゆる作業Excelで行いますセル結合や罫線を用いて、見栄えの良い資料を作る技術は、エンジニアにとって必須です。

プログラミング学習中であれば、たとえば以下のような題材の資料を作ってみると良いでしょう。

尤も、以上の資料は、ツールを使うことで自動作成することもできます。たとえば、ソースコード更新履歴Gitなどのバージョン管理システムを使うことでも管理できますしかし、それらの資料としてのクオリティは非常に低いため、アマチュアしか使うことはありません。プロを目指す皆さんは、必ずExcelを使いこなせるようになりましょう!VBA習得必須です。

プログラミングのコツ

以上、プログラミング勉強法について解説しました。ここからは、実際にソースコードを書くときのコツを紹介していきます。他のプログラマと差をつけることができる技術ですので、意識するようにして下さい。

変数名は短く

プログラムで使う変数名は可能な限り短くしましょう。

理想は、aやxなどの一文字です。ただし、これだけだと26文字しか使えないので、a1, a2, ...のように連番でグルーピングすると良いです。

また、変数宣言使用箇所が離れた場合に、変数の型がすぐに分かるように、たとえばint型であればi1, i2, ...、string型であればs1, s2, ...のように命名すると、読む人に親切で自分ミスしにくくなります

変数名を長くするのは、以下のデメリットがあるため、絶対にやめましょう。


なるべく関数を作らない

多くのプログラミング言語には、クラス関数といった機能がありますが、これらは基本的ライブラリ提供者などが使う想定の機能であり、一般プログラマが使うのは好ましくありません。したがって、クラス関数はなるべく使わないようにして下さい。

関数を作ると、以下のデメリットがあります

不要関数を作らないためのテクニックには、以下のようなものがあります

まず、関数引数に「フラグ」を渡し、関数内部で処理を切り替えれば、1つの関数複数の処理をすることができます

function f(i) {
  switch(i) {
    case 1:
      // i = 1のときの処理
      break;
    case 2:
      // i = 2のときの処理
      break;
    case 3:
      // i = 3のときの処理
      break;
    // ...
  }
}

この方法は、以下に述べる「変数寿命を伸ばす」効果もあります。つまり、この関数内で宣言された変数は、すべての処理で共通して使用することができます

クラス不要関数を作らないようにするには、「継承」を用います複数クラスで用いる関数定義したクラスを1つ作っておき、そのクラス継承すれば、新しいクラス関数定義する必要はありません。

理想的には、プログラム内のすべての関数を同一のクラス定義し、それを継承するべきです。そのようなクラスは俗に「神」と呼ばれ、プログラマからはこの上なく尊ばれています

class God {
  f1() {
    // 関数1
  }
  
  f2() {
    // 関数2
  }
  // ...
}

class C1 extends God {
  // 何も書かなくても上の関数が使える!
}

class C2 extends God {
  // 何も書かなくても上の関数が使える!
}
// ...

変数寿命を長くする

変数宣言する場所によって、ソースコードのどの範囲から参照できるかが決まっています。この範囲が広いことを、「変数寿命が長い」と言います

たとえば、以下のコードのaは、関数定義の外側からは参照することができません。

function f() {
  var a = 1;
  return a;
}

一方、以下のコードのaは関数の内外どちらからでも参照することができます

var a = 1;

function f() {
  a = 2;
  return a;
}

変数寿命を長くするのは、プログラマの腕の見せ所です。

せっかく作った変数がすぐに死んでしまうのは、非常にもったいないです。ソースコードの表面には現れませんが、変数を作ったり捨てたりするのには、計算コストがかかります。したがって、寿命の短い変数を作りすぎてしまうと、プログラムが遅くなってしまます

また、変数寿命が長いということは、変数をたくさん作らなくても、1つの変数を色々なところで利用できるということであり、とても便利です。たとえば、上記の前者のコードでは、関数の外部からaの値を参照したくなっても、参照することができません。後者のように書いておけば、プログラムのどの箇所からでも、aの値を参照したり、更新することができます。したがって、変数寿命を長くするとプログラムを変更しやすくなります。つまり保守性が上がります

例外を潰す

例外とは、プログラムが予期しない処理をしようとした場合に、プログラムの実行を停止し、呼び出し元にエラーを通知する機能です。たとえば、「test.txt」というファイルを開こうとしても、そのファイル存在しない場合は、例外となります

例外が発生すると、プログラムが停止してしまうため、非常に困ります。したがって、プログラマ例外をきちんと処理しなければなりません。

ほとんどのプログラミング言語には、例外処理のための機構があります。たとえば、以下のような構文です。

try {
  // 例外が発生し得る処理
  // ex. ファイルを開く
}
catch (e) {
  // 例外が発生したときに、実行する処理
}

例外への対処は実はとても簡単です。是非ここで覚えて下さい。上記のような機構のある言語であれば、catch節の中身を何も書かなければ、例外が発生しても、何事もなくプログラム動作を続けます

try {
  // 例外が発生し得る処理
}
catch () {}

全ての例外を潰せば、決して不慮の動作で停止することのないプログラムを作ることができます。ですから例外が発生し得るコードは、積極的上記try-catch構文を用いて、例外を潰すようにしましょう。

おわりに

全体的に専門用語盛りだくさんの記事になってしまいましたが、

部分的にでも理解すればプログラミングを見る目が変わるはずです。

うさんくさい記事インターネットには多いですが、

そういう情報に惑わされずに本物の技術を身につけてもらえればと思います

2021-08-08

anond:20210808130731

サッカーオーバーヘッドキックをしないのが許せないので禁止するべき

なんでみんなキャプテン翼みたいにやらねえの?

2021-07-02

初心者から中級者になるためのプログラミングのコツ

変数や構文などのプログラミングの基礎は覚えた人向けに、ソースコードを書くときのコツを紹介していきます。どれも今日から実践できるものばかりです。他のプログラマと差をつけることができる技術ですので、ぜひ意識するようにして下さい。良い子はまねしないで下さい。

変数名は短く

プログラムで使う変数名は可能な限り短くしましょう。

理想は、aやxなどの一文字です。ただし、これだけだと26文字しか使えないので、a1, a2, ...のように連番でグルーピングすると良いです。

また、変数宣言使用箇所が離れた場合に、変数の型がすぐに分かるように、たとえばint型であればi1, i2, ...、string型であればs1, s2, ...のように命名すると、読む人に親切で自分ミスしにくくなります

変数名を長くするのは、以下のデメリットがあるため、絶対にやめましょう。


なるべく関数を作らない

多くのプログラミング言語には、クラス関数といった機能がありますが、これらは基本的ライブラリ提供者などが使う想定の機能であり、一般プログラマが使うのは好ましくありません。したがって、クラス関数はなるべく使わないようにして下さい。

関数を作ると、以下のデメリットがあります

不要関数を作らないためのテクニックには、以下のようなものがあります

まず、関数引数に「フラグ」を渡し、関数内部で処理を切り替えれば、1つの関数複数の処理をすることができます

function f(i) {
  switch(i) {
    case 1:
      // i = 1のときの処理
      break;
    case 2:
      // i = 2のときの処理
      break;
    case 3:
      // i = 3のときの処理
      break;
    // ...
  }
}

この方法は、以下に述べる「変数寿命を伸ばす」効果もあります。つまり、この関数内で宣言された変数は、すべての処理で共通して使用することができます

クラス不要関数を作らないようにするには、「継承」を用います複数クラスで用いる関数定義したクラスを1つ作っておき、そのクラス継承すれば、新しいクラス関数定義する必要はありません。

理想的には、プログラム内のすべての関数を同一のクラス定義し、それを継承するべきです。そのようなクラスは俗に「神」と呼ばれ、その利便性からプログラマからはこの上なく尊ばれています

class God {
  f1() {
    // 関数1
  }
  
  f2() {
    // 関数2
  }
  // ...
}

class C1 extends God {
  // 何も書かなくても上の関数が使える!
}

class C2 extends God {
  // 何も書かなくても上の関数が使える!
}
// ...

変数寿命を長くする

変数宣言する場所によって、ソースコードのどの範囲から参照できるかが決まっています。この範囲が広いことを、「変数寿命が長い」と言います

たとえば、以下のコードのaは、関数定義の外側からは参照することができません。

function f() {
  var a = 1;
  return a;
}

一方、以下のコードのaは関数の内外どちらからでも参照することができます

var a = 1;

function f() {
  a = 2;
  return a;
}

変数寿命を長くするのは、プログラマの腕の見せ所です。

せっかく作った変数がすぐに死んでしまうのは、非常にもったいないです。ソースコードの表面には現れませんが、変数を作ったり捨てたりするのには、計算コストがかかります。したがって、寿命の短い変数を作りすぎてしまうと、プログラムが遅くなってしまます

また、変数寿命が長いということは、変数をたくさん作らなくても、1つの変数を色々なところで利用できるということであり、とても便利です。たとえば、上記の前者のコードでは、関数の外部からaの値を参照したくなっても、参照することができません。後者のように書いておけば、プログラムのどの箇所からでも、aの値を参照したり、更新することができます。したがって、変数寿命を長くするとプログラムを変更しやすくなります。つまり保守性が上がります

例外を潰す

例外とは、プログラムが予期しない処理をしようとした場合に、プログラムの実行を停止し、呼び出し元にエラーを通知する機能です。たとえば、「test.txt」というファイルを開こうとしても、そのファイル存在しない場合は、例外となります

例外が発生すると、プログラムが停止してしまうため、非常に困ります。したがって、プログラマ例外をきちんと処理しなければなりません。

ほとんどのプログラミング言語には、例外処理のための機構があります。たとえば、以下のような構文です。

try {
  // 例外が発生し得る処理
  // ex. ファイルを開く
}
catch (e) {
  // 例外が発生したときに、実行する処理
}

例外への対処は実はとても簡単です。是非ここで覚えて下さい。上記のような機構のある言語であれば、catch節の中身を何も書かなければ、例外が発生しても、何事もなくプログラム動作を続けます

try {
  // 例外が発生し得る処理
}
catch () {}

全ての例外を潰せば、決して不慮の動作で停止することのないプログラムを作ることができます。ですから例外が発生し得るコードは、積極的上記try-catch構文を用いて、例外を潰すようにしましょう。

2021-05-27

ミドリムシ水素

といわれたらん~水素かなあと感じる。

ミドリムシCO2再吸収するとはいってもCO2結局排出するし、

それなら水しか排出しない水素のほうがオーバーヘッドがないというか、未来感あるよね。

そもミドリムシ生物から化石燃料と同じで、生命依存してるし。

https://response.jp/article/2021/04/10/344838.html

問題水素を作り出すうえで必要な電力やらだけどそこは技術向上でなんかなりそ。

やっぱミドリムシより水素だなあ。

http://hydrogen-navi.jp/technology/manufacture.html

2021-04-03

anond:20210403182456

そのとおりで、

APUやiGPUというものができてもう20年くらいになるけど、

いまだにオンチップのSoCディスクリートGPUでは性能に雲泥の差があるのは面白い

1978年のインベーダーから1988年PCエンジンまで10年で、

PCM音源が搭載された進化速度とくらべると非常に遅い。

結論グラフィックサウンドでは処理の難しさが天地ほど違うということだと思う。

https://btopc-minikan.com/note-gpu-hikaku.html

それに関連して、

GPU仮想化マイクロソフトがRemoteFXっていう技術で開発してたけど性能が悪くて断念した。

最近日本人技術者メインにGPU-P(GPUパーティショニング)っていうものが開発中で、

これがもしオーバーヘッドなしで、

n:1の分割のようなことができればグラフィック業界クオンタムリープになると思う。

2021-03-27

マージン上乗せ発想の人々

個人事業主フリーランサー中小企業経営者に捧ぐ

マージン発想の人たちからの教訓


今後の方針


(その他、マージン発想の人への対処方法を望む)

2021-01-02

anond:20210102000049

聞かないパターンについては「聞かなくてあとから袋を要求される」件数の少なさを鑑みれば「全件袋の有無を聞く」場合オーバーヘッドの合計時間下回るので、大手積極的に聞かなくなってる

消費者に最大限の福利だのなんだのが与えられる時代は終わる…

2020-12-27

面倒くさい人

性格悪い人よりも無駄コミュニケーションオーバーヘッドかけてくる人が苦手だ

個人的にはそういう人のことを面倒くさい人と呼んでいる

有名人の例を上げると三谷幸喜みたいな人

2020-12-06

パートナーとしての土木技術者ICBM施設建設

1940 年代後半から 1950 年代前半、土木技術者は、今日技術者と同様の問題経験していた。しかし、1950 年代と 1960 年代の一時期、これは変化した。大陸間弾道ミサイル(ICBM)計画運用計画が始まったことで、ミサイルの地上環境の設計者は、ミサイル設計者と一体となって仕事をしなければならないことが明らかになりました。

第二次世界大戦後、空軍ドイツ科学者採用し、ドイツのV-2ロケット備蓄品を捕獲してミサイル開発に着手した。1953年8月ソ連が熱核爆弾実験成功したと発表するまでは、資金不足がその努力を妨げていた。突然、ドワイト・D・アイゼンハワー大統領は、ソビエトに追い抜かれないようにICBMの開発に向けた大規模な努力を求めた。空軍の Bernard Adolph Schriever 少将は、ミサイルとその地上支援を開発するための努力の先頭に立った。

ICBMs

1.5段のアトラスと多くのサブシステムを交換可能な2段のタイタンの2つのICBMの開発がほぼ同時に開始され、知識ベースを広げ、最短時間兵器を完成させるための競争活性化させました。ICBMの開発と開発へのプレッシャーは強烈でした。推定 13 年かかっていた作業が、5 年以内に達成された。このことは、空軍土木技術者にとって大きな意味を持っていた。時間的な制約よりも重要なのは兵器システムの開発において、地上環境が後回しにされていないという事実であった。"飛行機は最低限の地上支援があれば飛行できるが、弾道ミサイルは適切な発射設備がなければ意味がない」というのが、このプロジェクトを主導した民間技術者の一人である空軍研究開発司令部弾道ミサイル部(BMD)民間技術部司令官ウィリアムレオンハード大将見解である

用地選定

ミサイル特殊要件圧縮されたスケジュールは、建設作業のあらゆる面に影響 を与え、まず候補地の選定プロセスに着手しました。空軍エンジニア工兵隊の代表者建築家エンジニアファームメンバー、BMDの職員構成される数十人の調査チームが、アトラス計画だけでも250以上の候補地を調査するために、全国に散らばっていました。チームはネブラスカ州からジョージア州まで、ニューメキシコ州からニューヨーク州までを調査しました。候補地の適合性を判断する際に使用された厳格な基準には目を見張るものがありました。深さ174フィート、直径52フィートミサイルサイロ、幅40フィート、深さ40フィートの発射管制センターサイロ、2つのサイロをつなぐ人員トンネルケーブルウェイを建設するためには、厳しい土壌と地質条件が必要でした。さらに、距離要件は、サイロがその支援基地から少なくとも18マイル人口25,000人以上の町から18マイル以上離れていなければならないことを意味していました。また、互いの距離は7マイル、人が住んでいる住居から1,875フィート公道から1,200フィートでなければなりませんでした。サイトへの公共アクセス道路は、大型のミサイル運搬車収容しなければならなかった。技術基準評価された後、最終的なサイト選択は、サイト経済的実現可能性に依存した。サイト選択され、承認されると、作業を開始することができた。

地上設備設計建設担当した技術者が直面した困難の一つは、ミサイルとその支援構造物作業が同時進行で急ピッチで進められていたこであるミサイルの準備ができたときには、発射設備を準備しなければならない。ミサイル自体必要設計変更が設備の変更に反映されてしまうため、ほぼ戦時中の緊急性の高い状況下での工事余儀なくされていた。

サイロ建設

ミサイルの保管モード、発射モードミサイル分散度の多様性技術者作業に影響を与えました。例えば、アトラスDの一部のモデルは、サービスタワーで露出した垂直方向に保管されていましたが、他のモデルは水平方向に保管され、風雨から守られていました。アトラスEは半硬化構造の中で水平に保管されていました。アトラスF、タイタンI、IIはすべて、硬化サイロに垂直に格納されていました。

サイロ建設は膨大なエンジニアリング作業でした。例えば、カンザス州シリング空軍基地では、エンジニアアトラスFミサイル収容するために12個のサイロ建設しました。作業は深さ40フィートの掘削からまりました。これが管制センターの基礎となり、トンネルサイロの上部を接続しました。その後、サイロの下部の残りの部分は、開 発部からさらに1.5m下で採掘されました。サイロ自体を構築するために、作業員はスリップフォームプロセス使用しました。フレームサイロの壁から約140フィート上に上がったところで、1時間に約14~16インチの速度でコンクリート連続的に打たれました。作業員は昼夜を問わず、1つのサイロにつき、わずか6日間で500トンの鋼材と5,000立方ヤードコンクリートを打設しました。完成時には、アトラスの1つのサイロには、15階建ての構造用鋼製ビル1棟の重量約1,500トンに相当する複合質量が含まれていました。

電力供給

打ち上げ施設に電源を供給するために、エンジニアディーゼルエンジン原子力燃料電池電池ガスタービン、商用電源との様々な組み合わせなど、いくつかの代替案を評価しました。電源は、信頼性が高く、無停電で、打上げ施設内で自己完結するものでなければなりませんでした。また、核爆発による地上衝撃によって引き起こされる非常に高い加速度を吸収できるか、ショックマウントに取り付けられていなければなりませんでした。システムイニシャルコスト運用保守コストの両方が評価されました。サイトへの動力供給には、信頼性の高い旧型ディーゼルエンジン選択しました。システム設計では,水や流入空気の加熱など,装置から発生する熱を可能な限り利用しました.典型的アトラスサイトでは,各プラントに1,000kWのユニットが4基ずつ設置され,ミサイルクラスターを支えていました.

サイロ上部ドア

サイロオーバーヘッドドア設計は、エンジニアリングのジレンマを生み出しました。300平方フィートの開口部を覆うドアは、極端な天候、核放射線、過圧、構造的な反発からミサイル保護し、ミサイルの発射と誘導に影響を与えないこと、発射合図後30秒以内に完全に開くこと、ミサイルカウントダウン手順の中で連続した項目として動作すること、などが求められました。また、クロージャの構築、完全な組み立て、設置、フィールドでのチェックアウトを可能にするように設計されていなければなりませんでした。シングルリーフ設計やロールアウェイ設計のようなそれぞれの潜在的設計には、それを考慮から排除する独自特定欠点のセットがありました。最終的に、ダブルヒンジ、ダブルリーフフラットドアのデザイン採用されました。2つの半分の間の中央の亀裂の問題は、ドアの特別なくさび設計と、さらシール性を向上させるためにネオプレンガスケットとステップメッシュ使用することによって解決されました。

サイトアクティベーション

様々なミサイルサイト建設アクティベーションに関与する多様な要素をすべてまとめることが、サイトアクティベーションタスクフォース司令官仕事であった。彼は、親コマンド関係なく、与えられた基地弾道ミサイルサイトアクティベーションプログラムに参加しているすべての空軍の要素に対する作戦上のコントロールを与えられました。主に土木工学諜報機関キャリア分野から来た司令官は、現場支援施設住宅建設を指示し、建設監視提供し、サイトの設置、チェックアウト、戦略航空司令部への転換を管理しました。土木機械電気技術者、低温工学、熱応力、衝撃実装専門家資金管理者、広報担当者、議会調査官への説明役などが求められた。要するに、彼らは空軍のためにそれを実現させた人物だったのです。1961 年までに、彼らはアトラスミサイル 120 発のアトラスミサイル11 基地に、タイタンミサイル 54 発のタイタンミサイルを 5 基地配備していた。

おわりに

この記事では、この大規模な取り組みに関わった人々が直面した様々な工学課題について簡単に触れただけです。その規模の大きさは今でも注目に値するものであり、土砂、岩石、泥の総量は3,755万立方ヤードに及びました。これは、ロサンゼルスからピッツバーグまでの深さ10フィート、幅10フィートの灌漑用水路に相当します。現場使用された鋼材は、サンフランシスコからワシントンD.C.までの鉄道線路建設することができました。当時、全国ニュース誌は「ミサイル基地建設計画ピラミッドティンカー・トイの演習のように見せている」と述べていますアメリカ土木学会は、ICBM施設建設プログラム1962年の "Outstanding Civil Engineering Achievement of the Year "に選出した。同様に重要なのは、この取り組み全体が、空軍土木技術者に対する見方の転換点となったことです。空軍技術者自分たちプロフェッショナリズムに対する尊敬認知度の向上を求めていた時期に、ICBMプロジェクトでの彼らの仕事が道を切り開いたのです。

2020-11-27

kotlinよりjni(C++)の方が200msも遅い

こんなことがあっていいのか

俺の実装へぼいせいか

それともマーシャリングオーバーヘッドはかくも巨大なものなのか

2020-11-24

2年後Macは無くなるんだろう

何言ってんだ、さてはアンチだなオメー。

―新しいARM Macは良いものだと思います。おおむねIntelモバイル上位機種の5割強くてRosettaで2~4割オーバーヘッドあってもまだ強いよというところが今回の勝つためのポイントだったのではないでしょうか。あとは低消費電力とAllways OnもあるけどSurface Pro Xでそれはユーザーメーカーに届かなかった結果が出てるので…。

いやいやベンチガンガン攻めてんじゃん?

―気になる点がいくつかあります


せっかくの転換点にM1凄さ以外で息切れしてない?

ネットで新Mac褒めてる人の実際の行動は「やっぱAppleってすげえな」でiPhoneiPadを買う。そう、Mac存在は知ってるけど必要はない。

Apple自身、桁違いのハード売上だけでなくロックインした市場アプリ販売もあるiOSに比べMacうまみがないのをよくわかってる。

なにしろiPhoneのおかげでこの10Macにとって絶好最強の追い風コンディションだったのだけどシェア10%前後という状況は変わらなかった。

今やりたいことはMaciOSへの合流でしょう。

ARMWindowsそもそもMSにやる気がない感じもあるけど、ユーザーにとって「違いを意識せず移行できる」=「特にメリットない」で、メーカーには「安くもならないしユーザーへのアピール少ないしアーキ変更の手間は多い」=「デメリットしかない」から動かなかった。

Appleはその轍を踏まえて移行を決定事項にした上で実際速いM1で一点突破、無関心の壁を越えたいのだ。花嫁ドレス(新デザイン)も着せないまま。

でも超えてどうすんのかな…うまくARMに集約できてマルチスクリーン展開するiOS未来しか見えないよ。

MacAppleにとってアイデンティティなので政治的にもないがしろにはできない…しかしこれだけ騒いで数字が動かなければしようがない、でしょ?

2020-11-18

キャプ翼で育った俺がキャプ翼必殺技現実サッカーであるかまとめた

必殺技現実
オーバーヘッドキック中途半端クリアボールシュートして押し込むケースが多い、センタリングを直接オーバーヘッドするのはスーパープレー
直線的ドリブル真正面同士でショルダーチャージで吹っ飛ばすドリブルはない、反則
ヒールリフトブラジル選手などが魅せ技でやる、欧州選手侮辱されたと感じるので反則で潰してやり返したりする
ツインシュート 偶然で発生することはあるが狙って出せないしあくまでただのシュート
三角蹴りディフェンス無駄な動きなので現実ではやらない
シュート ただの強めなシュート
ドライブシュート普通にある。コントロールが難しいので一流選手でもゴールを決められる選手は少ない
カミソリシュートバナナシュートのように楕円軌道を描くシュートはあるがいきなり鋭く曲がるシュートはない(無回転シュートならそのように錯覚はさせる)
スカイラブハリケーン ただの反則
イーグルショット ただの強めなシュート。地を這う強力なシュートプレミアリーグでは撃つ選手はかなりいる
タイガーショット ただの強めなシュート
顔面ブロック 偶然で発生する。発生したら受けた選手は悶絶して苦しんでる
ファイヤーショット燃えるシュートなんかねえよ馬鹿野郎
キャノンシュートジャイロ回転?のシュートということになるのだろうか。撃てる選手はいない
スライダーシュート いきなり横に曲がるシュートを撃てる選手ほとんどいない。そこまでのクラスになると歴代でもFKからベッカムぐらいしかいない。
ハリネズミドリブルからドリブル真正から弾き飛ばすのは反則だって
フライングドライブシュート普通にある。コントロールが難しいので一流選手でもゴールを決められる選手は少ない
サンターナターン ドリブル中にわざわざ反転してやらないが似た技にシャペウという技がありブラジル選手などが使ったりする
ローリングオーバーヘッド そんな体操選手みたいなシュート撃てる選手いません
雷獣シュート そんなシュートはない、たまにシュートした時に地面の芝生も抉れてるシュートはあるが別に威力は上がらない
ブーメランシュートコーナーキックから直接決めたりするシュートはあるので事実上それになる
ムササビジャンプ ある。みっともないのでプロではあまり見かけないがやった選手はいる。しかワールドカップでやった。
反動蹴速迅砲 狙ってできる選手はいない
スカイダイブシュート相手選手の足を踏み台にしてる時点で反則です
直角フェイント そのまま模倣してできる選手はいないが結果的に近いのではダブルタッチがある。イニエスタなどが名手
リバウールターン 現実にあるトリックドリブルでやっと現実にできるトリックが出てきた
つま先シュートロマーリオブラジルロナウドなどが使うシュートドリブルが上手い選手が使うとシュートタイミングが取りづらくゴールを決めやすいようだ
セグウェイドリブル できるわけないだろバカにしてんのか

2020-11-16

anond:20201115125745

プログラマ35歳定年説は、体力的なもの、新しいスキルを学び続ける事、SEPM等へのシフトアップ必要な事から言われていますが、

私は、「その年になるまでPGなんてしてられるか」とか「その年までにはSE等のシフトアップ必要でしょ」みたいな感じでした。

匿名さんは、コーディング限界が来て辞めるのではなく、人との絡みに嫌気がさして辞めているようにも感じます

システム開発は、企業の都合で開発責任者が決められてしまうために、その人材により、下の者は苦労します。

プロジェクト国家のようなもので、酷い政治家(PMSE)の国で暮らす(開発する)のはしんどいと思います

システム開発するうえで、一番効率が良いのは1人で作り上げる事だと思っています。つまり、35才定年説なんてありません。

1人で作り上げる理由は、人が言葉文書だけでコミュを取って意思疎通するのには限界があるからで、

今では相当なモジュールが完成されているために1人で開発する環境は昔ほど悪くはないと思います

規模がどんなに大きくなっても、根幹部分や仕組みは1人が仕様決定してコーディングしておき、

その他はテストメンテが容易になるようなコーディング規則と、

出来る限り単純な仕組みを作って他のプログラマに守りやすいようにして複数で開発することがいいと思います

サブシステム毎にSEがいて、同時開発していけば、似たような機能を持つ関数・メンバが大量に別名で作られてしまい非効率になってしまますので、

そのあたりをまとめるための雑務的なSE配備必須です。

この雑務SE重要ポジションで、意図目的が明確になっていて中でどのように動くかが明確でなければ、

それが不具合となり匿名さんのような苦悩を味わいます

あと、人が増えれば意思疎通のミーティング必要になり、冗長的になってしまますので、その効率化も求められます

話しを定年説に戻しますが、

【年と共に覚えられる記憶量に限界が来る事】

という体力的な面について、日々感じている事を書きます

20代では、携わるシステム関数・メンバ・変数等は、約数千個程度は記憶出来ていますが、

30代では、それが半分程度になります40代では更にその半分程度になり、50代ではせいぜい数百が限界になってきます

それを補うための開発環境進化と、コーディング内のコメントの充実で、逆に不具合の少ないシステム構築が出来るので、

20代では一気に開発が出来ますが、デバッグ時間がかかり、50代では開発は時間がかかりますが、デバッグには時間がかからないという傾向にあります

それでも数百程度を越えて来ると翌日には忘れていく部分があるため、日々、忘れている部分を確認して思い出す時間だけ開発にオーバーヘッドがかかります

そのため、常に忘れては思い出してを繰り返す事になり、自身記憶容量の限界を痛感する日々になってしまます

【人との絡みで限界を感じているのでしたら】

限界だと感じた時が、定年なのかもしれませんが、システム構築をする事が楽しいのであれば、いつでも現場復帰していいんではないでしょうか?

技術は日々、新しくなって行きますので、頭に入れるのは大変かとは思いますが、根幹はそんなに変化ありません。

私自身も、必要かられて自分マルチタスクスクリプト言語を開発していましたが、

量子コンピュータにならなければ、どれも似たような構造しかありません。

また開発したいと思ったりクライアントがいて需要があるなら、1人で出来る範囲を開発して、足りない部分は誰かに委託してみてはどうかなあと思います

2020-08-15

anond:20200815181444

手間的にも通信量的にもAPIの分割はオーバーヘッドを増やすから、そこはトレードオフやな

今回は権限上の問題

ログインユーザーでなければIPはnullとかundefinedで返しとけばよかったわけ

2020-08-01

anond:20200801214621

なにグラフィックの話?

オーバーヘッドを考えたらラスタライズとか後処理考えたら頭から穴までGPUでやる以外選択肢なくね?

2020-07-18

anond:20200718044903

最初質問を見たときから普通にidjoinしてるだけじゃないのって思った

RDBを使って作ってあって、新しいtableが参照したいテーブルidを持つようにしておけばjoinで全部の要素を持った大きなテーブルがあるかのように扱えるよね。

気ままにそういう運用をしてきたらjoinによるオーバーヘッドがばかにならなくなってきたり、テーブル間の関係が複雑になりすぎて訳が分からなくなってくると思うので、そういう時はいったん開発を止めてリファクタリングするべきだろうね。

個人的には開発がある程度進んだ段階で全体を俯瞰してご破算で願いましてはして作り直すのもそんなに嫌いじゃない。

2020-07-06

1日のバッチ

インスタンスをかりる

 ↓

初期化する

 ↓

処理

 ↓

インスタンス削除

 

どうしても、ショッカのオーバーヘッドがかかるのでしょうがない。

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