Qiita Advent Calendarとは、クリスマスまでの日数をカウントダウンするアドベントカレンダーの習慣にもとづいて毎年12月1日から25日までの期間限定で展開される記事投稿イベントです。毎年、Qiitaとクリスマスを最高に盛り上げる一大イベントとなっております。興味のあるトピックのカレンダーに参加し、この年末を最高に盛り上がる年末にしていきましょう🎉豪華景品がもらえるスポンサーカレンダーもありますので、ぜひ奮ってご参加ください🎄

こんにちは @wasabeef_jp です 最低限、これだけ知っていればAndroidエンジニアとして語れるものを一覧にしています。 随時、このRepositoryを更新していきますので、参考にして下さい。 参照：wasabeef/ListOfAndroidLibraries UI系のライブラリは含めてません Networking Name | Repository | License --- | --- | --- | --- Android Asynchronous Http Client | https://github.com/loopj/android-async-http | Apache License V2 Async Http Client | https://github.com/AsyncHttpClient/async-http-client | Apache Li

運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します⁠。個別にライセンスが設定されている記事等はそのライセンスに従います。

gitblit とは gitblit はオープンソースな git server。今は ticket も管理できるようになっている。 http://gitblit.com/ 1.4.0 から ticketが追加。 1.5.0 から java7で動くようになった。 1.6.1 現在(そろそろ1.7.0がでそうだ) gitblit を使うきっかけ 最初 gitlab(https://about.gitlab.com/) をつかっていたが遅い(gitのプロセス起動してパースしているので。https://gist.github.com/catatsuy/8827731 が詳しい)ので gitblit に乗り換えた。 gitblit はプラグインが groovy でかけるので気に入っている。 gitblit 自体は Java で Wicket をつかって書かれている。git 操作は JGit、検索には

タスク管理のツールとしてオープンソースのRedmineを使っていた。エンジニアだけで使っているうちは特に問題はなかった。エンジニアが10数名、全員でも40人規模の会社なので全員の作業を見える化したいよねという話が上がって全員でRedmineを使い始めることになった。そして何が起きたか。 プロジェクトが乱立した エンジニアであれば「プロジェクト」は単位は大体想像がつくと思う。しかしながらツール上ではその単位でプロジェクトは作られなかった。「正規のプロジェクト」の小規模な機能追加であっても「○○対応プロジェクト」と銘打たれツール上にプロジェクトが作成された。 「〜対応プロジェクト」「〜導入プロジェクト」「〜検討プロジェクト」「〜プロジェクト」・・・どんな言葉にもプロジェクトを付ければ”プロジェクト”にできるんだということは新鮮ではあったし、勉強にもなった。（そもそも”プロジェクト”って何だ？）

#Gitチートシート ##用語 ###リポジトリ バージョン管理システムにおいて，プログラムやファイルを蓄積しておく場所． Gitではローカルリポジトリとリモートリポジトリの二種類のリポジトリを扱える． ###ローカルリポジトリ 現在作業中のリポジトリ．主に自分のPCや開発サーバーなどで作業する場合はローカルリポジトリとなる． また，リモートリポジトリからリポジトリをクローンして，自分のPC上やサーバー上に環境を構築することもできる． ###リモートリポジトリ 外部にあるリポジトリ．リモートリポジトリはローカルリポジトリを通じて作業を行う． 複数人での作業やインターネットに公開する場合に利用できる． ###ワーキングツリー ユーザーが編集したり新しいファイルを作成したりする場所． ###インデックス ワーキングツリーでの編集後，リポジトリへのコミットの前に次のコミットの対象となる状態を保持

TL;DR: グローバルな gitignore に ,/ を追加して、作業用スクリプトを , ディレクトリに入れると便利。 ,/tmp_script.sh で実行できる。 Git リポジトリの中に一時的に使う作業用スクリプトを置いておきたいことがある。自分だけが使うものなのでコミットはしたくないが、いちいち .git/info/exclude に追加して無視させるのも面倒臭い。 今まで自分は、 tmp_script.sh~ や tmp_script.sh.bak など、グローバルな gitignore で無視されるファイル名にしていたが、これは不要なファイルと間違えて消してしまう危険がある。 ignored.tmp_script.sh は分かりやすいぶん長い。 _tmp_script.sh は悪くないが、コミットすべきファイルにもアンダースコアで始まるものがあって紛らわしい。 そこで、作業

