「gzip」を含む日記 RSS

はてなキーワード: gzipとは

2022-06-27

Core Keeper Dedicated Server を VPS 上に構築したときの手順メモ

Ubuntu 22.04 LTS x86_64 で構築。

CoreKeeper側で apt依存しているっぽいので、Ubuntu でやった方が楽だと思います

Tips

Ubuntu 20 TLS でやる場合、/home/steam/Steam/ が /home/steam/.steam/ になってたと思うので、環境に合わせて読み替えてください。

Install steamcmd dependent packages

dpkg --add-architecture i386
add-apt-repository multiverse
apt-get update
apt-get dist-upgrade
reboot

Create steamcmd User

useradd -m steam
passwd steam
gpasswd -a steam sudo

Steamcmd / Core Keeper Dedicated Server Install

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

Run steamcmd (Install and Creating Core Keeper Dedicated Server system drectory )

cd ~/Steam/steamapps/common/Core\ Keeper\ Dedicated\ Server/
./_launch.sh

Press Ctrl + C for Stop Core Keeper Dedicated Server

World file migration (if there is an old file)

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

Backup setting

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

Start Core Keeper Dedicated Server

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 で動かしています

不具合 (2022/06/28時点)

6-8人以上で2-3時間サーバー動かしてると、Unityライブラリがsegfault起こして、Core Keeper Dedicated Server が落ちます

ログ取れたのでバグレポしましたが、改善するまでは不特定多数が好き勝手するサーバーみたいなのを長期運用するのは厳しいかなと思いますタイミングによってはアイテムロストしてしまうので。

遊びで使うなら、ウォッチドック的なサービスを入れて、落ちたら適宜起動しなおすみたいな対応をした方がよいと思います

2020-03-15

金毘由他用語

sudo 須藤

su

chown 趙雲

mkdir 椋鳥

which 魔女

cat 猫

vi

zip 実父

gzip 爺実父

gunzip 眼実父

cron 九龍

ubuntu文通

golang 呉蘭

python 牌遜

java 邪馬

heroku 平六

github 岐阜羽生

jenkins 漸近主

docker 独歌

2018-07-09

anond:20180709082514

その人は本来UNIX 使いで、ziptar.gz なんだろう。

tar で固めてから gzip圧縮して」と等価作業を「(zipで)固めて」と言っている可能性がある。

2018-07-05

swift暗号化zipを作りたいだけなのに

なんで作る仕組みがないんだよ。

zlibやCommonCryptoはswift用のライブラリがないので、裏技的やり方でObjective-Cライブラリを引っ張ってこないといけない。

しかもそんな面倒は序の口で、本当に面倒なのはそこから

zlibは何をどうやってもgzipしか作れないし、作ったgzipをCommonCryptoのAES暗号化したら、今度はどうやっても解凍できないし。

あとzlibによる圧縮で、圧縮前の拡張子を覚えさせる手段が見つからなかったので、ファイル名に圧縮前の拡張子を含めさせておかないと、解凍後に手動で拡張子を追加しないといけない。

そりゃ、APIドキュメントをくまなく読み込めば全て解決するんだろうけど、そんなコストは掛けられない。

要するに並のプログラマの手には負えなさそうな話という結論


からなのか、ググってみると9割方SSZipArchive使えって記事が引っかかる。

あのさ、そういう目的特化で作られているんだから、使えば一瞬で目的達成できるのは分かるよ?

そこじゃないんだ。そしたらプラグインみたく必要ライブラリを入れまくって解決した気になるのは違うと思うし、それが無理なケースもあるんだよ。

そもそもの疑問として、タイトルに有る通り「暗号化zipを作りたいだけなのに」なんで最初から仕組みが用意されてないんだ。


あれか、Apple的にはswift暗号化zipを作る時代じゃないと、そういう見解なのだろうか。

2017-06-18

https://anond.hatelabo.jp/20170618103253

