gaming_mouse, I may be mistaken but I don't think it's enough to 4choose2 hole cards and run the resulting 6 7-card evals against the board, I think you need to 5choose3 the board also for Omaha, and run each 2-card holecards against each 3-card board, so ~60 5-card evals/hand.

Also, obligatory link: http://forumserver.twoplustwo.com/45...valuators-597/ Gullanian's best thread in software forum! (no omaha in there afaik, was too long ago!)

dave, the 7 card evaluator implicitly does the 5 choose 3 part. i have read that thread, great stuff!

ah ok. it sounded like you would be re-purposing a holdem evaluator, which I don't think would do 5 choose 3 by default. (does it? what for? sidenote: I'm no expert, mostly guessing!) it gave me the slightly amusing thought of being a "holdem player's noob mistakes in omaha" evaluator "But I have the nut flush! oh wait must use exactly two holecards "

oh nm, i misunderstood you the first time. you were correct. the normal 7 card evaluator wouldn't enforce the must use 2 hole cards. so yeah, now we have (5 choose 3)*(4 choose 2) = 16, more than order of magnitude slower than straight holdem.

so back to the question of my original post: is there a better way? i believe you could use the LUT method, but the LUT would probably be a gig or two of RAM.

EDIT: just spitballing here, but i think one other possibility is to recreate the standard holdem lookup, but with the enforcement that both hole cards are always used. then you'd be able to successfully loop the 6 hole combos, and still have a LUT which is like 120MG

@shoe,

happened to come across something today relevant to our previous conversation about rails:

http://alisnic.github.io/posts/rails-logic/

