Nuxt.js × Atomic Designのサービスデザインフロー
2019/6/1 初夏のJavaScript祭りで使用したスライドです。 Atomic Designの考え方をNuxt.jsのコンポーネント分割に取り入れてサービス開発してみました。フロントエンドエンジニア、デザイナー両面からの視点でやってみて良かったことやハマりどころをご紹介します。
FlowのドキュメントにあるコードをひたすらTypeScriptのPlaygroundで試す - Qiita
Flow 0.74 Typescript 2.9 TypeScriptの設定は以下な感じ 先にまとめ やってみることによって学びがあった。良かった。 FlowのObjectTypeは必要なプロパティがあれば同じ型として使えるがTypeScriptの場合はそうではない。 基本型はだいたい同じだが、mixedがないのとvoidの挙動が違う。 Maybe型がない。 TypeScriptは型を書かないとanyになるがFlowは推論は推論してくれる 多分、お互いに似たようなことはできるが、実際にやるにはそれなりの経験が必要そうだ。逆をやってみるのも面白そう。 これをやってみた感じからするとFlowのほうが好み。 Stringへの暗黙型変換 // @flow "foo" + "foo"; // Works! "foo" + 42; // Works! "foo" + {}; // Error! "fo
JSON Schema 中心設計 - FlowType から RAML まで - - Qiita
はじめに Web サービスの運用を続けていくと，依存関係が徐々に複雑になっていきます．そしてメンテナンスするものが増えた結果，それらが相互に乖離していく，といったことが起こりがちです． そこで今回は，JSON Schema のみをメンテナンスしていくことで，動的チェック (バリデーション)，静的チェック (FlowType)，API ドキュメント生成，スタブ作成といった様々な恩恵を享受し，品質と保守性を同時に向上させるアプローチについて書いていきます．この JSON Schema を中心に据えたエコシステムを，JSON Schema 中心設計と呼ぶことにします． JSON Schema の仕様については割愛しますので，必要な方は こちら をご覧下さい．また，本記事では JavaScript での事例を紹介しますが，他の言語でも同様の適用ができるかと思います． アプローチ 本記事では，以下の
一からマイクロサービスの開発フローを作った話 - Qiita
※ 2016年の記事なので、すでに古い情報が多いです。 今の会社で、全社の外部サービスで利用できるAPIを作ってね、という話があったので、環境構築からコーディング、運用まで一人で行っている。 基本はAWSのサービスを利用し、ログの保存だけGCPのBig Queryを利用した。 ※ 2017/10/13 追記 このときの経験を踏まえて、コンテナでの環境構築を行ったので記録した。 → 一からAPIサーバの開発フローを作った話〜コンテナ編 関連記事 マイクロサービスで調査しやすいログをつくる マイクロサービスのテスト作成方針 マイクロサービス作成時におこなった負荷対策 deployフローに関しての振り返り ウェブサービス構築時に導入する、開発が3倍速くなる仕組み 簡単な要件 ゲームなど自社で利用するユーザアカウント情報を1つにする 現在のアカウントで引き続きサービスは利用できる アカウント以外に
もう保守されない画面遷移図は嫌なので、UI Flow図を簡単にマークダウンぽく書くエディタ作った - Qiita
はじめに Webサービスやアプリを企画したり、立ち上げたりする際にプロトタイピングツールや、ExcelやPowerpoint、Illustraterなどを駆使した謎のファイルで画面遷移図を描くことがある。 こういう図を元に仕様を決めて行って、サービスを作っていくのは以下の点で困る。 画面遷移図が保守されない。 書くのが非常に面倒くさい ユーザーのモチベーションの流れが追いづらく、見た目ばかりに注目してしまうものになりがち マシンリーダブル(ソフトウェアで構造を取り出せない)でない。 このような欠点があってどうにも扱いづらい。 そんなわけで、markdown風のテキストから簡単に画面遷移図を描けないかなとコンパイラを作成し、次にそれをインタラクティブに編集できるエディタを作成した。 UI Flows図について 画面遷移図的なものを書く際に、僕が個人的につかっていた表現方法として、UI Flo
システム障害と僕達はいかにして戦えば良いのか、障害対応について考えた - Qiita
IT界隈でエンジニアしていると、よく出くわすのが障害対応です。できれば会いたくないという人が多いと思うんですが、僕はけっこう好きです。障害対応。どこに原因があるのか調査をして、バランス良くベターな対応をしたときの楽しさは、プログラミングとはまた違ったものがあります。探偵っぽい感じが面白いですよね。もちろん、障害が発生しない状況を作るのが一番です 弊社では数多くのWebサービス／アプリを運営しているので、過去様々な障害対応をしてきました。その際に、解決までどんな道筋を僕がたどるのかを振り返ってまとめてみました。これが大正解なんてことはなく、人や事象によって違うとは思いますが。 なお、障害検知手法とか、サーバのコマンドとか、コードのデバッグ手法とか、具体的なことは一切出てきません。手続きと思考プロセス的な話です。 障害対応フローチャート 一般的な感じだと思いますが、障害報告から対応完了までのフ
アプリ開発にはGitlab flowが合うと思います - Shoichi Matsuda's diary
はじめに みなさまのプロジェクトではどのようにバージョン管理を行っているでしょうか。 ここでのバージョン管理とは具体的にはどのようなブランチを作ってどこにマージするか、リリースはどのように進めるかといった事柄を指しています。 今日は数あるバージョン管理戦略の中で比較的新しく提唱されたGitlab flowというフローを中心にして話していきたいと思います。 最近アプリの開発においてこのGitlab flowが個人的には一番しっくり来ているのでオススメしたいです。 有名なフロー gitは分散型のバージョン管理システムとして一世を風靡しており、いまや事実上のデファクトスタンダートです。 名前のとおり分散している（ローカル・リモートが明確に分かれている）ことやブランチ・コミットの編集も非常に容易で柔軟性が非常に高いです。 一方でその柔軟さゆえにルールをきちんと決めなければ各個人のフローが大きく異な
読み手に伝わりやすく！ブログに説明図を入れるときに便利な無料ツールまとめ
draw.io draw.io WEB上で無制限に無料利用できるドローツールです。 チャート、フローチャート、マインドマップ、モックアップ、ネットワーク図、ソフトデザイン図、回路図、ワイヤーフレーム他など、大抵の図なら簡単に作成できてしまうツールです。 日本語にも対応していて、操作性も良いので、かなりおすすめです。 出力方法も、PNG、JPG、GIF、SVG、PDF、HTML、XML、iframeで埋め込みなどと豊富です。（以下はPNG） Cacoo(カクー) Cacoo – Web上でフローチャートやUMLなど様々な図を作成 クラウド上で、簡単にサイトマップやワイヤーフレーム、フローチャート、マインドマップ、UML、ネットワーク図などの図を作成できるドローツールです。 作業シート、25枚までなら無料で利用することができます。 例えば、「PDCAサイクル」みたいな、「初めて聞いた人が、よく
Diagramly - Draw Diagrams Online
Flowchart Maker and Online Diagram Software draw.io is free online diagram software. You can use it as a flowchart maker, network diagram software, to create UML online, as an ER diagram tool, to design database schema, to build BPMN online, as a circuit diagram maker, and more. draw.io can import .vsdx, Gliffy™ and Lucidchart™ files . Loading... Please ensure JavaScript is enabled.
GitLab flowから学ぶワークフローの実践 | POSTD
Gitによるバージョン管理では、従来のSVNなどよりずっと簡単にブランチングやマージができます。さまざまなブランチ戦略やワークフローが可能であり、以前のシステムに比べるとほとんど全てが改善されたと言えるでしょう。しかしGitを利用する多くの組織はワークフローの問題に直面します。明確な定義がなく複雑で、Issue Tracking Systemと統合されていないからです。そこで、明確に定義された最良の実践的方法としてのGitLab flowを提案したいと思います。issue trackingには feature driven development と feature branches を組み合わせます。 他のバージョン管理システムからGitに移行する際によく耳にすることは、効果的なワークフローの開発が難しいということです。この記事ではGitワークフローとIssue Tracking Sys
開発フロー研修 @ Wantedly - Qiita
Githubでの開発 - Issue, Commit, Pull Request, Mention, Code Reviewに関する基本的なルール ゴール 「 チーム で 長期にわたって 生産性を上げる 」 前提 みんながサービス・プロダクトについて自主的に考える組織 エンジニア全員がそれぞれオーナーシップを持ってよりプロダクトを良くすることを考える いわゆるPM職の不在 = コードは書かずに、マネージだけする人がいない これは組織による。(e.g. 外注やディレクター職の存在) けれど、Wantedlyは、多少変化しつつも、より良いサービスを生み出すために、役割の程度の差はあれ全員がプロダクトについて考え責任を持ったほうが良いと考えている。 理想型 図:「青と黄色」のチーム構成が従来の縦割り+統括チーム、「緑(金)色」のところが目指すべきマイクロサービスチーム マイクロサービスチームは、
Facebook Flowの初見の感想 - Qiita
mizchi君の記事を見て、だいぶ感想が違ったので書くことにした。 なお、僕はTypeScript信者であることを踏まえてこの記事を読んでほしい。 あと、最初はまじめに記事にしようと思ったけどダルくなってきたのでメモをそのまま投げる。 TypeScriptより良い型推論 Flowパイセンの一番偉いところはTypeScriptより型推論が強いところだと思った。# /* @flow */ function foo(x) { return x * 10; } foo('Hello, world!'); 関数foo内部のxは、* 演算子を利用しているのでnumberであると推論している。 これが実際の利用箇所でstringを引数にしているので怒ってくれるわけだ。偉いな！ Flow is a static type checkerと謳っているとおり、完全にpure JavaScriptで書かれている
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Node-Based UIs in React – React Flow
マイクロソフト、IFTTT的なサービス連係サービス「Microsoft Flow」正式公開。GitHub、Dropbox、Slack、メール、Twillio、Googleカレンダーなど多数のサービスを連係可能 － Publickey
Sketchで変わるワークフロー
pixivの開発フローについて話しました - catatsuyとは