商用サービス並みに高精度な住所正規化用のNodeモジュールを公開しました！
概ね以下のような感じになります。 町丁目レベルまでの数字は漢数字に変換します。 例: 24-2-2-3-3 => 二十四軒二条二丁目3-3 街区、地番レベルの数字は、アラビア数字に変換します。 例: 十四ーイ二十二 => 14-イ22 京都の通り名は削除します。 郡 が省略されている場合は補完します。 例: 和歌山県串本町 => 和歌山県東牟婁郡串本町 が、ケ、ヶ などの揺れを吸収し、国交省が公開する位置参照情報のデータと同じ文字になるように変換します。 旧字体は、新字体に変換します。 大字、字 は削除します。 街区、地番以降の文字列、たとえば建物名などは、そのまま返します。 京都の通り名を削除することには賛否両論あるかと思いますが、この正規化モジュールは住所の名寄せを目的としているため、そのような仕様になっています。 精度が気になる方は、以下にテストケースがありますので、そちらをご覧いた
npm-scripts を書く時の手癖 - mizdra's blog
かれこれ 5 年くらい趣味開発で npm-scripts を書き続けている。長年書き続けているとノウハウが蓄積されてきて、「こう書くとスッキリする」「迷いがなくなる」「後から拡張したくなった時に、簡単に拡張できる」みたいな書き方が身についてきた。自分の型、あるいは手癖のようなものだと思う。 せっかくなので、id:mizdra の今の npm-scripts を書く時の手癖を書き連ねてみる。 基本形 { "scripts": { "build": "webpack --mode production", "dev": "webpack-dev-server --mode development", "lint": "eslint .", "test": "jest" } } 一番シンプルな npm-scripts を書く時のパターン。以下の 4 つの script を登録している。 buil
Nuxt + Sails + TypeScript + Fargateでタスク管理ツールを作ったら快適だった話 - Qiita
Repsona LLCの@GussieTechです。無料ガントチャート、無料カンバン、無料ドキュメント管理が便利な「理想のプロジェクト管理ツール」を作っています。 タスク管理ツール、情報共有ツール、便利ですね！ これまでいろんな仕事で、いろんなツールを使ってきました。それぞれ、特に不自由もなく、乗り換えるほどのモチベーションもなく使い続けていたんですが、不満が全くなかったわけではありませんでした。 ・遅い ・ダサい ・わかりにく ・カンバンがない ・ガントチャートがない ・Wiki的なものがない ・なぜか仕事がうまく進まない ・SNSみたいな感じで、社員がもっと楽しくつながれたらおもしろそう ・スキルがレベルアップしてる様子とか、可視化されたらおもしろそう ・勝手に仕事してくれたりしないかな、AIとかで ・使ってたら無意識にPMBOKみたいになるように、レールが敷かれていると便利な気がする
PullRequestからチーム開発の生産性・健全性を測るCLIツールを書いてみた - $shibayu36->blog;
最近、開発チームの生産性や健全性をどのように計測したら良いかについて興味を持っている。その中で「LeanとDevOpsの科学」の中に書いてあるようなデプロイの頻度・変更のリードタイム・MTTR・変更失敗率の4指標や、開発チームの生産性・健全性を客観的に知るためにリポジトリ履歴から機械的に可視化するツールを作った - Qiitaに興味を持った。 一方、それらの指標を考えてみた時、以下のような点について悩んでいた。 マイクロサービスなどで複数レポジトリとなり、さらにデプロイ手法がそれぞれ違う状況の場合、変更のリードタイム = コミット〜本番稼働までの時間を計測するのがなかなか難しい コミットという単位だとかなり小さく、個々人のばらつきも大きすぎるように感じるので、もう少し良い単位はないのだろうか このような悩みから、PullRequestの単位で集計することで、生産性や健全性をもう少し測りやす
npxが結構良さそうな件について - Qiita
追記：2017/07/12 gist連携時の理解が間違ってたので修正 npm 5.2リリース。npmパッケージのダウンロードと実行を一度に行うCLIツールnpxが同梱された / “Release v5.2.0 (2017-07-05) · npm/npm · GitHub” https://t.co/2CXccPBqcq — Teppei Sato (@teppeis) 2017年7月11日 へー、と思って見に行ったら結構面白かったので雑な紹介を書いてみることにする。 v.5.2.0 リリースノート npxの紹介記事 この記事は紹介記事のざっくりしたサマリ相当です。 適当に20分くらい触ってわかったことだけ書いてあるので間違ってたり不正確だったりしたら別途詳解記事を書いて教えてもらえると幸いです。 npx is 何？ $(npm bin) やってくれるマン npx tsc は大体 $(np
CarloでNode.jsのツールにUIをもたせる - Qiita
先日、GoogleがCarloというライブラリをリリースしました。 少し気になったので、軽くメモを残しておきます。 Carlo is 何 CarloはChromiumを画面描画エンジンとして動作するNode.js アプリケーションフレームワークです。 Node.js、ChromiumともにV8が動作するため、JavaScriptのみでデスクトップアプリが作れるよ、というわけです。 公式のサンプルとほぼ一緒ですが、次のようにコードを書くと、index.htmlがデスクトップアプリ風に立ち上がります。 const carlo = require('carlo'); (async () => { const app = await carlo.launch(); // html/CSS/JavaScriptを配置しているフォルダを教える app.serveFolder(__dirname); /
inkでターミナルappを作る - Qiita
inkとは、ターミナル上で動くインタラクティブなアプリケーションをReactライクに作ることのできるフレームワークです。 あくまでもReact ライク であって、Reactそのものが動いているわけではありません。 React周辺の知識がある程度あれば、誰でもアプリケーションを作ることができます。 ↓こんな感じのものが簡単にできます。(デモ用に作った、なるべくたくさんのコンポーネントを使っただけの無意味なアプリケーションです。GitHubのリポジトリ) ちなみにreact-ink等の類似モジュールがありますが、それらとは無関係です。 この記事ではinkのREADMEを見ただけでは分かりにくいであろう、環境の作り方等を記します。 手順 0. 新規作成 適当なディレクトリを作り、普通のnpmと同じように yarn init します。 聞かれる各種事項には適当に答えてください。 1. 使用モジュー
Monorepoについて - Qiita
Monorepoとは何か npmで管理する複数のpackageを、まとめて一つのgitリポジトリで管理すること。 具体的に 例えば、 npm上にBabelは108以上のパッケージがある。 babelはpluginを追加していくスタイルなので、 babel-core, babel-cli, babel-preset-es2017, babel-preset-flow .... と、たくさんのパッケージがあり npm install babel-preset-flow 等々して取り込んでいく。 従来、npmでは「１リポジトリ＝１パッケージ」が標準だったが、多数パッケージを管理するBabelのようなプロジェクトでは多数リポジトリを扱うことになり、混乱が大きい。 そこで、単一リポジトリの /packages 以下にたくさんパッケージを作り(フォルダとpackage.jsonを多数作り）、管理するの
Rails serverを見やすくするツール rails-dashboard - Qiita
Rails serverを起動する際に、通常は bin/rails s あるいは bundle exec rails s と実行するかと思います。しかし単にログがつらつらと流れるだけなので見にくくないでしょうか？ というわけで、見やすくする↓こんなツール(rails-dashboard)を作ってみました。 ↓ レスポンスタイムの内訳を見たり、 ↓ リクエストパラメータを見たり、 ↓ SQLを見たり、 ↓ レンダリング情報を見たり、 ↓ 生ログを見ることができます。 使用方法 1. rails-dashboard はnpmなので、まずはインストールします。 $ npm install -g rails-dashboard # インストールできたかの確認で、バージョンを表示 $ rails-dashboard -V 2. Railsアプリケーションのディレクトリで、 rails-dashboa
amakanでyarnを使うようにした - ✘╹◡╹✘
amakanをUnicornからPumaに移行した - ✘╹◡╹✘ に引き続き、小さい改善を加えた。 変更の概要 https://amakan.net/ への今後の変更に備えて、テストやデプロイに掛かる時間を短くする恩恵が良いだろうと思い、node_modulesの管理に使うツールとしてyarnを使うことにした。結果的に、テスト用ビルドの所要時間が130秒から70秒に、デプロイ用ビルドの所要時間が300秒から200秒になった。 CircleCIの設定変更 継続的なテストとデプロイ作業の実行のために、amakanではCircle CIを利用している。Circle CIを使っている理由は、仕事でも使っている上にPrivateでも無料だから。 yarnを利用するためにCircle CIに追加する必要があった設定は、以下の通り。 指定したバージョンのyarnが入っていない場合はインストールする グ
npm install scriptの脆弱性とオープンソースと信頼 - teppeis blog
先日アナウンスされた脆弱性とその周辺について、とりとめなく。 The npm Blog — Package install scripts vulnerability Vulnerability Note VU#319816 脆弱性の概要 VU#319816 によれば、今回問題になっているのはnpmの以下の性質を利用するとnpmパッケージでワーム（自己増殖力のあるマルウェア）を作れるというもの。 依存パッケージのバージョンをロックせず、semverにより範囲指定することが多い CLIで一度npmへloginすると、明示的にnpm logoutするまで認証が永続化される npm registry が中央集権型サーバーである 具体的な手法として、Chris Contoliniが PoC として pizza-party というリポジトリを公開している*1。以下のように動作する。 ワームが仕込まれ
フロントエンド開発における革命とビルドプロセスについて - Qiita
こんにちは、freeeでフロントエンドエンジニアをしている @joe_re です。 freee Engineers Advent Calendar 2015の4日目を書きます。 僕からはfreeeで現在進行中の革命について、フロントエンドのビルドプロセスを中心に書こうと思います。 革命 ってなんのこと？ というのはフロントエンドヤンキーこと @ymrl が 2日目で書いたので詳しくはそちらをご参照頂ければ幸いです。 背景 弊社ではRuby on Railsを主軸にしてWebサービスを作っています。 Railsは素晴らしいフレームワークですが、めまぐるしく変化する昨今のフロントエンドについては、このままRailsの用意しているRailに乗ったままでは時代に取り残されてしまう危機感があります。 僕たちは時代に取り残されている場合じゃない。 最先端でかつ適切な技術を用いて未来を切り開いていかなく
RailsのAsset PipelineとPrecompileをNode.jsのみで処理できるgulp-sprocketsを作った - yo_waka's blog
RailsのAsset PipelineとPrecompileをNode.jsのみで処理できるgulp-sprocketsを作った 仕事ではRailsアプリを書いていて、JSやCSSなどのフロントエンドはRailsのAsset Pipelineの仕組みに則ってビルドしてる。 普通にRailsアプリ作ってると普段Sprocketsについて特に意識しないと思う。 Sprocketsはそこが凄くて、あまり考えなくてもドキュメント通りにやってれば、必要なAssetを結合できて、リリース時は変更がなければブラウザキャッシュから、変更があれば 新しく読み込まれるみたいなことをやってくれる。 なんだけど、もうそろそろ新しい機能はES2015で書きたいよねという人が増えてきた。 とはいえSprocketsは独自のディレクティブ以外は使えなくて、SprocketsWayから外れると途端に脆い。 ES2015
JavaScriptのトレンドを素振りして確認する方法 - Qiita
JavaScriptは流れが早いと言われますが、その流れをどう捉えるかの一つの要素として使える素振りの話です。 流行り廃れが早いのはちゃんと循環してるということなので問題ないですが、 トレンドと言われるものの半分ぐらいは誰かの主張にすぎない事があります。 そのため、主張だけを見て判断しないで中身を見て確認する必要があります。 自分はJSer.infoというJavaScriptの情報サイトを2^8週間ほど継続してやっています。(5周年記念イベントを1/16(土)にやります) JSer.infoで紹介するものは何かしらの方法でその主張がおかしくないかの確認をとります。 売り文句は素晴らしいが中身を見た時におかしな部分や問題がありそうなら、そこで引き返して追わないという判断もします。 仮にそこで引き返した事が間違えであっても、それが素晴らしいものなら別の誰かがそういう主張を書いてくれるはずなので
Railsのフロントエンドのビルドをnpmコマンドのみで完結したい - Qiita
こんにちは、freeeでエンジニアをやってます @yo_waka です。 これは、freee Engineers Advent Calendar 2015の11日目の記事です。 これまでの弊社のAdvent Calendarでは、社内で革命と呼ばれるフロントエンドの改善ネタが多いと思いますが、その流れとして、RailsアプリケーションにおけるフロントエンドのビルドツールであるところのSprocketsをどのようにしたら外せるかという話を書きます。 Sprocketsがやってくれること まずはSprocketsが裏側でどういうことをやっているのか知る必要があります。 Advent Calendar4日目の記事で既に概要が書かれていますが、もう少し細かく内部動作に踏み込んで書いてみます。 尚、Sprocketsのコードは現状のRailsの最新版である4.2.5で利用されている、Sprocket
gulpとかnpmのこととか – A Memorandum
最近、Gruntからgulpに切り替え始めている人が増えている気がします。この数ヶ月でいろんなブログなんかでも導入記事が増えてるようですが、ひとつ言っておきますと「数ヶ月前の記事は鵜呑みにしてはいけない（というか、そのままだと動かないこともありうる）」かな〜、なんて。 あれがどうしたこうしたと質問を受けたりするんですが、いろんな人がはまってる原因はそこら辺にある気がしてならないのですよね。そんなわけで、ちょっとその辺の話をまとめておこうかと立ち上がった次第です。 ※この記事は2014年7月30日時点のものですので、数ヶ月後にコレを読んでる方はご注意を。 アップデートの頻度が高いので… こういったツールのアップデート頻度は高いものですが、gulpのバージョンアップ頻度もまぁまぁで現在の最新版は「v3.8.6」になっています。プラグインを使えばあらゆる機能を追加することができますが、そういった
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - renovatebot/renovate: Home of the Renovate CLI: Cross-platform Dependency Automation by Mend.io
GitHub
Glitch
GitHub - ladjs/superagent: Ajax for Node.js and browsers (JS HTTP client). Maintained for @forwardemail, @ladjs, @spamscanner, @breejs, @cabinjs, and @lassjs.
