OverviewDocker overview Get started Part 1: OverviewPart 2: Containerize an applicationPart 3: Update the applicationPart 4: Share the applicationPart 5: Persist the DBPart 6: Use bind mountsPart 7: Multi-container appsPart 8: Use Docker ComposePart 9: Image-building best practicesPart 10: What next? Docker concepts The basics What is a container?What is an image?What is a registry?What is Docker

仕事で外部のエンジニアに依頼したドメイン移行が正しく動作していなかったため、良い機会と思いDNSについて調べました。 名前解決の方法 そもそも名前解決とは何かというと、ドメインとIPアドレスを紐付けることです。手法として以下の2つが上げられます。 /etc/hostsに直接対応を記述する方法 /etc/resolve.confにDNSサーバーのIPアドレスを記述し、問い合わせる方法 今回はDNSサーバーによる名前解決について説明していきます。 DNSによる名前解決 ドメインツリーによる負荷分散 全世界に無数に存在するドメインの解決を一台のネームサーバーで担当するのは不可能です。そこでDNSでは下記のように、各階層に意味を持たせ、下位のドメインを管理させることで分散型の構造を構築しています。 ドメインツリー キャッシュサーバーによる高速化 クライアントからDNSサーバーに対してドメインを問い

まぁこれは基本的に膨大なログを見ている時に、ピンポイントで絞り込み検索をするという行動を前提としてるからだと思うんだけど、デバッグとかしてるときは「スゴク、コレジャナイ感…」がするわけです。 なので、そんな時はもう素直にkubectl get podsして、kubectl logs -f …. している自分がいました。 まぁこれでも充分なんです。充分なんですけど、辛い事が二つあって。 まず複数のコンテナにロードバランスされるペイロードに関しては自分が見てるコンテナにアクセスが来るとは限らないから全部のコンテナのログを見てるか、自分の見てるコンテナにアクセスが来るまで読み込み続けなければならない。 もうひとつは、開発をしている間の話なので、kubectl applyでdeploymentをガンガン入れ替えているのでコンテナもどんどん世代交代するわけです。そうすると… そう、当然コンテナはデコ

ダイキン工業が、真夏のエアコンシーズンに向け、故障やトラブルを防ぐための試運転と点検方法について案内している。例年7月にエアコンに関する故障の問い合わせや点検依頼が集中するため、同社は5月～6月前半の試運転を呼びかけている。 試運転は（1）運転モードを「冷房」に、温度を最低温度（16～18度）に設定し、10分程度運転、（2）冷風がきちんと出ているか、異常を示すランプが点滅していないかを確認、（3）さらに30分程度運転し、室内機から水漏れがないかを確認、（4）異臭や異音がないか確認、という順で行うという。 同社によると、外気温が低い初夏に試運転する方がエアコン内部に負荷がかかりにくく、製品にも環境にも優しいので適切としている。室内機だけでなく、室外機の動作確認も必要だ。 節電方法についても、（1）2週間に1度のフィルター清掃、（2）設定温度の目安を28度に、（3）室外機の周囲に放熱を妨げる障

鳥のさえずり声を聞いて、私は悪態を吐いた。今日の早朝に予定されていたミーティングのことをすっかり忘れていたのだ。 まったく、最悪の朝だ。着替えている間に、電話も鳴った。「高い金を払ってコンサルタントを雇った極めて重要なミーティングだ」と念を押されていたというのに。 それもこれも昨日のバグのせいだ。睡眠時間も、開発スキルも、人員も、私の現場には何もかもが足りていない。 それにも関らず、理解の足りない上司は「テスト工程を削ってでも早く納品しろ」とプレッシャーを与えてくる。 あの馬鹿どもめ。一体何を考えているんだ？ スーツに着替え終わった私は、冷蔵庫の缶コーヒーで空腹を誤魔化すと、バイクに跨った。通勤時間が5分なのが、せめてもの救いだ。 「遅れてすまない」 そう言って会議室に入ると、奇妙なことに気がついた。教室のように整然と並んでいたはずの机が、即席の半円形に並べ替えられていた。 何より、ホワイ

