「例外処理」を含む日記 RSS

はてなキーワード: 例外処理とは

2021-11-21

anond:20211121084140

コード?書く?例外処理

コンセントに刺さってる電源コードみたけど、増田の言ってることよくわからなかった。

anond:20211121082514

コード書いてる人が多いんじゃないかなとなんとなく予想。

常に例外処理意識してるから言葉定義例外に敏感なんだと思うし、文脈をあえて読まずに文章どおりに解釈をする。

なのでコード書かない人から見たら揚げ足取りに見えるんじゃないかな。

2021-09-25

マクロ化できたということは、正しくマニュアル化できたということでもある

担当者レベル野良マクロを書きたくなる業務というのは、大概ややこしいのである

無駄に手順が煩雑だったり、分岐例外処理の山なのである

引き継がれた通りにやったら、ここが10以下の時はこっちにしなきゃいけないとか言われる。

それどこに書いてあるんですかと聞くとどこそこのフォルダテキストメモで入ってるとか言われる。

前例確認しろとか言われる。

それこそ属人化の極みなのである

慣れた人は、ああこれは10以下のパターンからこっちの帳票だなってぱぱぱっと脳内で処理できるが、引き継がれた人はそうもいかない。

そんなことをされるとマクロ化したくてしょうがないのである

正しくマクロ化されていれば、少なくともVBEを覗けば、そこにその手順の全てが載っているということになる。

IFとFORとWHILE。GOTOさえ使わなければ、言語仕様によって強制的構造化された手順書がそこにある。

そこまで整理されることで、上司や前の担当者にすら把握されていなかった業務手順の全体像というものが見えてきて、ここの手順は他に影響しないし大してお客様の役にたっていませんよねとか改善提案ができるのである

そんなのわざわざマクロ化しないでも人間が読めるようにWordでまとめればいいだろ、と思うかもしれない。

しか人間曖昧さと空気読みが大得意で、文書でまとめるとつい厳密でない記述を残したり(こういった場合に注意する、とか。注意してどうするのか書かれない)、書かれていなくても経験とか常識対応できてしまう。

VBAには曖昧さは通用しないので、得てしてWordでまとめたマニュアルなどより遥かに正確で抜けのない読みやすい(言語さえ読めれば)業務手順になる。