Gitによるバージョン管理では、従来のSVNなどよりずっと簡単にブランチングやマージができます。さまざまなブランチ戦略やワークフローが可能であり、以前のシステムに比べるとほとんど全てが改善されたと言えるでしょう。しかしGitを利用する多くの組織はワークフローの問題に直面します。明確な定義がなく複雑で、Issue Tracking Systemと統合されていないからです。そこで、明確に定義された最良の実践的方法としてのGitLab flowを提案したいと思います。issue trackingには feature driven development と feature branches を組み合わせます。 他のバージョン管理システムからGitに移行する際によく耳にすることは、効果的なワークフローの開発が難しいということです。この記事ではGitワークフローとIssue Tracking Sys

開発現場で保守性の高いTDD／BDDを実現するための3つのポイント――テストレベル／網羅性とは：いまさら聞けないTDD/BDD超入門（4）（1/3 ページ） 連載目次 前回の『TDD／BDDにおける「振る舞い』の意味するところとは何なのか」までで述べたような、TDD／BDDを導入するときには、現場で「で、今までやってきた単体テストと結合テストって、どうやってこれに組み込めばいいんだっけ？」「網羅的なテストをどうやって書けばいいんだろうか？」「テストを先に書くだけくらいにしか違いがないのではないだろうか？」などの疑問が出てきます。 今回は、これらの導入時の疑問を解決するようなパターンを紹介します。まずは説明のためにいくつかの言葉の定義を紹介してから、どういったことで保守性の高いTDD／BDDを実現できるかを紹介します。 テストレベルの定義 大まかに言えば、「テストレベル」とはテスト対象の大き

SourceTreeの使い方 | コミットの取り消し方法まとめ（amend, reset, revert, cherry-pick） 高機能Gitクライアントの「SourceTreeソースツリー」（無料）や「Tower」（有償）は導入しやすく機能が豊富なため人気があります。Gitにはコミットやプッシュだけではなくさまざまな機能が存在するので、使いこなすことで効率よく開発を進めていけるでしょう。本記事ではGitを使う上で必須となるcommitコミットの取り消し方法をテーマに、次の4つの機能を解説します。 コミットの修正・やり直し（amend） コミットの取り消し（reset） コミットの打ち消し（revert） 別ブランチからのコミットの取り込み（cherry-pick） 本記事では次の機能をSourceTreeとTowerの両方のソフトウェアの操作方法として解説します。 コミットの修正・や

業務システムの複雑膨大な設計情報を効率的に管理するために、Excelのような汎用ツールではなく、専用のCADツール（システム開発用の設計情報管理ツール）を使おう。そのように主張しているのだが、反応はさまざまだ。もちろんほとんどの技術者が賛同するのだが、所属組織にそれを導入できるかどうかになるとビミョーだったりする。 専用ツールを用いることの効果のひとつが、設計の巧拙がはっきりする点だ。スキルレベルの高い組織であればそれでいいだろうが、そうでない組織は現状維持を望むかもしれない。Excel方眼紙（細かい方眼紙状に設定されたExcelシート）で設計書を書くやり方は蛇蝎のように嫌われているが、それが設計の拙さを見えにくくするための隠れ蓑として役立っていることがある。彼らはExcel方眼紙がもたらす壮大な無駄を棚に上げ、「新たなツールを導入すれば、余計な学習コストがかかる。だいいち、ツールベンダー

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 最近新人研修（プログラミング未経験者・大学で専攻など、ごちゃまぜ）に関わることがありました。 適当なタイミングでEclipseのショートカットキーを教えていたのですが、実演してあげると食いつきがよかったです。 ウケがいい≒新人から需要があるといえそうですし 教えるほうも教わるほうもモチベーションを保ちやすいです。 その点で、ウケるかどうかは大切な視点のひとつだと思います。 なので、ウケのよさランキングの形式で、ショートカットを紹介したいと思います。 環境は、WindowsでPleiadesのやつ（http://mergedoc.sour

