タグ

2022年2月7日のブックマーク (5件)

  • セブに移住しようとしたが、色々あって長野にログハウス借りて住んでる人の話 | DevelopersIO

    2020年8月に住み慣れた東京を離れ、八ヶ岳の麓にある長野県富士見町へ移住しました。そこに至るまでの経緯や実際にやってみて感じたことなどを書きたいと思います。 この記事は「いつかどこかへ移り住んでみたい」と考えはじめている人向けの内容です。技術的な話は全く出てきませんがご容赦ください。 やらずして後悔するよりやってみるべし 私は東京生まれビーバッブ育ちの40代、生まれてこの方ずっと東京都民として暮らしてきました。30代後半に差し掛かったあたりで「もう東京でやりたいことないな」と思いはじめ、漠然と別の土地で暮らしてみたいと考えるようになりました。 ですがプロマネという職種の性質上、お客様と対話してナンボの世界で、多くのクライアントがある東京を離れる=ジョブ的な死を意味する、というのは少し言い過ぎにしても、仕事で価値を出せなくなってしまっては末転倒、なかなか踏み込めずにいました。いや今思えば

    セブに移住しようとしたが、色々あって長野にログハウス借りて住んでる人の話 | DevelopersIO
    clairvy
    clairvy 2022/02/07
  • ソフトウェアテストで参考にしている67のモノ 2021 #scrumniigata|kyon_mm

    ソフトウェアテストの学び方に関して書籍やウェブサイト、そしてそこから伸びる某かについて自分なりにまとめ直してみるかーと。思いました。これを全部読めとかではなくて、まぁ自分が今まで読んできて役に立ったものリストくらいの感じです。 また、このリストの解説をスクフェス新潟でプレゼンしたいと思い公募に出しました。リンク先でLikeしてもらえるとプレゼンできる確率が上がるのでよければぜひ押していってください。 ソフトウェアテストで参考にしている67のモノ #scrumniigata https://confengine.com/conferences/scrum-fest-niigata-2022/proposal/16369/67 まずは、リストを。後半に各カテゴリの所感とかを。 発端は先日、Twitterでリプライをいただいて、7年近く前に「テストエンジニアの品格」という煽ったプレゼンをしていた

    ソフトウェアテストで参考にしている67のモノ 2021 #scrumniigata|kyon_mm
    clairvy
    clairvy 2022/02/07
    入れたいものがあって、途中からコンテキストがジャンプする感じはした。監視辺りから
  • JavaScriptの演算子の優先順位と「禁止ルール」の一覧

    ただし、種別は以下の通りです。 prefix (前置演算子) …… もとの式の手前に何個でもつけられる演算子。 例: -~-~x postfix (後置演算子) …… もとの式の直後に何個でもつけられる演算子。 例: x.foo()`bar`[0] postfix once …… もとの式の直後に1個だけつけられる演算子。 例: x++ は可能だが x++-- はパースされない。 逆に ++--x はパースされるが、構文とは別のルールで禁止される。 (後述) infixL …… 中置演算子で左結合 (演算子の優先度が同じ場合は左側にあるほうが優先される) 例: 0.1 + 1.0 - 1.0 は (0.1 + 1.0) - 1.0 になる infixR …… 中置演算子で左結合 (演算子の優先度が同じ場合は右側にあるほうが優先される) 例: 2 ** 2 ** 3 は 2 ** (2 **

    JavaScriptの演算子の優先順位と「禁止ルール」の一覧
    clairvy
    clairvy 2022/02/07
  • 1年、3年、13年、17年ごとに課金が発生し、100年持続する法要という古来から続くサブスクシステム

    Miyahan @miyahancom MSP事業者で監視システムの運用や業務標準化・自動化をやっています。今後は運用設計をやっていきたいけど学がない。体重2桁死守。 / ex 大手通信会社で壊れたルーターを取り替えるだけの夜勤作業員 miyalog.hatenablog.jp

    1年、3年、13年、17年ごとに課金が発生し、100年持続する法要という古来から続くサブスクシステム
    clairvy
    clairvy 2022/02/07
  • 「Rustでやると知らないうちに詰む設計」を避けるためのTipsを集めてみる

    とりあえず、よく言われてるやつから埋めていこうと思う。 構造体にライフタイムを持たせない 構造体にライフタイムを持たせるのは「基的に」避けよ、というのが重要なのは間違いないのだけど、これをもう少し実践的な内容にしたい。ちょっと考えてみたけど、こういうのはどうだろうか。 ある関数呼び出しの中でしか絶対に使わない。returnするまでにその構造体のデータは全て破棄される。static変数に退避させることもできない。アロケーションもその関数が面倒を見る。そういう一蓮托生できる関数呼び出しに心当たりはあるか? ある→ 構造体にライフタイムを持たせてもよい。 ない→ ライフタイム禁止。 そう考えてみると、DIとかReduxとかとも通じるところがあるかもしれない。「つべこべ言ってないで全部の責務を一番外側に持っていく」という決断ができるときは構造体ライフタイムが選択肢に入る。

    「Rustでやると知らないうちに詰む設計」を避けるためのTipsを集めてみる
    clairvy
    clairvy 2022/02/07