コードを書く際の指針として見返すサイトまとめ - Qiita
お勧めの記事がありましたらコメントなどで教えて頂けると幸いです。 Guidelines プログラマが知るべき97のこと 技術的負債 不慣れなコードベースで短期間に生産性を高めるための7つの方法 何も知らない人を育てるために(新人教育情報キュレーション) 保守開発に開発者として入って困ることのまとめ(実体験) 技術系の名言まとめ++ 真似をする前にバッドプラクティスかどうかを調べてみよう 読まれない名著「人月の神話」を本気で読み込んでみた（まとめ） 技術的負債とどうやって戦うか 楽しいコーディングのための CUPID - SOLID 原則に対するアンチテーゼ エンジニア基礎(新人研修資料) Coding Style モデルやメソッドに名前を付けるときは英語の品詞に気をつけよう 関数名や変数名に使えそうな動詞・名詞・形容詞のメモ Naming -名前付け- DRY原則をもう一度 -コンカレント
prchecklist でリリース Pull Request のチェックフローをスムーズに行う - 詩と創作・思索のひろば
背景 GitHub を使った開発では、 master ブランチがいつでも本番に出せる状態として、 master から切った develop ブランチを開発のベースとし、 各フィーチャは develop から切って develop にマージし、 リリースのタイミングで develop を master にマージ、リリース ……という流れを pull request ベースで行うのがよくあるパターンのひとつだと思います。リリースの際、ステージングや QA という名前のついた本番前環境でそれぞれの機能が正しく動いているか確認するのもよくあるフローです。 このチェックを pull request 本文のチェックボックスを使って行おう、というアイデアを実装したのが git-pr-release で、もともと id:hitode909 がチーム向けにこしらえたものをパクった汎用化したものでした。この仕
JSON Schema 中心設計 - FlowType から RAML まで - - Qiita
はじめに Web サービスの運用を続けていくと，依存関係が徐々に複雑になっていきます．そしてメンテナンスするものが増えた結果，それらが相互に乖離していく，といったことが起こりがちです． そこで今回は，JSON Schema のみをメンテナンスしていくことで，動的チェック (バリデーション)，静的チェック (FlowType)，API ドキュメント生成，スタブ作成といった様々な恩恵を享受し，品質と保守性を同時に向上させるアプローチについて書いていきます．この JSON Schema を中心に据えたエコシステムを，JSON Schema 中心設計と呼ぶことにします． JSON Schema の仕様については割愛しますので，必要な方は こちら をご覧下さい．また，本記事では JavaScript での事例を紹介しますが，他の言語でも同様の適用ができるかと思います． アプローチ 本記事では，以下の
物理的にアメリカのオフィスを作った話 – DeployGate
こんにちは！Software Engineerの井上恭輔( @kyoro353 )です。今日はDeployGateの米国オフィスを物理的に作った話をご紹介したいと思います。 DeployGateは2016年3月に米国法人を登記し、海外のお客様向けの各種サポートを提供しています。しかし、実は今までリモートベースの活動がメインで自分たちのオフィスを持っていませんでした。 おかげさまで三期目を迎えた今年は、米国やベトナムを始め海外での利用事例が増えていることもあり、米国にも固定オフィスを作るか！という話になりました。が、私たちは小さなスタートアップ。オシャレなオフィスを作りたいけど、丸投げで依頼するお金も無いし、何より面白く無い… …そうだ、DIYの聖地アメリカだし、自分たちで施工してしまおう！！ という考えに至った私は「大抵のプログラミングはできるのだから、きっとググれば家くらい作れるだろう」
「技術をアウトプットするところに技術は集まる」ソウゾウ エキスパートチームの役割 | メルカリエンジニアリング
ソウゾウのエキスパートチーム所属の@mhidakaです。今回はソウゾウのエキスパートチームが、どんな活動をしているのか紹介します。 エキスパートチームについて ソウゾウでは「技術をアウトプットするところに技術は集まる」という思いから、 稼働の50%以上を技術コミュニティへの貢献や技術の普及に取り組むエキスパートチームが存在します。 私以外に@tenntennが居て、ふたりのミッションにはコミュニティへの貢献も含まれています。 現在、チームは二人で構成されており、メンバーごとに担当する技術分野が違います。 Go/GCPであればGo Conferenceやgolang.tokyoなどを運営している@tenntenn、 AndroidであればDroidKaigiや技術書典などを運営する@mhidakaという役割分担をしています。 エキスパートチームは次のような目的を持って活動をしています。 社内
テストなんか書かなくて良い 僕の考えるサービス開発の肝 - mosa_siru’s blog
世の中は一周まわってエンジニアリングの手法に溢れている。 テストを書け、ドキュメントを書いて冗長化しろ、コミットはわかりやすく、コーディング規約が、安定性が─── でも、それって本質なんだろうか？ 新規サービスを作る際に肝だと思っていることをまとめてみた。 おことわり 以下は少人数で"普通"のアプリやWebサービスを自社で新規開発するときのことを想定しています。大人数で重厚なソシャゲを作るとか、ガチガチの金融系サービスを作るとか、コンシューマーゲーム開発とか、個人で好きなものを作るとか、受託とかは全く想定していません。 基本的に一通り現場をこなした中級以上のエンジニア向けに書いています。 アンチテーゼとして、ややキツめに断定する箇所が多いです、こういう意見もあるんだな程度に受け止めてください。 所属する団体の意見とかは一切関係ありません。 目次 おことわり 目次 ユーザーのことだけ考える
現役エンジニアがお勧めする 絶対に使うべきWebサービス7選
GEEKJOB主催の勉強会（2017/07/28開催） の資料です。 オンラインでもオフラインでもプログラミングの学習ができる https://learn.geekjob.jp/
HTMLスクレイピングやファイルでのバッチ連携を不要に、「API管理ツール」でWebへRESTful APIを公開。ドキュメントもSwagger記述も自動生成［PR］
HTMLスクレイピングやファイルでのバッチ連携を不要に、「API管理ツール」でWebへRESTful APIを公開。ドキュメントもSwagger記述も自動生成［PR］ WebサイトやWebサービス上の情報を取得し加工したい、あるいは、別の情報と組み合わせるために情報を取得して再利用したい、というとき、そのWebサイトにデータを取得できるAPIが用意されていれば便利ですが、現在のところ、現実にそういうAPIが整備されているケースは滅多にありません。 そのため、WebサイトからHTMLを取得して解析することでデータを取得する、いわゆる「HTMLスクレイピング」を用いるケースも増えてきています。しかしIDとパスワードを第三者に渡してのスクレイピングは、Webサイトやサービス提供者として、セキュリティやサーバへの負担からも避けたいところでしょう。 社内の業務アプリケーションでも同様です。 自社のカ
モデル設計を適当にやるとどうなるのか
2017年7月24日に行われた「技術的負債ナイト」（https://speee.connpass.com/event/60381/）の登壇資料です。 プログラミングにおいて、どういうコメントをどういう風に書いていけば良いのか、またどのようなタイミングと考え方で書けば良いのかについて述べていきます。
MVP（Minimum Viable Product）とは？実践するメリットと検証方法
Interaction Design Foundationはグローバルにデザインレベルの向上を目指す、デンマーク発の非営利団体です。 MVP（実用最小限の製品： minimum viable product）という考え方が広まったのは少し前のことです。MVPはFrank Robinson氏によって定義され、起業家であり学者のSteve Blank氏と、リーンスタートアップ（Lean Startup）を提唱したEric Ries氏という２人のプロダクトデザインの権威によって有名になりました。 MVPとは？ 簡単に定義すると、MVPとは、製品を提供する上で必要最小限の機能のみをもつ、もっともシンプルな製品です。しかし一般的には、「顧客価値があり、利益を生み出せる最小限のもの」と考えられています。 MVP戦略においては、価値基準を理解することが決定的に重要です。たとえば、車輪は車輪だけではユーザ
システム開発が失敗する理由 | 株式会社アクシア
システム開発の世界では”デスマーチ”という言葉がよく使われ、世のプログラマー達が自分達のプロジェクトのデスマーチ自慢をするという光景もよく見かけます。それだけシステム開発のプロジェクトは炎上することが多いということであり、システム開発の成功率は３割りくらいとも言われています。 成功率は31.1％ – 第2回 プロジェクト実態調査（対象800社） プロジェクトが失敗するからには何か理由があるわけでして、端的に誰が悪いかというと「顧客が悪い」か「開発会社が悪い」か「その両方」ということになります。 システム開発の業界というのはその構造自体に問題を抱えていると言わざるをえない部分がありまして、多重下請け構造で客先常駐なんかやっていたらそんなの失敗事例が量産されても当然だよなとなってしまうわけです。 そういう意味では、システム開発の実に７割にも及ぶプロジェクトが失敗している要因としては「開発会社が
マネージャーと開発者が安心してアプリ開発を続けるための開発ルール - Qiita
@eaglesakura です。 皆さん、進捗どうですか？ お仕事の規模が大きくなれば、参加人数が増えていくでしょう。 参加人数が増えれば、様々な宗教観の人がプロジェクトに参加するでしょう。 お一人様プロジェクトを中心にやっていた人もいれば、大規模案件のソルジャーとしてキャリアを積み上げてきた人もいます。彼らのスキルレベルもまちまちです。 私が参加している（そしてプログラマーに対して強い権限のある立場である）プロジェクトでは、次のようなルールをベースに適用しています。 これはなるべくプログラマーの負担をかけずに管理側（プロジェクトマネージャー＝PM）が開発管理を行える（進捗がブラックボックス化しない）ことを目的とした開発ルールです。 前提ルール ソースコード管理はgit/githubを利用する 1コミット（1ブランチ）に対して、複数Issueを処理しない githubはリポジトリ管理（作成
Shows
AI is suddenly everywhere. Do you need to go and get a shiny machine learning degree to remain competitive? John Maeda says not to worry. He’ll show you how to cook delicious dishes into your coding repertoire with his new show - Mr. Maeda’s Cozy AI Kitchen. Find out how you can use GitHub Copilot, an add-on that is powered by AI, to get helpful suggestions when writing code or documentation. This
コードレビューのクオリティとスピード，とくにスピードについて，それとコミュニケーションについて - hitode909の日記
ソフトウェアを作るときにクオリティとスピードのバランスをとりたくて，どちらかに偏ってはいけなく，どちらもキープしないといけない．すごく雑に*1とらえると， クオリティ→正しく動き，不具合がないほうがよい スピード→(計算時間ではなく)早く作れるほうがよい ということになる． コードレビューでは，不具合を見つけて直してもらったり，動きはしてもコードの可読性に問題があって直してもらったりと，クオリティに目を向けられがちだと思う． ところで，コードレビューとスピードの関わりについて考えてみる．スピードのためにできることはいくつかあり， 早く読み始める→他のことやってても手を止めて読み始めたり，1日のうち決まった時間にレビュータイムを設けたり 速く読む→これはコツとかある*2けど精読しないといけないので難しい 不具合を見逃さない→リリース後とか，リリース直前に正しく動かないことが分かったら大きな手
だんだん開発スピードが遅くなっていくのをどうやってとめたら良かったんだろう？ - Mitsuyuki.Shiiba
先日、モブプロをやってきた。その中で、モブプロとは別で、いくつか感じたことがあって、今日はその中のひとつを思い浮かんだままにメモ。 bufferings.hatenablog.com 要件を満たすプロダクトをより早く出す モブプロでTDDしながら、要件を満たすプロダクトをより早く出すことに集中してみた。例えば、第２ラウンドのお題はTDDBCなどでお馴染みの「自販機」。 「100円を入れてボタンを押すとコーラが1本買えること」 最初に「100円を入れてボタンを押すとコーラが1本買えること」と言われ。 assertThat(get(100), is("コーラ")); みたいなテストを書いて。 String get(int money) { return "コーラ"; } みたいな実装を書いた。爆速！ 「200円を入れてボタンを押すとオレンジジュースが1本買えること」 次に「200円を入れてボタ
オーバーエンジニアリングの正体とその向き合い方 | POSTD
(編注：2020/08/18、いただいたフィードバックをもとに記事を修正いたしました。) 問題は細部（あるいはその欠如）にあり。 議論とは、ソフトウェア開発の基本的な構成要素であり、スケーラビリティを向上させるためには避けられない摩擦であると言えます。議論を通して私たちは出来上がるものの品質に影響を与え得るような問題を早い段階で浮かび上がらせることができるのです。その1つがオーバーエンジニアリングの問題です。 ウィキペディアによると、オーバーエンジニアリングとは下記のとおりです。 十分な 安全率 や十分な機能の確保のためか、あるいはデザイン上の誤りのどちらかの理由から、アプリケーションが必要とする以上に強固で複雑なプロダクトがデザインされてしまうこと。 また、ウィキペディアには、オーバーエンジニアリングが好ましい場合として、さらに、このようなことも書いてあります。 ある特定の基準の下で安全
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
システムリニューアルと サーバーサイドKotlin
グローバルなエンジニアを目指す為の入門的な話
webhint, the hinting engine for web best practices
技術的負債と向き合う
