  |
はてなキーワード: エラーメッセージとは
運用監視の現場で週末も心休まらない皆さんこんばんは。一人運用チームです。
さて、世間ではDevOpsだのイケてるクラウド監視ツールだの楽しそうですが、そうでない人もいますよね。
もちろん、「運用チーム（実態は俺1人）」なんてのは、ペイグレードに応じた責任感で粛々と業務を進めて理不尽には応じないのがプロフェッショナルな態度ですが、
お銭を稼がなければ生きていけないのも渡世の世知辛いトコロです。
これから金を生むんだ！という強烈な人間が金を引っ張ってこない限り、コスパの悪いサービスにリソースは割り振られません。
つまり、今もし運用監視体制が限界ギリギリで踏ん張っている場合、拡充される可能性はありません。諦めましょう。
今回のみずほ銀行の調査報告書（2021年6月15日発行分）p114-p116におけるヒアリング結果が悲哀に満ちているのも当然と言えるでしょう。
教訓は、「維持メンテの人員が不足したら、それ以上増えない」というものですね。
維持されている（ように外部から見える）場合、余剰人員は不要なコストです。
さて、みずほ銀行の調査報告書を読むと、今回大ごとになっている「通帳の取り込み」というのは何度か起きていますが、改善されていません。
まあ、やりたくないよね、「障害が起きた時の顧客影響を抑える」なんて後ろ向きな投資。
なお、盛大な怒られが発生した結果、再発防止策として、今回の通帳取り込み5244件のうち4915件をなくせる仕様変更が入りました。
直せないのではないのです。直さないのです。
教訓は、「障害が発生しても、予算を握ってる人に被害が及ばない限り、リソースは降ってこない」というものですね。
過ぎたことは過ぎたこと。いま維持メンテがギリギリのところに新たにリソースが投入されることは基本的にありません。
外圧があれば別ですが。
さて、ここまででわかる通り、いま1人運用やそれに近い運用をしている皆さんに、追加人員は来ません。
リソースは降ってきません。予算は通りませんし、人員は増えませんし、なんなら残業代も出ません。
もうわかりますね？障害は握りつぶしましょう。出しても一つも良いことないんですから。
慢性的に時間がない皆さんに朗報です。実は時間を生む画期的なテクニックがあります。
業務について最初に、毎日1時間を「斧を研ぐ時間」にするのです。
大丈夫分かっています。今あふれんばかりに仕事があって実際あふれているんでしょう？
どうせあふれるんです。あふれさせましょう。どうせ怒られるなら「仕事」したいじゃないですか。
WARNINGやERRORまみれのログが定常的に出ている状態は、たいへんよろしくないです。
握りつぶしましょう。
「そのエラーは概ねもっと深刻なエラーが吐かれるまでは気にしなくて良いヤツ」みたいなのがあるでしょう？
消し去りましょう。痕跡すら残さずに。
そのために、運用監視用のログが必要なら、生成しましょう。その生成途中で握りつぶせば良いのです。
「ドラえも～ん、大量にエラーが出たら処理しきれないよ～」「のび太君それ全部処理するの？」「え？」「え？」
当たり前のことなんですが、人間には概ね4本以下の手しかありません。俺は2本派です。
運用チームの対応者が一人の場合、対応できる時間当たりの処理能力には上限があります。人間はオートスケールしないんで、当たり前ですね。
つまり、「同じようなエラーで同じような処理をしないといけないが、違うエラーメッセージ」というのは、無意味です。
さっき、自分が理解ってるエラーを握りつぶすことを日課にしましたね？
次の段階です。対応できるエラーだけ残して握りつぶしましょう。
もちろん、裏では垂れ流しで大量のエラーログは取っておく必要はあります。見るエラーは一つで良いはずです。だってまずそれ対応するんだもの。
例えば、1人の時に100件のエラーが出ても、3人の時に6000件のエラーが出ても、処理できないことに変わりはありません。
つまり、それは「記録には残すエラー」ですが「対応のトリガーにするエラーメッセージ」じゃ無いんです。
例えば、幸せなことにショートメッセージやメールに自動発砲できる場合、初手だけ発砲して残りは握りつぶしましょう。
飛行機や宇宙船で機長が言うでしょう？事故が起きてアラーム鳴ってたら、アラームを切れって。
アラームは気が付かないと困るからワーワー言うんであって、処理してる最中は邪魔なだけです。
握りつぶしましょう。
多少手荒でも良いんです。エラー即再起動みたいな乱暴な奴でもオッケーです。
思い出してください。リソースは無く、対応するのはあなただけ、維持管理出来て当たり前。
どうせクレームの電話がかかってくるなら、一人一人に真摯に向き合って丁寧に応対するのも良いかもしれません。
身命を賭してクレームに寄り添って慚愧に堪えぬその思いを真剣に伝えましょう。
その間に、システムは自動的に再起動し、他のクレームの電話は保留音を聞くことに飽きてきます。
慣れてくると、鼻をほじりながら「誠に申し訳ございません、今誠心誠意全力で復旧に」と喋りながらチャートを引っ張り出して手順を追えるようになります。
復旧手順RTAチャートの作り方は、珍しく潰しの効く能力になるので磨きましょう。
しっかりとしたチャート、常にチャートを見直す向上心、日々の走り込み、本番での平常心。
出てきたモグラを叩くのではないのです。モグラの出現順序を覚え、練習し、効率良く叩くのです。
さて、最近も陰謀が話題になりましたが、情報を知るものが増えれば握りつぶすことは難しくなります。
人を減らしましょう。
レポートラインは一本に絞り、その障害が起きたことになると給料が下がるタイプを相手に連絡を取りましょう。
うっかりミスからメールのCCから落とすのでも、手順書を作ったときに気が付いたら項目が無くなっていたのでも問題ありません。
残念ながら、その時不思議なことが起こって、連絡先が増えることもあるかもしれませんが、そういう時も諦めましょう。
出来ることは変わりません。
みずほ銀行の場合、A2以下の障害ランクの場合、頭取は別にニュースで初めて情報を知っても良いのです。
システム障害というから、なんか大変なことになるのです。インシデントだの障害だのは無くしましょう。
それは「予定されていた手順」なのです。
納品されたハードウェアには不備があり、雷は落ちてコンセントまで到達し、ケーブルは間違えて刺さり、ココしかないというタイミングで停電になります。
ただでさえ維持メンテの人員が足りてないのに追加機能や新規バッチが走ったりすることもあるでしょう。
チャートです。RTAチャートです。復旧RTAチャートを作るのです。
そのチャートには不足しかないかもしれません。ハードウェア故障→上司に電話、停電→上司に電話、みたいなチャートもよくあることです。電話しましょう。
それは障害ではありません。事前に探しておいたルートを走る競技です。
李下に冠を正さず。
例えカンムリが傾いてると分かっていても、問題になりそうな場所で手をあげてはいけないのです。
繰り返しになりますが、ペイグレードに応じた態度がプロフェッショナルには求められるのですが、お給料はいただきたい。
必要なのは、まず個別最適化です。あなたの仕事を減らしましょう。
余裕が生まれたら「この仕様は修正した方が」とか「週末にバッチあてるなら前の週末に復旧訓練をしましょう」とか言い出せば良いのです。
まあ、次にみずほ銀行が日曜に新規バッチを当てるときに、その2週間前の日曜に頭取を含んだS懸念の緊急対策本部を立てた訓練をするかっていうと、しないんじゃないかな。
つまり、そういうことです。
我々は、日々斧を研ぐ時間を作り、RTAチャートの更新を怠らないようにしましょう。
https://anond.hatelabo.jp/20210617075257
上がってるような基本（元増田に上がってるやつの倍ぐらい）が全部立ち上げからできて
2〜3個プロジェクト経験したらテックリードの素養が既に身についてそう。
プロジェクト的にもどっちかが弱いと
Rails/DjangoにjQuery+Bootstrapみたいな構成や
Amplify/FirebaseにVue/Reactみたいな構成も全然あるので
面接はなんとか抜けてもらうとして、
チーム開発での最低限の目標としては、
成果物から、指導、学習コスト、レビューコスト、技術的負債、マネジメントコストを引いた分が正になっていれば
ひとまず「チームに居ていい人」と見なされそう。
チーム的に良くても、経営層にそれで許されるかはわからんのでその辺の立ち回りも上手いことやるとして、
一旦は、正の生産性を目指してほしい。
以後、ブコメで誰一人一ヶ月でできるって言ってなくて笑うので、
一ヶ月というのは無視して、三〜六ヶ月程度をイメージしつつ書いていく。
似たような言語なのでどっちからやってもいいし、両方同時にやってもいい。
どっちかしかやらないならJavascriptがおすすめ。後ででてくる、Flaskは適当にExpressとかに置き換える
現場だとほぼTypescriptなので、Javascriptはある程度慣れたらTypescriptに移行したほうがいい。
どちらも、Python2とES2015以前の記法というレガシーがネット上に転がってるので参考にしないように注意。
・一貫性があって
・正しい書き方がされた
お手本プロジェクトをなにか(githubや書籍など)で手に入れて読むべき。
おそらくフレームワークに乗っかっているので並行して進めることになる。
話の流れで先にこっち
現在のコーディングのグッドプラクティス、デザインパターンはフレームワークの形をしている。
なので、ReactとVueをその思想から理解しきれれば、プログラミング言語の潮流の最先端に追いつけるはずだ。
TypescriptもVue.jsも書き方をどこまで取り入れるかが使用者の裁量に任されてるし、
開発でVueとReactのどっちを使うかはチーム次第なので、
一旦React+Typescriptでガチガチに書かれたコードプロジェクトを拾ってきて、必死で解読するのがいいと思うなー。
2割ぐらいわかった気になればチーム入ってから(React, Vueどちらだったとしても)動けそう。
パッケージとかテスト、タスク＆デプロイ辺りもこのタイミングで拾ってきたプロジェクトを使って学ぶ。
バージョン管理とコンテナの思想が優れているのは自明なので、これらはツールと見ていい。
そして、後からプロジェクトに入った人がプロジェクトの流儀に沿って使う分には難しいことはなさそう。
採用に来た人がgitとかわかってるとチーム開発経験者だなーって思うし、知らないと未経験者なんだなーって思うし、
そういう意味ではチーム開発の経験があるかどうかの試金石にはされてそう。
構築できる、ではなく、触れる程度で良さそう。
gitはプロジェクトの流儀によると書いたが、git-flowのイメージ図を理解して運用できるのがよい。
https://qiita.com/KosukeSone/items/514dd24828b485c69a05
こういうのができるんだなーって言うのを知っておいて、調べつつ書ければ十分。
あとはシェルスクリプトとかって思ったけど同様のことはPythonでもできそう。
地味にSSHでログインした先の環境だと、vimが主要なテキストエディタになるので
vimを最低限触ることだけ要りそう。もういらないかもって思ってたんだけどなー。
→ ファイル開いて入力モードに切り替えて書き込んで保存して終了
細かく書いたが、LPIC-1の範囲がほどよくまとまっているのでそっちを参照するとよい。
これが意図なら
この辺の機能を持った小規模Webアプリを作ってHerokuでデプロイすれば一旦完成とみなしてよさそう。
コード書き写しただけにならないようには注意しつつだけど、長く見て5人日ぐらい？
慣れると1日あればいけると思う。
フレームワークもなんでもいい。
Djangoとかでも各コンポーネントがどんな働き方してるか程度はわかるだろうしそれで十分。
余力があれば複数個触ってみたり、人から勧められたらそっちでも。
最近はサーバーレス&NoSQLが流行ってるのでFirebaseとかもやればいいと思う。
に尽きる。
計算量を気にしなかったせいで線形検索メソッドとfor文を組み合わせて
それらに対して分散や非同期処理で解消しようとするとか、
ちょっとでもアルゴリズムを触った人ならアホらしいなって思うような行為を
計算量を意識するだけなら、AtCoderのABCのC〜D問題辺りが解ければ十分。
有名な脆弱性や攻撃手法は、ほとんどフレームワーク等で解決手段が用意されている
のでアドリブをせずに正しい書き方でやれば良い。
開発現場でもセキュリティリスクがある箇所を1から自前で実装することを経験が浅い者にはやらせないので、
ただただ、フレームワークが正しいとしているやり方をなぞるのが良い。
開発の勉強のやり方としては、
・正しいコード見本を手に入れること
この辺りの習慣があればやってけんのかな、
その他、チーム開発って面では
TeamGeek（人間性）とかインプットしておくと共通言語が増えて嬉しい。
この方向で進めてけば、その途中で正の生産性≒足引っ張らないぐらいになれるので、
そしたらやってけるんちゃうーって感じ。
IT業界じゃない人にとって「エラーが発生したとき画面に出ている内容を他人に伝える」は難しいことなのか - Togetter
https://togetter.com/li/1714921
このエントリーについてすこし自分でまとめておきたいと思い、増田に残すことにした。これは自分達で開発したプロダクト、サービスについての話なので｢windowsが起動しなくなったんだけど｣といった雑多な問い合わせを受けるITSM部などには当てはまらないと思う。
→ コメントで逆張りだと言われてしまったが、私の携わったプロジェクトでは実際にやっていた（半年かけてエラー出力処理を見直した）ことだ。
まず前提は利用者は困っている。
あなたが利用者のITリテラシーの低さに嘆く以上にシステムを使えないことに困っていることを理解しなくてはいけない。これは心構え。
無償のボランティアではないと思う。偉そうな態度をとりながら対価を受けることはできない。これも心構え。
自社内のサービスであろうと社内システムに予算を計上してることを忘れてはいけない。これも心構え。
日本語で提供しているシステムが突然｢ERR:DB CONNECION ERROR ｣等と言い出したら、利用者はまず｢金を払ったシステムが作りかけか？｣と疑う。もし動作ログと同じものを表示しているのなら欠陥だ。
システム全体が使えないのか、そのアカウントだけなのか、それによって利用者は対応を変える。｢一時的にセッションが切断されました、再度ログインしてください｣と｢データベースの接続が失敗しました、システム管理者に利用してください｣ではまったく異なる。エラーメッセージが表示される時点でそれをリカバリする業務が走ることを忘れてはならない。
ひとつ上の例と被る。利用者が自力でリカバリできればあなたへの問い合わせを減らすことができる。
利用者はシステムがどんなときに利用できないかを気にする。エラーメッセージはその検索キーになる。
やるべきことをやってないことを利用者の責任にしてはいけない。やっていなければ問合せ窓口が吸収するしかない。問合せ窓口が吸収できなければ開発者が吸収することになる。これは成果物の責任を持つということ。
今すぐ廃業すべきだろう。
イキりまくってるコンサルにクソムカついたという話が出てたので、そのついでに自分の話もしてみたい。
今から数年前、自分の担当していた企業の業績が急激に悪化し、再建支援(これは表向きの理由、真の目的は債権保全)のため自分がそこへ出向することとなった。
年商数百億円規模の会社で銀行借入も百億円近くある企業なので、管理体制はそれなりに構築されているのだろう、そう思っていたのだが実際には酷い有り様であった。
社内の情報共有は全く成されていない、損益管理も決算を締めてみるまで分からない(月次で試算表は作っているが、進行基準ではなく完成基準なので全く参考にならない)
資金繰りの管理すら行われていない、「月末の不足分は銀行の当座借入枠で調整」という中小企業でよくある典型的パターンとなっていた。
「このままではとても自力再建など出来ない」と気づいた私は、危機感も能力も全くないプロパー社員を指導しながら、社内管理体制の構築に努めた。
出向から1年が経過し、それなりに社内の管理体制が整い、月次の損益管理や資金繰り管理もそれなりに形になってきた。
その結果、「決算を締めてみて大赤字が判明する」という幼稚園児レベルから「決算を締める前に大赤字だと分かる」という小学校低学年レベルへ進化することが出来た。
そして私は遅まきながらようやく悟ることが出来た。
今私がやっていることは高血圧の人に対して「毎日血圧を測定しましょう」と言っているに過ぎないのだと。
毎日血圧を測れば高血圧だということは分かるが、測定したからといって血圧が下がるわけではない。
リアルタイムで赤字を認識しようが、決算を締めて認識しようが赤字は赤字にしかならないのだ。
ベンチからの指示は「とりあえずもう少し続投」であったが、私は「どうやったって自力再建は無理なんで、そろそろ敗戦処理を送り込んで貰えませんかね」と強く要請。
そしてここでようやく本題である「あまりイキってないコンサルの人たち」が登場することとなった。
私の想像でしかないが、所謂イキり系コンサルはIT系、システム系に多いのではないかと思う。
経営改善コンサルや事業再生コンサルと比べると、システム系コンサルは歴史が浅いのでイキり系が産まれやすい土壌でもあるのだろう。
私が一緒に仕事をすることとなった人たちは「事業再生コンサル」であり、弁護士・公認会計士・元銀行員といった顔ぶれであった。
ネット上でイキる意識高い系のコンサルと違い彼らはみな紳士的な対応であったが、逆にその丁寧さが私には慇懃無礼に見えて仕方がなかった。
彼らの登場により、私の業務についても次のステージへ進められることとなった。
プロパー社員たちに知られることが無いよう、一日中別室でコンサルたちと事業DD、財務DDを行い企業の清算価値を査定した。
当社は3つある事業部のうち、製品製造を行っている2事業が海外との競争に晒され赤字垂れ流し状態。
しかし幸いなことに、一番規模の小さいメンテナンス事業部だけがコンスタントに黒字を計上していた。
法的整理を行い担保物件等を処理した場合、百億近くある融資のうち回収出来るのは1割未満。
一方で、大幅なリストラを行い黒字の事業部だけを新会社に移し、今後10年間で返済可能な借入を背負ってもらうとなると3割程度は回収可能。
この試算結果を受けて、経済合理性の観点からも再生は可能であると判断された。(ここで再生不可能と判断されれば破産するしか手はない)
ちなみに事業再生系のコンサルの費用は本当にアホかというくらいに高い。
各種資格保有者ばかりということもあるが、当初3ヶ月の契約で3000万円。
そしてここから半年かけて行う事業リストラ、再生計画策定、解雇された従業員の再就職支援等の費用として5000万円請求された。
(費用のほとんどが彼らの人件費であり、駄目元で値下げ交渉したところすぐに5～10％値引いてくれた。にしても利益率高すぎじゃね？)
ここまで書いていてふと思い出したのだが、そんな彼らにも少しだけこちらをイラっとさせる癖があった。
会話の中でとにかくやたらと良く分からない横文字のビジネス用語を使いたがるのである。
「リストラについては一律にやると優秀な人から抜けるリスクがあります。まずは経営陣でバイネームでリストを作成してください」
「増田さん、これだとアップルトゥアップルの比較にならないですよ」
(あっぷるあっぷる？りんごが溺れてあっぷるあっぷるなのかな…）
「スポンサー候補先とはNDA締結してExclusiveでの交渉になりますね」
彼らとの会話にときたま苛々させられながらも、Google翻訳の力を借りて再建に向けた作業は着々と進みつつあった。
法的整理と異なり私的整理は基本的には迷惑をかけるのは金融機関だけなのだが、法的拘束力が無いのでこの調整が一番難航する。
高い費用をかけてコンサルを導入する理由は、この対金融機関折衝を乗り切るためといっても過言ではない。
債権放棄額の妥当性、再生計画の蓋然性について、各金融機関を納得させるための資料作りに関しては彼らの能力は非常に高い。
まあ高いコンサル費用払ってるんだから当然といえば当然なのだが、彼らは凄まじいスピードで計画や報告書を作り続けた。
私が出向してきて3年が経過したところで、ようやく事業再生手続がひと段落した。
黒字事業と借入の一部を新会社へ移管したうえで、旧会社は銀行団が債権放棄を行ったのち清算。
1000名以上いた従業員も8割以上が解雇となり、人材引き受けの協力を得られた他企業へ転籍したり、転職支援サービスを利用して転職したりしていった。
そうして私もようやく長い任務から解き放たれ、出向元へ復帰することが決まった。
コンサル会社との契約もここで終了となったので、慰労を兼ねて私はコンサルチームのメンバーと最初で最後の飲み会へ行くこととなった。
私としては3年間という短い期間だったとはいえ、一時は同僚だった人たちの大半をリストラするという後味の悪い仕事が完結したということもあり目一杯呑みたい気分だった。
しかし残念ながらコンサルの人たちは飲み会の場ですらもスマートであり、1杯目だけはアルコールだが2杯目からは皆ソフトドリンクへ切り替えていた。
「恐らくこの後もビジネスホテルに帰って他の仕事をしたり、自己啓発したりするのだろうな」と思っていると、予想通り飲み会は開始からきっかり2時間で終了。
まだまだ飲み足りない私を残し、コンサルたちはタクシーに乗り込み帰ってしまった。
一人残されてしまった私は「憂さ晴らしにデリヘルにでも行くか」と考えた。
しかし私はすぐに反省した。リストラされ再就職先も決まっていない従業員も大勢いる。
そんな状況で呑気に風俗に行くなど道義的に許されることではない。自分よりももっと辛い状況の人は大勢いるのだ。
デリヘルに行くことは断念し、私は駅前のレンタルショップでアダルトDVDを借りることで手早く性欲を満たすこととした。
帰宅後、風呂に入ったあとでDVDを入れたのだが「このDVDは再生できません」というエラーメッセージが出てしまった。
記録面が汚れているのかな…と思いティッシュで綺麗に拭き取ってみたが、何度やっても読み取りエラーが出てしまう。
これではやむを得ない、やはり最初からこうするべきだったなと思い私はデリヘル店へと電話をかけた。
URL に `locale=ja` が含まれていると発生するようです。ブラウザの「言語設定」から日本語を削除するか、https://creators.brave.com/ からログインページにアクセスしましょう。
URL に `locale=ja` が含まれていると発生するようです。ブラウザの「言語設定」から日本語を削除してください。
クレジットカードかデビットカードを PayPal で登録・認証しましょう。
なお、現在は BAT への移行期間らしいので手続きはお早めに。
https://brave.com/ja/bap-to-bat/
https://community.brave.com/ で質問しましょう（英語）。
上記のログインエラーに該当するスレッドは https://community.brave.com/t/cant-login-first/216606 です。
決済で使ってる三井住友銀行から、ロンダリング防止の確認のためのweb提出を求められたんだが、苦痛に耐えつつ8割くらい進んだ所でエラーが出て、入力分が全部喪失してしまったので、やめてしまった。回答いただけないと利用制限とか警告書いてあるけど、無視してやる。
https://infoweb.smbc.co.jp/hojin/
以下、ダメすぎてムカついた点
https://www.iseto.co.jp/company/profile.html
なんだか歴史だけは御大層な会社に依頼して作ってるらしいけど、学生サークルのイベント参加フォームだってもっと丁寧に作るだろ。金とっていい仕事じゃないよこれ。こんなの納品されてOKだしてる銀行のIT部門も相当クソ
infoweb.smbc.co.jpが、httpからhttpsにリダイレクトする設定がされてないから、ブラウザでアドレス打ち込むときに、しっかりhttpsから打ち込まないと、目的のページにはたどり着かないってのが原因だ。スマホのときは、QRコード使ってhttpsのほうにアクセスしたからつながったってことか。
SSL使ってるちゃんとしてるはずの企業で、こんなクソサイト初めてだわ。http→httpsのリダイレクトなんてSSL対応の基本の基本なのにな…SSL対応のお仕事は会社設立以来初めてやりましたって会社なのか？こんな素人感丸出しだと、もっと重要なところでもやらかしてそうで、金預けてて大丈夫か心配になるわ。
http://infoweb.smbc.co.jp/hojin/
何事もなければ社長が死んだショックだけで終わったかもしれない。
7Payと言えばわかるだろうか。詳しくは書けないのだけど、あれと似たようなことが起きてしまった。
かなりのストレスだったと思う。ネットで調べたところ、急性心筋梗塞はストレスでも発症することがあるらしく、そこが少し引っかかってしまった。
様々な理由から現状社長の訃報を知らせるページを検索エンジンにインデックスされないようにしています。
もし心当たりのある会社があった場合でもリンクは貼らないでいただけますようよろしくお願いします。
使うのであれば、ライブラリ、フレームワーク、ミドルウェアの更新（バグ、脆弱性情報）を一生追い続ける覚悟で使ってほしい。
テスト自動化とかそういう発展的なものではなく、もっと根本的なテストについて勉強してほしい。
コードレベルのカバレッジとかそういうのではなく、「境界値分析」、「デシジョンテーブル」、「オールペア法」、「直交表」こういう物について勉強してほしい。
他にもいろんな手法はあるのだけど、上記に上げたもので1個でも知らない単語があった人は今すぐ検索してほしい。
いくら進捗が悪いからと言ってお客さんに順調などと嘘をつかないで欲しい。
遅れている理由を正直に言って（例えばテストの工数が膨れているとか）相談すればお客さんもわかってくれるかもしれない。
また、テストの質もそこまでの物が求められていないとかがわかるかもしれない。
お客さんに相談しないで工数圧縮の為にろくなテストも書かないで動いてるからいい！っていうのは危ない。
自信がない、もしくは、やったことがない・使ったことがない、などは正直に話してほしい。
もしかしたらそのせいで給料があがらなかったり、出世できなくなったりするかもしれない。
だけれど、その嘘のせいで他の誰かに負担がかかったり、他の誰かが不幸になるようなことがあってはいけないと思う。
これに関してはいろんな批判があることは覚悟している。嘘をついてでもいろんな経験をした方がいいって言う人もいると思う。
それでも、どうしても書きたかった。
別にLPIC(LinC)は持ってなくてもいい。本屋で適当に対策本をパラパラめくって、聞いたことのない単語がないレベルであればいい。
インターネットには嘘が散りばめられている。昔は本当だったけど今は嘘になっているものだってある。
一番いいのはエラーメッセージを出している物のソースコードを読むこと。二番目はドキュメントを読むこと。それでもわからない時だけ検索してほしい。
そして、その情報が誰が書いているかをよく見てほしい。書いている人が本当に信用できる、かつ、更新日付が近かったときだけそこの内容を信じてほしい。
公開リポジトリにpush/commitされているメールアドレスを収集している人がいるということ、
公開リポジトリにpush/commitされている秘密情報を収集している人がいるということ、
RDBによってはSQLのIN句に指定できる数に上限があること、
他にもいろいろあるが、1個でも知らないものがあった人は検索してみて欲しい。業界にもよるかもしれないが、本来であれば最低限知っておかなければいけない知識。
これを知らないと適切な設計、ましてや適切なコーディングすらできなくなる。
ぼくはエンジニアに向いてない
会った件数：0
これらが女性側の求めるもの以上だったときにはじめてマッチングすることができ、更に
が適切な内容だった場合のみメッセージのやり取りを開始することが出来るのですが、自分はそのハードルを越えることがほとんどできませんでした。
ちなみに、いいねを送っている女性の系統はインドア系の趣味も許容できるとプロフィールに書いてある、もしくは女性もインドア系の趣味、デート代が割り勘になっている人たちです。
友人や家族からは評判がよかったプロフィール写真なのですが、自分がいいねを送っている人たちにはあまり印象のよくない写真らしくほとんど足跡が付きませんでした。
（パソコンで作業をしている時に「こっち向いて〜」と言われたのでそっちを向いたらカメラを向けられてたので思わず笑顔になった瞬間が収められている写真です。
いろいろ試行錯誤を繰り返しているので、もしよければ「こんな写真がいいよ！」とかあれば教えてください。）
自己紹介の文章や詳細プロフィールについてもあまり印象がよくないのか、足跡がついてもほとんどがブロックされてしまいます。
後で話を広げられるように趣味は広い定義で書いているのですが、もし詳細にプロフィールに書いたほうがいいことなどあれば出来れば教えてください！
アマチュア無線やラジオを聴いています。基本的にスケルチ全開な為、特定周波数をワッチしているときには数時間ホワイトノイズのみを聴いていることもあります。（受信にはVR160を使っています。）
一応アマチュア無線の免許も持っているのですが、ハンディ機しか持っていないので電波を出すことはほとんどないです。
いつかBCLラジオを買って海外の局にベリカードを送ることが夢です。
ThinkPadのジャンク品からパーツを取って自分のThinkPadを整備したりしています。
他にも自分の開発用マシンのjournalを確認してエラーメッセージを調べてみたり、launchpadのバグ情報を確認したりしています。
いろんなWEBサイトを巡回して面白い動きや表現があれば自分用にメモしています。
また、APIに送信されている情報を見て、こういうAPIの作りもいいな〜とかもメモしています。
あとは自分用にちょっとしたツールを作成したり、言語のリファレンスを読んだり、最近はクラウドサービスのドキュメントも読んだりしています。
間違った情報や古い情報を書いているサイト、既存の脆弱性が放置されたままのサイトを撲滅させることが夢です。
どうやったら一番効率よく勝てるのかを考えています。身近なところだとパチンコの勝ち方を調べたり計算したりしています。
オーバー入賞の方法や期待値の計算など、なかなか奥が深くて楽しいです。
日本にカジノが出来たらブラックジャックでチキン・ディナーを体験してみるのが夢です。
子持ちの人、年齢が10以上離れている人にはどうせ相手にされないだろうと思ったので最初はいいねを送っていなかったのですが、
「いいねを送り返すかどうかは相手が決めることだから気にせずどんどん送った方がいいよ」とのアドバイスを友人に貰ってからは気にせずいいねを送るようにしていました。
結局そういう人たちにはいいねを送ってもブロックされたのですが。。。
マッチングアプリ、奥が深い。
