yuw27b’s blog

技術メモと雑記

NDS第51回勉強会に行ってきたよ

第51回勉強会(2017/03/25) - 長岡 IT開発者 勉強会(NDS) に行ってきました。
50回は行けなかったので、半年ぶりのNDS、半年ぶりの長岡でした。

NDSは名称に「IT開発者」とあるとおり、幅広い分野の開発者さんが参加しているところが好きです。
私はWeb周りをやっているので、普段SIerさんとお話しする機会はなかなかないですが、NDSでそういった方の発表を聞くと勉強になります。

また、今回は「データに関わるなにか」がテーマということで、グラフ構造データについて発表させてもらいました。
スライドはこれです:
yuw27b.github.io

  • グラフ構造データについて
  • グラフデータベースのNeo4j
  • W3Cが標準化したリソース記述方式のRDFとそれを探索するSPARQL
  • おまけでグラフの可視化ライブラリとか

という、それぞれ独立したものを詰め合わせたのですが、「独立したもの」ってちゃんと伝わったかどうかがちょっと不安です(もうちょっと強調してしゃべるべきだったかな、と。)

そもそもは、Neo4jやSPARQLを使ったことある人はあんまりいないんじゃないかな、と思って題材に選びました。
質問していただけたり、知らなかったよ、と言ってもらったりしたので、その点は良かったです。
今すぐ業務に使う、ということはあまりないかもしれませんが、こんなものもあるんだな、と思っていただけてたらうれしいな。


以下、みなさんの発表を聞きながらのメモ・感想など、備忘録:

Vue.jsから始めるDOMにデータを持たせないアプリケーション開発への第1歩 nemuzukaさん

サーバからJSON返してもらうような業務用Webアプリケーションを作っているとのこと。
jQueryやテンプレートエンジンでは辛くなってきたが、業務アプリでReactとかAngularを覚えるのもちょっと、ということでVue.jsを採用したそう。
HTMLのクラスがJS用かCSS用かわからなくなるなど、DOMにデータを持たせるのは限界だった、とおっしゃってましたが、非常に共感できました。
ちょうどVue.jsやってみたいな、というところだったので、タイムリーな発表でした!

RDBMSトランザクション分離レベルやレプリケーションとか。あと苦労話。 bell-miyaさん

なんとなくサーバサイドもやっている(けどフロントメイン)な私が一番分かってない部分な気がしていて、楽しみにしていた発表でした。で、やっぱり私分かってないな、と。
分離レベルやSQL標準など、まだ理解しきれませんでしたが、勉強していきたいです。

入門系の本を一冊も読まずにデータサイエンスの世界に足を突っ込んでみる sakapunさん

チートシートがわかりやすかったです!やはりこの分野はPythonなんですね。
職場に機械学習をやっている人たちがいて、彼らはChainerを使っているようでしたが、今はいっぱいあるんだな、と。
あと「そろそろ本を読む」とのことでした。

PostgreSQL データ型 civicさん

「数値・文字列・日付ぐらいしか使ってない」って私のとこですね・・・。
PostgreSQLはデータ型が多いと思ったが、現在はそれほど差がなかった、というのが興味深かったです。
Python SQL Alchemyが便利とか。
排他制約とか、そもそも適切な型を指定するとか、もっとちゃんとやるべきだな、と思いました。

C#によるデータ処理のなにか masaru_b_clさん

.NET、C#は私自身はあまり馴染みがないのですが、LINQというものについて。
ExcelCSVXMLRDBMSなどに向けて共通のコードで.NETからクエリが発行できるということ・・・であってるかな。
書籍も書かれている方で、非常に聞きやすかったです。発表うまくなりたい。



また長岡にお邪魔したいと思います。
ありがとうございました!

JavaScriptでクリップボードにコピー(Chrome/Firefox/Safari10〜/IE9〜)

※2022/4/19追記:ここで使っている仕様は古くなり、非推奨になっているため、新しい記事を書きました。そちらを参照してください。



クリップボードにコピー」はJavaScriptのみでは不可能だと、昔に思い込んだままだったのですが、HTMLの各種APIJavaScriptを組み合わせることで、ほとんどのブラウザで実現できるようになってきたようです。

HTMLとJavaScriptのコード
<p class="copyTarget">コピーしてもらいたいテキスト</p>
<button class="copyBtn">クリップボードにコピーする</button>
function copyText () {
  var $target = document.querySelector('.copyTarget');
  if (!$target) {
    return false;
  }
  var range = document.createRange();
  range.selectNode($target);
  window.getSelection().removeAllRanges();
  window.getSelection().addRange(range);
  document.execCommand('copy');
  return false;
}
document.querySelector('.copyBtn').addEventListener('click', copyText, false);
使用するAPIとブラウザ対応

