知っておきたいブラウザについての基礎入門 at サポーターズ京都勉強会 https://supporterz.connpass.com/event/51220/

デブサミ2017講演スライド 【16-B-7】視点移動～ビジネスと組織と人の狭間で越境し続けるエンジニアの物語、その彼岸

長くなったので先に三行でまとめておこう。 コピペするプログラマが生まれるのは教育の問題ではないか（仮説） 文法は学んでも処理の流れから考えることは教わっていない（根拠） ロジックを訓練するには脳内プログラミングが良いのでは？（提案） 少し前に私のMediumで、こんな記事を書いた。タイトルが言葉足らずだったおかげで、少し話題になった。「量産型プログラマを撲滅したい」 今回の記事では、この中で書いたコピペするプログラマがなぜ生まれるのか、どうすれば良いのか、考えてみたい。 どうすれば見分けられるのか 書いたプログラムを説明させてみれば、その人が、ちゃんと考えて作れる人か、コピペでしか作れない人か、すぐにわかる。自分の書いたプログラムの流れを説明できるということは「わかって書いた」ということだ。わかっていなければ説明できない。 「わかって書く」という一見すると当たり前のことができない人もいる。

ここから、DevとOpsが協力すればより効率的になる＝DevOps、という言葉が生まれました。 当時は大企業においてはDevとOpsが分かれていることが当たり前だったのです。そして、大企業における当たり前が、当たり前ではないことに気付き始め、DevOpsを実現するためのツールができ始めたころでもあります。 ではなぜ、大企業ではDevとOpsが分かれているのが当たり前だったのでしょうか？ ハードウェアの時代その昔、産業の主役はハードウェアでした。 そのため、多くの企業はハードウェアを作ることに対して最適化が行われました。 ハードウェアには研究開発、製造、運用サポートといった大きな区分けが存在します。そして、それぞれの仕事において要求する人材レベルは異なります。 加えて、大量生産された製品の運用サポート（設置作業員、サポートセンタ）には、大量の人員が必要になってきます。 したがって、組織を研究

2017/2/9 に株式会社チームスピリットで開催されたCI/CD NIGHTのLT資料です。 React.jsで構築したWebサービスをSeleniumでE2EテストするときにReact.js側で気をつけることをまとめました。

ワケ一覧 序の口: フレームワークだけが負債だと思ってる 序二段: ビジネスサイドに理解してもらう努力がない 三段目: 技術で遊び過ぎてしまう 幕下: 太り過ぎアーキテクチャ 十両: 過去に目もくれず、現状だって見ない 前頭: 技術に詳しいだけでアーキテクト 小結: アーキテクトの知識と覚悟が足りない 関脇: スパンが長く、モチベーションが続かない かど番大関: スパンが長く、人の入れ替えでチグハグ 大関: アーキテクチャデザインはどこへ？ 横綱: 実は人間的負債だった 序の口: フレームワークだけが負債だと思ってる みんな、フレームワークが大好き。とはいえ、さすがにみんな、「フレームワークが古いことだけが負債」だなんて思ってないはずだが...なのに多くの人が、あたかもそのような振舞いと判断をしてしまう。潜在意識の Big Issue だから？ o 信用できないテストデータ も負債 o 現

果たしてGitLab.comで何が起きたのでしょうか？ これまでの経緯をまとめました。 スパムによるトラフィックのスパイクからレプリケーションの不調へ GitLab.comは今回のインシデントについての詳細な経過を「GitLab.com Database Incident - 2017/01/31」で公開しています。また、もう少し整理された情報がブログ「GitLab.com Database Incident | GitLab」にも掲載されています。 これらのドキュメントを軸に、主なできごとを時系列に見ていきましょう。 1月31日16時（世界協定時。日本時間2月1日午前8時）、YP氏（Yorick Peterse氏と思われる）はPostgreSQLのレプリケーションを設定するためにストレージの論理スナップショットを作成。これがあとで失われたデータを救う幸運につながります。 1月31日21時

ブログっぽいことを初めて書きますが、来週（2017/02/03）JaSST東京の前ににテスト分析とテスト設計についてのLT大会が開催されます。 ということで、当日話すスライドを作成しました。 他の人がゆもつよメソッドについて解説してくれているものがあったので事前に読み返せるように貼り付けておきます。これらを読んで予習しとかないと！ WCATE2015に参加してくれた藤沢さんのスライド WACATE2014に朱峰さんがセッションとして発表した時のスライド 2020/5/5追記）みっきーさんが語る夕べの原稿を起こしてくれたnote。すごく良くまとまっているので追記しておきました。2021/6/5追記）語る夕べでゆもつよメソッド取り上げられたときの記事メモをに書いてくれているQita。これもよくまとまってるし、議事も書かれてて興味深い。この話、もともとなんで始まったんだろうかというとTwitte

もうちょっと規約的なものを「JavaでのUT作成基準を整理してみた」にもまとめてみました。 はじめに 去年、ブログの方に「ふつうのユニットテストのための７つのルール」という記事を書いたのですが、思ったより反響がありました。 あの記事で書いたのはあくまで原理・原則で、それを実現するためにはいくつかのテクニックが必要です。 特に、ああいうルールを作って「ユニットテストを書く事」を厳守するようにしても、 適切なテクニックを知らなければメンテが困難だったり、品質に寄与しなかったり、実行性能が悪いゴミが量産される可能性があります。 じゃあ、どうすれば良いかというと「最初からユニットテストが書きやすいように元のコードを設計する」ということです。 そう。まず身に付けるべきは「テストコードの書き方」では無く「テスト対象コード」すなわち「プロダクトコードの書き方」なのです。 また、ここで言ってる「最初から」

