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

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

2023-01-18

中学の時便所飯してた

オタクだらけの班入れられて「こいつらと食うぐらいなら便所飯したほうがマシだから」って昼休み弁当障害者トイレで食べてた

使う人居ないのは知ってた

から使用禁止になってた

今思えば直接オタクグループ言えばよかったんだよねそれを

でも俺は優しいから抱えてしまうんだよね

班決めのときヤンキー忖度した担任が俺にオタク押し付けたよね

人数が足りなくなるのに押し通されたよね

例外処理を許したよね

優しいからよく許したね

こんなやつらと飯食うなら便所のほうがマシだよね

便所で隠し持ってたスマホTwitterやりつつ飯食ってたほうが楽しいよね

今思えば先駆者だよね

なんでスマホ禁止だったのだろう

いやヤンキーは持ってきてたけどね

自分が優しいからよく押し付けられるし、自分不正だけ正されるんだよね

中2の頃は年間100回遅刻してたよね

登校中ずっと葛藤してたよね、行くべきかどうか

たぶん今だから言えるけど行く価値ある中学じゃないよ

動物園もの、その見方は当たってるよ

もし便所飯したり引きこもったりしてる中学の子がいて、しかもその理由自分がかつてそうであったかのように妥当性があったら何て声をかけるかな

自分がそうであったかのように自殺を勧めるかな

2022-11-01

anond:20221101164547

最初に選んだドアが不正解だったとき司会者が開けるのは必ず外れのドアの方、という例外処理コーディングが間違ってるんだろうな。

2022-08-28

anond:20220828204835

障害者の扱いに限らず、例外処理というのは時間も労力もかかってとにかく面倒臭い。その例外処理利益の源泉なんだったらやるしかないが、金にもならないならそんなことやるメリットが無い。だからかいことは無視して障害者は「障害者」という単一の箱に入れてまとめて同じように扱いたいのだ。その方が面倒臭くないから。例外の人が多少不都合を被るかもしれないけどそれは扱いきれないので無視する。そこ頑張っても利益よりコストの方がでかいからな。

2022-08-26

社内システムを構築したがその後上司とそりが合わず現場に飛ばされた俺。後任のシステム管理者が泣きついてきたけどもう遅い。

俺にもあのシステムがなんで動いているのかわからいから……

 

例外処理に継ぐ例外処理例外処理

コピペコピペガッチャンコしたキメラコード

永久に繰り返されるループ処理。

どこで宣言されてどこで使われているかよくわからない大量の変数

 

すまんな。

2022-08-11

ネットで子持ちに「わかってて子どもを産んだんだろ」とかって絡むひといるけどさー。私は我が子のためにわざわざプレゼン資料作って役所の窓口で「そちらの制度理解と処理が間違っている可能性があるので一緒に確認してくれないか」と懇々と説明する育児なんて想定できんかったわ。制度担当者例外処理の取り扱いについて相互確認するための資料よ。それがないと話が全く進まないぐらい(状況の把握だけで混乱するレベル)で障害児の支援制度は複雑になるパターンが稀によくあるんですよ。

2022-07-28

anond:20220728014237

ちょっとミスしましたが、さきほどの虚無魔神と壊獣の裁定破綻はなく例外ではありません。一般的ルール範囲内で収まります

例えば虚無魔神がいるときに融合を発動して融合素材にしたり、シンクロやエクシーズの素材にすることはできません。

そう考えると割と普通なルールですよね。

これが虚無魔神と壊獣というあまり見ない組み合わせるなのでわかりづらいだけです。

こっちのほうが空撃ちに近く例外処理として扱えます

「妨げられた壊獣の眠り」は、自分または相手モンスターゾーンに「壊獣」と名のついたモンスター存在する場合でも発動する事ができます

その場合、お互いのフィールド存在するモンスターを全て破壊し、『その後、デッキからカード名が異なる「壊獣」モンスター自分相手フィールドに1体ずつ攻撃表示で特殊召喚する。この効果特殊召喚したモンスターは表示形式を変更できず、攻撃可能場合攻撃しなければならない』処理も通常通り適用されます

