notes/A_recipe_for_a_functional_app/How to design and code a complete program.md at master · yukitos/notes
関数型アプリケーションのレシピ パート1 原文：How to design and code a complete program 「自分ではミクロレベルで関数型プログラミングが分かってきていて、小さなプログラムくらいは作成できるようになったんだけれど、どうしたら実際のデータを処理したり、現実的なエラー処理を実行するような完全なプログラムを作成できるようになるんだろう？」 これは非常によくある疑問です。 そこで私は以降の一連の記事において設計やバリデーション、エラー処理、一貫性、依存性の管理、コードの構成など、完全なプログラムを作成するために必要なレシピを解説していこうと思っています。 先にいくつかコメントしておきましょう。 この連載ではアプリケーション全体というよりは1つのユースケースに焦点を絞ります。 そうすればきっと必要に応じてコードを拡張できるはずです。 特別なトリックや高級なテク
The mindless tyranny of 'what if it changes?' as a software design principle - Blogomatano
"What if it changes?" isn't just a question. It's a powerful heuristic for software design that can be used to justify almost anything. Everyone should use it more. It's great precisely because it's rooted in pure speculation. Once you've freed yourself from the baggage of reality, there's nothing easier than inventing scenarios where your special code will be useful under the new imaginary future
Military time zone - Wikipedia
The military time zones are a standardized, uniform set of time zones for expressing time across different regions of the world, named after the NATO phonetic alphabet. The Zulu time zone (Z) is equivalent to Coordinated Universal Time (UTC) and is often referred to as the military time zone. The military time zone system ensures clear communication in a concise manner, and avoids confusion when c
ミリタリータイムゾーン - それはそれ、これはこれ
タイムゾーンというと、+0900 のように符号と四桁の数字か、UTC PST JST のような三文字の英字*1、Asia/Tokyo のようなzoneinfoのファイル名とかで表すが、米軍規格の一文字英字もある。UTC を一文字で Z で表すのはここから来ている。ちなみに JST は V だ。 現在でもちゃんとgnu-dateにその機能が残っている。 export TZ=UTC for T in A B C D E F G H I J K L M N O P Q R S T U V W X Y Z JST PST do date "+$T %Y-%m-%d %H:%M" -d "2010-01-01 00:00:00 $T" done 実行結果、つまり「各タイムゾーンの午前0時がUTCで何時になるか」は、 A 2010-01-01 01:00 B 2010-01-01 02:00 C 20
The Code Review Pyramid
When it comes to code reviews, it’s a common phenomenon that there is much focus and long-winded discussions around mundane aspects like code formatting and style, whereas important aspects (does the code change do what it is supposed to do, is it performant, is it backwards-compatible for existing clients, and many others) tend to get less attention. To raise awareness for the issue and providing
Goodbye, Clean Code — Overreacted
It was a late evening. My colleague has just checked in the code that they’ve been writing all week. We were working on a graphics editor canvas, and they implemented the ability to resize shapes like rectangles and ovals by dragging small handles at their edges. The code worked. But it was repetitive. Each shape (such as a rectangle or an oval) had a different set of handles, and dragging each ha
正しい日付を入力してるのにエラーになるときがある - CAT GETTING OUT OF A BAG
今年に入ってから二つの異なるソフトウェア（iOSアプリと組み込み系）で「正しい日付を入力してるのにエラーになるときがある」というバグに遭遇しました。おかしさっぷりが似ていて、きっとこれは「よくある不具合」なんだろうなと思いました。 軽い気持ちでお題風にツイートした 日付欄の入力チェック処理で「正しい日付を入力してるのにエラーになるときがある」というバグが潜んでいるとしたら 1. どのようなことが起きていると思いますか？ 2. (ソースコードは見れないとして)どんなテストをしてみますか？— miwa (@miwa719) 2021年9月7日 軽い気持ちでお題風にツイートしたら「ソフトウェア開発で日付を扱うときに気にしたほうがいいこと」が、たくさん集まりました。うれしかったです。 「1. どのようなことが起きていると思いますか？」では、失敗しそうなシチュエーションや疑わしいところ、確認したい事
リーダブルなコードを書く習慣の身に付け方・実践の仕方 - 2021-09-22 - ククログ
結城です。 2021年9月13日から14日にかけて、東京都立大学の大学院生向け特別講義として「リーダブルコード演習」を実施しました。 演習の内容は、当社でこれまでにも行ってきているリーダブルコードワークショップを、プログラミング経験が比較的浅い・プログラミングの量がまだそれほど多くない方向けに調整した内容としました。 この記事では、実施した演習の概要と、今回意識した点を紹介します。 本文が長いため、目次を用意してみました。 発端 演習の構成 座学パート リーダブルなコードを書く意義について リーダブルコードを実践するためにまず取り組むべきこと 実際の現場での「コードがリーダブルでなくなってしまった」「リーダブルになるよう改めた」実践例 最初の実装 リーダブルでなくなった実装 リーダブルさを取り戻すための改修 コードがリーダブルでなくなっていってしまう要因 壊すのが怖くて、見て見ぬフリ 恐怖
JSON スキーマで必須項目を指定する場合のよくある間違い | MuleSoft ドキュメント
Skip to left navigation Skip to main content Skip to page navigation
PHPerKaigi 2019: RESTの力 / 郡山 昭仁
PHPerKaigi 2019 のセッション動画です。 2019/03/30(30分) スピーカー: 郡山 昭仁 ( @koriym ) タイトル: RESTの力 HTTPはRPCではなく、RESTはHTTP上のCRUDシステムではありません。RESTはハイパーメディアアフォーダンスという発見性を持ち、進化可能性(evolvability)、スケーラビリティ、自己記述性、といったアプリケーションをパワフルにする力を持ちます。このトークでは、RESTの本来の力がアプリケーションにどのようにパワーとパフォーマンスを与え、アプリケーションアーキテクチャとどう作用できるのかフレームワーク製作者の視点を交えてお話します。 https://fortee.jp/phperkaigi-2019/proposal/777a19ee-2d1a-483d-a457-f72ef0bf5fbe
Web アプリケーションに HAL を適用する - addsict's blog
HAL (Hypertext Application Language) とは Web API でやり取りされるリソースを、ハイパーメディアとしても扱えるようにするための仕様です。 ハイパーメディアとは HTML のアンカータグをイメージするとわかりやすいですが、ドキュメントといったメディアがリンクを介して繋がっている状態のことを指します。 例えば通常の Web API で取得できるリソース同士は特別何かで繋がっているわけではなく、お互いのリソースがある意味孤立した状態にありますが、そこにリンクを含めてあげることでお互いのリソース間を行き来することが出来るようになります。 HTML と HAL をハイパーメディアの観点で言うと、このような感じになるでしょうか。 HTML: 人間が操作するためのハイパーメディア HAL: 機械が操作するためのハイパーメディア 具体的にリソースを HAL +
RFC7807に沿ったエラーレスポンスの実践について - トリプル・ダブリュー・ジャパン(DFree)開発者ブログ
トリプル・ダブリュー・ジャパン株式会社でソフトウェアアーキテクトをしています西田です。ネット上では主にkbigwheelの名前で活動しています。 今回は最近私達のチームで行ったRFC7807に沿ったエラーレスポンスの実践について紹介します。 RFC7807とは 2016年にIETFから発行された、新しいHTTP APIのエラーレスポンス形式*1です。 日本語の解説記事は非常に少ないですが、こちらのブログで非常にわかりやすく要所を日本語に翻訳しつつ説明されています。 HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様 この標準に沿うことで新しい開発メンバーへ仕様を共有することが簡単になります。 また過去にこの仕様を見たことがあれば、新たに勉強することは最小限で済みます。 サーバサイドチームの取り組み 私が所属するサーバサイドチームでは11月にAPIサービスの大幅なバージョンア
もう絶対迷わないエラーレスポンスの作り方【RFC7807】 - Qiita
この記事は「ゆめみ その2 Advent Calendar 2019」の5日目の記事です。 ある日のこと… 「いきなりそんなこと言われても…」 上司「ついでにいろんなところで使いまわせるように普遍的なのにしてね」 「えぇ…」 「こういう時にエラーレスポンスが標準化されてRFCでまとめられてたらいいのになぁ…」 ありました RFC7807 : Problem Details for HTTP APIs RFC7807では開発においてHTTP APIのために新しくエラーレスポンスを定義するのを避けるために、プログラムが読み取れるような問題詳細（Problem Details）をapplication/problem+jsonまたはapplication/problem+xmlで定義しています。 問題詳細（Problem Details）ってなんぞや？ type, title, status,
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ポステルの法則
鉄道指向プログラミング(翻訳)
オブジェクト指向のハードコア (9) OOP
オブジェクト指向のハードコア (8) GUI
オブジェクト指向のハードコア (7) DCI
オブジェクト指向のハードコア (6) REST
Understanding Problem JSON