責任（せきにん、英: responsibility/liability）とは、元々は何かに対して応答すること、応答する状態を意味しており、ある人の行為が本人が自由に選べる状態であり、これから起きるであろうことあるいはすでに起きたこと　の原因が行為者にあると考えられる場合に、そのある人は、その行為自体や行為の結果に関して、法的な責任がある、または道徳的な責任がある、とされる。何かが起きた時、それに対して応答、対処する義務の事。

上記はwikipedia から

曖昧って言ったけど、言葉そのものはそこまで曖昧じゃない

「Aに対してBする責任がある」と言うと

「Aに何らかの不備が生じた、あるいは生じる可能性があるときに、Bしなければならない」って意味だ

プログラムで考えると分かりやすい

責任という言葉には引数が2つある。責任の対象(Reason)と、行為(Action)だ。

だけど世間の「責任」の使われ方はどうだ？

Actionが抜け落ちている。酷いときにはReasonも抜け落ちている。

何をしてほしいのかまるでわからない、何に対して責任あるかも曖昧。

ただただ避難するためだけに「責任」という言葉を使い

俺はいつだって「結局何をしてほしいんですか？」と聞く羽目になる

そんなシーンは世の中至る所で見かける

言葉も満足に使えないバカがやたら「責任」を使いたがる

もっと別の言葉に置き換わってもらえないだろうか

ReasonとActionを述べないと使えないような語に。

Permalink | 記事への反応(0) | 10:11

2017-06-21

■[ゲーム日記]６月２０日

○朝食：なし（ヨーグルト致命的なまでに飽きた）

○昼食：助六（飽きない）

○夕食：ご飯、納豆（二つ）、減塩野菜たっぷり味噌汁（フリーズドライ）

○間食：アーモンド（五粒）、スライスチーズ（二枚）、野菜ジュース（ちょっと先月と今月で妙に間食癖が着いてしまったので自戒の意味を込めてコーナーを追加、かつスナック菓子、みたいな不健康そうなものじゃなくてまだマシそうなものをチョイス）

○調子

はややー。

仕事はそれなりにこなした。

昨日書いた通り、本来三日の仕事を二週間に薄めて仕事していて、僕含めて全員そんな感じのスケジュールなので、今まであまり自分が追ってこなかった分野の有識者に話を聞いて見たりして時間を使った。

ただ、その話を聞く部分はいいんだけど、メインのその三日で終わらせる部分がなんか少しだけ要領が悪くて、かみ合わなかった。

こんな日もそりゃあるんだけど、元は自分の書いた共通コードなのに引数にトンチンカンなものを渡す仕様にしてしまう、今までなんどもやってきたケースなのに何故か間違ってはないけど今まで違う上に将来性や運用を考えると微妙なやり方でやってしまう、などの間違いというか、ミスというか、なことが起きた。

どちらも、間違いを指摘されたらすぐわかったから、本当そういう日もある、いつも100点とれるわけじゃないって話なんだけど、二回続けてだったから、ちょっと心残りみたいなのがある。

それを気にしてどうこうって話題でもないんだけど、なんだか妙に「なんでこうできなかったかなあ」と悔しい感じだ。

ある意味、自分の中で「俺はできる」みたいな自負があってそれがうまく回らなかったから悔しいのかなあ。

まあ、適度に頑張ろう。

●Xbox360

○デッドライジング

・ケース2

スナイパーライフル装備のカリートとのバトル。

ライフが有り余っているので、狙撃されながらスケボー近づいて、小型チェーンソーでごり押しという脳筋プレイ。

お話は、ブラッドさんが負傷してしまうも、博士を救出できた。

その後、スーパーマーケットの薬局に薬を取りに行くも、スーパーマーケットの店長のサイコパスとバトル。

こちらも、スケボーで近づいて小型チェーンソーでごり押し。

お話は、イザベルを救助するもツンデレな感じで、逃げられてしまう。

・ケース3

救出した博士とお話。

ただ、フランクさんはあまり信頼されてないので、お話はほとんど聞けず。

・ケース4

なので、話を知ってそうなイザベルを監視カメラで見つけて、会いに行く。

バイクに乗った彼女とバトル。

これも、小型チェーンソーでごり押し。

金的を食らいながらも、フランクさんの説得でお話を聞いてもらえるようになる。

どうやら、カリートがこの事件の犯人らしく、ゾンビはカリートのメッセージ、みたいな話で、気になる展開。

さらに、イザベラはカリートの妹であることが判明し、カリートを説得してくれることに。

・ケース5

が、説得は失敗。

イザベラは怪我をしてしまったので、おぶってセキュリティルームまで運ぶことに。

この、おぶるシステム他の救助者でもやりたいな、指示出すのイライラするし、フレンドリーファイヤが有りだから救助者運び大変なんだよね。

●3DS

○ポケとる

サファリを、前回からの追加分のピカチュウの顔違いを捕獲目当てで、10回ぐらいプレイ。

が、影も形も出ず。

●iPhone

○はねろコイキング

トレーナーランク38。

コイキングは、51代目。

○コマスター

ログボが単発ガチャチケだったので、さっそく回す。

シザリガーとサメハダーは出ず。

何気に、マテリアルが6100も溜まっている。

4000はEXの悪ポケ追加にとっておきたいので、サメハダーは交換しちゃおうかなあ。

サザンドラは多頭飼い専門だから敷居が高いし。

とはいえ、サメハダーも運用できるポケモンあまり持ってないし、微妙かなあ。

それこそ、サザンドラとサメハダーは相性がいい気がするし、難しい。

Permalink | 記事への反応(0) | 00:48

2017-05-30

■BASP21で受信したメールの添付ファイル名などが文字化けする問題の対処のポイント

今時BASP21 DLL（フリー版）でメール受信してどうのこうので困ってる人が世の中にどのくらいいるかどうかわからないけど、今日嵌ってググってもまともな答えが出てこなくて途方にくれたのでポイントをメモっておく。

