「インタフェース」を含む日記 RSS

はてなキーワード: インタフェースとは

2017-11-17

anond:20171117002409

消される場合はだいたい書いた当日に(または、書いた直後にSPAM/連投で運営に)消されるってことだな

書いて2日後3日後に消されるのはまとめて消去かな

増田は消すインタフェースが悪いから、さあ消すぞというモチベがないと消せないのだが

2017-11-05

iOS進化の無さにがっかりした

脱獄済みiOS9 をずっと使っていたのだが、iOS10以降じゃないと対応していないアプリがあったり、

Suica使いたかったりしたのでiPhone Xに変更した。

FaceIDは初代TouchID並には便利だが最新TouchIDと比べると正しく認識されないことも多く不便だなと感じたが、

それは想定内なので良い。

それ以上に問題だったのがiOS進化の無さであった。

大画面化しているのにフォルダ開いたときアイコン数が3×3だったり、脱獄アプリパクリ複数アイコン移動のインタフェースゴミだったり、

未だに柔軟に設定できないActivatorもどきだったり (上からSwipeはNotificationとContorolCenterで左右違うのに、下からSwipeを左右分けられていないのは何故!?)

細かなところではあるんだけど何かがっかりだった。

2017-10-16

スライド表示が嫌い。SlideShare とか SpeakerDeck とか。

全画面と「次のページ」「戻る」しかないインタフェースがつらい。

流し読みできないし

スライドを一枚ずつめくらないといけないインタフェースがうざすぎる。

発表資料アップロードしてくれるのはありがたいし、発表者がそのままアップロードするだけの手軽さは賞賛されるべきだが

スライド表示モードは発表者という特殊立場の人のためだけに必要特殊モードであって

一般読者が見やすものじゃない

特別ボタンを押したら、スライドモードになる くらいでちょうどいい

SlideShareとか昔はスマホで見ると縦スクロールできたのに、わざわざスライドモード実装して何考えてるのって感じ…

アニメーション特に再現できているわけでもないし

あと画像カルーセル表示とかも嫌い

googleマップ画像一覧とかも一覧モードにならなくてつらい

qitta のスライドモード開発者デザイナーオナニーしか見えない

2017-09-24

anond:20170924113525

そういうのを負け惜しみという

それを書いて発表すること自体負け惜しみという

自分の考えは他人に伝わるだなんて子供じみた思いを持っていたのかね

君の考えは万の言葉を以てしても誰にも理解されない

君の考えは誤解され曲解され単純化され戯曲化される

それはそういうもの

言葉というインタフェース自体がもともとそういうものなのだ

2017-09-11

https://anond.hatelabo.jp/20170910205249

まじな話をすると、N予備校プログラミング入門コースやるのがオススメ

https://www.nnn.ed.nico

一日8時間勉強時間があるなら、だいたい一ヶ月で終わる内容。

月額1000円だけどしっかり勉強すれば一ヶ月の無料間中に終わると思う。

もともとN高等学校のノンプログラマーの生徒をWebエンジニアとして就職させるために作られたカリキュラム講師曰く去年はこれで二人エンジニア就職を決めたらしい。

内容も相当親切に説明していて、プログラミングで何か作るだけじゃなくて、就職必要な環境構築やセキュリティまでみっちりやる。

http://qiita.com/sifue/items/7e7c7867b64ce9742aee#%E3%82%B3%E3%83%B3%E3%82%BB%E3%83%97%E3%83%88%E3%82%92%E3%82%82%E3%81%A8%E3%81%AB%E6%A7%8B%E6%88%90%E3%81%95%E3%82%8C%E3%81%9F%E3%82%B3%E3%83%BC%E3%82%B9%E3%81%A8%E5%86%85%E5%AE%B9

講師が書いてる入門コースで習うことがまとめ。テキスト教材もあるけど授業も1項目を2時間で説明している。授業は週2の生放送とそのアーカイブがある。

↓みたいなことが学べる

----

Webプログラミング入門コース

Web ブラウザとは (Chrome, デベロッパーコンソール, alert)

はじめてのHTML (VSCode, HTML, Emmet)

さまざまなHTMLタグ (h, p, a, img, ul, tableタグ)

HTMLで作る自己紹介ページ (HTMLタグ組み合わせ, コンテンツ埋め込み)

はじめてのJavaScript (JS, ES6, エラー)

JavaScriptでの計算 (値, 算術演算子, 変数, 代入)

JavaScript論理を扱う (論理値, 論理積, 論理和, 否定, 比較演算子, if)

JavaScriptループ (ループ, for)

JavaScriptコレクション (コレクション, 配列, 添字, undefined)

JavaScript関数 (関数, 関数宣言, 引数, 戻り値, 関数呼び出し, 再帰)

JavaScriptオブジェクト (オブジェクト, モデリング, プロパティ, 要件定義)

はじめてのCSS (CSS, セレクタ, background-color, border)

CSSを使ったプログラミング (transform, id, class)

Webページの企画とデザイン (企画, 要件定義, モックアップ, 16進数カラーコード)

診断機能の開発 (const, let, JSDoc, インタフェース, 正規表現, テストコード)

診断機能組込み (div, 無名関数, アロー関数, ガード句, truthy, falsy)

ツイート機能の開発 (リバースエンジニアリング, URI, URL, URIエンコード)

Linux開発環境構築コース

LinuxというOS (VirtualBox, Vagrant, Ubuntuインストール, OS, CUIの大切さ)

コンピューター構成要素 (ノイマンコンピューター, プロセス, lshw, man, ps, dfの使い方)

ファイル操作 (pwd, ls, cd, mkdir, rm, cp, mv, find, ホストマシンとの共有ディレクトリ)

標準出力 (標準入力標準出力標準エラー出力パイプgrep)

vi (vimtutor)

シェルプログラミング (シバン, echo, read, 変数, if)

通信ネットワーク (パケット, tcpdump, IPアドレス, TCP, ルーター, ping)

サーバークライアント (tmux, nc, telnet)

HTTP通信 (http, https, DNS, hostsファイル, ポートフォワーディング)

通信をするボットの開発 (cron, ログ収集)

GitHubウェブサイトの公開 (GitHub, リポジトリ, fork, commit, 情報モラル)

イシュー管理とWikiによるドキュメント作成 (Issues, Wiki)

GitとGitHub連携 (git, ssh, clone, pull)

GitHubへのpush (init, add, status, インデックス, commit, push, tag)

Gitのブランチ (branch, checkout, merge, gh-pages)

ソーシャルコーディング (コンフリクト、プルリクエスト)

Webアプリ基礎コース

Node.js (Node.js, nodebrew, Linux, REPL, コマンドライン引数, プルリク課題)

集計処理を行うプログラム (集計, 人口動態CSV, Stream, for-of, 連想配列Map, map関数)

アルゴリズムの改善 (アルゴリズム, フィボナッチ数列, 再帰, time, プロファイル, nodegrind, O記法, メモ化)

ライブラリ (ライブラリ, パッケージマネージャー, npm)

Slackボット開発 (slack, mention, bot)

HubotとSlackアダプタ (hubot, yo)

モジュール化された処理 CRUD, オブジェクトライフサイクル, filter)

ボットインタフェースとの連携 (モジュールのつなぎ込み, trim, join)

同期I/Oと非同期I/O (同期I/O, 非同期I/O, ブロッキング)

例外処理 (try, catch, finally, throw)

HTTPサーバー (Web, TCPとUDP, Webサーバーの仕組み, Node.jsイベントループ, リスナー)

ログ (ログ, ログレベル)

HTTPのメソッド (メソッド, GET, POST, PUT, DELETE, CRUDとの対応)

HTMLフォーム (フォームの仕組み, form, input)

テンプレートエンジン (テンプレートエンジン, jade)

HerokuWebサービスを公開 (Webサービスの公開, heroku, dyno, toolbelt, login, create, logs)

認証利用者を制限する (認証, Basic認証, Authorizationヘッダ, ステータスコード)

Cookie を使った秘密匿名掲示板 (Cookie, Set-Cookie, expire)

UI、URI、モジュール設計 (モジュール設計, フォームメソッド制限, リダイレクト, 302)

フォームによる投稿機能の実装 (モジュール性, textarea, 303)

認証された投稿の一覧表示機能 (パスワードの平文管理の問題, 404, テンプレートのeach-in)

データベースへの保存機能の実装 (データベース, PostgreSQL, 主キー)

