Rich Hickeyの有名なプレゼン"Simple Made Easy"を簡単に解説(*> ᴗ •*)ゞ Clojureの基本的な設計思想を理解しよう!Read less
Keycloakドキュメントの翻訳ではどうしているかというと、3つ目のテキスト抽出した部分のみを翻訳の方式を採用しています。というのも、現状、毎月のように最新版がリリースされており、ドキュメントもどんどん変わっていく恐れがあると思い、変更に追随しやすい(はず)、翻訳者は翻訳作業だけに集中できる、という点から3つ目の方式を今のところは採用しています。 ソーステキストからのテキスト抽出について 方式3を取る場合、テキスト抽出を行い、翻訳後に元のテキストにマージする仕組みが重要になってきます。というわけで、次はテキスト抽出について述べます。 翻訳対象のソーステキストフォーマット テキスト抽出を行うためには翻訳対象のソーステキストフォーマットが重要なポイントになってきます。OSSドキュメントで利用される代表的なテキストベースのドキュメント作成ツール/マークアップ言語としては以下があります。 Asc
clara-rulesというライブラリがにわかに自分の中で話題になっていたのでさっとまとめてみた。 概要・特徴 ルールエンジンの実装を提供するライブラリ ドメインの知識をコードから分離する clj/cljs両方で利用できる Javaからも自然に利用できる 作者本人による講演のビデオもある [1] [2] より最近の講演のビデオもある ルール?エンジン? エキスパートシステムに出自がある プログラマーが足り無い状況で、ビジネスユーザーがプログラマーを介することなく問題を解決できることが魅力で一時期流行ったが限界があった clara-rulesは現実的にどのようなルールでもコードであるという視点で、ビジネスユーザーではなくプログラマーをターゲットにしている 解決できること 何かロジックがあったとして、関数の呼び出しとして表現すると、そのロジックが必要とする情報を渡す/受けとることを明示的に書く
ブログを書くのは久々です。 京都で小さな会社をやっていて、自社開発でClojureとClojureScriptを使用し続けて、概ね3年くらい使い続けています。その過程で、Clojure自体にも小さいながらソースレベルの貢献ができたりして、オープンソースプロジェクトとしても面白かったのですが、もともとオブジェクト指向言語ばかりやってきたところから、Clojureという、まったくオブジェクト指向言語ではない言語に飛び込んだ経験や考えたことなんかを、ブログにストックすると、何か他の人にも役立つこともあるかと思って、ブログに書くことにしました。 このところずっと、自社の仕事とは別に、恵比寿にある 株式会社ユーザベース さんのお仕事に参加しています(私が法人を作る前からなので、もう5、6年くらいになります)。そちらの方でもClojureやシステム設計の話(プレゼンなど)などを何度かさせてもらったり、
2017年4月1日、秋葉原コンベンションホールにて「ElixirConfJapan 2017」が開催され、300人を超す参加者が集まり大盛況となりました。その模様をレポートします。 オープニングの模様 オープニングキーノートセッション ―José Valim氏 オープニングキーノートはElixirの作者であるJosé Valim氏による講演です。2017年1月で5歳になるElixirの歴史と今後の展望について発表しました。 José Valim氏 何故Elixirを作ろうとしたのか 2011年、並行処理の重要性が高まりから、その課題解決のアプローチとして、関数プログラミングに注目したとJosé氏は語り始めました。 RubyやPython等のオブジェクト指向プログラミング言語では、複数のスレッド間で並行的にオブジェクトの状態操作を行うのは難しいという問題があります。そこで、関数プログラミング
C++からRustに入った人あたりから「関数型言語から来た人のRustの感想を知りたい」とたまに言われるのでいつかブログ書こうか。 — κeen (@blackenedgold) 2017年4月3日 イントロ 私はRustをやる前にはCommon LispやSMLを主に使っていましたが、仕事ではScalaを使っていましたし他にもOCamlやSchemeやClojureやATS2やHaskellなどを書くこともありました。 私を含めた多くの関数型言語経験者人が一度は Rust for functional programmers を読んだことがあるかと思います。 このように関数型言語と比較して書かれるといかにも似た言語に見えるので私は興味を持ちました。そこで私は実際にRustに触れ始めたのです。 構文 let があるのでおよそOCamlなどに似ているという印象を受けました。 デフォルトでイミ
1. The document discusses RESTful APIs and gRPC, comparing their characteristics and use cases. 2. RESTful APIs typically use HTTP and JSON to access resources via URLs while gRPC uses protocol buffers and HTTP/2 for efficient streaming and RPC. 3. gRPC is better suited for microservices and mobile apps due to its ability to handle streaming and performance, while REST is more widely used due to i
(編注:2016/7/27、頂いたフィードバックを元に記事を修正いたしました。) 学生たちから、次に学ぶ言語はどれがいいのかとよく聞かれます。IT業界で働きたい人にお薦めするのは、現在盛んに使われている言語です。C++、Java、C#はもちろん、Python、Ruby、PHP、Perlなども挙げられるでしょう。 一方、向学のためという人や、学術研究や起業に関心がある人にとって、次の言語を選ぶ基準となるのは、就職に有利かではなく言語の表現力でしょう。学術研究や起業活動を行うには、プログラマとしての能力を何倍にも高める必要があります。そして、(おそらく)確立されたコードベースを扱った経験はないでしょうから、手元にあるタスクにとって最適な言語を自由に選ぶことができます。 この記事では、勉強に適したHaskell、Scala、ML、Schemeという4つの言語を、私の好きな特徴や参考資料のリストと
先週末、はてな社内の勉強会で構造学習、特に実装が簡単な構造化パーセプトロンについて発表しました。発表資料と説明用にサンプルで書いたPerlの品詞タグ付けのコードへのリンクを張っておきます。 今日からできる構造学習(主に構造化パーセプトロンについて) from syou6162 structured_perceptron/structured_perceptron.pl at master · syou6162/structured_perceptron 「えっ、Perlかよ」という人がいるといけないので、Clojureで構造化パーセプトロンを使った係り受け解析のサンプルコードへのリンクも張っておきます(2種類あります)。PerlもClojureもあれば8割くらいの人はカバーできそうなので、安心ですね。 syou6162/simple_shift_reduce_parsing syou616
※以前の採用ページは楽しかったのですが、冗談が過ぎるので普通のページにしました。楽しんでいただけた皆様、ありがとうございました。以前のページはこちら サービスも製品も全て自社開発。自ら考え、次々に機能を追加していく— 全く新しいコンセプトの今までにない新しいシステムを共に開発しませんか? 類い稀なるスピードで継続開発していくことが求められるこのスタートアップ環境で、その力を発揮してください。 技術的には色んなものを取り扱っておりますが、今のメインは Nix + Haskell + Elm です。 ご興味あるかたはぜひご連絡ください。 ソフトウェアエンジニアリングでのインターンシップも募集しておりますので、エントリーください。 必須条件 アプリケーションを企画・設計から実装・テストまで一貫して行った経験 Haskell、Lisp、OCaml、Erlang、Clojure、Julia、Elmの
プログラミング言語ランキングより:2016年 動向を見守るべき言語は Elixir、Julia、Rust、Swift、TypeScriptRustTypeScriptElixirJuliaSwift 最新のRedMonkプログラミング言語ランキング1 によると、Swiftの成長ぶりと潜在的なポテンシャルは驚異的とのことだ。GoとSwiftは、トップ10に食い込む可能性もあると見られている。 また、トップ20圏外にいるが、今後の動向を見守るべき言語として、Elixir、Julia、Rust、TypeScriptが挙げられている。 ベストランキング 開発者が採用するプログラミング言語を調べるために、RedMonkはStack Overflowのディスカッション数や、GitHubで使用されている言語を分析している。RedMonkのアナリストおよび共同創設者のスティーブン・オグレディは、その結果を
概要 いま、ズンドコブームが来てます。 Javaの講義、試験が「自作関数を作り記述しなさい」って問題だったから 「ズン」「ドコ」のいずれかをランダムで出力し続けて「ズン」「ズン」「ズン」「ズン」「ドコ」の配列が出たら「キ・ヨ・シ!」って出力した後終了って関数作ったら満点で単位貰ってた — てくも (@kumiromilk) March 9, 2016 非常にセンスが良いですね! 巷では「ズンドコキヨシ」「キヨシチェック」「ズンドコチェック」などと呼ばれているようです。 さまざまなズンドコキヨシ プログラミング言語系 ズンドコキヨシ with Ruby by @yancya 無限に'ズン'と'ドコ'をランダムに返すEnumeratorを使ってるのがいいですね ワンライナーズンドコキヨシ with Ruby by @from_kyushu 毎回 'ズン'と'ドコ'のランダムな5つの組み合わせを
Visual Studio Users Community Japan #1 で発表した資料になります。 https://vsuc.connpass.com/event/143114/
他のフレームワークやライブラリから React に乗り換える人たちは、「ReactはUIのレンダリングに関する問題しか解決しておらず、状態管理とアプリケーションアーキテクチャの選択は開発者に委ねられているのだから、どうやってアプリケーションの状態を管理したらいいのか?」 と疑問に思う傾向があります。FacebookはReactのレンダリングモデルに適している、 Flux と呼ばれるアーキテクチャを勧めています。 この記事では、UIレイヤとしてReactを用いてJavaScriptのアプリケーションの状態を管理する方法を探り、 Om のような ClojureScript ライブラリのアイデアを用いてFacebookのFluxの抽象的なフレームワークを作り変えてみたいと思います。 Fluxの核となる考えは、 データは一方通行で流れるべき というものです。これによってアプリケーションの論証が簡単
2013-06-24 2012年4月23日にテキサスの Austin で行われた RailsConf 2012 での Rich Hickey (@richhickey) さんによる基調講演、Simplicity Matters を書き起こして翻訳しました。 Rich Hickey さんは Clojure や Datomic の作者です。 この翻訳は Creative Commons Attribution ShareAlike 3.0 ライセンスに基いて公開します。 Rich Hickey 講演 e.e d3si9n 訳 談: こんにちは。ご招待いただきありがとうございます。 聞く所によると RailsConf はいつもコミュニティーからかなり外れた人を選ぶらしく、今回は僕ということになりました。 僕の電話ボックスは外に駐車してあります。(会場、笑) だけど、今日は言語の壁を越える話題を持
たまたま、goで書かれた物をperlへ移植しようとしていたらsplitの挙動の差が出てきまして、他の言語の場合どうなるんだろうとぱっと思いついた言語で実行して見ました。以下の文字列を言語標準でついている文字列のsplitを実行した結果となります。 "/path/to/hoge/" 言語 結果 perl(5.12) ['','path','to','hoge'] golang(1.5) ["" "path" "to" "hoge" ""] ruby(2.1) ["", "path", "to", "hoge"] ptyhon(2.7.8) ['', 'path', 'to', 'hoge', ''] js [ '', 'path', 'to', 'hoge', '' ] perl6 ("", "path", "to", "hoge", "") # (perl6-m -e 'say "/pat
7/27に開かれたLisp Meetup #30で「Clojureシンタックスハイライター開発から考えるこれからのLispに必要なもの」というタイトルで話してきました。 Clojureシンタックスハイライター開発から考えるこれからのLispに必要なもの from sohta 内容としては、去年のShibuya.lispのテクニカルトークで話した内容を重点をズラして焼き直したものです。終わった後にいくつか意見をいただきましたが、絶対数は多くないのでどう受け止められているのかはちょっと気になるところです。 「これからのLispに必要なもの」とタイトルにはあるものの、具体的に「これが必要だ」と言えてないのが残念な感じですが。。。この発表でいいたかったのは、「LispコードをCASEツールで解析できる対象にしていきませんか」という提案です。 ICSE勉強会なんかの話を聞いていると、他の言語(特にJ
調査への回答を行ったユーザーの年齢のうち、もっとも多かったのは25~29歳(28.5%)で、20~24歳(24.5%)、30~34歳(17.8%)が続く。国別の平均年齢では、アメリカが31.6歳、イギリスが30.3歳、カナダが30.3歳などとなっており、男性が9割以上を占めている。 プロフェッショナルのプログラマとしての経験は、2~5年(32.4%)がもっとも多いが、11年以上(24.2%)、6~10年(23.2%)と経験豊かなユーザーが多いことがわかる。なお、男女の比較では、女性は2年以内、男性は2~5年がもっとも多いという結果であった。 プログラミング技術の習得方法に関する質問では、自分で学習したユーザー(41.8%)が最多で、コンピュータサイエンスの学士課程(37.7%)、業務におけるトレーニング(36.7%)がそれに続く。 本来の業務とは別のプロジェクトや、オープンソースプロジェク
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く