Javascriptは死んでほしいと思っているので詳しくないんだがgzipかける前提ならミニファイソフト変数をi,ii,iii,iiii,iiiiiみたいにするんだろうか・・・

(もちろんするとしても通信経路で最も小さくなるようにするかテーブル作るときに最も小さくなるようするかオプションで選べるとは思うが)

2017-05-02

http://anond.hatelabo.jp/20170501041533

レスポンスヘッダー抜粋

Cache-Control:no-store, no-cache, must-revalidate

Connection:keep-alive

Content-Encoding:gzip

Content-Type:text/html; charset=UTF-8

Pragma:no-cache

Server:cloudflare-nginx

Set-Cookie:CAKEPHP=xxxx

X-Powered-By:PHP/7.0.18

2015-11-01

いい感じの動画紹介サイトを作って、高速化した話

作ったもの

大人向けのエンタメ動画キュレーションするサイトを作ってみました。

18歳未満の人はみちゃだめです

http://videovdo.com/

高速化の話

このサイト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配信したいので、gemheroku-deflaterを入れる。

このgemはすごくて、herokuに乗っていると勝手gzip圧縮してくれる。

これによってCloudfrontの利用料を節約する。

料金

僕のサイト場合、このherokuサーバーから配信しているのは、HTMLCSSが1ファイルとあと画像が1つで合わせて10kBぐらいしかない。

こんだけだと、Cloudfrontの料金は100万PVでも1000円いかないぐらい。

heroku札束で叩くのと違って、従量課金なのであらかじめ高いお金を払っておく必要もないし、

100万PV1000円ならまあ割と現実的価格なので、当分の間はこれで運営していこうかと思う。

2014-03-14

はてブロJavaScript問題にみるはてなの駄目さ 顧客が抱える問題放置

はてな最近迷走している。ある調査だとアクセス数が落ちているという。アクセス数が増えないことを別の方法カバーしようとまた余計なことをして顧客ばなれを招くという悪循環に陥っていると。新しいサービスは軒並み失敗中だ。

なぜか。それは顧客が求めているもの分析せず、表面的に考えているからだ。社員顧客ではなくとなりの同僚の方をみて仕事をしているからだ。

それを表す顕著な事例があったので書かせてもらう。

経緯を整理する

http://emija.hatenablog.com/entry/2014/03/11/231940

はてなブログが遅いのはだいたいJavaScriptのせい

こんな記事があがった。

要点を絞るとこうだ

  • はてなブログが重たい・遅い
  • 独自に調査してみたところ、Javascriptを切ったら早くなった
  • どのJavascroptが悪いのか確認したところ、はてなコードが目についた
  • 妙なコメントがついているし、容量が大きい。これが原因ではないか。改善を求める。

また、この情報に対する他の顧客から、minifyを実施するのは常識であって、なぜそれを行わないのかという指摘があった。

それに対してはてな側の対応はこう。

http://developer.hatenastaff.com/entry/2014/03/14/125131

はてなブログにおけるページ表示速度改善の取り組みについて

もしはてな食品製造会社だったら?

また、この情報に対する他の顧客からHACCPを取得しそれによって管理するのは常識であって、なぜ行わないのかと言う指摘があった。

それに対して

はてな対応問題点

今回のはてな対応で何か改善した事は何もない。元の顧客が感じた「遅い」という問題は解決していない

はてなの中では「お前のせいで遅いのだろう」と言う汚名を返上できたと言う内々の評価はあろうかとおもうが、そんなもの顧客に何の関係があるのか。最大限評価してもこう言う的外れクレームに晒された経験のある一部のニッチな同類技術者が多少の賛意を得られ、彼や彼女らの評価が若干上がる程度だ。

多くの人は重たいページに出会ったとき、その場で評価を決めて次に去ってしまう。そこで技術論をいくら述べてもほとんどの人間はそれに興味が無い。

