GraphQLはどんな時に使うか@saboyutaka 合同会社春秋 Tech Base Okinawa 2023
GitHub Actions で Xcode のインクリメンタルビルドを実現する (xcode-cache アクション) - Qiita
GitHub Actions で iOS アプリをビルドするときの Xcode のインクリメンタルビルドを有効にするためのキャッシュ設定について解説します。 CI でのビルドで Xcode のインクリメンタルビルドが使えるようになれば、毎回 CI 上でフルビルドし40分程度かかっていたプロジェクトが、差分のみのビルドでビルド時間が5分に短縮されたりすることが期待できます。 環境 この記事では、以下の環境で調査・検証した結果を記載しています。 ローカル環境 macOS Ventura 13.5.1 Xcode 14.3.1 (14E300c) APFS (Encrypted / Case Insentive) GitHub Actions 環境 macos-latest macOS Monterey 12.6.8 Xcode 14.2.0 (14C18) 結論 結論としては xcode-ca
SwiftUIのレンダリングループについて
はじめに レンダリングループとはアプリが起動している間常に起動している処理です。 例えば、タッチイベントはOSからアプリに伝えられ、アプリはUIの変更をOSに伝え、OSがフレームを最終的にレンダリングして私たちの目に見える変化となって現れます。 SwiftUIはこの内部実装がよく隠されていて、そうしたレンダリングループのことを一切考えずに次のようにViewを構築できます。 struct TestView: View { var body: some View { VStack { Image(systemName: "face.smiling") Text("Hello World!") } } } このようにレンダリングに関する意識を関心から外すことで、私たちはViewの構築に集中することができます。一方で完全にレンダリングを意識の外に追いやると、コミットヒッチやレンダーヒッチなどユーザ
プラットフォームエンジニアリング (Platform Engineering) とは？
TL;DR 昨年、2022 年頃から急激に注目を集め始めバズワードとなっている "Platform Engineering" については、Zenn を見ている方たちの多くも注目をしているのではないかなと思います。 日本国内でも関心の高まりはいたるところで目にするようになってきているので、どういうものなのか簡単に "製品ベンダーの中の人" の目線から説明してみたいと思います。 注釈 "製品ベンダーの中の人" の目線と書いたように、ぼく自身は決して Platform Engineer ではありません。そのため、実践した経験をもとに Platform Engineering について説明しているわけではないことを了承していただければと思います。 どうしても、Platform Engineer のコンセプト的に製品ベンダーの人が話す内容と、実践している Platform Engineer の視点と
2023年のシェル環境構築
tl;dr fig starship zsh fzf sheldon なぜ vscode の .vscode/tasks.json が fishと非常に相性が悪い。とくに fish-nvm を使っていると、fish 経由のパス実行時に node と npm へパスが通らない。 そもそも fish を使っていた理由は autocomplete を快適にするためだったが、1年ぐらい Fig を使っていて、補完はこれを任せていいと気づいた。 Fig はこういうやつ そもそも fish の拡張コマンドを使わないように生活していた。方言を覚えたくない。というか bash 拡張や zsh 拡張もあんまり覚えたくない。
Mirrativ iOSアプリでのメモリ使用量削減への取り組み - Mirrativ Tech Blog
こんにちは、iOSエンジニアのふじのです。 Mirrativの機能開発を進める傍ら、iOSアプリのメモリ使用量の改善に取り組んでいます。 今回は、アプリ内でメモリ使用量を増やしている問題点を見つける方法と、それらをクライアント実装で解決する具体的なアプローチについて紹介します。 Mirrativアプリが抱える課題 着眼点とアプローチ 画像キャッシュの効率化 UIImageのリサイズ 画像のメモリキャッシュの上限サイズ設定 メモリリークへの対策 Allocationsやmemory graphを利用した手動検出 XCTestを利用したCI上での自動検出 改善の成果と今後の課題 We are hiring! 参考リンク Mirrativアプリが抱える課題 Mirrativアプリはライブ配信機能や視聴機能、Unityを利用したアバター機能やWebGLを利用したゲーム機能など、メモリを多く必要とす
Swift 5.5から登場したActorについて
サンプルコード https://github.com/SatoTakeshiX/first-step-swift-concurrency/tree/main/try-concurrency.playground 対応するサンプルコードにはページ名を記載します。 検証環境 Xcode 13.2.1 Swift 5.5 データ競合 マルチスレッドプログラミングにおいて、重要な問題はデータ競合（data race)をいかに防ぐかです。複数のスレッドから一つのデータにアクセスした場合、あるスレッドがデータを更新するとデータが不整合を起こしてしまう可能性があります。デバックが非常に難しくやっかいなバグをになることが多いです。 データ競合がどういうものかをコードで解説します。 例えばゲームの点数を管理するScoreという型をクラスで定義します。 // Page: 3-1-data-race class
Introducing Swift Concurrency to Merpay code | Mercari Engineering
This post is for Day 23 of Merpay Advent Calendar 2022, brought to you by takeshi from Merpay iOS Team. Introduction Since Swift 5.5 was released in 2021, we are able to use Swift Concurrency. Swift Concurrency prevents your code from data races and provides a simple way to implement async code. It is big news for iOS developers. Merpay iOS team attempts to introduce Swift Concurrency into our cod
警察が嫌がる苦情の入れ方（警察にとってダメージの大きい苦情の入れ方） | 元警察官による暴露ブログ
「警察官に暴言を吐かれた！」 「職質してきた警察官が横柄な態度をとってきた。こちらは協力してやったのに気に喰わない」 このような警察官の職務中の態度や問題行動について苦情を入れたくなるときってありませんか？ 警察官の立場としては、なるべく苦情を受け付けたくはないし、できれば知らないフリをして逃げたいところです。ですがあまりにも横柄な態度をとる警察官がいたり、権力を振りかざすような警察官がいるのも事実。 そこで今回は「警察官が嫌がる苦情の入れ方」「警察組織に対する効果的な苦情の入れ方」についてご紹介します。 この方法で苦情を入れれば効果てきめん！苦情が警察内部で゛なかったこと゛にされて悔しい思いをすることもなくあなたの意見がすんなりと受け入れられ、警察官の行動や態度は劇的に改善されるでしょう。 警察官が嫌がる苦情には、 公安委員会苦情 監察苦情 の2種類があります。 都道府県公安委員会に苦情
最小限のコードで動く最も汚いコードから始める
最小限のコードで動く最も汚いコードから始める 2023.09.02 コードを書く際の重要な要点は、読みやすく他人に理解される「良いコード」を書くことです。しかし、完璧を目指して最初から書こうとすると行き詰まります。代わりに、荒削りながらも動くコードを作成し、徐々にリファクタリングして完成度を高めます。型エラーやリントエラーを無視しても構わないので、まずは動くものを作成しましょう。それからリファクタリングして「良いコード」を作成できます。 コードを書くときに最も大切なことってなんだろう？聡明な読者諸君ならご存知だろうが、コードは書く時間よりも読む時間のほうが長い。だから他人に読まれることを意識して、読みやすい「良いコード」を書かなくっちゃならない。コンポーネントは適切な粒度で分割されていて、適切な名前がつけられている。型システムに安全性だって守られてるし、最新のなんとかアーキテクチャにも準拠
ハッカーの呪いと共に生きる ~ The hacker is dead, long live the hacker! - An Epicurean
私がWeb業界に入ったのは、ハッカーに対する憧れからです。その原体験を大事にしたいという気持ちを今でも強く持っています。 もう20年近く前になりますが、Web2.0の時代、私は傍観者でした。世界ではGoogleを筆頭として、日本でも、はてな社などが、エンジニアドリブンで個性的なサービスを生み出していました。他にもmiyagawaさんなど、個人で世界的に使われるようなOSSを開発している人もいました。書籍「ハッカーと画家」で描かれるような、ハッカーが個人技で大企業を出し抜く痛快さがありました。 そのように、WebサービスにせよOSSにせよ、同年代のハッカーが自分の技術でイノベーションを起こし、世の中に影響を及ぼしていることに羨望の眼差しを向けていたのです。 サブカル的な空気感も好ましく思っていました。西海岸のコンピュータ文化はヒッピーカルチャーの影響を受けていたのは間違いないでしょう。当時の
(翻訳) ビッグテックのプロジェクトマネジメントとスクラム不在の謎 - forest book
本稿は Gergely Orosz 氏によって書かれた次の記事の日本語翻訳です。著者に翻訳の許可を得て公開しています。 blog.pragmaticengineer.com また本稿は DeepL Pro を使って下訳したものに手を加えています。日本語翻訳の不具合または誤訳については Gergely Orosz 氏ではなく、本稿のコメント欄にお願いします。 著者も機械翻訳を下地にしたやり方に関心をもたれたようです。 The article translated to Japanese: https://t.co/4uynyyhm4E The author was transparent and noted that the article is a modification of an ML-translated article. This person managed to transl
サーモン、K-POP、ピアノ、パイナップル……日本産水産物だけじゃない中国の経済制裁 - 斗比主閲子の姑日記
東京電力福島第一原発の処理水の海洋放出に対して、中国が日本産の水産物の禁輸措置を行っています。2022年水準で871億円で、半分強がホタテです。 中国、日本産水産物の輸入を全面停止(中国、日本) | ビジネス短信 ―ジェトロの海外ニュース - ジェトロ 2021年以降、日本にとって中国は世界1位の農林水産物・食品の輸出相手国となっている。農林水産省によれば、2022年の日本から中国への農林水産物・食品の輸出額は前年比25.1％増の2,782億円で、全体の20.8％を占めた。中国向け輸出額のうち水産物は871億円、品目別ではホタテ貝が467億円、なまこ（調製）が79億円、かつお・まぐろ類が40億円となっている。 ちなみに、中国以外の国だと、JETROのニュースを見る限り、こんな反応です。 ALPS処理水の処分に伴う輸出等の対策に関する特別相談窓口および各国・地域の動向について | 農林水産物
LINEはなぜBazelを使わないことにしたのか？
Jung Giuk2023-08-292019年 LINE に Build Engineerとして入社し、現在は「アプリプラットフォーム開発室」のディベロッパーエクスペリエンス開発チームに携わっていて LINE iOSアプリのビルド環境やコードクォリティの改善に取り組んでいる。 はじめに こんにちは、ディベロッパーエクスペリエンス開発チームのJungです。 この記事では２年以上 LINE iOSのビルドシステムとして運用したBazelをやめることにした背景についてご紹介します。 Bazel導入とこれまでのLINE iOS LINE iOS は200万行以上のソースコードと200以上のモジュールで構成される大規模プロジェクトです。 LINE iOSのソースコードとモジュールの数が増えて規模を拡大し続けるにつれて、ビルド/テストの遅延と DX(デベロッパーエクスペリエンス) の低下という避けら
SREはインフラエンジニアだけでなく、みんなの活動 - ytake blog
みなさんSREしてますか？ サービスなどの品質を維持していくために切っても切り離せないSREですが、 日本でもSREという言葉が定着しつつあるかと思います。 このSREについて書いていきたいと思います。 SRE NextのCFP忘れてたのでその代わりに・・ SREってインフラですよね？ 非常によくあるケース、というか多分ほとんどがこうなっていると思います。 もちろん会社としてインフラのことを指しても問題はありませんが、 SREとはどういうものなのか、正しく認識して今一度現状を振り返ることで さらに良い活動に繋がることが多いと思います。 なんのこっちゃ、という方も多いかもしれません。 SREはエラーバジェットなどの話が必ず出てきますので、 モニタリングや監視などが必ずセットにはなっていきます。 ですが、この部分が強調されているのかどうしてもインフラエンジニアでしょ、 というのが定着している場
スムーズに進行するためのエンジニアリングタスク分割の工夫 - $shibayu36->blog;
会社の振り返りで「エンジニアリングの作業タスクがうまく分割できていそうだったが、その知見を共有してほしい」と言われたので、自分がどう考えてタスク分割をしているかをこの記事で共有したい。 この記事のスコープとすること・しないこと タスク分割をするときの工夫点 少なくとも1スプリント以内で終わるタスクになっている 完了条件が明確である 開始から終了まで他タスクによる待ち時間がない 他タスクが待ち状態になる時間を最小限にする 自分にとって難易度の高いものが1タスクの中で1つである 初めから完璧なタスク分割を目指さない 工夫を考慮した分割例 まとめ この記事のスコープとすること・しないこと 今回の記事では、あるユーザーストーリーが存在するとして、その設計・実装・テストなどをスムーズに進行するための工夫について書く。 逆に次のようなタスク分割については取り扱わない。 ユーザーに提供すべき価値があると
Obsidianを使って生産性を高める - Qiita
目次 1.はじめに 2.Obsidianとは 3.Obsidianのインストール 4.プラグインの導入 5.おすすめのプラグイン 6.Obsidian参考サイト 7.おわりに 1. はじめに 生産性を高めるツールは色々存在します。 タスク管理を例に挙げると、私はタスク管理にはカンバンツールが好きで、オフラインで使えるWekanやFocalBoardというツールを使ってきました。 しかし、タスク管理は〇〇、エディタは△△、作業記録は××といったように複数のツールを使うのは非常に面倒です。 機会があってマークダウンエディタであるObsidianを活用する方法を調べてみたところ、このツール1つで様々なツールの代替ができて非常に有用だと感じたので、Obsidianの導入方法とタスク管理機能を含めた個人的におすすめなプラグインを紹介し、Obsidianの活用方法を紹介していこうと思います。 まだまだ
第7回 テストコードの認知負荷 ～テストの名前、構造、情報量を工夫する～ | gihyo.jp
サバンナ便り ～ソフトウェア開発の荒野を生き抜く～ 第7回テストコードの認知負荷 ～テストの名前、構造、情報量を工夫する～ 開発の現場では、既存のテストコードから仕様を読み解く機会がよく訪れます。そのようなとき、テスト対象の仕様やテストの意図を読み解きやすいテストとそうではないテストがあることに気付きます。今回はテストコードの読み解きやすさに寄与する要素を考えます。 認知資源と認知負荷 人間は何かを読み解くときに脳のリソース（脳内のワーキングメモリ）を使います。リソースの量は有限で、個人差があります。このような脳のリソースは「認知資源」と呼ばれています。 人間が何かを読み解くときに認知資源が何にどのくらい割かれているかという概念を「認知負荷」と言います。「どのくらい」は状況に左右されます。たとえば、読み解く対象を知っているかどうかで認知資源が割かれる量は変化します。「何に」も状
個人的にワーキングメモリーを鍛えるのに役立ったなと感じた事を挙げる。 ..
個人的にワーキングメモリーを鍛えるのに役立ったなと感じた事を挙げる。 自分も増田の言及している人物と似たようなレベルだったが、これらを続けて別人レベルに改善されたと思う。 まだまだこういった情報は世の中に普及してないので、知らずにもったいない人生を送っている人がたくさんいるだろう。 断捨離＆整理整頓これはマジで効く。騙されたと思ってこんまりの本を読んでから思いっきり断捨離してほしい。 （なぜ先にこんまりの本を読むかというと、物が多いやつが自分のそれまでの考え方を引き継いで断捨離したところで捨てられないままだからだ。外部からマインドに介入する必要がある） 物の多さに専有されてた脳内メモリーが解放されかなり頭がスッキリする。 何があるか、どの場所にあるか、いくつあるか、普段は意識してなくても無意識に脳が使われていた諸々の情報が一気にクリアされるのだから当然だ。 ADHDだから物に溢れるのではな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
複雑さに立ち向かうためのコードリーディング入門
