はてなブックマーク

脊髄反射でやってみようと思ったことを実行に移せた時ってスッキリしますね。 gbdaitokai.connpass.com 当日の様子はこちら。 ホワイトボードチャレンジで遊んでみてる pic.twitter.com/Y31K5NqNZE— あべさん (@mao_instantlife) 2018年1月17日 二サイクル目 pic.twitter.com/l56F11J4g7— あべさん (@mao_instantlife) 2018年1月17日 ちなみに、写真の光の加減がなんかおかしいですが、レンズカバーの部分にヒビが入ってたっぽい。そろそろ替え時ですかな。。。 ホワイトボードチャレンジ is 何？ デザイナーとクライアント、タイムキーパーに別れて、お題について短時間でロールプレイするプロダクトデザインの訓練です。詳しくは今回実施のきっかけとなった下記ブログを。 blog.haiji.co

先日、このようなブログが発信されました。 aws.amazon.com この辺りのデータ環境周りを作るためのサービスは、どんな状況であっても覚えておいて損はないですし、好きなレイヤーでもあるのでちょっと触ってみました。なお、公開されているのはまだ北米リージョンのみです。 ドキュメント読みながら、使いながらメモ書きしてたらある程度のボリュームになったので、一旦区切って出します。 参考リソース なんにせよ公式リソースが一番ですので、迷ったらここに当たってみましょう。 docs.aws.amazon.com サンプルや各種ライブラリのリポジトリもすでに作られています。今はまだ少ないですが、これから充実して行くことを期待しています。 github.com github.com AWS Glue is 何 AWS上のフルマネージドなETLです。ETLはextract, transform, and

前回、全体像を追いかけてクローラを実行するだけで結構なボリューム行ってしまったので続きです。 mao-instantlife.hatenablog.com 今回は右から左に流すジョブを作ってみるのと、その過程でわかったことを何点かまとめておきたいと思います。 Webコンソールからジョブを作る ソースもターゲットが単一で、単にマッピングの変更があるレベルであればウィザードから作成するだけでジョブが作れます。下図のように、ソースもターゲットもウィザード上はラジオボタンなので、ソースやターゲットが単一でないようなレベルのジョブを作りたい場合は、メインのソースやターゲットのみ決定してテンプレートとして作った後でソースを編集するなどの方法を取る必要があります。 ちなみに、ジョブの全般的な設定でTemporary directoryの入力が必須なんですが、デフォルトでは何も入力されていません。スクリプ

前々から興味があったので、開催を聴いてメンターとしてお手伝いさせていただきました。お手伝いできてよかったな、と心から思えるイベントだったので、熱が冷めないうちにブログに起こしておきます。 CoderDojoとは？ coderdojo.jp 子供のためのプログラミング道場です。塾とは違うので、決まったことを教える場ではありません。あくまでやりたいことを支えてあげる場。メンターは教えるというより一緒に考える人、といったスタンスで子供にお付き合いします。 で、岡山で立ち上がったのが、CoderDojo 岡山岡南です。 coderdojo-konan.media-interesting.info メインで動いているのが、なんと中学生ですよ。これがまたしっかりしてて、将来が楽しみです。大人になって有名なエンジニアになったら「こいつは俺が育てた」的な老害になりたいので、これからもご活躍を期待しておりま

SpringBoot 1.4が対応したみたいなので、これから先に予定している機能のこともあり、用途の検討も含めて少し使ってみました。なお、SpringBootからの利用ではなく、Neo4Jそのものの検証です。 そもそもNeo4Jとは？ 大体以下から大まかに抜粋。 neo4j.com Neo4j - Wikipedia レコード(Neo4J的にはNode)と関連のグラフ構造でデータを表現するグラフデータベースです。データ構造がリレーションモデルではないので、当然系譜的にはNoSQLなわけですが、他のNoSQLとは違ってKeyValue形式ではないのが特長です。 で、他のグラフデータベース(ぶっちゃけ他に何があるか知りませんが)と違うのは、 ACID特性をフルサポート トランザクションがある インデックスがある といったあたりで、Enterprise Editionの可用性とともに、この辺結構

本当は玉川さんの基調講演を岡山の人にも聞いてもらいたかったので、岡山サテライト開催しようと思ったんですけどね。なんかサテライト開催の挙手のタイミングが全くわからないまま、妻の入院やらバタバタしてたらいつの間にか時期を逃してしまっていましたとさ。 結果として、高松サテライトに行ってよかったです。他のコンテンツも当然よかった中でこんなこと書くのは本当に心苦しいのですが、私にとっては平鍋さんのセッションをやっと生で聴けたということに尽きます。大体この辺の反応を見ていただければ、その大きさがお分かりいただけるのではないかと思います。 プロジェクトファシリテーションの資料は今の仕事の原点 #ajtakamatsu— あべさん (@mao_instantlife) 2016年6月25日 どういう環境、制約の中ででも、前よりもチームやプロジェクトを良くすることはできる。望む世界ではないけど、それに近づく

