ブログをAstro に移行しました - As a Futurist...
式年遷宮の様な感じですが、数年おきにブログを作り直してます(前回)。今回は Gatsby でデザインした UI をほぼそのままに、フレームワークを Astro に移行しました。静的サイトの作成では Astro の開発者体験が最高に優れているので、2 年間ほぼ塩漬けにしてしまっていた Gatsby のコードを無事に移行できてよかったです。 Astro とは？ Astro は 一言で言うと、Better HTML です。Astro というフォーマットでサイトが記述できるのですが、普通の(素の)HTML も Astro としてそのまま使えます。厳密には違いますが、HTML のスーパーセットみたいな感じです。その HTML の要素群を component としてまとめることで関心を分離できて(この辺は Web Components でも実現できます)、必要に応じてビルド時にロジックも走らせることが
コードが読めるソフトウェア開発者 - As a Futurist...
僕はコードを読むのは得意な方だけど、それが過ぎてコードを書かなくてもシニアソフトウェア開発者になってしまった。実はコードをちゃんと読めるソフトウェア開発者って希少価値が高いのではないか、と思ったので自分がどんな感じでシニアになったのかをまとめてみた。似た様な人の参考になれば幸いだ。 同意。僕は未だ書く方はほとんど機会なく成果もないけど、コードを読み尽くして、負荷試験や本番で挙動を把握し続け、メトリクスでとことん確かめていった結果、Sr. Engineer になれた。 https://t.co/KXtMdEaRr8 — Ryosuke Iwanaga (@riywo) April 16, 2021 コードを書かなくてもシニアソフトウェア開発者になれた 僕は今 Amazon の Sr. Systems Development Engineer という職種で働いている。いわゆるソフトウェア開発職
質の高い技術文書を書く方法 - As a Futurist...
大学や大学院で論文の書き方を鍛え上げた人たちには遠く遠く及ばないが、僕の様なはぐれもの1でも最近は Amazon 社内で文書の質が高いと評価してもらえるまでにはなった。Software Engineer として、コードでのアウトプットはもちろん大事だけど、文書のアウトプット(およびそれによって得られた実際のアウトプット)は同じだけ重要である2。今回は自分が最近どういうところに気をつけて技術文書を書いているのか、ということについて数年後の自分が忘れてないことを確かめられる様にまとめておく。 そもそも文書とは？ 英語だと document。ここで指す(技術)文書とは、人間が読む文体で書かれた技術に関連する情報、といったものだ。具体的に言うと以下の様なものを想定している: 新しいプロジェクトの骨子を説明する資料 会議の叩き台となる 1 枚ペラ 本番環境に変更を加えるにあたっての包括的な情報や具体
フロントエンド初心者がGatsbyでブログを作り直した話 - As a Futurist...
フロントエンド初心者が無事に Hugo のブログを Gatsby で一から作り直すことができた。その振り返り。 歴史 インターネットを小中学生(もはや 25 年以上前)に触り初めた頃に、HTML で文章の構造を作り CSS でデザインする、ということができるのを知って感動したけど、結局自分には何かが合わなくてそれを突き詰めることができなかった。というか、それを知ったが故にテーブルレイアウトとかがどうしても気に入らず、かといって CSS は float が難しすぎて、結局ウェブサイトを作る、という根本的な営みをずっと避けてきてしまった。 時は過ぎ、Wordpress の様なブログエンジンや Hugo の様な仕組みがあったおかげでブログを初めて続けることはできた。13 年前にレンタルサーバに Wordpress を置いて始めたこのブログも 9 年前には VPS での Wordpress 運用に
perlbrewとextlibなアプリのcronとかdaemontools - As a Futurist...
perl は system perl じゃなくて perlbrew で入れて、アプリで必要な CPAN モジュールは全てアプリのディレクトリ下の extlib というディレクトリにインストールする方式は個人的にはいい感じだよなぁと思いつつ、cron とか daemontools がいつもどうやるのが正解なのか分からず困ってた。 またセットアップする機会があったので色々考えた結果、こんな感じなら割とすっきりした感じになった。 env このファイルがキモで、アプリのディレクトリに移動しつつ、いい感じに perl とか PATH とか@INC を設定して、渡されたコマンドを実行してくれる。 # perl -v This is perl, v5.8.8 built for x86_64-linux-thread-multi # ./env perl -v This is perl 5, versi
かっこいいスライドの作り方 #yapcasia 2012編 - As a Futurist...
さて、今回スライド結構がんばって作ってみました。どうよ、これかっこ良くない？？？ https://speakerdeck.com/riywo/ops-tool-made-by-perl-beginner-number-yapcasia-2012 どうやって作ったのか、大したことはないんですが軽く共有しておきます。 と言っても、ぶっちゃけ以下のエントリを丸パクリして Keynote でポチポチ作っただけですが。。。 Slide Design for Developers フォント Yanone – Free Font: Yanone Kaffeesatz こちらを使わせて頂きました。とてもかっこいいです。 配色 Color Trends + Palettes :: COLOURlovers こちらから自分の好みのパターンを幾つか探して、Keynote のパレットに拾っておいてあとはそれをポチ
初めてのオレオレbash補完 - As a Futurist...
さて、ひとつ前のエントリは釣りだったわけですが、本題の bash 補完を初めてやってみました。ちょっとした物だったら割と簡単に書けたので、共有。 目標 自作コマンド(仮にsugyanとします)はこんな感じの I/F だとします。 sugyan subcommand [args] いくつかの subcommand は次にくる引数が限られる 例えばsugyan momocloの後にはkanako renichan shiorin ahrin momoka sugyan listでそういう補完の一覧が色々出せる sugyan list commandで subcommand の一覧 sugyan list momocloでももクロ一覧 一応sugyan listでcommand momocloが返る あとはいつもの bash のままにファイルとかを補完して欲しい 実際叩くと、 $ sugyan
「リーダブルコード」が良書すぎて胃が痛い - As a Futurist...
インフラ系のエンジニアは、あまりリファクタリングとかクラス構造といった視点でコードを読む機会が少なくて、勢い作ったスクリプトやツールはそれはそれはひどいものになりがちです(体験談)。 僕もエンジニアになって以来、まともなコードなんか書いたことなくて、従ってる原則といえば、「グローバル変数は悪」とか「短いことはいいことだ」とか「コメントは書かない方がいい」とか、なんか学生の時にたまたま目にしたよくわからない何かに従ってる程度。 少し大きい規模を書き始めると、昨日の自分と今日の自分で命名規則が全然一貫性なくて、「getHoge()」と「makeFuga()」がおんなじようなことをやってたりしていつも嫌悪感に駆られてました。 ちょうど 1000 行くらいのアプリ書いてたところだったので毎日吐き気をこらえながら「まずは動くものをつくるんだ。全てはそれからだ」と言い聞かせて汚いコードをゲロゲロしてた
オペレーションエンジニアとは何かを理解するために「ウェブオペレーション」を読んで欲しい
最近は、@kazeburo さんの真似をして自分も「オペレーションエンジニア」と名乗ろうかと思ってます。正直最初にオペレーションエンジニアって聞いた時、なんのことだかよくわからなかったんですよね。ちょうどこの言葉を最初に見たのは 1 年前くらいで、その時僕は 2 年目に入ったところで MySQL Conference から帰ったばかりで「おらは DataBase Administrator(DBA)なんだ！」と思ってた頃でした。 それからちょうど 1 年。1 年目の時も DB だけをやってたわけではないですが、この 1 年はより広くより深くいろんなモノを見てきた関係で、自分の仕事は「DBA」だけだとちょっと説明に足りないなぁと思ってたところで、「オペレーションエンジニア」という言葉を思い出しました。そう、僕の仕事は「オペレーションエンジニア」なんです。ひよっこだけど ん、ちょっと待てって？
新人は「サーバ／インフラエンジニア養成読本」読むべきで、僕はツールを開発すべき - As a Futurist...
ふと本屋に寄ったら、SoftwareDesign の特別版で題名の本が出ていましたので、ホイホイと買ってしまいました。内容としては、最近の SD 誌であったインフラ系の特集を抜き出してまとめたものなので、多少古い内容もあるかとは思いますが、雑誌のバックナンバーを買い揃えるのって結構面倒なので、こうしてまとめた形にしてくれると入手しやすくなっていいですね！ 入門 サーバ/インフラエンジニア養成!基礎講座 効率化(効率的サーバ/ネットワーク管理「実践」入門) 達人管理者になるための ssh 活用術 Kickstart で実践!システム管理「完全自動化」大作戦 開発力 サーバエンジニアのための「開発力」養成講座 クラウド活用 サーバ/インフラエンジニアのためのクラウド入門 セキュリティ これだけは知っておきたいセキュリティの常識 ドキュメント作成 現場で役立つ運用管理マニュアルの作り方 内容的に
DNS勉強会＠ゼロスタに行ってきた - As a Futurist...
恒例の行ってきたエントリです。そういえば qpstudy 書き忘れてたけど、あれは勉強会じゃないからいいよね(；・∀・) というわけで、今日は万難を排してゼロスタートコミュニケーションズで開催された「DNS 勉強会」に行ってきました。つぶやきまとめはこちらをご覧ください。途中の@sugyan さんがよくわかりません。 Togetter – 「インフラエンジニア( zaki )による、エンジニアのための「初心者向け DNS 勉強会」 #zsstudy」 DNS ってなんじゃい！ BIND があまりにもよく使われるせいで、「DNS=BIND」的な感じで BIND の設定のはなしとかばっかりが世の中にはびこってるけど、そもそも DNS ってどういう仕組みでどういう登場人物がいるのかという話を、@zaki 社長自ら解説するという豪華な勉強会。最初かなりグダグダな感じ(始まってから「ハッシュタグ今決
GNU Parallelがすごすぎて生きるのがつらい
皆さん今日もたくさんのサーバを相手にされていることかと思いますが、いくつかのサーバにアクセスして 1 秒間の統計情報(例えばvmstat 1 2)を集めてパッと表示したい時ってどうやってますかね？shell script を学びはじめたばっかりの僕はこんな感じで書いてました。 $ for i in host1 host2 host3; do ssh $i "vmstat 1 2 | tail -1"; done 0 0 0 329004 210836 14275360 0 0 0 2424 1410 1828 0 0 100 0 0 0 0 0 3716112 587704 25921684 0 0 0 488 1643 2026 0 0 100 0 0 1 0 0 555440 265560 14015548 0 0 0 4204 1534 2392 1 0 99 0 0 vmstatと
パスワード管理について「安全なWebアプリケーションの作り方」で学んだので実装してみた - As a Futurist...
前回半分くらい読んで積読になってしまっていた「徳丸本」こと「安全な Web アプリケーションの作り方」を週末に読みきりました。本当にいい教科書だと思いますので、脱初心者を目指す人は読んでみると良いと思います。 特に今までぼんやりとしか理解していなかった「パスワード管理」について非常に体系的に分かりやすく説明されていたので、せっかくなので Plack アプリで実装してみました。ソースは gist に貼っておきました。 基本的には徳丸本にあったとおりに実装しています。 パスワードはハッシュをかけた値を DB に保存 但し単純なハッシュ関数だと漏洩したときにクラックされる(=逆方向に解析される) そこで 2 つの対策を組み合わせる salt 値 user_id と固定値を利用して salt 値を作りパスワードに付加してハッシュを取る もし同じパスワードのユーザがいてもハッシュ値は異なる ストレッ
「安全なWebアプリケーションの作り方」を読んでセッションを復習してみた - As a Futurist...
タイトルが長くて略称があれば知りたい感じの「安全な Web アプリケーションの作り方」を暇を見つけて読んでいます。今まであいまいなままだった部分を順を追って説明してくれるので、本当に助かります。Web アプリ作りの初心者は卒業したかなーという人は必ず目を通しておくと良いと思います。 Cookie を用いたセッションについて復習 「HTTP はステートレスで」とかいう話はよく聞きますが、じゃあどうやってセッション管理するのがいいの？って話をよく考えると体系的に聞いたことがなかった！というわけで、この本で文字通り体系的に学び直すことができました。 その中でも、「セッション ID の固定化」という話題はちゃんと分かってなかった部分があったので、こちらのサイトを参考に PSGI なアプリケーションを作ってみました(僕の書いたアプリ自体はその他の脆弱性に溢れていますがｗ)。コードはエントリの最後に。
「出過ぎた杭」を目指してみませんか？ – 新卒エンジニアに向けて - - As a Futurist...
新卒準備カレンダー 2011 春というおもしろい企画がありまして、3 日目は自分が担当させて頂くことになりました。@shibukawa さんの様に抽象的なレベルまで高めて書くほどの経験は残念ながらありませんので、僕ものんべんだらりと自分語りをしたいと思います。 Who are you? DeNA のサーバインフラエンジニア新卒 2 年目(=もうすぐ 3 年目)です。主な言語は Perl とshow slave statusです。プログラムやコンピュータに結構詳しい学生さんでも、インフラって何やってるのかについてはイマイチ伝わらないことが多いのですが、一応説明しておきます。僕は大してコードも書いてませんし、かといってプロジェクトマネージャみたいに人の管理もしていません。僕が相手にしているのはシステムが動いているコンピュータ(=サーバ)そのものです。システムの多くは無数のサーバが通信しあって提
リソースモニタリングツール「CloudForecast」入門 - As a Futurist...
kazeburo さんが開発をされているサーバリソースの可視化ツール「CloudForecast」ですが、個人的に使ってみていてとても使いやすいなと思っています。もっと使ってくれる人が増えるといいなと思い、自重せずに入門エントリを書いてみました。 CloudForecast って何？ そもそも何なの？という話ですが、CloudForecast とはリソースのグラフ作成ツールとして有名な「RRDTool」の薄いラッパーとして作られています。記述言語は Perl ですので、Perl と RRDTool の使い方が大体分かっている人にとっては導入さえしてしまえばかなりかゆいところまで手が届く＝カスタマイズが簡単かつ自由自在なツールだと思います。とりあえずのイントロとしては kazeburo さんの YAPC::Asia 2010 でのこちらのスライドをご覧頂ければと思います。 RRDTool っ
突然のTwitter砲にもなんとか耐えたさくらVPSに感謝する - As a Futurist...
なんか、2/6 の夜に「修士論文の代わりに退学願を提出してきた」が Twitter でばずったらしく、Yahoo 砲よろしく突如としてアクセスが集中しました。下の方にリソースモニタリングのグラフを貼りつけてますが、今までがほぼ 0 に見えてしまうくらいに来てたのでびっくりでした。 まぁ色々コメントつけて頂いたりしてますが、もう2 年も前なんでこのエントリについて今更僕から突っ込むことは無くて、あのエントリはあのエントリとして見て頂ければと思います。ここでは今回そんな突然のアクセス集中にも見事耐えてくれたさくら VPS に感謝しつつ、アクセス集中の状況を鯖管的立場から分析してみましょう。 ちなみに、以前エントリに書いていますがサーバの構成としてはさくら VPS1 台で、CentOS+Apache+mod_fastcgi+PHP-FPM+MySQL5.5(InnoDB)で WordPress
サーバインフラエンジニアについて思うことを『小悪魔女子大生のサーバエンジニア日記』に触発されて書いてみた - As a Futurist...
サーバインフラエンジニアはモテるとの噂が最近絶えないわけですが、そんな僕達注目の書籍『小悪魔女子大生のサーバエンジニア日記』がついに刊行されましたので早速ゲットしてみました。紀伊国屋の店頭取り置きサービスというすばらしいサービスを使わせてもらったのですが、取りに行った時に「書籍の名前はなんでしょうか？」「こ、小悪魔女子大生の・・・」とか言わせんなよ恥ずかしい＞＜ かわいい絵だけど中身はガチ すでに一部界隈では有名になっているこちらのブログの書籍化です。まったくの素人だった女子大生がだんだんと知識を吸収していく様を見ていると、「俺が教えたかった orz」という思いが、、、じゃなくて、すごい細かいところまで内容としては盛り込まれていて、すごいですね。 絵については僕がとやかく言う事ないですが、最後の加藤さんのコメントにもある通り、内容としては小悪魔さんと同じように全くの初心者向けというよりは、
Plack+CatalystでWebアプリ（とCLI）を作ってみる - As a Futurist...
1 年間インフラ修行ばっかりやってて、カタムースとかプラック企業の流れに乗り切れなかったので 一念発起して最近趣味で Plack と Catalyst で Web アプリを書こうとしています。 ただ、アプリのロジックに入る前に、そもそもモジュールの構造をどうしようかと 試行錯誤するだけで数週。。。一旦ここまでのまとめをしておきたいと思いました。 Perl 界隈の方々は本当にエロくてすばらしいなと改めて感じました。 自分のプログラムセンスの無さをひしひしと感じてますが、 今回のアプリの開発を通じて何か CPAN に上げて、僕もエロくなれたらいいなぁ とか密かに思ってたりしてます。 それは MyApp::Web から始まった とりあえずモダン Perl 入門にあるように、以下の様なコマンドで Catalyst 用のモジュールを 一段名前を掘って作りました。 catalyst MyApp::We
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