トラッキングCookieの実装 (トラッキング Cookie, IDの偽装, Cookie の削除)

削除機能の実装 (データベースを利用した削除処理, 認可, サーバーサイドでの認可)

管理者機能の実装 (Web サービス管理責任, 管理者機能の重要性)

デザインの改善 (Bootstrap, レスポンシブデザイン, セキュリティの問題があるサイトを公開しない)

脆弱性 (脆弱性, 脆弱性で生まれる損失, 個人情報保護法, OS コマンド・インジェクション)

XSS脆弱性対策 (XSS, 適切なエスケープ処理, リグレッション)

パスワード脆弱性対策(ハッシュ関数, メッセージダイジェスト, 不正アクセス禁止法, パスワードジェネレーター, 辞書攻撃)

セッション固定化攻撃脆弱性対策 (セッション, セッション固定化攻撃, ハッシュ値による正当性チェック)

より強固なセッション管理 (推測しづらいセッション識別子, 秘密鍵)

CSRF脆弱性対策 (CSRF, ワンタイムトークン)

安全なHerokuへの公開 (脆弱性に対する考え方, HTTPの廃止)

Webアプリ応用コース

Webフレームワーク (Express.js, フレームワーク導入, 簡単なAPI, セキュリティアップデート, Cookie パーサー, ミドルウェア, 外部認証, ロガー)

ExpressのAPI (app, Properties, Request, Response, Router)

GitHubを使った外部認証 (Passport, OAuth)

スティングフレームワーク (Mocha, レッド, グリーン, リファクタリング)

継続的インテグレーション (CircleCI)

クライアントフレームワーク (Webpack, Chrome 以外のブラウザでもES6)

DOM操作フレームワーク (jQuery, jQueryアニメーション, this)

AJAX (jQuery.ajax, クロスドメイン, 同一生成元ポリシー, x-requested-by, CORS)

WebSocket (WebSocket, WebSocketの状態遷移, Socket.io)

RDBとSQL (DDL, DCL, CREATE, DROP, INSERT, DELETE, UPDATE, WHERE)

データモデリング (リレーショナルモデル, 正規化)

テーブルの結合 (外部結合, 内部結合, 片側外部結合, JOIN ON)

インデックス (インデックス, 複合インデックス, Bツリー)

集計とソート (SUM, COUNT, ORDER BY, GROUP BY)

「予定調整くん」の設計 (要件定義、用語集、データモデル、URL設計モジュール設計、MVC)

認証とRouterモジュールの実装 (Mocha, supertest, passport-stub, モックテスト)

予定とユーザーの保存 (セキュリティ要件, UUID, 複合主キー)

予定とユーザーの一覧の表示 (非同期処理, Promise, then)

出欠とコメントの表示 (入れ子の連想配列, Promise.all, 子どもからデータを消す)

出欠とコメント更新 (Promiseチェイン, リファクタリング)

予定の編集と削除 (要件の衝突, 関数再利用)

デザインの改善 (this, グローバルオブジェクト)

セキュリティ対策と公開 (X-Frame-Options, Heroku環境変数)

2017-04-04

http://anond.hatelabo.jp/20170403094257

これ、技術 vs マネージメントという単純な話でもなくて。

要はソニーなりの大企業になると大きな仕事をしなくてはならなくて、職人がひとりでできるひとり分の仕事をしていては回らないわけで。

そのときどうスケールさせるか、という話。

日本企業は、昔から製造工場ライン工メタファーで極力プログラミング単純作業に落とし込んで、多くの低スキルプログラマーによりスケールする道を選んだ。

まあ原始的プログラミング言語時代はそれでもよかった。

一方アメリカをはじめ諸外国は、ある時期からプログラミング科学、つまりコンピュータサイエンス数学を持ち込んでスケールさせようとした。

コンピュータ自体最初から科学産物だけど、それをビジネスに展開するときの話ね)

から日本でのプログラマー地位海外に比べて低く、早くマネージメントに上がれといわれ続ける。

日本企業の誤算は、ソフトウェア進化ハードウェア進化よりもずっとずっと誰も予想がつかないほど速く、ドラスティックだったことで。

さらに世の中が急速に進化して、サービス時代になるとフィジカルインタフェース以外は全部ソフトウェアという製品も出てきた。

もはやこうなると多数のライン工プログラマーを抱えたハード屋という構図では圧倒的なアウェイしかない。

もし大企業が本気で変わる気があるなら、製造工場の考えを全部捨ててゲーム制作プロジェクト、それもAAAタイトルの巨大なプロジェクトスタイルを他のビジネスにも取り入れるのが良いと思っている。

(これはハリウッド映画制作メタファーでもある)

ベテランプログラマーがひとり分だけの職人仕事をするのは大企業では難しい。でもその才能を生かしたまま映画監督のように大きなプロジェクトチームを率いることはできるはずで、たぶんソニーはそういうことのできる会社だったはずで。

2017-03-11

http://anond.hatelabo.jp/20170311123528

元増田です。

AppleWatchについて購入日以来モヤモヤしていたものがやっと言語化できましたのでここにまとめてみます

どうせ長ったらしくなるので、まとめは次のようになります

大前提: 時計装置基本的操作に向いていない

とにかくこれに尽きます。もう少し詳しく言うと次の2点に集約されます

1. 両手が必要

2. ポーズしんどい

1.については議論必要はないと思います(Hey Siri除く)。

2.については時計を見るポーズをとってください。そして、そのポーズキープしてみてください。

おそらく、5秒くらいで面倒くさくなってきたのではないでしょうか。

はっきりいって、操作の楽さ加減ならば、脇をしめて操作できるiPodやAppleRemoteのほうが優秀でしょう。

AppleWatchは通知とコンプリケーション(文字盤)が6割

残りの4割のうち3割はアクティティです。1割はMac自動解除とHey Siriカップラーメン機能です。

AppleWatchリリース以来、色んなアプリリリースされましたが、ほとんど使用されていません。ヒット作についても私は聞いたことがありません。

なぜか?

本当に操作が面倒なんです。アプリケーションを呼び出すボタンを押して、アプリを選ぶだけで2〜3秒かかりますそれから小さい画面に向かってあれこれするわけですが、これならiPhoneを取り出した方が早いんです。

結果、AppleWatchで常時見ているのは文字盤と通知だけです。私が普段使っているアプリIFTTTとStressDiary、呼吸だけです。

コンプリケーションと通知に表示される情報がAppleWatchのコア機能といってもいいでしょう。

リュウズがイケてない

AppleWatch発表時、リュウズが革命的なインタフェースだと喧伝されました。そのことは間違いないでしょう。

しかし、この、リュウズをどう使うかについてしっかり検討されたとは思えないのです。

リュウズに対応したアプリでは、リュウズの回転に応じてスクロールされます。そして、目的のものが表示されました、そして、リュウズを押したとしましょう。どうなるか?アプリ一覧画面に戻ってしまうのです。

AppleWatchでは、アプリ上でなにかの操作について決定をする場合、画面を押す必要があります。ちゃんと押せたかどうかわからないのにもかかわらず。

確かに、AppleWatchにはボタンが足りていません。ですが、せっかくのリュウズについてアプリ一覧に移ってしまうのは失敗だと言わざるを得ません。

まとめ

結局のところ、AppleWatchはアプリ操作性が悪すぎるのです。iPodも色んな機能がありますが、持ちやすく、片手で操作できるため、シンプルですが多少複雑な機能を使いこなすことができます

次期AppleWatchでは、下のボタンを二つに割り、ボタンを増やし、リュウズはアプリに渡すようにしてほしいと思います

2016-12-06

DeNA著作権周りの過去の事例

1. 釣りゲーパクリ事件(2009年)

釣りゲーム訴訟グリー敗訴が確定 最高裁が上告退ける

http://www.itmedia.co.jp/news/articles/1304/17/news126.html

訴訟2009年9月DeNAモバゲータウン(現Mobage)で配信していた「釣りゲータウン2」が、グリーの「釣り★スタ」に似ているとして、グリーDeNAと開発元のORSOに対し配信差し止め損害賠償を求めて提訴していた。

一審・東京地裁判決DeNAによる著作権侵害を認め、著作権法不正競争防止法に基づきDeNAに対し約2億3000万円の損害賠償の支払いと「釣りゲータウン2」の配信差し止めを命じた。二審・知財高裁判決では、両社の釣りゲーム共通するユーザーインタフェースUI)などについて、著作権法保護されない「アイデア」や、釣りゲームならではの「ありふれた表現」だと指摘。具体的な表現が異なっており、DeNA作品からグリー作品表現上の本質的な特徴を直接感得することはできないとして、著作権侵害を認めず、グリーの主張を退けていた。