問題と原因

BASP21 DLLのRcvMailメソッドでPOP3 サーバから受信してReadMailメソッドでメールの内容を取得すると、一部のメールが送信者や添付ファイル名が文字化けして正常に取得できない。これはBASP21 DLLのReadMailメソッドが最近普通に送信されるUTF-8のメールに対応していないため。

対処法

RcvMailで受信したファイルをReadMailで読み込む前に直接開き、Base64 エンコードされたUTF-8の文字があったらデコードしてJISに変換してBase64 エンコードして保存する。その処理したファイルをReadMailで取り扱うようにする。全部BASP21の機能でできる。

BASP21のKconv メソッドの第１引数のinstrに文字列を渡せるのはUnicode UCS-2のみの場合だけらしく、UTF-8の文字列を渡しても正常に動作しない。なので、一旦テンポラリファイルに書き出しKconvFileメソッドを使用して変換を行う必要がある。っていまドキュメント眺めてたら文字列をバイト配列にするByteArrayというメソッドがあるみたいなのでこれをを使えばできるかもしれない。けどもう正直いじりたくないよ…。

Permalink | 記事への反応(1) | 21:06

2017-04-24

■隣の席の人が怖い

新しいプロジェクトで隣の席になった人の独り言が怖い。

プログラミング中ブツブツ言うのは全く気にならないんだけど、時折「死ねよこのコード書いたやつ」とか言い出す。

挙句には変数名をfuckにしたり引数にfuckを渡したりコマンドラインにfuckって書いたりしている。

変数のfuckは気付いたら普通になってるけどこんなにイライラしながら仕事してハゲないんだろうか？

Permalink | 記事への反応(1) | 21:43

2017-02-26

■http://anond.hatelabo.jp/20170226153940

言語：java
親を頼らない(親を参照しない)
知らないおじさんについていかない（シングルトンや便利関数を使わないで、なるべく与えられた引数とシステムライブラリのみを扱う）
普通科に進学しない（行き過ぎた汎用性を求めない。純粋関数に近づけることを心がける）

Permalink | 記事への反応(0) | 15:50

2016-12-03

■老害 プログラマだが。最近、若いもんが書いたコードを読んだ。

例外ってあるじゃろ。tryしてる間にthrowされたのをcatchするアレじゃ。あれは、たしかに有用な仕組みじゃ。何かの関数に失敗したとき、本来の値のかわりに特定の値を返すのもダサいし、参照型の引数で成功したか否かを返すのもダサい場面、というのは確実にある。そもそもプログラマは怠惰で忘れっぽい生き物なので、例外という仕組みがなければ、関数で失敗したことにすら気づかないかもしれない。

だがな。例外は魔物じゃぞ。昔は、gotoというものがあってだな。好きなところに処理を飛ばすことができる。あまりに、いろんなところに飛ばせるので、邪悪だと言い出した奴がおって、今ではあまり使われなくなった。なぜgotoが邪悪と呼ばれたか。gotoというのは、順接、分岐、反復という、プログラムを組む上で最低限必要な制御構造から逸脱した、どっかからどっかに飛んでいく、という行為が容易にでき、それを多用したコードはまともな人間には読めなくなるからであった。そして、例外は、まさにその「どっかからどっかに飛んでいく」を容易にするための仕組みなのじゃ。

例外は、順接、分岐、反復による基本的な制御構造があった上で、あくまで対処を要するアブノーマルな状況に使われるべきものであり、例外というのは、制御機構として使ってはいけない。値を返す目的で例外を使ってはいけない。一体どこから来て、どこへ行くのか分からない、そんな、流れ星のような例外の使い方をしてはいけないのじゃ。例外を使うなと言うつもりはまったくない。じゃが、例外は制御構造を壊しうるものだと認識し、例外を悪用していないか、それによってコードが追えなくなることはないか、と、考えてから、使ってほしいのじゃ。

イベントの悪用も見た。イベントは非常に有用な仕組みだし、GUIなんかだと、もはや必須とも言える。なので、イベントを使うことは有用なことだ。けれど、イベントは、いつどこで発生するか予想が付きづらいものが多く、また、スレッドなどを使って非同期でイベントが処理される場合(今時は、多くがそうだろう)は、マルチスレッドと同じく、リソースの排他制御を行う必要があるかもしれない。複数の処理が同時に動くというのは、恐ろしいことなのじゃ。いつの間にか、変わってないと思ってた変数が途中で変わるやもしれない。「まー、滅多に起こらないし、ええじゃろ」って判断の上、何も対策しない、という手もあるが、ええじゃろで済むのか済まないのか検討するくらいは必要じゃわな。C# なんかだと、言語レベルでイベントが実装されておる。じゃから、イベント必要ないじゃろと言いたくなるような場面で、イベントが使われていたコードを見た。

便利な仕組みがどんどん出てきて、新しいものがどんどん古くなる今のコンピュータ業界。新しいものを追いかけるのもいいが、基本は基本として、しっかり押さえて欲しいのじゃ。今更、アセンブラでゲームを作れるようになる必要なぞ、微塵もないが、自分のコードがどのように動くのか、興味をもってほしいのじゃ。わしのような新しいものに不勉強な老害は、最近の若いものが基本的なことを不勉強だからこそ、居場所があるのじゃ。じゃが、わしももう長くない。若いもんは、新しい仕組みの表面だけでなく深い部分に触れて、学んで、わしら老害を追い出せるくらいになってほしい。わしからは以上じゃ。

Permalink | 記事への反応(0) | 17:43

2016-09-08

■Excelで特定の文字を含むセルを調べる方法

事例

特定の文字を含むとはいわゆる「あいまい検索」です。

例えば、

A列に住所があり、「東京都」という文字列があれば、B列に「◯」を、そうでなければ「×」を表示させたい

という場合を想定してみましょう。

