「ユースケース」を含む日記 RSS

はてなキーワード: ユースケースとは

2020-06-09

https://b.hatena.ne.jp/entry/s/gist.github.com/mattn/488af4c3b3841ea901a1f9820636393c

ワイはallow/blockが好きやなあ

aとbだから

----

masterとslaveの意味がしっくりくるのはscsiくらいなもんだと思う

このユースケースにおいて適当な言い換えは思いつかない

(gist代替案が書いてあるけどfollowerでもworkerでもreplicaでもないよな)

----

白黒つけるって発言もそのうちできなくなるから、今のうちにいっぱい言っておいた方がいいんでないか

まああれは人種ではなくて囲碁なんですけどね

囲碁も赤と青の碁石を使うようになるかな?

----

一昔前ならそんな荒唐無稽なことは言わないのだけど、アメリカ社会馬鹿さ加減について認識が改まった昨今において、彼らがやらないという確信はもはや持てない。すまないね

2020-05-26

情報処理技術者試験なんて何の役にも立ちません

情報処理技術者試験資格を取っても実質的に得るものはありません。「実質的に」というのは、技術者としてのスキル向上に貢献するということであり、「報奨金が貰える」とか「履歴書に書ける」などの技術無関係ものを含まないということです。

なぜ、情報処理技術者試験が役に立たないのかと言えば、出題内容が表面的な知識問題に極端に偏っており、本質的理解を問うていないからです。たとえば、オブジェクト指向の三要素に「カプセル化」「継承」「ポリモルフィズム」がありますが、これらを御題目のように唱えていても何の意味もありません。しかし、情報処理技術者試験ではこれらの用語さえ覚えておけば、しっかり点になります

オブジェクト指向におけるカプセル化説明したものはどれか。

  1. 同じ性質もつ複数オブジェクト抽象化して,整理すること
  2. 基底クラス性質派生クラスに受け継がせること
  3. クラス間に共通する性質抽出し,基底クラスを作ること
  4. データとそれを操作する手続を一つにして,オブジェクトの内部に隠ぺいすること

https://www.fe-siken.com/s/kakomon/19_haru/q42.html

こんなのは単なるポエムであり、これが解けたところでコードが書けるわけでも、良い設計ができるわけでもありません。

数学で喩えれば、「加減法」とか「代入法」のような用語を暗記して、具体的な連立方程式の解き方は分からないようなものです。

ひどい問題は挙げればキリがありません。

UML2.0において,オブジェクト間の相互作用時間の経過に注目して記述するものはどれか。

  1. アクティティ
  2. コミュニケーション
  3. シーケンス
  4. ユースケース

https://www.ap-siken.com/s/kakomon/22_haru/q44.html

図の名称を答えさせる問題。図を読み取らせる問題なら、まだ理解できますが。そもそもUMLなど別に技術者として知っておくべき知識でもありません。

要求分析から実装までの開発プロセスを繰り返しながら,システムを構築していくソフトウェア開発手法はどれか。

  1. ウォータフォールモデル
  2. スパイラルモデル
  3. プロトタイピングモデル
  4. リレーショナルモデル

https://www.fe-siken.com/s/kakomon/23_aki/q50.html

これも、こんな分類自体、覚えたところで何にもならないわけですが、その用語を答えさせる問題いかに、この試験エンジニアリングプロジェクト管理本質関係いかがよく分かります

極めつけはこれ。

次の画像符号化方式のうち,携帯電話などの低速回線用の動画像の符号化に用いられるものはどれか。

  1. JPEG
  2. MPEG-1
  3. MPEG-2
  4. MPEG-4

https://www.fe-siken.com/s/kakomon/17_haru/q52.html

地方公立中学校定期試験レベルのひどい問題です。出題者は、1だの2だの4だの7だのといった数字語句対応を覚えることが重要だと思っているのでしょうか。

情報処理技術者試験で測れる能力は以下の2つだけです。

  • 内容の理解はともかく、ある用語を「聞いたことがある」かどうか。
  • 150分間、落ち着いて椅子に座っていられるかどうか。

まり、ある種の発達障害ではない意識高い系ポエマー認定するための試験であり、そもそも技術者のための試験ではないということです。あとは、中小企業診断士などを受ける人が試験免除を獲得するためとか。

そもそもコンピュータプロジェクトマネジメントの技術を、資格試験勉強しようというのがピントがズレています。それらは既に良質な解説書が豊富にあるのだから、それで勉強すればいいのです。

2020-03-31

anond:20200331104551

というか増田自体が新コロ特措法の話だからといって新コロの症状に考えが捉われすぎてると思うぜ。

