タグ

2015年5月26日のブックマーク (13件)

  • GitHub - unassert-js/babel-plugin-unassert: Babel plugin to encourage reliable programming by writing assertions in production code, and compiling them away from release.

    You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

    GitHub - unassert-js/babel-plugin-unassert: Babel plugin to encourage reliable programming by writing assertions in production code, and compiling them away from release.
    t-wada
    t-wada 2015/05/26
    Design by Contract (DbC) を支援するためビルド時に表明(assertion)を除去する Babel プラグインを書きました。 id:ledsun browserify 版も作りました。アドバイスありがとうございます! https://github.com/twada/unassertify
  • ES6 Modules 間では export/import された変数(?)は同期される - Qiita

    import { foo, bar } from './foobar'; console.log(foo); bar.changeFoo(); console.log(foo); babel-node index.js と実行すると Foo Bar と 出力されます。Foo Foo ではありません。Node.js で CommonJS を書いていた人からすると、???となる挙動ですね。index.jsでの foo はただの変数ではないのです。 CommonJS なら・・・ CommonJS で素直に同じようなモジュールを書こうとすると、以下のようになると思います。これだと当然 Foo Foo と出力されますね。bar.changeFoo() を呼んでも foobar.js の module.exports.foo も更新されませんし、index.js の foo も更新されません。

    ES6 Modules 間では export/import された変数(?)は同期される - Qiita
    t-wada
    t-wada 2015/05/26
    おっ、これは盲点だった……
  • PHP7で変わること - hnwの日記

    次の土曜日5/30のPHPカンファレンス関西2015で基調講演(10:30-11:15)をさせて頂くことになりました。タイトルは「PHP7で変わること——言語仕様とエンジンの改善ポイント」です。チケットは既に売り切れているそうですが、参加者の方は早起きして来て頂けると幸いです。 このところQiitaに「PHP7調査」というシリーズを連投していたのも発表を意識してのことです。PHP7の新機能を一つずつ実際に試してみて、その結果を簡単にまとめていました。 今回は発表前の区切りとして、私の書いたPHP7関連の記事・プレゼン資料を一覧形式でまとめなおしてみます。PHPカンファレンス関西2015ではこれらの内容を踏まえつつ、気になる点を重点的にお伝えしたいと考えています。 内部実装のリファクタリング PHP7の目玉と言える、速度改善に関わる内容がほとんどです。 PHP7はなぜ速いのか - Slide

    PHP7で変わること - hnwの日記
    t-wada
    t-wada 2015/05/26
    PHP7 は内部実装のリファクタリングと速度改善がメイン。それでも新しい機能もいろいろ入っている。
  • 破れ紙の片割れのようなMixinができてしまうワケ - @kyanny's blog

    最近「Mixin は避けられれば避けたほうがよいのではないか」と思い始めている。扱いに困るダメ実装の Mixin を簡単に作れすぎてしまうからだ。 Wikipedia の定義によると、 mixin とはオブジェクト指向プログラミング言語において、サブクラスによって継承されることにより機能を提供し、単体で動作することを意図しないクラスである。 とのことなので、そもそも Mixin される側の実装と結びつきが強くなるのは仕方ないのだろう。しかし、まれにだが破れ紙の片割れのような実装を持つ Mixin ができてしまうことがある。 一枚の紙を適当に手で破って二枚にする。断面はギザギザだが、破った二枚の紙の断面はぴったり一致する。もともと繋がっていたものを切り離したのだから当然だ。だが破れ紙の断面にぴったり合うような別の紙を用意するのは簡単ではない。別の紙を合わせる必要があるのならば、紙を破るときに

    破れ紙の片割れのようなMixinができてしまうワケ - @kyanny's blog
    t-wada
    t-wada 2015/05/26
    "ダメなMixinは破れ紙の片割れに似ている。Mixinされる側と合わさって初めて用をなすが、断面(インタフェース)がギザギザに入り組んでいるので、新しくMixinを適用したいクラスを作るのが非常に難しくなる"
  • スケーラブルなプログラミングのために何が必要か - ジンジャー研究室

    Fluxに関する独自解釈と妄想を、何かの翻訳っぽく書いた。 スケールするアーキテクチャ フレームワークを作る時、我々は「簡単に記述する」ことを第一に考えがちだ。 そして、簡単にするための仕組みはウケる。 逆に記述量が増えるとウケない。 しかし例外があって、多く書くことによるメリットが受け入れられたときは別だ。 例えば、Backbone.jsを使うと記述量が増える事は誰もが認めるところだが、MVCの実現というメリットのために広く受け入れられた。 要するにトレードオフなのだ。 ここのところFluxアーキテクチャが注目を浴びているが、書いてみると記述量は相当増える。 そもそも登場人物が多すぎる。 Action、Dispatcher、Store、View、それからそれらの間に挟まって仕事をする者達。 一体彼らは何をしたいのか。 最近になって分かってきた。 これはアプリケーションそのものを抽象化した

    スケーラブルなプログラミングのために何が必要か - ジンジャー研究室
    t-wada
    t-wada 2015/05/26
    Flux がなぜフレームワークではなく「アーキテクチャ」なのかが考察されている
  • What is Gradual Typing: 漸進的型付けとは何か - Qiita

    稿は Python に型アノテーションを追加するという PEP 483 - The Theory of Type Hinting の提案で参照されている Jeremy Siek (@jeremysiek) 氏と Walid Taha 氏が開発した漸進的型付けについての入門記事の翻訳です。 What is Gradual Typing Python 3.5 で導入された型アノテーションについて興味がある方は以下を参考にしてください。 Python と型ヒント (Type Hints) と #pyconjp [翻訳] PEP 0484 -- 型ヒント (Type Hints) Revenge of the Types: 型の復讐 私自身、型システムに明るくないため、一部未訳の部分があったり、勘違いや誤訳もあると思います。そういった誤りを見つけたら編集リクエストを送ってもらえると助かります。

    What is Gradual Typing: 漸進的型付けとは何か - Qiita
    t-wada
    t-wada 2015/05/26
    Gradual Typing (漸進的型付け) について
  • Suffering-oriented programming - thoughts from the red planet - thoughts from the red planet

    September 2021 (1) March 2017 (1) January 2017 (1) July 2016 (1) June 2016 (1) September 2015 (1) October 2014 (1) June 2014 (1) May 2014 (1) February 2014 (2) April 2013 (3) March 2013 (1) September 2012 (1) February 2012 (1) January 2012 (1) October 2011 (1) March 2011 (1) January 2011 (3) December 2010 (2) November 2010 (1) October 2010 (2) August 2010 (2) July 2010 (2) June 2010 (1) May 2010 (

    Suffering-oriented programming - thoughts from the red planet - thoughts from the red planet
    t-wada
    t-wada 2015/05/26
    "suffering-oriented programming: First make it possible. Then make it beautiful. Then make it fast."
  • Atom を使うようにしてから 1 ヶ月位たった - HsbtDiary(2015-05-18)

    ■ Atom を使うようにしてから 1 ヶ月位たった emacs をずっと使っていたけど、Atom どうなんということで Atom を 1 ヶ月くらい使ってまあまあ使えるようになってきた。プロジェクト単位ということで複数のディレクトリ(rails/rails とか ruby/ruby とか)をまたがって何かをする、という開発にはとても弱いのでこの辺は慣れでなんとかすることにした。 やったこと atomic-emacs 入れて emacs キーバインドにした autosave を有効にしてフォーカスが変わる度にセーブ tab キーを indent に変更 linter, language を色々入れた これくらいで他は特にいじってないけど、Atom が emacs に見えてきたので大丈夫だと思う。後は起動速度さえなんとかなればなあ。

    Atom を使うようにしてから 1 ヶ月位たった - HsbtDiary(2015-05-18)
    t-wada
    t-wada 2015/05/26
    atomic-emacs を使ってみよう "Atom が emacs に見えてきたので大丈夫だと思う" ゴクリ……
  • 「QA@IT」ナンバーワン回答者 flied_onionさんに聞く「なぜ私は、無償で質問に答え続けるのか」

    「QA@IT」ナンバーワン回答者 flied_onionさんに聞く「なぜ私は、無償で質問に答え続けるのか」:一つの回答に数時間かけることもある(1/2 ページ) @ITが運営する問題解決コミュニティ「QA@IT」には、日々さまざまな質問が投稿されている。レベルもジャンルもさまざまなこれらの質問に、丁寧で分かりやすい回答を付けてくれることで、コミュニティ内外のエンジニアから注目されているのが「flied_onion」さんだ。「空飛ぶタマネギ」はどんな人物で、どんな思いで回答しているのか。編集部がお話を伺った。 2012年5月29日にサービスを開始した、ITエンジニアのための問題解決コミュニティ「QA@IT(キューエーアットマークアイティ)」は、ITエンジニアが日々遭遇する課題やトラブルを質疑応答形式で解決&共有するサイトとして、たくさんの質問と回答を蓄積してきた。中でも、レベル4000超とい

    「QA@IT」ナンバーワン回答者 flied_onionさんに聞く「なぜ私は、無償で質問に答え続けるのか」
    t-wada
    t-wada 2015/05/26
    QA@IT 回答数ぶっちぎりトップの flied_onion さんのインタビュー。面白い。
  • WebAPIリクエスト仕様書としてcurlコマンドのご提案 - Qiita

    WebAPIの仕様を記述する方法はいくつかあると思う。 普通に日語で記述する JSON Hyper-Schema、WADL、RAML、Swaggerなどを使う 仕様書の代わりにプログラムを書く HTTPメッセージそのものを記述しておく でも、文法にばらつきがあったり、読みにくかったり、ツールのセットアップが面倒だったり、どれもイマイチな所があって、手軽な方法が欲しいと思っていた。 何気なくcurlコマンドのオプションを調べていたら、「もうこれでAPIドキュメント扱いにしちゃえばいいんじゃね?」と思えてきたのでメモしておく。 curlコマンドのおさらい curlコマンドはlibcurlの付属コマンドで、最近のUnix系OSなら大抵最初から入っていると思う。コマンドの詳細はmanを読んでいただければ。 cURL - How To Use (マニュアルページ日語訳) curlコマンドのオプシ

    WebAPIリクエスト仕様書としてcurlコマンドのご提案 - Qiita
    t-wada
    t-wada 2015/05/26
    面白い。すぐ試せる、実行可能なドキュメントという側面はとても良いと思う
  • ymsr墓ッソン(java-ja.墓)開催レポート

    インターネット上のymsrの墓には毎日線香を(cronで)あげているが、物理墓はまだ確認してなかったなー、とか考えていたら、 唐突に「墓ッソン」という単語が降りてきたので、実施するしかなくなった。 急な告知にもかかわらず、参加率100%(1人/1人)でドタキャンなし。素晴らしい。 家族に時間をもらい、車を走らせること約一時間半、住宅街のなかにたたずむ見晴らしの良い静かな霊園にたどり着いた。 桶と線香を借りて、階段を降りていく。 いた。ymsrと彫り込まれた特徴のある墓石。 途中で買ってきたピザとビールをお供え。やはりハッカソンと言えば、そしてymsrと言えばこれしかないだろう。 自分は車なのでノンアルコールビールだけど。 で、おもむろにMacbookproを取り出し、墓ッソン開始。会場には椅子や机など無いので、墓の前に座り込んでコード書くスタイルとなる。 あからさまに不審者である。無論、電

    ymsr墓ッソン(java-ja.墓)開催レポート
    t-wada
    t-wada 2015/05/26
    いいハックだ……
  • WebAPIでエラーをどう表現すべき?15のサービスを調査してみた - Qiita

    2017-01-05 追記 2016年3月にエラーの標準形式RFC7807「Problem Details for HTTP APIs」が提案され、今日現在proposed standard(標準化への提唱)となっています。こちらも是非ご覧ください。 RFC 7807 - Problem Details for HTTP APIs HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様 最近はREST APIを提供しているサービスが増えてきていますね!また公開されるAPIだけでなく、Microservicesなアーキテクチャを採用して、バックエンドがWeb APIで通信するケースも増えてきているように思います。 APIを使うときはあまり気にしたこともなかったですが、いざAPIを設計してみるとどんなインターフェイスがいいのか、どんな形式がいいのかといった疑問が次々と出てきます。

    WebAPIでエラーをどう表現すべき?15のサービスを調査してみた - Qiita
    t-wada
    t-wada 2015/05/26
    Web API のエラー表現 (エラー時のレスポンスボディ) を各社サービスがどのように設計しているかのまとめ。参考になる。実際の HTTP ステータスやヘッダがどうなっているのかも気になる。
  • Testing Casual Talks #2 へ参加してきた - 雑文発散(2015-05-25)

    ▼ [雑] Testing Casual Talks #2 へ参加してきた Testing Casual Talks #2 へ参加してきた。前回(初回)は2年前くらいに開催されていたそうだ。その時は行っていないので、気付かなかったんかなー。 mruby のテスト方法についての試行錯誤 GMO ペパボで ngx_mruby の記述をテストするために実行してきた内容のお話。 まだ自分では Nginx の config が複雑怪奇になるところまでは書いていないのだけど、設定を mruby で書いて、しかもそれをテストできるという状態はとても気持ち良さそう。 いまやサーバ構築はテストできるし、アプリケーションももちろんテストできる。ただ、その間にあるミドルウェアに関しては、テストすることがうまくできていないという言葉を聞いて、そういう視点では考えたことなかったなーと、目からウロコ。 最近また少し自

    Testing Casual Talks #2 へ参加してきた - 雑文発散(2015-05-25)
    t-wada
    t-wada 2015/05/26
    Testing Casual Talks #2 のくわしい参加レポート。参加できなかったのでありがたい。資料へのリンクもまとまっている。