フロントエンドを楽にするために
フロントエンドを楽にするために Qiitaを支えたい技術 at 時雨祭 About HN: mizchi Qiitaの方からきました(入社半年たったらしい) Reactオジサンはそろそろ飽きてきた Angularに興味が無いのでこっちにきた 最近の業務 Kobito for Windows Closedβ中: もうちょい待ってろ お前らウェブエンジニアはWindows使わないのでβユーザー集めにくいんじゃ 省力モード 一昨日がClosedβリリースだったんで察してくれ！！！ ついさっきまでバグフィックス用のビルド作ってた Qiitaを支える技術? 4ヶ月ほどほぼソロ作業 正直カウボーイぎみ OSSでドキュメントガンガン書いてカバー(したい) 業務から派生したOSS mizchi/arda Flux フレームワーク mizchi/stone-skin IndexedDb ラッパー mizch
論理削除はなぜ「筋が悪い」か
「論理削除が云々について - mike-neckのブログ」を読んで。 データベース設計において、「テーブルの書き換えをするな、immutableなマスタと更新ログによって全てを構成しろ」というこの記事の主張はモデリング論として全く正しい。 だが、残念なことに、ディスクやメモリが貴重な資源だった時代の技術であるRDBは、そのようなモデリングに基づいて設計されたデータベースには必ずしも適していない。 第一の問題は、RDBに対してなされる様々な「更新」（トランザクション）は不定形（どのテーブルをどのように修正するかはアプリケーション依存）だという点。不定形な「更新」を時系列にそってRDBに記録していくのは、設計と並走性の点において困難あるいは煩雑なコーディングが必要になる（というか、そのような「イベント」による「変化」はREDOログに書き、その更新された「状態」をテーブルに反映していくというのが
Goでchannelがcloseしてるかどうか知りたい というアンチパターン
そういえば金沢に行って来た話の2〜4日目をかいてる途中で2ヶ月くらい経ったことに気付きましたが、まぁその話はおいておいて今日はGoの話です。 さて、このタイトルを見てGoに詳しく賢明な読者の方々は「あぁまたこの話題だよ、Goでchannelがcloseしてるかどうか知りたいようなパターンはだいたい書いてるアプリの設計とかchannelの使い方が間違ってるんだからやめとけ」と眉をひそめるかもしれません。まぁちょっとまって! オレもそうなんじゃないかなぁという気はしているし、ハマリどころがありそうということはうすうす分かってるけど一応調べて考えてみてもいいじゃないか。 結局の所調べて「こうすればいいね!」ってことは分かったんですが、それも破綻する場合があるので、アンチパターンだなぁと思いつつこの記事を書くことにしました。 まずGoのchannelのナイーブさを再確認する そもそもGoのchan
雑な発想を活かすチーム作り - クックパッド開発者ブログ
インフラストラクチャー部の成田（@mirakui）です。インフラストラクチャー部は、クックパッドで扱っている全サービスのサーバを設計・構築し、運用しているチームです。2015年3月現在、6人のメンバーで運用をしています。 さて、この運用というのは外から見ていると保守的な仕事に思えるかもしれませんが、その実、とてもクリエイティブな仕事です。クックパッドのサービスは一日平均で10回以上デプロイされており、アクセスも日々増え続け、状況は刻一刻と変化しています。今日動いているサーバ構成が、一年後に通用するとは限らないわけです。そんな変化に追従するためには、サーバを常に改善していかなければなりませんし、チームにも柔軟な発想が求められます。 「さあブレストしよう」→アイデア出ない問題 さあ業務を改善しよう、と意気込んでブレインストーミングを開いても、なかなか十分なアイデアが出きらないのはよくある話です
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
BLOGOS サービス終了のお知らせ