ワイは極論言ってるけど、とはいえユースケースとしてあり得ない級の話でもなく、マウストゥマウスの話であれば

「急に症状が悪化して救急車呼んだはいいが到着時にはすでに心肺停止していた」状況なんかではあり得る話だからな。(まあ、新コロの症状を前提に考えるとやらないほうがいいが)

2020-03-04

anond:20200304120431

5Gはエリアが狭いことが逆にメリットであって「ローカル5G」みたいなシステム許可さえあれば作れるんよ。

からディスク無しPCユースケースとしては「情報持ち出し禁止」みたいな現場で「端末に情報持たなきゃええやん」みたいな発想をした場合システムってことな

古くはダム端末。

2020-01-16

anond:20200116120318

とあるあるユースケースだと、仕事上司部下の関係にある人が

「そのPC使ってGmailで疎通できるか確認して?」みたいな作業を依頼して、その次の日に使ったPC回収して…みたいなのはあるようだけどな。

2019-12-29

モバイルアプリハイブリッド実装で後悔したもろもろ

モバイルアプリ実装と言えば主力はKotlinSwift(Objective-C)だけど、簡単な作りであればcordovaベースフロントエンド開発ライクに進められる。

そもそもライブラリ選定には関わっていなかったものの、便利と思って使った結果後悔した思い出のお話

WebViewベースである以上、イベントレンダリング系統ネイティブに劣る

特にiOSが顕著だった。

Angular, Vue実装していたけどレンダリング系に属するイベント盛りだくさんの場合

結果的ネイティブ実装したほうが楽だしレンダリングの面で有利。

そもそもcordovaからと言ってネイティブ知識がいらないわけじゃない。

標準サポートしているプラグイン群でできることは限られてくるし、そのまま突き進むならネイティブ実装知識必要になる。

フロントエンド開発できない奴が作れる代物ではない

これは当たり前だけど…

JSパッケージングだったりCSSビルドが組めないとなると逆にコスト高。

Angularベースで進めていたときにそれは起こった。

そもそもNode.jsビルド根本的に理解してない奴がプロジェクトを作ったせいで

JSパッケージビルドもされない、jQueryを突っ込まれるなどひと悶着あった。

3年前くらいだったけど既にTypeScriptも出てたし、何故そうしなかったのか理解できない。

結果ロードが激重になった。そりゃそうだ、minifiedされてないのだから

用法用量を正しく守って使わないと、後で面倒になる好例だった。

ビルドが意外と面倒で手間

大概は専用プラットフォーム上でビルドしていくがこれがくせ者。

ブラウザIDE(という名のただのテキストエディタ)が使えるけどそもそも構成管理できない。

ローカルビルド乖離するし、ブランチすら切れないのだから本人以外は触れないシロモノになってくる。

ビルドのためにアップロードするんだがこれまた賢くない。

別端末でビルドしようとすると同名の新しいプロジェクト作成される。

ここまでくるともう触りたくなくなる。ただ、触らないわけにはいかないので何とか整合が取れる状況にした。

さらに言えば、ビルドが終わってステータスが見れるが、内訳が見れるのはそのタイミングだけ。

これはマジで止めてほしい。殺意が湧くレベルでやめてほしい。

多分、海外で公開したプラットフォームをそのまま持ってきてるんだと推測しているが流石にこれは悪意しか感じない。

やろうと思えばそりゃローカルビルドはできるけれども。

クライアントOSで動くビルドツールが使い物にならない

ただのCLIバックグラウンドで実行するだけのGUIラッパーと化している。

かといってlintを掛けてくれるわけでも無し。

個人的に要らないし今後は使わない。

WEB RTCを使うとiOS互換に苦しむ

突き当たったのはWebSocketを使うシーンが出てきたとき

ライブラリで何とかする方向で進めたかったけどそもそもwebpackビルドにすら対応していなかった。

件のAngularベース場合もっとひどくてクソラッパーを作りやがったせいで依存度が激高になった。

ちなみにネイティブはそれぞれにサポートするライブラリが出ていて、最新バージョンに向けてきちんとメンテナンスされている。

その辺はJS世界の闇に降れた瞬間でもあったりした。

総括

根本的にiOS側の実装レスポンシブ的なレイアウトが作りにくい現状を鑑みて、

WEBベースで新商品などの通知をしたい、残りは情報の閲覧のみでSPA構成的なシロモノで作りたい。

こんな需要には使ってもいいんじゃないかと思う。相当なレアケースだけれども。

いいところは確かにあって、CSSデザインの調整が効くところは大いに評価できる。

