サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
れい(猫耳の専門家)🍥 @rei_software 最近あったトラブル 証言１「朝ネットが使えないことがある」 俺（WiFi機器のスリープ復帰障害とかかな？ 証言２「有線だけダメ。無線はOK」 俺（有線で朝だけっておかしいな？夜も通信してるし 証言３「Aさん（中国人）が来るとネットが使えない」 俺（人依存かよ…どうせ間違いだろ で、調査したら 2020-11-04 08:43:19 れい(猫耳の専門家)🍥 @rei_software 確かにAさんが出勤してしばらくすると20分ほどネットが使えない端末があるっぽい。 で、出勤してからの行動を見ると ・入室 ・席でカバンを置く ・給湯室でお茶をつくる ・お茶をもって席に ・大抵はメールチェック←このあたりでネットが使えない人が出始める という現象が。 2020-11-04 08:46:26 れい(猫耳の専門家)🍥 @rei_softwar
再発防止策を書くのは難しい。 良い再発防止策 良い再発防止策について、順位付けするとしたら、 その種類の問題について二度と意識することがなくなる解決策 その種類の問題を開発時に自動的に検知することができる解決策 その種類の問題が発生しても自動的に復旧することができる解決策 その種類の問題が発生しても影響が局所化される、フールプルーフ、フェールセーフになる解決策 と言うのは意識したいと思いつつ、やはり難しい。 再発防止はむずかしい 障害の再発防止策は、 メカニズム ツール ルール チェックリスト の順番に検討せよ。と言われても、急いで書けなんて言われると「次回からは複数人でチェックします。」とか「チェック項目を追加します。」とかいう徹底できなそうな「反省文」になってしまう。 まさにこの有名な猫...。 **「なぜミスを繰り返すのか」「どうすればミスを防げるのか」を真剣に考えていないことがミス
NTT東西の提供するFTTHサービス「フレッツ・光ネクスト」では、「IPv6オプション」を利用（IPv6オプションは2012年のある時期以降に新規開通した回線ではデフォルトで利用可能な状態になっている）することにより、NTT東日本、NTT西日本それぞれのエリア内でインターネットを経由しないフレッツIPv6網内折り返し通信が可能であることは、本ブログの読者の多くはご存知かと思います。 IPv6網内折り返し通信は、遅延やパケットロスが極めて少ないことや、PPPoEでのインターネット接続と比較して、スループットが高いこと、ISP契約が不要であることなどにより、安価で高品質なベストエフォートなVPN構築用回線として利用されることがあります。AS59105(HOMENOC)でも、拠点間の回線は Ether over IP トンネルやGREトンネルなどをIPv6網内折り返し通信の上で構築して利用してい
こんにちは、id:shallow1729です。最近はインフラ寄りなお仕事をよくやっていますがこれまでにいくつかデータ移行やデータ基盤構築などのバッチ処理のお仕事をしてきました。以前にも一度そういった経験を元に記事を書いたのですが、MySQLやシステムに関する知識が以前よりも増えた今もう一度書き直したいなと思いました。 なので今回はバッチ処理を書く時のテクニック2022版という感じです。今の仕事の関係でMySQLやrailsを前提にしている話が多いですが、おそらく他のデータベースを使っている人にも役に立つ話が多いのではないかと思います。ただ、今回の記事は経験に基づくものが多く、あまりよくないアイデアもあるかもしれません。改善点や間違いなどあればご指摘ください。 冪等性を持つように 冪等性とは端的に言えばある操作を複数回実行しても一回しか実行しなかった時と同じ結果になる性質の事です。長時間かか
Ｓ Ｕ Ｚ Ｕ@旅パッキングand客力の磨き方 @suzukyuin ヒューマンエラーの勉強をすると「気をつける」は対策ではありませんと、教え込まれるので。全てのものにフールプルーフ＆フェールセーフをするようになるので、エラーが減ります。 エラーする人は自分を信じすぎでは？って思ってる。 Ｓ Ｕ Ｚ Ｕ@旅パッキングand客力の磨き方 @suzukyuin 得にルーティーンで決まってることの途中でイレギュラートラップ（例えば話しかけられる、電話かかってくるとか途中の流れをインターセプトされる状況）が起きると、全部スッこ抜けて大事故につながるエラーを起こすので、そう出来ない仕組みを作るとかね。 とにかく「人は間違える」って思うの大事 Ｓ Ｕ Ｚ Ｕ@旅パッキングand客力の磨き方 @suzukyuin とんでもないのは「自分は間違えない」って変な自信を持ってる人。この手の人は「間違えるわけな
はじめに こんにちは、皆さん。今日は、シェルスクリプトを使った高度な自動化のベストプラクティスとパターンについて解説します。これらは、ちょっとした知識で実行でき、作業を大幅に効率化できるTipsです。シェルスクリプトは、特にUNIX系システムでの自動化タスクに欠かせないツールです。適切に使用すれば、複雑なタスクを効率的に、そして信頼性高く実行できます。 トイルとは、反復的でマニュアルな作業のことを指します。これには、例えば、手動でのシステムのスケーリングや、エラーのトラブルシューティング、ルーティンなメンテナンス作業などが含まれます。トイルを特定し、それを自動化することで、エンジニアはより創造的なタスクやプロジェクトに焦点を合わせることができます。 トイルを判別する方法としては、以下のような基準が挙げられます： 手作業であること 完全な手作業だけでなく、「あるタスクを自動化するためのスクリ
C言語（C++を含む）を習得したい人，ポインタを勉強したい人はgcc-14を使いましょう．難しいところは gcc-14 が丁寧に解説してくれます C言語の難しいところ 例を示します．C言語で記述された，たった６行のソースコードです int main() { int buf[10]; buf[10] = 0; return 0; } このソースコードには問題があります．初見でわかるでしょうか？ : : : 問題があるのは buf[10]=0 の部分です．C言語でやりがちなミスですが，これがバグやセキュリティホールの原因になります． C言語が難しい理由は二つあります．この手の問題を見逃しやすい点と，この手の問題を理解することが難しい点の二つです gcc 14 に解説してもらいましょう 上記の６行のソースコードをgcc14を使ってコンパイルしてみます ソースコードのファイル名は test.c と
こんにちは、m3 エンジニアリンググループ CTO 矢崎(id:Saiya)です。 過去に Go 言語の仕様を一通り見た経験があったのですが、久しぶりに Go のコードを最近読み書きした際に、ここ数年の Go 言語やエコシステムの進化による変化もあり、発見やハマりが多々ありました。 Go 言語公式のロゴもスピード感ありますね。 同じような迷い・回り道をしてしまう方ももしかしたらおられるのではないかと思いますゆえ、 エムスリー Advent Calendar 2020 6 日目の記事として、筆者が実際に「最初から知っていれば時間を無駄にしなかったのに...！」と感じた知見をざっくばらんにシェアいたします。 本記事がどなたかの一助になりますと幸いです。 なお本記事の内容は筆者個人の理解・自身で直接読み書きしたユースケースの範囲での知見であり、全ての Go 利用事例に当てはまらない点も含みうりま
はじめに [ $? -eq 0 ] や [ $? -ne 0 ] は冗長でデメリットしかありません。非常に多く見かける書き方ですが、1979 年に Bourne シェルが広く公開された時からこのようなコードは必要ありませんでした。実際に当時はこのような書き方は使われておらず、このような書き方をしなければならなかった歴史的な経緯などはありません。これはなぜか広まってしまった良くない書き方です。 優れたコードとは無駄がないシンプルなコードです。丁寧なコードとは無駄な処理を書くことではありません。[ $? -eq 0 ] や [ $? -ne 0 ] は書かないほうが、簡単で読みやすくわかりやすくなります。優れた文法を持つシェルは短いコードで正しく動作し、良い書き方は最短の時間と最小の手間で目的を達成することができます。コマンドのエラー処理を簡潔に書くことができるのが、シェル言語の優れている点の
![いい加減シェルスクリプトで [ $? -eq 0 ] や [ $? -ne 0 ] なんて エラー処理を書くのはやめよう！ - Qiita](/image.pl?url=https%3a%2f%2fcdn-ak-scissors.b.st-hatena.com%2fimage%2fsquare%2f43a2a7b8ee94b5659b6dd6d14aeb6f02c2c6bd86%2fheight%3d288%3bversion%3d1%3bwidth%3d512%2fhttps%253A%252F%252Fqiita-user-contents.imgix.net%252Fhttps%25253A%25252F%25252Fqiita-user-contents.imgix.net%25252Fhttps%2525253A%2525252F%2525252Fcdn.qiita.com%2525252Fassets%2525252Fpublic%2525252Farticle-ogp-background-afbab5eb44e0b055cce1258705637a91.png%25253Fixlib%25253Drb-4.0.0%252526w%25253D1200%252526blend64%25253DaHR0cHM6Ly9xaWl0YS11c2VyLXByb2ZpbGUtaW1hZ2VzLmltZ2l4Lm5ldC9odHRwcyUzQSUyRiUyRnFpaXRhLWltYWdlLXN0b3JlLnMzLmFtYXpvbmF3cy5jb20lMkYwJTJGNTQ5MTglMkZwcm9maWxlLWltYWdlcyUyRjE0NzM2OTM1Mjg_aXhsaWI9cmItNC4wLjAmYXI9MSUzQTEmZml0PWNyb3AmbWFzaz1lbGxpcHNlJmZtPXBuZzMyJnM9YjQzZjY0ZGMzZWVjY2UyZTY1MGQ4NTRlNzk3ZDI2NGQ%252526blend-x%25253D120%252526blend-y%25253D467%252526blend-w%25253D82%252526blend-h%25253D82%252526blend-mode%25253Dnormal%252526s%25253D8fcfde890a56b8fea74f53d87eeef4e6%253Fixlib%253Drb-4.0.0%2526w%253D1200%2526fm%253Djpg%2526mark64%253DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk2MCZoPTMyNCZ0eHQ9JUUzJTgxJTg0JUUzJTgxJTg0JUU1JThBJUEwJUU2JUI4JTlCJUUzJTgyJUI3JUUzJTgyJUE3JUUzJTgzJUFCJUUzJTgyJUI5JUUzJTgyJUFGJUUzJTgzJUFBJUUzJTgzJTk3JUUzJTgzJTg4JUUzJTgxJUE3JTIwJTVCJTIwJTI0JTNGJTIwLWVxJTIwMCUyMCU1RCUyMCVFMyU4MiU4NCUyMCU1QiUyMCUyNCUzRiUyMC1uZSUyMDAlMjAlNUQlMjAlRTMlODElQUElRTMlODIlOTMlRTMlODElQTYlMjAlRTMlODIlQTglRTMlODMlQTklRTMlODMlQkMlRTUlODclQTYlRTclOTAlODYlRTMlODIlOTIlRTYlOUIlQjglRTMlODElOEYlRTMlODElQUUlRTMlODElQUYlRTMlODIlODQlRTMlODIlODElRTMlODIlODglRTMlODElODYlRUYlQkMlODEmdHh0LWFsaWduPWxlZnQlMkN0b3AmdHh0LWNvbG9yPSUyMzFFMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZ0eHQtcGFkPTAmcz1jZDg3NWQ1NmUzYzAzYjJiYzA2NDJlODRkZjlhOGQ4ZQ%2526mark-x%253D120%2526mark-y%253D112%2526blend64%253DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTgzOCZoPTU4JnR4dD0lNDBrbzFua3NtJnR4dC1jb2xvcj0lMjMxRTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LXBhZD0wJnM9ODVlMzIyOWJiNjA2ZTE4YzM2ZmM0MzNjMTk0ZjJkMmI%2526blend-x%253D242%2526blend-y%253D480%2526blend-w%253D838%2526blend-h%253D46%2526blend-fit%253Dcrop%2526blend-crop%253Dleft%25252Cbottom%2526blend-mode%253Dnormal%2526s%253D37916b2f47181baacefc69b1cacc89e8&f=jpg&w=240)
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに この記事では、メインフレームでは異常時の処理でどのようなことをやっているのか、また、Linuxの異常処理との違いなどについて話してみようと思います。 この記事を書くに至った直接的なきっかけは、とある人からリクエストがあったからです。が、日ごろからメインフレームの異常処理の考え方については、PCサーバーやクラウドによるシステムがメジャーになった現代であっても、参考になることは多いと感じていてはいました。 筆者は今でこそLinux Kernel周りの仕事をしていますが、20年ぐらい前のころはメインフレームのOS開発部隊に配属されて
高速逆平方根とは？ C言語のコード 検証 アルゴリズムの要点 [1] 逆平方根の計算を対数・指数の計算に置き換える [2] 浮動小数点型の内部表現を利用した対数・指数の近似計算 [2.1] 対数の近似 [2.2] σの最適値 [2.3] 整数型での解釈 [2.4] 逆平方根の計算とマジックナンバー0x5F3759DF [3] ニュートン法による収束で精度アップ 感想 高速逆平方根とは？ 高速逆平方根(fast inverse square root)とは、平方根の逆数 を高速に計算するアルゴリズムです。平方根の逆数は逆平方根とも呼ばれます。逆平方根はベクトルの正規化などに用いられるので、これを高速に計算できるアルゴリズムには大きなご利益があります。 参照： Fast inverse square root - Wikipedia C言語のコード 高速逆平方根の関数を示します。0x5F375
はじめに この記事は実際の業務で発生した MySQL のデッドロックとそのいくつかの回避方法や対応方法を（テーマは変えて）手元で実行できるコードを用いて解説する記事です。具体的には「トランザクション張っておけば大丈夫」と思ってませんか？ バグの温床になる、よくある実装パターンの記事で紹介されている「1on1 チャットサービス」で紹介されているデッドロックとデータベースレイヤでは同じ状況だったのですが、記事で紹介されている方法とは別の方法でデッドロックを回避する必要があったため、同じ状況に遭遇した人の助けになればという思いで記事を書きました。また、こちらの記事が無ければ私自身も現象を理解するのにもっと苦労したと思うので、この場を借りてお礼申し上げます！ 出金サービス履歴登録サービスを例に考える コードと説明が https://github.com/shuntagami/withdrawal_
こんにちは、テックリードの夏です。 今年4月にCTOからテックリードに肩書が変わり、ガリガリコードを書くようになりました。 背景については、こちらをご覧ください。 www.wantedly.com 普段はプロダクト側の機能開発と、サーバ側の基盤開発を半々ぐらいの割合で仕事しています。 一口にサーバ側の基盤開発といっても定義が曖昧なのですが、基本的にはこんな感じのタスクをやっています。 インフラコストの最適化 不正なアクセスからの防御 障害の再発防止 新技術の導入やアーキテクチャの整備 今回はこのうち「新技術の導入やアーキテクチャの整備」の中で、サーバサイドをGo + Clean Architectureで再設計したことについてお話したいと思います。 背景 ミラティブは2015年春頃に開発が始まり、同年8月にサービスがリリースされ、2020年8月で5周年を迎えました。 その過程で組織やプロダ
はじめに 最近、若手のコードレビューをしていて例外の使い方を教える機会があったので、ブログの方にもまとめたいと思います。今回はバッチ編。オンラインだとまた少し違う観点があると思います。また、言語はJavaを前提していますが考え方は例外機構をもつ言語ならあまり変わりません。 TL;DR 例外は原則キャッチしない。バッチは速やかに殺せ 個別箇所でログを出さずに必要な業務情報はExceptionを入れ子にして乗せる 長いバッチのためにはスキップもやむなし 原則、例外はキャッチしない JavaにはErrorとExceptionが存在し、OutOfMemoryErrorとかプログラム上ではどうしようもないものがエラー、ファイルが存在しない(FileNotFoundException)とかプログラム側でハンドリングするもの、と教科書では習うと思います。なのでException系はキャッチするものと、と
ReactのConcurrent Modeが最初に発表されたのはもう1年近くも前のことです（記事執筆時点1）。Concurrent Modeはたいへん奥深い機能で正式版がたいへん待ち遠しいですが、Concurrent Modeの代名詞として多くのReactユーザーに知られているのはPromiseをthrowするというAPIデザインです。Concurrent Modeでは、コンポーネントがレンダリング時にPromiseをthrowすることで、レンダリングをサスペンドした（Promiseが解決されるまでレンダリングできない）ことを表します。 Concurrent Modeに関しては筆者の既存記事Concurrent Mode時代のReact設計論 (1) Concurrent Modeにおける非同期処理などをご参照いただきたいのですが、ここではPromiseをthrowするということ自体に焦点
class: center, middle # 明日から使える<br/><strong>実践</strong><br/>エラーハンドリング Scala関西Summit 2018 11/10 --- class: left, middle ## 自己紹介 * 中村 学(Nakamura Manabu) * [@gakuzzzz](https://twitter.com/gakuzzzz) * Tech to Value 代表取締役 * Opt Technologies 技術顧問 <img src="../images/opt_logo_1.jpg" alt="Opt Technologies" width="450" style="margin-left: 0px" /> * F-CODE CTO <img src="../images/f-code_logo.png" alt="f-cod
はじめに このページは、プロトアウトスタジオのAPIにつなげる授業に関連して、よりAPIの多様さ、広がりを深掘りします。 まだ、JavaScriptに慣れていなくても「なるべくシンプルにAPIを体験する」ことを目指して、 public-apis というフリーで使えるAPIを集めてリストにしているサイトから、手順が少なくAPIにつなげられるシンプルに取得できるものを中心に、直接取得できるURL・Node.js axios await/async ソースコードを一つ一つトライしています。 慣れてきたら、自分で public-apis のサイトを直接読んでみて、巡ってみましょう！ APIピックアップ数 最終更新日 2020/6/8 104 個のAPIをピックアップ中！ 参考資料 public-apis の豊富なAPIリストをベースにAPIつなげていきます。 ピックアップルール 手順が少なくAPI
こんにちは。決済チームでエンジニアとして働いている芦川です。 UPSIDER Tech blog 第2弾として「決済チームがテストコードを書く際に気をつけていること」を紹介しようと思います。 TL;DR 100％のテストカバレッジを目指す テストはブラックボックスを優先して記述、どうしても到達できない場合はホワイトボックス 最初のテストケースは、テスト対象が動作する最も一般的なケースであるべき 私たちは日々大量のコードを書いており、そのシチュエーションは多岐にわたります。 そういった環境において、動作確認からのコード改修のコストを考えた場合、自動テストの有無によって生産性に大きく差が出ることは容易に想像ができます。また、既存のサービスに改修を加えるために、そのサービスの概要を把握したい場合、良いテストコードはドキュメントとして役立ちます。 以前、私はテストコードを一切書かないプロダクトの開
2023 年度の僕のエラーハンドリング について書きたい。 昨日Safe Data Fetching in Modern JavaScriptを読んでいて、fetch に限った話ではないが一家言ある内容だったので書きたくなった。 おそらくやりすぎだとか非効率と言われる点はあると思うので、みんなの一家言も教えて欲しい。 対象は Typescript での サーバー開発想定だが、TS であればクライアント開発にもほとんどに当てはまる話だと思う。 例外のスローではなく Result 型を使う Result は失敗するかもしれないという文脈を与えてくれる型 エラーハンドリングの戦略として例外を投げるのではなく、Result 型を返すやり方がある。 Result 型というのは export type Result<T, E> = Ok<T> | Err<E>; export interface Ok
JavaScriptの仕様であるECMAScriptはEcma Internationalによって定められています。ECMAScript 2015（ES6）の登場以降は、ECMAScript 2016、ECMAScript 2017･･･と、年次で仕様が更新されています。ECMAScript 2022（ES2022）は2022年6月22日のEcma InternationalのGA 123rd meetingにて、ECMAScript 2023（ES2023）は2023年6月27日のGA 125th meetingで承認されました。 ES2022とES2023はすでに多くのブラウザやNode.js環境で利用可能です。本記事では新仕様と使いどころを紹介します。 ES2023 - 配列の非破壊操作 ES2023では配列を非破壊で操作できるメソッドが追加されています。非破壊とは、元の配列を変更せ
はじめに 最近書いてるソフトウェア設計シリーズです。今回は例外に関して。以前、以下のような記事を書いたのですが、もう少し深堀して書いてみました。 ちなみにソフトウェア設計シリーズは他には以下を書いています。 モジュールになぜ分けるのか？ モジュール、依存、そしてカプセル化 モジュールをどう分割するのか？ 簡潔さは力なり？ 予測可能な振る舞いと簡潔さについて ドキュメントとしてのコメント TL;DR 例外は「原則」キャッチしない 業務例外や必ずハンドリングさせたい例外はOptionalなど戻り値の方が便利 だいたい以下の図が言いたい事のすべて 例外処理とは？ 「例外処理(Exception Handling)」は言語に依らず普遍的な関心事です。端的に言えば例外処理は異常やシステムの動作に不備が発生した際の特別な分岐処理です。リカバリやリソースの解放、あるいはユーザへの通知などがありますね。
この記事について SWR について色々と学んだので、その知見をここで共有したいと思います 💪 ※ 基本的に以下の公式サイトの情報を参考にしています 📖 そのため、この記事で出すサンプルコードなどは主に上記の公式サイトから引用させてもらっています。予めご了承ください 🙏 SWR とは何か？ SWR は、Next.js を作っているVercel 社が開発しているデータフェッチのための React Hooks ライブラリです。"SWR"と言う名前は、 stale-while-revalidate の頭文字をとって名付けられています。そのため、SWR はstale-while-revalidateに基づいた処理と設計になっています。 stale-while-revalidateについて解説したい所ですが、解説するとすごく長くなってしまうため、ここでは「 キャッシュをなるべく最新に保つ機能 」
みなさんTypeScriptでサーバアプリケーション（Node.js）のロジックを書く時に、異常系の表現をどのようにされていますでしょうか？ここでいう異常系とは、仕様上想定される異常のことです。準正常系と言ったりもするかと思います。 私はJavaScriptの延長でTypeScriptをはじめたので、最初は null や undefined を返したり throw を用いるやり方をしていましたが、次第にTypeScriptが持つ型を生かし、できるだけ型安全に異常系を表現したいと考えるようになりました。そして試行錯誤した結果、いい感じの落とし所に落ち着いたので、その内容についてお伝えしたいと思います。 また記事の後半では、異常系の型を実装する中でハマった点についてもお伝えしたいと思います。 TypeScriptの異常系表現について 1. nullやundefinedを返す 冒頭でも述べたよう
今回はPythonで簡単にリトライ処理を追加できる「tenacity」を使ってみます。 デコレータ形式で簡単にリトライ処理を追加できるので便利です。 tenacityについて プログラムを書いていて、HTTPの通信などでリトライ処理を実装する機会は多いと思います。 今回はそんなリトライ処理を簡潔に書けるtenacityの使い方を説明します。 インストール インストールはpipで可能です。 pip install tenacity 使い方 シンプルな例 import random from tenacity import retry @retry def random_error(): num = random.randint(0, 10) if num > 4: print(f"Error: num={num}") raise Exception("Error!") else: retur
TypeScript/JavaScriptの言語思想的にはtry/catchを使ってerror handlingをするのが普通
こんにちは。 株式会社ラクスで先行技術検証をしたり、ビジネス部門向けに技術情報を提供する取り組みを行っている「技術推進課」という部署に所属している鈴木（@moomooya）です。 ラクスの開発部ではこれまで社内で利用していなかった技術要素を自社の開発に適合するか検証し、ビジネス要求に対して迅速に応えられるようにそなえる 「技術推進プロジェクト」というプロジェクトがあります。 このプロジェクトで「WEBアプリケーションのDockerコンテナ移行」にまつわる検証を進めているので、その中間報告を共有しようかと思います。 本検証での想定環境 CIに不必要な部分は後回し 既存アプリでコンテナ化の障害になった部分 OSコマンドを利用している ミドルウェアとの密結合 オンライン系とバッチ系の密結合 ひとまず目指す状態 プロセス相乗りの影響 ログが複数出力される まとめ 続きの記事も書きました。 tech
M 年前にも N 年後にも人類は同じ話をしている. まとめ エラーの発生方法は throw と return に大別できる throw には簡潔さ, return には明瞭さと型安全性といった特徴がある どちらの方法がより適しているかはプログラムの規模, エラーの種類, ハンドリングの方法などが判断の材料になる 実際にどちらの方法を使うかは上の判断材料と, フレームワークやプロジェクトのコーディング規約なども合わせて複合的に決めるのがよい エラー発生方法の分類 まず前提として, 関数から呼び出し元にエラーを伝える方法は以下の 2 つに大別できます. 逆にこの記事ではこれ以上の具体的な方法についての議論はしません. throw エラーを throw して呼び出し元に伝える方法です. 例えば以下のようなものが当てはまります. throw new Error("...") Promise.rej
TypeScript の型システムを活用して、本番のアプリケーションにおける実用的な問題を解決することを目指しています。Effect-TS は、以下のような特徴を備えています。 並行性（concurrency）：Fiber ベースの並行モデルにより、高いスケーラビリティと低レイテンシを実現 コンポーザビリティ（composability）：小さく再利用可能なパーツを組み合わせることで、メンテナンス性、可読性、柔軟性の高いソフトウェアを構築する リソースの安全な管理（resource-safety）：処理が失敗したとしても、安全にリソースを開放する 型安全性（type-safety）：TypeScript の型システムを活用した型推論と型安全性に焦点を当てている エラー処理（error handling）：構造化された信頼性の高い方法でエラーを処理する 非同期性（asynchronicity
This article explores Go error handling. Earthly is popular with Go developers for ensuring reproducible builds. Check it out. Error handling in Go is a little different than other mainstream programming languages like Java, JavaScript, or Python. Go’s built-in errors don’t contain stack traces, nor do they support conventional try/catch methods to handle them. Instead, errors in Go are just value
こんにちは、21 卒エンジニアの id:d-kimuson です。 モバイルファクトリーでは、最近のプロダクトではフロントエンドに TypeScript を採用していますが、僕がアサインされているプロダクトは歴史が長く JavaScript で書かれていて、今回 TypeScript へのリプレースを行いました。 既存プロダクトの TS リプレースではしっかり型付けすることは難しいので、型チェックオプションを緩くしてリプレースすることが多いと思います。しかし、既存コードからリプレース後のコードまで全て型安全性が担保できなくなってしまうので、後からの strict 化は非常に大変になってしまいます。 今回のリプレースでは、型チェックオプションは緩くしない代わりに @ts-nocheck や @ts-expect-error を使用することで、段階的に型安全性を高めやすい形でリプレースを行いま
Twitterでこんな記事を見かけたので。 zenn.dev ジェネリクスの件もそうですが、Goの言語設計は現実主義なのになにか特別なポリシーによるものだと宗教化されてしまって、ファンには勝手に崇拝されてアンチにはディスられがちだなーと感じます。 Goのエラー処理を改善する実験プロジェクトxerrorsがGo本体のerrorsにマージされた時、 errors.New() はスタックトレースを取得していました。しかしGo 1.13がリリースされる前に削除されました。 削除された理由の1つは、今までの errors.New() のパフォーマンスに依存していたコードの速度が低下しアロケーションが増えることです。 github.com しかし、これが理由だと今まで思ってたのですが、実際にはもう1つより重要な理由がありました。エラーのフォーマットです。エラーに複数のフォーマットを持たせようという提案
概要 タイトルの通り、他言語から入門した人が最低限気にするべき、ネーミングルールをまとめました。 対象読者 Goの基本構文を理解している人を対象読者としています。 この記事で説明すること、説明しないこと 説明すること Goのファイル名、変数名などの名前付けに関するルールや慣例などを説明します。 説明しないこと 名前付け以外で気をつけるべきGoの書き方[1] がいくつかあります。 しかし、それらに関してはこの記事では説明しません。 筆者のバックグラウンド プログラマ歴はもうすぐ8年程で、Goの他には以下のような言語の経験があります。 JavaScript TypeScript PHP Ruby Java Scala Goは少し前に書いて、一時期書かない時期が続いていましたが、最近また書いています。 トータルするとGoの経験は1年半程度です。 意識すべき名前付けルール package名 利用し
Google、訂正不可能なメモリエラーによるクラッシュを回避する「Memory Poisoning Recovery」をGoogle Cloudで提供へ ずっと安定して稼働していたシステムが、ある日突然エラーでクラッシュ。調べても原因が分からないので、「何らかのノイズや放射線などの影響でメモリエラーが起きたのでは？」という推測を顧客に報告した、なんて経験を持つベテランのITエンジニアは少なくないのではないでしょうか。 実際のところ、2009年のGoogleの調査では同社の本番システムにおいて、1年間で8％以上のDIMMモジュールにメモリエラーが発生していたと報告されています。想像以上にメモリエラーというのは起きているのですね。 ただし、現代のメモリとCPUなどではエラー訂正機能を備えているため、多くのメモリエラーは訂正され、システムの動作に影響を与えないようになっています。 しかし訂正しき
TL;DR エラーハンドリングを行う目的 エラーハンドリングが適切に行われているとどう嬉しいか 1. エラーの発生原因が分かる 2. レスポンスステータスを型安全に出し分けることが可能になる どうエラーハンドリングを行うのか 実装方法 エラー型の定義で気を付けるべきポイント なぜanyhowを利用しないのか エラーハンドリングを行う上で持っている課題感 Drawer Growth グループ バックエンドエンジニアの中野です。今回は、私が所属するチームで gRPC API を開発する際に実践している Rust でのエラーハンドリングについて紹介していきます。 TL;DR エラーの発生原因がわかるようにエラー型を定義することが大切。 anyhow は使わずに自前のエラー型を定義して利用する。 エラーハンドリングを行う目的 そもそもなぜエラーハンドリングを行う必要があるのでしょうか。私が所属する
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
