例えば次のようなテーブルがあったとする。 -- PostgreSQL CREATE TABLE history ( id SERIAL PRIMARY KEY, user_id INTEGER NOT NULL, data TEXT, created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ); -- MySQL CREATE TABLE history ( id INT AUTO_INCREMENT PRIMARY KEY, user_id INT NOT NULL, data TEXT, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ); INSERT INTO history (user_id, data, created_at) VALUES (1, 'First
TypeScriptで関数を書く際に、気をつけていることを記載しました。 BMIを計算する処理を例にして説明いたします。 引数をobject形式にする 引数をobject形式にする事で名前付き引数に近い形式になり、順不同になります。引数の順番に意味が無い関数でも、使用時にどの順番で引数を渡すか迷う事がありません。 const calculateBMI = (p: { height: number; weight: number }) => { // BMIの計算処理 }; calculateBMI({ height: 170, weight: 60 }); calculateBMI({ weight: 60, height: 170 }); 以下は、引数がobjectではありません。この関数だけ見ると特に違和感は無いと思います。しかし、上記に比べると情報量が減ります。特にheight, w
はじめに こんにちは、皆さん。今日は、シェルスクリプトを使った高度な自動化のベストプラクティスとパターンについて解説します。これらは、ちょっとした知識で実行でき、作業を大幅に効率化できるTipsです。シェルスクリプトは、特にUNIX系システムでの自動化タスクに欠かせないツールです。適切に使用すれば、複雑なタスクを効率的に、そして信頼性高く実行できます。 トイルとは、反復的でマニュアルな作業のことを指します。これには、例えば、手動でのシステムのスケーリングや、エラーのトラブルシューティング、ルーティンなメンテナンス作業などが含まれます。トイルを特定し、それを自動化することで、エンジニアはより創造的なタスクやプロジェクトに焦点を合わせることができます。 トイルを判別する方法としては、以下のような基準が挙げられます： 手作業であること 完全な手作業だけでなく、「あるタスクを自動化するためのスクリ
はじめに Java の enum は大変便利で非常多くのシーンで活用されています。例えば区分を表すようなオブジェクトを表現したい際にもよく使われていますね。 Java 14 で正式機能となった switch式にて網羅性検査が行えるようになり、それまで以前ではどうしても抽象メソッド等を活用する必要があった処理についても、switch式を利用する事で簡潔に表現することができるようになりました。 また、Java 17 で正式機能となった sealed classes/interfaces と Java 21 で正式機能になった Record Patterns によって、これまで必要だった区分値のような enum を必ずしも定義しなくて良い場合も出てきました。 この記事では、今まで enum を使っていたコードがこれらの機能によってどのように変わるのかを紹介し、盲目的に enum を定義するのでは
あるレポジトリのサブディレクトリ配下を別のレポジトリへ履歴付きで移行する - $shibayu36->blog; の逆バージョン。 あるレポジトリでずっと開発していたが、やっぱりモノレポの中に入れたいとなって、履歴付きでモノレポの特定のサブディレクトリ配下に移動したい時があった。たとえば https://github.com/shibayu36/go_todo_app の履歴をすべて https://github.com/shibayu36/go-playground のgo_todo_appディレクトリに移したいみたいなケースだ。この時コミット履歴としてはgo-playgroundのgo_todo_app/配下で初めから開発していたかのように移したい。 この解決策として Gitのサブツリーのマージについて - GitHub Docs にあるように、サブツリーマージという方法も取れる。しか
こんにちは、ソーシャル経済メディア「NewsPicks」のむとうです。 先日から『Ghost of Tsushima』の開発者が書いた『ルールズ・オブ・プログラミング』という本をちょっとずつ読み進めていて、プログラミング熱が高まっています。この本は大きな指針を示すだけで具体の話をするものではないのですが、読み物として面白いので私も似たようなことをやってみたくなりました。 何年もこういう仕事をしているとバグが入るパターンというのが見えてきます。そしてだいたいどこに行っても何の仕事でも似たようなことをすることになるのですが、今回の話もその一つです。 構造化テキストを文字列結合で作らない、置換でいじらないというのはこれだけみると何のことか分かりづらいかも知れませんがSaaS Product Team セキュアコーディングの啓蒙 第2回 （SQL インジェクション編）の内容とある面では同じ話です。
ちょっと前の話だけど、社内のISUCON練習会で特定のエンドポイントが重いのをなんとかしようとしていた。このエンドポイントはキャッシュして問題ないので普段はキャッシュから返して1秒おきにリフレッシュしたい。Redisなどに入れてTTLを指定してキャッシュが揮発していたら再生成という手もあるが、これだとTTLが切れた瞬間わずかにリクエストが詰まってしまう。なので、何か別の手立てで定期的にキャッシュをリフレッシュしたい。 Goだとcarlescere/schedulerを使えば簡単にできそう。ただ、この回はPerlでやろうということで進めていた。AnyEventを使えばなんとかなる? と思いつつあんまり慣れていないライブラリを突然使うのはコストが高い。そんなときwatchを使えばいいじゃんということに気付いた。 systemdのunitファイルを以下のような感じで書いて systemctl s
最近の自分が、どんな風に Git を使ってるか、メモを残しておこうかなと思ったので書くことにした。こういうの、以前に書いたかもしれない？と思ったらあった↓ bufferings.hatenablog.com この頃はコマンドだけ使って操作してたけど、最近は JetBrains の IDE から一部操作するようになったのだ！便利！ エイリアス 話に入る前に、使ってるエイリアスを紹介。自分で考えるの苦手なのでこの設定ファイルをコピーしてきて使ってる↓ https://github.com/timcharper/git_osx_installer/blob/master/assets/etc/gitconfig.default#L23-L41 とは言いつつ、最近おもに使ってるのは git l くらいかな l = log --graph --all --pretty=format:'%C(yell
Like many Unix users, I long ago created a ~/bin/ directory in my home directory and added it to my PATH so that I could supplement the wonderfully rich set of basic Unix commands with some conveniences and shell scripts of my own devising. The problem, of course, was the chance of collision. Because my shell script names tended to be short and pithy collections of lowercase characters, just like
Gitって難しい。簡単にぐちゃぐちゃの状態になっちゃうし、失敗を直す方法を知ろうとしたところでまじくそ不可能。Gitのドキュメンテーションって卵とニワトリの問題みたいなところがあって、ハマりから抜け出すために知ってないといけない事柄の名前をあらかじめ知っていないと、どうやって問題を解決したらいいのか検索することすらできないんだよね。 だからここに、私が遭遇したことのあるよろしくない状況から、最終的にどうやって抜け出したかをフツーの日本語で書いていこうと思う。 くっそー、超絶やらかした。お願い、Gitには魔法のタイムマシンがあるって言って？ git reflog # こうすると、Gitでやったことがすべてのブランチに渡って全部見えるよ！ # どのブランチにも HEAD@{index} ってインデックスがあるはずだから # やらかす前のやつを見つけて git reset HEAD@{index
自己紹介 メディアエンジンの岩元(github)と申します。新卒から１０年程度はメーカーの社内SEでCOBOLや色々な言語で書きつつ社内のいろいろなシステムに関わり、色々回り道をしてメディアエンジンにジョインました。なかなかバグを作ることの才能に恵まれているため、修正しやすいコードの書き方を覚えました。 はじめに 多くの方は早期リターンまたはガード節と呼ばれるコーディングテクニックについてご存知だと思います。読みやすいコードを書く人が常に早期リターンを使うというわけではありませんが、必要な箇所では必ず使っています。 基礎的かつベテランでも活用できていない場合もあります。大事な事と思いますので、まだ目にしていない方のために書きました。 早期リターンとは 簡単に言えば return を使うことで if などによるネストを減らすテクニックです。例を見たほうが早いと思います。 早期リターンの例 ユ
パトリック・ミッケンジー（Patrick McKenzie）さんのブログ・エントリ、 “Falsehoods Programmers Believe About Names” の日本語訳です。翻訳の公開を快諾してくださったミッケンジーさんに感謝します。 公開: 2012-02-22 Posted on June 17, 2010 by Patrick きょう、ジョン・グレアム゠カミング（John Graham-Cumming）が、正しくない文字が含まれているといって彼のラスト・ネームを受け付けないコンピュータ・システムへの不満の記事を書いていた。もちろん彼の名前に「正しくない」ところなどない。当人の申し出たものが当人を識別するものとしては相応しいのであって、定義からして名前とはそういうものである。このことにジョンは当然ながらいらだったし、そうなるのもきわめて正当なことだ。定義からすれば事実
軽く各方面とバトりそうなネタなれど。 まず。 ヨーダ記法(ないしNTT記法…って、うちのまわりではいってたんだけど、ググるとあんまりでてこない)ですが。 これは「if等の比較演算において、左辺に定数、右辺に変数を置く」記法です。 とりあえず幾つかネットで拾ってみる。 http://uchidak.net/yoda-notation このようにヨーダ記法とは、予期しない代入を防ぐために産み出された安全側へ倒すための書き方です。 しかしながら、現在はコンパイラがよしなにしてくれるため、あえてヨーダ記法で可読性を失うような書き方をすることをリーダブルコードでは推奨していませんでした。 http://qiita.com/moriturus/items/723eb17873381f94baf8 確かに、ヨーダ記法(1 == hogeのように記述する)は、発見しづらいミスを防ぐのに有用かもしれないが、
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? これは Git (や Subversion などのバージョン管理システム) にコミットする時により良いコミットメッセージを書くための提言です。この提言は特にメッセージの一行目だけを対象とします。せめて最も重要な一行目だけでも良いメッセージを書いて欲しいからです。提言をズバリ一言で表すと 一行目には要求仕様を書け です。 背景 プロジェクトによっていろいろ慣習の差はあるものの、一般的には「コミットメッセージの一行目は変更内容の要約を簡潔に書け」とされます。特に Git は、各コミットメッセージの一行目だけを取り出してそれを一覧表示するなど
できればシェルスクリプトなんて書きたくないんだけど，まだまだ書く機会は多い．シェル芸やワンライナーのような凝ったことではなく，他のひとが使いやすいシェルスクリプトを書くために自分が実践していることをまとめておく． ヘルプメッセージ 書いてるシェルスクリプトが使い捨てではなく何度も使うものである場合は，本体を書き始める前に，そのスクリプトの使い方を表示するusage関数を書いてしまう． これを書いておくと，後々チームへ共有がしやすくなる．とりあえずusage見てくださいと言える．また，あらかじめ書くことで，単なるシェルスクリプトであっても自分の中で動作を整理してから書き始めることができる．関数として書くのは，usageを表示してあげるとよい場面がいくつかあり，使い回すことができるため． 以下のように書く． function usage { cat <<EOF $(basename ${0})
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