if i were to use rails again, i would follow the advice here strictly. it would answer a lot of my objections. of course the thing that bugs me is that if you want to use the framework in a way consistent with good design, you have to structure your app in a nonstandard way. imo this should be the standard way everyone structures his app (in any case, it's a big improvement over what is now standard).

I tend to break out things into services in Angular, so that design pattern is pretty common to me. I try not to go overboard with this stuff though, when it becomes a problem then I deal with it by shuffling things around.

Sometimes it's not terrible to have certain things in a controller that you could in theory move to some type of service. I see a controller as a big robotic arm that just gathers data from many different sources and then sends it to a view.

I do like the idea of having isolated bits of functionality being called though but at the same time I'm not a huge fan of mocks/stubs. If you're going to have a test database to work against you might as well use it. I could see the reasoning for not using it for certain things though. There's no reason to test to make sure ActiveRecord works, it already works and is well tested.

Btw so far I'm about a third of the way done reading Eloquent Ruby (great book imo), skimmed some of the official rails guides, figured out a decent work flow for making new projects (using rvm to manage gemsets, etc.), picked out a bunch of handy development oriented gems and started to go through popular gems for popular bits of functionality.

It's worth noting this is not what a controller is in classical MVC, and i think it's a misleading way to think about them even in the context of web applications.

Controllers are an intermediary between models and views which are classically responsible for updating the model when the user manipulates the view.

--http://addyosmani.com/resources/esse...ook/#detailmvc

The controller takes user input (in a web context, web requests) and delegates to model objects (in the domain sense of that word, not in the ORM sense). That is its primary conceptual purpose. Because in typical web apps the views cannot directly observe the model objects, it is often used for this secondary task of preparing data for the views. This need not be so. See https://github.com/garybernhardt/raptor for an alternative that I find much cleaner, which pretty much eliminates controllers altogether. You can steal the basic concepts of this approach and apply them to rails too, to keep your controller thin and focused.

You really shouldn't be coupling your tests to a test database. You are right that mocks and stubs can be a sign of suboptimal design. See http://www.confreaks.com/videos/1314...012-boundaries for an illuminating talk about minimizing and isolating them.

+1

I don't really limit myself to definitions. I just use what makes sense. For example in the article that your article linked to he had a contact system where it saved it to a db and sent an e-mail.

In an express app my first instinct would be to have both actions being called in a route handler.

This way I can simply look at the route and instantly understand that it's saving to a db and sending out an e-mail. Having to look into the model code to determine any secondary actions seems like a mistake to me.

A good example would be:

Let's say a user uploads a photo. I would see this as many small actions.

UploadFile
ResizeImage
CopyToCDN
EmailNotification

I don't think I would add any of those to a traditional model because it has nothing to do with the user model. They are completely isolated events that have nothing to do with each other.

They belong as services and to intermingle everything I would just throw them in a controller. I wouldn't separate them until I had a reason to do so though. If I wasn't using the code in other spots of the program I would probably just inline in the controller, using private methods most likely so I can still skim the controller action and see what's going on at a high level without much thought.

I guess you could say I would do this in order:

1. Inline to controller.
2. If it got too nasty, refactor it to a private method in the controller.
3. If I wanted to reuse it elsewhere, isolate it to its own module and label it as a "service".

---

I don't like to get bogged down by OOP madness. I was happy to read that while Ruby does have classes and inheritance it's implemented in a way that doesn't suck. That book used an example of the File class and StringIO class both exposing the same methods. You can assign a variable to either one and just use it. Not having to worry about interfaces and abstract classes is a massive win to me.

i'm not suggesting you limit yourself. i'm suggesting understanding the history of the pattern will give you deeper insight that will help you use it and variations of it more effectively.

It's not a mistake. You're looking in one file instead of another. If you are literally following the path of execution, you'll need to open the controller file, see what it delegates to, then open that file. But if your objects are named properly you won't even need to do that. You'll know based on the *behavior* you are invoking what object it belongs to, and you'd just open up that file.

What do you mean by "traditional" model. I suspect you are thinking of an ActiveRecord model or something similar, which isn't what I mean and is what I've been railing against. I am basing this on your assumption that this has anything to do with a User model. Maybe you aren't understanding the distinction between database model and domain models? I mean, resizing files, copying them, sending emails -- these things have nothing to do with User behavior. I can't say for sure, but you'd probably want something like a "PhotoSubmission" domain object (remember, this is not a database object). That object would collaborate with "CDNBackup" and "EmailNotification" services. You could group the 3 image related actions together and expose it as a method called, perhaps, "postUploadHousekeeping()"

Why would you do this instead of putting it all in a controller?

1. It will be much easier unit test. And much faster. You are now testing something that isn't tied to the rails (or express, or whatever) framework. And why should it be tied there? This behavior has nothing to do with a particular framework. What if I decide to swith frameworks? If you do it the way I'm suggesting, nothing changes. Your objects, with all its tests, still work. You'll just be using it somewhere else.

2. Re-use. You allude to this your point 3 above. I'm suggesting skip steps 1 and 2 and go right to 3. For no extra effort, you can now use TDD, test your code properly, and have it ready for reuse.

The question is, why wait? It doesn't require any more time to start with the code as a module that you are delegating to. Really, you're just creating a second file. And if you don't do that, you won't be able to TDD it, and when it's finished, it won't be tested. The bottom line is controllers are awkward to test, and they tie your application code to arbitrary framework details. I think it just feels easier because those are the steps you've done a thousand times.

I wait because often times if you try to make something too generic before you even use it you end up wasting a lot of time or it becomes extremely complicated very quickly and now instead of just making the thing work you're worrying about how it might be used in 30 different use cases.

I think another difference is I don't really do TDD too. I write tests but a lot of times I write them to confirm my code afterwards, I don't use them to drive the design of my code. I would say like 90% of the time that is how I do it. The other 10% of the time I do some form of TDD but this is mainly to help me work through a problem in an algorithmic way.

I wrote up a make believe snippet of Express code. I feel like this is where I would get eventually with the code after it started to become a problem. Also while coding those functions, if something jumped out and it really made sense to turn one into a generic module asap then I would do it.

It's why you can't build a framework out of thin air. Frameworks are usually pulled out of projects and are made modular at a later time. It happened with django and rails and it happens all the time in javascript too.

I'll write something inline for some project and be like oh "ohh cool, this could be a module". Then I wrap it up, modify it a bit and publish it to npm.

The timing of this conversation is amusing since I have to refactor this web application in the next couple weeks (PHP with codeigniter though. please be gentle :P) and i've been trying to figure out a lot of this stuff (controllers too heavy, domain model logic versus purely db related logic, moving things into services, etc etc)

I've definitely gone for the ol' hack the **** out of it and figure out how it should actually be done later route. But now it's later

@Shoe,

You're creating a strawman. Pulling the code into a separate file isn't making anything general, or more abstract, or anything. Literally just put the code in another object, include it at the top of your controller page, and then call that other object from the controller. Congratulations, you've now untangled your application logic from your controller.

If you set stuff up so that it's super easy test, you might be inclined to test more. At the very least, it will be easily testable when you decide to do so.

I just have to do my standard rant here - he didn't say he doesn't test. He just said he doesn't use TDD that often.

Not doing TDD does not mean your code is not tested.

Edit: Re-reading both posts maybe I misunderstood but in case I'm not, and because I really like to rant about this, I'll leave my post up.

I don't just throw them in a diff file and call it a day. I would be passing in values to those functions from the route (mentioned this in the comment). I just didn't bother to add them into this example because I didn't think through how any of those functions would work and it wouldn't make sense to anyone who has not used express.

The uploadFile() function itself wouldn't depend on a request. All it would care about is that the thing you passed into it contains everything necessary for it to do its job. It would probably depend on express in the real world because of how express returns the list of files being uploaded but that's a usage detail and isn't related to mocking or testing it away from express.

It could be mocked easily if you wanted to test it in isolation because at the end of the day it's just an object with a few properties. It doesn't matter who created the object.

The reason I code in features before testing most of the time isn't because testing is slow or difficult. It's just a style I prefer to work with.

I feel like I can pump out code and get to a working example quicker if I don't have to be bothered with any testing ceremony. Then once it's working, it's like there's a huge burden removed and I can spend all the time I want to make the code awesome and test all the little edge cases.

As long as I don't go a long time before making it awesome things tend to work out well. The problem is when you end up writing in 5 features and you end up with a 300 line function that's impossible to test and you have to ship it due to time constraints so you just say fk it and work on feature #6. Then you're kind of screwed. As long as you have discipline to refactor before things get ugly then you don't "need" to be a hardcore TDD enthusiast to have solid test coverage.

Each time I build a web app, I forget how much f'ing work goes into getting it ready after most of the app is already done. So many small things, just me to fix them... ugh.

I've recently read "The first 20 hours - How to learn anything fast".

Structure of the book is ... first some basic explanation of how you should go about learning quickly (basically common sense imo) and then chapters on all the skills the author picked up (Yoga, programming, Go, windsurfing, playing Ukulele, touch typing).

While I didn't like the book (I somehow expected more...didn't even finish reading all the learned X chapters) as much as I expected it has an interesting chapter on learning to program. The content is nothing special (he's learning Ruby+Sinatra to replace his WordPress blog) but it's fairly interesting to see how someone with no/very little knowledge about programming approaches the problem. Good exercise in empathy to read someone like that explain concepts he thinks may be important.

I kind of wish that chapter would be available standalone (maybe it is didn't google) because it seems like it could be a decent pointer for someone that wants to get started.

Edit:
TED-Talk

16 5-card lookups, so you can't compare directly to the one 7-card lookup of holdem (the naive 7.card holdem one does 7c5 = 21 5-card lookups, so it's possible the Omaha one is actually faster)

the LUT for holdem (based off the famous one) is just one LUT which you can use for 5, 6, or 7 card hands. A 7 card hand does 7 array lookups, and that's it, so you don't do 21 5 card lookups.

i don't follow what you are saying about 15 5-card lookups. Maybe we're just talking about different approaches? I am imagining a single LUT approach as is used in holdem, so it wouldn't be limited to 5 cards.

God the business IT market is insane. My sister just told me what kind of software they are getting and what they'll pay for it. 5k+20%/year for some basic CRUD no fancy requirements basically just store some stuff in a DB instead of Excel.

I seriously feel like I should just hack together a basic ERP thingy (just store people, company, invoices) and stuff like that would take a day...three with meeting them and wandering around the place.
[And I'd be shocked if hacking together the base system would take more than a week...could be a bunch more if you do some fancy stuff but that is not required at all]

This is what I was talking about the other day. The crapware the company uses is a friggin joke. They've been asking for a "feature" to allow inventory to be correctly counted for years and the company has been dragging its feet since time eternal. One would think counting products sold would be the first thing a program would get right, but nope, not on commerce software.

Most companies build the stuff internally and have it customized for them specifically or just hire a consultant because they have 10 small but totally unrelated problems. It's not easy to find a good general purpose CRM or "ERP thingy", I don't think one exists.

Good luck building something that can compete with http://www.salesforce.com in about a week though. They are a full blown CRM service but have ERP-like stuff add ons.

The problem is every business has completely different problems. I just spoke to someone the other day where they have this non-standard way to pick vacation days. The details of it doesn't matter but, they wanted a web app setup so that people could sign in and pick their days instead of keeping track of it on paper (~50 employees).

You're kind of missing the point I'm trying to make. There are bazillions of smallish companies that don't need salesforce (and probably have no idea it even exists). Essentially what they need is "Excel in a Database+some basic items like people and companies and invoices"

The point is setting up this base system (which is essentially your typical blog post tutorial except instead of blog posts you have other items such as companies, people and so forth) and then spending a day with them and a day coding and having a "custom made" system. I've worked in ERP and it's essentially the same on a higher level. This should be incredibly easy to scale down.

I'm not interested at all in customers with complex setups of any sort. I'm interested in the companies that have one person that handles their IT stuff with some manual Excel tables.

[Also I think you're overselling the complexity of ERP-systems in general. The problem is that most ERP systems are a load of grown ****. If the underlying system is sufficiently intelligent in the abstractions you can handle surprisingly complex setups. Security configuration is often considered very hard but I've seen systems that make pretty much any security configurations quite easy and elegant. Basically takes a consultant walking through the company and filling out sort of an org chart in Excel/Calc and security roles and employee stubs are autogenerated from that. 2 days with a little preparation (securing access to the right people mostly) for a 1k company with non-trivial structrues]

I think poker-eval uses the holdem evaluator to evaluate Omaha hands. If i remember correctly from going through the code, it filters out all the hands that it isnt a legal omaha hand. Probably a pretty poor way of doing it, figures to be atleast 60 times slower that holdem evaluation.

Using Cactus kev it would probably be about three times slower for Omaha than holdem evaluation since it evaluates 5 card hands.

Havent seen any public code where theyve gotten around the problem that you cant evaluate it as a single hand.

Anyone have thoughts on Spring Roo?

I want to learn one of the high productivity web frameworks and would like to leverage my Java background so I guess that means Grails or Roo.

I currently use Spring MVC and both Grails and Roo sit on top of that. Grails would require that I learn Groovy while Roo is pure Java. A big concern I have with Roo is if it's actually being used or if it's going to die. A nice thing about Roo is I already know a lot about Spring and am really comfortable with Eclipse.

However, I'm also terrible doing command line stuff and have always programmed Java on a Windows OS, so thinking it may be a good career building exercise to partition my drive and put a Unix OS on there and force myself to learn Grails from the command line.

There are some articles/blogs out there comparing the two, but there doesn't appear to be a real consensus, so any thoughts would be appreciated.

Why not pure Rails? Really good documentation. Rails is reaching enterprisey level so it's not going anywhere. The Ruby part of rails is not that complex (of course behind the scenes Rails uses some Ruby magic), but for everyday use you don't need to be a Rails expert to be productive.

Install Debian 6 on a virtual machine, setup rails/everthing else.