以下のAPIを使っています。

API 仕様 対応ブラウザ
Range API DOM Level2 + Living standard IE9〜、Edge、ChromeFirefoxSafari
Selection API > getSelection() W3C 草案 IE、Edge、ChromeFirefoxSafari
Android browser4.3〜
*ただし、window.getSelection()のサポートに限って確認。
Selection APIの全てをサポートしていないブラウザもあります。
Editing API > execCommand('copy') W3C 勧告改定案 IE9〜、Edge、ChromeFirefox、Safari10〜
これも仕様の全てをサポートしているブラウザは少ないですが、「copy」の実行についてのみ確認。



Safariがバージョン10以降なのがちょっとネックではありますが(2017年2月現在)、限られたユーザー層向けのWebサイトでは実際に使用したケースでは特に不具合の報告はありません。
ブラウザによっては、一旦「クリップボードにアクセスしようとしています」というような警告ダイアログが表示されるので、導入の際にはそのあたりも検討が必要になりそうです。

CSSの擬似要素を使ったあれこれ

この記事は、今年お世話になったCSS Advent Calendar 2016の20日目です。

擬似要素自体は特に今年どうこうなった仕様ではありませんが、大変お世話になりました。

擬似要素をよく使う場面

自分的頻出パターンとしてはこんな感じです:

counterと組み合わせたリスト

See the Pen List with counter by Yu Watanabe (@yuw27b) on CodePen.


パンくずリスト

See the Pen Breadcrumb by Yu Watanabe (@yuw27b) on CodePen.


三角形

See the Pen Css triangle by Yu Watanabe (@yuw27b) on CodePen.


上下中央揃え

See the Pen Align middle by Yu Watanabe (@yuw27b) on CodePen.



「:」なの?「::」なの?

擬似要素は、CSS 2.1の仕様ではコロン1つの「:before」「:after」でしたが、CSS3ではコロン2つになりました。
CSS3はモダンブラウザとIE9以上が対応しているので、IE8のサポートが切れた今年(2016年)からは「::before」「::after」を使用すれば良いと思います。
とはいえ、IE8でも・・・という案件がなぜかまだあったり、各ブラウザも後方互換のため「:before」でもきちんと解釈してくれるし、という状況で、結局コロン1つで書くことも多かった1年でした。

Safariのバグに出会った

擬似要素とcurrentColorを組み合わせたときに発生します。Safari9で修正されたようです。
親要素のcurrentColorがうまく継承されない、というものです。
css - currentColor seems to get "stuck" in Safari - Stack Overflow
Bug 133420 – `currentColor` computes to the same colour on all elements, even if 'color' is inherited differently

ターゲットブラウザにSafari8が含まれそうなら、擬似要素内でのcurrentColorの使用は避けたほうが良いと思います。


来年の抱負は、Flexible Boxにお世話になりたい!です。
未だにIE9〜対応の案件もあるので難しそうですが、スマートフォン専用サイトならそろそろ使えそうですね。

SVGをReact.js/JSXで使う

この記事はSVG Advent Calendar 2016の19日目です。
去年に引き続きグラフを描いての参加です。


React × SVG

React.jsなプロジェクトでSVGを描画したときのメモです。
React.jsでは、JSXという記法でJavaScriptコード内にHTMLタグを記述していきますが、SVGタグも記述できます。
React.jsの特徴は仮想DOMですが、SVGSVG DOMというインターフェースを持っているので、HTML同様にサポートされているのですね。

Attributeはキャメルケースを基本に

まずタグ内の属性名については、基本的にハイフンがキャメルケースになります。ネームスペースを表すコロンも同様です。

通常のSVG

<svg version="1.1" width="200" height="200"  xmlns="http://www.w3.org/2000/svg">
  <rect width="100" height="100" x="10" y="10" fill="#900" stroke="#666" stroke-width="5" />
  <a xlink:href="http://blog.hatena.ne.jp/yuw27b/"> 
    <text x="20" y="40" fill="#FFF" text-anchor="start" font-size="20">Text</text>
  </a>
</svg>


JSX内のSVG

