年の瀬ご多端の折、皆様におかれましては本年も大変お世話になりました。crowdworks.jpの開発をしているプロダクト開発部部長兼VPoEの@hihats です。 本記事はクラウドワークスAdvent Calendar 2022 24日目の記事です。 我々の組織ではこれまでも技術的負債解消に取り組んできていましたが、今期（10月）よりさらに人と時間をそこに集中しています。これまでこのブログでも紹介されてきたようにRuby on Railsのモノリスとなっているcrowdworks.jpにおいて、フロントエンドのVue.jsへの移行は今年に入ってから着々と進む中、バックエンドのほうは保守性の低下からどう脱却していくかが手付かずに近い状態でした。 この本丸を攻略するにあたって、闇雲にリファクタリングしていくぞ！では到底うまくいきそうにない。まず「何故やるのか、何をゴールとするのか」の意識あわ

高品質なウェブフロントエンドを作るための言語 Elm の有用性が徐々に広まり、今年も採用事例が増えました。 利用者数が増えることは良いことではありますが、一方で悪気なく誤解を招く情報が生まれてしまう機会も増えてきます。 そこで、本記事はこれからElmをはじめる人やはじめて間もない人1が遠回りしないで Elm をモノにできるように、Elm を学ぶ上で落とし穴となる注意事項とその回避方法をまとめます。 なお、本記事で対象にするのは「実際に Elm を使って実用的なアプリケーションを作りたい」と考えている方です。 Elm をマウンティングのために使いたいマウンティングゴリラの方や、「プログラミング言語全部完全マスターした」と言うためにハローワールドやTODOアプリだけ書いて満足したい方は、別にそういう生き方も否定はしませんが本記事の対象外です。 そういう手っ取り早く形あるものを作ること自体に最大

手続き型に慣れた人にもやさしい、こわくないHaskell入門記事です。 「なぜHaskellを学ぶと良いか」も参考にしていただければ幸いです。 まえがき Haskellと聞いて、何を思い浮かべますか？ モナド 関数型 遅延評価 第4世代Intel Coreプロセッサ アライグマ いろいろ思い浮かべるかもしれませんが、Haskellがすばらしいのはモナドを利用しているからでも、遅延評価型の純粋関数型言語だからでもありません。 いろいろな「Haskellらしさ」が集まって、その結果Haskellにしかないすばらしい魅力を提供してくれます。 それは、決していままでのパラダイムと対立するものではなく、 手続き型 構造化プログラミング オブジェクト指向 のようなこれまでの便利な道具をうまく抽象化しながら統合して作り上げられたものです。 PHP javascript C++ Java などにあなたが費

なぜこれを書くのか 私がQiitaに投稿した記事を見た方から、メールが届きました。 プログラミング言語のHaskellを勉強し始めたものの、難しくてやめようかと考えているそうです。 その気持ちも非常によく分かります。 すごいH本が出版されてから年月も経ち、それなりに勉強しやすくなったとはいえ、お世辞にもHaskellを学ぶ環境が整っているとは言えません。 私はHaskellで製品開発をする会社を保守運用していたことがあり、また自分自身もHaskellでプログラムを書いています。 また、Haskellを普及させるべく、「こわくないHaskell入門」という記事を書いたこともあります。 これらの経験を踏まえ、この機会にあらためて「なぜHaskellを学ぶと良いか」についてまとめたいと思い立ちました。 Haskellについてまだよく知らない方が、入り口として読める内容を目的としているので、できる

この記事は、Haskell Advent Calendar 2022の23日目の記事です。 だいぶ荒削りですので、間違いがあるかもしれません。 目的 OSSのプロジェクトで4年ほどNixを使い続けてきました。 NixのHaskellのサポートの現状のいいところと課題を整理するのが目的です。 なぜNixを使うのかを確認したあと、NixのHaskellサポートをみて課題をまとめます。 なぜNixか、なにがやりたいのか？ Nixはパッケージマネージャーです。各種Linuxディストリビューション, MacOSに入れられるものです。 Nixに期待していることはなんでしょうか？ それは再現性と効率性ではないかと思います。 まずは再現性についてです。nixosのポータルの一番はじめにでてくるように再現性がもっとも重要でしょう。 手元の開発環境やクラウドの開発環境、各種のメンバーで開発するソフトウェアのバ

