PostgreSQL アップデート時のタイムスタンプ自動更新 - IT技術で仕事を減らしたい！
どうも、NIPPAです。 データベースを利用していると、最終アップデートの日時を保存しておきた場合があります。 MySQLでは、テーブル作成時に定義することで自動的に更新日時を格納してくれる機能がありますが、 PostgreSQLでは工夫が必要になります。 今回は、PostgreSQLでもデータ更新時に更新日時自動でアップデートする方法のご紹介になります。 環境 PostgreSQL Functionについて Functionの設定 Functionにトリガーを設定 Functionの削除 感想 環境 PostgreSQL10.12 PostgreSQL Functionについて PostgreSQLでFunctionの機能を使って、自動更新する方法をご紹介します。 PostgreSQLのFunction機能は、テーブルが更新された際に指定されたカラムに対して処理を自動で行う機能になります
ソーシャルゲームの価値を上げるログデータのつくりかた
はじめに 現在データ分析基盤の再構築を担当している、サーバーサイドエンジニアの小川詩織です。これまで私は4つのソーシャルゲームの新規開発・運用を経験してきました。そこでの知見と考察をまとめます。 ログデータは、調査などに必要なただの履歴という立場に置かれがちです。ですが、作業工数を大幅カットしたり、定量的な効果測定や判断ができるなど、適切なログ設計と活用により利益に繋がる施策の指針にすることも出来るものです。 ログには、コンテンツ内容により色々な種類や設計があるため、全てに共通する最適解はありません。ですが設計の指針となるべき事柄はあるので、ログの種類や活用例、設計の仕方、工夫などについて入門的な内容について一通り触れていきます。その中でログの可能性も一緒に感じていただきたいと考えています。 対象とするログと、全体像 今回はこれまでの経験が最活かせるソーシャルゲームのログのみを想定した内容
履歴テーブルについて - 一休.com Developers Blog
この記事は一休.com アドベントカレンダーの25日目の記事です。 レストラン事業部エンジニアのid:ninjinkunです。 一休.com及び一休.comレストランはユーザー向けのシステムだけではなく、店舗や一休内の管理者向けの業務システムという性格も持っています。 業務システム経験の無かった自分が一休に転職して最初に驚いたのが、DBに履歴を保持するための履歴テーブルが大量にあることでした。 そこから履歴テーブルの存在に興味と疑問を持ち、社内外のエンジニアと履歴テーブルについて議論してきました。このエントリではそれらの議論をまとめた結果について書いていきます。 履歴テーブルのパターン まず以下の図をご覧ください。 込み入った図かつ事例が一休特化で恐縮ですが、左上の起点から始まって、右のオレンジの部分が最終的な実装パターンです。 図にあるとおり、たいていのユースケースでは以下の3パターンの
データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3
初心者向けにMongoDBの基本を解説しています。 この資料は2014/3/1のOSC 2014 Tokyo/Springで発表しました 。 2015/3/3最新の情報で一部アップデートしました。 2015/7/15MongoDB ver3.0ようにちょっと修正しました。 This document summarizes a microservices meetup hosted by @mosa_siru. Key points include: 1. @mosa_siru is an engineer at DeNA and CTO of Gunosy. 2. The meetup covered Gunosy's architecture with over 45 GitHub repositories, 30 stacks, 10 Go APIs, and 10 Python ba
マイクロサービスを形式的に見てみる - Juju-62q's blog
マイクロサービスについて考えていたら疲弊したので、少し技術者らしく形式的に見てダメのものを思考から削ぎ落としたいと思った。 グラフ理論などコンピュータサイエンスの基礎を交えて話をするが、基本的には当たり前のことしか言わないと思うのでここに書くことを意識せずとも暗黙的に実践している人も多いだろう。 なお、個人の意見でしかないのであっているか間違っているかはわからないし、筆者にこの記述に反した実装を否定する意図はない。 今回は適当に書き散らかすのでかなりテイストが違うが他のブログと同一人物が書いている。乗っ取り等ではないです。 TL;DR マイクロサービスはDAGとすると考えやすいしデプロイしやすい 閉路があるなら設計を見直した方がいい DAGかどうかはサブシステムレベルでそれぞれ考えると簡単 デプロイに関係するリポジトリでは閉路がないことを意識させる設計にするといい マイクロサービスと疲弊
量子コンピューターをおうちで自作しよう！ ハッカーの楽しい挑戦 (1/2)
量子コンピューターをおうちで自作したい。足りない部品は3Dプリンターで作って、作れないものはeBayやAmazonで調達。設計はOSS（オープンソースソフトウェア）を活用すれば問題ない。助手にはときどき手伝ってくれる10歳の娘がいる。これはいけそうだ――。 「その気になれば、量子コンピューターだって自宅のガレージで作れる！」。2019年12月、ドイツ・ライプチヒで開催された「36th Chaos Communication Congress（36C3）」の講演においてヤン・アラン氏はこう断言し、自宅で現在進行中の“量子コンピューターづくり”を楽しく紹介していった。 量子コンピューター自作、まずはイオントラップ装置の研究から 量子コンピューターを設計するにあたり、アラン氏がまず検討したのは「量子ビット」をどのようにして作るかだった。量子ビット（qubit：キュービット）は量子情報の最小単位で
https://blog.animereview.jp/zero-trust-architecture/
シンジです。社内インフラを構築するとき、何を指標として設計しているか、何のために作るのか、誰が嬉しいのかを考えずに淡々と予算を投入している企業の多いこと多いこと。これから会社を作るならまだしも、既存企業は長年の蓄積があるわけです。物理機器や、買収合併の弊害、シャドーITに働き方改革推進の圧力。これらに個別的に対処することこそが無駄かつ自己満足なので、自社のインフラはどうなるべきだったのかを考えたい物です。 ITは企業にとってコアである 企業や組織運営において、ITを使うことで便利になったり、効率が良くなったりする程度の時代はとっくに終わっています。企業や組織からIT全てをとっぱらってしまうと、企業や組織が消え去る可能性が非常に高い、というか確実に死ぬであろう状態にまでITに依存しています。つまり現代においてはITはコアなのです。 情報システム部門はその重要性を理解していない 企業においての
タマホームのビジネスモデルを丸裸にする
増田に書くスレじゃない気がするが、身バレしないように、増田に書いておく。 ローコスト住宅大手のタマホームがなぜあんなに安いのか、いろいろと調べてみた結果。 知恵袋とか検討者ブログには、一部ミスリーディングな情報も散見されるので、その訂正伝票の意味合いもある。 最大の理由は３点 １．「タマルール」と呼ばれる設計制約を設け、規格化メリットを最大限追求した ２．工期が徹底的に短い(２ヶ月程度)、工期遅延しない ３．営業利益率が低い(薄利多売、業界最高利益率水準のへーベルハウス等と比較すると相当低い) ※タマの営業セールストークや検討者ブログに 「タマは大量発注しているから、その分安くなる」という説明がなされることがあるが、あれはミスリーディング。 嘘はついてないかもしれないが、タマより大量発注している積水ハウスは、なぜ高くなる？ ※「質が悪いのでは？」という懸念の声も結構あるが、調べてみると、建
グローバルサービスでのタイムゾーンとの向き合い方 - Quipper Product Team Blog
Web developer の大庭 (@ohbarye) です。 今回はタイムゾーンにまつわるお話をしたいと思います。 タイムゾーンは私が Quipper に入社したばかりの頃に最も頭を悩ませたことの一つです。入社以前にはタイムゾーンを跨ぐようなグローバルなアプリケーションの開発を全くしてこなかったので、まさにゼロから学び、考え、そしてハマりました。今でも気を抜くとハマりそうです。 入社からおよそ1年。この間に得た経験と知識を活かし、タイムゾーンと向き合うテクニックをまとめてみたいと思います。 目次 はじめに 前提 - Quipper のご紹介 難しさ 現在時刻を扱う問題 言語、フレームワークの実装 認知の問題 タイムゾーンを考慮した設計の問題 解法 基本的な考え方 デフォルトタイムゾーンを設定する PostgreSQL Rails タイムゾーンを意識した設計 タイムゾーンを意識したプログ
ドメイン駆動 + オニオンアーキテクチャ概略[DDD] - little hands' lab
DDD連載記事 なぜDDD初心者はググリ出してすぐに心がくじけてしまうのか ドメイン駆動設計の定義についてEric Evansはなんと言っているのか モデルでドメイン知識を表現するとは何か ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か 背景 ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何かの記事で、オススメしていたのはオニオンアーキテクチャでした。 今回は、オニオンアーキテクチャについて詳しく説明したいと思います。 上述の記事でも書いた通り、「ヘキサゴナル、オニオン、クリーン」の3つは、本質的には全く同じで、思想としてはヘキサゴナルで完成されているのですが、より具体的に説明されているオニオンアーキテクチャから説明を読んだ方が理解がしやすいと思います。 その後にヘキサゴナルの説明を読むと「なるほど」となって「あれ、結局ヘキサゴナルじゃん」と
![ドメイン駆動 + オニオンアーキテクチャ概略[DDD] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/08f5c6031dd21f86d259a1d9e9f6383a3180a1cb/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fl%2Flittle_hands%2F20171011%2F20171011062558.png)
今あえてDRY原則に向き合う
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
Railsアプリケーションで採用しているDBスキーマ設計ガイドライン - LCL Engineers' Blog
Webエンジニアの森脇です。 Railsアプリケーションで採用しているDB設計（スキーマ定義）について紹介します。 ※ Railsでは当たり前もの、Railsに依存していない内容も含んでいます。 前提 環境違えば、採用するルールも異なると思いますので、まずは弊社で利用している環境を記載します。 DBはPostgreSQL 9.x 開発言語は、Rails 4.x,5.xを利用 命名ルール Railsの規約に沿う命名を採用しています。DB設計にこだわりがあるメンバーにとっては、異論があるルールもあるのですが、アプリケーション開発の生産性も考慮しRailsの規約に寄り添うのがよいと判断をしました。 テーブル 動詞は使用せず、名詞とする 複数形とする 1:n のテーブル名は「単数形_複数形」 とする n:n のテーブル名は「複数形_複数形」とする カラム カラム名にテーブル名のprefixは付与し
The Twelve-Factor App （日本語訳）
はじめに 現代では、ソフトウェアは一般にサービスとして提供され、Webアプリケーション や Software as a Service と呼ばれる。Twelve-Factor Appは、次のようなSoftware as a Serviceを作り上げるための方法論である。 セットアップ自動化のために 宣言的な フォーマットを使い、プロジェクトに新しく加わった開発者が要する時間とコストを最小化する。 下層のOSへの 依存関係を明確化 し、実行環境間での 移植性を最大化 する。 モダンな クラウドプラットフォーム 上への デプロイ に適しており、サーバー管理やシステム管理を不要なものにする。 開発環境と本番環境の 差異を最小限 にし、アジリティを最大化する 継続的デプロイ を可能にする。 ツール、アーキテクチャ、開発プラクティスを大幅に変更することなく スケールアップ できる。 Twelve-F
» アダルトサイトをAWSで運用する時に信頼性と料金節約を両立する為のノウハウ | アダルトサイト制作会社
弊社で大規模なアダルトサイトの運用を行う上でのAWS利用構成を紹介させて頂きます。 利用料金を抑えたいというビジネス的な観点と、サービスを止めない為の障害回避を念頭に構成を紹介します。 関連：AWSのt2.microで月間100万PVに耐えるアダルトサイトを制作した話 この記事は技術者向けの内容になっています。 システム開発の発注をお考えの方は、こちらアダルトホームページ制作のご案内をご覧下さい。 サービスを止めない為のAWS利用構成 サービスを止めない事は弊社では2つの思想によって設計をしております。 障害を防ぐ為の堅牢な設計とする 障害が起きた時に瞬時に復旧、あるいは回避する 前者はイメージしやすいと思いますが、弊社では後者のフェイルオーバーも非常に大事であると考えています。 システム障害が起きない様にスペックを十分に確保する等は当然の事ですが、 万が一障害が発生した場合に即座に代替機
HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様
今日では HTTP(s) で API が公開されることは当たり前の時代ですが、エラーをアプリケーションにどう伝えるかは、個々の API の設計に依存していました。特に、HTTP ステータスコードは有限であり、元々持っている意味があるので、自由に使うことはできません。API はそのドメインごとにもっと複雑で細かなエラー情報があるはずで、それらはレスポンスボディに載せてアプリケーションに伝えることになりますが、その書式に規定は今までありませんでした。 HTTP API にて、アプリケーションにエラー情報を伝達するための（レスポンスボディに載せられる）標準的な形式が、RFC7807 Problem Details for HTTP APIs で定められています。適用例としては、以下のようになります。 HTTP/1.1 403 Forbidden Content-Type: application
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
