GraphQLのはじめかた - Write and Run
トレンドに乗るためにはトレンドを自分の方に捻じ曲げるのが一番いい、ということで、Twitter で日夜 GraphQL, GraphQL と騒いでいる日々であります。 GraphQL の話、スライド上げました https://t.co/hTUvA9Fajt ハンズオンに良さそうなコードや解説記事などもそのうち公開します #tng23— KOBA789 (@KOBA789) 2016年10月22日 先日、tng23 で「GraphQLの話」をしてきました。解説記事とか書くみたいなことをノリで口走ったので、これは伏線回収です。 GraphQL は公式のドキュメントが充実しています。とはいえ、全部英語なので日本にはあまりリーチしてないですね。みなさん英語読んで……。 母語でない言語で書かれた文章を自分のペースで読みながら、そこに書かれている新しい概念を獲得するってのは結構な重労働です。そこで、お
Debeziumで変更データキャプチャを学ぼう #jjug_ccc
JJUG CCC 2021 Fallの 「15:00 ~ 15:50 Debeziumで変更データキャプチャを学ぼう」の資料です
入門 統計的因果推論 | MoT Lab (GO Inc. Engineering Blog)
AI技術開発部分析グループマネージャーの島田です。分析グループは、タクシーアプリ「GO」におけるデータドリブンなビジネス意思決定を行うために、様々なユーザ分析、乗務員分析を行っています。本記事では、分析グループ内で開催した統計的因果推論の勉強会について紹介したいと思います。 勉強会のモチベーション「データドリブンなビジネス意思決定」という文脈においては、機械学習モデルの精度を向上させる能力はあまり重要ではありません。どちらかといえば、物事をどうモデリングすべきか不明なケースで、状況を整理して課題を明確にし、適切に定式化したり、データ分析に落とし込む能力が重要で、その一助となるであろう「統計的因果推論」をチームのスキルとして身につけようということで勉強会を開始しました。つぎのような場面で統計的因果推論が活躍してくれることを期待しています。 A/Bテストでは効果なしとなったが、あるサブグループ
Unity Learnチュートリアル「ML-Agents：ハチドリ」で強化学習を始めよう｜①Flowerクラスの実装
ML-Agents：ハチドリ Unityには、強化学習を構築するためのフレームワークであるML-Agentsがあります。また、Unityの公式なチュートリアル&コースウェアを提供するUnity Learnにおいて、このML-Agentsのチュートリアルを提供する「ML-Agents：ハチドリ」があります。 「ML-Agents：ハチドリ」は、Humming bird (ハチドリ)が蜜を吸うゲームの中で、ハチドリが効率的に蜜を吸うことをゴールとして、強化学習を用いてハチドリをトレーニングするための学習コンテンツです。 この記事は、私が「ML-Agents：ハチドリ」を学習した際に、重要だと考えた事項を備忘用にメモするためのものです。 プロジェクト:①Flower.cs 本プロジェクトでは、個々の花の機能のスクリプトを作成します。ハチドリはこの花と直接やりとりをするので、適切な反応をする必要が
チームの開発生産性を高めるための心がけ | フューチャー技術ブログ
はじめにTechnology Innovation Group 辻です。 秋のブログ週間の 4 本目です。 最近はアーキテクトとしてチームにジョインすることも増えてきました。より素早く、継続的にビジネス上の価値を提供するためにチームの開発生産性は重要です。チームの生産性を高めるために私が心がけているいくつかの内容を紹介します。 心がけ 開発上のボトルネックを取り除く コードべースの品質を保つ コードを読みやすくする 素早くレビューに取り組む、質問/相談にレスポンスする 体裁の一貫性を保つ 1.開発上のボトルネックを取り除く開発上のボトルネックになっているポイントを発見し、原因を特定し、対応する、ということです。一例をあげると以下のようなことです。 コードの責務がはっきりしておらず、改修時の影響が大きくなる。意図しない挙動になる そもそもテストコードがなく、機能仕様が満たされているのかわから
クラウドとオンプレ / on the Cloud or Premises
pixiv SPRING BOOTCAMP 2015 講義資料
答えやすい質問、答えづらい質問
こんにちは。株式会社プラハCEOの松原です 先輩に質問したら「もうちょっと聞きたいことをまとめてくれない？」と怒られた StackOverflowに質問したけど誰も答えてくれずしばらくして通知が届いたらdownvoteだった 質問しても曖昧な回答しか返ってこなくて、お互い気まずい空気が流れる そもそも技術系の質問するのが苦手 どれか1つでも該当する方にはこの記事が役に立つかもしれません。ちなみに僕は新人時代にフルコンボだドン 最近ではプラハチャレンジのメンターとして質問を受ける側に立つことが多いのですが、「これは答えやすい」と思う質問もあれば「ちょっと答えづらい...」と思う質問もあります。かれこれメンターとして1000個近くの質問を受けて来たので、せっかくの経験を生かしてより良い質問に繋がるチェックシートを作ってみました。 相手に十分な情報を与えているか 「プログラマが知るべき97のこと
エンジニアの思考を停止させる不安係数∞の罠 | F's Garage
エンジニアの職能の一つに「重箱の隅のような問題に気がつくスキル」というのがあります。このスキルのおかげで、見積もり精度はあがり、将来に起きうるリスクを防ぐことができるというメリットがある反面、不確実性のあることへの恐怖、100%の確信がないことから自分の発言に自信が持てない、決断できないなどのデメリットをもたらすことがあります。 これを総称して「不安係数∞」という言葉を、はるか昔から使っていましたが、それに言及した自分の昔のブログの記事でいいものが見つからなくなってしまったので、もう一度書いておきたいと思います。 我々は日常、たくさんのリスク要素に気が付きます。Webサービスならセキュリティホール、ネットワーク設定の不備、技術的負債に基づくスケーラビリティ問題などなどが代表例ですし、受託ならお客様の対応が信じられない、納期がころころ変わる恐怖、仕様が難しすぎて実現できないのでは？などなど。
コードを読む時に意識していること - エニグモ開発者ブログ
こんにちは、サーバーサイドエンジニア の 橋本 です。 この記事は Enigmo Advent Calendar 2022 の 14 日目の記事です。 はじめに エンジニアとして仕事をしているとコードを読むことが多いと思います。例えば、仕様調査、CSからのお問合せ対応、レビュー対応などがあると思います。 今年を振り返るとコードを書く以上に読むことが多く、コードをより正確かつ速く読むにはどうすればいいかを考えることが多くありました。 ということで、この記事では私個人がコードを読む時に意識していることを紹介していこうと思います。 いきなりコードは読まない 1つ目はいきなりコードは読まないことです。業務で使われているコードの量は1つの機能でもとても多いです。いきなり読み始めるととても時間がかかったり、迷子になってしまうかもしれません。なのでまずはシステム全体を把握してインプットとアウトプットが何
個人的コードを早く書くための覚書
なんとなく書いてみた。というか書いてみると作業方針ぽくなったし、チケットの捌き方みたいになった。 IDEを駆使して自分の作業をoptimizeする ショートカットキーとコード補完などは覚える。 操作を行う頻度の多いもの、処理に時間がかかっているものを最適化するのが目的。 IDE自体の処理スピードがネックになる場合はチューニングすること。 タイピングからのレスポンシビリティが下がる、 ビルド・デプロイにコードベースの量から想定される以上に時間がかかる。 などと行った場合はなんらかのゾンビプロセスなりが存在しているかもしれない。 なるべくチケット化する これはプロジェクト方針と合致するかということも大いにあるけど、 基本的にチケットは細かくあったほうが良いと考える。 明らかに作業に対してチケットのタイトルが合致していない場合、 チケットにない作業をしている場合などが該当する。 タスクを細かく切
トラブルを解決できる人になろう - そーだいなるらくがき帳
そんな想いを込めてこの特集記事を書きました。 自分が担当したところ バックエンドとデータベースの2つの章を担当しました。 バックエンドもデータベースもトラブルはISUCON9を題材にWebアプリケーションのトラブル、特にパフォーマンスチューニングについて話を書いています。 この本に書いてあることは明日から使える実践的な内容になったと感じています。 これはISUCONの問題がとても実践的で現場に即した内容だからこそ。 だからISUCONを題材にすることを快諾していただいた @941 さん @catatsuy さんは感謝しています。 本当にありがとうございます！！！ この本を読めば予選抜け出来るとは言わないけど何も出来なかった！ってことは無いんじゃないかなといえるくらいのHowは書いたつもりです。 これをきっかけに是非、ISUCON9の予選問題もチャレンジしてみてください。 isucon.ne
ドキュメントはなぜ書くべきなのか - inductor's blog
はじめに 最近、仕事・プライベート問わず技術的な内容に関して人に教える機会をいただくようになりました。 僕は前のチームの影響で文章を書くことの重要性を意識するようになりましたが、最近はどうしても面倒で後回しにしがちなドキュメントをどうやったら書けるようになるかということについても考えています。 なぜドキュメントは大切なのか ドキュメントの重要性は、個人的な感覚ではテストコードに近いと思っています。 特にプロジェクト初期や設計の段階では、「なぜその技術を選んだのか」や、「なぜこの方針にしたのか」といったことを議論したり、複数の選択肢から技術を選定するためにさまざまな比較検討を行います。 このとき、決めたことはコードとして残りますが、「検討したが採用しなかったアイデア」についてはコード内ではなかったものにされ、見えなくなってしまいます。正確に言うと、コードとしては不要なものはいらないのでそれは
ライブラリやフレームワークを早く使いこなす方法
このブログでは自分なりに得た個人開発についての方法論をいろいろと紹介している。全工程を自分でやらなければならない個人開発は、自身の能力を底上げするのに最高の方法でもある。その過程で、アプリをよりよいものにするために新しいライブラリやフレームワークの導入を検討する事も多々あるだろう。 コードを書く時間というのは実は意外に短くて、基本的に作業時間の40%以上は勉強や調べ物に費やされる。以前、WakaTimeというコーディング時間を計測するサービスで計ってみたら、週に20時間程度しかやってなかった。となると、ドキュメントを読む時間やそれを理解する時間は、場合によってはボトルネックになりうるという事だ。言い換えると、ライブラリやフレームワークの使い方を素早く把握できれば、仕事の速さが大きく向上する。 本稿では、技術の使い方を素早く把握して手早く自身のプロダクトに適用するための考え方をシェアしたい。
朝活として最高の書籍である『システム運用アンチパターン』を読んだので読書感想文 - じゃあ、おうちで学べる
はじめに SREという信頼性の観点からのプラクティスや運用技術を実施出来るためのプロダクトの開発をしている身からすると『システム運用アンチパターン』はまさに様々な課題がわかりやすく言語化されており素晴らしい書籍で、熟練の運用エンジニアとお話ができるような経験ができました。このエントリーは『システム運用アンチパターン』を読んでみた中での感想文となります。 www.oreilly.co.jp 『システム運用アンチパターン』目次 1章 DevOpsを構成するもの 1.1 DevOpsとは？ 1.2 DevOpsの柱となるCAMS 1.3 また別のDevOps本？ 1.4 本章のまとめ 2章 パターナリスト症候群 2.1 安全装置ではなく障壁を作ってしまう 2.2 ゲートキーパーの導入 2.3 ゲートキーパーの分析 2.4 自動化によるパターナリスト症候群の解消 2.5 承認の目的を把握する 2.
企業のデータ分析は4つのアクションで成り立っているという話 - Data Analystのメモ帳
この記事ではデータ活用が進んでいる企業で実際に見かけたデータ活用方法を4つのアクションにわけて説明します。 やや抽象的に書いていますが、多くの企業では共通して下記に説明するようなことを実施しています。 どこの会社も具体的な部分は異なりますが考え方は同じです。 やっていることはシンプルで単純だということを感じ取ってもらえると嬉しいです。 データ活用の4つのアクション データを用いた経営やサービス開発では大きく下記の4つのアクションに基づいて行われます。 それぞれが完全に独立していることはなく組み合わせて実行されることもあります。 このなかで1~3に対して4番の監視は少し趣が違うアクションですが、まずは説明のために併記します。 調査 予測 検証 監視 調査 データからユーザやマーケットなどを調べることです。 たとえば「機能Aを使っていないユーザ属性の調査」とか「課金までに離脱しているプロセスの
技術書典13でBigQueryデータ基盤本を頒布する予定です - 本日も乙
2022/09/10 訂正 以下の記事で正式告知させていただきました。 https://blog.jicoman.info/2022/09/announcement-techbook-fest-bigqueryblog.jicoman.info 先週は夏季休暇をいただいていましたが、技術書典13に向けた新刊の執筆で終わってしまいました・・・。今までサボっていた自分が悪いのですが。まだまだ執筆が終わっていませんが、ようやく終わりが見えてきたので告知します！ どんな本？ タイトルは「WebエンジニアのためのBigQueryデータ基盤入門」（仮）です。データエンジニアリング未経験な私がここ1年ぐらいBigQueryでデータ基盤構築していたので、その知見などを同人誌にしてみました。 データ基盤と聞くと、データエンジニアやデータサイエンティスト、機械学習エンジニア、会社によってはITインフラエンジニ
Google Cloud Storage（GCS）でうっかり30万以上溶かした話 - のんびりしているエンジニアの日記
皆さんこんにちは。 コンペで頑張ったので疲れました。 さて、Google Landmark 2021が終了し、Retrieval5位（金）、Recognition12位（銀）となりました。 本日は自戒と反省により、クラウドで30万円消失した話を 記録として書こうと思います。皆さん私を見て反面教師にしてください。 事象 9月入ってからLandmark2021に参加し、Google Cloud Platform、通称GCPを利用していた。 主な利用はGoogle Cloud Storageのみで、ほぼ容量課金だろうと高をくくっており、課金請求の上限など入れ忘れてました。 すると9/18に久々に請求額を確認すると32万ほどの請求額がありました。 さすがに目玉が飛び出て、調査にあたったといったものになります。 課金内容を確認したら原因はすぐにわかり、チームで対策を打ちました。（私が慌てて学習にスト
学習コストを下げるために大切な3つのこと ～エンジニア編～
子育てエンジニア advent calendar 2012 に刺激を受けて書きます。 世の中のパパエンジニアの人、色々苦労されてる反面、楽しくイクメンされてるようですね。 特に苦労されているところは学習コスト（金銭的・時間的）を払えなくなったというのを見ます。 しかもこれだけ変化が早いIT業界なら尚更です。 しかしながらIT業界で研鑽を止めると言うのは大変リスキーなことです。 私ももうすぐ5歳になる長女と2歳の次女、そして今は妻のお腹の中にいる第三子（長男）がいる子育てエンジニアです。 しかも私はエンジニアを志したときは既に長女がおり、独身時代の知識が0でした。 （最初はコマンドプロンプトからpingも撃てませんでしたｗ） そんな私が日々行なっている学習の3つのコツを紹介したいと思います。 １ 業務を通して知識を研鑽する これは一番手っ取り早く、かつ確実に行えます。 自分の興味のある技術を
コードレビュー・ネイティブ世代
会社員になってお仕事としてソフトウェア開発を始めたころ、ぼくにとってコードレビューは当たり前のものではありませんでした。幸いなことに、なにかのタイミングで当時ぼくが属していたチームのリーダーが「コードレビューをやりましょう」と提案してくれて、それで、会議スペースに液晶ディスプレイを設置して、ソースコードを画面に映して、チームメンバーで集まってあれこれと言い合う時間を過ごせました。これがきっと、ぼくとコードレビューの出会いです。おかげでぼくは「コードレビューって、ありがたいものなんだな」「コードレビューがあることで回避される悪いシナリオがたくさんあるな」と思えるようになりました。 気付けばあれから 10 年以上が経っていて、ぼくらの業界におけるコードレビューの認知度はどんどん上がり、実践している現場もどんどん増えてきたように感じています。今では「ふつう、やるよね？」と捉えている人も多いかと思
達人プログラマー 第2版はいいぞ
名著中の名著である達人プログラマーの第2版が2020年11月に出版されました。 原著であるThe Pragmatic Programmerは、1999年の出版で、第2版（英語版）の出版が2019年なので20年ぶりの改定ということになります。 この書籍にある個人的に響いたTipsと、ちょっとした感想をこの記事に書いていますので、書籍購入の参考になれば幸いです。 個人的に響いたTips8選 本書にはありがたいTipsがたくさんありますが、その中でも自分に特に響いたTips8つを紹介します。 割れた窓を放置しない 環境犯罪学の理論で有名な「割れ窓理論」はエンジニアリングの世界でも 当てはめることができるようです。 この書籍では悪い設計や質の低いコードを「割れ窓」とみなし、 それを放置することはクリーンなシステムの崩壊を加速させると言及しています。 これに関しては自分の心のなかで「割れ窓」が種とな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
