小学生男子向けオススメ書籍 | 外道父の匠
息子が小学校を卒業したので、今までどんな本を買ってあげたかな～と本棚を振り返ってみました。 最近は子ども向けの良書が多すぎて、羨ましい時代でございます。※以下、各リンクは可能な限り公式にしてあり、少なくともアフィではありません。 幼少期 幼児～年中あたりまでは、ひたすら本を読んであげていました。同じ本を何度も何度も……『はらぺこあおむし』などは幾度もテープで修復しつつも最後はほぼバラバラになって、引っ越しのタイミングでさようならしました。 幼少期に読んであげる本はぶっちゃけなんでもよいと思っています。最も重要なのは朗読終了後に反復を要求された時に、表面上は一切嫌がらず、それこそ機械的にしかし感情を込めて朗読してあげることです。上手に読むほど反復要求が強くなるジレンマがありますが、読んだ回数がそのまま読書好きになると思えば、安い……モノ……。 選ぶ本は、選ぶ意思が出てきたら本屋で本人がピンと
エンジニアの勉強と技術力と育児 | 外道父の匠
仕事力と技術力と不安に関する雑文 | YuheiNakasaka’s Diary を読んで、自分も勉強とは技術力とはなんぞやと考えてみたくなったのでポエムです。 詰まるところ人それぞれではあるものの、考えることは少なからず良い方向に向かう、そう願いたいものです。 勉強とは 世の中にある意見として、エンジニアは生涯勉強だとか、強々エンジニアになるための勉強だとか、色んなモノを見かけます。そういう勉強に対する意見ってたいていネガティブな印象の内容が多く、なんだか迷走しているなぁという感想を持つことが多いです。 良い子ちゃん視点では、学ぶこと、その全てには意義がある、と言いたいところですが、こと仕事においては無駄な学びもあるし、将来無駄になる学びもあります。また、自発的かどうかでその効果は天地の差があるので、他人に向かってこれくらいやるべきとか言うことの意味は薄く、突き詰めると自己責任の範囲の話
小学校のPTA作業を改善した記録 | 外道父の匠
子を持ち育つと必ずやってくる関わりに、古の組織PTAがあります。 今回、そのうちの軽めの役割を担当した際に、作業を改善した内容の記録をしつつの雑談です。 PTAの現状 PTA – Wikipedia や各学校のPTA概要を見るとわかるのですが、Parent-Teacher Association とは名ばかりで、先生はあまり関わらず、一部の親たちによる半強制的な慣習的活動になっているのが多くの現状です。 在学中に１回は何かの役割を受けないといけないとか、年に数回の持ち回りの役目があるとか、そういうほぼ強制的な仕組みが批難の理由だったりするのですが── 活動内容によってはそうとも言い切れないのが面白いところ。 例えば運動会当日の準備と片づけは、要請されればパッと集まって済ませれば先生の負担が減るからやればいいし、登下校の旗振りはウチはシルバー人材の方が担当しているけど、見てると自分も歳とった
Kubernetes、やめました | 外道父の匠
最近 Kubernetes 全然触ってねーなって思ってたところに、『6年ぶりぐらいにクラウド使った結果、Kubernetes以外のマネージドサービスとか基本要らなくない？となった話 – データエンジニアの酩酊日記』を見つけて、自分と異なる立場によるコンテナシステムへの感想を興味深く読ませていただきました。 Kubernetes を推す人がいる一方で、ここには昨夏『Kubernetes、はじめました』と言っておきながら今年に入って全然触らず、ECSを使ったシステムばっか手掛け、Kubernetes いらなくね？って思う人もいるわけで。これはいったいどういうことでしょう、と雑感タイムです。 どうしてコンテナシステムで迷うのか 最初に断っておきたいのは、以下 Kubernetes を否定したり腐すような意図は全くなく、なんでやろ？って自身に問いかけた私見です。やめました、と言ってもウチで今も使っ
データセンターの思ひで | 外道父の匠
今月、とうとうオンプレミス環境がその役割を終えたので、当たり障りのない範囲で思ひでを記録しておこうと思います。 だいたい 2002年 から運用が始まったので18年ほどの歴史でしたが、血と汗と…… 血と汗くらいですかね滲んでるのは。さぁ振り返りです。 大阪 私が参画した時にはインフラエンジニアというかサーバー担当者が既に１名おり、「サーバーやってみない？楽しいよ！」と言われて乾いた笑顔を返したのを覚えています。 当時は京都の極小ベンチャー企業で、なぜ最初が大阪のデータセンターだったのかは聞きませんでしたが、とある現地作業についていって、ハーフラック１台に１Ｕ２台が積載されていました。このへんは私自身かなりのペーペーだったので知識不足もあり記憶がかなり曖昧です。 平々凡々に運用していたある日、WEBサイトへのアクセスが途絶えました。 社長の「ねぇ、サイトに繋がらないんだけど」の一言が口火です。
ミドルウェア性能検証の手引き | 外道父の匠
インフラエンジニアの多分、華形のお仕事の１つであるミドルウェアの性能検証を久々にガッツリやる機会がありましたので、検証作業の基本的な項目について初心から振り返っておきたいと思います。読みやすさ度外視の詰め込み記事注意警報です。 世の中、雑な検証結果もちょいちょい散乱していて、私自身もそうならないよう注意を払っているわけですが、ガチでやると気をつける項目が多くて、自分で忘れたりしないようにと、誰かにやってもらいたい時に基本を抑えてから取り掛かってもらうために、形にして残しておこうと思った次第であります。 目次 なぜ性能検証をするのか 環境の準備 インスタンスの用意 クライアントの用意 サーバーの用意 ボトルネックになりうる項目 CPU Utilization Memory Network Bandwidth Disk Bandwidth Disk IOPS Disk Latency Disk
子どもの夏休みに在宅勤務してみた | 外道父の匠
以前、IT企業の勤務時間帯と子育てについて という記事にて、勤務時間を早くしてみて絶賛継続中になりますが、今回は子どもの夏休みに取り組んでみた施策について、少し長くなりますが振り返ってみます。 自宅での作業は今までいくらでもしてきましたが、明示的な在宅勤務は初めてであり、会社としても大々的に推奨しているような仕組みというわけではない、といった状況での試み的な感じです。 試みを考え始めた理由 常日頃から学童を利用している一般的な小学生の夏休みは、通常、朝～夕方まで学童で過ごし、お昼ごはんはお弁当を持参することになります。なので、普通に過ごすならば、朝お弁当を作って持たせるだけで特に不自由なく親子ともに生活することは可能です。 コレに対して、私の教育的観点から、言い方は悪いですが、夏休みにこどもを学童に閉じ込めることによる成長の機会損失が嫌だと考えました。学童の場合、友達や本などと、朝４時間過
IT企業の勤務時間帯と子育てについて | 外道父の匠
私は、それまで 9:30-18:30 だった勤務時間を、４月から 8:30-17:30 に変更しました。理由は単純で、息子の為なのですが、この１ヶ月間で感じたことでもツラツラと書いてみます。 最近のIT企業では、フレックス制だの、午後から出勤だの色々ありますが、その辺の事情も気になったのでついでに軽く調べつつ、現状の見直しでもしてみようかなと思った次第です。 私の育児事情 私の家庭はいわゆる共働きなのですが、家事育児の99％は私が稼働することで成立しています。ゼロ歳の生まれたての頃から、夜な夜な三時間おきに起床してミルクをあげつつ、通常通り業務をこなしていました。と言えば、わかる人には大体わかってもらえるでしょう。 稼働率を50/50に近づけたいという希望は一瞬ありましたが、人間、得手不得手がありますし、ストレスを一切溜めずに家事・育児・教育、全てこなせてしまう私がやってしまうことが、ベス
td-agent版Fluentdデーモンの特徴と監視 | 外道父の匠
td-agent版Fluentdを大量に導入してみて、かなり快適に動いています。 ただ、若干不安定な部分があり、対応が必要だったので記しておきます。 導入したOS 今のところtd-agentを入れたOSは CentOS 5 Debian Lenny Debian Squeeze td-agentデーモン（プロセス）の特徴 プロセス数 netstatやlsofで見たらわかりますが、tcp, udp用2つで1セットとなっています。 重複起動する /etc/init.d/td-agent start を実行したら実行した分だけ起動していきます。これはCentOSでもDebianでも確認しました。これをやると、/var/run/td-agent/td-agent.pid には新しいTCPプロセスのPIDが記録されていますが、古い方のプロセスも通常通り動作しているため、 ログが重複送信される sto
OZ plusのイクメン紹介に載りました | 外道父の匠
技術話ではないのですが、一応『父』を名に含んでいるので記念投稿してこうかなと。 7月28日(火)に発売された雑誌『OZ plus 2015年09月号』のイクメン紹介の一人として、インタビューが掲載されました。オズプラス最新号 – OZmallに立ち読みがあって、ちょうどそこが載っているのでオンラインで読むことができます。 インタビューを受けた経緯 会社の広報的に、育児に協力的な組織ということをアピールしていこう、という案から始まったようです。実際、ウチは育児に寛容な方だと思うので、その辺は入社前に質問しておくと、十分な回答を得られると思います（アピール終）。 で、広報の人が誰にインタビューしてもらうかを周りに聞いたところ、私の名が即座に上がったようで依頼が舞い込んだということになります。社内では、私の家事育児の担当率がツーナイン（99%）以上あることを知っている人も多いので、まぁ当然の結果
伝説のFusion-io ioDrive2(組立式)を手に入れたぞ！ | 外道父の匠
先日、Fusion-io Atomic Series の紹介を、ということで例によって@hasegaw御大にお越しいただきました。 いつも通りといってはアレですが、いつも通りの濃くて楽しいお話を90分コースでしていただき、お帰りの際にはレアアイテムをドロップしましたので、危なくない範囲で書いていこうと思います。 Atomic Series PX600/SX300 7月にioDriveの新しい後継機種となる、PX600/SX300が発表されました。リリース内容についてはこの辺です。 Atomic Series :: Fusion-io フュージョンアイオー、従来製品比2倍のパフォーマンスと2倍の容量を実現した新世代PCIeフラッシュストレージを販売開始 :: Fusion-io Fusion-io、微細化したNANDチップを採用しつつ性能を向上させた新フラッシュストレージ「ioMemory
エンジニアがアウトプットすべき理由 | 外道父の匠
ブログが流行りだして10年以上が経とうとしているのに今更な内容ですが、エンジニアがブログを書く書かないについて再考する機会があったので、書き留めておきたいと思います。 書く人にとってはメリットがわかってるし、書かない人にとってはデメリットを流せるし、ぶっちゃけ好きにすればいいだけではあるのですが・・・ アウトプットとは ”発信”の方がしっくりくるのでどっちも使いますが、ここでは一般的っぽい”アウトプット”としています。私が思いつくアウトプットとは、 技術ブログを書くこと Wikiに手順やバッドノウハウをまとめること Twitterやコミュニケーションツールで短文メッセージを投稿すること 登壇発表すること 講師やメンターとして育成すること 書籍や連載を執筆すること ソースコードを公開またはプルリクすること で、どれも社内／社外どちらでも問わない、といったところです。ただし、社内におけるコード
Mackerel Meetup #1 Tokyo に参加したり使ってみた感想 | 外道父の匠
はてなの Mackerel は気になっていたので登録はしていたのですが、ウチのお母さんがこのイベントに参加することになり、その勢いで俺と息子(4歳0ヶ月)もいくことになりました。 Mackerel Meetup #1 Tokyoを開催します！ – mackerel.io ブログ そのため、あわてて実際に Mackerel を使ってみて感想をメモっておくとかしておいたのですが、懇親会ではずっと息子と遊んでいたので、こちらに考えたことを書くことにします。 イベントの内容 これについては早くもまとめてくれている方々がいるので、こちらをどうぞ。 Mackerel Meetup #1 Tokyo の感想まとめ #mackerelio – Togetterまとめ Mackerel Meetup #1 に行ってきました #mackerelio | こえむの編集後記 はてぶ発の監視サービスを中の人が語る！
MySQL + ioDrive + XFSにおけるbinlogローテート問題 | 外道父の匠
前回の問題とはまた別件で、今度はbinlogのローテート切り替わりタイミングに更新クエリが停滞する、という問題を調べることになりました。 調査の過程で何を誤ったか、Twitterという魔法陣から最強クラスの重鎮魔神を召喚してしまい、恐れ多くも原因の特定と対応方針の決定ができてヘコヘコな感じでございます。 binlogローテート時の障害 数十分に１回、更新クエリが停滞してアプリケーションにエラーログが残るということから、他のエンジニアが、どうもbinlogの切り替わり時にそれが起きているっぽいことを特定してくれました。発生時は1～3秒は更新機能が停止するので、結構なレベルの障害ということでした。 binlogは1GBでローテートするように設定していたのですが、dstat -d でwrite容量を見ていると、確かに切り替わり時に800～900MBの書き込みを確認できました。 このことから、bi
2014年からはじめるAWSリンク集 | 外道父の匠
ガチのAWSド素人が年末に調べまくった、AWS関連のリンク集です。 まだまだ調査中なので随時追加する予定ですが、広深くてキリがないのと、年始一発目の目覚ましエントリということでいってしまいます！ はじめた目的 多数のスタートアップにおいて、インフラ専門のエンジニアが付かなくても、小～中規模程度まではそのチームでインフラ面を完結できるようにしたい。 …ということで、今の時代に合わせて簡単・安価・拡張性・耐障害性…を満たす環境を考えるべく、ひたすら知識をかき集めることにしました。考えた構成などについては別途書きたいと思います。 また、遡って調べるほどに出来と進化速度に感心するとともに、情報消費期限がせいぜい２年だと感じ、ほぼ２年以内の情報をもってこのような臭ぇタイトルにしています。 目次 ドキュメント アーキテクチャ クラウド全般比較 クラウド性能比較 費用／スペック ネットワーク 基本インス
Percona ServerとMySQLのSHOW比較 | 外道父の匠
使ってみれば便利なPercona Serverも、導入前は結構慎重に検証した覚えがあります。 特にベンチマークをとって極端な性能劣化がないか、とか、設定やステータスの差異をたくさん調べました。今回はSHOWの差異について書いていきます。ほぼ本家MySQLとPercona Serverの情報を表示して比べただけの内容ですが、導入するか悩んでる方には参考になるかもしれません。 SHOW ENGINES 本家MySQLのdebパッケージとの比較してもInnoDB行のCommentしか差異がないのでPercona Serverだけ載せておきます。 表示名はInnoDBでも中身はXtraDBであることを主張しています。 mysql> SHOW ENGINES; +--------------------+---------+--------------------------------------
MySQL Percona 基本情報とインストール | 外道父の匠
ioDrive＋MySQL勉強会でチラリと紹介したMySQL Percona Serverですが、並列処理やDiskI/Oに配慮された設計だけではなく、それ以外にも様々な強みがあるので紹介していきたいと思います。 Percona関連の日本語情報はまだまだ少ないようですので、自分の復習も兼ねて基本的なところから少しずつ書いていきます。 はじめに 表記について MySQL Community ServerをMySQL PerconaのMySQLをPercona Serverもしくは比較時には単にPercona あえてファイル名をmysql_perconaのようにしている所は、無関係者にMySQLの設定と理解してもらうためです 記事の書き方について わかりやすくするため記事を小分けにして長期に渡って書く予定です。そのため気分によって途中で別ジャンルの記事を挟むこともありますが、ちゃんと続けます。
ulimitが効かない不安を無くす設定 | 外道父の匠
limits.conf に書いても ulimit に効いていない、というのはよくある話です。 ulimit が少なくて困ったことはあっても、多くし過ぎて困ったことはほとんどないでしょうから、ドーンと全条件下でulimit設定を効かせる方法を紹介します。 ulimitが効かない問題 だいたいこんな内容だと思います。 SSHログインだと効かない su すると効かない OS起動時に自動起動したデーモンに効かない 普通はデーモンに効けばよいので、本当に困ったら起動スクリプトに直接書いたりしますが、方法としてはイマイチなのでちょっと工夫をします。 その前に・・・ PAMについて PAMというユーザー認証システムについてはググっていただくとして、よく出てくる /etc/security/limits.conf という設定ファイルは、PAMを通る条件下でしか有効になりません。 ではPAMを通るとはどうい
電子書籍の法人利用規約まとめ | 外道父の匠
エンジニアたるもの技術書に目を通すことはしばしばあるわけですが、最近は良書っぽいモノを見つけた時は、自分で読みたいという思いより、社内のエンジニア達に薦めて読んでほしいと思う方が強い時があります。 そうなると電子書籍を扱うことに考えがいきますが、サービスごとに規約が異なったりグレーな部分が多かったため、複数人が集まる法人として購入した場合はどのように扱うことが明確にセーフであり、かつ効率的なのか知る必要がありました。そこで、各サービスが法人の利用規約をどのように定めているのか調べてみることにしました。 最初に 調査に至る経緯 私が、法人における電子書籍の扱いについて不明確なことについてブツクサ発言していたら、法務の人が気にかけてくれて、わざわざ各サービスに問い合わせしてくれました。対象のサービスは、会話の中で数人のエンジニアがピックアップしたものが中心になっています。海外にも同様に問い合わ
キャパシティプランニング 発表資料 | 外道父の匠
久々に社内向けに勉強会を行いました。 既に稼働しているサービスの、サーバの台数調整の考え方についてです。半分くらいは口頭で話したので資料だけでは物足りないかと思います。が、せっかくなので公開しておきます。 内容はインフラ管理についてですが、対象者はどちらかというとアプリケーションエンジニアとして作成・発表しました。資料と、ブログ用に補足を書いていきます。 作りやすくて頼りになるので、 もう、赤さんはテンプレでいいかな、とも思い始めました。 補足 勉強会をするに至った理由 いわゆるインフラエンジニアが、サーバの負荷状態を観測したり、台数を判断できるのはアタリマエですが、サービスを作成しているアプリケーションエンジニアにとってはアタリマエではなかったりします。 理想としては、WEBエンジニアたるもの、自宅サーバやレンタルサーバを１つは持っていて 総合的な知識を得ようとする環境・努力をして欲しい
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
