東京工業大学エンジニアリングデザインコースでは、春の「デザイン思考基礎」という講義で「羽田空港にいる外国人にインタビューする」というなかなかハードルの高い（デザイン思考を学ばせたいのか、英語を学ばせたいのか、いまいちよくわからない……）経験をしてもらっています。 なぜそんなことをしているのかというと、デザイン思考の最初のステップが「共感（empathy）」だからです。建物（講義室）の外に出て、ユーザーに直接インタビューしたり、現場の様子を参与観察したりすることで、とにかくユーザーの世界に飛び込んでみよう!! というわけです（そのことをimmersionと呼びます）。 年間を通じて、この「共感」プロセスを継続的に行なっていくため、このような大変な思いを最初に経験しておくと、あとから楽になるようです。 実際の受講生の言葉を紹介しておきます。 外国人にインタビューすることに比べたら、日本人にイン

Photo by Cafer Mert Ceyhan on UnsplashI’m one of those guys who like writing Python code in a robust IDE like Pycharm and once the job is done copy/paste the code to Jupyter Notebook to continue with my data science project. IDEs like Pycharm aren’t meant for data science, so that extra step was a must … until I discovered DataSpell. DataSpell has some of the typical features you’d expect from a n

図1: QUICの無効化は待ってくださいQUICを無効化？！“Googleが遅く感じるので、QUICを無効化する” そのようなTIPSが散見されます。数年前から見ていましたが、QUICがトレンドになったのと同時に、再び目立ち始めたと感じています。IPv6が普及し始めた時期もそうでしたが、新しいプロトコルの出現時には、決まって現れる文言です。 問題に直面する利用者にとっては切実であり、無効化は間違った解決手段とは言いません。しかしエンジニアならば無効化する前に、原因を探求しなければなりません。 HTTP3/QUIC と HTTP2/TCP どちらが優先？QUICの無効化とは、TCPだけを利用する選択と言えます。はじめにQUIC, TCPの両者が使えるとき、どのように使い分けるのか見ていきます。 ある、HTTPSスキームのURL https://www.example.com/ があったとき、

Kubernetes / GKE ファンの皆様こんにちわ。Google Cloud の Kazuu (かずー) です。GKE Autopilot が GA になりました。弊社公式ブログに続きまして、GKE Autopilot を日本語で解説していきたいと思います。 本記事は以下、3 部構成となります。 GKE Autopilot 概要GKE Autopilot を試してみるGKE Autopilot がハマりそうなユースケースは？ 1. GKE Autopilot 概要GKE Autopilot は GKE の新しいモードです。Control Plane に加えて、Node が完全マネージドになります。これまでの GKE では Node はユーザー自身が必要台数分作成し、以後の Day 2 オペレーション (e.g. アップグレード) 等も気に掛ける必要がありました。GKE Autopil

はじめにこんにちは、@pacocat です！この記事は「eureka Advent Calendar 2020」15日目の記事です。 気づけばエウレカに入社して1年が経ちました。入社後はデータアナリストとして活動していましたが、今年の3月からはData Directorとして、AIを含むデータ部門を統括する立場として、組織づくりや戦略推進を行っています。 もともとエウレカに入社したきっかけは、過去にデータアナリスト→AIプロジェクトリーダーとキャリアを積んでいく中で、プレイヤーとしてだけでなく、チームや組織としてデータ活用のあるべき姿を考えたいという気持が高まったことにあります。今は毎日優秀なメンバーに支えられながら、成長痛を感じつつ新しいチャレンジを楽しめています。 この記事では、普段私がどのような観点でデータ組織を運営しているか、をまとめていこうと思います。データチームはこの1年だけで

はじめに以前 Yuki Furuyama さんが「NEG とはなにか」という哲学的な(?)記事を書かれていましたが、このたび「Serverless NEG」(Serverless Network Endpoint Group)という新しいタイプの NEG が追加されました。(まずは Beta でのご提供です → EDIT(2020–10–14): 2020年10月14日に GA になりました。) これで NEG は Zonal NEG、Internet NEG、Serverless NEG の三種類になりました。 Furuyama さんの Zonal NEG に関する記事には「NEG は Kubernetes の Service に相当するもの、Network Endpoint は Pod に相当するものです」とありましたが、Serverless NEG では「Network Endpoi