これがまたネイティブ実装だと面倒。特にiOS。お前はダメだ。

結局進めていくとネイティブ実装知識を求められるのだからネイティブ実装したほうが良くね?と言ったところ。

ユースケース的に超単純要件アプリを作りたい、かつ、ユーザに何かpush知的なやつを入れたいって場合は使ってもいい気がする。

うそ大手でもなければ無い気がするけど。

2019-09-29

anond:20190929144700

推奨は要求じゃないし、あくまでも運営者が想定する増田ユースケースの一端でしかない。いずれにせよ、それに反した使い方が駄目とは書かれてないから好きに使えばいいよ。

2019-08-07

単一責任原則vsカプセル化

投稿につき至らない点があるかもしれないが容赦してほしい。が、指摘は受け入れる所存。

俺はとあるUIコンポーネントライブラリ開発者だが、先日議論されたあるコンポーネント設計について悩み続けている。

これを読んでくれた人の設計センス知識経験から第三者の率直な意見を聞きたい。

悩んでいることの概要は、

ざっくり言えばこの2択だ。

どちらも間違った考えだとは思えないので、そもそもどちらかの捉え方がおかしいのだと思う。そういった意見も聞きたいが、まずは読んでみてほしい。

設計対象コンポーネントは、よくある触って動かせるスライダーである。下記リンク先のようなものだ。

https://material-ui.com/components/slider/

前提として、このコンポーネント構成要素を下記とする。

加えて、下記も前提としてほしい。

Sliderというコンポーネントクラスを作るとして、これらの構成要素をライブラリ-ユーザー間でどう分担するかという点で、AさんとBさんで意見割れた。

それぞれの意見を要約すると下のようになる。Aさんはカプセル化を狙い、Bさんは単一責任原則を重視している。

Aさんの構成イメージは下記のような感じ

画面
└ Slider         (ユーザー作成)
   ├ 背景バーノブ
   └ 進捗バー

Aさん案の場合だと、Sliderクラス内部で勝手にそれぞれの要素を作成し、自分の子にするなりして表示する。

Bさんの構成イメージは下記のような感じ

画面
├ 背景バー     (ユーザー作成)
├ ノブ         (ユーザー作成)
├ 進捗バー     (ユーザー作成)
└ Slider       (ユーザー作成)
   ├ 背景バーへの参照    (ユーザー指定)
   ├ ノブへの参照        (ユーザー指定)
   └ 進捗バーへの参照    (ユーザー指定)

Bさん案では、ユーザー構成要素それぞれを作成し、Sliderにそれを食わせる。

SliderはAさん案のように各構成要素を構築する必要はなく、ノブの移動や進捗バーサイズ変更だけすれば良い。

Aさんはユーザー制御する必要のない背景バーノブ、進捗バー構成隠蔽(カプセル化)しようと提案したが、

Aさん案に対しBさんは、単一責任原則観点から「各構成要素の構築や表示」という責任を外すべきだと訴え、Bさん案を提示した。

またBさんは、コンポーネントユーザーが扱うべきものであり、コンポーネントコンポーネントを内部で勝手使用しているのは混乱を招くとの見方もしている。

ただしAさんの考えの通り、実際に各要素の構成ユーザー制御するユースケース存在しない。

その場では「単一責任原則」を持ち出したBさん案で決定された。

しかしなんとなくAさん案派だった俺はモヤモヤしたまま家に帰り、本当に単一責任原則に反しているのか、カプセル化よりも大事なのかと悩み続けている。

ここまでが事実となる。

さて本当にBさんが正しかったのか、あるいは単一責任原則の捉え方が間違っているのか、はたまた・・

第三者による意見が聞きたい。周りのコメントに左右されない率直な意見が望ましい。なんとなくな意見も歓迎する。

満たすべき機能は見た目だけではないがそこは置いておいてほしい。

以下は個人的意見とか思ったことや疑問など。

2019-04-14

アプリログユースケースが知りたい

ログとはここでは、特にprintf()やロギングライブラリを使いアプリに仕込まれた明示的な出力とする。

サーバーサイドのログ必要だと分かる。

攻撃来てるかとか気付けるし、ビッグデータとしてゴニョゴニョ解析できるし。知らんけど。

でもアプリログってどう使えばいいの?

バグが起きた時とか、基本的再現手順を元にデバッガーのブレイクポイントとか使うだけで、ログは実際全然見てない。

あとネットワーク解析ソフトと、アプリに埋め込む系のデバッグツールあれば十分って感じ?

役立つログなんて、デバッガーの調子が悪い時にコミットしないものを一瞬入れるくらいかなぁ?

