【比較表あり】自社に最適なデータフィード管理サービスを見つけよう!選び方と 4 つの主要サービスを解説
この記事は、 Mastodon Advent Calendar 2017 の15日目の記事である。 前日の記事は『どうすれば変化するAPIと上手く付き合っていけるのか – Tootle Inside – Medium』、 翌日の記事は『Mastodon フロントエンド改造入門 | THE BOSS's blog』である。 あんただれ GNU Social GNU Social 個人用インスタンス勢 (gnusocial.cardina1.red) nightly 追従勢 クソザコ PR を送ったことはあるが、コードそのものに手を入れたことはない 周辺プラグイン (Qvitter 等)に PR 送ったことはある Mastodon Mastodon 個人インスタンス勢 (mastodon.cardina1.red) master 追従勢 PR とか issue は書いたことなし(純粋なユーザ)
{ "data": { "viewer": { "login": "takochuu", "avatarUrl": "https://avatars1.githubusercontent.com/u/207675?v=4", "company": "Japan", "name": "", "url": "https://github.com/takochuu" } } } ね?簡単でしょう。 今回は、goでGraphQLを使用したAPIサーバーのソースコードをgoで作ります。 GraphQLを使ったサーバーの実装 ここからはいよいよ実装に入ります。 introductionとしてはこちらのtutorialを実施してもらうのが良いと思います。 今回、GraphQLのライブラリとして github.com/graphql-go/graphql を利用します。 1ヶ月程masterにcommit
昨日、スターウォーズの前夜祭でエピソード8見てきました! えーすけです!!! ラストジェダイ最高だったんでみんなエピソード1から全部見て行きましょう!!!! ネタバレすると、スクリーンで動くポーグがひたすらにかわいい。 この記事は feedforce Advent Calendar 2017 - Adventar の 15日目の記事です! 昨日は、スケちゃんの GraphQL API をスキーマファーストで開発したいけどスキーマと実装で乖離を起こしたくない - Feedforce Developer Blog でした! GraphQL 楽しそう!!! 今回の記事は、コードレビューについてです(サムネ画がポーグなのは全く関係ありませんw)。 最近行った勉強会でレビューについて考える機会があったので、普段の業務の中で日々受けて自分なりにこうしてるよというのをいい感じにまとめれたらなと思っていま
注意 現在の graphql-ruby (ver: 1.8.x) は Ruby のクラスベースによる定義がメインで、この記事に書いてある DSL を使った定義は 非推奨 です。 ロードマップ には DSL を使った .define-style は、graphql-ruby 2.0 で廃止するとあります。 新しいクラスベースでの書き方は 公式ドキュメント を御覧ください。 日本語の記事だと @gfx さんの 「GraphQL」徹底入門 ─ RESTとの比較、API・フロント双方の実装から学ぶ が非常によくまとまってて分かりやすいです。 はじめに 私が携わっているプロダクトでは、フロントエンド用のAPIとしてGraphQLを採用しました。 実際に使ってみてかなり良い感じなのですが、最初はいざ実装しようにもよく分からずに苦労しました。 そこで、GraphQL の実装方法についてサーバーサイドに焦
この記事は AWS Fargate Advent Calendar 2017 の16日目の記事です。 概要 AWS Fargate の登場により、EC2インスタンスやそのクラスタを意識せずともコンテナが実行できるようになりました。AWSさん曰く、”コンテナをデプロイする最も簡単な方法”ということです。すごいですね。一方で、コンテナを本番環境に導入すると"9ヶ月でコンテナ数が5倍に増加する"や"仮想マシンより9倍早く縮退するようなライフサイクルで利用される"といったレポート1 もありますので、より流動的になるインフラに対して運用時の可視性を確保するためにFargateのモニタリングについて考えてみました。 AWS Fargate で利用可能なモニタリング AWS FargateはこれまでのAmazon ECSと同様にCloudWatch Logs と CloudWatch Eventsをサポ
サーバーレス・アプリケーションの開発ツールチェーンとして AWS SAM まわりがいい感じに成長してきているのであらためて紹介します Serverless Advent Calendar 2017 の 15 日目です. 本記事ではサーバーレス・アプリケーションの開発ツールチェーンとして最近なかなかいい感じになりつつある AWS SAM (AWS Serverless Application Model) とその周辺を紹介しようと思います. 本記事は AWS 上でサーバーレスなアプリケーションを動かしたい オープンソースとしての公開も考えてたりする サーバーレスなアプリケーションも CI/CD に組み込んで継続的に開発・デプロイしていきたい 過去に CloudFormation で Lambda をデプロイしようとして血を吐きかけた というわけで CloudFormation は生理的にちょ
この記事は、Go2 Advent Calendar 2017の15日目の記事です。 最初に Go言語のHTTPサーバに対してテストを実装する方法を簡単にですがご紹介したいと思います。 今回はサーバ側の実装としてechoを利用していますが、他のフレームワークを利用していても同様にテストすることが可能です。 今回のテスト対象のHTTPサーバは以下の通りです。 package main import ( "net/http" "github.com/labstack/echo" ) const helloMessage = "Hello, World!" func main() { router := NewRouter() router.Start(":8080") } func NewRouter() *echo.Echo { e := echo.New() e.GET("/hello",
最近は仕事でも新しくGoのプロジェクトをイチからはじめることが増えてきて、コピペ元が欲しくなるので、スナップショットとして残しておきます。とくに Go でウェブアプリケーションを書くような場合を想定していて、npm エコシステムにも乗っていきます。 大まかな方針としては、 self-contained である グローバルな環境を汚染しない コマンド一発で開発環境が再現できる ……というところを目指します。 motemen/prchecklist がこれを達成しているつもりなので、以下、これを例に見ていきます。 依存ライブラリは dep なり何かしらのツールと Go 標準の vendoring で管理すればよい一方、そのツール自体であったり、他の開発中に必要なツール(golint とか gobump とか)であったりのインストールをどうするかという話。 npm であれば devDepende
2017年12月15日 下水管理業者のワイが下水道に流してはいけないもの、流したらどうなるかを書いていく カテゴリおもしろ・ネタ Comment(107) 1: 名無しさん 2017/12/14(木)20:03:35 ID:7tb わいは下水道関連の仕事してる者なんやが、「下水道には何でも流せる」って勘違いしてる人や、ためらいなく異物を流す人もおるけんもうめちゃくちゃ困っとるんや このスレでは下水道に流してはいけないもの、流したらどうなるか、などを書いていくで 3: 名無しさん 2017/12/14(木)20:04:32 ID:p0H 頼む。 4: 名無しさん 2017/12/14(木)20:04:51 ID:7tb ①食用油 症状…油が下水道内で冷えて固まり、 ・配管の詰まり ・水の流れが悪い ・悪臭 などの症状が発生 処置…ジェッターやダンパーといった高圧洗浄機を使用 水に圧力をかけて
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く