Riot.jsの落とし穴まとめ - Qiita
はじめに 軽量かつ学習コストも低めで書きやすいライブラリのRiot.jsですが、いわゆる落とし穴がいろいろあります。が、このライブラリに関する日本語の記事があまり多くなく、コード書いていると突然「あれっ！？」となることがたまにあるので、自分が知っているものを書いていきます。 ※執筆現時点でのバージョンは2.4.1です。 ※2016/11/10追記 既に3.0.0-alpha.13がリリースされた今、2.4.1なんて古いバージョンを使っている方はいないと思いますので、今の時点での2系の最新である2.6.7でも確認しました。 親タグマウント時に子タグもマウントされる タグ(.tagのこと)がネストしていると、親タグをマウントすると子タグも一緒にマウントされます。 例えば以下の様な場合、親タグ（appタグ）で何か処理する必要があって、その結果でマウントする子タグを決めたい場合、子タグ（child
Atomic Designの考え方と利点・欠点 – wkr.
Atomic Design はデザインシステムを作る方法論となります。 デザインシステムというのはスタイルガイドやブランドのガイドラインなどを指すようです。 日本だとAbemaTV（アベマ TV）で使われています。 （Atomic Design を実案件に導入 - UI コンポーネントの粒度を明確化した結果と副産物 | ygoto3.comより） Atomic Design は今までのページ単位と違いコンポーネント単位でデザインカンプを作る考え方です。 作ったコンポーネント同士の組み合わせでページを作ります。 Atomic Design はコンポーネントの単位を 5 つに分けています。 その 5 つの単位は Atoms（原子）・Molecules（分子）・Organisms（有機体）・Templates（テンプレート）・Pages（ページ）です。 各コンポーネントの詳細は次のとおりです。
開発チーム内の“宮大工”はこう活かせ～freeeの「巨匠システム」がいろいろ示唆深い - エンジニアtype | 転職type
エンジニアが働く上で気になる【開発環境】に焦点を当てた、チーム紹介コーナー。言語やツール類を紹介するだけではなく、チーム運営や開発を進める上での不文律など、ハード・ソフト面双方の「環境づくり」について深掘りしていく。 エンジニアのような専門スキルを武器に仕事をする人たちにとって、「スペシャリスト」は一度は憧れたことのあるポジションだろう。誰もが頭を悩ます課題をコードで解消し続け、周囲にすごい！と言わしめる。そんな仕事人生を全うできたら、これほど楽しいことはない。 海外の大手テクノロジー企業は各種スペシャリストを破格の待遇で雇う傾向がある一方で、日本企業では「スペシャリスト＝職権の限られた一専門職」扱いというところも。ビジネスそのものをけん引するのはディレクターやプロダクトオーナーであるとされ、収入面でも彼らの方がよかったりする（※参照記事）。 結果、経営者や開発チームのマネジャーは、「実力
Golang vs PHP7(追記あり) - GMOインターネットグループ グループ研究開発本部
Golangが一番パフォーマンスが良いかと予想していましたが、全く逆の結果になってしまいました。 Golangが遅い理由 遅い原因をいくつか考えて改善できないか試してみました。詳細は省きますが、以下の点については問題なさそうでした。 goroutineはリクエスト単位で起動している コネクションプールは有効になっている BeegoのORM特有の処理は主原因ではない(標準ライブラリのsql関数と大差なし) DB側のCPU使用率は100%になっているが、CPU使用率とメモリ使用量はPHP環境と同程度の負荷になっている ここまで確認して、プロファイラを使った方が良さそうに思えたので、いったんプロファイラで状況を確認するために、標準で提供されていて手軽に使えそうなpprofを使ってみました。topで確認すると次のような結果がでました。 (pprof) top 20 -cum 920ms of 15
go-sql-driver/mysql でプレースホルダ置換をサポートしました : DSAS開発者の部屋
前回の記事で少し触れましたが、 go-sql-driver/mysql にドライバ側でのプレースホルダ置換を実装するプルリクエストを出していました。 それがマージされたので、背景のおさらいと利用方法を紹介しておきます。 背景 Go の database/sql の概要については前回の記事で解説しました。 そこで説明したとおり、 DB.Prepare() を使わずに直接 DB.Exec() や DB.Query() を使った場合、 ドライバ側でのプレースホルダ置換に対応していないドライバでは prepare, exec, close で3回のラウンドトリップが発生することになり、パフォーマンスが悪くなります。 基本的には DB.Prepare() を使えばいいのですが、前回の記事で修正したスケーラビリティの問題は Go 1.5 になるまで直りませんし、 IN 句があるSQL文などで事前に P
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Redux Middleware Wars (Japanese)