バグが起きた時はQAとかから再現手順と一緒にコンソール出力も飛んでくる。

その中で例外出力は有用なことが多いんだけど、それはハンドリングされなかったのが出てるだけ。

ロギングライブラリを使って何段階もログレベル分けてやって得られたものがあまりないなあって最近思う。

2019-04-03

anond:20190403152304

文章を書くとき主観的になりきる(感情移入する)必要があるが、プログラム客観的メタな考え方でつくる必要がある

コンピュータシステム立場になって考えている。UMLユースケース図は証左。たぶん、増田コンピュータ感情移入できないから、そのように思うのだろう。クルマを愛車と呼ぶのか、単なる移動手段の一機械しか思えないか。どちらが良い悪いは無いけど。

プログラム意味や内容がわかっていないことについて書けない

⇨かつてはやり直しコストが高かったのでウォーターフォールモデルが主流だったが、現在WYSIWYGのごとく、コードを書いて、動かしてみて、検討しなおしてコードを書く、といった繰り返しで調整して作っていくこともそんなに変ではない。

作りたい成果物が決まっているのは、文章も何らかの意図を持って書くのだから一緒。

私の結論プログラム言語は、英語にも増した世界共通言語(よく変わるけど…何処かの進学塾のセンセが書いていたけど、数式のほうがさら普遍性が高い)

2019-01-22

マキタ掃除機

言うほど良くはない。

しかに軽くてバッテリー容量もいいかもしれない。最初は吸引力がすごーい❤︎みたいなテンションかもしれない。だが、次第に弱点が見えてくる。そう、ヘッドである

マキタ掃除機のヘッドはおもちゃみたいな品質なので、人間が気を使わないと綺麗にならない。ビルテーマパークの清掃なら言うことないだろう。しかし、家庭の清掃においては必ずしもフィットするとは言い難い。自家用車の清掃など、どちらかと言うと利便性が重視されるユースケースにおいては力を発揮するだろう。

掃除に気を使いたくない人は少し高くてもヘッドの性能が高い掃除機を購入することをお勧めする。

2018-11-17

anond:20181117114626

Androidを6年使ってきて先月iPhone 8に乗り換えた人間私見

実際はそこまで不便じゃなかったり好みが大きく入っていたりするところ


本当にクソなところ


逆にiPhoneが優れているところ


個人的結論としてはFGOをやめさえすれば本当にどっちでもいいなという感じ.

文字入力ストレスなくできる点ではAndroidの方が好みかも.

2018-08-21

anond:20180821092925

よくある論破ごっこのユースケースでは、割と「仮想設定としてもありえない」ものを両サイドに設定するのが通例だから、そういう様式に慣れてない素人はてな―の無様な姿を見られるだけでも十分面白かったよ。

ちゅーかはてなー全体が論破ごっこに慣れてなさすぎ。

自分主体ではなく客体として演技的に語ったりとか、別に演劇部ではなくても一般社会人的なスキルとしてよくやるやろが。

2018-07-14

人を追加しても立ち上げれない

1.

仕様がわかるドキュメントがほぼユースケース(シナリオ)のみ

下位ドキュメントの内容は上位ドキュメント参照になっててなにも詳細になってない

かい仕様も載っていない

1.

仕様書、設計書がバージョン管理システム管理されていない

ファイル名+日付みたいなそんなちゃちなもんじゃねぇ

最新のドキュメントがどこにあるかがわからない&異なる仕様変更を反映したバージョン複数存在するんだぜ

1.

設計書と実装が一致していない

ドキュメントに変更が反映されてないとかそんなちゃちなもんじゃねぇ

アーキテクチャがまるっと変わるような変更(設計書)をしておきながら

めんどくさいからって実装は古いままなんだぜ

2018-03-30

anond:20180330140525

以前、あるシステムの開発にかかわることになって、それのマニュアルを渡された。

画面のスクリーンショットが貼ってあって

「〇〇画面」の「登録ボタン説明が「〇〇を登録する」。

「△△画面」の「削除」ボタン説明が「△△を削除する」。

というような説明が延々と続く。

画面を見るだけで分かるような情報量ゼロ説明があるだけ。

チュートリアルユースケース的な説明はいっさいない。

装丁は立派だからマニュアルを作れと言われてとりあえず形だけ作ったんだろうなと解釈して、操作方法質問しに行ったら真顔で「マニュアル渡したでしょ。読めば?」と言われた。

どうやら本気作っであのマニュアルだったらしい。

2018-03-23

anond:20180323164918

