はてなブックマーク

This article is a Private article. Only a writer and users who know the URL can access it. アーキテクチャの議論でよく出てくるのが、コンウェイの法則と、逆コンウェイ戦略です。これについては、うっかりIT用語をバズらせてしまう達人のマーチン・ファウラーのブログにも詳しい説明があります。角さん、いつも翻訳ありがとうございます。 「逆コンウェイの法則」が持ち出された議論が苦手なんどけど、なんでなのかな。コンウェイの法則はよく理解できるんだがー。 — Kazunori Otani (@katzchang) February 28, 2023 この@katzchangさんのツイートもそうですが、逆コンウェイ戦略に関しては僕も少しモヤモヤするところが個人的にあり、そのあたりを周りの人（@katzchangさんや@

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

pyspa Advent Calendar 2021のエントリーです。昨日は@kuenishiさんでした。 どんなプログラミング言語でも、最終的にはOSへのシステムコールとなってプログラマーがやりたいことを実現しています。文字列をコンソールに出したり、ファイル入出力、ネットワーク入出力などなど。Goの場合Goならわかるシステムプログラミングという本がありますね。もちろん、みんな一人10冊ずつぐらいお買い上げのことだと思いますが、せっかくなので他の言語でも見てみましょう。 ここで扱うのは先日、TIOBEインデックスでプログラミング言語の人気No.1になったPythonです。 ただし、Pythonでメインの処理系のCPythonではなくてPyPyで見ていきます。理由は後から説明します。 PyPyのコードは次の場所でホストされています。 早速、次のコードの中身を見ていきましょう。 print()

しかし、パッケージとしては以下のような依存が発生してしまっています。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はあまりきちんと試していま

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

なお、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もないため、ビルドイメージにすることもできません。いろいろ調べた結果、

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? PySpaアドベントカレンダーのエントリーです。昨日はYesterdayでした。今日はTodayです。 ずっと開発や普段使いで使えるChromebookが欲しいと思っていました。勉強会の発表で使ったりするので、きちんと技適が通ったやつで、性能がまとも（以前ATOMベースのマシンにLinux入れたけど遅くて使う気になれなかったので）なやつを待ち望んでいました。 7月ぐらいからHPがChromebookを販売開始してくれました。気づいてから申し込んだものの、予想外に受注があったのか、納期が伸びに伸びて1ヶ月半近くかかりましたが、とても良いも

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

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

ユーザーの認証と認可を行う方法としては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化したら多くの人に使ってもらいたいですよね？というのは考えるわけですが、その「

PySpa統合思念体です。これからJavaScriptを覚えるなら、「この書き方はもう覚えなくていい」（よりよい代替がある）というものを集めてみました。 ES6以降の難しさは、旧来の書き方にプラスが増えただけではなく、大量の「旧来の書き方は間違いを誘発しやすいから非推奨」というものを作り出した点にあります。5年前、10年前の本やウェブがあまり役に立たちません。なお、書き方が複数あるものは、好き嫌いは当然あると思いますが、あえて過激に1つに絞っているところもあります。なお、これはこれから新規に学ぶ人が、過去のドキュメントやコードを見た時に古い情報を選別するためのまとめです。残念ながら、今時の書き方のみで構成された書籍などが存在しないからです。 たぶん明示的に書いていても読み飛ばす人はいると思いますが、すでに書いている人向けではありません。これから書くコードをこのスタイルにしていくのは別にいい

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

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? PySpa統合思念体です。 某チャットで、「今時のOSSのプロジェクト管理とかのベストプラクティスが書いてある本ないかな、陳腐化早そうだしないか」みたいな話題が投入されました。その中で、エキスパートPythonプログラミングとか、Pythonプロフェッショナルプログラミングとかは思い出して紹介したけど、他の人からはShip It、Manage It、Release It三部作とか、達人プログラマーとかも出てきました。 このあたりの源流を辿ると、そういえば今流行ってる開発の源流としてはエクストリームプログラミングの開発系のプラクティスの遺

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 伝統的なループが一番軽いというのはみんなが認めるところです。

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? フューチャーアドベントカレンダー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を作る、という感じで読んでいただけるように書いています。対象言語とかも増やしたいので、この記事自体、検証結果を受けてどんどん変わっていく予定です。 ソースコードは次のリポジトリに置いておきます

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

TL;DR いろいろ書いていますが、一番書きたかったのは最初のライブラリと最後のReact Componentのプロジェクトの作り方ですね。ぱっとnpm installして、最初から型定義ファイルが入っていて、@typesを持っているライブラリを探したり、自分で.d.tsを書いたりしなくてもいい世界がやってきて欲しいな、という気持ちから書いています。 ここで紹介したTypeScript環境構築はすべて、自分用にYeomanのテンプレートとして作成したので、以下のジェネレータをインストールして選択したらそれでおしまいです。 @shibukawa/typescript (npmには公開していないので、checkoutしてビルドしてインストールしてください) 2020/7/26: React周りを現在の最新の情報に更新 2019/1/22: TSLint→ESLintに修正 2019/8/1:

よくあるユースケースである、ヘッダーのハンバーガーメニューとドロワー。どうやって実装するのが良いでしょうか？ よくある実装としては、メニューとドロワーが置いてあるところの親のコンポーネントを置いて、ヘッダーのボタンが押されたコールバックを受け取り、ドロワーの表示フラグをオンにする、みたいな実装かと思います。明示的に関係を記述する、という感じ。 ですが、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フレームワークと外部ライブラリでテーマを合

わかりましたか？よくわかりませんよね？まあ、godocとgo docは同じドキュメントツールですが、別のツールです。本家と元祖みたいなものとして、長らく平行で提供されてきました。ちょうどこの記事を書いている少し前にリリースされた1.11で、godocの方がウェブだけになるとリリースノートに書かれました。 また、godoc.orgのサーバーはローカルのgodocコマンドよりも機能が増えていたり、テンプレートが微妙に違ったりします。とはいえ、ドキュメントを書くときはこれらの違いはそこまで気にすることはありません。 2020/09/19追記: 現在はpkg.go.devが稼働を開始し、godoc.orgのページにアクセスするとこちらへのリダイレクトをするかどうかを問い合わせるバナーが出ます。将来的にはこちらに一本化されると思います。開発者が行うべきこと、記述すべきことは差はありません。このドキュ

PySpa統合思念体です。 Pythonの開発環境の最新の環境の構築に挑戦してみたら、いろいろ型チェックとかできるようになって面白かったのですが、まとまった情報がなかったのでまとめてみます。基本的にはmacOSでやっているけど、Python本体のインストール以外には使用しているツール類はOS依存のものは使っていないため、パスや環境変数の設定を読み替えれば他の環境でも使えると思います。もし他の環境で注意すべきポイントがあったらお気軽に編集リクエストください。 本エントリーは @aodag と @moriyoshi 、 @knqyf263 の情報提供により完成しました。ありがとうございました。 タイトルの意味 タイトルは本文の想定状況を過不足なく状況をお伝えするために色々制約を加えています。「内作アプリケーション」と書いているのは、配布しているツールとかでなければ、特定のバージョン1つを選択し