はじめに APIの仕様をSwagger/OpenAPIで書くケースは増えてきました。これはAPI提供側と利用側の取り決めなので、これさえしっかり書いてメンテしていけば、独立して開発できるようになります。 というのはいささか理想が過ぎるようにも思えます。というのもSwagger/OpenAPIでは仕様、特にやりとりするJSONのデータの仕様を書ききるのは難しいためです。一応型としてきっちり定義できるように、スキーマ定義の部分は仕様が膨らんできていますが、その延長線上にはそれこそメンテ不可能な、過去人類が通ったスペックモンスターの規格を生み出してしまわれそうです。 もう少し上手いやり方は無いものでしょうか? そこでJSON Specというものを作ってみました。どんなAPIでもサーバサイドでは、受け取るパラメータやJSONのバリデーションはしっかり書くはずです。これを利用して、APIのテストにも

κeenです。最近、Rustのタプルに「tuple[0] じゃなくて tuple.0 のようにアクセスするのなんでだろ」というのをみかけてびっくりしたのでそれについて。 TL;DR: タプルは構造体の一種。ユニット型は0要素タプル。 Rustのタプルの要素へのアクセスは tuple.0 のようにアクセスしたい要素の番号をドットで繋げるような記法で書きます。構造体のフィールドアクセスと似ていますね。 これについて、私のようにML系言語のバックグラウンドがある人は当たり前のように感じるでしょう。 しかし別の言語のバックグラウンド(PythonとかDとかがそうらしい？)を持つ人には驚かれるようです。 また、特段バックグラウンドがなくてもドキュメントで配列と比較するような書き方がされているのでそこからも疑問が湧くようです。 タプルとレコード Rustだと分かりづらいのでRustが参考にしたというM

(or for any other name) The web is moving to HTTPS, preventing network attackers from observing or injecting page contents. But HTTPS needs TLS certificates, and while deployment is increasingly a solved issue thanks to the ACME protocol and Let’s Encrypt, development still mostly ends up happening over HTTP because no one can get an universally valid certificate for localhost. This is a problem b

発注者と開発者の認識の齟齬により要求と実現されるソフトとの間に「ギャップ」が生じます。具体的には、次の（1）～（3）のようなギャップが生じます。 要件定義すべき内容が抜けており、開発者に説明していない。 発注者が開発者に説明したが、何らかの理由で漏れた。 開発者が何らかの理由により誤認・拡大解釈し、実現範囲に取り込んでしまった。 機能要件に着目し、上流工程で実現したい情報システム像を伝え、発注者と開発者との不充分な合意形成が原因で発生する下流工程の手戻りを防止するための次のようなコツを集めたものです。 実現したい情報システム像について発注者と開発者が合意形成するために、伝える側が漏れなく正確に情報を提供するためのコツ 発注者と開発者との不充分な合意形成が原因で下流工程で発生する手戻りを防止するための先人の開発者のコツ 機能要件の合意形成ガイドは、「概要編」 と次の6つの技術領域のコツをまと

本記事の内容は、ある程度書いていたり色々記事を読んでいると自然と身についていく類のものですが、初めから色々知っていると捗るのと、すでに慣れている場合でも少しは新しい発見があるかもしれません。 また、Flutterの効率良い学び方 にも書いた通り、自分でFlutterコードを書く分にはAndroid Studioの方が捗ると感じているためそれに沿った説明になっていますが、VS Codeでも大体通ずる内容です。また、キーボードショートカットはmacOSでのデフォルトとなっているので、環境が違う場合は随時読み替えてください。 [追記 2019/03/03] 最近はVS Codeに絞るのも良いかなと思ってきています(→ 2022年2月からVS Codeに乗り換えました)

2019年初に2018年のDartを振り返ってみる。僭越ながらDart advent calendar 25日目の記事だが、大幅に超過して新年になってしまった。申し訳ない。そして大した内容ではない。個人の回顧です。 Dart 2のリリースと、Dart 1の回顧 Dart 1を回顧するに、以下の特徴をもった言語だったと思う。 VMを活かした動的言語であること VM前提の動的言語の表現力、進化を妨げないための、選択換装可能な型システム (言語が型システムに依存するのではなく、型システムが言語に依存する) エディタ、デバッガ（等々）が統合された開発体験などの、Smalltalkを目標とした環境の提供（が目標） ライブラリや開発環境などを整備し、言語のカタログスペックでなく実際のDeveloper Experienceが優れていること 世の中の圧倒的多数を占めるCとJavaのプログラマーに学習コス

