プログラマやエンジニアの技術情報は、まず最初に英語でやってきます。
しかしながら、普段何気なくGoogle検索を利用していると、
日本語の検索結果が多く混じってきます。
個人的には、まず英語でInputを吸収、
その後に日本語のドキュメントがあれば吸収していきたいと
思っていますので、そのための設定をエントリーします。
Chromeで英語検索用のURLを開いても、日本語のGoogleアカウントが紐付いている場合に
やはりノイズが混じってしまうようで。私はDuckDuckGoを利用しています。
play.google.com
英語のインプットを増やし普段から英語と接することは、
エンジニアにとってメリットしかないと思います。
以上です！
エキスパートを招いたナイトセミナーですごく良質なセッションが聞ける勉強会でした。
今回はイベントスタッフとして参加しました。
jjug.doorkeeper.jp
[Java Track]の最後のセッション「Microservices Gone Wrong!」に参加することができたのでレポートしていきます。
Companies that have successfully adopted Microservices have... - ...determined that they are an IT company which happen to offer financial/healthcare/trading/ shopping... services - ...embraced Cloud (technologies) as a strategic advantage - ...established solid Cl/CD practices, and deploy to production multiple times per day
What it actually means... - Make sure the organization is compatible with the software architecture - If your (microservices) architecture does not reflect the way your organization is structured, dont even bother going that way! - It also means that your teams should be cross-functional. Everyone you need to build, maintain and get it into production must be part of the team
There is no single way to do microservices right!
Struggles - Data Strategy - (A)synchroncus programming model - Orchestration vs Choreography - Re-use Traps - Test Strategy - Dealing with Failure
真に非同期で、完全に分散されたイベント駆動型アーキテクチャは、心配気のないものではありません！
A truly, asynchronous, fully distributed, event-driven architecture is not for the faint of hearted!
Isolation - Avoid cascading failures by applying bulkheads: - In shipping: partition the load into sections allowing you to seal them off if there is a breach - In software: isolate services to prevent cascading failures to cripple the entire system
Loose-coupling - Reduce coupling between failure units through - asynchronous communication - location transparency - relaxed temporal constraints - idempotency - self-containment
Latency control - Detect and handle non-timely responses to avoid cascading failures through: - Timeouts - CircuitBreaker - Fan-out & quickest reply - Bounded queues - Shed load
Anti-fragility - Try to make code less breakable by correctly applying: - Encapsulation (OOP) - Open/Closed principle - Test Driven Development (TOD)
マイクロサービスは、あらゆる組織のエンタープライズアーキテクチャの論理的な次のステップではありません
Microservices are NOT the logical next step for enterprise architecture in every organization
Microservices - ..are suites of independently deployable services, organized around business capabilities - ..are small enough so they can fit in your head and you can throw them away - ..are all about promoting modularity at the system level - ..are thriving on continuous deployment. DevOps, and infrasructure auicomaticn - ..are a legitimate way of achieving business agility in some organizations - ..will cause nightmares forever when applied for the wrong reasons!
Microservices関連は日本でも多くの登壇資料が存在していて、それだけ注目を集めています。
ユースーケースにおいて、日本人も海外の人も同じような内容を共有しているなと感じました。
それだけ、日本と海外でMicroservicesに関する認識齟齬が少ないということなのかもしれませんね。
↓の写真はOracleのサーバラックと明治神宮野球場。
こういう機会がないとサーバラックはなかなか拝めないかも。
以上です！
行ってきました！AWS Dev Day Tokyo 2018！
今回は10/31のLT大会にて、
「AWS DMSで5億レコードを移行して知り得た勘所」というタイトルでLTさせて頂きました！
※LT資料については公開許可をもらっていないので、今のところは公開予定はありません。
参加したセッションについてレポートしていきます！
www.slideshare.net
www.slideshare.net
www.slideshare.net
目黒セントラルビルの17階から見る眺めは素晴らしいの一言！
毎日こんな景観を見ながら仕事できるといいのになぁ。
私は最近、岡山に本社がある企業様とSlackで連絡を取り合い仕事をしています。
その際に一度、メッセージを見逃してしまうということがありました。
Slackの公式ドキュメントで下記のナレッジがあり、
重要なメッセージを見逃さないようにする対策が紹介されています。
もう二度と、重要なメッセージを見逃さないために実践していることを下記に記します。
この設定を有効にすることで、「全未読」というチャンネルのようなものが表示されます。
「全未読」がハイライトされている時はすぐに気付けるので便利です。
get.slack.help
すべての新規メッセージに変更する。
自分の場合はリリースとかデプロイ依頼が来るので、マイキーワードとして設定しています。
「非アクティブ状態になったらすぐに」を選択し、併せてメール通知を送信するようにする。
特定の時間帯に不在であったり、有給休暇を取得する時にステータスを設定しています。
他にも、スマホを家に忘れてきてモバイルから確認できない時などもステータスを設定しています。
↓の例では、時間指定をして業務中であることを明示してみました。
これ、意外と重要だったりします。
SlackはLINEのように既読マークが付くわけではありません。
ビジネスでスピード感が求められる時にチャットベースで仕事する場合には、
メッセージを見たことを即座にリアクションすることが大事だと思いました。
その時に私が使っているリアクションが:eyes:です。
デメリットもあります。それは、スマホの充電がみるみる減っていくことｗ
通知が多いチャンネルに参加している場合に、特に充電の減りが早い気がします。
こればっかりはしょうがない・・。
おまけで、Slackテーマのお話です！
これさえあれば複数のSlackチャンネルを差別化できます！
GitHubで公開されてるので、forkすることもできます！
できればダークモードも実装してくださいマジお願いしますSlack様。
実はHappy Hacking Keyboardを10月の初旬に
知り合いから安く売ってもらえる機会がありました。
Happy Hacking Keyboard | HHKB Professional JP | PFU
利用開始から3週間が経過し、使用感もまとまってきたのでエントリーを残します！
職場ではリアルフォースを使わせてもらっていて、
静電容量無接点方式キーボードの使い心地の良さをずっと体験していました。
個人的にも自宅で静電容量無接点方式キーボードを使いたいと思っていました。
そうなると、リアルフォースかHHKBくらいしか選択肢がありませんでした。
※最近出たNizというキーボードもありますが、できるだけ王道を行きたかった。
「エンジニアなら変化を恐れちゃだめでしょｗｗ」という内なる囁きを聞き、
新しいキーバインディングに慣れつつもMacとWindowsで兼用できる
静電容量無接点方式キーボードを使いたいなと思い、Happy Hacking Keyboardを選択しました！
常時日本語入力モードにして、半角英数字を入力したい場合は「F10（Fn＋0）」を使うほうがしっくりきた。
また、半角スペースは「Shift」＋「Space」を使う頻度が多くなった。
なんと表現すればよいのか悩むのですが、
HHKBの打ち心地は、高級な積み木を転がしているような感覚・・かもしれません。
打ち心地には心底惚れ込みました！
（Windows PCを利用しているケースにおいて限定ですが）
Macの標準キーボードに使われているデフォルトなキーバインドと同じことが出来ないのは辛い。
Dip Switchで「Del」などに切り替えられなくていいので、「Home」などに切り替えられるようにしてほしい。
ソフトウェアで対応できないかなー？
しかしながら、HHKBのキーバインディングを真似た製品が多く出回っているので、
デファクトスタンダートの地位を築いているのかもしれない。・・つまり慣れるしかないんだろうなぁ。
Windowsユーザなら使うであろう、「Ctrl」＋「Alt」＋「Delete」。
私はVirtula BoxのUbuntuに影響を与えないように、画面をロックする時に利用しています。
「Delete」が簡単に押せないんですねー。「Fn」キーと同時押しする必要があります。
できるだけ、どこでもHHKBを使ったほうがいいことになります。
持ち歩きたくないので2台持ちとかになると、お金がかさみますねー！
しかしながら、この押し心地には変えられない魅力がありますので、結局使ってしまう・・。
分割キーボードはまだ種類が少なく、
高価なものが多いので敷居が圧倒的に高いです。
安価で入手できるMistel Barocco600も検討しましたが、
マニュアルを読んでいるとキーバインディングが独特すぎて使いにくいそうな感じがしました。
しかしながら、分割キーボードによる肩こりの解消は見逃せません！
となると、理想形はHHKBの二刀流かもしれません！？
Type-Sを購入すればUSBハブが内蔵されていますので、
それを利用してもう1台のHHKBを接続するとか！？
いつか試してみたいなぁ・・。
HappyなHackingができるように・・なりました！！
数十年、愛用していきたいキーボードです！
AWSはマネージメントコンソールからアクセスするサービスなら
直感的に利用できるようになっているのですが、
それ以外のサイトで普段からよく閲覧するものが存在しますよね。
こういうサイトは、よく使うのにすぐURLを忘れます。(というか導線がしっかりしてない。)
ですので、備忘録も兼ねてエントリーを残します。
Amazon Linux Security Advisories
Amazon Linuxインスタンスを運用している場合に必読な脆弱性情報の掲示板。
http://status.aws.amazon.com/
AWSの各サービスの稼働状況を確認できる。障害かな？と思ったら確認するサイト。
しかしながら、障害が局所的な場合このDashboardで確認できない場合もある。
https://phd.aws.amazon.com
こちらはマネージメントコンソールにログインした後に表示できるサイト。
何故かサービス一覧から検索しても出てこず、サイトの導線がとても分かりづらい存在。
「利用サービス、リソースに合わせた状態管理」であるため、
ログインしているアカウントで利用しているAWSリソースの
障害やメンテナンス情報が確認できる。
Amazon Web Services Simple Monthly Calculator
こちらは有名ですね。
AWSの利用料金を試算する時によく使いますが、
最新のサービスに対応してないのではないか？という印象。
https://awstcocalculator.com/
こちらも有名。
クラウドへのマイグレーションを実施する場合に説得力のあるレポートが作れるサイト。
ただ、クラウドネイティブで作ってると使わなくて存在を忘れる印象。
対象範囲内のサービス – アマゾン ウェブ サービス (AWS)
こちらも普段あまり意識されないサイト。
AWSリソースのコンプライアンス準拠状況が確認できます。
企業のセキュリティ要件に対応できるAWSリソースを探す時に役立ちます。
1年に1度くらいしか設定しないので、設定しようと思ったらやり方を忘れていることもあるSwitch Role。
下記の資料がよくまとめられていて見やすいです。
qiita.com
以上です！
