カンファレンスや勉強会に参加して感動したり、あなたの人生を変えるような何かに出会ったことありますか?
あなたが好きだと感じたその場所が、いつか衰退して永久に失われてしまったら悲しいですよね。
しかしあなたは自身の"LIKE"を守るためいつでも行動をおこすことができます。
このセッションでは、コミュニティ運営を事例にして、自身が成し遂げたいと思った"LIKE"を実現に導くための道のりを紐解きます。
私が複数コミュニティを運営するなかでどんな困難を感じてどう乗り越えてきたかなどの経験を踏まえながら、何かを始めたり継続するために必要なマインドや行動のエッセンシャルをお伝えします。
“余白”のない開発を経験したことはありますか?
破綻と隣り合わせの綱渡りスケジュール、山盛りの要件と機能仕様、いつまでも解消されない負債、そこに発生する割り込みのインシデント対応…ぐわあああああ!
”余白” を作っておいたはずなのに、気付いたら空っぽになっていることも少なくありません。
“余白” がなければ、リファクタやテストコードのメンテナンスなどが滞って、生産性が落ちていくかもしれません。
“余白” があれば、インシデントで1日潰れても、スケジュールを引き直す必要はないかもしれません。
20%ルールのように、”余白” が非連続な成果を生み出すかもしれません。
“余白” を愛する全ての人へ
”余白” を手に入れるための戦いをはじめましょう
主なトピック
今日、OSSでも社内のインターナルなプロジェクトでも、重要なソフトウェアは歴史が長く大きく複雑で、いわゆる "レガシー" なソフトウェアが増えてきています。これらのソフトウェアは、重要であるにも関わらず、ドキュメントが不足していたり、当時は良いとされていた設計が時代遅れになっていたりするなど、様々な理由により理解するのが難しい。
すばやくソースコードを理解し分析することは、レガシーなソフトウェアにおける複雑な問題を解決したり、オーナーシップをとったり、はたまたオープンソースに貢献したり、モノリスを分解したり、あるいは未知のドメインでのコードレビューを行うときに重要なスキルとなります。
この発表では、プログラム理解に関する質的研究と、私がOSSやレガシーソフトウェアの開発に貢献してきた経験をもとに、どのように巨大なソフトウェアに対して取り組んでいけばよいのかについて紹介します。
弊社では30days Albumという写真をアルバム形式で共有できるサービスを運用しています。
これまで本サービスは独自にハウジング契約したデータセンターで運用してきましたが、GMOインターネットグループのシナジーを活かすために、グループで契約されたデータセンターへ全てのサーバを移設することにしました。しかし、本プロジェクトは期限とコストが非常に限られた中で完遂する必要がありました。また、このサービスでは4ペタバイトを超える巨大なストレージをオンプレミスで保有しており、この移設も大きな課題として立ちはだかりました。様々な手法を検討した結果、搬送業者に依頼してトラックに全サーバを載せて物理的に一斉搬送するというめったに聞かない(と思われる)手法をとりました。
本トークでは移設に踏み切った経緯、破損事故などのリスクを踏まえてどのように一斉搬送したのかお話しします。
好きなものは何かと問われても、そんなの一つに決められない。
ソフトウェアエンジニアならOSもプログラミング言語も開発環境だって好きな人は多いはず。
そんな中、マイブームを上げるならNixです。NixはOSでもあり、パッケージマネージャでもあり、プログラミング言語でもあります。
1つで3つ美味しいじゃないですか。
というわけで今回、パッケージマネージャについて話したいと思いました。
AptやHomebrewのようなシステムパッケージはもちろん、プログラミング言語のパッケージモジュールを管理するのもパッケージマネージャと言えるでしょう。PerlならCPANです。
そこで、パッケージマネージャの基本からさまざまなパッケージマネージャと、ついでにその終着点の一つともいえるNixの魅力について簡単に紹介したいと思います。
世の中にはたくさんのマイクロサービスの導入例が紹介されていますが、その中のうちどれぐらいのサービスが今も生き残り、また成長を阻害するような痛みが解消され、開発が続けられているかはあまり知られていないように思えます。
面白法人カヤックが運営するeスポーツイベント運営のためのサービス「Tonamel」では3年前からマイクロサービスを導入し、今もまだサービスの成長と機能の拡張を続けています。
導入から3年経ち、もともとあったレガシーなアプリケーションから大半の機能が、マイクロサービスで新たに実装され直した部分へと移されました。この結果、サービスとしての安定性を保ちつつ、機能実装のスピードの向上などの効果が目に見えて出てきていると実感します。
そこで、生き残ったマイクロサービスで、どうして生き残ったのかをマイクロサービス導入の当初から携わるアーキテクトである私が考察し紹介します。
「自分で管理しているシステムなら、手を加えられるけど、外部のサービスやウェブサイトはどうしても手を出せない…」こんなもどかしい経験、一度や二度はしたことがありませんか?しかし、プログラムを書くことにそれほど抵抗がないのであれば、ブラウザ拡張機能を自ら作成することが、この問題への解決策のひとつになります。
このセッションでは、ブラウザ拡張機能の開発の魅力を、実際の開発エピソードを交えて紹介します。外部サービスも、自分の手でカスタマイズし、使い勝手を向上させたり、効率を良くするアプローチを紹介します。そして、初めての拡張機能開発でも迷わないステップや、作成にあたっての考え方も紹介します。
プログラミングのスキルを活かして、ウェブの世界をもっと自分好みに、もっと効率的にしませんか?外部のサービスに自分の手を加えて、毎日の業務やブラウジング体験を向上させる方法を手に入れましょう。
みなさん、好きな言語や好きな技術はありますか? その技術を使って開発した経験は?
…働くようになってから、「技術と初めて出会った時のようなトキメキ」はまだ残っていますか?
個人開発をしたい(している)けれど、”作るものが思い浮かばない”という壁にぶつかる人も多いでしょう。
かく言う私もその中の1人です。
このセッションでは、普段ハッカソンの運営をしている私が出会った「好きなものを使って」「好きなように開発する」学生たちの事例をもとに、凝り固まった考えを捨てて開発する”お遊び開発のススメ”についてご紹介します。
Site Reliability Engineering (SRE)が近年話題ですね?SRE本が出てから早6年、既に「近年」ではないという説もありますが、ますます盛り上がってきている分野であります。
SREというロールがあるにせよないにせよ、皆さんも似たようなことは日頃やっているはずです。
他の人がどんなSRE的取り組みをしているか気になりませんか?気になりますよね?
LINE スタンプという、多くのユーザーがいるサービスで、実際に日々行っている(比較的小さな)SRE的な取り組みをご紹介します!
皆さんはUIの実装を楽しんでますか?マークアップ、Webフロントエンド、GUI、ネイティブアプリ等、ドメインや技術は様々ですが、アプリケーションには必ずUIがあり、それを実装する作業があります。このUI実装の技術についてはよく語られる一方、UI実装者のモチベーションについてはあまり語られていません。本セッションでは発表者の15年ほどUIに関わってきた経験を通して、UI実装の魅力やどのように楽しめばいいのかをご紹介します。
話すこと
対象者
「プログラミング楽しい!」という気持ちで今の世界に飛び込んで、15年以上が経ちました。何度かの転職も経て、業務で扱う言語も、流行りの技術も、様々な変遷をしてきました。また自分自身も加齢やライフステージの変化により生活スタイルなど大きく変わりました。
そんな中でも、今も昔もずっと変わらずに続けているのが「趣味プログラミング」です。
そのときそのときに興味を持ったものを題材として、自分の好きなようにコードを書き、自分の作りたいものを作る。自分だけのための「趣味」としてのプログラミングです。
ただ自分が楽しむためのものでしたが、その趣味プログラミングを通じて様々な学びがあり、出会いがあり、多くの経験を得ることができました。私のこれまでの趣味プログラミングの話、取り組むときの思考、起きた変化などを紹介し、趣味プログラミングの楽しさをお伝えし「プログラミングが好き」な仲間を増やしたいと思います。
「隙間家具OSS」は私が考えた言葉で、クラウドサービスやミドルウェアなど、システムを構成する大きなコンポーネントの間にあるちょっとした隙間をうまく繋ぐためのソフトウェア(特にOSS)のことです。
数年来、私は「隙間家具OSSを作るのが趣味です」と公言しています。そして、このような小さなソフトウェアをOSSとして開発し続けることで、ソフトウェアエンジニアとして生きていく上で、いろいろと重要なことを学べることを実感しました。
このトークでは、小さく実用的なソフトウェアを開発することを通して得られた「よいこと」をお伝えします。
株式会社はてなでは長年の運用によりPerlでのWebアプリケーション開発知見は溜まっていますが、Goにおけるベストプラクティスが定められていません。Goを採用しているチームはそれぞれで試行錯誤しながら開発を進めています。
この状況を見かねて、Goにフォーカスしたチーム横断のタスクフォース「Goサブ会」を設立しました。社内外のGo知見の輸出輸入を活発に進められるような工夫を検討しながら実施しています。
またさらにここから分離した「標準化分科会」も少人数で実施し、社内でのGo Webアプリケーション開発におけるガイドラインの設立を目指して活動を進めています。
本セッションでは「Goサブ会」および「標準化分科会」オーナーである私から、どのようにしてこれらのタスクフォースを回しているのか、現在どのような成果が出ていて今後の展望としてどのようなことを考えているのか事例を交えつつ紹介いたします。
SHOWROOMのサーバーサイドアプリケーションは、オンプレ時代のインフラを前提としたPerlのアプリケーションでした。
その後コストや運用負荷の観点から一部コンポーネントをAWSマネージドサービスへ移行したのですが、
その際さまざまな問題がありアプリケーション側の改修も含めてそれらを解決したので、
本発表ではその知見を共有したいと思います。
弊社ブログ「SHOWROOMインフラのマネージドサービス移行」の内容の一部を少し深くお話しする予定です。
今の時代、ソフトウェア無しでは事業の成長はありえません。
しかし、実際にソフトウェアを作るとなると様々なことを決める必要があります。
あのときの決断が技術的負債の根本原因になってしまった…そんな経験が自分もあります。
そこで今回は現場で技術選定を行ったり、ソフトウェアを作る時に必要な考え方やテクニックをご紹介します。
CI/CDパイプラインとは何?なんのためにやるの?
やれば何がいいことがあるの?
やりたいけど何から始めるの?
大掛かりなことはできない・・・一部だけ実装することはできないの?
というお話をします。
これからはDXの時代! なんでもかんでもデジタルにしたい! そんな波に乗っかり、私もやりたいことをやることにした。
しかしそこに立ちはだかるのは、金、人、時間の壁!
いかにわたしは社内DXをやり遂げたのか?!
実際はいまから(2023/9)やっていくので、登壇するときに詳細を話します
perldocを見ていると, 「振る舞いは未定義です」といった表現が見られることがあります. Perlには文法的には正しくて実行できるものの, その振る舞いが未定義である場合がいくつかあるのです.
このトークで改めて「Perlの未定義な振る舞い」について振り返ってみましょう. 実はこれ, 振る舞いが未定義だって知っていました?
※ タイトルは「100連発」ですが, 実際に未定義な振る舞いを100個紹介することを保証するものではありません. ご了承ください
私たちの日々の業務運営におけるSlackの役割は極めて重要であり、それは情報の伝達やコミュニケーションの場として、私たちの仕事の中核に位置付けられています。
このセッションでは、Slackを組織で上手に活用するために、私がどのようにして自社のSlackボットを開発し、日々の業務に導入したかを共有します。具体的には、
などについて紹介します。
また、これらのボットを開発・導入することで得られた具体的な利益や生産性の向上、更には仕事の進め方の変革について紹介し、最終的な目標は、皆さんが自社の業務にもこれらのテクニックを用いて、業務改革を実現するためのインスピレーションを得られることです。