先日慶應義塾大学日吉キャンパスで行われた builderscon2018、最高のカンファレンスでしたね。わたしも「開発現場で役立たせるための設計原則とパターン」というタイトルで発表させていただきました。今回は恒例「実況中継シリーズ」として、プレゼンの再現をブログで行いたいと思います。 なお、過去の実況中継シリーズは前職の技術ブログにまとまっていますので、そちらからご覧ください。 それでは本編を開始したいと思います。 開発現場で役立たせるための設計原則とパターン アバンパート よろしくお願いします。 まず最初に簡単に自己紹介をさせていただきます。 先月転職をしまして、8/1からClassiという会社で働いています。妻と息子がおります。Scalaが好きですが、仕事ではRubyメインという感じです。 Web+DB PressやSoftware Designで何度か特集を書かせていただきました。と
2018年現在でもJava開発をしていると、Antすら使っていないEclipseプロジェクトにそこそこの頻度で出くわします。Eclipseの自動コンパイルが通ればOKであり、ビルドはExcel手順書をもとに手動で行われ、依存関係ライブラリはもちろんlibフォルダに各種jarファイルが放り込んであります。Eclipse上以外ではどう動かせば分かる人がいないため、コマンドラインからビルドなどを行うことは叶わず、CI化なんて夢のまた夢です。 そんなJava開発から脱却したい人向けのJava開発のモダン化ガイドです。 基本的にJava 8以降での開発を想定しています。 OpenJDK/OracleJDK上での開発を想定しています。 Android開発の場合は一部適用できない可能性あり。 英語のIDE、ツール等は積極的に使用します。 英語嫌いだとモダン化は難しい。 Java開発全般を前提としているた
アプリケーションエンジニアの多くは、眠れない夜を過ごしたことがあるでしょう。特に月に一度の…「月末締めバッチ」の日は。 そんなデータ量の多い日や、初モノのバッチが動く日でも安心して眠れるためのバッチ設計を考えてみます。 ログの設計 まず何はなくともログです。きちんとしたメッセージを出せていれば、専任の人がリカバリ可能にもなるってものです。 Audit用のログなど業務要件の強いものを除いては、だいたい3種類に分けるようにしています。 プログレスログ リカバリログ 例外ログ(調査のため) この分類でファイル単位も分けます。ログを必要とする人が、それぞれ異なるからです。 プログレスログ プログレスログは、特に長時間かかるバッチに対して、現在どのくらいまで処理が出来ているのかを目的として出力します。 トラブル発生時や、大規模移行作業時には、バッチの定期的なモニタリングと報告の必要が出てきます。「あ
最近、仕事やら趣味やらで AWS / OpenStack / GCE その他のいわゆるIaaSなプラットフォームを調査したり、いじったり、そのAPIをいじったりする機会が多かった。 この辺の運用を考えていて試したこと、ぶつかったことなどをまとめたい。 実際やったこととしては、特定のプラットフォームに依存している訳ではないが、たいていの人はAWSのアレね、みたいなイメージを持った方が読み進めやすいんじゃないかと思う。 ゴールデンイメージを雑に走らせること この手のIaaSの基本であるが、サーバーはインスタンスと呼ばれ、イメージを指定して起動する。ec2 aws run-instanceとかnova bootとかその類いである。 イメージからの起動のためには雑には大きく2要素があって、一つはイメージ自体の構築、もう一つは起動直後のそれぞれのインスタンスの特性に合わせた初期化処理のフェーズである
開発フェーズは終わり、細かい残作業の片づけと、結合試験の準備が始まりました。 で、前々から頭の中で「どうするのが楽なんだろう…」と思っていた 環境ごとにwarに含む設定ファイルをどうやって切り替え、管理するかなぁ… という疑問に着手しました。もっと早い段階から考えてやっとけよ!と自分で突っ込みつつ…恒例の「時間がなかったんです」という言い訳(^^; 色々方法がありそうですが、今回は以下のサイト群を参考にmaven-war-pluginとprofileを使うことにしました。 Apacheのサイト maven-war-pluginで設定ファイルとweb.xmlを書き換えたWarを作ってみる Mavenビルド時に開発用とリリース用でリソースを入れ替える。 TECHSCORE プロファイル 今のところ環境は少ない 設定ファイルを分ける前提となる環境は 開発用(今まではこれ) 結合テスト用その1 結
自分の担当したWebアプリケーションを引き継ぐ際に、予備知識として説明したことのまとめ 注意事項 もともと明確に定義されていない概念や、簡単に説明するため正確さを犠牲にした部分が多い 間違っていることを前提に、疑いながら読むのがベター アプリケーションの層構造 アプリケーションを構成するオブジェクトには非常の多くの種類がある アプリケーションの(より良い)構成をオブジェクト単位で考えるのは難しいので、もっと粒度の大きい単位で考えたい アプリケーションをいくつかの層(オブジェクトの所属するグループ)に分割し、層単位でアプリケーションの構成を考える View層(ビュー層) レスポンスをクライアントにとって都合のいい形(i.e. 画面)に変換する層 View層のオブジェクトは Controller層のオブジェクトから利用される DomainModel層のオブジェクトを利用して、ユーザーに表示した
先日プレスリリースが出たのですが、KAIZEN platform という会社で技術顧問などをやっています。それから、一昨日自分も出たWebアプリケーション開発に関する勉強会 (資料) を開いたじげんという会社でも少し前から同じように顧問のような形で携わっています。 自分が関わっている会社のPRも含めて、すこし、2013年現在のWebサービス開発の現場感、やり方みたいなものを書いてみたいと思う。ただ、自分の利益があるところの話だけではフェアではないので、Webエンジニアならよく知っているであろう Qiita を運営しているインクリメンツの様子も合わせて紹介する。 KAIZEN platform KAIZEN platform が提供しているサービスは planBCD という A/B テストの SaaS で、Webサイトのコンバージョンだとかを画面の構成要素を変えて効果測定したいとか、そういう
1 pixel|サイバーエージェント公式クリエイターズブログ サイバーエージェントのクリエイターの取り組みを紹介するオフィシャルブログです。最新技術への挑戦やサービス誕生の裏話、勉強会やイベントのレポートなどCAクリエイターの情報が満載です。 フロントエンドエンジニアの谷です。 本記事ではGoogle Chromeの開発者ツール、Chrome DevToolsを使いこなすために参考になるサイト、ページの紹介をします。 すでに多くのフロントエンドエンジニアが開発で使っているかもしれませんが、「要素のインスペクタなどの基本的な機能しか使っていない」「UA切り替えくらいしかつかってない」というような方や、そもそもほとんど使ったことがない、という方もこれらを参考にフロントエンド開発を効率化していきましょう! 基本的な使い方 Chrome DevTools Overview 基本はやはり公式ドキュメ
「業務ロジックをデータモデリングはどこまで表現できるか?」について考えたことをラフなメモ書き。 業務システムでは、データが命。 データには個人情報が含まれるために管理が重要だったり、売上データやPVデータから、どの層の顧客から売上やアクセスが多いのか、を計測することもできる。 すると、それらデータを格納するRDBが必要になり、そのテーブル設計が重要になってくる。 顧客の業務プロセスをモデリングする場合、最近ならOOAが主流。 でも、DOAの方が現代は重要性を増していると考えている。 例えば、Railsのような優れたWebフレームワークがあれば、ER図さえきちんと作れば、DBマイグレーションとプログラム雛形を自動生成することによって、テーブルのCRUDのような画面はすぐに作れてしまうからだ。 日本におけるデータモデリングの歴史は意外に古い。 TH法、T字型ER、渡辺さんのXEAD Model
プログラムの種類によっては、そのまま実行できるものと、実行できるようにするために「ビルド」が必要なものとがあります。Cなどのコンパイルが必要な言語で書かれたプログラムは当然ビルドが必要ですし、コンパイルが不要な言語であっても、インストーラパッケージを作るというビルド作業が必要な場合はあります。 ビルド作業の自動化のためのツールとしてmakeなどがありますが、そこまで本格的な事をやる必要がない場合は、シェルスクリプトで「ビルドスクリプト」を作るのが手軽でおすすめです。この記事では、そのような場合に役立つシェルスクリプトのテクニックを4つご紹介します。 エラーの気付きやすさとデバッグのしやすさを高める メッセージに色を付ける シェル関数をライブラリにする 一時的に作業ディレクトリの中に入る エラーの気付きやすさとデバッグのしやすさを高める はじめに紹介するテクニックは問題が発生した時に気づきや
「なぜアジャイルなのですか?改めて考察するウォーターフォールとの違い」の説明資料 http://agileucdja.doorkeeper.jp/events/1736 当日の話のビデオをyoutubeに上げて頂きました。 ウォーターフォールが何だったのかを消化しきれなくて先に進めない方や,そういう人に納得しもらう説明が必要がある方のお役にたてれば幸いです。 (1/4) http://youtu.be/uueTeig6QoI (2/4) http://youtu.be/6upGG7xpQyw (3/4) http://youtu.be/46SwtfOAWqs (4/4) http://youtu.be/tisy_98A434
デブサミ関西2012での講演内容まとめ はじめに 今月、GOOS日本語版が発売されました。 実践テスト駆動開発 (Object Oriented SELECTION) 作者: Steve Freeman,Nat Pryce,和智右桂,高木正弘出版社/メーカー: 翔泳社発売日: 2012/09/14メディア: 大型本購入: 4人 クリック: 262回この商品を含むブログ (31件) を見る継続的デリバリーに続き、高木さんと一緒にお仕事をするのはこれで二冊目です。今回も多くの人に助けられて、目標としていたデブサミ関西での出版にこぎつけることができました。関係者の皆さま、どうもありがとうございました。 講演では触れませんでしたが、ここで「実践テスト駆動開発」というタイトルの由来について少し書いておきます。原書のタイトルはご存じの通り、"Growing Object-Oriented Softwa
はじめに 「分かりやすいコードを書く」、「コードと一緒にテストも書く」等はソフトウェア開発において大切なことです。しかしそれと同じくらい大切なことして「分かりやすいコミットメッセージを書く」があります。これはあまり着目されていなく、見過ごされていることです。 今回は、コミットメッセージの分かりやすさの大切さ、そして、分かりやすくするための書き方を説明します。 コミットメッセージとその大切さ バージョン管理システムとコミット 現在、ほとんど全てのソフトウェア開発ではSubversionやGitなどのバージョン管理システムを使っています。バージョン管理システムを使うことによるメリットというのは、ソフトウェアの変更が記録されていくことにあります。 具体的なメリットは3つあります。 ソフトウェアの調査がしやすくなることです。現時点でのコードと、そして変更の履歴とを組み合わせることで、それらから非常
オペレーションとかインフラ系のエンジニアリングからは少々離れそうなので、個人的な備忘録がてら、Gitのブランチモデルについて。淡々と書くよ。 見えないチカラ: A successful Git branching model を翻訳しました 基本的に、このA successful Git branching model(上記は翻訳記事)を参考にしています。ですが、完全ではありません。運用しながら都合よく省略していますし、悪く言えば曲解もしています。あくまで、わたしが都合良く解釈して取り回した結果と考えてください。 さて、このようなドッシリとしたブランチモデルが、あらゆる規模のプロジェクトに対して有効であるかといえば、もちろんそうではありません。コツコツ個人で開発しているライブラリなどは、ブランチを使わなくても良いケースがあるでしょうし、作ってもバージョン番号ブランチぐらいのケースだってザラ
制限 同時に再生できる音源は1ファイルのみ 再生できるタイミングはユーザイベントのハンドラ内だけ プリロード不可 OS自体のサイレントモードと連動せず BGMを流すだけならこんな方法も $('<div>BGMを再生しますか?</div>').appendTo('body').click(function () { $(this).remove(); (new Audio('bgm.mp3')).play(); }); $('body').on('click', 'a', function (e) { e.preventDefault(); $.get($(this).attr('href')).success(function (html) { $('body').html(''); $('body').append($(html).find('body')); }) });
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます 【ラウンドアップ】 アジャイル開発の基本的な事項を解説。ウォーターフォール型開発との比較、契約モデル、予算策定手法に加え、旧来のプロジェクトマネジメントとの軋轢が生む様々な困難を解決する考え方も紹介。 「アジャイル開発」って何がいいの?--アジャイル開発を実案件に生かすための基礎知識 「アジャイル開発」と聞くとどんなイメージを思い浮かべるでしょうか。英語の“agile”を辞書で引くと「俊敏な、迅速な」という意味が載っています。刻々と変化する市場の要求、顧客の要求に迅速に対応していくというのが基本的なアジャイル開発のあり方です。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く