政府向けシステムの話をするときの前提知識
政府向けシステムに関わったことがある身からすると、政府向けシステムの話をするときに前提として知っておいてほしいことは、住基ネット最高裁判決に「現行法上，本人確認情報の提供が認められている行政事務において取り扱われる個人情報を一元的に管理することができる機関又は主体は存在しない」という骨子があること。これによって政府向けシステムは個人情報を一元的に管理できず、個人情報は各自治体で分散管理しかできない。この文面でググれば政府がどれだけこの骨子を気にしているかは分かると思う。 今回の話は「国民マスターテーブルを持たずに認証するにはどうすべきか」という政府向けシステムで常に挙がる課題で、良いアイデアがある人は政府に提案しにいってほしい。個人情報保護法の目的外利用に違反しない上で。 はがき送りつけこれをできるのは自治体のみで防衛省はできない。防衛省は国民の住所氏名を知らないのではがきを送れない。防衛
Webサービス公開前のチェックリスト
個人的に「Webサービスの公開前チェックリスト」を作っていたのですが、けっこう育ってきたので公開します。このリストは、過去に自分がミスしたときや、情報収集する中で「明日は我が身…」と思ったときなどに個人的にメモしてきたものをまとめた内容になります。 セキュリティ 認証に関わるCookieの属性 HttpOnly属性が設定されていること XSSの緩和策 SameSite属性がLaxもしくはStrictになっていること 主にCSRF対策のため。Laxの場合、GETリクエストで更新処理を行っているエンドポイントがないか合わせて確認 Secure属性が設定されていること HTTPS通信でのみCookieが送られるように Domain属性が適切に設定されていること サブドメインにもCookieが送られる設定の場合、他のサブドメインのサイトに脆弱性があるとそこからインシデントに繋がるリスクを理解してお
経産省発の npm モジュール！住所や電話番号の正規化、ジオコーディングなどができる IMI コンポーネントツールを試した！
経産省発の npm モジュール！住所や電話番号の正規化、ジオコーディングなどができる IMI コンポーネントツールを試した！ Code for Japan の関さんが SNS でシェアしてて知ったのですが、経産省さんがなにやらオープンソースで住所や電話番号の正規化などなどをするツールを公開したとのこと。 https://info.gbiz.go.jp/tools/imi_tools/ 経産省が住所変換や法人種別名、電話番号の正規化に使えるIMIコンポーネントツールを公開しました。 ソースコードも公開。README にも使い方が丁寧に書かれていました。https://t.co/fPbV00EgZP 素晴らしい動き。こういう... #NewsPicks https://t.co/bew0qGKMFE — Hal Seki (@hal_sk) May 28, 2020 ぶっちゃけ当初はあまり期待
よく、仕様書を書いていなくて、書いてみたいけど、具体的な仕様書がネット上に落ちてなくってこまってるって相談を受けるので 「仕様書の記載内容のイメージ」を作りました！ ※前提として「現在仕様書を書いていない、自社開発のMVP検証前後のフェーズのスタートアップ向け」に書いています。PMが仕様書、エンジニアがDesign Docを書く分担です。 ついでに、システム開発の基礎である「システム開発のV字モデルをベースにした設計書の紹介」も含めてまとめてみましたー！ 大規模開発に使われたり、古くからあるフレームワークなので、スタートアップの方だと、システム開発のV字モデルの概念やそれにあわせた成果物を知らない人が多いけど、「要件定義書」と「設計書」を全てドキュメント化するとどうなるかを理解した上で、「仕様書」として情報を削る方が、考慮漏れ防止やエンジニアがやっている設計内容の理解につながるので、全体を
プロダクトマネジメントと事業開発に関する私的な振り返り - 下町柚子黄昏記 by @yuzutas0
TL;DR 企画力が…欲しい… pic.twitter.com/hJfr0qNv7T— ゆずたそ (@yuzutas0) 2020年11月19日 試行錯誤の瓦礫の記録です。 はじめに もくじ TL;DR はじめに もくじ 以前書いた記事 前提・免責 アイデア 1日1案（やってよかったこと） 1stスクリーニング（やってよかったこと） コミュニケーション チームへのリスペクト（やってよかったこと） 話す <<< 聞く（改善余地あり） 即決する（やってよかったこと） 自分で各論まで見る（やってよかったこと） 発散→収束でディスカッション（改善余地あり） イラストで話す（改善余地あり） 日次ミーティング（やってよかったこと） 議事録を書く（改善余地あり） 得た情報を共有する（改善余地あり） 想定納期を示す（改善余地あり） カレンダー招待＆日程確約コメントを転記（改善余地あり） プロセス管理 仮説
先日、弊社では Community Geocoder というサービスをリリースしました。 Community Geocoder 紹介記事 さて、このジオコーダーは、住所を正規化してそれを「大字町丁目コード」という12桁の数字に変換し、そのコードをファイル名として GitHub ページ上に大量においた JSON ファイルにアクセスして緯度経度を取得するということをやっています。 つまり、住所の正規化からコードに変換する部分がとても重要で、そもそも正規化に失敗してしまうとどうしようもないという仕様なんです。 さいわい先日経産省が公開した IMI コンポーネントツール である程度のことをやってくれるのですが（というかそうであることを期待したのですが）、いろいろ調べ始めると住所という仕組みはほんとに複雑で、Facebook で絡んでくださった @hfu さんいわくまさに「自然言語処理そのもの」であ
Markdownでシーケンス図とかが書けるMermaid記法で業務フローを書いたら意外とイケたので自分なりのコツを紹介してみる | DevelopersIO
こんにちは、臼田です。 みなさん、業務設計してますか？(挨拶 今回はMarkdownでシーケンス図やフローチャートなどの図を記述できるMermaidを使って業務フローを書いてみたら、意外と書けたので自分なりのTipsを紹介したいと思います。 その前に 注意点として、まだMermaidを使い始めたばかりなので、「もっとこうしたらいいぞ」とか「こっちのほうがいいぞ」とかあれば建設的なフィードバックとしてSNSとかでいただけるとありがたいです。 あと業務フローって表現しましたが、人によって思い描く業務フローが違うと思うので、業務フローの定義に関するツッコミはご容赦ください。私が今回Mermaidで書いたのは以下の図です。(内容はブログ用に簡素化しました) この図のコードは以下のとおりです。(後ほど解説します) sequenceDiagram autonumber actor お客様 partic
Intro Fetch API の実装が広まり、 IE もリタイアを迎えたことで、今後忘れ去られていくことになるだろう XMLHttpRequest について。 どのように始まり、どのように広まり、どのように使われなくなっていくのか。その間に残した多大な功績を残す。 XMLHttpRequest の始まり この名前は非常に長いため、通常 XHR と略される。 この API は、現在の Web API のように W3C/WHATWG による標準化を経て策定された API ではない。 Microsoft によるいわゆる独自実装の API として始まり、後追いで標準化される。 したがって、 Web API の中でもかなり異質な命名である XHR が、 XmlHttpRequest でも XMLHTTPRequest でもなく XMLHttpRequest である理由も、 Microsoft の命
質問のコツ 質問内容は抽象的な言葉よりも具体的な言葉を選ぶようにすると、回答の精度がより上がります。 回答内容に対して、更に質問を繰り返して深掘りしていくと理解度が高まり効果的です。 「あなたはプロのエンジニアとして振る舞って下さい」などと最初につけるとよりそれっぽくなります。 文章が長くて途中で終わってしまう場合は、「続き」と入力すると続きからの回答をしてくれます。 わかりやすく解説してもらいたい時は「小学生でもわかるように解説して下さい」などとつけるとわかりやすい回答が返ってきます。 「私はプログラミング初心者です」など自分のレベル感を付けると、レベルに応じた回答になります。 「コードブロックだけで返事をしてください」とつけるとコードだけで回答してくれます。 ロードマップ(カリキュラム)編 まずは、目標に向けてどういった勉強をすべきかというロードマップ(カリキュラム)を提案してもらいま
糞コードは直すな。 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? とりあえず落ち着け。 みなさん、毎日なにかしらのコードを読み、開発する日々を送っていると思います。そんな中で、 糞コードは死ぬべきである！！絶対に直すべき！！ という感情に取りつかれてしまうことがあると思います。自分の技術力に自信のある人ほど、無理やりにでも直そうと試みると思います。それがどんな修羅の道か。そして、糞コード修正がどんな道を歩むのか。この記事では糞コード修正の罠とありがちなストーリーについて書きたいと思います。 ビジネスとしてのプログラムは本質的に糞である 例えば、「携帯電話の利用料金」のプログラムがあります。 「携帯電話
※品質保証のエンジニアである筆者が自省・戒めのために書いた記事になります 品質管理（Quality Control）、品質マネジメントは国内では製造業を中心に発展し、プロダクトの競争力向上に貢献してきました。 JTCと呼ばれる旧来からのメーカーでは、その実績・年功の蓄積に応じて、独立性を保った品質管理・品質保証部門が権威を獲得し、今でもソフトウェア開発に強い影響力を保持するようになっています。筆者は複数のメーカーを転職やコンサルで巡って来ましたが、例えば品質保証部門が承認しないとマイルストーンで開発がブロックされる、プロダクトがリリースできないといった権限を持つ体制が、今なお普遍的に見受けられます。 この品質保証部門が権力を持ち、品質ゲートの門番として振る舞う体制は、今であっても、ある面で恩恵を提供しています。例えば次のようなものです： 法規制対応、標準化対応、その他公的なガバナンス要求へ
脳に収まるコードの書き方
ソフトウェアは複雑さを増すばかりですが、人間の脳は限られた複雑さしか扱えません。ソフトウェアが思い通りに動くようするには、脳に収まり、人間が理解できるコードを書く必要があります。 本書は、拡張を続けても行き詰ることなくコードを書き、複雑さを回避するための実践的な方法を解説します。最初のコードを書き始めるところから機能を追加していくところまでを解説し、効率的で持続可能なペースを保ちながら、横断的な問題への対処やトラブルシューティング、最適化を行なう方法を説明します。自分のチェックリストからチームワーク、カプセル化から分解、API設計から単体テストまで、ソフトウエア開発の重要な課題に対する考え方やテクニックを紹介します。サンプルプロジェクトで使うコードは、Gitリポジトリの形で入手でき、試しながら学べます。 有効に機能するプロセスを選び、効果のない方法論から脱却する方法。チェックリストを使うこ
この投稿がきっかけでソフトウェアデザインに寄稿しています。この投稿の加筆修正ですが、自分のパート以外にもVS Code全般の特集となってますので興味あるかたはぜひそちらも！ ソフトウェアデザイン 2021年6月号 作者:tsutsu,吉岩 正樹,中村 充志,西谷 圭介,erukiti(佐々木 俊介),結城 洋志,上田 隆一,八田 昌三,サリチル酸,結城 浩,山川 正美,大串 肇,松本 直人,清水 洋治,広田 望,松田 佳希,田中 宗,中島 明日香,くつなりょうすけ,高橋 永成,金谷 拓哉,佐藤 雄飛,梶原 直人,髙濱 暢明,星川 真麻,八木澤 健人,けんちょん(大槻 兼資),職業「戸倉彩」,森若 和雄,大隈 峻太郎,小野 輝也,河野 哲治,古川 菜摘,石井 将直,杉山 貴章,Software Design編集部技術評論社Amazon はじめに Remote Containers Docke
Value Objectについて整理しよう - Software Transactional Memo
Value Objectとは何であるか? マーチン・ファウラーのPatterns of Enterprise Application Architecture(PofEAA)やエヴァンス・エリックのDomain Driven Design: Tackling Complexity in the Heart of Software(DDD)が原典であるが、PofEAAではこう切り出している。 When programming, I often find it's useful to represent things as a compound. プログラミング時は物をcompound(合成物)として表現すると便利なことがしばしばある。 例えば2次元空間上での座標のように複数のメンバ(属性)を持つ物は便利である、と。しかしそれらを比較する方法は一意ではない、そこで Objects that a
この記事は Laravel Advent Calendar 2020 - Qiita 最終日の記事です。 TL;DR DDD や "真の" クリーンアーキテクチャは， Web 業界における大抵の現場ではオーバースペックだし，導入しても全員がついてこれるとは限らない app/UseCases ディレクトリだけ切って，ドメインごとに単一責務なクラスを置くと使いやすいよ ActiveRecord 指向のフレームワークで Repository パターンを無理に導入すると死ぬので， UseCase で Eloquent Model の機能を使うことを恐れるな はじめに Zenn では初投稿です。日本の Laravel コミュニティではもうお馴染みのようで実はあまり顔を出していない（？） @mpyw と申します。オンラインサロンの火付け役となった Synapse が最初の仕事でしたが，就職後すぐ会社が
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 人は見た目が9割 皆さん一度はこの言葉を耳にしたことがあるのでしょう。内面がどれほど素晴らしくても、外見がそれに見合わないと、なかなか本当の価値を認めてもらえないものです。 この話は人間だけでなく、アプリケーションにも当てはまります。どれだけ内容が素晴らしくても、見た目がイマイチだったり使い勝手が悪かったりすると、ユーザーに敬遠されてしまいます。(私は以前ネ⚪︎フリからア⚪︎プラに切り替えたのですが、使いにくく感じたため、すぐに元のサービスに戻しました) エンジニアの皆さん、優れた技術力を持ちながら、デザインが原因でユーザー離
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? ＊この記事は2020年3月頭に書かれている記事です どうも、Vueはいいぞおねーさん(自称)です。 Vue.jsは私に言わせるととてもよいフロントエンドフレームワークであり、その理由の一つにプログレッシブフレームワークである(段階的に利用する機能を増やしていくスタイルにマッチしている)ものとして、フロントエンド初学者の皆さんにもおすすめしたい代物です。 しかし、現在までに様々なプラクティスが考案されたがゆえに、「最初からベストな方法で始めたい」という思いから一度にたくさんのことに挑戦してしまいたくなりがちです。 そしてそれはプログレッシ
Webサービスぶっ壊れ地獄、行きやすぜ！
はじめに なあジョージさんよ……あんた、いつもこう言ってたよな？ 「便利さとシンプルさ、それがユーザーも開発者も幸せにする秘訣だ」ってよ。 あたしゃな、その言葉に乗っかっちまった。ユーザーのため？ 開発を効率化するため？ そりゃあ立派なもんだ。でもな、それが「命取り」になることがあるんだぜ。 シンプルに作ったはずのサービスが、悪意ある奴らに好き勝手利用されて、時には「あたしの知らなかった地獄」を見せてくれる。越えたらいけない一線がある。そんな話を、今日はしようじゃねえか。 さあ、これがあたしらの舞台だ。 セキュリティの教科書には載らない、バグバウンティでも指摘されない、ニュースにもならない、「 現場のWebサービスぶっ壊れ地獄 」 ……教えてやりますぜ！！ 1. サインアップし放題からのクレカ決済し放題地獄 この地獄、知ってやがるかい？ 聞いてくれよ。ユーザーを簡単にサインアップさせる……
WebデベロッパーのVictor氏による下記のツイートから始まるスレッドが大変参考になる内容だと感じたので、ご本人に許諾を得て日本語で紹介させていただくことにしました。 I reviewed 100+ user interfaces this year. Avoid the most common 18 mistakes to make your UI/UX design better 👇 — Victor (@vponamariov) July 30, 2021 私は今年100以上のユーザーインターフェースをレビューしました。あなたのUI/UXデザインをより良くするための、下記に示す18個の良くある誤ちを回避しましょう。本記事で使用する画像はすべてVictor氏のツイートから拝借しています。なお翻訳には一部私の意訳が入っていることをご了承ください。 1. 薄いコントラストの文字適切では
多分今回のポストは多くの人には参考にならないだろう。相当ニッチなので。でもこれは自分にとってはとても大きなことだったので、忘れないように記録しておきます。 生産性の悩み あまりこの世界では生産性とはあいまいな言葉で、何をもって生産性が高いとは言いにくい。速いのが良いのではない。ただ、自分の実感として自分は生産性が良くないといつも感じていた。だからいろいろ努力したり、考え方をできる人を観察して真似してみたり、直接本人に聞いたりして工夫をしてきた。 実は自分はめっちゃコーディングが早い人になりたいわけではない。そうではなくて、「平均的」になりたいだけだ。それぐらいいければ「Strategy」でカバーできるどころかもっと上に行けると確信があったから。でもそうではなくて明らかに遅いのでそれが自分の足を引っ張っていた 努力の方向性 様々な努力をして、特に有効だったことを自分の本に書いたつもりではある
この記事はNuco Advent Calendar 2024の12日目の記事です。 はじめに エンジニアとして、開発を効率化しながらクオリティの高い成果物を生み出すには、優れたツールやリソースを活用することが欠かせません。 苦労して自分で作ったものの、実は便利なツールが既にあって、車輪の再発明をしてしまっていた、、ということも日常茶飯事です。 しかし、インターネット上には無数の選択肢があり、「どのサイトを使えばいいのか迷ってしまう」という声もよく聞かれます。 本記事では、そんなエンジニアの方々のために、日常的な開発やデザイン業務で役立つ便利なサイトを16個厳選しました。 UIデザインの参考になるサイトから、日々の業務を効率化するツールまで、多岐にわたるリソースをご紹介します。これらを活用することで、業務のスピードアップだけでなく、新たなインスピレーションを得るきっかけになれば幸いです。 1
営業、受注、制作、納品、運用と、ウェブ制作の活動は長期に渡り、そのタスクの種類と量は膨大です。だからこそ、基本的なプロセスや使用するドキュメントなどを明確に定義しておかないと、サービスの品質が担当者により大きく変わることになります。 ベイジは社員がまだ5名の頃、各人に委ねた進め方によって以下のようなトラブルが頻発していました。 ミスが発生しても「次から気をつける」と精神論で終わらせてしまう 担当するディレクターやクリエイターによってタスクの抜け漏れが起きる 担当者それぞれが属人的な進め方をしてて品質が安定しない 役割が不明瞭なグレーゾーンのタスクが放置されてしまう 創造的な仕事の時間が、ルーチンや計画にないタスクに奪われてしまう 新しい社員が入る度に同じことを教えないといけない これら問題を解決するため、2014年頃からワークフローを整備するようになりました。ちなみに私が入社したのはこれ以
この記事は、 Rails を主戦場としている自分が今後学ぶべき技術について(随筆) | うなすけとあれこれ についてのアンサー記事です。 うなすけ君が Ruby on Rails で育ってきたように、僕も JavaScript とともに育ってきたという自覚があります。なので、これについて書くことは、ポジショントークは避けられない、という感覚があります。 冷静に比較しようとも思いましたが、やっぱり開き直って思いっきりポジショントークをすることにしました。そっちのほうが面白いと思うので。 自分の基本的な主張は、こちらの記事にあるとおりです。 Frontend Study #1: 基調講演 - Frontend 領域を再定義する 自分と Ruby on Rails 僕は、キャリアとしては Rails の会社で JavaScript を書いてきたことが多かったです。学生の頃は socket.io
※月単価80万円を基準に、7ヶ月分の工数として560万円相当と換算しています。 最初に こんにちは！ 普段はIT企業でWebエンジニアとして働いています。 現在はフリーランスとして活動し、Ruby（Ruby on Rails）、TypeScript（Next.js, React）、Pythonなどを使って、フロントエンドとバックエンドの両方に携わっています。 将来はソフトウェアエンジニアとしてアーキテクチャ・設計について自ら意思決定した上、プロジェクトを推進する事が出来るようになりたいです。 そのためさらにスキルを磨いていきたいと思っており、日々技術に対して情熱を持って仕事に取り組んでいます。 以前Qiitaで 退職して560万円相当の工数をかけてお金を稼ぐサービスを開発した という事でBizRankというビジネス書籍を紹介するサービスを開発しました。 今回はその後としてのお話になります。
アプリケーション開発で、「ビジネスロジックは分離しろ」だとか「Controller にビジネスロジックを書くな」といったことをよく言われると思います。 しかし、ビジネスロジックという言葉の意味を聞いたり調べたりしてみても、「システムのコアの部分」とか「システムの目的になる処理をするところ」みたいなことを言われたりして、よく分かりませんでした。 そんな中、クリーンアーキテクチャや DDD の戦術的設計について学ぶことで、「ビジネスロジックとは何か」、「ビジネスロジックはどう実装するか」について、自分なりの考えが整理されてきたので、この記事ではそれをまとめます。 ※ 曖昧な言葉を自分としてどう使っているかという話になります。違う意味で使う方もいると思うので、ご注意ください ビジネスロジックとは何か 「システムのコアの部分」とか「システムの目的になる処理をするところ」といった説明も正しいとは思い
伝わるバグ報告 | さくらのナレッジ
この記事は2020年10月28日に行われたさくらの夕べ Tech Night #3 Onlineにおける発表を文章化したものです。 ダーシノと申します。さくらインターネットでフロントエンドエンジニアをやっています。この記事では、発生したバグをプログラマーに的確に伝えるためのバグ報告の書き方について説明しようと思います。 バグ報告にはコツがある！ プログラマをされている方で、過去にこんなバグ報告をもらった経験はないでしょうか。例えば「動きません」とだけ送られてきたりとか、イラッとした感情も含めた「使えねぇな！」みたいな報告、「アレもコレもソレもおかしいよ」みたいな、いろんなものが書かれた報告もあると思います。バグを残してリリースしてしまったプログラマーとしては非常に申し訳なくて今すぐ対応をしたいのですが、さすがに先ほどのようなバグ報告を受けても、我々プログラマは対応のしようがありません。「申
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事では、Webフロントエンド開発において役に立つと思われるサービスやツールをまとめます。 全般 Can I use 指定した特定の機能が、どのブラウザのどのバージョンで利用可能かを確認するためサービスです。新しいJavaScriptのAPIやCSS3の機能を使ってモダンなWeb開発を行う場合、必須とも言えるくらい利用することになります。 指定した国におけるブラウザのシェア情報をもとにして、特定の機能が何割のユーザーで使用可能かを調べることもできます。 npm / webpack BUNDLE PHOBIA 指定したnpmパッケージ
ベイジは2010年の創業以来、ウェブ制作事業を中心に事業を展開してきました。この事業では、サービスの質を統一するために2014年頃からワークフローの整備に取り組んできました。 一方ウェブアプリデザイン事業については、事業拡大したのがここ数年で、まだワークフローが整備されておらず、各人の裁量に委ねた進め方になっていました。そこで今後の事業拡大とメンバー増員を想定し作成したのが、業務システムやSaaSのUIデザインに特化した「ベイジの業務システムUIデザインワークフロー」です。 基本的な進め方は国際規格（ISO 9241-210※）の人間中心設計プロセスに基づいて組み立てていますが、細かいタスクの順序や内容は、今までベイジで培ってきたノウハウをふんだんに盛り込み、組み換えています。 そして、様々なプロジェクトでこのワークフローを実用しながら、今もアップデートを続けています。 また今回のワークフ
はじめに サーバーレスに触れて数年が立ちました。 そろそろ人にある程度説明ができるレベルの知識と経験が備わったような気もするので、年末なのでまとめてみました。 サーバーレス気になっているけれども、という人に少しでもためになればいいなーと思います。 サーバーレス基礎 皆さん、サーバーレス設計という話を聞いたことはあるでしょうか？ まずサーバーレスについて説明しますが、世の中にはたくさん解説記事があるのでそちらも適宜参照ください。 サーバーレスでも実際にはサーバーは存在する サーバーレスとは開発者がサーバーのことを意識しなくてもよい、ということ Function as a serviceに代表されるように、あるプログラムの実行環境を提供するが、プログラムの動作環境は開発者は意識する必要はない、というイメージ 恐らく、AWS Lambdaが一番理解しやすいと思います。 AWS Lambdaではプ
DDD失敗パターン集 DDDという方法論それ自体に対する僕の立場はあんま好きじゃない寄りのフラット（といいつつほぼ忘れかけている）なんですが、過去何度もDDDでプロジェクトが爆死するのをみたり、爆破してしまったり……というのを見てきたので供養したいとおもいます。 メンバーの大半がDDDを知らない 「えっ!? ドメイン駆動を知らずにDDDを?」 「出来らぁっ!」 DDDを知らずにDDDをする、という前提がすでに禅問答じみてる気がしますが、たぶん一番よく見かける失敗パターンなんじゃあないでしょうか。 どういうことかというと、オニオンとかレイヤードとかクリーンなアーキテクチャのモジュールの命名ルールと構造を採用（採用できているとは言っていない）しただけの状態です。 私見ですが、アーキテクチャというのはメンバー全員がそれを理解できていない限り*1即破綻します。 理解できない人はどこに処理を書いてい
「一時保存や下書きできるようにしたい」といった要望が出てくることがあると思います。世の中のサービスでよくある機能ですしあったら便利だなと思うのも当然です。 同じ要望を受けた当時の私はその大変さに全く気づいていませんでした。 意外と考えることが多いよ、というのが伝わると幸いです。 当初明確になっていた仕様 入力フォームには必須と任意の項目があるが、必須項目が未入力状態でも一時保存できる 入力フォームにはファイルを添付できる 正式データと一時データは同じ一覧ビューの中で両方とも表示させる 一時データはユーザー単位ではなく共有される（誰かが作った一時データは自分も閲覧編集できる） 一時データは正式データに対してひとつのみ存在できる 最終的には上記以外にももっと細かい仕様になったのですが、この後の検討や設計の流れに沿って随時記載していきます。 データの持ち方の方針 方法としては以下二つの案がありま
この記事は？ それぞれが専門にしている領域に関わらず、Webエンジニアリングの基礎知識として知っておきたいと思う事を対話形式でまとめていく。知識はインプットだけではなく、技術面接や現場では、専門用語の正しい理解をもとにした使用が必要なので、専門がなんであれ理解できるようなシンプルな回答を目指したものになっています。解答の正しさはこれまでの実務と各分野の専門書をベースに確認してはいますが、著者は各技術の全領域の専門家ではなく100%の正しさを保証して提供しているものではないので、そこはご認識いただき、出てきたキーワードの理解が怪しい場合各自でも調べ直すくらいの温度感を期待しています。なお、本記事で書いている私の回答が間違っている箇所があったりした場合、気軽にコメント欄などで指摘いただけるとありがたいです。 Webエンジニアリングの基礎 この記事でカバーしている領域は、以下のような領域です。W
サマリ ハッキングAPI―Web APIを攻撃から守るためのテスト技法（2023年3月27日発売）を読んだ。本書は、Web APIに対するセキュリティテストの全体像と具体的なテスト方法を記載している。ペンテスターは、APIの検出、APIエンドポイントの分析、攻撃（テスト）を行う必要があり、そのために必要な情報がすべて記載されている。また、実習のためのツールと「やられサイト」を複数紹介し、具体的なトレーニング方法を解説している。単にツールやサイトの使い方の説明にとどまらず、本格的なペネトレーションテストの考え方を説明している。 本書の想定読者はAPIのペネトレーションテストを実施するペンテスター及びペンテスターを目指す人であるが、API開発者やウェブアプリケーション脆弱性診断員にとっても有益な内容を多く含む。 重要事項説明 本書の監修者の一人（洲崎俊氏）と評者は知人関係にある 評者が読んだ書
はじめに どんなソフトウェアエンジニアも拡張しやすくメンテナンスしやすいソフトウェアを作りたいと思っているはずです。また、どんなプロダクトマネージャも同様に拡張しやすいシンプルな要求を作りたいと考えているはずです。 しかし、将来の不確実性や発展性に対して見通しを立てるのは難しいものです。そのため、開発チームの思いとは裏腹にソフトウェアの複雑性はどんどんと増大していきます。気がついたら技術的負債と呼ばれるような手もつけられない泥団子になってしまうということもしばしばです。誰もが生産性を下げるために機能を追加したいわけではなく、ビジネス価値を提供するために機能を追加したいだけなのにです。 このような状況を避けるためにはどうしたらよいのでしょうか。今回はその一つの手段として、要求には隠れた「意図」があり、それを発見していくことの重要性についてまずはお話しします。さらにわかりやすい要求が持つ仕様の
アプリケーションをユーザに公開する場合, それがGUIであってもCUIであってもインタフェースが必要になります. Webアプリケーションを公開する場合にはWeb APIを利用するのが一般的であり, AWSもAPIをフルマネージドで活用するためのAPI Gatewayを提供しています. 非常に簡単に活用できるのですが細かい機能などを今一度洗い直す機会があればと思っており, 社内勉強会の機会があったのでAPI Gatewayについて話しました. 今回の記事では社内向け勉強会で登壇した内容をブログ向けに再編しています. 資料はSpeakerDeckで公開していますが, 内容についてより細かくこのブログで説明しますので, 是非ご閲覧ください. What is API まず最初にAPIが何かを確認します. 大雑把に伝えるとアプリケーションが呼び出せば予期した結果を返されるような仕組みです. 名前にあ
正規表現は文字列の検索や置換を行うための強力で便利なツールです。基本をマスターすれば開発から日常の事務作業までさまざまな場面でラクをできる魔法の道具ですが、見た目がちょっと分かりづらいので、避けている方もいるのではないでしょうか？ 筆者の個人的観測ですが、とりわけフロントエンドのエンジニアには正規表現に苦手意識を感じている方が多いようです。 この記事では正規表現の基本と、正規表現がどこで使えてどれだけ便利になるのかを紹介します。 正規表現の基本：正規表現ってそもそも何？ 正規表現（regular expression）は、ごく簡単にいえば「さまざまな文字列のバリエーションをひとつの文字列で表現したもの」です。たとえば、郵便番号の7桁の数字には（実際に使われていないものも含めれば）一千万通りのバリエーションがありますが、正規表現を使えば次のようにひとつの文字列で表現できます。 ▼「7桁の数字
実践！ Typescript で DDD - マイクロサービス設計のすすめ - Leverages Tech Blog
対象読者 マイクロサービス化を検討しており、実際に作る場合の構成を参考にしたい。 ドメイン駆動設計について、基本的な用語の知識がある。 TypeScript を多少触ったことがある。理解がある。 はじめに こんにちは。エンジニアの吉村です。 現在、弊社が運営する teratail というサービスに携わっており、CakePHP で動作しているモノリシックな既存サービスをマイクロサービスに移行するというプロジェクトを進行中です。 この記事では、実務を通して得た知見として、マイクロサービス化によりどんな恩恵があるのか、具体的にどのような構成で実装をしているのかについてご紹介します。 TL;DR マイクロサービスのバックエンドサービスの実装に焦点を絞って、ドメイン駆動設計 + オニオンアーキテクチャをベースに設計をしました。 本記事では、具体的に「ユーザ新規登録処理」の実装をする場合を例にとり、実
NoSQLデータモデリング技法.markdown #NoSQLデータモデリング技法 原文：NoSQL Data Modeling Techniques « Highly Scalable Blog I translated this article for study. contact matope[dot]ono[gmail] if any problem. NoSQLデータベースはスケーラビリティ、パフォーマンス、一貫性といった様々な非機能要件から比較される。NoSQLのこの側面は実践と理論の両面からよく研究されている。ある種の非機能特性はNoSQLを利用する主な動機であり、NoSQLシステムによく適用されるCAP定理がそうであるように分散システムの基本的原則だからだ。一方で、NoSQLデータモデリングはあまり研究されておらず、リレーショナルデータベースに見られるようなシステマティック
今週は同僚と毎日長時間ペアプロしていた。 おもしろかったのが、同僚のテストの書き進め方で、一番複雑な正常系のテストをちゃんと書いてから、その複雑なテストをもとに、いろんな条件を削っていって異常系のテストを作っていく、というところ。 僕は逆で、入力が空なら何も起きない、とか、一番簡単な異常系のテストを書いて、そこだけ通るのを確認して、よしよし、と進めていって、メソッド本来の動きは最後に確認して終わる。 変な進め方だな〜(主観)と思って眺めていたけど、たしかに正常系のテストが通っていれば、あとはバリデーションまわりのチェックとか、例外となる場合のチェックをすれば終わりで、異常系のテストがすごい速さで書かれていておもしろかった。 …という話をしたら、チームメンバーたちは正常系のテストから書きはじめるという人が多くて、正しくことを確認してから、1個ずつ前提となる条件を外してみて試す、と聞いて、同値
Python 製 Web フレームワークを Flask から FastAPI に変えた話｜NAVITIME_Tech
こんにちは、けんにぃです。ナビタイムジャパンで公共交通の時刻表を使ったサービス開発やリリースフローの改善を担当しています。 今回は Python 製の Web フレームワークとして FastAPI を導入した話をしようと思います。 Python 製の Web フレームワークPython には代表的な Web フレームワークが 2 つあります。 ・Django: フルスタックフレームワーク ・Flask: マイクロフレームワーク Django は大規模開発向け、Flask は小中規模開発向けと言われますが、今回開発したサーバは小規模なサーバだったため、以前は Flask で開発していました。 しかし、どちらのフレームワークを使う場合でも下記のような機能を使おうとするとプラグインやサードパーティの助けを借りる必要があります。 ・OpenAPI ・JSON Schema ・GraphQL ・We
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
仕様書の参考例と、こんな内容を仕様書に最低書くといいというお話｜田辺めぐみ
日本の住所の正規化に本気で取り組んでみたら大変すぎて鼻血が出た。 - Qiita
XMLHttpRequest とはなんだったのか | blog.jxck.io
ChatGPTを最強の学習ツールにする方法 - Qiita
品質保証部門の陳腐化。そして陳腐化した品質保証は品質を悪化させる - 千里霧中
DockerとRemote Containersでの開発環境が最高過ぎる - Sweet Escape
5年間 Laravel を使って辿り着いた，全然頑張らない「なんちゃってクリーンアーキテクチャ」という落としどころ
【閲覧注意】イライラ不可避なUIデザイン10選 - Qiita
今からVue.jsを始める人のための「知るのを後回しにしてよい」n個のこと - Qiita
UIデザイン時にやってしまいがちな18の誤ち｜Mikio Kiura / ANKR DESIGN
今のチームに来てから最も生産性が上がった考え方｜牛尾 剛
【開発効率爆上がり】すべてのエンジニアが必ず見るべき16のウェブサイト - Qiita
ベイジのウェブ制作ワークフロー2021年版（約100のタスクと解説） | knowledge / baigie
Re: Rails を主戦場としている自分が今後学ぶべき技術について
【無料公開】560万円かけて開発したサービスのソースコード
「ビジネスロジック」とは何か、どう実装するのか - Qiita
Webフロントエンド開発で役立つサービスまとめ - Qiita
【2024年6月版】ベイジの業務システムUIデザインワークフロー（100のタスクを徹底解説） | ベイジのUIラボ～業務システムとSaaSのUIを考える
AWSでサーバーレス設計を考える時の手引き書 - Qiita
実はDDDってしっくりこないんです - タオルケット体操
「下書き」「一時保存」という要件を甘く見積もってはいけない
【Web】知っておきたいWebエンジニアリング各分野の基礎知見80
[書評] ハッキングAPI ―Web APIを攻撃から守るためのテスト技法
スケールする要求を支える仕様の「意図」と「直交性」 - Qiita
Amazon API Gateway は何をしてるのか | DevelopersIO
覚えれば一生もの！ ウェブエンジニアのための正規表現活用入門 - ICS MEDIA
NoSQLデータモデリング技法 · GitHub
テスト、正常系から書くか異常系から書くか - hitode909の日記