投稿

2月, 2014の投稿を表示しています

Yahooのeコマース革命が本気な件

イメージ
NET & SMARTPHONE COMMERCEに参加してきました。
eコマース革命 @ Yahoo執行役員 小澤隆生さんのお話が印象に残ったので投稿。

内容としては、Yahooはeコマースにマジで、本気で取り組みますっていう熱い内容でした。
勢いだけでなくしっかりと背景も説明して頂いていて納得感のある講演で、
Yahooで出店したくなりました。


以下、講演内容のメモ。


* Yahooはショッピングに本気じゃなかった
検索に関する知見は溜まっていたが,ショッピングについては力を入れてこなかった.
日本のeコマース市場は小売り市場全体の6%にすぎない(2011年度eコマース市場規模 8.8兆円)ため、今後ユーザーが増えて成長する余地がある。
プラットフォーマーとしてやるべきことは市場の拡大スピードを向上させること.
市場のシェアを競合から奪うことではなく,eコマース市場を拡大させたい.
その結果、eコマース革命と称して数々の施策を打つこととなった。

以前、インターネットユーザーを増やすため、モデムを配ったことがある。
無理やりにでもインターネットユーザーを増やし、
インターネット上でビジネスを展開する会社が儲けられる環境を作りたかった。
儲かればプレイヤーが増えて市場が広がる。
それが競争を産み、広告を打ってもらえていた.
プラットフォーマーとして、市場拡大の施策を以前も打ち、成功してきた。

* 攻めの経営
これまでは検索連動広告だけで十分儲かってきたが、今はビジネス環境が変わってきた。

- 精度の良い検索連動広告
PCクエリシェア国内最強の地位を活かして、検索とショッピングを連動させる。
具体的には、ユーザーが検索したワードに連動した広告枠が検索結果画面に出てくる仕組み。
日本人はランキングが好きな人種で、間違った商品を買いたくないなーという心理から、どんなものが売れているかといったランキングを気にしている.
国内最強の検索クエリシェアのビッグデータを利用した検索連動広告は、
出店者にとって非常に有益なものになると自負している。

- ランディングページ
今でもYahooのトップページをスタートページに利用してもらっているユーザーは多い。
年末は、トップページからヤフーショッピングに広告を載せて、流入量を上げるような仕組みを作った。
これはYahooだけが提…

"SDNは世界を救う? @ SDN Conference 2014" が物凄くわかりやすかった件

イメージ
SDN Conference 2014 @ グランフロント大阪 に行ってきました。
SDNが何かを漠然と知ってるつもりで参加してきました。
参考になった講演があったので詳細をまとめます。


================================================================= SDNは世界を救う? 講演者 東京大学
情報基盤センター
准教授
関谷 勇司
概要 Software Defined Networking (SDN) は従来のネットワーク構築手法や運用手法を変化させる技術革新として、近年注目されている。様々な機器ベンダーがSDN に対応した製品やソフトウェアを出荷し、クラウドの構築や管理を主眼とした SDN 製品も登場し始めている。本講演では、近年盛り上がりを見せているSDN の本質とは何なのか、その適用範囲と適用手法、ならびに欠点や注意事項も含め現状の SDN の全てをわかりやすく概説する。SDN を導入すべきなのか、どの部分にいつ導入すべきなのか、研究者としての中立な立場から、最新の技術動向をふまえ、SDN の未来を語る。
=================================================================

SDNの定義

SDN = ソフトウェアによって柔軟に定義されるネットワークとその周辺技術
SDNはある枠組みに従って作られた技術の総括であって技術ではない.
一方でOpen Flowは特定の技術のことを指します.

従来のネットワークとOpenFlowの差異

- 従来のネットワーク
IPネットワークは自律分散型で,それぞれのスイッチやルーターが協調して動作している
IPアドレスが識別子.通信の宛先でありすべてを示している
ルータースイッチといった機会はIPアドレスというインターネット上の番地を参考してバケツリレーしていく

- OpenFlow
あるデータを転送するにあたってどういう道筋で送るかを考える部分(コントローラ)と,
指示に従ってデータを渡していく部分を分離したモデル(スイッチ)
コントローラがすべてを決めていく.
IPアドレス以外の要素も見ながら道筋を決定していく
コントローラ側を人間がプログラムする神様モデル.

- SDN
単位は「機器」ではなく「サービス…

ネットワークプログラミング最速入門

ネットワークプログラミングを最速入門してみる。
TCP/IPの本とか読み漁ってみたけど、実際に実装はしたこと無いし、
ソケットAPIとかも全く知らない私が取った勉強方法をまとめます。


