2016/08/16 この記事は書かれてから1年以上が経過しており、最新の情報とは異なる可能性があります techChefAnsible 前の記事の WordPress を捨てて Hugo に移行した よりも前に、 ずいぶん前に “Chef を捨てて Ansible に移行” していたのですが、 書いておかないと忘れるので自分用にメモしておきます。 プロビジョニングツールを使い始める前の自分Chef を利用する前は、 いわゆる プロビジョニングツール というのものを一切使っておらず、 サーバの構築はそのマシンでうまく行くまで何度も行う、 トライアンドエラーのようなサーバ構築を行っておりました。 こういうのって、ちゃんとコマンドラインで入力した内容をメモるなりして きちんと手順化していかないと、 すぐに忘れたりして環境の再現ができなかったりするんですよね。 最初は実機に対して直接作業を行うこ

ペパボ研究所客員研究員の力武健次（りきたけ・けんじ）です。この記事では、ここ10年ほど力武が研究対象の1つとしてきた、コンピュータで扱うランダムネス（乱雑さ）と物理乱数の扱い方について述べます。（文中敬称略） コンピュータとランダムネスは相性が悪い ランダムネス（randomness）は日本語では「乱雑さ」と訳され、一切の法則性を持たず、予測が不可能な状態のことを指します。コンピュータは基本的に人間がプログラムした通りに動き、それ以外の動作をしないことが前提となっている機械ですから、ランダムネスから最も遠い存在です。 しかし、あらゆるものが事前にプログラムされ、予定調和となっている決定的なアルゴリズム手法だけでは、現実の問題には対応できません。いくら周到に準備しても予定外や想定外のことが起こるのは不可避である以上、これらに対して可能な限り備えてプログラムを書く必要があります。そのためには、

今週のお題「家飲み」 はてなブログにはお題ボタンというものがあり、一週間ごとに記事のお題が設定してある。別に書いても書かなくても良いのだが、これは俺の得意分野なので書く。 俺は家で普段ウィスキーを飲み、奥さんは家で普段ビールを飲む。 皆に聞きたいのだけど、エヴァンゲリオンのミサトさんの家の冷蔵庫を思い出してほしい。ビールでいっぱいである。あれを見て何を思うだろうか。酒好きなんだろうなあ、って、そういう感想だろうか。いや、もちろん酒好きなのだろうが、同時に俺はミサトさんの意思の強さを感じずにはいられない。だらしないようにみえて、さすがは職業軍人である、と思わずにはいられない。なぜなら、もし我が家の冷蔵庫があのような状態になっていれば、我々は冷蔵庫にあればあるだけ酒を飲んでしまうからである。 冷蔵庫に500mlロング缶が2本あれば、翌日には無くなっている。ロング缶が4本あれば、翌日には無くなっ

Firebaseでプロダクトを作ってたけど、色々キツくなって、やはりAWSに乗せ替えたいという話をよく聞く。 EC2の上に普通にアプリケーション組んでRDSにデータを移行すれば済む話だが、Firebase Authenticationのデータ移行ができない問題にぶち当たる。 どういうことかと言うと、パスワードがハッシュ化されてるから、移行後に全員にパスワードリセットさせないといけなくなるということだ。 しかし、これはよくある勘違いで正しくない。 Firebase Authenticationのハッシュアルゴリズムやパラメータは知ることができるので、同一アルゴリズム・パラメータでハッシュ計算をしてあげれば、パスワードリセットをさせることなくパスワード認証をすることができる。 パスワード認証を一度通した後に新しいハッシュアルゴリズム・パラメータでハッシュ計算し、以降はそのハッシュ値を認証に用い