https://www.db.yugioh-card.com/yugiohdb/faq_search.action?ope=5&fid=19928&keyword=&tag=-1

壊獣がいると別の壊獣を出す行為も許さないのに、それができてしまう。

2022-06-06

自動化させるためのバリ取り」によって発生するコストが「自動化で浮く工数」を上回ることを説明しているんだが

何故か理解してもらえない。

多分俺の説明が悪いんだろうな。

何度か挑戦しているんだが毎回失敗する。

1ST LOOP 「脱穀機に入れる前に砂利を取り除かないといけないんですよ」作戦

俺「脱穀ってあるじゃないですか。稲を玄米に変えるアレ。アレの機械ってものによってはまず石を人間が取り除いておかないと玄米ごと石をジャリジャリやるから玄米が砂まみれになるし、なんなら機械も壊れやすくなるんですよね」

だいぶ上の上司「僕の実家の近くには自動精米機があるが、アレは自動で石を取り除く機能がついている。それを実装したまえ」

俺「それを実装することによる例外処理コストがだいぶかかるのですが」

俺の直属上司「そんなことないよ!異常なデータを取り除くだけだから簡単ですよ。すぐにやらせます

俺「異常かどうかの判定を凄く荒くすれば出来ますけど、それをやると自動化出来る部分が大幅に減って」

よそのそんな偉くない上司「つまり出来るということのようですな。喋る前に手を動かすべきですな」

GAME OVER

2nd LOOP 「面接の時に学歴フィルターをかけるでしょ」作戦

俺「面接の時には学歴フィルターをかけるわけですが」

まり関係ない部署上司「我が社はそんなことは断じていたしておりません!不愉快だ!かえりゅ!」

俺の直属上司「おい。謝りに言ってこい」

俺「はい

よその上司はいじゃないが」

直属の上司「本当に反省はしているのか。頭を冷やしてから、謝りに言ってこい」

3rd LOOP 「とにかく工数説明しよう」作戦

俺「今まで通りのやり方で作業した場合工数がおよそ2人月かかるデータに対して自動化を目指したと仮定しますと、そもそも自動化のフォーマットに合わせてデータを調整する作業自体に1人月、その後自動化で出力されたデータ確認作業に0.5人月自動で処理できなかったデータに対しての作業に1人月がかかり結果として合計のコストは増えることに」

偉い上司「つまりこの企画自体が失敗だったということなのですね」

俺の直属の上司の直属の上司「そんなことはありません!企画のコンセプトは正しいのです」

偉い上司B「では何故このようなことに?」

偉い上司C「想定しているデータの規模が小さすぎて自動化のスケールメリットが発生していないのではないかね」

俺「自動化は出来ても初期の処理や確認においては手作業に近い部分が入りますので」

偉い上司D「それを自動化することは出来ないのかね」

俺の直属の上司の直属の上司「今後の改良によって可能となります

俺「(無理だっつってんだろ)」

2022-05-18

anond:20220518013039

法的にはまず自動車原付自転車に割り振られ

そこから特定の条件を満たすもの施行規則例外処理されてる

から条件を満たさなくなったら単にその例外処理がなくなるだけ

2022-05-08

ギークためのChromebook入門

エントリ目的

ライトコンピュータユーザ一切合切無視してギークギークのため情報共有するためのエントリ
感想はてブへ、質問トラバに投げれば誰かが答えるんじゃないか?(他力本願)

開発者は初手でデベロッパーモードにするべし

セキュリティ懸念があるけれど通常モードはセキュアを維持するため機能制限があるので制限開放のため開発者は初手でデベロッパーモードにするしかない。
用途中でデベロッパーモードにするとストレージファクトリリセットされるので注意。

ハードウェア選択

Webで完結するのであれば低性能機で問題ない

Webエンタメを楽しんだりWebツールを中心に利用するのであれば、5万円未満の低性能機で必要十分。
この用途では実質的タブレットPCのような運用へなりやすいのでフリップする2 in 1機やタブレット機がオススメ

ただし、Webベースゲームは楽しめるがAndroid Appレイヤーを用いたゲームは非常に厳しいので諦めたほうが良く、そこそこの負荷の掛かるAndroid Appツールも鈍足でストレスになるのでWeb版があるならそっちを使ったほうが良い。

