XORM - eXtra ORM for GoEasy to UseBy join function design, use less codes to finish DB operations. Rich FeaturesSupport cache, transaction, Optimistic Lock, Multiple Database support, Reverse and etc.
Box | Open Source
Box <3 Open Source At Box, we rely on open source software every day. That's why we give back to the open source community whenever possible, by contributing code to outside projects and sharing projects that we've developed internally. About Our Projects Our open source projects represent the best of Box. They are all hosted on GitHub. We hope you'll find them helpful and we invite you to contrib
Pretty Diff - Gitの差分表示をGitHub調にして見やすく整形
MOONGIFTはオープンソース・ソフトウェアを紹介するブログです。2021年07月16日で更新停止しました これはGitを使っているならぜひ入れておきたいツールです。 GitHubのコード差分表示はとても見やすくて、一旦あれに慣れてしまうとターミナルで出力されるDiffが非常に見づらく感じるようになります。しかしプロジェクトによってはGitHubを使えないというケースもあるでしょう。 そこで使ってみたいのがPretty Diffです。任意のGitリポジトリでGitHub風の差分表示を実現してくれるライブラリです。 Pretty Diffのインストール インストールはnpmを使って行えます。 $ npm install -g pretty-diff これで準備は完了です。 Pretty Diffの使い方 使っているGitリポジトリに移動します。例えば最後のコミットとの比較はこんな感じです。
GitHub の ATOM が CoffeeScript で書かれているのはどうなの? - ワザノバ | wazanova
http://discuss.atom.io/t/why-coffeescript/131 2 comments | 2 points | by noto ■ comment by noto | 約1時間前 先日 GitHub が発表してエディタ ATOM のディスカッション・フォーラムでなぜ CoffeeScript で書かれていて、EcmaScript 6 (ES6) じゃないの? node.js/V8 を利用するデスクトップアプリケーションなら ES6 をすぐに使うほぼ完璧な機会なのに、という問題提起があり、それについて議論があったようです。 前提として、GitHub の JavaScript Styleguide に 新たに JS を書く時は CoffeeScript で書くこと 新たに .js ファイルを追加することは避けること と書かれていて、GitHub の中の人としては
lightline.vim作りました - プラグインの直交性について - プログラムモグモグ
lightline.vimというVimプラグインを作りました。statuslineをなんかかっこよくしてくれるやつです。 https://github.com/itchyny/lightline.vim からインストールできます。 デフォルト (powerlineと同じ配色) wombat solarized landscape どうしてこれを作ったのかということを話すには、vim-powerlineとの出会いまで遡らなくてはなりません。 vim-powerlineとの出会い vim-powerlineとの出会いは約一年前になります。それ以前から気になってはいましたが、フォントにパッチを当てるのが面倒でためらっていました。しかし、重い腰を上げてインストールしてみました。 vim-powerlineがすごい - プログラムモグモグ インストールしてすぐ感じたことは、配色が気に入らないことでし
Scalaにおける細かい最適化のプラクティス - xuwei-k's blog
列挙順自体はとくに意味ありません。あと「どの最適化がどのくらい速くなるのか？」を詳細に計ったことはないですし、「原理的にこうなってるから(ry」というのを説明するに過ぎません。中には「JITで無意味になるようなどうでもいい細かすぎること」も書いてありますし、最適化のトレードオフとして失うものもあるので、そのあたり自己責任でお願いします。本当に最適化が必要とされる場合は、以下のものを無闇に実行するよりまず計測したほうがいいのは、言うまでもありません。*1 1. private[this]をつかえ scalaのvalやvarは、private[this]にしたときのみ、直接のフィールドアクセスになります(それ以外ではメソッド呼び出し)。シングルトンのobjectの場合も同様です。private[this]をつけられる場合はできるだけつけましょう 2. なんでもかんでもListをつかうな 最初の
Coveralls + Perl - naoyaのはてなダイアリー
Coveralls は Github に置いているソースコードのテストカバレッジを git push の度に調査して報告してくれるクラウドサービス。「カバー率100%を維持したいなら継続的インテグレーション (CI) のレポーティングにテストカバレッジも含めちゃえばいいじゃない」という貴族向けのサービスです。いえ、貴族はフィクションです。 こんな感じでモダンなデザインで色々教えてくれる。各行が何回テストされたかみたいな詳細なレポーティングもある。 Travis CI と同じく Github の README なんかに貼り付けるバッジがあります。というか Travis CI なんかのCIツールと連携して Coveralls にレポートを投げるのが前提になっているようです。 つい最近 プロトタイプ開発用のRailsプラグイン「Chanko」を2.0.0にアップデートしました - クックパッド開
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
はてなブログチームの開発フローとGitHub