DVC Studio Track experiments and share insights from ML projects
Data Science Version Control System
DVC Studio Track experiments and share insights from ML projects
The problem with Git flow
The problem with Git flow Learn why Git flow complicates the lifecycle and discover an alternative to streamline development. Sometimes, you can have too much of a good thing. That’s certainly true with Git flow, a well-known software development workflow that offers several options but can bog down users. We developed GitLab Flow as the solution to eliminate messy complexity and streamline the de
ソースコードブランチ管理のパターン - Martin Fowler's Bliki (ja)
https://martinfowler.com/articles/branching-patterns.html 最新のソース管理システムには、ソースコードのブランチを簡単に作成できる強力なツールが用意されています。しかし、最終的にはこれらのブランチをマージしなければならず、多くのチームは混み合ったブランチに対処するのに膨大な時間を費やしています。複数の開発者の作業をインテグレーションし、本番リリースまでの道筋を整理することに集中して、チームが効果的にブランチを利用できるようにするためのパターンがいくつかあります。全体的なテーマとしては、ブランチを頻繁にインテグレーションし、最小限の労力で本番環境に展開できる健全なメインラインを作ることに注力すべきだということです。 ベースパターン ソースブランチング ✣ メインライン ✣ 健全なブランチ ✣ インテグレーションパターン メインラインイン
Infrastructure as Codeにおけるテスト駆動開発実践入門(上) - Qiita
Infrastructure as Codeにおけるコード開発にテスト駆動開発を導入する具体的な方法を全二回に分けて説明します。(上)ではIaCとは何か、テスト駆動開発とは何かについて概要を説明します。 Infrastructure as Codeにおけるテスト駆動開発実践入門(下)はこちら はじめに クラウド/コンテナ技術の登場により、ITインフラは頻繁に作っては捨てられる時代になりました。このような時代において、ITインフラの構成管理を従来通り手動で行うことは不可能です。なぜなら次のような事態が起こるからです。 頻繁にITインフラの構成が変わるため、手動で構成管理すると管理コストが膨大になる 管理表の反映し忘れにより、管理表に記載されているITインフラの構成と実際のITインフラの構成が乖離する そこで近年Infrastructure as Code(IaC)という技術が注目を集めていま
汚コードが我慢ならないエンジニアに使ってほしいリファクタリングツールまとめ｜TechClips[テッククリップス]
エンジニアにとって一度書いたソースコードを改善するリファクタリングは欠かせないものです。特に中長期的に修正や拡張が繰り返されるような場合、書いた本人だけでなく、ほかのエンジニアであっても理解できるようにしておくことはとても重要。 万が一怠ってしまうと、それはもう目の当てられない状況になることもあります……。そうならないためにも、常日頃からリファクタリングという作業をルーチンとして取り入れたいところです。そうしたリファクタリングを少しでも効率化できるツールをいくつかご紹介。 もちろん、事前にデバッグしておくことも重要ですので、後半ではデバッグツールもいくつかあわせてご紹介します。日々、コードレビューに時間を取られているような方にとっても作業を円滑にするうえで参考になると思いますので、是非ご一読してみてください。 grunt-plato https://github.com/jsoverson
![汚コードが我慢ならないエンジニアに使ってほしいリファクタリングツールまとめ｜TechClips[テッククリップス]](https://cdn-ak-scissors.b.st-hatena.com/image/square/2d065d176533eb4ce3238953d8860cd2e4c665dd/height=288;version=1;width=512/https%3A%2F%2Fobject-storage.tyo1.conoha.io%2Fv1%2Fnc_261159609ad84809af5afcb9e5f56abb%2Ftechclips%2Fimages%2F260%2Fimage.png)
js13kGames：コードゴルフ型ゲーム開発大会
この記事は “js13kGames: Code golf for game devs” の抄訳です。 13KB。KB なんて最近では雀の涙ほどのデータ量ですが、ゲームの歴史を遡れば先駆者たちはとんでもない制約の中でゲームを作ってきたということに気づくはずです。 一例を挙げると、皆に愛されたアタリ 2600 の RAM は、ほんの 128 バイトしかなく、カセットをさしても 4 KB 増えるだけでした。ことわざにもある通り、制約は創造の母です。そんなゲームのコンペティション、js13kGames の季節がやってきました。これは zip 圧縮して 13,312 バイト以内であることを条件に、ゲームの創造性を競う大会です。 HTML5 ゲーム開発者向けの大会 js13kGames は HTML5 でゲームを作る開発者のための大会で、2012 年より毎年開催されています。作成するゲームのファイルサ
いつ突然会社をやめても問題ないという基準でコードやドキュメントを書くテクニック - $shibayu36->blog;
blog.shibayu36.org 上の記事が思ったより読まれていたので、自分がこの基準を満たせるようにやっているテクニックも箇条書きで書いておく。 PullRequestを作ったら必ず自分でコードレビューをする コードを書いているとき、その一部一部はこれで完璧と思ってるけど、実は全体を見直すと分かりにくかったりする 1日寝てから見直す 1日経つとちょっと忘れて新鮮な気持ちで見れる 1週間後にもう一回見てみる 1週間くらい経つともうだいぶ忘れて、穴が見えてくる 穴があったら別PullRequestで直す もう一度同じところを担当することがあればチャンス。自分でもこれどういうことだっけってググり始めたら基準を満たせていない 自分が全く関わっていない部分のところを触りだしたらかなりチャンス。本当にまっさらな頭で基準を満たすか見れる。他人がやったことだからとか思わずにちゃんとその時に直す やっ
コードを書く際の指針として見返すサイトまとめ - Qiita
お勧めの記事がありましたらコメントなどで教えて頂けると幸いです。 Guidelines プログラマが知るべき97のこと 技術的負債 不慣れなコードベースで短期間に生産性を高めるための7つの方法 何も知らない人を育てるために(新人教育情報キュレーション) 保守開発に開発者として入って困ることのまとめ(実体験) 技術系の名言まとめ++ 真似をする前にバッドプラクティスかどうかを調べてみよう 読まれない名著「人月の神話」を本気で読み込んでみた（まとめ） 技術的負債とどうやって戦うか 楽しいコーディングのための CUPID - SOLID 原則に対するアンチテーゼ エンジニア基礎(新人研修資料) Coding Style モデルやメソッドに名前を付けるときは英語の品詞に気をつけよう 関数名や変数名に使えそうな動詞・名詞・形容詞のメモ Naming -名前付け- DRY原則をもう一度 -コンカレント
コードを引継いでどこから手をつけるか - ワザノバ | wazanova
http://www.se-radio.net/2009/11/episode-148-software-archaeology-with-dave-thomas/ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 他人から引継いだコードを把握するのにどこから着手するかというテーマで、たまたまいくつかのエントリーを見かけました。「コードを読み切れないほど膨大にある。」「前任者、経緯のわかる人がいる/いない。」「ドキュメントがある/ない。」など様々な事情が想定されますが、全部まとめて主な声を拾ってみました。 謙虚な姿勢で臨むこと。そのコードベースがわかりづらいのは、書き方が悪いコードだからかもしれないが、自分がその専門領域の知識がなかったり、ベースにあるアルゴリズムが本当に複雑な場合もありうる。それを、全
コードレビューを円滑に行いたい (#cross2014 のお話) - $shibayu36->blog;
id:antipopさんやid:studio3104さんに機会をもらえて、CROSS 2021に参加させてもらい、はてなでのレビューの話を軽くさせてもらった。はてなからは僕とid:hakobe932さんとで参加した。 http://blog.kentarok.org/entry/2014/01/18/204552 2014/1/17 #cross2014 コードレビューCROSS 〜ぶつかり稽古 2014初場所〜 - Togetter それで、今回参加して他の会社の人のレビューの話も聞いて、あーそれはあるあるとか、そういう問題解決するためにこういうことしてますとか、他の会社ではこういう時どうしているんだろとか、幾つかおもうところがあったので、もう少しレビューのことについて書いてみる。 レビューと関係性問題 レビュアーとレビュイーの関係に関して - 職質アンチパターン コードレビューと関係性
Coverband: production Ruby code coverage - LivingSocial's Technology Blog
Rubyists have long used code coverage to help guide development. While our coverage reports are typically generated from tests, I wanted to see coverage of the production system as it was getting exercised by our users. After discussing with a number of developers and failing in several of my attempts, I built coverband to record production code coverage. Why production code coverage? Dead code is
CodeKata
How do you get to be a great musician? It helps to know the theory, and to understand the mechanics of your instrument. It helps to have talent. But ultimately, greatness comes from practicing; applying the theory over and over again, using feedback to get better every time. How do you get to be an All-Star sports person? Obviously fitness and talent help. But the great athletes spend hours and ho
Square: 普段仕事してる雰囲気でインタビューに臨んでもらう - ワザノバ | wazanova
http://corner.squareup.com/2013/11/culture-fit.htmlSquareが一連のブログでエンジニアのインタビュープロセス、採用基準などについて公開しています。昨日発表されたViewfinderの買収も報道によると、サービスを取り込むというよりはNYに拠点を広げるタレントバイ（talent-buy: 優秀な人材の確保）のようです。買収金額は発表されてませんが、買収先のサービスが不要で人材だけを確保する目的の場合は、人数 x $1M（約1億円）が相場と言われてるので、数億円〜10億円程度の規模でしょうか。 さてインタビューに話しを戻すと、ベイエリアの企業のエンジニアのインタビューは丸1日かかるので、現在勤めてる会社を休まないと面接にいけないという話しはよく聞きますが、Squareも例にもれず、かなり時間をかけているようです。 インタビューは計５時間 「
『リーダブルコード』を他書と読み比べる（その1） - 杉風呂2.0 - A Lifelog -
よい本なので、他書と比較しながら再読していきます。短期集中連載のつもり。 1章 理解しやすいコード ここでは本書の根底となる「すべての原則が生じるテーマ」と「読みやすさの基本定理」について説明がされています。 コードは理解しやすくなければいけない。 コードは他の人が最短時間で理解できるように書かなければいけない。 『C++ スタイルブック (IT Architects’ Archive―CLASSIC MODERN COMPUTING)』の「はじめに」には次のように書かれています。 チームが成果を上げるには、誰もが、他の人の書いたコードを読んで理解できなければならない。 『Code Craft ~エクセレントなコードを書くための実践的技法~』1章「防御的プログラミングの技法」には次のように書かれています。 簡潔性よりも明瞭性を重視してコードを書く 簡潔ではあるのものの混乱を招くおそれのある
1ヶ月後でも読めるソースコードの書き方 - 何気に大変
あなたはコードを書くときに何を重視して書きますか？実行時の速度だったり、拡張のしやすさといったところですか？ 今回は読みやすいコード(=readable code)についてです。 私が考える読みやすいコードとは以下のようなコードです。 関数(メソッド)名が適切に付いている コーディングスタイルが一貫している コメントが少ない では、ひとつずつ例を挙げていきます。 関数(メソッド)名が適切に付いている check_member()は特定のユーザーがメンバーかどうか判定する関数とします。 if (check_member(user)) { ...... }上記のcheck_member()はif文の中で使用していることからbooleanが返ってくるだろうと予想できますが・・・駄目っ！この名前では、どのような時にtrueが返ってくるのかは関数の中身を見ないと分かりません。このように何かを判定する
頑健なJavaプログラムの書き方
日頃より、アレスネットをご愛顧いただきまして誠にありがとうございます。 「ホームページサービス」のサービス提供は2016年1月31日をもちまして終了させていただきました。 これまで長らくご利用いただき、誠にありがとうございました。 今後も、皆様によりよいサービスをご提供させていただけるよう、サービス品質向上に努めて参りますので、何卒、ご理解いただけますようお願 い申し上げます。 ＜アレスネットをご契約のお客様へ＞ 後継サービスとして「userwebサービス」を提供させていただいております。 詳しくは、以下のリンクをご参照ください。 ▼「userwebサービス」のご案内 http://www.ejworks.info/userhp/alles/index.html 今後ともアレスネットをご愛顧いただけますようお願い申し上げます。 株式会社イージェーワークス アレスネット カスタマーサポート
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Learn Contemporary C++ | Concise&Visual Examples
Tabnine AI code assistant | Private, personalized, protected
サバクラ両方で動く JavaScript の大規模開発を行うために
チームのコード品質