CryptoSummerからCryptoWinterへ このところ、”CryptoWinter（暗号資産の冬）”という言葉がささやかれている。それは、ビットコインをはじめとした暗号資産の価格の単純な下落というだけでなく、この領域に参加している多くの人が薄々感じていたバブルが弾けて、ビジネスの対象としての「冬」を感じているからだろう。 2017年の秋から暗号資産の価格は高騰した。Coindeskによると、ビットコインのドルへの交換レートが一番高かったのは、1BTC=17394.97USD（2017年12月11日）。2018年元日の交換レートは1BTC=15,317.38USDだったが、それが12月25日現在では3740.17USDである。年初から見ても4分の1程度となっている。 ガートナー社が発表しているハイプ・サイクル（hype cycle、ハイプ曲線：図１参照）は、ある意味わかりやすい仮

Clean Architecture in Clojure is a joy. — Uncle Bob Martin (@unclebobmartin) 2016年6月26日 と言うことで、Clojure で Clean Architecture を意識した簡単な TODO アプリを作成してみたいと思います。 最終的なソースはこちら Clean Architecture とは？ 他のアーキテクチャ1と同様、関心事の分離を目的としたアーキテクチャです。クリーンアーキテクチャでよく見かける以下の図は、この関心事の分離を実現するために外側から内側へ依存性のルールを持っていることを表しています。４つの同心円に目が行きがちですが、４つの同心円に特に縛りはなく、必要に応じで増減させて問題ありません。大事な点は、依存性のルールに従い、円の外側にあるフレームワークやDBといった詳細が、円の内側にあるビジネ

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事は、開発を持続可能にできるようなアーキテクチャとその適用方法を考察するものです。 骨子はできていますが、実装経験をフィードバックして詳細を若干変更するかもしれません。 勉強不足な点もあるので、意見を歓迎します。 開発においてよくある問題点 ビジネスロジックの本質が何だったか見失う。ソースコードのどこまでが業務上の関心で、どこからがそれを実現するための技術上の関心か分からなくなる。 入出力双方向の処理が散在して処理が追い切れなくなる。特にイベント処理でどこに飛ぶかわからないコールバック地獄になる。 初期化・つなぎ込み・統合者的オブ

この記事はFlutter Advent Calendar 2018の10日目の記事です。 まえおき Flutter 1.0のリリースがアナウンスされましたね、めでたい！！ さて、Flutter Liveで は紹介されていなかったようですが 1も紹介されていたようですが、Google Developers Blogのポストを見ていると、記事の中ほどに プラットフォーム ビュー 2という見出しとその説明があります。 今までAndroidでしか実現できていなかったのが、いよいよiOSでも使用できるようになった、ということのようです。 私がいま所属している会社的にはこの機能のおかげで大変救われました。 それはそうとして、この機能、どう実現されているのでしょうか？ 気になりませんか？　気になりますよね？　ね？ Platform View とは Platform View とは、FlutterのWid

Bringing mechanical ergonomic keyboards to the masses. Whether you want a full build, a kit, or just a case for your next project, we are here.

# 競技プログラマの名前で呼ばれるアルゴリズムたち [競技プログラミング Advent Calendar 2017](https://adventar.org/calendars/2221) Day

“Spider-Man leaning on concrete brick while reading book” by Raj Eiamworakul on Unsplash 数ヶ月間Flutterに関する大量のインプットを行い、単純なアプリならサクッと、複雑なアプリでも都度調べながらなら慣れているiOSネイティブアプリ開発と比べても遜色ないレベルのものを普通に作れるであろう自信が出てきました。本記事では、自身の過去の取り組みを踏まえてFlutterを学ぶにはこういう道筋が良いだろうということを書いていきます。 まずはとにかく公式ドキュメント