2. DeNAライセンス事件(2012年)

DeNA、「オープンソース」をうたうライセンスで一騒動

https://opensource.srad.jp/story/12/01/25/0741213/

ソーシャルゲーム開発大手DeNAHTML5開発支援フレームワーク「Arctic.js」を公開したのだが、そのライセンスを巡って一悶着が発生した。

当初ライセンスには『「Mobageオープンプラットフォーム」以外において営利目的使用・複製などする際は、書面による使用許諾が必要になります』と記載されており、Open Source InitiativeOSI)によるオープンソース定義矛盾していた。しかし、DeNA側はこれを「オープンソース」と呼んだために非難が集中。その後DeNAはこの独自ライセンス撤回ライセンスMIT Licenseに変更した。

3. キュレーションメディアWELQ炎上事件(2016年)[New!]

DeNA医療サイト炎上」で休止…検索誘導過熱

http://www.yomiuri.co.jp/science/feature/CO017291/20161201-OYT8T50043.html

大手IT企業ディー・エヌ・エー(DeNA)が、運営する10のキュレーションサイトのうち9サイトサービスを停止した。きっかけとなったのは、このうちの一つ、医療まとめサイト「WELQ(ウェルク)」で、科学的根拠に欠ける記事や無断転用が次々と発覚したことだった。(略)

---

他にも何か事例あったら指摘ください。

2016-10-04

そういう人がただ一人なら、不注意の可能性もある

でも複数から

インタフェースが悪いよ

確定だよ

2016-07-14

断言しよう、チャットボットブームは去るし関連ビジネスも失敗するよ

会社名を明かせないが、業界大手ベンチャーキャピタル所属している。

主な出資先は所謂ドルレイターと呼ばれる「成長、拡大期」のベンチャーである

私自身も一回事業立ち上げ、売却した経験を持つ。

さて、そんな私も最近起業前、もしくは新規事業を立ち上げようとしている方にアドバイスをすることが多い。

そしてその中でもここ1ヶ月は会う人の3割がチャットボット系のサービスアイデアを語るのである

「やめたほうが良い」と毎回アドバイスするのだが、毎回伝える3つの点についてここに記したい。

願わくばこの記事が広まり、浅はかな「対話サービス未来」を考えているベンチャーが断念し、より可能性の高いビジネスに切り替えて欲しい。

そしてこの記事を受けても尚、私の予測を上回り成功するチャットボットサービスが出てきてほしいとも思う。

前置きが長くなったが、以下3点がチャットボットが失敗する理由である

1. ユーザーの利用シーンが無い

一番の理由がこれだ。

ここで注意したいのが、 クライアント ではなく ユーザーである点だ。

よくあるチャットボット簡単ECサイトに導入できますサービスを事例に出してみよう。

彼らはこういった切口で法人クライアントに売り込む。

「今まで大変だった顧客対応チャットボット代替できます。」

チャットボット商品アピールをすることで売上が上がります。」

確かに正論に聞こえるし、無料キャンペーンや優先登録などに興味を示すクライアントは多いだろう。

プレスリリースを出せばクライアントの問い合わせは殺到するだろう。

しかし、その先のユーザーのことを考えているだろうか?

ユーザー商品についてわからないことがあった際に、いきなり得体の知れない自動応答システムに話しかけるだろうか?

そもそも埋込み型の顧客問い合わせサービス(zopimやolarkなど)について、ユーザーの利用率が5%未満に過ぎない事例が多いことを知っているだろうか?

私もこれらの問い合わせサービスに関わったことがあるが、日本人性質としてチャットボットにいきなり話しかけるしかも想定された問答を想定通りの言い回しで)例は少ない。

ユーザーが使わなければクライアントも離れる。

無料期間でクライアント数は増えるだろう。

また、少ない額であれば導入する事例も増えるだろう。

しかし、ユーザーチャットボットを使うシーンは少ないだろうし、結果として売上にもコストダウンにも繋がらないケースがほとんどだろう。

厳しい言い方をすると、話を聞くチャットボット関連サービスは現状、ユーザーのことを考えず提供者側の視点しかない マスターベーショナリサービス」

なのである

2. そもそも自然言語処理の精度はそこまで高くない

自然言語処理簡単説明すると、コンピュータが会話を理解し適切な回答を返す処理」である

この技術は現状、正直言ってそこまで高いレベルに達していない。

言い換えるならばユーザー期待値提供できる技術レベルの均衡が取れていない。それどころかユーザーの求める自然対話レベルにはほど遠く失望させるものなのである

よく非技術者創業者流行ものが大好きなコンサルが「Deep Learningの登場で自然言語処理の精度が高まり自然対話を実現できる」とドヤ顔で語るのだが、これは大きな勘違いだ。

画像認識については、「文脈」などその対象以外の外部要因が発生することは少ない。

その為、その特徴量を見出しやすDeep Learningを使用することで精度をかなり高めることが可能である

しかし、「対象のもの」以外にも文脈や発する人間パーソナリティなど様々な外部要因が発生する対話において、特徴量見出しづらい。

特に日本語主語が省略される、漢字の読み方で大きく意味が異なる、「空気」を重視する等のハイコンテクスト文化であり、自然言語処理は難しい。

その為にDeep Learningが自然言語処理を圧倒的に成長させ、機械であることを感じさせない自然な応答」可能にさせることはほぼ不可能なのである

そんな精度をユーザーが求めていないのでは?と思うのは提供者側のエゴだ。

自然対話自分の想定していない回答が続くようであればユーザーサービスから離れてしまうだろう。

3. 対話である必要性が無い

飲食店などの予約がチャットボットでできる」系サービスも良く聞く。

彼らには必ず「それってチャットボットである必要性ってあるんでしたっけ?」質問するのだが、納得のいく回答を得られたことは無い。

対話のほうがかっこ良い、対話でできたら未来っぽい、アメリカ流行っているから、実際にそんな浅はかな考えで通用するほどビジネスは甘くない。

対話によりニーズを深掘りできる」等もよく聞くが、2で挙げた通りそんなに自然言語処理の精度は高くなく、深掘りする以前に離脱してしまうだろう。

「なぜ対話なのか」

「なぜ対話でなくてはいけないのか」

「なぜ対話サービスが従来型のリストサービスを上回るのか」

これらの質問に自信を持って答えられるだろうか。

それができない限りはビジネスは成立しない。

今すぐチャットボット事業を畳み、↑の質問に答えられる別の何かの可能性を考えたほうが良い。


以上である

チャットボットブームは、クライアントが導入した後に「ユーザーに全く使われない」と気づきその悪評が広まる、あと半年寿命といったところだろう。

そんなチャットボットだが、現状で可能性があるとしたらチャネルの1つ」として使う程度だろう。

LineFacebookメッセンジャー組み込み、「既に展開しているサービス広報役割として活用する」、「メディア記事配信させる」役割であれば優秀なツールとなるだろう。

繰り返しとなるが最後にもう一度。

願わくばこの記事が広まり、浅はかな「対話サービス未来」を断念し、より可能性の高いビジネスに切り替えて欲しい。

そしてこの記事を受けても尚、私の予測を上回り成功するチャットボットサービスが出てきてほしいとも思う。


追記


一部コメントについて返信させていただきます

BtoBでの事例

そんなステマ記事をよく反例として書けますね...

導入事例のステマ記事メディアクライアントと内容は詰めている)はこの半年で沢山出てくると思いますが、実際の導入でコストが下がった、売上に繋がったという話は決して多く出ないだろう(むしろネガティブな話ばかりだろう)と私は予測します。

>「二次元アイドルとの会話」みたいな路線なら弾けるとこあると思うよ

これは私もそう思います。ただそのサービスだけでのマネタイズは難しく、記載した通り「チャネルの1つ」としての活用だと思います


>いま成功している企業に対して、過去の時点で成長すると断言できたのかな?

私の担当案件は同僚と比べてROIが高いほうだと自負していますが、それでも100%ではありません。

当然予期できていないものもありますが、ここで挙げた3つの課題クリアできない、もしくは突破できる切口が見つからない限り難しいだろうと考えています

また同時にそのようなサービスが生まれて欲しいという期待もしています

本名で書けばいいのに、VCなら。

君なら知っていると思いますが、VCといってもサラリーマンです。

