system-design-primer#system-design-interview-questions-with-solutionsYou signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
GraphQLは何に向いているか - k0kubun's blog
今年GitHubがGraphQL APIを正式公開したあたりから、GraphQLが去年とかに比べちょっと流行り始めたように感じる。idobataがGraphQL APIを公開したり、Kibelaも公開APIをGraphQLで作ることを宣言している。 利用者側からすると使えるインターフェースの中から必要なものを調べて使うだけなのであまり考えることはないのだが、自分がAPIを提供する立場になると話は変わってくる。REST APIとGraphQL APIはどちらかがもう一方のスーパーセットという風にはなっておらず、どちらかを選択すると何かを捨てることになるので、要件に応じてどちらを選ぶのが総合的に幸せなのか考える必要がある。 以前趣味でGitHub連携のあるサービスを作っており、それを最近GraphQL API v4を使うように移行し、そこでついでにそのサービスのGraphQL APIを書いてみ
ReactNativeでの開発を通じて得た知見 - razokulover publog
前回はてぶのお気に入りフィードを読むHBFavというアプリのReactNative版RNHBFavというアプリを作っているという話を書いたが、とりあえずAppStoreへ申請するところまで終わった。 razokulover.hateblo.jp 申請がどのくらいで通るかはまだわからないが、たぶん1週間はかかる気がする。 少し時間が空きそうだし、ここらで今回ReactNativeで開発〜リリース申請する中で感じたことやこうした方が良かったみたいなものをメモしておこうと思う。 垂直分割/水平分割のディレクトリ構成 ディレクトリ構成はプロジェクトごとにみなそれぞれ自分なりの構成を持っているようだけど、例えばreduxを利用するアプリだと以下のような作りになると思う。 index.ios.js index.android.js src |__actions |__hoge.js |__reduce
「オブジェクト指向」や「アジャイル」では食えない - 設計者の発言
技術で安定的に稼ぐためには、どんな「専門性」を核に据えるかがカギである。その選定に失敗すれば、貴重な現役時代の１０年くらい簡単に無駄使いしてしまう。これを避けるためには、自分の専門性がターゲットとする「市場」をよくよく見定めておく必要がある。 先日、ある超高速開発ツールを活用している技術者の語りを聴く機会があった。彼は最初にハードウエアの設計技術者としてあるメーカーに入社したのだが、そこで製造管理を強化するために独力で生産管理システムを設計・実装してしまった。この経験を生かしてその後ソフトウエア技術者に転身し、ユーザ企業のシステム部門を渡り歩いてきた。現在所属しているメーカーでは、彼のおかげでシステム部門のプレゼンスが高まって感謝されているという。キャリア経験の中から「自分と家族を食わせてゆくための源泉」を見つけ維持している立派な技術者だと感心させられた。 特定の超高速開発ツールを利用して
デザインとプロダクト開発における「割れ窓理論」
by Tobias van Schneider first appeared on my private email list. 私が「割れ窓理論」に出会ったのは、数年前、当時働いていたSpotifyの同僚が勧めてくれたのがきっかけでした。 「割れ窓理論」とは、地下鉄の落書きを消したりすることで都市の環境をきちんと整備すると、破壊行為や路上飲酒といった小さな犯罪の発生率が下がり、街に秩序を好む雰囲気が生まれるというものです。そして、それがより深刻な犯罪の発生を減少させるというのが最大のポイントです。 比較的最近のニューヨークの例を紹介しましょう。1990年代にニューヨークの犯罪発生率は劇的に下がりました。重大犯罪がこの期間アメリカ全土で28%減少したのに対し、ニューヨークは56%以上も減少しました。どうして短い間にニューヨークの犯罪発生率はこれ程大きく落ち込んだのでしょう？ 一般的に、こう
だんだん開発スピードが遅くなっていくのをどうやってとめたら良かったんだろう？ - Mitsuyuki.Shiiba
先日、モブプロをやってきた。その中で、モブプロとは別で、いくつか感じたことがあって、今日はその中のひとつを思い浮かんだままにメモ。 bufferings.hatenablog.com 要件を満たすプロダクトをより早く出す モブプロでTDDしながら、要件を満たすプロダクトをより早く出すことに集中してみた。例えば、第２ラウンドのお題はTDDBCなどでお馴染みの「自販機」。 「100円を入れてボタンを押すとコーラが1本買えること」 最初に「100円を入れてボタンを押すとコーラが1本買えること」と言われ。 assertThat(get(100), is("コーラ")); みたいなテストを書いて。 String get(int money) { return "コーラ"; } みたいな実装を書いた。爆速！ 「200円を入れてボタンを押すとオレンジジュースが1本買えること」 次に「200円を入れてボタ
「絶対要らないハズだけど、なかなか削除できずにいるもの」を対応した小話 | メルカリエンジニアリング
はじめましてこんにちは。SREの@masartzです。 私は最近joinしたのですが、今回は本番環境に古くからあるテーブルの掃除作業をした案件をご紹介します。 tl;dr; 本番の住所情報テーブルを消したけど問題なかった話 絶対要らないハズだけど、なかなか削除できずにいるもの を対処する話 本番環境の住所情報テーブルをdropするまでの作業 今回、本番環境の住所情報テーブルをdropしました。 と言っても、事故でもうっかりでもなく、既に使われていなかったものの整理という作業でした。 何故使われていなかったかというのは、メルカリの住所情報の保持の仕方の変遷が関係しています。 初期にはuser情報と住所情報は1対1の関係でした。イメージとしては以下です。 CREATE TABLE IF NOT EXISTS users ( id INT UNSIGNED NOT NULL, name VARC
デザイン主導開発とは何なのか - 小さなごちそう
とても興味深い記事があった。 ▼ デザイナーが暴走する組織をつくってはいけないーAirbnbデザイン部門主任が語るスタートアップのあり方 翻訳元の記事はこちら。 かんたんに要約すると以下の通り。 デザイナー主導の組織文化では、デザイナー以外のスタッフの気づき（インサイト）がないがしろにされがち プロジェクトリーダーはエンジニアやデザイナーなど特定の部門を代表するのではなく、ユーザーを代表するべき ユーザーの都合と実装の都合がぶつかることでイノベーションが生まれる この主張には全面的に賛成だが、そもそもDesign-led（デザイン主導）に対する誤解がある気がする。デザイン主導開発とは、見た目が良いプロダクトを作ることでも、デザイナーの意見を最優先することでもない。要は人間中心設計、ユーザー中心設計で開発することで、つまりユーザー観察を元に企画し、開発プロセスの初期段階でユーザーテストを実施
実装を引き受ける前に詰めておくべきWebフロントエンドの想定漏れチェックシート - Qiita
リキッドレイアウトのように幅が常に変動するレイアウトのデザインは、動かないカンプからは実際の挙動が読み取れず、デザイナーの意図が汲み取りきれないことが多い。また、複雑化するアニメーションの実装においても、カンプだけではコミュニケーションに不備が生まれてしまう。ほかにも、CMSを使った案件ではデザインカンプと実際のデータの間に齟齬がある可能性もある。 実装効率を高めてスケジュール通りに仕事を終わらせるには、とにかく事前に仕様を固めることが大事だ。ワイヤーフレームやデザインの途中の段階からなるべくデザイナーとコミュニケーションを重ね、想定外の要件が発生しないように気をつけるべきだろう。 この記事では、デザイナーやフロントエンドエンジニアが見落としがちなWebフロントエンドの課題について列挙していく。 ホバー表現を後から指示される ツッコミ 後から仕様追加されると困るから先に決めて! メモ 最近
SVN脳患者から見たGit - Qiita
はじめに 僕はSVN脳患者である。SVN脳とは、SubversionのポリシーでGitを理解しようとしたり、使おうとしたりする病気で、中年プログラマに発症例が多い(気がする)。それまでSubversionを使ったことがない人がGitを使う場合には問題にならなかったことが、SVN脳患者がGitを使おうとすると問題になることが多い。特に、SVN脳を発症したプログラマは、そうでない人に比べてGit学習コストが爆発的に増大する。最初からGitに触れた人は、なぜSVN脳患者がGitを理解できないのかを理解できないだろう。 これは、SVN脳患者である僕1が、なぜGitを長いこと理解できなかったかをつらつら書くポエムである。病人の書いたポエムであるからして、所謂マサカリの類はほどほどにしていただきたい。 以下、「SVN脳患者」という大きな主語を多用するが、要するにこれは僕のことであり、言うまでもなくSu
グローバルゲームジャムでクラス設計をやった話2017 - Qiita
お知らせ 2017/11/26開催の「プログラマのためのUnity勉強会」において、 Unity開発で使える設計の話＋Zenjectの紹介 というタイトルで講演しました。こちらのスライドを先に見てから本記事を参照されることをおすすめします。 はじめに 去年に引き続き、今年もGGJに参加してきました。今回もそのことを書きたいと思います。 今回の内容は以前に投稿したUnity開発で便利だったアセット・サービス紹介 & Unityでのプログラミングテクニックとつながりがあるので、こちらを先に読んでからのほうがわかりやすいかもしれません。 Global Game Jam とは GGJとは全世界同時に行われるゲームジャムのことです。要する、世界規模のゲーム開発ハッカソンです． プログラマ、デザイナ、プランナ、グラフィッカなど様々な役職の人をごちゃまぜに、3～8人程度のチームを組み、48時間でゲームを
ペロリ流 開発要件のまとめ方 - peroli Developer's Blog
2016 - 07 - 22 ペロリ流 開発要件のまとめ方 開発プロセス list Tweet こんにちは。開発部のマネージャーをやっている mizushimac です。 今回は開発するモノの要件のまとめ方についてペロリ開発部が実践している内容を少しご紹介したいと思います。みなさんの会社やプロジェクトではどうやって開発するモノの要件をまとめていますか？ パワポ ですか？ spreadsheet ですか？ 流れ行く slack や github issue で議論しながらコメントに埋もれていき誰かが箇条書きでまとめますか？ きっとカオスなことが多いかなと思いますのでこのエントリーが少しでもご参考になればと思います。 ちなみに、ペロリはカオスを楽しめる人を求めていますw 開発要件のまとめ方って色々あって難しい 私が学生の時に所属していた ベンチャー企業 では、数十MBもある パワポ に画面イメ
マイクロインタラクション事始め以前 - MOL
（アニ GIF あるのでちょっと重いです…） マイクロインタラクション事始め以前 @Yahoo!Japan 2016.07.04 先日、とある社内勉強会にて発表する機会があったので書き残しておく。要は最近のフロントエンド開発の流れに疲れて、もうちょっと違う方向で頑張ろうと思った話。 葛藤 Kaizen Platform, Inc. フロントエンドデベロッパーの t32k です。皆さん、ご存知かもしれませんが、Kaizen Platform は A/B テストツールを提供しています。その A/B テストのデザイン案も国内外約 2 千名のグロースハッカーと呼ばれる方々から、クラウドソーシングで調達することができます。なので、自社内にデザイナー抱えてなくても A/B テストが実行可能です。 グロースハッカーの登録自体は無料ですので、デザイナーの方はぜひ登録してもらうと、コンバージョン率の高いデザ
スマートフォンアプリ開発における共創的な開発チーム
複雑かつリッチな体験を提供するスマートフォンアプリを開発するためのチームワーク、その中でのエンジニアの役割について
デザインパターンをチームで学んで得たもの - CARTA TECH BLOG
おはようございます、こんにちは。Zucks Affiliate事業本部でエンジニアをやっている新卒二年目のだっちと申します。 この事業部には最近部署異動で配属され3ヶ月ほど経ちました。 さて、今回は@t_wadaさんと事業部内エンジニアで毎週行っているJava言語で学ぶデザインパターン入門の読書会で得た知識によって設計の語彙がチームに浸透してきて円滑にリファクタリングの方向性が進んだ話をしたいと思います。 簡単な事業部紹介 Zucks Affiliateは名前の通りアフィリエイトを扱っている事業部で、エンジニアや営業間のコミュニケーションも盛んで日々雑談から事業・技術的な相談まで気軽にしています。 エンジニア間では朝・夕会でお互いにやっていること・詰まっている部分を共有しているのに加えて、コードは全員でレビューし、具体的に何をしているかがしっかりと把握できている状態になっています。 総じて
第２回 Elasticsearch 入門 データスキーマ設計のいろは | DevelopersIO
第2回目の Elasticsearch 入門は「データスキーマ設計のいろは」です。 設計と言うほどでもないのですが、例えば RDB で検索にフォーカスした設計や、他の検索エンジンも経験していると、これまでの制限や習慣で Elasticsearch の特徴を生かせない設計をしてしまう事があるので、このテーマにしてみました。 それではインデックスするためのデータ構造を Elasticsearch でどのように設計するのか解説したいと思います。 設計フローまで変えてしまう画期的なドキュメント指向型検索エンジン Elastic 社のホームページを見てみると Elasticsearch の特徴の１つとして「Document-Oriented」と言う記載があります。直訳すると「ドキュメント指向」です。 簡単に説明すると 現実世界の複雑なデータをJSONドキュメントにしてインデックスするだけで、デフォル
クックパッドにおける最近のMicroservices事例 - クックパッド開発者ブログ
こんにちは。技術部の吉川です。 最近ではMicroservicesという言葉もかなり浸透し、そのテクニックも体系化されつつあります。 一方でMicroservicesについての話は概論や抽象的な話が多く、具体像が見えないという方もいらっしゃるのではないでしょうか。 当ブログでは1年半ほど前にMicroservicesへのとりくみについてご紹介しました。 当時社内ライブラリだったGarageはその後オープンソースとして公開され、また社内のシステムも当時と比べ飛躍的な進化を遂げています。 そういったクックパッドにおける最近のMicroservices事例を先日Microservices Casual Talksで紹介しました。 Microservicesの抽象的な話は一切割愛し、具体的な事例に終始した内容となっています。 Microservicesの基本となる考え方はわかったものの、実践方法で
Pelletkachels.nl
Pelletkachels waren ooit eenvoudige apparaten voor verwarming, maar ze hebben een opmerkelijke evolutie doorgemaakt sinds hun bescheiden begin in de jaren ’80 van de vorige eeuw. In dit artikel duiken we diep in de geschiedenis van pelletkachel, bespreken we de belangrijkste mijlpalen en ontwikkelingen op het gebied van subsidiemogelijkheden en werpen we een blik op de transformatie tot moderne en
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
システムエンジニアのカレンダー | Advent Calendar 2016 - Qiita
ネットゲームデータベース設計むかしばなし、あるいはとんでもないMMORPGの設計の話: 不倒城