  |
はてなキーワード: Gzipとは
CoreKeeper側で apt に依存しているっぽいので、Ubuntu でやった方が楽だと思います。
Ubuntu 20 TLS でやる場合、/home/steam/Steam/ が /home/steam/.steam/ になってたと思うので、環境に合わせて読み替えてください。
dpkg --add-architecture i386 add-apt-repository multiverse apt-get update apt-get dist-upgrade reboot
useradd -m steam passwd steam gpasswd -a steam sudo
sudo -u steam -s cd sudo apt install steamcmd ln -s /usr/games/steamcmd steamcmd ./steamcmd +login anonymous +app_update 1007 +app_update 1963720 +quit
cd ~/Steam/steamapps/common/Core\ Keeper\ Dedicated\ Server/ ./_launch.sh
Press Ctrl + C for Stop Core Keeper Dedicated Server
mkmir -p -m 775 /home/steam/.config/unity3d/Pugstorm/Core\ Keeper/DedicatedServer/worlds chown steam:steam /home/steam/.config/unity3d/Pugstorm/Core\ Keeper/DedicatedServer/worlds
Copy old world file (0.world.gzip) to
/home/steam/.config/unity3d/Pugstorm/Core\ Keeper/DedicatedServer/worlds
Copy old setting file (*.json) to
/home/steam/.config/unity3d/Pugstorm/Core\ Keeper/DedicatedServer/
chmod 664 /home/steam/.config/unity3d/Pugstorm/Core\ Keeper/DedicatedServer/worlds/0.world.gzip chmod 664 /home/steam/.config/unity3d/Pugstorm/Core\ Keeper/DedicatedServer/*.json
vi /etc/cron.hourly/corekeeper_backup #!/bin/bash cp -a /home/steam/.config/unity3d/Pugstorm/Core\ Keeper/DedicatedServer/worlds/0.world.gzip /home/steam/worldbackup/0.world.gzip.`date '+%Y%m%d%H%M%S'` cp -a /home/steam/Steam/steamapps/common/Core\ Keeper\ Dedicated\ Server/CoreKeeperServerLog.txt /home/steam/worldbackup/CoreKeeperServerLog.txt.`date '+%Y%m%d%H%M%S'` chmod 777 /etc/cron.hourly/corekeeper_backup sudo -u steam -s cd mkdir worldbackup
sudo -u steam -s cd ~/Steam/steamapps/common/Core\ Keeper\ Dedicated\ Server/ nohup ./_launch.sh tail -f ~/Steam/steamapps/common/Core\ Keeper\ Dedicated\ Server/CoreKeeperServerLog.txt
利用者の問題か、サーバーの問題かわかりませんが人数が10人超えると CPU4コア/メモリ4G/100Mbps で結構ラグかったです。
今は CPU6コア/メモリ8G/1000Mbps で動かしています。
６-８人以上で２-３時間サーバー動かしてると、Unityのライブラリがsegfault起こして、Core Keeper Dedicated Server が落ちます。
ログ取れたのでバグレポしましたが、改善するまでは不特定多数が好き勝手するサーバーみたいなのを長期運用するのは厳しいかなと思います。タイミングによってはアイテムロストしてしまうので。
なんで作る仕組みがないんだよ。
zlibやCommonCryptoはswift用のライブラリがないので、裏技的やり方でObjective-Cのライブラリを引っ張ってこないといけない。
zlibは何をどうやってもgzipしか作れないし、作ったgzipをCommonCryptoのAESで暗号化したら、今度はどうやっても解凍できないし。
あとzlibによる圧縮で、圧縮前の拡張子を覚えさせる手段が見つからなかったので、ファイル名に圧縮前の拡張子を含めさせておかないと、解凍後に手動で拡張子を追加しないといけない。
そりゃ、APIのドキュメントをくまなく読み込めば全て解決するんだろうけど、そんなコストは掛けられない。
だからなのか、ググってみると9割方SSZipArchive使えって記事が引っかかる。
あのさ、そういう目的特化で作られているんだから、使えば一瞬で目的達成できるのは分かるよ？
そこじゃないんだ。そしたらプラグインみたく必要なライブラリを入れまくって解決した気になるのは違うと思うし、それが無理なケースもあるんだよ。
そもそもの疑問として、タイトルに有る通り「暗号化zipを作りたいだけなのに」なんで最初から仕組みが用意されてないんだ。
大人向けのエンタメな動画をキュレーションするサイトを作ってみました。
18歳未満の人はみちゃだめです
このサイトはRailsで作ってherokuに乗せてみたんですが、いかんせん遅い。
もちろんherokuは札束で叩けばいくらでも早くなるんだけどそんなに予算もないし、そもそもそんなお金あったらこんなことしてない。
なのでどうにかしてお金を掛けずにサイトを高速化する方法を考えてたら1つアイデアが浮かんだのです。
それはサイト全体をCDNのCloudfrontに突っ込んでしまう事。
ルートドメインのDNS設定のCNAMEで、Cloudfrontのドメインを指定します。
そしてCloudfrontのオリジンをherokuのドメインに指定する。
こうすることでCSSとか画像ファイルだけでなく、HTMLも含めて全部のファイルをキャッシュすることができます。
そしてCloudfrontの設定で、HTMLファイルは10分とか1時間とか割と短めに設定して、
CSSとかJSとかは、Railsで作っているとMD5キャッシュが効いていて、勝手にキャッシュが無効化されるので、
1か月とかを指定すればよい。
効果としては、heroku単体でやるとHTMLファイルの応答が600msぐらいかかっていたのが、Cloudfrontでキャッシュさせると60msぐらいで帰ってくる。
もう超早い。10倍速い。
あとgzip配信したいので、gemでheroku-deflaterを入れる。
このgemはすごくて、herokuに乗っていると勝手にgzipに圧縮してくれる。
これによってCloudfrontの利用料を節約する。
僕のサイトの場合、このherokuのサーバーから配信しているのは、HTMLとCSSが1ファイルとあと画像が1つで合わせて10kBぐらいしかない。
こんだけだと、Cloudfrontの料金は100万PVでも1000円いかないぐらい。
herokuを札束で叩くのと違って、従量課金なのであらかじめ高いお金を払っておく必要もないし、
はてなは最近迷走している。ある調査だとアクセス数が落ちているという。アクセス数が増えないことを別の方法でカバーしようとまた余計なことをして顧客ばなれを招くという悪循環に陥っていると。新しいサービスは軒並み失敗中だ。
なぜか。それは顧客が求めているものを分析せず、表面的に考えているからだ。社員が顧客ではなくとなりの同僚の方をみて仕事をしているからだ。
それを表す顕著な事例があったので書かせてもらう。
http://emija.hatenablog.com/entry/2014/03/11/231940
はてなブログが遅いのはだいたいJavaScriptのせい
こんな記事があがった。
要点を絞るとこうだ
また、この情報に対する他の顧客から、minifyを実施するのは常識であって、なぜそれを行わないのかという指摘があった。
http://developer.hatenastaff.com/entry/2014/03/14/125131
また、この情報に対する他の顧客から、HACCPを取得しそれによって管理するのは常識であって、なぜ行わないのかと言う指摘があった。
それに対して
今回のはてなの対応で何か改善した事は何もない。元の顧客が感じた「遅い」という問題は解決していない。
はてなの中では「お前のせいで遅いのだろう」と言う汚名を返上できたと言う内々の評価はあろうかとおもうが、そんなものが顧客に何の関係があるのか。最大限評価してもこう言う的外れなクレームに晒された経験のある一部のニッチな同類技術者が多少の賛意を得られ、彼や彼女らの評価が若干上がる程度だ。
多くの人は重たいページに出会ったとき、その場で評価を決めて次に去ってしまう。そこで技術論をいくら述べてもほとんどの人間はそれに興味が無い。
クレームを上げてくれる人間などほんの僅かだ。さらに分析までしてくれるというのは顧客としてはその分析が多少間違いでも最優秀だろう。そこで自社のプライドを守るためだけの話に終始し、顧客の問題を放置するなど、一体何を考えているのか。
書くべきエントリーは
「はてなブログにおけるページ表示速度改善の取り組みについて」ではなく
「はてなブログの表示をより高速にするためのTips」であるべきだった。
内容はいきなり技術論から始め、顧客の推論を否定する等ではなく
「はてなブログは速度も最大限になるように努力しておりますが、ユーザの皆様の環境によっては読み込みが遅く感じる事もあると思います。読み込み速度を重視する皆様に、よくある速度を遅くする原因と、できるだけ快適にするためいくつかチェックするポイントをまとめました」
として
といった事をきちんと書き、顧客の「遅い」という問題の解決を図る。
そして最後に
「ご参考に、弊社ではできる限り高速なサービスを提供出来るよう、様々な工夫をおこなっています」
として、今回のこの「はてなブログにおけるページ表示速度改善の取り組みについて」エントリーの一部を掲示し、やんわりと顧客が推測したことは間違いだと否定する形にするべきだった。（当然ながら社内コストがかかるからやらないとか余計なことは書かない）
そして、今回のような説が広がったことが営業的にマイナスであると考えるのであれば、今後は誤解を与えないように誤解を与えた原因を修正する。（誤解する相手を変えることは不可能）
食品工場の例なら、客が不衛生な環境に置いたのが悪いのだというのではなくて、清潔で乾燥した場所に置けと言う事をやんわりと伝え、最後に自社の衛生環境に対する取り組みを伝えるべきだ。その後でまた誤解を受けないようにペンキ屋でもなんでも手配し、対外的に説明のしやすくなるHACCP認定取得を目指すという事になるだろう。
はてなはブクマガールズなど試験的なものをリリースしている。今度はニュースアプリにも参画しようという。これは従来のはてなユーザ以外にも顧客を広げたい意向があるのだろう。そうでなければ企業としての成長が難しいからだ。
確かにはてなはエンジニアの利用者が多い。だからはてなの内情を察知してくれ、技術の話をしたらそれにもきちんとついてきてくれる。しかし、今後もそんな優しいユーザだけ相手にするつもりなのか？彼らは技術の事を話をすれば、なるほどそれは仕方が無いと納得してくれるだろう。だが果たしてそんな姿勢で、顧客を増やせるのか？
はてなブックマークのデザイン改悪が実施された頃からいろいろとおかしくなった。それ以前はなによりベータ版を提供していたし、それによって得たフィードバックを反映していた。しかしそのあたりから指摘を受けると間違っていないと言う言い訳はするものの、顧客が困っていることについての解決策を示さなくなった。顧客が出すクレームよりも、となりにすわる同僚が同意してくれることを重視していないか？
もう一度考え直せ。このままでいいのか？
ユーザとしては全くよくない。いい加減しっかりしてくれ。
どうもわかってないな。
minifyは開発手法だとする意見。常識を理由にするのでは技術者失格だし、技術者じゃないのなら「もうちょっと周囲のコメント読んで」といった所。作り話（≠例え話）でないと対抗できない時点で勝負ありと思うがどうか
解決ではなくて「問題なし問題なし」と言い続ける奴らが回り回ってはてなを駄目にしてる。はてなを甘やかすなと言いたい。
そんなのは枝葉。
そういう技術論ばかりやって本当に客が必要だったものを用意できないのがはてなの最近の駄目さなんだよ
例えば、LINEが自社で使ってる技術をアピールする事で客を集めてるか？
もしLINEが技術をアピールする戦略をとったら、今のような形になれていたと思うか？
その上で"尖った"技術力がどんどん無くなっているのがはてなの現状。ベンチャー企業ってのはそういうもん。これは別に悪い事じゃない。ただそれ以外にウリを作り出せないとじり貧だろう。
http://anond.hatelabo.jp/20140315033741
実際に見て欲しいんだけど、そんなに広告多い？
具体的には分からない。
ただはてなは顧客から寄せられたクレームにおける推測部分を否定だけしたが、顧客が抱えている問題に対して答えを出していないのは確か。
そこに書いてあるようにはてなが言うべき回答例として挙げた部分は、例えばそういうことが言われているので書いた例程度に思ってくれ。
当然ながら、はてなはきちんと分析して回答するべき。顧客が投げてきた疑問を否定するためだけに無駄に時間を使う暇があるならできるはずだ。
http://anond.hatelabo.jp/20140315042727
http://emija.hatenablog.com/about
その人も技術者らしいんだけど
まさに天才的発想...違法プログラムを素数に変換した「違法素数」が話題に - Togetter
厨二設定的な名前も確かに魅力だけど、その背景にある暗号解読の美しさ、素数の美しさ、DeCSSの物語の美しさにぜひ目を向けて欲しくて、僕なりに必死に解説を考えた。
→DVDは暗号化されてるから、鍵を知ってる業者じゃないと再生プレイヤー作れないよ
→あるプログラムが、再生可能な鍵を、うっかり誰でも見れる状態で配布されちゃった
→それも公開したら違法と言われた
→k*256n+bが素数となるnとbを見つければ…
→素数マニアの雑誌（そんなんがあるのが美しい）に発表可能ｗｗｗ
→ktkr
→最初に見つかったのは、n=2、b=2083
→n=211、b=99、キタコレ
→素数マニアの雑誌で大ウケｗｗｗこんな素数みたことないｗｗｗ（ECPP法で証明された素数として10番目に大きな素数だった）
→しかもこの素数を、bで引き算した後nの乗算をなんとかして256で割り算した数字が…
→gzip展開するとDVD暗号解除プログラムになりまーすｗｗｗ司法乙ｗｗｗｗもう広まっちゃったｗｗｗｗ
流れとしてはこんな感じになりますかね。美しいですね。
ところどころ間違えてる箇所、端折ってる箇所ありますが、最終的に素数だけで酒が6杯は飲める変態が世の中にはいることが伝わればそれでいいです。
エロが好きです。
ボクはDMM.R18のヘビーユーザーなのですが、どうしても自分の好みの中だけで、グルグル回ってしまい、
世の中にAVは山ほどあるはずなのに、知らないなんてもったいない！もっとたくさんのエロに出会いたいという思いがあって日々悶々としていました。。
そんな中、AVというのは毎日の気分によってオナニーしたい見たいものが違うわけだから（例えば毎日食べたいおかずが違うように）、
今の自分の気分を簡単に答えれば、それに対してオススメのAV動画を紹介してくれるというサービスはどうだろう？とモヤモヤと考えていました。
ある日、会社の人に相談したら、それ「いいね！」ということになって、「そういえばDMMのAPIってのが公開されたから、それ使ってできるんじゃね？」ってことになり、
本格的にサービス開発を行うことになりました。
そしてこの度無事リリースすることができました。
「今夜のおかず」
３つの質問に YES / NO で答えるだけで、今のあなたに最適なアダルト動画を紹介するサービスです。
・フレームワーク：express（node.jsのフレームワーク）
・クライアント：jQuery、CoffeeScript、SCSS
・ビルドツール：grunt
node.jsは少し趣味でやった程度で、今回やってセッション管理やルーティング周りが勉強になりました。
データベースにはMySQLを使っています。node.jsならばmongoDBというイメージが強いですが、質問をランダムに表示する機能で、
mongoDBは現時点で正式な機能としてはランダム検索が出来なかったので、MySQLを選びました。
あと、CoffeeScriptやSCSSはJavaScriptやCSSの記法を簡単にしてくれるやつで、慣れてしまうと離れられません。
あとはTwitter Bootstrap。これなしでは生きていられません。
スマホでもなるべく早く結果ページまでたどり着けるようにしたつもりです。
オススメの動画が表示された後に、今日はこの動画の気分じゃない！と思ったときはチェンジボタンにより、同じ条件で他の動画にチェンジ！できます。
質問からやり直したいときは、さいしょから！ボタンで他の質問からやり直せます。
一刻一秒を争うエロビ探しですのでパフォーマンスには気を配りました。
最初はサーバーサイドでHTMLテンプレートを使わずに完全にREST API化して進めていましたが、
最初の表示までの若干のライムラグとSEO対策の為、最初の質問だけnode.jsでHTMLテンプレートを使用して組み立てています。
また、シンプルなサイトなのでライブラリはjQueryのみ使用し、concat/minify化はgruntのタスクとして登録しています。gzip化はNginxで行なっています。
我らがDMM様への敬意を払い、白ベース＋ポイントで赤のシンプルなデザインにしています。
・CSS（SCSS）が初めてだったので、微調整するのが大変でした。
・質問のパターンを考えるのと、紹介する動画が偏りすぎないようにするのが難しかったです。（これはまだ要調整）
・質問に対するおすすめ動画の精度をもっとあげていく。 （ユーザーの癖を把握して、機械学習とかできればいいかなと）
・おすすめ動画を表示した後に、その商品を誰かにつぶやいたり。
今回、同じ会社に勤めるエンジニア3人が約2ヶ月で作成しました。
実験的なサービスでもありますので、今後も色々と機能追加をしていくつもりです。
自動でマッチングしてチャット相手を見つけてくれるマッチングチャットや、すぐにチャット相手を見つけてくれるフリーチャット、コミュニティチャット、フレンドチャットなど、とにかくチャットがメインのSNSです。
■自分について
昨年の４月から、プログラムを学び始めた素人。２２歳。札幌在住。
FaceBookがウザい。というか嫌い。
これがきっかけ。
顔本が良いSNSだと話題になっていたので、実名登録してみた。大学の知り合いが見つけてくれて、友達登録などが増える。（ほとんど話したことがない人からも友達登録が来て、「おぉ！これで俺も友達が増えるんだ！」とワクワクしていた）。
が、流れてくるのは自慢ばっかり。
コミュ障で彼女はおろか、女友達もほとんどいない自分にとって顔本で「飲み会行ってきたぜウェーイw」とか、「○○ちゃんの誕生日会なう！」とか、「○○勉強会行ってきたました！ みんな熱い人ばっかりで最高！」とか書いてあるのを見て「こんなSNSは嫌だ……」と思った。
ようするに嫉妬です。
で、自分の好きなようにSNSを作ってみたいなぁ。と思いました。
自分の趣味がレトロゲーなので、自分と同じ趣味の人と話せたら素敵だな。ということでチャット式のSNSを思いつく。
が、Webサービスを独力でつくるのはこれがはじめて。というより、プログラム自体がはじめて。
案の定、前途多難だった。
そして私はアホだった。
■とにかく計画を立てる。
ざっくり、どんな機能が欲しいか考える。自分の力じゃ無理そうでもOK.とにかく妄想を爆発させる。
メッセージ機能、コミュニティ機能、あしあと機能、日記機能、コメント機能、つぶやき機能など。
コミニティ専用のチャットルーム、アカウント専用のプライベートチャットルーム（鍵をかけられる）、自動でチャットが開始されるフリーチャット、自分の指定した条件にあう人を自動で見つけてきてくれて、チャットができちゃうマッチングチャット。
などなど。
妄想するのは簡単だ。でも、全くわけがわからない。何から手をつけていいのかわからない。
「うはｗｗｗｗ これで勝つるｗｗｗ」と思ったけれど、どうやってチャット機能を追加して良いのかわからなかった。改変しようにも謎の記号がめちゃくちゃにならんでいてどうして良いかわからない。
しかも、改変したら改変したでそれを全世界に公開しなくちゃならないらしい（オープンソースというらしい）。
無理だ。
とにかくサーバーサイドの言語と、データベースについて勉強しろや！ とのことだった。
■使う言語について。
サーバーサイドを扱える言語はたくさんあって、PerlとかPHPとかPythonとかRubyとか色々あるらしいのだが、色々悩んだ結果
PHPにした。WebサービスならPHPが良いらしい。レンタルサーバーなどでも簡単に扱えるらしい。
後でPHPがクソ言語という話も聞いたが、とにかく最初に選んだのがPHPだったので。
・PHP
よくわかるPHPの教科書。http://www.amazon.co.jp/dp/4839933146/
MySQLとかについて一通り書いてあるので良かった。二週間くらいでなんとか全部こなした。xamppなども触って、ローカルサーバーで色々試した。
これが終わったら、
パーフェクトPHP http://www.amazon.co.jp/dp/4774144371/
パーフェクトって書いてあるから、パーフェクトなはずだと勝手に思い込む。
実際かなりすごい内容で、胃もたれ起こした。一ヶ月くらいで三回くらい読んで、大体のところを理解した。
フレームワークにCakePHPを使ったので、MVCについてのくわしい記述は大変参考になりました。
基礎からのMySQLで勉強。 http://www.amazon.co.jp/dp/4797344385/
最期に
ハイパフォーマンスMySQL http://www.amazon.co.jp/dp/4873114268/
とりあえず掲示板くらいはつくれるようになったので、チャットについてリサーチ。
ajaxとかよくわからん技術やnodejsを使った非同期処理などがあると知る。
nodejsはC10K問題という問題を解決するすごいものらしく、かっこいいらしいのでこれを勉強することに。
ついでにnodejsと相性の良い、mongoDBも勉強することに。
よくわかるjavascript http://www.amazon.co.jp/dp/4839941874/
終わったら、
パーフェクトjavascript http://www.amazon.co.jp//dp/477414813X/
パーフェクトjavascriptはnodejsについてものすごく詳しく書いてあったので、とても参考になった。このあたりで、LINUXというOSを扱わなくてはいけないと気付き、自宅PCをウィンドウズから、LINUX（ubuntu)に変えた。
これはとにかく触ってなんぼでした。MySQLと感覚が違い、苦労しました。
https://github.com/ichikaway/cakephp-mongodb
という素晴らしいものを利用させていただきました。
■このへんで一回限界がきた。
なんとなくnodejsを扱うこともできるようになり、それなりに楽しいと思ってはいたものの、「SNS作ったる！」と思ってから六ヶ月以上が経過していた。
さらにWebサービスを公開するにはデザインもそれなりにしなくてはいけないらしく、CSSなどについて勉強しなくてはいけないと知る。
一人でWebサービス作ってる「ゆーすけべー」さんとかすごいなと思った。
勘違いサブカル野郎だと思っていた「家入一真」とかもやっぱりすごい人なんだと思った。
自分はなんもできないなぁ。と痛感した。
で、悩んでても仕方ないので、デザインはバッサリあきらめることにした。
もうなんでもかんでもやるのは無理なので、捨てるものは捨てることにした。
基本的に Initializr http://www.initializr.com/ （テンプレートエンジン）
と
TwitterBootStrap http://twitter.github.com/bootstrap/ （Twitterっぽい今時な感じのデザインが簡単に使える）
を使うことに。
でも、これだとまさにTwitterそのまんまっぽかってので、
http://bootswatch.com/ （きれいなデザインテンプレートがあるサイト）
も使うことに。デザインについてはこれだけ。
無理はしないことに。
■大体できたら、あとはセキュリティ。
セキュリティは大事。自分のサイトでは一応、登録制なのでフリーメールアドレスなどを預かる。これは流出させたら困るし、なによりユーザー様が安心して使えないなんてだめなので。
これにはかなり注意したつもりです。
まず基本的なことは 『体系的に学ぶ 安全なウェブアプリケーションの作りかた』 http://www.amazon.co.jp/dp/4797361190/
で勉強。
本番環境に公開する前には グーグル先生が公開している skipfishというツールでチェックをしたり、
Dos攻撃対策に、
http://up-point-server.info/?p=54
などに書いてある
mod_dosdetector などを利用。
これははてなさんが公開しているものです。この場を借りて感謝します。ありがとうございます！
あとはSSHへのブルートフォースを防ぐために、DenyHostというツールを利用するなどした。
クラウドサービスを利用しているので大丈夫だとは思うのですが、一応rsyncコマンドでバックアップを定期的にとることに。
サーバー上の別の場所にGzipで保存し、それを自宅サーバーのCentOSで保存するという形式です。深夜にcronで自動的に実行しています。
参考サイトは、
http://mukaer.com/archives/2012/03/14/vpscentos/
です。
■パフォーマンス向上のために少しだけ
はじめはサーバーはapacheだけだったのですが、今は画像ファイルなどはNginｘというサーバーを使うのが良いそうなので、Nginxを使いました。
あとはPHPの中間キャッシュを利用するAPCなども利用することに。
このへんについては、
このような解説記事がたくさんあったので、参考にさせていただきました。
■ようやく完成。
で、なんとか完成しました。
使ってみた感想や、ダメ出しなど頂ければ狂喜乱舞します。よろしくお願い致します。
■モチベーションを維持するためにやったこと。
あっさりと書きましたが、実際は失敗の連続でやる気が萎えてばっかりでした。
疲れて帰ってきて、なにもやる気の起きない時もありました。
そういう時は、とにかくサポートページのQ&Aの1文でも良いから書いてみるとか、とにかくパソコンとエディターだけ立ちあげてみるとか、していました。
ものすごーく覇気のない目でキーボード打ち続けていましたが、それでもなんとか完成することができました。惰性だろうとなんだろうと、少しずつは進むのだとわかりました。
やはり１から完全自作をするのは無謀だった。でも、プログラムをやったことのない素人でも約一年頑張ればそれなりのSNSもどきを作ることができた。
これも先人たちの作ってくれたフレームワークや様々なツール、そして参考書などのおかげ。
私のようなアホでも頭の良い人の力を借りればなんとかなりました。ありがとうございます！
そしてプログラムは一人でも出来るので、私のように非コミュでも楽しめる素晴らしい趣味である。
■現在。
今はRubyに夢中です。くり返し処理がすごくきれいにかけるので素敵な言語だと思っています。あと、javascriptも面白いので毎日いじくって遊んでいます。PHPももちろん触っています。
非コミュはあいかわらずですが、プログラムが楽しいので前より幸せです。
使用言語 PHP,Javascript
SmartNewsで炎上マーケティングが大成功しているみたいで、株式会社ゴクロのみなさんは本当におめでとうございます。
SmartNews事件の擁護派・反対派まとめ - NAVER まとめ
こちらに今回の事件の「擁護派」「反対派」がまとめられていますが、擁護派からは「タダ乗り」に対する「感情の問題」みたいな言説が目立ちます。別にタダ乗りだとかそういう話ではなくて、株式会社ゴクロは単に違法行為を行なっているというだけの話です。
に記されているように、「レスポンスとしてニュースデータ（ヘッドラインと"キャッシュ"を含めたもの）がgzip圧縮され」て、SmartNewsのサーバーから返ってきます。このとき、"キャッシュ"は広告などが抜かれ、改変された状態で送られてくるので、(ゴクロが)キャッシュと称するのは不自然です。
「他人の著作物を、株式会社ゴクロのサーバーで広告を削除した上、全文を転送する」という行為は、明らかに悪質なもので、著作権者の利益を侵害していると言われてもおかしくありません。
に記されているように、PocketもSmartNewsと同じ仕組みを使っています。しかし問題とならないのは、そもそも登記している国が違うからです。
「フェアユース」という抽象的な方法を取る米国と、「私的複製」などの具体的な例外条項を取る日本では、比較するのはナンセンスです。
結論は、株式会社ゴクロの行なっていることは著作権の侵害である可能性が高い。Pocketの行なっていることも著作権の侵害であるが、国が違うので比較対象としては間違っている。ということです。
しかしながら、「Pocketにタダ乗りされたんだけど、、、」といった話は聞いたことがありません。法律上ではどうなっていても、感情的な問題として、Pocketへの批判はなかなかないでしょう。
現状では「違法性の高い」ということしか言えません。コンテンツパブリッシャーが株式会社ゴクロを訴え、判例を作って白黒はっきりつけていただきたいです。
「Pocketが良くてSmartNewsがダメな理由」は、法律に原因があります。ぜひともフェアユースを日本に導入するというのが良いかと思います。しかし、フェアユースを前提として訴訟の手続きが粛々と取られるというだけの話なので、過度な期待はしないでいただきたいです。
「法律的に問題ない仕組み」というのは、アプリ側で加工せよ、という話ではありません。そんなことをしても違法性が弱まるだけで、炎上し、粛々と訴訟の手続きが取られるだけです。「全文転載をやめる」「ユーザーの能動性を高める」という２つの対策を取り、「感情的な落とし所」をつけるのが良い対策だと考えられます。
どうしたんかいな、とネットワークトレースをとってみた。そしたら、トップ画面の要求に対してこんな応答が返っていた。
GET / HTTP/1.1 Host: www.yodobashi.com Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: ja,en-us;q=0.7,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: Shift_JIS,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive HTTP/1.1 200 OK Date: Wed, 29 Oct 2008 02:02:31 GMT Server: Apache Pragma: no-cache Cache-Control: private Expires: -1 Set-Cookie: JSESSIONID=FAE13F42154EB566479E047B57CBF2EA; Path=/cs Set-Cookie: SS_X_JSESSIONID=AFA6E52B61BCC8A2C2704B1F60B98B6A; Path=/ Set-Cookie: SS_X_JSESSIONID=AFA6E52B61BCC8A2C2704B1F60B98B6A; Path=/ Set-Cookie: SS_X_JSESSIONID=AFA6E52B61BCC8A2C2704B1F60B98B6A; Path=/ Set-Cookie: SS_X_JSESSIONID=AFA6E52B61BCC8A2C2704B1F60B98B6A; Path=/ Set-Cookie: SS_X_JSESSIONID=AFA6E52B61BCC8A2C2704B1F60B98B6A; Path=/ Set-Cookie: SS_X_JSESSIONID=AFA6E52B61BCC8A2C2704B1F60B98B6A; Path=/ Set-Cookie: SS_X_JSESSIONID=AFA6E52B61BCC8A2C2704B1F60B98B6A; Path=/ Set-Cookie: SS_X_JSESSIONID=AFA6E52B61BCC8A2C2704B1F60B98B6A; Path=/ Set-Cookie: SS_X_JSESSIONID=AFA6E52B61BCC8A2C2704B1F60B98B6A; Path=/ Set-Cookie: BIGipServerPool_www_yodobashi_com_cms=1258399936.20480.0000; path=/ Content-Length: 83878 Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Content-Type: text/html;charset=Windows-31J
えーと。どこから突っ込んでいいのやら。
システムの機械語レベルの挙動を意識するとどういうところが気になるようになるか、それを現代の環境ではどう教えるか、という点が問題でしょうね。
・メモリやレジスタ幅(桁数)と情報の規模の関係を意識する - まあ、Oracle は 64bit OS で使えとか、xfs を 32bit OS で使うと(atomic な部分の更新が泣き別れになって)クラッシュの危険が高いとか
・API 仕様を意識する - 上の例の続きだけど、パッチのあたってない古い gzip で 2Gbytes 以上のファイルが圧縮できないとか
・コードを展開した結果、関数の出入りやインタフェースでどう膨れ上がるか、リソースの解放がどれだけ無意味になりうるかを知っている - C++ とかの場合。Tomcat もクラスロード(とリソースの確保も -- 追記)で1時間待たされるとかくだらないことが起こるけど、開発効率と運用のトレードオフだからなぁ
・(Ruby, PHP, Java などの)VMに頼るべきでない場合が何かを知っている - 速度もだけど、VMがバグ持ちの場合、デバッグが困難を極めることもある
・ビット操作系のコードを書けないと困る - まあ、ioctl や fnctl で苦労したことがあればどういうものかは判ると思うけど
・(追記)strace とか ldd とかくらい言われる前にやってほしい - 実際 Java と PHP しか知らないと本当にこの辺はできない
・(追記)497(×10^-n)日で落ちた、と言われた瞬間にカーネルのバグを疑ってほしい - lbolt 溢れ系のバグは本当にありふれている
いまどきは障害対応系の運用をやったほうがプログラマとしてコード書くよりもこの辺の問題に詳しくなれる気がします。
追記：「こういうこともわからん子供たち」をうまく使って利益を上げる会社と、「こういうこともわからん子供たち」を教えるのにフラストレーションを感じるハッカーがひとりで回している会社、どっちが上記のようなことを学びやすいかというのは難しいところです。SUSv3 (昔のオライリーの POSIX 本でもいいけど)を面白いと思えない人に正直あまり細かいことを学べるとは思えないし‥