ChromeOSハードウェアスペックで殴ると快適なのは変わらない

Core i7クラスCPUや16GB以上のワーキングメモリSSDストレージなど高性能機でChromeOSを使うとその分だけ快適になる。
Android Appレイヤーを用いたゲームも快適に動き、ウマ娘クラス3DCGAndroid Appゲームも高速に動く。
しかし、高性能機は空冷ファンを搭載していることが多く、高負荷を掛ければファンは唸るしウルサイ。

Android Appレイヤーを中心に運用したいと考えてるならばx86_64機は非効率

Google Play StoreにてAABパッケージがほぼ強制になったとは言え、開発段階でx86_64を意識しないと処理が非効率になりがちのようなので、Android Appレイヤーを中心に運用したいと思っているのであれば素直にARM機を探してきたほうが良い。

1つのIDEで開発をしクロスプラットフォーム対応することが流行っている昨今、自動でガベコレに頼っていてリソース管理経験に乏しい開発者マジで底辺しか漂流できないので覚えたほうが良いぞ。
それがWeb系のフロントエンドでもバックエンドでもそうだから底辺から脱したいのであれば覚えろ。

しっかりリソース管理できているChromebook向けビルドアーキテクチャによらずサクサクなのでクロスプラットフォームビルドマジで開発チームの腕が如実に反映される。

ちなみにSnapdragon 8 Gen1なChromebook公式発表は今のとこ無いのでAndroid Appレイヤーブンブン回すのは難しい。
メーカーはもうちょっと頑張れ。

Android Appレイヤー

macOSiOSレイヤーよりAndroid App数は多いし操作性は良い

Chromebookの大半はタッチスクリーンディスプレイを搭載しているし、Android StudioでAndroidManifest.xmlを何も考えずに生成すると勝手にChromeOSサポートするので結果的にChromeOSで動くAndroid App数が多くなるという現象が起きている。

Android Studioが雑なのかXcodeが厳密なのかは意見が分かれると思うけど、タッチパッドでiOS App操作というセンスがクソなのは万人が納得するところだと思う。

GPS事実上ほぼ機能しない

ARM系のSoCであればワンチャンいける可能性はあるものの、市場に出ているChromebookの大半はx86_64でGPSモジュールを積んでいないのでGPSを使おうと思うとBluetoothあたりでGPSレシーバ接続するしか無い。
当然A-GPSは使えないので精度がそこまでではないから期待し過ぎに注意。

USB over MIDIが使える

Android AppレイヤーではUSB over MIDIが使えるのでDTMあたりに活用することは可能ものの、iOS比較してレイテンシがそこそこ大きくDTM活用しようと思うユーザは不満を持ってしまうかも知れない(ハードにもよるけど0.5msecくらいズレる)。

そもそも既存Android AppなDAWVSTやLV2などの外部プラグイン対応していないのでAUプラグインが使えるiOSのほうがDTMへ向くんじゃないだろうか?
ただし、DAW単体でDTMを完結するとレイテンシほとんど気にならなくなるので絶対Android AppでDTM不可能というわけでもない。

Linuxレイヤー側でDTMをするのはレイテンシが大きすぎるしJackも上手く動作しないのでオススメできない。

ChromeOS向けマルチタスク対応していないとAndroid Appはスリープする

ChromeOS向けマルチタスク対応していないとAndroid Appはフロントエンド(プライマリ)からフォーカスが外れてバックエンドへ行くとスリープする。
Android Appがスリープされることを考慮しておらず例外処理がされていないとAndroid Appはそのまま落ちる。

まぁAndroid Appがスリープされることを考慮しておらず例外処理がされていないとAndroid Appはそのまま落ちるっていう部分はAndroidスマホで実行しても同じなので正直に言ってスリープされることを考慮しないデバックってAndroid App開発者は何やってんの?とは思う。

ICT教育日本中学生がChromeOSを使うようになっているので、ゲームであれツールであれ何であれChromeOS向けのマルチタスク考慮しておくとスリープしたり落ちたりするAndroid Appよりも支持されるのは間違いないのではないか

