Reach Over The Sky, Tear The Sky

tree_encoding_blog_post.md tree コマンドの結果をリダイレクトでファイルに保存すると、以下のような文字化けが発生します： I:. │ .flutter-plugins-dependencies │ .fvmrc 上記のような正常な表示が、以下のように化けてしまいます： I:. ��������.flutter-plugins-dependencies ��������.fvmrc または I:. ・ｽ・ｽ・ｽ・ｽ・ｽ・ｽ・ｽ・ｽ.flutter-plugins-dependencies ・ｽ・ｽ・ｽ・ｽ・ｽ・ｽ・ｽ・ｽ.fvmrc 原因 この問題は 文字エンコーディング の違いによって発生します： tree コマンドの出力 : Windowsの既定エンコーディング（CP932/Shift_JIS） ファイル読み込み時 : UTF-8として解釈される この不一致により、罫線文字（ │ , ├─ , └─ など）が正しく表示されません。 解決方法 方法1: PowerShellの Out-File コマンドレットを使用（推奨） tree /F | Out-File -FilePath filename.txt -Encoding UTF8 この方法により、最初からUTF-8エンコーディングでファイルが作成されます。 方法2: コマンドプロンプトでコードページを変更 chcp 65001 tree /F > filename.txt chcp 65001 でUTF-8コードページに切り替えてから実行します。 方法3: 既存ファイルの変換 既に文字化けしたファイルがある場合： Get-Content filename.txt -Encoding Default | Out-File filename_fixed.txt -Encoding UTF8 treeコマンドのオプション解説 /F オプションの違い tree （ /F なし） : ディレクトリ構造のみ表示 tree /F （ /F あり） : ディレクトリ構造とファイル名の両方を表示 実行例 /F なしの場合： フォルダー パスの一覧: ボリューム HDCZ-U...

 私の場合はバッテリー充電の設定のうち、「バッテリー充電の最適化」を解除したことにより解消されました。 この画面は右上の電池マークのアイコンから「"バッテリー"管理設定」を開くと表示されます。 「最適化」という単語はとてもいいものに聞こえますが、時には期待しない挙動をすることもあります。 この機能は「バッテリーの劣化を軽減するため」とありますので、状況によっては 充電してほしいのに、これまでの使用状況からOSが「いまは充電しなくてよい」と判断されて充電がされない といった状況が起こり得るということになります。 これが気になりました。  結果として、最適化を解除したとたんにファンの鳴動が静まり、アプリケーションのカクつきがピタッとおさまりました。 これが時間とともにもとのカクつき状態に戻るかどうかは追って確認したいと思いますが、いったんはこれでよさそう…。  ひょっとしたら同様の手順で解決する人もいるかなと思い、メモとして残したいと思いました。  最近は転職したり色々あってフルリモートで自宅で会社支給のMacで業務に勤しむような状況で色々と頑張らないといけない感じですが、これまで知り合った同業の知人たちにもあまり連絡できていなかったりするので、そのへんも少しずつご連絡もできればと思っています。