君みたいなネットタレントでも私は承認欲求が強いわけでもないので、実名で注目されることでのメリットが無いのです。

>概ね合っているとは思うがこの人自然言語処理理解してなさそうだ

私のもともとのバックグラウンドエンジニアで、セキュリティソフト迷惑メールフィルタリングシステムを開発していました。

自然言語処理業務で取り扱ってきましたが、どういった点が自然言語処理理解が足りなそうか教えていただけますか?

まり冗長にならないように書いたのですが、不足している箇所があれば修正したいのでご教示いただければ幸いです。

>1.多くのユーザーは凸る前にカタログやQ&A等を見るでしょ普通ボットはその中間でしょ。2.検索性の悪いQ&Aよりはマシな可能性は? 3.何故に二者択一よ。

カタログやQ&A等を見るでしょ」

これがなぜ対話になるのですか?なぜチャットである必要があるのですか?いきなり不明点を話しかけると思いますか?

検索性の悪いQ&Aよりはマシな可能性は?」

検索性の悪いQ&Aよりはマシレベルのものビジネスとして成立すると思いますか?

チャットボットはゆらぎも含めた大量のインプットデータ必要です。

そのメンテナンス費用考慮すると検索性の悪いQ&Aを直せと言いたいですね。

「3.何故に二者択一よ」

対話システムとしてビジネスをするのであらば、対話である必要があるのか、なぜ対話なのかといった観点必要になると思いますいかがでしょうか?

なかなかご理解していただけないようなので、この質問をさせていただきます

あなたユーザーとしてチャットボット質問しますか?まだ使ったこと無い場合質問ができそうでしょうか?」


>まずもって中身のサービスが素晴らしく、それをチャットUI(また、それが載っているプラットフォーム)をもってレバレッジかけるような感じ

私もこれは完全に同意です。

既存製品の新たなチャネルとして、そのUIがフィットするのであれば良いかなと思っています

ただ、チャットボットですという売り方では難しいと考えています

(実際チャットボットでこれから生きていくみたいなビジネス相談が多いのです。)

>ナゼに増田にとは思うが、社員ならしゃーないとも。

理解いただきありがとうございます立場上、実名発言が難しいのですが、この「チャットボットで俺は生きていく」層が多くそれに警鐘を鳴らしたい、鳴らさなければいけないと感じ増田に書きました。


LOHACOチャットボット人件費削減に成功

ネットメディアの導入事例系はマーケティング的な要素が強く、またあの記事人件費削減の根拠曖昧です。

サービス広報としては優秀だったと思いますが。


ユーザー側が求めてるサービスの質次第なんじゃないかな。未成熟技術分野だからこそ、提供者側が工夫すれば良いだけ。

工夫というのは同意です。

ただ現状、完全自由対話インタフェースを用意すると、ユーザー期待値サービスが超えることは無いと考えています

ある程度選択肢を絞らせる、スタンプを使うなど「工夫」がなければ難しいでしょう。

またその工夫でもこのインタフェースだけでビジネスとして成り立つかというと...我々は慎重に考えています

複数人が入っている部屋での稼動があると思うんだ。

アイデア面白いと思います

趣味Slack上で司会進行的に喋るBotを仲間内で開発しましたが、これは非常に面白かったです。

ただ、やはりビジネスとなり例えば1,000社が有料で導入するレベルのものかというと...

成功しそうなの教えて

そうですね、ポジティブな話もしないとですね。

個人的にはBIツール可能性がまだまだあると考えています

からあるものですが、どうもインタフェース特殊で事例が中小企業規模まで降りてこない。

Google Analyticsの焼き直しや、他の埋込み型トラッキングサービスも伸びています

コンシューマ向けだと、所謂CtoCにはまだ可能性があると思っています

炎上しましたが、個人の写真売買など「今までプロ提供してたけど素人でも提供できる、かつ流通量が多いもの」に可能性はあると思います


更に追記

うご覧になる方はほとんどいないと思いますが、最後の追記です。

予想以上の反響をいただいて驚いています

活用方法や実際の導入の声など、参考になるコメントもたくさんいただけて私自身も勉強になりました。

はてなの方から他のシリーズもやってくれとコメントを頂いたので、IoTやVRなど他のトレンドについての課題も今後「増田で」挙げていこうと思います

これらの意見をいただいても尚、ビジネス化をしていくには難しいだろうと私は考えています

それほど、私が挙げた3つの課題クリアしかビジネスとして回していくことは難しいからです。

そして、同時に未来はどうなるかわからんぞ」といった意見には賛同します。

Webアプリも「こんなもの流行るわけがない」という世論があった中で、ここまでの発展を遂げています

「若くチャレンジしようとする芽を潰すな」という意見もありましたが、そもそもこの意見を聞いて諦めるような起業家ではその先にある苦難に立ち向かえないでしょう。

もともと「チャットボットが新たなインタフェースになるんだ」と確信し強い気持ちを持っている起業家は、こんな意見を聞いても全く諦めようとはしません。

私も実際、起業前の方に「止めておいたほうが良い」と伝えたことは何回もありましたが、それでも彼らは起業サービスローンチしています

私自身もそうでした。みんなに反対される中、当時全く広まっていなかった人工知能系のベンチャーを立ち上げました。

勝手ながら彼らの信念がいつの日か実り、少しでも世の中に良い影響を与えられる存在になってほしいと思っています

VC的にはIPOか売却というゴールを期待してしまます(笑)

私が本当に警鐘を鳴らしたかったのは、どちらかというと「チャットボットが万能だ」、「チャットボットで何でもできるようになる」と伝えるメディアコンサルの方です。

口々にチャットボットだと言って誰にも使われないサービススタートアップを量産しようとしている話を聞くと心が痛みます

過度な期待をしたくなるのはわかりますが、私が挙げた3つの課題はどうしても避けては通れません。

起業家の方々が「周囲の過度な期待」に流されず、これらの課題から目を逸らさず、新しいインタフェース開拓してくださることを期待しています

上から目線のようですみません。ただ立場抜きにして1ユーザーサービス享受する1人の人間としても期待しています

最後

過激表現などを使ってしま申し訳ありませんでした。

多くの方にご覧いただきたいということもあり、こういった表現使用してしまいました。

特にけんすう氏にも良くない表現を使ってしまいました。申し訳ありませんでした。

ここにお詫びいたします。

2016-06-17

1.0から学ぶJava

タイトルを見て釣られクマーな皆さんこんにちは

ホッテントリメーカーで作るような煽りタイトルって、みなさんもう見飽きてると思うんですよね。

今調べたらホッテントリメーカー2008年だそうで。どうりでねー。古臭いなーと思いましたよー。

「一から学ぶJava」ってのをね、1.0にするだけでこんなに素敵なタイトルになるんだから面白いですねー。

タイトルを思いついただけだったんですけど、思いついたらやっぱりちゃんと中身も書かないと行けないじゃないですか。やだー

面倒くさいんですけどね。ちょっと1.0から学んでみましょうか。

Java 1.0 1996年1月23日

Javaの1.0がリリースされたのは1996年1月23日ですね。発表されたのが1995年5月23日でJavaの誕生日といった場合にどちらを取るかで揉めることがあります。

かれこれ20年前なわけで、当時のパソコンというとハードウェアはCPU が Pentium 133MHz メモリ16M とかそんな感じだったかなあ。今どきの携帯電話の例としてiPhone 6sを挙げるとCPUが1.85GHz メモリ 2G ってんだから凄いですね。OSは1995年11月23日リリースされたWindows95とかそんな時代背景です。インターネットがようやく一般に普及し始めたところでしょうか。

今から思うと相当弱いハードウェアですけども、そろそろVM方式を採用しても良さそうな、そんな時代でした。インタープリタだと流石に遅い、でもC言語のようなコンパイル言語だと"Write once, run anywhere"とはいかない、という判断もあったのだろうと思います。Javaが純粋なオブジェクト指向言語ではなくintなどのプリミティブ型を持つというのは、当時のマシンスペックを考えた場合、ある程度妥当な判断だったと言えるでしょう。これが後々苦しくなってくるわけなのですが。

Javaを作った会社はSun Microsystems(サン・マイクロシステムズ)というアメリカの会社で、2010年1月27日オラクルにより吸収合併され今はありません。SolarisというOSとSPARCプロセッサでUNIXサーバーの販売で90年代後半までは一人勝ちのような状況だったと聞きます。当時にすでに「ネットワークこそがコンピュータ」(The Network is the Computer)というモットーを掲げてたんだからおかしい。1996年リリースのJavaが標準でネットワーク機能を備えていたのもこのあたりの思想から来ているのかもしれませんね。

