自宅で美味しいコーヒーを飲むためにどういう順序でお金を使うべきか
みなさんこんにちわ、カカオ豆です。 皆さんは家でコーヒーを飲みますか？僕は一日4杯くらい飲みます。 コスパ良く美味しいコーヒーが飲みたすぎて自家焙煎までしはじめて、職場の同僚にもその良さを布教しまくるようなウザムーブをかまして、気がつけば2年が経ちました。 さて、自宅コーヒーは、ちょっと気をつけて投資するだけでその辺のカフェくらいなら余裕で追い越せるくらい美味しいのが淹れられるようになります。 え？「プロをなめんな？」 いえいえ、もちろん超こだわったお店で超こだわる客に出す超高い一杯を超えるのは相当難しいです。 しかし普通のカフェが出す普通のお客さんに出す普通の一杯は極限までコストを削減しなければならないのです。 それはそれでプロの仕事ですが、我々自家消費のしろうとはコスト感覚を無視して高級豆を使えるのです。よく「ドリップ技術」なんて言われますが、コーヒーのドリップは豆の品質がほとんどです
Flutterでそこそこ規模の大きいプロダクションアプリを作ったのでスケールする設計についてまとめる - タオルケット体操
あわせて読みたい FlutterでBLoCだChangeNotifierと振り回されて消耗するまえに - タオルケット体操 筆者のFlutterに対する印象は半年前にこのエントリーを書いたときから驚くほどに何も変わっていないので、逆にFlutterは非常に明快でわかりやすいライブラリなのかもしれないですね。 hachibeechan.hateblo.jp 筆者の主張の事前まとめ Reactの学習は実質Flutterの予習 クライアントアプリを設計するにあたってはActiveRecordパターンの再発明をしてはいけない 結局MVX RXSteamとはなんだったのか DDDの勉強をすると多くの示唆を得られる Remi wareを信じろ ちなみにここ以下で述べるActiveRecordパターンはPoEEAとRoRのものの混合があるかもしれませんが、利用すべきじゃないという点において同一なので特に
Flutter所感 - タオルケット体操
諸事情によりしばらくFlutterでアプリ作って感じたことをいくつか。 良いところ 1. ちゃんと動く みなさんも今までに出ては消えていくiOS, Android両方で動くアプリ作れるよ系ソリューションで色々なお気持ちを発生させてきたかとおもいますが、Flutterの出来の良さはピカイチ感があります。Flutter Engineすごーい！ 大抵のアプリが必要とするような機能（当然全てではない。例えばパスワード管理との連携とかは存在しない）であれば、各プラットフォームネイティブに手を入れることなくちゃんと動く。自前レンダリングと聞いて心配していたパフォーマンスも普通に悪くない。なんて素晴らしいんでしょう。 Flutterの良さはそこに尽きるとおもいます。 2. すぐ動く いろいろな意味で。 まずコンパイルがそこそこ早いです。 そしてSDKが用意していくれているWidgetの種類がかなり豊富で
「Reactの難しさ」を分解しよう - タオルケット体操
他のライブラリと比べるまえに まず、ReactとjQueryと比べるのはやめよう 「テンプレートエンジン」として捉えて、シンタックスを攻撃するのをやめよう ライブラリとしてのReactはとても簡単 Reactの思想を理解するのはチョットムズカシイ 環境構築が難しい JavaScriptそのものが難しい GUIが難しい jQuery時代からのパラダイムシフト フレームワーク関係者の情報量が多い SPAはとりわけ難しい まとめ ずっと感じてたもやもやを書き連ねたら長くなってしまったが、ぼんやりとReactとかなんか難しそうだしめんどくさいから新規案件だけどjQueryでやろっかなどうしよっかなーと迷っている人の指針になってくれればうれしい。 他のライブラリと比べるまえに まず、ReactとjQueryと比べるのはやめよう 出た時から延々と言われ続けているものの、やっぱり今でもjQueryとRe
ノウハウの共有文化がない場所にコードレビューをねじ込んでみた結果とか - タオルケット体操
「コードレビューをキメると品質も上がるし自分のレベルも上がるので最高」みたいな論が巷を賑わせていて、以前はそういうイケてる制度を指をくわえてみるのみだったのだけれど、最近職場と、それと個人的に関わったプロジェクトでコードレビュー制を無理矢理交渉して導入してみた結果、世間のイケてる書籍やエントリから得られる情報とはまた少し違う知見が得られたので書いてみる。 割と泥臭かったり、あまり希望に溢れてたりはしない感じのエントリなのでそういうのは期待しないほうがいいです。 準備 些末なコードレビューを極力避けるために、コードの規約やスタイルについてはlintとフォーマッターを用意した。 他は無策。 結論 結論から言うと、理想的な運用は出来なかったものの、コードレビューについて世間で言われるような成果（作業を共有する意識、レベルの向上）は得られた。良かった。 ぶっちゃけ僕なんかが浅はかな考えで導入しても
Haxeの3.2でJavaScriptとの相互運用性がTypeScript相当くらいまでにカイゼンしたっぽい！ - タオルケット体操
以前こんな記事を書きましたが、Haxe 3.2で状況が改善したようです。 とりわけ嬉しいと思われるのは @:nativeマクロがクラスフィールドをサポート 可変長引数のサポート Union Types的な機能をサポート でしょうか。 nativeマクロがメンバ変数やメソッドにも使えるようになった @:nativeというマクロは、以前は型名のエイリアスにしか使えませんでした。そのため、利用法としてはモジュール名が大文字から始まる（Haxeではモジュール名は小文字からはじまらないといけない）というようなケースくらいにしか使えませんでした。 ところがJavaScriptでは、$記号や、catchなどの予約語をメソッドに使うなどの行為は実際チャメシ・インシデントです。 一応Haxeでも、propertyを使ってクロージャを返すような型定義をする（うろ覚え）……などの裏技で回避出来るんですが、@:o
普通のフロントエンドを書くのにHaxeをしばらく使っての所感 - タオルケット体操
仕事でWebのUIを作るのにしばらくHaxeを使っていたので適当な所感とかをまとめます。 その前になんでTypeScriptじゃなくてHaxeにしたか まずは言語仕様が綺麗だったから、そして（比較当時の）TypeScriptの仕様が残念だったから。 まぁどうしたって比較しちゃいます。当時TSは出たてでした。 TSはシンタックスシュガーが嫌いな感じだったりするのもそうなんですけど、特にモジュールまわりの仕様が腐ってて「あーこりゃダメだわ」って感じで使うのやめちゃいました。モジュール周りは今でも残念なんですかね。 あとはコンパイルの遅さ、Haxeのほうが歴史が長かった（ので安定して動いてくれそうみたいな雑な考え）、とかそんな感じです。 おすすめできる？ ふつーにフロントのJavaScriptを書きたいのであれば、余計な苦労ばかりすることになるのでHaxeはおすすめしません。素直になれ。 以下理
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
