  |
はてなキーワード: テストケースとは
営業職とエンジニア両方そこそこやってという変な経歴の持ち主だけど上記の通りのことしたら、お定まりの下流で下積みしてから上流へ…みたいなことを言われてて、草生えそうになったのを我慢しながら聞いてて、ふと思ったけど
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分ほどで吹き上がってきますので、カップの水入れ、水温を下げます。もう一度吹き上がりかけたところで、火を止めて水切りをします。
水切りができたあたりで、タイマーが鳴り、即席ラーメンが茹で上がります。時間設定はシビアです。モタモタしている暇はありません。
即席ラーメンは、少し固めに茹でた以外は即席ラーメン研究者の考えた通りのものができています。
体調が悪くない限りおいしい。問題がない仕上がりです。
この先の即席ラーメンに対する替え玉は、未知の領域の方が多いことでしょう。
近年の即席ラーメンのスープは即席ラーメンの研究者たちの研究心により、高度に発達しているので、そのスープに生麺を入れて、おいしくないわけがありません。
しかしながら、替え玉の最大の弱点は、一度普通盛りを食べてしまったあとのスープが少し薄くなってしまっていることです。
塩気やうまみが足りないと感じた人は、替え玉を盛り付けるときにあらかじめ、麺にだし醤油を一回りかけておくといいと思います。
これで、今回のレシピの紹介はおしまいです。ちょっとした工夫で即席ラーメンのボリューム感をアップすることができました。ご家庭でもぜひお試しください。
システム開発は色々面倒な作業がつきまとうが、特にテストがしんどい。
設計のフロー1個1個にテストケースを作ると、それだけで1メソッドあたりのケース数が30くらいになってしまう。
何よりケースを抽出し、文章にするのはどうやっても効率化できない。
それだけならまだいい。
基本コピペであっても記述量が膨大で、書いても書いても終わらない。
そんなことを要求してくるJUnitは最低最悪のツールだと思う。
大体、テストコードで開発が効率化されるとか、寝言抜かすなと思う。
そして以上の作業を1メソッドにつき1週間でやるとか、遅筆の自分には無理。
そもそもフローで書かれた手続きをJavaで実装しようとすると、処理のネストは深く、かつ記述量も長くなってしまって非効率この上ない。
大きな開発でJava使う意味なんて、というかオブジェクト指向を持ち出す意味なんて殆ど無いどころか、書きにくくなるばかりで、これまた開発の効率化なんて嘘だと思う。
具体的に言うと、
・日本語での説明があんまりうまくできない。今日も後輩にJVMってなんですか、Staticってなんですかって聞かれたけど、なんかうまく説明できなかった。
あーなってこうなってっ説明しても、相手は「？？？」みたいな顔をしている…。
・深く考えられない。相手から意見言われと、思考が停止して「それが正しいまさに正解だ」という気持ちになってしまう。
たぶん他人から「1+1は3だよ」って言われたら、「えっ!?そうなの？そうなのか…」みたいな気持ちになって、最終的に納得してしまう。そんなレベル。
・不適切な場面で万能感が湧き上がることがある。「なんかできる気がする！！！」スイッチが突然入る。
ただ、それは大体「気がする」止まりで、最終的に痛い目をみることが多い。
今日もJVMの説明するとき、説明の筋道考えてる最中に突然「なんかできる気がする！！！」スイッチがONになってしまい、
その勢いのまま説明を始めてしまった。結局、私の口からはぐしゃぐしゃした言葉しか出てこなかった。
・単体テスト仕様書を作ると、割りとテストケースが足りてない。しかもそれは難しい観点のケースじゃないんだ。
自分の中で、もはや当たり前になってた観点なのに、ときどきボロンと抜け落ちる。
・誤字脱字などのケアレスミスも多い。印字切れとかもよくやる。
・主体性がない。責任感がない。当事者意識がない。進んであれやりますこれやりますって、言ったことないなあ。
…もし上記を読んで「あーああいうタイプの人間ね」みたいに想像ついた方いらっしゃったら、
恐れ入りますが現状を改善するためのアドバイスをいただきたいです…。
上司に「そのままのキャラでいいよ」といじられるけど、本音は"もう諦めてる"なのかなあ。
ちゃんとした人間になりたいよ。
派遣会社から派遣されてくるSEの質が悪すぎて怒りを通り越して無に近づいてきてる。
クソみたいな障害を切り分け、ひと段落ついたついでに愚痴らせてくれ！！！！！！！！！！
派遣SEだから酷いのか、酷いから派遣でしか働けないかは知らない。
今まで三年働いてきて、周りで見ていてひどかった奴らを順番に紹介していく。
そいつらは、私の会社が入れた奴だったり、元からその現場にいたやつだったり様々だ。
5ページ構築するごとに「疲れた、もう無理」と嘆き、周囲に不満を漏らす。
同時に、タバコ休憩に向かう。休憩に行ったら30分帰って来ないが、そんな奴はよくいる
構築をサボって普段使わない端末の前に座っていたため何してるのかと覗き込むと、ひたすはエクセルでドット絵をお絵かきをしていた。
参考URLはこちら。
http://tera-hirakata.jugem.jp/?eid=791
2、数日で蒸発男
よくいる奴。今まで3人ほど遭遇。
数日出社したのち、インフルだ風邪だと言って来なくなり、そのあと連絡が途絶える奴。
40ちかい派遣のおっさんによくいる。就職氷河期だったから大変だったんだよね！わかる！わかるよ！！わかるからさっさとIT業界から消え失せろ。
25くらいの女と40くらいの男。
二人はこの作業場で出会った。ペアで作業をすることが多かったが、作業をしているよりも言い争いをしている時間の方が長いのではないかというくらい酷い奴らだ
ある日突然二人とも休み、その翌日、男は会社に来たが、その日以降女は会社に来なくなった。
どうやら「女の両親が倒れた」らしい。真実は闇の中だ。きっとDV男と一悶着あったんだろう。
男と女が休んだぶん、女がこなくなってから1週間の仕事はすべて当時最年少だった私に降って来た。許すまじ。
ただ単純作業だったため、やつらが23時まで残業してた作業が定時で終わったのが唯一の救いだ。どんだけ非効率なんだよ。
業務内容の説明をすると、「うっす」「ういっす」と返事をする。返事をするが一切内容を理解できていない。
何度もこの環境にはA、B、Cの環境があり、それぞれのIDとパスワードはコレだ、と言ってもメモも取らず返事をするだけ。
案の定パスワードを間違えまくり、アカウントをロックさせ、「なんか入れなくなったんっすけど」と言いやがる。
「メモしてください」と言ってようやくメモするが、メモしたノートを見ないためまたアカウントをロックさせる。
そんなクソ野郎なのに、shift＋deleteで完全削除できるという小ワザを身につけやがってて、本番サーバのファイルを消し、隠蔽しやがった。
ファイルの更新日付を確認したいと言ったはずなんですけど？？？あ？？？？？？なんで消えとんじゃ、クソ男。
何が「これ、テストサーバーじゃないんっすか？」だよ、作業前にこのテストドメイン使えって言ったのに本番ドメインに接続しやがったのお前だろ？しね。
消えてから2年近く経つが、思い出すだけで今でも相当胸糞悪い。
30男。ただの反抗期。4の男と類似。メモを取らない、覚えないためいつまでたっても私に聞いてくる。
「大事なことなのでメモ取ってください」というと、「今取ろうと思ってた」と言い紙とペンは手に持つが、何も書かない。
テスト中に集中力が明らかにキレてるため、「15分休みましょう」と言うも、「いいっす、大丈夫っす」と言い、テストを間違えまくる。間違えた部分を仕方なくダブルチェックで指摘すると、「テストケースの書き方が悪い」とキレる。
そしてワキガで超臭い。隣でテストをしてるとその匂いに頭が痛くなり、テストに集中できない。
同期や同業他社の友人にこの話をしても、そんな人今までに1人出会ったかどうかくらいだ、と口を揃えていう。
ほんとかよ？？？？？
転職して参画した案件（PHPでWeb業務システム構築）が、ネットで聞いてた「SIerあるある」まんまだった。
その中でも結合テストが謎。
1000項目以上あるテストケースの一つ一つ、心を込めてエビデンスを取っている。
・WinShotでログインから１動作ずつキャプチャとる（ボタンのところにカーソル合わせて「ここ押す」感まで出す）
・Apacheログ、アプリログ、試験前後のDBのdumpをとる
これ、誰が見るんだ。何のために取るんだ。
お客に対して「ちゃんとテストしたよ！証拠もあるよ！」くらいの意味しか見出せない（お客だってサマリーくらいしか見ないだろう）。
メンバー曰く、「不具合があった時にどういう状況でテストしたかを確認するため」とのこと。
どういうテストしたか、なんてテスターの不備を追求してる暇があるなら、さっさとバグを直せばいいじゃん。
そんなに吊るし上げしたいのか。
一番怖いのは誰も文句言わず黙々とキャプチャとってること（自分もだけど）。
汎用系のエンジニアからRubyのエンジニアとして転職して1年。
コボラー（笑）なんて言われることも多いが、この1年で出会ったRubyエンジニアは全て糞だった。
その特徴はだいたいこの3つだ。
やれテスト自動化だ、やれテスト駆動開発だの口だけ達者なエンジニアの多いこと。
そもそもブラックボックステスト、ホワイトボックステストを分かっていない奴が多すぎ。
テストコードでカバレージが100%だったとしても実際の打鍵結果でエラーは弾けることが多いのにリリースしてしまう。
ドキュメントを揶揄し机上デバッグも行わない、こんな状態で「アジャイルですから」とかドヤ顔でいってしまうRubyエンジニアは糞である。
そもそも自分が行おうとしているソートが何ソートなのか知っているのか？計算回数を考慮した上での実装か？
便利なメソッドがたくさんあるのは知っている。
ただ、中身くらいは知っておこうよ。
新人に教えたらバカにされたけど、まずフローチャート書くようにしようぜ。
「Githubで公開されてましたんで導入しました」じゃねーよ。
得体の知れないコードをたくさん詰め込んだプログラムをよく動かせるな。
そんで都合の悪いところだけコードを読んでオーバーライドする。
影響範囲を全く調査せず、Gem絶対神話を唱える。あれなんなの？
いや、Rubyが便利なのは認めるよ。俺だってPLIとかCOBOLより書いてて楽しいよ。
エンジニアもどき量産言語だね。どれか１つでも当てはまった奴は小学校からやり直せ。
追記
意見がたくさんもらえて喜ばしい。
文化の違いという意見もあったが、「よくわからないけどなんかうまくいく」コードだとデバッグも大変だし不具合も起きやすい。
「だいたい」とあるだろう。全てのだいたいだ。
＞フローチャート糞
精神論に聞こえるかもしれないが、フローチャート書いて育ったエンジニアは頭の中でロジックの組み立てと凡その演算回数が計算できるようになるよ。
＞カバレージが100%だったとしても実際の打鍵結果でエラーは弾ける
あー、ここは誤タイピングだわ。
自動テストでカバレージ100%です、そして画面数回触ってリリースしますーっていう奴が多いってこった。
単体だけじゃなく画面使ったテストもケース表書いて網羅性を担保しないとダメだろ。
そろそろ報道が下火になってきた、神奈川の傾斜マンション事件。どうしても個人の犯罪に変換したい報道姿勢はどうかと思うのだが、安心するためには仕方ないのだろう。
しかし、現代においてマンション以上の社会基盤であるコンピューターシステムの設計にはどうして一級建築士のような資格制度がないのだろうか。東証が止まり、ニューヨークストックマーケットが止まり、空港業務がとまり、ＡＴＭがとまり、１月１日午前０時に流量規制を実施されるというのに、今回のマンションほど加熱した報道もなければ、犯人探しもない。実に奇妙だ。世界中がコンピューターシステム関係者を擁護しているのかもしれない。時折ほとぼりがさめたころに敗軍の将が兵を語る程度である。実に、実に奇妙だ。これほどの影響が出るのだから、もっともっと事件として扱うべきだろうし、設計には資格を設けるべきだろう。しかし、実際の設計現場には何の知識もない派遣社員があふれかえり、テストケースは過去のそれを流用し、他システムのソフトウェア設計を流用し、ハードウェア構成を流用しているだろうに。
今回の傾斜マンションは個人の財産が毀損したため「もしかしたら私のマンションも」という不安が背景にあるのは想像も理解もできる。しかし、あなたが使っているスマホに謎のチップが、プログラムが、世界のどこかのサーバにデータを送り続けている、グーグル検索記録が残り続ける、文字変換の履歴が残り続ける、ネットにつないだテレビ、レコーダから利用履歴がどこかのサーバに、ラインのログが残り続ける、あらゆるアクセスしたサイトにログが残り続けるのは不安ではないのだろうか。おそらく今回のマンションの事件は誰でも目に見えてわかるからこれほど煽情的な事件となったのだろう。ケータイショップ店員のグチ、家電量販店店員のグチ、とかをみると、説明してもわからない人の事例が目立つ。とにかくバカはバカだと思い知らされることを恐れるのだ。しならい、わからない、と言わないのだろうか。よく新人社員に「同じことを二回聞くな」という低能がいるが、それに通じる自己尊大化の患者だろう。
システム開発の現場にいると、マンションで例えるな、ちゃんとした長さの杭が届くことがマレだ。なんだかんだで届かない。杭が届けばまだいい方だ。杭が来たのだから。
サーバ屋が友達紹介で仕事も持ってきて、そいつが客との窓口をやっているのに、金のことは知らないといってきやがった。
ボクの初仕事でどうなるかわからないから、格安で受けたと取締役に説明を受けていたのに、そんなことは知らないといってきやがった。しらないわけがないだろう！ボクがへまやらかして、今その調整をしているのはそのサーバ屋なんだから。
今思えば、”初仕事だから格安”ってどういう意味なんだろ？今陥っている状態は”初仕事で格安”だから仕方ないのか金額が少なくて済んでいるのか。
人懐っこい感じの取締役で、この人となら仕事できるかなーと思ったけど、単なる人たらしらしいや。
でも悪い人じゃないだろう。順境なら「この取締役と出会えてよかった！」と思っているはず。人たらしなだけで、最初からボクをだますつもりじゃなかったろうからね。
この取締役、よく言えばボクたちを個人事業主としてちゃんと立てて話をしてくれる。それなのに身内として取り扱ってくれる。ただし今のような状態になったら容赦しない。←文面にすると企業の取締役として当然だね。むしろ懐が深い。
サーバ屋と取締役との温度差をすごく感じる。ベクトルが違う。会社って外から見ると全員が同じ性格と価値観と思ってしまうけど実際は違う。取締役はその器でサーバ屋を抱えているのかもしれないが、サーバ屋と仕事するボクはサーバ屋のまっすぐすぎて曲がらないところを直撃してる。まず謝らない。というか、悪いと思っていない。
毎日のようにAの仕事の進捗を上げて遅れてることを認識しているはずなのに、Aの次に行う予定だったBの仕事が順調に進んでいると思っていたようだ。少し言い方が違うか、Aが遅れていることがBの遅れに直結しなかったようだ。
Bが遅れている事態に相談をするときに「連絡をくれてすみません」と取締役とサーバ屋にハングアウトしたらサーバ屋が「たしかに遅かったですね」と上から目線でいってきた。ボクの感覚からすると、会社や取締役に対しては連絡遅れはサーバ屋も共犯だと思うんだがなぁ。Aの遅れもボクの担当する前のやつの部分の直しがほとんどだ。それに気づかずに遅れてしまっているのもボクのテストケースが少ないから気づかなかったからで100％ボクが悪いらしい。簡単にネットの強い言葉を使いたくはないが「アスペじゃないか」とサーバ屋を否定しないとボクのほうで気持ちが落ち着かないところまで来てしまった。サーバ屋とはもう作業はできない。
他人事に思えばボクが悪い。やると言ったのに約束を守れないボクが悪い。迷惑をかけているのはボクだ。でも、もう金払うから開放してほしい。
アニメ業界って分業化が適切に進んでて、それぞれの職種が有機的に結びついてて、監督の権限（責任）が行き届いてて組織として結構理想的な気がする。（実際の現場はしらないけど）
絵コンテを書いて衆目にさらされる最終的な成果物の全体像を導く監督的な人ってSIにいるっけ？
アニメでいうところの原画、動画、動件、CG、BG、音響、その他諸々の専門っぽい人は下流の下請けで指示書通りに作って、
元請けは制作進行（この言葉が正しいのかわからないけど）的なことが中心になってない？
どうも仕事の分業や各職種間のパワーバランスがおかしい気がする。
＊＊＊＊＊＊＊＊＊＊＊
疑問に思ってるのは元請け様が偉そうにふんぞり返って作業指示ばかりしているなんてことではなく、
（実際、アニメの制作進行が激務なように、要件の調整や、折衝等で作業的にはトップレベルに大変だろうし）
分業のありかたに違和感があるのと、
言語、フレームワークの選定や、（拡張性なり保守性なり効率性なりなんなりを重視した）モジュールの設計、デザインの監修みたいな
成果物の本質的な品質（バグ検出密度やテストケース密度なんてものではなく）に責任を持つ役割の人がPMBOK的・ウォーターフォール的な組織にはあんまりいないんじゃないかってことです。
なんでだろう。
なんか、変に話が大きくなってますが、元SIerとしては単なるあるある系のクソ仕事話の一つって感じの、Excelスクショエビデンスについて話をしておこうと思います。
最初に結論を言っておくと、
「意味があるのは分かっているが、そもそも責任回避のための資料作りなんて出来るだけやりたくないし、そんなのが大量に必要であること自体が気に入らねえ！」
ってことです。
参考:
Excelスクショ問題について周りの方へのお願いと、今職人となっている方への励ましの言葉（元職人より） | 羽根帽子の太公望
まあ、意味があるのは分かる。やってた事もある。
とは言え、何の意味かというと発注元の企業とゴタゴタが起こった時の責任回避の資料作りという意味で。
後になって問題が起きた時に原因究明の資料になるとかいう話もありましたが、それはかなり怪しい。
適切な粒度で切られたテストケースと更新がある度に正確にメンテされ続けるドキュメント管理力が必要ですが、そんな信用度の高い文書あんまり見たことない。
結局、動いてるシステムとソースコード見るしかない。その時の参考資料になるドキュメントは必要だと思いますが、それがExcelスクリーンショットかというと……。
どうしても再現環境を用意できず、机上で推論するしかない場合は役に立つかもしれませんが、そもそもそんな重要なシステムで何でそんなところケチってるのか意味が分かりません。
後、ソースコード読めない上流のSEがバグ原因を推定してお客様に説明する、という不毛な作業をする時にも役に立ちますね。
やはり、責任回避のための言い訳資料を作る、という名目が強いように思えます。
大半の人にとって、そもそもこういう資料作成自体が不毛でやりたくないと思います。
テスト工程とか余計なこと言わずに、訴えられて損害賠償請求されたくねーからやってんだ！と新人に説明すべきだと思う。
(こういう事ネットには色々書いてあるんだけど、会社は教えてくれないんよね、何故か)
大体、なんでこんな事やってるかっていうと発注元の受け入れ作業をベンダーが肩代わりしてるからです。
自分が注文したものがちゃんと動いてるのかの確認までベンダーに投げるので、「やった」「やらない」を過剰に説明する資料が必要になる。
専門知識を持った人材を抱えておくことをコストだと考えてるから、もっと無駄な事が世の中に発生してしまう。
そして、これのせいで付随して更なる問題が発生する。
顧客提出する資料に専門用語を含めた説明文を書くと、言葉が理解できない、という理由でリテイクをくらう場合があります。
説明資料じゃなくて、開発者や運用担当者が参照するための技術資料なのに、技術的に正しい、とかはどうでも良くて顧客が理解できる言葉で書け、ってことですね。
向こうのレベル感を探り探りしつつ文言を選んで説明分を付与する不毛な仕事が求められるのです。
これが顧客に対する誠意だと言うんですからお笑い種なんですが、まあ向こうがそれに金払う、って言ってんだから作るんでしょう。
既に十分不毛なんですが、これに輪をかけるのが体裁というやつです。
スクリーンショットの位置や文頭が微妙にズレてたりすると怒られるやつです。
それが、そんなに重要なのかどうかについては、最後まで分かりませんでした。
項目幅を調整して印刷可能なページに適切に収めるのに消費される時間が辛い。
後、カーソルをA1に戻しとけ、とかも全く意味が分からないし、納品前に数時間かけて印刷して判子を押して回るのも意味が分からない。
こんな単純作業を人間が手動でやっててミスらん訳が無いだろうに。
気を付ける、とか真剣にやる、とかで解消できると思ってるなら、お花畑過ぎるだろと言わざるを得ない。
しかも、自動化するために諸々やってると、最悪サボってると見做されるし、ひどい場合は、作業用PCに使えるソフトが限定されてて、スクショ取るツールさえ入れられない事があるらしい。
そこまで行かなくても、社内プロキシの穴を付いて開発環境を落としてきたりして、最悪セキュリティ担当の人に怒られる場合がありますね。
なんでこんな面倒なことしなきゃならんのだとソウルジェムがガンガン濁っていきます。
(メモ帳でもありゃいいだろ、という話もあるかもしれませんが、俺のような凡人はそれはそれでソウルジェムが濁ります)
まあ、それを回避して何とか自動化して省力化できるようになったら、他の人の作業時間と同じぐらいの見積り出して、本当にサボるんですけどね。
ダラダラと色々書きましたが、まとめるとこういう事です。
企業活動として意味があるのは分かるが、その根本的な目的は誰かが手抜きしたコストを肩代わりしてるだけに思える。
ただ資料を作るだけじゃなくてすげー細かい注意が必要になるのだが、そこに合理的な意味があるのか分からない。
作業自体がめっちゃ面倒くさいのだがその面倒くささを解消する方法に何故か制限がかけられている。
そして、世の中のプログラマーがどうであるかは知らんけど、俺はそんな作業が大嫌いだ。
むしろ、Excelにスクリーンショットを取って張るなんてのはどうにでもなるんだけど、それに付随している業務慣習の大半が意味分からなくてクソ喰らえである。
というわけで、意味があるとかそういう主張はどうでも良くて、そんな仕事やりたくない。
まあ、それしか金を得る方法が無いんだったら、嫌々でもやりますが……。
しかし、そもそもの話、実際冒頭で挙げた参考エントリの人も心病んでるし、他にも病院送りにされてる例が多数あるわけで、
仮にこれが本当に必要だと認めるにしても、人間の心をすり潰してまでやらなきゃならないような工程が、
当然のものだと受け入れられてる業界は最悪じゃねえのかと思う。
従業員の精神を壊してまでやらなきゃいけないような事なのか、これは。
必要とか必要でないとか以前に、こういう事やると人間の心が病むんだよ。そんなものが仕事なんだったら、そりゃ人間働かなくなるだろうよ。
そんなすぐに世の中変えようもないしどうしても作らなきゃいけないんだ、という場合は、せめて自動化に対する障壁を外して欲しい。
見た目の凝り具合とかは本当に必要な最小限度の体裁にして欲しい。
テクノブレイク.jpという、エロ専用RSSサービスを公開しました。
これは、自分のお気に入りのエロサイトの更新動画を、サイトすべてに訪問して確認しなくてもチェックすることができる、というエロのための時間を効率化させるWebサービスです。
今年文系で大学を卒業し、まったくの未経験で大手IT企業に入社し、研修を経て初めてプログラミングを触ることになりました。
それでも少しはできるようになったため、「ゆとり」でも「未経験」でも「文系」でも自分でwebサービスが作れるんじゃないか？と思い至り、ちょっと力試しということでやってみるか！！！とこのサービスを作りました。
僕は以下のような人間ですが、「仕事」を通じてプログラミングを学びました。もちろん今も勉強中です。
まだまだ働き始めたばかりなので、僕はプログラミング初心者が数ヶ月勉強したという方と同じような人間です。
なので現在上記にあてはまる人でも作ろうと思えば「自分でサービスを作れる」ということがわかっていただけたらと思います。
僕はオナニーをする時は、スマホのアプリで必ずエロ動画を探すのですが、だいたい以下のようなステップを踏むんですよね。
このように１つの動画を見るために、９つのステップを踏むんです。
もう何がいやだって、（７）ですよ。これが面倒くさい。
それから（２）のブックマークからエロサイトを開くことも面倒じゃないですか。
だって（１）〜（９）をサイトごとにやらないといけないわけですから。
これらを簡単にすることができないもんかなと。
だから、毎回だらだら開発を進めると時間がかかり、最終的にモチベーションが下がり、何もしなくなってしまうんです。
プログラムだけじゃありません。デザインを考えたり、仕組みを考えたりしないといけません。
あとで、このプログラムじゃ、仕組みじゃダメだったな、ってわかり手直しをすることだってあります。
すべてをそこそこ、８０％におさめてください。
最初はすべて８０％です。
ここで言う１００％とは、あなたの考える理想を１００％叶える、という意味です。
そういった意味では１００％はありませんが、あなたにとっての理想の１００％はありますよね。
走りながら、目指してください。
早くリリースすればするほど、ユーザーからの声を早く拾うことができます。
ユーザーの声こそ、そのサービスの目指すべき姿のことが多いです。
８０％完成してリリースすればいいのに、残りの２０％を埋めようとあなたが頑張ったとします。
もしかしたらその自分勝手な２０％は、ユーザーに取っては不必要な２０％かもしれませんよね。
なぜならドメイン代を支払ってるんですから。その金を無駄にしたくないですよね。
で、サーバーは後、というのは開発が無駄に３ヶ月かかったとすると、その３ヶ月分のサーバー代金が無駄ですよね。
実サーバーテストは、テスト環境でテストを終えてからやればいいかなと思ってます。
まずどんなコンセプトか、どんな機能が必要か、どんなUIにすべきかという目標をたてましょう。
なぜこうするかというと、常に自分が何をすべきかが明確になるからです。
なにも決めずにやろうとすると、
なんてことになります。
だから、頑張りすぎなくていいんです。
Webスクレイピングとは、サイトのコンテンツから欲しいデータを取得する方法です。
僕がどうやってRSSサービスを作ったかというと、このwebスクレイピングのおかげなんです。
広告、注目動画、アーカイブなどのそのサイトのコンテンツははじきます。
で、その主要コンテンツから、記事の画像とタイトル、URLをゲットしてきます。
やり方としては、主要コンテンツからそのサイト内部のリンクが貼られたimgタグを探し出します。
そして、そのリンクのタイトルまたは記事のタイトルを取得します。
こうすることで、そのサイトの更新一覧から更新記事のURLとタイトル、画像がわかります。
BootstrapはウェブサイトやWebアプリケーションを作成するフリーソフトウェアツール集である。 タイポグラフィ、フォーム、ボタン、ナビゲーション、その他構成要素やJavaScript用拡張などがHTML及びCSSベースのデザインテンプレートとして用意されている。
これを利用すると、基本的なWebサイトのデザイン（htmlとcss）が手に入れることができ、そのまま利用できたりします。
デザインを作る上で、非常に助かります。なぜなら最初からすべて自分でコーディングする必要がないからです。
僕は以下の時間に開発をしてました
だと思います。
どうしているかというと、Readdleの「Downloads」というスマホアプリを利用しています。
これは写真やファイルをクラウド上に保存したり、Dropboxや外部サーバーとファイル共有をすることができるアプリです。
画面は小さくてストレスがかなーーーりありますが、僕は外出中はこれでプログラミングをしています。
通勤中にこれでプログラミングをし、降車した後の徒歩で続きのプログラミングをキリが良いところまでする、という感じです。
また、歩きながらでもテストはできると思うので、歩きながらプログラミングは難しいという方はテストだけでもやってみはどうでしょうか。
Webサービス俺もやってみようかなーと少しでも思ってくださった方へ、
僕は開発をしながら、本当にやりたいことがあったら、時間はいくらでもつくりだせるなって感じました。
歩いてるときだって、トイレにいるときだって、電車にいるときだって、いつだって今の時代はできるんですよ。
それだけ現代って便利で、生きやすくて、なんでも挑戦しやすい環境のある時代なんです。
恐らく、少し前の時代、スマホが出る前の時代では歩きながらプログラミングなんて考えられないと思います。
そう考えると数年前と今って格段に何かを始めることができやすい時代なんですよ。
それでも挑戦しないって、もったいないねーなーって思ったんですよね。
だから、なにか本当にやってやりたい！！！ってことがあれば、まず一歩を踏み出してみてください。
ググれば、一発ですよ。
こんなことGoogleが日本に来るまでは考えられないことですよ。
だって、昔の検索エンジンって十分に欲しい情報が手に入らなかったですもんね。
僕も高校時代とかCROOZ？とかヤフーカテゴリー？とかで携帯でぽちぽち検索してた記憶があります。
初心者向けのランクC問題でさえ、回答想定時間に間に合わない。
Cを使ってるが、文字列の扱いだけで結構手間取る。１個だけたまたま時間内にできたのでCランクになったけれど他のCランクの問題に挑戦するも時間切れ。想定回答時間２０分の問題に２時間かかる。そして提出するもテストケースでエラーが発生する。もちろん問題に記述されているテストケースはクリアした上で提出している。しかし、それじゃダメなんだろう。Dランクと言われても受け入れるしかないくらい。仕事で行うプログラミングは、あらゆる状況を網羅したテストケースを作ることが出来なければ通用しないってことなのだろう。テストケースが用意されてれば、それに対応できるとは思うのだけど。あらゆる状況を網羅したテストケースを作れるほどにはスキルがない。
趣味でプログラミングやってる程度だけど「俺だってやろうと思えばプログラミングの仕事くらいできるよ」とか思ってたが、全くダメだ。なんだか恥ずかしくなってきた。
例のAppleのSSL/TLSのバグの件、日本語情報がなかったので意訳しました。
Adam Langleyさんによって書かれた原文はこちら。要所要所に親切なリンクがついているので、ぜひ原文も見てみてください。
Apple's SSL/TLS bug (22 Feb 2014)
https://www.imperialviolet.org/2014/02/22/applebug.html
(Hi Adam Langley, Than you for your blog! We really appreciate you.)
-----
昨日、AppleはばかばかしいiOS向けのセキュリティアップデートを発行した。 それは詳しく明かされていないが、SSL/TSLについてとんでもなく恐ろしい間違いを示すものだった。 その答えは既にハッカーニュースのトップにタレこまれている(https://news.ycombinator.com/item?id=7281378)し、アップルが隠したい秘密はもうバレてしまっていると思う。 そして現在、俺たちはその誤った情報を正すステージに来ているんだ。 ほらここに、Appleのbugがあるんだ。：
static OSStatus SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams, uint8_t *signature, UInt16 signatureLen) { OSStatus err; ... if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0) goto fail; if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) goto fail; goto fail; if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0) goto fail; ... fail: SSLFreeBuffer(&signedHashes); SSLFreeBuffer(&hashCtx); return err; }(Quoted from Apple's published source code.)
(訳者注：(Quoted from Apple's published source code)→sslKeyExchange.c) 2行のgotoがあるだろ。 2行目のgotoは、見て分かる通り常に発動する。 変数[err]にはエラーを示す値が入らず、正常を示す値のままfailに飛ぶってことだ。 それって成功したのと同じなんだよね！ この署名検証処理は(訳者注：SSL/TLSハンドシェイクのやりとりのうちの一つである)ServerKeyExchangeメッセージの署名を検証するものだ。 このServerKeyExchangeでは、"the ephemeral key"（通信のための一時的な鍵）を交換するためのDHE や ECDHE という暗号スイートが使われる。 そのサーバーは言うんだ。 「ここに"the ephemeral key"と署名があるよ、ほら、これが証明書だ。君はこれが僕からのものだってわかってくれるよね！」 今、もし"the ephemeral key"と証明書の関係が破たんしているならば、すべては無意味なんだ。 これってつまり、正規の証明書チェーンをクライアントに送信したけど、ハンドシェイクへの署名には正しくない間違った（つまり適当にその辺で作った）鍵を使ったり、そもそもハンドシェイクに署名しなかったりってことができるってことなんだよ！ そこには、今君が通信しているサーバーが、サーバー証明書に含まれる公開鍵の秘密鍵を持っているってことの証明が、何もないんだ。 これはSecureTransport(というライブラリ)に入っていて、以下に影響する。 ・iOS 7.0.6より前(俺は7.0.4で確認した) ・OS X 10.9.2より前(10.9.1で確認した) (訳者注：つまりiOS 7.0.6、OS X 10.9.2で解決した) これはSecureTransportを使っているすべてに影響するけど、ChromeとFirefoxはそうじゃない。 ChromeとFirefoxはSSL/TLSのためにNSSを使っている。 でも、それはあんまり君のマシンがSecureTransportを使っていないってことを意味しないよ。(ソフトって更新されるしね) 超特急でテストサイトを作ってみたよ。https://www.imperialviolet.org:1266 ポート番号に気を付けてね。(テストサイトはCVE番号になってるよ) 443は通常通りに動いているからね。 ポート1266のサーバーと443のサーバーは同じ証明書を送っているけど、完全に異なるキーで署名しているんだ。 君がもしポート1266のHTTPSサイトにアクセスできたんだったら、君のマシンはこのイケてるバグを抱えてるってことだね。:) それってつまり、証明書チェーンは正しいってことで、そしてハンドシェイクと証明書チェーンの関係は壊れたってことで、もう俺はどんな証明書も信じないよ。 またこれは、DHE または ECDHE 暗号スイートを使っているサイトに影響を及ぼすだけじゃないんだ。 攻撃者は、この暗号スイートを使うサーバーを自分で建てるようになるだろう。 また、これはTLS 1.2には影響しない。このバグを含まないTLS 1.2の別の関数があったから。 でも攻撃者は使うプロトコルをある程度選ぶことができるから、安心できないよ。 (訳者注：サーバー側がTLS1.2を使えないことにしていたら、それ以外の例えばSSL3.0とかTLS1.0とか1.1で通信が始まっちゃうから。) でもでも、クライアント側でTLS1.2だけを使えるようにしておけば、それは今回の問題の回避策になる。。 同じく、クライアント側でRSA暗号スイートだけを許可するということも、ServerKeyExchangeが発生しなくなるので今回の問題の回避策になる。 (2つのうち、1つ目のほうがだいぶ好ましい。) 俺のテストサイトでは、iOS 7.0.6 と OS X 10.9.2で問題は解決していた。 (更新：このバグはOS X 10.9 のときに入ったように見えたけど、iOS6にもっあったぽい。iOS 6.1.6は昨日リリースされたよ。) こんなような微妙なバグって、悪夢だ。 俺はこれは単なるミスだと思うし、なんかもうほんと最悪って思う。 ここに、今回の問題を明らかにするコードがある。：
extern int f(); int g() { int ret = 1; goto out; ret = f(); out: return ret; }
もし俺が"-Wall "を付けてコンパイルしたとしても、XcodeのGCC 4.8.2 や Clang 3.3は死んでるコード(the dead code)について警告をしないんだ。 本当にビックリだよ！！！ ここで警告が出ていたらこの問題は止められたのに。でもたぶん、現実には死んでるコードが多すぎて無視することにしてるんだろうね。 (ピーター・ネルソンが教えてくれたけど、Clangはこれを警告するための"-Wunreachable-code"を持ってる。でもこれ、なんと"-Wall "には含まれてない！) if文に{}をつけないことを許すコーディングスタイルはこの問題を誘発したかもしれない。 でも、人は{}を付けたとしても間違ったプログラムを書くことがあるから、これは俺はあんまり関係ないように思う。 テストケースはこれを見つけることができたはずだけど、今回のはいろいろ条件が複雑なやつだったから難しかったと思う。 TLSのめちゃめちゃ多くのオプションを試さなきゃいけなかったからね。しかも正常系じゃないやつも。 俺、TLSLiteでちゃんとテストしてるか思い出せないもん。(月曜日怖いかも) コードレビューはこの種類のバグについて効果的でありえる。 ただし単なる審査じゃなく、それぞれの変更に対してしっかりとレビューすることだ。 Appleのコードレビューカルチャーがどんなもんか知らないけど、もし俺が同じようなことをやっちゃったとしたら、同僚のWan-Teh や Ryan Sleevi がばっちり見つけてくれたと、固く信じてる。 でも、誰もがそんなにいい仲間を持てるわけじゃないよね。 最後に。昨日、Appleが証明書のホスト名をちゃんとチェックしていなかったことについて多くの議論があったんだけど、 それは OS X のコマンドラインでcurlを使うと、IPじゃない証明書でもIPでHTTPSにつながっちゃうってだけだったよ。変だけど。 Safariはこの問題には関係なかったよ。
