builderscon tokyo 2018 2018-09-08 10:00-11:00 @ Track-C
builderscon tokyo 2018 2018-09-08 10:00-11:00 @ Track-C
------- GND -- |01 31| -- +5V CPU A11 -> |02 32| <- M2 CPU A10 -> |03 33| <- CPU A12 CPU A9 -> |04 34| <- CPU A13 CPU A8 -> |05 35| <- CPU A14 CPU A7 -> |06 36| <> CPU D7 CPU A6 -> |07 37| <> CPU D6 CPU A5 -> |08 38| <> CPU D5 CPU A4 -> |09 39| <> CPU D4 CPU A3 -> |10 40| <> CPU D3 CPU A2 -> |11 41| <> CPU D2 CPU A1 -> |12 42| <> CPU D1 CPU A0 -> |13 43| <> CPU D0 CPU R/W -> |14 44| <- /ROMSEL (/A
OSS準備室長を務めていた ymmt (@ymmt2005) です。 過去形なのは、OSS準備室は 7 月末で解散したためです。 OSS準備室では、サイボウズ社員がオープンソースソフトウェアに関する活動を行いやすくすることを主な目的として、会社の基本方針を「OSSポリシー」という文書にまとめる作業を行いました。 完成したOSSポリシーはCC0 (いかなる権利も保有しない、いわゆるパブリックドメイン)で広く他の企業の方々にも活用いただけるよう以下で公開しました。本記事ではその内容と、サイボウズにおけるオープンソース活動のこれまでとこれからを紹介いたします。 OSSポリシー(日本語) (GitHub) OSS Policy (English) (GitHub) オープンソースについて オープンソースソフトウェア(Open Source Software, OSS)とは、オープンソースの定義に基
AWS News Blog Extending AWS CloudFormation with AWS Lambda Powered Macros Today I’m really excited to show you a powerful new feature of AWS CloudFormation called Macros. CloudFormation Macros allow developers to extend the native syntax of CloudFormation templates by calling out to AWS Lambda powered transformations. This is the same technology that powers the popular Serverless Application Model
概要 Google App Engineのフレキシブル環境にNuxt.jsのSSRアプリをサービスとしてデプロイしてみました。 Nuxt.jsはMacのDockerで開発環境をつくり、npmではなくyarnを利用、言語はTypeScriptとSCSSが利用できるようにしました。(趣味 上記を実現するのにすでに良い記事があったのですが、手順としてまとめてみました。 同じ趣味の方は大いにご参考ください^^ Nuxt.jsとは Vue.js製フレームワークNuxt.jsではじめるUniversalアプリケーション開発 https://html5experts.jp/potato4d/24346/ Nuxt.js(ナクストと読みます)はReact.jsベースのSSR用フレームワークであるNext.jsに触発されて作成された、Vue.jsベースのフレームワークです。 です。 手順 Docker環境構
こんにちは、メディア事業本部のエンジニアの@__timakin__ です。 僕が好きなGo言語は、先日バージョン1.11のリリースパーティも開かれ、wasmサポートやModules機能など、結構目新しさのある機能が足されることになりました。 で、その最新のGo界隈の話題の機能の一つとして、「Go Cloud」というものがあります。 github.com 先日のリリースパーティでも、@ymotongpooさんによってGo Cloudが紹介されていました。 docs.google.com Public Keyさんでもちょうど本日記事が公開されていました。 www.publickey1.jp Go公式のブログ告知にもあるとおり、Goのエコシステムがより良くなる過程で、多くの企業・機関で課題となった「マルチ(ハイブリッド)クラウド」へのデプロイという、ポータビリティの実現のためのAPIを提供するパ
ども、大瀧です。 内部NLB(Network Load Balancer)でFluentd Aggregatorの負荷分散構成を組んでいたところ、タイトルの制約に気がついたので共有します。 どういう制約? 図で示すと以下になります。 NLBのターゲットグループがインスタンス単位で登録するタイプの場合、NLBはトラフィックの送信元IPアドレスをクライアントIPアドレスのままターゲットに転送します。そうするとターゲットからの戻りのトラフィックの宛先IPアドレスがターゲット自身に向き、行きと戻りで経路がちぐはぐになってしまうわけです。 こんな構成にすることあるの?と思われるかもしれませんが、ECSタスク(Dockerコンテナ)のログをNLB経由でFluentd Aggregatorに送るというケースだと十分ありえるわけです。 で、本ケースについてはドキュメントに記載があり、さらに回避方法も案内さ
どうも!アプリケーション基盤チームの@yokotaso です。 単純だけど、大量のソースコードの修正が必要な場合、みなさんはどうやって修正していますか? Junit4からJunit5の移行調査をしていたときに、例外を検証する@Testの expected がJunit5では消えていることがわかりました。 社内のコードを調べたところ、修正が必要な箇所が1000箇所くらいということがわかったので、ASTを活用した自動修正ツールを作ってみました。 今回は自動修正ツールを使った大量修正の話を紹介します。 ASTとはなにか? ASTとはプログラミング言語のソースコードの構造をツリーとして表現したもです。 今回はJavaの話なので、javaparserを使って話していきます。 例えば次のようなテストコードがあったとします。 @Test(expected = IllegalArgumentExcepti
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く