  |
はてなキーワード: 例外処理とは
担当者レベルで野良マクロを書きたくなる業務というのは、大概ややこしいのである。
引き継がれた通りにやったら、ここが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割くらいじゃなかろうか。
＜追記＞
https://doc.rust-jp.rs/book-ja/title-page.html
って書かれてたわ
一年に二回くらいコンパイルが通らなくなった記憶があるんだが・・・なんかのクレート（パッケージ）だったかもしれない
いま昔のプログラムを適当にチェックしてみたら明確にdeprecatedって言われたのはtraitにdynをつけろ(Trait objects without an explicit 'dyn' are deprecated)って部分くらいだ
https://qiita.com/maeda_/items/d765d514e7c72778f29f
に
ここまでのまとめ
Rustには記述をシンプルにする仕組みもあり、ライブラリ実装者も気の利いた作りにしてくれたりするが、実際に裏側で何をやっているか把握しないとハマることがある。
また、例外処理や非同期のような基本的なところでも活発に議論されているし、ライブラリも刻々と変わっている。他の言語以上に流行り廃りが激しいことに留意しておくことが大切に感じた。
って言ってるから感想としては間違ってないと思うが・・・あまりエビデンスのはっきりしないことは言うべきでないな
ごめんなさいRust
最近、マスクなし、マウスシールドのみ、フェイスシールドのみでイベントに来る客が僅かにいる。体感では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
↑清水建設は屋外なので仕方ないと思う。
プログラミングという言葉がアフィブロガー御用達になって、SNSでプログラマーを名乗るのが憚られる感じの昨今。
プログラミングを勉強すればフリーランスで一生困らないみたいなこと書いてあるけど、そんな夢のスキルじゃないよ。
それなりにベテラン()を見てきたけど、結局はマネジメント層になれなければ会社にしがみつくことになる人が多い。
これはvueかReactか、javaかRubyかみたいな話じゃなくて、もう少し基本的な部分。
例えば大きいのはオブジェクト指向とクラス/インスタンスの概念。
他には、ガベージコレクタ、例外処理、マルチスレッド、デリゲートやラムダ式、非同期処理、バインディングとビューモデル、イテレータ、null安全。
今プログラミングを学んでる人には当たり前かもしれないけど、これらは十数年かけて徐々に当たり前になっていった。
ITバブルでブイブイ言わせていたけど、これらをうまく扱えないベテランは結構いる。
固定長メモリとポインタとmemsetで全てをまかなってきた層や、静的なモジュールで全部の画面を作ってたVB屋とか。
若いころは勉強すればいいと思うだろうが、理解はできてもそれを流暢に使いこなし適合するのは意外と難しい。
プログラムの中でその人の担当箇所だけいまいち読みにくくて、取り回しの悪いものになってしまう。いわゆるstaticおじさんというやつ。
これはベテランのイラストレータやシナリオライターが、デッサンや構成力はあっても、なんか古臭いものが出来上がってしまうのに似ている。
こうなると若いチームメイトや新しいプロジェクトからは敬遠される。
もちろん、COBOLの案件が未だにあるように、レガシー資産を利用した仕事で腕を振るえる場所は結構ある。
ただそういった環境は既存の人材・企業にがっちり掴まれてることが多く、後から見つけて入り込むのは簡単ではない。
| 時間 | 記事数 | 文字数 | 文字数平均 | 文字数中央値 |
|---|---|---|---|---|
| 00 | 69 | 11450 | 165.9 | 57 |
| 01 | 37 | 4296 | 116.1 | 46 |
| 02 | 46 | 5740 | 124.8 | 50 |
| 03 | 12 | 799 | 66.6 | 57 |
| 04 | 11 | 1019 | 92.6 | 78 |
| 05 | 10 | 6106 | 610.6 | 177.5 |
| 06 | 23 | 2784 | 121.0 | 81 |
| 07 | 34 | 7304 | 214.8 | 126.5 |
| 08 | 72 | 6580 | 91.4 | 44.5 |
| 09 | 84 | 10162 | 121.0 | 61.5 |
| 10 | 99 | 12235 | 123.6 | 65 |
| 11 | 89 | 13279 | 149.2 | 74 |
| 12 | 122 | 7080 | 58.0 | 36 |
| 13 | 127 | 12984 | 102.2 | 53 |
| 14 | 112 | 11947 | 106.7 | 60.5 |
| 15 | 144 | 13116 | 91.1 | 42 |
| 16 | 204 | 16800 | 82.4 | 55 |
| 17 | 157 | 14574 | 92.8 | 50 |
| 18 | 113 | 12472 | 110.4 | 45 |
| 19 | 123 | 18091 | 147.1 | 46 |
| 20 | 149 | 16751 | 112.4 | 47 |
| 21 | 161 | 14547 | 90.4 | 45 |
| 22 | 244 | 19576 | 80.2 | 46.5 |
| 23 | 180 | 21820 | 121.2 | 43.5 |
| 1日 | 2422 | 261512 | 108.0 | 50 |
富岳(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), ■anond：20200623071250 /20200623074018(5), ■anond：20200623125511 /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), ■anond：20200623160735 /20200623161138(5), ■anond：20200623171321 /20200623171505(5), ■姉妹愛を描いた美しいアニメが見たいです /20200623224812(5), ■ /20200623223553(5), ■趣味で勝ち上がれなくて苦しい /20200623111102(5), ■なんでここに書き込んでる奴って /20200623095955(5), ■発達障害を自称する人間ってウザくない？ /20200623115458(5)
そんなわけはない。
基礎的な例外処理をわかってないってのは、野球で言うとフライを取られたら
次のベースに走ってはいけないことをわかってないくらいのレベルなので
今回問題が起きてるのは時間がないからテストしてなくてバグが残ってるという問題。
それでも無理に問題をみつけようとするのであれば「基礎的な例外処理をわかってない」のではなく、
iOSで多くのアプリを作っている人なら回避できる、よくあるミスを最初から回避できなかった点。
施行版なんでバグ取り全くしてません。と思ってた奴はいくらなんでもいないでしょ。
「彼らは立場をよくわきまえている様子だった。なんとか王子とは違って」
そもそも、批判対象は厚労省や受託先の企業が指揮するCOCOAというプロダクトな訳で、その責任者はパーソルプロセス＆テクノロジー社でしょ。実際の開発を仕切ってたのはこの人のようだけど。
実際の開発してたのがこの人でも、出しゃばるのは体制から考えたらおかしい。この人はパーソルプロセス＆テクノロジー社の人間ですらない。
「○○って（企業開発の）アプリのこの画面がバグだらけで素人レベルかよ」って批判に下請けの実開発担当のBさんが「そんな批判しないでよ」って言い出してるような感じじゃん（COCOAでは特殊ケースだけど）