クレームを上げてくれる人間などほんの僅かだ。さら分析までしてくれるというのは顧客としてはその分析が多少間違いでも最優秀だろう。そこで自社のプライドを守るためだけの話に終始し、顧客の問題を放置するなど、一体何を考えているのか。

はてなはどうするべきだったか

書くべきエントリー

はてなブログにおけるページ表示速度改善の取り組みについて」ではなく

はてなブログの表示をより高速にするためのTipsであるべきだった

内容はいきなり技術から始め、顧客の推論を否定する等ではなく

はてなブログは速度も最大限になるように努力しておりますが、ユーザの皆様の環境によっては読み込みが遅く感じる事もあると思います。読み込み速度を重視する皆様に、よくある速度を遅くする原因と、できるだけ快適にするためいくつかチェックするポイントをまとめました」

として

といった事をきちんと書き、顧客の「遅い」という問題の解決を図る。

そして最後

「ご参考に、弊社ではできる限り高速なサービス提供出来るよう、様々な工夫をおこなっています

として、今回のこの「はてなブログにおけるページ表示速度改善の取り組みについて」エントリーの一部を掲示し、やんわりと顧客が推測したことは間違いだと否定する形にするべきだった。(当然ながら社内コストがかかるからやらないとか余計なことは書かない)

そして、今回のような説が広がったことが営業的にマイナスであると考えるのであれば、今後は誤解を与えないように誤解を与えた原因を修正する。(誤解する相手を変えることは不可能)

食品工場の例なら、客が不衛生な環境に置いたのが悪いのだというのではなくて、清潔で乾燥した場所に置けと言う事をやんわりと伝え、最後に自社の衛生環境に対する取り組みを伝えるべきだ。その後でまた誤解を受けないようにペンキ屋でもなんでも手配し、対外的に説明のしやすくなるHACCP認定取得を目指すという事になるだろう。

はてなユーザをちゃんと見ているのか

はてなブクマガールズなど試験的なものリリースしている。今度はニュースアプリにも参画しようという。これは従来のはてなユーザ以外にも顧客を広げたい意向があるのだろう。そうでなければ企業としての成長が難しいからだ。

確かにはてなエンジニア利用者が多い。だからはてなの内情を察知してくれ、技術の話をしたらそれにもきちんとついてきてくれる。しかし、今後もそんな優しいユーザだけ相手にするつもりなのか?彼らは技術の事を話をすれば、なるほどそれは仕方が無いと納得してくれるだろう。だが果たしてそんな姿勢で、顧客を増やせるのか?

はてなブックマークデザイン改悪実施された頃からいろいろとおかしくなった。それ以前はなによりベータ版提供していたし、それによって得たフィードバックを反映していた。しかしそのあたりから指摘を受けると間違っていないと言う言い訳はするものの、顧客が困っていることについての解決策を示さなくなった。顧客が出すクレームよりも、となりにすわる同僚が同意してくれることを重視していないか?

もう一度考え直せ。このままでいいのか?

ユーザとしては全くよくない。いい加減しっかりしてくれ。

追記

どうもわかってないな。

b:id:pmint

minifyは開発手法だとする意見常識を理由にするのでは技術者失格だし、技術者じゃないのなら「もうちょっと周囲のコメント読んで」といった所。作り話(≠例え話)でないと対抗できない時点で勝負ありと思うがどうか

http://b.hatena.ne.jp/pmint/20140315#bookmark-186417446

  • だれもminifyをしろと言う意見を書いてない。対応が全くなってないと言う話をしている
  • 技術者合格しなけりゃはてなユーザにはなれないのか?
  • 問題を作り話だとレッテルを貼っても問題は変わらない。対抗などしていない。
  • そもそも、客と勝負してどうするんだって話をしてるのに、勝負有りとかなしとか。その視点をまず捨てろ

解決ではなくて「問題なし問題なし」と言い続ける奴らが回り回ってはてなを駄目にしてる。はてなを甘やかすなと言いたい。

http://anond.hatelabo.jp/20140314173959

