個人開発のモチベを上げるおしゃれリポジトリ駆動開発 - Qiita
はじめに 皆さんは個人開発しているでしょうか？？ 私はしたいなと思いながら開発を始めるも環境構築で燃え尽きたり、作りたいものの規模が大きくて最後まで作りきれなかったりすることが多かったです。 なので、書籍などを学習するほうが先が見えるので好きな傾向にありました しかし、最近周りの人たちがプライベートにいろいろ作っていることに危機感を覚えて自分なりにどうすればモチベーション高く個人開発ができるのかを考えたのでまとめます それが おしゃれリポジトリを作る という考え方です まさに 「おしゃれリポジトリ駆動開発」です おしゃれリポジトリとは 文字のままですが、自分がアプリケーションを愛せるようなおしゃれなリポジトリを作るということです 例えば最近作った「Sanpo」というアプリケーションがあります 実際にGitHubをみてほしいのですが、おしゃれなバナーが用意されおり目を惹くようなリポジトリにな
エリート DevOps チームであることを Four Keys プロジェクトで確認する | Google Cloud 公式ブログ
※この投稿は米国時間 2020 年 9 月 23 日に、Google Cloud blog に投稿されたものの抄訳です。 DevOps Research and Assessment（DORA）チームが実施した 6 年間の研究から、ソフトウェア開発チームのパフォーマンスを示す 4 つの指標が確立されました。 デプロイの頻度 - 組織による正常な本番環境へのリリースの頻度 変更のリードタイム - commit から本番環境稼働までの所要時間 変更障害率 - デプロイが原因で本番環境で障害が発生する割合（%） サービス復元時間 - 組織が本番環境での障害から回復するのにかかる時間 概要レベルでは、デプロイの頻度と変更のリード時間は速度の指標であり、変更障害率とサービス復元時間は安定性の指標です。チームはこれらの値を測定し、継続的に改善を繰り返すことで、ビジネス成果を大幅に向上させることができま
Gitのワークフローについての私のスタンス | おそらくはそれさえも平凡な日々
Gitのワークフロー、好みが分かれる分野で自転車置き場の議論にもなりがちだと感じている。基本的にはプロジェクトの流儀に素直に従い、余計なストレスを抱えないのが良いと考えている。例えば、私はマージコミットを作るのが好みだが、OSS活動等では「squash & mergeして」って言われることもあり、そういうときは当然素直に従うようにしている。 ということで、私のGitのワークフローについてのスタンスについて書いておこうと思う。私と一緒に働く人や、働くことを検討している人の参考になればと思います。もちろん、この辺りは、良い方向に変化もさせていきたい。例えばエントリー内でも触れていますが、私は昔はforce pushを禁止したいくらいでしたが、今は使っても良い、と思うようになりました。 Natureの特にGoでのバックエンド開発はこれに近い感じだとイメージしてもらえればと思います。ただ、できてな
PullRequestからチーム開発の生産性・健全性を測るCLIツールを書いてみた - $shibayu36->blog;
最近、開発チームの生産性や健全性をどのように計測したら良いかについて興味を持っている。その中で「LeanとDevOpsの科学」の中に書いてあるようなデプロイの頻度・変更のリードタイム・MTTR・変更失敗率の4指標や、開発チームの生産性・健全性を客観的に知るためにリポジトリ履歴から機械的に可視化するツールを作った - Qiitaに興味を持った。 一方、それらの指標を考えてみた時、以下のような点について悩んでいた。 マイクロサービスなどで複数レポジトリとなり、さらにデプロイ手法がそれぞれ違う状況の場合、変更のリードタイム = コミット〜本番稼働までの時間を計測するのがなかなか難しい コミットという単位だとかなり小さく、個々人のばらつきも大きすぎるように感じるので、もう少し良い単位はないのだろうか このような悩みから、PullRequestの単位で集計することで、生産性や健全性をもう少し測りやす
Markdown と GitHub で社内規程を便利に管理 - クックパッド開発者ブログ
VP of Technology の星 (@kani_b) です。技術基盤や研究開発領域などを担当しつつ、社内の色々なことを技術の力でいい感じにする仕事をしています。セキュリティや AWS の話が好きです。 さて、みなさんは、ご自身が勤務する会社の就業規則を読んだことはあるでしょうか。 エンジニアに限らず、会社の全スタッフが仕事をする上で関わってくるのが、就業規則や情報セキュリティドキュメントなど、会社のルールや規程を記す文書です。 特にセキュリティやインフラに携わるエンジニアは、その改訂も含め携わったことがある方もいるのではと思います。 よくある文書管理 こうした文書は、以下のように管理されていることが多いようです。 ベースドキュメントは Word 保存時は PDF で保存 版管理は Word の編集履歴 + PDF に保存する際のファイル名 編集は担当部門, 担当者のみが行う かつての
PWAゲームを開発しネイティブアプリ化までした中での課題と対策 - builderscon tokyo 2019
Abstract 本セッションでは、PWAゲームを開発し1年以上運用してきた経験から アセット配信 マスターデータの配信や管理 アニメーションや動画を使ったリッチな表現 一部ユーザーからのチート行為への対策 といったゲーム開発を行う上で必要となる諸機能が、ブラウザというフィルタを通すことで 「ディスクキャッシュ容量が限られる中でいかに通信量を減らして」アセット配信するか 「ブラウザのストレージ容量が5MB,10MBと制限される中での」マスターデータの配信や管理 「通信量を抑えなければならない中での」アニメーションや動画を使った表現 「DeveloperConsoleから簡単に通信情報やソースコードが見れる中での」チート行為対策 と変貌することへのとりうるアプローチの考察や実際に行った対策について、 クライアント・サーバー両方の立場から説明していきます。 ( 説明の中には、Goやcgoを使っ
「大規模なUI改修」を行うとどうなるか
アプリケーションを実装していくと、「大規模なUI改修」に遭遇することがある。 あちこちで見聞きした結果、以下のようなパターンがあるように感じたのでまとめてみた。 （UI改修なので基本的にフロントエンドからみた内容） これは一般的に「技術的負債」と呼ばれることが多いが、デザインの負債（UIを置く場所が無くなったり無くなったり、同じ概念のUIが分散したり）である場合も多い。 （ちなみに、デザインの負債は「ダイアログを多用する」とか、「最小画面サイズが大きくなる」とかの形で現れやすい） そして、デザイン負債に対応するために実装の困難なUIが増えるため、技術的負債も高くなる傾向がある。 （サーバサイドの技術的負債がDBの負債に起因する場合が多いことと似ているかもしれない）
身の丈にあったWebAPI設計ガイドラインを作った話 - Qiita
こんにちは。フリーランスエンジニアの@dayoshixです。 現在、リンクアンドモチベーションのモチベーションクラウドの開発に、主にフロントエンドエンジニアとしてお手伝いさせて頂いております。 そのようなご縁もありモチベーションクラウドのアドベントカレンダー（３日目）に参加させて頂くことになりましたので宜しくお願いします！！ トップバッターの@ishigeさん、２日目の@HayatoKamonoさんお疲れ様でした！！ お二人の記事はこちら。どちらも力作なので宜しくお願いします。 1年半取り組んだWebプロジェクトマネジメントを振り返って、やって良かったこと、やっておけば良かったことをすべて書く Vueを用いた開発プロジェクト用にカスタムジェネレーターを作ってみる ということで始めたいと思います。 概要 最近モチベーションクラウドのWebAPI設計ガイドラインが作成されたのですが、それはどの
DX: Developer Experience （開発体験）は重要だ - Islands in the byte stream
DX: Developer Experience （開発体験）とは、あるシステムを「気持ちよく開発・保守できるかどうか」を示すもの 開発者は開発・保守という行為を通じたそのシステムのユーザーであり、DXはUXの一種である DXがよいと日々の開発を楽しめるようになり、気持ちに余裕ができる 気持ちの余裕がでるとコードの品質があがり保守時のデグレも減らせる また、DXがよい事自体がDXを高める動機になり、正のスパイラルを見込める つまり、「定められたタスク」（＝義務）以上のことを行うようになる DXが悪いと開発を楽しめず、「定められたタスク」以外のことをしたくなくなる DXは放置すると悪化するので、「DXがよくも悪くもない」プロダクトは時間が経つに連れ「DXが悪い」になる なので積極的にDXを良くしていく活動を奨励していくのがよい いくつか興味深いフィードバックがあったので記しておきます。 DX
SIGPX: Special Interest Group on Programming Experience
SIGPXは、プログラミングのための環境と、その環境が提供する体験の設計に興味を持つ人で集まり、最新の研究動向や事例について情報交換する会です。 The English translation is available here. 何でやるの？──かつてコンピュータのユーザが全員プログラマだった時代、プログラミング言語・ソフトウェア工学とHuman-Computer Interaction・ユーザインタフェースの研究には何の違いもなかったはずです。その後、GUIの登場とともにプログラマ・エンドユーザの区別が生まれ、分野が細分化しました。今また、誰もがプログラミングを学ぶべき時代と言われるようになり、これらの研究分野を横断してUXならぬPXすなわち「プログラミング体験」を考え直すべき時期がきているように思います。 企業が最先端の研究をしてデプロイしていることが当たり前のご時世、研究と開発を分
あるエンジニアが「Kibela」というサービスを考え、リリースするまでのフローを全部教える - エンジニアHub｜若手Webエンジニアのキャリアを考える！
あるエンジニアが「Kibela」というサービスを考え、リリースするまでのフローを全部教える エンジニアがサービスのアイデアを思いつき、それをリリースするまでにはどのような過程があるのでしょうか。情報共有ツール「Kibela」が世に出るまでのフローを、起業した井原正博さんが詳細に振り返ります。 ヤフーやクックパッドでの開発を経て、ビットジャーニーで代表を務める井原正博（いはら・まさひろ／@ihara2525）です。プライベートで超長距離のランを楽しむかたわら、情報共有ツール「Kibela」の開発・運営を手がけています。 Kibela - 個人の発信を組織の力にする情報共有ツール 「Kibela」は僕自身が2015年に起業して立ち上げたサービスですが、この記事では、僕がサービスをいかに開発したか、その方法からリリースまでの過程を振り返りつつ、サービスの現在の状況までお伝えします。 「自分でもサ
デスマーチが起きる理由 - ３つの指標
鳥のさえずり声を聞いて、私は悪態を吐いた。今日の早朝に予定されていたミーティングのことをすっかり忘れていたのだ。 まったく、最悪の朝だ。着替えている間に、電話も鳴った。「高い金を払ってコンサルタントを雇った極めて重要なミーティングだ」と念を押されていたというのに。 それもこれも昨日のバグのせいだ。睡眠時間も、開発スキルも、人員も、私の現場には何もかもが足りていない。 それにも関らず、理解の足りない上司は「テスト工程を削ってでも早く納品しろ」とプレッシャーを与えてくる。 あの馬鹿どもめ。一体何を考えているんだ？ スーツに着替え終わった私は、冷蔵庫の缶コーヒーで空腹を誤魔化すと、バイクに跨った。通勤時間が5分なのが、せめてもの救いだ。 「遅れてすまない」 そう言って会議室に入ると、奇妙なことに気がついた。教室のように整然と並んでいたはずの机が、即席の半円形に並べ替えられていた。 何より、ホワイ
「新機能作成時に開発ブランチに細かくmergeしていく戦略」について社内勉強会で発表しました - Hatena Developer Blog
はてなのアプリケーションエンジニアのid:shiba_yu36です。社内技術勉強会で「新機能作成時に開発ブランチに細かくmergeしていく戦略」という発表をしたので、資料を公開します。 speakerdeck.com 以下、簡単に文字でまとめておきます。 戦略 ユーザーに新機能が見えないようにする工夫をし、新機能のbranchもどんどん開発ブランチにmergeしていく mergeされたものは随時本番にリリースされるが、ユーザーに見えない工夫をしているので問題なし PRは可能な限り細かくする 機能が完成したら最後にユーザーに新機能を見えるようなPRを作り、mergeしてリリースする なぜこの戦略を使うのかいろんな失敗を経験して、この戦略を最近使っている。 失敗パターンその1: 巨大PRパターン 失敗パターンその2: 新機能リリースブランチパターン 失敗パターンその1: 巨大PRパターン 新機
22名で開発合宿いったけど土善旅館さん、なんだこれまじで最高か？ - Qiita
12/3~12/4 Swift愛好会で開発合宿！! Q.合宿したいね〜 A.しよや！！！ 開催日きめよか タイミングが合わなくていきたかったけど行けない！という事象がなるべく少なくてすみように、事前にコアメンバー７人くらいにまず空いてる日を複数教えてもらいました 12/3~4 でいこか 宿決めよな @afroscript10 運営の木下さんが「ここがいいんじゃないですか？」とのことで 開発合宿界隈では安いと有名なお宿に決定！ wifiも良くて、なにかがわるかったとかいう口コミが全くない！ 最高待遇か？（1回目） 予約テレフォン 11/３11/7に電話して、12/3~4日に15名前後ということで仮予約 年末だし行きたがる人多いかなー空いてないかもなーとかおもってたんだけど奇跡かな。予約できました。 おかみさんからの確認事項 開発の部屋と宿泊の部屋が同じになるお部屋は予約が入ってしまっててNG
全プログラマーが一般教養として知っておくべきセキュアプログラミング、「明日から現場に生かせる」短期集中講座が開講
7月のCodeZine Academyは「セキュア開発Boot Camp」だ。セキュア開発とは、要件定義、設計、コーディングの段階で、脆弱性を作り込まないようにする考え方。このセミナーでは、26日と27日の2日間、基礎編・適用編と分けて、じっくりセキュア設計、セキュアコーディングの考え方と実装スキルを習得する。セミナー実施に先立って、講師を務める岡田良太郎氏（株式会社アスタリスク・リサーチ エグゼクティブ・ディレクタ / OWASP Japan Chapter Leader）に、どんな内容なのか、どんな意味があるのか、話を聞いた。 OWASP Japan Chapter Leader 岡田良太郎氏 セキュリティ人材よりも不足している セキュアコーディングが行える人材 一般にセキュリティ対策といえば、ファイアウォールやウイルス対策といった入口対策、監視・監査・多重認証といった出口対策、あるい
ユーザーに受け入れられ、問題を起こしづらい大規模リニューアルの進め方
iOSDC Japan 2016の発表資料です。 https://iosdc.jp/2016/c/node/84
test.comやaaa.comをテストデータに使うのはやめましょうという話 – 打つか投げるか
2018/02/13追記：「サンプル用のドメインを使おう」の説明に “.example” と “.test” の使い分けについて追記しました。 Web システム開発時のテストデータを作成する時、また各種ドキュメントを書いている時など、サンプルの URL を使う場面は多いと思いますが、その時に適当なドメイン名を使うのはやめましょう、という話です。 知っている方には当たり前レベルの話ですが、意外と IT 企業のシステム開発現場等でも普通に見かけることがまだまだありますので・・・。 よく見かける例 例えば、こんなドメインの URL で開発中システムのテストデータを作っていたり、仕様書に説明が書かれていたりする場面をよく見かけませんか？ test.comaaa.comabc.comsample.comdummy.comhoge.com でも、これらのドメインって存在していて、また実際に利用されてい
100 Days of Google Dev
100 developer videos over 100 days -- the Google Developers channel is here for you beyond I/O!
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
質とスピード / Quality and Speed
開発合宿