普通想像するのは、IF関数の条件として「*」（アスタリスク）などのワイルドカードを使う方法ですが、これをIF関数で表すことはできません。

B1セルに「=IF(A1="*東京都*","○","×")」と入力し、下方向にオートフィルすればよいような気がしますが、これでは実際にはA1が「*東京都*」という文字列の場合のみ結果が「◯」となります。「*」（アスタリスク）が文字として認識されてしまうためです。

方法

では対処方法の紹介です。

次のようにIF関数とCOUNTIF関数を組み合わせることで可能となります。

B1セルに

=IF(COUNTIF(A1,"*東京都*")＞0,"○","×")

と入力します。（※「＞」は正確には半角です。ここでは匿名ダイアリーの特性で全角としています。）

COUNTIF関数は、第1引数で指定された範囲の中から、第2引数で指定した条件に合致するセルの個数を数えてくれます。「*」（アスタリスク）はここではワイルドカードと認識されるます。

複数の関数を組み合わせないといけなかったり、IF関数とCOUNTIF関数で「*」（アスタリスク）の扱いが異なっていたりとややこしいですが、覚えてしまえばこちらのものです。

これで普段のエクセル作業も一気に効率が上がることでしょう！！

Permalink | 記事への反応(1) | 23:05

2016-09-06

■

手続き型で代入ができる言語では、参照透過性があり副作用がないサブルーチンって存在しないんだろうか。

int sum (int n) {
  int i = 0;
  int result = 0;
  while (i <= n) {
    result += i;
    i += 1;
  }
  return result;
}

例えばこんなサブルーチンなら、ローカル変数のiとresultに再代入はするけど、同じ引数で毎回同じ結果になるし、ローカル変数以外には影響を与えない。

条件はおそらくこのくらいでいいはず。

サブルーチン外で定義されたグローバル変数を読み書きしない
引数を書き換えない
IOを行わない
中で呼び出すサブルーチンは、参照透過性があり副作用がないサブルーチンのみ

こういうのがコンパイラやIDEで検知できれば便利そうなんだけど。

Permalink | 記事への反応(0) | 14:53

2016-09-02

■情報系の学科に通っています。

学問の徒として生きるのは完全に諦めてるし、大学もはや無駄と思ってるけど、無能でない俺ですら無理と思う道であってこんな補助金出してガバガバ教育してる日本金の使い方無駄すぎ……とは思う　

もっとちゃんとした就職予備校設置してほしいけどそういう変革は無理なんだろう。

そういう話じゃないのか。今回はそういう話ではないです。

パソコンのご本を読めるようになるのが難しい、という感じのお話。独学？が難しい。

パソコンのご本、あんまり知識がちゃんとしてない人は読めないようになっているっぽい。

後述するけど、わかりやすいように作られたスクショまみれの本とか。

全体的なビジョンがないわけ。実際の世界がそれで動いてるようなビジョンが。だから読めない。

僕は社会の役に立つことを直接学びたかったよ。社会がどういう風に動いてるかみたいな話をさア

そういうのがあれば、パソコンのご本を読めるようになるんだろうなという感覚がある。

実務の話！！実際に「IT系のおしごと」というのがやってるような話で、特にコーディングに直接絡んでくるようなもの。

技術の実態みたいなやつ。そういうのは学校で教わらないんですよね。

優秀な人はバイトとかやって知ってるっぽいけど、それみんなバイトでやるの？みんなはやらんでしょ。

というかバイトみたいな形で社会参画しないと学べない知識だったら、それはそれでやばくないですか？という提起でもあります。

はてな民の人IT系で働いてる人多そうだけど、そういうところ、そういうところなんですよね。

そういう知識があれば、大学の図書館に置いてあるような「技術本」っぽいやつ？の扱い方がわかるんだろうなーと思う。

いや別にやってきたことは何も無駄にはなってないんだけど。ハードよりの話もしたり、基本的な数学とか物理とか電子とか論理学とかシャノンの話とか。

でも、パチョコンは実学も以前に学問というか、実際に使えてナンボな部分が(いまこの想定してる話では)デカすぎるのに、

そんな環境的な、Linuxでサバ建てしましょーねーみたいな話も三年後期になるまでやらなくて、そんなん人が立ててるの見たら一発で覚えられることだし、みたいな。

みたいな。

そう、なんというか本が読めないんですよね。これ人がいたら一発なのに……というようなことだらけで、絶対間違った道に来ちゃってるよという感じがする。

↑

（焦ってるんじゃないのか？一冊だけをしっかりやれよ。と思ったりするし、言われそうだけど、それが一番の正解なのかな…やっぱり）

つーか本読みながらチンタラチンタラ比較するの嫌になるわけですよな。わかる。

スクショがいっぱい貼ってあったからといってわかりやすくなるわけではないし……。

てかスクショ貼ってあると古くなるとすぐ対応できなくなるから本当に困りますわよね、という話もあります。

僕が何を期待しているのかって？それは実務のうちで難しいお話が出てこない、環境の話、という感じ。

プログラミングをやれと言われても、それIDEはなによ？っつー話ですわな。WindowsだとVisual Studioとかになるのかな。

Eclipseはよくわからない。Javaでアプリ作るっていうのそんなに真剣にやったことないし……

っていうかそもそもプログラミングのお仕事？？がよくできる人たちはプログラミングで何をしているの？

アプリを作っているんですか？それだったらヴィジュアルモードのチェックが簡単なやつ必要だよね、という話で。

あるいは別にアプリなんか作ってないのかもしれないよな。とすると何かしらサーバーを使って捌くようなシステム・サービスの細かい調節のお手伝いをしてたりするわけだ。

その具体的なトラフィックがどうだからどうのこうの、というお話をしたり、アクセスの仕方がどうの脆弱性がどうの、新しい技術がどうの、という話だと思うんですけど、