そりゃ100%合致は無いけど最大公約数的なものだろ。

特にiPhoneXなんてのは仮に使いこなせないにしても他の人の耳目を集める

結果的に使い方を学べたりして損はしない格好になるだろ。

お金はかかるが、少ない情報から導き出せる安牌としてこれ以上の答えは無いだろ。

次点で「タブレット」だが、ご老輩だからといってタブレットを持ち歩きたいと思ってるかどうかは微妙

ファブレットすら死詞になりつつある昨今、タブレットは「ダサさ」の象徴とみなされてる可能性もさもありなん。

老人のフィジカルユースケースを考えればアリな選択肢ともいえるが、ご老人だからこそプライドの高さはあるもの。傍目にダサいものプレゼントされて喜べるかどうか。親を辱めるためにプレゼントをしたいなら止めないよ?

そして、タブレットには漏れなく種類大杉問題が纏わりつく。安全牌のiPadですら選択肢を間違えるとただの物置のガラス板だ。

からこそ、増田リスクを抑えなおかつ喜ばれうるものプレゼントしなければいけない。

その選択肢として最も有用なのは2018年現在iPhone Xを除いて他に無いのだ!

2018-01-25

形式的ユーザーインタビュー意味とは

アプリなんかでユーザーインタビューをやるという話をよく聞くけど、意味を履き違えている人が多い気がする。

定性的調査である以上、本来意味ユースケースなりペインポイントの「異なる視点から気づき」を得ることであって、それ以上でもそれ以下でもない。

その気づきフォーカスしてみるのかどうかはプロダクト責任者次第だし、その気づきが多くの共感を得るかもわからない。

しかしたら一回では何も得られないかもしれない。

なので、この調査からユーザーはここに困っている」と決めつけるのは全く違うし、集団心理が働くため正確な結果かどうかもわからない。

都合の良い結果だけを議論に持ち出して説得するのには有効かもしれないが、この場合はただ「お金を払って調査した」という事実が欲しいだけである

気づきを得るためなら本質的には、友達とかその辺の人に聞いて回るのだって良いと思う。

※手間がかかるような状況だとか、世に出ておらず価値の伝えにくいものインタビューするなら良いかも。

2018-01-08

ビットコインユースケース

ビットコインとは何か、という記事が注目を集め始めているが、もっぱらビットコイン投機性に対してのみ注目を集めていて、どういう実利があるのか・無いのかという話に踏み込んでいる記事が少なすぎると思う。

ビットコインが役に立つ状況と、その前提条件について、素人なりに思いつくところを書いてみる。

 

(1)海外への送金手段として

普通に銀行口座を使って高額のお金を送金しようとすると、それなりの手数料がかかる。安くても2%、5%以上取られるケースも多い。

これに対して、日本ビットコインを購入し、海外ビットコインを送り、送った先でビットコイン現金化すれば、銀行手数料を払うよりも安上がりになる可能性が高い。

 

但し、ここで問題は、送金元となる国でビットコインを売ってくれる人が居る事、そして送金先でビットコインを買ってくれる人が居ることだ。送金先があまりにも小国マイナー通貨だったりすると、上手くいかない可能性がある。

 

さてここで、海外送金について最も切実な需要がある国はどこかといえば中国である中国は、お金海外に送金したり持ち出したりすることに関して非常に厳しい規制がある。一方、中国からアメリカ日本に送金したいという需要は莫大にある。この問題に、ビットコインは風穴を開けている可能性がある。

   

ビットコインに関しては、中国の方が良くも悪くもずっと進んでいるし、現実問題として中国ではビットコインに切実な需要があるのだ。

 

ただし、これには前提条件がある。中国ビットコインを購入し、それを日本日本円に換金したい場合日本ビットコインを購入してくれる人が必要だ。ではどうやって日本でのビットコイン購入者を増やすか。ビットコインには現状、市場操作価格操作)に関する規制が無い。中華マネーをもってすれば、日本の小さなビットコイン市場操作することなど朝飯前だと思わないか

 

 

(2)タックス・ヘイブン代替手段として

ケイマン諸島パナマなどが、租税回避地として騒がれたのは去年の話だ。これに対して、各国の税務署が協力し合って対策を講じ始めている。つまり放置しておくと莫大な徴税を受ける可能性のある金持ち企業世界中ごろごろ居るという事だ。

それで、代わりになる新たな租税回避手段が、あれやこれや模索されているわけだが、そこでビットコインが注目を集めている可能性がある。ダメもとでビットコインを購入し、結果としてビットコインが無に帰したとしても、どうせ放置しておけば徴税されるお金だ。上手くいけば値上がり益を得られる可能性もある。最終的にはビットコインにも税務署の手が入るだろうが、ケイマン諸島パナマよりは後のことになるだろう。

 

 