FirebaseのFirestoreをやめることにしたので雑なメモを残しておく。なお、まだ走り始めたばかりなので、内容には間違いや考慮不足も多数含まれる可能性があるので読む人はその点注意を。あと、あくまでも雑なメモなので細かいところは書いていない。 なぜ脱Firestoreするのか？ なぜGraphQLではなくREST APIなのか？ 移行にあたって検討したこと、決め事 ドキュメントIDをどう扱うか サブコレクションをどう扱うか 配列やマップといったフィールドのタイプをどう扱うか 追記: Mapの配列をどうするか Firebase Authenticationとセキュリティルールで実現しているセキュリティ機能をどうするか では実際にどんなテーブル設計にするのか 次にやること なぜ脱Firestoreするのか？ まず、脱Firestoreする理由は ユースケースとしてFirestoreでは対

はじめに ヘルステックスタートアップのUbieに転職してから3ヶ月が経過したので、転職のきっかけや実際に入社して感じたことなどを書き連ねました。いわゆる入社エントリというやつです。 転職の経緯 前職ではDMMでSREをやっていました。特定のサービスに限定した活動ではなく、組織全体に関わるチームに属し、様々な部門に対してクラウドマイグレーションやインフラの改良、SRE文化の普及といった活動をしていました。DMMは50以上の多種多様なサービスを運営しており、新規事業の立ち上げ時にインフラ設計を行ったり、既存のレガシーインフラを改善するなど、多岐にわたる経験ができたことは大変有意義でした。 一方で私が所属していた部署では「このサービスのこの部分を改善してほしい」といったスポットでの関わりが多く、もう少し長い目線でプロダクトや基盤を育てていきたいという気持ちがありました。そんな折に登録していた転職

こんにちは大櫛です。Travis CIがオープンソースプロジェクトで使いづらくなったり、Azure PipelinesからGitHub Actionsになった途端*1爆発的な流行が生まれたりと、CIサービスにおいてもここ数年で色々な動きがありました。 特に技術記事・ブログのトレンドや企業のリクルート向け資料を見ていると、GitHub Actionsの利用が進んでいるような印象を受けます。 今回はそんなGitHub Actionsについて、Rust projectで使う際に知っておいた方がいいことやactionを紹介していきます。 以下の情報は執筆時点（2023-02-19）のものに基づいています。閲覧時には無効・誤ったものになっている可能性がありますので、必ず最新の情報・状態を確認するようにしてください。 actions-rs（非推奨） まずはじめに、執筆時点では使用を控えた方がいいact

概要 知的労働者にとって作業環境は重要です。 良い機材にはお金をかけても効率が上がればすぐに回収できます。早く買えば、利用した日数で金額を割ると日割り金額が低く済みます。 ということで、私がトライアンドエラーしてたどり着いたデスク環境を紹介するので参考にしていただければと思います。 身体に触れる部分である、デスク、チェアー、モニタ（視覚的に）には良いものを使いたいという思いが強いです。 ユースケース定義 デスクで何をするかを考えます。 仕事: プログラミング、設計図書く、文書を書く、音楽を聞く、テレカンをする、写真のレタッチ。 趣味: 電子工作 要求定義 上記のユースケースを実現するための要求は以下になります。 電動の昇降機能付きデスク 音質が良いスピーカー ノイズが少なくて指向性のあるマイク 良い感じのWebカメラ 長時間座っても疲れにくい椅子 長時間使っても疲れないモニター。解像度が高

こんにちは。五所です。 最近は時代についていこうと、フロントエンドの情報収集をしています。 React, Redux, AngularJS, ES6, Webpack, Gulp, Babel, Yarn... 情報収集すればするほど、頭がいっぱいになるのですが、その過程で感じたこと、考えたことをつらつら述べさせて頂きます。 Vue.jsについて github.com Vue.jsは近年非常に盛り上がりを見せているJavaScriptのフレームワークです。 特に2016年にすさまじい勢いで伸びました。 GitHubのスター数は2016年だけで26400獲得し、2017年1月21日現在では40000スターを超えています。 risingstars2016.js.org Vue.jsは the 10th most starred JavaScript project on GitHub the

