  |
はてなキーワード: エラーメッセージとは
だって、細かく書けば書くほど全部読まないんだもん。
画面設計書いて、そこに表示する項目と入力項目を細かく表に書いて、そこにその項目は必須入力じゃないって書いてあるのに、
受け入れテストで入力エラーが出ないとはずのところで入力エラーが出るの確認する。
ちゃんとエラーメッセージの表を作って渡してるのに、メッセージが間違ってる。
データ項目としては定義されていないが、この機能は別の項目にこういう入力をして表現するからこういう動作をしてくれって書いたと思ったけど、
仕様書通りになっているかどうかのチェックから始める必要があるのはおかしいだろ。そこは仕様書書かせるなら最低ラインじゃね？
メンヘラの条件は、以下のいずれかを満たしている事としてみます。
先ずは、メンヘラが陥りがちな心理状況です。
病的になると、恐らくは何をやっても、空回り。どうしようもない状態になるので、
定型のうつ病対策が効果的です。非定型については、省きましょう。
理由として、ドロップアウト、もしくは気味の人間なので、社会から見れば、同年代と比べ
価値があまりないのですが、少し語弊がある言い方をすると、最低限その間は
甘やかされてきたので、自分自身に力があるように思い込みます。
そう、思い込まないとやってこれなかったので、自己肯定するか、他所のせいにしていたはずです。
目的1つに絞って行動するのが常ですので、成果は出ます。寛解です。
1日1週間でわかるものではないので、数ヶ月はかかるでしょう。
社会との折り合いをつけるために、自分のおかしさ、異常さに気づいたしても、
ただ、身体上はよくなってもまだ早いかもしれません。
焦ると、巻き返しをしようと気張ればすぐにリバウンドです。
ここで、悪循環に入りやすい、もしくは同様の失敗をおかす可能性が
あるものとしては、第三者が口を出せない状況が続くということです。
とラフになにか言える信頼関係づくりが希薄だと、勘違いしたまま進んでしまいます。
あまり親しくない間柄では、善意のつもりが、イジメになってしまいます。
別段、直接「おかしい」と伝えなくても、相手に気づいてもらえればそれでいいので、
気づく力がありそうなら、何か伝わるようにしたり、見守ればそれでよさそうです。
言ってくれる人も鬼ではないはずなので、ここまでの痛みなら受け入れるだろう。
と勘案した上で伝えてくれていると信じたいところです。
薬というのは、毛布のようなもので、強い薬は分厚い毛布です。
外からの声、音が聞こえなくなる分、薬を断てば大きな声、音が強い刺激として入ってきます。
体調がよくなった上で、外界からの刺激全てに耐える力が出来てからが、本来の寛解にも考えます。
そろそろ本気を出していいとおもいましたか？
まだです。
最終調整に必要なのは、衰えた体力と、使わずにいて錆びた頭を動かすことです。
とても難儀です。1,2ヶ月で取り返すことは出来ません。
話がふりだしに戻って、通しでご覧になればわかるとおもいますが、最初の話です。
上記3点くらいまで来てしまうと、1年程度は調整が間に合わないようにも見えます。
ここまでは状況説明です。
ここで、詰んでいます。
なぜなら、上記3点の経験者は、精神面で持ち崩しやすいからです。
観測し続ける限り、ほんとうの意味で寛解はしていないし、思考が子供のままです。
社会の理不尽（とも思うべき折り合いの多さに慣れる）と付き合うには、
・レシピを見ない料理や、掃除といった、脳が無意識に手続きを考えなければならない事をする
・習慣化された手続きを作る、行う。散歩やtail -f で/var/log以下を見て、エラーメッセージを解読するなど
今朝のスッキリで手巻きピザが紹介されたせいで、ピザーラのサイトが一時的にアクセス集中でエラーになった
おそらく503エラーと思われるが、httpヘッダがshift_jisなのに、aspxのデフォ設定がUTF-8のままっぽくてエラー文がutfで吐き出されてた。
IEならこれでも表示できちゃうんだろうけど、firefoxとかだとおもいっきし文字化けする
返ってきた文章は、「今はエラーも出ずにちゃんと見れてますので確認してみてください。エラーの設定は影響範囲が広いので考えさせて」といったもの。
まあそんなもんだろ。通常あるべき姿でないときに表示されるメッセージに不具合があったところで、誰も困るわけじゃない。
そもそもエラーメッセージすら出ずに白紙になるサイトなんてゴマンとある。至極まっとうな返事かもしれない。
「おたくのお店、停電したとき壁に変な模様が出ますから直したらどうですか？」って言ってるようなものだ。そもそも停電なんて普通起こらない。そこに金かけるかと。
こう来るのは分かってたんだけどねえ。じゃなんで問い合わせしたんだろ。問い合わせないと気がすまなかったのか。
言われる側としては迷惑な話じゃないのか。他人のアラにばかり目が行ってテメエの会社のサーバーはどうなんだおい、と。
まあそんなことを考えさせられました。
最近、地方→中央省庁のとあるデータのやりとりが、Accessベース（Access＋VisualBasic）からExcelベース（Excel＋マクロ）に変わったんだが…。
うちの県ではVisualBasicのランタイムを作業用ＰＣにインストールするだけで折衝に一年越しだったから、一応変更自体は歓迎だったんだけれども、これが…。
ちなみに、扱うデータ量は、ざっくり言って、一都道府県当たり平均で5000行×1000列の表くらい。多い都や府なら、列の方がこの数倍行くだろうな。で、あくまで個人的な感想として、どんな感じかつーと、
(1)データ触ったり集計したりしにくくなった。
前のシステムは、データ自体は単なるAccessのデータだったので、間違いを修正したり別の集計に使用したりが意外と気楽に出来た。
今度は、Excelを無理矢理マクロやらで動かしてデータベース化してるから、Accessの時代よりも途中でデータが触りにくくなった。で、データにミスがあれば、いちいち一番大元の支所の担当者に連絡して最初の打ち込みデータから変更して貰わないとならない。
(2)めちゃくちゃ重くなった。
これは、まあ想像つくと思うけど…重い。Excelとはいえファイルが数十メガとかあって、デカいから扱いに困るし、重さについては、特にデータから選択して表示させる機能が弱いらしく、やたらに時間がかかる。これが結構致命的かも。支所に配付した入力システムですら、４年前のPCではフリーズしまくった（新しいＰＣ使えと言ったら、結局個人用のＰＣ使ったとかいう噂も……ウソでしょ？）。県庁での取込・集計システムは、取り込んだデータの10支所ごとのまとめ表を閲覧表示しようとするだけで大体数分かかる。なお、一支所毎に表示する機能がないので（なんだそれ）仕方なく、支所ごとに、システムから一覧表（紙）を打ち出して送付してもらっているが（なんだそれ）、そうなると今度は、データと紙が一致しないという事例が発生した。表示機能が特に重いので、先方でも、データの中身は余り見ずに送ってるらしく、最終段階でデータいじったのを忘れたりしてそういうことが起こるらしい（なんだそれ）。
これは仕方ないことだが、RDBなら元々ソフトの機能でしていることをマクロでやらせてて、そこを触られたくないからだろうが、やってることの中身が把握できない。で、たとえばデータ保存の際にいろいろエラーメッセージが出ることがあるんだが（２年前のシステムで、標準で.xlsで保存する仕様になってるため、「機能低下が云々」とか）、おそらく問題なかろうとは思いつつも、不安なまま運用してる。
エクセルだから、入力とか扱いとか、気楽になった部分は評価する。なので、データベースとしての運用を想定したＤＢ機能強化版のExcel Proとか出ないものか？ と。
ヤフオクでずっと探していた物を見つけたので、
数年前から使っていなかったYahoo! IDでログインしようと試みた。
しかし、思いつく限りのパスワードを入力してもログインできない。
まず「Yahoo! JAPAN IDを忘れた」のリンクからIDを確認。
記憶している物と相違なかったので、少なくともIDの間違いはない。
なので、間違っているのはパスワードの方。
まぁ、数年使っていなかった訳だし、パスワードを記憶していないのは、いかにもありそうな話だ。
なので、ここ↓
https://account.edit.yahoo.co.jp/forgot_acct?.src=www&.done=http%3A//www.yahoo.co.jp/
やることは非常にシンプルで、前述のように確認済みのYahoo!IDを入力し、
そうすると、次のメッセージが表示される。
エラーが発生したためお手続きができませんでした。次のような原因が考えられますので、ご確認のうえ、お手数ですが最初からやり直してください。
おまえは何を言っているのかと。
順当な手順を踏んで、パスワードを確認したいだけなのに、なんかこっちが悪いみたいなエラーメッセージが出て、それができない。
時間をおいても（と言っても、今日の出来事なのでたかだか数時間だが）変化なし。
そして腹立たしいことに、Yahoo! JAPANには問い合わせをする窓口が無い。
FAQに、ズバリ自分と同じ悩みが載っていなければ、その先を調べる公式の手段は無くなってしまう。
まぁ、問い合わせ窓口が無いのは有名な話だが、自分が必要に迫られるまで、あまり気にしていなかった。
当事者になると、本当に怒りに震える。
IDを問い合わせれば返答があるのだから、アカウントが失効している訳ではない。
それなのに、パスワードを確認できないとは、本当にどういうことなのか。
日を空けたらしれっと使えるようになっているのかもしれないが、
とにかくホトホト呆れる。
大企業が聞いて呆れるわ。
魔が差した。
また私の失敗が他山の石となれば、落命した諭吉も成仏できるだろう。
カーネルの変更、高解像度・マルチタッチへの対応、長期サポート。すべてがまぶしく映った。
UIは旧バージョンとほとんど同じだし、高価なディスプレイ持ってないし、Ubuntuでトラブったら基本自力で解決するしかなくてサポートもヘチマもない。
何も目新しいことはないのだが、恋は盲目というやつだろうか。
「中古PCにインスコしたい」という欲求がふつふつと湧いてきて、どうにも抑え切れなかった。
○ハードウェアのお得感
あれ、良くない。
好条件の商品を探すのに熱中し気持ちが高ぶり、要らんものを買ってしまう。
私「おぉ、XPマシンが即決6,500円じゃないか！ 爆安だゾ！」
普段から中古パソコン相場をチェックしているわけではないから、本当は高いか安いか判断できない。
しかし、頭の中には『買いたい』という結論が先にある。
そこで暴走する私の物欲は、「買い替えによる中古XPマシンの増加で、今リユースパソコンが値崩れしている」という話をでっちあげ、理性をねじ伏せてしまった。
液晶モニター 1,500円
パソコンは20万円、液晶は「1インチ1万円」という時代を知っているから、自然食料品店の催眠商法で羽毛布団を買ってしまうお年寄りみたいなもので、迷いはなかった。
○なんだ普通に使えるじゃないか
幸か不幸か、衝動買いを反省する材料にならない。ﾃﾞｭﾌﾌﾌw
Ubuntuで綺麗に上書きした。サポートが切れてるとはいえもったいない。
ピュアLinuxマシンが手に入り、私はホクホクである。デュアルブートしているWindowsに気兼ねしたり、クソ遅い仮想マシンやUSBにイライラする必要がないのだ。
衝動買いを正当化する材料がまた一つ増え、子供のような物欲は勇気りんりん。
○その他ハッピーなこと
省スペースで場所を取らない。あと、ストロークが深く打ち心地が良い。あまりにも素敵だからもう2個くらいポチりそうになった。
他方、Ubuntuは言うことを聞かない。
パッケージが足りない、競合している、見たこともないエラーメッセージ。つまずくたびにググらなきゃならない。
でも、その手間が楽しい。DVの共依存みたいなものだろうか。「氏ね！ 動け！」とシャウトするごとに愛が深まるのである。
○懸案事項
『ソーセージの中身は肉屋と神様しか知らない』ではないが、『マザボと電源は修理業者と中国人しか知らない』
マザボ(というか電解コンデンサ)、HDD、電源はいつ逝去されてもおかしくなく、不安だ。
○今後の課題
一度、私の金銭感覚を山岳ベースに軟禁して総括する必要があるように思われる。
35,000円でNexus5を衝動買いしたり、米国AmazonからChromebookを個人輸入したり、私は累犯を繰り返している。物欲を粛清し、生産計画に見合った消費を心がけたい。
近年、関数型プログラミングの重要性はいろんなところで叫ばれています。
Javaの最新バージョンに関数型プログラミングに関する新機能が加わりました。
Rubyも昨今、関数型プログラミングへのサポートが手厚くなってきています。
プログラミングの教科書の大手、オライリー社から、Javascriptで関数型プログラミングを行うための解説書が発行されました。
関数型プログラミングへの注目度は高まってきています。
おそらく、みなさんは既にオブジェクト指向が何か、を知っています。
でも関数型プログラミングとは何か、胸を張って語れる人は、周りに見当たらないかと思います。
実際、オブジェクト指向によってプログラミングする方法は、わかりやすい解説があちこちにある一方で、
関数型プログラミングとは何か、何が良いのか、ということについての、よいまとめは見つけることはできませんでした。
この記事を読む方の中で、「関数型プログラミングを取り入れるか・取り入れないか」で切実に悩んでいる人は、おそらくいないでしょう。
この記事はあまり細かいところに立ち入りません。関数型プログラミングを使う側の立場に立って、利点や向き・不向き、それが導くスタイルを書きました。
みなさんは鳥のように飛んで、高い空から、関数型プログラミングとは何か、何が良いのか、を見渡してください。
オブジェクト指向的アプローチは、名前をつけてプログラムを整理する。
関数型プログラミング的アプローチは、汎用部品でなんとかする。
Googleが近年リリースした言語、Goには、”継承”を直接サポートする仕組みが無いことが話題になりました。
また、Mac OSXの基幹ライブラリCore Foundationは、ライブラリ自体はC言語で書かれているにもかかわらず、その設計方針は明確にオブジェクト指向です。
その本質とは"名前をつけて対象を識別し、それを扱うこと"、にあります。
最もプリミティブなオブジェクト指向の対象は、ファイルハンドラです。あるファイルを開いて、読み込んで、あるいは書き込んで、ファイルを閉じる。
これらの処理をまとめたら、わかりやすいですよね？
対象に関する処理を、対象の周りにまとめる。これがオブジェクト指向の基礎的な理念です。
識別することとイコールで比較できることは、とても良く似ています。
イコールによる比較は、オブジェクト指向では鬼門であることが知られています。
PointクラスのインスタンスとColoredPointクラスのイコール演算をどう決めればいいかに、正解はありません(詳しくは"effective java"をご参照ください)。
また名前をつけて識別する対象は、フワフワしていてはいけません。
たとえば、"軍人の階級"をオブジェクトにしたとしましょう。"大佐"クラスのある兵士は名前のフィールドや、性別のフィールドを持っているでしょう。
ところで彼が昇格したときに何が起こるでしょうか。
新たに"少将"クラスのインスタンスが作られます。"大佐"クラスを破棄する前に、名前、性別、その他沢山のデータを引き継がなくてはいけません。フィールドを増やしたい場合はその都度コードに修正を加える必要があります(*)。
なるべくイコール比較を避けたい。対象は不安定なものではいけない。では何に名前をつけて、識別するか。そこにオブジェクト指向技術者の熟練度が現れるのです。
一方、関数型プログラミングでは、特定の何かに名前をつけるより、極力、汎用部品でなんとかしようとします。
関数自体をリストなどのデータ構造に詰めることもよく行われます。
実は、関数型プログラミングというのは本質を表していません。
関数をはじめとして、リスト・ツリーのようなコンテナ、手続きを抽象化したもの、回路を抽象化したもの。
あらゆる対象を値として、合成し、ときに分解し、新しい値を作ります。
変数に適用する処理を作りあげることが、とても簡単だからです。
四則演算が定義されたデータを詰めたデータ構造もまた、四則演算可能だったり。
誤解を恐れずに言うと、オブジェクト指向がトップダウンなのに対し、関数型プログラミングはボトムアップです。
関数型プログラミングをサポートする言語には、沢山の汎用部品が定義されています。
このような構造をインターフェイスとして、様々なライブラリが組まれているので、
たとえばモナドを知っていれば、30分程度でパーサー(解析機)を理解することができて、
パーサーを理解できれば、JSONパーサー・ XMLパーサー・markdownパーサー・C++パーサー ... などを理解するのはとても容易です。
理解しやすいこと。これが関数型プログラミングの大きな利点です。
追記:
また、汎用部品と型のお陰で、ライブラリのドキュメントが圧倒的にひきやすい、というメリットも有ります。
Haskellな人がPythonにトライした結果 - Togetterまとめ
関数型プログラミングは「厳密な事前設計を必要とするため、簡単なことをやるのにも時間が掛かる」。
＞＞ map (*2) [1,2,3] [2,4,6]
邪魔な”儀式”や、"おまじない"のコードが徹底的に撤廃されているためです。
関数型プログラミングのコードは、潔癖かつ濃密です。
たとえばC言語でint hoge(int x,int y)が定義されているとき、hoge(3)はなんの意味も持ちませんが(コンパイルでコケますが)、関数型プログラミングでは意味があり、実際に有用です。
上の例では、「掛け算をする」(*)関数は、二引数関数ですが、それに引数を渡して作られた「2を掛ける」関数(*2)は、一引数関数になります。
関数型プログラミングでは、「簡単なことは簡単にでき、複雑なことは複雑にできる。ただし、間違ったことは殆どできないか、全くできない」。
また、静的型付けの力によって、コード補完は非常に強力になっています。インテリセンスの比ではないです。
たとえば、関数中のある表記の型を任意に表示できます(GHC/TypedHoles - HaskellWiki)。
やがてやってくる未来には、プログラムをテキストエディタで書くことは時代遅れになっているでしょう。
統合環境のサポートで、バグやミスの少ない、スムーズなプログラミングができます。
そしてその環境で動くプログラミング言語は、関数型プログラミングをサポートした言語なのです。
以下の様な兆候を感じたら、あなたはそのプログラムを関数型プログラミングで書くべきです。
一般に、オブジェクト同士の相互作用が複雑になるほど、オブジェクト指向では手に負えなくなっていきます。
そういうときは、オブジェクトを直接扱わず、替わりにその"相互作用"を扱うことで、複雑さを軽減するアプローチが有効です。
それこそが関数型プログラミング的アプローチです。
特にオブジェクト指向が有効なのは、プログラミング初心者がそのコードをいじるかもしれないときです。
関数型プログラミングは、強固さと柔軟さの代償として、高い学習コストを伴います。
オブジェクト間の相互作用が複雑でなく、着目している(名前をつけている)概念が安定しているとき。
そして、プログラムをいじる人たちの間で共通理解が図れているならば、オブジェクト指向が有利です。
遅延評価という機能によって、レガシーな言語で扱えなかった、巨大な数を扱うことができます。
関数型プログラミングで書かれたプログラムは、正確さが要求される、金融関連の業界で使われています。
手続きとしてパーサーを記述できるので、テキスト処理プログラムはより理解しやすく、メンテナンスしやすいものになります。
関数型プログラミングを知らない人は、「正規表現でおk」と言いますが、
彼の書いた複雑な正規表現は、半年後には(書いた本人でさえ)理解できなくなっていることでしょう。
手続き一般を扱うことができるので、途中で割り込みのある手続きの表現も容易です。
関数型プログラミングをサポートしていない言語ではコルーチン(ファイバー)などをつかってなんとかするしかありません。
さもなくば、非並行処理では普通に関数として記述できるところを、並行処理のために、Builder,Strategy,Command,Interpreterパターンを駆使して書き直すことになります。
Javascript使いの方は、Deferredなどの構造を使うでしょう(http://qiita.com/KDKTN/items/4c6986049d204f0645d8)。
C++使いの方はBoostで頑張りましょう。破滅的に解りにくいコンパイルエラーメッセージと格闘してください。
もう少し簡単な例をあげます。
あなたは、あるレシピにしたがって、自動的に料理を行うマシンの制御プログラムを書いているとしましょう。
1. まず玉ねぎを炒める。
2. 飴色になったら、肉を加えて炒める。
3. 野菜を加える。
4. 水を加えて煮る。
5. スパイスを加える。
…できませんよね？何故ならば、各ステップの"間に"、マシンのロボアームの位置や動きを調整する処理が必要だからです。
これをオブジェクト指向でやろうとすると、各ステップの副作用として、それらの処理を行うことになります。
そうすると、マシンが二機に増えた時などの変更量は、絶望的なものになります。
あるいは関数として表現するのを諦め、手順全体をDSLで記述できるようにします。
このアプローチは関数型プログラミング的です。しかし関数型プログラミングをサポートした言語の助けなしでは、そのDSLを記述するために沢山のユーティリティーコードを書かなくてはならないでしょう。
オブジェクト指向的アプローチでこの問題をエレガントに解こうとすると、クラス化の粒度を上げる事になります。
野菜クラス、フライパンクラス、ボイルクラス、フライクラス、焼き加減クラス、アームクラス、野菜の大きさクラス、切り方クラス、焼き方クラス、"焦げたよ"クラス、etc...
こうすると早晩レシピはプログラムのコード上から消え去ることになります。上記のたった5行は、依存性注入のオブジェクトグラフを構築するコードに取って代わることになります。そこには沢山の挙動の制御がオプションとして付記されているのです。
カレーなど、ある種のレシピに限定することで、見た目の理解しやすさを得ることができますが、一方それは表現力を損なうことを意味します。
C言語などではマクロを使うこともできますが、それは結局、関数型プログラミング的アプローチの意味するところと同じになります。すなわち、補助のために沢山のコードを書くことになるでしょう。
iOSのAppstoreアプリは、"無料"と書かれたボタンを押すと、それが"インストール"ボタンに変わり、それをもう一度押すと、ダウンロードの進捗を表すインジケータに変わり、それを押すとダウンロードをキャンセルできます。
このように、位置は同じなのに、ステートに依って見た目と機能が変わるボタンは複雑です。
これをオブジェクト指向で実現しようとすると、
という下らない問題にぶつかります。
一方関数型では、"機能"、"見た目"、"状態"、を独立に扱って、それらを合成してボタンを作るので、迷うことはありません。
「同じ位置にあるUIオブジェクトは、コード上で(インスタンスとして)独立して、他から干渉を受けない」
この条件が満たされているうちは、オブジェクト指向でGUIを実現することに無理はありません。
しかし、携帯端末のような小さい画面で、多くの機能を達成するためには、UI要素はコンテキスト依存的に複雑になりがちです。
近年、PCのディスプレイの大きさは、頭打ちになってきました。
画素数は増えているのですが、MacにおけるRetinaのように、複数ピクセルでひとつのドットを表すようになってきています。
これは、ひとつの画面に置かれるボタンなどのUI要素の数は、これから先の未来で増えることはない、ということを意味します。
したがって、未来のGUIのプログラミングは、注意深く機能をピックアップして制限するというデザイナーの努力を脇におけば、
関数型プログラミングの力を頼るしか無いでしょう。
つまり…
Haskell さいこうなのおおおおおおおおおおおおおおおおおお!! おしっこ漏れちゃうのおおおおおおおおおおおおおおおおおおおお(゜∀。)ﾜﾋｬﾋｬﾋｬﾋｬﾋｬﾋｬ
1. google:すごいHaskellたのしく学ぼう を注文する。
2. Download Haskell を自分のPCに導入する。
3. コンソールにghciと入力して、対話型コンソールを立ち上げる。
4. 次の関数をコンソールに打ち込んで、結果を見る。即値で書かれているところとかをいろいろ変更してみて、感動する。
take 4 $ map (*2) [1..]
追記:
いかがでしたか？
ちまたには、関数型プログラミングの利点は変数が無いことだ、とか、より安全だから、とか、より速いから、などという妄言が満ち溢れています。
オブジェクト指向と関数型プログラミングは、水と油ではありません。プログラマは自分のプログラムに最適なアプローチを選ぶことができます。
一般にはあまり知られていないことですが、Haskellにもオブジェクト指向へのサポートがあるんです(Lensライブラリ、これを使用したサードパーティ製ライブラリも最近増えてきています)。
この記事を読んだオブジェクト指向プログラマのあなたが、少しでも関数型プログラミングに(そしてHaskellに)興味を持ってくださって、ホームセンターの大人用オシメのコーナーが大賑わいになれば幸いです。。
最後まで泣くんじゃない。
システム一式○○万円でござい、と出すと「もっと具体的な根拠を出せ！ そんなんで当社の社内決裁通らんわ！」って言われる。言われた。
具体的な根拠（=原価見積もり書的なもの）って何？っていうと、労働集約型産業なので、そのシステム作るのに何人が何ヶ月張り付いたか、に帰結するんだよね。
プログラムコードの行数で原価算出する手法もあったりするんだけど、古い大企業や公的機関といったお固いところほど、人月による詳細内訳が【求められる】。
「発注の前に、プロジェクトのメンバー構成表（各人の実名入り）出して」とかね。開発現場激励という名目の視察チェックが不定期に入ったりとかね。もうね。なんだろうね？
人月計算で見積もり出してプロジェクト動かしてるにも関わらず、システム会社の人間が死んだ魚の眼で一日中キーボードを叩き続けてる理由。
・技術力および経験不足で見積もりミスってる。（および、競争入札で一番安いとこに発注するって言われたから無理なダンピングしてる）
・進行中のプロジェクトにおいて、上流マネジメントの失敗で追加仕様や仕様変更が頻発してる。
・開発メンバーの中に役立たずが混ざってる。
この全てでございます。
最近は裁量労働制がトレンドだから遅くまで煌々と働かせても残業代払わなくていいし、生かさす殺さずで搾り取ろう！ ふぁいと！
なんで大きな開発案件ほど、UI 設計にちゃんとした時間と工数割かずに適当にやっちゃうんだろうね？ 不思議。
設計の最初の段階で【画面仕様書】という名のポンチ絵を書いて、ユーザ承認が降りたらもうあとは動かしたりしないんだけど。
おおむね、システム開発一筋３０年みたいな大ベテランが伝統の技を活かして固定画面でキーボード操作オンリーの前世紀 UI になるか、ロクな経験も無い頭でっかちの若手がドヤ顔で最新トレンドを取り入れてメニューがやたらパカパカ閉じたり開いたりする落ち着きの無い UI 設計になる。なった。
激しく使いづらいと、作ってる側も認識してるけど、その段階ではもうどうしようもない。ゆくみち戻れず。
実現場の利用ユーザには大変申し訳ない限りだけど、これはもうシステム会社まかせにしてても現実問題どうにもならんです。
だって、システム会社は納品済ませれば仕事完了だし。その先毎日１０年に渡ってうんこ UI と延々付き合い続けるのは、あなたがたなのだから。
画面仕様書が提示されたら、懇切丁寧に読み込んでチェック入れて赤字だらけにしたものを「バーカバーカ」って言いながら突き返しましょう。
その手間隙は絶対に惜しんではいけない。
開発会社から「ユーザインタビューの時間を下さい」って言われたときに、日常業務が忙しくて時間が取れないって断るのは自殺行為だ。残業してでもたっぷり時間取れ。
エラーメッセージに意味不明のシステム情報出すのは、システム会社が１００％悪いですね。
さすがにそこまでユーザ側に設計チェックさせろというのも無理筋な話。TCO に密接に関わるんだからおざなりにせず、もっと気合入れて丁寧に案内作りましょう。
全メッセージ「システムに不具合が発生したため処理を中断します。詳しくはシステム担当にお問い合わせ下さい」とかやらないように。約束だよ？
本業の利益ベースでウン億円も稼ぐ苦労に思いをはべらすと、感情的にもなりますわな。日々 100 円単位でコスト削減努力に血道をあげてるっていうのに！
このあたりはシステム会社の営業がちゃんと、ユーザが心から納得できるように丁寧に説明して理解させろ。頑張れ。超頑張れ。
まあこれについては根本、大規模システムにおける競争入札制度の欠陥ってのが何十年も前から指摘されてて、全く改善の目処が立っていない絶望的な今が有るわけです。
ユーザ側企業は「こんなこといいな、できたらいいな。空を自由に飛びたいな。さて、ハウマッチ？」で競争入札を求めてくるし。
システム企業側は「え？ もうちょっと詳しく話を聞かせてくれないとなんとも…あ、とりあえず予算組のために総金額だけ知りたいですか。入札日は２週間後！？ あわわ…えーと、んじゃ、どんぶりで…こんぐらい？」って杜撰な見積出して来るし。
まあそんな適当な入札、勇気を出して見送ればいいんですよ。でもそんな適当入札しかないんですよね世の中。武士は喰わねど高楊枝、なれど妻子は喰わしていかねば。
スタートラインがそんなだから、ボタンの掛け違い一つで開発プロジェクトはいともたやすく炎上するし、末端の開発人員はブラックだし、上層部はいつまで経っても終息しない開発とテストのエンドレスエイトに夜も眠れぬ日々を過ごすし、できあがったシステムはうんこでユーザ側も大変だし。幸せってなんだっけ？
システムの要件定義契約と、実際のシステム開発契約を分ければいいんじゃないって皆が思うのだけれど、まあ現実問題これもなかなかねえ。どうすればいいんでしょうね？
http://anond.hatelabo.jp/20131008141912
全く困らない。慣れる。
適切な単語の選択のセンスはプログラミング経験でいくらでも身に付くので、
辞書があれば困らない。
エラーメッセージで検索するとよくStack Overflowなどが引っ掛かるが
ある程度長い場合は機械翻訳に突っ込むこともあるが意味が取れなかったことはない。
質問をしたことは無いが、コードとエラーメッセージを簡単にまとめればなんとかなると思っている。
あまり気の利いたことは書けない。
Issueを要約したタイトルぐらいなら書ける。
内容をすべて英語で書こうとすると日本語の時の数倍の時間が掛かることになるため、できれば書きたくない。
Gmai宛に送ったら、なにやら長文が帰ってきたというので確認してみたら…
: host gmail-smtp-in.l.google.com[173.194.79.27] said:
550-5.1.1 The email account that you tried to reach does not exist. Please
try 550-5.1.1 double-checking the recipient's email address for typos or
え～っと…
このメールは配信できなかったよ、アドレスをよく確認して余計なスペースが入ってないか見てね…か。
で、詳しくは↓を見ろと。
http://support.google.com/mail/bin/answer.py?answer=6596
なになに？
だったらUser Unknownって書いとけ！
言葉細やかに丁寧な説明だと思うけど、
元ブログ見たけど酷いな。俺なりの解決案を書いてみる。アホなこと書いてるかもしれないが、少なくとも仕事はうまくいってる。
誰か話が出来そうな人に聞いて決める。納期や現場の人間関係が問題？そんなクソ環境とか知るか。
エラーメッセージは後でトラブルが起きたときに使うんだろ？トラブル解決に必要な情報くらい分かるだろ。
数字でなく、抱えている問題を報告させる。
90％終わってるけれど大きい問題を抱えてていつ終わるか分からないのと、30%しか終わってないけれど後は単調作業で先が読める場合、前者の方が問題だろ。
量じゃなくて質。量は適当。間に合いそうかそうでないかだけでいい。
自動化は当然として、単調作業だけ一ヶ月はスケジュール組む方がアホ。適度に単調でない作業を混ぜろ。
気づいたら報告しろ。嫌いな奴、知らない奴だから報告できない？お前のそのコミュ障をまず何とかしろ。
UT作るなり適当にログ入れたら分かるだろ。分かったことからコメント入れていけ。ログ入れたら動かなくなった？そんな言語捨てろ。
時間が余ったら元増田の言うように仕事の精度を上げるようにしてる。優先度は低いかもしれないけれど、コードだけが成果物じゃないから。
俺ですらこうなんだから、有能なプログラマーならもっといろいろ思いつくだろう。
バレずに、そのまま自分が別の案件や現場に移動するまで逃げ切れれば
万事解決なのである。
俺は一つのシステムを開発から保守までやってるから、逃げようにも逃げられないし、サボったらそれだけ自分が後で苦しむ。逆に頑張れば頑張るほど仕事が楽になっていくからやりがいもある。まず完成したら終わりというクソ環境から逃げることを考えたら？
諸事情で眠れない。
「仕様が曖昧だからこうしておくね、よろしく」という一方的な通知をメールでぶん投げて終わり。
曖昧な箇所とは、どうでもいいと思われている箇所なので、たいていの場合実際にどうでもいい。
「ケース自体は洗い出せているが、具体的にどのようなエラーメッセージを表示すべきか？」お前は小姑か。どうでもいいに決まってんだろそんなもん。
コメントを書けよ糞馬鹿野郎。見られたくないならコミットコメントやチケットにひっそり隠すという裏技もある。
進捗などというものは存在しない。0%か100%かだ。中間報告が必要なタスクは粒度が荒すぎる。
こんなもんは21世紀のITエンジニアにとって基礎スキルすぎるので割愛する。
その程度の事もできない低脳だから、周りに迷惑をかけないように刺身タンポポワークに回されているのだろうが。次は机の上に内線電話しかない部屋で一日中座ってる仕事かな。
担当者を探すことすら放棄する。直らなくても気にしない。それらはリーダーか担当者自身の仕事であり、俺の仕事じゃない。
無視してもいいが、指摘と無視では、大体無視の方が総コストが高く付く。
越権行為をする、つまり自分のキャリアを危険に晒してまで修正するほど仕事熱心な奴は勝手にやればいいが、俺は死んでもやらない。
「ここにこういう不具合が残っている、どうしよう」とリーダーに丸投げするだけでいい。システムを止めて入れ替えとかそういう事はリーダーが勝手に考える。勿論「軽微な不具合なので放置する」という判断もあり得る（大規模なシステムには大抵「既知の不具合」リストがある物だ）。「面倒なので客には黙っておこう」というのも、夜中にコッソリ修正するのと同じく、ハイリスクな判断であり、そんなもんは自分でやらずにリーダーに丸投げすべきだ。
ユニットテストを書けよ糞が。こんなもんは21世紀のITエンジニアにとって基礎スキルすぎるので以下略。
人間は、能力の限界まで能力を行使していないと劣化する。優秀な人間はそれを知っているので、「自分の仕事を減らすための嘘」は、自分を守るために必要最小限しかつかない。糞みたいな仕事で一杯になったら？黙って転職するんだよ。
あるいは、時間を仕事の精度を上げる方に費やす。テストの充実、ドキュメントの充実、開発用ツールの整備、リファクタリング。時間の都合でオミットされがちな要素などいくらでもあるし、優秀な人間ほどそうした要素が沢山見えている。