(3)例えば麻薬販売代金の送金手段として

海外への送金の手数料が高かったり、色々な規制が入ったりする理由の一つは、それが犯罪によって得られたお金である可能性があるためだ。なので、ここには常に監視の目が光っている。これを免れる手段として、ビットコイン有効だ。今のところ。あとは説明する必要は無いね

 

 

上記の3つの例では、いずれも巨額のお金が動く。ビットコインバカげた高騰を説明するのには十分では無かろうか。

ビットコインは優れた技術かもしれないが、それが高騰している理由は、必ずしも褒められる理由では無い可能性があるということを認識してほしい。

 

一般市民が手を出すのは、十分な法整備が行われ、金融庁税務署公正取引委員会などの監視の目が光るようになってからでも遅くないよ。

 

2018-01-05

仮想通貨取引を始めようか迷っている増田

仮想通貨をめぐる情報アフィリエイト仕手筋が入り混じりクソを煮詰めたがごとき肥溜めになってしまっているので、

損得抜きに「仮想通貨取引とはこういうものだ」という実感を書いておく。

株もやったことがないが大丈夫

仮想通貨価値を正しく判断できるのはエンジニア

通貨のコンセプトを読んで、「ユースケースは?スケールする?技術課題は?」といったことがパッと頭に浮かぶやつが適している。

しろ取引に慣れた金融出身にはアドバンテージがないと考えるべき。

もう遅いのでは?

別に遅くはない。

ただし暴落する可能性もあるので遊べる金でふわふわするぐらいにしておけ。

ビットコインを買えばいいのか

やめとけ。 ツルハシを売る業者ツルハシを振るう業者一方的に儲かるように整備されたクソ通貨

最初に作られたという以外に特徴がない。近いうちにイーサリアムリップルに抜かれる。

ではなぜビットコイン価値が落ちないのか

他のコインの購入は基本的ビットコイン建てで行われるという不幸な状況だから

例えばどこかの取引所イーサリアム建てで買えるようにした瞬間に、ビットコイン価値は大暴落する。

マイニングしたい。将来性は?

暗い。最近マイニング不要通貨とか、そもそもブロックチェーンですらない通貨が作られだしている。

どの通貨をどういうふうに買えばいいのか

まず少しでいいかブロックチェーン勉強しろ。今国内で買えるヤツで挙げるなら↓だ。

一年忘れることが難しいなら、とりあえず買ったあと値動きを見ろ。

そして気の向くままに情報を漁れば良い。

買った通貨そのままでいいの?

取引所破綻するリスクがあるので、万全を期すならハードウェアウォレット買って入れておけ。

コインとかICOかいうのは?

90%は詐欺。9%は技術不足で沈没。0.9%は開発されるけどスケールしない。

もしあなたエンジニアなら、その通貨ホワイトペーパー読んでみ。あまりのクソっぷりに失笑するから

それでも買いたければ買えばいい。

Twitterで○○が良いと言っている人がいる

すでにその通貨を仕込んでいる連中が叫んでいるだけ。

他の人が釣られて買うことにより値上がりを待ち、売り抜けをする愚劣なカスどもだ。

で、増田は何を買って、いくら儲かったの?

リップル20円のころに200万買って、いまは3200万に化けた。

SBI北尾が全力でSWIFTを奪りに行っているので、あと二年は寝かせる予定。

そもそもブロックチェーン社会を変える志を持つ技術でありインフラだろ。投機とかクソじゃん。

もっとも。ただ、正しい技術お金を突っ込むのは投機ではないと思う。

「買うのは企業、株ではない」とバフェットも言ってるだろ。「買うのは技術仮想通貨ではない」のだ。

その仮想通貨提案する未来を信じられるなら、金を入れろ。短期で売るな。寝かせろ。

金で幸せは買えないが、金は自由保障してくれる。

エンジニアが儲けを出しやす特性もあるし、現状クソ通貨をクソだと言える人が少ないため他の人にももっと入ってきて欲しいと思っている。

それでは、良い仮想通貨ライフを。

適当に書いた文章からリップルじゃなくてXRPなとかそういうツッコミは要らん。無粋だぞお前ら。

2017-09-13

anond:20170913160909

ニュースの図とか、GitHubに上がっていたユースケース図の方が分かりやすいのに、わざわざ文字で書くなよ。読んで考えちゃうじゃんか。

2017-08-07

