GraphQLが"グラフ"であることを利用してビジネスロジックを入れ込んでみる - Qiita
動機 GraphQLを勉強しているとき、 GraphQLが"グラフ"を扱っているのはわかるけどそれによってどんないいことがあるんだろう？ バックエンドにGraphQLを選択した際、ビジネスロジックはどこに表現されるべきなんだろう? という私の疑問にサクッと答えてくれる日本語の文献が少なくともネット上には見つからなかったので、書いてみることにしました。 作るもの いわゆる"TODOリスト"を作ります。TodoistやRememberTheMiik的なあれですね。 いきなり余談ではありますが、何か新しい言語やフレームワーク、DBなどをサクッと試したいときに作るものの題材として、"TODOリスト"は個人的に以下の観点からオススメです。 仕様がイメージしやすい 大抵の方は何らかのTODOリストを使ったことありますよね？ どんなアーキテクチャでも大抵１日以内に完成する 慣れないアーキテクチャであまり
なぜ我々は頑なにforを避けるのか - Qiita
動機 前回の記事を投稿したことを某SNSで通知したところ、そのSNSでこんなコメントをいただいた。転記する許可を取ったわけでは無いので私なりに要約させていただくと、 なぜそんなトリッキーな書き方をしてまでforを使うのを避けるのか そんな書き方をして可読性を下げるくらいなら素直にforを使う方が良い ということだと理解している。 なるほど、一理ありそうだ。しかし一方で、前回貼ったStackOverflowのQ&Aはなかなかの人気記事（質問に1243ポイント、回答に最大で1559ポイント）なので「多少トリッキーなことをしてでもforを書きたくない！！」という意見をもつプログラマも一定以上いるのだろう。当然私もその1人だ。 ということで、この記事で「なぜそこまで意固地になってまでforを書きたくないのか」を説明することにする。 尚、今回は前回の記事つながりで言語はJavaScriptを使うが、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
