NEKOLAB

投稿

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

すべて表示

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

J-Coin Pay　手数料なしで現金化できる電子マネー銀行が運営する初の電子マネーみずほ銀行が３月１日から、QR コードを活用したスマホ決済サービス『J-Coin Pay（ジェイコインペイ）』の提供を始める。約６０の金融機関と連携した「銀行系初のデジタル通貨」だ。 QR コードを活用したスマホ決済サービス『J-Coin Pay』の提供開始についてもっともQRコード決済自体は目新しいものでない。 PayPay LinePay 楽天Pay OrigamiPay といった主要なサービスはすでに走っている状態であり、それの後を追う格好だ。他のサービスと比べたJ-Coin Payのメリットは何か？手数料なしでの個人間送金１つは、手数料なしの個人間送金が可能だ。銀行でいうところの振込機能であり、それができる他のサービスは決して多くないが、個人間送金サービスとしても目立ったものはない。以下に比較した。サービス個人間送金送金手数料参照 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つの漏えい事件について２０１９年１月末、２つのサービスで大規模な情報漏えい（Peingは実質的にその危険に晒されていた）の事件が発生した。一つはファイル転送サービスである「宅ふぁいる便」約４８０万件。もう一つはTwitter上で匿名で質問を送る俗に「質問箱」と言われる「Peing」約１５０万件弱。 ※なお、実際に漏えいしていたのは、APIトークン。直接的な情報については、そのAPIトークンを利用して二次的に漏えいしていた可能性がある、という状況）どちらも極めて個人や企業に結びつきやすいサービスであった。情報漏えい自体は、Webサービス提供者として最も注意するべきリスクの一つである。ただ、今回の２件の漏えい事件には一つ違いがあり、短期長期的双方から鑑みて利用者影響の観点では大きな差が生まれた。パスワードのハッシュ化有無の違いこの２つのサービスに限らず、登録時、利用者はアカウント名（メールアドレス）パスワードを登録することがほとんどだ。このとき、Webサービス側ではそれらを管理する単純な方法として「パスワードをそのまま（平文のまま）保存する」という方法が考えられる。こちらは「宅ふぁいる便」のケースである。ただ、現在では特別な事情がない限り、パスワードの平文での管理はされてはならない。もう一つは「パスワードに何らかの加工を行って保存する」という方法が考えられる。それをする理由は、後述する情報漏えい時の重大なリスクを現実的に無害化するためである。つまり、パスワードをそのまま持っていることは、漏れたときにいろいろまずいことが起きるわけだが、だったら、もともとのパスワードとは違う形に変更して保存しておけば悪用されないよね？という論理である。これを実現するための方法の一つがハッシュ化である。ハッシュ化についてハッシュ化は、ハッシュ関数と呼ばれる処理によってある固定長（必ず決まった文字数）の文字列（ダイジェストと呼ばれる）に変換する方法である。つまり、直接パスワードを管理せずハッシュ関数で処理し、ダイジェストを保管しておく、という寸法だ。ハッシュ関数が同じである限り、必ず同じダイジェストに変換されるので、同一性を（天文学的な確率を無視すれば）保証でき...

続きを読む