https://anond.hatelabo.jp/20170806201515

うーん、何か違うなぁ…と思ったので前作S+99勢が考えるスプラトゥーンアドバイス

事前にやること

試合中にやること

  • とにかくやられない
    • 危ないと思ったら一旦引くことも大事
  • 味方・相手ブキ確認
    • 前作ならステジャンの有無も
  • 塗り状況を意識する
  • 敵味方の人数を意識する
    • 敵が落ちてる時にカウントを進めるのが常套

他にもあると思うけど、とりあえず思いついたものだけ

追記

  • 全てやれとは言ってない、ひとつでも出来るようになるときっと今よりスプラが楽しくなるはず
  • デマエなんて通過点でしかなく、前作でもそうだったけどS+内でかなりの格差がある

2017-07-05

https://anond.hatelabo.jp/20170705094055

横2000px以上のモニタで、ウィンドウ幅を広げても左右の余白だけが広がっていく絶望を味わってみるといいよ…。


特に意味もない追記

ウィンドウを広げなきゃいいじゃん」だと私のお悩みは全く解決されないんですが……? いやそもそもモニタ環境ユースケースも違うからお悩みポイントが共有できません」という程度の話なんだと思うんだけど、なんでアホ呼ばわりされなきゃいけないんだっけ……?

2017-02-16

親の車を捨てる話

条件がぐちゃぐちゃしているのでユースケースを一つ作る。

「Aは親であるBと遠くはなれて住んでいる。様子を見に行くのも飛行機を使うため、気軽に帰省する訳には行かない。Bは高齢のためここ数年、急激に運転がおぼつかなくなってきた。軽い認知症が始まっている。車を降りることを薦めても『心配しなくていい』を繰り返すだけで、話を聞かない。後期高齢者保険の話をしても嫌な顔をするだけ。ヘルパーを入れることも拒む。説得を続けると『疲れた』といって引っ込む。高齢者運転事故の話が話題になっており、心配だ」

多分日本中に掃いて捨てるほどあるユースケース。本当に掃いて捨てたら大阪の海が悲しい色に染まるどころか広大な埋立地ができるだろう。

さて、BはAの言うことをまったく聞かない。一方でBの運転能力は日増しに低下している。ここで何ができるか。現実的選択肢は以下のとおり。

  • 殴り飛ばして無理やり言うことを聞かせる
  • Aが今の仕事を放り出してBの近所に引っ越す
  • Bが衰弱してAに抵抗できなくなるまで待つ

最初選択肢はAが逮捕される。2番目の選択肢を取る人は一定数いる。その後再就職できずに低所得層に転落する悲劇が量産されているが、報道はめったにされない。最後選択肢現実解として選択する人は多いだろう。

最後選択肢を選んだ場合で、かつBが誰もひき殺さなかった場合現実に起きるのは次のような事態になる。

「Bは認知症が進行し、徘徊を始めるようになった」

Bは脳機能の衰えにより、自分の車がどうなったかを正常に判断できなくなる。車を捨てるのはこのときしかない。しかしながら、同時にBは徘徊等をはじめており、この時点で付きっきりの監視必要になる。

Bはヘルパーを拒んでいたため、遠隔地からAがBの世話を頼める人はいない。「徘徊しているお父さんを保護しました」という警察から電話に、予定をすべてキャンセルし、会社に頭を下げて(割安航空券を使わずに)あわてて帰省することになる。

長期休暇は取れない。ここでどうやって車を捨てればよいか

実は車を捨てるという言葉には、二つの意味がある。

普段意識していないが、会話で「廃車」というときには上の二つの意味を両方含んでいる。

この二つを短時間にできるだろうか。

スクラップ処分はできる。近所に業者がいるならば、自走していって車検証と自分身分証を見せるだけで廃棄してくれる。所有者の同意書、委任状などは不要業者確認することを推奨)。

問題は法的な廃車のほうだ。

法的な廃車はAの居住地でもできる。必要ものは:

この二つがあればいい。さてここで問題。Aの言うことをまったく聞かなかったBは、Aに登録印の保管場所を教えてくれるだろうか。

教えてくれているなら幸い。とにもかくにもすぐに廃車処理すべきだ。(来年納税までに捨てればいい)などというのは間違いだ。なにしろ

登録印は自治体の外に引っ越すと無効になる』

Bが自活能力を失ったからAの元に引き取る。あるいはAの居住地の近所の施設に入れる場合、当然住民票を移動することになる。

教えてくれなかった場合印鑑を再登録する必要がある。

