Published on 2021-10-22 Tagged: bazel career go 先週の金曜日は、私にとってGoogleでの最後の日でした。もちろん、Googleを辞めるときには、何かしらの手紙や暴言を書かなければなりません。真面目な話、これはルールで、出版するまで神経インプラントは外されません。 冗談はさておき、これは極論というよりも回顧録のようなものです。もちろん、私は意見を持っていますが、今はその時ではありません。これは、私の人生の最後の7年間を振り返って、何が重要だったのか、そして将来何を違った方法で行うのかを考えるためのものです。 Googleでの仕事内容 Docs, Sheets, and Slides 今回の主な教訓は ベイゼルへの応援 今回の私の重要な教訓。 グーグルで働き続けた理由 私が辞めた理由 燃え尽きた キャリアと報酬 その他の考え方 Googleでの
ここまでBazel の利点をいくつか紹介しましたが、採用には懸念点もありました。次のセクションからは、どのような懸念があったか、それをどのように解決したのかを紹介します。 Xcode 統合 Bazel と Xcode の統合は Bazel の採用においてもっとも大きな懸念でした。 Xcode はビルドシステムと密結合したやや特殊な IDE なので、外部ビルドシステムとの統合が難しいのです。特に indexing や LLDB デバッグを正しく動作させるのは困難でした。 統合とはつまり、Bazel によるビルドのアウトプットを利用して Xcode がサポートする動作を再現することを意味していて、主に下記のような要件を満たす必要があります。 Bazel のビルド構成ファイル群を解析して Xcode プロジェクトを生成する Xcode ビルドの実行を抑制し、代わりに Bazel ビルドを実行する
開発言語と主要フレームワーク 95%以上Swiftで、特に古いテストやエンティティはObjective-Cが少しだけあります。新規のものは必ずSwiftで開発していて、残っているObjective-Cは少しずつ減らしています。 使っているSDKのバージョンに関しては、Xcode 12への移行対応が終わっており、近日中に12でビルドしたバイナリーを公開する予定です。 ほぼほぼUIKitですが、いくつかの画面でSwiftUIを使っています。最低対応のSDKはiOS 13なので、LazyStack系やLazyGrid系がまだ使えないのですが、設定周りの画面など、CollectionViewっぽくない画面を今年中にたくさん移行しようと思っています。移行自体は色々考えてプロトタイプを作るなどして、2020年のiOSDCで発表しました。また、UIKitはモダンなAPIを使うように心がけており、例えば、
Should you use PyTorch vs TensorFlow in 2023? This guide walks through the major pros and cons of PyTorch vs TensorFlow, and how you can pick the right framework. PyTorch and TensorFlow are far and away the two most popular Deep Learning frameworks today. The debate over which framework is superior is a longstanding point of contentious debate, with each camp having its share of fervent supporters
Cloud FunctionsをGoで書く。またはFirebaseのためのマイクロサービスアーキテクチャ - laiso
Firebase Advent Calendar 2019 の17日目です。16日目はKesin11さんの「Firebase Emulator Suiteをフル活用してTDDで開発しよう」でした。 はじめに FirebaseプロジェクトでCloud Firestoreを利用する時は通常Node.jsによるCloud Functionsでトリガーとなる処理を記述します。その他には関連するAPIサーバー、WebアプリのフロントエンドのSSR、バックエンドの非同期処理など、多くの場面でCloud Functionsが活用されています。 この開発→デプロイサイクルをお手軽に行ってくれるのがfirebase-toolsというnpmモジュールです。JavaScriptでFunctionを実装し、firebase deployコマンドを実行するだけでFirebaseプロジェクト用のCloud Funct
Knative Servingを用いて多数の開発環境APIを低コストで構築する - ZOZO TECH BLOG
はじめに こんにちは、技術本部ML・データ部MLOpsブロックの鹿山（@Ash_Kayamin）です。先日、20個の開発環境APIを用意し、各APIをリクエストに応じて動的に起動できる仕組みをKnative Servingを用いて構築しました。 この記事ではKnative Servingを利用した背景と、利用方法、はまりどころ、利用によって得られたコスト削減効果についてご紹介します。なお、今回はKubernetesクラスタのバージョンとの互換性の都合でKnativev1.3.1を利用しました。2022/9現在の最新バージョンはv1.7.1になりますのでご注意ください。 目次 はじめに 目次 課題：20個の異なる開発環境APIを低コストで提供したい 解決策：Knative Servingを用いて、リクエストに応じて動的にAPIサーバーを起動する仕組みを導入する Google Cloud上でA
Jung Giuk2023-08-292019年 LINE に Build Engineerとして入社し、現在は「アプリプラットフォーム開発室」のディベロッパーエクスペリエンス開発チームに携わっていて LINE iOSアプリのビルド環境やコードクォリティの改善に取り組んでいる。 はじめに こんにちは、ディベロッパーエクスペリエンス開発チームのJungです。 この記事では２年以上 LINE iOSのビルドシステムとして運用したBazelをやめることにした背景についてご紹介します。 Bazel導入とこれまでのLINE iOS LINE iOS は200万行以上のソースコードと200以上のモジュールで構成される大規模プロジェクトです。 LINE iOSのソースコードとモジュールの数が増えて規模を拡大し続けるにつれて、ビルド/テストの遅延と DX(デベロッパーエクスペリエンス) の低下という避けら
Goのテスト安定性向上のためにFlakyなテストを再試行する機能を導入する提案 - tomato3713’s blog
Go言語にFlakyなテストへのサポートを追加する提案が面白かったので紹介します。 概要 Flakyなテストとは、コードに変更がないにもかかわらずテストが成功したり失敗したりと不安定な実行結果になるテストのことです。 テスト結果は本来なら全て成功ならリリース可能、1つでも失敗すればバグがあるのでリリース不可のようにリリースの可否を判断するための情報です。 そのため、不安定なテストは書かないようにすることが大前提です。 しかし、実際にはflakyであるとわかっていても修正が難しかったり、修正するための時間がないのでそのまま残すという判断をすることもあります。 Flakyなテストは削除するというのも手ではありますが不安定であってもテストが無いよりはマシとして残すこともあると思います。 github.com この提案では、Flakyなテストを扱うための機能を追加するものです。 初めの提案内容は、
人に説明するのがスムーズにできなさそうなので、理論武装というか順序立てて話すためにこの記事をまとめる。 対象 ブラウザから利用するマルチプラットフォーム向けウェブアプリケーションの開発 モバイルのネイティブアプリ開発は含まない（知らないので） 利用言語はJava, JavaScript/TypeScriptを想定するが、特に言語に依存しない認識 開発経験はあるが、情報や経験が少なくて「よりよいプロダクト開発」の理想が描けない方への一助として作成 TL;DR 状況やベストプラクティスが目まぐるしく変わる現代において、すぐに変化できるソフトウェアを保つこと・ヒトの手をできるだけ空けることが重要。 かつてIaaSがAPIを提供し環境管理の多くを自動化したように、各種サービスがAPIやWebhookを通じてDevelopment Workflowの多くを自動化してきている。 多くの視点や知見を活か
turborepo で monorepo の差分ビルド
Turborepo vercel が開発した monorepo 環境のためのビルドツールです。vercel ですが next 非依存です。 turborepo が何を解決するか node.js に限らず monorepo 環境下では、それぞれの内部モジュールのビルドは個別に行われることが多いです。ここでいう内部モジュールは、 package.json を持つディレクトリ単位、と捉えてもらって結構です。 apps/ web/ package.json # => foo, bar を参照 packages/ foo/ package.json dist/ index.js bar/ package.json # => foo を参照 dist/ index.js package.json このビルドが、(ビルドしない素の js と比べて)面倒な問題を引き起こします。 更新時にビルドを忘れて古い
自分は今は社内 Monorepo での作業がメインで、たまに Android とかさわってる。 レポジトリの壁というか、レポジトリの違いを含むインフラの違いの壁は、組織の壁より厚い。 この話は前にも書いたことがある。 だから向井さんの言っていることはよくわかる。 Monorepo が強制するインフラ共通化が押し下げた組織の壁の低さを、しばしば実感する。 たとえば最近だと、仕事でやっている Android アプリの APK のビルド方法が変わった際にビルドツールチェインにあるマイナーなバグにあたってしまい、 そのツールのバグを直したことがあった。そんなツールがあるとは知らなかったというくらい降って湧いた話。 でもビルドシステムが統一されているおかげでコードをビルドするのもテストするのも簡単で、 IDE も普段の設定そのまま。コードレビューもいつもと同じ。 はじめてのコードベース、レビュー相手
Turborepo is a high-performance build system for JavaScript and TypeScript codebases. We're reimagining build systems, taking inspiration from tools like Buck and Bazel, to make them accessible for everyone. At the heart of Turborepo is a very simple idea: never do the same work twice. We accomplish this through incremental builds, parallel execution, and Remote Caching. As usage has grown and pro
Raspberry Pi4 で TensorFlow Lite GPU Delegate (OpenGLES) を試す - Qiita
0. 更新履歴 (2020/06/27) Tensorflow r2.3用に記述内容を全面修正しました。 1. はじめに ラズパイ４の OpenGLES はリリース当初 ver 3.0 でしたが、2020/1月に ver 3.1 にアップデートされました。 OpenGLES 3.1 では、ComputeShader が使えるようになり、GPGPUプログラミングしやすくなります。超うれしいアップデートです。 一方 TensorFlow Lite には、推論にかかる演算処理を CPUからGPU にオフロードする GPU Delegate 機能があります。 この GPU Delegate は、さらに V1(OpenGLES) と V2(OpenCL) とがあり、V1 は OpenGLES 3.1 が使える環境であれば動かすことができます。V2は OpenCL が使える環境での動作を想定しています
It's Time to Forget About Docker | Martin Heinz | Personal Website & Blog
In the ancient times of containers (really more like 4 years ago) Docker was the only player in the container game. That's not the case anymore though and Docker is not the only, but rather just another container engine on the landscape. Docker allows us to build, run, pull, push or inspect container images, but for each of these tasks there are other alternative tools, which might just do better
R&D チームの奥村（@izariuo440）です。EfficientDet がブラウザで動いているのを見たことがなかったので、やってみました。以下はブラウザで実行中の様子1です。 結果として、EfficientDet-D0 で 256x256 の解像度の画像を TensorFlow Lite で推論させると、ネイティブで 20 FPS、WebAssembly SIMD support ありの Chrome で 7 FPS 程度の速度性能を確認できました。 Case XNNPACK XNNPACK スレッド数 FPS A OFF N/A 4 B ON 1 15 C ON 4 20 測定環境は MacBook Pro (Retina, 15-inch, Mid 2015) の 2.5 GHz です。 背景と動機 周辺知識 EfficentDet EfficientDet の精度 Effici
Compression Dictionary Transport (Shared Brotli) によるコンテンツ圧縮の最適化 | blog.jxck.io
Intro Chrome で Compression Dictionary Transport の Experiment が行われている。 Intent to Experiment: Compression dictionary transport with Shared Brotli https://groups.google.com/a/chromium.org/g/blink-dev/c/NgH-BeYO72E この提案の仕様および本サイトへの適用について解説する。 brotli の Dictionary 圧縮方式は、基本的に「同じ値が出てきたら、それらをまとめて小さく表現する」という方式が中心となる。 # 繰り返しを数値で表現する場合 from: aaaabbbbb to: a4b5 この方式は、対象としたデータの中で、如何に効率よく「同じ値」を見つけるかが肝となる。例えば以下の例
LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog LINEの技術組織が取り組んでいる・今後取り組む未解決課題を深堀りするインタビューシリーズ「Unresolved Tech Issue」をスタートします。今回のテーマは「LINEアプリのさらなるモバイル体験向上に向けた改善・開発」です。 数億人のユーザーがコミュニケーションに利用するLINEアプリのクライアント開発組織では、2021年にモバイルエクスペリエンス開発室を立ち上げました。この開発室では、iOS/Androidの新機能対応やLINEアプリを複数のデバイスで利用する際の体験向上、モバイルプラットフォーム特有のビルド課題の改善などに挑んでいます。 モバイルエクスペリエンス開発室の活動の詳細について、室長の早石明浩と副室長
TIGの渋川です。 CNCF連載の第4回は、CNCFのSandboxプロジェクトのBuildpacksについて紹介します。 https://buildpacks.io BuildpacksとはHerokuがオリジナルで作ったビルドツールです。HerokuのオリジナルはHerokuのプラットフォーム用のビルドツールだったと思いますが（使ったことはない）、CNCF版はコンテナイメージを作成します。オリジナル版とはいろいろ違いがあり、区別をつけるためにCloud Native Buildpacks（略してCNB）と呼称されているようです。 ツールの方針としては、ビルド設定ファイルのようなものを作らなくても（実行情報のみを書いたファイル、project.tomlは書ける）ソースコードを与えるだけで、Dockerfileなどを使わずにDockerimageが作れます。 使い方は簡単で、作業フォルダで
The Legends of Runeterra CI/CD Pipeline Hi, I’m Guy Kisel, and I’m a software engineer on Legends of Runeterra’s Production Engineering: Shared Tools, Automation, and Build team (PE:STAB for short). My team is responsible for solving cross-team shared client technology issues and increasing development efficiency. We focus on the areas that empower other teams to do more and protect the team from
Cloud Deploy 実践編: CI との連携
前回『デプロイに全集中！新サービス Cloud Deploy』では、Cloud Deploy （現在プレビュー段階です）の背景にある思想 & 基本的な使い方をご紹介しました。今回は少し視野を広げ CI との関係を知り、連携して動かすことをゴールに、その過程で考慮すべきポイントも併せてご紹介します。 TL;DRCI と CD の管理主体が分かれます、改めて理想を検討しましょうgit リポジトリでテスト・ビルド・デプロイ “方法” を管理CI でテストし、ビルドし、成果物をまとめるCD で成果物とデプロイ先の管理 & ロールアウト / ロールバックこの 3 つを繋ぐのは Skaffold ローカルから実行環境までの様々な環境差異視野を広げつつも、今回も Google はどんなことを課題と捉え、何を解決しようとしているのかを一緒に考えてみたいと思います。 CI / CD パイプラインパイプライン
2021年10月以降の Mozc に対する主な変更
初稿: 2022-10-10 2021 年 10 月以降の Mozc に対する主な変更をまとめました。ドキュメントやコミットログ、 Issues に書かれているものをまとめただけで新しい情報はありません。抜けているものがあれば後で追記します。 Mozc の問題の報告や機能の要望等は、GitHub の Issues や Discussions へお願いします。 前回: 2020 年以降の Mozc に対する主な変更 次回: 2022 年10月以降の Mozc に対する主な変更 統計情報 コミット数: 509 クローズした issue の数: 91 (Issues · google/mozc) マージしたプルリクエスト数: 2 (Pull requests · google/mozc) ビルド関連 GYP から Bazel への移行 GYP はメンテナンスモード。今後は非推奨に。 GYP での
'); doc.close(); } if (!doc) throw Error('base not supported'); var baseTag = doc.createElement('base'); baseTag.href = base; doc.getElementsByTagName('head')[0].appendChild(baseTag); var anchor = doc.createElement('a'); anchor.href = url; return anchor.href; } finally { if (iframe) iframe.parentNode.removeChild(iframe); } }()); } // An inner object implementing URLUtils (either a native URL // ob
【これはUnipos Advent Calendar 2021の2日目の記事です】 つい最近、EarthlyというDockerコンテナベースのビルドツールで、自分の開発しているGoのアプリケーションのMakefile/Dockerfile/docker-compose.yamlを置き換えたのでそれを記事にしてみる。 Earthlyとは github.com めちゃくちゃ雑に言うとDockerイメージをベースにしたビルドツール。 できることとしてはGoogleが作っているBazelに近い*1が、書き味はMakefile+Dockerfileに近く*2、独特の文法が少ない雰囲気。当然、言語やフレームワークに依存しない。まるでローカル環境でビルドをしているかのようにシームレスにコンテナ環境でビルドを実行できる。 Earthlyは書き味こそDockerfileと似ているが、Dockerイメージを作
こんにちは！SouzohのMLチームでSoftware Engineerをしているwakanaです。 SouzohのMLチームは2021年4月にスタートし、ちょうど2年が経ちます。当時1人だったメンバーも、今では4人になり、レコメンデーションを中心に5, 6個の機能を提供するようになりました。MLOpsも成熟し、より新しく高度なML機能開発に集中して取り組める環境が整ってきていると感じています。 そこでこの記事では、立ち上げから2年たった今SouzohのPython, ML環境がどのようになっているか紹介しようと思います。これからPythonやMLのMonorepoでの開発環境を整えようとしている方、特に少人数での運用を考えてる方の参考になれば嬉しいです。 TL;DR SouzohではPoetry, Bazel, VertexAI Pipelinesで快適なMonorepo開発環境を実現
TL;DR goccy/go-graphviz が新しくなり、cgo を使って Graphviz の機能をバインディングしていたところを WebAssembly ( 以降 WASM ) ベースに置き換えたため、晴れて Pure Go になりました。 一部 API のインターフェースが少し変わっていますが、以前できたDOT言語の読み書きやSVG、PNGとしての出力などは全て可能です。それに加え、図中の画像のレンダリングサポートやフォントまわりの改善、最新のGraphvizライブラリへの対応により以前よりもレンダリング処理が改善されています。 また、任意の出力フォーマットに対するレンダリング処理をプラグイン形式で外から追加できるようになったので、terraform graph の内容を読んで構成図を出力するとか、アスキーアート出力するみたいな特殊な処理が実装しやすくなりました。 Graphvi
今 Earthly というビルドツールが (自分の中で) 俄かに話題になっています．自分で手を動かしてサンプルコードを作ってみたので，それを基に簡単に機能を紹介したいと思います．題材は Go + gRPC です． Earthly って何？ Earthly は Makefile と Dockerfile を足したような書き味のビルドツールで， Makefile のように複数のタスクを定義し，タスクの中で Dockerfile を書くような感じでテストのような命令を実行したり，イメージを生成して保存したりできます． すでに他の方が Earthly を紹介している記事もあるのでぜひご覧ください． Earthly の大きな特徴は "Makefile + Dockerfile 風な構文の馴染みやすさ"， "タスクをコンテナ上で実行することによる可搬性の高さ"， "ビルドキャッシュの仕組みの簡単さ (
'); doc.close(); } if (!doc) throw Error('base not supported'); var baseTag = doc.createElement('base'); baseTag.href = base; doc.getElementsByTagName('head')[0].appendChild(baseTag); var anchor = doc.createElement('a'); anchor.href = url; return anchor.href; } finally { if (iframe) iframe.parentNode.removeChild(iframe); } }()); } // An inner object implementing URLUtils (either a native URL // ob
Lyra - enabling voice calls for the next billion users
The latest news from Google on open source releases, major projects, events, and student outreach programs. The past year has shown just how vital online communication is to our lives. Never before has it been more important to clearly understand one another online, regardless of where you are and whatever network conditions are available. That’s why in February we introduced Lyra: a revolutionary
3ヶ月で120のリポジトリを1つのMonorepo(モノレポ/モノリポ)に移行した話 - asoview! Tech Blog
PolyrepoとMonorepo これはアソビュー！ Advent Calendar 2022の23日目です。 アソビューでVPoE兼Tech Leadをしているdisc99🐼です！ 今回は、Monorepo運用の事例紹介をさせてもらえればと思います！ アソビューではほぼすべてのGitリポジトリを統合したMonorepo運用を2年以上行っています。 最近では特定の技術領域やプロダクトに対してMonorepoを適用した事例は増えてきています。 しかし、社内のほぼすべてのソースコードを1つのMonorepoで管理している組織はまだ多くないと思いますので、参考になれば幸いです。 今回はなぜMonorepoに移行したかや、具体的にどのような管理をしているか、また今後の展望などを公開します！ 🐣なぜMonorepoなのか 背景 Monorepoとは？ 素早さ 分かりやすさ 管理のしやすさ その
'); doc.close(); } if (!doc) throw Error('base not supported'); var baseTag = doc.createElement('base'); baseTag.href = base; doc.getElementsByTagName('head')[0].appendChild(baseTag); var anchor = doc.createElement('a'); anchor.href = url; return anchor.href; } finally { if (iframe) iframe.parentNode.removeChild(iframe); } }()); } // An inner object implementing URLUtils (either a native URL // ob
CoC が苦手な奴、認知資源が乏しいだけ説 「設定より規約」「CoC (Convention over Configuration)」と呼ばれる設計思想がある。 参考：設定より規約 - Wikipedia フレームワークやライブラリ側で、ベストプラクティスなデフォルト設定を規約として決めておくから、利用する開発者はイチイチ考えなくていいよ、というワケだ。 コレは、ともすれば、「Opinionated (自己主張的)」なフレームワークやライブラリだとみなすこともできるだろう。 参考：Opinionatedなライブラリとチーム開発 - Runner in the High 僕は CoC が割と好きだし、CoC か否かに関わらず、Opinionated なツールも好きである。だが、自分の回りでは「CoC が苦手」とか「柔軟性のないフレームワークは嫌い」といった人が多く、疑問を持っていた。 今回、
Secretlintはmonorepoとなっていて、パッケージを公開する際にlernaを利用していました。 しかし、lernaは現在メンテナンスされていないため、publish機能だけを取り出したlerna-liteと効率的なmonorepo向けのビルドツールであるTurborepoへ移行しました。 Lerna is largely unmaintained · Issue #2703 · lerna/lerna 追記: NxによってLernaがメンテナンスされるそうです。 Announcement: Passing the torch · Issue #3121 · lerna/lerna Lerna is dead — Long Live Lerna. If you’re in a hurry, here’s the TL;DR: | by Juri Strumpflohner | M
のがもはや半年前だけど記録として書いておく。結論を書くと、ecs-deployからecspressoに乗り換えるのはすぐできるし、タスク定義が管理しやすくなるのでおすすめです。 https://github.com/kayac/ecspresso もともとNature社では僕が入社する前からecs-deployが使われていた。これは、コンテナイメージをすげ替えてdeployするだけであればシンプルでわかりやすい。ただ、以下のような課題があった。 タスク定義自体を変更したい時にecs-deployだけでは対応できない ソースがbashスクリプトで年々複雑になっており(僕には)読みづらい 実際度々メンテナンスが滞ったりforkがいくつかあったりする jqやawsコマンドに依存している それに対して、ecspressoは以下のような利点があった。 タスク定義ごとリポジトリ管理できる Goなので(
On my quest towards building a GoLang Desktop application I found some useful frameworks, Lorca and Webview (which I wrote about in my previous post). These frameworks create a window which GoLang can inject HTML, CSS, and JavaScript to build the UI. But I don’t want to write JavaScript(!) and deal with all the complexities that comes with it like npm, webpack, typescript… Fortunately, I can just
監視資本主義: デジタル社会がもたらす光と影 | Netflix (ネットフリックス) 公式サイト
'); doc.close(); } if (!doc) throw Error('base not supported'); var baseTag = doc.createElement('base'); baseTag.href = base; doc.getElementsByTagName('head')[0].appendChild(baseTag); var anchor = doc.createElement('a'); anchor.href = url; return anchor.href; } finally { if (iframe) iframe.parentNode.removeChild(iframe); } }()); } // An inner object implementing URLUtils (either a native URL // ob
Jest 27 について
https://jestjs.io/blog/2021/05/25/jest-27 についてまとめる。筆者は Jest についてあまり詳しくないので、記事中に誤りがあった場合はコメントで指摘していただけると嬉しい。 Jest 27 では Jest 15.0: New Defaults for Jest以降初の大幅なデフォルトの見直しが行われた。 また、そのような変更だけでなく、いくつかの新機能も実装されている。 新機能 比較的小さめなものとしては ESM のネイティブサポートが進んではいるが、モッキングなどの大きな複雑な問題が残っている。 シンボリックリンクとして置かれたテストファイルも適切に扱えるようになった。これは Bazel ユーザーが主に望んていたようだ。 transformを非同期にできるようになった。これは esbuild や snowpack、vite などのツールを介したト
Lars Gyrup Brink Nielsen for This is Angular Posted on Jul 21, 2020 • Updated on Nov 15, 2020 Cover photo by Pixabay on Pexels. The views expressed in this opinion piece are entirely my own. They do not represent any organization. You're going down a dark, murky, slippery road and you've lost your way. What do you do? Keep moving while acting like everything is alright? Or stop and ask for help? T
はじめに 2022/07/19、C++ の後継言語の Carbon が発表されました。 最大の特徴としては、C++ との双方向の相互運用性です。 TypeScript や Kotlin と役割が近いですね。 Rust でいいのでは？ はい、その認識で間違いないようです。 公式の FAQ でも「f you can use Rust, ignore Carbon」と記載されています。 あくまで、C++ に大きく依存するプロジェクト向けのようです。 Editor は？ contribution_tools に記載されている通り、基本的には Vim で、数名 Visual Studio Code を利用しているメンバーがいるくらいのようです。 ただ、Carbon 用のプラグインはまだないようなので、本格的に開発するのはまだまだ難しそうです。 言語仕様 Language design に記載されてい
Image from UnSplash I’ve led infrastructure at a startup for the past 4 years that has had to scale quickly. From the beginning I made some core decisions that the company has had to stick to, for better or worse, these past four years. This post will list some of the major decisions made and if I endorse them for your startup, or if I regret them and advise you to pick something else. AWS Link to
関数を組み合わせてシステムを組む「Haskell」。クセの強さがその魅力？〜エンジニアが語る技術愛 ＃01〜｜ミクシル
ミクシィには、探究心溢れるエンジニアがたくさん在籍しています。 その探究心は業務で扱う技術にとどまらず、趣味で書いているプログラムだったり、個人的に研究している言語だったりと、自身の気になった技術への追求も留まることを知りません。 そこで、社内のエンジニアに“好きな技術”について、思う存分に語ってもらうシリーズを始めました。 ルールはこの通り。 ・業務で使っている技術でも、使われていない技術でもOK ・あくまでも個人的な見解で ・その技術のどこが面白いのか ・愛を込めて語り尽くしてもらう 第1回目は、「モンスターストライク（以下モンスト）」のサーバーエンジニアの松原に、関数型プログラミング言語「Haskell」についていったい何が面白いのか、どういうものなのか、好きなだけ語ってもらいました。 有名プログラミング言語のナレッジが通用しづらい独特な「Haskell」 ━━今日は好きな技術につい
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Googleからの撤退〜シン・すべてがNになる〜 - エンタングルメントosugi3yのブログ
メルカリiOSアプリのBazelを使った高速・高信頼性ビルド | メルカリエンジニアリング
minne iOSの2021年の開発環境 - Pepabo Tech Portal
PyTorch vs TensorFlow in 2023
LINEはなぜBazelを使わないことにしたのか？
考察：Reactive Workflowが生まれた背景とその狙い - Kengo's blog
モノレポ好きじゃない / morrita - Message Passing
Why Turborepo is migrating from Go to Rust – Vercel
物体検出器 EfficientDet をブラウザで高速推論 - OPTiM TECH BLOG
LINEアプリのさらなる体験向上のために。モバイルエクスペリエンス開発室が目指すビジョン
Buildpacksのビルダーをスクラッチから作ってみる | フューチャー技術ブログ
The Legends of Runeterra CI/CD Pipeline
大奥 | Netflix (ネットフリックス) 公式サイト
Earthlyでコンテナ時代のビルド環境を味わう - Runner in the High
メルカリShopsを支えるMonorepo ML開発環境 | メルカリエンジニアリング
go-graphviz が新しくなりました - Route54
gRPC サーバのビルドに Earthly を使ってみよう
Netflix (ネットフリックス) 日本 - 大好きな映画やドラマを楽しもう!
赤ちゃんを科学する | Netflix (ネットフリックス) 公式サイト
CoC が苦手な奴、認知資源が乏しいだけ説 - Neo's World
lernaからlerna-lite + turborepoに移行する
ecs-deployからecspressoに乗り換えた | おそらくはそれさえも平凡な日々
GoLang Desktop App with webview/Lorca, WASM and Bazel
Angular struggles in 2020
Carbon Language が発表されたので実際に動かしてみた
(Almost) Every infrastructure decision I endorse or regret after 4 years running infrastructure at a startup