こんにちは。エンジニアの小椋です。 最近になって初めてTypeScriptを使う機会があり、TypeScriptもっと使おう!😠😠😠と思ったので、今回はVue.jsでTypeScriptを使う方法を紹介したいと思います!
![TypeScript + Vue.js の始め方](https://cdn-ak-scissors.b.st-hatena.com/image/square/39e482c008d605a5b5f9180e98756d084baf2b67/height=288;version=1;width=512/https%3A%2F%2Fblog.asial.co.jp%2Fogp-logo.jpg)
こんにちは。エンジニアの小椋です。 最近になって初めてTypeScriptを使う機会があり、TypeScriptもっと使おう!😠😠😠と思ったので、今回はVue.jsでTypeScriptを使う方法を紹介したいと思います!
有言実行しなきゃね... ちょっと来月の頭くらいまでに、「本当にAngularは学習コストが高いのか?」っていう内容のブログを書くので、書いてなかったら怒ってください— lacolaco / Suguru Inatomi (@laco2net) 2019年1月24日 この記事では、「学習コストが高い」と評されがちなAngularについて、本当にその学習コストは高いのかということについて紐解いていきます。 先に言っておきますが、ReactやVueをはじめとする他のフレームワークとの比較はしません。また、なかなか本題に入らない回りくどい文章になる予定なので、予めご了承ください。そして筆者はAngularが大好きです。Angularが好きな人間が書いたポジショントークであることは前提として読んでください。 そもそも学習コストとは何だ? まずはじめに、「学習コスト」って何だ?っていうところから始め
ReactiveProperty は MVVM + Rx でプログラム組むときにいい感じにしてくれるものですが MVVM だけでも大変なのに Rx なんて魔法みたいなものを覚えないといけないなんて…!!ということで学習コストが高いので導入をためらうことがあると思います。 当然、何かを使うということは導入のためのコストを払って開発を通じて回収していかないといけないので、そこのバランスが取れないものをあんまり入れると大変なことになりますよね。 ということで Rx 知らない人向けに Rx 成分無しで ReactiveProperty 使って感覚を掴むための使い方を紹介したいと思います。 導入 ReactiveProperty の NuGet パッケージを追加して終わりです。 UWP, Xamarin.Forms, WPF のような XAML を使うものでいい感じで動きますが、まぁ使えそうだと思っ
最新版 最新版はこちらになります。 MVVM をリアクティブプログラミングで快適に ReactiveProperty オーバービュー 2020 年版 前編 - Qiita 本文 MVVM + リアクティブプログラミングの組み合わせを快適にするためのライブラリのReactiveProperty解説記事です。 github.com 以下のNuGetから入手できます。 www.nuget.org ReactivePropertyの特徴 ReactivePropertyは、MVVM + Rxを支援するための機能を有したライブラリです。以下のような機能を持っています。 ReactivePropertyクラス ReactiveCommandクラス ReactiveCollectionクラス ReadOnlyReactiveCollectionクラス INotifyPropertyChanged/INo
Chrome でマイクからの音声を録音して、その音声認識で書き起こしも同時に行うツールを作った。 recording-studio.netlify.com で遊べる。 Chrome に搭載されてる Web Standard Proposal? の SpeechRecognition API を使っている。 developer.mozilla.org Chrome のみだが、 PC Chrome だけではなく Android Chrome でも動作確認済み。 ブラウザをオフラインにすると動作しないので、このAPI の 中身はたぶん Google Speech to Text API だと思われる。 出力 録音したものは webm ファイルとしてダウンロードできる。認識されたテキストも、タイムスタンプ付きのプレーンテキストなので、適当にもっていって、ぐらいの気持ち。 クラウドで音声認識してるこ
本記事は、下記の記事の翻訳です。著者の許可を得て翻訳しました。 この記事はフォースクエアの技術的リーダーシップを簡潔に説明したガイドだ。 ベン・ホロウィッツの「良いプロダクトマージャー、悪いプロダクトマージャー」からインスピレーションを得ている。 チームワーク / Teamwork 良いテックリードはチームの一員として振る舞い、自分の成功とはチームが成功することだと考える。面倒で退屈な仕事の一部を担って障害物を取り除き、チームが100%のパフォーマンスで稼働できるようにする。チームの技術的能力を拡大し、システムの重要な知識が属人化しないように務める。 悪いテックリードは注目の集まる仕事で自分の成果を示すことを好む。その成果は部分最適に留まり、開発チームのアウトプットを増やすにはエンジニアの人数を増やすしかない、という状況から脱することができない。 技術的ビジョン / Technical v
おもしろライブラリを見つけて興奮しているので紹介します。 UIスレッド(メインスレッド)からユーザー操作をブロックしてしまうような重い処理を逃がす off-the-main-thread を実践しようとなると、実際に問題になるのは、ほとんどの処理は何らかの形で DOM を参照し、それに連なるものが処理時間の殆どを占めている、ということです。 off-the-main-thread の時代 - mizchi's blog DOM に触れない WebWorker でビジネスロジックを処理するのは、ある種の健全性(Universal/Isomorphic)を手に入れるための「縛りプレイ」として有用ですが、現状は実用上のメリットが殆どありません。 例えば react / redux の reducer で、ビジネスロジックを worker 側に移して処理できるぐらいアイソモーフィックに(DOMに触
今まで自分で作ったものが十数個、仕事で5社ぐらいの redux を見てきたので、その結果思うところを書く。 前提として、自分はエコシステムに乗るという意味で今では redux 肯定派だが、redux それ自身が過剰に抱えている複雑さはもっと分解されるべきだ、という立場。 Redux がうまく設計されているとどうなるか 一貫した一つの設計論に従うので、考えることがなくなる 難しさが廃されるのではなく、難しい部分が一箇所に集中する。React Component の末端では、何も考えることがなくなる。状態管理という難しい部分を作る人と、末端のコンポーネントのデザインに注力する人を分けられる。 大規模になっても設計が破綻しにくい、というエンタープライズ向きな特性を持つ。が、その技術基盤は(静的)関数型由来の考えが多く、基礎設計や基盤理解にはハイスキルが要求され、需要と適用対象のミスマッチを感じる
某社で自分が React/Redux + TypeScript などの講習をやってみた結果、TypeScript 入門用資料が必要だと思って書いたやつです。 このドキュメントのターゲット TypeScript で書かれたプロジェクトに参加する人 TypeScript を導入するために、その事前知識が必要な人 このドキュメントの読み方 ES2015 for Beginners ES2015 for ES5 Programmers ES Modules 非同期表現: Promise と async/await TypeScript エコシステム編 自分が React/Redux などの講習でいろいろやってみた結果、 ES2015 と TypeScript を同時に教えると、初学者は何がどの概念に由来するかの区別が出来ずに混乱します。なので、ES5 -> ES2015, ES2015 -> Ty
やってみた。実用に耐えうるかはわからないけどメモ。 環境構築 node.js 8.11.x(LTS) Azure Function Core Tools v2(preview) VSCode Azure 拡張機能 Azure Functions 拡張機能 TypeScript 3.0 npm install -g typescript やってみよう Visual Studio Code の左のメニューから Azure のアイコンを選択。自分の Azure のアカウントでログインしてたら使えるはずです。(ログインしてない状態だとどうなってるのか把握できていない) FUNCTIONS の部分にある Create New Project... を選択します。 フォルダを選択して言語は JavaScript を選択します。 ターミナルを出して以下のコマンドを打ちます。(Windows だと Ctr
元糞コードマイスターとしては、生産性については思うところある。 技術的到達深度が深い人じゃないとそもそもかけないコードってのももちろん存在して、その前提で10倍とか100倍になりうる話をする。 そもそもマイナスになる人がいるって話。 隠しパラメータをモデル化 エンジニアA:「週に10の成果を出して3の負債を生む人」を考える。この人は開発を止めてリファクタリングをすれば10-3 = 7の技術的負債を返却できるとする。 ここで正確には成果10には* aの係数が掛かっている。これはプロジェクト開始時1.0で、技術的負債が貯まるほど0に近づいて行く 次に、エンジニアB:「週に15の成果を出して10の負債を生む人」を考える(これにも係数aがかかる)。この人は見た目上は上の人の1.5倍速く成果を出しているように観測できるが、負債もたまりやすい。リファクタしても綺麗になりにくい。 これは割とエンジニアに
まだプロトコルを正しく理解しておらず、とにかく動くところまで。そのメモ。 こんな感じ コード GitHub - mizchi-sandbox/hello-data-channel simple-peer と react で雑に一筆書きした。simple-peer は webtorrent などでも使われていて、筋が良さそう。 none => initiator | receiver => connected と mode が遷移する。 // <div class="root"></div> みたいなDOMがあることを前提 import Peer from "simple-peer"; import React from "react"; import ReactDOM from "react-dom"; let peer: Peer.Instance = null as any; clas
こんにちは。 この記事ではAngular CDKの次期アップデートで提供される、 drag-and-drop 機能を紹介します。 執筆時点ではまだnpmパッケージとして公開されていないので、一般に利用できるまでにはもうしばらくかかりますが、 もし早く使いたい方は、次のコマンドで開発版ビルドをインストールしましょう。 なお、開発版ビルドですので自己責任でお願いします。 $ yarn add angular/cdk-builds CDK drag-and-drop drag-and-dropはその名のとおり、UI上でのドラッグアンドドロップ操作をサポートするものです。 @angular/cdk/drag-drop パッケージから提供される DragDropModule をインポートすると、次の2つのディレクティブ、コンポーネントが利用できます。 cdkDrag ディレクティブ cdkDragデ
技術部のヨシオリです。 Netflix が Chaos Engineering の論文を公開して 2 年ほど経ちました。 クックパッドは最近、 Chaos Engineering を導入する事を決めました。 この記事ではその背景を紹介したいと思います。 そもそも Chaos Engineering とは Netflix では Failure Injection Testing として、営業時間中に意図的に障害を起す事をやっていました。Chaos Monkey というインスタンスとサービスを落すものから Chaos Gorilla、Kong という availability zone や region 単位で障害を発生させるものなどです。 その経験から Chaos Engineering というものが提唱されました。 Principles of Chaos Engineeringによれば C
このテーマで書く前に、まず、最初に自分に多少の偏りがあることを認めておかなくてはなりません。 オブジェクト指向より、関数指向寄り オブジェクト指向のアプローチは有用だが、ただしそれを実現する手段はクラスと継承ではない。 階層化されたツリー構造(GUI/リレーショナルな参照構造)に埋め込まれる状態はコード品質を悪化させるので、できるだけ出現するべきではない。 ただし、状態は確実に存在する。だからこそ慎重に扱うべきだ、という派閥です アンチパターン: 特に理由もないクラスメソッドへの所属 何かのバリデータを実装したいとします。 その関数がどこに所属するかについて、よく見るこれらの実装は全部アンチパターンといっていいと思います export class Validator { static validate() {...} } export class Validator { validate(
この記事ではAngularDart/Flutterの文脈で新しいコンポーネント設計パターンとして広まりつつあるBLoCパターンを、Angularの語彙で理解し、実装する方法を紹介する。 BLoCパターンとは BLoCとは、Business Logic Componentの略である。 BLoCを使ったアプリケーションの実装パターンをBLoCパターンと呼ぶ。 まず誤解を招きそうなポイントとして、この"Component"はReactやAngularなどでいうところのビューを構築する"コンポーネント"ではない。 一般的な単語としての、アプリケーションを構成するひとかたまりの要素という意味の"Component"なので誤解しないこと。 対比するレベルとしては、"UI Component" vs "Business Logic Component"のようになる。 BLoCは複数の環境向けにアプリケー
Webにかぎらず、アプリケーションというのは作って終わりではなく、その後も継続して改修・改善されていくケースが多い。受託で開発して納品して終わりというケースでも、納品した先にメンテナンスする人がいる。 この記事では、Angularアプリケーションの開発において、いかにメンテナンス性を維持して、持続可能なプロジェクトを構成するかについての個人的な見解をまとめる。 フレームワークを邪魔しない Angularアプリケーションのメンテナンスにおいて、いちばん重要なことはいかにAngularのアップデートを阻害しないかという点に尽きる。 これはAngularに限った話ではなくフレームワークと呼ばれるものを使うなら常に必要なことであるし、 アップデートが定期的に降ってくることが決まっているAngularであればなおさらである。 アプリケーションの一番根幹となる部分の鮮度が落ちれば、その他の部分はそれに
僕がAngularアプリケーションを書くときに頻出する実装パターンを紹介する記事です。続くかどうかは未定です。 onDestroy$ ngOnDestroyメソッドが呼び出されたタイミングでemitされるEventEmitterを作っておき、RxJSのtakeUntilパイプなどで使う実装パターン。 ngOnDestroyメソッド内でunsubscribeメソッドを呼び出すよりも宣言的で意味が取りやすいし、忘れにくい。 実装例はこんな感じ。ReactiveFormsModuleを使うときにvalueChangesに引っ掛けることが多い。 import { Component, OnDestroy, OnInit, EventEmitter, Output } from '@angular/core'; import { FormGroup, FormControl } from '@ang
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く