Prestoの導入メリットのほか、HiveQLからPrestoへの書き換えTipsを紹介しますRead less
![爆速クエリエンジン”Presto”を使いたくなる話](https://cdn-ak-scissors.b.st-hatena.com/image/square/f99fc32e69e7bdca77db19896ff55f979723bd27/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Fbullethadoopqueryenginepresto-150424064424-conversion-gate01-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
Welcome, fellow Pythoneer! This is a small book of Python anti-patterns and worst practices. Learning about these anti-patterns will help you to avoid them in your own code and make you a better programmer (hopefully). Each pattern comes with a small description, examples and possible solutions. You can check many of them for free against your project at QuantifiedCode. Why did we write this?¶ Sho
Rodeoという新しいプロダクトがリリースされました。 ŷhat | Rodeo: A data science IDE for Python Rodeoは、The IPython Notebook — IPython や RStudio のようなデータ分析系のIDEです。Python製で、pipインストールできます。 pip install rodeo Rodeoインストール直後の pip list を確認します。 docopt (0.6.2) Flask (0.10.1) gnureadline (6.3.3) ipython (3.1.0) itsdangerous (0.24) jedi (0.8.1-final0) Jinja2 (2.7.3) MarkupSafe (0.23) pip (1.5.6) pyzmq (14.6.0) rodeo (0.2.1) setuptool
ansibleを使ってec2にプロビジョニングするときの導入部分をメモ程度に。 ansible自体のインストールは済ませてあるものとします。 まずhostsファイルを作ります。 ~/ansible/hosts <- フォルダは好きなところで構いません [kudohamu-ec2s] xx.xxx.xx.xx <- ec2インスタンスのIP 次にplay-bookの作成。今後ec2を増やすことを考慮してここではcommon.ymlという名前にします。 common.ymlでやること ユーザ(kudohamu)の作成 kudohamuユーザにsudo権限を付与 gitのインストール サーバではなるべくrootユーザを使わないようにします。必要なユーザを作って必要な権限を与え、そのユーザで作業するのが一般的です。 とはいえ趣味のEC2なのでひとまずkudohamuというユーザを作りsudo権限を
Ansibleって何? Ansibleとか構成管理ツールのことで、Chef等のツールと大体は同じです。 Chefと比べ、AnsibleはRubyの理解を必要とせず、yaml形式での記述をするため、比較的初心者向けとなっております。 チームで開発したりする際に、ローカル環境を同一にするために使われると思います。 環境 環境は以下となります。出来るだけ最新の環境で試します。 Windows7 Vagrant1.6.5 VirtualBox4.3.12 Gow0.8.0 なお、参考にしているサイトは、 Ansible チュートリアル です。 GowはWindowsでlinuxコマンドが打てないため使用しています。 サーバーの準備 チュートリアルの通りにやっていきます。 $ mkdir ansible-tutorial $ cd ansible-tutorial $ vagrant init ce
最近、Ansibleを使い始めたのだが、yumやapt-getでインストールできるものはいいけど、 どうしてもソースインストールが必要な場合がある。 ソースインストールを行う際のPlaybookの書き方と注意点をまとめた。 まず、あたりまえだが、ソースインストールを行うには以下のフローを踏まなければいけな。 1. ソースファイルの取得(tarで固められていると仮定) 2. tarファイルの解凍 3. 解答してできたディレクトリへ移動 4. configure 5. make 6. make install また、Ansibleでは何回もPlaybookを実行していくため、 すでにインストールされている場合は、インストールをスキップする必要がある。 yumやapt-getで管理されていれば上記を心配することはないのだが、やはりソースインストールだとこの壁がある。 ※パッケージ化しろよ!という
ありがたいことに、以前のJenkins自動デプロイ記事がそれなりに多くの反応をいただきまして、冷静に見直してみたのですが、ちょっとデプロイ処理が雑だなと。 最近ではデプロイをやるにも、Capistranoやfabricなどのツールがあり、多様化するデプロイ要件に柔軟に対応できるような工夫が施されています。これらのツールを用いることで、シェルスクリプトで記述されたぐちゃぐちゃなオレオレデプロイを回避できたり、デプロイ失敗時のロールバックなどがしやすくなるメリットがあります。 現在開発しているアプリでは、git pullだけでデプロイできるようにしてあるので、前回の記事のようにJenkinsのジョブにシェルスクリプト直書きでもいいのですが、 デプロイ先の変更やスケールアウトに対応しにくい 認証鍵の場所をコマンドで直書きするのが、個人的にちょっと抵抗ある 書き方がスマートじゃない ←重要 という
react-style-guideの日本語訳が見つからなかったので、ざっと読むだけでなく英語の勉強がてらオレオレな和訳をしてみた。(半分ぐらい個人用メモ状態です) (わからない部分はGoogle翻訳に頼ったし諦めたりしたりしたし)ものすごい誤訳意訳口語訳多数だと思うので、指摘等いただけると幸いです。 Reactの"独特な"考え方は今までこれといってスッキリと書くことができなかった。 だから私は、所属するチームで過去数ヶ月の間で使ってみたイケてる感じのReactの書き方についてまとめてみようと考えた。 この記事は、React-Componentsに限定した範囲での話をします。 (JavaScriptの)プログラミング全体のスタイルや、componentization(Web Componentsを用いた開発?)、Fluxの概念とかの話ではないです。 同様に、ドキュメントは生きていますし、これ
10分で実装するFlux 自己紹介 azu @azu_re Web scratch, JSer.info Flux /flˈʌks/ Fluxとは Facebookが提唱したSmalltalk MVCの焼き直し CQRS(Command Query Responsibility Segregation)と類似 データが一方通行へ流れるようにするアーキテクチャ ウェブUIについてそれを適応する 今日の目的 小さなFluxの実装を作りながらFluxついて学ぶ Fluxの特徴: Unidirectional data flow 本当にデータが一方通行に流れるのかを確認する Fluxでよく見る図 登場人物 何か色々いる Action Creators, Dispatcher, Store, React Views... Dispatcher = EventEmitterと今回は考える もっと実装的
はじめに Hadoopを使って大規模データを蓄積し分析するのは、もはや当たり前になってきた昨今ですが、大規模データ分析の環境を試すのは、なかなか難しいというのが現状です。確かに、Hadoop単体やSQLエンジン単体なら、Amazon EMRやGoogle BigQueryなどを使うことで体験することは可能でしょう。しかし、大規模データの分析基盤では以下のようなことを行っていく必要があります。 RDBMSからデータをHadoopにインポートする SQLを使って、大規模データを高速に分析する アクセスログなどの大量の非構造化データを分析する 大量のデータに対し、リコメンドに利用するための高度な分析処理を行う 大量のデータを全文検索できるようにする これらすべてを試す環境を構築するのは、たとえクラウド環境を使ったとしても困難です。また、(検証環境としては)意外と高額な費用がかかってしまい、永続化
Amazon EC2 Container Service • コンテナ管理サービス – シンプルなAPIでEC2クラスタ上のDockerコンテナを管理 • プライベートレポジトリ対応・Diskマウント対応 – Dockerコンテナの管理を簡単に行えるようにしたサービス • EC2インスタンスのリソース管理 • デプロイ管理 – EC2インスタンス上に複数のコンテナを起動出来る • EC2インスタンスのリソースを効率的に利用可能 – クラスタの構成管理などの運用が不要 • コンテナインスタンスを起動してクラスタに参加させるだけ • リソースの空いているコンテナインスタンスにコンテナを自動的に起動 • 明示的にコンテナインスタンスを指定してコンテナを起動することも可能
AWSでは高可用性を高めるためにマルチAZの配置を推奨しています。サーバーをマルチZA配置にすることで、物理的に独立した複数のAZ (Availability Zone)にサーバーを稼働させることができるので、障害に強いシステムを構築できる素晴らしい仕組みです。 いいことずくめの仕組みなのですが、唯一の欠点はAZ間のレイテンシです。Elasticsearchは受け付けた検索要求をすべてのシャードへ問い合わせる仕組みのため、マルチAZ配置にするとAZ間の通信が発生してしまうので、どうしてもパフォーマンスが落ちてしまいます。 これを避けるには、1つのAZ内に配置されているElasticsearchのノードだけで完全なインデックス(シャード)を保持し、受け付けた検索要求は同じAZ内で検索を完結できるように構成する必要があります。それを実現するのが Shard Allocation Awarene
本サイトでは、ラーニング・パターンの考え方や個々のラーニング・パターンについて紹介します。 ラーニング・パターンは、自律的で創造的な学び方のコツをパターン・ランゲージという形式でまとめたものです。どのような状況でどのような問題が生じやすく、それをどのように解決すればよいのかの発想がまとめられています。このようなコツを「言語」として共有することで、個人の自律的で創造的な学びの支援と、学びのコミュニティの活性化を目指しています。 ラーニング・パターンは、2009年4月から毎年、慶應義塾大学総合政策学部・環境情報学部の全学生(一学年約900人)に配布されているほか、本ウェブサイトやtwitter等で、幅広い世代の方に広まりつつあります。ぜひご活用ください。 ラーニング・パターン(Learning Patterns)のtwitter配信をしています! よりよい学びのコツを記述した「ラーニング・パタ
昨日か今日ぐらいの発売のWEB+DB Press vol.86のp123~のnaoya氏のReactの記事が良いらしいからみんなで勉強しましょう、って増井先生が言ってたので、昨日夕方数人で読んでて家帰ってから実際にコード書いてみた。 JavaScript苦手なのでcoffee-scriptで写経した。 https://github.com/shokai/react-coffee-study observer modelかつデータの流れを1方向にするのをFluxアーキテクチャと呼ぶのとか、DOM切り貼り職人のつらみとVirtualDOMの差分更新とかそういう概念の話は知ってたけど、なぜかなかなかReactそのものを使う機会が無かった。 Reactの感想 触ってみた感じではBackbone+Marionetteよりとっつきやすい。 WEB+DB Pressの記事の前半のtodoリストはみたまま
このスライドは Markdown でプレゼンテーションが作成できるサービス Stobo で公開されています。
一部のサブシステムの構築で、プロビジョニングツールを捨ててみた。じゃあどうするのかというとシェルスクリプトでやる。今回はこのやりかたが一番楽できるような気がしたので試している。 具体的にはPackerからシェルスクリプトとServerspecを実行してAMIを煮込む。おいしくできあがったらそいつから構築。もしミドルウェアより下の層のコンフィグ類に変更があったらまた煮込む。構築する。新しい方に切り替える。つまり”捨てるインフラ”にする。 プラットフォームはAWS。 (追記)ちなみにchefなどのプロビジョニングツールがめんどくさいからシェルスクリプトにしたというよりは、捨てる前提のサーバだからシェルスクリプトでの構築も選択肢として出てきたということです。ただ自分個人の嗜好としてchefはもう飽きたというのも事実です。なお、オンプレだと同じサーバで継続してプロビジョニングすることになるのでch
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く