まずは図が多用してあって事前知識ゼロでもざっくりとわかった気になれる資料を探しました。
いろいろググってたら、信州大学のネットワークプログラミングの講義資料が超絶わかりやすすぎた。
ざっくり実装はできそうだなーという感覚が得られればこのサイトの役目は終了。
特に、 3. ソケットプログラミングの基礎 と、 5. プロセス管理とソケット管理 にエッセンスが詰まってる。
順番的に自分としては5→3の順番で勉強するといいと思う。


「5 プロセス管理とソケット管理」で学ぶこと

「プロセスとはなんぞや」って部分が初心者にもわかりやすいように解説されているので非常に有益でした。
プログラムをざっくり写経してみて、適宜printfを突っ込みつつマルチプロセスなプログラムの挙動を理解すればいいだけ。
ここでの肝は、fork()とsignal()とwait()というAPI。

* fork()について
子プロセスを作ります。
子プロセスでは返り値が0、親プロセスでは返り値が子プロセスのプロセスID。
fork()を呼んだ時点で親プロセスメモリがコピーされて子プロセスが生成されます。
fork以下のコードパスは、親子どちらのプロセスも通ります。
fork()の返り値は親子で違うのでif文で分けるのが定石っぽいです。

* wait()について
子プロセスよりも親プロセスが先に終了すると、子プロセスがゾンビプロセスとして残っちゃうらしい。
親プロセスが子プロセスより先に終了しないために、子プロセスの状態変化を待つためのしくみがwait()、待つからwait。

* signal()について
"あるプロセスがシグナルを受信すると、そのプロセスが現在実行している処理を一旦中断しそのシグナルに対応した処理"シグナルハンドラ"を実行します。" ← 完全に引用。

「3 ソケットプログラミングの基礎」で学ぶこと

クライアント側とサーバー側で実装が異なるので、違いを抑える。
システムコールの流れを覚える。
ソケットAPIの挙動を説明できるレベルで理解する。
通信フロー図を書いてみる。

Getting started to improve web design in a corporate site...

イメージ
When I was a master graduate student, I spent a lot of time to create a corporate website.
It is because all the codes were written from scratch.
I could learn a lot by doing that.
At that time, all the codes were easy for me to understand.
But now....  I can't.
It's because codes are too complicated and messy..
From the start point, I should've avoided such "Reinventing wheel" work.
In addition, I should have learn how to implement website effectively by employing some sophisticated web framework and libraries.

So I'll employ those kinds of things to implement better website from the view point of design and maintenance.

I'll use bootstrap.js as a first step to achieve that.
Currently I'm creating a sample website like this on Google app engine.






Webデザインを考えるのが面倒なのでBootstrapを1時間くらいで導入してみた話

イメージ
Webサイト作るのは楽しい。 初めてWeb技術を触った2010年くらいの時は、面白すぎてHTML, CSS, Javascriptをフルスクラッチで実装してた。


Done is better than perfect

テンプレとかもあったけど、私はブラックボックスが嫌いだったので、 試行錯誤して、完璧なものを目指して膨大な時間をかけてしまった。 勉強にはなった。 一方で提供した価値は掛けた時間の割に小さかった。 デザインはゴミ、操作性もゴミ。
Webの世界は巨人の背中に乗ってサクッとものを作ってしまうことが大事で、 車輪の再発明をするようなエンジニアに付加価値は無いわけだと最近つくづく思います。 このとき、マーク・ザッカーバーグのいう「Done is better than perfect」に納得しました。
余談ですが組み込み系の世界ではまたそれが違って、 仕様の徹底理解と入念なテストが必要になってきます。 # デバイスに書き込まれるファームウェアとかは容易に書き換えられないので。

超速でとにかく実装完了を目指す
時間をかけずに、それなりのサイトを超速で作ることに主眼を置くと見えてくる世界が変わります。
実装する側の視点に立ってみる。 にたてば、「どんなテンプレ使おうか」、「どんなライブラリ採用しようか」といった思考を巡らせるかと思います。 ざっくりググッて見ると革新的なウェブデザインとかたどり着くんですが、 広告やら芸術系のサイトならそれは価値があります。 一方で、自分が作ろうとしているものはなにか?と自己問答してみると、 デザイン面は提供する価値ではないと判断しました。
視点を変えてみる、ユーザーの気持ちに。 ユーザーからすると革新的なデザインよりもよく使っているデザインがいいんじゃないか。 デザインに独自性はないものの、ストレス無く使ってもらえるウェブサイトが作れるんじゃないか。 そんな仮説から、頻繁にアクセスされるSNSを見てみた。 最近、スマホアプリの殆どがFacebookアプリライクなデザインになっていくのを感じるし、 有名サイトの殆どが似たデザインになっている。 やはりこの仮説の妥当性はほぼ検証できたので、 それぞれのサイトで「右クリック+ソースを表示」してみた。 なんか殆どBootstrap.jsっての使ってるぞ。

超速でBootstrap.jsを導入…