タグ

ブックマーク / qiita.com/shibukawa (9)

  • fmtパッケージをインポートするとファイルサイズがどかんと増えてしまう理由 - Qiita

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

    fmtパッケージをインポートするとファイルサイズがどかんと増えてしまう理由 - Qiita
  • イマドキのJavaScriptの書き方2018

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

    イマドキのJavaScriptの書き方2018
  • 最小のNode.jsのDockerイメージを目指すスレ - Qiita

    フューチャーアーキテクトアドベントカレンダーに投稿したサーバーサイドレンダリングの代替としてPrerenderを試してみたに引き続き、JS系?ウェブ系?なエントリーです。 ECSとかEKSとか出てきて、コンテナを使うと、一つの物理ホストで、複数のコンテナをさばいて効率を上げる、というのが簡単にできるようになってきました。そのため、Node.jsのアプリもDocker化して配りたいですよね? 次のスライドを見ると、サイズが小さいほうが良いとされています。中には静的リンクが云々みたいなトリッキーな技もありますが、そこまでがんばらない&黒魔術にならない程度でがんばる方向でサイズを小さくしてみたいと思います。 お前のDockerイメージはまだ重い💢💢💢 by stormcat24 STEP1: Alpine + 標準ライブラリのみ 小さいというAlpine Linuxを使ってみます。クールな

    最小のNode.jsのDockerイメージを目指すスレ - Qiita
  • Dockerで最小のGoのイメージを作成する(cgo編) - Qiita

    「最小のNode.jsのDockerイメージを目指すスレ」、「JavaでもDockerでマルチステージビルド」というエントリーでは、Node.jsとJavaを使ったアプリケーションのイメージをなるべく小さくするトライアルをしました。 今度はGoでやってみます。ただし、Pure Goで最小というのはすでに方法があって、scratchという何も含まれないイメージを元に、静的リンクしたバイナリを配置するという方法です。 Building Minimal Docker Containers for Go Applications Goを使う場合に、一部cgoで使われたパッケージを利用したいこともあるでしょうし、雑にコマンドラインを利用することもあるだろう、ということで、今回も、できることを減らさずに(やりたいことにしたがって細かく作戦を微調整する必要がない)、なるべく小さく、という方針でいきたいと

    Dockerで最小のGoのイメージを作成する(cgo編) - Qiita
  • サーバーサイドレンダリングの代替としてPrerenderを試してみた - Qiita

    9月から入社したフューチャーアーキテクトのアドベントカレンダーのエントリーです。技術的にはウェブフロントエンドGolangあたりです。 シングルページアプリケーションを数年前に試してみて、やりたい表現はこれで十分できるし、過去大変だったことも大分解消されましたのを感じました。一方でSEOとかOGPとかいくつかそのまま実現できないものがあります。とはいえ、それの解消のためにサーバーサイドレンダリングをするのは実装の手間が大変です。そこで、設計時に考えなきゃいけないことが増えます。ウェブアプリケーション側でその手の考慮&実装をいっさいせずに、今時のウェブアプリケーションでやった方がいいことを実現できる方法について考えました ・・・と思って準備しておいたのですが、@R548さんがDMM.comさんのアドベントカレンダーに書かれてしまった内容と一部かぶります。合わせてお読みいただくと、理解が深ま

    サーバーサイドレンダリングの代替としてPrerenderを試してみた - Qiita
    mapk0y
    mapk0y 2017/12/11
  • サーバーサイドレンダリング不要論 - Qiita

    サーバーサイドレンダリング、Isomorphic、Universal JavaScriptなどの言葉をよく見かけます。なるほどね、良さそうだね、外部公開するサービスを書くことがあったら挑戦してみたいね、Mithrilにもisomorphic-mithrilってのをがんばっている人がいるし、みたいなことを漠然と思っていたのですが、最近ASCII.jpのシステムコールプログラミングの連載を書いていて、あらためてHTTPの仕様を見返してみて、逆にサーバーサイドレンダリングをしない方がいいのではないか、と思い始めました。 追記(23:30): サーバーサイドレンダリングと書いていますがUniversal JavaScriptみたいな凝ったビューの更新の意味です。 サーバーサイドレンダリングの欠点 サーバーサイドレンダリングのメリットとしてあげられるのは次の2点です。 検索エンジンのクローラー向け

    サーバーサイドレンダリング不要論 - Qiita
  • pyenvが必要かどうかフローチャート - Qiita

    pyspaの統合思念体の渋川です。 「pyenv使いましょう!」系の記事、全部ゴミ — Yoshifumi YAMAGUCHI (@ymotongpoo) September 29, 2016 これはpyenvがダメではなくて、pyenvをとりあえずインストールしておきましょう記事がダメという意味だそうです。すでにとんぷーが5年前にこの問題について書いています。これを読んで分かる人には不要です。 この記事では「便利」と「必要」は分けて考えています。後者にフォーカスしています。 前提知識 Environment Isolation Tool(環境分離ツール)というカテゴリの開発補助ツールがあります。pip install Sphinxとか書いたら、ライブラリはグローバル空間に入っちゃいます。複数バージョン入れられません。そんなときに使うのが、この環境分離ツールです。最近はいろいろな言語がこれ

    pyenvが必要かどうかフローチャート - Qiita
  • Cache-Controlヘッダは仕様通り実装されていない? - Qiita

    最初に 次のエントリーで追試しました。エントリーの内容は古いです。一応Qiitaは履歴もとってくれるのでこの記事を上書きしちゃってもいいんですが、そうなるとコメントのコンテキストがわからなくなってしまうので、別記事にしました。エントリーも記録のために残します。 Cache-Controlヘッダは仕様通り実装されていない?(2) 編 HTTPのキャッシュの仕組みをいろいろ調べているのですが、よくわからなかったので実験してみました。 HTTP キャッシュの作成 14.9 Cache-Control 上記のサイトの説明によれば、no-cacheとmust-revalidateは非常に近い説明になっています。no-cacheはsubsequent requestと書いてあるので、.htmlから呼ばれる.css、.jsあたりのことまで(subsequent request)書いていると思われま

    Cache-Controlヘッダは仕様通り実装されていない? - Qiita
    mapk0y
    mapk0y 2016/07/06
    検証は docker の selenium イメージ使ってやるのが便利
  • OracleとGoogleの判決文を斜め読む - Qiita

    (7/7追記)僕は斜め読みだったんですが、もっときちんと読んだ上で解釈を書いてくれている方がいます。僕も時間をとって全文を読みたいとは思っていますが、まだ時間がかかりますし、yudaiさんの会社の方が妥当性は高いと思いますので、そちらをご参照ください↓ 朝っぱらから色々衝撃が走った第一四半期の最終日ですが、OracleGoogleの裁判について、どのあたりが問題だったとされるのか気になるので判決文等を読んでみました。 経緯 2010年8月、OracleGoogleを訴える。当初の争点は特許侵害 (publicKey1) 2012年4月、サンフランシスコ連邦地裁の法廷開始 2012年5月、Googleの特許侵害はないとの陪審評決。ただし、フェアユースは意見が別れる。 2012年6月: OracleGoogleJava/Android訴訟、損害賠償金ゼロで合意。今回議論された37件のJ

    OracleとGoogleの判決文を斜め読む - Qiita
  • 1