並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 40 件 / 1026件

新着順 人気順

jenkinsの検索結果1 - 40 件 / 1026件

  • 優秀さについて

    Twitter で医師を拾ってきて Google のソフトウェアエンジニアにするだけの簡単なお仕事 - 白のカピバラの逆極限 S.144-3 はじめに 「【転職エントリ】Googleに入社します|Lillian|note」という、医師から未経験で Google のソフトウェアエンジニアになった記事があります。 note.com 私は、この記事に出てくる「とある元 Google のソフトウェアエンジニア」で、面接の対策を立てました。 記事が出た当初から大反響で、私もそれなりの反応を見まして、いろいろと誤解されているなあ、と思う一方、アドバイザーはあくまでもアドバイザーだから、アドバイザーとして知りえた情報については、口をつぐむべきだと思っていました。 ただ、あまりにも誤解されており、悪影響が大きく、犠牲者も多くなってきたと思ったので、… 同僚からこれについてどう思うか、と聞かれた。元の文章が

      優秀さについて
    • 自称IT企業があまりにITを使わずに嫌になって野に下った俺が紹介するWindowsの自動化の方法 - Qiita

      はじめに コンピュータを使用した多くの操作は自動化することができます。 この技術は運用や試験工程で大きな力を発揮します。 自動化の技術は一般的なソフトウェア技術者が、ちょっと努力すれば普通に身につく能力であって、特別なものではありません。 ただ残念なことにこれらの技術はあまり知られておらず、活用されているとは言い難い現場も多いです。 ユーザー企業さんができないのはしょうがないですが、ITで飯を食べているはずの自称IT企業においても、自動化を拒否して手動で心をこめて作業をしてリソースを無駄にするケースを稀によく見かけます。 自動化の拒否が「余剰人員のための経済対策だよ!」という身もふたもない理由でないと信じて今回は、Windowsでの作業の自動化についてお話しようと思います。 自動化のテクニックの話をする前に Windowsの自動化のテクニックの話をする前にちょっと重要なことを先に述べておき

        自称IT企業があまりにITを使わずに嫌になって野に下った俺が紹介するWindowsの自動化の方法 - Qiita
      • ネットの音楽オタクが選んだ2021年のベストアルバム 50→1 - 音楽だいすきクラブ

        ネットの音楽オタクが選んだ2021年のベストアルバム、最終日です。Twitterのハッシュタグと告知記事のコメント欄で参加していただいた722人分のデータを集計しました。 今回のランキングは僅差でした。ありがたいことに年々参加者が増えているので集計対象外のものは除外しているのですが、そういうものに配慮すればまた順位は変わってきたと思います。だけど順位は目安であり、場所や時期を変えれば当たり前のように変わります。だからあまり気にしすぎないでください。この記事はあくまで知らなかった作品を知る場として使っていただければうれしいです。 有志によるレビューもつけました。まだまだレビューも受け付けています。記事末尾にプレイリストも用意しました。楽しんでいただけたら幸いです。それではお楽しみください。(ぴっち) このランキングについて ネットの音楽オタクが選んだベストアルバムは音楽だいすきクラブ、及びそ

          ネットの音楽オタクが選んだ2021年のベストアルバム 50→1 - 音楽だいすきクラブ
        • 手軽に負荷テストができるツール「Taurus」がスゴい

          modules: jmeter: version: 5.4.1 # ここに書いてあるバージョンを勝手にダウンロードしてくれる properties: log_level.JMeter: WARN log_level.JMeter.threads: WARN system-properties: org.apache.commons.logging.simplelog.log.org.apache.http: WARN 既存ツールのラッパーとして動作 デフォルトでは内部的にJmeterが実行されますが、以下のようなツールで作成されたスクリプトを流用することが可能です。 JMeter Gatling Locust Selenium Vegeta つまり、さきほどはYAMLでシナリオが記述可能とは言いましたが、もちろん既存のスクリプトを流用できるってことです。 いままで作り上げてきたスクリプトや

            手軽に負荷テストができるツール「Taurus」がスゴい
          • 世界中のITエンジニアが悩まされている原因不明でテストが失敗する「フレイキーテスト」問題。対策の最新動向をJenkins作者の川口氏が解説(前編)。DevOps Days Tokyo 2022

            世界中のITエンジニアが悩まされている原因不明でテストが失敗する「フレイキーテスト」問題。対策の最新動向をJenkins作者の川口氏が解説(前編)。DevOps Days Tokyo 2022 世界中のITエンジニアが悩まされている問題の1つに、テストが原因不明で失敗する、いわゆる「フレイキーテスト」があります。 フレイキーテストは、リトライすると成功することもあるし、失敗する原因を調べようとしてもなかなか分かりません。GoogleやFacebookやGitHub、Spotifyといった先進的な企業でさえもフレイキーテストには悩まされています。 このフレイキーテストにどう立ち向かうべきなのか、Jenkinsの作者として知られる川口耕介氏がその最新動向を伝えるセッション「Flaky test対策の最新動向」を、4月21日、22日の2日間行われたイベント「DevOps Days Tokyo 2

              世界中のITエンジニアが悩まされている原因不明でテストが失敗する「フレイキーテスト」問題。対策の最新動向をJenkins作者の川口氏が解説(前編)。DevOps Days Tokyo 2022
            • Docker創始者らが開発、ビルド/テスト/デプロイの自動化をポータブルにするツール「Dagger」登場。そのままローカルでもGitHubでもCircleCIでも実行可能に

              Docker創始者らが開発、ビルド/テスト/デプロイの自動化をポータブルにするツール「Dagger」登場。そのままローカルでもGitHubでもCircleCIでも実行可能に Dockerの創始者であるSolomon Hykes氏らが中心となって開発しているオープンソースのCI/CD環境構築ツール「Dagger」が公開されました。 Windows、Mac、Linuxで試すことができます。 And we are live! Introducing Dagger, a new way to build CI/CD pipelines. By the creators of Docker. https://t.co/DU8racmoUo — dagger (@dagger_io) March 30, 2022 Daggerが定義したCI/CDパイプラインはポータブルになる Daggerとは「A P

                Docker創始者らが開発、ビルド/テスト/デプロイの自動化をポータブルにするツール「Dagger」登場。そのままローカルでもGitHubでもCircleCIでも実行可能に
              • 10 年前に JavaScript で Flash Player を開発し買収された話

                この記事は、JavaScript で Flash Player の実現を頑張った(もしくは現在進行系で頑張っている)人たちの集う Flash Advent Calendar 2020 に参加しております。 私は過去に自分が設立した会社で ExGame という HTML5 実装の Flash Player(正確には Flash Runtime Engine)を開発し、その会社ごと DeNA に買収(M&A)されました。あまり出来ない体験であるのは間違いないので、Flash が終了を迎える今、改めて振り返ってみようと思います。 Flash Player の開発 今から 10 年前の 2010 年、ちょうど iPhone が普及し始めてきてガラケーのシェアが 8 割から 6 割くらいに落ちようとしていた時期に、私は Flash Player を JavaScript で実装していました。以前この

                • 【Webエンジニアど素人から3年生ぐらいになるまでに読むと良い本】を段階的にまとめた - Qiita

                  これってなんなの? 【ど素人状態=社会人になって初めてプログラミングを勉強したぜ!(特に新卒)】〜【Webエンジニアの3年生ぐらい】になるまでに読むと良い本まとめです。「どんな目的で学ぶか?」*「いつぐらいまでに読むといいか?」を段階的にまとめました。「これだけ読めばいい!」と、そんな簡単な話ではありませんが、「今いるレベルより少し上の人がどんなジャンルのことを学んでんだろ?」という方の参考になれば嬉しいです。過去の自分に向けてでもあります、自戒。これからWebエンジニアになる人、なって間もない人の参考になれば幸いですm(__)m ※続編 【Webエンジニアど素人】が【3〜4年生】くらいになったら読むといい本を目的別にまとめた ”Webエンジニアど素人から3年生ぐらいになるまでに読むと良い本”の段階的まとめ(一部外部記事あり) ど素人の方々が手を動かしながら1〜6ヶ月以内に学ぼう! ◆どの

                    【Webエンジニアど素人から3年生ぐらいになるまでに読むと良い本】を段階的にまとめた - Qiita
                  • pixivのブックマークに関する負荷対策をしました - pixiv inside

                    10/22(金) 追記 この記事で解説している内容について解説する勉強会を開催することとなりました。以下のconnpassよりお申し込みください。 pixiv.connpass.com 10/22(金) 追記 pixivのブックマークについて ブックマークDBの問題について 具体的な対策内容 論理削除廃止・index追加・ブックマークタグのテーブル分割 適応ハッシュインデックスの無効化 アプリケーションコードのリファクタリング・全発行クエリの列挙と見直し 大きな更新処理の非同期化 結果 あわせてよみたい pixivではサービスの成長に伴い、気に入った作品に対して付けることができるブックマークの総数が急速に増加しており、ユーザーの皆様に滞りなくサービスを提供し続けるためブックマークに関するデータベース(以後DB)の負荷対策が必要になりました。 2021年2月より対策を行うプロジェクトを発足し

                      pixivのブックマークに関する負荷対策をしました - pixiv inside
                    • コードレビュー虎の巻 - Qiita

                      レビューガイドライン(Review GuideLine) ここで述べているレビューはピアレビューについての方法です。 (作業成果物の欠陥と改善の機会を探すレビュー) 「最悪を最初に」を基本としてレビューすべき、 たとえば、仕様やアルゴリズムに欠陥があるのに、typoにこだわってもしょうがないので、なにが最悪かを考え、それを防ぐための物からレビューをします。 誤りがプロダクト全体に影響し、手戻りのコストが高くつく、あるいは失敗するようなリスクがないかを考慮にいれてレビューの対象を選択します。 たとえば、基本的な初期フェーズの要求仕様や、クリティカルな決定の基礎になる仕様、使用頻度が高いモジュールなどを重点的にレビューします。 以下に書く項目はレビュアーに負担をかけないようにするのが前提なのでレビュアーに出す前にそもそもテストしたい項目です。 参考: あなたのおっしゃるレビューってどのことかし

                        コードレビュー虎の巻 - Qiita
                      • レガシープロジェクトを引き継いだ時、最初にするべき7つのこと - Qiita

                        営業一課で使っている PHPアプリを保守してくれないかな? ○○さんが1人で作ってメンテしてたやつなんだけど 皆さんは上司からこんな仕事を振られたことはないでしょうか?私は過去に何度か経験した1のですが、こういった仕事はなぜか: 正確な仕様を知っている人はいない(知ってた人は辞めた) テスト計画書・デプロイ手順書・仕様書といったドキュメントは無い ソースコードはもちろんスパゲッティ でも、業務ではガッツリ使われているので廃止できない というレガシープロジェクトばかりでした。この記事では、レガシープロジェクトを引き継いでしまった時に、最初に何をするべきか書いていきたいと思います。 なお、ここで最悪なのは「とりあえず、緊急の不具合から直してしまおう」と、いきなりコードの修正にかかることです。 ※おことわり: 「レガシー」には様々な定義がありますが、この記事では「遵法的な職場の」「PHPやRai

                          レガシープロジェクトを引き継いだ時、最初にするべき7つのこと - Qiita
                        • t_wada さんの講演メモ ー 技術書の読み方を中心に - 冷めたコーヒー

                          はじめに 和田さん(@t_wada)の講演が素晴らしく良かったのでメモを残しておきたいと思います。和田さんと言えば... t_wada ですね!本講演では、「技術の学び方を学ぶ」ことを目的として二部構成で論が展開されました。「技術の学び方の学び」とは、メタレベルの学びのことを指しています。すなわち、効率的に新しい技術を学ぶためにはどのように学べば良いのかという話です。内容は以下の通りです。 第一部 四半期ごとに技術書を読む 手を動かしながら学ぶ 毎年少なくとも一つの言語を学ぶ 身の回りをプログラミング対象にする アウトプットを行う 第二部 毎日コードを書く 年下から学ぶ 過去から未来を見る 人のつくる渦を見る 大事なことに集中する いずれも非常に興味深い内容だったのですが、細かい事項については2017年の講演メモのエントリーがありましたので、ぜひそちらをご覧いただければと思います。(記事へ

                            t_wada さんの講演メモ ー 技術書の読み方を中心に - 冷めたコーヒー
                          • バッチ処理について考える - Qiita

                            TL;DR ひとくちにバッチといっても色々ある 夜間バッチをもう作るな オンラインバッチはSQL以前にDB設計がんばれ はじめに Twitterのタイムラインで以下のようなツイートが回ってきました。 バッチ処理をみんな舐めてかかったり、ショボイとか思ってる人多い印象なんだけれども、数十万~数千万件規模のデータを処理したことあるのかな。テンプレ通りのコードじゃ動かないよ?ネットに本にも答え載ってないよ?低レイヤも意識しないと動かないよ? 2020年1月10日 ツイートされたわだっしーさんの意図がどこにあるかは確認してないですが、極限の世界でテンプレート的な処理では対応出来ないのはあるよな、と思いつつもある程度はバッチの作法としての書き方があると思っています。 このツイートとその関連ツイートを読みながら、そういえばバッチ処理に関して書いてある記事はあまり見ないなぁ、とおもったので他のネットや本

                              バッチ処理について考える - Qiita
                            • マイクロサービス設計原則: SOLIDではなくIDEALS

                              キーポイント For object-oriented design we follow the SOLID principles. For microservice design we propose developers follow the “IDEALS”: interface segregation, deployability (is on you), event-driven, availability over consistency, loose-coupling, and single responsibility. Interface segregation tells us that different types of clients (e.g., mobile apps, web apps, CLI programs) should be able to inte

                                マイクロサービス設計原則: SOLIDではなくIDEALS
                              • Software Design連載 2021年9月号 「テストが無い」からの脱却 - MonotaRO Tech Blog

                                こんにちは、鈴木です。 「テストが無い」状態を脱却しました。 「いつの時代かよ!」と突っ込まれるかもしれませんが、モノタロウは創業から 20 年ほど EC をやっています。昨日書いたコードも、15 年前に書いたコードも、元気にビジネスを支えています。 本記事ではモノタロウの EC を支える API の話をします。「テストが無い」状態がスタートラインでした。そこから、CI を導入して、ローカル開発環境の整備して、テストコードを書いて、リリースマネジメントを導入しました。 目新しいことは書きません。長寿の大規模システムであっても、愚直に数年取り組むことで、「前進できる!」「変えられる!」という実例を書きます。 ※本記事の初出は、 Software Design2021年9月号「Pythonモダン化計画(第2回)」になります。第1回の記事は「Software Design連載 2021年8月号

                                  Software Design連載 2021年9月号 「テストが無い」からの脱却 - MonotaRO Tech Blog
                                • JP Contents Hub

                                  AWS 日本語ハンズオン Amazon Web Services(AWS) の 日本語ハンズオンやワークショップを、カテゴリごとにまとめています。 右側の目次や、ヘッダー部分の検索ボックスから、各コンテンツにたどり着けます。 また、Ctrl + F や command + F を使ったページ内検索もご活用いただけます。 料金について ハンズオンで作成した AWS リソースは通常の料金が発生します。作成したリソースの削除を忘れずにお願いします。 もし忘れてしまうと、想定外の料金が発生する可能性があります。 画面の差異について ハンズオンで紹介されている手順と、実際の操作方法に差異がある場合があります。 AWS は随時アップデートされており、タイミングによってはハンズオンコンテンツが追いついていない事もあります。 差異がある場合、AWS Document などを活用しながら進めて頂けますと幸い

                                    JP Contents Hub
                                  • Markdown と GitHub で社内規程を便利に管理 - クックパッド開発者ブログ

                                    VP of Technology の星 (@kani_b) です。技術基盤や研究開発領域などを担当しつつ、社内の色々なことを技術の力でいい感じにする仕事をしています。セキュリティや AWS の話が好きです。 さて、みなさんは、ご自身が勤務する会社の就業規則を読んだことはあるでしょうか。 エンジニアに限らず、会社の全スタッフが仕事をする上で関わってくるのが、就業規則や情報セキュリティドキュメントなど、会社のルールや規程を記す文書です。 特にセキュリティやインフラに携わるエンジニアは、その改訂も含め携わったことがある方もいるのではと思います。 よくある文書管理 こうした文書は、以下のように管理されていることが多いようです。 ベースドキュメントは Word 保存時は PDF で保存 版管理は Word の編集履歴 + PDF に保存する際のファイル名 編集は担当部門, 担当者のみが行う かつての

                                      Markdown と GitHub で社内規程を便利に管理 - クックパッド開発者ブログ
                                    • エンジニアは全員おうちKubernetesをやるべし【Part 1:なぜやるのか】 - Qiita

                                      こんにちは。おうちKubernetesを勧めるためにやってきました。 このシリーズでは、Part 1で「なぜやるのか」、Part 2で「どうやるのか」について話します。 この記事は自宅サーバー上のKubernetesで不特定多数向けのサービスを展開することを勧めるものではなく、自分用・身内用のアプリを自宅サーバー上のKubernetesで運用することを勧めるものです。 エンジニアは全員おうちKubernetesをやるべき絶対的な理由 自己研鑽のために (鑽←この字「研鑽」と「大鑽井盆地」でしか見ない) 企業がKubernetesを採用する場合、ほとんどがEKSやGKEといったクラウド上で動作するマネージドKubernetesサービスを使用すると思います。ただ、Kubernetesであればコマンドやマニフェストファイルの書き方は共通なので、おうちKubernetesで学んだことがそのまま業務

                                        エンジニアは全員おうちKubernetesをやるべし【Part 1:なぜやるのか】 - Qiita
                                      • Twitter での 2年 · eed3si9n

                                        2022-11-20 僕は Twitter社の Build/Bazel Migration チームでスタッフ・エンジニアとして勤務していた。信じられないような 2年の後、2022年11月17日をもって退職した (企業買収後のレイオフでも任意でもあんまり関係無いが、僕は任意退職希望のオファーを取った)。Twitter社は、切磋琢磨、多様性、そして Flock を構成する全ての人に対して溢れ出る優しさというかなり特別な文化を持った職場だった。これを間近で経験して、その一員となる機会を得たことに感謝している。(Flock は「鳥の群れ」の意で、社内での Twitter社の通称) 以下は過去2年の簡単な振り返りだ。尚本稿での情報は、既に公開されているトークやデータに基づいている。買収後、うちのチームだけでも 10名以上のメンバーが Twitter社を抜けたので、在籍・元含め LinkedIn プロ

                                        • 大きなGitリポジトリをクローンするときの工夫を図解します - DeNA Testing Blog

                                          こんにちは、SWETでCI/CDチームの前田( @mad_p )です。 SWETではCI/CDチームの一員として、Jenkins運用のサポートや、CI/CD回りのノウハウ蓄積・研究をしています。 はじめに Gitリポジトリをクローンすると、ローカルフォルダにはそのリポジトリの全体がダウンロードされ .git というフォルダに格納されます。ブランチをチェックアウトすると、ブランチ内のファイルがワーキングツリーとして展開されます。この様子を図にするとこのようになります。 この .git とワーキングツリーの使うディスク容量を節約しようというのが今回のお話です。特にJenkinsにおいて、大きめのGitリポジトリをクローンしてくる場合に課題があり、いろいろ工夫してみたので、その結果を紹介します。同じCI/CDチームの加瀬による記事「大規模リポジトリで高速にgit cloneするテクニック」と内容

                                            大きなGitリポジトリをクローンするときの工夫を図解します - DeNA Testing Blog
                                          • PayPayエンジニアが明かす「100億円キャンペーン」のシステムの舞台裏 数々の問題を解決するためにやったこと

                                            PayPayエンジニアが明かす「100億円キャンペーン」のシステムの舞台裏 数々の問題を解決するためにやったこと PayPay 100億円キャンペーンのシステム構築 #1/2 2019年6月12〜14日、幕張メッセにて「AWS Summit Tokyo 2019」が開催されました。アマゾンウェブサービス (AWS) に関する情報交換や、コラボレーションを目的として行われるこのカンファレンスでは、140社以上の利用企業による先進事例セッションをはじめ、数々のイベントを実施しました。プレゼンテーション「PayPay 100億円キャンペーンのシステム構築 」に登壇したのは、PayPay株式会社プロダクト本部の山本啓介氏とShilei Long氏。スマホ決済アプリとして新規参入した同社が展開し、日本中の話題をさらった「100億円キャンペーン」の技術的背景について語ります。前半パートとなる今回は、山

                                              PayPayエンジニアが明かす「100億円キャンペーン」のシステムの舞台裏 数々の問題を解決するためにやったこと
                                            • GitHub Actions入門 ── ワークフローの基本的な構造からOIDCによる外部サービス認証まで - エンジニアHub|Webエンジニアのキャリアを考える!

                                              GitHub Actions入門 ── ワークフローの基本的な構造からOIDCによる外部サービス認証まで GitHubが公式に提供するGitHub Actionsは、後発ながらよく使われるワークフローエンジンとなっています。本記事では、藤吾郎(gfx)さんが、典型的なCI/CDのユースケースに即したワークフローの設定と管理について解説するとともに、注目されているGitHub OIDC(OpenID Connect)の利用についても紹介します。 GitHub Actionsは、GitHubが提供するCI/CDのためのワークフローエンジンです。ワークフローエンジンは、ビルド、テスト、デプロイといったCI/CD関連のワークフローを実行し、定期実行するワークフローを管理するなど、開発におけるソフトウェア実行の自動化を担います。 ▶ GitHub Actions - アイデアからリリースまでのワーク

                                                GitHub Actions入門 ── ワークフローの基本的な構造からOIDCによる外部サービス認証まで - エンジニアHub|Webエンジニアのキャリアを考える!
                                              • SoundCloudに転職した

                                                2019年12月17日Cookpad(イギリス支社)を6月に退職し、7月からベルリンに移りSoundCloudで働いている。 日本を離れてから3年が経つ。何かしらの形で情報発信しないと日本での人間関係が文字通りゼロになってしまいそうなので近況を綴ることにした。ついでに、誰かの参考になれば尚嬉しい。 誰?2014年にCookpad入社。直後からiOS Tech Leadとして海外事業の立ち上げに従事し、2017年からは海外事業の拠点であるイギリスに出向。2019年7月にドイツに移りSoundCloud入社、現在に至る。『Swift実践入門』の著者の一人。 前職のことについてあまり言及しないが、端的に言うと素晴らしい職場だった。優秀なメンバーと刺激的なプロジェクトから多くを学んだ。こうして新しい挑戦ができるのも前職で成長する機会に恵まれたからに他ならない。日本・海外共に積極採用しているはずなの

                                                • マーソ株式会社を退職します - ikasama over technology

                                                  6 月 30 日付けで退職、昨日 28 日が最終出社日でした。 2018 年 2 月から、約 1 年半お世話になりました。 マーソ株式会社 is 何 ( 2019 年 6 月末時点の情報です ) www.mrso.jp MRSO という Web サービスを運営している会社です。 MRSO は、人間ドックや検診を全国の医療施設から検索・予約できるポータルサイトです。 登録されている医療施設数は、国内の類似サービスの中ではトップクラスの規模です。 他にもこんな事業をやっています。 MRSO で利用できるギフト券、マーソギフト券の販売 健康をプレゼントするとう考え方 ご両親に人間ドックを受けてほしい! というユースケースが多いようです 企業向けの健診結果管理システムの開発・運用 ( toB ) 何をしていたのか MRSO の開発・運営に必要なほとんどの領域を担当していました。 具体的には、 新機

                                                    マーソ株式会社を退職します - ikasama over technology
                                                  • LINEの社内には「テクニカルライティング」の専門チームがあります - LINE ENGINEERING

                                                    こんにちは、Developer Contentチームのmochikoです。LINE株式会社でテクニカルライターとして働いています。今日は「テクニカルライター」というお仕事と、LINEにあるテクニカルライティングの専門チームについてお話しします。 テクニカルライターという職種があります テクニカルライターって何をしてるの?何を書くの? ドキュメントはどうやって書いてるの? どんなメンバーで仕事をしてるの? ドキュメントを書く以外にこんなこともしているよ でもドキュメントを書くだけだと技術力が下がらない? どんな人がテクニカルライターに向いてるの? テクニカルライターという職種があります 私はもともとウェブ制作会社のインフラエンジニアでした。とある技術書を書いたことをきっかけに「テクニカルライターとして一緒に働きませんか?」と声をかけてもらい、LINEへ転職するに至ったのですが、実はお誘いをい

                                                      LINEの社内には「テクニカルライティング」の専門チームがあります - LINE ENGINEERING
                                                    • 15年間システム開発業を営んで来た結果の最適解 - Qiita

                                                      15年間様々な環境を試してきましたが、これが最適かと思っている事を記載します。 随時更新し、各項目の詳細は別記事で記載していこうかと考えています。 2019/08/28追記 多くのいいねを頂きありがとうございます。 大切な業務分析が抜けていましたので、追記させて頂きました。 環境周り 開発環境 IntelliJ vim・emacsでプラグインを使用、Eclipseなど様々なIDEを使用してきましたが、現在はIntelliJに統一しました。 以下採用理由です。 構築が行いやすい 多数の言語・フレームワークに対応している あらゆるプロジェクトにて同じIDEを使用出来る 補完が非常に便利 あらゆる操作にキーバインドが設定可能 初心者から熟練者まで満足できる操作性 Docker 出来る限り環境依存を無くす為、データベースなどのサーバープロセスはDockerで構築しています。 但し、Tomcatは環

                                                        15年間システム開発業を営んで来た結果の最適解 - Qiita
                                                      • テクノロジー企業の墓場

                                                        (はてなブックマークやTwitterでの対話で詳しい人が色々教えてくれたのでそれに伴って改稿) VMwareがBroadcomに8兆円(!)で買収されるというニュースが報道されている。 Broadcomは通信に必要なチップを寡占している地味なベンダという印象であったので、なんじゃそりゃと思ったら、2005年にプラベート・エクイティが作った会社が買収と売却を繰り返して急成長して、2015年にはBroadcomを5兆円で買収して社名を引き継ぎ、2017年には更にQualcommを買収しようとして米国政府に阻止され、2018年にはCAを買収、2019年にはSymantecを買収と、そういう流れである。 要するに、マーケットを寡占している製品を持つ低成長・斜陽の会社のIPを割安で買って、セールスもマーケティングもR&Dもお金のかかる事は全部辞めて、既存のお客さんからライセンス料をとれる間だけとろう

                                                          テクノロジー企業の墓場
                                                        • 「1人アジャイル」から始める、アジャイル開発導入のススメ|Agile Journeyローンチによせて - Agile Journey

                                                          みなさん、こんにちは。 ユーザベースという会社でSaaS事業のCTOを務める林 尚之です。 本日、新しいWebメディア『Agile Journey』がローンチされました。私はこのメディアに編集長として関わりますが、本稿では『Agile Journey』がどんなメディアで、なぜアジャイルをテーマとしたメディアを立ち上げたのかをお伝えしたいと思います。 『Agile Journey』はできるかぎり「実践」にフォーカスしていきたいと考えています。すでに世の中には、アジャイルに関する事柄を解説する本や資料がたくさんあり、「ペアプロってなに?」「TDDってなに?」という問いに対する基本的な解は容易に見つかるでしょう。しかし、「やり方を知る・理解する」と、「それをいかに実践するか」には別の難しさがあります。実際、私も「アジャイルをいかにして、実践するか」に関して日々、頭を悩ませていますし、試行錯誤を繰

                                                            「1人アジャイル」から始める、アジャイル開発導入のススメ|Agile Journeyローンチによせて - Agile Journey
                                                          • プログラムの実行時間を99%短縮した「たった1行のコード」とは?

                                                            プログラムの実行速度やウェブサイトの表示速度は、たった数秒の改善でも多くのエンジニアたちの苦心を必要としますが、時として拍子抜けするほどにあっけなく、かつ劇的な改善がなされる場合もあります。画像共有サービスのPinterestが自社のブログで「たった1行の変更でコードの実行時間を99%短縮した」事例を紹介しています。 How a one line change decreased our build times by 99% | by Pinterest Engineering | Pinterest Engineering Blog | Oct, 2020 | Medium https://medium.com/pinterest-engineering/how-a-one-line-change-decreased-our-build-times-by-99-b98453265370

                                                              プログラムの実行時間を99%短縮した「たった1行のコード」とは?
                                                            • Software Design連載 2021年8月号 Python製のレガシー&大規模システムをどうリファクタリングするか - MonotaRO Tech Blog

                                                              Software Design連載開始 ※ (2021/09/02 08:55) 「Pythonを用いて開発を始めたのが2003年」を「Pythonを用いて開発を始めたのが2002年」に修正 こんにちは。金谷です。 このたび、モノタロウにおけるPython大規模開発に関する取り組みを、技術評論社様で発刊されている Software Design に連載させていただくことになりました。 モノタロウがPythonを用いて開発を始めたのが2002年。2021年の現在もPythonを用いた開発が続けられています。 事業の成長に伴い、関連するシステムやエンジニアの数も増え続けていくなかで、いかに安定的に価値を提供し続けられるのか。 モノタロウにおける取り組みを、開発や運用周りを通してご紹介していきます。 本記事の初出は、 Software Design2021年8月号「Pythonモダン化計画(第1

                                                                Software Design連載 2021年8月号 Python製のレガシー&大規模システムをどうリファクタリングするか - MonotaRO Tech Blog
                                                              • GitHub Actions に入門するなら GitHub Learning Lab の Hello World コースを受講しよう - kakakakakku blog

                                                                GitHub を学ぶときに「GitHub Learning Lab」を使うと便利!という紹介記事を6月に書いた.最近 GitHub Actions を使う機会があり,入門するために「GitHub Learning Lab」の「GitHub Actions: Hello World」コースを受講した.今回も非常に良かった! kakakakakku.hatenablog.com GitHub Actions: Hello World 「GitHub Actions: Hello World」は GitHub Actions を学ぶ入門コースとなる.現在はまだ日本語に翻訳されてなく,英語を選択する必要はあるけど,Bot / Issue / Pull Request を活用したインタラクティブな構成になっていて,楽しく学べる.以下のステップを進めていくことになり,最終的には GitHub Acti

                                                                  GitHub Actions に入門するなら GitHub Learning Lab の Hello World コースを受講しよう - kakakakakku blog
                                                                • 3年間ちょっと勤めたNTTテクノクロスを退職しました - blog.manj.io

                                                                  6/14に退職したので、退職エントリを公開することにしました。 NTTテクノクロスを退社して、LINEに転職しました。 Nanimono TX入社まで NTTで過ごした3年間 転職活動 きっかけ 顛末 転職判断 NTTについてぼんやりと思うこと NTTテクノクロスの環境について おわりに Nanimono Twitter: @_manji0 1994年製。早生まれ25歳児。ビールと日本酒と煙草大好きマン。趣味は筋トレ。 持ってる資格はAPとNWと普通免許のみ。 NTTテクノクロス(以下TX)という会社に2016年に入社して、以下のようなことをしてた。 OpenStackの検証やグループ内クラウド基盤の保守対応 研究所と一緒にNW系のアレコレ研究開発 StackStormやAnsibleを使って作業自動化 TX入社まで とある駅弁大学の工学部のシステム系の学科にいた。GPAは0.7くらいしか

                                                                    3年間ちょっと勤めたNTTテクノクロスを退職しました - blog.manj.io
                                                                  • 【レポート】楽天の大規模決済システムを支えるAWSアーキテクチャ #AWSSummit | DevelopersIO

                                                                    DA事業本部の春田です。 AWS Summit Online絶賛開催中!ということで、本記事では「CUS-65: ペイメントプラットフォームにおける AWS の活用」の内容についてまとめていきます。 セッション情報 楽天株式会社 グローバルテクノロジー統括部 國谷 彩 氏 AWS上でのPayment Platformシステムの歴史についてお伝えします。AWSへ移行してからこれまでの課題と解決方法について説明します。 ※セッション動画は以下リンク アジェンダ 楽天グループについて ペイメントプラットフォームについて ペイメントプラットフォームにおけるアマゾンウェブサービス(AWS)の歴史 楽天グループについて Eコマースのサービス「楽天市場」をはじめ、Fintech事業やエンターテイメント事業まで、さまざまなビジネスを展開 各サービスが楽天共通IDで繋がることで、サービスを跨いだグループシナ

                                                                      【レポート】楽天の大規模決済システムを支えるAWSアーキテクチャ #AWSSummit | DevelopersIO
                                                                    • 業務委託テックリードと技術的負債 - LIVESENSE ENGINEER BLOG

                                                                      河野と申します。2018年8月からマッハバイトで業務委託(いわゆるフリーランス)として業務に携わっており、2022年6月から、テックリード(以降、TL)という立場となりました。 TLという言葉は広く使われていますが、実際に何をするのかは、会社や環境によってさまざま。 3ヶ月の振り返りがてら、ここに一例として公開してみようと思った次第です。 TL着任以前 Join当初はRailsエンジニアとしての働きを期待されており、最初の担当はマッハバイトiOS版用に、REST APIを開発することでした。 半年少しでその業務が一段落した後は、以下のことなどを担当してきました。 Rails製アプリケーションの機能追加、Ruby、RailsのUpdate ホストOSのUpdateに伴う、deploy環境の修正や、ライブラリなどのUpdate(オンプレ環境) マイクロサービスの中心に置きたいメッセージングサー

                                                                        業務委託テックリードと技術的負債 - LIVESENSE ENGINEER BLOG
                                                                      • 20年でソフトウェア開発の景色はどのぐらい変わったのか? - Qiita

                                                                        PySpa統合思念体です。 某チャットで、「今時のOSSのプロジェクト管理とかのベストプラクティスが書いてある本ないかな、陳腐化早そうだしないか」みたいな話題が投入されました。その中で、エキスパートPythonプログラミングとか、Pythonプロフェッショナルプログラミングとかは思い出して紹介したけど、他の人からはShip It、Manage It、Release It三部作とか、達人プログラマーとかも出てきました。 このあたりの源流を辿ると、そういえば今流行ってる開発の源流としてはエクストリームプログラミングの開発系のプラクティスの遺伝子を受け継いでいるのが多いよな、そういえば当時から見て今ってどう変わっているのかな、という話題に。せっかくなので20年前を思い出しつつ、当時と今でどういう風に変わってきたのか適当にまとめてみます。 20年前の状況 XP白本こと、eXtreme Progra

                                                                          20年でソフトウェア開発の景色はどのぐらい変わったのか? - Qiita
                                                                        • 退職しました - ししちにじゅうはち 4x7=28

                                                                          例の画像をここに貼る どこを 東海地方では有名な大企業D社を退職しました。 実に9年も勤めていたようです*1。 経緯 * 入社前 東北大学院情報科学研究科の大堀研究室にて、プログラミング言語の研究をしていました*2。 自分の研究は、関数型プログラミング言語のSML#コンパイラの内部機構とIDEの支援機能の連携でした*3。 他にも、コンパイラの中間表現をいじったり、授業やゼミでラムダ計算や論理学や並列計算や画像処理や、あれこれやっていたなぁとぼんやり思い出します*4。 学ぶのが好きで大学や大学院の授業は真面目に受けていました。 また、ゼミでは先生や先輩から知識から普段の生活まで様々なことを学ばせてもらいました。 ただ、当時はこの知識の貴重さへの認識が薄かったと思います。 しかし実務をして役立った知識はとても多く、その価値の重さを再認識しています。 * 新人研修時代 大企業らしく、半年以上の長

                                                                            退職しました - ししちにじゅうはち 4x7=28
                                                                          • ニコニコで12年運用した決済システムを移行する上で必要だったこと - Qiita

                                                                            はじめに 今日は、ニコニコのプレミアム会員サービスを支える「プレミアム課金システム」を動画システムのモノリスから切り出し、変更可能にしていった過程について書きます。プレミアム課金システムは金銭を扱うシステムですので、「(特に、失敗した)話を聞くのは面白いけど、自分で触りたくない」と思われる方も多いのではないでしょうか。 この記事では、決済にかかわるシステムでも一般的なシステム改善の方法が適用できることをお伝えしたいと思います。また、コストを抑えつつ着実なシステム改善を行う方法論としてもご理解していただけると嬉しく思います。 背景 プレミアム会員サービスについて 月額500円(税別)のプレミアム会員制度には159万人(2020年9月末現在)の方が加入してくださっており、ニコニコ事業を支える主要な有料サービスです。 ニコニコ動画は2006年にサービスを開始し、2007年にプレミアム会員サービス

                                                                              ニコニコで12年運用した決済システムを移行する上で必要だったこと - Qiita
                                                                            • 株式会社ワークスアプリケーションズを退職しました - しまたくブログ

                                                                              ※以降の文章では”ワークスアプリケーションズ”のことは'WAP'と略して表記します。 目次 はじめに なぜWAPに入社したのか WAPで何をしてきたのか WAPの良いところ・悪いところ なぜWAPを退職したのか 今後に関して はじめに 2017年4月に新卒で入社し、約2年ちょっと所属していたWAPを退職しました。 特に同期と後輩にはすごく恵まれた環境でした。 この記事を書いた理由としては、WAP退職者の”ちゃんとした”退職エントリーが無かったという点が大きいです。 現状みたいな部分は内部機密が多いに含まれるので、ザッと大筋だけの説明ですがその辺はフィーリングで感じてください。 なぜWAPに入社したのか 新卒のタイミングでWAPを選んだ理由としては、下記2点が主な理由です。 1. 同期に多様なバックグラウンドを持っている人が多かった。 (外国人、経営者、東大生、京大生、バンドマンetc) 2

                                                                                株式会社ワークスアプリケーションズを退職しました - しまたくブログ
                                                                              • ソフトウェアテストの実行を機械学習で効率化する。Jenkins作者の川口氏が立ち上げた「Launchable」で実現しようとしていることとは(前編)

                                                                                ソフトウェアテストの実行を機械学習で効率化する。Jenkins作者の川口氏が立ち上げた「Launchable」で実現しようとしていることとは(前編) Jenkinsの作者として知られる川口耕介氏は、昨年米国で新会社「Launchable」を立ち上げ、日本にもその100%子会社であるLaunchable Japanを近日中に立ち上げ予定です。 Jenkinsの登場がテストやビルドの自動化を促進し、ソフトウェアの開発生産性を向上させたことは明らかでしょう。川口氏によると、Launchableは機械学習などの技術を用いてそれをさらに前進させるものだとしています。 インタビューを行った5月末の時点で、同社は米国に6人、日本に4人と10人ほどの体制で製品開発を進めています。 果たしてLaunchableはどのようなビジョンで何を実現しようとしているのか、同社共同創業者兼共同CEOの川口氏と、Laun

                                                                                  ソフトウェアテストの実行を機械学習で効率化する。Jenkins作者の川口氏が立ち上げた「Launchable」で実現しようとしていることとは(前編)
                                                                                • 技術blogのリンクを投げたらChatGPTが要約して、いい感じに整形してチャンネル投稿してくれるbotを社内Slackに生やしたら捗った話

                                                                                  こんにちは、株式会社シグマアイのエンジニアの@k_muroです。 今回の記事は最近導入した「技術blogを良い感じに共有してくれるSlack bot」のご紹介を。 はじめに 技術の進化は止まらない。(真面目な話、AI系の進捗がマジですごいて全然追えない) 毎日のように新しい技術、フレームワーク、ライブラリ、ツールが生まれています。そんな中でエンジニアとして働いていると、この情報の波に疲れを感じること、ありませんか? ありますよね?(脅迫) 実際私もその一人で、この小さな疲れが積み重なって大きなストレスとなることに気づきました。 「新しい技術情報、追いつけるかな?」 「あのブログ記事、後で読もうと思ってたのに、どこいったっけ?」 「チーム全員が同じ情報を持ってるか心配だな。」 そんな日常の疑問や不安から逃れるための一歩として、私はあるSlack botを開発しました。このbotは、送られた技

                                                                                    技術blogのリンクを投げたらChatGPTが要約して、いい感じに整形してチャンネル投稿してくれるbotを社内Slackに生やしたら捗った話