タグ

ブックマーク / techblog.yahoo.co.jp (19)

  • ES6時代のNode.js

    ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは。情報システム部の伊藤(@koh110)です。 社内システムの開発、運用を担当しています。 今回、担当しているシステムをNode.js LTS(v4.x)へバージョンアップしました。 それに伴い実施したES6対応の中から3つの事例を紹介したいと思います。 varを撲滅しよう arrow functionを使おう callbackを撲滅しよう varを撲滅しよう varをlet, constに置き換えます。基はconstに置き換えます。 メリットは以下の点で、コードの品質向上につながると思います。 プログラム中で変更不可である事を明示的に示せる。 誤った使い方をした時にバグとして検出される。 varを利用するとブロック

    ES6時代のNode.js
  • 世界最強のソフトウェアアーキテクト

    ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは! マーケティングソリューションカンパニー(MSC)開発部の小川雄大です。 昨年11月に子会社のクロコスからヤフーに移りまして、現在はヤフーで開発を行っています。みなさまどうぞよろしくお願いします。 MSC開発部では、ヤフーが世界最強を目指してどう取り組んでいくかについて議論する会を毎週開催しています。今回はそこで今年の1月に僕が発表した「世界最強のソフトウェアアーキテクト」について公開したいと思います。 今回はヤフーに入ってはじめての発表ということもありテーマをどうしていくかはかなり悩んだ部分なのですが、テクニックよりもアーキテクトが持つべきマインドを共有することが次につなげていく上で大切になると考えたので、多少抽

    世界最強のソフトウェアアーキテクト
  • 細かすぎて伝わらないSSL/TLS

    ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog 「細かいと言うより長いよね」 はじめに こんにちは。ATS の脆弱性を発見した小柴さんや ATS に HTTP/2 の実装を行っている大久保さんと同じチームの一年目、匿名社員M さんからいじられている新人です。今回ありがたい事に、こういったすごい方々を含めモヒカン諸先輩方より「何か書かないの?」「いつ書くの?」という数々のプレッシャーお言葉をいただきました。 というわけで、SSL/TLS の Session 再開機能に関して書いていこうかと思います。 SSL/TLS は機密性、完全性そして真正性に対して安全な通信を行うための仕組みです。しかし、この仕組みは暗号技術を多用し特に接続において複雑なプロトコルを用い、Client, Se

    細かすぎて伝わらないSSL/TLS
    blythegirls
    blythegirls 2015/01/26
    細かすぎて伝わらないSSL/TLS
  • レガシーコード改善勉強会 開催レポート

    ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog ヤフー株式会社の有地です。 9/27(土)の昼から6時間にもわたり、さまざまな視点から「レガシーコード」について知識を深めるための勉強会を開催いたしました。 「そもそも正しい仕様を知っている人がいない」 「システムのブラックボックス化が留まるところを知らない」 こんな不条理なレガシーコード(テストコードが無いコード)と日々戦うエンジニアも多いことと思います。 今あるレガシーコードをどうやって保守・改善していけばよいのかという課題に気で取り組んでいる、または取り組みたいと考えている大勢の方々に参加していただきました。 <開催趣旨・目的> テストコードが無いプロダクションコードをレガシーコードと定義し、テストコードによって保護され、

    レガシーコード改善勉強会 開催レポート
  • PHPカンファレンス2014にYahoo! JAPANが参加します #phpcon2014

    こんにちは、Yahoo!デベロッパーネットワークの中野です。 今週の土曜日、2014年10月11日に、年に一度のPHPの祭典「PHPカンファレンス2014」が開催されますが、今年はYahoo! JAPANもプラチナスポンサーとして参加します。 Yahoo! JAPANノベルティグッズを配布するほか、社員によるセッションもありますので、ぜひ会場へお越しください。 昨年の様子はレポートとしてまとめていますので、合わせてご確認いただければと思います。 PHPカンファレンス2013参加レポート - Yahoo! JAPAN Tech Blog PHPカンファレンス2014概要 テーマ

    PHPカンファレンス2014にYahoo! JAPANが参加します #phpcon2014
  • HTTP/2 入門

    ストリームによる多重化 2つ目の特徴は「ストリーム」です。従来のHTTPでは、リクエストとレスポンスの組を1つずつしか同時に送受信できないことが、パフォーマンス上のボトルネックになっています。この問題を改善するべくHTTP/1.1では新たにパイプラインが導入されましたが、一部のレスポンスに時間がかかるような場面でレスポンスが詰まってしまう問題などがあり、広く使われてはいません。そこで、HTTP/2では1つの接続上にストリームと呼ばれる仮想的な双方向シーケンスを作ることでこの問題に取り組んでいます。 1つの接続上に作られた複数のストリーム上では、複数のフレームを同時並行で転送できます。例えば、あるストリーム上ではリクエストにあたるフレームが送信中でも、別のストリームではレスポンスにあたるフレームを受信するといったことが可能になります。これにより、全体的なパフォーマンスが向上します。 ヘッダー

    HTTP/2 入門
  • 爆速でわかるjQuery.Deferred超入門

    ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog Yahoo!デベロッパーネットワークの中野(@Hiraku)です。これまで、JavaScriptで非同期処理を書く上での問題として、コールバック地獄やエラー処理に例外が使えないことなどを解説してきました。 これらの問題に対処するライブラリの1つであるjQuery.Deferredに関して、もう少し丁寧に解説いたします。なお、jQueryのバージョンは記事執筆時点の最新である、1.9.1を想定しています。 jQuery.Deferredとは jQuery.DeferredとはjQueryのバージョン1.5から導入された、非同期処理をうまく扱うための標準モジュールです。使いこなすことで、以下のような効果が見込めます。 非同期処理を連結

    爆速でわかるjQuery.Deferred超入門
  • JavaScriptとコールバック地獄 - Yahoo! JAPAN Tech Blog

    ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog Yahoo!デベロッパーネットワークの中野(@Hiraku)です。JavaScriptでサンプルコードを書く機会があったので、どんなインターフェースで提供するのが便利なのか考えてみました。よく問題になるコールバックのネスト問題について、一般的な話をまとめてみます。 お題 突然ですが、次のような処理を行う必要があるとします。 「0」を出力する 1秒待つ 「1」を出力する 1秒待つ 「2」を出力する これをプログラムで書くとどうなるでしょうか? シェルスクリプトの場合(同期) たとえばシェルスクリプトで素直に書くと、次のようになります。

    JavaScriptとコールバック地獄 - Yahoo! JAPAN Tech Blog
  • レプリケーションを使わないMySQLの冗長化

    ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、DBMSチームの三谷です。 ヤフーでは多くのサービスでMySQLを利用しています。MySQLはヤフーを支える重要な技術の1つです。 私のチームではヤフーのさまざまなサービスのデータベースを集約して管理・運用しています。 集約することでコストの削減やノウハウの蓄積といった効果を生み出しています。 今回はこの集約環境の冗長化方法についてご紹介します。 集約環境の構成 集約環境ではマスターの冗長化にレプリケーションを利用せず、エンタープライズ向けの共有ストレージを利用したアクティブ・パッシブ型のHA構成を採用しています。 データファイルを共有ストレージに置き、どのマスターサーバーからでも同じデータに対してアクセスできるように

    レプリケーションを使わないMySQLの冗長化
  • サーバーの熱は冷まさなくても良い?

    ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、運用技術部 サイトオペレーションズ部の秋山と申します。 Yahoo! JAPANには日一のサイトを支えるたくさんのネットワーク機器、サーバー、ストレージがあります。 日々増え続ける、インフラ機器の運用管理に頭を悩ませている、管理者も多いかと思います。 悩むポイントは機器管理、コスト等いくつかあるかと思いますが、今回は「サーバーの熱」に焦点を絞り、話をします。 普段使っているパソコンなどもそうですが、情報技術IT)機器全般に電源投入後は熱を持ち、 内部のファンで、たまった熱をケース外に吐き出す構造のものがほとんどです。 パソコン1台ですと、暖かい風が出てくるだけ。というイメージが多いかと思いますが、 データセンタの

    サーバーの熱は冷まさなくても良い?
  • Silverlightのパフォーマンスを向上させるための10のヒント

    ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog はじめに こんにちは、制作部の藤川です。 みなさん、Silverlightで何か作ってみようとしたことはありませんか。 Silverlight開発の経験のあるかたなら一度は悩んだことがあるのがパフォーマンスの問題ではないでしょうか。 Silverlightは新しい技術であり、パフォーマンスについては、前例や参考文献も少ないのが現状です。 そこで今回は、Silverlight開発で得た経験や知識から、パフォーマンスを向上するためにはどうすればいいか、ヒントをご提供できればと思います。 また、このページの最後に参考リンクを貼っていますのでこちらもあわせてご参照ください。 パフォーマンスを向上させることによってどんなメリットがあるでし

    Silverlightのパフォーマンスを向上させるための10のヒント
  • 認証が必要なWeb APIをSilverlightで使う方法

    ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog はじめに こんにちは。制作部の藤川です。 主にSilverlightでの制作案件を担当しております。 今回は私のほうからSilverlightとYahoo! JAPAN IDとの連携について、 サービスの開発事例をもとにご紹介したいと思います。 どうやって連携するか 今回ご紹介する内容は、Yahoo! JAPAN IDにひもづいたXMLデータをどうやって取得したか、ということです。 一般的なSilverlightアプリの場合、WebClientクラスを使用しWEBサーバーにあるXMLを直接読み込めばいいのですが、Yahoo! JAPAN IDにひもづいたXMLデータの場合は、そう単純には行きません。 というのも、Yahoo! J

    認証が必要なWeb APIをSilverlightで使う方法
  • エラーページ - ヤフー株式会社

    指定されたURLは存在しません。 URLが正しく入力されていないか、このページが削除された可能性があります。

    エラーページ - ヤフー株式会社
  • ヤフーのセキュリティに対する取り組みについて 第2回目

    ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、R&D統括部 開発推進室 セキュリティプラットフォーム技術の戸田 薫です。 セキュリティプラットフォーム技術の取り組みについてご紹介します。 「ヤフーのセキュリティに対する取り組みについて 第1回目」で「アプリケーションを開発するときには、既知の脆弱性を意識して行わなければなりません。」と述べたことについて、ヤフーがどのように取り組んでいるかについてご紹介いたします。 ◆セキュアなシステムを構築するために 安全に利用できるシステムを構築するためには、知識や技術がなければなりません。 そのためにヤフーでは 1:教育 2:アプリケーションのセキュリティ対策 3:ソースコードレビュー 4:脆弱性テスト 5:セキュリティチェ

    ヤフーのセキュリティに対する取り組みについて 第2回目
  • マークアップ効率化 - zen-codingでコーディングを倍速に

    HTMLの記法について 基的には「div」の様に要素を省略せずに記述して、それを展開すると「<div></div>」という形に展開されます。 このときに展開できる要素は以下の公式ドキュメントに明記されていますのでそちらを見るとよいです。 Zen HTML Elements Zen HTML Selectors Zen CheatSheets 基的な記法 ひとつずつ順番に記述して説明していきます。しばらく初歩的な説明になるのである程度知っている方は飛ばしていただいて良いかと思います。 まずものすごく基的な記法である、単独タグの記法について説明を行います。 cssのセレクタをイメージしながら見ていくと納得しやすいと思います。 タグだけ変換 変換前 div 変換後 <div></div> デモ 文末でtabを押してください div 変換後、div要素の間にカーソルが移動するので、すぐにテキ

    マークアップ効率化 - zen-codingでコーディングを倍速に
    blythegirls
    blythegirls 2010/03/16
    Intellisence との相性悪そう
  • OAuthの仕様について 〜署名?それっておいしいの?〜

    ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、IDプラットフォーム技術の近藤裕介です。 OAuthを使ったアプリを実装している方の多くは特にパラメータの署名まわりの部分で少し詰まることが多いように見受けられます。署名はOAuthのキモとなる仕組みなので今回はこれに関する記事を書いてみようと思います。 署名の仕組み OAuth(以後OAuth Core)の仕様では、一般的な署名の仕組みを使ってリクエストの内容の改ざんや送信者のなりすましをされにくくしています。いまのところ以下の3つの署名方式に対応しています。 HMAC-SHA1 Service Provider(以後SP)側でConsumerkeyとSecret(秘密鍵)のペアをConsumerに発行し、APIリク

    OAuthの仕様について 〜署名?それっておいしいの?〜
  • Inside Yahoo!メール 第2話「分析!迷惑メール」 (Yahoo! JAPAN Tech Blog)

    ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、ソーシャルネット開発部の島貫 和也です。 連載では、今まであまり触れられてこなかったYahoo!メールの迷惑メール対策と、電子メールに関連する情報をご紹介しています。今回は前回に引き続き、Yahoo!メールで実施している Botnet の分析と対策について、その取り組みの一部をご紹介させていただきます。 ご注意 出典元の説明のため、いくつか外部リンクがあります。リンク先については保証しておりませんのでご了承ください。 この記事の性質上、迷惑メールの性質や送信手法について触れている箇所がありますが、電子メールやコンピュータの不正利用を助長する意図のものではありません。読み物としてお楽しみください。 はじめに 前回の記事

    Inside Yahoo!メール 第2話「分析!迷惑メール」 (Yahoo! JAPAN Tech Blog)
  • Inside Yahoo!メール 第1話「迷惑メールとBotnet」

    ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、ソーシャルネット開発部の島貫和也です。Yahoo!メールの配送システムおよび迷惑メール対策を担当しています。 Yahoo!メールはプロバイダ(Yahoo! BB)のメールサービスでもありますが、フリーメールとしての側面もあるため、非常にさまざまな方に多様な形態で利用されています。このようなサービスでは、迷惑メールなどの不正利用を前提とした対策が必要不可欠といえます。 連載では、今まであまり触れられてこなかったYahoo!メールの迷惑メール対策と、電子メールに関連する情報を数回に分けてご紹介したいと思います。 ご注意 出典元の説明のため、いくつか外部リンクがあります。リンク先については保証しておりませんのでご了承くださ

    Inside Yahoo!メール 第1話「迷惑メールとBotnet」
  • APIとの通信効率をよくする実装例(2) 簡易キャッシュ

    こうして見ると、仮に5分程度ライムラグがあってもさほど影響が無いものが多い、つまり毎度APIに問い合わせるのが無駄とも言えないでしょうか。(毎度通信すべきはなのは、上の表では「高」の部分のみ)。 そこで、APIから取ってきたデータ(XML)を少しの時間だけとっておくのはどうでしょう?(リアルタイム性が高いものや検索結果については毎度通信し、それ以外のものはキープしておき再利用)アクセスしてきたAさん、Bさん、Cさん・・・誰が見ても同じ内容ならなおさらみんなでシェアできれば、通信の数もそれにかかる時間も減るはずです。 このように一定時間データを溜めて再利用するシステムや行為を、キャッシュ(cache ※1)といいます。 どんな言語でも、こんな流れのロジックが書ければ実現できるでしょう。 if ( とっておいたXMLが賞味期限切れ ) { 捨てる; } if ( とっておいたXMLがある )

    APIとの通信効率をよくする実装例(2) 簡易キャッシュ
  • 1