The Wrong Abstraction — Sandi Metz
I originally wrote the following for my Chainline Newsletter, but I continue to get tweets about this idea, so I'm re-publishing the article here on my blog. This version has been lightly edited. I've been thinking about the consequences of the "wrong abstraction." My RailsConf 2014 "all the little things" talk included a section where I asserted: duplication is far cheaper than the wrong abstract
電王・Ponanza開発者が語る、理由がわからないけどスゴイ“怠惰な並列化”
皆さんこんにちは。 私は将棋プログラム「Ponanza」の作者、山本一成と申します。Ponanzaは初めてプロ棋士を破った将棋プログラムで、近年最も強い将棋プログラムと言えると思われます。また、2017年もトッププロ棋士の方と対局することが予定されています。Ponazaの改良のための機械学習に現在ジサトライッペイさんのPC「大紅蓮丸」の計算リソースを借りているのですが、その関係で原稿を書いてとお願いされたので、3回に渡って将棋プログラムの今について、書いていきたいと思います。 フリーランチの終焉、並列化の効率問題 アスキー読者の方々には言うまでもないのですが、まずは近年のCPU事情について解説していきたいと思います。ちょっと昔まではCPUはシングルコアが当たり前で18ヶ月経過すればCPUのトランジスター数は倍になり、性能が向上するという流れが続いていました。ソフトウェアはその性能向上に伴い
The Elixir programming language
All Elixir code runs inside lightweight threads of execution (called processes) that are isolated and exchange information via messages: current_process = self() # Spawn an Elixir process (not an operating system one!) spawn_link(fn -> send(current_process, {:msg, "hello world"}) end) # Block until the message is received receive do {:msg, contents} -> IO.puts(contents) end Due to their lightweigh
プログラミング言語Rust
注意: 最新版のドキュメントをご覧ください。この第1版ドキュメントは古くなっており、最新情報が反映されていません。リンク先のドキュメントが現在の Rust の最新のドキュメントです。 プログラミング言語Rust ようこそ!この本はプログラミング言語Rustの教材です。Rustは安全性、速度、並行性の3つのゴールにフォーカスしたシステムプログラミング言語です。 ガーベジコレクタなしにこれらのゴールを実現していて、他の言語への埋め込み、要求された空間や時間内での動作、 デバイスドライバやオペレーティングシステムのような低レベルなコードなど他の言語が苦手とする多数のユースケースを得意とします。 全てのデータ競合を排除しつつも実行時オーバーヘッドのないコンパイル時の安全性検査を多数持ち、これらの領域をターゲットに置く既存の言語を改善します。 Rustは高級言語のような抽象化も含めた「ゼロコスト抽象
私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログ
私はソフトウェアの専門家としてお答えすると、ウォータフォールは何のメリットも無いというのが私の意見であることを共有しておきたい。そういう意見に至った経緯をこのブログで書き留めて置きたい。 尚、これは所属会社の見解ではないことは明確にしておきます。 サム・グッケンハイマーの一言 私は DevOpsのエバンジェリストで、それ以前からアジャイル開発をかれこれ１５年ぐらい実施し、導入の支援をしている。私はかつては、日本の環境の制約の中で如何にアジャイル開発のメリットを最大に引き出すか？ということを考えていた。 ウォーターフォールに対する立場も、真っ向から否定するものでもなく、現状もあるし、それに慣れている人もいるし、実際ウォーターフォールでも失敗しない人も居る。だから、人にウォータフォールのメリット・デメリットを聞かれた時も「変化しないものに関してはウォータフォールはいいのかもしれない」と回答して
「それ、アジャイルできてへんのちゃいますか？」チェックリストの公開 - メソッド屋のブログ
DevOps を導入して、リードタイムの短縮などの効果を出したい時に、前提条件となっている「アジャイル」がまだ導入できていないケースが多い。そういったケースでは、まずアジャイル導入のご支援をすることもよくある。 そういった支援に入ると、「アジャイル導入前提」で構成されたはずのプロジェクトであっても、全然「アジャイル」のポイントを外しているというケースは珍しくない。更に問題なことに、「アジャイルをできます！」と言っているベンダーさんを連れてきても、全然ポイントを外しているというケースすら珍しくない。今回のブログではそういったケースでも、簡単に確認できる、「アジャイルになっていないかもしれない簡単なチェックポイント」を対策付きでいくつかご紹介しよう。 スプリントの中で、ウォータフォールを実施するのではない。それはミニウォータフォールというバッドプラクティスだ。 1. 進化型設計ができていない
関数型プログラミングはオブジェクト指向の正当な後継である - Qiita
この記事の補足を書きました。併せてご覧いただけると幸いです。 「関数型プログラミングはオブジェクト指向の正当な後継である」がわからない理由 対象読者 この記事はオブジェクト指向設計を本格的に学びドメイン駆動設計や責務駆動設計等を実践したことがある人々に「オブジェクト指向と関数型プログラミングの関係」を深く知ってもらうことを目的としています。これらの人々の中には手に馴染んだオブジェクト指向に未だに固執している人や、関数型プログラミングが気になってSwiftやScalaを触り始めているがイマイチ関数型プログラミングの本質が見えていない人も多いと思います。そうした人々が次の一歩を踏み出すキッカケになれば幸いです。 なぜこの記事を書こうと思ったのか？ IT系の情報サイト等で「Haskellがすごい」という記事を見かけるようになってからもう10年近く経とうとしています。私自身もこれまでに何度か関数型
JavaScriptをOCamlから生成するトランスパイラ「BuckleScript 1.0」、米ブルームバーグがオープンソースで公開。TypeScriptよりタイプセーフかつ効率的で高速と
JavaScriptをOCamlから生成するトランスパイラ「BuckleScript 1.0」、米ブルームバーグがオープンソースで公開。TypeScriptよりタイプセーフかつ効率的で高速と 金融情報などの提供を行っている米ブルームバーグは、OCamlのコードからJavaScriptのコードを生成するトランスパイラ「BuckleScript 1.0」をオープンソースで公開しました。 BuckleScriptはTypeScriptやBabelJSなどからインスパイヤを得て開発されたと説明されていますが、最大の特徴はTypeScriptなどが独自の構文を備えているのに対し、BuckleScriptは既存の言語であるOCamlを採用しているところです。 OCamlはオブジェクト指向型と関数型の両方の特長を備え、特に海外では金融系システムの開発でよく使われているプログラミング言語です。 Buckl
Haskellと共に4年間を歩んだ起業家の視点 | POSTD
(訳注：2017/11/17、頂きましたフィードバックを元に記事を修正いたしました。) 2012年、私は 新しいタイプの企業向けeラーニングプラットフォーム を開発するスタートアップ、Better ^(1) を共同設立しました。私たちのゴールは、大企業が、適応力の高いクロスプラットフォーム、多言語のオンラインコースを、速く安く開発、配信、解析できるようにすることでした。 立ち上げ初日にメインで使うと決めたHaskellは、チームが開発者10人を抱えるようになった時もバックエンドで使い続けていた唯一の言語でした。 実験と開発の期間を経て、Betterは数か月の間にAmerican ExpressやSwissportを始めとする顧客を得て、$0から$500,000超の年間経常利益を上げるまでに成長しました。しかし、更なる成長を目指すためには配信モデルが妨げになることが分かったため、最終的にオー
npm、一見無意味なパッケージを消したら1000件ものパッケージが依存するパッケージであったことが判明
npm、一見無意味なパッケージを消したら1000件ものパッケージが依存するパッケージであったことが判明 npmが一見無意味に思えるfsというパッケージをSPAMとみなして削除したところ、1000件ほどのパッケージが依存するパッケージだったので、削除を取り消した。 npm, Inc. Status - "fs" unpublished and restored 今日、数分ほど、"fs"というパッケージが、ユーザーからSPAMであるという報告を受けて、レジストリから非公開にされた。これは現在復旧されている。これは私(@seldo)による人為的なミスである。私は非公開が安全であるかを確認する内部のガイドラインに従っていなかった。ビルドが阻害されたユーザーに謝罪する。 詳細："fs"というパッケージは、無意味なパッケージである。これは単に"I am fs"をログに残して終了する。このパッケージが何
子どもだけではなく全ての日本国民にとってプログラミングが重要である、たった1つの理由
特集：小学生の「プログラミング教育」その前に 政府の成長戦略の中で小学校の「プログラミング教育」を必修化し2020年度に開始することが発表され、さまざまな議論を生んでいる。そもそも「プログラミング」とは何か、小学生に「プログラミング教育」を必修化する意味はあるのか、「プログラミング的思考」とは何なのか、親はどのように準備しておけばいいのか、小学生の教員は各教科にどのように取り入れればいいのか――本特集では、有識者へのインタビューなどで、これらの疑問を解きほぐしていく。 今回はビジュアルプログラミングツール「Viscuit」の開発者である原田康徳氏に話を伺った。 コンピュータとは何か――共生のためには子どもだけではなく大人も学ぶべき 「『2045年にシンギュラリティ（技術的特異点）が起こり、人間の仕事が人工知能つまりコンピュータに奪われる』『人類がコンピュータに支配される」などとよくいわれて
Oregon Programming Languages Summer School
Oregon Programming Languages Summer School — July 22-August 3, 2013 Types, Logic, and Verification Speakers Organizers Curriculum Schedule Participants Coq Preparation and Boot Camp Several of the course lecture sequences will assume basic familiarity with the use of the Coq proof assistant. In particular, the lecture sequence Software Foundations in Coq, based on the book of the same name [availa
なぜ採用される言語とされない言語があるのか | POSTD
私の 前回の記事 では、 Heartbleed バグを早めに見つけられないことは、ある意味で改良とデプロイの失敗となると論じました。そうでなければ、これは静的解析にとって効果的なテクノロジーです。特に、商業的な静的解析ツールは故意に潜在バグを無視しますが、これは間違ったアラームが大量に報告されるのを避けるためです。つまり、健全性よりも完全性が好ましいということです。このようなツールを作る企業は、利益になるサービスを好況市場に提供することを狙いとしており、彼ら独自の調査では健全性は売れ行きに関して重要ではないということが示されています。その代わり、生き残るためには、本当に重要なバグを開発者が効率的に発見する手助けになるツールでなければいけません。全てのバグの検出は必要ないのです。リサーチャーの挑戦は、効率（それと、その他の望ましい基準）を維持しながら、健全性に背を向けてビジネス案を推進する方
オーディオアプリ開発でありがちな4つの間違い | POSTD
ここで論じているのは、オーディオアプリの開発者が陥りがちな 4つの間違い 、 より良く開発する方法 、 問題個所の発見方法 です。主に開発者向けの内容ですが、開発者以外の方にも知っておいてもらいたいと思います。ここでは、開発者向けの診断ツールである Realtime Watchdog を紹介し、 人気のあるオーディオライブラリの調査結果 を提示します。 オーディオアプリの開発はとてつもなく楽しいです。やりがいを感じるし、創造力を発揮できる範囲が大きく広がり、ひとたび開発が終われば、 誰かがクリエイティブなツールとして使ってくれるのです！ こんな分野は多くないし、この領域で働けるなんて非常に幸運だと自分でも思っています。 しかし、仕事でオーディオアプリを扱う時には深く考えなければならない部分もあります。オーディオアプリの開発者としてユーザに対する責任があるのです。大前提として、ユーザを公共の
C++11スマートポインタで避けるべき過ち Top10 | POSTD
(注：2017/10/25、いただいたフィードバックを元に翻訳を修正いたしました。修正内容については、 こちら を参照ください。) 私は新しいC++11のスマートポインタをとても気に入っています。自分でメモリを管理するのが嫌だと感じる多くの仲間たちにとって、これはいろいろな面で天の助けでした。私の場合、このおかげで新人にC++を教えるのがずっと楽になりました。 しかし、C++11のスマートポインタを幅広く使っていた2年ちょっとの間で、使い方を誤ると、プログラムの効率が落ちたりクラッシュして壊れたりするという事態に何度も遭遇しました。参照用に、以下に例を載せました。 まずはこれらの”過ち”を、簡単なAircraftクラスを例に取って見てみましょう。 class Aircraft { private: string m_model; public: int m_flyCount; weak_p
コードレビューのベストプラクティス | POSTD
Wiredrive では、私たちはかなりの数のコードレビューを行います。しかし、ここで働き始める前には私はコードレビューなどしたことがありませんでした。今回は、私がコードレビューをする時に何に注目するようにしているかや、私の考え出したベストなコードレビューのやり方をお話したいと思います。 コードレビューとは、簡単に言うと2人以上の開発者で問題を引き起こしそうなコードの修正について話し合うことです。コードレビューをすることのメリットについては多くの記事で語られており、知識を共有できること、コードのクオリティが上がること、開発者が成長できることなどが挙げられています。しかし、レビューを行う上で、どのように進めていくかという具体的なことについてはあまり多く語られてないように私は思いました。 レビューで何に注目するか アーキテクチャ/デザイン 単一責任原則 : 1つのクラスは変更する理由が2つ以上
コードの品質を維持したまま開発スピードを上げる | POSTD
高品質のコードベースは、反復作業やコラボレーション、メンテナンスを簡単にすることで、長期的な開発のスピードを上げてくれます。Quoraではベースコードの品質は重要だと考えます。 高品質のコードを維持することは利点がありますが、その反面かなりのオーバーヘッドが発生し、実際の開発のサイクルに時間が掛かってしまいます。このオーバーヘッドと利点の折り合いを付けるのは難しい問題です。この場合、2つの選択肢しかないように思えます。低品質でコードスピードが速いか、もしくは高品質でスピードが遅いか。スタートアップは素早い開発サイクルに最適化しているので、多くの人は低品質で進めたほうがいいと思っています。 このジレンマは解消できます。ツールやプロセスを工夫することで、コードベースの品質を維持したままスピードを速めることができるのです。この投稿では、コードの品質に関しての私たちの考えや、2つの世界を共存させる
アーキテクチャよりも設計を重視しよう – 米政府18Fチームの提案 | POSTD
注釈： CASH LAYER：キャッシュレイヤ FRONT END：フロントエンド ASSET SERVE：アセットを供給 WEB SERVER W/ROUND ROBIN FAILOVER：ラウンドロビンとフェールオーバーを実装したWebサーバ THE CLOUD：クラウド ALL READS! ：全ての読み込み WRITES：書く READS：読む MASTER：マスタ INPORTANT POINTY THINGS：重要な鋭い情報 MULTI MASTER DB CLUSTER：複数のマスタからなるデータベースの集合体 「エンジニアはまずアーキテクチャの全体像から始めるべき」、というのが先人たちの知恵からの教訓となっています。データベースを使ったサービスが他のサービスと関係する様子を、線や矢印で表したのが上の図です。キャッシュレイヤ、ロードバランサ、その他の複雑な形も上図の情報フロー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
開発者を苦しめる.NETのHttpClientのバグと紛らわしいドキュメント
「なぜDI(依存性注入)が必要なのか？」についてGoogleが解説しているページを翻訳した - Qiita
