OrangeSignal CSV – Java CSV ライブラリ
OrangeSignal CSV とは OrangeSignal CSV は CSV 入出力操作を簡易化させる高機能で便利な Java プラットフォーム向けの CSV ライブラリを提供します。 OrangeSignal CSV はパワフルであらゆるシチュエーションにマッチ可能な OSS (オープンソース・ソフトウェア) の CSV ライブラリです。 機能・特徴 区切り文字、囲み文字、エスケープ文字など CSV 形式を詳細に設定可能 (CsvConfig) 区切り文字、囲み文字、エスケープ文字やその他もろもろの CSV 形式に関する設定が可能です。 設定可能な項目は以下の通りです。 区切り文字 囲み文字 (無効化も可) エスケープ文字 (無効化も可) 項目値内の改行置換文字列 NULL 文字列 (大文字・小文字を区別する/しないの指定も可) 項目値前のホワイトスペースを除去 項目値後ろのホワ
ショボいPull Requestを積み重ねて、自分の中でOSS活動の敷居を下げる - not good but great
GitHubのプロフィールページがパッとしない https://github.com/naoyashiga 「Repositories contributed to」がスカスカ GitHubの自分のプロフィールページを見るたびに、なんかパッとしないなあと思っていた。それは「Repositories contributed to」のところがスカスカだったからだ。Contributeをしてプロフィールページを豪華にしたいと思った。 スターが多いリポジトリは難しい できればスターが多いリポジトリにContributeしたい。自分はSwiftを使うことが多く、例えばAlamofireのような人気リポジトリに、プログラミング能力が低い自分がContributeするのは難しい。実際にリポジトリを見ても、何が問題なのか全くわからなかった笑 ショボいPull Requestを送る 「Repositorie
プログラミングにおいて大切な 'スパイクを打つ'とは？
求められるライブ設計力！ 私が勤めているソニックガーデンでは、ライブ設計力というものが求められます。 というのも、お客さんの要望を聞いている間に、ある程度自分の中でデータの構成を考えて、 ミーティング中に実装で必要な情報が揃っているのかを常に考えなければなりません。 ソニックガーデンでは、受託開発で 要件定義をしない ことを実践しています。毎週ミーティングをして、 その週に必要な開発だけを実装します 。そのため、 要望を聞く ↓ 一度会社に戻ってタスクの見積もりを出す ↓ これでよいか顧客先に尋ねる という流れを同じミーティング内でおこない、その場で設計ができていないといけません。 なぜ、この方法でうまくいくのか気になった人は弊社代表倉貫の著書に詳しく書かれていますのでご一読下さい。 「納品」をなくせばうまくいくソフトウェア業界の”常識”を変えるビジネスモデル 私は修行中の身で、技術的にも
GitHubでの”Merge pull request”の弊害 | POSTD
私は GitHub が大好きです。GitHubはオープンソースへの コントリビューション （寄与貢献）を何十倍も容易に、そして楽しいものにしたと思います。ですが、GitHubがPull RequestというwebのUI形式で前面に押し出しているオープンソースの メンテナー のワークフローが、プロジェクト品質とコントリビューションを受けつけるスピードの弊害になるということに気がつきました。そこで、GitHubの Pull Request にある「Merge pull request」ボタンをクリックする前に、少しお話をさせてください。 メンテナーの紹介 ジェーンはそこそこの成功を収めているオープンソースプロジェクトのメンテナーです。彼女は毎週プロジェクトのGitHubリポジトリに上がる新しい Issue を確認し、リクエストに対し速やかにフィードバックを返します。リクエストをすべて実行する時
Makefileの書き方 備忘録 - mnSoft Wiki
2012-02-08 RecentDeleted 2011-09-14 Armadillo-440 OpenJdk6 2010-10-12 Diary 2005.05 2010-07-07 java JNI 備忘録2 2010-03-25 InterWikiName 2009-12-01 Fedora11 CF Install 2009-08-26 Diary 2009.05 2009-08-10 MenuBar 2009-06-26 Diary 2006.11 2009-05-27 Diary 2009.04 2009-04-06 Diary 2009.03 2009-03-02 Diary 2009.02 2009-01-08 Diary 2008.12 2008-12-02 Diary 2008.11 2008-11-04 Diary 2008.10 2008-10-02 Diary
第17回 Padre：Perlで拡張できるコミュニティのための開発環境 | gihyo.jp
Perlを入れたはいいものの ご存じのように、Perlには、簡単なコマンドであれば、いちいちスクリプトファイルを用意しなくてもコマンドライン上で実行できる-eというスイッチが用意されています。 > perl -e 'print "Hello, world!"' また、一行では収まらないような長さのスクリプトでも、使い捨てでよければ、perlコマンドをスクリプトファイルや-eスイッチなしで実行することで、コンソールからスクリプトを入力できるようになります。 > perl print "Hello, world!"; ^D とはいえ、まともにPerlを使おうと思ったら、何らかのテキストエディタが必要になります。Unix系の環境ではviとEmacsの系統がそれぞれ一大勢力を成していますが、Windows環境では、標準添付のメモ帳（notepad）があまりに貧弱なため、たいていの人は自分の好みのエ
プログラマーは自分のコードを疑え - 南極の図書館
若い頃にはよく陥る過ちだと思う。 最近やってしまったので自戒エントリ。 1.テストでバグ発見。 2.共通で使っている様々な計算をするクラスのメソッドから期待した値が戻ってこない。 3.どう考えてもこの（自分以外が作った）メソッドが業務上の例外を考慮してないだろ（履歴を見ると何度も問題があったモンスターメソッドだ）。 4.読み辛いながらも、そのメソッドのバグを探す。 5.どうもバグってないように見えるので、そのメソッドが使っている定数まで疑いだす（どんだけだよ。） 6.よく見たら私が書いたメソッドの呼び出し方が悪かった（結論） この歳になってこれはないよ。。。 でも「今更やってしまった」と実感できたのは良かった。 今後、バグを見つけたら、自分のコードを徹底的に疑う。 以下余談。 テストのコストが高いのがネックだと感じる。 数秒で終わるUTのコードがあればぐるぐるまわすんだけど、テストコードを
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Microsoft Debugging Tools
https://dl.acm.org/citation.cfm?id=1133410
Amazon.co.jp: ジェネレーティブプログラミング: クシシュトフチャルネッキ (著), ウールリシュ W.アイセンアッカー (著), 津田義史 (翻訳): 本