CircleCIからGitHub Actionsへの移行 (Node.js) - 余白
自作のライブラリのCIをCircleCIからGitHub Actionsへ移行したメモ github.com github.com 特にメリットがあるから乗り換えたとかいうわけでもないけど、GitHubだけで完結するならそれに越したことはない ファイルの場所 .github/workflows/<ワークフローの名前>.yml だが、いまのところ複数作るユースケースが見えないので main.yml とした。 実行環境 ubuntu-latest を選択した。特に理由はないけど一応MacOSやWindowsも選べるっぽい？ Software in virtual environments for GitHub Actions - GitHub Help を見るとわかるが、 めちゃくちゃ充実したプリインのソフトウェアがある。 yarn や Git、Docker、Chromeもなんの設定もなく最初
転職のお知らせ - 余白
写真は妻が作った雪だるまです。 From: 株式会社Kaizen Platform 2/28が最終出社日でした やってたこと Webフロントエンド SPA開発 (React/TypeScript) Schema-first GraphQLによるAPI仕様中心開発の整備 UX/UI設計 Webパフォーマンス計測、改善 その他 lacolaco.hatenablog.com To: bitbank株式会社 4月から入社します 週4日にしてもらいました 空いた1日はClassiでの技術顧問とOSS、個人開発などに使います やりたいこと ある程度の規模に育ったAngularアプリの開発に関わりたい Angularのエキスパートとして持てる力を尽くしてチームを加速させたい Web技術とブロックチェーンのこれからについて、持論を持てる程度の学びを得たい ついでにマイクロペイメントまで学びを得られたら嬉
昨日のツイート群への個人的な回答 - lacolaco
技術的に誤った認識でnot for meされるのは悲しいし寂しいので、誤った認識に反論しておきます。 React の過激派(高尚なコードを求める人々)と Vue の過激派(動けば良い人々)と Angular の過激派(オブジェクト指向信仰の人々)— ユーン🍆 (@euxn23) August 7, 2018 何を以ってオブジェクト指向とするかは人それぞれだけど、Angularはオブジェクト指向ではないと個人的には思ってる。 クラス使ってたらオブジェクト指向、というのであればそれは否定できない。 ちなみに過激というかアドバンスドな設計をすればするほどAngularもRxJSをベースにしたリアクティブプログラミングに寄っていく傾向にある。 AngularとAngularFire（FirebaseのAngular向けライブラリ）を使って簡単なアプリケーションでも書いてみれば多少体感できると思う
無責任な"not for me"発言は迷惑なのでやめてほしい - lacolaco
愚痴。 最近特定の技術やライブラリ、ツールなどに対して、「自分には合わなかった」のような発言をする人をよく見かける。 ちょっと前だと「○○はクソ」のような直接的なdisが目立っていた気がするので、少しは丸くなったつもりなのかもしれないが、 Angularというひとつの技術のユーザーコミュニティを主催する僕としては余計に迷惑だ。 もっと慎重になれ medium.com AirbnbがReact Nativeを使うのをやめた記事、これは本当に偉い。 技術選定を行い、結果的にマッチしなかった、というレポートには、最低限次の項目が必要だと考えている。 開発の目的 選定理由 マッチしなかった理由 このどれが欠けてもいけない。単に言葉遣いが柔らかいだけでdisと変わりないどころか、下手するとFUDにすらなり得る。 FUD - Wikipedia FUD（英: Fear, Uncertainty and
GraphQLとRESTfulについて今日考えてたこと Backend for Usecase/Resourceについて - 余白
DISCLAIMER: これは本当にただのメモ書きで、これがベストプラクティスだとかいう話ではないので、同じようなことを考えてる人いたら今度議論しましょうよ、って程度の話の種。 GraphQLを使うべきスポット、RESTfulが好ましいスポットについて今日ぼんやり考えていて、なんとなく言語化ができる気がするので文字起こししてみる。 Backend for UsecaseとBackend for Resource バックエンドのAPIには2種類あって、 「データ」を構成する「リソース」を提供するもの アプリケーションの「ユースケース」がもつシナリオのなかで登場する「データ」部分を埋めるためのもの を区別することが必要そう、と思っている。 まず前者を Backend for Resource (BFR)と呼ぶことにする。これはわかりやすくて、これはまさしくRESTfulそのもの。 RDBやそう
「やはりHTML/DOMは再発明されるべきじゃないか」に対する感想 - 余白
mizchi.hatenablog.com エモにはエモ。 わかる だいたいわかる。そもそもSPAの必須パーツであるクライアントサイドルーティングなんてブラウザ機能の再実装の極致だし、ブラウザ上でアプリケーション作るとなるとブラウザに足りてない部分はラップして、アプリケーションプラットフォームにしたてる必要がある。 Angularはアプリケーションフレームワークとして、HTMLの限界をカバーするために独自にHTMLのパーサーを積んでいる。 テンプレート構文をサポートするためでもあるが、おそらく中途半端にブラウザの機能に頼ってデータモデルからビューへの投影にノイズが含まれるよりは、 Angularという世界に閉じた一気通貫なフローを採用して、ブラウザとのコミュニーケーションを最小限にしたかったのも大きいと思う。 というか、Native ScriptとかWeb WorkerとかSSRとか、クロ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
