はじめまして、2021年に新卒としてSWETに加わったIKです。 今回はSWETに入って感じたこと、思ったことなどを新卒目線で書いていきたいと思います。 IKってどんな新卒？ 学生時代にVim scriptばかり書いていた新卒です。 主に、ソフトウェアのメンテナンスに興味をもち、OSSにパッチを送る活動をしていました。 パッチを送った主なリポジトリ vim-airline vim-devicons また、VimConf2019に登壇し、以下の発表をしました。 Grown up from Vim User to Vim plugin developer side しかし、一般的なWebシステムやアプリ開発には疎い、そんな状態で入社しました。 どうしてSWETへの配属を志望したのか 私は学生時代、1からソフトウェアを作ることよりも、ある程度形になったソフトウェアのメンテナンスに参加することの方

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

こんにちは、Androidチームの田熊（fgfgtkm）と外山（sumio）です。SWETのAndroidチームでは、Androidのプロダクトに対して自動テストのサポートをしています。 この度株式会社Mobility Technologiesが提供するタクシーアプリ「GO」のAndroid版に対する、おおよそ2年間に渡る取り組みが終了しました。 本記事では、この取り組みで行ってきた次の2点を紹介したいと思います。 「GO」のAndorid版に対してどのような自動テストを導入したか 開発チームに自動テストを定着させるまでにやったこと タクシーアプリ「GO」に対しての自動テスト導入 SWETのAndroidチームは「社内のAndroidエンジニアが自動テストを書くことを習慣化している」ことをゴールの1つとして、自動テストを普及させるための取り組みをしています。 その中でAndroidのテスト

大学や大学院で論文の書き方を鍛え上げた人たちには遠く遠く及ばないが、僕の様なはぐれもの1でも最近は Amazon 社内で文書の質が高いと評価してもらえるまでにはなった。Software Engineer として、コードでのアウトプットはもちろん大事だけど、文書のアウトプット(およびそれによって得られた実際のアウトプット)は同じだけ重要である2。今回は自分が最近どういうところに気をつけて技術文書を書いているのか、ということについて数年後の自分が忘れてないことを確かめられる様にまとめておく。 そもそも文書とは？ 英語だと document。ここで指す(技術)文書とは、人間が読む文体で書かれた技術に関連する情報、といったものだ。具体的に言うと以下の様なものを想定している: 新しいプロジェクトの骨子を説明する資料 会議の叩き台となる 1 枚ペラ 本番環境に変更を加えるにあたっての包括的な情報や具体

1. はじめに SWETグループの井口です（@hisa9chi）です。現在はスマホ向けゲーム開発案件にてゲーム開発者がゲーム開発に集中できるようにCI/CD関連を幅広くサポートしています。 本稿では、その中でも Jenkins Pipeline Job で利用可能な Shared Libraries に関して弊社でどのように活用しているか事例を紹介してみたいと思います。 Jenkinsと聞くとおそらく皆さんは、昔は利用していたが今は運用コストが高いなどの理由から、マネージドなクラウドのCI/CDサービスへ移行したという方が多いのではないでしょうか。しかし、ゲーム開発の現場ではJenkins master / agentのクラスタ構成を構築して、運用を続けているプロジェクトが弊社内にも多く存在します。なぜ、運用コストが高いにもかかわらず構築して運用しているかというと、ゲーム開発特有の理由から

ニッチな話題ですが、業務におけるCI/CDの現場では避けることのできない大規模リポジトリと戦うためのgit cloneのテクニックを紹介します。 この記事はDeNA Advent Calendar 2020の10日目の記事です。 CI/CDマニアの@Kesin11です。SWETではCI/CDチームの一員として、CI/CDの啓蒙活動やJenkinsを必要とするチームのサポートなどの業務を行っています。 はじめに おそらくどこの会社でも1つぐらいは巨大なリポジトリが存在しているかと思いますが、歴史あるリポジトリはgit cloneするだけで数分を要し、checkout後のリポジトリサイズがGB単位になることも珍しくないでしょう。業務で古くから存在するプロジェクトのリポジトリを触ったことがある方はきっと経験があるかと思います。 git cloneを実行するのは最初のセットアップ時だけなのであまり

はじめに SWETグループGoチームの金子 (@theoden9014) です。 弊社が運営するライブコミュニケーションアプリであるPococha（ポコチャ）においてロードテストを実施する際、Go言語を利用して独自のロードテストツール開発しました。今回は、その知見を共有したいと思います。 この記事はDeNA Advent Calendar 2020の4日目の記事です。 本記事ではシステムをWebシステムと前提としていますのでご注意ください。 ロードテストとは (Load Testing) JSTQBやISTQBにおいては性能テスト (Performance Testing) の1つと定義されています。 性能テストとはシステムテストにおける非機能テストの1つです。 ロードテスト、耐久性テスト、ストレステスト等があり、それぞれ目的に応じて実施します。 ロードテストは、システムがユーザ負荷のピー

