mruby-cliがアツいですね - Kentaro Kuribayashi's blog
昨今、Goのような言語が注目されているのにはいろんな理由があるかとは存じますが、こと運用の面に関していうと、バイナリをビルドしてポン置きすればマルチプラットフォームで動くということが簡単にできることも大きい。Goは、個人的には好きな言語だが、Rubyで書けると楽な場面も多々ある(Concurrencyが問題でないツールなどは特に)。そんな時に有用なのが、mruby-cliだ。 github.com 具体的な利用例としては、「mruby-cliを使ってプロセスのfdをリソース使用率を元に解析するワンバイナリなツールpfdsを作った - 人間とウェブの未来」に詳しい。ローカル(Mac OS Xなど)でさっとビルドして、本番環境(x86_64上のLinuxなど)にポン置きしたら動く。便利。 mruby-cli特有のお作法と、mrbgemに対する知識が必要ではあるものの、そのあたりをクリアしさえす
mruby-hibariで、ngx_mruby、mod_mruby、h2oで同じコードを使えるようになった - delirious thoughts
「Webサーバへの組み込みmrubyのRack-based APIまわり」の続き。 Rack-basedなAPIに対応したWebサーバ用のWebアプリケーションフレームワークのmruby-hibariですが、ngx_mruby、mod_mruby、h2oいずれのサーバ上でも同じコードで動く感じになりました。 github.com mrubyでハンドラを書くわけですが、その際、書き方を好みに応じて使い分けられるよう、ふたつスタイルを用意しました。 DSLぽい感じ: hibari do res.code = 200 res.headers["content-type"] = "text/html; charset=utf8" res.body.push("Hello, World!") req.params.each do |k,v| res.body.push("#{k}: #{v}") e
岸政彦『断片的なものの社会学』 - Kentaro Kuribayashi's blog
まさに「断片的なもの」への興味というのはずっとあったのだし、しかし、だんだんとそういうのを忘れていってしまい、そういうのがわからなくなってしまってきているのを反省したいなと思ったりして、読んだ。素晴らしい本。 断片的なものの社会学 作者: 岸政彦出版社/メーカー: 朝日出版社発売日: 2015/05/30メディア: 単行本（ソフトカバー）この商品を含むブログ (11件) を見る イントロダクション - 分析されざるものたち 人生は、断片的なものが集まってできている 誰にも隠されていないが、誰の目にも触れない 土偶と植木鉢 物語の外から 路上のカーネギーホール 出ていくことと帰ること 笑いと自由 手のひらのスイッチ 他人の手 ユッカに流れる時間 夜行バスの電話 普通であることへの意志 祝祭とためらい 自分を差し出す 海の向こうから 時計を捨て、犬と約束する 物語の欠片 あとがき 岸政彦『断片
メタ・マネジメント: ビジネスと技術とDXの均衡点を探ることと、その均衡をぶち破ること - Kentaro Kuribayashi's blog
今日、エンジニア職位制度に基づく面談をしていて、自分の職務のうちのひとつを言語化したということがあったので、メモっておく。 CTOとは何か？ CTOというのがなにをする役職であるかについては、基本的には以下のスライドで述べた通り。 上記で述べられている、4つのマネジメント対象のうち、ヒトについては全ての基盤になる要素であり、あとの3つを別の言葉でいいかえると以下の通りとなる(それぞれに重なる部分はあるが)。 モノ: 技術 カネ: 事業 情報: DX(デベロッパー・エクスペリエンス)*1 3要素のバランス 組織の成長を最大化するという前提において、3要素それぞれについてバランスよくマネジメントして、そのいずれもが良い状態にあることが目指すべきところである(下図(1)の状態)。 その3つをうまいこと取り持つことで、上記の(1)のように3つのどれもに重なる部分を得られる時、技術マネジメントがうま
エンジニアとしていかに成長するかについて、GMOグループの新卒エンジニア・クリエータの皆さんにお話した - Kentaro Kuribayashi's blog
GMOグループにはGMOテクノロジーブートキャンプという新卒エンジニア・クリエータ向けの研修メニューがあって、そこでなんか話してくれという要請があったので、「エンジニアになる」というタイトルで、エンジニアとしての成長について、少しお話をしてきました。 自分自身がエンジニアとしていままでどうしてきたかみたいな話は、まとまった形ではこれまでしたことがなかったわけですが、立場上とか年齢的にも「僕ごときが……」とかいってもいられないので、恥を忍んでスピリチュアルな話をしてみました。以下、ご笑覧くださいませ。 いいたいことはだいたいスライドに書きこんだのですが、以下、ちょっとだけ補足。 このスライドを作っていた時に、ちょうど「現場ロックイン」についてのエントリが話題になったり、また、このエントリを書く直前にも似たような話題のエントリを見たりしました。 現場ロックインが技術力さげてるのかもしれない -
情報価値の高いスライドを作るために - Kentaro Kuribayashi's blog
役職が変わったりしたこともあって、取締役会のみなさんに説明したりエンジニアのみなさんに考えを伝えたりなど、社内向けにもいろんな資料を作る必要も増えてきて、そういうのが増えること自体どうかというのはともかくとして、エンジニアとしてより活動を広げていくためには、そういう文脈における資料の作り方を身に付けるというのも、ひとつのスキルアップではあります。 これまでもかなりの量のスライドを作ってきたわけですが、そのほとんどが技術イベントで話すためのもので、それはそれでいろんな工夫をしてきたつもりではあっても、コンテキストが違うと、ただ一本調子で同じようにやってもうまくはいかないわけです。上述の通り、昨年後半以降、そういうことが増えてきて限界を感じたので、あらためてものの本を読んだりして学習してみました。 コンテキストの違い ここでいうコンテキストとは、エンジニアだけを対象にしているというよりは「経営
書評『pixivエンジニアが教えるプログラミング入門』 - Kentaro Kuribayashi's blog
著者のid:catatsuyさんよりご恵贈いただきました。ありがとうございます。 pixivエンジニアが教えるプログラミング入門 (星海社新書) 作者: 金子達哉出版社/メーカー: 講談社発売日: 2015/03/26メディア: 新書この商品を含むブログを見る 本書は、先日紹介した『Webエンジニアの教科書』とは異なり、プログラミングの基礎が多少はある人に向けてWebプログラミングの概要を教える本ではありません。 例えば次のような方にオススメをします。 システムエンジニアやプログラマーとプロジェクトを共にする、Webディレクター/デザイナーの方 プログラミングに興味はありつつも、なんとなく難しそうではじめるきっかけが掴めない方(10年前の著者) 就職/転職の結果、全くの未経験からシステムエンジニアになることになった方 プログラミングによって何か動くものが作ってみたい方 (本書p.2) その
GMOペパボ株式会社の執行役員CTOに就任しました - Kentaro Kuribayashi's blog
昨日(3/21)、GMOペパボ株式会社の執行役員CTO*1に就任しました。昨年8月に技術責任者に就任したのですが、今後はより一層、経営に近い立場で「技術」という切り口において会社の成長に貢献していきたいと思います。 今後やっていくこと 今後やっていきたいことを整理すると、以下の3つになります。 成長のための技術戦略の策定・実行 1.を実現するための技術基盤づくり 1.を実現するための組織づくり これまでも「GMOペパボ攻勢の裏側にあった「技術的負債を抱えない開発体制づくり」3つの布石 - エンジニアtype」にある通り、あれこれやってきましたが、より踏み込んだ戦略を立て、実行していくつもりです。また、それぞれにおいて各論的にいろいろ考えていることはあるのですが、細かいことをここで述べてもしかたないでしょう。このブログでもこの1年あまり、上記についてあれこれと書いてきたので、是非そちらをご覧
全社的に使っているチャットツールをSlackに移行した話 - delirious thoughts
ペパボでは、チャットツールとしてIRCを長らく使っていたのですが、先日、Slackに全面的に移行しました。その話を少し書いてみようと思います。 追記: 社長的にSlackに移行したほうがいい理由 | ペパボ社長ブログというエントリが出ていたので、そちらもご参照ください。 IRCの利用程度 そもそもIRCをどの程度使っていたかというと、職種や役職等を問わず、全スタッフ(アルバイト等も含む)が使っていました。つまり、エンジニアも総務も、マネージャーも社長もみんなIRCにいて、そこでフローのコミュニケーションを行っていたということです(ちなみに、情報のストックや、チャットには向かないような共有にはGitHub Enterpriseを使っています)。また、サーバの状態監視等の様々な通知や、いわゆるChatOps的なこともIRCでやっていたので、人間もbotもとにかくたくさんいて、賑やかな状態です。
gRPCでgdbmにネットワークインタフェイスを持たせる - Kentaro Kuribayashi's blog
先日、HTTP/2とProtocol BuffersをベースにしたRPCフレームワーク、gRPCがリリースされた。 Google Developers Blog: Introducing gRPC, a new open source HTTP/2 RPC Framework Microservicesがなんちゃらいわれる昨今だが、その実現のためには、設計面におけるベストプラクティスはもとより、実装面においても課題がある。すなわち、サービス間でどのようにオーバーヘッドが少なく、帯域を浪費しない通信を実現するかということ。そんな折Googleが、上記のリンク先にある通り「うちらめっちゃMicroservicesだし」ってんで、まさに「これだ!」という技術スタックでいい感じのものを出してくれた。 gdbmにRPCしてみる とりあえず試してみたいので、簡単にできそうな例として、gdbmにネットワ
Slack用のIkachanを作った - Kentaro Kuribayashi's blog
最近、社内のチャットツールをSlackに移行しつつある。ペパボではIkachanをヘヴィに使っているので、移行に際してはそこをどうSlackに移行するかが問題となった。というわけで、Ikachanと同じインタフェイスでSlackにメッセージを送れる簡単なツールを作成した。 kentaro/takosan Ikachanを使っているひとには特に説明の必要もない感じ。詳しくはREADMEを見てほしい。go getしたら、 $ SLACK_API_TOKEN="YOUR SLACK API TOKEN" takosan [-host string] [-port int] [-name string] 以下のように起動して、あとは $ curl -d "channel=#channel&message=test message" localhost:4979/privmsg とかするだけ。簡単で
エンジニア専門職のグレードについて詳細な役割定義は必要か？ - Kentaro Kuribayashi's blog
様々な人々から、エンジニアに関する制度についてインタビューされる機会が増えてきた。その中で考えが整理されてきたパーツもあるので、せっかくなのでまとめておこうと思う。 ペバボのエンジニア職位制度のアップデートについてなどで書いている通り、ペパボはエンジニア専門職制度を制定し運用している。その前提として、専門職制度がどのような位置付けかというと、簡単に示すと以下の図の通りである。 この構造自体は特になんの変哲もない、わりと一般的な制度だといえるが、我々はこの中にひとひねり加えている。以下に説明する。 前提知識 ただし、その前に人事制度における前提的知識について述べておかないとならない。 社員格付け 昨今は「フラットな組織」「ネットワーク型組織」などというものも出てきているが、それはそれとして、一般に企業組織は、その構成員をなんらかの方法を用いて格付けしている。すぐに思い浮かぶのは、部長とか係長
RESTが日本で受け入れられていった頃の話( #mozaicfm の補足) - Kentaro Kuribayashi's blog
mozaic.fm第7話のRESTの話で、RESTが日本で広く受け入れられていった頃、というか、その端緒の頃の話が出ていて懐かしかったのだし、細部にやや不正確なところがあるのが気になったりもしたので、補足を書いておきますね。 まず、いわずとしれた@yoheiさんがRESTをまず知ったのが2003年とかそれぐらいの時期とおっしゃっていて、それから数年経ち、RESTがWebエンジニアに広く受け入れられていったのは、2007年末にリリースされ、resourcesという機能を取り入れたRails2からというのは、@t_wadaさんがおっしゃっている通り、事実だろうと思います。 また、Podcastの中では、主催のJxckさんが、それはそれと認めた上で、彼自身にとってはAjaxの登場が大きかったということを述べた上で、@yoheiさんの主催された第八回XML開発者の日での高橋征義さんとid:seco
`gate`をGitHub対応した - Kentaro Kuribayashi's blog
Google認証なリバースプロクシ＆静的コンテンツ配信サーバー「gate」 - unknownplace.orgで紹介されている、typesterさんのgateという、GoogleのOAuth2認証付きプロキシサーバがとても便利そうだったので、即座に使いたくなった。 これは、昨今増えつつあるメトリクス系のツールだとかの、インターネット上に置きつつも、社内のみに提供したいサービスを立てるに際して、フロントにnginxをおいた場合に、認証のことを考えるのがだるい、というか、nginxの設定自体がだるいみたいなときに役立つツールです。その際、自分とこ的にはGitHubのorganizationでアカウント管理できるとさらによいので、GitHub対応をしてpull requestを送ったところmergeされました。ありがとうございます。 会社で運用しているorganizationがfoo_orga
RailsでTypeScriptを使う - Kentaro Kuribayashi's blog
JavaScriptは設計が難しい。経験上、すぐグシャグシャになってしまう。よくわからなくなる。もちろん、私のスキル不足というのはあるだろうけれども、スキルが不足してるのはしかたないので、学習は続けることは前提であるにしても、技術的に解決できるなら技術に頼りたい。そうした意味で、いわゆるAltJSの中ではTypeScriptが有望だろうと思う。 RailsとTypeScript TypeScriptを使うにしても、それ単体で使うというシーンは、Webアプリケーション開発という文脈ではあまりない。たとえば、Railsで開発しているWebアプリケーションのフロントエンドを構成する言語として使うことになるだろう。その際、まず考えるべきことは、Asset Pipelineとどう折り合いをつけるかということだろう。 Asset Pipelineは、以下の機能を担っている: 拡張子(例:applica
Casto: 史上最速にライブコーディングができるサービス - Kentaro Kuribayashi's blog
CastoというWebサービスがあります。史上最速に、インターネット経由でライブコーディングができる、非常に素晴らしいサービスです。その素晴らしさのわりにまだあまり知られていないので、紹介します。 Castoでライブコーディングを始めるには、ふたつの方法があります。 CastoのWeb UIから、ライブコーディング対象のファイルをドラッグアンドドロップする castoコマンドを用いる 後者のコマンドの例は、作者によって以下の様なアニメーションGifで紹介されています。 ↑の画像では、Casto上のURLをコピペしてブラウザで開いていますが、--browseオプションをわたすと自動的にブラウザで開くよう、pull requestを送って、マージされております。 コマンドについては、最近追加されたのですが、さらに利便性が高まったと思います。是非お試しいただきたいサービスです。
ペパボのエンジニア評価制度をパワーアップした - Kentaro Kuribayashi's blog
mizzyさんのエントリ(paperboy is hiring - Gosuke Miyashita)にある通り、ペパボでは、エンジニアに関しては一般のラインとは別に、専門職としてのキャリアアップをしていくラインがあって、ここ2年ほど運用され、よく機能しているところです。そんな折、技術基盤チームも陣容が充実し、社内にもその存在や成果が充分に浸透してきただろうというわけで、半年ほど前からあたためてきた新しい制度を、先日から運用開始しました。 今回の制度は、上述の専門職としての評価制度はそのままに、既存の半期ごとの目標設定 → 評価サイクルの中に、エンジニア的観点をより盛り込んでいこうというものです。エンジニアであろうがなかろうが、一般に、事業目標をブレークダウンしたものが個々人の目標 → 成果になっていくわけですが、そうしたプロセスにおいて、より多様な観点からアウトプットの生産性を向上させて
情報共有の必要性について
本エントリは、社内向けに書いた記事を公開するものです。 なぜ情報共有するのか みなさんご存知の通り、コーポレートサイトにて、以下のように謳われています。 意見やアイデアは、ミーティング、社内SNS、メールなどで積極的に発言しましょう。不採用かもしれないと思っても、他のアイデアと合わさることで新しいものになることがあります。そのために、すべてのアイデアに耳を傾けると同時に、頭に浮かんだことをどんどん外に出しましょう。 また、インターネットで表現し続ける、コミュニケーションし続けることを楽しんで、自分たちが一番のユーザーであることを心掛けましょう。 大切にしてほしいこと | 採用情報 | 株式会社paperboy&co. このことからもわかる通り、様々なことに関してアウトプットを行い、広く共有することは、我々みなに求められていることです。 組織面からの理由 他にも理由があります。それは、我々が
ジェネラリストについて - Kentaro Kuribayashi's blog
専門を極めるとか職人技を鍛錬し続けるとかにすごく憧れつつもついついあれこれ手を伸ばしちゃって、よくいえばジェネラリストなんだけど、まあ普通にいって器用貧乏みたいな感じになっちゃうのは、性格的な問題もあるのでしかたないのかもとは思うけど、これだけはひとに負けないと誇れるみたいなのもやっぱほしいよなあとは思う。 とはいえ、では、誰でもがジェネラリストたり得るかといえば、そういうこともない。ジェネラリストであることと、なんでも中途半端ってのとは違うし、そもそもジェネラリストであることには適正があるんだとは思う。そうした適正というものを自分がそれなりに持っているのだろうとは思うので、それはそれでよい。 先日、まきもとさんと飲んでた時にそういう話になったのだけど、彼もまたそういうタイプで自分に近いと思っていたので、その点について話が合って面白かった。まあ、タイプという面で近いだけで、ジェネラリティの
サーバ管理の仕組みを作り始めた話 - Kentaro Kuribayashi's blog
先日(10/9)、riywoさんさんの呼びかけにより、サーバ管理をどうやったらいい感じなるかを話し合う会がもたれました。僕は、直接サーバ管理をやっているわけではないのですが、社内でそういうの欲しいという話をしていて、ツールを作りたいといっていたので、参考になればというわけで、お誘いいただいて参加してきたのでした。 riywoさんから、叩き台としてホストのキーを元にした統合的なAPIの構想を図式化したスライドを提示していただいた後、管理システムの主なユースケースや、各社の実際の管理手法などをいろいろお話をうかがいました。僕など、インフラ的な知識に乏しいもので、これはなかなか大変なことだなあというのがあらためてわかりました。 組織体制や経理ルールの複雑性が各社でだいぶ違う サーバの情報として必要な属性が各社でだいぶ違う そもそもサーバの情報が複雑 既にあるなんらかの管理の仕組みとの整合性を取る
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
