フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
![Google BigQuery の話 #yapcasia // Speaker Deck](https://cdn-ak-scissors.b.st-hatena.com/image/square/cc5fd563e94ea4365b5ea81c0afa9050ab1cf9a7/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F5c680810121d0132c86f02e2e0c65448%2Fslide_0.jpg%3F3452163)
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
Scalaのマクロというより、一般的にマクロに共通する基本であり重要な部分です。それをScala使って説明するだけです。 Scalaのマクロは、未だexperimentalという位置づけで、他の機能に比べれば仕様やAPIが変わりやすい状態です。そして、機能が搭載されてからあまり時間が経っていないこともあって*1あまり一般的に使われているとはいえない状態でしょう。しかし、Cなどのマクロとは違い、Scalaのものはある程度は本格的にコンパイル時に抽象構文木を自由にいじれるものであり、使いこなせるようになってくるとなかなかおもしろいです。 マクロというと、ある程度の人はLispを思い浮かべると思いますが(?)、先ほど書いた「本格的に抽象構文木いじれる」という点はまさにLispと共通する部分もあります(もちろん異なる部分も多くあります)。 つまり、これから説明することは、On Lisp*2 On
アジャイルソフトウェア開発の奥義 第2部「アジャイル設計」の自分用まとめ。 アジャイル設計 アジャイルな設計 「原則」「パターン」「プラクティス」を継続的に適用することで、読みやすく変更に強い状態を保つことができる設計。 悪い設計 第2部の中で「貧弱な設計の兆候」「腐敗するソフトウェアの兆候」として、以下の7つが挙げられている。 硬さ (設計変更が難しい) 脆さ (設計が壊れやすい) 移植性のなさ (再利用が難しい) 扱いにくさ(正しい設計をするのが困難なソフトウェア、面倒な開発環境) 不必要な複雑さ("後で必要になるかもしれない"と考えて先行実装したコード) 不必要な繰り返し (コピペ) 不透明さ (目的や意図がわかりにくい) 原則 システムに悪い設計の兆候が見られるとき、その原因がオブジェクト指向設計の原則に反していることだったりする。 ただし無条件で原則に従うと「不必要な複雑さ」を招
YAPC::Asia Tokyo 2014で、いろんな言語を適材適所で使おう - YAPC::Asia Tokyo 2014という話をしてきました。 これまでのソフトウェアエンジニアとしての経験から、継続的に価値を提供し続けるための技術選択はどのようにあり得るのかということをずっと考えていて、「「技術的負債」を問いなおす」というタイトルでJAWS DAYS 2014で話してきた #jawsdaysや、GMOペパボのエンジニア新人研修 #lldiverという発表でもそのあたりの問題意識に基いて話したりしてきました。今回の話は、では、それらの延長線上での、将来における技術選択の最適化について考えてみました。 もうちょっとちゃんと定量化できる感じにしたいけど、まだまだ難しそうだなあという感じ。もうちょっと深堀りして考えていきたいと思います。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く