新しくウェブ系のシステムを開発するときにやったことがいいことを書いておきます。コードを書くスキルとはちょっと別なのでこういうのは経験がないと身につかないけど超重要です。 1. システム構成図を描く どんなシステムがあってどんな流れで処理が進むのかを絵に描く。かっちょいい設計書じゃなくてもいい。手書きの雑なやつでもいい。一個一個の処理に「〇〇君」のような名前を付けていくといい。「JSON書き出し君」みたいな感じ。 2. 誰が何をやるかを明確に タスクを洗い出すだけではなく、誰がどこまでやるかを明確にする。1で描いた絵に担当をアサインしていくと漏れがない。 3. リリース日を決める リリース日を決めずに開発を始めるとパリッとしない。リリース日を決めて、アプリの申請、 QA の予定などを埋めていくと、何日までに開発を終わらせておかなければならないかが逆算的にわかる。間に合わなそうであればリリース
この文章は、2019年4月18日に開催された国際カンファレンス SeleniumConf Tokyo 2019 で行った基調講演の文字起こしを土台に加筆修正したものです。 当日の講演資料は speakerdeck で、動画は YouTube で公開されています。 Clean code that works - How can we go there? - Takuto Wada | SeleniumConf Tokyo 動作するきれいなコード - どうたどり着くか 本日の講演タイトルは「動作するきれいなコード - どうたどり着くか」です。動作するきれいなコードへ至る道の話をさせていただこうと思います。 資料は公開予定で、講演の写真撮影も問題ありません。ツイッター等での実況も大歓迎です。ハッシュタグは #SeConfTokyo です。 改めて自己紹介です。和田卓人（わだたくと）といいまして、
AI & MLLearn about artificial intelligence and machine learning across the GitHub ecosystem and the wider industry. Generative AILearn how to build with generative AI. GitHub CopilotChange how you work with GitHub Copilot. LLMsEverything developers need to know about LLMs. Machine learningMachine learning tips, tricks, and best practices. How AI code generation worksExplore the capabilities and be
（本稿は、QCon London 2016で行った講演の内容に基づいています。スライドとビデオは近日中に掲載予定です） 2014年に開催された最初のGopherConで、私は「 Best Practices in Production Environments（本番環境でのベストプラクティス） 」と題した講演を行いました。 SoundCloud の私たちはGoのアーリーアダプターで、その時点までに既に2年近く、本番環境向けの様々なGoコードを書き、実行し、メンテナンスしていました。そして私たちはいくつかのことを学んだので、その教訓をまとめ、多くの人に伝えたいと思ったのです。 それ以来、私はフルタイムでGoを使う仕事を続けています。SoundCloudではその後の活動やインフラチームで、そして現在は Weaveworks で Weave Scope や Weave Mesh の開発に使ってい
Wiredrive では、私たちはかなりの数のコードレビューを行います。しかし、ここで働き始める前には私はコードレビューなどしたことがありませんでした。今回は、私がコードレビューをする時に何に注目するようにしているかや、私の考え出したベストなコードレビューのやり方をお話したいと思います。 コードレビューとは、簡単に言うと2人以上の開発者で問題を引き起こしそうなコードの修正について話し合うことです。コードレビューをすることのメリットについては多くの記事で語られており、知識を共有できること、コードのクオリティが上がること、開発者が成長できることなどが挙げられています。しかし、レビューを行う上で、どのように進めていくかという具体的なことについてはあまり多く語られてないように私は思いました。 レビューで何に注目するか アーキテクチャ/デザイン 単一責任原則 : 1つのクラスは変更する理由が2つ以上
About the content This content has been published here with the express permission of the author. Carthage is a new dependency manager for Objective-C and Swift projects, intended to be the simplest way to add frameworks to a Cocoa application. Carthage works by delegating tasks to Xcode and Git, minimizing new concepts as much as possible, so you can continue to use the tools you’re already famil
海外事業向けのiOSアプリケーション開発を担当している西山(@yuseinishiyama)です。クックパッドは現在、海外複数カ国に向けてサービスを展開しています。 主にObjective-Cで記述されたアプリケーションを全面的にSwiftに書き換える機会があったので、その際に得た知見や書き換えるに至った動機を共有します。 書き換えに至るまでの経緯 この項では、書き換えに至るまでの経緯について説明します。 Objective-C期 アプリケーションの開発は2014年7月頃にスタートしました。Swiftの発表直後でしたが、時期尚早ということもあり、Objective-Cで実装することになりました。 Objective-C、Swift混在期 2014年10月頃から、Swiftへの段階的な移行のために、新規のコードをSwiftで書くようになりました。Swiftの記述力や、ヘッダと実装を行き来しな
10 Years of Git: An Interview with Git Creator Linus Torvalds | Linux.com gitの10週年を記念して、リーナス・トーバルズがインタビューに答えている。以下はその翻訳である。 なぜGitを作ったのか？ トーバルズ：俺はソース管理ツールなんて作りたくなかったし、コンピューターの業界において最も興味がないものだと見なしていた（データベースは別だが）。それにソース管理ツールなんてどれも嫌いだった。しかし、BitKeeperがやってきてからというもの、ソース管理に対する見方が変わったね。BitKeeperは大抵のことを正しく行っていた。レポジトリのローカルコピーがあることと、分散マージはでかかった。分散ソース管理の何がいいかというと、ソース管理ツールの問題を吹っ飛ばせることだ。「誰が変更を行えるか」といった政治問題があるが、B
（訳注：この記事は本家OKFn.org記事の日本語訳です） データのために「バージョン管理」を行う能力は重要な関心事です。様々な選択肢がありますが、最も魅力的なもののひとつは、Git やMercurial のように、コード用の既存ツールを再利用することです。この投稿では、私たちが暫くの間使用してとても効果的だということが分かったツールを利用する、データの格納とバージョン管理のための単純な「データ・パターン」について記述しています。 序章 行われた変更を格納し、それを他の人と共有する、データのバージョンとリビジョンを管理する能力、とりわけ分散的な手法は（オープン）データ・コミュニティにとって大きな便益となるでしょう。私はその理由を以前（こちらの初期の記事を参照）議論しましたが要約すると： 効率的な分散型の共同作業が可能です。私のデータセットを取り出し、変更し、それを再び私と（同時に他の人とも
連載 "Android Studio最速入門〜効率的にコーディングするための使い方" における "第32回 バージョン管理─Mercurial連携の使い方" での Mercurial 連携に関する説明で、気になる点があったので、まとめておこうと思います（筆者の方には報告済み）。 ある程度 Mercurial を使い込んでいる人であれば、多分言うまでもない話かもしれませんが、Git と併用しているような人や、Mercurial 初学者の誤解を防ぐことができれば幸いです。 あちらの記事の読者が、こちらのエントリに辿りつけるのかは、微妙なところではありますが、まぁ、そこはネット（＋検索）の力を信じることにしましょう（笑）。 リポジトリを最新の状態に保つ 1ページ目の「リポジトリを最新の状態に保つ」での: つまり，hg pullはGitでいうgit fetch相当なので，git pullに相当する
これまでも サービスAPI の更新や、それに伴う UI の変更など、小刻みな機能向上が図られていましたが、昨年11月、GitHub の ヘッダ、フッタが新しくなった のを皮切りに、12月には Gist のリニューアル と GitHub トップページのリニューアル が立て続けに行われました。 また今年1月には、ユーザー数が、アカウントベースで300万人を超えた そうです。 小さくかつ素早く、不断のサービス向上を図る姿勢が、ここまでユーザーを惹き付けた理由なのでしょう。 一方、公式ブログ を追いかけていくと、単に Git のリポジトリ・サーバーとして便利で使い易くする以上に、「自然に人が集まる魅力的なコミュニティ」を目指し、「誰もが気軽に参加できるオープンソース・コミュニティを創る」という意気込みのようなものを感じました。 人が集まれば、それだけビジネスの機会も増えるというワケです。 そこで今
ここ暫く、Twitter や ML 等で、Mercurial の『ブランチ』に関する質問 (特に Git の『ブランチ』との対比) に答える機会が度々あったので、Mercurial における『ブランチ』の概念に関してまとめてみた。 実のところ、SCMBootCamp in Nagoya #1 での、稲田氏 (id:methane) の基調講演資料における Mercurial のブランチに関する説明 (30ページ目) を見て: 別途口頭での説明が無いと、初学者や他のツールからの移行者にとっては、誤解を招きやすいのではなかろうか？ と思ったのが、このエントリを書く元々の動機だったのだけれど、書き上げるのにかれこれ３ヶ月以上を要してしまったというのは、反省することしきり。 っつーか、ここ暫くは本家に (議論の叩き台としてリジェクト覚悟で) パッチ提案したりと、色々アレだったんで、その辺は勘弁して
今回は Atlassian の開発者である Charles O’Farrell によるゲストブログです。チームが DVCS として Git を選択する理由について説明します。Charles はコーディングをほとんど DVCS 上で行い、また ClearCase から Git へユーザーを移行させる作業を行ってきました。 前回の記事では、分散バージョン管理システムとしてチームがなぜ Mercurial を選択するのかについて考えてみました。今回は、分散バージョン管理システム (DVCS) として なぜ Git が有力な選択肢であるのかについて考えてみましょう。 1970 年の黎明期から、ギークたちはどちらが善でどちらが悪かという血なまぐさい論争を長い間行ってきました。それが Vim と Emacs との間の戦いです。最近では、それとは別のツールセットについて、ギークたちは本来の仕事そっちのけ
ここで見たように、Git は、Subversion ユーザーにその CLI に早く慣れてもらうようにするということをあまり考慮していません。 新しいコマンドを入力するために指を再度トレーニングすることによりこの問題を回避することはできますが、それでもシステムを移行する上での障害の一つになるでしょう。その上、Subversion ユーザーにとってフレンドリーで、かつ、強力で美しいインターフェースをもった Mercurial があるので、Git がなくても問題はありません。 履歴が安全な Mercurial Mercurial の哲学は、 “履歴は永久的で神聖である” ということです。Mercurial のコアには、履歴を変更できるコマンドがたった一つだけあります。hg rollback です。このコマンドは直前のプルやコミットを “取り消し” ますが、それより前のものには一切触れません。 G
php, 雑記いつもなら寝ている時間なのだけれど、なぜか睡魔がやってこないので過去の思い出をまとめてみる。去年の2月ごろ、新規案件のウェブサービスに開発メンバーとしてアサインされた。作るべきものが大量にあったため、4チーム（工期中多少増減したが）に分けてドメインごとに作業分担をした。そのうち、ウェブアプリケーション本体（フロント、API、マネージツール）を担当するチームのサブリーダーが自分の役割だった。そのプロジェクトは去年の末に一旦の区切りを迎え、自分はそこで退職し、新たな環境に身を置くことにした。それから丸4ヶ月経って、自分が書いたコードと新しい環境で書かれていたコードを見比べて、思うところが多々ある。それらを文章としてまとめたいと思う。 失敗したこと簡単な骨組みを作ったあと、デプロイの仕組みを作った。php には phar という仕組みがある。これは jar/war のようにウェブサ
By Jon Saints - 29 Jan 2012 I recently read 3 UI books Design of Everyday Things About Face Don’t Make Me Think. The books did make me think. A lot. A lot about a tool I use everyday… git http://git-scm.com. Git is sweet tool. But, the UI could use some love. The UI can be confusing and inconsistent for newbies. In fact, even after three years of using git, there are commands I still find confusin
http://www.nishiohirokazu.org/tmp/git02.pdf あまりに激しく突っ込まれたので「ちょ、ちょっとまって、続きはまた今度で」とお願いして逃げ帰ってきました。 「リポジトリって何」「変更履歴を溜めておく場所」 「これ書き換えるのはどこ」「<name>のところ」「じゃあ斜体にするか色変えるかいっそ日本語にしなきゃ。かっこごと灰色とかにしないとかっこを入力しちゃうよ」 「コマンドの部分を箱で囲むなり書体を変えるなりプロンプトつけるなりが必要」 「コミットをするって何？」「変更履歴をリポジトリに入れること」 「なんで『最初の』コミットなの？最後のコミットはあるの？」 「コメントでの解説の色を変えろよ」 「『.gitにできる』ってどこ？急に思いついて作っていいの？いつもhomeにいるとは限らないでしょ」「いまいるディレクトリの中。思いついて作っていいよ」「2回 g
This entry was posted by Jun Mukai on Wednesday, 22 June, 2011 git commitにある–amendというフラグをご存知だろうか。 gitでは、commitは手元のレポジトリに保存される。多人数で開発するときの中央レポジトリに反映させるには、commitしたものをpushする必要がある。……で、大抵の多人数で開発するプロジェクトの場合、commitした変更を(gerritとかの手段によって)レビューしたりしつつ、すべてが整ってから、pushするというのが一般的な流れかと思う。 だけど人間というのはうかつなことをするものだから、commitした直後に下らない間違いを犯しがちなわけだ。例えば、編集したのにChangeLogを追加してないとか。ファイル足したのにビルドファイルの変更を加え忘れたとか。そういうやつ。そういうしょうもない
John Wiegleyさんの "Git from the bottom up" を翻訳しました。 元PDFはこちらからダウンロードできます： http://newartisans.com/2008/04/git-from-the-bottom-up/ 元記事のライセンスがクリエイティブコモンズのBY-SAであったため、この翻訳もBY-SAとなります。 ライセンスを守って自由にご利用ください。（詳しくは記事内の最初にも書いてあります） 翻訳ミスの指摘や改善の提案等があればブログコメントやTwitter(@oshow)などで遠慮なくどうぞ。 Git をボトムアップから理解する Wed, 2 Dec 2009 by John Wiegley 私が Git を理解しようと調査した時、高級なコマンドの視点から眺めるよりボトムアップ式に理解することが役立った。そしてボトムアップ視点で見る Git が
Git のコマンド体系は全く歴史に学ばず後世に禍根を残す酷いデザインだが、どういうわけか内部構造は大変素晴らしい。特にファイル構造を一旦キーバリュー式データストアに保存するというのは是非参考にしたいアイデアなので調べてみました。 Git 内部データストアの基本機能は、ファイル名を使わず中身だけを保存する事です。ファイル名が無くて後からどうやって保存した中身を取り出すかというと、保存時に SHA-1 という文字列が発行されるのでそれを鍵に取り出します。それでは試しにやってみます。まず準備として新しい Git レポジトリを作ります。 $ mkdir test $ cd test $ git init Initialized empty Git repository in /Users/takashi/tmp/test/.git/ blob 次に、適当な文字列を保存します。 $ echo '適当
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く