実は読後まとめは人が書いたものを読むのは好きなんですが、自分が書くのはあまり好きじゃないんですよね…ｗ ハーバード・ビジネス・レビューは初めて読みました。 1冊2000円でかなり高いですが経営者や会社役員が読むような内容が多いので、まぁ価格もそういう設定になると思います。 私はビジネス雑誌が割と好きで新入社員のころは「プレジデント」を読みまくっていましたが、こちらの方が値段が高い分、論文の引用も多くて記事に対し学術的な裏付けが強く、またインタビューの質も高いと感じました。 今後もタイトルをチェックして気になった号はピックアップして読もうと思います。 さて、セルフ・コンパッションです。 直訳すると「自らに同情すること」となりますが、感覚としては「 大きなトラブルやミスに直面した時に、仲のいい友人のようなもう一人の自分を作り、その友人として自分を慰め、励ますこと 」という感じでしょうか。 そうやって、人によっては必要以上に落ち込んでふさぎ込んだり（私もそう）、必要以上に自分を叱り改善のために鞭を打ったり（私もそう）してしまい、ただでさえケアが必要な状況で自分が自分をより追い込んでしまうような場面を回避する手段として注目されているそうです。 本来の「 自己肯定感 」と同じ意味だと思います。自己肯定感は「ありのままの自分を受け入れられるレベル」を指します。自分に自信を持つ、自分をもっと高く評価するというのはまた別の用語になります（セルフ・エスティーム：自尊心） まぁとにかく、セルフ・コンパッションを思い出して、日々自分の活動やメンタル状況と向き合い、自分の中で「仲のいい友人」を展開して、その友人としてより良い方向に動けるよう、励ましあうのがよいということでした。 そのほかにも色々とためになる記事がありましたが、全部書くと転写と変わりがなくなってしまうので、興味がある方は雑誌をご覧ください。