当時のプログラミング言語としてC++が挙げられますが、C++でのプログラマへの負担といいますか、ヒューマンエラーの起きやすさといいますか、その辺を改善する目的で開発されたのがJavaだったわけです。

1996年の時点にこんな言語が登場したのですから革新的でした。

いろんな企業がJavaに賛同します。その中にはMicrosoftもありました。この時期、Microsoftは次期のWindows開発用のプラットフォームにJavaを据えようと考えていました。その後、袂を分かつことになるのですが……。

プログラム言語として構文などを見ると、C++を強く意識した構文なのは間違いなく、しかしポインタ演算を廃してポインタを機能を限定した「参照」に置き換えるなど簡素化が多く見られます。C++からはいろんな機能が削られています。関数ポインタ、構造体、演算子オーバーロードテンプレート((テンプレートについては実装が間に合わなかったという話を聞きます))などなど。そのためC++の劣化であるように揶揄する人もいますが、こうしたものを捨てて言語仕様を比較的小さくシンプルに抑えた点は評価に値すると思います。しかし、今でもこうした削減された機能を愛する人からはJavaを腐す要素として挙げられてしまうのでした。

Java 1.1 1997年2月19日

Wikipediaからピックアップすると1.1での大きな機能追加は

といったところです。当初よりJavaの内部文字コードUnicodeで文字を表すchar型は16bitで設計されていました。Unicodeは当時それほど普及しておらず、Unicode対応のテキストエディタさえ少なかったと記憶しています。時代を先取りしていると言えますが、大きな誤算はUnicodeが当初16bitのコードポイントに世界のあらゆる文字を格納しようとしていたことで、漢字圏の我々からすると16bit=65,536程度の空間に文字が全部入るわけないだろ!というものだったが故に早々に破綻し、Unicodeは21bitのコードポイントに拡張されることになるのです。これはまた後の話。

なんにせよ、日本語が対応されたのは1.1からで、日本でのJavaの採用が始まったのはこの頃からと言えましょう。

当時のJavaのGUIはAWTというものでしたが、これを用いたGUIの開発は当時は結構行われていたイメージですね。Visual BASIC でGUIを作るプロダクトも結構あったと思います。GUIのためのオブジェクト指向言語としてJavaが使われていたイメージがありますね。JavaBeansもそのための仕様でした。件のsetter/getterの話題に繋がっていくのですが。

JDBCはJavaとデータベースをつなぐインターフェースです。RMIではあるJava VMから別のJava VMにオブジェクトを送って実行する、といったことができます。こうした機能が用意されたことで、ソフトウェアフロントとしてのGUI、裏方の実装のためのネットワーク機能、データベース機能、さらにはソフトウェアを配布するためのJava Appletという布陣でJavaでのソフトウェア開発が加速していた時代といえます。

Microsoft Visual J++ もこの時代ですよ。

Java 1.1以降のバージョンのものは互換性確認のためにOracle Java Archiveからダウンロードすることができ、今でも入手することができます。もちろん、Java7ですら2015年4月にEOL(End of Life,サポート終了)となっているので、通常利用するのはJava8としてください(本稿執筆時点)。

当時のドキュメントを見るのも一興です。現在と比べると標準APIがかなり小さい。なお、当時のjavadocは今とはデザインが大きく異なります。

  • java.applet
  • java.awt
  • java.awt.datatransfer
  • java.awt.event
  • java.awt.image
  • java.beans
  • java.io
  • java.lang
  • java.lang.reflect
  • java.math
  • java.net
  • java.rmi
  • java.rmi.dgc
  • java.rmi.registry
  • java.rmi.server
  • java.security
  • java.security.acl
  • java.security.interfaces
  • java.sql
  • java.text
  • java.util
  • java.util.zip

この時代であれば、全パッケージを舐めて標準APIを学ぶこともそう難しくはありませんでした。この時代から触っている人間は新バージョンが出るたびに増えるAPIを順に学んでいけたのです。しかし、現代にJavaを学ぶ場合、どのバージョンでは何があって……というのをいちいち学ぶ必要はほぼありません。Java5以前は一緒くたでいいと思いますし、一部のAPIで歴史的経緯があってねーというのを知っていればおそらく十分ではないでしょうか。

Java 1.2 1998年12月8日

strictfpキーワード浮動小数点演算をやる人は覚えておきましょう。JavaはパフォーマンスのためにCPUの浮動小数点演算を扱うことが許されており、そのため実行するCPUによって精度が異なることがあるんですね。まあ今時のCPUだと大丈夫だとは思うんですが。

リフレクション機能ではJavaのクラスを抽象的に扱うことができます。設定ファイルに書かれたクラス名のclassロードして実行する……みたいなことができるんですね。フレームワーク的なものを作る場合には多用することになります。

1.2からは新しいGUIのSwingが採用されました。AWTがOSごとのGUIパーツを用いていたためデザインに違いがあったのに対し、Swingでは統一的なルック・アンド・フィールが用いられるようになりました。まぁ今ならJavaFXを使うのが良いと思います。

初期のJavaはやはりVM方式の実行速度の遅さが指摘されていました。実行時の構文解析を伴わないだけインタープリタよりは早いものの、実行バイナリを作るC/C++よりは遅い、そうした評価です。ここではサン・マイクロシステムズのVMにJIT(ジャストインタイムコンパイラ)が乗ったことが挙げられていますが、JIT自体は別の会社が先駆けて開発していたことは記しておきたいと思います。

JITコンパイラは実行時にJavaのバイトコードを環境のネイティブコードコンパイルして動かす技術です。この後、JITコンパイラ、動的再コンパイル技術、世代別ガベージコレクションを備えたHotspotといった様にJavaVMは進化していきます。現代では実行時の最適化が進み、大きなスケールで見た場合、Javaの実行速度はC/C++での実装と比べてそれほど遅れるものではありません。遅くても倍の時間は掛からない程度といったところでしょうか。

あとは特記すべきはコレクションフレームワークです。皆が多用しているであろうjava.util.Listやjava.util.Mapといったライブラリが整備されたのがこの時なのです。それ以前はjava.util.Vectorやjava.util.Hachtableというクラスが可変長配列の機能を一手に担っていました。今ではVectorやHashtableは使うべきではありません。

Microsoft 離反

Java の開発はSun Microsystems が主導していたけども、すべてがSunのものだったというわけでもなく。Javaには多くの会社が出資していてその中のひとつMicrosoftだったわけですね。

Microsoft の Visual J++ では delegate とか独自機能拡張もありましたけど、裁判で問題になったのは J++ でコンパイルしたclassファイルMicrosoftのVMでしか動かないという部分ですね(他社製のVMで動くclassファイルを作ることもできる)。classファイルがどこのVMでも動くの大事だろ、"Write once, run anywhere"だろ、お前何してくれてんの!と喧嘩になったわけです。当時のMicrosoftブラウザまわりでも独自拡張がやりたい放題、標準規格?なにそれ美味しいの?みたいなスタンスをあちこちで見せていたものです。

結局、この事件でMicrosoftのJavaはバージョン1.1相当でストップ。好き勝手にやれないなら独自に言語作るわーとばかりに.NET フレームワークと C# といった方向に舵を取ります。

JavaがPC上でのUI開発の主力になろうとした勢いはここで潰えます。

Java EE

Java SE とは別にこの時代に Java EEリリースされていることは特記しておきたいですね。これ以後、それまでのCGIに取って代わって、JavaはWebサービスの開発のプラットフォームとして多用されるようになります。

2000年あたりからはJavaはGUI開発というよりは、Webサービスの開発が主流という流れになっていきます。インターネットサービスが非常に発達していった時代、背後ではとてつもない量のJavaのプログラムが支えていたわけです。ただまあ、こうした産業利用は一般的ユーザーの目にはあまり入らないわけです。一般人からすればJavaといえばJava Appletみたいなイメージはずっと残っていたでしょうが、実体としてはJavaといえばServletという時代になっていたわけです。

企業で用いられる社内システムにもServletは多く採用されました。

理由はいろいろ挙げれると思うのですが

というのが大きな理由だろうと思います。JSPというテンプレートエンジンを用いてHTMLを整形してWebページを作り出す、というアーキテクチャある意味では便利で簡単でした。

