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

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

2019-08-24

anond:20190824022241

Pythonはただのインタフェースだろ。そんなに文句あるならnative extensionかけや

2019-08-04

anond:20190804221343

コメントどもです〜

もーーー年指定全然うまく動いてないのね。なんか違うインタフェース考えます。。。

キーボード操作できるのは朗報ありがとうございます

2019-05-24

パラリンピックとe-スポーツ

障害者のためのスポーツというけれど、実質的に主に足に不自由がある人のオリンピックになってね?

走る系のスポーツ義足選手ばかりだし、球技系は両手使えない選手見ないし(つまり足が不自由選手ばかり)、水泳系も手が使えない選手をあまり見ない。

ルール理解できない知的障害者も多分いないし、精神障害者蚊帳の外

なんつーかe-スポーツってパラリンピックへの応用のしがいがあると思うんだよね。

様々な障害を持つ人のためにユーザインタフェースを工夫しまくってできるだけ沢山の障害者選手にできればいい。インタフェースの差が実力差になってしまうのなら、そこは技術の発展のチャンスだし、e-スポーツルール外のことはできないか知的障害者参入障壁も低い。

そう思うんだけど、みんなどう思うよ?

2019-05-05

令和も終わってしまった

つのまにか令和も終わってしまった。

結局、そこまで大した進歩はなかった、と言うのか、もはや周りが変わっていくことにもう慣れきってしまったのかも。

インタフェースが出てきてから大きく変わったような気もするし、結局変わっていないような気もする。

朝になれば子供学校に行くし、大人会社に出社する。

そういえばこの間検索2ちゃんが引っかかったんだが、ちょっと笑ってしまった。結局、年収やら童貞やら結局、今のトレンドと何も変わらないな。

あ、30年たっても結局俺は童貞のままだったわ。すまんな。

ほんといつも思うんだが、AIだのロボットだのが発達したって結局俺らが働かなくちゃいけないのってなんなんだろうな。

どうせなら働いてる分俺らにそのまま寄越してくれたらいいのにな。

若いのってほんと羨ましいわ。だめだ、もう時代の変化についていけなくなってる気もする。

おっさんたちがスマホ使えないのって正直バカにしてたけど、今や俺がそのおっさんだ。

読唇入力だってこの間やっと覚えたばっかだし、インタフェース旅行だって3D酔いしてた俺は苦手すぎてできない。

まぁ旅行別に興味ないからいいんだけど、時代自分のためじゃなくって、若者のためにあるってことにひしひしと辛さを感じるわ。

もう少し頭が動かなくなったら、老人ホームに入って一生ソシャゲする生活になるんだろうな。

まぁ、別にいいんだけど。

2019-04-24

日本イノベーションが滞っているの、中途半端法律守ってるからじゃないの

自動運転車許可なく町中走らせたり、民泊法律駄目だったし、電動スクーター迷惑考えてないかアメリカは出来ている。

消費者利益にはなってるかもしれないけど、チップをそのまま運転手に払うんじゃなくて最低賃金補填にしてたりさ。


AmazonGoogleも、消費者とのインタフェース機械にして叩かれないようにしてリスク回避してる。

Amazon配達デリバリープロバイダって人と人が接点持つようになると問題抱えるからさ。

2019-03-12

馬鹿名前を覚えておこう

USBメモリインタフェースを閉じたとして、HDMIはいかがでしょうか? HDMIプレゼンテーションの際にモニタに映し出すことが多いため、口が空いていることが多いのではないでしょうか? HDMIUSBの変換コネクタを使えば、USBメモリ使用できるのではないでしょうか?

吉政忠志

https://news.mynavi.jp/article/virus_drweb-11/

2019-02-23

anond:20190223045232

perlでは連想配列

しかし、この話を読んでJavaだけ違うよなって思ってしまった。他のはみんな実装言語処理系にお任せだけれど、JavaだけはMapは単なるインタフェースで、どの実装にするかはお前が選べってところがねぇ。こいつだけはGenericsを使って、keyvalueの型を指定するのも違う。

