[JPOUG Tech Talk Night #12]SQL Plan Management(SPM)とAdaptive Cursor Sharing(ACS)の組み合わせ

Higher-Order Components(以下、HOC)は、Reactのコンポーネントを作る際のパターン。 HOCを使うことで、複数のコンポーネントで使っている処理を共通化したり、SFCにライフサイクルメソッドを追加したりすることが出来る。 基本的な構造 HOCは、以下のような関数を使って実現する。 function hocFactory(WrappedComponent) { return class extends React.Component { render() { return <WrappedComponent />; } }; } コンポーネントを引数として受け取り、それに機能を追加した新しいコンポーネントを返す。 上記の例では何もしていないが、hocFactory(ファクトリ関数)のなかで様々な処理を行うことで、WrappedComponentに新しい機能を加えるこ
JavaScriptで非同期処理をasync/awaitを使って同期的なスタイルで書いていると、すべてのコードをそのスタイルで統一して書きたくなる。なので非同期処理を開始して実行を明け渡したいときはもちろんawaitを使うし、非同期処理に失敗したときはtry-catch構文で例外ハンドラに制御が移るようにする。ただ、同期的なスタイルで書けない処理が存在するために、どうしてもすべてを統一することはできない。Direct styleで書けないcontrolは継続渡しスタイル(CPS)を使って書くしかないからだ。 JSの場合でいうと、並行制御周りがそれにあたる。Promise.all() や Promise.race() などは対応する構文がJS側に存在しない。 例えば Promise.all() に対応する awaitall みたいな構文が言語側に欲しくなる。こんなふうに: const [x,
はじめに VueをつかってWebアプリケーションを実装するとき、Componentをどう切るかって誰でも一度は悩みますよね(悩みますよね?)。とりあえず思いつくままに切ってみたり、繰り返し使いそうなもので切ってみたり、CSSのスコープで切ってみたり…。いろいろな切り口があると思います。 この「いろいろな切り口」でコンポーネントを切ることができる点が、コンポーネント設計を難しくしている所以だと考えています。 そこで今回は、どのような切り口・観点でコンポーネントを切ればよいのか、そのときに気をつけるべきことは何か、といったComponentの設計方法についてまとめてみます。 すべての実用ケースを想定できているわけではないと思いますが、大小いくつかのWebアプリを開発する際に利用してみて今のところいい感じに運用できている方法です(というか自然と収束して出来上がった考え方という感じです)。 はじめ
JavaScriptフレームワークを比較してみよう (2018年4月) トレンドの移り変わりが激しいWebフロントエンド。2017-2018年現在、JSフレームワークで最も有力な3強がAngular/React/Vue.jsの3つと言われています。他に日本で比較的聞くのはRiot.js、Ember.js、Hyperappなどがありますね。 ちょいとFW選定の技術調査でいろいろ調べたりしたので、このエントリでは初学者なりに比較を整理してまとめてみたいと思います。 なお最後にも書いてありますが、実際に使ったりして得られた知見もあれば、入門レベルだと確かめようがないので本やネットの情報や意見の中で多いものの受け売り的になっているところもあります。フレームワークって結局どれがいいのという話は混乱したり場合によっては荒れがちですが、最終的には情報は各自の判断でご利用ください。フレームワークは開発をよ
ソフトウェアの世界には「悪い方が良い」原則という有名なエッセイがある。キレイにレイヤ分けされた一貫性のある良いデザインよりも、一見手抜きっぽい悪いデザインのほうが実は良いときもあるという話だ。この逆説的なデザイン原則を僕は身をもって体験したことがある。それについてちょっと書いてみようと思う。 僕はlldというリンカの現行バージョンのオリジナル作者だ。リンカというのはコンパイラと組み合わせて使うもので、実行ファイルやDLLを作るのに使用される。lldはプロダクトとしてはかなり成功していて、標準のシステムリンカとして採用しているOSがいくつかあったり、GoogleやFacebookなど皆が知っているような大規模サイトの中で広く使われていたりする。 現在のlldは2世代目で、第1世代のlldは僕がプロジェクトに参加する前から存在していたのだけど、数年前にそれを捨てて一から書き直すということになっ
セッションIDやアクセストークン、はたまた業務上で使う一意の識別子など、いろんなところで一意のIDを生成しなきゃいけないケースが存在します。 そこで世間で使われているIDの生成方法について調べてみました。 選択基準 ID生成における要求として、以下の観点が上げられるかと思います。 生成の速度 大量にデータを短期間で処理し、それらにIDを付与する場合、ID生成そのものがボトルネックとなることがあります。 推測困難性 IDを機密情報と結びつける場合、IDを改ざんされても、機密データが見れないようにできている必要があります。 順序性 採番した順にデータをソートする必要がある場合は、IDがソートキーとして使えないといけません。 それぞれについて各生成手段を評価します。 ID生成の手段 データベースの採番テーブル 採番用のテーブルを作り、そこで番号をUPDATEしながら取得していくやりかたです。古い
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 僕の本職はサーバーサイドなのですが、半年くらいReactとReduxを使ったフロント部分を触ったので、書きたいと思います。 先にReact.jsについてですが、本家がチュートリアルをしっかりと用意しており、学習コストも高くなく、悪くないものだなと思いました。 しかし、Reduxが入った途端、めっちゃ複雑になった印象があります。chromeのプラグインを入れて開発するのが普通とか言われたのですが、そんなものを使わないと作業できないくらいに複雑で辛いなぁという印象です(Javascriptは、console.logがあれば、ほぼ開発できる気
MANABIYA 2018-03-24 (sat) Webセッション 3時限目の発表内容 https://manabiya.tech
Native API AccessThanks to NativeScript's superpower, you get access to ALL native apis right in your JavaScript. Learn more → Does it work with Vue 3 or the Composition API? Yes! Since 3.0, Vue 3 is supported. You can use both the Options and the Composition API per your preference. What is NativeScript-Vue? tl;dr it's a custom renderer for Vue that renders to NativeScript views. Does it run in
はじめに Netlify Netlifyは静的なサイトを超高速で提供できるWebサービスです。先日210万ドルの出資を受け話題になりました。わずか3ステップでおしゃれなサイトが作成できるとのことです。本記事の前半ではNetlifyの特徴を軽くまとめ、後半は実際にNetlifyを利用してサイトを作成してみます。 Netlifyの特徴 詳細は公式ドキュメントにあります。今回はその中から一部を抜粋して紹介します。 ビルド、デプロイ、ホスティングの全て Netlifyはフロントエンドのビルド、デプロイ、ホスティングの全てを行います。単純な静的サイトのデプロイであれば下記の3行をコマンドラインに打ち込むだけでできます。 また、NetlifyはGitHubリポジトリとリンクし、GitHubリポジトリにプッシュがある度にgruntやgulpを介したビルドをしたうえでサイトをデプロイしてくれます。 これら
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 可及的速やかにReactが絶滅しますように。 以下はFront-End Developer Handbook 2018の第三部、Front-end Developer Toolsからリンクされているツールと、その簡単な紹介です。 ドキュメントツール 開発者向けドキュメント、APIリファレンス Dash 200以上のAPIリファレンス、100以上のチートシートを一括ダウンロードできる。有料、Mac用。 DevDocs 200以上のライブラリをオンラインで検索できる。無料。 Velocity 中身はDashと同じ。有料、Windows用。
某所で書いたものを公開用に書き直したもの 前提 フロントエンドでTDDは難しい、というかほぼ不可能である。なぜなら事前に副作用をデータとして表現できるか不明だからだ。たとえばあなたのプロダクトの画面の何処かにボタンを追加するために、その内部表現を事前に思い浮かべることが可能だろうか? react-redux などのFluxフレームワークは如何に副作用をアクションとして表現することで、テスト・デバッグのための情報を残すか、という視点で発展してきた側面がある。あの冗長なアクション定義は、全てデバッグのために書いていると言っても、過言ではない。それすら「Textは文字がある」といったトートロジーなデータになりがち。 フロントエンドの現実的な単体テストは、他の開発者のために、自分が書いたコードの要求を満たしているか検知する手段として、防衛的にテストアフターしておく。これぐらいしか現実的な手法がない
javascriptの開発では、sassやtypescriptなどのコンパイル、minifyやautoprefixerでの最適化、依存関係を解決しbundleするなど多様な工程があるので、属人化・職人依存を避けるためにタスクランナーでの自動化が昔から当たり前に行われています。 webpackはこの手のツールのデファクトです。webpackはタスクの自動化支援ではなく、なんでもjsにまとめるという仕事をうまくやる事に特化しています。gulpやbrowserifyで行なっていたようなタスクの自動化はnpm scriptで十分やん、という割り切りを感じます。 なんでもjsで扱えるようにするので、cssや画像やhtmlもjs内にロードでき、設定が煩雑になりにくくなります。 webpackのloaderという仕組みがjsへの組み込みや最適化をうまくやってくれるのですが、どういうものか検証していきまし
こんにちは、一般ノーマルエンジニアのgeta6です。社内ではpixiv SketchというサービスでJavaScriptを書く仕事をしています。今日はPrettierの話をします。 JavaScriptを書くのが大好きな皆さま各位におかれましては、きっと酒のつまみにコードを書くこともあるでしょう。しかし酔っ払いながらコードを書くと、往々にして上記のような書き散らかしをしてしまうことがあります。 このコードは動きます。動きますが、思わず目を背けたくなる汚さです。この世に存在することが許されるべきか疑うレベルです。ESLint先生も思わずブチギレです。当然ですね。 CIにLintを仕込んでいた場合は当然通りませんし、gitのprecommit hookにLintを仕込んでいた場合はgit commitすら許されません。堅牢なシステムは酔っ払いにコードをコミットする権利すら与えてくれないのです。
はじめに 筆者が今携わっているプロジェクトでは Vue.js(以後は Vue)が使われています。 そのプロジェクトで一度 「Storybook」 というツールを導入しようとしたことがありました。結局導入は見送ることになりましたが、その時に Storybook に良い手応えを感じたため、あらためて簡単なプロジェクトを作り Storybook を試してみました。 下記がデモです。 デモ 1(プロジェクト) デモ 2(プロジェクトの Storybook) Storybook 自体まだまだ新しいプロジェクトのため、ネット上にも情報は多くありません。この記事を読み Storybook に興味を持ってくれる人が増え、ネット上に Storybook の情報が増えていけばいいな、と思います。 この記事の対象読者 Vue を使って開発をしている人 / する予定のある人 / 興味のある人 Vue のプロジェク
2018/12/23 リンク切れしていたものを削除 & リンクを追加 https://qiita.com/sinsengumi/items/e20342d13cbdd7ac2304 を読んで、すこしだけもやもや感がぬぐえなかったので、適当に自分が思ってる「今のJavaScriptはこんなかんじ」というのを書いた。 EcmaScript だいじなこと EcmaScriptとは、プログラミング言語ではない。 EcmaScriptとは、Ecmaインターナショナルが決めているJavaScriptの言語仕様のこと。 Ecmaとは、European Computer Manufacturers Association の略で、要は世界のコンピュータ関連の仕様を決めてる闇の組織みたいなところ。 (→History of Ecma) なんでEcmaScriptとかいうものがあるのか? 大昔、JavaScr
TypeScriptは型がついたJavaScriptです。プログラミングにおいて型があることの恩恵は大きく、近頃AltJSの代表格として人気を集めています。TypeScriptはもともと型のないJavaScriptで書かれるコードに型を付けることを使命としていることもあり、たまに変な型が追加されます。例えばTypeScript2.8で追加されたconditional typesはずいぶん注目を集めました。これによってTypeScriptの型システムの表現力が広がりましたが、一方でTypeScriptを書いている人の中には、よく分からない型が増えてついて行けない、一部の人たちが長くてよく分からない型定義を書いて喜んでいるだけと思っている方もいるのではないでしょうか。実際、健全にJavaScriptを書いていれば、自分でそのような変な型を書くことはあまり多くありません。 そこで、この記事ではT
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く