d4n3

Great idea... I don't mind paying for good games, but what i do mind is games that try to squeeze as much money out of you for just playing it, which fits your definition of bullshit games.

So unlockable DLC and removable ads are fine, but endless pay-to-win consumables aren't.

Sorting by number of reviews would be great - it's a better indicator of popularity than the review score

> The price is defined primarily by how much you ask for and what you can offer in return.

I couldn't agree more. I know a lot of developers that have the mentality to just accept what they are offered without negotiating. It's up to you to get a good price for the value you bring to the company. Negotiation is the best way to significantly increase your salary, regardless of your technical skills.

Patio said it best: http://www.kalzumeus.com/2012/01/23/salary-negotiation/

It seems like you're comparing current conversion rates vs. past conversion rates.. Did you try AB testing this side by side? It's not necessarily only the effect of image optimisation, could be just organic growth of your site?

I think this actually wasn't an arbitrary choice, but a result of the algorithm.. e.g. factors are displayed as clusters ordered in a circle (factors of 2 is a circle with groups of 2, factors of 3 is a circle of groups of 3).

So for primes, you have a circle of groups of 1.

Very cool visualization... I wonder how they get their data?

you could probably combine this with the font-face trick to target different letters

you could combine this with ::first-letter and custom selectors for each item of interest to get more specific data from targeted page elements...

If there was a way to target n-th letter in css, you could also get the full plaintext of an element with a huge number of font-face / selector combinations

Chrome devtools sort selectors by specificity by default and you can quickly see what order the selectors / properties were applied in and what overrided what.

Most of the !important uses I've seen are more due to "Why doesn't this work? Dunno, I'll just put !important on it.."

Since !important only applies to a specific property, it's not that useful for making structured CSS components, and makes it harder to override (using !important again on every property)

I can't think of many cases where using !important would be better than overriding with specificity. Maybe when using 3rd party styles or making styles that are embedded in an external page (e.g. widgets).

> as they seem not fully aware of the standard order of conflict resolution

I'd say it's the other way around - a lot of usages of !important are due to lack of understanding of CSS specificity, usually as a symptom of something else like using IDs in selectors..

If you avoid using IDs in selectors and avoid deep nesting of classes, then overriding styles works as you expect - apply a more specific selector to override the style.

Selector order only comes in to play rarely, and you can structure your files to start with less specific (base) styles first.

I see !important as more of a workaround than a solution, and I don't think it is used as it was originally intended.

There' a user switcher button in the top right corner, you can have multiple browser sessions with seperate histories / cookies (e.g. work / personal)

Right, with lots of elements, React still needs to render and diff each component which for a lot of elements causes a lot of garbage and diffing work. ShouldComponentUpdate / PureRenderMixin avoids this altogether when props/state isn't changed so this gives a significant boost with lots of elements.

PureRenderMixin is basically shouldComponentUpdate with a shallow comparison of previous/next props and state, but the big win is avoiding render and diff for the component, so returning false would be about the same as PureRenderMixin.

PureRenderMixin would defenitely help here, even to the point where it's comparable with the js solution.

Even though keys help here, render is still called for every image every time and then diffed.

He'd have to extract the image divs to a component and put PureRenderMixin on it so that the component's render is skipped altogether.

For me it was trying to index a huge folder containing images, you can use project settings to exclude some folders with the folder_exclude_patterns setting.

I think modern browsers prevent cross-requests to local subnets so this may mitigate CSRF

Ah ok. At first glance it looked like he was putting together something like an url.

It's way better to use [values].join('') here... It's probably faster and it coerces all values to string.

If the first couple of results were numbers or booleans, they would be summed:

    > true + 10 + " result"
    11 result

    > [true,10," result"].join('')
    true10 result

Javascript has "semicolon insertion".

It tries to parse a newline with no semicolon as continuing the current expression, if it can't, it inserts a semicolon.

It's a 'feature' that's caused too many bugs and is a warning in most linters.

Jshint catches this with 2 warnings: missing semicolon and expected assingment or function call.

In Sublime text 3, you can have inline warnings and as-you-type linting with the sublimelinter jshint plugin:

https://github.com/SublimeLinter/SublimeLinter-jshint

I love this quote in the comments:

> when you have REPL you are TDD’ing in a different way as opposed to constructing persistent unit-test classes that could potentially form a layer of cement.

Lately I've been using the console for development in rails and javascript more than anything and it is a really good way to iterate on a solution quickly.

Wow, that was exactly what happened to me... Everything is so sharp and square here.

Sorry, which library do you mean? The OP is a javascript library..

I just wanted to point out that regex is much faster in javascript than doing things 'by hand'.

> you'll want to replace them with code written in the native language

Probably not true for Javascript (and other scripted languages) - matching regex uses native and highly optimized regex lib, which will usually be orders of magnitude faster than implementing this in the language.

This is kind of disappointing.. I thought it would actually compile or something. Is it even possible with that BMP header?

Only writing some text as a bitmap isn't very impressive when the pixels are stored directly as bytes by default.

but how would you deal with async data fetches then?

I want to have the same routing and data fetching logic both on the client and on the server, and for that I would need to have stores that are independent for different incoming HTTP requests.

- dispatching and listening to actions. you need to pack your action with a magic string and a param object then unpack the params again in every listener. It's easy to forget what the params names are and its hard to see what the function gets as params just from its signature.

It would be much nicer to have e.g.:

   context.actions.myAction('foo', 'bar')

And

   onMyAction: function(foo, bar)

- dealing with asynchronous data fetches. The example shows that you should create 3 actions for every async data action: FETCH_STARTED, FETCH_COMPLETE and FETCH_ERROR.

How would you deal with cases where you need to fetch multiple data sources then combine them? Seems like the number of actions would quickly explode. Also, how would you deal with dependencies and errors?

- the service api:

    context.service.read('message', {}, {}, function (err, messages)

too many optional params, kinda hard to keep track what goes where.

I'd prefer something with promises.

- I also miss query params support in fluxible router

Anyone tried doing isomorphic (server/client) flux?

Most implementations rely on the flux stores being singletons which can't work for multiple requests on the server.

The only one that's isomorphic is yahoo's but that one feels terribly verbose.

The official OSX build (http://phantomjs.org/download.html) crashes for me with

Killed: 9

I upgraded because of SublimeLinter plugins (inline error checking for js, jsx, ruby, php etc.) only available on ST3.

ST3 seems pretty stable for regular use.

seems like lodash now has lazy evaluation as well when using the _(obj).method() syntax:

http://filimanjaro.com/blog/2014/introducing-lazy-evaluation...