並び順

ブックマーク数

期間指定

  • から
  • まで

241 - 280 件 / 16795件

新着順 人気順

アーキテクチャの検索結果241 - 280 件 / 16795件

  • 銀行の基幹系システムはなぜ古臭いのか?|つっちーさん

    タイトル詐欺である。今回も反省せずに続きといきたい。 前回も示したが、ざっくりとした銀行の基幹系システムは「勘定系」「情報系」「チャネル系」の三つの構成になっているという図が上である。ざっくりとしたものなので、実際にはもっと複雑(特にメガバンクでは)だし、これがあるのにアレがない、とかいったものはある。細かいところを気にしすぎると禿げるぞ。 今回は、銀行の基幹系がなぜ古臭いのかという話をしたい。古臭いと言ってもいろいろあって、特にエンジニア界隈からは「メインフレームを使ってる」とか「COBOLみたいなカビの生えた古代言語を使ってる」とか、とにかくイケてないシステムの代表例のように言われることが多い。対して、預金者の側からはネットとの親和性だとかサービス面の不満からくるイケてないという話が多いと思うのだが、これはどちらかというとシステムの話ではなくて、サービス設計とかその背景になるビジネスモ

      銀行の基幹系システムはなぜ古臭いのか?|つっちーさん
    • Apple・AMD・テスラ・Intelを渡り歩いた天才エンジニアのジム・ケラー氏へのインタビューが公開中、Intelで一体何をしていたのか?

      AMDのAthlonやZenマイクロアーキテクチャ、Apple A4など数々のチップ開発に携わり、「天才エンジニア」と高い評価を受けるジム・ケラー氏は2021年1月にIntelを突如退職し、記事作成時点ではAIチップのスタートアップであるTenstorrentの社長兼最高技術責任者を務めています。そんなケラー氏に、技術系ニュースサイトのAnandTechがインタビューを行っています。 An AnandTech Interview with Jim Keller: 'The Laziest Person at Tesla' https://www.anandtech.com/show/16762/an-anandtech-interview-with-jim-keller-laziest-person-at-tesla なお、ジム・ケラー氏の経歴は以下の通り。 入社退職年企業肩書き関与した製

        Apple・AMD・テスラ・Intelを渡り歩いた天才エンジニアのジム・ケラー氏へのインタビューが公開中、Intelで一体何をしていたのか?
      • PayPayの1秒あたり1000決済への道のり

        パフォーマンス・チューニングに関するブログの第1回目です PayPayは、日本でもっともよく知られているQR決済サービスとなりました。2018年10月5日のローンチ後、2018年12月より実施した100億円あげちゃうキャンペーンは、その後のプロダクトの急成長に合わせたシステムのスケール拡張という長い道のりのスタート地点でもありました。 ここ数ヶ月の新規ユーザーの増え方[1]を見るにつけても、PayPayが驚異的な成長を続けていることは間違いありません。スタートアップ企業はまるで竹のように成長するとはこのことではないでしょうか。(竹は24時間で最大約90cmも伸びるそうです) PayPayの成長速度は? ユーザー数の伸び 2018年10月に初めてユーザーが増え、キャンペーンや日々メディアで報道されることによるユーザー数の増加もあり、1年後には1500万人を突破しました。2020年5月現在、サ

          PayPayの1秒あたり1000決済への道のり
        • ガチ三流エンジニアが米国マイクロソフトのドリームチームのメンバーになれた話とそのためにやった事 - メソッド屋のブログ

          私は卑下しているわけではなく、ガチでプログラミングの才能が無い。他に才能があるといわれる分野は持っているが、プログラマとしてはガチで三流だ。 そんな私が、今でも夢のようなのだけど、長年あこがれた米国マイクロソフトのドリームチームのポジションを得ることができた。今回はどうやってそのポジションをゲットすることができたかについてシェアしてみたい。 ガチの三流プログラマ 私はガチでプログラミングの才能が無い。プログラミングを始めたのは確か、10歳ぐらいだろうか?だからキャリアはスーパー長い。三流というのは謙遜ではなくて、自分と過去に仕事したことがある人なら知っていることだと思う。私には人より出来ることもある。それはコンサルティングだったり、アジャイルや、DevOps のコーチ、そしてエヴァンジェリストだ。日本のマイクロソフトではプレゼンは必ず上位だった。私は過去を振り返ると、何回もプログラマになろ

            ガチ三流エンジニアが米国マイクロソフトのドリームチームのメンバーになれた話とそのためにやった事 - メソッド屋のブログ
          • USBが誕生したのは「奥さんのプリンタをつなげる手間にキレたから」 USBの設計当時を振り返る

            USBが誕生したのは「奥さんのプリンタをつなげる手間にキレたから」 USBの設計当時を振り返る:“PC”あるいは“Personal Computer”と呼ばれるもの、その変遷を辿る(1/6 ページ) IBM PC、PC/AT互換機からDOS/Vマシン、さらにはArmベースのWindows PC、M1 Mac、そしてラズパイまでがPCと呼ばれている昨今。その源流からたどっていく大原雄介さんによる解説連載の第8回。前回はPCのアーキテクチャを巡るIntelとMicrosoftの動きを描いたが、今回はそこでIntelの取り組みの成果の一つとして挙げたUSBのお話である。 USBはいろいろ失敗もある(というか、現在進行形で失敗し続けている気もしなくはない)が、それでも大成功したインタフェースである。そして単にPCだけではなくマイコン(※1)などでも普通にサポートされるようになってきており、加えてP

              USBが誕生したのは「奥さんのプリンタをつなげる手間にキレたから」 USBの設計当時を振り返る
            • ウォータフォールはやめて2024年の開発をやろう!|牛尾 剛

              今回の記事は特に私の意見であり、所属会社の意見ではないことをお断りしておきます。 最近になってまたウォータフォール vs アジャイルの議論を見かけることが多くなってきたので、私が勤務する米国の世界規模のクラウドプロバイダーでは2024年現在どんな開発をしているのかをご紹介したいと思います。私はこれが「正解」といいたいのではなく、何らかのポイントが皆さんの何らかの参考になったらいいなと思って筆をとりました。 ちなみに、2016年時点で私のウォータフォール開発に対する考え方は下記のブログの通りで今も変わっていません。ただ、2024年現在だからといってアジャイルをやるべきと思っているわけでもありません。 もし、今ウォータフォールをやっている人がいたら「そんなこと言ってもどうしたらええねん」となると思うので、自分なりの解決方法も考えてみました。 最初に自分的な結論を書いておくと「2024年の開発と

                ウォータフォールはやめて2024年の開発をやろう!|牛尾 剛
              • 「もったいない」マインドが逆に効率を悪くする。フロー効率とリソース効率から考えるチームで仕事をする理由 - Qiita

                Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? #はじめに 前回、なぜ、ソフトウェアプロジェクトは人数を増やしても上手くいかないのかの記事において、プロジェクト型の人員規模を柔軟に変化させる開発スタイルに関して、理論的なスケジュール削減の限界について考察しました。その際に、チーム型開発や組織とソフトウェアの紐付けについても示唆しました。 今回は、チームでソフトウェアを開発することに関して、「フロー効率」と「リソース効率」という観点から考察し、なぜ私たちはチームで開発するのか、あるいはなぜプロジェクト型を採用するのかについての考え方を深めていきたいと思います。 そして、組織における効率

                  「もったいない」マインドが逆に効率を悪くする。フロー効率とリソース効率から考えるチームで仕事をする理由 - Qiita
                • QiitaやZennよりも便利? IPAの資料を読もう!

                  はじめに 飲み物じゃないIPAをご存じでしょうか? 漢字でいうと、独立行政法人 情報処理推進機構ですね。情報処理技術者試験を実施いる謎の組織という認識の方も多いと思います。 実はIPAはいろんなドキュメントを公開していてQiitaやZenn以上にお役立ちなサイトなのです。 まあ、AWSをどうこうとか、FireabaseやNext.jsのようなキラキラした奴は基本載ってないので特に代替えするものではないですが、ブログとかはまた種類の違った情報があるので個人的には結構使うことあります。しかも 「日本語」! こういう感じの事をTwitterでつぶやいたところ意外にイイねをされたので、せっかくだしどんなドキュメントがあるかちょっと紹介したいと思います。 セキュリティ関連NIST文書 まずはNISTドキュメントの翻訳版! これは良いですよね。NISTはアメリカの米国国立標準技術研究所で、セキュリティ

                    QiitaやZennよりも便利? IPAの資料を読もう!
                  • 設計を学びたいときに読みたい本一覧 - Qiita

                    これは何 の参加記事です。 エンジニアとして開発をしていく以上、設計についての知識を身につけていくことはとても重要です。 とはいえ設計という言葉からは何を勉強するべきかがいまいちピンときません。 この記事では、僕が読んできた設計に関するおすすめの本を網羅的に紹介しています。 これから設計を勉強する方の役に立てれば幸いです。 おすすめの本一覧 おすすめの本を紹介していきます。 他にもおすすめがあればぜひ編集リクエストをください! オブジェクト指向設計実践ガイド 設計を始めに学ぶならこれ、という一冊です。 エンジニアとして開発を行なっている中で、オブジェクト指向設計は一番汎用的に使う設計知識なのではないでしょうか? オブジェクト指向設計を学ぶことで、いわゆる「におう実装」と「良い実装」を見極めることができるようになると思います。 知らなかったら読んだほうが良いキーワード SOLID原則 Cle

                      設計を学びたいときに読みたい本一覧 - Qiita
                    • DMMはAWS“から”オンプレミス“に”切り替える サーバーとネットワークのコストから見直す適切な環境選び

                      DMM. comのITインフラ本部が今期に注力している取り組みについて、事例を紹介しつつ話す「DMM meetup #31 ~DMMのインフラを支えるITインフラ本部の取り組み紹介~」。ここでSRE部の松浦氏が登壇。WebRTCの配信システムについてと、配信サーバーをAWSからオンプレミスに切り替える理由を紹介します。 AWS“から”オンプレミス“に” 松浦庸介氏(以下、松浦):SRE部の松浦から「WebRTCの配信システムをAWSからオンプレミスに切り替えている話」ということで発表したいと思います。 まず、簡単に自己紹介をしたいと思います。2020年の5月に入社して、それ以来WebRTCのリアルタイム配信システムの開発や運用を担当している、松浦と言います。本日はよろしくお願いします。 まずこのタイトル、みなさん「AWS“から”オンプレミス“に”」というところ、気になってる方がいるんじゃな

                        DMMはAWS“から”オンプレミス“に”切り替える サーバーとネットワークのコストから見直す適切な環境選び
                      • 開発者の年功レベル

                        Kamran Ahmedのブログより。 ジュニア、中堅レベル、またはシニア開発者としてステップアップするには? カムラン・アーメッド (Kamran Ahmed) 私はロードマップのやり直しに取り組んでいます —— 年功レベルに基づいてスキル一式を分割し、新しい開発者に理解しやすくし、怖がらせないようにします。ロードマップは技術的な知識についてだけになるので、私が繰り返し、様々な年功の役割について考えていることについて記事を書くのは良い考えだと思いました。 私は、多くの組織が長年の経験を本来あるべきものよりも重要視することで開発者の年功を決定しているのを目にしてきました。私は、「ジュニア」とラベル付けされた開発者がシニア開発者の仕事をしており、「シニア」と呼ばれる資格さえない「主任(lead)」開発者を見てきました。開発者の年功は、彼らの年齢、経験年数、または彼らが持っている技術的知識だけ

                        • AWS公式の無料EラーニングでAPI Gateway REST APIを網羅的に学ぶ | DevelopersIO

                          Amazon API Gateway について紹介し、API を作成してデプロイする方法を学習していただける無料デジタルコース Amazon API Gateway for Serverless Applications (Japanese) - 75min をローンチしました? 認定インストラクターが日本語でスタジオ収録していますので是非!https://t.co/emJoRhImIH pic.twitter.com/3zEnTb6WI8 — Wataru Nishimura (@kuwablo) January 27, 2021 上記で紹介されているAPI Gatewayを学べるEラーニングを受講したのでレポートします。 Amazon API Gateway for Serverless Applications (Japanese) 良かったこと 体系的に学べる API Gatewa

                            AWS公式の無料EラーニングでAPI Gateway REST APIを網羅的に学ぶ | DevelopersIO
                          • ソフトウェアアーキテクトが知るべき 97 のこと

                            【01】システムの要件よりも履歴書の見栄えを優先させてはならない by ニティン・ボーワンカー 【02】本質的な複雑さは単純に、付随的な複雑さは取り除け by ニール・フォード 【03】最大の問題は、たぶん技術的なことではない by マーク・ラム 【04】まずコミュニケーション、そのための明快さとリーダーシップ by マーク・リチャーズ 【05】パフォーマンスの決め手はアーキテクチャー by ランディ・スタッフォード 【06】要求仕様の本当の意味を探れ by アイナー・ランドル 【07】立ち上がろう! by ウディ・ダーハン 【08】すべてのものは、かならずエラーを起こす by マイケル・ナイガード 【09】それは交渉だということに気付け by マイケル・ナイガード 【10】定量化を求めよ by キース・ブレイウェスト 【11】500 行の仕様書より 1 行のコード by アリソン・ランダ

                              ソフトウェアアーキテクトが知るべき 97 のこと
                            • 単一責任の原則(Single responsibility principle)について、もう一度考える | オブジェクトの広場

                              単一責任の原則(Single responsibility principle)について、もう一度考える はじめに オブジェクトの広場をご覧の皆様ならば、「SOLID原則」という言葉を聞いたことがあるかもしれません。 SOLIDとは、以下の5つのソフトウェア設計原則を並べたバクロニムです。 Single Responsibility Principle:単一責任の原則 Open/closed principle:オープン/クロースドの原則 Liskov substitution principle:リスコフの置換原則 Interface segregation principle:インターフェース分離の原則 Dependency inversion principle:依存性逆転の原則 ソフトウェアエンジニアが知っておくべき設計原則のセットとして、Clean Architecture や

                                単一責任の原則(Single responsibility principle)について、もう一度考える | オブジェクトの広場
                              • 安全安心にソフトウェア開発を行うためのDesign Doc導入ガイド|面川泰明

                                みなさん、コードを書く前に設計書を書きますか? 書くか書かないかは人それぞれだと思いますが、「設計」というプロセス自体は意識的であれ無意識的であれエンジニアであれば全員やっていることだと思います。 今回は設計プロセスの改善という文脈で私たちがDesign Docという仕組みを導入したことについて共有しようと思います。もし同じような状況を経験している人がいたら参考になれば幸いです。 導入の背景まずは導入するに至った状況からお話します。 私たちのサービスは、利用していただくユーザーの数が増加しています。それに伴って品質のハードルも上がってきました。サービスに障害が発生するとユーザーさんに大きな損害を出してしまうことになるからです。そこで今まで以上に安全にサービスを開発できる仕組みづくりが必要になりました。ですが、実現のためには大きく2つの課題がありました。 課題1. 開発スピードが徐々に鈍化し

                                  安全安心にソフトウェア開発を行うためのDesign Doc導入ガイド|面川泰明
                                • データベースの仕組み(アーキテクチャ)をざっくり理解する

                                  フリーランスエンジニアをしているrevenue-hackです! 普段はGo言語でバックエンドを中心にやっています〜 ↓登壇したときの資料です! より図を入れて詳しく書いております! 今回はデータベースの特にRDBの仕組み(アーキテクチャ)についてざっくり理解して、なにかに役立てようぜ〜 というような内容になります。 ↓記事はこちらに移しました!↓

                                    データベースの仕組み(アーキテクチャ)をざっくり理解する
                                  • shiodaifuku.io

                                    Webエンジニアのブログです。

                                      shiodaifuku.io
                                    • Re: Rails を主戦場としている自分が今後学ぶべき技術について

                                      この記事は、 Rails を主戦場としている自分が今後学ぶべき技術について(随筆) | うなすけとあれこれ についてのアンサー記事です。 うなすけ君が Ruby on Rails で育ってきたように、僕も JavaScript とともに育ってきたという自覚があります。なので、これについて書くことは、ポジショントークは避けられない、という感覚があります。 冷静に比較しようとも思いましたが、やっぱり開き直って思いっきりポジショントークをすることにしました。そっちのほうが面白いと思うので。 自分の基本的な主張は、こちらの記事にあるとおりです。 Frontend Study #1: 基調講演 - Frontend 領域を再定義する 自分と Ruby on Rails 僕は、キャリアとしては Rails の会社で JavaScript を書いてきたことが多かったです。学生の頃は socket.io

                                        Re: Rails を主戦場としている自分が今後学ぶべき技術について
                                      • 良いドキュメントを書きたくなる本を読んだらドキュメンタリアンになりたくなった - じゃあ、おうちで学べる

                                        ドキュメンタリアンとは、役職に関係なく、ソフトウェア業界でドキュメントとコミュニケーションに関心を持つ人のことです。 www.writethedocs.org はじめに これは主に『ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング』の書評です。私はSreakeにてSREという役職についています。SREはサービス概要、アーキテクチャの解説や図、各種構成図、各種手順書、ポストモーテム、ポリシー、SLA(SLO) … その他の様々な場面でドキュメントを書く必要があります。しかし、ドキュメントは価値が見えにくく時間と労力がかかり品質担保の面で重要度がとても高いのにその場での価値が見えにくいので浸透しにくいです。そのため、エンジニアとしてモチベーションが保ちづらいです。2021年 State of DevOps 2021 にもドキュメントに関する言及があり今後、

                                          良いドキュメントを書きたくなる本を読んだらドキュメンタリアンになりたくなった - じゃあ、おうちで学べる
                                        • 今いちばんオススメしたいPython本 2022 - 初心者からプロまで仕事に活かせる3冊 + α - Lean Baseball

                                          2021年も数多くのプログラミングやPythonを扱った素晴らしい書籍とたくさん出会いました. 私はリアルの本屋さんに行くのがとても好きで(ECの本屋さんも好きですが), 技術書のコーナーには必ずと言っていいほど足を運ぶのですが, 年々「Python」というラベルが付いた棚の領域が広がっている気がします. プログラミング初心者でPythonからやりたいけど何から読めばいいのか🤔 実務に役立つような参考書籍ってどうやってみつければいいかわからない😇 よりビジネスに役立つ, 実践的な事例をしりたい💪🏻 という, 割とありそうなニーズにお応えすべく, 2022年いや, 今この瞬間に読んでおきたい・抑えておきたいPython関連書籍をまとめました! 2011年頃からPythonを使って仕事をし始め, 今もエンジニアリングからコンサルティング, マネジメントをやっている私独自の視点で, オス

                                            今いちばんオススメしたいPython本 2022 - 初心者からプロまで仕事に活かせる3冊 + α - Lean Baseball
                                          • 否定文を理解できないAIたち - ジョイジョイジョイ

                                            BERT や GPT の登場により、テキストを扱うモデルは大きく発展しましたが、否定というごくありふれた操作を扱うのが依然難しいです。 本稿では、その理由と、部分的な解決策を紹介します。 目次 目次 否定文を理解できないAIたち 否定文を理解できずに困ること なぜ否定文をうまく扱えないのか なぜたまに成功するのか 対処法 ファインチューニング プロンプトの工夫 否定文を意識した訓練 文書数を増やす クエリとキーを拡張する おわりに 否定文を理解できないAIたち BERT (tohoku-nlp/bert-base-japanese-v3) で A =「私はお寿司が好きです。」 B =「私の好きな食べ物はお寿司です。」 のテキスト埋め込みのコサイン類似度を求めてみましょう。A と B は同じようなことを言っており、予想されるようにコサイン類似度は 0.9695 と高いです。 では、 A =「

                                              否定文を理解できないAIたち - ジョイジョイジョイ
                                            • ゼロからのハイパーバイザ自作入門

                                              本書では、64-bit ARM (ARMv8/AArch64) アーキテクチャを前提としたハイパーバイザの仕組みをできるだけ分かりやすく解説し、実際にラズベリーパイ4やQEMUで動作するハイパーバイザ (Type1) を自作する方法を解説しています。 ソースコード: https://github.com/HidenoriMatsubayashi/evisor ⬛︎ 注意 本書はまだ作成中(現在5章を作成中)ですが、モチベーション維持のために公開している状態です(章立てなど今後変わる可能性ありです)。内容は随時更新していますので、気になる方はウォッチやコメント等をお願いします。 ⬛︎ 学べること ・ハイパーバイザとその仕組みと原理 ・64-bit ARM (ARMv8/AArch64) アーキテクチャの仮想化支援機構 ・自作ハイパーバイザの作り方 ⬛︎ コミュニティ 質問や間違い指摘など本書

                                                ゼロからのハイパーバイザ自作入門
                                              • やはり予想を超えてこなかったGPT-4と、GPUの未来、ホビイストへの手紙

                                                やはり予想を超えてこなかったGPT-4と、GPUの未来、ホビイストへの手紙 2023.03.16 Updated by Ryo Shimizu on March 16, 2023, 08:00 am JST 3月14日の早朝、GPT-4が公開され、筆者は早速試した。 その後、開けて3月15日の早朝、APIも部分的に解放され、筆者はそれも試した。 その上で、先週書いた記事の内容についての確信が深まった。 やはり、GPT-4は期待を超えてはこなかった。 GPT-4は、ChatGPT Plusに入会すると誰でもすぐに使うことができる。APIだけは招待制だが、それも筆者と同じくらいのタイミングでアンロックされた方も少なくないのではないか。 100倍規模のパラメータがあっても、アプローチには限界があるのである。 また、ChatGPTが注目を集めたことで、これまで下火になっていた他の大規模言語モデル(

                                                  やはり予想を超えてこなかったGPT-4と、GPUの未来、ホビイストへの手紙
                                                • 【決定版】2022年~2023年で必ず確認するべきGitHubリポジトリ 40選

                                                  はじめに 今回の記事では、個人の独断と偏見で2022年~2023年で必ず確認するべきGitHubのリポジトリを紹介する。私のTwitterでこれまで紹介したものもあれば、そうではないものもある。 GitHubはプログラマーにとって、普段の学習・開発を進めるうえでもっとも重要な情報源の1つである。本記事では、分野ごとに確認するべきGitHubリポジトリを紹介する。 なお、今回の記事で紹介するGitHubリポジトリの分野は以下の通り。内容はWeb開発に特化している。 確認必須 Web Python JavaScript TypeScript ちなみに、「確認必須」は分野を問わずすべてのプログラマーに役立つGitHubリポジトリを紹介している。 今回の記事を通して、年末年始の学習・開発に大いに役立ててもらえたら幸いだ。 確認必須 freeCodeCamp 世界最大規模のプログラミングメディア「f

                                                    【決定版】2022年~2023年で必ず確認するべきGitHubリポジトリ 40選
                                                  • 桃太郎電鉄の「いけるかな」を実現する高速なアルゴリズムの実装と考察 - Qiita

                                                    この記事は「データ構造とアルゴリズム Advent Calendar 2020」16日目の記事です。 15日目の記事はyurahunaさんの「木分解上の動的計画法」で、 17日目の記事はtsukasa__diaryさんの「Lawler の K-Best 列挙アルゴリズム」です。 この記事内で使用しているプログラムやそのテストプログラムは全て以下のGitHubリポジトリで閲覧可能です。プログラムの詳細に興味がある方はこちらをご覧ください(ついでにStarを押していってくれると喜びます🙂)。 Github: ashiba/Imprementation_of_IKERUKANA: Momotaro Dentetsu is a game. 変更履歴 2020/12/21に「最終的に貧乏神が付かない移動方法 ~貧乏神持ちの場合~」, 「最終的に貧乏神が付かない移動方法 ~貧乏神がついていない場合~

                                                      桃太郎電鉄の「いけるかな」を実現する高速なアルゴリズムの実装と考察 - Qiita
                                                    • 1年以上かけて生産性倍増+成長し続けるチームになった施策を全部公開 - Qiita

                                                      Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 1. はじめに 本稿は、私が1年以上の期間をかけて、成長し続けるチームに変わることができた施策を紹介します。 本稿は長文なので、忙しい人は太字だけを拾い読みして、興味をもった施策だけを詳しく読んでいただければと思います。 なお、本稿の内容で「Developers Summit 2020 KANSAI」というカンファレンスで発表した結果、ベストスピーカー賞1位をいただきました。発表を視聴してくださった方々に感謝しております。 発表資料と発表動画はコチラ 2. 施策の効果 私の開発チームは当初(1年と数ヶ月前)は、以下の状態でした。 あまり

                                                        1年以上かけて生産性倍増+成長し続けるチームになった施策を全部公開 - Qiita
                                                      • 【無料公開】560万円かけて開発したサービスのソースコード

                                                        ※月単価80万円を基準に、7ヶ月分の工数として560万円相当と換算しています。 最初に こんにちは! 普段はIT企業でWebエンジニアとして働いています。 現在はフリーランスとして活動し、Ruby(Ruby on Rails)、TypeScript(Next.js, React)、Pythonなどを使って、フロントエンドとバックエンドの両方に携わっています。 将来はソフトウェアエンジニアとしてアーキテクチャ・設計について自ら意思決定した上、プロジェクトを推進する事が出来るようになりたいです。 そのためさらにスキルを磨いていきたいと思っており、日々技術に対して情熱を持って仕事に取り組んでいます。 以前Qiitaで 退職して560万円相当の工数をかけてお金を稼ぐサービスを開発した という事でBizRankというビジネス書籍を紹介するサービスを開発しました。 今回はその後としてのお話になります。

                                                          【無料公開】560万円かけて開発したサービスのソースコード
                                                        • 「ビジネスロジック」とは何か、どう実装するのか - Qiita

                                                          アプリケーション開発で、「ビジネスロジックは分離しろ」だとか「Controller にビジネスロジックを書くな」といったことをよく言われると思います。 しかし、ビジネスロジックという言葉の意味を聞いたり調べたりしてみても、「システムのコアの部分」とか「システムの目的になる処理をするところ」みたいなことを言われたりして、よく分かりませんでした。 そんな中、クリーンアーキテクチャや DDD の戦術的設計について学ぶことで、「ビジネスロジックとは何か」、「ビジネスロジックはどう実装するか」について、自分なりの考えが整理されてきたので、この記事ではそれをまとめます。 ※ 曖昧な言葉を自分としてどう使っているかという話になります。違う意味で使う方もいると思うので、ご注意ください ビジネスロジックとは何か 「システムのコアの部分」とか「システムの目的になる処理をするところ」といった説明も正しいとは思い

                                                            「ビジネスロジック」とは何か、どう実装するのか - Qiita
                                                          • 「カブトクワガタ」は日本のゲームアクセシビリティの革命である

                                                            3行で 「カブトクワガタ」に搭載されている読み上げ機能によって、画面を見ることができない全盲のプレイヤーがゲームを楽しめるようになっています。 視覚に障害を持つプレイヤーだけでなく、未就学児や、文字を読むことに困難を抱える人など、色々な属性の人がプレイできるようになっていると思います。 システム面・技術面の両方において、「カブトクワガタ」は日本のゲームアクセシビリティに革命をもたらすポテンシャルがあり、その事実が、開発者を含めた多くの人に知られることを臨みます。 ※最終更新: 2023/07/27 カブトクワガタってなんやねん カブトクワガタ は、Nintendo Switchのゲームです。クワガタやカブトムシを育てて戦うRPGです。2023年3月15日にリリースされました。 なにがすごいのか ほぼ全ての文字を読み上げる このゲームは、画面に表示されるほぼ全ての文字を読み上げてくれます。本

                                                            • 月10万円の売上を目指して、個人開発でやったこと全てを公開 - Qiita

                                                              収益化方法の整理 今回の目的の1つの、売上月10万円を達成するために、まずは代表的な収益化モデルについて整理しました。こちらもNotionまとめたものをそのまま転載します。 純広告 広告を掲載したい企業を募集し、掲載料をもらう。ある程度のPV数がないと掲載するメリットないのでPV数があることが前提。バナー広告、テキスト広告、動画広告などがある。 ネイティブ広告 PRマークはつくが、Webメディアのコンテンツに溶け込むように掲載するタイプの広告。デザインを壊さない。 アフィリエイト 成果報酬型の広告。広告をクリックしたユーザーが商品を購入してはじめて収益になる。広告料を払ってくれる企業を募る必要がない。ASP(A8,バリューコマース,楽天等)に登録すればいろんなジャンルの広告が扱える。 アドネットワーク 広告媒体になるサイトを集約し、一括で配信する仕組み。広告枠を設置すれば自動で広告が配信さ

                                                                月10万円の売上を目指して、個人開発でやったこと全てを公開 - Qiita
                                                              • 【資料公開】アジャイルについてマネージャーが知るべき97のこと

                                                                みなさんこんにちは。@ryuzeeです。 昨年12月に新刊『チームトポロジー』が発売になったのでぜひよろしくお願いします。 アジャイルコーチや技術顧問の仕事は多岐にわたりますが、その1つに社内での講演やセミナーがあります。 今回、技術顧問先のイベントで登壇しましたので、その際の資料を公開します。 アジャイルとは直接関係ないものも多々含まれていますが、ネタということでご了承ください。 アジャイル全般QCDSを同時にすべて固定することはできない要件の決まったものを早く・安く作る方法ではない開発だけをアジャイルにしても意味がないアジャイルで請負契約は無理だと心得ようすべてがアジャイルに適しているわけではない大規模アジャイルは小さなアジャイルの成功後アジャイル導入を支援しようアジャイル推進での組織的な課題に取り組もう無駄な社内プロセスを廃止するよう働きかけよう効率ではなく成果に着目した組織設計をし

                                                                  【資料公開】アジャイルについてマネージャーが知るべき97のこと
                                                                • WEB アプリケーション設計入門 / Introduction to web application design

                                                                  PHP Conference Japan 2020 トーク前提の資料です。そのため、トークがないと理解が難しいかもしれません。 https://youtu.be/UTKJ-Lgn3aI?t=36 ※冒頭音声が小さいです。マイクを手に持ってから聞こえやすくなると思います。 資料中の ADOP …

                                                                    WEB アプリケーション設計入門 / Introduction to web application design
                                                                  • Amazon EC2 を Arm に切り替えたら幸せなことしかありませんでした | CyberAgent Developers Blog

                                                                    技術本部 サービスリライアビリティグループ(SRG)の長谷川 @rarirureluis です👳 #SRG(Service Reliability Group)は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。 はじめに Apple M1 で Arm という単語をよく耳にし、そしてその性能に驚いた方も多いと思います。Apple M1 が搭載された Mac のベンチマークはこちら そして Amazon EC2(以下:EC2)にも Arm が搭載されたインスタンスがあります。 https://aws.amazon.com/jp/ec2/graviton/ 今回はとあるサービスの全開発環境の EC2 インスタンスを m5.large から t4g.medium へ移行したら幸せになれたので、この記事を

                                                                      Amazon EC2 を Arm に切り替えたら幸せなことしかありませんでした | CyberAgent Developers Blog
                                                                    • Apple iPod touch の生産終了により飲食業界に打撃か

                                                                      5月10日(現地時間)、「Apple(アップル)」が生産終了を発表したiPod。音楽を聴く端末として2001年から発売された本シリーズのうち唯一生き残っていたiPod touchだが、『M&A Online』によると、このモデルの生産打ち切りにより、意外にも飲食業界が打撃を受けてしまいそうだというのだ。 飲食業界のどのシーンで利用されているかわからないという方も少なくはないと思うが、レストランやカフェ、居酒屋などの飲食店で、店員がオーダーを受ける際にスマートフォンのような“ハンディ”を使用している姿を見かけたことはあるだろうか。“電話機能のないiPhone”として親しまれていた4インチディスプレイ搭載のiPod touchは、CPUにiPhone 7シリーズと同様のA10 Fusionを採用しており、最新のOSにも対応。先述した通り、電話機能を備えていないため、iPhoneと比較して約3万

                                                                        Apple iPod touch の生産終了により飲食業界に打撃か
                                                                      • DI (依存性注入) って何のためにするのかわからない人向けに頑張って説明してみる - Qiita

                                                                        追記 2022/11/12 追記 この記事読んで、DI 便利だなって思ったらこちらも併せて読んでみてください。クリーンアーキテクチャーの開設の中で依存性逆転の説明が出てきます。難しいかもしれませんが、一度理解すればつぶしが効く考え方なので腰を据えて読んでみてください。 本文 ここでは、最近のそこそこの規模のアプリだと大体使われてる(と私は思ってる)Dependency Injection(DI)について、何故使ってるのか?というのを私の理解で書いていきたいと思います。 今回の対象言語は C# ですが、DI 使ってる言語であれば大体同じ事情なのかなと思います。 単体テストしたいよね アプリケーションを作るとうまく動いているかテストをすると思います。 たとえ、そのアプリがハローワールドだとしても動かして目視で確認してると思います。 もうちょっとアプリの規模が大きくなってくるとクラス単位やクラス

                                                                          DI (依存性注入) って何のためにするのかわからない人向けに頑張って説明してみる - Qiita
                                                                        • 「無人化システム」を駆逐する組織マネジメントとエンジニアリング

                                                                          弊社では2019年3月ごろから「無人化システム」の駆逐を進めています。本記事ではこの取り組みを、組織マネジメントとエンジニアリングの側面から紹介します。 恐怖の無人化システム 「無人化システム」は社内の独自用語なので、まずは言葉の意味から説明します。 無人化とはなにか 無人化の前に属人化について触れておきましょう。weblio辞書から属人化について引用します[1]。 ある業務を特定の人が担当し、その人にしかやり方が分からない状態になることを意味する表現。 無人化は属人化の進化系です。無人化とは「属人化していた業務の担当者がいなくなってしまい、誰にもやり方が分からない状態になること」と定義できます。誰がどう見てもダメな状態ですね。 無人化システムとはなにか システム運用が属人化し、かつその運用者が退職するとシステムが無人化します。我々の会社ではこのようなシステムを『無人化システム』と呼んでい

                                                                            「無人化システム」を駆逐する組織マネジメントとエンジニアリング
                                                                          • エンジニアとして今の自分を形成した本を5冊紹介する - パンダのプログラミングブログ

                                                                            エンジニアとして今の自分を形成した本5冊 エンジニアとして働くにあたって自分が大きく影響を受けた本を考えてみた。もちろん他にもあるが、今回は以下の5冊に絞って紹介する。 Clean Coder(クリーンコーダー) Team Geek Clean Architecture(クリーンアーキテクチャ) テスト駆動開発 LeanとDevOpsの科学 この記事の対象者としては、独学でプログラムを書き始めた人やエンジニアスクールを卒業したばかりの方というよりは、実務経験を1~3年くらい積んでいるけど次に何を学べば良いかわからず、自分でイマイチ伸び悩んでいると感じている人を主に想定している(かつての自分がそうだった)。 特にチーム開発、オブジェクト指向言語でのコーディング、テストコードを書いた経験がある人が読んで、本に書いてあることを実践すると自分の成長を実感するだろう。 「Clean Coder」、「

                                                                              エンジニアとして今の自分を形成した本を5冊紹介する - パンダのプログラミングブログ
                                                                            • 脳に収まるコードの書き方を読んだ。面白かった。 - Mitsuyuki.Shiiba

                                                                              いただきましたー!わーい。脳に収めるぞー! @haradakiro @ryuzee pic.twitter.com/3Qd6EvPioU— SHIIBA Mitsuyuki (@bufferings) June 13, 2024 明日(2024年6月18日)発売! www.oreilly.co.jp どう書くのがいいんだろうなぁ? 複雑なコードと向き合うときは「あー、これはメモを取りながら読まないと迷子になるやつだ」ってなる。最初はわりとキレイに作られていたとしても、機能追加を重ねていくとだんだん読めなくなっていく。 だから「時間が経っても読みやすいコードってどう書くのがいいんだろうなぁ?何かヒントがあるかなぁ?」って思いながらこの本を開いた。先に書いておくと、ヒントはあった。 アウトサイドインのTDD 全然予想してなかったから、おー!と思ったのが、説明をTDDで進めていくってところ。好き

                                                                                脳に収まるコードの書き方を読んだ。面白かった。 - Mitsuyuki.Shiiba
                                                                              • MySQL のレプリケーションから10年間逃げてきた我々が学んだこと8選 - Cybozu Inside Out | サイボウズエンジニアのブログ

                                                                                こんにちは。クラウド運用チームで SRE をしている飯塚です。 今回は、MySQL のレプリケーション機能を約10年もの間ずっと使ってこなかった私たちが、レプリケーションを使った高可用性構成に移行するための取り組みの中で学んだことについて紹介します。 背景 巨大なテーブルへの primary key の付与 トランザクションサイズが大きい場合には tmpdir に注意 mysqldump で絵文字が消えていないか要チェック mysqldump が Error 1412: Table definition has changed... で失敗する mysqldump したデータのリストアが Duplicate entry 'xxx-yyy-PRIMARY-n_diff_pfx01' for key 'PRIMARY' で失敗することがある mysqldump したデータのリストア時のディスク

                                                                                  MySQL のレプリケーションから10年間逃げてきた我々が学んだこと8選 - Cybozu Inside Out | サイボウズエンジニアのブログ
                                                                                • 個人開発・スタートアップで採用すべき最強のアーキテクチャを考えた - Qiita

                                                                                  Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 結論 「アジリティ」「コスト最適化」「スモールな構成」「開発スピード」という観点でWebアプリケーションのアーキテクチャを考えてみました。 ServerlessFrameworkを使い倒す フロントエンドはS3 hosting + CloudFrontで。SSRもLambda@Edgeでできます データベースはRDSは使わずにDynamoDBで APIは基本的にGraphQL。必要に応じてRESTも簡単に追加できるよ。 補足(2022/04/12) 最近個人開発しているこちらのWebサービスはこのアーキテクチャに沿って作られています。

                                                                                    個人開発・スタートアップで採用すべき最強のアーキテクチャを考えた - Qiita