そんなのは枝葉。

そういう技術論ばかりやって本当に客が必要だったものを用意できないのがはてな最近の駄目さなんだよ

例えば、LINEが自社で使ってる技術をアピールする事で客を集めてるか?

もしLINE技術をアピールする戦略をとったら、今のような形になれていたと思うか?

その上で"尖った"技術力がどんどん無くなっているのがはてなの現状。ベンチャー企業ってのはそういうもん。これは別に悪い事じゃない。ただそれ以外にウリを作り出せないとじり貧だろう。

http://anond.hatelabo.jp/20140315033741

実際に見て欲しいんだけど、そんなに広告多い?

http://emija.hatenablog.com/entry/2014/03/11/231940

具体的には分からない。

ただはてな顧客から寄せられたクレームにおける推測部分を否定だけしたが、顧客が抱えている問題に対して答えを出していないのは確か。

そこに書いてあるようにはてなが言うべき回答例として挙げた部分は、例えばそういうことが言われているので書いた例程度に思ってくれ。

当然ながら、はてなはきちんと分析して回答するべき。顧客が投げてきた疑問を否定するためだけに無駄時間を使う暇があるならできるはずだ。

http://anond.hatelabo.jp/20140315042727

http://emija.hatenablog.com/about

その人も技術者らしいんだけど

技術者である前に、そいつ顧客だ。はてなはまずはそう扱うべきだろ。

2013-07-23

違法素数

まさに天才的発想...違法プログラムを素数に変換した「違法素数」が話題に - Togetter

違法素数 - Wikipedia

今日は一日、違法素数に沸いたのがモヤモヤした。

厨二設定的な名前も確かに魅力だけど、その背景にある暗号解読の美しさ、素数の美しさ、DeCSSの物語の美しさにぜひ目を向けて欲しくて、僕なりに必死に解説を考えた。

DVD暗号化されてるから、鍵を知ってる業者じゃないと再生プレイヤー作れないよ

→あるプログラムが、再生可能な鍵を、うっかり誰でも見れる状態で配布されちゃった

→それを10代の男の子発見して祭り状態に

DVD再生し放題。リッピングし放題祭り開催

DVD暗号解除プログラムの公開が違法と判断された

プログラム10進数数字に変換してやれ

→それも公開したら違法と言われた

→k*256n+bが素数となるnとbを見つければ…

素数マニア雑誌(そんなんがあるのが美しい)に発表可能www

ktkr

最初に見つかったのは、n=2、b=2083

→こんなしょぼい素数では、素数マニアは納得しない

→n=211、b=99、キタコレ

素数マニア雑誌で大ウケwwwこんな素数みたことないwww(ECPP法で証明された素数として10番目に大きな素数だった)

しかもこの素数を、bで引き算した後nの乗算をなんとかして256で割り算した数字が…

gzip展開するとDVD暗号解除プログラムになりまーすwww司法乙wwwwもう広まっちゃったwwww

流れとしてはこんな感じになりますかね。美しいですね。

ところどころ間違えてる箇所、端折ってる箇所ありますが、最終的に素数だけで酒が6杯は飲める変態が世の中にはいることが伝わればそれでいいです。

2013-03-03

DMM APInode.jsで今の気分に最適なエロ動画紹介サービスをつくってみた

作成の経緯

エロが好きです。

ボクはDMM.R18のヘビーユーザーなのですが、どうしても自分の好みの中だけで、グルグル回ってしまい、

世の中にAVは山ほどあるはずなのに、知らないなんてもったいないもっとたくさんのエロ出会いたいという思いがあって日々悶々としていました。。

そんな中、AVというのは毎日の気分によってオナニーしたい見たいものが違うわけだから(例えば毎日食べたいおかずが違うように)、

今の自分の気分を簡単に答えれば、それに対してオススメAV動画を紹介してくれるというサービスはどうだろう?とモヤモヤと考えていました。