この記事は、 NTT Communications Advent Calendar 2022 24日目の記事です。 はじめに イノベーションセンターの木村と申します。初めてのアドベントカレンダー&Engineers’blog投稿です。普段の業務は、機械学習をもちいた時系列データ分析の研究開発やお客様データ分析案件支援を主として行っています。プライベートでは自転車にお熱でZwiftでバーチャルライドをしたり、最近ではテクニック向上のためバニーホップの練習に励んでいます（なかなか上達しません…）。 今日はクリスマスイブということで、時系列データ分析コンテンツ「ごちきか」 をプレゼント（？）します！年末休みのお供にぜひご照覧ください。 サマリー 時系列データ分析コンテンツ「ごちきか」を公開しました （余談として）基盤やデプロイ方法を紹介します What is 「ごちきか」？ 私たちのチームでは、

2023年2月〜3月頃に、私が執筆した書籍『エンジニアのためのマネジメント入門』が発売になります🎉 本稿では、発売に先立って「書籍について」と「執筆のきっかけ」、そして、書籍の「目次」と「各章の内容」を紹介します。 書名: エンジニアのためのマネジメント入門 著者: 佐藤大典 出版社: 技術評論社 発売日: 2023年2月〜3月頃（追記: 2023年3月9日発売になりました） 書籍『エンジニアのためのマネジメント入門』について 本書は、タイトルのとおりエンジニアリングマネージャーの入門書です。 本書のポイントは、エンジニアリングマネージャーの実務よりも、基礎となる知識の体系化を図ったことです。 この一冊で、エンジニアリングマネージャーの基礎的・基本的な知識と技能を学べます。 ハウツーではなくマネジメントの原典を基にした本なので、エンジニアリングマネージャーの入門者だけではなく、経験者の方

こんにちは！ dely, Inc.のリテールカンパニーというリテーラー向けにプロダクトを提供している事業部でSaaSプロダクトのプロダクトマネージャー (PdM) をしている奥原 (@okutaku0507) といいます。 この記事は「プロダクトマネージャー Advent Calendar 2022」の23日目の投稿です。昨日は安部さん (@abeshow) の「個に迫って見つけた課題が、どうして広く一般的なものだと言い切れるのか」でした。個人の課題を掘っていったら、実はみんな抱えている課題だったということは良くあります。是非、読んでみてください。今年のAdvent Calendarも、どれも学びがある投稿が多く勉強になります。 毎年、長編のnoteを書いていますが、今年は「プロダクトマネージャーは考える葦である」というタイトルで、なぜ人間は学ぶのか、学んだことで本当に成長するのか、どうし

こんにちは、すべての合意をフェアにしたい、MNTSQ（モンテスキュー）の板谷です。 私は「契約×NLP」をテーマとしたSaaS企業のCEOをしています。この投稿は、「”検索” や “推薦” の技術が、社会をフェアにする力になる」ことをお伝えする連続投稿の後編です。 （Part I）なぜ ”検索” と “推薦” で社会がフェアになるのか （Part II）契約に関する検索の面白さ ←今回 今回は、ひたすら契約というドメインにおける検索の面白さ / 難しさを語っていきます。 契約データの共通性のなかにも顧客ごとの独自性が存在する契約というデータが、本質的にNLPと非常に相性がよいというのは Part I で触れたとおりです。 他方で、契約データ特有の難しさもあります。その一つは、契約はあらゆるビジネスで締結されることがあるがゆえに、ビジネスごと・顧客ごとに独自性も存在するということです。そのた

はじめにこんにちは。GMOペパボ株式会社で、オリジナルグッズ作成・販売サービス「SUZURI byGMOペパボ」のPMをしているマキヤマミルテです。 この記事は、地味PM Advent Calendar 2022 3日目のエントリーです。 自社サービスの話になりますが、今まで「オリジナルグッズ」という物販の領域でサービス提供をしていたSUZURIが、クリエイターの皆様の創作活動の幅を広げる取り組みとして、11月16日から動画や音楽などデジタルコンテンツの取り扱いをスタートしました。（現状は事前登録のみ可能です） このプロジェクトは今年の夏頃から始まり、自分が担当PMとして進めていたものだったのですが、今までのSUZURIにはなかった「デジタルコンテンツの販売」という新しい概念を取り入れるにあたり、正直最初はわからないことばかりで、特に最初は久々の「全くわからん」という感情が大半を占める日々

