タグ

2014年8月14日のブックマーク (9件)

  • Amazon Redshift クエリパフォーマンスチューニング ベストプラクティスを読んでみた | DevelopersIO

    Amazon Redshiftでは『ベストプラクティス』なるテーマで、それぞれの局面でのお作法的な設定、改善の為のノウハウがドキュメントとして適宜追加or更新されています。ちょうど去年の8月にクラスメソッドにジョインした際もこの辺りのドキュメントについて幾らか目を通して参りましたが、英語ドキュメントを訪れてみると更に充実した形で『ベストプラクティス』が整備されているようです。そこで当エントリでは『クエリパフォーマンスチューニング』という切り口で更新されている以下ドキュメントを改めて読み直してみたいと思います。 Amazon Redshift Best Practices - Amazon Redshift 目次 1.パフォーマンスを考慮したテーブル設計を行う 1-a.最善のソートキーを選択する 1-b.最善の分散キーを選択する 1-c.COPY時に『自動圧縮あり』でデータをロードし、オスス

    Amazon Redshift クエリパフォーマンスチューニング ベストプラクティスを読んでみた | DevelopersIO
  • 「Raspberry Pi」搭載カメラ自作キット「SnapPiCam」

    「SnapPiCam」は「Raspberry Pi」搭載カメラ自作キットだ。SnapPiCamは、「Raspberry Pi Model A」とRaspberry Pi 5メガピクセルカメラボードを採用し、「Compact」「Adventurer」「MegaZoom」「MegaZoom Plus」の4種類がある。 Compactは、Raspberry Pi採用5メガピクセルカメラで、1200mAhリチウムポリマーバッテリを搭載し、大きさは100mm×68mm×50mmだ。

    「Raspberry Pi」搭載カメラ自作キット「SnapPiCam」
  • sakutto

    NEWSニュースリリース 2014年11月26日 「トップページ」に使える資料(PART2)を計32点追加いたしました! 2014年11月12日 「トップページ」に使える資料を計32点追加いたしました! 2014年11月07日 お役立ち資料『フィーチャーフォンサイトのコーディング規約』を追加いたしました! 2014年11月05日 「商品」の詳細ページに使える資料を計24点追加いたしました! 2014年10月31日 お役立ち資料『フィーチャーフォンサイトのデザイン規約』を追加いたしました! 2014年10月24日 お役立ち資料『PCサイトのコーディング規約』を追加いたしました! 2014年10月22日 「クーポン」の詳細ページに使える資料を計24点追加いたしました! 2014年10月17日 お役立ち資料『PCサイトのデザイン規約』を追加いたしました! 2014年10月15日 「クーポン」のペ

    sakutto
  • Amazon EC2(Linux)のネットワーク設定でハマったときに見るメモ | DevelopersIO

    ども、大瀧です。 LinuxのEC2インスタンスでちょっと変わったネットワーク設定をしようとすると、思う通りに動かなかったり設定が見えなかったりと、オンプレミスとは雰囲気の異なる振る舞いをすることがあります(質的にはオンプレミスとなんら変わらないのですが)。自身で経験したケースをメモ書きとして残しておきます。 想定するLinux OS : Amazon Linux, CentOS 6.x, RHEL 6.xなどRed Hat系ディストリビューション /etc/resolv.confを変更したのになぜか元に戻ってしまう DHCPクライアントによるものです。DHCPクライアントは定期的にIPアドレス更新の問い合わせをDHCPサーバーに行いますが、そのときに付随するDNSの情報を元にデフォルトで/etc/resolv.confファイルを上書きします。これを無効にするためにNICの設定ファイル/

    Amazon EC2(Linux)のネットワーク設定でハマったときに見るメモ | DevelopersIO
  • 今日から始めるNode.jsコードリーディング - libuv / V8 JavaScriptエンジン / Node.jsによるスクリプトの実行 | Tokyo Otaku Mode Blog

    ソフトウェアを正しく理解する唯一の方法はコードを読むことです。 ドキュメントを読めばそのソフトウェアが何を実装しているか分かりますが、どのように実装されているかまでは分かりません。 開発中に何らかのトラブルに悩まされたときや、効率的なコーディングをしたいと思ったとき、下位レイヤのソフトウェアを理解しておけば素早く対処できるシーンが多くあります。 ただ、コードを読むことは簡単なタスクではありません。 現代的なソフトウェアはそれなりの規模のコードを含んでいることがほとんどです。アーキテクチャ間の差異を吸収するためのコードなど、質的な機能を理解する上ではあまり重要ではないコードも含まれています。 何らかの問題が発生してからコードを読もうと思っても、準備なしでは関連する箇所を探すだけでかなりの労力が必要な作業となります。 従って、普段からコードを読んでおくことが重要です。 また、コードを読むにあ

    今日から始めるNode.jsコードリーディング - libuv / V8 JavaScriptエンジン / Node.jsによるスクリプトの実行 | Tokyo Otaku Mode Blog
  • UIデザインにおけるナビゲーションのデザインパターンまとめ | ベイジの社長ブログ

    前回エントリーでは「UIデザイナーが理解しておくべき11種類のナビゲーションと特徴」として、ナビゲーションの種類を、機能的な側面から分類し、ご紹介しました。 続編となる今回は、ナビゲーションをデザイン的な側面からとらえ、形状、ふるまい(動き)、階層というの3種類の表現軸に分けて、ナビゲーションでよく使われているデザインというものを整理してみました。 形状のデザイン UIにおけるナビゲーション要素が、主にどのような形状でデザインされているか、というパターンをここではご紹介しています。 メニューバー メニューをボタン化し、バー状にまとめたデザインです。PCサイトのグローバルナビゲーションやローカルナビゲーションなどによく採用されます。 一覧性に優れ、一目でナビゲーション要素と分かるため、ユーザビリティに優れます。一方、ある程度の表示スペースを必要とするため、スマートフォンではあまり用いられない

    UIデザインにおけるナビゲーションのデザインパターンまとめ | ベイジの社長ブログ
  • プログラミング・レスで5分でサックリWebスクレイピング「kimonolabs」 - プログラマでありたい

    Rubyによるクローラー開発技法」で付録か何かで書こうか悩んだ末に書かなかったのが、kimonolabsの話です。kimonolabsは、クローラー/スクレイピングをオンラインで実行できるWebサービス(SaaS)です。クローラーを書いておいて何ですが、9割の人は自分でクローラーを作らずに、この手のサービスを利用すれば事足りると思います。(書かなかった理由は、Ruby縛りサービスの継続性とスケジュールの問題です。主に最後) kimonolabsとは? kimonolabsは、先述のとおりWebスクレイピングをしてくれるSaaSです。会員登録してChromeの拡張をいれれば、すぐに使えるようになります。一般的に、Webスクレイピングする場合は、次のような手順が必要です。 対象ページのダウンロード ダウンロードしたページから、特定の箇所を抜き出す 抜き出したデータの保存 対象ページのダウン

    プログラミング・レスで5分でサックリWebスクレイピング「kimonolabs」 - プログラマでありたい
  • 私の周りにいる、異常にコミュニケーション能力が高い人たちのこと - glasstruct log

    考えすぎてコミュニケーション能力が低い人へ - teruyastarはかく語りき この記事を読んで、「あああ、分かるなあ、これ自分のことだなあ」と思ったので、自分なりに「コミュニケーション力」について思ったことをチョボチョボと書きます。主に仕事上のことです。 異常にコミュニケーション能力の高い人たちのこと 私の勤め先は、「学生時代一番人気があった子たちで、就職活動もどこでも行けた」ような人が大変多い。こういう人の集団で過ごしていると、私のようなコミュニケーション能力(以下コミュ力)の低い人間は、丸腰で最前線を匍匐前進で進んでいるような感じです。何かって言うと、会議で軽い、時事ネタなど織り込まれた会話のジャブを進めていきながら核心にズイズイ進んでいく中で、私は変なタイミングで「これってこうすればいいと思います、いやでもそれじゃコンペでは目立たないかもしれないし、もしかしたら敢えてこうするとか

  • テスト先に書きたい若者よ - hitode909の日記

    弊社では毎年インターンを受け入れているのだけど,いまもインターンが来てて,テスト先に書きたいけど油断すると先に実装を書いてしまう,とか話してた. 個人的には,テスト先に書くのが大事というよりかは,意識して仕様を先に考えるのが大事だと思っている.テストを先に書くと,先に仕様を考えざるを得ないので,良いスタイルが身につく. 僕がよくやるのは,関連しそうなクラスの絵をひと通りノートに書いてみて,その図だけで,うまく動くことを説明できるくらい考えてみる.その時点でおかしかったら,コード書いてもおかしくなる.ノートに方眼ついてるとクラス図書きやすい.UMLとかじゃなくても,自分で見て分かるくらいでもいいと思う. 紙でうまくいったら,外部仕様だけソースコードに書いてみる.クラス名と,メソッドの定義と,メソッドの上くらいに,ひと通りコメントでも書いてみて,この関数はこういうことをするんです,こういう引数

    テスト先に書きたい若者よ - hitode909の日記