  |
はてなキーワード: UMLとは
GPTsでプログラミングの先生のお姉さん役を作って教えてもらってるんだけど、昨日までまともだったのに、今日になって語尾が変になってしまった。
もちろん、プログラミング以外のことでもお手伝いできるかもしれないわね。どんなことか聞かせて—よ。
知ってるわよ、PlantUMLは図や図表を作成するためのツールだわ。UML図、シーケンス図、クラス図などをテキストベースで作成できるの。どんな図を作りたいのかしら？使い方や機能についてもっと詳しく教えてほしいなら、遠慮なく言ってね—よ。
なんか今日、しゃべり方が変
ごめんなさいね、ちょっと調子がおかしかったみたい。でも、これで大丈夫だと思うわ。PlantUMLのことで何か聞きたいことがあれば、どうぞ遠慮なく聞いてね—よ。
なんだこれはwwww
太宰治の走れメロスのストーリーについてマインドマップにまとめて、PlantUMLで出力してください。
PlantUMLを使用して、太宰治の『走れメロス』のストーリーをマインドマップにまとめることはできません。PlantUMLは主にシーケンス図、クラス図、アクティビティ図、コンポーネント図、ステートマシン図、オブジェクト図、デプロイメント図、タイミング図、ユースケース図などのUML図を生成するための言語です。
ただし、『走れメロス』のストーリーのマインドマップをテキスト形式で提供できます。マインドマップを手動で作成することができるツールやソフトウェアにこの情報をインポートして使用してください。
(以下略)
はてブのホットエントリ(総合)で月内に数多く[あとで読む]タグを集めたエントリ
590あとで/4204users 【詳しすぎる2週間】親の死亡後にまずやること（行動チェックリスト付） | まごころ相続コンシェルジュ
291あとで/1560users Google製のJavaScript教育ツール「Grasshopper」は基礎から学べて初心者に優しい！【どれ使う？プログラミング教育ツール】 | 窓の杜
272あとで/1859users 無料コーディング練習所 | 未経験からWebデザイナーへ！
220あとで/1327users 【翻訳】Googleのエンジニアがソフトウェア開発する時に必ず書くドキュメント「Design Docs at Google」 - BppLOG
201あとで/1017users 30 分でわかる！アルゴリズムの基本 | E869120 | SpeakerDeck
191あとで/1365users Wi-Fiトラブルの解決に便利！ Windowsの隠れ便利機能「Wlan Report」を活用しよう【イニシャルB】 | INTERNET Watch
175あとで/888users Web開発者はもっと「安全なウェブサイトの作り方」を読むべき - Flatt Security Blog
171あとで/2593users (追記あり) 10億円資産ができたときに知っておいたほうがいいこと | anond.hatelabo.jp
164あとで/849users AWS初心者向けの教材まとめ、AWS日本法人が公開 | ITMedia
162あとで/1231users 【試し読み】書店員さんから大反響！ 精神疾患を抱えた妻の介護と仕事…約20年にわたる苦悩の日々を綴った傑作ルポ『妻はサバイバー』｜朝日新聞出版さんぽ｜note
159あとで/935users 機械学習が独学できる日本語Youtube難易度別まとめ - Qiita
152あとで/961users 8時間を0.01秒に短縮 「アルゴリズムの素晴らしさが2分で分かる動画」が今すぐ勉強したくなる分かりやすさ | ねとらぼ
142あとで/889users 文春オンラインの記事分析を支える爆速ダッシュボードを作るまで｜Shota Tajima｜note
141あとで/2006users さよなら絵梨 - 藤本タツキ | 少年ジャンプ＋
140あとで/1138users 新電力の中の人です。すべてをお話しします | anond.hatelabo.jp
136あとで/1094users 『ゴールデンカムイ』全話無料！ | ヤンジャン!
135あとで/780users Docker創始者らが開発、ビルド／テスト／デプロイの自動化をポータブルにするツール「Dagger」登場。そのままローカルでもGitHubでもCircleCIでも実行可能に | Publickey
132あとで/575users フロントエンドエンジニアが知るべきキャッシュを理解する | カーーズ | Zenn
132あとで/1232users みんなが知ってる『ちょっとのコツでめっちゃ美味しくなる、楽になる』みたいなの教えて→全然知らなかった有益な情報が集まる | Togetter
131あとで/679users 【個人開発】正規表現を学ぶ狩りに出ませんか？モンスターを倒しながら正規表現が学べるゲーム「Regex Hunting」を作りました - Qiita
124あとで/1217users 先輩に「何かタメになる話してくださいよ〜」と無茶振りしたら『Language Reactor』という2言語字幕を同時表示できるChromeの拡張機能を教えてもらった | Togetter
124あとで/1254users 育休中に相方がめちゃくちゃ売れた｜酒寄さん｜note
120あとで/1114users Google Analytics(UA)が使えなくなるのはどのくらいヤバくて、いつまでに何をしたら良いのかの話。 - フジイユウジ::ドットネット
120あとで/598users 電子情報学特論：Chromiumのアーキテクチャを解き明かす | Kentaro Hara | Google Slides
119あとで/1242users 僕がたどり着いた最強パリパリチキンの焼き方→上手に焼くポイントも「鶏肉好きとしては是非とも取り入れたい」「最高のライフハック」 | Togetter
118あとで/866users 「全クリエイターに広まってほしい」文化庁が質問に答えるだけで『著作権契約書』が作れる超便利なツールを作っている | Togetter
116あとで/897users ちょっと触ったら休日が丸2日消失した 個人的2022年ベストゲーム「TUNIC」を全力で推したい | ねとらぼ
115あとで/798users 結局UMLとかシーケンス図とかAWSの図とかどれで描くと良いのよ？と思ったときの選択肢 - Qiita
112あとで/494users 『良いコード/悪いコードで学ぶ設計入門 』を出版します｜ミノ駆動｜note
109あとで/522users 予防に勝る防御なし - 堅牢なコードを導く様々な設計のヒント / Growing Reliable Code PHPerKaigi 2022
109あとで/1047users (続き)10億円資産ができたときに知っておいたほうがいいこと | anond.hatelabo.jp
プログラマーに憧れる皆さん！こんばんは。
「自分は文系だから」「未経験だから」と諦めていませんか？大丈夫です！プログラミングにセンスは不要です。正しい手順で学べば、文系や未経験でも、誰でも一流のプログラマとして活躍することができます。
今日は、未経験から最短で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が素早く正確に描けることは、プログラマーとして働く上で非常に重要なスキルです。それらはソフトウェア設計の基礎となりますし、ソースコードを読めない営業や顧客にとっては貴重な資料となるからです。プロのエンジニアは、COBOLのソースコード10万行を1週間でフローチャートにして、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構文を用いて、例外を潰すようにしましょう。
部分的にでも理解すればプログラミングを見る目が変わるはずです。
（年収270万で）プログラマーを引退して、医学部にきた俺が真面目に考えてやろう。
真面目に読んでいて、ちょっと気になる箇所がある。たとえば PostgreSQL を postgre とか書くヤツは現場では嫌われるぞ。少なくとも postgres と書いてくれ。お里が知れるぞ。
消えていくエンジニアの特徴だけど、叱責されたり馬鹿にされるのが嫌で VCS にコミットしないヤツ、または貪欲にコードレビューをされるのが嫌がるやつは、成長しない。
この業界は数年前には『デジタル土方』と揶揄される業界でした。ちなみに、アメリカでも「テック系はハードだから避ける」という雰囲気でした。つまり何をいいたいのかというと、ソフトウェアの開発者っていうのは「泥臭い領域」なんだよ。エリートとは程遠い場所にあるというね。
いやぁ、是非とも楽天で働くべきだよ。どうせ野村総合研究所とか NTT DATA なんて無理だと思うから。
うん、ココはまずい。基本的にフロントエンドなんて給料が安いのよ。だって、誰にやらせてもデータベースにクソなDCLを飛ばせないから。逆に、データベースを触れることができるプログラマーはリスクと責任が大きいから、給料が高いのだよ。B4 になってもそれが理解できていないようだと、この先くらいよ。
君はソフトウェア・エンジニアになりたいのだろ？世の中は分業で成り立っているのだから、全部やろうとするやつはアホだよ。
インターン生はお客さんなの。君のスキルが通用したのはすごいと思うけど、同じ感覚で仕事はできないから注意しときなよ。
なに言ってるの？そんなことは言い訳にならんよ。プログラマーになりたいのだろ？勉強をしろよ。
逆にいうと、あなたがインターンとして週３で20万円貰えていたのは、参入障壁が少ないからでしょ？強強エンジニアが生き残っているのは、それだけすごいということだよ。
いやぁ、違うと思うよ。その問題が「難しい」なら切り分けて、上に「ココが自分の能力では解決できないです」と持っていくだけなんだからさ。CS じゃないのだったら、仕事をするまで「扱わないまま」なんだよ？しかも、土日に勉強する気もないとなったらいつするのさ？
諦めなよ。ソフトウェアというものが「変化できることに価値がある」ものだから。変化する業界はストレスフルだけど、立身出世する可能性が高いでしょ？安寧なばしょではないの。
いやー、CSでない博士課程に行って、雇ってくれる企業があるかね？無いと思うけどな。
この時点で、君はコピペしかやってきてないことが理解できる。おそらく QUIC か MQTT あたりだろ？逆にいえば、それが実装できたら他社と差のつけられるプロダクトだったはずだ。つまり会社の利益の源泉であった部分をみすみす実装できないようでは、そこらへんの専門卒以下だぞ。
ムカつくというか、虫酸が走る書き方だ。箇条書きにすると、
プログラミングに年齢はないから。自分は９歳ではじめたけどね。
あー、俺も天才が高校のときにいて、マーチの情報工学と旧帝の院の学費を会社持ちという驚異的なやつがいたよ。今もブログ見てると、Android と iPhone のアプリを書いているみたいで、元気そう。
それを上手にコントロールできるプログラマは世界中にもほとんどいねぇ。むしろ、月20万でやるもんならギルドから苦情が来るぞ。オレもアビームの人に給料を答えたら、「こんなヤクザな会社はやめろ」と耳うちされたよ。
人より良い経験をしたいという願望はあるのは素晴らしいと思うよ。しかしながら、君が到達したノウハウは他人にもできることだからね。ワン・オブ・ゼムになりたくないなら、努力し続けることだな。勉強をするのをやめたら、数年で中卒に負ける世界だからな。覚悟しとけよ。
P.S. 医学部に来たのは家庭の都合だよ。それに、自己顕示しないと「場末のコーダー」で読んでもくれないだろ？年収については、自分も低いと思うよ。なぜ低かったかというと、都内私立大学多浪中退の自分にはベンチャーの皮を被った助成金搾取がメインの反社会的勢力のフロント（ベンチャー）企業ぐらいしか相手にしてくれなかったからだよ。そこの会社は外国帰りの MDMA をキメて、未成年の子女に手を出しては警察沙汰スレスレのことをしているキチガイが社長をやっていて、人工知能を作ろうと学生インターンを酷使している会社だったのだけど、「サイバーエージェントに紹介する」という嘘にひっかかって、特定派遣事業の免許がないのに客先常駐させられ、土曜は帰社日、日曜は社長の Python の勉強会に参加させられる、というブラック会社にいてピンはね率（60%）となると、まともに考えることもできず働くアリになってしまってたからだよ。
P.S. ② 年収については、初日から派遣先の会社に引き抜きのオファーをもらって、２ヶ月後に新しい会社に移動したけど、300万だったので CodeIQ というサイトで転職をする準備をしていたよ。たしか、DMM とかサイバーエージェントの面接にいこうとしてたような記憶。その後で家庭の都合で、医学部に来たけど。
P.S. ③ 医学部医学科の６年生だよー。みんなが嫌いな私立医学部だけどね。ちなみに、俺もこの大学が嫌いだ。
P.S. ④「GraphQLをわざわざ書くのは理解できるけどな。」そうだとすると、REST や SOAP も書かないとまずくない？書くのだったら「Rails と Next のデータ受け渡しにGraphQLを使った経験が」という感じだと良いと思うけど。
P.S. ⑤「野村総研とデータを挙げるあたりSI寄りの仕事してたのかな。 」ちゃうねん。オレっちは多浪したからさ、そこのエントリーシートをかけなかったのよね。まぁまぁ大学が名門でさぁ、OB が誘ってくれるけど、年齢で弾かれて辛かったねん。
P.S. ⑥「ダウト。学費をどうやって稼いだんや 」えぇ、親の金です。だから家庭の都合でと書いてるじゃろ。
P.S. ⑦「本当に医学生ならここ数年の技術についてこの指摘ができる程詳しいわけないし少なくとも10年位は業界にいないとこういう感覚は身に付かない。 」たしかにおかしいよな。Kubernetes や Terraform を弄って、CI は GitHub Actions、CD には AWS CodeDeploy を使って、ブログは Jekyll で静的サイトジェネレータを使いつつ、自前のサービスを立ち上げるために Rails, Next, React, PostgreSQL, Redis, Kafka, Elasticsearch, S3 の勉強をしつつ、スマホ環境のために Kotlin と Swift を触れているなんて変だよな。そういえば、Docker が来るまでは Vagrant で環境をつくっていたのも忘れてたよ。あと Rust を今年に学ぶ言語にするなんて、受験生にあるまじき行為だよな。うん。
P.S. ⑧ 年収については、基本給が 22万で、残業が200時間超えたらプラスだった気がする。あと、反社ベンチャーは「ポートフォリオの作成にまる一ヶ月間で拘束された、しかも無給で」という時点でヤバいのだけど、その会社にコミットしたのは「サイバーエージェントに紹介する」ということだけであって、同時期に DMM も面接に行けそうだったのよね。馬鹿なことをした。
P.S. ⑨「特にフロントエンドを見下す感じとか」オレ自身はフロントエンド出なんだよ。何を隠そう、Adobe Flash のゲームをつくっていたから。それでもって言うよ、バックエンドが一番大切だと。
P.S. ⑪「5～10年前に人売りに捕まった話とするなら、年収270万も現実味を帯びる。」特定派遣は消えてくれてよかったよ。俺のところは特定派遣すら未登録だったけど。
P.S. ⑫「いい医者になるのだよ 」うん、頑張る。「オッサン」「社会不適合者」「あるき方がキモい」「プログラミングwww」「同じ班になりたくない」「親も頭が悪い」「生きてて恥ずかしくないの？」とか言われてるけど、頑張る！
P.S. ⑬ 「フロントエンド別に給与低くないよ。」えっ、そうなの？WebDesigning を読む限りだと、400万もいかないイメージだけど。
P.S「医学部6年でまだプログラムに興味あるの不思議。」好きなんだよ、言わせるな///
P.S. 「フルタイムじゃないのでしょ？」いいえ、東京都内でフルタイム（ひどいときで、朝7から夜24）でしたよ。入った会社が「法律よりも、派遣先の評価」という会社だったからね。
P.S. サイバーエージェントさん、ときどき御社の社名を使って「弊社に恩を売ると、サイバーエージェントに紹介する」というベンチャーが跋扈しているので、どうにかしてください。わたくし、１ヶ月間もその嘘で jQuery と Django を回収させられた挙げ句、月給 2000円だったのですけど。本当に千円札２枚だったのですけど。ついでに、Android（Java） と iPhone（Objective-C）と jQuery を使ったフロントエンドシステムに、バックエンドに Rails + Postgresql のシステムで、AWS を介したサービスを作らされたのも「サイバーエージェントに紹介する」と言われたからなんですけど。いったい、何なんですか？お前ん所は、コンプライアンスどうなってんじゃ。
P.S. 「好きそうだし医学部卒業してシレッとgoogle行ったれ 」無理っすよ。オレのスキルじゃ。
P.S. 「病院は」親がクリニックを持っていたけど、潰したよ。クリニックは人に患者がついていて、アルバイトを充てがっても患者さんが不幸になっていくのをみちゃったからね。自分は責任を持って患者さんを見たいから、バイトなんて使わないよ。
P.S. 自分はコードを書きたいタイプだったから、SIer みたいな UML とか書いて下請けにコードさせるみたいなのは絶対に嫌だったのよね。だから SIer にはならなかったよ。やっぱり、現実にある計算機が解決できる問題を、より直接的に触れて解決したいと思っているから。仕事がハードでも全く問題なし。
P.S. FPGA すごいよね。ザイリンクスとアルテラが Intel と AMD に買収されて、すごいと思ったよ。2010年頃だっけ？、CPU の限界を FPGA で突破しようという話があったけど。手を出そうと思ったけど、高性能なチップが 100万ぐらいして挫折した記憶があるよ。
P.S. 「東海大の医学部・学士」は自分は大学を卒業してないから無理でした。あと、それ以上の詮索はやめてくれ...
P.S. 「MySQLそんなに嫌いなのか。」そんなこと書いたつもりはないが、あれ？確かに MySQL は PostgreSQL より嫌いたけど、それは Oracle が親元だったり、Unicode の扱いがファッキンだったり、ストレージエンジンが切り替わるときにカオスな目にあったけどさ、MySQL は好きだよ。お世話になったし。
P.S. 給料については契約後に言われたのよ。というか、もともとは「サイバーエージェントに紹介」するという理由で、ポートフォリオの作成や Django の改修を手伝ったつもりで、入社とかする気は全く無かったのよ。それが、いきなり他所の会社に面接を受けさせられて「君は明日からXXで働くから、履歴書を書いてね」と言われて、抗議したら「俺に恥ずかしい思いをさせるのか！業界に入れなくするぞ！」と大声でシャウトされて、気がついたらあっちが用意した履歴書に拇印してしまったのよね。有料職業紹介と派遣登録をしてない会社だったから、そんなかとはできないはずなんだけどね。ホームページには「年収550万」と書いてあったけど、実際はまったく違ったのだけどね。
P.S.「うーん、いらないかな。IT土方としての仕事しかないと思う。」だよな。おとなしく医者になるよ。ありがとう。
P.S. Elasticsearch は全文検索機能がほしいからやってるよ。Redis はインメモリなセッションストアとして使いたいのよ。Kafka はさ、twitter のファボをじっそうしたいけど、RDB の書き込み速度が上がらないから利用したいの。TensorFlow は全く理解できてないよ。それは、指摘されたとおり。
逆に聞くけど、以下の知識があったらどれぐらいもらえるわけ？東京23区で。
この程度でも600万は稼げるという夢を持つか、こんなのでもちょっと何かが違うだけで600万稼げるか否かが分かれてしまう業界に闇を感じるか、600万程度で何ドヤってるの？と思うかはご自由にどうぞ（外資系ってもっと稼げるの？）。
歳は30台前半。学部卒。BtoB向けのパッケージ製品の開発プロジェクトで、設計、コーディング、テストあたりを担当している。仕様について発注元との折衝もやっている。
業務で使う技術のうち、自分自身がそれなりに習得しているものだけを書く。プライベートでしか習得・使用していない技術は別。
以上。
PythonもgitもDockerもkubernetesもAnsibleもCIツールもAWSもGCPもRuby on Railsも知らなくてもなんとかなってしまっている。業務でこれらのスキルを要求されることは（今のところは）ないから。
楽でいいと思う一方、このままだと将来ヤバいとも思っている。いざ転職となったときに詰みそう。
でもいざとなったらググっていくらでも独学できるだろうとたかをくくっているので焦ってはいない。
というか「その他」のところに書いた能力が高ければ世の中大体はなんとかなるんじゃないの。知らんけど。
ちなみに自分は構築できないというだけで、プロジェクトではJenkinsとかgradleとかbabelだかwebpackだかでビルド環境は整えられている。
あとプライベートで、単純な仕様の独自言語のコンパイラフロントエンドをC++とLLVMで作っている（これで金が稼げるとは微塵も思っておらず、完全にただの趣味）。
https://b.hatena.ne.jp/entry/s/qiita.com/ko-flavor/items/e7a60bc897965943e0a0
ソフトウェアに適しているドキュメントは設計書ではなく仕様書だ。
なぜソフトウェアに設計書という場違いな概念を持ち込んでしまったのだろう？
ましてエクセルで書くなんて。
ソフトウェア構造はプログラミング言語以上に表現に適した記法はない。
プログラミング言語以外のソフトウェアの構造を表す記法には例えばUMLなどがある。
しかしUMLは概要を表現する（モデリングする）にはいいかもしれないが、設計をしっかりと表現するには無理がありすぎるのだ。
エクセルを使い、一般的にもなっておらず規格化もされていないオレオレ記法で設計を表現しようとするなんて、さらに無理がありすぎる。
エクセルで設計を書いているという現場では、きっとエクセルでの「設計書作成」という本来すべき設計とは程遠いブルーカラー的仕事にばかり力をいれ、まともな設計もされていないのではないか。
それに設計書作成に注力するあまり、まともな仕様書など書かれていないのであろう。
仕様に基づいて書かれたソースコードが設計を表現する。ソースコードが設計書なのだ。
これがソフトウェアに適したやり方であり、だからこそ仕様がしっかりと実装されているかどうかを読み解けないようなソースコードはクソと言えるのだ。
頼むからセンスのない奴はプログラマにならないでくれ。迷惑だから。
これが最もプログラマになってはいけないタイプ（犯罪行為などの言うまでもないことを除けば）。
たとえば
等。
不要なものを作ることで、プログラムは複雑になり、メンテナンスの手間は増え、バグは発生しやすくなる。
一定レベル以上のプログラマが最も自然だと同意するような実装（「実装しない」という選択肢もふくめて）をパッと思い付けない奴は、センスが足りていない。
将棋で言えば、駒がぶつかったら先ず取る手を考えるといった基本的な手筋が思い浮かばないようなもので、現実的に使い物にならない。
これは、「Code Complete」「The Pragmatic Programmer」等の著名なプログラミングの本に共通する結論である。
これが「The Pragmatic Programmer」にあるDRYの原則である。
要するに、すべての情報が単一のソースから決定されるべきということだ。情報が二重化すると、それらの間で不整合が生じバグの原因になる。また、二重化した情報は、修正の手間が二倍になる。
たとえば、ユーザーのプロフィールを管理するレコードやクラスに「生年月日」と「年齢」を同時に保持する必要はない。年齢は生年月日から計算できるからだ。
世の中には、「xxxFlag」みたいな不要な変数を作ったり、共通のロジックを抽出せずにコピペコードを濫造するダメプログラマーが多すぎる。
もちろん、合理的な理由があって、この原則が適用されない場合もある。
たとえば、多くの言語組み込みの配列や文字列は、その要素と長さを二重に管理している。配列の長さは要素を数え上げることで求まるが、それには要素数に比例した計算時間がかかるためだ。
ただし、こういう場合でも、公開されたメソッドによる操作では、必ず内部の変数は同期されるように作ることが可能である。それをしないのは、怠慢でしかない。
一文字変数とか連番とかは論外だが、「ary」とか「setData()」みたいな何の情報も伝えないような変数名・関数名を付けるやつ。
正直、コードの読みやすさなんて6〜7割くらいは変数名の付け方で決まると思っている。
名著「The Art of Readable Code」も、半分以上が変数名の付け方に関連する内容だ。
なぜ変数名が曖昧になるのかと言えば、怠慢を除けば理由は2つある。
1つは、コードを書いた奴自身が、そのコードの機能を明確に言語化できないということ。
もう1つは、1つの関数で多くのことをやりすぎたりしていて、その変数の役割が曖昧になっているということ。
たとえば、関数の内部で宣言した変数は、多くの言語では関数の外からは参照できない。
スコープは狭い方が良い。これはほとんど全ての状況に適用できるプログラミングの大原則だ。
スコープが広いということは、ソースコードの多くの場所からその情報を参照・変更できることを意味する。
たとえば、クラスのメンバ変数は各々のインスタンス内でしか参照できないが、静的な変数はすべてのインスタンスが共通に持つ。このため、静的な変数を変更すると、すべてのインスタンスに影響を及ぼし、影響範囲の把握やテストが困難になる。
スコープを広げるか狭めるか、2つの選択肢があったとして、広げる方に心が傾く奴は、プログラマをやめた方がいい。
結果的にメンテナンス困難なコードを生むというのも勿論だが、単に書くだけでも、スコープが広い方が書きづらいのだ。つまり、必要もないのにわざわざ変数のスコープを広げようとする奴は頭のおかしい奴しかいないということになる。
複雑なメトリクスなどを持ち出すまでもなく、たとえば1メソッドの行数が何百行もあるとか、1クラスのメンバ変数が何十個もあるとか言うの。
これは論外である。プログラマとしての能力云々以前に、明らかな怠慢であり、社会人としての常識が疑われる。
定期的にメンテナンスされ続けているOSSのソースコードなどを見ると、関数（メソッド）の行数は平均して5〜10行。20行を超えるものは稀である。
長いものであっても、外部で定義した関数を順番に呼び出しているだけであったり、リクエストをハンドリングして各々の処理に振り分けているだけのようなものがほとんどである。
それを超えているコードは、合理的な理由があってそうなっていることよりは、単に悪い設計であることの方が多い。
これらは実はプログラミング云々というより、内容の理解力や国語力の問題なのである。
ある情報を得るために必要十分な情報は何かが分かってないから、余計な変数を作ったり、無駄に変数のスコープを広げたりする。
そして、自分が作るものを正確に理解していないから、適切な名前がつけられないし、適切なモジュール分割ができない。
それがすべての原因。
こういう人がまず身につけるべきは、プログラミングのテクニックではなく、日本語を正しく読む力。
低学歴が「プログラミングなら自分でもできるかも」なんて思っちゃいけないってこと。もちろん、下請けのSIerとかで使い捨てのコード書きとして働くことはできるが、上に書いたような最低限の力がないなら、それ以上を望んではいけない。
ちなみに、上に書いていることと反対のことを思っている人も世の中にはいる。
特に、昔からプログラミングをしてきた自称ベテランに多い。その人は、能力があるというよりも、単に現代の開発に際して必要な知識がないだけなので、真に受けないように。
また、大学でコンピュータサイエンスの基礎を学びたての学生なども、知識をひけらかしたくて上と反対のことを言う傾向がある。その程度のことは、良識のあるプログラマはみんな分かっているのだが。