本エントリは社会人学生 Advent Calendar 2020の19日目です。ただ今月の後半は個人的事情で非常に忙しいことが予想されるので、本日書いてしまってまだ筆の熱が残っている内に公開してしまおうと思います。 改めて自己紹介をさせてください。37歳の職業ソフトウェア技術者です。現在フルタイムで働きながら、北陸先端科学技術大学院大学（通称JAIST）の博士前期課程で情報科学を専攻しています。実は本アドベントカレンダーは去年も参加しました。そちらには進学の動機や入学したばかりの初々しい気持ちが表明されているような気がします。 fushiroyama.hatenablog.com さて、本エントリで何を書こうか少し悩みました。考えた結果、前半で「1年目を終えた率直な感想」を、後半で「JAISTで社会人大学院生をやること」について書こうと思います。特に後半には、この1年でのべ100人ぐらいに

はじめに こんにちは。富士通研究所プラットフォーム革新PJの川上です。理化学研究所/富士通が共同で開発した新しいスーパーコンピュータ「富岳」が神戸市沖のポートアイランドに納入され、当初の予定を前倒しして今年度から試行運用が開始されました。6月には早速、スパコンランキングで世界初の同時4冠(TOP500, HPCG, HPL-AI, Graph500)を獲得するなど、幸先のよい立ち上がりを見せています。私が所属する部署では富岳を始め、富岳と同じCPUを搭載した弊社製品PRIMEHPC FX1000/700上でディープラーニング(DL)処理を高速に実現する技術の研究開発をしています。今回は、DL処理を高速に実現するoneDNNというライブラリソフトウェアを富岳向けに移植し、開発したソースコードを本家IntelのoneDNNに寄稿し、取り込まれた話をご紹介します。 ディープラーニング処理のソフト

はじめに SWETグループiOSチームのkariad(@kariad_uu)です。 本記事はiOSDC 2020 Japanにて発表した「継続的にアプリのパフォーマンスを計測する」の内容を元にブログという形で改めて紹介する記事となります。 発表時のスライドは以下を参照ください。 iOSチームではiOSアプリのパフォーマンス計測に取り組んできました。 iOSアプリのパフォーマンス計測方法はたくさんありますが、中でもInstrumentsを利用したパフォーマンス計測とその自動化について紹介します。 なぜパフォーマンス計測が必要なのか？ 取り組んだ計測方法についてご紹介する前にアプリにとってパフォーマンスとその計測がなぜ重要なのかという点を説明します。 起動に時間がかかる、読み込みに時間がかかるアプリは動作が遅くユーザにストレスを与えてしまいます。 短時間で熱くなってしまうアプリでは端末が熱くて

AWS Lambdaの環境がどのようになっているか、ユーザが用意したLambdaファンクションがどんな感じで実行されるかってあたりを可能な限り詳しく説明したいと思います。 はじめに 大前提 コールドスタート/ウォームスタート コントロールプレーン/データプレーン アイソレーション AWS Lambdaのコンポーネント群 同期実行かつ初回呼び出し（コールドスタート）、もしくはスケーリング 同期実行かつ再利用（ウォームスタート） 非同期実行 スケールアップ エラーハンドリング リトライ その他 ネットワーク まとめ はじめに この投稿は2020年9月29日の21時から開催予定のイベント（ライブストリーミング）で話す内容です。 serverless-newworld.connpass.com もし間に合えば、かつ時間があればぜひライブ配信のほうにも参加ください。 （2020.09.30 upda

気がつけば 2020 年前半も終了。ひとつ大きな区切りがついたので、この半年を振り返ってみようと思う。 よく出来たこと 今年に入って 2 つの大仕事をやりきれたと思っている。 1 つ目がインフラチームのマネジャーとしてチームを作りをしたこと。 今年の頭から、難しい状況にあるチームと一緒に走ることになった。前のマネジャーとは考え方も仕事の仕方も違う中で、新しいやり方をメンバーと共に模索する必要に迫られた。 インフラエンジニアというのは、エンジニアの中でも特に職人気質が強い。はっきり言って癖があるし、人とのぶつかり方は半端じゃない。でも、こだわりを持っているし良いものを作る。そんな彼らの思いを汲み、方向を示し、底力を活かし、時にぶつかり、時に助ける。チームのひとりひとりが本来の力を発揮できる流れをつくると、自然と良い成果をあげてくれる。 辛い半年だったが、とても良いチームを作れたと思っている。

