PHPカンファレンス福岡2018前夜祭リジェクトコン
![コンテナを雰囲気で動かさない話](https://cdn-ak-scissors.b.st-hatena.com/image/square/36eadc7d9a15905be34280f7c381000e15ecc5ea/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2Fd342fef437344404a2ce17bb43528785%2Fslide_0.jpg%3F10226736)
【ACM】 サーバー証明書の有効期限切れ/自動更新失敗 ACMは、CloudFrontとELBと連携してサーバー証明書を提供するサービスです。 ACMで発行する証明書は1年毎に更新する必要がありますが、基本的には自動更新されます。 ただし、場合によっては自動更新が失敗するケースがあります。 検証の仕組みは、以下のドキュメントを確認してください。 自動ドメイン検証の仕組み 自動検証に失敗した場合、EメールおよびPersonal Health Dashboardで通知されます。 自動検証に失敗した場合 また、外部で発行された証明書を利用している場合は、手動で更新する必要があります。 再インポートの手順は、以下のドキュメントを参照してください。 証明書の再インポート EV証明書が必要なケースでも無ければ、ACMで証明書を取得してオペレーションが発生しないようにしておきたいですね。 【Route
個人で運用している幾つかの Web サービスについて、自分がどう管理しているかを振り返る。 実験には Heroku を利用習作につくったアプリやβ版段階のアプリは、Heroku で動かしている。Heroku を使う場合のより具体的な条件としては、データベースが明らかに無料枠に収まりそうで、24時間動いていなくてもまあ誰にも怒られそうないような場合。Slack 用の Bot や、nippo という日報専用サービスのクローズドβ版などを主に置いている。 メリットに感じている部分は、無料で使えること。デメリットに感じている部分は、サーバが US に配置されることと、データベース系の Add-On が高くつくこと。例えば日本語圏向けのサービスだと、通信時間がそこそこ長くなり、結果的にサービスの体験が悪くなる(昨今の平均的な Web サイトの速度はまだまだ遅いので、それと比較すると悪くなるというほど
引っ越して2ヶ月ほどの新しい自宅で試したDIYやスマートホーム関連のIoTデバイスなどを実践して試したことについて4回にわたって書いていこうと思います。 INDEX 賃貸DIYでつくる住みよい部屋 実践HomeKitの暮らし スマートスピーカーの設置と運用 ← 今回 スマートスピーカーへの展望とデザイン スマートスピーカーの設置と運用 我が家ではスマートスピーカーの中でも、Amazon Echo DotとGoogle Home Miniを設置して運用しています。 正直そこまで使い込んでいるわけではないので、マイナーなおすすめスキルを紹介するような事はできませんが、私が実際の生活の中で利用するシーンや普段の暮らしにどのように溶け込ませているのかなど、私の趣向的な感想も踏まえながら書いていこうと思います。 Amazon Echo DotとGoogle Home Mini スマートスピーカーはA
はじめに 小室です。2017年も最後の日になりました。 ここ最近は読書によるインプットが少なくなったことによって、文章の質が自ら目を背けたくなる程度に低下していたため、仕事納めから数日はひたすら本を読む生活をしていました。まだまだインプットが足りていないので充電が完了していないのですが、年末恒例になったエントリーを書かないことが自分の中でモヤモヤとして残っていたので、重い腰を上げて文章を書いてみようと思います。 ここ数年は珍しく1つのプロジェクトにつきっきりで設計/実装から運用までを通して担当しています。 *1特に運用を担当するようになって多くを学んだ一年でした。もはや設計・実装者が一人も残っていないアプリケーションのメンテナンス、改修に関わったり、インフラ側とアプリケーション側の狭間を埋めるように動くためにAWSのサービスについて本格的に勉強をしたりするなど、1アプリケーションエンジニア
IaaSの中で構築などをしている者です。 データセンターの中にネットワークやサーバを作っていますが、データセンター設計1にはこれといった指針やベストプラクティスのようなものが(あるようで)実はあまりないため苦労することがあります。 検証環境でもない限り、データセンタに作ったシステムというのは、気に入らないからと言って、じゃあ止めて作り直すね、というわけにもまいりません。 特に物理的な問題は、後になってから「ああしておけばよかった」と思っても、後の祭りです。 クラウドを使っていれば、気にしなくても良いのですが、それでもコロケーションやオンプレミスに何か作らなければならなくなった方の参考に少しでもなればと思い、まとめます。 サーバとルータを同じラックに入れるのは有りか? 何が問題なの?と思われるかもしれませんが、 結論を言えば、無しではないが極力避けるべき、です。 主な問題はこんなところです。
IT導入を行うにあたって、非常に多いのが「カタログや画面、説明を聞いていたらこのソフトやシステムで問題ないと思っていたが、実際に納品されたものと使ってみると使いづらかった。期待したものではなかった。」という失敗談です。そういったすれ違いを可能な限り少なくするために、ITシステムを導入するために何をどう考えなければならないのかを解説します。 「要望」と「要件」がもたらすギャップ システムを手に入れる過程は、注文住宅を作る過程によく似ています。 リビングは12帖以上 書斎が欲しい 床の木からぬくもりを感じたい 寒がりなので断熱効果を高めたい これが要求、つまり成し遂げてほしいことです。使う人が作る人に対して、伝えるべきことです。 これに対し「要件」というものは、こういうことになります。 12帖のリビングにするために、書斎の場所は収納になるが良いか? 断熱効果を高めるための素材はこれでいいか?
属人化の理由 個人の問題 手抜きやバグを隠す たとえば、仕様書外の動作を実装し、それをプロジェクトで利用する 解雇されないための保険的行動 チームの問題 マニュアルを作る文化の欠如 他人のタスクに対する無関心 他人の監査なしにプロジェクトを更新可能 どうやって属人化を避けるのか 間違った対策 ○○さん以外にもマニュアルなしで操作できる人間を育成 育成した人が全滅すればやっぱり同じ状況 全員がすべてのプロジェクトに精通するとかはムリ 正しい対策 モジュールごとに仕様書を用意 間違って使うことが難しい仕様とする 即ち、仕様書を読まなくてもある程度正確に使える お互いにコードレビューさせる 具体的にはどうすれば良い? テスト・仕様書・利用例 テストは仕様書のベースとなる 仕様書を見れば、深い動作がわかるようになる 仕様書を読まなくても、利用例を見れば使える 全員がテストできる環境を作る 前提条件
http://itpro.nikkeibp.co.jp/atcl/column/14/346926/101101158/ Q1.役所の仕事なんて全国でほぼ一緒なのに、なんで自治体ごとに別のシステムを作るの? A1.地方自治体の事務や財務について法律で決まっているのは大枠だけだよ。 それを実務≒内部規定に落とし込むのは各役所ごとなので大枠は似てても実務プロセスは全然各役所で違うよ。例えば同じ業務でも独自の語彙があったり、下手すると同じ語で市町村ごとに意味が違ったりするよ。 Q2.なんで新規で作らないの? A2.80年代ぐらいにやったよ。その結果が政令市クラスに残ってて今回京都市が更新しようとしてるような、メインフレーム上のシステムだよ。 Q3.メインフレーム(汎用機)って何? A3.みんなが使ってるWindowsとかLinuxとかのOSがなかった時代のコンピュータだよ。IBMとかがベンダーご
もう5年か、まだ5年というべきかちょっと判断に迷う。大抵の業務系のシステムがクラウドを始めるのは現実的には今年来年以降になるので、今の自分達の状況は多分、今後の業務系システムをクラウド移行したユーザの近未来になると思う。ので、予想的にまとめておく。本格的にクラウドを利用した業務アプリケーションの5年がどうなるかの一つの指針になるかと。 以降は別に統計データでもなんでもなく5年間を眺めてみて自分の印象。 ・障害:大規模は5年で2-3回程度。一度は業務に影響が出て客先にお詫びに行った。AWSだったけど、サポートからは「もう回復してるのでチケットクローズね」みたいな話だったと記憶している。その後は大体四半期に一回程度のN/W障害。障害は普通に起きているし、オンプレと比べてどうか、という比較では細かい障害件数は減った気はしていない。ただし、「ドカンと来るでかい障害」は確実に減った。 ・データ増加対
scala.connpass.com Scala福岡で登壇機会をいただき、お話してきました。 ぼくたちが運用・開発しているMackerel というプロダクトで、2度実施したPlay Frameworkのバージョンアップで得た知見を元に、アプリケーションフレームワークの更新をどうすれば安全にやれるだろうか、という観点でのお話でした。 あえて技術的な側面にはあまりフォーカスせずに、プロジェクトマネジメントの視座からお話することで、ScalaやPlayにかぎらず参考になるような発表になればいいな、ということを意識しました。他の言語の世界をあまり詳しく知らないので、意図通りの発表になったかどうかはわかりませんが…。 Twitterを見たところ、おおむね好評なようでよかったです。 サービスに機能追加しながら運用しつつ、フレームワークやライブラリのバージョンアップについて行くのまじで大変なので、このセ
大阪でサーバーレスの話をしてきました クラスメソッドの開発を知る!大阪勉強会 第7回 これから始めるサーバーレス!〜最新サービス使いこなし術〜で スピーカーとして登壇しました。参加率が非常に高く、多くの方にご参加いただきました。誠にありがとうございました! 本記事では、勉強会でお話しした「目的別、サーバーレスアーキテクチャの教科書!これのときはこう!」の発表資料を公開します。 発表資料 内容 本セッションでは、これからサーバーレスを始める人向けに、サーバーレスとは何か?という話から、具体的にどのようなアーキテクチャを構築するのか?というお話しをさせていただきました。 サーバーレスアーキテクチャパターン 本セッションでは、サーバーレスアーキテクチャのパターンを20種類ご紹介しました。サーバーレスと言えるアーキテクチャは20種類では語りきれないほど沢山ありますが、今回は独断と偏見で選んでみまし
先日、某SIコンサル社にいる方が、まだ転職を悩んでるという前提でのカジュアル面談に臨んだ。その人の転職理由というのは、僕が受託の会社から転職した時に言っていたこととそのままだったので、是非、本面接に進んで欲しいと思った。 その一方で、受託からWebサービスに来る人に、よく言うことして、 「受託からWebサービスに来ると、ファンタスティックな案件がなくなってつまらないかもしれないですよ」 と言う話をする。これはどういうことか?というと「技術的チャレンジ」を求めるならば、筋の良い受託の会社にいる方が楽しくて、Webサービスはコードを書いている瞬間から技術的なレガシーを産んでおり、先々に渡って最初の選択の影響を受けるので、あなたの技術力の定義が「話題の言語でコードを書けること」であるならば、Webサービスはあんまり勧めません、という話をする。 当時僕がいた会社は、技術の共通化がまだ進んでおらず自
名古屋大学で開催されたIPSJ-ONE2017 で登壇しました。 IPSJ-ONEというのは、情報処理学会の各研究会から選ばれた日本の若手トップ研究者17人が集まり、自身の研究を高校生でもわかるように発表するイベントです。 1000人ぐらい入る講堂で、しかもニコニコ生放送で配信されるというとても大掛かりなイベントです。 ちなみに、昨年は、同じ研究会からの推薦で、 id:matsumoto_r (matsumotory) さんが登壇されています。 IPSJ-ONE 2016で登壇してきた - 確実に時代は変わってきている #ipsjone - 人間とウェブの未来 発表 「高度に発達したシステムの異常は神の怒りと見分けがつかない」という、一見何の話かわからないやばそうな話なんですが、大真面目に話してきました。 スライドを以下に公開しています。ただ、スライドだと何の話をしているかおそらくわからな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く