git push されたら Jenkins でビルドする - milk1000cc
まず、Jenkins を叩くスクリプトを ~/git/jenkins.rb などに置きます。 require 'net/http' require 'uri' Net::HTTP.version_1_2 unless ARGV[0] puts 'usage: ruby jenkins.rb [JOB_NAME]' exit 1 end user = "(Jenkins ユーザーID)" api_token = "(ユーザの API トークン。Jenkins の、ユーザ設定ページに載っています)" uri = URI("http://JENKINS_HOST/job/#{ ARGV[0] }/build") # ARGV[0] に job 名が渡ってきます Net::HTTP.start(uri.host, uri.port) do |http| req = Net::HTTP::Get.n
2014年のウェブシステムアーキテクチャ - stanaka's blog
(Monitoring Casual Talk in Kyotoで発表してきたので、ブログエントリにまとめ直しました) 2013年はインフラ周りの技術的な進化が大きく、いくつかのエポックメイキングな概念と実装が産まれました。個人的には特に以下の2つが大きいと思っています。 AWSの本格普及期 DockerとImmutable Infrastructure これらを踏まえて、2014年のウェブシステムの進化の方向性を考えてみます。また、それによるモニタリングへの影響もあわせて考えます。だいぶ長くなってしまったので、急ぐ人は最後に結論をまとめましたので、そちらからどうぞ! 2013年という時代背景 AWSが本格普及期を迎えているのは、言わずもがなのことで、Re:Inventでの246件という膨大のセッション数などにその勢いが表われています。 また、DockerはLXC (LinuX Conta
最近のImmutable Infrastructureに関する議論(Orchestration編) - Kentaro Kuribayashi's blog
この分野について議論する際には、インフラ系技術の流れ - Gosuke Miyashitaで紹介されている Bootstrapping Configuration Orchestration という整理を前提に議論すると、どのレイヤについて話しているのかごちゃごちゃにならなくてよいと思う。ただ、 上記は階層を成す概念なのだけど、それぞれが必ずしも排他的ではなく、重なる部分が多々ある(たとえば、(1)に該当するDockerやPackerにも(2)の要素が含まれている等) Orchestrationというネーミングがいまやミスリーディング(な面がある) ということもあって、一部に混乱をきたしている。ここでは、特に(2)について、時系列を追って論ずる。 時系列の整理 インフラ系技術の流れ - Gosuke Miyashitaによる整理 Rebuild: 25: Immutable Infrast
Go の Test に対する考え方 - Qiita
この記事は Go Advent Calendar 2013 の 9 日目の投稿です。 今回は、 Go の testing というパッケージの使い方を解説しようと思ったのですが、 それだとつまらなすぎるので、合わせて Go が test というか assert についてどういうスタンスをとっているかを書いてみます。 Go でテスト さて、「テストのないコードはレガシーコード」などと言われて久しく、様々な言語が test (主に Unittest) について言語レベルでサポートしたり、デファクトなライブラリが確立したりといった状況が、今日では至って普通のこととなっています。 そんな言語や環境で、息をするようにテストを書いてきたみなさんが、はじめて Go でコードを書く時に見るべきは testing パッケージです。 http://golang.org/pkg/testing/ 命名規則 では、
Node.jsの開発を超速化するGitHub連携 三種の神器 - teppeis blog
Node.js Advent Calendar 2013 - Adventar 9日目です。 あまりネタを用意する時間がなかったので、GitHubにNode.jsのリポジトリを置いたりnpmにパッケージを公開したりしたときに便利な定番サービスを3つ紹介します。 Travis CI Coveralls David タイトルは釣りですが、特にTravisとCoverallsは一度体験すると離れられないぐらいほんとにlife changing。コードをpushしたらブランチのビルド結果をプルリクに表示してくれたり、カバレッジ結果をコメントで書き込んでくれるので、それを見ながらコーディングを進めていけます。これが無料なのは意味不明なぐらいの神です*1。 サンプルコードはこちらのプロジェクトで見てください。 Github: https://github.com/teppeis/fixclosure
リレーショナルモデルのドメイン設計についての議論
リレーショナルモデルを実践するには、ドメイン（≒データ型）を如何に正しく設計するかということが極めて重要になる。しかしながら、ドメインをどう設計すべきかという議論はあまりされていないように思う。その結果、ドメインについての理解はあまり進まず、データベース設計に失敗しているパターンが多いように思われる。 というわけで今日のテーマはドメインである。 集合を定義するリレーショナルモデルにおけるデータ型とは何か。リレーショナルモデルを実践するにはまずその点から理解する必要がある。 リレーショナルモデルでは、データ型はドメインと呼ばれる。ドメインとは、その属性（≒カラム）に入るべき値はどういったものかを集合として定義したものだ。言い換えると、属性値とはある集合の要素の一つであると言える。従って、ドメインを設計する際には、SQLで言うところのデータ型、つまりINTやCHARといったものだけでなく、その
IDの設計についてのさらに突っ込んだ議論
今日も前回に引き続きデータベース設計の話をする。今回の話で一旦データベース設計については筆を置くつもり（ブログ書いてないで原稿書けよ＞俺）であるが、その前に話をすっきりさせて置きたいと思う。最後を飾るテーマはIDの設計である。 数字しかないのに意味を含んだID前回のエントリを見ていただいた方から、次のような構造を持った学籍番号があるというフィードバックを頂いた。 全部数値で"入学年度下2桁"+"学科コード"+"学科内のあいうえお順の順位" このようなルールで割り当てた学籍番号を、単なる数値として扱うのであれば大きな問題はない。これは数値しか含まれていないので、SQLのデータ型としては単に数値型を使えば良いだろう。だが、学籍番号から入学年度を判断する、あるいは学科を判断するといった用途で使われるのであればやはり適切ではないといえる。リレーショナルモデルの観点だけからではなく、IDとして適切で
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