AWS認定 SysOpsアドミニストレーター アソシエイト に先日合格しました。 合格時のスコアは 794/1000 で、合格者の中では高くないほうだと思います。 分野的には「モニタリング」と「ネットワーク」が特に点数が低かったみたいで、その領域については別途改めてまとまった量の勉強を行っていった方がよさそうです。 学習内容について 学習方針は基本的にソリューションアーキテクトの時やデベロッパーの時と同じです。 学習方針 AWSが公式に提供している模擬試験を受ける 模擬試験の問題をすべてスクリーンショットを撮る スクリーンショットを見返して特にわかってなさそうなサービスや技術領域（監視系、サーバレス系、DB系　など）を特定する その分かっていないサービスや技術領域に関するドキュメントを読みまくる サードパーティーの有料教材は買わない これまでとSysOpsでの勉強方法や内容の違い Developer アソシエイトの場合は海外ブログ等を発掘してどのサービスを重点的に勉強すればよいかを洗い出していったのですが（これ勉強しとけよ！って書いてくれてる英語ブログとかあった）、SysOps アドミニストレーター アソシエイトの場合はとにかく先人のブログが少ないです。 それで今回は基本に忠実？に、スクリーンショットを見返してそこから自分が勉強すべき内容についてリストアップしました。 その結果以下のようになりました。 上から勉強した方がいい順です。 System Manager AWS Service Catalog Snowball Storage Gateway AutoScaling Group Egress-Only Internet Gateway SAMLフェデレーション VPN(Direct Connect?) NAT Gateway VPC Route53 CloudFormation S3 低頻度アクセス 受けたあとについでに学習したほうがいいと思ったのは、以下のようなサービスです。 AWS Config IAM Route53(優先度上げたほうが良かったかも） ちなみに今回は時間がなかった（取り掛かり始めるのが遅すぎた）ので、あんまり...

ブログ執筆のリハビリにもなるので閑話休題的な話題について備忘録を残そうと思います。 私はここ最近Nintendo Switchで出た「 大乱闘スマッシュブラザーズSPECIAL 」（スマブラSP）にハマっており、わりとオフタイムの時間をそれに捧げています。 スマブラSPではいくつかのオンライン対戦機能があり、それらをより快適にプレイするために、現状の確認と課題の洗い出しを行なったりしてみました。 オンライン対戦機能の種類 「だれかと」対戦 任天堂のサーバでマッチングが行われ知らないだれかと対戦する レーティング機能があり強い人のレートは高くなる 「専用部屋」対戦 いわゆるロビーを作成しフレンドを呼んで好き勝手に対戦する ロビーには最大8人まで参加でき対戦していないときは他のフレンドの対戦を観戦できる 結論 NTT東日本フレッツ光＆インターリンクの場合ネットワーク内のMTUを1454にしないと接続状況が著しく不安定になりニコニコ動画をはじめ一部のサイトはそもそも閲覧できなくなる IPv6接続には「IPoE（ネイティブ）」と「PPPoE」の2種類があり本命は「IPoE」 インターリンクはどちらのIPv6接続方式も提供しているが「IPoE」の場合はオプションサービスとなっている 「PPPoE」接続でIPv6環境を実現しようとする場合はその仕様上ルータをYAMAHA RTX等のエンタープライズ利用に耐えうる機種に置き換える必要がある インターリンクの「PPPoE」版IPv6接続は無料で利用可能だが仕様上ルータの買い替えが必要となった UPnPはセキュリティの課題があるプロトコルであるし家庭ではまず使わないので無効にする HWでのNATは無効化したほうがいいらしい…確かに家庭用ルータはHWスペックが低そうだからオフロードさせない方がいいのかも（程度は不明だが速度は上がった） WAN側からのPingは応答するようにした方がいいらしい…固定IPを引いている訳では無いので許可してみた（程度は不明だが速度は上がった） ほんとかどうかわかんないけどSwitchの有線接続の場合Cat7よりCat6の方が逆に性能が出るらしい… 逆にノイズが乗るらしい …なるほど 現状 有線接続で混雑時間帯でも60Mbps程度は出力されているの...

表題の通り AWS Summit Tokyo 2019 の Day3 だけ行ってきました。 3日間行きたかったけど都合つかず…。 企業ブースには寄らず、講演拝聴スケジュールを詰め込んで、合間にAWS認定資格の保有者しか入れない「認定者ラウンジ」に入ったりした程度で、かなりミニマム（かつギッシリ）な感じの1日でした。 こんな感じの拝聴予定でした。リンクはそれぞれの発表資料 or 他者さまのまとめとなっているのでいい感じに飛んでいただけると思います。(ほとんどクラスメソッドさんのまとめですが公式資料が出たらそっちに切り替えます) ------------------------------------ 6月14日 10:00-11:30 　 基調講演 ------------------------------------ 6月14日 12:00-12:40 　 メルカリ写真検索における Amazon EKS の活用事例 ------------------------------------ 6月14日 13:00-13:40 　【仮】来たるべきAI時代のための「イケてる」データ基盤の作り方 ------------------------------------ 6月14日 14:00-14:40 　 Deep Dive DynamoDB ------------------------------------ 6月14日 15:00-15:40 　 ロマサガRSの大規模トラフィックを捌くAmazon ECS & Docker運用の知見 ------------------------------------ 6月14日 16:00-16:40 　 めざせ！サーバレスプロフェッショナル ------------------------------------ 6月14日 17:00-17:40 AWS   & Alexa Automotive : Worldwide Automotive industry trends ------------------------------------ 13:00 - 13:40 のだけ会場がわからず（なんか地図持ってなかった）の...

自分のためのメモの意味合いが強いです。 時系列で書いてみます。 それまでの自分 AWS歴は4年ほど EC2とかELBとかRDSとかのいまどきの「サーバーレス」っぽくない基本のプロダクトを業務でよく使っている 最近はWAFとかSAMとかいじってる ACMがDNS認証可能になってRoute53に勝手にレコード書いてタダでソッコーSSL証明書が入手できるのはほんといい時代だなーといつも思っている アプリのコードは書いていない 運用自動化のコードはマイペースに書いている 今の会社に転職する前に当時のAWS本を何冊か読み漁りあとは Developers.io や Qiita や公式ドキュメントで自分なりに学習してそれを業務で試す日々 Developers.io はメッチャお世話になっておりますクラスメソッドのみなさん本当にありがとうございます 40日前 受験を決意 公式の模擬テストを受けたんだけど ソリューションアーキテクト アソシエイトを合格したご褒美として無料 だった さらに 本番の試験費用もご褒美として半額になるクーポンが利用可能だった 模擬テストは全部画面キャプチャして見返せるようにした 模擬テストは受けた直後に結果がメールで届く 模擬テストの総合スコアは75%だったので頑張れば受かるぞという気持ちになった 39日前〜10日前 平日はふつーに仕事してた 仕事が結構大変で全然勉強できてなかった 休日は疲れを癒すのでわりと精いっぱいだったので全然勉強できなかった 7日目〜前日 GWに入ったので勉強のチャンスだった GW前までは仕事して気分転換にお酒飲んでゲームして寝るような日々が多かったのでなかなかスイッチを切り替えられなかった 毎日1時間ずつ増やしていった。1日目1時間、2日目2時間、3日目3時間みたいな…。 模擬テストのキャプチャを見返してSQSの知識が足りてなかったからSQSの公式ドキュメントを順番にたくさん読んだ 2日前からSQS以外のサービスについて「軽くは知ってるよ」レベルになるように学習対象をリストアップしてそれらについて各種ドキュメントを読んだ Code*系のサービスをもっと学習しておけばよかったなと思ったけど間に合わなかった Nintendo SwitchのFi...

自分のためのメモの意味合いが強いです。 時系列で書いてみます。 それまでの自分 AWS歴は3年半ほど EC2とかELBとかRDSとかのいまどきの「サーバーレス」っぽくない基本のプロダクトを業務でよく使っている ACMがDNS認証可能になってRoute53に勝手にレコード書いてタダでソッコーSSL証明書が入手できるのはほんといい時代だなーといつも思っている アプリのコードは書いていない 運用自動化のコードはマイペースに書いている 今の会社に転職する前に当時のAWS本を何冊か読み漁りあとは公式ドキュメントで自分なりに学習してそれを業務で試す日々 40日前 受験を決意 二千円払って公式の模擬テストを受ける 模擬テストは全部画面キャプチャして見返せるようにした 模擬テストは受けた直後に結果がメールで届く 模擬テストの総合スコアは84%だったので安心する 39日前〜10日前 平日はふつーに仕事してた 帰宅後スイッチ切り替えのため30分だけスマブラしたりしてた お酒飲みながらいつもより多めにAWS公式ドキュメントを読んだりした 週末に読みたい記事をTodoistにToDoとしてメモした TodoistはURLを貼ると記事名に変換されそれがタスクになるので便利 画面キャプチャの問題文を読み直しよくわかっていないプロダクトや単語をピックアップして自分の重点学習項目とした 多分1日30分 ワイヤレスイヤホンを買ったので皿洗いをしながらEFSのBlackbeltの動画を流して聞いたりした…2周したけどおかげで知識ゼロからだいぶ増えた 試験は平日にしか受けられなかったので会社に「AWSの試験受けてくるので休みます！」宣言をして許可と応援をもらった 10日目〜前日 週末の日中帯は部屋でずっとドキュメント読んでた Redshiftを業務で使ったことがなかったのでクラスメソッドさんのRedshiftの記事から新しい順に10本読んだりしてその記事に貼られている公式ドキュメントも読んだりした 1週間前から禁酒を開始して最後まで飲まなかった 英語オンリーっぽいけどAWSの公式ラーニングサイトで勉強動画見放題なのに気づいてすげーってなった 当日 テストセンターでの受験 米国（ホントかわかんない...

タイトルの通りです。 あ、 この記事は AWS初心者 Advent Calendar 2018 の7日目 として書いております。 最近会社でWAFとかLambdaとかSAMとかちょっとEC2やRDSといった基本のプロダクトとは違った要素について検証・導入を行なっているのですが、Lambdaをデプロイするために使ってみたSAMでWAFをデプロイすると楽ちんでした。 たとえばここに、HTTPリクエストのメソッドの種別を確認し、HEAD、CONNECT、TRACEを利用したアクセスをブロックするようなWAFを作成するためのSAMテンプレートがあります。 これが存在するディレクトリで以下のようにパッケージングのためのコマンドを実行します。 あ、念の為に雑多なディレクトリではなく、このテンプレートだけが存在する新しいディレクトリを作成してください。 aws --profile [プロファイル名] cloudformation package --template-file template.yml --s3-bucket [あらかじめ用意したS3バケット名] --output-template-file packaged-template.yml これを実行することで、SAMでのデプロイのためにパッケージング化された各種ファイルが指定したS3バケットに送られ、そこからデプロイするために書き換えられた packaged-template.yml が生成されます。 Lambda Functionのためのソースコードがあればここで併せてパッケージング化されるのですが、今回は無いのでtemplate.ymlだけですね。 そして以下のコマンドを実行するとデプロイされます。 aws --profile [プロファイル名] cloudformation deploy --template-file packaged-template.yml --stack-name otameshi-http-method-restriction-for-cloudfront --capabilities CAPABILITY_IAM --parameter-overrides yourApplicationeName=[任意の文字列] コマンド名に...

結論 結論から言うと API Gateway でした。 ACMで発行したSSL/TLS 証明書を シームレスに他のAWSプロダクトで利用することが可能なのですが、その時に内部動作としては規定のアカウントIDでCloudFrontディストリビューションが生成され、そのディストリビューションに対して証明書が適用されるようです。 直面した問題 AWSでのシステム運用にあたり、それなりの数のドメインを運用しているのですが、基本的にはACMにて発行した証明書を利用しています。 以前はメール認証しかできず、きちんと環境を整えてあげないと自動更新に失敗することもあり、DNS認証の同一ドメインの証明書を別に発行し、そちらに切り替える作業を行なっていました。 ACMで発行した証明書はAWSコンソール上から簡単にELBやCloudFrontといったAWSプロダクトに利用することが可能なのですが、証明書を削除する際には全てのインスタンス・ディストリビューションから利用を解除する必要があります。 「あとはどの子（インスタンス）が使っているのかな〜？」と確認したところ、 arn:aws:cloudfront::969236854626:distribution/ABCDEFGHIJKLMN のようなCloudFrontディストリビューションが利用していることがわかりました。 969236854626 の部分が自分のAWSアカウントIDになりますが、私が利用しているアカウントのIDは全然違います。 対策 「えっ…？」と思いましたが調べたらすぐに解決。 答えはこちらに書いてありました。 エッジ最適化のカスタムドメイン名を作成する方法 - Amazon API Gateway  https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/how-to-edge-optimized-custom-domain-name.html API Gatewayにカスタムドメインを割り当ててHTTPSを利用させたい場合に、AWSは特定のIDでCloudFrontディストリビューションを内部的に自動で作成し、そのディストリビューションに証明書を関連づけるのでした。...

スレッドダンプとは スレッドダンプとは何なのでしょうか。 スレッドのダンプ…JavaのスレッドはJavaを実行する際の実行単位というか、処理の流れの1つのこと。 それのダンプ…ダンプとはあるOSやプログラムのその時の状況を丸ごと取得してファイルなどに出力したもの。 なのでスレッドダンプとはJavaプログラムのある時点での処理状況をダンプとして取得したものになります。 スレッドダンプについては下記などがとても参考になりますのでご参照ください。 (参考) » 「うわっ…私のアプリ、遅すぎ…？」 スレッドダンプでJavaアプリケーションのボトルネックを調査しよう TECHSCORE BLOG http://www.techscore.com/blog/2016/02/05/%E3%82%B9%E3%83%AC%E3%83%83%E3%83%89%E3%83%80%E3%83%B3%E3%83%97%E3%81%A7%E3%83%9C%E3%83%88%E3%83%AB%E3%83%8D%E3%83%83%E3%82%AF%E3%82%92%E8%AA%BF%E6%9F%BB%E3%81%97%E3%82%88%E3%81%86/ あなたとスレッドダンプ - スレッドダンプ入門 - この国では犬が http://enk.hatenablog.com/entry/2014/09/22/001303 スレッドダンプツールについて jstackというツールがあり、これを利用してスレッドダンプを取得するのが一般的なようです。 どこの記事を読んでも出てきますし、下記のAdobeの技術記事（2017年10月更新）でも利用されているのでjstackを利用しておけば間違いありません。 (参考) JVM からのスレッドダンプの取得 https://helpx.adobe.com/jp/experience-manager/kb/TakeThreadDump.html インストール方法 普通はJavaを実行しているマシンにはだいたいjstackがインストールされているようなのですが、私が運用しているサーバには入っていなかったので入れてみました。 既存のJDKのインストール状況確認 $ rpm -qa | grep jdk ...

オリジン間リソース共有 (CORS)という技術があります。 ドメインAのWebページを表示する際に、一部のコンテンツをドメインBから取得してそれを表示したいといった場合に利用する必要があります。 それは最近のWebでは割とありふれたことだと思います。 なので意識せずともかなりの頻度で利用されているのではないでしょうか。  先日業務でCORSを意識した問題に直面してしまったこともあって、一度きちんとした技術文書を読んだ方が良いと思い、Mozillaが提供している MDN web docsの丁寧なドキュメント を読んでみました。 CORSまとめ WebブラウザがドメインAのページを取得したいが、ドメインAのそのページはドメインBのコンテンツを含むといった場合に、ドメインAのサーバはドメインBのコンテンツを取得して自ページのコンテンツの一部としてWebブラウザに返さなければいけない その時に利用される技術がCORS CDNで画像やスタイルシートやフォントやスクリプトを配信している昨今ではかなりの頻度で利用されていると思われる 基本的にはHTTPヘッダに所定の内容をクライアントとサーバが用意することで成り立つ CORSができるかどうかを確認するために「プリフライトリクエスト」という事前HTTPアクセスが必要である 「プリフライトリクエスト」はOPTIONメソッドで行われる…GETやPOSTではない 「プリフライトリクエスト」が発生しない「単純リクエスト」というCORSリクエストもあるが該当条件が厳しい 特に世の中に多そうなcontent-typeが「text/html」のページは単純リクエスト対象外なので基本的にはほとんどのCORSでプリフライトリクエストが発生すると考えた方が良さそう プリフライトリクエスト時にクライアントから発送される「Access-Control-Request-Method」にはプリフライト後の本来のリクエストでどのメソッドが使われるかが書かれている 同様に「Access-Control-Request-Headers」には次に行われる本来のリクエストでどのようなヘッダが送信されるかについて書かれいる プリフライトリクエストを処理するためにサーバ側（CORSで一部コンテンツを提供するドメインBのサーバ）...

自分が送ったコミットを特定のブランチ（今回はstaging）にマージしてくれと言われて対応した時のメモ。 まずこうやってリポジトリを clone して hub am −3 コマンドを使ってマージしようとした。 git clone git@github.com:(team name)/(repository name).git cd (repository name) git checkout staging hub am -3 https://github.com/(team name)/(repository name)/pull/(pull number) 認証失敗 そしたら hub am -3 コマンドが認証失敗になりうまく動かない。 $ hub am -3 https://github.com/(team name)/(repository name)/pull/(pull number) Error getting pull request: Unauthorized (HTTP 401) Bad credentials 色々調べたけど結論としては ~/.config/hub に書いてある認証情報が古かったので消すと認証の再要求が発生して解消した $ rm ~/.config/hub $ hub am -3 https://github.com/(team name)/(repository name)/pull/(pull number) github.com username: hub am -3 コマンドでマージしようとしたらコンフリクト $ hub am -3 https://github.com/(team name)/(repository name)/pull/(pull number) Applying: (this is a comment of commit) Using index info to reconstruct a base tree... M circle.yml Falling back to patching base and 3-way merge... Auto-merging circle.yml CONFLICT (content): Merge con...