IDDD本から理解するドメイン駆動設計一覧CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。
インフラ構築をコードで自動化できる「Docker」の魅力――主婦と先生と作家をコンテナ仮想化で両立する阿佐志保さんの生き方
翔泳社では11月19日に『プログラマのためのDocker教科書 インフラの基礎知識＆コードによる環境構築の自動化』を刊行しました。今回、Dockerが大好きだという著者の阿佐志保さんに、本書の紹介だけでなくDockerに関わる人生観についてもお話をうかがいました（インタビュー内容は10月21日時点のものです）。 家事、育児、講師、執筆の両立 ――よろしくお願いします。最初に、阿佐さんの自己紹介をお願いできますでしょうか。 阿佐：結婚・出産前は、システムの基盤を構築・運用するエンジニアなどをしていました。インフラの設計構築だけでなく、アプリケーション開発標準化や運用設計など、障害やトラブル以外では表に出ることのない地味な仕事です。毎日、朝早くから終電まで働いていました。仕事が好きだったし、非常に優秀なメンバーに囲まれていたのであまり苦ではありませんでした。 分かりやすくいうと「社畜」です。社
バージョン管理システム「Git 2.3.0」がリリース、簡単にデプロイできる機能が追加
「Git 2.3.0」では、新たにサーバ上のレポジトリへ、直接変更をプッシュできるようになった。サーバ上における現行ブランチへの変更が、自動的に適用され、簡単にデプロイできるようになる。 ただし、この機能では変更履歴が保存される「.git」ディレクトリが作成されるとともに、変更の適用中は、ユーザーに対して変更前と変更後の混在するデータが提供される可能性があるため、利用にあたっては注意が必要となる。 さらに、リモートレポジトリをクローンする際に、すべてのデータをクローンせず、変更が行われたデータのみクローンすることを可能にしている。また、git pushコマンドのデフォルトの挙動を変更し、上流のブランチが指定されていない場合は、プッシュを行わないようにした。 シェル変数では、オプションを指定してSSH接続できるようにするGIT_SSH_COMMANDや、cronのジョブなどでGitを使用する
Android開発におけるクラスのおさらいと主なメソッド
はじめに 第2回目の本稿は、前回のサンプルコードをもとに、Javaの文法、特にクラスに関連する基本的な構文などを解説していきます。 対象読者 Androidアプリケーションの開発を始めたい方で、JavaとEclipseのごく基本的な知識がある方を対象とします。 HelloWorldアプリケーションのファイル構造 前回は、いわゆるHelloWorldアプリケーションを作成しました。作成といっても、ほぼソースは自動生成されたものです。Eclipseのパッケージ・エクスプローラーには、このプロジェクトで生成されたファイルが表示されています。最小のアプリケーションとはいえ、さまざなファイルが作成されています。主なフォルダ、ファイルは、以下のようになっています。 <HelloWorld> ├ \src ソースフォルダ │ └ \codezine.androidjava.chap1 │ └ Hello
F#キーワードを再定義するコンピュテーション式
はじめに 連載「C#プログラマのためのF#入門」最終回となる今回は、コンピュテーションエクスプレッション（計算式）について説明します。 コンピュテーションエクスプレッションは、F#で記述されたあるコードをどのように動作させるか独自の解釈で定義したり、他の言語に変換する機能です。F#言語構造のサブセットの意味解析を上書きするような機能と言えます。例えばwhile、return、yieldなどのF#キーワードの仕様を再定義できるのです。 関数型プログラミングのデータ制御、および副作用の管理に使用できる関数型プログラミングの機能であるモナドのF#版とも言えるでしょう。モナドと呼ばない理由は、響きが悪い（とっつきにくい）とか、副作用がF#の型システムによってトラックされない（モナドでは副作用は全てモナドにリフトされる）ようにできるところなど、小さな違いがあるからだそうです。コンピュテーションエクス
既存のデータベースでEF『コード・ファースト』を使用
先月、新しいEntity Framework 4『コード・ファースト』開発オプションについてブログ投稿しました。EF『コード・ファースト』はデータを扱うための非常に優しい『コード中心』の開発ワークフローを可能にします。それにより以下のことが可能です。 デザイナを開いたりXMLマッピングファイルを定義したりすることなくデータが扱える ベース・クラスなしのプレーン・オールド・クラスを書くだけでモデル・オブジェクトを定義 明示的な設定をすることなく、データベースの永続化が可能な設定に勝る規約を使用 初回のブログ投稿で、EF『コード・ファースト』を紹介し、新しいデータベースを作成する時のデフォルトのEF4マッピング規約の使用方法をお見せしました。これらのデフォルトの規約は新しいアプリケーションに非常にうまく動作し、データベースへまたデータベースからクラスをマップするのに明示的に何かを構成しなくても
「レガシーコード改善ガイド」のススメ 第1回：レガシーコードの定義、テストの重要性とは
「レガシーコード」とは何か 最初に1つ質問です。皆さんは、「レガシーコード」と聞いて何を想像するでしょうか？ 多くの方はCOBOLなどで書かれたメインフレームで動くコードを真っ先に思い浮かべるのではないかと思います。しかし、本当にそれだけでしょうか？ ここでは「レガシーコード」という言葉を『何年も前に誰かが作り、内容が複雑で何をしているのかよく分からず、まともな仕様書もない』というコードを指すものとします。そう考えると、必ずしもメインフレームだけの話ではなくなります。この記事を読んでいる皆さんなら、そのようなコードを少なからず目にしていることでしょう。 現在の業務システムは、Java EEや.NETなどの基盤上に構築される、いわゆるオープンシステムが主流になっています。このようなオープンシステムであっても、構築されてから既に5年以上経過していることが珍しくなく、何度も手が加えられたコードは
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Rubyで作るProlog処理系
「ドロップシャドウ」 ～マンガでプログラミング用語解説
デブサミ2015、講演関連資料まとめ
今からでも遅くない これから始めるScala（後編）