 
|
はてなキーワード: WEBサービスとは
これは、「事務職リーマンがwebサービスを作ってみた話」のトラックバックに対するトラックバックです。
もちろん、この手のアルゴリズム処理に「完璧」は存在しません。
ですが、拾った結果の品質を数百個ばかり、サンプリングで調査した範囲では、商品サイズを拾える商品のうち、９割を大きく超える率で、正しいサイズを拾えていますので、
もちろん、検索できる商品数が尋常じゃないので、サイズ抽出をミスっていそうな商品を狙い撃ちで探すと、結構見つかったりはしますが。
ちなみに、上記の「商品サイズを拾える商品」という表現には、レトリックがありまして、結構、楽天ではサイズが画像のみで記載されている商品もありまして、そういうものは、当然、検索できない商品となっています。
まあ、これは仕方が無いところです。
サイズは、正しくサイズを拾えるよう、複数の書き方パターンでサイズ候補を抽出しています。
おおまかには、
・幅×奥行×高さ（単位センチ）・・・・・・XX × YY × ZZ
の２パターンで、このパターンを軸に、さまざまな派生に対処しています。
この派生（というかノイズ要因）が滅茶苦茶いろいろなパターンであって、相当手を焼きました。
実はこれも、簡単そうに見えて、結構、面倒なところでした。
・サイズ記載部分から遠く離れた部分に（単位：ミリ）とか書いてある場合がある
など、さまざまなパターンがあり、結局、サイズ記載箇所の前後を見て、距離などから重み付けを調整して、サイズ単位を拾っています。
また、そもそもサイズ単位が記載されていない（意外とよくある）場合は、サイズ値の大きさを見て推定したり、（例えば、家具カテゴリのサイズ表記に小数点があれば、それはきっと、ミリではなくセンチだろう、など。）全く見当が付かん、というときには、決めで処理したり、仕方なくあきらめたり・・・といった処理をしています。
サイズを拾うだけでは、梱包サイズとか、引き出し内寸とか、ノイズが多いので、これらは、重み付けを行い、一番重み付けが高いものを外寸サイズとして拾っています。
この辺の重み付けは、ある程度、作りこんでいますが、もちろん、完全ではないので、今後のブラッシュアップが必要な部分です。
こちらは、型番等で誤反応を起こしやすい、W/D/Hでの記載サイズのレーティングを少し下げて対処しているのですが、初めのほうにトラックバックを頂いた方もご指摘されているとおり、それでもある程度引っかかっちゃいます。
タイトル中の型番を検索外すとかの手も無くはないのですが、型番って意外と本文中にも多くて、例えばテレビ台とかで、本文中にテレビ型番をズラズラ列挙されて、それが反応した時もあります。
一応、異常値についてはレーティングを下げたり、サイズ数値取れずで処理はしています・・・みたいなところではありますが、検討すべき改善箇所です。
ex)「幅800×奥行400×高さ100センチ」の棚・・・など。
こちらは、最終的なサイズ数字を見て、「サイズ単位の書き間違い・拾い誤り推定」の判定を入れておりまして、判定に抵触したサイズについては、正しいと思われる単位に変更・救済しております。
もちろん、フォローにも限界があったり、フォローを行って二重遭難する場合もあるんですが、検証してみたところ、ほんのわずかな二重遭難よりも、誤り救済を行ったほうがはるかに結果がよかったので、処理を入れてます。
ただ、結論から言うと、サイズ情報に対する、楽天市場側の動きはほとんど無いと読んでおります。
なぜなら、圧倒的にニーズが高く、ハードルも低いと思われる、送料込み価格検索すら、彼らは実現できてないからです。
恐らく、楽天側では、出店側に登録させる情報を、いじりたくないと思っているのではないでしょうか。
しかも、サイズ情報は、楽天が扱っているほとんどのジャンルの商品にとっては、それほど重要性の高くない情報です。
ごく一部のジャンル向け以外は重要性の高くない追加の登録情報なんて、楽天はあまり実装したくはないのではないでしょうか。
・・・と、そういう読みをしてますし、さらに、読みが外れて楽天が対応を行ったとしても、別に私は片手間でやっているだけなので、それほどペナルティが大きい訳ではありません。
以上、カグサイズのページ処理の内容部分の説明でした。
それではー。
----------
Pythonの方が弄れる対象が多いのに、なんでウェブ系だとPHPの方が流行ってんだろ
端末からのテキスト処理も楽だし、数値計算周りのライブラリも充実しているのに
PHPが優遇されているのって歴史的な経緯以外に何か他の理由でもあるのか？
けどまぁ、情弱な文系SEが大半を占めているバカだらけの日本じゃ別にPHPで困ることもないか
数値計算や端末からのテキスト処理なんてWeb系じゃ大して使わないからなあ…
Pythonに関しては、ZopeさえコケていなければWebサーバ用LLとして大成功していたはずなのに、
Railsなんかが登場したおかげで、すっかり影が薄くなってしまいますた....
ってか、railsにインスパイアされたフレームワークって今じゃ幾らでもあるよね
djangoとかCakePHPとか。rubyってRoRを使いたいユーザを除くと、
pythonやPHPの方がユーザー数は圧倒的に多いと思うんだけど
本家のrailsって、他を遥かに越えるほど良いものなんだっけ？
44
Zopeが登場した当時、「RDB+PHPはもう古い、これからはOODB+ZopeがWebの中軸になる！」と
少なくとも自分はZopeからPythonという言語を知ったし、その時点でRubyは知らなかった
そして、その後のORM(RDB)+Railsの出現と華々しい革新性への注目は、誰もが知っているだろう
今でもZopeの開発は継続されてはいるが、結果的に当初の期待が大きく裏切られたという事実は動かしがたい
djangoとCakePHPについては実際に触っていないので憶測になるが、おそらく技術水準ではRailsと同等だろう
しかしRailsはRailsでコミュニティの活動が活発だし、その進化は異常に早い
Railsに何か致命的なトラブルが発生して開発が停滞する、あるいはdjangoやCakePHPから
何かのイノベーションが提示されでもされない限り、後発のdjangoやCakePHPがRailsに追いつくのは無理
Railsは決して技術的に完璧なWebフレームワークではないんだけどね....（たとえばSeaSideのような.... ）
だからこそ「もしもZopeが....だったなら」という「たら・れば」感はPythonコミュニティの潜在認識になっている
C a k e P H P は う ん こ
CakePHP使ってんの？
可哀そうにw
でもやっぱりいつもの使い慣れたLL(Python/Ruby)で
Webサービスを書きたいってのがある
求人数は
Ruby on Rails＞＞＞＞＞＞＞＞Django
http://www.indeed.com/jobtrends?q=django%2Cruby+on+rails&l=
どういうことなの？
求人数が多いのはそのためだと思うよ
なんかのミスかと思ったがアメリカでもRuby on Railsは人気があるのかなあ・・・
Pythonのほうが使いやすいと思うのだがフレームワークはRailsが優位なんだろうか
Djangoは周辺ライブラリが微妙だし本体も鈍くさい感じがする。
でも、FlaskはSinatraより好きだから、Pythonが嫌いってわけではない。むしろ好き。
ただ、いざ作り始めるとやっぱりRailsが楽だなあってなって、Railsを使い続けている。
同感だ
同じように思っている人が他にもいて安心した
PHPはフレームワークが乱立しすぎているから、RailsをPHPで実装してみようというやつが出てきた。
それに比べてPythonは、Zopeというデファクトスタンダードが既に存在していたけど、
ただ、どうやってもRailsもどきがRailsを超えることはできないのは間違いない。
パクリはオリジナルを超えられない(ｷﾘｯ って定型句だけど、
これってｷﾘｯって言いたいだけだと思う。
D言語って超えたって？
B言語って超えたって？
PHPで同じ事をできないわけではないだろうけど、Ruby on Railsほど簡潔にはできない
まあくだらねえWEBサービス作って喜んでる情弱は早く死ねって事だよ
そういう理由じゃなくてRailsのほうが単純に情報もプラグインも多いからでしょ
linuxじゃデフォのツールなんだし、ツールとの連携を考えたらpython一択じゃん
わざわざ不合理で不完全な言語を使うなんて
もしも
＞linuxじゃデフォのツールなんだし、ツールとの連携を考えたらpython一択じゃん
真実であるのなら、今頃はdjangoの情報とプラグインが溢れかえっているはず
yumや、gdbとgnomeの拡張がpythonであるからといって、それをwebアプリでも使いたいと思う人は少ないというだけのこと。
ソースからインストールする必要があったとしても、web開発ではrubyを使いたいという人が多いというだけのこと。
というか、世界中のPythonプログラマが Remeber Zope!! を合い言葉に
打倒RailsたるWebフレームワークを開発しているはずだけど、
Railsも登場してから、かなりの年月が経過しているんだけどなぁ....
その間にもRailsはRails 3が登場して、REST/AJAXの強化等の進化が継続しているよ
Ruby では
ary.map {|x| x**2}
map(lambda x: x**2, ary)
となり、lambda の本体が1つの式では表現しきれなくなると
.....
と書き換える必要があります。
f = lambda x:(x and f(x-1)*x)or 1
RubyにはPythonのように「lambda本体は式でなければならない」という限定がありませんから、
f = lambda{|x|if x == 0 then 1 else x*f.call(x-1) end}
または
f = lambda{|x|x == 0 ? 1 : x*f.call(x-1)}
と書けます。lambda内でreturnが使えますから、書きたければ
f = lambda{|x|if x == 0 then return 1 else return x*f.call(x-1) end}
でもOKです。
348
これはPythonをdisっているように見せかけてRubyをdisっているのか？ と一瞬思ってしまったｗ
だってRubyのほうが長くない？CLのfuncallみたいなcall()がちょっとうざいし…
そしてどっちもlambda式の中で束縛変数の名前で再帰可能、と
print [x*2+100 for x in [1,2,3,4,5] if x > 2 and x < 5]
暗号のように見える。
puts [1,2,3,4,5].select{|i| i > 2 and i < 5}.map{|i| i*2+100}
思考の流れと、コードの流れが一致しているので書きやすい。
map(lambda x: x*2+100, filter(lambda x: x > 2 and x < 5, [1,2,3,4,5]))
pythonて可読性が高いのをうたってる割にはそこいまいちだよね
Rubyの場合には、左から右へと無名関数がデータフローあるいは
関数型プログラミングに不慣れな初心者でも、参照透明性のあるコードが自然に書ける
プログラマにとって優しい or プログラミングの楽しさを教えてくれるのがRuby
それと比較すると、Pythonのコードは、関数型プログラミングというものが
いかに高度で難解なものであるかという事をもったいぶってプログラマに押し付ける
もしもPythonしか知らないプログラマであれば、関数型 = 難解 という印象を持つだろう
階乗計算くらいだと単純すぎて、ナゼ重要なのかが分かりづらいと思うのでコードで示す
result_list = source_list.map { |elem|
x = foo(elem.x) # ここが局所宣言を書く部分
x + y # 最後に評価された式の値が、無名関数のリターン値になる
}
Rubyでは、map等に与える無名関数の中で局所的な環境(クロージャ)が作られるから、
x = foo(...) のような代入文がいくつでも(= 複雑な処理でも)書ける
このポイントは、実用的なプログラムを関数型風で書こうとした時に、威力を発揮する
余計分かりづらくなった
高卒ドカタなんだろうなぁと可哀想になる
集合の表記に似せてることが分かるから
355
＞map/filterはfor/ifと同じだと言っているだけだから、難解という印象は持たない。
関数型プログラミングに慣れた、あるいは得意な人であれば、そういった印象なんだろね
Rubyの魅力はこれから関数型プログラミングを学ぼうとする初心者、 あるいはそんな初心者へ教える立場から見た、優しさ or 分かりやすさなんだ
[1,4,3,2].sort.reverse.map{|x| x.to_s}.join('-')
Pythonだと読みにくい。
'-'.join(map(str, reversed(sorted([1,4,3,2]))))
Pythonでは思考の流れと一致しないばかりか、「カッコだらけ」のコードになると.....
カッコだらけのコードを分かりやすくする基本的な方法は静的単一代入じゃないか
Rubyのやり方は基本ではなく玄人のやり方だろ
Pythonでは組み込みの型でメソッドチェインはやって欲しくないな
似たようなコレクションtuple,deque,array,queue等にも同じメソッドが必要になってくるし。
372
外部のライブラリでも列挙可能なものは、たいていEnumerableモジュールをimportしてますね
Rubyユーザーは列挙可能なものはmapやselectできて当然だろって思ってる気がします
Pythonは「何かを便利に書くためのしわ寄せ」をはっきり寄せてくる
得意と不得意を言語レベルではっきり主張するのでメリケン好みと言えなくもない
Rubyは全方位になんとなく八方美人なので、全体的になんとなく書きやすくてなんとなくキモくて遅い
「書きにくいってことはその処理に向いてないってことだから諦めろ」を地で行く
無名関数が文を使うほど複雑なら名前を付けるのが Python 流と想像。
これを読みづらいと感じるのは、左から右に流れる
もしかしてアラビア語ネイティブな人からすると逆に読みやすいのか？
Webシステムとは縁遠い事務職のリーマンが、ある日思い立って、ニッチな用途の検索エンジンサービスを作ってみたので、ちょっと書いてみようと思います。
ちなみに、検索エンジンといっても、googleカスタム検索とかのお茶濁し系じゃなくて、apache Solrというオープンソース検索エンジンを、VPS上で動かしているという、それなりに本
気度の高いものです。
なんで素人がそんな物騒なものを動かす羽目になったかは、後述。
やりたい構想みたいなことを思いついたのは、もう6、7年前ほど前のこと。初めて独り暮らしを始めたときに、ひどく不便を感じたことがあり、こんなサービスがあったら便利だなあ、
ちなみにその妄想をふと高校の同期に話したとき、そのサービスはどこにあるのか？！と、えらくがっつかれたのを、覚えてます。まあ、俺と同じく偏執狂の奴だったからだと思います
が。
ただ、しがない事務職リーマンということもあり、当然、技術も無く、そのときは、やるならこんな名前のサービス名だろうなあ、とか、そんな妄想レベルで、話は終わっていました。
そんな感じで、5年ほど月日は経ち、なんとなくリーマン人生の流れも見えてきたところで、以前、妄想していたことを、ふと思い出しました。
5年も経ったら、さすがに自分が考えたようなこと、誰かがやっているだろうと調べてみたところ、意外なことに、競合になるようなサービスは存在せず。ちょうど異動があって、少し時
間が出来たこともあり、じゃあ、着手してみようかと思い立ちました。
やりたいことは、大手サイトの情報検索。ただ、商品ページ内の特定情報、それも、商品ごとに正規化されていない表記を、正規化して抽出する必要があったので、大手サイトの既設API
だけではとても実現不可能でした。
まあ、だからこそ、5年間、誰もやろうとしなかったんでしょうが。
ということで、とても一発では解決できなさそうな内容だったので、自分でなんとか実現できそうな機能に細分化して、各個撃破していくことにしました。
随分と考えた結果、
以上に区分できると考えて、これらを各個撃破していくこととしました。
また、技術もなく、プログラミングも出来ず、ましてやlinuxサーバのお守りをしたことなんて当然ないので、インターネット上に置くサーバですべての処理を完結させるのではなく、イ
ンターネット上に置くリソースは最小限に留め、できる限り、勝手がわかる自宅のwindowsパソコンで処理を行うことにしました。
ちなみにさらっと結論だけ書いてますが、ここまで至るまでに、いろいろと調べ続たり、考え込んだりしていたので、思い立ってから3ヵ月は掛かってます。。。
さて、やる方針を決めたあと、はじめに着手したのは、要の検索エンジンサーバです。
いろいろとググって調べて、mySQLというやつか、apache Solrというやつかに絞りましたが、結局、Solrを使うことにしました。
MySQLのほうが実績は多そうだったのですが、Solrのほうが検索専門で、滅茶苦茶動作が速いらしいということ、MySQLでも出来るが特に速度が遅いらしい全文検索機能も使いたかったこ
と、あとファセット機能がジャンル絞りこみに便利に使えそうだったので、というのが理由です。
ちょうどSolr本が発売されていたこともあり、それを参考に、自分が使うように設定ファイルを変更していきました。
しかし、初めは設定ファイルの内容も意味不明な上に、私の書き方も雑なのか、少しいじっただけでまったく動かなくなる。結局、設定ファイルを一文字ずつ変更しては動作検証、とい
った始末で、進捗は地を這うよう。ある程度思い通りにSolrを扱えるようになるまで、3ヵ月以上掛かったでしょうか。。。
さらに、検索エンジンのフロントエンド（Solrの検索結果を、htmlに変換するプログラム）も書かなければならない。プログラミングが出来ない人間には、これが本当に辛かった。
Solr本に、いろんなプログラミング言語でサンプルがあったのですが、迷った末に、わずか数行なら書いた（≒コピペした）経験があるという理由で、javascriptを苦渋の選択。
しかし、選択はしてみたが、基礎が本当に無いから内容がサッパリ頭に入ってこない。こちらも、わかるところから本当に1文字ずつ変えていくといった手探り状態。
プログラミングについては、今回のためだけだから、といった理由で、一切基礎をやらずに着手したのが裏目に出たのか、サンプルのソースをモノにして、書き上げるのに、ゆうに半年
以上。本当に時間が掛かりました。
さらに、Solr周りで計9ヶ月間ハマっていた頃、忘れもしない、kanzen21のおっさんが彗星のように現れて、衝撃を受けることになります。
大手サイトのページをクロールして検索エンジンを作る手法は、私と考えていた構想の枠組みとまさに「完全に一致」な訳で。。。
図書館事件に注目していたのも同じで、あまりの一致具合に衝撃を受けっぱなしでした。
その後の成り行き等も含めて、興味深く観察させて頂き、本当に参考になりました。
そんな感じで紆余曲折もありましたが、ようやく難題だった、プログラミング関連に目処が立ってきたので、あとはクローラと肝心のデータ処理です。ここからは、勝手知ったるwindows
まず、クローラですが、専用のクローラをwindows用に探してきたり、それを設定するのも大変なので、今回はテレホーダイ時代に使っていたような、フリーのweb巡回ソフトを利用する
こととしました。指定のhtmlをダウンロードしてくるだけなので、別に変に新しいものに手を出す必要もないので。
また、ダウンロードしてきたhtmlファイルについては、これまたフリーの日本語処理ツールでcsv方式に加工することにして、処理ルール部分を相当に作り込みました。
このあたりは、全体を通して見てもキモの部分なんですが、ある意味、ちょっとしたパズル感覚だったので、プログラミング言語の部分と違って、かなり楽しかったです。
あとは、msdosのバッチファイル（これは前から知っていた）で、これらの処理を繋ぎ、cygwinのcurlとかいうツールで、連続して検索エンジンサーバにcsvファイルをアップロードする
仕組みを作りました。
検索エンジンサーバには、容量は少ないが、安くて高性能という、今回の用途にピッタリだった、さくらのVPSを借りて設定。CentOSのサーバ構築ホームページを見ながら、サーバとか
Solr管理URLとかにセキュリティを掛けて、こちらも素人ながら、意外とすんなり設定。
ホームページは、vpsサーバに相乗りさせるのではなく、別にさくらのレンタルサーバを借りました。apacheの設定方法等を習得する必要がありませんし、vpsのリソースをapacheと分け
合う必要が無くなるので。ホームページのhtmlファイル、cssファイル等も調べながら設定し、画像も準備しました。
あと、構想を思いついたときに妄想していたサービス名の.comドメインは、すでに他者に取得されていたのですが、どうも使っている風にも見えなかったので、whoisで出てきたメールア
ドレスに連絡して交渉し、幾ばくか払って買い取りました。
結局、足かけ18か月。ようやく完成。
楽天市場の家具を、幅x奥行x高さ(家具サイズ)で検索できる、楽天市場・家具カテゴリ専門の検索エンジン
この商品数規模（データ収録約30万アイテム）で、1センチ単位で家具のサイズ指定検索が可能な手段は、商用サービスも含めて、ほかには存在しないと思います。
kanzen21と違って、エロじゃないから華はないけどね。。。
ちなみに冒頭で少し書いたきっかけですが、就職して独り暮らしを開始したときに、新しい家にピッタリサイズの家具が欲しかったのですが、これが楽天で探すのは至難の技でして。
楽天で家具を探してみようと思った人には判っていただけると思うのですが、楽天では、価格では範囲指定やソートができても、サイズでは検索出来ないんです。
これは、楽天では、商品のサイズ情報は商品の自由記述欄に記載することになっているためで、商品ごとにサイズの記載方法がバラバラのため、検索が事実上、不能となっています。
家電製品とかに関しては、種類が少ないこともあり、メーカーのホームページとかでサイズを確認した上で、商品型番で検索すればいいので、それほど問題にはならないのですが、家具
って、種類が非常に多く、型番もあったり無かったりで、家電のようにサイズを調べることができません。
・・・ということで、カグサイズでは、楽天の商品ページにいろいろな書式で書かれているサイズ情報を拾って解析して正規化し、範囲指定やソートして検索ができるようにしています
。
また、単に寸法サイズを拾うだけでは、梱包サイズとか引き出し内寸とかも引っ掛かってしまうので、それらは出来るだけ排除して、商品の外寸が優先して引っ掛かるよう、アルゴリズ
ムを調整しています。
単位（センチとミリ）に関しても、商品ごとにバラバラ（単に単位だけでなく、商品説明のどこに"センチ"とか"ミリ"と記載しているかについてもバラバラです。）なので、サイズ表記
の前後の状況をみて、正しいと思われる単位で拾うようにしています。
あと、変わった使い方としては、欲しい家具の価格比較みたいなこともできます。
家具は、同じ商品でも、店ごとに型番が違ったりすることがよくあり、簡単には価格の比較が行いづらいジャンルの商品です。
しかし、型番は違っても、同じ商品なら原則、サイズは同じですから、欲しい商品とまったく同じサイズで検索をかけると、同等商品があるのかどうか比較しやすい・・・といった使い
方もできます。
と、そんな感じで、しがない事務職リーマンが作ってみた、ニッチな用途の検索webサービスを、サービスインさせて頂きました。
一般に公開されていて、誰でもアクセスできる情報でも、ニーズが有りそうな切り口の条件で検索性を高めれば、新しい価値を創造できるんじゃないかという実験です。
もしよろしければ、ぜひ、使ってみてくださいー。それでは！
----------
Webサービスになるんじゃないかなーってことを思いついたので、自力で作ってみよう思う。
プログラマとして社会人約三年経験後、無職半年目。別業界に行こうと思ってた。
でも思いついたからやってみるって言うのは有りだと思うんだ。
機能拡張とかばっかりだったから、どうしていいのかいまいちわかってない。
・レンタルサーバを借りる
・余裕があればドメイン取得
・開発言語はPHP（とはいえ独自フレームワークばっかりだったのでCakeとか使えないぞ……）
・MySQL実は使ったことがないんだよな。関数をチェックしておく必要性あり。
・UIはHTML5を意識したXHTMLで書いておけば将来的な移行がしやすいのかな。最初からHTML5で書くというのも手か？
・CSS3使ってもいいのかなあ
・関連商品の表示のために何をすればいいのか（DBに閲覧履歴を保持するのか？）
・他にも思いつき次第追記
・ここがわからないのであった
・twitterとかなのかな
まあ、作れないかもしれないけど、その時はその時。
最近は、女性向けの同人活動ということで、pixivをメインとした活動もされるようになった。pixivのランキングで女性向けのイラストが入っていたり、一部の方が大衆の不快にしてしまう行為をしてしまうけれど、女性向け同人として、pixivは同人活動においてなくてはならないものとなっている。pixivでの活動自体は、2年前ぐらいからはあったが、現在、さまざまなジャンルのアンソロジーの企画ページを見ると、参加者の一覧での参加者ページのリンクがpixivだけになっていることが多い。もう、同人活動のメインとして、pixivがメインなのだ。
実際、pixivはあくまでもSNSサイトであって、ホスティングサービスでないのは事実。Facebookを市のサイトとして全面移行しようとした佐賀県武雄市と同様に、腐女子がpixivを作品を展示できるホスティングサービスと勘違いしているのも事実。
もし、pixivがなくなったらどうなるんだろうか。一からHTMLを学んで、レンタルサーバーを借りて、ホームページを作ったり、FC2ブログで似非サイトを作ったりするんだろうか。
私自身、pixivは、信用できない企業だと思っている。画像データがIDCフロンティアのデータセンターから配信されているのはいいのだけれども、メインシステムがpixivのオフィス、つまり、データセンター向けでない普通のビルにあるらしい。何かpixivオフィスであれば、サービス停止ということもあり得るし、セキュリティ的にもよろしくない。pixivブログのサービスもそのうち停止してしまうらしいし、需要があるのかわからない「ショーケース機能」（有料で一定タグを宣伝できる）をリリースしたみたい。
これらから、pixivはWebサービス提供者として信用できない企業だと思う。ホスティングサービスとしてのpixivに期待する腐女子もあれだが。しかし、pixivには安定した運営と、利用者の声を反映した運営をお願いしたい。というか、現在のpixiv運営だと、コラージュ騒動のときと同様に、何かあったときにうまく収めることができるのかわからない。
どうにもこうにも親が機械の操作について、同じ事を何度も聞いてくることに苛立ってしまったからだ。
機械といっても、車のシフトチェンジなど分からなければできない操作ではなく、ディスプレイに専門用語ではない用語で丁寧に表示されている操作を、逐一毎回聞いてくるからだ。
おまえは日本語が読めないかと最初はバカにしていたが、話を聞くうちにそうではないということがわかった。
どうも失敗することができない操作と失敗してもリカバリーできる操作の区別がつかないらしい。
PCやAV系は失敗できない操作は普通最終確認をしてくることは、使える人はわかっているから、初めて使うソフトウェアやWEBサービス等を使うことが出来る。
その取り敢えず画面に従ってみるということが出来ないようだ。つまり表示を信用していない、いや信用できるか判別できない。
なんか聞いたことがある話かと思ったら、そうだ赤ちゃんのことだと気がついた。
赤ちゃんはチャレンジャーでなんでも真似してしまう。身体的に不可能なことでも、リカバリー出来ないことでも。
この場合、その模倣相手は画面表示だが、リカバリー不可能な操作をしてしまうことを恐れて逐一聞いてくるようだ。
ただ、赤ちゃんは親が見張ってくれるように、一般的にリカバリー不可能な操作は画面で警告してくれる。
まずはそこを教えるべきだったと反省している。
まとめ
ガチ無知というのは「HTMLとかの知識が全くない人」という意味です。他意はありません。
先日「WEBサービスを作りたい！」と思い立ったガチ無知の自分。まずHTMLから勉強した。そんな自分の理解を復習ついでにまとめてみる。
まあはてな界隈では少ないだろうけど、俺と同じガチ無知の人がいたら、HTML/CSSについてイメージが掴める、かも。間違ってたらごめんね。
HTMLをプログラミング言語みたいなもの？と思ってた人。（少なくとも俺はそうだった） 違います。
じゃあHTMLとは何か。文章を飾り付ける魔法だ。飾り付け。それ以上でもそれ以下でもない。
世の中には数多のサイトがある。数多のデザインがある。アレ全部文章の飾り付け。画像？Flash？飾り付けだ。
HTMLは、ずらっと文字だけが並んでるとページが見づらいからそれを見やすくする魔法。とりあえずそう認識しとこう。
HTMLは「文章を飾り付ける魔法」だ。じゃあ魔法を使うにはどうすればいい？
呪文を使うんだ。35まで純潔を貫き通す必要のないお手軽な魔法だ。
じゃあ呪文の使い方をば。
[呪文 飾り付けたい文章] ←これを
[呪飾り付けたい文章文] ←こう
そう、挟めばいい。HTMLは範囲指定魔法。だから効果範囲を呪文で挟む。以上。HTMLの使い方解説終了。
↓これは、文章を強調する呪文。
＜strong＞＜/strong＞
で、↓この文章の一部に魔法をかけよう
HTMLは、"HTML is Text Markup Language"の略です
これを、
＜strong＞HTML＜/strong＞は、"＜strong＞HTML＜/strong＞ is Text Markup Language"の略です
すると、
HTMLは、"HTML is Text Markup Language"の略です
こうなる、と。おしまい！
ここまででわかるだろうけど、俺の解説はものごっつい大雑把だ。
「呪文を強化する」 魔力を底上げするわけじゃない。魔導書は特定の呪文しか強化できない。
氷の魔導書を読むと、ヒャドは強化されるけど、メラは変化なし、みたいな話。
CSSと言う名の魔導書の書き方はこうだ。
強化する呪文名 { 強化内容 }
以上！
じゃあさっきHTMLの紹介で使った＜strong＞呪文を強化する魔導書をつくる。
strong {color: red;}
これは、strongに{color: red;}の効果を追加する魔導書。読んで字のごとく。色を赤にする追加効果。
さっきの飾り付けた文章が
HTMLは、"HTML is Text Markup Language"の略です
となる、と。呪文自体が強化されてるから両方赤になっている、と。
以上。終了。
さらっとメモ書きをするつもりが、すっげえ長々と書いてしまった。
まあインターネッツの大原則として、「間違ったことをドヤ顔で披露するとみんなに修正してもらえる」というのがあるので、このエントリもそういう役割を果たしてくれるんじゃないかな、、、
HTML4.0を勉強したんだけど、HTML4→HTML５の違いというのは、魔法を使う杖がランクアップしたようなもの、という認識でいいのかな？
というタイトルの記事をいつか書けるようになりたいなっ
ああっ、ちょっと待って。できるだけ多くの人の目に入ってくれたらと思ってやった出来心なんだよ。許して。
でもさ、HTML？ああ、ホームページビルダーで見たことある！レベルの人間なんだよ。
だからこの記事読んでも何を勉強すればいいのか皆目見当がつかない。HTMLやればいいのは間違いなさそうだけど。
でも俺は「完全に一致」みたいな検索システムが作りたいわけじゃない。
利用者が自分でページを作って、そこに人が集まってみたいなページがつくりたいんだ。ごめんよくわかんないよね。
Facebookの中のFacebookページの仕組みの部分だけをつくりたい、というのが一番近いかも。
ねえ、何を勉強すればいいと思う？こういうのはてなーの人なら詳しいと思って。
あ、待った！そうだよね、自分で何も調べずに教えてとか礼儀に欠けるよね。ちょっとタンマ。
==============================================================================================
よし、調べてきた。Ruby on RailsっていうのがWEBサービスを簡単に（？）作れるらしいですね。
でも、それが自分の作りたいものに適しているのかが分かりません。
少なくとも「完全に一致」の人はRoR(こう略すので正しいんだよね？)使ってないし。
だから、自分がこれからRoRを勉強するのが適策なのか、そうじゃないのかだけでも教えていただければ幸いです。
いや、ごめん、ホントはそんなことが聞きたかったんじゃないんだ。
本当は上記エントリでやる気になったけど、一人でスタートするのが寂しいから、誰かに「頑張れ」って言って欲しかっただけなんだよ。
かまってちゃんで申し訳ない。
Webサービスやアプリをつくって公開するのが好き。またブログもよく書く。その為、非プログラマーの人達にもよく知られているので”スーパープログラマー”のような評価で持ち上げられがちだが、プログラマーたちの評価はそれほど高くなくそのギャップに悩んでいる。よく起業する。
自分が使っているプログラミング言語(やエディタ)のライブラリを作って公開するのが好き。プログラミング活動が自己実現に直結したエコシステムも持っている。勉強会やオフ会によく行くので友達も多く、望んだ職場に出会えることが多い。延々とtwitter をやっている
大企業の製品の開発現場に生息する。業務の為に必要なプログラミングを学習したので目的に特化したスキルをもっている。その反面、自主的な学習意欲は少く体系的な知識がないので潰しがきかない。プログラミング以外が好き
todesking
はてなブックマークをご利用の皆様は、よろしければ以下の質問におこたえください。
質問は以上です。ありがとうございました。通常ですと粗品としてボールペンなどをあげるのですが、今回はそういった用意はしていません。
web：yahoo＞google＞楽天＞youtube＞ニコ動＞２ｃｈ＞mixi＞アメブロ＞はてな＞goo＞ライブドア＞facebook
yahoo＞楽天＞Twitter＞youtube＞２ｃｈ＞mixi＞アメブロ＞google＞ニコ動＞goo＞ライブドア＞はてな＞facebook
こんな感じだろ。
アメブロは有名人が良く使ってるし、２ｃｈは割かし話題に上る。
webサービスってくくりがでかすぎるな。
失敗を大目に見て問題ない事と、失敗が許されない事とを区別しようゼ。
自転車の練習とか個人が立ち上げる他愛ないwebサービスとか、そういうのは失敗を大目に見てなんの問題もない。
想定外を気にせず、誰もがどんどん失敗して失敗確率を下げればいい。
でも例えば原発で想定外はダメ。失敗した場合の影響がでかすぎて取り返しが付かないから。
人間がたくさんいる所で運用して簡単に失敗された日にゃ、命がいくつあっても足りない。経済的損失や環境的損失も甚大だ。
こういうのの場合は、実用までには被害を最小限に抑えて実験を繰り返すべきだし、
実用段階でも、あらゆる想定をして予防対策と発生時対策を取っておく必要がある。
いつものように増田への投げ売り堂の9月の結果と雑感を書き込みます。今日は長めになりそうで。
| 項目名 | 9月 | 8月 | 増減 |
|---|---|---|---|
| ユニークユーザー | 1983 | 690 | +1293 |
| ページビュー | 8777 | 3086 | +5691 |
| 平均ページビュー | 1.60 | 1.89 | -0.29 |
| 平均滞在時間 | 2.59 | 1.33 | +1.26 |
| 新規訪問数 | 29.90% | 31.79％ | -1.89％ |
詳細はいつものように以下の Analytics の PDF に書いてあります。
ごらんのとおり、アクセス数とユーザー数が伸びていますが、それ関連で色々やったこと。
リリース後にすぐに載せたんですが、そこまで効力が無く・・・。一回沈んだらそのままな感じなので仕方ない感じでしょうか。
これが一番やり方としてはダメですが、一番伸びた大きい要因でした・・・。
12日以降に定期的に投げ売り堂の URL をそれなりに関係があるかもしれないところに張って・・・。
申し訳ないと思いつつ、手っ取り早く広める。というのは素人にはやっぱりこれが一番なのかなと再確認をした感じです。
そもそも手っ取り早くな事を考えているのが甘いんですが。
今月の10/26から適応される、Amazon Product Advertising APIの仕様変更
の対策を全くメールを見てなかったので失念していて、ItemPage をガッツリ使っているこちらとしては、このままでは存続自体が危ない感じなので対策をしました。
まずはフィギュアだけなんですが、ItemSearch の際に KeyWords を使って複数検索をかけるように変更しました。
・「1/4」などのスケール
・「PVC」などの素材
これによって、ItemPage が400→10件に減らされても品揃えは遜色ないように出来ました。
DVD・BDとゲームもあるんですが、もう少し工夫をして今と同等にしようと思います。
しかし今回の API 仕様変更は困る人が多いんだろうなぁ・・・。
この辺で詳しくは述べてますが、料金は抑えることが出来そうです。
今月はサービスに直結する対策を色々とやりました。
サービスの拡張はやれなかったですが、存続の危機になりかねない事だったので色々と勉強になって結果良かったなーと思っています。
Webサービス始めるにあたって、特定個人や団体名に関する紛争に対してどういう対応をすればいいか思いつきで書いてみた。
もちろんこういったノイズに対してはできるだけ労力は割きたくない。
基本。ルール違反は即削除なり通報なりの対応をする。逆恨みとかされるのかな。
・IP開示請求に応じる
一定期間のアクセスログを取って、即時応じる。オプションとして、開示請求プロセスを公開することも考慮する。
・削除依頼に応じる
削除依頼を開示して、削除する。対象となる発言者に報告して、反論がなければ無条件に削除する。反論があれば削除依頼者に転送する。
・他人の書き込みに対する影響権限をユーザに与える
モデレート権限、サムズアップ、削除人制度など。これらはどちらかというとスパム排除や健全化に役立つ仕様だけど、紛争の開示と併せるとサービスの民主化にも役立ちそうな気がする。
・顕名化
実名制や、ID制で心理的な抑止効果を狙う。個人情報をちゃんと扱う気力があれば、携帯メールアドレス登録などのサブアカウント対策を行う。
んー、もっと大きな基本的な考えがあるんじゃないかなぁ。それは、「昔は、会社でないとできないことがたくさんあったけど、今はそうじゃない」ってこと。
昔は、「自分が作ったサービスを日本中、いや、世界中の人に紹介して使ってもらいたい」なんて思えば、会社の力を借りるしか無かった。個人で出来る範囲を遙かに超えるコストがかかるから。だからまず社内で「こういうことをやりたい」と企画して、お偉いさん達を説得することから始める。そして会社で開発して、会社で宣伝して、会社でサービス運用しないとダメだった。なので、どんなに「面白い人」も会社を辞めずに会社で仕事した。
でも今じゃ、Webサービスの開発やプロモーションくらい、全部個人でやろうと思えばできる時代。じゃぁ、どうして不自由さを感じてまで、わざわざ会社でやる必要があるの? 自分でやっちゃえばいいじゃん。ってなるのは当たり前。
私が感じた例で言うと、例えば海外のある国のある田舎町について直接現地住人に聞いて調べたいとする。昔ならまずそこの現地まで行って、そこの住民にコンタクトを取ってインタビューするまでに膨大なコストがかかり、気軽に個人でできるもんじゃなかった。でも今なら、Facebookでもなんでもいいけどそこに住んでいる人を見つけて、直接メールなりビデオチャットなりで頼んで聞いてしまえばいい。
そう、「個人でできる仕事」がとても大きくなっているんだ。
他の業界、例えば音楽業界なんかも。昔は、自分が作った曲を演奏して、それを日本中に届けたい……って思えば、もうレコード会社と契約する以外の選択肢は無かった。でも今じゃ、音楽やりたければmp3で自分でネット配信しちゃえばいい。CDを売りたければ、それこそ自分でCD-R焼いて自分で通販サイト作って売ってもいい。
結局、今の時代、会社が従業員に提供できるものって、もはや「電話受けてくれたり、事務書類や法律関係のお手伝いをしてくれて、仕事のためのインフラ環境を整えてくれる便利な事務所」としての機能しか無いのだ。ここがちゃんと分かっている会社も(日本には非常に稀だけど)確かにあって、そういう会社には優秀な人は居着いているよ。でも全く分かってない会社も(残念ながら)たくさんあって、そういう会社はいまだに「朝は9時出社」「社内からTwitter禁止」「10年は泥のように働け」ってなってるわけ。