アプリやウェブアプリケーションは、ユーザーからの入力がなければ何も変化しません。プロダクトデザイナー、開発者、そしてプロダクトマネージャーがそれを理解することはとても重要です。 テキストフィールドは、ユーザーが短いテキストを入力するための基本パーツです。どのようなアプリでも、個人情報の入力を求める小さなテキストフィールドを必ず目にします。 この記事では、テキストフィールドを中心にデータ入力を改善する重要な要素について見ていきたいと思います。ただし、すべてのルールには例外があるということを念頭に置いておいてください。 わかりやすさ わかりやすいテキストラベル ユーザーはどんな種類のデータをフィールドに入力するべきか知りたいと考えます。明確なラベルテキストはユーザーにそれを伝えるメインの手段になります。もちろん、アイコンを頼りにフィールドの意味を理解することもあります。例えば、ユーザーが虫眼鏡

こんにちは。ヒューマンクレストのマイです。 私はベトナム出身で高校を卒業してから日本に来ました。母国と違う国に住み、今まで自分にとっての常識や考え方が覆されたことが少なくありませんでした。今回は自分が経験したことに基づいて品質の考え方について話したいと思います。 早速ですが、皆さんは物を買うときに何を意識していますか。値段？見た目？最近ECサイトでのお買い物が当たり前のように行われており、口コミなどを見て買い物をする人も少なくないですね。しかし、店舗での購入であれ、オンラインショッピングであれ、一番意識しているのはやはり「品質」ではないでしょうか。 我々が普段何気なく使っているこの「品質」という言葉ですが、「品質とは何か」と聞かれてすぐに答えることができるでしょうか。 品質とは？ ISO9000：2005では、以下のように定義されています。 「品質とは本来備わっている特性の集まりが要求事項

ご査収ください (2022年12月8日 追記) フローチャートを書き直しました。内容自体は当時のものと同じです。 補足 パフォーマンスの出し方は人それぞれなので「私はこんな感じです」というものです。 とりあえず「なんかやばいな?」と思ったら休む 体調的にはもちろん、「これ結構やばそうだな?」という勘所は大事 15分以上(長くても30分)悩んだら周りに聞いてみる こういう時はだいたい 視野が狭くなっている(簡単なスペルミスだったり) 暗黙知に触れている(業務だとよくある) とてつもない難問にぶちあたっている といったケースなので、仲間にSOSを出した方がチーム全体の進捗も結果的に良くなる、という経験談です。 ちなみに15分の根拠はなんとなくです。 ちなみに、問題に取り組み始めるその瞬間から「15分やってわからなかったら誰かに聞こう」としている場合は、 フローチャートの「30分動いてなかったら

職場で勝手にやっている改善活動のメモを取り出してから1年たったので振り返ってみたメモ。 書くこと 実際にやったこと 変わったこと 一番大きく変わったこと まとめ 実際にやったこと メモはハッシュタグ #俺俺改善活動 を付けて Twitter へツイートしていました。*1 今月の #俺俺改善活動．構成管理のブランチポリシーを整理してドキュメント化した．普段は見ないものだけど，ブランチ開発経験のない人が入ってきたときは効果すごいある— えび🦐 (@ebc_2in2crc) 2016年7月28日 今月の #俺俺改善活動．高コストな上に誤りが混入しやすい機能をエンドツーエンドでテストできるようにした．テストは自動化されているから CI に組み込めるし，安心して修正できるようになった(*'▽'*)— えび🦐 (@ebc_2in2crc) 2016年7月28日 今月の #俺俺改善活動 ・テストの2

こんにちは、2017年のエンジニア研修の担当者を務めます、 @asuforce & @shimojuです。 研修の担当者は社内でスーパーバイザーとか船頭と呼ばれております。 ペパボの新卒も7期目になり、エンジニアとして入社した4人が研修に励んでおります。 6月の後半から始まったエンジニア研修が1つの節目を迎えたので、これまでの様子を紹介いたします。 ペパボの新卒エンジニア研修について 研修の内容は大きく、基礎研修、サイクルOJTに分かれています。 基礎研修とは3ヶ月の間にWeb開発、Webオペレーション、モバイルアプリケーションを学ぶもので、サイクルOJTとは複数のサービスを2週間ごとに移動しながらOJTを行うものになります。 より詳しい内容は以下の記事を参考にしていただけると、概要を掴むことができると思います。 GMOペパボの新卒エンジニア研修の様子 & テキストを公開します 事前準備

Workshop: Half hour of labeling power: Can we beat GPT?

エンタープライズアジャイル勉強会で使用した資料

37. その他の用語 イベント（事象）  システムの外側で発生し、その発生をシステムが制御できない事象。システムにとっていつ起こるかわからない、タ イミングの操作が不可能な出来事。 スティミュラス（刺激）  発生したイベントによってシステムに刺激を与えるための情報入力。イベントによって、イベントの発生元とシステ ムの境界を流れてくるデータ。 アクション（行動）  イベントが発生した時にシステムが起こす行動。システムの外側から見て、システムが何をするのか。 レスポンス（応答）  システムが起こしたアクションの結果、システムの外側から見える形で応答するための情報出力。スティミュラスに 対応して、システムの外側に流れ出てくるデータ。 エフェクト（影響）  システムのレスポンスによって、システムの外側に与える影響。イベントに対してどのような価値が得られるか。 38. その他の用語 エピソ

2017/07/28 @ Developers Summit 2017 Summer A-5セッション「組織と文化のリファクタリング」後編資料