PMJPでレビューに手を挙げて、著者のお一人である川畑雄補様よりご恵贈いただきました。 スマートフォンアプリマーケティング 現場の教科書 作者: 川畑雄補,丸山弘詩,荻野博章出版社/メーカー: マイナビ出版発売日: 2016/06/01メディア: 単行本（ソフトカバー）この商品を含むブログを見る より深い理解は、会社に持って行って仕事で使いながら得ていかないといけませんが、まずは通読しましたので、ご紹介いたします。 私の背景 まずは、私がどういうポジションでこれを読んで、所感を書いているのか、評価の上で重要な項目だと思います。これを整理しておこうと思います。 エンジニアからチームのマネージャ、プロダクトマネージャというキャリア エンジニアのキャリアはサーバサイド中心 初めてのプロダクトマネージャ現在進行形 担当プロダクトはWebサービスからスタート予定 アプリ化は未定 というところです。つ

または私は如何にしてプログラミングをするのをやめてマネジメントを愛するようになったか。 すみません、言いたかっただけです。 engineer.crowdworks.jp このポエムは、上記記事ではなくブクマの反応を見ての感想です。皆さんマネジメントお嫌いなんですね。まあ、タイトルはこのもにょりに対する煽りが少しだけ入ってます。 それと、マネジメントと一口に言っても対象によってアプローチも醍醐味も違うと思うので、ここはチームのマネジメントに絞って話をします。 マネジメントの面白さ チームで仕事をすることって、私のように圧倒的クリエイティビティの欠如を劣等感にしている人間にとっては、クリエイティビティを発揮して貢献していくためのほぼ唯一の手段なんですよ。自分の働きかけでチームがより力を発揮できるようになって、チームが想定もしていなかったようなハイパフォーマンスを発揮し出す瞬間は本当に見てて楽し

まあ、サービス開発でなくともいろんな人がプロジェクトに関わります。受託だとむしろこの辺は最初にガッチガチに決められてしまう分楽なのかもしれませんが、社内だと「とっ捕まえて話しゃいいんだから」となって少し雑になっていた気がします。 ただ、ポジションによって、結果を求めるまでのタイムスパンであったり、求められる判断をするための情報であったりが違うので、情報の見せ方をコントロールしないと伝わらないな、と思って関わる人が少ないうちに整理しました。 とりあえずこんな感じ 汚い絵ですみません。最近、図で描き起こしてみると理解が早いことに気づいたので。 この流れは、以下二つの仮説に基づいています。 あまりにすべての情報が一元的にありすぎると、ノイズが多くなってきて正しい判断ができないのではないか？ 情報のフォーカスは現在被っている帽子によって変わるのではないか？ なので、それぞれのポジションのために適切

我が社の(元)jenkinsおじさんがCircleCI推しなので、ちょっと調べてみることにしました。今更かよm9 という突っ込みは甘んじて。 なお、今回はプロジェクトの構成側に問題があって、まだCircleCIには移行していません。検証内容のまとめです。 何のために 私のチームの技術基盤はJavaやC#です。特にJavaの場合は静的解析ツールが結構充実しており、ビルド時などに様々なメトリクスを取ることができます。レポーティングプラグインもあるし、この辺りはjenkinsの方がまだ優位性があるのかなあ、と思ってました。ちなみに現状レポートが出るようにしてあるのは以下について。 Jacoco(テストカバレッジ) CPD/PMD(コード解析) findbugs(バイトコード解析) まあ、常に見たい訳ではないです。当面は週次のチームミーティングなどでメトリクスを確認して、危ない所がないかどうか位は

タイトルだけで何をやったか想像がついた方はお疲れ様でした。とりあえずなんだかんだはまりながらたどり着いたので、もっとできる人からもっと効率の良いやり方のまさかりが飛んでくることを期待しつつ。 背景 Webアプリケーションとバッチで構成されるサービス Web側についてはアクセス数に応じてスケールさせやすくしておきたい バッチはデータ量が極端に増えないのであまりスケールを考えなくてもいい どうせ同じEntityモデルとか使うしWebとバッチでリポジトリは分けたくない 一応、Webアプリケーションとバッチはdocker(でなくてもいいけど)でスケールしやすい構成にしようかと思っています。 で、Webアプリケーションは複数だし、バッチもあるし、必ずしも両方リリースする戸言うことは考えられないし、デプロイ時にDDLのauto-generateやってしまうのはあまり得策ではないなあ、と思ったので、マル