システム開発の世界において「技術的負債（Technical Debt）」は繰り返し話題になり、しばしば炎上しています。 技術的負債という概念の生みの親は Ward Cunningham （ウォード・カニンガム）です。彼は 1992 年にオブジェクト指向プログラミングの国際カンファレンス OOPSLA '92 の Experience Report でコードの初回リリースを負債に例えました（"Shipping first time code is like going into debt"）。 Ward Cunningham はソフトウェアの世界に多くの貢献を果たしてきました。Wiki の発明者であり、XP と TDD の父 Kent Beck の師匠のような存在であり、建築の世界の「パタン・ランゲージ」を Kent Beck と共にソフトウェアに輸入した人であり、「アジャイルソフトウェア開

SWETグループ、iOS自動テスト領域チームの平田（tarappo）とAndroid自動テスト領域チームの田熊（fgfgtkm）、外山（sumio）でお送りします。 おかげさまで、今年でiOS Test Nightは3周年を終えて4年目に、Android Test Nightは2周年を終えて3年目になりました。 皆様のおかげでTest Nightに登録されている資料は156件になりました。ここには素晴らしい知見が集まっています。 そんなTest Nightですが、12/16(月)に2019年最後のTest NightとしてiOSとAndroidを併せておこなったAndroid/iOS Test Nightを開催しました。 今年のTest Nightをすべて振り返りたいところですが、その中でも今年最後のAndroid/iOS Test Nightでの登壇について、SWETメンバーが軽くふりか

「S.386/H.R.1044」が何だか分かりますか いま米国で最もホットな話題（と勝手に言い切ります）、S.386/H.R.1044についてです。この話題は日本メディアでは全く報道されていないようなので、私のような素人であっても日本語で概説することにある程度価値があるのではないかと思っています。 Twitterでは悲鳴のようなつぶやきが両陣営から続々と上がっており、これは日本に住む日本人としても動向を注視せねばと思っています。 論争の中心になっているのは米国の永住権、いわゆるグリーンカードです。 今回の問題を一言でいうと、「インド人と中国人がグリーンカードをめぐって大変な争いとなっている。実は日本人にとっても他人ごとではない」ということです。 S.386/H.R.1044は、移民国籍法の改正法案を指します。 これまでの状況 ・就労ビザ（特に今回問題なのがH-1B ）を持つ外国人が米国の永

2014年にAWS Lambdaが登場し、Functionを単位としてアプリケーションを実行する基盤をFunction as a Service(以下、FaaS)と呼ぶようになった。 そして、同時にサーバーレスアーキテクチャ、またはサーバーレスコンピューティングと呼ばれる新しいコンセプトが普及するに至った。 当初、そのコンセプトが一体何を示すかが定まっていなかったために議論が巻き起こり、今現在では一定の理解に着地し、議論が落ち着いているようにみえる。 しかし、サーバーレスという名付けが悪いということで議論が着地したようにみえていることにわずかに疑問を覚えたために、2019年の今、これらの流れを振り返ってみて、サーバーレスアーキテクチャとは何かを改めて考えてみる。 サーバーレスとの個人的関わり サーバーレスアーキテクチャという名を僕がはじめて耳にしたのはAWS Lambdaが登場した2015

古来、Pythonでは「代入は文であるべき！」と一貫して主張してきました。 C言語などでは、代入は足し算や掛け算と同じ、値を計算する「式」で、たとえば a = (b=100) / 2; と書くと、b には 100 を代入し、a に 100/2=50 を代入します。1+1 は 2 という値になる 式 ですが、b=100 も同様に値が 100 となる 式 なのです。 Pythonでは、代入は式ではないので、こういう書き方はできません。 Pythonの代入は、足し算などの演算子の仲間ではなく、if や for のような制御文の仲間で、あまり自由な書き方は出来ないのです。 Python FAQ では、その理由として Python の式中での代入を許さない理由は、この構造によって起こる、他の言語ではありがちで見つけづらいバグです: if (x = 0) { // error handling } e

このブログ記事で 「MultiAZ」にしていたら何事も全て大丈夫という認識を変えられると嬉しいです （当該の時点で障害起こした人はちゃんとMultiAZにしてなかったんでしょ？という人の認識も変えられると嬉しいです）。 MultiAZにしておくことは基本 です。 その上でも、 安心しきらずに監視は必要 という話をしています。 MultiAZ構成にしておきましょう そのうえで監視、検知、トレーサビリティを大切にしましょう MultiAZ要らないという見当外れの解釈はしないでください （一部、間違えた解釈をしてるコメントも見受けられましたが、大いに違います）。 前提 2019-08-23、AWSで大規模な障害が起こりました。 障害の一般的な内容は以下のとおりです。 まとめのブログ https://piyolog.hatenadiary.jp/entry/2019/08/23/174801 AW