インフラエンジニア(狭義)は死んだ - YAPC::Asia Tokyo 2014
※ 本トークにおける「インフラエンジニア」は、運用エンジニアでありながら、プログラミングに関連すること一切を、自らの選択によって放棄してしまっている人を指します IT系エンジニア(広義)を世代ごとに分類すると、おおまかに以下のようになると思います。 ハードやネットワークなどの低レイヤからミドルウェアの設定、コーディング、運用まですべてを担っていた第一世代 第一世代の知識経験を備えつつ、効率化のためにレイヤごとに分業をするようになった第二世代 分業前提で業界に飛び込んだ第三世代 もちろん、所属する組織の規模などによって一概には言えないですし、第二世代第三世代でありながら、幅広い領域をカバーしつつ活躍しておられる方もたくさんいらっしゃるとは思いますが、大半は世代や年齢層ごとにどこかに心当たりがあると思います。 昨今はフルスタックエンジニアなる言葉がバズワードとなり、下から上まで一人でなんでもこ
esa.io - 趣味から育てたWebサービスで生きていく - YAPC::Asia Tokyo 2015
「esa」は esa LLC が開発・運営しているチーム向けMarkdownドキュメント共有サービスです。2015年1月に正式リリースされてから約半年、βテスト期間も含めると1年ほどになります。 本トークではエンジニア1人とデザイナー1人で開発・運営・経営・営業などを行う上で考えたこと、経験したことなどを中心に、オフの時間に趣味で作り始めたWebサービスを事業化することについてお話したいと考えています。 発表内容(予定) 私は誰? esa LLC とは esa.io について この発表はこんな人におすすめ 趣味のようにプロダクトを作って生活していきたい人 esa.io の中のひとの考え方に興味があるひと トリが好きな人 (\( ⁰⊖⁰)/) Before esa お仕事でいろいろ 趣味でいろいろ いろいろやってたらいろんな人々に出会った ポエム界隈 #とは いろいろ試すの、大事 Begin
うっかりをなくす技術 - YAPC::Asia Tokyo 2015
人間は間違える生き物である 以下の問題を解決するヒントになる話をします: 既存のコードを誤って壊してしまうことがよくある 作業手順が多くよくミスをしてしまう 設定が正しいのかどうかよくわからないので祈りながらdeployをしている このような問題はなにを引き起こすでしょうか？ たとえば、Webアプリケーションの開発においては、誤ったデータベースの変更や決済処理を正しい状態に戻すことは難しいでしょう。 また、iOSやAndroid向けのアプリケーションの開発においては、リリースしてしまったコードを消すことはできません。 ソフトウェアにはこのようなリスクに対する安全性が求められます。 そういった意味での、安全なアプリケーションとはなんでしょうか？ 一般的には、安全なアプリケーションであるために、以下のような要素が必要とされると思います。 クラッシュしにくい オペレーションを間違えにくい データ
辛いことをやめる！から始まる業務改善とInfrastructure as Code - YAPC::Asia Tokyo 2015
Simple steps and tips to improve IT infrastructure operations Accepted #yapcasiaE Vote! Tweet (English follows Japanese) 「辛いことをやめよう！」 2年前、ITインフラを支えるMSPであるハートビーツが、業務改善を始めるときに決めたキーワードでした。その頃は、ちょうどAWSの活用をはじめとしたITインフラを取り巻く環境が激変している頃でした。私たちも例に漏れず、今までのやり方の延長ではなく、変化を求められる状況にあったのです。 本セッションでは、私が中心となって2年間取り組んだハートビーツの業務改善、特にMSPならではのInfrastructure as Codeの取り組みについて、主に次の3点についてお話しします。 1: 辛いことって結構聞きやすい 2: 最も必要として
技術ブログを書くことについて語るときに僕の語ること - YAPC::Asia Tokyo 2015
エンジニアには、なぜか「技術」についてブログに書き残すという文化があるということはここでは言うまでもないと思います。 新たに投稿されるエントリを見かけない日はなく、なんらかの技術について書かれたエントリが毎日のようにエンジニア界隈を賑わせています。 技術ブログの内容は人それぞれです。 自分が注目している流行りの技術の紹介であったり、自分が作ったソフトウェアの紹介であったりします。 ときには「ポエム」と呼ばれるような、技術を通して自分の考え方や生き方を表現したものもあります。 その技術ブログの評価システムの代表的なもののうちの１つとして、はてなブックマークがあります。 テクノロジーカテゴリのホットエントリを日常的に眺めて、技術そのものもしくはエンジニア界隈の情報を仕入れたり、エントリにつけられるブックマーク数をブログを書くモチベーションにされている方も多いのではないでしょうか。 発表者もその
Perlの上にも三年 〜 ずっとイケてるサービスを作り続ける技術 〜 - YAPC::Asia Tokyo 2015
Three years on Perl ~ The technology to developing cool web service ~ Accepted #yapcasiaE Vote! Tweet 発表者は，この三年間はてなブログというイケてるPerlのサービスの開発に携ってきました… Perlの最新を追い求め続けた三年間でした… なにも分からず，SQLをコピペし続けた数ヶ月… つらいことも，たのしいことも，みんな分かちあったコードベース… 救いを求め，藁にもすがる思いで，朝も夜も読み続けたオブジェクト指向入門…… 偶然発見して，これだと思ったドメイン駆動設計…… 苦しみの軌跡と，現在最高の設計を紹介します………!!!!!!! 当時最強のフレームワーク それまでの，社内フレームワーク 鳴り物入りで登場した，当時最強のフレームワーク 社内でも歓迎されたが…… 最強のフレームワーク vs
Perlワンライナー入門 - YAPC::Asia Tokyo 2015
Perlワンライナー便利です たくさんの技術があるなかで、適切な場面で適切な技術を選択するのは大切です。 自分が働いているフリークアウトはアドテクと呼ばれる業態です。Perlで業務を行っています。 弊社の業務ではログファイルなどで何十万行程度のテキストファイルからアドホックにデータを抽出・加工するような業務が頻出します。 自分はそういった場面ではPerlを選択するのが最善ではないかと思っています。 pythonで5分かかる作業を30秒で書いたワンライナーがなんとかしてくれる様子は「Practical Extraction and Report Language（実用データ取得レポート作成言語）」の面目躍如といった趣があります。 似た領域の技術にawkがありますが、かなりややこしいことまで出来るPerlワンライナーをおぼえておいても損はないはずです（-Mオプションもございます） 内容 この発
我々はどのように冗長化を失敗したのか - YAPC::Asia Tokyo 2015
概要 Webシステムを動かすサーバは、細胞と同じように、生まれて死んでいく。 そのようにシステム全体を活性化させることによって、常に綺麗なサーバを保つことができる。 それは式年遷宮という日本古来のシステムの中にある、穢れと禊という概念にも通じる。 この概念は去年のYAPCで話した通りだ。 その思想を持って構築を試みた2015年、 構築前「完全無人自動化で運用しようや」 ... 構築後「冗長構成って本当に必要なんですか？」 トーク内容 この構築の最中に彼が見たものとは？ 式年遷宮インフラストラクチャ3部作の第2部にあたる今作は どのような思想を持ってとりかかり、どのように失敗したのか。 実体験を元にしたお話をできればと思います。 キーワード Consulを使おう consul-templateとdnsmasqとhostsファイルと順番と MySQL(GTID)という名の夢 mysqlfail
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