基本的に内容は同意するし、どれもいい方向に向かうための記事であまり空気に水さしたくないので、記事を個別にあげることはしませんが、管理という言葉の使い方が自分と違ってもにょったのでちょっとまとめてみます。 管理なくなってねーじゃん あの手の記事を読むたびにいっつも心の中で入れてるツッコミです。どの記事を見ても、管理をマネージャだけがするものではなく、組織(チーム)のあまねくレベルに管理が行き渡るようになってるんですよね。結果、マネージャがやらなきゃいけないことの要求は上がっていくわけですが。それを継続していく、という面ではあまり多くの記事が出ていませんが、作り上げられた組織の状況としては非常に良いと思います。 で、なんでこの手の記事で「管理をなくした」という表現のなるか考えて出た結論が、「管理と指示統制を混同している」のではないかということです。 管理と指示統制は違う 管理とはある目的を達成

先日からdockerとdockerホストをハンドリングして保守部門を巻き込んで運用体制できないかなあ、と考えて作り始めたツールがあるんですが、それを完全にいらない子化してくれそうなサービスを見つけたので、期待を込めてお試ししてみることにしました。 なお、2015年11月3日現在、まだベータ版でプロダクション環境への適用は推奨されていませんので、これを参考にする方も検証のみにしておいてください。 Tutumとは？ 何て読むんでしょうね？タタム？ japan.zdnet.com 上記記事を読む限り、以前からあったサービスをDockerが買収したようですね。不勉強で全く知りませんでした。DevOpsチーム向けのDocker分散アプリ開発と管理の利便性を追求したサービスのようです。まさに私が作ろうとしているツールと同じ目的を持っています。期待に胸が膨らみます。 準備 サインイン 利用にはDocke

最近、会社で使うツール類のコードを書いていて「シェルでやれよ」的な処理に出くわすことが多いんですよ。ファイル操作やら外部コマンドの実行やら。で、シェル書いて、というのも考えるんですけど、永続化とか処理そのものの構造化とか考えるとプログラミング言語でできる限り書きたい。自分がある程度まともに使える言語の中で一番その辺の処理が楽そうなのがScalaなので、最近はScalaばっかり使っています。 とはいえ、Scala(というかJava)のファイル操作や外部プロセス実行のAPIがイケてるかというと、まあそういう訳でもないですね。ちょっと冗長というか。 そういう面もあって、中々「シェルでやれよ」的な処理を書くのがおっくうだった訳ですが、今日見つけた「Ammonite-Ops」というライブラリがかなり理想的な使い勝手でした。軽く使ってみた感触をまとめてみます。 Ammonite-Opsとは Scala

Dockerおじさん業はまだまだ続きます。理想のかっこいいデプロイ環境を作りたいんですよ、こんてぃにゅーあすでぷろいですよ。 Docker Composeを使うとコンテナのスケールは簡単にできる訳ですが、負荷分散の面でいうとホスト自体も分けてスケーリングしたいところです。Dockerが提供するツール群には、Docker Swarmという複数のホストをあたかも一台のホストのように扱うためのツールがあります。Docker Swarmで管理している複数ホストにDocker Composeでコンテナをスケーリングし、フロントはリバースプロキシとして機能するnginxでロードバランスするという構成を試してみたいと思います。今回のゴールは以下のような構成です。 Docker Swarmで複数ホストを連携させる Docker ToolboxまたはDocker Machineをインストール済の場合は特に新

こんにちは、Dockerおじさんです。前回こんなことをやりました。 mao-instantlife.hatenablog.com 今回はこれの続きで、Docker Registryを使ってイメージのやり取りをやってみたのでそのまとめです。 やりたいこと すごく雑な絵ですが、こんな感じです。 社内ツールとして使うアプリケーションもあり、展開する自社サービスもあります。どちらもDockerでインフラ構成を一元的に扱いたいのですが、扱ってるデータの関係上社外にアクセスしてはならないサーバもあるわけです。これらのサーバとイメージをやり取りするためのDocker Registryを社内に作ってしまえば良い、という訳ですね。 ちなみに、DockerのコンテナイメージをRegistryに対してpushやらpullやらでやり取りする場合はsshでアクセスします(当然ながら)。社内で作ったサーバには当然認証

こないだこういうことをやりました。 mao-instantlife.hatenablog.com 結論として、環境変数SPRING_PROFILES_ACTIVEをセットすれば良いんじゃないかという所までは行きましたが、まだまだ事故りそうで怖いですね。サーバへの環境変数設定を忘れたり、間違えたり。現在の所は、私が扱っているプロダクトは、アクセス数も限定されているものが多いので大きな問題にはなっていませんが、デプロイやスケールアウトが容易な(自動化しやすい)状況を作っておくにこしたことはありません。 この辺り、dockerを使って楽にならないかと考えていて、ちょっと試してみたのでまとめておきます。 必要なツールのインストール docker-machine docker-compose VirtualBox5をインストールしている人は、docker-machineのインストールで注意が必要です