ところが、印鑑登録の再登録には本人自筆委任状必要となる。委任状を書けるくらいなら運転心配などあるわけないっつーの。そもそも、委任状を書ける状態ではBはAに同意しない。

この点に関して、役所は一切助けてくれない。結局、この状態になると選択肢は二つ。

偽造が発覚した場合、たぶん書類送検される。裁判で争うのも一興だろう。ツイッター炎上させてメディアを巻き込む。うまくするとゴーストライター適当感動ポルノ本を書いてくれる。印税で買ったワインを飲みながら、すでに知的な話をできなくなったBの耳元に「あんたのおかげで大もうけできたよ」とささやくと、テレビドラマ的で素敵だと思う。

重量税を払わない方法もある。払わないと警察が来るので「この人が脱税しました」と、Bを突き出すのだ。嘘ではない。安全運転納税は所有者であるBの義務だ。うまくするとBはお上が面倒を見てくれる(ないない)。

成年後見人は一番まともな方法だ。成年後見人になれば、Bの代わりに印鑑登録し、廃車することができる。が、認定されるまで数ヶ月かかるという、お役所仕事なので年明けにスクラップにしたなどという場合はあきらめるしかない。

かくのごとく、親の車を捨てるとは面倒な事である

当然だが、ここに延々と書いた面倒な話とは別に「老いの準備を一切しなかった親を引き取る」という大変な事態が同時に発生する。

子供が憎い、子供を少しでも苦しめたい。そう思っている方には『心配しなくていい。俺は大丈夫だ』と言い続けることをお勧めする。効果は絶大である

2016-11-05

なぜソースじゃなく詳細設計を欲しがるのか

Javaを始めとするオブジェクト指向言語による開発になると、設計手法も従来とは大きく変わる。

その結果、不要になるドキュメントが出てくる。

詳細設計のことだ。

ここでいう詳細設計とは、本来コード記述する処理を、逐一日本語で書き下したものを指す。

てか、そんな物を読むくらいなら、現物ソース読めよって話だ。

だいたい、ソースに書くレベル粒度記述を、なんでいちいち日本語なんて表記揺れも甚だしいフォーマットで書かにゃならんのだ。

何よりソース修正が入ると、遡って詳細設計も直さないと整合性が取れなくなるので、言うなれば二重に工数を掛けることになる。

「違うよ、設計を直して実装するんだよ」というが、合理性を重んじるSEPGという人種が、実質同じ内容を何度も書きたがるわけがない。

それに、単体テストくらいまでの段階ならともかく、開発要員が縮小される結合テストシステムテスト以降で、そんなことをしている余裕など現場にはない。

結果、実装と合ってないドキュメントけが放置されてしまう。


でも、そうなることが目に見えているにも関わらず、欲しがる客や元請が後を絶たない。

負担ばっかり増えて、尚且つ無意味作業やらせるなって感じ。

なんでそんなに「日本語訳」が欲しいの?

ぶっちゃけソースコードレビューでいいじゃん。

もし客がソースを読めないなら、その時に客が読みたい部分だけを元請が訳して説明すればいい(全部読みたがるヒマな客なんてそうそういないだろうし)。

そして元請はITプロなんだからソースなんてスラスラ読めて当然なわけで。英語読めない英語専門家存在しないのと同じ理屈ね。

それこそ読み取り専用でリポジトリアカウントの一つや二つくらいいつでも作れるので、ソース抜き打ちレビューどうぞって話だ。


はいえ、別に何も「真実ソースただ一つ!」なんて言うつもりはない。

ソースに行き着くまでにも考えることは色々あって、その考えた結果は全て形に残さなければならない。

ソースもまた考えた結果の成果物の一形態であり、他の形態が、各フェーズで書くドキュメントなのだと思っている。

そしてドキュメントがあるお陰で、システムがトラブった時もいきなりソース問題箇所を探し回る苦労から解放されるのだ。

ドキュメントを手がかりに「このクラスの、このメソッドが怪しい」まで行き着いてから、そこで初めてソース確認すればいいと。

Javaだったら、ユースケース図、アクティティ図、クラス図、シーケンス図、Javadocによるメソッド説明と読み込んでいってアタリを付け、それから当該メソッドソースを読めばいい。

逆に言えば、記述粒度が同じ成果物は2種類以上も要らない。整合性を保つための手間が増えるだけなので。

詳細設計書は不要というのはそういうことだ。

つーか「ソースが読めないか日本語訳を渡せ」とか甘えんな

2016-07-17

Excelに苦戦中

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

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


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

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

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

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

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


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

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

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

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

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

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


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

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

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

ログイン ユーザー登録
ようこそ ゲスト さん