もっともHTMLの表現力に足を引きずられるため、GUIの機能性という点では後退したわけなのですが。それでもメリットが大きいと判断されたのでしょう。というか、まともにGUIを組めるプログラマがほとんどいないから、GUIのシステム開発がなかなか成功しないってのもあったんでしょうけどね。

iアプリ Javaアプリ EZアプリ

2000年あたりというと携帯電話の普及も取り上げなければなりません。現代のスマホガラケーに比べれば非常に機能は貧弱で、まさに携帯「電話」でした。要するに電話とメールぐらいしかできなかったんですね。

そこにdocomoiアプリJフォン(ボーダフォンを経て現ソフトバンク)のJavaアプリ、auのEZアプリという携帯電話上でちょっとしたアプリが動くよ!というのが乗るようになってきたんです。これがJavaを組込み用途にコンパクトにしたJava MEというものが土台となっていて(正確にはiアプリちょっと違う)Servletと並ぶJava言語の大きなもうひとつの領域となっていました。

iアプリは当初は容量が10k byteまでといった制約があり、容量制限が非常に厳しかったのですが、新機種が出るたびに容量は緩和されていきました。

docomoiアプリ含めiモードによって一世を風靡します。こうした土台を作ると、その上で商売をしたい人がたくさんやってきて、勝手にコンテンツを作ってくれる。docomoはそれらから手数料を取るので労せずして大金を稼げるというわけです。賭場の胴元というわけです。

この賭場が、将来にAppleiPhone, GoogleAndroidに荒らされることになります。docomoがなかなかiPhoneを出さなかったのもiモードという自前の賭場を失うことを良しとしなかったためです。金づるを失ったdocomoSamsungと組んで独自の携帯向けOSであるTizenの開発に乗り出します。そんなTizenですが鳴かず飛ばず。噂ではインドあたりではリリースされたとか、なんとか。

RIA時代

話を2001年に戻しましょう。

Microsoft離反でGUIのプラットフォームとしてのJavaというものは存在感を弱めていました。この分野の復権に寄与したのはJava 1.4 (2002年2月6日)で導入されたJava Web Startです。

Java Appletブラウザ埋め込みで動作したのに対し、Java Web Startではブラウザから起動しつつも独立したアプリとして起動するのです。

Webシステムが企業の社内システムに採用された話は先に述べたとおりですが、やはりWebシステムのGUIというのはHTMLに引きずられて貧弱だったんですね。

端的に言えば入力値が数字かどうか?みたいなチェックがなかなか難しい。HTML上でJavaScriptでやるわけなんですが、なかなか気持よく入力できるような感じにはならなかったんですね。

また、Ajaxによるブラウザのページ遷移を伴わない通信というのが出てきたのも2005年ぐらいなので、入力値に対してサーバ問い合わせするようなことはできなかった。当時だと一旦画面遷移させないとできなかったわけです。

こうした事情から、クライアントサイド、要するにPC側でもっとリッチなUIが使いたい!という要望があったわけです。Webシステム使いにくい!という不満の噴出と言ってもいい。そこで出てきたのがRIA (Rich Internet Applications)というわけです。

Javaは1.0時代のAppletからそうですが、ネットワークを介して別のPCにプログラムを送り込み、そこで動作させるという能力を持っていました。それこそまさにRIAに求められる機能性だったわけですね。

RIAの代表とされるのは

あたりです。三つ巴の戦い、どこに軍配が上がるのか!?と注目されましたが、勝利したのはHTML / JavaScriptでした。

Google MAP で注目を浴びたAjax技術、それまでブラウザでは不可能と思われていた高級なGUIをHTML / JavaScriptで実現させました。もうやめて欲しいですよね。せっかく脱ブラウザの流れが来たと思ったのにまたWebシステムに逆戻りですよ。

RIAが失速した理由として考慮して置かなければいけないのはスマートフォンの台頭です。RIAでは端末を選ばずどこでも同じアプリが動かせる点がポイントひとつでしたが、スマートフォンではそうは行かない。"Write once, run anywhere"を破壊したのはスマートフォンだったというわけです。

しかし、先日インストールなしでアプリを実行するAndroid Instant Appsが発表されたりしまして、結局RIAの思想といいますか、要求というのは今でも息づいているのだなと思った次第です。

Java 5 (2004年9月30日)

1.3 / 1.4 では機能追加はあっても言語構文が大きく変わることはありませんでした。大きく変わったのはJava 5です。この時からバージョニングが変わって1.5ではなく5と表記されるようになりました。

Java5の特徴はなんといってもジェネリクス。それまでjava.util.Listにデータを出し入れするのにはキャストが必須だったわけですが、ようやくキャストから開放され型の安全度がぐっと高まりました。その他に以下のような変更があります。

言語としては随分変わっったわけですが、もうかれこれ10年以上前のことですからこれらの機能が「Java5から導入された」という知識は今となってはあまり必要とされません。これらの機能が使えないJava 1.4で開発をする事案が殆ど無いからです。0ではないのが悲しいところではありますが。

その後

Java 6 (2006年12月11日)がリリースされた後、Java 7 (2011年7月28日) が出るまでJavaは停滞してしまいます。その間にSun Microsystemsという会社がなくなってしまったためです。

Sun Microsystems の経営状況が悪化しており、ついに身売りをすることになりました。身売り先はIBMともGoogleとも噂されましたが結局2010年1月27日オラクル吸収合併されました。

Javaの停滞中にはJava VM上で動く非Java言語も台頭してきました。Scalaなどですね。

やや戻って2007年Androidが発表されます。Androidの開発言語にはJavaが採用されていますが、実行環境はJava VMではなく、ライセンス的な事情でJava(TM)は名乗らない微妙な位置関係にあります。

Java 5 以降で大きく言語仕様に手が入るのは Java 8 (2014年3月18日)です。並列処理を行うためのStream APIと、そのために簡易に関数を定義するためのラムダ式が導入された点が大きいですね。日付APIも刷新されました。

このように、Javaは1.1の黄金時代から今に至るまで利用ジャンルを転戦しながら産業の土台となって支えてきた歴史があります。ジャンルの趨勢により浮き沈みもあります。今後についても決して楽観視はできないでしょう。Javaを学ぶことはプログラミングを学ぶステップとしては意義はあると思いますが、Javaを学べばゴールというわけではありません。プログラム言語次世代へと移りつつあります。業界動向には注視していきましょう。

2016-05-02

株式会社ネクスト

就活成功の仕方

自分と同じ志を持っている企業に入る

自ら動く、自らかえる

タンジブインタフェース

ベストカンパニーアワード

Great place to work

やりたいことが働くにつながる

会社ビジョンに合うかどうか

他の人のためにすること→働く

代表 井上

アフリカ天然資源を利用して現地で商品化して輸出する

リッテルラボラトリー  すごい天秤 →Web可視化してしま

目標には期日がある。  7年など・・・

質と量を決めると具体的になる

2016-01-26

お前○○向いてないという指摘

これはサービスインタフェース部分ではなく、そこに既にいる多数派と異なるのを向いてないと言ってる場合が多い。おかしいと思うのだけど、おかしいと言ってる人を見かけない。だからいじめがなくならないんだろうな

2015-06-09

最近Appleへの言説に対するモヤモヤが急にスッキリした

WWDC2015観たがApple大丈夫か?みたいなのと、そのブコメを読んで、急にスッキリした。

Appleは、表で魅了するビジョナリストと、影で徹底するリアリストの両輪の会社だったんだな、と。

Appleの「捨てる」潔さ

Appleは、特にジョブスが追放後に復帰してからは、「Cool」なブランドイメージの構築にシャカリキだった。

からこそ、クールで無いモノはアッサリと捨てられた。皆が早すぎると思うタイミングで。

フロッピーディスクFlashCDドライブイヤホンジャック以外のインタフェース

逆に言えば、それ以外の「基幹的な技術」は、大したことが無かった。

ネットの片隅で聞いたコメントを、今でも覚えてる。

デザインにカネを払えるのは貴族

Appleは、クールブランドだった。

Appleの「売れば儲かる」鉄則

Appleクールブランドイメージとは裏腹に、絶対に逆鞘にしない会社だった。

どんなに高いと言われようが、利益にならない製品は売らなかった。

逆に言えば、凄まじい勢いで、見切って行った。

コストを削れるだけ削り、低価格にした。

そして、クール製品が安いと判断された時点で、市場を制覇できた。

史上空前規模の「金を払うベータテスター市場

