実はDDDってしっくりこないんです - タオルケット体操
DDD失敗パターン集 DDDという方法論それ自体に対する僕の立場はあんま好きじゃない寄りのフラット（といいつつほぼ忘れかけている）なんですが、過去何度もDDDでプロジェクトが爆死するのをみたり、爆破してしまったり……というのを見てきたので供養したいとおもいます。 メンバーの大半がDDDを知らない 「えっ!? ドメイン駆動を知らずにDDDを?」 「出来らぁっ!」 DDDを知らずにDDDをする、という前提がすでに禅問答じみてる気がしますが、たぶん一番よく見かける失敗パターンなんじゃあないでしょうか。 どういうことかというと、オニオンとかレイヤードとかクリーンなアーキテクチャのモジュールの命名ルールと構造を採用（採用できているとは言っていない）しただけの状態です。 私見ですが、アーキテクチャというのはメンバー全員がそれを理解できていない限り*1即破綻します。 理解できない人はどこに処理を書いてい
NestJSちょびっとだけ触ってみた所感 - タオルケット体操
ここ数年まともにサーバーサイドをやっていないなぁとかおもいつつなんやかんやあってNestJSを数日ほど触ったりドキュメントを読んだりしてたので初心を忘れないようにメモ。 いちおうTypeORMだけは出始めにちょっと使ってた。 理解度が高まったら気分が変わるかもしれないです。そしたらもっかい日記書きます。 てか全体的に難易度高くないこのフレームワーク？求められるリテラシー高くない？ お気持ち表明 前提なんですが、僕はこのフレームワークのことをまだあまり好きになれていません。オブラートを外してのべると、すでに半分くらい嫌いです。 良いとおもったところ 色々なライブラリをつけ外しして使える つまりNestJS自体が提供している機能はそれほど多くないと言う意味ですね。 そこそこ柔軟に書ける ↑で述べているように、プラガブルなんで例えばORMだってTypeORM使ってもいいしPrisma使ってもいい
脱MacBookしようとしてnew XPS 13 2018年モデルにLinuxをいれてみたけどちょっと後悔してるよ - タオルケット体操
Linuxはオープンソースなので政治的にも正しいし、自分で改造すれば理論上は無限大の可能性があり、とにかくすごいです。 Macは使うととにかく宗教になってしまい信者だから全部ダメだし、オープンソースじゃないから自由じゃないです。みんながLinuxを使えば無限がたくさんになって、かなりすごいことになるとおもいます。 みなさん使うといいとおもいます。 困ることは何もありませんでした、あったとしても自分でパッチをあてれば理論上は全て解決するのでわるいアップルやマイクロソフトみたいな悪のプロプライエタリ企業の顔色を伺う必要もなく、誇り高いきもちになれます。こんなすごいOSを使える自分はきっと特別な存在なのだと感じました。 *1:たぶんDellは日本にDevelopperがいることを知らないんだとおもう。SEしかいないとおもってる *2:正気かよ *3:筆者はペーペーなのでLinux GUIの詳しい
覚えるだけでPythonのコードが少し綺麗になる頻出イディオム - タオルケット体操
まえがき 今年の春から今まで、2年ぶりにPythonを沢山書いているわけなんですが、JavaScriptのクソに頭をやられて久しぶり書くだけあって基本的なところから色々と頭から抜け落ちていたわけです。 そんで何か思い出すたびに会社のwikiを使ってメモっていたのですが、せっかくなので少々訂正をしてブログにも書きます。 また、弊社はPython2を使っているので、2が前提の記述になっているところがいくつかあります。なるべくフォローしていますが、参考にする場合は自分が使っているバージョンを確認することをおすすめします。 また、今から新しくPythonでプロジェクトを始めようと思っている人は3系を使いましょう。 知ってる人は当然知ってる、でも結構長いことPythonを書いてても知らなかったりするような小技を載っけました。 なお、メタプログラミングとかの黒魔術っぽい記事のまとめはこちら: hach
Pythonのラムダ辛い問題を解決する暗黙のプレースホルダ - タオルケット体操
＊ ネタ元 Rubyのブロックつらい問題を解決する暗黙のブロックパラメータ - Qiita RubyPythonのブロックラムダつらい問題 Pythonでショートコードをしようとおもうと、時々こういうことが起きます。 map(lambda it: it.upper(), ['foo', 'bar', 'baz']) それぞれの要素に対してupcaseを適用する、ただそれだけのためにitを2回も記述しなければなりません。っていうかそもそもlambda:って読みにくいです。 Pythonはラムダをあまり使わない言語なのでこの様なコードを書く機会は少ないですが、それでもちょくちょく出番があり、やがてあなたは辟易するはずです。 <中略> 参考になる例として、ClojureやScalaでは暗黙のパラメータ（プレースホルダ）を導入することでこの問題を上手く解決しています。 <例は省略> やりましょう
普通のフロントエンドを書くのにHaxeをしばらく使っての所感 - タオルケット体操
仕事でWebのUIを作るのにしばらくHaxeを使っていたので適当な所感とかをまとめます。 その前になんでTypeScriptじゃなくてHaxeにしたか まずは言語仕様が綺麗だったから、そして（比較当時の）TypeScriptの仕様が残念だったから。 まぁどうしたって比較しちゃいます。当時TSは出たてでした。 TSはシンタックスシュガーが嫌いな感じだったりするのもそうなんですけど、特にモジュールまわりの仕様が腐ってて「あーこりゃダメだわ」って感じで使うのやめちゃいました。モジュール周りは今でも残念なんですかね。 あとはコンパイルの遅さ、Haxeのほうが歴史が長かった（ので安定して動いてくれそうみたいな雑な考え）、とかそんな感じです。 おすすめできる？ ふつーにフロントのJavaScriptを書きたいのであれば、余計な苦労ばかりすることになるのでHaxeはおすすめしません。素直になれ。 以下理
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
