データモデリング・テクニック
4. いろいろなデータモデリング手法 標準的なモデリング手法が存在するわけではない Peter Chen記法：ER図の元祖（だが使われない） THモデル：椿正明／穂高良介 IE (Information Engineering) 記法 IDEF1X (Integration Definition) 記法 T字型ER：佐藤正美 三要素分析法：渡辺幸三 UMLクラス図：オブジェクト指向設計 4 記法や詳細は異なるが、基本は通底している それぞれの方法論は必ずしも排他的ではなく、学べることも多い 5. IE記法 どの記法を使うべきか IDEF1X か IE記法（鳥足）が一般的 今となっては「UMLクラス図」が一番いいかも 誰でも知ってるし、わかりやすい 機能が多いことより、みんながわかる／知ってることが重要 この資料ではUMLクラス図を使うことにする B CA D
Javaエンジニアに知ってほしいRDBアンチパターン その3 について話して来た #jjug_ccc - そーだいなるらくがき帳
Javaの国内最大カンファレンス、JJUG CCC 2017 springで登壇してきました。 僕の中で先週のオープンセミナー岡山の熱がまだ収まらぬ中の登壇だったのですが、多くの方に聴いていただけて嬉しかったです！ その時の資料がこちら。 RDBアンチパターンについてはPHPカンファレンスやYAPC:Kansaiでも話をしましたが、今回は別バージョンです。 soudai1025.blogspot.jp soudai.hatenablog.com あのときはWeb系の人向けに話をしましたが、今回はエンタープライズな業務系の人向けです。 業務系は僕の印象では制約だったり、RDBの機能を有効活用してる印象があるのですが、逆に過剰になっていることが多い印象があります。 また論理IDなどデータ量が少なかったり、アプリの改修が少ないから死ななかっただけの設計も多く見られる印象です。 そういう点を今回お
JJUG CCC 2017 Springで論理削除フラグをどうにかするための話をしてきました 【FOLIOスポンサー】 - itohiro73’s blog
JJUG CCC 2017 Springで、「データ履歴管理のためのテンポラルデータモデルとReladomoの紹介」という話をしてきました。 データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3 from Hiroshi Ito 今回の登壇は、株式会社FOLIOのスポンサーセッションです！FOLIOについてはこちらの入社エントリー記事もご参考ください。Toggetterは下のリンクから。 togetter.com 世の中のみなさんが「論理削除フラグ」を使いたくなるモチベーションとしては、実は「削除」ではなく別のビジネスロジックを実装したいだけであることがほとんどだと思います。 たとえば論理削除フラグという名の死亡フラグ - @ledsun blogというエントリを参考にさせていただくと、下記のような要件の例があります。 ・社員が退職（・転
オフラインファースト的なGUIアプリケーションをScala.jsで書く話 / Scala.jsについて - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
はじめに オフラインファーストへの要求 近年、オフラインファーストというか、「オフラインのときにも普通につかえて、オンラインになったら同期する」みたいなことに対する要求が高まっているように感じます。 その場合は、ローカルにもきちんと永続データを持っておき、オンラインのときにバックエンドと通信をしながらバックエンドのデータと同期していく、というスタイルを考えるのが自然だと思います。 また、普通のJSアプリケーションであっても、「サーバーに投げる際に失敗したデータはローカルでメモリ上にもっておいてリトライしたい」などの要求もあるでしょう。 さらに、ここでモバイルアプリも視野に入っているとなると、どうしても「オッRealm Mobile Platformか！？」という感じが出てきますが、Realm Mobile Platformにロックインされるのと引き換えに開発の速を選ぶのか、それとも、という
スタートアップが陥る「仕組み化」の落とし穴 - 株式会社SCOUTERのCOOが人事を尽くして考えた
加速する仕組み化の流れ 最近、仕事の生産性の話題が多くなり、それに伴い「仕組み化」に関するナレッジも多く世の中に共有されるようになってきました。スタートアップだとメルカリさんやwantedlyさんあたりがナレッジをたくさん公開しています。 www.supporttimes.com www.wantedly.com リソースの少ないスタートアップにとって、いかに無駄な時間を減らすか、仕組み化によって業務を効率化するかは成長角度の重要な要素、ひいてはビジネスそのものの利益率に大きく関わってくる重要な要素です。SCOUTER社でもサービスをリリースして一年がたち、この「仕組み化」に非常に力を入れております。CS・営業・マーケティング領域では続々と仕組み化を進めています。その中でも特に対人の仕事が多いCSの部門ではどれだけ仕組み化が上手くできるかがとても重要になってきております。 CSが陥る仕組み
WebRTC 1.0 に向けたロードマップ | blog.jxck.io
Intro Google の Product Manager である Huib Kleinhout が、 disscuss-webrtc の ML に以下のような投稿をした。 Completing WebRTC 1.0 WebRTC 1.0 を年内に終わらせるためのロードマップ(Chrome の改善を含む)を提示している。 このロードマップに期待を寄せ、簡単に現状を振り返りつつ紹介する。 Completing WebRTC 1.0 2015 年の TPAC あたりで、すでに WebRTC 1.0 を 2015 年内に完了する目標は掲げられていたが、結果諸々の問題を解決し切れず 2017 年を迎えた。 しかし、今回の投稿では、いよいよこの作業に終止符を打つためのロードマップが挙げられている。 WebRTC の現状 先に現時点の問題について整理する。 WebRTC は主に、 IETF が策定す
冗長化の難しさとNetflixの答え｜こんぴゅ
この世には、ダウンすることが許されないシステムが存在する。金融機関の基幹系、原子力発電所や鉄道の制御システム、流通業の物流管理システムなどはもちろんであるが、最近ではtoCのサービスでもダウンタイムが長くなると大事件として騒がれ、ヤフトピに載ってしまったりする。 ではダウンへの対策はどうするかというと、いくつか手法はあるのだけど代表的なのは「冗長化」である。簡単に言うと、全く同じシステムを裏側に待機系として用意して、有事の際は自動的に切り替わるようにしておくのである。素朴だが、殆どのシステムではこの種の仕組みを用意している。 それでうまくいけばいいのだけどじつは、この待機系への切り替えというのは鬼門であり、高確率で失敗する事になる。 ［続報］東証のシステム障害、原因はハードウエア故障後の切り替えミス http://itpro.nikkeibp.co.jp/article/NEWS/2012
「ノーアジェンダ・どうしましょうか会議」の傾向と対策 - UNIX的なアレ
wadap.hatenablog.com 先日、こんなエントリーを書きました。割とエンジニアやデザイナーの方は経験したことがある会議ではないでしょうか。このワードに反応されていたので、少し掘り下げてみたいと思います。 「ノーアジェンダ・どうしましょうか会議」とは もうこの名前に全てが詰まってはいるので、経験したことがある人はすぐにわかるとおもうのですが、以下の点が揃っているとまさにその会議かと思います。 アジェンダが用意されていない とりあえず関係がありそうな人を呼ぶ 会議が始まり次第「どうしましょうか」的な空気が流れる ダラダラ長い 丸投げ感満載 というところでしょうか。会議そのものに主催者側の専門性があるものでは起きづらいのですが、自身が理解できない or 経験の無い領域の話になるとわりとこういう会議になりがちなのかなと思います。 会議の傾向 そしてこの会議が始まり「どうしましょうか」
Open-source tool that uses simple textual descriptions to draw beautiful UML diagrams.
🌱 PlantUML at a Glance 🚀 Getting Started PlantUML is a highly versatile tool that facilitates the rapid and straightforward creation of a wide array of diagrams. Utilizing a simple and intuitive language, users can effortlessly draft various types of diagrams. For a detailed exploration of the language's capabilities and syntax, please refer to the PlantUML Language Reference Guide. If you are n
JSON Feed
We’ve updated the spec to version 1.1. It’s a minor update to JSON Feed, clarifying a few things in the spec and adding a couple new fields such as authors and language. For version 1.1, we’re starting to move to the more specific MIME type application/feed+json. Clients that parse HTML to discover feeds should prefer that MIME type, while still falling back to accepting application/json too. The
Rubyによるデザインパターン5原則 - Qiita
概要 改めて基本を学ぶ。 Rubyによるデザインパターン第1章。 デザインパターンとは プログラミングにおいて繰り返し現れる問題に対する、適切解のパターン。 無駄無く設計されたオブジェクト指向プログラムの実現をサポート。 パターンとしてカタログ化されていることで 車輪の再発明を防ぐ デザインパターンの根底にある5つの考え 変わるものを変わらないものから分離する プログラムはインターフェイスに対して行う（実装に対して行わない） 継承より集約 委譲、委譲、委譲 必要になるまで作るな（YAGNI） 変わるものを変わらないものから分離する ソフトウェアの仕様には必ず変更が加わるもの。 変わるものと変わらないものを分離しておくことで、 「仕様の変更」に対して「システムの変更」を出来る限り局所的にする。 プログラムはインターフェイスに対して行う（実装に対して行わない） 可能な限り「一般的・抽象的なもの
Ruby で Visitor パターンをあまり使わない理由，Ruby で Visitor パターンを使うとき
Ruby で Visitor パターンをあまり使わない理由，Ruby で Visitor パターンを使うとき 答: Java/C++ で Visitor パターンを使うときに得られるメリットと比べて，Ruby で Visitor パターンを使っても得られるメリットが小さいため Ruby と Visitor パターンVisitor パターンは，GoF 本として知られるオブジェクト指向における再利用のためのデザインパターン(改訂版）の p.353 で紹介されているパターンである．このパターンは メソッドを加えるオブジェクトのクラスに変更を加えずに，新しいメソッドを定義する ことを目的に利用される．しかし，私は Ruby では Visitor パターンをあまり使わない．この文書では，その理由を書いてみる．この文書は Visitor パターン自体の解説ではないので，Visitor パターンについて
DI（Dependency Injection）に関するメモ - Shin x Blog
PHPの現場 にて、DI 談義を行うので、頭を整理しておくためのメモです。 DI についてきちんと知りたいのであれば、参照に挙げたリンク先に有用な記事があるので、そちらを参考にして下さい。 PHP を念頭に置いてますが、Java など他言語でも大枠は同じだと思います。この内容は、いずれ整理するかもしれませんし、そのままかもしれません。 DI という言葉 「DI」が差す意味合いが、依存オブジェクトの注入だけなのか、DI コンテナによる注入を含んでいるのか、DIP まで意識しているのかが、人やコンテキストによって違っていそうで、そこを揃えてから議論しないと。— Masashi Shinbara (@shin1x1) May 19, 2017 DI について話す時に、何を差すのかが異なると話が噛み合わない。そこで、それぞれに名前を付ける。 DI パターン = 依存オブジェクトを注入することを差す
Visitor パターン再考 - Qiita
オブジェクト指向 Advent Calendar というものを見つけたので、Visitor パターンについて書いてみます。 嘘です Visitor パターンについて書きたいけれど、Java Advent Calendar は埋まってしまってるので、それっぽい Advent Calendar に参加しただけです。別に Advent Calendar に参加しないといけない決まりなんてないんですけど。 デザインパターン Visitor パターンとは、デザインパターンの一つです。 そもそもデザインパターンとは何かというと、1995 年に Gamma らが "Gang of Four"、俗にいう GoF で提唱した、オブジェクト指向プログラミングによって特定領域の問題を解決しようとする際に頻出するイディオムのようなものです。 GoF で提唱されたデザインパターンは多くありますが、1995 年に発表
その事例だとコメントは不要だと思います - erukitiのmiscなやつ
「正しく書かれたソースコードにコメントは必要ない」なんて幻想だという話 - 土屋つかさのテクノロジーは今か無しか および 「正しく書かれたソースコードにコメントは必要ない」なんて幻想だという話（補足編） - 土屋つかさのテクノロジーは今か無しかで、計算式の意図を説明するためにコメントを書こうぜという主張が書かれてますが、この内容だと全く賛同できませんね。別にコメントを全否定するわけではありませんが、この主張の例だと不適切です。 //フェードインが未完了の場合 if (alpha < 1.0f){ //処理A } 元記事の主張は、alpha < 1.0f という計算式はコメントなしでは本来の意味であるフェードインが未完了の場合、というものがさっぱりわからないということでした。つまり意味情報の欠落を問題にしています。 const isFadeinCompleted = () => alpha
PHPの連想配列は常にin_arrayより速いのか - hnwの日記
プログラムを書いていると、入力値が辞書に含まれているかを調べたいようなことがあります。たとえば、ユーザーに都道府県名を入力させて、それが正しい都道府県名であるかどうかを調べたい、というようなことがあるかもしれません。 このような内容をPHPで書く際、キーに都道府県名を持つような連想配列を作る習慣がある人は多いはずです。これは典型的な連想配列の使い方といえるでしょう。 <?php $prefs = array( "北海道" => true, "青森" => true, // ... "沖縄" => true, ); if (isset($prefs[$input])) { // 都道府県名が正しい時の処理 } 一方で、in_array関数を使うやり方も考えられます。 <?php $prefs = array( "北海道", "青森", // ... "沖縄", ); if (in_array
【資料公開】アジャイル開発プロジェクトの始め方
みなさんこんにちは。@ryuzeeです。 これからアジャイル開発を始めるときには、気をつけておいた方がよいことや、実際にスクラムでスプリントを回す前にやっておいた方がよいことが色々あります。 それについて使っている資料がありますので参考までに公開しておきます。 これもやった方がいい、こういう時にはどうするの？などありましたら是非[Twitter](https://twitter.com/ryuzee)などでお知らせいただければと思います。それでは。 SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発著者／訳者：西村 直人、 永瀬 美穂、 吉羽 龍太郎出版社：翔泳社発売日：2020-05-20単行本（ソフトカバー）：288ページISBN-13：9784798163680ASIN：4798163686
Amazon Aurora のアーキテクチャまとめ - おくみん公式ブログ
先日公開された『Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases』を読みました。 興味深かった部分や疑問に思った(あんまりわかってない)部分をまとめておきます。 AWS は詳しくないので、ところどころ間違っているかもしれません。 Amazon Aurora とは Amazon Aurora のアーキテクチャ全体像 quorum 10GBに分割されたストレージ redo ログのみを転送 感想 Amazon Aurora とは Amazon Aurora は Amazon Web Service が提供する、マネージドリレーショナルデータベースサービスです。 Amazon Aurora (MySQL 互換のリレーショナルデータベース） | AWS Amazon A
JavaScript のもう一つの「関数名」 —— name プロパティ - Qiita
「関数名」と name プロパティ JavaScript において「関数名」あるいは「メソッド名」というと何を指すでしょうか。 関数オブジェクトを参照している変数名やプロパティ名を指すことが多いと思います。 しかし、もう一つ「関数の名前」と言える物として、関数オブジェクトの name プロパティがあります。 これは関数オブジェクトの生成時に決定される、文字列のプロパティです。 function foo() { // do something } let bar = foo let baz = foo let qux = [foo, foo] console.log( foo.name ) // 出力 -> "foo" console.log( bar.name ) // 出力 -> "foo" console.log( baz.name ) // 出力 -> "foo" console.l
転職ドラフトの結果と考察 - おいちゃんと呼ばれています
転職ドラフト（第6回） に参加した。参加に至る経緯については こちら に書いたが、それはともかくとして、結果を受けて、いろいろと自分を見つめ直す機会となったのでメモしておく。 結果 利用規約 を読むに（特に16条）あまり詳しく書いてはいけないと思うので企業名は伏せるけれども、 年収 800万 x 2 指名 年収 750万 x 1 指名 自分がパフォーマンスを発揮できる環境において、出せるバリューはこれくらいかなと考えて「希望年収」欄には 800万と記入していたので、まあだいたいそのくらいだよなと確認できて良かった。 全体の分布をみると下記のような感じで、ああ結構高く評価していただけたんだなと、嬉しく思った。 評価の理由 企業が記入してくださる欄に「指名理由」という項目があって、 フロントエンドとバックエンドどちらも高いレベル 適切な技術を選択してユーザービリティの高いものを一気通貫でつくり
Amazon ECSを用いたDocker本番運用の実現 - Qiita
はじめに 現在お手伝いしているアカウンティング・サース・ジャパンにて、ECSを使ったDockerの本番運用を始めたので、その一連の流れについてまとめました。 税理士向け会計システムを扱うアカウンティング・サース・ジャパンでは最近Scalaでの新規プロジェクトが立ち上がってきており、既存のプロジェクトはJavaであったり、Erlangであったりと様々な言語が用いられていますが、インフラ人員が少ないということもあり、なるべくシンプルなインフラ構成を実現する必要がありました。 そういった中、各アプリケーションをDocker化することでインフラとしては共通基盤としてのDockerクラスタのみの管理になり、運用コストが下がるのではないかという仮説からDocker化を進めることになりました。クラスタを実現するに辺りKubenatesなどの選択肢もありましたが、今回はECSを選択し、下記のようにAWSの
エンジニアの幸せ - 読むために生まれ。
エンジニアにとっての幸せとは何だろうか。一般的には、エンジニアとは何かを作る人だ。橋を作る人、ビルを作る人、電子機械を作る人、ソフトウェアを作る人、これらは皆エンジニアだ。よって、創造の喜びというのがひとつの答えとなるのではないだろうか。 一方で、世の中には、何も作りはしないけれども、エンジニアと同じように高度な専門技術を持っている人たちもいる。医者や弁護士やコンサルタントだ。このような人たちにとっての仕事をとおしての幸せは何だろうか。私は、技術の行使がその答えだと思う。 後者の人たちの仕事は、顧客あるいは患者から持ち込まれた問題を解決することだ。なぜ彼らのところに問題が持ち込まれるかというと、そのような問題の解決には高度な専門技術を要するからだ。問題解決者としての彼らの興味は、自らの専門技術を行使していかに困難な問題を解決するかという点に注がれるのではないかと思う。難しい問題ほど挑戦し甲
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Avdi Grimm
Web開発者が React Nativeで 開発から本番運用までして辛かった事
知っているようで知らないWebサーバアーキテクチャ