こんにちは。 マネージャーのnakayanです。 今回は、マネージャーとしての立場で思うことを綴ってみたいと思います。 私は新卒で入社して元々は営業職でした。 そもそもPCやシステムのことは全くわからず、『OS？』『ブラウザ？』みたいなレベル。。。 一番の衝撃は、Web上で表示されているページが絵ではなく文字であるということ。 正直『(　ﾟдﾟ)？？？』という感じです。 そんな私が、いつの間にやらWebマーケターになり、UI設計を行い、徐々にシステムに関わるようになりました。 データベースのことも分からないし、プログラミング言語も何もわからない… そんな中、中途入社・新卒入社を含めて本当に優秀で志の高いメンバーが集まっています。 各メンバーが、チームをどう作り上げていくか、組織をどう変革していくのか。 また個人としてのスキルをいかに高めていくのか。 常に向上心を持ってITの力で貢献し、変革

何をやってもヒールサイドターンがズレる ヒールサイドターンはズレやすい。僕は、ずーーっとズレてます。ここ数年は、トゥサイドが良くなったので、トゥサイドで減速できなかった分をヒールサイドでカバーする必要がなくなり、ヒールサイドのズレは少なくなりました。 しかし、正直まだズレてます。カービングではなく、まだズレの少ないターンです。 トゥサイドのこともあり、何をやってもズレるので嫌になって、「スノーボードなんかやめてやる！」、「つまんない！」と思ったことが何度もありました。 悪循環はこうして始まった ズレの原因はヒールサイドターンのはじまり、つまり切り替え期に、エッジを立てようとすればするほど、エッジが立たない動きをしていたということです。 スノーボードを始めた頃からずっと、ヒザを曲げて、腰を落としてというように言われてきました。雑誌のヒールサイドターンの写真を見ても、ヒザが曲がって、腰が落ちて

いやー、これがなかなかうまく動くまでが試練の道だった。自分の技術的な知識を大幅に超えた世界を1人で歩いている感じで、なにか壮大な勘違いをしながら歩いている気が今でもしている。まぁ動いたからそれでいいんだけど…。 必要なときだけ取り出してスイッチを入れればBluetoothで即接続してテンキーが使える環境を望んでいたのだけど、Amazonを見たら割と価格にびっくり。なんと2,000円くらいから普通に存在していたのかっていう。でもあれです。好みのキースイッチを使えない。キーレイアウトを変えられない。キーカスタマイズはほぼ皆無。っていうことになるし、何よりも自分で作った感がうれしいから多少高くてもいいじゃないのって自分に言い聞かせる。 調べていると、なんとAttack25がBluetooth対応版もあるじゃない！唯一、これしか見つからなかったので何も考えずにポチッと。 ※ProMicroは仕入れ

年の終わりに 今日は仕事納めだったので、少し今年を振り返るためにも記録を一つ。 タイトルの通り、今年は「なにもしないこと」の大切さと、難しさを痛感した一年だった。 今年は転職して、スタートアップ企業でエンジニア兼テクニカルマネージャーとして働いている。特にスタートアップというのは立ち上げ期は非常に忙しい。 エンジニアとして仕事をしている期間は、自分の人生の中では比較的長いのだけれど、ソフトウェアエンジニアというのは知能労働と言われるだけあって、脳疲労が大きいと感じている。オフィスワークやリモートワークによる運動不足も相まって、他の職業よりも脳疲労は深刻であると思う。 自分はその脳疲労の軽減のために数年に渡ってマインドフルネスを実践しているのだけれど、今年はその大切さと難しさを同時に実感した一年だった。 （なお、脳は疲労しないと一説ではいわれているのだけれど、ここではわかりやすさのために脳疲

