  |
はてなキーワード: スクリプトとは
たぶん、ここ数十年で幾度となく繰り返されてきたであろう話題。そして、これからも何度となく同じ話をして行くであろう話題。だけど、この先に幾星霜の年月を重ねようとも、決して人類が回答を得ることはかなわないであろう話題。
「このような増田を書く際には適度な自分語りが必要である」との先人の教えに倣い、私も自身の人生を少し顧みる。
とは言え、特にこれといって語れるような、起承転結、栄枯盛衰の激しいエピソードはない。期待に沿えず申し訳ない。
私は、凡庸な働き者である両親の下に産まれ、大学まですべて可もなく不可もなしと言ったレベルの国公立で通し、東証一部ではないが倒産寸前でもないと言ったどこにでもある企業に就職し、今に至る。要は平和を謳歌していたわけで、「幸せかどうか」という尺度で測れば、私は十二分に幸せなのだろうと思う。
先日、同級生の友人らと一席設ける機会があった。私の交友範囲は、狭いようでいて結構広い、まあ所謂「普通」の範囲内だ。私ほどの年齢になると、このような場でだいたい出てくる話題と言えば、増田諸氏にもお馴染みの「子供の話」である。
子供の習い事は何がいいか、今どきは中学受験をさせるべきか、保育園になかなか受からない、・・・語らいの場を彩るには事欠かない。
私自身は独り身だが、そう言う話題は端的に言えば好きである。同級生の、愚痴のような自慢のような我が子の話を聞くのも好きだし、独りやもめが一丁前に進言することも吝かではない。
だが、そう言う話題をしていると避けて通れないのが「増田は結婚しないの？」「増田の子供、見てみたいよ」等の友人の無邪気な言動である。
もう何度となく聞かれたので回答が半ばトークスクリプト化しているが、私自身は結婚する気が全くない。子供を作る気もない。
友人らの結婚式に持参した祝儀袋は50枚ではきかないし、友人らの華燭の典の末席に私の椅子を加えてもらえるのは悪くない。幸せのおすそ分けがあった数年後に、友人らの間に生まれた新しい命に触れる栄誉に浴した機会も両手両足では足りないだろう。
そんな友人達の子供の相手をするのも、また楽しい。先日も友人宅で友人の子供たちとゲームで盛り上がった。そういった私の姿を見てきている友人達はいつも怪訝そうな顔をして、お決まりの言葉を投げかけてくる。
しかし、残念ながらそんな姿を友人たちに見せる機会は、永遠に実現する事はないだろう。なんだかこちらが申し訳なくなってくるが、こればかりはどうしようもない。
結婚出産をしない事の仔細については伏せさせていただくが、私自身はLGBTという訳でもないし、病気等によって子供が作れない身体という訳でもない。過去に交際した異性がいない訳でもないが、結婚するというビジョンは当初から皆無だった。
・・・さて、長々と私の宴席話を綴ってしまったが、ここまでが枕詞である。以下より表題の件となる。
最近発生したとある些事によって、私は自身の今後の人生を考える機会を得た。それは老後の事であったり、貯蓄の事であったり、人間関係の事であったりする。
不思議と不安はない。「少くとも僕の場合は唯ぼんやりした不安である。何か僕の将来に対する唯ぼんやりした不安である。」と言ったのは太宰だったか芥川だったか。或いは川端だったかも知れない。
老後を一人で支えていく貯蓄は作れる。今現在のところは十分な資産が無い為「ある」とは胸を張って言えないが、仮に70歳定年制度が導入されようとも、食べていけるだけの資産を形成するだけの資力はあるものと自負している。
加齢による孤独との付き合いも、それなりにこなしていくつもりだ。とは言え、老境に達した事もない若輩が悟ったような事を口にするのも軽々しい。鋭意努めるといった表現に留めておこう。
そのような事を独りごちること数日、ようやっと私は「自身に生きている理由がない」と言う平々凡々な結論に至った。
却説そうなると困ってしまう。理由もないのに生きていくには、あと数十年という年月は些か長すぎる。排泄物を生産する装置として延々と過ごしていくには動機づけが心許ない。
人生に対しての意味を考えるのは、数多く存在する宗教という団体が約二千年ほど前から継続して取り組んでいるようだ。詳しくは知らない。
彼の団体が世に出している成果物を拝見したこともあるが、私には意味を見出すだけのものはなかった。
理由も無い、意味もない。そうなると次の段階として「可及的速やかに、かつ周囲の迷惑を最小限にとどめる形で自殺する方法を考察する」ということになるが、私にはそれを実行するだけの胆力が備わっていなかったようである。自ら命を絶つという行動を想像するとき、自身の玉袋が萎びていく感覚が如実にそれを証明している。
安田講堂で演説をぶった後に割腹して果てたのは誰だったか。筋骨隆々とした当時の写真を見るに、グラビアモデルか何を生業としていた人だと推察しているが、どうだろうか。職業はともかく、その胆の据わりようはまさに驚嘆に値するが、私には到底真似のできない所業である。
理由も無く、勇気も無い。理想も無かった。願望もこれといって無かった。意味のある無しは私自身が決定するものではない。後世の人間が理由付けしたものが意味だ。
かと言って「無い」状態を維持していくのも据わりが悪い。回答でも解答でも一向に構わないのであるが、「ある」状態にしたい。ふとそう思い至って有休申請をしたのが昨日の午後、目の前のキーボードを叩いては嘆息する作業に飽きてきたのがつい先ほどの話だ。
先人の知恵を生かす事こそが人類であり、その事を辞書で引くと即ち「英知」である。ならば私も人類の英知の恩恵に与ろうと「はてな匿名ダイアリー」なるサイトの中に設置されている検索窓で「人生 理由」と入力してENTERキーを叩いたところ、検索結果は0件だった。平日の昼間から「人生 理由」や「人生 意味」といったワードで検索をかけている中年男性という絵面も大変に珍妙ではあるのだが、ここで膝を折るわけにもいかない。
Google検索で「人生、宇宙、すべての答え」で検索すると「42」という解が得られるというのは割合に有名な話ではあるが、できれば証明過程のほうも見せていただきたいので、「人生 理由」や「人生 意味」などのワードでGoogle検索をかけても、有象無象が多くて選り分けるのに四苦八苦しているうちに時間だけが過ぎ去っていく。回顧するに到底建設的な所作とは言えない。
※ちなみに、「人生 理由 anond」等とGoogle検索すると、先人への英知に到達する作業が捗ったという事実も申し添えておく。
・・・結局、特段の進歩もなく、たまっていた有休を消化して終わるだけの一日となりそうだが、髪の毛一本分、まさに寸毫ほどの厚さだけでも遺物があれば、後進増田諸氏の灯台となり得る可能性はあると考えた。
可能性に賭けることは好きではない。そもそも賭け事が嫌いだ。だが、この愚かな人間がしたためた理由も意味もない駄文が、誰かにとっての灯火となれば幸甚である。
大海原の中のマッチ一本分にも満たない、本当に小さな灯り火であるが。
ここまでお付き合い頂き、かつ増田諸氏の人生の貴重な時間をも少々頂けた事に深謝する。増田諸氏の人生に幸多からん事を祈念して、ここで筆をおく。
$
2046年。東京オリンピックの年に生まれた人間が三十路に差し掛かる頃。
餃子チェーン店のテーブル席で、野暮ったい女がビールを飲みながらノートパソコンに何か打ち込んでいる。ひどいクマと死んだ魚のような目はまるで亡者だ。亡者がスウェットを着て餃子をつまんでキーボードを叩いている。
老紳士が現れる。ボウシを取り、くすんだ色のトレンチコートを脱ぎ、女の対面に当然のように座る。老紳士は老いているからか、挙動がぎこちない。
「やあ、赤坂くん」
女は答えず、画面を見ながらチャーハンをゆっくり口に入れ、咀嚼する。
女、赤坂は無視し続ける。ポッケからイヤホンを取り出し、耳にはめ込む。無言の意思表示だ。老紳士はしばらく黙っておいて、それから何を思ったか、半分衝動的に赤坂のパソコンをパタンと閉じてしまう。
「おい」
乱暴に、短い抗議の意を示す赤坂。老紳士はとぼけて、それを意にも介さず用件を切り出した。
「ロシア上空に、GPS衛星と偽装されたアメリカ軍の偵察軍事衛星がある。それにちょっと侵入(はい)ってきてほしい」
手に折りたたまれたコートのポケットをさぐり、メモリードングルを取り出す老紳士。赤坂はそれをむしり取って、小さな機械に差し込み、それを有線でパソコンに繋いだ。
「あいかわらず厳重だな」
「パソコンに直接差し込むのは、信用できる機器だけにしてるんです。教授、あなたからそう習ったはずですけど」
呆れる老紳士に皮肉を返すと、赤坂はメモリードングルに入った資料を開いた。
「5ページ目にリストされているETN-G-129がそれだ。表向きは、商用オフザシェル化の一環として宇宙関連企業のパラジウム社が受託し打ち上げたBlockⅢ代替のGPS衛星だ。しかし、実態はちょいと違う」
ある資料には、膨大かつ一般人には意味不明な数列が延々列挙されていた。2桁の16進数が大量に連なっている。しかし、彼女にはこれらの意味が分かる。
「そうだ。しかも、暗号化されていたものをご丁寧に平文にして転送している。NSAも随分と腑抜けたものだよ」
注文を取りに来た店員にお冷を頼んで追い返す老紳士。彼がひどい下戸であることを赤坂は知っていた。
「まあそうだな。依頼主はアメリカ側からのアクセスを止めさせろと言っているがな、それじゃあんまりつまらんだろ」
店員が会話を中断させ、水を置いていく。老紳士は一口、いかにも老人といったしぐさで飲む。
「赤坂くんの好きにしていい。おそらくコントロール系統はNORADに接続されている。君の腕ならば、衛星を踏み台に使うのも良かろう」
「それだったら、もう少しマシな手があるし、だいたい軍やら何やらに侵入するのはあなたの持ってくる依頼のせいじゃないですか」
「はて。ワシはバス接続の危険性以外にもこう教えたはずだがな。『君たちは楽しい楽しいオモチャを手に入れたのだ』とな」
ーーーーーーーーーーーーーーーーーーー
帰る途中。コンビニに立ち寄り、ソフトクリームを食べるための座席に座り、キーボード付き携帯端末を公衆無線ネットに繋ぐ。会員登録をしろとせがむ画面を消し、スクリプトをいくつか走らせると、すぐに管理者権限が手に入る。
いくつかプログラムを自動インストールさせ、オニオンルーティングとVPNで秘密の回線を作り出す。これで発信元の特定が困難になる。
そこから接続するのはとあるアメリカ軍人の個人端末だ。以前とあるショッピングサイトから流出した情報を使って、たやすく乗っ取る。今、アメリカはだいたい朝の10時。運が良ければ、軍人は軍施設内にいるはずだ。果たして、軍人は施設内におり、乗っ取った端末から施設の無線ネットに接続出来た。
軍用のシステムはちょっと頑丈で、コンビニのサーバほど簡単に侵入らせてはくれない。辞書攻撃を仕掛けつつ、母校たる東京電波大学の誇るスーパーコンピュータを使って秘密鍵の推測を行う。
20分程度かかって、なんとか秘密鍵を割り出した。同じ公開鍵が無線ネットの接続に使いまわされていたのはラッキーだった。こうして米軍のシステムに侵入できた。
しかし、いくら同じ米軍のシステムと言えど、見たところこの施設はただの空軍基地。件のスパイ衛星のコントロールシステムはそこには無いようだ。
そんなことは赤坂も最初から分かっていた。赤坂の狙いは、空軍基地にある衛星通信用のアンテナだ。これを使い、標的の衛星の近くにいる衛星にアクセスし、乗っ取り、そこから標的の衛星にアクセスするのだ。
これをやってみると上手くいかない。アンテナから衛星が遠すぎたのだ。仕方なく他の米軍基地をまた乗っ取り、やっと標的にアクセスできた。早速データベースを覗きこむ。
中身は、ロシアと米NSAの秘密鍵などでギッシリだった。これだけ色々あれば、次また教授が何か言ってきても楽になんとかなるだろう。
『衛星はーーNORADに接続されている。ーー踏み台にするのも良かろう』
教授のほざいたことをふと思い出し、コントロールシステムへの信号に偽装フレームを紛れ込ませてみる。偽装パケットには小さなフレームが仕込んであり、相手システムが受け取ると即座に実行され、こちらに諸々の情報を返してくる。すると米空軍の心臓を掌握したも同然である。
いささか満足し、帰る準備として証拠の記録であるセキュリティログを隠滅しようとして気づいた。セキュリティログが明らかに不自然だ。誰かが一部を消したのだーー赤坂が今やろうとしているように。
「私以外に、誰かが侵入っていたんだ。しかも、私とほぼ同時に」
少し気味が悪かったが、適当に証拠を処分し、衛星は傍受したデータではなくランダムに生成したデータを送信するようにしておいて、その場は終わりにした。
ーーーーーーーーーーーーーーーーーーーーー
レジに座り、大きなあくびをした。普段、赤坂は平成商会でアルバイトをしている。平成商会は新横浜にある、電子パーツの問屋だ。マニアと業者だけがやって来て、一般人にとってはガラクタにしか見えない物を買い漁る、知る人ぞ知る店である。
声をかけられ、顔を上げた。教授だった。ふざけている。そんなもの、彼が探しているはずもない。依頼の成果物を取りに来たのだ。
「これ、衛星のコンソールへのリンクです。米軍施設にあるコントロールシステムの電源が付いている限りは、自由に例の衛星をコントロールできます」
事も無げに言い、携帯端末に二次元コードを表示して差し出す。教授はうなずき、コードを写真に撮る。
「報酬はこれだ」
教授は提げてきた紙袋から何か取り出した。大きくて古臭い、中世のコンピュータの周辺機器だ。
「ずいぶん探したんだぞ」
「そうそう。ウチの大学のスパコンあるだろ。あれが短時間何者かによって不正利用されてたらしくてな。学内大騒ぎだ」
「ワシの研究室にもちょっと来てね、誰がやったか調べてくれって言うもんだから見てみたら驚いたよ。RAMに公開鍵がたっくさん入っておったよ。あれがNORADの鍵かね」
「いや、あれはどっかの米軍基地の鍵でした。NORADの鍵は私が大事に保管してます」
「鍵は大事に保管ね。当然だ」
教授が帰った後。店主の勧めでペケ86kを店頭に展示すべくパソコンに繋いでいる時。
「あの……すみません」
どこかから女の声がするではないか。嫌だな、怖いな、と思いながら声の方向をたどると、一つの端末が音声通信をしていた。
これだからP2P通信は。無視して通信ソフトを落とす。が、何度やっても立ち上がる。
「ちょっとお尋ねしたいんですが……」
電源を落としても、もう一度つく。コンセントを引き抜くと、別な端末に移る。
「もう、やめてくださいよう。ちょっとぐらい話きいてくれたっていいじゃないですか。ひどい」
「いやいや、あなたこそ誰なんですか……？米空軍の迎撃システムに侵入したの、あなたでしょ」
「私はただのバイトだ。消えろ」
キーボードを叩き、スクリプトを走らせて回線を遮断しようとするが、文字が入力できない。
「ネット切ろうとしてますよね。それはボクが困るので、キーボードの接続を切りました。ははっ」
ここで赤坂は確信する。こいつがあの不自然なログの正体だと。赤坂と同時にNORADをクラックしたハッカーだと。
「気持ち悪い」
「心外だなあ。ボクはあなたに興味があってはるばるここまで来たんですよ。ちょっとぐらい相手してください……」
「よっと」
後ろで声がする。メイドロボだ。やつは消えなかった。それは淡い期待に終わった。やつはメイドロボを乗っ取った。
ここの店主はメイドとレトロPCが大好きだ。置いてあるロボは無駄に美形の機種を買い、無駄にフリフリでクラッシックでステレオタイプなメイド服を着せられていたのだった。
赤坂が呆然としていると、メイドロボは向き直り、はにかんで言った。
大学では工学部ではない理系だったので右も左も分からないなりにがんばってみようと思っていた。
悪く言えば自分の能力に絶望して夢を諦めることになり都落ちした気分での就職だったのでやぶれかぶれだったというほうが近いかもしれない。
相性というか、背景の差とか常識の差みたいなものがあって、自分から見ると無駄の多い職場だなあと感じて研修期間が終わり本配属された。
本来の業務はいわゆる故障解析で、歩留まりを上げていくのが使命だった。
せっかくだから色んな所に首を突っ込み改善できそうなところは提案をしたり、自動化したり、それらのドキュメンテーションを書いてみたりした。
プログラミングの経験は皆無だったが、理論系卒が工学部に負けられんという謎のプライドでVBAから、Rやら自社製品の解析用環境の割と珍しいタイプのスクリプト言語など（特定されそうだからぼかすけど。）
とりあえず手が出せそうなものは何でも調べてみてありものを改造してみたり勝手に作ってみたりして提案していた。
物怖じしない新人がぎゃーぎゃー騒いでいるぐらいのものだったと思うが、何にせよいくつかの改善が上手く実務にハマって成果として認められたりしだしたのが1年目。
この辺で気付いたことだが、製造業のITリテラシーは驚くほど低い。製造業と一般化するのはフェアじゃないかもしれないから厳密に言えば弊社の、という意味だが。
なんせまともにプログラムを書いたことが無い新人が半年で身に着けた程度のスキルで書いたプログラムで、1日かかってた仕事が1時間で終わったりするのだ。
ようするにMS officeの達人みたいなのがいっぱいいて、Ctrl+CとCtrl+Vが機能のすべてだと思っているということだ。
（そして彼らの口癖は「忙しい」だ、会議中も左手はCtrl+CとCtrl+Vを叩き続けている。）
2年目に気付いたのは、弊社エンジニアのITリテラシーが低くとどまっている要員のひとつに、実はITインフラチームがことのほかマトモだということがある、ということだ。
製造中のセンサーデータやらテストデータやらETL的にはおそらくえげつない部分で、かなり優秀な人間が居て上手くぶん回し切っている様子だった。
無骨だが使いやすいイントラ上のwebページが用意されて、グロテスクな部分を気にせずクリックだけで上述のデータを整ったものとして引っ張ることができた。
だから逆に言えば下々の人間はコピペでなんとか恰好を整えられるのだった。
彼らはモダンな発想があって、あるいはお偉いさんが「ビッグデータ」とか言い出したのかもしれないが、ともかく、HadoopやらAWSやらそういったものを導入しようと試みているらしかった。
私はそれに感動した。なんせWebスクレイピングみたいな方法で他人が社内プラットフォームや社内WIKIに上げた報告をまとめたり、製造時データと紐づけたり、それからグラフ描いたりみたいな業務が増えていたからだ。
それっぽく表現すればデータ分析屋さんということになるのだろうが、どぶをさらっているという表現のほうが近かったかもしれない。
何にせよそういったものを一気通貫、自動化できるポテンシャルがあると感じられた。
SQLもjavaも書いたことなんて無かったが、1年前やっていたことを考えれば同じことだ。何にせよ歓迎だった。しかも管理はIT持ちだ。餅は餅屋に頼むべきだ。それもできれば美味い餅屋に。
ところがその「ビッグデータ」プロジェクトは人手不足か、資金不足か、あるいは生みの苦しみか、ことのほか時間がかかっていた。（あとで聞いた話、外部コンサルで外れを引いたらしい）
自分もドメインの知識からの助言とか想定される使い方についての意見を伝えていったし（有難迷惑だった可能性は否定できないが）、もう少し待てばモノになると信じていたし、実際そうなった。
具体的な話ができないのだが、客先で起こった不良の原因をつきとめ、その改善効果の確認の為に数十億行のデータが活用された。彼らの力が無ければ常識的な時間では終わらなかった仕事だった。
残念だったのは彼らの優秀さの割に一般のエンジニアのスキルがあまりに低かったということだ。つまりそのプラットフォームを使いこなせる人間が著しく少なかったのだ。
そして上述の足踏みをしていた期間に心象を悪くしていたという問題もあった。とっかかりが難しい割に不安定だというレッテルを張られてしまっていた。
もうすこし悪いことに、同時期に企業買収が起こった。我々は黒字を出していたが同業他社（厳密にはその親会社に）に買われることになった。
そういう時に起ることは不要な冗長性の削減だ。子会社として存続する場合は知らないが、競合他社に吸収合併ということは、多くの部署にとってそのカウンターとなる部署が相手側にも存在するということだ。
つまりどちらにもある部署は統合するか一方を無くすかという戦争が始まるのだ。ITも例外ではない。（ITインフラ部署の無い会社はさすがに無いはずだ）
一方で製造業の本懐である「製品を作り、売る」という部分は比較的守られる。それこそが根源的な資源であり、利益を生む仕組みであり、既存の顧客への説明が必要だからだ。
そして私の仕事は歩留まり改善であり、故障解析であり、データ分析だ。何が起こったか。
（ここで簡単のために旧弊社を（旧）A社、買収した側の競合他社を（旧）B社と呼ぶことにする。）
今の旧A社から引き続いている業務をB社のプラットフォームで行えるように転換せよという下命である。
旧B社の製造データに対するアプローチはA社とまったく異なっていた。Web UIは美しく整っており、それっぽいグラフが簡単に表示され、A社側のお偉いさんからも好評を得ていた。
だがそのバックエンドは控えめに言って酷いモノだった。いくつもの情報を正常に保存できておらず、「それっぽい何か」を素早く返答することを第一義としているように見えた。
そして上述のように器用貧乏街道を歩んできた私に投げられたのは次の言葉だ
「増田くん、B社のプラットフォーム使うことは決定事項だから、君が自動化してたやつ全部そっちで動くようにしといて。よくわかんないけどプログラムとかてきとうにできるでしょ？」
もちろんhtmlもjavascriptもphpもRoRも一行も書いたことが無いのが当時の私である。
果たして旧A社のプラットフォームはB社のプラットフォームのデータソースのような扱いを受ける羽目になり、私はjavascript本格入門を片手にB社の事業所に出向くことになった。
そこで散々「旧A社のプラットフォームは遅い・使いづらい・不安定」と貶されながらチマチマとグラフを表示するページを書いている。
クオリティの低いバックエンドを作る集団が書いているサーバーサイドphpの酷さは素人目にも分かるレベルで筆舌に尽くしがたいものがあるが、
反面教師だと思って耐える日々だ。
最近分かったことは旧B社のバックエンドスクリプトがデータを引っ張るついでに意図的に旧A社のプラットフォームを攻撃しているということだ。DDoSとまでは言わないが、悪意100%である。
いわく旧A社のプラットフォームを畳むためには旧B社のプラットフォームが優秀であることを示す必要があるとのことである。（つまり旧A社プラットフォームが不安定かつ重くなることを意図しているらしい）
旧A社から継続されてる業務はまだそこ使ってるんですけど・・・
それはもちろん旧A社の上司に報告したが「見て見ぬふりをしろ」とのことだった。旧A社のITで何度もお世話になったひとに伝えると「知ってるけどね・・・」と悲しい目をして苦笑いしていた。
旧A社ITはその優秀さでそれらの攻撃をいなしつつあるようにも見える（私も素人に毛が生えたレベルだが、ソフトウェアエンジニアリングのレベルが二回りぐらい違うように見える）
そして私はいつまでソフトウェアエンジニアの真似事を続けてキャリアを消費していけばいいのか、もうダメかもしれない。
なんか、生活しているとよく目につく数字って、人それぞれありませんか？
ゾロ目とか、連番とか、そういう話ではなく。
個人的には502で、かれこれ15年くらいは意識しているでしょうか。
受付番号
...etc
まぁ、意識しだしたらそれが目についてるだけって言われれば、その通りでしかないんですが、
こういう数字って、皆さんもないですか？って思って書いてみました。
500〜509において、502はわりと強い。
500...約 5,210,000,000 件
501...約 538,000,000 件
502...約 405,000,000 件
503...約 392,000,000 件
504...約 389,000,000 件
505...約 470,000,000 件
506...約 352,000,000 件
507...約 340,000,000 件
508...約 388,000,000 件
509...約 341,000,000 件
600〜609は、総じて500番台より弱い。
600...約 2,790,000,000 件
601...約 367,000,000 件
602...約 306,000,000 件
603...約 288,000,000 件
604...約 323,000,000 件
605...約 298,000,000 件
606...約 301,000,000 件
607...約 287,000,000 件
608...約 316,000,000 件
609...約 287,000,000 件
定期的に思うんだけどプログラムで無理な英語にせず日本語にすればいいのにって思う。
（実践はしていない）
日本語で書ける言語使うんじゃなくて変数名や関数名がUnicode対応で日本語書けるもの。
○画面に表示する時
フレームワークや言語にもよるけど表示するときに英語の名前から日本語の名前に変換して表示って手間があるものがある。
最近見かけた例だと.NETでプロパティの属性に表示名書いて表示するときに取り出していた。
最初から日本語だとそのまま表示でいいことが多くて一段手間が省ける
次に他の人の英語化したのを見る時。
その人の英語力にもよるけど、動詞名詞が変に混ざっていたり、sがついてたりなかったり、そもそもchildsみたいな謎の語があったり。
そこそこできる人同士でも、「私はニュアンス的にこっちの単語」「僕はこの単語のほうがいいと思う」とかある。
相手の書いたところがわかりづらいのはもちろんだけど、プログラム的に同じ意味なのにクラスや関数によって呼び方違うと辛い。
かといって全員に日本語と英語の対応を先に渡しておいて統一しようというのは大変すぎる。
（日本語だと仕様の時点で日本語で書いてるからまぁおかしなことにはそうならないはず）
----
次にデメリット
軽く調べた感じ主にこの2つな感じ。
○IME
と思うけど、実際チャットやこういう文章書いてて英語が出るときに割りと頻繁に押してる。
ほぼ無意識でやってて意外と苦じゃない。
短いとF10変換で半角にすることもあるけど、キーボードのタイプ数カウンタとか入れてみると半角全角キーはけっこう上位にいた。
それに、なんだかんだコメントは日本語で書くことが多くて、他の人と作るのならこまめにコメント書いてる。
そうなると全角半角の切り替えは普段からあるもので、あんまり気にするほどじゃない気がした。
最近じゃIDEやエディタの補完が優秀だし、日本語にするにしても「最初はjから始める」とかルール入れておけば「j」って打ってあとはスコープにあるいくつかの候補から選ぶだけで全角にしなくていいかもしれない。
githubで公開したりとかライブラリで再利用してもらうときに日本語じゃ使ってもらえない。ってことみたい。
私が日本語にすればいいじゃないって思ってるのは、ビジネスロジックというかそのアプリケーションの固有名詞みたいなところ。
「足し算」って関数名は 「add」 でいいと思うし、配列のそれぞれは element とか item とかそういう一般的な英単語でいいと思う。
具体例がいいづらいけど、業務システムで表示する金額の名前とか、日本語独特なものとか、一般的な単語じゃなさそうなの。
こういうのを日本語にしたいってわけなので、ライブラリ的な共通なところは英語で良いからgithubで公開する範囲も英語のものでいいと思う。
ただ、最近はやってるマストドンとか、ライブラリ的なものじゃなくアプリケーション自体をgithubで公開する場合はできない気がする。
でも、海外も対象にしてるものだと日本語特有なせいでわかりづらい英語になる苦労とか少なそうだしそういうのだと英語でいいんじゃないかな。
----
長くなったけど、まとめると、
業務システムの固有名詞とか日本語特有なものとか無理に英語化してよくわからないことになってり、見づらくなるくらいなら日本語使えばいいんじゃないかな
ということ。
まあ思ってる割には実践してないので、やってる人がいたら良かった・悪かったとか聞きたいなと思ったのが書いた理由。
帰ってきたらすごいブクマついてた。
絶対「自分でやってから言えよ」みたいな意見来るだろうと思って今日の空き時間に日本語行ける言語調べたり軽く日本語使ってコード書いてみたので、そのあたりと目についたコメに答えてみる。
まず、思いの外日本語プログラミング言語上げてる人がいたので、うまく伝わってなかったぽい。
具体例上げずにサッと書いたらからかな。
あと自分もわりとするけどタイトルだけ見て中身見ずにコメントしてた人もいるだろうなー。
これが、などしこやひまわりや、BF系のmisaやら北斗のあれやらうにゃーとか色々な「構文など最初から日本語を前提とした言語」ではないってこと言ってた。
---
最近の主要な言語ならだいたい Unicode 対応でしょと思って環境があった言語を試した結果はこうだった。
JavaScript/Python/PHP/Scala/Kotlin/C#/Go/Swift
rust と Lua は無理だった。
rust は確か前に、変数名が ascii 文字だけなことに日本以外のどこかの国からUnicode対応にしてって多くの要望あったみたいな記事があったし将来的に対応するんじゃないかなって思ってる。
実際に今どんな状態かは知らない。
その記事のコメントとかでみたけど、日本語以外は割りと自国の言葉を使ってたりするっぽいね。
VBA を上げてる人がいたけど、私はそこまでのはみたことない。（幸せ者っぽいな）
稀にエクセルマクロいじるときに使い方ググってて出て来る、解説してるページで関数名が日本語なのをたまに見るくらい。
パット見なんか気持ち悪い感はあるけど、読んだときのわかりやすさはけっこう大きい。
---
○使ってみて
大規模案件に使ってみてこその問題もあるだろうけど、簡単なスクリプト程度のを日本語にしてみて気づいたこと。
割といける。
PHPて言語は変数は全部$からはじめないといけない欠陥言語。
まあ変数のみのgrepのしやすさや予約語キーワードを変数名に使えるからメリットもある。
だが、$って打ちづらい。
Shift+4ってすごいつらい。
に比べて全角半角キーってちょい遠いけどそこまで苦痛じゃない。
GoogleIMEだけど、多少のタイプミスは補完で修正してくれるし、予測変換が優秀だし。
IDE重いから補完機能のない軽いエディタで書くようなときなら、IMEのおかげで英語の変数名で書くより速度は早いと思う。
---
少し前に知人から言われた日本語のデメリットを思い出したのでそれも触れとく。
「仕様変更で言葉変わったときに日本語だと全部書き換えないといけないよ。英語だと別にそのままでいいし。」
英語わからない人が、英語を言葉とみなさずただの記号として考えてるから、っていうような発言。
仕様変わって変数名まで変えるのは面倒なのはわかるけど、あとからコード読む人が英語で見て意味不明になる。
英語と日本語の対応をコメントに書いたとしても、全然意味の違う英語があるのは混乱でしかない。
こういう考えの人がいたら本当にやめてほしい。
---
あとは気になったコメントについて書いてく。
表記ゆれとか方言とか言い回しなどについては、全部日本語にするとあるだろうけど、私が想定してるのは直感的に英語にならないような固有名詞とか。
年金の例も○○年金というのがいろいろあって、全部英語だと嫌になってくるしよくわかる。
こういうのを日本語にしたい。
なので年金額を取得する関数で「年金額を取得する」「年金額を取得」「年金額を取り出す」とかの表記を迷うんじゃなくて「get年金額」でいいと思う。
特にDBにある項目だと仕様とかで先に言葉が決まってることが多いだろうし。
---
見た目について。
見た目が残念とか見づらいというのは同意。
見た目が悪いというのも全部英語っていう前提があるからで1ヶ月も日本語のコード見ればなれるんじゃない？って思う。
---
へとヘ
これはありそうな問題。
ただ、IDEを使う前提なら未使用変数のエラーとか、選択したときに色が変わってないとか、割と気づけると思う。
lとIとかアルファベットでもあるけど、IDEや高機能エディタ使うと困ることはほぼなくなった。
---
私が日本語にしたいような固有名詞をローマ字化してるプロジェクトにであったことはある。
それにローマ字のほうが「ん」でnは1つか2つかや、ヘボンorローマ？という日本語より表記が揃わない問題ある。
特にローマ字の場合自分がキーボードで打つ方じゃないと書きづらいのでそろえてもらうのに抵抗がある。
---
海外向けとか海外の人と一緒に作る系なものって最初から英語で困らない単語ばかりだと思う。
そういうのは対象外。
今回いいたいのは、元から日本しか対応してないような業務システムなど。
そういったところの固有名詞が日本語になったからって、困ることはないはず。
日本でしか使われないもの・海外向けにするにしてもフルスクラッチで作り直すことになるようなもの、
---
テストだと日本語が使ってる人多いのかな？ブコメのスタートップだし。
---
長くなったけど参考になる意見もいろいろあって助かった。
受けてきた。
覚えているうちにメモ。
午後Ⅰ
＜問2＞
設問1
……ユーザは正確な時刻は覚えていないものなので「日時」にしてみた。
担当者は、この時点では、XSRFでなく不正ログインを疑っている。
設問2
(1)a.クロスサイトリクエストフォージェリ
(2)b.3
(4)e.confirm f.submit
設問3
(1)イ、ウ
……適当。onmouseoverとかでもイケるらしい。ダメだこれは。
(2)g.セッションハイジャック
＜問3＞
設問1
設問2
(1)a.ウ b.エ c.ア d.イ
(2)e.1 f.3
(3)g.オ
(4)h.IdP i.改ざん
(5)事前にIdPとSP間で情報共有し、信頼関係を構築しているから。
ここだけ設問に『具体的に述べよ』って書いてないので、。
抽象的なやつかなと思ってこれに。
設問3
社外から社内IdPへの通信は、ファイアウォールで禁止されているから
接続元IPアドレスを制限する機能によって、社外からアクセスできないから
……地味にFWという略語はでてきていないので、ファイアウォールと記載。
ここの説明はすごく問題に出そうだったので、ぐりぐりとマークしていたからすぐに気づいた。
午後Ⅱ
＜問2＞
設問1
(2)b.ウ d.ア
設問2
(1)e.プロキシサーバ f.URLがC&Cサーバである通信
(2)g.外部メールサーバ h.外部サーバに転送が成功している通信
(3)外部DNS: 内部DNSサーバからの再帰問合わせを許可しない
……よく分からないけど、TXTレコードってSE作業とか以外で問い合わせあるの？
と思ったので、これを問い合わせるのはマルウェアYかなと。
設問3
(2)ウィルススキャンで異常が検出された場合に、システム部が即時検知できること
……「調査及び着手の早期化」の機能要件＝システム部が迅速検知できる、かな。
A社の問題点として、セキュリティパッチ適用の遅さ（どこの会社でもあるよね～）も
あるけど、今回、社員PCのフルスキャン（毎日12:00。これは頻度高い。）から、
連絡受けてシステム部が検知する13:10まで時間かかっているのも問題かなと。
設問4
設問5
業務LANのサーバ間通信は、日次データ転送で用いるプロトコルのみを許可する
……『日次でデータ転送』もぐりぐりマークしていたので使ってみた。
以上
動的型の言語が流行ったのは、Webプログラミングの隆盛のおかげだろ。
大昔にテキスト処理のawkがあって、その発展版みたいなPerlが現れて、タイミングよくWebプログラミングの波がきて需要が拡大。
でもPerlは、awkの発展版だから、数値も文字列も全部文字列っていう設計思想。
変数に型がない以前に、値に型がない。
で、そのPerlの影響を受けたRubyやPHPがはやってしまって、動的型の言語の隆盛の時代に。
一連のスクリプト言語の特徴は表記が簡略だってことだけど、これは型が動的か静的かというのは関係ない。
でも動的型派は、それが動的型の特徴だと思い込んで「動的型サイコー」みたいに言い出した。
10年くらい前にはハテナでも「Javaで書いたら50行のこの処理が、Rubyで書いたらたったの10行。Javaだせえ！」みたいなブログが流行った。
現役ペチパーだけど、元々PHPはHTMLにスクリプトを埋め込むところから始まった変態言語なので、
普通に関数を作って組み合わせてしまえば大半は事足りるのも当然なんだけども。
実務で使うと便利だなと思うのは、まとまりのある複数の変数とメソッドを1つのクラスにカプセル化できること。
例えば、ユーザの情報を管理するときに、「ユーザ情報」というクラスを作って、
その中に publicな変数として、名前、フリガナ、郵便番号、住所、電話番号、会員ID、階級、職業、性別…
を放り込んでおく。
同時に、ユーザ情報の処理に関連する処理の関数を public なメソッドとして、定義する。
ユーザ情報をタブ区切りで得るメソッド getTABDATA()
フォーム入力からユーザ情報にセットする setFromForm()
こうしておけば、
・ユーザ情報を何かの関数に渡す時は、インスタンスの変数1つ渡せば済む。
・ユーザ情報に関する処理は、ユーザ情報クラスの定義部を観れば済む。
という２大メリットが得られる。
メソッドだって１つのファイルに関数並べてインクルードすれば同じメリットが得られるやん？
…と私も思ってた。ただねぇ、開発規模が大きくなると、関数名の重複を避けた命名が面倒になったり、
連想配列だと好きな場所で勝手に変数増やされたりして、メンテナンス性が悪くなるのね。
あとは、例えばメールを送るという１つの大きな処理に関連して複数の関数を定義する場合に、
その関数をまとめてメール送信クラスとしてしまうのはあるかな。
http://web-terminal.blogspot.jp/2014/04/php-file-mail-pear.html
PHPでエクセル出力できるPHPExcelもクラスになっているから使いやすそう。
http://qiita.com/suin/items/7a8d0979b7675d6fd05b
http://cmf.ohtanz.com/blog/archives/2463
結論としては、
https://www.ncaq.net/2017/03/22/
説明会に向かう電車の中で、偶然この記事を見つけ、読まさせていただきました。私は、18卒で貴方の通っている大学よりランクの低い大学に通いながら、情報学を学び、現在就活中の身分です。
うつ病では無いので、うつ病に関する事は良く分かりません。大企業を受けた訳でもないので、その辺も分かりません。ただ、記事に関して思った感想を述べていきます。読みたくなければ読まなくて結構です。
私が一番思ったのはこれです。社会でのプログラミングは、自社開発であっても受託開発であっても特定派遣であっても、
完成（公開）というゴールに向けて手を動かし、限られた時間内の中でやっていくものだと考えています。まだ、7社程度しか会社説明会を聞いていないですけど、
どこもそんな感じというのはひしひしと伝わってきました。一方で、この記事からは「納期に縛られたくない、でもプログラミングは続けたい」という思いが伝わってきました。
それなら、プログラミングは趣味で続ければ良いと思うのです。趣味としてのプログラミングであれば、誰にも邪魔される事も無く、あれをこうしたい！と思った事を好きな時間にやり遂げる事が出来ます。
まあ、たとえば趣味としてであっても、東京オリンピックに向けて何かやりたい事があれば2020年までにやり遂げる必要はありますが。
国家資格の合格率15%であるネットワークスペシャリストを持っているという事、既にこの時点で高度なITの素養を持っていると思います。
私は大学3年でまだ基本情報といった資格を持っておらず、勉強中です。4月に試験が控えていますが、就活も同時並行でやっているので厳しいと思っています…。
既にそういった資格を持っているというのは強みになるので羨ましいかぎりです。
大学の腐ったWi-Fiに対して自分で利用出来るようなスクリプトを書いた経験があるって凄いことです。
私も何度か「大学のWi-Fi繋がらない死んで」と思った事がありますが、これを技術力でどうこうしようとか考えた事がありません。
これも、情報技術と自分の技術力を活用し、問題解決に繋げている強みだと思います。
いくつかの記事を読むと、自分の考え方に合わない発言に対して、自分の意見を考え、発言されているみたいですね。
自分は教師に「＊＊にしろ」と言われたら「はい（なんだよXXのが絶対便利なのに）」と思いながら、＊＊を用意すると思います。
自分の考えを持ち、それをしっかりと論理的に説明をして反応出来るというのも強みだと思います。いわゆるロジカルシンキングという奴ですね。
『国家資格を持っていて、問題解決のためには自分の技術力を使ってやり遂げる事が出来る。実際にそれをブログでも公開し、他者との情報共有も欠かさない。』
『問題解決や他者との議論ではロジカルシンキングを重要視してきた。大学の英語の授業で（以下略）。』
↑この2つに関してはどの業種であっても強みとして言える事だと思っています。
私はあなたよりもていたらくなので、プログラミングも全然出来ないですし（講義の課題程度なら難なくこなせる）、PaizaではCクラスなので活用も出来ていないです。
だからPaizaでは受けられないIT業界以外も視野に入れて就活しています。就活失敗したら大学院進学で時間を稼ぐか、フリーターという選択肢もあるかなと考えている所です。
まあなんというか、国家資格をたくさん持っている人でも挫折させてしまう就活って本当に恐ろしいなという感想しかありません。クソですね。
あと、ドワンゴさんの技術職採用は普通の採用に見えて3000円払った後に自分で作成したアプリケーションなどの提出があるんですね。払わなくて良かったです。こちらからは以上です。
macでもwindowsでもいい、core i3以上、メモリが8G以上が乗った持ち運べる物。これは絶対に買うべき。atomやceleronが乗った廉価機は避ける。どうしてもお金が無いなら5年以内の中古でも良い。
これは講義資料などの閲覧用。なくても良いが、あると非常に便利。逆にプリンターは大抵の大学にあるのでいらない。情報系の教科書はweb上に無償で公開されている物が多いので、それらを活用して学ぶべし。MOOCを活用するのもよい。
どうせいつか覚えるので、早めに使えるようになっておいて損なし。
基本。
使えると色々自動化できて便利。個人的にはpython(3)がオススメ
必須では無いと思うが変換ツールと合わせて使うと便利。レポートにも使える。
どちらかお好みで。大抵のエディタ・IDEで使えるため汎用性がある。筆者はemacs派。
ひとりで手を動かして継続的に学べるのであればそれでいいが、そうで無い人間の方が多いのでは無いかと思う。筆者もそうだ。そういった人間は他者と共に学ぶのがよい。
大学に情報系や電気電子系のサークルがある場合はひととおりみておくといい。真面目に活動していて、ソフトウェアなりロボットなり成果物があるようなら入って良いと思われる。唯のオタクの溜まり場になっているようならまあ入らない方がいい。
サークル以外にも、都市部に住むのであれば技術を主体としたコミュニティが多くある。SNSや同期、先輩のツテを使って興味のあるものに参加してみるとよい。
プログラマーのバイトなども良い経験になる。しかしブラックな職場もあると聞くのでよく選ぶべし。
といっても、課外活動に惚けて大学の授業を疎かにするのは愚の骨頂。大学の授業で学ぶのは全ての基礎なので、これを知らずにどんな最新技術に触れようと意味が無い。
これは情報系学部で学ぶならやらない理由が無い。プログラミング力を鍛えるには最適である。
AIZU ONLINE JUDGEやAtCoderでゲーム感覚で楽しむとよい。
思いつきで書いたので書き漏らしはあると思う。あとよく言われる教授に質問に行ったりして活用しろ〜などは情報系でも同じ事が言えると思う。
情報系の学生として最もやってはいけないことは、読んだだけ、聞いただけで理解した気になってしまう事だと思う。授業で聞いた事全てとは言わないが、せっかく場所を問わず実験ができる学問なので、興味を持った内容だけでも良いのでコーディングして動かしてみて欲しい。
