RustでAPIを開発してみたら結構辛かった話
はじめに 皆様こんにちは、株式会社プラハのAwataです。 今日は、以前書いたリーダーの振り返り記事で軽く触れていた、RustでのAPI開発についての記事を書いていこうと思います。 結論RustでWebは辛い！という話なんですが、約5か月くらいRustでWeb開発をしたので、今後の参考になるようなことを書いていこうと思います。 ぜひ最後までお付き合いください。 TL;DR RustでWeb開発はまだ早いかもしれない。 RustでDDDはやりやすい。ただしDIがやりにくい場合があるので、そこは要注意。 Rustはモジュールの仕組みが協力なので、モジュラモノリスはやりやすい。 サンプルリポジトリはこちら Rustはやっぱり難しいけど人気の理由も少し分かった気がする そもそもなぜRustでやってみようとなったのか 前例が少ない中、どうしてRustで開発しようと思ったのか気になる方も多いと思います
リーダブルテストコード / #vstat
「リーダブルなテストコードについて考えよう ～VeriServe Test Automation Talk No.3～」で使用したスライドです。 https://veriserve-event.connpass.com/event/243280/ 登壇動画はこちらで公開されています。 https://vimeo.com/742517199/e001ac43ac ＜参考リンク＞ Twitter https://twitter.com/jnchito Blog https://blog.jnito.com/ Qiita https://qiita.com/jnchito プロを目指す人のためのRuby入門［改訂2版］ https://gihyo.jp/book/2021/978-4-297-12437-3 Everyday Rails - RSpecによるRailsテスト入門 https://
伸ばすのが難しい能力: 柴田 芳樹 (Yoshiki Shibata)
2018年6月1日に株式会社メルペイに入社して、4年が過ぎました。入社当時は、定年が60歳と聞いていたので、1年半の勤務だと思っていましたが、実際の定年は65歳であり定年まであと2年半です。 ソフトウェアエンジニアにとって重要な能力と（私は考えるが）、身に付けるのが難しいのが現実だと、この4年間で再認識したのは次の三つです。 開発の最初にAPI仕様をきちんと書けるソフトウェアエンジニアは少ない テストファースト開発を行っているソフトウェアエンジニアは少ないか、いない Tech Blogなどの執筆で、読み手を意識して、分かりやすい文章を書く、ソフトウェアエンジニアは少ない API仕様については、このブログでも何度か書いています（「API仕様を書く」）。テストファースト開発についても、「テストファースト開発」を書いています。分かりやすい文章については何も書いていないですが、「伝わる技術文書の書
モックは必要悪で、しないにこしたことはない - blog.8-p.info
Mockito や gomock が使いやすいせいか、単体テストというのはモックするものである、という思い込みがあるのか、人々がモックしすぎているのを時折みかける。 モックは必要悪で、しないにこしたことはない。外部の API サーバーとかはガンガン叩くわけにもいかないけれど、ファイル読み書きくらいは、実際にファイルを作ったり消したりしてしまっていい。/etc/passwd を消すとか、1GB のファイルを作るとかだと難しいかもしれないけれど、その場合でも、パスのプレフィックスを指定できるようにして、一時ディレクトリの中の etc/passwd を使うとか、ファイルサイズを指定できるようにするとか、逃げ道はいくつもある。そこを飛ばして「ファイル操作は一律モックしましょう」とか頑張りだすと辛いことになりがちだ。 モックの一番の問題は、本番とテストで違うコードが走ることで、これは自動テストの価値
net/httpで作るGo APIサーバー #1
GoにはWebサービスを作るためのフレームワークがそれなりの数存在している。 Awesome Go - Web Frameworks ただ、そこまでデファクトというものがあるわけではなく、他の言語と比べると少々乱立気味なのではないかな、という感想を持っている。この記事ではnet/httpを主軸に据え、取替可能な部品となるライブラリを利用してAPIサーバーを作成する方法を紹介する。 長くなりそうなので記事を分けて紹介する予定だけど、今日はアプリケーショングローバルな値をどのように保持するのが良いのかについて書く。 アプリケーショングローバルな値 APIサーバーにはそのアプリケーションにおいてグローバルな値を保持しておきたいケースが多い。例えばAPIサーバーの設定情報だったり、外部APIにアクセスするクライアントだったり、DBへのコネクションだったり、loggerだったり。そういったものを初期
こんなに使える！今どきのAPIドキュメンテーションツール
Dapr × Kubernetes ではじめるポータブルなマイクロサービス（CloudNative Days Tokyo 2020講演資料）NTT DATA Technology & Innovation
どんなに実装がしょぼくても，テストは合ってるはずなので，将来的にいい方法が見つかったときに，テストはそのままに実装だけ美しく書き直すことができる． ■ - hitode909の日記
どう作ればいいか分からないとき，同僚に相談したりするけど，それでもいい方法がなければ，我々のスキルがしょぼすぎて，しょぼすぎるスキルではそういうものしか作れないのだからあきらめて作ろう，ということになる． それはそれでよくて，どんなに実装がしょぼくても，テストは合ってるはずなので，将来的にいい方法が見つかったときに，テストはそのままに実装だけ美しく書き直すことができる． そんな都合よく行くのか，という話だけど，意外とうまくいっていて，ここいけてないなーと思ってたところは半年もすればどう書けばよかったのか分かってきて，初めからそこにあったかのような美しいモデリングができる． 本番環境でプロトタイピングしてるようなものだけど，半年間プロトタイピングを重ねてついにリリースよりは，なんか動くものを今日リリースできるほうがいいし，最初にしょぼいコードを書いているのは，さぼってるわけではなく，技術力が
The history of testing framework in Ruby - Kouhei Sutou - Rabbit Slide Show
Description This talk describes about the history of testing framework in Ruby. Ruby 2.2 bundles two testing frameworks. They are minitest and test-unit. Do you know why two testing frameworks are bundled? Do you know that test-unit was bundled and then removed from Ruby distribution? If you can't answer these questions and you're interested in testing framework, this talk will help you. This talk
ESDoc - The Good Documentation For JavaScript - クックパッド開発者ブログ
こんにちは。会員事業部の丸山@h13i32maruです*1。 ソフトウェアのドキュメント(マニュアル)を書くには色々なツールや方法があります。 JavaScriptの場合はJSDocというドキュメンテーションツールがデファクトスタンダードです。 ですが、JavaScriptの最新仕様であるECMAScript2015(ES2015)がリリースされたことにより、 JSDocの競合として新しいツールが登場したり、JSDoc自体もバージョンアップしたりしています。 本記事ではそうした新しいツールの一つであるESDocを紹介します。 ESDocとは？ ESDocとは私が2015年4月から開発を行っている、JavaScript(ES2015)向けの良いドキュメントを作るためのドキュメンテーションツールです。 https://esdoc.org/ https://github.com/esdoc/es
Testing Swift's ErrorType: An Exploration
In this post, we explore the nature of Swift’s new error type, looking at the possibilities and restrictions for testing error handling implementations. We end with an illustrative example, and some helpful resources. How to Implement the ErrorType Protocol If we jump to the definition of the ErrorType protocol in the Swift standard library, we see that it doesn’t contain many obvious requirements
ESDocというJavaScript向けのAPIドキュメントツールを作りました - maru source
こんにちは丸山@h13i32maruです。 昨日、ESDocというツールをリリースしました。GW中になんとかリリースできて一息ついているところです。今回はそのESDocというツールについて紹介します。あと最後に雑談と宣伝があります。 ESDocとは？ ESDocとはJavaScript(ES6)向けのAPIドキュメントツールです。JavaScript界隈ではJSDocがデファクトスタンダードであり、ESDocもJSDocに触発されて作りました。なのでタグの使い方はなるべく互換性を持たせています。とはいえ不要だなと思うタグもかなりあったのでそれらは実装していません。 ESDocの特徴(主にJSDocに比べて)としてはこんな感じです。 詳細なドキュメントを生成する ドキュメントカバレッジを計測する テストコードとドキュメントを関連付ける ES6のclass, import/exportを使った
Xcode6で追加された、XCTestの新機能 - Qiita
2014年のWWDCでは、"Testing In Xcode 6"という講演で XCTestの変更点について、以下の通り説明されています。 * 互換性の向上 * 非同期テスト用APIの追加 * パフォーマンス評価用APIの追加 この記事では、非同期テスト用APIの追加・パフォーマンス評価用APIの追加について説明します。 非同期テスト用APIの追加 XCode6のXCTestでは、非同期テスト用のAPIが追加されました。 バックグラウンドで実行するような処理やネットワークのI/Oなど、非同期な振る舞いをテストするときに使えます。 書き方 非同期な処理を実行するときに、期待する処理が完了したタイミングでXCTestExpectationのfulfillを呼び出すよう実装します。 そのときにテストケース側ではwaitForExpectationsWithTimeout:を呼び出して、期待する処
Javadoc ドキュメンテーションコメントの書き方 - Qiita
出展: プログラム内のコメントの書き方 | 天才まくまくノート はじめに（モチベーション） こんな話があります。あるソフトウェア企業が一人の技術者の採用を決めました。その決め手となった理由は、「公開しているオープンソースソフトウェアのドキュメントが素晴らしかったから」です。彼らは、作成されたドキュメントを見ただけで、その人には技術力がある、一緒に働いて欲しいと判断したのです。 ある国の言語を学ぶために読み書きの練習が必要であるのと同様に、コーディング技術をつけるには、多くの良質なコードを読み、多くのコードを書くことが必要です。設計ドキュメントを書くのも同じことです。日頃から分かりやすいドキュメントを書く鍛錬を怠らず、長年の経験を積んでいかなければ、良質なドキュメントを書く力は身に付きません。今日からドキュメンテーションコメントをバリバリ書いて、ドキュメンテーション力を付けていきましょう。
Rubyのテスティングフレームワークの歴史（2014年版） - 2014-11-06 - ククログ
2014年12月にRuby 2.2がリリースされる予定です1。 Ruby 2.2にはRuby 1.9.1のときに外されたtest-unitというテスティングフレームワークが再びバンドルされる予定です。Rubyのテスティングフレームワーク周りに詳しくない人にはよくわからない状況でしょう。そこで、Rubyのテスティングフレームワークの歴史を説明することで状況を整理します。 名称の整理 この説明の中ではたくさんのテスティングフレームワークが登場します。似たようなものもあるため、最初にテスティングフレームワークの名称を整理します。この説明の中で登場する名称は次の通りです。 RubyUnit Lapidary rubyunit Test::Unit test/unit test-unit miniunit minitest RSpec 違いがわかりますか？ざっくり説明すると次の通りです。 RubyU
OHHTTPStubsを使ったiOSアプリ開発の進め方 - Qiita
概要 スタートアップiOS勉強会 #3 http://www.zusaar.com/event/4557003 自分もこれで話す内容についてずっと考えていて、laisoさんのスタートアップの人材戦略とは何かを読むと先にLTの内容を公開していたのでこちらも公開することにした。 10分以下のLTだと細かいことは多分話せないので、先におおまかに公開し実際のLTでは自分の特に話したいことを集中して話すようになるのではないかと思う（もしくはジョブズが成仏した話みたいに当日思いつきでぜんぜん違うことを言うかもしれないし、もしくは近所にガールズバーができたから行ってみたらビール一杯3080円だった話になるかもしれない）。 スタートアップに関する話について 経験上、iOSアプリ開発ではWebアプリ開発のようにいきなり大人数で開発を進めることがないので、iOSアプリ開発での技術的ノウハウやあるあるネタはスタ
QUnit
The powerful, easy-to-use JavaScript testing framework.Get Started View the Docs Easy Easy, zero configuration setup for any Node.js project and minimal configuration for Browser-based projects. Universal Tests can be run anywhere; Node, your browser, even inside a Web Worker. Test your code where it runs.
Ajax開発のテストツールとしてのPython : DSAS開発者の部屋
KLab Advent Calendar 2011 「DSAS for Social を支える技術」 の15日目です。 最近はソーシャルゲームの開発案件も増えてきました。Android/iOSアプリの開発をはじめとしたAjax通信の事例が数多くなり、開発スタイルも様変わりしつつあります。以前はWebサイト・Webアプリ構築の場合はPCや携帯のブラウザをリロードしながらだったのが、スマートフォンが加わりつつあります。 スマートフォンにおいてはさらにアプリ開発が大きな意味を持ちつつあります。携帯時代にもJavaアプリやBREWアプリなど多様なアプリがありましたが、スマートフォンアプリでの違いは、サーバとの通信を非常に多く行うようになったことです。クライアントアプリは多くの場合自前かもしくはWebViewを用い、通信はAjaxが使われます。リクエストもGETだけでなくPOSTを使う事も多くあり、
JavaScriptでのテストや開発についてのアウトプット - Block Rockin’ Codes
最近JavaScriptを個人的に勉強しているんですが、そんなJS初心者ながら色々試すなかで気が付いた開発とかTDDとかについて色々思うところをアウトプットしてみようかと思います。 一番多いのは、ClientSideJSで、使ってるのはjQueryとQunitが中心でした。 でもこれからは別のフレームワークや、ServerSideJSなんかも出てきますし、 今読んでる本が終わったら、こっちの本も見てみたいと思っているので、 Test-Driven JavaScript Development: Safari Books Online その前にこれを書いておこうという目的です。自分に付ける一つのTagという感じです。 あまり一貫性に拘らず、垂れ流したいと思います。 Ajax と API 以前こんな記事を書いたように、サーバ側がAPIでデータを提供し、ロジックをクライアント側に固めるタイプの開
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - AliSoftware/OHHTTPStubs: Stub your network requests easily! Test your apps with fake network data and custom response time, response code and headers!