Mustache Templateの実装を書いた - 時計を壊せ
この記事はPerl Advent Calendar 15日目の記事です。 qiita.com さて 様々からの現実逃避とISUCONに向けたPerlのリハビリでmustache template engineをちまちま自作してたんだけどついにmustache/specなどから作ったテストが全部通ってしまった— かるぱねるら (@karupanerura) December 12, 2023 ということで、ひさしぶりにCPANizeしました。なんか早速bug fixが見つかって早々に0.02です。 metacpan.org 今のPCでは初めてのCPANizeだったようで ~/.pause がなくてちょっと焦った。 なんで？ 人生色々。様々があります。 たとえば、やることに追われたり、悩ましい考え事に苛まれたり、やることに追われたり、やることに追われたり、様々があります。 一方でISUCONも
Linux以外ではDockerでIPv6が扱えないので簡易なTCP Reverse Proxy Serverを書いた - 時計を壊せ
まずは公式ドキュメントをご覧ください。 docs.docker.com IPv6 is only supported on Docker daemons running on Linux hosts. 残念！ Docker Desktop for Macなどでローカル開発をしているときに、ローカルで立ち上げたプロセスからDocker内にあるコンテナに通信したいことは割りとよくあるユースケースだと思う。 こういうときは、基本的には宛先をIPv4のLoopback Addressである127.0.0.1に向けてあげて、 IPv6を使わないようにしてあげるとよい。 localhostを使ってしまうと、名前解決でIPv6のLoopback Addressに名前解決されるケースがあり、そうなればIPv6に対して接続しようとしてしかしIPv4でしかlisten(2)されていないのでコケる。 しかし、世
YAPC::Japan::Online 2022が終わり、その先の未来について - 時計を壊せ
YAPC::Japan::Online 2022が終わりました。 JPA代表あるいはYAPC::Japan::Online 2022の主催としてのコメントはこちらに書きました: blog.yapcjapan.org ここでは、個人的に考えていることを書いてみます。 コミュニティ主催のカンファレンスの価値はなんだったのか なぜ、ぼくたちはカンファレンスに参加(した|していた)んでしょうか？ なぜ、ぼくたちは、どこかの誰かがやってくれる大きなカンファレンスではなく、自分たちのカンファレンスを作っているのでしょうか？ 人それぞれいろいろな答えがあると思いますが、はっきり「これだ」といえる理由がある方はおそらく多くは無いのではないかと思います。ぼくも、なんとなくカンファレンスに参加するのは好きだし、得られるものが多い気がしているだけで、あまりうまく言語化できないです。 自分の場合はどうだろうと、自
コードレビューとPull Request、そしてその承認機能の副作用について考える - 時計を壊せ
用語 レビュアー 対象となるコードをレビューする人のことを指します。 レビュイー レビューを受ける人、つまりレビューする対象のコードを書いた人のことを指します。 tl;dr アプリケーション開発業務におけるコードレビューはコードの正しさや質そして一貫性を保ち、それらと同時にコードに対するチームとしての共有知を作り上げる良いプラクティスだと思います アプリケーション開発チーム内でのコードレビューにおいてPull Requestを使ったレビューのスタイルは一般的ですが、Pull Requestの承認は実際にはほとんど意味がないのではないでしょうか？ ほとんど意味がないにも関わらず、承認の有無によって業務フローが左右されることでそれが権威的に扱われてしまいオーナーシップを希薄化させ、結果的にコードレビューのコストが増加したりそれを行う目的を見失ってしまっていることはないでしょうか？ Pull R
Japan Perl Associaton代表理事に就任します - 時計を壊せ
SEE ALSO: blog.perlassociation.org なぜ平成も終わるこのご時世に？と思う方もいらっしゃると思います。 思いの丈を書いてみます。 昨今のWeb開発のトレンドとしては、動的型付け言語から静的型付け言語へシフトが進んでいます。 また、PaaS/SaaS/FaaSの普及により言語選択よりも技術選択とそのアーキテクチャがより重要になってきており、 *1いちプログラミング言語の重要性というものは、(特に動的型付け言語においては)昔ほど重要ではなくなっているのが実情かと思います。 その中でもPerlは、人気度でいえば比較的低い言語といえるでしょう。 LLと呼ばれる言語の中で最低の人気と言っても間違いではないかもしれません。 ひどいときには、1987年に作られたPerlと1959年に作られたCOBOLが並べて語られることすらあります。*2 それでも、ぼくはPerlが好きで
gitで新しくブランチを切るベストプラクティス - 時計を壊せ
普段から普通にやっている方法です。 git fetch git checkout -b $BRANCH_NAME origin/master git push -u origin $BRANCH_NAMEgit fetchでoriginを最新にして、origin/masterからブランチを切ります。 これで、プロジェクトの最新の状態からbranchを切る事が出来ます。 現在どのbranchに居るかを気にせずとも、branchを切る元を間違える事がないので安心です。 （例えばうっかり関係ないtopic branchから切ってしまう。といったことを気にしなくて良くなります。） また、git push -u origin $BRANCH_NAMEすることにより、 リモートブランチがupstreamとして紐付く為、いちいちgit pull origin $BRANCH_NAMEとかしなくて良くなり
クソコード、あるいは技術的負債 - 時計を壊せ
クソコードについてここ数日で考えたことを書いてみる。 技術的負債まわりのえらいひとたちの議論を眺めてて、技術的負債って言うとなんかプロっぽいけど、クソコードって言ったほうが示したいモノを素直に表してるし分かりやすいきがしてきた。 クソコードを書くなとは思わないけど、クソコードをいつまでも放置するのはやめようって思う。 クソコードは次なるクソコードを生み出すし、バグを隠蔽するし、メンテナンスコスト増大の悪循環のキッカケになるし、新人の教育上良くないので無くて済むならもちろんないほうがいい。 ただ、ギークな人たちを除いて、さらっと60点*1のコードなんて書けない。僕を含め大多数のエンジニアは自分自身が書いたクソコードをリファクタリングして60点以上のコードを目指すための時間が必要になる。 そのうえ、そういうコードを書いてもだいたい時間経過に伴って事情が変わって、60点のコードの挙動を壊さないよ
#chibapm いってきたたたたた - 時計を壊せ
#1も#2も行ったけど#1のレポ牡蠣忘れてたのでついでにかく。 #1 内容は他の方々が既にしっかりまとめてくださってるのでそれに頼らせていただくとして、 Perl初心者な人とある程度がっつり使ってる人の両方がいて、 Perl初心者な人はこういうのやりたい！もっとうまいやりかた教えて！みたいなかんじで、 懇親会でも他の言語と比べてみてどうだとか、突き詰めれば手続き型でちゃんとロジック分割して疎結合に書けなければ他のパラダイムでも酷いコード書きがちだよねとか、 そんな感じの事をゆるふわに語ってた記憶があります。たのしかったー Chiba.pm#1でLTしました。 - arveltの技術メモ Chiba.pm#1に行ってきた。 - ほっけの足あと Chiba.pm #1 に行ってきた ( #chibapm ) - WebService::Blog->new( user => ’hide_o_55
.gitconfigにinclude書くと捗る - 時計を壊せ
2012-08-20一部訂正 githubにdotfile上げてる人は結構多いですが、 github.tokenなど、一部の設定は公開されると困りますね。 そんなときはincludeディレクティブを使うとローカル用の設定を別ファイルに出来るので捗ります。 [include] path = .gitconfig.local [core] editor = emacs pager = lv whitespace=fix,-indent-with-non-tab,trailing-space,cr-at-eol excludesfile = .gitignore こんな感じでやると.gitconfig.localを読み込んでくれるので、 github.tokenなどは.gitconfig.localに書いておくといい感じになって捗ります。 参考： http://stackoverflow.com
Data::Validator::Managerなるものを書いてみた。 - 時計を壊せ
メソッドや関数の引数をバリデーションするときにData::Validatorを使わせて貰っているのですが、 低レベルAPIと高レベルAPIで同じバリデーションルールを適用したい事があって、 そういうときに複数箇所にコピペして使ったりしていると、 低レベルAPIのインターフェースを変えたくなったときにそれに依存している高レベルAPIのバリデーションルールも変える必要があってだるかったり、 そもそもクローンとも言えるオブジェクトが複数ヶ所で静的変数に保持されているのは無駄なのではないか。 あと、そもそも5.10未満では静的変数は使えないので5.8しか使えない環境とかで使いたくなったとき困るのではないか*1とか、そんな事を思ったので、 そんな問題を解消するモジュールを書いてみました。 PrePAN: http://prepan.org/module/429En4oFcf Github: http
Mouse::Util::TypeConstraints等を使って新しい型を定義するときのベストプラクティス - 時計を壊せ
更に追記 MouseX::Typesですが、その後検証してみたかんじ、 要素を「=>」で繋げてしまうと左辺が文字列として認識されてしまうようなので、 要素を「,」で繋げなければいけないようです。 等価だと思っていましたが微妙に違うんですね。 package HogeProject::MouseType; use strict; use warnings; use utf8; use MouseX::Types -declare => [qw/UInt/]; use MouseX::Types::Mouse qw/Int/; subtype UInt, as Int, where { $_ >= 0 }; 1; 追記 id:gfxさんによるとMo[ou]seX::Typesがまさにそんな機能を持っているとの事。知らなかった！ http://search.cpan.org/~gfuji/Mou
正月発火村に行って来た。あるいはXOClockの話。 - 時計を壊せ
さりげなくないけど今年初bloggingです。 あけましておめでとうございます。 正月発火村とは 主に 僕 と @kfly8 が「ハッカソンやりたい！」とか言って適当に集まった面子で、 水上温泉に行ってやってきたhackathonです。 僕はXOClockというものをPerlで開発していました。 XOClockってなに 指定した時刻に指定したJobを実行するJobQueueサーバーです。 例えば、 Facebookでつながってるフレンドをあらかじめ選択して登録しておくと、 2012-02-14 00:00:00にそのフレンドのWallに「Give me chocolate!!」というpostをするWebサービス を実装したいケースなどで役に立つと思います。 ぶっちゃけ、あまり需要は無いと思いますが、 こんなものがあったら便利になるケースもありそうかなーって思って作りました。 バレンタイン支
#isucon に参加してきました。 - 時計を壊せ
うっかり申し込むのを忘れて、定員に達して出れなくなってたので ぬーん（´・ω・｀）ってなってたんですが、 @walf443さんに誘われたので#isuconに参加してきました！ 人数が多い方が有利だとの事だったけど正直足手まといになった気しかしないのは秘密。 #isucon ってなに？ Iikanji Speed Up CONtest の略でISUCONだそうです。 reverse proxy1台、appサーバー2台、DBサーバー1台の構成のWebアプリを いい感じにスピードアップしてあげるコンテストです。 概要: [ http://blog.livedoor.jp/techblog/archives/66528186.html ] ソースコード等: [ https://github.com/tagomoris/isucon ] WHKチームの行動まとめ *1 gitが無いと俺達はソースの変
ApacheBenchを使いたいけどApacheを入れるのがだるかったのでベンチマークツール書いた - 時計を壊せ
なんでこんな事をしたんですか？*1 昨日、コンソール開いたんです。コンソール。 そしたらなんかabコマンド打ってもApacheBench使えないんです。 で、よく見たらなんかApacheが入ってなくて、"command not found: ab"とか書いてあるんです。 もうね、アホかと。馬鹿かと。 お前らな、ApacheBench如きで普段使ってないApache入れるかよ、ボケが。 Apacheだよ、Apache。 なんか沢山モジュールとかも付いてるし。1台何役だよ。おめでてーな。 よーしついでだからこれもこれも使うといいぞー、とか言って色々いれてくるの。もう見てらんない。 お前な、ApacheBenchだけよこしてさっさと消えろと。 サーバーってのはな、もっと殺伐としてるべきなんだよ。 ネットワーク越しのイカれた奴といつ喧嘩が始まってもおかしくない、 落ちるか落ちないか、そんな雰囲気が
Memoize::Class::Constructor作った - 時計を壊せ
GitHubに上げました。 名前のとおりクラスのコンストラクタをメモ化するモジュールです。 前回の反省*1を踏まえてもうちょっとIFやらなんやら煮詰めてみようって言う目論見です。 How to use こんな感じで使います。 use HeavyClass; use Memoize::Class::Constructor qw(HeavyClass); もちろん複数指定することも出来ます。 use HeavyClass; use FatClass; use Memoize::Class::Constructor qw(HeavyClass FatClass); 他にもコンストラクタを明示的に指定したり、 use HeavyClass; use FatClass; use RikishiClass; use Memoize::Class::Constructor ( 'HeavyClass',
1年間を振り返る - 時計を壊せ
何があったっけ オレオレ4半期毎に振り返ってみよう。 1月〜3月 就活もいよいよ説明会や面接が活発になってきた。 スーツに慣れるために塾講師のバイトも始めた。 初めて他教室にヘルプに行ったら前日に食べたカキに当たったのか腹を壊して迷惑かけた事もあったなぁ。 履歴書に貼る写真を撮るのを忘れてギリギリのスケジュールで写真撮ったり、 前日に案内を最終確認したときに初めて履歴書を提出する事に気づいて徹夜で履歴書を書いて*1、初めてのGDは疲れた頭でろくな事も言えず大失敗に終わった。 就活をやっていくなかで何人か友人も出来た。 世の中本当に色々な人が居ると実感した。 次の月に最終面接を受ける事も決まった。 前々から欲しかったベースもついに買った。 Historyのプレンジョンベース。正月三が日のセールで15000円だった。 今更な感じもあった学生自治会*2を引き継いで副会長に就任したり、お金関係のい
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
state変数は初期化のタイミングで例外が発生しても二度と初期化が行われる事は無い - 時計を壊せ
callbackを直列化してみる遊び - 時計を壊せ