はてなブックマーク

Goの紹介を書くために思い立ってグラフ化してみました。情報源はこちらです。 2014ぐらいまでは、利用言語は自由記述と本文に書いてあったり、無記名のチームもあったようなので参考値です。2013では予選はGoで突破したけど本戦は別の言語で出たチームがあったみたい（2チーム突破で8%だったけど決勝は4%になってた)。 Goの開発効率と実行効率を証明する証拠として、JTBCで上司を説得するような場合に便利にご利用いただけるかと思います。 ソースの生データも貼っておきます。 予選 予選突破 ISUCON3(2013) 4.23 8 ISUCON4(2014) 16.1 24.1 ISUCON5(2015) 14.2 22.2 ISUCON6(2016) 19.2 42.3 ISUCON7(2017) 28.4 53.3 ISUCON8(2018) 40 63.3 ISUCON9(2019) 49.

print()関数 Pythonは何もインポートしなくても使える関数は __builtins__ の中にいます。PyPyリポジトリの/pypy/module/__builtin__/というフォルダがそのコードに該当しそうです。この中のapp_io.pyにそれっぽいものがありました。 Pythonのprint()はfileオプションで出力先を変更できます。何もしていないければ標準出力をとってきています。内部で定義されたwrite()関数はこれのwrite()メソッドを呼んでいます。最後に呼ばれるのはこのwrite()メソッドですね。 def print_(*args, **kwargs): """The new-style print function from py3k.""" fp = kwargs.pop("file", None) if fp is None: fp = sys.st

しかし、パッケージとしては以下のような依存が発生してしまっています。internalは抜きます。 errors go io os path reflect sort strconv sync syscall unicode time type Goはリンク時に不要な関数は削除してバイナリをなるべく小さくしようとするのですが、Goの言語仕様&エスケープ解析の欠点としてはinit()で参照（パッケージグローバル変数の宣言もコンパイル時に生成されるinit()にまとめられるので、グローバル変数宣言も）されたものはすべて、eliminationが働かずにリンクされちゃうんですよね。 %vでどんな型がきてもパースしてやるぜ、という機能があるのでおそらくそこでリフレクションをimportしていて、そのimportの中にinit()があれば、そこで使っている要素がシンボルとして残り・・・みたいな連鎖でし

フューチャーアドベントカレンダー21日目のエントリーです。全25話中、神回が25回あったウルトラマンZが終わってしまいましたね。全日本人のうちの1億2000万人ほどがウルトラマンZロスでうちひしがれているころかと思います。 Goでは、Goをインストールしたときに一緒にインストールされるライブラリを「標準ライブラリ」と呼びます。また、golang.org/xなパッケージ群は準標準ライブラリと呼ばれます。準標準ライブラリには多彩なライブラリが含まれます。今ではもう本家に入ってしまって、後方互換性のためだけに残っているパッケージも一部ありますが・・・ これ以外にも https://github.com/golang/ にはたくさんパッケージがあります。一部はgolang/xのものも入っているのですが、それ以外のものをここでは仮に準々標準ライブラリと呼ぶことにします。 golang.org/xのも

MacBook Pro (M1)でのメモです。インストールできるかどうか状況確認メモです。 自分がよく使うものを中心に。なるべくARMネイティブになるように。もしプライマリーで提供されているインストール手段（.dmg利用など）でARM対応が済んでいればそれを紹介しますが、もしそれで対応していない場合にはMacPortsやソースビルドなどの結果も合わせて紹介します。 PowerPC->x86->x86_64とユニバーサルバイナリを挟んで対応してきたMacPortsはこういう過渡期に強いです。 なお、ここで紹介するバージョンは最新版から古い可能性がありますが、「M1サポートが追加された前後のバージョン」を明記するのを目標にしていますので、これより新しければ問題ないと見てもらえればと思います。 編集リクエストウェルカムです。 現在の状況 IDE/エディタ Eclipseはあまりきちんと試していま

OpenCensusのノリで、エクスポーターを複数追加したら、なぜかJaegerにトレースが出ないぞ、ということで、もしかしてこれはバグなのでは？コミットチャンスでは？と思い調べたりしていました。 うまくいかなかったコードはこちら。サンプルのjaeger出力のコードに対して、タコの絵文字の部分を追加しました。標準出力エクスポーターですね。 https://github.com/open-telemetry/opentelemetry-go/blob/master/example/jaeger/main.go package main ​ import ( // (略) "go.opentelemetry.io/otel/exporters/stdout" // 🐙 ) ​ func initTracer() func() { // (略) // begin: 🐙 _, err = st