マクロ化は礎(いしずえである

そこから正式業務マニュアルにすることもできる。改善提案もできる。

それだけでなく正式システム化発注する際の要件定義書にすらなりえる。

スクリプト言語とはいえマクロが書かれているということは、既にほぼシステム化されているようなものなので、そこから仕様を書き起こして少し検討するだけでいいのだ。

そういう能力を持った人材がいるのなら、むしろ管理職が先導して積極的マクロ化させるべきなのである

2021-09-23

アイドル恋愛禁止ミソジニーだとして、じゃあ男アイドルは?

[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のやつみたいな「男性アーティスト女性ファンを見下している」に当たるミソジニー案件だと思ってたから、フェミニスト自認の人たちが女性ファン批判の方に流れてるの見て驚いてしまった

男性ファン女性アイドル処女性を求める」ことと「女性ファン男性アイドル偶像性を求めること」って背景が異なると思うんだけど、そこを無視して男も女も一緒!みたいにするの、ミソジニストのやり口と変わらないと思うんですが

別に女性無罪論を唱えたい訳じゃないけど、アニオタによるジャ◯ーズの女オタク叩きって昔から酷かったし(今回も見た)、あの手の話題が殊更荒れるのって「イケメンが好きな女性」に対するミソジニーも含まれてるからじゃないかって常々感じていたので。



結婚相手女性に対して「匂わせ女」だとして誹謗中傷混じりの非難が行われている状況に対しての言説の一例がこれ。

「匂わせ女」を叩く女性ファン言動よりも「匂わせ」をする側の方がミソジニーである、という理論。すごいよね。

仮にそうだとして、交際相手女性一人に対して大勢ファンネットでぶつける非難の方がどう考えても巨大なミソジニーだろ。どうなってんだ。

他にも「交際相手の匂わせ行為を許しているのはニノ自身女性ファンに対するミソジニーの発露」とか、

アクロバティックな理論アイドル側を加害者とする理屈を唱える者なんかがマジでいて、それにいいねがたくさんついて共感される状況が展開されていた。

腐女子フェミニストとかもおんなじだけど、男の文化(と思っているもの)への普段苛烈非難に対して自分趣味不思議なまでに例外処理を行い、

どんな状況からでも「女は被害者・男は加害者・男におもねる女は名誉男性加害者」という構図を維持しようとする努力マジですごいなと思います

2021-09-19

ソート処理

リスト存在しないことを表す表現として「-1」を使っているが、空は後ろに詰めたい。

昇順のバブルソートを組んだがそれでは-1が0より手前に来てしまう。

例外処理を書きたいが交換に伴う副作用が内容物が入っていることを前提に組んでいるので諸所で-1判定を組み込んでスキップさせるか、副作用が無い純粋な入れ替え処理だけをコピペで用意しなければ。

純粋な入れ替え処理だけを切り出して、-1ならそれだけ、それ以外なら副作用サンドイッチ

とも考えたが、-1なパターンて交換元の場合もあるし交換先の場合もある。

例外処理が2倍になる感じでもう面倒くさくて考える気がなくなってきた。

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-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-03-22

人の「友人がこういうことをしたら(関係を)切ると決めている」という主義に触れると、友人関係例外処理集合体のようなものとして捉えてる自分とは逆に、無矛盾関係をつくろうとする姿勢を感じで怖気づくようなところがある。まったく構わないことではあるんだけども。

2021-02-21

世の中はもっとシンプルにあるべき

教科書を読んだだけで、全く手を動かさずにテストの8割答案を埋められる人は何割いるだろうか?

テストレベルにもよるとか言われそうだが、伝えたいことはそうではない。問題なのは、塾に通って何度も手を動かしても、教科書の例題を解くのが精一杯の生徒は確実にいるという事実を皆が無視して、馬鹿に優しくない世の中を作ってるということだ。

直感的に操作できるアプリケーションを本当に直感操作できる人はひと握りだ。VBAなんてプログラミング知識なしで書けると売り出したが、結局何割の人が使えたのか?VOOKUPどころか四則演算すらまともに出来ないから、ジジババは電卓確定申告書を作ってる。

1番の問題は、貧しい人を救うセーフティネットはいくらでもあるが、貧しい人は往々にして馬鹿なのでその恩恵に預かれないということ。

例えば、馬鹿だと自らの貧しさを説明することが出来ない。去年に比べて収入が減ったことを説明出来ない。

BSとPL作ればいいだろ、個人事業主や家庭のなんてちょっとググればサクッとつくれるだろ」と言い放っても出来ないものは出来ないのだ。

ふるさと納税がしたいが確定申告が出来ないから諦めてたサラリーマンがたくさんいたように、大半の人間自分現金収入すら把握してないし、いくら税金を払ってるかも知らないのだ。まして、現金以外の資産状況については全く説明出来ない。

教科書を読んだだけで答案を埋められる人にとっては、この世はイージーモードだ。

制度を作ってる人達もやっぱり教科書を読んだだけで答案を埋められる人たちなので、馬鹿にとってはハードモードなことを理解できない。

追記

ここまで読み切った人達は、馬鹿共感する資格はない。

世の中の馬鹿は、こんな長い文章は読めないのだ。

馬鹿は長い文章理解できないし、条件分岐例外処理理解できない。

役所に行けば食べ物が貰えます、そのくらいのシンプルな仕組みのセーフティネットしか馬鹿が利用することは出来ないのだ。

さら追記

本論とは話がズレるが、時折、田舎文化レベルが低いとか教養がないとか言う議論があるが、自分観測範囲だと、都会と田舎ヤンキー比率の中のマイルドヤンキーガチヤンキー比率が違うくらいで、ここで言うマトモな人間教科書を読めば答案が埋まるような人間比率は都会でも田舎でも1割くらいじゃなかろうか。

2021-01-25

setjmpとかで例外処理してたのを思い出すからやめてくれ〜

2020-12-11

増田トラバ二重投稿ありがちなのは半分ぐらい運営のせい

増田って重くなると、書き込んで投稿ボタン押したときにたまに502エラーや504エラー吐くじゃん?

書き込めてないか不安になって戻るボタン押して再度投稿すると、二重投稿になってるんだよね。

いつもそうなるわけじゃないから、502か504、どっちかのエラー発生時は本当に投稿されてなかったことになる。

エラーコード素人に見せつけても意味ないんだから、「投稿できませんでした」ぐらい表示する例外処理ぐらい実装するべきなんだよね。

そこが改善されれば二重投稿は劇的に減ると思われる。

2020-11-26

go言語アプローチだとerror関数戻り値なので、戻り値を受け取らない関数呼び出しという

一見何の問題もなさそうに見えるコードが、error握りつぶすというよくない挙動を引き起こす。

 

throw-catchアプローチならばerror握りつぶすには意図的にそれを行うためのコードを書かないといけない。

かといってerror戻り値を必ず受け取らねばならないよう言語仕様制限を入れると、

かつてJavaが犯してしまったように例外処理がめんどくさすぎることになる。

 

もしgo++言語を作るとしたら、これはどのようにするのが正解なんだろうか。

2020-11-22

anond:20201122223948

anond:20201122224122

追記

https://doc.rust-jp.rs/book-ja/title-page.html

Rustの後方互換性の約束は守られています

って書かれてたわ

一年に二回くらいコンパイルが通らなくなった記憶があるんだが・・・なんかのクレート(パッケージ)だったかもしれない

いま昔のプログラム適当にチェックしてみたら明確にdeprecatedって言われたのはtraitにdynをつけろ(Trait objects without an explicit 'dyn' are deprecated)って部分くらいだ

https://qiita.com/maeda_/items/d765d514e7c72778f29f

ここまでのまとめ

Rustには記述シンプルにする仕組みもあり、ライブラリ実装者も気の利いた作りにしてくれたりするが、実際に裏側で何をやっているか把握しないとハマることがある。

また、例外処理や非同期のような基本的なところでも活発に議論されているし、ライブラリも刻々と変わっている。他の言語以上に流行り廃りが激しいことに留意しておくことが大切に感じた。

って言ってるから感想としては間違ってないと思うが・・・まりエビデンスのはっきりしないことは言うべきでないな

ごめんなさいRust

新人が書いたコード新人から洗練されてないのは仕方ないとして、例外処理catchして放置するだけなのが気になる

でもとりあえずは動いてるし教えるのめんどくさくてなんも言ってない

ごめんね

2020-11-18

賃貸トラブルチュートリアル面白いです

大屋がまったくのど素人適当対応に振り回されていた事に確信を持ってから、色々その手の賃貸トラブルサイト見てるけど

プログラミングチュートリアルより理解やすい。ざっくりした概要把握するだけで何とかなる感じ。

メソッド名(条文)とかファイル名とか行数(条項)覚えなくてもざっくりとした処理の流れと禁則だけわかっておけば何とかなる感じ。

推奨の書き方(交渉随意相場があり)なのか、そもそもエラーになる処理(法律的NG)なのかとかも

大屋目線サイト見てもしもの際の相手の出方を研究中。

向こうは専門家を付ける知恵もなさそうだけど、思いもよらない例外処理を繰り出してきそうで怖い。

そういう時は弁護士フレームワーク使えばサクっと行ける感じ。

2020-10-28

anond:20201028160831

そこら辺は上長とかシステム管理者メアドとか勤休管理名前をどう紐づけてるかにもよるからあくま一般論としてだが

数百人規模を超える会社システムを一人で回してたりすると、例外処理を招く新旧性ミックス人間を数人混ぜ込むのは死ぬほどめんどくさい

かといってこのご時世、各自パソコン監視するシステムくらいは常時動かさないとセキュリティを守れない

結果的資金繰りタイト会社ほどシステム更新に手が回らず、そういう個人の都合を無視せざるを得んもの

2020-10-22

anond:20201022110139

「型」という言葉が、たとえばCoqのような形式証明や、よくあるHaskell純粋性などを解説する際に用いられるような

「周辺環境すべての情報を含むもの

という意味でしたら、「型を一致させる」という表現は、あながち間違っていません。まあしかし、そういう意味で用いていないことは常識的に明らかでしょう。

単に「型を一致させる」と言った場合、他のオブジェクトへの副作用例外処理などの話題を含みませんが、Liskovの置換原則は、それらも含めた置換可能性を要求します。

2020-09-17

マウスシールドと消毒についてイベント現場から

イベント関連の接客業をしている。

最近マスクなし、マウスシールドのみ、フェイスシールドのみでイベントに来る客が僅かにいる。体感では1%より少ない。

少ないがそれに対する例外処理ができてない。

屋内イベントは国や自治体ガイドラインによりマスク義務化されていることが多いので、マスクなしで来場した客には、マスクなしでは入場できない旨を伝えて入場を断るかマスクを断るか販売するかして対応している。

※なにか理由がある場合強制しない

ここで困るのがマウスシールドフェイスシールドでの来場者だ。

河野行政改革担当大臣や森法務大臣が、何を考えてかマウスシールドのみつけて報道陣の前に出てくる。

これのせいで(これだけじゃないが)市中にマウスシールドだけ、フェイスシールドだけでも問題ない。なんなら「マスクより強力に対策できる!「」なんて言い放つ関係者ばかりでうんざりする。

こいつらはなんのためのマスク、なんのためのフェイスシールドかというのが致命的にわかってない。

で、あたりまえだがそんなやつばかりがトップなので手指消毒もほとんどの客もスタッフも正しく行えていない。ボトルスプレー最後までワンプッシュすれば、適量(少し垂れる程度)のアルコールが噴霧されるのに、垂れたり乾くのに時間がかかることを嫌って、スプレーをちょんと押して終わってしまう訳だ。

いまは市中感染者も少ないので実質的問題にはならないんだが、今後秋から冬にかけて感染者が増えてくるであろう時に、自分感染したり、それによって家族感染したり、なんだったら仕事も失うことになるわけだ。

恐怖しかない。

現状、コロナなんて〜とほとんどのやつらが思ってて、マスクも消毒もアリバイのためにしかされていない現状をどうにかしたいんだがほぼだれにも理解されない。理由は単純で私が専門家でも行政機関でもないためだ。

マイナポイント国勢調査CMバンバン打つくらいなら、公共広告で正しいマスク、正しい手洗い、正しい消毒について啓蒙してほしい。

国民の半分、いやせめて1/3くらいはアリバイとしての対策でなく、本質的対策を知ってる、くらいになってほしい。

接客業で多くみられる「マウスシールド」その有効性は【#コロナとどう暮らす】

https://news.yahoo.co.jp/byline/ishidamasahiko/20200714-00187918/

マウスシールドマスクの代わりにならない」新型コロナ感染予防で神戸市健康

https://www.kobe-np.co.jp/news/kobe/202009/0013659734.shtml

清水建設マスクの代わりに「マウスシールド」を全国の現場で導入

https://built.itmedia.co.jp/bt/spv/2006/23/news052.html

清水建設は屋外なので仕方ないと思う。

2020-06-27

プログラミングは一生安泰のスキルではない

プログラミングという言葉アフィブロガー御用達になって、SNSプログラマーを名乗るのが憚られる感じの昨今。

プログラミング勉強すればフリーランスで一生困らないみたいなこと書いてあるけど、そんな夢のスキルじゃないよ。

それなりにベテラン()を見てきたけど、結局はマネジメント層になれなければ会社にしがみつくことになる人が多い。

なぜなら概念レベルでの流行というものがあるから

これはvueかReactか、javaRubyかみたいな話じゃなくて、もう少し基本的な部分。

例えば大きいのはオブジェクト指向クラス/インスタンス概念

他には、ガベージコレクタ例外処理マルチスレッドデリゲートラムダ式、非同期処理、バインディングとビューモデルイテレータ、null安全

プログラミングを学んでる人には当たり前かもしれないけど、これらは十数年かけて徐々に当たり前になっていった。

ITバブルブイブイ言わせていたけど、これらをうまく扱えないベテラン結構いる。

固定長メモリポインタとmemsetで全てをまかなってきた層や、静的なモジュールで全部の画面を作ってたVB屋とか。

若いころは勉強すればいいと思うだろうが、理解はできてもそれを流暢に使いこなし適合するのは意外と難しい。

プログラムの中でその人の担当箇所だけいまいち読みにくくて、取り回しの悪いものになってしまう。いわゆるstaticおじさんというやつ。

これはベテランイラストレータシナリオライターが、デッサン構成力はあっても、なんか古臭いものが出来上がってしまうのに似ている。

こうなると若いチームメイトや新しいプロジェクトから敬遠される。

もちろん、COBOL案件が未だにあるように、レガシー資産を利用した仕事で腕を振るえる場所結構ある。

ただそういった環境既存人材企業にがっちり掴まれてることが多く、後から見つけて入り込むのは簡単ではない。

なので今いる場所仕事があるならば、それを失わないようにしがみ付くことになる。会社員であろうと個人事業主であろうと。

立身出世できなければ社畜。結局ほかの会社員と一緒だよ。

2020-06-24

[]2020年6月23日火曜日増田

時間記事文字数文字数平均文字数中央値
006911450165.957
01374296116.146
02465740124.850
031279966.657
0411101992.678
05106106610.6177.5
06232784121.081
07347304214.8126.5
0872658091.444.5
098410162121.061.5
109912235123.665
118913279149.274
12122708058.036
1312712984102.253
1411211947106.760.5
151441311691.142
162041680082.455
171571457492.850
1811312472110.445
1912318091147.146
2014916751112.447
211611454790.445
222441957680.246.5
2318021820121.243.5
1日2422261512108.050

本日の急増単語 ()内の数字単語が含まれ記事

富岳(4), 例外処理(11), COCOA(9), 富嶽(3), 非核(3), 高木浩光(7), 年パス(5), 女性化(3), 噺家(4), HiromitsuTakagi(4), 産総研(3), メールアドレス(15), 王子(14), 匿名性(13), 短期間(14), MS(10), 黒人差別(8), ルッキズム(10), インストール(12), 悪用(12), 誘う(10), いみ(11), アプリ(46), ジャニーズ(11), プログラマー(17), セキュリティ(10), 誘わ(12), ド(17), 不当(12), リリース(8), 手法(15), 黒人(31), 同意(37), 白人(20), 素人(26), 登録(22), 事前(16), 運用(16), 痴漢(50), エンジニア(22)

頻出トラックバック先 ()内の数字は被トラックバック件数

■なぜ酒がセーフなのかが分からない…… /20200622205006(26), ■接触確認アプリに関する炎上騒動誹謗中傷問題 /20200623071250(22), ■ /20200623160415(13), ■私が接触確認アプリインストールしない理由 /20200622163854(12), ■12年前にレジ袋を有料化した県に何が起こったか /20200622195053(12), ■日本小児性愛者の大半は「女性」だよね /20200623115004(8), ■昨日道を歩いてたら前にいた女性めっちゃ駆け足になって逃げていったんだけど /20200623073459(8), ■増田で同じ内容を投稿するのってあり? /20200623120022(7), ■富嶽1位取った富士通技術力と評価 /20200623001201(7), ■ポケモン世界風俗産業 /20200608213219(6), ■プログラマー連中にはもううんざり /20200623193731(6), ■学生アルバイト仕事を舐めていて辛い /20200623215646(6), ■日本google誕生しても絶対に潰されたよな。 /20200623221447(6), ■anond20200623071250 /20200623074018(5), ■anond20200623125511 /20200623125917(5), ■https://b.hatena.ne.jp/entry/s/www3.nhk.or.jp/news/html/20200623/k10012480321000.html /20200623135242(5), ■小説投稿サイトをよく観覧するのだけど /20200623143331(5), ■マジで今のインターネット「あああ!!敵対陣営のひとりがこんな酷いことを言った!!!叩け!!」の無限ループだよな /20200623145250(5), ■黒人制度差別に反対している人達って /20200623152303(5), ■「利己的な遺伝子」をちゃんと読んで /20200622052939(5), ■anond20200623160735 /20200623161138(5), ■anond20200623171321 /20200623171505(5), ■姉妹愛を描いた美しいアニメが見たいです /20200623224812(5), ■ /20200623223553(5), ■趣味で勝ち上がれなくて苦しい /20200623111102(5), ■なんでここに書き込んでる奴って /20200623095955(5), ■発達障害自称する人間ってウザくない? /20200623115458(5)

2020-06-23

anond:20200623142736

基礎的な例外処理をわかってたらテストしなくても必ずバグ回避できるんなら、ソフトウェア開発はとても楽だったんだがな。

残念ながら、そうではないのである

anond:20200623153604

そんなわけはない。

基礎的な例外処理をわかってないってのは、野球で言うとフライを取られたら

次のベースに走ってはいけないことをわかってないくらいのレベルなので

そんなヤツにはそもそも動くアプリが作れない。

今回問題が起きてるのは時間がないかテストしてなくてバグが残ってるという問題

 

それでも無理に問題をみつけようとするのであれば「基礎的な例外処理をわかってない」のではなく、

iOSで多くのアプリを作っている人なら回避できる、よくあるミス最初から回避できなかった点。

もちろん今回のプログラマーには、時間があればそのミス普通に見つけて普通に修正できる力はある。

anond:20200623071250

「基礎的な例外処理をわかってないプログラマー

驚愕のド素人開発」

結果から見たら事実陳列罪でしか無いじゃん。

施行版なんでバグ取り全くしてません。と思ってた奴はいくらなんでもいないでしょ。


「彼らは立場をよくわきまえている様子だった。なんとか王子とは違って」

そもそも批判対象厚労省受託先の企業が指揮するCOCOAというプロダクトな訳で、その責任者はパーソルプロセス&テクノロジー社でしょ。実際の開発を仕切ってたのはこの人のようだけど。

実際の開発してたのがこの人でも、出しゃばるのは体制から考えたらおかしい。この人はパーソルプロセス&テクノロジー社の人間ですらない。

「○○って(企業開発の)アプリのこの画面がバグだらけで素人レベルかよ」って批判下請けの実開発担当のBさんが「そんな批判しないでよ」って言い出してるような感じじゃん(COCOAでは特殊ケースだけど)

誰がどう開発してたかなんて99.9%の人は知らん事を後から知って人格攻撃だって言い出す事後諸葛亮やめなよ。

anond:20200623153604

「基礎的な例外処理をわかってない」んじゃあなくて、メイン機能関係ない部分を後回しにしてたら、後回しにしたまま納期が来てしまった、だと思うよ

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