2022年6月5日のブックマーク (9件)

  • 馬に関する素朴な疑問「立ったまま寝る理由」と「蹄鉄が必要な理由」を解説! - ナゾロジー

    立ったまま寝るのはなぜ? 走る子羊 / Credit: Pixabay 隠れず、逃げて敵から身を守るため 私達が馬の睡眠姿をあまり見たことがないのは、馬の睡眠は『立ったまま、短時間であること』が理由です。 『立ったまま寝るなんて、とても珍しい動物だ!』と思われるかもしれませんが、実はそうでもありません。 馬以外にも、キリン、ゾウ、ウシ、ヒツジ等も、睡眠時間のほとんどを立って過ごします。 では、これらの動物はなぜ立ったまま寝る生存戦略を取っているのでしょうか? それは、彼らの共通点を見つけると分かります。 彼らは『比較的身体が大きい、草動物』です。 まず『身体が大きい』=『隠れる場所が、あまり無い』ということです。 次に『草動物』=『腹ペコの肉動物から逃げる必要がある』ということです。 つまり、『肉動物という天敵がいるが、身体が大きくて隠れられる場所があまり無いため、すぐ逃げられるよ

    馬に関する素朴な疑問「立ったまま寝る理由」と「蹄鉄が必要な理由」を解説! - ナゾロジー
  • VSCode のリモートコンテナ機能を用いて、あるリポジトリ専用の環境を開発者間で統一する

    概要 VSCode のリモートコンテナ機能を用いると、開発環境を dockerfile の形でコード管理することができます。これにより、開発者が開発に用いる環境をリポジトリごとに統一できます。 VSCodeのリモートコンテナ機能とは コンテナの中に開発環境を押し込んで、その中にディレクトリをマウントして開発するVSCodeの機能です。 リモートコンテナ機能を用いて開発するメリット リモートコンテナ機能を用いて開発することには以下のようなメリットがあります。 local環境を汚さない 複数のプロジェクトで開発するにつれて、local マシンにはそのための様々なアプリ・設定が導入されていきます。この状態には以下のような欠点があります。 導入されたアプリや設定が膨大になって管理しきれなくなり、何のために導入されたか、変更してよい設定なのかが分からなくなる 異なるプロジェクトで必要な設定・アプリ同

    VSCode のリモートコンテナ機能を用いて、あるリポジトリ専用の環境を開発者間で統一する
  • Flutter研修【ミクシィ22新卒技術研修】

    22新卒技術研修で実施したFlutter研修の講義資料です。 動画:https://youtu.be/oQCJZFqDwIo ハンズオン用リポジトリ https://github.com/mixigroup/2022BeginnerTrainingFlutter

    Flutter研修【ミクシィ22新卒技術研修】
  • Flutter初心者たちが3ヶ月で新規アプリをリリースした話 #Flutter - Tech Blog

    ネイティブエンジニアの桐山です。 Timersでは新規事業として、毎月無料でましかくプリントを印刷できるサービスを始めました! 新規アプリでFlutterを採用し、3ヶ月でiOS・Androidアプリをリリースした話の概要編をお届けします。 はじめに この度弊社で新しい家族向けアプリをFlutterで作りました! https://famm.us/ja/print/top 毎月10枚がずっと無料の写真プリントアプリ Fammプリント Timers, Inc.写真/ビデオ無料apps.apple.com play.google.com おおまかなフロー Why Flutter? 弊社では元々家族アルバムアプリFammや年賀状アプリをネイティブで開発しており、写真を扱うネイティブ開発の知見も人的リソースもありました。新規アプリの開発するにあたって、ネイティブで開発した方が良いのでは?という意見が

    Flutter初心者たちが3ヶ月で新規アプリをリリースした話 #Flutter - Tech Blog
  • Golangでいい設計を実践するための6つのツール

    概要 Golangを書くにあたり、いい設計のコードを書くための手助けとなるツールを調べたのでまとめます。 想定読者 Golangの使い方をある程度わかっている(チュートリアルはやった) いい設計をするための具体的なノウハウに興味がある 記事を書いたきっかけ 引用: https://www.amazon.co.jp/dp/B09Y1MWK9N 最近設計に関して勉強するために「良いコード/悪いコードで学ぶ設計入門」を読みました。 の中では マジックナンバーを使うな 一つのメソッドの中で多くのことをやりすぎるな などの言われてみると基的な注意点が書いてありました。 一方で以下のように、確かにそうなんだけど実際は守れていない注意点にも書かれていました。 単一責任の原則を守ってクラス設計しよう 高凝集なクラスを作ろう を読んでわかった気になって今までと同じように悪い設計のコードを書くままではい

    Golangでいい設計を実践するための6つのツール
  • 自分流vscode高速術

    今回はvscodeを使っている方に対して、おすすめのショートカットやカスタム設定などを紹介し、早く開発するコツを紹介したいと思います。 参考にできそうな部分があれば幸いです。 おすすめtipsリスト 筆者の環境がmacなので、その点ご了承下さい。 ワークスペース系 ctrl + shift + n もう一つワークスペースを起動できます。 他のプロジェクトのコードを参考にしながらコードを書くといったシーンで使えます。 ctrl + r 最近開いたプロジェクトから簡単に開くディレクトリを指定することができます。 cmd + shift + e エクスプロラーとエディタ、ターミナルの行き来を簡単にします。 cmd + b エクスプローラーを出し入れします。 cmd + w 開いているファイルを閉じます。 ターミナル系 ctrl + ` ターミナルを出すことができます。 出した状態だと、閉じること

    自分流vscode高速術
  • FlutterアプリのPresentation層構成方針

    この方針策定のためのディスカッションページ 当方針は @naipaka さんにより起案・骨子考案いただきました!ありがとうございます👏 @keimiya_325 さん、ディスカッションへの参加ありがとうございます🙌 前提・Presentationとそれ以外を分ける理由は? 弊社では、UIとドメインは分ける方針をとっています。 1つにPresentationとドメインの分離という考え方を参考にしています。 PresentationDomainSeparation また、機能ごとにトップレベルディレクトリを切った場合、果たしてアプリの機能と画面は1体1でしょうか? 昨今の複雑化しているアプリで見ると、複数の機能を使用する画面は少なくないと感じます。 そのとき、その画面はどのディレクトリに入れますか? 画面はあくまで複合した機能をユーザーに見せたり使ってもらう場所であり、一番変更の多い箇所で

    FlutterアプリのPresentation層構成方針
  • Go言語で定数として扱いたいmapを毎回アロケートさせて性能劣化した話 | フューチャー技術ブログ

    はじめに失敗談をテーマにした連載の3目です。 TIG DXユニットの原です。21年度4月に新卒で入社し、2年目となります。 参加しているプロジェクトで、数百万件のデータを処理する機能を担当したことがありました。 記事はその際の失敗と、その失敗から得た経験を共有するため、執筆しました。 内容のサマリ 来フィールドで宣言すべき定数的に扱いたい変数を、関数内で毎回生成しreturnしてしまったので呼び出す度に毎回アロケートが発生し性能劣化してしまった Benchmark Test、Profiling、Escape Analysisでどのような挙動になってしまっていたか調べてみた 内容記事では、まずどのような状況であったかを説明し、どのような順番で問題を解決したかの順で説明します。 主にGoのテストとProfilingに関した内容です。 Goのテストについての関連記事として、Goのテストに

    Go言語で定数として扱いたいmapを毎回アロケートさせて性能劣化した話 | フューチャー技術ブログ
  • Oh Shit, Git!?!

    Gitって難しい。簡単にぐちゃぐちゃの状態になっちゃうし、失敗を直す方法を知ろうとしたところでまじくそ不可能。Gitのドキュメンテーションって卵とニワトリの問題みたいなところがあって、ハマりから抜け出すために知ってないといけない事柄の名前をあらかじめ知っていないと、どうやって問題を解決したらいいのか検索することすらできないんだよね。 だからここに、私が遭遇したことのあるよろしくない状況から、最終的にどうやって抜け出したかをフツーの日語で書いていこうと思う。 くっそー、超絶やらかした。お願い、Gitには魔法のタイムマシンがあるって言って? git reflog # こうすると、Gitでやったことがすべてのブランチに渡って全部見えるよ! # どのブランチにも HEAD@{index} ってインデックスがあるはずだから # やらかす前のやつを見つけて git reset HEAD@{index