Yeah, mine too. But they're all the rage.

Theoretically they're amazing. And practically they have a lot of nice benefits. But I don't think it's worth it yet.

My macbook pro runs ubuntu and windows 8.1 flawlessly in parallels.
Not sucky or slow and it must be your machine not being powerful enough which sucks.

I did have a thinkpad that I setup virtual box to run ubuntu and it was really slow. Now the macbook pro has 16gb ram and built in gpu so obviously that has something to do with it. If the thing ever dies on me before I get 5 years of use, i'll consider it a bad investment.

Virtual box on my desktop cpu with i7 and 16gb ram is somewhat laggy at times. Not a huge deal but annoying. Running mint on a win 8.1

@kingofcool does it have a graphics card because I'm surprised that its laggy with an i7 and 16gb ram.

I have a few virtualbox snapshots of software in perpetual free trial mode. How much lag you experience depends on how much memory you give the box when you set it up. I have a few that run really smooth but will make my main OS (ubuntu) almost unusable.

Yes it does. Radeon r290, should be fine.. I only allocate 2 gb of ram to linux though, maybe that is the problem.

Yah only 2gb ram is most likely the problem.

I'm running the vm on my 6 month old retina macbook and comparing that to running directly on my 2012 retina MacBook.

My VM is maxed out entirely. The OS is okay speed, but VirtualBox is buggy as hell.

I think it also depends on what you are running. I've had good luck with Arch and CentOS. Ubuntu is pure mayhem.

I'm using Rails for the backend, only thing I've used before for a webapp, so sticking with what I sort of know

I'm running Ubuntu.

anyone have advice or know of resources on flexible permission design?

say my app has models with some fields and arbitary user "tiers". based on the current user's tier, when he accesses an object in the frontend, only certain fields are exposed (so some users can see Project.name, others can see Project.name/version)

two naive ways we're discussing are:

1. restrict fields at the view/controller level, since we know the auth'ed user, we point to specific serializers based on the user tier; major downside is we might need a ton of serializers, and different api end points (say search/browse) may need to repeat code to limit fields

2. restrict at the model level, so the ORM query only gets specific fields, the downside is i think the fields need to be moved to an EAV system (so they become relationships rather than fields). and we'd to maintain a massive user-to-EAV permissions table for efficient querying

anyone have experience with something like this?

How do promotions work at your place of employment?

Is it based mostly on time, mostly on performance, or a good balance of both?

Depends on what you're using on the frontend. What you might do is add some fields to each user document on the backend. Each field would correspond to a potential field name that is exposed on the frontend. Each field would be a true/false value which would basically be saying "authorized to access that field/unauthorized to access that field". If you're using something like knockoutJS, you would populate different observables with truthy/falsy values. In the view then you might use an if / ifnot binding with the observable to determine whether or not that content is displayed.

In the end, there are probably lots of ways to do what it is you want to do. The specific details of how to do it depend on what your tech stack is.

That is asking for problems.

Find an authorization library and don't ever roll your own.

I agree to find a library but I don't think this is a never roll your own thing like with authentication. Just that it's such a common problem that solid libraries already exist.

Also it doesn't sound like he's asking how to set up authorization but how to use it.

I'd say this is definitely something to be handled at the controller/view level. Whether this means many serializers or smarter serializers that can omit data based on the tier parameter you pass them I don't have a strong opinion.

Build your own stuff or be a pleb

My mentor at work today informed me he is leaving in two weeks because he took a job at Amazon. I am super stoked for him but really sad to lose him as a mentor

Maybe you'll be joining him in the near future Oo

sounds like an interesting problem. it's hard to answer without knowing more, though. could you give some specific examples? (eg, what are the tiers? what are examples of pages that need different views? what are the differences in the views? describe it without reference to anything technical)

algorithm question for those familiar hand evaluators, specifically with the array lookup table method used in the 2p2 evaluator, which requires an ~125MB array to be stored in RAM.

how much of a speedup over that method could you expect by doing the following:

1. using 64bit ints, represent each card as a single "one bit on" integer (ie, 1,2,4,8,16,...).
2. represent a 7 card hand as the sum of 7 cards, call this sum the "hand key"
3. rather than using the 2p2 method, which requires 7 array lookups, you do a single lookup in a hash table whose keys are "hand keys" from step 2. the value of the table is the same value as in the 2p2 method, ie, an int representing global hand rank.

so, you essentially replace 7 array lookups with a sum and one hash table lookup. i think it would take about 1G of RAM to hold the giant hash table.

my question is, would this result in a significant net improvement in speed?

Already read this I assume?

http://people.math.sfu.ca/~alspach/comp20/

yeah thx but that's more preliminary info to the question I'm asking. more accurately, my question is really a pure algorithm analysis question.

Random thought of the day: underscore.js is actually pretty cool. I wish all projects had the commented code stuff they do

For ordered enumerations you basically just need ~1 array lookup per evaluation using the 2p2 method by caching the intermediate indices. So there is no way you could be faster than this using your method.

And using a generic hash function doesn't work very well. As you said this would require 52c7 = 133784560 key/value pairs, which comes out to roughly 1GB. Due to the additional size this will result in considerably more cache misses than the 2p2 eval, and you have additional CPU cost for the hash function.

A better approach is to use a specialized "hash" function that attempts to map a high % of hands with identical ranks to the same index in a handranking lookup table, therefore reducing the overall size of the lookup. There is a trade-off between complexity of this function and size of the lookup table.

The hand evaluator I posted a while back is based on that approach, the last version is using a 512kb lookup table with an indexing function that is still fairly fast. (.jar incl source)

PS: Using 64bit int's to represent hands is fairly common for evaluations, e.g. HoldemShowdown