パイプライン演算子の歴史 - まめめも
(You can read this article in English.) Ruby の開発版にパイプライン演算子（pipeline operator）が試験的に導入されましたが、いろいろあってプチ炎上になっています（チケット）。 せっかくの機会なので、パイプライン演算子の歴史を調べてみました。付け焼き刃の調査なので、間違ってたら教えてください。 パイプライン演算子とは こんな感じのものです。 x |> f |> g |> h # h(g(f(x))) と同じ意味 h(g(f(x))) という関数適用の式は、関数が呼ばれる順序（f→g→h）と、プログラムの字面上の順序（h→g→f）が逆でわかりにくいとされます。この問題は、特に、関数が大きくなったときに顕著になります。 wonderful_process_h( marvelous_process_g( fantastic_process
動的計画法超入門！ Educational DP Contest の A ～ E 問題の解説と類題集 - Qiita
0. はじめに: 非常に素敵な DP の入門コンテンツ 待ちに待ったコンテストの到来です！！！！！ DP (動的計画法) はアルゴリズムの登竜門というべき難所ですが、いくつか問題を解いて行くとパターンのようなものが見えて来ます。まさに「習うより慣れろ」の世界で、たくさん問題を解いて行くうちに、DP な問題の解法を一言で言えるようになって来ます。 典型を学ぶ方法論として、その最も典型的なシンプルな形をした問題をそのまま吸収してしまうのは 1 つの有効な方法だと思います。それにふさわしいシンプルな問題たちを集めた DP コンテストが先日開かれました。DP 以外にもこういうのが欲しい気持ちになりますね。 Educational DP Contest / DP まとめコンテスト 全部で A 問題から Z 問題まで 26 問あります。今回はこれらの問題に対し 簡単なコメントや解説、その他の解説へのリ
Best of 2018 in Tech Talks
For the past two years, I’ve been publishing a list of my favorite tech talks from the previous year (here’s the 2016 edition of this post and here’s the 2017 edition). This list isn’t by any means comprehensive and I’m certain there are many tech talks from 2018 that I’ll only discover much later. But among the talks I attended or watched, these were some of the best (in no particular order). The
Programming Fonts - Test Drive
Size / ↑ ↓ Theme Language // Type some code -> console.log "oO08 iIlL1 g9qCGQ ~-+=>"; function updateGutters(cm) { var gutters = cm.display.gutters, __specs = cm.options.gutters; removeChildren(gutters); for (var i = 0; i < specs.length; ++i) { var gutterClass = __specs[i]; var gElt = gutters.appendChild( elt( "div", null, "CodeMirror-gutter " + gutterClass ) ); if (gutterClass == "CodeMirror-line
Sebastian Aaltonen氏のプログラミング観 - Qiita
とても勉強になったので写経のつもりで翻訳しました。 普段自分でもわかっている気がするけど言語化するのが難しかったこと、自分でやっていて確かにあとから痛い目を見たかもしれないと反省を促される内容でした。 ※ゲームプログラミング特有だなと感じた内容はきちんと理解できなかったので割愛しています。 Now that people have already said highly controversial stuff like ”debugger is useless for C++ development”, I think I can share my own controversial thoughts about unit testing, DRY, copy-paste coding and function length, etc... with 20 years of C++ pro
太一のコードの読み方メモ
太一のコードの読み方メモ 全体として太一が感覚的に実践している事を論理的に説明しようと試みている為、 説明の粒度が適切でなかったり一貫性が無いように見える部分があるかもしれない。 普段やっているけども書ききれていない事も多分きっとある。 コードを読むとは何か コードを嗜む コードを学ぶ 武器を手に入れる これは武器を手に入れるコードリーディングの話 武器とは何か プロジェクトで戦う為の道具となる知識 プロジェクト内における技能を示す為の道具となる知識 プロジェクトのやり方を自ら決められる様になる為の道具となる知識 権限と責任がバランスよく割当てられた時モチベーションは最大化する 何と戦うのか プロジェクトリスク プロジェクトをより良い状態にする為の基礎的な根拠となるのがコードである コードが全てではないが適切に動作するコードが無ければプロジェクトは終わらない これはつまり理想を体現する為の
型システム 〜プログラムの安全性を支える数学〜 - Laborify
京都大学大学院 情報学研究科 通信情報システム専攻 修士2回生の五十嵐雄です．大学では，プログラミング言語理論，その中でも特に型システムの研究をしています． この記事では，私が特に力を入れて研究している漸進的型付けという種類の型システムについて紹介します．プログラムや型システムといった基本的な概念から解説していくので，プログラミング経験のない人も安心して読み始めてもらえたらと思います． はじめに プログラムとはコンピュータへの命令を記述したものです．2018年現在，私たちの生活は数多くのプログラムに支えられています． あなたがこの記事を Windows が入ったパソコンで見ているなら，まずその Windows がプログラムです．お家にテレビや冷蔵庫があれば，それらの中にもプログラムが内蔵されているでしょう．空いた時間にスマートフォンでゲームをするなら，遊んでいるゲームも全てプログラムです．
JITあれこれ | κeenのHappy Hacκing Blog
κeenです。遅刻してしまいましたがこのエントリーは 言語実装 Advent Calendar 2018 1日目の記事です。 最近私の観測範囲内でJITが流行っているのですが一口にJITと言っても色々あるよなーと思ったので私がJITについて知っていることをグダクダ話します。 このブログでも何度がJITや周辺技術について取り上げてますが話の流れがスムーズになるので最初から説明していきます。 2018-12-03: 加筆修正しました。差分はこちら JITって？ Just in Time(コンパイル)のことで、日本語にすると「間に合ってコンパイル」になりますかね。 インタプリタの高速化テクニックの1つです。 最初はインタプリタのようにコードをコンパイルせずプロセスが起動しますが、メソッドを実行するまでにはメソッドをコンパイルして、ネイティブコードで実行する方式です。 本来ならJITはこのような意
問題解決力とコーディング力を鍛える 英語のいろは：書籍案内｜技術評論社
2018年11月23日紙版発売 2018年11月23日電子版発売 鈴木達矢 著 A5判／192ページ 定価2,178円（本体1,980円＋税10%） ISBN 978-4-297-10247-0 Gihyo Direct Amazon 楽天ブックス ヨドバシ.com 電子版 Gihyo Digital Publishing Amazon Kindle ブックライブ 楽天kobo honto この本の概要 「最新の技術を勉強したいけど，苦手な英語とどう向き合えばいいのかわからない」「とにかく効率的に必要な英語力だけを身につけたい」「もっと端的なクラスの命名ができるようになりたい」など，英語を勉強する際に悩んだことはないでしょうか。 本書では，英語の苦手な方でも読み始められるように，日本語と英語を比較しながら「エンジニアが本当に使える英語」を紹介します。かんたんな文法の復習をはじめ，インプット
Koka - Microsoft Research
Koka is a strongly typed functional-style language with effect types and handlers. The core of Koka consists of a small set of well-studied language features, like first-class functions, a polymorphic type- and effect system, algebraic data types, and effect handlers. Each of these is composable and avoid the addition of “special” extensions by being as general as possible. Koka tracks the (side)
Algebraic Effects 自習用資料まとめ
俺は OCaml が好きだ。俺は Reason が好きだ。Algebraic Effects はもっと好きだ。 最高のリポジトリEffects bibliography: https://github.com/yallop/effects-bibliography もうこれだけあればいいんじゃないか？ってくらい言語実装と論文がまとまってる。あとは「OCaml Weekly News」とかにEffect関連の発表とか論文が紹介されてたりする。ICFPもEffect関連増えてる。 論文・An Introduction to Algebraic Effects and Handlers by Matija Pretnar Effを作った人。Computational Effectsの導入にあたって、Effect Handlerを扱えるようなコンパクトな追加の言語仕様を定義してそれをもとに入出力と
A Look at the Design of Lua – Communications of the ACM
Lua is a scripting language developed at the Pontifical Catholic University of Rio de Janeiro (PUC-Rio) that has come to be the leading scripting language for video games worldwide.3,7 It is also used extensively in embedded devices like set-top boxes and TVs and in other applications like Adobe Photoshop Lightroom and Wikipedia.14 Its first version was released in 1993. The current version, Lua 5
20 万行超のコードベースをテストせずにリファクタリングリリースした話 - MonotaRO Tech Blog
こんにちは、鈴木です。 20 万行を超えるアプリケーションのほとんど全てのソースコードを変更し、テストを行わずに本番リリースしました。 「それってテストいるんですか？」問題 いきなりですが質問です。ソースコードを 1 バイトでも変更したら再テストする必要はあるでしょうか。「絶対に再テストすべき」という方もいれば、「状況によるしケースバイケースかな・・」という方もいらっしゃると思います。 ケースバイケースと考える方は、どのような場合にテストを行わなくて良いと考えるでしょうか。例えば、コメント内の誤字を修正した場合はどうでしょうか。ローカル変数の名前を typo していたので修正した場合、デッドコードを削除した場合はどうでしょうか。 こんなことがありました ある日、Python のソースコードを眺めていると、「# $Id」のような CVS 時代のコメントがありました。いまやソースコードは Gi
プログラミングと女性の歴史
Sep 17, 2018 ソフトウェアエンジニアの分野で活躍する女性がもっと増えてほしいという議論が日本だけでなくさまざまな場所で行われています。 数字で正確に推し量る事は難しいですが、やはり男性が多数を占める業界であるという認識が共有されています。 2013年にサンフランシスコで行われたJessica Lynn Suttlesさんの講演は個人的に目からウロコの内容でした。 歴史を紐解いて見ると、プログラミングへの大きな貢献を残した女性は数多く「女性が切り開いた業界」であるという一面があります。今回は海外で行われた講演や記事から読み取れる内容をまとめます。 その後、Ruby On Alesにてほぼ同じ内容の講演が行われこちらはアーカイブが残っています。(関係ないですが、confreaksはいいサイトですね。) The History of Women in Programming 世界初の
エンジニアを育てる環境と、コミュニティのありかたについて - blog.8-p.info
エンジニアを育てるはなしが、たぶん以下の Takuto Kihira さんの tweet をきっかけに盛り上がっていた。 昨日の飲みで、某CTOが「エンジニアを育てるって言うけど、紀平さん誰かに育てられました？自分で育ったでしょ？だからエンジニアに対しては、頑張れ、としか言いようがないと思うんですよね」って話をしていて、まあ確かにそうだと思った。自分はしかし親に環境を用意してもらったな。本とかPCとか。 私の立場は、Dai MIKURUBE さんの tweet に近い。 エンジニアの成長について「自分は自力で育った」「今まで見てきた人は誰かに育てられたというより自力で育ってきてた」は観察としてたぶん真なんだけど、「だからこれからもそれでいい」は明確に偽だと思うんだよなー。それって各種の職人業が次々廃れてるのと同じことを再現するだけのような気がする 私自身も大学で情報工学を学ぶまえに多少はプ
American Fuzzy Lop internals - ちょっとずつ成長日記
American Fuzzy Lopのソースコード解析 ここ最近のAmerican Fuzzy Lopに対してオレオレ実装した過程でソースコードを解析したので、その結果をブログにまとめてみようということで書いてみました。ソースコードの解析しているようなブログなどはとくにみたことがない(2018/03/19時点)ので書く価値があるのかなという自己満足で書いてみました American Fuzzy Lopとは American Fuzzy LopはGoogleのエンジニアである、Michal Zalewski氏らによるfuzzing toolである。fuzzingとはざっくりいうと「自動でバグ、脆弱性を見つけようぜ」というものである。 有名なところで言うとCGC(Cyber Grand Challenge)でコンピュータ同士の攻防でfuzzingが使われていたりする。またここ最近の出来事として
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ID生成方法についてあれこれ - Qiita
GitHub - ponylang/ponyc: Pony is an open-source, actor-model, capabilities-secure, high performance programming language
GitHub - tau-prolog/tau-prolog: An open source Prolog interpreter in JavaScript
The “No New Rationale” rule | alvinalexander.com