PowparkA short article on how we implemented a proof of concept for a Filecoin oracle on Ethereum during PL hack week.
DevOpsに欠けている二つのピース
最近、取材先から「DevOps（デブオプス）」の話題を聞くケースが増えてきた。DevOpsに厳密な定義はないが、一般的には「開発チームと運用チームが一丸となり、ビジネス上の効果を高めるため、短サイクルでシステムを改善し続ける取り組み」といった意味だろう。 このうち「ビジネス上の効果を高めるため、短サイクルでシステムを改善し続ける」という部分に着目すると、現在のDevOpsには、大事なピースが二つ欠けているように思う。 一丸となるべきは開発と運用だけではない その一つは「利用部門」である。 ビジネス上の効果を高めるシステム改善を行う上では、利用部門が起点になる。利用部門が既存システムの改善要望を出し、それを開発チームと運用チームが一丸となったITチームが受け付け、実現していく。その際、改善要望を単に受け付ければいいわけではない。詳しくは後述するが、利用部門に要望の目的を確認したり優先順位付け
dstat経由でredis infoを眺めfluentdを通してgrowthforecastでグラフにする - maaash.jp
dstat が万能なのでredis infoのキーを眺められるプラグインをつくった。 redis-cli info の total_commands_processed を眺める場合。 DSTAT_REDIS_* な環境変数を設定することでなんでもできるし fluentd-plugin-dstatを使う場合には環境変数がいじりにくかったので同じディレクトリにある設定ファイルを使ってもいい。 # td-agent/templates/default/td-agent.conf.erb <source> type dstat tag dstat.<%= node[:hostname] %> option --redis delay 30 </source> <match dstat.*> type map tag "mapped." + tag time time record record[
Creating Efficient Docs with API Documentation Tools | AppMaster
Flexibility and scalability have become an integral part of modern systems, and application program interfaces (APIs) play an essential role in providing such features. It is important to build efficient APIs to provide modern web services. Since coding and development are all about the team's efforts, it is important to use reliable API documentation tools to keep thorough records and ensure the
Replace Rake with Thor
Okay, let’s be honest, when was the last time you actually wrote a unit test for a Rake task? My guess is NEVER. Unit testing Rake tasks is a pain in the ass to say the least. Most developers “work around” unit testing Rake tasks by extracting logic out of the Rake task and into an actual unit testable Ruby object, still leaving the actual Rake task untested. This may be acceptable for some develo
デザインの裏側を理解できるエンジニアになろう - Qiita
「画面」のデザインは、エンドユーザーから見た「プロダクト」との唯一の接点。超大事。 そんな画面のデザインにまつわる、エンジニアが「いじる」ときに気をつけると、もしかしたら面倒が減って争いが減ってみんなが幸せになれるんじゃないかなあ、とか、そもそもの設計上で考慮できると、もしかしたら使う人たちが幸せになれるんじゃないかなあ、というポイントを、思い付きで書いていくので、あとは誰か整理してほしい的な投げやり感あふれるアレコレ。デザインとコーディングの話を混ぜて書いてます。 空白の理由を考える編 その1. 空白にまつわる認識の相違 例えば、Tumblrのダッシュボード。右肩のメニューの隅までちゃんとレイアウトされてるなーって感じがします。 でも、もしあなたが「空白を理解しないエンジニア」だった場合、こんな感じにコーディングしてしまうかもしれません。 （※画像はイメージです） 「なーんか、素人感があ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
