  |
はてなキーワード: テストケースとは
今日はちょっと早く帰れるかもなーとかおもってたけど、こんな時間になってしまった。
まだ、早いと言えば早い時間だけど、今日はイブだし、もうちょっとぐらいは早く帰りたいじゃん。
こんな日だからこそより自分の不甲斐なさが際立っちゃって、もう泣きそうだよ。30代も後半に入ったのに俺は何してんだろうな。転職も何回もしたし、違う職種も頑張ってみたけど、いつも精神がダメになっちゃうんだよ。
ほんと、だめだよな。
そう思うと、親父はえらかったな。家庭を省みなかったけど、それでも毎日定年まで働いてさ。それを文句いいながらも一緒に走った母親もえらいよ。こんな俺でも育ててくれてさ。
そう思うと周りはえらい人ばかりだ。こんな時間まで働いてる店員や駅員さん。会社の窓を見るとまだ働いてる人がいっぱいいる。定時であがった周りの社員たちもしっかりしてるから帰れるんだもんな。
こんなにえらい人ばかりなんだから俺がいなくても大丈夫だよな。
こんな文章をここまで呼んでくれる人もほんとえらいよな。
ありがとね。
みんなにいいことがありますように。
はてブのホットエントリ(総合)で月内に数多く[あとで読む]タグを集めたエントリ
441あとで/2227users 未経験でも1カ月で即戦力クラスの知識が身に付く『webデザインドリル』公開 | knowledge / baigie
319あとで/2886users 賃貸住宅の退去費用として13万円請求された時の対応方法をまとめます｜犬笛｜note
305あとで/1662users 非デザイナーの僕がデザインぽいことをする時に使う便利なツール18選｜かずたか@プログラミング独学して起業した人｜note
260あとで/2214users 【朗報】Youtuber中田敦彦、うっかりまともな資産運用を数十万人に広めてしまう・・・これには金融マンも真っ青 | ライフハックちゃんねる弐式
228あとで/1529users 研修資料まとめ.md · GitHub
214あとで/1017users 技術ブログをバズらせたくて必死で身につけた情報収集術 - omuriceman's blog
191あとで/1517users 社会人の不幸の8割は合意のない期待から｜田中邦裕｜note
185あとで/1788users この法律が日本を｢生産性が低すぎる国｣にした | 国内経済 | 東洋経済オンライン | 経済ニュースの新基準
182あとで/1222users 科学的で現代的な「人を動かす」──『事実はなぜ人の意見を変えられないのか-説得力と影響力の科学』 - 基本読書
180あとで/970users 3年かけてたどり着いた英語記事を読むための方法 - Qiita
172あとで/796users 文系大学生が機械学習を０から始めて９か月でKaggle銀メダルを獲得するまで - Qiita
170あとで/669users いま知っておきたいLinux─WebアプリがOSのプロセスとしてどのように見えるか？ を運用に生かす - エンジニアHub｜若手Webエンジニアのキャリアを考える！
170あとで/1344users 機械の立体図をフリーハンドでとんでもなく上手に描く人が製図のテクニックを解説「恐ろしいレベル」「弊社に欲しい」 - Togetter
169あとで/2472users 食べログ3.8問題を検証 - クイックノート
168あとで/1146users 質問が出ないのは話し手の責任が8割。だから「質問が出る」ようにルールを決めたら、大成功した話。 | Books&Apps
166あとで/898users 貧困を減らす実験アプローチ｜安田 洋祐｜note
165あとで/679users 社内勉強会で作ったDocker/Kubernetes入門の資料を公開しました - inductor's blog
164あとで/695users データサイエンス・機械学習をやるためのエンジニアな本まとめ - 2019年版 - Lean Baseball
157あとで/1090users 20年の営業マン生活でわかってきた「仕事の本質」を全部話す。 - Everything you've ever Dreamed
154あとで/953users 【インスタ、エアビー、Slack等】人気サービスの初期ユーザー獲得方法
153あとで/1292users 【四川料理のスゴい人】家庭のキッチンの火力で「プロ並みのチャーハン」をつくる方法 - メシ通 | ホットペッパーグルメ
151あとで/1150users ０から100万円貯める、節約サバイバルガイド
149あとで/1972users 巨乳の炎上に見る進化と文化のミスマッチ - 本しゃぶり
148あとで/637users WebサービスのA/Bテストや機械学習でよく使う「確率分布」18種を解説 - paiza開発日誌
147あとで/1149users フライドポテト、チェーン店別徹底比較 :: デイリーポータルZ
143あとで/598users プログラミングの命名規則ガイドラインを規定するオープンソースプロジェクト「NamingC - エンジニア・プログラマのソーシャルITメディア
143あとで/661users ワークフロービルダーが新登場 : Slack で簡単にタスクを合理化 | The Official Slack Blog
142あとで/564users 「単体テスト」再入門！ 開発の現場でバグを確実に洗い出す最適な手法と、テストケースの作り方 - エンジニアHub｜若手Webエンジニアのキャリアを考える！
140あとで/1334users 13歳から43年間野宿していた「洞窟オジさん」はかつての住処でナニを食べていたのか？【極限メシ】 - メシ通 | ホットペッパーグルメ
138あとで/963users 自称IT企業があまりにITを使わずに嫌になって野に下った俺が紹介するWindowsの自動化の方法 - Qiita
まず自分について。俺はmarch未満大学卒のアホな文系だ。新卒就活時にはやりたい事も、何かをやれる才能もなかった。
ただ営業は絶対に無理だと思い、「文系でも無問題」「手に職がつく」という甘言に乗せられてIT業を志望した。
そうして適当に面接していたらある中小企業に引っかかったのでそこに入社した。
入ってから最初にやった研修はビジネスマナーとエクセルが中心で、技術らしい技術に関してはjavaの基礎文法を申し訳程度にやったぐらい。今思えばこの時点でお察しな企業だった。
俺が入ったのはある大企業のグループ会社で、これは後で知ったことなのだがその中でも運用、手動テストといった最末端のクソ案件があてがわれる立ち位置だった。
要は入社した時点でまともなエンジニアになる道は閉ざされていたのだ。
俺が売りとばされた最初の案件は作業系テスト。エクセルスクショマシーンとして給料を貰っていた。
三つ目の案件は肉体労働系テスト。ここでは「ハード検査」として1ヶ月間延々とプラグの抜き差しをやらされた。
その後はプロパーが用意したテストケースに沿って延々ソフトを動かすだけのソフト検査もさせられた。
営業はここに2~3年は置いといて、ある程度の経験を積ませたらその流れで適当にリーダーっぽいことさせようという魂胆だったらしい。しかし、仮にも大卒で底辺企業に入った絶望感、上司からのパワハラ、酷い環境での単純作業が重なり、鬱になりかけてまともに働けなくなったためここは数ヶ月で切られた。
そして最後の案件がソフトの監視。半分寝ながらでもできるような仕事だった。
二つ目の現場で自分の会社はIT業と言いつつ、その実態は技術者ではなく五体満足な奴隷を売り飛ばすだけの奴隷商であると気が付いた。長くいるほど市場価値が下がるため、理系上がりで技術の素養がある同期は今年の頭にはもう退職していた。営業のジジイどもは適当な現場に売り飛ばすことしか考えておらず、「俺ももともと現場にいた」と言っていた若手営業も上記のようなクソ案件しか経験してこなかったため、「お前入れや」と言いたくなるようなクソ案件ばかりを投げてきた。
まぁ「先輩が手取り足取り教えてエンジニアにしてくれる」思っていた俺もめちゃくちゃ頭が悪かったことは認める。
ただ、それにしても酷い。ここにいると生涯底辺作業員だなと思い、昨年末頃からRuby等web系言語を勉強して転職活動を始めた。そうしたらつい先日ある企業から内定をもらえた。社員数20人未満の超零細で若干不安な所はあるが、エンジニアとして今よりはまともな経験ができるだろうということで入社を決めた。
仮にブラックでもまともな開発経験を詰めるなら、またしばらく働いて転職すればいいだろうぐらいの感じだ。
通帳に記された100数万の数字を見るに、この一年とちょっとの全てが無駄だったとは言い切れないが、キャリアにおいて得るものはなかったと思う。
俺みたいな理由で文系からエンジニア職になろうとする人は少なくないと思っているのだが、まずSES、受託、自社開発、SIerという四つのビジネスモデルについて熟知した上で就活することをオススメする。
https://www3.nhk.or.jp/news/html/20190404/k10011873041000.html
箕面市の上下水道局によりますと、今月１日、家庭や事業所に配られた水道料金の検針票1365枚に、口座から料金が引き落とされる日が印刷されていないミスが見つかったということです。
https://www.yomiuri.co.jp/national/20190410-OYT1T50328/
市上下水道局によると、元号の誤記があったのは７６８通で、記載した日付がいずれも「令和３１年」になっていた。受け取った市民からの指摘で誤りに気付いた。同局は「再発防止に努める」としている。
https://tech.nikkeibp.co.jp/atcl/nxt/news/18/04724/
ミスがあったのは私立幼稚園に通園する子供を持つ保護者に補助金を交付する通知書類である。通知書類を起票した日付と補助金の振込日の2カ所を について、「平成31年」と印字すべきところを「平成3元年」と印刷した。対象世帯に約1万通を発送したという。
世田谷区は西暦のデータを渡し、印刷業者は和暦に変換するプログラムで処理してから印刷する。このプログラムは和暦の一の位が「1」だったら「元」に変換するロジックを組み込んでいた。しかし、十の位を考慮していなかったため、ミスが生じた。
世田谷区はデータ内容の正しさを確認してから印刷業者にデータを渡した。世田谷区と印刷業者はテスト印刷の結果をそれぞれ確認したが、テストで使ったデータがダミーデータだったため、バグが表面化せず、発見を漏らしたとしている。
先日「採用力強化Meetup」という勉強会に参加しましたが、よく見たら採用する力を強化するのイベントでした。間違えちゃった。
僕の認識。採用（される）力を強化するためのイベント。転職しようとする人たちが集まり、「採用される力を強化しよう」が目的の会。
実際。採用（する）力を強化するイベント。転職者を見る人、つまり採用担当者様向けの会。
開始5分で出ていくのも恥ずかしいので、素知らぬ顔で話を聞いてみることにしました。
講師は某大手人材会社のキャリアアドバイザー、開催企業の人事担当者様。
ベンチャーの大きくなる流れは以下の通り。
シード期（1人～10人）、会社立ち上げ期、毎日しんどい、社長との距離は近い。
アーリー（20~50）、技術力や即戦力が求められる、企業としての基盤づくりの時期。
ミドル（50～）、事業をさらに拡大していく時期、社内のコミュニケーションを考え始める、人事制度を本格的に構築する時期。
ベンチャー企業の規模から、求められるポジションを判断する指針になるか？
ベンチャー企業ではここのマッチングを重視しているのが多いのだろうか？
面接でも「いかに本音を引き出して、当人の考え方を探るか」に苦心しているようだった。
くらいはチェックするらしいが、そこまで一語一句をチェックしているようには思えなかった。
細かい言い回しやら言葉尻に気を揉む必要性は薄いように思えた。
25歳くらいの例。
30歳くらいの例
ミッション、ビジョンへの共感も大事だけど、ここは取り繕ってもボロが出る気がする。
ネームバリューだけで選んで「やりたい仕事と違いました」は最悪。まぁ100%自分のやりたい仕事でした、は無いさ。
面接関連の話。
Doの質問。過去の経験について、どうして、どのように、どうしたのか？という聞き方をする。
「何をやったか」の奥にある考え方につなげるため？
whatの質問。原因は何だったと思う？なにがあなたをそうさせたのか？を聞く。対話を重視してる？
面接ではこれが基本だと思われているが、この聞き方では上下関係が露骨になるので面接でするべきではない、というお話。
相手は詰問されてるように感じるらしく、委縮させるとか。
相手の話をよく聞いてやること。自分の話を聞いてもらえなかった人は、相手の話も聞かなくなることを忘れないで。
だからこそ対話することが重視される？というかしようとしてる？
【パターン1】
A あの時のプロジェクトは大変でしたね～
A そうなんですよ！〇〇で！△△で！
【パターン2】
A こんなことをやりました。
B それはどうしてですか？
A これこれです。
B 他に何を？
A ほげほげです。
採用面接を受ける側としてはむしろ自分から喋りに行くくらいが良いのではないか・・と考え始めた。
今まで自分ではパターン2が正しいものだと思っていて使わなかったが、どちらかというと聞かれてもない事までベラベラ話すタイプであり
こういう考えもあると分かったことは収穫だった
その他
そもそもITゼネコン主導の大規模開発は悪評まみれで、天国案件なんて数えるほどしかないと言われる。
なので誰がやってもしんどいと思うが、特に自分には全く合わなかった。
自分のプログラミングは、動かす前に「これで行けるだろう」と確信しながら、動かしてみて抜けや漏れが発覚するタイプなので、コードの品質は多分悪い部類に入るだろう。
つーか、仕事なんて楽に済ませたいから、コードなんて可能な限り書きたくないというのが一番にある、かなり独善的な人間だ。
一方で大規模SIのプログラマなんて、基本的にライン工か調整役以外お呼びでない。
そしてコミュ障でもある自分は必然的に、もらった設計書の長ーいフローをひたすらコードに翻訳するという、まさにライン工として身を粉にして働くしかなかった。
それこそif文の後のelseが何ページも先になろうが、ループが何重にネストしようが一切気にせず、可能な限り設計に沿うようコードを書き続けた。
元々コードを書かずに済ませたい自分には、正直目が眩みそうな作業だったが仕方ない。
しかし上述のように元来不注意な人間なので、品質は恐らくメンバーの中では最低レベルの代物を量産する結果となった。
コーディングもスケジュール的に余裕なかったが、テストに至っては必死にというか、死に物狂いで頑張らないと遅れてしまうくらい、作業量が半端なかった。
ちょっと込み入ったメソッドになると、それだけでテストケースが20とか30とか相当な数になるので、ケースの抽出から始まって、最終的にレポートにまとめてカバレッジと一緒に提出するまで、地獄のような作業の連続になった。
最終的には体調不良を理由に「すんませんクビにしてください」と言って現場を抜け、その責任を取って僻地に飛ばされ今に至る。
そんなことはどうでもいいのだが、それ以来、テスト自動化ツールに対しては、理屈抜きに憎しみしか沸かないようになった。
フレームワークの便利さを推す記事とか、むやみに持ち上げるヤツは一切信用できなくなったし、オブジェクト志向をやたら崇高で革命的なもののように吹聴するやつはもっと信用できなくなった。
例えば次の一文を取ってもこの人がシステムというものを何も理解できていないことが分かる。
「コンピュータは考え得る限りの状況をテストしてから製品となり、日時を扱うシステムなら「２１００年に２月２９日はあるか」という処理までチェックするものです。」
リソースが無限にあるなら「考え得る限りの状況をテスト」することが可能だが、実際のリソースは有限だ。
極論すれば、1万年後、10万年後までのテストをするのか、考えてみるとよい。
ライブラリの単体テストでは、「２１００年に２月２９日はあるか」というテストを行うかもしれない。
しかし、結合テスト、システムテストとテスト局面が進むたびに、いちいち「２１００年に２月２９日はあるか」というテストを行うと、テストケースが爆発的に増えてしまい、これも現実的ではない。
「２１００年に２月２９日はあるか」というケースは、ライブラリ単位では保証されるかもしれないが、システム全体として保証されることはまずありえない。
今日遭っちゃったのよ、なんと渡されたテストケースの手順がまるっと白紙！
ゾゾーッ！
その前からね、渡されたテストケースの手順が歯抜けだったり、上から下までそのまま実行すると辻褄が合わなかったり、確認観点の部分に何やら文章が書いてあるんだけど、ちゃんと読み下してみてもいまいち何を確認したらいいか見えてこない怪文だったりで、なんだかここのテストケース怪文書寄りだなぁ、ちょっとヤバいなぁ、なんて思っていたりしたんですけどね。
…それもね、あとから聞いた話、いま別の案件に追われている有識者が、わざわざ工数を使ってね、ちゃあんとテストケース見直しやった後だっていうんですから、こりゃもうただの怪奇現象じゃない。
あたしゃもうおっそろしくって、定時後だったのをいいことに、エスカレーションした後はそそくさ荷物をまとめてとりあえず退勤してきたんだけどね、
皆さんもね、危ないと言われてるような場所には気をつけて、よくよく近づかないことですよ。
英語と日本語が混ざってるような職場環境で働いている（英語話者と日本語話者が混ざっているため）
何かの文章を英語で書く際に、日本語のほうが分かり易いから、本当は日本語で書きたいなぁ、と思うことがあり、
それが語学力に起因するものなのか、それとも、別の理由もあるのか、疑問に感じることがある。
比較的短い文章で意味を伝える場合、漢字や文字種別が多いせいか、日本語のほうが(慣れていれば)かなり解りやすくなる気がする。
特に、テストケースのテスト名(アサーション)でそれを感じることが多く、次いでチケット名や、コミットログなどか。
例えばテストケースについては、短く、かつ、ある程度の表現力が必要とされることがあり、日本語が使いやすい気がする。
各種言語のネイティブ話者に同じ意味を表す文章を短い時間(0.5秒など)見せた場合、言語毎に認識程度の差はどのくらい出る・出ないものなのだろう。
キーボード叩いてると突然ウっとなって涙がじわじわにじんでくる。きっかけはよくわからない。
涙がにじむとトイレにこもってできるだけ涙を排出し、自席に戻る。
涙が出るたび一々トイレに行かなければならないのが面倒くさい。
涙を出しきったつもりで自席に戻ってもしばらくは残尿みたいに止まらないのも面倒くさい。
そういうのが一々面倒くさいからそのまま涙流しながら仕事させてほしい。
なので泣きながら仕事してたら変に心配されてしまうと思うが、でももうデフォルトで涙がでてくるため
自分としてはなんかあくびとかくしゃみとか居眠りぐらいの位置づけであり、あまり気にしないでほしい。
居眠りしながら仕事してる人間もいてそれが黙認されてるくらいゆるい会社なので
泣くことも許してくれないかなあとおもう。
きっかけはエンジニアのおじさんに理系特有の早口でしゃべられた上長文赤字のメールを送りつけられたからだとおもう。違うかもしれない。
そういえば職場で始めて泣いたのはおじさんからバカでかいフォントの指摘メール送られてきたときだった。
なんでこんなにおじさんから圧かけられがちかというと、この分野の知識が本当に本当になく不勉強だからだ。
弊社はメガバンク系SIer会社なのだが、自分は最近までwebアプリの開発を担当していた。eclipseでjavaでjQueryでUNIXでshellだったのだ。
それが今のチームに異動となり、分野は一変、メインフレームでzOSでcobolでファンクションキーになったのだ。
最初はわからないことが多いけど弊社主力の分野なので頑張ろうと思った。社内研修かたっぱしからでてメインフレームで遊ぼうよんで
がんばってついてこうとした、でも座学だけでは知識は身につかなかった。
手を動かしたかったが、Sierとはコードは書かないし資源引き揚げもしないみたいだ。
そういうのは製造委託先のエンジニア達の仕事で、では我々は何をするかというと、エンジニアさんの作った内部設計書、
テストケース、成果物一覧、スクリーンショットを確認するのである。
でもそもそも何が確認観点で何がまちがってて何がどうなってれば正しいのかよくわからないのだ。
自分の会社の上司先輩に聞きたかったが、ある程度スキルをもった上司先輩は業務に忙殺されておりもはやふだんどこにいるかよくわからない。
というのも近年弊社では超大規模プロジェクトが発足しており、
ある程度スキルをもった人間はそちらに根こそぎもってかれてしまっている。
自分はメインは運用・保守・メンテナンスチームなので、そういう上司先輩とは関わりがない。
またこのプロジェクトでごっそり人がもってかれてるためメンテナンスチームの人間が少ない。なのでとにかく一人あたりの作業が膨大なのだ。
そして作業内容は前述のとおり。委託先のつくった成果物をチェックし、品質関連の定型的な資料をつくり、承認する。
なにをみたらよいかわからない成果物がどんどん送られてきてどんどんチェックしなければいけないのがつらい。
なにをしたらいいかわからないことをどんどんしなければならないのがつらい。
同じメンテナンス担当の先輩にきいてもよくわからないと返答がきたので
いまさらなにをそんなこと聞くんだみたいな雰囲気をにおわせながら
理系特有の早口でいまさらそんなこと確認しても意味ないですっていわれたからもうめんどうくさくなってしまった。
でもかつてはソースかいてテストして資源ひきあげする立場だった身をしては、ちゃんと確認したい気持ちがある。
でも同時に、とんちんかんな質問する担当者に対してエンジニアがイラっとする感覚も容易に想像つくので
もうなにもかもめんどうくさい。
明るくない分野の仕事をてさぐりでやらなければなければならないのがめんどうくさい。
チェックシートに日付をひたすら埋める仕事がつらい。※つじつまをあわせるために、全て同じ日付にしてはならない。
これらをやらなくてもどうせシステムはちゃんとうごくのがわかってるから尚つらい。
かつてソースかいてテストしてた時代は、ネットにあふれるイシキタカイキラキラサイシンギジュツブログと
自分が担当しているつまらなくぱっとしない時代遅れのwebアプリに不満を感じていた。
テストといってはひたすらスクリーンショットを延々と印刷する作業にいったいなんの意味があるのだろうと思っていた。
昨日Qiitaでメインフレーム関連の記事をあさっていたところ、zOSではteraTermによりUNIXライクな操作ができることを知った。
また、ftpが使えることも知った。ということはffftpが使えるかもしれない。希望の光に見える。うれしい。すごくうれしい。
USSが使いこなせればもうすこしこのメインフレームまわりに馴染みやすくなるかもしれない。
※補足
その友達とはネットで知り合った。リアルで会った事はないけど、付き合いは長い。
その子は年齢詐称でなければ私と同じ20代で、今は無職らしい。加えて承認欲求と自己愛が異常に強いメンヘラちゃんで、虚言、自己中心的、ヒステリー、嫉妬で他人を貶める…など数々の問題行動(?)を頻繁に起こすから色々なコミュニティで揉めては孤立って流れを過去に何度も繰り返してきた。twitterでも自傷や自殺願望をほのめかすとかの病みアピールがしつこいとかかまってちゃんすぎるとことかそういうので嫌われて孤立→垢削除→転生を繰り返しているような子。私はその子の性格が本当に、反吐がでるほど嫌いなんだけど、それでもずっと友達づきあいを続けてる。理由は単純。隣で見ていて気持ちがいいから。
実は私も昔からメンヘラ気質なところがあって、実際高校生の頃付き合っていた先輩に二股をかけられてた時は自傷行為がやめられなかったし、でも精神的に依存してたから別れるのは嫌でずっと粘着して嫉妬して、毎晩しつこくLINEしたり束縛したりとか本当に相手の気持ちを考えないような嫌なことばかりするゴミみたいな女だった。社会人になって二年しないうちに上司から毎日嫌味言われたりただただ不快なだけのいじりがしつこくて辛かったっていう他人から見たら本当につまんない事でメンタルやられて仕事一回辞めちゃったし、その時発症した精神疾患がまだ完治できてなくて今の職場でも薬のお世話になりながら働いている状況。人見知りが激しいのが大人になっても直せなくて友達も指で数えるくらいしか作れてない。高校の頃のことがあって男性が苦手になって以来彼氏がいない…って言い訳してるけど、本当は自分もメンヘラだし嫉妬深いし十分気持ち悪くて最低な女なのに人間不信になったとか言って一方的に男性側のせいにしてるだけなんだって分かってる。
私はそんなクズみたいな人間だから、どうしてもその子に自分を重ねると安心してしまう。もし私が仕事を辞めてひきこもったままだったり、人目を気にすることをやめて自堕落に肥え太ったり、人の気持ちを考えたり空気を読むことを放棄して自分のエゴばかり他人に押し付けるようになった結果の姿、最底辺まで落ちぶれた私の末路みたいなものが今の彼女の姿なんだと、最近はそう思っている。シュミレーションとかテストケースみたいな感覚になるのかな？だから、ちょうど実験体みたいな彼女がどんどんダメになって荒んでいく姿を見たら凄く気持ちいい。それかもしくは他人のはずなんだけどその子が苦しむことが一種の自傷みたいに思えて、なんだろう、見てて心がすっと晴れるような気持ちになる。
あの時再就職の為に努力をしなかった場合の私や、メンヘラをこじらせたままの私が今こんなネットでも嫌われ者リアル社会でもゴミ同然の扱いをされて親にすら見放されたヒキニートになってる、でも私はそうじゃないし、絶対絶対そうなっちゃいけないって思える。だからどんなに辛くても仕事頑張るし、あの子みたいに自分勝手に人を悲しませたり虚言を繰り返すような真似はしない。拒食症もカウンセリング通って治したし、人見知りでコミュ障でどれだけ苦痛でも絶対ひきこもって現実逃避するような真似はしない。毎日自堕落にゲーム三昧で体重70kgオーバーお風呂は数日入らない部屋は汚いほうが好き、なんて恥ずかしい女性には絶対ならない。
散々ヒドイこと書いちゃったけど、自分の嫌いな部分を全部ごった煮にしたような彼女の姿が、こんな自分から脱却したいっていう強い気持ちをいつも与えてくれたから今なんとか社会復帰して頑張れてる私がいる訳で、そう思うとあの子には感謝してもしきれない。あの子と知り合えたお陰で私はいっぱい変われた。私の代わりに失敗してくれてありがとう。変わる努力をしなかった場合の私の姿を人生ドブに捨ててまで私に見せ続けてくれてありがとう。貴女と出会えて本当によかった。これからもずっと友達でいようね。大好きだよ。
はてなユーザーには馴染み深いであろう、「SIerへのdisり」で有名なpaizaのスキルチェックをやってみた。
ちなみに、私は現在SIerに勤めており、最近仕事への不満が高まっているので、転職を考えている。
といって別にSIerが憎いわけでもないし、paizaのポジショントークはどうかと思っている。Web系に行きたいわけでもない。
ただ色々な転職サイトに登録してる流れでpaizaも登録したので、せっかくだしプログラミングスキルチェックをやってみた。
スキルチェックするにはプログラミングの問題を解けばいい。問題にはランクがあり、難易度順にS,A,B,C,Dの5段階。問題を解くと100点満点で評価される。
得点は「テストケースに通るか？」と「時間内に解けたか？」で決まり、各ランクの問題で81点以上とれば、自身のpaizaランクが上がる。（paizaランクはS～Eまで）
問題は多数用意されているが、1問でも81点以上取ればランクが上がるので、ランクアップのハードルは低い。しかもランクが落ちることもない。
B 普通。稀にひらめきが必要な問題もあったが、特に迷わず解ける。
A やや難しい。自分の能力不足かも知れないが、少し実装が込み入ってくる。しかし解けないものは無い。
S 難しい。解けない問題もある。愚直に解くと計算量が多すぎたり。アルゴリズムの知識が必要だったり。
Aランク以下の問題はほぼ全て81点以上（というかほとんど100点）だったので、全体的な難易度は低い。
「高ランクだと企業からオファーが来ます！」っていう触れ込みだけど、最近は業務でワードエクセルしか触っていない私でもこんな感じなので、単なる足切り程度の意味しかない気がする。
ユニットテスト書きすぎじゃない？って話です
http://kenn.hatenablog.com/entry/2014/01/03/095026
今はこのブログで言ってることがその通りだと感じる場面が多い
スマホアプリの開発現場では、MVVMやクリーンアーキテクチャと言った手法を用いて
Viewのロジックに近い部分までユニットテストしようというのが主流になっている
この空気感では最早テストを書くのはやめよう！という人は居ない
テストを書いたほうがいいか、書かなくてもいいか、迷うくらいなら書けという感じ
その結果、仮にバグが有ったところで大して痛くもないところまで緻密なテストが書かれ
コード量は爆増し、開発速度ははっきりと低下している
テストを書いておいたほうが結果的にリリースまで早くなる箇所もあると思うが
テスト礼賛の現状、よっぽど強い意志を持っていたり強い権限を持っていないと
そうでないところまでテストを緻密に書く流れにどうしてもなってしまう
もうAppleの審査も昔のように一週間もかかったりしないんだから
営業職とエンジニア両方そこそこやってという変な経歴の持ち主だけど上記の通りのことしたら、お定まりの下流で下積みしてから上流へ…みたいなことを言われてて、草生えそうになったのを我慢しながら聞いてて、ふと思ったけど
IT系のキャリアって35歳過ぎたら営業かマネジメント行くしかないから問題だし、そのための準備とか一切させてもらえないで転向だから大問題なんだろうな
幾ら優秀なエンジニアでもいきなり営業かマネジメントやって上手くできるはずがない、営業や総合職ですら最初から少しずつできそうなところからやって、ようやく２７～８で物になるってくらいのものなのにさ
なのに、院卒でも大卒でも、最初の３～４年間はインフラならサーバー監視から数年経験を積んで…とかプログラマーならテストから数年経験を積んで…とか
そんなことしか言われないし、ネットのIT転職でも、そんな大間違いの話しか流れていないのが不思議でしょうがない。
だったら最初から1年か半年で切りあげて、技術系の法人営業にでも転向しないと(俺の場合は順番が逆だったけ)、どう考えても35歳定年説より先を生き残ることなんて不可能なのにさ
1月～４月生まれの奴ならさ、大学卒業してこの道で3年サバ監やテストケースやエクセル方眼紙職人した日には、27歳だぞ？27歳、27歳でやったことはサーバー監視とテストだけってweb系でもどこも拾ってくれなくなるし、かといってweb系から入っても滅茶苦茶変な技術になるしビジネスマナーすらつかないから、いざ転職の時に全く潰しが効かないなんてこともよくある。
どう考えても、35歳過ぎてこの業界で生き残ってるとか稼いでる奴等は口をそろえて「営業力>>>>>>>>>>>>>>技術力」というくらい、そっち方面のノウハウがいるのに、それを積まさせないようなキャリアが常識になってるのが、ホント不思議でしょうがないわ、IT系って
一番不思議なのは、ネットですら転職サイトやIT転職系のHP見てたら、このこと一切書いてないんだよな、お決まりのように社内SEかPMかweb系か…みたいなことしか言わないという
すごい疑問なんだけど、現状のIT系のキャリアで、実際や本当のこと話したら、政府のIPAから刺客が放たれて暗殺される危険性があるから言えないとか、そんなことでもあんの？
みなさん、即席ラーメンという便利な食料のことはご存知でしょうか。
揚げ麺や乾麺が袋詰めされ、粉末や液体のスープがついています。ほとんどの製品は約3分間、お湯で煮ることによってぴちぴちの麺になる。とても調理が簡単です。
手軽に作れる半面、老若男女問わず食べやすい量に設定されているため、ボリューム感足りない。これはまぎれもない事実です。
この問題点を解決するため今回ご紹介するレシピのダブル即席ラーメンを開発するに至りました。
ボリューム感を出す方法はあまたあれど、だいたい時間がかかったり、おいしさを損ねてしまいます。
2回に分けてインスタントラーメンを作ることを考えてみると1回つくる、そして、食べる、食べている間にお湯をわかす、2回目をつくる、そして、食べるという手順を踏むことになります。1回目と2回目の食べる行為の間に間ができてしまいリズムがよくない。無理してひとつの鍋で2つ分を一度に作ることは、即席ラーメンの開発者の想定外の作り方です。即席ラーメン開発者のテストケースからも外れているのか、もしくは、倍量の即席ラーメンと通常量の即席ラーメンに対する水分量・加熱・スープに対する麺の割合などの側面で共存できない開発側の理由があるのか、実際にやってみると味がぼんやりしたり、麺のゆで具合に致命的な影響が出てしまいます。
ここまでの説明で、お腹が空いているときに即席ラーメンを2つ作ることによるデメリットが大きいことがわかります。即席ラーメンのメリットである短時間で料理が完了することを損なわない調理方法でお腹いっぱい食べる方法を考えてみましょう。
今回お伝えする方法は、家の台所では思いつきませんでした。ヒントはラーメン店のカウンター席にありました。カウンター席は知見の宝庫です。
そのお店は豚骨ラーメンを主に提供するラーメン店でした。頼んだ豚骨ラーメンが配膳され、半分ほど食べ始めたところで、店の主人が「替え玉はいかがですか。」と尋ねてきたのです。
替え玉というのは、あとから麺を追加で入れることがサービスです。大盛では最初から麺の量が多くなりますが、替え玉ではあとから麺が増えます。最終的な麺の摂取量に変化がないので、どちらでもいいのではないかという反論に対しては、断固、替え玉と大盛は違うと答える。普通盛りで温度・うまみ・塩気・油などの完全なバランスを達成しているラーメンの麺の分量を1.5倍にした場合、往々にしてバランスが崩れてしまいます。麺に合わせてスープを1.5倍にすればいいのかというとそんな単純な話ではありません。麺に残存する水気であったり、温度の変化であったり、うまみや油の絡み方であったり、何かしらの要素で普通盛りのバランス感を超えることできません。これを解決する手段として、替え玉はひとつの最適なソリューションです。替え玉方式にすると、最初は、普通盛りで作るので、作り手の最適なバランスのラーメンをを提供することができます。さらに量的に足りない人には、麺を追加でいれることにより満足感を付加することができるメリットがあります。
ということで、自宅で作る即席ラーメンでも、替え玉を実現してみようと思います。思いました。
・即席ラーメン（お好みで）
・生麺（お好みで）
この二つがあれば、ダブル即席ラーメンを作ることができます。家事に忙しい主婦の方も、仕事に忙しい会社員の方も、近所のスーパーで売っている手に入りやすい材料のみで今回のレシピは完成します。
即席ラーメンを2つ用意して、片方のスープを使わずに麺のみを入手する方法も考えたのですが、即席ラーメンのスープが台所にどんどんと積み上がり近い未来にごみ屋敷の基礎となってしまいそうな気がしたので、生タイプの生麺を選びました。生麺にはスープがついていないものを選んでください。スープ付きの生麺を選ぶと、やはり、スープだけのコレクションが台所に増え続けていきます。精神安定上よくない。できるだけ人生に必要のないものは買わないようにしましょう。
即席ラーメンの作り方は、袋の裏に書いてある調理方法に従いましょう。日夜、即席ラーメンの開発のために身を粉にしている研究者が考えた調理方法を我々は超えることできません。水の量はきちんとカップで計量し、火加減を守り、ゆで時間はタイマーで管理します。ゆで時間に関しては、30秒短く作ることが多いです。これは、火を止めてから盛り付けるまでの手際の限界というか、トラブルに対処する時間稼ぎのためです。3分と袋の裏に書かれていれば、2分30秒、4分と書かれていれば、3分30秒にタイマーをセットします。
まず、鍋をふたつ用意し、お湯を二つ沸かします。片方が即席ラーメン用、片方が生麺用です。
スープをどんぶりに入れ、お湯が沸くのを待ちます。カップには水を汲んでおきましょう。
沸騰したところで、タイマーをスタートし、即席ラーメンを作り始めます。そのとなりの生麺のほうにも麺を入れてゆで始めます。
生麺は、1分ほどで吹き上がってきますので、カップの水入れ、水温を下げます。もう一度吹き上がりかけたところで、火を止めて水切りをします。
水切りができたあたりで、タイマーが鳴り、即席ラーメンが茹で上がります。時間設定はシビアです。モタモタしている暇はありません。
即席ラーメンは、少し固めに茹でた以外は即席ラーメン研究者の考えた通りのものができています。
体調が悪くない限りおいしい。問題がない仕上がりです。
この先の即席ラーメンに対する替え玉は、未知の領域の方が多いことでしょう。
近年の即席ラーメンのスープは即席ラーメンの研究者たちの研究心により、高度に発達しているので、そのスープに生麺を入れて、おいしくないわけがありません。
しかしながら、替え玉の最大の弱点は、一度普通盛りを食べてしまったあとのスープが少し薄くなってしまっていることです。
塩気やうまみが足りないと感じた人は、替え玉を盛り付けるときにあらかじめ、麺にだし醤油を一回りかけておくといいと思います。
これで、今回のレシピの紹介はおしまいです。ちょっとした工夫で即席ラーメンのボリューム感をアップすることができました。ご家庭でもぜひお試しください。