前の記事で、考えないことの大切さに言及したのだけれど、さらにジャッジしないことはもっと大事だと思う。 確か同じタイトルで以前記事を書いたことがあるように思うのだけど、それでもあえてまた書くのは、ジャッジしないということは意識をしていないととても難しいから。 物事の多面性と、言葉の二面性 例えばなにか悪いことが起こったりすると、つい「今日は最悪だー」とか、「これは不吉な予感だ」とか思ったりする。 逆もそうで、優秀な同僚がいたら、「優秀」という言葉が物語っているように、良い悪いというレッテルを貼る。 こうして、本来多面的である物事に、だんだんとわかりやすい二元論的なレッテルをつけて管理をしていく。これがジャッジするということ。 頭で考えるというのは、論理的に考えやすい単位に物事を整理していくということで、だんだんと物事を単純化して考えていく。 思考整理をしているときは、各事象が多面的であるとい

はじめに 2022年8月25日に、Herokuが無料プランを終了することを発表しました。 blog.heroku.com また、9月26日には前回のアナウンス時にはなかった、低コストプランが発表されました。 blog.heroku.com いずれの内容も英語なので、日本語で要点をまとめてみます。 また、エントリの後半では無料プラン終了後の個人的な移行方針についても書いてみます。 おことわり このページの情報は2022年10月4日時点の情報です。時間が経つと情報が古くなっている可能性があります。 また、内容の正確性は保証しないので、正確な情報を知りたい場合は上記ページを参照してください。 8月25日に発表された無料プラン終了のまとめ 2022/10/26から1年以上活動のないアカウントとそのストレージを削除する 2022/11/28から無料プランの提供を停止し、無料Dynoと無料DBの稼働を

DeepMindの深層強化学習による核融合炉制御論文を読んだので論文内容と論文を理解するために調べた技術背景をまとめます。 Accelerating fusion science through learned plasma control www.nature.com 要約 技術背景：核融合炉の仕組み 核分裂エネルギーと核融合エネルギー 核融合反応のおこしかた トカマク型磁気閉じ込め方式 深層強化学習によるトカマク型核融合炉の制御 研究者はさまざまなプラズマ形状の特性を探索したい 課題：目標形状ごとに磁気コイル制御システム構築するのがつらい 提案：深層強化学習で任意形状の制御を実現する 制御ポリシーのトレーニング Sim to Real 分散並列強化学習 MPOアルゴリズム 即時報酬rの設計 実機へのデプロイ 性能検証 所感 ※筆者は原子物理/核融合理論について完全な素人であり当該分野の

任天堂97カップの歴史は、原作の世代から、 幾度も吹雪という名の天災に見舞われてきた歴史…。 今こそ話そう。ここ1年で（初代VCに）何があったのかを。 最強の技《吹雪》を中心とする新たな強弱関係 1997年に開催された第1回ポケモンリーグ任天堂公式トーナメントを再現したGBコロシアム通信対戦のニンテンドウカップ'97の対戦環境で象徴的な技は、吹雪である。登場当初の吹雪は命中率90%、30%の確率で凍り状態の追加効果の大技であり、おまけに当時の凍りは通信対戦中では、相手から火傷状態の追加効果の発生する攻撃技か、黒い霧を受けない限り、回復手段がなく、瀕死と違って場から自動的に退場しないため、凍りのままでは相手の積み技の起点となってしまいやすい。吹雪の凍りを遮る手段は氷属性を持ったポケモンのみ。 ヒストリアカップ開幕直前の対戦環境 当初は吹雪の凍りをあまり深く考慮せずに組んだ人が多かったため、単

はじめに 「登録する」という意味でregistと書くのがあるあるなのかは分かりませんが、色んなプロジェクトで色んな人が書いたコードを見ても、結構registが使われていました。 英語的には誤りであり、registという単語は存在しません。正しくはregisterです。ではなぜregisterではなくregistが使われているのか、そう書いた人ひとりひとりを捕まえて「あなたはなぜregiterではなくregistと書いたのですか？」とインタビューすることはできないので、勝手に推測しています。 registerではなくregistを使う理由を推測 -erが動詞っぽくないから 個人的には一番それっぽい理由だと思います。 registerはまぎれもなく動詞なのですが、-erという接尾辞が「～する人」ということを表すので、-erを抜いたregistが「登録する」ということなのだろう、と思ったのではな