Web立ち上げ勉強会というものに参加してきた。
いかにして新規のWebサービスを立ち上げるか、そしてそれを広めていくかということに対して、参加者のWeb立ち上げ経験者が意見交換を行うというもの。
リアル体験談は非常に興味深し。
・仮説を立てたらしっかりと検証を行うこと。
・初期ユーザの獲得には人脈力が大きくすること。
・初期ユーザの獲得はひたすらプッシュ！
・プッシュするにしても効果の高いプッシュをすべき
・リアルな情報が信頼感を向上させる
・初期の流行ってる感が重要
・初期の流行ってる感はスタープレイヤーを置くことで対処
・スタープレイヤー以外の一般プレイヤーは見せないくらいでいい。
・コミュニティ系サイトは炎上する
・炎上した際に炎上したままにするか炎上を削除するかは両者ともに意義がある
・その際、提供したい価値を考え、軸をブラさないようにすることが重要
・プレスリリースは効果が大きい。
・プレスリリースの際にも方法論はある。
・異業種交流会でライターさんと知り合いになっておく
・月曜の朝一にプレスのお願いを出すといい、など。
などなど。
備忘録的に書きました。
グループワークでtwitterの新しいサービスを考えるということで
taxtter
というものを発表してきました。
反応はいまいち。。
2009年7月10日金曜日
2009年7月1日水曜日
[Rails]findメソッドとfind_by_idメソッドの微妙な違い
モデルが参照するテーブルのレコードで、存在しないidものにアクセスしようとすると、その戻り値がfindとfind_by_idで違うことについて。
dataテーブルのidカラムが1～9まで埋まっているものとしよう。
このとき、id = 5のものにアクセスしようとすると、
同じものが返ってきます。
一方、id = 10のデータにアクセスしようとすると、そんなインスタンスはなく、
返ってくるものが違うんですね！
dataテーブルのidカラムが1～9まで埋まっているものとしよう。
このとき、id = 5のものにアクセスしようとすると、
Data.find(5) # => datasテーブルの5番目のDataモデルインスタンス
Data.find_by_id(5) # => datasテーブルの5番目のDataモデルインスタンス
Data.find(5) == Data.find_by_id(5) # => true
同じものが返ってきます。
一方、id = 10のデータにアクセスしようとすると、そんなインスタンスはなく、
Data.find(10) # => # ActiveRecordNotFound
Data.find_by_id(10) # => nil
返ってくるものが違うんですね！
2009年6月30日火曜日
Googleと知恵袋とVBAがすっごい便利だと思う
完全にルーチンワークな作業が舞い込んできたときにこの3つのツールは本当に便利。
要はたくさんのExcelファイルから情報を読み込んで1つのシートにまとめるっていう作業がありまして。
そこまでファイル数も大きくないしなー
マクロ組むほどでもないか―
とか思いながら1個1個データを移してたら。。。
意外と時間がかかる！
てか、あとのフォルダの情報量半端ねえ！！
ってことでネット検索♪
先人たちの遺産はネット上にごろごろ転がってるわけですよ。
検索に特化したgoogleさん。
人が質問するワードに近い検索が容易な知恵袋系サービス。
そして一瞬にして問題解決を行ってくれるマクロ♪
おそらく1時間くらいかかりそうな作業が検索・ダウンロード5分。理解10分。実行＆生成で10分くらいで完了しました♪
以下今回使ったソース。
フォーマットの決まったExcelファイルを一括で読み込んでその情報を1つのExcelシートにまとめる。
今回のケースはA1, A2, A3セルに情報が入ってるものとする。
読めばわかるけどまだVBA慣れてない。。
これも要勉強ですね。
要はたくさんのExcelファイルから情報を読み込んで1つのシートにまとめるっていう作業がありまして。
そこまでファイル数も大きくないしなー
マクロ組むほどでもないか―
とか思いながら1個1個データを移してたら。。。
意外と時間がかかる！
てか、あとのフォルダの情報量半端ねえ！！
ってことでネット検索♪
先人たちの遺産はネット上にごろごろ転がってるわけですよ。
検索に特化したgoogleさん。
人が質問するワードに近い検索が容易な知恵袋系サービス。
そして一瞬にして問題解決を行ってくれるマクロ♪
おそらく1時間くらいかかりそうな作業が検索・ダウンロード5分。理解10分。実行＆生成で10分くらいで完了しました♪
以下今回使ったソース。
フォーマットの決まったExcelファイルを一括で読み込んでその情報を1つのExcelシートにまとめる。
今回のケースはA1, A2, A3セルに情報が入ってるものとする。
Sub summary()
Sheets.Add
Set nSH = ActiveSheet
rL = 1
Set mySh = CreateObject("Shell.Application")
Set myPath = mySh.BrowseForFolder(&O0, "フォルダを選んでください", &H1 + &H10, 0)
If myPath Is Nothing Then Exit Sub
If myPath.Items Is Nothing Then Exit Sub
If myPath.Items.Item Is Nothing Then Exit Sub
フォルダ = myPath.Items.Item.Path
Set mySh = Nothing: Set myPath = Nothing
Set myFS = CreateObject("Scripting.FileSystemObject")
For Each myCSV In myFS.GetFolder(フォルダ).Files
If LCase(myFS.GetExtensionName(myCSV)) = "xls" Then
Workbooks.Open myCSV
'For Each rSH In Sheets
For Each myCC In Range("A1, A2, A3") ' ここに取得したいセルを羅列
rC = rC + 1
nSH.Cells(rL, rC).Value = myCC.Value
Next
rC = rC + 1
nSH.Cells(rL, rC).Value = ActiveWorkbook.Name
rC = rC + 1
nSH.Cells(rL, rC).Value = ActiveSheet.Name
rL = rL + 1
rC = 0
'Next
ActiveWorkbook.Saved = True
ActiveWorkbook.Close
End If
Next
Set myFS = Nothing: Set nSH = Nothing
MsgBox "完了"
End Sub
読めばわかるけどまだVBA慣れてない。。
これも要勉強ですね。
2009年6月28日日曜日
Windows上でUbuntuを動かしてみた。
ここのサイト参考にしてWindowsにUbuntu入れてみた。
すっげー簡単なのね。
http://www.ubuntulinux.jp/products/JA-Localized/vmware
イメージとしてはこんな感じ。
最初からOpen Officeも入ってるんですねー。
ただ、セットアップ中に
「この仮想マシンで VMware Tools パワーオンスクリプトが正常に実行されませんでした。仮想マシンにカスタムされたパワーオンスクリプトが構成されている場合は、スクリプトにエラーがないか確認してください。それ以外の場合は、サポートにご連絡してください。」
というエラーが出たのが気になる。。
問題なく動いてるからいいけど、何なんだろ？
それからもう一点。
VMwareを使ってUbuntu立ち上げるとだいぶメモリを食います。
タスクマネージャで確認したところ、およそ500MBのメモリ消費量。。
すっげー簡単なのね。
http://www.ubuntulinux.jp/products/JA-Localized/vmware
イメージとしてはこんな感じ。
最初からOpen Officeも入ってるんですねー。
ただ、セットアップ中に
「この仮想マシンで VMware Tools パワーオンスクリプトが正常に実行されませんでした。仮想マシンにカスタムされたパワーオンスクリプトが構成されている場合は、スクリプトにエラーがないか確認してください。それ以外の場合は、サポートにご連絡してください。」
というエラーが出たのが気になる。。
問題なく動いてるからいいけど、何なんだろ？
それからもう一点。
VMwareを使ってUbuntu立ち上げるとだいぶメモリを食います。
タスクマネージャで確認したところ、およそ500MBのメモリ消費量。。
2009年6月27日土曜日
[書籍]世界で一番簡単なUnixのe本
そろそろちゃんとUnixとかサーバとか勉強しようと思ったのでタイトルに釣られて本書購入。
世界で一番簡単なというように、
非常にわかりよいイラストと解説・章ごとクイズ・まとめと解説等があって好印象。
内容としては、
そもそも情報処理とは何かとか、Unixとは何かといったことから始まり、
Unixのコマンドの紹介があったり、
WindowsでUnixを使ってみましょうという話があったり。
何よりも、こういう知識は理解しただけじゃ意味がないのでMy windowsパソコンにVM Wareあたりをインストールして使ってみようと思います。
世界で一番簡単なというように、
非常にわかりよいイラストと解説・章ごとクイズ・まとめと解説等があって好印象。
内容としては、
そもそも情報処理とは何かとか、Unixとは何かといったことから始まり、
Unixのコマンドの紹介があったり、
WindowsでUnixを使ってみましょうという話があったり。
何よりも、こういう知識は理解しただけじゃ意味がないのでMy windowsパソコンにVM Wareあたりをインストールして使ってみようと思います。
2009年6月23日火曜日
脆弱性とは何か？-ウェブアプリに関する脆弱性のまとめ
脆弱性ってなんなん？って思ったのでちょっとまとめた。
簡単に言うと、
脆弱性とは、コンピュータやネットワークなどの情報システムにおいて、第三者が保安上の脅威となる行為(システムの乗っ取りや機密情報の漏洩など)に利用できる可能性のあるシステム上の欠陥や仕様上の問題点。
以下のサイトが詳しい。
http://www.ipa.go.jp/security/vuln/20050623_websecurity.html
で対策としては、
1. アプリと
2. サーバと
3. ネットワークを
守れと。
監視しろと。
無駄なものは省けと。
そんな感じ。
で、今回ちょっとウェブアプリに関する脆弱性についてまとめてみる。
◆ SQL インジェクション
何か：SQLコマンドを用いた攻撃
対策：SQL文の組み立てにバインド機構を使用
利用できない場合、SQL文の変数に対しエスケープ処理
パラメータにSQL文を直接指定しない
エラーメッセージをブラウザに表示しない
データベースアカウントに適切な権限を与える
◆ OS コマンド・インジェクション
何か：OSコマンドを用いた攻撃
対策：シェルを起動できる言語機能の利用を避ける
利用する場合は、引数を構成する全ての変数に対してチェック
◆ パス名パラメータの未チェック／ディレクトリ・トラバーサル
何か：外部にwebサーバないのフォルダ構成がばれることによる攻撃
対策：外部からのパラメータにファイル名を指定しない
固定のディレクトリを指定しディレクトリ名がばれないようにする
ウェブサーバ内のファイルへのアクセス権限を設定
ファイル名のチェック
◆ セッション管理の不備
何か：このセッションID の発行や管理に不備がある場合悪意のある人にロ
グイン中の利用者のセッションID を不正に取得される
対策：セッションIDを推測が困難なものにする
セッションIDをURLパラメータに格納しないようにする
HTTPS通信で利用するCookieにはsecure属性を加える
ログイン成功後に、新しくセッションを開始するようにする
ログイン成功後に、既存のセッションIDとは別に秘密情報を発行。ページの遷移毎にその値を確認
セッションIDを固定値にしない
セッションIDをCookieにセットする場合、有効期限の設定に注意する
◆ クロスサイト・スクリプティング
何か：入力値を用いて出力値を出すウェブアプリにおいて、出力値にスクリプトを埋め込まれる
解決：ウェブページに出力する全ての要素に対して、エスケープ処理
出力は「http://」「https://」に限定
要素の内容を動的に生成しない
スタイルシートを外部サイトから取り込めるようにしない
入力値の内容チェックを行う
入力されたHTMLテキストから構文解析木を作成し、スクリプト排除
入力されたHTMLテキストから、スクリプトに該当する文字列を排除
HTTPレスポンスヘッダのContent-Typeフィールドに文字コード(charset)指定
Cookie情報の漏えい対策として、TRACEメソッドを無効化し、発行するCookieにHttpOnly属性を加える
◆ CSRF（クロスサイト・リクエスト・フォージェリ）
何か：Webサイトにスクリプトや自動転送を仕込むことにより閲覧者に意図せず別のWebサイト上で何らかの操作を行なわせる攻撃
解決：処理を実行するページを POST メソッドでアクセス
「hidden パラメータ」に秘密情報が挿入されるよう前のページを自動生成。
処理実行直前のページで再度パスワードの入力を求める
入力されたパスワードが正しい場合のみ処理を実行
Refererが正しいリンク元かを確認し、正しい場合のみ処理を実行
重要な操作後、ユーザーの登録済みメールアドレスに結果を自動送信
◆ HTTP ヘッダ・インジェクション
何か：HTTPヘッダに、任意の情報を挿入することで攻撃を行う手法
解決：ヘッダの出力を直接行わない
ウェブアプリケーションの実行環境や言語に用意されているヘッダ出力用APIを使用
改行コードを適切に処理するヘッダ出力用APIを利用できない場合、改行を許可しない
外部からの入力の全てについて、改行コードを削除する
◆ メールの第三者中継
何か：全く関係のない第三者のメールサーバを踏み台にして送信元を偽造
解決：外部からのパラメータをメールヘッダの内容に指定しない
外部からのパラメータをメールヘッダに指定する場合は、危険な文字を排除
簡単に言うと、
脆弱性とは、コンピュータやネットワークなどの情報システムにおいて、第三者が保安上の脅威となる行為(システムの乗っ取りや機密情報の漏洩など)に利用できる可能性のあるシステム上の欠陥や仕様上の問題点。
以下のサイトが詳しい。
http://www.ipa.go.jp/security/vuln/20050623_websecurity.html
で対策としては、
1. アプリと
2. サーバと
3. ネットワークを
守れと。
監視しろと。
無駄なものは省けと。
そんな感じ。
で、今回ちょっとウェブアプリに関する脆弱性についてまとめてみる。
◆ SQL インジェクション
何か：SQLコマンドを用いた攻撃
対策：SQL文の組み立てにバインド機構を使用
利用できない場合、SQL文の変数に対しエスケープ処理
パラメータにSQL文を直接指定しない
エラーメッセージをブラウザに表示しない
データベースアカウントに適切な権限を与える
◆ OS コマンド・インジェクション
何か：OSコマンドを用いた攻撃
対策：シェルを起動できる言語機能の利用を避ける
利用する場合は、引数を構成する全ての変数に対してチェック
◆ パス名パラメータの未チェック／ディレクトリ・トラバーサル
何か：外部にwebサーバないのフォルダ構成がばれることによる攻撃
対策：外部からのパラメータにファイル名を指定しない
固定のディレクトリを指定しディレクトリ名がばれないようにする
ウェブサーバ内のファイルへのアクセス権限を設定
ファイル名のチェック
◆ セッション管理の不備
何か：このセッションID の発行や管理に不備がある場合悪意のある人にロ
グイン中の利用者のセッションID を不正に取得される
対策：セッションIDを推測が困難なものにする
セッションIDをURLパラメータに格納しないようにする
HTTPS通信で利用するCookieにはsecure属性を加える
ログイン成功後に、新しくセッションを開始するようにする
ログイン成功後に、既存のセッションIDとは別に秘密情報を発行。ページの遷移毎にその値を確認
セッションIDを固定値にしない
セッションIDをCookieにセットする場合、有効期限の設定に注意する
◆ クロスサイト・スクリプティング
何か：入力値を用いて出力値を出すウェブアプリにおいて、出力値にスクリプトを埋め込まれる
解決：ウェブページに出力する全ての要素に対して、エスケープ処理
出力は「http://」「https://」に限定
要素の内容を動的に生成しない
スタイルシートを外部サイトから取り込めるようにしない
入力値の内容チェックを行う
入力されたHTMLテキストから構文解析木を作成し、スクリプト排除
入力されたHTMLテキストから、スクリプトに該当する文字列を排除
HTTPレスポンスヘッダのContent-Typeフィールドに文字コード(charset)指定
Cookie情報の漏えい対策として、TRACEメソッドを無効化し、発行するCookieにHttpOnly属性を加える
◆ CSRF（クロスサイト・リクエスト・フォージェリ）
何か：Webサイトにスクリプトや自動転送を仕込むことにより閲覧者に意図せず別のWebサイト上で何らかの操作を行なわせる攻撃
解決：処理を実行するページを POST メソッドでアクセス
「hidden パラメータ」に秘密情報が挿入されるよう前のページを自動生成。
処理実行直前のページで再度パスワードの入力を求める
入力されたパスワードが正しい場合のみ処理を実行
Refererが正しいリンク元かを確認し、正しい場合のみ処理を実行
重要な操作後、ユーザーの登録済みメールアドレスに結果を自動送信
◆ HTTP ヘッダ・インジェクション
何か：HTTPヘッダに、任意の情報を挿入することで攻撃を行う手法
解決：ヘッダの出力を直接行わない
ウェブアプリケーションの実行環境や言語に用意されているヘッダ出力用APIを使用
改行コードを適切に処理するヘッダ出力用APIを利用できない場合、改行を許可しない
外部からの入力の全てについて、改行コードを削除する
◆ メールの第三者中継
何か：全く関係のない第三者のメールサーバを踏み台にして送信元を偽造
解決：外部からのパラメータをメールヘッダの内容に指定しない
外部からのパラメータをメールヘッダに指定する場合は、危険な文字を排除
2009年6月21日日曜日
クラウド勉強中③AWSをより安く使うには
Amazon EC2は同じ機能を使うにしても、料金が変わってくる。
サービス自体が従量課金であるため、ちょっとの差でも大きく変わってくる。
注意したいところ。
1. WindowsよりもLinux
AmazonEC2においてではスペックにより値段が変わる。
それは当然だとしても、同じスペックでOSの種類によって値段が変わる。
例えば、Standard Instance Smallの場合、
Windows: 0.125ドル/1h
Linux: 0.1ドル/1h
ほんの0.025ドルの差だが、これが1000hになった時には25ドル、1年間では219ドルの差になってくる。
同じスペックなのにこの値段の差。できればLinuxを使いたい。
(僕はまだLinuxは不慣れです。。)
2. ヨーロッパよりもアメリカ
Amazon S3ではデータの保存容量に対して課金がされる。
使用するサーバがどこにあるかによって料金が変わってくる。
例えば、Amazon S3の合計保存容量が50TB未満の場合、
アメリカ: 0.15ドル/1month・1GB
ヨーロッパ: 0.18ドル/1month・1GB
アメリカの方が断然安い。
Amazon Cloud Frontではアメリカに設置されてるサーバが最も安く、
0.17ドル/1month・1GB
日本に設置されてるサーバが最も高く、
0.22ドル/1month・1GB
AWSを使うときにはこの辺もしっかりと考慮しなきゃですね。
サービス自体が従量課金であるため、ちょっとの差でも大きく変わってくる。
注意したいところ。
1. WindowsよりもLinux
AmazonEC2においてではスペックにより値段が変わる。
それは当然だとしても、同じスペックでOSの種類によって値段が変わる。
例えば、Standard Instance Smallの場合、
Windows: 0.125ドル/1h
Linux: 0.1ドル/1h
ほんの0.025ドルの差だが、これが1000hになった時には25ドル、1年間では219ドルの差になってくる。
同じスペックなのにこの値段の差。できればLinuxを使いたい。
(僕はまだLinuxは不慣れです。。)
2. ヨーロッパよりもアメリカ
Amazon S3ではデータの保存容量に対して課金がされる。
使用するサーバがどこにあるかによって料金が変わってくる。
例えば、Amazon S3の合計保存容量が50TB未満の場合、
アメリカ: 0.15ドル/1month・1GB
ヨーロッパ: 0.18ドル/1month・1GB
アメリカの方が断然安い。
Amazon Cloud Frontではアメリカに設置されてるサーバが最も安く、
0.17ドル/1month・1GB
日本に設置されてるサーバが最も高く、
0.22ドル/1month・1GB
AWSを使うときにはこの辺もしっかりと考慮しなきゃですね。
登録:
投稿 (Atom)