並び順

ブックマーク数

期間指定

  • から
  • まで

41 - 80 件 / 1495件

新着順 人気順

技術選定の検索結果41 - 80 件 / 1495件

  • レシピサービスのフロントエンドを Next.js と GraphQL のシステムに置き換えている話 - クックパッド開発者ブログ

    技術部の外村(@hokaccha)です。今回はクックパッドのウェブサイトのフロントエンドを Next.js などを使って作り直している話を書きます。 この記事で紹介する新システムは、スマートフォン向けのレシピページで確認することができます。もし興味があるかたはレシピページをスマートフォンのユーザーエージェントで開いて DevTools などで確認してみてください。 Next.js と GraphQL で動いているのがわかると思います。 ご存じの方も多いかもしれませんが、クックパッドのウェブサイトはモノリシックな Rails で作られていて、10年以上 Rails で開発を続けてきました。10 年以上同じシステムで開発を重ねれば当然レガシーな部分が大量に生まれてきますが、特にフロントエンドはその影響が顕著でした。 どこから使われているかわからない CSS が大量にある、JS のコードは昔なが

      レシピサービスのフロントエンドを Next.js と GraphQL のシステムに置き換えている話 - クックパッド開発者ブログ
    • スタートアップのためのマイクロサービス入門 | Amazon Web Services

      AWS Startup ブログ スタートアップのためのマイクロサービス入門 こんにちは、スタートアップ ソリューションアーキテクトの松田 (@mats16k) です。 以前「スタートアップのためのコンテナ入門 – Kubernetes 編」を出した際に記事内で、マイクロサービスやサービスメッシュにふれる機会がありました。今回は AWS でデベロッパーアドボケイトをしているトリ氏 (@toricls) にマイクロサービスについて記事を寄稿いただきました。 ※ 本記事は Software Design 2020年7月号 に掲載された「スタートアップのためのAWSテクノロジー講座 – マイクロサービスのあるべき姿と特徴を知る」からの転載、改修版です。 目次 マイクロサービスにはコンテナが必要なのか? サービスメッシュは本当に必要なのか? 「マイクロサービス」という言葉の功罪 マイクロサービスが必

        スタートアップのためのマイクロサービス入門 | Amazon Web Services
      • エンジニア採用面接での「質問項目」と「意図」を公開する - Qiita

        はじめに LITALICOの亀田です。エンジニアしてます。 Qiita: @kamesennin X(Twitter): ka_me_sen_nin エンジニア採用も大事な仕事の一つとしてやっています。 今まで1万人近いエンジニアの方々のご経験を見て、1,000人以上とお話してきました。 何を書いたか LITALICOでは新卒/第二新卒/中途に限らず(大体)通年でエンジニア採用を行っていて、採用面接の中で「どんな質問をどんな意図で行っているのか」を整理してみました。 ※実際には、弊社の面接で以下質問事項を「網羅的に一方的にしつこく聞いて見極める」などはございません。 ※「お互いが今一緒に働くことが良いと思えるか?」が採用プロセスの本質で、まずは弊社のことをお伝えさせて頂き、皆様に今後の環境に求めることや今までのご経験を伺い、「どういったポジションや環境が弊社に存在するか、そこはご希望に沿え

          エンジニア採用面接での「質問項目」と「意図」を公開する - Qiita
        • ドメイン駆動設計の正体

          はじめに "ドメイン駆動設計は当たり前のことを言っているだけ" "ドメイン駆動設計はただのオブジェクト指向プログラミング" "ドメイン駆動設計はより良いアーキテクチャだ" "軽量DDDはアンチパターンだ" このようなドメイン駆動設計に関する言及を聞いたことがあるでしょうか? ドメイン駆動設計に言及する記事や書籍は多くありますが、それぞれ着目する側面が異なったり色々なコンテキストから言及されています。 おそらくそれが原因でドメイン駆動設計が何であるかをぼやけさせ、正体のわかりにくい概念になっているように思えます。 そこで今回は色々な観点から整理し、ドメイン駆動設計とは何であるのか、その正体を考えていきます。 ドメイン駆動設計の基本的概念について ドメイン駆動設計はEric Evansが出版した「Domain-Driven Design」という書籍がルーツになっています。 ドメイン駆動設計を一

            ドメイン駆動設計の正体
          • 採用担当者から見る、実務未経験エンジニア市場で起こっていること|とし

            iCAREでVPoEをしている安田と申します。 弊社のエンジニア採用は、以前は実務経験のある方に対象を絞っていましたが、数ヶ月前から実務未経験エンジニアも積極的に採用するようになりました。 そして、実務未経験エンジニアを対象として、かなりの数の書類選考、カジュアル面談、面接をしてきました。その結果、多くのことがわかってきたのですが、今日はこの実務未経験エンジニア採用まわりの知見について、過去のツイートも参照しながら、まとめてみたいと思います。 採用担当者は「そっくりな」応募者情報の山の中で疲弊している自分は実務未経験エンジニアの採用活動について、折に触れてツイートしているのですが、このトピックで、はじめてある程度の注目を集めたのが、以下のツイートです。 今日も未経験エンジニアとカジュアル面談しましたが、最近思うことなのですが、未経験エンジニアが市場に溢れすぎて、かつ彼らの作るポートフォリオ

              採用担当者から見る、実務未経験エンジニア市場で起こっていること|とし
            • データエンジニアの私が機械学習・データサイエンスでオススメしたいスキルマップと本まとめ - 2020年版 - Lean Baseball

              要約すると, データサイエンス・機械学習周りでよく聞かれること&回答を言語化しました. 「データサイエンティストやりたい」「機械学習エンジニアになりたい」というキャリア志望を持つ方は多いと思います. 私の周りでも, 公私ともにそんな志望者の相談を聞いたり, (主にインターンの学生さんですが)一緒に仕事をしたりする機会もメッチャ多いです. 「ビジネスサイド強いマン」「サーバーサイドエンジニア」という視点からデータエンジニア兼データサイエンティストな自分が, そんな彼ら彼女らにオススメしている, データサイエンティストを目指すためのスキルマップ 各領域のスキルアップを実現するためにオススメしたい書籍 を紹介したいと思います. なお, 昨年も同様のエントリーを書いておりそのUpgrade版となります. shinyorke.hatenablog.com このエントリーの対象読者 データサイエンスに

                データエンジニアの私が機械学習・データサイエンスでオススメしたいスキルマップと本まとめ - 2020年版 - Lean Baseball
              • リードエンジニアが育休を6ヶ月取ることにした話 - 八発白中

                先月子供が産まれました。この記事は育休を取得しようと思った経緯を書き綴ったものです。 妻の記事はこちら。 meymao.hatenablog.com ことの始まり 2019年1月。妻は妊娠7ヶ月を迎えていた。 うちは夫婦共働きで二人共30代の中堅会社員。子供が産まれても働き続けたいという希望はある。けれど初めての子であるために働きながら子育てをするとはどのようなものかという実感が薄い。Web上には育児の大変さを吐露する書き込みはいくらでもあるが、それらは隣町の火事程度にしか思えず漠然とした不安しかなかった。 夫婦の両母親には出産予定日を伝えてある。産後に手伝いに来てくれないかという依頼を伝えるためである。しかし二人とも仕事をしているという都合や、遠方 (福岡) に住んでいるという事情もありなかなか思い切りのよい返事は得られない。 妻から育休の話をされたのはその頃だった。 ――育休を取る予定

                  リードエンジニアが育休を6ヶ月取ることにした話 - 八発白中
                • 内製化をすすめる知人へのアドバイス - Kengo's blog

                  ソフトウェアエンジニアとしての働き方を探求してきた経験と、駐在員として文化の狭間でうろちょろしてきた経験、OSSエンジニアとして多数の多様な人材と交流してきた経験をもとに、果敢にも内製化に挑戦する知人へのアドバイスを気持ちまとめます。 前提 主な利用技術にはJava(Spring Framework)やTypeScriptを想定 FaaSを始めとしたManaged Serviceは(いまのところ)積極採用しない構え Digital Transformationを推し進める一環としての内製化に、エンジニアリングの観点から挑む方を読み手として想定 内製化のターゲットは決まっているか心当たりがある状態 既存の開発チームはほぼ無い想定 1. チームビルディング 1.1. スーツとギークの対立を避ける 我々が若かった頃は"スーツ"と"ギーク"の対立を煽る風潮にありました。Rockstar Engin

                    内製化をすすめる知人へのアドバイス - Kengo's blog
                  • いまNext.jsで新規サービスを立ち上げるときの観点(Router・CSS・認証・監視など/2023年末)

                    免責事項 社内向けに展開するように雑にまとめました Next.jsの知見が深くない人がリードしてPoCを立ち上げなきゃいけなくなったが、社内的にはNext.jsを推奨しているみたいな場面を想定しています なので自信ないところも多いですが割と断言するように心がけて書いています PoCの立ち上げ想定なので、jest/Storybookなど内部品質面についてあまり深く書くことを避けています ほぼ自分の知識だけで書いており私見も多いですし、そもそも自分自身がトップクラスの知識や視座を有しているわけでもないので、まずは以下の話を理解はした上で、踏襲するかどうかは別途他記事やGitHub、公式ドキュメントなどを漁って判断することを推奨 App RouterかPages Routerか 2023年末現在まだApp Routerは技術記事が足りてきている印象ではないため、社内でノウハウを積極的に貯めていく

                      いまNext.jsで新規サービスを立ち上げるときの観点(Router・CSS・認証・監視など/2023年末)
                    • データ基盤にありがちな「何を使って作ればよいか?」という問いに対する処方箋を用意してみました. - Lean Baseball

                      ちょっと昔まではデータ基盤の管理人・アーキテクト, 現在は思いっきりクラウドアーキを扱うコンサルタントになったマンです. 私自身の経験・スキル・このブログに書いているコンテンツの関係で, 「データ基盤って何を使って作ればいいの?」的なHow(もしくはWhere)の相談. 「Googleのビッグクエリーってやつがいいと聞いたけど何ができるの?」的な個別のサービスに対するご相談. 「ぶっちゃけおいくらかかりますか💸」というHow much?な話. 有り難くもこのようなお話をよくお受けしています. が, (仕事以外の営みにおける)個人としては毎度同じ話をするのはまあまあ疲れるので, データ基盤にありがちな「何を使って作ればよいか?」という問いに対する処方箋 というテーマで, クラウド上でデータ基盤を構築する際のサービスの選び方 (データ基盤に限らず)クラウド料金の基本的な考え方 をGoogle

                        データ基盤にありがちな「何を使って作ればよいか?」という問いに対する処方箋を用意してみました. - Lean Baseball
                      • 副業エンジニアとして3年目に突入したのでコツをまとめる|Jumbo

                        屋号「jumbo」で開業しようと思いますので、よろしくお願いします — ジャンボ@レアジョブEM (@jumboOrNot) November 22, 2017 どうやら開業から2年たち→3年目に突入した。アプリエンジニアとしてだけでなく、デザイナー・インフラ・企画・・・色んなものを作ってきました。そんな折、こんなイベントに出ます!!! 「誰でもかんたん!」とか「余暇時間を使って効率的に!」という話は一切出てきません。泥臭くいろんなことを好きだからやってきた感じです。やってきたからわかる勘所・コツとそもそもの副業への考察について整理していこうと思います。 今までに受けたお仕事・関わった技術・【C向け】旅行AIアプリiOS開発・改善・グロース案件 iOS(MVC)/javascript/css/html ・【B向け】運送サービスiOS/Android開発・AR調査案件 iOS(MVC)/An

                          副業エンジニアとして3年目に突入したのでコツをまとめる|Jumbo
                        • Vue.js?React?フレームワーク選びの7つの選定基準、大規模ECサイトのフロント刷新プロジェクト - MonotaRO Tech Blog

                          こんにちは。モノタロウでフロントエンド寄りの開発をしている、陳です。 今回はモノタロウの新フロントエンドのメインフレームワーク選定についてお話しします。 選定結果から言うと、モノタロウ独自の7つの選定基準をもとに、Reactを選ぶことになりました。 背景 新フロントエンドプロジェクトの立ち上がり Vue.jsとReactの比較検討をしてみた 俯瞰して改めて選定基準を考えた 一般的な視点 モノタロウの社内事情 7つの選定基準 選定結果 技術選定を通して得た3つの学び 背景 まず、モノタロウの現フロントエンドについてざっくり説明します。 モノタロウは2002年から、PythonとJavaScriptでECサイトを開発してきました。 基本構成として、サーバサイドのPythonでHTMLを生成し、クライアントサイドのJavaScriptでカートインなどの動的処理を補完する形ですが、実はこの構成で違

                            Vue.js?React?フレームワーク選びの7つの選定基準、大規模ECサイトのフロント刷新プロジェクト - MonotaRO Tech Blog
                          • GraphQLの全体像とWebApp開発のこれから - Qiita

                            TL;DR GraphQLはクライアント側とサーバー側の双方の複雑化を解決するために利用されてる フロントエンドにとってGraphQLはHTTP上で動く信頼できる唯一のリソースとして振る舞う フロントエンドの状態管理のベストプラクティスとしてのApollo Client クライアントファーストなAPI, GraphQLはWeb APIのベストプラクティスになり得る クラシックアプリケーションを改修することなくGraphQLとモダンフロントエンドで今どきのアプリを作れる はじめに GraphQLは非常に良く出来たソフトウェア(の仕様)ですが、複数の側面を持つことからすぐに理解することが難しくまだ日本ではあまり受け入れられていない印象があります。GraphQLを端的に何と言われると "全てのフロントエンドのためのAPI BFF" なのですが、それだけで理解出来る人はなかなか居ないように思います

                              GraphQLの全体像とWebApp開発のこれから - Qiita
                            • 最近の業務での AWS サーバーレス開発を振り返ってみた | DevelopersIO

                              AWS Lambda を使用した Web アプリケーションの開発プロジェクトで、バックエンド・フロントエンド・インフラを一貫して開発をしてきました。 改めてどのように開発をしていたのか、使った技術スタックや各サービスをどのように活用したかを整理したいと思い記事にしました。今後サーバーレス開発を行う際の技術選定の参考にしていただければ幸いです。 前提 Web アプリケーションです。 管理画面用の内部 Web API、外部のサービスと連携するための外部 Web API があります。 処理としてはリソースの CRUD がメインです。 管理画面は SPA で、バックエンドの Web API にリクエストします。 開発メンバーは 4 人ほどで、フロントエンドエンジニア、バックエンドエンジニアといった区分けはしていませんでした。 機能ごとにメンバー全員がバックエンドからフロントエンドまでを一気通貫で実

                                最近の業務での AWS サーバーレス開発を振り返ってみた | DevelopersIO
                              • 自作RDBMSやろうぜ!

                                Skip to the content. 自作RDBMSやろうぜ! このサイトの目的 RDBMS(いわゆるリレーショナルデータベース)というものはプログラミング言語の処理系や、OSなどと同様に、世の中で広く使われているソフトウェアであるにも関わらず、いざ自作してみようと思うと日本語で記述されたサイトや書籍で、必要な情報・情報源がまとまったものがないことに気づきました そこで、叩き台として、本サイト管理人および数名のコミッタで開発している自作RDBMSである SamehadaDB が軌道に乗るまでの経験をベースに、自作RDBMSするための道筋をある程度整理して書き記してみました 各々の情報・情報源はあいかわらず多くが英語で記述されていますが、その点はご容赦下さい なお、本サイトは技術的な解説を提供するのではなく、適切と思われる情報・情報源をポイントするようなサイトとなることを想定しています

                                • Active Recordから考える次の10年を見据えた技術選定 / Architecture decision for the next 10 years at PIXTA

                                  September 15, 2021 @ iCARE Dev Meetup #25

                                    Active Recordから考える次の10年を見据えた技術選定 / Architecture decision for the next 10 years at PIXTA
                                  • ITエンジニアに刺さる「ポッドキャスト6選」

                                    はじめに 皆さんは「ポッドキャスト」を聞いていますか? ポッドキャストは個人でも配信できる音声メディアのことです。特定のサービスを指すわけではなく、音声ファイルをWebサーバーに置き、RSSフィードで更新情報を配信すればポッドキャストとして認識されます。ポッドキャストのアプリでは、そのRSSフィードのURLを登録すると随時更新された音声データを聴くことができる、という仕組みです。専用のアプリをインストールしておくと番組が更新された時点でプッシュ通知されるため、常に最新の音声データをチェックできます。 ポッドキャストという名前の通り、「iPod」時代の遺物といったイメージもあるかもしれません。しかし昨今、ポッドキャストが見直されているようです。大きな流れとしては、2018年に「Anchor」というポッドキャスト配信サービスが広まったことに起因すると思われます。録音から配信までを1つのサービス

                                      ITエンジニアに刺さる「ポッドキャスト6選」
                                    • ハードワークで人は成長するか - SaaSベンチャーで働くエンタープライズ部長のブログ

                                      「成長するためにはハードワークは不可欠」。こういう言説は常に世に出ています。そして、それを信じた真面目な若者が「成長」するためにハードワークをこなすという流れ。知っているだけでも10年以上同じサイクルがあるように思います。 思いつくだけでも、サイバーエージェント創業者の藤田晋氏が著書「渋谷ではたらく社長の告白」で月に440時間働いていたという話や、テスラ創業者のイーロンマスク氏が世界を変えるためには最低でも週80時間は働くべきだと主張があったり、成功者がハードワークを乗り越えた話があります。 一方で自分自身の経験を振り返ると、必ずしも労働時間の長さが個人の成長につながったとは思えません。この認知の違いはどこからくるのか。自分自身の経験を振り返ってみたいと思います。 自分自身の労働時間経験 ハードワークだが成長しなかった経験 ワークライフバランスを保ち、成長した経験 成長の定義を「今できない

                                        ハードワークで人は成長するか - SaaSベンチャーで働くエンタープライズ部長のブログ
                                      • 〔Udemy初夏のビッグセール開催中〕エンジニア組織をまとめる技術─マネージャー歴12年のEMが語るプロジェクト・プロダクト・ピープルマネジメントに必要なスキル - はてなニュース

                                        ソフトウェアエンジニアにとって、マネジメントの職に就くかどうかは大きな選択です。現在ではプレイヤーのままでスタッフエンジニアといった高い職位に進むキャリアもありますが、マネージャーとしてチームを率いてこそ達成できるビジネス上の成功もあるでしょう。 ひとくちにマネージャーといっても、マネジメントの対象によって要求されるスキルに幅があります。これまでUdemyの大きなセールで講座を紹介してきた当ニュースですが、今回はソフトウェア開発組織のマネジメントに必要となるスキルにフォーカスしました。 マネージャーという仕事と学びたいスキルを紹介してくれるのは、10年以上前からPM(プロジェクト・マネージャー)などに就いてチームを牽引し、現在はヘルステックベンチャーのカケハシでEM(エンジニアリング・マネージャー)を務める小田中育生(@dora_e_m)さんです。 また記事の後半では、マネジメントに関連し

                                          〔Udemy初夏のビッグセール開催中〕エンジニア組織をまとめる技術─マネージャー歴12年のEMが語るプロジェクト・プロダクト・ピープルマネジメントに必要なスキル - はてなニュース
                                        • 入社して1ヶ月で意思決定の速さに驚いた話 - ANDPAD Tech Blog

                                          2021/10から株式会社アンドパッドで働いているid:shiba_yu36です。現在はセキュリティチームで認証基盤に関するエンジニアリングをしています。 アンドパッドは2021/10/01時点で従業員数が539名となっています。入社する以前は「この人数になってくると自分が何か提案したとしても中々意思決定が進まずヤキモキするのではないだろうか」と不安に思っていました。 しかし入社してから自分が開発プロセスや人員配置に関して提案してみたところ、この心配は杞憂だったどころか、逆に思った以上の意思決定のスピードに驚いてしまいました。そこで今回は自分が入社してから1ヶ月ほどの間に実際に提案・採用した内容を書きながら、どの程度意思決定がスピーディだったか伝えられればと思います。 ミーティングではesaで同時編集しながら議事録をみんなで作るスタイルへ -> その日から開始 フルリモートでの円滑なコミュ

                                            入社して1ヶ月で意思決定の速さに驚いた話 - ANDPAD Tech Blog
                                          • バウンスしすぎて Amazon SES から追放された俺たちは Mailgun と SendGrid に国を作ることにした - ANDPAD Tech Blog

                                            これは何 どのように技術選定してますか。よく聞かれます。SREチーム 鈴木心之介 です。しかし説明が難しい。難しいですが説明の助けになってほしく思い、技術選定を文書化した DesignDoc から1枚を公開してみました。 DesignDoc とは、ある程度の大きさや複雑さがあり一言で説明の難しい技術選定について、文書化したものです。これを通じて、技術選定をどのように行うか組織内に広めようとする試みです。2021年1月頃から始めています。 題材は、メール配信の冗長化をRailsで実現した tech.andpad.co.jp を、インフラ視点から技術選定した DesignDoc です。このメール配信SaaSの選定は2019年末頃に実施したもので、DesignDoc の取り組みを始めていなかった頃でした。時が経ち、ソースコードやSaaSの構成からは意図を読むことが難しく「なんじゃこれ」って質問を

                                              バウンスしすぎて Amazon SES から追放された俺たちは Mailgun と SendGrid に国を作ることにした - ANDPAD Tech Blog
                                            • Webフロントエンドの開発効率を高く保つための考え方

                                              これまでいろんな現場でWebフロントエンド開発をしてきて、メンテナンスしやすく効率の高いWebフロントエンド開発をする上で重要になる考えが自分なりにまとまってきたので記事にしてみます。 Worse is Betterという考え方 自分が見てきた中でWebフロントエンドの開発効率が落ちてしまう一番の要因は、きれいで理論的には優れているアーキテクチャを構築しようとしてそれ自体がもたらす複雑性を支えきれないというパターンです。 少し前にフロントエンドにClean Architecture(以下CA、あの同心円の図を指すのは誤用に近いですがここではそれに乗ります)を導入する記事が流行ったと思いますがあんな感じです。ああいったクラスベースでDIが重要となる設計手法はサーバーサイドのJavaでSpringを使うのとは違ってReactがサポートしているものではないため、CAの実現自体に高い設計スキルが必

                                                Webフロントエンドの開発効率を高く保つための考え方
                                              • 2021年のウェブ標準とブラウザ | gihyo.jp

                                                2021年になりましたね。 矢倉眞隆(myakura)です。ウェブ標準やブラウザに興味のあるウェブ開発者です。gihyo.jpでは2009年に「Web標準とその周辺技術の学び方」という連載をしていました。 今回は昨年の泉水さんに代わり、2021年のウェブ標準やブラウザの動向を占おうと思います。2020年は世界もブラウザもそれなりに大きな出来事がありましたので、2020年の動きをまずおさえ、そのうえで2021年はどうなるのかを考えてみました。 W3Cのプロセス改訂でLiving Standardライクな仕様の改訂が増えていく W3Cは2020年9月に、新しいプロセス文書と特許ポリシーを公開しました。 新しい文書プロセスはW3Cの組織の定義や標準化の流れ、意思決定などについて定めた文書です。ここ数年は毎年更新されていますが、2020年はこれまでと比べて最大級とプレスリリースでもうたわれています

                                                  2021年のウェブ標準とブラウザ | gihyo.jp
                                                • スタートアップのためのコンテナ入門 – Kubernetes 編 | Amazon Web Services

                                                  AWS Startup ブログ スタートアップのためのコンテナ入門 – Kubernetes 編 こんにちは、スタートアップ ソリューションアーキテクトの松田 (@mats16k) です。 「スタートアップのためのコンテナ入門 – 導入編」「スタートアップためのコンテナ入門 – AWS Fargate 編」という記事を公開してきましたが、Kubernetes に興味があるスタートアップも多いのではないでしょうか。今回は Kubernetes にフォーカスしてお話しします。 なお Kubernetes 以前に、「そろそろコンテナやった方がいいか?」「なんとなく使い始めたけれどこれでいいのか?」「コンテナ自体は分かったけど、サービスでの利用に踏み切れていない」といった漠然とした課題感をお持ちの方は「スタートアップのためのコンテナ入門 – 導入編」から目を通して頂ければと思います。 目次 Kub

                                                    スタートアップのためのコンテナ入門 – Kubernetes 編 | Amazon Web Services
                                                  • なぜ default export を使うべきではないのか?

                                                    プロジェクトで使われている技術と ESModule の状況について UIT では、 SPA 開発のプロジェクトにおいて Vue.js と React が多く利用されており、既存の多くは Babel を利用した JavaScript で、新規のプロジェクトでは TypeScript を利用して開発が行われています。 FYI: 【LINE DEV DAY 2019 番外編】UIT Front-end Tooling Survey 2019 技術選定は勿論、プロジェクトにおける細かなコーディングルールについては、プロジェクトのコードオーナーに委ねられており、プロジェクトごとに裁量を持った意思決定を行っています。 その上で、私が携わるプロジェクトにおいては、 default export を可能な限り避けるように心がけています。 import 側の裁量で対象を自由に命名できてしまう 今回は「『Da

                                                      なぜ default export を使うべきではないのか?
                                                    • 積極的な技術選定と消極的な技術選定 - uhyo/blog

                                                      この記事は、筆者が技術選定について思うところをまとめた記事です。Twitterに同じ話を何回か書いているので、文章にまとまっていたほうがよいと思い用意しました。 やや過激な思想で愚痴も含んでいるので、共感いただけると嬉しいものの、みなさんを説得しようというつもりはありません。こいつはこういう考え方なんだなという心持ちでお読みください。 積極的な技術選定と消極的な技術選定ITエンジニアの方々の中には、技術選定をする立場の方も多いでしょう。技術選定にあたってはさまざまな事情を勘案しなければならない難しいもので、それだけに多くの人が技術選定に関する各々の考えを述べています。 筆者は、技術選定における意思決定のプロセスは、積極的な技術選定と消極的な技術選定の2種類があるのではないかと思っています。 積極的な技術選定は、選定される(あるいはされない)技術そのものが原因となる意思決定です。 一方、消極

                                                        積極的な技術選定と消極的な技術選定 - uhyo/blog
                                                      • 【2022年最新版】3,000人に聞いたWebエンジニアの業務委託単価相場について - Qiita

                                                        こんにちはISSUEを運営している寒河江です。 今回は情報の少ないWebエンジニアの業務委託単価相場について調べてみました。 現在の単価が適正単価なのか、次の単価レンジに行くにはどうすればいいか。ISSUEの実績をふんだんに使い記事を書いてみたのでご一読いただけると幸いです。 オリジナルの記事はこちら ISSUE DB 3,000人の実績データから相場を作成 現在(2022年11月)ではISSUE上に1,800人以上のユーザーデータと2,000以上の単価診断結果があります。またISSUEではクラウドソーシング形式で企業とマッチングすることにより、報酬を獲得することができます。その際の契約時給単価を参考に今回の相場作成の参考にしています。ISSUE上でもリアルタイムの単価相場を確認できますのでご参考ください。 Webエンジニアの業務委託単価相場 わかりやすいように各業務委託単価とその技術能力

                                                          【2022年最新版】3,000人に聞いたWebエンジニアの業務委託単価相場について - Qiita
                                                        • シリコンバレーと日本のエンジニアの能力の違い : 酒井潤公式ブログ

                                                          さて。皆さん、アメリカのエンジニアってとんでもなくすごい能力を持っているエンジニア集団だと思っている人も多いかと思いますが、んなことありません。 私も何度かYouTubeでお話ししてるので改めてブログで書いておこうと思います。まず、個々の能力の平均で見たら日本人エンジニアの方が圧倒的に優れてるし、よく働くし、日本人エンジニアの方がIQレベルと言いましょうか、仕事能力レベルと言いましょうか、日本人エンジニアの方が能力は高いと思います。 では、何でこんなに世界と差がついているのかというと、仕事で使ったりする技術選定の時点で世界とかけ離れ、日本のエンジニアは世界からどんどん遅れた技術を使って仕事をしてしまっているからですね。 日本では、Rubyが流行っておりますが、シリコンバレーではRubyは流行っておらず、PythonやらGo Langが流行って来たりしております。 Rubyは開発者の方が日本

                                                            シリコンバレーと日本のエンジニアの能力の違い : 酒井潤公式ブログ
                                                          • Vue・React・Angularのパフォーマンス比較検証 - ICS MEDIA

                                                            ウェブのフロントエンド開発に役立つライブラリとして、VueとReact、Angularがよく取り上げられます。これらのライブラリは、SPA(シングルページアプリケーション)の開発に役立つ多くの機能を持っています。 フレームワークを選定するには、「人気だから使う」という短絡的な理由で選択をするのは望ましくありません。設計思想や機能の種類、学習コストなどの観点で、プロダクト・プロジェクトチームへの適性を検討するのがセオリーです。幸いにも、それぞれを比較した記事がウェブに数多くあり、選定のヒントを簡単に得ることができます。 一方、機能面の比較ばかりが取り上げられ、性能面で紹介されている記事が少ないように見受けられます。記事『サービスにおいて速さこそが神である|深津 貴之』でも紹介されているように、昨今のウェブはスピードが求められる時代でもあり、ライブラリの性能評価の記事があってもよいのではないで

                                                              Vue・React・Angularのパフォーマンス比較検証 - ICS MEDIA
                                                            • 技術選定の審美眼(2023年版) / Understanding the Spiral of Technologies 2023 edition

                                                              Tech BASE Okinawa 2023 2023/09/23(土) https://codebase.connpass.com/event/285901/ https://techbaseokinawa.com/

                                                                技術選定の審美眼(2023年版) / Understanding the Spiral of Technologies 2023 edition
                                                              • 君は使い分けられるか?CSS/SVG/Canvasのビジュアル表現でできること・できないこと - ICS MEDIA

                                                                ブラウザーで新たにインタラクションやアニメーションを作る時、皆さんはどのようにして使う技術を選んでいますか? 使い慣れたライブラリに機能がないかドキュメントを調べてみたり、流行りのキーワードであればGoogle等で検索してみることも多いでしょう。一方、独自のビジュアル表現やアニメーションの場合、そもそも検索するキーワードがわからないことも多いのではないでしょうか? この記事では、webのビジュアル表現・アニメーションを実現するベースの技術であるCSS・SVG・Canvas(WebGL)の3つについて、それぞれのできること・できないこと(得意・不得意)を作例とともに紹介します。 クイズ:どうやって実現する? webでできるさまざまな表現 下の図はこの記事で紹介する9つのサンプルを並べてみたものです。すべてのサンプルはCSS・SVG・Canvas(WebGL)のいずれかを中心に実装されています

                                                                  君は使い分けられるか?CSS/SVG/Canvasのビジュアル表現でできること・できないこと - ICS MEDIA
                                                                • Firebaseの存在をフロントエンドから隠蔽するために

                                                                  「Firebase は安いし楽だしマジ最高」という一心で技術選定してしまったプロダクトが成功して見えてきた課題、割高なコスト・権限管理・カスタマイズ性、そして (特性やスキルセット的に)RDB 製品が適していたのに無理やり Firestore を採用したことによるデータ不整合。 その結果チーム内で Firebase を抜ける機運が高まるも、Firebase べっとりなアプリケーションすぎて移行しづらいといった問題に出会うかもしれません。 そのような場合に備え、Firebase の存在を隠蔽して開発することに挑戦してみましょう。 注意: Firebase を剥がしているときに「俺、次は絶対そうするわ」と感じたものを書いているだけであり、まだ実際にはこのパターンでプロダクション導入していません。 あくまで個人開発で試してみていけそうと思ったので、提案しますという体です。 また Firebase

                                                                    Firebaseの存在をフロントエンドから隠蔽するために
                                                                  • Reactを使ってプロダクト開発している開発者だけでなく、マネージャにも読んでほしい「Fluent React」 - ROUTE06 Tech Blog

                                                                    チームでReactを使って開発していると、コードレビューをする際に、「この書き方はしない方がいいが、それを説明するには800文字くらい必要。図も描きたい。でもそれらを準備する時間はない。」ということが度々ありました。 また、フレームワークやライブラリの技術選定をする際、マネージャに「どうして技術選定が必要なのか」を説明する必要がありました。ROUTE06のマネージャはエンジニアリングへの造詣が深い方が多いので、対立構造になることはありませんが、説明するためには1000文字くらい必要で、やはり図も描きたい。時間はない。と同じ気持ちになることがありました。 参考情報として紹介できる情報がないか探してみると、「とりあえずこうすればOK」というベストプラクティスについては検索エンジンやSNSですぐに見つかります。ただ、どうしてその方法がベストプラクティスなのか、仕組みや原理を説明している情報は少な

                                                                      Reactを使ってプロダクト開発している開発者だけでなく、マネージャにも読んでほしい「Fluent React」 - ROUTE06 Tech Blog
                                                                    • 組織を本当に動かしたいなら、やりようはいくらでもある 及川卓也氏が語る「ソフトウェア・ファースト」で変わる日本の企業

                                                                      ITエンジニアの課題解決能力を社会にインストールするために、2020年2月に発足したコミュニティ、ハッカーライフラボ。第4回目のオンラインイベントは、2019年10月に刊行された『ソフトウェア・ファースト』の著者である及川卓也氏が「ソフトウェア・ファースト」の考え方、日本企業の課題などについて紹介します。4回目の最後は、どうすれば組織は変わるのか、大企業を経験してきた及川氏ならではの理論に注目です。 組織を本当に動かそうと思ったならば、いろいろやりようもある 岩切晃子氏(以下、岩切):今質問でね、「やっぱりトップはソフトウェアの重要性を認識してるんだけど、ミドルマネージャーが変化の障害になることが多いように感じる」と。「及川さんがミドルマネージャー層にメッセージを伝えるとしたら、どんなものを伝えますか」と書いてくれた人がいたんですけど、やっぱりこれも辞める気になって「変えるのか?」というの

                                                                        組織を本当に動かしたいなら、やりようはいくらでもある 及川卓也氏が語る「ソフトウェア・ファースト」で変わる日本の企業
                                                                      • 「私の手順」というサービスを作りました

                                                                        手順共有サービス「私の手順」を作りました。 本記事では背景から開発の流れ、技術選定などを記載していきます。 背景 ほとんどの行動には手順があるかと思います。最初にこれをやって、次にあれをやって、最後にこれをやる。 テキストコミュニケーションで以下のような説明をしたことがある方は多いのではないでしょうか。 仕事に限らず、料理はもちろん、サウナのルーティンも1つの手順です。 そんな手順をいい感じに共有できないかと思い、本サービスを作りました。 以下、詳細について説明していきます。 デザイン Figmaを使ってデザインを作っていきました。 コードをいきなり書き始めてもよいのですが、最終形を決めてから進めていきたいと思い、作りました。 技術選定 言語: TypeScript フロントエンド: Next.js バックエンド: Next.jsのAPI Routes インフラ: Cloud Run DB

                                                                          「私の手順」というサービスを作りました
                                                                        • ホテルの客室検索APIのアーキテクチャ設計時に考えたこと

                                                                          作ったもののイメージ ホテルの客室検索APIとは、チェックイン日やその他の条件を入力として受け取り、マッチするホテルの客室を返すものです。以下の画像はExpediaのものですが、赤枠で囲っている部分(他にもたくさんある)が入力になります。2022年4月頃に無事リリースされました。 この検索APIを構築を任された際に、何を考えて設計していったのかを以下に示していきます。 顧客からの要望 顧客の会社は当時エンジニアがおらず(やりとりしている社長は元エンジニアだが)、これまでも私と仕事をしたことがあったので依頼が来ました。顧客と密にコミュニケーションを取りわかったのは、以下のような要望でした。 このAPIは自社サービスとして第3者(要契約)に使ってもらえるようにしたい 完全に一般公開ではなくちゃんと契約を結ばないと利用できないようなもの 検索条件を柔軟に、かつ使いやすい感じで指定できるようにした

                                                                            ホテルの客室検索APIのアーキテクチャ設計時に考えたこと
                                                                          • Modern Data Stack / モダンデータスタックというトレンドについて - satoshihirose.log

                                                                            はじめに Modern Data Stack ? Modern Data Stack の特徴やメリット、関連するトレンド データインフラのクラウドサービス化 / Data infrastructure as a service データ連携サービスの発展 ELT! ELT! ELT! Reverse ETL テンプレート化された SQL and YAML などによるデータの管理 セマンティックレイヤーの凋落と Headless BI 計算フレームワーク (Computation Frameworks) 分析プロセスの民主化、データガバナンスとデータメッシュの試み プロダクト組み込み用データサービス リアルタイム Analytics Engineer の登場 各社ファウンダーが考える Modern Data Stack さいごに Further Readings はじめに Modern Dat

                                                                              Modern Data Stack / モダンデータスタックというトレンドについて - satoshihirose.log
                                                                            • PayPayがAWSを使い続ける理由 日本No.1のQR決済サービスを支えるインフラ構成

                                                                              ZOZO×一休×PayPay AWS Nightは、2020年7月22日に開催されたZOZOテクノロジーズ・一休・PayPayの3社による合同イベントです。各社それぞれAWSの活用事例を紹介します。PayPay株式会社プラットフォームチームの西中氏がPayPayのインフラの概要について話しました(記事内の情報はイベント開催時点のもの)。 日本のNo.1 QRコード決済サービス 西中智樹氏(以下、西中):「PayPayでのAWS活用事例について」と題して、PayPay Platformチーム・西中が発表いたします。 簡単に自己紹介します。西中智樹と申します。2018年12月よりPayPayで仕事をしていまして、現在、AWSなどのPayPayのインフラを所管するPlatformのチームに所属しています。好きなAWSサービスはEKSです。 本日のセッションのアジェンダになります。この順番でお話を

                                                                                PayPayがAWSを使い続ける理由 日本No.1のQR決済サービスを支えるインフラ構成
                                                                              • 注目のITサービスを支えるアーキテクチャ特集 技術選定のポイントと今後の展望 - Findy Tools

                                                                                公開日 2024/05/27更新日 2024/05/27注目のITサービスを支えるアーキテクチャ特集 技術選定のポイントと今後の展望 現代のITサービスは、ユーザーに高品質で安定した体験を提供するために、より効率的で柔軟な技術選定が不可欠です。 本特集では、注目企業のシステムアーキテクチャ設計に携わるエンジニアの方々より、それぞれの技術選定における工夫と、未来を見据えた展望についてご寄稿いただいています。 各企業がどのように課題を乗り越え、開発生産性や品質を向上させるためにどのようなアプローチを採用しているのか ー この記事を通じて、実際の現場で活用される最先端の技術や戦略を学び、皆さんのプロジェクトに役立つ洞察を得ていただければ幸いです。 ※ご紹介はサービス名のアルファベット順となっております airCloset - 株式会社エアークローゼット エアークローゼットは日本初・国内最大級、女

                                                                                  注目のITサービスを支えるアーキテクチャ特集 技術選定のポイントと今後の展望 - Findy Tools
                                                                                • GitLab.comはどうやって6TBのPostgreSQLを9.6から11にたった2時間で移行したのか? | DevelopersIO

                                                                                  GitレポジトリのホスティングサービスGitLab.comは2020年の5月に 6TB あるPostgreSQL 9.6クラスターをたった2時間のメンテウィンドウ中に11.7へアップグレードしました。 GitLab.comのエンジニアブログに、このPostgreSQLのメジャーアップグレードプロジェクトが解説されていたので、かんたんにご紹介します。 How we upgraded PostgreSQL at GitLab.com | GitLab ポイント PostgreSQL 9.6から 11.7 へのメジャーアップグレード 2時間のメンテナンスウィンドウ内でアップグレード完了 データサイズは6TB DBクラスターは GCP 上の 12台の VM インスタンスで構成 クラスターはアップグレード用の8台とリカバリー用の4台に分割 pg_upgrade & ハードリンクでインプレースアップグ

                                                                                    GitLab.comはどうやって6TBのPostgreSQLを9.6から11にたった2時間で移行したのか? | DevelopersIO