前編はこちらです 4：テストに伴うコスト 2014年5月27日 audio 今回のテーマは、テストとTDDのマイナス面です。 テストをやりすぎることがあるか、そして機能的なコードよりテストを重視するチームには問題があるかという点について議論しました。 議事録 Davidが会話の口火を切りました。 「トレードオフについて話すなら、当然そのマイナス面について理解しなければならない。なぜなら、欠点のないトレードオフは存在しないからだ」 このあと彼は続けて、TDDは開発者に何かを強制するわけではないが、ある一定の方向に導くことは確かだと言いました。 それから、最初の問題点として、テストの過剰な実施を取り上げました。 TDDでよく言われるのは、テストに失敗せずして1行のコードも書くべきでないということです。 Davidも当初はこの考え方を合理的だと思っていましたが、そのうち、テストをやり過ぎる傾向が

後編を公開しました（2014/10/8） これは、テスト駆動開発（TDD）とTDDがソフトウェア設計に与える影響についてKent Beck、David Heinemeier Hansson、および著者の3人で行った一連のディスカッションの議事録です。 ディスカッションに至った経緯 あるセンセーショナルな発言とブログ記事が発端となり、お互いの見解と経験について理解を深める目的で、話し合いが持たれました。 この会話のきっかけとなったのは、 DavidがRailsConfで行った基調演説です。 彼はRailsコミュニティでTDDおよびユニットテストへの不満を表明しました。 程なくして、彼はいくつかのブログ記事を公開しましたが、そのうちの最初の記事で “TDDは終わった” と宣言したのです。 それから2～3日後、Davidのその後の記事について私がタイプミスの修正を送ったところ、 Davidは彼の

Help us understand the problem. What is going on with this article? 仕事で Golang を使ってウェブアプリを作ることになりそうなので、どんな構成がいいのか考えてみる。あくまで前提ありきの選択なので、何でもかんでも適用できるわけではない。 JS や静的ファイル部分は今のところ考慮していない。単によく知らないので。 突っ込み大歓迎です。これいいよ！とか教えてください 前提 多機能なフレームワークよりシンプルなフレームワークに色々組み合わせる方法をとりたい。 開発者は数名程度。Golang に精通している開発者が 1 名いる。残りはこれから。 開発者は Django での開発経験が豊富な人が多い 全員ウェブ開発経験はそれなりに積んでいる。 HTML と JSON 両方のパターンが存在するのでテンプレートエンジンは重要。 JS

はじめに 独学でプログラミングを勉強しても実務に通用しにくい理由 - 25歳ニートが35万円で上京を企むブログを読んだときに、僕自身もまた不安定労働から、ある程度「これだったら自分できそうだ」という気持ちで取り組み、独習のつもりで幾つものプログラムを書いたりしていた。だから、ニートからプログラマを目指して、社員として今頑張ってます、というのはすごく仲間意識を持ってしまうし、同じように頑張ってほしいという気持ちはある。 確かに、上の記事の趣旨自体、つまり「独習で学ぶことは、実務上でカバーできない部分がある」という側面があることは認めつつ、しかし、自分自身は独習したことが案外実務上で役に立っている部分もあり、その部分は明確にしたほうが、今後同じように独習して、今度プログラマを目指す人々において役に立つのではないか、と思うので、この記事を書こうと思う。 この記事で扱う「Webアプリケーション開発

自分はテストコードを書くのが嫌いだし、ほとんどの場合テストコードを書くのは効果に見合わないと考えているので偏見は入っていると思う。そのうえで、ゲーム開発とテストコードについて考えてみる事にする。 テストコードを書かない理由 すでにゲーム業界に来て3年半ほど経つが、テストコードを書いている人は見たことがない。 波動拳がちゃんと出るか確認するテストなんてどうやって書くんだ、と言っている人がいたが、確かに想像しにくい。 ゲーム開発でテストコードを書かないのは開発手法が遅れているわけではなく、いくつか合理的な理由があると思う。思いつく理由を書き出してみよう。 ゲームはマルチメディアである ゲームはグラフィックやサウンドなど、数値やテキスト以外の要素を多く含んでいる。これらの複雑な情報をテストの予期結果として準備しておくのは現実的ではない。 また、様々なタイプのコントローラによる操作がリアルタイムに