５社同時に働いてみて分かったこと
来るもの拒まずで全力でアクセルを踏んでみた週３で外部に出て、週２で自社の仕事をする、という感じでトントンで回しています。 何か案件があれば、適当に声を掛けていただけると遊びにいきます(有償) 前回の記事に、上記のようなことを書いておいたら、気づいたら案件が増えていくわけですね。 現在は、開発案件１、機械学習案件１、コンサル案件２、ゲームディレクター１、記事執筆のライター案件２、といった感じです。隔週で行っているところもあるので、最近は、週4.5日程度外部に出稼ぎに出ています。 あとは今月はとあるコンテスト審査員（守秘義務でにゃーん）の案件がスポットで入っています。 それから自社の開発がちょろちょろ。 基本は毎日客先に行っているストレス度ゼロのフルパワー勤務5＋αの会社で同時に働いているわけですが、このような働き方をしているとどうなるかというと、仕事をいただいている会社から「難易度が高いが、
GitHub に AWS キーペアを上げると抜かれるってほんと？？？試してみよー！ - Qiita
🤔 前書き 稀によくある 、AWS を不正利用されちゃう話、 AWSで不正利用され80000ドルの請求が来た話 - Qiita 初心者がAWSでミスって不正利用されて$6,000請求、泣きそうになったお話。 - Qiita AWSが不正利用され300万円の請求が届いてから免除までの一部始終 - Qiita ブコメ等で GitHub にはアクセスキーを検索するBOTが常に動いていて、公開するとすぐに抜かれて不正利用される 的なコメントがつくのを何度か目にしたのですが、 本当にそんな BOT が動いているの？ どのくらいの時間でキーを抜かれて、不正利用が始まるの？ というのが気になったので、検証してみました。 GitHub にそれっぽいパブリックリポジトリを作成、権限が一つもついてない AWS のアクセスキー＆シークレットアクセスキーをうっかり公開、外部から利用されるまでの時間を計測します。
LinuxサーバでネットワークI/Oで刺さっている接続先を発見する - ゆううきメモ
Linuxサーバの障害対応で社内で伝統的に使われているテクニック。I/Oで完全にブロックしているポイントを特定するノウハウ。 問題対応のため、怪しいプロセスをstraceしてみる read(2)やwrite(2)でブロックしていることを発見する read(2)やwrite(2)、connect(2)の引数にはファイルディスクリプタ番号がみえる プロセスIDとファイルディスクリプタ番号を使って、/proc//fd/ の中身をみると、ソケットI/Oで刺さっている場合はソケット番号を発見できる netstat からソケット番号でgrepして接続先を発見する [y_uuki@hogehoge ~]$ sudo strace -p 10471 Process 10471 attached - interrupt to quit read(58, <unfinished ...> Process 10
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
