タグ

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

  • サイトマップやレイアウト構築に便利なUIキット「Website Flowcharts」

    webサイトの制作をスタートする前には、レイアウトの構築やサイトマップの作成が必須。それをすることで、サイトの全体像を把握しながら計画的にデザインをすることができます。今回はそんな企画時に是非利用したい便利なUIキット「Website Flowcharts」を紹介したいと思います。 いろいろなレイアウトのフォーマットUIイメージが72種揃っており、組み合わせをすることでサイトイメージをふくらませることができます。 詳しくは以下 カラムレイアウトやグリッドレイアウト、ランディングページやブログ、カレンダーやユーザープロファイル、コメント欄、タブ、404エラーなど、サイトを制作する上で想定されるレイアウトUIがラインナップされており、わざわざ1つ1つ書き起こす必要がありません。時間短縮にもなりますし、企画書のクオリティも高められるのではないでしょうか? いろんなシーンで活躍してくれると思います

    サイトマップやレイアウト構築に便利なUIキット「Website Flowcharts」
  • AWSのアカウント管理の話 - プログラマでありたい

    AWS Advent Calendar 2014の7日目です。あと、全部俺Advent Calendarも開催中です。 運用絡みで何か書くと宣言したので、AWSのアカウント運用について書いてみます。テクニックや技術より、考え方の面での整理です。 AWSのアカウントの種類 AWSで利用するアカウントは2種類あります。AWSアカウントとIAMアカウントです。AWSアカウントは、マスターアカウントと呼ぶこともあって大元のアカウントになります。AWSにサインアップ時に作るものが、AWSアカウントで1つだけ存在します。それに対して、IAMアカウントはユーザアカウントです。AWSの管理コンソールから、個々のユーザ向けなどに作成します。 AWSアカウントの取扱について AWSアカウントは、全権限を持っています。強力すぎるアカウントで、日常の運用に利用するには危険すぎます。日常の運用には使わないというのが

    AWSのアカウント管理の話 - プログラマでありたい
  • 意識の低い自動化

    意識を低く保ったまま、定型作業を自動化する話です。 ※どうも言葉足らずで誤解させてしまっているようなので補足を書きました。ご覧ください http://qiita.com/greenspa/items/fff535d2ae5da36e36feRead less

    意識の低い自動化
  • Auto Scalingによる自動復旧(AWS Lambda編) - @ijin

    ちょうど1年程前に「非ELBなAutoscalingによる自動復旧」の再検証をしました。前回も復旧までのタイムラグが20分だったので、この1年で変わったかまた検証してみました。 (*) このエントリはAWS Advent Calendar 2014の5日目分です。 設定 前回とほぼ一種ですが、今回はついでにEC2 Status AlarmをCloudwatch経由でSNSでアラートを飛ばします。 SNS作成 & Subscribe(送られてくる確認メールは手動で承認) $ aws sns create-topic --name instance-alert { "TopicArn": "arn:aws:sns:us-west-2:123456789012:instance-alert" } $ aws sns subscribe --topic-arn arn:aws:sns:us-wes

  • 好みや多数決で決めない、デザインとの正しい付き合い方

    「私はデザインができない」と言っている方でも、デザインの好き嫌いはあります。また、「使いやすい」という言葉にも様々な意味があるだけでなく、人によって優先にしていることが異なることがあります。デザインプロセスに参加するひとりひとりの意見は大事にしたいですが、なにを重んじて話し合い、進めればよいのか分からないことがあると思います。デザインの議論が脱線すると、プロジェクト全体にも影響します。 セッションでは、CMSをつかったデザイン案件のなかで気をつけておきたいデザインの進め方、話し方のポイントを紹介します。対クライアントだけでなく、社内でデザインを議論するときにも役立ちます。Read less

    好みや多数決で決めない、デザインとの正しい付き合い方
  • https://darashi.net/2014/12/07/home-hacks.html/

  • if式 / if文 の条件節で、左辺に定数を書くべき言語はあるか? @ajiyoshi.gist

    gistfile1.md if式 / if文 の条件節で、左辺に定数を書くべき言語はあるか? @ajiyoshi.gist twitterからながれてきたこの話題。昔のCコンパイラは、if文の条件節で代入を書いても文句を言わなかったので、このようなコードに何の警告も出なかった。 #include<stdio.h> int main() { int x = 0; /* おそらく意図と違う。 x == 1 と書くべきであった これでは常に実行されてしまう */ if ( x = 1 ) { puts("残念"); } } 「これをこのように書けば、コンパイルエラーになり、ある種の誤りをコンパイラに見つけさせることができる」というのが、「老害」とされる人の主張である。 /* これはコンパイルエラーになる */ if ( 1 = x ) { puts("残念"); } もし使っている環境が「コンパ

    if式 / if文 の条件節で、左辺に定数を書くべき言語はあるか? @ajiyoshi.gist
  • RubyGemはめっちゃ簡単に作れる! 

    今回はbundle gem test_gemの方を説明していきます。Rails Pluginの詳細は次のサイトに解説があります! rails pluginコマンドで簡単に出来るgemの作成方法 🚜 作成されたファイルの概要今回作成されたファイルの簡単な説明。 bundle gem test_gem -t create test_gem/Gemfile create test_gem/Rakefile create test_gem/LICENSE.txt create test_gem/README.md => このgemの説明や使い方を記述 create test_gem/.gitignore create test_gem/test_gem.gemspec => このgemの説明や依存関係などを記述 create test_gem/lib/test_gem.rb => プログラムを記

    RubyGemはめっちゃ簡単に作れる! 
  • https://qiita.com/kenokabe/items/618692858044a89adbc0

  • DockerでオレオレVPSを作った話 - Masteries

    Docker Advnet Calendar 2014の6日目の記事となります. 今日は, 「DockerでオレオレVPSを作った話」というタイトルで, 最近作った「Pocker」という名前のアプリケーションを紹介したいと思います. どうしてそのようなアプリケーションが必要になったのか, その中でのDockerの使い方や, 利用したテクニックなどについてお話できれば, と思っています. あらすじ 自分は昔から「さくらのVPS」を愛用していて, 趣味で作った小規模な自分用ウェブアプリのようなものを, VPSの上に複数個設置していました. さくらのVPSは非常に安価で, しかも価格が固定という事もあり, 小規模なウェブアプリを共存させるには最適だったのですが, 1つのVPSに複数のWebサービスを設置してくると, 「ゴミが溜まってくる」という問題が出てきます. つまり, うまく管理していないと

    DockerでオレオレVPSを作った話 - Masteries
  • 技術評論社のWebサイトが改ざんされた件をまとめてみた - piyolog

    2014年12月5日11時頃から、技術評論社のWebサイトを閲覧すると別のサイトに転送される事象が発生しました。ここではその関連情報をまとめます。 公式発表 12/6 サーバ障害のお詫び 12/8 弊社ホームページ改ざんに関するお詫びとご報告 技術評論社Twitterアカウントのアナウンス(一部) 【日11時ころより発生してる状況について】日11時ころ,サーバ管理ツールに侵入されサーバそのものを入れ替えることにより,外部サイトにリダイレクトされるように設定されました。危険なサイトである可能性があるため,現状アクセスしないでください。— gihyo.jp (@gihyojp) 2014, 12月 6 サーバOSそのものへの侵入ではなく,OSの入れ替えが行われたため,情報漏洩等は確認されておりません。詳細は後日改めてご報告いたします。 ご報告が遅れておりますことをお詫びいたします。— gi

    技術評論社のWebサイトが改ざんされた件をまとめてみた - piyolog
  • Macの容量を大きく占めるlost+foundファイルの正体と処理について - あなたのスイッチを押すブログ

    lost+foundファイルの見つけ方 まず最初に、「lost+found」ファイルの見つけ方です。私の場合は、アプリ「GrandPerspective」を使います。 該当するファイルを見つけたら、そこで右クリック。「Reveal in Finder」を選択すると、Finderが開いて、目的のファイルを見つけることができます。 lost+foundとは そもそもこの「lost+found」ファイルとは何なんでしょう?私も全く知らない間に生成されたようでして、こんなものが出来ていたとは気が付きませんでした。 Googleで検索してみると、どうもこれは「迷子になってしまったファイル」らしいです。 システムが正常に終了されなかったとき、次回起動時にファイルシステムをチェックするfsckというコマンドが実行されます。 このとき、ディスクにはあるのにファイルテストシステム上には無いことになっている(

    Macの容量を大きく占めるlost+foundファイルの正体と処理について - あなたのスイッチを押すブログ
  • 機械学習をこれから始める人に押さえておいてほしいこと - Qiita

    いしたーです。アルバイトで機械学習やってます。こんにちは。 とある勉強会に出席したときに、「機械学習をやりたいけどわからないことが多い」という意見を聞いたので、いくつかアドバイスを載せておきます。 読む前の注意 研究についてのアドバイスは書いていません。趣味機械学習をやろうと思っている方が対象です。 この記事は他の方の意見をまとめたものではありません。私個人の経験に基づいて書いたものです。よって、この記事の内容はほとんど「私の意見」です。 以上2つの注意点を踏まえた上でお読みください。 「機械学習で何をしたいのか」を決めてほしい 機械学習を学ぶ前に、機械学習を使って何をしたいのかを決めてください。 機械学習は数式がたくさん登場したり、難しい概念を理解しなければならなかったりすることがあります。 やりたいことを決めてから学ぶと、今自分はある目的を達成するために学んでいるんだと思うことができ

    機械学習をこれから始める人に押さえておいてほしいこと - Qiita
  • Rubyの凄く面白い特徴をRailsのコードを例に解説 - Qiita

    これはドリコムAdventCalendarの6日目です。 5日目の記事は、ドリコムの開発を支えるGitリポジトリ@gussanです。 7日目は、般若心経F*ck、コピペで徳を高める話@おーはらさんです。 自己紹介 ドリコムでアプリケーションエンジニアとしてネイティブゲームの開発を行ったりマネージメントをしたりしています。 その他の事はこちら参照: https://gist.github.com/Shinya131/5d9e604d963177ee2cdc はじめに この記事は、プログラミング言語Rubyが持つ凄く面白い特徴を、 Ruby on Rails の一部であるActiveSupport core extensionsのソースコードを題材に解説する物です。 題材に使うActiveSupportは、version 4.1です。 対象とする読者 この記事は、以下のような読者に役立つ内容を

    Rubyの凄く面白い特徴をRailsのコードを例に解説 - Qiita
  • DOCOMOの雑談対話APIを使ってHubotと雑談する。 - 文字っぽいの。

    photo by Jenn and Tony Bot 先駆者 Rubotyを使っている方は、こちらを見ると良いでしょう。 DocomoruでBOTと雑に会話する - Qiita Hubotでも使いたい Hubotでも使いたいので、CoffeeScriptで簡単に書きました。 DOCOMO雑談対話API こちらからユーザ登録をして、API_KEYを取得します。 API/ツールの概要 | docomo Developer support | NTTドコモ Hubot Script contextをリクエストボディ(JSON)に含める事によって文脈を保存できるので、会話につながりが出来て便利です。下記の実装ではrobot.brain(Redis)を使って、コンテキストの永続化をしています。 ただ、文脈を破棄するタイミングが難しい。下記の実装例では一定時間毎に破棄していますが、会話するユーザ毎に保

    DOCOMOの雑談対話APIを使ってHubotと雑談する。 - 文字っぽいの。
  • 例外入門以前 - Qiita

    例外 Advent Calendar 2014の継続について 参加者が集まらなかったという経緯から独りAdvent Calendarとして始めた「例外 Advent Calendar 2014」ですが、諸事情により継続が困難となったため私Kokudoriの6日以降の投稿はありません。変に注目だけを集める形になってしまい申し訳ありません。 以下、諸事情というか、言い訳。 『契約による設計から見た例外』という記事にて述べた「契約」に対する私の理解が根的に間違っていました。 そこから芋づる式に例外に関する私自身の考えが間違っていた、あるいは理解が浅かったことに気づきました。このような理解力では例外について私見を述べることさえ不可能となり、結果頓挫という形になりました。 考えうる限り最低で残念な結果になってしまいました。当に申し訳ございませんでした。 初めに原則を考え出して、それから例外を見つ

    例外入門以前 - Qiita