2024年度リクルート エンジニアコース新人研修の講義資料です
![現代的システム開発概論 2024](https://cdn-ak-scissors.b.st-hatena.com/image/square/f45dc7f371d4bf53ccbbc9225545a737b4f607fd/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2Fc0fd5ee53ef34b488d8c251afa0d00a7%2Fslide_0.jpg%3F31298807)
こんにちは!LayerXのバクラク事業で機械学習・データ周りを担当しております、たかぎわ (@shun_tak) と申します。 みなさま、ChatGPTの登場に衝撃を受け、これを日々の生活やビジネスに活用されていることかと思います。わたしも社内でChatGPT活用の勉強会を開催したところ、大変大きな反響をいただきました。 tech.layerx.co.jp ChatGPTの登場以来、AIを前提としたユーザー体験の構築、すなわちAI-UXの実現を目指すことがLayerX社内の共通認識になりました。LayerXは、プロダクトだけでなくあらゆるビジネスプロセスにおいて、ユーザー体験をAIを前提に再構築するAI Transformation (AX) を推進することで、生産性革命を実現しようとしています。 comemo.nikkei.com AI-UXやAXの実現を通じて、仕事や暮らしの中にある摩
概要 気象庁の気象情報を取得し、加工した上でBigqueryに登録するデータパイプラインです。 上記構成図の内、赤枠内のサービスをTerraformで定義しています。 また、今回のデータ基盤定義をしたTerraformを上記Gitリポジトリにて公開しています。 実装した背景 現在無職なので、転職用のポートフォリオとして作成しました。 また、GCP・Terraform(あとGit)も触ったことがなかったので、技術スキルを高めることも目的の一つです。 各工程の説明 一連の流れは、下記のとおりです。 ①データ取得 ②データ加工・投入 取得データは、最高気温・最低気温・日降水量の3つです。 これらはLooker Studioで日ごとの遷移を可視化することを想定して選定しました。 記事公開時点ではLooker Studioのダッシュボードを作成していないので、折角なら実装しようかとも思っています。
本記事ではデータパイプラインにおいてべき等性(Idempotent)を保つための方法について、パターン分けして整理してみたいと思います。 1. はじめに データパイプラインでは べき等性(Idempotent)と言われる「ある操作を何度実施しても同じ結果になる」という条件を満たすことが好ましいと言われています。 ただし、べき等性を満たすためには具体的にどうすれば良いかというのは結構難しいので、自分の頭の整理も兼ねてパターンに分けて考えてみたいと思います。 単純化のために操作を1回実行した結果と2回実行した場合を考えたいと思います。 同じ状態(上図の「初期状態」)から操作を1回実行した場合と2回実行した場合の結果の状態(それぞれ「状態X」「状態Y」)が同じであれば、べき等性を実現できていると本記事では考えます。 1回実行時の操作 (A) と2回実行した場合の2回目の操作 (C) は、正しい入
ちなみに jq がインストールされている必要はありません。 jnv does not require users to install jq on their system, because it utilizes j9 Rust bindings. https://github.com/ynqa/jnv#installation JSON navigator and interactive filter leveraging jq Usage: jnv [OPTIONS] [INPUT] Examples: - Read from a file: jnv data.json - Read from standard input: cat data.json | jnv Arguments: [INPUT] Optional path to a JSON file. If not prov
はじめに いつも聞いているポッドキャスト番組で、エンジニア転職について生々しくリアルな話が聞けたので、紹介します。今の自分がやっている仕事が市場価値を上げられているのか? と日々の業務を振り返るきっかけになりました。詳しく知りたい方は是非、聞いてみて下さい。 転職の前提 かいちさん(転職した人)の紹介 情報系の大学院卒 中堅のバックエンド・エンジニア(30代) 社会人7年目 主に使っている言語: python, PHP アジャイル開発ができることを転職の軸に据えた 転職して感じたこと ① 30代は中堅の仕事を求められる → リーダー的立場が求められる ② 若い時の業務経験が転職の際に活きてくる → 20代はとにかく挑戦する回数を増やそう ③ 転職はどのタイミングでやってくるかわからない → 常に職務経歴書を更新し続けよう 結論 重要なポイント ・チームで開発した経験があるか? ・AWSなど
こんにちは。SRE部の巣立(@ksudate)です。 我々のチームでは、AWS上で多数のマイクロサービスを構築・運用しています。マイクロサービスが増えるにつれて、CI/CDの長期化やリリース手法の分散など様々な課題に直面しました。 本記事では、それらの課題をどのように解決したのかを紹介します。 目次 目次 はじめに CI/CDのこれまで Release PRによるリリース CI/CD実行時間の長期化 マイクロサービスごとのリリースが難しい リリーサーの制限ができない ドメイン単位の並行リリース リリース手法が分散する ブランチ間の同期が必要 パイプラインの増加 CI/CD実行時間の長期化 リリーサーを制限できない CI/CDの刷新 高速かつシンプルなCIパイプライン 変更差分を利用したCIパイプラインの実行 承認機能付きのCDパイプライン GitHub Environmentsによるリリー
はじめに DROBE の課題と GPT-4-Vision-Preview を試すモチベーション ケーススタディ 入力するデータ 推論周辺部分のコード プロンプト 実験結果 おわりに 参考文献 はじめに OpenAIが Dev Day で発表したGPT-4-Vision-Previewは、画像処理と自然言語処理を組み合わせた最先端の技術です。 このモデルは、画像を理解し、その内容に基づいてテキスト情報を生成する能力を持っています。例えば、写真やイラストから物体を識別し、それに関連する説明や情報をテキストとして提供できます。この技術は、画像とテキストの間のギャップを橋渡しするものであり、多様な応用が可能です。 DROBEは、多様なファッション商品を取り扱うECサイトを運営しています。我々の挑戦の一つは、膨大な数の商品画像と説明文から、正確で有用なタグを抽出し、整理して保存しておく事です。このプ
コアテクノロジーグループの山田です。 先日、新しいSQLフォーマッターであるuroboroSQL-fmtをリリースしました 🎉 このツールは弊社が公開しているPostgreSQL向けのSQLコーディング規約に基づき、SQL文をフォーマットするツールです。 弊社でのSQLフォーマッター開発の取り組み元々弊社ではuroboroSQL Formatter(以下uroboroSQL Formatterを旧版、uroboroSQL-fmtを新版と呼ぶ)というSQLフォーマッターを公開していました。旧版は 字句解析して得られたトークンを基にフォーマットするという設計になっていたため、SELECT句のエイリアス補完といった文法を考慮する必要のある機能の追加が困難Pythonで書かれておりVSCodeの拡張機能として動作させるのが難しいという課題を抱えており、それを解消するため新たなSQLフォーマッター
Engineering Manager という仕事をしていると、自己効力感が低下する瞬間がけっこうあると感じる。(多分 Engineering に限らない Manager 一般の話も多いと思うけど、ここではその考察はしない) 仕事において自己効力感が高まる状態というのは、たいてい、自分が何か努力して、それによって目に見える成果が出ているときに生まれるのではないかと思う。ところが、Engineering Manager の仕事というのは基本的に、自分以外のみんなが成果を出せている状態をつくることで、それにより絶妙なズレが生まれると感じる。 Engineering Manager の仕事を例にあげると、個々人のサポートをしたり、チームがうまくいくサポートをしたり、チーム間のコミュニケーションラインを整えたり、チームのはざまに落ちてるタスクを拾ったり、必要な人を採用したり、ビジネスや経営から求め
Typograms (short for typographic diagrams) is a lightweight image format (text/typogram) useful for defining simple diagrams in technical documentation, originally developed here. See it in action here: https://google.github.io/typograms/ Like markdown, typograms is heavily inspired by pre-existing conventions found in ASCII diagrams. A small set of primitives and rules to connect them is defined,
「住所の揺らぎ程度のことにAIを使いたいだとかデジタル音痴」だの「住所の正規化なんてExcelで2時間あれば作れそう」だの、たいへんフットワークの軽やかな言説の数々に、位置情報界隈のみならず住所の正規化や名寄せに少しでも関わったことのあるエンジニアが総立ちでマサカリを投げていたのも記憶に新しい今日この頃ですが(2023年6月6日)、この手の騒動は周期的に起こってる印象です。 ということはつまり いつまで経っても解消されない、解決が困難な課題である その困難さが界隈以外に共有されていない であるわけで、その都度Twitterにトリビアが投下されてはTLが賑わい華やかではありますが、そろそろ自分の整理としてもどれだけ日本の住所システムがカオスで、その計算機的な処理がいかに困難かをメモっておこうかと思いました。 なおこの件については既にQiitaにGeoloniaの宮内さんが鼻血の出そうな良エン
(※本記事は去年の弊社のQiita アドベントカレンダーに投稿したものをリライトしたものになります。反響が嬉しすぎたので自社ブログにも載せて擦ります。) はじめに リンクアンドモチベーションで、エンジニアをしています、宮田と申します。 自分は外部の技術顧問の方に月に一回のペースで1on1する機会をもらっています。 今回はその中で話したことを共有します。 公開するにあたって分かりやすさを重視して少し脚色していますが、大筋はリアルなものです。 見積もりに対する課題感 ぼく「約束は開発を遅らせるという記事を最近読んだのですが、その通りだと思ったのですよね。」 さて、チームの外に対して約束するために「この機能1ヶ月で出せるよね?」とプロダクトの人やマネージャーに聞かれたら。これは返事に悩む。「ラフで構わないから」って言われて伝えたら、それがコミットメントになってしまったのを過去に何度も見たことがあ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く