タグ

2014年5月5日のブックマーク (12件)

  • ノイズありテクスチャをSVGで

    PNGのようなビットマップ形式の方が向くサブトなんとかなノイズ付きのスキューなんとかなテクスチャを、SVGのfilter要素でfractalNoiseを利用して生成する試み。SVGだからというか、filterで生成する形なのでスケーラブル、ノイズの分布が平均的なのでおおまかにリピータブルにもなる。上記画像もSVGなのでそのソース見るとわかる。 Demo: SVG Noisy Background filter要素でfractalNoiseを利用しランダムにノイズを与えた矩形とそれに混ぜる単色透過付きの矩形を重ねて実現する。実装任せなのでソースはコンパクトで、URLエンコードのData URIなら557バイトで済んだ。密度の違うノイズを重ねて分布を偏らせることもできるはずなので、慣れてきちんと作れるようになったならサイズ的なメリットは大きい。 Demo: SVG Noisy Backgrou

  • 配色を考えるときに便利なオンラインツール10個集めてみました | WP-E (仮)

    最終更新: 2018年4月14日 皆様こんにちは!最近WP-Eメンバーに名を忘れられているような気がするWP-E HINOTANです。寿司ネタがどこかへ行ってしまいましたね。 さて今回はタイトルの通り、便利な配色ツールを紹介していきたいと思います。 Adobe Kuler まずはAdobeが提供しているAdobe Kulerから。こちらは有名なので知っている方も多いと思います。Adobe KulerはPhotoshopやIllustratorとの連携機能があるので便利です。(Adobe Creative CloudのアカウントIDが必要となります) 「Explore」のページでは、様々なカラーパターンを見ることができ、気に入ったものを登録したり編集したりすることができます。登録したカラーパターンはPhotoshopやIllustratorにも反映されます。 Color Hexa Colo

    配色を考えるときに便利なオンラインツール10個集めてみました | WP-E (仮)
  • IDEA * IDEA

    ドットインストール代表のライフハックブログ

    IDEA * IDEA
  • seen.js

    source map | unminified javascript | full coffeescript seen.js has no dependencies. Licensed under Apache 2.0 To see what is new in this version, read the release notes. Demos Hello, World! Materials gallery Noisy Wave Patch Noisy Sphere Same Scene, Canvas vs. SVG Same Scene, Multiple Angles SVG Masks and Effects Text Depth of Field Audio Equalizer N-Body Gravity Simulation Mocap-Driven Skeleton 2

  • Using jQuery UI with AMD | jQuery Learning Center

    **Note:** This documentation refers to functionality made available in jQuery UI 1.11. As of jQuery UI 1.11, all of the library's source files support using AMD. This means that you can manage your jQuery UI dependencies without using Download Builder, and load jQuery UI's source files asynchronously using an AMD loader such as RequireJS. In this article we'll walk through the process of using AMD

  • デバイスとアプリで愛車の走行データを節約につなげる | ライフハッカー・ジャパン

    疲れやすい、呼吸の浅さを改善。ストレッチポールは毎日使いたいほど気持ちがいい!【今日のライフハックツール】

    デバイスとアプリで愛車の走行データを節約につなげる | ライフハッカー・ジャパン
  • ユーザーインターフェースの質を高める手法「ユーザーはヨッパライ法」とは

    PCを操作するキーボードやタッチパネル、自動車を運転する時のハンドルやペダル類、あるいはウェブページの操作画面など、ユーザーが何かを操作したり情報をやりとりする際に触れる部分は総称してユーザインタフェース(UI)と呼ばれており、その仕上がり具合によっては製品の評価が大きく左右されることもあります。製品企画をおこなう際には重要な項目の1つとなっているUI設計ですが、特にウェブサイトにおけるUI品質を高めるための手法がYouTubeで公開されています。 The User is Drunk - YouTube 優れたユーザーインターフェースデザインの手法について語るのはウィル・デイブルさん。オーストラリア・メルボルンのウェブコンサルタント企業であるSquareweaveを率いる1人です。 デイブルさんが唱える手法とは、「ユーザーはお酒に酔っ払っている」と仮定してインターフェースを設計する「The

    ユーザーインターフェースの質を高める手法「ユーザーはヨッパライ法」とは
    seckie
    seckie 2014/05/05
  • 生産性アップの金字塔「GTD」の理念をおさらい | ライフハッカー・ジャパン

    Getting Things Done、あるいは「GTD」とは、物事を効率よく処理し、生産性を上げるためのシステムです。外から見ると複雑に見えますが、その最終目標はいたってシンプル。「しなければならないこと」をする時間を短縮し、「やりたいこと」をする時間を増やすことです。 今回は、GTDの概要を説明するとともに、GTDをシンプルに導入する方法を紹介します。 GTDとは何か?(Getting Things Doneとは?) Getting Things Done(GTD)とは、通常、2つのものを指します。ひとつは生産性メソッドの名前。もうひとつは、生産性コンサルタントであるデビッド・アレン氏のベストセラーのタイトルです。GTDには長い歴史があり、米Lifehackerを含め、いたるところで生産性マニアたちに熱烈に支持されてきました。とはいえ、米LifehackerであってもまだGTDについ

    生産性アップの金字塔「GTD」の理念をおさらい | ライフハッカー・ジャパン
    seckie
    seckie 2014/05/05
  • にわか TOEIC マニア - steps to phantasien

    社内で開かれたワークショップ形式の研修に参加したのは一年前、ちょうど今頃のこと。 それはたぶんチームワークのような何かを学ぶ会だったはずだけど、 私の感想は題と関係なく「いいかげん真面目に英語を勉強しないとあかん」だった。 話が通じないとチームワークどころじゃない。 米国資勤めの会社員からすると、英語はグローバル云々以前に仕事用 DSL みたいなもの。 英語ができないまま騙し騙し働くのはたぶん、 SQL が書けなからと ORM の上だけでコードを書こうとするのに似ている。できなくはないけど、いろいろしんどい。 幸い私は Web 開発者じゃないから SQL はわからなくていい。でも英語はやらないとダメっぽい。 入社二年半、ようやく現実を直視した。 最初はしゃべる練習をしようかと思ったけれど、そもそもしゃべる以外の英語すらできるといえるのか。怪しい。 むしろまず典型的日人として英語ができ

  • にわか Podcast ファン - steps to phantasien

    出張中。時差ボケ修正のためキータイピングで眠気を払おうと試みているところ。 いつになくどうでもいい内容につき見逃してください。 最近はやりの Podcast 番組 Rebuild を聴きはじめた勢いで他の番組も聴くようになった。にわかポッドキャスト好き。 にわか欲があるうちに聞いている番組を紹介したい。といってもだいたい ”オススメ Tech Podcast 5選” の記事にあるやつなんだけど。ちなみに私の Podcast 歴がどれだけにわかかというと、rebuild.fm の序盤はブラウザから mp3 をダウンロードして聴いていたくらい。 Podcast はとっくに滅びたメディアだとおもっていた。でも Blog が生き残っている程度には元気だと知りました。 私の聞いている番組は基的にアホらしい内容のものが多く、情報収集というより娯楽。 ニュースほど早口でも無味乾燥でもなく、講演ほど背筋

  • コードレビューいろいろ - steps to phantasien

    コードレビューの話をいくつか見かけた. (1, 2, 3) 私もはやりにのってなにか書いてみたい. といってもリンク先についてどうこう言う気はない. ふだんからぼんやり感じていることをテキストにしてみたい. コードレビューの様式 コードレビューのやりかたは色々ある. 話の背景をあきらかにすべく, まずは私が参加したり見聞きしたりしてきた方法を紹介したい. ただとりとめなく列挙しても見通しが悪いから, 方法を評価する軸を見立てておこう. コードの粒度: 一回のレビューでレビュアが目を通すコードの量はどのくらいだろう. プロジェクト全体? モジュール単位, 機能単位, それともクラス単位? 古典的なレビュー様式はこれら <論理的な単位> でレビューをすることが多い. 最近はブランチやコミットのような <ひとまとまりの変更> を単位とする方法に人気がある. Github の Pull Reque

  • 下から目線のコードレビュー - steps to phantasien

    WEB+DB の新しいやつがちょっと前にでてます. コードレビュー特集だそうな. 時が経つのは早い. まだ次の原稿書いてないのに… そういえば前にコードレビューの話を書いた気がして, 見なおしたところ かきかけ だった. せっかくなので続きを書いてみることにします. といっても何書くつもりだったか覚えてないのでだらだらと. WEB+DB PRESS の特集は, 主にこれからコードレビューを導入したい人に向けて書かれている. 幸か不幸か私はコードレビューを義務付けれたプロジェクトで働いているため, 導入には苦労していない. かわりにレビューをちょろまかせない面倒はある. ある意味でコードレビューを <やらされている>. もちろんこの言い分は大げさだ. 必要性に異議を唱える気はない. ただ異議はさておき自分の意向とは無関係にコードレビューに参加している気分を書いた話は あまり目にしないので,