なお、distrolessのイメージは2種類（3通りの名前）がありますが、Python 3.5はバグ修正はせず、セキュリティ修正のみでサポート期限が2020/9/13というステータスなので、本エントリーでは3.7の方のみを扱います。 gcr.io/distroless/python3: Python 3.5.3 gcr.io/distroless/python3-debian9: Python 3.5.3(上のイメージと同一) gcr.io/distroless/python3-debian10: Python 3.7.3 一応サンプル等もありますが、どれも1ファイルで構成されたサンプルスクリプトばかりです。前回のsite-packagesにコピーする方法を軽く試したところうまく動かず、シェルもpipもensurepipもないため、ビルドイメージにすることもできません。いろいろ調べた結果、

お前誰よ 渋川よしき フューチャー株式会社で仕事してます いろいろ本を書いたりしています みなさん買ってくださっていますよね？ 今日は、家族がいろいろ体調を崩していて時間が取れなかったのでQiitaスライドで 今回の内容 フューチャー社内で行ったコードリーディングの勉強会の再演です。現在、標準ライブラリをみんなで読んで解説しています。 わたしは1.14で追加されたhash/maphashを説明しました。 1.14の変更 Go 1.14のリリースノート: https://tip.golang.org/doc/go1.14 hash/maphash https://tip.golang.org/pkg/hash/maphash/ ここによると、1.14ではぼちぼち新しいメソッドやRISC-V実験サポート開始や、lock周りやdeferの高速化、テストが後処理ができるようになるなどがあるが、完全

PySpaアドベントカレンダーのエントリーです。昨日はYesterdayでした。今日はTodayです。 ずっと開発や普段使いで使えるChromebookが欲しいと思っていました。勉強会の発表で使ったりするので、きちんと技適が通ったやつで、性能がまとも（以前ATOMベースのマシンにLinux入れたけど遅くて使う気になれなかったので）なやつを待ち望んでいました。 7月ぐらいからHPがChromebookを販売開始してくれました。気づいてから申し込んだものの、予想外に受注があったのか、納期が伸びに伸びて1ヶ月半近くかかりましたが、とても良いものだったので、今ではすっかりメインで使っています。 バージョンによって状況はまた変わってくるかもしれないので、タイトルに日時を入れました。これを書いた時点でのバージョンは78.0.3904.106（Official Build）（64 ビット）でした。 日本

Goアドベントカレンダーその2の3日目のエントリーです。 Goではエラー処理の方法としてはプリミティブな方法しか提供しておらず、他の言語のユーザーからやいのやいの言われてきました。Go2でそれを改善するぞからプロポーザル募集でいろいろ意見を募っては二転三転みたいな感じで、Go 1.13ではだいぶおとなしい感じに機能拡張されました。基本的な方向性としてはgithub.com/pkg/errorsから少し機能を取り込んだ感じです。 すでに、数多くのエントリーやらプレゼンテーションやらでGo 1.13の利用者視点でのerrorsの変更点については触れられてきましたので詳しくはそちらをご覧ください。サマリーとしては下請けのパッケージで出てきた詳細なエラーをラップして扱うための便利な機構がいろいろ追加された感じです。 これらでは主にアプリケーションコードの実装者というかライブラリの利用者向けの説明が

2019年はWebComponents元年(2回目)！WebComponentsをReact/Angular/Vueと一緒に使う WebComponentsは未来の技術みたいな感じでしたが、lit-elementが登場してかなり作りやすくなりました。ただ、実際のウェブアプリケーションで使うにはどんな感じになるのかな、というのを脳内シミュレーション＆実験してみましたので、それの記録です。 この記事自体は5月ごろに書いて放置したのですが、JSConfで発表したのでそれに合わせて公開します。 本記事の想定ストーリー かっこいい部品を作りたいデザイナーさん、もしくは社内的なデザインガイドラインがある。ホストのフレームワークがなんであるかは気にしないで、とりあえずデザインを作り込みたい 管理画面はフォームのバリデーションとかが手厚いAngularを使いたい。でも、ユーザー向け画面は高速にVue.js

ユーザーの認証と認可を行う方法としてはOpenID Connectがメジャーですよね。ローカルで簡単にテストするために、ローカルでKeycloakをDockerで起動してテストしてみます。外部システムはモックを使う、というのがセオリーですが、気軽に使える本物のサービスを使った方が楽ですよね、ということで。 なお、認証周りのGoのアプリケーションコードは超簡易実装なので、本番実装に入れちゃダメですよ。 2020/11/10: コンテナの置き場が変わっていたので更新 2020/11/11: Realmについて補足 Keycloakとは KeycloakはIBM傘下のRedHat傘下のJBossが作成している認証のすごいソフトウェアです。 自分自身でユーザーIDとパスワードを管理するID Provider機能を持つ OpenID Connect、OAuth2、SAML経由でユーザー認証ができる（

