Docker、OCI やめるってよ : 革命の日々 その２
週末のTwitterの応酬が面白かったのでメモ タイトルはもちろん「桐島、部活やめるってよ」のパクリですが、わたしはこれ見たことないです。 Kelsey Hightower （GoogleのKubernetesの中の人） がまず燃料投下 There are many application platforms that support Docker images without the Docker daemon. Which one was first I have no idea. — Kelsey Hightower (@kelseyhightower) 2016年7月28日 Dockerアプリ動かすのってもうDocker純正エンジンいらないよねー もちろん（Docker CTOの） Solomon Hykes は反論 @kelseyhightower pseudo-support.
IT芸人が訊く、なぜ優秀なおっさんエンジニアを次々と採用できるんですか？（前編） | HRナビ by リクルート
変化の激しいエンジニアの世界で、どうすれば成長し続けられるのか。飲食店向け予約台帳アプリを手がける「トレタ」の増井雄一郎さんが、そのヒントを解説する連載がリニューアルしました。今回からは、「IT芸人」の異名を持つ増井さんが今、気になる人に直撃。エンジニアとしてのキャリアパスや最新のテクノロジーなどについてインタビューします。 今回登場いただいたのは、プログラマ向け技術情報共有サービス「Qiita」を運営するIncrementsの海野弘成社長。同社には昨年11月、元グーグルの及川卓也さんが入社、その前後にも著名なエンジニアがジョインしています。なぜ、いちベンチャー企業が次々と優秀なエンジニアを獲得できたのかーー海野さんに聞きました。 ※後編はこちら IT芸人が訊く、おっさんエンジニアが“老害”にならないために 平均年齢20代の会社に40代が入社……摩擦はなかった？ 増井：海野さん、今日はよろ
私のソースコードの書き方 - @kyanny's blog
note.mu なるほど自分も同じような感じでやっているなぁ、と思った。もうちょっと詳しく書くと、 まず変更しようと思っている部分の周辺のコードを読んで、「ここらへんをいじればよさそう」と当たりをつける（当たりのつけかたにもいろいろあるのだが後述） 土地勘を養ったところで具体的な変更の仕方を考える。必要に応じて紙に下手くそな図を書いたり、考えを箇条書きにしたり、実際にコードを試しに変更してみたりする この方針でいけそう、と道筋が見えたらいよいよコードを書き始める。細かい単位でコミットするかどうかは場合によるが、少なくとも git add はこまめに行う（エディタの undo でせっかく書いたコードを失わないため） 道筋が見えなかったり、プロトタイプ的に書いたコードが望み薄そうだったら潔く諦める。煮詰まっていることを自覚して、コーヒーを買いにいったり、オフィスの外を散歩したりして頭をリフレッ
現実世界のマイクロサービス：サービスに陰りが見え始め、いよいよ本気になるとき | POSTD
マイクロサービスを用いれば、エンジニアリングチームは迅速にプロダクトを拡大することができます……もちろん、彼らが分散システム運用の複雑さのせいで泥沼にはまっていなければの話です。本記事では、マイクロサービスの運用に関わる非常に厳しい問題―例えば大規模なサービスのステージングやカナリアデプロイなどの問題―が、RPC層に ルーティング の考え方を導入することにより、どう解決できるのかを説明します。 私は、Twitterでインフラのエンジニアを務めていた時代（2010年から2015年まで）を振り返ってみました。すると、当時はそういった言葉がなかったというだけで、私たちは「マイクロサービスを使っていた」のだということが分かります（当時は、今思えば分かりにくい言葉、 SOA ＜サービス指向アーキテクチャ＞と呼んでいました）。 バズワードはさておき、当時も、現在私たちがマイクロサービスを使おうとする動
Almin.js | JavaScriptアーキテクチャ
autoscale: true Almin.js | JavaScriptアーキテクチャ 自己紹介 Name : azu Twitter : @azu_re Website: Web scratch, JSer.info 中規模以上のJavaScript 設計が必要になる 正しい設計はない Bikeshed.js :bike: 人、目的、何を作るかによってアーキテクチャは異なる 前回の続き? How to work as a Team Read/Write Stack | JavaScriptアーキテクチャ 用語 設計の目的 中規模以上のウェブアプリ SPAというよりは、画面が複雑なElectronアプリのようなイメージ スケーラブル 人、機能追加、柔軟性、独立性 見た目が複雑ではないアーキテクチャ 書き方が特殊ではなく見て分かるもの 設計の目的 テストが自然に書ける パーツごとに無理なく
ソースコードって実際のところどういうふうに書いていますか？｜Rui Ueyama
私はプログラミングは結構自信があるんですが、他の人の作業をつぶさに観察したことがあるわけでもないので、自分で当たり前だと思っているコーディングの方法が他の人にとってはそうではないこともあると思ってます。上手い人がどういうふうにしてプログラムを書いているのか知りたいんですよね。 逆に私はどういうふうに書いているかちょっとまとめてみました。自分はこうしている、というのがあったらぜひ教えてください。 まず私の場合、ゼロからコードを書くよりも現在のプロジェクトのためのコードを書くことのほうが多いので、コードを書くというのは既存のコードに変更を加えることがほとんどです。既存のコードに手を加えるときは、新機能追加か、リファクタリング（動作は変えずにコードをきれいにすること）のどちらかになるわけですが、まず前者をどうしているかどうかをできるだけ説明してみます。 まず必要なのは考えることです。よく知ってい
Mojolicious 7.0 released: Perl real-time web... - Sebastian Riedel about Perl and the Web
I’m excited to announce the release of Mojolicious 7.0 (Doughnut). While the community around Mojolicious keeps growing, you might be surprised to hear that the distribution itself has actually been shrinking. This is a very good thing, even with all the features we added over the years, we’ve managed to reduce the code size from 11247 lines in 2010, to 8490 lines today. As you can see, it’s not a
Redis 本番障害から学んだコードレビューの勘所
Redis不適切利用による問題は本番運用が始まってから顕在化することが多く、時限爆弾みたいな存在です。事前に防ぐにはコードレビュー段階で叩くしかありません。 Redisはスクリプト言語と相性が良く、適切に利用するとRDBと比較し驚くほど高速なプログラムを組むことができます。昨年尊敬する先輩にコードレビューで斧100本くらい(レビューコメント)投げられて血まみれになりつつ学んだことを、まとめて書いてます。概要は『消えても良いデータならRedis』 Redisのメモリが溢れたら... （この話は事実ではなくファンタジーです。） 深夜電話で叩き起こされました。どうやらアクセス障害みたいです。 何人かで実機確認したら、まったくゲームが遊べない。データ不整合怖いのでメンテIN。 ほどなくしてRedisが溢れメモリ不足で新規書き込みが出来なくなっていると判明。サーバのメモリ容量は64GByteでこれ以
httpoxy
Recommended reading Summary What Is Affected Immediate Mitigation Prevention Interesting, but once you’ve mitigated How It Works Why It Happened History of httpoxy CVEs A CGI application vulnerability (in 2016) for PHP, Go, Python and others httpoxy is a set of vulnerabilities that affect application code running in CGI, or CGI-like environments. It comes down to a simple namespace conflict: RFC 3
飲食店向けITサービスのカオスマップ作ったよ : TORETA（トレタ） ブログ
さて、昨年大好評をいただいた外食経営者向けカンファレンス「FOODiT TOKYO 2016」の開催が迫ってまいりました。開催は8月22日。リンク先を見ていただければお分かりいただけると思いますが、今年も去年以上に豪華な皆さんが登壇します。 未来に向けた刺激的な議論がたくさん交わされる場になるんじゃないかな！本当にここから外食の未来が生まれるんじゃないかな！そんな予感がひしひしとしております。 そこで、そんなワクワクした気持ちをより高めるため、今年も飲食店向けITサービスの「カオスマップ」（この類の図表って『カオスマップ』って言うんですって）を作りました。2016年版です。 （※2016/8/18更新しました）
作業が早いプログラマーと遅いプログラマーの差の比は4:1
An empirical study of working speed differences between software engineers for various kinds of task プログラマーの作業速度には差がある。作業速度が早いことだけをもって優秀なプログラマーとは限らない。そのソフトウェアの保守性が悪いかもしれないからだ。しかし、やはり作業速度の早いプログラマーは優秀と見られがちだ。特に、転職界隈では、優秀なプログラマーは、その作業速度の速さを形容して、「ニンジャ」とか「10倍プログラマー」などというタイトルで喧伝されている。さて実際には、プログラマーの作業速度は、全体としてどの程度違うのか。 プログラマーの作業速度が早いものと遅いものの比は、従来、28:1であると言われてきた。この数字には根拠となる研究がある。1967年にGrantとSackmanが公開した論文
DB Tech Showcase Tokyo 2016 で発表しました。MySQL 5.7の新機能 〜InnoDB編〜
表題の通り、db tech showcase Tokyo 2016にて、MySQL 5.7の新機能についての解説を行った。スライドをアップロードしたので、セッションに来てくれた方も、見逃したという方もぜひ見て頂きたい。 What's New in MySQL 5.7 InnoDB from Mikiya Okuno 思えば、4年前のdb tech showcaseでMySQL 5.6の新機能について解説したときは、1回のセッションですべての機能を詳解することができた。ところが、MySQL 5.7に至っては、昨年MyNA会でオプティマイザ関連の新機能についての解説を行ったのに続き、今回はInnoDBの新機能だけに的を絞った解説となった。このように小出しにしているのにはワケがある。いや、そもそも小出しにしているというつもりはない。単にMySQL 5.7の新機能が多すぎて
トレタの雰囲気と強さを象徴するカウンタースペースでのコミュニケーション : TORETA（トレタ） ブログ
今回はトレタオフィスのワークスペースなかでも、とても特徴のあるカウンタースペースについてご紹介したいと思います。昨年9月末に恵比寿から移転してきた五反田のオフィスにもすっかり慣れ、ここでなければなかった文化も生まれています。 カウンタースペースには朝から常に人がいて仕事をしています。主にいるのは開発メンバーですが、職種や用途に関係なく良いコミュニケーションの場になっています。集中したい時はデスクや集中ブースに移動したりというように、メリハリをつけやくすなっているのも、トレタのオフィスの特徴です。 こうした環境の中で特に良いなと思うのが、開発メンバーとセールスメンバーのコミュニケーションです。お互いの職種の違いもあってか、特にセールスメンバーからすると集中している開発メンバーに声をかけづらい。というのはあると思います。ところがトレタのカウンターでは、開発メンバーのそんな雰囲気にも隙があるよう
良く分かる「みずほ銀行デスマーチ」
やあ、デスマーチってるかい？ 実はデスマーチ基準ってのがあって、7時間寝られるか。 なんと自宅に居る時間は5時間だけ？継続してたらデスマーチよ。 法律守って作業者が自宅に9時間いられるようにマネジメントするのがお仕事。 （鎮火の初動は、終電まで働かせといて健康管理は自己責任とか言う人の排除から） というわけで、みずほ銀行が最近また話題になったので、振り返ってみよう。 銀行の権力闘争が根本原因さて、みずほ銀行の吸収合併は、こんな感じ。 みずほコーポレート銀行＜改名＝富士銀行←日本興業銀行みずほ銀行＜改名＝（第一勧業銀行←富士銀行のリテール部門）←（みずほ統合準備銀行←日本興業銀行のリテール部門）で、記憶に新しい2011年の東日本大震災システムトラブルの影響で、 システム刷新して再発防止するぜ！というのが2012年スタートの話。 みずほ銀行＜改名＝みずほコーポレート銀行←みずほ銀行 （一体化し
Movable Typeを開発するシックス・アパート、経営陣と従業員の持ち株会社が全株式を取得。独立した企業として再出発
Movable Typeを開発するシックス・アパート、経営陣と従業員の持ち株会社が全株式を取得。独立した企業として再出発 Movable Typeは2000年代にはじまるブログブームの火付け役として登場したCMS（コンテンツマネジメントシステム）です。そのMovable Typeを開発する企業「シックス・アパート」は7月4日、経営陣と従業員が立ち上げた持ち株会社が親会社であるインフォコムから自社の株式を全株取得し、新体制となったことを発表しました。 シックス・アパートはもともと、Movable Typeを開発したベン・トロット、ミナ・トロット夫妻によって2001年に米国で創業された企業です。2002年にブログメディアとして登場したGizmodoや、2003年に登場したブログ検索エンジンのTechnoratiなどとともに、初期のブログブームを牽引する企業の1つでした。 その後同社は多くの企業
Rubyist Magazine - スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on Rails (モデル編)
『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0063 号 バックナンバー Rubyist Magazine 0063 号 Rubyist Magazine 0062 号 Kaigi on Rails 特集号 RubyKaigi Takeout 2020 特集号 Rubyist Magazine 0061 号 Rubyist Magazine 0060 号 RubyKaigi 2019 直前特集号 Rubyist Magazine 0059 号 Rubyist
海老蔵の取材自粛要請に週刊誌が応じない理由｜新聞・週刊誌「三面記事」を読み解く｜ダイヤモンド・オンライン
市川海老蔵氏が記者会見やブログで実家周辺への取材自粛を要請した。メディアはどう対応すべきなのか Photo:AFLO 市川海老蔵夫人・小林麻央さんの闘病が報じられている。ずいぶんと前になるが、ある狂言師一家に密着したり、七代目市川染五郎さんら歌舞伎役者に取材した際、彼らの幼少時の稽古の厳しささながら、“梨園の妻”の大変さを教えてもらったことがある。 歌舞伎役者に嫁ぐからには命をかける覚悟がなければ務まらないと言われたほどで、だから麻央さんの回復は私も願ってやまないが、他方、海老蔵氏が要請したという取材自粛のお願いにはちょっと首を傾げているのである。 〈人の命に関わることです。よろしくお願いします。マオ本人の負担になるような撮影はやめてください〉 今月十日夜のブログに、海老蔵氏はこう綴った。そして、九日に会見を開き、麻央さんの病状を打ち明けたのは、実家周辺への取材を自粛してほしかったからだと
モバイルアプリ開発者のための mitmproxy 入門 - Qiita
はじめに モバイルアプリを開発しているときに、アプリとサーバー間の通信を確認したいときがあります。たとえば、期待通りの HTTP リクエストが送られているか調べたり、サーバーからのレスポンスが間違っていないか確認したりする必要が生じます。 そんなときに、いちいちデバッガで止めても良いのですが、プロキシをはさめば簡単に通信を覗くことができます。しかも、レスポンスを改竄して、わざと不正なレスポンスにしてアプリがクラッシュしないかテストしたり、特定のリクエストだけブロックしてサーバー障害を擬似的に再現することができます。 mitmproxy とは mitmproxy は man-in-the-middle 型のプロキシサーバーのツールです。OS X や Windows、Linux 上で動作し、対話式の CUI を持ちます。SSL サポートをしている点が特長になります。 公式サイト: http:/
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
CloudFrontをかますとキャッシュなしのAPIコールでも速くなるようだ : sonots:blog
ウェブサービス型CMS「MovableType.net」、無料での常時SSL化に対応 