テストコードを初めて書く時やプロダクトがどんどん大きくなっていく時に、ついつい保守しづらいテストを書いてしまうことはありませんか。 さっとコードを直したいからテストを書いているのに、それが面倒になってしまっては本末転倒ですね。 この本ではテストコードを触るのが億劫にならない様になる考え方の１つを紹介します。

この記事はソフトウェアテストのカレンダー | Advent Calendar 2022 - Qiitaの23日目です。 毎年のことながら「何を書こう・・・」と悩んでいてTwitterに助けを求めたところ、@teyamaguさんからネタをいただきました（ありがとうございます） 案1：今年読んだ中で最も役に立ったor読んで良かった本 案2：今年で見た中で最もイケていた自動テストシステム とかどうでしょうか？ — teyamagu (@teyamagu) December 6, 2022 最も役に立った、だとなかなか決めかねる部分があり、「読んでよかった本」をつらつらと書いていこうかと思います。 私が2022年に読んだというだけで、今年発売された本には限らない点ご注意ください。また、熟読した本ばかりではなく、ポイント読みやざっと流し読みした本も含めます。（意志薄弱 The BDD Books -

この記事は「STORES Advent Calendar 2022」 12/17の記事です。また、「Engineering Manager Advent Calendar 2022」 カレンダー2の12/17の記事でもあります。 こんにちは！STORES エンジニアリング室の塩谷(@kwappa)です。この記事では、エンジニアリングマネージャーの中に棲んでいる「荒ぶる四天王」について考え、うまくつきあい、あわよくば手懐けてしまおう、という試みについてお伝えします。 エンジニアリングマネージャーのしごと この記事をご覧の方でしたら、今年8月にオライリーから発売された『エンジニアリングマネージャーのしごと』という書籍に興味がある、もしくはもう読んだのではないでしょうか。エンジニアリングマネージャー（以下EM）という重要だが定義がふわっとした仕事にどう取り組んだらいいかのガイドとなる、とてもいい

よければ他のアドベントカレンダーで書いた記事もどうぞ！ はじめにはじめまして！現在、BASE株式会社でプロダクトマネージャーをやっている @tsuboと申します☕ 前職クックパッドで『クックパッドマート』というサービスで、アプリのプロダクトマネージャーとして2年ほどPMを経験し、これまでSchooなどスタートアップを数社経験してきました。今年BASEに転職し、現在はショッピングサービス『Pay ID』のプロダクトチームのマネージャーをしております。 プロダクトオーナーシッププロダクトオーナーシップは諸説あり、定義されたものがすでにあると思いますが、ここでは「ユーザーのことを考えて、価値のあるプロダクトをつくるため、チームがプロダクトに対して自分ごと化していくこと」と解釈しています。 ※ この記事ではAgile Product Ownershipとは、異なる定義・解釈をしています チームがプ

Slackのメッセージに絵文字でリアクションするの、便利ですよね。 絵文字一つでコミュニケーションが円滑になった例をたくさん見てきたので、どんどん追加する人が増えるといいなと思っています。 今回は、様々なworkspaceで合計数千個の絵文字を追加してきた私が、多くの人の中で使われ、組織に良い影響を与えるために、作成時に気をつけていることについて紹介したいと思います。 https://<workspace-id>.slack.com/customize/emoji で絵文字の追加と、追加されている絵文字を名前や追加したメンバーで検索することができます。 私が絵文字の作成 / 追加に使っている主なツール（すべて無料で使うことが出来ます。） 簡単に絵文字を作成できるWebサービス 絵文字ジェネレーター: 簡単にテキストの絵文字を作成できる。専用のChrome拡張と組み合わせると、作成してそのま

本記事は、画像生成AI Advent Calendar 2022 15日目を埋める記事です。 はじめに 画像生成AIは、学習した画像をコラージュした画像を出力しているのではないか、という議論があります。多くのモデルは勝手に収集した画像で学習（訓練）されているため、そのようなコラ画像が生成されていたら大問題です。 上の図を見てください。この図は、今月投稿された論文 [1] Diffusion Art or Digital Forgery? Investigating Data Replication in Diffusion Models [Gowthami Somepalli+, arXiv 2022] の図です。上段がStable Diffusionの生成画像、下段が訓練データのサブセット（LAION Aesthetics v2 6+）中で一番似た画像です。生成画像の一部またはほぼ全部が

