While we believe that this content benefits our community, we have not yet thoroughly reviewed it. If you have any suggestions for improvements, please let us know by clicking the “report an issue“ button at the bottom of the tutorial. Search Engine Optimization, or SEO, is a crucial part of any website or web app. Applications and sites that are not easily indexed by search engines or poorly opti
ここ1年ほど実務でVue.jsを利用してWebアプリケーションを開発しています。 今回はVue.jsを使ってチームあるいは個人で開発を始める上で予め考慮しておくと良さそうな事をいくつか書きたいと思います。 コンポーネントルール Vue.jsは単一ファイルコンポーネントによって、とてもシンプルな記述でコンポーネントを作る事ができます。しかし、開発者同士でコンポーネントの認識を揃えておかないと同じようなコンポーネントが作られてしまい、保守性を低下させる要因になってしまいます。 そのため、昨今ではAtomic Designなどの考え方をベースにコンポーネントを管理する方法が用いられています。Atomic Designを用いたコンポーネント設計方法については、以下の記事が参考になるかと思います。 Vue.js × Atomic Design - it's an endless world. いずれ
Pinterest’s new mobile web experience is a Progressive Web App. In this post we’ll cover some of their work to load fast on mobile hardware by keeping JavaScript bundles lean and adopting Service Workers for network resilience. Why a Progressive Web App (PWA)? Some history.The Pinterest PWA started because they were focused on international growth, which led them to the mobile web. After analyzing
AWS Lambda + API Gatewayで今流行りのサーバーレスなWebサービスを使ってみる機会がありました。 Lambda関数を管理コンソール上でインライン編集をしていたのですが、ある時間違えてソースをいじってしまい、関数、ひいてはAPI自体が動かないということに...。 ソース管理は大事!!ということを身にしみて感じたので、Lambdaのソース管理を行う方法を調べました。 AWS SAM (AWS公式) Serverless Framework 2つの方法があることを見つけたのですが、AWS SAMは現時点でAPI GatewayでのCORS対応が行えないようなので、Serverless Frameworkを使用してLambdaのソース管理を行うことにしました。 (ローカルでServerlessのプロジェクトを作成し、gitでソース管理を行う。) Serverlessで、Lam
PySpa統合思念体です。これからJavaScriptを覚えるなら、「この書き方はもう覚えなくていい」(よりよい代替がある)というものを集めてみました。 ES6以降の難しさは、旧来の書き方にプラスが増えただけではなく、大量の「旧来の書き方は間違いを誘発しやすいから非推奨」というものを作り出した点にあります。5年前、10年前の本やウェブがあまり役に立たちません。なお、書き方が複数あるものは、好き嫌いは当然あると思いますが、あえて過激に1つに絞っているところもあります。なお、これはこれから新規に学ぶ人が、過去のドキュメントやコードを見た時に古い情報を選別するためのまとめです。残念ながら、今時の書き方のみで構成された書籍などが存在しないからです。 たぶん明示的に書いていても読み飛ばす人はいると思いますが、すでに書いている人向けではありません。これから書くコードをこのスタイルにしていくのは別にいい
パフォーマンスに関する各種ブラウザAPI ◯◯ Timing APIはW3CのWeb Performance Working GroupのIlya Grigorikを中心に策定が進められている、ブラウザのパフォーマンスを計測するブラウザAPIである。 User Timing API: 任意のラベルを用いてプログラムの実行にかかったを取得する Navigation Timing API: ブラウザライフサイクルの発生した時間を取得する Resource Timing API: リソースのロードに際して発生した各種時間を取得する Frame Timing API: ブラウザフレームの内訳を取得する Server Timing API: サーバー処理の内訳を取得する High Resolution Time API: 高精度のタイムスタンプを提供する ブラウザのwindowオブジェクトにperf
Payment Request APIという仕様の策定が進んでいるという話を聞きまして、ちょっと触ってみました。 あまりコードは書いてないですが、ここに置いてあります。 github.com https://joe-noh.github.io/payment_request_api/でも試せるようにしてあります。108円取られそうになりますが、途中で失敗して中断するようになってます。 できること ECサイトなんかで買い物をするとき、フォームにクレカ番号とか届け先とかを入力すると思いますが、あの辺の情報の入力をブラウザに丸投げできちゃいます。言葉で書くより、以下のページのスクショを眺めたほうが速いと思いますので貼っておきます。 developers.google.com ここではブラウザの画面で説明されていますが、今後はPCはもちろんもっと多様なデバイスで使えるようになって、夢が広がるねとい
Service Workerの全体像の解説と、それがもたらすWebの未来を考察します。今後の動向を左右しそうなService worker meeting notesについても解説します。
As great as Node.js is for “traditional” web applications, its potential uses are far broader. Microservices, REST APIs, tooling, working with the Internet of Things and even desktop applications: it’s got your back. Another area where Node.js is really useful is for building command-line applications — and that’s what we’re going to be doing in this article. We’re going to start by looking at a n
- + 最近の小学校では、「お父さん・お母さんの名前をグーグルで検索してみましょう」という、世にも恐ろしい授業があるらしい。・・・。 — 丹 洋介 (@yosuke_tan) January 25, 2015
以前、Chrome拡張機能でFileSystemAPIを使う記事を書きました。 Chrome拡張機能でFileSystemAPIを使ってみた - メモ的な思考的な それを使って個人的な拡張機能を作っていたのですが、ふと先日気づいたところ、動作していないことが分かりました。 そこで、現在のChrome24に対応できるようにしてみたときのメモを残します。 お世話になったサイト ManifestFileのバージョン2対応や、APIの切替、拡張機能のデバッグなどで以下のサイトが参考になりました。ありがとうございました。 http://blog.maripo.org/2012/08/iinya-migration/ 現在開いているタブの一覧を取得・表示するGoogle Chromeプラグインを作ってみた - Life Refactoring Google Chrome Extensionを作ってみた
JavaScriptは移り変わりの早い言語です。 もう1年以上経っていますし、記事のメンテもちゃんとできていないので、消し線を入れることにしました。 参考程度のために記事は一応残しますが、より新しい情報を読まれることをお勧めいたします。 はじめに --- 最近では JavaScript の実行環境はブラウザに限りません。(node.js, Web Workers) また、旧来のような <script> 経由でのロードもとうに古くなっています。今は CommonJS スタイルで、require を用いたモジュールのロードを行なうことがより良いとされています。 ですから、次のようなことは改める必要があります。 - var YourModule = {}; などとして、外部から YourModule.hoge(); などと呼び出す書き方 - this === window だと思うこと 今回は、
WebWorkers(以下Worker)をハンドリングするのは結構大変で、ちゃんと意味があるコードを書こうとすると、 Worker が応答無くなったらどうしよう。エラーハンドリングどうしよう。どんなエラーがあるんだろう Worker に job 投げて結果を受け取ってクローズしてという基本的な部分をもっと楽に書きたい インラインワーカーどうしよう。インラインワーカーの場合の importScripts のパスの指定どうしよう postMessageの呼び出しコストは大丈夫か? 十分な時間分解能があるんだろうか などなど色々と考慮する必要があったりします。 このへんの事を考慮した実装がこちら( WebWorker.js )。半年ほど前の実装です。 https://github.com/uupaa/WebWorker.js/blob/master/lib/WebWorker.js (409行)
WKWebViewをinit時にJavaScriptを設置します。設置したJavaScriptはページ読み込みのたびに実行されます。 window.webkit.messageHandlers.yourKeyPath.postMessage("文字列/配列など"); 上記のJavaScriptを使うと、userContentController:didReceiveScriptMessage:が応答するので、yourKeyPath部分をもとに処理できます。 サンプルとして新規作成、"Single View Application"テンプレートからViewController.mに以下を貼り付けると試せます。 結果としてデバッグエリアにUserAgentが表示されるはずです。 #import "ViewController.h" #import <WebKit/WebKit.h> @inte
February 16, 2015 Swiftly Secure, Part 3 – Dividing Huge Numbers Posted in iPhone development, mac development tagged algorithm, division, huge, integer, multi-word, Swift at 9:05 pm by tetontech Let’s face reality. Computer division is ugly. It’s not the case, but it might seem to some people that those who conceived the computers we use today dropped the ball. Addition and Multiplication algorit
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く