  |
はてなキーワード: 例外処理とは
横からだけど、｢エアプ！｣｢エアプじゃない！｣の言い争いやってて虚しくならんの？
おれも囲碁はつまなそうだと思うが、｢例外処理があるとクソゲー」は正直よくわからん
具体的にどんなの？
なんかの機能追加というタスクがあるとまずタスクを分割してTODOアプリに登録する
こんな感じ。できる限り1タスク1～5分くらいで終わる量に分割する
1メソッドが大きい場合は例外処理のみ、DB登録部分のみ、メール送信部分のみとかそれだけでもタスクを分ける。
30秒で終わるようなことでもタスクとして独立してたら分けて登録する
「30分あれば上から12個こなせるな」とか見積もりして該当タスクに印をつけて30分タイマーで都度タイムアタックする
タイムアタックが終わると5分ほど休憩。見積もってた分が30分より早く終わってもその時点で休憩。5分くらい？
Youtube見たり在宅だったらえっちぃビデオ見たり音楽聞いたり好きなことをする。
終わったらまた30分分のタスクを見繕ってタイムアタック。それの繰り返し
ちなみにSlackで問い合わせとか来た場合はその時点で返信より前にTODOとして登録。何故ならそうしないと絶対返信忘れるから。
・ASU2016-01に則っての処理が要求されるわけだが、この規定、有害であり、情報価値を著しく損なう悪規定である。
・従来、市場性のない持分証券への投資は、取得原価での測定が原則であった（公正価値オプションはあったが）。
・ところがASU2016-1の公表（2016年1月）によって、公正価値を容易に決定できない持分証券については、原価で評価することができなくなり、原則として公正価値（例外処理あり）で測定されることとなった。
・この背景は、次のとおり。
・FASBは、資本性金融商品については公正価値により測定することが適切であるとの結論に至ったというが、市場関係者は「戦略投資」については、公正価値変動をその他の包括利益（OCI）に含める例外を設けるべきことを主張した。ところが、FASBは「このような例外を含めることは会計処理を複雑にするから」と相手にしなかった。
→ 絶句するほかない。ばかか。腑抜けのFASB。知ってはいたが、やはり腐ってやがる。
・FASBは、過去にIASBが戦略投資を原則主義的に定義することは困難であり、財務諸表の利用者にとっての有用性を増加させるとは限らないにもかかわらず、複雑性が増すとの結論に至ったことも参考にした、とか抜かしている。
→ 有効性を増加させるとは限らないのじゃなくて、情報価値を毀損させているんだろうが。
（結論）US Gaapは三流の会計基準に堕した。日本基準の方が断然ましである。
参考にさせていただいたサイト：
https://accounting-agent.com/equity-security-321-10/#ASU2016-01
担当者レベルで野良マクロを書きたくなる業務というのは、大概ややこしいのである。
引き継がれた通りにやったら、ここが10以下の時はこっちにしなきゃいけないとか言われる。
それどこに書いてあるんですかと聞くとどこそこのフォルダにテキストメモで入ってるとか言われる。
それこそ属人化の極みなのである。
慣れた人は、ああこれは10以下のパターンだからこっちの帳票だなってぱぱぱっと脳内で処理できるが、引き継がれた人はそうもいかない。
正しくマクロ化されていれば、少なくともVBEを覗けば、そこにその手順の全てが載っているということになる。
IFとFORとWHILE。GOTOさえ使わなければ、言語仕様によって強制的に構造化された手順書がそこにある。
そこまで整理されることで、上司や前の担当者にすら把握されていなかった業務手順の全体像というものが見えてきて、ここの手順は他に影響しないし大してお客様の役にたっていませんよねとか改善提案ができるのである。
そんなのわざわざマクロ化しないでも人間が読めるようにWordでまとめればいいだろ、と思うかもしれない。
しかし人間は曖昧さと空気読みが大得意で、文書でまとめるとつい厳密でない記述を残したり（こういった場合に注意する、とか。注意してどうするのか書かれない）、書かれていなくても経験とか常識で対応できてしまう。
VBAには曖昧さは通用しないので、得てしてWordでまとめたマニュアルなどより遥かに正確で抜けのない読みやすい（言語さえ読めれば）業務手順になる。
そこから正式に業務マニュアルにすることもできる。改善提案もできる。
それだけでなく正式にシステム化発注する際の要件定義書にすらなりえる。
スクリプト言語とはいえマクロが書かれているということは、既にほぼシステム化されているようなものなので、そこから仕様を書き起こして少し検討するだけでいいのだ。
[B! 恋愛] うゆだ on Twitter: "もう絶対にこれの表れでしかないんですけど！？！！って毎度なる。 絶対に看過したくない。 https://t.co/2UgQks5yXf" https://b.hatena.ne.jp/entry/s/twitter.com/Uyudna3/status/1440662399460069388
これマジで面白いんだけど、女アイドルの恋愛禁止はミソジニーだとして、じゃあ男アイドルの恋愛禁止はどうなのかっていうと、
男アイドルの交際相手の女や男アイドル自身が女ファンに対してミソジニーを発露しているって話にされてるんだよね。
嵐・二宮和也が結婚したときに結婚相手がブログでニノと付き合ってる「匂わせ」をしてたと話題になった。
まず交際相手らしき人物のブログを監視して「匂わせてる！」といちいちキレてる時点で相当気持ち悪いけどまあそれは自由だわ。
そんでアイドルが結婚してファンが悲しんだりキレたりするのも、まあ自由だわ。ネットで誹謗中傷をばらまいたり直接危害を加えたりしない限りは。
ところでネット上のフェミニストにはジャニオタや腐女子を兼ねている人が結構います。
そうした人々の一部がニノの結婚のときにどういった言説を行ったかの一例を提示しよう。
https://twitter.com/mijiyooon/status/1194369092636958720
私がこんなこと言うすじあいもないんだけども、匂わせって、無邪気に自分の気持ちがあふれるだけならいいけど、そこに微量でもマウントが入ってるとかぎ分けちゃうもんなんだろうなって。
んでこんなこというと、フェミなのにミソジニー…みたいな感じもあるかと思うけど、男性をめぐって自分のほうがより知っている愛されている、みたいなことでそれ以外の人に知らしめたいという感覚のほうが、ミソジニーを基本としていると思ったりもする。
男性をめぐって女性同士は競い合うものっていうことを内面化している人はもちろんいて、自分もそういう考えに毒されていたこともあったけど、たぶんそんな気持ちは実はいらないのではないかって。
周囲の人に影響を受けるので、父親がそんな風に母親と娘を競争させる感じに持っていく人とかに育てられると、未就学児でもそんな感じになってたりするのを見たことがあって。お母さんがすでにライバルなの…。村上龍が父権の高い男に育てられた娘はモテる女になるみたいなこと言ってたけどこれかって。
https://twitter.com/hd_dondon/status/1195989080154075136
某アイドルが匂わせする相手と結婚した件、前にあったUV◯Rworldのやつみたいな「男性アーティストが女性のファンを見下している」に当たるミソジニー案件だと思ってたから、フェミニスト自認の人たちが女性ファン批判の方に流れてるの見て驚いてしまった
「男性ファンが女性アイドルに処女性を求める」ことと「女性ファンが男性アイドルに偶像性を求めること」って背景が異なると思うんだけど、そこを無視して男も女も一緒！みたいにするの、ミソジニストのやり口と変わらないと思うんですが
別に女性無罪論を唱えたい訳じゃないけど、アニオタによるジャ◯ーズの女オタク叩きって昔から酷かったし（今回も見た）、あの手の話題が殊更荒れるのって「イケメンが好きな女性」に対するミソジニーも含まれてるからじゃないかって常々感じていたので。
結婚相手の女性に対して「匂わせ女」だとして誹謗中傷混じりの非難が行われている状況に対しての言説の一例がこれ。
「匂わせ女」を叩く女性ファンの言動よりも「匂わせ」をする側の方がミソジニーである、という理論。すごいよね。
仮にそうだとして、交際相手の女性一人に対して大勢のファンがネットでぶつける非難の方がどう考えても巨大なミソジニーだろ。どうなってんだ。
他にも「交際相手の匂わせ行為を許しているのはニノ自身の女性ファンに対するミソジニーの発露」とか、
アクロバティックな理論でアイドル側を加害者とする理屈を唱える者なんかがマジでいて、それにいいねがたくさんついて共感される状況が展開されていた。
腐女子フェミニストとかもおんなじだけど、男の文化（と思っているもの）への普段の苛烈な非難に対して自分の趣味は不思議なまでに例外処理を行い、
どんな状況からでも「女は被害者・男は加害者・男におもねる女は名誉男性で加害者」という構図を維持しようとする努力、マジですごいなと思います。
プログラマーに憧れる皆さん！こんばんは。
「自分は文系だから」「未経験だから」と諦めていませんか？大丈夫です！プログラミングにセンスは不要です。正しい手順で学べば、文系や未経験でも、誰でも一流のプログラマとして活躍することができます。
今日は、未経験から最短で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構文を用いて、例外を潰すようにしましょう。
部分的にでも理解すればプログラミングを見る目が変わるはずです。
変数や構文などのプログラミングの基礎は覚えた人向けに、ソースコードを書くときのコツを紹介していきます。どれも今日から実践できるものばかりです。他のプログラマと差をつけることができる技術ですので、ぜひ意識するようにして下さい。良い子はまねしないで下さい。
理想は、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構文を用いて、例外を潰すようにしましょう。
教科書を読んだだけで、全く手を動かさずにテストの8割答案を埋められる人は何割いるだろうか？
テストのレベルにもよるとか言われそうだが、伝えたいことはそうではない。問題なのは、塾に通って何度も手を動かしても、教科書の例題を解くのが精一杯の生徒は確実にいるという事実を皆が無視して、馬鹿に優しくない世の中を作ってるということだ。
直感的に操作できるアプリケーションを本当に直感で操作できる人はひと握りだ。VBAなんてプログラミングの知識なしで書けると売り出したが、結局何割の人が使えたのか？VOOKUPどころか四則演算すらまともに出来ないから、ジジババは電卓で確定申告書を作ってる。
1番の問題は、貧しい人を救うセーフティネットはいくらでもあるが、貧しい人は往々にして馬鹿なのでその恩恵に預かれないということ。
例えば、馬鹿だと自らの貧しさを説明することが出来ない。去年に比べて収入が減ったことを説明出来ない。
「BSとPL作ればいいだろ、個人事業主や家庭のなんてちょっとググればサクッとつくれるだろ」と言い放っても出来ないものは出来ないのだ。
ふるさと納税がしたいが確定申告が出来ないから諦めてたサラリーマンがたくさんいたように、大半の人間は自分の現金収入すら把握してないし、いくら税金を払ってるかも知らないのだ。まして、現金以外の資産状況については全く説明出来ない。
教科書を読んだだけで答案を埋められる人にとっては、この世はイージーモードだ。
制度を作ってる人達もやっぱり教科書を読んだだけで答案を埋められる人たちなので、馬鹿にとってはハードモードなことを理解できない。
馬鹿は長い文章は理解できないし、条件分岐も例外処理も理解できない。
役所に行けば食べ物が貰えます、そのくらいのシンプルな仕組みのセーフティネットしか馬鹿が利用することは出来ないのだ。
本論とは話がズレるが、時折、田舎は文化レベルが低いとか教養がないとか言う議論があるが、自分の観測範囲だと、都会と田舎もヤンキー比率の中のマイルドヤンキーとガチヤンキーの比率が違うくらいで、ここで言うマトモな人間、教科書を読めば答案が埋まるような人間の比率は都会でも田舎でも1割くらいじゃなかろうか。