AMPは高速化のための技術かどうかを問うブログエントリーがありました。 AMPを「高速化技術」「一瞬で表示する技術」というのはもうやめよう。 WebComponentsを使っているから遅い AMPの速さはGoogleの検索結果からプリフェッチするから速いだけである AMPはGoogleのサーバーにコンテンツを乗せるためのプロトコルである これは僕の理解とは大幅に異なっているので説明します。この説明が正しいとすると、検索結果以外から直接AMPを使ったサイトを閲覧すると「高速ではなくて逆に遅い」ということになります。 さて、これは正しいかどうか。 HTMLの表示を遅くする要素 高速化の前に、HTMLの表示を遅くする要素についてまとめておきます。 再計算 画像のサイズがなくて、読み込んで見てからレイアウトをしなおす スタイルシートを後から読み込んで、要素に適用していく 通常はheadタグ内でdo

最近、社内でよく話をする内容についてまとめました。 企業がOSS化するといろいろメリットがあると思っていて、社内でもそこのコンセンサスはうちの技術横断部門のメンバー間では取れていたりするのですが、自社以外の人とかと話をする時もあるので、いろいろまとめておきます。 なお、この文章では本業をOSSにしつつビジネスを回そうみたいなElasticsearchとかMongoDBとかMySQLみたいな話題はとりあげず、本業が別にある会社がOSS化する、という部分に特化した話です。 9/13に追記 よく言われるメリットとデメリット メリットは、公開することで開発が自然と進み、コスト削減になる。一方でノウハウの流出などのデメリットがある、みたいなトレードオフ、という理解をしている人が多いようです。 コストは削減にならない OSS化したら多くの人に使ってもらいたいですよね？というのは考えるわけですが、その「

