本当は怖い、逆コンウェイ戦略 - Qiita
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さんや@
M1 Macの開発環境 - Qiita
MacBook Pro (M1)でのメモです。インストールできるかどうか状況確認メモです。 自分がよく使うものを中心に。なるべくARMネイティブになるように。もしプライマリーで提供されているインストール手段（.dmg利用など）でARM対応が済んでいればそれを紹介しますが、もしそれで対応していない場合にはMacPortsやソースビルドなどの結果も合わせて紹介します。 PowerPC->x86->x86_64とユニバーサルバイナリを挟んで対応してきたMacPortsはこういう過渡期に強いです。 なお、ここで紹介するバージョンは最新版から古い可能性がありますが、「M1サポートが追加された前後のバージョン」を明記するのを目標にしていますので、これより新しければ問題ないと見てもらえればと思います。 編集リクエストウェルカムです。 現在の状況 IDE/エディタ Eclipseはあまりきちんと試していま
2019年版: JavaScriptのループの考察 - Qiita
JavaScript いつの間にかずいぶん違う言語になったなぁ、と思うけど、 for(let i = 0; i < 100; i++) { /.../ } これはまだこう書くしかないのかな？const使えない？ — Takuo Kihira (@tkihira) June 6, 2019 このツイートを起点に、パフォーマンスの話が出て、紀平さんも計測されていたんですが自分でも思うところがあって計測して考察してみました。 実測前の僕の予想（というか過去の経験）は 普通のforが最速 for-inは速度以前に使ってはいけない for-ofとforEachは関数呼び出しがループごとに挟まるのでどちらも遅いが同じ水準 for ofは言語標準なので最適化が行われる期待！ でした。さて、結果はいかに？ それぞれのループの解説 伝統的なfor 伝統的なループが一番軽いというのはみんなが認めるところです。
イマドキのJavaScriptの書き方2018
PySpa統合思念体です。これからJavaScriptを覚えるなら、「この書き方はもう覚えなくていい」（よりよい代替がある）というものを集めてみました。 ES6以降の難しさは、旧来の書き方にプラスが増えただけではなく、大量の「旧来の書き方は間違いを誘発しやすいから非推奨」というものを作り出した点にあります。5年前、10年前の本やウェブがあまり役に立たちません。なお、書き方が複数あるものは、好き嫌いは当然あると思いますが、あえて過激に1つに絞っているところもあります。なお、これはこれから新規に学ぶ人が、過去のドキュメントやコードを見た時に古い情報を選別するためのまとめです。残念ながら、今時の書き方のみで構成された書籍などが存在しないからです。 たぶん明示的に書いていても読み飛ばす人はいると思いますが、すでに書いている人向けではありません。これから書くコードをこのスタイルにしていくのは別にいい
Goのリバースプロキシーでレスポンスを書き換える - Qiita
フューチャーアーキテクトアドベントカレンダーの5日目の サーバーサイドレンダリングの代替としてPrerenderを試してみたの最後で、「Go実装について 長くなったので説明は省略します。だれかがGoアドベントカレンダーを落としたら書くかも？」と書いていたら、早速落とす人がいたらしいので、ハイジャックします。 リバースプロキシーはnet/http/httputilパッケージの ReverseProxyを使えば簡単につくれますよ、という説明はよく見かけるのですが、レスポンスを書き換える方法はまとまった情報がなかったので紹介します。 リクエストを書き換える go言語でリバースプロキシというブログのエントリーにある通りです。 向き先を書き換える、Directorというフック関数を設定してあげることで、向き先を変えられます。なお、このエントリーにあるように、この関数の中でrequestを書き換えるこ
printデバッグについて - Qiita
初心者が多用するデバッグ法というと、printデバッグです。誰に教わることもなく、自然と自己発見して使い続けるケースが多い気がしています。 プログラマーの三大美徳には怠惰という文言があります。ただ、この怠惰というのは繰り返し作業をやめるために、アクティブな行動を伴うので、別なポジティブなラベリングがされるべきだし、個人的にはちょっと違和感があります。低きに流れて部分最適化されてしまうprintデバッグこそ愛すべき怠惰な気がしています。 UI/UXというと、すごい意識高い感じだけど、じつは意識の低さが大事だと思っていて、低きに流れた先が最短ルートで目的というのが大事なんじゃないかと。何かを探すときはまずスタートボタン（Windows95）。困ったらホームボタン（iOS）。OSごとのUIガイドラインに従うのも、そのユーザーにとってすでに常識となっている使い方に対応することで、ユーザーに新しい学
最速という噂のFlatbuffersの速度のヒミツと、導入方法の紹介(Go) - Qiita
GoCon 2015 Winterでは、社内での取り組みとしてExcelのパースの時間のロスを避けるために、簡易データ構造を使ってMessagePack + LZ4で圧縮して高速化したことを紹介しました。それでも十分速くはなったのですが、LTで発表のあったシリアライズ系のライブラリのベンチマーク比較でFlatbuffersが最速だったので、ちょっと試してみました。 ↑のグラフは、こちらのベンチマークの結果をExcelでグラフにしてみたものです。Gobがダントツ遅かったのでそちらは振りきっています(Gobに合わせると他のものの比較がしにくくなるので範囲を狭めた)。GoConで発表した通り、今MessagePackを使っているのはデータのキャッシュです。作成に多少がかかっても、後の読み出しが速い方がトータルとしてはうれしい領域なので、Unmarshalが最速のFlatbuffersに俄然興味を
OracleとGoogleの判決文を斜め読む - Qiita
(7/7追記)僕は斜め読みだったんですが、もっときちんと読んだ上で解釈を書いてくれている方がいます。僕も時間をとって全文を読みたいとは思っていますが、まだ時間がかかりますし、yudaiさんの会社の方が妥当性は高いと思いますので、そちらをご参照ください↓ 朝っぱらから色々衝撃が走った第一四半期の最終日ですが、OracleとGoogleの裁判について、どのあたりが問題だったとされるのか気になるので判決文等を読んでみました。 経緯 2010年8月、OracleはGoogleを訴える。当初の争点は特許侵害 (publicKey1) 2012年4月、サンフランシスコ連邦地裁の法廷開始 2012年5月、Googleの特許侵害はないとの陪審評決。ただし、フェアユースは意見が別れる。 2012年6月: Oracle対GoogleのJava/Android訴訟、損害賠償金ゼロで合意。今回議論された37件のJ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
