JSONをURIに埋め込んでも%地獄にならない「Rison」のススメ - Qiita
さくらのクラウドでバックエンドを担当しております、@townewgokgok と申します（記事はフロントエンド寄りの記事になります）。これは さくらインターネット Advent Calendar 2018 11日目の記事です。 JSONのように階層化された値をURLに埋め込みたいことってありませんか？ たとえば 価格.com の商品検索結果ページ のように、リンクを開いたら検索フォームの内容が復元されて、URLのコピー時に見ていたものがそのまま表示されて欲しい。 これを実現するには、従来なら文字列のキーバリューとしてごく一般的な application/x-www-form-urlencoded 形式でURLにパラメータを埋め込むところです（上記の価格.comの例でもやはりそうなっています）。ただ、そこそこ複雑な検索フォームの値をいちいちこの形式にまとめたり復元したりするのはわりと面倒です
新人プログラマをレビューで傷つけないために - Qiita
はじめに この半年くらいで初めて本格的にチーム開発を行い、今では日常的に GitHub の Pull Request を使っています。 チームの方々には、基本的なことから応用的な部分まで様々な観点からレビューをしてもらって、大いに勉強になりました。 ただ、時には「新人にとっては厳しいレビュー」をいただき、1 人で傷つきモチベーションを落とすこともありました。 もちろんそれは悪意のあるものではなくて、新人とレビュワーのスキルのギャップによって意図せず生み出されてしまうものです。 そのような不幸なレビューによって苦しむ新人が減ることを願って、新人を不用意に傷つけてしまう恐れのあるレビューをまとめていきたいと思います。 新人教育の場に少しでも役に立てていただけると嬉しいです。 前提条件 今回の対象とする「新人」は、本格的な開発経験が1年未満の方を想定しています。 個人で少しプログラミングはしてき
State of SEO for SPA 2019 - Qiita
メタ この記事はNode学園2018にて話した内容を記事として編纂 +その後の変化を加筆修正したものです。 スライドはこちら。 https://speakerdeck.com/kazuyaseki/seo-for-spa-cfb3706f-ae1d-4c6f-a83f-96dc2452f32b 追記 2019/5/8 遂に Google bot が扱うレンダリングエンジンが Chrome 最新版(現時点では 74)相当となりました！ https://webmasters.googleblog.com/2019/05/the-new-evergreen-googlebot.html ただタイムアウトなどのリスクは依然存在するので、信頼性を求めるならやはり Dynamic Rendering や SSR が選択肢になるのかなと言う気はしますが、そこまで要求が強くない場合にはあまり頑張らなくてよ
持続可能な開発を目指す ~ ドメイン・ユースケース駆動（クリーンアーキテクチャ） + 単方向に制限した処理 + FRP
この記事は、開発を持続可能にできるようなアーキテクチャとその適用方法を考察するものです。 骨子はできていますが、実装経験をフィードバックして詳細を若干変更するかもしれません。 勉強不足な点もあるので、意見を歓迎します。 開発においてよくある問題点 ビジネスロジックの本質が何だったか見失う。ソースコードのどこまでが業務上の関心で、どこからがそれを実現するための技術上の関心か分からなくなる。 入出力双方向の処理が散在して処理が追い切れなくなる。特にイベント処理でどこに飛ぶかわからないコールバック地獄になる。 初期化・つなぎ込み・統合者的オブジェクトが小さな機能単位で生まれて統一感が無くなる。 状態を持つ値が大量に散在して副作用を起こしバグを生む。 これらの問題の結果、小さな単位ごとに個人のノウハウで"良い"設計がされ、機能を追加しようとしたときにどういう方針で行えばよいか分からなくなる。 解決
「さようなら ImageMagick」の考察 - Qiita
はじめに サイボウズさんの ImageMagick の利用をやめる記事について少し思う所を書きます。否定というよりアシストのつもりです。(2018年08月26日投稿) さようなら ImageMagick 自分のスタンスを3行でまとめると、 policy.xml で読み書き出来るファイル形式を絞れば、いうほど怖くはない ただ、ImageMagick に限らずサーバサイドで動かすのは手間と覚悟が要る Yahoobleed の件でコード品質が信用ならないと言われたら、ごめんなさい 「ImageMagick を外した理由」 サイボウズさんのブログでは、2017年の ImageMagick 脆弱性報告数が多いので駄目との事です。 脆弱性 ImageMagick には脆弱性が大量に存在します。 2017 年に報告された ImageMagick の脆弱性は 236 件 でした。 大量にある上にリモートコ
メールのトランザクション設計 - Qiita
3日目で息切れしてきたので、今日は軽めな内容です。 データベース更新とメール送信の一貫性 商品購入の完了ページなど、よくデータベースを更新して、メールを送信してデータベースをコミットするという仕様があります。 データベース登録出来てないのに、完了メールを送るわけにはいかないので、これらを1トランザクションにできなきゃいけません。が、SMTPプロトコルにコミット/ロールバックの概念はありません。 さて、どう設計しましょうか、というお話です。 方式 A.DBトランザクション後にメールを送る 同一トランザクションはあきらめ、データベースを先にコミットし、その後でメールを送る、という設計です。 メール送信でエラーになったら、データベースには書き込めているので、メールだけ再送するように仕組みを作ったりします。 以下のようなイメージです。 public class OrderController {
JavaEE使い方メモ（Bean Validation） - Qiita
環境構築 コード Bean Validation とは バリデーション（入力チェック）用のフレームワーク。 入力チェックは様々なレイヤに分散されやすい。 例えば、桁数やフォーマットのような形式チェックはプレゼンテーションレイヤに、マスタの存在や他のデータとの関連が正しいかなどのビジネスロジックのチェックはそれより深いレイヤなどに分かれたりすることがある。 こういった分散されやすい入力チェックを、一箇所にまとめまられるようにしようという目標のもと作られたものらしい。 入力チェックのルール（制約）はアノテーションで定義する。 null チェックなどの汎用的なものはあらかじめ定義されている。もし標準のアノテーションでは足りない場合は、独自にアノテーションやバリデーションロジックを定義することもできる。 この仕様は、単体で利用するよりかは他のフレームワーク（JPA, JAX-RS, JSF など）
JPA と DDD の関係で僕が思っていること - Qiita
このスライドについて このスライドは、 JJUG CCC 2016 Fall でお話ししたときに使用したスライドです。 自己紹介 opengl-8080 主に Qiita で技術メモを書いたり 関西の SIer 勤務 今日話すこと JPA と DDD の関係について思っていること JPA で DDD のパターンを実装するとどうなるか JPAとDDDの関係で思っていること 最初は、 JPA に対してあまり良いイメージはなかった DDD を学ぶにつれて、徐々にイメージが変わっていった なぜ変わっていったのか、どう変わっていったのか JPAでDDDのパターンを実装 エンティティ・値オブジェクトなどを JPA で実装する 仕様上の限界、実装ごとの現実 JPAとDDDの関係で思っていること JPA へのイメージの変化 DB アクセスライブラリ1との出会い DB アクセスってこうやるのかぁ JPA と
ソートアルゴリズムを極める！ 〜 なぜソートを学ぶのか 〜 - Qiita
NTT データ数理システムでリサーチャーをしている大槻 (通称、けんちょん) です。 今回はソートについて記します。 0. はじめに データ構造とアルゴリズムを学ぶと一番最初に「線形探索」や「ソート」が出て来ます。これらのテーマは応用情報技術者試験などでも頻出のテーマであり、アルゴリズムの Hello World とも呼ぶべきものです。 特にソートは、 計算量の改善 ($O(n^2)$ から $O(n\log{n})$ へ) 分割統治法 ヒープ、バケットなどのデータ構造 乱択アルゴリズムの思想 といった様々なアルゴリズム技法を学ぶことができるため、大学の授業でも、アルゴリズム関連の入門書籍でも、何種類ものソートアルゴリズムが詳細に解説される傾向にあります。本記事でも、様々なソートアルゴリズムを一通り解説してみました。 しかしながら様々な種類のソートを勉強するのもよいが、「ソートの使い方」や
PHPでダウンロードさせるファイル名がIEで文字化けする件 - Qiita
問題はどんな言語で書いても起こることですが、たまたま仕事でPHPつかってたときにぶつかったのでメモしておきます。 結論 HTTPのレスポンスヘッダで Content-Disposition: attachment; filename*=UTF-8''URLエンコードされたファイル名を送ってあげる。 追記 2017/11/02: Edgeでも通用するようです。https://github.com/netcommons/NetCommons2/issues/126 ファイル名が化ける PHPでファイルアップローダをつくっていました。 動作確認はUbuntu 14.04のFirefox30をつかっていましたが、社内ではIE11がデフォ。「一応やっとくか」とIE11で動かしたら、日本語のファイル名が見事に化けました。 またお前か、IE！チキショー Slim Frameworkをつかっているので、こ
KubernetesでAWS ALBを自動作成する〜ついでにRoute53 Record Setも - Qiita
Ingress Controllerとは KubernetesのIngressはL7ロードバランサのスペックのようなもので、そのスペックから実際にL７ロードバランサをセットアップするのがIngress Controllerの役割です。 coreos/alb-ingress-controllerとの違い coreos/alb-ingress-controller Ingressリソース一つに対して、1 ALBをつくります zalando-incubator/kube-ingress-aws-controller ACM証明書のドメイン一つに対して、ALBを割り当てます 同じドメイン名に対するルートを含むIngressリソースは、一つのALBにまとめられます ALBのターゲットグループにEC2インスタンスを割り当てるところまでしかやってくれない！ので、実際にIngressとして利用するためには
Kubernetesのexternal-dnsでRoute53 RecordSetを自動作成する - Qiita
external-dnsとは kubernetes-incubator/external-dns Configure external DNS servers (AWS Route53, Google CloudDNS and others) for Kubernetes Ingresses and Services externa-dnsはKubernetes Incubatorプロジェクトの一つで、KubernetesユーザがクラウドプロバイダのWebコンソールやCLIを使わずとも簡単にDNSレコードを作成・更新してサービスを公開するために利用します。 AWSの場合、AWSコンソールやawscliを使わずともkubectlだけで簡単にRoute53でサービスを公開することができます。 external-dnsの仕組み Kubernetesユーザが何かサービスをデプロイするとき、Depl
Kubernetes: Deployment の仕組み - Qiita
Deploymentはローリングアップデートやロールバックといったデプロイ管理の仕組みを提供するものです。 下記の図のようにDeploymentはReplicaSetを生成・管理し、ReplicaSetはPodを生成・管理します。 ReplicaSet(ReplicationControllerの後継)はPodTemplateと呼ばれるPodのテンプレートをもとに、Podを指定された数(レプリカ数)に調整・管理を行う仕組みです。Podがレプリカ数より足りない場合はPodを追加し、多い場合はをPodを削除します。この仕組みによってノードの障害やアプリケーションのクラッシュでPodが足りなくなった際も自動的にPodが追加され、セルフヒーリングが実現されています。 Deploymentはコンテナイメージのバージョンアップなどアップデートがあった場合、新しい仕様のReplicaSetを作成し、新旧
Kubernetes: kubectl apply の動作 - Qiita
kubectl apply はオブジェクトが存在しなければ作成し、存在すれば差分を反映してくれる便利なコマンドです。しかし差分の反映は単純な上書きではないので注意が必要です。この記事では Kubernetes Meetup Tokyo #5 で発表した内容をベースに kubectl apply の動作を整理してみました。Kubernetes v1.9.0 で確認をしています。 kubectl apply とは kubectl にはオブジェクトを操作する様々なサブコマンドが用意されています。apply 以外の create, replace などのサブコマンドは、現在のオブジェクトの状態を意識して操作をする必要があります。例えば kubectl create では存在する名前のオブジェクトを再度作ろうとするとエラーになりますし、kubectl replace では存在しないオブジェクトを上書
次世代監視の大本命！ Prometheus を実運用してみた - Qiita
こんにちは！freeeでインフラゾンビをやっている @sugitak です。ゲームではレベルを上げて物理で殴る派です。 freee ではたまにインフラエンジニアの数が減るのですが、その減ったインフラエンジニアはインフラゾンビへと進化し、社内を闊歩します。インフラゾンビは主に開発チームに所属して、アプリっぽいインフラの仕事をインフラからアプリ側へと持っていきます。デプロイとか、Dockerとか、Jenkinsとかの、いわゆる DevOps 系のところですね。こうすることで開発者は手を出せるものの自由度が増えるし、インフラはより本来のインフラとして純度を上げていける、 so, win-win ってわけです。 さて、そんなわけで監視です。freee Engineers Advent Calendar 2016の9日目の記事として、 Prometheus による監視が最高なのでみんなもっと使おうと
Kubernetes のメトリクスを Prometheus を使って監視する - Qiita
また, Prometheus 自体は監視対象の Kubernetes クラスタ上に構築するものとします. Prometheus の構築 始めに Kubernetes クラスタ上に Prometheus を構築します. $ kubectl create -f https://raw.githubusercontent.com/kkohtaka/kubernetes-metrics/master/prometheus/service.yml $ kubectl create -f https://raw.githubusercontent.com/kkohtaka/kubernetes-metrics/master/prometheus/deployment.yml $ kubectl create -f https://raw.githubusercontent.com/kkohtaka/k
GitHub Issuesでブログを作る - Qiita
GitHubのIssueをNuxtとNetlifyでブログ化するというのをやってみたので解説します。 デモサイト： https://gh-blog.netlify.com/ Issues： https://github.com/miyaoka/gh-blog/issues Headless CMS はじめにHeadless CMSについて解説しておきます。旧来のAPI無しのWordPressのような一体型CMSではなく、コンテンツ管理部分を切り離してAPIでやりとりできるようにするのがHeadlessなCMSです。これによりフロントの実装やデプロイが疎結合になり、好きにできるようになります。 例としてCMSにContentful、デプロイにNetlifyを使う構成だとこんな感じになります。 参考） 次世代Headless CMS「contentful」事始め - Qiita Nuxt.js
React + TypeScript (+ Electron)でアプリを書き始めるときにやってること - Qiita
diff --git a/tslint.json b/tslint.json index eb5d66a..2b86576 100644 --- a/tslint.json +++ b/tslint.json @@ -1,99 +1,3 @@ { - "extends": ["tslint-react"], - "rules": { - "align": [ - true, - "parameters", - "arguments", - "statements" - ], - "ban": false, - "class-name": true, - "comment-format": [ - true, - "check-space" - ], - "curly": true, - "eofline": false, - "forin": true, - "indent": [ tru
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MyBatis 使い方メモ - Qiita
Angular 4.3で追加されたHttpClientModuleについてのメモ - Qiita
