andrzejkrzywda

19 ms·

121.
by andrzejkrzywda 14y ago
"I still find back-end developers who are resistant" "(...) how happy they where not not have to deal with UI requirements and be able to focus on the business logic." I've noticed the same, but I still don't understand why is that. I'm cur
122.
Frontend is a separate application(andrzejonsoftware.blogspot.com)
8 points by andrzejkrzywda 14y ago|5 comments
123.
How to waste time on TDD(andrzejonsoftware.blogspot.com)
2 points by andrzejkrzywda 14y ago|0 comments
124.
Everything You Always Wanted to Know About Fibers, But Were Afraid to Ask(blog.robert.pankowecki.pl)
3 points by andrzejkrzywda 15y ago|0 comments
125.
How we ended up organizing a Ruby conference(andrzejonsoftware.blogspot.com)
4 points by andrzejkrzywda 15y ago|0 comments
126.
DCI and Rails, lessons learnt(andrzejonsoftware.blogspot.com)
6 points by andrzejkrzywda 15y ago|0 comments
127.
Rails is still cool(andrzejonsoftware.blogspot.com)
11 points by andrzejkrzywda 15y ago|1 comments
128.
Args, opts, params(andrzejonsoftware.blogspot.com)
1 points by andrzejkrzywda 15y ago|0 comments
129.
by andrzejkrzywda 15y ago
Yes, exactly. The idea is that the Data doesn't change that often, so it's kept separate from the things that change frequently - roles, use-cases. Exposing use-cases is also an important goal, usually they are scattered across the codebase
130.
by andrzejkrzywda 15y ago
The metaphore of DCI is a theatre. The context is the director. Chooses who plays what, instruct them how to do it and then let them play. Theory: 1. Expose use-cases (context) as first-class citizens of your code. 2. Each use-case selects
131.
Ruby On REST 2: Representers and the DCI Pattern(nicksda.apotomo.de)
28 points by andrzejkrzywda 15y ago|9 comments
132.
Ruby On REST: Introducing the Representer Pattern(nicksda.apotomo.de)
5 points by andrzejkrzywda 15y ago|0 comments
133.
Continuous integration - some tips(andrzejonsoftware.blogspot.com)
2 points by andrzejkrzywda 15y ago|0 comments
134.
CoffeeScript is the fresh air(andrzejonsoftware.blogspot.com)
1 points by andrzejkrzywda 15y ago|0 comments
135.
by andrzejkrzywda 15y ago
OP here. There's one more reason why I want to clarify the situation with terminology. Apart from being a Rails developer and running a Rails company I also teach Ruby on Rails at a university. Obviously, I'm not the single source of knowle
136.
by andrzejkrzywda 15y ago
I'm a Rails person, but I always respected the Django community. The fact, that you were clear with the MVC vs MTV approach since the beginning was one of the reasons.
137.
by andrzejkrzywda 15y ago
Here are the definitions as I know them: MVC - MVC is separated, Models can notify Views. Model1 - mixing all code in one place, often seen in first PHP apps Model2 - separation between Model and View, I think Struts started it. Rails made
138.
MVC with CoffeeScript(andrzejonsoftware.blogspot.com)
46 points by andrzejkrzywda 15y ago|9 comments
139.
Rails is not MVC(andrzejonsoftware.blogspot.com)
138 points by andrzejkrzywda 15y ago|45 comments
140.
DCI and Matrix: Can you fly that helicopter?(andrzejonsoftware.blogspot.com)
2 points by andrzejkrzywda 15y ago|0 comments