フリーエンジニアでサービス開発をしている入江慎吾といいます。 独立してから早7年。ここ2年くらいは毎月平均200万位の売上を上げれるようになりました。 この記事では僕がフリーとして独立してから、どのようにして受託開発で安定して稼げるようになったかを書いていこうと思います。（ちなみにアフィリエイトとか、情報商材とかではなく正攻法の開発で稼いでいます） 独立当初は仕事がなかったのでブログとサービスづくりに励んでました2011年に独立しました。まず、僕がやっている仕事はスマホアプリ開発、Webシステム開発、Webサイト制作の3つ。 初年度はコネも全くなくて苦労しました。それまで制作会社に10年勤めていたのですが、クライアントの引き抜きはしないように...と何もアプローチせず退社しました。 しかし、しばらくして以前勤めていた会社で取引があったクライアントが直接僕を探して問い合わせしてくれました。正

今年の1月から、90日間にかけて互いに監視しながら毎日英語を学習するという活動を行っており、先日無事完走を果たすことができたので、その感想を残しておきます。 実際の活動内容については @kon_yu さんのブログを参照ください。 konyu.hatenablog.com 前提 自分は英語力はほとんどなく、幾度か身につけようと学習を試みたものの、一向に向上しない感覚から挫折を繰り返していました。今回Facebookの投稿で募集を見つけ、これで続かなければもう身につけられることはないだろうという思いで参加を表明しました。 なお自分が振り分けられたみんチャレのグループは Maker Faire Tokyoと MashUp Award それぞれお互いを2人ずつぐらい知っているグループ Web系ソフトウェアエンジニア1 Web系ソフトウェアエンジニア2(下ネタが好きそうな人) 中国・深セン の内のW

With the advent of generative AI, AI applications are transforming and reshaping various industries and changing how people work. Software development is no exception. San Francisco- and Tokyo-based startup Autify…

はじめに ※この発言は個人の見解であり、所属する組織の公式見解ではありません 用法用量を守り、個人の責任で業務に投入してください 参考資料 2024/02/14追記 実際のテーブル設計の詳細はこちらを参考にどうぞ。 agilejourney.uzabase.com 要件 User情報を保存するときにどのようなテーブル設計を行うか 今北産業で頼む テーブルに状態を持たせず状態毎のテーブルを作る 状態が変わればレコードを消して別のtableに作る tableの普遍的な情報は別に持たせる 僕の考えた最強のDB設計 PostgreSQLをベースの雑なER図を作った。 これを元に話を進める。 table構成 users 親tableであり、すべてのユーザはここに属する。 基本はINSERTのみでUPDATE、DELETEを考慮しない。 user_detail userに付随する詳細の情報がここに登録

SREの@deeeetです。 新しい機能を素早くリリースしフィードバックを得てすぐにPivotの決定を行う、もしくはリスクを抑え小さな改善を継続的に行うContinuous Deliveryはソフトウェア開発において非常に重要です。 メルカリではこのContinuous DeliveryのためのPlatformにSpinnakerを採用し始めました。現在は主にkubernetes（k8s）へのコンテナアプリケーションのDeployに利用しており、既にいくつかの本番アプリケーションがSpinnakerによりDeployされています。 本記事ではなぜSpinnakerを採用したか、Spinnakerとは何か、実際にメルカリでどのようにSpinnakerを使っているか、について簡単な紹介をします。 kubernetes上でのDeploy問題 k8sへのコンテナイメージのDeployは非常に簡単で

