Type-safe, composable asynchronous and concurrent programming for Scala
![ZIO | ZIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/691eac359239d0df18173ac94ba6150121a2319e/height=288;version=1;width=512/https%3A%2F%2Fzio.dev%2Fimg%2Fzio.png)
Type-safe, composable asynchronous and concurrent programming for Scala
はじめに 先日、エンジニアの能力と今どきの難しさというタイトルの記事(2018年)を読んで、「これはほんとにその通り」と思う一方で、具体例がないためにピンと来ない人や、マウント取りではという意見も多数見られた。というわけで、自分が比較的得意な、プログラミング言語の構文解析といった分野に関して、この記事の言わんとしていることを補足するような記事を書こうと思い至った。 記事中では、エンジニアに必要な知識や経験を、「ベース」「カテゴリ」「実行環境」という形(以下)に分けて論じている。 ①ベース コンピュータサイエンス(CS)などの理論的なもの 低レイヤー ②カテゴリ フロントエンド / バックエンド / クライアントアプリなど ③実行環境 特定のプログラミング言語や開発環境やツール、フレームワークやライブラリなど この中で、特に印象的であり、かつ「よくわかる」と思ったのは以下の記述だ。 ③は比較
はじめに ここ数年で、Kotlinは急速な勢いで台頭してきており、Androidでは(おそらく)既に支配的な言語になっているかと思います。サーバーサイドKotlinはまだまだこれからというところがあるように感じますが、今後の発展次第でシェアを伸ばす可能性が高いでしょう。この記事では、そんなKotlinとScalaの関係について説明したいと思います。 結論からいうと、KotlinはScalaの直系の子孫であり、ScalaはKotlinの親であるといって差し支えないくらいKotlinがScalaから受けた影響は深いです。このことについて、私はパクリだとかそういうつもりは一切ありません(元々、プログラミング言語の発展というのは、色々な言語からアイデアを集めてきてこそですし)。しかし、最近、Kotlinについて、GroovyとScalaのいいとこどりであるとか(そのくらいにしか影響がないという意味
お久しぶりでございます。Scalaでバックエンドを開発しているaxtstar(@axtstart)です。 みなさまゴールデンウィークはいかがお過ごしだったでしょうか? 我が家はあまり旅行に行くということもなく、近場のドライブや、ちょい大き目の公園などで過ごすことが多かったです。 さて、そのおかげというわけではありませんが、この連休を利用して、 新たにRustとWebAssemblyに入門してきたので今回はそのあたりの話を、書きたいと思います。 Image by prettysleepy1 from Pixabay 前書き 遅ればせながら、前々から気になっていた、Rust Programming Languageの勉強をGWを利用して初めて見ました。 随分昔ですが、Visual C++でDLLを作ってそれをフロントのVisual Basicで呼び出すのが最強と思っていた時があります。 それと
新しめの言語では例外を投げることを推奨しない言語が出てきているように思えるが、そうした言語が例外をどう考え、例外の代わりにどのようなアプローチを奨励しているかを調べてみた。 本稿での「例外」とは、Javaのthrow構文のようにスコープを脱出してcatchされるまでエスカレートされる「投げる例外」のことを指し、エラーを表現したオブジェクト(エラーオブジェクト)については「例外オブジェクト」と呼び区別するものとする。(この2つを同一に扱うと、例外を使わないということは、エラーオブジェクトは使わないの?という話になるため) Go言語 - 例外はコードを複雑にする Go言語では、通常、エラーは戻り値として扱われる。(本当の本当に例外的なエラーのためにpanic, recoverがあるが、ほとんど使われることがないように見受けられる。) 例外がないGoでは、どう呼び出し元にエラーを伝えているかとい
Trygve Reenskaug氏とJames O. Coplien氏らが提唱する「DCIアーキテクチャ」について、id:digitalsoulさんが論文を翻訳してくださり、またその解説とサンプル実装(groovy, scala)を示してくださっており、読んでみたところ、大変興味深いので理解した限りを書いてみます。 おじさん登場 たとえば、あるおじさんがいたとします。 このおじさんは、白いスーツ、グラデーションの入ったサングラスと金ぴかのネックレスをつけて新宿歌舞伎町に出かけ「やくざ」として振るまいます。とおりかかったお兄さんがそのおじさんに出会い、目が合ってしまい、因縁を付けられ、お金を巻き上げられてしまいます。 さて、おじさんは家に帰ります。実は、このおじさんは家では良いお父さんとして振る舞います。赤ちゃんはこのおじさんの目を見て笑いかけます。おじさんは相好を崩し、オーよしよし。 さて
この記事は RECRUIT MARKETING PARTNERS Advent Calendar 2018 の投稿記事です。 こんにちは。スタディサプリENGLSHでサーバーサイドとインフラを担当している松川です。 CleanArchitectureにEffを組み込むことによって、これまでモナドトランスフォーマーでは辛かった数種類以上のモナドを取り扱う処理をフラットに書けるようになったり、多くのメリットがあったので紹介させていだきます。 はじめに スタディサプリ ENGLISHのサーバーサイドは全てScalaで書かれており、CleanArchitectureを採用しています。 1つのサービスにおけるsbtプロジェクトの依存関係は以下のようになっています1)StreamAdapter,InternalAdapterは存在しないサービスもあります。。 基本的にはオブジェクトが主役な設計ですが、
前回↓ "2月になったくらいのタイミングでまた別途書きます" と言っていたやつです。 xuwei-k.hatenablog.com 今日、2019年2月1日が初出社でした。 Scalaをやってる企業としての知名度だと、おそらく前職に比べたらそこまで有名ではないかもしれませんが、それなりにやってるらしいです。 もちろん(?)、全部の部署がScalaではなく、自分が関わることになる部署を中心に一部で、会社全体でいうとおそらく今のところはScalaは少数派だとは思います。 一応、会社的な色々を説明しておくと リクルートは数年前まで大きい一企業だったけど、いくつかに分社化された。そのうちの一つが リクルートマーケティングパートナーズ 。*1 Quipperという企業を数年前?に買収して、教育関連のサービスはそことも関わるので、自分もそことも関わるのだが、ここでこれ以上詳細を説明してもしょうがないの
これはFOLIO Advent Calendar 2017の25日目の記事です。昨日は弊社CTOである椎野(tshiino48)による「IOTA ~ポストスマートフォン時代のフィンテック~」でした。 qiita.com 本日はFOLIO Advent Calendar最終日、締めの記事を「株式会社FOLIOの次世代証券システムをひもとく」と題して、Head of Engineeringの伊藤(@itohiro73)が務めさせていただきます。 株式会社FOLIOでは、フォリオという、個別銘柄ではなくテーマを選んで投資するオンライン証券サービスを提供しています。 *図表やデータ等はあくまでもサンプルであり、将来の運用成果等を示唆あるいは保証するものではありません。また、サービスの詳細はこちら 。 本エントリーでは株式会社FOLIOを支える次世代証券システムについて、機能面とエンジニアリングの両
1. Reladomo in Scala 株式会社FOLIO 伊藤博志 グッドフロー・テクノロジーズ 瀬良和弘 Scala関西 Summit 2017.9.9 Reladomo is an open source software Licensed under Apache 2.0 License, Copyright 2016 Goldman Sachs, Its name may be a trademark of its owner. X 2. 1 Agenda 1. 自己紹介 2. 株式会社FOLIOでの開発とReladomo 3. scala-reladomoの紹介 4. バイテンポラルモデル 5. scala-reladomoの… OSS公開!!!! hashtag: #scala_ks_main 3. 2 自己紹介 Head of Engineering @ FOLIO 伊藤
2019年1月20日付で株式会社FOLIOを退職し、2019年1月21日付でfreee株式会社に入社します。 FOLIOで何をしてきたか FOLIOでは2017年4月にテックリードとしてジョインし、その後Head of Engineeringへと名称が変わり、その後病気による休職を経て復職し、シニアソリューションアーキテクトとして働いてきました。 たった1年8ヶ月ほどの在籍でしたが、非常に密度の濃い日々を過ごしてきた気がします。 今回はせっかくなので生々しい話も含めて在籍中の思い出を語ってみたいと思います。 FOLIOとの出会い FOLIOを知ったのは2017年の2月頃、この記事を見つけたのがきっかけでした。 newspicks.com 前職の先輩であるbitFlyerのCEO加納さんのこのようなコメントをみて、プロダクトリリース前でのこの期待値はすごいな、面白そうだな、と思った記憶があり
Accidentally Turing-Complete ― Andreas Zwinkau 本来なら、チューリング完全となるべきではなかったものがある。これは、そのようなうっかりチューリング完全になってしまったものの例である。 C++テンプレート 当初はチューリング完全を目指していなかったが、C++テンプレートはチューリング完全になってしまった。その証明は、この論文にある(PDF) x86 MMU x86のpage fault handlingは、単純なマシンの実装に使える。原理としては、page faultが1 wordをスタックに積み、それによりアンダーフローを起こして別のトラップを生成する。この仕組みは、「減算して0以下ならば分岐」処理を実現する。チューリングマシンを実装するには十分である。デモ動画、講演動画 マジック・ザ・ギャザリング マジック・ザ・ギャザリングはカードゲームであ
# イマドキと言われる言語機能について ---------------------- [第60回プログラミングシンポジウム](http://www.ipsj.or.jp/prosym/60/60program.html) === # About Me --------- ![κeenのアイコン](/images/kappa.png) * κeen * [@blackenedgold](https://twitter.com/blackenedgold) * Github: [KeenS](https://github.com/KeenS) * [Idein Inc.](https://idein.jp/)のエンジニア + 情報科学の教育は受けていない純粋なエンジニア * 実際に仕事で使った(ている)のはJava, Scala, Rust === # 最近っぽい言語 ------------
このエントリは ドメイン駆動設計 #1 Advent Calendar 2018 の5日目です。 4日目は @s_edward さんの「Microservices と DDD」でした。 6日目は @kawakawa さんの ドメインオブジェクトとユースケースの関係について です。 TL;DR エンティティの同一性を表現するためにequalsをオーバーライドすべき ではない と考えています。 稀によくあるサンプル 次のような実装を目にすることがあります。以降のコードは Scala 2.12.7 で動作確認しています。 ※私が書きやすいのでScalaを用いていますが、他言語においても同様のことは言えるかと思います。 trait Identifier trait Entity[ID <: Identifier] { def identifier: ID def canEqual(that: An
Scalaのビルドツールsbtには1.xからLanguage Server Protocol 3.0に対応したサーバモードが実装されており、常駐させたサーバに別プロセスから接続してコマンドを実行することができます。サーバモードはIDEやエディタプラグインのために実装されたものだと思いますが、sbtにはクライアントモードも実装されており、コマンドラインで動作を確認することもできます。 たとえばあるプロジェクトでsbtのプロセスを立ち上げておき、 $ sbt ... sbt:gitbucket> 別のターミナルから以下のようにしてコマンドを送信します。 $ sbt client clean ... [info] entering *experimental* thin client - BEEP WHIRR > compile サーバ側ではこんな感じのログが表示されます。 [info] new
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く