Go 1.13時代のエラー実装者のお作法 - Qiita
Goアドベントカレンダーその2の3日目のエントリーです。 Goではエラー処理の方法としてはプリミティブな方法しか提供しておらず、他の言語のユーザーからやいのやいの言われてきました。Go2でそれを改善するぞからプロポーザル募集でいろいろ意見を募っては二転三転みたいな感じで、Go 1.13ではだいぶおとなしい感じに機能拡張されました。基本的な方向性としてはgithub.com/pkg/errorsから少し機能を取り込んだ感じです。 すでに、数多くのエントリーやらプレゼンテーションやらでGo 1.13の利用者視点でのerrorsの変更点については触れられてきましたので詳しくはそちらをご覧ください。サマリーとしては下請けのパッケージで出てきた詳細なエラーをラップして扱うための便利な機構がいろいろ追加された感じです。 これらでは主にアプリケーションコードの実装者というかライブラリの利用者向けの説明が
JavaScript/TypeScriptの例外ハンドリング戦略を考える - Qiita
PySpa統合思念体です。あと、 @yosuke_furukawa にも協力いただきました。 基本的に、あまりエラーの種別を細かく判定してあげることはJavaScriptでは今までやってこなかったのですが、ちょっとしたメタデータを乗っけてあげるとか（例えばリトライ回数）、何か凝ったことをしたくなったらこういう方針でやればいいのでは、という試行錯誤録です。 エラーと例外の区別が必要か この手の話になると、エラーと例外の違いとか、こっちはハンドリングするもの、こっちはOSにそのまま流すものとかいろんな議論が出てきます。このエントリーではエラーも例外も差をつけずに、全部例外とひっくるめて説明します。 例外というのはすべて、何かしらのリカバリーを考える必要があります。 ちょっとしたネットワークのエラーなので、3回ぐらいはリトライしてみる 原因: ネットワークエラー リカバリー: リトライ サーバー
チョットできるGoプログラマーになるための詳解GoDoc - Qiita
上の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が運用開始 わかりましたか？よくわかりませんよ
2018年のJavaScriptのコードフォーマッター事情 - Qiita
2020/01/23追記: これはすでに古い情報です。ESLintとPrettierは同時に使わないのが今の推奨設定です。最新の情報は以下のところにあります。 https://future-architect.github.io/typescript-guide/baseenv.html 以下は過去の情報です PySpa統合思念体です。 go fmt便利ですよね。設定なしで言語が定めるルールで一発でやってくれるので良いですね。で、JavaScriptでは歴史的経緯もあって、フォーマットの流派はいろいろあります。 インデントはスペース2/4、ハードタブ 文字列にはシングルクオート使う派（英語キーボードだとシフトキー押さなくていい） 末尾のセミコロンは必須・省略 そのためカスタマイズ可能なフォーマッターが必要となります。カスタマイズの柔軟性や歴史的経緯や新しい文法への対応などで、いくつかのツー
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で使われたパッケージを利用したいこともあるでしょうし、雑にコマンドラインを利用することもあるだろう、ということで、今回も、できることを減らさずに（やりたいことにしたがって細かく作戦を微調整する必要がない）、なるべく小さく、という方針でいきたいと
イマドキのJavaScriptの書き方2018
PySpa統合思念体です。これからJavaScriptを覚えるなら、「この書き方はもう覚えなくていい」（よりよい代替がある）というものを集めてみました。 ES6以降の難しさは、旧来の書き方にプラスが増えただけではなく、大量の「旧来の書き方は間違いを誘発しやすいから非推奨」というものを作り出した点にあります。5年前、10年前の本やウェブがあまり役に立たちません。なお、書き方が複数あるものは、好き嫌いは当然あると思いますが、あえて過激に1つに絞っているところもあります。なお、これはこれから新規に学ぶ人が、過去のドキュメントやコードを見た時に古い情報を選別するためのまとめです。残念ながら、今時の書き方のみで構成された書籍などが存在しないからです。 たぶん明示的に書いていても読み飛ばす人はいると思いますが、すでに書いている人向けではありません。これから書くコードをこのスタイルにしていくのは別にいい
Goのリバースプロキシーでレスポンスを書き換える - Qiita
フューチャーアーキテクトアドベントカレンダーの5日目の サーバーサイドレンダリングの代替としてPrerenderを試してみたの最後で、「Go実装について 長くなったので説明は省略します。だれかがGoアドベントカレンダーを落としたら書くかも？」と書いていたら、早速落とす人がいたらしいので、ハイジャックします。 リバースプロキシーはnet/http/httputilパッケージの ReverseProxyを使えば簡単につくれますよ、という説明はよく見かけるのですが、レスポンスを書き換える方法はまとまった情報がなかったので紹介します。 リクエストを書き換える go言語でリバースプロキシというブログのエントリーにある通りです。 向き先を書き換える、Directorというフック関数を設定してあげることで、向き先を変えられます。なお、このエントリーにあるように、この関数の中でrequestを書き換えるこ
GraphQLは90%のウェブサービス開発者にはまだ時期尚早ではないか - Qiita
PySpa統合思念体です。チャットで話をしたことのまとめです。何人かで雑に話をしたことのまとめで、特定の誰かの発言というわけではなく、一種の怪文書です。 さて、GraphQLが世間を賑わせ始めています。Facebookが開発し、GitHubも機能提供をし始めました。GraphQLはRESTの未来か？みたいな論調もありますが、新しいものが出てくると既存のものをサンドバックにして「まだそんな古いの使ってやがるのかよwwwww」みたいな煽りをするのはもはやウェブ界隈の風物詩になっていますが、そういう信者発言をして「ああ、あいつまた踊らされてるな」「あいつ技術を見る目がないな」みたいに思われないように、少し冷静にGraphQLの立ち位置や、今後予想される流れについて考えてみます。 LSUDsとSSKDs WebAPI The Good Partsでも紹介されていた概念として、Netflix社のAP
オレの最弱のES6開発環境 - Qiita
ブラウザのES6サポートが急速に良くなってきています。社内ツールとかElectronとか、ブラウザの普及率を気にしなくていい環境ならそろそろ使えるのではないかと思って調べたり試してみたりしています。 更新 https://caniuse.com/#search=es6 http://kangax.github.io/compat-table/es2016plus/ これを見るともうほぼ実装は完了していますね。Node.jsも対応していますし使えるブラウザが限定できるならもはや変換なんかしなくても大丈夫。注意点としては以下の2つ。 IE11は渋い ES6 modulesはまだまだ ソースをES6で書いて、結果もそのままES6という手抜き開発に使えるツールのメモです。手抜きなので、おそらく経年変化の影響はほとんどないはずです。対象としてはブラウザだったり、ElectronでのSPA開発です。
最速という噂のFlatbuffersの速度のヒミツと、導入方法の紹介(Go) - Qiita
GoCon 2015 Winterでは、社内での取り組みとしてExcelのパースの時間のロスを避けるために、簡易データ構造を使ってMessagePack + LZ4で圧縮して高速化したことを紹介しました。それでも十分速くはなったのですが、LTで発表のあったシリアライズ系のライブラリのベンチマーク比較でFlatbuffersが最速だったので、ちょっと試してみました。 ↑のグラフは、こちらのベンチマークの結果をExcelでグラフにしてみたものです。Gobがダントツ遅かったのでそちらは振りきっています(Gobに合わせると他のものの比較がしにくくなるので範囲を狭めた)。GoConで発表した通り、今MessagePackを使っているのはデータのキャッシュです。作成に多少がかかっても、後の読み出しが速い方がトータルとしてはうれしい領域なので、Unmarshalが最速のFlatbuffersに俄然興味を
Electron + Mithrilで、ふつうのデスクトップアプリを作る - Qiita
最近は、Mithrilのお陰で、シングルページアプリケーションが大分作りやすくなりました。仕事でも使ってます。あ、ドキュメントの日本語訳もありますよ。本もあります！ http://mithril-ja.js.org/ http://www.oreilly.co.jp/books/9784873117447/ 社内ツールを作るのにMithrilとElectronで作ってみたのですが、ふつうのデスクトップアプリを作るのにちょっと手間が多いので(これはMithrilを使わなくても)、ふつうを実現するためのフレームワークについて考えて実装してみました。特にまだ名前はありません。 Electronとは？ Electronはウェブ的なスキルがあれば、それが簡単にデスクトップで動くようになるという仕組みです。元々はatom-shellと呼ばれていました。類似のものに、NW.js(元node-webkit
node.jsで子プロセスを起動しまくってエラーにならないようにするモジュール - Qiita
https://github.com/shibukawa/spawn-limit https://www.npmjs.com/package/spawn-limit spawn-limit というモジュールを作りました。node.jsのchild_process.spawn()の薄いラッパーで、通常のspawnはChildProcessオブジェクトを返して、そいつに色々イベント登録して・・・という使い方をするんですが、プロセスを起動したらthenが呼ばれるPromiseを返すモジュールです。 ブラウザでサーバ間通信のコールバックの管理をPromiseでやるのは問題になることはないと思います。ネイティブのレイヤーで同時通信数を絞ってくれるので、アプリレイヤーで細かいことを考える必要はないでしょう。 今回はnode.jsで外部プロセスを起動しまくるコードを書いたら、プロセス数制限に引っかかって
Go用のGoogle製のGUIツールキットgxuiのインストール - Qiita
GoogleがGo用の新しいGUIライブラリのgxuiをリリースしました。 ソースコードを見て分かる特徴 ボタン、テキスト入力、ツリーコンポーネントとかがありそう ツリーアダプタ的なクラスがある。直接ツリーコンポーネントに要素を追加するんじゃなくて、MVC的な作り？ テーマが切り替えられる。darkというのが最初から組み込まれている。色を変えるぐらいならすぐできそう。ちなみに、テーマといいつつ画像データはなくてフルソースコード。 ベースはOpenGL。 C拡張を使っているのでクロスコンパイルは簡単ではなさそう。 Macへのインストール MacOSX 10.9+Golang 1.4.2(公式バイナリ)で試しています。 glewというライブラリが必要そうなので、Sourceforgeからtarballをダウンロードしてきてインストールします。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
