全国1億2000万人のImmutable Infrastructure好きの皆様こんばんは。 去年あたりに色々な場所で紹介されたりして知っている人が多いと思うのですが、簡単に自分用にダッシュボードを作れるDashingが結構使いやすいので改めて紹介しておきます。APIを用意しているミドルウェアやシステムであれば簡単にデータを引っ張ってきてゴニョゴニョできます。 Dashingとはhttp://shopify.github.io/dashing/で公開されているSinatraベースで作られたダッシュボード作成用のフレームワーク。 非常に見た目の良いダッシュボードが作れます。デモは、こちらで公開されています。 ウィジェット型のアーキテクチャーのため、色々なダッシュボード用のパーツを独立して作成し、自由に配置することができること、データを自動で更新できること等も特徴です。 インストールDashi
Vagrant Cloudがリリースされたので、自分のBoxの公開を試してみた。 試した環境 Max OSX 10.9.1 Vagrant 1.5.0 Vagrant 1.5.0以上が必要。 リポジトリへのBoxの配置 Vagrant Cloudは、それ自体がBoxのリポジトリとなるわけではなく、Boxのリポジトリを仲介するようなイメージとなる。 そのため、まずはBoxを公開されている任意場所に配置する必要がある。 Boxの作成 こちらを参考に、任意状態の仮想マシンをPackageする Vagrantのboxに少しだけ手を加えたものをboxとして取っておきたい Boxをリポジトリへ配置 Packageして作成したBoxを、インターネット上へ公開されている任意リポジトリへ配置する。 DropBoxを利用して公開するとエラーとなる(後述)ので、Amazon S3上へ配置した。 Vagrant
Hubot (note: it's prounounced hew-bot) A Customizable, Life Embetterment Robot Commissioned by GitHub View Hubot's Documentation (Learn about getting started, etc.) View Hubot's Source Code(via http://github.com/github/hubot/.) What is Hubot? Hubot is your friendly robot sidekick. Install him in your company to dramatically improve employee efficiency. No seriously, what is Hubot? GitHub, Inc., wr
http://zachholman.com/posts/github-communication/ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 ほうれんそう(報告/相談/連絡)って正直面倒ですよね? もちろん自分も大人ですから、仕事におけるタイミングよい細かなコミュニケーションの大切さは理解してます。だから職場では頑張ってやりました。折をみてメンバ全員を集めて話しもしました。1 on 1のミーティングもやりました。そしてメンバにもまわりとのコミュニケーションを積極的にとるように期待しました。 けど、子供のときに朝8時半に学校に行かなくてはいけなかったときと本音では変わってないと思います。やらざるを得ないからやるということ。やはりストレスです。 GitHubのコミュニケーション伝導師のZach Ho
Amazon Kinesis と初音ミクをもちいた、元気パワーのリアルタイムビジュアライザーRead less
他人の文章を自分の文章のように扱う研究上の不正は、「剽窃」または「盗用」と呼ぶのが正確であり、不正確で誤解を招く「無断引用」という表現を用いるのはやめるべきである。 「無断引用」という表現はよろしくない 小保方晴子氏が他者の文章を自分の論文に盗用したという事件 [1] があった。この事件の報道において「無断引用」という表現が各所で用いられているが、この表現は正確でなく誤解を招きやすいので、使うのはやめるべきだと思う。「無断引用」の代わりに、「剽窃(ひょうせつ)」か「盗用」と言ってほしいところだ [2] 。 引用という行為は、引用の作法を守っているかぎり、法的にも倫理的にも何ら問題のない行為である。そして、引用は基本的に無断で行われる。わざわざ出典の著者の許可をとらないのである。つまり、無断で行われる引用は全く正常な行為であり、研究上の不正ではない。 研究上の不正になるのは、他人の文章を自分
質の高い本を読むと、いろいろと得るものがあります。ただ、読んでも頭の中を情報が素通りするだけで、きちんと記憶できないときはイライラしますよね。実は、こうした時に記憶力をぐんと向上させるメソッドがあるのです。 Q&A サイト「Stack Exchange」にいた"本の虫"が、クイズゲームにも勝てる知識を身につけるコツについて教えてくれました。私は、自分が興味を持ったトピックに関するノンフィクションをよく読むのですが、本で得た情報をきちんと覚えていられないのが悩みです。 例えば、1年前にトーマス・ジェファーソンの伝記を読んだのに、今となっては、彼が生まれたのが1743年だということ以外、何も覚えていません。ジャーナリストのクリストファー・ヒッチンス氏や、作家であり神経科学者でもあるサム・ハリス氏といった私が憧れる書き手たちは、読んだ本の内容を当たり前のように暗記して引用しています。ヒッチンス氏
前提: GitHub flow を使っていてCIサーバーはJenkins 最近ちょっと開発フローの改善をして、とてもよく機能してて満足しているので紹介してみる。 この改善をやる前の悩み: pull-requestでコードレビューはできるのだけど、cssとかjavascriptなどの見た目や動作の変更ってコードだけだとわかりにくい。レビューする人が各自ローカル環境で実行するのもだるい。 コードを読まないデザイナーとかプロダクトオーナーとかの人が、pull-requestのレビュープロセスに簡単に参加できない(非開発者全員のところでローカル環境設定するのはだるすぎる)。 コード的にokに見えてmasterにmerge後、何か問題(特に仕様的な問題や、デザイン的な問題)が発生した場合、「修正branchを作ってpull-request」というフローを再度回さないといけない。最初のpull-req
最近CIサーバーを自前Jenkinsから CircleCI に移した。CircleCIとても便利で簡単なのでオススメ。 CircleCIには普通のheroku deployは内蔵されているのだけど、 非開発者もGitHub Flowに巻き込んでみんなハッピーになった話 、をやるにはちょっと工夫が必要。 色々書こうと思ったけど、めんどくさくなったのでscriptを晒しておくだけにしよう! この中で使われているスクリプト関連、特に秘密にする部分もないのでpublicでgithubに置いている。 https://github.com/quipper/deploy-support-tools /circleci.yml deployment: feature: branch: /^(?!^master$).+$/ commands: - ./script/staging_deploy.sh pro
些末なコードレビュー - naoyaのはてなダイアリー なおやさんのエントリーを読んで改めて感じました。これはコードレビューについての話ですが、言いたいことは本質的なことについて話せるかどうかという点だと思います。 いい加減、「コミュ力」という単語で片付けるのはやめよう 「エンジニアはコミュ力がない」とかいわれますが、コミュ力とかいう単語1つで片付けてほしくないです。少なくとも普段の会話におけるコミュニケーションと仕事におけるコミュニケーションって別物ですよね。 先ほどのコードレビューの話ですが、仕事においてのコミュニケーションってどれだけ本質について話せるかなんですよ。要するに、情報を整理して正しく相手に伝えるということ。となると、仕事におけるコミュニケーション力って職種とは直接的に関係してこないと思っています。 「コミュニケーション能力」の意味の違い 「仕事におけるコミュニケーション能
当社はCookieを使用して、お客様が当社のWebサイトでより良い体験を得られるようにしています。引き続き閲覧する場合は、プライバシーポリシーに同意したことになります。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く