改行されているときに、文が終わっている時もあれば、文が続いている時もあって、これは前の行からの続きなのか、別の文なのかを毎回意識する必要があって読みにくいなと思ってしまうパーソンです。皆さんはいかがですか?
この記事は はてなエンジニア Advent Calendar 2022 の2023年1月3日の記事です。 昨日は id:onk で ストーリー性のあるプレゼン - id:onk のはてなブログ でした。 『Production Ready GraphQL』といえば Production Ready GraphQLはGraphQLを採用するなら必ず読んでおきたい良書 などでも紹介されていますが、GraphQL APIを設計・開発・利用するなら大変参考になる良書ですね。はてな社内でもGraphQL開発における前提本ですね、などと言われている模様です。 この中で好きな箇所の1つが「Specific or Generic」という節の「Anemic GraphQL」という項です。たくさん引用するわけにもいかないので冒頭だけ見ますと、 Anemic GraphQL is something I sto
Renovateは様々なデータソース・パッケージマネージャーに対応していて、もちろんRubyのBundlerのGemfileにも対応しているのだが、APIリクエストのレートリミットを回避する関係で、https://rubygems.org をデータソースとする場合はリリースノートの取得ができなくなっている。 これが不便で、自分達のチームではGemfileの更新にはDependabotを併用するという面倒な運用をしていた。最近になってこれを部分的に解消できる設定がRenovateに誕生したのでご紹介。 customChangelogUrlという設定を使うと、あるパッケージのリリースノートを探しにいくURLを指定することができる。これを使うとGitHubやGitLabの該当リポジトリのReleasesや CHANGELOG.md などからリリースノートをリストアップしてくれる。 例えばfast
とあるAPIのスキーマの叩き台をクライアントサイドとして検討している際に、コンテンツの公開期間やイベントの開催期間のような期間について議論が少し盛り上がった。 要件としては、期間の開始と終了の日時をそれぞれ取得できたい。 期間を考える時、開始と終了がそれぞれinclusiveなのかexclusiveなのかをまず考慮すべきであるが、開始日時の重複や終了日時に隙間を発生させないためには、開始はinclusive、終了はexclusive、つまり半開区間(左閉右開)にするのが望ましいだろう。 終了をexclusiveにすると、例えば8月の1ヶ月間、つまり8月1日0時0分〜9月1日0時0分という期間の場合、ユーザー向けの表示としては終了日時は「8月31日23時59分まで」と表示したくはなるが、これはプレゼンテーションロジックとしてクライアントサイドの責務としてやる。基本的には-1秒してからフォーマ
[RFC] React 18 and types-only breaking changes · Issue #46691 · DefinitelyTyped/DefinitelyTyped [@types/react] add VoidFunctionComponent type which does not accept "children" by awmottaz · Pull Request #46643 · DefinitelyTyped/DefinitelyTyped https://react-typescript-cheatsheet.netlify.app/docs/basic/getting-started/function_components/ 簡単に言うと React.FCのpropsの型定義には暗黙的にchildrenが含まれてしまう childrenが必要ない
タイトルがほぼ全てです。 func foo(_ closure: () -> Void, defaultArg: Int = 0) { closure() } foo { print("foo") } このコードはSwift 5.2では動作しますが、Swift 5.1以前ではコンパイルエラーになります。 Nimbleに挙がったissueでそのことに気付きました。 Discordのswift-developers-japanで話してみたところ、apple/swiftのこのコミットが該当の変更であることを分かりました。 さらに芋づるで分かったことがあって、一時期のSwiftのDevelopment SnapshotでNimbleのビルドが通らなくなったり、そのリグレッションがきっかけでapple/swift-source-compat-suiteにNimbleが追加されたのもこの辺りに関連した
このような便利なパッケージがありました。 GitHub Actionsにはworkflow commandsと呼ばれる、echoコマンドと特定の形式の文字列を使うことでActionsの処理に一部介入できる機能があります。その中にはファイルの特定の箇所(行・カラム)にdebug/warning/errorメッセージをPRのアノテーションとして追加できるコマンドがあります。jest-github-actions-reporterではJestのレポーターの実装としてそのSetting an error messageコマンドを使い、Jestのテストの失敗結果をerrorアノテーションとしてPRの差分表示上で簡単に結果が閲覧できるようになっています。 こういうやり方があるのはRenovateのこのPRで気付きました。 きっとそのためのJestのレポーターをパッケージとして作成・公開している人がいる
GitHub Actionsをそこそこ使っている今日この頃です。さて、Actionsといえば普遍的に使う、リポジトリをチェックアウトする actions/checkout がありますが、このアクションがv2になり、色々と挙動が変更・改善されてい便利そうなのでいくつかご紹介。 https://github.com/actions/checkout/releases/tag/v2.0.0 https://github.com/actions/checkout#whats-new fetchのdepthがデフォルトで1になり、フェッチが速くなった チェックアウトの際に使用されたActions発行のトークンがgitのconfigに永続化され、リモートへのpushなどの操作が設定要らずでできるようになった ブランチのチェックアウト時にはローカルブランチを作るようになった(detached HEADに
こんにちは、id:ikesyoです。これは はてなエンジニア Advent Calendar 2019 17日目のエントリーです。 昨日12月16日(月)に行われた 年末だよ Android/iOS Test Night - 2019 にて、『2019年のSwiftモック事情』という発表をしました。 Swiftでテストのためのモックを用意するとなると、リフレクションでめちゃくちゃするということができないので、素朴に手で書くか、コード生成をすることになります。今回の発表ではコード生成に主眼を置き、以下の4つの選択肢を紹介しました。 SourceryのAutoMockable SwiftyMocky Cuckoo Mockolo それぞれの機能や違いなど詳しい内容は、ぜひ発表のスライドを見てみてください。 Swiftでのモック事情については、今年4月の Mobile Act KYOTO #1
https://swift.org/blog/swift-4-2-released/ でSupport for batch mode compilation resulting in faster build timesと言及されているものについて。 この件はWWDC 2018のセッションでも紹介がありました: https://developer.apple.com/videos/play/wwdc2018/401 これまでSwiftのビルドは簡単にまとめると、デバッグビルド(インクリメンタルビルド)では1ファイルずつコンパイル、リリースビルドではWhole Moduleモードと呼ばれるモードで、モジュール内の全ファイルを一度にまとめてコンパイル、という感じであった Whole Moduleモードでは、モジュール内で継承されていないclassはfinalが付いていなくても、実質的にfina
Crash Reporting for React Native apps · Issue #5378 · facebook/react-native · GitHub 雑感としてはSentryがよさそうな雰囲気。App Centerもいいかもしれない。 Crashlyticsとそのラッパー iOS, Androidのネイティブのクラッシュレポートの定番はCrashlytics(無料だし)だが、ソースマップ適用したスタックトレースを表示したりできるわけではないので、React Native側のJSのエラーレポートには力不足だと思う。 クラッシュレポートからバグの原因を特定する - ReactNative - 個性は次々死んでいく https://github.com/mikelambert/react-native-fabric-crashlytics ( https://github.c
これでSwiftのWebAssembly対応もちょっと捗るのかもしれない? swift-llvmがLLVM 6.0に追従したっぽい? https://t.co/SlBrAqYSFE— いけしょー@本書きました (@ikesyo) 2018年3月10日 元々stable-nextっていうブランチで追従してたのをstableブランチにmergeしたのか https://t.co/GvmdKFBIVq— いけしょー@本書きました (@ikesyo) 2018年3月10日 参考: https://github.com/kripken/emscripten/issues/2427#issuecomment-372025515
SwiftでCLIツールを書く時のArgument Parser(引数やサブコマンドをいい感じに解釈してくれるやつ)の選択肢を書き連ねておきます。これら以外の良い選択肢をご存知の方はぜひ教えてください 🙏 Commandant Carthageで使われています(というかCarthageの開発のために作られた) SwiftLintなどでも使われています SwiftのJSONデコーダーのArgoと、HaskellのAesonの影響を受けているため、関数型感のある書き味です 自分がメンテナーをしています Commander 個人的に信頼感のあるkylefプロダクト Commandantより直感的に、またより簡単に定義できるような気がします swift-package-manager なぜSwiftPMが?と思われるかもしれませんが、SwiftPM内部で使われているArgumentParserと
SwiftLint 0.22で追加された multiple_closures_with_trailing_closure というルールをご存知でしょうか。これは次のような複数のクロージャを引数に取るAPIを使用する時に、最後の引数のクロージャをTrailing Closureとして渡すことを警告するというルールです。 func fetch(id: Int, success: () -> Void, failure: (Error) -> Void) { ... } // NG fetch( id: 12345, success: { print("success") } ) { error in print("error: \(error)" } // OK fetch( id: 12345, success: { print("success") }, failure: { error
SDK overlay SwiftのSDK overlayというものを耳にしたことはあるでしょうか?これはSwiftのOSSプロジェクトであるapple/swiftの開発において、FoundationやAppKit、UIKitなどのObjective-Cで書かれたシステムフレームワークに対し、SwiftらしいAPIを提供するための拡張レイヤーです。 https://github.com/apple/swift/tree/master/stdlib/public/SDK Swift 3で、NSDateに対するDate、NSURLに対するURLなど、参照型と対応する複数の値型がFoundationに追加された*1のを覚えている人も多いかと思います。これらの値型はもちろんSwiftで実装されているわけですが、これも実はSDK overlayの一部です(この場合はFoundationのoverla
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く