複数の ActiveRecord オブジェクトをまとめて扱う - ursmの日記台北市立動物園と迪化街めぐり 子連れ台湾#5 年越し台湾旅行5日目、レジャーや友人との食事を楽しむ日です。前日の様子はこちら www.oukakreuz.com 台北市立動物園へ パンダ館 パンダが見られるレストラン 迪化街へ 林茂森茶行でお茶を購入 小花園で刺繍グッズを購入 黒武士特色老火鍋で夕食 台北市立動物園へ 松…
satococoa's blog - pplog iOS アプリをリリースしました
pplog の公式 iOS クライアントアプリをリリースしました。 pplog on App Store pplog とは pplog (通称ポエム) についてはメインプログラマの @ppworks さんのブログとデザイナの @ken_c_lo さんのブログを見ていただくのが良いと思います。 このプロジェクトの目的について高らかに語られていますのでぜひご覧下さい。 まったりと過ごせるおれたちのインターネット、それがポエム pplog.net #pplog - ppworks blog 俺たちのゆるふわインターネット「pplog」 をリリースしました（してました） - 納豆には卵を入れる派です。 pplog iOS クライアントについて pplog iOS 版の構想はかなり初期からあって、web 版 pplog を身内だけでクローズドにカリカリとドッグフーディングしている頃から、「どうせなら
離婚して1年して思うこと
25で結婚して、28でマンションを買い、30で別れた。 原因は物理的なすれ違いの末のセックスレス、よくあることだ。 1ヶ月が3ヶ月になり、3ヶ月が半年になり、半年が1年になり。 一度レスになるとキスもしなくなる、カラダに触れられなくなって、手もつなげなくなる。 何となくいけないんじゃないかと思いながらも、人間的には好きだし、忙しさを理由にして放っておいた。 スキンシップがなくなると、必然的に会話も減り、相手の考えていることがわからなくなった。 そうして3年くらいかけて、ゆっくりとゆっくりと他人に戻っていった。 そもそも子供が欲しくて、そのための経済的な基盤を整えるための期間に、皮肉にもレスになってしまった。 最後は同じ部屋にいる時の張り詰めた空気が苦痛になり、別居した。 相手がどんな金持ちだろうが、貧乏だろうが、美人だろうがブサメンだろうが、 誰と結婚しても意識を変えなかったらきっと同じだ
Webアプリ開発をする上で読むべき本とか - catatsuyとは
Web アプリ開発をする上で読むべき基本的な本は無いかと聞かれて，すぐに出てこなくて困った 今後もそういうことを聞かれることもあるかもしれないので個人的にまとめておきたい 基本的には何かを作ってみて，習うより慣れろの精神で行くのがいい 最近は Ruby on Rails が流行りな気もするのでその辺りで役に立ちそうなサイトを紹介する Ruby on Rails チュートリアル：実例を使って Rails を学ぼう サクサク引ける Rubyリファレンスマニュアル bbatsov/ruby-style-guide Rails のチュートリアルはたくさんあるので他にも読んでみると良いかもしれない ただ Ruby on Rails が簡単というのはウソ - #生存戦略 、それは - subtech に書かれていることを全部やろうとすると絶対にハマるので分かるところから少しずつやるといい それと We
Ruby loves DDD - ema.blog
On 14th june, in Milan, I spoke at the rubyday, and I presented a possible implementation of Domain Driven Design (with CQRS and Event Sourcing). I know quite well the principles and patterns of DDD since we used them in some applications developed by CodicePlastico, but I never tried to do the same with Ruby. The main reason of my experiment is that in C#, implementing this kind of architectures,
Home
Costruiamo sinergie tra aziende e tecnologiaSiamo una squadra di esperti che, da più di dieci anni, crea soluzioni IT capaci di generare valore. Lavoriamo con le aziende, progettando e realizzando sistemi nei quali la tecnologia è un reale strumento di supporto ai processi operativi di ogni giorno. Vai al quartier generale! L'altra metà della melaOgni progetto inizia con una stretta di mano, reale
CQRSの和訳
DDDとCQRSについて DDD (Domain Driven Design = ドメイン駆動設計)が世間に知られるようになってきましたが、今度はDDDをさらにスケーラビリティにするCQRS (Command Query Responsibility Segregation = コマンドクエリ責務分離)が出てきました。 DDD提唱者の英語本の和訳版「エリック・エヴァンスのドメイン駆動設計」がAmazonにありますが、非常に分厚く高価です。概要をまとめた資料が「Domain Driven Design（ドメイン駆動設計） Quickly 日本語版 - InfoQ」から入手できます。 CQRSはデータベース設計とイベントソーシングも含めた壮大なWebアプリケーションのアーキテクチャですが、日本語の資料がまだ少ないです。CQRSを適用したアプリケーションを構築できるインフラがWindows Az
一緒に働けない人、働きたい人 - The HIRO Says
ガイアが俺に書けと囁いているので、徒然なるままに。 一緒に働けない人 １．常に他人事 たとえ仕事であっても、絶対に自分でやろうとしない 自分の仕事ではないと常に考えようとする／発言する 「へ〜大変ですね〜」が口癖 ２．言葉の定義にイチャモンをつけたがる 「それって、xxという言葉の定義と違いますよね。それじゃ私の仕事じゃないです。」 「何でそこでその言葉を使うのか理解できません。そもそも（以下略」 『「バグがあるかもしれない」と「バグがある可能性がある」とは意味が違いますよね』 私も意味が分からなかったです ３．話している最中に内容をすり替える ４．最終的には逃げる これが癖になっている人って、何で社会人やっているんだろうね？ こういう人とは、話しても理解し合うことは不可能。一緒に仕事をしていても、尻拭いを強いられている感に苛まれるだけ。関わらない環境を作った方が良い。 昔しんどいと思った
クソコード、あるいは技術的負債 - 時計を壊せ
クソコードについてここ数日で考えたことを書いてみる。 技術的負債まわりのえらいひとたちの議論を眺めてて、技術的負債って言うとなんかプロっぽいけど、クソコードって言ったほうが示したいモノを素直に表してるし分かりやすいきがしてきた。 クソコードを書くなとは思わないけど、クソコードをいつまでも放置するのはやめようって思う。 クソコードは次なるクソコードを生み出すし、バグを隠蔽するし、メンテナンスコスト増大の悪循環のキッカケになるし、新人の教育上良くないので無くて済むならもちろんないほうがいい。 ただ、ギークな人たちを除いて、さらっと60点*1のコードなんて書けない。僕を含め大多数のエンジニアは自分自身が書いたクソコードをリファクタリングして60点以上のコードを目指すための時間が必要になる。 そのうえ、そういうコードを書いてもだいたい時間経過に伴って事情が変わって、60点のコードの挙動を壊さないよ
25年前に放置されたシュールストレミングの缶詰が発見され軍の連絡により専門家が出動
「世界一臭い食べ物」と評されるスウェーデン名物ニシンの塩漬け「シュールストレミング」。うっかり放置すると缶詰が膨らんで破裂しあたりに臭いをまきちらす危険な食べ物ですが、25年放置した缶詰が見つかり軍と専門家が出動する事件がありました。 先日、ノルウェーのインゲ・ハウセンさんは所有する山小屋の屋根裏でシュールストレミングの缶詰を発見。90年代に購入したものの食べ切れなかった残りを放置してそのまま忘れてしまっていたということですが、缶詰は膨らみきっており屋根を2センチも持ち上げる超危険状態であったため、ハウセンさんは軍に通報しました。 しかし、シュールストレミングは爆発物でも毒ガスでもないため、軍はスウェーデン・シュールストレミング学会のルーベン・マドセンさんをハウセンさんに紹介。2014年2月18日、スウェーデンとノルウェーの新聞記者や17のテレビ局が報道する中、無事に「処理」することに成功
Ginza.rb 第8回 Gemfileみせっこ！みんなどんなの使ってます？ を開催した
Ginza.rb.第8回を開催しました。今回は参加者の方に事前にGemfileをアップして頂き、使用しているgemについて説明をして頂く形式で実施。 Gemfileの置き場は[こちら](https://github.com/ginzarb/meetups/issues/6)。 話に上がったgemについて以下にずらずらと。 ### [gon](https://github.com/gazay/gon) Rails側の変数をJavaScriptに渡す事が出来るgem。 controllerから大量のデータをJavaScriptに渡す必要がある場合に便利。 詳細は[RailsCast](http://railscasts.com/episodes/324-passing-data-to-javascript?language=ja&view=asciicast)参照。 ### [Better E
scopeはlambdaで書いて - (define -ayalog '())
軽くハマッたので。 class User < ActiveRecord::Base scope registered:, where(registered: true) end って書いてしまうと User.registered.where('age < 20') こう書いたときと User.where('age < 20').registered こう書いたときの結果が変わってしまう。*1 具体的には開発時とかに追加したはずのデータが正しく取得されなかったりする。 Rails4以降でのscopeの書き方はlambdaが必須なので、以下のように書くのが正しい。 class User < ActiveRecord::Base scope registered:, -> {where(registered: true)} end *1:というか、正常に動いてないんだけど
Railsエンジニア(仮)にジョブチェンジしました - (define -ayalog '())
2014-02-24 Railsエンジニア(仮)にジョブチェンジしました 日記 開発 Java Rails 2/17から新しい環境で働き始めて*1なんとか1周間乗り切りましたってことで近況報告的な。過去4年間システム開発に携わってきて、それまでJava*2一辺倒だった僕がRailsエンジニア(仮)*3になったお話です。ちなみにJavaは言語でRailsはフレームワークだ！っていうツッコミを貰う前に書いておくと、やっぱりRailsってRubyというよりはRailsって感じなので、この辺はRailsを書いている人なら分かってもらえるかなーと。 Railsエンジニア(仮)にジョブチェンジするためにやったこと まず、大事なことがふたつありました。 上司の理解を得ることが出来てサポートしてもらえること やりたい仕事をするための知識/スキルを持っていること 1については元々僕が転職するときに既に社長に
人生って別にそんなにつらいものじゃないよ
日本はとりあえず恵まれている例えば自分がワープアだとするじゃん。年収２００万以下。辛いって思うじゃん。でも、月１７万くらいあったら、安い家賃のところに住んで、そこそこうまくもまずくもない飯を毎日食べれて、娯楽費にもある程度ぶちこめてちょっと節約すれば貯金もできるわけ。（ただし独身に限る） 発展途上国ではなかなかこうはいかない。飯が食えて家があるだけでとりあえず上等。娯楽費にお金なんてなかなか使えない。とりあえず何かスキルをつければお金をもっと稼げるようになるスキルがあれば億万長者になってうっはうはというわけではないけど、とりあえずある程度まで何らかのスキルを身につければ、収入は上がる。そうすれば生活はもっと楽になるし、選択肢ももっと広がる。こういうのって２１世紀より前ではなかなか考えられなかった、つい最近の話。悲観しているのは未来が悲惨っぽいからどうせ頑張ったって人生に意味なんてないんだか
Passive View Pattern - Tbpgr Blog
概要 Passive View Pattern 詳細 旧来のMVC Model View Controllerの構成であり、 ・Model ドメインオブジェクトで、データに関わるビジネスロジックを含むもの。 アクセサやわずかな処理しか持たず、サービス層に処理を任せるのはドメインモデル貧血症である。 ・View 表示を受け持つ。 ・Controller ViewとControllerの仲介。 入力を元に適切にモデルを呼び出したりするのが主な責務。 旧来のMVCの問題 ドメインに属さないようなロジックを書く場所が明確に規定されていない。 表示のためのロジック等。 Passive View Pattern MVPパターンの一種。PはPresenter。 Presenterはモデルの呼び出し、UI系のロジックの時刻、Viewの操作を行う。 Viewは操作される側＝Passive View（受動的な
Blog
What We Know Our key takeaways from partnering with enterprise-level engineering teams. Details How We Ensure Success Our unique and personalized approach to help you achieve your business goals. Details Your SEI Platform Get to know your custom-designed Software Engineering Intelligence (SEI) platform. Details
model の decorator の話
最近の sapporo.rb などでは ActiveDecorator など、model の Decorator の話で少し盛り上がっているようだ。view に関わるコードをどう整理するか？という話について、共通見解が定まってきたということだろう。 rails の MVC に沿ってコードを書くと、view 回りがだんだんごちゃっとしてくる。scaffold のように単純に model の property を表示するような view なら良いが、STI のタイプに応じて表示内容を変えるとか、新規登録の場合と更新の場合で表示を変える、ユーザの権限に応じてどこまで情報を見せるか制御するなど、model のデータやセッションのデータに基づく条件分岐と html の描画が絡み合うような場合にこれをどこに書くのか？というのが問題になる。 伝統的な rails のレイヤーわけだと候補としては view
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Hipster Dev Stack
GitHub - emadb/ruby_loves_ddd: A sample application to get practice with ruby and Domain Driven Design