チームに「効く」ダッシュボードを考える - コネヒト開発者ブログ
Creating Effective Dashboards こんにちは、サーバーサイドのお仕事してます金城(@o0h_)です。 つい先日、なんか気分が乗らないぜ〜〜って時にスピナーベイトを読み直してみたんですけど、気分の悪さが・・・上塗りされました・・・気をつけましょう。 スピナーベイト (1) (バーズコミックス) さて、今回は抽象的な話になります。 「チームで毎日見るようなプロダクトの成長のためのダッシュボードってどういうのを作るんだっけ」という内容です。 TL;DR 以下のポイントを抑えると「効くダッシュボード」ができるのでは、と考えています。 「なんとなく」で作るのはダメ🙅 目的を持ち、「誰が」「いつ」「何のために」という意図を明確にする 通常のプロダクトと同じく「UX」「ペルソナ」大事 「必要なこと」を厳選する。全てをダッシュボード上でやる必要はない digるのは他の場所で。ダ
質問は恥ではないし役に立つ - Qiita
一年半SEとして働いてきた中で、私自身が苦手だと思っており、他人からもそのように評価されていたのが「質問の仕方」でした。 それが先日、他人から「質問の仕方がうまいね」と褒められることがあり、ようやく一人前の質問の仕方ができるようになってきたので、どのようにして克服できたのか紹介したいと思います。 質問の基本形 私が入社したばかりの頃は、わからないことがあればすぐに先輩に質問していました。 そのときにしていた質問の内容はだいたいこんな感じです。 「環境構築を手順書通りにやったんですけど、○○のコマンドでエラーがでてしまいます！なんとかなりませんか？」 このような質問を受け取ったら、先輩は暇ならばエラーメッセージを見てくれ、エラーメッセージに書かれていることに対して調査してくれるかもしれませんが、忙しいときにはそんなことはしてもらえません。 こんな質問を繰り返しているうちに先輩からは「技術系メ
クックパッド サマーインターンシップ2016の資料を公開します - クックパッド開発者ブログ
技術部開発基盤グループの @moro です。 クックパッドでは、昨年に引き続き今年も、夏の技術職インターンシップを実施しました。 クックパッドのインターンシップは前後半に分けた構成になっていました。まず前半はWebサービス開発に必要な技術の中から6つの分野に関する講義や実習を行いました。さらに後半は、前半の座学に合格した方を対象に、メンターとなる社員と一緒に実際の開発現場に入り、具体的な問題解決に取り組んでもらいました。 その中で、前半の講義に使った資料を公開します。 1日目 Git (@moro) 昨年に引き続き、講義初日はGit, TDD, Railsを1営業日で一巡りするという、忙しい構成でした。 Git編では、すでにGitを使っているエンジニアも多いだろうと想定して各コマンドの紹介などは最小限に済ませました。代わりに、Gitの内部構造を説明し「コミットを覚えておけばなんとかなる」感
2人で楽しくサービスやアプリを作る話
YAP(achimon)C::Asia Hachioji 2016mid in Shinagawa Talk 7/3 10:00- スライド資料です 子供のころは、秘密基地作ってる最中が一番楽しかったりしました。小さいサービスやアプリを2人で作るときに、企画・設計・開発を「2人で」楽しく進められるように、いくつかのサービスで行ってきた具体的な事例をベースに、簡単にできる方法を話します。 - アイスブレイク - ものづくりのフローを楽しく - ものづくりのフロー - ブレストの基本 - ホワイトボードの基本的な使い方 - スケジュール調整の基本 - イメージをすり合わせて一緒に形にしていく - リード・ファーストフォロワーを2人で使い分ける - アドホックペルソナと簡易シナリオ - リアルの時間を楽しく過ごす - メッセージやりとり - 開発合宿
これだけはやっておきたい〜マイクロサービスのデプロイメント - クラウドワークス エンジニアブログ
Scala大好きインフラエンジニアの九岡(@mumoshu)です。マイブームはConcourse CIですが、今日はマイクロサービスの話をさせていただきます。 TL;DR; 「サービスの負荷上がってきたし、マイクロサービス化しよう。マイクロサービス化って、Railsアプリ分割して、それぞれCapistranoでデプロイしておけばいいんでしょ？」*1 マイクロサービス化をするためには、アプリケーションだけでなくインフラや運用のことも考える必要があります。 この記事では、クラウドソーシングのクラウドワークスが来るマイクロサービス化に向けて認識しているデプロイメント上の問題とその対策を紹介します*2。 テストからデプロイまでがめんどくさいよ問題 →Dev/Prod Parity、Infrastructure as Code、CI、ビルドパイプライン リリースに1時間かかるよ問題 →ビルドキャッシ
16年間うごいているWebアプリケーションが抱えていた技術的負い目を考察する | GMOメディア エンジニアブログ
技術推進室の浅井です。 技術的負い目とは、世に言う技術的負債のことです。 社内で技術的負債の定義、ことばの表現を考える中で、「『負債』は優れた比喩表現であるものの、第三者への返済義務がない点で会計上の負債とは異なり、言葉としての問題も多く、不必要な議論を生み出しやすい」などの指摘があり、代わりの表現として社内の一部で使われている言い回しです。 最近社内のたいへん古いシステム（16年の歴史があります）の技術推進を行う機会があり、たくさんの技術的負い目と向き合いました。 そのような古いシステムの技術的負い目と向き合ったとき、エンジニアはストレスを感じ、ネガティブな感情を抱いてしまいがちです。負い目に苦しめられることで過去のコードや技術的判断に対して不満を言いたくなる気持ちはとてもよくわかりますし、実際に私もたくさん苦しんでたくさん不満を言いました。 ですが技術的負債の文脈でよく言われるとおり、
プロジェクトを成功させるために最初におこなっていること - $shibayu36->blog;
ディレクター時代に仕事でプロジェクトを受け持つ時にどうやったら成功させることが出来るのかについていろいろ考えていた。僕は開発フローをいろいろ考えるのが好きなのだけど、実際に自分がリーダーシップを取ってプロジェクトを進めることを経験すると、そもそもその前に考える・決めるべきことがたくさんあるということが分かったので、ブログに書いておこうと思う。 ここで言うプロジェクトとはサービスを一から作ったり、サービスの一機能を作ったり、受託案件一つだったりを指す。特に開発プロジェクトに限定するものでもない。 プロジェクトを成功に近づけるためには、まずプロジェクトの開始時に、プロジェクトの5W1Hを明確にし、個々のメンバーの責任範囲を決め、それらを一つの場所にまとめておくということをしておくと良いと考えている。 5W1Hを決める すごい基本的なことだけど、プロジェクトをやる上でやはり5W1Hは大事である。
夏の技術職インターンシップ講義資料公開 - クックパッド開発者ブログ
こんにちは！クックパッド編集室メディア開発グループ長の @yoshiori です。 このまえ夏の技術職インターンシップの前半の開発講義・課題部分が終わったのでさっそく公開しちゃいます！ ちなみにこのインターンの対象者はプログラミングはわかるし自分で（授業とかではなく）コード書いている人なので超初心者向けでは無く、少なくともひとつ以上の言語でプログラミングが出来る人向けです。 一日目 TDD + git 編（@yoshiori） 講義初日なのでまずは簡単に肩慣らし & 開発の基礎の部分として TDD と git で始めました。 git については軽く説明し TDD は基本のテストファーストで進めて行きました。 ちゃんと何かをするたびにテストを実行し、メッセージを見れば次にすることが分かるというのを体験してもらい、GREEN が良くて RED が悪いのではなく、GREEN を想定しているのに
スケールする開発組織の作り方 #jawsug
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
コメントの9割は無駄！～アンチプラクティスから学ぶ洗練されたコメントの書き方～ #code #コード｜CodeIQ MAGAZINE
コメントは基礎的で一般的なものでありながら、「どのようなことをコメントに残すか」は経験のあるプログラマにとっても難しいもの。 この記事では、アンチパターンコメントを見ながら、どのようなコメントを残すべきかについて説明します。 by 馬場美由紀 （CodeIQ中の人） コードは機械のために、コメントは人間のために? プログラミング言語を学ぶとき、コメントは最初に習う項目のひとつです。そして、プログラムであればコメントを含んでいることが普通です。ある研究によれば、ソースコードの平均19%がコメントだそうです。 コードを書くとき、私たちは機械とコミュニケーションを取ることを意識しています。機械はコードを認識してコンパイルしたり実行してくれます。解釈できなければ教えてくれます。プログラマは、コンパイラのためにデータ型を明示するコードを書いたりもします。 一方、コメントは人間とコミュニケーションする
発注側から見て、困った開発をどうするか。 島国大和のド畜生
・2023年03月 (1) ・2023年02月 (1) ・2023年01月 (2) ・2022年12月 (1) ・2022年11月 (3) ・2022年10月 (1) ・2022年09月 (1) ・2022年08月 (1) ・2022年07月 (1) ・2022年05月 (2) ・2022年04月 (1) ・2022年03月 (1) ・2022年02月 (1) ・2022年01月 (1) ・2021年10月 (1) ・2021年08月 (1) ・2021年07月 (2) ・2021年05月 (1) ・2021年04月 (1) ・2021年03月 (1) ・2021年02月 (1) ・2021年01月 (1) ・2020年12月 (1) ・2020年11月 (1) ・2020年10月 (1) ・2020年09月 (1) ・2020年08月 (2) ・2020年06月 (2) ・2020年04
私が超高速開発コミュニティに託しているもの - ジャスミンソフト日記
先ほどまで @yusuke さんと私、もう一社のコミュニティ幹事の方と3名で熱く議論していたところです。正直、@yusuke さんにはこちらの不手際が重なり、どうお詫びしていいのやらという厳しい状況でもあったので丁寧に説明しました。ただ、語るほどに目標としている世界観が近いと感じたので、できればコミュニティに参画していただきたいと願っています。至らない点は（図々しいのは承知の上で）一緒に改善していきましょう、と。時間はかかるかも知れませんが、あまり心配していません。同じ問題意識を持っている方がそれぞれの知見を出し合い、相互に改善するプロセスを回すことができれば、うまくいくはずです。 ところで超高速開発コミュニティは、どうしてもツールベンダーが営業するための仕掛けと勘ぐられるところがあります。それは活動実績によって明らかにするしかありませんが、少なくとも「どうしたいのか」も見えないというのは
オバマケアのサイト不具合はなぜ起こった？ 現場の泥沼：Behind the HealthCare.gov Disaster
オバマケアのサイト不具合はなぜ起こった？ 現場の泥沼：Behind the HealthCare.gov Disaster When we spend $630 million, this is what happens. 6億3000万ドル（630億円）を投じた国家プロジェクトは、なぜ見切り発車したのか？ 米医療保険改革（オバマケア）の柱のオンライン保険購入システム「HealthCare.gov」が10月1日オープンするなり盛大にクラッシュした件で、NYタイムズが舞台裏の話を書いた。 関係者は政府も企業も全員、守秘義務があるので、これまでこういう話はなかなか出てこなかったけど、たぶんCGIはこれで切られるのかな…企業側の話もかなり入ってるよ。要点を拾っておこう。 壮大な構想を語る政府 vs. 目の前の現実を語る請負業者 システム開発を請け負ったCGIフェデラルはじめ各社は8月の段階で、「
メールに関連した開発のお供に。Java製ダミーメールサーバ·FakeSMTP MOONGIFT
FakeSMTPはJava製、マルチプラットフォームで使えるダミーのSMTPサーバです。 テスト用にダミーのSMTPサーバが必要になったらFakeSMTPを使ってみましょう。Java製なのでマルチプラットフォームで使えて便利です。 メイン画面です。サービスを開始します。 開始しました。この状態でプログラムからメールを送ってみます。 リストに送信したメールがあがってきます。 ダブルクリックで本文が読めます。 ログです。 最後のメッセージは細かく見られます。 実際のメールアドレスを使って開発していて、間違って一括メール送信してしまったなどといったら目も当てられません。FakeSMTPを立てて決してメール送信されないようにしておけば安全に開発、運用ができるでしょう。 FakeSMTPはJava製のオープンソース・ソフトウェア（BSD License）です。 MOONGIFTはこう見る メール周り
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
System of Record と System of Engagement
あの日見た M V Whateverの Modelを僕たちは まだ知らない
突如見知らぬ言語に出会ってしまった俺達は
時雨堂を支える技術
「チーム開発実践入門」勉強会
Amazon.co.jp： Webアプリエンジニア養成読本 〔しくみ、開発、環境構築・運用・・・全体像を最新知識で最初から! 〕 : 和田 裕介, 石田 絢一 (uzulla), すがわら まさのり, 斎藤 祐一郎