ある日、会社の人に相談したら、それ「いいね!」ということになって、「そういえばDMMAPIってのが公開されたから、それ使ってできるんじゃね?」ってことになり、

本格的にサービス開発を行うことになりました。

そしてこの度無事リリースすることができました。

作成したサイト

「今夜のおかず」

http://okazunight.com/

つの質問YES / NO で答えるだけで、今のあなたに最適なアダルト動画を紹介するサービスです。

使ってる技術

サーバーサイド:node.js

フレームワークexpressnode.jsフレームワーク

CSSフレームワークTwitter Bootstrap

クライアントjQueryCoffeeScriptSCSS

データベースMySQL

ビルドツール:grunt

バージョン管理GitHubプライベート

HTTPサーバNginx

インフラ:某クラウドサービス

node.jsは少し趣味でやった程度で、今回やってセッション管理ルーティング周りが勉強になりました。

データベースにはMySQLを使っていますnode.jsならばmongoDBというイメージが強いですが、質問ランダムに表示する機能で、

mongoDBは現時点で正式な機能としてはランダム検索が出来なかったので、MySQLを選びました。

あと、CoffeeScriptSCSSJavaScriptCSS記法を簡単にしてくれるやつで、慣れてしまうと離れられません。

あとはTwitter Bootstrap。これなしでは生きていられません。

