crontabのsyntax checkをTravis-CIで行う - Hateburo: kazeburo hatenablog
crontabファイルをrespositoryで管理していますが、テストができてなかったので、それを解消すべくTravis-CIでやってみました。 .travis.yml language: ruby script: - cat crontab.ok.txt | crontab - cat crontab.fail.txt | crontab travisで実行された様子 意外なことに簡単に動いた。 Travisはcrontabが登録されても実際にはコマンドが動かない、はず。 songmuさんのParse::Crontabも非常に良いのですが、今のプロジェクトはPerlのプロジェクトではないので若干入れにくい。 参考 おそらくはそれさえも平凡な日々: 運用におけるcrontabのテストとParse::Crontab 第25回 cron周りのベストプラクティス（1）：Perl Hackers
Complete list of new features in MySQL 5.7
There are over 150 new features in MySQL 5.7. The MySQL manual is very good, but verbose. This is a list of new features in short bullet form. I have tried very hard to make sure each feature is only mentioned once. So InnoDB native partitioning could be mentioned under either InnoDB or partitioning. Multi source replication [1] Online GTID migration path [1 2 3] Improved semi-sync performance [1
Flying faster with Twitter Heron
We process billions of events on Twitter every day. As you might guess, analyzing these events in real time presents a massive challenge. Our main system for such analysis has been Storm, a distributed stream computation system we’ve open-sourced. But as the scale and diversity of Twitter data has increased, our requirements have evolved. So we’ve designed a new system, Heron — a real-time analyti
嫁に休日を。育児１日丸々やった - #はるはら日記
赤ちゃんの世話、普段はできる限り手伝っているのだけども 原稿が追い込みの時期になるとあまり手伝えなくなり ほとんど嫁に任せっきりになってしまった 任せっきりで数日たった時 これはヤバイ 嫁を休ませないと嫁の心が折れちゃう！ と 原稿が一段落ついた所でスケジュールを見直し ボクが１日赤ちゃんをみとく日を作った 今までも１日２～３回はミルクあげる役やってたし オシメもけっこう変えてた お風呂にだって入れている だから１日まるまるだって余裕だって思ってた 甘く見ていた 嫁から赤ちゃんを預かり 最初にした事をミルクあげだった うちの子はだいたい３時間に１回ミルクを欲しがる ちょうど前回のミルクから約３時間 ミルクの時間だったのだ ミルクをあげたらゲップをさせる その後寝かしつけ この寝かしつけの儀式が長い 寝るの自体は５分くらいで寝るのだが 寝たと思ってすぐ下ろすと泣き叫ぶ 寝かした後深い眠りに落
プログラミングスタイルガイドのスタイルガイド - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 本文書は、プログラミング言語向けのスタイルガイドに向けたスタイルガイドである。 本文書へのフィードバックはQiita上のコメントにて受け付ける。 構造 対象を明確にする そのスタイルガイドがどのような状況のどのような対象に向けたスタイルガイドであるか規定すること。 状況や対象は広すぎてはならない。 理由: 対象はスタイルガイド記述者には自明かもしれないが、似て非なる言語に誤用されたり、特定分野のアプリケーション向けスタイルガイドが他分野のアプリケーションを理不尽に拘束したりすることがある。これを防ぐべきである。 良い例: 「本文書はRu
言ったもの勝ち/言わないと伝わらない - サンフランシスコではたらくソフトウェアエンジニア - higepon blog
今回のブログは短く。同僚・上司たちは「日本人的な空気を読む」ことはしません。というか無理。 例1 ある日の 1 on 1にて 上司「というわけでこんなプロジェクトがあるんだけどどうかな？」 僕「・・・（うわあ。これは炎上しそうなプロジェクトだな避けよう）」 僕「（困惑顔かつ拒否オーラを出しつつ）考えさせて下さい」 上司「オーケー分かった！」 翌週の 1 on 1 上司「例の件考えた？（結構乗り気だったよね？）」 僕「（いや。空気読んでくれよ・・・いやだよ）」 この場合の1つの正解は最初の 1 on 1 で率直に「ごめん。炎上しそうなのであまりやりたくないな」とか「やってもいいけど。xxx な条件なら」などとはっきり答える。 例2 上司「おい。ひげぽん。Android の仕事が入ったぞ。やってくれ。」 僕「（え。僕 iOS が好きって言ったのに・・・断りづらい）」 この場合の1つの正解は「i
AWS のセキュリティ関連資料（セキュリティ三部作）を読んだ - ようへいの日々精進XP
自分メモ。 追記 aws.typepad.com DDoS に関するホワイトペーパーも日本語訳されて公開されている。後ほど読みませう。 tl;dl こちらに紹介されている資料をダウロードして読んでみた。 セキュリティプロセスの概要 AWS セキュリティとコンプライアンス AWSのセキュリティについて 内容をちゃんと把握は出来ていないが、以下に雑にメモる。 感想等 読んでみて セキュリティプロセスの概要 はホワイトペーパー（全 27 ページ）でほぼ文字だったが、各 AWS リソースのセキュリティ実装について触れられていた AWS セキュリティとコンプライアンスと AWSのセキュリティについてについては上記のホワイトペーパーをわかりやすく解説するような構成になっていた ピックアップキーワード 責任分担モデル（セキュリティ共有モデル）→ AWS はインフラ部分のセキュリティに責任を持つ セキュリ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
msgpack-lite ピュアJavaScript実装の速いMessagePackライブラリ - Qiita
