はじめに 先日、RSpec 3.7がリリースされました。 参考: RSpec 3.7 has been released! 上記ブログの中で「今回のリリースはRailsのSystem Testの統合機能をいち早く使ってもらうためのリリースだ」と書いてあります。 実際、ブログの中で触れられている新機能は「System Spec」機能の追加だけです。 というわけで、この記事はrspec-rails 3.7で導入されたSystem Specの紹介と使い方の説明をしていきます。 実行環境 この記事は以下のバージョンを対象にして書かれています。 rspec-rails 3.7.1Rails 5.1.4Ruby 2.4.2 selenium-webdriver 3.6.0 Capybara 2.15.4Chrome 62ChromeDriver 2.33 サンプルコード この記事で使用したコー

先日行われたbuilderscon tokyo 2017 にて、「複雑なJavaScriptアプリケーションに立ち向かうためのアーキテクチャ」という発表をしてきました。この記事では、そのプレゼンテーションの再現を行います。 アバンパート本日はこういう発表をします。よろしくおねがいします。 普段はメディロムという会社で働いていて、ScalaとJSを主軸に活動しています。PerlとRubyもたしなむ程度には書きます。業務では、業務で使うアプリケーションをブラウザプラットフォーム上に作っています。こういうブログも書いてるんでよかったら読んでください。 あと、何度かweb+DBプレスに特集書かせてもらっていて、とくに左の「データ構造の基礎知識」ってやつは自分で言うけどまじでいい記事なんでまだ読んでないひとはバックナンバー買って読んでください。 さて、複雑なアプリケーションに立ち向かうためのアー
npm v5 The npmBlog — v5.0.0 npm に v5 がやっとリリースされました。この npm v5 は既に明日リリース予定の Node v8 にバンドルされる予定です。 かいつまんで、機能を紹介します。 Notable Changes package-lock.json!!! faster than npm v4 no more --save option Offline mode sha512 support package-lock.json!!! npm v4 まで問題だった npm-shrinkwrap の問題 を解消するための新しい lock ファイルが生まれました。 shrinkwrap は依存ライブラリを固定するための機能です。npm v4 までは shrinkwrap で固定していましたが、新しく npm v5 になってからはshrinkwrap は

待望されたYarnサポートの入ったRails5.1が2017年4月にリリースされました。Ruby onRails 5.1 ReleaseNotes —Ruby onRailsGuides 他にもjQueryがデフォルトdependencyから外されたり、Optionalでwebpackサポートが入ったりしており、Railsのフロントエンドは大きな転換点を迎えたと言ってよいでしょう。本エントリではRailsのフロントエンド技術の今を振り返り、今後どうなっていくかをまとめてみたいと思います。 DisられてきたRailsフロントエンドRailsのフロントエンド技術スタックは、フロントエンドを専業とするエンジニアにDisられるものでした。具体的には下記の技術要素です。 jQueryCoffeeScriptAssets Pipeline (sprockets)gemのエコシステムに乗っ

This question has been addressed, in a slightly different form, at length, here: RESTful Authentication But this addressesit from the server-side. Let's look at this from the client-side. Before we do that, though, there's an important prelude:JavascriptCrypto is Hopeless Matasano's article on this is famous, but the lessons contained therein are pretty important: https://www.nccgroup.trust/us/
現在開発中のシステムにリアルタイムな処理があり、そこで socket.io を使おうかなと思ってて、そういう折にタイムリーにもこの辺りの記事がタイムラインで出てきたのでメモ代わりに自分の意見を残しておく。blog.jxck.io qiita.com socket.io が提供してくれているもの 「ブラウザとサーバ間のプロトコル」という観点で見ると socket.io は WebSocket を基本として繋がらなかった時に XHR Long Polling や polling といった形式の代替手段を提供してくれるもの、という位置づけ。 一方で「ライブラリ」という観点で見ると socket.io はリアルタイムアプリケーションを作る際に必要になる処理をまとめて実装し、クライアントとサーバ間での EventEmitter として抽象化してくれているもの、という風になる。 もう少し噛み砕いて言
I’m usingJavaScript to pull a value out from a hidden field and displayit in atextbox. The value in the hidden field is encoded. For example, <input id='hiddenId' type='hidden' value='chalk & cheese' /> gets pulled into <input type='text' value='chalk & cheese' /> via some jQuery to get the value from the hidden field (it’s at this point that I lose the encoding): $('#hiddenId').attr('v
若者の成長曲線は半端なく、おじさんエンジニアは日々恐怖を覚えます。 出る杭はちゃんと打っておきましょう。 環境の弄りがいのあるツールを教えるEmacs,VIM, zsh, tmuxなど…設定のいじりがいのあるツールは理想の環境を追い求めても終わりはなく、コンフィグはどんどん膨れ上がるばかりです。 それらを「一流のプログラマは、一つの道具にこだわりとことん使い尽くすもんだぜ」とでも言って、ずっとDotfilesのリポジトリばかりいじるようになってくれれば、彼らがプログラミングに費やす時間は減るはずです。 バイナリアンにさせるいくらアプリケーションが作れても、低レイヤのことが分からないとダメだと刷り込みます。 「プログラムがどうやって起動するか分かってる? えっ、mainを書けばそれが呼ばれる? あのなぁ、_startというのがあってだな…」 無駄に低レイヤに詳しいおじさん力を活かして、あた

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに データ可視化では、データの性質によって概ねどのような可視化ができるのか決まる場合があります。データ可視化は探索的なデータ分析をする場合や、データ分析した結果を誰かに伝えるために重要であり、その時々の目的に合わせた可視化を選択するべきですが、そもそも可視化手法の特性とデータの性質があっていないとあまり効果がない場合があります。筆者が業務においてデータ可視化する際にデータの性質から可視化手法を導く場合の道のりを整理し、チートシートとしてまとめてみました。 もちろん、調べたい・表現したい内容によって自分で自由に選んでもまったく問題無

2016/2/4 「ソフトウェアジャパン ビッグデータ活用実務フォーラム」でのプレゼン資料です。 主にPythonで書いたコードの高速化の話です。タイトルと中身がマッチしない感じがするのは自覚しています。
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 春ですね!人の配置がリファクタリングされ、コードもリファクタリングの季節です。 では僕がここでモダンなJavaScriptとES2015の利点を語る役をやるので、みなさんはチームを説得する役をやってください。JavaScriptの歴史 まず最初にJavaScriptの歴史を踏まえることで、今学ぶべきものとその理由を確認しましょう。 なぜ2016年の記事でES2016ではなく、ES2015なのか、と疑問に思った方もいるかもしれません。それは、ES2015がただの年次アップデートではなく、これから始まる毎年のメジャーバージョンアップの起点

(2015/10/21追記) 記事を書いてから半年経ちましたが、最近はRxの良さを理解したり、ES7のasync/awaitがbabelによって実用的になりつつあったり等、またもやベストプラクティスとはなんだったのか状態です。とはいえ、いまのところPromiseは非同期処理の土台であり続けそうですし、Generatorもasync/awaitへの足がかりとして知っておくことのメリットは大きいかと思いますので、引き続き公開させたままとさせて頂きます。 (追記ここまで) 数ある非同期処理のプラクティスを試してみて、だいたいこれが良いんじゃないかというパターンが固まったので書きます。効用はコールバック地獄からの脱出と結局非同期どれが良いの感の払拭。ES6寄りです。 前提知識JavaScript Promiseの本 http://azu.github.io/promises-book/ ジェネレ

リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く