FacebookがHermesという組み込みのJSエンジンを公開したようです。 ReactNative用の組み込み用のJSエンジン（最新版だとオプション切り替えで使えるっぽい） MITライセンス プロプラなものとの組み合わせが発生しうる組み込みにおいては正義しかない ES2015をサポート(予定） 現時点ではクラスとかlet/constのブロックスコープは実装途中 Map/Setとかの組み込みクラス系は実装済み サイズの小ささをうたった処理系はES2015への対応はまだまだなのが多いので（Duktapeとか）良い 事前にJavaScriptのソースコードをパースして中間表現（LLVM IRをそのまま利用？）にしておいてロードする モバイルのCPUやバッテリー、メモリーにも優しい なお、エロいというのは強く感情が揺さぶられた結果が出てきたワードであってセクシャルな内容は一切含まれておりません

PySpa統合思念体です。 某チャットで、「今時のOSSのプロジェクト管理とかのベストプラクティスが書いてある本ないかな、陳腐化早そうだしないか」みたいな話題が投入されました。その中で、エキスパートPythonプログラミングとか、Pythonプロフェッショナルプログラミングとかは思い出して紹介したけど、他の人からはShip It、Manage It、Release It三部作とか、達人プログラマーとかも出てきました。 このあたりの源流を辿ると、そういえば今流行ってる開発の源流としてはエクストリームプログラミングの開発系のプラクティスの遺伝子を受け継いでいるのが多いよな、そういえば当時から見て今ってどう変わっているのかな、という話題に。せっかくなので20年前を思い出しつつ、当時と今でどういう風に変わってきたのか適当にまとめてみます。 20年前の状況 XP白本こと、eXtreme Progra

PySpa統合思念体です。あと、 @yosuke_furukawa にも協力いただきました。 基本的に、あまりエラーの種別を細かく判定してあげることはJavaScriptでは今までやってこなかったのですが、ちょっとしたメタデータを乗っけてあげるとか（例えばリトライ回数）、何か凝ったことをしたくなったらこういう方針でやればいいのでは、という試行錯誤録です。 エラーと例外の区別が必要か この手の話になると、エラーと例外の違いとか、こっちはハンドリングするもの、こっちはOSにそのまま流すものとかいろんな議論が出てきます。このエントリーではエラーも例外も差をつけずに、全部例外とひっくるめて説明します。 例外というのはすべて、何かしらのリカバリーを考える必要があります。 ちょっとしたネットワークのエラーなので、3回ぐらいはリトライしてみる 原因: ネットワークエラー リカバリー: リトライ サーバー

JavaScript いつの間にかずいぶん違う言語になったなぁ、と思うけど、 for(let i = 0; i < 100; i++) { /.../ } これはまだこう書くしかないのかな？const使えない？ — Takuo Kihira (@tkihira) June 6, 2019 このツイートを起点に、パフォーマンスの話が出て、紀平さんも計測されていたんですが自分でも思うところがあって計測して考察してみました。 実測前の僕の予想（というか過去の経験）は 普通のforが最速 for-inは速度以前に使ってはいけない for-ofとforEachは関数呼び出しがループごとに挟まるのでどちらも遅いが同じ水準 for ofは言語標準なので最適化が行われる期待！ でした。さて、結果はいかに？ それぞれのループの解説 伝統的なfor 伝統的なループが一番軽いというのはみんなが認めるところです。

フューチャーアドベントカレンダー2018のピンチヒッターです。ワイキキの海を見下ろすホテルからこんばんわ。 QUICがリブランドされてHTTP/3になったというのはそれなりに大きな話題になりました。これを機に学ぼうという人も多いと思いますが、個人的には費用対効果を考えると、まだ早いのではないかと思います。HTTP/2のときともまた違ってそんな学んだことが役に立つ人も多くないのではないかな、と思います。 HTTP/2を学ぶべきだがHTTP/3を（あえて）学ぶ必要はないと思う理由 HTTP/1.1からHTTP/2はほとんどの部分が同じです。フレーム単位で送受信する方式になって、メールとかネットニュースと同じようなテキストベースのプロトコルから変わったりという「表現のシンタックス」上の変更が中心でしたが、その上で表現する、たとえばクッキーの意味だとか、フォームなどの情報をどのようにシリアライズし

Futureアドベントカレンダー6日目です。昨日は @shun_shushu さんでした。 マイクロサービスまではいかなくても、gRPCなり、Swaggerなりを使って、リッチなSPAのフロントエンドと、いくつかのプロセスに分割されたバックエンドでサービスを開発したい、というニーズはあると思いますので、今までやってきた開発の反省・良かったところを踏まえて、次やるなら絶対にこうする・実際にこうし始めた！というDocker活用案です。 フロント、バックエンドのサービスを種類ごとに書いています。好きなフロントエンドと、好きなバックエンドのレシピを組み合わせて、オリジナルのdocker-compose.ymlを作る、という感じで読んでいただけるように書いています。対象言語とかも増やしたいので、この記事自体、検証結果を受けてどんどん変わっていく予定です。 ソースコードは次のリポジトリに置いておきます

Angularアドベントカレンダー2日目です。昨日は @kasaharu さんでした。 ReactやMithrilのテンプレートは基本的に、render()/view()メソッド内のJavaScriptの関数呼び出しですので、JavaScriptの文法でいろいろコードをいじることができます。それに対して、VueとAngularはテンプレート言語を持っていて、それを実行時に評価して（パースは事前に行うが）HTMLを生成します。 で、Angularの方には、テンプレートを構造化するためのもろもろの便利タグがあります。 <ng-container> ReactでいうところのFragmentです。ちょっとタグのようにみえるけど、タグではない、でも少しタグっっぽいタグです。表示するときには何も表示されません。Angularではタグに*ngIfとか*ngFor構造化ディレクティブをつけて、タグのON/

2019年版: 脱Babel!フロント/JS開発をTypeScriptに移行するための環境整備マニュアル環境構築TypeScriptライブラリReact TL;DR いろいろ書いていますが、一番書きたかったのは最初のライブラリと最後のReact Componentのプロジェクトの作り方ですね。ぱっとnpm installして、最初から型定義ファイルが入っていて、@typesを持っているライブラリを探したり、自分で.d.tsを書いたりしなくてもいい世界がやってきて欲しいな、という気持ちから書いています。 ここで紹介したTypeScript環境構築はすべて、自分用にYeomanのテンプレートとして作成したので、以下のジェネレータをインストールして選択したらそれでおしまいです。 @shibukawa/typescript (npmには公開していないので、checkoutしてビルドしてインストール

よくあるユースケースである、ヘッダーのハンバーガーメニューとドロワー。どうやって実装するのが良いでしょうか？ よくある実装としては、メニューとドロワーが置いてあるところの親のコンポーネントを置いて、ヘッダーのボタンが押されたコールバックを受け取り、ドロワーの表示フラグをオンにする、みたいな実装かと思います。明示的に関係を記述する、という感じ。 ですが、Angularではおそらく別の回答になります。Angularには暗黙的なインタラクションを可能にするAPIの数々があって、実際それを活用したコンポーネントなどもあるので、React/Vue/Mithrilとはちょっと違う世界が見える気がしたので、それを紹介します。 最近の主流のフロントエンドの世界観 まずは、Angularの話の前に、このエントリーの前提となる認識を合わせておきましょう。 最近は、フロントエンド界隈では、まずコンポーネントとい

Angularを使う Angular Materialを使う Angular Materialにカスタムテーマを設定する アプリケーションと同一環境で動作するライブラリでAngular Materialのテーマを利用 あたりは記事がたくさんあるのですが、ライブラリを作る、そのライブラリでAngular Materialのテーマを利用する、あたりの情報が見当たらなかったので（日本語でも英語でも）、せっかくなのでまとめました。Angular v6で試しています。 Angularのcliはインストール済み、チュートリアルの最初ぐらいはやった、を前提にして進めますが、ここで紹介するテクニックは、TypeScriptを使い、何かしらのフレームワーク用のライブラリを開発する、テーマに対応するUIフレームワークを作る、CSS in JSを積極的に活用しつつ、UIフレームワークと外部ライブラリでテーマを合

上の2つがCLIで、下の2つがブラウザです。歴史的な経緯を見てみましょう。 〜1.1: go docはバンドルされているツールで、ソースもgo本体に同梱 1.2: go docは別のリポジトリにわけられてgodocになり、go本体から外れた 1.3: godocで-analysisオプションが追加 1.5: 新しい"go doc"コマンドがgo本体に同梱 1.11: godocがウェブだけになるため、go docを使えというアナウンスが出るように 1.12: godocが-httpだけをサポートしてCLIの機能は削除予定 1.13: godocのwebサーバーが同梱されなくなって手動でのインストールが必要に 1.13～: 既存のgodoc.orgから、go modのプロキシサーバーの情報をもとにドキュメントをホスティングするpkg.go.devが運用開始 わかりましたか？よくわかりませんよ

ちなみに、3.7としているけど、ほぼ3.6でも問題なくいくかと思います。 本エントリーの方針 このエントリーではPython 3.7で動くアプリケーションの開発環境を作りますが、その過程で必要なツール（Python本体、pip、pipenv）をそれぞれの場所にインストールします。とりあえず次の方針でやります。Python本体以外はPythonのエコシステムでやっていきます。イージーよりはシンプルという方針です。 管理者権限が必要なシステムへの変更は最低限にする。ユーザー権限で入るものはユーザー権限で入れる。 PATHや環境変数への変更も最低限にする。 Python本体以外はOS固有のツールには依存しないようにする。 curlで取ってきたスクリプトをパイプでsudoで実行するみたいな頭に虫が湧いているようなマジキチなことはしない。 Python処理系環境構築 (システムごとに1度だけ実行）

2020/01/23追記: これはすでに古い情報です。ESLintとPrettierは同時に使わないのが今の推奨設定です。最新の情報は以下のところにあります。 https://future-architect.github.io/typescript-guide/baseenv.html 以下は過去の情報です PySpa統合思念体です。 go fmt便利ですよね。設定なしで言語が定めるルールで一発でやってくれるので良いですね。で、JavaScriptでは歴史的経緯もあって、フォーマットの流派はいろいろあります。 インデントはスペース2/4、ハードタブ 文字列にはシングルクオート使う派（英語キーボードだとシフトキー押さなくていい） 末尾のセミコロンは必須・省略 そのためカスタマイズ可能なフォーマッターが必要となります。カスタマイズの柔軟性や歴史的経緯や新しい文法への対応などで、いくつかのツー

最近、マルチコアでの性能向上についてよく考えている。フューチャーアーキテクト（裏）アドベントカレンダーです。 マルチコアの性能向上の基本 マルチスレッドの性能向上というと、アムダールの法則というのが有名で、なにかと引用される。僕の本の「Goならわかるシステムプログラミング」でも引用させていただいた。 P は並列化できる仕事の割合、N は並列数です。ある仕事のうち 50% の部分が並列化 可能だとすると、N を無限大にしても(分母の右側の項がゼロになる)、パフォーマン スは 2 倍にしかなりません。90% が並列化可能だとすると、最大で 10 倍になります。 並列化の恩恵がどれだけあるかは、並列化できる仕事の割合によって変わるのです。 アムダールの法則によると、並列化して効率がどれだけ改善できるかは P にかかっ ているといえます。P を改善するには、