<svg version="1.1" width="200" height="200"  xmlns="http://www.w3.org/2000/svg">
  <rect width="100" height="100" x="10" y="10" fill="#900" stroke="#666" strokeWidth="5" />
  <a xlinkHref="http://blog.hatena.ne.jp/yuw27b/"> 
    <text x="20" y="40" fill="#FFF" textAnchor="start" fontSize="20">Text</text>
  </a>
</svg>

JSXはあくまでもJavaScriptの中なので、ハイフンやコロンが使えないからだと思われます。
サポートされている属性名のリストは以下の公式ページの最下部にあります。
https://facebook.github.io/react/docs/dom-elements.html

上記のリストには含まれていないのですが(HTMLと同じだから?)、「class」も「className」になります。

ブラウザにReactのDeveloper Toolsを入れておけば、使用できない属性名についてはコンソールに警告が出るので、まずはそのままSVGを書いてしまって、エラーが出たら都度修正、でもいいと思います。

または、自動的に変換してくれるnpmパッケージと、それを元にしたオンラインサービスもあります。
svg-to-jsx
SVG to JSX Online Converter
ただし、若干バグがあるような感じなので、全部お任せはちょっと難しいかもしれません。


簡単なグラフ(もどき)

プルダウンからソート順を選択すると再描画する棒グラフっぽいSVGを書いてみました。

See the Pen xRMYzQ by Yu Watanabe (@yuw27b) on CodePen.

※仮想DOMなので、再描画の動作も軽いのでは、と思いますが、もっと大規模なものを作らないと差が分からないですね・・・。



SVGのグラフライブラリ×Reactも試しているのですが、それはまた別の記事にしたいと思います。

RESTful APIで長い検索クエリを扱う

Webアプリケーション用のRESTfulっぽいAPI*1を作っていて、複雑な検索クエリを受け取る必要が出てきたときのメモです。

悩み

RESTfulの原則に従うと、検索クエリを投げて結果の一覧を取得する、というリクエストは、
「リソースの取得」なので、GETを使うべきです。
/api/entries/?q=xxx とか
/api/entries/?created=20161129&status=active
みたいなURIになりますよね。

こんな感じで検索キーワードが1つ2つなら良かったのですが、
今回作っていたのが限定されたユーザー向けのアプリで、多少検索に時間がかかってもいいから複雑なクエリを投げたい、というのが要件でした。
こんなふうに検索条件を組み合わせられるようになっていました。
f:id:yuw27b:20161202233544p:plain

問題は、
①検索条件がいくつ来るか分からない
②「q=xxx」の形式では「equals」「not equals」のところが渡せない
という点です。

まず①で、GETのクエリパラメータが長くなる==URIが長くなるので、ブラウザ〜ファイアウォール〜サーバまでのどこかで制限される可能性がありそうです。
さすがにそこまで長くは・・・とは思うものの、理論上は無制限に検索ワードを指定できるので、「たぶん大丈夫」ではやっぱりダメですよね。

②も、そのままJSONを文字列にエンコードするとか、「?key__equals__value&…」とか考えるものの、やはりクエリが長くなってきます。
そもそもフロント側でクエリを文字列に変換し、それをサーバ側でまたパースする、というのがあまりイケてないような気もします。

POST使っちゃダメ?

GETが厳しいとなるとPOSTで、と思うものの、
RESTful APIでは、POSTはリソースの新規作成なので、検索クエリを投げて良いのだろうか、と悩むし、
そもそも「/api/entries/」に対するPOSTリクエストは、当然"entry"の新規作成用に使ってしまっています。

解決策:検索用エンドポイントを用意してPOSTする

「/api/entries/search」というURIにPOSTでJSONを投げることにしました。
参考にしたのはこれ↓です。
rest - Design RESTful query API with a long list of query parameters - Stack Overflow

レスポンスのステータスは迷いましたが「201 Created」を返しています。
上のリンク先にもあるように「検索結果というリソースを生成している」と捉えています。まあ200でも良さそうですが。

新たな悩み

検索条件が設定されているかどうかをフロント側で判別して、あれば「POST /api/entries/search」、なければ「GET /api/entries」にリクエストをかけているのですけど、
もう全部POSTに統一のほうがいいのだろうか・・・?


ひとまず、そこまでREST原理主義でなくてもいいかと思いこんな感じにしましたが、何かもっといい方法があれば知りたいです!

*1:最近、業務で作っているWebアプリケーション専用のAPIなので、API単体で一般に公開するような性質のものではないです。Ruby(Sinatra)+MySQLで、フロントエンドからのリクエストにJSONを返しています。