この記事は Nikkei Advent Calendar 2022 の 24 日目の記事です。 はじめに メリークリスマス 🎅 デジタル事業情報サービスユニットで検索エンジニアをしている日當（@hinatades）と申します。 本記事では、報道記事の時事性を加味したクラスタリング手法を、検索サービスへ導入することを目的として開発したのでご紹介します。 弊社ではこの開発テーマを長らく実現に向けて取り組んできましたが、今月やっと日経リスク&コンプライアンスにて初めてサービスインできました。 これまでの課題感 私の所属している情報サービスユニットでは、200 社以上の企業様とコンテンツを提携しており、それらを各サービスからお客様に提供しています。 例えば日経リスク&コンプライアンス(以下日経 RC)では、50 社以上の報道記事を検索することで取引先のリスクやコンプライアンスのチェックが可能です

この記事はユアマイスターアドベントカレンダー2022の22日目の記事です。 はじめまして。ユアマイスターでプロダクトマネージャー（以下PdM）をしております、稲垣と申します。 この記事では、私がPdMとして約10年程働いてきた中で、プロダクトチームにおいてPdMとエンジニア、デザイナーの関係性において、考えていること、大切にしていることを書きたいと思います。私は経験がBtoB向けのプロダクトが中心なので、そっち寄りの内容になっています。 まず自己紹介私は2022年10月にユアマイスターに入社しました。まだ新人です。あと、初めてnoteを書くので緊張しています。よろしくお願いします。 これまでのキャリアでは最初4年ほどエンジニアをやっていたのですが、その後は約10年ほどPdMをやっています。領域としては、ずっとBtoBの、主にSaaSをやってきました。 ユアマイスターには約5年ほど前に「大人

技術的負債は開発者体験を悪化させる / Technical Debt and Developer Experience - Speaker Deck 「品質と速度はトレードオフの関係ではなく、比例する」みたいな話を見聞きするたびにモヤッとするのが、 本当に短期的な話、三十分以内に変更してデプロイしたい、みたいな「短期的」な話であれば「テスト書いてる時間はない」は間違いではない、一分将棋みたいなギリギリのプロジェクトに従事している人のことを考えろ（？） 「ちゃんと設計せずに作った（そうせざるを得ない外圧があった）→ちゃんと設計する余裕があれば負債を溜め込まずに済んだ」みたいに聞こえるが、十分な時間があったら負債が出ない高品質の設計ができたとでも思っているのか？ ↑に書いた「三十分か一時間か」みたいなギリギリの状況ならいざ知らず、日・週単位でスケジュールが組まれてるソフトウェア開発プロジェクト

「仮説を出すための分析」はどう実践するか 加藤舞子氏（以下、加藤）：ということで（ここまでで）3つ聞きましたが、視聴してくれている方がたくさんいて、質問もたくさんもらっているので、質疑応答に移れればと思います。 1つ目。「仮説を出すためのデータ分析には、どのような分析が効果的なのか聞いてみたいです」。確かに「仮説を持て」と言うけれど、その足がかりもない時はどうすればいいのかということで。じゃあ、厳しそうだったまーいー（今井氏）に聞いてみようかな。 永石陽祐氏（以下、永石）：（笑）。 今井隆文氏（以下、今井）：仮説を出すための分析と、課題を具体化するための分析はやはり違うんだろうと思っています。仮説を出すための分析は、「数値の前にユーザーの行動がどうなのか」ということにフォーカスする。自分はそう意識していると思います。 具体的には、例えば「ここのパネルが悪い」という分析は、そこを改善する時の

はじめに 最近、GoのNamed return valueに関する話題を見かけたり、コードレビューでNamed return valueについて説明をすることがありました。 せっかくなので、Named return valueのメリデメを自分の主観でまとめます。 Named return value Goでは、関数の戻り値に名前をつけて変数として利用することができます。 この仕組みをNamed return valueといいます。 メリット 変数名から、戻り値が何かわかる 関数の戻り値に名前をつけると、変数名から何の値かわかるようになります。 関数名や型から戻り値が何か明らかでないときに役立ちます。 具体例を示すために、Effective Goのサンプルコードを引用します。 nextInt関数はint型の変数を2つ返します。 しかし、nextIntという名前から何の値が返されるかはわかりま

