  |
はてなキーワード: エラーメッセージとは
1か月ほど前まで初代第1世代Core iのPCをほぼノーマルで使っていたが、Windowsの肥大化（*1（本増田の最後に参考webページを記載。以下同様））のせいかweb閲覧やExcel操作程度の作業でも引っかかりを覚えるようになったり、Windows11ブームに煽られてセキュリティ関連の記事を読み古いCPUには脆弱性が付き物だと知った（*2・3・4）り、あれこれあったためPCを新しくすることにした。
その際に色々な知見を得て情報の更新ができたため、日記帳兼リンク集として増田に残しておくことにした。極少数の人にしか役に立たないであろう文章だが、体験談の類として暇つぶしに読んでもらえれば幸い。ただ、過去のPC事情を懐古したりするのが目的なら、数年前にホッテントリ入りした別の記事（*5・6）を読む方が有意義かもしれない。
まず、パーツの買い方を3種類に大別して検討した。
この前段階で格安の中華製ミニPC（*7）も候補に挙げていたが、拡張の厄介さや商品到着までの時間の長さを難に感じて選択肢から外した。
今新しく自作PCを組むなら鉄板の構成だと思う。現在の相場では、M/B 13k円、Celeron 7k円、DIMM2枚組 6k円、SSD 200GB 4k円で約3万円くらいになるだろう（*8・9・10）。構成品のどれかを中古にすれば2万円台前半で抑えることもできそうだ。
しかしながら、最近まで骨董品で我慢できた身には過剰スペックになりそうだという懸念と逆張り志向のせいでRyzen APUに惹かれたためとで、この組合せは除外した。
時機を見極めて個々のパーツを買えれば、安く挙げることができる方法だろう。
だが、動作不良品・リマーク品（*11）・その他の不動品（*12）等を掴むリスクやピン折れ曲り（*13）他機器不良への対処を避けるため、この組合せも選ばなかった。
M/B・CPU・ビープスピーカー・電源があれば動作検証は可能だ（*14）。そのことは前提知識として通用してるだろうと期待し、ジャンクな出品物・者を弾けば少なくとも直ぐに判明するような不良品を掴むことは避けられるだろうと考えて、セット品を軸にパーツ調達することにした。
ただ、個別のパーツだけ欲しいと思う人が多いせいか、希望に叶う出品は少なかった。値段や特定のパーツへのこだわりは捨てて条件をだいぶ緩くしたが、それでも購入作業を終えるには結構な時間がかかった。
作業の結果以下のパーツが手に入った。これら以外にも試用して直ぐ売却したものがあるが、その分は少々の損失で済んだため、実質合計費用は25k円+10k円。
元の電源が10年以上持ったので、5年前の製品なら後5年は使えるだろうと考え、中古で済ませることにした。
参考になるまとめ記事を元に、経年による劣化が小さいと思われる、電圧と電流の波形が綺麗な製品（*15）を候補にした。5年以上前に発売された商品を1年少々しか使っていない状態良好品だと嘯く詐欺師がフリマには跋扈しているが、そういう輩を除外しても選択肢が十分にあるのは幸いだった。プラグイン電源という危険そうな製品（*16）以外に無難な選択肢が無かったのは、老害な増田には難だったが。
余談だが、電動ブロワーは電源の清掃にとても役立った（*17）。騒音が問題にならない環境の人には是非お勧めしたい。
大型のファンを備えた電源ユニットをケース下部に置く組み方が主流になって久しいようだ（*18）が、冷却や静音にこだわる必要が無いのでケースは流用することにした。ただ、電源LEDがそのままでは機能しないので、オス-メスのジャンパワイヤー（デュポンケーブル）をフリマで買ってピンとコネクタをつないだ（*19）。
マザーボードについては色々調べたが、8ピンのATX 12V電源コネクタ（*20）が一般化して久しいことや、フェーズ数の増加（余談だが、I/O電圧とコア電圧が異なるデュアルボルテージは、30年近く前にモバイル版P54Cで初めて採用された）（*21・22）といった電源回りのことで特に知ることが多かった。光物（*23）はあまり興味が無いのでほぼスルーした。
RyzenもIntel Coreもどちらも魅力的だと思った（*24・25）が、結局はAMDで組むことにした。そこそこのGPUを省電力で使えることが大きかった。
メモリは多少勉強した（*26）つもりでパーツ選定に着手したが、チップセットの16Gbitチップ対応事情（*27）を全く把握していなかったため、相性問題にぶつかって最初に購入したパーツセットを買換えることになった。容量について言うと、16GBだとたまに心許なくなるが32GBだと過剰という感がある。Intelなら24GB（8+16の2枚）載せて16GB分をデュアルチャネルモードで使える（*28）ので、その点は良いなとも思う。
SATA SSDでも体感速度は悪くない（*29）という言説を見て、安く手に入ったSSDで十分と判断した。記録方式がTLCかどうかといった商品選択の時に普通ポイントになる点（*30）は、次に買換えたくなった時に気にかけようと思う。
光学ドライブも電源ユニットと同様、本来は5年程度で買換えるべき製品とされている（*31）が、それはそれとして、電源と同様の理由で5年くらい前の中古品を探そうかと思って調べてみたら、M-DISCという規格（*32）があると知った。対応するドライブやメディアを購入すると割高だ、余計に金をかけてまで保存すべきデータはどれだけあるか、そもそも光学メディアの読み書きをする機会はどれだけあるか（*33）等、あれこれ考えた結果光学ドライブは買わないことにした。
最近は無音でPCに向かうことが専らなので、USB-DACを排除してHDMIモニタのイヤホン出力で済ませることにした。気まぐれに音楽を聴きたくなったらヘッドフォンアンプをライン出力につないで使おうと思う。
ケースと一緒に死蔵品を引っ張り出した。文字入力を業としない立場なのでキーボードは何でもどうでも良い。
マウスはクリックが利き辛くなったので放置してたが、分解修理可能（*34・35・36）だと知ったので実例（*37）を参考に簡単に清掃して使えるようにした。マウスホイールは部品交換が必要な状態（ホイールのゴム部分が、加水分解して汚れてたので重曹で洗った（*38）ら、完全に溶けてなくなってしまった）なので、そのうちAliExpressで補修品（MX300適合品ではないが、サイズが同じもの）（*39）を購入しようと思う。
初めは旧システムの入ったHDDを新しいM/Bにつないで使っていた。後で中身をSSDにクローンしようと考えたが、安物のSSDゆえガンガン書き込むことを必要以上に避けなくても良いなと思い直したので、結局新規インストールすることにした。
Raven RidgeではWindows11にアップグレードできない（*40）。だが、Windows11ではGPUが重くなりその対策が未だ無いよう（*41）なので、Windows10のままで良いということにした。
Windows7の頃はUEFIで起動しないPCがまだ一般的（*42）だった。このHDDもそういうPCに接続されてたのでフォーマットはMBRだった。CSMを有効にすればそのままで起動できるが、そうできるのは古いGPUを使っている時で現行のiGPUではたいてい無効にされる（*43・44）。CSMは頼りにせずGPTに変換して使うのが無難だ。
変換の際はWindows10のUSB起動メディアでmbr2gptを使ったが、ReAgent.xmlの更新に失敗したというエラーメッセージが出たので、回復パーテーションを弄って（「コンピュータの管理」ではドライブレターを付与できないのでdiskpartを使った）修正した（*45・46）。
Microsoftアカウントで常用していたためかライセンスの再認証を求められることも無く、上記の問題を除けばほぼすんなりと使用できた。セクターにアライメントのずれが無いかどうか（*47）も調べたが、問題無かった。
VMWare上で予行した分も含めて何回もした。セットアップを繰り返した理由は、Administratorを有効にしパスワードを設定しないままメインアカウントを標準ユーザーにしたらAdministratorにログインできなくなって（*48）詰んだり、OneDriveの動作選択画面で「このPCにのみファイルを保存する」を選択せず「次へ」移動したら戻れなくなった（ドキュメントやピクチャ等のフォルダパスをOneDriveに指定した後で、再度ローカルストレージに変更するのは割と手間になる）（*49・50）り、システムファイルを移動させようとして次節で説明するようにシステムを破壊したりしたためだ。
SSDの容量節約と書込み抑制のため、ページ、スワップ、ハイバネーションの各ファイル・OneDriveフォルダ（ただし、空フォルダにマウントしたドライブは移動先に指定できない）・ユーザプロファイルフォルダ下のドキュメント等のフォルダ・AppDataフォルダ下のRoamingフォルダとLocalフォルダの一部・テンポラリフォルダ・ストアアプリフォルダを移動（*51・52・53・54）した。Superfetchはデフォルトで良しとした（*55）。
かつては別アカウントでログインしてプロファイルフォルダを全部移動しジャンクションを貼って使うこともできたが、Windows10のあるバージョン以降でそれをするとスタートメニュー他ショートカットやストアアプリが即死する（*56）。一部のシステムファイルが変化するとメニューやアプリ全体が損壊判定されるようだ（十分な検証はしてないが、container.datやハッシュ値が名前になってるファイルを弄ると不味いように感じた）（*57）。こうなるとアカウントを消して再作成する他無くなる。ちなみにCドライブ直下のProgramDataフォルダ等を壊すともっと悲惨で、新規インストールくらいしか回復の手立てが無かった。
https://b.hatena.ne.jp/entry/1 または https://b.hatena.ne.jp/entry?eid=2（それぞれ、数字部分がeid）のような形式のurlを入力すれば、当該ブックマークエントリーにアクセスできる。
| *1 | Windows 10はバージョンアップを重ねるたびに本当に遅くなっているのか？検証結果はこんな感じ - GIGAZINE | https://gigazine.net/news/20210622-windows-10-version-slow-down/ | 4704430589992224258 |
| *2 | Googleが発見した「CPUの脆弱性」とは何なのか。ゲーマーに捧ぐ「正しく恐れる」その方法まとめ | https://www.4gamer.net/games/999/G999902/20180105085/ | 373991174 |
| *3 | AMDのプロセッサに脆弱性、セキュリティ企業が情報公開--懐疑的な見方も - CNET Japan | https://japan.cnet.com/article/35116106/ | 360332677 |
| *4 | インテルとARMのCPUに脆弱性「Spectre-v2」の悪夢再び、新たな攻撃手法 | TECH+ | https://news.mynavi.jp/techplus/article/20220312-2290634/ | 4716634065497432514 |
| *5 | 「Sandy Bridgeおじさん」とは何か？ : 因画応報 | http://ingaoho.ldblog.jp/archives/4916067.html | 362560793 |
| *6 | ありがとう鼻毛鯖 8年使った鼻毛鯖をついに買い替えました | 日本霜降社 | https://nihonsoukou.com/20181123/1827 | 4665750545042615426 |
| *7 | 2万円の超格安パソコン「GREEN G2」値下げ、高性能CPUに大容量メモリやSSD採用で仕事でもプライベートでも大活躍 | Buzzap！ | https://buzzap.jp/news/20220318-trigkey-green-g2-ultra-low-price-pc-happy-price-down-3/ | 4716943171239004674 |
| *8 | 第12世代インテル Core プロセッサー 特集 | パソコンSHOPアーク（ark） | https://www.ark-pc.co.jp/special/intel-12th-gen-core-series/ | - |
| *9 | 8GBモジュール | 2枚組 | DDR4 DIMM (288pin) | デスクトップ用 | 通販・価格/性能比較一覧 | 価格の安い順 | パソコンSHOPアーク（ark） | https://www.ark-pc.co.jp/search/?col=3&order=&p1=b21010&p2=c21050&p5=s21010&p6=w11726 | - |
| *10 | 〜256GB | M.2 | SSD | 通販・価格/性能比較一覧 | 価格の安い順 | パソコンSHOPアーク（ark） | https://www.ark-pc.co.jp/search/?col=3&order=&p1=b32020&p2=c32024&p5=s32220 | - |
| *11 | 【やじうまPC Watch】中国でIntel CPUの偽造品出回る。公式が注意を呼びかけ - PC Watch | https://pc.watch.impress.co.jp/docs/news/yajiuma/1248215.html | 4684567815854719490 |
| *12 | Lenovoに搭載されているAMD CPUにベンダーロックが設定されているせいで中古市場が混乱している - GIGAZINE | https://gigazine.net/news/20220118-lenovo-vendor-lock-amd-cpu/ | 4714151541045747810 |
| *13 | ASCII.jp：冗談ではなく目の前が真っ暗になる恐怖……ピンを曲げてしまったRyzen 9 5950Xの修復を試みる (1/3) | https://ascii.jp/elem/000/004/053/4053723/ | 4703873313928579106 |
| *14 | パソコンが起動しない場合の確認方法｜テックウインド株式会社 | https://www.tekwind.co.jp/ASU/faq/entry_31.php | 4666842797243724258 |
| *15 | 【自作PC】電源ユニットの選び方を自作経験者がガチ解説する | ちもろぐ | https://chimolog.co/bto-choose-psu/ | 367187040 |
| *16 | 何故プラグイン式PC電源ユニットのコネクタは規格統一されていないのか？ - Togetter | https://togetter.com/li/1564076 | 4688976497965880706 |
| *17 | ブロワーの選び方 | DIY工具紹介部 | https://diytool.biz/blois | 170335990 |
| *18 | “冷却の常識”を徹底検証 - AKIBA PC Hotline! | https://akiba-pc.watch.impress.co.jp/docs/dosv/662237.html | 364049132 |
| *19 | PCケースのPower LEDケーブルを3ピンから2ピンに変換した | TeraDas | https://www.teradas.net/archives/16603/ | 4705898232067265346 |
| *20 | 20ピン ATX 電源は 24ピンのマザーボードに使えるのか – 分かりにくい ASUS マニュアルと ATX 電源の規格 | Nire.Com | https://www.nire.com/2009/10/atx-24pin-motherboard-vs-20pin-power/ | 75424033 |
容量超過のため、anond:20220419200228 に続く。追記もあり。
まずはバグの原因を突き止めてそれが何故テストをすり抜けたかを調査
調べてみるとテスト中に出てくるエラーメッセージが微妙に違うけど気付かずにスルーしてしまったらしい
再発防止策としては社員のマインド醸成とか言い出しててアホかと
上流工程でもっと詳細な検討をするべきとかも言い出しててホントアホかと
報告書を上司の上司の上司まで報告し終わったらようやくバグ改修の予算が下りるらしい
そんでその予算を使って契約書作って上司の上司の上司まで承認を貰えたら修正開始
修正そのものは3行ぐらいなんだけど、もう一回テストやり直すんだって
多分だけどマインド醸成するための研修とかもやることになるんだろうね
この手の人達にアジャイルをいくら説いてもそりゃぁわからんよなぁ
要するにこの手の人達って骨の髄からミスが嫌いでこんなことになってるんだと思う
電車が遅延するとか、お釣りを2円間違えてるとか、書類の提出が1日遅れたとか
そういうのが大っ嫌いな国民性だからソフトウェアのバグも根本的に嫌いなんだと思う
「よく考えて作れば間違いは起こらないよね？」
「ちゃんとチェックしたの？」
とかそんなことばっかりやってる
とか平気で言ってくるんだもんな。どうかしてる
あと、心の底では機械を信頼していないっていうのもあると思う
コンバインで刈ったお米よりも手作業で刈ったお米の方が美味しいと思ってる
Excelが計算した数字よりも、自分で電卓叩いた方が正しいと思ってる
（電卓の中身は分かってないのだが、電卓はもはや自然の一部だと思ってる）
ちなみに本当にExcelは間違えることがあるのでタチが悪いのだけれど
そもそもExcelを使う利点は「入力すべき数字だけを入れれば、必要としている数値や情報が自動的に計算される」という点にあるんだけど
そこまでいくともう信用されない
なのでプログラミングみたいなことをやるときにも「信用できない」っていう前提で作るから
とにかく慎重に作るし、間違いが無いように丹精込めてじっくりゆっくり作る
人間が指さし確認でExcelの表を一つ一つ埋めていくし、それをダブルチェックする
誇張でもなんでもなくて、割とこういう開発は日本中で行われてる
結局彼らにアジャイルマインドを教えるのなんて天動説を信じてる人に地動説を教えるぐらい不毛な話なんだと思う。
天動説が廃れたのは、ただ天動説を信じてた人が死んでいったから、という話と同じで
この手のマインドの人達が定年して退場して頂くまでこれは続くんだろう
ただ、若手が彼らのマインドを引き継いでいる様子もあるので地獄しか待っていない気もしなくはないが・・・
ちなみにLog4jのことは昨日知ったらしくこれから対処予定らしい。
運用監視の現場で週末も心休まらない皆さんこんばんは。一人運用チームです。
さて、世間では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 です。
