「デバッグ」を含む日記 RSS

はてなキーワード: デバッグとは

2019-06-14

何をやってもツイてない増田住まい名手いつもテッヤを蜷(回文

おはようございます

なにをやってもツイてなくうまく行かない日ってあるじゃない。

なんか昨日は、

ずっとそんな日で1日ツイてないなぁーと思いつつ、

こういう時は大人しくしておくに限るんだけど、

それに追い打ちを掛けるかのように

車に鳥のフン。

あちゃー今日はほんと正にこういう日なのね!

ってまあそれに関しては「運」が付くって思っちゃえるぐらいなので、

あとで洗車機かければ汚れ落ちるし

さすがにやったー!とまでは思わないけど

ラッキーポイントが当たったって感じね。

で車を駐めていた駐車場の料金を払おうと精算機に行ったのよ。

そしたら駐車料金は無料です!って精算機が言うじゃない。

誰かが駐車番号を間違って払っちゃったったとしても、

それはそれでさすがに直前じゃないから少しは駐車場代は発生するわけじゃない?

杓子定規で愛想のない間違いもない機械よ。

ポイントカードが貯まったか無料とも限らないし、

第一そんな気の利いた機能は無いし

会員のポイントカードだってまだ入れてなかったのよ。

でもちゃん無料です!ってしっかり言って

車止めもちゃんと解除されてるし、

なんかツイいてないなーって思いながらも

捨てる神あれば拾う神ありって言葉意味はよく分からないけど

まりそう言うことなのかしら?

泣きっ面に蜂の逆バージョン

もしかしてデバッグモードとかで精算機のそういうドアを開けちゃったのかしら?

よく分からないけど、

その時の操作手順も忘れちゃったし、

だってでもいつもの精算方法でやったのよ。

からなお不思議だなーって。

これに興じてまた調子に乗ったらだめだから、

今日今日で慎重に運転して帰ったわ。

駐車場代浮いたお金で洗車できたし、

別にそうたいしたことじゃ無いけど、

なんだか不思議体験だったわ。


今日朝ご飯

バナナ1本をサクッと食べた感じ

落ち込んでいられないので頑張るわ適当に。

デトックスウォーター

コールド麦茶ウォーラー

出来栄えは上出来!

美味しく出来たわよ。

これを夜帰って飲むのもすーっと身体に染みわたる感じがいいのよね。

デトックスウォーラーオススメ


すいすいすいようび~

今日も頑張りましょう!

2019-05-22

4000Stepを超えるVueコンポーネントを見た

もはやどこまでが methodでどこからがcomputedなのかも判断できなかった。

VuexのModuleも5000Stepを超えていた。管理しているstateの数は100近かった。

もちろんTypeScriptなどという高尚なものを使っているわけもなく。コメントからなんとなくObjectの型を推測してデバッグするしかなかった。

テストなんてあるわけない

chromeデバッグツールけが頼りだ。Vueデバック用の拡張機能は重すぎて動かなかった。

非同期処理のハンドリングも雑だった。

async関数の中で平気でコールバック関数を呼んでたりするし、

awaitがついていないことも多々あった。

アプリ挙動が安定しないのは明らかに雑な非同期処理のせいだったが、コードが巨大すぎて原因を突き止めるには至らなかった。

処理の途中でObjectの型が変わることもしょっちゅうだった。

さすがJavaScriptだ。必要になったら必要になった分だけいくらでもプロパティを追加できる。

でもごめんなさい。追加してくれたのはありがたいけど、僕には今目の前にあるObjectに何が入っているのかもはやわからないんだ。

君が好意で追加してくれたプロパティを、僕は活かすことができない。

このコードにらめっこを始めてから3日間、全く進捗はなかった。

今日やっとなんとなく全体像がつかめてきたところだ。

明日からは、何かしらの進捗が出せるかもしれない。

とりあえずModuleを分割するところから始めようか

いや、その前にテストを書く必要があるのかもしれない。

でもどうやって書けばよいのだろう。正解がわからないんじゃテストの書きようがないじゃないか

週末には、上司に何かしらの報告を入れなければいけない。

どう説明すればよいだろう。いっそさじを投げてしまおうか

「あまりにも難解すぎて私には無理です」

と。

でもたった3日で諦めてしまってよいのだろうか?

しかしたら、これはものすごい成長のチャンスなのかもしれない

僕が世間知らずなだけで、世の中にはこんなコードがいっぱいあって、みんなこの試練をくぐり抜けて一人前になっているのかもしれない。

たかだか4Kステップときでガタガタ言うなと言われてしまうかもしれない。

この程度でさじを投げていたら、なんの仕事もできないのかも・・・

とりあえず今日疲れた。もう寝てしまおう。

明日になったらなにかいアイデアが出てくるかもしれないし

しかしたら親切な増田たちが、あっと驚く素敵な解決方法を見つけてくれるかもしれない。



明日自分に幸あれ

2019/5/22 記

2019-05-07

普通エンジニアみたいになれない

何もないところから何かを生み出すのが苦手。新しいことを考えろと言われるのが苦手。言語機能を詳しく知るのが苦手。ライブラリの隅々まで体得するのが苦手。登壇してしゃべったり、本書いたりする人って本当にすごいな。俺の知ってることなんて3行で終わるレベル

既存コードがある状態で、それをまねしながら書いていくので一向にメソッド名とか覚えない。〇〇というライブラリを使ったことがありますといっても、既存コードで使っている以上の機能は使わないので全然まらない。基本的にVSを便りに書いているので、言語文法すらあやふや

既存コードを読んで動きを理解するのは得意。既存コードバグ報告から原因を特定するのが得意。とくにレースコンディション関係の地道なデバッグが得意。好きではないけど。

今まで面接ではできる風を装って突破したが、それもつらくなってきた。これからも周囲を、そして自分をだましながら生きていかなければならないのか。

2019-05-03

anond:20190503155458

何ができたらプログラマなんてのは気持ち問題

大事なのは課題が何でその課題をどれだけの工数解決できるか

課題に合ったスキル経験、基礎知識と応用力があればそれが短縮されるというだけ

過去プロジェクトコード改変で15分でできるのか

関数名調べつつ処理考えつつエラーデバッグしつつ5時間でできるのか

言語なんて一つ深めに学べばできることなんてほぼ変わらん

系統言語なら基本文法だけみたら未経験でもすぐかける。でも一々調べる時間がかかる。FWも同じ

あとコードエンティティ設計の質の差はめちゃくちゃでかい

後の改修に要する工数が5倍くらいは普通に変わったりする

2019-04-29

コンビニATM平成元年バグ調査報告めっちゃ気になる

に変換する際の考慮が、とかざっくりした説明じゃなく詳細に聞きたい

なんならコード読みたい

と書いてみて職業病だなと思った

ソースコード公開したらゴールデンウイークですることがないプログラマー有志がデバッグしてくれそう

2019-04-20

anond:20190420191911

MsgBoxデバッグしか残された道がないのか……

その環境ちゃんと異常であると気づけるなら転職も手だと思うがな

2019-04-15

素人プログラマーを目指すのは止めたほうがいい

まず、素人プログラマーだと思っている人はプログラマーではなくゴミカスである

コンパイルが通る・自分で想定したデータがなんとか処理できる程度の人間プログラマーとはみなされない。

だいたい100人中99人がこのレベル給料はまぐれ当たりだと高いことがあるが、だいたい安く長時間労働休みがない。

プログラマー100人中1人のレベルは凡人。自分で作ったプログラムデバッグが出来る程度。

優秀と言えるのは1万人に1人くらい。しかし、レベルを維持し続けるには毎日勉強が欠かせない。

勉強止めれば即座に脱落する。

そして他の職業なら現役引退したら後進の指導かい役割があるが、プログラマーにはそれがない。

どんどん新しい言語や新しい考え方が出てくるので、それについていけなくて脱落した者が教師役になれるわけがない。

プログラマーに向いているのは、中学高校時代からバリバリプログラムを書いていて、新しい言語を学ぶのではなく、自分で新しい言語を作り出すような人だけだ。

2019-04-14

アプリログユースケースが知りたい

ログとはここでは、特にprintf()やロギングライブラリを使いアプリに仕込まれた明示的な出力とする。

サーバーサイドのログ必要だと分かる。

攻撃来てるかとか気付けるし、ビッグデータとしてゴニョゴニョ解析できるし。知らんけど。

でもアプリログってどう使えばいいの?

バグが起きた時とか、基本的再現手順を元にデバッガーのブレイクポイントとか使うだけで、ログは実際全然見てない。

あとネットワーク解析ソフトと、アプリに埋め込む系のデバッグツールあれば十分って感じ?

役立つログなんて、デバッガーの調子が悪い時にコミットしないものを一瞬入れるくらいかなぁ?

バグが起きた時はQAとかから再現手順と一緒にコンソール出力も飛んでくる。

その中で例外出力は有用なことが多いんだけど、それはハンドリングされなかったのが出てるだけ。

ロギングライブラリを使って何段階もログレベル分けてやって得られたものがあまりないなあって最近思う。

2019-04-05

世間的には同じSIerといわれる目立つ企業の話を書く

anond:20190326233147

に触発されて似たような記事を書く。

おそらく世間的には元増田SIerといわれる某目立つ会社の話をしよう。

この目立つ会社世間的には同じと見られているようだけど、意外と過ごしやす場所もある。

あくまで半径5m以内の話であって、もちろん環境の悪いところも結構ある。

開発環境普通

8GB i5のSurface Proとi7 16GBの開発用PCを使っている。営業メインの人はシンクライアントのみらしいが、開発部署なら

これぐらいは「頼めば」くれる。自動的にくれるわけではないのでそのへんは流行りのWeb系に比べると微妙かもしれない。

Windowsなのがクソといわれるかもしれないけどアルゴリズム関係の開発なので正直それほどこまってはいない。

Ubuntu環境必要場合は社内クラウドインスタンス立てるのも自由。また社員自由に使えるOpenStackクラウドとか

Slack風のチャットシステムGitLabもある。

上環境も普通

流石にアーロンチェアは買ってくれないが椅子はイトーキの5万円クラスのを支給される。机は個室やパーティションはくれないが

普通事務である

事務環境はだめ

流石に電話会議を自席でエンジニアが全員やるなんて光景は見たことない。

が、イヤホン音楽聞いてる人は基本的にいない。怒られはしないと思うのだが、雰囲気的に不可。

あとしょっちゅうしかけてくる人が多いのは結構うざい。

評価制度の納得感はない

完全に上司に気に入られるかどうかにかかっている。

古い方法へのこだわりはない

開発基準はあるが、「ちゃんと開発できる実力があるのならば」自由に開発できる。いつもチケット駆動で開発して

ユニットテストコードと同時に書いているが怒られたことはない。

ユニットテストコードと同時に書いて怒られる」という言葉意味がわからない人に説明すると、

SIerではユニットテストでN件以上バグが出ないと品質が悪いとみなされ、バグが出るまで延々とデバッグさせられる、

という文化がある。そのため、ユニットテストコードを同時に書いた場合ユニットテストの摘出バグ件数が0件と

認定されてしまい、追加でバグが出るまでひたすらデバッグさせられるという恐れがあるのだ。

ただそのようなプロジェクトは単にPL/PM無能なだけであり、最近ではそういう人は淘汰されてきた。

新しい方法技術の導入の難しさ

少なくとも開発部署として新しい導入の壁はほぼない。本人が開発できるのなら新しい技術でもどんどん使えという感じである

ただし、間接部署がとても足を引っ張る傾向がある。特に社内情シスは糞中の糞で、フリーソフトの導入ですら

1週間コース手続き強要してくる。MSDNライセンスを開発で購入しても、MSDNからダウンロードしたVisual Studio

情シスに無断でインストールしようものなら目の色を変えて説教しに来る。

残業時間評価

先程評価制度は気に入られるかどうか、という話をしたが、気に入られるかどうかに残業時間は大いに関係がある。

まり残業時間評価に直結する。なので私は去年度の月平均残業時間は-10時間程度である

何を言っているのか分からないという人もいるだろう。つまり、毎月の残業時間が60時間を超えるような人は

評価が下がるのだ。残業時間が60時間や80時間を超える場合上司幹部承認というとてもめんどくさい作業

しなければならなくなる。そんなのを毎月やってしまうような部下は当然だが評価は低い。

ちなみに残業は下命だからそれはおかしいという人もいるかも知れない。しかし、その目立つ会社はほぼすべての社員

裁量労働制採用しており、残業するかしないかはすべて個人裁量なのである

また当然だが残業代なんてもの存在せず、(たとえその月の残業時間が-50時間であろうとも)数十時間分の残業代相当が固定で支払われる。

スキル無関係の異動

業績のよい部署であればそれなりにやりたいことをやらしてくれるし、海外異動も基本は本人希望による。

ただし、業績が悪いところが解散するために徐々に人を無関係のところに放り出す、というのはよくある。

外資なら部署ごと売り払われることを思うとまだマシなのではないかとは思う。

社内技術への関心のなさ

社内でしか使われてない技術はみんな嫌いである。もちろんプロプライエタリソフトウェア製品をいくつか作ってはいるが、

出来が悪いものはことごとく嫌われている。その結果、糞アプリを量産していた部署の業績が悪くなったと

聞くが知ったことではない。余談ではあるがGitが使えないのは論外だし、SIerの標準言語であるJavaとその周辺技術は当然として、

若手はだいたいPythonの基本は一通りマスターしている。分析チームではそれに加え基本的Python分析ライブラリ

の使い方は大体マスターしているようである。40↑のおっさん連中は流石にそこまでではないが。

なんちゃってフレックス

コアタイム10から15時ぐらいである。そのため、私は12時ぐらいに出社している。

何をいっているのかわからないと思うが、コアタイム適用されるのは入社2年目までで、それ以降は

裁量労働制になるためコアタイムすら関係なくなるのである。ちなみに退社は19時ぐらいである。

リモートワークは予定さえあいていれば自由可能であるわたしは自宅にいることが結構ある。

人が均質的だがたまにすごいのがいる

尊敬できる人が少ないのはある。ただしたまにCVPRに通してる研究員や、現代的なReactのWebさらっと書いてしまうような

フロントエンド技術者、数千ノード分散システム開発者、競プロバリバリやってる人などを100人に1人ぐらいの割合ですごいのはいる。

未来のほの暗さ

これはイケイケのWeb企業でなければどこでも似たような感じなのではないかと思う。今の年収40歳手前で諸々込み1100万程度であるが、

かなりITバブル的な要素が多く、来年ぐらいまでは良いかと思うけど20201年以降はガクッと下がる可能性は高い。

転職可能

これだけ見るとSIerとしてはだいぶ恵まれいるかもしれないが、それでもやはり転職してしまう人が増えてきたのは確かである

今はITエンジニアバブルなこともあり、私と似たようなスキルの人では最高1500万のオファー結構あるときく。

大抵は1200万ぐらいでメガベンチャーあたりに行く人が多いらしいのだが、やはり年収と言うよりも

足を引っ張らない間接部署や、マネジメント業務なしの開発に集中できる環境を求めて出ていくようである

もちろんこの目立つ会社では、事務ソフトOfficeOutlookであるし、社内システムもクソで

MacBookなんて夢のまた夢だし、社内Proxyにいじめられる環境ではあるのだが労働時間の半分以上は開発に当てられており

残業時間マイナス年収もそこそこということを考えるとあまり転職モチベーションが沸かない。

一方で、一回ぐらい転職経験しないとスキル的にだめになってしまうのではないかという懸念はかなりあるので、

周りに転職者が出るたびに少し焦りがあるのも事実である

2019-03-25

みんなは身体デバッグしてる?

昨日久々にあの胃痛が来た

22時から5時まで右脇腹(胃?)がすげー痛くて

病院で処方されたエチゾラム(?)を大量に飲んで、案の定全然効かなくて

風呂冷水と温水を交互に浴びながら般若心経を唱えつつちんこしごいて耐えきったんだけど(耐えられていない)

今もまだ胃がじわじわ痛いんだけど

 

まあそれは置いといて

胃痛?の再現ができた気がする

 

1.炭水化物系を暴食する(暴食と言っても3食普通に食べただけなんだけど)

2.胃痛を恐れて下剤を飲む(コーラック

3.翌日スッキリする

4.安心して飯を食う

 

これで胃痛再現できると思う

あとどうにもセブンイレブン卵焼きが怪しい気もしてる

 

他に再現できるのは、2週間以上の激務(1日14時間くらい働く)を終えて休んで3日目、風邪、季節の移り変わり、その他のストレス帰省あたり

俺の身体再現性がなさすぎる、バグるにしてももっとちゃんと動け、再現しないと原因がわからないだろう

もうこれ12年目くらいだぞ

 

だめだ、薬の影響でまだ頭が働いてない

2019-02-24

もっと有意義時間の過ごし方

それは、何もしないことだ。

最近やっと分かってきたんだ。

社会的生物としてはそれは×印をもらう行動のように思えるが、

それ以前に人間という生物として自分のことを捉えなきゃいけなかったんだ。

何もせず過ごす時間は何よりも大切で、有意義で、生物の基礎として譲ってはならない時間だったんだ。

他の哺乳類霊長類を見てみろ。彼らは圧倒的に、何もしていない時間が長い。そこに気づきを得るべきだ。

動物人間は違う、などという考え方はただの驕り高ぶりにすぎない。

何もしない時間のことを休息と呼ぶなら、睡眠も似たような文脈で語られることがあるが、それとは別だ。

十分な睡眠も当然、何よりも死守すべき時間のうちの一つではある。

脳のデフラグタイムである睡眠大事だが、それをハードウェアデバッグとするならば、

覚醒時における何もしない時間は、ソフトウェアデバッグだ。

別に瞑想というほど作法にこだわる必要はない。

何もしないでいられるほど、日常タスクやら何やらに追われずに済む時間

それがあって始めて、人間精神は強固な安定を得られる。

精神の安定は、何もしない時間きっかけに始まる自省によってもたらされると考えられる。

自省を「する」という感覚ではなく、ぼーっとすることが自省に「なる」のだ。

自省というと説教臭い印象が出てしまうが、言うなれば自分輪郭を正しく認識するための時間だ。

世界自分境界線キャリブレーションする、ということだ。

そういう機会を失ったまま毎日をすごし、それを何年かつづけると、人間は壊れる。

たいてい肉体よりも先に精神が壊れ、最終的には自殺へ向かうように脳が動き出す。

思うに、鬱になった時点でやっと何もしない時間を得られても、ほとんど手遅れなのだ

不適切コードの上に不適切コードを何重にも重ねたスパゲッティコードが、

致命的なエラーを吐きはじめた時にやっと手直しを始めようと思っても、ほぼ諦めざるを得ないレベルに困難なのと同じなのだ

これは、休日にしっかり休息をとる、という話ではない。

おそらく、睡眠と同じように毎日必要時間なのだ野生動物のように。

1日に何分、あるいは何時間、どれくらい必要かは分からないが、長ければ長いほどいいだろう。

これ以上何もせずにいられない、と自発的に動き出す気になるまでは、ぼーっとするべきだ。

これは個人的体感なのだが、睡眠場合、前日にたくさんの経験をした密度の濃い日ほど、多くの睡眠時間必要になる。

それと同じで、たくさんの情動を抱える人、精神が揺さぶられた日ほど、多くの何もしない時間必要になるのではないか

その点でいうと、このサイトに書き込んだり閲覧したりという行為は、人によるがいたずらに情動を激しくする行為と言っても過言ではない。

増田を利用するのなら、同時にぼーっとする時間も摂らねばならないと考えられる。

2019-02-03

WEB開発がしんどい

業務システム屋勤務。

最近WEB系の開発作業がすごく嫌になってきた。

ストレスたまる

もともと今の会社ではVB.NETによるWindowsFormの案件が主流だった。

そんな中WEB割合も増えてきた。

本当はASP.NET MVCJavaでやりたいけど、上の事情によりPHPでやってる。

本来オーバーロードがないこと、LINQに代わるものがない(仕方無くGINQ使ってるけど

クエリ構文などなくFunction地獄になる)のがつらい。

それでもまぁ、サーバーサイドのロジックゴリゴリするのは楽しい

問題ViewHTML)だ。Smartyテンプレート飛んだり、CSSに飛んだり、JavaScriptファイルに飛んだり

しないといけない。IDE上で新たなエディタタブが増えるたびに嫌になる。それはNetBeans使おうが、

PHPStorm使おうが同じ。

自分が集中したいドキュメントと、デバッグ過程で開いちゃうどーでも良いドキュメントが、

とにかくごっちゃになって開かれているのがつらい。

俺が集中したいソースファイルのタブだけ、特定場所で開いてくれたら良いのに。

フォルダでもファイルでも開かれまくっている状態が大嫌い。

最近PHPファイル開くのはOKだがその次の流れでViewテンプレート開かないといけないとき

躊躇するようになった。急に世界観変わるのが嫌。Viewなんてどーでも良いじゃん。

なんでGUIなんかにこだわるんだよ、ってのが正直なところ。言えないけど。

2019-02-02

anond:20190202154613

(仮)とかにしてほしい

デバッグなのか本番なのかわからなくなるし

2019-01-29

Land of Lisp読み終わった

一周目は軽く読み流し、二周目にコードを書きながらしっかり読んだ。2週間かかった。

これに手を付ける前のLisp歴は1週間。ネットLisp入門読んだ程度。

オライリーの本にあるまじきファンキーな表紙なだけでなく、中身もジワる漫画イラストがちょくちょくある。

にもかかわらず内容は恐ろしく難しかった。

読んでいて素晴らしい技術書だと絶賛されているのがわかったし私もそう思うが

Lispを学ぶのに一冊目の本としては適さないと思った。

一冊目の本は機能解説に特化すべきだ。

ソケット通信ゲーム木、ミニマックス法によるAI実装など出てきて

それを今学習中の未知のプログラミング言語解説されるので二重の複雑さ・苦しみになっていた。

とは言っても他にLispの本なんてないし、これをやるしかないのだろう。

2019-01-19

研究で結果が出なくて、どうすればいいかからなくなった時

PCの中を整理してたら、なかなかよい自分メモを発掘したので、ここに記します。

1. 簡単で具体的な例を実装することを目指す

  結果を予想できるような入力モデル、設定値にして、予想通りの結果を得ることを目指す。

  設定値は極端な例(0とか)で良い。

2. 結果を極力可視化する

  シュミレーションの結果や計算プロセスデバッグで追わないで、グラフ可視化する。

  見れたらわかりやすいな、と思うことは全て可視化する。手間を惜しまない。

3. 極端な例を実施してみる

  入力値がとても大きな値や極端に小さな値、0等の極端な値を入れてみる。

  結果が分析やすくなる。

4. 上記PPTにまとめて、人に見てもらう

  人に説明しようとすると、順序立てて、論理展開に穴がないように考え直すことになる。

  また、内容を知らない人に対しても理解やすいように、わかりやすい図を作ることになる。

  上記プロセスで、自分がうまく説明出来ない点があることに気づいたり、何か見落としていた

  視点発見することができる。

  人にアドバイスをもらうことで、自分が思いつかなかった点を指摘されることがある。

  更に大事なのは、人に見せることで、自分が(無意識のうちに)目を背けていた

  問題を改めて指摘されることがある。その問題に腰を据えて(覚悟を決めて)取り組む

  ように腹をくくることになる。

2019-01-07

anond:20190107104436

ステップ実行の結果表示って結構めんどくさいんだよ

制御構造をきちんと理解していることが前提だし

初心者フレンドリーではないので避けられがち

変数表示デバッグのほうがまだなんぼか素直

どちらかというと変数表示デバッグの次の道筋がないことが問題

2018-12-29

現場の他社の人たち、みんな口が達者で

さすがお客さんの会社系列だけあって、教育もしっかりしてんだろうな〜とか関心してた

けど、バグをけっこう出してた

バグ自体はまぁ、テストで出るものだとは思うが

プログラムコメントデバッグログ出力もきれいに削ったものだった

DB周りの処理やら他機能連携やら、異常としかさな

複雑な機能なのにこれでよく単体テストやれたなと思った

設計書で求められているログは出力している、とは言っていたが

そう思うとうちの会社の同僚はインターフェース周りの文書の食い違いに実装前に気づいて確認取ってたり

DB周りのエラーログを出力するようフレームワークに組み込んでたりと

実装周りではい仕事してるなと思った

トークはうまくない人が多いけど

2018-12-24

IT業界から足を洗って

たった3年で4社転職

ずっと自分が異常だと思ってた。

・良くわからんシステム保守

・ころころ変わる仕事内容。

メモリ2Gしかない開発環境

いくら家で勉強しても、会社ではVB6だったりJava6ぐらいで作られたシステム保守バグ探し。

IDEは使えずサクラエディタ

デバッグなんて動かすだけ15分も掛かる(昔の2時間とかよりはましか)

勉強すればするほど、現状の不便さがわかり辛い。それでも変えることはできない。

でもみんな平気な顔してやってるんだ。

誰も技術の話なんてしないどころか、日常会話ですらしにくい人たちばかり。

もうだめだ、と思って今はバイト転々としている。

だけどそれが正解だった気がする。

バイトだけど普通に仕事の合間合間で下らん会話できて、

挨拶だって明るく返してくれる。

バイトから自宅にいる時間は長いおかげで、好きなIDE言語、高性能なPC作業ができる。

IT業界にはもう関わりたくない。

全部がそうではないとわかっていても、もうこれ以上正社員になって辞表を出すのは疲れた

でも、プログラミングが好きだからできればスキルを上げていきたい。

今はニートで、優秀なプログラマーでもないから将来は不安だが、

いつか仕事IT以外で、風通しの良い職場で働けて家でプログラミングができればいいか

がんばるぞぉ

2018-12-18

anond:20181218135753

他人の書いたテストってもはやただのオブジェだよね

テストは素晴らしい論調がまだ理解できない

 

printデバッグに毛が生えた程度に便利」っていうのは理解できる

使い捨てテストコード

2018-12-11

Beep音の思いで

古いPC対応アプリケーション製作中、Beep音を出力する必要に迫られた。

アスキーコード0x07を出力するだけなのだが、鳴らない。

1発じゃ短すぎてならないのかと思って、何発も出力してみたが鳴らない。

デバッグがここで止まってしまった。

幾らソース見直してみても、理論的に間違っているところは勿論、エラーが見つからない。

サウンドカードインストールされていないPCだが、Beep音だけは出力できる仕様であることは確認済みだ。

暫くすると、しょうがいかBeep音無し、メッセージのみで良い事になってしまった。

それでこのアプリ製作は終了した。

ハードウェアパフォーマンスの低さにソフトウェア仕様を合わせた形になった。

とても悔しかった。

恐らく、なんでもないちょっとした使い方の問題のはずなのだが、どうしても解決できない。

その時はハードウェアの不良や故障は考える余地はなかった。

月日は経ち、古いPCの事は忘れてしまっていたのだが、或る時中古ショップでそれと同等のPCを見かけた。

それを見て愕然とした。

Beep音の音量を調整するボリュームつまみ発見たからだ。

フレームの端の方に小さなボリュームつまみが格納されていた。

ギザ十の様な、ローレット加工された円筒形の一部だけが露出されたつまみが、

外部からは見えづらい位置に取り付けられている。

「これが有ったのかー!?

きっとあの時PCは、「ボリュームゼロで鳴り続けてるんだってばー」と叫び続けていたに違いない。

今更どうにもならない、ハードウェア仕様もっと確認しておくべきだった。

2018-11-29

anond:20181129152300

ローカルにXAMP入れて、Xdebug入れて自前でデバッグ環境とか作れへんの?<PHP

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん