エンジニアtypeは、各種エンジニアをはじめ「創る人たち」のキャリア形成に役立つ情報を発信する『@type』のコンテンツです。
![エンジニアtype 技術者のキャリアを考えるWebマガジン - 転職@type](https://cdn-ak-scissors.b.st-hatena.com/image/square/2dada44508f8eb0dcb2d06c7287c2ad4158d0c71/height=288;version=1;width=512/https%3A%2F%2Ftype.jp%2Fet%2Ffeature%2Fwp-content%2Fuploads%2F2016%2F03%2Fet_site_og.jpg)
最近勉強を始めたコンテナ技術に関する基礎的な知識をまとめました。 [訂正と注釈] p.27-30: 「Deployment」内の「Version: 1」 => 「Version: 2」 p.37: 「終了コードをから」 => 「終了コードから」 p.39: 「HTTPSが利用できない」=> AWS上では、SSL終端するLBがサポートされています。https://kubernetes.io/docs/concepts/services-networking/service/#ssl-support-on-aws p.40: 「ユーザがingress controllerをmaster上にセットアップする必要」 => master上にセットアップしなければならないという制約はありません。例えばGCEのingress controller(GLBC)はPodとして動作します。https://gi
「大きい番号は魅力的だからv3.20へ進むか、あるいは番号をリセットしてv4.0にするか、どっちがいい?」。約10日前の2月13に、Linus Torvalds氏は次のLinuxのバージョン番号についてGoogle+に質問を投稿し、投票を呼びかけました。 2.6.39のようなバージョン番号を避けたかった Linux 4.0へとLinuxのメジャーバージョン番号を大きくすることは、以前からTorvalds氏が個人的な希望として示していたことでした。Torvalds氏は投票を呼びかける投稿の中でも「I don't want another 2.6.39」と書いています。これは、2.6.39のようにバージョン番号の下位の細かい数字が増えていくことで、バージョン番号が分かりにくくなることを敬遠したい、ということを示しています。 そして現在のLinuxがバージョン3になり下位の数字が3.19から次に
今回は、私自身がずっと課題に感じていた「企業やチームでのパスワード管理」について。 前職で全社の情報システム部に所属していたことがあるので、以前から企業セキュリティにはかなり興味があるのですが、大企業では、セキュリティがガチガチで利便性が無い。逆にスタートアップは、セキュリティ?みたいな感じが非常に多いと思います。大抵の場合「セキュリティねえ、わかるよ、わかるけど面倒だよね」みたいな考えを持っている人が多く、あまり積極的では無いような気がします。一度失敗した経験が無いとあまり身近に感じないのではないでしょうか。 セキュリティ対策というとやることはたくさんあるけど、どの企業も抜けているんではないかと課題視していたのが、チームでのパスワード管理。自分自身もリスクあるなあと思いながら暗中模索していたんですが、ようやくそんな悩みを解決できるMeldiumというサービスを見つけてしまいました。しかも
雑誌の概要はこちら => WEB+DB PRESS Vol.85|技術評論社 。 写真はオープンセミナー広島2015での発表から 共著のみなさんも既にブログで紹介されています、各章の対象読者や雑誌のオススメ具合はこちらがとても参考になります。 @sgwr_dts(winebarrel) さんの記事 => AWS as Code!: WEB+DB PRESS Vol.85に記事を書きました - so what @muramasa64 さんの記事 => WEB+DB PRESS vol.85にCloudFormationの記事を書いた - 雑記帳(2015-02-23) @y15i(y13i) さんの記事 => t.y13i.com — WEB+DB PRESS Vol.85にCloudFormationの記事を書きました 特集を簡単に紹介すると、 導入しやすく、まあまあ普及感のあるCloud
2015年5月にSIMロックの解除が義務化され、既存のキャリア以外のスマホを使うという選択肢が増えることもあって、大きな注目を集めている格安SIM・スマホ市場。その市場規模は、今後5年で5倍に拡大すると言われている。 イオンやビックカメラなど業種・業態を問わず、様々な企業が参入し競争が激しくなってきている中、参入のタイミングは後発ながらも「業界最安値」をキーワードにひときわ注目を集めている格安SIMがある。それが「DMM mobile」だ。 「DMM mobile」は動画配信、レンタル、通販、オンラインゲーム等を提供している「DMM.com」がスタートさせた格安SIM。1GB月額660円〜という料金プラン、また利用金額の10%を「DMMギフト券」として、ユーザーに還元するキャンペーンを実施するなどサービス面にも強くこだわっている。
はじめに こんにちは、Go界のうまい棒です。昼間にTwitter眺めてたら次のような記事を見かけました。 この頃 流行りの 言語たち(他)でベンチマーク (Dart, Go, Julia, Nim, Python, Rust 他) - Blank File 結果はあくまでフィボナッチ数列をナイーブに実装した場合なんで、まあ明らかに遅くなるよなあと予想通りの実行結果でした。 件のプログラム ナイーブにフィボナッチ数列を実装してますね。 package main import "fmt" func fib(n int) int { if n < 2 { return n } return fib(n-2) + fib(n-1) } func main() { fmt.Println(fib(42)) } これを実際にビルドして実行するとどれくらいかかるかというと、だいたい手元で2.5秒以上かか
MacBook Proを新調したのでいろいろとセットアップ中です。 homebrewの検索 brew search をしまくっていたら、以下のエラーを見たのでとりあえず対策したのでメモ。 ちなみにエラーに書いてあるとおり待てば時間が解決してくれるエラーなので無理して設定する必要はないです。 $ brew search java app-engine-java-sdk javarepl jslint4java libreadline-java Error: GitHub API rate limit exceeded for 121.108.126.210. (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more detail
B! 35 0 0 0 Homebrewでsearchコマンド等をたくさんしてると使用回数を超えて GitHub API rate limit exceededと言ったエラーが出てしまいます。 その対処法について。 アクセス回数制限 GitHubでAccess Tokenを作る HomebrewにTokenを渡す。 アクセス回数制限 GitHubでは認証無しのアクセスについて、同じIPアドレスから1時間で60回までと 制限がかかっています1。 Homebrewで沢山searchコマンドなんかを使ってると、 $ brew search Error: GitHub API rate limit exceeded for xxx.xxx.xxx.xx. (But here's the good news: Authenticated requests get a higher rate limi
※2016/04/24 追記 昨年末にItamae meetupで話した時のスライドリンクを追記しました。 Databag > itamae-secret の話やConsul連携の話が追加されています。 http://www.slideshare.net/tsuyoshitorii5/itamae-meetup-vol1public 現在自分が運用管理しているChef-soloプロビジョニングの仕組み 1 を Itamaeに移行した時のお話をしようと思います。 管理規模としては大規模ではなく、小〜中規模的なところかと思います。 (ロールによってレシピ切り分けたり、環境毎にレシピ用意したりなど…) 最初に: Itamaeについて https://github.com/itamae-kitchen/itamae 軽量なChef と考えればよいでしょう。 Chefの複雑さを取り除き、必要十分な部
最近話題のGo言語の勉強も兼ねて,sensu-apiを叩くCLIを作ってみました. 名前の由来 sensu(扇子)に関連する単語ということで,kaname(要)やyoichi(与一)が候補でした. GitHubに同名リポジトリが無いということで,ohgi(扇)にしました. 作ったきっかけ 既にRuby製のagent462/sensu-cliがあります. ただ,表示の情報量が多く,見難いと感じていました. そこで,シンプルな表示で,高速に動作するものを作ることにしました. 表示形式やコマンドは,Uchiwaを参考にしています. コマンド構成 Goでコマンドを作るために,spf13/cobraを使いました. spf13/pflagでフラグが使えたり,helpを生成してくれたりして便利です. 文字列の結合は「Goの文字列結合のパフォーマンス - Qiita」を参考に,[]byteとappendで
▼ [Emacs] Emacs 24.4 の新機能・矩形選択をする rectangle-mark-mode Emacs はエディタにもなるので、その編集機能についての新機能もたくさん NEWS ファイルには書かれていた。その中で今日は rectangle-mark-mode を調べてみる。 rectangle-mark-mode は矩形の領域がマーク(選択)できるモードで、C-x SPC にキーバインドされている。 例えば、次のような状態のテキストがあるとする。Markdown でリストを書いてたけど、BBB、CCC、DDD のインデントを間違えたので、一段上げたいと思っている。 このようなときに、今までの Emacs でも delete-rectangle を使えば、矩形領域を一発で削除できた。 手順としてはこんな感じ。 上記のカーソル位置で C-SPC (set-mark-comman
Cookbookの共通化(library) 前回エントリではrecipeとdefinitionを用いたCookbookの共通化の手順を紹介しました。 今回はChefのもうひとつの共通化の仕組みであるlibraryを紹介します。 libraryって libraryはRubyコードを用いて、Chefに新しいクラスやメソッドを追加することができる仕組みです。 libraryはクックブック内のlibraries/library_name.rbに定義することで自動で読み込まれ、recipes, attributes, file, definitions, providers, definitionsで利用することができます。 libraryの用途は以下の様なものがあります。 ファイルに格納されている属性値へのアクセス ループのようなプログラムテクニックの利用 Chefのレシピから直接呼び出せるような
auユーザーの皆さん、毎月のスマホ代(利用料金)は確認してますか? 昔はauから封書(紙)で請求金額の書かれた「請求書」が郵送されてきてましたが、自然環境対策や印刷コスト・郵送コスト削減などの理由?で、メールやMy au(Web・アプリ)での確認が基本になりました。 利用料金確認サービスの名称は、「WEB de 請求書」! これからは環境の為に、請求書・明細はMy au(Web・アプリ)で確認してくださいとのこと。 しかし、どうしても紙(封書)で請求書・明細を確認したいって方がいるのも事実…。 そんな方は、有料になりますが、紙請求書の発行受付をされています。 手数料がかかって、毎月50円(1通)。 毎月封書で送られてくるので逐次保管しておけます。 当記事では私の体験の元、auユーザーの皆さんが、My au(Web・アプリ)で請求金額や明細を見る機会が増えればと思い、「利用料金の請求書・明細
PHPのbasename関数には、マルチバイトに対応していないという誤解(実際にはロケールの設定をすればマルチバイトでも使える)があったり、不正な文字エンコーディングをチェックしないという課題があったりで、イマイチだなーと思っている方も多いと思います。 そういう方々が、preg_replace(u修飾子つき)やmb_ereg_replaceを用いて代替関数を作成している解説も見かけますが、それではこれら正規表現関数は不正な文字エンコーディングをチェックしているのだろうかという疑問が生じます。 ざっと調べたところ、以下の様な状況のようです。 preg_replace : 不正な文字エンコーディングをチェックしている mb_ereg_replcae : 不正な文字エンコーディングをチェックしていない ここでは、mb_ereg_replaceが不正な文字エンコーディングをチェックしない状況と、そ
Buyer Protection Program When you buy a domain name at Dan.com, you’re automatically covered by our unique Buyer Protection Program. Read more about how we keep you safe on our Trust and Security page. Next to our secure domain ownership transfer process, we strictly monitor all transactions. If anything looks weird, we take immediate action. And if the seller doesn't deliver on their part of the
URLをいじくるプログラムをいじっていて、仕様がよくわからなくて悩んだのでまとめます。 2/23: 追試部分を追記 2018/7/14: JavaScriptのURLSearchParamsと、GoのPathEscapeについて追記 ことの経緯 HTTPとはなんぞやとか、GETとPOSTがどうの、それぞれでパラメータがどういう経緯でウェブアプリケーション(とかCGI)に渡って来るのかぐらいは知っていました。で、ウェブでXHRでGETリクエストを送る場合にはJavaScriptのencodeURIComponent()で各パラメータをエンコードして、&でくっつけて、URLの末尾に?で付与すればいいんだよね?と思っていました。こんな感じに。 var finalUrl = [url, "?", encodeURIComponent("key"), "=", encodeURIComponent(
若手インフラエンジニア現状確認会 #wakateinfra に参加したまとめ Feb 23, 2015 若手インフラエンジニア現状確認会に参加してきた。とにかく最高だった。 若手インフラエンジニア現状確認会 きっかけはこれです。 @rrreeeyyy @deeeet @y_uuk1 飲み会しよ pic.twitter.com/zUehyYnP7v — okumura takahiro (@hfm) 2015, 1月 22 Mackerel Meetup #3 Tokyo に参加した辺りで若手少ないかつ交流そんなにないよね、みたいになって開催が決定した。 あれよあれよという間に各社から有名若手がバンバン集まってきてこの中に居ていいのか…みたいな気分はあったんだけど、参加してみたらとにかく最高だった。 資料 各人の発表資料(無い人もいる)とちょっとしたまとめ、思ったことを付しておく。 ペパボ、
日本アニメ初の快挙!海外アニメ賞を受賞した『スキップとローファー』海外ライセンス部長&プロデューサーが語る、奮闘の舞台裏
いままで色々なところで言ってきたことをだらだらとまとめてみました。 計画および準備段階要求される品質の定義をおこなうDevとOpsの双方で情報が共有されるようにするいつデプロイを開始するのかを明らかにするデプロイの際にインフラを変更する必要はあるのかを明らかにするデプロイを行う時間帯、行わない時間をあらかじめ決めておく(休み前を避ける)ブランチ戦略、マージ戦略を決める継続的インテグレーションの戦略を決めるログの出力戦略を決めるビルドとリリースの自動化人的要素を減らす繰り返し可能にする自動作業と手作業を混ぜないビルドを自動化する誰のマシンでもビルドできるようにするユニットテスト、結合テスト、UIテストなどテストを自動化する本番にデプロイする際にコードを書換えなければならないといった実装を避ける毎回デプロイプロセスを設計するのではなく、毎回同じ方法でデプロイする毎回同じ方法が難しければ2パター
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く