Javascriptはプロトタイプベースオブジェクト指向言語から、こいつもこいつで思想が他のと違うんじゃないかとも思えてきた。

2019-02-11

紙の本は柔らかい

現代においては物理的に柔らかいことが長所の源泉であり、他の方法で心情的に代替できない理由なんじゃないかな。

それに人間の指の特性が加わり、ページめくりの多様なインタフェースが実現され(一枚一枚ゆっくり小口(こぐち)をなでてざっと見、前後ページを素早く移動、離れたところに指を挟んでおいて移動)また、持った時の心地よさから所有感が補強されているのでは。

たとえば毛皮のように撫でて心地よく、程よく温かいデバイスが出来たら電子書籍でもいいのかもしれない。

- - -

2018-12-12

ハードウェア設計方法って書籍でもネットでも情報ないよな

東大CPU実験くらいは有名なものはあるけれど。

トランジスタラジオインタフェースくらいか

レイヤーが好きだといっても、USB3.1自作しましたとかはないし。

設計するソフトが足りてないのか、人数が少なすぎるのか。

学生からすると何やってるかわからないし、Googleなんかに負けてるし行くメリット動機もないわな

2018-10-30

電子工作情報ネットにも本にもなく勉強できないが、独学で作った物を発表すると笑われる世界

Lチカから次に何かをしようとするとかなりハードルが高いのが電子工作


KiCadやOrCadやAltiumの使い方までは調べればわかるが、PCBをどう設計すればいいか情報はほぼない。

トランジスタ技術インタフェースを読めばわかるかといわれると、ネット上に居る職人に言わせれば間違いだらけの(笑)のシロモノらしいのだが、

自分には、技術力がないのでどこが悪いのかがわからない。


どこが間違っていて、間違っていた場合何が起こるのか書いてあればいいのだが、(笑)で済まされる。

ネット記事もなければ、書籍もないので、指摘するとき引用すらできない状態らしい。


ハワードジョンソンの黒魔術本を読めば解決するかというとそうでもないらしい。

デザインルールチェックをGithubで共有しみんなでアップデートしていくということもない。

2018-09-28

デザイナーを雇うな

例えばツイッターでもなんでもいい、ウェブサイトアプリデザインが急に変化して、「なんで変わったの?」「これ意味ある?」「前のほうが使いやすかった」と思ったことは無いだろうか。

増田の老人達なら昔mixiデザイン一新した際に改悪反対署名運動などが起こったのを覚えているかもしれない。ユーザーは使い慣れたものが急に変わったらまず拒否反応から入るのが普通なのだ。

ではなんでこんなことが起こるか。それはデザイナーを社内に雇っているかである

多くのエンジニアビジュアルデザインが得意でないから、サービス実装初期はデザイナーの手助けが必要であるしかし一度リリースしたサービスは大体基本のデザインの流用で別のページを作れるし、デザイナーの助けなんていらなくなる。そうなった時、社内で時間を持て余したデザイナーは何をするか。

そう、既存ページの新しいデザインを考え始めるのである

ウェブページは「ユーザーインタフェース」であって、デザイナーファッションショーの場じゃない。使い慣れた70点のUIを新しい80点のUIにされても多くのユーザーは喜ぶどころか拒否反応を示すのだ。

点が上がればまだよくて、UIになんら寄与しない「流行りのマテリアルデザインしました」だけの70点→70点のデザイン更新がされる事すらある。この場合デザインに慣れたユーザーから見たら新しい70点は70点未満に映るだろう。

以前大流行したフラットデザインが本当にユーザーを満足させたかマテリアルデザインはどうか?

ファッション世界でも定期的に○○年代リバイバルなどが起こるように、デザインなんてものは「飽きたから変える」とか「目新しいかどうか」といった程度の存在で、新しい流行本質的に良いものかどうかなんて実際は殆ど関係ないのだ。新しいビジュアル本質的メリットを持っているならリバイバルなんて起こるわけがない。

