タグ

2016年4月7日のブックマーク (7件)

  • デート中に韻を踏んでしまう彼氏が気をつけるべきたったひとつのこと - 踏む.韻 fumu.in

    この記事が話題なので、一言だけコメントする。 detail.chiebukuro.yahoo.co.jp 韻に踏まれたら終わり この彼氏がダメなのは、 真剣な話をしていても、デートのプランを立てていてもなにかにつけて韻を踏みます。 とあるように、つまり、デートの行き先まで、韻に引っ張られている点だ。 来は、伝えたいことをよりうまく伝えるために、韻は踏むべきもの。それなのに、この彼氏の場合、最初に韻ありきで行動が決まってしまう。 想像するに、デートの行き先を決めるにしても、 今日は仕事は5時まで じゃあ二人で行こうとしまえん という感じで、当はディズニーランドに行きたくても、韻に引っ張られてデートの行き先が、としまえんになってしまうのだろう。 こういうのを、「韻を踏む」のではなく、「韻に踏まれる」と言う。 言いたいことをリズム良く言うために韻は踏まれるべきであって、韻に引っ張られて言いた

    デート中に韻を踏んでしまう彼氏が気をつけるべきたったひとつのこと - 踏む.韻 fumu.in
  • すべてのReact.js初心者が知っておくべき9つのポイント - Qiita

    9 things every React.js beginner should knowを意訳しました。 誤りやより良い表現などがあればご指摘頂けると助かります。 私は約6ヶ月間React.jsを使用してきました。それほど長い歴史ではありませんが、あなたがひげの長老として扱われるようなJavaScriptフレームワークの目まぐるしい世界の大きな枠組みの中で、私は最近、React初学者のTipsで少数の人々を支援してきましたので、ここでより多くの人々にその内容を共有するのが良いアイデアであると思いました。これらは全て私が始めた時に知っておきたかったことか、もしくはReactを習得するために当に役立ったもののいずれかです。 あなたが絶対的な基を知っていると想定して話を進めますが、もしコンポーネント、propsやstateなどの言葉に馴染みがなければ、公式の入門やチュートリアルページを読むと

    すべてのReact.js初心者が知っておくべき9つのポイント - Qiita
  • iOS ヒューマンインターフェースの原則 - Qiita

    はじめに iOS のヒューマンインターフェースを理解するためにはまず UI 設計の原則を定めた聖典 iOS Human Interface Guidelines を読むことから始めなければなりません。ここにはプラットフォームの特徴からデザインの原則、それぞれの部品が何のためにデザインされたのか、どう利用するのか、iOS を構成する UI の基指針がまとまっています。 よく、『磨りガラス効果がかっこいい』『アニメーションしておくとイケてる』『ボタンは右配置の方が右手で押しやすい』『流行っているから』……などの観点によって UI の設計が決められることがありますが、そういうことではないのです。いや実際かっこいいかわいいだとかの感覚は重要なのですが、見た目が何となくそれっぽいだけでは優れた UI とは言えません。磨りガラスでも何でも必ずそこには意味があります。だからこそ HIG に書かれた思想

    iOS ヒューマンインターフェースの原則 - Qiita
  • 「WebAPI 設計のベストプラクティス」に対する所感 - Qiita

    「翻訳: WebAPI 設計のベストプラクティス」を読んで色々と思うところがあったので書きました。 上記の記事は訳文でありますので、正しくは「Best Practices for Designing a Pragmatic RESTful API」に対する所感と述べた方が良いのかもしれませんが、日語で通して読めるよう Qiita に投稿された訳文に対する所感として書いています。 以下では「翻訳: WebAPI 設計のベストプラクティス」並びに「Best Practices for Designing a Pragmatic RESTful API」は「当該記事」と表現します。 観点 当該記事では「○○とした方がよい」との意見に対してそうすべき理由が明らかになっていないか、もしくは表現が曖昧な場合が目立っていると感じました。設計は実装のようにプログラム言語仕様が制約を与えられないため、意図

    「WebAPI 設計のベストプラクティス」に対する所感 - Qiita
  • もう保守されない画面遷移図は嫌なので、UI Flow図を簡単にマークダウンぽく書くエディタ作った - Qiita

    はじめに Webサービスやアプリを企画したり、立ち上げたりする際にプロトタイピングツールや、ExcelPowerpoint、Illustraterなどを駆使した謎のファイルで画面遷移図を描くことがある。 こういう図を元に仕様を決めて行って、サービスを作っていくのは以下の点で困る。 画面遷移図が保守されない。 書くのが非常に面倒くさい ユーザーのモチベーションの流れが追いづらく、見た目ばかりに注目してしまうものになりがち マシンリーダブル(ソフトウェアで構造を取り出せない)でない。 このような欠点があってどうにも扱いづらい。 そんなわけで、markdown風のテキストから簡単に画面遷移図を描けないかなとコンパイラを作成し、次にそれをインタラクティブに編集できるエディタを作成した。 UI Flows図について 画面遷移図的なものを書く際に、僕が個人的につかっていた表現方法として、UI Flo

    もう保守されない画面遷移図は嫌なので、UI Flow図を簡単にマークダウンぽく書くエディタ作った - Qiita
  • はじめてのOSSリリース記 〜なぜ無料でソースコードを公開するのか? - Qiita

    はじめに 先日、一年ほど前から運営しているWebサービスのコードをGitHub上で公開(いわゆるOSS化)しました。 ※サービス自体は公式ホスティングサービスという位置付けで運営を継続しています。 小さなライブラリをOSSとして公開することはあっても、運営中のサービスを丸々OSS化するケースは割と珍しいかと思い、今回OSS化するに至った経緯とその狙いについてまとめてみました。 サービスについて 題に入る前に、簡単に対象のサービスについて触れておきます。 Chibineko (https://chibineko.jp) 「世界で最もシンプルなテスト支援ツール」をコンセプトに、マニュアルテストの管理に特化した軽量なテストツールです。 Markdownライクにテストケースを書けるのが特徴で、リリース前テストなど100項目程度の簡単なテストをサクッと書いて、サクッと実行するのに向いています。 ト

    はじめてのOSSリリース記 〜なぜ無料でソースコードを公開するのか? - Qiita
  • javascriptを使ったSEO対策まとめ - Qiita

    一昔前まではjavascriptを使ったSEOに弱いというのがあったりしましたが、今ではGooglebotが大分賢くなりjavascriptを実行できるようになってきてます。 とはいえ何も考えなくてもいいかというとそうでもないので、javascriptを使った場合にSEO対策として意識しないといけないことをまとめてみました。 いろいろ書きましたが、 Hisory APIを使ってURLをきちんと書き換えよう っていうのが主です。(pjaxと呼ばれている手法です) クリックやスクロールでDOMを生成するコンテンツはインデックスされない ページロード時点ではhtml内に生成されていないが、あるイベントが起きた時にDOM要素を生成するパターン。 Qiitaで言うとTOPページ下部にある「もっと見る」とかがそうですね。 Googlebotはjavascriptを実行することはできるのですが、clic

    javascriptを使ったSEO対策まとめ - Qiita