Haskell製の新しいメッセージングシステムfranz(フランツ)の紹介。 github.com 背景 取引所にあるマシンで取引プログラムを実行するのが我々の仕事だが、朝8時に起動したらあとは昼寝したり酒を飲んだりというわけにはいかない。モニタリングしたり、分析のためにデータを残しておく必要がある。そのため、プログラムによって解析しやすい形でログを出力する。 今までは複数の種類のレコードをシリアライズし、一つのファイルに連結させる独自のフォーマットを10年近く使っていたが、書いていて恥ずかしくなるような多数の問題を抱えていた。 柔軟性が乏しい: 32bit整数や文字列などの単純な値しか格納できず、例えばレコードを含むレコードなどを表現できない。その結果、複雑なデータは一旦文字列に変換するような運用がされており、そのプリティプリンタやパーサは十分にテストされていない。 コードがまとまってい

前回の続きで、今回はPrismについて調べたのでそれについて記す。(lensパッケージ バージョン4.7に基づく) 前回書いたように、PrismはTraversalの一種であり、全体データの中の0個もしくは1個の部分データに着目する。また、Prismは「部分データから全体データを復元することができる」という、Lensにはない特徴を持つ。(そのため、Prismでは「全体」と「部分」という言い方は不適切かもしれない) >>> (Right "hoge") ^. _Right "hoge" >>> "hoge" ^. re _Right Right "hoge" この、Prismの効果を「逆転」する関数であるreがどういう仕組みになっているか気になったので、lensのマニュアルやソースコードを読んだ。 Prismの型 Prismのデータ型は以下のようになっている。 type Prism s t

In Scala variables are declared like: var stockPrice: Double = 100. Where the type (Double) follows the identifier (stockPrice). Traditionally in imperative languages such as C, Java, C#, the type name precedes the identifier. double stock_price = 100.0; Is it purely a matter of taste, or does having the type name in the end help the compiler in any way? Go also has the same style.

The Free Monad with Multiple Algebras Posted 29 Mar 2017 by Danielle Ashley In this post I will look at the machinery that makes it possible to use Free with more than one algebra at once: Coproducts and the Inject type class. This technique was first described in the paper Data types à la carte, and Cats and other libraries provide implementations. However we’re going to build our own implementat

Motivation and philosophy

発端 去年、Naoya Ito さんがこんな話(System of Record と System of Engagement)をした後、SOEとかSORとか話題になることも多くなったと思う。 そんな折、ちょうどいいタイミングで、SOR中のSORなシステムである銀行システムの話を、日本における銀行システムの曙までさかのぼってまとめた本が出たのでさっそくゲットした。 Title: 進化する銀行システム 24時間365日動かすメインフレームの設計思想 (Software Design plus) Publisher: 技術評論社 (Feb. 2, 2017) Author: 星野 武史 (著), 花井 志生 (監修) ISBN-13: 978-4774187297 Publish Date： 2017/2/4 Amazon: https://www.amazon.co.jp/dp/477418

