文化祭入退場・混雑管理システム "CAPPUCCINO" 開発・運用記
この記事は、文化祭実行委員会に所属する[1]現高校 3 年生 3 人で文化祭の入退場混雑管理システム「CAPPUCCINO」を 2 年間に渡り開発し、実際に運用した記録を残したものです。 ＊この記事は以下の 3 名による共同執筆です 著者・開発者: すばる (@su8ru / Twitter:@su8ru_) 高校３年生。普段は TypeScript に使われながらウェブフロントエンド技術で遊んでいます。 たけ (@takeno_hito / Twitter:@Takeno_hito) こうこうさんねんせい。コーディングよりはゲームのほうが好きです。上下二人に揉まれながらも一応リーダーをやってました。 ふわわあ (@fuwa2003 / Twitter:@ibuki2003) 高3。Vimmer。半言い出しっぺなのに後半コード書いてないとかで最近は肩身が狭い思いをしています。 1. CAP
HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様
今日では HTTP(s) で API が公開されることは当たり前の時代ですが、エラーをアプリケーションにどう伝えるかは、個々の API の設計に依存していました。特に、HTTP ステータスコードは有限であり、元々持っている意味があるので、自由に使うことはできません。API はそのドメインごとにもっと複雑で細かなエラー情報があるはずで、それらはレスポンスボディに載せてアプリケーションに伝えることになりますが、その書式に規定は今までありませんでした。 HTTP API にて、アプリケーションにエラー情報を伝達するための（レスポンスボディに載せられる）標準的な形式が、RFC7807 Problem Details for HTTP APIs で定められています。適用例としては、以下のようになります。 HTTP/1.1 403 Forbidden Content-Type: application
大きな組織で情報共有するためのOSSつくってみた - Qiita
この記事は、Fujitsu Advent Calender 2016の6日目の記事です。 はじめに 仕事柄、沢山の人が関わるお仕事の効率化に関心があり、プライベートで研究や開発をしています。システム・インテグレーションをはじめ沢山の人が関わるお仕事は、人海戦術で行なわれる事がよくあります。しかし、経験上ITが関わるお仕事の人海戦術はおすすめできません。効率面、品質面、労務管理の面で問題が発生する事が多いからです。 人海戦術にならないようにするには、「人間的な仕事」と「機械的な作業」を切り分けて、機械的な作業をIT化するのが近道ではないかと考えています。 ITの現場における機械的な作業の例 情報を記録する（課題とか、バグとか、更新履歴とか） 情報を探索する（あの資料どこだっけ？とか） 情報を収集する（進捗どうですか？だめですか？とか） 情報を転記する（メールからエクセルとか） 情報を伝達する
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
