5 Hidden Secrets in Java - DZone
As programming languages grow, it is inevitable that hidden features begin to appear and constructs that were never intended by the founders begin to creep into common usage. Some of these features rear their head as idioms and become accepted parlance in the language, while others become anti-patterns and are relegated to the dark corners of the language community. In this article, we will take a
2019-03-06 ダメな「運用自動化」の3類型 + α /operation-automation-3-bad-model
ssmjp 2019/03での発表資料です。 「運用自動化の基本原則」シリーズの番外編と位置付けています。 # 運用自動化の基本原則シリーズ - 2019-03-06 「運用自動化」とは: https://speakerdeck.com/opelab/20190306-operation-what-automation - 2019-05-24 運用業務の「構造化」: https://speakerdeck.com/opelab/20190524-structured-operation - 2019-04-18 運用自動化の基本原則1 「引継ぎの原則」: https://speakerdeck.com/opelab/20190418-operation-automation-basis-principle-1 - 2019-05-24 運用自動化の基本原則2「平易化の原則」: https
うまくメソッド名を付けるための参考情報 - Qiita
クラス名編をつくりました あるメソッドを定義しようとするとき、そのメソッドを使う人達が名前からどんなことをするか理解できるようにするには、メソッドの内容に応じて適切な情報量の命名が求められます。 この記事では、メソッド名に用いることでどのような情報が提供できるかを見ていきたいと思います。 真偽値を返すメソッド 場所 単語 意味 例
git-flow cheatsheet
About git-flowはgitの拡張であり、Vincent Driessenの提唱するブランチモデルを実現するための高度なリポジトリ操作を提供します。 more ★ ★ ★ このチートシートは基本的な使い方とgit-flowの効果を表します。 ★ ★ ★ Basic tips Git flow は素晴らしいコマンドライン補助と出力を提供します。何が起こるか注意深く読み解いてください。 macOS Clientの Sourcetree は素晴らしいGUIとgit-flowサポートを提供します。 - Git-flow はマージすることをベースとして考えるソリューションです。リベースは行いません。 ★ ★ ★ macOS Homebrew $ brew install git-flow-avh Macports $ port install git-flow-avh Linux $ apt
git による分散作業パターン | GREE Engineering
分散バージョン管理を華麗に扱いたい堀口です。 GREE Advent calendar 2013 の 14 日目として参加させていただきます。 お二人に続き Haskell の話をしようかと思ったのですが、急遽無難な開発の話に変更しました :o Java や C++ には OOP の概念が必要であったように、分散作業の認識が薄いまま git や Mercurial を使うことは長期的に不幸をもたらします。 とあるプロジェクトにて、その一部を副産物のミドルウェアとして抽出すべく、アプリケーションと分離したい 不具合があったので原因を探りたいが、依存関係が複雑すぎるのでコードを読む量を減らしたい テストやレビュー、提案、リファクタの運用を強化したい よそのプロジェクトに迷惑を掛けないように、そこのツールを改良して使いたい。 いままで何気なく「こんなもんだろう」と思って手間をかけていませんでした
初心者こそ、お洒落でvimらしい使い方を学ぼう！
vimをvimらしく使っていますか？ ネットで「vimの使い方」と検索すると、vimにはモードがある事を教えてくれたり、カーソル移動やよく使う編集のためのキーバーインドの一覧をまとめてくれていたりするページが沢山ヒットします。 それらを読んで、実際に使ってみて 「うはぁ、vimって超便利！もう手放せないぜ！」 って、なりましたか？ 私の場合は、正直、「何これ？モード移動とか超面倒クセーーー」って感じでした。 vi 対 Emacs どっちが最強？！ とか、言われているはずなのに、普段、Emacsを使っていた私にとっては、vimの何処が良いのか、さっぱり分かりませんでした。 私は、別にEmacs信奉者であるというわけでは無く、どちらかと言えば、マニアックな操作感を持つvimに常に魅力を感じていて、使えるようになりたいなぁと憧れさえ持っていました。 なので、偶にネットでvimの使い方を検索してみ
普通のpatchコマンドで取り込めるdiffファイルをgitで作成する - kanonji’s diary
まとめ $ git diff --no-prefix HEAD~ > thisis.patch $ patch --dry-run -p0 < thisis.patch $ patch -p0 < thisis.patch git diffに--no-prefixをつける事で、普通のpatchで当てられるパッチファイルを出力できます。この例ではHEADの1個前*1からHEAD*2までのパッチです。 普通のpatchコマンドのほうの知識があまり無くて-p0がいまいちよく分からないんですが、git diff --no-prefixで作成したパッチファイルを当てるには必要みたいです。--dry-runは、実際には当てないけど当てた場合の結果を出力します。なので、まずは--dry-runで確認して、問題が無ければ実際にパッチを当てます。 エントリー書いた後に教えてもらった補足 patch -p1の
GitHubへpull requestする際のベストプラクティス - hnwの日記
みなさん、Git使ってますか？僕はまだメインのVCSがSubversionなのもあって、なかなか慣れません。せっかくGitを使っているのに、ちょっと不便なSubversionくらいの位置づけです。でも、同じような理解度の人って多いんじゃないでしょうか。 一方で、最近はGitHub管理のオープンソースプロジェクトが増えてきました。バグレポートを送るにしてもpull request*1が前提のような空気があり、Git初心者には少し敷居が高い印象があります。 そんな僕も先日初pull requestをしてみたんですが、色々な失敗の積み重ねで残念なpull requestになってしまいました。その反省を元に、本稿ではpull requestする際のベストプラクティスを紹介します。これは「Git Workflow」をベースにコマンド例などを加筆したものです。 概要 pull requestする際は、
GitHub で clone するときは SSH じゃなく HTTP を使ったほうが高速
GitHub には clone するための URL として [HTTP]、[SSH]、[Git Read-Only] の 3 つが用意されている。 いままで、SSH に慣れているという理由だけで [SSH] を利用していたのだけど、「SSH は転送速度が遅い」という問題がある。 SSH だとこんなに遅い… さっき、[SSH] で clone してみたら 20～60 KiB/s 程度の速度しか出なかった。 $ git clone git@github.com:nitoyon/tech.nitoyon.com.git Cloning into 'tech.nitoyon.com'... remote: Counting objects: 8856, done. remote: Compressing objects: 100% (2125/2125), done. remote: Total
git でコミットが消えた場合に簡単に復帰する方法 - Qiita
git 初心者がよくやってしまう失敗だと思います。git のブランチというものを把握すればなんてことのない問題なので、再度失敗しないようにまずは git のブランチについてよく理解することが必要です。 さて、このコミットが消えた、という状態ですが、ようするにコミットがどのブランチにも所属していないため、ログに表示されていない状態となります。 このようなコミットは git reflog コマンドを使えば追うことができます。 $ git reflog 8598194 HEAD@{1}: commit: 4 a734caa HEAD@{2}: commit: 3 5e85532 HEAD@{3}: checkout: moving from caseB to 5e85532 5e85532 HEAD@{4}: checkout: moving from master to caseB 18de5
git diff の使い方がほんの少し理解できた - murankの日記
いままでなんとなく使ってきたけど、ようやく使い方が分かったような気がするのでメモ。 前提知識 インデックスとワーキングツリーが理解できていること HEAD が何か分かっていること git diff ワーキングツリーとインデックスの差分を表示。 git add した後にさらに修正したけど、そういえばどの時点で git add したのかなー、というときに使う？ git add したらすぐにコミットする自分には関係なさそう。 git diff --cached HEAD とインデックスの差分を表示。 git add して、コミットする前に差分を確認したい時に使うんだと思う。 自分は git diff よりもこっちの方をよく使う。 git diff HEAD HEAD とワーキングツリーの差分を表示。 前にコミットした時からどれくらい編集したか確認したい時に使う。 HEAD の部分はコミット(HE
Java やってる人が C# を使うとはまること - ぐるぐる～
ここでは、Java SE 5.0 以降を知っている人が C# 2.0 を使うことになった場合を考える*1 *2。 あと、ライブラリについては触れないことにする*3。 命名規約 まず、命名規約が全然違う。Java ではメソッド名にキャメル形式*4を使うけど、C# では Pascal 形式*5を使い、Java では定数名に大文字アンダーバー区切り*6を使うけど、C# では Pascal 形式を使う。 C# に関する命名規約としては、ここだとかここだとかにあるので、参考にするといい。 間違っても、オブジェクト倶楽部のは参考にしないこと*7。 struct の扱い Java ではユーザ定義型は全て参照型だけど、C# では値型も作成できる。また、標準ライブラリの中に struct で定義されたものもある。 で、何にはまるかというと、struct は class と違い、「値渡し」される*8、つまりコ
grep, awk, sed でバッファしない方法 | TECHSCORE BLOG | TECHSCORE BLOG
こんにちは、TechscoreBlogのログ閲覧が日課になっている河野です。 ログをtailでリアルタイムに見ているときに、grep, awk, sedと組み合わせることがあります。ところが、特にオプションを指定しないと、各コマンドでバッファされてしまうので、ログの表示が遅延することがあります。単にアクセス状況を眺めているだけなら問題ありませんが、チューニングしてる時とか気になりますよね。 そんなわけで、今回はバッファさせない方法を紹介します。 grep : --line-buffered grepでのオプションです。正確にはバッファさせないのではなくて、1行毎に出力するというオプションです。 tail -f logfile | grep --line-buffered -vE '\.(css|js|ico|png|gif|jpe?g)'
型変換のいろいろ - Qiita
JavaScriptは型変換がおもしろいと思うので残しておく JavaScriptの勉強中なので、こうしたほうがいいなどありましたらガンガン言っていただけると喜びます。 基本型から 文字列 と 数値 変換の方法がいくつかあり、それぞれ挙動が違ってきます。 文字列 → 数値 var value = '1234'; // 以下、1234 Number(value); parseInt(value,10); value - 0; +value; value - 0 数値演算のオペランドに文字列値を書くと、暗黙に数値に型変換されます。（+は文字列連結として扱われる） そのため、value - 0 ではnumが暗黙の型変換によって数値になりますが、0を引いても数値は変わらないため型変換だけが行われることになります。 +value また、+演算子を単項演算子で使用すると、正の符号演算になります。正の符
JavaScriptの「&&」「||」について盛大に勘違いをしていた件 - Qiita
論理演算子「&&」「||」について JavaScriptの基本である論理演算子の && || について、 根本的に勘違いをしていたことに最近気付いたので自戒の意味を込めてここに記します。 論理演算子の使い道 1. お馴染みの使い道「条件処理」 JavaScriptには皆さんご存知の通り論理演算子&& ||が存在します。 それぞれ「AND」「OR」という意味で、条件処理の中で使うことが多い演算子です。 // aとbに0または1を足し続ける // aとbのどちらかが最大値に達すると終了 var a = 0, b = 0, max = 50; // 条件式その１ AND while (a < max && b < max) { // 0または1を足す a += Math.round(Math.random()); b += Math.round(Math.random()); console.l
GitHubでFork/cloneしたリポジトリを本家リポジトリに追従する - Qiita
2019/12/11 分かりやすいサイトへのリンクを追加しました hub コマンドの hub fork について追加しました 2013/04/11 興味深い手法があれば随時追加していきます ネットを検索すると、色々な手法が出てきますが、自分としては「WEB+DB PRESS plus 開発ツール徹底攻略」p.71 に載っていた以下の手法がシンプルで良く理解できました。 本家リモート upstream を追加する方法 本家リポジトリの例として、実際にGitHubに存在する練習用リポジトリ git@github.com:DQNEO/Renshu.git を使います あなた (youraccount) が既にForkしているRenshuリポジトリをcloneします。 $ git clone git@github.com:youraccount/Renshu.git Cloning into 'R
Rubyの内部文字コードはUTF-8ではない...だと...？！｜TechRacho by BPS株式会社
こんにちは、hachi8833です。 少し前に、babaさんから「Rubyの内部文字コードはUTF-8じゃないよ」とツッコミがありました。 （追記: 上は会話の途中から切り取りましたのでご了承ください） いきなりの展開にくらくらきましたが、babaさんはさらにたたみかけます。 こうしたことはとっくにご存じの方も多いと思いますが、「Rubyといえば2.0以来UTF-8完全対応なんじゃないの」と勝手に思い込んでた私は脳に掌底を食らったような思いです。ああ、でもこういうことがあるから面白い。 ⚓ プログラミング言語と内部文字コードの関係 まず最初に押さえておきたい点です。プログラミング言語で文字コードに関連する部分は、「文字列」「正規表現」「入出力」「コード中の文字リテラル（""の中など）」「コード中の文字リテラル以外の要素（変数名など）」「ファイル名」などが中心になります。そして文字列に関連し
SpringにおいてJPAのEntityをRESTのJSON返却値としてそのまま用いる際の注意点 - 今日学んだこと
Spring Frameworkを使ってREST APIを作りつつ、その返却値としてJPAのEntityを使いまわそうとしたところエラーに悩まされ。その解決策について、日本語で書かれている情報がなかったので、ここに共有します。 問題が発生する条件 JPAのEntityを返却値として用いている Entityの中でリレーションを定義している が条件となります。 どのような問題が発生するか JPAでリレーションを設定する際、親から子へのリレーションだけでなく、子から親へのリレーションも定義する必要があります。 具体的にいうと /** 親テーブル */ @Entity @Table(name = "parent") public class Parent implements Serializable { @Id String id; String name; @OneToMany(mappedB
コマンドラインツールを書くなら知っておきたい Bash の 予約済み Exit Code - Qiita
上記の表の通り，Exit Code 1, 2, 126〜165, 255 は特別な意味を持ち，スクリプトやプログラム内で exit に指定するパラメータとしては避けるべきである．とりわけ，Exit Code 127 はトラブルシューティングで混乱の元である（"command not found" で終了したのか，プログラム固有のエラーなのか区別できなくなる）．しかしながら，多くのスクリプトが exit 1 を一般的な実行を続行できないエラーとして使っている．Exit Code 1 は Bash の一般的なエラーを含め，とても多くのエラーで発生しうるので，デバッグの時に切り分けが大変になるだろう． Exit Code を体系立てて定義する試みはある（/usr/include/sysexits.h）が，これは C と C++ プログラマー向けである．スクリプトに関しても同様な感じにするのが適切
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
『質問は恥ではないし役に立つ - Qiita』へのコメント
