サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
iPhone 16
blog.kengo-toda.jp
Dependabotの作ったPRがSecretsにアクセスできないためにことごとく失敗していたのを修正しました。 github.com SecretsにアクセスできないのはKeeping your GitHub Actions and workflows secure: Preventing pwn requestsで説明されているようにセキュリティ向上のためです。workflow_run イベントでCheckを回すとワークフロー定義は常にデフォルトブランチのものが使われるため、PRでワークフローファイルが悪意を持って変更されてもマージしなければ悪影響を受けません。ので今後、基本的にはSecretsを必要とするワークフローはworkflow_runイベントで回すことになります。 上記securitylab.github.comの記事で色々説明されていますが、わりと限定的なユースケースについ
SLF4JとLogbackの中の人はここ数年活発ではないのでLog4j2などを代わりに使いましょう。 SLF4Jの活動は最近活発ではない SLF4JはVCSとしてGitHubを利用しています。最後の変更が2020年2月、最後のリリースが2019年12月となっていることからも、あまり活発ではないことが伺えます。 またBTSとしてJIRAを使っていますが、こちらもメンテナンスされていません。昨夏SLF4J-209が既にクローズ可能な状態であることやSLF4J-186が修正可能であることなどをコメントしましたが、1年近く経った今もすべて返信がない状態です。 2020年12月にイシューを閉じていたりするので全く動きがないわけではないのですが、年間で22つ作成されたのに対して2つしか閉じられていないので、充分にメンテされているとは言い難い状況です。 2021年5月31日時点での過去360日のイシュー
ソフトウェアエンジニアとしての働き方を探求してきた経験と、駐在員として文化の狭間でうろちょろしてきた経験、OSSエンジニアとして多数の多様な人材と交流してきた経験をもとに、果敢にも内製化に挑戦する知人へのアドバイスを気持ちまとめます。 前提 主な利用技術にはJava(Spring Framework)やTypeScriptを想定 FaaSを始めとしたManaged Serviceは(いまのところ)積極採用しない構え Digital Transformationを推し進める一環としての内製化に、エンジニアリングの観点から挑む方を読み手として想定 内製化のターゲットは決まっているか心当たりがある状態 既存の開発チームはほぼ無い想定 1. チームビルディング 1.1. スーツとギークの対立を避ける 我々が若かった頃は"スーツ"と"ギーク"の対立を煽る風潮にありました。Rockstar Engin
JJUG CCCで聞きたい内容を募集👇🏻— ゴールドシップと同誕の方のトダ (@Kengo_TODA) 2021年3月2日 ということでJava8〜16におけるバイトコード生成の変化について、先日開催されたJJUG CCCで喋ってきました。 動画をYoutubeにて配信していただいているので、よろしければご覧ください: youtu.be 資料はSpeakerdeckにあります。ハイパーリンクを埋めているところは、PDFを落としてもらえれば追えるはずです: speakerdeck.com マイクロベンチマークはGitHubに置いてあります。みんなも手元でレッツJMHだ: github.com なお最後の方に触れたJEP396については、掘り下げたセッションがあったようです: youtu.be 運営の皆様、いつも素敵なイベントを開催いただきありがとうございます! 昔は息子氏見てもらう
TL;DR 2021年5月時点では raw.githubusercontent.com や gcr.ioはGFW内からアクセスできません。 開発しているOSSを広いユーザに利用してもらいたい場合は、こうしたドメインへの強い依存は避けることを検討しても良いかもしれません。 中国インターネットから見たOSS開発体制 中国本土でOSS開発をしていると、以下のようにバッジが壊れているGitHubリポジトリによく遭遇します: バッジが表示されないGitHubリポジトリの図 これはバッジが使っているドメイン raw.githubusercontent.com にアクセスできないことから生じます。バッジなら大して影響ないのですが、開発体制構築がこれに依存していると厄介です。 例えばYarn v2のインストール手順は、JSONファイルを raw.githubusercontent.com からダウンロード
ITエンジニア本大賞2021で紹介されていた「ドメイン駆動設計入門」(以下、本書と呼ぶ)が、DDDを学ぶ上でわかりやすかったです。一応他のDDD本も数冊読んではいたのですが、どうしてもユビキタス言語や境界づけられたコンテキストなど”場合による”ものが頻出してしまい、結局どうすればいいんだ……となって手が動きにくかったのです。よくわからない概念の上にさらにわからない概念を積み重ねるので、どんどん混乱する感覚がありました。 定期的にDDD勉強しなきゃ……ってなるんだけどやらない(やれ)— 正月と正月のあいだ (@Kengo_TODA) September 5, 2019 反面、本書では副題の通りボトムアップ形式を採っているため、実際にどう手を動かせば良いのか細かく確認できました。また不明点を最小化しながら進むだけでなく、その概念を導入することでどんな問題が解決されるのかが実例をもって明示されて
Elastic社のブログをきっかけに、最近見かける新しいライセンスについて個人的に調べてみた。私は専門家ではないので要注意。公開情報も隅々まで追えているわけではないし。 なお一部ライセンスはOpen Source Initiative (OSI)による承認を受けていないので、ここではオープンソースライセンスではなく単に「ライセンス」と書くことにする。 新しいライセンスが誕生している背景 従来のオープンソースライセンスが再頒布以外の利用をあまり想定していなかった。 Open-core modelないし完全オープンソース戦略を採る企業が自衛策を必要とした。 既存のライセンスが難解なため、理解しやすいライセンスが求められた。 OSS活動を収入に繋げるためのモデルが試行錯誤されている。 新しいライセンスを導入しているプロジェクト(一例) プロジェクト ライセンス Elastic SSPLと独自ライ
4年前の下書きが出てきたので、供養のために置いておきます。 SpringOne Platform 2016のKeynoteとSessionを、特にProject Reactor周りについて確認した。 https://www.youtube.com/watch?v=Xm-KjMY_Z_w http://www.slideshare.net/SpringCentral/going-reactive-building-better-microservices-rob-harrop http://www.slideshare.net/SpringCentral/data-microservices-in-the-cloud http://www.slideshare.net/SpringCentral/designing-implementing-and-using-reactive-apis h
この記事は、2013年に書いた記事を現状に合わせてアップデートするものです。結論から言うと、当時から id:miyakawa_taku さんがおっしゃっていた「APIは依存に含めて良い」を支持するものです。あるいは無難にバージョン 1.7.30 を使っておきましょう。 blog.kengo-toda.jp slf4j-apiに1.7, 1.8, 2.0の3バージョンが生まれた 現在slf4j-apiには3つのバージョンが存在します。現在のSLF4Jエコシステムを考える上では、これらの違いを抑える必要があります: 1.7.x Java 1.5から利用できるバージョンです。安定版にこだわるなら未だこのバージョンを使う必要があります。 1.8.x JPMS(a.k.a. jigsaw)を採用しServiceLoaderを使ってBindingを呼び出すようになったバージョンです。Java 1.6が
FOSS開発で細かいやらかしを積み上げてきたのでまとめる。 テストの失敗原因レポートをartifactとしてアップロードしそこねる actions/upload-artifactを使ってテストレポートをartifactとしてアップロードする際、以下の書き方だと失敗する。 # bad - run: | ./gradlew test --no-daemon --stacktrace - uses: actions/upload-artifact@v2 with: name: reports path: build/reports これはテストが失敗した時点で後続のstepsが実行されなくなるため。明示的に失敗時でもアップロードされるように指示する必要がある。 # bad - run: | ./gradlew test --no-daemon --stacktrace - uses: actio
人に説明するのがスムーズにできなさそうなので、理論武装というか順序立てて話すためにこの記事をまとめる。 対象 ブラウザから利用するマルチプラットフォーム向けウェブアプリケーションの開発 モバイルのネイティブアプリ開発は含まない(知らないので) 利用言語はJava, JavaScript/TypeScriptを想定するが、特に言語に依存しない認識 開発経験はあるが、情報や経験が少なくて「よりよいプロダクト開発」の理想が描けない方への一助として作成 TL;DR 状況やベストプラクティスが目まぐるしく変わる現代において、すぐに変化できるソフトウェアを保つこと・ヒトの手をできるだけ空けることが重要。 かつてIaaSがAPIを提供し環境管理の多くを自動化したように、各種サービスがAPIやWebhookを通じてDevelopment Workflowの多くを自動化してきている。 多くの視点や知見を活か
.classファイル向け静的解析ツールであるSpotBugsのバージョン4.0.0がリリースされました。 FindBugsとの互換性を極力保っていた3.1系と異なり、いくつかのAPIが変わったり機能が削られていたりします。 特にプラグイン開発者は、SpotBugs 3.1 から 4.0 への移行ガイドを確認するようお願いします。 一応ユーザに使われていない機能を調べて削ったので、一般ユーザに対する影響は限定的なはずです。 なおJava 9以降にはまだ対応していません。コミュニティで議論された4.0でやりたいことには含まれていたのですが、貢献がありませんでした。 ObjectWeb ASMやApache BCELの更新に追随しているのでコア機能は動作しますが、標準DetectorのうちNullness周りをはじめとしたいくつかのDetectorが動作しないことが知られています。のでJava9
考慮する点 成果物のデプロイ ビルドの成果物(artifct)をアップロードすること。アップロードと公開は分けて考えることに注意。デプロイ先にはいくつか候補がある: GitHub Packages (旧GitHub Package Registry) Maven Central Repository Docker HubなどのDocker Registry GitHub Packagesはコンテナも.jarもまとめて置けるが、コミュニティ標準の場所ではないので利用する際にひと手間必要になる。プライベートプロジェクトの場合は積極利用することになりそう。FOSSなら基本的にMaven Centralに置くことになる*1。プロジェクトによっては.jarファイルとしてではなくコンテナとしてデプロイすることもあるだろう。 リリースノートの作成 CHANGELOG.mdやsrc/site以下のファイル
最近Java周りでもsemantic-releaseの利用機会が増えています。Gradle pluginとMaven pluginが生まれ、特に後者はyarn*1で実行されるため既存のプラグインとも組み合わせやすく、JavaScriptと比較しても遜色ない状態と言えそうです。 2019年3月時点で、Java特にMavenがどのようにsemantic-releaseを活用できるのか、まとめてみます。 semantic-releaseとは プロジェクトにおいて以下の制約を導入することで、リリース作業をより一段階自動化する仕組みです。 Semantic Versioningを使ったバージョン番号の付け方 Conventional Commit Messagesを使ったコミットコメントの書き方 すでにJavaコミュニティにおいてもSemantic Versioningは標準となっているため、実際に
クラスメソッドさんのブログでSonarQubeの紹介がされています。そちらの記事では記事の半分ほどを割いてインストール方法を説明していますが、dockerを使えばより楽に行えますのでその方法を紹介します。 dev.classmethod.jp 検証用のSonarQubeを立ち上げる 以下のコマンドで、組み込みデータベースを使用したサーバが立ち上がります。ユーザ名admin、パスワードadminでログインできます。 このコマンドは英文公式ページからの引用です。 $ docker run -d --name sonarqube -p 9000:9000 -p 9092:9092 sonarqube なおalpineを使ったイメージもあるのですが、2018年8月1日現在でClassNotFoundErrorが出るなど不安定なようです。7.1-slpineなどのバージョンではなく、7.1などのバー
これ↓読んで、自分の経験をまとめようと思ったのでメモ。 www.yutorism.jp チームビルディング、ないし組織・オフィスの改善のためにやってきたことはけっこうある。反面、できていないこともかなりある。 やったこと、継続していること 社内技術勉強会 上海拠点設立時に董事長と話してやったのがこれ。せっかくCS専攻の人を集めたのだし、ポテンシャルある人ばかりなので、彼らが互いに刺激を与え合える機会を作ろうという狙いだった。当時は20名弱だったので、全員にスライドを使って企画意図を説明したのを覚えている。 最初は発表者が2,3名に偏ったり、開催時間が固まらなかったり(最初は朝開催を目指したが、結果的には夕方開催に落ち着いた)、発表が数週間連続でなかったりという問題も多かった。しかし結局は、私が異動でいなかった時期(1年間)も含めて6年間続けられている。継続するのが一番難しいので、これは普通
このエントリは「Announcing SpotBugs as FindBugs successor」の意訳です。一部、明らかなURLの誤りを修正し、可読性のため強調を施しています。 皆さんこんにちは、 このメールはこのメーリングリストにおける私の最後の投稿であり、また昨年のこちらの投稿の続きです。 https://mailman.cs.umd.edu/pipermail/findbugs-discuss/2016-November/004321.html TL;DR: FindBugsプロジェクトはプロジェクトリードが管理者権限を移管しないままプロジェクトを離れ、また1年以上応答がなくなったため停止しました。SpotBugsプロジェクトがその後継であり、バージョン3.1.0 RC5を既にリリースしています。ASM6の安定バージョンがリリースされしだい、SpotBugsの3.1.0 RC6そ
先週、FindBugsのメーリスに興味深い宣言が流れました。今のFindBugsはメンテ困難であり現体制での継続保守が難しいとするものです。 ただこれをもってFindBugsはおしまいだ、としてしまうのはちょっと違います。コミュニティ自体はまだ活発で、プロジェクトのあるべき姿について話し合っています。私はコミッタでもなんでもないのですが、1週間経ったこともあり日本語で簡単に経緯を紹介したいと思います。 出典明示のため細かくリンクを張りますが、リンク先を見ずとも本エントリだけで理解できるよう努めます。 現体制最大の問題はプロジェクトリーダーの不在 1年以上前から、プロジェクトリーダーのBill Pugh氏はコミュニティ開発者からの連絡に返信しなくなりました。メールもそうですがGitHubやTwitterでのmentionにも返信しません。私もこの5月にTwitterで連絡を取ろうとしましたが
社内勉強会向けに作成したコード内コメントとJavadocの書き方についてのスライドを、Speaker DeckとSliDeckで公開しました。 このスライドは概要とメリットについてざっくり説明し理解と学習の動機を作ることを目的としていますが、これは日本ないし中国の大学ではコメントについてそこまで扱わないらしい*1という前提に基づいたものです。 ここに記載のない発展的な内容としては以下が挙げられますが、これらについて学ぶのはまず手を動かした後で良いと考えています。 API Specとは何か、何を書くことが望ましいのか(読み手目線に立った考え方) package-info.java によるパッケージに対するドキュメンテーションコメント Mavenでjavadocを出荷する方法 @Documentedアノテーションとは何で、いつ必要なのか コード内コメント以外のドキュメント(README、コミッ
今日、拙作findbugs-slf4jのGitHub Pageを作りました。このブログではこのプロジェクトについて日本語で紹介したいと思います。 概要 拙作PMDプラグインをもとに、2012年8月から実装を開始したfindbugsプラグイン SLF4J利用時のよくあるトラブルを未然に防ぎ、コードの品質を担保する 全自動なので、開発者各々の個性に影響されずに品質の底上を実現できる 既存の課題:SLF4Jの直感的ではないインタフェース SLF4J(Simple Logging Facade for Java)はJava向けに開発された、ログ用のFacadeです。開発者はSLF4Jが提供するインタフェースを利用することで、「高パフォーマンスなログ処理」と「利用者に好きなログ基盤を選ばせる自由」を提供することができます。例えばLog4j 2のような新しいログ基盤でも、プログラムがSLF4Jを使って
Sometimes my teammates ask me about how to find and learn new technologies. It would be common question for technologist and developers, so I will try to summarise current my theories. How to find new technologies RSS (articles) RSS is still my best method to collect information from WWW. I have already tried AI based curation like Gunosy and SmartNews, but they summarise information from only lim
Guavaのテストコードを読んでいたらTruthというtesting frameworkが使われていることに気づき、最新の個人プロジェクトで使ってみました。まだアルファ版ですし、自分でも使い続けるかどうか微妙なところですが、試用記録として利点をまとめます。 なお著者がアサーションフレームワークに求めるのは、大人数が関わるプロジェクトにおける「開発者の個性(経験、知識、趣味)に限らず、短時間で保守性が高く直感的なコード・エラーメッセージが書ける」ことです。異なる観点からこのプロダクトを見ると、また違った意見があるかと思います。 assertThat()が必要とされた理由 そもそもassertThat()はなぜ必要なのでしょうか。それはassertTrue(), assertFalse() などのメソッドが生むエラーメッセージが直感的でないからです。 Truthのウェブサイトにのっている例が非
一時期はメソッド名は動詞で始まらなければならないと言われていましたが、昨今ではJava標準APIでも動詞ではないメソッド名が散見されます。本エントリではその傾向をまとめます。 of, from(from, of, valueOf, fromString, fromNullable etc.) fromやofはEffective Javaでも触れられているように、ファクトリメソッドとして利用されることが多いようです。例えばJAX-RSでは valueOf(), fromString() といった名前のファクトリメソッドを利用します。 EnumSet.of Integer.valueOf to, as(toList, asList, toArray etc.) 主に自分自身を別の形に変換するインスタンスを返すメソッドに使います。 IntStream.toArray Arrays.asList
JavaのStreamで末尾再帰するというアイデアが今読んでるFunctional Programming in Javaで紹介されていた。 The Pragmatic Bookshelf | Functional Programming in Java agiledeveloper: Functional Programming in Java is quite Approachable 動かしてみたら、確かにStacktraceが浅いままで階乗の計算ができている。 タネはStream.iterate()で、このメソッドが再帰の代わりに必要なメソッドの計算を行ってくれている。試していないがStream.generate()でも同じことができるのではないだろうか。 あまり直感的ではないが、実用的なテクニックではありそう。覚えておこう。 追記 マイクロベンチの結果、やはり素直な書き方よりは遅
Jenkinsの使い方と狙いについて話す機会があるので、自分の考えをまとめる。 時間節約と内容簡素化のため、CIとJenkinsとを分けて説明するのではなく、開発者なら共感できるであろう表現によってJenkinsとCIの双方を説明することを目指す。なお「品質」の定義について、ここでは明確には定めない。 アジェンダ Jenkinsはいろんなことを自動化するサービス 人間に「人にしかできないこと」へ注力させるため、機械の執事を雇って自動化する。 自動化の恩恵は「省力化」と「コミュニケーション促進」 省力化: 人間に「役割」へ注力させるため、Jenkinsは各種「役割」の補佐を行う。コンパイルやテスト、情報収集や統計などルーチン作業を通じて人間が思考し判断することを助ける。ゴールは「人が行うルーチン作業」と「作業完了待ちによる暇」をゼロにすること。 コミュニケーション促進: 「役割」間の連携を促
Gitbookの多言語対応はまだ弱く、日本語で書籍を書く際はいくつか対応が必要です。 しかし文字化け等はないため、Markdownに慣れている人であれば充分に活用できる製品になっていると思います。 文中の意図せぬ空白 文中の改行が空白に変換されてしまうため、段落をすべて1行で書ききる必要があります。 下記プラグインで対応可能のようですが、利用時に警告が表示されます。折り返し表示可能なエディタを利用したほうが良いかもしれません。 github.com GLOSSARY 用語集は半角空白で区切る言語のために設計されています。つまり半角空白で区切られた単位を「単語」として認識し、自動的にリンクを追加するような仕組みになっています。 このため、日本語のような単語間に空白が入らない言語の場合は、分かち書きをしないと使えません。 例えば「りんご」という言葉を用語集に追加する場合、本文には りんごの木が
最重要 実行に重きを置く やらないで後悔するよりも、やって反省する。 反省は成長を産み生産的だが、後悔は精神の無駄な消費。 時間は有限で貴重な資源だが、たぶん今の段階では行動する前に得るものや結果を予測するのは難しい。 正しい反省の方法とは何か、考え続けること。 「正しく反省するために、何を記録しておくべきか」実行前に明らかにしておくこと。 反省の結果は組織的な何かに落としこむ。組織構造、戦略、静的解析、自動テスト、教育など。意識しないでも巨人の肩に乗れる状況を作ることが、組織の成長につながる。 Done is Better Than Perfect ただし、思考停止の言い訳にしないこと。詰めの甘さを擁護する言葉ではない。詰めの甘さは立場や考え方が違うひと3人くらいに意見を求めればだいたい炙り出せる。 長期的視野を持ちつつ、それに引っ張られない。進展を作ること、現状を少しずつ変えることを意
ここではカタいクラス=フェイルファストで、コンパイル時に問題を発見しやすく、かつ保守しやすいクラス と定義する。 基本的には goog.ui.Component あたりを読むと勉強になる。もちろんネームスペースでユーティリティメソッド群を実装する場合にも通じる。 goog.asserts.assert を使う 「ここではこういう理由からこういう状態であるべき」をコードで明記できる。例えばgoog.ui.Componentでは以下のようにして使っている。 /** * Similar to {@code getElementByClass} except that it expects the * element to be present in the dom thus returning a required value. Otherwise, * will assert. * @para
チームで仕事をする上で気づきの機会を提供することが大切であると考えているのですが、では新人の技術者には何を気づかせるべきなのでしょうか。基本的には以下だと考えています。 目的を忘れないこと コミュニケーションの大切さとその理由 作ったものがどう使われるか想像する必要性 日々の学習がなぜ必要なのか、危機感を持つこと まずそれぞれについて「何に気づくべきか、なぜ気づくべきか」を述べ、次に「そのためにどのような機会を作るべきか」について述べます。 気づくべきこと 目的を忘れないこと 技術者とは技術のエキスパートであり、技術とは問題解決のための手段です。ゆえに技術者は問題解決のために自分の技術がどう活きるか、どんな技術をどう組み合わせるのかを考えなければなりません。 流行や新技術もいたずらに追うのではなく、なぜ今それが流行なのか・既存技術と比べての利点や欠点は何なのかを咀嚼し自分なりの解釈を作った
次のページ
このページを最初にブックマークしてみませんか?
『Kengo's blog』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く