個人事業主になりました
念のためはじめに言っておきますが会社は辞めてないですよ
色々書いて、最後のオチに持ってこようかとも思ったんですが、万が一の誤解を解くのが面倒なのでｗ
経緯
まず、私の勤めている会社で今年の春ぐらいかな？副業が解禁されました。
で、最近とある方面から個人としてお仕事のお話をいただけることがあって、その中で確定申告が必要な収入に達したので、確定申告の方法を調べていたら、どうやら副業でも個人として確定申告が必要なら個人事業主になった方が節税になるという情報を得て、ちょっとやってみようかなと思い立ったわけです。副業の対象に個人事業主は想定されていなかったんですが、試しに相談してみたら規定を見なおしてOKもらえました。会社に感謝です。
まあ、今現在安定して月収5万～10万円の保証なんてどこにもないわけですが・・・
正直、節税は割りとついでの意味合いで、こうやって形にすることで本業外で色々と動きやすくなると良いなーという想いがあったりする感じです。
どんな感じで働くの？
とりあえずは本業に影響を与えないことが前提なので、平日はフルタイムで出社して働いているので、休日や夜間がメインとなります（連絡くらいは多少遅れることはあるかもしれませんが、もちろんできます。手を動かすのはという感じ）なので、正直なかなか厳しいだろうなーとは思ってはいます。。。
何ができるの？
- クラウド（主にAWS、GCP勉強中）インフラ設計・構築
- Chef等を用いた所謂自動化・DevOps等の開発・運用フロー改善
- インフラからアプリケーションコードまで踏み込んだパフォーマンスチューニング
- PHP,Pythonを用いたアプリケーション開発（Go, Rubyもちょっとだけできます）
- 上記に関わるコンサルティングや技術支援
特に上の３つはそこそこできる方だと思っています。少なくとも道内では「この人には敵わない」って人は思い浮かばないです（勝っているとは言っていない）
特に、本業でもDeveloperとArchitect的なロールの両方をやっているので、インフラからアプリケーションまで含めて全体として最適なアーキテクチャを組んだりアプリケーションの設計をすることは普段から心がけていて、そのあたりはあまり他の人にはないバリューの出せるポイントかなーなんて思ったりしています。
なんか、こうやって自分の宣伝するのって恥ずかしいですねｗ
自分を見つめなおす良い機会になった気もしますがｗ
屋号は？
形だけに近くとも、せっかくの機会なので付けました。
Willyworks（ウィリーワークス）です。よろしくお願いします。
Willyの語源は学生時代にやっていたアメリカンフットボールのポジションの通称から取ってます。
正確にはWeak-side Linebacker(WLB)といい、簡単に言うと人数が少ない方（Weak-side）を広く守りつつ、時に鋭く前線に突っ込む（Blitz）みたいなポジション（僕の認識では）です。なんとなく自分の仕事にも当てはまるかなと感じたので。イギリス英語のスラングかなんかでアレな意味があるらしいですが。。。worksはそれっぽい感じで語呂が良かったのでｗ
というわけで
フルタイムじゃないので相談しづらいでしょうが、何かありましたらお気軽にご相談くださいませ。
Infrastructure as Code Casual 札幌 #0を開催しました。 #infracode_sap
はじめに
題の通り、やりました。 infracode-sapporo.connpass.com
満員御礼、出席率ほぼ１００％で、とても盛り上がりました。
参加していただいた皆様、ありがとうございました！
その雰囲気はこちらからどうぞ。 togetter.com
一年くらい、やるやる詐欺してたのが、やっと重い腰が上がった形になります。
まあ、雰囲気や個々の発表なんかはTogetterやら、他の方のブログなんかを見てもらうとして、振り返りをしておこうと思います。
成り立ち
まあ、これにもなんとなく書いてるんですけど。
www.slideshare.net兎にも角にも、身の回りにInfra as Codeを実践してる人が少ない。北海道で真面目にやってるは自分だけなんじゃないかと思ってしまうほどに少ない。なので、話し相手が居ないのである。
話し相手を見つけたい、増やしたい。それもやってて楽しい形で。
ということで、前々から札幌にCasual文化を持ち込みたかったというのもあり、ああいった形になった。
あとはやっぱり、一人でやると辛いので身近に一緒にやってくれる人がいたことが大きい。
何故発表を「推奨」としたのか、クオリティを問わないのか
これまでの経験上（それほど多くはないものの）、勉強会的なものを楽しくて実りあるものとするために必要なものは「多様性」であると思う。色んなバックグラウンドを持つ人が、色んな話をすることで、色んな刺激が生まれる。それによって様々な意見や議論が飛び交って、盛り上がる。
また、完成された話ではなく「これからどんなことをしたいか」や「どんな話が聞きたいか」等も可とした。これには２つの目的がある。
- 実践に繋げる
分からないことや聞きたいことを聞ける場所があるというのは、実践する上でとても助けになるのではないかと思っている。自分自身、誰にも聞ける人が居ないというのは中々に辛いものがあった。
必ずしも、予め内容が決められた勉強会なんかでは聞きたいことが聞けるとは限らない。だから、聞きたいことがあるなら言ってほしい、それも大声で。そうすれば、きっと誰かが返してくれるはず。
そして、そうやって誰かに返してもらった人はきっと、次は発信する立場になってくれるんじゃないかと思う。そうやって、喋りたい人ばっかりが集まるようになるときっと、もっと楽しいはずだと思うし、自然とレベルも上がると思う。 - 議論の喚起
ある程度見込んだことであったものの、今回は本当にこれを実感した。お酒の勢いもあってとても良い雰囲気で様々なやり取りが行われ、それによって大いに盛り上がった感がある。
要は、同じ興味を持った人が集まって、好きなようにワイワイ楽しくやりながらも、実りある形にするにはこういう形も良いのではないか。と思ったという感じである。
最後に
とにかく、楽しかった。今回のは厳密には勉強会ではないけど、そういったものでこんなに楽しかったのは凄い久しぶりだったと思う。またやってくれというありがたいお言葉もいただいているし、自分自身もまたやりたいと思っているので、たぶんまたやります。
某氏は毎月とか言っていたけど、最近ちょっと忙しくなってきたし、2,3ヶ月後くらいかな。それこそ、次もまた @hokkai7go が帰ってくるタイミングでも良いかもしれない。
今回はかなり強引に開催まで持っていったので、事前の調整不足で色々と配慮しないといけない所が出てきてしまっているので、それ次第という感じもする。
とりあえず、参加していただいた皆様、ありがとうございました！またよろしくお願いします！
特定のAMIイメージの最新情報を簡単に取得できるGemを作りました
背景
まず、この辺の記事がネットで流れてきました。
「へー、便利だなー」と思った反面、以下の様なことを感じました。
「こんな複雑なシェル覚えられる気がしない」
「これ、分かったとしてその後どうするの？コピペ？」
ということで、より使いやすくプログラマブルな形で取れると良いかなと思い作ってみました。
やってることは至極単純なので、昼休み中に何とか終わったｗ
amino | RubyGems.org | your community gem host
使い方
$ gem install amino
$ pry
[1] pry(main)> require 'amino'
=> true
[2] pry(main)> Amino('name' => 'amzn-ami-hvm-*-gp2', 'virtualization-type' => 'hvm').last.image_id
=> "ami-1ecae776"
簡単ですね :-)
この例では、リージョンはus-east-1になってます。
リージョンや認証情報はaws-sdkを使っているので、同じ方法で変更できます。
第2引数に以下の様にHashで渡すとその場で指定もできます。
Amino(
{'name' => 'amzn-ami-hvm-*-gp2', 'virtualization-type' => 'hvm'},
{'region' => 'ap-northeast-1', 'aws_key_id' => 'xxxxxxxx', 'aws_secret_key' => 'XXXXXX'}
)
たぶん、使わないと思いますがfirstも一応ありますｗ
これ、もしかして
Kumogata先生と組み合わせたらめっちゃ便利なんじゃね？
既存システムでインフラのコード化を行う意義
はじめに
大抵、インフラのコード化を始めるのって新規システムとかになると思います。
たしかに、最初からやる方が途中からやるのに比べて遥かに敷居が低く、費用対効果も高いと言えると思います。
まあ、インフラのコード化に限らず、TDDとかもそうです。
新しいことを始めるのは最初からの方がやりやすい。
これが、既存システムの場合は
- 今動いているものが壊れたらどうする？
- 既に出来上がっちゃってるものにそんなにコストかけてやる必要ない
とかいう感じで、コストやリスクと得られるメリットを天秤にかけた結果、敬遠されがちなのかなと思います。
たぶん、比較対象のメリットは以下の様なものでしょう。
- 自動化による人的コスト減
- 再現性のあるインフラによる追加開発やメンテナンスの効率と質の向上
- モチベーションアップ
でも、やったことがある人には判るかもしれませんが、実はもっと重要なメリットというか、意義があるんです。
それは何か
それは、今まで見えなかったものが見えるようになることです。
インフラをコード化していくとはどういうことなのか
特に僕が多くの場面で使っているChefだとそうなのですが、そのシステムを構成しているコンポーネントを洗い出し、分類し、依存関係を整理して、コードという形で定義していくという作業です。
そして、見えてくるものがある
例えば以下の様なものです。
- 役割を負い過ぎているサーバ
- 役割が重複しているサーバ
- 実は無くても良くて潰しちゃってコストを下げられるサーバ
- 耐障害性に不安があるサーバ
- 依存関係が複雑で追加開発や保守作業の足を引っ張りそうなサブシステム
- サービスが停止する原因となりそうな障害
他にも細かい所では、致命的なバグや脆弱性を内包したバージョンのまま動かしてるミドルウェアとかが見つかったりすることもありますが、まあそれはコード化特有っていう話ではなく二次的なものですね。
見えてくると改善できる
今までなんとなく動いていてなんとなくそのままでいたものが、見えてくることによって改善できるようになります。
そうなると、特に今後もある程度長く続くであろうシステムであれば、十分にコード化を進める意義があると思いませんか？
新規システムでもそうです。はじめからちゃんとやっておくと、全体を俯瞰して把握しやすくなり、改善計画を立てやすくし、成長スピードを速められます。
そのために
上述しましたが、そのシステムを構成しているコンポーネントを洗い出し、分類し、依存関係を整理して、コードという形で定義していくという作業をちゃんとやる必要があります。
これは、ある程度の「設計」や「実装」のノウハウが必要になります。
YAPCではその辺りをお話してみたいなと思っているので、気になる方は是非SNSなどでシェアして応援お願い致します！
以上、ステマですいません。。。
Google Spreadsheet Add-on「AWS Priceing Helper」を新しいリザーブド購入オプションに対応させました #jawsug
もっと早くやれよ、今更かよ、って話なんですが。。。
AWS Priceing Helper #とは
Google SpreadsheetにAWSの料金見積もりをするために、料金を勝手に埋めてくれる便利なカスタム関数群を追加するアドオンです。
詳しくは、今更見られるとちょっと恥ずかしい昔書いたブログをば。
blog.memolib.com
追加した関数群
- EC2_LINUX_RI_NO_AD
- EC2_LINUX_RI_PART_AD
- EC2_LINUX_RI_ALL_AD
- EC2_WINDOWS_RI_NO_AD
- EC2_WINDOWS_RI_PART_AD
- EC2_WINDOWS_RI_ALL_AD
- EC2_LINUX_RI_NO_HOUR
- EC2_LINUX_RI_PART_HOUR
- EC2_LINUX_RI_ALL_HOUR
- EC2_WINDOWS_RI_NO_HOUR
- EC2_WINDOWS_RI_PART_HOUR
- EC2_WINDOWS_RI_ALL_HOUR
関数名の意味
- 末尾
ADはAdvanced paymentで前払い金額 - 末尾
HOURはまんま時間課金の金額 NOがNo Upfrontなので前払いなしPARTがPartial Upfrontなので一部前払いALLがAll Upfrontなので全額前払いなし
ちな、時間課金の金額は公式ページには乗ってない情報だったりします。
月額が書いてあるので1年に均して割返せば分かるんですけど（っていうかアドオンでもそうやって出してる）
なぜ今更？
転職して自分で見積もりとかあんまりやらなくなっちゃったので。。。
と思ってたら、こんな感じになりまして。
けっこうな規模の見積もりレビューしてくれってSimple Monthly Calculatorのリンク送られてきて、クソ見づらいから某アレをちゃんと整備して展開すべきか…ってなってる
— Marcy Terui (@marcy_terui) 2015, 4月 14あと、Google SpreadsheetのAPI的な制限に引っかかるようになっちゃった部分とかがあっｔ（ﾓｺﾞﾓｺﾞ
ちなみに
ダウンロード数とかけっこう多い割に使ってる人ほとんどみたことないので、
最近GithubのStarとかPRくれたのも外人さんだし、海外で意外と使われてるみたいですｗ
どうぞ、ご査収ください。
IaaSのNetworkのINには課金せず、OUTにだけ課金するのは、とても理にかなった手法なんじゃないかと今更気が付きましたが何か？
とても今更感があるけど、、、「何を今更」と思ったらここで読むのをやめましょう。
ついったに書くには長くなりそうなので、落書きしてみる。
要は
INに課金しないことで、副次的に他の課金を促進できる
理由
INには多くの場合にOUTが伴う
これは言わずもがな。INがあればOUTが当然期待できる。
分かりやすいのがWebシステムで、リクエストに対してレスポンスが必ずある。
ここまでは良い。
ただ、INに対して、必ず同等のOUTがあるわけではないので、
一見するとNW帯域を消費するのはどちらも一緒で非効率なようにも感じる。
では、OUTが無い場合に起こっていることはなにか？
INがあるのにOUTが無い、あるいは出て行く量が少ない場合、内部では何が起こっているか？
内部に貯める
情報が入ってくるのに出て行かないということは、入ってきた情報を内部に貯めるということになる。
つまり、ストレージ料金が発生する。計算する
入ってくる量に対して、出て行く量または貯める量が少なくなる場合、多くのケースでそこには計算が発生する。
圧縮、分析、サマライズ、などなど。これらには必ずと言ってよいほど計算処理が必要になる。
つまり、コンピュート料金が発生する。
つまりどうなるか
INに課金しないことで「とりあえず入れとけ」的な発想を促進できる。
また、計算に料金がかかるのは当然的な意識が大半の人にはあると思うので、それなら「潤沢な計算能力を活かそう」という流れができあがる。
例えるなら
魅力的な入場無料のテーマパークで、退場時にお金が取られる。
じゃあ、せっかくだから長く遊んでいこうかってなるけど、中で生活する以上、飲食代やホテル代がかかる。そんな感じでよくできてるなあと思いました。まる。
knifeコマンドが面倒すぎるので「knife-helper」というpluginを作った #getchef_ja
経緯
コメント欄参照
knife-zeroとknife-soloとの違い
元々knife-soloを使っていた身からすると、Chef Serverの多機能さが気軽に使え、手元にサーバのインベントリがある状態で操作でき、条件で絞って一括で適用したりするのが楽なので、特に複数のサーバがある環境ではknife-soloより、とても便利です。
ただ反面、多機能ゆえにサブコマンドやオプションが多く、覚えきれないし、手数が多くて面倒な部分もあります。
これは、knife-zeroが悪いのではなく、knifeコマンド自体がそうで、knife-ec2なんかを使おうとするともっと多いですｗ
じゃあ、何があれば良いのか
initコマンド.chef/knife.rb生成BerksfileまたはCheffile生成
- ショートカットコマンドの定義
yaml等のファイルにショートカットコマンドを定義して実行できるtest-kitchen風？erbでrubyコードが埋め込めると尚可
こんな所ですかね。
ということで作った
とりあえず、ざっくり雰囲気はREADME参照ということで、詳しい使い方はこれからQiitaに書きます。書きました↓
