投稿

2月, 2019の投稿を表示しています

銀行初のデジタル通貨「J-Coin Pay」について調べてみた

イメージ
J-Coin Pay 手数料なしで現金化できる電子マネー 銀行が運営する初の電子マネー みずほ銀行が3月1日から、QR コードを活用したスマホ決済サービス 『J-Coin Pay(ジェイ コイン ペイ)』の提供を始める。 約60の金融機関と連携した「銀行系初のデジタル通貨」だ。 QR コードを活用したスマホ決済サービス『J-Coin Pay』の提供開始について もっともQRコード決済自体は目新しいものでない。 PayPay LinePay 楽天Pay OrigamiPay といった主要なサービスはすでに走っている状態であり、それの後を追う格好だ。 他のサービスと比べたJ-Coin Payのメリットは何か? 手数料なしでの個人間送金 1つは、手数料なしの個人間送金が可能だ。銀行でいうところの振込機能であり、それができる他のサービスは決して多くないが、個人間送金サービスとしても目立ったものはない。 以下に比較した。 サービス 個人間送金 送金手数料 参照 J-Coin Pay ○ 無料 PDF PayPay ○ 無料 個人間送金(譲渡)について LinePay ○ 無料 LINE Blog 楽天Pay × - 将来的には可能? 「楽天ペイ」アプリに「Edy」統合へ 個人間送金も予定 OrigamiPay × - - Kyash ○ 無料 HP 手数料なしでの現金化 重要なのは、もう一つの特徴だ。 手数料なしの現金化が可能 という点だ。つまり、 現金と同等の取扱が可能 ということを意味している。 この点は、他のサービスと比較して重要な特徴といえる。 サービス 個人間送金 送金手数料 現金化手数料※1 参照 J-Coin Pay ○ 無料 無料 PDF PayPay ○ 無料 不可 LinePay ○ 無料 216円※ LINE Blog Kyash ○ 無料 不可 - ※1 個人での現金化を意味する。 ※2 振込手数料 手数料なしで現金と同様に行われる決済 「金の専門家」銀行が他と違うワケ 他のサービスは、根拠法が「資金決済法」にある。1回あたり

[git]作っていたローカルレポジトリを後からリモートレポジトリと結びつける

イメージ
という、タイトルの悩みを解決したかったのですが、以下の記事がすべて解決してくれました。 【Git】ローカルリポジトリからリモートリポジトリ、環境作成方法 いちおう実践したので、メモを残しておく。 イメージ ただ、上記の記事中冒頭の画像のほうがよっぽどわかりやすいですね。 順番 前提:あらかじめローカルでレポジトリを作成している bareリモートレポジトリを共用フォルダ上で作成する。 git init --bare --shared –bare --sharedで作成しておく ローカルレポジトリにリモート先を設定する git remote add RemoteRepositoryURI ローカルレポジトリからpushする git push 公開レポジトリでリモートレポジトリからcloneする git clone RemoteRepositoryURI . 運用想定 ソースコードというよりテキストの共有がしたい…というところが本音。 gitがよくわからない人には公開レポジトリを見せておく gitがわかるひとには、リモートレポジトリをcloneしてもらって編集してもらう。 感想 職場は、コードを組む職場でないので、gitなどに理解のない人が多いし、あまり使われない。 実際まだ展開していないので、いろいろ試しだめし。 ただ、更新履歴の管理がしやすくなるので、やりやすい…かと思って試してみたい。

highlight.jsを追加してみた