公開されている良い方法をパクるのに遠慮はしません(少しは遠慮しろ。 先日よりこれを取り入れてみました。 背景 細かいプロジェクトが多い プロジェクトは並行する 多くの人に手伝ってほしい局面があったりする 上記の様なチーム状況で、各プロジェクト間でサポートの調整したりするために、以下の観点で状況を把握したいと思いました。 今、各メンバーが何を担当しているか？ 今、注力すべきことに注力しているか？ モノは？ プロジェクト名とかメンバー名とか出せない情報もあるので、ごめんなさい。やってることは上記スライドと一緒で、デザインが違うだけです。 何で作ってるの？ Keynoteです。アイコン画像やパーツなどをそろえておけば、特に自動化とか考えなくても良い手間だと思いますよ。というか、更新するという行為の中で状況が把握できるということもあるので、このくらいだったら私が手で更新すべき、と思ってます。 更新

Spring Bootでプロファイルごとに異なるDBMSを使うように接続情報を分ける、プロファイルごとのhibernateの初期設定を変更する、ということをやったので、備忘録的にメモ。 背景 既存にある別のプロダクトのデータを取得するREST APIを作り始めたのですが、プロダクトが利用するDBMSはSQLServerで、既にデータベース自体は構築されています。また、私の開発環境はMacなのですが、テストコード動かしたりローカルで動かしたりする場合にいちいちサーバ用意したりするのも何か手間です。 そのため、ローカルで開発している段階では、h2辺りをインメモリで使えるようにしておきたかったというのが主な理由です。ただし、デプロイ時に設定ファイルとか構成をごにょごにょしてしまうのも事故の元なのでなるべく避けたい。環境を指定して実行すれば、勝手に切り分けてくれる、というのを今回のゴールにしました

みなさん、チームでふりかえりしてますか？私生活は恥が多すぎてふりかえれない私ですが、チームでは定期的に(なるべく)ふりかえりをするようにしています。というか、今のチームを担当させてもらう上で、一番最初に実施することを決めたのはふりかえりです。 先日のポストに味を占めたので、前職も含めて何度かチームに対するアクションをしてきた中でなんとか自分でもモノになってきた感のあるふりかえりについて少しまとめてみようかと思います。今のチームで気をつけたことですが、だいたい毎回同じようなアプローチで行っています。 なお、やっているのはシンプルにKPTです。 「とりあえず生」くらいの感覚で始められるふりかえり 現チームに限らず思ったことですが、チームの状態を良くする、改善するとなった場合にまず始めると良いのがふりかえりです。そう思う理由は以下の4点。 準備にほとんどコストがかからない コミュニケーションがと

本家のドキュメント(Leveldb)を翻訳してみました。 長文をちゃんと最後まで訳しきるのは大学入試以来で、えいや！でニュアンスのみにしている所もあります。 また、誤訳や私の理解が追いついていないところなどもあると思いますので、その辺りは指摘していただけるとありがたいです。 前回の記事で宣言したソースは、よくよく考えてみるとJNIのReadmeのサンプル以上のことはしていないので、公開してもあまり役に立たないことに気づきました。 なお、サンプルはC++のまま記載しています。 では、以下に訳したドキュメントを。 leveldb levelDBは永続的なキーバリューストアを提供するライブラリです。キーと値は任意のバイト列です。ユーザ定義の比較関数に従ってキーバリューストア内のキーを順序づけられます。 データベースの開始： levelDBデータベースはファイルシステムのディレクトリに一致する名前

まあ、参加してきたといってもオンラインミーティングで家から参加したんですけどね。 オンライン形式のミーティングが果たしてうまくいくか、という懸念もありましたが、その部分の心配はなかったようです。むしろログが残る上にちょっと時間をおいてからその話題に戻ったりも楽なので、あーだCoderのように議論が発散しやすい勉強会ではありではないかとも思いました。それと、音楽聴いてテンション上げながら勉強会に参加できるのも嬉しかったり*1。 すごく良い議論ができて、楽しかったのでそれが皆さんにも伝わればいいなあと。 あーだCoderについて 先日のエントリでも軽く触れましたが、モデルとコードのあれこれについて実践に基づいた議論をするための勉強会です*2。 設計からコードまでを対象としていますが、その背景として書籍の内容について追いかける一般的な形の勉強会だと、抽象的な一般論の話になってしまい(仕方のないこ