After ~12.5 years at Google and ~10 years working on Go (#golang), it's time for me to do something new. Tomorrow is my last day at Google. Working at Google and on Go has been a highlight of my career. Go really made programming fun for me again, and I've had fun helping make it. I want to thank Rob Pike for letting me work on Go full time (instead of just as a distraction on painfully long gBus
53サービス・アプリのクラウドやフレームワーク・言語など聞いてみた! アーキテクチャ大調査2020 エンジニアHub恒例のアーキテクチャ大調査。2020年版では、フロントエンドとサーバサイドの開発環境や、クラウドサービスの利用を分けてアンケートを実施。53のアプリ・サービスから回答がありました。 ソフトウェア開発には日進月歩で新しいテクノロジーが続々と登場し、開発からデプロイ・運用までさまざまな環境でトレンドが次々と移り変わっていきます。そこには、技術選択した開発者の設計思想も見えてきます。 エンジニアHubでは、2017年と2019年にさまざまなIT企業にアンケートを実施し、各社のサービスやアプリを開発しているプログラミング言語やアーキテクチャ、またインフラを構成するミドルウェアやデータベースをまとめて掲載しました。 今回の2020年版ではテクノロジーの進化にあわせ、開発環境についてWe
SF ベイエリアで働く1人のソフトウェアエンジニアとして、楽しくエンジニアリングをやっていくために日頃からぼんやりと心がけている3つのポイントについて今回は書いてみたい。 インフラを作る側にいるソフトウェアエンジニアとして普通の Software Engineer から Senior Software Engineer、Staff Software Engineer とだんだん昇進していくにしたがって、より大きな成果を出すことを期待される。Staff レベルにはチームをまたいだ成果を出すことが求められる。そのためには多くの場所で使われるようなサービスやライブラリを作るのが一番成果としてわかりやすい。 会社とプロダクトが初期段階から成長していく過程で、最初は1つしかなかったエンジニアリングチームが大きくなるにしたがってインフラ側とプロダクト側に分割されていく。そのときにかならずインフラ側に属
1.コーディングインタビューとは何か コーディングインタビュー(Coding Interview、またはProgramming Interview)とは、1時間ほどの制限時間内に小さなプログラミング問題を解かせる面接形式のことをいう。プログラマー、またはデータサイエンティストなどの採用試験として、米国を含むいくつかの国で用いられている。「物理的なホワイトボード上にプログラムを書く」という形式で実施されることが多い。「オンライン上の共有エディタで書く」といった形式のこともある。Googleなどは自社のYoutubeチャンネル動画でも説明している。 出題される問題としては、例えば、「複数の数字numbersと整数kが与えられたとき、合計がkとなる数字の組を1つ出力せよ」といったものがある。この問題は有名なので通称が付いており、Two Sumと呼ばれる。 Two Sumの一例。与えられた数値の並
1 on 1 (ワンオンワン) とは1対1のミーティングの事。ここでは毎週もしくは隔週で行われるマネージャとその部下(direct reports)であるソフトウェアエンジニアの 1 on 1 に焦点をあてる。よく 1 on 1 で何を話したらよいか分からない。話題がない。と相談されるので僕の思うところをまとめてみる。 僕はマネージャもソフトウェアエンジニアのどちらも経験があるので両側からの視点を提供できると思う。 マネージャ編 マネージャは 1 on 1 を部下のために開催しなければならない。自分のための時間ではないことを肝に銘じよう。部下には話したいことを何でも話してもらう。事前に「1 on 1 は君のための時間だよ」と説明しておこう。 1 on 1 が始まったら「何か話したいこと、気になることある?」と問いかけよう。焦ってはいけない。じっくりと待ってみよう。 たとえマネージャとしてプ
The Qiita Advent Calendar 2019 is supported by the following companies, organizations, and services.
LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog Developer Relationsチームの三木です。 11月20日から21日にかけて、LINEのエンジニア向け技術カンファレンス「LINE DEVELOPER DAY 2019」を開催しました。社内外のエンジニアの皆様3,000名以上にご来場いただく大盛況なイベントとなりました。ご来場いただいた皆様、登壇いただいたゲストの皆様、運営に携わっていただいた皆様、誠にありがとうございました! 今年のLINE DEVELOPER DAYは、より深く幅広い分野に関連した内容を提供するために、二日間の構成としました。全部で68個のメイントーク、42個のショートトラック、9個のポスターセッション、6個のハンズオンセッション、19個のブー
概要 インターネットに晒されているWebサービスでは TV等で紹介されたことによる大量流入 悪意ある人物からの攻撃 クライアントのバグに依る大量リクエスト など、本来想定していた以上のトラフィックが来ることはよくあります。 単純にシステムを構築すると大規模トラフィックに対応できずシステムがスローダウンしてしまうため、何かしらrate limitをかけておいた方が良いです。 ただしrate limitと一口に入っても色々あるため、今回は主なrate limitアルゴリズムを紹介します。 Leaky bucket Leaky bucketはデータ転送レートを一定にする(=上限を設定する)アルゴリズムです。 下の図のように、様々な流量の水流がそのバケツに流れ込んでも小さな穴からは一定の水流が流れ出す仕組みです。 ref: What is the difference between token
2. アジェンダ 講演前半 (概要, ビジネスミーティング内容, トレンド, Keynote) 概要 ビジネスミーティングの内容 トレンド(私見) Keynoteザッピング 講演後半 (受賞関係, 研究紹介) Codd Award 受賞講演 (Prof. Ailamaki) Best Paper Interventional Fairness: Causal Database Repair for Algorithmic Fairness Runner-up Incremental and Approximate Inference for Faster Occlusion-based Deep CNN Explanations Fast General Distributed Transactions with Opacity 面白かっ
現在のインターネットの基本をなしているIPv4というプロトコルには、広く知られた大きな欠点がある。パケットのアドレスフィールドの幅が32ビットなので、ネットワークに接続可能なホスト数の上限が2³²(約43億)になってしまっているのだ。その欠点を修正するために、1990年代後半にIPv6という新たなプロトコルが設計されたのだけど、いまだにインターネットではIPv6は少数派で、主流ではいまだにIPv4が使われている。 1990年代当時は、IPv6は規格を策定すれば比較的すぐに普及するはずで、それによってインターネットが抱えているアドレス枯渇の問題が解決されるという雰囲気だったように思う。1998年にタイムトラベルして、20年たってもまだIPv4を置き換えることに成功していないと当時の人のIPv6推進者たちに教えたら、多分すごくびっくりされるだろう。一体どうしてこんなに普及が遅れてしまったのだろ
2019/10/31 を持って8年間勤めてきたドワンゴを退職しました。 ドワンゴ退職エントリの旬は過ぎているよう気もしますし、こんな何年も放置していたブログで今更何をと思わなくもないですが、なんとなく自分の気持ちの整理もかねて適当に綴ってみようと思います。 何をやってきたか 各種のゲームデバイス、PS Vita, Wii U, 3DS, Nintendo Switch 上でのニコニコプレイヤーの実装をずっとやってきていました。 それぞれのデバイスでのシステム部分というか、ゲームデバイス上での非ゲームアプリケーションフレームワーク、そんなものを作り続けてきた感じです。 これらのニコニコ動画クライアントは、私の手を完全に離れてしまうことになります。 もっとできることはたくさんあるし、改善すべき点もたくさんある。愛用してくれているユーザーに対して自分が出来るはずのすべてを提供することができなかっ
ロックインとはなにか?すべてが悪いのか?「開発におけるロックインのリスク評価と考え方」 #AWSDevDay とかく悪の象徴として語られがちな「ロックイン」ですが、それが本当に悪いものなのか?そもそもロックインとはなにか?それのリスクをどう考えればよいのか?真正面から解説された素晴らしいセッションでした。 「いや、そこまでAWSどっぷり使ってもうたら、他に移行するの大変やん?」 あなたがユーザー側クラウド導入推進担当として、あるいはクラウドベンダーの担当として上司やお客様から冒頭の質問を投げかけられた時、どのように答えますか? 自分もクラウドベンダーの一員としてお客様と対峙する時、基本的には「AWSにあるものは基本的に全て使いましょう。それが結局は一番オトクです」と答えているんですが、それがすべて本当なのか?AWSのなかでもマネージドサービス複数あるけど、使えば使うほどええってわけでもない
はじめに こんにちは。コミュニケーションアプリ「LINE」の Android クライアントチームの石川です。 先日、コードの可読性についてのプレゼンテーション (https://speakerdeck.com/munetoshi/code-readability) を公開しました。 今後、このプレゼンテーションについてのちょっとした解説を、本ブログ上で不定期に連載していきます。 今回は、このプレゼンテーションの概要と、最初の章 "導入と原則" についての解説を行います。 このプレゼンテーションについて このプレゼンテーションは、コードの可読性を向上するためのアイディアをまとめたもので、以下の8つの章からなります。 導入と原則: 可読性の高いコードの重要性、プログラミング原則 命名: 名前の示す内容、文法、語の選択 コメント: ドキュメンテーション、インラインコメント 状態: 状態遷移の管理
監訳者まえがき はじめに 第I部データシステムの基礎 1章 信頼性、スケーラビリティ、メンテナンス性に優れたアプリケーション 1.1 データシステムに関する考察 1.2 信頼性 1.2.1 ハードウェアの障害 1.2.2 ソフトウェアのエラー 1.2.3 ヒューマンエラー 1.2.4 信頼性の重要度 1.3 スケーラビリティ 1.3.1 負荷の表現 1.3.2 パフォーマンスの表現 1.3.3 負荷への対処のアプローチ 1.4 メンテナンス性 1.4.1 運用性:運用担当者への配慮 1.4.2 単純さ:複雑さの管理 1.4.3 進化性:変更への配慮 まとめ 2章 データモデルとクエリ言語 2.1 リレーショナルモデルとドキュメントモデル 2.1.1 NoSQLの誕生 2.1.2 オブジェクトとリレーショナルのミスマッチ 2.1.3 多対一と多対多の関係 2.1.4 ドキュメントデータベース
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く