タグ

ブックマーク / havelog.aho.mu (10)

  • JavaScriptよ。文明を捨て、自然に還れ。

    Web ナチュラリスト フィードを眺めていたら Alex Russell 氏の新作が投稿されていた。 The "Developer Experience" Bait-and-Switch | Infrequently Noted 来の趣旨については原文を読んでもらえばいいし、下記はこれを読んだ上で普段の考えを踏まえて脳裏をよぎったポエムである。 我々は複雑性で仕事をしている 仕事をしている、もしくはそれでお金を稼いでいる。誰もが。 私は 2012 年頃から Web の、特に Web フロントエンドの複雑性に加担している自覚がある。 Web の専門性が高まることはその技術領域に深淵な価値があることを示唆し、それに携わることの価値を相対的に向上させることができる。 私の活動そのものは些細なものだが、かくして 2018 年現在の Web はかくも複雑になることに成功し、エンジニアリングの名の下

    JavaScriptよ。文明を捨て、自然に還れ。
  • アーキテクチャ編: SSR と CDN ( Fastly ) とユーザー依存情報の分離(新規開発のメモ書きシリーズ4)

    新規開発のメモ書きのラスト シリーズだったはずなのに、色々あって前回のエントリから1ヶ月あきました。_:(´ཀ`」 ∠): 今回の話の中心は結果的に「Server Side Rendering との折り合いの付け方」と「Fastly を利用した動的コンテンツのキャッシュ戦略」です。 このシリーズの他の記事はこちら。 技術要素編: web アプリが新陳代謝を続けるための依存関係の厳選 ビルド設定編: UA に応じた最適な JS バンドルの配信と webpack との距離感 コード設計編: context による縦軸分類とレイヤードアーキテクチャ まずは全体的なアーキテクチャ像 次の図はアーキテクチャの全体像です。クライアントサイド寄りの範囲を中心に書いているため、バックエンドな Microservice 群以降がおざなりな図ではありますがご容赦ください。 主要リソースは Fastly を通じ

    アーキテクチャ編: SSR と CDN ( Fastly ) とユーザー依存情報の分離(新規開発のメモ書きシリーズ4)
  • コード設計編: context による縦軸分類とレイヤードアーキテクチャ(新規開発のメモ書きシリーズ3)

    流行りの monorepo 風味と DDD 風味? 今回はコードの設計について書き残します。主に JavaScript 界の話です。Web アプリケーション全体の設計は次回で、今回はコード面の設計に限定して書き留めています。プロダクト全体のアーキテクチャは次の記事で述べる予定ですが大雑把には、メディアっぽいサービスでありつつも SPA + SSR が許容される程度には要件定義の時点でコードの行数がかさむことが約束されたプロダクトです。 今回は大きく分けて下記について述べています ディレクトリ構造 オブジェクトの種類と責務 Flux 的なデータフロー あくまで風味なので今回、専門用語の意味ズレなどは優しくお願いします... このシリーズの他の記事はこちら。 技術要素編: web アプリが新陳代謝を続けるための依存関係の厳選 ビルド設定編: UA に応じた最適な JS バンドルの配信と web

    コード設計編: context による縦軸分類とレイヤードアーキテクチャ(新規開発のメモ書きシリーズ3)
  • リモートワークの勘所と限界について1年くらいの感想、組織にとっての選択肢作りの話

    1年くらいリモートワークを続けてみた感想 まず当然ながら「リモートワークは生産性が高い!これこそ未来のワークスタイル!」のような感想はありません。 生産性やコミュニケーションに関連するメリット、デメリットをうまく相殺しきれれば、生活の自由度だけ向上してハッピー、と考えています。 今は自宅かレンタルオフィスのいずれかを作業場として開発などを行いつつ、社がある渋谷には1泊2日の出張を月2回するようなペースで仕事をしています。基Slack でテキストチャットによるコミュニケーションをメインとしつつ、必要があれば MTG に Hangout でビデオチャットで参加します。 生産性は大して上がらない 期待していた生産性は、それほど向上することはありませんでした。 東京にさえいなければ気軽に MTG に呼び出されることもありませんし、開発に充てることが可能な時間は若干増えています。通勤時間が長

    リモートワークの勘所と限界について1年くらいの感想、組織にとっての選択肢作りの話
  • AngularJS についての所感

    AgularJS に対する気持ち 所感といいつつ、主に自分がつらさとして感じていることを書く。所感シリーズとしては jQueryについての所感 も併せて読みたい。 この学習曲線の中でいうと、たぶん今の自分は Very Cool! の頂点から降りている最中くらいだと思う。そして、マサカリをふりかぶった諸兄にひとつだけ言いたいのは、共感脳を養った方がモテるということだ。 チキンハート的弁解: 以下はAngularJSに関するつらさを述べることに専念するために、美点を挙げていないだけであってAngularJSを全方位的に貶めたり、何かと比べて明確にクソだというような意図はない。 画像は AngularJS: The Best Parts · Anand Mani Sankar からの引用。X軸にある www.bennadel.com は AngularJS 大好きさん。 辛1. $scope が

    AngularJS についての所感
  • Concatだけでビルドを済ませてた例(Backbone.jsとAngularJS)

    Concatでどこまで戦えるのか @jxck_ browserify使ってるんだけどあんま意味ない感じになっててつらいんだよねーっていうのを昨日 @ahomu に話したら、concatで全然いけますよって言われたからさっき乗り換えた。 — Kazuhito Hokamura (@hokaccha) August 6, 2014 (^ω^) 全然いけますよ 依存管理をサボってconcat 以下、「依存管理に労力を割きたくない」という理由で依存管理を省略した場合に、concatだけで破綻無くビルドするためにやっていたパターンの紹介。いけますと言った手前はあるが、最終的には現場によってケースバイケースということで、どうかひとつご容赦願いたい。 Case 1: Backbone.js Backbone.jsの場合、extends に代表されるクラスベースのオブジェクト指向モデルに多少の制約が必要に

    Concatだけでビルドを済ませてた例(Backbone.jsとAngularJS)
  • Docker を Mac で使ってみた(Nodeアプリ例)

    色々あってDockerした。さっくりとアプリ作るならHerokuも便利なのだけど、Dockerをサポートする他のPaaSも使えた方が便利そうな風潮を感じたので。 1. インストール&導入 Mac OS X - Docker Documentation Releases · boot2docker/osx-installer からpkgインストーラをダウンロードして実行。適当にはいる。 boot2docker Mac OS X上で、Dockerを走らせるためのLinuxなVMを boot2docker で立ち上げられる。(boot2docker/boot2docker はpkgインストーラに含まれている) boot2docker init boot2docker up boot2docker init で初期化 boot2docker up で起動。dockerコマンドにホストを教えるための

    Docker を Mac で使ってみた(Nodeアプリ例)
  • Angularそっちのけで、Vue.jsについて所感

    Vue.js 軽量でパワフルなデータバインディングMVVM, vue.jsで遊んでみた - mizchi's blog を読んで触発されたので、自分も外見的に良いなと思ったポイントだけ書き留めてみます。さすがに実戦投入できていないので、そのあたりの精度は悪しからず。 サンプルコードの雰囲気 サンプルコードとか自分でちょっと触ってみたときの感触からは、以下のポイントが気に入りました。data-bidingsとかは前提として便利です。はい。 覚え切れそうな分量のAPI Class: Vue - vue.js 脳みそちっちゃいので助かります。それに尽きる。 プロパティによる宣言っぽさ Angularだとイベントハンドラ類を書くにも、$scopeに都度ハンドラを仕込んでいくのがあまり好きでないです。工夫で回避できそうですが、与えられたスタートが下記のような状態であることには変わりません。 angu

    Angularそっちのけで、Vue.jsについて所感
  • Gruntについて最新の気持ち

    思いつき だいぶ前からGrunt周りというかGruntそのものへの関心が薄れゆくなか、タスク周りがやたらと充実してきたエコシステムの恩恵を、ただただ享受するにとどまっている。 業務で700行のGruntfile.jsを見かけて、SAN値をもっていかれた折に前々から感じていた疑念が表に出た。 「これ、Gruntに仕事させすぎじゃないの」 分担してもよいのでは 前述の700行のなかには、ファイルのビルドをはじめとして、ユニットテスト、E2Eテスト、ドキュメント生成、ローカルサーバー、LiveReload etc etc etc ...すべてひとつのファイルに入っていた。 (; ⁰⊖⁰) Oh... いまいち感覚的なトコロなので表現しづらいのだが、役割としてあまりにGruntfileで表現している内容がごった煮すぎるように思う。 自分の場合、テスト周りはtestemにしていて、ドキュメント生成系

    Gruntについて最新の気持ち
  • `that = this` について思ったこと

    thatに思いを馳せる JavaScriptにおいて that = this とか self = this なパターンを頻繁に使うと、作業者の理性が保証されない場合に下記に示す2点の問題が起こりう得ると思っている。 「あー、どうなのかなー、うーん」と思いながら書いてみる。 1.メソッド分割が適切におこなわれない雰囲気 ちょっと極端かも知れないが、Backboneっぽいコードを例にしてみる。 initialize: function() { var that = this; this.listenTo(this.entity, 'success', function() { var bar = that.foo(); that.$el.find('.qux').text(bar); // long. // long.. // logic... }); this.entity.execute(

    `that = this` について思ったこと
  • 1