だが自分達の仕事を増やしたいデザイナー達は「このスタイルはもう古い、流行じゃない」みたいな空気を出して流行に乗らないことへの罪悪感を広め、結果ユーザーにはどうでもいいデザイン変更が実施されるのだ。

なので無意味デザイン更新をしてユーザーの機嫌を損ねたくなかったら、デザイナーは社内で飼わず外注して実装が終わったら放逐したほうがいい。

2018-09-09

anond:20180909100816

2068年の日用ガジェットはああいう分かりやすく間違えようのないインタフェースになってるんでしょ。

懐中時計だか腕時計だかの形に縮んでいるけど「バイク」とすぐ分かる。

タイムマジーンの腹には「ロボ」「ろぼ」とちゃんと書いてある。

2018-07-30

anond:20180730125012

『AオブジェクトのBメソッドを〜』

って書いておきながら、引数で持ってくるのかnewするのかは書かないって、片手落ちじゃん

ロジック実装に任せるっていうなら、設計DBまでかもしくは、外部インタフェース仕様ぐらいまでにして、内部で使うクラスメソッド実装側に任せろよ

2018-07-25

銀行ゴミアプリ決定戦

銀行系のアプリが使いにくくて、驚いたが、一番面白いのは、銀行系のアプリについての罵倒批判改善要求コメント。そこで、この場を借りて紹介してみよう

千葉銀行

・これは、すごい。このアプリを作った会社天災だが、このアプリ採用した千葉銀行天災だ。千葉銀行を使っている自分ホコリに思える。もしかしてショートカット作成AIでも導入されているのか、ブラウザを開いているような新技術が使われているのか、絶妙すぎで凄すぎる。流石に儲かっている銀行提供するアプリだけあってユーザービリティ再考

バカが作ると出来上がるアプリの良い見本、本社セキュリティが甘いため、アクセスのために様々な煩わしさをユーザーに強いる。 何が悲しくてパスワード以外に3つもキーワード入力させるのか? この仕様提案OKを出している連中は人々に迷惑しかかけられない能無しなので全員廃業しろっての

・使えなすぎ。 ただのショートカットアプリワンタイムパスワードが夏から必須になるけど、アプリで使えるようにして。トークンなんて不便すぎ。技術低すぎ。解約したい

新生銀行

・最悪すぎる。 スマホ認証で、キー発行アプリを参照すれば、当アプリバックグラウンドになり、最初の画面からやり直し。 認証出来るわけない!嫌がらせか!! そもそもバックグラウンドに行ったらログインし直しじゃ、、メールで振込先口座見ながらとか全く無理。 設計ミス。使い手のイメージ出来てない証拠利用者視点テストを考えてない証拠。いろいろ怪しくなってくる。 今後が不安なため、メインバンク変更決めました

銀行アプリは多く使っておりますが、こんなに使えないものをよく世に放出出来ましたね。何をするもにも再ログインしかも口座番号を覚えてくれる機能もないので支店番号暗証番号ダイレクトパスワード全て1から入力時代は移りゆくものですが、ネット銀行員の知能の低さすら垣間見ますアプリ操作方法に関して問い合せても「アプリというかブラウザの○○をご覧下さい」。アプリについて尋ねたのですが。蛇足ですが。全額出金しま

素人が作って素人承認した未完成アプリです。 フリーズが頻繁に発生し、まともに進むことができません。 また無駄セキュリティチェックが多く、ログインしても振込時に、いちいちセキュリティカード記号を入れようとさせます自分で作ったアプリに自信がないからそうするのでしょうが利用者からすると迷惑です。 だったらアプリじたい提供しないでほしい

みずほ銀行

・メチャメチャレスポンスが悪い。普通にブラウザからアクセスしたらサクサクなので、ネットワークの問題ではない。即アンインストール

・どうして更新する度にお客様番号が消えるのか。 とても面倒で煩わしいです。 基本重いです。 正しいパスワード入力しても入れない時もある。 時間置くと入れるけど、時間かかるので面倒です。 他銀行サクサク行くんですけどね… 銀行行った方が早いって思ってしまうので、何のためのスマホバンキングなんだろうって感じです。 それでも使う時もあるので、頑張って欲しいです

