やはり俺の情報教科書はまちがっている。 - Qiita
目次 はじめに 個人を特定する情報が個人情報じゃない デジタル署名は暗号化しない TLS(SSL) は共通鍵を公開鍵で暗号化しない TLS(SSL) が使われていれば安全じゃない 変数は箱じゃない Python 等は「ソースコードを 1 行ずつ実行するインタプリタ方式」じゃない 日本語 1 文字は 2 バイトじゃない 動画が動いて見えるのは残像によるものじゃない 標本化定理は「2 倍以上の周波数」じゃない その他いろいろ はじめに 2022 年から高等学校で、プログラミング等を学ぶ「情報Ⅰ」が 必修 必履修科目になりました。1 さらには 2025 年入試から大学入試共通テストでも出題されるようになり、教科「情報」の重要性が高まっています。 これで 2030年に79万人不足すると言われる IT 人材 の問題が解決！…と言いたいところですが、先日も『課題感ある教科1位「情報」』という調査結果が
AWSが教えてくれないコスト削減の小話いろいろ | 外道父の匠
米ドル/円 が150円と計算しやすくなり、コスト削減の圧力が日々強まる中、皆様お宝探しと垂れ流し回収の真っ最中でございましょうか。 最近はコスト削減や予算について見ることが多いので、その中で出てきた面白げな話に雑談を加えてとりとめなく書いてみようと思います。 削減余地はある 昨年にご好評いただいた AWSコスト削減とリソース管理 | 外道父の匠 を含め色々な削減施策を試みてきましたが、サクッと成果になる箇所から泥沼に動かない所まで様々あったりします。 ただ、どんなアカウントでもトラフィックや処理負荷には波があり、それに対する余剰リソースを確保して構成しているので、その辺をキュッと絞ることまで含めればやれることは必ず一定以上存在することになります。 そういう大きなお宝ではない小さなお宝だと様々あり、古びたとか退職者が作ったとかで、ほぼ使っていない垂れ流しリソースやデータをかき集めれば、チリツ
リファクタリングをする際にソースコードの設計からはじめてはいけない - MonotaRO Tech Blog
どうも、レコメンド商品のシステム開発をしている野川と申します。 私は、2021年にモノタロウに新卒入社し、2022年5月からレコメンド商品の開発に関わり始めました。 モノタロウのレコメンド商品は、下の図の①～④の流れでクライアントサイドで表示しています。大部分の処理はJavaScriptで構成しており、UIもそのHTML部分をjQuery(JavaScript)で作成しています。 図：レコメンド商品表の流れ 入社当時私は、ソフトウェアエンジニアとして、「可読性の低いコードは駆逐するべきだ」「読みやすいコードだけが正義である」「理解しやすいシステムだけが皆を幸せにする」と心の底から考えていました。加えて、「なぜ先輩たちは可読性の低いコードを放置して平気なのか？」と疑問を持つこともしばしばありました。 レコメンド商品周りのコードはまさに可読性の低いコードベースとなっていたため、当事者となった私
〜2023年11月版〜 Leaner見積の開発プロセス
こんにちは。Leaner Technologiesの小久保(twitter:@yusuke_kokubo)です。 これはなに Leanerでは「Leaner見積」と「Leaner購買」という二つのプロダクトを開発提供しています。 ここでは「Leaner見積」の開発プロセスをざっくり説明します。 開発プロセスはプロダクトや事業、組織のフェーズによって日進月歩で変わっていきますので、あくまで執筆時点のスナップショットとしてご覧ください。 この開発プロセスの狙い 顧客フロントに立っているセールスや、カスタマーサクセスのメンバーと共同でプロダクト開発をするにあたり、以下の課題を設定して考えました。 （ビジネス側とDev側で）開発粒度の認識をいい感じに合わせたい （ビジネス側とDev側で）開発するうえでの難しさの認識をいい感じに合わせたい 今の開発プロセスになる前は、ここの認識が上手く合っていなかっ
【Rails】WebアプリにPWAを導入してネイティブアプリっぽくしてみた！ - Qiita
PWAとは？ PWAとは、「Progressive Web Apps」の略称で、PCやスマホでWebアプリを表示する際に、ネイティブアプリのような動作を可能にする仕組みのことです！ PWAを導入するメリットとして OSによる制限がないこと プッシュ通知を送ることができること ホーム画面にアイコンを設置できること Webアプリ上でキャッシュを使用でき、ローカルのキャッシュに保存できるため、再びアプリを開いた際の読み込みのスピードが従来よりも速くなること などが挙げられます！ 実装 まずは、app/views/layouts/application.html.erbに以下のように2箇所追記します！ <!DOCTYPE html> <html> <head> <title>Example</title> <%= favicon_link_tag('favicon.ico') %> + <link
APIデザイン中心の開発プラットフォーム「Apidog」を試してみた - Qiita
API設計、モック、テスト、ドキュメント作成を1つのプラットフォームで はじめに APIを開発する際に自分の知っている限りではこのような開発の流れとなっています。 要件を基にAPIのリクエストやレスポンスのインターフェースを設計する 設計した内容をドキュメントに残す モックを用意して、フロントエンド側の開発者が簡単な連携テストをすぐに出来るようにする APIを実装する 内部処理のテストを行う（DBに対する操作など） 実装したAPIがリクエストに対し想定通りのレスポンスを返すかAPIそのものに対するテストを行う そして、これらのフェーズで用いられるツールは異なっていることもあります。 設計、ドキュメント作成：Swagger UI、ReDoc等 あるいはExcelや社内Wiki モック：Swagger UI、Mock Service Worker等のライブラリ テスト：Swaggerの定義を基
実践要件定義入門以前 - 勘と経験と読経
最近ネットを見ていると要件定義入門的な記事が目についたので思ったことを書いてみる記事。ITシステム開発における要件定義に関するあれこれ。 【2023/10/10追記】続編の記事を書きました。実践要件定義入門 - 勘と経験と読経 目次 要件定義に関するおすすめ書籍 その要件定義は必要か 要件は決められるのか 要件定義をすることがルールで定められているから要件定義をする必要がある 要件は定義できるのか 現行の業務マニュアルをベースに要件定義をするつもりのあなたへ 現行システムをベースに要件定義をするつもりのあなたへ 外部業者を呼ぶ前に考えるべき事 どこから外注するかを考える 要件定義の作業期間を見積もる 要件定義に関するおすすめ書籍 この後に何度も引用することになると思うので、最初に要件定義のおすすめ書籍を紹介しておく。と言っても紹介するのは1つだけだ。 ユーザのための要件定義ガイド第2版 作
設計・ソフトウェアアーキテクチャを学べるGitHubリポジトリ 16選
はじめに 今回の記事では、設計やソフトウェアアーキテクチャを学べるGitHubリポジトリを16個紹介する。 対象とする読者 設計やソフトウェアアーキテクチャに興味関心があるエンジニア GitHubをエンジニアリングの情報収集に活用したいエンジニア タイトルで気になった人 Architectural Patterns システムの基本的な構成を理解するためのパターンやテンプレートを提供している。これらのパターンを学ぶことで、システムの構造やコンポーネントの関連性、相互作用を理解できる。これが開発者にシステムをより効率的かつ効果的に設計・実装する能力をもたらす。 Design Patterns for Humans 設計パターンを人間が理解しやすい形で説明している。デザインパターンは特定の問題に対して再利用可能なソリューションを提供する。これによって、開発者はより効率的にコードを記述でき、メンテ
【テンプレ付】chatgptを使ってツールの要件定義をしたら工数が40時間→4時間になった - みんなのシステム企画
「chatgptを使って要件定義の工数を削減したい」 「そもそもchatgptを使って質の高い要件定義ができるのだろうか」 とお悩みなのではないだろうか。 結論、chatgptで質の高い要件定義を短時間で実現することは可能だ。 実際に私もchatgptを使って下記のような要件定義書を完成させた。 通常この要件定義書を０から自力で作ろうと思うと４０時間はかかるが、chatgptを使う事によって４時間で完成させることができた。 しかし、ただプロンプトをなんとな投げ掛ければ良いというわけではない。 目的を達成するために綿密に設計をしたプロンプトを投げかける必要がある。 また、要件定義の中でも ・chatgptに丸投げして良いところ ・自分で手直しをした方が良いところ を精査することも大切だ そこで今回は上記のような要件定義書を4時間で完成させるために、私がchatgptへ投げかけたプロンプトを全
PlantUML備忘録(画面遷移図) - Qiita
画面遷移図で役立った構文 業務で画面遷移図(状態遷移図)を描きながら開発しているシステムの理解、未解決のバグを理解するタスクに取り組んだ時に助けられた構文を備忘録として残しておこうと思います。 合成状態 タブ遷移などを描くときに便利な構文として合成状態が有ります。 @startuml left to right direction title Example State Transition Diagram1 [*] -down-> メニュー1 メニュー1 -down-> メニュー2 state メニュー2 { [*] -down-> 概要 概要 -down-> 詳細 : 詳細 詳細 -down-> 概要 : 概要 } @enduml
いろいろおかしいマイナンバーカード｜青野慶久
新しく菅内閣が発足してデジタル化推進が叫ばれる中、その中心的政策であり、普及に向けて大量の税金が投入されているマイナンバーカード。でも、いろいろおかしくない？ 「マイナンバー」と「マイナンバーカード」は別物です。マイナンバーは国民の出席番号みたいなもので、ない方が不便だと思います。でも、それを使うために、新しくプラスチックの「物理カード」を「全国民に」発行して持たせる必要がありますか？ しかも、発行や更新の手続きが複雑すぎませんか？ 私の知識不足・勘違いもあるかもしれませんが、おかしいと思うところを列挙してみます。これを機に議論が活性化することを期待しています。 -- ・そもそもマイナンバーカードの目的がよくわからない。身分証明のためなら運転免許証や健康保険証でよくね？行政手続きのためなら普通にID発行してネットでやればよくね？ そもそも何が問題なの？ ・カードに書かれたマイナンバーが漏れ
糞コードは直すな。 - Qiita
とりあえず落ち着け。 みなさん、毎日なにかしらのコードを読み、開発する日々を送っていると思います。そんな中で、 糞コードは死ぬべきである！！絶対に直すべき！！ という感情に取りつかれてしまうことがあると思います。自分の技術力に自信のある人ほど、無理やりにでも直そうと試みると思います。それがどんな修羅の道か。そして、糞コード修正がどんな道を歩むのか。この記事では糞コード修正の罠とありがちなストーリーについて書きたいと思います。 ビジネスとしてのプログラムは本質的に糞である 例えば、「携帯電話の利用料金」のプログラムがあります。 「携帯電話 透明性高め料金値下げを」という記事もあるように世の中の携帯電話の料金プランはかなり複雑です。例えば、auだと「auでんき」といった電気料金とパックされた電話料金プランがあります。また、「auスマートバリュー」といったプランもあり、家のインターネット回線をa
フリーWi-Fiを使ったら秘密情報を抜かれる経路にはどのようなものがあるか - Qiita
ゴールデンウィークのはじめ（4月29日）に投稿された以下のツイートですが、5月7日20時において、1,938.8万件の表示ということで、非常に注目されていることが分かります。 我が名はアシタカ！スタバのFreeWi-Fiを使いながら会社の機密情報を扱う仕事をしてたら全部抜かれた。どうすればよい！ pic.twitter.com/e26L1Bj32Z — スタバでMacを開くエンジニア (@MacopeninSUTABA) April 29, 2023 これに対して、私は以下のようにツイートしましたが、 これ入社試験の問題にしようかな。『スタバのFreeWi-Fiを使いながら会社の機密情報を扱う仕事をしてたら全部抜かれた』と言う事象に至る現実的にありえる脅威を説明せよ。結構難しいと思いますよ。 https://t.co/LH21zphCTV — 徳丸 浩 (@ockeghem) April
マイナンバー制度は一部ITエンジニアが思っているような良いものではない～マイナンバーシステムの技術的問題点～｜ザード＠
結論マイナンバーのシステムはレイテンシーが酷すぎてリクエストを捌ききれない 一部ITエンジニアの主張について恐らく政府の意図もそこにあるのだろうが、特にITエンジニア界隈は現在の行政システムをマイナンバーで一元化して便利にしようという主張をしがちである が、結論としてはこれは不可能である。何故ならば政府のサーバは基本的にマイナンバーを保存していないからである 結論としてはマイナンバーと紐づいた符号というIDが各政府機関や保険組合ごとに発行され、この符号を使ってマイナンバーと結びつけて住基ネットで個人を特定して運用される。これがマイナンバーのシステムの全体像である つまり、政府含む特定の人たちがやりたいような集計処理をやろうとした場合、厚生労働省の中間サーバから符号を引っ張って来て財務省のサーバから符号を引っ張ってきてマイナンバーと紐づけて集計処理をする…のような処理…とはならない 何が問題
ちょうぜつ改め21世紀ふつうのソフトウェア設計
Forkwell Library #14 2023.1.25 のスライドです。 https://forkwell.connpass.com/event/271212/
どうやって技術的負債の雪だるまを生み出し、それを返済してきたか - 5年半越しの設計論
恥の多い生涯を送って来ました。 システムを開発していると、本当に多くの恥が生まれます。たとえば、こんな恥です。 テーブルの名前を付けミスったりは日常茶飯事。私が付けた変な名前が、自社の営業どころか他社のユーザーにまで浸透してたりもする。例えば、唐突に商品マスタに出てくる「グルーピングタグ」というカラムとか。（まじで意味不明） いま商品マスタと呼ばれているマスタの物理名が「kiosk_pricings」とか。日本語でおｋ。kiosk_pricings.grouping_tagってなんだよ。 「pricing」テーブルにはpriceカラムがあるが、全てのレコードで0になっていて、システムでは一切使っていないとか。（そのうち消したい） システムで使われている"正解"はkiosk_pricings.priceでした〜。 親子関係を間違えた事もある。チケットと決済の親子関係を入れ替えたりもした。 ま
ちょうぜつ設計とは - Qiita
ちょうぜつ設計概要 ちょうぜつ設計とは、自分の手でプログラムを書かない人たちの思い込みに反して、一見不思議に見えるけれど、普通の現役エンジニアが当たり前に備えている、暗黙的なソフトウェア設計センスの常識のことである。クリーンアーキテクチャとアーキテクチャ実体のメタ関係と構造的に同じになる。 なぜ変更しやすく作るのか ちょうぜつ設計の目的は変更容易性である。変更が容易なソフトウェアでなければ、反復的な開発に耐えることはできない。 使い捨ての簡単なソフトウェアはウォーターフォールで作ることができる。ウォーターフォールに変更容易性を求めるのは、技術者の自己満足にしかならない。反復的な開発において、以前開発した箇所を調整する、あるいは、運用を続けているサービスを壊さずに機能拡張する、といった目的がなければ、変更容易性は不要である。現代のソフトウェアの主流は当然後者である。 変更容易性は、結果得られ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Apidog APIの設計、デバッグ、開発、モック、テストを一体化した包括的なプラットフォーム
小さなバグが生んだ悲劇、そこから学ぶ耐障害性の高いアプリ設計
実践イミュータブルデータモデル — NEWTポイント機能の設計