Linuxレイヤー

実体LXC/LXD

LXC/LXDなのでDockerに慣れ親しんでる人にはわかりやすいかも?

デフォルトイメージはChromeOS向けにカスタムされたDebian
別のLinuxディストリビューションへ置き換えることも出来るが一部機能制限される可能性がある。

IMLinuxレイヤー側で用意する必要がある

ChromeOS動作するGoogle日本語入力とは別にLinuxレイヤー側で日本語入力を用意する必要がある。
選択できるIMは幅広いのでMozcだろうがSKKだろうが漢直だろうが何でもイケる。
ただ特殊ものを選ぶとChromeOS側と齟齬が発生するのでfcitx-mozcあたりが無難っちゃ無難

USB Pass Throughが使えない

ChromeOSマウントされたUSB機器、というかシリアル接続された機器Linuxレイヤーから認識しない。
見掛け上で接続されているハードのすべてはソフト仮想接続されているだけなので、一部経路から上手く認識しなかったりする。

まりLinuxレイヤーではUSB Pass Throughが使えないが、Android AppレイヤーではUSB Pass Throughが使えるということ。
Linuxレイヤーゲームやろうと思ってもUSBゲームパッド動かないのでマウスキーボードで完結できるFPSみたいなゲームしか上手くプレイできないぞ。

それぞれが独立しているLinuxレイヤーAndroid Appレイヤー相互認識しない

言うなればAndroid Appレイヤースクリーンキャプチャ系のアプリによってLinuxレイヤーで動くGUIアプリキャプチャしようと思ってもキャプチャできず撮像は暗転している。

ChromeOSホストLinuxレイヤーAndroid Appレイヤーゲストなのでそりゃそうなんだけど気付かないとハマる。

LinuxレイヤーDockerを構築するのはやめておけ

LXC/LXD on LXC/LXDになるので面倒くさくなること請け合いだ。
どうしても仮想環境Chromebookに欲しいのであればKVMとかのほうが安定している。
ただしゲストOS上へ仮想環境を構築しているという前提は認識しておくべき。
まりゲストOS制限KVMも引き継ぐ。

ただしこれはDockerが導入できないという意味ではない。
自分解決する気概があるのならばDockerは便利に使える。

Web開発であれば必要十分

CLIツール系は普通に動くのでWeb開発であれば何も意識しないで普通にできる。
ただ、PSD形式みたいなもんは扱いにくいのでWebデザイナーは悲しい思いをするかも知れない。

GIMPInkscapeなども動くけれどデザイナーAdobe使いたいんじゃなかろうか?

Chrome OS向けAndroid Studioが存在する

Android App向けIDEAndroid StudioはChromeOSけが存在するのでAndorid App開発が可能
しかデベロッパーモードでなければエミュレータや実機デバック制限が発生するので注意。

3DCGゲームを作りたいのであればGodot

UnityやUEを使いたいところだけれど、Linux版のUnityやUEは不安定なのでゲーム向けIDEが欲しいのであればGodotがオススメだ。
ライセンスMITなので商用利用だってイケる。

3Dのほか2Dゲームもいける上に、最近IDEよろしくマウスポチポチUIを作れるし、軽量動作物理演算日本語ドキュメントまで揃っているので中高生ガンガン使える素晴らしいIDEだ。

総評

浅い部分は気軽だが深い部分は非常に難解、それがChromebook

浅い部分を触っているうちはYoutubeを観たり、プリインストールされているGoogle Play StoreからAndoird Appをインストールして使うみたいな気軽な運用ができる。
言ってしまえばライトユーザ視点ではノートパソコンの形をしたAndorid機がChromebookだと言える。

しかし一度Linuxレイヤーへ手を出すとUbuntuという何でもできるようになったLinuxディストリビューションが存在する中で、昔懐かしい複雑怪奇Linuxディストリビューションを体験することとなってしまう。
ただ、Chromebookで何でもやろうとするからそうなるだけで、APTからIDEインストールしてちょっとした開発をするなんて使い方であるならば業務利用でも意外となんとかなる・・・というか何も意識しないで使える。

