Rust 初心者が自動型変換や型変換関係のトレイトを自信を持って扱えるようになるための型変換まとめ 8 パターン - Qiita
はじめに Rust をはじめてみて特によくわからなくて使っていて不安になっていたのは型変換関係の仕組みです。 String は &str として扱えますとか Vec<T> は &[T] として扱えますとかいうのは、そういうものなのかー便利だなーと思う半面、よくわからないなーこわいなーと感じていました。 この記事ではそんな型変換がよくわからなくてもやっとしている Rust 初心者が型変換関係の全貌をなんとなく把握して自信を持って扱うことができるようになるために、自動型変換や型変換関係のトレイトの利用パターンを 8 種類まとめてみました。 fn main() { let s: String = "hello".to_string(); // fn len(&self) -> usize を呼び出す // String -> &String に自動変換されて呼び出される assert_eq!(s
緊急事態宣言に「慣れた」んじゃなくて呆れ果てただけだよ（追記2）
「慣れた」から自粛が甘いってことにされそうなので書いとく。 慣れたんじゃなくて相手にする価値のないアホだとみなされたからだよ。 政府の要請にマジメに付き合ってもバカを見るだけなのがこの1年で広く伝わった。もう政府の信用が尽きたんだよ。 いま自粛してる人はあくまで自衛のためにやってるだけだし、大雑把な人はもう緊急事態宣言なんかなかったように路上飲みしている。 なぜか花見シーズンに合わせたのか特に理由も示さず緊急事態宣言を解除したり、首相の訪米と重ならないようにするためか緊急事態宣言を遅めに発令したり、事実でなく気分で操作してる様子を何度も見てきている。その割に（それだからこそ？）2,3日前にいきなり緊急事態宣言しますとか酒の提供をやめてもらいますとか言い出す。人間のことナメてんのか？在庫管理ってわかるか？ 実際、政府の言うことにつきあっても事態は何も改善されない1年だった。 厚生労働省「（2
コードが読めるソフトウェア開発者 - As a Futurist...
僕はコードを読むのは得意な方だけど、それが過ぎてコードを書かなくてもシニアソフトウェア開発者になってしまった。実はコードをちゃんと読めるソフトウェア開発者って希少価値が高いのではないか、と思ったので自分がどんな感じでシニアになったのかをまとめてみた。似た様な人の参考になれば幸いだ。 同意。僕は未だ書く方はほとんど機会なく成果もないけど、コードを読み尽くして、負荷試験や本番で挙動を把握し続け、メトリクスでとことん確かめていった結果、Sr. Engineer になれた。 https://t.co/KXtMdEaRr8 — Ryosuke Iwanaga (@riywo) April 16, 2021 コードを書かなくてもシニアソフトウェア開発者になれた 僕は今 Amazon の Sr. Systems Development Engineer という職種で働いている。いわゆるソフトウェア開発職
仕事としてOSS開発者をやってきた話 - 覚書
はじめに わたしは今も昔も仕事としてOSS開発者をしていて、twitterなどでそれなりに名前が知られていることもあって、昔から「どうすればそういうこと(業務としてOSS開発)ができるのか」「どういうキャリアを歩んできたのか」「Linuxカーネル開発者になるにはどうすればいいのか」ということをよく聞かれてきました。当時わたしが置かれた環境と現在の環境では違いがありすぎるので公開に積極的にはなれなかったのですが、一つの過去事例として何らかの意味はあるかもと思って公開することにしました。 書き方が難しかったのですが、うまくまとまらなかったので、自分が書くのが楽な日記みたいになりました。 きっかけ 2000年初頭に学部4年のころにLinuxを触りはじめてから「UNIXとかLinuxってすげえ」「こんなものが無償で使えるのか」「これらのソースコードが全部見られるのか」と感動して、「自分も成果物を公
FIREに至るまでの4ステップ - FIRE: 投資でセミリタイアする九条日記
最近、FIRE≒セミリタイアを目指して投資する人が本当に増えてきたように感じています。では、実際にFIREに至るまでにはどんな段階があるのでしょうか。それぞれのタイミングで、何を目標にしていったらいいのでしょうか。 ブレイクダウンして目標を細分化する STEP1：家計の黒字化 STEP2：ターゲット貯蓄率を超える STEP3：年間リターンと配当金が、年間投資額を超える STEP4：年間リターン＋配当金が、生活費を超える アフターFIRE：資産取り崩し期の考え方 ブレイクダウンして目標を細分化する どんなビジネス書にも書かれていることの一つに、目標を達成したいなら、それが実現した状態をイメージすること、そして実現までのステップを分解して、ゴールを設定し、ひとつひとつの段階をクリアしてくこと、というものがあります。 夢は夢だけにしていては夢で終わります。それに向けた具体的なアクションを取るには
システム負荷切り分け自分メモ - Qiita
概要 CentOSでシステムのボトルネックを調査する時の問題切り分け方法の自分メモ。 前提 カーネルモードでCPUが使われるのは、割り込み、システムコール、カーネルスレッド ロードアベレージとは CPUの実行権限が与えられているのを待っているタスク ディスクI/Oが完了するのを待っているタスクの ２つの状態のプロセスの数 切り分けフロー LA高いか？ 低い ネットワークなどがボトルネックになっているかも。muninなど、NWに関するグラフを見ると帯域が圧迫しているなどありえる OSの設定などがボトルネック。カーネルのsynパケットの受付数が低いなど。 アプリケーション、OSのログ、各種ログを見ることが大事 ↓ LA高い場合 vmstatで負荷の特徴把握 ↓ CPU負荷 or IO負荷 どちらか cpu負荷: us列, sy列 が高い IO負荷: b列をみる。IO列は低くてもIOが高い場合が
cgroupsを利用したリソースコントロール(RHEL7) - Qiita
cgroupsとは cgroups(Control Groups)とは、「プロセスをグループ化して、 リソースの利用をコントロール」するカーネル機能で、 Linux 2.6.24からマージされています。 具体的には、グループ単位でリソースの割り当て、 優先度、管理、モニタリングなどが設定できます。 cgroupsそのものはプロセスを「コントロールグループ」 と呼ばれる単位にまとめるだけで、リソースコントロールを 行うにはコントロールグループに「サブシステム」 と呼ばれる抽象化されたリソース群をつなげる必要があります。 主なサブシステムには、次のようなものがあります。 ・cpu CPUへのアクセス ・cpuacct CPUについての自動レポートを生成 ・cpuset マルチコアCPUのコア単位およびメモリノードを割り当て ・memory メモリに対する制限設定とメモリリソースについての自動レ
Twitter で医師を拾ってきて Google のソフトウェアエンジニアにするだけの簡単なお仕事 - 白のカピバラの逆極限 S.144-3
はじめに 「【転職エントリ】Googleに入社します｜Lillian｜note」という、医師から未経験で Google のソフトウェアエンジニアになった記事があります。 note.com 私は、この記事に出てくる「とある元 Google のソフトウェアエンジニア」で、面接の対策を立てました。 記事が出た当初から大反響で、私もそれなりの反応を見まして、いろいろと誤解されているなあ、と思う一方、アドバイザーはあくまでもアドバイザーだから、アドバイザーとして知りえた情報については、口をつぐむべきだと思っていました。 ただ、あまりにも誤解されており、悪影響が大きく、犠牲者も多くなってきたと思ったので、許可を得て簡単に背景を書いておこうかと思います。 これはあくまでもアドバイザー側からどう見えていたかを書いておくものですが、医学部卒だけでも3,4人 Google や Amazon に入っていったおぼ
時代に即したMySQﾚの新機能：PLEASE句 - sakaikの日々雑感～(T)編
最近は、会社などの組織において仕事の指示をする場合に、単に上司が命令をするだけでは組織は動かないと言われています。部下に仕事をしてもらうには－－そう、まさにこの「してもらう」の気持ちこそが本質なのですが－－「命令」ではなく「依頼」の形を取ることで、お互いに気持ちよく仕事をすることができ、より良いチームとなるのです。 この世の中の流れは近年、ソフトウェアの世界にも強く適用されるようになってきました。ソフトウェアに於いても、常に、より中立的な立場での対応が求められてきています。 MySQﾚも例外ではなく、最近の修正ではレプリケーションの master-slave を source-replica と呼ぶように変更したり、blacklist を blocklist に変更したりなどの話題を目にした方も多いと思います。 これら一連のポリティカリーにコレクトな対応に今回新たに加わったのが、冒頭で紹介
【保存版】東京リージョンの AWS 障害発生時にクラスメソッドのテクニカルサポートチームがやっていること | DevelopersIO
どのような事前準備をしているか 有事の際は想定外のことが発生しやすく、事前準備をしていないと冷静な対応が難しくなります。 いきなりしっかりした事前準備をすることは難しいので、徐々に成熟度を上げていきます。 本章では以下の観点で、事前準備についてご紹介します。 手順書 自動化 訓練 手順書 フローやチェックリストを含む手順書を準備しています。 手順書の内容は後述します。 分かりやすい手順書を準備することも重要ですが、その手順書への導線づくりも大切にしています。 運用周りのドキュメントは数が多く、目的のドキュメントが埋もれてしまい他のメンバーが見つけられない場合があるからです。 周知に加えて、ドキュメントの階層を見直したり、特定チャンネルに手順書の URL をピン留めしておくなど、手順書に辿り着きやすくする工夫をしています。 分かりやすい手順書の書き方については、以下のブログが参考になります。
pipとpipenvとpoetryの技術的・歴史的背景とその展望 - Stimulator
- はじめに - Pythonのパッケージ管理ツールは、長らく乱世にあると言える。 特にpip、pipenv、poetryというツールの登場シーン前後では、多くの変革がもたらされた。 本記事は、Pythonパッケージ管理ツールであるpip、pipenv、poetryの3つに着目し、それぞれのツールに対してフラットな背景、技術的な説明を示しながら、所属企業内にてpoetry移行大臣として1年活動した上での経験、移行の意図について綴り、今後のPythonパッケージ管理の展望について妄想するものである。 注意：本記事はPythonパッケージ管理のベストプラクティスを主張する記事ではありません。背景を理解し自らの開発環境や状態に応じて適切に技術選定できるソフトウェアエンジニアこそ良いソフトウェアエンジニアであると筆者は考えています。 重要なポイントのみ把握したい場合は、各章の最後のまとめを読んで頂
AWSのログ管理ベストプラクティス
9. 収集 処理 分析 保存 データ収集と 保存 データ処理イベント処理 データ分析 データ 答え 分析前の前処理等、 いわゆるETL （抽出、変換、挿 入 ）的な処理 各サーバや、サー ビスからのログを 収集する ログに対して各種 分析をかける 収集したログを サーバやデータス トアに保存する 10. Amazon S3 Amazon Kinesis (Streams, Firehose) Amazon DynamoDB Amazon RDS (Aurora) AWS Lambda KCL Apps Amazon EMR Amazon Redshift Amazon Machine Learning 収集 処理 分析 保存 データ収集と 保存 データ処理イベント処理 データ分析 データ 答え Amazon Athena
レビュアーにやさしいリファクタリングPRを作る
リファクタリングの PR、見るのツラい内容になりがち PR(PullReqeust)を作成してレビューを受け、Approve を受けたらマージする..という開発スタイルはよくあるパターンで、新たな機能追加や修正では観点が明確で動作確認も実施しやすいのですが、これがリファクタリングがテーマになると、途端にレビューが大変になることがあります。 個人的な経験則もありますが、何も意識せずに PR を作ると、次のような問題が発生しやすいように感じます。 １テーマに関する修正が一気に詰め込まれていて物量が多い 何を確認したらよいのかわからない 複数 PR に分けている場合に、後続の PR だけを見ても理解できない など... リファクタリングの PR は内容も淡々としたものになることが多く、確認もリグレッションテストが中心で、レビュアーはそこそこ心を削られます。そのうえ上記のような問題を抱えていると、
勉強用の読書に最適！ 本の内容が記憶にどんどん定着する「SQ4R読書術」を試してみた - STUDY HACKER（スタディーハッカー）｜社会人の勉強法＆英語学習
「本を読んだのに、あまり内容を覚えていない」 「読んでも、いまいち理解できない」 「勉強のための本は、関心が湧かなくて読み進められない」 読書をしていて、このような悩みを抱いたことはありませんか？ もっと効率よく、そして記憶に残る読書にするためのテクニックがあります。それは、カナダのウォータールー大学が推奨している「SQ4R読書術」です。 今回の記事では、SQ4R読書術の方法と効果をご紹介しましょう。実際に筆者が試した結果や感想についてもお伝えします。 「SQ4R読書術」とは 「SQ4R読書術」の原点は、アメリカの教育心理学者フランシス・P・ロビンソンが当時の大学生や軍人向けに考案した、教科書を学ぶメソッド。それをもとにさらなる研究が重ねられた結果、拡張バージョンとして「SQ4R読書術」が確立しました。数々の著名な大学に普及し、なかでもカナダのウォータールー大学では「SQ4R読書術」をマニ
mimalloc のメモリ管理 - Qiita
Microsoft の mimalloc は面白い割り切り方で、小さいソースコードで高速なアロケータを実装しています。 確保するメモリブロックのサイズを、 Small (~8KiB), Large (~512KiB), Huge (512KiB~) の3つに分類し、 Small と Large は同じアルゴリズムで管理し、 Huge は OS 任せにして、 Small と Large は同じアルゴリズムをうまく利用しています。 基礎 OSはpage (x86では基本 4KiB) ごとにメモリをプロセスに割り当てています。 しかしアプリケーションではずっと小さいメモリブロックが必要になることが多くあります。また、必要になるたびに毎回OSからメモリを割り当ててもらうのはパフォーマンスも悪いです。 mimalloc やその他の malloc 実装 (以降 malloc と呼びます) は OS か
【翻訳】技術的負債という概念の生みの親 Ward Cunningham 自身による説明 - t-wadaのブログ
システム開発の世界において「技術的負債（Technical Debt）」は繰り返し話題になり、しばしば炎上しています。 技術的負債という概念の生みの親は Ward Cunningham （ウォード・カニンガム）です。彼は 1992 年にオブジェクト指向プログラミングの国際カンファレンス OOPSLA '92 の Experience Report でコードの初回リリースを負債に例えました（"Shipping first time code is like going into debt"）。 Ward Cunningham はソフトウェアの世界に多くの貢献を果たしてきました。Wiki の発明者であり、XP と TDD の父 Kent Beck の師匠のような存在であり、建築の世界の「パタン・ランゲージ」を Kent Beck と共にソフトウェアに輸入した人であり、「アジャイルソフトウェア開
日本に居ながら海外の会社にリモートワークで働いていい給料をもらう方法
リモートワークをして Zoom で東京のオフィスに繋ぐんだったら、ロンドンやカリフォルニアに繋ぐのも同じ。だったら給料の高い英語圏の会社の仕事をした方が有利だと思う。 これを読めば日本に居ながら海外の会社からそれなりのいい給料をもらって働くことが可能になるはず。そうしてリモートでずっと英語を使って働いていれば、英語もかなり上達するし。 ずっと海外で働いてきて、それぞれのチームに必ず世界のいろんな場所からリモートで働いているメンバーが居た。現に今の職場にもアイルランド、ロシア、イスタンブールからリモートで入ってるメンバーがいる。彼らからも聞いた話しなどをまとめた。コロナの影響もあって IT 系の会社がエンジニアを募集する際に「オフィスに来て働いてもらう」という意識が希薄になったし、このチャンスは現在進行系で拡大しているのを日々感じる。 オフショア開発を再定義するまず「オフショア開発」というと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
深夜に食べると死ぬけどバカ美味いやーつのレシピまとめ
Rust in the Android platform
C++マルチスレッド一巡り
