フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
KAIZEN platform Inc. の開発マネジメント
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
AWSユーザーは必ず覚えておきたいExponential Backoffアルゴリズムとは何か - yoshidashingo
cloudpackエバンジェリストの吉田真吾（@yoshidashingo）です。 Exponential Backoff 直訳すると「指数関数的後退」つまり、指数関数的に処理のリトライ間隔を後退させるアルゴリズムのことです。 詳しくはWikipediaに記載があります。 Exponential backoff - Wikipedia 日本語でブログに書かれている方もいらっしゃいます。 exponential backoffのメモ – Siguniang's Blog これを見ていると、どうやらこのアルゴリズムは古くから通信装置において、イーサネットフレームのデータ送信時にコリジョン（衝突）を検出したら一定時間待機して再送して、処理を完結させるためのアルゴリズムとして使われているようです。 通信機器の世界に限らず、アプリケーションの分野でも、大規模で予測不能な処理量を有限なリソースでさばく
「ビジネスvsエンジニア」の構造に持ち込むな チーム内外の信頼を勝ち取るマネージャーの処世術
「周囲の信頼を勝ち取っておく」大切さ 伊藤直也氏（以下、伊藤）：このへんは、トップマネジメント向けです。CTOやステークホルダーに近いマネジメントをやっている人に対して、すごく重要なことです。 マネージャーをやるとき、自分のチームをきちんとマネージしていくことも大事なんですけど、もう1つは、自分たちのチームが外からの信頼を得ておくこともすごく重要です。 これをやっておかないと、エンジニア都合の「工数取りたい」といったときに、いちいちロジックを組み上げなきゃいかないんですよね。 でも、「あの人が言うんだったらそうなんだろう」と思わせておくと、だいたいどんなことも、懇切丁寧に説明しなくても「まあ、任せるよ」とスッと通るようになるので、ここをきちんとやりましょう。 エンジニアの良くないクセですが、すぐ「エンジニアとビジネス」の対立構造に持ち込んで、「営業がうらちのことわからないからダメなんだ」み
CodeIQについてのお知らせ
2018年4月25日をもちまして、 『CodeIQ』のプログラミング腕試しサービス、年収確約スカウトサービスは、 ITエンジニアのための年収確約スカウトサービス『moffers by CodeIQ』https://moffers.jp/ へ一本化いたしました。 これまで多くのITエンジニアの方に『CodeIQ』をご利用いただきまして、 改めて心より深く御礼申し上げます。 また、エンジニアのためのWebマガジン「CodeIQ MAGAZINE」は、 リクナビNEXTジャーナル( https://next.rikunabi.com/journal/ )に一部の記事の移行を予定しております。 今後は『moffers by CodeIQ』にて、 ITエンジニアの皆様のより良い転職をサポートするために、より一層努めてまいりますので、 引き続きご愛顧のほど何卒よろしくお願い申し上げます。 また、Cod
naoyaのはてなダイアリー - コネクションプーリングの話
かなりながーいエントリになる予定なので,結論だけ最初に書くとこんな感じ. この話題については自分も あとで書く と言って書いてなかったので書いてみますよ。2006年の下期にもなってコネクションプーリングかよというツッコミもありそうですが、あとで書くといったら書くの。あとで読むといったら読む。 普通「コネクションプーリング」と言ったら、主に二つの役割があると思います。話を簡単にするためにウェブアプリケーションに限定して言及します。 ウェブアプリケーションから DB への接続を開けっ放しにして、接続に必要とされるオーバーヘッドをカットして双方の負荷を下げる。 ウェブアプリケーションと DB への接続を「使いまわす」ことで、同時接続本数を節約する。 というもの。 mod_perl で DB と接続維持するとコネクション数増えて云々という話は主に前者のみについての話になります。Apache::DB
同じようなキャリアを歩んでいる先輩が、他にいなかった 【Kaizen Platform 伊藤直也さん】｜【パソナキャリア】パソナの転職エージェント
「新天地に飛び出したい気持ちもあるが、今の会社に愛着があるから転職に踏み切れない……」 こんな悩みを持つビジネスパーソンもいるだろう。そんな迷いに対して、「自分も同じようなことで悩んだことがある」と言うのが、ウェブのエンジニアとして著名な伊藤直也さんだ。 伊藤さんは、新卒で入社したニフティでブログサービス「ココログ」の立ち上げに参画。転職先のはてなでは取締役CTOとして「はてなブックマーク」を開発し、グリーではソーシャルゲーム開発現場の統括を歴任した。現在は、サイト改善のA/B テストを提供するKaizen Platformで技術顧問を務める。 移り変わりの激しい業界で、傍目には常に正解と言える選択をし続けたように見える伊藤さんに、キャリア形成についてお話を伺った。 「周囲を自分好みに変化させたい」というのはエゴかもしれないと思った ――ウェブ業界ができてまだ20年も経っていないといわれま
naoyaのはてなダイアリー - tmpfs は本当に容量が動的なのか
Linux には tmpfs という便利なファイルシステムがあります。 $ mount -t tmpfs -o size=64m tmpfs /dev/shm $ mount -t tmpfs -o size=64m /dev/shm /var/tmpとすると、/var/tmp がディスク上ではなくメモリ上に作られたファイルシステムとして mount されます。なので、/var/tmp は I/O 時にディスクI/Oが一切発生しない高速なディスクとして使えると。いわゆる RAM ディスク。(もちろんサーバーの電源を落とすと保存したファイルは消えます。) この tmpfs はなかなかに便利で、キャッシュとかそういうものでディスクにおいてたものここ置くと、ディスク I/O がカットできて超高速になります。はてなでは MySQL のスレーブの MyISAM のファイルを tmpfs において、オ
日本語で読める IT名文書 三選 - naoyaのはてなダイアリー
pplog の方に書いたけど、別にブログに書けばいいかと思い直したので投稿。Slack でチャットしてて、なんとなくこれ面白いよ URL を共有する機会があったので適当に選んだもの。 伽藍、バザール、ノウアスフィア、おなべ(3) http://www.artonx.org/diary/20120411.html#p01 artonさんがノウアスフィアの開墾についてわかりやすく書いてるもの。原文はちょっと長くて読むのが大変だけど、こっちは分かりやすいし、面白い。OSS の構造がなんかわかったきになる、すごい。 Steve Yegge の Google とプラットフォームに関するぶっちゃけ話を訳した http://anond.hatelabo.jp/20111018190933 (前編) http://anond.hatelabo.jp/20111018192953 (中編) http://a
Rebuild: 61: Test With Real Data (Naoya Ito)
Naoya Itoさんをゲストに迎えて、Kindle, 計算理論、開発環境、iOS 8, RubyMotion などについて話しました。 Show Notes きゃんちのギークガールになりたくて（KAIZEN platform編） Kindle Voyage アンダースタンディングコンピュテーション Understanding Computation Welcome to the SICP Web Site Ruby嫌いがアンダースタンディングコンピュテーションを読んで はてなキーワードを高速に付与 Aho Corasick 法 - naoyaのはてなダイアリー Apple, Amazon Offer Family Sharing For Digital Media 開発環境のデータをできるだけ本番に近づける | クックパッド開発者ブログ winebarrel/ridgepole Runn
インフラの継続的デリバリー - naoyaのはてなダイアリー
事前に断っておくがここでいう「インフラ」はレイヤ的には OS より上の話。 少し前に GitHub 時代のデプロイ戦略 - naoyaのはてなダイアリー で、GitHub を介したデプロイを実践しているということを紹介した。普段の開発を Pull Request ベースでやっているので、デプロイもまた Pull Request を契機に実行させると色々捗る、という話。 このプラクティスの対象領域をインフラにまで拡大してみました、というのが今回の話。 DNS レコードを Pull Request を merge した契機に自動で更新 AWS を利用している場合、ドメインの管理も Amazon Route 53 を使うといろいろと都合がいい。 Route 53 での DNS レコードの更新はこれまでブラウザから操作していた。これだと誰がいつ作業したかわからないし履歴もトラックしづらい。また変更
require.js 環境で mocha + expect + testem を使った JavaScript テスト - naoyaのはてなダイアリー
先日書いた自分用アプリケーションのひな形 http://d.hatena.ne.jp/naoya/20130503/1367581629 http://d.hatena.ne.jp/naoya/20130504/1367640512 これに、JavaScript のテスト環境も追加したい。 結論からいくと、フレームワークには mocha + expect、ランナーは testem を使うことにした。ついでにテストダブルライブラリとして Sinon.js も有効にした。 ちなみに今回の文脈は End to End のテストではなくてユニットテスト周りのおはなしです。 mocha + expect JavaScript のこの辺のテスト周りは今もいろいろなツールの整備が進んでいて、今回採用した以外にも Jasmin や QUnit そのほか色んな物がある。昨今の状況に関しては 先日の HTML
伊藤直也氏が語る、モバイルアプリケーション開発のいまとこれから（後編）～Salesforce Developer Conference Tokyo 2013
伊藤直也氏が語る、モバイルアプリケーション開発のいまとこれから（後編）～Salesforce Developer Conference Tokyo 2013 9月6日開催されたSalesforce Developer Conference Tokyo 2013のセッション「B2Cからみたモバイルアプリケーション開発のいまとこれから」では、コンシューマ向けサービス開発の現場に身を置いてきた伊藤直也氏が、モバイルアプリケーション開発を成功させるための方法をこれまでの経験や現在の開発現場のノウハウを基に語っています。 試行錯誤の回数を増やす、iOSとAndroidは同じように作ってはいけないなど、モバイルアプリケーション開発に関わるエンジニアやデザイナーにとって非常に参考になる内容が込められたセッションの内容を、ダイジェストで紹介しましょう。 （本記事は「伊藤直也氏が語る、モバイルアプリケーショ
伊藤直也氏が語る、モバイルアプリケーション開発のいまとこれから（前編）～Salesforce Developer Conference Tokyo 2013
伊藤直也氏が語る、モバイルアプリケーション開発のいまとこれから（前編）～Salesforce Developer Conference Tokyo 2013 いま多くの開発者が取り組もうとしているモバイルアプリケーションの開発は、経験の面でも技術の面でも、コンシューマ向けの開発現場が大きく先行しています。 9月6日開催されたSalesforce Developer Conference Tokyo 2013のセッション「B2Cからみたモバイルアプリケーション開発のいまとこれから」では、コンシューマ向けサービス開発の現場に身を置いてきた伊藤直也氏が、モバイルアプリケーション開発を成功させるための方法を、これまでの経験や現在の開発現場で得たノウハウなどを基に語っています。 試行錯誤の回数を増やす、iOSとAndroidは同じように作ってはいけないなど、モバイルアプリケーション開発に関わるエンジ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SSSSLIDE
SSSSLIDE