くそアプリアプリは削除してワンタイムパスワードカードに移行します。不便だけどアプリよりは多分マシ

三菱UFJ銀行

スマホ変えたらまた再登録ワンタイムパスワードがどうたらこうたらでよく分からん登録画面が複雑怪奇過ぎて…、これ1人で出来る1人何割くらいいるの?

メニュー画面を 開くための左下の表示がわかりにくすぎ。最低ランクユーザーインタフェースと言わざるを得ない

・なんで銀行アプリ広告があるんだよ、あほか あと画面勝手に横にすんな使いにくすぎ。正直★1やるのも惜しいくらいのクソアプリ。やっぱりufjゴミだな

コメントは、全て、「goole play」から引用

2018-04-25

anond:20180424102112

システム化されていくほうがレジ待ちが早くていいじゃん。

エンドユーザ(年寄り)目線の手厚い会計希望するならレジを分けて店員チップを払うようにすればいいんじゃね?

UIの作り込みの問題はあるにせよ、人かシステムかみたいなインタフェースの違いの話は所詮は慣れでしかいから、逆に今の中高生なんかだとスマホで注文できるほうがずっとエンドユーザ目線なわけで。

そもそもそういう店が嫌なら行かなきゃいいじゃん(笑)

2018-02-03

Web上の学習動画講義について考えたこ

 現在、有料の「学びエイド」、無料の「Web玉塾」、無料の「Manavie」家庭教師のトライがやっている無料の「Try it」、この4種の動画講義を主に利用している。

 

 この4種の中で、学校の授業に1番近い作り方をしているのは、「Try itである最初過去講義の振り返り、今回のポイント練習問題、振り返りと続く。1本の講義時間10から30分までである

 動画講義の中で1番短いのは、Web玉塾、学びエイである。両者の動画講義は基本10分程度に長さを抑えてある。ポイントは1動画に1つから2つ。1度学校の授業を受けてから見る動画という印象だ。Web玉塾は、古くからある動画講義で、早口コンパクトにまとめてある。学びエイドにある講義Web玉塾と同様の傾向がある。

 Manavieは、授業に似た講義(Mundi先生世界史日本史地理(途中))や学びエイド的な講義(とらます先生生物)、Web玉塾など、ネット上の無料動画講義キュレーションしたサービスであるユーザーインタフェースも整ってきている。

 現在、私は理科高校教員として働いている。Manavie、Web玉塾の生物動画講義を生徒に進めてみたが、どうも評判が良くない。なぜか考えていたところ、とらます先生ブログの下記ページからヒントを得た。

受講スピードに関する再発見

http://genuinestudy.seesaa.net/article/456325367.html

 上記リンクを読み、私が出した結論は、Web玉塾、Manavieの生物動画講義は、高校の生徒にとり早すぎるということだった。

 この発見から、次は家庭教師のトライの「try it」の生物講義を進めてみようと考えている。生物を一度学んだものにとっては、「try it」の講義は遅すぎる。しかし、私の仮説が正しければ、高校生には講義スピードの遅い「try it」は受け入れられるかもしれない。

 動画講義を作る人は、塾の先生教育燃えボランティアが多い。そのため、動画をなるべくコンパクトにし、勉強時間効率を高めるよう作られていると私には感じられる。

 しかし、多くの講義動画をみて私が感じたのは、長い動画にも見やすものがあるということだ。特に、ManavieのMundi先生動画は、世界史日本史に対する、Mundi先生愛情が溢れている。このため、長くても見れる。

try it」を見ていると、多少時間が長くてもゆっくり20から30分程度)1つの事柄説明しているため、授業作りのヒントが得られることも多い。長い(20から30分程度)の講義動画需要もあると感じた。

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タイトルの巨大なプロジェクトスタイルを他のビジネスにも取り入れるのが良いと思っている。

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

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

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