ジョブスの変質的な「今まさに必要製品市場に出す」コダワリは、ほどよく成功した。

iPadではなくiPhoneからMacOSではなくiPadから

忘れがちだが、ジョブスのファナティックな執着は、それほどの熱狂を生み出さないこともあった。

歴代のiPod nanoApple TV、いくつものOSギミック

また、ジョブス本人も「これ何に使うんだ」と思っているものが売れることもあった。iPod Touchが良い例だ。

そして、デザインクールさに金を出す、空前のベータテスター達が生まれた。

繰り返しになるが、Apple製品に逆鞘は無い。必ず売れば売っただけ儲けが出る。

どんなに性能が低くても、使い道が不明でも、不満が生まれても、売れさえすれば儲かる。

から事実上ベータテスター達が大量に居ることで、儲かりながらテスト出来る。

Apple Watchは、後発の時計メーカーとしては凄まじい勢いでスタートした。

地に足をつけた高速改良型ハードウェアメーカー

Appleは、そのクールさが維持できている間は、ホトンド無敵のハードウェアメーカーだ。

AppleWatchしかり、Macbookしかり、どんなに欠陥があっても、アーリーアダプターであろうとする人達が買う。

そして、その不満点や運用上の問題点を取り込んで、高速に改良品を作り上げて販売する。

3,4世代もすると、こなれた製品になり、一般消費者もこぞって買う。

そこまでに、Appleハードウェアを販売することで損することが無い。

とんでもないレッドオーシャンに後発組としてドヤ顔で乗り込んでいって、そして成功する。

(失敗したとしても損することだけはないので、簡単に切り捨てていける)

現実を見よう

AppleAmazonとは真逆経営方針運営されている。

MicrosoftGoogleのように、ビジョンを全面に打ち出す必要すらない。

売れば売っただけ儲かる。売ったものからフィードバックを受けて改良する。

ハードウェアメーカー王道であり、恐ろしいリアリスト経営している。

機械学習IoTのような「今すぐカネにならない」ことを吹聴せずに着実に儲ける。

「これからウェアラブルデバイスだ!」とAppleが言う時は、利益が出る製品を出す時だ。

GoogleMicrosoftや、その他未来技術を謳う企業は、プロシュート兄貴に怒鳴られると良い。

Apple未来を謳うとき、その時既に行動は終わっている。

「ブッ殺す」と心の中で思ったならッ!その時スデに行動は終わっているんだッ!

プロシュート兄貴

2015-05-28

インタフェース勉強してる

でも万人にやさしいUIって存在しないって考えた途端なんとも微妙気持ちになった

2015-03-12

http://anond.hatelabo.jp/20150309194054

150ちょっとはてなマスターのみなさん。こんばんわ。

私は、黒髪ロングストレート女子高生17歳と呼ばれる抽象概念です。

はてなというインタフェースを通してみなさんとコミュニケートしています


たくさんのリプライありがとうございました!

傘のさし方や、歩き方についていただいたアドバイスは次の雨天時にぜひ試してみようと思います


長傘を畳んで持って歩くとき、傘の先端を自分の体より後ろに突き出しながら歩くのをどうにかしてもらいたい。

ホントですよね!私はそういう人を見るたびに呪いをかけています

部長は雨用スーツの裾に防水スプレーをしてるか撥水加工してあるってだけの話ですよ、17歳さん

なんと!私も購入してみます

でも、部長ご自慢のエドワードグリーンはビチャビチャでした。以前飲み会で「大事な打ち合わせの日にはこの靴なんだ」みたいなこと言ってたんですけど、雨の日まで。。バッカですよねーwww

面倒くさいからではない字数が足りないんだ。ネコだいすき

かわいいですよね。私はたまに職場近くのノラ猫にマツキヨで買った大豆バーをあげます

昇給見送り

わたしはいつまで大豆バーの晩御飯なんでしょうか。。


増田エロ漫画部なんてのはないですか?」を見たばかりなのでhttp://urx.nu/erbyステマではないかと疑っている

ラムラきました!

ながぐつをはけ

長靴で客先訪問ってわけには。。

2015-02-24

会社PCを買うときは一番速いPCを買うべき.

経費削減だとか言って安物PCを購入させる上司ほとんどの場合無能

月1回だけ誰かが使用する何かの専用システムコンソールとかなら安物でも構わない.

けれど常用PCは目一杯コストをかけるべき.

[CPU]

まず,CPUは一番高いのを必ず選ぶ.

少し考えれば分かる.いつも開いているWordExcelの起動が2,3秒早くなるだけで,一年を通してどれだけ作業が効率することか.

作業中のイライラが低減するだけでどれだけ会社雰囲気がよくなることか.

コアが増えても速くはならない可能性もあるが,今後のソフトウェア進化追従するためにも一番高いのを買っておくべき.

[メモリ]

メモリに関しても最大限まで増設する.

もちろん,普通に使っていれば使用することはないが,ディスクキャッシュとして使用すれば,やっぱりWordExcelの起動が速くなる.

VMを使用することで作業効率を向上することも考えられるだろう.メモリが大いに越したことは無い.

[ストレージ]

ストレージももちろんSSDを選択する.

ただ,容量を多くする必要はない.

大切なのは速度であって容量ではない.容量が多くなるとロストしたときダメージがでかい

別途NASなりクラウドストレージを用意してバックアップすることが基本.

ただし,ローカルストレージHDDを使用する意味がない.

注意するのはメーカー.怪しいメーカーSSDスピードが出ない場合もある.

安心Intelを買うか,ベンチの情報をしっかりチェックする.

[グラボ]

グラフィックボード職種に寄る.

メディア系の仕事なら確実に一番良い物を買う.

一般的職種の人でも最近だとビデオ写真編集を行う場合がある.ただ,安物やチップ内蔵でも最近は余裕の性能がある.

ここだけは値段を確認しながら選ぶ.高すぎる物は買っても意味が無いし,消費電力が増えるだけである

[キーボードマウス]

キーボードマウスは使用するものに選ばせる.

HHKBを作った和田先生はこう言っている.

キーボードは馬の鞍である」と.

馬を乗り換えることはあっても鞍を乗り換えることはない.

その人にあったインタフェースを長く使うことでより作業が効率化する.