端的に言ってそういう話がぜんぜんわからない。そういう話がわかるとスンナリ進めるはずなんだけどな～と思いながら。

親の金で大学行ってるのに、なんかもっとこううまくできるはずなのに……という感じでつらい。

僕は人の役に立つ仕事のおべんきょおがしたいんですよ。なのに図書館で借りられる本、自分が何を知らないから理解できないのかもよくわからない感じで……

日経Linuxとか読んでみて、去年のやつにプロセスとかスレッドの説明あったけど、僕はまだOSの基本的な話もマトモに理解できていないなので、

そういう人間には難しすぎる (というか抽象的すぎてかなりわからなかった)　スケジューリングの話はされたので、プロセスが対象なの？とか、そもそもCPUがアセンブリ命令 ADDとか？を実行しつつ、

OSがそのアセンブリ命令をセットにした実行単位を用意して、OSがスケジューリングしてくれる、みたいな話なのかな……？と思った

(でも明らかにプロセスとスレッドがわからない人間には伝わらないような程度のフワフワ説明しかなくて、これ、誰向けだ？とか思ったけど、やっぱり身近に聞ける人間がいる人のための本なのかもしれないですなあ)。

そういうの、本とか、自分の足りない知識とか、おそらくその辺にあるんだろうな～と思いながら、でもバイトで働くにも微妙にプログラミングの知識が必要で、「これまで何作ってきましたか？」と言われても、

そういう、あんまりしっかりしたものを作ったことないし、C言語、gccで可変引数までやって、でもアセンブリがどう実行されるんですか、という話はよくわからない。

Javaも習って、まあそれっぽいお話はいっぱいされたんですけど、アプリ作るの難しかったし、GUIはクソだね、というか、手打ちでやったんですけど、こんなん絶対手打ちより良いやり方ありますやろと思いながらやっていた。

絶対手打ちより良いやり方あるはずだけど、僕は知らんし、知らない以上何が効率的に作れるのかもよくわからないし、わからないことにはできるだけ手を出さない方がいいな、と思う。

いや～なんつーかこういうことばっか書いてると「甘えんなカス。氏ね」とかコメントされて、2000回くらいは殺されちゃうんですけど、それは甘んじるとして、でも何というか……みんなそうなんですかね。

同年代で「めちゃくちゃプログラミングできちゃいます！(漠然)」みたいな人間いるけど、僕が例えばどういう本読んでどういう道筋を歩んだらそういうカンジになれるか、かなり見えなくてつらいし、

そもそもそういうのを職業にできるスキル高く磨けるような人って、いったいどういう生き方してきたらそうなるんだろう、と思っている。

これで情報系の研究室いって、なんとか乗り切って就活して、プログラムがんばって書きましょうー！というような職場に行ったら、

それはもう「学生じゃないんだから。もう社会人なんだから自分で調べて」となるんですよね。マンガとかでたくさん読みました。それは死ぬほどつらいでしょ。現に人死んでるじゃないですか。

結局周りに聞ける人間がいる環境ってなに？今もいないし、大人になってもいないんでしょ？だからはてブで「プログラマーはやっぱ自分で本読んでスキルアップしなきゃ死ぬぞ！」みたいなやつがホッテントリになったりするわけでしょ？

それはつらい。ご本読んで理解できないの、というか読めてないの、ウチにあるだけで目が上滑りして「全体像がよくわからないからな～　しょうがないよな～～」と言いながらろくに読む気も起きなくて、

「でも本当に役に立つ本って開いた瞬間に読みやすいのでは？」みたいな信念がある。　これが原因なのかな。でも、この信念、少なくともこれまでめちゃくちゃ役に立ってきたものなんだよなあ……。

学生の今、自分が考えてて不安に感じてることが、「追いつけない」みたいな不安が、イマイチわかり切ってないし、

だから具体的な質問として一言で言える話の羅列としてわかってないわけじゃなくて、もっと漠然とわからない。こういうこと感じてるの、僕だけじゃなくてパソコン知りてえ～～となって大学に来た人のうちけっこう多いような気がするんですよね。なんか生半可に甘えた環境だから。

----------------------

とりあえずこれ書いてたら少し気分落ち着いたので、要点をまとめると、

「本で勉強するのつらいよなあ～　そんなんじゃどんな分野行ってもつらいだろうなあ～」

ということです。

そういう有象無象の本をスパッスパッと切って、「この辺のこの本読んどくとこういうことができるようになるだろうな～」というモデルがまだあんまりできてない。

そういうのができるようになるのかと思ってたらあんまり学校でも学べる感じじゃない。全体像とは……となっているけど、こういう悩み、自然に解決したりしなかったりするんだろうな。

とりあえず、これは自分メモの今後の方針です。OSより下の階層、たとえばALUとメモリの組み合わせで、program counterを進めながら動いてるんだよーという感覚はあるので、

それがOSとどういう風につながってるのか、とか、100均で売ってる電卓、あのデジタル表示の部分がどういう仕組みで動いてるの、ということを考えたり、

インターネットプロトコルでパソコンが具体的にどういうパケットを送信しているんだろう、というような話を攻めて、これが全体像とやらが見えるようになる一助になるかはわからないけど、

できるところからできるところだけ勉強していきたいと思います。それが、僕にとって、よくわからない本をじっと読まなきゃいけない義務から抜け出した罰の引き受け方っぽいので。

Permalink | 記事への反応(27) | 03:10

2016-07-30

■http://anond.hatelabo.jp/20160730161746

おお、やるじゃん！！！！！

すごい！

そうそう、こういうこと！

こういうことが言いたいの！！！！

俺の前の増田は、これを読む前の奴だから、あんま気にしないでくれ！！！！！

こうすりゃ、一番最初の増田で言ってた、引数の中で実装とかしなくてもええやろ？

ようやく、伝わって僕も嬉しいわ！

本気でJava知らんけど、言いたい事が伝わって良かったわ。

いやあ、よかったよかった。

Permalink | 記事への反応(1) | 16:30

■http://anond.hatelabo.jp/20160730125112

うーん？

いや、なんか、通じてないな。

もうちょいサンプル詳しく書くから、サンプルのどこがわからないか言ってくれ。

EventHogeクラス（クリックした時のイベントを定義するクラス）

　　　　　　// Javaの書き方しらん、インターフェースを実装することを定義したい

　　　　　　public class EventHoge : View.OnClickListener {

　　　　　　　　// Javaの書き方しらん、インターフェースのメソッドを実装することを定義したい

　　　　　　　　public void View.OnClickListener.onClick(View v) {

　　　　　　　　　　　　// 元増田のサンプルそのままーー＞

　　　　　　　　　　　　AlertDialog.Builder dlg;

　　　　　　　　　　　　dlg = new AlertDialog.Builder(MainActivity.this);

　　　　　　　　　　　　dlg.setTitle("サンプル");

　　　　　　　　　　　　dlg.setMessage("Hello, サンプル!");

　　　　　　　　　　　　dlg.show();

　　　　　　　　　　　　//＜ーー

　　　　　　　}

MainHogeクラス（画面の初期化を行い、どのボタンにどのイベントを仕込むかを決めるクラス）

　　　　//　Androidなにも知らんけど、元増田がボタンにイベントを書く処理が書いてあるクラスのことが言いたい

　　　　public class MainHoge {

　　　　　　　　//　そのメソッド

　　　　　　　　public void Main() {

　　　　　　　　　　　　//ボタン実装のサンプル

　　　　　　　　　　　　final Button button = new Button(this);

　　　　　　　　　　　　button.setText("ダイアログの表示");

　　　　　　　　　　　　button.setOnClickListener(new EventHoge());

　　　　　　　　}

こうやって、クラス分けて書けば、外とか中とか、全く関係なくなるじゃん。

元増田のサンプルだと、メインの中でインターフェースを実装したクラスの実装を書いてるから、中とか外とかがあるんじゃないのか？

自分でクラスとして定義して、そっちで実装すれば、メインは紐づけるだけでよくなって、仮引数？の中で実装しなくてもすむじゃん。

Permalink | 記事への反応(2) | 13:08

■http://anond.hatelabo.jp/20160730090832

よくわからん。

中が嫌なら外でかきゃいいじゃん。

javaもAndroidもしらんから適当だけど。

　　　　　　// Javaの書き方しらん、インターフェースを実装することを定義したい

　　　　　　public class Hoge : View.OnClickListener {

　　　　　　　　// Javaの書き方しらん、インターフェースのメソッドを実装することを定義したい

　　　　　　　　public void View.OnClickListener.onClick(View v) {

　　　　　　　　　　　　// 元増田のサンプルそのままーー＞

　　　　　　　　　　　　AlertDialog.Builder dlg;

　　　　　　　　　　　　dlg = new AlertDialog.Builder(MainActivity.this);

　　　　　　　　　　　　dlg.setTitle("サンプル");

　　　　　　　　　　　　dlg.setMessage("Hello, サンプル!");

　　　　　　　　　　　　dlg.show();

　　　　　　　　　　　　//＜ーー

　　　　　　　}

// メインスレッド的なところ

//ボタン実装のサンプル

final Button button = new Button(this);

　　　　button.setText("ダイアログの表示");

　　　　button.setOnClickListener(new Hoge());

こう書けば、中で書かなくて良い気がするけど、駄目なの？

なんか、インターフェースだから引数の中ってのが意味わからん。

どう関係してるの？

Permalink | 記事への反応(1) | 12:05

■http://anond.hatelabo.jp/20160730090832

なんで仮引数の中で実装しなきゃいけないの？

会社のコーディング規約がそうだからじゃないの

俺はしないよ

汚く見えるから

Permalink | 記事への反応(0) | 09:17

2016-07-28

■http://anond.hatelabo.jp/20160727175406

ライブラリのバージョンが一致しているかどうか確認するのは当たり前のことだよ。

つーかNodeでもライブラリのドキュメント読めば互換性があるかどうかはきちんと書いてある。

Javaは安定してるっていうけど、この前Android開発でJDKのバージョンアップした時にjarsignerのデフォルト引数が変わっていてひどい目にあったからJavaでも同じ。

Permalink | 記事への反応(3) | 11:35

2016-07-17

■Excelに苦戦中

いわゆるExcel方眼紙でシステムの設計書を書いているのだが、これがどうにも上手くいかない。

問題は色々あるが、大きく分けて「必要な情報が見えにくい」「変化に追従するのが大変」に集約される。

まず「必要な情報が見えにくい」について。

そのメソッドを記述するのに必要な、他の設計書や仕様書を見つけにくい。

例えば、他の設計書(1ファイルで1クラス)に書かれているメソッド名や引数が合っていなくても、すぐに発見しづらい。

また、入出力情報が書かれたインターフェース仕様書を探しにくいなどなど。

そもそもどうユースケースを読んで、設計が必要なクラスを抽出するかもよくわからないし。

次に「変化に追従するのが大変」について。

上述の状態で設計書を書いた結果、製造するプログラマから「こんなんじゃ実装できない」と突っ返されて修正するパターンが多い。

また設計を進めた結果、仕様変更が必要な事態が度々発生する。

更に要件定義レベルでの見落としによる手直しも、結構な頻度で起きる。

いずれもExcel ファイル1個に留まらない、影響範囲の大きい修正になるケースが殆ど。

そんなことが相次いで発生した結果、修正対象の抽出・修正・確認作業で作業量が膨大化し、全く対応できない。

というわけで、もはや限界ギリギリだったり。

「1個ずつ解決していけばいずれ必ず終わる」を合言葉に、気合と努力と根性でやってきたけど、なんでこうも先が見えないのか意味がわからない。

どうしたら対応できるのか・・・。

Permalink | 記事への反応(0) | 22:53

2016-06-08

■

「オブジェクト指向は現実にある"もの"を元に設計します。だから人間にとってわかりやすい設計が自然にできるのです」

なるほどなるほど

「まずHTTPServletクラスを継承したクラスを作ります。doGetメソッドはHttpServletRequestクラスのインスタンスを引数にとります」

はあああああ？？？

Permalink | 記事への反応(1) | 12:29

2016-05-29

■

「富士通を退職した話」に言及とついでに自分の話でも。

自分も前に富士通に居て既に退職してます。後で詳しく書くけど、ソフトウェア開発職に居たです。

富士通を退職した話

彼のへの感想。

「富士通」の開発職を希望したらメインフレームも含むの当然なんじゃないの？
20万人月案件（炎上案件）に行かされたのは運が悪い。辞めるのも正解の一つ。
上司の対応はクソ。

富士通はクソでっかい会社なんだし、サイト見ればメインフレームやってるのだって判るんだから、開発職を希望したらメインフレーム関連の開発やる可能性あるのは当然予見出来るだろうし、それを想像してなかったのなら情弱とかブコメで言われてしまうよね。あと何も記述が無いから想像だけど、「それほど有能ではない」と判断された可能性もある。と言っても学生が思う「開発者として有能かどうか」ってのと会社でのそれってのは別物で、要するに学生自身が自分が実績もあって優秀だと思っても、会社的にはそうでないのよね。そうなると（後述の富士通に入社して10年が経った人の話にもあるのだけど）新人の能力の客観的な判断材料って大学と資格（応用情報レベル以上）程度なのよね。資格に関しても基本情報なんてMARCH クラス以上の人間なら受けたら取れて当然だから、「有能かどうか」の判断材料にならない。就活の際に本気でIT 業界に入りたいかどうかの判断材料にはなる程度。自分の同世代で富士通本体に入ってソフトウェア開発関連に配属された人のプロフィールを見たけど、確か偏差値的には少なくとも神戸大学とか千葉大学あたりの修士卒しか居なかった覚えがある。あと確か2～3人がソフ開持ってた気がする。だから、この増田がどの程度だったのかなと。

ただ、20万人月案件が具体的に何かは判らないのだけど、自分の在籍していた当時でも炎上巨大案件というのはあって、（自分が知ってるのは確かデジタルテレビがどうのこうのとか言ってた）、そういうのに入社して間もなく入ってしまうと自身の勉強等が出来なかったり潰されたり最悪死んだりするんで、そういう意味でも逃げるのは正解の一つ。（自分は炎上案件に放り込まれた新人が寮で死んでたとか話を聞いたことある）

上司の対応はまあこれだけ見ればクソだわな。

富士通を退職して思うこと

はあ、としか。この人がこう判断した際の判断材料にするであろう自己の体験を具体的に書いてないので、意識高い系がフカしてるようにしか見えない。あと、たった3年しか居なくてあの巨大企業の経営とか体制とか理解出来るんかね？と思わないでもない。自分とは部署が違うだろうから当然かもしれないけど、自分の体験とは違うなーって感じ。自分は、外から見たら馬鹿みたいな事やってるように見えるかもしれないけど、経緯や目的や巨大企業特有の問題があってそうなってるんだなって思う事が多々あった。

富士通に入社して10年が経った - blog

近い時期に入社したと思われる。具体的な話が自分の経験と一致してる。特に、富士通のソフトウェア開発と言えばミドルウェアの開発が主だというのは、富士通内部じゃないとなかなか（特に学生なんかじゃ）判らないかなと。

それでこれらの話を見てどんな人が富士通（というか大企業）に向くのかなと考えたんだけど、「やりたいこと」そこまで明確じゃないけどコンピュータは嫌いじゃないって感じで、地頭がまあまあ良くて勉強に関しても要領よくやれる（要するにそこそこの大学に行って卒業した人）、それでそこそこ安定した職・収入目当てな人かなと。ってコレ書いててふわふわしてる人みたいであんまり良い印象の人物像じゃないな。マッチングミスはどうしても起きると思うし、学生の頃に思う「やりたい事」って往々にして変わったり間違いだったりするし、そもそも学生の頃に明確な「やりたい事」がある人の方が少数派でしょ。だからこういうそこそこ優秀だけどふわふわしてる人の方が良いんじゃないかなとか。逆に、ちゃんと「やりたい事」が明確にあるけどまあ安定はしたいって人はどうしたらいいのかって言うと、自分みたく大企業の子会社を狙うと良いんじゃないかなと。子会社ならその会社がやってる事が理解しやすいし、入った後の配属の希望も大きく違ったものにはなりにくいし。まあ子会社は子会社で色々アルかもしれないけど。

で、自分の入社から退社までの話。

入社は10年ぐらい前。入ったのは富士通の子会社で主にミドルウェアの開発をやっている所でした。入社して1～2年したら子会社の統廃合とのことで富士通本体と連携してる部署（自分がそうだった）は富士通本体になりますとのことで富士通本体の方に移ったという経緯ですね。別に待遇とか元々本体と同じだったから変わらず、事務関連が小回りきかなくなったぐらい。入社してから退職までは5年ぐらいでした。辞めた理由は実家の事業を継ぐ事にしたため。

入社して数ヶ月の時にある温泉地にある某所でその手の開発をやってる子会社沢山と

富士通本体のソフト開発配属の人達で研修をやったのだけど、その際に富士通本体の人達と知り合った。（この際に全員のプロフィール冊子が配られた）そのときは流石子会社に入る人達と本体とじゃレベルが違うな～と思いましたね。（ちなみに自分はMARCHより下の院卒。）

自分が配属されたのは某製品部署のAPI部分チーム。その製品がC言語やJava 言語からも使えるように出入り口を用意する部分。中でやってる事は指定されたIPのポートにプロトコルに沿ってデータ投げるだけなんだけどね。ちなみに配属希望の際は「そこそこの忙しさの所がイイ」と言っていました。「バリバリに働きたい」と言ってた同期は多忙でヤバい所に配属されてました。他にもチームがいくつかあったけど、それらのうちの一つは例の「山奥の工場」でしたね。自分が配属された当時はC言語のAPIをリニューアルするって開発してたのだけど、設計担当がJava しかやったことない人で色々とC言語の流儀に反してて後々のメンテが大変でした。まあそれでもリニューアル前よりは遙かに良くて、以前はユーザに見せてる関数名が ○○search1 ○○search2 ○○search3 とかでしたね（ちなみに機能はそれサーチか？思うのもあった）。もっと酷かったのが初期製品のJavaの公開メソッドで、マニュアルには「このメソッドの引数○○を□□を指定した場合は戻り値のObjectを△△にキャストしてください。××を指定場合は…」という「これ製品にして売ってたんだ…」と思うレベル。もちろんコレがダメだったってのは開発側も認識していて当時は既にリニューアル済みだったけど。リニューアル済みでも少し微妙だったけどね。

これは、ミドルウェアの開発をやってる人達って基本的にC言語が主でJavaとかをやってる人がほぼ居なかったからだと思う。上司もそういうのは良くないってのは認識してた。対象 OSはWindowsとLinuxとSolarisだったけど、そんなにたいした事やってなかったからほぼ同じコードだったような。ソケットの一部だけ違ってたっけかな。

それでそのバージョンの開発が終わったあたりで、.NET Frameworkが出始めてきたので次バージョンでは.NET FrameworkのAPIを作る事になりまして、自分が少し勉強していたのでそれの設計から担当する事に。当時は.NET Framework 1.1で今思えば少し時期が早かったと思う。2.0でGenericが出てからやった方が良かったと思うんだけど、そういうの政治的判断だし結果論だしなー。それまでにRubyとかオブジェクト指向言語に触れてその辺の勉強もしていたので、.NET用のAPIに関しては設計も実装も結構良い感じに出来たと思う。ああ、そういえばRuby用のAPIも効率化の開発ツールとかの名目で仕事中に勝手に作ってたなあ。他にもC言語のAPIも内部実装がクソすぎ！とキレてユーザ公開関数インターフェースだけ同じで中身をフルスクラッチした事も。もちろん絶対にLDしてるんで完全に趣味なんだけどな。これでAPIはC言語とJavaと.NETになった訳だけど、現場の案件で使われたのってほぼ全てJavaだったと思う。（開発中のサーバのテスト用アプリはC言語だけど）。要するに自分が数年関わったコードが世の中ではほぼ使われてない訳でして、取りそろえとして必要だったとはいえ世の中の役に立ってないってのは嬉しくは無かったですね。まあ、大企業の仕事なんてそういうもんです。.NETに関してはそのバージョンが出る頃はその製品があまり売れてなかったんだか使われたって話は聞かなかったですね。ほほほ。大企業に勤めるのならこういう覚悟は必要かもね。

で、.NETのAPIが出来たあたりに開発ネタがなくなって保守気味になってきたので、人員整理と作業整理との事でインストーラと切りたいけど一度やったからには切れない補助製品の担当が増える事に。インストーラはWindowsがInstallShieldというクソみたいな言語上で作られたもの。LinuxとSolarisがシェルスクリプトでのもので、InsallShieldの方のコードはあまりにクソなのでリファクタリングさせてもらった。この辺の開発は少なかったのだけど新OS 対応(Vistaとか）とか保守作業が大変だった覚えある。

んで、これらの作業が終わったあたりでこの製品でやることが無くなってきたのと同時に、この製品の派生製品の話が出てきてて、それは1機能1exeで提供されてて、それらを纏めるバッチ処理機能部分を担当することに。バッチ処理の内容・順番を記述するのにXMLを使う事になったのでXMLのパーサが必要なのだけど、色々調べたら富士通内部でパーサ作ってたのでそれをもらって使う事に。そのパーサはC++からじゃないと使えなかったのだけど、趣味でC++で勉強してたので何とかなった。あと、結構 OSの知識（プロセスとか）が必要でWindowsとLinuxとSolarisで動くコードを書く必要があってまあまあ大変でした（と言ってもifdefで切り分けるだけなんだけど）。けど、これらの開発は自分が一から設計してコードを書いていたので楽しかったですね。それでこれが完成するかしないかあたりで、このバッチ処理機能が他の開発中の製品のバッチ処理に使えないかとか話が出てきたあたりで自分が退職する事に。（退職の話は1年ぐらい前に話し合って決定済み）引き継ぎをして退職ということになりました。最後は溜まった有給を使う予定でまだ在籍中だけど部屋を引き払って実家に帰ってたのだけど、打ち合わせに来て欲しいって言われてしまい実家から何日か通ったのは良い想い出。というかまさか実家から朝8時に間に合うとは思って無かった。

振り返ってみて残業時間は月40～60時間が多かったかな。100時間超えた時は上司に怒られた。あと退職前の1年ぐらいはうちの事業本部（だったかな？）単位で残業禁止になってホントに残業0時間になった時期があった。他の部署の人の話で、どう考えても狂ってる上司の話とかを聞いてると上司とかの運は良かったと思う。あと、やっぱり仕事でみっちりプログラミングが出来たのは運が良かったと思う。富士通のソフト開発で C C++ C# Java シェルスクリプト InstallShieldとか（そんなに深くはないけど）色々やれた人間はそうそう居ないんじゃないかな。同期とかの仕事は年上の人の派遣の人に指示出したり取り仕切ったりする仕事とか、保守サポートみたいな開発じゃない仕事の話も良く聞いていたので、ソフト開発のキモを体験出来たのは良かったです（こなみ）。

Permalink | 記事への反応(0) | 23:54

2016-05-25

■http://anond.hatelabo.jp/20160525213232

バグがあって、ストリームに変な値が入った時、どこがバグなのか、追跡するのが困難でしょ？

第一に、それは、ストリーム（FRPの値の定義）の問題であって、ユニットテストすれば良い。もしくは単にFRPのログを取れば良い。

グローバル変数ではそういうことはできない。FRPでは、岡部氏のFRP ライブラリも特にそうだけど、基本的にミュータブルな値同士が関数でリアクティブに連携されて常に整合性を保っているのだから、グローバル変数の、各所で更新されたそれぞれの値によって全体の整合性が損なわれないように気を配らなければいけないという（テスト自体困難な）問題は発生しない。それがFRPの唯一とも言えるメリットだとも言える。

使用する関数の問題じゃないし、「印」として引数に加えても別に構わないと思うが、君のいうグローバル変数の問題と一緒というのはまったく違う。

岡部氏との争いって「OCamlでGUI アプリを純粋関数型(状態渡し)で簡潔に書けるか」ってところじゃないよね？

いや、それがそもそもの発端であるとブログの経緯には書かれている。説明されている方式でGUI アプリまで書けるのか？と疑念が呈されたことがきっかけ。

岡部氏はFRPで状態を関数の外部に持ってても純粋関数型だ、と言ってて、そこで争ってるんだよね？

この論点は聞いたことがない。岡部氏がこだわっているのは非手続き型の宣言型で、純粋がどうとか議論はされてないように思う。

あと、OCamlでGUIを状態渡しで書いたら簡潔で無いのを「書けない」、「不可能」って言ってるのはわざと印象操作しようとしてるよね？

原理的に可能かという議論ではなく、実用的な範疇か？という議論。反対派ブログで出てきたコードは、本人が認めるように普通のやり方ではなく、実用的なコードだとは思えない。あと、FRPと状態渡しは同じ複雑さだという主張も崩されている。そこが重要。

Haskellで書けて、OCamlで冗長になっても、書けるなら「書ける」、「可能」だよね？

段階を踏んだ上で、非FRPのHaskellのIOモナドのコードを誰かが書いたらいんじゃない？当面、最初はOCamlの話だったのに、いきなりHaskellやElmのコードで書いて、そういうのがごちゃまぜに、何がどの言語でできるのかできないのか、誤魔化しがあると見做されたから制限されたんでしょ。実際には、OCamlの関数型では冗長でしか書けないと実証されたけど、そういうのがバレないように、別の言語を利用していたと看破されて当然の状況だと俺は思うね。

俺の書き込みが他人といきなり結び付けられたから、電波だな、と思ったの。
俺１人か、とか、らくだや住井が含まれてない根拠とか、関係無いよね。

関係ある。君ひとりは、そうじゃない、と君ひとりが言ってもそれが本当だとは確認のしようがないし、

書き込みをみれば、君以外の書き込みもすべて、その一派ではない、とでも言いたそうだ。

Permalink | 記事への反応(0) | 22:06

■http://anond.hatelabo.jp/20160525202812

否。ストリームに限らず、定数は引数で与えなくても純粋関数型である、という見解はごく普通。

定数って、プログラム中で更新不可能で、いつ読みだしても同じ値が出てくるから、グローバルでも問題無いんだよ。

ストリームは定数だ、って言ってみたところで、プログラム全体から更新可能なんじゃ、グローバル変数と同じでしょ？

バグがあって、ストリームに変な値が入った時、どこがバグなのか、追跡するのが困難でしょ？

なんで伝わらないんだろ。

複数人でプログラム開発したり、他人のプログラムをデバッグしたり、したこと無いんだろうか。

つまり、GUIになればもはや関数型では書けない、というのが推奨スタイルだ、って言ってるようなもの

「純粋関数型」とは何か、という話と、とOCamlでそれが推奨スタイルか、って別の話だよね？

岡部氏との争いって「OCamlでGUI アプリを純粋関数型(状態渡し)で簡潔に書けるか」ってところじゃないよね？

純粋関数型とは何かといった時にHaskellのように、IOも含めて引数と戻り値で表現する、関数のふるまいが関数の外の状態に依存しない、関数に副作用が伴わないとかの性質をいうと思うんだけど、岡部氏はFRPで状態を関数の外部に持ってても純粋関数型だ、と言ってて、そこで争ってるんだよね？

あと、OCamlでGUIを状態渡しで書いたら簡潔で無いのを「書けない」、「不可能」って言ってるのはわざと印象操作しようとしてるよね？

Haskellで書けて、OCamlで冗長になっても、書けるなら「書ける」、「可能」だよね？

その発言が事実か確かめる術はないし、ここで岡部氏攻撃しているのは君ひとりなのか？他の人間まで一連の誹謗中傷集団ではない、す駱駝、住井が含まれていないみたいに断言する根拠は何か？

俺の書き込みが他人といきなり結び付けられたから、電波だな、と思ったの。

俺１人か、とか、らくだや住井が含まれてない根拠とか、関係無いよね。

Permalink | 記事への反応(1) | 21:32

■http://anond.hatelabo.jp/20160525104221

ストリームを関数の外部に持つFRPを純粋関数型っていうのは少数派でしょ。

否。ストリームに限らず、定数は引数で与えなくても純粋関数型である、という見解はごく普通。

http://stackoverflow.com/questions/37405262/is-this-pure-functional-using-a-value-in-the-nested-closure-like-function/37405374

OCamlの元々の推奨スタイルならもっと短く書けるんでしょ？

つまり、GUIになればもはや関数型では書けない、というのが推奨スタイルだ、って言ってるようなもので、OCaml ベースでいくら関数型の講義やっても、最終的にはその関数型でまともなGUI アプリすら書けない、という批判でしょ。その批判が岡部氏からされたら、あたかも関数型で書ける、という強弁から生まれたのが「状態渡し」理論。それが無理筋だ、ということが今回実証された。