こだわった点

    スマホでもなるべく早く結果ページまでたどり着けるようにしたつもりです。

    オススメ動画が表示された後に、今日はこの動画の気分じゃない!と思ったときチェンジボタンにより、同じ条件で他の動画チェンジ!できます

    質問からやり直したいときは、さいしょからボタンで他の質問からやり直せます

    一刻一秒を争うエロビ探しですのでパフォーマンスには気を配りました。

    最初サーバーサイドでHTMLテンプレートを使わずに完全にREST API化して進めていましたが、

    最初の表示までの若干のライムラグSEO対策の為、最初質問だけnode.jsHTMLテンプレートを使用して組み立てています

    また、シンプルサイトなのでライブラリjQueryのみ使用し、concat/minify化はgruntのタスクとして登録していますgzip化はNginxで行なっています

    我らがDMM様への敬意を払い、白ベースポイントで赤のシンプルデザインにしています

    苦労した点

    CSSSCSS)が初めてだったので、微調整するのが大変でした。

    質問パターンを考えるのと、紹介する動画が偏りすぎないようにするのが難しかったです。(これはまだ要調整)

    今後の展開(たぶん)

    質問に対するおすすめ動画の精度をもっとあげていく。 (ユーザーの癖を把握して、機械学習とかできればいいかなと)

    おすすめ動画を表示した後に、その商品を誰かにつぶやいたり。

    ・結果を自分お気に入りとして保存できたり。

    ユーザーからフィードバック。(これ早めに)

    最後

    今回、同じ会社に勤めるエンジニア3人が約2ヶ月で作成しました。

    実験的なサービスでもありますので、今後も色々と機能追加をしていくつもりです。


    それでは、今夜もあなたが美味しいおかずに出会ますように。

    http://okazunight.com/

    2013-01-04

    素人が完全自作SNSを作ってみてわかったこと。

    ひっそりと、Webサービスリリースしました

    http://tag-chat.net

    で、チャットがメインのSNSです。

    自動マッチングしてチャット相手を見つけてくれるマッチングチャットや、すぐにチャット相手を見つけてくれるフリーチャットコミュニティチャット、フレンドチャットなど、とにかくチャットがメインのSNSです。





    自分について

    昨年の4月からプログラムを学び始めた素人。22歳。札幌在住。





    ■今更SNSを作ろうと思ったきっか

    FaceBookがウザい。というか嫌い。

    これがきっかけ。

    顔本が良いSNSだと話題になっていたので、実名登録してみた。大学の知り合いが見つけてくれて、友達登録などが増える。(ほとんど話したことがない人から友達登録が来て、「おぉ!これで俺も友達が増えるんだ!」とワクワクしていた)。

    が、流れてくるのは自慢ばっかり。

    コミュ障彼女はおろか、女友達ほとんどいない自分にとって顔本で「飲み会行ってきたぜウェーイw」とか、「○○ちゃんの誕生日なう!」とか、「○○勉強会行ってきたました! みんな熱い人ばっかりで最高!」とか書いてあるのを見て「こんなSNSは嫌だ……」と思った。


    ようするに嫉妬です。

    で、自分の好きなようにSNS作ってみたいなぁ。と思いました。

    自分趣味レトロゲーなので、自分と同じ趣味の人と話せたら素敵だな。ということでチャット式のSNSを思いつく。

    が、Webサービスを独力でつくるのはこれがはじめて。というより、プログラム自体がはじめて。

    案の定、前途多難だった。

    やはりザッカバーグは天才だった。

    そして私はアホだった。

    ■とにかく計画を立てる。

    ざっくり、どんな機能が欲しいか考える。自分の力じゃ無理そうでもOK.とにかく妄想を爆発させる。

    妄想した機能

    ・基本的なSNS機能

    メッセージ機能コミュニティ機能あしあと機能日記機能コメント機能つぶやき機能など。

    ・核となるチャット機能

    ミニティ専用のチャットルーム、アカウント専用のプライベートチャットルーム(鍵をかけられる)、自動チャットが開始されるフリーチャット自分の指定した条件にあう人を自動で見つけてきてくれて、チャットができちゃうマッチングチャット

    などなど。






    ■そんなに簡単にSNSが作れるわけがない。

    妄想するのは簡単だ。でも、全くわけがからない。何から手をつけていいのかわからない。

    とりあえずグーグル先生相談

    OpenPNEという簡単にSNSが作れるものがあると知る。

    「うはwwww これで勝つるwww」と思ったけれど、どうやってチャット機能を追加して良いのかわからなかった。改変しようにも謎の記号がめちゃくちゃにならんでいてどうして良いかからない。

    しかも、改変したら改変したでそれを全世界に公開しなくちゃならないらしい(オープンソースというらしい)。

    無理だ。

    と思ったので1から勉強することにした。

    とにかくサーバーサイドの言語と、データベースについて勉強しろや! とのことだった。






    ■使う言語について。

    サーバーサイドを扱える言語はたくさんあって、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

    基本的には、よくわかるPHP概要をつかんで、それから

    基礎からMySQL勉強。 http://www.amazon.co.jp/dp/4797344385/

    最期

    ハイパフォーマンスMySQL http://www.amazon.co.jp/dp/4873114268/

    インデックスの貼り方などについて勉強した。






    チャットに向いている技術

    とりあえず掲示板くらいはつくれるようになったので、チャットについてリサーチ

    ajaxとかよくわからん技術nodejsを使った非同期処理などがあると知る。

    nodejsはC10K問題という問題を解決するすごいものらしく、かっこいいらしいのでこれを勉強することに。

    ついでにnodejsと相性の良い、mongoDB勉強することに。







    javascript勉強

    よくわかるjavascript  http://www.amazon.co.jp/dp/4839941874/

    終わったら、

    パーフェクトjavascript http://www.amazon.co.jp//dp/477414813X/

    パーフェクトjavascriptnodejsについてものすごく詳しく書いてあったので、とても参考になった。このあたりで、LINUXというOSを扱わなくてはいけないと気付き、自宅PCウィンドウからLINUXubuntu)に変えた。


    mongoDB勉強

    これはとにかく触ってなんぼでした。MySQL感覚が違い、苦労しました。

    CakePHPmongoDBを扱うのは

    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だけだったのですが、今は画像ファイルなどはNginxというサーバーを使うのが良いそうなので、Nginxを使いました。

    あとはPHPの中間キャッシュを利用するAPCなども利用することに。


    このへんについては、

    http://bren.jp/blog/%E3%81%95%E3%81%8F%E3%82%89vps%EF%BC%9Anginx-apache-%E6%A7%8B%E6%88%90%E3%81%AE%E8%A8%AD%E5%AE%9A%E6%96%B9%E6%B3%95/

    このような解説記事がたくさんあったので、参考にさせていただきました。

    調子にのって、最期グーグルアドセンスも貼ってみました。




    ■ようやく完成。

    で、なんとか完成しました。

    いちおう妄想していた機能は実装できたかと思います

    製作期間は勉強期間なども含めて、大体9ヶ月くらいです。

    使ってみた感想や、ダメ出しなど頂ければ狂喜乱舞します。よろしくお願い致します。









    モチベーションを維持するためにやったこと。

    あっさりと書きましたが、実際は失敗の連続でやる気が萎えてばっかりでした。

    疲れて帰ってきて、なにもやる気の起きない時もありました。


    そういう時は、とにかくサポートページのQ&Aの1文でも良いから書いてみるとか、とにかくパソコンエディターだけ立ちあげてみるとか、していました。

    ものすごーく覇気のない目でキーボード打ち続けていましたが、それでもなんとか完成することができました。惰性だろうとなんだろうと、少しずつは進むのだとわかりました。

    SNS作ってみたわかったこと。

    やはり1から完全自作をするのは無謀だった。でも、プログラムをやったことのない素人でも約一年頑張ればそれなりのSNSもどきを作ることができた。

    これも先人たちの作ってくれたフレームワークや様々なツール、そして参考書などのおかげ。

    私のようなアホでも頭の良い人の力を借りればなんとかなりました。ありがとうございます

    そしてプログラムは一人でも出来るので、私のように非コミュでも楽しめる素晴らしい趣味である

    現在

    今はRubyに夢中です。くり返し処理がすごくきれいにかけるので素敵な言語だと思っています。あと、javascript面白いので毎日いじくって遊んでいますPHPももちろん触っています

    非コミュあいかわらずですが、プログラム楽しいので前より幸せです。


    仕様した技術など一覧

    サーバー さくらVPS4Gプランを使用しています

    Apache,Nginx,nodejsを利用しています

    データベース mongoDBMySQLを使っています

    フレームワーク CakePHP,socket.io

    使用言語 PHP,Javascript

    できたもの http://tag-chat.net

    2013-01-01

    SmartNews問題の本質は「違法行為」であって、感情の問題ではない

    あけましておめでとうございます

    SmartNewsで炎上マーケティング大成功しているみたいで、株式会社ゴクロのみなさんは本当におめでとうございます

    SmartNews事件の擁護派・反対派まとめ - NAVER まとめ

    こちらに今回の事件の「擁護派」「反対派」がまとめられていますが、擁護派からは「タダ乗り」に対する「感情の問題」みたいな言説が目立ちます別にタダ乗りだとかそういう話ではなくて、株式会社ゴクロは単に違法行為を行なっているというだけの話です。

    どういう仕組みか

    SmartNewsがダメならなぜPocketもダメなのか

    に記されているように、「レスポンスとしてニュースデータヘッドラインと"キャッシュ"を含めたもの)がgzip圧縮され」て、SmartNewsのサーバーから返ってきます。このとき、"キャッシュ"は広告などが抜かれ、改変された状態で送られてくるので、(ゴクロが)キャッシュと称するのは不自然です。

    「他人の著作物を、株式会社ゴクロのサーバー広告を削除した上、全文を転送する」という行為は、明らかに悪質なもので、著作権者の利益侵害していると言われてもおかしくありません。

    なぜPocketが問題ないのか

    SmartNewsがダメならなぜPocketもダメなのか

    に記されているように、PocketもSmartNewsと同じ仕組みを使っていますしかし問題とならないのは、そもそも登記している国が違うからです。

    フェアユース」という抽象的な方法を取る米国と、「私的複製」などの具体的な例外条項を取る日本では、比較するのはナンセンスです。

    感情論はある

    結論は、株式会社ゴクロの行なっていることは著作権侵害である可能性が高い。Pocketの行なっていることも著作権侵害であるが、国が違うので比較対象としては間違っている。ということです。

    しかしながら、「Pocketにタダ乗りされたんだけど、、、」といった話は聞いたことがありません。法律上ではどうなっていても、感情的な問題として、Pocketへの批判はなかなかないでしょう。

    これからどうするべきか

    裁判をする

    現状では「違法性の高い」ということしか言えません。コンテンツパブリッシャー株式会社ゴクロを訴え、判例を作って白黒はっきりつけていただきたいです。

    法律を変える

    Pocketが良くてSmartNewsがダメな理由」は、法律に原因があります。ぜひともフェアユース日本に導入するというのが良いかと思いますしかし、フェアユースを前提として訴訟手続きが粛々と取られるというだけの話なので、過度な期待はしないでいただきたいです。

    法律的に問題ない仕組みにする

    法律的に問題ない仕組み」というのは、アプリ側で加工せよ、という話ではありません。そんなことをしても違法性が弱まるだけで、炎上し、粛々と訴訟手続きが取られるだけです。「全文転載をやめる」「ユーザー能動性を高める」という2つの対策を取り、「感情的な落とし所」をつけるのが良い対策だと考えられます

    2008-10-29

    ヨドバシ・ドット・コム」がリニューアル後おかしくなってるそうな

    どうしたんかいな、とネットワークトレースをとってみた。そしたら、トップ画面の要求に対してこんな応答が返っていた。

    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
    

    えーと。どこから突っ込んでいいのやら。

    ベンダ変えた方がよくないですか?>ヨドバシ

    2007-09-14

    http://anond.hatelabo.jp/20070914021435

    システム機械語レベルの挙動を意識するとどういうところが気になるようになるか、それを現代の環境ではどう教えるか、という点が問題でしょうね。

    メモリレジスタ幅(桁数)と情報の規模の関係を意識する - まあ、Oracle は 64bit OS で使えとか、xfs を 32bit OS で使うと(atomic な部分の更新が泣き別れになって)クラッシュ危険が高いとか

    API 仕様を意識する - 上の例の続きだけど、パッチのあたってない古い gzip で 2Gbytes 以上のファイルが圧縮できないとか

    コードを展開した結果、関数の出入りやインタフェースでどう膨れ上がるか、リソース解放がどれだけ無意味になりうるかを知っている - C++ とかの場合。Tomcatクラスロード(とリソースの確保も -- 追記)で1時間待たされるとかくだらないことが起こるけど、開発効率と運用トレードオフだからなぁ

    ・(Ruby, PHP, Java などの)VMに頼るべきでない場合が何かを知っている - 速度もだけど、VMバグ持ちの場合、デバッグが困難を極めることもある

    ビット操作系のコードを書けないと困る - まあ、ioctl や fnctl で苦労したことがあればどういうものかは判ると思うけど

    ・(追記)strace とか ldd とかくらい言われる前にやってほしい - 実際 JavaPHP しか知らないと本当にこの辺はできない

    ・(追記)497(×10^-n)日で落ちた、と言われた瞬間にカーネルバグを疑ってほしい - lbolt 溢れ系のバグは本当にありふれている

    いまどきは障害対応系の運用をやったほうがプログラマとしてコード書くよりもこの辺の問題に詳しくなれる気がします。

    追記:「こういうこともわからん子供たち」をうまく使って利益を上げる会社と、「こういうこともわからん子供たち」を教えるのにフラストレーションを感じるハッカーがひとりで回している会社、どっちが上記のようなことを学びやすいかというのは難しいところです。SUSv3 (昔のオライリーPOSIX 本でもいいけど)を面白いと思えない人に正直あまり細かいことを学べるとは思えないし‥

     
    ログイン ユーザー登録
    ようこそ ゲスト さん