だいたいの試験項目書は Excel で作られている事が多いと思いますが、試験手順の修正や項目追加などでちょいちょい変更することがあって、バージョン管理していると衝突したり差分がわからなくなったりしがちだったりしませんか？ そんな現状をなんとかすべく、試験仕様書を Markdown で書くという試みをしてみました。(一応、実プロジェクトでも運用済み) Github のプロジェクトとして公開しています。 以前 Java で書いてたのですが、今だと Kotlin の方が管理しやすそうだったので Kotlin で書き直しました。Kotlinは本当に書いてて気持ち良い言語。 使い方 Github の README にも書いてますが、ここでは日本語で説明書きます。 1. 試験仕様書の Markdown を書く 下記のような Markdown を作成します。 # 試験カテゴリ ## 大項目サンプル ##
こんにちは、バックエンドエンジニアのじょーです。 以前、月額課金型のサーバーサイドでのレシート検証の記事を書きました。(iOSの月額課金レシート検証をサーバーサイドで行うときのTipsまとめ) 今回は、消耗型課金のサーバーサイド実装について書きます！ 注意 この情報は2017年8月25日現在のものです。 目次 消耗型課金全体の処理フロー レシート検証について 課金アイテムの扱い方について 消耗型課金全体の処理フロー 消耗型課金とは、AppStoreで登録できる使い切りのアイテムへの課金のことをいいます。 たとえば、ゲームアプリでライフを購入するときなどは使い切りのアイテムなので消耗型課金になります。一方、1か月など決まった期間サービスが受けられる課金のことを月額課金や、自動更新購読といったりします。 (実際のアイテム登録画面) アプリで消耗型課金商品を購入してからの処理の順番は、下記の図の
今年GitHubがGraphQL APIを正式公開したあたりから、GraphQLが去年とかに比べちょっと流行り始めたように感じる。idobataがGraphQL APIを公開したり、Kibelaも公開APIをGraphQLで作ることを宣言している。 利用者側からすると使えるインターフェースの中から必要なものを調べて使うだけなのであまり考えることはないのだが、自分がAPIを提供する立場になると話は変わってくる。REST APIとGraphQL APIはどちらかがもう一方のスーパーセットという風にはなっておらず、どちらかを選択すると何かを捨てることになるので、要件に応じてどちらを選ぶのが総合的に幸せなのか考える必要がある。 以前趣味でGitHub連携のあるサービスを作っており、それを最近GraphQL API v4を使うように移行し、そこでついでにそのサービスのGraphQL APIを書いてみ
目次 はじめに 自己紹介(2017年夏時点) インターンの内容 前半過程 すべてが繋がっていた Perlは良い言語です 学び方を学ぶ重要性 後半過程 最高のチームでした チームのスピード感 コミュニケーション プレゼンの重要性 自分のレベルが少し分かった 最終日に学んだこと おわりに 余談たち 関モバ ホテル オフィスランチ 晩ごはん 飲み物とお菓子 傘 あわせて読みたい はじめに 「はてなサマーインターン2017」の「ブックマークアプリコース」に参加してきました。 はてなインターンのいいところの1つに「体験談が豊富」というところがあるので、僕も学んだことをまとめたいと思います。 あ、応募するのを悩んでいる方がこれを見ているのなら、さっさと応募してからこのエントリーを読みましょう😃❗ 自己紹介(2017年夏時点) 大阪出身 22歳 東京大学 工学部 電気電子工学科 3年 明石高専 電気情
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