2018/04/19 JAPAN CONTAINER DAYS V18.04 (https://containerdays.jp/) にて発表したものを加筆修正しました。 Abstract: Kubernetes は豊富な機能とその高い拡張性により、現実における様々なユースケースに対応できる一方、その多機能さゆえにどう使えば良いか迷っている方もいると思います。Kubernetes の基本を学んだ人や本番運用を始めた人を対象に、私がメルカリでの Kubernetes 本番運用経験を元に考えた、アプリケーション運用、インフラ運用、組織の 3 つの観点での設計の指針を紹介します。

“オブジェクト指向”の意味を本当に理解するには、この概念の始まりを振り返ることが必要です。最初のオブジェクト指向言語はSimulaという言語で、1960年代に登場しました。オブジェクト、クラス、継承とサブクラス、仮想メソッド、コルーチンやその他多くの概念を導入した言語です。おそらく最も重要なのは、データとロジックが完全に独立したものであるとする、当時では全く新しい考え方をもたらしたことでしょう。 Simula自体には馴染みがない方も多いかもしれませんが、Simulaからインスピレーションを得たとされるJavaやC++、C#、Smalltalkといった言語は皆さんよくご存知でしょう。さらにそこからインスピレーションを得たものとしてObjective-CやPython、Ruby、JavaScript、Scala、PHP、Perlなど様々な言語があり、Simulaは現在使用されているポピュラーな

前回の ブログ記事 では、Kubernetesの話と、 ThoughtSpot がKubernetesを開発インフラのニーズに合わせてどのように取り入れたかをご紹介しました。今回はその続報として、最近の興味深いデバッグ経験について少々駆け足になりますがお話ししていきます。本記事も「コンテナ化と仮想化はノットイコールである」という事実に基づいており、たとえcgroupの上限がどれも高くない値に設定されホストマシンで十分な演算能力が利用できるとしても、コンテナ化されたプロセス同士がリソースの競合を起こす場合があることを示したいと思います。 ThoughtSpotでは内部のKubernetesクラスタで 多数のCI/CDや開発関連のワークフロー を稼働させており、ある1点を除いては全てが順調でした。唯一問題だったのは、ドッカー化された製品コピーを起動すると、パフォーマンスが期待を極端に下回るレベ

（本稿は、QCon London 2016で行った講演の内容に基づいています。スライドとビデオは近日中に掲載予定です） 2014年に開催された最初のGopherConで、私は「 Best Practices in Production Environments（本番環境でのベストプラクティス） 」と題した講演を行いました。 SoundCloud の私たちはGoのアーリーアダプターで、その時点までに既に2年近く、本番環境向けの様々なGoコードを書き、実行し、メンテナンスしていました。そして私たちはいくつかのことを学んだので、その教訓をまとめ、多くの人に伝えたいと思ったのです。 それ以来、私はフルタイムでGoを使う仕事を続けています。SoundCloudではその後の活動やインフラチームで、そして現在は Weaveworks で Weave Scope や Weave Mesh の開発に使ってい

grpc-gatewayはHTTP2+ProtocolBuffer をプロトコルに用いるgRPCのサービスを、HTTP/1.1のRESTfulな JSON APIとして利用できるようにするリバースプロキシを生成してくれるツールだ。 厳密にはProtocolBuffersを処理するコマンドであるprotocのプラグインとして動作し、protocに読み込んだgRPCのサービス定義をもとにGoで記述されたコードを生成する。生成されたコードはHTTPサーバのハンドラになっていて、net/httpに登録して使えるようになっている。 ハンドラはHTTP/1.1でリクエストを受け取ると、リクエストに含まれるJSONを対応するProtocolBufferのメッセージに変換し、プロキシ先のgRPCサービスのメソッドを呼び出す。このgRPCサービスは、元にしたスキーマが同じであればGo以外の言語で実装されてい

注意 本記事は以降更新されません。 https://knsh14.github.io/translations/go-codereview-comments/ こちらに移動しました。 以前にGoを書く機会があったときにレビュアーに「俺に持ってくる前にこれを読んで直してからこい！」 と言われたので、読んだ証拠に翻訳しました。 Go Code Review Comments 原文 go fmt あなたのコードに gofmt を走らせると、自動的に機械的に直すことのできるスタイルの大部分を修正してくれます。 世にあるGoのコードのほとんどすべてが gofmt を使っています。 この文章の残りは機械的に直すことのできないポイントについて解説します。 代わりに goimports を使う手段もあります。 gofmt に加えて必要に応じてimport内に空行をつけたり消したりする機能があります。 Co

どうぶつしょうぎ AI を作りました。絶対に勝てません。無力感を味わってください。 ref: http://mame.github.io/dobutsu-shogi-master どうぶつしょうぎとは 3 マス x 4 マスの単純化された将棋です。ライオン（王相当）、ぞう（1 マスしか進めない角行）、キリン（1 マスしか進めない飛車）、ひよこ（歩相当、にわとりに成ったら金相当）の 4 種類の駒を動かして、相手のライオンを取るか、トライ（ライオンを一番奥の行まで運ぶ、ただし直後に取られる場合はだめ）に成功すれば勝ちです。詳しくは Wikipedia の記事を見てください。 どうぶつしょうぎは後手必勝であることが知られています（研究報告）。つまり、後手が正しくプレイする限り、先手は絶対に勝てません。どうぶつしょうぎ名人は常に正しくプレイするので、先手のあなたは絶対に勝てません。 なんで作ったの