もう保守されない画面遷移図は嫌なので、UI Flow図を簡単にマークダウンぽく書くエディタ作った - Qiita
はじめに Webサービスやアプリを企画したり、立ち上げたりする際にプロトタイピングツールや、ExcelやPowerpoint、Illustraterなどを駆使した謎のファイルで画面遷移図を描くことがある。 こういう図を元に仕様を決めて行って、サービスを作っていくのは以下の点で困る。 画面遷移図が保守されない。 書くのが非常に面倒くさい ユーザーのモチベーションの流れが追いづらく、見た目ばかりに注目してしまうものになりがち マシンリーダブル(ソフトウェアで構造を取り出せない)でない。 このような欠点があってどうにも扱いづらい。 そんなわけで、markdown風のテキストから簡単に画面遷移図を描けないかなとコンパイラを作成し、次にそれをインタラクティブに編集できるエディタを作成した。 UI Flows図について 画面遷移図的なものを書く際に、僕が個人的につかっていた表現方法として、UI Flo
[翻訳]なんでGoってみんなに嫌われてるの？ - Qiita
原文：http://npf.io/2014/10/why-everyone-hates-go/ 酔っぱらった勢いで訳出してるので、違ってたら修正リクエストください。 訳者の１行でわかるサマリ それって、Goのシンプルな言語哲学が、ML系言語好きのアイデンティティを挑発しちゃってるからじゃないの？ いや、実際みんなって訳じゃないんだろうけど。最近、なんてGoをみんなそんなに批判的なのかって言うquoraの質問が出たもんで。（わるい、普段はquoraへのリンクを張らないんだけど、それがこの記事のきっかけだからね。）この質問への回答を見るまえにもう、僕には、次みたいなことが書かれていることがわかってた： Goは70年代に立ち往生した言語だ Goは40年間に及ぶプログラミング言語研究の成果を無視してる Goはブルーカラーの凡夫のための言語だ Go使いはJava1.0で仕事しても大丈夫なんだろう。
![[翻訳]なんでGoってみんなに嫌われてるの？ - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/3e47ec6b878ffabcea10cf86ffa8e2c8f98c5647/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9JTVCJUU3JUJGJUJCJUU4JUE4JUIzJTVEJUUzJTgxJUFBJUUzJTgyJTkzJUUzJTgxJUE3R28lRTMlODElQTMlRTMlODElQTYlRTMlODElQkYlRTMlODIlOTMlRTMlODElQUElRTMlODElQUIlRTUlQUIlOEMlRTMlODIlOEYlRTMlODIlOEMlRTMlODElQTYlRTMlODIlOEIlRTMlODElQUUlRUYlQkMlOUYmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZ0eHQtY2xpcD1lbGxpcHNpcyZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPWU3N2NhNTc1ZjdlM2JjZjRkYTdmNjI3ZjZmYmQxNGQ4%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwaGlyb2tpZGFpY2hpJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz00MmViZmQ0YmEwMzUxYTZmMGQyZjFhNWVhNzIyYjI2MA%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3D4d8c19ea19ffb0599017fbc64dee0829)
microservicesに分割する際に注意するべき5つのこと - Qiita
はじめに マーティンファウラーがmicroservicesの記事で、小さな役割をもったサービス群にアプリケーションを分割することを提案しています。 cookpadが、サービスをマイクロサービス群に分割していることの記事が注目を浴びており、最近急速にバズワード化しているように感じます。 バズワード化して、ポイントが損なわれる前にいくつかの注意点をまとめておきます。 1.インフラコストは基本的に増大する microservicesは、今まで単一のアプリケーションコードで行われていたことを複数のサービスサーバーに分割して管理・運営していくことです。ですので、プロセスを跨いだ通信が大量に発生します。その結果、サーバー台数は増大します。 つまり、インフラコストの増大と開発速度の高速化のコスト感覚をバランスして判断していく必要があります。疎結合性が高まり、アーキテクチャとしては美しく感じますが、実施に
ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習
最近、あまりプログラミングが得意でない人のサポートをする形で、長い時間にわたってペアプログラミングを行っている。そのなかで、気がついた悪い習慣と成長するための良い習慣というものをまとめてみる。 この記事のバックグラウンドとなる体系的知識が本になりました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング あわせて読みたい 経営者マインドが足りない！vs. 現場に任せてくれない！の対立をなくすカードゲームをつくった話 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習 あきらめるにはまだ早い！ソースコードの品質向上に効果的なアプローチ 心理的安全性ガイドライン（あるいは権威勾配に関する一
エンジニアなら知っておきたい障害報告&再発防止策の考え方 - Qiita
システムには障害がつきものです。どんなにしっかりと作られたサービスであっても思わぬところで、バグやミスが発覚して、トラブルになるものです。大事なのはこういった障害を次への糧にしていくこと。失敗というのは大事な資産なので、管理できるようにしましょうという話。 あわせて読みたい あきらめるにはまだ早い！ソースコードの品質向上に効果的なアプローチ メンタリングの方法について基礎をまとめました。内心でなく行動を変えることが障害報告とも共通します。 新入社員が来てメンターになれって言われたけど、どうすればいいのかという対話テクニック 半年で40kg痩せた！ダイエットでわかるリーンなプロジェクトマネジメント手法 心理的安全性ガイドライン（あるいは権威勾配に関する一考察） 障害の種類と障害報告について 障害には、小さなもの、たとえば画面に表示されているテキストの乱れから、すべての画面で50xエラーが発生
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