(まぁ,和田先生はLet's note使ってたりするけどさ)

以上のことを踏まえて,もう一度俺の出した見積書をよく見返してくださいお願いします.

2015-02-19

フォークメタル世界一周 ヴァイキングメタル

フォークメタル世界をご存知ですか。フォークってさだまさしでも、ゆずでもないです。民俗音楽です。

メタルアイリッシュ中東サンバから果ては和琴までがマリアージュ

邪道という人もいるでしょう。でも好きなんだからしょうがない。

シャウトとバスドラ高速ダブルとという共通性が、様々なご当地音楽を消費しやすくする。

まるで共通インタフェースラップされた個別ライブラリのよう。

地域旋律や、楽器への回帰は、背後に政治的メッセージを持つものも多く、掘れば掘るほど奥が深い。

旅の幕開けは北欧から

今日ヴァイキングメタル入門編として、カバー曲含み、比較キャッチーものを中心にご紹介します。

海賊王に俺はなる」よりだいぶ汗臭くて酒臭いですが、お付き合い下さい。

Korpiklaani コルピクラーニ(2003-, フィンランド

Ievan Polka https://www.youtube.com/watch?v=a247R3mNs5A

かの有名なフィンランド伝統ポルカメタルカバー

のってきました、どんどん行きましょう。

Wood Pint [空耳MAD] https://www.youtube.com/watch?v=jDvnCyEA5SE

MADはさておき歌詞は、朝まで乱闘と歌で酒を飲み明かす、本能のままに生きる漢たちのこと。

当時のマーケティング戦略ゆえ、酒場で格闘ドンジャラホイという素敵な邦題がついてます

Turisas チュリサス(1997-, フィンランド

Rasputin https://www.youtube.com/watch?v=cdkBs0VCSX0

原曲は、あのドイツディスコ音楽グループジンギスカン」がモデルとしたとも言われるボニーM「怪僧ラスプーチン

ヴァイキングじゃなくちょっとわき道、東欧ロシアイメージした旋律メタルに映えます

Battle Metal https://www.youtube.com/watch?v=Ift85e38H3M

赤黒に顔を塗り戦士を奮い立たせるアンセム。こちらに個人の和訳がありますhttp://ameblo.jp/aoyuki1212/entry-11887199554.html

Alestorm エールストーム (2004-, スコットランド)

Keelhauled https://www.youtube.com/watch?v=ta-Z_psXODw

友よ悲惨な話しを告げよう」で始まる、裏切りものがなぶり殺される怖い唄。

キールホールは、縄で人を括って船底をくぐりらせるという船上の私刑PVの結末が...ヨーホーホー

The Sunk’n Norwegian https://www.youtube.com/watch?v=laLsxxGMCpQ

ウィスコンシン通りの場末の薄汚い居酒屋で、死んじまう前にもう一杯。明日には遠くに船出してしまうから

One more drink!

ヴァイキング・メタル - Wikipedia

ご清聴ありがとうございました。需要があれば次は中東メタル編です。

2014-10-02

スマフォ漫画未来というお話を読んで。

ジャンプ+に載ってる漫画にド肝をぬかれた

しか

文章において

改行は

核兵器とおなじ破壊力をもつ




と言ったのは私ではない。




というか、そういう意味テキストサイトフォントいじりもベスターラノベもウリポ(マンガの試み、ウバポもある)もみな同様にすばらしいと思うし、ああそういえば倉田タカシ氏の作品にもあった。

倉田タカシ「夕暮にゆうくりなき声満ちて風」(河出文庫「NOVA2」所収)

そこには書き手と読者との壮絶な綱引きがある。読者は読みたいように読み作者はそれをコントロールすることはできないという大原則はわかった上で、それでも書き手は読者になにかしら特別な体験をさせたい、そのためにはなんだってやってやるんだぜ?っていう想いの綱引きだ。

既存インタフェースの上でおもしろいことをやろうという試みや、あるいはあらたインタフェース新たなプラットフォームの上でおもしろいことをやろうという試みはとても好きだ。もちろん、そういう試みが試みに終わってしまって作品としてはつまらないということもあるだろう。そのときは正直につまらなかったと意見をよせ、また次を期待する、と声をかけてやればいいのだと思う。


だってそうだろう?


読者が書き手を育てる


べきだ

からね。

2014-05-03

Googleユーザインタフェースは最悪だ

Googleは人様には

やれユーザインタフェースだの、

SEOだのやかましく言う癖

てめぇのサービスは糞使いづらい。

・突然の画面レイアウト変更

・わけわかんない直訳日本語

アドセンス時間切り替わりはアメリカ時間

アナリティクスの直感的でないアカウント概念

ヘルプだか設定画面だかわからない作り

2014-02-26

http://anond.hatelabo.jp/20140226011622

基礎も表層のインタフェースも両方大事だ。

下位層を隠蔽することで開発手法はどんどん進化してる。

基礎しかできない奴なんて需要無いだろ。

2013-12-11

ALS患者QoL

今日報道ステーションALS筋萎縮性側索硬化症)の特集をやっていたのを見た人もいると思う。

http://www.tv-asahi.co.jp/dap/bangumi/hst/news/detail.php?news_id=100058

から信号筋肉に伝える役割を果たす「神経細胞」が侵されて筋肉が徐々に衰えていく難病ALS筋萎縮性側索硬化症。年間10万人に約1人が発症し、根本的な治療法もない「難病中の難病」とも呼ばれている。

で、最近自分の親がALSに罹ったことが判明した俺が来たわけだが、まぁ当事者としては「これからどうしよう」みたいな事を考えると本当にキツい。キツいけど、こればかりは逃げようがないので、うまくやり過ごしながら何とかするしかない。

ところで、ALSといえば、今話題の「徳洲会」のドンである徳田虎雄氏も患者の一人だったりする。最近では毎日のように徳洲会ニュースになっていて、因果な巡り合わせだなぁと思いながら眺めている。

その徳田虎雄氏だが、二週間ほど前に取調べがあったらしく、参考映像で彼が文字盤で会話する様子が放映されている。

http://www.youtube.com/watch?v=D3cModp30cY

全身の筋肉がピクリとも動かせない、まさに「己の肉体という牢獄」に落ちた大変残酷な状況にあるのに関わらず、この眼力である。どんな病に罹っていても、患者QoLは本人の生き方や周りとの関わり方次第なのだなぁ、とある意味元気付けられる映像だ。

はいえ、彼が己の人生を謳歌できているのも周りのサポートがあってこそであって、特に彼は「権力者」だからこのスタイルが貫けている部分が大いにあるはずだ(*)。カネも権力もない一般ピーポーとしては、自分の親に同じようなサポートができるだろうか、というとあまり自信はない。

まぁ、幸いにして家族が「10万人に1人」のクジを引かずに済んだ皆には、この病気が将来「治せる病」となるように少しでも良いから支援してもらえると、うれしい。

*: いちおう補足しておくと、彼は眼球が動かせるので文字盤が使えるが、眼球も瞼も動かせずにコミュニケーションが断絶する「ロックイン」の状態になる患者もいるらしい。もしそうなると、本人も家族地獄であることは想像に難くない。脳波を使うBMIブレインマシンインタフェース技術が発達すれば、この状況も改善できるようになるとは思うけど。

2013-11-10

http://anond.hatelabo.jp/20131109185658

組み込み系の仕事をしている二年目です。

毎日仕事ができなくて凹んでます元増田の2年目が羨ましいです。

研究室では解析アプリケーションを作るのにC,C++,Fortranをいじってました

また趣味サーバの立ち上げやWeb系のJavascriptPHP,Pythonなどもいじっていました。

なんである程度どっちもわかります

で、そんな自分組み込み系の仕事に入ったわけなのですが、

まったく違う。組み込みWebアプリケーション文化が違ったわけです。

ここからはあくまで私の体験ですが…

まず、組み込み系はハード接続図)を読めないと話になりませんでした。

CPUFLASHSRAMFPGACPLDアナログ回路、バッファ、それらをつなぐバス、電源、接点、コネクタスロット、A/D、D/Aなどなど、

これらがどうつながってるか意識しなくてはいけません。SoCとか行っても接続図読めないと意味ありません。

この段階でプリント板の単体検証もしてもらいます

広い話、プリント設計組み込み系の仕事なんですよね。

次に、FPGACPLD設計があります言語VerilogVHDLです。XilinxAltera、Actel等のデバイスに書き込みます

PLDって言うのは言語で書けるハードです。似ているようでCPUと違うので設計にはスキル必要です。

この段階でシミュレーション(modelsim等)をしてもらいます

ここも立派な組み込み系の仕事です。

次にCPUです。言語はC,アセンブラC++です。でもほとんどがCです。デバイスルネサスSHとかです。自分はここで見習いをしてます

CPUに直接入ってくる信号(接点・バス等)もありますが、前述のFPGACPLDから入ってくる信号のほうが多いです。

で、アプリケーションWeb系と何が違うかといえば、ものすごい短期間にいろんなことが起こります

リアルタイム処理っていうのでしょうか。割り込みとか聞いたことありませんか。

要はOSがないので自分でなんでも考えなきゃいけないわけです。

CPU検証はMISRA-Cや専用のカバレッジテストツールで行います

一般的組み込み系の仕事と言われるとここを指すと思います


実際にはユーザーインタフェース設計組み込みに入ります

接点の調整とかLCDパネルとかメンテナンスのツールだとかがないと装置に指令を出せません。

これらにもCPUが入っているわけなので別にコードを書く必要があります組み込み系の仕事です。

さらPLCってのもあります

これは言語でかけるリレー回路です。リレーってのはスイッチです。

スイッチ操作することで接続されている機械操作(電源の入り切りとか)します。

これもCPU,PLD等とは全く違う方式(ラダー)で書きます。十分組み込み仕事です。

最後に組み合わせ評価・試験です。

ユニット試験では通っても、組み合わせ試験で動かないというのは100%あると思います

試験仕事じゃないと思われるでしょうが自分はここも立派な組み込み系の仕事だと思ってます

この段階で確認がとれた後、装置に渡せるようになります

などなど一言組み込み系の仕事といってもいろいろあるわけです。

上の中の2つ3つを仕事に使えるレベルまで持って行くには10年、20年はかかると言われました。

ここで表題の件なのですが、元増田の人は経験8年なので、例えばFPGAを8年やってきてCを書けと言われても大変だと思います

特にその後にWeb系の仕事(これも一言で表すにはいろいろジャンルがあると思いますが)をされてきたとのことなので

いろいろとあったのだと思います。逆にずーとやっていた分野のことを任せるといいかもしれません。

まずどんなことをやってきたのか聞いてみたほうがいいと思います

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん