自宅で美味しいコーヒーを飲むためにどういう順序でお金を使うべきか
みなさんこんにちわ、カカオ豆です。 皆さんは家でコーヒーを飲みますか？僕は一日4杯くらい飲みます。 コスパ良く美味しいコーヒーが飲みたすぎて自家焙煎までしはじめて、職場の同僚にもその良さを布教しまくるようなウザムーブをかまして、気がつけば2年が経ちました。 さて、自宅コーヒーは、ちょっと気をつけて投資するだけでその辺のカフェくらいなら余裕で追い越せるくらい美味しいのが淹れられるようになります。 え？「プロをなめんな？」 いえいえ、もちろん超こだわったお店で超こだわる客に出す超高い一杯を超えるのは相当難しいです。 しかし普通のカフェが出す普通のお客さんに出す普通の一杯は極限までコストを削減しなければならないのです。 それはそれでプロの仕事ですが、我々自家消費のしろうとはコスト感覚を無視して高級豆を使えるのです。よく「ドリップ技術」なんて言われますが、コーヒーのドリップは豆の品質がほとんどです
実はDDDってしっくりこないんです - タオルケット体操
DDD失敗パターン集 DDDという方法論それ自体に対する僕の立場はあんま好きじゃない寄りのフラット（といいつつほぼ忘れかけている）なんですが、過去何度もDDDでプロジェクトが爆死するのをみたり、爆破してしまったり……というのを見てきたので供養したいとおもいます。 メンバーの大半がDDDを知らない 「えっ!? ドメイン駆動を知らずにDDDを?」 「出来らぁっ!」 DDDを知らずにDDDをする、という前提がすでに禅問答じみてる気がしますが、たぶん一番よく見かける失敗パターンなんじゃあないでしょうか。 どういうことかというと、オニオンとかレイヤードとかクリーンなアーキテクチャのモジュールの命名ルールと構造を採用（採用できているとは言っていない）しただけの状態です。 私見ですが、アーキテクチャというのはメンバー全員がそれを理解できていない限り*1即破綻します。 理解できない人はどこに処理を書いてい
投資をやりはじめてから5年経った - タオルケット体操
事前に勉強している期間はあったが、実際に投資をやりはじめてからおおむね5年ほど経ったらしい。 投資は長い目でみてやるものなので5年という区切りには実際には何の意味もないのだけど、10進数で生活している我々からするとなんか区切りがよいので日記を書くモチベーションに使った。 ちなみに一番メジャーなETF（たぶん）であるVTIの価格はこの5年間でほぼ2倍に成長している。区切りがいいね。 僕の投資スタイル 個別の銘柄について述べることはしないが、僕の投資スタイルの基本は株式のインデックスファンドを買うことだ。 なぜかというと、それが一番楽でシンプル、かつ効率的だからだ*1。 ゲーム、スポーツ、仕事でもなんでもいいが、選択肢が複数あった場合はまず一番スタンダードかつ簡単なやり方を試すべきだ。初心者であればなおさらそうだ。 FPSの初心者はまずアサルトライフルからゲームを覚えるべきなのと同様に、投資の
プライベートにコードを書くと筋力があがる（可能性がある）仕組みについて - タオルケット体操
ZOZOの人の発言、ぶっちゃけアイティーでパソコンの先生やってる人の大半の人が大筋では同意するんだろうけどみんなへそ曲がりだから年末年始みたいなイベントと絡めたり散りばめられた意識高い属性にイラッときてるみたいなところがあるとおもう— はっちん (@hatchinee) 2021年1月4日 「年末年始にコード書かないやつは……」云々のツイートについてのお気持ちはだいたい↑の通りなんだけど、どうも世間の感想（ツイートへのぶら下がりとはてなブックマークのコメントという枠です）をみる限り僕の想定とはズレた感じで批判的な人*1が沢山いるようなので、プライベートのコーディングとプログラマとしての能力がどういう相関関係にあるのか僕の考えを書こうとおもいます。 プライベートで（趣味）コーディングしてる人が有能である（可能性が高い）理由について コーディングの前に （趣味） とついていますね？ まず趣味コ
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の種類がかなり豊富で
TypeScriptを導入する前に考慮したほうが良いこと 4項目 - タオルケット体操
補足：2021年6月 結構昔に書いた記事ですが、今でもたまにアクセスがある（ありがとうございます）ようなので使命感に駆られて追記。 本編の冒頭にもあるように、これは2018年の記事です。なので色々と書いてますが、2021年の人間の立場からTypeScriptの導入について申すのであれば一言です。 使いましょう。 もはや「TypeScriptを使う理由」とか言ってる時代はとっくの昔に終わっています（Elmとかそういう、他の型付きAltを使いたいなら別ですが）。 もちろんstrict mode一択ですからね。 当時は採用云々とか書いてましたが、逆にいまTypeScript書けるかどうかってのはフロントエンドエンジニア採用の足切りラインとしてちょうどいいくらい（書けるってのが程度かにもよりますけど）だとおもいます。 好き嫌いはともかく、TypeScriptを使えないエンジニアを雇ってもフロントエ
脱MacBookしようとしてnew XPS 13 2018年モデルにLinuxをいれてみたけどちょっと後悔してるよ - タオルケット体操
Linuxはオープンソースなので政治的にも正しいし、自分で改造すれば理論上は無限大の可能性があり、とにかくすごいです。 Macは使うととにかく宗教になってしまい信者だから全部ダメだし、オープンソースじゃないから自由じゃないです。みんながLinuxを使えば無限がたくさんになって、かなりすごいことになるとおもいます。 みなさん使うといいとおもいます。 困ることは何もありませんでした、あったとしても自分でパッチをあてれば理論上は全て解決するのでわるいアップルやマイクロソフトみたいな悪のプロプライエタリ企業の顔色を伺う必要もなく、誇り高いきもちになれます。こんなすごいOSを使える自分はきっと特別な存在なのだと感じました。 *1:たぶんDellは日本にDevelopperがいることを知らないんだとおもう。SEしかいないとおもってる *2:正気かよ *3:筆者はペーペーなのでLinux GUIの詳しい
そろそろコードレビューそのものの必要性について考えるときがきているのかもしれない - タオルケット体操
技術ブログの方に書くか迷ったのですが、かなりポエムの類な文章になりそうなのでこちらに書きます。 ちょっと前にバズったこちらの記事 medium.com に触発されました。 ちなみにコードレビューに関する話としてはまだ僕が色々と手探りだった3年前にもこんなことを書いていたようです。3年前の自分の考えに触れられるブログって面白いなという気持ちとこいつどんだけ軽率な文章書いてんだよという気持ちが合わさり甘酸っぱい気持ちが生み出されました。 hachibeechan.hateblo.jp 当時と今では日本全体の技術的トレンドも変わっていますし、そもそも僕の所属している会社も違います。今の会社ではGitHubを使っており、コードレビューが当然のフローとして組み込まれています。 そしていま改めて当時のブログを読み返したのですが、びっくりするほどコードレビューに対する僕の考えが変わっていないので、改めて
プログラミング初心者向けのシンプルなObserverパターンの解説 - タオルケット体操
まえおき デザインパターンに関しては色々言われていますね。 個人的には、「確かに微妙だし全体的に時代遅れっぽいけど基礎教養みたいなもんなので基本情報技術なんぞを受ける暇があるなら一通り目を通しておいてもいんじゃねえの？」っていう立場です。 微妙っぽい感じなものが多いデザインパターンなんですが、それでもちゃんと押さえておいた方がいいよねっていうものの一つがオブザーバーパターンです。 アプリケーション的なプログラミングをしていると絶対に避けて通れないパターンなんですけども、以外と存在も意味も知らずになんとなくとコピペで済ませている人に未だにめっちゃ出会うのでちょっとした危機感だよねっていうのが現状です。 このパターンはみんな大好きMVCの基礎となっている設計手法で、Webとかスマホアプリだとかをちゃんとやるには避けて通れないんだ。一切勉強もせずに聞きかじりの知識で「今さらデザパタの記事とかww
Paizaの炎上とIT業界とセックスと緑の自転車 - タオルケット体操
Paizaといえばいつの間にか雑なSIerDisりのポジショントークで各所から顰蹙を買う炎上芸人系サービスになっていたので、後日読んだときにどれの話だよとなりかねないので念のために書いておくと、女を捕まえて調教して金を稼がせつつハレムを作るゲームが炎上した話です。ようは大悪司を水で薄めたみたいなもんでしょう*1。 そういえば某社の人事が職権を乱用して夜の面接をしていたみたいな話をゴミタブロイド誌がすっぱ抜いていたのでIT業界は実質エロゲだと言って良いでしょう。 でもPaizaって最初は割と志のあるサービスだったと記憶してるんですよね。 競プロっぽい問題を解くことがそのままエンジニアの実力の証明になるかどうかについては正直疑問がなくはないですけど、それでもある意味で現状の最適解と言えなくもないわけですし、コミュ力とかいう面接官の胸先三寸雰囲気で採用が決まるような不健全なマスの転職市場を変えた
「Reactの難しさ」を分解しよう - タオルケット体操
他のライブラリと比べるまえに まず、ReactとjQueryと比べるのはやめよう 「テンプレートエンジン」として捉えて、シンタックスを攻撃するのをやめよう ライブラリとしてのReactはとても簡単 Reactの思想を理解するのはチョットムズカシイ 環境構築が難しい JavaScriptそのものが難しい GUIが難しい jQuery時代からのパラダイムシフト フレームワーク関係者の情報量が多い SPAはとりわけ難しい まとめ ずっと感じてたもやもやを書き連ねたら長くなってしまったが、ぼんやりとReactとかなんか難しそうだしめんどくさいから新規案件だけどjQueryでやろっかなどうしよっかなーと迷っている人の指針になってくれればうれしい。 他のライブラリと比べるまえに まず、ReactとjQueryと比べるのはやめよう 出た時から延々と言われ続けているものの、やっぱり今でもjQueryとRe
覚えるだけでPythonのコードが少し綺麗になる頻出イディオム - タオルケット体操
まえがき 今年の春から今まで、2年ぶりにPythonを沢山書いているわけなんですが、JavaScriptのクソに頭をやられて久しぶり書くだけあって基本的なところから色々と頭から抜け落ちていたわけです。 そんで何か思い出すたびに会社のwikiを使ってメモっていたのですが、せっかくなので少々訂正をしてブログにも書きます。 また、弊社はPython2を使っているので、2が前提の記述になっているところがいくつかあります。なるべくフォローしていますが、参考にする場合は自分が使っているバージョンを確認することをおすすめします。 また、今から新しくPythonでプロジェクトを始めようと思っている人は3系を使いましょう。 知ってる人は当然知ってる、でも結構長いことPythonを書いてても知らなかったりするような小技を載っけました。 なお、メタプログラミングとかの黒魔術っぽい記事のまとめはこちら: hach
英語できないエンジニアだけど外資系に転職してしばらく経ちました - タオルケット体操
僕の英語力について こういう記事って、「英語できない」を過少申告してること多いですよね。「TOEIC820点しかとれてなくて全然ダメなんです>_<」みたいな。アレはなんなんですかね？ ちなみに僕はそもそもTOEICを受けたことがないです。 そんな僕のスペックをまとめると 学生時代に特に苦手意識を持ったことはない（苦手意識を持つほど勉強しなかったとも言える） TOEICを受けたことがない StackOverflowを読むくらいならなんとか 英語で会話したことは（ほぼ）ない 去年初めてヨーロッパに行った際、「tea or coffee?」にcoffeeと答えたらteaが出てきた DMM英会話の無料体験をしてみたら死んだ つまり公式には学校教育でしか英語を学んでいないということになりますね。平均的な日本人って感じだと思います。そして学校の英語教育は役立たずで有名（実際に役立たずっぷりを実感）なん
補完などを有効にしてVimを最高のPython用開発環境に進化させる - タオルケット体操
注意：NeoVimとかneocompleteとか NeoVimの開発進行に伴い、多くのshougoware（neoシリーズ）も開発が終了して、闇の力をまとったなんかになっていってるっぽいです。 僕はNeoVim関係の情報をキャッチアップできていませんが、各プラグインに関してはREADMEやdocを読んでいって自己判断をやっていきましょう。 賛否あるでしょうが、Pycharm（IDEA）のような優れたPython用IDEがある現代においては、エディタのカスタマイズを全く行わないというのは生産性を犠牲にする行為であると筆者は考えています。 とはいえツールのセットアップというものはめんどくさいものです。IDEですら設定すべき箇所は多数あります。 今のところPython用Vimカスタマイズの設定例として個人的に満足するものがなかったのでブログにまとめておこうと思います。 Vim初心者だとわからない
言われた仕事を粛々とこなすか、頼まれてもいないことをやらかすか - タオルケット体操
まえがき 多分に考えを整理するためのWIP的な性格を持った文章になります。そして長いです。 「1をきいて10をこなす」的な優秀さか、「1をきいて3くらいをこなしながらabcをやらかす」的なはっちゃけか、どっちで生きるべきかみたいなはなしです。 いくつかのチームを抱えているような会社って、横断的なコミュニケーションや情報共有はどうなっているもんなんでしょうか。ウチは皆無です。正確には、同期でたまたま仲がいいだとか、そういった理由での個人的な繋がりはあるのかもしれないんですけど、組織的な風土や取り組みとしては実質的にほぼ皆無だと言って良いとおもいます。 社内の情報共有がない。でもそれで何か問題があるの？ コミュニケーション皆無だろうが、みんなが暗黙知を抱え込んで仕事をしていようが、それでみんなが（本音: 主に僕が）幸せに働けておカネもがっぽがっぽなら言うことないとおもいます。 が、どうにもうま
ノウハウの共有文化がない場所にコードレビューをねじ込んでみた結果とか - タオルケット体操
「コードレビューをキメると品質も上がるし自分のレベルも上がるので最高」みたいな論が巷を賑わせていて、以前はそういうイケてる制度を指をくわえてみるのみだったのだけれど、最近職場と、それと個人的に関わったプロジェクトでコードレビュー制を無理矢理交渉して導入してみた結果、世間のイケてる書籍やエントリから得られる情報とはまた少し違う知見が得られたので書いてみる。 割と泥臭かったり、あまり希望に溢れてたりはしない感じのエントリなのでそういうのは期待しないほうがいいです。 準備 些末なコードレビューを極力避けるために、コードの規約やスタイルについてはlintとフォーマッターを用意した。 他は無策。 結論 結論から言うと、理想的な運用は出来なかったものの、コードレビューについて世間で言われるような成果（作業を共有する意識、レベルの向上）は得られた。良かった。 ぶっちゃけ僕なんかが浅はかな考えで導入しても
エンジニアに「この会社はないわ」と思わせる面接のパターン - タオルケット体操
photo by DonkeyHotey 就職市場は売り手市場になりつつあるだとか、IT業界は人手不足だなどという話を最近はよく聞きます。 が、そういうわりにはマイナビだとかの斡旋サービスが出す雇う側視点の面接ガイドみたいなものが幅を利かせていて、雇われる側が面接の時にどういう基準で会社を選別しているのかみたいなおはなしは見かけない気がします。当たり前ですが、雇われる側にとっても面接とは擬似的にその会社の人間を体験する場（インターンほどではないですが……）なので、実際にやりとりをしてみたところで魅力に欠けるような会社であれば、志望を取り消します。逆お祈りメールです。 そんなわけで、プログラマーが面接を受けて「この会社こわ、入るのやめよ」っておもうような基準についてのお話ってみかけない気がしたので、エンジニア仲間と駄弁ってて出てきた話題だとか独断と偏見から出てきた考えだとかを書きなぐろうと思
ReactとFluxの入門のためにArdaを使ってみた - タオルケット体操
FluxもReactもよくわからん状態で入門して今日一日泣きそうになってたのでメモ。 というかいわゆるJavaScriptMVCをガッツリ書いたこと自体がないです。 Arda、指輪物語由来っていうあたりがよさがありますね。 あと全体的に薄いので、FluxとReactの仕組みを学びつつ、他と組み合わせたりいざとなったら捨てたり出来そうなのでよさそうっぽいなっていう雑な考えでいじりはじめました。 また、せっかくなので今回はContext層をTypeScriptにしつつComponentをCoffeeScriptにしてTemplateをreact-jadeに分離する、作者推奨っぽい構成でやってみました。 全体的な構成は mizchi-sandbox/arda-starter-project · GitHub から持ってきた感じなので、ツールの設定など特に言及のない部分は同じだとおもっていただきた
Pythonのラムダ辛い問題を解決する暗黙のプレースホルダ - タオルケット体操
＊ ネタ元 Rubyのブロックつらい問題を解決する暗黙のブロックパラメータ - Qiita RubyPythonのブロックラムダつらい問題 Pythonでショートコードをしようとおもうと、時々こういうことが起きます。 map(lambda it: it.upper(), ['foo', 'bar', 'baz']) それぞれの要素に対してupcaseを適用する、ただそれだけのためにitを2回も記述しなければなりません。っていうかそもそもlambda:って読みにくいです。 Pythonはラムダをあまり使わない言語なのでこの様なコードを書く機会は少ないですが、それでもちょくちょく出番があり、やがてあなたは辟易するはずです。 <中略> 参考になる例として、ClojureやScalaでは暗黙のパラメータ（プレースホルダ）を導入することでこの問題を上手く解決しています。 <例は省略> やりましょう
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
