毎朝、デザイン系の英語記事を10件ほどおすすめしてくれるSlackボットです。このボットは現在も問題なく稼働し続けていますが、毎朝のニュースは文字で読むよりも音声として聞いたほうが負担が少なく続けられそうです。 そこで、このSlackボットを拡張して、毎朝デザインニュースのポッドキャストを自動生成する仕組みを作ることにしました。 成果物はじめに成果物について。完成したポッドキャストは毎朝SpotifyとApple Podcastで配信しています。 おおまかな処理の流れ開発前に想定した処理の流れは以下の通りです。 毎朝ポッドキャストが自動で配信される理想的なフロー自分はコンテンツ制作者ではなく、あくまでリスナーというスタンスを取りたいため、ワークフローに自分が介在しない完全自動化が理想です。 ところが、Sound Cloud APIの利用に必要なアプリケーション登録の受付が現在停止しているこ

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? エンジニアの転職メモ を読んで、刺激を受けたので書いてみました。 非常に共感しました！ 自分的にちょっと気になるところ+αを書こうかなと。 書かれたことは会社的な方針ではなく、個人としての観点です。 自分誰よ とある企業で採用の一次面接に呼ばれたりする現場のエンジニアです。 Javaエンジニアです。Scalaもたまに書いてました。 転職回数は片手では足りないくらいの回数をしています。 最近はエンジニアマネジメントの比重が多く、ほとんどコード書いてないです。 コードは書いていませんがレビューや調査では読んだりします。 アーキテクチャ、フレ

昨年末に人生ではじめて面接を担当したので、考えたことを書いていきます。 大前提 面接をやるにあたって、個人的に心がけたのは「勘違いしない」ということです。 ネット上で流れてくる人事みたいな人間にはなりたくないな、と。 ただ採用する側になってみて、確かにこれは担当者を勘違いさせる魔力があるなと感じました。 良くないですね。 ただやっぱ採用って組織やチームとしてはめちゃくちゃ重要な活動なので、そこにコミットするのは大切。 特に小さな会社であればあるほど。 前提 今回の採用に関しては、iOSエンジニアの中途採用でした。 新卒採用だったらまた基準は違うと思います。 やるべきこと 面接に臨む前に、履歴書・職務経歴書は熟読しました。 SNSアカウント/Github/ポートフォリオサイトがあれば、それもサラッと見て。 面接そのものは実際そんな大事じゃないのかなと改めて思ったりもしました。 書類からある程

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 前置き 某上場Web系の企業で中途社員のサーバーサイドエンジニアの書類選考や採用面接官などをしています。途中に転職もしましたが面接などの採用に関わり始めてから５年経ちました。 以前に面接についてはこちらの記事を書きました。 エンジニアを面接するときに面接官が本当に知りたいこと 書類選考もしていて、欲しい情報が足りない。本当の実力はもっとあるのでは？と思うこともあり、今回は採用側の立場から、もっと見たい職務経歴書の書き方について書こうと思います。 全てのパターンに当てはまることはなく、主にWeb系の中でもそれなりに大きな会社の中で見てきた

この記事を書いた動機 なんとなくエンジニアの面接官が求めている情報と面接者の提供する情報にズレを感じることがあるなーと思っているので書こうかなと。 自己PRが上手くなくて損してしまうのはエンジニアとしては本分では無いかなと思うので、そのあたりがうまくない人はしっかり準備が出来たらいいなと。 あなた誰？ 某Web系上場会社に勤務するエンジニアです。 基本は現場で働いていますが、採用面接などは人事と一緒に現場エンジニアの一人として出たりします。 採用面接歴は２年以上。 注意事項 現在の会社の立ち位置から見た場合での限定した方向から見た場合の話です 個人としての考察になります。所属会社の見解とは無関係です 面接するときの私の個人の気持ち 落とすためにやっているのではなく、やりたいって思ってるなら全員通してあげたい！ いいところをたくさん見つけたい！ (強みを教えて！) 頑張ってることを評価したい

