タグ

ブックマーク / blog.takuros.net (28)

  • 年金の味がするお米 - プログラマでありたい

    煽り気味のタイトルですが、わりと真面目な話です。私の田舎の方で長らく続けてきたお米作りを止める決断がされました。それについていろいろ思う事があるので、文章として残しておくことにします。 zcf428526によるPixabayからの画像 背景の説明と止めるに至った経緯 まず登場人物の関係をぼかしたまま書くと、読んでいる人は訳がわからなくなるので差し支えのない範囲で背景を説明します。田舎と書いて実家と書かなかった理由としては、次のような感じです 私が30歳くらいの時に、兵庫県にある父方の私の伯父に養子にいって家を継ぐことになった。私の感覚としては、実家というよりおばーちゃんの家 生まれ育った家は滋賀県の大津市にあり、兄夫婦が住んでいる 実母は既に亡くなっており、実父は田舎と呼んでいる家から車で10分くらいにある旧家を継いで暮らしている 実父も40歳くらいの時に、親戚の旧家を継ぐために養子になっ

    年金の味がするお米 - プログラマでありたい
  • 技術本の著者からみた商業誌と同人誌の違い - プログラマでありたい

    先日リリースした『AWSの薄いⅡ アカウントセキュリティのベーシックセオリー』は同人誌として2冊目になります。また今回は、サークル主として他のメンバー3冊の企画作りを少し手伝わせて貰いました。なので、何となく同人誌の世界も解ってきたと言っても良いような気がするので、すこしエラそうかもしれませんが、技術の著者から見た商業誌と同人誌の違いを述べさせて貰います。 執筆時間 まず商業誌である『Amazon Web Services 業務システム設計・移行ガイド』は、384ページです。これに対して『AWSの薄いⅡ アカウントセキュリティのベーシックセオリー』は104ページです。ページ数にすると。3.7倍の違いがあります。が、実は文字数ベースでいうと、もう少し大きな開きがあります。27万字と6万字で、4.5倍と差が開きます。 これは、同人誌フォーマットが紙のサイズもA5と小さく、文字が大きめとい

    技術本の著者からみた商業誌と同人誌の違い - プログラマでありたい
  • #技術書典 の生産管理 印刷数の最適化を考える - プログラマでありたい

    先日の技術書典7で、「AWSの薄い IAMのマニアックな話」という同人誌を出展しました。技術書典に参加して面白かったのが、どれくらい売れるのかを予想しながら印刷冊数を検討することでした。どういった検討を経て決定したのか、まとめてみました。 2つのパラメーター 技術書典で考えるべきパラメータは単純に2つだけです。見込み販売数と印刷数です。見込み販売数は、サークルチェック数を中心に類推し、印刷数は自分で決めます。それぞれ、見てみましょう。 見込み販売数 まず頭を悩ますのが、見込み販売数です。これは自分だけでコントロールできるものでないので、いかに正確に読み解くかが勝負になります。幸い技術書典には、サークルチェックという機能があり、この数字を元にある程度の販売数を見通すことができます。更に、先人たちの知見の蓄積の結果、開催何日前にどれくらいのチェック数だったら、最終的にどこまでいくかの予想のモ

    #技術書典 の生産管理 印刷数の最適化を考える - プログラマでありたい
  • #技術書典 に出展する『AWSの薄い本 IAMのマニアックな話』はこんな本 - プログラマでありたい

    たびたびTweetしておりますが、2019年9月22日の技術書典7に、『AWSの薄い IAMのマニアックな話』というを出展します。名前の通りAWSですが、IAMだけを取り扱っています。初の同人誌を引っさげて、技術書典デビューします。 IAMの目的 書いたはIAMの特化ですが、何故IAMと聞かれるのでここに書いておきます。AWSが不正利用されて100万円の請求が来たというようなニュースが、たまにネットを駆け巡ることがあります。原因の多くがIAMのアクセスキーをGitHubに誤ってコミットしてしまい、そのキーを不正利用されたケースです。そういった事態を防ぐために正しくIAMを知って貰いたいのです。 IAMは、AWSの利用権限を管理する極めて重要な機能です。AWSには多種多様な機能があり、IAMはそれに応じて様々な記述方法で権限を設定できるようになっています。その分設定項目が多く、I

    #技術書典 に出展する『AWSの薄い本 IAMのマニアックな話』はこんな本 - プログラマでありたい
  • マルチAZ構成で単一AZの障害の影響を受けるのは何故か? - プログラマでありたい

    昨日の「AWSのAZの割り当ては、アカウントごとに違うという話」で宿題として残した、マルチAZ構成で単一AZの障害の影響を受けるのは何故かという問題について考えてみます。キーワードはELBです。 前提としてのELBの実装(の予想) マルチAZ構成での障害発生原因を検討する前に、まずELBの実装について考えてみましょう。5年ほど前に書いたELBの挙動からみる内部構造の推測です。 blog.takuros.net 旧ELB(CLB)をもとに書いていますが、ALBでも大きく変わらないと思います。要点としては、ELB自体は、AWSが管理するEC2インスタンス上で稼働し、バランシング先のAZにそれぞれ配置されているということです。図ではELBインスタンス(仮称)として表しています。そして、ELBインスタンスへの振り分けはDNSの名前解決で実現している点です。このアーキテクチャは私の個人的な予想ですが

    マルチAZ構成で単一AZの障害の影響を受けるのは何故か? - プログラマでありたい
  • AWSのAZの割り当ては、アカウントごとに違うという話 - プログラマでありたい

    先週の金曜日(2019/8/23)に発生したAWSの東京リージョンで大規模な障害が発生しました。障害の内容は、一つのAZで空調設備の問題からEC2インスタンス並びにEBSに問題が発生したという事象です。詳細についてはAWSから発表があるので、そちらをご参照ください。 aws.amazon.com 障害の最中にTwitterのタイムラインを見ていると、単一AZ障害ではなく複数のAZで障害が発生しているのではないかという観測が多く見られました。障害としては、AWSの発表通り単一AZ障害です。では何故多くの人に勘違いされたのでしょうか?理由は2つあります。 AZの割り当ては、アカウントごとに違うという事が知られていない マルチAZ構成にしていても、単一AZの障害の影響を受ける ここでは前者のAWSアカウントの割り当ての話を説明します。 あなたが見ているap-northeast-1aは、私が見てい

    AWSのAZの割り当ては、アカウントごとに違うという話 - プログラマでありたい
  • サーバーレスで技術書の執筆環境を構築できる時代になっていた - プログラマでありたい

    ブログでレポートするのを忘れていましたが、2月に開催されたJAWS Days 2019で"AWS 我々はこうして「AWS」を書いた! 〜十人十色〜"というセッションに登壇していました。商業誌・同人誌AWSの作者たちが集まって、執筆について語るという内容でした。 同人誌の執筆環境 登壇者の皆さんの話は、執筆方法・テーマの考え方・同人誌技術書典)を取り巻く環境・お金にまつわる話と、どれも非常に興味深かったです。その中で、個人的に衝撃を受けたのが同人誌の執筆環境です。を書く工程として、企画に始まり執筆⇒校正⇒組版⇒製版といった工程があります。執筆から製版までのプロセスを支援するツールとしてRe:Viewという書籍執筆支援システムがあります。原稿書くだけであればMarkDown形式というのが多いのですが、スタイルの指定など表現力に難があります。そういった部分までサポートするRe:VIE

    サーバーレスで技術書の執筆環境を構築できる時代になっていた - プログラマでありたい
  • AWSの新サービス群に対する一行所感 - プログラマでありたい

    今年もラスベガスで、AWSの最大のイベントre:Invent開催中です。初回のキーノートが終わった所ですが、怒涛のサービス発表で頭が混乱中です。整理のために、サービスに対する感想をつけてみます。間違っているかもしれないので、悪しからず。 AWS AppSync モバイル等での複数端末のデータ同期を見据えたソリューション。必要性はすごく解るが、それってCognito Syncでやりたかったことじゃないのかな?認証認可のサービスにデータ同期を加えた筋の悪さを解消に来たのか? 2017/12/3 追記 中の人曰く、次のような役割分担とのこと AWSの新サービス群に対する一行所感 - プログラマでありたい ありがたし / Cognito Syncは「一つのIdentityに(≒一人の人間)が持つ」複数端末間での設定値等の同期のためのものだったので、前提と志向が違うのです > AppSync “それ

    AWSの新サービス群に対する一行所感 - プログラマでありたい
    wasai
    wasai 2017/12/01
  • 「この一冊で全部わかるWeb技術の基本」の監修をしました - プログラマでありたい

    Facebook, Twitter等で軽く報告しておりましたが、イラスト図解式 この一冊で全部わかるWeb技術の基の監修をしました。執筆したのは、所属するNRIネットコムの同僚2人です。どちらも、大学時代しっかり情報工学を学んで、入社してからはインフラ寄りの仕事をしている人間です。Webの仕組みを説明するにはピッタリな人間によって書かれています。 イラスト図解式 この一冊で全部わかるWeb技術の基 作者: 小林恭平,坂陽,佐々木拓郎出版社/メーカー: SBクリエイティブ発売日: 2017/03/16メディア: 単行この商品を含むブログを見る 対象読者は? 入門書なので、これからITエンジニアを目指す人や、なりたての人、或いはIT業界に入ったのでWebとはなんぞやと知りたい営業・企画の人など、非エンジニアでも読めるように意識して書かれています。そもそもWebと一口に言っても、現在では

    「この一冊で全部わかるWeb技術の基本」の監修をしました - プログラマでありたい
    wasai
    wasai 2017/03/03
  • アプリケーションエンジニア向けのAWS本を書きました - プログラマでありたい

    たまに呟いていましたが、『Amazon Web Services パターン別構築・運用ガイド』に続くAWSの第二弾として、『Amazon Web Services クラウドネイティブ・アプリケーション開発技法』というを書きました。今回も、所属している会社であるNRIネットコム株式会社の同僚たちと書いています。そして今回のは、主にアプリケーション・エンジニアを想定して書いています。何とEC2の使い方が一切でてきません。 Amazon Web Services クラウドネイティブ・アプリケーション開発技法 一番大切な知識と技術が身につく 作者: NRIネットコム株式会社,佐々木拓郎,佐藤瞬,石川修,高柳怜士,佐藤雄也,岸勇貴出版社/メーカー: SBクリエイティブ発売日: 2016/04/20メディア: 単行この商品を含むブログを見る を書いた理由 前回の『Amazon Web Ser

    アプリケーションエンジニア向けのAWS本を書きました - プログラマでありたい
  • まさに実践入門!!「Amazon Web Services 実践入門」 - プログラマでありたい

    舘岡さん(@iara)さんに、Amazon Web Services 実践入門を頂きました。ありがとうございます!! 早速読んでみましたが、実践入門という名前に違わず入門なのに実践的という内容にまとまっていました。その辺りは、著者陣の経験の深さがにじみ出ています。著者陣は、舘岡さんを筆頭に、今井さん、永淵さん、間瀬さん、三浦さん、柳瀬さんとAWS界隈のスーパースターたちです。それぞれの所属する会社は、日で5社しかないAWSのプレミアパートナー、従来の情報システム部の常識をスーパーのパックの刺身のツマほどの価値しか認めず常に大胆かつ合理的な方法でAWSを利用し周囲を驚かせるハンズラボ、オンラインによる名刺管理という業界を作りリーダーとして君臨するSansanの中の人とAWSを知り尽くした人々によって書かれています。 Amazon Web Services 実践入門が実践的な理由 書で取り

    まさに実践入門!!「Amazon Web Services 実践入門」 - プログラマでありたい
  • 実行計画が解れば怖くない。SQL実践入門 - プログラマでありたい

    技術評論社さんから、SQL実践入門を献いただきました。ありがとうございます。 SQL実践入門の主題 このの目的は、「パフォーマンスの良いSQLの書き方、特に大量データを処理するSQLの性能向上の方法を理解すること」とあります。そのパフォーマンス向上の為の解として、SQLが内部的にどう処理されているかを表す実行計画の読み解き方を、いろいろなケースを上げながらひたすら解説しています。そして、何故その実行計画になるのか、データ構造やDBの動きとともに説明しています。ということで、実行計画大事という基かつ当たり前のことを、正面から取り扱っている良質のSQLです。 SQL実践入門の構成 SQL実践入門の章立ては、下記の通りです。 第1章:DBMSのアーキテクチャ──この世にただ飯はあるか 第2章:SQLの基礎──母国語を話すがごとく 第3章:SQLにおける条件分岐──文から式へ 第4章:集約

    実行計画が解れば怖くない。SQL実践入門 - プログラマでありたい
  • 『Amazon Web Services パターン別構築・運用ガイド』を書きました - プログラマでありたい

    たまに呟いていましたが、AWSを題材に『Amazon Web Services パターン別構築・運用ガイド』というを書きました。今回は、所属している会社であるNRIネットコム株式会社の同僚たちと書いています。 Amazon Web Services パターン別構築・運用ガイド 作者: NRIネットコム株式会社,佐々木拓郎,林晋一郎,小西秀和,佐藤瞬出版社/メーカー: SBクリエイティブ発売日: 2015/03/25メディア: 大型この商品を含むブログ (1件) を見る を書いた理由 前回執筆した『Rubyによるクローラー開発技法』が好評だったこともあり、SBクリエイティブさんからAWSを出さないかという打診を受けました。AWSは長年親しんできたこともあり、また仕事でもAWSに関する事業を進めている関係で、願ったり叶ったりでした。 一方で、やはりを出すというのは大変です。私個人の問

    『Amazon Web Services パターン別構築・運用ガイド』を書きました - プログラマでありたい
  • Amazon Elastic Load Balancing (ELB)の内部構造および拡張・障害時の動き - プログラマでありたい

    諸般の理由により、AWSの各サービスの挙動を改めて復習中です。まずは、Amazon Elastic Load Balancing 、通称ELBについてです。ELBの内部の動作については、公開されている公式ドキュメントが割とあります。是非一度しっかりと目を通しておくとよいですよ。少なくともAWSマイスターシリーズのELBについては、読んでおくべきです。簡潔にかつ詳しく説明されているので、理解が格段に進むでしょう。というところで、現段階で私が理解しているELBのアーキテクチャをまとめてみました。 ELBの内部構造 ELBは、ELBエンドポイントとELBインスタンス(仮称)によって構成されます。ELBインスタンス(仮称)の正式名称は知らないので、その名前で呼ぶことにします。ELBインスタンスには、グローバルIPが付与されます。ELBエンドポイントは、myLB-xxx.elb.amazonaws.

    Amazon Elastic Load Balancing (ELB)の内部構造および拡張・障害時の動き - プログラマでありたい
  • Twitterの呟きでAmazon EC2のインスタンスを起動するスクリプト - プログラマでありたい

    JAWS-UG Advent Calendar 2013の13日目です。ついでに独りでAdvent Calendarに挑戦中です。 AWSの費用を抑えるコツは、使っていないインスタンスをこま目に停止することです。例えば開発機として利用しているのであれば、出社した時に起動して退社時に停止するのが理想です。しかし、わざわざマネージメントコンソールにログインするの面倒くさいですね。私だったら、3日で手運用していることを忘れてしまいます。そんなモノグサちゃんでもちゃんと節約する方法を伝授します。Twitterによる起動停止です。 Twitterによるインスタンスの起動と停止 指定したユーザの特定の単語に反応して起動と停止するスクリプト例です。 起動・停止するインスタンスは、EC2のUserというタグ名でTwitterのユーザ名を設定しているインスタンスです。タグ指定なので、複数台でも起動出来ます。

    Twitterの呟きでAmazon EC2のインスタンスを起動するスクリプト - プログラマでありたい
  • Markdown記法+Git+md2review+ReVIEWで原稿・ドキュメント管理 - プログラマでありたい

    来年は、インプットあたりのアウトプットの増加を目指しています。具体的なアウトプットとしては、ブログを書くこともその1つですし、公開・非公開を問わずに効率的にドキュメントを書いていくこともあります。その中で効率的にドキュメントを書くには、バージョン管理を含めドキュメントを管理する仕組みが必須だと思います。以前、原稿を書いていた時は、Git+MS Wordで書いていました。版管理出来るという点では良いのですが、Wordということで執筆出来る端末も限定され、またフォーマット変更もしづらいので改善を考えていました。 そんな中で、IT系の物書きの人たちの間でReVIEW良いよという話を何度も聞いたので試してみようと思いました。一方で、記述のデファクトは今後はMarkDownになると思うのでそちらもマスターしたいと考えています。Twitterで何気なく呟いたら、@masawadaさんにmd2rev

    Markdown記法+Git+md2review+ReVIEWで原稿・ドキュメント管理 - プログラマでありたい
  • ワインの品種。まずは3つだけ覚えておけば大丈夫 - プログラマでありたい

    プログラマ系ブログですが、ワインの記事が好評で生き方に迷っています。さてワインを選ぼうとする時の最初の障壁は、品種だと思います。ワインのリストは大抵の場合、銘柄の他に生産地と品種が書いています。銘柄を知らないとしたら、生産地と品種(と値段)で選ぶしかありません。でも、ワインのブドウの品種は多すぎてとてもじゃないけど覚えられませんよね?そんな人に、最低限覚えておいて欲しい赤ワイン用の3つの品種を紹介します。 覚えておくと良い品種は、3種類だけ ワインのブドウの品種は、基的にはフランスのボルドー&ブルゴーニュの系列とイタリア&スペインの系列がメインです。そして、イタリア&スペインの品種はかなり細分化しているので最初は覚えるのを諦めて、フランス系の品種を覚えましょう。アメリカ・チリ・オーストラリア・ニュージランド・南アフリカで栽培される品種は、フランスとほぼ同じです。そうすると、品種をみるだけ

    ワインの品種。まずは3つだけ覚えておけば大丈夫 - プログラマでありたい
  • 身も蓋も無い1,000円台のワインの選び方 - プログラマでありたい

    フランス人じゃないですが、日常的にワインを飲んでいます。しかし、お大尽ではないので、必然的にコストパフォーマンスの良いワインを探すことになります。だいたい1000円台のワインを飲むことが多いです。最近では選び方が解ってきたので、千円台のワインであれば比較的大外れすることもなくなりました。 大体のポイントをまとめてみると、身も蓋もない結果になりました。賛否両論だと思いますが、参考にして頂ければと思います。 スーパーで買わない まず1つ目ですが、スーパーで買わないということです。以前にも書きましたが、大手スーパーは大量仕入れが前提となります。それに答えられる生産者は、大量生産する生産者だけになります。大量生産の生産者は自前の畑だけではぶどうが足りないので、近隣の農家からぶどうを買い集めることになります。その構造になると、ぶどうを納める農家側の行動原理は、出来るだけ多く納めることになります。そう

    身も蓋も無い1,000円台のワインの選び方 - プログラマでありたい
    wasai
    wasai 2013/10/01
    チリ産を買うことが多いですね
  • 家庭内ストレージ/NASのあれこれ。保存方法からバックアップ対象まで - プログラマでありたい

    はてブを見てると、NASやクラウドドライブなどストレージ関係のエントリーが幾つかあがっていました。私は、家庭内ストレージには比較的うるさいので一言いわせて頂きます。 家庭内でのストレージの種類 まずは一般的に家庭内のストレージはどういった種類があるのか整理してみましょう。主に下記の5種類くらいに分類出来るのではないでしょうか? パソコンのローカルストレージ(HDD/SSD) スマフォ/タブレットのデータ領域 NASなどのネットワーク接続型共用ストレージ Dropboxなどローカル同期型のクラウドストレージ Amazon S3やBitcasaなどのローカル非同期型のクラウドストレージ ストレージを考える上でのポイントは、速度・容量・価格の3点です。 まず速度については、パソコンからファイルを読み取るスピードです。小さいサイズのファイルだと余り問題になりませんが、動画系など大きなファイルだとこ

    家庭内ストレージ/NASのあれこれ。保存方法からバックアップ対象まで - プログラマでありたい
    wasai
    wasai 2013/09/01
    うちはローカルかNASがメインで、大事なものはオンラインストレージにも同期をとってますね。容量も結構あるのでこのへんがベストかなと。
  • 技術を伝えても、技術者の価値はなくならないという話 - プログラマでありたい

    増田で、この記事が話題になっていました。 正社員に仕事を教えたくない 私は今年で契約が切れるパート。同じ部署に昨年、数歳年下の新入社員が配属された。 彼女は私が少ない仕事から数年かけて学び、また効率的に処理できるように試行錯誤して会得したノウハウを、たくさんの仕事の中でどんどん吸収している。これまで私しか使えなかったソフトも、ほぼ同じくらい使えるようになった。 この記事書いた人の仕事の内容はよく解らないので元ネタに対するコメントは差し控えます。一方で、これを見ていたITエンジニアのクラスタっぽい人々が、技術職にとっては技術を伝えると自分の価値が無くなるよなぁ的な発言をしているのを幾つか見たののが興味深かったです。なので、ITエンジニアにとっての技術と、それを伝えるということを考えてみました。前提として、ITエンジニア技術についてです。製造業の技術流出は別の問題だと思うので、対象にしてい

    技術を伝えても、技術者の価値はなくならないという話 - プログラマでありたい
    wasai
    wasai 2013/05/28
    末端じゃきれい事だけで出来ないんだよなあ、今の部署もそうとうひどいし。請われれば教えますけど、それでまっとうに評価されたことは最近ないですな。