イメージ
当ブログに適当にHighlight.jsを導入してみた。 Highlight.js とは サイト中のコードをハイライト化して、コードを読みやすくするjavascript。 Bloggerに導入 Bloggerの管理ページから、[テーマ] > [HTMLの編集] をクリック HTMLの編集画面が出てきたら、以下のHTMLコードをHEADタグ内に入れる。 <link href='https://cdnjs.cloudflare.com/ajax/libs/highlight.js/9.14.2/styles/github.min.css' rel='stylesheet'/> <script src='https://cdnjs.cloudflare.com/ajax/libs/highlight.js/9.14.2/highlight.min.js'/> <script>hljs.initHighlightingOnLoad();</script> と、これだけ。 参考は、 コードのハイライト表示用 JS ライブラリ highlight.js の使い方 から。 投稿記事 投稿するには、至って簡単でHTMLでpreタグとcodeタグで括ってやれば自動的に認識してくれる。 <pre><code>~何かしらコード~</code></pre> 以下のようなイメージになる。 function $initHighlight(block, cls) { try { if (cls.search(/\bno\-highlight\b/) != -1) return process(block, true, 0x0F) + ' class=""'; } catch (e) { /* handle exception */ } for (var i = 0 / 2; i < classes.length; i++) { if (checkC

マークダウンをブラウザで作れるmerked.jsを使ってみた

イメージ
Markdown (マークダウン)は、文書を記述するための軽量マークアップ言語のひとつである。 Wikipedia より引用 要するに簡単にHTML文書に変換する事ができる言語である。 Markdownを使えるのは、Wikiや一部のブログサービスなど。今は、GitHubではよく使われていて、README.mdのようにmdファイルと呼ばれるそれは、Markdown記法で書かれているそれである。 その特性上、インターネットウェブ上で使われるものであるが、ローカルで使ってみたいと思う人もいる。 それ用のソフトウェアを落とせばいいんだけれど、仕事場だとそういうのにいちいち許可が必要だったりするので面倒臭い…。 インターネットのウェブサイトを見てもいいが、スクリプトを見ても構わんだろう? ということで、JavascriptでMarkdownをHTMLに変換(parse)できるmerked.jsを使ってみた。 といっても、ちょっと触っただけだけど。 merked.jsの公開場所 merked.jsは、 github で公開されている。 ちなみにウェブ上で試したいだけならば、 デモサイト がある。 使用方法 こと単純でHTMLで組み込んでやればよい。 サンプルは、githubに公開されているとおり。 <!doctype html> <html> <head> <meta charset="utf-8"/> <title>Marked in the browser</title> </head> <body> <div id="content"></div> <script src="https://cdn.jsdelivr.net/npm/marked/marked.min.js"></script> <script> document.getElementById('content').innerHTML = marked('# Marked i

フローチャート図を書けるmermaid.jsを使ってみた

イメージ
いい加減、仕事でワークフロー図なんかを作るのに、ExcelやWordから脱却したいと思っていた。 Visioとか入れればいいんだけど、入れてくれないんですよね。 ので、mermaid.jsについて勉強してみた。 mermaid.jsとは GitHub から冒頭の文を日本語訳して引用。 マークダウンと同じ方法でテキストから図やフローチャートを生成します。 実際には、マークダウンというより、独自構文といったほうがいいけれど、HTMLタグやスクリプトは必要ない単純な構文で図を作成できるスクリプト。 フローチャート図 シーケンス図 クラス図 ガントチャート  なんかが作れる。 フローチャート図を作ってみた 構文としては、以下のような感じで graph TD; スーパーに入る --> 品物をかごに入れる 品物をかごに入れる --> レジに並ぶ レジに並ぶ --> お金を払う お金を払う --> 袋詰する 袋詰する --> 帰る 簡単にコードを組んで、mermaid.jsに通すと以下のような画像がでる。 実際には、svgで作られるのだけど、Bloggerでうまく埋め込めなかったので、スクリーンショット止まり…。 実際にサイトに埋め込んで使うときは、 GitHub や GitBook を参考にmermaid.min.jsとmermaid.min.cssを導入して、HTMLに埋め込んでやればいい。 以下は、一番シンプルな例。 <html lang="en"> <head> <link href="mermaid.min.css" rel="stylesheet"></link> </head> <body> <div class="mermaid"> graph TD; スーパーに入る --> 品物をかごに入れる 品物をかごに入れる --> レジに並ぶ レジに並ぶ --> お金を払う お金を払う --> 袋詰する 袋詰する --> 帰る &

「宅ふぁいる便」と「Peing」の情報漏えいの違いとリスク

イメージ
2つの漏えい事件について 2019年1月末、2つのサービスで大規模な情報漏えい(Peingは実質的にその危険に晒されていた)の事件が発生した。 一つはファイル転送サービスである「宅ふぁいる便」約480万件。 もう一つはTwitter上で匿名で質問を送る俗に「質問箱」と言われる「Peing」約150万件弱。 ※なお、実際に漏えいしていたのは、APIトークン。直接的な情報については、そのAPIトークンを利用して二次的に漏えいしていた可能性がある、という状況) どちらも極めて個人や企業に結びつきやすいサービスであった。 情報漏えい自体は、Webサービス提供者として最も注意するべきリスクの一つである。 ただ、今回の2件の漏えい事件には一つ違いがあり、短期長期的双方から鑑みて利用者影響の観点では大きな差が生まれた。 パスワードのハッシュ化有無の違い この2つのサービスに限らず、登録時、利用者は アカウント名(メールアドレス) パスワード を登録することがほとんどだ。 このとき、Webサービス側ではそれらを管理する単純な方法として 「パスワードをそのまま(平文のまま)保存する」 という方法が考えられる。 こちらは「宅ふぁいる便」のケースである。 ただ、現在では特別な事情がない限り、 パスワードの平文での管理は され てはならない 。 もう一つは「パスワードに何らかの加工を行って保存する」という方法が考えられる。 それをする理由は、 後述する情報漏えい時の重大なリスクを現実的に無害化するため である。 つまり、パスワードをそのまま持っていることは、漏れたときにいろいろまずいことが起きるわけだが、だったら、もともとのパスワードとは違う形に変更して保存しておけば悪用されないよね?という論理である。 これを実現するための方法の一つが ハッシュ化 である。 ハッシュ化について ハッシュ化は、 ハッシュ関数 と呼ばれる処理によってある固定長(必ず決まった文字数)の文字列(ダイジェストと呼ばれる)に変換する方法である。 つまり、直接パスワードを管理せずハッシュ関数で処理し、ダイジェストを保管しておく、という寸法だ。ハッシュ関数が同じである限り、必ず同じダイジェストに変換されるので、同一性を(天文学的な確率を無視すれば)保証でき