この前職務経歴書を書いたので、そのとき色々考えたり調べたりしたことを書きます。 一般的な転職活動の職務経歴書は微妙だった 僕の転職は二回目です。 一回目の転職のときは、リクルートエージェントのサービスを使って転職しました。 リクルートが公開している、一般的な職務経歴書のサンプルは↓こんな感じです。 Wordで表をつくって、編年体に、何をやってきたかを書くことで、自分の職務経歴を書きます。 ただ詳細はちょっと長くなるので、職務経歴書の冒頭に数行でサマリーが書いてあって、親切ですね。 一般的な日本の職務経歴書というのは、このフォーマットで問題ありません。 実際一回目の転職のときは僕もこのフォーマットで転職しています。 二回目の転職活動も、この職務経歴書に二社目の経験を追記すればいいか、と思っていましたが、 見れば見るほどこのフォーマットで書いた自分の職務経歴書が微妙に感じてきました。 何が微妙

なけなしの100万ぐらいあった貯金を風俗にはまって溶かして、 慢性的にクレカのキャッシング枠を毎月全部使い切って、 おろした現金を握りしめて風俗に行く生活をしているが誰にも言えないし相談してない 貯金が目減りしたときに自分の収入にあった通い方に安定させたかと思ったが毎月クレカのショッピング枠とキャッシング枠が回復するのを待つ自転車操業になってしまってる 使いすぎた月は現金もキャッシング枠もなくてクレカ支払いでしか生活できない一週間、とかたまにあってヒヤヒヤする 金を工面することは楽しくはないし無駄にすり減る 本気で困窮しているわけではないけど相談するには恥なのでできない。 根本的な問題は女がいなくて風俗に通ってしまう環境と浪費癖なのだけど、 相談できないっていう状況それ自体も寂しくなっていることの現れだなぁと思う ここに追記しました(URL間違ってた…) https://anond.hat

This document summarizes Amazon Web Services Japan speaker Tsukagoshi Keisuke's presentation on AWS AppSync. It introduces AppSync as a fully managed GraphQL service that allows building GraphQL APIs integrated with various data sources like Amazon DynamoDB, AWS Lambda, and Elasticsearch. AppSync provides a GraphQL schema definition language to define types and queries, uses Apache Velocity Templa

最近公開されたGitHubのAPIは、GraphQLという形式に対応しました。今後はこちらが主流になっていくようで、既存のREST APIからGraphQLへのマイグレーションガイドも提供されています。 今回は、このGraphQLについて、実際にGitHubのAPIを叩きながらその仕組みを解説していきたいと思います。 GraphQLとは 歴史 GraphQLは、Facebookの中で2012年ごろから使われ始めたそうです。その後2015年のReact.js Confで紹介されたところ話題となり、同年"technical preview"のステータスでオープンソースとして公開されました。その後仕様が詰められ、2016年9月に晴れて"preview"を脱し公式実装として公開されました。これと同じタイミングで、GitHubからGraphQLバージョンのAPIが公開されています。 このあたりの経緯

