タグ

ブックマーク / medium.com (141)

  • Rustで作るLinuxデバイスドライバ

    だれでもできるシリーズとして、Rustでカーネルモジュールを実装しながら学んできましたが(役に立たないキャラクタデバイスドライバなど)、そろそろ実際に使える機能を実装したいころですよね! 今回は、筆者が実装したネットワークPHYドライバが、Rustで実装された初めてのデバイスドライバとしてLinuxカーネルに採用された話を紹介します。 誤解:LinuxカーネルがRustをサポート「LinuxカーネルがRustをサポートした」というニュースを見て、Rustのコードがどんどん採用されていると誤解している方もいるようです。このニュースは、「LinuxカーネルをRustでも書けるようになりましたが、実際に何かを実装するかどうかは未定」という意味です。Linuxカーネルは、メモリマネージメント、ネットワーク、暗号など、数多くのサブシステムで構成されており、それぞれのメンテナが、コードの採否を判断しま

    Rustで作るLinuxデバイスドライバ
  • Cloud Run でマイクロサービスを作る 5 つのポイントをまとめてご紹介!

    はじめに早速ですが、皆さんはマイクロサービスを構築するとしたら、どのような構成を考えますか? 多くの企業で、GKE を使ったマイクロサービス アーキテクチャが採用されています。選定理由として、Kubernetes が持つ機能や大きめなリソースが必要であったり、社内インフラチームによる Kubernetes のサポートがあるといった理由などがあります。一方、定期アップグレードなどの観点から、Kubernetes の運用は少し大変…と感じる方もいるかと思います。 GKE Autopilot の利用という考えもありますが、サーバーレスでコンテナを動かせる Cloud Run を使って、インフラ管理不要でマイクロサービスを構築が出来ると嬉しくないですか? 実際、そういった構成を採用されている企業も見かけます。 この記事では、設計や実装時に考えるであろう、以下の 5 つのポイントにフォーカスしてみた

    Cloud Run でマイクロサービスを作る 5 つのポイントをまとめてご紹介!
  • アンチパターン “ゴールが延び続けるスクラム”

    チームやプロジェクトを率いる立場で意識していることの1つに、「メンバーがタスクをやり切ったと継続的に感じられる仕組み作り」がある。特にスクラムを採用している場合は ”前に進んでいる感” を継続的に醸成していく事も欠かしてはいけないと思っている。ただ現実にはこの観点は悪気なく疎かになってしまうケースが(自他共に)多いという感覚がある。 Pull Requestレビューを例にしてみる。2週間スプリントのアジャイルチームでとあるプロジェクトの主担当として開発をリードしているエンジニア氏。仕様検討・周囲との調整・実装を頑張ってPull Request作成まで漕ぎ着けた。エンジニアは一旦ココで”仮達成感”に浸る(と、個人的に思っている)。そしてレビュワーにレビューを依頼して、反応を待つ。のだが。。。 スプリント1: 「進捗してます」「pullreqレビューをassignされたエンジニア程、別件で忙し

  • Linuxカーネルが難しい?Rustで実装しよう!. 「カーネル開発者になりたい!」 | by FUJITA Tomonori | nttlabs | Jul, 2020 | Medium

    「カーネル開発者になりたい!」 クラウドネイティブ世代の皆様は、何を言っているのか理解できないと思いますが、一昔前は、Linuxカーネル開発の魅力におぼれたエンジニアがたくさんいました。クラウドファースト時代に、誰もやってないだろうと、軽い気持ちで試すと、今もひっそりと生息しているカーネル開発者に、一晩中、指導をうけるはめになりかねません。前例のないRustなら安心です。 RustLinuxカーネルモジュールが実装できるRustでカーネルモジュールを実装する利点Rustへの愛だけが理由ではなく、カーネル開発にRustを用いると、様々なバグを減らすことができそうという利点があります。例えば、動的なメモリ管理で、うっかり、解放を忘れるとか、解放した後に使ってしまうと、往々として、辛いデバッグになります。 Rustで実装した簡単なカーネルモジュールRustのカーネルモジュール開発フレームワーク

    Linuxカーネルが難しい?Rustで実装しよう!. 「カーネル開発者になりたい!」 | by FUJITA Tomonori | nttlabs | Jul, 2020 | Medium
  • 【いでよ障害対応太郎】我々はインシデントにどう向き合っているのか 〜社内向け障害対応リスト付き〜

    「なんかアプリでインシデント起きてエンジニアがどこかで対応してるらしいよ」 「インシデント時のお知らせって誰がどうやって出すんだっけ?」 「インシデントの復旧作業って今どれくらい終わってる?」 「あのインシデントって振り返りしたっけ?」 「似たようなインシデント、前も対応したような、していないような」 このような会話に覚えはありませんか? FiNC Technologies社 (以下FiNC) では今まで インシデント対応をしていても自チーム内で対処しようとしてしまい、他の人が気づけないインシデント対応の仕方にフォーマットがなく、迅速な対応やお客様への報告ができないインシデントの振り返りが実施されず、インシデント時の知見が共有されないという問題がありました。 それらの問題を 気が付きやすく、シェアしやすくする = 統一のチャンネルで情報を整理し、そこにシェアしやすい空気を作る何をすべきかわ

    【いでよ障害対応太郎】我々はインシデントにどう向き合っているのか 〜社内向け障害対応リスト付き〜
  • Raspberry Pi 4 で構築する録画マシン | 空気録学電子版【公式】

    🍓 Raspberry Pi 4 が買えるようになりました2019年11月、待望の Raspberry Pi 4 技適取得版が発売されました。H.264 ハードウェアエンコーダを搭載した、リッチなシングルボードコンピュータです。2020年5月28日には 8GB メモリ搭載の上位モデルも登場しています。 はたしてこれは何をするためのデバイスなのでしょうか? そうです、録画ですね。もうテレビの録画をするために高価なパソコンを購入する必要はありません。5000円台から入手できるマシンを利用して、安価に録画サーバーを構築することができるようになったのです。 この記事では Raspbery Pi 4 を利用した Mirakurun + EPGStation での録画サーバー構築方法と、ハードウェアエンコーダを利用した録画ファイルのエンコードについて解説を行います。 筆者の⾃宅で運⽤している録画サー

    Raspberry Pi 4 で構築する録画マシン | 空気録学電子版【公式】
  • 「口の形アニメ」とは何か

    僕は最近「かわいい女の子がかわいいことをするアニメ」が好きで、よく見るのですが、「かわいいから良い」というのはちょっと抽象的すぎて、もう少し具体的に何が良いかはっきりさせたい、という気持ちがあった。 アニメの一部を切り取った画像を見て、「あっかわいい〜😍」ってなるもの、どんな特徴があるだろうって少し考えてみると、頻出するパターンがあることに気づいてきます。 たとえば「><」でよく表現される「かざり目」だったり、ひだまりスケッチなどに見られる「へちょ絵」といったデフォルメ・マンガ的表現。こういうのが出てくると「あっなんか良い(かわいい)」と感じることが多い。 そして2018年2月、アニメ「六畳間の侵略者!?」のエンディング映像を見てふと思った。「かわいい〜」って思えるシーンは女の子の口の形が特徴的だなって。 ゆりかちゃんふぁいおー!かわいいこのときはそれで終了したが、その後2018年4月、

    「口の形アニメ」とは何か
    kirine
    kirine 2020/04/12
  • 「Infrastructure as Codeに疲れたので、僕たちが本来やりたかったことを整理する」を1年掛けて整理した

    こんにちわ。rwle1212です。 記事は JAWS Days 2020 で話す予定でしたが、昨今の事情によりオンライン開催となったため、登壇予定の内容を記事にしたものになります。 登壇していれば諸般の事情により左手首を骨折したネタが使えたのですが、ブログでは伝わらないので非常に残念な思いをしております。という話はどうでも良いので題に入ります。 50分の登壇内容なので少々長くなりますが、お付き合いください。 JAWS Days 2019で登壇した内容の振り返り昨年の JAWS Days 2019 で「Infrastructure as Codeに疲れたので、僕たちが来やりたかったことを整理する」という内容で登壇しました。 まずは上のリンクに添付されているスライドを5分位で読めると思うので一読頂いて、下の文に進んで頂ければと思います。 そもそもInfrastructure as Cod

  • Google Glass (Glass EE2) 購入レポート

    まとめGoogle Glass の法人向け進化版 (Glass Enterprise Edition 2) が買えるようになりましたこれまでは法人販売限定だったけど、一般ユーザーでも購入可能に日からでも買えます。技適も大丈夫価格は、約16万円(体 + 配送料 + 諸経費)購入から到着まで、約10日前後Google Glass ?! 終わったはずでは …?終わってませんでした! 正確に言うと、2013年に一般開発者向けに発表された Google Glass (Explorer Edition) は開発・サポートともに終了していますが、法人向けの Glass (Enterprise Edition) は、2017年頃から開発が続けられています。

    Google Glass (Glass EE2) 購入レポート
  • 2歳半までの子育てで学んだ3つのこと。システム思考、レジリエンス、睡眠

    子どもが生まれてからあっという間に1年1年がすぎていきます。初めての子育てで手探りながら夫婦で試行錯誤していく中で、この約2年半で学んだことについて、記憶が鮮明なうちに書いてみたいと思います。 実際に痛みを伴いながら徐々に学んだおかげで腹落ちした部分もあると思うのですが、3つとも出会えてよかった,もっと早くから知っておけたらと思う観点で、今後子育て以外の局面でも助けてくれる気がしています。読んでいただいた方の参考になると嬉しいです。 もくじ1, システム思考 2, レジリエンス 3, 睡眠不足の害 1, システム思考システムから生じる一つ一つの個別事象に対処しようとするのではなく、根となるシステムを修正することのほうに意識を向けよう。 システム思考の例: 咳や鼻水といった一つ一つの症状を治すことに注力しようとするよりも、根原因である風邪を治すことに意識を向けてよく眠るなどの対策をとった

    2歳半までの子育てで学んだ3つのこと。システム思考、レジリエンス、睡眠
  • ミルクボーイがアジャイルを説明したら

    序章駒場「最近、うちのおかんがシステム開発に興味を持っててなぁ、名前は忘れたらしいんやけど、迅速に開発できて、仕様変更にも対応できる、素晴らしい開発手法を取り入れてるところがあるらしいんやわ〜。」 内海「そんなもんアジャイルに決まってるがなぁ〜! 今やシステム開発と言えば、アジャイル。素早く変化に対応できるってゆーのが特徴なんよ。そもそも名前が “迅速” を意味する英語やねんから、アジャイルに決まってるがなぁ〜。」 チームの人数駒場「最初、オレもそう思たんやけどな、なんでも 40 人ぐらいで開発してるらしいんやわぁ〜。」 内海「ほなぁ、アジャイルちゃうかぁ…。アジャイルでは 5〜9 人ぐらいが推奨されてるからなぁ〜。40 人もおったら、とてもやないけど、コミュニケーションが成立するとは思われへんなぁ〜。効率の悪い伝言ゲームになるのは目に見えてるからなぁ〜。おかん、他にもなんか言うてなかった

  • コンテナユーザなら誰もが使っているランタイム「runc」を俯瞰する[Container Runtime Meetup #1発表レポート]

    コンテナユーザなら誰もが使っているランタイム「runc」を俯瞰する[Container Runtime Meetup #1発表レポート] こんにちは、NTTの徳永です。稿では、コンテナユーザなら誰もが使っていると言っても過言ではない、コンテナランタイムの筆頭「runc」に注目し、その概要を仕様と実装の両面から俯瞰します。稿は私が主催者の一人として参加した「Container Runtime Meetup #1」で発表した内容をベースにしています。詳しい内容は発表資料もぜひご参照ください。 コンテナランタイムとはKubernetes等のコンテナオーケストレータを用いてアプリケーションをコンテナ(Pod)として実行するとき、実際にコンテナの作成をしているのは誰でしょうか。実はKubernetesはコンテナを直接触らず、あるソフトウェアを用います。まさにそれがコンテナランタイム(以降、ランタ

    コンテナユーザなら誰もが使っているランタイム「runc」を俯瞰する[Container Runtime Meetup #1発表レポート]
  • 本番環境のマルチテナント Kubernetes クラスタへの Istio 導入

    これは Mercari Bold Challenge Month の3番目の記事です。 Mercari ではモノリスなサービスからマイクロサービスのアーキテクチャへと移行を行っている間、長期的な観点からみて、サービスメッシュの導入とその重要性を理解することが必要だと感じていました。ほとんどのインシデントレポートに対する現実的な対策としてあがるのが、レートリミットの導入、適切なカナリアリリースのフローの導入、適切なネットワークポリシーの導入などでした。そしてこれらこそがサービスメッシュによってもたらされる機能です。 前四半期では、私達はついに Istio の導入に挑戦することに決め、調査を開始しました。結果として、100 以上のマイクロサービスをホストするマルチテナント環境のシングル Kubernetes クラスタを深刻な障害を発生させずに番運用を行うことができています。この記事では Me

    本番環境のマルチテナント Kubernetes クラスタへの Istio 導入
  • 【2019年版】UIとUXデザイントレンド - baby-degu - Medium

    Scenery Illustration by J.HUAこちらの記事は、2018年12月に公開された『 2019 UI and UX Design Trends 』の和訳になります。 はじめに私たちは去年、モバイルUIデザインのトレンドについての予測をまとめました。今年はモバイルだけを対象とせずに、さらに深く掘り下げていきます。 モダンなデザインの一番のトレンドは前後関係のあるつながりの中にあります。そのため、一般化することができません。 この記事を読むことであらゆるツール、技術の進歩、またユーザー向けのプロダクトが実際にどのように機能なのか開発者が理解し、全てが上手くいくように感じるでしょう。 近いうちに、販売だけでなく、生産するものすべてを網羅するユニバーサルデザインの考え方を発展させて行くでしょう。自分で何か物事を行うためには、より良いデザインの選択が必要です。 国家としての印象さ

    【2019年版】UIとUXデザイントレンド - baby-degu - Medium
  • Apache Airflowでエンドユーザーのための機械学習パイプラインを構築する Part5 (End)

    We organized Japanese financial reports to encourage applying NLP techniques to financial analytics. You can download… Part4からずいぶん間が空きましたが、その間にはデータ公開にまつわるもろもろの調整などがあったという。 Airflowを採用しなかった理由最終的にAirflowを採用しなかった理由は2つあります。 運用コスト開発コスト運用コスト Part3でも触れましたが、Airflowのホスティングは結構高くつきます。ホスティングサービスを提供しているのはGCPのCloud ComposerとAstronomerの2つが主です。Astronomerの場合は月額$100まで抑えることが可能ですが、固定で毎月かかるとなるとそこそこの金額です。 スケジューラーは、スケジュー

    Apache Airflowでエンドユーザーのための機械学習パイプラインを構築する Part5 (End)
  • iOSDC 2019「SOLID原則を生活に適用する」全文以上書き起こし

    SOLID原則は、オブジェクト指向プログラミングにおける基的な5つの原則です。 S — 単一責任の原則 (Single Responsibility Principle) O — 開放/閉鎖原則 (Open/Closed Principle) L — リスコフの置換原則 (Liskov Substitution Principle) I — インタフェース分離の原則 (Interface Segregation Principle) D — 依存関係逆転の原則 (Dependency Inversion Principle) コーディングにおいて、言語化できない不吉なにおい(Code Smell)を感じたときには、これらの原則に照らし合わせることで設計の間違いを言語化し、修正の手がかりを掴むことができます。 SOLID原則はもちろん、ソフトウェア設計のための原則です。 しかしオブジェクト

    iOSDC 2019「SOLID原則を生活に適用する」全文以上書き起こし
  • マイクロサービスで管理画面が乱立する問題と対策

    こんにちは、qsona (twitter) です。 マイクロサービスアーキテクチャを指向するとき、(主に社内向け)管理画面をそのままサービスごとに作っていくと、マイクロサービスの数だけ管理画面が乱立するという課題があります。FiNC においては、それにより実際に以下のような問題が発生しました。 ユーザの追加/削除や権限管理がとても大変ユーザ(CS対応者)がどこの管理画面を使えばわかりにくい記事では、 FiNC においてこれらの問題に対してどう対処してきたか、歴史とともに紹介します。 tl;dr各マイクロサービスで管理画面を作ること自体はよい。統一管理画面は開発のコストがかかりワークしなかった認証を中央管理にする権限管理は各サービス固有のドメイン知識だが、中央で一覧/変更できる状態になっていると便利マイクロサービスの横断的関心事への対処は、「標準」を意識する黎明期から、問題が起こるまでFi

  • エンジニアのコーチング by Kent Beck

    以下は、Kent Beckによる「Coaching Engineers」の翻訳です。人の許可を得て掲載します。tl;dr 有償でエンジニアのコーチをします。詳細と待ち時間についてはお問い合わせください。 物語の結末2018年2月にFacebookを退職する直前に、トップ1%のエンジニア(現在および過去にレベルE7以上だったエンジニア)のオフサイトミーティングに参加しました。海辺のリゾートでバスを降りると、私がコーチをしていた生徒が複数いることに気づきました。そのうち何人かは昇進したことを知っていましたが、その他の生徒には驚かされました。 私にとって、胸がはちきれるほどの誇り高き瞬間でした。私は、生徒たちと関係を築き、彼らの成功のために心の底から尽力してきました。多くの生徒らが成功を収めたことを目の当たりにして、私は大いに驚き、嬉しくなりました。物語はさらに続きます。 Facebookの上

    エンジニアのコーチング by Kent Beck
  • 呪い: 見積もりの3倍だけ常にかかってしまう

    みなさん、進捗どうでしょう?最高ですか?そんなことないよね!なぜならあなた達は呪われている。事前の計画よりも、常に、3倍の期間が必要になる。常にだ!!この呪いは強力であり、解放されるのは難しい。我々はどうすればよいだろうか? パーキンソンの呪いある資源に対する需要は、その資源が入手可能な量まで膨張する パーキンソンの法則 — Wikipedia ある仕事の作業量を見積もったとしよう。機能Aの追加に2週間程度必要そうだ、とする。順調にいけば、再来週には動き出し、価値が出せそうだ。ペースを作り、粛々と仕事を進めていこう。 ところが、現実的にはそんなに上手くはいかない。新しく導入するライブラリがうまく動かないとか、くだらないtypoに悩まされて半日失ったとか、既存コードの改修箇所が想像してたより多かったとか、何らかの別の仕事をやらなければいけなかったり、もしくは休暇が必要だったりとか。当初計画よ

  • GAE 2nd-gen でのサービス間認証

    TL;DRGAE 2nd-gen では X-Appengine-Inbound-Appid ヘッダの代わりに、ID Token + Identity-Aware Proxy を使った方式をサービス間認証に使えます。 はじめにGAE でマイクロサービスを構成する場合、各サービス同士を呼び合うときに同一 GAE アプリからのリクエストであるかを確認したい場面があります。シンプルな例だと、サービスがフロントエンドとバックエンドに別れていて、バックエンドはフロントエンドからしか呼び出せないようにしたい場合です。 GAE 1st-gen では X-Appengine-Inbound-Appid ヘッダという魔法のヘッダがありました。このヘッダは URLFetch を使用して別の GAE サービスにアクセスする時に、GCP が自動で呼び出し元の Project ID を入れてくれるヘッダです。そのため

    GAE 2nd-gen でのサービス間認証