  |
はてなキーワード: Cobolとは
（一気飲みを奨励するものではありません。お酒は20歳になってから）
パーアル パール パール フワフワ パーアル パール スクリプト
コーボル コボル コーボル フワフワ コーボル コボル コーボル 構造化
ルービイ ルビー ルービイ フワフワ ルービイ ルビー オンレイルズ
リースプ リスプ リースプ フワフワ リースプ リスプ 丸カッコ
スーカラ スカラ スーカラ フワフワ スーカラ スカラ 暗黙の
エースキュ エスキュ エースキュ エルエル エースキュ エスキュ 行ロック
ラースト ラスト ラースト フワフワ ラースト ラスト 所有権
ジャーバス ジャバス ジャーバス クリプト ジャーバス ジャバス webpack
（最初に戻る）
何かの参考とかにしたらダメです。書き始めて半年経つんだけどこっからどう直したらいいんだか（何をゴールにしたらいいのか）わからない。。
追記：合流性とか強正規化可能性とか停止性とか、全部チューリング不完全で、事前の静的解析で使うメモリの最大量が確定できる、とかそういう風に読み替えられる人を増やしたいのです、数式の添え字とΣと∫にびびらない人を増やしたいようなもので
数理論理学の一分野である証明論から成長した、数理論理学と理論計算機科学の境界領域の研究領域である型理論(type theory)は、大規模なプログラムの内的な整合性のチェックを行うための方法論を必要とする情報処理技術の分野で関心を集めている。
そもそも「型」(type)とは何か。プログラミング言語は一般的にはレコードや関数といったプログラムを構成する「値」(value)の定義をする道具である(*1)。その言語のコンパイラ作成者はこれらレコードや関数などの値、もしくは第一級の対象(first-class object)の種類を区別する型システム(type system)を必要とする。抽象代数学の観点からすると、「型」とはこれらの値もしくは第一級の対象が属する高階の対象(higher order object)としての空間(space)ないし代数系(algebraic system)で、型システムはそれら「型」とそれら相互の関係(relation)つまり型のなす順序構造(order structure)ないし束構造(lattice structrure)であるといえる。
プログラムを構成する値すべてに型が付くためには、曖昧でない(*2)こと、自己矛盾していないこと、悪循環を含まないこと、それぞれの値の内容をチェックするために無限の時間を要しない(*3)ことなどが必要で、これらを満たすなら、プログラムは有限時間で実行を終え、停止する。手続き型言語では無限ループ、型無しラムダ計算では無限再帰によって型付け不能なプログラムを書くことができるが、型理論はこれらのチューリング完全な計算機を意図しない停止しないプログラムから守る装甲でもあり、再帰やメモリ確保で好き勝手をさせないための拘束具でもある。型が付くプログラムには単に停止するというだけでなく、可能な実行経路（訂正：経路→方法）のすべてで同じ結果を出すなど種々の良い性質がある。
1)この定義は現実に使われているプログラミング言語の特徴を覆い切れていない、狭い不満足な定義だが本稿では都合上この定義に立脚して限定的に議論する。例えば変数(variable)というものを持つプログラミング言語もあり広く使われているが、これについてはレコードや関数と同じように性質の良いものとして扱うことが難しい。難しさの原因は次の注の内容と関連する。近年は変数を扱うかわりに値の不変のコピー(immutable copy)やその参照に名前を付ける機能を持つプログラミング言語が増えている。
2) 現実の情報システムでは、COBOL言語のレコード再定義やC言語の共用体、一般的な関数ポインタやVisual Basic言語のvariant型変数のように、同一領域に異なる型の値が共存する共用型(union type)の値がしばしば必要となる。共用型の値はgoto文を排除した構造化／オブジェクト指向プログラミングにおいて条件キャストやクラス分岐などによる実行経路の複雑さの主要な原因になるが、これは和型(sum type)すなわち相異なる型の非交和(disjoint sum)として定義することで曖昧さなく定義できる。
3) ゲームプログラムやネットワークサービスにおいてしばしばみられるように、入力として無限リストや任意に深い木のようなものを想定する場合には明らかに（条件を満たさない限り）停止しないことが正しい動作となり、この場合は最外周のループを（←どうする？）メモリリークを起こさないなど別の考慮が必要となる。
この件⇒ https://togetter.com/li/1452558
ユニケージはbashのパイプで作られた、RDBMSを使わずテキストファイルによる空白区切り行志向レコードへのデータ処理（だいたいプログラム1本の処理内容がメインフレームのCOBOLのそれと同じくSQLクエリ1個に相当する）で、同形式によるマスタとトランザクションファイル（RDBMS内部のredoログに相当）を使う（データに含まれる空白文字0x20はアンダーバー0x5Fに置換する、アンダーバーが複数存在するデータの場合どう扱うかは知らない）
開発と更新は早いんだけど参照が（テキストファイルなので）インデクスが効かないためシャーディングするしかなく、要するに検索機能の柔軟性がなく、リアルタイム性を損なう
おそらく基幹系というか在庫管理をユニケージでやっているので、ウェブサイト自体はユニケージで実装されていないかもしれないけど、しかし根幹に上記のような手作りのデータベース実装があるし、RDBMSに移行するとなると全部を止めてマスタとトランザクションファイルをマージしてインポートすることになる
追記：トランザクションファイルのマスタへのマージは営業時間後の日次バッチとかでやるはず
システムを止めている間も店舗が運営を続けているなら、たとえば店頭在庫を潤沢に積んだうえで、店舗間での在庫の融通は禁止し、店頭での売り上げ分はどこかでRDBMSに計上しなければならない
追記：テキストファイルに対するインデクスをつくって行頭へのシークの高速化をすること自体はもちろん一般的には可能だけど、ユニケージの方法論だとそれをする標準的な方法はないはず。ユニケージはRDBでもNoSQLでもなく、バイト位置でのシークという操作自体がない世界なので。sedとかで行の差し替えをした場合（SQLのUPDATE相当）当然行頭のバイト位置が変更した行以降ですべてずれてしまう可能性があるのでインデクスの更新がひどく非効率になる
追記：文章下手ですみません。ユニケージの良いところはRDBMSの実装の基礎を理解できるところ（これはDate先生の教科書を読んだりOracle Silverの勉強をしたりSQLの書き方を工夫したりクエリプランを読んだりするよりずっと効率的に学べる、ただしファイル編成法の知識はちゃんとした教科書で補う必要がある）、アプリケーション実装技術について横断的な理解ができるところだと思います（USP研究所のシェルスクリプトマガジンには実際勉強になりそうな記事が多い）自分はユニケージへの移行案件を生き残れなかったクチなので。。
追記：Tsukubaiは好きになれませんでした。
エンジニア職に就いたあと辞めたポエム の者です。業務終わりにみたら伸びてたので補足がてら。ぼくのいる雪山はまだそんなに積もってないんで16時くらいに閉めるんですよね。空気も美味いよ。暖冬最高。「週休2日しかもフレックス」なんて無いけどな。
はじめて書いた増田で、こういう形で二の句を継ぐなんてダサすぎる気がしますが、少しでも注目を得られたのが意外だったので。きもちは残して晒したい派です（なら実名でやれ）。
ここから先はフィクションです。遠い昔、遥か彼方の銀河系の、たまたま地球に似た惑星の、たまたま日本に似た列島の、とある僻地の物語。
もともとフォークやユニック乗ったりしてた人が途中からエンジニアを志してたらこんなヘソの曲がった駄文ではなく、もっと真摯な文章になってたと思います。自分の場合は逆で、バイトのためにフォーク免許取っただけなので、べつに工場勤務はバックグラウンドではないかなぁと思ってます。あと、1~2年で書ける才能があればよかったのですが、阿呆なので3~4年くらいやってこのレベルです。電工二種は落ちました。あれ受かるの天才じゃない？
ほかの多くのひとも言及してますが、マジでどこにでもある話だと思います。ただ、どこにでもあるはずだしタブーでもないのになぜかあんまり表立って見かけないのでぶん投げました。個人的には「どこにでもある話」と言ってる人にどうやってサバイブしているのか教えて欲しいところです。自分は妥協以前に病んだので駄目でした。
あとこれもよく言及してますが、今読み返したらフェイク1.5割くらい、本質に関係なさそうなのを含めると3割くらいな感じです。経緯っつーか言い訳としては、最初個人ブログに投げるつもりだったのでフォーカスずらしてうっすらとブラーかけてたんですが、客観的にみたときにdisだけで終わりそうになってしまったため、増田にアップしようとしてどうせならと加筆しまくったら文字数制限にひっかかってしまい、最終的にざっくりと削ったり言い換えたりしたのも影響してます。ところどころ日本語がおかしくなっとる（のに頑なに好きなvtuberの箇所は消さないスタイル）。
言葉っつーか界隈で使われがちな単語とかは、この程度ならQiita読んだりTech系ポッドキャスト聞いてると刷り込まれると思います。と、ほぼ未経験元SEが言ってみる。
本文中には敢えて書いてませんが、MTG時に議事録録る役を充てられている人がいました。その人が不在のときに自分に役が回ってきて、書き方はこれまでのやつを参考に、と言われたのでやったことが数回ありました。というか正しい議事録の録り方ってどっかで習えたりするもんなんでしょうか。いいなぁ。
これは指摘されて書き方が間違っていたと気づきました。もともとあったシステム部門を切り出したわけではなく、正確には新しく受注するシステムみたいなのを専門にやるために作った、というのが正しいと思います。うーん、そういわれれば本来そういう部門があったかどうかも怪しいです。どうしてたんだろう。
ほかの方も地域差について言及してますね。べつに場所にこだわりはない（ただし都市圏を除く）ので住むのはどこでもいいんですが、スキルに関してはたぶん過大評価です。ほかの方も能力について言及しているのを見かけますが自分のスキルセットは大したことないと思ってます（といってそもそも実務経験がこれだけなので棚卸しもなにもない）。今回は客観的に技術力を評価してもらいたいというのが主目的で入社したのですが、ご覧の通り結局叶いませんでした。せめて研修くらいあって、テックリード的な役割をしている人がいれば最高なんですが、逆にいうと地方でそんなのほとんどねぇよな〜という印象です。なんのためのインターネット・テクノロジーやねん。
本文にも書きましたが賃金はわりとどうでもよくて、「300万出す」と言われたら「180万でいいんで週休4日にしてくれませんか」てな感じで自分の時間を優先するタイプかもしれません。帰属意識や社会的責任が云々ではなく、単に貧乏性なんだと思います。
外国人たくさんいそうで英語使う機会ありそうだし面白そうだったんで白馬いきたかったです。。。
マジで行きたいですね。べつに場所にこだわりはない（ただし都市圏を除く）ので。バイト期間中にそこらへんの会社のリサーチをしてみます。札幌/仙台/金沢/岡山/福岡以外にどっかありますかね？海外でも火星でもいいけど。
ずっと相互のコミュニケーションが不足してるなぁという思いはありましたし、そこが問題だと思ってました。でもどうすりゃいいか結局わからなかったですね。本文に書いた「ポエム褒め褒め大会」や「全社清掃」も実はレガシーな形での相互理解の場のつもりだったのかもしれません。なんつぅか、互いに童貞・処女みたいな感じでした。童貞に雰囲気なんて作れるわけないよね。。。
自分も大好きで事あるごとに読み返してます。彼のような超天才タイプとは程遠いですが。お気づきのように冒頭の "ここから先はフィクションです" はリスペクトです。
ぼくのはなしは、これでほんとにおしまい。
退職者アドベントカレンダー2019はまだはじまったばかりです。楽しみですね。
深夜のパソ通で寝不足なのをマシン室に行ってるふりしてトイレで寝てるとか
アルゴリズム考えてるふりしてエロい絵が見えるパズルを短い手順でクリアするパターンを考えてるとか
同期の女子にJCLのわからない所教えてあげて必ずお礼するとか言われてもそれは絶対にないと思ってるとか
FさんやクライアントのSEが能力認めてくれてたから良かったけど
付き合いきれんかったわ
FのSEさんも欲求不満でマシン室でストレス解消にストックフォームの詰まった段ボール箱に
指で穴を開ける遊びをしていてそれも習得
力よりもインパクトの瞬間に手首のスナップで最速を出すのがコツ
やっぱり2年で学ぶことは無くなったな
ぶっちゃけタルいのがすげー嫌。
Oracle DBの使い方を習得するのに、一番最初に用意すべきなのはパソコンでもサーバでもない。
その教科書で、まずはスキーマやインスタンスやアーカイブログやREDOログといった、Oracle DBの仕組みや概念を学習する。
次にそれが実際のサーバ上でどんな風に見えていて、どうオペレーションするか…というアプローチを取らないと、絶対に動かないようにできている。
あーもうすげーめんどくせー。
なんでこんなにもったいぶっていて、無駄に固いんだか。覚えにくいことこの上ない。
それに比べると、PostgreSQLはフリーソフトなのに本当によくできている。
無駄な前置きは一切なしで、実際にいじりながら覚えていけるのでハードルが超低い。
てか、こういうのでいいんだよこういうので。
そもそもOracleのような「教科書と授業」みたいな形式で覚えてくのって、ストレージやアプライアンスを扱うのも仕事のうちという構築や運用の人間ならともかく、プログラマにとっては全く水が合わない。
だってCOBOLやFortranが主流だった大昔ならいざしらず、開発の世界じゃそういうのはC言語が出た時点で時代遅れになってるから。
まじで勘弁してほしい。
・20世紀から言語仕様が変わっておらず、今後も変わらないため、JavaやPythonやrubyみたいに毎年最新仕様を追いかける必要がない
・あと50年は無くならない。米国の各大手金融機関ですらCOBOLを残す決断をしているので、日本もそれに追随する
・上記の通り需要は残り続けるが、若手エンジニアでCOBOL志望者がほぼ居ないので、超ブルーオーシャン市場である
・新しいことはあまり出来ないだろうが、金融系システムでは「バックエンドはCOBOL、フロントはWeb」という組み合わせが珍しくないので、Web系技術も一緒にやりたければ出来る