注：単純なデータモデルでさえ、今後の維持や説明が必要になる6つものエンドポイントが含まれています。 あなたがクライアント側の開発者で、movies APIを使い、HTMLとjQueryで単純なWebページを作るとします。そのためには、映画と出演俳優・女優の情報が必要です。APIに必要な機能は揃っているので、データを取得します。 新しくターミナルを開いて以下を実行します。 curl localhost:3000/movies 以下の応答が返ってきます。 [ { "href": "http://localhost:3000/movie/1" }, { "href": "http://localhost:3000/movie/2" }, { "href": "http://localhost:3000/movie/3" }, { "href": "http://localhost:3000/mo

GraphQLは最近注目されているWeb APIのための問い合わせ言語だ。 現在主流のRESTfulなAPIはURLとmethodでリソースを表現するわけだが、GraphQLは単一エンドポイント（ex: "POST /graphql"）だけ存在し、欲しいリソースをHTTP POSTのbodyに明示的に記載してリクエストする。 ↑JSON APIをGraphQLの形式でコールする（引用: how to graphql ) 徐々に実装例が増えてきており、2016年にはGithubがAPIの実装を全面的にGraphQLに移行させたのが注目された。 色々調べていくと、GraphQLは単にRESTの代替ではなく、開発・運用フローを一新させうるほど豊かな思想・機能を含む事が分かって来たので現状の整理をしてみたい。 APIリクエストを束ねて効率化RESTではURLがひとつのリソースを表すため、複数のリソ

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? DMM.com Advent Calendar 2018 20日目の記事です。 DMM GAMES プラットフォーム開発本部 PFシステム部所属の@SiragumoHuinです。 ゲーム自体を作るゲームエンジニアではなく、https://games.dmm.comの各画面やソーシャルアプリケーションプロバイダー（SAP）さんが使うAPIを提供しているWebグループに所属してるサーバサイドエンジニアです。 （記事を書いた当時）本日で24歳になりましたが、Webグループでは一番の若造です（新卒2年目） tl;dr; GraphQL自体はフレ

概要 こんにちは。プラットフォーム開発部でリードエンジニアをしているchanceです。 私たちのチームでは現在、開発部内向けの API 設計ガイドラインを整備しようとしています。 API 設計において、REST は基本中の基本です。ガイドラインとしてまとめるからには適当なことは書けませんので、改めて REST の原則から確認しました。新しい技術を追いかけるのはもちろん重要ですが、こういった基本の技術をしっかりと理解することも同じように重要です。 この記事では、調べた内容のシェアとして、REST の誕生から原則、リソース指向アーキテクチャの概要や特性などを解説します。文字文字しくなってしまいましたが、ご容赦ください。 概要 REST の誕生 REST の原則 原則はいくつあるのか 書籍「RESTful Web Services」 ROA（リソース指向アーキテクチャ）について ROA（リソース

これはいわゆるWeb APIについて、ということかなと推測しました。RESTというのはAPIのプロトコルのことだと思われている傾向がありますが、そういうわけではありません。Web全体についてのもので、APIについてもWebアプリについても適用されるものです。 実はRESTでは「統一インターフェイス」の制約からメソッドについて規定されていますが、URLの形については特に規定されません（もちろんAddressabilityの面で重要であることは言うまでもありません）。なので実は/books,/books/1でなくてもいいのですが、これを規約(CoC)でズバッときれいに決めてしまったのがRailsのすごいところの1つです。 本の追加や削除を行う場合は、本情報をJSON形式でPOSTリクエストのボディとして送ります。application/x-www-form-urlencoded形式で送ることは

◯ リソースを一意に識別 RESTな考え方では、すべてのリソースはURIで表されるユニークなアドレスを持つ。 ◯ ハイパーメディア(リンクのこと)を仕様 今では結構当たり前。パソコンのOSに保存された設定情報に依存せずにリソースにリクエストすること。つまり、どのパソコンでも同じレスポンスが返ってくるリンクをHTMLとかXMLに含める。 ※ クッキーとセッションを用いたアプリケーションはRESTではない。 クッキーとセッションの仕組み RESTはあくまで、固有のHTTPメッセージ(リクエスト/レスポンス)に対して、固有の表現を表示する。つまり、クライアント側はサーバーからのレスポンスをただ一意に読みこめば良い。逆にサーバー側もただ、クライアント側のリクエストを一意に返せば良い。しかし、クッキーとセッションの仕組みは、クライアント側(ブラウザ)にアクセスするためのクッキーを一時的に保存させてあ

Row Data Gateway An object that acts as a gateway to a single record in a data source. There is one instance per row. Embedding database access code in in-memory objects can leave you with a few disadvantages. For a start, if your in-memory objects have business logic of their own, adding the database manipulation code increases complexity. Testing is awkward too since, if your in-memory objects a