ランディングページを作るとき・直すときには「見た目」を考えるよりも前に「何を伝えるか？」を考えることが重要になります。 これまで1000回以上のABテストを実施してきたデータアーティストのノウハウをギュギュっと詰めて、そしてちょっとふんわりさせたランディングページ最適化の資料です。Read less
お金をかけないランディングページのつくりかた
ランディングページを作るとき・直すときには「見た目」を考えるよりも前に「何を伝えるか？」を考えることが重要になります。 これまで1000回以上のABテストを実施してきたデータアーティストのノウハウをギュギュっと詰めて、そしてちょっとふんわりさせたランディングページ最適化の資料です。Read less
EditorConfig を Emacs から使う - 雑文発散(2014-01-04)
▼ [Emacs] EditorConfig を Emacs から使う ひさびさに CakePHP を clone したら、.editorconfig という見慣れないファイルがあった。 ファイル内はこんな感じ。 ; This file is for unifying the coding style for different editors and IDEs. ; More information at http://editorconfig.org root = true [*] indent_style = tab end_of_line = lf insert_final_newline = true trim_trailing_whitespace = true [*.bat] end_of_line = crlf http://editorconfig.org/ を見に行くと
モデルやメソッドに名前を付けるときは英語の品詞に気をつけよう - Qiita
はじめに 他の人が書いたコードを読んでいるときに時々気になるのが、英語の間違いです。 特に動詞、名詞、形容詞の使い分けが間違っていたりすると、かなり違和感を感じます。 そこで今回はモデル（＝クラス）やメソッドに名前を付けるときの基本的な原則をまとめてみます。 また、英文法的に正しい品詞が選べるようになるための習慣についても最後に説明します。 想定する言語/フレームワーク この記事の説明ではRuby/Ruby on Railsを想定しています。 ただし、基本的な考え方は他の言語でも同じように使えるはずです。 モデルの名前は名詞にする 例: 「支払い情報」を表すモデルを作りたい場合 × Pay ○ Payment 「支払う = payか。よし。」でモデルを作ってはいけません！ payは動詞で、payの名詞形がpaymentです。 Payモデルではなく、Paymentモデルを作りましょう。 例:
株式会社じげん に行ってきた！ - 941::blog
チェケラ！くしいです。 行ってきたシリーズも82記事目というわけでありますが、今回は「なんか凄いオフィスありますよ！」とご紹介いただいてお邪魔してきたのが、株式会社じげん さん。 ライフイベント領域（求人/住まい/結婚/車など）を中心に、その領域に特化したサイトを運営されているんだけど、オフィスはこの３月にお引っ越しされたばかりということで最新オフィスをドドーンと紹介しちゃう。なんかこう派手っちゅうかなんちゅうか凄いオフィスだった。 真っ暗でようわからんけどボンヤリ光るじげんロゴ。多分ここ。 ==== なんか電話あるから受付っぽい… けどなんかレーザーでピャーってなってる… ※公開から3ヶ月以上経過した特定の記事は有料となっている場合があります この続きはcodocで購入
nanapi勉強会 vol2 に参加してきました - FLOG SPLASH
めも Shellの活用でこれだけ毎日が便利になる http://nanapi.doorkeeper.jp/events/11514 Results for #nanapi_study そうたろう cocoiti さん、目で dis られる シェルをもっと効率的に使って作業しよう 武器を増やそう シェルの超基本 C-a とか C-e とか C-w とか使ってカーソル移動を効率的に screen とか tmux とか当然使おう それ上でコピペできるようになっておくとよいよ .zshrc とか いつも煩わしいと思ってた作業が簡単になるやつ！ 定着する よさそうだから入れてみよう！ たいてい定着しない インクリメンタルサーチ C-r 例えば git pull --rebase origin master と打ちたい場合、 pull あたりで C-r して過去のやつ引っ張ってくるとか 同じことの繰り
nanapi勉強会 vol2 で、シェルオプションの話をしてきた #nanapi_study - 元RX-7乗りの適当な日々
nanapiのCTOである@wadapさんに声をかけていただいて、LTをやってきました。 nanapi勉強会 vol2 - Shellの活用でこれだけ毎日が便利になる LTで使った資料を以下に公開しておきます。 bash(set)コマンドのオプション3選 from Yuuki Namikawa 資料だけだと伝わりづらいですが、僕がこのLTで話したかったことですが、実は本編はおまけみたいなもので、現地でしゃべったとおりですが、スライド3枚目〜5枚目の部分です。 単純に、先日発売になったChef実践入門の宣伝ｗと、もう1つはシェルのHistoryで初対面のエンジニアと仲良くなる方法ですｗ スライド4枚目に書いてあるとおりですが、普段自分が使っているシェルで例えば以下のような感じでコマンドを実行すると、Historyから、コマンドの実行回数ランキングを出してくれます。 $ history | a
提言: コミットメッセージの一行目には要求仕様を書け - Qiita
これは Git (や Subversion などのバージョン管理システム) にコミットする時により良いコミットメッセージを書くための提言です。この提言は特にメッセージの一行目だけを対象とします。せめて最も重要な一行目だけでも良いメッセージを書いて欲しいからです。提言をズバリ一言で表すと 一行目には要求仕様を書け です。 背景 プロジェクトによっていろいろ慣習の差はあるものの、一般的には「コミットメッセージの一行目は変更内容の要約を簡潔に書け」とされます。特に Git は、各コミットメッセージの一行目だけを取り出してそれを一覧表示するなど、一行目を特別に処理する機能が多いので、一行目にできるだけ多くの情報を凝縮させることは重要です。またメッセージを一行しか書かない不届きな慣習のプロジェクトでは、十分な情報を持たないメッセージは無用の長物と化します。 良くないコミットメッセージ しかし私は、情
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
zawで快適シェル生活