「プロダクトマネージャーカンファレンス 2022」は、プロダクトマネジメントに携わる人たちが共に学び、切磋琢磨することを目的に開催されるイベントです。ここで、コネヒト株式会社の吉岡氏が登壇。次に、“MyPM像”について話します。 吉岡氏流の「PMスキルモデル」 吉岡詩織氏（以下、吉岡）：ここまでバーッと私の具体のエピソードをお話ししましたが、後半はこの話を一歩抽象化したいと思っています。 突然ですが、世の中にはPMのスキルマップとかモデルみたいなものっていっぱいあると感じていて。（スライドを示して）これは、私なりにそれらをかみ砕いて落とし込んだモデルになっています。 まず一番下のところにこれはないといけないと感じているのが、プロダクトの成功を願うマインドであったり、顧客、ユーザー、ターゲットを幸せにしたいという気持ち。そして学んで身につけていくものとして、ビジネス、ものづくりの両面に対して

1. はじめに こんにちは！kintone 開発チーム所属モバイルソフトウェアエンジニアのトニオ（@tonionagauzzi）です。 Cybozu Advent Calendar 2022 の24日目の記事です。 私が所属しているkintoneモバイルチームではモブプログラミングが浸透しており、開発作業の7割以上をオンラインで画面共有するやり方でモブプロしています。 そのモブプロに関する記事ですが、今回は、既にモブプロをやっているkintoneモバイルチームに新人の私が入って感じた抵抗感についてです。 私が9月に入社してから4ヶ月間の抵抗感と乗り越え方について紹介することで、次に来る新人さんを「大丈夫だよ」と後押しできれば幸いです！ ※ 本記事におけるモブプロとは、一般的なモブプロではなく、kintoneモバイルチームが採用しているモブプロのことを指します。 2. モブプロの基本 モブプ

何かこうかな〜と思ったのですが、Nstockに入社してからの半年間で学んできたことは下記のnoteに吐き出しずみなので、別のなにかを書こうと思います。 そこで、11月のある日、Paul Graham先生のブログからありがたいお言葉をいただいたので、その話をしていこうと思います。 つまりこのnoteは 「PMのみんな！来年もたくさん書いていこうね！私もがんばるつもりだよ！」っていう自分への応援を込めたnoteなのであります。 ブログ内で例えばこんなことを言っている。 良い書き手はほぼ常に、書きながら新しい発見をしているんだ。 そして私が知る限り、こういう発見をする手段に代替方法はない （中略） 複雑で、明確に定義されていないような問題を解かないとならない時は、 ほぼまちがいなく、書くことが役に立つ。 ということは、書くことがうまくない人はそういう問題を解くのが苦手になるということだ。 ※版権

このブログでも、ぼくのTwitterでも「仕組みで解決していくしかない」とか「マネジメント頑張る」ということをよく書いているのだけど、あるとき「仕組みで解決ってどういうことなんですか？」と質問されてハッとしたことがあります。今日はそのことを書いていこうと思います。 そのひと曰く、仕事上の問題は個人ごとに感じ方や問題の観点、解決したいやり方が違う。だからその個人個人の感じるポイントややり方に合わせて個別具体的に解決していくものではないか、仕組みで解決なんてできることは少ないのではないか、と。 仕組みで解決というものに対して懐疑的というかむしろ否定的な人は多いなあと感じてはいたけれど、この質問をもらったことでそう感じる人が多いのは何故か、どう説明すべきかをより深く考える良い機会になりました。質問してくれたひとありがとう。 今日は「仕組みで解決する」と何が良いのか、「マネジメント頑張る」というの

ソフトウェアデリバリーパフォーマンスに関する考察（前編） - State of DevOps 2022では何が示されたのか 去る2022年9月29日（アメリカ時間）にState of DevOps 2022が公表されました。 State of DevOpsとは、年に1回DORA（Google Cloud内のチーム）が発表しているソフトウェアのデリバリーパフォーマンスに関する調査結果レポートです。State of DevOpsでは、ソフトウェアデリバリーパフォーマンスの指標でもあるFour Keysや、Four Keysの改善効果が高いとされるケイパビリティについての詳細な内容が記載されています。 株式会社ビズリーチでは、日々プロダクト開発のプロセスをより良くするための活動を行っています。今回State of DevOps 2022の発表に伴い私が所属するプロセス改善部内でState of

