サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
Pixel 9
qiita.com/bigwheel
対象の読者 Travis-CIやCircleCIなどのGithubと統合されたモダンなCIサービスを使ったことがあり、その使い方をおおよそ理解している人向けに書いています。 Travis-CIやCircleCIなどのモダンCIサービスとGithub Actionsで違う点 使い方はほぼ同じです。GitリポジトリそのものにコミットされたCI設定ファイル( .github/workflows/workflow-a.yml など)を読み取りGitリポジトリへのアクション駆動でCIが走ります。 CIの実行状況やログがウェブ上で確認できる点も同じです。 以下のようにCIステータス確認用のCIバッジの機能もあります。 おすすめポイント 利用料金が安い(というかだいたい無料) 個人ではなく組織で利用することを考えた場合、例えばCircleCIの利用料金は1ユーザー$15です1(料金プラン - Circl
前書き Terraformの機能の中でもmoduleはworkspace(旧environment)と並んで評価が分かれる1つだと思います。 僕自身も複数の人からmoduleに否定的な意見を聞いたことがあり、実際にmoduleを使い始めた頃はあまり便利だとは感じませんでした。 しかし、公式サイトのmoduleのページ12を読んでいくうちに間違ったmoduleの使い方をしてしまっているケースが多いこと、そういったアンチパターンを実行した/目にした結果moduleが使えない・実用的ではないといった誤解を招いているケースが数多くあることに気づきました。そういったアンチパターンにならないよう気を配り数ヶ月moduleを使ってみると、moduleはとても便利で汎用性の高い機能であることに気づきます。 このモジュール機能の有用性をもっと世のterraformerに知ってほしいと思ったため、このページで
こちらは【Terraform】moduleのアンチパターンとそれに対するベストプラクティス5選 - Qiitaとは違い、特に公式サイト書かれていたわけではないけども僕が数ヶ月Terraformを使って学んだ個人的なベストプラクティス集です。 リソースへ名前をつけがたいときはthisを使う あるリソースを宣言するとき、そのリソースがモジュール内で1つしかない場合は名前の付け方に苦労します。 リソースタイプと似たような名前をつける場合、以下のように以外と選択肢がたくさんあり面倒です。 aws_ssm_parameter リソースタイプの場合 parameter ssm_parameter aws_ssm_parameter ssmparameter ssm-parameter ... またアプリケーション名などその用途で表す方法もあります。 しかし、この書き方ですとこの部分を他のアプリケーショ
これ ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓ commit 3a8461e04c04ed94a64df5d2cd7adbe764a2b8d8 Author: bigwheel <hogehoge@gmail.com> Date: Tue May 2 02:50:19 2017 +0900 Fix Process output method 同僚に「ちょっとそのコミットのこれ、slack DMで送ってー」なんて言うとき、あると思います。 これをなんと呼ぶか。 自分はコミットハッシュないしコミットIDと呼んできましたがどうやら正しい呼称ではなさそう。 先に結論 Git manual的には コミットのSHA-1 ないし コミット(オブジェクト)?の(オブジェクト名|SHA-1)が正しい。 もしくはPro Git - Bookには以下の表現もある。 コミッ
新卒でIT企業に入ってから7年、ずっとアジャイルないしスクラム(という体の)のチームで開発を行ってきました。 しかし、一貫したアジャイルやスクラムに関する知識・理解を持った人がおらずだんだんやり方が崩壊していきなんちゃってアジャイル・なんちゃってスクラムになってしまうことが常でした。 これではだめだと思い、スクラムに対する一貫した知識・理解を得るため一念発起してこの認定スクラムマスター研修に行ってきました1。 認定スクラムマスター研修開催のお知らせ(開催日:2019年5月23-24日) | Attractor Inc. 受講の感想としては非常に良かったです。 特に受講者と講師のガビィ先生・原田先生の間のQAが非常に勉強になり、以前から抱いていた問題の回答が得られていたり誤解していたことに気付かされることが数多くありました。 この記事ではその講義の中で得られた気付きや従来誤解していたことを列
Scalazはscala上で関数型プログラミングをすることを支援するライブラリです。 2008/11/30にリポジトリが作られました。 各種モナドや便利な型クラスを導入してくれます1。 Catsもまたscala上で関数型プログラミングをすることを支援するライブラリです。 2015/01/25にリポジトリが作られました。 こちらもScalazとほぼ同じ概念を導入してくれます。 Catsが生まれた背景(ScalazのCoC問題) この2つは非常によく似ています。 以下のscaladocを見ればわかりますがクラスでも同名同機能のものや異名同機能のものが多数あります。 ScalazのScaladoc CatsのScaladoc ではなぜCatsが生まれたかというと、Scalazで過去ある騒乱があったためです。 OSSコミュニティがある日突然壊れたときにどうすればいいか - xuwei-k こちらが
問題 Open Api Specificationファイルを書き進めると中規模程度のサーバですら仕様ファイルが1000行を簡単に超える。 しかも1つのAPIについての記述がpaths下、requestbody下、schema下など非常に分散するので編集が辛い。 既存の解決策 中規模のSwaggerファイルをいい感じに管理するために薄いフレームワーク作った - swglow - Qiita OAS 3.0に対応していない OpenAPI Spec 3.0でのSwagger Specの分割管理 - Qiita JSON PATHの仕様に則っており良いが、書かれている通りswagger-editorやswagger-uiのようなツールで分割したままファイルを編集・表示することが非常に難しい また分割したファイルへ詳細を書いても結局のところ親のファイルで$refにより参照先を書かなければいけないた
発端 Java6までは言語仕様の中に命名規約の章があったけどJava7からはなくなった。あとパッケージ名もドメイン名逆順にしろというのが、ローカルでの利用を意図してるなら単一の識別子だけでいいということになった。そのころからlombokみたいにプロダクト名だけのパッケージ名を見るようになった気がする — きしだൠ (@kis) 2019年1月22日 今までjavaパッケージの命名はドメイン名の逆順というのが通例だと思っていたが、たしかにそれに沿わないライブラリも特にScala系のライブラリで見ることが増えてきた。 そもそもこの命名規則は確かに衝突を避けるためには合理的ではあるもののコード中の記述量が増えるため後発の言語でもまったく真似されていない。 最近のJavaでより短いパッケージの命名が許容されるならとても嬉しいと思い、本当にJavaのFQDN逆順命名規約は無視していいのか調べた。 調
Assume-role先のRoleの権限で(AWSの機能|vagrant|terraform|serverless|apex)を使いたいAWSaws-clivagrant-awsSTS 背景 AWS CLIがAssumeRoleによる自動クレデンシャル取得とMFAに対応しました! | Developers.IO awscliは上記で説明されているような記述を用いることにより、assume-role権限のあるroleへswitchしてコマンドを実行することができます。 しかし、この記述法は比較的最近導入されたこと、使用されることがそれほど多くないこと、内部的にSTSを使っているため自前で同様の仕組みを実装することは手間がかかることなどにより、通常 ~/.aws/credentials を見て自動的に認証情報を取得してくれるコマンドでもこのAssumeRole記法に対応してくれていないツールが
前書き Airframe Meetup #1 - connpassへ参加せてもらってなかなか良い刺激になったので、一念発起してScala用のDIライブラリの比較記事を書くことにしました。 が、ぶっちゃけるとAirframe: DI Framework Comparisonの記事のほうが100倍ぐらいDI真面目に使っている人がこの記事の10倍くらい時間かけて書いているに違いないのでそっち読んだほうがよいです。 この記事は多様かつ様々な視点からの意見があったほうがよいという背景から書いています。 ※注意: この記事を書いている人間はGuice, Airframe, MacWireそれぞれの使用時間が3時間未満なのでその程度の知識の人間が書いている前提で読んでください ドキュメント(仕様)を読んで比較して気づくこと Airframe: DI Framework Comparisonを参考にしつつ
概要 2017/12~2018/01にかわいいフリー素材集 いらすとやの専用検索サービスを作っていました。 完成後、いらすとやの中の人とコンタクトを取り許可をいただけたのでいらすとや検索(公認ファンサイト)として先日公開しています。 この記事の目的 AWSは従量課金なので使うときは料金が爆発しないか不安だけど、構成次第ではVPS 1つ借りるよりよほど安いよと伝えたい 既存サイトのデータを継続的にcrawlingして提供するサービスの典型例として共有 せっかくサービス作ったのでもっとみんなに使ってほしい・・・ システム構成図 運用コスト 月約4,000円程度。実際には90%がElasticsearch Service(ES)のためのEC2インスタンスで、それ以外は400円と激安。 技術スタック 使った技術を書き出しました。詳細は僕が説明するよりそれぞれの記事や解説を見たほうが良いと思います。
予防線 自分以外誰の役にも立つことを意図していない記事なので僕以外はブラウザバック推奨。 突っ込んでもらっても構いませんがリアクションは期待しないでください。 じゃあなんでネット上に公開しているのかって?こうするのがいつでもどこからでもアクセスできる一番便利な方法だからです。 文章も僕のエゴで満ちているので客観的な評価や表現は期待しないこと。毒も吐くよ。 あと極めて主観的に印象や感想を書きます。客観性とか期待すんな! 標準ライブラリのできが結構ひどい コード的にどうではなく、入っているクラス・メソッドの選定基準が非常に疑問。 例えば多くの場合良く使うusingメソッドがない。 Optionなどの実装にはすでにずっと疑問が提示されているにもかかわらず互換性を理由にそのままとなっている。 これはscalazやcatなどでOptionなどの再実装がされる背景となっている。 コンパイラ自身のコード
Ergodox Ez、いいですね。2週間前に届いてからメロメロです。 みんなにおすすめしたいんですが、値段が日本円にして3万円超と高いのと人を選ぶキーボードであるためErgodox向きかどうかの判断基準を書いてみました。 購入するかどうかの意思決定にお役立てください。 必須となるスキル C言語による簡単なプログラミングができる キーマップのカスタマイズに必要であるため 以下に多く該当するならErgodox Ez向き Ergodox Ezの利点はセパレートかつ高さ調整ができること、キーマップがおよそもっとも柔軟で複雑なマクロもプログラムにより定義できること、キーマップをハードウェア側で持つためポータビリティが高いことです。 逆に欠点を挙げると3万円超という価格やデフォルトのキーマップでは日本語環境ではほぼそのまま使えない点などです。 以上の特徴からErgodox Ezに向いている人を上げるな
ELB, RDSなど一部のリソースにCloudFormationのテンプレートで名前をつけるとスタックのUpdateができなくなるAWSCloudFormation 問題 Name タイプ - AWS CloudFormationで列挙されたリソースの名前をテンプレートで指定すると、そのテンプレート上でそのリソースに変更が加わったときそのままではupdateができなくなる。 対策 A. 名前を明示的につける 絶対にそのリソースのプロパティを変更しないと確信できるなら有効 B. 名前を明示的につけない CloudFormationが独自のルールで名前をつけることになる。 (2016/06/17時点で)ELBのように「{{stack名}}-{{リソース名}}-{{ランダム文字列}}」のようなわかりやすい形で名前をつけてくれるならこれで事足りるがRDSのように「{{ランダム文字列}}」のような名
IntelliJ Ideaでは作業環境を保存・共有することができる。 あなたはあなたの好むIDE設定を保存・格納したり、設定ファイルをバージョン管理下に置くことであなたの同僚がそれを利用可能にできる。 一方、あなたは他のチームメンバーが定義した設定やあなた自身が定義した設定を異なる使い方のために使用することができる。 このセクションでは以下のことをどのように行うか説明する: JARアーカイブとして設定をエクスポート JARアーカイブから設定をインポート IDE設定をJARアーカイブへエクスポート メインメニューから File | Export Settings を選択。 開いたExport Settingsダイアログボックス内でエクスポートしたい設定をチェックボックスを選択することでしている。デフォルトでは、すべての設定が選択されている。 Export settings toテキストボック
play frameworkはscalaのweb frameworkとしてデファクトスタンダードの位置にあります。 しかし、かなり古参のフレームワークであることもあって今日scalaを書く上で良いとされているpracticeやマナーに反する点も多くあります。 この記事では私が個人的にbad partsだと思う点とその回避策を挙げます。 Play2のbad parts一覧 activator(旧play)コマンド play frameworkのチュートリアルではactivatorコマンドのインストールを要求されます。 activatorコマンドはscalaを書く上で必要不可欠なビルドツールsbtのラッパーですが、追加されている機能は使われているのを聞いたことがないactivator uiとプロジェクトの新規作成テンプレートのみです。 play framework初心者でプロジェクトのテンプレ
非常に個人的なことですが、最近チーム内でrebaseの必要性が増しています。 なのでチーム内講習のためのプロットとしてここに説明することをまとめます。 主目的はチーム内での説明なので、記述にはチーム固有の事情やチームメンバーへの説明を前提としたものなどが一部あります。 なんのためのrebase rebaseをする理由・メリットはいろいろありますがうちのチームに限定すれば目的はほぼ一つです。 その目的はpull requestによるレビューをしやすくすること。 pull requestによるレビューはその性質上レビューによる指摘点を追加のコミットで行うことが多いですが、 この追加コミットは本来それまでにレビューしてもらったコミットへ含めるべきものであることが多いです。 例えば 適切でない変数名 よりベターなロジック記述の仕方 コメント中の誤字・脱字修正 などはすべてそれまでに見てもらったコミ
{ "person": { "properties": { "name": { "type": "string" }, "sons": { "type": "nested", "properties": { "name": { "type": "string" }, "age": { "type": "integer" } } } } } } はい、非常にわかりづらいですね。 なぜか。propetiesのせいです。 ElasticsearchはJSONフォーマットでmappingを表現してるので、そのフィールドの属性(typeなど)と子要素(propeties)は両者ともオブジェクトの中に一つネストして格納するしかありません。そのためJSONドキュメントより階層が1つ深くなってしまい、mappingとJSONドキュメントの対応が直感的にわかりにくくなります。mappingの方がproper
Vagrantのプラグインは素晴らしい 最近までVagrant-berkshelfぐらいしか使ったことなかったのですが、vagrant-omnibus使ってみたらすごく便利だったので他にも便利プラグインがないか調べてみたところ結構いいのがありました。 とりあえず公式が列挙してるプラグイン一覧 つ Available Vagrant Plugins · mitchellh/vagrant Wiki その中でも特に気に入って使ってる奴を紹介します。 使用中のお気に入りプラグイン5選 vagrant-lxc バックエンドにVirtualBoxではなくlxcを使ってくれるようになるプラグイン。 時代は仮想マシンレベルでの仮想化ではなくOSレベルでの仮想化です。 ホストOSがubuntu/debian系限定という縛りこそありますが、それさえ満たせばVirtualBoxに比べ劇的に高速・少メモリな環境
このページを最初にブックマークしてみませんか?
『@bigwheelのマイページ - Qiita』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く