この記事は Kobe University Advent Calendar25日目の記事です。 低レイヤー技術(後述)をこれから学びたい人向けの入門記事です。 自身の経験を踏まえ、より多くの人達にこのレイヤーに興味を持ってほしくて書きました。 決して卒論がやばくてAdvent calendarのネタが作れなかったわけでは(ry なぜこんな記事を書いたか いわゆるシステムプログラミングのような低レイヤー(と言って差し支えない)ジャンルって一体何から始めれば良いのかいまいちピンと来ないし、何が面白いのかも分からないと思われている事が多いと思います。 にもかかわらず低レイヤーの魅力や学び方の指針みたいな物を示した、いわゆる入門記事ってかなり少ないんですよね。 本記事はこれからシステムプログラミングを始めたい方や、既にかじってみたが中々先が見えてこない、将来何の役に立つのか不安という方達に読んでい

はじめに 皆さん、OpenID Connect を使った Web 認証/認可システムを実装していて、「サードパーティのライブラリなんかに頼りたくない！」とか「署名を自分でパースして中身見てみたい！」とか「OpenSSL の RSA_verify 呼び出すだけじゃ物足りない！自分で $m = S^e \pmod{n}$ ってやって署名検証してみたい！」って思うことよくありますよね？ ここでは、暗号関連のライブラリを使用せず、OpenID Connect の JWT の署名を自力で 検証した際に調べた内容を備忘録としてまとめてみました。 普通はライブラリ任せにする署名検証の処理も自力でやってるので、「RSA 暗号の数式も知ってるし、ライブラリ使えば暗号化もできる。だけど、平文として指定した hogehoge をどうやってあの数式に当てはめてるのか気になる」という人が読むと、もしかしたら嬉しいか

こんにちは、エンジニアの @MinoDriven です。 今年2019年4月にリファクタリング専門チームを発足しました。 crowdworks.jp の最重要機能であるお金周りの機能に関して、どのような技術アプローチでリファクタしているかを紹介致します。特に、Railsには適用困難と言われているドメイン駆動設計の考え方を取り入れた手法を解説致します。 目次 背景 リファクタリング専門チーム発足 技術的負債 リファクタリング対象選定 方針①：パレートの法則（80:20の法則） 方針②：リファクタリング選定基準3軸 「仕事周り」か「お金周り」か お金周りモデルのリファクタリングを妨げるConcern 課題①：ActiveRecord側の構造に依存したコード 課題②：型や構造のチェック(リスコフの置換原則違反) 課題③：重要業務概念の埋没 どのようにリファクタしたか 手法①：Concern側メソ

残業も減らせる!? 上級エンジニアになるためのDesign Doc超入門：プロジェクト成功確率向上の近道とは？（3）（1/3 ページ） ITシステム開発の問題点の一つであるコミュニケーションの失敗。本連載では、これを防ぐ方法としてお勧めしたい3つのドキュメントを紹介していく。今回は、「技術視点」のドキュメントとして、2000年代以降注目されている「Design Doc」について解説します。 IT技術がビジネスに貢献していくためには、まずはシステム開発を成功させることが重要です。本連載「プロジェクト成功確率向上の近道とは？」では、システム開発を成功させるために、コミュニケーションが果たす役割の重要性と、ドキュメントによるコミュニケーションの重要性について解説してきました。 連載1回の「ドキュメントは最強のコミュニケーションツールである――Joelの機能仕様書入門」、第2回の「サンプル例に見る

なぜ必要なのか？ アジャイルにしたら全体像が見えなくなる。 なんて、よく聞くことはありませんか？ スクラムの場合、製品の全体像を決めるものは、プロダクトバックログです。 プロダクトバックログを単調な優先順位とストーリーポイントのリストにしてしまうと、確かに全体像が見えにくい場合があります。 例えば、以下の様なユーザストーリーのリストを見ると、確かに少しわかりづらいです。 電子メール管理システムの場合 1.ユーザは電子メールを検索できる。 2.ユーザは電子メールをファイリングできる。 3.ユーザは電子メールをキーワードで検索できる。 4.ユーザは電子メールを移動できる。 5.ユーザはサブフォルダを作ることが出来る。なぜならそこに電子メールを移動させたいからだ。 6.ユーザはひとつのフィールドで電子メールを検索できる。 7.ユーザはひとつ以上のフィールドで電子メールを検索できる。 8.ユーザは

私が古代コーカサス人を目指すようになるまで「職場からそれなりに近い」というだけの理由で住んでいた六本木の街は、暮らすには最悪の場所で、当時、私の住んでいたアパートは、古くて汚くて治安の悪い、スラムのような場所だった。 週末は特に最悪で、土曜日の朝には、朝日がきらきらと光る街道の植え込みに、ゲロにまみれた人間たちがゾンビのように倒れていた。 ◇ 職場の同僚たちは、どういうわけか六本木に完全適応していて、ある日、誘われて行った飲み会では、テキーラが300杯も出てきて、明け方には、割れたグラスの破片でいっぱいの床に、酔いつぶれた人々が死体のように転がっていた。 「この前の会では、オーパスワンを60本並べて一気飲みしたんだ」 誰かが、誇らしそうにそう言った。 ◇ 文明がどれだけ発展しても、人間にとって最高の娯楽は酒とセックスで、お金があっても一気飲みする酒の種類が変わるだけ。それは、あまりにも夢が