追記GitHub Sponsors で組織がスポンサーになれるようになったため、個人アカウントから組織アカウントへ切り替えました。 月 500 ドルなぜスポンサーになったのか時雨堂では自社製品のすべてのウェブドキュメントに Sphinx を利用しています。そのため Sphinx を継続的な開発を少しでもやりやすくしてもらえるようにスポンサーになりました。 個人としても Sphinx は利用させてもらっており、今まで小宮氏への個人的なスポンサーにはなっていました。 ただ今後も Sphinx を自社製品のドキュメントとして使い続けたいという思いから、企業としてメインの開発者である小宮氏への継続的なスポンサーになるべきだと判断しました。 時雨堂がスポンサーになっている開発者Cowboy や Gun の開発者である Loïc Hoguin 氏Blend2D や AsmJit の開発者である Pet

DroidKaigi 代表理事 mhidaka です。 この活動報告は新型コロナウイルス感染症の影響によって2020年2月のDroidKaigi 2020が中止した影響をまとめています。 DroidKaigi 2020の中止を受けて2020年7月の今もなお新型コロナウイルス感染症は社会へ大きな影響を与えています。技術カンファレンスも変化せざるをえません。本記事は今一度、開発者・企業・IT業界の関係各位がカンファレンスの有り様について考えるきっかけとなればという気持ちで公開します。我々の至らないところも目立ちますが、広く共有することで業界に役立ってほしいと考えています。 この中止でご迷惑をおかけした講演者、一般参加者、アプリ開発にコントリビュートした開発者、協賛企業、取引企業、カンファレンスに関わった皆さんにとって残念な結果となったことを改めて、お詫び申し上げます。 DroidKaigi実行

「なんかアプリでインシデント起きてエンジニアがどこかで対応してるらしいよ」 「インシデント時のお知らせって誰がどうやって出すんだっけ？」 「インシデントの復旧作業って今どれくらい終わってる？」 「あのインシデントって振り返りしたっけ？」 「似たようなインシデント、前も対応したような、していないような」 このような会話に覚えはありませんか？ FiNC Technologies社 (以下FiNC) では今まで インシデント対応をしていても自チーム内で対処しようとしてしまい、他の人が気づけないインシデント対応の仕方にフォーマットがなく、迅速な対応やお客様への報告ができないインシデントの振り返りが実施されず、インシデント時の知見が共有されないという問題がありました。 それらの問題を 気が付きやすく、シェアしやすくする = 統一のチャンネルで情報を整理し、そこにシェアしやすい空気を作る何をすべきかわ

こんにちは。JDSCの栗林です。 BigQueryを使用されている方であれば、JavaScriptでユーザ定義関数(UDF)を作成できることはご存知かもしれません[1]。JavaScriptはSQLに比べてかなり自由度は高いのですが、実行速度の面ではどうしても不利になってしまいます。 そこでJavaScriptの高速化といえばWebAssembly！[2]ということで、BiqQueryのUDFでWebAssemblyを試してみたところ、一定の効果が見られたのでご紹介します。 まずは結果からみてみましょう。100個のデータそれぞれに対して、ループ回数を数える単純な処理を実行したときの実行時間を計測しました。BigQueryの実行時間はバラツキが大きいため、５回測定した中央値を採っています。 JavaScriptではループ回数が10の6乗を超えると極端に実行時間が増加しますが、WebAssem

なぜ Day One は Markdown を捨てたのか Day One が Markdown をやめて WYSIWYG に移行した話は前書いた。 自分が知っている範囲でアンチ Markdown 勢は Scrapbox… はてなブックマークのコメントなどを読んでも、ウェブでの記事制作においてワードプロセッサ（WordやGoogle docs）ライクなWYSIWYG（ウィジウィグ）なツールと、Markdown（あるいはそれに類する構造化簡易記法）のどちらがよいか？ という視点で議論されている（そして主に議論に参加しているのがエンジニアなので記法優位？）という状況に見えて、というより記事そのものがMarkdownの時代が終わってWYSIWYGに移行しているという論点なのだけど、実際に例示されているツールをよく見たところ、そうシンプルではないように思える。 むしろ、その両者を統合した、あるいはM

Flutter×GCP/Firebaseで何かを作っていく(る)方に参考になればと思います。 上記の技術構成でリリースした Othellode というアプリは、 iOS/Android で公開済みなので、興味あればダウンロードしてみて下さい。 “しっかり”とは？下記のような観点を考慮することを指しています。 運用を前提とする設計やフロー整備多言語対応負荷分散セキュリティモニタリング費用バックアップロギングdevelopment/staging/production 管理これらに関する知見から、13個厳選して広く浅く書きました。 (ポイントというより感想みたいな項目もありますが..) なお、情報漏洩対策(IP制限やBasic認証)やアセットパイプライン,BQによる分析等は、今回本腰を入れてない( 必要がなかった)ため触れませんし、詳しくありません。 目次Useful Information