Recruit Engineers Advent Calendar 2022 - Adventar 23日の記事になります。 1. 方法論は限定スコープ内における合理性の話である 書籍などで得られる概念や方法論（技術含む）は、その書籍がスコープとしている中での限定合理性の話をしており、 書籍がスコープとした範囲における論理的正しさである場合がある。 特定のスコープの中においての最適なので、実は全体からみると個別最適だったりする。 つまり、実は引いてみると非効率なことを近距離でみると効率的だと主張している場合もある。 この包含関係による概念的強さみたいなものは存在しており、例えば、制約条件理論みたいなものは、様々な概念の上位に存在しており包含していたりする(そう勝手に思っている)。スコープを決めそのスコープ内におけるボトルネックを活用しスループットを最大化させるという概念的な強さはあり、その

はじめに Java中心で仕事をしていた人がGoを書いてみると様々な文化の違いにぶつかると思います。そもそもオブジェクト指向言語と手続き型言語であるなど根本的に異なる点は多いのですが、「よりシンプルに」をモットーとするGoにはよりJavaエンジニアを困惑させる文化がたくさんあるように見受けられます。 本記事ではJavaエンジニアがGoを書いた際に感じた独特な文化を経験ベースで書いてみます。Goをこれから書くであろうJavaエンジニアのお役に立てれば幸いです。 対象読者 これからGoを書くことになりそうなJavaエンジニア Javaと比べたGo特有の文化を知りたい人 実際にGoの開発をするにあたって役に立つ思想を知りたい人 本記事の対象でない人 Goの構文や書き方を基本から学びたい人 とりあえずプロダクトを作って動かしてみたい人 実際に開発する上で意識しない裏の仕組みやアーキテクチャを知りたい

｜DMM inside

はじめまして。ログラスの盛川です。 ビズサイド2人目として入社し、現在はマーケティングとインサイドセールスの責任者をしてます。 好きなことは海外旅行です。感動をする自然・景色を見るのが好きで、30カ国ぐらいを旅しました。一人旅ではなく、友人とワイワイ楽しむ方が好きです。2023年こそはアイスランドに行く！ 卒業旅行で行ったウユニ塩湖留学中に行ったフィンランドの山奥これまでの経歴を簡単にまとめました。セールスや事業開発、マーケティングなど色々な経験させていただき、日々楽しく働いています。 これまでの経歴 1社目：フリークアウト（アドテクノロジー） 大学卒業後、アドテクを牽引するフリークアウトに新卒入社。国内大手の総合代理店・広告主の皆さまに対する企画営業や、BizDevとしてアライアンスや事業開発・商品開発を経験させていただきました。 2社目：ログラス（経営管理クラウド） ビズサイド2人目の

はじめに 従来式のニューラルネットでは, 未学習のニューラルネットに対し, 各辺の重みを徐々に変化させることで学習を行います. これに対し本記事では, 未学習のニューラルネットに対し, 重み更新なしで学習が可能な画期的な一風変わった手法"edge-popup algorithm"[1]を紹介します. 元論文: What's Hidden in a Randomly Weighted Neural Network? 公式実装: https://github.com/allenai/hidden-networks/blob/master/simple_mnist_example.py 本記事ではedge-popup algorithmがどういった着想で編み出されていて, 何を行うアルゴリズムか, どの程度高い性能が出るか, どういった後続研究があるかを順を追って見ていきます. 宝くじ仮説とは

どうも、Go信者のgureguです。今年初めて論理プログラミングをやってみて世界が変わりました。Go言語で論理プログラミングが出来るライブラリを紹介しようと思います。 ぼくのかんがえたさいきょのくみあわせ 課題: Go言語で書かれたソフトを拡張機能のようにカスタマイズしたい Go言語の特徴としては 制止的 コンパイル式 手続き型 標準ライブラリが優れている プラグインと言った拡張機能みたいな書き方は基本的に出来ない Prologの特徴は 動的 インタプリタ式 論理プログラミング 標準ライブラリ（ISO述語）は最低限の機能しかない プラグインとかスクリプトとしての使い方は簡単に出来る この正反対の言語２つを組み合わせたら最強になります。それぞれのメリデメをカバーが出来ます。 ichiban/prolog ichiban/prologはYutaka IchibangaseさんによるGoで実装さ