そもそもHTTP使えるなら今どきの開発は何とかなるので、Chromebookへ対してギークがゴチャゴチャ言うのはほぼ間違いなく不満を言いつつDIYを楽しんでる。
Ubuhtuならばアレができるコレができると言うならば最初からUbuntu使えよって話。

ギークとは不便を見つけてゴチャゴチャ言う、そういう鳴き声の動物なのだ

追記

少なくともGoogleエコシステムとしてのChromeOSは非常に完成度が高くなりつつある。
Googleアシスタントは元よりAndoridスマホとの連携もよく、ハードウェアへもそこそこの投資ができるのであれば多くのChromebookではUSIペンが使えるし、USBポートUSB-Cだ。
そこそこのChromebookは多くの場合HiDPIIPS液晶でありグレアなのは気に食わないが美しい。
デベロッパーモードにするとセキュアさは下がるが普通に使えばローリングリリースアップデート無償で得られ、Gentoo LinuxベースなChromeOS潜在的マルウェア絶対数がそもそもWindowsMacよりも少ないという利点がある。
Bluetoothイヤホンヘッドフォンヘッドセットも使えるし、NestスピーカーNest HubNest Camを持っているのであればGoogleアシスタントからコントロールが容易なのは想像が付くだろう。Android AppレイヤーGoogleホームマネジメントアプリであるGoogle Homeも動く。
大胆にも憎きCapsLockキーデフォルトで殺し、Everything Buttonキーとして独自キーバインドを与えたのも面白い
もちろんこれは選択するハードによるもの指紋認証ロックを解除することまでできる。

Googleエコシステムへ浸かっていてGoogle個人情報を捧げられるのであればChromebookはアリな選択肢だと断言できる。
敢えて欠点を挙げるのならば、たった一言欠点表現することが可能だ。


Chromebookじゃなくても別に良くね?」


そう、ギークLinuxを使いたいのであれば別にChromebookじゃなくても良い。
というかギーク別にLinuxじゃなくともHaikuであろうが超漢字Ⅴだろうが喜ぶ生き物だ。OS別になんだって良い。
このエントリは単にChromebookという新しい沼ギークの皆さんをご案内しているに過ぎないのだ。

2022-04-21

 

一度プレイしてみろとか他のゲームのほうが例外処理多いとかいくらでも反論できるのに

anond:20220421171404

例外処理が少ないことを説明たかったけど無能からできなくて捨て台詞はいて引っ込みがつかないンやろなぁ

anond:20220421170118

囲碁のコウは例外処理であってると思うけど

コウが3つ出来て三コウになると無効試合になる

anond:20220421165926

横じゃなくて本人なら徹底的にやるけど?

例外処理量の多寡クソゲーに明確な定義がない以上

主観であって事実誤認とななんも関係がないんだよなぁ

例外処理って要するにエラーに対して上位のクラススローするか自分で処理するか握り潰すかっていう、アレの話だよな?

プログラミングの話じゃないの?

特殊ルールが多いって意味で使ってるの?

なんか全然話違う方向に飛んでてワロタ

anond:20220421165739

その反論は「例外処理」について「クソゲーであるか」という要素を絡めて説明すべきであって

「エアプ!」で批判した気になれるわけではないだろ

anond:20220421164757

例外処理の話になるかと思って見てたらエアプ煽りエアプ否定応酬から呆れてしまった

囲碁ルール例外処理的なやつって

コウ周りだけじゃねえの?

anond:20220421163237

凄いな~

囲碁例外処理が多いかどうかの話かと思ったら、結構早いうちからエアプって言葉が正しいかどうかの話になってる

これが増田クオリティ

もちろん横

anond:20220421163714

からだけど、「エアプ!」「エアプじゃない!」の言い争いやってて虚しくならんの?

そもそもは「例外処理」云々だろ?

おれも囲碁はつまなそうだと思うが、「例外処理があるとクソゲー」は正直よくわからん

具体的にどんなの?

anond:20220421161823

別に囲碁プレイヤー気取りたいわけでも

ガチでやったけど足洗ったマンを気取りたいわけでもない

始めてルール聞いて例外処理ばっかでクソゲーって感想を持っただけ

なにか?

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