  |
はてなキーワード: ユースケースとは
マストドン。あとは、Dabel
Clubhouse が来るかも知れないし、来ないかも知れない
▼ Clubhouseとは？
Clubhouseは音声版Twitterと言われている音声SNS。さまざま人の「部屋」に入り、話を聞いたり、手を挙げて参加することが可能だ。部屋に入っていれば友達を呼べるが、その友達が承認しないと実際には入ってこない。オフラインのClubhouseっぽい感覚に近いサービスになっている。
テーマは参加している登壇者が決めるので、かなり自由なユースケースが生まれるのと、今現在はテック業界などの著名人が集まっている。例えば、D2CエキスパートのWeb Smith（ウェブ・スミス）氏がShopifyの話をしていたときに、ShopifyのCEOが自ら参加していた。
[TechCrunch Japan] 米国スタートアップ界で話題の次世代SNS「Clubhouse」になぜ100億円以上も時価総額がつくのか？
https://jp.techcrunch.com/2020/05/17/clubhouse/
本当に迷惑なんだ。
センスがない奴の何が問題かというと、技術がないとか、ベストプラクティスを知らないということではなく、根本的に「頭がおかしい」ことなんだ。
センスのない奴は、普通の人間が到底思い付かないことを平然と行う。所詮、本に書いてあるようなアンチパターンは、「経験のない人は典型的にこういうことをしがち」という例であるが、センスのない奴はそういう典型的なアンチパターンにすら当てはまらないほど意味不明なことをする。だから、「センスのない奴は典型的にこういうことをする」という具体例を挙げることが非常に難しいし、「ここがダメだから直せ」という指摘もできない。
普通の人なら、何も考えず以下のような実装をするだろう。フィールドの定義とデータが分かれているのは、ユースケースによってフィールドが可変だからだ。
[
{fieldName: "id", title: "id", type: "number"},
{fieldName: "name", title: "商品名", type: "text"},
{fieldName: "price", title: "値段", type: "number"}
]
[
{id: 1, name: "商品A", price: 100},
{id: 2, name: "商品B", price: 200},
{id: 3, name: "商品C", price: 300}
]
ところが、センスのない奴はたとえば以下みたいな意味不明な実装をナチュラルに行う。
[
{id: "0-0", val: "商品名", type: "text"},{id: "0-1", val: "値段", type: "text"},
{id: "1-0", val: "商品A", type: "text"},{id: "1-1", val: "100", type: "number"},
{id: "2-0", val: "商品B", type: "text"},{id: "2-1", val: "200", type: "number"},
{id: "3-0", val: "商品C", type: "text"},{id: "3-1", val: "300", type: "number"}
]
一応言っておくと、これは実例の一部を分かりやすいように切り取っただけであり、本物はもっとひどい。
センスのない奴っていうのは、スキル云々の問題ではなく、そもそも認識している世界が常人と異なるから、矯正は無理だし、チームにいると非常に迷惑なんだ。だから、プログラマにはならないでくれ。
https://b.hatena.ne.jp/entry/s/gist.github.com/mattn/488af4c3b3841ea901a1f9820636393c
ワイはallow/blockが好きやなあ
aとbだから
----
masterとslaveの意味がしっくりくるのはscsiくらいなもんだと思う
(gistに代替案が書いてあるけどfollowerでもworkerでもreplicaでもないよな)
----
白黒つけるって発言もそのうちできなくなるから、今のうちにいっぱい言っておいた方がいいんでないかい
----
一昔前ならそんな荒唐無稽なことは言わないのだけど、アメリカ社会の馬鹿さ加減について認識が改まった昨今において、彼らがやらないという確信はもはや持てない。すまないね
情報処理技術者試験の資格を取っても実質的に得るものはありません。「実質的に」というのは、技術者としてのスキル向上に貢献するということであり、「報奨金が貰える」とか「履歴書に書ける」などの技術と無関係なものを含まないということです。
なぜ、情報処理技術者試験が役に立たないのかと言えば、出題内容が表面的な知識問題に極端に偏っており、本質的な理解を問うていないからです。たとえば、オブジェクト指向の三要素に「カプセル化」「継承」「ポリモルフィズム」がありますが、これらを御題目のように唱えていても何の意味もありません。しかし、情報処理技術者試験ではこれらの用語さえ覚えておけば、しっかり点になります。
https://www.fe-siken.com/s/kakomon/19_haru/q42.html
こんなのは単なるポエムであり、これが解けたところでコードが書けるわけでも、良い設計ができるわけでもありません。
数学で喩えれば、「加減法」とか「代入法」のような用語を暗記して、具体的な連立方程式の解き方は分からないようなものです。
ひどい問題は挙げればキリがありません。
https://www.ap-siken.com/s/kakomon/22_haru/q44.html
図の名称を答えさせる問題。図を読み取らせる問題なら、まだ理解できますが。そもそも、UMLなど別に技術者として知っておくべき知識でもありません。
https://www.fe-siken.com/s/kakomon/23_aki/q50.html
これも、こんな分類自体、覚えたところで何にもならないわけですが、その用語を答えさせる問題。いかに、この試験がエンジニアリングやプロジェクト管理の本質と関係ないかがよく分かります。
極めつけはこれ。
https://www.fe-siken.com/s/kakomon/17_haru/q52.html
地方の公立中学校の定期試験レベルのひどい問題です。出題者は、1だの2だの4だの7だのといった数字と語句の対応を覚えることが重要だと思っているのでしょうか。
つまり、ある種の発達障害ではない意識高い系ポエマーを認定するための試験であり、そもそも技術者のための試験ではないということです。あとは、中小企業診断士などを受ける人が試験免除を獲得するためとか。
そもそも、コンピュータやプロジェクトマネジメントの技術を、資格試験で勉強しようというのがピントがズレています。それらは既に良質な解説書が豊富にあるのだから、それで勉強すればいいのです。
モバイルアプリの実装と言えば主力はKotlin、Swift(Objective-C)だけど、簡単な作りであればcordovaをベースにフロントエンド開発ライクに進められる。
そもそものライブラリ選定には関わっていなかったものの、便利と思って使った結果後悔した思い出のお話。
Angular, Vueで実装していたけどレンダリング系に属するイベント盛りだくさんの場合、
結果的にネイティブ実装したほうが楽だしレンダリングの面で有利。
そもそもcordovaだからと言ってネイティブの知識がいらないわけじゃない。
標準サポートしているプラグイン群でできることは限られてくるし、そのまま突き進むならネイティブ実装の知識は必要になる。
これは当たり前だけど…
JSのパッケージングだったりCSSビルドが組めないとなると逆にコスト高。
そもそもNode.jsのビルドを根本的に理解してない奴がプロジェクトを作ったせいで
JSのパッケージビルドもされない、jQueryを突っ込まれるなどひと悶着あった。
3年前くらいだったけど既にTypeScriptも出てたし、何故そうしなかったのか理解できない。
結果ロードが激重になった。そりゃそうだ、minifiedされてないのだから。
用法用量を正しく守って使わないと、後で面倒になる好例だった。
大概は専用プラットフォーム上でビルドしていくがこれがくせ者。
ブラウザIDE(という名のただのテキストエディタ)が使えるけどそもそも構成管理できない。
ローカルビルドと乖離するし、ブランチすら切れないのだから本人以外は触れないシロモノになってくる。
別端末でビルドしようとすると同名の新しいプロジェクトが作成される。
ここまでくるともう触りたくなくなる。ただ、触らないわけにはいかないので何とか整合が取れる状況にした。
さらに言えば、ビルドが終わってステータスが見れるが、内訳が見れるのはそのタイミングだけ。
多分、海外で公開したプラットフォームをそのまま持ってきてるんだと推測しているが流石にこれは悪意しか感じない。
ただのCLIをバックグラウンドで実行するだけのGUIラッパーと化している。
かといってlintを掛けてくれるわけでも無し。
個人的に要らないし今後は使わない。
突き当たったのはWebSocketを使うシーンが出てきたとき。
ライブラリで何とかする方向で進めたかったけどそもそもwebpackビルドにすら対応していなかった。
件のAngularベースの場合はもっとひどくてクソラッパーを作りやがったせいで依存度が激高になった。
ちなみにネイティブはそれぞれにサポートするライブラリが出ていて、最新バージョンに向けてきちんとメンテナンスされている。
根本的にiOS側の実装でレスポンシブ的なレイアウトが作りにくい現状を鑑みて、
WEBベースで新商品などの通知をしたい、残りは情報の閲覧のみでSPA構成的なシロモノで作りたい。
こんな需要には使ってもいいんじゃないかと思う。相当なレアケースだけれども。
いいところは確かにあって、CSSでデザインの調整が効くところは大いに評価できる。
これがまたネイティブ実装だと面倒。特にiOS。お前はダメだ。
結局進めていくとネイティブ実装の知識を求められるのだから、ネイティブで実装したほうが良くね？と言ったところ。
ユースケース的に超単純要件でアプリを作りたい、かつ、ユーザに何かpush通知的なやつを入れたいって場合は使ってもいい気がする。
初投稿につき至らない点があるかもしれないが容赦してほしい。が、指摘は受け入れる所存。
俺はとあるUIコンポーネントライブラリ開発者だが、先日議論されたあるコンポーネントの設計について悩み続けている。
これを読んでくれた人の設計センスや知識、経験から、第三者の率直な意見を聞きたい。
悩んでいることの概要は、
ざっくり言えばこの2択だ。
どちらも間違った考えだとは思えないので、そもそもどちらかの捉え方がおかしいのだと思う。そういった意見も聞きたいが、まずは読んでみてほしい。
設計対象のコンポーネントは、よくある触って動かせるスライダーである。下記リンク先のようなものだ。
https://material-ui.com/components/slider/
加えて、下記も前提としてほしい。
Sliderというコンポーネントクラスを作るとして、これらの構成要素をライブラリ-ユーザー間でどう分担するかという点で、AさんとBさんで意見が割れた。
それぞれの意見を要約すると下のようになる。Aさんはカプセル化を狙い、Bさんは単一責任原則を重視している。
画面 └ Slider (ユーザーが作成) ├ 背景バー ├ ノブ └ 進捗バー
Aさん案の場合だと、Sliderクラス内部で勝手にそれぞれの要素を作成し、自分の子にするなりして表示する。
画面 ├ 背景バー (ユーザーが作成) ├ ノブ (ユーザーが作成) ├ 進捗バー (ユーザーが作成) └ Slider (ユーザーが作成) ├ 背景バーへの参照 (ユーザーが指定) ├ ノブへの参照 (ユーザーが指定) └ 進捗バーへの参照 (ユーザーが指定)
Bさん案では、ユーザーが構成要素それぞれを作成し、Sliderにそれを食わせる。
SliderはAさん案のように各構成要素を構築する必要はなく、ノブの移動や進捗バーのサイズ変更だけすれば良い。
Aさんはユーザーが制御する必要のない背景バー、ノブ、進捗バーの構成を隠蔽(カプセル化)しようと提案したが、
Aさん案に対しBさんは、単一責任原則の観点から「各構成要素の構築や表示」という責任を外すべきだと訴え、Bさん案を提示した。
またBさんは、コンポーネントはユーザーが扱うべきものであり、コンポーネントがコンポーネントを内部で勝手に使用しているのは混乱を招くとの見方もしている。
ただしAさんの考えの通り、実際に各要素の構成をユーザーが制御するユースケースは存在しない。
その場では「単一責任原則」を持ち出したBさん案で決定された。
しかしなんとなくAさん案派だった俺はモヤモヤしたまま家に帰り、本当に単一責任原則に反しているのか、カプセル化よりも大事なのかと悩み続けている。
ここまでが事実となる。
さて本当にBさんが正しかったのか、あるいは単一責任原則の捉え方が間違っているのか、はたまた・・
第三者による意見が聞きたい。周りのコメントに左右されない率直な意見が望ましい。なんとなくな意見も歓迎する。
満たすべき機能は見た目だけではないがそこは置いておいてほしい。
ログとはここでは、特にprintf()やロギングライブラリを使いアプリに仕込まれた明示的な出力とする。
攻撃来てるかとか気付けるし、ビッグデータとしてゴニョゴニョ解析できるし。知らんけど。
バグが起きた時とか、基本的に再現手順を元にデバッガーのブレイクポイントとか使うだけで、ログは実際全然見てない。
あとネットワーク解析ソフトと、アプリに埋め込む系のデバッグツールあれば十分って感じ？
役立つログなんて、デバッガーの調子が悪い時にコミットしないものを一瞬入れるくらいかなぁ？
バグが起きた時はQAとかから再現手順と一緒にコンソール出力も飛んでくる。
その中で例外出力は有用なことが多いんだけど、それはハンドリングされなかったのが出てるだけ。
・文章を書くときは主観的になりきる（感情移入する）必要があるが、プログラムは客観的にメタな考え方でつくる必要がある
⇨コンピュータやシステムの立場になって考えている。UMLのユースケース図は証左。たぶん、増田がコンピュータに感情移入できないから、そのように思うのだろう。クルマを愛車と呼ぶのか、単なる移動手段の一機械としか思えないか。どちらが良い悪いは無いけど。
・プログラムは意味や内容がわかっていないことについて書けない
⇨かつてはやり直しコストが高かったのでウォーターフォールモデルが主流だったが、現在はWYSIWYGのごとく、コードを書いて、動かしてみて、検討しなおしてコードを書く、といった繰り返しで調整して作っていくこともそんなに変ではない。
作りたい成果物が決まっているのは、文章も何らかの意図を持って書くのだから一緒。
私の結論：プログラム言語は、英語にも増した世界共通の言語（よく変わるけど…何処かの進学塾のセンセが書いていたけど、数式のほうがさらに普遍性が高い）
Androidを6年使ってきて先月iPhone 8に乗り換えた人間の私見．
個人的な結論としてはFGOをやめさえすれば本当にどっちでもいいなという感じ．
特にiPhoneXなんてのは仮に使いこなせないにしても他の人の耳目を集める。
結果的に使い方を学べたりして損はしない格好になるだろ。
お金はかかるが、少ない情報から導き出せる安牌としてこれ以上の答えは無いだろ。
次点で「タブレット」だが、ご老輩だからといってタブレットを持ち歩きたいと思ってるかどうかは微妙。
ファブレットすら死詞になりつつある昨今、タブレットは「ダサさ」の象徴とみなされてる可能性もさもありなん。
老人のフィジカルとユースケースを考えればアリな選択肢ともいえるが、ご老人だからこそプライドの高さはあるもの。傍目にダサいものをプレゼントされて喜べるかどうか。親を辱めるためにプレゼントをしたいなら止めないよ？
そして、タブレットには漏れなく種類大杉問題が纏わりつく。安全牌のiPadですら選択肢を間違えるとただの物置のガラス板だ。
だからこそ、増田はリスクを抑えなおかつ喜ばれうるものをプレゼントしなければいけない。
アプリなんかでユーザーインタビューをやるという話をよく聞くけど、意味を履き違えている人が多い気がする。
定性的調査である以上、本来の意味はユースケースなりペインポイントの「異なる視点からの気づき」を得ることであって、それ以上でもそれ以下でもない。
その気づきにフォーカスしてみるのかどうかはプロダクト責任者次第だし、その気づきが多くの共感を得るかもわからない。
なので、この調査から「ユーザーはここに困っている」と決めつけるのは全く違うし、集団心理が働くため正確な結果かどうかもわからない。
都合の良い結果だけを議論に持ち出して説得するのには有効かもしれないが、この場合はただ「お金を払って調査した」という事実が欲しいだけである。
気づきを得るためなら本質的には、友達とかその辺の人に聞いて回るのだって良いと思う。
ビットコインとは何か、という記事が注目を集め始めているが、もっぱらビットコインの投機性に対してのみ注目を集めていて、どういう実利があるのか・無いのかという話に踏み込んでいる記事が少なすぎると思う。
ビットコインが役に立つ状況と、その前提条件について、素人なりに思いつくところを書いてみる。
普通に銀行口座を使って高額のお金を送金しようとすると、それなりの手数料がかかる。安くても２％、５％以上取られるケースも多い。
これに対して、日本でビットコインを購入し、海外にビットコインを送り、送った先でビットコインを現金化すれば、銀行に手数料を払うよりも安上がりになる可能性が高い。
但し、ここで問題は、送金元となる国でビットコインを売ってくれる人が居る事、そして送金先でビットコインを買ってくれる人が居ることだ。送金先があまりにも小国でマイナー通貨だったりすると、上手くいかない可能性がある。
さてここで、海外送金について最も切実な需要がある国はどこかといえば中国である。中国は、お金を海外に送金したり持ち出したりすることに関して非常に厳しい規制がある。一方、中国からアメリカや日本に送金したいという需要は莫大にある。この問題に、ビットコインは風穴を開けている可能性がある。
ビットコインに関しては、中国の方が良くも悪くもずっと進んでいるし、現実問題として中国ではビットコインに切実な需要があるのだ。
ただし、これには前提条件がある。中国でビットコインを購入し、それを日本で日本円に換金したい場合、日本でビットコインを購入してくれる人が必要だ。ではどうやって日本でのビットコイン購入者を増やすか。ビットコインには現状、市場操作（価格操作）に関する規制が無い。中華マネーをもってすれば、日本の小さなビットコイン市場を操作することなど朝飯前だと思わないか？
ケイマン諸島やパナマなどが、租税回避地として騒がれたのは去年の話だ。これに対して、各国の税務署が協力し合って対策を講じ始めている。つまり、放置しておくと莫大な徴税を受ける可能性のある金持ちや企業が世界中にごろごろ居るという事だ。
それで、代わりになる新たな租税回避の手段が、あれやこれや模索されているわけだが、そこでビットコインが注目を集めている可能性がある。ダメもとでビットコインを購入し、結果としてビットコインが無に帰したとしても、どうせ放置しておけば徴税されるお金だ。上手くいけば値上がり益を得られる可能性もある。最終的にはビットコインにも税務署の手が入るだろうが、ケイマン諸島やパナマよりは後のことになるだろう。
海外への送金の手数料が高かったり、色々な規制が入ったりする理由の一つは、それが犯罪によって得られたお金である可能性があるためだ。なので、ここには常に監視の目が光っている。これを免れる手段として、ビットコインは有効だ。今のところ。あとは説明する必要は無いね？
上記の３つの例では、いずれも巨額のお金が動く。ビットコインのバカげた高騰を説明するのには十分では無かろうか。
ビットコインは優れた技術かもしれないが、それが高騰している理由は、必ずしも褒められる理由では無い可能性があるということを認識してほしい。
一般市民が手を出すのは、十分な法整備が行われ、金融庁や税務署や公正取引委員会などの監視の目が光るようになってからでも遅くないよ。
仮想通貨をめぐる情報はアフィリエイトと仕手筋が入り混じりクソを煮詰めたがごとき肥溜めになってしまっているので、
損得抜きに「仮想通貨取引とはこういうものだ」という実感を書いておく。
通貨のコンセプトを読んで、「ユースケースは？スケールする？技術的課題は？」といったことがパッと頭に浮かぶやつが適している。
むしろ株取引に慣れた金融出身にはアドバンテージがないと考えるべき。
別に遅くはない。
ただし暴落する可能性もあるので遊べる金でふわふわするぐらいにしておけ。
やめとけ。 ツルハシを売る業者とツルハシを振るう業者が一方的に儲かるように整備されたクソ通貨。
最初に作られたという以外に特徴がない。近いうちにイーサリアムかリップルに抜かれる。
他のコインの購入は基本的にビットコイン建てで行われるという不幸な状況だから。
例えばどこかの取引所がイーサリアム建てで買えるようにした瞬間に、ビットコインの価値は大暴落する。
暗い。最近はマイニング不要の通貨とか、そもそもブロックチェーンですらない通貨が作られだしている。
まず少しでいいからブロックチェーンを勉強しろ。今国内で買えるヤツで挙げるなら↓だ。
一年忘れることが難しいなら、とりあえず買ったあと値動きを見ろ。
そして気の向くままに情報を漁れば良い。
取引所が破綻するリスクがあるので、万全を期すならハードウェアウォレット買って入れておけ。
90%は詐欺。9%は技術不足で沈没。0.9%は開発されるけどスケールしない。
もしあなたがエンジニアなら、その通貨のホワイトペーパー読んでみ。あまりのクソっぷりに失笑するから。
それでも買いたければ買えばいい。
すでにその通貨を仕込んでいる連中が叫んでいるだけ。
他の人が釣られて買うことにより値上がりを待ち、売り抜けをする愚劣なカスどもだ。
リップル。20円のころに200万買って、いまは3200万に化けた。
SBIの北尾が全力でSWIFTを奪りに行っているので、あと二年は寝かせる予定。
ごもっとも。ただ、正しい技術にお金を突っ込むのは投機ではないと思う。
「買うのは企業、株ではない」とバフェットも言ってるだろ。「買うのは技術、仮想通貨ではない」のだ。
その仮想通貨が提案する未来を信じられるなら、金を入れろ。短期で売るな。寝かせろ。
エンジニアが儲けを出しやすい特性もあるし、現状クソ通貨をクソだと言える人が少ないため他の人にももっと入ってきて欲しいと思っている。
うーん、何か違うなぁ…と思ったので前作S+99勢が考えるスプラトゥーンのアドバイス
他にもあると思うけど、とりあえず思いついたものだけ